Executive Summary

  • As part of a partnership, we also offer an external MRP optimizer that can replace the MRP functionality within any ERP system.
  • This can allow for a fast improvement for companies looking to improve MRP.

Introduction

The concept of the Brightwork MRP Ninja, as proposed by Denis Myagkov, is that MRP systems cannot be implemented without adjustment to the client. Therefore we do not provide a generic MRP engine, but rather one that is based upon the priorities of the specific company.

The MRP Ninja Case Study

At one particular FMCG manufacturer, a make to order model was followed. In make to order, the purchase order for inbound materials comes after the sales order is received. During the implementation of SAP ERP, it becomes obvious enough that standard functionality will not fit requirements and contradicts to scope that was sold to the customer.

This company assumed immediate confirmation of incoming orders when the sales manager has to be able to confirm the exact order specification with the exact nearest delivery date. This was viewed as too stringent of a requirement by the consulting firm, but all attempts of the consulting firm to persuade the customer to change the business requirements didn’t succeed. The core problem the company faced was the absence of functionality that could answer how many of product A could be produced in the future. The standard approach was to follow the following path:

  • Create Sales Order → Run MRP → Capacity Planning for PP Order → Run MRP for Components

To execute these steps, each sales manager required up to 30-40 minutes. It also had the negative consequence that it required the constant involvement of plant managers to perform capacity planning. After every phone call, a sales manager was not able to take the next phone call until all MRP runs were complete. Therefore, during the day the manager was able to handle only 15-16 phone calls, and due to the low number of calls per manager versus the total number of calls necessary to meet demand, the company did not have enough managers to handle the capacity

Accessing Scalable and Specialized Hardware Resources

Because AWS was used, it meant the solution could be easily scaled. This means that as much capacity as was necessary could be allocated against the processing. And that furthermore, the most appropriate type of processing capacity could be applied against the MRP run. That is versus using the ERP hardware at the on-premises location that was primarily sized for transaction processing rather than for MRP processing.

The performance improvements naturally expected to be good, and they ended up being quite impressive and allowed the MRP processing time meet the customer requirements.

  • Overall, the response time was reduced from 30-40 minutes to a matter seconds. (Which should tell us something about how efficiently MRP was being processed in SAP.)
  • The average data latency was between 200-230 milliseconds.
  • Denis Myagkov developed the MRP logic. It was also not standard MRP logic or anything like the MRP logic that is in SAP ERP. Denis was (and is) of the view that MRP logic needs to be customized per client. An identical MRP logic will nearly always need adjustments to meet customer requirements. Interestingly, almost all MRP run from in SAP ERP uses SAP’s standard logic without any adjustment.

The Business Outcome

Salespeople accessed SAP with a custom web application that provided maximum possible production capacity for products two weeks out from the order request date. In this way, the manager was able to confirm this to the customer with only the smallest time lag, and then to update the quantity from the customer in the application’s web interface.

The MRP Ninja’s Processing Sequence

Right after manager updated quantity in web application it automatically triggered the following sequence:

  1. Creation of Sales Order in SAP ERP via RFC (remote function call).
  2. Recalculation of maximum values for every subject material (standard components or capacity) with database updates. The calculation problem was represented as a quite simple system of linear inequalities with a maximization problem.
  3. During all calculations process, all materials were marked with ‘lock’ status using AMQ.
  4. To operate with the actual data from SAP system like material consumption or replenishments, on ERP side implemented user extensions in specific processes that notified remote server via RFC.

Go to top

Conclusion

The MRP Ninja was able to be free of the limitations of SAP ERP. SAP ERP could never have met the customer requirements laid out in this case study. This is true of either the business logic of the performance requirements. With the MRP Ninja, the performance was greatly enhanced, and the MRP logic was customized to the needs.

The nice thing about the solution is that it can be connected to any SAP ERP system, and SAP customers usually have MRP that has both poor performance characteristics and is not customized for specific requirements of different manufacturing environments.

We will not get into the detail of the MRP Ninja approach for the MRP logic other to say that it is based on Kolmogorov–Zurbenko, where the model is applied to every new event arranged in FIFO order. Using it requires going heavy on compute resources. But by doing so, it enabled the MRP Ninja to meet the customer requirement for near-immediate response time for the user. Events also trigger MRP Ninja.

Another problem was related to concurrency. That is, while the first sales manager would run through all of their steps, the second manager was not able to start their MRP routine. This was due to shared raw materials and plant capacity. Therefore the response time to every incoming client’s call dramatically increased, which lead to customers being put on hold, and which further resulted in several of them turning to competitors to have their orders fulfilled.

The bottleneck was a combination of the MRP runtime, along with improved capacity planning.  The company needed an MRP solution that had a maximum possible yield for every product for a given time horizon. Taking into account that in standard ERP, we had nothing to offer and that ERP in SAP was quite cumbersome both in terms of the software design and limited to the on-premises hardware.

Getting the Data from SAP to AWS and Back

The integration between SAP and AWS was performed with the Brisk Data Pipeline. This is important because SAP is generally known as the most difficult vendor in which to integrate. Moreover, using SAP standard integration tools like SAP PI/PO are expensive and troublesome to use. Furthermore, while SAP has been pushing customers to the SAP Cloud and the SAP Cloud Platform Integration add-on component (which is part of the Custom App Professional Edition, which runs between $4600 and $15,000 per month), there is little evidence of this component being used on SAP projects. And secondly, the overall SAP Cloud is a liability. The problem with all of SAP’s integration solutions is the bottleneck is the server, and it is more logical to access AWS servers rather than rely upon SAP servers. This provides far better scaling, pipeline optimization as well as data reuse.

Prototyping the MRP Ninja Versus the Current State

MRP Ninja pulls MRP outside of ERP and makes it much better and customized. We can run prototypes quickly because we can get the data in and out of SAP quickly. But of course, as with all things like this, the time goes into comparing the new results versus the old. And that means running KPIs on the previous stocking position and predicted service level and comparing it to the new output provided by the MRP Ninja.