There are no strict specifications for modeling processes in BPaaS. However if the process is supposed to be executable in an app, then some basic rules need to be followed when creating an EPC model. The modeling conventions are non-binding Best Practice recommendations to simplify modeling and to prevent execution errors.
When naming your elements keep the following recommendations in mind:
Chose short titles. The name should be as long as necessary and as short as possible. Examples:
| |
The name should reflect the element's content. Avoid obvious name components, such as form, mail, etc. Examples:
| |
Do not start your element's name with the company name or with stating the element type (project, app...). Examples:
Avoid repetition: The more elements start with the same description, the more chaotic the element overview becomes and the harder you have to search for your elements and projects. |
We will consider the elements Function, Event and Process App (start link) separatly, because their naming requires consideration of their specific characteristics.
Functions display actions and should therefore receive an active name. Examples:
| |
Events indicate that an action has been completed and a state has occurred. Therefore, we recommend to use a passively formulated name. Examples:
|
Use noun and verb for naming functions and events ("Reporting idea"). Avoid nominalization ("Listing of idea"). |
Process App Start Links | ||
---|---|---|
The Process App start links Create and Overview shall receive names to describe that both Create and Overview belong together. Positive Examples:
| ||
Role-based Process App Start Links | ||
In role-based a pps with various users the names of the Create and Overview elements should also reflect for which users the specific start links were created. Positive Examples:
| ||
|
An EPC should be modeld in a clear fashion, the course of the process should be traceable.
Before you start modelling, decide for one approach and ask yourself:
Once you have decided for one approach use it in all models. This increases overall transparency and user comprehension.
Visit page Form Combinations for an overview of which and how many forms can be modeled in a single process step. |
The EPCs main process branch should consitently be modeled from top to bottom. It is Best Practice to begin with a start event and to finish with an end event. | |
Descriptive elements documenting rights or connections (such as Organisation Units, Roles, Systems...) are arranged to the left of the main process. | |
Elements that actively process information (Forms, E-Mails, Documents, Workers...) are positioned to the right of the main process. | |
EPC elements are linked via Connections. In the process branch entries are drawn from the top to the corresponding element, exits leave from the bottom of the element. Connections to descriptive (left) and processing (right) elements are tied to the function via the side. |
See chapter EPC Elements for more informations regarding the various elements, their configuration possibilities as well as available entries and exits. |
Branchings separate the process in multiple branches. Executable Process Apps may contain AND Branchings and XOR Branchings.
In AND branchings multiple branches are processed independently at the same time.
Example: ACME Onboarding Process
XOR branching is always tied to conditions defined in the Event element.
Example: ACME Idea Management Process
See chapter Configuring EPC Branching for a detailed description of both branching methods. |
Integration of a loop allows you to jump back from a progressed process step to one of the earlier steps. During modeling make sure that you use the connection as entry into the function from which the process shall restart.
When modeling a loop, mark the start event as such (compare page Event). If the option start event is not activated, then the jump back within the EPC can only occur from the second function. |
Example: ACME Idea Management Process
If your process model becomes too big and confusing, consider the use of sub-EPCs. Sub-EPCs help to structure a process which makes the main process clearer and keeps it manageable. Sub-EPCs are modeled in their own EPC Model. You can for example outsource sub-processes in further EPC Model elements.
Indicators could be:
How to outsource an already modeled subprocess can be reviewed at page Nesting EPCs. |
Example: Outsourcing a subprocess
A new idea has to be reviewed by more than one approver. The form Authorization was therefore replaced by the EPC Model Authorization Process, in which the entire approval process is displayed. | |
Once you open the EPC Model Authorization Process, you receive an overview of the entire subprocess: The new idea has to pass a technical, an economic and a staffing assessment. Afterwards management decides if implemention approval is granted. Only once this subprocess is finished the main process continues. |