ERP is a process project, not a software project

The software is the easy part

You can install ERPNext on a server in an afternoon. Getting a business to run on it takes months, and very little of that time goes into the software. It goes into questions. When does an order count as confirmed? Who can promise a delivery date? What happens when a good customer is over their credit limit and the salesperson is sure they will pay?

Every company already has answers. They are just not written down, and different people give different ones. An ERP drags those answers into the open, because a system cannot run on “it depends who you ask”.

None of this is new. In 1998, as the first big wave of enterprise systems went in, Thomas Davenport wrote that the technical challenges “are not the main reason enterprise systems fail. The biggest problems are business problems.”¹ Of the more than 50 companies he had studied, the ones getting the most from their systems had “stressed the enterprise, not the system.”¹

Survey data points the same way. In 2001, Toni Somers and Klara Nelson surveyed 86 organisations that had finished an ERP implementation or were partway through one. Their respondents, mostly IT managers and executives, rated 22 factors by how much each mattered.²

The top of the list is about people: leadership, a capable team, departments that cooperate, clear goals. Most of the factors about the software, its vendors and outside help sit in the lower half. It is one survey, answered mostly by IT people, and the gaps between neighbours are small, so we read it as a shape, not a league table. One detail stands out, though. When the authors asked which factors mattered most at each stage, interdepartmental communication topped the list at every stage from adapting the system onward, with cooperation in the top three each time.²

Daniel Robey, Jeanne Ross and Marie-Claude Boudreau saw a similar split when they studied 13 industrial firms that had implemented ERP. Every firm had to get past two kinds of knowledge barrier: configuring the package, and absorbing new ways of working. Strong core teams and well-managed consultants handled the first. The second lingered. All 13 firms “experienced ongoing concerns” with it.³

That is why our first weeks on an ERPNext project are mostly questions, not configuration. The question that matters is not “how do we set this up?” It is “how does this business actually work?”

Don’t automate the mess

In 1990, Michael Hammer told a story about Ford that still explains ERP better than most ERP manuals.⁴ In the early 1980s, Ford’s accounts payable department in North America employed more than 500 people. Management planned to cut that by about 20% with new computer systems and tidier procedures. Then they looked at Mazda, where accounts payable was five people. Even allowing for Mazda’s smaller size, Ford’s department was five times bigger than it should have been.

The problem was not the clerks. It was the process. Three documents reached accounts payable from three directions, and someone had to match 14 data items across them before Ford would pay. Most of the department’s time went on the ones that did not match.

Ford did not speed up the matching. It removed it. Purchasing entered each order into a shared database. Receiving checked every delivery against it, accepted goods that matched an open order and sent back the rest. The computer prepared the cheque, and vendors were asked to stop sending invoices. The rule changed from “We pay when we receive the invoice” to “We pay when we receive the goods.” Where the new process ran, head count fell by 75%, not 20%.⁴

Hammer’s advice fits in one line: use information technology “not to automate an existing process but to enable a new one.”⁴ An ERP gives you the shared record that made Ford’s version possible. It does not decide to use it that way. Install it over the old process and you get the old process, faster.

Davenport has a later example. At Elf Atochem North America, a chemicals company, processing an order took four days and seven handoffs between departments, although only four hours of actual work were involved. The real source of its difficulties, he wrote, was “not the fragmentation of its systems but the fragmentation of its organization.”¹

So before we configure anything, we map how work runs today. Not the version in the policy file, the real one, with the WhatsApp messages and the spreadsheet on someone’s desktop. We follow one real order from enquiry to cash and ask the same things at every step: who does this, what do they type, where does the information come from, and what happens when it is wrong. The steps that matter most are often the ones nobody mentioned in the first meeting. Then we draw the process we want, and only after that do we ask how the software supports it.

Every process needs an owner

Departments own steps. Nobody owns the flow. Sales owns the order, the store owns dispatch, accounts owns the invoice. When an order goes wrong somewhere between them, each team can show that it did its part.

Hammer’s answer was a process owner: one person responsible for the whole flow, end to end. In his process audit, the weakest kind of owner “lobbies for the process but can only encourage functional managers to make changes.” A strong one “controls the IT systems that support the process and any projects that change the process.”⁵ In an ERP project, that is the person who should sign off the design.

The owner’s job is to make the decisions the system will later enforce. Does an order over the credit limit stop, or go through with a warning? Who can let it through? Do all branches follow one rule, or does each keep its own? Davenport called that last question the hardest part of an implementation: “determining what should be common throughout the organization and what should be allowed to vary.”¹ If nobody with authority answers these questions, the implementer ends up answering them by accident, one setting at a time.

Once the owner decides, the rule can live in the system. In ERPNext, a workflow sets the states a document moves through and the role allowed to move it at each step. It can also carry conditions, such as an amount above which a particular role must approve.⁶

Notice what the screen does not need: a phone call to accounts, a reminder on WhatsApp, a printed approval slip. The rule was agreed once, by the person who owns the process, and the system applies it every time.

Master data is the process, written down

An ERP is built so that one entry updates everything at once. A sales order reserves the stock, tells the store what to pack and tells accounts what to bill. That is the whole point. It also means a mistake in the base records does not stay where it was made.

Master data is the set of records everything else points at: items, customers, suppliers, prices, bills of materials, the chart of accounts. Here is one carton, recorded twice.

Nothing in the second run is a software bug. The system did exactly what it was told, three times over. Meanwhile 120 cartons sit on the shelf under the old code, free to be promised to someone else.

Duplicates like this rarely come from careless people. They come from nobody being in charge of the list. When Anders Haug and Jan Stentoft Arlbjørn surveyed 90 Danish companies, the factor with the largest impact on master data quality was “a lack of delegation of responsibilities for maintaining master data”.⁷ A later study by the same group with 787 manufacturers advised focusing on organisational issues first, rather than treating poor data quality as an IT problem.⁸

It starts with definitions. One of the questions Davenport says to settle first is: “Does the term ‘customer’ mean the same thing in every business unit?” Monsanto, one of his examples, went from 24 coding schemes for suppliers to one.¹

So master data gets an owner too. We agree naming rules before anything is migrated, limit who can create items and customers, and clean the records on the way in, not after go-live. Once bad records are mixed into live transactions, they are far harder to pull apart.

Configure before you customize

Sooner or later the software and the business disagree. The form has no field for something you track, or the approval runs differently from how you have always done it. Christina Soh and her colleagues, who studied these gaps in Singapore’s public hospitals, call them misfits. They list the choices an organisation has: “adapting to the new functionality, living with the shortfall, instituting workarounds, or customizing the package.”⁹ Somers and Nelson put it more bluntly: “Management has the ultimate choice of changing the process to fit the system or the system to fit the process.”²

Customizing is not one thing. Lars Brehm, Armin Heinzl and Lynne Markus described nine ways to tailor an ERP package, from setting parameters to rewriting its code, and estimated how much upkeep each one creates once the system is live.¹⁰

The cost of tailoring does not arrive once. It comes back with every release, and it adds up even for small changes. At one company Ben Light studied, staff had renamed terms and removed unused fields across many screens. Each change was small and easy to make, but keeping them all up, with their documentation, took 60 per cent of the ERP administrators’ weekly workload, and the next upgrade would wipe them out.¹¹

ERPNext makes the light end unusually wide. Customize Form does not change the underlying form; it adds separate records that override its properties.¹² Custom fields get a prefix “to avoid a potential clash with current/future standard fields”.¹³ Workflows and print formats are set up as records too, not code.

So our rule is simple. When the software and the business disagree, we first ask whether the business should change. Nah, Lau and Kuang’s review of the early ERP studies gave the same advice: “Organizations should be willing to change the business to fit the software with minimal customization.”¹⁴ The exception is where the difference is how the client wins. Davenport warned that an enterprise system “pushes a company toward generic processes even when customized processes may be a source of competitive advantage.”¹ There we customize on purpose, and the code goes into a separate app, never into ERPNext itself. Frappe’s update command, bench update, refuses to run while an app has uncommitted local changes, and one of the ways out it suggests is to discard them.¹⁵

Go-live is the halfway mark

Lynne Markus and Cornelis Tanis describe an enterprise system’s life in four phases: chartering, the project, shakedown, and what they call onward and upward.¹⁶ In our experience, most project plans stop at the end of the second. Yet shakedown, the stretch from go-live until work is normal again, is where “the errors of prior phases are felt”, as lost productivity or disruption. Only in the last phase can a company judge what it got for its money.¹⁶

A study of ERP adopters by Markus and her colleagues found the same thing from the other end: “many of the problems experienced in later phases originated earlier but remained unnoticed or uncorrected.”¹⁷ A process nobody agreed on in chartering turns into a workaround in shakedown. And workarounds outlive their reasons. People adopt them to cope with early problems, Markus and Tanis note, “and then fail to abandon them when the problems are resolved.”¹⁶

So the process work does not stop at go-live. Someone has to sit with users in the first weeks and fix what blocks them, retrain the people who drift back to spreadsheets, and write down why each setting was chosen, because the people who know tend to move on. Markus and Tanis list that loss of knowledge as a common problem of the final phase.¹⁶

None of this makes the technology matter less. It puts it in its place: after the questions, not before them.

You can buy the software. You have to build the process.