本文来源公众号：Edison的SAP实践与修行，作者： Edison
一谈到“计划”，也许首先映入脑海的便是“MRP”。的确，作为计划中最经典的代表，MRP再加上MPS，在某种程度上，特别是在如今很多企业的业务人员的认知中就是“计划”的代名词。当然，MPS与MRP，更多的是“业务”上的划分，对象的不同、业务目的的不同而已，前者主要针对的是主营业务成品、后者主要针对的是保证主营业务成品的制造过程中的物料，所以更多的将MPS表述为生产计划，MRP表述为物料计划；但是，从技术角度而言，这二者本没有明显的差异，从技术本质上来说都是从毛需求到净需求的计划，然后依据供给方式、计划参数等建议出合理的补货计划。
图一：MRP/MPS的技术过程概览
MRP的理念，自从1950年代开始引入后，特别是在IT系统例如MRP II、ERP、APS等的功能赋能下，得到的快速地发展与应用，甚至几乎可以说，有业务需求便有MRP，无论这里的“业务需求”是如制造型企业的生产需求，还是如贸易公司的分销调拨需求；所以，再落到IT系统建设，有无MRP，或者更准确地说MRP是否真正跑起来，也成为了ERP、APS是否成功的一个重要标志。
然而，在现实中，正如前面的文章（为什么说计划业务应该由IT系统提供帮助？）与（浅析供应链计划系统建设的难点与挑战）都有提到，“愿望是美好的，现实却是很骨感的”，我们更多看到的是，即使应用了像SAP、Oracle、金蝶、用友等很优秀的ERP软件，甚至还应用了像IBP、APO、BY、O9、杉数、数策等大量优秀的APS类软件，依然企业里的MRP很难真正地被应用起来，这里的“应用起来”不该模糊、就应该明确地指的是：能真正地帮助用户来指导供应计划，首先要“跑得来”、其次要“算得准”、最后要“管得好”。
作为从业者，扪心自问，头脑中有几家这样真正MRP达到这3个点的企业呢？
这是一个很好的话题，也是一个值得不断反复思考的话题，因为无论什么样的IT产品，也无论怎么样的IT销售，最终只有真正地为业务带来价值的IT产品与IT解决方案，才能真正地被不断推动前进，也才能真正地变得长久有意义。
纯粹个人的经验与看法。对于MRP，在接触到的很多的企业与用户， “愿望在左、现实在右”，围绕着怎样才能真正的“跑得来、算得准、管得好”，个人认为以下几个点便是“非常值得不断反复思考话题”中的典型代表。
MRP不是一个功能点的应用，而应该是一个计划体系的建设
MRP，正如前文图一所示，其技术过程的体现，从表象上来看的确是一个“功能点”的应用，即如何将毛需求转向净需求然后对净需求以正确的方式来补货。
如果MRP的问题，真地就是这么简单的技术问题，那无非就是将主数据的完整性与及时性、计划参数的正确性以及业务数据的实时性保证起来，那么MRP在一定程度上来说就已经达到了刚所述的3大目标（跑得来、算得准、管得好）。
然而，我们发现，事实并非如此，无论是主数据还是业务数据，我们不否认要真正做到“完整性”与“及时性”对于业务的挑战都还是比较高的，但通过努力以及管控都还是可以达到比较可接收的程度，但即使做到这些（即做到可接收的程度，甚至“跑得来”也“算得准”），MRP依然很难真正地被长久地有效地应用起来（即真正的“管得好”）。甚至正是这样的认知，在很多的MRP项目甚至大计划项目里，有时候“路还会走偏”、“本末倒置”，大量的精力去强调“数据对MRP的影响”，所以设置了一大堆有的没的IT规则、IT参数，自认为管好了“主数据”、管好了“业务数据”，从而貌似做到的“跑得来”也“算得准”，但却忽视了“流程及规则对MRP的影响”，因为数据总是在变动的，计划的环境、业务的场景也总是在变化的，数据、参数永远都只是辅助，MRP问题的核心还是应该首先要确定好流程与规则，即 MRP到底该怎么运行、运行的规则到底是什么。
所以，个人的观点：MRP，绝对不是一个功能点的应用，也绝对不是一个靠把数据、计划参数等维护好跑个Job就能收获完美结果的IT功能；MRP的核心，应该首先是一个流程Process+规则Rule的业务集合体，然后才是IT应用的体现者。
前面好些篇记录总结时总说，做IT系统、IT解决方案的，不应该眼光总落在IT技术、IT产品上，而应该从业务的角度来看业务流程Process、来看业务规则Rule、甚至还来看业务指标KPI、组织架构Organization。貌似好比自己总在强调“咨询”而轻“IT”，其实并不是，只是所写的话题，对于“供应链”、对于“供应链计划”、对于“MRP”，一定脱离不了业务。光说业务的顾问，有一点“耍流氓”与“务虚”地存在，因为光说业务，一定说不过或者一定说不全甲方所实实在在每天都在操作的业务，但优秀顾问存在的价值，便是快速地去甲方所最熟悉的业务中提纲挈领、一击击中地发现问题，并将甲方的业务进行乙方的梳理，然后提出契合甲方的解决方案，包括业务与IT解决方案。
所以，回到MRP这个话题，为什么说MRP绝不是一个功能点的应用？便是因为，正如前面一篇文章（为什么说计划业务应该由IT系统提供帮助？）中谈到MRP时，说到SAP践行的供应链计划体系的“最佳业务实践”。请先勿反感“最佳业务实践”，虽然不同的行业、不同的企业，业务实践一定不同，但我们所说的最佳业务实践并不是一个放之四海、各个企业都必须原封不动地使用的“实践”，而是如前文所述“优秀顾问”的能力一样，是“优秀咨询公司”、“优秀的软件企业”从大量的实践中发现规律、发现本质的东西，并给出的“骨架般”的“业务实践架构”，并取名为“最佳业务实践”，以希望将这些规律、这些本质更快速地传递，让企业避免重复的“造轮子”或“走弯路”。
图二：SAP产品支撑下的供应链计划最佳业务实践
所以，从业务的角度来看，计划便不是一个一蹴而就的点、而是此种以体系型的面上的存在，从战略计划到战术计划到运营计划。所以，可以看到，在不同的计划层级，长期的规划计划、中长期的S&OP计划、中短期的MPS主生产计划、短期的排产计划、超短期的排序计划，MRP都是一定存在的，战略性的备货、中长期采购备货、短期的JIT采购备货、超短期的JIS拉料送货等等都是MRP的应用也是MRP的计划结果，所以，显而易见，MRP绝对不仅仅只是一个最终按PC生产计划算出毛需求、展个BOM、算个净需求跑个MC物料计划这么简单的单点功能应用，而应该切切实实地被应用于完整的计划体系中：首先从业务上依据企业自身的供应链运营体系，特别是供应链计划过程，梳理业务流程Process；然后再业务上根据不同的物料管控策略，规范物料MRP规则Rule；然后，依据流程与规则，重视数据的质量，包括主数据、计划参数、业务数据，即前文所提到的“数据完整性与及时性”；最后，各层级的MRP，此时才算是真正地是一个功能点的应用。
MRP不该与MPS隔离开来，而应该是相辅相成
MRP的目的到底是什么？我们知道，MRP是为了把“供应做上去”，保证物料不断、保证库存管控，从而最终保证生产、制造、交付得到平稳而不影响主营销售业务，同时兼顾服务水平、收入、现金与成本。
图三：计划的“平衡”本质
所以，正如开篇所述，如果把MRP定位于“物料计划”，那么MRP就一定不能脱离定位于“生产计划”MPS，MRP与MPS一定是相辅相成的。
前面也说到，在很多现实情况下，我们看到，MRP真地就沦为了，当ERP中生产计划确定后（无论是线上排产还是线下手工排好后导入ERP），运行一下MD01/MD41等事务代码。所以，MRP成为了一种MPS事后型的存在。
这其实是一个很Tricky模糊的存在。我们看到，正因为以前的IT系统的发展、IT架构的原因，例如即使强于SAP这样的ERP，即使它有PP这样的生产计划模块，但ERP本身是一个“Transaction事务型”、“重执行“的系统架构，SAP中的PP模块也更偏重的是“执行”而非“计划”，PP模块支撑的业务，更多的是根据生产计划做报工、收货、投料反冲、集成成本做到业财一体等，而这个生产计划是如何来的？SAP PP从本质上来说并不支撑，其支撑的最多也只是一个类似于MRP的事务代码运行，但业务上的生产计划哪有这么简单，比如考虑产能约束、考虑工艺约束，SAP的PP是无法做到的（所以，更多的便是计划员线下做好计划，然后通过接口或手工导入SAP）。真正的“计划”，这其实是APS（SAP的PPDS或IBP）的业务领域范围了。所以，ERP中MRP，在某种程度上来说，之所以沦为当生产计划MPS确定后的一个事务代码的运行，也是其一种无奈之举。
但是，时代的变迁、商业社会的发展却并不会因为IT产品和IT架构而放慢其步伐，在如今的计划环境下，即使强势如Auto行业的汽车主机厂这样的存在，随着汽车电子化的进程，物料约束例如熟知的“缺芯”也实实在在地不断地发生，所以，物料供应情况就应该在形成生产计划MPS时被考虑。也就是说，MPS生产计划不应该在没有MRP物料计划参与的情况下，就制定出生产计划；同时反过来，MRP物料计划也不该完全的“跪舔”MPS生产计划，变成了名义上纯粹的“采购执行”。
所以，个人的观点：MRP与MPS的相辅相成，更多的是说在制定生产计划时，除了生产计划本身要考虑的“人、机、法、环”约束外，“料”的约束也更需要考虑，即需要考虑物控、需要MRP物料计划的输入，来制定综合考虑约束后的可执行的生产计划，最后的MRP才是可执行的MRP。
例如刚说到的汽车缺芯，以月计划为例，当在主机厂的月度S&OP计划过程中，在做需求与供应评审时，首先需要根据整车的预测，运行MRP，获得具体的例如ESP哪款芯片的补货需求（按规则Rule从毛需求算到净需求），然后跟供应商协同（或者提前获得的供应商产能的分配信息）得到该款芯片的需求预测确认，最后按确认后的需求来反推整车的生产计划，保证后续的ESP芯片能真正供应上来。
MRP不是一成不变，需要长久的追踪与不断的修正
前面也提到，借助MRP做好物料计划， 从“跑得来”到“算得准”，最终希望达到“管得好”。而商业环境总是在发展、企业所面临的业务也在不断地变化着，显而易见，“跑得来、算得准、管得好”绝不是一成不变的，计划一定是一个长期不断修正、不断发展的业务应用，MRP更是如此。
例如，采购部门开发多点供应了，企业强力推行JIT零库存管理了，VMI、Consignment大量应用了，供应商考核出现了，替代料出现了，Lead Time、MOQ、EOQ变化了，自制转外购了、外购转自产了等等，这些变化，势必要求企业自身的MRP也随着快速地变化。
图四：MRP是一个长期工程
所以，个人的观点：业务上的MRP快速的变化，也就要求IT技术上的MRP也能快速地变化，甚至对于IT技术要求更高，即在业务未发生真正变化时，IT技术先行，比如MRP的Simulation模拟、What-if分析等等。
所以，我们经常听到，例如，从中国惠州工厂到越南工厂，如果海运太慢，那改用陆运的话，越南工厂的MRP是否便可以更好地满足客户要求？但如果改用陆运了，运输成本又增加了，如果站在集团整体上而言，此版的MRP是否应该被真正的执行呢？
同时，前面所提到的“数据对MRP的影响”，更是一个需要与时俱进的的方面，包括各项计划的参数、采购策略，那么也就需要有长久稳固的企业IT管理机制，能及时地指导相关责任人员正确的或维护或调整IT数据，当然这里的“相关责任人员“绝对不仅仅只是IT人员，更多的还应该是相关的业务人员，包括PMC、仓储管理人员等等。
MRP一定需要成功，供应链建设才有可能真正成功
最后，聊了这么多关于MRP，都是个人的观点与看法，一定带有很强烈的个人主观局限性，甚至错误之处也在所难免。
然而，对于MRP本身，正如前文所述，无论是出于历史所造成的IT系统、IT架构以及IT产品定位的问题，还是出于企业内部一般都会“先重执行、再开始计划管控”的管理运营的实践，以及出于相关业务从业人员对MRP的认知原因，诸多的主客观因素，导致了如今在企业MRP场景上，我们看到，几乎没有哪一家企业业务上不关心MRP，但在IT系统上MRP却总是跑得并不那么完美，要么跑不起来，要么跑得不准，更别提管得好。
但是，MRP是难点，并不代表着这个业务处理不了，在以前的文章（为什么说计划业务应该由IT系统提供帮助？）便阐述了个人乐观的看法。
除此之外，正如本篇开头所强调的是，个人认为，如今企业的IT建设，受益于经济社会的发展，企业IT建设的阶段也在发展，慢慢地从最刚开始的偏“事务”、偏“执行”，以ERP、MES、LES等为代表的IT系统，向偏“管理”、偏“计划”重视起来，此时便以IBP、APS、BPC、SAC等为代表的IT系统。这其中，“供应链”的IT建设，是绝对的领头及重点领域。
然而，要建设供应链，以SCOR模块为例，“计划”又是绝对的核心，这便是我们常说的“供应链的大脑工程”。
图五：SCOR模型（参考APICS）
所以，我们完全有理由认为：作为计划的最经典的代表，只有MRP成功，计划才可能成功，最终供应链建设也才可能真正成功。
同时个人也完全相信，正如前面提到的几个观点，如果MRP，不厚此薄彼，首先从业务入手，再落地到数据支撑、IT支撑，从计划体系的完整规划建设、到MPS与MRP的相辅相成、最终到长期螺旋式的不断修正，那么MRP一定可以得到很好的发展壮大，最终真正地赋能业务，让业务信任MRP、让MRP反哺业务运营。
更多价值博文在微信公众号，欢迎扫码关注！
