ERP transformation architecture leadership
- architecture leadership not product implementation
- full arc from system selection to post-go-live stabilisation
- 0.25–1 FTE depending on programme phase
Replacing or introducing an ERP is not an IT project. It is a transformation of how the enterprise operates. Where a programme is nevertheless run as an IT project, the vendor’s template defines the scope, customisations multiply, and after go-live the old way of working continues on a new system.
We lead the programme from the business architecture side. We derive the target state and scope from the capability map, and in a greenfield implementation we fit the standard to the company, not the company to the vendor’s template. We provide a decision framework to separate standard from customisation, set business priorities for data migration, and represent a vendor-independent direction from system selection to post-go-live stabilisation.
Standard or customisation: how we decide
In a greenfield implementation the standard is fitted to the company, not the company to the vendor's template: deviation stays the exception, with a business case and approval.
When do you need us?
The vendor dictates scope and schedule
Scope and timeline come from the implementation partner's template, not from your operations. The programme follows their logic, not the enterprise's.
Customisations keep multiplying
There is no reference baseline against which to say no, so every departmental request turns into custom development. The system gets more expensive and every upgrade more risky.
The ERP programme has shrunk into an IT project
Migration and technical cutover make progress, but the transformation of operations never happens. After go-live everyone works the way they did before, just on a new screen.
Our process
Target state and scope based on capabilities
We derive from the capability map which areas the ERP covers, what stays outside, and what counts as success. Scope follows from your operations, not from the vendor's proposal.
Standard or customisation: a decision framework
In a greenfield implementation we fit the standard to the company, not the company to the vendor's template: we pick the standard solutions that match your operation. Deviation is justified where it carries genuine competitive advantage; every customisation request is measured against this framework.
Data migration with business priorities
We rank data cleansing and migration by business importance: which data sets operations cannot start without, and what can wait until later.
Vendor-independent direction across the programme
From system selection to post-go-live stabilisation we represent the business target state. Every decision is measured against your goals and rests on facts.
Let's see what this would give you.
Book a free 30-minute consultationWhat you get
- Capability-based target state and ERP scope with success criteria
- Decision framework separating standard from customisation
- Data migration priorities ranked by business importance
What it gives you
- Scope and schedule that follow from your operations, not from the vendor's template
- Customisations kept under control: deviation only where genuine competitive advantage justifies it
- Vendor-independent direction and fact-based decisions from system selection to post-go-live stabilisation
- A transformation of how the enterprise operates, not just a technical cutover to a new screen
What it looks like in practice
Covering the SCM domain in a greenfield SAP transformation
The challenge
The greenfield SAP S/4HANA private cloud programme touched the whole company, but the internal EA team's capacity did not stretch to covering the supply chain (SCM) domain. The domain that a manufacturer's operation depends on most would have been left without an owner.
What we did
We carried the enterprise architect role for the SCM domain from preparation to the start of implementation: we provided the target architecture for the domain together with the connected processes and systems, aligned with the internal EA and SCM teams, middle and senior management, and the vendors, and maintained the EA tool repository.
What came out of it
- The SCM target architecture was ready on time, together with the connected process and system picture
- The missing EA coverage filled, relieving the internal team
- The EA repository kept up to date throughout the programme
- Implementation could start with an agreed architecture and clarified dependencies
Frequently asked questions
How is this different from your Independent implementation oversight service?
Independent implementation oversight (client-side architect) provides the independent review of vendor plans and milestone control: it examines whether delivery is on track. This service sets the direction: target state, scope and decision frameworks. Together the two cover the full programme.
Is it worth starting before system selection?
Yes, ideally that is where it begins. We run the selection with the same weighted-requirements method as in our EA/BA tool selection service: the capability-based target state and scope provide the basis. Without them, proposals cannot be compared, and the vendor's template becomes the requirement.
Why are many customisations a problem?
Every customisation raises implementation cost, slows upgrades and ties knowledge to the developer. It is justified where your operations are genuinely distinctive. The decision framework separates the two on a factual basis.
Which ERP systems do you specialise in?
We are not tied to any single product: we provide business architecture leadership, not product implementation. That is exactly what makes the role work: we measure the programme against your business goals.
Our implementation is already running. Is it too late?
No. In that case we fix the target state and the decision framework retrospectively, then align the remaining phases to them. The earlier this happens, the less it costs.
How we can work together
Fix Scope
Scope and fee are agreed together at the start. For well-defined work this is the most predictable form; the business capability map, for example, typically runs this way.
Time & Material
Effort-based billing with a flexible scope. It works best when the task takes shape along the way and quick changes of direction matter.
Architect as a Service
An ongoing arrangement: architect capacity without hiring a full-time specialist. It can be fixed-price and predictable, or ad-hoc involvement; it scales up or down as needs change.
Book a free 30-minute consultation
Tell us briefly about your situation. We'll get back to you and start with a free, no-obligation 30-minute consultation.
Thank you for your message! We will get back to you shortly.
Something went wrong. Please try again or write to [email protected].
