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