SAFe, ITIL and the Multi-Vendor ERP Trap : How to Stay in Control Without Killing Delivery

SAFe and ITIL in an ERP Project : Two Distinct Roles, Not Two Options

SAFe (Scaled Agile Framework) is a scaled delivery framework. Its core principle: teams organised in 10-to-12-week cycles — Program Increments (PIs) — deliver functional increments, provided dependencies are plannable. That means visible, stable, and resolvable within the cycle's cadence.

ITIL is a framework for managing IT services in production. Its validation body is the CAB (Change Advisory Board), which controls what goes into production independently of the development team's delivery rhythm.

These are not alternatives. They are two distinct scopes: SAFe governs the Build (creating), ITIL governs the Run (stabilising). Mixing them without a clear contractual boundary creates exactly the conditions for a gridlock.

The Three-Party Trap : Why Three Parties Produce One Loser

In a Teamcenter–SAP CRM integration project with partial cloud migration, the three actors had structurally incompatible agendas.

The software vendor manages its own version roadmap. It controls access to the technical specifications of its connectors — not out of bad faith, but because this is a structural competitive advantage built into its business model. The more integrations run through its native tools, the longer the client relationship lasts. This is openly documented by SAP practitioners: ecosystem partners are incentivised to recommend the vendor's proprietary middleware, which consolidates technical dependencies — and contracts. [Confirmed — practitioner community, r/SAP, 2023]

The system integrator / AMS provider (Application Management Services — the equivalent of what French contracts call TMA, Tierce Maintenance Applicative) is remunerated on a volume of billable hours. Their incentive is not velocity — it is complexity. Broad user stories, partial specifications, unresolved dependencies: all of this justifies high charge estimates and change requests on every waiting ticket.

The client is caught between the two, with no contractual leverage over the vendor's specifications or the integrator's cadence. They pay for motion, not results.

Key #1 — Define the Contract Before Choosing the Method

The first mistake is selecting SAFe or ITIL before defining the contractual scopes. A methodology cannot compensate for absent governance — it makes it worse by giving it the appearance of rigour.

Three scopes must be contractually separated before signing, never after the first deadlock:

• Vendor support: incidents, security patches, version upgrades. Every commitment must include enforceable response SLAs and documented conditions for access to technical specifications — particularly for third-party connectors and integration interfaces. This scope belongs to ITIL, not SAFe. It must never enter a sprint backlog.
• Evolutionary AMS: custom developments, new integrations. This is where SAFe applies — provided user stories can be specified independently of the vendor's roadmap. The definition of "done" must be contractually enforceable: a story cannot be declared delivered if its validation depends on an interface that is not yet stable.
• Integration project: delivery milestones and — critically — vendor dependencies documented and contractualised: response times for specification requests, upgrade conditions, connector access. Without this framework, a vendor-triggered upgrade mid-project becomes a global deadlock trigger.

Key #2 — Understanding Why Agile Fails Without Control of the Code

SAFe — like all Agile methods — rests on a prerequisite that is rarely stated explicitly: teams must be able to specify what they are going to build. That means having access to interfaces, data schemas, and business rules — enough to break down a requirement into user stories with verifiable acceptance criteria.

In a multi-vendor ERP project, that condition is not guaranteed. A connector — the software component that allows two separate systems to exchange data (in this case, making Teamcenter and SAP talk to each other) — is technically an interface: a data exchange contract with its own rules, formats, and constraints. In practice, this takes several forms: a REST API (the most common today — system A sends a request, system B responds with the requested data), a SOAP service (an older standard, still widely present in legacy SAP and Teamcenter environments), or proprietary exchange formats such as SAP IDocs (Intermediate Documents — structured formats SAP uses for exchanges between modules and third-party systems). Each has its own structure, authentication, and versioning rules. When the specifications of these interfaces are controlled by the vendor and only partially shared with the integrator, you cannot accurately estimate what you cannot specify. A user story then becomes a charge envelope — a container for billable hours, not a delivery commitment.

The consequences for Agile mechanics are direct:

• The backlog is not controlled by the project team — it is partly dictated by the availability of technical information from the vendor.
• The definition of "done" becomes unenforceable: a story cannot be declared complete if its validation depends on an interface whose specifications may change at the next version.
• Velocity measures activity, not value delivered. Sprints complete, burn-down charts look healthy, nothing reaches production.

The solution is not to abandon SAFe — it is to restrict it to the scope where those prerequisites are met, and to contractualise access to specifications before the first sprint begins.

Key #3 — Configure the CAB to Protect, Not to Block

In this project, the CAB was treating two fundamentally different types of change identically:

• A security patch: low risk, mandatory, should be fast-tracked and approved within 48 hours.
• A custom module deployment: high risk, requires a full review with integration testing.

Processed in the same queue, critical patches waited weeks. Meanwhile, the integrator billed each waiting ticket as a change request.

This dysfunction has an underlying architectural cause: customisations had been integrated directly into the application core rather than placed on a stable extension layer. As a result, every change touched the same components, making CAB differentiation practically impossible.

This is where the two levels of decision — architecture and governance — converge: a customisation patched into the application core creates a dependency that neither SAFe nor ITIL can absorb. SAFe cannot plan a backlog whose specifications change with every vendor roadmap release. ITIL cannot distinguish a security patch from a custom deployment if both touch the same components. Architecture determines whether the Build/Run separation is governable at all. This must be assessed before signing — not discovered at the first upgrade.

A properly configured CAB has at minimum two tracks: a fast-track for low-risk, limited-impact changes, and a full review track for high-impact or broad-scope changes. This differentiation must be documented in the vendor support contract — not left to the discretion of a committee convened in crisis mode.

Already Under Contract? Don't Miss the Renegotiation Window

Everything above applies ideally before the contract is signed. But field reality is different: many CIOs will read this article already committed — an AMS contract in progress, an active vendor support agreement, an integration project that started without this separation.

In that case, three opportunities not to miss:

• Contract renewal is the primary renegotiation window. An AMS or vendor support contract coming up for renewal is the opportunity to reset scopes, introduce differentiated SLAs, and require documented access to interface specifications. Do not let a tacit renewal carry the same structural flaws forward.
• Timeline synchronisation is routinely underestimated. If your AMS contract renews in June and the vendor roadmap has an upgrade scheduled for September, the renegotiation window is before June — not after the upgrade. Mapping the key dates of every contract and every vendor roadmap allows you to anticipate friction points rather than absorb them at each cycle.
• A documented incident is also leverage. A recorded deadlock — an upgrade that paralysed the project, a critical patch stuck in a CAB queue for weeks — constitutes a concrete contractual argument for renegotiation. Document the impacts, delays, and costs systematically.

The message is simple: if you cannot act before signing, act at the next contractual window. And if that window is not yet visible, start by mapping it.

What This Means for Your ERP Programme

Is your multi-vendor ERP programme being governed — or endured?

If your sprints produce activity without results in production, if your CAB holds up critical patches alongside custom deployments, or if your integrators are billing for waiting rather than progress — the problem is neither SAFe nor ITIL. It is the absence of contractual separation between Build and Run, established before the programme begins.

These friction points are predictable. A free governance diagnostic identifies them and helps contractualise them before they become billable deadlocks. If you want to understand the broader framework first, our digital transformation consulting page details our intervention model.