One of the core functions of ERP is Material Requirements Planning (MRP), which aims to liberate planning, material control, customer service, and procurement from a vast amount of manual operations. However, after implementing ERP, only a few enterprises can actually run MRP effectively. In other words, production and procurement planning are still carried out in Excel. Some companies, even after enabling the MRP module, still manually input production plans; what ERP can do is merely automate the generation of procurement plans, functioning mainly as an order management and inventory in-and-out system, serving primarily to record execution.
When MRP fails to operate, some companies habitually place the blame on the system: “The ERP functionality is inadequate.” This may hold true for small ERPs focused on simple inventory management; however, it clearly does not apply to comprehensive large ERPs like SAP or Oracle. What we want to emphasize is that the failure of MRP to operate, on the surface, appears to be a system functionality issue, but it is underpinned by profound data, process, and management problems.
**Problem One: Inaccurate Bill of Materials (BOM)**
The BOM is the foundation for MRP operation: when demand is entered into the ERP system, the system checks the BOM layer by layer to determine if there is inventory; if not, it drives the supply chain to produce or procure. Thus, whether MRP can operate directly depends on the accuracy of the BOM.
In enterprises, BOM has long ceased to be just a list of materials; it has become a cross-domain and cross-professional management system, serving as core foundational data in manufacturing information systems. It spans the entire product lifecycle, involving almost all functional departments, intertwining sales, research and development, process, planning, production, procurement, warehousing, logistics, finance, after-sales, and the entire supply chain, serving as the bond connecting these links together. For BOM, the only constant is change. Amidst complex changes, it is challenging to maintain the accuracy of the BOM.
Common BOM data errors include: (1) Incorrect attributes of parts, such as drawing numbers, drawing versions, units, etc.; (2) Incorrect quantities of parts, like erroneous counts of primary or sub-components in the BOM; (3) Configuration issues, where the market configuration, engineering configuration, and production configuration do not match; (4) Procurement status, where BOM data errors arise from sourcing issues; (5) Workstation errors, where the system workspace does not correspond with the actual assembly. These are just a few examples of many BOM errors; for further details, one can refer to the online article “How to Improve BOM Accuracy,” which includes an extensive checklist and leaves one lamenting, “Any problem that can occur, will occur” with respect to BOM.
An even worse scenario is the complete absence of a BOM, or that the BOM is buried in a pile of Excel spreadsheets. This is common in enterprises with low levels of informatization, as this has been their traditional operating method. In some cases, even with an information system, the BOM is included, and the issues of BOM inaccuracy are identified, but it becomes challenging to modify it within the ERP system. For instance, changing the BOM must adhere to change processes; the larger the company, the more complex and slower these processes become, leading employees to operate outside the system, resulting in discrepancies between the “account and reality” of the BOM.
To resolve the accuracy issues of the BOM, R&D personnel cannot be overlooked. In any company, R&D teams are the busiest; although they are the main responsible parties for the BOM, focusing on developing new products, how much time can they dedicate to maintaining the BOM? Moreover, with so many products and BOMs, allocating resources to accurately maintain some while neglecting others is not acceptable. This creates a dilemma where complete resolution is unattainable, and partial fixes fail to tackle the issue.
As time goes on, the BOM becomes increasingly unreliable, ultimately evolving into a significant problem that no one can manage. An unreliable BOM is akin to a weak foundation; thus, MRP cannot function properly.
**Problem Two: Inaccurate Master Data**
The functioning of MRP logic hinges on master data such as lead times, minimum order quantities, default suppliers, etc. In poorly managed enterprises, master data is generally very incomplete. One reason for this is the absence of dedicated planning; a considerable number of local enterprises are still in the nascent stage of planning functions, primarily relying on flexible cooperation among executing departments. The separation of planning and execution is not established, leading to weaker internal demands for standardizing master data. For instance, if a production supervisor creates a production plan, they are familiar with each step on the production line, how many personnel and the respective process parameters, and they prefer storing all in their memory, rather than put them into ERP.
With master data being incomplete and inaccurate, many enterprises leap into the digital age, hoping to enforce processes and management through ERP implementation while simultaneously solving data issues, but this often leads to inefficient outcomes.
A common scenario occurs when consultants implement the ERP system. After importing all products into the system, user departments are then asked to provide corresponding production process parameters, lead times, process, capacity data, and unit costs. The enterprise suddenly realizes that because it has historically relied on manual production scheduling, those responsible for execution have also served as planners, and much of this master data has never been formally calculated. Consequently, they scramble to compile vast amounts of data quickly, resulting in low accuracy, which leads to MRP-generated plans being unexecutable.
This is the moment when true pressure triggers deeper issues, but only a handful of enterprises will persistently engage with master data, correcting one issue at a time—a path rarely taken that requires long-term commitment. On the other hand, most enterprises choose the easier route, placing the blame on the system and consultants—a common scenario where the ERP system does not contest, and once the consulting firm is paid, the discrepancies in master data remain unresolved.
This discussion pertains to production master data. Due to the involvement of numerous internal functions, resolving these discrepancies can be challenging. Many enterprises continue to use old practices, making production plans in Excel. Procurement master data, primarily related to suppliers, is relatively easier to manage, allowing MRP to run procurement plans. Some enterprises allow procurement plans to be ran via MRP, but manual production plans that get imported into ERP. However, many enterprises also struggle with supplier-related master data, as suppliers are changing continuously; parameters like lead times, purchase quantities, and packaging specifications are changing all the time, and management responsibilities for master data remain unclear, leading to untimely updates.
Even if one day the suppliers finally stabilize, master data will still face numerous challenges. For example, take procurement lead times; they cannot simply be determined based on historical orders, as some orders are placed early but require late shipping from suppliers, or as a set of orders sent on the same date but received in multiple batches, leading to inaccuracies in actual order sending and delivery dates, which in turn makes the lead times calculated from these dates unreliable. Ultimately, it comes down to asking suppliers to provide this data. The MRP system didn’t make any difference for their lead time.
The underlying reason is that “purchasing management” focuses primarily on price, quality, returns, and other so-called “key” procurement metrics, without serious agreements on service indicators like lead time and on-time delivery, it is supplier performance assessment.
Whether it’s production or procurement, the reasons for inaccurate master data are varied, but the results are similar: inaccurate master data leads to unreliable MRP results; when no one trusts the results, MRP cannot function.
**Problem Three: Inventory Discrepancies**
When running MRP, the system needs to deduct on-hand and in-transit inventory to calculate net demand. Discrepancies between inventory records and actual stock directly prevent MRP from functioning.
For instance, if product A is scanned upon arrival but product B is moved in instead; if during stocktaking product A is counted while product B’s barcode is scanned; if product A is supposed to be shipped but product B is sent instead, all these contribute to discrepancies. Products returned from the production line, engineers returning unused items, and inventory that is logged but not recorded; discrepancies will result. If packaging is supposed to be 16 bottles per box and is recorded as such, but used by disassembling the box for individual bottle shipping—recording one box as one bottle—will also lead to discrepancies.
Numerous factors contributing to inventory discrepancies—anything that could possibly happen, will happen—but fundamentally, it all boils down to meticulous operations, which is a crucial reflection of an enterprise’s overall operational level. When assessing a company’s operational level, I usually ask two questions, one of which concerns whether inventory records match with physical stock (the other is whether the system can run MRP): Accurate records do not necessarily signify a high operational level; however, a low operational level certainly results in discrepancies.
Due to many reasons, resolving inventory discrepancies is not easy. Whenever someone asks me what to do about inventory discrepancies, I often feel despair: They ask me provide a magical solution; unfortunately, in my view, there are no shortcuts to achieving accurate records unless we ensure that every necessary action is performed properly. This requires support from organization, processes, and information systems, but more importantly, it needs determination and discipline.
The more loosely managed an enterprise is, the more “flexible” its operations are, and the less they adhere to basic rules, the more exceptions arise, far exceeding what structured MRP can handle. As a result, the millions invested in ERP systems ultimately yield disappointing returns and become mere ornaments.