前言
企业数字化转型的关键在于以平台思维构建系统，意思就是要给存在相互影响和依赖的双边和多边群体提供一个空间（或系统），满足不同群体在这个空间的利益。
在这个转型过程中，以下十大要素是这个平台思维的重要组成部分。
要素一：业务全局视角贯穿业务链
首先，各个业务系统都是从系统所属业务主导方的视角构建的，缺乏全局视野，容易由于数据标准、格式不一致导致出现数据孤岛现象。另外，因为业务系统本质上还是不同业务部门从自己局部角度出发而建设的产物，因此系统间所产生的联动成本高本身也是“部门墙”的直观体验，对创新所需的灵动和高效协同是一种极大的阻碍。
因此，业务中台的建设就起着核心作用。我的理解是业务中台就是由一堆的服务中心所组成的（例如我们IT规划中的互联网中台就是由营销中心、用户中心、产品中心所组成），同时这堆服务中心又分别由一堆系统或者一堆微服务所组成（例如营销中心则由券码服务、支付服务、订单服务等一系列服务所组成）。这些对外提供能力的中心跟我们平时建设的系统功能模块有本质的区别。区别在于它们是向所有的前台业务场景或条线提供服务的，因此它们是业务无状态性的、原子性的、租户隔离的。
要素二：构建支撑业务优化的数据链路闭环
虽然同业也意识到数据的重要性和大数据的价值，但实际上在很多企业的IT组织架构里面基本一个部门负责系统建设，一部们负责管理数据，容易因为对业务的理解不一致导致难以实现数据驱动业务。
为了避免系统与数据的割裂，可以通过业务中台和数据中台共共同构建起企业数据闭环；其中业务中台负责讲一切也数据化，数据中台负责将一切数据业务化。这里要简单介绍一下业务中台和数据中台的功能。
业务中台的定位主要包含以下几方面：
1、业务场景覆盖2、用户触点汇集3、交易处理支持4、数据高效生成
数据中台，它的核心定位应该为标准的、可复用的数据资产库。按书中所说，它应该分为三层：
垂直数据中心、全域数据中心
和
萃取数据中心。
按照我的理解，映射回银行的数据系统。垂直数据中心应该是指从各应用系统抽取数据后的数仓贴源层等。全域数据中心更像是根据某些业务主题构建出来的指标层或指标库；萃取中心更是围绕以核心业务对象（例如持卡用户）的的综合画像数据（即客户标签体系）。
在数字化转型的新时代，我们不能再像过去一样，先进行系统功能建设再进行数据管理分析功能建设，而是要从一开始则准备数据闭环的全局思维进行整个闭环能力的建设。
要素三：以用户体验最佳为重要原则
数字化转型的其中一个核心就是要从以前的以产品为中心转向以客户为中心，细一点讲就是以满足客户需求为中心。因此，追求用户体验的极致是一个极其重要的任务。
简而言之，就是要从业务需求和用户体验的角度来说，用户访问终端渠道需要多样性，而且所谓的多样性不是指我们传统的以项目方式所建设出来的烟囱式的互相割裂的一个个系统，它的多样性要体现在能够满足用户在不同场景通过融合各系统的能力在更好的解决当前遇到的问题，说得俗一点就是要通过整合不同系统间的数据去了解客户当前的需要，通过整合不同系统间的能力去实时满足客户当前的需要。这里什么意思呢？举个简单例子，当有个客户在信用卡APP浏览其月度账单而且曾经点开过账单分期的页面（但停留了一会最终还是离开了页面），当系统通过画像数据发现其是分期客群且最近几个月的额度使用率较高，系统能够预测评估客户离开的一个可能原因是觉得费率太高，从而系统能够自动触发推送费率折扣的推送给客户，或者说当客户登录到该银行微信公众号首页时候系统自动推送费率折扣的优惠广告。
那映射到系统建设层面我们应该如何做呢？从架构的视角，我们就要把应用系统进行三层架构设计（具体可以参考下图）。
1、产品共享服务层，它从产品应用的全局视角分离出多个产品都需要的公共功能，以服务方式向上次提供支持；2、产品服务层，它主要包含单一业务场景下的功能；3、前端交互层，它的责任在于针对用户终端所需的数据和功能，将下层、产品共享服务层、产品服务层中的这些服务进行组合和处理，并返回到客户端。
经过三层的进一步解耦，实际上复用的能力得到进一步的提升，除了产品共享服务层外，实际上产品服务层也能提供一定粒度的复用。例如，产品服务层中电商服务的物流跟踪既能服务上层营销/运营这种2C业务流，也能服务物流供应链这种2B业务流，且数据是一致的，这样对用户来说就是一致的体验。
要素四：提供复用能力支持业务快速创新
在现今这个快鱼吃慢鱼的时代，一家企业是否具备核心差异化竞争能力是在于这家企业是否具备更强的业务创新能力。那怎么才能具备强劲的业务创新能力呢？那其中的一种途径就是进行中台能力建设，把企业各种核心能力进行抽象封装成具体的“积木”，改变以往信息系统从零搭建的方式，而是通过组合不同现有的“积木”的建设方式，将以前的系统建设从“冷启动”变成“热启动”，才能最大限度提升交付效率，给业务的快速试错提供技术支撑。
因此，我的理解是中台的建设是数字化转型的一个重要组成部分，业务数字化转型的重要建设目标。（具体关于中台建设的讨论可以参考我的另外一篇文章
中台建设落地浅谈_justyman的博客-CSDN博客
https://blog.csdn.net/justyman/article/details/114477257?spm=1001.2014.3001.5501
https://blog.csdn.net/justyman/article/details/114477257?spm=1001.2014.3001.5501
要素五：支持业务上下游企业的网络协同
数据的价值会在共享中得到提升，而提升的数据价值在很大程度上取决于数据被共享、开放的范围。当一家企业内部的数据共享机制做得足够好后，为了实现效率和效益的持续提升，一定会对生态链的上下游进行数据共享，以便进一步提升生态链的效率。
对于如何支持上下游企业的网络协同，业界有两种主要思路。
- 很多大型互联网公司，他们讲企业自身需要开放的数据以服务形式对生态链上下游进行开放，然后引导上下游企业或组织与自己形成联动，继而集成到自己系统以便达到更高程度的交互协同。但这种方式相对比较单向，具体要看哪一方比较有话语权了。
- 另外一种就是直接给生态链上下游企业提供SaaS服务，以数字赋能的方式给大家带来更多价值。当然这种做法一般只适合那些在行业中有较大话语权或占有率的企业，就是它有足够的数字化能力，也有进一步提升协同效率的诉求，然后肯定要把这诉求诉诸于生态链的上下游企业，通过提升全链的效率的方式帮助自己提升效率。
要素六：支持多个开发团队协同共建
数字化转型本身就是面向全链路或生态的数字化建设，因此它一定不是只靠某一个团队实现的，而是靠多个团队互相协同而完成的。因此，需要在流程、规划和规范上进行相应的统一。
从上图可以看出来，整个链路应该分为业务中台层、数中台层、产品共享服务层、产品服务层和前端交互层。不同团队间的功能和运营边界要清晰，我的理解是不要有重叠。从业务全域的角度看，需要分别针对上图各层构建业务运营体系，各个团队在对应的运营平台上进行日常运营，同时也基于该平台进行线上的高效协同，这是流程规范的问题。
另外，因为中台也是不断演进的，为避免后期各团队的天马行空，需要从系统架构设计、产品设计和产品开发这三方面进行定义，具体如下：
-
无论后续要建设什么功能或系统，一定要遵循上面的分层规范；
-
在产品设计阶段要综合考虑各个运营平台的分工和用户终端的体验，既要实现不同团队的独立运营，业务保证最终的用户体验一致。
-
建设好平台相关的规范（鉴权规范、接口设计规范等），确保多团队在产品开发过程使用统一的规范，做到降本增效的效果。
要素七：支持用户个性化及业务扩展需求
每家公司有不同的部门，每个集团也管理着不同的分支机构；它们之间的诉求不尽相同。从全公司或全集团角度看，希望集中资源建设，提升联动效率，避免各自建设系统带来的业务系统和数据不统一的问题；从部门或分支机构来看，因为有各自个性化的诉求，如果要求业务迁就系统，反而因为统一建设而影响业务高效开展。这种问题在企业中十分常见。
其实，数字化转型必须要解决这个不可避免的问题。那如何解决？实际上要做的就是如何满足用户（不同部门或分支机构）的个性化需求及业务扩展性的问题。那具体应该如何做呢？
1、建立租户隔离机制
采用租户隔离机制，保障每个用户的数据都是隔离不可见的。但是租户隔离要解决以下几个问题：
-
租户和平台间的数据共享；
-
租户间的数据共享；
-
数据跨租户间的流转。
2、基于中台架构实现共性和个性的分离
从宏观角度看，业务中台建设的本质就是共性与个性的分离。
3、业务可扩展框架支持业务场景个性化需求
我们在做服务设计或微服务划分的时候的原则就是做到服务能力内聚。但是在很多时候我们做设计服务中心会遇到一些比较棘手的问题，例如我们建设订单中心，一开始可能是比较简单的功能（锁库存 -> 订单创建 -> 扣库存），这里我称之为“原子层”，但后面随着各个渠道的接入，也因为不同渠道的特殊性会要求订单中心在之前的“原子层”上再加入额外的功能（例如如果对接第三方的话，可能要推送订单状态下发给第三方），这里就不得把这些功能进行编排封装成一个更大粒度的服务，这里我称之为“聚合层”。但是随着服务中心的数量越发增多，你会发现这对于中台开发人员将会是一种效率和成本上的考验。当然你可以说这个是渠道特性应该是渠道开发自己解决而非中台开发，但是如果这个特性是几个渠道需要具备但又不是所有渠道需要的呢？那究竟是渠道团队自己重复开发还是中台团队开发呢？
其实，解决这个问题最好的应该是提升中台的开放性。即既保证中台的稳定性（对共性封闭），又提升中台的灵活性（对个性开放），具体的做法是：
4、基于功能市场实现用户体验的“千人千面”
针对同一个系统或者产品，不同角色（含用户和客户）所关心和需要的服务都是完全不一样的。举个例子，在线上商城，客户希望看到的是琳琅满目的商品与对应的折扣，而运营则更希望看到目前的订单状况和活动运营情况。哪怕同一个角色在不同终端希望看到的也不一样。再举一个，运营在手机终端希望看到的是一些总结性或分析性数据（例如订单总数），但是在PC端则希望看清每个订单的明细（特别是一些有客诉的单）。
这样就要求企业在构建自己的平台时候应该是以功能作为做小建设单位，而非系统本身。这也是跟中台中的服务中心的概念不谋而合的，该平台一定要对所有以功能为颗粒度建设的服务进行“原子化”管理，并支持不同角色用户的按订阅模式进行使用，这样才真正是基于功能市场实现用户体验的“千人千面”。
要素八：团队从项目制建设为主转向数字能力产品运营
传统的项目制建设模式有以下弊端：
1、系统扩展性从来不是必要选项，无论是以上线验收为目标的项目还是驻场迭代式的模式，它所交付的系统或功能模块终究会带来扩展性不高的问题，究其原因正是所有的一切为系统上线和验收为目标，而不是以持续运营为目标，这是项目制的“原罪”；
2、项目制模式不能持续式的满足业务增长的需求，而应该要采用响应更快的“切香肠”式的迭代模式不断试错，通过持续性“喂饱”业务方去填平业务与IT的鸿沟。
3、项目制不利于人才培养，因为项目结束后人员就会被抽调至其它项目，如果是同类型的项目还好，否则很难在同个业务有较深的积累（谁敢保证自己未来几年的项目都是同一个业务类型呢？），这对于企业和个人都是不利的。对企业来说总是培养不起来既懂技术又懂业务的人才，对个人来说永远是个工具人。
反观，以产品运营的中台建设模式，却有助于帮IT培养业务专家，毕竟该中台的运营人员或开发人员在日常工作中会面对全公司所有业务场景对该中台服务的需求，这样就会迫使它们以全局视野去支持或满足业务，从理论上就帮助人们构建起整个面的认知体系，这假以时日就成长为在该中台服务（或领域）的专家。
要素九：支持基于能力开放的外部合作伙伴生态共建
企业数字化转型发展的趋势是能力的开放。在这种利他的平台建设上不能过于强调管控，而应该开放心态吸引合作伙伴。当企业将本身的核心能力通过平台进行开放，合作伙伴呢的业务数据也回回流到企业中，为更好的为企业沉淀行业级的数据能力。
要素十：从职能型组织架构向业务导向型组织架构转变
企业的传统组织架构导致所谓的“部门墙”问题，这种现象映射到IT系统层面则会出现早期的业务系统建设均围绕具体业务部门的需求而来的，这就是导致烟囱式系统不断丛生的根源。当然，这合乎当时的“司情”；确实，公司在早期的核心是要生存下来，唯一的要求就是要从零到一的快速投产，而不是坐下来慢慢论证究竟数据怎么拉通，功能怎么复用；这个是有点勉为其难的，企业明天能不能生存下来都不知道，惘论说数据拉通或功能复用的问题。
随着业务的发展，这个问题是一定得解决的。根据书中说讲的，组织架构可以遵循以下3个原则：
1）数据透明共享；2）业务导向；3）组织认知统一。
首先，对数据进行共享透明不单单可以降低信息获取成本，同时可以提升团队协同效率。因为当数据共享后，人的潜能就可以得到释放。为什么呢？因为，不同的人处于不同的角色，对整体数据有着不同的解读，这样可以让团队可以迸发出创新或高效的idea。第二，数据信息的不对等被得到很大程度的解决，每个人都会被得到信任并会认为自己是数据的共同owner之一，这样的话人们不仅愿意承担工作上的职责，也会不断寻求更大的责任，这对团队或公司来说都是有利的。
第二，我理解的业务导向是要建立一个矩阵式组织，即把围绕同一个业务目标的不同专业的人组合成一个实体或虚拟组织，它们为着共同的业务目标高效协同工作，这有点类似业务敏捷背景下的从产品、BA到开发、测试的全功能团队。
第三，组织级认知统一。组织确定企业愿景，中层基于这份愿景进行目标分解，基层负责执行落地。在这个过程中，愿景越往基层传递，感知越弱。因此，需要企业领导者带领团队将目标进行明确和细化，不单单只停留在无数次会议的口头要求上。