谢会忠 罗戈研究

※

从2019的一言难尽，到2020的妙不可言

——物流SaaS软件应用

谢会忠

为何SaaS软件会越来越难做呢，是什么矛盾导致了物流SAAS应用领域的难题？套用一句话——

对于SaaS软件从业者来说，物流行业既然是一个特定行业，就一定有行业共性，只要抓住了行业共性，客户需求就能满足七七八八；只要做出了一套符合行业共性的SaaS软件，躺着赚钱的日子就不远了。

对于SaaS软件使用方（物流公司或物流部门）来说，我的企业或者我的项目，本身是有特色的，它不同于其他一般公司项目，你这软件必须要按照我的要求来修改和实施。什么，你是SaaS软件不支持定制修改？那你告诉我这功能有那功能也有是啥意思？要么你按我要求改了，否则这合同就到此为止，休想蒙混过关。

甲乙方从相爱至相杀，大体都离不开以上场景。

那么，是什么原因造成此类矛盾重复发生，乃至于把一些公司（甲方乙方都有）拖入绝境呢？关键还是双方价值观的不同：甲方（物流公司）希望少花钱多办事；乙方（软件公司）希望少办事多赚钱。两个价值观完全背道而驰的公司，勉强合作的结果，必然导致软件项目的崩溃。

实际上，作为占GDP约15%的物流行业，市场规模相比于其他任何行业领域都要来得大，并且它几乎贯穿于任何一个行业产业的供应链交付过程中。所以，从物流管理本身来说，物流软件是一个既广而又复杂的系统，它的复杂程度不会低于任何一类行业软件（包括ERP软件和财务软件等）。

因为物流软件的复杂性，所以其价格一直以来也是高高在上，早期的国外WMS和TMS价格都是百万级以上的；即使是后来国内各模仿者的加入，也仅仅是将价格稍微拉低了一点，到几十万的级别。为什么呢，因为实施一个项目真的是“太难了”，需要花费太多的人力对软件进行定制以及对客户进行大量适应性培训；商业的本质决定了软件商不可能做赔本买卖。那为什么打着SAAS旗号的物流软件能把软件价格拉低到令人咂舌的程度呢。

2. 各种新商业模式对物流信息化的要求

一段时间以来，各类新商业模式雨后春笋式的爆发，从以前的“卡车航班/落地配”，到后来的“城市共同配送”，再到现在的“新零售物流”。大家一方面对新商业模式跃跃欲试，但又害怕投资风险，浅尝辄止。因而注定在项目投资（包括物流系统投资）上畏首畏尾。而另一方面，既然是新模式，就避免不了摸索中前进，各种试错成本是少不了的。新模式的创业者们很容易只看到成功的希望，却忽略了过程中的风险。

投资是风险、市场是风险、运营是风险、信息化本身也是风险。很多人不是想着如何去降低风险，却更加关注风险发生后减少损失；因为投入少，所以即使风险发生了也没啥损失。殊不知，包括信息化方面，减少投入本身就是最大的风险。

3. 各种小规模搅局者的存在

不得不说，不管是仓库业务还是运输业务，物流从业者中仍然存在大量的搅局者。基本上是凭借和甲方的特殊关系来拿项目。这类搅局者本身并不具备专业物流管理能力（不管是资源掌握能力、项目运作能力，还是资金投入能力），他们大多依靠某单一的项目生存。因此这类物流企业的项目大多是以短平快为主。这也注定了他们没法在信息化上做太多投入。而为了维持和甲方的关系，至少表面上要让甲方看到是专业的，迫不得已需要上一套管理系统。

可以说，物流SaaS软件的应用促进了物流行业的洗牌。好坏暂且不论，但有和没有，是判断一个物流公司是否具备基本业务管理条件的硬标准。

基于上述几个原因，一方面物流市场要求从业者需要从信息化上体现其专业性；而另一方面从业者本身因为各种原因又无法在信息化上做太多投入，因而催生了SAAS应用的爆发。大部分SaaS软件供应商都是打着低成本和快速部署的旗号进入这一领域。

低成本的SaaS一定好吗？也许它在企业（项目）发展初期能起到一定的作用，但随着企业/业务规模的发展，各方面的管理需求都要附着在这个软件上。而SaaS软件的特性决定了“这也不能改，那也不能改”；即使能改动，也是被迫发部单一版本，物流企业习惯了廉价的SaaS后，是否还能够接受高昂的“独立部署”代价。如果甲方企业没有从廉价的思路中转变过来，结果是必然是患得患失，业务发展因为SAAS应用反而受到约束。

上帝要使其灭亡，必先使其疯狂。物流软件的SAAS应用领域，从2014年开始火起来，经过这几年的发展，到2019年已经明显到了分水岭阶段。某知名TMS软件从拿到投资开始铺天盖地的宣传，压得“友商”们喘不过气来。一些传统物流软件厂商被迫也推出SaaS的应用。也有不少跟随及模仿者，因为有“后发优势”做得也是有声有色。可以说，物流SaaS的应用进入了类似于2010年团购兴起时的“百团大战”阶段，并且似乎快要分出胜负了。那么，SaaS服务商们都通过什么手段来竞争呢？

1. 价格战，永远的制胜法宝

舍得一身剐，敢把皇帝拉下马。价格战永远是没有最低，只有更低。从最初上百万的专业级软件一路被竞争到几千块乃至几百块一年。竞争的结果似乎是让客户捡到了便宜。但以往的经验告诉我们，给你便宜了多少必将在未来加倍的还回来。百蛊竞争王者归来后，所有的荣光必将归于一身，某嘀打车也好、某（念man）帮也好，都是这个道理。到时候人为刀俎我为鱼肉的感受如期到临。当然，蛊虫之间的竞争，未必是体大腰粗的就能坚持到最后；个头大的，受攻击面积也大，如果没有深厚的内力作为依仗，反而容易最先倒下。

在价格战期间，“便宜没好货，好货不便宜”的规则已经不适用了。说实话，价格已经这么便宜了，多出一块（万）两块（万）的已经不是主要问题。唯一的判断标准就是亲自试一下是否合脚；甚至不能仅仅凭借试一次的感觉，至少要多试几家，找到最合脚的一家。

当然，甲方也要做好这个心里准备，一旦价格战决出胜负，价格回归理性是必然的。理性的价格一定是以服务提供方的成本相匹配的。甲方到时如果接受不了这个价格落差，那一定是很失落很失落。那么，保护好自己看好的服务商，让他们不至于在价格战中彻底消亡。硝烟散尽后，大家还可以相互一笑，终于可以踏实做事了。

2. 功能战，有多少爱可以错过重来

前文已经说过，物流系统（不管是仓储系统还是运输系统）是个复杂的系统，各个行业、各个公司、各个项目，乃至各个不同的人，都对其有不同的理解。即使是国外那些大型物流软件也无法做到通吃。而号称无所不能的SAAS软件，在打完价格战后，还要满足以上所有要求，其难度不言而喻。在这种环境下，不同服务商采用了不同的对策。

（1）另立品牌，由繁化简

某知名WMS服务商，已经在市场上做得风生水起；但为了实现通杀，专门另立品牌，强行介入SAAS应用市场。软件产品其实很难和普通商品一样做成同一品牌不同档次的产品。服务商既要保证高端市场的利润率，又想要低端市场的占有率。结果必然是面向低端市场的产品“低端化”，也即是对产品进行阉割。但实际结果是，客户并不对被阉割了的产品买账。他们的理由很简单，软件产品的边际成本基本为零，你为啥不好人做到底送佛送到西，把全功能的产品都给我呢。事实上，客户们可能不知道，软件服务商由繁化简不一定是不愿把功能完善的软件给你，而是即使给了你你也消化不了。（消化差点打成笑话，功能完善的产品交给客户，确实很容易出笑话）。

（2）由简入繁，新手慎入

这段时间经常听到这几个词“降维打击”、“跨界打劫”，说的无非就是本来不是你这个行业领域的人进来抢了你的生意。物流SAAS应用市场的混战，大都源于一些新手入行。有的是做了某个物流定制项目，认为掌握了真谛，然后进入了这个领域；有的是某些大企业（比如某东）建立了庞大的信息化体系，服务了自己的物流业务，然后认为别的物流业务也大体如此；也有的纯粹是因为感觉这是个蓝海，值得进来冒险一试。

不管因为何种原因，想当然的原因做出的是想当然的软件，结果当然是到处碰壁。没有经过系统的理论学习、大量的实践经验、以及深思熟虑的设计，在业务框架和数据库结构上很容易存在致命缺陷。2019年我们也接手过好几个这类被做坏了的项目。

总之，在物流SAAS软件设计上，由奢入俭难，由俭入奢更难。不管你有多大的背景，有多大的投资；轻易下水的话，一定会被呛得够呛。

尽管说了些耸人听闻的话，但目的并不是要把所有人都唬住，而是希望甲乙各方都理性回归到SAAS应用本身，认清SAAS的优缺点；SAAS不是万能的，在适当阶段能发挥其最佳效用。作为甲方用户，需要从以下几个方面来判断和选择SAAS应用。

1. 确定自己的真正需求

真正需求也即是需要解决的主要问题。首先，物流SAAS软件其实和其他所有应用软件（ERP或财务软件等）一样有它的应用边界。不要指望SAAS软件去解决应用边界范围之外的需求。比如有客户要求我们WMS功能里包含派车功能，说只要做一下简单的车辆信息登记就行。这个需求被我们拒绝了，不是这个需求是否简单，而是如果同意了这个要求，过不多久他就会要求再加上一点车辆状态记录，然后再要求加上一点签收回单记录等。其次，认清主要功能和次要功能。比如WMS主要功能是管理仓库收发货和货位管理等，而计费功能是相对次要的，尤其是针对一些复杂的计费逻辑，大部分都是要经过定制处理。如果客户忽略主要功能而揪着次要功能不放耿耿于怀，长此以往一定会是不欢而散。

2. 认可乙方的服务成本

没有无缘无故的爱也没有无缘无故的恨，如果是纯粹的软件服务，那羊毛一定是出在羊身上由吃羊肉的人买单。甲方提的要求，乙方来做一定会发生成本；如果甲方支付的费用包不住乙方的成本，这个生意一定长久不了。如果甲方以终止合同来要求乙方提供超出成本的服务，这其实是另外一种行业压榨，没有谁愿意在受压榨的情况下快乐的干活。甲乙方在不同场景时，角色是会对调的，乙方在被逼到绝境的时候，也会有对甲方的决绝。良好的沟通，适当的妥协，是甲乙双方和谐共处的基础。

3. 要有一定的业务分析能力

没有金刚钻不揽瓷器活，但大部分软件客户，实际上是没有这个金刚钻的。很多客户会认为自己有很丰富的业务经验，然后就要求软件服务商必须按照自己的思路和要求来调整软件。殊不知，软件本身是源于业务而高于业务；实施一个软件除了要有丰富的业务经验，还要有足够严谨的逻辑判断力。简单的说，软件服务商最怕遇到半瓶子水晃荡的；说的是表面合理实际上逻辑根本不通的要求。而比较好实施的项目是，要么甲方有足够的分析判断力（专业级的能力），乙方按照甲方要求来做；要么甲方彻底相信乙方的行业经验，按照乙方的建议来做。软件项目如果没有了甲乙双方的信任基础，而纯粹变成命令式的（甲方命令乙方），这个项目就很难成功。

4. 消除对软件安全的担忧

客户经常会担心的是，我的数据放在你们服务器上安全么。这个问题要从两方面看，一方面是客户自己有没有足够的能力（包括资金能力）来提供更安全的部署；如果有，那没得说，你自己部署好了。另一方面，相信软件公司来维护软件，安全性上一定比客户自己维护更可靠，毕竟软件开发者对软件更熟悉。至于数据泄露风险（怕乙方泄露商业机密），完全可以通过合同协议来约束。

5. 拿到源代码不是终极保障

经常会遇到客户要求提供源代码，这是对未来极度不安的表现。客户的理由是，万一你提出极端无理的要求，我们就自己干；或者是，万一你们公司倒闭了，我们有源代码还能自己维护。我们先不说源代码是软件公司的终极核心利益；仅从甲方获得源代码的代价来看是否合适。首先是甲方为获得源代码，必然要付出额外的代价；其次是，甲方为了实现源代码级别的维护，付出的代价一定比由乙方来维护的代价高。源代码的学习成本很高，想吃透一套成熟软件的源代码，没有半年一年时间是很难搞得定的；第三是，甲方靠一两个人是很难实现源代码级维护（以及开发）的，一般都要四、五个人的团队，而乙方只要一两个人就行。

所以，甲方完全可以以远低于购买源代码的成本（包括衍生成本）来和乙方建立更牢靠的合作关系，这对双方都有利。

不管如何竞争，作为软件供应商至少要保证自身的生存底线。而保证生存底线就要合理认识到自身在行业内所处的位置，一味的拼价格、拼功能、拼承诺可能会把自己陷入恶性循环，陷入一些无休止的具体项目需求，而无法将视线投入到更广阔的市场需求。这就要求软件供应商需要关注以下内容。

1. 不要急于将新软件投入市场

虽然新软件快速投入市场能迅速给自己公司造势，但如果过急投入市场，可能会面对大量需求变更的要求。在没有合同的情况下，可以有大量的时间从容设计产品；通过多个种子用户来验证软件功能。而如果急急忙忙投入市场，在合同和工期的压迫下，即使是产品级的需求变更，为了赶进度也很容易造成草草改动了事，这种修改对于SaaS化的运营是有害无益的。

2. 设计足够健壮的、松耦合的功能模块

足够健壮本身是一个很笼统的概念，简单地说就是软件核心功能不容易出错。如果任何一个需求变更都可能会导致核心功能的调整，那这个软件在经历过多个项目需求调整后将变得越来越难以维护。松耦合其实是软件健壮的一种设计思路，也即是软件功能模块之间尽量越少的关联越好。最常见的松耦合做法是将新增功能做成可配置项，原有客户默认为该功能不打开。松耦合体现在数据库设计上是，尽量不要在原有表结构上增减字段；而是通过建立新的关系表、扩展表来扩充功能。

3. 选择合适的软件部署方式

作为软件服务商，最希望的当然是一次部署到处应用。但是有时候又不可避免的因为特殊原因导致必须要单独部署。这个原因一方面是因为客户的特殊软件功能要求，导致一些改变无法部署到统一服务上，必须要单独部署；另一方面也可能是因为客户要求必须要在数据上和其他客户做物理隔离。独立部署一定会占用更多的服务器资源，为了保证以最低成本满足客户需求，软件服务商就有必要建立自己的私有云。

4. 保证数据安全

任何客户都关注数据安全，任何一个数据安全问题都可能将软件公司陷入万劫不复的困境。数据安全包括维护时安全和运行时安全。有些项目的维护不可避免的可能发生直接对数据库的操作，尤其是对删除数据的操作，一定要建立严格的数据维护安全管控机制，防止有意或无意的误删除操作。绝对不允许出现“删库跑路”的情况出现。而在运行时安全上，需要考虑数据库服务宕机、操作系统宕机、服务器硬件宕机等情况，建立三级备份机制。

5. 专注擅长领域不盲目扩张

不管是个人还是公司，都有自己擅长和不擅长的领域。作为软件供应商，需要扬长避短做自己擅长领域的业务，这样才能起到数半功倍的效果。多年前戴定一会长曾公开叮嘱，软件公司一定要专注一个特定领域，不要想面面俱到，想面面俱到看起来所图甚大，但结果很容易是处处碰壁。这种情况曾经发生过，并且也正在发生着。

read the whole passage