Process Mapping After the Project Ends: Why Most Repositories Go Dormant
Process Mapping After the Project Ends: Why Most Repositories Go Dormant
Almost every large enterprise has paid for process mapping at least once. A programme was funded, workshops ran for several months, analysts interviewed the people who do the work, and a repository of models was delivered. Somewhere in the organisation, that repository still exists.
The question worth asking is what has happened to it since. In a large share of cases the answer is the same: the models describe an organisation that has changed, nobody has opened them in over a year, and the next time somebody needs to know how a process works they will ask a colleague instead.
This is rarely a failure of the mapping work. The models were usually accurate when they were drawn. What failed is everything that was supposed to happen afterwards, and that failure is structural rather than accidental.
The pattern, three years on
The sequence repeats with enough consistency to be treated as a default rather than a risk.
In year one the repository is current and there is visible enthusiasm. In year two a reorganisation moves two departments, a core system is replaced, and roughly a fifth of the models quietly stop matching reality. Nobody updates them, because updating them is nobody’s job. In year three a new transformation programme is scoped, the team looks at the existing repository, concludes it cannot be trusted, and commissions a fresh mapping exercise.
The organisation now pays twice for the same knowledge, and the second repository is on the same trajectory as the first.
The financial waste is the obvious cost. The more expensive consequence is that the organisation has learned, twice, that process documentation is something you produce for a project rather than something you operate.
Four structural reasons repositories go dormant
The documentation was a project deliverable rather than an operating asset. A mapping programme has a scope, a budget, an end date and an acceptance criterion, and the criterion is almost always that the models exist and have been signed off. Nothing in that definition requires the models to be used. A deliverable is complete when it is handed over. An asset is complete when it is producing value, which is a different test and a different funding model.
Nobody owns the model after go-live. There is usually an owner during the project, and the role frequently dissolves when the project closes. Without a named person who is accountable for a model matching reality, drift has no counterforce. This is one of the leadership patterns that recurs across failed BPM initiatives, and it is the one most often mistaken for a tooling gap.
The model is disconnected from the thing that runs. Where the process model lives in a modelling tool and the actual work executes in a core banking platform, an ERP, a ticketing system and a set of manual steps, changing the model changes nothing and changing the execution updates no model. Two artefacts, no link, guaranteed divergence. Where the model is executable, a change to the process is a change to the model by construction, which removes the drift mechanism rather than managing it.
There is no consumption path. This is the one that gets the least attention and does the most damage. Ask how an operations analyst finds out how a process works in most enterprises and the honest answer is that they ask someone. The repository requires knowing it exists, having access, knowing which of four hundred models is the right one, and being able to read the notation. Every one of those is a barrier, and the sum of them is why people ask a colleague instead. Documentation that is harder to query than a person will lose to the person every time.
The cost surfaces later
A dormant repository is not an isolated problem. It degrades everything built on top of it.
Automation scoping suffers first. A project scoped against documentation that is two years stale automates a flow that has already changed, and the divergence is discovered during testing, at the point where correcting it is most expensive.
Regulatory evidence suffers next. Frameworks that European enterprises now operate under, including DORA for financial entities, MaRisk in German banking, and the deployer obligations arriving under the EU AI Act, all expect an organisation to be able to describe how a process runs and demonstrate that the description is current. A repository nobody maintains is not evidence.
Process improvement suffers quietly. Analysis performed against a model that does not match the executed process produces recommendations that address a flow nobody follows. This is the same structural break that appears when process mining findings never reach the execution layer. The organisation holds a description and a reality, and the distance between them is invisible until something forces the comparison.
And onboarding suffers most predictably. New joiners learn the process from whoever is nearest, which reproduces local variation and undocumented workarounds at the same rate the organisation hires.
What separates a living repository from a dormant one
Across engagements, the repositories that stay useful share four conditions. None of them is a product feature.
A named owner per process, with authority over its design. Not the team that built the model. The person accountable for the process running correctly, who has a reason to care whether the description is accurate and the standing to approve a change.
A defined trigger for review. Models do not decay on a schedule, they decay on events: a reorganisation, a system replacement, a regulatory change, a new product. Where those events are wired to a review obligation, drift is caught close to the cause. Annual review cycles disconnected from operational events find the drift a year late.
A link between the model and execution. The strongest version is an executable model, where the artefact that describes the process is the artefact that runs it. Where that is not achievable across the whole estate, and for most enterprises it is not, the achievable version is to identify the processes where divergence is most costly and close the loop on those first.
A consumption path shorter than asking a colleague. Someone with a question should be able to get an accurate answer in less time than it takes to find the person who knows. This is where AI-assisted consumption changes the economics of process documentation, because the barrier was never that the information was missing. The barrier was that retrieving it required expertise in the repository.
That last point deserves more weight than it usually gets. For two decades the case for process documentation rested on governance and compliance, both of which are real and neither of which the average employee experiences as a benefit. A repository that answers questions in natural language is the first version of process documentation that is directly useful to the people whose behaviour determines whether it stays accurate. The incentive finally points the right way.
Explore our services for how discovery, design and automation delivery sequence in practice.
Where to start when the repository already exists
Most enterprises reading this are not starting from nothing. They are starting from a repository of uncertain accuracy, which is a different and more awkward position than a blank page.
The instinct is to remap everything. That is usually the wrong call, because it repeats the cycle that produced the current situation and it treats all processes as equally worth describing.
The alternative is a triage. Establish which processes carry real consequence, whether through regulatory exposure, revenue dependency, customer impact or operational risk. For that subset, and it is normally a small fraction of the repository, verify accuracy against what actually runs. Assign ownership. Wire the review triggers. Close the loop to execution where the divergence is most costly.
The remainder can be left alone, formally deprecated, or refreshed opportunistically. Deciding not to maintain a model is a legitimate decision. Leaving four hundred models in an ambiguous state, where nobody knows which are trustworthy, is the condition that makes the whole repository unusable.
For enterprises approaching the tooling question as part of this, the tool selection process and scoring approach covers the evaluation in detail. The sequence matters: the ownership and trigger questions are answerable before a platform is chosen, and answering them first tends to change which platform fits.
The position worth taking to the board
Process documentation has been sold to European enterprises as a compliance obligation and bought as a project. Both framings produce the same outcome, which is an artefact that is complete on the day it is delivered and declining from that day forward.
The alternative framing is that a process repository is an operating asset with a maintenance cost and a return, and that it should be funded, owned and measured accordingly. That reframing is uncomfortable because it converts a one-off capital item into an ongoing obligation. It is also the only version that has ever produced a repository still worth opening in year five.
The organisations getting value from process documentation are not the ones with the best modelling tool. They are the ones that decided what the documentation was for, gave it an owner, and made it easier to consult than the person sitting two desks away.
DNA works vendor-neutrally across ARIS, Camunda, ServiceNow, SAP Signavio and Power Automate, and recommends what is best for the client rather than what is licensed. 75% of DNA client engagements last five years or more.
Book a meeting to discuss the state of your process repository and what it would take to make it operational.
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently Asked Questions
Almost every large enterprise has paid for process mapping at least once. A programme was funded, workshops ran for several months, analysts interviewed the people who do the work, and a repository of models was delivered. Somewhere in the organisation, that repository still exists.
The question worth asking is what has happened to it since. In a large share of cases the answer is the same: the models describe an organisation that has changed, nobody has opened them in over a year, and the next time somebody needs to know how a process works they will ask a colleague instead.
This is rarely a failure of the mapping work. The models were usually accurate when they were drawn. What failed is everything that was supposed to happen afterwards, and that failure is structural rather than accidental.
The pattern, three years on
The sequence repeats with enough consistency to be treated as a default rather than a risk.
In year one the repository is current and there is visible enthusiasm. In year two a reorganisation moves two departments, a core system is replaced, and roughly a fifth of the models quietly stop matching reality. Nobody updates them, because updating them is nobody’s job. In year three a new transformation programme is scoped, the team looks at the existing repository, concludes it cannot be trusted, and commissions a fresh mapping exercise.
The organisation now pays twice for the same knowledge, and the second repository is on the same trajectory as the first.
The financial waste is the obvious cost. The more expensive consequence is that the organisation has learned, twice, that process documentation is something you produce for a project rather than something you operate.
Four structural reasons repositories go dormant
The documentation was a project deliverable rather than an operating asset. A mapping programme has a scope, a budget, an end date and an acceptance criterion, and the criterion is almost always that the models exist and have been signed off. Nothing in that definition requires the models to be used. A deliverable is complete when it is handed over. An asset is complete when it is producing value, which is a different test and a different funding model.
Nobody owns the model after go-live. There is usually an owner during the project, and the role frequently dissolves when the project closes. Without a named person who is accountable for a model matching reality, drift has no counterforce. This is one of the leadership patterns that recurs across failed BPM initiatives, and it is the one most often mistaken for a tooling gap.
The model is disconnected from the thing that runs. Where the process model lives in a modelling tool and the actual work executes in a core banking platform, an ERP, a ticketing system and a set of manual steps, changing the model changes nothing and changing the execution updates no model. Two artefacts, no link, guaranteed divergence. Where the model is executable, a change to the process is a change to the model by construction, which removes the drift mechanism rather than managing it.
There is no consumption path. This is the one that gets the least attention and does the most damage. Ask how an operations analyst finds out how a process works in most enterprises and the honest answer is that they ask someone. The repository requires knowing it exists, having access, knowing which of four hundred models is the right one, and being able to read the notation. Every one of those is a barrier, and the sum of them is why people ask a colleague instead. Documentation that is harder to query than a person will lose to the person every time.
The cost surfaces later
A dormant repository is not an isolated problem. It degrades everything built on top of it.
Automation scoping suffers first. A project scoped against documentation that is two years stale automates a flow that has already changed, and the divergence is discovered during testing, at the point where correcting it is most expensive.
Regulatory evidence suffers next. Frameworks that European enterprises now operate under, including DORA for financial entities, MaRisk in German banking, and the deployer obligations arriving under the EU AI Act, all expect an organisation to be able to describe how a process runs and demonstrate that the description is current. A repository nobody maintains is not evidence.
Process improvement suffers quietly. Analysis performed against a model that does not match the executed process produces recommendations that address a flow nobody follows. This is the same structural break that appears when process mining findings never reach the execution layer. The organisation holds a description and a reality, and the distance between them is invisible until something forces the comparison.
And onboarding suffers most predictably. New joiners learn the process from whoever is nearest, which reproduces local variation and undocumented workarounds at the same rate the organisation hires.
What separates a living repository from a dormant one
Across engagements, the repositories that stay useful share four conditions. None of them is a product feature.
A named owner per process, with authority over its design. Not the team that built the model. The person accountable for the process running correctly, who has a reason to care whether the description is accurate and the standing to approve a change.
A defined trigger for review. Models do not decay on a schedule, they decay on events: a reorganisation, a system replacement, a regulatory change, a new product. Where those events are wired to a review obligation, drift is caught close to the cause. Annual review cycles disconnected from operational events find the drift a year late.
A link between the model and execution. The strongest version is an executable model, where the artefact that describes the process is the artefact that runs it. Where that is not achievable across the whole estate, and for most enterprises it is not, the achievable version is to identify the processes where divergence is most costly and close the loop on those first.
A consumption path shorter than asking a colleague. Someone with a question should be able to get an accurate answer in less time than it takes to find the person who knows. This is where AI-assisted consumption changes the economics of process documentation, because the barrier was never that the information was missing. The barrier was that retrieving it required expertise in the repository.
That last point deserves more weight than it usually gets. For two decades the case for process documentation rested on governance and compliance, both of which are real and neither of which the average employee experiences as a benefit. A repository that answers questions in natural language is the first version of process documentation that is directly useful to the people whose behaviour determines whether it stays accurate. The incentive finally points the right way.
Explore our services for how discovery, design and automation delivery sequence in practice.
Where to start when the repository already exists
Most enterprises reading this are not starting from nothing. They are starting from a repository of uncertain accuracy, which is a different and more awkward position than a blank page.
The instinct is to remap everything. That is usually the wrong call, because it repeats the cycle that produced the current situation and it treats all processes as equally worth describing.
The alternative is a triage. Establish which processes carry real consequence, whether through regulatory exposure, revenue dependency, customer impact or operational risk. For that subset, and it is normally a small fraction of the repository, verify accuracy against what actually runs. Assign ownership. Wire the review triggers. Close the loop to execution where the divergence is most costly.
The remainder can be left alone, formally deprecated, or refreshed opportunistically. Deciding not to maintain a model is a legitimate decision. Leaving four hundred models in an ambiguous state, where nobody knows which are trustworthy, is the condition that makes the whole repository unusable.
For enterprises approaching the tooling question as part of this, the tool selection process and scoring approach covers the evaluation in detail. The sequence matters: the ownership and trigger questions are answerable before a platform is chosen, and answering them first tends to change which platform fits.
The position worth taking to the board
Process documentation has been sold to European enterprises as a compliance obligation and bought as a project. Both framings produce the same outcome, which is an artefact that is complete on the day it is delivered and declining from that day forward.
The alternative framing is that a process repository is an operating asset with a maintenance cost and a return, and that it should be funded, owned and measured accordingly. That reframing is uncomfortable because it converts a one-off capital item into an ongoing obligation. It is also the only version that has ever produced a repository still worth opening in year five.
The organisations getting value from process documentation are not the ones with the best modelling tool. They are the ones that decided what the documentation was for, gave it an owner, and made it easier to consult than the person sitting two desks away.
DNA works vendor-neutrally across ARIS, Camunda, ServiceNow, SAP Signavio and Power Automate, and recommends what is best for the client rather than what is licensed. 75% of DNA client engagements last five years or more.
Book a meeting to discuss the state of your process repository and what it would take to make it operational.
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently Asked Questions
Written by:
Nikola Dlaka
Managing Partner
Share with friends:
What is process mapping?
Process mapping is the practice of documenting how a business process actually runs, including the sequence of steps, the people and systems involved, the decision points, and the exceptions. The output is normally a set of models in a standard notation such as BPMN 2.0, held in a repository. Mapping describes the process. It does not by itself change or execute it.
Why does process documentation become outdated so quickly?
Because organisations change continuously and documentation is usually maintained on a project cycle. Reorganisations, system replacements, regulatory changes and new products each invalidate part of the repository. Where no person is accountable for keeping a model accurate and no event triggers a review, drift accumulates without resistance until the repository is no longer trusted.
How often should process models be reviewed?
Event-driven review works better than calendar-driven review. Tie the obligation to the things that actually invalidate a model: reorganisation, system change, regulatory change, product launch, or a material change in volume. A fixed annual cycle disconnected from those events tends to find drift long after it occurred.
Is it better to remap processes or to fix the existing repository?
For most enterprises, a triage is more effective than a full remap. Identify the processes with genuine regulatory, revenue, customer or operational consequence, verify those against what actually runs, assign ownership, and leave or formally deprecate the rest. A full remap repeats the cycle that produced the dormant repository in the first place.
What makes a process repository stay useful over time?
Four conditions recur: a named owner per process with authority over its design, review triggered by operational events rather than the calendar, a link between the model and the system that executes the process, and a consumption path that is faster than asking a colleague. Tooling supports each of these. None of them is created by tooling alone.
What is process mapping?
Process mapping is the practice of documenting how a business process actually runs, including the sequence of steps, the people and systems involved, the decision points, and the exceptions. The output is normally a set of models in a standard notation such as BPMN 2.0, held in a repository. Mapping describes the process. It does not by itself change or execute it.
Why does process documentation become outdated so quickly?
Because organisations change continuously and documentation is usually maintained on a project cycle. Reorganisations, system replacements, regulatory changes and new products each invalidate part of the repository. Where no person is accountable for keeping a model accurate and no event triggers a review, drift accumulates without resistance until the repository is no longer trusted.
How often should process models be reviewed?
Event-driven review works better than calendar-driven review. Tie the obligation to the things that actually invalidate a model: reorganisation, system change, regulatory change, product launch, or a material change in volume. A fixed annual cycle disconnected from those events tends to find drift long after it occurred.
Is it better to remap processes or to fix the existing repository?
For most enterprises, a triage is more effective than a full remap. Identify the processes with genuine regulatory, revenue, customer or operational consequence, verify those against what actually runs, assign ownership, and leave or formally deprecate the rest. A full remap repeats the cycle that produced the dormant repository in the first place.
What makes a process repository stay useful over time?
Four conditions recur: a named owner per process with authority over its design, review triggered by operational events rather than the calendar, a link between the model and the system that executes the process, and a consumption path that is faster than asking a colleague. Tooling supports each of these. None of them is created by tooling alone.
What is process mapping?
Process mapping is the practice of documenting how a business process actually runs, including the sequence of steps, the people and systems involved, the decision points, and the exceptions. The output is normally a set of models in a standard notation such as BPMN 2.0, held in a repository. Mapping describes the process. It does not by itself change or execute it.
Why does process documentation become outdated so quickly?
Because organisations change continuously and documentation is usually maintained on a project cycle. Reorganisations, system replacements, regulatory changes and new products each invalidate part of the repository. Where no person is accountable for keeping a model accurate and no event triggers a review, drift accumulates without resistance until the repository is no longer trusted.
How often should process models be reviewed?
Event-driven review works better than calendar-driven review. Tie the obligation to the things that actually invalidate a model: reorganisation, system change, regulatory change, product launch, or a material change in volume. A fixed annual cycle disconnected from those events tends to find drift long after it occurred.
Is it better to remap processes or to fix the existing repository?
For most enterprises, a triage is more effective than a full remap. Identify the processes with genuine regulatory, revenue, customer or operational consequence, verify those against what actually runs, assign ownership, and leave or formally deprecate the rest. A full remap repeats the cycle that produced the dormant repository in the first place.
What makes a process repository stay useful over time?
Four conditions recur: a named owner per process with authority over its design, review triggered by operational events rather than the calendar, a link between the model and the system that executes the process, and a consumption path that is faster than asking a colleague. Tooling supports each of these. None of them is created by tooling alone.