深圳oa软件系统

 与大部分流程顾问的经历不同，我是经过甲方IT项目经理乙方开发项目经理再转行的，因此我对项目成功的标准不是验收，而是咨询成果客户用起来，价值能量化。在这个苛刻的标准下，我对自己做过的每一个流程咨询项目都判定不合格。最终，我领悟到：流程管理=流程+组织+团队的整体规划，客户的团队实际能力是我做咨询的依据，换句话说，如果我想让客户拥有多个业界最佳实践合成成果，我就得假设客户拥有业界顶级的豪华团队。假设不成立，我也不想用欺骗替代假设，于是我放弃了这个职业。当然，在咨询顾问期间，将组织与流程视为解决方案的两面，而不是孤立看待流程，仍是有用的思路。

 写过代码的人都知道对象与接口，但不玩设计模式的，很少会注意到和使用接口（最多只是会调用别人的API接口）。其实程序设计中对象的设计有点像定义组织，接口的设计有点像流程设计（你还可以把类的属性方法看成部门职责，接口看成对外暴露的部门职责）。优秀的软件设计会遵循“高内聚低耦合”，但正如大部分程序员只能把类视为方法集合最终玩成了“低内聚高耦合”，大部分流程管理员也因为缺少组织视角，把流程做成“低内聚高耦合”。 

 绝大部分组织，都遵循自上而下的树型组织架构，组织的职能不断分解，最下面的一级是末级部门，向上则是一个人（两三个人，正副助理啥的也可以）代表的上级部门，层层叠叠，而行使大部分职能的其实还是末级部门。

因此整个组织的职能就被分解成了下图：

整个组织实际行使的职能就是如下这样，可以看到存在大量的职责空白区，所以我们作为一个客户/员工，总能感觉到供应商/公司内部好乱/有点乱/不顺畅。

这就是组织的“断”

 

 感觉不太好是吧？但这是对的，定义组织的目的就是断，将职能进行切割，切割到一个合理的粒度（比如说5~10人的小团队级别协同）可以实现“高内聚”。高内聚在管理上的优势是无障碍的沟通与协同，仅仅通过社交行为，实现人与人的沟通与监督，几乎不需要流程与规章制度就能实现职能。

剩下的问题就是，空白区如何解决？这个则是流程的意义所在，流程穿透空白区，把一个个孤立的职能连起来，这就是流程的“通”。可通有什么意义？

除非你为了避免空白区，可以把每个末端部门的职能搞大，大到彼此重叠（其实很多企业也是部分这样干过，然后更多的问题随之而来），否则无论我们如何定义组织，企业内部职能的空白区都是存在的。定义组织结构图，导致的其实是职能的碎片化，定义流程，则连接了职能碎片，使其成为更大的职能（事半功倍地解决了空白区造成的职能隔断）

那流程有没有减小空白区？从理论上看，如果我们能从端到端（蓝线）定义流程，所有来自外部的客户/合作伙伴/员工/股东/外部环境需求都能得到响应，那空白区是否存在就不再成为一个问题了。这也是端到端流程对企业的意义：与其从内部设计一个没用空白区的管理体系，不如从外部响应入手，设计一个尽可能响应外部需求的管理系统。当然，这是理论上的，所以别太较真啊。

PS：在上面我默认末端部门可以胜任，但我们知道，现实中，图中的黑块的黑白是参差不齐的，这个就是另一个要素：团队（能力）。在不同的环境下，同一个类的运行效率是不一样的，因此你所拥有的部署环境同样应该成为你的类与接口设计的约束条件。这篇就不谈了。

 

再次推荐阅读

《ImprovingPerformance，How to Manage the White Space on the Organization Chart》

中文版名称《流程圣经，让流程自动管理绩效》

建议阅读时不求甚解。