O2O 生鲜 SaaS 创业记·中台篇（五）

编辑导语：除去前期的市场调查、用户需求调查之外，如何在SaaS产品创业过程中，做好相应的中台产品架构设计？本篇文章里，作者结合自身的创业经验，总结了他在SaaS产品创业过程中的中台产品架构流程，一起来看一下。

一、系列简介

这是一部云时代 SaaS 产品创业记，讲述一位技术创业者如何从零开始系统完整建设满足行业客户产品，从战略到战术，从产品到技术到组织，从定位到定价到盈利，从云到中台到 SaaS，共计八个篇章内容涵盖行业/客户/友商、市场/增长、产品/中台、云服务/微服务/系统、组织/协同，力求全面清晰讲透云时代下 SaaS 产品建设。

二、产品篇序

SaaS 产品价值是“以客户为中心围绕业务提供具备生产力的行业解决方案”，实现价值第一要素理解行业客户和行业成熟解决方案，第二要素中台和 SaaS 化服务。

三、产品目标和效用

市场篇我们确定了产品定位是服务生鲜外卖代运营产品，目标为客户提供代运营模式下生鲜外卖平台管理系统，规划两个产品线，第一个是建设具备平替外卖平台功能的管理系统，满足客户多平台多渠道多品牌需求。第二个是建设客户定制化的业务考核管理系统，满足客户运营效率和 KPI 考核需求。

要满足客户多平台多渠道多品牌需求，要建设平替外卖平台的管理后台，首先要建设生鲜外卖平台管理后台，连接外卖行业三大平台美团外卖、饿了么、京东到家，建设客户端 PC 和 APP。目标是平替外卖平台后台管理功能，效用是提高多平台管理人效问题，组成外卖平台管理系统主干。

客户的代运营业务需求和外卖平台管理需求是两种类型的需求，在行业篇我们调研了外卖业务可以是餐饮、生鲜、水果、饮品、鲜花、医药等业态，运营模式可以是直营连锁例如喜茶；也可以是特许加盟钱大妈；也可以是客户这样的代运营，不同的业务和运营模式都可以适用外卖行业。

友商篇我们调研美团外卖商家中心，可以发现并没有对不同业务和运营模式进行定制化设计，足以说明外卖平台管理后台已经成为行业成熟的解决方案，是外卖产品行业标准功能。

我们把外卖平台管理功能作为主干产品，不同业务和运营模式的差异作为分支，主干产品符合行业标准，成熟稳定，面向整个行业提供解决方案，通用和抽象，分支产品面向行业内运营模式，面向运营实体提供解决方案也更加的具体。

外卖平台管理产品 OKR：

四、中台产品建模

我们使用 Thoughtworks 中国区 CTO 徐昊发明的履约建模法进行中台产品的业务建模，外卖平台管理系统连接三个外卖平台，通过开放平台 API 接口实现多平台统一管理，三个平台在外卖业务闭环流程上大致相同，通过对平台服务合同和履约项提取，建立外卖业务闭环宏流程模型。

宏流程模型是外卖核心业务模板，是一种宏观的抽象的流程模型，可以直观描述业务核心逻辑，同时具备稳定性和复用性以及弹性，业务上可以隐藏不同平台差异，这种差异体现是平台产品定位和能力，并不影响业务流程本身。

例如商家订单发配送是宏流程（发起配送请求→配送供应商接受请求确认 → 骑手取货 → 骑手配送 → 配送完成），具体业务实现上美团外卖是美团配送、饿了么是蜂鸟配送、京东到家是达达配送。

可以发现具体配送供应商因平台定位和能力而不同，这个差异完全不会影响商家订单发配送流程，当我们需要实现美团配送时只用配置宏流程业务模板，以及相关美团配送配置项，即可完成前台业务的具体实现。

这里强调下中台理论和架构中的“前台”更多是指一个具有运营能力或者研发能力的业务团队，而不是一个软件或者 APP。

例如生鲜品牌连锁，有广东团队和沈阳团队，组建地区团队专注服务于本地生鲜市场，不同地区市场需求、饮食习惯，消费能力，市场环境这些肯定是有差异的，南橘北枳对吧。

面向不同地区的市场环境运营策略肯定也是不同的，两个团队都会提出自己的产品需求满足市场，他们所使用外卖业务系统主逻辑肯定是一样的，毕竟都是外卖业务，但某些功能上的具体实现会有一定差异。

我们会发现两个团队都有着高度相似但又不是完全相同的需求，要求是高效重用，以满足业务快速扩张的需要，比例开拓新的城市或者新的供应商。

同时在某些业务上需要高度自主自治，比如促销、运营政策、流量补贴等，以满足各自的市场需求。

阿里认为应对“未来商业社会的是一种可能更具竞争力的模式，是通过小而灵活的前台团队，频繁而低成本试错，而支撑这种团队结构的软件就是中台”。

中台理念的发明者，芬兰游戏 supercell 完美诠释什么是中台“一个支撑多个小而灵活的前台业务团队的系统平台”。

简单概括这个前台业务团队职责是“以用户为中心，快速响应市场需求”，团队人员构成要少，甚至不需要研发团队，组建团队成本低，人少好沟通和协作，对市场响应快速，能接受快速试错。

下图是外卖平台管理系统宏流程模型，客户和外卖平台签署合同开展外卖业务，为了多平台统一管理，客户和外卖 SaaS 产品签署合同，管理外卖平台上的外卖业务。外卖 SaaS 产品和外卖开放平台签署合同，通过 API 接口为客户完成最终的外卖业务管理。

模型中有四个点需要提醒说明：

外卖平台背后具体的实现是美团外卖、饿了么、京东到家三个平台，当三个平台任意一个发生变化时并不会影响宏流程模型，当我们需要新增外卖平台时，只需要按照模型具体实现即可。 三个平台对系统容量要求各不相同，例如美团外卖订单量更多，我们可以为美团外卖服务部署更多云服务资源，或者收取按需收费。 外卖平台配送有平台美团配送、蜂鸟配送、达达配送，业务上还可以第三方配送供应商，例如顺丰、闪送等，通过引入配送供应商，提高外卖业务上可能性。 代运营、特许加盟、直营连锁是业务的运营模式，被隔离在外卖业务主逻辑之外，不会影响模型稳定性，隔离变化提供创新土壤。

宏流程模型从合同履约开始到业务流程结束，充分应用云服务的技术特性，完成中台建设核心要素权责分明、能力复用、隔离变化、弹性服务、模型稳定、快速响应。

五、产品架构和演进路线

通过宏流程模型我们更容易设计中台产品架构，将合同履约作为服务边界，自然而然做到适合的模块解耦，下图是外卖平台管理产品架构图。

蓝色部分是客户端，包含 PC、安卓 APP、iOS； 绿色部分是客户管理，包含客户登录注册、版本付费、第三方配送付费、版本功能选项、功能额度选项，以及后期规划 API 服务； 黄色部分是外卖平台管理中台服务，包含外卖平台管理、外卖平台开放 API 接口、配送供应商这些是外卖平台管理主逻辑产品，代运营、特许加盟、直营连锁、创新运营模式都是主逻辑上的业务运营模式逻辑； 橙色部分是定制化需求； 红色部分是中台 API 服务。

根据客户意愿和产品优先级，我们需要确定产品的演进路线，MVP 阶段完成平替美团外卖后台功能，建设中台雏形；发展期完成饿了么和京东到家、配送供应商、特许加盟，成熟期完成中台 API。

六、SaaS 化能力

我们建设了满足客户多平台外卖业务管理运营需求，在中台能力上建设客户定制化的业务考核管理系统，满足客户运营效率和 KPI 考核需求，最后我们可以开放中台 API 接口，加上云服务弹性部署能力，进行私有化部署，满足部分客户特定场景需要，包括接入 ERP、进销存等。

例如抖音需要一套外卖平台管理系统，我们可以部署一整套外卖平台管理服务，可以配置任意业务运营模式或者进行定制化，都不会影响到现有的客户，后面不合作了，也可以随时关闭这套系统。

如果说中台是为产品搭建起复用能力平台，提高产品创新能力和面对不断变化市场响应能力，降低试错成本，那 SaaS 化是为产品搭建端到端的解决方案，扩大客户群体，提高创新合作上限，降低生产以及协作成本。

SaaS 化的本质是提供产品的能力服务，应用云计算虚拟化和容器技术，使得我们可以对产品进行整体包装和部署，使其成为一个独立的产品进行能力服务。

七、中台篇总结

1）宏流程模型是天然适配中台建模，从合同履约开始到业务流程结束，充分应用云服务的技术特性，完成中台建设核心要素权责分明、能力复用、隔离变化、弹性服务、模型稳定、快速响应，为 SaaS 产品提供创新能力。

2）SaaS 化服务提供端到端的解决方案，充分发挥弹性服务、隔离变化、定制化和私有化，为 SaaS 产品扩展商业道路。

系统篇预告

如何研发中台产品？中台建模如何实现？如何选择微服务技术栈？LaaS、PaaS、SaaS 如何架构？能力复用、隔离变化、弹性服务如何研发？如何降低研发成本？答案都在系统篇。

 

本文由 @徐小威 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Pexels，基于CC0协议