Your analysis should deliver a set of use cases that has been broken down into coherent modules and to which some prioritisation has been applied. You now need to turn this into a design. The main things you need to design are role, flows, groups, data and forms.
Roles
You need to consider who does what in the processes. There are two different types of role categorisation.
You need to consider who does what within the owner's end ot the application. Do some people have administration right, and some just users? Are there different sorts of users?
You also need to consider the roles of the different participants in the process, i.e. who other than the process owners gets involved. Are they in the same organisation, or a different organisation? If they are in the same organisation, do they need access to the same application, or are they just following a self-contained process?
Flows
Flows map out the steps in the process, covering both the owner role and participant role (or roles, if there are multiple participants).
At design stage, you don't need to elaborate the flows completely. You just need to identify the major value adding steps, i.e. what delivers information and where does that come from. Most processes have ancillary steps, such as redo loops, chat, reminders and status changes, which can be added later.
It is worth considering whether any of the standard flows could be used. These cover common collaboration patterns, and can be parameterised to deal with different data. Even if they are not a perfect fit, they may be more appropriate because they make the solution more standard. Available flows include:
- Task completion
- Report distribution
- Link sharing
- Document completion (i.e. fill in an empty document)
- Document review - formal or informal
If the standard flows are not a good enough fit, they may be a good basis, either by overriding properties, extending the processes, or just copying and modifying the definitions.
You can find reference informtion about available step types in [[metrici_development_guide]], [[metrici_development_guide_bpm_interface]] section.
When considering the flows, there is tradeoff between the control of running a very detailed process and the ease of use of a simpler process. In many cases, it is best to have a simple process without trying to capture all possible conditions, but then to have general features such as chat or the ability to force status change to deal with the more unusual conditions.
Groups
Groups, or folders, are used within the process client to subdivide work. They are used for many purposes.
- Groups provide the application structure, both an overall container for the application, and for the parts within it, which might represent different functional areas and/or episodes of activity or projects.
- Groups are used as the basis for ownership and granting permissions. Permissions that are applied to groups also apply to all sub groups. If you need to separate work depending on who is allowed to do it, you need to do so using groups.
- Groups are used to represent datasets (see below).
- Groups are also used to control the structure sent to a partner, in the form of "connection paths" (which is a specification of sub groups with the partner's connection group for your organisation). You can use this to suggest to a partner how work might best be organised (e.g. by application or by project), though it is up to the partner how they then choose to respond to processes added to those groups.
Data
Like any IT development, it is useful to model the data that is being gathered, stored and changed by the processes. A data model will help clarify the data to be stored and provide consistency about the data.
Within the Metrici portal process approach, there are two types of data.
- Individual workers each have their own data area, which is local to that worker. This holds the data and status required by a process flow. Groups can have data in a similar way, though this tends to be limited to specialised configuration data.
- Data can be held within the process module. This can be accessed by any workers and groups, allowing this data to be shared across an application.
Forms
Forms are used to provide a custom user interface within the process client. Although forms typically are used to collect data, they can also be used just to show data. Each form can be set up as a node, and can be demonstrated and trialled with users prior to completing the process automation solution.