系统|从供应链中台的故事说起，聊一聊中台的本质和设计之道( 二 ) safari|ipad|os|Safari浏览器|漏洞

文章插图
中台的搭建就像造航母
在日常工作中，中台主要解决如下几方面问题：
1）底层能力的复用，降低业务与系统成本。
当多个业务都需要供应链能力时，将已有的供应链业务和支撑系统进行升级，使其能同时支持多个业务方，通过复用的方式同时降低业务成本和系统研发成本。
2）把复杂的底层能力对外简单化、透明化。
供应链本身就是一个庞大且复杂的体系，自己人尚未能完全理明白，更别说让业务来理解了，但业务又必须用到供应链的能力，如何是好？这就需要供应链中台来转化了，供应链内部可以很复杂，但通过中台转化后提供给外部业务部门时必须足够简单明了，否则就不是一个好中台。
3）将多点对接的网状结构变为单点对接，流程更清晰。
无论是中台的部门还是中台系统，都是多组织形态的，任何一个业务如果单独对接采购、仓储、配送等部门，成本都会非常高，会变成一个多对多的网状结构，而供应链中台则可以作为下游供应链部门的一个统一门面对外，将多点对接变为单点对接，流程会更加清晰，难度也自然降低了。
4）关键信息聚合。
中台建设的另一个目的是将关键的信息做聚合，而不是散落到各方，这样当需要数据时，就能够从中台直接提供，而不是从各个系统里去提取了。
三、中台的本质：沉淀+复用说起中台，可以很复杂，复杂到涉及十多个部门，几十个系统，几百号人之间的相互协同，同时也可以很简单，简单到用两个词就够了：沉淀+复用。
1. 沉淀输入中台需要将一些可以复用的业务、功能和数据尽可能沉淀下来，不要让每个业务自行实现，否则是极大的浪费，还会增加业务的接入成本。例如X公司有多个仓，针对商品的库存管理功能，如果A业务有，B业务也有，C业务也需要，那就应该考虑放到中台来集中实现。
但所有的能力都应该落到供应链中台吗？
当然不是，供应链中台的搭建目标并不是要替掉业务方，而是让业务能更好地开展业务，不被后端供应链所拖累，所以最佳合作方式是划清边界，一起共建，原则上只将相对稳定且比较通用的的能力落到中台，而个将性化的业务逻辑交由业务自由发挥，具体实现时可根据具体情况具体分析。
同时，中台能力的沉淀绝不可能一蹴而就，它一定是一个慢慢积累的过程，很多能力在尚未成型时更加适合放到业务侧去，等稳定成熟以后再落到中台。
2. 复用输出随着中台沉淀的能力越来越多，就能够给业务输出更多的通用的复用能力了，包含流程层面、人力方面和系统层面。
拿X公司的采购业务来说，无论有多少个业务平台，都可以共用公司的采购的流程、采购部门的人力和采购系统，在这种情况下，采购部门充当的职能就是中台的角色，将采购的能力集中化输出，满足各方采购诉求。

文章插图
中台的本质：沉淀与复用
中台能力的输出好坏取决于沉淀的多少，如同做蛋糕，可使用的模具越多，就能做出越多不同的图案样式，如果沉淀不够，自然就会缺东少西，业务接入也会坎坎坷坷。很多中台在搭建之初效果不好，让业务感知不好用，原因就在此。
所以，搭建供应链中台请一定多一些耐心，要相信，随着沉淀的慢慢增多，中台输出能力会越来越强，业务的接入也会变得越来越简单和顺畅，也更加愿意接入和向中台沉淀，最终形成良性飞轮效应，让中台的势能和价值发挥越来越大。