编辑导语：现在，越来越多的企业正在推出数字化方案，以提高或具备数字化能力，旨在提升业务效率或达到最佳的营收增长。随着数字化转型成功案例的不断涌现，这一潮流趋势正在不断升温。
好久没有更新文章了，最近一直在给一些大型企业做数字化转型的方案，所以公众号又落灰了。恰逢项目间隙，想着沉淀下之前的一些建模的方法和思路，分享给大家。
一、写在正文前
目前我就职于一家tob的数字化服务公司，主要为各类大中型企业服务，提供数字化转型的咨询、诊断、评估、落地实施等一条龙的服务。
在这个过程中接触了很多百亿规模营收的公司，即有之前熟悉的零售连锁行业，也有很多未曾接触过的行业，如医药，保健品，工业等。
在服务的过程中，无论是前期的战略规划还是系统顶层架构设计，对我这种常年生活于互联网公司的人来说，最大的感受不是在于许多传统行业的同学不向往数字化，而是大多数人也说不清楚怎么样叫数字化。
对于大多数人来说，包括一些在互联网公司的人员，对于数字化、信息化、数智化这些层出不穷的概念未必都有很清晰的理解和认知。下图是我对于各类公司在广泛意义上对数字化理解的细分拆解：
数字化阶段拆解
工具化：有些公司还停留在所谓IT时代，大多数对于系统的理解是进行单点的操作工具。
比如单一的财务系统，通过导入excel生成订单记录的订单系统等。
这类公司对于系统的理解更多是excel表的延伸，不具备太多流程化的信息能力。不过此类公司在当前时代已经比较少见了。
信息化：这个阶段的公司属于市面上的主流情况，公司内部通过购买、自研等方式已经完成了线上、线下业务流程的打通和闭环，可以通过一定量的信息化系统完成日常的运营、操作、执行等动作。
信息化的典型特征就是看起来系统貌似各个环节都有。但是各自为政的情况比较多。而且数据底层的连通性较差。
不少公司的管理者往往期望在这个阶段就开始所谓数字化的转型，但实际上还是缺乏很多必要的支撑。
自动化：在这个阶段是容易产生误差最大的阶段。
自动化是建立在信息化的基础上，目的是提高系统间的协同能力，这里包括一体化的中台能力，底层的数据架构。从根本上来说自动化是通过系统的协同完成完整的线上作业流程，从而降本增效。
大多数传统公司会误解的点主要是高层在很多时候会忽略这个阶段，尝试从有系统到智能决策一步过渡，但实际运行过程中我们发现，大多数的信息化能力仅仅是有，而还没有做到自动协同，一体化管理决策的基础搭建。
数智化：这个阶段我理解才是我们常常想象的数字化。
智能化决策、数据中枢等等都是我们梦寐以求的能力，到达这个解决的公司是比较少的，往往会通过加速进程的方式使得部分环节达到初步的能力。
数字化转型过程中之所以有这么多的误解，最大的原因还是认知问题。这也就是为什么这么多网上类似的文章提到数字化转型不仅仅是系统升级，更多是战略、组织的变革。
在调研和沟通的过程中，来自数字化转型企业的人员甚至高管经常会问到类似的一些问题：
目前我们系统都比较健全，但是在对业务支撑上总是不太够用，是出了什么问题？目前我们的需求来自于业务方，业务人员并不知道如何提出相应的问题，更多的需求都是解决操作易用性的问题。多数传统企业还是早年信息化的认知阶段，所以在进行数字化转型时候往往按照以前的ERP设计思路来改造数字化架构，感觉到处都别扭。
在我看来，服务过这么多家各行各业头部客户以后发现，数字化转型主要面临的是对于系统价值的认知及使用模式发生了变化。
很多早年传统的管理者，甚至是IT负责人都不能很好的理解其中的价值和含义，才使得数字化转型变得步履蹒跚。
数字化转型在我看来，对于企业业务的经营改革主要是来自于对于认知的变化，体现的现象就是要求一些非标的能力、行为、准则逐步建立结构化的形式和数据，从而提供数据驱动业务发展、决策的模式。
早期企业对于系统的诉求更多是完成降本增效的诉求，所以更多以工具的形式来辅助业务运营。
随着市场环境的不断变化，我们渐渐开始进入到乌卡时代(VUCA volatile，uncertain，complex，ambiguous ),企业需要面对更多的不确定性，更多的竞争，对于企业经营来说也要求脱离以往粗放型的人为决策管理方式，变为精细化、数据化、标准化的高效管理模式。
在这个前提下，对于数字化对系统的要求也不仅仅是工具，而是需要精准的数据、多维度的决策判断、直达一线的命令传达效率等等。
这些都需要通过数字化及系统、数据的改进过程中不停的对组织、战略认知进行调整，从而逐步达到数字化转型的目的。
而在这个过程中，如何量化线下人为的各种运营动作和行为，能够完成从非标到标准化、结构化的过程就是建模的过程。在我看来，掌握建模方法的平台才能最快最有效的快速完成数字化转型的道路。
二、数字化建模框架
我们知道想完成企业的结构化标准化，就需要从战略、执行、模式等多方面出发，这样看来建模也不仅仅是系统层面的架构设计，更多是要看符合战略、模式的契合度。
企业架构（EA Enterprise Architecture）的框架设计在业内也有很多已经成型的方案，从宏观上来说，企业架构包括业务架构、产品架构（应用架构）、技术架构、数据架构。
企业架构作为宏观的指导框架，可以帮助负责人从公司角度来审视如何指导拆解目前的事务及结构、机制等。目前的主要架构模型也很多，比如TOGAF,ZACHMAN,MEAF等。这里我们重点介绍下前两个。
ZACHMAN作为比较早期的企业架构理论发起者，他的框架是大多数企业框架的雏形。
zachman框架
从结构上来看，他的理论基础是通过5W1H的问问题方式对不同类型的模型进行分析设计。这个方式在现在来看已经是比较普遍的理论方式了。
5W2H（多了一个how much）目前很多时候被运用在调研需求的时候或者产品规划设计的时候，从起源来说都是从zachman的框架延伸出来的。
我们可以认为某个产品或者业务是一个企业，通过这种方式来进行“企业架构”的设计，即我们说的产品业务的规划设计。
模型上zachman框架主要是三类模型：业务模型、产品模型和技术模型。这些模型在后来的绝大多数框架设计中都是主要的组成部分。
而另外一个影响比较大的则是TOGAF框架，相信这个框架很多人都听说过，而我们可以发现现在很多时候产品经理的一些规范、方法论也都来自于此框架的体系。
TOGAF框架
上图可以看到TOGAF的框架跟现在我们日常的需求管理流程是很相似的，只是从颗粒度看日常的需求更小一些。
两者都是通过对业务能力的了解（调研）进行架构设计，并根据设计的框架逐步进行内容的开发。
所以我们可以看到企业架构设计的元素和原理与日常我们在进行产品需求规划设计是很相似的，这也就是为什么常说产品经理理论上是一个公司的ceo，他负责的部分从认知上来说应该站在企业公司或者产品顶层的角度来思考问题。
从上面的一些经典企业架构来看我们会发现，在管理企业架构的时候整体下来主要是对四个部分进行架构设计和建模的操作，即业务架构、产品架构（应用架构）、技术架构、数据架构。作为一般企业核心的四套架构设计，其中包含了很多需要掌握的建模模型、梳理方法论等。
我基于在互联网大厂（曾在京东、阿里多家一线履职过）的中台经验，结合我近年来为各大不同行业的头部企业的数字化转型咨询、评估的情况。我梳理了一下数字化转型需要进行的一系列建模及设计的顶层框架。
数字化建模蓝图
这个框架是基于多行业的实操落地经验总结的，在不同的框架中运用了多种模型，包括对流程分解的，prd梳理的、业务架构建模的，产品建模的等等。其中技术模型考虑到相对更底层，且和业务价值的关联相对较弱，这里不进行展开和解读。蓝图中有一些模型是来自于一些成熟的方法论，比如PCF，DDD，有一些则是根据我的实际经验结合方法论提炼出来的建模方法。希望对于大家有借鉴参考的作用。考虑到文章篇幅过长，本章中涉及方法、建模的详细过程不在本文累述，后续我会单独写一些系列文章来讲解本文里面哪些模型的详细拆解过程。接下来我们来看下这个建模蓝图中都有哪些会运用到的模型及方法。
三、数字化建模详解
上面我们说到了数字化架构有4种架构，除了偏底层的技术架构以外，其他的几种都是反映企业业务运营特征的核心架构，而不同架构下也有不同的模型表现形式：
1. 业务架构模型
负责表达业务运营机制模式的模型，主要解答业务的机制，规则等。常见的业务模型主要包括业务流程图、业务SOP规范，业务决策规则清单等等。
形式上不限于线上，线下的excel等各种格式也是比较常见的。
价值流梳理
海外仓业务管理模型
2. 产品架构模型
通过业务架构的模型进行系统层面的解读。包括产品分层模型等。
产品建模的过程其实就是日常产品经理的常见工作内容，包括流程图、ER图，产品规划蓝图，产品roadmap等等，甚至PRD里面的逻辑描述其实也是基于一定规律的建模模型获得的（很多资深产品经理脑海中已经形成一定的经验，所以不需要特意去建模获取）
建模在产品经理的日常过程中是特别常用的工作方式，也是方法论沉淀的方式，甚至即使是前端的产品经理，在设计页面的时候也需要运用到一些信息架构设计的模型或者方法。
某平台采购下单流程模型
3. 数据模型
基于业务的梳理和建模，构建数据层面的模型包括物理模型，数据实体，数据血缘，数据流向等等
订单模型
整体架构的建模是从业务模型开始，业务模型代表着公司的业务机制及模式，业务建模产生相应的业务元素，如业务流程，业务角色，业务动机等。这些元素是其他模型等必备要素。
业务模型分解的元素和规则可以用来进行数据建模，数据建模根据业务诉求搭建相应的数据结构和模型，从而满足业务的记录、观测、分析的各类数据诉求。
而数据模型也是产品建模的重要组成部分，产品建模时候也需要参考数据模型来进行相应的产品设计及划分。
产品建模则是我们真正意义上完成业务价值流在数字化上的体现。好的产品建模可以最大程度的还原业务的真实作业场景，盈利方式，合理规则，有效监控等等一系列的能力。从而帮助业务更上一个台阶。
模型之间关联
产品建模根据业务战略、执行、落地等多个维度，也会分解成若干层，不同维度的产品建模代表着不同的含义和价值实现。
总之，所有的模型建模的目标都是为了最大程度的提供还原度高、标准化、结构化的业务模式解读，并可以通过在线的能力有效的解决线下的各种问题。
在不同的架构中，建模的方法及建模后的产物都有着很强的联动性，在日常的产品、业务工作过程中，很多东西我们都是无意识的在使用，而忽略了他们之间的关系。
比如我们画的产品流程图是基于业务流程图来进行制定的。产品的逻辑是根据业务执行的逻辑进行转译的。这些其实都属于建模层面的产物。
接下来我们简单看下各部分架构内都有哪些模型及规范的。
我们日常用到的一些设计的流程大多数是源自于TOGAF的企业架构，在TOGAF的企业架构中有一种架构的开发方法，简称ADM(Architecture Development Method,ADM)。
ADM是从企业架构的角度给出了对于架构设计的设计思路和路径。而路径上可以看到业务架构的设计和愿景是产品架构（信息架构设计）的前提，所以我们可以理解为ADM在日常工作中就是我们产品需求设计的一个流程框架。
我们可以看到流程上都要进行业务规划（架构愿景）、业务调研、分析（业务架构）、产品规划设计（信息系统架构）、技术方案设计（技术架构），复杂项目还会有多条线的整体产品方案（解决方案）等。
下图是ADM的各个环节的关系图
在实操场景下，现在绝大多数公司的产品需求设计流程都是和ADM的架构设计流程是相似的，原因在我看来产品需求设计更多是对于业务诉求及规范的理解和转义（让语言上更解决系统语言的表述方式）。所以在设计业务架构的时候都是相通的。
ADM是从宏观角度划分不同环节的关系及路径，那么另一种企业架构CBM（component business model组件化业务模型）设计思路则是更加细化到更细的领域进行。
CBM引入了领域和职能的概念，进一步将价值单元进行划分，不同领域在不同职能上都有特定的价值组件（BC），而每个价值组件既可以是业务的也可以是系统的。
当然在数字化的认知下，原则上业务组件都可以通过量化完成系统化的构建。
这种分层分域的逻辑产品经理是不是看着十分的熟悉？
没错，大多数的产品架构蓝图也是基于这个理念进行划分设计的。后面我们会细说下关于产品建模时候蓝图如何聚合领域。
前面我们说了，业务架构、产品架构、数据架构是息息相关的，而架构建模的源头来自于对于业务架构的设计。
4. 业务架构
业务架构目前市面上主流的设计框架是价值流+流程的组合，即通过识别企业业务价值流，构建实现价值流的流程从而完成整个业务架构的设计。
在实际落地过程中我发现一个问题，价值流是属于顶层设计，而流程更多是聚焦到所有分支场景的执行操作，中间还需要有一个桥梁来连接，也就是说同样场景或性质的流程应该形成统一规范，即业务的SOP。基于上面的设计框架，最合适的业务架构建模框架包含的元素有
1.价值流（价值主张、价值流、价值流阶段）;
2.业务SOP（规则集合、流程合集的价值主张）;
3.业务流程（即包括所有业务场景的执行流程及逻辑规则）。
原则上业务SOP的模型形式和价值流和业务流程的的模型类似相通的地方，大多通过流程图的方式来展现。
5. 业务价值流
比如上图就是一个供应链企业的生产、交易价值流梳理，而下面提炼的阶段就是价值流阶段包含生产价值流阶段和交易的价值流阶段。
价值流中间的每个细节节点如加车、下单等又构成了一个SOP的规则、流程集合。里面包含很多不同的处理子流程。
很多时候大家在梳理业务价值流的时候会和系统的流程混淆。一般情况有以下几点区别：
业务价值流重点描述场景、角色的交互，系统只是其中的一小部分，而系统流程的交互主要是线上系统交互为主。业务流程的节点需要表达业务价值的阶段或者成果，如履约完成、审核开票等。而系统流程中间有不少是系统的底层处理，比如数据的转换之类的。
业务架构的建模框架如下：
业务架构建模框架
我们上文有提到业务架构建模核心是价值流和流程的梳理和拆解。其中价值流分为识别和价值流阶段梳理。
什么叫价值流呢？
企业存在的核心在于为客户提供价值，即其价值主张。业务的价值流是为了实现其价值主张而进行的方式。
业务价值流解读是产品建模、拆解的前置依赖条件，无论是平台级规划还是单独条线的规划都是如此。
举个例子，腾讯的核心产品是微信和QQ，那么他的价值主张是什么呢，价值流又是什么呢？
腾讯的核心能力是社交类软件，那么它的价值主张就是社交吗？并不是。我们知道，腾讯有很多其他产业，比如投资京东、美团等，它投资不同领域的产业目的是将连接属性做到最大化。
因此腾讯的价值主张是“连接”，因为无论是人与人之间的连接，还是人与行业之间的连接，都需要围绕连接开展。
而腾讯的价值流基本以连接后的导流，引入为主，通过连接提供更大的客户群体。
阿里的价值主张则相反，它通过买断自运营的方式实现进场（比如饿了么、高德等），再通过制定平台规则和平台统筹实现统一管理，实现各种服务、商品、信息的流通。
因此阿里的价值主张是“撮合”，撮合的本质是降低商业摩擦成本，并通过各种规则和能力使得商业成交转化率得到大幅提升。
阿里的业务价值流主要以平台间商品价值的互换和组合销售为主的交易流，提供更高更多的客单。
综上可以看出，价值主张为公司确定了很多隐性的东西。如果我们没有深入理解这个概念，就容易设计出一些跑偏的架构。
价值流的识别和制定也是来自于一些内外部的输入，包括战略输入、动机输入、商业模式输入。
数字化转型需要制定一系列的战略决策，不单单是进行系统的改造升级，战略决策及业务动机会直接导致数字化的倾向性。
比如战略上希望打造供应链一体化平台，那么业务动机和商业模式则会聚焦在提高供应链产能、周转，扩大分销渠道等能力上，商业模式也以大宗批发为主，零售为辅助。
这样的输入下，价值流的核心会聚焦在后端及B2B的模式上做延伸，类似S2B2C等等。
而如果战略上希望打造的是全渠道营销平台，那么供应链就会弱化，更多是完成渠道和用户的转化能力。
关于战略、动机、商业模式的输入可以通过构建战略屋的方式来得到公司层面或者事业部层面的战略构建。
业务价值流依存于输入的差异和变化，价值流则绝对后续的业务架构建模。
业务价值流是一个端到端的流程合集，为客户、利益相关者或最终用户创造整体结果。即为某个或某群特定的利益相关方提供完成企业或平台价值主张的流程或标准。他是由若干个价值流阶段构成，即我们常说的关键环节
下图是一个标准的电商价值流的示例：
价值主张：交易平台，为客户提供交易及履约服务；价值流：交易价值流（或叫价值链）；价值流阶段：共五部分（加购物车、下单、支付、分拣打包、配送）。
价值流的识别和价值阶段的拆解有助于我们快速找到业务的核心逻辑及目标价值。方便对后续的更细维度的流程、功能、业务逻辑进行拆解。
识别价值流以后就需要进一步对业务价值流或者价值流节点拆解、细化。形成可以落地执行的内容，如流程、规则、策略等。
这时候要PCF（ Process Classification Framework流程分类框架）,PCF不是一个业务上的模型，更像是对于业务流程梳理的时候一个通用的规范。
他可以让业务人员在梳理业务流程和SOP的过程中按照一定的规范快速梳理出自己业务的相应流程和规则。
PCF共计有13个分类的流程框架，5个级别流程拆解层级。
13个分类流程框架
PCF将13个分类流程框架分为两大类：日常运营类的和管理支持类的。而这13个分类在日常我们的工作中最常用到的是运营流程类的相关框架。
PCF的最大作用是通过框架一定程度上穷举了不同层级对于业务流程的概述。你可以通过PCF的内容快速了解到当前需要梳理的业务流程都有哪些种类，他们的大体关系是什么样的。
按照PCF的划分，整个流程被分成了5级：
1. 类别：可以理解为是表达当前领域下对于价值流和价值主张的流程。
2. 流程组：是解答上一级流程划分的集合，我们也可以理解为是价值流阶段，代表是不同节点的组合。
3. 流程：这个层级的流程也是以流程集合形式体现的，差别在于这个层级更聚焦在具体的成功转化上，这个层级的”流程”会消耗到资源，所以需要从业务的实际工作维度来进行设计，可以理解为是我们常见的业务SOP。
比如售后分类中，售后维修可能是流程组的概念，那么维修评估、维修报价等等就是我们说的“流程”，他需要开始对资源进行消耗。
而维修评估不单单是一个独立的业务流程，还可以进行进一步的拆解，即下层级的活动。
4. 活动：这个层级的流程则是我们通常意义上表达的业务流程，主要是进行生产、操作流程的。
5. 任务：任务属于在更细维度的事务拆解，一般情况下这个颗粒度分解的内容可以理解为处理业务的原子因素。在DDD领域设计里面的事件、命令其实就是对应这个维度的。
需要说明下，有时候业务场景没有那么复杂，事件和命令的原子因素也可以对应上级的内容。
5个层级样例
比如上面这张图就汽车是企业风险合规整治的一个流程框架概述，通过逐级拆解可以找到业务场景下需要梳理的流程清单，方便我们在做业务架构设计的时候快速穷举查找。
PCF不会涉及到具体的业务元素，但在判断是否完善业务场景和流程的时候，可以作为参考的架构来看，此外PCF还有很多不同行业的细分框架，对于具体业务理解更有助于判断。下面这个就是汽车生成行业的客服管理流程分类框架。
汽车PCF流程分类框架样例
说了这么多流程分类的方法论，也许对于很多产品出身的同学来说感觉不是那么好理解，那么我通过系统的相关模型给大家解读下如何来看待业务架构设计中PCF对于产品架构设计和日常需求的作用。
PCF的五层分类前两层可以便于我们去快速找到对应领域业务的关键价值流和价值流阶段的内容。而后面的三层可以指导我们去识别业务SOP、业务流程梳理的完整度。
前期业务建模的架构越完整，对于识别出来的流程、角色、事件、命令就会越准确，后面去进行系统领域的划分设计就会更加容易匹配，输出价值。
我们以订单中台系统中的一个部分拆单模块为例来看下，假设我们认为拆单模块的流程是一个完整的流程分类，那么他的链路就是我们说的价值流，里面的节点是价值流阶段，再往下拆分的就是子流程，即流程、活动、任务。
子流程都是需要消耗资源的，即需要调用相关系统计算、更新数据等。
拆单流程分类框架示例
业务流程拆解后，为了后续可以进行系统的架构和建模，可以在已经完成的业务流程中做一些“标签”的识别，我们可以通过流程节点识别出来事件、命令、角色。这个概念是来自于DDD领域设计中的事件风暴。
在实际的建模和落地实施过程中我发现，事件、命令就是最小的业务单元，而能够讲业务流程拆解到最小业务单元，在进行后续的产品架构设计，甚至产品具体功能的PRD编写时都有很大的便利和指导性。
以一个审批流程为例，我们可以看到，事件、命令作用于每一个节点上，通过拆解可以找到最小单元的变化数据和最小单元的操作动作。从而进一步结构了业务在运行之中的核心“原理”。
事件、命令拆解示例
对于产品建模来说，业务架构建模是非常重要的过程，很多企业没有能做好这块，或者说对于业务设计更多来自于脑海中的概念和口述，缺乏更多的细节。
这样就导致产品规划、设计时候很多产品经理经常会抱怨业务没有想清楚，方案感觉都是拍脑袋的原因。
另一方面，业务的经验更多来自于运营过程中的不断收集，内容更多是碎片化的积累，如果希望做数字化转型，业务架构建模的体系能力是很重要的。
业务建模后很多元素是产品建模的基础，比如流程、规划、目标等。下面这个图来自于建模蓝图中的一部分，表明了业务建模和产品建模的转换关系。
业务建模与产品建模的关系
说完业务模型，我们来看下产品模型，产品建模解决的是设计的框架及对待问题的处理方案准则。很多的信息和数据都是来自于业务建模的转化，产品建模需要通过对业务的理解和抽象形成系统层面的模型来指导产品系统的搭建。
按照从宏观到细节，我将产品模型分成了三层。
顶层建模：针对业务价值流和阶段进行拆解，找到核心的业务价值，转义业务架构建模形成的信息。领域建模：基于DDD的方法论针对产品领域进行聚合，形成不同产品领域的模型。包括一二级域。通过产品能力矩阵识别领域缺失，逐步完善领域建模。产品功能点建模：指的是基于上面模型的原子要素（事件、命令、角色等）和流程、逻辑进行具体需求的整理，也就是我们整理prd的过程。通过模型可以及时发现需求梳理的问题，进行完善。
产品建模：顶层模型、领域模型
产品功能点建模
产品的的分层建模目的是通过不同维度的建模可以将对应层级的业务架构进行转化，比如价值流的梳理转化的产品层面就是顶层架构建模，可以通过价值流和价值流阶段的识别，快速确认在数字化中核心的产品链路是哪些，核心产品链路要赋予更高层次的数字化能力的规划。
举个简单的例子，一个供应链企业和一个营销型企业虽然同样都需要交易、营销、供应链的能力，但是数字化产品架构设计时，由于业务架构上的价值流和流程的级别不同，所以产生了差异化产品架构设计的情况。
供应链企业对于库存、商品、物流方向的智能化、自动化能力就需要有一些深度规划，而营销型企业则需要加强用户运营，营销的玩法。
供应链企业产品架构示意图
营销型企业产品架构示意图
顶层产品架构设计会影响到在领域建模时对于根据产品能力矩阵进行领域能力完善时的侧重和取舍。
产品建模的顶层建模不仅仅只是照抄业务架构建模的价值流内容，而是需要判断出业务的属性特征，从而得到产品可以赋能的核心价值点。
除了进行分层转化以外，产品架构设计最重要的是提炼出两个东西：
系统流程，系统流程代表着业务线上还原的场景，还原度越高越能够体现业务架构设计的准确性。而且系统流程直接决定了交互的逻辑、关系，所以系统流程的梳理是很重要的一项产品建模；事件、命令、角色，通过事件风暴获得的事件、命令、角色是基于业务建模的，在进行产品建模的时候需要根据系统场景和流程补充很多系统层面的事件、命令、角色。
比如订单的下单就需要增加一些线上的审核校验事件或命令，促销发券就需要有一些促销计算的过程等等。
在产品建模中，事件、命令这些元素是业务的最小单元，也是系统执行的最小单元，我们可以理解为它就想PCF分类框架中的最后层级的流程分类：任务。
所以包括领域建模、功能点建模都需要通过事件、命令进行归因识别，确保业务、产品从上到下的逻辑是统一的。
在产品分层建模中，我使用的核心思路是基于DDD领域设计的思路，包含了各类领域设计的元素：聚合根、事件、命令、限界上下文等。
下图是我总结的关于DDD领域设计中各个元素间的关系：
数据建模
市面上讲述数据架构的详细文章很多，也说的比较清楚，关于基础的概念这里我不单独累述了，考虑到数据结构还是比较方法化，很多东西和概念对于之前接触不多的人来说容易绕晕，本文重点用一些通俗的表达让大家来理解下这块的内容。
业务和产品建模的关系类似于人类起源之时人类生产活动和工具的关系。业务建模代表人们的基本运营规则和方法，而产品建模则是通过更多系统化的能力提供快速提升的手段。
而数据建模则像是语言一样，负责传达和表达人们真实的想法和沉淀积累。所有业务、产品的行为都会以数据的形式记录下来以便进行更多的分析、判断。
所以数据建模既来源于业务、产品建模，又对它们有导向的作用。
在进行数据模型的抽象之前，很多基础的信息都是来自于对于实体的理解和拆分。所以ER实体建模是进行数据架构的前提条件。
业务实体与数据架构的关系
数据实体识别完成后，我们就需要根据需要将数据分层、拆解、得到相应更独立的数据结构，这就是数据建模的过程。
举个例子，我们现在有一个订单的实体建模，那么根据订单的使用场景、信息、类型等维度对数据就有不同的诉求和分析角度。
我们可以根据场景拆分成交易场景、财务场景、售后（订单快照）等等，不同场景下的数据需要完成哪些分析，从而聚合形成相应的数据结构。
上面的描述方式类似口语，在实际建模过程中则会根据模型的特点分为逻辑模型、概念模型和物理模型。
简单来说概念模型就是表达实体的关系，可以用“实体-关系”（E-R）图来呈现，它的实现代表了自然语言的转化。
逻辑模型则是技术侧在进行理解的时候用技术的语言解读实体关系的内容，这个过程和业务建模转化成产品建模由异曲同工的过程。
物理模型则是逻辑模型的落地，是对于真实数据库表的描述，包含了表、视图、字段、数据类型等等要素。可以理解为是具体的表结构。
需要说明的是这里面的表结构可能会因为场景、业务属性、用途等进行聚合或者拆分，理解上不是我们常规见到的业务系统里面的数据库结构，比如订单的数据可能就有多维度数据聚合的宽表来进行财务、业务上的分析使用。
除了模型外，关于数据的源头、流向、血缘关系也是数据架构建模的时候需要重点关注的，这些相当于我们在做业务、产品建模时候管理相应生命周期的闭环是一个道理。只有能够最大程度记录和体现业务、产品生命周期下的情况及特征，才是数据建模最大的价值。
四、数字化建模工具
说完了建模的方法，那么通过什么方式或者手段来建模呢？构建的模型都有哪些常用的形式呢？
首先，模型是包含很多种形式的，主要的作用是通过抽象的方式固化下来相对核心主要的模式、规则、流程等。所以模型等表现形式是多种多样的。
我们日常画的流程图就是建模的一种形式，业务梳理的规则列表，产品整理的数据字段，开发的接口规范，业务运营的流程，sop。这些都是模型的范畴。
我们这里面的模型是广义上的模型，而不仅仅是常规印象中的算法模型那些。
类似下述的这些图都属于模型的范畴，包括但不限于价值流、流程、规范、框架、规划等。
交互模型
业务流程
架构图
其次，建模的规范和标准是需要统一化的，在产品中大家见到的最多的模型语言就是UML，UML可以基于各种链路流程进行制图，表达他们之间的流转和关系。
此外还有对于业务建模常用到的BPMN规范。接下来我们重点介绍这两种语言。
1. UML
关于UML的基本概念相信在很多的书籍或者文章上大家都有阅读过，这里面我就不再啰嗦了。重点我讲下我对于UML的理解以及在架构、模型设计时候的一些底层逻辑。方便大家理解对于UML的合理使用。
UML在产品经理或业务运营人员日常的画图中经常会用到，它有一些基本元素和类型，我总结了一下，大概有以下几类：
1）实体元素：包括各类实际行为或者载体的表达，开始结束的表达以及对于判断的表达等。这些实体元素在各类图中用于对业务载体、产品系统载体、逻辑载体进行描述。
需要注意的是，这里面提到的实体载体是指对业务或系统上某个规则或模型的载体，他可能是一系列的流程、sop、策略或具体角色、任务等。
流程建模示例
上图中的矩形和判断的菱形元素都是在表达实体的内容，包括判断逻辑和业务动作行为。
2）连接关系：连接关系用于表达实体元素间的互动逻辑，不同类型的连接关系形成不同类型的图，如并列关系。
下列是我们日常常见UML的模型图分类及样例：
UML图样例
2. BPMN
除此以外还有一种规范其实也是我们经常见到的，就BPMN（Business Process Modeling Notation 指业务流程建模与标注）。
BPMN可以理解为是UML的升级版本，在BPMN中，包含的基础元素有：
流对象（Flow Object）用来操作数据的流向的对象，所有流转含义的内容都可以通过流对象表达，包括事件、网关、活动等。数据（Data）：数据对象是一个显示活动是如何需要或产生数据的。它们通过关联与活动连接起来。链接对象（Connecting Objects）：连接对象将流对象连接起来形成一个业务流程的基本结构。泳道（Swimlanes）：通过泳道对主要的建模元素进行分组。描述对象：我们可以理解为扩展信息等内容主要进行注释，辅助描述等。包括组和注释两种概念。
在日常工作中，这两种语言其实没有太多本质性的差异，很多产品经理画的流程图或者泳道图都是混合了两种语法的产物。
大多数的流程大家会基于UML的格式来进行，但是从我个人的经验来看BPMN在进行业务建模复原的时候更容易表达业务的上的一些场景、触发机制等。所以可以使用一些BPMN语法的概念来进行特殊节点的描述。
比如UML开始节点并没有表明太多元素或者触发的动机，而在BPMN中规定流程的初始需要通过某类事件或者场景的触发，即设定相应的流对象。这个概念有助于建模时对场景的描述更加具体完善，避免缺失和遗漏。
此外，对于我们常规建模的图形来说，大体可以粗略的归为两类：结构静态图和行为图。
结构静态图一般是用UML的格式来画，代表一些今天结构的图，比如产品架构图、组织结构图等。这些一般不代表行为或动作。
另一种就是行为图，比如我们经常画的流程图，系统交互图，时序图等都是这个范畴，代表一系列行为的动作流转。在这种图里面可以加入一些BPMN的元素用来丰富表达的含义。
尤其是在进行业务行为描述的时候对于特殊的场景、触发逻辑等可以通过BPMN的元素进行表达，方便进行事件、命令抽象的时候更加完善。
五、总结
数字化转型是一个痛苦的过程，但又是一个必经的过程。如何能够通过数治代替人治是数字化的核心改革。
建模是决定能否变成可量化、可衡量、可延展的商业体系的标准之一。一个数字化转型成功的企业都需要具备良好的合理的建模基础。通过模型可以有效的防止、预估、判断各类不可控情况的发生和蔓延。
本文重点讲解了各种模型、方法之间的关系及内部的结构逻辑，考虑篇幅没有特别深入的展开。后续我会对每部分单独写文讲解其中的方法及实操内容。
#专栏作家#
高晖，微信号公众号@产品老高，人人都是产品经理专栏作家。10余年IT经验，互联网老兵。多年电商公司经历，曾参与过B2B/B2C/O2O等多个方向的电商项目，熟悉电商全流程产品线情况。
本文原创发布于人人都是产品经理。
题图来自 Unsplash，基于CC0协议
本文来自网络或网友投稿，如有侵犯您的权益，请发邮件至：mikytey@163.com 我们将第一时间删除。
