回顾我这些年的工作历程，有过3次重要的转折。第一次是从做流程转身做业务架构，背后的动因是想借助业务架构推导出“正确的”流程架构；第二次是从公司内部的流程专家转身去做面向客户的咨询顾问，背后的动因是发现只有业务架构是“落不了地”的，必须跟其他3个A（IA、AA和TA）一起才能发挥EA的价值，而当时在企业内部找不到合适的机会，就希望能在面向客户的咨询项目上进行实践和探索；第三次是从咨询顾问转身去做专业的EA产品和解决方案，背后的动因也很简单，就是发现用PPT和Excel做企业架构都是“纸上谈兵”，必须要用专业方法和工具做专业的事。每一次的转身都不是预先“规划”的，而是遇到了在当时的认知水平上解决不了的问题，于是就不断地“追问”，不断去寻找新的思路。这篇文章就是跟大家分享我在这个过程中的一些思考，希望给同样在这条路上探索的伙伴们一些参考和启发。

追问1：流程架构与业务架构有啥区别？

背景

这个问题提出的背景大概是在2015-2017年。在此之前，当时我所在的H公司一直是基于2007年前后设计的一版流程架构在进行流程建设。到2015年前后，大规模的流程建设已经基本完成。与此同时，H公司的业务范围跟2007年时也发生了显著变化，从单一的运营商业务发展到运营商、政企、消费者三大业务单元。原有的流程架构能否满足业务发展的需要，流程架构应该如何设计、如何优化，成了当时的我所在的流程管理部门必须回答的问题。

难点

依托H公司强大的平台，我们做了很多行业领先知识方法的研究，例如BPM、Business Model、Business Operating Model，最后锁定了业务架构，认为是业务架构决定了流程架构，可以通过业务架构设计来牵引流程架构的优化。当我们真正沿着这个思路往下走的时候，却发现很难区分清楚业务架构和流程架构。毕竟这么多年以来，流程架构在H公司早已经深入人心，各业务领域在设计业务架构的时候，总是感觉业务架构跟流程架构“长得差不多”。如果只是把原来的流程架构换个名字叫业务架构，有什么意义呢？

思考

业务架构包括了业务能力、价值流、信息概念、组织、功能、流程、角色、施动者等等十几个要素（参考TOGAF®元模型）。很明显，流程是业务架构中的一个元素，但流程架构不是。

流程架构是对流程进行分类的框架，也就是流程分类框架（PCF，Process Classification Framework）。例如：“开票流程”是一个流程，它可以被归到销售流程域，也可以被归到财务流程域，归到哪一类对于如何开票这个流程本身几乎没有影响，区别在于哪一个流程域对开票业务负有管理责任。

企业中的流程成百上千，不做归类是无法管理的。因此，流程架构（准确地说，应该叫流程分类框架）的作用就是划分业务部门对流程的管理责任，也就是明确哪个流程归谁管！而流程的管理责任必须跟企业的治理结构相适应，这就是常说的“组织与流程适配”。H公司的L1流程域里有一类叫Operating流程，例如IPD、LTC、MTL、ITR，都是Operating流程。在做咨询顾问的时候，我发现有些客户沿用了这一模式设计本企业的流程架构，却落不了地，甚至难以找到合适的业务领导来做流程Owner。究其原因，H公司是典型的“强矩阵”组织，职能线和项目线并存，职能线管资源，预算和权利则向项目线倾斜。例如：IPD背后是以PDT团队为代表的一整套项目型组织，LTC背后是以CC3为代表的销售和交付项目团队。没有这些项目型组织，这些端到端流程是运行不起来的。

结论

流程架构是对流程的分类框架，分类的目的是为了落实管理责任，因此流程架构必须跟企业的治理架构相匹配。强调职能线运作的组织，流程架构也应该以职能流程为主要分类维度；强调项目型运作的组织，流程架构则可以将跨职能的端到端流程作为主要分类维度。一句话：怎样有利于落实流程的管理责任，流程架构就应该怎样设计！切忌单纯追求流程架构的“先进性”，而忽略了组织与流程架构的匹配度。

追问2：如何实现可编排、可重用？

背景

这个问题提出的背景大概是在2016年前后。当时以“业务线上化、管理标准化”为特征的信息化建设已基本完成，业务的差异化需求显著增加。表现在流程建设工作上，当时我们做了大量的“流程适配”工作，就是把全球标准流程放在全球各个地区部、代表处，结合当地的业务特点进行裁剪或修改。流程的适配相对“容易”，除了自有人力成本外不需要花费太多的成本。但是流程适配给IT带来了巨大的工作量，原来IT都是依托标准化的业务流程开发一套系统，全球适用；现在要面向每个代表处设计“个性化”的IT系统，这就推动了IT系统从原来的单体式架构向“组件化、服务化、可重用”的模式转型。

难点

如何才能识别出“可重用”的组件？不是那种“增、删、改、查”意义上的重用，而是真正业务意义上的重用，这就成了当时作为业务架构师的我要思考的问题。

我们做了一些尝试。例如，在LTC流程中有各种各样的评审业务，标书评审、合同评审、订单评审……，既然都是评审，何不把“评审”作为一个组件，每个流程到了评审环节就来调用评审组件，评审组件提供评审服务，业务流程就可以这样编排了。然而，流程的编排毕竟还是纸面上的，真正到了IT侧问题就全暴露出来了。虽然都是评审，但标书评的是技术方案，合同重点评商务条款，订单评单价、折扣和交货期，每个评审的过程、规则都不一样……想要能设计一个能被重用的评审功能，似乎还差的很远。

思考

在上面这个例子里，真正被重用的不是“评审”这个动作，而是“任务”这个对象。无论评审标书还是合同，本质上都是发起了一个评审的任务，把任务分配给不同的评审人，在任务上记录开始和结束事件、记录评审意见，然后触发下一个任务，最终得出评审结论，任务结束。这个思维的转变是从“过程抽象”到“本质抽象”的转变。

过去画流程，我们习惯于做过程抽象，就是按照时间维度描述业务，所有的流程图都是按时间顺序展开的，关注谁先干什么、谁后干什么、他们之间的输入输出关系是什么；而本质抽象要求我们换个视角，去识别业务中关键的人、事、物。所有的业务行为都是围绕这些对象展开的，这就是所谓的“业务对象”，或者叫“概念数据对象”。

这种思维模式的转变对业务人员是个巨大的挑战！以前大家画流程，可能认为流程中的输入输出表单就是业务对象，例如招聘流程中的面试申请表、入职登记表，培训流程中的培训签到表，等等。但这些表单并不是真正的人、事、物，只是这些人、事、物的某些属性的集合。真正的人、事、物是这些表单背后的员工、技能、岗位、组织单元、培训课程、会议、地点…… 从表单到业务对象，靠的人对业务的抽象。它们就好像业务中的化学元素，看似千变万化的业务，归根到底都是由这些稳定的“对象”构成的。找到了“对象”，再去分析业务围绕“对象”有哪些功能，这样设计出来的组件才有可能被“重用”！

结论

可重用的组件必须是“对象+行为”的封装，对象是从现实业务中抽象出来的关键的人、事、物。抽象的范围越广，可重用的空间就越大。但重用的目的决不是要“一统天下”，把现有系统中的功能都替代掉、只能用公共的组件，这是对“可重用”的巨大误解。“可重用”的目的恰恰是为了快速满足业务的差异化需求。可重用组件提供基本的共性功能，差异化的前台应用在此基础上拓展个性化功能，从而快速满足业务的差异化需求。

追问3：有或没有企业架构，数字化建设有何不同？

背景

这个问题提出的背景大概是在2019年前后。在此之前，大约2015-16年，H公司就已经把企业架构方法纳入变革规划流程，要求每年基于企业架构方法开展变革规划，而且规划出来的变革项目，其论证立项、高阶方案也必须基于企业架构方法论开展设计，过程一般是采用“PPT方案+专家评审”的模式。

难点

虽然公司发布了完整的架构原则、架构评审Checklist，但实际情况是每个项目都从本项目的角度设计4A架构。这就好像在一栋使用中的楼房顶上加盖游泳池，如果没有一套准确描述楼房现状的架构作为参考，专家也很难判断游泳池的方案哪些合理、哪些不行。换句话说，仅依赖专家的经验判断是很难从架构角度给项目提出有价值的建议的。

在这种机制下，项目前期做了大量4A架构方面的沟通、汇报，但到了详细设计阶段都要落到具体的应用功能和数据上，前面的4A架构跟后面的IT设计与实现中间存在断档，于是很多人开始质疑：企业架构到底有什么用？没有企业架构不是也一样做变革项目吗？企业架构师除了能画PPT之外还能做什么？所谓的架构治理，如何才能发挥价值？

思考

TOGAF说企业架构的价值在于牵引有效变革。有或没有企业架构，这种“牵引”作用至少体现在以下两个方面：

l 一是变革规划阶段。随着企业数字化投资规模越来越大，如何确保数字化投资总是对准业务战略，这是负责数字化规划的部门必须回答的问题。去年花了2000万，今年要花3000万，这些投资到底往哪投、要解决什么问题、达到什么效果。没有企业架构的时候，要么是上面的领导拍，要么是各个业务部门上报，但汇总上来的需求哪些先做、哪些后做，最终还是得靠人拍。有了企业架构之后，在决定要做哪些项目之前，就要先把业务战略放在企业架构上做全局的影响分析、识别能力差距，分析差距、设计工作包、进行关联关系分析和优先级排序，最后才能形成项目和项目群。换句话说，企业架构有助于开展自上而下的全局规划，聚焦那些支撑业务战略达成的关键举措，合理分配数字化投资。

l 二是变革项目立项论证和高阶方案设计阶段。企业架构从多视角、全要素构建企业的数字化模型，以便为战略的落地、资源的配置提供决策依据。没有企业架构的时候，每个项目各讲各的“故事”，有了企业架构之后，所有项目都要在这一套架构基础上讲“故事”。架构治理就体现在分析这些项目的方案对企业的架构现状做出了哪些变化，这些变化是否合理、是否能满足战略的要求、是否符合企业统一的架构规范。因此，企业架构对项目的牵引更多体现在战略目标和架构规范性方面，只要满足这些要求，项目的业务方案和具体IT系统如何设计、实现，则并非企业架构师关注的重点。

结论

有或没有企业架构，区别在于企业的数字化治理能力上。企业的数字化规划和建设是人为判断的、随机的、直觉式的管理行为，还是经过科学方法分析和论证的、工程化的、有意识的管理行为。不能仅仅用降低多少成本、提高多少效率来衡量它的价值。这种管理能力的价值体现在，它能够用结构化的方式呈现战略、业务与各类数字化资源（如数据、应用、技术等）间的追溯关系，在面对企业战略和业务的快速变化时，企业架构师能基于这种追溯关系快速识别变化带来的影响，并提供最合理的解决方案。这才是企业架构师的主战场！

用专业的工具做专业的事

没有人想要做“PPT架构师”！但合格的架构师必须完成“从文档到模型”这一关键转变。文档是非结构化的，且自然语言天然存在模糊性，不能作为企业架构设计和分析的载体，必须从“基于文档”转为“基于模型”，用模型语言进行准确描述和逻辑分析。

传统的建模工具是面向工程师的设计工具，虽然提供了丰富的模型语言支持建模，但无法承载更大范围的架构治理。

数孪模型科技的EMAGE是新一代的EA平台，它将建模作为底层功能，在模型基础上构建了丰富的业务与IT管理场景，能够支撑企业的数字化决策层、管理层，以及各类业务管理人员、IT管理人员，基于EMAGE进行数字化规划、项目群管理、流程和合规管理等。