Maintained twice is wrong once
The main process shows not a single link, although it is plainly critical. Everything sits on the sub-processes. Why maintaining things twice is the worse answer, and how a process can display links without owning them.
Sooner or later a business impact analysis asks which IT systems a process actually depends on. You open the main process, look at its links and find nothing. No systems, no software, no information. And yet the process is plainly critical.
The reason is rarely negligence. The links are maintained, just on the sub-processes. That is where people work, and where it is known which step needs which system. The main process above them is a bracket, and brackets have no data of their own.
Two bad ways out
The first: record everything on the main process as well. The overall view is then correct, but every link exists twice. And two copies of the same statement drift apart as soon as one of them is maintained. A year later nobody knows which one is right.
The second: keep everything only on the main process. The overall view is complete, but the sub-processes are empty and therefore useless to anyone working on a single workflow.
Showing without owning
So the main process inherits. If embedded sub-processes carry their own links, meaning software, IT systems, networks, procurements, information, information domains or processing activities, those appear on the parent process automatically. Marked with the note "from sub-process", and a tooltip names the sub-process the entry came from.
Maintenance still happens in exactly one place: on the sub-process. The main process shows the complete picture without owning it. The BIA question becomes answerable, and there is still no second copy that can go stale.
One detail decides whether this holds up in practice: entries already recorded directly on the main process are not additionally shown as inherited. Otherwise the same system would appear twice in the list, once directly and once from the sub-process, and the count below the table would be wrong.
The second derivation
Standards and norms follow the same pattern. They are captured not only through direct assignment but also derived from the linked information domains. If you connect a process to an information domain covered by ISO 27001, you do not have to record the standard on the process again.
What deliberately stays out of the list
Processes can be modelled graphically as BPMN diagrams. The individual diagram nodes, meaning start and end events, tasks and gateways, remain part of the diagram and are not listed separately in the process overview. Only conventionally created processes and genuine sub-processes appear as entries of their own.
That sounds like a detail, but it is the difference between a usable process list and one with four hundred entries, three hundred and fifty of which are called "Exclusive gateway". A diagram node is a drawing, not a process.
A process modelled with a start event can be executed through workflow management. Process documentation and executable workflow then draw on the same model. That is the only arrangement in which the documented and the lived process cannot diverge, because there is only one of them.
More on the process modelling module page.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.