基于SaaS的规则引擎在企业流程中的应用引言规则引擎原理流程应用基于saas的模式意义
1、引言
目前，B2B电子商务平台发展了大量的中小企业用户，提供具有共性的信息管理服务，但是这些服务对于特定用户来说，无法根据该用户的业务流程来构造与其自身业务相匹配的管理过程；同时，平台亦无法应对会员企业将来发展带来的管理过程的不断变化。
在这种情况下，为中小企业用户提供个性化的服务，对企业的意义是非常重大的。
尽管现在有些软件开发商为企业提供量身定制的功能需要，但这种方式开发成本很高，而且基本上是按照当时或者用户可以预见的方式进行开发，不可避免的出现一些弊端：（1）需要安装专门的管理系统软件，维护困难；
（2）功能的灵活性较小，只能符合某些行业的特点，不符合B2B电子商务平台上广大行业的需求；
（3）功能的配置操作复杂，不利于中小企业用户的使用；
（4）功能维护和修改的成本高。
为了解决上述弊端，基于SaaS的业务规则引擎的方法被提了出来，这种方法充分利用了SaaS（软件即服务）的特点，不需要在中小企业的计算机上安装任何软件，把系统的日常维护工作都交给软件服务运营商；而且使用成本低廉，符合中小企业的信息化成本要求。同时通过企业业务流程与规则引擎的结合应用，把商业规则与应用开发代码，让中小企业的工作人员能在运行时可以动态地管理和修改商业规则，保证了软件系统的柔性和自适应性，使电子商务平台为中小企业用户提供个性化的服务打下了良好的基础。
2、业务流程与规则引擎
2.1 业务流程与流程引擎
业务流程属于工作流的范畴。工作流指全部或者部分由计算机自动处理的业
务过程。而工作流管理系统是这样的一个系统：详细定义、管理并执行“工作流”，系统通过运行一些软件来执行工作流，这些软件的执行顺序由工作流逻辑的计算机表示形式（流程定义）来驱动。
工作流系统与业务系统的关系如下图所示：
国际标准化组织WFMC（工作流管理联盟）发布了一个通用的工作流系统实现模型，这个模型可以适用于市场上的大多数产品，因此为开发协同工作的工作流系统奠定了基础。
把工作流系统中的主要功能组件，以及这些组件间的接口看成抽象的模型。考虑到会有许多其他的具体实现不同于这个抽象模型，因此，特定的接口在不同的平台中会采用不同的技术，有不同的实现方式。而且并不是所有的开发商都会暴漏功能组件间的每一个接口，具体的规范会定义接口之间的相互操作功能，不同的厂商必须支持这些开放接口才能实现不同工作流之间的协作。
通用的工作流系统实现参考模型如下所示：
不同的厂商必须支持5类开放接口才能实现不同工作流之间的协作。
a)过程定义工具（Process Definition Tool）
过程定义是用来创建一个计算机可以处理的形式的过程描述。可能要以形式过程定义语言、对象关系模型、简单的系统、脚本、或者在参与者间进行信息传递的路径集为基础。工作流定义工具，可能作为工作流产品的一部分、也可能作为业务过程分析产品的一部分来提供给用户，作为业务过程分析产品一部分，会有其他的组件来负责处理业务过程的分析或者模型，这时，必须要有兼容的转换格式，与运行时期的工作流软件进行过程定义的相互转换。
b)过程定义（Process Definition）
过程定义包含，工作流执行软件运行过程所需的过程所有详细信息。包括过程的开始和结束条件、组成活动、在活动间进行导航的规则、需执行的用户任务、可能会被调用的应用程序、所有工作流相关数据的定义等。
过程定义可能会涉及到一个组织/角色模型，模型包含组织结构和组织中的角色等信息。从而使过程定义在，与具体活动或信息对象相关的组织实体和角色功能方面，十分详细。工作流执行服务器负责把工作流运行环境中的参与者与相应的组织实体或角色联系起来。
c)工作流执行服务器（Workflow Enactment Service）
工作流执行服务器软件负责：解释过程定义、控制过程实例、安排活动的执行顺序、向用户工作表中添加工作项目、调用应用工具。这需要一个或者多个协同工作的工作流机来完成这些职责，工作流机管理各种过程的一个单独实例。工作流执行服务器维护内部控制数据，这些数据或者集中于一个工作流机中，或者分布在一个工作机集合中；这些工作流控制数据包括与各种过程、或者正执行的活动实例相关的内部状态信息，也包括工作流机用来合作或者从失败中进行恢复的检查点、恢复/重新启动信息。
过程定义与（运行时期）工作流相关数据协作，一同用来控制过程中活动的导航、提供活动的进入与退出条件、不同活动的并行执行、顺序执行选项、用户任务、与每个活动相关的IT应用程序等。如果过程定义包括组织模型/角色实体类型，那么完成以上任务，需要访问组织/角色模型数据。
工作流机也包括调用一些形式的应用工具的能力，来激活必要的应用程序执行相关活动。这种调用机制间有很大的不同，在一些简单的系统中，也许只提供对单一的固定工具调用（例如，文本编辑器），然而在工作流系统中可能提供调用本地与远程的大范围内工具的方法。
d)工作流相关数据和应用数据（Workflow Relevant Data and Application
Data）
过程导航判断或工作流机中的其他控制操作，都以工作流应用程序产生或者更新的数据为基础，这些数据可以被工作流机和条件工作流相关数据（也成为情况数据）所访问；这是工作流机唯一可访问的应用程序数据。尽管，工作流机负责在应用程序间传递工作流应用程序数据，但工作流应用程序数据直接由被调用过程操作。不同的应用程序由工作流过程内的不同活动调用。
e)任务表（Worklists）
过程执行中需要用户交互的地方，工作流机把任务添加到任务表中，以便任务表处理器对其处理，任务表处理器管理与工作流参与者的交互。
这个过程对工作流参与者可能是不可见的，任务表在工作流软件中维护，把用户需要执行的下一个任务提供给他。在其他系统中，任务表可能对用户是可见，用户自己从任务表中选择执行任务，任务表也用来指示任务的完成。
f)任务表处理器用户接口（Worklist Handler & User Interface）
任务表处理器是一个软件组件，管理工作流参与者与工作流执行服务器间的交互。任务表处理器负责请求用户关心的进展中的任务，并负责通过任务表与工作流执行服务器进行交互。在一些系统中，只是使用一个桌面应用程序来提供一个简单的任务进入，等待用户注意。在其他一些系统中，任务表的处理可能更成熟，控制任务在一些用户间进行分配，
并考虑到转载平衡、任务重分配等。另外的一些任务表处理功能，工作
流机典型支持与客户端应用程序大范围的交互，包括工作流参与者的签
到和退出、请求过程实例的开始、任务排队等候特殊的参与者等。在工
作流参考模型中，更广泛的使用“客户端应用程序”这个词，而不是“任
务表处理器”，从而反映其潜在的广大使用范围，其包含任务表处理功能
的同时也包含过程控制功能。
在上图中，用户接口是一个单独的软件组件，负责提示和处理用户对话
框，并控制本地用户的本地接口。在某些系统中，用户接口可能会与任
务表处理器组合到一起，构成一个简单的功能实体。我们希望一些客户
端应用程序能够和几个不同的工作流服务器进行交互，从而把服务器中
的任务整理成统一的格式，通过公共用户接口提供给用户。
可能会调用本地应用程序，来支持用户完成特殊的任务，这由任务表处
理器来负责，或者由用户负责，在用户接口使用简易通用工具来安装适
当的支持程序。在任务表处理器/用户接口中调用应用程序与工作流执行
软件直接调用应用程序，有明显的不同。
g)管理操作（Supervisory Operations）
工作流系统中有许多的管理功能；这些管理功能以工作站点或者用户的
管理权限为基础。这些管理功能使得管理者可以修改任务分配规则、确
定过程中组织角色的参与者、跟踪遗漏的最终期限报警或根据其他事件、跟踪某一过程实例的运行历史、查询任务吞吐量或其他统计信息等。使
用分布式工作流机的地方，可能需要特殊的命令来在不同的工作流机间
传递控制操作或者（局部）响应，从而提供一个单一的管理接口。
h)外部和内部接口（Exposed and Embeded Interfaces）
上述的体系结构适用于大多数工作流产品，但是并不是所有的产品在每
个不同的系统功能组件间，都提供外部接口；一些产品把几个功能组件
作为一个逻辑实体来实现了，并把接口包含在了软件组件的内部，导致
无法被第三方产品使用。WFMC规范定义了每个接口在实现多工作流系统
协同工作中的作用，因此，可以鉴别单独的产品是否符合协同工作标准。
2.2 规则引擎
规则引擎是一种根据规则中包含的指定过滤条件，判断其能否匹配运行时刻的实时条件来执行规则中所规定的动作的引擎。与规则引擎相关的有四个基本概念，为更好地理解规则引擎的工作原理，下面将对这些概念进行逐一介绍。
1)信息元（Information Unit）
信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对象。这些信息包括：消息、产生事件的应用程序标识、事件产生事件、信息元类
型、相关规则集、通用方法、通用属性以及一些系统相关信息等等。
2)信息服务（Information Services）
信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对象。即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有不同的属性和规则集。需要注意的是，在一台机器上可以运行许多不同的信息服务，还可以运行同一信息服务的不同实例。但无论如何，每个信息服务只产生它自己类型相对应的信息元。
3)规则集（Rule Set）
顾名思义，规则集就是许多规则的集合。每条规则包含一个条件过滤器和多个动作。一个条件过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合，其组合结果仍然是一个布尔类型的。在程序运行时，动作将会在条件过滤器值为真的情况下执行。除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作（Discard Action）、包含动作（Include Action）和使信息元对象内容持久化的动作。前两种动作类型的区别将在2.3规则引擎工作机制小节介绍。
4)队列管理器（Queue Manager）
队列管理器用来管理来自不同信息服务的信息元对象的队列。
下面将研究规则引擎的这些相关构件是如何协同工作的。
如图2所示，处理过程分为四个阶段进行：信息服务接受事件并将其转化为信息元，然后这些信息元被传给队列管理器，最后规则引擎接收这些信息元并应用它们自身携带的规则加以执行，直到队列管理器中不再有信息元。
图2 处理过程协作图
3、规则引擎的工作机制
下面专门研究规则引擎的内部处理过程。如图3所示，规则引擎从队列管理器中依次接收信息元，然后依规则的定义顺序检查信息元所带规则集中的规则。如图所示，规则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此规则相关的动作皆被忽略并继续执行下一条规则。如果第二条规则的过滤器值为真，所有与此规则相关的动作皆依定义顺序执行，执行完毕继续下一条规则。该信息元中的所有规则执行完毕后，信息元将被销毁，然后从队列管理器接收下一个信息元。在这个过程中并未考虑两个特殊动作：放弃动作（Discard Action）和包含动作（Include Action）。放弃动作如果被执行，将会跳过其所在信息元中接下来的所有规则，并销毁所在信息元，规则引擎继续接收队列管理器中的下一个信息元。包含动作其实就是动作中包含其它现存规则集的动作。包含动作如果被执行，规则引擎将暂停并进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的地方继续执行。这一过程将递归进行。
图3 规则引擎工作机制
Java规则引擎的工作机制与上述规则引擎机制十分类似，只不过对上述概念进行了重新包装组合。Java规则引擎对提交给引擎的Java数据对象进行检索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。这些实例将在引擎接到执行指令时、依照某种优先序依次执行。一般来讲，Java规则引擎内部由下面几个部分构成：工作内存（Working Memory）即工作区，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放被激活的规则执行实例;静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。Java规则引擎的结构示意图如图4所示。
图4 Java规则引擎工作机制
当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种“动态” 的规则执行链，形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据驱动的。
任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的Charles L. Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。
3、业务流程与规则引擎的融合
作为企业IT基础设施的关键部分，业务流程管理越来越重要了。在BPM产品套件平台上，可以建模、部署、执行和监视企业的业务流程，业务流程可以包含业务规则。例如，在银行的账户验证过程中，评估客户资格或确定价格的业务策略很复杂，而且在快速发展的市场中常常会变动。把这些策略硬编码在过程中是不合适的，因为很难在运行时管理和维护业务规则。通过把业务规则和业务流程分隔开，单独地执行和管理它们，可以提高整个业务流程的敏捷性和扩展性。
ILOG的JRules在融入到IBM的WebSphere套件体系后，在架构层面和技术层面充分体现了这种业务流程与业务规则分离的思想，如下图所示：
ILOG JRules是先进的业务规则管理系统（Business Rule Management System，BRMS），提供编写、部署和管理业务规则等业务功能，支持高效地修改策略和快速部署策略。
ILOG JRules提供一种建模、实现和部署业务规则的系统化方法。它支持以有秩序的高效的方式进行协作。它包含的工具针对不同用户的技能和知识优化过，因此策略经理、业务分析师和开发人员都可以获得所需的支持，可以尽可能发挥BRMS的价值。
4、重要意义
企业管理者对企业级IT系统的开发有着如下的要求：
1.为提高效率，管理流程必须自动化，即使现代商业规则异常复杂；
2.市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更
新；
3.为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序-
而项目开发人员则碰到了以下问题：
4程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型；
5软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中；
6对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。
基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。
规则引擎技术为管理多变的业务逻辑提供了一种解决方案。规则引擎既可以管理应用层的业务逻辑又可以使表示层的页面流程可订制。这就给软件架构师设计大
型信息系统提供了一项新的选择。而Java规则引擎在Java社区制定标准规范以后必将获得更大发展。
业务流程管理方法及步骤： 业务流程管理（process management），是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化方法。可以达到节省时间金钱、改善工作质量、固化企业流程、流程自动化、实现团队合作、优化流程、向知识型转变等的目的。 业务流程的管理按照其变革的程度分三步：业务流程的建立和规范、业务流程优化和业务流程重组。 第一步：确定业务管理需求及目标，如新业务/工作指标/短板问题； 第二步：初步制定新的业务流程及规则。根据业务管理需求及目标，依靠现有的经验及简单的制度，建立新的业务流程规范初稿、关键是明确权责，识别和描述流程，使工作例行化。第三步：试点及优化。 根据建立的流程及规则，进行讨论优化，并实际验证试行，最终评估出可行性及问题，并根据试行评估情况进行进一步改良优化。 第四步：业务流程重组。 业务流程重组，全面推广、实施新的业务流程及规则。 案例 “当日装、慢必赔”工作业务流程及规则制定过程 确定需求及工作目标； 接应流程讨论初稿： 地市试点 试点评估 全省推广。 落地及推进 新的业务规则及流程只有具备可执行性，才能得到有效落地，推进业务流程、规则落地，实现战略落地主要从以下几个方面着手展开。 首先，目标合理有效分解，与各部门业务活动紧密关联是关键第一步。 一是目标应逐层分解到公司各个职能和层次，与公司的各部门生产活动过程有效关联，才能确保团队内责任分工明确，方向一致。 二是应识别影响目标实现的关键成功因素，形成战略地图。 其次，要实现落地，必须发挥业务流程管理的核心枢纽作用，将各项行动措施落实到各部门具体的业务工作中，实施业务流程分级管理，确保各项行动措施职责分工明确，业务实施流程清晰。 加快装接应职责图 但新的业务流程及规则该如何推进呢？实际中根据具体现状，应进行流程分级管理，流程分级管理会有所区别，一般可分为三级(如图所示)，
HR511制度与流程执行奖惩实施条例 1. 总则 1.1目的： 《沿海地产投资（中国）制度与流程执行奖惩治理规定》（以下简称“本规定”），是《沿海地产投资（中国）奖惩治理制度》系列中，为强化制度与流程执行成效，达到提倡良好的企业执行文化，规范运作、禁止错误连续和改正错误的目的，而建立的专项治理规章制度。 1.2 宗旨： 以爱护国家与企业的法律和规定为目标，通过采纳奖惩治理那个鼓舞工具，操纵企业中的非期望行为的发生，引导职员知法，守法。 1.3奖罚原则 (1) 地区采纳从总经理基金列支，及时奖励的原则； (2) 与绩效治理挂钩的奖励原则 (3) 检查期内累计犯错次数，合并处罚的原则。 (4) 视情节的严峻性，在类别与金额范畴内，量情确定处理程度的 原则； (5) 采纳纪律处罚与经济罚款的手段配合使用的原则。
1.4适用范畴： 本规定奖罚适用于沿海地产投资（中国）全体职员和各所属及合作治理的机构，包括美佳物业总公司，但不包含美佳物业总公司治理下的各项目物业治理处（各项目物业治理处按美佳物业总公司相关奖惩制度执行）。 2. 治理职责 2.1.奖惩决定机构 1)总部各部门及负责人、各地区公司及负责人－有权在日常治理 中按照本规定对所管辖内下属部门及个人，按照集团授予的治 理权限，对遵守或违反制度与流程的行为确定奖励与处罚。 2)集团审计治理委员会－有权通过内部审计，对遵守或违反制度 与流程的行为确定奖励与处罚。 3)集团绩效促进委员会－有权通过绩效考评，对遵守或违反制度 与流程的行为，依照集团绩效治理的规定确定奖励与处罚。 2.2. 奖惩建议与执行部门 1)集团职员以及集团各级组织－关于违反集团制度与流程规定 的行为，拥有按本规定提出处罚建议的权力与义务。 2)地区人力资源部－拥有是依据本治理规定，对地区遵守或违反 制度与流程提出奖惩建议，并按集团和地区公司确定的《制度
欢迎阅读 会议制度与流程 一、目的： 1.1规范公司会议的管理，提高会议效率与质量。 1.2检查、掌握公司日常运营、管理工作执行情况，规范公司管理，促进公司各部门的沟通与合作。 3.1.7与会人员必须严格遵守会议时间，应尽量提前两分钟到达开会地点，如有特殊原 因临时不能与会者，应提前通知主持人。 3.2议题准备 会议召开前会议主持人须做好例会的准备，会议前和相关人员拟定会议议题（主题），通知与会人员等，不能毫无准备地召开例会，各岗位人员要围绕议题做好充分准备，要有明确具体方案或意见，避免会议时间过长。
3.3发言要点 3.3.1与会人员汇报工作、讨论问题等，其发言要围绕会议议程和主要议题，简明扼要，条理清楚，发言时间一般控制在3－5分钟。 3.3.2不要总是围绕一个问题不放，这次例会要解决的问题拿住一些有代表性的问题来解决，一些特殊的问题可以会后单独处理，要是觉得有必要可以在以后的时间把解决问题的过程公布，对常规的一些问题的进行针对性的渗透。 3.4会议记录 后 3.5.1与会人员必须认真对待会议主题，积极发表自己的见解，对发表意见的真实性、可行性负责。并且要注意条理清晰，简明扼要。会议发言应言简意赅，紧扣议题。遵循会议主持人对议程控制的要求。 3.5.2与会人员要准时到会，没有特殊情况不得缺席周会，不得迟到、早退，中途不得随意离场。因工作需要主持人不能参加会议，要提前指定主持人；其他有必要参加的人员不能参加的，应当事先请假，并提前将与本次会议有关的报表、材料、计划等以书面形式交主持人。
3.5.3与会者必须严格遵守会议纪律，不得随意走动、交头接耳，周会期间不得接听电话，所有与会人员应将随身携带的手机调至无声或振动状态；如事情紧急可向主持人请假，到会议室外面接听电话。 3.5.4所有与会人员统一着正装，准备好笔和笔记本。 3.5.5例会上讨论的问题属于公司机密，参会人员必须遵守公司的保密制度保守公司机密。会议记录为公司的机要档案，保管人员不得擅自外泄。其调阅应严格按公司文档管理制度和保密制度的有关规定执行。 5.8各员工请在会前准备、组织好会议发言的相关内容，若出现没有准备的情况，给予20元罚款。 5.9违反保密制度的人员将视严重程度给予相应的处分； 5.10以上条款涉及的罚款将作为员工活动经费由公司行政部统一保管。 附表1： 早会流程
ILOG 规则引擎系统运维手册 一、 ILOG 规则引擎系统介绍 ? 为什么使用ILOG 规则引擎系统？ 保险行业是大量业务规则的处理过程，投承保规则、保费计算规则、核保规则、核批规则、费用规则、核赔规则。。。业务规则无所不在，且随着行业监管、市场环境、业务管理等因素不断变化。 业务规则管理混乱、业务规则变更过分依赖技术人员，业务人员无法单独完成业务规则变更，维护成本高昂，由此带来的问题： ? 业务规则变更周期长、成本高 ? 规则重用性差 ? 业务规则知识随着时间被淡忘 基于ILOG 的规则管理，可实现： ? 业务规则与保险应用剥离，业务规则易于管理 ? 使用集中规则库进行管理，业务人员可单独变更业务规则 ? 实现历史规则追溯 ? 规则可重用 ? 缩短新业务发布周期 ? ILOG 在都邦保险的运用 Ilog 规则引擎系统目前维护的规则有车险核保规则和车险费用规则。 自动核保规则是指根据某些核保因子判断当前保单是否能够自动核保通过或者不能够自动核保通过的规则。 其中，不能够自动核保通过的规则，一般又分为数据校验规则、打回出单规则以及自动核保校验规则（转人工核保）等。 人工核保权限规则是指在人工核保环节，不同级别的核保员具有不同的核保权限，配置不同级别的核保员核保权限的规则就是人工核保权限规则。 ? 产品组件 Rule Studio （规则开发环境） 用于对基于规则的应用程序进行编码、调试和部署； Rule Execution Server （规则执行服务器） RES 执行部署的规则应用，业务规则调用的组件，并包括一个web 的管理控制台，业务人员/技术人员编写的业务规则只有部署在规则的执行环境中才能被执行，才能起到作用； 核保规则 自动核保规则 人工核保规则 ——维护各核保级别的权限 打回出单（数据校验或拒保）规则 转人工核保规则 自动核保通过规则
制度制定、修订、发布、执行管理流程 （行政内部） 第一条：总则 为完善行政工作流程，加强行政工作的规范化，保障规章制度的有效实施，提高行政工作效率和效果，特制定本规定。 第二条：规章制度的制定 1、制度的草拟： 行政人事部根据公司经营管理的需要，草拟符合公司管理要求的各项规章制度； 职能部门及分子公司根据自身经营需要订立部门规章或管理制度，可由各职能部门及分子公司自行拟订。 2、行政人事部草拟的各项规章制度，经适用部门或公司主要负责人对制度的实用性、可操作性进行审核，并提出修改建议。 部门及分子公司拟定的各种规章制度，须经综合管理部对制度的合法性、合理性进行审查，并提出修改意见。 审核、审查规章制度必须在五个工作日内结束。 3、行政人事部、其他拟订制度的部门或分子公司应根据修改建议或意见，做好制度的修正工作。 4、经审核、审查的规章制度修正后，由行政人事部牵头，召集相关部门负责人会签制度。 5、制度会签后，由行政人事部公布，各部门及分子公司须落实执行。
6、新制度试行三个月，在执行过程中须检查制度的合理性、实用性、可行性；在确定符合公司需要的情况下，报经执行董事审批。 第三条：规章制度的修订 1、行政人事部定期检查公司已有制度的执行状况，发现规章制度在合法性、实用性等方面影响到公司经营环境时，应主动提出修订。 2、职能部门及分子公司发现部门规章或公司制度影响公司经营时，也可以提出修订。 3、制定修订的内容在合法性的前提下，对修订的制度条款进行列表分析，说明原因。 4、制度修订的过程参照制度制定流程：草拟、审核、修正、会签、审批，原则上，修订制度须在十个工作日内完成。 5、修订后制度，须重新编号，标明版本级次。 第四条：规章制度的发布 1、新订或修订的规章制度，在执行董事审批后，由行政人事部适合的场所进行公布；同时以邮件方式，将规章制度发送给各部门及分子公司负责人。 2、部门及分子公司制定的规章制度，均经行政人事部备案。行政人事部可协助职能部门公布，并组织部门内部实施，或由部门自行实施。 3、行政人事部、其他职能部门及分子公司负责人均对公布的所有规章制度存在宣导或督导义务。 4、公布的新制度或修订的制度，各职能部门及分子公司须于1周内组织本部门（或公司）人员学习。 新进员工入职时由行政人事部组织学习规章制度。
规则引擎研究——Rete算法介绍 一、R ETE概述 Rete算法是一种前向规则快速匹配算法，其匹配速度与规则数目无关。Rete是拉丁文，对应英文是net，也就是网络。Rete算法通过形成一个rete网络进行模式匹配，利用基于规则的系统的两个特征，即时间冗余性（Temporalredundancy）和结构相似性（structuralsimilarity），提高系统模式匹配效率。 二、相关概念 2.1事实（FACT）： 事实：对象之间及对象属性之间的多元关系。为简单起见，事实用一个三元组来表示：（identifier^attributevalue），例如如下事实： w1:(B1^onB2)w6:(B2^colorblue) w2:(B1^onB3)w7:(B3^left-ofB4) w3:(B1^colorred)w8:(B3^ontable) w4:(B2^ontable)w9:(B3^colorred) w5:(B2^left-ofB3) 2.2规则（RULE）: 由条件和结论构成的推理语句，当存在事实满足条件时，相应结论被激活。一条规则的一般形式如下： (name-of-this-production LHS/*oneormoreconditions*/ --> RHS/*oneormoreactions*/ ) 其中LHS为条件部分，RHS为结论部分。 下面为一条规则的例子： (find-stack-of-two-blocks-to-the-left-of-a-red-block (^on) (^left-of) (^colorred) -->
...RHS... ) 2.3模式（PATTEN）： 模式：规则的IF部分，已知事实的泛化形式，未实例化的多元关系。 (^on) (^left-of) (^colorred) 三、模式匹配的一般算法 规则主要由两部分组成：条件和结论，条件部分也称为左端（记为LHS,left-handside），结论部分也称为右端（记为RHS,right-handside）。为分析方便，假设系统中有N条规则，每个规则的条件部分平均有P个模式，工作内存中有M个事实，事实可以理解为需要处理的数据对象。 规则匹配，就是对每一个规则r,判断当前的事实o是否使LHS(r)=True，如果是，就把规则r的实例r(o)加到冲突集当中。所谓规则r的实例就是用数据对象o的值代替规则r的相应参数，即绑定了数据对象o的规则r。 规则匹配的一般算法： 1)从N条规则中取出一条r； 2)从M个事实中取出P个事实的一个组合c； 3)用c测试LHS(r)，如果LHS(r（c）)=True，将RHS(r（c）)加入冲突集中； 4)取出下一个组合c，goto3； 5)取出下一条规则r，goto2； 四、RETE算法 Rete算法的编译结果是规则集对应的Rete网络,如下图。Rete网络是一个事实可以在其中流动的图。Rete网络的节点可以分为四类：根节点（root）、类型节点（typenode）、alpha节点、beta节点。其中，根结点是一个虚拟节点，是构建rete网络的入口。类型节点中存储事实的各种类型，各个事实从对应的类型节点进入rete网络。 4.1建立RETE网络 Rete网络的编译算法如下： 1)创建根； 2)加入规则1(Alpha节点从1开始，Beta节点从2开始)； a.取出模式1，检查模式中的参数类型，如果是新类型，则加入一个类型节点；
为了更好的提高会议质量，达到时间及工作效益的提高，现制定公司每周例会流程。 一、会前准备 1.常务副总提前一天调查各个部门所遇见的问题和困难。（主管副总要把工作过程中的问题及时做好记录，便于常务副总调查工作时能把问题统一汇总。以此避免在会上提问题或打电话浪费领导和大家的时间） 2.主管副总至少提前半天开一次主管部门碰头会议，提出初步解决方案，并确定会议中将要解决的程度和要求。 3．常务副总至少提前半天开一次小型公司（副总）级碰头会议，提出初步解决方案，并确定会议中将要解决的程度和要求。 二、会议传达 会议过程中，必须严格控制时间，在有效的时间内完成更多的决策。 1.主持人，在会议过程中任何人出现偏题、跑题、争执、抬杠或者扩大范围的情况都有权利对发言人进行制止。 2.汇报工作要清楚，针对要点汇报，汇报时间要有限制。（除主持人外，其他人发言限5分钟） 3.会议总结必须精、准、简，将本次会议的情况做出总结。如有
通告批评则应建立在有建设性意见的基础之上，不扩大范围。 三、会议追踪 会议落实重在追踪。 1.行动追踪： 追踪会议决策时谁在做，是何时在做，在哪里做， 2.执行追踪： 是否及时执行，执行到何种程度， 3.完成时间追踪： 是否按规定时间完成。 4、跟踪情况向常务副总汇报和对完成情况进行下周例会点评。 四、例会程序及内容 1、参会人员汇报本周工作总结、下周工作计划。需要公司帮助 解决的问题。 2、公司领导检查工作发现的问题及各部门工作点评。 3、公司领导针对提出的问题要有具体的解决方案及建议。 4、学习公司制度。 5、企业文化及管理人员综合能力提升。（高管宣词） 五、参会人员 1、各门经理、主管副总 六、开会时间(每周一下午一点)
Java规则引擎工作原理及其应用 作者：缴明洋谭庆平出处：计算机与信息技术责任编辑：方舟[ 2006-04-06 08:18 ] Java规则引擎是一种嵌入在Java程序中的组件，它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对 摘要Java规则引擎是一种嵌入在Java程序中的组件，它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程 序中对应的操作。 引言 目前，Java社区推动并发展了一种引人注目的新技术——Java规则引擎（Rule Engine）。利用它就可以在应用系统中分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改，从而为企业保持灵活性和竞争力 提供有效的技术支持。 规则引擎的原理 1、基于规则的专家系统（RBES）简介 Java规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。为了更深入地了解Java规则引擎，下面简要地介绍基于规则的专家系统。RBES包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine。它们的结构如下系统所示： 图1 基于规则的专家系统构成 如图1所示，推理引擎包括三部分：模式匹配器（Pattern Matcher）、议程（Agenda）和执行引擎（Execution Engine）。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。模式
制度与流程执行奖惩实施条例 1. 总则 目的： 《****公司制度与流程执行奖惩管理规定》（以下简称“本规定”），是《***公司奖惩管理制度》系列中，为强化制度与流程执行效果，达到提倡良好的企业执行文化，规范运作、制止错误延续和改正错误的目的，而建立的专项管理规章制度。 宗旨： 以维护国家与企业的法律和规定为目标，通过采用奖惩管理这个激励工具，控制企业中的非期望行为的发生，引导员工知法，守法。 奖罚原则 (1) 地区采用从总经理基金列支，及时奖励的原则； (2) 与绩效管理挂钩的奖励原则 (3) 检查期内累计犯错次数，合并处罚的原则。 (4) 视情节的严重性，在类别与金额范围内，量情确定处理程度的原则； (5) 采用纪律处罚与经济罚款的手段配合使用的原则。 适用范围： 本规定奖罚适用于****公司全体员工和各所属及合作管理的机构，包括美佳物业总公司，但不包含美佳物业总公司管理下的各项目物业管理处（各项目物业管理处按美佳物业总公司相关奖惩制度执行）。
2. 管理职责 .奖惩决定机构 1)总部各部门及负责人、各地区公司及负责人－有权在日常管理中按照本 规定对所管辖内下属部门及个人，按照集团授予的管理权限，对遵守或 违反制度与流程的行为确定奖励与处罚。 2)集团审计管理委员会－有权通过内部审计，对遵守或违反制度与流程的 行为确定奖励与处罚。 3)集团绩效促进委员会－有权通过绩效考评，对遵守或违反制度与流程的 行为，根据集团绩效管理的规定确定奖励与处罚。 . 奖惩建议与执行部门 1)集团员工以及集团各级组织－对于违反集团制度与流程规定的行为，拥 有按本规定提出处罚建议的权力与义务。 2)地区人力资源部－拥有是依据本管理规定，对地区遵守或违反制度与流 程提出奖惩建议，并按集团和地区公司确定的《制度与流程奖惩处理决 定》，执行奖罚或监督相关部门执行的权力与义务； 3)集团人力资本经营部－拥有依据本管理规定，对集团遵守或违反制度与 流程提出奖惩建议，并按集团确定的《制度与流程奖惩处理决定》，执 行总部奖罚或监督相关部门执行的权力与义务； 4)集团知识管理部及地区常务董事－拥有依据本管理规定对遵守或违反制 度与流程实施过程检查、审计、提出奖惩建议并下达《审计处理决定》 的权力与义务；
业务流程再造案例分析1 业务流程再造案例分析 业务流程再造由美国的Michael Hammer 和James Champy 提出，在20世纪90年代达到了全盛的一种管理思想。强调以业务流程为改造对象和中心、以关心客户的需求和满意度为目标、对现有的业务流程进行根本的再思考和彻底的再设计，利用先进的制造技术、信息技术以及现代的管理手段、最大限度地实现技术上的功能集成和管理上的职能集成，以打破传统的职能型组织结构，建立全新的过程型组织结构，从而实现企业经营在成本、质量、服务和速度等方面的戏剧性的改善。近些年我国各大知名企业也纷纷开始自己的业务流程再造。 集团在21世纪初的几次的管理信息化建设过程中，陆续上线了财务管理系统、分销管理系统、库存管理系统，实现了局部的信息化管理。市场的竞争环境和股东的回报要求都迫使企业持续推进管理变革，不断降低企业运营成本、提高运营效率。更深入的、整体的业务流程重组已经是企业不得不做的选择。于是在2004年到2005年开始了相关部门的业务流程重组。事实上业务流程是经过一定程度重组的，信息化程度也很高，得益于此娃哈哈的业务流程的重组变得十分快捷和顺滑，这里以采购方面为例子。 材料的采购业务流程： 1. 采购员向供应商下达订单后，随即传一份定单副本给采购部门；
2. 供应商送来的货物抵达指定的库房时，验货员对货物进行清点，记录，然后将点货清单转给采购部门； 3. 供应商在送进货物的同时将货款发票给采购部门； 4. 对每一批货物的清单和发票核对无误后，采购部门发出货款支票。订单 订单副本货物 发票 点货单 付款旧的业务流程是按专业部门分工设计的，长久以来人们以习惯于按专业职能处理信息，在信息采集、信息共享方面未建立整体的管理规则。企业常常在部门需要某个数据的时候从采购员供应商 验货员采购部门 计算机系统中倒出数据来，重新整理、加工、制表后在进行人工传递，费时费力，效率低下。 材料新的采购业务流程： 1. 采购员通过共享的计算机系统生成采购订单； 2. 供应商将货物送到库房； 3. 验货员根据共享系统中的订单验收货物；
中国XXXXXXXX系统 for J2EE 规则引擎解决方案调研报告 Version 1.0
目录 1.规则引擎4 1.1概述4 2.应用方案的一般实现5 2.1建立规则集7 2.2部署规则集7 2.3规则服务接口－JSR94 7 2.4对规则的计算7 2.5规则的过滤8 2.6使用计算结果8 3.现有的商业解决方案8 3.1ＩＬＯＧ新产品ＩＬＯＧＪＲｕｌｅｓ8 3.2操作人员已经显示提单列表错误!未定义书签。 4.其它解决方案10 4.1提单和报检单完成对碰10 5.评估11
规则引擎解决方案调研报告 1. 规则引擎 规则引擎是解决可变的商业规则的问题的 1.1 概述 规则引擎（Rules Engine）的运作机制是在内存中向对象应用一套规则。首先内存使用来自调用对象的输入，例如用户档案请求会话。这样，在任何规则实际激活之前，在内存中就已经有了一份用户档案的内容。 规则只能在一个上下文环境中执行，上下文环境把规则集和内存关联起来。该环境提供了到Rules Engine的接口，Rules Engine控制着应用程序的规则部分与内存之间的关系。 内存由生产规则（production rules）负责操作，生产规则包含在规则集里。，依照规则的左半边（left-hand sides，LHS）针对内存中的对象进行计算。如果内存中的对象与LHS中描述的模式匹配，就会触发规则的右半边（right-hand side，RHS）指定的操作。此外某些操作可能会在内存中加入新的对象。例如，规则 Classifier 对用户年龄进行测试，如果 USER.age > 45，就在内存中加入一个新的Classification 对象。 生产系统的运行，要执行以下操作： 1.匹配: 估计规则的LHS，判断哪个规则与当前内存中的内容匹配。 2.冲突解决：选择一个LHS匹配的规则。如果没有规则匹配，就停止解释。 3.操作: 执行选中规则RHS中指定的动作。 4.返回第1步。 规则会一直在内存中执行，直到冲突解决集变为0时才停止（也就是没有规则能激活了）。 在Rules Engine停止之后，规则管理器组件会返回一个对象列表，列表中包含内存中仍然存在的对象。一个可能的场景就是，还剩下一个类型为“Classification”或“ContentQuery”的对象。 Rules Manager接着对剩下的对象进行迭代，用可选的对象过滤器过滤它们。过滤器可以有选择地忽略某些对象或者对某些对象进行变换。 1.2 规则引擎分类 值得注意的是，存在不同类型的规则引擎，在决定如何应用一种工具之前理解这种工具的用途是极其重要的。当您跨业务规则领域进行调查研究时，您将注意到这些工具可以分为以下几类： ?简单业务规则（simple business rule）——通过一张简化的、直观的词汇表来表达并且是在应用程序或业务流程的可变性情况下调用的一种业务规则。这种规则引擎的一个很好的例子就是 ilog、Blaze 和 IBM 的 BRBeans。
制度流程执行检查制度 第一章目的 第一条为加强公司制度和流程管理，使各项制度流程切实贯彻执行并不断优化改善，特制定本制度。 第二章适用范围 第二条本制度适用于公司制度和流程执行情况的检查管理工作（不含EHS体系文件）。 第三章职责 第三条各中心负责本中心制度流程的贯彻执行及自查、整改工作。 第四条制度流程检查小组负责对制度的检查、监督、考评、改善追踪等管理工作。 第五条人力资源部负责考评奖惩的兑现工作。 第四章管理内容 第六条公司组织的检查，具体工作由制度流程检查小组负责，检查小组由各中心负责人和部门经理组成。各中心、部的自查，由各中心、部自行组织。检查成员应熟悉各项管理制度和流程，具有较强的原则性。 第七条检查范围：公司和各中心、部已签发各项制度和流程。
第八条检查方式：制度流程检查小组检查与中心、部自查相结合。 第九条检查频次：制度流程检查小组每季度对各中心、部制度和流程执行情况进行检查，具体检查时间以通知为准。各中心的自查由中心负责人组织，每月不少于1次，检查人员由各中心、部自行确定。 第一款季度检查按照“行政线”、“生产线”、“销售线”、“发运线”、“安全线”和“客服线”六条线进行检查，原则上被检查部门人员不参加本部门检查。月度自查根据各中心、部制度汇编文件进行。 第二款检查中查看过程记录文件、资料凭证，对照有关制度要求进行，确定制度是否执行落实；检查业务开展情况，确定是否按照流程办理。 第三款检查通过现场提问或书面测试，检查被查部门人员对相关制度和流程内容了解、熟悉、掌握情况。 第四款在检查过程中，检查人员要实事求是并认真作好检查记录，内容包括参加的人员、时间、检查项目内容、检查结果等。检查完成后，由检查人员填写《制度流程检查记录汇总表》，对不合格项开具《整改通知单》，明确责任部门，整改期限。责任部门接到《整改通知单》后应分析原因，积极整改，在限期内由检查小组或所在单位检查人员复查验证整改效果。
业务流程分析 业务流程分析(Business Process Analysis, BPA) 目录 [隐藏] ? 1 业务流程分析概 述 ? 2 业务流程分析的 内容 ? 3 业务流程分析的 步骤 ? 4 业务流程的调查 ? 5 业务流程分析方 法 [编辑] 业务流程分析概述 业务流程分析是对业务功能分析的进一步细化，从而得到业务流程图即TFD （Transaction Flow Diagram ）,是一个反映企业业务处理过程的“流水帐本”。业务流程分析的目的是：形成合理、科学的业务流程。通过分析现有业务流程的基础上进行业务流程重组（BPR），产生新更为合理的业务流程。
[编辑] 业务流程分析的内容 业务流程分析的内容： （1）原有流程的分析。 （2）业务流程的优化。 （3）确定新的业务流程 （4）新系统的人机界面。 [编辑] 业务流程分析的步骤 根据对组织结构图和业务功能体系图的分析，可决定下一步重点调查的部门，然后对该部门的业务信息、业务流程等进行详细调查。流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系，明确每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流成变化提供依据。 业务流程分析是要将企业具体的业务活动过程（内容、步骤等）描述出来，并对此优化 1.绘制各部门的业务流程图； 2.与各部门业务人员讨论业务流程图是否符合实际情况； 3.分析业务流程中存在的问题（有无不合理流程/环节）； 4.与各部门业务人员讨论，提出改进方案； 5.将新业务流程图提交决策者，以便确定合理的、切合实际的业
业务流程分析方法 企业的效能离不开对企业的业务流程进行分析，企业信息化是企业进行业务流程重组最为重要的手段，从企业的业务流程角度来对企业进行研究是有效而且必须的。无论企业实现信息化还是进行业务流程重组的目标都是一致的，提高企业各条价值链的效能是根本所在。 应该看到业务流程重组的产生是社会化的生产中大工业规模化生产向信息化个性生产所带来的企业管理模式的变革，工业化大规模生产解决了生产效率问题，但其特征是将产业工人固化到流水线上，企业管理链便被层层的管理阶层拉成长长的一条，导致企业行为钝化。 ?企业信息化在业务流程上的贡献价值包括： o建立更高效的决策体系：在企业员工能充分分享信息的情 况下，就能制定出更细腻的业务规则，使决策点降低，反应 速度更快。 o提高企业的执行效率：通过信息系统更快速地下达生产指 令、物流调配指令，以及进行复杂的计划运算，从而达成提 高产能，降低成本的目的。 o业务流程的价值链：信息化系统支持业务流程重组的意义 提升流程链的价值，完成信息化系统之后，流程链可以被延 伸更广的范围，个体行为对企业流程的价值能得到更好的分 析利用。
某油田服务股份有限公司 流程和制度建设及持续改进管理办法 第一章目的及适用范围 1.目的 1.1本程序规定了公司流程和制度建设及持续改进工作必须遵循 的原则、程序,使公司流程和制度建设及持续改进工作规范 化、程序化和制度化,并明确各部门/单位的职责,以提高公司 流程和制度建设及持续改进工作的效率和质量。 2.适用范围 2.1本制度适用于公司和各事业部的流程和制度建设及持续改进 工作。 第二章定义 3.流程——流程是指一个任务从需求提出到任务完成所经过的一个 或一系列行为，包括每个部门在这个过程中所处的节点和承担的任务，以及该节点的输入、输出信息和成果。 4.制度——制度是对流程的描述,是流程规范化、程序化和制度化的 具体表现,包括各部门在流程中所处的节点和承担的职责，以及该节点的输入、输出信息和成果。
第三章原则 5.公司和事业部的流程和制度建设及持续改进工作应遵循全面性、 战略性和及时性等三项原则: 全面性：公司制度建设的规划管理应覆盖公司的各个部门和各个经营领域,以使公司的经营活动有规可循,消除随意性和盲目性； 战略性:公司流程制度的建设应符合公司长远战略发展目标的要求； 及时性:随着公司发展战略目标的调整，公司的制度和流程也应及时进行调整,以满足公司长远战略发展目标的要求。 第四章部门职责和权限 6.战略规划部:战略规划部负责公司流程和制度建设及持续改进工 作的总体规划，并对公司各部门流程和制度建设及持续改进工作进行指导、检查和监督。 7.总部各职能部门：根据战略规划部的流程和制度建设及持续改进 工作的整体规划,负责公司一级流程和制度建设及持续改进工作,并就流程和制度的执行情况进行总结；同时,对于事业部、分公司、办事处的流程和制度建设及持续改进工作进行指导、检查和监督。 负责协助战略规划部制定公司流程和制度建设及持续改进工作的总体规划。
Drools规则动态更新 在常规开发方式中，如果涉及规则的变更(比如将物流费用从6元调整为8元)，可以通过重新完成规则的开发并发布应用来更新。或在设计上，将可能变更的规则以配置(比如数据库)方式管理。发生规则变更时，只需修改配置即可。事实上，Drools提供了另一种规则更新的方式--扫描Maven仓库(本地或远程)来自动发现规则模块的更新。 我们知道，Drools可以利用KieServices来创建基于classpath的KieContainer(即使用KieServices.newKieClasspathContainer()方法)。其实，KieServices还提供了从Maven 仓库加载并创建KieContainer的方法--newKieContainer(ReleaseId)。与通过classpath 创建KieContainer类似，使用Maven仓库加载的方法，会尝试读取对应jar包中的META-INF/kmodule.xml文件，基于此，我们可以完成KieSession的创建。 我们通过一个简单的例子来观察规则的动态更新。在这个例子中，我们会将商品的折扣进行动态调整。我们需要构建规则，并安装到Maven仓库中--简单起见，我们将应用发布到本地Maven仓库中。首先，我们创建一个Maven项目: $mvn-B archetype:generate-DarchetypeGroupId=org.apache.maven.archetypes\ -DgroupId=com.sharp.rules-DartifactId=discount 如果没什么问题，我们可以得到一个名为discount的文件夹，其中的pom.xml看起来像这样:
制造业业务流程及需求分析 本章导读: 本章首先从企业管理历史的发展谈起,介绍了及大规模生产模式相适应的科层制管理的特点以及及现代企业管理的不适应之处;接着介绍了波特的企业价值链的概念,价值链将企业经营活动分为基本活动和辅助两大部分.然后分别介绍了基本活动中的采购、库存、生产、销售管理和辅助活动中的财务管理的基本流程和管理职能；由于成本在企业管理的重要性,特别将成本管理作为独立的章节。通过上述章节的介绍使学生对企业管理有一个初步的了解。 最后从价值链的角度阐明企业管理信息的集成和共享对于管理现代化的重要意义。 学习目的： 通过本章的学习，应该重点掌握以下知识点： 1、了解制造业企业的价值链的内容。 2、了解制造业企业核心的业务流程及职能，对企业管理的过程有一个级别的了解。 3、了解我国企业管理普遍存在的问题。 关键概念： 科层制价值链采购管理库存管理生产管理销售管理成本管理财务管理
第一节中国企业的管理现状 (一）企业管理发展的历史回顾 人类社会经历了从农业经济时代到工业经济时代的发展，而今正进入一个崭新的时代——知识经济时代。企业管理理论和实践是伴随着工业化进程的发展而不断产生、创新和发展的过程。企业管理的目的是打造企业的竞争能力，使企业在不断变化的市场环境中获得最大的经济利益。 18世纪产业革命把人类社会从农业经济时代推入工业经济时代。随着机器和电力的使用,工业生产从手工业作坊向大规模生产方向发展，生产组织和协同关系越来越复杂。工业化初期的特点是短缺经济，产品供不应求。企业管理的重点就是提高生产效率，降低单位产品的劳动成本和设备成本并提高单位时间的产出量，进而实现企业利润最大化。 亚当·斯密首次提出的劳动分工原理，经过分工的工人各自负责产品的一个工序,比每个工人都独自完成全过程生产的效率高几百倍。美国汽车业的先锋亨利·福特（Henry Ford）将劳动分工的概念应用到汽车制造上，并由此设计出世界上第一条汽车生产流水线，大规模生产从此成为人类历史上的现实.福特根据劳动分工原理化解汽车装配工作，把它拆成一系列毫不复杂的任务，使每个工人的工作都非常简单易学。然而,人员协调和工人工作成果的组合过程却因此而变得非常复杂。 劳动分工的理论应用到管理部门的专业人员上，导致了企业管理部门金字塔式的“科层制”组织模式。企业等级结构的形成的根本原因是有效管理幅度的限制，即当组织规模扩大到一定程度，必须通过增加管理层次来保证有效领导.工业革命初期，“科层制”以其动作稳定、持续并可预见的特点，盛行一时。这种注重纵向分工、强调命令控制的高耸式等级体制在今天的企业中都能找到其踪影.科层制组织模式是及大规模生产模式相适应的，在工业化进程中曾经起到积极的作用。 科层制中组织层次过多会引起沟通成本的剧增，并且随着企业规模的扩大，延长了信息沟通的渠道，从而增加信息传递的时间，导致了商机的延误和决策过程的失误. 此外，在科层制管理体制下，由于缺乏有效沟通和共享信息的手段，信息的相对封闭造成沟通不畅，企业经营流程被割裂成一个个相对封闭的职能板块,各子单位往往会精心构思自己的行为，追求局部最优和小团体的利益最大化，使自己的目标凌驾于整个组织的目标之上，形成了多头利益目标的多元化价值取向。这种分散主义和利益分歧，或许能够实现局部利益的提高，但却弱化了整个组织的功效。 到二十世纪中期，短缺经济的状况已经大大改观。为了增强企业在市场中的竞争力，企业注重对内部各个环节的改善。这一时期，许多新的管理理论、实践和方法应运而生。例如全面质量管理TQM、准时生产JIT、并行工程SE等。这些对企业各个业务环节进行改善的方法,如果实施得当，也会明显改善企业的管理绩效。但需要指出的是,这些方法都有是面向企业业务管理的各个单一环节，而不是面向企业的整个业务流程。 图2-1 科层制管理及流程管理的比较 在当前全球经济一体化和信息技术飞速发展的今天，现实社会发生了革命性变化.企业所处的商业环境已经发生了根本性变化。顾客需求瞬息万变、技术创新不断加速、产品生命周期不断缩短、市场竞争日趋激烈，这些构成了影响现代企业生存及发展的三股力量:顾客（Customer）、竞争（Competition）和变化（Change)（简称3C)。为了适应以“顾客、竞争和变化"为特征的外部环境，过去在工业经济时代的商业规则及“科层制"管理模式已经不再适用于今天企业的发展，甚至严重影响到企业的生存. 为了满足快速变化的市场和客户个性化的需求,企业管理在结构和系统理论的影响下，产生了新的思想和方法,例如二十世纪末期美国兴起的业务流程再造，变局部为全方位的重新考量和梳理业务流程，在思考新的市场环境背景和新技术的前提下重新设计企业的业务流程，带来了美国企业的又一次辉煌. 波特教授推出的价值链管理方法，从客户的角度拉动整个经营流程，搭建出价值链的科学构架，从系统的视角观察辅助流程的支撑作用;跨越职能部门的审视采购、生产、物流、销售和服务整个经营流程的运转是
医嘱查对制度与执行流程 一、医嘱查对制度 （1）处理长期医嘱或临时医嘱时要记录处理时间，执行者签全名，若有疑问必须问清楚后方可执行。各班医嘱均由当班护士两名进行查对。 （2）主管护士和夜班护士对当日医嘱要进行查对，每周定期大核对两次，并根据需要进行重整。整理医嘱后需经另一人查对，方可执行。 （3）对有疑问的医嘱必须问清楚后，方可执行。 （4）抢救病员时，医师下达口头医嘱，执行者须复诵一遍，经双方核实无误后，方可执行。用过的空安瓿，须经2人核对后再弃去。抢救结束后６小时内据实补齐医嘱并签字。 （5）整理医嘱、治疗卡、服药卡后，须经2人查对。 （6）护士长每周总查对医嘱2次。 二、医嘱执行流程： （1）医嘱处理护士接医生下达的医嘱后，认真阅读及查对。 （2）查对医嘱无质疑后确认医嘱。 （3）医嘱处理护士按医嘱执行要求的缓急分配给护士执行。 （4）医嘱执行护士接医嘱执行单后，认真查对，严格按照医嘱的内容、时间等要求准确执行，不得擅自更改。 （5）医嘱执行后，应认真观察疗效与不良反应，必要时进行记录并及时与医生反馈。 紧急情况下口头医嘱制度与执行流程 1、在非抢救情况下，护士不执行抢救医嘱及电话通知的医嘱，口头医嘱只有在抢救或手术中可以执行。 2、危重抢救过程中，医生下达口头医嘱后，护士需复诵一遍，得到医生确认后方可执行。 3、在执行口头医嘱给药时，需请下达医嘱者再次核对药物名称，剂量及给药途径，以确保用药安全。 4、抢救结束医生应及时补记所下达的口头医嘱，保留用过的空安瓶，须经两人核对记录后方可弃去。
5、在接获电话医嘱或重要检验结果时，接听护士需对医嘱内容或检验结果进行复述，确认无误后方能记录和执行。 6、对擅自执行口头医嘱行为视为违规，一经发现将给予处理 一、口头医嘱制度 1、一般情况下不执行口头医嘱，口头医嘱仅限于紧急抢救、手术时执行。 2、紧急情况下医生可下达口头医嘱，护士执行时必须复诵一遍，确认无误后执行。 3、给药时，须与医生再次核对药物的名称、计量、用法，确保用药安全。 4、保留用过的空安瓿，以备查对。 5、将口头医嘱内容及时登记在抢救用药记录本上。 6、抢救结束后6小时内，医生根据抢救用药记录补开医嘱。 7、护士在医嘱单上签名。 8、对违反以上规定者，给予处理。 二、口头医嘱执行流程 （1）医生下达口头遗嘱 （2）护士复诵一遍 （3）与医生共同核对药物 （4）实施治疗护理 （5）保留空安瓿 （6）记录口头医嘱内容 （7）医生补开医嘱 （8）护士签名
基于Java的规则引擎
目录 1.简介 (3) 1.1业务规则 (3) 1.2规则引擎产生背景 (3) 2.规则引擎 (4) 2.1业务规则 (4) 2.2规则引擎 (4) 2.3规则引擎的使用方式 (4) 2.4规则引擎架构与推理 (5) 2.5规则引擎的算法 (6) 3.Java规则引擎 (7) 3.1Java规则引擎商业产品 (7) 3.2规则引擎产品特点分析 (8) 3.2.1IBM WebSphere ILOG JRules (8) 3.2.2Redhat JBoss Dools (11) 3.2.3JESS (11) 4.Java规则引擎API（JSR94） (13) 4.1简介 (13) 4.2简介Java规则引擎API体系结构 (13) 3.2.4规则管理API (13) 3.2.5运行时API (14) 4.3Java规则引擎API安全问题 (15) 4.4异常与日志 (15) 4.5JSR94小结 (16) 5规则语言 (17)
1.简介 1.1业务规则 一个业务规则包含一组条件和在此条件下执行的操作．它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言或脚本来定制。 业务规则的理论基础是：设置一个或多个条件，当满足这些条件时会触发一个或多个操作。 1.2规则引擎产生背景 复杂企业级项目的开发以及其中随外部条件不断变化的业务规则（business logic），迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时（即商务时间）可以动态地管理和修改从而提供软件系统的柔性和适应性。规则引擎正是应用于上述动态环境中的一种解决方法。 企业管理者对企业级IT系统的开发有着如下的要求： 1.为提高效率，管理流程必须自动化，即使现代商业规则异常复杂； 2.市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更 新； 3.为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序 开发人员参与。 而项目开发人员则碰到了以下问题： 4程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型； 5软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中； 6对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。 基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。