idea's blog

做工作流系统的人, 往往分不清哪些应该是软件做的, 哪些是实际发生的. 首先必须明确的是, 工作流系统必须是一个记录器, 只负责记录发生了哪些事件. 其次, 工作流不是一个工业自动化控制系统, 它不应该去控制机械设备的运行.

从逻辑上说, 流程是动作及其动作之间联系的集合. 动作分为系统动作了业务动作. 记录文字在本子上就是一种系统动作, 审核人登录软件系统点击一个按钮也是一种系统动作. 运送货物是一种业务动作.

工作流系统只关心系统动作, 所以必须将业务中的业务动作转换为系统动作的表示. 如前面举的运送货物的例子, 应该分解为"开始运送"和"结束运送", 这样, 才能在工作流系统中体现. 工作流系统只记录运送什么时候开始, 什么时候结束, 而不是去控制汽车运送货物.

基于工作流系统分析一个业务流程时, 除了分析业务流程本身, 还要分析它在软件系统中会对应多少个页面.

BPM软件可以做得很薄, 也可以做得很厚. 如果做得很薄, BPM软件只是一个流程引擎, 流程引擎只负责生成流程实例和任务实例并执行, 流程引擎只关心任务的执行顺序, 并不关心谁在什么时间执行.

显然, 如此原始的BPM软件(工作流引擎)根本卖不了一分钱. 所以, 软件商在提供BPM软件时, 工作流引擎的外围工具才是卖点. 所以说,

BPM软件 = 流程引擎 + 接口 + 外围工具

流程引擎提供了一种机制, 用于创建, 执行和监控流程. 所以, 创建什么样的流程, 接受什么样的输入以及并执行什么操作和产生什么样的输出, 如何统计要监控的数据, 这些都留给了BPM软件的使用者, 这也是工作难度和工作量的所在. BPM软件提供了一些工具, 可以改善这些工作, 但是, 从实际来看, 只减少了极少的工作难度和工作量. BPM提供的工具的使用门坎, 工具的智能程度和对业务的抽象水平, 共同造成了这种结果.

如果认为工作流引擎或者工作流系统是一个可以被最终用户使用的系统, 那就大错特错了.

流程定义时叫: Workflow, Activity, Context(上下文, 如表单Form)
流程实例时叫: Process, Task

Activity和Task是可嵌套的, 用来实现子流程 - 那么, 是不是也可以把Activity和Process统一起来, 一个Activity就是一个流程, 流程中的所有Activity都是子流程. Activity 有 onBegin() 和 onEnd() 两个方法, 用于主动与外部系统交互, end()方法被外部系统调用, 内部有begin()方法, 总是在前一个Activity end的时候隐式地被调用. onBegin()和onEnd()两个方法可用于实现流程系统对外界系统的自动化控制. begin()和end()方法不会阻塞, 立即返回.

工作流系统(Workflow)和信息管理系统(MIS)的整合的主要目的是, 通过工作流来保证MIS中的数据在业务语义上合法. 这要求, 工作流系统中的活动, 必须导致业务信息的变更.

传统的工作流系统或者工作流引擎, 只是实现了非常简单的转单功能. 业务信息按照既定的信息在不同角色的人员面前展示, 自始至终未发生改变. 这显然没有多大用处, 甚至是说毫无用处, 因为人类的活动, 特别是商业活动, 必然会涉及到业务数据的改变.

信息管理系统中存储着宝贵的业务数据. 有一种说法是, 相对于数据, 数据的存储和处理系统(即软件)是微不足道的. 这种说法有失偏颇, 不能认为数据比流程更重要.

将工作流系统和信息管理系统整合, 可以使信息按照流程所预定的线路增加, 修改, 删除, 查看.