Business Consulting · Custom Software & AI Development
Dependency mapping for a regulated manufacturer — 65 critical processes, 45% of data movement done by hand
A regulated manufacturer could not answer what depended on what — for any system, process or person. We ran structured discovery across the business, modeled every answer as a dependency graph, and built the web application they now query before a migration, an outage or a resignation makes the question urgent.
65
Business-critical processes mapped
250
Data movements between systems
45%
Of that movement done by hand
The problem
What they were dealing with
Every organization runs on connections nobody has written down. In a regulated manufacturing business — where a process may carry a compliance obligation and a system may hold records somebody will later be asked to produce — that gap carries consequences beyond inconvenience.
Three questions had no reliable answer. If this system is unavailable, what stops, and for how long? If this person is away for two weeks, what stalls? If we move or retire this platform, what else has to move with it?
None of these were academic. Platform replacements were being planned with no dependency map to plan against. Knowledge of how several processes worked sat with one person each and was recorded nowhere. And critical work was running on spreadsheets and paper records that appeared on no system inventory, so no amount of looking at the IT estate would ever have surfaced them.
Answering any of it meant convening the people who might know — which took weeks, and produced a slightly different answer each time.
Constraints
What made it hard, and what we did about it
- Challenge
- Knowledge of how several processes worked sat with one person each, and was written down nowhere
- What we did
- Negative-space questioning — who is the backup, is there a written procedure, is that file backed up anywhere — asked of every department rather than inferred from an inventory, because no inventory shows an absence
- Result
- Key-person exposure registered against the processes it threatens, so coverage can be planned rather than discovered during a resignation
- Challenge
- Departments described shared processes differently, and the discrepancies were invisible from inside any one of them
- What we did
- The same core question set put to every team unchanged, with contradictions carried into the next session as its opening question rather than resolved privately between us
- Result
- Ownership of several processes clarified — including one that each of two teams believed the other ran
- Challenge
- A map that overstates its own completeness is worse than no map at all
- What we did
- Coverage stated inside the deliverable itself: every department marked interviewed, partially covered, referenced only, or not yet met
- Result
- Executives can see exactly how much of the picture they are looking at before they act on it
How it ran
The sequence
The discipline is that discovery produces structured data rather than notes. Every answer was typed as entities and relationships from the first session onward, which is why the sixth department's picture merged cleanly with the first's instead of having to be reconciled by hand afterwards.
Phase 1
Ask
Structured discovery sessions per department, built from one core question set and tailored to each team's work. Five questions were put to everybody unchanged — that is what makes separate answers comparable. Each pack was calibrated from what earlier sessions had exposed, so later sessions opened with specifics rather than generalities, and open items nobody could close traveled forward into the next session with a named owner.
Phase 2
Capture
Every answer decomposed into typed entities — people, applications, workflows, files, data flows, risks, vendors, roadmap events — in one consistent schema, one register per department. Each captured movement tagged confirmed, partial, not discussed or planned, so gaps stayed visible instead of being quietly smoothed over.
Phase 3
Connect
Entities linked by typed relationships: uses, supports, feeds, enables, system-of-record, critical dependency. Because a risk is a node rather than a sentence in a document, the business can ask which processes carry the most of it. Because a file is linked to both an application and a process, it can ask what stops if that file is lost.
Phase 4
Explore
A web application over the graph, with the Excel and Word reports generated from the same data on demand. Contradictions between departments were treated as findings rather than resolved privately, and where the client corrected a premise we had been working from, every affected deliverable was updated the same day and the correction recorded rather than quietly absorbed.
Results
What it produced
65
Business-critical processes mapped
Workflows where a failure reaches revenue or operations directly
250
Data movements between systems
Each typed by mechanism, by direction, and by how confident we were in it
45%
Of that movement done by hand
A person retyping, uploading a spreadsheet or emailing a PDF
The enterprise can now query any application, process or person and see what depends on it — before a migration, an outage or a resignation makes the question urgent.
Four executive views ship with the application. The riskiest processes, scored on a formula that is visible and adjustable rather than hidden, so the ranking stays a conversation. Where the process debt sits, by division. The business-critical files drawn as a layer of their own, with a simulation of what stops if one is lost. And a blast-radius view showing the cascade outward from any system selected.
The 45% of data movement being done by hand is not a criticism of anybody. It is a prioritized automation list with a cost already attached to each line, which is a more useful thing to hand an executive team than an opinion about efficiency.
The model was built so each further team plugs into the same structure rather than starting again. The engagement is continuing on that basis.
What the client gained
Beyond the numbers
An answer in a query, not a meeting
"What depends on this?" stops being a question that requires convening the people who might know, and stops producing a different answer each time it is asked.
Migrations planned rather than discovered
Selecting a platform due for replacement shows what has to move with it, what has to be revalidated, and what breaks first — while the program is still being planned rather than after cutover.
A prioritized automation list
The manual data movements are an inventory of automation candidates, each arriving with its departments, its volumes where known, and the risk it carries already attached.
Continuity priority derived, not assumed
Recovery sequence based on how far a failure actually spreads, feeding the continuity runbook directly instead of sitting in a document alongside it.
The hidden layer made visible
The spreadsheets, trackers and paper records that hold processes together while appearing on no system inventory, drawn as a layer between the systems and the processes they quietly support.
Deliverables that cannot drift
The Excel and Word reports are generated from the same model the application reads, so the register and the documents stay in step by construction rather than by discipline.
Related reading
The thinking behind this
More work
Other case studies
Something similar on your side?
Tell us what you run today and we will tell you what we would look at first.