中台实战：万能的中台MSS建设框架
众所周知每家企业对于中台需求都是不同的，可以说中台建设属于千人千面，但是在中台建设中还是有一个通用的方法论可以参考进行，这就是MSS建设框架。
那么什么是MSS建设框架呢？就是下面这张图：
（注：本页内容出处：《中台产品经理宝典》一书6-1节）
具体来说整个建设过程可以分为三个建设阶段：
市场宏观认知（概括为Market）
企业标准化（概括为Standard）
解决方案设计（概括为Solution）
下面让我们一个个展开来谈。
1
阶段1：市场宏观认知理解（Market）
本阶段具体分为两个部分：企业外部调研与企业内部调研。
Part 1 企业外部调研——行业研究
（1）研究公司产品背后的细分行业现状是什么，公司整体业务在行业中所占地位，以及未来行业发展趋势是什么；
（2）研究公司的目标市场是什么人群，基于什么场景，通过什么方式，解决什么问题。
目的是为了发现未来可能需求，理解企业战略，我们才能预判优先级。例如在一家电商公司中，当我们孵化了一个主播业务，这个时候我们对流媒体管理的功能是否有必要超过商品管理的优先级（电商，直播间）来进行中台建设吗？答案肯定是否定的，因为企业的重心并不在这里。
Part 2 企业内部调研
（1）商业模式：调研企业是如何达成商业目标的。
（2）用户研究：汇总企业内部各业务线对中台的需求与IT架构。
这里商业模式调研推荐使用一个工具：商业模式画布，一张图搞定商业模式分析，如下图：
我们只需要按照这里空进行填写既可完成业务的具体调研。
完成了本阶段的工作，一个在中台建设中经常会被提及的问题也就可以迎刃而解了：中台概念如何让老板认可，要怎么争取公司资源呢？
这里就需要我们基于本阶段的调研回答这三个问题，并向老板进行汇报，就基本上可以收获老板的赞同：
（1）公司业务的认知，告诉老板你是懂业务的，例如市场初期规模比利润重要；
（2）秀肌肉：你能告诉公司现在的最重要问题是什么？以及中台化改造会投入多少，产出多少？（收入是否远大于投入）
（3）试验田是什么？怎么定义第一块试验田，准备怎么开展？验收标准是什么？
2
阶段2：企业标准化（Standard）
所谓企业标准化就是指将企业内部不同事业线的工作流程与规范进行统一。
这样做的目的就是为了标准化作业流程，从而让中台建设起来后的功能能在不同业务线进行复用，否则无法复用。
原因很简单，功能开发不像是文章一样，通过复制粘贴，把这一段话复制粘贴过去就可以直接用了，实际上根本不是这个样子的。
在软件开发中想要实现复用，最重要的问题不是功能复制，而是复制过去之后，这边的业务操作人对于原功能的流程要求是否一样。
举个例子来说，A业务线中操作流程你是从a到b到c，B业务线要求是从a直接到c，此时原有A业务线的功能就不能直接复用了。
此外当流程一样的情况下，还需要考虑此处的作业操作时效是否相同，然后相同时效下工作量是否一样。
就是相同流程下这个作业者操作的时间要求是否相同，A业务线可以三个小时完成该工作，因为这没有特殊的任务截止时间，功能流程上我们设计的时候也就不会考虑过度简化。
但是B业务线这边由于种种原因，要求完成这个业务必须在十分钟内就要把整个流程跑完，此时A业务线这边设计的这个流程是否能到B业务线这能复用，就要打上一个大大的问号了。
比如说这样的场景最常见出现在不同业务的供应链中，在电商的供应链里会出现这样一个问题，看似两个都是一个不同业务的电商业务团队，在管理者眼中认为你们的供应链不都是一样的吗？不都是库存管理，出入库管理等这些功能，但是工作量可能完全不同：
我这边一天入库可能达到300次，400次，每次必须在5分钟内完成，但是对于另一边，比如说是大宗商品的入库管理，每天的采购单量比较少，那么你一天使用这个流程可能只用一次到两次。
此时这两个场景就完全不一样了，我一天用300次的时候我的，我每多一个步骤，那就意味着我整个环节的步骤就会多300次人工操作，这个对于业务方来说，其实根本是不符合业务需求的，因为人工作业成本太高，所以此时流程明显无法复用。
总结下：进行标准化的核心原因是为了规范如下三个问题：
流程是否一样？
流程一样下作业者的操作时效是否相同？（三小时跑完流程与10分钟跑完流程）
相同下工作量是否一样？（一天用一次该流程与一天用100次）
这三者任意不一样都会导致软件功能无法复用
因此要想进行企业标准化，这里必须要做的核心任务为如下两点：
（1）定义企业业务关键节点；
（2）定义企业业务各单位的SOP；
3
阶段3：解决方案设计（Solution）
根据前面的文章所介绍的，中台解决方案设计，建设思路一共分为5步走：
（1）寻找共性需求，剥离掉业务特征
怎么理解这句话呢？作为产品经理我们都用过axure吧，我们发现通过axure自带的这些元件，就能描述所有业务的原型，可以自定义万物，我们从来没听说过axure为哪个企业自定义化过元件库，就是因为axure帮助我们从具体事务中剥离了业务特征，抽象出来了通用最小原件。
（2）根据业务完成建模从而设计业务组件
业务建模主要通过上一步梳理出的标准业务流程模板，将企业中的各系统、各功能的运行所需的支撑能力确定下来，初步梳理出整个企业的中台通用模型，产出中台的基本能力框架。
（3）特征列表管理
面对不同业务线的个性需求，要建立起特征列表去收集，在这些特征中分析共性部分进行建设，从而让中台尽可能多地服务不同业务线。对于实在无法进行合并的特异性部分，我们使用插件进行解决（也就是开放中台服务接口，允许特殊情况下业务线调用接口跳过部分流程）。
最后，也是MSS建设框架强调的，基于MSS产出的内容需要不断优化与迭代，以此适应动态发展的企业。
至此我们一个完整的中台建设框架就描述完了，大家可以根据自己的业务实际情况进行有的放矢的参考，搭建适合自己公司的中台。
PS：
（1）下一篇文章将为大家我在全国中台大会上分享的基于MSS框架的实战案例演讲图文版；
（2）想要了解更多中台搭建实战内容，或者想要学习掌握更多高阶产品经理的必备技能，可以来看看我的这本《中台产品经理宝典》一书。
我的新书《B端产品经理必修课2.0》已经开售了。
这是对我的第一本书的全新改版，也是关于B端产品的方方面面。
查看具体内容：我的《B端产品经理必修课》升级了
推荐阅读：