Hi there! I am looking for some guidance on the following puzzle:
We are currently looking into porting our process repository to ARIS Connect. While doing so, we want to ensure that processes remain/become generic (understand: applicable to the largest number, pools either name-less or role based,...) to the lowest process layer possible . Process changes in the broad sense (addition, update) are triggered either through projects or process improvement initiatives. How would you suggest to handle a generic process repository versus what seems to me a per-project instantiation of these processes? How to keep it manageable and avoid inflation of variants which may become service or system specific? How to ensure operational people can find their way in a structure which would expand with each instantiation, while still providing relevant information as of who do what in a given context?
To make it tangible let's say we have got a generic incident management process than gets split up across level 3 and 4.
Level 3 is common to the whole organization, while level 4 is specific to the each division.
Hello Eric,
just an idea: Try to apply service-oriented principles. On level 3 assign business services to your tasks (via FAD). In a service allocation diagram for the service you define the service interface and relate all "instantiations" as a function object to the service. From there you go via assignment to each instantiation (Layer 4 BPMN Collaboration diagram).
Collect all business services in a service architecture. Advantage: you have a decoupling of layer 3 (reference process) and layer 4 (local process) and you don't have to handle complex Collaborations.
What I don't understand in your description: Pools either nameless or role-based. Do you mean Lanes? Pools should bear the name of the process they describe, as they represent the process.