Our Process Knowledge Is Fragmented and Untrusted

Host: Okay, quick exercise before we start. Think about the last time you needed to check how a process actually works. Not guess, not ask around, actually check it.

Co-host: Where did you go?

Host: That's the thing. I genuinely don't know where I'd go first. Is it the Visio diagram from two reorgs ago? Is it a SharePoint site somebody built and then left the company? Is it a spreadsheet that lives on one person's desktop?

Co-host: Or is it just messaging the one person who's been there twelve years and asking them.

Host: Right, the human search engine. And that's exactly the mess we're getting into today.

Co-host: This is the second piece in the series, and it picks up right where the last one left off.

Host: Last time was about processes being documented as opinions rather than operational fact. Today's source document takes that a step further and asks a different question.

Co-host: Even if you had the truth, could you actually find it?

Host: Exactly. The title on this one is blunt. Our Process Knowledge Is Fragmented and Untrusted.

Co-host: No hedging in that title either.

Host: None. So let's set the scene. The source describes content existing across Visio, SharePoint, SOPs, spreadsheets, and individual knowledge.

Co-host: Five different formats, five different owners, and usually five different answers to the same question.

Host: And this becomes most visible, the source says, when decisions have to cross functions, systems, or organisational boundaries and no single owner can supply a trusted answer.

Co-host: Which is precisely the moment you need the answer most. Nobody goes looking for the authoritative process map on a quiet Tuesday for fun.

Host: You go looking when there's an audit tomorrow, or a system's about to be retired, or a new hire needs to be onboarded onto a process nobody's written down properly in years.

Co-host: And that's when you discover the real problem isn't that the documentation doesn't exist. It's that too much of it exists, and none of it agrees.

Host: That's a sharper way of putting it than I expected. Walk me through why that happens.

Co-host: Because every team solves its own local documentation problem in isolation. Finance builds a SharePoint site. Operations keeps a folder of SOPs. A project team draws a Visio diagram for one initiative and never touches it again after go-live.

Host: Each one true enough for the person who built it.

Co-host: Right, and each one abandoned the moment the immediate need passes. Nobody's job is to keep it current. So versions conflict, ownership goes stale, and eventually people just stop trusting the central content altogether.

Host: Which is the real damage here. It's not just clutter, it's a trust collapse.

Co-host: Exactly the phrase the source uses. Once people stop trusting the repository, they stop using it, and once they stop using it, they go back to asking a person. And now you're right back to tacit knowledge.

Host: The problem the first episode was about.

Co-host: It's the same disease showing up in a different organ. Underneath both is the same underlying weakness: the absence of a governed, connected, and queryable representation of the operating model.

Host: Okay, I want to push on this a little. Every large organisation I've ever worked with has some kind of document management system. SharePoint, Confluence, a DMS of some kind. Isn't that the single source of truth already?

Co-host: It's a filing cabinet, not a source of truth. A document management system stores files. It doesn't tell you which of the four versions in that folder is the one currently being followed on the floor.

Host: So it solves storage but not authority.

Co-host: Precisely. You can have a beautifully organised SharePoint site full of confidently wrong documents. Storage was never the hard problem. Governance is the hard problem, and governance is what's missing.

Host: Let's talk about what this actually costs, because 'people don't trust the wiki' sounds like an inconvenience, not a crisis.

Co-host: It stops being an inconvenience the moment an audit, a change, or an incident hits. The source is direct about this: every audit, change and incident triggers a costly manual hunt.

Host: A hunt. Not a lookup.

Co-host: A hunt. Someone has to go around, gather the competing versions, interview the people who actually run the process, and reconcile it all into something an auditor or a project team can actually rely on.

Host: And then, presumably, that reconciled version doesn't get fed back into the system either.

Co-host: Almost never. It gets built for that one audit, used once, and forgotten. Which means teams recreate content constantly, and fragmentation compounds. Every hunt adds another version to the pile instead of resolving it.

Host: So the fix each time actively makes the underlying disease worse.

Co-host: That's the trap exactly. At enterprise scale, this isn't a one-off cost. Every change, audit, incident or transformation programme rebuilds the same knowledge at additional cost, over and over, department by department.

Host: I want to sanity check the scale of that. Are we talking about a mild productivity drag, or something bigger?

Co-host: Think about how many separate initiatives in a large enterprise, in any given year, each independently need to answer 'how does this process actually work'. Compliance needs it. A systems migration needs it. A new operating model design needs it. Each one is paying to rediscover the same ground truth because nobody retained the answer from the last time somebody asked.

Host: That's not friction, that's a recurring tax on the organisation.

Co-host: And a hidden one, because it's never itemised as a single line. It's buried inside a hundred different project budgets as 'discovery' or 'requirements gathering', so nobody ever adds it up and says, this is what fragmentation actually costs us annually.

Host: Okay, so what does the fix actually look like? The source moves from problem to need-payoff at this point.

Co-host: The need-payoff is a governed repository, plus what the source calls repository intelligence, working together to create a trusted, searchable operating-model source.

Host: Two separate things bundled together there. Let's take them one at a time. What does 'governed' actually add on top of just 'a repository'?

Co-host: Ownership. Every piece of content has a named owner accountable for keeping it current, and a defined lifecycle so stale content is retired instead of quietly rotting in a folder for six years.

Host: So governance is the thing that stops the trust collapse from happening again.

Co-host: Right. Without it you're just building a nicer-looking version of the same fragmented mess. And that's where repository intelligence comes in, because governance alone doesn't help you find the answer fast. It just means the answer, once found, can be trusted.

Host: So intelligence is the search and retrieval layer on top of the governance layer.

Co-host: Exactly. It's the difference between a well-organised archive and a system you can actually interrogate. You ask a question, and instead of five people in five departments giving you five answers, you get one answer, and you can see who owns it and when it was last verified.

Host: That maps onto the payoff language pretty directly. In practical terms, leaders and delivery teams can work from the same baseline, interrogate relationships quickly, and govern updates as the organisation changes.

Co-host: Which is really the whole point. The organisation doesn't just get tidier documentation. It gets a baseline everyone can build on without re-verifying it from scratch every time.

Host: And this isn't just an internal opinion, is it? The source brings in outside validation.

Co-host: Two sources. APQC notes that governance and ownership are challenging within process, knowledge and data disciplines, and become more complex when they have to be integrated across those disciplines rather than handled separately.

Host: So even the benchmarking body that studies this for a living says integrated governance is genuinely hard, not just a discipline problem inside one weak team.

Co-host: Right, it validates that this isn't a training issue you can fix with a memo. And ISO's process approach reinforces the other half: managed processes and their interactions support consistent results, performance evaluation, and continual improvement through the process approach and the PDCA cycle.

Host: Which only works if there's one process definition to manage in the first place. You can't run a Plan-Do-Check-Act cycle against five conflicting spreadsheets.

Co-host: That's the connective tissue. Continuous improvement, in the ISO sense, is structurally impossible without a trusted single version to improve against.

Host: Let's get practical. The source gives some pointed discovery questions here. First one: how many places must someone search to answer a process question?

Co-host: If the honest answer is more than one, you already have the fragmentation problem, whether or not anyone's named it yet.

Host: Second: who decides which version is authoritative?

Co-host: If that question makes people pause, or worse, if different people in the room give different answers, that's your trust collapse happening in real time.

Host: Third: how much duplicate or orphaned content exists?

Co-host: Nobody ever knows this number until they go looking, and it's always bigger than they expect. Orphaned content, remember, is content with no living owner. It's not wrong exactly, it's just unaccountable, which in practice is just as dangerous.

Host: And the two closing questions carry over from the wider pattern across this whole series. Which executive decision currently takes too long because operating-model evidence must be assembled manually?

Co-host: That's the cost of the hunt, made concrete. If your leadership team is waiting weeks for someone to assemble a trustworthy picture, that delay is the fragmentation tax landing directly on strategic decisions.

Host: And finally, what governance event causes the process baseline to be reviewed and updated?

Co-host: If there's no answer to that one, there's no governance. There's just a pile of documents that happen to still be sitting on a server, hoping nobody asks too many questions about them.

Host: So bringing this together. What's the actual shift an organisation needs to make?

Co-host: Stop treating documentation as a storage problem and start treating it as a governance and intelligence problem. A repository with a real owner for every piece of content, and a way to query it that returns one trustworthy answer instead of five competing ones.

Host: One repository, one owner per item, one queryable answer. It sounds almost too simple for how expensive the current state is.

Co-host: It usually is that simple in principle. What's hard is the discipline to actually retire the SharePoint site, the orphaned Visio file, and the spreadsheet on someone's desktop, instead of just adding one more well-intentioned system on top of the pile.

Host: Which is probably the real test for anyone listening to this. Not 'do we have a repository', but 'do we have one repository, and does everyone actually believe it'.

Co-host: That's the question worth taking into your next Monday meeting.