TOC and Software – the Search for Value

Software is both a blessing and a curse. The current huge push to Big Data, Industry 4.0, and perfect forecasting algorithms expresses the hope that software would tell us things we don’t know.  In other words, reduce the threat of uncertainty and bring back the hope for truly optimal organizational performance.

The late Eli Goldratt dedicated two of his books to the impact of software. Back in 1990 he wrote The Haystack Syndrome – showing the potential damage of overwhelming us with ocean of data.  He defined ‘information’ as an answer to a question asked, and by this put his finger on the potential value of finding answers. According to Goldratt the core damage of software is being unable to see the forest for the trees.

The other book by Goldratt Necessary but Not Sufficient (with Eli Schragenheim and Carol Ptak), written in 2000, looks into the ERP world and the necessity to clearly define how the user is going to get real value.

Software for organizations yields two obvious benefits; maintaining the database and quick calculations.  One might add managing communications as a third element. Simplicity, a basic TOC insight, implies that the logic behind the calculations is clear and agreed-upon by the users.  Goldratt called the software he developed in the late 80s “Disaster” to emphasize what would happen to the user who runs the software without understanding the logic.

Simplicity versus Sophistication is a key dilemma for software.  Simplicity brings value through better decisions and more effective actions.  Sophistication is mainly a proof of the capability of the software developers (“we can do that”) and it serves well the dream for optimal performance in complex and uncertain environments.  TOC challenges the assumption that the only way to improve an organization is through optimum performance of all resources. TOC claims that by focusing on what is truly meaningful (like a potential need of customers that is not answered today) it is possible to achieve a breakthrough that the optimization process is not aware of.

Software has another important benefit, though indirect, to offer:

Software forces the users to certain processes that follow key policies!

This capability of software is the source for many specific dilemmas around the pros and cons of every policy. The policy and its ramifications would determine whether the software, forcing that policy, is a blessing or a curse.

Software companies usually resolve the dilemma by letting the user have a wide choice of policies along their key parameters. Goldratt, on the other hand, strived to minimize the common big mistakes people do. In his juicy verbalization: “We should not give the rope to the user to hang himself.”  This fear led Goldratt to narrow the user choices of policies.  The TOC philosophy is to stick to good-enough effective policies that deal well with uncertainty.  This is the source of all the TOC policies and detailed solutions.

However, the TOC solutions do not cover all the possible situations and there are cases where a temporary deviation is necessary. This means a certain choice has to be given to the user, either by allowing the basic policies to consider certain deviations, or by letting the user bypass the software directives.  Such an action has to be infrequent and the user has to take the full responsibility for all the ramifications.

Just to illustrate the last point here is an example. Suppose a certain SKU has a target level of 1,000 units and right now there are only 999 units in the system.  Would you issue a replenishment order for one unit?  If your answer is “it depends” then you realize that a certain deviation might be required.  Goldratt himself outlined a more elaborate rule to release orders based on the planned-load, sometimes releasing the order earlier in order to keep the weakest-link constantly loaded, which deviates from the rule of chocking the release.

Generally speaking we have to judge any software based on two very different criteria:

1. The net added value the software generates in comparison to what already exists. The six questions on assessing the value of new technology is a powerful tool for that.
2.  The potential damage the software generates!

There are three different ways for the software to cause damage:

The way the software works.

• Bugs that mislead the user or causing a crash.
• Supporting the wrong procedures or the wrong algorithms.
• Letting the user make wrong decisions due to too much choice.
• Note, every single feature that does not bring value actually causes damage of confusion and potential mistakes.

The way the software has been modeled and installed.

• This is relevant for ERP, CRM and all large software packages where many critical choices and parameters have to be properly introduced into the software upon installation. TOC packages of DBR, SDBR and CCPM also require modeling and fixing certain parameters, like buffer sizes, into the software. When big mistakes are done at that stage – the amount of the damage can be HUGE!!!

Wrong use of the software by the user.

• This is the most frightening way of causing damage by software. The software and its specific installation could be excellent, but users who don’t think they need to understand the logic might generate huge damage.

TOC software packages used to be added-on modules that are linked to an existing ERP or MRP. The interface makes the installation critical.  CCPM software also used to be linked to Microsoft Project, but several newer CCPM packages are stand-alone packages.  However managing projects sometimes requires an interface to the ERP, like for the purchasing orders or for managing the budget.   When the synchronization between different packages is important then the burden on the interface, a critical part of the installation, is particularly high.

Eventually my main point is the responsibility to bring the user to fully understand the logic and the capabilities of any software. Limiting the choice of options that might be useful could create big damage.  Bypassing the software when the user does not fully understand the logic is even more dangerous.

This means that the TOC champions and consultants have to take the responsibility for the right level of knowledge at the client, including how this knowledge is preserved when new employees take over. Somehow the current S&T templates do not include the necessary educational activities to ensure ongoing training.

Sometime in the future I’d love to see a full ERP and business-intelligence software based on the TOC approach.  A key insight has to be that there is a need to combine data based on the user intuition with a rigorous numerical analysis.  I have put this kind of effort in my initiative of Decision-Support in TOC Way (DSTOC) and I think this insight should be spread all over the software industry.