JG
Hi,
I have a question on the concept of Process Level Hierarchy. In our company, the convention is this:
Level 1: Company Process Map
Level 2: Process Areas within the Process Group (VAC)
Level 3: High Level overview of Processes (VAC)
Level 4: Processes (VAC) / Activities (EPC)
(Level 4-n): Activities (EPC)
Level 5: Details (FAD)
Now, there is a request to Connect Level 2 directly to Level 4 EPC. Convention-wise, it's not allowed. But there is the argument that it's easier for the users to go directly to the process steps rather than "creating Process Level 3", less click.
I just want to know what your views on this and well, if it will be allowed, what would be the effect on the architecture and technically, application-wise.
Regards,
Julie
Hello Julie,
it is quite normal, that you have a varying depth in your process hierarchy. It's a design decision. When you have a hierarchy this deep you are most likely not modelling end-to-end processes. The hierarchy rather serves as a table of contents and the process interfaces you discover at the lowest level are not reflected in your hierarchy. Hence, the higher VAC level views strictly speaking do not constitute processes, but are a list of processes.
When you design this table of contents you will have larger and smaller "chapters" and sometimes there is just not enough contents to justify a deeper nesting of sub-chapters.
I would suggest, you stick to calling the EPC level "level 5" and the lowest VAC level "level 4". Omit level 3, where the opportunity arises. This way you have a clear nomenclature for your levels and what to expect there.
I would not give the FAD a level number of its own, but consider it the same level as the EPC it is assigned to, since it contains the same object and could be modelled at the same level in the EPC directly, if your method permitted.
