How ERP software is crippled by bad design. It's the process, stupid!

Recently, I learned that ASML, the world’s leading manufacturer of lithography equipment, is making a major investment in expanding their SAP implementation.

That surprises me, because I’ve always thought of ASML as a pretty cool company. For instance, they use virtual reality to train their maintenance people, so they can work through a repair before visiting a customer’s site.

So what would a tech-savvy, forward-thinking firm like them be doing with SAP? Particularly when they’ve got the resources to build something from scratch that does exactly what they want?

Why choose SAP?

The promise of SAP is a single platform for all processes in your business, such as customer relationship management, resource planning, supply chain management, and business intelligence.

The idea of an all-in-one solution can be very appealing, particularly if you’re currently struggling with multiple systems.

You also have to consider SAP’s critical mass. It has a reputation of being the gold standard in ERP, so you get the reassurance of choosing what others have chosen. And if your clients or suppliers are using it, it seems sensible for you to use it too.

None of this necessarily means SAP is right for your business, but it’s hard to swim against the tide. To adapt the old computing proverb, “Nobody got fired for buying SAP.”

Empty promises

Unfortunately, SAP is not a miracle cure.

First, before you can start using it, you need to have it set up and configured to your business by a specialist consultant. SAP implementations can take months and run to hundreds of thousands of euros. I imagine ASML’s will cost millions.

That price would be worth paying if the software lived up to its promise. But clients who worked with SAP in the past tell me that it is clunky, inflexible, and frustrating to use.

On a technical level, it’s hard to make SAP talk to other software, and programmers dislike its ABAP development language. Worst of all, once you start using it, you’re effectively locked in, unable to escape without a disruptive switching process.

No wonder, then, that 60% of SAP customers say they would not buy SAP’s solutions again, and 90% have no plans to upgrade to SAP’s new S/4HANA platform.

One size doesn’t fit all

This disappointment with SAP isn’t that surprising when you think about the nature of prefab software. Whereas custom-built software is built from scratch to meet a specific need, an SAP implementation is an adaptation of a one-size-fits-all base product. It is a solution in search of a problem. Let me explain.

The purpose of business software is to automate processes. As software developers, our job is to create the functions and interfaces that allow the user to interact with the computer as smoothly and transparently as possible, so they can get their job done more quickly and easily.

If the task at hand is relatively simple, a standard tool will do. Most of us find that Word is up to the job of writing text. And if you’re running a trading company selling commodity products, off-the-shelf software is perfectly adequate.

However, the more complicated the task, the less useful one-size-fits-all solutions become.

Form follows function

Creating effective custom software begins with establishing a good design process.

Design is not just about creating layouts or setting visual styles. It is all about finding the best way to automate highly complex, multidimensional processes. This sort of design is closer to architecture or engineering than graphics. As Steve Jobs used to say: “Design is not just what it looks like and feels like. Design is how it works.”

The guiding principle of good design is that form follows function. A tool should be designed for the job it has to do.

That fit between form and function can only be achieved if you fully understand the problem to be solved, and keep an open mind about ways to solve it. You reach your destination by taking a carefully calibrated sequence of decisions — a delicate process that involves careful listening, deep understanding, suppressing prejudices, and not jumping to conclusions.

Insights from research

Before we start building an application, we go through a detailed research phase. This can take weeks or even months if the project is large.

The best approach is with a team with three disciplines: a client-side domain expert who understands the problem to be solved, an analyst who can translate tasks into features, and a developer who actually codes the software.

The insight flows from the client to us, because the software should be shaped by the process, not the other way around. Form follows function.

Research like this can be transformational, because it invites clients to think deeply about how their business works, and how it could work.

The SAP way

When you adopt SAP, the analyst can’t work from a clean slate. The analyst has to reconcile whatever you want to do with what SAP can actually offer.

Here, the solution is already a factor in the design, and that corrupts the design process. Form does not follow function; instead, function follows form. SAP already exists, as a one-size-fits-all solution that has to work for every company, and your needs must be bent out of shape to fit it. “The answer is SAP. Now, what’s the question?”

In theory, SAP is customizable. Fields can be moved around, and business logic can be adapted. But based on the SAP implementations that I’ve seen, it seems that clients run out of time and money before they are able to reach an acceptable result.

To add insult to injury, you’re effectively paying your consultant to lock you into SAP. Instead of offering impartial advice on what’s best for you, as a consultant should, they’re tying you down with a suboptimal solution.

All this means that SAP simply cannot be right for your business in the same way that custom-built software is.

Thoughtful design

Compared with custom-built software, the typical SAP interface looks thoughtless — because it is. It wasn’t designed around the tasks that users need to accomplish. Instead, it’s a lowest common denominator solution that tries to be acceptable to thousands of different companies.

In contrast, custom-built software is thoughtfully designed. The way people work is reflected in its structure, functionality, and language. That makes work far easier, quicker, and more streamlined, and reduces training time for new staff too.

Caring about quality

Emotions matter. If people really hate the software they’re using, it’s a sign that it’s holding them back. And that’s a very real cost to your business in terms of reduced motivation, productivity, and ultimately profit.

Custom-built is about giving talented people the best tools to do their jobs. Asking them to use ERP software is like giving them uncomfortable chairs, or not heating the office in winter. It doesn’t make a lot of sense.

That’s why it’s so surprising that ASML, with a culture of innovation, tons of resources, and clear authority over their supply chain, would put up with SAP. They could have made a huge leap forward in their corporate development, but instead they’re locking themselves into a little box. And the only winners, in the end, will be SAP.