有信云产品副总裁郑秋明先生，他在互联网领域深耕数十年，曾是腾讯电商、微信支付等国民级产品的产品经理，在优质产品打造方面颇有建树。
加入有信云后，全面发力打造「低代码PaaS中台」，历经三至四年时间沉淀，对于如何构建一个更好的PaaS平台实现企业数字化转型拥有丰富的实操经验和深刻的思考。以下他在“第七届消费品数字科技大会”上的演讲全文。
非常高兴能够跟大家分享，过去三四年，我们在做“PaaS”这件事情上的一些收获和思考。
01.
新时代、新挑战
今天的世界随时都在变化。当北京冬奥会如火如荼的进行，全世界人民正深刻感受这盛世的时候，转眼就爆发了战争；
世界局势如此，聚焦到消费品行业，我们同样面临着“快速变化“带来的挑战。
首先，第一个挑战是中国的业态非常复杂。
在过去的几年里我们交流了非常多消费品公司的CIO、CEO，其中也包括宝洁的CEO。我们了解到，国外生意的业态其实是非常简单的。比如宝洁有一些品类在美国销售，可能只需要同行业内前5家KA达成合作，像沃尔玛、Costco、Amazon以及其余几家KA，就已经占据收益的50%以上了。
但是在中国，生意的业态极其复杂。原来我们做深度分销有一级经销、二级经销、三级经销，从经销到门店再到消费者；再之后KA崛起，国内涌进沃尔玛、家乐福这种大型超市，甚至我们本土也兴起了很多大型连锁超市；2010年之后，出现了电商，我们的货品必须通过天猫、京东等电商平台进行销售。电商的盘子越来越大，但我们都清楚其中的利润很低；近几年又兴起了社交电商、社区电商乃至今天的私域电商。
我们发现，中国的业态具备各种各样的形态，极其复杂。
第二个挑战是个性化。
在中国做生意，你在做的过程中会发现我必须做的跟别人不一样。如果陷入同质化竞争，那最后只能靠打惨烈的价格战取胜。所以，你必须找到自己的差异化优势。每个在市场上活下来的公司，必然是拥有属于自己的一套商业模式和业务流程。
因此，这对系统、技术人员、做数字化的公司都提出了更高的要求。通常你做了某个集团其中一个业务的系统，但却未必能将这个系统复用到另外一个业务上。
第三个挑战是变化非常迅速。
过去系统的迭代周期，我们通常以半年为单位。但国内的市场变化速度，迫使你必须按周甚至天来进行迭代，以此适应业务端的需求。
面对以上挑战，技术人员通常怎么应对呢？传统的经验里通常有几种方式。
通过自建技术团队或寻找外包公司针对业务需求进行个性化开发。但缺点是需要耗费较长的开发周期以及较高的开发成本。部分头部企业具备自研团队，能够利用内部资源完成系统开发需求。但对于中腰部企业来说，成本难以支撑。
通过采购成熟的门店系统、经销商管理系统满足业务需求。但当企业有个性化的需要，系统能不能进行差异化的设置？
SaaS公司往往满足不了这个需求。
举个例子，企业需要增加一个促销功能，预算3万，预计开发周期两周。但SaaS公司需要评估这个功能是否会跟原来的满减、优惠券、拼团等其他业务冲突？对在线的其他租户是否有影响？综合评估后发现成本需要二三十万、开发周期预计两个月。实际耗费成本与企业初始预算出入较大。
上述两种开发方式会形成我们常说的软件烟囱。
一是应用开发效率低，二是入口复杂。举个例子，某公司里面可能有三四十个系统，每个系统都有一套登录系统，当业务人员需要登录七八套应用系统去操作业务、且各应用之间数据还未打通的时候，业务人员的使用意愿和整体效率是极其低下的。
02.
有没有一种高度定制化的SaaS解决方案？
既能提供云端的服务又有成熟的体系，同时又有高度定制化的可能性。
有信云从三四年前就开始做这件事情。
早期，我们设想过：
1、开发很多应用，当企业有需求的时候，通过积木的形式拼装上线；
2、通过一个入口触达所有业务；
3、具备低代码的能力，不需要写太多的代码，就可以做出需要的应用；
4、其次是PaaS，把平台作为服务，通过这套平台就可以实施和开发你所想要的应用。
这套东西我们统称之为低代码PaaS中台。
低代码PaaS中台有三个核心特点。分别是沉淀复用、灵活配置、高可扩展性。
可类比为四大发明之一的 “活字印刷”，文字可以反复使用，同时每个活字互不影响，可以根据需求进行灵活配置。其次，假如需要新的活字，重新雕刻即可，无需废弃原有的字，具备高度可扩展性。
03.
我们认为，每一个规模化企业都需要一套低代码PaaS中台。
第一，满足稳态业务需求。可以通过一套稳定的低代码PaaS中台进行常规业务流程的搭建。
第二，满足敏态业务需求。前端市场变化快、活动类型丰富，需要一套可随时组装、灵活复用的系统。
第三、满足融合业务需求。传统业务和新业务必然会面临着数据的融合，比如原来做传统业务的公司，需要做私域运营、小程序、抖音、小红书等，以上这些触点需要统一的数据中台。
在过去的实践中，我们了解到企业搭建一套低代码PaaS中台至少需要投入上亿元资金、200人以上的产研团队、以及三年以上的时间沉淀，才能把所需的组件、引擎等基础能力备齐。
当然，并不是所有企业都需要自建一套低代码PaaS中台，市场上已出现部分初具规模的厂商，可以通过合作建设的模式完成这一套系统的搭建。
04.
低代码PaaS中台建设经验分享
第一、如果要建设一套业务型的PaaS中台，需要注重关于身份的数字化建设。
比如消费品行业的身份，从品牌方到经销商、经销商到门店到终端的C端。部分企业采购的传统SaaS软件，例如SFA的身份体系可能只包括你所在的公司、经销商和业务员。当公司需要拓展到门店、C端的时候，会变得极其困难，因为需要从最基础的地方打破。
因此，在初期就需要考虑到体系里的所有身份角色。绝大部分企业都是以下几种生意形态:第一种是B2B，企业与经销商的关系；第二种是B2C企业与消费者的关系；第三种是BbC，通过门店系统连接消费者。当企业这三种体系建设完毕后，可以为后续打下很好的基础。
第二、面向场景去构建应用。
在上述三种体系建设完毕的基础之上，我们需要应用来满足这些场景。比如业务员巡店所需的SFA、品牌方与经销商之间的营销费用的申请、核算、报销需要用到TPM、物料资产管理需要的POSM等…
这些应用都是建立在一个统一的中台基础之上的。意味着数据是统一的、关系身份是统一的。
门店体系也是如此。
门店的进销存、电源管理、店务管理、轻POS，甚至关于客户的客户资产、客户画像、客户标签、客户生命周期、客户MOT等体系，都可以建设在这个平台之上。
数字化交易，包括B2B、B2C、BbC的交易都可以统筹在一起。
无论是哪一种场景，哪怕是同行业同品类，在不同的渠道去销售其实都是有差异的。因此，企业需要根据自己的场景去构建需要的应用。
第三、运用引擎处理多变的流程
在做PaaS中台的第一天，企业就应当考虑到不是面向某个场景进行定制化的开发，因为企业的业务未来肯定会发生变化，需要引用引擎的配置来满足业务端的需求。
第四、打造集成平台、实现数据互通
每个系统都不是一个孤岛，如果它成为一个孤岛，它最终可能会死。
如何让系统不成为孤岛？需要打造一个集成平台。
举个例子，百度云里面有很多智能接口，如果每次都是硬接的方式，那花费的成本会极高。那通过集成平台去对接外部几十个系统，整体效率将会得到大幅度提升。
05.
No PaaS, No SaaS
无PaaS不SaaS。
如果企业要建设一套自己的线上数字化云平台或云系统，而仅仅用SaaS的思维说我只是上云，那就能解决大部分的问题吗？
如果脱离了PaaS的定制搭建能力；如果脱离了PaaS统一数据的能力；如果脱离了PaaS的系统集成能力。那上云了又能怎样？这与自己一个人开发或者一个团队默默地在本地化开发、定制化开发是没有差别的。
因此，我们认为最重要的思想就是——No PaaS, No SaaS。
如果你想要一套真正适应你这个企业的数字化系统，如果你想让你的数字化系统跟业务一起成长。那它不是一个静止的孤立的一个点，我们需要开始去关注如何做一个更好的PaaS平台。
