We have rules everywhere.


We have operating procedures (read: rules). We have policies (read: rules). Our software executes business rules against the data we supply. We have more or less formalized “rules” by which we determine safety stock levels, reorder points, order cycles, and much more.


Carol Ptak and Chad Smith, in the outstanding book DDMRP – Demand Driven Requirements Planning make two important observations about rules:


  1. Most rules are life limited. Rules are instituted most often based on assumptions about the environment at the time they [are] made. Rules are often made to accommodate certain limitations. When those assumptions or limitations change, the rules must be reexamined to determine whether they are still appropriate. Souder’s law states that “repetition does not establish validity.” Simply continuing to do something that has always been done does not define whether it is, or ever has been, the appropriate thing to do. Worse yet, the longer the repetition, the more invalid or inappropriate the rule [is likely to] be.
  2. “Optimizing” inappropriate rules is counterproductive. Attempts and investment meant to enable or accelerate compliance [with] rules that are inappropriate can be devastating to an organization. If the rule is not only inappropriate, but also damaging, then the organization is at risk to do the wrong things faster.

Tools versus Rules

If the tools we have and use are merely attempts to optimize or accelerate the enforcement and execution of rules that may be out-of-date, outmoded, or simply wrong for the current (or, actual) circumstances, then our tools will have little value to us.


Let us consider an example tool—data collection.


Data Collection and Analysis

If you are like most of our clients, you are already swimming in data. Your existing ERP system probably collects and stores millions of data points. Perhaps, it even collects and stores millions of data points every day!


It now becomes your job to sort out the relevant information from the irrelevant data that is accumulating.


But, wait!


What if some of the data you collect is incorrect, or the analysis applied is misleading?


For example, you record stock-outs. But, what if the stock-outs are being caused by bad rules (a policy constraint, for example) or by bad assumptions that feed into the business rules being applied to supply chain planning and execution?


Instead of looking for new tools and better analysis, maybe it’s your rules that need to be reassessed. In short, maybe it’s new thoughtware you need instead of new software.


What problem are we really facing?

We find that, by far, the majority of the supply chain executives, leaders and managers with whom we come into contact believe that their biggest challenge—the “problem”—they are facing is costs.


“We’ve got to reduce our costs,” they keep telling themselves. “We need to find ways to cut shipping costs, production costs, warehousing costs….” On and on goes the cost-cutting mantra.


So, they look for new tools to help them cut costs.


But, in a supply chain, the real problem to be dealt with is FLOW (not costs).


When the FLOW of relevant materials (Throughput) [1] is maximized in the supply chain, costs are automatically reduced and efficiencies [2] automatically are improved.


When the FLOW of relevant materials becomes the real problem that the supply chain executives are tackling, the two key system-wide performance metrics automatically start to improve. What are those metrics?

  1. On-time performance
  2. Return on investment


What is the real problem your supply chain (or enterprise) is facing? What tools are you using to attack this problem?


Have you considered new thoughtware before spending money on other new tools?


We would like to hear from you. Please leave your comments below, or feel free to contact us directly, if you prefer.



[1] Throughput we define as revenues less (only) truly variable costs (without allocations)
[2] The efficiency of the system (i.e., the enterprise or the supply chain) can be measured in the ratio between Throughput and Operating Expenses (T/OE). The larger this number, the better your system is performing.


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