Multi-pillar — running ERP and CRM in parallel

The dual-pillar decision is taken in Pre-Programme

Whether to run dual-pillar is a strategic scope decision, surfaced in Vision & Strategy (S1) and embedded in the Case for Change and Benefits Map at Value Definition & Case for Change (S2). The benefits map either includes CRM-driven outcomes or it doesn't. If it does, the CRM pillar is in scope from the first day of the programme. If it doesn't, the CRM pillar isn't a sequel.

SIs raising "should we add CRM?" at Discovery (S11) is a sign Pre-Programme wasn't done properly. By S11 the Funding Envelope (S6) has been Board-approved against a benefits case that didn't include CRM benefits, and the SI ROM at S9 has been priced against a single-pillar scope. Adding the CRM pillar at S11 means re-baselining the business case and almost certainly re-running Gate 1.

Single SI is mandated

One SI for both pillars is the right answer and should be mandated in the RFP. Keystone assumes a single SI throughout. Different SIs for ERP and CRM turns the integration boundary into a contractual boundary, and integration defects become a commercial finger-pointing exercise rather than a delivery problem to solve.

Two-SI setups happen — preferred-supplier estates, weak CRM practices at the chosen ERP SI — and they are materially harder to govern. The client carries more of the integration architecture risk directly. The methodology is set up for the single-SI case; if you're operating two-SI, you're working in heavier conditions.

Team structure — one Programme Manager, two Project Managers

One Programme Manager owns the whole transformation. Two workstream-level Project Managers — the ERP Project Manager and the CRM Project Manager — report to the Programme Manager and own day-to-day delivery within their respective pillars.

This reinforces the existing Keystone distinction: Programme Managers are not Project Managers. The Programme Manager owns strategic alignment, governance, benefits realisation, and the Steering Committee. The two workstream Project Managers run the build, test, and deploy mechanics within their pillar, against the same methodology and the same gates.

Roles that are single across both pillars

The following roles are mandatory single-headcount, even in dual-pillar:

• Programme Manager — one. Cross-pillar accountability for the whole transformation.
• Solution Architect (Client side) — one. Cross-pillar accountability for design integrity, even if technical specialists exist per pillar.
• Data Architect — one. Owns master data ownership decisions across both pillars (see below).
• Client Test Manager — one. Mandatory. Covers both pillars and the integrations between them. Two Test Managers means two test plans, two defect triages, and integration defects no-one owns.
• Change Lead — one. Users straddle both systems; the change story can't be told in two halves.

Integration Lead — earlier and more visible on dual-pillar

The Integration Lead exists on single-pillar medium+ programmes (it sits in the role catalogue on Roles & governance). On dual-pillar it's mandatory regardless of size, engages from Discovery (S11) onwards, and owns the synchronisation framework (Dual Write in D365, equivalents elsewhere) as well as the wider integration estate. Reports to the Solution Architect. Co-chairs an Integration Working Group with the SI Technical Lead during S11–S14.

Where the role isn't staffed, the Solution Architect tries to cover it, doesn't have time, and integration defects pile up at the boundary — particularly at the ERP ↔ CRM seam.

Master data ownership — workshopped, not assumed

The default position: ERP leads on customer, product, and finance master data. Finance functions tend to want ERP as the system of record, and the financial controls argument is strong.

But this is workshopped, not assumed. Master data ownership is a Solution Design (S12) decision, taken on SI advice and based on the specific business model. A B2B distributor selling through CRM-driven sales motions may want Customer originated in CRM with sync to ERP. A manufacturing business with strong finance discipline may want everything originated in ERP. The methodology says: workshop it properly in Discovery (S11) and Solution Design (S12), document the decision in the Architecture Decision Record, and don't let either pillar quietly assume ownership.

Dual Write is a Solution Design decision, not a build-time detail

Dual Write — Microsoft's framework for syncing entities between F&O and CE — is not a technical detail the SI configures during Build (S13). It is a Solution Design (S12) architectural decision that the Design Authority signs off, recorded as an Architecture Decision Record (ADR). The same applies to the equivalent integration framework on any other dual-pillar pairing.

The S12 decision covers:

• Which entities are sync'd. Customer, Product, Currency, etc. Not everything needs syncing.
• Which side is the system of record for each entity. Per the master data discussion above.
• Synchronous vs asynchronous behaviour per entity. Sync for things that must be consistent in real time; async for things that can tolerate eventual consistency.
• Failure handling. What happens when Dual Write breaks — both technically (queue, retry, alert) and operationally (do users keep working, or stop?).
• Performance characteristics under expected load. Volume tested, not assumed.
• Monitoring and alerting. Who notices when a sync has stalled, and how quickly?

By Build (S13) these decisions need to be in the ADR. Changing them later is expensive — both in re-build cost and because integration defects discovered in SIT are usually traceable back to a Dual Write decision that wasn't formally taken.

Integration testing — one SIT, with timing nuance

The default position is one System Integration Test covering both pillars and the integrations between them. Two SITs — one per pillar — followed by a separate integration test phase invites the worst of both worlds: defects discovered late, ownership unclear, no single body of evidence the integrations work end-to-end.

Timing is the honest difficulty. A single SIT requires both pillars to be build-complete in roughly the same window, and that's not always achievable. Two valid alternatives:

• Parallel development with phased go-live (ERP first, CRM second). The SIT for ERP happens at its natural point. Integration testing for the ERP ↔ CRM boundary happens later, before CRM go-live, and is backwards-compatible — i.e. CRM must integrate cleanly with the already-live ERP.
• Big Bang with combined SIT. Both pillars build to the same date. Single SIT covering everything. Higher risk, higher reward, requires the organisation to absorb more change at once.

Which approach is right depends on the organisation's capacity for change. Keystone doesn't pretend there's one answer.

Go-live — situational

Same go-live date for both pillars or phased — depends on the organisation. The decision is driven by:

• Capacity for change in the user community. Big Bang is harder on users.
• Operational risk tolerance. Phased reduces blast radius if something goes wrong.
• Benefits-realisation timing. Some benefits only land when both pillars are live; phasing delays them.
• Integration complexity. More integrations, with more cross-pillar dependencies, argue for phased.

What's not negotiable: whichever approach is chosen, the cutover plan must account for integration state during the gap. If ERP goes live first, CRM continues to run on legacy until its own go-live, and the ERP ↔ legacy-CRM integration must be supported during that window. This is often where phased go-lives go wrong — the "temporary" integration to legacy CRM becomes a permanent operational tax, because no-one budgeted for the work to dismantle it.

Infrastructure

Both pillars on the same Azure tenant, with shared Lifecycle Services environment management and aligned One Version update cadence. Different tenants or fragmented environment management produces unnecessary integration friction during testing and ongoing operations — and it's friction the methodology can't fix from the outside, because it's been baked into the technical estate before the build started.

Common mistakes — multi-pillar specific

A consolidated list, several of which are flagged in context above:

• Treating CRM as the faster, lighter sub-project. The pull is understandable — CRM modules feel more configurable than ERP, and parts of the SI market position the CRM stream as quicker, lighter, and well-suited to a more iterative delivery pattern. In practice, the failures attributed to "ERP being slow" on dual-pillar programmes are typically integration defects discovered late, because the CRM workstream arrived at integration-test readiness behind schedule with un-tested integration logic. Apply the same methodology, the same gates, and the same test discipline across both pillars.
• Two methodologies for one client. The client cannot govern two methodologies in parallel. Pick one and apply it across both. Keystone is the one to pick.
• Customer master ownership not formally decided. Both pillars create customer records "for now". Reconciliation later becomes archaeological.
• Dual Write tested only in SIT. Should be tested at every layer — FAT, SAT, SIT — with realistic data volumes and failure scenarios.
• Integration Lead role not staffed. Solution Architect tries to cover it. Doesn't have time. Defects pile up at the boundary.
• Treating the synchronisation framework as configuration, not architecture. Dual Write (or its equivalent) is an architectural decision. Ratify it in S12; don't discover it in S13.