Five Systems, One Process, No Owner
(08)
Overview
Every large institution has a process rebuilt five times: once per system, once per team, because nobody was ever assigned to own it end to end. Layering technology on top doesn't fix that. It just automates the duplication faster.
Year
2026
Industry
Capital Markets / Operating Model
Challenge
A new product launches across five systems: one for booking, one for client onboarding, one for reconciliation, one for reporting, one for settlement. Five different teams each build their own version of the same underlying process, check the client's status, confirm the trade, reconcile the position, because nobody upstream decided who actually owns that process end to end. This isn't a technology gap. It's an org-design failure that technology just makes more visible. The pattern repeats almost identically across large institutions. A new business initiative gets approved. The business case names a booking model, a control model, a capacity plan. What it almost never names is a single owner for the processes that now have to run across those five systems. Each team inherits their piece, builds what makes sense for their system, and moves on. Six months later, you have five slightly different versions of "confirm the client is who they say they are", each with its own logic, its own exceptions, its own failure points. Nobody planned this. It happened because the org chart is built around systems and reporting lines, not around the process itself. Five systems means five owners, and five owners means five processes, even when the underlying work is identical. Then someone asks, "can we speed this up?" And the honest answer is sure, you can automate all five versions. You'll have five faster, more expensive, still-divergent processes instead of five slow ones. The duplication was never a speed problem. It was a design problem, and speed doesn't fix design. I've seen this exact shape play out in new business launches inside global banks. A new product gets approved, and the operating-model work focuses on entity, booking, and capital: the visible, board-level decisions. The cross-cutting processes that have to run underneath all of it get inherited by whichever team happens to be closest, one system at a time. Nobody owns the process. Everybody owns a piece of it. The tell is simple: if you ask "who owns this process end to end," and the honest answer takes more than one sentence, you have a duplication problem, not an automation opportunity.
Impact
Fixing this doesn't start with a tool. It starts with a decision: who owns this process, across every system it touches, before a single line of automation gets built. That decision is uncomfortable, because it means someone gives up control of "their" version of the process, and someone else takes on accountability for a process that spans systems they don't fully control. This is exactly the kind of assumption that gets deferred in new business launches — the same way booking model and capacity planning get deferred until month three, ownership of cross-system processes gets deferred until it's someone's emergency. The fix is sequencing, not tooling. Name the single owner first. Redesign the process around that owner, not around the five systems it currently touches. Only then does automation make sense — because now you're automating one process, not accelerating five divergent ones. This matters most for the cost and risk side of the ledger. Five duplicated processes mean five sets of controls, five places for something to go wrong differently, and five teams' worth of headcount doing work that one well-designed process could absorb. That's real cost sitting in plain sight, and real risk, because divergent processes fail in divergent, harder-to-catch ways. A control gap in one of five versions doesn't show up in the other four, so nobody notices until it's already cost you something. The org-design work is the unglamorous part. Nobody gets credit for deciding who owns a process, they get credit for shipping the new product. But the product that ships on top of five divergent processes doesn't consolidate anything. It just makes five different mistakes happen faster, in parallel, at scale. If you're evaluating a new business launch and you can't name the single owner of a cross-system process, don't reach for a tool yet. You don't have an automation opportunity. You have an org-design decision that hasn't been made, and no tool fixes a decision nobody's made