供应链这个领域有个挺有意思的现象几乎每个刚入行的人第一次看到系统清单时都会懵——SCM、SRM、WMS、TMS、ERP、PLM、MES、PMS再加上OMS、CRM十个缩写排在一起像一串密码。更麻烦的是很多资料要么只讲单个系统的功能清单要么一上来就画一张密不透风的架构图看完还是不知道这些系统之间到底谁管谁、数据从哪流到哪、边界在什么地方。我在实际项目里踩过不少这方面的坑。早些年做系统集成时曾经把WMS的库存逻辑和ERP的库存逻辑当成一回事结果对账对到怀疑人生也见过团队在SRM和采购模块之间反复扯皮最后发现是职责划分没理清。所以这篇不打算写成产品手册而是按一个从业者的视角把这十个系统逐个拆开讲清楚每个系统解决什么问题、核心数据是什么、和上下游怎么衔接最后再拼成一张完整的架构图。不管你是刚接触供应链系统的新人还是需要做系统规划、集成对接的老手看完应该都能对这套体系建立一个清晰的心智模型。1. 先搞清楚这十个系统各自站在供应链的哪个位置在逐个拆系统之前得先建立一个整体视角。供应链的本质是一条从需求到交付的价值链中间涉及计划、采购、生产、仓储、运输、财务结算等多个环节。这十个系统不是并列关系而是分布在这条链的不同环节上有的管计划有的管执行有的管记录有的管协同。1.1 用计划层—执行层—支撑层三层来归类我习惯把供应链系统分成三层来看这个分法比按字母顺序背缩写有用得多。计划层负责回答要做什么、做多少、什么时候做。典型代表是SCM供应链管理偏计划协同和PMS生产计划/项目管理视具体定义而定。这一层的特点是数据颗粒度相对粗但时间跨度长输出的是指导性计划。执行层负责回答具体怎么干、干到哪一步了。WMS管仓库内的作业TMS管运输执行MES管车间生产执行SRM管供应商协同执行。这一层数据颗粒度细实时性要求高直接对应物理世界的动作。支撑层负责回答账怎么记、数据怎么统一、产品怎么定义。ERP是财务和业务的主数据底座PLM管产品全生命周期数据CRM管客户与需求侧信息。这一层不直接指挥作业但为上下两层提供数据基础和结算依据。这么一分你会发现很多困惑自然消解了为什么WMS和ERP都有库存因为一个是执行层的实时库存一个是支撑层的账面库存两者口径不同、更新频率不同本来就不该混为一谈。1.2 一张表看清十个系统的核心职责与主数据下面这张表是我在多个项目里反复修正后总结的重点看核心主数据和主要服务对象两列这两列决定了系统之间的集成关系。系统全称核心职责核心主数据主要服务对象SCM供应链管理需求计划、供应计划、产销协同计划版本、需求预测计划部门SRM供应商关系管理供应商准入、寻源、采购协同供应商档案、采购订单采购部门WMS仓储管理系统收货、上架、拣货、盘点、发货库位、库存事务、批次仓储部门TMS运输管理系统运输计划、调度、跟踪、运费结算运单、车辆、路线物流部门ERP企业资源计划财务核算、订单管理、主数据统一物料主数据、会计科目全公司PLM产品生命周期管理产品定义、BOM、变更管理物料清单、图纸、版本研发与工艺MES制造执行系统工单执行、工序报工、质量追溯工单、工序、设备状态生产车间PMS生产/项目管理计划排程、项目进度、资源分配排程计划、项目节点计划与项目组OMS订单管理系统订单接收、拆分、履约跟踪销售订单、履约状态销售与客服CRM客户关系管理客户档案、商机、售后服务客户主数据、商机销售与市场这张表里有个细节值得注意ERP和PLM都涉及物料但ERP的物料主数据偏商务属性价格、税率、库存单位PLM的物料偏工程属性材质、图纸、BOM结构。实际项目里最常见的集成难点之一就是这两套物料编码怎么对齐——这个后面会专门讲。1.3 为什么不能按大而全的思路理解这套体系很多刚接触的人会问既然ERP什么都能管为什么还要这么多系统直接一个ERP全包不行吗这个问题背后其实是个架构哲学问题。ERP的强项是记录和核算它擅长把已经发生的业务记成账。但仓库里的拣货路径优化、运输中的实时调度、车间里的工序级报工这些高频、实时、强物理属性的作业ERP做起来又重又慢。所以行业里逐渐演化出专业系统做执行、ERP做核算的分工。这不是厂商为了多卖产品硬拆出来的而是业务复杂度逼出来的必然结果。理解这一点很关键系统之间的边界本质上是业务职责的边界不是技术能力的边界。你在做系统规划时先想清楚某项业务该由哪个部门负责、按什么频率决策系统归属自然就清楚了。2. 计划与协同侧SCM和PMS到底在算什么计划层是最容易被低估的一层。执行层出问题往往是看得见的货发错了、工单延误了但计划层出问题影响是隐性的、滞后的等发现时往往已经积压了一堆库存或者断了一堆货。SCM和PMS这两个系统就是用来把这种隐性风险显性化的。2.1 SCM的核心不是管而是算和协同很多人把SCM理解成一个供应链管理平台这个理解太宽泛了。实际落地中SCM最核心的价值在两头一头是需求预测一头是供应计划平衡。需求预测这块SCM要做的是把销售侧的历史数据、市场活动、季节因素揉在一起跑出分品类、分区域、分时间段的预测值。这里有个实操经验预测的颗粒度不是越细越好。我见过有团队把预测做到单SKU单天结果预测准确率惨不忍睹因为颗粒度太细噪声淹没了信号。比较稳妥的做法是按品类×周或重点SKU×周来做再往下拆的时候用规则分配而不是硬预测。供应计划平衡是SCM的另一半。它要回答的是给定需求预测和现有产能、库存、在途哪些地方会缺、哪些地方会剩需要提前做什么动作补货、调拨、催产能。这一步的输出通常是供需平衡表格式大致如下品类周次需求预测期初库存在途可用产能缺口建议动作A类W112008003001000-100紧急补货B类W16009000700200可调拨这张表看着简单但真正跑起来难点在于数据口径统一。需求预测来自销售、库存来自WMS、在途来自TMS、产能来自MES或PMS四个来源四个口径不统一就没法算。所以SCM项目里数据治理的工作量往往比算法本身还大。2.2 PMS的定位取决于企业类型别照搬别人的定义PMS这个缩写在不同企业里含义差别很大。在项目型制造企业里它通常指项目管理系统管的是项目节点、资源投入、进度里程碑在流程型或离散型制造企业里它更多指生产计划管理系统管的是排程、产能负荷、工单下达。这个差异不是文字游戏直接影响系统选型和集成方案。项目型企业的PMS核心数据是项目WBS节点资源和ERP的项目核算模块强关联生产型企业的PMS核心数据是排程计划产能日历和MES的工单执行强关联。我的建议是先明确你所在企业的生产组织方式再决定PMS的定位。如果是按订单设计、单件小批量PMS偏项目管理如果是按库存生产、大批量PMS偏排程管理。搞错了这个前提后面所有的集成设计都会跑偏。2.3 计划层与执行层的数据握手点计划层算出来的东西怎么传到执行层这里有三个关键的握手点每个握手点都是一次集成设计的机会也是一次踩坑的机会。第一个握手点是计划到采购SCM算出的补货建议要转成SRM里的采购申请或采购订单。这里的坑在于时间颗粒度——计划是按周算的采购是按天执行的转换时要做时间展开还要考虑供应商的交货提前期。第二个握手点是计划到生产PMS的排程结果要下达到MES变成工单。这里的坑在于排程假设和实际产能的偏差排程时假设设备可用率95%实际可能只有80%所以下达工单时要留缓冲不能把排程结果当成铁律。第三个握手点是计划到仓储补货计划要提前通知WMS做收货准备。这个握手点最容易被忽略结果货到了仓库才发现没地方放、没人收计划做得再准也白搭。3. 采购与供应商侧SRM不只是个供应商档案库SRM是这十个系统里被误解最深的一个。很多企业上SRM最后只上成了一个供应商信息登记系统供应商名录、资质证书、联系人仅此而已。这等于花了大价钱买了个通讯录。SRM真正的价值在采购流程的协同和寻源的规范化。3.1 从寻源到合同SRM管的是采购的前半程采购流程可以粗略切成两段前半程是找谁买、按什么条件买后半程是下单、收货、对账。SRM主要管前半程ERP的采购模块管后半程。前半程里SRM要做的事包括供应商准入资质审核、现场评审记录、寻源询比价、招标、竞价、合同管理框架协议、价格条款、供应商绩效交付准时率、质量合格率。这些动作的共同特点是低频但重决策一旦定下来后面很长一段时间的采购都按这个框架走。这里有个实操心得供应商绩效评估的指标不要贪多。我见过有企业设了二十几个考核指标结果每个季度打分时采购员凭印象填数据全是拍脑袋的。比较务实的做法是抓三到五个硬指标——交付准时率、来料合格率、价格竞争力、响应速度每个指标都要有系统自动取数取不到数的指标宁可不设。3.2 SRM与ERP采购模块的边界怎么划这是集成设计里绕不开的问题。我的划分原则是决策类动作放SRM交易类动作放ERP。具体来说供应商准入、寻源定价、合同签订这些定规则的动作在SRM里完成结果合格供应商清单、协议价格同步到ERP。而具体的采购订单下达、收货、发票校验、付款这些走流程的动作在ERP里完成。这样划分的好处是ERP的账务链条保持完整SRM的协同能力又能充分发挥。反过来的做法——把采购订单也放在SRM里管——我也见过问题在于SRM和ERP的库存、财务数据对不上每个月对账都要人工拉平。除非企业规模大到需要独立的采购执行平台否则不建议这么干。3.3 供应商协同的实时性要求与常见断点SRM里有一块功能叫供应商协同就是让供应商登录系统看采购订单、确认交期、提交发货通知。这块功能听起来简单实际落地时断点特别多。最常见的断点是供应商不用。系统上线了供应商还是习惯打电话、发消息确认订单。原因往往不是供应商抵触而是系统用起来太麻烦——登录要审批、界面不友好、看不到自己想要的信息。解决办法不是强推而是先把供应商最关心的三件事做顺我的订单在哪、什么时候要交、上次的货款结了没有。这三件事做顺了供应商自然愿意用。第二个断点是交期确认的闭环。供应商在SRM里确认了交期这个确认结果要能回传到ERP的采购订单上否则采购员还是看不到最新交期。这个回传链路如果断了协同就变成了单向通知失去了意义。4. 仓储与运输侧WMS和TMS是物理世界的数字化WMS和TMS是执行层里最接地气的两个系统它们直接对应仓库里的每一次搬货和路上的每一趟运输。这两个系统的共同特点是数据实时性要求高、和硬件设备扫码枪、打印机、GPS耦合紧、上线难度大。4.1 WMS的核心是库存事务的精确记录WMS的本质是把仓库里每一次物料的移动都记成一笔事务。收货是一笔事务上架是一笔事务拣货是一笔事务盘点调整也是一笔事务。这些事务累加起来就构成了WMS的实时库存。这里的关键词是实时。ERP里的库存是账面库存可能一天更新一次WMS里的库存是物理库存扫码那一刻就变了。两者之间的差异就是所谓的库存口径差。这个差异不是bug是设计使然但必须有人定期对账否则差异会越滚越大。WMS的核心数据模型大致是库位×物料×批次×数量。这四个维度缺一不可。少了库位拣货时找不到货少了批次追溯时查不到来源少了数量盘点时对不上账。我见过有WMS为了简化把批次维度省了结果做质量追溯时抓瞎最后不得不返工加回来。4.2 拣货策略的选择直接决定WMS的上线成败WMS上线时拣货策略是最容易出问题的地方。常见的策略有四种按单拣货、批量拣货、分区拣货、波次拣货。选哪种取决于订单结构。策略适用场景优点缺点按单拣货订单少、单量大简单、不易错行走路径长批量拣货订单多、品项重合度高路径短、效率高需要二次分拣分区拣货仓库大、品类分区明显并行作业跨区订单要合并波次拣货订单量大、有截单时间平衡负载系统配置复杂实操经验是不要一上线就上最复杂的策略。先按单拣货跑通流程等作业稳定了再根据实际订单结构逐步切换到批量或波次。我见过有项目一上线就配波次拣货结果波次规则没调好拣货员在仓库里来回跑效率反而比手工还低。4.3 TMS的难点不在运输执行在运费和异常TMS管运输表面看是管货从A到B实际难点在两块运费计算和异常处理。运费计算这块规则复杂度远超想象。同一个承运商可能按重量计费、按体积计费、按趟次计费还有燃油附加费、等待费、卸货费。这些规则如果不在TMS里配置清楚月底对账就是一场灾难。我的建议是运费规则要在合同签订时就结构化把计费方式、费率、附加费条件都定义成TMS能识别的格式而不是等到对账时再人工算。异常处理这块TMS要能记录运输过程中的各种意外延误、货损、改道、拒收。这些异常不只是记录还要能触发后续动作——延误要通知客户、货损要发起理赔、拒收要安排退回。TMS如果只做运输跟踪不做异常闭环价值就少了一半。4.4 WMS与TMS的交接点月台管理WMS和TMS的交接点在月台装卸货口。货车到了TMS知道车到了WMS知道该卸到哪个库位但两边如果没打通就会出现车等位或位等车的尴尬。这个交接点的集成设计核心是预约机制。TMS把运输计划里的到货时间推给WMSWMS根据月台占用情况分配卸货时段再把确认结果回传TMS。这样司机出发前就知道几点到、去哪个门仓库也知道几点有车来、安排多少人卸货。这个机制看着简单但能显著降低月台拥堵是投入产出比很高的一项集成。5. 生产侧MES和PLM撑起制造的数据底座制造环节是供应链里数据最密集的一段。一个工单从下达到完工中间要经过几十道工序、上百次报工、无数次质量检验。MES和PLM就是用来接住这些数据的两个系统一个管怎么做出来一个管按什么标准做。5.1 MES的价值在工序级追溯不在大屏很多企业上MES最初的动机是想搞个车间大屏实时看产量。这个动机没错但如果MES只做到大屏展示那就浪费了。MES真正的价值在工序级的追溯能力。什么叫工序级追溯就是任何一个成品都能查到它经过了哪些工序、每道工序是谁做的、用的什么设备、什么参数、检验结果如何。这个能力在出现质量问题时价值巨大——不用整批召回可以精准定位到问题工序和问题批次。实现工序级追溯的前提是报工颗粒度要够细。如果报工只报到工单完工追溯就断了必须报到工序完工甚至工序内每个关键参数。当然颗粒度越细录入工作量越大所以要在追溯需求和录入成本之间找平衡。我的经验是关键工序影响产品性能的细报辅助工序如包装、贴标粗报。5.2 PLM管的是产品的基因BOM是核心中的核心PLM的核心是产品数据而产品数据的核心是BOM物料清单。BOM不只是一张物料列表它至少有三个层次设计BOMEBOM研发视角按产品功能结构组织反映产品由哪些零件组成。制造BOMMBOM工艺视角按装配顺序组织反映产品怎么装起来。服务BOMSBOM售后视角按维修单元组织反映坏了换哪个件。这三个BOM在PLM里定义在ERP和MES里使用。实际项目里最常见的坑就是EBOM到MBOM的转换没做好——研发改了设计MBOM没同步车间按旧BOM领料装出来才发现少了个件。所以PLM的变更管理流程必须和ERP、MES打通变更一旦生效下游要能收到通知并执行切换。5.3 PLM与ERP的物料编码对齐一个绕不过去的硬骨头前面提过PLM的物料偏工程属性ERP的物料偏商务属性两套编码怎么对齐是集成里的硬骨头。常见的做法有三种一是以PLM编码为主ERP沿用二是以ERP编码为主PLM做映射三是建独立的物料主数据平台两边都从平台取。三种做法各有适用场景我整理成表做法适用场景优点风险PLM主导研发驱动型企业工程数据一致性好ERP历史数据要迁移ERP主导商务驱动型企业财务口径稳定研发新物料要等编码主数据平台多系统、多工厂全局唯一建设成本高不管选哪种有一条铁律物料编码只能有一个权威源。两边都能新建物料必然出现一物多码后面所有的库存、成本、追溯都会乱。这个坑我见过太多次每次收拾起来都要花几个月。5.4 MES与WMS的物料流转衔接MES和WMS的衔接点在物料配送。车间要生产得先从仓库领料领料这个动作在WMS里是出库在MES里是投料两边必须对上。衔接方式有两种推式和拉式。推式是WMS按领料单主动配送拉式是MES按工单进度触发要料。大批量生产适合推式多品种小批量适合拉式。实际项目里往往是混合模式——常规物料推式配送紧急物料拉式要料。这里有个细节容易被忽略线边库存的管理。物料从仓库领出来到真正投料之间有一段线边库存。这段库存在WMS里已经出库了在MES里还没投料处于账外状态。如果不专门管理线边库存会变成黑洞月底盘点时对不上。解决办法是在WMS里设线边库位物料移到线边库位算移库不算出库投料时才真正出库。6. 支撑与交易侧ERP、OMS、CRM的分工与咬合支撑层的三个系统——ERP、OMS、CRM——是供应链的账房和前台。它们不直接指挥物理作业但决定了整个链条的结算口径和需求来源。6.1 ERP是主数据底座不是万能系统ERP的定位要摆正它是企业的主数据底座和财务核算中心。物料主数据、供应商主数据、客户主数据、会计科目这些全局性的数据应该在ERP里统一管理。但ERP不是万能的前面说的执行层作业ERP做不了也不该做。ERP在供应链里的核心作用有三个一是订单管理销售订单、采购订单的台账二是库存核算账面库存、成本核算三是财务结算应收应付、总账。这三个作用决定了ERP必须和其他系统保持数据同步但同步的方向和频率要设计好。同步设计的原则是主数据从ERP往下游推业务数据从下游往ERP汇总。物料主数据从ERP推到WMS、MES库存事务从WMS汇总到ERP。方向搞反了就会出现下游改了主数据、上游不知道的混乱。6.2 OMS解决的是订单履约的最后一公里协调OMS这个系统在有些企业里被合并进ERP在有些企业里独立存在。它解决的核心问题是一个订单进来怎么拆、怎么分配、怎么跟踪到履约完成。订单拆分是OMS的典型场景。一个订单可能因为库存分布在不同仓库、部分商品缺货、客户要求分批配送被拆成多个履约单。这些履约单分别流向不同的WMS和TMSOMS要负责跟踪每一单的状态最后汇总成对客户的统一反馈。OMS和ERP的边界在于ERP管订单的财务属性金额、信用、开票OMS管订单的履约属性拆分、分配、跟踪。两者通过订单号关联各管一段。6.3 CRM与供应链的接口需求信号的源头CRM通常被归到销售侧但它和供应链的连接点很关键——需求信号。CRM里的商机、订单预测、客户订单是SCM做需求预测的重要输入。这个接口如果没打通就会出现销售在CRM里报的预测和SCM算出来的预测对不上的情况。解决办法不是让两边算得一样而是建立预测共识机制——CRM提供销售侧的判断SCM提供历史数据的统计两者在产销协同会上对齐形成最终的计划版本。7. 十个系统拼成一张架构图集成关系与数据流向前面六个章节把十个系统逐个拆开了这一章把它们拼回去。拼的时候不是简单堆叠而是按数据流向和集成关系来组织。7.1 分层架构图与集成总线从架构上看这十个系统可以画成三层加一条总线顶层是计划与协同层SCM、PMS、CRM。这一层输出计划、预测、需求信号。中间是执行层SRM、WMS、TMS、MES、OMS。这一层承接计划执行物理作业产生实时数据。底层是支撑层ERP、PLM。这一层提供主数据和核算能力。贯穿三层的是集成总线所有系统之间的数据交换都通过总线或API网关走而不是系统之间点对点直连。点对点直连的问题是系统一多连接数呈平方级增长维护成本爆炸。走总线的话每个系统只对接总线新增系统只需接一次。用文字描述数据流向大致是CRM的需求信号→SCM做预测→PMS做排程→MES执行生产、SRM执行采购→WMS/TMS执行仓储运输→所有执行数据汇总到ERP核算。PLM的BOM数据同时供给MES指导生产和ERP指导成本核算。7.2 关键集成链路清单实际做集成时不可能一次把所有链路都做完要排优先级。下面这几条是我认为优先级最高的PLM→ERP的物料与BOM同步这是所有数据的基础不同步后面全乱。ERP→WMS的物料主数据与采购订单同步仓库收货要用。WMS→ERP的库存事务回传账实一致的前提。SRM→ERP的供应商与协议价格同步采购下单要用。MES→ERP的工单完工与领料回传成本核算要用。TMS→ERP的运费结算数据回传应付账款要用。这六条链路覆盖了主数据、库存、采购、生产、物流、财务六个维度做完这六条基本盘就稳了。剩下的链路如SCM与PMS的计划协同、OMS与WMS的履约跟踪可以按业务优先级逐步补。7.3 集成方式的选择接口、中间表还是消息队列集成方式的选择取决于实时性要求和数据量。我整理了一个对照表方式适用场景实时性复杂度API接口主数据同步、单据传递准实时中中间表批量数据汇总、报表取数定时如每小时低消息队列高频事务、事件通知实时高实操建议主数据和单据用API批量汇总用中间表高频事务如WMS的库存事务用消息队列。不要所有链路都用一种方式也不要用消息队列去传大批量历史数据——那是杀鸡用牛刀还容易把队列堵死。8. 落地时最容易翻车的几个地方系统清单讲完了架构也拼完了最后说说落地。这一章不讲理论讲我实际项目里见过、踩过的坑。8.1 主数据不统一集成做再多也白搭这是最老生常谈但又最常翻车的一条。物料编码一物多码、供应商一处多名、客户档案重复这些问题不解决集成链路建得再漂亮传过去的数据也是脏的。我的经验是上集成之前先做一轮主数据清洗。清洗的重点是物料和供应商方法是定编码规则、定唯一性校验、定变更流程。清洗的工作量可能占整个项目的一半但省不得。见过有项目为了赶进度跳过清洗结果上线后天天对账返工成本远超清洗成本。8.2 边界不清导致的系统打架系统打架的典型表现是同一个数据两个系统都能改改完还不一致。比如库存WMS能改、ERP也能改最后谁说了算解决办法是明确每个数据的权威源。库存的权威源是WMSERP只读不写物料主数据的权威源是ERP或PLM看企业选择其他系统只读。权威源一旦定下来就要在权限和接口上落实——非权威源系统的写权限要关掉接口只做单向同步。8.3 上线顺序的取舍先上哪个后上哪个十个系统不可能一起上顺序怎么排我的建议是按数据依赖排而不是按业务重要性排。先上PLM或ERP主数据底座再上WMS和SRM执行层依赖主数据然后上MES和TMS更复杂的执行层最后上SCM和PMS计划层依赖执行层的数据。OMS和CRM可以穿插在中间看业务紧迫性。这个顺序的逻辑是下游系统依赖上游系统的数据上游没上稳下游上了也是空转。见过有企业先上WMS结果物料主数据还没统一WMS里一堆临时编码后面ERP上线时全部要返工。8.4 用户不用系统再好的架构也是摆设最后一条也是最容易被技术团队忽略的一条系统是给人用的。仓库的拣货员、车间的班组长、采购的跟单员他们用不用系统决定了系统有没有价值。让用户愿意用关键在三点一是操作要快扫码比打字快能扫就别让填二是信息要准用户看到的数据要实时、要正确三是反馈要闭环用户提的问题要有人管、有回应。这三点做到了推广就顺做不到再好的架构也只是PPT上的图。我在实际项目里的体会是供应链系统的成败技术只占三成剩下七成是业务梳理和组织协同。系统架构图画得再漂亮如果业务职责没理清、部门之间没对齐落地时照样一地鸡毛。所以每次做系统规划我都会先花时间把业务流程和职责边界捋一遍再谈系统怎么建——这个顺序反不得。
供应链这个领域有个挺有意思的现象几乎每个刚入行的人第一次看到系统清单时都会懵——SCM、SRM、WMS、TMS、ERP、PLM、MES、PMS再加上OMS、CRM十个缩写排在一起像一串密码。更麻烦的是很多资料要么只讲单个系统的功能清单要么一上来就画一张密不透风的架构图看完还是不知道这些系统之间到底谁管谁、数据从哪流到哪、边界在什么地方。我在实际项目里踩过不少这方面的坑。早些年做系统集成时曾经把WMS的库存逻辑和ERP的库存逻辑当成一回事结果对账对到怀疑人生也见过团队在SRM和采购模块之间反复扯皮最后发现是职责划分没理清。所以这篇不打算写成产品手册而是按一个从业者的视角把这十个系统逐个拆开讲清楚每个系统解决什么问题、核心数据是什么、和上下游怎么衔接最后再拼成一张完整的架构图。不管你是刚接触供应链系统的新人还是需要做系统规划、集成对接的老手看完应该都能对这套体系建立一个清晰的心智模型。1. 先搞清楚这十个系统各自站在供应链的哪个位置在逐个拆系统之前得先建立一个整体视角。供应链的本质是一条从需求到交付的价值链中间涉及计划、采购、生产、仓储、运输、财务结算等多个环节。这十个系统不是并列关系而是分布在这条链的不同环节上有的管计划有的管执行有的管记录有的管协同。1.1 用计划层—执行层—支撑层三层来归类我习惯把供应链系统分成三层来看这个分法比按字母顺序背缩写有用得多。计划层负责回答要做什么、做多少、什么时候做。典型代表是SCM供应链管理偏计划协同和PMS生产计划/项目管理视具体定义而定。这一层的特点是数据颗粒度相对粗但时间跨度长输出的是指导性计划。执行层负责回答具体怎么干、干到哪一步了。WMS管仓库内的作业TMS管运输执行MES管车间生产执行SRM管供应商协同执行。这一层数据颗粒度细实时性要求高直接对应物理世界的动作。支撑层负责回答账怎么记、数据怎么统一、产品怎么定义。ERP是财务和业务的主数据底座PLM管产品全生命周期数据CRM管客户与需求侧信息。这一层不直接指挥作业但为上下两层提供数据基础和结算依据。这么一分你会发现很多困惑自然消解了为什么WMS和ERP都有库存因为一个是执行层的实时库存一个是支撑层的账面库存两者口径不同、更新频率不同本来就不该混为一谈。1.2 一张表看清十个系统的核心职责与主数据下面这张表是我在多个项目里反复修正后总结的重点看核心主数据和主要服务对象两列这两列决定了系统之间的集成关系。系统全称核心职责核心主数据主要服务对象SCM供应链管理需求计划、供应计划、产销协同计划版本、需求预测计划部门SRM供应商关系管理供应商准入、寻源、采购协同供应商档案、采购订单采购部门WMS仓储管理系统收货、上架、拣货、盘点、发货库位、库存事务、批次仓储部门TMS运输管理系统运输计划、调度、跟踪、运费结算运单、车辆、路线物流部门ERP企业资源计划财务核算、订单管理、主数据统一物料主数据、会计科目全公司PLM产品生命周期管理产品定义、BOM、变更管理物料清单、图纸、版本研发与工艺MES制造执行系统工单执行、工序报工、质量追溯工单、工序、设备状态生产车间PMS生产/项目管理计划排程、项目进度、资源分配排程计划、项目节点计划与项目组OMS订单管理系统订单接收、拆分、履约跟踪销售订单、履约状态销售与客服CRM客户关系管理客户档案、商机、售后服务客户主数据、商机销售与市场这张表里有个细节值得注意ERP和PLM都涉及物料但ERP的物料主数据偏商务属性价格、税率、库存单位PLM的物料偏工程属性材质、图纸、BOM结构。实际项目里最常见的集成难点之一就是这两套物料编码怎么对齐——这个后面会专门讲。1.3 为什么不能按大而全的思路理解这套体系很多刚接触的人会问既然ERP什么都能管为什么还要这么多系统直接一个ERP全包不行吗这个问题背后其实是个架构哲学问题。ERP的强项是记录和核算它擅长把已经发生的业务记成账。但仓库里的拣货路径优化、运输中的实时调度、车间里的工序级报工这些高频、实时、强物理属性的作业ERP做起来又重又慢。所以行业里逐渐演化出专业系统做执行、ERP做核算的分工。这不是厂商为了多卖产品硬拆出来的而是业务复杂度逼出来的必然结果。理解这一点很关键系统之间的边界本质上是业务职责的边界不是技术能力的边界。你在做系统规划时先想清楚某项业务该由哪个部门负责、按什么频率决策系统归属自然就清楚了。2. 计划与协同侧SCM和PMS到底在算什么计划层是最容易被低估的一层。执行层出问题往往是看得见的货发错了、工单延误了但计划层出问题影响是隐性的、滞后的等发现时往往已经积压了一堆库存或者断了一堆货。SCM和PMS这两个系统就是用来把这种隐性风险显性化的。2.1 SCM的核心不是管而是算和协同很多人把SCM理解成一个供应链管理平台这个理解太宽泛了。实际落地中SCM最核心的价值在两头一头是需求预测一头是供应计划平衡。需求预测这块SCM要做的是把销售侧的历史数据、市场活动、季节因素揉在一起跑出分品类、分区域、分时间段的预测值。这里有个实操经验预测的颗粒度不是越细越好。我见过有团队把预测做到单SKU单天结果预测准确率惨不忍睹因为颗粒度太细噪声淹没了信号。比较稳妥的做法是按品类×周或重点SKU×周来做再往下拆的时候用规则分配而不是硬预测。供应计划平衡是SCM的另一半。它要回答的是给定需求预测和现有产能、库存、在途哪些地方会缺、哪些地方会剩需要提前做什么动作补货、调拨、催产能。这一步的输出通常是供需平衡表格式大致如下品类周次需求预测期初库存在途可用产能缺口建议动作A类W112008003001000-100紧急补货B类W16009000700200可调拨这张表看着简单但真正跑起来难点在于数据口径统一。需求预测来自销售、库存来自WMS、在途来自TMS、产能来自MES或PMS四个来源四个口径不统一就没法算。所以SCM项目里数据治理的工作量往往比算法本身还大。2.2 PMS的定位取决于企业类型别照搬别人的定义PMS这个缩写在不同企业里含义差别很大。在项目型制造企业里它通常指项目管理系统管的是项目节点、资源投入、进度里程碑在流程型或离散型制造企业里它更多指生产计划管理系统管的是排程、产能负荷、工单下达。这个差异不是文字游戏直接影响系统选型和集成方案。项目型企业的PMS核心数据是项目WBS节点资源和ERP的项目核算模块强关联生产型企业的PMS核心数据是排程计划产能日历和MES的工单执行强关联。我的建议是先明确你所在企业的生产组织方式再决定PMS的定位。如果是按订单设计、单件小批量PMS偏项目管理如果是按库存生产、大批量PMS偏排程管理。搞错了这个前提后面所有的集成设计都会跑偏。2.3 计划层与执行层的数据握手点计划层算出来的东西怎么传到执行层这里有三个关键的握手点每个握手点都是一次集成设计的机会也是一次踩坑的机会。第一个握手点是计划到采购SCM算出的补货建议要转成SRM里的采购申请或采购订单。这里的坑在于时间颗粒度——计划是按周算的采购是按天执行的转换时要做时间展开还要考虑供应商的交货提前期。第二个握手点是计划到生产PMS的排程结果要下达到MES变成工单。这里的坑在于排程假设和实际产能的偏差排程时假设设备可用率95%实际可能只有80%所以下达工单时要留缓冲不能把排程结果当成铁律。第三个握手点是计划到仓储补货计划要提前通知WMS做收货准备。这个握手点最容易被忽略结果货到了仓库才发现没地方放、没人收计划做得再准也白搭。3. 采购与供应商侧SRM不只是个供应商档案库SRM是这十个系统里被误解最深的一个。很多企业上SRM最后只上成了一个供应商信息登记系统供应商名录、资质证书、联系人仅此而已。这等于花了大价钱买了个通讯录。SRM真正的价值在采购流程的协同和寻源的规范化。3.1 从寻源到合同SRM管的是采购的前半程采购流程可以粗略切成两段前半程是找谁买、按什么条件买后半程是下单、收货、对账。SRM主要管前半程ERP的采购模块管后半程。前半程里SRM要做的事包括供应商准入资质审核、现场评审记录、寻源询比价、招标、竞价、合同管理框架协议、价格条款、供应商绩效交付准时率、质量合格率。这些动作的共同特点是低频但重决策一旦定下来后面很长一段时间的采购都按这个框架走。这里有个实操心得供应商绩效评估的指标不要贪多。我见过有企业设了二十几个考核指标结果每个季度打分时采购员凭印象填数据全是拍脑袋的。比较务实的做法是抓三到五个硬指标——交付准时率、来料合格率、价格竞争力、响应速度每个指标都要有系统自动取数取不到数的指标宁可不设。3.2 SRM与ERP采购模块的边界怎么划这是集成设计里绕不开的问题。我的划分原则是决策类动作放SRM交易类动作放ERP。具体来说供应商准入、寻源定价、合同签订这些定规则的动作在SRM里完成结果合格供应商清单、协议价格同步到ERP。而具体的采购订单下达、收货、发票校验、付款这些走流程的动作在ERP里完成。这样划分的好处是ERP的账务链条保持完整SRM的协同能力又能充分发挥。反过来的做法——把采购订单也放在SRM里管——我也见过问题在于SRM和ERP的库存、财务数据对不上每个月对账都要人工拉平。除非企业规模大到需要独立的采购执行平台否则不建议这么干。3.3 供应商协同的实时性要求与常见断点SRM里有一块功能叫供应商协同就是让供应商登录系统看采购订单、确认交期、提交发货通知。这块功能听起来简单实际落地时断点特别多。最常见的断点是供应商不用。系统上线了供应商还是习惯打电话、发消息确认订单。原因往往不是供应商抵触而是系统用起来太麻烦——登录要审批、界面不友好、看不到自己想要的信息。解决办法不是强推而是先把供应商最关心的三件事做顺我的订单在哪、什么时候要交、上次的货款结了没有。这三件事做顺了供应商自然愿意用。第二个断点是交期确认的闭环。供应商在SRM里确认了交期这个确认结果要能回传到ERP的采购订单上否则采购员还是看不到最新交期。这个回传链路如果断了协同就变成了单向通知失去了意义。4. 仓储与运输侧WMS和TMS是物理世界的数字化WMS和TMS是执行层里最接地气的两个系统它们直接对应仓库里的每一次搬货和路上的每一趟运输。这两个系统的共同特点是数据实时性要求高、和硬件设备扫码枪、打印机、GPS耦合紧、上线难度大。4.1 WMS的核心是库存事务的精确记录WMS的本质是把仓库里每一次物料的移动都记成一笔事务。收货是一笔事务上架是一笔事务拣货是一笔事务盘点调整也是一笔事务。这些事务累加起来就构成了WMS的实时库存。这里的关键词是实时。ERP里的库存是账面库存可能一天更新一次WMS里的库存是物理库存扫码那一刻就变了。两者之间的差异就是所谓的库存口径差。这个差异不是bug是设计使然但必须有人定期对账否则差异会越滚越大。WMS的核心数据模型大致是库位×物料×批次×数量。这四个维度缺一不可。少了库位拣货时找不到货少了批次追溯时查不到来源少了数量盘点时对不上账。我见过有WMS为了简化把批次维度省了结果做质量追溯时抓瞎最后不得不返工加回来。4.2 拣货策略的选择直接决定WMS的上线成败WMS上线时拣货策略是最容易出问题的地方。常见的策略有四种按单拣货、批量拣货、分区拣货、波次拣货。选哪种取决于订单结构。策略适用场景优点缺点按单拣货订单少、单量大简单、不易错行走路径长批量拣货订单多、品项重合度高路径短、效率高需要二次分拣分区拣货仓库大、品类分区明显并行作业跨区订单要合并波次拣货订单量大、有截单时间平衡负载系统配置复杂实操经验是不要一上线就上最复杂的策略。先按单拣货跑通流程等作业稳定了再根据实际订单结构逐步切换到批量或波次。我见过有项目一上线就配波次拣货结果波次规则没调好拣货员在仓库里来回跑效率反而比手工还低。4.3 TMS的难点不在运输执行在运费和异常TMS管运输表面看是管货从A到B实际难点在两块运费计算和异常处理。运费计算这块规则复杂度远超想象。同一个承运商可能按重量计费、按体积计费、按趟次计费还有燃油附加费、等待费、卸货费。这些规则如果不在TMS里配置清楚月底对账就是一场灾难。我的建议是运费规则要在合同签订时就结构化把计费方式、费率、附加费条件都定义成TMS能识别的格式而不是等到对账时再人工算。异常处理这块TMS要能记录运输过程中的各种意外延误、货损、改道、拒收。这些异常不只是记录还要能触发后续动作——延误要通知客户、货损要发起理赔、拒收要安排退回。TMS如果只做运输跟踪不做异常闭环价值就少了一半。4.4 WMS与TMS的交接点月台管理WMS和TMS的交接点在月台装卸货口。货车到了TMS知道车到了WMS知道该卸到哪个库位但两边如果没打通就会出现车等位或位等车的尴尬。这个交接点的集成设计核心是预约机制。TMS把运输计划里的到货时间推给WMSWMS根据月台占用情况分配卸货时段再把确认结果回传TMS。这样司机出发前就知道几点到、去哪个门仓库也知道几点有车来、安排多少人卸货。这个机制看着简单但能显著降低月台拥堵是投入产出比很高的一项集成。5. 生产侧MES和PLM撑起制造的数据底座制造环节是供应链里数据最密集的一段。一个工单从下达到完工中间要经过几十道工序、上百次报工、无数次质量检验。MES和PLM就是用来接住这些数据的两个系统一个管怎么做出来一个管按什么标准做。5.1 MES的价值在工序级追溯不在大屏很多企业上MES最初的动机是想搞个车间大屏实时看产量。这个动机没错但如果MES只做到大屏展示那就浪费了。MES真正的价值在工序级的追溯能力。什么叫工序级追溯就是任何一个成品都能查到它经过了哪些工序、每道工序是谁做的、用的什么设备、什么参数、检验结果如何。这个能力在出现质量问题时价值巨大——不用整批召回可以精准定位到问题工序和问题批次。实现工序级追溯的前提是报工颗粒度要够细。如果报工只报到工单完工追溯就断了必须报到工序完工甚至工序内每个关键参数。当然颗粒度越细录入工作量越大所以要在追溯需求和录入成本之间找平衡。我的经验是关键工序影响产品性能的细报辅助工序如包装、贴标粗报。5.2 PLM管的是产品的基因BOM是核心中的核心PLM的核心是产品数据而产品数据的核心是BOM物料清单。BOM不只是一张物料列表它至少有三个层次设计BOMEBOM研发视角按产品功能结构组织反映产品由哪些零件组成。制造BOMMBOM工艺视角按装配顺序组织反映产品怎么装起来。服务BOMSBOM售后视角按维修单元组织反映坏了换哪个件。这三个BOM在PLM里定义在ERP和MES里使用。实际项目里最常见的坑就是EBOM到MBOM的转换没做好——研发改了设计MBOM没同步车间按旧BOM领料装出来才发现少了个件。所以PLM的变更管理流程必须和ERP、MES打通变更一旦生效下游要能收到通知并执行切换。5.3 PLM与ERP的物料编码对齐一个绕不过去的硬骨头前面提过PLM的物料偏工程属性ERP的物料偏商务属性两套编码怎么对齐是集成里的硬骨头。常见的做法有三种一是以PLM编码为主ERP沿用二是以ERP编码为主PLM做映射三是建独立的物料主数据平台两边都从平台取。三种做法各有适用场景我整理成表做法适用场景优点风险PLM主导研发驱动型企业工程数据一致性好ERP历史数据要迁移ERP主导商务驱动型企业财务口径稳定研发新物料要等编码主数据平台多系统、多工厂全局唯一建设成本高不管选哪种有一条铁律物料编码只能有一个权威源。两边都能新建物料必然出现一物多码后面所有的库存、成本、追溯都会乱。这个坑我见过太多次每次收拾起来都要花几个月。5.4 MES与WMS的物料流转衔接MES和WMS的衔接点在物料配送。车间要生产得先从仓库领料领料这个动作在WMS里是出库在MES里是投料两边必须对上。衔接方式有两种推式和拉式。推式是WMS按领料单主动配送拉式是MES按工单进度触发要料。大批量生产适合推式多品种小批量适合拉式。实际项目里往往是混合模式——常规物料推式配送紧急物料拉式要料。这里有个细节容易被忽略线边库存的管理。物料从仓库领出来到真正投料之间有一段线边库存。这段库存在WMS里已经出库了在MES里还没投料处于账外状态。如果不专门管理线边库存会变成黑洞月底盘点时对不上。解决办法是在WMS里设线边库位物料移到线边库位算移库不算出库投料时才真正出库。6. 支撑与交易侧ERP、OMS、CRM的分工与咬合支撑层的三个系统——ERP、OMS、CRM——是供应链的账房和前台。它们不直接指挥物理作业但决定了整个链条的结算口径和需求来源。6.1 ERP是主数据底座不是万能系统ERP的定位要摆正它是企业的主数据底座和财务核算中心。物料主数据、供应商主数据、客户主数据、会计科目这些全局性的数据应该在ERP里统一管理。但ERP不是万能的前面说的执行层作业ERP做不了也不该做。ERP在供应链里的核心作用有三个一是订单管理销售订单、采购订单的台账二是库存核算账面库存、成本核算三是财务结算应收应付、总账。这三个作用决定了ERP必须和其他系统保持数据同步但同步的方向和频率要设计好。同步设计的原则是主数据从ERP往下游推业务数据从下游往ERP汇总。物料主数据从ERP推到WMS、MES库存事务从WMS汇总到ERP。方向搞反了就会出现下游改了主数据、上游不知道的混乱。6.2 OMS解决的是订单履约的最后一公里协调OMS这个系统在有些企业里被合并进ERP在有些企业里独立存在。它解决的核心问题是一个订单进来怎么拆、怎么分配、怎么跟踪到履约完成。订单拆分是OMS的典型场景。一个订单可能因为库存分布在不同仓库、部分商品缺货、客户要求分批配送被拆成多个履约单。这些履约单分别流向不同的WMS和TMSOMS要负责跟踪每一单的状态最后汇总成对客户的统一反馈。OMS和ERP的边界在于ERP管订单的财务属性金额、信用、开票OMS管订单的履约属性拆分、分配、跟踪。两者通过订单号关联各管一段。6.3 CRM与供应链的接口需求信号的源头CRM通常被归到销售侧但它和供应链的连接点很关键——需求信号。CRM里的商机、订单预测、客户订单是SCM做需求预测的重要输入。这个接口如果没打通就会出现销售在CRM里报的预测和SCM算出来的预测对不上的情况。解决办法不是让两边算得一样而是建立预测共识机制——CRM提供销售侧的判断SCM提供历史数据的统计两者在产销协同会上对齐形成最终的计划版本。7. 十个系统拼成一张架构图集成关系与数据流向前面六个章节把十个系统逐个拆开了这一章把它们拼回去。拼的时候不是简单堆叠而是按数据流向和集成关系来组织。7.1 分层架构图与集成总线从架构上看这十个系统可以画成三层加一条总线顶层是计划与协同层SCM、PMS、CRM。这一层输出计划、预测、需求信号。中间是执行层SRM、WMS、TMS、MES、OMS。这一层承接计划执行物理作业产生实时数据。底层是支撑层ERP、PLM。这一层提供主数据和核算能力。贯穿三层的是集成总线所有系统之间的数据交换都通过总线或API网关走而不是系统之间点对点直连。点对点直连的问题是系统一多连接数呈平方级增长维护成本爆炸。走总线的话每个系统只对接总线新增系统只需接一次。用文字描述数据流向大致是CRM的需求信号→SCM做预测→PMS做排程→MES执行生产、SRM执行采购→WMS/TMS执行仓储运输→所有执行数据汇总到ERP核算。PLM的BOM数据同时供给MES指导生产和ERP指导成本核算。7.2 关键集成链路清单实际做集成时不可能一次把所有链路都做完要排优先级。下面这几条是我认为优先级最高的PLM→ERP的物料与BOM同步这是所有数据的基础不同步后面全乱。ERP→WMS的物料主数据与采购订单同步仓库收货要用。WMS→ERP的库存事务回传账实一致的前提。SRM→ERP的供应商与协议价格同步采购下单要用。MES→ERP的工单完工与领料回传成本核算要用。TMS→ERP的运费结算数据回传应付账款要用。这六条链路覆盖了主数据、库存、采购、生产、物流、财务六个维度做完这六条基本盘就稳了。剩下的链路如SCM与PMS的计划协同、OMS与WMS的履约跟踪可以按业务优先级逐步补。7.3 集成方式的选择接口、中间表还是消息队列集成方式的选择取决于实时性要求和数据量。我整理了一个对照表方式适用场景实时性复杂度API接口主数据同步、单据传递准实时中中间表批量数据汇总、报表取数定时如每小时低消息队列高频事务、事件通知实时高实操建议主数据和单据用API批量汇总用中间表高频事务如WMS的库存事务用消息队列。不要所有链路都用一种方式也不要用消息队列去传大批量历史数据——那是杀鸡用牛刀还容易把队列堵死。8. 落地时最容易翻车的几个地方系统清单讲完了架构也拼完了最后说说落地。这一章不讲理论讲我实际项目里见过、踩过的坑。8.1 主数据不统一集成做再多也白搭这是最老生常谈但又最常翻车的一条。物料编码一物多码、供应商一处多名、客户档案重复这些问题不解决集成链路建得再漂亮传过去的数据也是脏的。我的经验是上集成之前先做一轮主数据清洗。清洗的重点是物料和供应商方法是定编码规则、定唯一性校验、定变更流程。清洗的工作量可能占整个项目的一半但省不得。见过有项目为了赶进度跳过清洗结果上线后天天对账返工成本远超清洗成本。8.2 边界不清导致的系统打架系统打架的典型表现是同一个数据两个系统都能改改完还不一致。比如库存WMS能改、ERP也能改最后谁说了算解决办法是明确每个数据的权威源。库存的权威源是WMSERP只读不写物料主数据的权威源是ERP或PLM看企业选择其他系统只读。权威源一旦定下来就要在权限和接口上落实——非权威源系统的写权限要关掉接口只做单向同步。8.3 上线顺序的取舍先上哪个后上哪个十个系统不可能一起上顺序怎么排我的建议是按数据依赖排而不是按业务重要性排。先上PLM或ERP主数据底座再上WMS和SRM执行层依赖主数据然后上MES和TMS更复杂的执行层最后上SCM和PMS计划层依赖执行层的数据。OMS和CRM可以穿插在中间看业务紧迫性。这个顺序的逻辑是下游系统依赖上游系统的数据上游没上稳下游上了也是空转。见过有企业先上WMS结果物料主数据还没统一WMS里一堆临时编码后面ERP上线时全部要返工。8.4 用户不用系统再好的架构也是摆设最后一条也是最容易被技术团队忽略的一条系统是给人用的。仓库的拣货员、车间的班组长、采购的跟单员他们用不用系统决定了系统有没有价值。让用户愿意用关键在三点一是操作要快扫码比打字快能扫就别让填二是信息要准用户看到的数据要实时、要正确三是反馈要闭环用户提的问题要有人管、有回应。这三点做到了推广就顺做不到再好的架构也只是PPT上的图。我在实际项目里的体会是供应链系统的成败技术只占三成剩下七成是业务梳理和组织协同。系统架构图画得再漂亮如果业务职责没理清、部门之间没对齐落地时照样一地鸡毛。所以每次做系统规划我都会先花时间把业务流程和职责边界捋一遍再谈系统怎么建——这个顺序反不得。
