Strategy to Outcomes – Article Series -1

The systems delivery problem fragmentation.

Systems delivery is becoming fragmented by design. The vendor sells the software and the value promise. Partners deliver the services. Offshore teams execute work packages. AI accelerates artefact production. Project managers manage scope, tasks, risks, milestones, testing, cutover, and go-live. Success managers manage adoption, account health, retention, and expansion. Finance separates contractual obligations for revenue recognition.

Each component has a rational purpose. The vendor wants a lower cost profile, higher margin, prepaid revenue, scalable delivery, and reduced implementation risk. But the customer did not buy fragments. The customer bought an outcome. That is where the real problem begins.

Customers today need more than a software vendor. They are looking for trusted advisors who can help them interpret change, mitigate risk, and drive measurable outcomes. That expectation has elevated the role of the channel. The channel is no longer simply a route to market. It is becoming a strategic growth engine and a critical layer of value creation for customers navigating uncertainty, complexity, and operational change.

It also increases the importance of coherence. If the vendor owns the software promise, the partner owns much of the implementation service, offshore teams execute work packages, and success managers inherit the value narrative after go-live. The delivery ecosystem needs more than standard methods. It needs a shared value architecture.

Without that, the customer’s outcome can fall between the commercial model, the project model, the partner model, and the success model.

Thesis - Standardisation is the vendor’s countermeasure.

Once delivery is distributed across vendors, partners, offshore teams, project managers, success managers, and AI tools, variability becomes a commercial risk.

The vendor’s answer is standardisation. Standard methods, templates, implementation pathways, best practices, governance checkpoints, partner certifications, accelerators, and success offerings. That makes sense. A fragmented model needs standardisation. Without standardisation, the model cannot scale.

But here is the problem. Standardisation controls delivery variability. It does not automatically create business adaptability. A standardised system delivery method can progress features, functions, workflows, configurations, reports, test scripts, and training. But it won’t deliver the control mechanisms required to realise the strategic benefits.

The agility paradox

This is where the industry language becomes interesting. Systems transformation surveys often place ERP agility at the top of the objective set. In the figure below, ERP agility is shown as the leading modernisation objective, ahead of business process simplification, innovative best practices, step-by-step modernisation, and standardisation of process.

That matters because agility is not simply the ability to implement faster. In a Strategy to Outcomes context, agility is better understood as adaptation. Adaptation means the organisation can sense variation, interpret signals, review tactics, adjust operating responses, and, in some cases, reconsider strategy. That is where many organisations are not equipped to achieve their own stated objective. They say they want agility. But they do not have the #ControlRegulators needed to adapt.

The missing layer: #ControlRegulators

I call these mechanisms #ControlRegulators. They are the design mechanisms that sense variation, trigger decisions, protect constraints, guide execution, and keep ERP-enabled change connected to strategic outcomes.

Examples include finite scheduling, DDMRP, drum-buffer-rope, readiness gates, measurement systems, benefit sensors, assumption checks, and tactical review triggers. Most ERP programs standardise around features and functions. Order to cash, procure to pay, plan to produce, maintain to operate, hire to retire, record to report. But business benefits depend on regulators.

What controls release?
What senses variation?
What triggers intervention?
What protects the constraint?
What governs buffer status?
What distinguishes a metric from a signal?
What makes the system adapt when assumptions fail?

That is not standard feature and function delivery. That is operating system design. This is where standard ERP methods often become necessary but not sufficient. They may deliver the system of record, but they don’t deliver the system of control.

Agility requires signals and sensors

The objective of agility creates a deeper question. How does the organisation know when it needs to adapt? Most organisations do not have a clear answer. They may have dashboards, reports, project status packs and KPIs. But that is not the same as a measurement system that distinguishes between KPI outcomes, metric contributors, operating signals, assumption sensors, and control triggers.

 A KPI may tell the executive that performance has changed. A metric may help analyse why. A signal should indicate that variation is emerging. An assumption sensor should indicate that the logic behind the benefit case may no longer hold. A #controlregulator should trigger the appropriate response. Without that structure, agility is only a word. The organisation says it wants to adapt, but it has no designed mechanism to know when adaptation is required.

Internal and external variety

This is where Beer and Ashby become highly relevant. Ashby’s law argues that a regulator needs sufficient variety to deal with the variety of the disturbances it faces. His classic systems behavioural  law is that only variety can absorb or destroy variety. Stafford Beer’s Viable System VSM) extends this into organisational design, focusing on viability, adaptability, recursion, coordination, control, intelligence, and policy. That lens changes the ERP question. The question is; have we designed the regulatory system needed to keep the business viable as internal and external variety changes? If the ERP program has no signals and sensors to detect those changes, the organisation cannot adapt in time. It can only react after the correction window is closed.

What often gets reduced from scope

This is the uncomfortable part. The areas that most directly support benefit realisation are often the area’s most likely to be reduced, delayed, or converted into generic “future phase” language.

Deep measurement systems are replaced by reports and dashboards. But dashboards are not the same as measurement architecture. A dashboard tells you something happened. A measurement system tells you what matters, what changed, why it changed, what assumption failed, and what regulator must respond within its established tolerance range.

Standard planning systems are not supplemented by a finite scheduling regulator. One supplies the what’s required but it’s the finite schedule that supplies  the when. It’s a #controlregulator that models demonstrated capacity, queues, constraints, release timing, and due-date risk.

 If a finite scheduling #controlregulator is used, is it managing all of the resource or just the constraint. Is the constraint used as the drum that sets the pace with the buffer protecting the constraint, and the rope governing release. That’s a #controlregulator.

When standard Material Requirements Planning (MRP) logic is used, are nominated items flag with a Demand Driven MRP (DDMRP) order policy.  DDMRP is built around strategic inventory positioning, buffer profiles and levels, and dynamically adjusts based on demand-driven planning. That makes it a planning and execution #controlregulator.

Best practice is usually a pattern of execution. A regulator is a mechanism that senses variation and changes system behaviour.

The friction problem

This is why the phrase “frictionless road to value” becomes problematic. A frictionless road to value sounds commercially attractive. It supports speed, standardisation, partner scale, reduced delivery cost, and lower implementation risk. But control regulators create friction.

They require harder questions. What benefit are we actually trying to generate? What operating constraint limits that benefit? What variation will threaten it? What must the system sense?
What decision must be triggered? Who owns the regulator? What is the cadence of measurement? What happens when the assumption fails? When should tactics be reviewed?
When should strategy itself be reconsidered? Those questions create friction.

They involve executives, operations, delivery teams, partners, solution architects, planners, schedulers, success managers, and finance. They cross the boundaries the vendor model has deliberately separated.

The critical thesis

If agility is the objective, where are the #ControlRegulators that make agility possible?

#StrategyToOutcomes #ControlRegulators #ERP #ERPImplementation #ValueRealisation #BenefitsRealisation #SystemsThinking #APS #FiniteScheduling #DDMRP #ManufacturingERP #DigitalTransformation