← All Guides Technology & Systems
Full guide in Portal →
Methodology Guides/Technology & Systems
💡
OM Layer 03 — Operating Model

Technology & Systems.

Technology that serves the operating model — not the other way around. Architecture decisions made after process design, not before it.

Full practitioner methodology in the CN Portal Log in →
The key principles

How CN approaches this work.

01
Operating model first, technology second
The most expensive mistake in transformation is selecting technology before designing the operating model. System configuration embeds process assumptions. If those assumptions are wrong — because the process was not designed before the system was selected — the organisation is locked into the legacy process by the new system.
02
The system must serve the process, not define it
When a system is implemented, there is always pressure to configure the process around the system's default workflows rather than configuring the system to support the designed process. This is the technology tail wagging the operating model dog. Resisting it requires the process design to be completed and locked before system configuration begins.
03
AI adoption is a change problem, not a technology problem
Most AI transformations stall not because the technology does not work but because the organisation was not designed to adopt it. The workflows were not redesigned. The managers were not enabled. The informal leaders decided — in the corridor — that it was optional. AI adoption requires a change programme, not a deployment project.
04
Legacy retirement is as important as new capability
Organisations accumulate systems. Every system has a constituency that depends on it, workarounds built around its limitations, and informal processes that do not exist anywhere in the documentation. The decision about what to decommission requires as much rigour as the decision about what to build.
05
Data architecture is an operating model decision
Where data is created, where it lives, how it flows to where it is needed — these are operating model decisions, not IT decisions. Data architecture that is not designed as part of the operating model will not support the management information the operating model requires.
What good looks like
  • ✓Technology selection made after process and people design is complete
  • ✓System configuration reflects the designed process, not the legacy one
  • ✓AI adoption designed as a change programme from day one
  • ✓Data architecture designed to support the MI framework
  • ✓Legacy decommissioning plan in place before new system goes live
  • ✓Technology change management running alongside technical implementation
Warning signs
  • ✗ERP selected before operating model is designed
  • ✗Process redesigned around system defaults rather than business requirements
  • ✗AI tools deployed without change programme — becoming shelfware
  • ✗Legacy systems retained indefinitely alongside new ones
  • ✗Data architecture treated as an IT decision separate from the operating model
  • ✗Technology adoption measured at go-live rather than month 12
Diagnostic questions

Use these in client conversations or team reviews to quickly surface where the real issues are.

QWas the process designed before the system was selected — or did the system selection define the process?
QFor each AI tool deployed: what is the month 12 adoption rate, and what was the change programme that drove it?
QWhich legacy systems are still running alongside the new platform, and what is the decommissioning plan?
Full Practitioner Guide

The complete methodology is in the CN Portal.

The full guide covers: technology-to-operating-model sequencing, system selection criteria framework, AI adoption programme design, legacy assessment methodology, data architecture principles, configuration governance, and the change management approach for technology transformation.

Access Portal Join the network