读完这本书后，最大的感想就是抽象能力。
我们平时面对各色各样的IT系统，其实就是不同业务需求背景抽象的结果；我们讨论管理组织架构，也是对团队的责任能力要求的抽象结果；任何事物没有对与错，只有合适不合适；
行业发展：互联网颠覆变革
简单说就是互联网已经把C端的用户玩熟玩透了，从交易维度去挖掘客户已经变得效益不高了。希望利用互联网的中台玩法来给供应链企业赋能，加快产业端的发展；
差异：
互联网做产品推广客户群将成本摊薄的打法在B端却失灵了；
B端用户要求高，变化大
B端状况，同行业不同企业都各不一样
中台是什么？
前后台弊端：
中台的诞生：
面临困境：
C端中台：
用户总群体开发饱和，企业之间进行零和博弈；需要进行用户精细化营销，打开市场；
B端中台：
中台是否创造收益？是否提效？是否有利传播?
需要有ROI的思维：站在客户角度思考自己产品的适应性；
MVP的敏捷试错模式对B端企业无效；
业务中台
需求分析：
行业分析
针对行业的宏观市场分析，产业链的预判；
使用商业分析画布，来对企业的运作模型，怎么赚钱的问题想清楚；
最后把中台在企业的适应性与客户调研沟通；
注意点：
独立中台研发团队：
从业务先抽离的团队，就像一盘散沙。永远不会有时间做中台事情；
适当的实际业务经验是友好的，但是容易陷入老旧思维陷阱，抽象深度不够；
必须有高管介入支持，责权清晰
清晰需求边界：
满足可复用，标准，可赋能的原则；
分清业务中台和数据中台边界；
需求分析办法：
演绎法：对未知需求进行演练分析，以客观的形式进行事实反馈，适合自上而下的数仓建设；
归纳法：对已知业务进行归纳抽象，适合自下而上的数仓建设；
业务标准化
组织抽象：中台团队的抽象，比如测试团队的共用&拆分。前台团队的抽象，中台团队的整合；
业务抽象：站在全企业设计的高度，对企业业务及流程进行抽象；把整个公司视为一个产品，然后抽象产品主体，标准流程，运营后台；
流程抽象：对企业流程进行分析拆解，然后对其重新抽象组
数据中台
解决什么问题：
缺少完整的指标体系辅助企业决策；
各业务线搭建了自己的数据团队和数据分析平台，需要解耦；
搭建全企业完整的指标体系：
战略指标：全公司战略统一的目标，如：GMV，NUA，用户数；
战术指标：各部门或业务线的为达到战略目标的延申任务目标，如：总订单量=支付订单量+未支付订单量。
行动指标：包含业务行动定义具体部门需要达成行动的任务目标，如：转化率；
互联网搞很多活动通常每个活动都会有对应的系统，每个系统都会独立的会员模块，订单模块。导致了从企业角度的冗余；每次上新活动都相当于开发一个新系统；
为了解决效率问题，将业务抽象成模型（或者更细的业务流程）而不是系统；通过中台的配菜，完成统一管理，系统的快速实施；
PS：在这里会有一种错觉，作者把传统BI实现的指标体系描述成了数据中台。但其实我觉得指标体系要搭建是对的，中台要打破各自为战的数仓和数仓团队更是最重要的。
