Personal Portfolio · Case Study
Adeyinka Badmus

Business Orchestration & Operating Model Transformation

How I approached fragmented workflows as an operating model problem, connecting process, accountability, governance and technology around the way work needed to move.

My Contribution Diagnosis · Operating Model Design · Process Design · Governance
Transformation Context Business Orchestration · Workflow · Technology Enabled Change
Judgement Applied Decision Rights · Controls · Human Accountability · Implementation
The Problem

I Did Not See This as an Automation Problem

Work depended on people moving between systems, translating requests, coordinating handoffs and determining what needed to happen next. Individual activities could be completed, but the end to end journey remained fragmented.

It would have been possible to approach this as a technology problem and automate individual steps. My concern was that this could preserve the underlying fragmentation while simply making parts of it faster.

My starting point was therefore not, “What can we automate?”
It was, “How should this work operate before we decide where technology belongs?”
My Diagnosis

Four Things Changed How I Framed the Problem

01

The Handoffs Were Symptoms

Manual coordination was visible, but removing individual handoffs would not necessarily solve the underlying problem. I needed to understand why those handoffs existed and what responsibility, decision or system boundary each one represented.

02

User Intent and System Activity Were Different Things

What a person wanted to achieve was often much simpler than the sequence of activities required across systems. Separating the intended outcome from the current execution path created room to rethink the process rather than reproduce it.

03

Accountability Could Not Disappear Into Automation

Some activities were suitable for automated execution. Others involved approval, exceptions, material risk or judgement. I treated that distinction as an operating model decision rather than simply a technical capability question.

04

Governance Needed to Move With the Work

If controls, evidence and approvals remained separate from the workflow, the redesigned process would still depend on parallel governance activity. I therefore considered control points as part of the operating process itself.

Design Judgement

The Decisions That Shaped My Approach

My approach drew on programme governance, process design, technology delivery and quality assurance. I was looking for a model that could work operationally, remain controlled and still be implemented through technology.

01

Start With the Outcome

I centred the design on what the user was trying to achieve rather than treating the existing systems and process steps as fixed constraints.

02

Redesign Before Automating

I separated necessary work from activity that existed because of historical processes, system boundaries or manual coordination. Automation would support the redesigned journey rather than reproduce the old one.

03

Make Ownership Explicit

I considered who owned initiation, execution, approval, exceptions and outcomes so that greater automation did not create less accountability.

04

Define Decision Rights

I distinguished activities that could progress within predefined authority from decisions requiring explicit review or approval.

05

Build Controls Into the Journey

Permissions, evidence, approval and traceability were considered within the execution path so governance did not become a separate administrative layer around the process.

06

Design for Exceptions, Not Only the Happy Path

A workable operating model needed to account for uncertainty, failed actions, unusual requests and situations requiring human intervention rather than assuming every transaction would progress normally.

Experience Applied

Four Parts of My Background Came Together

The operating model was shaped by more than process design. Different parts of my delivery background influenced what I looked for and the questions I asked.

01

Programme Governance

Who owns the decision, what authority applies, what needs escalation and how does accountability remain visible?

02

Process & Operations

How does work actually move, where does friction occur and which activities genuinely contribute to the outcome?

03

Technology Delivery

Where can systems remove friction, coordinate execution and support the redesigned process without dictating it?

04

Quality & Assurance

What could fail, how would we know, what evidence should exist and where does human validation remain necessary?

Connecting the Model

Maintaining a Line of Sight From Intent to Evidence

I wanted the operating model to preserve the relationship between what someone intended to happen, who was accountable and what actually occurred.

01

Intent

What outcome is required?

02

Workflow

What needs to happen?

03

Ownership

Who is accountable?

04

Decision

What authority or judgement applies?

05

Execution

What should technology or people do?

06

Evidence

Can we show what happened and why?

That continuity mattered because orchestration could reduce manual interaction without reducing visibility, control or accountability.
Operating Model Mindset

Four Questions I Kept Returning To

01

Does This Activity Need to Exist?

Challenge whether each step contributes to the outcome or simply reflects the way the process historically operated.

02

Who Remains Accountable?

Ensure ownership remains explicit even when technology performs more of the underlying execution.

03

Where Is Human Judgement Necessary?

Preserve review and approval where risk, exceptions or consequential decisions require accountable judgement.

04

Can We Evidence What Happened?

Maintain traceability between request, decision, execution and outcome so greater automation does not reduce assurance.

I do not start operating model transformation by asking what technology can automate.

I start by understanding how the work should operate, who should own it, where decisions belong and what controls are required. Technology can then remove friction from a model that has already been deliberately designed.

Outcome

What My Contribution Helped Establish

Transformation Risk

Existing inefficiency could be reproduced through automation
Ownership could become less visible as execution became automated
Technology boundaries could continue defining the workflow
Governance could remain separate from everyday execution
Exceptions could expose gaps in an apparently efficient process

Capability Established

Workflow organised around intended business outcomes
Clearer ownership and decision rights across execution
Explicit points for human judgement and approval
Governance, controls and evidence embedded within the workflow
Technology positioned as an enabler of the operating model
The contribution was not simply process redesign or automation. It was bringing process, governance, technology and accountability together as one operating model problem.
Capability Evidence

What This Case Study Demonstrates

01

Operating Model Thinking

Looking beyond individual processes to understand how people, decisions, controls and technology work together.

02

Process Transformation

Challenging existing workflows and redesigning work around the required business outcome.

03

Governance & Decision Rights

Defining ownership, authority, approvals and accountability within the operating process.

04

Technology Translation

Connecting business intent to technology enabled execution without allowing technology to dictate the operating model.

05

Quality & Assurance

Considering exceptions, evidence, traceability and validation as part of the design rather than after implementation.

06

Transformation Judgement

Balancing efficiency, automation, control and human accountability rather than optimising any one dimension in isolation.

Personal Portfolio

Explore More of My Transformation Work

Return to my portfolio to view selected work across AI transformation, enterprise technology, programme governance and operating model transformation.

Back to Portfolio