企业数字化模拟图,嘉兴数字化建模开发

01

写在正文前

目前我就职于一家tob的数字化服务公司，主要为各类大中型企业服务，提供数字化转型的咨询、诊断、评估、落地实施等一条龙的服务。在这个过程中接触了很多百亿规模营收的公司，即有之前熟悉的零售连锁行业，也有很多未曾接触过的行业，如医药，保健品，工业等。

在服务的过程中，无论是前期的战略规划还是系统顶层架构设计，对我这种常年生活于互联网公司的人来说，最大的感受不是在于许多传统行业的同学不向往数字化，而是大多数人也说不清楚怎么样叫数字化。

对于大多数人来说，包括一些在互联网公司的人员，对于数字化、信息化、数智化这些层出不穷的概念未必都有很清晰的理解和认知。

下图是我对于各类公司在广泛意义上对数字化理解的细分拆解：

数字化阶段拆解

工具化：有些公司还停留在所谓IT时代，大多数对于系统的理解是进行单点的操作工具。

比如单一的财务系统，通过导入excel生成订单记录的订单系统等。

这类公司对于系统的理解更多是excel表的延伸，不具备太多流程化的信息能力。不过此类公司在当前时代已经比较少见了。

信息化：这个阶段的公司属于市面上的主流情况，公司内部通过购买、自研等方式已经完成了线上、线下业务流程的打通和闭环，可以通过一定量的信息化系统完成日常的运营、操作、执行等动作。

信息化的典型特征就是看起来系统貌似各个环节都有。但是各自为政的情况比较多。而且数据底层的连通性较差。

不少公司的管理者往往期望在这个阶段就开始所谓数字化的转型，但实际上还是缺乏很多必要的支撑。

自动化：在这个阶段是容易产生误差最大的阶段。

自动化是建立在信息化的基础上，目的是提高系统间的协同能力，这里包括一体化的中台能力，底层的数据架构。从根本上来说自动化是通过系统的协同完成完整的线上作业流程，从而降本增效。

大多数传统公司会误解的点主要是高层在很多时候会忽略这个阶段，尝试从有系统到智能决策一步过渡，但实际运行过程中我们发现，大多数的信息化能力仅仅是有，而还没有做到自动协同，一体化管理决策的基础搭建。

数智化：这个阶段我理解才是我们常常想象的数字化。

智能化决策、数据中枢等等都是我们梦寐以求的能力，到达这个解决的公司是比较少的，往往会通过加速进程的方式使得部分环节达到初步的能力。

数字化转型过程中之所以有这么多的误解，最大的原因还是认知问题。这也就是为什么这么多网上类似的文章提到数字化转型不仅仅是系统升级，更多是战略、组织的变革。

在调研和沟通的过程中，来自数字化转型企业的人员甚至高管经常会问到类似的一些问题：

目前我们系统都比较健全，但是在对业务支撑上总是不太够用，是出了什么问题？目前我们的需求来自于业务方，业务人员并不知道如何提出相应的问题，更多的需求都是解决操作易用性的问题。多数传统企业还是早年信息化的认知阶段，所以在进行数字化转型时候往往按照以前的ERP设计思路来改造数字化架构，感觉到处都别扭。

在我看来，服务过这么多家各行各业头部客户以后发现，数字化转型主要面临的是对于系统价值的认知及使用模式发生了变化。

很多早年传统的管理者，甚至是IT负责人都不能很好的理解其中的价值和含义，才使得数字化转型变得步履蹒跚。

数字化转型在我看来，对于企业业务的经营改革主要是来自于对于认知的变化，体现的现象就是要求一些非标的能力、行为、准则逐步建立结构化的形式和数据，从而提供数据驱动业务发展、决策的模式。

早期企业对于系统的诉求更多是完成降本增效的诉求，所以更多以工具的形式来辅助业务运营。

随着市场环境的不断变化，我们渐渐开始进入到乌卡时代(VUCA volatile，uncertain，complex，ambiguous ),企业需要面对更多的不确定性，更多的竞争，对于企业经营来说也要求脱离以往粗放型的人为决策管理方式，变为精细化、数据化、标准化的高效管理模式。

在这个前提下，对于数字化对系统的要求也不仅仅是工具，而是需要精准的数据、多维度的决策判断、直达一线的命令传达效率等等。

这些都需要通过数字化及系统、数据的改进过程中不停的对组织、战略认知进行调整，从而逐步达到数字化转型的目的。

而在这个过程中，如何量化线下人为的各种运营动作和行为，能够完成从非标到标准化、结构化的过程就是建模的过程。在我看来，掌握建模方法的平台才能最快最有效的快速完成数字化转型的道路。

02

数字化建模框架

我们知道想完成企业的结构化标准化，就需要从战略、执行、模式等多方面出发，这样看来建模也不仅仅是系统层面的架构设计，更多是要看符合战略、模式的契合度。

企业架构（EA Enterprise Architecture）的框架设计在业内也有很多已经成型的方案，从宏观上来说，企业架构包括业务架构、产品架构（应用架构）、技术架构、数据架构。

企业架构作为宏观的指导框架，可以帮助负责人从公司角度来审视如何指导拆解目前的事务及结构、机制等。目前的主要架构模型也很多，比如TOGAF,ZACHMAN,MEAF等。这里我们重点介绍下前两个。

ZACHMAN作为比较早期的企业架构理论发起者，他的框架是大多数企业框架的雏形。

zachman框架

从结构上来看，他的理论基础是通过5W1H的问问题方式对不同类型的模型进行分析设计。这个方式在现在来看已经是比较普遍的理论方式了。

5W2H（多了一个how much）目前很多时候被运用在调研需求的时候或者产品规划设计的时候，从起源来说都是从zachman的框架延伸出来的。

我们可以认为某个产品或者业务是一个企业，通过这种方式来进行“企业架构”的设计，即我们说的产品业务的规划设计。

模型上zachman框架主要是三类模型：业务模型、产品模型和技术模型。这些模型在后来的绝大多数框架设计中都是主要的组成部分。

而另外一个影响比较大的则是TOGAF框架，相信这个框架很多人都听说过，而我们可以发现现在很多时候产品经理的一些规范、方法论也都来自于此框架的体系。

TOGAF框架

上图可以看到TOGAF的框架跟现在我们日常的需求管理流程是很相似的，只是从颗粒度看日常的需求更小一些。

两者都是通过对业务能力的了解（调研）进行架构设计，并根据设计的框架逐步进行内容的开发。

所以我们可以看到企业架构设计的元素和原理与日常我们在进行产品需求规划设计是很相似的，这也就是为什么常说产品经理理论上是一个公司的ceo，他负责的部分从认知上来说应该站在企业公司或者产品顶层的角度来思考问题。

从上面的一些经典企业架构来看我们会发现，在管理企业架构的时候整体下来主要是对四个部分进行架构设计和建模的操作，即业务架构、产品架构（应用架构）、技术架构、数据架构。作为一般企业核心的四套架构设计，其中包含了很多需要掌握的建模模型、梳理方法论等。

我基于在互联网大厂（曾在京东、阿里多家一线履职过）的中台经验，结合我近年来为各大不同行业的头部企业的数字化转型咨询、评估的情况。我梳理了一下数字化转型需要进行的一系列建模及设计的顶层框架。

数字化建模蓝图

这个框架是基于多行业的实操落地经验总结的，在不同的框架中运用了多种模型，包括对流程分解的，prd梳理的、业务架构建模的，产品建模的等等。

其中技术模型考虑到相对更底层，且和业务价值的关联相对较弱，这里不进行展开和解读。

蓝图中有一些模型是来自于一些成熟的方法论，比如PCF，DDD，有一些则是根据我的实际经验结合方法论提炼出来的建模方法。希望对于大家有借鉴参考的作用。

考虑到文章篇幅过长，本章中涉及方法、建模的详细过程不在本文累述，后续我会单独写一些系列文章来讲解本文里面哪些模型的详细拆解过程。

接下来我们来看下这个建模蓝图中都有哪些会运用到的模型及方法。

03

数字化建模详解

上面我们说到了数字化架构有4种架构，除了偏底层的技术架构以外，其他的几种都是反映企业业务运营特征的核心架构，而不同架构下也有不同的模型表现形式：

业务架构模型：负责表达业务运营机制模式的模型，主要解答业务的机制，规则等。常见的业务模型主要包括业务流程图、业务SOP规范，业务决策规则清单等等。形式上不限于线上，线下的excel等各种格式也是比较常见的。

价值流梳理

海外仓业务管理模型

产品架构模型：通过业务架构的模型进行系统层面的解读。包括产品分层模型等。产品建模的过程其实就是日常产品经理的常见工作内容，包括流程图、ER图，产品规划蓝图，产品roadmap等等，甚至PRD里面的逻辑描述其实也是基于一定规律的建模模型获得的（很多资深产品经理脑海中已经形成一定的经验，所以不需要特意去建模获取）建模在产品经理的日常过程中是特别常用的工作方式，也是方法论沉淀的方式，甚至即使是前端的产品经理，在设计页面的时候也需要运用到一些信息架构设计的模型或者方法。

某平台采购下单流程模型

数据模型：基于业务的梳理和建模，构建数据层面的模型包括物理模型，数据实体，数据血缘，数据流向等等

订单模型

整体架构的建模是从业务模型开始，业务模型代表着公司的业务机制及模式，业务建模产生相应的业务元素，如业务流程，业务角色，业务动机等。这些元素是其他模型等必备要素。

业务模型分解的元素和规则可以用来进行数据建模，数据建模根据业务诉求搭建相应的数据结构和模型，从而满足业务的记录、观测、分析的各类数据诉求。

而数据模型也是产品建模的重要组成部分，产品建模时候也需要参考数据模型来进行相应的产品设计及划分。

产品建模则是我们真正意义上完成业务价值流在数字化上的体现。好的产品建模可以最大程度的还原业务的真实作业场景，盈利方式，合理规则，有效监控等等一系列的能力。从而帮助业务更上一个台阶。

模型之间关联

产品建模根据业务战略、执行、落地等多个维度，也会分解成若干层，不同维度的产品建模代表着不同的含义和价值实现。

总之，所有的模型建模的目标都是为了最大程度的提供还原度高、标准化、结构化的业务模式解读，并可以通过在线的能力有效的解决线下的各种问题。

在不同的架构中，建模的方法及建模后的产物都有着很强的联动性，在日常的产品、业务工作过程中，很多东西我们都是无意识的在使用，而忽略了他们之间的关系。

比如我们画的产品流程图是基于业务流程图来进行制定的。产品的逻辑是根据业务执行的逻辑进行转译的。这些其实都属于建模层面的产物。

接下来我们简单看下各部分架构内都有哪些模型及规范的。

我们日常用到的一些设计的流程大多数是源自于TOGAF的企业架构，在TOGAF的企业架构中有一种架构的开发方法，简称ADM(Architecture Development Method,ADM)。

ADM是从企业架构的角度给出了对于架构设计的设计思路和路径。而路径上可以看到业务架构的设计和愿景是产品架构（信息架构设计）的前提，所以我们可以理解为ADM在日常工作中就是我们产品需求设计的一个流程框架。

我们可以看到流程上都要进行业务规划（架构愿景）、业务调研、分析（业务架构）、产品规划设计（信息系统架构）、技术方案设计（技术架构），复杂项目还会有多条线的整体产品方案（解决方案）等。

下图是ADM的各个环节的关系图

在实操场景下，现在绝大多数公司的产品需求设计流程都是和ADM的架构设计流程是相似的，原因在我看来产品需求设计更多是对于业务诉求及规范的理解和转义（让语言上更解决系统语言的表述方式）。所以在设计业务架构的时候都是相通的。

ADM是从宏观角度划分不同环节的关系及路径，那么另一种企业架构CBM（component business model 组件化业务模型）设计思路则是更加细化到更细的领域进行。

CBM引入了领域和职能的概念，进一步将价值单元进行划分，不同领域在不同职能上都有特定的价值组件（BC），而每个价值组件既可以是业务的也可以是系统的。

当然在数字化的认知下，原则上业务组件都可以通过量化完成系统化的构建。

这种分层分域的逻辑产品经理是不是看着十分的熟悉？

没错，大多数的产品架构蓝图也是基于这个理念进行划分设计的。后面我们会细说下关于产品建模时候蓝图如何聚合领域。

前面我们说了，业务架构、产品架构、数据架构是息息相关的，而架构建模的源头来自于对于业务架构的设计。

业务架构

业务架构目前市面上主流的设计框架是价值流 流程的组合，即通过识别企业业务价值流，构建实现价值流的流程从而完成整个业务架构的设计。

在实际落地过程中我发现一个问题，价值流是属于顶层设计，而流程更多是聚焦到所有分支场景的执行操作，中间还需要有一个桥梁来连接，也就是说同样场景或性质的流程应该形成统一规范，即业务的SOP。基于上面的设计框架，最合适的业务架构建模框架包含的元素有

1.价值流（价值主张、价值流、价值流阶段）

2.业务SOP（规则集合、流程合集的价值主张）

3.业务流程（即包括所有业务场景的执行流程及逻辑规则）

原则上业务SOP的模型形式和价值流和业务流程的的模型类似相通的地方，大多通过流程图的方式来展现。

业务价值流

比如上图就是一个供应链企业的生产、交易价值流梳理，而下面提炼的阶段就是价值流阶段包含生产价值流阶段和交易的价值流阶段。

价值流中间的每个细节节点如加车、下单等又构成了一个SOP的规则、流程集合。里面包含很多不同的处理子流程。

很多时候大家在梳理业务价值流的时候会和系统的流程混淆。一般情况有以下几点区别：

1.业务价值流重点描述场景、角色的交互，系统只是其中的一小部分，而系统流程的交互主要是线上系统交互为主。

2.业务流程的节点需要表达业务价值的阶段或者成果，如履约完成、审核开票等。而系统流程中间有不少是系统的底层处理，比如数据的转换之类的。

业务架构的建模框架如下

业务架构建模框架

我们上文有提到业务架构建模核心是价值流和流程的梳理和拆解。其中价值流分为识别和价值流阶段梳理。

什么叫价值流呢？

企业存在的核心在于为客户提供价值，即其价值主张。业务的价值流是为了实现其价值主张而进行的方式。

业务价值流解读是产品建模、拆解的前置依赖条件，无论是平台级规划还是单独条线的规划都是如此。

举个例子，腾讯的核心产品是微信和QQ，那么他的价值主张是什么呢，价值流又是什么呢？

腾讯的核心能力是社交类软件，那么它的价值主张就是社交吗？并不是。我们知道，腾讯有很多其他产业，比如投资京东、美团等，它投资不同领域的产业目的是将连接属性做到最大化。

因此腾讯的价值主张是“连接”，因为无论是人与人之间的连接，还是人与行业之间的连接，都需要围绕连接开展。

而腾讯的价值流基本以连接后的导流，引入为主，通过连接提供更大的客户群体。

阿里的价值主张则相反，它通过买断自运营的方式实现进场（比如饿了么、高德等），再通过制定平台规则和平台统筹实现统一管理，实现各种服务、商品、信息的流通。

因此阿里的价值主张是“撮合”，撮合的本质是降低商业摩擦成本，并通过各种规则和能力使得商业成交转化率得到大幅提升。

阿里的业务价值流主要以平台间商品价值的互换和组合销售为主的交易流，提供更高更多的客单。

综上可以看出，价值主张为公司确定了很多隐性的东西。如果我们没有深入理解这个概念，就容易设计出一些跑偏的架构。

价值流的识别和制定也是来自于一些内外部的输入，包括战略输入、动机输入、商业模式输入。

数字化转型需要制定一系列的战略决策，不单单是进行系统的改造升级，战略决策及业务动机会直接导致数字化的倾向性。

比如战略上希望打造供应链一体化平台，那么业务动机和商业模式则会聚焦在提高供应链产能、周转，扩大分销渠道等能力上，商业模式也以大宗批发为主，零售为辅助。

这样的输入下，价值流的核心会聚焦在后端及B2B的模式上做延伸，类似S2B2C等等。

而如果战略上希望打造的是全渠道营销平台，那么供应链就会弱化，更多是完成渠道和用户的转化能力。

关于战略、动机、商业模式的输入可以通过构建战略屋的方式来得到公司层面或者事业部层面的战略构建。

业务价值流依存于输入的差异和变化，价值流则绝对后续的业务架构建模。

业务价值流是一个端到端的流程合集，为客户、利益相关者或最终用户创造整体结果。即为某个或某群特定的利益相关方提供完成企业或平台价值主张的流程或标准。他是由若干个价值流阶段构成，即我们常说的关键环节

下图是一个标准的电商价值流的示例：

价值主张：交易平台，为客户提供交易及履约服务价值流：交易价值流（或叫价值链）价值流阶段：共五部分（加购物车、下单、支付、分拣打包、配送）

价值流的识别和价值阶段的拆解有助于我们快速找到业务的核心逻辑及目标价值。方便对后续的更细维度的流程、功能、业务逻辑进行拆解。

识别价值流以后就需要进一步对业务价值流或者价值流节点拆解、细化。形成可以落地执行的内容，如流程、规则、策略等。

这时候要PCF（ Process Classification Framework 流程分类框架）,PCF不是一个业务上的模型，更像是对于业务流程梳理的时候一个通用的规范。

他可以让业务人员在梳理业务流程和SOP的过程中按照一定的规范快速梳理出自己业务的相应流程和规则。

PCF共计有13个分类的流程框架，5个级别流程拆解层级。

13个分类流程框架

PCF将13个分类流程框架分为两大类：日常运营类的和管理支持类的。而这13个分类在日常我们的工作中最常用到的是运营流程类的相关框架。

PCF的最大作用是通过框架一定程度上穷举了不同层级对于业务流程的概述。你可以通过PCF的内容快速了解到当前需要梳理的业务流程都有哪些种类，他们的大体关系是什么样的。

按照PCF的划分，整个流程被分成了5级：

类别：可以理解为是表达当前领域下对于价值流和价值主张的流程。流程组：是解答上一级流程划分的集合，我们也可以理解为是价值流阶段，代表是不同节点的组合。流程：这个层级的流程也是以流程集合形式体现的，差别在于这个层级更聚焦在具体的成功转化上，这个层级的"流程"会消耗到资源，所以需要从业务的实际工作维度来进行设计，可以理解为是我们常见的业务SOP。比如售后分类中，售后维修可能是流程组的概念，那么维修评估、维修报价等等就是我们说的“流程”，他需要开始对资源进行消耗。而维修评估不单单是一个独立的业务流程，还可以进行进一步的拆解，即下层级的活动。活动：这个层级的流程则是我们通常意义上表达的业务流程，主要是进行生产、操作流程的。任务：任务属于在更细维度的事务拆解，一般情况下这个颗粒度分解的内容可以理解为处理业务的原子因素。在DDD领域设计里面的事件、命令其实就是对应这个维度的。需要说明下，有时候业务场景没有那么复杂，事件和命令的原子因素也可以对应上级的内容。

5个层级样例

比如上面这张图就汽车是企业风险合规整治的一个流程框架概述，通过逐级拆解可以找到业务场景下需要梳理的流程清单，方便我们在做业务架构设计的时候快速穷举查找。

PCF不会涉及到具体的业务元素，但在判断是否完善业务场景和流程的时候，可以作为参考的架构来看，此外PCF还有很多不同行业的细分框架，对于具体业务理解更有助于判断。

下面这个就是汽车生成行业的客服管理流程分类框架

汽车PCF流程分类框架样例

说了这么多流程分类的方法论，也许对于很多产品出身的同学来说感觉不是那么好理解，那么我通过系统的相关模型给大家解读下如何来看待业务架构设计中PCF对于产品架构设计和日常需求的作用。

PCF的五层分类前两层可以便于我们去快速找到对应领域业务的关键价值流和价值流阶段的内容。而后面的三层可以指导我们去识别业务SOP、业务流程梳理的完整度。

前期业务建模的架构越完整，对于识别出来的流程、角色、事件、命令就会越准确，后面去进行系统领域的划分设计就会更加容易匹配，输出价值。

我们以订单中台系统中的一个部分拆单模块为例来看下，假设我们认为拆单模块的流程是一个完整的流程分类，那么他的链路就是我们说的价值流，里面的节点是价值流阶段，再往下拆分的就是子流程，即流程、活动、任务。

子流程都是需要消耗资源的，即需要调用相关系统计算、更新数据等。

拆单流程分类框架示例

业务流程拆解后，为了后续可以进行系统的架构和建模，可以在已经完成的业务流程中做一些“标签”的识别，我们可以通过流程节点识别出来事件、命令、角色。这个概念是来自于DDD领域设计中的事件风暴。

在实际的建模和落地实施过程中我发现，事件、命令就是最小的业务单元，而能够讲业务流程拆解到最小业务单元，在进行后续的产品架构设计，甚至产品具体功能的PRD编写时都有很大的便利和指导性。

以一个审批流程为例，我们可以看到，事件、命令作用于每一个节点上，通过拆解可以找到最小单元的变化数据和最小单元的操作动作。从而进一步结构了业务在运行之中的核心“原理”。

事件、命令拆解示例

对于产品建模来说，业务架构建模是非常重要的过程，很多企业没有能做好这块，或者说对于业务设计更多来自于脑海中的概念和口述，缺乏更多的细节。

这样就导致产品规划、设计时候很多产品经理经常会抱怨业务没有想清楚，方案感觉都是拍脑袋的原因。

另一方面，业务的经验更多来自于运营过程中的不断收集，内容更多是碎片化的积累，如果希望做数字化转型，业务架构建模的体系能力是很重要的。

业务建模后很多元素是产品建模的基础，比如流程、规划、目标等。下面这个图来自于建模蓝图中的一部分，表明了业务建模和产品建模的转换关系。

业务建模与产品建模的关系

说完业务模型，我们来看下产品模型，产品建模解决的是设计的框架及对待问题的处理方案准则。很多的信息和数据都是来自于业务建模的转化，产品建模需要通过对业务的理解和抽象形成系统层面的模型来指导产品系统的搭建。

按照从宏观到细节，我将产品模型分成了三层。

顶层建模：针对业务价值流和阶段进行拆解，找到核心的业务价值，转义业务架构建模形成的信息。领域建模：基于DDD的方法论针对产品领域进行聚合，形成不同产品领域的模型。包括一二级域。通过产品能力矩阵识别领域缺失，逐步完善领域建模。产品功能点建模：指的是基于上面模型的原子要素（事件、命令、角色等）和流程、逻辑进行具体需求的整理，也就是我们整理prd的过程。通过模型可以及时发现需求梳理的问题，进行完善。

产品建模：顶层模型、领域模型

产品功能点建模

产品的的分层建模目的是通过不同维度的建模可以将对应层级的业务架构进行转化，比如价值流的梳理转化的产品层面就是顶层架构建模，可以通过价值流和价值流阶段的识别，快速确认在数字化中核心的产品链路是哪些，核心产品链路要赋予更高层次的数字化能力的规划。

举个简单的例子，一个供应链企业和一个营销型企业虽然同样都需要交易、营销、供应链的能力，但是数字化产品架构设计时，由于业务架构上的价值流和流程的级别不同，所以产生了差异化产品架构设计的情况。

供应链企业对于库存、商品、物流方向的智能化、自动化能力就需要有一些深度规划，而营销型企业则需要加强用户运营，营销的玩法。

供应链企业产品架构示意图

营销型企业产品架构示意图

顶层产品架构设计会影响到在领域建模时对于根据产品能力矩阵进行领域能力完善时的侧重和取舍。

产品建模的顶层建模不仅仅只是照抄业务架构建模的价值流内容，而是需要判断出业务的属性特征，从而得到产品可以赋能的核心价值点。

除了进行分层转化以外，产品架构设计最重要的是提炼出两个东西：

系统流程，系统流程代表着业务线上还原的场景，还原度越高越能够体现业务架构设计的准确性。而且系统流程直接决定了交互的逻辑、关系，所以系统流程的梳理是很重要的一项产品建模事件、命令、角色，通过事件风暴获得的事件、命令、角色是基于业务建模的，在进行产品建模的时候需要根据系统场景和流程补充很多系统层面的事件、命令、角色。比如订单的下单就需要增加一些线上的审核校验事件或命令，促销发券就需要有一些促销计算的过程等等。在产品建模中，事件、命令这些元素是业务的最小单元，也是系统执行的最小单元，我们可以理解为它就想PCF分类框架中的最后层级的流程分类：任务所以包括领域建模、功能点建模都需要通过事件、命令进行归因识别，确保业务、产品从上到下的逻辑是统一的。在产品分层建模中，我使用的核心思路是基于DDD领域设计的思路，包含了各类领域设计的元素：聚合根、事件、命令、限界上下文等下图是我总结的关于DDD领域设计中各个元素间的关系：

数据建模

市面上讲述数据架构的详细文章很多，也说的比较清楚，关于基础的概念这里我不单独累述了，考虑到数据结构还是比较方法化，很多东西和概念对于之前接触不多的人来说容易绕晕，本文重点用一些通俗的表达让大家来理解下这块的内容。

业务和产品建模的关系类似于人类起源之时人类生产活动和工具的关系。业务建模代表人们的基本运营规则和方法，而产品建模则是通过更多系统化的能力提供快速提升的手段。

而数据建模则像是语言一样，负责传达和表达人们真实的想法和沉淀积累。所有业务、产品的行为都会以数据的形式记录下来以便进行更多的分析、判断。

所以数据建模既来源于业务、产品建模，又对它们有导向的作用。

在进行数据模型的抽象之前，很多基础的信息都是来自于对于实体的理解和拆分。所以ER实体建模是进行数据架构的前提条件。

业务实体与数据架构的关系

数据实体识别完成后，我们就需要根据需要将数据分层、拆解、得到相应更独立的数据结构，这就是数据建模的过程。

举个例子，我们现在有一个订单的实体建模，那么根据订单的使用场景、信息、类型等维度对数据就有不同的诉求和分析角度。

我们可以根据场景拆分成交易场景、财务场景、售后（订单快照）等等，不同场景下的数据需要完成哪些分析，从而聚合形成相应的数据结构。

上面的描述方式类似口语，在实际建模过程中则会根据模型的特点分为逻辑模型、概念模型和物理模型。

简单来说概念模型就是表达实体的关系，可以用“实体-关系”（E-R）图来呈现，它的实现代表了自然语言的转化

逻辑模型则是技术侧在进行理解的时候用技术的语言解读实体关系的内容，这个过程和业务建模转化成产品建模由异曲同工的过程。

物理模型则是逻辑模型的落地，是对于真实数据库表的描述，包含了表、视图、字段、数据类型等等要素。可以理解为是具体的表结构。

需要说明的是这里面的表结构可能会因为场景、业务属性、用途等进行聚合或者拆分，理解上不是我们常规见到的业务系统里面的数据库结构，比如订单的数据可能就有多维度数据聚合的宽表来进行财务、业务上的分析使用。

除了模型外，关于数据的源头、流向、血缘关系也是数据架构建模的时候需要重点关注的，这些相当于我们在做业务、产品建模时候管理相应生命周期的闭环是一个道理。只有能够最大程度记录和体现业务、产品生命周期下的情况及特征，才是数据建模最大的价值。

04

数字化建模工具

说完了建模的方法，那么通过什么方式或者手段来建模呢？构建的模型都有哪些常用的形式呢？

首先，模型是包含很多种形式的，主要的作用是通过抽象的方式固化下来相对核心主要的模式、规则、流程等。所以模型等表现形式是多种多样的。

我们日常画的流程图就是建模的一种形式，业务梳理的规则列表，产品整理的数据字段，开发的接口规范，业务运营的流程，sop。这些都是模型的范畴。

我们这里面的模型是广义上的模型，而不仅仅是常规印象中的算法模型那些。

类似下述的这些图都属于模型的范畴，包括但不限于价值流、流程、规范、框架、规划等。

交互模型

业务流程

架构图

其次，建模的规范和标准是需要统一化的，在产品中大家见到的最多的模型语言就是UML，UML可以基于各种链路流程进行制图，表达他们之间的流转和关系。

此外还有对于业务建模常用到的BPMN规范。接下来我们重点介绍这两种语言。

UML

关于UML的基本概念相信在很多的书籍或者文章上大家都有阅读过，这里面我就不再啰嗦了。重点我讲下我对于UML的理解以及在架构、模型设计时候的一些底层逻辑。方便大家理解对于UML的合理使用。

UML在产品经理或业务运营人员日常的画图中经常会用到，它有一些基本元素和类型，我总结了一下，大概有以下几类：

实体元素：包括各类实际行为或者载体的表达，开始结束的表达以及对于判断的表达等。这些实体元素在各类图中用于对业务载体、产品系统载体、逻辑载体进行描述。需要注意的是，这里面提到的实体载体是指对业务或系统上某个规则或模型的载体，他可能是一系列的流程、sop、策略或具体角色、任务等。

流程建模示例

上图中的矩形和判断的菱形元素都是在表达实体的内容，包括判断逻辑和业务动作行为。连接关系：连接关系用于表达实体元素间的互动逻辑，不同类型的连接关系形成不同类型的图，如并列关系。

下列是我们日常常见UML的模型图分类及样例

主要域

视图

图

主要概念

结构

静态视图

类图

类、关联、泛化、依赖关系、实现、接口

用例视图

用例图

用例、参与者、关联、扩展、包括、用例泛化

实现视图

构件图

构件、接口、依赖关系、实现

部署视图

部署图

节点、构件、依赖关系、位置

动态

状态机视图

状态机图

状态、事件、转换、动作

活动视图

活动图

状态、活动、完成转换、分叉、结合

交互图

顺序图

交互、对象、消息、激活

协作图

协作、交互、协作角色、消息

模型管理

模型管理视图

类图

包、子系统、模型

可扩展性

所有

所有

约束、构造型、标记值

UML图样例

BPMN

除此以外还有一种规范其实也是我们经常见到的，就BPMN（Business Process Modeling Notation 指业务流程建模与标注）。

BPMN可以理解为是UML的升级版本，在BPMN中，包含的基础元素有：

流对象（Flow Object）用来操作数据的流向的对象，所有流转含义的内容都可以通过流对象表达，包括事件、网关、活动等。数据（Data）：数据对象是一个显示活动是如何需要或产生数据的。它们通过关联与活动连接起来链接对象‍（Connecting Objects）：连接对象将流对象连接起来形成一个业务流程的基本结构泳道（Swimlanes）：通过泳道对主要的建模元素进行分组描述对象：我们可以理解为扩展信息等内容主要进行注释，辅助描述等。包括组和注释两种概念

在日常工作中，这两种语言其实没有太多本质性的差异，很多产品经理画的流程图或者泳道图都是混合了两种语法的产物。

大多数的流程大家会基于UML的格式来进行，但是从我个人的经验来看BPMN在进行业务建模复原的时候更容易表达业务的上的一些场景、触发机制等。所以可以使用一些BPMN语法的概念来进行特殊节点的描述。

比如UML开始节点并没有表明太多元素或者触发的动机，而在BPMN中规定流程的初始需要通过某类事件或者场景的触发，即设定相应的流对象。这个概念有助于建模时对场景的描述更加具体完善，避免缺失和遗漏。

此外，对于我们常规建模的图形来说，大体可以粗略的归为两类：结构静态图和行为图。

结构静态图一般是用UML的格式来画，代表一些今天结构的图，比如产品架构图、组织结构图等。这些一般不代表行为或动作。

另一种就是行为图，比如我们经常画的流程图，系统交互图，时序图等都是这个范畴，代表一系列行为的动作流转。在这种图里面可以加入一些BPMN的元素用来丰富表达的含义。

尤其是在进行业务行为描述的时候对于特殊的场景、触发逻辑等可以通过BPMN的元素进行表达，方便进行事件、命令抽象的时候更加完善。

05

总结

数字化转型是一个痛苦的过程，但又是一个必经的过程。如何能够通过数治代替人治是数字化的核心改革。

建模是决定能否变成可量化、可衡量、可延展的商业体系的标准之一。一个数字化转型成功的企业都需要具备良好的合理的建模基础。通过模型可以有效的防止、预估、判断各类不可控情况的发生和蔓延。

本文重点讲解了各种模型、方法之间的关系及内部的结构逻辑。

作者：高晖 《业务中台产品搭建指南》作者，前阿里本地生活&京东产品专家，15年互联网经验的老兵，分享大厂经验的点点滴滴。

企业如何数字化转型

企业数字化转型面临的固有难点依然存在；四个变化因素是疫情影响、5G部署、人工智能（AI）加快应用，以及中美技术加速解耦。四个变化因素导致企业数字化转型或主动或被动加速，并加强了本土定制化方案需求。这要求企业能深入理解未来数字化企业的关键特征，充分利用2020年的变化带来的契机，系统性解决推进数字化转型中面临的固有难点，并依据对企业所处转型阶段的判断，制定符合自身特点的转型推进方案。

数字技术的发展已经从互联网、大数据，迈入人工智能时代。在数字化对社会经济的冲击和颠覆中，互联网企业独领风骚，传统企业的总体表现迄今为止不够理想。本文建议传统企业从对自身的数字化成熟度评估入手，明确所处发展阶段，理清数字化企业的七大关键特征，并注意克服企业数字化转型道路上的五个常见困难，在数字化转型的新一轮进程中达到事半功倍的效果。

01

正确评估数字化成熟度

企业推进数字化转型的过程中，业务应用、IT 架构、组织机制建设等工作环环相扣。企业要分清哪是因、哪是果，建立多维度的企业数字化成熟度评估体系，用于判断企业所处的数字化阶段，找出推进不利的可能原因，以及相应需要采取的措施。普华永道企业数字化成熟度评估框架从数字化战略引领、业务应用结果、技术支撑能力、数据支撑能力、组织支撑能力，以及数字化变革六个维度对企业的数字化成熟度进行评估（见图1）。其中引领性指标是第一点“数字化战略”，业务应用结果性指标是第二点“数字化业务应用”，其余四个维度（3~6）是支撑性要素，每个维度又可以细分为若干子维度。

图1：企业数字化成熟度评估架构

根据企业的数字化成熟度不同，可以将企业数字化转型所处的阶段分为在线化、集成化、数字化、智能化四个阶段。目前中国大部分传统企业处于在线化和集成化阶段，少数企业进入数字化阶段。智能化的局部应用已经出现，大规模成体系地应用在传统企业的情况尚不多见。处于在线化和集成化阶段的企业，当前数字化转型的两项任务是：

建立数字化转型的蓝图，可以参考下述数字化企业的七大特征；

加快完成企业运营的在线化和集成化，为真正实现企业的数字化分析和洞察打下坚实基础。

02

数字化企业的七大特征

与传统企业相比，数字化企业在业务、组织、IT 等方面展现出七点不同（见图2），其核心是构建“以客户为中心”的能力体系。

图2：数字化企业与传统企业的主要不同特征

一、以客户为中心的组织能力体系

以客户为中心是企业数字化转型的目标，其含义是打造多层次体系的以客户为中心的组织能力，包括围绕客户设计组织结构、基于客户场景的创新能力、设计满足客户体验的互动方式，并在数据、IT 以及考核机制等各方面体现“以客户为中心”的理念。

1) 组织结构：从以产品为中心向以客户为中心转变

传统模式下，企业以“我”为中心，不同产品的营销服务通常自成体系。数字经济下，以客户为中心，对同一目标客户群体，采用同样渠道触点，通过统一平台进行数据分析并推荐最优产品，采用统一的服务体系。基于这样的理念设计的组织结构（见图3），有利于客户数据打通和洞察，统一客户体验，提高企业资源利用效率。如果企业顾虑组织结构调整牵扯利益方较多时，可以先通过关键流程控制点以及数据的打通实现以客户为中心的能力建设，等时机成熟再做组织调整。

图3：以产品为中心向以客户为中心的转变

2) 业务创新：从流程驱动向场景驱动转变

从客户在特定场景下的需求出发，挖掘客户需求，设计整体解决方案，带给客户完整感受。这个方法解决了传统企业业务战略和业务流程之间缺少衔接，注重单个流程的效率，而忽略了客户整体需求的弊端。围绕客户需求，通过多流程、多功能配合实现创新（见图4）。

图4：场景驱动，多用户服务结构

3) 客户互动：从注重功能到注重体验

客户体验主要指沿着客户全互动旅程带给客户的便利性和感受舒适度，包括线上线下。线上通过 UI/UX 设计，线下通过特定场景/店面的全流程互动设计，打造无缝综合客户体验。实践中，要注重从整合、客户洞察视角打造优质客户体验，避免聚焦于单点的客户体验设计。

二、多元化能力

面对内外部日益复杂多变的运营管理环境，企业需要具备四种能力：敏捷、精益、智慧、柔性。支撑这四种能力的是先进的 IT 架构以及相应的组织能力体系（见图5）。每个域的能力特点如下：

客户互动：以客户为中心，全渠道、全价值链，强调敏捷、用户体验

资源管理：以流程为中心，围绕传统 ERP 系统，强调稳定、精益、高效

智慧洞察：以数据为中心，全域、全形式，强调智慧洞察

智能生产：以机器为中心，围绕 IoT 和企业生产制造系统，强调成本、效率、质量、柔性

图5：数字化企业的四个核心能力

三、智慧大脑

以数据价值为基础，人工智能分析为引领，搭建企业全局数据平台和智能分析系统，为企业运营管理的所有环节提供分析洞察，并从分析运营结果向预测未来发展转化（见图6）。妨碍企业整合数据分析平台建设的因素包括技术和部门墙带来的数据隔离，后者是目前更主要的障碍。智慧大脑在数据来源、数据分析能力、数据服务企业的方式几个方面都与传统方式有明显差异。

图6：“智慧大脑”的概念架构示意

四、敏捷能力

数字化时代企业需要具备敏捷的反应能力，对外应把握客户和市场的迅速变化，对内满足企业管理要求。敏捷能力的建设需要业务模式、IT 架构、产品开发方式同时实现敏捷。业务模式上采用“一线尖兵”+“后方资源平台”的方式，产品开发方式上采用设计思维和敏捷迭代方式（见图7）

传统用户产品需求，需要系统化分析论证、形成产品定义后再上线部署。设计思维和敏捷迭代方式下，通过用户角色模拟、聚焦小组分析、最小原型产品设计，可在最短时间内上线产品，迭代优化。

图7：敏捷迭代法

五、AI加持

企业应用 AI 分为两个阶段：应用场景较少时，AI 应用作为一个工具嵌入某个信息系统，常见的是互动型 AI，比如语音识别、机器人客服；企业的 AI 应用场景很多时，与 AI 的开发环境、常用 AI 数据模型，以及数据库整合在一起，形成企业 AI 中台，将各种AI能力汇聚在一起，对不同业务提供 AI 能力，并形成具备AI服务能力的中台（见图8）。

图8：AI赋能的IT架构

六、云+5G延伸运营空间

基于云+5G 的端边云架构，将企业的运营管理空间从依赖于有线网络环境的空间，延伸到更广阔物理区域（见图9）。“云”上实现业务中台赋能，“边”可以通过 5G 网络的边缘计算功能实现，增强终端控制的实时性，减少云端处理的数据量；“端”是 5G 终端实现与物理环境/机器的直接交互和控制。这样的架构将在工业领域、智慧城市、医疗、金融、快消行业得到广泛应用。

图9：企业应用的云+5G架构

七、IT组织能力从支撑型向驱动型转化

传统的 IT 部门以项目交付为主，数字化 IT 组织作为企业数字化转型的主要推动者之一，在交付模式、人员技能、IT 治理，以及成本核算等七个方面都有较大变化（见图10）。

图10：IT组织能力和运营模式的变化

大型集团企业，IT 力量分布在各层级单位，数字化转型还需要重点考虑如何整合 IT 资源，共同服务企业数字化转型，并为对外服务打下基础。

03

数字化变革的难点和解决方式

了解了数字化企业的特征，还不代表企业能转型成功。从互联网1.0时期开始至今，中国传统企业数字化转型十余年，整体效果并不理想，因为在推动转型过程中面临各种由于技能不足和机制不足交织在一起形成的固有难点。常见的困难包括五种：

对数字化转型的概念理解不一；

难以制定数字化转型的目标和评估数字化带来的实际业务价值；

可选项过多，每个业务和职能部门都有很多想法，但缺乏清晰的路径；

缺乏数字化人才；

传统企业的工作机制不适合推动数字化这种跨部门、求创新的变革。

解决这些难点，普华永道建议统一思想、统筹规划，并建立与企业数字化成熟度相匹配的推进机制。

一、统一思想

企业数字化转型定义：企业综合利用各种数字技术，与业务模式转型相结合，为企业解决问题、创造价值、提升企业业绩的持续性过程。

这个定义里，数字化包括信息化也包含业务模式转型。企业可以对数字化转型有不同的定义，重要的是了解数字化、信息化、业务模式转型三者间的关系。不论怎么定义，底层的业务逻辑、系统架构、业务与系统间的衔接，该怎么做还是怎么做。

二、设定目标

科学+艺术的方式，是企业制定数字化蓝图的手段。由懂数字技术能力的专家和懂企业业务痛点的专业人员一起，以设计思维（Design Thinking）的分析方式快速勾勒出企业应用数字化的主要场景以及可能实现的状态，即数字化蓝图，然后沿着蓝图逐步深入（见图11）。

图11：“科学+艺术”勾勒数字化蓝图

三、选择路径

建议企业采纳自上而下的顶层规划和自下而上的局部尝试并行。不同的局部尝试发生冲突时，遵循直接客户相关的解决方案优先、客户体验优先，以及 IT 架构前瞻性优先原则。在切入点的考虑上，优先考虑推进企业业务和管理的线上化，以充分利用疫情期间培养的习惯。

四、建立推进机制

依据企业对数字化转型的不同应用程度，数字化推进方式可采用“探索式”、“协调式”、“集中式”、“嵌入式”四种方式（见图12）。关键是是否需要一个中心化的数字化管控组织。

图12：企业数字化转型推进的四种方式

数字化转型初期，企业尚未确立整体推进方案，但局部试点的条件还是具备的，这时采取探索式，鼓励各 BU 局部尝试；之后，随着企业对数字化的应用加深，跨部门的协调需求加剧，向着协调式、集中管理式过渡。最终实现的是嵌入式管理，全企业在顶层规划下的数字化转型。

五、IT能力建设

资源层面通过内外 IT 力量的整合/借用。运作方式上，从项目制向产品制转移；人员上，初期重点强化 IT 团队中的产品经理、数据分析、业务架构类的队伍建设。

不同类型企业在转型过程中面临的难点是不一样的。对于规模较大，业务较复杂的企业，在转型初期，建立适合的转型推进机制，是比解决技术上的难点更重要的事情。

企业应该如何进行数字化转型？

首先，企业进行数字化转型不能一昧的崇尚技术或者停留在狭义的产品制造层面。而应该像海尔一样从单一的产品、到成体系的服务，到全新范式的组织结构、管理模式，到商业模式的颠覆创新，从而满足用户群体在数字时代不断更迭的需求。