TAOM consequences of change
A change to a process step – and everything attached to it.
Whoever changes a step changes more than a box in the diagram: requirements, tests, approvals, risks, protection and responsibilities are attached to it.
In TAOM they are attached to the same process step. That is why it is visible what a change touches – before it is approved, and only for the people and AI agents who are allowed to see it.
The idea
The innovation lies in the connection, not in the individual function
Modelling, requirements, testing, re-engineering, governance, information protection and reporting exist separately in many tools. In TAOM they all access the same step – with the same ID, the same version and the same protection level.
What is attached to the step
Six questions every change raises
1 · Requirements
Which business and technical requirements describe this step – and do they still apply after the change?
2 · Tests and evidence
Which test cases belong to the step, which evidence has been accepted – and which must run again? Testing and verification
3 · Approvals
Which approvals are needed: four-eyes at the step, a new model version with approval? Field control
4 · Risks
Which risks and controls are attached to the step – and are severity, probability and detectability still rated correctly?
5 · Information protection
Which level does the step have – and what may be output where after the change? Information protection
6 · Who may change
Which people and which AI agents may edit this step at all – set by the customer’s administrator.
Example
The step “Grant temporary access (four-eyes)” changes
From the reference model “Access to security areas” (fictitious, strictly confidential): instead of two people, one person with a system check is to approve in future.
| What is attached to the step | What the change means |
|---|---|
| Requirement “Four-eyes principle for restricted zones” | is contradicted – must be adapted or consciously replaced |
| Test case “Grant temporary access (four-eyes)” | passed so far – must be rewritten and re-run |
| Risk “Approval without second check” with controls | reassess – the control “second person” no longer applies |
| Approval of the model version | new version, approved by the responsible person |
| Classification “Strictly confidential” | remains; only people and AI agents with this level see the change |
| Project times and process mining | approval time per case decreases – the effect becomes measurable after go-live |
How the change impact analysis works
One click shows what a change entails
In the editor, “Consequences of change” compares the current state with the valid, approved version of the model – and summarises for every changed step what needs to be done.
What the analysis shows
- new, changed and removed steps – and what has changedtoday
- requirements and development objects at the steptoday
- test cases with their last run – and which must run againtoday
- risks whose rating needs to be reviewedtoday
- approvals at the step and the new model versiontoday
- protection level – downgrades are named explicitlytoday
Only what you are allowed to see
Steps above your own clearance level appear only with name and ID. The same rule applies to people, guests and AI agents – set by the customer’s administrator.
Straight to the step
Clicking a step highlights it in the diagram – test cases, risks and approval can be edited right there at the step.
Change Impact
From consequences to an assessment
With the Change Impact Management add-on licence TAOM condenses the consequences into an explainable Impact Score – with effort internal and external and costs only for people with the right “View costs”. For security-critical changes, fixed rules require an impact review regardless of the score.
Impact Score
“58 = 18 process + 12 requirements + …” – every share visible; the administrator sets weights and thresholds.
Effort without staff costs
Score, effort and costs are strictly separated levels; remuneration data of individuals is seen only by the administrator.
In reporting
All open changes per node of the enterprise model – filterable by level, standard or WRICEF.
Consequences of change
Change processes without losing the overview
For organisations whose processes must be tested, approved and protected – GxP, defence, finance, energy.