中台，是我进入这家零售公司后第一个从0到1谈得上规模的产品，眼看马上又一个财年了，才有开始动笔写下来的动力，只为给自己一个成体系的交（感）代（动）罢。
最初并没有做中台的想法
这事得从2018年7月说起，当时了解到某一品牌商品的损耗一直居高不下，这个品牌商品的货架天数就一天，当天无法售罄就会报损。门店一般会安排人力巡场跟踪库存，再依据经验判断何时进行促销，这带来了巨大的人为操作空间，管理水平不那么高的门店往往做得很差。我们很快确定了用打折手段促销降损的方案，这有了最早“从监控到执行”的雏形，始祖版产品于2018年9月发布。
始祖版实现了业务链路自动化
项目核心思路是用系统方法替代人力的低效和人脑的不确定性，在产品上我们与数据团队协同，主要完成了指标服务化、预警规则可配置、待办任务三个能力的建设。为了验证可行性，从发布至2019年1月期间，我们利用这个产品计算所有门店的数据，但不下发任务，通过比对模拟预警、实际打折和是否售罄的关系，测算出系统决策正确率高于人工约50%。
中台是在2019年初被正式推向舞台的
年初，公司提出了提升门店员工效率的大目标，通过合理排班、混编用工、薪酬激励来提升工作饱和度，这意味着线下作业需要被数字化，各条垂直业务的共通点需要被系统沉淀，建设中台是一件看起来一劳永逸的事情。
我们在4月完成了产品重构，这一次的设计，和前一版相比，是思维方式的变化：
1、结构化了作业链路（下图四步骤）；
2、可接入外部服务实现触发或决策；
3、配置集中化管理。
重构版抽象出了触发、决策、找人三大模块
然而此时，仅仅是表面的风光
新的垂直业务接入之初，遇到了特别多方案迟迟无法达成一致的情况。中台建设之时仅有打折一个落地案例，在评审新的垂直业务后，往往会发现中台现成能力不足需升级，任何项目一定是以业务目标为第一要务，这使得业务团队不可能损失效率迁就中台。中台团队希望用标准约束业务，而业务团队只要平台能提供需要的服务即可。
盘点业务是个较典型的案例。业务需求是：各品类商品按特定周期实施盘点工作，每一项完成后根据盘点差异决定是否需要复盘，对于门店员工来说，只需要从手持设备待办列表中领取、完成任务即可。两个团队提出了各自的解决方案：中台团队倾向于表达“执行到决策到再执行”更贴近原始需求的流程，但这里产生了一种新的结构模式，需要升级平台；而业务团队认为，决策逻辑由业务系统实现，业务系统来驱动流程就能满足需求。
两个方案其实是理想和现实的PK
经历这些事，我常常思考中台应该如何去演进发展，在现状下出现了两条截然不同的路径：
一种是以中台建设为主要目标，以赛代练，逐步打磨能力，但这样做的坏处是（很有可能）拖累业务，在相当长一段时间内，中台的存在会付出降低效率的代价，而这个时间的长短取决于团队能力、业务变化度、系统复杂度。
另一种是只保证数据结构的统一，用简单框架满足业务为优先，设定中台阶段性目标，当做了二个、三个时可能积累还不够，但做到第四个、第五个时一定会出现需要沉淀的共性，阶段性地做一次升级、迁移。这样做的缺点是更多的IT成本。
路径没有优劣，只有适合
前一种路径，最好有一个大团队，统一目标，前期专注于“赛”，中期逐步分出一个独立小团队开始“练”，后期并行。后一种路径，中台团队需要一个很好的介入时机，中台本质是总结前人经验带来提效的IT方法，需要多个业务的场景输入，当公司只有一个业务时，想做出中台是很困难的。
我们后来选择了第二条路，用低成本方案在5-7月间陆续上线了6条垂直业务，并于8月启动了中台的一次大升级。我们在这次升级中专注于把各角色的职责关系定义清楚，主要做了三件事：
1、可视化的流程设计器，把「流程应该是什么」的工作交给业务产品；
2、流程节点被抽象定义，可被复用，需要新的由中台后端技术开发；
3、配置组件被抽象定义，可被复用，需要新的由中台前端技术开发。
升级版明确了各角色的职责
对于中台团队来说，技术能够专注于中台能力的建设，成果可被复用，如果一个业务场景没有特殊性，中台技术就没有工作量。中台产品的职责在这个阶段仍旧需要向业务倾斜，协助形成业务数字化的最佳实践，但和业务产品会有明显的分工。
业务产品和中台产品的分工与合作
中台的这次升级花了约4个月，于2020春节前完成发布，期间又接入几条业务后，在中台上运行的业务已达10+。
写到这里，差不多到尾声了
而中台的建设还远未到头，从产品视角看，我们下一阶段会专注于业务支持、能力建设、应用分析三件事。
1、垂直业务目前分别跑在中台两个版本上，维护成本很高，迭代需求若要在老版本上开发，等于double的工作量，后续需要加快向升级版迁移的进度，同时赋能新业务也不能停；
2、目前业务接入成本集中在开发新的配置组件，我们正在考虑开发一个组件设计器，让业务产品能独立定义组件；
3、基建完成后就得考虑如何使用这些数据，目前应用分析层还未来得及动工；
……
如果面对中台「有没有价值」、「应不应该做」这样的问题，我想我会回答：
中台是一种服务共享，是总结前人经验带来降本提效的IT方法。
中台作为横向的基础产品，研发质量会得到更多的保障，试想中台服务若挂了会波及多大的业务范围。
中台的可持续性（除了团队能力）非常依赖于高层支持和组织架构保障。
中台在初创期容易拖累进度，和业务KPI难以达成平衡，甚至是反KPI的，以至于会受到更多挑战。
中台在选择支持哪些业务上是存在风险的，如果相比成本和质量，业务更在意速度，那么是很难说服业务产品加入合作的，这和中台本身的定位也是有矛盾的。而“初生”业务不稳定，容易把平台带偏，也有可能活不了多久就被砍掉了。
网友评论