数字化转型实践分析：从产品到产业

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

整理：North，人人都是产品经理实习生

分享嘉宾：高晖，前京东、阿里本地生活资深产品专家

题图来自Unsplash，基于CC0协议

全文共 6522 字，阅读需要 13 分钟

——————/ BEGIN /—————

在这里，我总结了2个关键词，即“数据驱动”与“精细化决策”。

数字化转型现状解读

当下的互联网时代和早年的互联网时代相比，已经发生了非常大的变化；而由于一系列因素的影响，我们对互联网本身的特征、应用，甚至于传统行业如何将这些能力转变为数字化能力等方面，都提出了新的挑战和要求。

可以大致分为两种类型。

第一种类型，即增量经济时代。

这个时代的互联网红利非常可观，所以在发展过程中，我们可以不断找到新的场景、新的业态、新的服务模式；此时大家追求的是增量服务，要求就是“快”、能尽量解决问题，传统行业也一直在试图跟上互联网行业的步伐。

第二种类型，即存量经济时代。

这个时代和增量经济时代相比，最大特点在于人口红利、业态红利等各方面红利的下降，所以我们需要在当前的存量现状下寻找新的突破、新的需求增长曲线。

而无论是互联网企业还是线下企业，其实都面临着这样的问题，所以线上线下相融合的逻辑也就浮出水面了。

简单来说就是：在现有渠道、现有能力内盘活所有资产，并更好地进行使用；此时就需要将增量时代的互联网经验能力赋能在现有体系下，让线上线下都具有一定程度的数字化能力，从而在存量时代实现精细化运营。

这就是现在存量经济时代的一个特征。

在这样的特征下，我们对人、货、场有更深度的要求，并需要具备更深度的运营能力或经营能力。

详细分析，无论是在传统行业还是互联网行业，我们都需要具备几种运营能力。

其一，渠道能力

几乎所有公司都需要面临如何拓展销售渠道、供应链渠道等问题，渠道决定了企业是否有能力转化各种订单交易行为。

而在当前时代，我们除了传统的线下、线上渠道，还存在着混合渠道，比如私域，本质上而言就是线下线上的流量混合，一些传统渠道则变成了真正意义上的公域。在这些渠道里，我们是需要具备运营能力的，但以往的增量经济时代并不存在这类要求。

其二，供给能力

简单来说就是采仓配能力，或者是ERP的某些核心能力。

在早年里，这类能力和相关经验是相对固定的，但是伴随存量时代的到来，在供给能力上，我们也需要具有更深度、更精细化的运营能力。

比如以往我们只需要在纸面上进行计划、协同，但现在我们需要将其逐渐落地，无论是颗粒度管理能力、商品能力，还是采购能力，都需要管得更细，无论是追踪，还是对于货品、汽车等的调度监控预警能力，也需要更加深钻。

最后，运营能力

其实以往无论是成本、业绩分析，还是制定决策等方面都需要进行运营，不过现在，因为渠道能力和供给能力在被动增长，此时运营能力如果不进一步深化，就会导致管理上的脱节。

所以在当前时代，你会发现几乎所有公司都开始尝试提升销售能力与供应链能力，这就造成运营能力上的被迫提升。至于所有的提升都依赖什么——不仅依赖于人，互联网的一些能力，比如数据能力、系统能力、智能化能力，也开始被“依赖”。

这就造成了2个关键点的出现。

第一，在这个时代你需要具有强大的样本数据，并利用强大的、细化的数据能力来做精准度更高、更标准化、更客观的分析和判断。

这就导致了数据驱动的出现。而数据驱动的出现改变了以往的人力驱动或业务驱动模式，它是相对而言可评估、可量化、可追踪的，这也是精细化的一个前置条件。

第二个关键点，就是精细化决策能力。

我们几乎所有的增长、所有的成本管控、所有营收能力的提升，本质上并不取决于日常操作，而是取决于如何基于日常操作提供更高效、更有效的决策。而这需要依托数字化时代的产品来帮助解决，因为以往的数据颗粒度不够细、可供分析、处理、判断或执行的颗粒度也不够细。

而在这个时代，数据驱动和精细化决策是解决大多数企业寻找第二增长曲线的底层逻辑，在这个过程中又会涉及到系列问题，比如数据架构、策略集中化管理等，这些才是时代刚需：

数字化时代之所以被称作数字化时代，原因在于这里的大多数问题都可以通过数字化产品能力进行解决，此时人不再处于完全主导地位，而是需要通过系统辅助来完成驱动和决策。

此时，我们的系统大致会形成通常意义上的双中台模式。大多数企业也开始尝试这一模式，虽然大家的起步阶段可能有差异。

那么双中台的作用在于哪里？

首先，它可以完成数据驱动。

其次，所有的指令可以通过中台模式进行深加工，从而将指令散发至各个业务端，形成精细化决策的逻辑。

互联网公司也在尝试着将现有能力赋能传统企业，推动数字化转型，比如常见的大平台开放数据、SaaS服务的出现等等。

不过在实际搭建的过程中，我们也会遇到许多问题，比如产品能力重复建设、业务价值弱，业务协同能力不足、线上线下脱节，又比如标准化程度低、逻辑不清晰……

而导致这些问题的核心关键点就在于缺乏统一的架构认知和设计，所以信息化资产很难被驱动与落地沉淀，也就达不成数据驱动和精细化决策的目标。

因此，完整的认知是十分重要的，因为无论是技术、业务，还是产品、运营人员等，意识和认知可以帮助我们更加快速地在时代中完成转型。

这里可以提出2个关键词。

首先是“顶层设计统一化”。

简单而言就是在做整体的系统设计时，将业务上的价值精髓抽象出来，看看在数字化转型阶段，技术可以为业务带来什么样的增长价值，也可以认为是业务价值流的一个实现。

如果系统只是为了解决工具化，那就称不上数字化能力。如何能将业务认知沉淀并形成广泛应用，才是数字化时代最重要的事情，而核心点就在于“顶层设计统一化”。

其次是“业务需求结构化”。

因为我们要实现统一化设计、要尝试实现业务价值的线上转化与业务场景的线上还原，所以结构化是十分重要的。

以往大多数的业务需求或者业务思路是相对零散的，此时我们便需要通过数据来驱动业务，从而让逻辑思路或者业务模式完成结构化、标准化，最大可能地发挥价值，这也是我们常说的数字化能力。

产品经理如何适配

那么，产品经理要如何适配现在的时代？

其实主要就在于认知上的改变。

因为无论你是产品、还是数字化部门的负责人，抑或是在SaaS公司为数字化赋能，本质上来说，都是希望改变现有运行业务的认知，改变现有的操作结构，形成一套可量化、可标准、可追踪的能力来帮助业务解决问题。

这是我们当前时代的一个核心诉求，所以产品经理要从这个角度去进行适配。

数字化时代的组织结构，发生了哪些调整？

早年在传统公司或者互联网公司，我们可能常见的是IT部门，或者产研部门；而在数字化时代，数字化部门被延伸出来了。当然，也存在数字化部门被IT部门兼任的情况。

但不管怎么说，为了让数字化能力可以更加快速地提升，并发挥数字化处理、决策能力，所以许多传统企业会将数字化部门单拎出来。

一般会形成两种模式的架构。

其一，IT驱动的数字化架构。此时数字化部门会置于IT部门下面作为IT的子分支，主要负责解决三方企业的问题，比如与合作的三方厂商进行对接，整合方案、与业务沟通确认需求、跟进过程、完成开发落地等。

其二，集中制数字化架构。意思是在领导层笃定要做数字化转型这件事时，从上到下往下推，让IT部门去进行思考，从而有全局性的、从业务到系统的全局认知。

此时为了真正建成数字化能力而非工具化能力，企业会单独建立数字化部门，负责整体的规则设计、三方能力的整合方案、以及决策的分析制定等。

比如现在不少大型企业都会这么做，这个部门可能不太怎么管理实际的开发落地，但是却会管理方案整合、业务分析与策略制定。

这两种模式对数字化能力的要求、或者部门人员的要求并不一样，相对相通的部分在于这两种模式都要求对产品方案、对业务有深度理解，从而帮助实现快速转化。

而大多数产品经理其实缺失了这部分能力，具体缺了什么，可以看下方的产品能力矩阵。

一般来讲，5年是一个门槛，5年左右以上的产品经理更需要提升的是管理能力、增加经验；而年限较短的产品经理则大多聚焦于执行能力上的提升，接着是认知能力和逻辑能力的提升。而先前讲的数字化部门、或者传统意义上的产研部门，所缺乏的就是认知能力。

所以在向上提升的时候，如果想提升核心竞争力，本质上来说就是提升逻辑能力与认知能力，或者再抽象聚焦一下，即模型化能力与规则化能力。

比如你如何能将业务模型化、规则化，简单来说即标准化、量化、结构化，沉淀之后还可以落地执行；这其实是所有产品经理在这个时代都需要试图掌握的能力。

而这种能力的本质在于对整体架构、业务架构、模式的理解学习，这就不得不提到对企业架构的掌握。

宏观角度来看，企业架构可能包括战略设计等层面，而大多数产品同学可能会涉及到的是业务架构设计与应用架构设计，简单来说即产品架构设计，甚至还有数据架构设计。

而架构设计最核心之处在于建模，以及对各种事物进行分析、理解、评估，从而构成数字化转型结构。

业务架构设计是应用架构设计与数据架构设计的一个前置，最终底层则是技术架构设计，这个部分是许多产品或者数字化转型部门所需具备的能力，或者说需要有相应的认知理解。

为什么？

原因在于现在是数字化驱动寻找第二增长曲线，如果对产品、业务的理解不够深，或者设计上不够完整或合理，那么在业务层面，无论是价值链、运营模式或者是执行维度，就都有可能出现偏差，从而导致市场认可度、执行力不足。而这，就是数据驱动时代的明显特征表现。

所以在进行业务数字化转型时，大家可以考虑学习架构设计的相关内容，比如业务架构、产品架构等，这样将有助于你在后期进一步提升认知能力。

这里可以简单讲述两个通用的架构模型。

第一个是1987年提出的zachman框架，它将所有场景分成了若干维度，又横向分成了若干种模型。

可能很多人看完了之后也会发现，这个模型的逻辑与5W2H很像，它的业务系统技术模型与我们现在的划分逻辑大致类似，而现在许多模型也沿用着这个框架。

第二个是1995年左右出现的TOGAF框架，这个框架在大多数互联网公司和传统IT企业里都会遇到。

而图中左侧是该框架中相对核心的模式，这个模式的运作流程与现在产品经理接需求的流程大致类似：前期包含业务设计、信息设计，后续紧接技术设计、方案上线变更优化等。许多传统企业的逻辑经验也基于这个框架进行了延伸，只是早期企业大多只学了皮毛，没有更加深入。

以上，就是我们常见的两个企业架构模型，而企业架构又延伸出了业务架构与产品架构，业务战略、企业战略与产品战略是一体的。

所以无论是产品、开发还是运营，都需要对企业架构中的产品架构和业务架构有一定了解，这决定了后续如何做转化、如何理解业务战略，并形成一套可落地、可执行、并具有延展性的能力。

而业务架构和系统架构之间存在着相互转化的过程，这其中就构成了一些系统流程规范。

可以用中台的系统架构来进行解读。

比如在业务架构一侧包含了价值链、业务流程、业务领域等方面的分析，这些分析会转换至系统的相应规则、服务标准、规划能力等维度，二者之间是不可剥离的，否则就会走向工具化。

这也是数字化与信息化的区分所在，如果业务和系统之间不能形成有效的解读，那就意味着企业仍旧处于信息化时代。

可以看看下面的这张图，它包含了从企业架构、业务架构与产出PRD里可能涉及到的业务、产品等维度的内容。

那么数字化产品能力建设一般可以分成哪些步骤：

简单来说，即通过到手的信息、数据、以及对方讲解的流程，来判断如何做才会更合理，之后拿着正确的模型进行架构设计，如此，才能保证做出来的数字化能力不会在原则上跑偏。而短期内是否可以见效，则需要看业务的具体发展。

这里可以分成两个方面，其一是价值方面，即业务价值流以及业务SOP，在客观地解读之后结构化，形成相应的业务流程图，之后按照事件风暴模式进行下一步。

简单来说，即将流程图标准化之后，形成事件命令清单，将其元素化，此时只要将元素捋清了，那么理论上做建模时，就是相对标准的。此时依照事件命令清单进行架构设计，也就完成了我们做产品规划时的标准化流程，也可以保证我们在前期进行业务调研分析时不偏离业务路线。

以这个基于库存的模板案例为例，我们按照之前的过程进行拆解。

首先，梳理业务场景，根据不同场景进行调研；分析之后找到相应的产品模块定义，基于定义来定位、明确其价值，之后寻找其价值流、寻找其解决哪些问题、需要哪些流程节点、流程节点下又需要多少业务流程、业务流程规则又应具备什么样的能力？

梳理完毕之后，我们可以尝试将其元素化，进行事件命令风暴的拆解；拆解了之后，就可以进行相应的架构设计以及行动蓝图。

可能不少人会对价值流与业务建模的概念有些模糊，所以我们来简单介绍一下。

什么是价值流？

简单来说，价值流也是流程的一种，只是它是最顶层的流程，它代表着某种商业模式上的关键流程；所以它可以看作是业务动作。

而在整个拆解的过程中，我们首先要做的就是对价值流进行识别，之后对价值流的每个阶段进行识别，比如它有若干个节点，这些节点是什么，在进行系列盘问之后，相应的产出物就是节点清单，再加上我们的流程图。

举个例子，比如拆解订单。

一般标准化地来看，即下单——接单——支付——下放仓库——分拣打包——出库运输等，这是标准的电商流程。

其中包含不同的价值流阶段，个中又有许多子流程，此时又可以继续拆解，比如最上层即价值流，基于价值流可以形成不同模块，有各自的组合部分，比如审单时可能会有审核机制，但审核机制不属于价值流部分，而是属于其他的业务场景，其前置可能也有待配置的事项，这时就会需要针对不同流程、子流程、主流程进行拆解、判断。

这也属于业务SOP的概念，接着继续分析当前场景下应具备的流程有哪些；如果没有，又该如何完善。

在拆解完了之后，我们就可以做事件风暴，完成事件命令清单，最终的产物形成子流程图集，完整地构成业务价值识别时的建模逻辑。

可能许多人听说过领域驱动，却并不了解。

简单来说，事件本身代表当前完成的动作和节点，比如“已下单”，代表这个动作已经完成，进入已下单状态。

而命令代表完成这个动作所需进行的动作和行为，比如“已下单”这个动作需要金额计算、金额校对、地址校对等行为来帮忙促成。

这就是命令与事件之间的关系，一种N对1的关系，即多个命令可以完成一个事件。

之后进行建模，主要分三个层次：顶层架构建模、产品领域建模与产品功能建模。

具体有关领域建模的内容可以看看下图，可以通过这样一个模式，基于事件和命令进行解读和聚合。

以这个实例拆解过程为例，首先进行事件分析，在事件风暴结束之后会形成相应清单，后续依据该清单拆解聚合根，了解在领域内应该做哪些能力、解决哪些问题、形成怎样的模块，之后再依据二三级域形成相应的交互图。

最后再来看功能模型。

简单来说，即把之前分解好的业务元素形成相应的PRD，在PRD中，我们要保证逻辑和业务分解时是一致的，这里又会涉及命令与事件，分别对应执行规范与操作流程。

在设计完PRD之后，我们可以再从业务视角将模型还原，从而保证模型不会失真。

数字化的本质即让业务结构化、将人类认知结构化，从而让系统实现更精密的结算，提供更完善的能力。而产品经理就需要在过程中完善认知结构、完善结构化认知。

——————/ E N D /—————

每一年，我们的大会都致力于为大家带来这个行业内的前沿信息、行业动态，帮助大家看到更多领域，发现更多机会，带来可复制的经验、独家的实践案例。

今年的产品经理大会，我们设计了6大专场：行业、技术、产业互联网、用户洞察、商业化、ToB产品。

从多元的角度、不同的领域，告诉你哪些行业有机会，告诉你思维升级的方向，带大家一起看行业，看赛道，看岗位本身的发展，看优秀公司，看优秀的案例实践，找到适合我们自己的方向，提升自身的能力！

扫码即可了解大会详情，前3个专场回放已上架，购买即可收看哟！