一体化模型的力量：从"流程金字塔"到"房子"，拒绝业务模型与技术模型分离

业务人员和开发人员的协作，绝不该是一方把定义好的模型硬扔给另一方——真正的成功来自开发者也认真考虑业务流程、业务人员也理解技术因素（比如为什么某个模型必须改动才能变得可执行），这种相互理解本身就是巨大收益；合作的目标是就建模决策达成共识，而不是争论谁对谁错。一个常见的失败模式是妄图让”捕捉业务需求的业务模型”和”可执行的技术模型”两个不同职责的模型共存——大型咨询公司推广的”流程景观PPT”就在助长这种想法，让你一路穿过层层流程直到可执行流程；这类高层战略模型确实有价值，适合印出来给所有人建立对流程起源和目的的整体概念，但它更像电影预告片，会突出某些方面却不真正反映”剧情”，操作层面的实际实现可能完全不同。作者本人曾在2010年出版的BPMN书里画过一个”多级流程模型金字塔”，后来意识到这张图本质是在鼓励”业务把模型扔过栅栏给IT实现”，正是失败的根源，于是把它改成了”房子”的比喻——依然是一体化模型，只是把业务模型进一步区分成人工流程模型和技术流程模型，效果好得多。在操作层面，应该只有一个单一、全面的模型，即使它有不同的物理表现形式（业务分析师在BPMN协作工具里处理、开发人员在Git仓库处理.bpmn文件、运维人员在运维工具里处理部署实例）——这些文件在物理位置上不同，但逻辑上是同一个模型，就像同一份源码部署在不同服务器上一样；关键是内容必须完全共享，没有翻译、没有转换、没有说不清的转手技巧，不同副本的同步就像源码的fork/branch，需要设定同步点合并变更，一般以某一份（如开发者的Git仓库）作为主模型，业务分析师的改动最终合并进去即可，纪律比工具功能本身更重要。