WMS系统架构设计的演变与选择

WMS发展到今天，在功能上已经非常成熟了，基本上各家的产品在功能上已经趋于同质化了。以至于有些厂家在介绍自己产品功能的时候可以说：同上家！

WMS产品虽多，但总体上可以归纳为三种：定制、开关驱动型配置、流程驱动型配置。从发展历程上，估计从定制开始，经历了定制、开关驱动型配置、流程驱动型配置。随着业务复杂性的不断提高，这三种类型的优劣型也在发生着变化，为了造福后来者，现开帖对此三种类型的优劣型进行讨论。厂家可以辩论，用户可以发表自己的使用感受。

个人认为“基本上各家的WMS产品在功能上已经趋于同质化了”这个说法比较重，如果认同了等于认同挑选了任何一家都一样，只需要拼一下实施能力和价格。而事实上，各家的确都有几个自己比较专长的行业。而在自己专长的行业中，的确有些比其他厂家做的出色的功能。反过来说，只要A厂家有一个比较出色而且市场需求大的功能，其他厂家一般也会尽量加上这些功能，因此，客户在选型时，的确会觉得“都一样嘛！你讲的功能上家也讲过，他们也有”。这可能是“同质化”一词流行起来的原因吧。事实是，有不少想加进系统的功能流程是受制于系统本身的底层架构和设计的，有时候也只能加个表面而欠缺深度，但这个程度的区别并不是那么容易被客户在选型的demo、RFP/RFI回复、甚至POC中看的出来的！

有一次我机缘巧合看到一家非常小型的国内WMS厂家（“厂家”两个字好像不太适用于他们吧？）的PowerPoint deck，吓了我一跳，那就是多家国际厂家的精华功能Slides组成！而且还是你愿意出多少钱他就能卖多少钱！估计他们控制研发成本非常有效，否则如何能生存？十多年来，我反复的讲解WMS功能，在不少的场合中感觉到听众用眼神告诉我“都一样嘛”，慢慢的我意识到不管如何讲功能，都很难让听众听出区别来。“有些厂家在介绍自己产品功能的时候可以说：同上家！”，有趣！巧！最近我的确也常问听众“你们想听听功能介绍吗？想听我可以讲，但估计你们听下来会觉得：跟前面几家差不多嘛！”。注意，我说的是听众都会觉得一样，而不是我认为事实上是一样。

我们聊聊“开关驱动”和“流程驱动”吧，大概40年前McHugh（后来RP，现在JDA）率先发布套装WMS，紧跟着有Dallas System（后跟Neptune合并成EXE，然后SSA，现在Infor），HighJump，MA，Neptune等相继在八、九十年代陆续成为套装WMS的领头知名厂家。多年以来，市场都沉醉在Highly Configurable也就是“高可配置”，也就是用同一套软件，通过开关和参数配置来满足不同的业务需求。于是，几乎所有厂家都跟着这个方向走，研发重点都在于如何透过增加开关和参数来加强系统能提供的功能和流程，所以多年下来的研发，开关和参数也就越来越多，而系统“在理论上”也就越能满足不同行业、不同业务的功能和流程需求。为什么是“理论上”呢？因为很多应该有的功能流程，并不一定能配出来的！

开关驱动型WMS：

思考一下：给你50个开关（每个开关一般都有2到5个参数），虽然比较容易控制整个系统，但你可能觉得能配出来的功能流程不够用，不爽；给你几百个开关，你开始兴奋了吧，可以变出来的花样还真不少！给你一千多个开关呢？你知道一千多个开关，加上每个开关有2到5个参数，能有多少个排列组合吗？？？谁能准确预估每个排列组合对功能流程带来怎么样的变化？没有人！原厂的顾问也不能！

这个“高可配置”对客户来说更像是面对大海时口渴，能看不能喝！有谁实施了这样“高可配置”系统的人试过自己去改过配置的？小的配置或者有，关键配置估计没几个敢碰！不信你自己去打听去问问！那么厂家或者实施商在实施时如何配置的呢？答案是”Try & Error”，意思是这样配然后试试行不行，不行的话那样配再试试，不断的重覆直到“配出来”想要的功能流程，在很多的情况下，顾问实在找不出应该开或关那个开关和相关开关的参数应该放什么值，所有顾问也只能打开系统研发的技术说明书，看看里面的逻辑（比如：If table_x.field_y = value_z then doThis）才知道应该去看看和配置table_x表里的field_y字段！现在大家明白为什么成熟产品，只需要配置（感觉好像打开个开关那么容易的事）但实施的配置和测试时间确需要好几个月了吧？？？别怪厂家，他们没有骗你的工时（就是实施费），他们也很苦，他们的确需要不少时间去配置和测试的！

还有不少的情况是，明明知道某一个功能流程是可以配置出来的，可就是无论如何也配不出来，可能是bug，可能是找不到在那里配，因为这配的过程真不容易，因为你配的时候虽然是为了配一个流程可是你做的却是去某个画面勾选一些属性，另一个画面改个参数等等，你完全无法把你在做的事跟你想要配出来的流程关联起来。你可能会开始想“如果可以像画流程图一样，把流程的逻辑关系弄好了，我就得到我要的流程，那该是多美好的事呀！！！NND，勾来选去、反复测试的，我这是在配置流程吗？像在猜谜语吧！说回来，配不出一个应该有的功能流程，顾问会怎么办呢？顾问会问客户能否调整一下流程或者加点钱和时间动源代码开发？我这个要求明明是合理和高效的，凭什么要我放弃？当预算我的确没了，咋办？

当然，不管是什么型的WMS，顾问的行业能力永远都重要，因为行业能力强的顾问可以帮客户设计出更加合理的流程，所以不管你是什么型的WMS，缺少了这样一位（项目中有一位这样的强手就够了）项目就险了，除非客户本身就有这样一个强手。

可是，从上面不难看到，开关驱动型的WMS对负责配置和测试的顾问的要求也是非常高的！否则就非常难在有限的时间内通过Try & Error的方法把设计好的流程配出来，他们必须要非常熟悉在实施的WMS，否则无法有效完成工作。还有一点是，上线后，客户方参与实施的人员应该也能Trouble Shoot一下系统问题的，但时间一久，在当初参与过实施的人员自然流失和升迁后，想再内部培养一些人就非常不容易了！

流程驱动型WMS：

这个类型的WMS的特色是，对一目了然的配置它也提供了开关和参数，但对比较复杂的流程的配置它放弃了提供开关和参数，而选择了提供一个“业务流程配置工具”！系统里面的任何一个流程都可以使用这个“业务流程配置工具”来进行修改！更让人兴奋的是，如果你需要一个全新的流程，你完全可以自己使用“业务流程配置工具”来配置出全新的流程！

从80年代到00年代，市场疯狂的迷恋开关驱动型，所以HighJump一直无法攀上顶峰，但HighJump 30年来始终坚持走平台化路线和流程驱动模式！研发精力除了放在加强WMS产品本身的功能流程，也投放了非常大量的研发精力去加强她的平台和“业务流程配置工具”。

HighJump的WMS出厂时就具备了积累了30年的行业经验带来的常用功能流程，而每一个流程都配上相关的流程图，这些流程图在名为Architect的“业务流程配置工具”都有对应的流程逻辑代码（比常见的源代码更加容易明白，任何看的懂流程图的人就能看的懂这些逻辑代码）。

实施时，当然也需要一个行业能力强的顾问，为客户设计出合理的流程：第一种情况是可以选用一些原有的流程；第二种就是把现有比较接近想要的流程做些修改；第三种是创建出新的流程来满足需求。

第一种情况就不说了；第二种情况，在设计阶段先相关的流程图上做出修改，然后交给技术顾问在Architect也就是“业务流程配置工具”里看着流程图把对应的逻辑代码修改；第三种情况，在设计阶段按照新的流程画出对应的流程图，然后技术顾问按照流程图在Architect也就是“业务流程配置工具”中创建出新的一套流程。

比起开关驱动的勾来选去、反复测试，在Architect里面配置新的流程或者修改现有流程明显更加的直观！你要做的是修改一个流程，那你就看着流程图直观的做修改而不是毫无流程感觉的去动开关改参数；你要加一个新的流程，也是直观的看着流程图，创建一个新的流程（客户完全可以自己去做），而不是像开关驱动型的那样，要用源代码来开发（必须要原厂，就算你有源代码，你确定你的IT团队能驾驭数百万行的源代码吗？？？而且，厂家真的会把所有相关的有助于明白系统原设计的开发文档给你？）。

开关驱动型WMS能做到的功能流程一定是有限的，很容易就需要去动源代码；而流程驱动型除了可以修改现有功能流程，它还可以不需要源代码就能创建新的功能流程！

除了那位行业能力强的顾问（设计）外，流程驱动型负责做配置和测试的技术顾问的可代替性比起开关驱动型同样是负责配置和测试的顾问的可代替性要高的多，基本上能驾驭流程图的人熟悉一下Architect的使用就能胜任！在HighJump的客户群中，很多都是客户自己就能控制Architect的使用，真正意义上享受了“高可配置”的好处，真正“拥有”系统！

写到这里，发现自己卖了不少免费广告。现在，我想先跟大家分享老牌的资深WMS分析评论家，ARC Research 的 Steve Banker 先生说过的一句非常击中要害的话：“WMS系统正成为定制化程度最高的企业应用系统之一。”原话是：”WMS software tends to be among the most customized enterprise applications.”

这里我也要说说我个人根据Forrester Wave对各大国际知名WMS厂家在“产品现状 Current Offering”和“策略Strategy”两个纬度的评论报告，与及我个人对相关WMS产品的理解得到的看法：如果比较系统出厂时的功能，我认为，做为比较用的参考值，假如MA WMOS是100分，那么JDA-RP Discrete就该是95分，而HighJump WA就该是90分；但是，按照目前的行业状况，如果拿出任何一家需求比较复杂的客户出来，三家公司的产品都会同样的不能100%满足客户需求，可能都同样的只能满足80%（如果客户来自正在颠覆传统WMS的电商物流业，情况可能更加糟糕！！）。

从上面Steve Banker的话中，结合我前面写的，不难理解：前几十年，物流行业（尤其是欧美）对WMS的需求还是比较规范、可控的，但随着消费者、消费习惯、零售、生产、和服务模式和意识的持续改变，物流行业对WMS的要求也就不能再像以前那样规范了，压力也就自然的转嫁给了WMS。更恐怖的是正在爆发的直接面对消费者的电子商务物流，更加无情的摧毁了传统WMS走了几十年的“开关驱动”模式！！！最大的证明是，各大WMS厂家都分别在过去5年间，开始启动转型平台化上，但这是需要产品发布后最少5年的稳定期的。

前面说过不管是100分、95分、还是90分都只能满足客户80%，所以客户要评估的应该是WMS厂家如何去面对另外的20%需求！这个时候，真正具备柔性的流程驱动型WMS明显是更加突出的选择！因此， WMS产品策略除了需要持续加强功能，追求能满足90% 甚至是100%而不是80%之外，必须要聚焦在如何提供一个流程驱动模式的WMS平台，让客户更快、更方便、更低成本（自己可以去做）的响应市场的要求！因为物流企业、部门自己的需求也不断的为了响应市场要求而的在变！

流程驱动型配置肯定是应用行业软件未来发展的必然趋势，这里面也肯定包含WMS，只是在现阶段，是否有这样NB的软件能够通过这种方式完全满足不同客户的个性化需求（或许95%以上也不错，但关键的个性化需求必须能够配置出来）。不要说界面的可定制化和类似OA的单证流转驱动配置就是所谓的流程驱动型软件，这对WMS远远不够，WMS需要的是对系统&作业流程及在此流程中涉及到的各类元素的协同和流转。比如最复杂的出库流程，库存分配，拣货（订单别，汇总等），复核，发货及这些流程节点中涉及到的多包装，容器，条码，硬件设备（RF，电子标签，自动运输设备等）的协作与集成。这些流程驱动型配置系统是否能搞掂。不然的话，这种软件也只是像国内某著名物流软件公司推出的“上帝”型软件一个路子：忽悠人。

WMS如果连本业，比如文中说的 “最复杂的出库流程，库存分配，拣货（订单别，汇总等），复核，发货及这些流程节点中涉及到的多包装，容器，条码，硬件设备（RF，电子标签，自动运输设备等）的协作与集成。” 都没法做好，而只去追求“流程驱动”和“平台化”，那就失去意义了！

个人觉得，面对3PL和B2C的行业，可能由于其各家（货主）业务需求的差异化，因此需要WMS系统具备很好灵活行的特性，才能满足所有客户的需求。因此选择流程驱动型的产品会更好；而对于企业或者集团公司来说，更多的是关心公司整体的物流供应链的运作和管理。可能基于开关驱动型+少量Customization的产品应该可以满足。

正如，所有的WMS都会有入库订单、出库订单、分配、拣货等这些功能；但是不同行业或者同行业的不同公司，在管理上肯定会有差异的，这也就有了定制的内容了。简单点来说，电商类（当前比较火的B2C）与三方的肯定就会有差异的，电商类的SKU也许不需要货主的管理，三方的肯定要有货主管理。而三方仓储又由于客户行业不一样也会有不一样的需求，比如三方服务的是服装类的客户还是食品类的，都是会有差异的，所以肯定会有部分定制的内容，单纯靠配置，恐怕不那么容易吧。

WMS系统架构设计的演变与选择相关推荐

万亿级调用系统：微信序列号生成器架构设计及演变
"每天万亿级调用的重量级系统,每次申请序列号平时调用耗时1ms,99.9%的调用耗时小于3ms,服务部署于数百台4核CPU服务器上!" 老司机介绍: 曾钦松,微信高级工程师,目前负 ...
微信序列号生成器架构设计及演变
一.摘要微信在立项之初,就已确立了利用数据版本号实现终端与后台的数据增量同步机制,确保发消息时消息可靠送达对方手机,避免了大量潜在的家庭纠纷.时至今日,微信已经走过第五个年头,这套同步机制仍然在消息 ...
vivo全球商城：库存系统架构设计与实践
作者:vivo官网商城开发团队 - Xu Yi.Yan Chao 本文是vivo商城系列文章,主要介绍vivo商城库存系统发展历程.架构设计思路以及应对业务场景的实践. 一.业务背景库存系统是电商商 ...
系统架构设计_系统工程师--系统架构设计
系统架构设计包含硬件架构和软件架构,功能的模块化和描述输入输出是基本思维.并且系统架构设计是做系统级失效模式影响分析(SFMEA)的输入. 硬件架构设计是根据ISO26262-2018第5章中的附录D ...
系统架构设计的工程与艺术（0）
对于系统架构设计,我现在是功力不够,境界还凑合,俗称眼高手低是也.功力不够只能一点一点地练,一点一点的涨了,还不知道什么时候能有所小成.不过有境界也算是一件好事情,所以这个系列会先聊一聊境界方面. 之 ...
专访腾讯徐汉彬：日请求高达3.5亿+平台的架构设计及演变
专访腾讯徐汉彬:日请求高达3.5亿+平台的架构设计及演变发表于11小时前| 2426次阅读| 来源CSDN| 3 条评论| 作者钱曙光 SDCCSDCC讲师专访腾讯徐汉彬架构WebPHP width ...
《程序员》2014年11月刊：电商峰值系统架构设计
双11来临之际,<程序员>以"电商峰值系统架构设计"为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电 ...
腾讯云低延时直播系统架构设计与弱网优化实践
"直播带货"可能是2020年最具代表性的词汇之一,那么传统电商该如何融合直播系统,直播过程如何保障用户的最佳观看体验?本文由腾讯云资深架构师何书照在LiveVideoStack线上 ...
插件式架构设计实践：插件式系统架构设计简介
本系列博文将使用微软RIA技术解决方案Silverlight以及扩展性管理框架Managed Extensibility Framework(MEF),以插件式架构设计为导线,分享本人在从事基于微软S ...

WMS系统架构设计的演变与选择

WMS系统架构设计的演变与选择相关推荐

最新文章

热门文章