Build — Turning design decisions into configuration and code

This is the sixth 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, architecture, and design. This one enters the build, where the design finally meets configuration and code, and where the question stops being what to build and becomes whether it gets built well or merely gets built.

The build phase is traditionally approached as a standardized factory floor. Management visualizes a clean pipeline where competent teams line up discrete objects: a piece of standard configuration, a block of custom ABAP code, a set of test scripts. This theoretical framework is comforting to PMOs, but it hides the exact mechanism of project failure.

The build is not a monolithic manufacturing block. It is a critical, fragile chain of handoffs: from the business to the functional consultant, from the functional consultant to the developer, from the developer to the tester, and eventually back to the business. It breaks at the seams between these links far more often than inside any single box.

When a program transitions to a distributed delivery model (offshore or nearshore factories), the problem does not change its nature—it changes its scale. Every seam is suddenly stretched across a time zone, an cultural boundary, and a Jira ticket. An enterprise ERP program is never judged by the isolated quality of its links; it survives or dies based on the structural solidity of its seams.

The technical seam: The fiction of the standard Agile user story

The first structural seam opens between the functional design and technical execution. In modern ERP rollouts, integrators frequently push for a pure "Agile factory" approach, relying on lightweight user stories to drive offshore development. For an enterprise core system like SAP S/4HANA or Oracle Cloud, this method is highly dangerous.

A user story stating "As a credit manager, I want to block high-risk invoices" is completely useless to a developer sitting 5,000 miles away. It lacks the architectural context required for complex integrated systems. When left with vague parameters, an offshore factory will inevitably build a decoupled, custom silo that ignores database locks, standard memory blocks, or core table joins.

To bridge this technical seam, you must reject the shortcut of conversational specs and enforce a rigid, structured functional appendix. Every technical specification must explicitly detail:

• The precise database tables and standard field structures involved (e.g., BSEG, ACDOCA).
• The exact standard SAP BAPIs, BADIs, or extension points to be used, protecting the "clean core" principle.
• The transaction volume expectations and specific database indexing to prevent catastrophic locks during month-end closes.

Landscape governance and the transport matrix

The second technical failure point during build is the anarchy of uncoordinated system transports. In multi-stream programs (Finance, Supply Chain, Logistics), consultants configuration changes simultaneously in a shared development environment. Without ironclad governance, one stream's transport package will silently overwrite another stream's settings, resulting in constant regression loops during unit testing.

To secure this seam, direct configuration in shared test clients must be frozen. You must establish a weekly cross-stream transport synchronization board. Before any configuration package or custom workbench object is promoted to the QA environment, it must be cross-checked against an automated dependency matrix. No transport affecting global organizational elements—such as company codes, charts of accounts, or global plant matrices—can be moved without multi-stream sign-off.

The business seam: The latency of the unanswered query

The build phase cannot operate in a vacuum; it requires continuous business arbitration. As developers write code and consultants configure processes, they inevitably encounter gaps that the initial design phase missed. This is where the business seam is tested.

When a developer in an offshore factory hits a logical contradiction in the spec, they open a ticket. If the local functional team takes three days to review it, and the business process owner takes another week to provide a decision, that single ticket introduces ten days of latency. Multiply this by three hundred active development objects, and your build schedule is mathematically destroyed.

The offshore factory does not wait idly. To meet their contractual execution metrics, they will either guess the business logic—introducing deep functional debt—or pause the development and reassign the resource. When the answer finally arrives, the developer has moved on, and re-boarding them costs another three days.

Securing the business seam requires a dedicated, daily arbitration ritual:

1. The 24-Hour SLA: The functional stream leads and business counterparts must commit to an ironclad SLA: any technical query raised by the factory must be resolved or formally arbitrated within 24 hours.
2. No Placeholders: If a business decision cannot be made instantly, the functional lead must enforce a temporary "standard path" configuration rather than allowing the development block to stall.

The organizational seam: The junior trap and stream authority

The final, and most sensitive, seam is organizational. It defines how human beings communicate across boundaries of geography, seniority, and contractual incentives.

The typical integrator model relies heavily on pyramid leverage: a highly experienced, articulate partner sells the project, a couple of senior architects design it, and an army of junior offshore developers actually builds it. This creates an immediate organizational seam. If a junior developer is left to code complex financial reclassification logic without direct senior oversight, they will deliver an object that passes its basic "happy path" unit test but crumbles under volume or real-world integration data.

You cannot prevent the use of junior resources—it is the economic reality of large system integrators. However, you must actively police the seam. Enforce mandatory, peer-reviewed code checks and buddy-programming systems where a senior architect signs off on the technical architecture before a single line of custom code is finalized.

Protecting stream authority against director short-circuiting

The organizational seam also breaks at the top. When a program timeline tightens, the Program Director is tempted to short-circuit the hierarchy. Seeing a delay in the Finance stream, the director may bypass the Finance Stream Lead and speak directly to the technical factory manager to demand acceleration.

This is a structural mistake. By short-circuiting the stream lead, the director destroys their authority and breaks the transmission of functional command. The factory manager accelerates execution by cutting corners on documentation and unit testing, and the stream lead stops taking accountability for the final quality. The Program Director's job is not to manage the technical factory; it is to protect the stream lead's authority, ensuring they have the space and the senior resources to enforce quality control at the seam.

What the build really is

When you step back from the spreadsheets and tracking tools, the build phase stops looking like a technical execution stage where teams simply produce software objects. It is revealed for what it truly is: a continuous chain of human and system handoffs. The configuration and the custom code are rarely where the project fails; the seams between them are.

Distributed delivery does not invent these structural flaws; it merely exposes them by injecting geographical distance, cultural friction, and ticketing latency into the most fragile parts of the architecture. Running a successful build is not about fighting for flawless human perfection in every box. It is about protecting the arrows between the boxes: a functional specification that leaves no room for guessing, an arbitration process that answers in hours rather than weeks, a landscape governance that stops transport conflicts before they happen, and a senior engineering oversight that never lets a junior code alone.

Whatever is built during this phase, whether sound or fragile, must now be rigorously proven before the enterprise can risk its operations. That is where the next chapter takes us: Testing — Proving the system works before you turn it on.