Process Hierarchy
When (to use it)?
I use a Hierarchy diagram at the beginning of the project - almost the first thing after Glossary, list of people and alongside the inventory of systems.
To Achieve?
A simple and instant view of the Process Breakdown - Hierarchy diagrams are a great way of viewing all your main processes in one go; a summary of your process scope.
What is it?
Hierarchy Model is: A static view of the Processes and their Breakdown. You can see all the component processes that make up the larger process. You can see parent child relationsships between processes.
Hierarchy Model is not:
- It is not a network of processes.
- It isn't supposed to show relationship of "child" processes across different parents.
- It doesn't show the relationship of actors with processes.
- It does not show that a Process can be repeated in different contexts. e.g. if you have a Bank and a user they both authorise accounts; you can't show this repetition unless you have a process called BankAuthorisation and one called UserAuthorisation.
Notation
...ok, this one is simple
Example
Following shows a very simple use of Hierachy diagrams - it shows that the European Direct Debit process consists of: Mandate Management, Payment Authorisation, Payment Capture and Clearing and Settlement processes. Those processes in turn are made up of additional sub-processes and so on. Please note that the following is for illustration only and is not a complete definition of European Payment as a whole - for more comprehensive domain models please refer to the domain section of this site.
Back to Techniques ...
- Process Hierarchy
- Swimlanes
- UML
- DFD (Data Flow Diagrams)
- Context
- State Diagrams
- ERM (Traditional Data Models)
- Activity Modelling
- Sequence Modelling
- Decision Flows