Necessary is not Sufficient - book by Eliyahu Goldratt

Hello,

In the last couple of months, I have been reading works by Eliyahu Goldratt, a physicist turned into an exceptional management guru. He is most known for his invention of the concept of “Theory of Constraints” which he introduced through a fantastic novel The Goal. I was introduced to Goldratt and his works through my professor of Operations Management course at MDI, Prof. Sindhwani. I would like to thank him for doing that. I did some research about him after I got to know him and left it at that.

Recently, I came across Goldratt’s another great novel Necessary but not sufficient which is also a work based on the Theory of Constraints but with a theme of Information Systems and ERP systems in particular. This hit home because it broadly matches my interest areas. The novel revolves around a fictitious software company that sells ERP systems, around the beginning of the 21st century. It started out as a 2-people company, Scott and Lenny, the salesman and the programmer respectively which has now grown into a mature multi-national software company with thousands of employees across the world. They have had exceptional growth so far, have been an industry leader with highly re-assuring forecasts but are facing some hard problems and the novel navigates one after the other. It provides a bird’s eye view into how the decision makers, the senior management works through problems, building a short and long term strategies. While most of the strategy case studies provides this view, I think this novel does a better job simply because its an elaborate journey of a company over a prolonged timeframe navigating through different situations than a short case study that generally is focused on a particular situation. As I progressed through the book, it became clear that each chapter has a specific theme to it and particular learning that can be taken home. I felt it would not be a bad idea to summarize each chapter with its learnings here.

There are a few chapters which have solid content and themes where I have written my heart out, some where it is better to read the chapter itself.

Chapter 1: Pilot chapter & Paranoia

15 August 2025

There are a number of small, day to day actions that are performed in a company. How do these actions fit into the global picture? How do they impact the global picture? These are important questions for top management and a constant reassessment is necessary to ensure the firm is going in the right direction. The author defines this as being paranoid - to constantly assess the impact of one’s actions on the global picture. But to be able to do this, one should get a good understanding of the big picture first.

The chapter presents a unique position of the ERP software company. The Price-Earning Ratio (PE Ratio, also commonly known as the Multiplier) is very high for the company indicating that the performance expectation is also high. The company so far has grown at a phenomenal rate of 40% year on year and the market expects the growth to continue, which is why the multiplier is 100x for the company. The primary customer base of this company are the big companies going for ERPs. There are only so many of them and the market hits saturation at a point. Once you reach a certain growth point, there is simply no room to grow in the same place. The entire pie is almost eaten with you having the majority share. A firm at its inception does not have this problem, their both short and long term strategies align. But at this level, short-term strategy will mostly be chasing the forecasted growth but there needs to be a radical change in the long-term strategy.

The Ansoff Matrix is a simple framework to help navigate the situation. A firm has four options across the product-market matrix - Market Development, Market Penetration, Product Development and Diversification. The case of market saturation is one where market penetration of an existing product in an existing market has peaked and no substantial growth is going to come out of that quadrant. So the company needs to see where growth lies for the them. Ofcourse, the company can employ strategy to garner growth from more than one quadrant. Netflix for example followed Market Development when it expanded to several other geographies along with Product Development making it highly localized and personalized, followed by usual Market Penetration strategy to improve the market share. How Netflix Expanded to 190 Countries in 7 years, Netflix: International Expansion are two good cases that delve deep into Netflix’s expansion strategy. Adding to that, this book The Death of Demand: Finding Growth in a Saturated Global Economy is highly relevant to this problem.

Coming back to the chapter, it is made clear at the end of the chapter that the CEO (and the company) have been doing the same set of things that has driven growth so far, and doing more of the same things. This helps when there is a seemingly good growth path, but not when there is a massive road-block like market saturation. The same things cannot be done, there needs to be a change.

While there are themes to each chapter, the running theme of the novel is about the sustainable long term growth strategy - this essentially holds the novel together.

Chapter 2: On Product Development

The first chapter gave a company overview from a market pov, this chapter gives a view from product pov.

There is often a tug of war between the product development teams and the customer facing/sales teams. The customer facing teams unfortunately commit to a variety of customer demands which cannot be implemented with quality by the product teams. This is described with an elaborate set of examples.

As of today, there is a clear distinction between ERP product companies which build the product and consultancy companies that implement the software for customers. Implementation itself is a business function (which is different from sales and maintenance). Typically, in the early stages of an ERP product company, the implementation function generally part of the main company but with the product itself growing in size, implementation became a separate entity. Today, there are a variety of consultancy companies which implement variety of ERPs and such IT software for different customer segments. These two entities (Product Company and Implementation company) work very close together from product development to sales to maintenance. One can find a number of case studies where big consultancy and services firms like IBM, Accenture, CapeGemini partner with SAP, SalesForce and such IT software companies implementing them for a number of different customers. For example, you can find such cases implemented by IBM here.

Coming back to the novel, the firm is facing an interesting product problem. The software was simple in early stages when solutions, features, bug fixes could be added with ease. But with time, the software grows with various feature requests from customers, regular bug fixes and general product development. In such cases, the product generally becomes very hard to maintain and changes come at a very high cost. Here is what the author tells about the (assumed) CTO of the company.

He is caught between a rock and a hard place. And not just on this issue but on almost everything that he is doing. That's the nature of the monstrous system that has grown here. But he is not going to solve it now. Actually he doesn't see how to solve it at all.

This is a difficult situation to be in with respect to the product. A lot of good product companies grapple with this issue. It is generally not good to have a single monolith of a product. This is exactly what was done at my previous workplace. There was a base software on top of which features and bug fixes were committed to only relevant lineups. There were customer-specific lineups, hardware-specific lineups and so on. It did increase some overhead of keeping track of what fixes are to be commited to which lineups and so on, this is where tools and managers assisted us, but all to keep the software as lean as possible and I think it did to a certain extent. I am not sure if this problem is openly spoken about in a systematic manner, but this is a serious problem at product companies.

The plot gets more interesting as the problem is delved deeper in later chapters.

Chapter 3: The Product Problem

There are always many symptoms to a problem. It takes careful analysis and diagnosis to find the root cause. The partner consultancy firm presents a number of bad symptoms to the ERP product company - extremely poor help from technical support centers, a sharp decline in acceptances of feature requests that come from the partner firm - these despite a thorough reorganization of the technical support center and the (assumed) CTO having all the power to allow feature requests. What might be going on? What could be the issue? The product problem we got a glimpse of in the previous chapter is described in a bit more detail here.

It all boils down to the fact that the ERP software, the product has become too bloated and complex. This has serious consequences which show up as the above symptoms experience by the partner firm. Incorporating new features into a complex software system needs to be done carefully. There is a high chance many bugs can be introduced unintentionally. Adding to that, because of the complexity, finding the root-cause of the problems consume a lot of time, and at times, there are more than one root-cause to describe the same problem. Quoting the CTO,

“If we want to stay competitive we must broaden the scope our system covers. We must have more modules. And the number of modules is not the problem. It is still a manageable number, and the interfaces between them are well defined. I’m making sure of that. The problem is the numerous features each module contains. By now, many modules have become monstrous.” Decisively he says, “The features are the killer.”

Infact, there are a number of systematic studies in the software industry that discusses this very problem - as the code size and complexity increases, the number of defects and their complexities also increase (it becomes harder to find them, they have more than one root-cause and so on). Every large organization like Google, Microsoft have their own detailed studies of this problem. Here are a few over the last 4-5 decades: The use of Software Complexity Metrics in Software Maintenance in 1987, Software Fault Tolerance: A Tutorial by NASA in 2000, Use of Relative Code Churn Measures to Predict System Defect Density, Code Red: The Business Impact of Code Quality in 2022. One more relevant study is this - it is an empirical case study which attempts to measure the influence of organizational structure on software quality.

Coming back to the novel, the issue is simple: To bring back service and support within reasonable time delay, the product needs to be simplified. But to keep the clients happy and needs of the market, more features needs to be added from time to time. It is a constraint problem with harsh consequences of trade-offs on either sides. One common “solution” product teams tend to is to restructure the product code and simplify it to a large extent. But unfortunately it cannot be a permanent solution and is only a stop-gap arrangement. So is there a sustainable solution to this problem?

Chapter 4: The Market Problem

In the first chapter, the problem of market saturation was discussed in brief. In a discussion between the CEO, CTO and the head of the company’s salesforce, the problem is elaborated upon.

Once the discussion points in the direction of the current market of big companies investing in ERP systems is saturated, and that the top managers are worried that the forecasts will not be met in the upcoming couple of quarters. One obvious option is to focus on the mid-sized companies - navigate in the Market Development quadrant of the Ansoff Matrix. Even though the product is already present, selling it is not easy. The new market comes with its own challenges, and the effort and cost of sales remain the same as selling to the big companies, while the revenue generated is evidently less. So the bottom-line takes a hit. To even achieve a top-line target, the company will have to pursue larger number of mid-sized companies which will need a much larger salesforce and accompanying team. Therefore, what can be the strategy in such a case? A detailed analysis will be needed before continuing. Implementing such a radically different strategy would mean lot of changes in the company.

One solution the team has come up with is a simpler product - essentially certain product development/innovation for the existing markets that focuses on speed of implementation and ease of installation - attempting to find growth in the Product Development quadrant of the Ansoff Matrix.

SAP primarily focused on the big markets, just like the company in the novel. But it decided to enter the market of small and mid-sized businesses. This was done through new product development SAP Business One- which is smaller, modular and simpler to work with. SAP Business ByDesign. And similar to the big companies’ market, there are a number of ERP products that primarily target small and mid-sized businesses like Microsoft’s Dynamic 365, Oracle’s NetSuite, Odoo ERP and so on. It should be noted that Product Development does not mean actual product development. It can mean an acquisition and rebranding of an existing product that caters to the market segment you are trying to enter. SAP Business One is an example of that - it was a product popular in segments in the Israeli markets but post acquisition, the product got a complete makeover. It has its own leadership governing the product and all the relevant associated teams needed to make it work. One trivia is there are companies whose whole growth strategy is based on mergers and acquisitions (M&As). Cisco is one such companies which has aggressively acquired a variety of companies over the years in the fields it has decided to enter. Well, not just other fields but also to strengthen its product offerings in existing markets. Cisco has a very well defined acquisition strategy.

I am not sure what the company does later in the novel to resolve this problem, but product acquisition and rebranding is a viable option. First, the existing product is not suitable for the mid-level markets they want to target. Second, drastic modification of existing product to suit other markets is an option, but sometimes simply not viable. Third, fresh homegrown product development is always an option but it is a highly time consuming process, and the company does not have time more than a couple of quarters to an year. So acquisiton is a fair option - it helps in getting the product ready early. But the problem with sales and marketing costs and efforts still remains. It might need more than just expanding the salesforce.

Chapter 5: How does it translate to bottom-line?

16 August 2025

ERP implementation in a company generally happens only when there is an absolute necessity. The company goes through phases and only when it reaches a certain level of maturity, the top management decides to go for an ERP implementation. Until then, companies work without ERP systems, or implement business function-specific systems based on their needs and so on. Two case studies that helped me get a perspective on ERP implementation as a strategic decision are Ozark Feed and Ag Corporation: The ERP Decision and Surviving SAP Implementation at a Hospital. The first deals with fundamental ideas like what an ERP is, when does a company even decide to pursue an ERP implementation, overall view of the ERP market. The second revolves around actual implementation and change management.

Why a company decides to go for an ERP implementation is always interesting. It is a general fact that ERP systems streamlines operations and dataflow, connects the business functions together, and ERPs today have excellent analytics and predictive capabilities that help companies. Despite this, companies at their inception don’t care about ERP systems. The adoption of Information Systems in a company is generally an incremental process, which is done on a need-basis. For example, if you are running a small manufacturing firm with a small plant with 10 employees, Microsoft Excel might be sufficient to manage operations and get insights. But with time the firm grows and you have a large manufacturing plant with hundreds of employees working on the shop floor, you may not be able to manage with Excel. This points to the fact that the firm has reached a certain level of complexity and there is a need for a certain IT system to manage it. You decide to go for a Manufacturing Execution System (MES) to manage the production plant. A few years later, you decide to open plants in a number of locations inside your home country and outsource some of it to other countries. Now the firm operations is much more complex and you decide to go for a proper Supply Chain Management (SCM) system to manage it. At the same time to manage your sales and marketing, you have a Customer Relationship Management (CRM) software to work with it. And there is some glue software between the SCM and CRM software connecting production, supply-chain and sales. Operations again become complex enough and to ease the situation, you finally decide to go for a full-blown ERP implementation which essentially has modules for all business functions and puts everything together. While it has its advantages, the entire ERP lifecycle can be an extremely costly affair for the company adopting it. The questions are “What is the impact? On Operations? On the bottom-line? How is the impact measured?” and so on. This chapter revolves around these questions in the ERP context.

When convincing the stakeholders for an ERP implementation, the management definitely will have a number of subjective reasons (strong ones) and maybe at times certain objective/numerical data defending the implementation. Some very obvious reasons being ease and streamlining of operations across business functions, better data availability, all the data in one place helps in better analytics, forecasting and so on. But what about the exact impact on bottom-line? The bottom-line will take a definite hit given the hefty implementation cost irrespective of a successful or a failed implementation (read about lidl’s ERP system failure). What is the ERP system bringing back to the table in pure money terms is an interesting question. How hard/easy is it to conduct one? What are the challenges of such a study? This is the direct theme of this particular chapter.

To make this clear, let us go over a simple isolated example inspired from this chapter. Say the accounting department in your company has 500 employees. Prior to the ERP system, it used to take about 6-7 weeks to get the finanicial report of the quarter once its over. But with the ERP system, the report is available within 2 weeks, along with a lot of automation and help coming from the ERP system. So it is evident there is a clear benefit here, but can one quantify the benefit in terms of money? In this very specific isolated example, is there even a benefit? Even though the ERP system automates quite a bit of tasks, there are still 500 employees and on top of that the cost of the accounting module in the ERP system. One can provide a number of such examples where impact on the bottom-line is hard to measure or it has probably had a negative impact (probably in an isolated setting).

One neat example describing the exact impact on the bottom-line is the streamlining of production and sales numbers - between production plants and sales. With numbers, one can have forecasts of how much to be produced in each plant and how much to be transported to each sales region from each plant. Without all this data put together, it is possible that there are mismatches in the production plant numbers and the sales regions it supplies to, maybe a product is underproduced leading to loss in sales and possible high transport costs (because products needs to be brought in from far away plants), or they are overproduced leading to high inventory costs and possible loss of product. All these can be clearly quantified. Assuming the company had these numbers prior ERP implementation, one can clearly present and before and after study. But note that this can be done only after the implementation, measuring the impact prior implementation is still hard.

While the ERP context is very interesting and is something to be delved deeper into, there is a more general context the chapter runs on (independent of the ERP theme). It is about the type of languages different stakeholders speak. The shareholders, top management and possibly the board of directors are concerned about the finances and the bottom-line, a purely financial language. They generally do not care about the ERP system you are using or if you are even using one - what matters is the financial performance of the company. The bottom-level of the company - be it the technical side of a technology company or the production team at a plant, their talk is in the technical language. For example, the technical team speaks the language of computer systems, data, analytics and so on. Whereas the middle management who oversee the operations (of any business function) speak the language of productivity, lead-time reduction, cost-reduction, efficiency and so on, its the language of Key Performance Indicators (KPIs) to be precise. The way I see it, each rung of the organization (bottom, middle and top) have their own languages and the translation between any two is not easy/trivial. I believe this is where management accounting and controlling comes in. It seems to be the formal language that stitches all the three languages together.

The heart of the problem is that managers are not able to come up with a sound financial model for their IT investments. The costs are transparent, but the expected returns in terms of the bottom-line is not clear. Two relevant resources which delve deeper into this topic are a case study Realizing the Business Value of Information Technology Investments: An Organizational Process and the book The IT Payoff. Both resources are old but relevant.

I personally realize how important thinking in terms of bottom-line is. Especially if you are selling a product to another company, understanding how the product impacts the bottom-line has a great impact on the sale.

Chapter 6: A Day in the life of a CEO

I think this chapter is about the day-to-day life of a CEO of a company, here its a ERP implementation firm (like SAP consultancy firms who implement SAP for customers). The chapter mainly gives an overview into the tactical/day-to-day problems that the CEO encounters. It is unique in a way because the discussion generally revolves around vision-mission-strategy when its about top management but here its about tactical matters. Along with that, it presents their line of thought on a variety of other matters like hiring, on customers and so on which act as their guiding principles - these are more like words of wisdom from seniors, through experience and intuition from the author himself which may or may not apply based on the situation. And the entire chapter is sprinkled with it. I will try my best to list/discuss them here but I think just reading the chapter is better.

As discussed, the main theme is about tactical items the CEO/top management engage in. There are a number of interesting articles on what CEOs actually do, how they tend to tactical matters, on their time management and many such relevant articles.

In this chapter, the discussion is about the CEP of a SAP Consultancy-like company (where their core business runs on implementation of ERP software for customers - essentially managing the entire ERP lifecycle for customers). Project Management forms the core operations of such a firm - a number of implementation projects being managed for a bunch of customers.To get an overview of what a typical SAP Project Manager does, you may read this chapter which describes a day in the life of an SAP Project Manager. Infact, the internet is full of books, resources, cases on SAP Consultants and Managers. This article/short case discusses how an interim Project Management Office (PMO) successfully completed migration from SAP R3 to SAP S/4HANA for a customer. Because of this, Project Management plays a central role in such firms. And hiring/assigning the right project manager for the right customer/project is a make or break decision. Coming to the hiring/assignment of Project Managers, they play a key role in the success of these firms. This is a good study I came across about the different types of people who can be hired as project managers and who can be the best fit. The particular problem the CEO faces here is called “Project Manager Shuffle”, essentially working out the hiring/assignments of Project Managers among the projects. The CEO faces a very specific problem of one of Project Managers jumping ship to another company leaving a critical project astray weeks before go-live. There is a strong correlation between leadership departure and project failure, and therefore this needed to be handled carefully.

Top managers develop a number of intuitions over their experience which can act as informal guiding principles. In this case, the CEO prefers experienced project management hires to college freshers. Or that candidates either have an internal drive or not and it is often binary in nature and one should hire the ones with drive. Being paranoid, constantly focusing on the big picture and mapping actions and its impact ot the big picture is essential. Or the rule “the customers are not always right, but they are always the customers” that runs contrary to the usual saying that customers are always right, along with a number of such intuitions.

I think the takeaway of this chapter is that top managers do quite a bit of tactical work along with thinking long term and we got a glimpse of the same in this chapter.

Chapter 7: Deeper view into the market and product problem

To be continued.