I was asked this week by a colleague how I would go about sitting down and designing a Metastorm process from scratch. They where intrigued to know before getting into the details of how to use Metastorm what considerations should be taken into account to ensure the process had the best possible design. A good question and one I’d not really thought about with having my own ‘ways’ of approaching each different Metastorm project.
Normally you would utilize process observations, documentation (requirements/specifications) and notation models to identify what the process should look like, how it should operate, who (users) and what (systems) it should interaction with. This would result in a ‘rough’ architectural outline that would include how many processes to create, what hierarchical interaction each process would have and whether flags or sub procedures would be used to link the processes. A quick architectural diagram would help at this point and contribute to any technical specifications being drawn up.
Thinking a little more about the question I drew up a post it of areas that should be given some thought prior to process design time and have translated my scribbles into the following key considerations to ponder prior to dragging any actions into the Metastorm process:
[Note – For the purposes of Metastorm BPM 7.6 and 9.0 cross over I will refer to v7 maps as processes (v9) in this article. Also (as basic reminder) note that a Metastorm folder represents a process instance. That process instance will be moved through the process by user and system interactions obtaining process instance specific data along the way that can be utilized by the process.]
1) Identify the tasks to be executed in order to complete the process. Prioritize those tasks. Modelling notations (UML/BPMN etc) can assist in identifying these. Ask yourself what states the process can be in during the process (think about what the folder / process instance will wait for i.e. awaiting approval, awaiting user input). Stages represent these states. Also ask yourself what activities will be performed by process participant (users) and systems. The are the process actions.
2) Define how the process should start and who should initialize the process. Processes can have different initializing actions of types flagged and user. Define which shall be used for each process. For multiple start actions, remember to name them differently.
3) Identify process participants by defining roles. Process participants will interact with the process as defined by their role membership. Define what functional activities process participants can take to further the process and create a role that reflects this. Systems also participate in the process but are generally interacting at a system stage so do not require roles.
4) Determine data requirements. The processes can be data driven as well as participant driven and so its important to define what data entities the process will work with. Does it need customer lists, pricing information or user security information and if so in what form will the process obtain this data. Web Services, Directory Servers and Databases amongst other technologies can be utilized as part of the process. Identify what is required when. These data driven entities are called Business Objects as they represent a real world entity generated or consumed by the process.
5) Identify re-use. Parts of a process can that operate the same but appear at different times in the process flow. It is useful to identify these early on and prior to design time so that sub processes can be determined. If for example you have some data collection , outbound email preparation and sending in your process that may occur several times in one process, you will want to break this out into a sub process. Sub processes are the child processing of parent process. As the parent process enters a sub process stage, the process instance (folder) is dropped into the sub process so that the emailing can take place. Upon send the Sub Process can enter a virtual archive stage and return the process instance back to the parent map for continued execution. Sub maps can be nested.
6) Consider transactional roll back. If something errors during an action or a stage, Metastorm will roll back the process instance to the last successful ‘completed ‘ stage. If for example a system stages on start event causes an error, Metastorm will roll back the process instance to the previous successful stage. The same goes for the preceding action (as the process instance will never stall at an action, only ever a state/stage). A perfect illustration of how roll back can affect your process is the use of a flagged action as the first process action. If you add logic to the flag completion event you risk rolling back the process instance all together. If an error occurs during processing of this on completion event, Metastorm will roll back the action and subsequently the creation of the folder. Place nothing in your flagged action and dedicate a system stage on completion event for this logic.