ERP解决不了的积木式供应链系统

物流网络重新布局、构建零部件VMI枢纽、需求预测、协同计划、运输整合等等，任何一个重大的供应链项目都必然要求部署相应的信息系统。是在已有的ERP软件框架内考虑实现关键供应链项目所需要的系统功能，还是建立新的供应链系统与ERP集成？

ERP解决不了的积木式供应链系统: “积木式”VS“一个中心”

对于已经实施了ERP，尤其是SAP、Oracle等国际一流ERP软件的企业来说，这是一个非常重要的决策。Yes或No，完全不是一个技术性考虑，而是一个决定企业供应链蓝图的“路线方针”。因为信息系统的结构关系决定了企业对于自身供应链能力的定位及其能力发展途径。

“在已有的ERP软件框架内实现关键供应链项目所需要的系统功能”会得到很多人的支持。ERP软件商可能会说“供应链功能需求我们都可以支持，高级计划、运输管理、仓库管理等等都有相关的模块，世界500强有一半在使用”；财务人员可能会说“ERP投资很大，尽可能深化其应用才能充分回报”；IT人员会说“不用接口，技术风险小”。更重要的是在实施ERP之前，可能正是以“一个ERP软件，一个标准规范，一个统一平台”解决管理问题的诱人图景取得了决策者的高度认同。

但是，这样的图景基于一个关键假定：ERP套件可以容纳企业不断发展的供应链模式，并且内涵了实现这些供应链模式的“最佳实践”。所以，当供应链项目不断拓展的时候，不需要“重新发明轮子”，只需要把国外大企业早就验证过的“最佳实践”从软件里发掘出来就可以了。不信你看，这里有49种订单类型，360个流程，你见过的，没见过的，今天在用的，明天可能用的，都有……

大一统的图景总是很迷人的，但是并非都有好的结果，而且失败的时候往往不仅仅是悲剧，更是巨大的灾难。譬如希特勒的“一个主义，一个政党，一个领袖”。

直觉上我从来不愿意相信这样的图景。我总是认为应该在ERP的框架之外去建立供应链系统，无论是分销管理、需求预测，还是仓储管理、运输管理，越是关键越应该独立于ERP系统之外建立。这样的话，供应链的能力可以生长在一个简洁、可把握的信息系统环境中，供应链管理每一天的新进展、新智慧立刻可以自如地更新到系统中，不需要等待总部IT部门的批准，不需要与ERP实施顾问的谈判，不需要严肃的需求分析会议，不需要担心对ERP系统的改变会影响整个公司的正常运行。

当然，供应链的关键价值点可能不是一个，而是三个，例如终端需求管理、物流网络管理以及零部件供应商管理，那么供应链的系统也不一定是一个，而是三个。这自然需要一个总体的架构规划，回答到底有几个系统、每个系统的业务定位、系统间的接口方式、哪个在先哪个在后等等关键问题。

这种“积木式”的信息系统框架中，每一块“积木”都有其独特的业务定位，ERP只是其中的一块，不是全部，不是唯一的核心，其他系统也不是ERP的补丁。ERP在整体信息框架的作用就像财务部门在企业整体组织中的作用一样，是个不可缺少的基础管理部门，但并不是其他部门的中心。

“积木式”结构中，供应链系统是掌握在相关的供应链组织手中，而不是掌握在IT部门手中，不同的“积木”体现不同拥有者的经营智慧，系统伴随着供应链组织的成长而成长。这种结构容许多个创新中心的存在，支持供应链部门通过内部竞争取得更大的服务范围，例如从一个事业部的物流部门成为全集团的物流服务平台。

当我们期待组织内的供应链创新以最快的速度进入系统，当我们期待供应链模式的变革不受既定框架的束缚以最快的速度获得信息系统的支持时，我们应该选择“积木式”。

ERP解决不了的积木式供应链系统: 但这种坚持是否太武断呢？

ERP解决不了的积木式供应链系统: 信息来源：IT经理世界