camunda流程定义表无数据_流程的永恒之道 笔记

说pbm必定要说流程。

流程之父迈克尔 哈默的定义：流程是把一个或者多个输入转化为对顾客有价值的出的活动。

李 克拉耶夫斯基和拉里 里茨曼 在《运营管理--流程与价值链》的定义：流程是一种或一组活动，这些活动利用一个或多个输入要素，对其进行转换并使其增值，向顾客提供一种或多种产出。

由上述的定义，可以抽象出几个要素: 输入、活动、转化、输出和价值。所以我们可以这样简单的理解，流程就是按照一定顺序执行的一组活动。

而业务流程就是为顾客产生价值、为企业带来利润的流程。

有了业务流程，还需要弄懂流程技术、bpm等关系，借鉴一张图

引用自《流程的永恒之道》。

简单地说，流程就是企业和组织内被管理和支撑的对象，它承载着企业和组织的运营。流程管理是管理领域的方法论，用这些方法论来管理企业和组织内的流程。而流程技术则是对流程管理方法论的支撑和实现，将流程管理的方法论实现为软件系统、软件工具。

工作流技术的诞生

这是本篇的重点，工作流来自1993年成立的工作流管理联盟WMC所提出的工作流定义：工作流是一类能够完成或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。

实际实施过程中，本人比较认可《流程的永恒之道》这本书的定义：可以支持灵活变化的、可由计算机实现的流程。与WMC的定义区别最大在于灵活二字，因为客户在上线workflow系统有了流程后，往往受困于流程的呆滞不可变。比如一个财务流程，一开始仅是每一个节点有一个审批，后面就有了按金额大小产生并发执行的诉求，而且因为单据涉及的人员众多还会有修改、会签，会签又有多级会签等。简而言之就是，业务是变化的，技术就应该是变化的。

接下来再看下WMC1995发布了1.1.版本的工作流管理系统参考模型。

接口定义如下：

接口1：工作流定义接口，为用户可视化，可以对实际业务进行建模的工具，并生成业务过程的可被计算机处理的形式化描述。

接口2：工作流客户应用接口，它给用户提供一种手段，以处理过程实际运行过程中需要人工干预的任务。

接口3：工作流调用应用接口，指工作流执行服务在过程实例的运行过程中，调用的、用以对应应用数据进行处理的程序。

接口4：工作流引擎协作接口，在大型的分布式的工作流管理系统中，工作流需要多个工作流引擎共同完成，甚至需要其他异构的工作流执行服务来辅助完成，此接口为不同的工作流管理系统之间的协作提供了一种标准。

接口5：管理接口，主要对工作流管理系统中过程实例的状态进行监控与管理。

《流程的永恒之道》也对上述的模型进行了扩展，感觉更贴近业务。

上述模型突出了组织模型数据、流程相关数据、流程控制数据，之所以觉得这个更合适，是因为这大型企业实施的时候，用户提出了这样的诉求--业务数据在原有系统，流程数据在流程引擎。

猛一看到上述的图时候，我差点怀疑是业务方的老师写的书。

组织模型数据就是用户的组织架构数据，流程每个节点都需要分配给不同的人，根据分配的不同，有"受理"、"初审"、"复审"、"会签"等等。

上述图的简化版：

• 工作流控制数据：工作流系统管理的内部控制数据，这些数据包括了与流程实例和活动实例相关的执行数据和状态数据，例如流程实例的状态和执行时间、活动实例的执行者、活动执行时间和状态、紧急程度等。
• 工作流相关数据：工作流系统使用工作流相关数据确定流程实例的流转条件，并选择下一个将执行的活动，这些数据由业务应用系统访问并修改。例如报销流程中的"报销金额"，这个数据会决定该流程的审批路径；再如为活动设置的超时时间，这个数据会触发活动的取消。
  这个数据又细分为a. 连接业务应用系统的关联数据：工作流系统与业务应用系统进行关联的数据，例如特定于Web系统，工作流系统会在每个流程/活动实例里保持导航至对应业务表单的URL。b .传递作用的业务应用数据:当流程跨越多个业务模块或系统时，需要在模块或系统间传递数据，此时会利用工作流系统进行传递，需要在工作流系统里暂时存储或转换这些业务数据。c.影响路由的业务应用数据：同WFMC对工作流相关数据的定义。
• 工作流应用数据：业务应用系统管理的业务数据，有些业务应用数据需要传递给工作流引擎，作为人工UI的列表显示使用。