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, Business process model (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 process approach, there are two types of data.
Individual workers each have their own data area, which is local to that worker. This holds for data and status required by a prcoess flow.
Data can also be held within the process module. This data is conceptually related to the groups within the process client, though it can be accessed by workers and other groups, allowing this data to be shared across an application. Data is identified using the process identifier associated with a group. Modules can also store data associated with individual workers, though this is not so very useful.
For example, a process module might maintain a set of options associated with the application-level group which can then be accessed by processes or groups within the application.
Process modules can maintain data associated with groups that are not contained within the application. For example, a supplier management process module might hold data against the groups that represent the supplier connections, in effect using the supplier connection groups as the identifier for the data. Data maintained by different process modules can later be combined through the process identifiers of connection groups.
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.
Forms are also used to describe module data, which means that process modules can understand the data that is stored without an additional set of metadata.