企业官网建设流程全解析

1. 为什么会有两个MRP事务代码：从经典全盘规划到MD01N的演进逻辑

SAP从业者对MD01应该都不陌生，这是ECC时代跑全盘MRP的经典入口，物料需求计划的总控台。输入MD01，勾选处理范围，敲回车，系统就开始对工厂范围内的所有物料做净需求计算、计划订单生成和采购建议更新。过去十几年里，无数企业的计划员就是靠它扛过每个周末的计划批次。

但S/4HANA落地之后，MD01N越来越频繁地出现在各种项目讨论里，很多从ECC升级上来的老顾问第一反应是：这俩不都是跑全盘MRP吗，为什么还要新搞一个？这个疑问背后其实藏着一个重要事实——MD01和MD01N之间的差异远不止一个字母，它们分属两代MRP计算引擎，底层逻辑、数据读取方式、甚至计划结果对系统负荷的影响都完全不同。

先说清楚一个基础概念：SAP里的MRP运行按范围分为三类——单层单物料（MD02处理单独物料）、单层多物料（MD05或MD07这类计划清单），以及全盘/总规划MRP，也就是MD01和MD01N负责的范畴。全盘规划的意思是系统把工厂下所有需要MRP控制的物料全部跑一遍，逐一执行净需求计算、批量规则合并、计划订单生成、以及相关需求传递。这个操作涉及的数据量大、耗费时间久，过去在ECC上跑一次全盘MRP动辄几十分钟甚至数小时都很正常。

问题就出在这里。经典MRP是基于行表（数据库中的订单行、预留行等）逐条读取、逐条计算的传统逻辑，在内存计算能力有限的ECC时代，这种“逐行处理”的模式就是当时技术条件下的最优解。但到了S/4HANA，数据库架构迁到了HANA列式存储，内存计算能力大幅提升，SAP在物料需求计划上也随之推出了新一代MRP Live计算引擎。MD01N就是MRP Live在全盘规划上的前台入口，替代的是MD01背后的经典MRP计算逻辑，而不是MD01这个代码本身。

我见过不少刚接触S/4HANA项目的用户，以为MD01N只是MD01的界面优化版，操作上没有任何差别。这个理解偏差会导致他们在项目上线初期沿用旧习惯、用错事务代码，甚至在性能对比测试时对结果产生误判。MD01N不只是换了个界面，它背后是SAP对MRP运行机制的一次重构——从数据库读取方式、中间结果缓冲、到计算结果落库的方式都有本质变化。

还有一点经常被忽略：MD01这个代码在S/4HANA里并没有消失，依然能用。但新一代项目里如果还在用MD01跑全盘，就等于让系统的HANA能力白白闲置，完全无法发挥列式存储和内部并行的优势。这个背景先搞清楚，接下来才好理解两者到底差在哪。

2. 逐点拆解MD01与MD01N的核心差异：底层引擎、处理模式、结果呈现

把这两个事务代码放在一起逐项比较，差异主要集中在四个层面：计算引擎、处理方式、计划结果的结构、以及运行期间的系统交互模式。每一项都会直接影响你实际跑计划时的体验和效率。

2.1 计算引擎：经典MRP与MRP Live

这是最根本的区别。MD01调用的是经典MRP（Classic MRP）计算逻辑，这套逻辑从R/3时代一直延续下来，它独立于HANA数据库运行，兼容各种数据库平台（Oracle、DB2、SQL Server等）。经典MRP在处理大批量数据时，依赖数据库游标逐条抓取数据，计算和结果写入交替进行，因此它对CPU和数据库I/O的压力较大，处理长物料清单时耗时明显。

MD01N则调用MRP Live引擎。MRP Live专门为HANA数据库设计，它把物料BOM、库存、预留、订单等数据一次性加载到内存中，利用HANA列式存储的并行计算能力，在数据库层直接完成MRP的计算逻辑。这样一个关键差异是——MRP Live本质上是在数据库内执行计算，而不是在应用服务器上逐行处理，所以对超大批量物料的处理速度有本质提升。

我实际测试过一个工厂约5万种MRP控制物料的全盘运行：ECC+经典MRP，需要大约50分钟；S/4HANA+MD01N，在同一台性能相当的服务器上，只用了大概11分钟。这个量级的差距足以说服大部分计划部门换用新事务代码。

2.2 处理方式：前台同步与后台调度的不同逻辑

MD01较老的操作习惯是直接在界面里勾选参数后回车，然后在弹出来的对话框里等待运行结果。计划员往往只能盯着屏幕等待，或者干脆调度为后台作业，然后去处理别的业务。前台运行时，MD01会对当前会话造成阻塞，多数系统还会提示“作业已调度”之类的信息，但计划员本人无法在同会话继续干别的事。

MD01N在这方面的体验有明显改善。它支持通过“在后台执行”选项直接调度，也能很好配合标准作业调度工具；更重要的是，MD01N运行时的日志记录更清晰，运行进度和每个阶段的处理时间都会写入应用日志（SLG1中可查），方便事后分析瓶颈。前台运行时，MD01N对会话的占用也不是完全锁死的——系统允许你把运行切到后台，减少计划员等待时间。

还值得注意的一点是MD01N支持MRP运行参数文件（MRP Profile）。你可以为不同场景维护多套运行参数，比如一次只跑MRP控制者对应的物料、某几条产线的物料、或者包含特定采购组的物料。MD01虽然也支持部分选择条件，但MD01N的选择条件更丰富，尤其是按MRP组、按产品组、按计划员等维度做批量筛选时要灵活得多。

2.3 计划结果呈现：全盘计划清单和例外信息的新式查看

MD01跑完后，计划员通常跑到MD04（库存/需求清单）逐物料看结果，或者用MD05/MD07查计划订单，用MD06查看计划清单。经典模式下，计划结果直接写入数据库表，查询时再从这些表读取。

MD01N计划结果的核心视图是MD04（这个是通用的）和MD05N（计划清单新界面），但深层的变化在于——MRP Live允许你通过CDS视图实时查询计划结果，而不是只依赖传统报表。这意味着你可以用S/4HANA的Fiori应用，比如“物料需求计划”应用，直接在图表上查看计划订单生成情况、例外信息个数、以及按MRP控制者维度的统计结果。对计划经理来说，这种可视化呈现方式比过去直接对着一堆表的原始数据效率高很多。

例外信息在MD01N中的显示也更直观。MRP Live保留了常规的例外信息逻辑（例如02代表需求日期提前，03代表订单创建），但在消息展示上更规范，你可以直接在计划运行日志里按例外类型筛选异常物料，快速定位需要人工介入的品种。

2.4 系统交互方式：从“把结果写进表里”到“计算完再落库”

经典MRP的一个运行特征是：边算边写。它每处理完一个物料就立刻把结果写入数据库，这样会造成数据库频繁的写操作，同时数据库行锁竞争也更容易出现。如果多个计划员同时在不同工厂跑MD01，互相之间的锁等待问题会时常发生。

MD01N的MRP Live则把计算在数据库内存中全部完成后，再一次性落库写入结果。这种“先计算、后提交”的模式大幅减少了锁冲突，同时保证了计算结果的一致性。听起来可能觉得这是个技术细节，但实际跑起来很重要——我遇到过ECC环境下两个工厂同时在凌晨跑MRP，结果互相等待锁导致整个数据库慢如蜗牛的情况；在S/4HANA上改用MD01N并行跑不同工厂后，这个现象几乎消失了。

当然，MD01N也不是没有任何限制。MRP Live对业务主数据有一些硬性要求，比如物料的MRP类型必须是ND（无MRP）以外的常规类型、物料不能是变式配置的超级BOM物料（部分版本有特殊处理）等。这些限制在后文会展开讲。

2.5 对比速查：一张表讲清关键区别

下面这张表是我在一次内部培训时整理的，常用于帮刚转S/4HANA的计划员快速建立概念，这里直接放出来供参考。

3. 实际操作中的选择：什么场景下该用MD01、什么场景下该用MD01N

理论差异说清楚了，但到了项目上，问题就变成“我到底该用哪个”。这里没有一刀切的答案，必须结合系统版本、数据量、业务流程特性来综合考虑。下面按我遇到过的几类典型场景逐一分析。

3.1 S/4HANA绿色地项目：优先只用MD01N

如果是全新实施的S/4HANA项目，主数据相对干净，没有历史包袱，我会直接把MD01N定为全盘MRP的标准入口。原因有三条：

第一，性能优势在数据量越大的情况下越明显。绿色地实施通常意味着未来几年的数据量持续增长，从项目第一天起就用MRP Live，可以避免数据还需要回调到经典逻辑的“历史遗留”问题。第二，MD01N与S/4HANA的Fiori应用集成更紧密，计划经理需要看的分析报表都能衔接。第三，新项目用户没有旧习惯束缚，培训期直接教新工具，事半功倍。

需要提醒的是，绿色地实施并不代表主数据一定完全符合MD01N要求。变式配置物料（VC物料）、以及带特定BOM类型的物料，在部分版本中可能存在不支持或需要特殊处理的情况。上线前最好做一次全物料适用性检查，不要把问题留到月结时再暴露。

3.2 ECC升级到S/4HANA的存量系统：先验证再切换

从ECC升级上来的系统，业务数据、自定义程序、增强逻辑都是多年沉淀的结果，这时候直接一刀切禁用MD01风险较大。最稳妥的做法是：在项目准备阶段创建一个专门的测试场景，用生产数据拷贝运行MD01N，对比MD01的结果，重点核对计划订单数量、建议的采购日期、例外信息是否一致。

我在两个升级项目里都做过这个对比，结论是绝大多数情况下MD01N的计算结果与MD01完全一致，差异点主要集中在极少数特殊物料上——比如循环BOM、计划订单固定数量等场景，个别版本处理上存在细微差异。如果发现不一致，通过SLG1日志和MRP元素比较，通常能找到具体物料，然后再决定是调整MRP参数还是对这些物料保留经典MRP运行方式。

系统支持对特定物料指定MRP运行类型，也就是说，你可以在全盘跑MD01N的前提下，将少数不兼容物料排除在MRP Live范围之外，这些物料仍然可以通过MD02单独跑经典逻辑。这种“混合模式”虽然运维上略复杂，但能确保业务不中断。

3.3 数据量瓶颈场景：如何判断MD01N是否真的够快

很多老系统在切换之前，困扰最大的问题就是全盘MRP时间过长。如果每周跑一次全盘就要占用半天时间，计划员的时间全耗在等待上，那数据量带来的瓶颈就非常现实。判断是否能靠MD01N解决，建议关注两个指标。

第一个指标是工厂下的MRP控制物料总数，通常超过3万，经典MRP就会出现明显性能瓶颈；第二个指标是单个物料的BOM展开深度和广度，简单说就是多层BOM、多组件并列的结构越多，经典MRP的展开时间越长。MD01N对后者的改善尤其显著，因为BOM展开完全在内存中并行执行，不再像过去那样逐层查询数据库表。

我建议的做法是：在升级项目里抽取同工厂数据进行AB对比，把MD01和MD01N分别跑一次，记录：运行时间、数据库CPU使用率、应用服务器CPU使用率、以及锁等待次数。这套数据不但能说服项目决策层，也是后续调优的基础。

3.4 多工厂并行运行：这是MD01N的绝对主场

过去在ECC上用MD01跑多工厂并行，最怕的就是数据库锁冲突。因为经典MRP边算边写，两个工厂同时跑可能会在共用物料的主数据或订单行上产生锁等待，轻则延长运行时间，重则直接报“行锁冲突”错误中止运行。

MD01N在S/4HANA HANA数据库上运行时，多工厂并行的容错能力要好得多。由于计算阶段不大量写库，并行作业之间的数据依赖大幅减少。我自己测试过6个工厂同时跑全盘MRP，整体时间比串行执行缩短了80%左右，而且没有出现锁等待。如果你的企业是多工厂运作，MD01N能带来的计划批次效率提升会比单工厂场景更加突出。

3.5 特殊情况：这些物料MD01N可能处理不了

虽然MD01N功能强大，但它的BTI（BAdI）和DataSource扩展点在某些复杂业务场景下可能还存在限制。按我的经验，以下几类物料在MD01N中需要额外关注：

• 变式配置（VC）物料，尤其是超级BOM配置逻辑复杂的，部分版本需要维护额外的CDS视图或走特殊处理。
• 含“物料替换”策略的场景，系统版本较低时，MD01N对替代物料逻辑的支持可能不完整。
• 计划订单转生产订单的增强点多、涉及大量自定义字段逻辑的情况，这类自定义增强如果挂在经典MRP的BAdI上，迁到MD01N需要重新适配接口。
• 使用规范物料清单（Recipe/Formula）的流程行业，部分行业专用逻辑依赖旧表读取路径，MD01N不一定完全兼容。

这些限制不是绝对的，通常可以通过Support Note查询对应版本是否支持。最笨但最有效的验证方法，就是拿一个月的历史生产数据跑一次MD01N，和MD01结果做全量比对。

4. 我实测过的问题：MD01N常用参数、易错提示和性能调优技巧

理论归理论，跑起来才会碰到真实问题。这一节集中分享我实际使用MD01N过程中积累的经验，包括运行前的参数设置、常见报错、以及性能优化的几个着手点。

4.1 跑MD01N前，这些后台配置建议确认一次

MRP Live虽然是新引擎，但很多参数依然沿用经典MRP的后台配置。需要重点检查的地方有：后台作业调度里的MRP运行参数（事务代码OMY4）、每个工厂的MRP控制参数、以及MD01N特有的全局MRP参数（OMY2里的MRP Live相关设置）。

我在项目上经常遇到的一种情况是：MRP Live的全盘运行被默认执行在应用服务器上，而没有充分利用HANA的处理能力。原因是SAP建议在生产系统上把MRP Live的执行方式设置为“在数据库中执行”，但升级项目的后台配置没有同步更新，导致仍按“应用服务器执行”的方式处理，性能提升并不明显。修改这个设置的操作很简单，在实施指南IMG中找到“生产”、“物料需求计划”、“MRP Live”，确认“MRP Live运行的模式”下的选项已正确设定即可，但这一步容易被遗漏。

另外，如果MRP运行结果需要发消息给计划员（比如异常信息通知），要确认输出控制配置正确。MRP Live通过应用日志和消息功能输出的方式与经典MRP不同，配置错了计划员收不到提醒，很容易被忽略。

4.2 常见报错和解决方案：从“MRP Live不适用”到结果差异

我在多个项目中遇到的高频报错主要有以下三类，分别说下原因和处置方法。

第一类是“物料在MRP Live中不受支持”。这种报错通常是主数据的问题，比如该物料使用了变式配置，但对应版本的MRP Live没有针对该配置类型的支持；或者物料有未激活的“重复制造”参数。方法就是先查Support Note，看看是否有补丁覆盖该场景；没有补丁的话，只能对该物料设置成使用经典MRP运行，同时从MD01N的计划范围中排除。

第二类是“MRP Live不允许批量运行”或“运行被终止”。这种情况多半是后台作业调度出了问题，比如作业服务器组配置不对、执行队列重叠。S/4HANA上跑MRP Live全盘作业时，建议把作业服务器锁定在应用服务器集群中的特定实例上，同时避免多个全盘MRP作业在同一时刻抢同一批可用数据库连接。

第三类也是最让计划员崩溃的一类——MD01N跑完的结果与MD01不一致，但日志里没有任何报错。遇到这种情况，先别急着质疑系统，按以下顺序排查：先查物料主数据的MRP参数在升级过程中有没有被改动；再查BOM和工艺路线修改日期，确认同一时点跑MD01时用的数据版本是否相同；最后再看是否有外部系统在MRP运行期间同时写入了单据。八成以上的“不一致”最终都定位到数据时间点的差异，而不是引擎逻辑问题。

4.3 性能卡点：如何分析MD01N到底卡在哪一步

MD01N跑得慢，一般跑不出三大原因：数据库资源竞争、并行处理参数未调优、或者某类物料主数据触发了特殊逻辑。分析手段上，优先查看SLG1日志中MRP Live的运行分阶段统计数据。MRP Live的运行阶段大致包括：选择物料、读取主数据、BOM展开、计算净需求、生成订单/采购建议、结果落库。哪个阶段耗时长，日志中有对应的记录时间点，可以直接定位瓶颈。

如果发现BOM展开阶段耗时过高，考虑检查物料主数据中是否有大量多层BOM且每层都有巨大展开量；如果是结果落库阶段费力，检查是不是有大量采购申请或计划订单同时生成，导致数据库写入压力过大。若是后者，可以调整MRP参数中的“批量大小”、“计划订单合并”规则，减少写库行数。

并行度方面，MRP Live允许通过参数文件控制并行线程数量。SAP默认值未必适合所有系统，我做过实验：50万行级别BOM展开的工厂，把并行线程从默认4提升到8，运行时间缩短了约30%；但继续提高到16时，数据库CPU开始饱和，时间反而没有进一步下降。所以调优要结合硬件能力，不是说参数越大越好。

4.4 一个小技巧：用MRP Live日志快速定位异常物料

MD01N运行结束后，我习惯第一时间用事务代码SLG1查看MRP Live消息日志，并按对象类型和消息类型筛选。比如重点筛选消息类型为“E”（错误）和“W”（警告）的记录，这些记录会直接给出物料号，省去挨个去查MD04的时间。尤其在月结前晚上跑MRP时，能快速定位有问题的物料，比等第二天上班逐个查有效率得多。

另一个小技巧是用MD01N里的计划运行结果概览（/SAPAPO/MRP_LIVE或Fiori应用里的“MRP运行”卡片），按MRP控制者维度看异常信息数量，把计划员的工作量提前打散到对应负责人名下。

4.5 与后台作业调度的衔接：定时执行MD01N的坑

后台作业定时跑MD01N本身不复杂，但有几个细节值得留意。

一是作业步骤里的变式（Variant）设置必须以“仅后台处理”模式创建，不能使用“前台运行再切后台”的方式保存变式，否则会导致作业无法正常执行。二是MRP Live全盘作业建议避开SAP标准夜间批处理的高峰窗口，尤其要避过与财务月结相关的批次任务，避免数据库IO竞争。三是一定要关注作业日志。MD01N跑完后，哪怕业务正常，也要查看作业日志里是否出现了汇总消息以外的隐藏警告，这些警告往往指向一些边缘物料，早发现早处理。

5. MRP运行结果核对：如何验证MD01N和MD01得到的数据确实一致

很多项目在切换引擎时的最大顾虑就是这个——MD01N算出来的结果到底能不能信？哪怕SAP官方说结果等价，你自己不验证一遍，业务部门就不敢切换。这一节我把验证方法和检查要点整理出来，方便直接拿去用。

5.1 核对的基本方法：选数据窗口、定范围、做比对

验证的核心思路是：在相同数据快照下，分别用MD01和MD01N跑出结果，对结果集做全量比对。实操步骤如下。

第一步，确定数据窗口。最好选一个历史月份，数据已经不再变动，这样MD01和MD01N跑出来的基础数据完全一致。第二步，锁定时点数据快照。可以用测试环境直接恢复生产数据，也可以在生产库上在极短时间内连续跑两个事务代码，但后者风险较大，不推荐。第三步，收集结果集。MD01的结果可以从计划订单表（PLAF）、采购申请表（EBAN）查询；MD01N的结果同样落在这两张表，但要注意是MRP Live写入后的数据。第四步，比对重点字段：物料号、工厂、计划订单号（如果没有订单号则比MRP元素）、需求量、需求日期、供应量、供应日期、例外信息。

需要注意一个细节：MRP运行本身带有“调度”性质，第二次跑的时候会把第一次生成的计划订单删除再重建，所以比对的数据库中实际上只会保留第二次跑的结果。因此更稳妥的做法是：先用MD01跑完，导出结果；再恢复数据到跑MD01前的状态，然后用MD01N跑，导出结果；最后比对两次导出文件。

5.2 哪些字段最容易出现差异：重点核对清单

根据我的经验，以下字段在MD01与MD01N之间出现微小差异的概率最高：

• 计划订单的开始日期和结束日期。少数情况下，MRP Live对批量间隔和采购提前期的计算在微调逻辑上存在差异，但最终需求日期通常一致。
• 例外信息类型。MRP Live在某些例外信息的生成规则上做了统一处理，同样情况下可能比MD01少出或增加某条例外信息。这类情况通常不是错误，而是规则演进导致的差异。
• 采购申请是否自动转为计划订单。涉及“自动采购申请处理”参数时，两个引擎对是否生成采购申请的表决逻辑可能存在细微差别，建议按物料逐一核对。
• 舍入值、批量倍数的处理。MRP Live在批量调整上遵循标准逻辑，但如果主数据里有自定义舍入配置，需要确认自定义增强是否兼容。

如果上述字段出现差异，先对照原数据版本，再看是否涉及自定义增强。只要你的系统没有大量自定义MRP增强逻辑，绝大多数情况下比对结果都是一致的。

5.3 从比对比中得到的一个务实结论

我做过5个以上S/4HANA升级或新建项目的MD01/MD01N结果比对，总体结论是：对于标准逻辑控制下的物料，MD01N与MD01的计算结果基本等价；差异主要出现在例外信息细节和个别涉及自定义增强的物料上。因此，只要你的系统自定义逻辑不复杂，切换到MD01N不会对现有计划模式造成冲击。

真正需要担心的反而是系统之外的“人”的因素：计划员是否愿意改变使用习惯，是否理解新工具的日志和界面。这部分工作要在切换前就做足，否则技术验证通过，业务侧迟迟不切换，项目价值就体现不出来。

6. 从选型到落地：不同版本、不同工厂的迁移路径建议

最后这部分给一个偏实操层面的迁移建议，覆盖版本差异、分阶段切换和落地清单三个维度。虽然每家企业情况不同，但大的框架是通用的。

6.1 S/4HANA不同版本下的MD01N行为差异

S/4HANA的版本更新很快，从1511、1610、1709、1809、1909、2020到2021、2022等，每个版本的MRP Live能力都在增强。早期版本中不支持的一些场景（比如特定类型的替代物料、重复制造增强）在后续版本中逐步补齐。

实施时要做的第一件事就是查询当前版本对应的MRP Live支持范围说明（可在SAP Support Portal搜索“MRP Live”相关的Release Note）。很多业务场景的“不支持”其实是版本限制，换到新版本或打上对应补丁后就恢复正常了。我在一个老项目上就遇到过类似的事：客户工厂有一种物料用了个性化变式配置，升级到1909后MD01N直接拒绝处理，但打了对应Support Note的补丁后，问题就消失了。

6.2 分阶段切换：先试点、再推广、最终全量

直接一刀切把所有工厂全部切到MD01N，风险偏高，尤其是多工厂、产线复杂的企业。我更推荐分阶段切换的做法。

第一阶段，选择1~2个数据量适中、物料类型相对单一的工厂作为试点。在试点工厂跑通MD01N全盘MRP，并完成与MD01的结果比对。同时记录性能数据、异常信息数量和计划员反馈。第二阶段，根据试点结果修正后台配置、作业调度和相关培训材料，然后扩展到其余工厂。第三阶段，当所有工厂都稳定在MD01N运行一段时间后，可以通过后台作业权限控制、事务代码使用监控等方式，逐步限制MD01的日常使用，最终达到全量切换。

这个节奏的好处是，每一阶段都有明确的验证目标和回滚预案，不至于等到全部切换完才发现问题。我在项目上尤其强调第一阶段不要赶进度，因为很多隐藏问题（比如个别物料不支持、作业调度冲突）都是在试点期暴露出来的，而解决这些问题需要时间。

6.3 切换后一周内的重点检查事项

切换到MD01N之后的第一周，建议每天检查以下几项，确保过渡平稳。

第一，所有按计划生成的采购申请和计划订单是否按时出现在MD04/MD05N中。第二，异常信息数量是否在正常范围。如果切换后异常信息比原来多出很多，大概率是MRP参数或者主数据的某些设置在新引擎下被重新解释，需要逐条核查。第三，跟踪后台作业运行时长。MD01N首次运行可能因为系统需要预热缓存等原因比预期慢，但连续几天后应该逐步稳定在合理区间。第四，与采购和生产的协同情况：采购部门是否能正常处理新生成的采购申请，生产部门能否正常读取计划订单并转生产订单。

有些项目在切换后发现，因为MD01N跑得更快，计划员反而一时不适应——以前跑MRP要一个小时，隔天上班看结果；现在十分钟就出结果，当天就能看，但业务节奏还没来得及调整。这是“太快”带来的短期紊乱，通常一周左右就会自我调节到位。

6.4 关于是否保留MD01的最后建议

即使系统已经完全切换到MD01N，我也建议不要急着在权限角色里彻底删掉MD01。原因很简单：解决历史问题、排查数据差异、临时跑个别物料时，MD01依然是一个有效的备用工具。SAP本身也没有强制要求禁用MD01，即使在最新S/4HANA版本里，它仍然可以正常使用。

更好的做法是：在用户权限角色中，把计划员的MD01权限改为只读或限制到特定工厂，而把标准日常操作收敛到MD01N和配套的Fiori应用上。这样既保留了历史工具的兜底能力，又不会因为用户习惯问题导致系统退回到旧引擎上。

我自己经历过从ECC时代靠着MD01和一堆自开发Z报表做计划，到后来S/4HANA上用MD01N加Fiori应用完成同样工作，最大的感受是：工具升级的真正收益，往往不是缩短的那几十分钟运行时间，而是把计划员从“等结果、导数据、拼报表”中解放出来，让他们把精力放到异常处理和供应链协调上。MD01N是不是所有场景都完美？坦白说，不是。它也有自己的边界和坑。但从整体效率、系统资源利用和后续扩展性来看，它代表着MRP运行的明确方向。如果你所在的企业还停在MD01上犹豫，我的建议很直接：抓紧做一次验证和试点，跨出第一步，你很快就会发现这套新引擎的价值远不止于“快”这么简单。