Common notion is that a good MRP run can complete in about 3 and half hours for a big organization. But have you ever wondered about that? Just how fast could Master Planning go if it really got some performance tuning – I mean the nonstandard stuff that isn’t documented? It took years, but I got a full-blown MRP project where I could truly tweak an Enterprise MRP solution to test speed. The results are pretty amazing as time for a full run was reduced from about 4 hours to 21 minutes. I share key learnings here.

We started here with our runs:

Notice that it is about 3.5 to 4.0 hours which is average for a large enterprise..

We are currently here after some serious performance tuning. Your eyes are reading it right. 21 minutes for a full plan regeneration with 7 different BOM levels on the same 208,145 items as above.

Here are the takeaways.

First, start with the excellent MRP Performance Series on Premier Support’s Page and the MRP presentation at the technical conference.

Just following the suggestions in the 3 articles plus the Technical Conference video got me a 200% performance improvement. For most enterprises, this would have been just fine. For many of the biggest implementations, having a run time of 3 and a half hours is considered just fine. For smaller ones, they will be faster than this. This is an excellent way to get your on MRP Performance tuning advice “on the cheap”. Just follow the suggestions here and about 90% of the implementations can stop here without having to invest in heavy supply chain performance tuning expertise. For the rest of you, please continue. Be sure to put in the CU11 filter on demand enhancement by the way.

Second, unlearn what you have learned with the cache

Cache is not always good. For big organizations with large resultsets, cache will send your MRP runs to hell. Here is a classic culprit right here: the work calendar cache. The customer is right. These cache’s are fast when just a few items are added to them, but when thousands of items start to get added, they rapidly decline in speed.

Leave it to Microsoft to tell it how it is. The way I got around this was by disabling the work calendar cache manually in code – the parameter setting for minimize didn’t do anything anything. I had to go into the code and disable it. Performance quadrupled after I did that. I did the same thing with the reqtrans cache because it was another time hog. In both cases, performance really got fast. What I’m saying here is that cache can be slower than the database if there is enough of it. Organizations with lots of items can quickly overwhelm the cache algorithm and end up in a slow-down situation.

Third, lots of hidden secret parameters that you can tweak

Going through the code, I found lots of macros (aka constants) and hard coded constants. That means that somebody planned universal constants for all possible implementations. Unless their name begins “G”(OD), there is not possible way in the world, one size fits all here and that the constants would be right for everyone. There are about 30 hardcoded hidden performance tuning settings that you can change which don’t appear on the form at all. Tweaking these for my customer got me a lot of speed. Here is a good example. When scheduling production orders, Microsoft code says look for times within two calendars for up to 1000 days out before giving up. It’s hard coded right here. But wait?? How many companies need to schedule 3 years out??

I recommended to my client that they set it to two years out instead.. They got even more aggressive than that and set it to 1 year out. The final coverage results were not affected by changing it to one year, but performance increased 70%! You get the point now.

Fourth, just cause Microsoft hasn’t detected a kernel error, doesn’t mean that there is not one.

4 Kernel level errors and counting baby.. 2 of them have been there since 2009. They lead to various hiccups and hangs in memory. They tend to be easy to fix. Doing this really brought the performance up and gave me that last push to over 1000% performance gain.

Here is bad one right here. Notice an unusual amount of time of a method that simply creates a string.

So, I imported a dll and rewrote the code as a .net stringbuilder instead of a strfmt.. It now runs over 100 times faster. See below..

Thinking outside of the box brought my customer a lot of speed.

DON’T BE AFRAID TO BE CREATIVE

During the entire exercise, my client heard all kinds of things like Kernel level code, best practices actually slowing things down, tweaking algorithms ( I designed a tweak to the scheduling engine and the coverage algorithm which would speed up Master Planning by a factor of 10 but not implemented yet), and they stayed patient with me as I worked on this. Now, at the end of the day, my client will have the fastest full MRP run of any major implementation that I’ve ever seen for being patient. But what we did wasn’t that special, it just results that someone be creative and looking for ways to improve the logic.

This will end my series on MRP for now but perhaps in a future story, we’ll explore the algorithm tweaks that I came up with to really speed up MRP. You could take your Dynamics AX MRP system and put the SAP’s and other ones to shame with this sort of speed.. and believe it or not.. It can get a lot faster than what I accomplished with some changes to the algorithm that equivocate results.

Peace!!!!!!!!!!!!!!!!!! Out!!!!!! And till next time.