04
元模型和流程是方法论两个方面
我们通常所说的IT，其实包含两部分内容，Information 和 Technology。I是信息、数据，长期以来大家都是把它跟数据库和数据结构划等号，直到近年大数据的崛起和数据治理（Data Governance） 的重视，关于数据资产、数据要素以及数据安全等方面逐步引发关注。T是技术，是加工数据、处理业务逻辑、串接业务流程的技术工具，也是原来颇受大家关注的开发语言对应的部分。
信息和对信息的处理也恰是IT最重要的两个方面，在这对关系中，信息（I）是载体，承载 了业务对象的属性描述与当前状态，信息本身并不会流动，就像事务的状态本身并不会发生变化，它的变化是由外界事件触发和驱动的，所以信息本身是静态的，是稳定的，也是本质的。
技术（T）则是流动的，它编写了业务规则和处理逻辑，驱动（或由用户驱动）业务对象从一种状态流转到另一种状态，或是使业务对象产生或消亡；它代表了业务的流动。
IT是现实世界的数字孪生，是为了解决现实世界的问题而诞生的模拟空间；正如IT空间中的Information 和 Technology的关系一样，现实世界也是由静态的“对象”和动态的“流程”构成。
看一个现实中的例子，如何得到一张宜家的桌子？
我们从宜家买回来的往往都是半成品，拆开箱子会看到一堆原件和说明书，说明书上会先介绍都有哪些原件，然后告诉你详细的安装步骤，按照安装步骤去组装原件，就可以得到一张宜家桌子。
原件以及最后组装完毕的桌子都是业务对象，一步一步引导我们组装的过程就是业务流程。这个过程和IT的两方面是何其一致？因为IT的本质是对现实的模拟。宜家把我们获得家具的过程进行了简化，延伸去设想一下，我们进行其他复杂的工作，是否也是由这基本的两方面构成？
这基本的两方面，从方法论的视角进行总结，就是元模型和工作步骤。
元模型定义了我们看待问题的角度和方式，这种方式可能是客观的（举例：色相、明度、纯度）也可能是主观的（举例：目标、任务、需求），在我们认为的视角下才有了相关概念，以及概念之间的关系。
概念给了我们描述问题的视角，一直到视角发生改变前，概念本身是不需要变化的。所以概念是我们看待问题的静态方面，我们只需要用这几个概念方面去描述问题即可，不需要多，也不会少。
但是概念之间是有关系的，有前后关系，上下关系，总分关系，归纳或演绎关系等，所以当我们将概念分散在问题空间时，可以从空间观去看待这些概念。
但仅有概念是不能完成工作的，就像原件是不会自动变成桌子的，把原件“变成”桌子需要一定的工作步骤和工具，这就是方法论中的“流程”的部分。
流程驱动了作业向前推进，促使概念发生改变和转化，一直到最后问题的解决。所以流程是方法论中的动态的部分，具有工艺的先后顺序，需要按照一定的步骤和逻辑去完成，代表了我们看待问题的时间观。
空间和时间、静态和动态、概念和流程，是相辅相成的，仅有概念没有流程，世界就是僵死的，仅有流程没有概念，世界是无状态、不可描述的。流动以生发，静观以成相。
继续使用前文战略分解的案例，元模型包括我们提到的业务目标、业务能力、目标任务和高阶业务需求的业务主体概念，工作步骤是我们每一步做什么，怎么做，有哪些输入，哪些输出，使用什么工具和技术？
以定义目标任务举例，输入是企业总体战略、同业领先实践、业务与科技发展趋势、政策与监管要求等，输出是目标任务清单，使用的工具包括战略解读、调研与访谈等，具体的步骤包括：
理解战略内涵，分析业务战略核心价值
分析同业领先实践和科技发展趋势
总结归纳形成业务目标定义
一个疑问，“定义目标任务”本身就一个工作步骤，为什么还会对工作步骤分解？这涉及到流程颗粒度的问题，对于工作步骤我们分解到什么颗粒度才是合适的？为什么不先安装桌面然后安装桌腿？为什么客户履历也属于客户对象，而客户关系不属于客户对象？为什么得到的是这几个活动而不是别的活动？
还有很多如此这般灵魂拷问，这些疑问可能来自客户也可能来自其它成员，问到最后你会发现这些问题跟“为什么这个叫苹果而不叫香蕉”是同一个性质。
关于为什么（why）的问题，不能用元模型和工作步骤来回答，元模型回答了如何描述问题（what），工作步骤回答了如何解决问题（how），而回答“为什么（why）”要靠原则。
原则的意义在意定义了事前的形式准则和事后的验收标准。当工作过程中度量难以把握时就是原则起作用的时机，如果发现一个问题即不能抉择，又无相关原则可以参考，那说明需要增补你的原则库，直到所有的（大部分）工作的分歧可以用原则来解决。
原则大多数时候是最佳实践，比如设计的原则“高内聚、低耦合”，数据库的原则“分而治之”，业务组件的原则“不重合无遗漏（MECE）”“价值链”；但有时候也只是为了统一思路，比如“一条高级需求只能对应到一个活动，而一个活动可以实现多个高阶需求”。总而言之是为了“达成共识”服务。
To be continued……
