这是物流软件SaaS漫谈的第二辑。上一辑主要围绕物流软件SaaS产品是否应该免费、获客策略（选大客户还是小客户）、客户留存管理等几话题做了一些探讨
在第一辑中提到了传统软件厂商在向云端迁移的趋势。以甲骨文在今年第四季度发布的财报为例，其SaaS和PaaS的营收比去年同期增长66% （尽管云端营收尚未超过总体盘子的10%）。但如果关注Oracle的话就会理解它的转型很大程度上是依赖并购实现的 - 甲骨文仅从去年至今就已完成了包括Opower, Ravello, Textura, Taleo以及Netsuite在内的多家云端产品的收购（Netsuite日前以93亿美金的价格成交）；SAP的主力SaaS产品SuccessFactors，Ariba，Concur也均系收购而来。相比这些资金充沛、具有相当市场统治力的传统IT软件巨头，传统物流软件软件厂商的转型之路又在哪里呢？
1左右互搏的烦恼，怎么释怀
一旦传统物流软件软件厂商做了物流软件SaaS就会颇为尴尬地发现不知不觉已陷入两难境地：
从二者的目标客群及销售渠道/获客方式上看，传统TMS/WMS卖的是具有高度定制化需求并希望得到顾问式咨询服务的那部分客户群体，其销售的过程也需要完全依赖BD/顾问的“地面式作战”和贴身服务。而SaaS TMS/WMS则更强调通过产品化、标准化的应用来满足客户至少95%的核心诉求（所谓通过花传统软件50%的钱，来解决至少95%的业务问题）,在产品的快速迭代过程中，也是尽可能去考虑功能的复用性以更多地解决行业客户的共性问题，而并非某个单一客户阶段性的过度需求。因此，传统物流软件软件和物流软件SaaS产品面向的客群是有一定程度上的错位；同时，物流软件SaaS在获客方面，除了凭借传统的地面销售之外会更多地利用线上及产品本身的传播和转化效应。
如果通过传统物流软件软件团队来卖SaaS产品，一套传统TMS/WMS动辄上百万的单子，SaaS产品还怎么去卖呢？即便实行incentive激励，但由于两个产品线高频接触客群的有很大的错位，也会导致销售团队很难带来好的SaaS产品销售商机，这也就是为何通过传统销售资源共享来引流SaaS产品很难取得好的效果。
系统架构和产品理念，这就从底层体现了传统TMS/WMS和SaaS产品的最本质的不同 ——这就好比PC思维和移动端思维的差异绝不仅仅体现在传播媒介的迁移。这件事最终体现在人上 —— 做传统TMS/WMS和做物流软件SaaS产品的人，对其所需的核心能力和目标导向是不甚相同的，因此怎样能不受既有传统产品条线既得利益和思维模式的干扰，最好的方式就是完全打破原有体系，重建一个SaaS实体，而最有效、最快捷的方式就是通过收购来获取具有SaaS产品基因及核心能力的团队并保持独立运作。
2通过“混合云”构建物流软件平台是伪命题吗？
首先要明确，并非在原有传统物流软件应用产品之外再开发一套基于云端的物流软件产品，并把二者做简单叠加就成了所谓的“混合云”，这就好像说并非数据“大了”、“多了”大了，就搞成“大数据”了。
以TMS运输管理应用为例，“混合云”的应用场景把业务数据部署在本地服务器，并调用云端的计算能力。但事实上运输业务的痛点绝不是数据量过载、计算能力不足的瓶颈，而是在于运输链条各个层级割裂，横向、纵向互动低效造成的信息不对称和资源错配。从这个角度看，所谓物流软件“混合云”的TMS没能真正解决物流软件“私有云”TMS解决不了的问题，传统TMS架构下的一个个信息孤岛在更强大的计算能力驱动下，从“小孤岛”变成“大孤岛”。对货运物流软件平台而言，“混合云”的模式也无法通过企业间协同来优化供需资源的配置，更无法通过网络效应赋能，因此其提供的仍只是传统工业框架下的软件工具生产服务，而无法真正地实现平台化。oTMS段琰在今年3月份《佘山论剑 – 供应链管理精英论坛》上有一段针对运输平台化分享：
以运输平台化为例，要实现协同和网络化可以从横向和纵向两个角度来看 ——
纵向垂直链条的协同与高效互动
运输链条上延展开的业务合作伙伴通过同一个SaaS平台连接起来，首先可以在同一个货主主导运输网络中实现协同与高效的互动。
横向的货主间协同与资源集约
货主间协同是真正意义上的结构性优化，可以最大程度上驱动整个运输链条上的资源匹配更加均衡、高效。
对于传统物流软件软件厂商而言，是希望通过孵化新的SaaS战队来真正走向平台化，还是继续守住传统软件业务，做个专而美的，面向物流软件垂直领域niche market的专家？你的看法呢？
