平台化系统商业化能力的另一种表现-SAAS

写在前面

中台和平台化很火，其实中台更多的是组织墙维度做的事情，我们多个领域能力组织在一起形成一个中台，所以首先要做的是组织的划分和合并。随着参与中台事情的越来越多，现在对于中台的理解与定位也更倾向于某种特定而具体的能力收敛。比如交易中台，主要围绕于用户选品，下单，支付这个环节。或者售后中台，涵盖了从用户下单之后的履约之后的b、c端多个环节，比如涉及到评价、打分、退款、退货等环节和功能。很少有一种叫法是“电商中台”，因为盘子太大了，更好的中台还是具体围绕于某个比较确定的方向，比如阿里的中台更多的是以交易为核心，不管是淘系，还是非淘系的入淘出淘都是围绕于交易这个内核。

说道平台其实他是中台下的某个具体方向能力的一个沉淀，平台更偏向于某个具体的能力域的沉淀，因为有“平”字，对应的就是把以前能力类似的多个烟筒式的架构拉平形成平台，烟筒到平台这个过程设计到了分层，哪些是通用能力，哪些是商业能力，哪些是业务能力，哪些是技术能力，哪些是开放能力等。

其实做中台更多是高级管理者们撕逼的政治产物，因为中台为的是降本增效，比如沟通成本，怎么方便怎么来，所以需要做一些团队和部门的整合。而做平台才和技术人员关系更密切一些，首先你要做平台，就需要有平台化的思维，将业务的现状和未来进行分析，进而体现在你的平台化系统设计里面，有的需要做沉淀和整合，没有的需要预留扩展能力。运营层面我们需要承接不同部门的运营需要，需要做一套适合于不同业务背景的运营同学好用、易用的运营管理平台。之前的文章中介绍过平台化系统商业能力产品化的一个方案是APAAS，今天和大家介绍下另一种形式SAAS。

你这个平台商业能力的核心是什么？

要做SAAS首先要问自己的第一个问题是定位问题，你这个SAAS平台究竟是以什么为核心呢？他的定位是什么呢？等你想明白这个问题之后，接下来的规划就是围绕于这个“商业内核”去做衍生了。

比如有的SAAS是围绕于CRM实现的，有的是进销存，有的是客服工单，这个是首先想好的问题。

想好了“商业内核”这个问题之后就需要梳理三个统一，如：模型统一，数据统一，运营统一。

这里统一的意思是将你所见到的各个业务方各种个性化的需求进一步收敛、抽象、分析、沉淀形成一套统一的业务模型。而模型背后的数据我们同样需要做抽象，以期望可以适用于不同的业务，这样做的好处是，我们数据的下游可以统一用一套数据模型做一些智能化的动作，比如上层业务模型的数据分叉太多，下游的数据服务必将需要做各种数据兜底适配这个成本巨高。接下来我们就是开始做产品化或是商业能力这一层抽象了，不同业务的个性化往往在于这里，但是我们交付的运营管理系统还是希望做到运营统一，这样可以拉齐各方运营同学使用的标准，降低学习成本，真正做到降本增效。

有了能力的分层我们接下来就是讲一些核心商业能力之外的能力收口，其实是微服务那一套，彻底的服务化，和商业能力无关的能力下沉。比如做SAAS势必需要一些账号、登录、注册、鉴权、租户、验证等功能，这些可以独立剥离出对应的服务，以微服务的方式为SAAS服务提供服务。

上面谈的还是围绕于技术或是架构的事情，其实做SAAS大家很容易忽略的一点是运营后台的能力，比如一个完整的SAAS平台化系统做出来后，需要满足不同套餐、不同层次商家的需求，我们需要有个产品定义平台，帮助我们把功能性的东西做完之后抽象出不同的套餐定义，以提供不同产品给不同商家使用，这样我们可能还需要以供服务市场平台以及以供开放平台实现和商家现有软件产品的打通。

新零售SAAS产品

说了那么多我们举个新零售SAAS产品的例子。

零售现在是一个非常火的概念。新零售到底是一个什么东西？怎么理解？我从我的角度跟大家讲一下我们这边对新零售的理解和怎么去做这个事情。

大家先看一下SAAS电商，讲新零售为什么又讲电商，要知道我们所有的体系都依赖于电商体系，最底层就是我们的电商体系，只不过展示不同的形态。不管是天猫也好，天猫底下的饿了么或者盒马鲜生也好，各种各样的形态，还有现在摆的无人零售体系的无人货柜也是我们零售体系展示的形式。

整个电商的体系架构分为好几个层次。

最底层是一个中台的能力，比如说用户、商户、支付、卡券、会员、数据、物流，这些都是相通的，有很多的共性。

往上是电商体系，里面包含商品、价格、库存、订单，到新零售的时候还有多门店、多仓库等。

再往上是营销体系，有满减折、会员、卡券码这些东西。营销体系再往上是商家的体系，商家体系是B端的，还有C端用户的体系。

用户登录到你的体系来可以做什么东西，有哪些点是跟你相关的。

再就是交易流程的体系。

再往前是给用户展示的，页面不管是首页也好，广告页也好，很多分类页也好，属于导航的体系。

顶层是渠道层，公众号也好，小程序也好，H5也好，百度小程序，都是一样的，对于我们来说只要你底层架构一样了，顶上的渠道可以是任何的一个点。以上是我们整个电商的架构。

你看分层多重要，很多技术人简单的将分层理解为解耦，其实分层更多是将能力聚拢、收敛形成标准化，分层是对这一层能力的标准化的动作。

我们了解了传统的电商体系能力，那么我们再看下新零售体系有什么变化呢？

一个小圆圈就代表一个线上商城，新零售就是由多个小圆圈组成的。除了商家本身外，下面还有很多子门店，对比我们说的线上商城体系，我们的新零售有很多不一样的特征就展示出来了。

比如可能出现一店一商城的情况，每个门店拥有独立、完整的商城功能，支持直营、加盟等多种门店方式。

电商线上商城是线上的场景，到现在我们支持了很多线下场景，导购、开单、收银、自提、线下支付。

现在到了新零售的阶段，线上和线下打通，规模统一，价格一致，支持门店共享仓、独立仓、云仓等库存体系。

线下是进销存体系，涉及到供应链的需求。

现在有多种订单处理方式，之前是线上订单来了，我线下发货。新零售有前置仓，可以把订单派到不同的线下的门店，用户可以自提。同时也支持不同的策略，把订单分配给不同的门店。

最后是商家+多门店的体系。零售体系和线上商城体系相比，功能体系已经发生了很大的变化，在这个过程中，业务架构设计是一个难点。特别是在商城里要做好零售的设计。如果已经把门店体系考虑进去。这是非常核心的点，这样你的系统设计已经成功了一半了。

接下来再看下电商系统核心业务架构里面的商品体系架构。

在线上电商商品体系里面，线上商城涉及到商品是线上的，可能有B2C的订单，积分订单，商品和SKU。如果做过电商的都了解这些模型。

标签也是通用型的标签，这边是活动的库存，后面价格是统一的。这样零售会变成什么样的？这样会多很多东西，这时候商品已经增加了线下的商品和多门店的商品。

还有单品和组合品，如果做到仓库体系，我一瓶可乐+雪碧组合起来形成商品。单品我也可以卖一瓶可乐和一瓶雪碧，这里有组合品的概念。

还有门店商品关系，进销存相关和多仓库相关的我们之前说了。设计整个商品模型的时候，就要求做线上商城的时候要考虑线下零售，要把模型设计好。

越是做大系统就要考虑整个的模型体系怎么设计。刚才把底下的点铺开了，我们没有把上面的点铺开。所有的商品相关的点，我们利用商品中台对接完整个体系，营销体系、导航体系、交易体系和订单体系，还有直播、客服等等。这样要求你的中台能力非常强。

接下来说下库存系统，线上的简单库存体系只有普通库存和活动库存。到了新零售整个体系就完全不一样了。

进销存体系，还有整个仓库体系不光有线上还有线下的，共享云仓、独立仓、仓库、门店仓库关系等等。

举个劲霸男装的例子，他们希望把上海100个门店都生成虚拟的仓库，所有的门店都整合到虚拟的仓库里下单，所有的客户都在虚拟仓库里面，这就是我们说的云仓的概念。这就要求我们在做线上商城的时候就要把整个仓库的点考虑进去了。一开始设计的时候就要考虑这些维度。

接下来还有营销能力的设计，比如价格，商品有成本价格和市场售价，还有活动时候的营销价格。

举个例子，有300件营销的价格，前面100个是100块钱，接着下来是150块钱，后面100个是200块钱。我要引爆营销活动，支持阶梯式的价格，价格是有生效时间和失效时间。体系很简单，但是一开始就要考虑好整个业务是什么样的。

我们再说下支付架构设计。

其实支付是一个有非常多领域知识的领域，大家虽然都知道支付这个事情，但是如果做一个支付平台架构其实挑战是很大的。

比如在用户看来我在线上微信支付就完了。从商家来看则有很多不同的点。

整个支付体系还分很多场景，比如分次支付、线上线下混合支付、多次合并支付及重复支付自动退款等等。支付的方式大家比较常见的有微信支付、支付宝、网银等等。如果整个架构体系来说，还涉及到收支明细、营收概况、营收趋势等等。

还有一些其他业务能力，我们有很多合作的第三方支付公司，需要利用它们可支付的整合能力。比如说一个商家进来，我收了一笔钱，可能要分给A多少钱分给B多少钱，分销的时候每一级我要分多少钱，每个钱怎么分，怎么打到具体的帐号里，也是很复杂的点。我们整个支付体系已经支持了这些东西，整个架构体系考虑了非常多的东西。

接下来再说下订单，订单和商品往往被认作是交易系统的核心。

对于零售来说有各种各样的订单，不单单是大家常见的线上下单然后我发货，这种情况属于实物订单，实际上还有很多虚拟订单，积分订单等等。怎么做这么庞大的订单系统？

我们会把每一种订单按它的交付类型、交付方式统一。虚拟订单交互的方式是不一样的。对我们来说订单有很多层次，业务订单、营销订单、基础订单等等。比如说拼团订单，五个人成团，怎么去控制拼团的订单做流转？我是不是可以拼周期购的订单？这样整个体系就非常大了。我

拼的是周期的充值订单体系又不一样了，所以订单的体系也是很复杂的体系。如果对于C端用户来说，不同的订单还要帮我整合起来。大家看美团点评的订单类型，我今天吃饭的单，充值的单，各种类型的单，都整合在你的订单里面。

我们整个订单中台有很多不同的东西，营销订单有砍价的、秒杀的、SDP订单，会有整合搜索引擎承载这些东西。还有数据库中间件等等支撑庞大支付的体系。

所以分层和领域建模，以及边界划分对于一个大型复杂系统设计是非常非常关键的，如果这里做不好，系统的规则变化膨胀之后，你的系统将会爆炸。

再来说订单中台，所有的订单都会被收过来，最终下到基础订单，由基础订单统一对外呈现东西，把订单串联整合起来。

这里需要真正做到电商体系的时候才会有深刻的理解。另外大家可以从这个点上了解一下我们做新零售，我们之前讲了整个AAS体系，讲了新零售从线上商城到线上线下打通的多门店体系，接着我们又讲了电商核心领域怎么做演进。

整个电商里面最核心的是要从商品开始，商品设计好了，整个的交易流程把商品需要的东西，或者我订单交付需要用到的东西全部承载到订单里面去，订单落地完了以后，剩下的是我们走后续交付的路线，根据不同的订单有后续不同的交付路线。

支撑服务

好的SAAS产品或是架构可以支持十几种解决方案，上百套套餐。

上面介绍的是核心电商或是新零售的架构与设计方案，围绕于核心架构之外还有一堆支撑系统，比如权限管理系统，比如数据统一处理系统，各种监控告警系统，持续集成系统，资产管理系统，日志分析系统，虚拟化与容器调度系统，大数据存储系统，流量网关、waf安全等系统。

基础架构底层是基础设施层、消息中间件、ES、缓存、流式计算。

基础设施层之上是服务治理层，这是最重要的，有配置中心、dubbo、注册中心、服务管理等等。

上面还有基础工具，如媒体中心、短域名、大数据服务、IP服务等。

再顶层是具体的业务层，有新零售、到店、微站等。左边是CAT监控系统，这个是需要通过蛮长时间的迭代发展起来的，已经可以满足大型的业务监控支持。

还有全局调用链系统，这是大型互联网公司必备的，很多请求出现问题以后，一个接口在外面体现出来，底下经过几百个接口的调用，靠全局调用链系统一下就可以发现问题。

最后

从应用架构层面来说，很多东西看起来比较简单，但是你要抽象出很多不同的场景做很多不同的应用。

我们简单可以看一下，比如说通用日志，后台商家有很多通用日志，我们接口统一出来进行注解+AOP。规划定义不出来，出来的东西就五花八门。当人员变化比较多，有不同的处理，怎么保证这些东西大家一看到都是很清晰的。通用权限和风控拦截、分库分表等等，很多是apidoc和http register，也会有相应的动态注册。

对于零售体系来说，你要提高效率，最重要的是应用架构很多规约的制定和不同场景使用什么样业务处理方式，大家以后做比较大的系统的时候，也能考虑到这些点，那你就会发现整个架构设计的理念和考虑的角度很不一样。

最近听到一句话：

听上去任何人造个火箭????都是可能的，实际上并不。项目很多时候失败并不是软件工程失败，设计失败，资源问题，能力不足，是更常见的原因，软件工程只是背锅侠。