作者：王永谦，上海云质信息科技有限公司

研究领域：制造业质量管理及其信息化

3.6  需求方——企业现状

 

以中国企业为例，首先看一看需求方企业的情况。

 

3.6.1  企业的划分

 

·       按照规模划分--特大型、大型、中型、小型、微型。

2018年底，全国全部企业大约为3400万家。
全国规模以上企业（是指年主营业务收入为2000万元及以上的工业法人单位，2018年4月末）37万个（372355个），占全部企业数的1.1%。

·       按《国民经济行业分类与代码》划分--20个门类、97个大类、473个中类、1380个小类。

·       还可以按产权性质划分，地域划分，国别划分等等。

 

3.6.2  每一细分行业的企业数目

 

尽管有1380个小类，但还是太宽泛，小类仍然包含很多还可以更细分的类别。

·       如类别2661，化学试剂和助剂制造，指各种化学试剂、催化剂及专用助剂的生产活动。很难说出有多少种化学试剂和助剂。

 

·       再如类别4015，试验机制造，指测试、评定和研究材料、零部件及其制成品的物理性能、机械（力学）性能、工艺性能、安全性能、舒适性能的实验仪器和设备的制造。无人能说的清楚有多少种类试验机。

 

372355/1380=270，可以说，但就生产某一类似产品的规模以上企业数远远小于270家。

 

各位读者，您可以就您所熟悉的行业数一数，看一看生产类似的产品规模以上的企业全国有多少家？

 

啰里啰唆写了这么多，只是想说这些企业的相同点就是不同--产业不同，产品不同，定位不同，规模不同，营业策略不同，经营状况不同，技术水平不同，国别不同，产权不同，地域不同，企业文化不同，生产量不同（大量，批量，单件），生产计划方式不同（MTO，MTS，MTO/MTS混合），生产流程不同（连续，批次，离散）……。

 

3.6.3  企业的关注点不同

 

企业对于工业管理软件的各个模块关注度不同，以及该模块能实现的功能的需求也不同：

 

·       以物流为中心的企业，仓库是其利润的来源，期望得到一个优秀的WMS。

 

·       小批量，多品种，交货急类型的企业，APS的水平高低，很可能决定一个企业的利润水平的高低。

 

·       客户产品如果关系到客户健康安全问题，质量控制系统成为企业是否能继续存活的关键要素之一，比如，气体探测行业，核工业，关键零部件行业。

 

·       产量和质量与员工的工作技能和工作态度有强关联的企业，对于员工激励措施和业绩考核人事系统更加关注。

 

·       对于设备价值高的企业，比较关注OEE，比如精密加工，EMS等行业。

 

·       对于医药行业，必须要服从法律法规的要求，合规性是一个关键需求之一。

 

·       希望能详细记录每一个产品的生产过程产品检测参数的企业，大数据处理就可能成为关键因素之一。

假设每个产品有100个参数，产量为每年1000万个产品，那么数据量就是10亿个，不用说做深度关联分析，存储这些数据对传统的关系型数据库就是一个挑战。很多老旧的MES或其它软件，如没有与时俱进重构，就会造成运行速度慢，甚至宕机。

 

3.6.4  企业在不同阶段，需求也不同

 

企业另外一个不变的特点就是不断变化。

这一点很重要，企业的昨天与今天不同，明天会更不同。

 

公司会重组；

生产方式会变；

部门职责会变；

批准流程会变；

产品构成会变；

设备会变；

班组工作形式会变；

激励方式会变；

人员岗位会变；

工艺参数会变；

产品检验标准会变；

原料来源会变；

数据采集粒度会变；

统计分析的需求会变；

……

 

这种不同和变化是由企业本质决定的，企业要生存，企业要追求利润。即使是多个厂家生产完全相同的产品，企业的规模也差不多，企业家每天在思索的事情就是在做出自己的特色，做出差异化（包括产品，经营模式，生产方式等等），找到适合自己发展的生存空间。

 

3.6.5  企业自身特点总结

 

企业相同的地方就是--不同。

企业不变的特点就是--变化。

 

3.6.6  制造企业实施信息化的原因

 

以私企的老板为例，因为私企老板更接近经济学中假定的理性行为决策人，花自己钱，给自己办事，花钱要少，有效产出要大。

 

可能包含如下理由：

确保企业基业长青

追求更多利润

追求更多的客户

提高客户满意度

领先对手

追赶对手

应对未来挑战

政府补贴

企业形象

…

 

尽管会有一些其它理由，应该说大部分企业的出发点还是为了企业的发展，提高竞争力，说到底是为了生存。

 

3.6.7  企业对软件的要求

 

第一，企业第一要务是生存，购买的软件首要目的就是要能给企业带来正收益。

第二，公司的员工可以顺利使用这个软件系统，或者说是能驾驭这个系统。

第三，可接受的价格。

第四，系统稳定，要保证系统可靠性，宕机时间在行业可接受范围。

第五，数据要安全。

第六，能应对生产方式和管理的不断变化。

第七，适用未来数据的增长。

 

这些都是通常的要求，有些企业还对移动端，深度分析，高并发等其它功能有需求。

 

3.6.8  企业的支付能力

 

需求多，需求高，但企业的支付能力呢？

对于大企业还好说，中小企业根本不可能支付超越其本身能力的金额，即使他们有很强的愿望购买。

合适的价格是一个很关键的因素。

但问题是，市场是否能提供出既能满足使用的需求，又能满足价格的需求？

如果能满足甲方的使用需求，但甲方给出的价格会导致乙方亏损，甲乙双方的交易是不会达成的。

美国在“先进制造”中，对于中小企业，也反复强调可支付能力（affordable）。

 

3.6.9  企业信息化现状总结

 

对于中国企业，没有权威的数据来源，各种统计数据之间也不能完全统一，或者是有些统计样本量太小，可信度不高，尽管这样，这些数据可以作为一个大致量级的参考。

目前，中小企业使用比较多的系统是ERP。

中小企业使用ERP的比例大约为10%，主要是财务，进销存，人事管理，其它模块用的比较少。至于MES，大部分还没有，或者是很简单的一些功能。 

 

下图是英国的ERP从2011年~2013年，按照企业规格大小普及的情况（图6）。

数据让人吃惊，超过1000人的企业，在2013年，竟然还有34%企业没有使用ERP，小于50人的企业，没有使用ERP的比例为93%。

 

图6，英国的ERP从2011年~2013年，按照企业规格大小普及的情况

 

3.6.10  中小企业对信息化需求特点的总结

 

·       市场空间巨大。

 

·       行业众多，需求复杂程度超出想象。

 

·       支付能力有限。

 

·       自身信息化水平认知和能力有限。

 

·       要易于理解和使用。

 

·       信息系统给企业带来收益要大于对其的投入，这一点很关键。

 

3.7  供给方——工业管理软件服务商现状

 

3.7.1  项目型软件服务商类型

 

根据公司的经营特点可以分为项目型和产品型。

 

·       全能型：这种公司是什么项目都做，成功案例企业的类型也是各个行业都有，无所不包。客户只要有需求，该公司就能做。要小心这类企业，人不是万能的，企业也不会是万能的。

 

·       聚焦型：通常只做某类产品或某些行业，这类公司几年后，通常会转变成为产品型公司。

 

·       资源整合型：通常只参与大项目，然后将项目分解给分包商，自己是总承包人。公司会有一些产品和IT人员。

 

·       人脉型：主要是国家/政府/大型企业的项目，公司的主要成员通常是学术权威或者人脉关系极广的人，项目金额通常比较大，利润也比较可观。看该公司的网站客户介绍，客户的相同点很明显。

 

·       代理开发型：代理其它公司的产品，为客户做二次开发。

 

·       转手型：公司消息多，公关能力强，项目通常都转交出去，赚取差价。

 

·       散兵游勇型：有项目就找几个临时人员开发，三天打鱼，两天晒网。

 

3.7.2  项目型软件的优缺点

 

3.7.2.1  项目型软件优点

 

存在，就有合理性。

 

如果项目型软件管控的好，能保证质量，又能根据客户的实际要求定制，是不错的选择，通常大企业，有钱，有人，有技术，会采用这一方式。

还有一些企业的管理比较特殊，市场上没有现成的产品，只能定制开发。

 

项目软件最大的优点是适应企业的实际情况，功能不多不少，刚好满足需求。

 

3.7.2.2  项目型软件缺点

 

项目型产品无论大小，都是手工作坊形式，只是档次不同，有的是爱马仕，有的是农夫自己编的篮子，其本质是没有社会化大分工，性价比不高，不能提高整个社会的生产率。

 

通常来说，产品型的软件的性价比要远远高于项目型的软件。

 

·       首先是产品经验，如果要开发产品，通常这个软件公司首先要对这个行业很熟悉，同时对需要也有深入的了解。

 

·       因为产品聚焦，有问题就不断地完善，产品成熟度比较高，同时功能比较强。

 

·       因为是开发产品，相比较项目而言，规划的比较详细，员工比较能深入理解产品，在架构考量上也比较深刻，会考虑到未来的需求。

 

·       开发过程中，对于编写代码的规范，文档，测试，运维相对于项目型软件要好很多。

 

我们一条一条来看，通常的项目型产品是如何开发出来的。

 

·       首先，软件公司通常根据项目的大小，派驻若干人到客户现场，边梳理需求，边开发。

 

·       客户的需求是匆忙制定出来的
如果客户这时经验不足，通常不会对未来有所考虑。客户IT人员，通常不是业务领域的专家。客户业务专家，通常不懂IT，即使这个客户业务专家懂得IT，同时IT人员懂得业务，提出的需求也不可能充分，因为极少人员会花费多年的时间去钻研某一项目的信息化需求，他们都有本职工作要做，通常这些需要都是挤时间，大家一起拍脑袋想出来的，是副业，很多想法太理想化，项目上线以后，发现很多不实用的东西。

 

·       客户经常变更需求
由于一开始需求不周密，客户难免要变更需求。变更需求，意味着改代码，增加工作量。容易造成甲乙双方矛盾，相互埋怨。甲方可能对系统不满意，乙方由于频繁改代码，超出工期，没有赚到应有的利润，最后搞得双方都有怨气，双输。

 

·       语言的选择
由于乙方是项目制开发公司，通常开发公司空余下会什么语言的人，这个项目就用什么语言，对于数据库也是如此。所以你会发现，有些软件公司开发的语言多种多样，产品的界面也风格各异。
即使是公司统一规定语言和数据库，也会有这种问题。道理很简单，软件开发公司可以在一定时期内保持一种语言，但由于IT的不断进步和迭代，语言和数据库一定会变化。
一个项目交付后，软件公司是不大可能主动能给系统迭代升级的。
多语言，多数据库杂乱无章的现象是不可避免的，这是由项目型业态造成的，不是管理的问题，中国是这样，外国也是这样。

 

·       架构的选择
除非客户指定，软件公司通常会选用已有的架构和模块，在此基础之上开发产品，因为这样最经济。软件公司不大可能依据客户业务的特点，仔细选型和搭建构架。

 

·       代码的质量
由于项目是有时间要求的，代码的质量很难保证，各种嵌套，逻辑混乱。即使给足了时间，也不要期望代码的质量会改善，以交付为目标的项目型系统，必然是以能通过甲方验收为标准的，这对乙方是最理性和最经济的做法。

 

·       编代码人的水平
企业是追求最大利润的，必然要考虑到雇佣员工的薪资，能满足需求就好。所以残酷的现实就是项目开发公司往往留不住优秀的员工，除非能提供非常优厚的报酬。有本事的人不大可能会满足每天没有创造性的劳动，必然会去寻找更好的机会。

 

·       系统升级
随着系统的使用，甲方某种程度上要优化改进一些地方，这是很自然的事情。由于开始编写代码都是以快速交付为目的的，很多地方都写死了，大概率也没有开发文档，不用说由别人来修改，就是开发者本人来修改，估计也要花费很长时间才能看懂原先的逻辑。如果是多年以后，公司没有人会当初开发时所使用的语言和数据库，这简直就是一场灾难。

现在还有的企业系统使用的Cobol语言，但是会这种语言人真是不多了。系统运行越来越慢，但又没有方法改进，除非彻底换掉该系统，但是这个系统里面还有大量的历史数据，真是两头为难，此类例子屡见不鲜。

还有，有的软件系统是大学老师带着学生开发的，学生毕业后，升级就非常困难了。

 

·       系统的稳定性
实现功能的代码量与为了预防非正常事情代码量通常的比值为多少？
大约是2：8，甚至是1：9。 写出预防非正常事件的代码通常是非常优秀的开发人员所具有的习惯，同时这个人还要有大量的实战经验。
测试，客户反馈也是很重要的来源。如果是产品，经过多年内部测试和外部使用，bug的水平会控制的很好，项目型软件则不会有这样的改进机会。

 

·       服务水平
应该说绝大部分乙方软件公司都是想服务好客户的，这一点毋庸置疑。但项目型软件公司有没有这个能力才是问题的关键。

我们想着重强调一下，服务水平通常与服务能力更相关，而不是服务态度。至少，对于很多软件公司，甲方对乙方的服务不满意，更多的原因是乙方没有能力服务好。

我们可以脑补一下客户发现bug时的情况。以项目为主软件公司的情况，首先是要安排人记录问题，如果这家公司什么都做，项目的种类很多，客服人员未必能完全理解甲方的问题描述，还得让技术人员再次详细了解一遍。如果是当初的项目人员已经离开，或者时间比较久远，还得重新梳理逻辑系统，重新梳理系统的时间长短就很难说了。企业对于系统修复的时间容忍度是相当低的，不能想象生产停顿下来，长时间等待软件的修复。

没有软件可以完全避免bug，但是可以做到的是：避免严重问题，降低bug率，快速反应。项目型产品，除非甲方完全知道如何控制软件质量，并且能付得起高昂的价格，否则效果不会太好。

 

·       失败率
现在手头上没有关于项目型产品失败率的统计，但是听到很多关于项目型软件失败和废弃不用的新闻。

即使是成熟的ERP软件的失败率都能达到50%，那么，对于大部分订制化的项目失败率则会更高。

本文的后面有ERP全球占有率第一SAP失败率的链接。

 

3.7.3  产品型软件服务商类型

 

很多做项目的企业，经过几年发展，有可能会转变成为产品型公司，毕竟做项目是跟随客户的需求走，只是在卖人头，赚的是辛苦钱，很难形成自己企业品牌和技术的护城河。

 

相对来说，美国的公司一般都是产品型软件企业，印度公司项目型软件公司比较多。

 

·       虚假产品型
这种公司是什么产品都有，成功案例企业的类型也是各个行业都有，无所不包。通常是开发一个项目后，然后对外宣称有产品，产品成熟度非常低。
看一看这家公司的产品介绍，从产品界面就能看出，五花八门，风格各异。

如果一家企业产品多如牛毛，这家公司如果不是像西门子，SAP这样的巨头，就可以得出两个结论，他们是骗子或者他们的产品是垃圾。

还记得吗？被西门子收购的排程软件Preactor有21年历史，质量软件IBS有31年历史，这两个功能可仅仅是MES的两个功能模块，如果能轻轻松松开发出来，西门子何必花大价钱收购。

 

·       聚焦型
少数是由聚焦型项目型公司转变而来，产品数量极少，专心打磨，通常会拒绝不相关的项目。开发有完善的流程，成熟度高。
更多的是新成立的初创企业，创始团队通常在该领域有深厚的经验积累，知道行业的痛点在哪里，市场定位比较准确。定位准确，这一点很重要，很多产品失败就是这点没做好。
美国有很多这样的非常聚焦SAAS企业，非常值得我们关注。

 

·       曾经领先型
产品成熟度不错，也聚焦某类产品或行业，但由于重构成本高，产品没有创新，因循守旧，越来越不能满足现在和未来的需求。
看界面，就会感到古老陈旧的气息扑面而来。

后面会提到不断重构和迭代的重要性。

 

·       巨无霸型
通常是外企，名气响，产品贵，服务贵，反应速度慢，产品不一定适应工厂的实际情况。产品成熟度还不错，为了适应客户需求，通常会找第三方做定制开发。
很多ERP和MES等软件都是产品+二次开发组成的。比如，SAP的ERP，就好比SAP提供积木套装，二开负责把不合适的积木修整一下或添加一些特殊功能积木块，实施团队负责搭积木，产品是否能使客户满意，SAP ERP本身的质量，二开团队和实施能力都很重要。

 

·       前店后厂
通常是知名咨询机构，以咨询辅导名义，给企业提供解决方案，然后夹带推销产品。通常就是一个字--贵。
作为咨询公司的普华永道在中国有1700名IT人员，科尔尼也卖软件。

 

3.7.4  产品型软件优缺点

 

3.7.4.1  产品型软件缺点

 

首先是不需要的功能太多。

 

产品中有些功能是客户不需要的，有些规则比较繁琐或者与企业实际情况偏差很大，但还得遵守，操作起来很不方便。对于办公室的人员还好，但对于生产现场的一线员工来说，这是比较严重的问题。

 

通过调查发现越是与生产现场关联紧密的产品型软件失败概率越大，理由有：

 

1.       管理人使用软件，通常会对工作效率有帮助，实施阻力较小或者管理人本身就强烈需求这个软件。但在生产现场，工人使用软件，对工人本身的改善影响比较小，通常工人会认为这不是他们的工作职责，不会给他们带来收益，阻力较大，甚至找借口阻止实施。工人是数据提供者，但不是数据需求者，这是根本原因。

 

2.       现场的录入数据的环境也不大好。

 

3.       现场员工的离职率比办公室员工的要高，实施和使用成本高。

 

4.       办公室人员与现场操作人员接受能力不一样，如果系统比较复杂，学习和使用成本进一步提高，使情况进一步恶化。

 

为什么会这样？

产品要追求通用性，高通用性意味着有很多的功能和各种开关，自然就会导致操作界面上按钮一堆，再考虑到管理逻辑上的需求，改一个内容要多个人配合，十分麻烦。有的软件又设置了一些快捷搜索代码，操作人员还得准备一个快捷代码记录本，在使用时要经常打开看一下。

如果这样的软件让一线工人使用，是会造成巨大的麻烦。

知名的ERP企业SAP，在上海有400个销售顾问，但没有质量顾问，因为他们知道他们的质量管理系统对于一线员工来说太麻烦。

该系统的质量模块就有550页说明书，能想象出一线工人在使用这个质量模块的心情吗？

该企业的说明书，就是质量经理也未必能理解其描述和逻辑，怎么能期望一线员工理解？

 

在生产一线，那个工人愿意看这个反人性的界面（图7）。

      图7，SAP产品截图

 

还有其它缺点吗？

有，甲方要跟随乙方已有的逻辑系统运行。

二开或定制的收费比较高。

即使是二开，有时也不能完成满足甲方的需求，不是乙方不想满足甲方，是二开也不都是很容易完成的，甚至有些是根本不可能实现的。

 

3.7.4.2  产品型软件优点

 

·       专业性更强，理解行业更透彻。

 

·       系统比定制要稳定，bug少。

 

·       服务响应快。

 

·       安全系统要远远大于定制产品。

 

·       会不断升级，适用不断变化的市场（定制的软件不大可能会主动升级）。

 

·       与其它系统对接，有完备的接口。

 

·       性价比高。

 

·       实施周期相对短。

 

·       产品寿命长。

 

4   工业管理软件解决方案探讨

 

4.1  现阶段是工业管理软件有效供给不足

 

Salesforce 一家企业的全球销售额与MES全球销售额差不多，销售模块的确很重要，但MES销售额绝对不应该如此低。其中的原因有多种，MES的复杂程度要远远大于CRM，这个原因很重要，导致MES有效供给严重不足。

 

要提高有效供给，首先要降低价格，但同时还要保证乙方盈利，否则交易还是不能达成，这个要求是前提。

 

有效供给不足，用白话说就是，可选择的软件产品种类少，价格还贵。

 

现阶段的软件生产，有点像资本主义社会早期，生产方式正由手工业作坊向机械化生产转移的阶段，中国的产品型软件销售占全部市场份额的30%，比例太低了。合理的比例应该是产品为主，定制为辅。

 

4.2  解决方案应是社会总成本最小，社会总收益最大

 

如果判定一个解决方案有没有生命力，就是要看这个方案是否有助于减小社会的总投入，提高社会的总收益，亚当斯密的理论在软件行业依然有效。

 

对于大企业可以任意选择，定制项目型软件可以，购买产品型软件也可以，大企业不是我们文章讨论的重点，我们主要讨论中小企业。

 

中国如果想提高企业的信息化整体水平，绕不过去的事情是提高企业数目占比99%的中小企业的信息化。

 

对于其它国家也是一样，美国，德国，日本，英国等等，都是中小企业占绝对的多数，而且面临的问题也是一样，这在美国政府的制定的“先进制造”中也有清晰的表述。

 

根据本文前边的论述，中小企业的需求是：

·       价格可接受。

·       系统可以被掌控。

·       还得带来收益。

 

那么，解决方案就是SAAS系统.

 

此处的SAAS是指多租户系统，不是指仅能放到云端的B/S构架系统，SAAS好处也不仅仅是甲方不用购买服务器，不用甲方管理服务器，或者是按年支付租金这么简单，如果只是这样认为，就大大低估了SAAS的潜在的爆发力。SAAS真正的优势是边际成本在客户量不断增加的情况下依然可以保持在较低的水平。

 

首先要强调的是多租户系统，这个系统首先对乙方有利，但是很多乙方在销售时通常是不提及这一点的，同时这个系统不一定对某一个具体甲方有利，但对于整个甲方有利，对整个社会有利，这一点好像不大容易理解，看似很矛盾。

 

首先讨论为什么SAAS系统对乙方有利，假设乙方的系统不是一个多租户的系统，如果某一天发现一个bug, 这时乙方已经有1000个客户，如果是同一个语言，同一个版本，也要修改1000次，人重复做1000次，大概率还会在修改过程中发生错误，带入新的bug。如果是不同的语言，不同的数据库，不同的构架，其混乱程度可想而知。这也的确是现在很多软件公司的现状，公司要花费很多的人力保证系统的运行，公司虽然还能赚钱，但是随着客户的增多，公司的边际利润在不断下降，边际成本不断提高。

 

很多公关能力很强，有人脉的软件公司，初期拿到很多的订单，可以快速成长，但到一定规模之后，就很难再长大，后续发展无力，形成了软件行业的资源诅咒，先甜后苦。

 

如果软件公司想降低边际成本，他会怎么做？答案是做成有限版本的软件，把类似的客户数据放置在一起，如果需要修bug，只有修改一次就可以了。

 

天底下，有好的一面，就一定有坏的一面。

 

对于软件公司有什么不好的一面，您可能会想,要开发一个多租户系统，会增加成本，的确是这样，但这个成本不是大问题，如何开发出一个比较通用的系统才是大问题。

 

下面我们逐条展开这个论述。

 

4.3  工业管理软件首先要满足甲方需求

 

这里指的满足不是无条件的满足，至少是在客户可承担的费用条件下，可能还包括，是否可以被客户正确理解和顺利使用。

 

系统首先要有用，对于好的项目型软件这个问题不大，对于产品型软件则是第一原则。即使是大企业软件公司，如果在这方面没有做好，即使是品牌知名，渠道广，营销力度大，市场也不会认可，如本文后续会提到SAP Anywhere 失败案例。

给狮子喂青菜，洗的再干净，也没用。

 

如果系统有用，还要考虑另一个因素，系统是否可以被顺利使用，既系统符合管理流程，企业习惯，以及使用成本不能过大。也就是，系统要有一定的通用性，灵活性。

 

另外一个策略是，系统没有办法增加通用性，灵活性，或者操作界面没有办法做到非常友好，那只能是提高产品的使用价值和不可替代性，甲方也会接受，很多专业工具软件就有这个特点。

 

也就是，有用和通用。

 

有用，也就是说通过对特定行业或某种管理功能的理解，把具象的事务用代码写成抽象的逻辑，并适用于定位的目标客户，并能给客户带来增值。

这个说起来比较容易，做起来难。甲方在这个行业这么多年了，天天想的就是降低成本，增加利润，乙方凭什么就敢说它的软件能带来增值服务？

 

要给甲方带来增值，这就要求乙方一定要把该行业或该模块的内核逻辑想清楚。如果乙方的产品经理不是一群（不是一个）在该领域内资深人士，并且深耕多年，是做不到这一点的（参考一下，被西门子收购公司的平均年限），这与To C 产品有很大的不同。

 

提高通用性，如微服务，PAAS等，这也不容易。不单单是IT技术的问题，也需要对该领域深刻的认知，否则不可能开发出来。还有，提高通用性，如果不提高垂直度，系统复杂度会急剧升高，开发成本难以接受。

 

工业管理软件，首先是企业管理知识，然后才是IT知识。

 

4.4  通用软件必然是垂直细分

 

乙方为了自身的利益，而不得不深度思考产品，在开发之前就要精心策划，要彻底改变以前项目制开发系统的思维。这一点对甲方很重要，对社会也很重要。

 

开发多租户SAAS不能是仅仅收集几家客户的需求，然后就开始写代码。

毫无经验的人，想通过给几个患者试吃不同的药看患者反应，以此变成优秀的大夫，这个想法是可笑的！同样，没有一群在企业有过多年实际经验的人，是不大可能开发出给客户带来价值的通用系统。

 

我们前边已经讨论过了，甲方的需求是千变万化的，写出一个通用的系统之难，难于上青天。灵活性要极大，如果灵活性极大又会带来其它问题。

 

第一个问题是系统复杂，很多中小企业驾驭不了，白给也不会要，这就是为什么很多软件一到生产现场实施就会失败的原因之一。

 

第二个问题是，结构越复杂，数据一多，速度就变慢，很多企业都遇到这个问题，打一个报表要等上一个小时，这个事时有发生。

 

第三个问题是，结构越复杂，Bug产生概率越大。

 

第四个问题是，结构越复杂，升级越困难。

 

这就要求，要平衡好市场的规模，客户需求的边界，客户使用的难易程度，开发的成本，实施的成本和运维的成本。

 

要满足客户的需求，就要增加灵活性，要增加灵活性，同时还要控制系统的复杂程度，只能缩小系统覆盖的领域，做垂直细分市场。

 

此处的垂直细分，有多种表现：

 

·       全功能模块，针对规模较小的企业，模块功能简单，解决基本管理问题。

 

·       全功能模块，抽取某些类似行业的管理共性，解决这些行业的痛点。

 

·       垂直深耕某一功能，如APS，QMS，解决客户该模块的痛点问题。

 

更重要的是，乙方很明白，无论他如何做，是不可能100%满足客户需求的，只能满足客户大部分的需求。即使是满足了客户今天的需求，由于企业也是不断变化的，也可能明天就不能满足了。只有增加垂直度，才能提高通用性，控制住复杂度，让客户满意。

 

4.5  SAAS有助于甲乙双赢

 

举个例子，当父母的很少会担心爷爷奶奶，姥姥姥爷会对孩子不好，为什么？因为他们都关心这个孩子，他们的目标和利益是一致的。

 

项目型软件在目标方面，甲乙双方就相差的比较远。乙方更多的担心是是否能通过甲方验收，收到全款，至于以后的事，以后再说。有些乙方有时知道这样做在未来会有风险，但是为拿到项目，为了能顺利验收，有时也不会提醒客户。

 

非SAAS型产品在稳定性，专业性方面要强于项目型产品，但从本质上没有改变游戏规则。

 

SAAS系统，不用甲方提出要求，乙方为了自己的利益也会这么做，甲方完全是在不知不觉中收益。

 

都有哪些地方利益是一致的？

 

1.       系统升级，甲方根本无需提出这个要求。乙方一定给甲方免费升级，如果甲方要求乙方不准升级，这对乙方一倒是个麻烦事。很多客户在一个数据库系统，要升级，很方便一起就升级了，如果甲方要求不升级，乙方还得把甲方的数据迁移到单独一套系统，再给其它客户升级，但这对双方都没有好处，甲方系统不会得到升级服务，乙方成本提高。

 

2.       系统稳定性。没有哪个软件没有Bug，乙方一旦收到一个甲方的bug投诉，会通过多租户给全部的客户升级，这样平均下来，每个甲方都会感觉到系统很好用，在没有被大多数客户发现之前，系统已经被修复了，极大改善客户使用体验。

 

3.       甲方好的建议，会给全部客户带来收益，社会总体收益最大化。

 

4.       快速反应，甲方发现一个bug，如果没有容器技术，每次系统升级可能用2个小时，甚至更长时间，有了容器技术几分钟就可以完成升级，而且犯错误的概率还很低。
多租户系统会经常升级，乙方为节约时间和降低犯错误的概率，自然就会使用这样的技术，这和甲方的利益也是一致的。项目型的产品很难会用容器技术，乙方也不会主动给甲方升级。

 

5.       乙方为了追求利益最大化，会改变工作模式，由应付客户交付型向追求客户口碑型转变，会深耕某一领域，专家型产品经理会深度思考产品。由于是标准产品，可以做到标准化运营，相比于项目型软件，会节约大量开发，售前，实施，运维成本（这对软件企业是相当大的一笔费用），是更有效率提高整个企业的信息化水平的方式。

 

6.       还是由于是标准化产品，乙方也不需要很多客服人员，由于产品的种类少，客服还可以做到比较专业，提高客户售后满意度。

 

7.       乙方为了增加客户量以及防止客户流失，相对于项目型和非多租户型产品，在新技术，安全，灾备上投入的ROI会有更大的收益。多租户系统一旦出现大问题，会影响到全局。

打个比方，项目型企业如果有1000家客户，就好比用1000个篮子装1000个鸡蛋，很难照顾好每一个篮子，坏几个篮子是大概率事件。多租户SAAS是把这1000个鸡蛋放在一个或少量几个篮子里面，效率高，为了避免风险，会把这个篮子编制的很结实，即使是篮子掉在了地上，也还会用多种其它防护措施。

 

8.       多租户SAAS企业，一开始除了考虑到以上事情，还有高并发，如何应对数据量较大的情况，与其它系统对接等问题，一旦考虑不周，代价会非常大。比如，对接，一旦对接会影响到后面的升级，多租户系统就会失败，就变成单租户系统。

 

4.6  SAAS的基因是什么？

 

多租户SAAS从一出生就注定了：

 

·       垂直细分

 

·       追求技术

 

·       高稳定性

 

·       高性价比

 

这不是情怀的问题，这是不得不这样做的问题。

 

SAAS对中国整体To B软件水平进步也有重大意义。

 

 

5  中国企业如何突围？

 

5.1  中国软件市场大致情况

 

2018年，中国软件和信息技术服务业规模以上企业为3.78万，业务收入为63061亿元，实现利润为8079亿元，利润率为12.8%（图8）。

图8，中国2013年~2018年，软件业务收入

 

软件产品收入为19353亿元，占全行业比重的31%。

从业人数为643万，人均产值为98万元。

中国软件占全球的5%左右，美国为25.6%，中国可发展的空间还很大。

中国软件和信息技术服务业出口额为554.5亿美元，中国软件服务商的市场主要在中国本土。

 

5.2  国际大公司的软件是不可战胜的吗？

 

国际企业巨头，如西门子和SAP不仅领先发展这么多年，而且还收购很多市场中的优胜者，中国还有机会吗？

 

我们就以据说80%世界500强都用，ERP市场份额第一的SAP为例（图9），看一看它的客户满意度如何。

图9，2017年，ERP全球市场份额

 

5.2.1  SAP能让中国客户满意吗？

 

SAP当然有好的一面，但也有需要改进的地方。

下面是网上可以搜索到的部分公开信息。

 

·       1992年，上海机床厂购买SAP R/2系统的全套解决方案，实施6年，最终只成功存货管理，且每年服务费难以承受。2006年，上海机床停止与SAP合作，换成用友系统。

 

·       1999年，长虹在SAP实施“灯塔计划”时购买了SAP R/3，累计投资5000多万元人民币，结果却差强人意。2003年初，长虹内部人士说：其零部件的库存准确率只有60%，产成品准确率只有25%，系统的作用仅仅是打打单据，该采购什么、生产什么，还得相关人员到仓库去清点。

 

·       2003年11月，广东至高空调投资200万购进SAP 的 mysap.com，2004年8月，项目全线终止。 

 

中国人通常是吃苦遭罪都自已咽在肚子里，但很多实施失败项目没有被公开。

不仅如此，SAP在宣传资料上还把上海机床厂和长虹当作成功案例，如果不是相关人员说出真相，很多企业都暗自认为，只有自己的项目失败了，其它公司的都成功了。

 

另外一个原因导致在中国不知道SAP失败率有多少是很多CIO选型SAP ERP就是出于私心，为了逃避未来可能的失败责任，反正我已经选型了世界上所谓的最好的ERP，实施失败不是我选型失败，肯定是咱们自己不好，而不是SAP软件不对。

 

即使是所谓实施成功的企业，SAP的确能运行，但就像花费200万买一个高档车，但每次用它运一块砖头，还得配备10个司机，不知道这样是否也算是成功。

 

5.2.2  SAP能让外国客户满意吗？

 

实施不成功，是否只是中国企业水平不行？看一看国外的报道。

 

·       1993年，全美排名第四的药品批发公司FoxMeyer Drugs, 花费1亿美元实施SAP R/3 ERP。系统上线时，客户订单每晚从420,000下降到10,000，因为新系统应付不了交易量。在花费1亿美元和4年后，这个医药巨人破产。

(How a Failed ERP Implementation Took Down the FoxMeyer Drug Company. Four years and over $100M later, the pharmaceutical giant filed for bankruptcy.)

 

·       1999年，惠而浦公司SAP ERP项目，导致发货延迟6~8周，造成客户取消订单，极大地影响了公司业绩。

 

·       2004年，惠普SAP项目最终导致惠普1.6亿美元订单积压，收入损失超过项目估计成本的5倍。

 

·       2009年1月14日，美国computerworld.com报道，Jeweler Shane（销售钻石）公司指责SAP的软件很难上线且导致该公司破产。

（SAP project costs cited in jeweler's bankruptcy filing， Shane Co. says it has also had functionality problems with ERP system installed in 2007）

 

·       2012年，美国的National Grid 公司，实施SAP系统时，造成员工工资和供应商货款支付错误。

 

·       2018年，德国超市巨头Lidl在花费5亿欧元和7年时间后，宣布废弃（scrapped）SAP 项目。

 

·       2019年1月15，媒体报道SAP S/4HANA迁移问题导致小熊糖在德国缺货。

（How a troubled SAP S/4HANA migration caused a gummy bear shortage in Germany）