Skip navigation
2018

Gee Whiz 2 ROI

February 2018 Previous month Next month

Here’s one of the things I don’t understand about why supply chain managers and executives are stuck in a rut using traditional planning methods. By “traditional methods,” I mean traditional MRP (material requirements planning), MRP II, DRP (distribution requirements planning), and most methods employed by the bulk of ERP (enterprise resource planning) systems today.Stuck in a Rut?

 

Why do they pay their planners to plan using these tools, and then, when the plans don’t work out in their real world, they pay these same folk—or other folks in addition to the planners—to expedite and fire fight.

 

Oh! And “when the plans don’t work out in their real world” is almost every day!

 

Here’s why

Here’s the reason I don’t understand.

 

While management is paying the planners to plan, they already know—with considerable certainty—that the plans will not be effective in the real world of actual demand. They already know that there will be lots of consternation, aggravation, (likely) shouting, firefighting and expediting to try to get things back in line with actual demand.

 

So, after the planners have planned…

So, after the planners have planned logistics, the production, the purchasing—the whole big deal—with quantities and dates and times and all the details, the expeditors are called in.

 

Whether “the expeditors” are, in fact, the same people, who have now left off planning and have begun to face their reality, or if they are actually a different group of folks altogether, in most organizations it’s the expeditors that have the real power!

They are authorized to spend money left and right on overtime, expedited shipping charges, or surcharges from suppliers for “rush orders.” They have authority to break setups and destroy the “efficiencies” that other have meticulously calculated into batch sizes.

 

The people doing the firefighting and expediting have the real support of top management. The C-suite recognizes that—despite what the fancy and costly planning systems told them—the real money is made by PROTECTING FLOW, and that’s precisely what an expeditor’s job entails.

 

What expeditors really do

We can condense into one sentence what expeditors really do:

 

Expeditors PROTECT FLOW by uncovering which time buffers, capacity buffers and stock buffers in the supply chain are most likely to FAIL to protect flow due to their current state relative to ACTUAL (not forecast) DEMAND.

 

They then attempt to direct the appropriately prioritized actions to restore the time buffers, capacity buffers and stock buffers to a state where these buffers are more likely to support and protect FLOW in light of actual demand.

 

Compare this to Demand Driven MRP

Implementing DDMRP merely cuts out the failing step above—the one with the plans that don’t work in reality.

 

The DDMRP approach, after configuration and implementation, takes over what your expeditors are doing now.

 

DDMRP automatically reveals which time, capacity and stock buffers are most likely to be at risk of failure to PROTECT FLOW in your supply chain. Priorities for actions are easy to set, because the signals are unambiguous. A simple signal of a color and a numeric value combine to tell every participant where that buffer’s priority falls relative to other buffer signals.

 

Why not put your money into a system that works the way you really work anyway. Let an automated DDMRP solution turn your failing two-step (planning to fail and then expediting) into a one-step success program.

 

Still doing the two-step?

Are you still doing the “failure then expedite” two-step?

 

Let us know. Leave your comments here, or feel free to contact us directly, if you prefer.

 

 

Follow us on Twitter: @RKLeSolutions and @RDCushing
LIKE us on Facebook: RKL eSolutions and GeeWhiz2ROI

For readers who are not Trekkies, we will let you in on the mystery. According to Wikipedia:

 

The Kobayashi Maru is a training exercise in the fictional Star Trek universe designed to test the character of Starfleet Academy cadets in a no-win scenario. The Kobayashi Maru test was first depicted in the opening scene of the film Star Trek II: The Wrath of Khan and also appears in the 2009 film Star Trek. Screenwriter Jack B. Sowards is credited with inventing the test. The test's name is occasionally used among Star Trek fans or those familiar with the series to describe a no-win scenario, a test of one's character or a solution that involves redefining the problem.

Captain Kirk - I don't believe in no-win situations

 

Two separate incidents brought the Kobayashi Maru test to mind for me recently.

 

First, a brief article from Wired magazine about hacking. Here is the opening portion of the article:

 

Virgil Griffith discovered the allure of hacking in 1993, while slumped at an Intel 80386 in Tuscaloosa, Alabama. He was 10, and he was on a losing streak at Star Wars: X-Wing. To hit the leaderboard, he'd need a fleet of ace wingmen, but he only had one X-Wing fighter that could hold its own in the game's World War I-style dogfights…. Digging around in the game's code, Griffith found that each pilot had its own file, so he cloned his good fighter. Copy and paste, copy and paste--fully 20 times. This gave him… "a plentiful supply of the best wingmen from then on." Players without Griffith's workaround were out of luck.

 

Those brave pilots, gouged from the game's code, seemed to serve as Griffith's guardian angels in the next few years, during which he lived by the hacker's creed: Enlightened cheating is the highest form of gameplay. You don't beat the TIE fighters. You beat the game itself.

 

[Heffernan, Virginia. "Twilight of the Hackers." Wired, February 2018, 13-16]

 

For me, the key is found in the last sentence: “You don’t beat the TIE fighters. You beat the game itself.”

 

The second was a conversation I had with Chad Smith, co-founder of Demand Driven Institute, along with Carol Ptak. The question that I (and others) had raised was, “How did Smith and Ptak settle on calling this new supply chain approach ‘DDMRP,’ since it acts almost nothing like traditional (Joe Orlicky-style) MRP?”

 

Chad Smith’s response was both enlightening and fascinating.

 

Unlike some might think, Smith told me, choosing the name ‘DDMRP’ “was not an opportunistic marketing ploy.” If you understand the literal of ‘MRP,’—i.e., Material Requirements Planning—then you can also see that using MRP here isn’t at all misleading, Smith suggests.

 

“The last thing in the world I ever expected to be a part of was something with the ‘MRP’ name attached to it,” Smith flatly tells me. When Carol [Ptak] and I decided on ‘Demand Driven MRP,’ we looked each other in the eye and said, ‘Do we really want to do that?’ The answer was, ‘well, that is what it is.’”

 

“We recognize that probably the last thing the world needed was ‘another version of MRP,’ Smith adds. “But, we felt it was important to be true to what we were actually doing.”

 

“The basic nature of MRP,” Smith further explains, “is to perform a calculation of dependencies… based on three basic inputs: 1) a source of demand, 2) a product structure file, and 3) inventory records. DDMRP has these same requirements.”

 

Hacking the system

So, how does all this tie together?

 

Here’s what I see. See if you agree.

 

Right now it is likely that hundreds of thousands of supply chain managers and executives around the world are trying to “win” at supply chain management using the traditional MRP “game” code. And, they are probably taking more losses (i.e., fewer wins) than they’d like.

 

What they would really like to do is “win” more rounds, like hacker Virgil Griffith in the article from Wired above. But, the MRP “code”—logic—isn’t letting them win. In fact, more and more, it’s seeming a lot like a no-win scenario. They are facing their own Kobayashi Maru no-win challenge.

 

What Ptak and Smith saw was the same thing that Captain Kirk and Virgil Griffith saw: If supply chain managers must continue to play the MRP game using the logic that exists in the native “code,” they will seldom win—and likely never win big!

 

So, Ptak and Smith, in developing DDMRP decided to “hack the code.”

 

DDMRP still MRP. It still does material requirements planning. It just does it differently—and better.

 

DDMRP “hacks” that old MRP code and give you and your supply chain management team a chance to “win” much more often and, even, an opportunity to win big in a conscientiously applied program that fully exercises the DDMRP and DDOM (Demand Driven Operating Model) principles and best practices.

 

Join the “hackers.” Win where other are struggling to win. It’s about time.

 

You’ve played alongside the other also-rans long enough. Break away from the pack with DDMRP.

 

We can help. Feel free to contact us directly, or leave your comment below. We would be delighted to hear from you.

 

---------------------------------------------------------

Picture credit: www.YouTube.com

 

Follow us on Twitter: @RKLeSolutions and @RDCushing
LIKE us on Facebook: RKL eSolutions and GeeWhiz2ROI