打造业界第二个“SAP”, 开头难!

在数字化转型的浪潮中，企业对全流程线上化管理的需求日益迫切，但如何在有限的IT资源下实现多业务线的数字化覆盖，并最终打造出能够对外销售的通用化产品，是许多企业面临的一大挑战。本文作者作为一家致力于成为业界第二个“SAP”的公司的项目执行负责人，分享了他们在探索软件发展模式过程中的艰难抉择与灵光一现。

这里分享的经历，是在《那个ERP项目，让人后怕！》《一个ERP项目，在深山调研》《那个亿元ERP项目，难忘…》《那一年，给SAP“整容”》后发生的事儿。十点半的地铁，终于每个人都有了座位。

温热的风，终于能轻轻地静静地吹。

……

城市的夜，在头上沉默经过它的心上。

尽管它千疮百孔，仍在夜里笑得冷艳漂亮。

——李健干净温暖的歌声从耳机中传来。

这一刻，十分应景，加班的夜晚，地铁疾驰而来，是回家的末班车，车厢已不再拥挤，稀疏地坐着几个人，面露疲态。我寻了个座位坐下，脑海中思索着近日战略会议上，老板提出的“保三争六”议题。

所谓“保三争六”，背景是公司经营着多条业务线，每一条业务线都属于独立的单元，业务间并没有任何关联，业务流程上也略有差异。只有一两个业务线实现了全流程线上化管理，其他的业务线也迫切地需要数字化支持。

奈何IT资源有限，无法为一条条业务线定制化开发系统，只能探索通用化产品建设，实现三年内部业务线全覆盖，六年实现产品对外销售，成为业界第二个“SAP”。

理想很宏大，现实很骨感，要完成这么大的目标，背后一定得有技术过硬的团队，但IT人力资源本就捉襟见肘，我作为此项目的执行负责人，特别头疼。

好在经过一两周的协调，我们的团队成立了，有IT架构师、业务顾问、产品经理、前后端开发、测试、UI人员、以及各个业务线的关键用户，加起来足足有二三十人。

开攻第一件事，就是确定软件的发展模式，由于既要实现通用化，又得考虑内部业务线的差异点，最后还能兼顾公司的宏大愿景——打入外部市场。

真是个大难题，万事开头难，得到了具像化的体现。只有模式想清楚了，才能开始下一步的落地工作。在此前，我们已经展开过讨论，大家的思路是打造SaaS产品模式。

但我深知这是不可行的，一是SaaS类产品需要完全的通用化，在目前的业务场景下是不满足的；二是未来面对的是外部市场，这属于大型管理软件，有无数的定制化需求，不是SaaS订阅产品所能兼容的，最后只会发展成四不像。

但是呢，我也没有一个好的方案，所以加完班，坐在地铁上陷入了沉思。地铁在隧道中蜿蜒前进，时儿直行，时儿转弯，直行时可以看到前面好几节车厢，转弯时则只能看到下一节车厢，原来每节车厢都有一个软连接区域，可以有一定幅度的摆动，从而实现地铁在隧道中走曲线。

我嘴里不自觉地念着“车厢”、“软连接”两个词，仿佛想到了什么，这不正是我思索的软件模式的模型嘛，“车厢”就像软件应用的一个组件，通过“软连接”就可以拼成我想要的形状。但这不就是低代码平台的思路嘛，不可行，我否定了自己的思路，因为低代码平台太过于泛化，没有一点业务逻辑在里面，只能全靠用户DIY，应用难度非常大，也没法实现超复杂的需求。

但我立马想到，地铁车厢可以拼装，但拼出来的一定是地铁，不是房子，也不是写字楼，它的形状也一定是一节连一节的长条形，不可能是个圆或者其他形状。

这就是和低代码平台最大的区别，我们一定要约束系统的主流程和关键模块顺序，至于其他的附属模块，就像车厢里的座椅，可以按需通过软连接的方式连起来。这样既兼顾了通用化业务，又增加了灵活的扩展性。

随后，我又想到，地铁一趟趟驶去，虽然看起来一样，但实际上都是不同的地铁，有各自的编号，想要多少辆就可以造多少辆，想放在几号线就放在几号线。

我醍醐灌顶，原来我们要造的不是某个软件，而是软件的孵化器，再结合上面的约束，即能够孵化出标准应用的孵化器，再结合插件式开发，打造个性化的插件服务。

此时，兴奋至极，恨不得马上和团队分享这个想法，奈何时间太晚，大家都已经休息。末班地铁响起：“本次列车终点站为XX，前方到站YY，列车将开启右侧车门，请提前做好准备”，只能等待第二天了……