Processes & Services: You Paid to Make the Old Way Faster

Think about the last major system your organization rolled out. New platform. New tool. New dashboards. Now ask a harder question. Six months later, was your team actually working differently? Or were they still sending the same emails, keeping the same side spreadsheets, and chasing the same approvals, just inside a more expensive system? If the technology changed but the work did not, you did not transform anything. You paid to make the old way faster.

Welcome back to Digital Transformation for Leaders, a journey from insight to strategy to execution. We are still in Phase 2, Plan the Change. This is Step 6, Processes and Services. In the last two episodes, we made two big decisions. In strategy, we chose where to compete and what to stop. In business models, we asked whether the model itself is still strong enough to hold the value we want to create. Now we reach the most practical question in the entire phase. Can your organization actually deliver any of it? Because strategy lives in a document. The business model lives in a canvas. But value is created or destroyed in one place only: in how work actually flows. This episode is about processes and services. And this is where most transformations quietly get stuck.

The BBC Spent 98 Million Pounds and Got Nothing

In 2008, the BBC launched something called the Digital Media Initiative. The goal was reasonable. Move the entire organization off physical videotape. Let staff create, share, edit, and archive content from their desktops. A fully digital production process for a media company. On paper, exactly the right ambition.

Five years later, in 2013, the BBC cancelled it. The cost to license fee payers was 98.4 million pounds. Most of it was written off as wasted. A parliamentary committee later called it a complete failure.

Now here is what most people take away from this. They say it was a technology project that went wrong. Bad vendor. Bad code. Poor oversight. But that is not the real lesson. The technology was being built around a version of the BBC’s work that did not match how the BBC actually operated. The system was being developed in one place. The people who would use it were somewhere else. And the gap between what was being built and what production teams actually needed kept growing, until the two had almost nothing to do with each other.

The independent review was direct about it. The failure had very little to do with software. It had everything to do with management, people, and the work itself. Nobody had a clear, shared view of how programs actually got made before they tried to digitize it. So they tried to automate an idea of the process, not the real one. You cannot digitize a process you have never honestly mapped. You can only digitize what you imagine it to be. And in most organizations right now, that gap between the imagined process and the real one is still there. It just has not cost 98 million pounds yet.

Everyone Owns a Step. Nobody Owns the Outcome.

Let me talk about something I am sure you are familiar with. I have seen it in almost every organization I have worked with. Take one process that crosses departments. Onboarding a customer. Fulfilling an order. Resolving a complaint. Now ask each leader where it breaks.

Your Head of Sales says the problem is in planning. Planning says the real constraint is operations. Operations says procurement never delivers on time. Procurement says the specifications arrive too late from sales. Every answer is accurate. Every answer is incomplete. Because each leader is describing the process from inside their own box. Each one can see their step clearly. None of them can see the whole thing.

And here is the part that matters. The place where the process actually breaks is almost never inside a department. It breaks in the handover between them. The moment work passes from one team to the next, with no clear owner, no agreed standard, and no single person accountable for the result the customer actually receives. Every function owns a step. Nobody owns the outcome.

So transformation projects get launched function by function. Sales improves its part. Operations automates its part. IT connects the systems. Each project is justified. Each one optimizes a piece. And the thing the customer actually experiences, the end to end flow, stays broken. If three leaders cannot agree on where one process breaks, that process does not belong to anyone.

Ask Three Leaders Where It Breaks. Watch What Happens.

If you want to find out whether anyone actually owns your key processes, here is how. Pick one process that touches at least three functions. Customer onboarding. Order to delivery. Incident resolution. Whatever matters most to your customers. Then ask three department heads the same question, separately: where does this process actually break down? Do not frame it as a meeting topic. Do not let them align first. Just ask.

You will almost always get three different answers. And each leader will locate the problem just outside their own boundary, just past where their responsibility ends. The one place nobody names is the space between them. The handover. That is the finding.

Because if every leader can describe their own step but no one can describe the whole flow, you do not have a process problem. You have an ownership problem wearing a process costume. And no system you buy will fix it. Software automates steps. It does not assign accountability. A process nobody owns end to end cannot be transformed. It can only be automated into a faster version of the same confusion. Run that test. The silence after the third answer tells you everything.

Redesign the Work First. Then Build the Technology.

Most organizations start process improvement the wrong way. They look at the systems they have. They find the gaps. They ask IT to fill them. Or they bring in a vendor who maps the process around the tool they are already selling. Neither one starts with the right question. The right question is not what does the system need. It is what does the work actually require.

That distinction is the whole point of the tool I use with leadership teams here. I call it the Process Redesign Map. It is not a process diagram for the operations team. It is a leadership tool for redesigning how work flows, before a single decision is made about which technology supports it. It works across four moves.

The first move is service to process. Start with the experience someone is trying to receive. A customer. An employee. A partner. Then expose the process that actually delivers it today, and the exact point where it visibly breaks for that person. The service is what people feel. The process is what produces the feeling.

The second move is the end to end view. Force a single picture across every department the work touches. Who supplies the input. What actually happens, step by step. What gets created. Who receives it. The goal is to find where work waits, where it loops back, and where people are quietly compensating by hand for systems that were never properly connected.

The third move is the design sequence. This is the one leaders most often get backwards. Process defines what information you need. Information defines which applications you need. Applications define the integration. Integration defines the infrastructure. If your organization buys the platform first and expects the business to bend around it, this is where that mistake becomes visible.

The fourth move is redesign or just digitize. For every active initiative, one honest question. Are we redesigning how the work happens, or are we putting a cleaner screen on a broken flow? The second one has a name. Polished chaos. The interface improves. The work does not.

The output is not a report. It is a short list of decisions. Which processes to redesign before touching a system. Which handovers need an owner assigned before automation begins. And where the organization is about to spend real money making a broken process faster.

Nineteen Days to Eight.

Let me show you what that looks like in practice. A professional services firm decides to fix its client onboarding. The experience is slow, and they know it. The plan on the table is a new CRM. Before approving it, they run the Process Redesign Map.

The service to process move shows that onboarding a new client touches four teams: sales, legal, operations, and finance. And from signed contract to active delivery, it takes an average of nineteen days. The end to end view shows where those nineteen days actually go. Eleven of them are not inside any step. They are in the gaps between steps. Approvals sitting in inboxes. Handovers with no trigger. The same client details re-entered into three different systems because no one owned the transition.

The design sequence move reveals something uncomfortable. The proposed CRM was being designed entirely around the sales team’s workflow. Legal, operations, and finance were never in the room when the requirements were written. And the redesign or digitize check confirms it. The firm was about to spend real money automating a nineteen day handover problem and call it transformation.

The CRM was not the wrong tool. The sequence was wrong. So they reversed it. They mapped the end to end service. They assigned an owner at every handover. They cut the onboarding timeline from nineteen days to eight. Then they built the system around the process they had just fixed. Same investment. Completely different result.

AI Cannot Fix a Process Nobody Understands.

There is a reason this matters more now than it did five years ago. AI and automation are being layered on top of existing processes at a speed most organizations are not ready for. And the quiet assumption in a lot of boardrooms is that AI will sort out the messy processes underneath. It will not.

AI works when a process is clearly defined, consistently run, and actually owned. When those three things are missing, AI does not clean up the mess. It runs the mess faster, at greater scale, and makes it harder to unwind.

Think about an equipment manufacturer moving to predictive maintenance. Sensors catch early signs of failure. The system checks the production schedule and parts availability. Maintenance gets planned before the machine stops. That is a genuinely better process. But it only works if someone owns the decision. If maintenance, procurement, operations, and planning each hold a different version of the truth, the sensors will produce perfect data that nobody acts on in time, because no one has the authority to act. The technology was ready. The process was not.

AI cannot optimize what the organization cannot describe. And automation cannot fix a process that nobody owns. Get the process right first. Then let AI make it faster. Not the other way around.

Five Questions Before You Automate Anything

Before your organization digitizes or automates another process, five questions are worth answering honestly at the leadership level.

First, can we describe our most critical processes in a way every leader in the room would agree on? Not the documented version. The version that actually runs weekly. Second, for each one, who owns the outcome, not a step, but the full end to end result? If the answer changes depending on who you ask, the ownership does not exist. Third, where does work actually stop moving in our most customer facing process? Not where the system slows down. Where work waits, loops back, or gets handled manually because two systems do not talk. Fourth, are we redesigning our processes, or are we putting technology on top of the existing ones? Be honest. The answer decides whether you get real return or expensive disappointment. Fifth, can our processes survive change? When a key person leaves, when a platform is replaced, when customer expectations shift. Rigid processes do not just break during transformation. They break the transformation.

These are not operational questions for the process team. They are leadership questions. The organizations that answer these before they build are the ones that do not have to rebuild.

Leadership Diagnostic

This is the end of Phase 2. Three steps. Three decisions. Three tools that leadership teams can use immediately. In Step 4, we looked at strategy: where to compete, what to win on, and what to deliberately stop. The tool was the Value Evolution Map. In Step 5, we looked at the business model: whether the way you create, deliver, and capture value is still strong enough for what is coming. The tool was the Business Model Shift Canvas. And in this step, Processes and Services, we moved from intention to reality, because strategy without process is a direction with no road. The tool is the Process Redesign Map. Three steps. Three evidence based tools leadership teams can use immediately.

Energy Is Not the Same as Clarity.

Phase 2 was about designing the change worth making. The leadership teams that did this work enter execution with clarity. They know where value is created. They know how the model needs to evolve. And they know which processes have to change before a single system goes live. The ones who skipped it enter execution with energy. Energy and clarity are not the same thing. One launches projects. The other finishes them.

Phase 3 is where the plan finally meets the organization. Not the organization on the chart. The real one. The one with people who have their own priorities, their own habits, and their own reasons to resist a change they did not design. That is execution.

And that is exactly where we go next.