流程引擎中的Virtual OC理念

先注明这是一篇随笔性文章，以致接下来可能有的错误都是情有可缘的。（板砖接连而来）

接触了不少专业领域的流程引擎提供商的产品，几乎所有的厂家都有自带的OC（Organization Chart）模块。这让不少最终用户很欣喜，理由实在是很简单，国内很多企业的HR系统维护不完善，此中原因是多方面的。

那么一个不完善的系统为何会影响到流程的设计呢？我们举个例子简单的阐述一下，了解这个原因的朋友可以跳过此节。我们都知道，公司里的每个员工都应该有个对应的职务，例如信息部门经理，市场总监等，在流程中的某个环节需要信息部门经理来审批，而HR或AD中该字段的信息没有进行正确的维护，导致流程不知道该找谁来审批，从而出现问题。如果强行将信息部门经理张飞的名字拉入进该节点进行审批操作，那一理张飞离职，该流程就是断档。

上面只是一个简单场景的描述，还有一些客观原因造成现有的HR系统或AD信息不能参与流程设计本身。例如，公司里可能有正式的职务信息，但同时也有多个附加的职务信息，例如，关羽是销售Office产品的销售部门经理，同时他也是多个产品组合销售部门的经理，例如：Office和Sharepoint等产品的组合包。后者的名称会随着产品功能的变化而变化的，因此在HR系统或正式名片上只有其正式职务，即销售部门经理。但很明显，这两职务的权限是不一样的，因此在流程审批时就是困难了。

那些提供了OC模块的流程引擎厂家到了这一点，并将其产品能提供这一功能而作为较大的卖点。但这个OC将来的维护责任在谁？IT？还是HR？相信任何一个IT部门经理不愿意答案是前者。有些流程引擎产品的OC设计比较弱，并不能完全考虑到企业的复杂情况，但这一功能是基于产品包提供的，不会有灵活的变更，需要Partner进行扩展开发，这下麻烦了，且不去看厂家是否愿意公司OC的细节，光是定制开发扩展OC这一块就是个不小的工作量，况且有些问题并不是技术在解决，而应该是政策。

有幸看到一个专业的国际流程引擎产品，其本身非常专注于流程的设计及监控本身，OC这一块是空白。经过对该产品的大量研究发现，其必须要符合中国特色才行，所以，他也应该具有OC模块，很兴奋，他的底层数据都是开放的，而且有很强的编程操作方法。

结合上述的OC的责任问题，我在该流程引擎产品的OC设计上提出一个新的概念：Virtual OC　。同样，引申出来的概念：Virtual Role。我们可以理解这个OC不是正式，官方的，但流程里又是必不可少的，设计时考虑到流程审批者的定位问题（即如何找到这个人），以及复杂的OC问题，Virtual Role解决了复杂的职务，角色问题。这些Virtual Role可能不同的部门有不同的理解，因此是细化到部门的Virtual OC。

还有一点要注意，名称本身有个小小的陷井：Virtual OC，Virtual Role，顾名思义，一切都是虚拟的，维护工作由各部门自己负责，责任不在IT，而在于提出这些Virtual Role名称的部门本身。