经常在群里看到有朋友讨论供应链系统是自己研发好，还是购买三方的系统好。问这一类问题的朋友，通常是处在业务发展和系统建设的十字路口，需要对下一步的系统规划做决策，担心当前决策失误了为未来留下隐患。这种决策通常会发生在两个阶段：一是业务刚启动时，想要一个系统快速支撑业务的开展；二是业务已经步入正轨，需要加大投入时。

不得不说，系统建设的决策确实很重要，特别是业务已经步入正轨，一旦起量了，再进行系统切换，付出的代价会是初始建设的好几倍，会涉及到业务流程的重新梳理、数据的迁移、操作人员习惯的转变等诸多问题，所以在做决策之前，做好充分的规划和对比是非常有必要的。

在做系统规划时，我们通常有三种建设思路可供选择：自研系统、定制开发和外采市面上标准的产品：

（1）自研系统：一般有自己的研发团队的公司会选择自研，即所有功能都自己研发，完全贴合自有业务。

（2）定制开发：寻求市面上专业的解决方案公司，提业务需求，让解决方案公司为自己定制系统开发，开发完成交付以后，有的公司可以连源代码一起交付，有的则只交付成品系统，不交付源代码。

（3）外采标准产品：直接采购市面上标准的解决方案产品，或者付费使用标准的SAAS产品。

三者的优劣和适用场景如图所示：

从上图的对比可以看到，无论是自研、定制开发，还是外采产品，都是需要结合企业自身现状的，还是要追求成本收益最大化，并不是为了秀肌肉，所以即便是有雄厚研发实力的企业，也不全部自研产品，一般核心业务系统会考虑自研（如用户端、供应链系统、交易系统等），核心较稳定的系统考虑定制开发（如财务系统、ERP系统等），新型业务或可独立运行的系统考虑外采（如新尝试的某电商业务、EHR系统、OA系统等）。

记得十多年前，信息化还不像现在这么发达，无论是自研，还是定制开发，或者外采标准产品，程序都只需要部署在企业当地的机房中，在本地局域网里运转，用现在的话叫私有化部署。一旦出了问题，好一点的情况可以通过远程桌面解决问题，严重一点的事故需要工程师坐几天火车去到现场解决，成本高，而且非常低效，不过当时的工程师是万能的，不仅会写代码，还要充当网络部署、服务器运维、数据库DBA等角色，什么都要懂一些。

随着云服务的普及，近几年市面上的系统开发方式也发生了翻天覆地的变化，出现了SaaS、PaaS、IaaS等很多耳熟能详的新鲜名词，各种花样层出不穷，即便是身处软件开发行业的产品经理和开发工程师们，也经常会被这些名词整得一愣一愣的。不过不用紧张，下面，我们从老王养鱼的故事开始聊起，带大家一起认识一下这些神秘的服务，最后，再一起来分析一下该如何使用这些服务。

首先，要修建一个鱼塘，这是所有环节的基础，就像种树需要阳光和土壤一样；

然后，选择合适的鱼苗品种进行投放，这个环节也很关键，为什么要养鱼而不是养螃蟹，一定是经过市场分析的；

接着，就是对鱼苗进行养殖和养护，让它们茁壮成长，这是最漫长的过程，通常要几个月的周期；

最后，等鱼苗长大后，到了打捞的季节了，进行成鱼的捕捞和销售。

无论哪一步，都需要有人力和财力的投入，还有时间成本。经过分析，老王整理出了4个可行的方案：

方案1：所有环节全都自己干。自己把农田改造成鱼塘，然后从市场上挑选合适的鱼品种进行培育，然后再开始养殖，但以上每一步都需要投入时间和资金，而老王自己一窍不通，试错成本太高；

方案2：找同村的李叔租一块鱼塘，其它的环节自己学自己干。这样自己不用单独挖鱼塘了，省掉了最大的时间投入，但是要把利润拿一部分出来当作鱼塘的租金给李叔；

方案3：鱼塘租李叔家的，鱼苗也请有经验的李叔帮忙挑选和培育，自己只负责后续的养殖和销售。毕竟自己一窍不通，让李叔帮忙选苗，风险比较低，期初投入也不大，但利润也比较薄了；

方案4：完全不管养殖，直接从李叔那采购已经养大的成鱼，自己负责后续的销售。这样最省心，但得完全依赖李叔，即李叔有什么鱼，自己只能卖什么鱼，而且大部分利润都给李叔了。

思来想去，老王决定第一年先用MVP的方式低成本低风险投入，试水一下这块养殖业务，如果ROI还不错，第二年再加大投入。于是，他选择了方案3…...

第一步：购买服务器，部署服务器网络和操作系统（建鱼塘）；

第二步：确定开发语言，部署开发环境（选鱼苗）；

第三步：进入系统开发、测试（鱼苗养殖）；

第四步：系统上线推广，提供给业务方使用（成鱼捕捞）。

在以上4步开发过程中，也有4种投入方式：自采服务器+自主研发、租用三方云服务器+自主研发、使用三方服务商的开发环境开发、使用三方服务商开发好的软件，分别对应本地自研（建鱼塘，选鱼苗、养殖鱼苗和成鱼捕捞都自己干）、Iaas（只租李叔的鱼塘，自己培育和养殖鱼苗）、PaaS（租李叔的鱼塘+请李叔选鱼苗，自己负责养殖）、SaaS （李叔提供鱼塘租赁+选鱼苗+成鱼捕捞一条龙服务）4种模式：

本地自研：企业自己建设机房，并购买服务器和安装操作系统，然后在服务器上部署开发环境、开发系统，并完成项目上线，这种模式在10年前网络不通畅时，是主流的开发模式；

IaaS（Infrastructure as a Service，基础设施即服务）：企业不需要建设机房和购买服务器，可以按需直接购买IaaS服务商提供的虚拟机、存储、网络和其他基础设施资源，这些基础设施都是部署在云端的，也即经常所说的云计算，像市面上的阿里云、腾讯云等；

PaaS（Platform as a Service，平台即服务）：在IaaS的基础上，服务商还为企业提供了一个开发和部署应用程序的平台环境。开发人员可以使用PaaS提供商的工具和资源和开发规范来直接构建、测试、托管和扩展应用程序，只需要开发很少的代码。

SaaS（Software as a Service，软件即服务）：服务商提供完整的软件系统供企业使用，企业直接打开浏览器即可访问，服务器、开发环境和开发过程都不需要了。

无论是IaaS、PaaS还是SaaS，都是服务商为企业提供的可直接购买的云服务，所以才叫“XXX即服务”，但三者提供的服务方式不同。IaaS只提供服务器和网络等基础设置，PaaS还提供开发平台供企业做二次开发，SaaS则为企业提供完整的软件服务。

▲本地自研、IaaS、PaaS与SaaS

在PaaS中，还有一种特殊的形式，叫aPaaS（application Platform as a Service，应用程序平台即服务）：由服务商提供可视化的开发组件，使用方可以在不具备开发能力的基础上也能在平台上快速搭建出自己想要实现的系统功能。它和PaaS的区别是PaaS通常需要开发人员按照PaaS平台的规范，基于PaaS平台的API接口，在本地完成应用程序的开发和数据提供，然后部署到PaaS平台上，需要写少量的代码，也即传说中的低代码，而aPaaS则是由服务商提供全套开发组件，开发者拖拖拽拽即可完成系统开发，即传说中的无代码。

回到老王的故事里来，PaaS就像李叔提供鱼苗培育的技术标准(鱼塘的酸碱度、温度等)，老王按照技术标准在自己的鱼塘里培育鱼苗；而aPaaS像是老王直接在李叔已经调配好的鱼塘里进行鱼苗培育，无需自己操心，相比PaaS会更加省事。

IaaS、PaaS与SaaS是随着互联网的普及逐渐形成的。在最早的软件市场里，只有标准化的产品，比如国内的SAP、Oracle，国内的金蝶、用友等软件，受限于网络传输，主要在本地部署。随着电信网络的普及，传输速率加快，慢慢就出现了IaaS产品，解决了每个企业都需要自己花钱建机房和买服务器的问题。

与云服务随之而生的是SaaS产品，用来满足很多中小型企业的标准化需求，比如早期的电商ISV、打单软件、CRM系统等，相比传统的标准产品，部署更快、成本更低。

但标准化的产品总是无法很好的满足每个企业的需求，于是企业稍微有个性化需求，SaaS产品就无法支持了，导致很多用户的流失，这也是国内SaaS行业最大的痛点之一。于是，为了能更好的适应市场上不同用户的需求，PaaS模式就诞生了，服务方提供服务平台，可以由使用方自定义系统流程和系统功能，相当于服务方提供一套工具箱给使用方，想做成什么样子完全由使用方自己打磨，而且利用PaaS和aPaaS的架构方式来快速实现业务开发，相比传统开发模式，开发周期和开发成本缩减了50%。

听起来很美好是不是？这也是这两年低代码和无代码平台火起来的原因，号称可以干掉一大片的程序员的新型开发模式。但实际情况是，即便是国内最先进的低代码和无代码平台，也无法完全用组件化的方式实现每个企业的个性化需求，他们的工具箱的完善还需假以时日（所以程序员朋友们暂时还没有必要杞人忧天~）

这个问题和前面开篇提到的自研好还是购买三方软件好一样，不在特定的场景下做对比，没有意义。

站在使用方的视角，自研、PaaS、aPaaS和SaaS的工作量呈递减态势，自研模式下，所有工作量都需要自己完成，开发工作量自然最大；PaaS模式下，服务方提供了完整的开发环境和规范，使用方按标准使用，工作量次之；aPaaS模式下，使用方甚至都不用懂开发，通过配置后台就能完成系统的开发，开发过程就是配置的过程，工作量小的多；在SaaS模式下，服务方直接提供了完整的系统，使用方只需要付费开通账号即可使用，开发工作量为零。

当然，PaaS、aPaaS和SaaS之所以开发工作量比自研要少，是因为服务方提供了相当多的系统集成能力和开发工具箱，这就要求软件的生成必须符合服务方的开发规范，如果业务需求超出了服务方提供的工具箱能力，就无法满足了。所以从扩展性来说，自研模式是最高的，几乎没有限制；其次是PaaS，取决于服务方提供的开发规范，可以支持外接扩展能力；然后是aPaaS，使用方可以在aPaaS平台上按照平台规范定制软件功能，但取决于aPaaS平台的组件能力；扩展性最差的是SaaS，由于服务方提供的是已经成型的标准产品，除非所有使用方都有相同的需求，平台统一升级，或者使用方付费做定制化开发，否则很难有扩展的可能性。

（1）如果业务相对稳定，需求变化比较慢的业务，更加适合购买三方成熟的软件，如果遇到个性需求无法满足，可以适当定制；

（2）如果需求变化快，有自己的研发团队，更加适合自研，这样可以更加快速的响应业务发展的步伐；

（3）如果业务变化快，研发预算又较小时，适合用MVP的方式最低成本启动试错（自研和三方，谁成本更低就用谁），待业务相对稳定成规模以后，再决定购买三方系统还是完全自研。  

最后，需要强调的是，除了成本本身，数据的连贯性和统一性、系统切换的风险、上下游系统对接的难度、操作习惯的改变等，也都是我们做决策时需要考虑的因素，切不可忽视哦!

—END—