Necessary But Not Sufficient, 2nd pass

On recommendation of a friend, I re-read Necessary But Not Sufficient by Eli Goldratt, Eli Schragenheim and Carol A. Ptak.  It's another Theory of Constraints business novel.  This time the focus is on the principals at a large software vendor (ERP systems) and their primary systems integrator.  I've heard that the story was supposed to be aimed at SAP and IBM to encourage them to adopt TOC principles.

This book contains something very valuable that I have mistakenly attributed to The Haystack Syndrome.  The rules for technology:

1. What is the power of the technology?
2. What limitation is being overcome (limited capacity, for example)?
3. What old rules were followed because of the limitation (and need to be eliminated)? 
4. What new rules need to be created?

I liked how the authors walked through the discovery and articulation of these rules with the characters.  The "limitation" is often hard enough to discover, but those "rules" that came about because of the limitation are a bear.  They quite often have nothing to do with the technology being proposed, but without acknowledging them, the limitation becomes the rules themselves and the technology (or any other change) will never see its full benefit.  I enjoyed the comment by the software engineer that many of the change requests that come from customers have to do with their desire to re-implement many of the old rules into the new software - thereby ham-stringing any hopes for benefits.

My friend recommended it because I am now working for a good-sized software company, and he thought some of the lessons here could be useful for my thinking about how our software impacts life for our customers.  We don't sell ERP, but the common justification for my products has to do with efficiency, visibility, streamlined processes, improved collaboration, etc.  Of course these things are helpful, but if you don't know which of these is connected to the bottom line, they are fairly meaningless.  And this is where I have been struggling with understanding our customers.

Happily, there are some specific examples of how our customers used our software to significantly improve things at the bottom line.  I have one story that I hope to document in more detail where a customer nearly doubled the capacity of a key manufacturing plant by optimizing a specific operation with our software.  But, in my view, that is just an example of how the software could be used.  One could just as easily use it to optimize an operation that has nothing to do with a real constraint.

So, my struggle is how to understand our customers well enough to make strong connections to value at the end of the day, not internally-allocated savings that never end up on the bottom line.  And one thing has become clear in re-reading this book and thinking about our customers: there are a lot of internal rules and ways of doing business that need to change if our software is going to have anywhere near the impact we claim it will have.  How do I get that process started?

What about the book itself?

With regard to the story in the book, I enjoyed it for what it was.  It follows the usual path.  The vendor and implementer see they have a problem meeting their forecasts.  They come upon the idea of selling bottom line value, rather than the usual justifications that their industry offers.  And they discover just how hard it is to turn "visibility" into a number that means anything to the bottom line.  Eventually, they hit upon a way to think about their software in a new way - a way that is inspired by Theory of Constraints. 

It's about this point in the book that it seems to shift from being mostly "novel" into mostly promotion of the TOC way.  While the story continued, there seemed to be far too many leaps in logic and discovery within the novel that it was very distracting for me.  (Lot's of "how did they jump from X to Y?" thoughts running through my head.)  I don't recall it being so heavy-handed the first time through, so maybe it just goes over the heads of newcomers to TOC.

If you have anything to do with software and are interested in TOC, I think this is a good book to get you thinking about how things really impact the business of your customers.  But you might stop after the halfway point, unless you are interested in seeing one view of how all the TOC pieces could come together.  Of course, the rules for technology don't show up until that second half, so maybe keep reading anyway.