Design — Trading off fit-to-standard against custom requirements

This is the fifth of thirteen chapters in "Inside a Large ERP Program." The earlier chapters set out the triple lens the book reads each phase through, then walked scoping, selection, and program architecture. This one enters the design phase, where the program's processes get designed against the standard, and where a single arbitration meeting can quietly decide years of the program's future.

The program directive is never ambiguous. Stay close to the standard. Configure, don't develop. Keep the core clean. Everyone signs up to it at kickoff, and it goes on every steering slide for two years.

Then watch where that directive actually lives. It lives in the mouth of a consultant, in a design workshop, facing a business owner who has done the job one way for fifteen years. And that consultant has no power to enforce it. He can propose the standard. He cannot make anyone accept it. So the gap between the directive and its application is total: the principle is carried by the one person at the table who has no authority to apply it.

That gap is the subject of this chapter. Design isn't where fit-to-standard is won. It's where it's argued by people who can't decide it.

How a design actually gets made

Design isn't one meeting. It's a sequence of workshops.

The first workshops collect. You gather the business need and the historical way of working, the way it has always been done, exception flows and all. Then the consultants go away and think. They come back with a proposed design, built to land as close as possible to what the SAP standard can do, and they put it in front of the global process owner or the key users.

What you hope to see at that moment is flexibility, a business willing to bend its habits to work the standard way. What you usually get is the opposite. Habit blocks. The business owner looks at the standard flow and says it doesn't fit, asks for a specific alternative that matches the way they already work. And now the machine turns: the consultants go back to the developers and the project management, build a costing and a schedule for the requested specific, and that package goes up to the arbitration committee.

Notice what just happened. The workshop didn't decide anything. It surfaced a need, hit a wall of habit, and packaged a request. The actual design decision moved one level up, to a room the key users aren't in. The workshop instructs. It doesn't rule.

The authority is somewhere else

Here is the structural fact most programs never say out loud. Only the arbitration committee can force the business onto the standard. The consultant can't. The program directive says "stay close to the standard," and the person repeating it in the workshop has no lever to make it true.

There's a human cost to that gap. The consultants wear themselves out trying to hold a line they have no authority to hold. They push the standard, argue for it, fight the business owner to respect the program's fit-to-standard directive, all while the balance of power is against them. The sane way to work is to stop fighting battles you can't win at your level: propose the standard, and at the first real resistance, escalate. Raise the point, hand it to the committee, let the authority that exists settle it. The consultants who don't learn that, who keep absorbing the friction personally because they feel responsible for a directive they can't enforce, are the ones who burn out. A lot of them do. I did.

So the committee is where it's settled, and the committee is a confrontation. The business line comes in defending its specific. The program leadership is supposed to block it, to say no, this runs in standard, you don't get the development. That's the design, working as intended: the program director holds the line the consultant couldn't.

But the line only holds if someone at the right level actually defends it, with the right argument. If the program leadership doesn't hold, or doesn't have the technical case to show the committee that the gap really does run in standard, the gap passes. And it passes wearing the authority of a committee decision, which makes it final. And that's where the consultant role really is in the end: presenting at the committee the best arguments, slides, and pros and cons to push it toward the standard.

That's the part to sit with. Fit-to-standard isn't a property of a good design. It's the outcome of a power struggle in a committee room. No committee that holds the line, no standard, no matter what the directive says or how many slides repeat it.

The daily cost transfer that never stabilized

Let me give you the cleanest example I have, and it comes from an intercompany flow.

The business wanted the costs of an internal supplier to land in the internal customer on a daily basis. The reason was partly habit, their previous ERP, an Oracle system, had worked that way, and they didn't want to change. But it wasn't only habit. They wanted to be able to invoice the external customer off the internal costs without waiting for the internal supplier's invoice, which arrived less often. That's a real business need, not a whim, and it's worth saying clearly: the people asking for this had a defensible reason.

The problem is how SAP moves cost between companies. In SAP, an intercompany cost transfer goes through internal invoicing. If you want the cost to move, you raise an internal invoice. The business didn't want to multiply invoices, and didn't want to lower the transfer frequency to match an invoicing rhythm. So the request that went up was a specific: a custom program that would post the costs daily, revenue included, through an FB01 posting. Which meant, under the hood, collecting all the costs, collecting the associated revenue, merging the two, and then determining the analytical object in the internal customer, every day, by code.

The committee approved it, and the build began. After months of development, the program still wasn't reliable, not quickly anyway. There were too many sub-cases, edge conditions nobody had been able to anticipate in advance, and each one needed its own handling. In the end the daily ambition collapsed back to weekly invoicing, the thing the standard would have given them in the first place. Months of custom development to arrive, eventually, near where standard would have started.

The decision to attempt it took one committee. The bill, months of build, then the climbdown, landed on the people who came after.

Who decides is not who pays

That example isn't a one-off. It's the mechanism, and the mechanism is simple enough to state in one line: the person who wins the gap is almost never the person who pays for it.

The business that secured its daily cost transfer had a real reason to want it, and it was never going to concern itself with the technical debt the custom program created. Why would it? It asked for something that served how it needed to operate. The debt, the months of build, the unstable program, the edge cases multiplying in code, the eventual climbdown, lands somewhere else entirely, on the technical team, on the run organization, on whoever inherits the program afterward.

The calendar version of this is "design validated by people who'll never run the system." That's true, but it's not quite the heart of it. The business owner does run the system, every day, with the process they fought for. What they don't carry is the debt. The convenience sits with the decider; the consequence sits with the people who maintain it in the long run. And note, the business asking for something reasonable doesn't change the outcome, the requester here wasn't being unreasonable, and the debt landed all the same.

Which tells you the question the committee should be asking, and usually isn't. The committee asks: is this gap justified for the business? And the answer, from the business's side of the table, is almost always yes, because the business is sincere, the specific really does suit how they work. That's the wrong question. The right one is: who carries the debt this gap creates? Because let's raise another misalignment while we're here: the program director is usually not the manager of the run team that will clean up his potential mistakes afterward. And a second question the cost-transfer case makes obvious: has anyone actually established that the specific can be built reliably, or are we approving an ambition?

What design really decides

Pull it together and design stops looking like a workshop phase. The workshops collect and instruct, but they don't decide, and the consultants who run them hold a directive they can't enforce. Fit-to-standard is won or lost one level up, in the arbitration committee, on a single question the committee too rarely asks: is the person winning this gap the same person who'll carry its debt?

When the answer is no, and it almost always is, the program buys years of debt with minutes of meeting time, and pays for it long after everyone in the room has moved on. Get that question into the committee, make the cost visible to the people deciding, and most of the bad gaps die where they should, before they reach the code.

Once the design is arbitrated, someone has to build it. And whether it gets built well, or merely gets built, is its own story. That's where the next chapter goes: Build — Turning design decisions into configuration and code.