The Company Inside the Machine

In the summer of 1999 the Hershey Foods Corporation, America’s largest chocolate maker, switched on a new set of computer systems. They included enterprise resource planning software from SAP to handle orders, finance and purchasing, customer relationship software from Siebel, and supply chain planning from Manugistics, together costing about $112 million. The project had been planned to go live in April. It slipped to July, the start of the season when retailers place their orders for Halloween. Within weeks, orders were going unfilled. The chocolate was in Hershey’s warehouses, but the systems could not reliably get it onto trucks to the right stores. The company reported that it had been unable to deliver an estimated $100 million of orders, and its quarterly profits fell sharply.¹

Hershey’s software was not unusual. Thousands of companies installed similar systems in the late 1990s, and most eventually worked. What made Hershey’s case famous was that it showed, in a single season, what was at stake. Enterprise systems are not tools that a company uses on the side. They become the company’s nervous system: the place where orders are taken, stock is counted, money is recorded and decisions are made. When they fail, the company cannot function. And when they work, they shape how the company works, because the software embodies a view of how each task should be done.

This essay follows how enterprise software came to occupy that position. It is a story about integration, standardisation and the promise of “best practice,” and about projects that failed at enormous cost. Its deeper subject is the relationship between organisations and the systems that run them: who adapts to whom, what is lost when knowledge is written into code, and what happens when an institution trusts its system more than its people. To understand it, we need to start with the idea that every job has one best way.

The one best way

In 1911 the American engineer Frederick Winslow Taylor published The Principles of Scientific Management. Taylor argued that work in factories was done inefficiently because each worker followed traditional methods learned by rule of thumb. Management should study each task scientifically, timing and measuring its parts, determine the one best way to perform it, and then train workers to follow that method precisely. Planning should be separated from doing: managers would design the work and workers would execute it.

Taylor’s ideas were controversial from the start, criticised for treating workers as machines, but they shaped twentieth-century management. They established the principle that processes can be designed, standardised and imposed from above, and that knowledge held in workers’ heads should be captured in written procedures. Enterprise software would later carry that principle into code.

Computers learn to plan

Businesses adopted computers in the 1950s for accounting, payroll and billing, tasks that involved large volumes of routine calculation. In the 1960s manufacturers began to use them for planning. Making a product such as a tractor required thousands of parts, each needed at a particular time, in quantities that depended on the production plan. Engineers at IBM and manufacturing companies developed material requirements planning (MRP), which calculated from a production schedule and a bill of materials which parts to order and when. In 1975 Joseph Orlicky, an IBM engineer, published Material Requirements Planning, which popularised the method.² In the 1980s MRP grew into manufacturing resource planning, known as MRP II, which added capacity planning, scheduling and links to finance.

These systems ran on mainframes, usually in overnight batches, and were often custom-built or heavily modified for each company. Different departments had different systems, which did not share data easily. Sales, manufacturing and accounting each kept their own records, and reconciling them took clerks, spreadsheets and time.

SAP and standard software

In 1972 five engineers who had worked for IBM in Germany, Dietmar Hopp, Hasso Plattner, Claus Wellenreuther, Klaus Tschira and Hans-Werner Hector, left to found a company that became SAP. While working as IBM consultants, they had noticed that the programs they wrote for different companies did similar things. Their idea was to write standard business software that many companies could use, configured to their needs rather than written from scratch, and that processed data in real time, as transactions occurred, rather than in overnight batches. Their first customer was the German subsidiary of the British chemical company ICI.³

SAP’s first product handled financial accounting. In 1979 it released R/2, which ran on mainframes and integrated accounting with purchasing, inventory and production. The central idea was integration: a single database, so that when a salesperson entered an order, the system immediately updated inventory, production plans and accounts receivable. There would be one version of the truth.

In 1987 SAP began building R/3 for client-server computing, networks of smaller computers that were replacing mainframes in many companies, and released it in 1992. R/3 was modular, covering finance, controlling, sales and distribution, materials management, production planning and human resources, and it could be configured through thousands of settings rather than reprogrammed. It became the dominant enterprise system of the 1990s. Competitors such as Oracle, PeopleSoft, Baan and J.D. Edwards offered similar systems, and the industry analyst firm Gartner and others popularised the name for the category: enterprise resource planning, or ERP.

Re-engineering and the year 2000

Two forces turned ERP from a product into a movement. The first was business process re-engineering. In 1990 Michael Hammer, a former professor of computer science at MIT, published an article in the Harvard Business Review titled “Reengineering Work: Don’t Automate, Obliterate.” He argued that companies had used computers to speed up old, inefficient processes, and should instead redesign their processes from scratch around what technology made possible. His 1993 book with James Champy, Reengineering the Corporation, became a bestseller. Re-engineering projects swept through large companies, and ERP systems, which embodied integrated processes, became one of their main vehicles. Consulting firms built large practices implementing them.

The second force was the year 2000 problem. Many older systems stored years as two digits and could fail when the date rolled over to 2000. Replacing many old systems with a single new ERP system that handled dates correctly solved the problem and modernised the company at the same stroke. In the late 1990s thousands of companies, under deadline pressure, bought and installed ERP systems.

The software as a template

An ERP system promised more than integration. Its vendors described the processes built into it as best practice: the accumulated experience of many companies about how to handle orders, purchasing, accounting and production. A company implementing the system could configure it, choosing among options, but the underlying structure of data and processes was set by the software. Companies were encouraged to adopt the standard processes, “going vanilla,” rather than modifying the software, because modifications were expensive to build, made upgrades difficult and undermined the benefits of standardisation.

In 1998 Thomas Davenport, a management scholar, published an influential article in the Harvard Business Review titled “Putting the Enterprise into the Enterprise System.” He argued that an enterprise system imposes its own logic on a company’s strategy, organisation and culture. It pushes a company towards generic processes even when customised processes might be a source of competitive advantage, and it centralises information and control. Companies that installed such systems without thinking through these effects, he warned, could find that the system had redesigned the business for them.⁴

That was the central tension of enterprise software. Standard processes brought efficiency, consistency and the ability to compare and control. But a company’s distinctive way of doing things might be why it succeeded, and that way of doing things might not fit the software.

When projects fail

The history of ERP is marked by famous failures, each with its own causes and a common pattern.

FoxMeyer Drug, one of the largest pharmaceutical distributors in the United States, with annual revenue of about $5 billion, licensed SAP R/3 in 1993 and at the same time commissioned a highly automated warehouse. The company operated on thin margins and handled very large volumes of orders, and it bid for new contracts expecting savings from the systems. The projects ran late, the systems had difficulty with the volume of transactions, and the warehouse automation had problems of its own. In 1996 FoxMeyer filed for bankruptcy. Its bankruptcy trustee later sued SAP and the consulting firm that implemented the system, Andersen Consulting, for hundreds of millions of dollars each; both denied responsibility and described the company’s problems as the result of its own business decisions.⁵ Many analysts concluded that the company had taken on too much risk at once.

Hershey’s failure in 1999 was a failure of timing more than technology. The company compressed the implementation, switched several systems on simultaneously in a “big bang” rather than in phases, did not have time to test some parts fully, and went live at the start of its busiest season.

In 2004 the US Air Force began the Expeditionary Combat Support System (ECSS), intended to replace hundreds of legacy logistics systems with a single integrated system based on commercial ERP software. By November 2012, after spending about $1.03 billion, the Air Force cancelled it, concluding that finishing would cost about another $1.1 billion and deliver only about a quarter of the original scope. Reviews pointed to the attempt to change processes, organisation and technology at once, weak governance and extensive customisation.⁶

Lidl, the German discount supermarket chain, began a project in 2011 to replace its own inventory management system with a SAP retail system. One reported difficulty was that Lidl had long valued its inventory at the prices it paid, while the SAP standard was built around retail prices, so adapting the software to Lidl’s practice required extensive changes. In 2018, after about seven years and a reported €500 million, Lidl stopped the project and returned to developing its own system.⁷

The failures share features that research on large projects has documented repeatedly: underestimated complexity, simultaneous changes to technology and organisation, customisation that undermined the standard software, inadequate testing, big-bang cutovers and difficulty stopping projects that were going badly. Many successful implementations shared the same risks and survived them. The difference was often whether the organisation could absorb problems when they came.

The computer is always right

The most serious failure of an enterprise system in recent decades was not an implementation failure but a failure of trust.

In 1999 the British Post Office began rolling out Horizon, an accounting and transaction system built by the computer company ICL, later part of Fujitsu, to its network of branches, many of them run by self-employed sub-postmasters. Sub-postmasters were contractually responsible for any shortfalls in their branch accounts. Soon after Horizon was introduced, some reported unexplained shortfalls, sometimes of thousands of pounds, which they could not account for. The Post Office, which had the power to bring private prosecutions, treated the shortfalls as evidence of theft or false accounting. Between 1999 and 2015 more than 900 sub-postmasters were prosecuted; many were convicted, imprisoned or bankrupted, and many more paid shortfalls out of their own money.⁸

English law at the time made such prosecutions easier. A statutory requirement that evidence from computers be shown to be reliable before it could be used in criminal cases had been repealed in 1999, on the recommendation of the Law Commission, leaving a common-law presumption that computers were working correctly unless there was evidence to the contrary. In practice, defendants could not show that the system was faulty without access to information that the Post Office and Fujitsu held.

A group of sub-postmasters led by Alan Bates brought a civil claim against the Post Office. In December 2019 Mr Justice Fraser, in a judgment on the Horizon issues, found that Horizon had contained bugs, errors and defects that could and did cause shortfalls in branch accounts, and that the Post Office had known of some of them. The case was settled for about £58 million, most of which went in legal costs. Convictions began to be overturned on appeal in 2020 and 2021, and in 2024, after a television drama brought the case to wide public attention, Parliament passed the Post Office (Horizon System) Offences Act, quashing the convictions of hundreds of people en masse. A public inquiry, chaired by Sir Wyn Williams, began publishing its final report in 2025, documenting the suffering of those affected, including people who had contemplated or attempted suicide.

The Horizon scandal is not a typical story of enterprise software, but it is the extreme case of a general pattern: an institution that came to treat its system’s output as fact and the testimony of people who contradicted it as suspect. The essay on spreadsheets describes the same pattern on a smaller scale, in models whose numbers were trusted because they came from a grid.

Consolidation, the cloud and S/4HANA

In the 2000s the enterprise software market consolidated. Oracle bought PeopleSoft in 2005 and Siebel in 2006, and many others; SAP bought Business Objects and later several cloud companies. A new generation of vendors, described in the essay on subscription software, built enterprise applications for the cloud: Salesforce for customer relationships, NetSuite for mid-sized companies’ finance, and Workday for human resources and finance at large enterprises.

SAP’s response was S/4HANA, released in 2015, a rebuilt ERP system running on SAP’s HANA in-memory database, available both on customers’ own servers and, increasingly, as a cloud service. SAP set a date for the end of mainstream maintenance of its older system, ECC: the end of 2027, with extended maintenance available until 2030.⁹ Tens of thousands of companies, many of whose ECC systems were heavily customised, faced migration projects of the kind that had produced the failures of the 1990s. SAP’s cloud revenue grew rapidly; in 2025 it reported total revenue of €36.8 billion, with cloud revenue of €21 billion, up 23 percent.¹⁰

The most recent change is the addition of artificial intelligence. Vendors are embedding AI assistants and agents in enterprise systems to answer questions about the business, draft documents, reconcile accounts and, increasingly, take actions such as placing orders or approving invoices. The essay on large language models describes the strengths and failure modes of such systems. Inside an ERP system, an agent’s errors become transactions.

What enterprise software is today

Enterprise software today is the operating core of most large organisations. It records their transactions, enforces their controls, produces their financial statements and holds much of what they know about their customers, suppliers and employees. It is integrated, standardised and, increasingly, delivered from the cloud. It embodies a set of assumptions about how businesses work, which organisations adopt, adapt or fight. And replacing it remains among the most expensive and risky things a company can do.

How enterprise software changed organisations

Several shifts follow from the spread of enterprise systems.

From departments to processes

Before ERP, a company was a set of departments with their own records. Integrated systems made the company a set of processes running across departments, from order to cash, from procurement to payment. Organisational charts began to be redrawn around those processes.

From local judgement to configured rules

Decisions that had been made by clerks and managers using their judgement, such as whether to extend credit or approve a purchase, became rules configured in the system. Consistency and control rose. So did rigidity.

From many truths to one

A single database promised one version of the truth. That made the company more visible to its leaders and easier to audit. It also concentrated authority in whoever controlled the data and its definitions.

From custom to standard

Companies that had built their own systems around their own practices adopted processes designed by vendors for many companies. Much of the variety in how companies worked was standardised away, for better and worse.

From people to systems as the record

The system became the official record of what had happened. When people and records disagreed, the record usually won, which was efficient when the record was right and devastating when it was wrong.

What the history suggests

Enterprise software repeats patterns found across this site. Standardisation and abstraction won, as SAP’s packaged software defeated custom programming. Compatibility became gravity: once a company’s processes and data were built around a system, it was very hard to leave, and vendors could set the timing of migrations. Computing swung from mainframes to client-server to the cloud, and the vendors that moved early prospered. And large, irreversible decisions taken quickly, Hershey’s cutover, FoxMeyer’s simultaneous projects, went badly.

But enterprise software also shows something more particular. It is the clearest case of software that does not merely help an organisation but defines it: its processes, its controls, its knowledge and, in the end, its sense of what is true. Organisations adopt it to become more efficient and find that they have also become more like their software. That is where the philosophy begins.

Understanding the philosophy

The rest of this essay examines the ideas beneath enterprise software, one at a time. Each is explained in plain terms, connected to the tradition of thought that has examined it, traced in the history above, tested against its strongest objection and related to how organisations decide today. The connections to philosophers, sociologists and management thinkers are interpretations offered to make the ideas clearer. The builders of enterprise systems were solving business problems and did not, as a rule, set out to answer these thinkers.

1. Best practice and the one best way

The idea in plain terms

ERP vendors sell their processes as best practice: the right way to handle an order, a purchase or a payment, distilled from the experience of many companies. The idea is attractive. Why should every company invent its own way of doing what thousands of others already do? But the idea assumes that there is one best way, and that it is the same everywhere.

The tradition

Taylor’s scientific management rested on that assumption. For every task, careful study would reveal the one best way, which should be standardised and imposed. Taylor’s critics objected that he ignored the knowledge and judgement of workers, the variety of conditions and the human costs of treating people as parts of a machine. Later management thinking moved in two directions. One continued Taylor’s project through operations research, quality management and process engineering. The other, from the human relations school of the 1930s onward, emphasised that how work is done depends on people, context and circumstance.

Contingency theory, developed in the 1960s by organisational researchers such as Paul Lawrence and Jay Lorsch, held that there is no one best way to organise; the right structure depends on the organisation’s environment, technology and strategy. The strategist Michael Porter argued in 1996, in “What Is Strategy?”, that operational effectiveness, doing the same things better than rivals, is not strategy. Best practices spread quickly and are easily copied; competitive advantage comes from performing different activities, or performing activities differently.

Where it shows up

ERP is Taylorism for processes. Its standard configurations encode a view of the best way to run finance, purchasing and production, and its vendors urge customers to adopt them. For most companies, most of the time, this is sensible: there is little advantage in a distinctive way of paying invoices. But Lidl’s experience shows the cost when a company’s distinctive practice, here how it valued inventory, conflicts with the standard. Davenport’s warning was Porter’s point applied to software: if every company adopts the same best practice through the same software, none gains an advantage from it, and those whose advantage lay in doing things differently may lose it.

The strongest objection

The objection is that the critics overstate how much companies differ. Most business processes are not sources of advantage, and companies that insisted on their own ways often did so out of habit, not strategy. Standard software freed them from maintaining idiosyncratic systems and let them focus on what really distinguished them. This is largely right. The skill lies in telling the two apart: which processes are commodity, to be standardised, and which are distinctive, to be protected.

What it means today

Before implementing enterprise software, an organisation should decide which of its processes it will adopt from the standard and which it will defend, and why. Defending a process should require a strategic reason, not habit; adopting a standard should require confidence that nothing distinctive is lost. The same reasoning applies to any template, from management frameworks to AI-generated plans.

2. Bureaucracy written in code

The idea in plain terms

An ERP system is a set of rules: who may approve what, which steps must be followed, which fields must be filled, what happens next. It is bureaucracy, in the precise sense of administration by impersonal rules, but enforced by software rather than by clerks. That makes it more consistent and more rigid than any human bureaucracy.

The tradition

The German sociologist Max Weber, writing in the early twentieth century, described bureaucracy as the most rational and efficient form of administration. It is characterised by fixed rules, a hierarchy of offices, written records, specialised training and impersonal application of rules to cases. Weber admired its efficiency and feared its effects. He wrote that the modern economic order was becoming a shell as hard as steel, often translated as an “iron cage,” within which people would be bound by rational rules and calculation, losing meaning and freedom.

The sociologist Robert K. Merton later described the dysfunctions of bureaucracy: officials trained to follow rules come to treat the rules as ends in themselves, applying them rigidly even when they defeat their purpose, a pattern he called trained incapacity.

Where it shows up

ERP systems are Weber’s bureaucracy in its purest form. Rules are applied identically every time; records are complete; authority is defined by role. Their benefits are Weber’s benefits: consistency, predictability, control and the elimination of arbitrary personal discretion. Their dysfunctions are Merton’s: employees who say “the system won’t let me” when a sensible action falls outside the rules, workarounds that develop because the system cannot handle exceptions, and processes that persist because changing the configuration is hard. The Horizon scandal showed an extreme form: an institution whose procedures treated the system’s figures as authoritative even when that defeated the purpose of finding the truth.

The strongest objection

The objection is that bureaucratic rules protect people as well as constrain them. Consistent rules prevent favouritism and fraud; audit trails protect honest employees; segregation of duties enforced by software prevents the theft that discretion allows. Many of the controls in ERP systems exist because of real scandals. This is true. The point is not that rules are bad but that rules encoded in software are harder to bend, question or change than rules administered by people, and so need explicit mechanisms for exceptions and review.

What it means today

Every rule configured in an enterprise system should have an owner who can explain its purpose and a process for handling cases it does not fit. Organisations should watch for workarounds, which are signs that the system’s rules and the work have diverged. And they should notice when employees stop asking whether a rule makes sense, which is the beginning of Merton’s trained incapacity.

3. Who adapts to whom?

The idea in plain terms

When an organisation installs a system, something has to change: the software, to fit how the organisation works, or the organisation, to fit how the software works. Usually both change, in a long negotiation. The outcome shapes the organisation for years, often in ways no one chose deliberately.

The tradition

In 1980 the political theorist Langdon Winner asked, in an essay titled “Do Artifacts Have Politics?”, whether technologies can embody forms of power and authority. His answer was yes: some technologies are designed, intentionally or not, to settle questions of power, and some are strongly compatible with particular social arrangements. The way a system is built can allocate authority, define roles and make certain kinds of organisation easier or harder.

The organisational researcher Wanda Orlikowski, drawing on the sociologist Anthony Giddens’s theory of structuration, argued in the 1990s that technologies and organisations shape each other. A technology embodies structures, its designers’ assumptions, but people enact those structures in practice, using the technology in ways that reproduce or change their organisation. Technology does not simply determine organisation, nor does organisation simply choose technology; each constrains and enables the other over time. A related principle, Conway’s law, observes that the structure of systems tends to mirror the communication structure of the organisations that build them, an idea explored in Organisations Ship Their Own Shape.

Where it shows up

ERP implementations are negotiations over who adapts. Companies that adopted the standard processes changed their roles, approvals and reporting lines to fit the software; companies that customised the software spent heavily to make it fit them, and then struggled to upgrade. Lidl tried to keep its way of working inside standard software, and failed. Orlikowski’s insight explains why even well-planned implementations surprise their designers: employees find their own ways of using the system, workarounds become practices, and the organisation that emerges is neither the one planned nor the one before.

The strongest objection

The objection is that the question of who adapts to whom is overdramatised. Companies choose software that fits them, configure it extensively and change it over time; vendors adapt their products to customers’ demands. The relationship is a normal process of mutual adjustment. This is true, but the balance of power is uneven: the software is built for many customers, and one customer’s needs count for less than the vendor’s roadmap, especially when the vendor sets dates for ending support.

What it means today

Leaders should treat an enterprise system as an organisational design decision, not an IT purchase. The questions to ask before implementation are which roles, decisions and structures the system assumes, and whether the organisation wants them. After implementation, they should watch what people actually do with the system, because that, not the design, is what the organisation has become.

4. Seeing like an enterprise system

The idea in plain terms

To manage something, you need to see it, and to see it at scale, you need to simplify it into standard categories. An ERP system sees a company as master data, transactions and processes. That makes the company visible to its leaders in a way it never was before. It also means that what does not fit the categories becomes invisible.

The tradition

In Seeing Like a State (1998) the political scientist James C. Scott studied how states made their territories and populations legible: measurable, standardised and therefore governable, through surveys, censuses, standard weights and measures, permanent surnames and planned cities. Legibility gave states great power to tax, conscript and plan. But Scott showed that grand schemes imposed in the name of legibility often failed, because they ignored mētis, the local, practical knowledge that made complex systems work. The site’s idea Legibility and Mētis explores this in detail.

Where it shows up

ERP systems are legibility machines for companies. They require every customer, product and supplier to be recorded in standard master data, every transaction to follow a defined path and every cost to be allocated to a defined account. Leaders gain a view of the whole company in real time, which is a genuine advance. But the system can see only what it is designed to record. The informal arrangements by which experienced staff got things done, the customer who was always given extra time to pay, the supplier who could be phoned for an urgent delivery, the warehouse worker who knew which shelf really held which product, are often lost when the system is introduced. Hershey’s product sat in its warehouses while the system could not see how to ship it.

The strongest objection

The objection is that informal knowledge is also where favouritism, error and fraud hide, and that making a company legible to its managers and auditors is a precondition for accountability. Scott’s examples concern states imposing schemes on populations; companies choosing systems for their own operations are different. This has force. Legibility in companies is mostly beneficial. The warning is narrower: when introducing legibility, find out what practical knowledge the old arrangements contained, and do not assume the new system captures it.

What it means today

Before replacing a system or process, ask the people who do the work what they know that the system does not record. After implementation, look for the things that used to happen informally and no longer do. And remember that the dashboard shows what the system can count, which is not everything that matters.

5. Automate or informate

The idea in plain terms

Information technology can be used in two ways: to replace human work, or to give people more information so that they can work better. The same system can do either, depending on how it is designed and deployed. The choice shapes what workers know, what they can do and how much they are trusted.

The tradition

In In the Age of the Smart Machine (1988) the social psychologist Shoshana Zuboff studied workplaces where computers were being introduced, from paper mills to offices. She argued that information technology has a dual capacity. It can automate, substituting machines for human effort and skill, as earlier industrial technology had. But it also informates: it generates information about the processes it controls, making them visible in new ways. Managers could use that information to tighten control and deskill workers, or to share it and build a more knowledgeable, empowered workforce. Zuboff found that most organisations chose control, and lost the potential of the second path.

Where it shows up

ERP systems automate a great deal: posting transactions, calculating requirements, generating invoices. They also informate, producing vast amounts of data about how the company operates. In many implementations, that information flowed upwards to management and auditors, while front-line employees saw only the screens needed to enter data. Workers became operators of the system rather than users of its information. Where companies shared the information, giving employees visibility into orders, inventory and customer histories, the systems could make them more capable. The arrival of AI agents in enterprise systems sharpens the choice again: agents can automate decisions, or inform the people who make them.

The strongest objection

The objection is that Zuboff’s dichotomy is too neat. Most systems do both, and automation is often exactly what workers want, relieving them of tedious work. Giving every employee access to all information can overwhelm them and breach confidentiality. This is fair. The point is not that automation is bad but that informating is a choice that organisations can make deliberately, and that the default tends towards control.

What it means today

When implementing or extending an enterprise system, especially with AI, ask what information the people doing the work will gain, not only what work will be removed. Organisations that use systems to make their employees more knowledgeable tend to get more from both.

6. What cannot be written down

The idea in plain terms

Much of what makes an organisation work is knowledge that its people cannot fully state: how to handle a difficult customer, which supplier can be trusted in a crisis, when to bend a rule. Enterprise systems require knowledge to be made explicit, as rules, fields and workflows. What cannot be made explicit is at risk of being lost.

The tradition

The chemist and philosopher Michael Polanyi argued in The Tacit Dimension (1966) that we know more than we can tell. Skilled practice depends on tacit knowledge, learned through experience and example, which cannot be fully articulated in rules. The Japanese management scholars Ikujiro Nonaka and Hirotaka Takeuchi argued in The Knowledge-Creating Company (1995) that organisations create knowledge through continual conversion between tacit and explicit forms, and that companies which reduce knowledge to explicit information lose the capacity to innovate. The essay on large language models discusses Polanyi’s idea in relation to AI.

Where it shows up

ERP implementations require companies to document their processes in detail, which often reveals how much depended on tacit knowledge. The rules configured in the system capture the explicit part. When experienced staff retire, leave or are replaced during re-engineering, the tacit part can go with them. Many implementation problems, such as Hershey’s difficulties in getting product out of warehouses, arise at the boundary between what the system knows and what people used to know. The Horizon scandal shows a darker side: sub-postmasters knew that they had not taken the money, a knowledge the system could not represent and the institution would not credit.

The strongest objection

The objection is that making knowledge explicit is valuable precisely because tacit knowledge is fragile, inconsistent and held by individuals who leave. Documenting processes, encoding rules and building systems that do not depend on particular people make organisations more resilient. This is true; making knowledge explicit is a central achievement of modern organisations. The warning is that not all knowledge can be made explicit, and that systems should leave room for the judgement that cannot.

What it means today

During system implementations, keep experienced people involved and listen to what they say the system misses. Design processes with exception paths that rely on human judgement, and record why exceptions were made, which turns some tacit knowledge into explicit learning. And be wary of efficiency programmes that remove the people who carried the organisation’s unwritten knowledge.

7. When the system says you are guilty

The idea in plain terms

People tend to trust computers. A figure produced by a system looks objective; a person disputing it looks self-interested. When institutions build that tendency into their procedures, by treating system records as evidence and requiring people to disprove them, the consequences can be catastrophic when the system is wrong.

The tradition

Psychologists studying automation have documented automation bias: the tendency to favour suggestions from automated systems and to discount contradictory information, even from one’s own observation. Raja Parasuraman and Victor Riley, in a 1997 paper, described the misuse of automation, over-reliance on it, as one of the main ways human–automation systems fail. The philosophical question of whom to believe, the testimony of a person or the record of a machine, connects to the long tradition on the epistemology of testimony.

In law, the presumption that mechanical instruments are working correctly, such as clocks and speedometers, has a long history. When the English legal system extended a similar presumption to computers in 1999, it treated complex software, which contains bugs, as though it were a simple instrument. After the Horizon scandal, lawyers and computer scientists called for the presumption to be reformed.

Where it shows up

The Post Office case is the clearest example. The institution trusted Horizon’s figures over the accounts of hundreds of sub-postmasters, many of whom had served their communities for years. It did not seriously consider that the system might be wrong, though some within the Post Office and Fujitsu knew of problems. The legal presumption made it hard for defendants to challenge the system. Isolated individuals, each told that they alone had problems, could not see the pattern. The essay on large language models discusses related failures of trust in machine output.

The strongest objection

The objection is that systems usually are more reliable than people, and that the Horizon case was exceptional. Organisations cannot investigate every discrepancy as a possible software bug, and records are necessary evidence in most fraud cases. This is true; computer records are generally reliable and indispensable. The lesson of Horizon is not to distrust systems but to treat their output as a claim that can be wrong, especially when many people report the same kind of discrepancy, and to make it possible to check.

What it means today

Organisations should have processes for investigating cases where people dispute what their systems say, and should look for patterns in such disputes. Evidence from systems should be accompanied by the ability to examine how it was produced. As AI agents take actions inside enterprise systems, the same principle applies with more force: an output that is fluent and confident is still only a claim.

8. Why failing projects are hard to stop

The idea in plain terms

Enterprise projects that are going badly are rarely stopped early. Money has been spent, careers are invested, and stopping would mean admitting failure. So more money is spent, often for years. The longer a project runs, the harder it becomes to stop, even when the evidence says it should be.

The tradition

In 1976 the organisational psychologist Barry Staw published a study titled “Knee-Deep in the Big Muddy,” showing that people who were responsible for a failing course of action tended to invest more in it, not less, to justify their earlier decision. He called this escalation of commitment. Economists describe the error of letting past costs that cannot be recovered influence future decisions as the sunk cost fallacy, explored in Sunk Costs and the Escalation of Commitment. The planning scholar Bent Flyvbjerg, studying thousands of large projects, found that most exceed their budgets and schedules, and that the cause is systematic optimism and strategic misrepresentation at the outset, which he proposed to correct with reference class forecasting, the method described in The Inside View and the Outside View.

Where it shows up

The Air Force’s ECSS ran for eight years and a billion dollars before cancellation. Lidl’s project ran for seven years. In both cases, the organisation continued long after warning signs appeared. Hershey compressed its schedule rather than delay past the peak season, and FoxMeyer bet its business on promised savings. Each fits the pattern Staw and Flyvbjerg described: optimism at the start, commitment that grew with investment and difficulty stopping.

The strongest objection

The objection is that perseverance is often right. Most large implementations go through a valley of difficulty before they succeed, and projects stopped too early waste the investment made. Many ERP projects that looked troubled eventually delivered. Distinguishing a difficult project from a doomed one is genuinely hard. This is fair. The answer of the tradition is not to stop every troubled project, but to decide in advance what evidence would justify stopping, to have someone without a stake in the original decision review it, and to compare the project with how similar projects have actually gone.

What it means today

For any large system project, set explicit criteria for continuing, pausing or stopping before it begins, and review them with people who were not responsible for starting it. Break the project into pieces that deliver value on their own, so that stopping does not mean losing everything. And compare the plan with the outside view: how long and how much projects like this have actually taken.

Bringing the threads together

Enterprise software carried Taylor’s idea of the one best way into code, as best practice that many companies could adopt. It became Weber’s bureaucracy made rigid by software. It forced a negotiation between organisation and system over who would adapt, in which the system often won. It made companies legible to their leaders and less attentive to what did not fit the categories. It could automate or informate, and usually automated. It made knowledge explicit and lost what could not be written down. At its worst, it was trusted more than the people it recorded. And its largest projects showed how hard it is to stop what has already cost so much.

The company inside the machine

When SAP’s founders decided to write standard software, they made it possible for companies everywhere to run on integrated, reliable systems that no single company could afford to build. Enterprise software has made organisations more efficient, more consistent and more accountable, and most of the time it works quietly, recording the transactions of the world economy.

The history also shows what organisations give up and risk when they adopt it. The working principles are not complicated. Decide which of your processes to standardise and which to protect, before the software decides for you. Give every configured rule an owner and every exception a path. Ask what the people who do the work know that the system does not. Treat the system’s output as a claim to be checked, especially when people dispute it. Break large projects into pieces that can succeed or fail separately, and decide in advance what would make you stop. And as AI agents begin to act inside these systems, keep a human able to see, question and override what they do. A company that installs an enterprise system is choosing what kind of company to become. It is worth making that choice deliberately.

Selected bibliography

• Taylor, Frederick Winslow. The Principles of Scientific Management. Harper & Brothers, 1911.
• Weber, Max. The Protestant Ethic and the Spirit of Capitalism. 1905; and Economy and Society, 1922.
• Merton, Robert K. “Bureaucratic Structure and Personality.” Social Forces 18, no. 4 (1940): 560–568.
• Polanyi, Michael. The Tacit Dimension. Doubleday, 1966.
• Lawrence, Paul R., and Jay W. Lorsch. Organization and Environment. Harvard Business School, 1967.
• Orlicky, Joseph. Material Requirements Planning. McGraw-Hill, 1975.
• Staw, Barry M. “Knee-Deep in the Big Muddy: A Study of Escalating Commitment to a Chosen Course of Action.” Organizational Behavior and Human Performance 16, no. 1 (1976): 27–44.
• Winner, Langdon. “Do Artifacts Have Politics?” Daedalus 109, no. 1 (1980): 121–136.
• Zuboff, Shoshana. In the Age of the Smart Machine. Basic Books, 1988.
• Hammer, Michael. “Reengineering Work: Don’t Automate, Obliterate.” Harvard Business Review, July–August 1990.
• Orlikowski, Wanda J. “The Duality of Technology: Rethinking the Concept of Technology in Organizations.” Organization Science 3, no. 3 (1992): 398–427.
• Hammer, Michael, and James Champy. Reengineering the Corporation. HarperBusiness, 1993.
• Nonaka, Ikujiro, and Hirotaka Takeuchi. The Knowledge-Creating Company. Oxford University Press, 1995.
• Porter, Michael E. “What Is Strategy?” Harvard Business Review, November–December 1996.
• Parasuraman, Raja, and Victor Riley. “Humans and Automation: Use, Misuse, Disuse, Abuse.” Human Factors 39, no. 2 (1997): 230–253.
• Davenport, Thomas H. “Putting the Enterprise into the Enterprise System.” Harvard Business Review 76, no. 4 (1998): 121–131.
• Scott, James C. Seeing Like a State. Yale University Press, 1998.
• Flyvbjerg, Bent, and Dan Gardner. How Big Things Get Done. Currency, 2023.
• Bates and Others v Post Office Ltd (No 6: Horizon Issues) [2019] EWHC 3408 (QB).
• Post Office (Horizon System) Offences Act 2024.
• Post Office Horizon IT Inquiry. Final Report, Volume 1. 2025.

Research limitations

Accounts of the FoxMeyer, Hershey, Lidl and US Air Force projects rely on contemporary press reports and later case studies; the parties disputed responsibility in several cases, and the litigation over FoxMeyer was not fully reported. Cost figures are as reported and approximate. The explanation of Lidl’s difficulties, including the inventory valuation issue, comes from press reports and was not confirmed by the company. The account of the Horizon scandal relies on the High Court judgment, the 2024 Act and reports of the public inquiry; the inquiry had not published all of its conclusions on responsibility at the time of writing, and this essay makes no claims about individuals. The attribution of the term ERP to Gartner follows common usage. SAP’s revenue figures are from its own results. The description of AI agents in enterprise systems is general and describes a rapidly changing field. The philosophical connections to Taylor, Lawrence and Lorsch, Porter, Weber, Merton, Winner, Orlikowski, Giddens, Conway, Scott, Zuboff, Polanyi, Nonaka and Takeuchi, Parasuraman and Riley, Staw and Flyvbjerg are the author’s interpretation; their works are paraphrased apart from short, attributed phrases. The decisions in the decisions box are judged by the author, separating what could be known at the time (process) from what happened (call).

Footnotes

1. “Halloween less spooky for Hershey’s this year,” Computerworld; “Supply chain: Hershey’s bittersweet lesson,” CIO. ↩

2. Joseph Orlicky, Material Requirements Planning (McGraw-Hill, 1975); see “From BOMP to SaaS and Beyond: 1970s”. ↩

3. “SAP R/3: A History of Enterprise Software,” We Are Open; Encyclopedia.com, “SAP AG”. ↩

4. Thomas H. Davenport, “Putting the Enterprise into the Enterprise System,” Harvard Business Review 76, no. 4 (1998). ↩

5. “SAP software ‘hastened’ FoxMeyer’s demise, say trustees,” The Register, August 1998; “Enterprise resource planning: SAP’s drugs bust ends up in court,” Computing. ↩

6. “The US Air Force explains its billion-dollar ECSS bonfire,” IEEE Spectrum; “Senators Levin and McCain call for answers on failed Air Force ERP program,” Defense One. ↩

7. “Lidl cancels SAP introduction having sunk €500 million into it,” Consultancy.uk, citing Handelsblatt; RetailDetail. ↩

8. Wikipedia, “British Post Office scandal”; Wikipedia, “Bates & Others v Post Office Ltd”; Institute for Government, “The Post Office (Horizon System) Offences Bill”; “The Post Office scandal in numbers,” AOL/PA. ↩

9. SAP News, “Embracing the future: a strategic shift to cloud ERP”, October 2024; Redress Compliance. ↩

10. SAP SE, quarterly statement Q4 2025, 29 January 2026. ↩