Ezpay

数字化平台这个词，在不同的会议上指向并不一样。有人指的是数据中台，有人指的是业务系统群，也有人把官网和公众号都算了进去。口径不统一，讨论就容易各说各话。把顶层设计、技术架构与落地路径分开来看，事情会清楚许多：先想清为什么建、建到什么程度，再谈用什么搭、怎么推。三段里任何一段跳过去，后面都要补课。

一、顶层设计先回答三个问题

一个数字化平台在动工之前，有三个问题绕不过去：它为谁服务，边界划在哪里，由谁负责。为谁服务，说的是给管理层看全局，还是给一线提效率，抑或两者兼顾；划分边界，是明确哪些事由平台承担、哪些留给专业系统；由谁负责，则是牵头的是技术部门，还是业务与管理层共同有助于。这三问答不清楚，后面建得越多，返工越贵。顶层设计不是一份漂亮的蓝图，而是把这几件事在开工前谈拢。谈拢的意思，是各方都认，而不只是会上点了头。

1.1为谁服务

服务对象不同，平台的模样完全不同。面向管理层的，重在看全局与预警；面向一线的，重在随手可用、少填几张表。想两头都占，就要在设计上分清主次，别让每一方都觉得它不顺手。服务对象一旦含糊，功能就会越加越多，谁的需求都想满足，到头来谁都不满意。

1.2边界划在哪

平台不是把所有系统都推倒重建。哪些能力上平台、哪些保留在专业系统里，事先说明白，后续才不至于功能重叠、口径打架。边界清楚，各方各守其位，协作反而顺畅；边界模糊，建着建着就会出现两套并行的账。

1.3由谁负责

牵头的人要能跨部门调动资源，也要拿得到管理层的支持。责任落到具体岗位，进度才有抓手，否则容易停在开过几次会的阶段，谁都在场，谁也不真正担责。

二、技术架构，分层来看

数字化平台的架构讲分层，是为了让每一层各司其职。数据层负责把散在各处的数据汇集、清洗与统一口径；能力层通常被称作中台，把可复用的能力沉淀下来，供上层调用；应用层面向具体业务，按场景搭建；集成与安全贯穿其间，负责对接与守住底线。分层不是说层数越多越好，而是每一层都有明确的职责，改动时能收敛在局部，不至于牵一发而动全身。分层的意义，也在于让每一处改动都有迹可循。

2.1数据层

数据的汇集、治理与口径统一是地基。地基不牢，上层做得再花哨也站不住脚。这一层往往耗时，又不容易被看见，却偏偏是省不掉的一步。

2.2能力层

把反复出现的能力抽出来共用，避免每个业务各建一套，日后维护时四处救火。沉淀什么、沉淀到什么程度，要按实际复用情况来定。

2.3应用层与集成

应用按场景生长，集成负责与既有系统对接。两者都要留出调整的余地，别把结构焊死，给日后留一点变更的空间。

三、落地路径，别指望一次做完

数字化平台的建设，很少有一次性完成的。更可行的节奏是先选一两个价值明确、条件成熟的方向做试点，把数据打通、把流程跑顺，再向外扩展。每一期都设定能验收的目标，用起来之后再看下一步。分期不等于慢，恰恰是分期让风险可控，也让使用者的习惯有时间跟上。试点选得准，往后推起来信心也足；一上来就全铺开，往往头一道坎就没跨过去。试点的选择，宁小勿大，宁实勿虚。

四、几处常被低估的工作

数据治理是其一，口径统一往往比建系统更耗时；权限与安全是其二，不是上线后再补的附件；运维与调整是其三，平台交付之后仍需要人持续照看。这几件事不在功能清单上，却决定了平台两三年后是否还立得住。把它们当作建设的一部分，而不是额外的负担，返工的概率才会小。这些工作做在前面，后面省心；堆到后面，就要用加倍的力气去补。

五、建成之后看什么

平台建成之后，判断它有没有价值，看的不是功能多少，而是几件朴素的事：常用的事是不是更快办成了，数据是不是真的被人用起来了，出问题时能不能在平台上找到依据。如果上线半年，员工仍是绕着它走，那问题多半不在技术，而在一开始的服务对象与边界就没想清楚。定期回看这些实际的变化，比看一份建设总结更有意义。用得起来的平台，才算真有价值。

数字化平台建设，说到底是把顶层设计、技术架构与落地路径三段接起来看。想清楚为谁服务、边界在哪、由谁负责，再按分层思路搭好骨架，用分期的方式推进，平台才可能既立得住、又用得上。跳过其中任何一段，后面都要用更高的代价补回来。判断的标准，终究落在日常是否更顺上。