审批与工作流的不同

审批更多体现在上下级，管与被管之间，更多体现的权力意志。

而工作流，则不一定。工作流，更强调跨部门、跨专业的作业流程交互。

----------------------------------

所以，审批权，程序如何能自动落到一个员工身上，是一个课题。

困难在于，如何使系统上线后，能随着时间的变化，员工的来来走走，系统能够自适应。

自适应包括自我适应，和错误自我感知，和错误自我修复的过程。

第一种自适应，是说，当有审批权的用户，离职，或调离，或是其它变因发生变化时，新建的流程，能够，自动指向新任审批者。

错误的自我感知，可以由事先设定的一系列规则，在每天下班后，系统，进行全面扫描。找出那些正在进行中的流程，卡住的情况。

这是很关键的一环，一个办法是，把这个程序与离职流程和调动流程相绑定，主动进行检查。

自我修复，可以根据一定的规则，自动将由于人员的变动，走不下去的流程向前推进，比如，自动指向新的审批者。

-----------------------------------------

所以，这里最重要的要点，还是如何找到审批者。

由于现实的系统，不是都能满足象军队那种层级结构，有的员工，长期工作于多个部门之间。

所以，一个简单的办法，可以学习一下以太网，

一个子网中，只有一个网关可以对外，这基实是一个好点子。

默认网关，事实上，对于同组的员工来说，他并无更高权限，看起来和他们是一样的，但他可以把不是本网络的报文发向下一个节点。

但困难在于，我们每块网卡上，都有指向，而IT系统中，我们无法为每个用户的每个流程，进行指向。

当然，可以学习类似DHCP那种全局的官控机制，这是一种方式。但还是比较复杂。

简单的办法，可以指定同一组的某个员工，有审批角色。

审批页面提交的时候，系统自动扫描其所在的组，找到哪些人有审批权。

为了消除，不允许多个人有审批权的可能性，在指定某人有审批权时，事前进行有效性检查，是否有人已被指定有此权力。

进一步来说，审批权到底是什么？

可以借鉴微软的CRM，在微软的CRM中，并无审批权这个权力存在，只有一个对当前模块读和写的“范围”：

包括：

对自己的的数据的读与写；

对与同级团队的数据的读与写；这个写，就是审批权。

有时还有对上一级团队的读与写；

以及对所有级的团队的读与写；

其实这的确是一个好的思路。在微软的CRM中，这种情况进一步简化——读与写的范围，只与角色绑定，而与人和团队无关。