随需应变的管理软件(4)

在构建抽象过程中，发现事务流程的关键控制点在这两方面：

      事务状态的完成人

      事务状态的状态变化阀值

我将第一个关键点称之为U变量，第二个称之为V变量。

每一个状态都会由这两个变量集合来组成与决定。

 

引用软件设计中的流程图，来表示现实事务流程是可以接受的。事务的执行过程中并不会考虑到复用，也不会有继承。这样会使得事务的成本开销比较高。并且，这些东西应该是由人脑来学习和判断的。所以我们可以用流程图与状态变化图来表示事务的流转。

 

要设计一个通用的事务流引擎，比较关键的是能够包纳各种各样的事务类型。要做到事务流引擎是一个容器，可以通过公用接口来插入具体的事务对象。

如何实现这一点呢？我们可以通过U集与V集的公用接口来完成。至于流程的具体流转，可以用网的二叉树实现来表示。毕竟现实工作中，事务流程的复杂度要小于网。因为现实的事务是由人来执行的，基本上所有的复杂流程都可以分解成一个个状态的变化图。

 

U集合：可以表示当前状态的前后状态的集合。也可以表示当前状态操作点的集合。我们可以将同一状态的多个操作点分别看成并行的多个状态。也可以用很简单的语句来进行操作：

     当A状态的所有操作者都OK时，可以继续

     当A状态的某位操作者OK时，可以继续

     当A状态的其中多少位操作者OK时，可以继续

     当A状态的某位操作者反对时，需要回退...

我们在构建引擎时，需要抽象掉所操作的对象。假设我们的流程什么样的数据都可以操作。只关心流程本身。

 

V集合：理论上，流程自动化流转时，应该是不需要人来操作的（例如不需要人来按一个确定提交按钮什么的）。但现实生活中的工作内容往往很难做到量化到如此的程度。所以V接口在我的事务引擎设计中只是一个构想。并不会实际去实现它。

 

这样我的事务流引擎的工作第一步是设计一个公有的U集合模型。

如果只实际对于流程状态变化的一个管理，似乎里头缺少了事务流中一个很重要的管理对象：操作者。其实事务流管理的核心是人来管理人，而不是机器来管理人。

为什么这么说？因为在我们使用事务流程工具时，需要人来评估与设计事务流程。需要在工作中不断修改，与统计事务流程的效率。这与工作考核是同一概念。

所以我们的事务流程是一个管理工具，而不是一种管理思想。我们需要设计这样一种工具，来帮助用户达到这样的目的：

      完成事务的整个电子流转过程

      记录事务的流转成本

而后面一点就决定了考核只需要针对完成时间，而不需要针对事务的具体内容。

 

至于这些的详细解释，会在以后一一说明。