业务中台04：某制造企业业务中台咨询案例
第20篇原创好文，共3600字|阅读用时8分钟
近期三爷受邀参与了某消费品制造龙头企业的中台建设外部专家小组，本文将以该项目的实战经历为大家带来中台MSS模型的一个实战案例（受保密要求，案例为精简脱敏版，重点为大家展开使用MSS框架进行中台前期分析的一个过程）。
1
设计目标
在现阶段一家传统消费品制造企业面临的消费者场景越来越多，如自有平台，微信生态，抖音生态等若干渠道。
在此基础上对企业的信息化团队提出了更高标准的要求，要求信息化系统能同时支持企业的快速业务创新，另一方面解决企业业务增长的需求，并同时解决个性化的渠道业务需求。
此时L公司因为同时经营多类细分市场，在内部拥有两个相互独立的业务与系统体系，此时在面对新消费场景时传统烟囱式开发模式造成的需求建设周期长，投资成本大，在现阶段这种需要快速响应市场的企业战略下变得越来越不匹配。
为了适应未来全渠道销售模式以及支撑作为多组织的事业部和信息系统未来发展趋势，L公司需要一个能将统一化的业务能力存放在公共服务中心中，从而使前台业务通过能力组装和个性化扩展即可快速满足企业的新需求。
并在中台架构体系下，实现多个业务的公共部分使用相同的中台服务，并实现关键流程统一。
2
建设思路
在开始建设之前，首先需要将该公司的中台建设目标做一个分解，具体来说中台建设的目标有两个维度，一个是功能维度，一个是数据维度。
（1）功能维度目标：基本目标是要能够支撑企业现有的业务功能，实现平稳切换，完整目标是需要产出标准化可复用的“场景化”功能群；
（2）数据维度目标：能够支撑企业数据驱动的管理和运营目标。
根据上述目标，以及前面文章中提及的MSS方法论，可以得到中台战略的落地建设思路如图所示。
（1）高层在全公司宣导启动中台战略，将中台建设上升至企业级解决后续推动问题；
（2）业务团队在中台负责人配合下完成业务关键节点定义（如：注册/订单/支付）；
（3）不同业务线统一并标准化关键节点，得到统一业务模型；
（4）IT团队在旧IT架构上完成复用化场景与个性化场景定义，并进行新IT架构定义。
3
基于MSS模型的中台方案产出
有了建设思路下一步我们就可以开始去产出具体的中台方案了。
（0）现阶段IT系统架构
这个本质上就是要对现有公司内部对IT系统进行梳理，分为哪些系统又分别承载什么内容？搞清楚企业内部信息化现状，通过这些系统也能很方便的剥离具体的业务特性来理解业务的信息化流程。
例如在初次接触L公司中的生产业务，乍一听十分复杂里面又有几百种原材料管理，还有几百页的车间作业手册。
我随便摘取一段：
“在水相锅中投入称好的水相类原料,搅拌加热到80,在油相锅中投入称好的油相类原料于85完全溶解。将乳化锅预热至6070,抽真空吸入......”
但是通过系统梳理后，我们就能很快理解如下图所示。
本质上其实我们就是在用功能流程代替业务流程，来帮助我们快速理解一家公司的业务运作。
（1）节点梳理
首先第一步是需要进入L公司与L公司的业务团队进行一对一的业务调研，在本环节要做的就是要找出L公司的业务节点都有哪些？
由于L公司内部拥有两条业务线，这里我当时选择了以单据流作为线索进行展开，通过分析单据流转，可以很快摸清楚的业务是怎么样的，以及单据都会经过哪些节点。
以下是我梳理出的L公司两条业务线的不同单据流：
A1业务线单据流：
A2业务线单据流：
可以看到在两个业务线中的节点可以摘录如下表所示的节点表：
节点号 | A1业务线 | 节点号 | A2业务线 |
销售过程 | 销售过程 | ||
01 | 订单创建 | 01 | 订单创建 |
02 | 现结 | 02 | 账期 |
生产过程 | 发货过程 | ||
03 | 客需统计 | 03 | 客需统计 |
04 | 生产计划 | 04 | 发货 |
05 | 领料 | 05 | 签收 |
06 | 成品入库 | 生产过程 | |
发货过程 | 06 | 备货计划 | |
07 | 发货 | 07 | 领料 |
08 | 签收 | 08 | 成品入库 |
采购过程 | 采购过程 | ||
09 | JIT采购 | 09 | 订货点采购 |
10 | 采购结算 | 10 | 采购结算 |
11 | 采购付款 | 11 | 采购付款 |
在梳理完相同节点后，下一步就是要将节点分为可标准化的部分与个性化部分。
这也是在中台建设中极易常见的误区，很多中台产品负责人听到要复用化，就一味将所有节点全部进行了统一，导致出现“为了中台而中台”的现象，最终让中台上线后各个前台业务系统都不愿意接入。
具体来说这两类的节点定义如下：
可标准化节点：各业务相同承载部分
个性化节点：各业务个性化部分
再举个通俗的例子，创建订单节点就是可以标准化节点，因为不管任何交易最终承载订单都是由固定三要素组成交易标的，交易人，交易媒介-钱组成，所以我们完全可以把订单节点去标准化。
如何评估业务节点是否可以合并，这里有很多方法，比如公司业务专家评估，高层拍板（很不幸在我做过咨询的绝大公司都是这样做），这样的做法不能说错误但是容易产生遗漏。
因此这里我建议使用一个比较科学的方法来评估相似度，可以参考我在《中台产品经理宝典》中提出的管道对比法，其核心要求我们不是进行具体功能的输出结果是否一模一样进行比较，而是对对象进行比较，这里在L公司的节点比对结果如下表所示。
节点 | A1业务线 | 类型 | 节点 | A2业务线 | 类型 |
销售过程 | 销售过程 | ||||
01 | 订单创建 | 可标准化节点 | 01 | 订单创建 | 可标准化节点 |
02 | 现结 | 可标准化节点 | 02 | 账期 | 可标准化节点 |
生产过程 | 发货过程 | ||||
03 | 客需统计 | 个性化节点 | 03 | 客需统计 | 个性化节点 |
04 | 生产计划 | 个性化节点 | 04 | 发货 | 可标准化节点 |
05 | 领料 | 可标准化节点 | 05 | 签收 | 可标准化节点 |
06 | 成品入库 | 可标准化节点 | 生产过程 | ||
发货过程 | 06 | 备货计划 | 个性化节点 | ||
07 | 发货 | 可标准化节点 | 07 | 领料 | 可标准化节点 |
08 | 签收 | 可标准化节点 | 08 | 成品入库 | 可标准化节点 |
采购过程 | 采购过程 | ||||
09 | JIT采购 | 个性化节点 | 09 | 订货点采购 | 个性化节点 |
10 | 采购结算 | 个性化节点 | 10 | 采购结算 | 个性化节点 |
11 | 采购付款 | 可标准化节点 | 11 | 采购付款 | 可标准化节点 |
在得到这个表后，下一步还需要做的事情就是要去思考并不是一次性将所有可标准化节点都需要进行标准化并合并到中台，还需要进行一次评估，中台需要做这么重吗？
在L公司经过初步沟通，我们决定从最基础的可标准化节点开始着手1.0版本。
（2）节点标准化
对于可标准化的部分，这里需要通过定义“SOP”进行统一，下面摘取了在L公司的方案中商品库存管理标准化内容。
标准化内容 | 示例（商品库存管理） | |
系统 | 名词 | SKU统一代替旧称呼： A1业务线：品名 A2业务线：SKU名称 实物库存/虚拟库存 |
流程 | 库存管理流程分为： （1）实物库存：库内实物件数 （2）虚拟库存：商城自定义数，默认为0 | |
公式 | SKU库存计算逻辑 （1）以最小库存单元统计（注1） （2）可售卖库存=实物库存+虚拟库存-锁定库存 | |
展示逻辑 | 前台展示可售卖库存数 | |
功能 | （1）实物库存查询 （2）虚拟库存设置 （3）锁定库存查询 （4）可售卖库存查询 | |
业务 | 角色 | 功能使用角色 = 商品运营 |
场景使用规则 （SOP） | （1）正常售卖：设置以实物库存售卖 （2）预售售卖：设置可采购上限的虚拟库存售卖 （3）在途售卖：设置以在途量的虚拟库存售卖 |
（注1：在此处也是中台在实施过程中遇到的一个最棘手的困难，就是中台设计的统一化方案很先进，但是原有业务线在此处进行改动时需要进行非常大的改动，例如这里的库存管理逻辑，此时的做法中台应该使用软接入的方法，也就是采用转换器或虚拟接入的方式先行让业务线接入，在后续迭代中进行彻底解决，具体软接入的方法我将在后面的文章中为大家详细展开。）
通过这里的节点合并重新定义，大家应该能理解了什么叫做场景级复用，也就是不仅仅在系统上做出了统一的设计语言，更重要的是要求业务方在进行业务开展时也能以统一的规则进行展开，从使用者源头上进行规范。
找到了标准化节点其实也就得出了我们服务中心的范畴，在L电商公司中我们根据标准节点一共得到L电商公司中台1.0的六大服务中心。
（3）中台架构
综上根据抽象出的业务模型中的统一且标准化的部分进行中台架构设计，可以得到L公司全新的IT架构。
4
方案投入产出比
（1）投入
A公司的中台建设与以中台战略为导向的企业信息化改造，累计项目研发周期需要约5个月。
（2）产出
建设完成后获得可面向多个场景的统一支持能力，归并企业内部基础服务，获得可快速响应不同业务的需求，目前现有的独立外部渠道已有微信、支付宝。外部H5内嵌等多个渠道，约7千万的渠道月GMV，将合并至主业务流程享受与现有业务流程相同的迭代速度与支撑，不再需要独立开发。