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

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

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

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

微软的新搜索引擎, 网址 www.bing.com, 中文版 cn.bing.com, 中文名"必应", 已经开始带来流量了, 今天只有一个.

"bing", 总让人联想到中文的"病", 估计, 它的角色和 live 搜索一样, 只是微软不愿放弃的一个产品, 并不期望带来多少直接盈利.

BPM软件调研

作者: ideawu

http://www.ideawu.net

2009年5月25日

本文调研了两套BPM软件, 商业化的Oracle BPM软件套件, 和开源的JBoss JBPM框架.

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

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

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

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

所以说, “工作流自动化不仅涉及到流程建模，还需要建立电子化表单，及定制各种报表。所以对于工作流系统，如果只有流程建模工具，没有表单设计器及报表设计器，或是这方面的功能不够强大，就需要编写程序来完成表单及报表的功能。这就意味着必须依赖供应商来完成流程系统的实施，或是在公司内有专业的IT人员来完成这些工作。”

Continue reading »

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中的数据在业务语义上合法. 这要求, 工作流系统中的活动, 必须导致业务信息的变更.

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

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

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

公司的一个邮件处理程序出现问题, 费了很大劲, 才发现, 原来是微软的Exchange Server擅自篡改客户的邮件, 将text/html内容改为text/plain和text/html.

看了微软的文档, 竟然毫不知耻地声称, 其这样做是为了改正用户的邮件错误格式! - http://technet.microsoft.com/en-us/library/bb232174.aspx

见过不要脸的, 但没见过Exchange Server这么不要脸的! 擅自篡改客户的邮件还有理了?! 如果邮局的人拆开寄信人的邮件, 把认为字迹潦草的信件重新抄写一遍, 再发出去, 你认为这合理合法吗, 即使它闭着眼睛抄? 况且RFC规定MTA不可以修改邮件内容.

国外有个Mikhail发贴问, 能不能禁止Exchange Server这么做? 有一个微软的MVP说ES这样做没问题啊. 然后Mikhail指出, RFC规定, 传输者(MTA)不应该修改邮件的内容. MS-MVP先生狡辩, 没有正面回答是否能禁止. 最后, Mikhail只能开始证明微软的Exchange Server就是一件垃圾(piece of junk), MVP先生你还别不承认(Please, refrain from denying the obvious and from blaming me for pointing it out. ).

- http://www.eggheadcafe.com/conversation.aspx?messageid=30509248&threadid=30509248