观点一：选择WMS 产品并不难
为什么不难，因为其实只要是主流产品，你无论选哪家的产品都没错。对于主流厂商的WMS 产品而言除非是非常特殊的业务， 否则都是完全满足和胜任的。 而且主要功能都是大同小异。即使是非常特殊的业务，也是可以通过二次开发实现的。用一个贬义词来形容就是WMS 产品在功能层面其实是同质化的。 用褒义词来讲：叫做英雄所见略同，殊途同归。 而在案例方面，每家都能带你去看若干个成功客户。
如果经过评标，结果是某个WMS 的功能远远强于其他公司产品，那可能只是因为这家公司的顾问更好的理解了你的需求， 并很好的阐述了其软件产品相应的特性。
既然是同质化的，换句话说选哪家都一样。扔个硬币就行了。你说难不难？
再补充一个侧面的佐证：郭总当年是EXE 的专家，之后成为MA 的专家，未来可能成为其他厂商的专家。 对于专家而言， 他对于仓库管理业务融汇贯通了，产品就不这么重要了（本身就是同质化的），只是一个工具而已。 如果产品真有这么大的差别，那业界的专家都只能在一家公司终老了。
这个观点比较震撼吧，不过注意，我说的是软件功能同质化，除了功能外，还有很多要考虑因素和各家差异。接下来我们看看应该考虑什么。
观点二： 软件即服务
买一套WMS产品买的不是那几张光盘（光盘无论如何也不值那么多钱）。你买的的是解决你仓库管理具体业务问题的服务，选择重点不是光盘而是服务，即包括项目前期的规划服务，中期的实施服务，也包括后期的维护服务，升级服务和变更服务。
要把服务做好当然不是靠喊口号的，哪家来投标都会说自己的服务好。甲方可以从以下几点去看：
1. 能力
这个公司的人是否真的懂WMS ，懂（或者很快能搞懂）你所在的行业和企业。
同一套WMS，实施的人不同，结果也会有很大差异。就好比同样的笔可以写出围城、管椎篇，也可以写出三重门、杯中窥人和故事会。
2. 意愿
这个公司真的有意愿和决心把你的项目做好吗？ 还是说如果碰到困难或者预算超限找个借口就闪了？
3. 资源
这家公司是否能够在需要的时候，有充沛的可控资源可以调配来解决各种必须解决的问题；
观点三： 购买用得起的软件
接触过一些客户，这些客户从公司IT 惯常投资而言应该是比较节省的，是无法负担高额的软件采购费用的。为了买一套软件，采取了两招：
a. 就把投资费用包含在仓库的基建费里面，由于软件价格相对于基建价格还是非常小的，因此就得到了购买预算
b. 把几家公司都找去，往死里压价格。
最终客户把想买的那套WMS买下来了。王子和公主终于排除万难结婚了，他们从此过上了……悲惨的生活（此后省去1000字）。
购买软件时，千万别认为把软件买下来后就万事大吉了，一定要评估今后若干年的使用成本：
1. 需要增加仓库和用户数时，还需要多少钱
2. 如功能不满足业务发展要求，需要对系统进行二次开发，需要多少钱？ 是否会需要支付海外专家的费用
3. 每年软件运维费是多少钱？
因此我给甲方的建议是买软件千万别太勉强，宁可买稍便宜点的，手上预算有富裕， 有什么特殊情况发生好应对， 强买自己买不起的，表面上看来把价格压下来了好像赚到了（很多女人会跟老公说，今天大打折，我赚了1000块，丈夫昏倒）， 但软件和衣服不一样，软件是服务，衣服是产品。 衣服买下来后就落袋为安了， 服务买下来后才刚刚开始。
观点四： 性能和稳定性比功能更重要
国内客户在采购WMS 软件的时候往往进行功能的评比，很少有客户去进行性能评测。 WMS 是一个实操要求非常强的执行层系统， 而且在波次处理、分配等各环节都涉及到大数据量计算。 再强的功能如果使用起来慢吞吞（让你的操作员恨不得一头撞死，或者掐死买软件的领导），或者一跑分配就是半小时（或更长），并且跑分配的时候还不能做其他操作，对于业务带来的影响是非常致命的。
功能不足可以通过二次开发往上加， 而性能不行往往很难得到解决。我可以很负责任的说，目前市面上某些WMS 产品在性能方面是有非常大问题的。
在实践中吃了苦头的客户可以在心里举个手。
观点五：IT架构很重要
有一种观点是IT 架构不重要，管他.NET , JAVA , PB，VB 只要功能好，就可以买。 IT 部门不应该设定这方面的限制。
我个人不太同意这个观点， 还是回到我们第一个观点： 主流 WMS 产品功能上是同质化的， 并不存在一套软件可以技压群芳， 非买他不可。 在这个前提下，IT 部门根据自己企业的IT 整体规划，对于WMS 采购提出技术上到要求当然是很合理的。
购买WMS 软件千万不能只站在仓库一个点上看问题。 WMS只是企业中的一个相对较小的 IT系统，这个系统如果在技术架构上和其他系统一致， 后期IT 团队容易支持和运维，出了问题好解决。运维成本也比较可控。混搭不是不行，只是确实会增加成本和风险。
具体限制还是不限制取决于企业IT 整体治理能力和策略。 IT 应该要有发言权。
WMS 采购时需要考虑或设限的IT 架构包括但不限于：
a. B/S还是C/S
b. 集中部署还是每个仓库装一套
c. 使用哪种数据库
d. .NET还是JAVA
e. 运行在window平台上，还是unix 平台上
f. RF手持终端架构
作为供应商，我希望企业如果有这方面的限定，最好在引入供应商招标前就说清楚，别把大家都叫去，忙活半天， 最后在投标前出一个架构要求的杠杠。那些被杠杠栏出去厂商前面的心血和成本都白费了，情何以堪。
观点六：功能评分表还是需要做的
很多甲方买WMS 的时候，往往喜欢从网上找来评分表， 让乙方填是否满足的方式来评分。
这种方式我和郭总的观点是一样的，完全是浪费时间。 网上能找到的评分表一般都是某个阶段某厂商做出来的软文，之前有个很流行的表就是High Jump 做的。
当乙方问甲方某些条目是什么意思的时候， 甲方招标者往往自己都不知道，支吾一阵后，说：你们自己看着填吧，也不是很重要。
这种评分表打分会带来两种结果：
a. 所有厂商都全部满足。因为既然没有细致说明和实际业务场景，乙方从字面上做对自己有利的理解当然是合情合理的。
b. 所有厂商都有某些不满足。 甲是1，2，3 不满足； 乙是8，9，10 不满足。 由于这些点不是根据企业自身需求提出的， 因此无法判断到底1，2，3 重要还是8，9，10重要。
这两种结果带来的效果是一样的： 评分表对于招标没帮助，浪费时间。
有些朋友可能会问，根据观点一：功能都是同质化的，那么是否评标就不需要搞功能评分表了？ 就搞技术架构评分，商务评分，服务评分就行了？
当然不是，功能评分表是招标中必须要做的一个非常重要的表。 这个表应该企业根据自己的现实需求（包含部分未来规划的需求）亲自编写出来的评分表。 由于其精练性和必要性，所有乙方都应该必须填：满足（包括产品现有功能支持或承诺二次化开发后满足）；最后大家得分差不多。
这个精练的，体现真正需求的功能评分表，应该签入合同。 功能评分表的真实用途不是评分，而是用于锁定乙方承诺的。
如果你用的是网上的大表，同时你希望逼厂商签入合同，那必然会带来要么厂商提价，你支付你自己根本不需要功能的费用。 要么未来项目根本没法验收。
观点七： 集成
购买WMS 的客户可以分为两大类：物流企业和企业物流。 企业物流可以再细分为流通行业的企业和制造生产行业的企业。 实施WMS 的时候和企业其他信息系统（主要是ERP）集成的难度从高到低的次序是： 生产制造企业，流通企业和物流企业。
物流企业由于是帮客户管货，因此集成主要关注在物上。 而企业物流由于实施WMS 之前，库存和帐都是在 ERP的相关环节中管理的， ERP 实施往往会为了帐，设置大量的逻辑库，这就造成WMS 集成难度大大增加。 如果WMS 厂商只懂仓库运作，对于ERP 账务管理机制和背后的业务需求原因不了解和熟悉的话，项目失败风险极大。
因此在选择供应商的时候，先看看你的企业是上述三种的哪一种。 如果是后面两种，对于集成方面就要非常非常重视了。
在集成能力打分方面，往往会有这样的评分点：
投标方WMS 产品是否和SAP 集成？
厂商甲回答： 我公司WMS 产品提供和SAP 有标准接口
厂商乙回答： 我公司WMS 产品和SAP 有很多集成成功案例， 完全可以在这个项目上实现集成
大部分客户会给甲 5分； 乙3分。
我的建议，甲0分；乙5分。
客户往往担心WMS 产品和ERP 技术上接不上，这其实是不用担心的，现代IT 技术都是开放的， SAP，Oracle，用友，金碟 等ERP 系统都提供多种接口，技术上的连通是非常简单的。
集成最大的工作量在于双方顾问需要研讨如何确保企业业务流程， 在引入WMS后， 能够继续流畅运行，并且得到优化。 这是非常花费时间，精力和需要经验的工作。由于客户的业务不同，流程不同，ERP 实施方案不同， 因此没有任何两个集成方案是一摸一样的。
厂商甲的回答包含了一个潜台词：标准接口
换句话说，项目开始后，他扔个标准接口文档给你，其他就不管了。你需要找ERP 厂商去配合他的接口来完成集成； 如果ERP 厂商也不管的话，你就需要自己做，或者另外花钱找第三方做。
观点八：IT部门在 WMS 选型中的地位
IT 部门介入WMS 选型是非常重要的， 至少和业务部门一样重要，如果不是更重要的话。 这话可能业务选型人员不爱听， 但确实非常重要。
我讨论是基于一般的情况， 在某些企业里面有非常懂IT 的业务人员，或者非常懂业务的IT人员，这种都是特殊情况， 就不在此讨论了。
IT 部门的作用有以下部分：
1. 确保WMS 能融入整体IT 体系中，符合公司IT 规范，不要变成整套明清家具中的一张巴洛克风格大床
2. 确保厂商充分明白集成工作量，正确报价
3. IT 人员比业务人员更容易看懂产品的差异，不被表面的介绍蒙混（简单讲：更精一点）
4. 帮助业务部门把关，业务部门提出的需求确实得到了乙方的承诺，能够达成
5. 帮助乙方把关，不要把不相干的，太理想化，概念性的需求塞入招标要求（结果是赶走诚实供应商，留下习惯于坑蒙的供应商）
6. 由于系统长期运维是要IT 负责的， 让IT 充分参与，调动他们的积极性， 避免出现问题后IT撂挑子不管
观点九：平台化是关键技术
本次WMS讨论的触发是某网友微博问：为什么国际WMS 厂商在国内做不起来。 公正来说，国外厂商在国内还是做了不少单的， 所谓做不起来是和SAP, ORACLE 这些公司的市场领导力相比较。
我们换个问法：为什么SAP ,ORACLE 在中国能够形成如此强大的市场领导力？其核心关键是他们卖的并不是简单的ERP套件 ，他们卖的是平台化的ERP 或者 ERP平台。
中国市场各种行业形态，各种阶段，各种管理模式的公司太多了（全球就更多了）， 任何一家公司的产品都不可能有一个“万能的主”，可以在产品中包含了所有客户需要的功能， 任何功能都可以通过开关配置实现。
要解决“所有问题”的技术手段就是平台化。SAP 的核心层是ABAP平台；然后在这个平台上搭建其强大的ERP系统。 客户和合作伙伴都可以得到ABAP代码， 可以在其上方便的进行功能扩展和加工。同时这些代码又只能在SAP 平台上使用， Oracle 拿到也没用。 这就是平台化软件的强大能力， 他可有构建起由厂商、代理商、独立顾问、客户IT 多个层面的技术服务力量，来满足客户的各种个性化需求和业务流程创新的需求。
国外大型的软件都是平台化的。但由于种种原因，进中国的三家WMS 厂商产品都不是平台化的。 这就制约了其对于客户业务响应能力，和市场产业链的培育能力。 为了解决这个问题INFO（前身EXE） 采用了较为激进的做法， 但带来的后果也非常严重。
当然我讲的平台化WMS产品说的不是“开发平台”。平台化WMS首先必须是一套强大的WMS 系统，具备WMS 所需的各种功能，有大量成熟案例。 同时它又是开放的，客户可定制的， 这才是真正有价值的平台化软件。 没有前者，最多只算开发平台。 开发平台是不值钱的。
观点十：适合的才是最佳实践
曾经微博上贴出来AMAZON收购KIVA 引来一片赞叹之声。 我认为这种赞叹毫无意义。 因为中国广大客户在WMS 上面的投资预算估计只够买他一个机器人的，更遑论配合这个机器人工作所需的各种自动化拣选设备和地面要求。
另一方面即使 AMAZON 使用了KIVA，并不代表KIVA 就是行业最佳实践。我不知道AMAZON 是如何确定使用KIVA 而不是其他解决方案的，但也很可能只是某决策领导被忽悠了，或者想搞面子工程而已。就好比当年沃尔玛放言某某年必须实现全部RFID供货，结果还不是不了了之一个道理。
我的观点是别管AMAZON 或者别人用什么，回到自己的业务现状和亟待解决的业务核心问题， 选择适合自己的方案才是正途。此处“适合”即指功能流程适合，也指投资预算适合。
对于实在想引入KIVA最佳实践，但苦于买不到或者买不起的同志们我推荐可以考虑月租模式的KIVA替代品。一方面节省初期投入，另一方面在每月维修费用，绿色环保，库内安全方面都有更大的优势。