中台！中台！
分享人：
去年底大家炒作“中台的邪”，现在又
是“阿里去中台化”，你怎么看？
“中台的邪”该文章我曾经参与，也被大家开玩笑说百果园是文章中唯一正
面形象。
今年去中台化又成为了热议，我认为这是一种不对的心态。
看一件事物要看他的本质，中台只是一种方法论，就和中医与西医一样，两
种方法论，你不能把所有错误推到方法论上面去。这也反映了我们国内IT建
设的盲目性和跟风现象，毕竟屁股决定脑袋，你不用最新的流行语，怎么能
从老板那里拿到预算呢？
中台和任何其他新技术一样，首先需要的是人，是组织陪衬，原来是大刀长
矛，现在换成了冲锋枪，你就不能拿起来抡人，而且你还要时刻关注子弹的
消耗与后勤的保障。不做组织变革，一定出问题。
阿里中台有先天的原因和文化的因素，一千个企业有一千种不同的中台，因
为实现的目的、路径不同。
中台的真正价值是什么？如何深度理解对企业的意义？中台是一个技
术系统，还是一个解决问题的方法论？数字中台包含了哪些技术应用
？
中台是方法论，不一定仅用于IT，例如立白，就很好的把中台应用到组织架
构，原来大大小小的事业部，都需要物流，各自寻找合作伙伴，现在通过中
台事业部，把它整合成一个“物流服务”，统一输出服务，不仅提高了效率、
减少了腐败，也进一步提高了服务质量。
中台的思维是一种控制思维，针对70%效率30%创新的企业而言，效果很好，
针对70%创新+30%效率的模式就不太适合，在这种高创新环境下，试错追
求的是灵活，而不是成本。
数字中台这个提法不算太恰当，因为数据原来在企业中没有人专门整体负责
（和外部数据是不同，数据一般有人管理），所以，数据是最容化的，而且
整合了内外部数据以后，价值立竿见影，所以被提到的比较多。
数字中台一般会包含数据治理、数据展现、数据洞察、数据消费四大类
接上一问题
如果我们抛开中台两个字，其实很多成功企业早就这么干了，中台只是在中间
抽象了一层，让这一层的工作更加清晰。
中台的崛起和云端算力突破瓶颈是不可分割的，原来的信息系统，哪怕是最强
大的商用服务器，比如Oracle的ExaData，单台机器的扩充也是有瓶颈的，
而互联网的突发高流量现象，需要新的技术解决方案，这时候云服务器的按需
付费模式，就变成很好的补充，在新的软件技术帮助下，系统第一次突破了算
力的瓶颈，同时按需付费又大大降低了设备的投入。这时候，中台体系就变得
很有意义。
原来我们上一套系统，必须先问清楚，多少用户，多少数据，访问频次，来预
估极限，现在云端算力可以说是无穷无尽，可大可小，因此，可以简单粗暴的
把功能堆砌上去，用的时候弹出新服务器即可。
在SOA年代（中台前身）必须考虑服务的粒度拆得多细才是最佳，细了更灵活
但是效率会降低，现在可以完全不用管这个。
本质上，中台是个对云的深入应用，最大的收益者自然也是云服务器厂商，这
也是为什么阿里大力推动中台的一个原因
企业级的中台有没有非常好的案例？到底解决了什么核心
问题
目前看到，适合自己的才是最好的，不同发展阶段的企业，中台对他来说意
义是不一样的。
就以刚才立白的例子，物流可以变为业务中台的一种能力，同样， 大量的
业务都需要调用会员的信息，会员的资料，调用会员积分的接口，这时候，
他们就被中台化了。
中台在发展的早期，也是很痛苦的，刚开始是颠覆性的鄙视传统信息系统例
如SAP， 把他的功能全部拆成服务，做法简单粗暴，就像一根玉米上的玉
米粒，全部被剥下来，混在一起，结果带来很多问题，后来中台重新向传统
系统学习，提出了域的概念，其实就是把原来的会员系统，称为会员域，把
营销系统，称为营销域，并定义了域与域之间不能互相调用，这样相当于把
玉米粒剥下来以后，重新再排成一排，但是立竿见影的解决了原来服务体系
的混乱，变得可用了。
接上个问题
中台到底解决了什么呢？
个人认为这就和旅行一样，沿途的风景才是最大的收获，在简历中台的过程
中，很多企业彻底的、全新的梳理了自己的流程与价值，所以可以说，上中
台成不成功，本质是企业有没有弄明白自己是什么。
我们的系统是中台架构，对外输出的时候我有三不做，没有明确的足够预算
不做，没有清晰的战略定位不做，甲方没有对业务有清晰认识的高管不做。
因为这三点才是上中台过程中能让企业获得价值的核心。
成功企业不会因为上了中台就更成功，不太成功企业如果能够成功的实施了
中台，那也就意味着成功。
什么样的企业适合打造中台？有没有行业和大小之分？
对于大公司，什么最难？创新！如果能有30%的创新就已经乐开了花。
中台和其他一切相关工具都是为了低成本的创新而存在
ERP：提升业务效率
中台：提升创新效率
成本核算：
投入：足够多的资源投入（外部采购成本：3000万，自研成本：8000万）
损耗：经受得起一定的性能下降带来的额外开销：短期增加30%的性能开销
收益：1%的效率提升、2%的业绩提升，营业额至少要达到50亿才能持平
在普遍实行类阿米巴管理体系下，小企业业务部门分摊的成本有限
对于中小企业，有更简单轻量的方案
经典的中台运营架构图什么样子？能否描绘一下？数据中台、内容中
台和交都是什么关系？
业务中台 数据中台
后
台
进销存 仓储 物流 财务 OA HR
订单中心 商品中心
会员中心 支付中心
营销中心 库存中心
数据业务化
业务数据化
客户画像 门店画像
数据标签
物流中心 结算中心
数据地图
算法模型 数据仓库
人场 货
门店
线上线下一体化运营
精准
营销
千人
千面
APP 小程序 采购 库存 供应链
数字化选品
计划经济与动态销管
第三方
“业务+数据”双中台打造水果零售行业的数字双引擎
接上一问题
简单的说，中台提供了两种能力，随心所欲而不逾矩
1、针对业务：想要什么数据，立刻就可以得到什么数据
2、针对开发：想要怎么复用业务流程，就可以怎么复用
这两点支持了创新，这就是中台的核心价值
打造中台的步骤怎么样？企业如何一步步展开部署？要点
是什么？
1. 组织变革与陪衬
2. 明确清晰定位自己的战略
3. 确认自己未来的收益
4. 数据治理，建立数据中台
5. 业务流程清洗（EPR企业流程再造）
6. 建立不同的业务域，构建业务中台
7. 前台对接匹配
8. 按SAP的说法，以上都是为了敏态业务服务，而财务等稳态业务无需纳入中台，
而我认为这只是时间的问题，一定程度上，稳态业务也可以通过中台化进行优
化，只是长，风险较高，收益较低，是一个值不值得做的问题而不是该不该做
的问题。
企业在打造中台的过程中，如何进行组织变革？人
员和岗位要求怎样？
这个问题太大了，但是有一个更加重要的前提，我在中台的邪里面提到了，
企业文化一定要匹配，一个企业如果各个部门本位主义严重，个个只想着甩
锅，那一定无法成功，需要强有力的领导和深入了解全产业链业务的高管，
最后，还要有充足的预算。
最低配置，5～6个架构师，20左右的产品经理（懂业务的），开发如果是
外包，人可以少一点，如果是自研，老板不可能一个中台上2年，所以根据
业务的复杂程度，需要匹配一年内完成开发工作量的足够的开发人员。
企业数字中台的运营能力体现在哪些方面？中台的运营是
否体现在对数据能力的掌控上？为什么？
效率、效益、创新
互联网的开发都是小步快跑，企业未来也会需要这样的迭代方式，中台能否
服务好他们就是中台的评判标准
数据只是其中一个方面，但也是最重要的方面，毕竟数据能否清晰透明，随
时掌握了，企业主就不用拍着脑袋做决策，成功概率会更大一些。有的时候，
你只要跑得比对手快就够了。
中台的运营，可以做一个简单的模拟， 你今天经营的产品出了重大问题，
那么，你手里有1000万的会员，你能用多快的时间给他们提供新的品类的
产品服务？比如你是星巴克，突然咖啡绝种了，你要改卖面包，你的整个体
系需要多久，你的IT系统需要多久？在新零售和疫情的双重夹击下，其实这
个问题已经在每天拷打着各行业的老板们，这才是中台的核心意义。
接上一页
我的回答是这样，你首先需要数据中台，对你的消费者做出全面的分析，哪
些是只愿意在你这里买咖啡的，哪些是愿意尝试你的新产品的，他们有多少，
在哪里？消费能力是多少？然后你再根据这个数据来设计新品，重构供应链，
这时你的业务系统如何与上游对接？你的新品类的销售模式可能也和原来不
通，这时候你怎么改造业务系统来完成你的交易？这些才是对中台的挑战和
价值体现。
这个问题做完了，我们回过头来看，哦，现在咖啡还没有绝种，那么这个想
象中的新品类，是否能够加入我目前的体系中来，给我企业带来新的增长点
？这如果可以，恭喜你，你又可以带领企业上一个新的台阶，着就是一个创
新的完整过程。
数字中台部署成功的要素是什么？标志是什么？一
般需要多长时间？
开会的时候没有几个部门在争吵说你的数据对还是我的数据对了
数据的展现可以自动化了，比如针对某个新的经营主题，大家都很关注，那
么是否能够很简单的建立一个自动化推送，如果可以，那就再加一分
数据中是否能洞察出企业发展的危机或者机遇？可以，那就再加一分
数据能够让一线的业务人员更方便的访问，并且整合到他们的日常操作中去，
并且不会随着业务扩越慢，可以，那就再加一分
数据这么方便了，是否足够安全？安全，那就再加一分
数据的价值就是在这一点一滴中积累起来的，成功其实永无止境
一般至少1年的时间。
部分常见问题交流
部分常见问题交流
1. 数据中台的建设思路、规划和建议【是否加智能属性？该如何规划数据中
台和算法中台，是先建设BI，然后优化，然后加智能算法，还是其他】
2. 数据中台，甲方的项目团队建议
3. IT系统架构的建议和介绍【业务中台，数据中台和算法中台】
4. IT团队的建设及组织架构建议（略）
5. 甲方IT团队技术选型【技术中台介绍】（略）
数据中台的建设思路、规划和建议
中台是一种方法论
中台的目的是高效复用
中台变革必须优先建立组织陪衬
先后顺序：
数据中台——快速看到问题，建立数据治理规范（强与弱）
业务中台——为解决问题、执行流程的组织提供高效的服务
算法中台依托于数据中台，可逐步完善
IT只是工具，IT的设计、规划，都必须服从于公司的整体战略，应该优先考虑的
是要什么？为什么要？技术要解决的问题是什么？
希望IT能够帮客户解决哪些问题？
零售客户认为IT的范围和边界是啥
客观认知：存、取、计算
主观认知：我想控制的利益外的工作
希望IT能解决哪些方面的问题
第一阶段：和电脑有关的重复操作
第二阶段：人力无法触达的细致操作
第三阶段：大数据洞察
如何验证有没有达到效果
拆细、分阶段
IT领先业务半步，提前订出衡量标准
特别注意细节、借口
中台不是万能药
什么特征的客户群关注中台：
中台的价值对于中小型客户不高，需要有业务模型构建能力
中台可以参照当年SOA架构的适用者
中台适用于领跑者：
中台需要有良好的企业文化作为业务落地的支撑来体现价值
大量业务模式需要探索与改变，有一定IT能力（中台主要解决了复用和性能问题）
对于大型企业，中台的短期目的是
IT不拖业务后腿
IT能够创造额外价值
IT不会短期遇到性能瓶颈，可以平滑扩充
不同的客户眼中的中台及要求
同样是买一辆车，不同用户有不同的核心诉求：
只是要一辆车
要系统：价格和别人差不多，别人有的我也应该有
要一辆跑得快的车
要流程：别人能跑多快，我应该也行，关注业务流程在系统中的实现
要一辆合适的车
要价值：注重车辆各个部件带来的能力
要一辆能送我到达目的地的交通工具
要引擎：关注能否适应我的需求，能否按需定制
IT思维与老板思维的不同：拖拉机VS 种什么
数据中台很重要，但只是一部分
1. 数据是不是对的？（准确问题、合规问题、时效问题）
2. 数据所触发的流程是否是合理的？
3. 流程触发的执行是否是正确的？
对于大多数零售企业，在努力回答第一个问题，在归纳总结第二个问题，在靠
惯性操作第三个问题。
数据的外层是流程，再外层是执行
零售业的困惑是人引发的某省市场变化引发的异常
数据用于发现异常、预测未来、指导干预结果
流程是选择快速准确解决这个问题的方法
数据的细分
数据有两层：
1. 数据：业务数据，流程清晰即可定义
2. 外部数据：精芜混杂，人的经验、精力不足以解决，
AI是过渡，因为普适性和效率不足
解决问题只是最简单的条件反射，发现规律才是智能的本质
目前的数据中台的建立
1. 收集外部数据，基于留痕与轨迹数据量较大
2. 元数据规整，大约1-200个元数据，数据量适中
数据中台：解决数据存在哪里、怎么存、怎么快速取出
3. 通过BI、报表等建立一线的基础反射
中台是一种方法论
开发、思维模式发生了巨大变化，要把后背交给别人
传统模式 中台模式
性能VS功能 优先考虑功能，然后是性能 优先考虑全弹性，然后是复用
分解逻辑 顺着流程向下分解（纵向） 基于服务单元进行分解（横向）
业务关系 基于表单任意跳转关联 基于域进行限制
开发模式 一个人（组）可以做完一整条线 分层开发，各司其职
瓶颈 数据库性能，可扩充 网络带宽、弹性效率
IT管控 多系统运维 整体控制
重点解决问题 业务部门内规范 跨部门规范
理论基础 老三论：系统论、控制论、信息论 新三论：耗散论、协同论、突变论
设计要点 别出错 别失控
实施问题 一定要按流程执行 信任、错误数据如何回滚
从流程分解到服务单元分解
中台的风险
对于大公司，什么最难？创新！
中台和其他一切工具都是为了低成本的创新而存在
ERP：提升业务效率
中台：提升创新效率
成本核算：
投入：足够多的资源投入（外部采购成本：3000万，自研成本：8000万）
损耗：经受得起一定的性能下降带来的额外开销：短期增加30%的性能开销
收益：1%的效率提升、2%的业绩提升，营业额至少要达到50亿才能持平
在普遍实行类阿米巴管理体系下，小企业业务部门分摊的成本有限
对于中小企业，有更简单轻量的方案
不要被中台绑架
中台的问题
能说得清的人不多
投入的成本高
短期不能快速解决实际业务问题
作为一个简单粗暴的方案，还有大量优化的余地
第三方开发的风险上升：模块级——系统级
引入第三方的成本增加：额外的中台开发接口
未来基于中台的业务创新技术方向：
从数据—>应用—>算法 逐步递进
全数字化空间和自主行动者建模（Agent Based Model）
AI 预警、预测
甲方的项目团队建议
系统建设，架构优先
建立本企业的架构及技术标准与规范
系统建设，流程先行
懂系统、懂开发、懂业务的团队
系统建设，落地为根
再好的系统，必须有一个清晰的落地节奏，综合考虑到切换的风险、人员及组织
的匹配、培训的效果、系统的安全等多个方面
A模式
“立白集团”作为例子，立白集团外部咨询顾问历年总费用累计近5个亿，每年
IT投入2个亿，虽然立白集团的IT建设也走了一些弯路，还是卓有成效
目前立白采用的方式是：建立一个50人左右团队，一小半是架构师，负责整体
把控架构，任何开发商都必须在这个架构框架下开发，另一大半是产品经理，
他们与业务深入沟通，保证开发出来的系统能够“更好用”，能够真正的解决
问题，同时，产品经理也要负责功能的流程落地与协调，毕竟每个部门都有自
己对系统流程的考量，需要一个协调团队来评估与整合。在这种情况下，外部
开发商才能真正的和企业协同、协作。软件的均由立白拥有，一步到位的解决
了源代码问题与后续开发问题。
优点：部门成本低，商务合同规避风险
缺点：整体成本没有降低，对第三方依赖度较高
B模式
百果园，因为水果产业过分孱弱，国内外均没有任何可以参考的例子，因此
自建全套开发体系
600余人，服务于：ERP、电商、金融、物流、营运、营销、质检、种植等
各个环节，以保证最后的出品质量
好处：前期试错成本低，创新容易，业务部门容忍度高
缺点：成本投入较高，未来庞大的IT团队必须有持续的收入来源支撑，劳务
合同替代了商业合同，风险较大
