Book Notes - Necessary But Not Sufficient

Necessary But Not Sufficient by Eliyahu Goldratt [2000]

Summary:
The inherent conflict in software development is adding features to keep the customers happy Vs keeping the software easy to maintain and use to keep the customers happy. This conflict can be avoided if you focus on adding value to the customer, if they are making bottom line benefits they will not be interested in adding features that do not add value.
To add value you must work out what limitation your software can overcome. Moreover you must work out what rules are in place in the company to accommodate those limitations and then replace those rules with new more suitable rules. Only once the rules that accommodated the limitation are removed will you see benefits.

Notes:
Page 60: Have the client meet the project team before the bid goes in, while it does mean you need to have excess staff it can work very well to motivate the sale. If the client can get a feel for the project team and their competence they are more likely to select that vendor.
Page 61: Companies spent a lot of time making their new tools (ERP systems etc) look like the old tools, the problem is if they looked exactly like the old system then what is the point in upgrading.
Page 114: Refer to these 5 pages for discussion on finite capacity scheduling, along with its pros and cons.
Page 124: The key to finding the where the benefit lies in a new technology is to understand what limitation it overcomes, but moreover work out what rules helped us accommodate the limitation and what we should replace them with.
Page 130: Concept of time buffers as well as material buffers. Also concept of dependant setup times (going from black to white parts in injection moulding). Even more complicated if dependant setup on two machines overlaps and causes the bottleneck to shift between them.
Page 163: To make sure clients don’t focus on stupid little details you need to offer them sufficient value that they don’t care about the little details only the bottom line benefits.
Page 175: TOC can be devastating to a system if you only introduce it to one section at a time. If you introduce it in production and sales can’t keep up you have too much capacity for no reason. If you increase sales but production can’t keep up then you annoy your customer. The same is true of all other dependant functions.
Page 176: Forecasting at a warehouse level and particularly basing Min/Max Replenishment on forecasts is an easy way to build inventory, the solution is not to have a better forecast but to be flexible enough to make product to order.
Page 183: Oral presentation of the conflict between production, distribution and sales, example of presenting a transition tree.
Page 190: Forecast accuracy for various sample sizes like central limit theorem?
Page 192: Have a pull system with each plant holding ~3 weeks (dependant on replenishment time) of inventory of everything and shipping what each warehouse sells on a daily basis. As the shipments are for all sales, not just one product, the transportation should be still be a sensible cost.
Page 198: Measure your pull in throughput dollar days both for inventory and for missed shipments.

Quotes:
Page 4: “To be paranoid you must constantly assess the impact of your actions on the global picture. Which means that first you must relentlessly search for a deep understanding of the global picture.”
Page 62: “The customer is not always right but they are always the customer.”
Page 124: “We expect that a new technology will bring benefits when and only when, the new technology surpasses an existing limitation.”
Page 224: “As long as the end customer in the supply chain didn’t buy, nobody in the supply chain has sold.”
Page 226: “Trust is nice as long as there are measurements that serve as a watchdog.”