You’ve Derived Your Process, so What Comes Next?
Watch our video to discover which physical elements you must consider for your process, and how you will be implementing them.
(5m:10s)
Click here to watch the previous video in our series, ‘What is Process Design?’, to learn about the steps taken to design your process, ready for configuration.
Having derived your Business Process Flowchart (your process Workflow), next, we must define the ‘physical’ elements required by your process.
[Key Process Stages]
Divide your process into stages. This allows control to pass between roles at each stage if required and ensures that any bottlenecks are highlighted.
For example, in a Complaints Management system, the different stages may be:
- New Complaint;
- Under Investigation;
- Negotiating with Client;
- Email Resolution;
- Refer to Ombudsman;
- and Closed.
Tracking Statuses allow bottlenecks during the process to be highlighted. They also help ensure that you have the right resources available, with the right skills, at each stage.
[People (Roles)]
Consider the people involved in your process and what Roles they must perform. In the case of a Complaints Management System, it may be the ‘Complaints Manager’ who picks up and resolves a complaint, and the ‘Complaints Administrator’ who deals with complaints sent to the ombudsman. People may be ‘internal’ to your organisation, or ‘external’.
Another thing to consider is how will these people participate in the process? For example, via email, letter or direct access to the system? And how are they kept up to date during the progression of the process?
[Defining your Data Types]
Next you must consider the ‘things’ you want to record data about, and the ‘fields’ needed to describe those things. In a complaints system, information concerning the complaint would need to be logged, for example: a description of the complaint; the date it was reported; the proposed resolution, and so on. In this case, the ‘thing’ (or ‘data type’) would be ‘Complaint’, and its fields would be: ‘Description’; ‘Date Reported’; and ‘Resolution’.
Information may also need to be logged on the person who raised the complaint. The details logged may include the person’s ‘First Name’; ‘Surname’; and ‘Company Name’.
It may also be useful to log details of the product or service they are complaining about. For example, the ‘Product Name’; the ‘Product Code’; and the ‘Serial Number’.
[How are your Data Types Linked?]
Once your Data Types have been defined, you must then decide how they relate to one another. For example, complaints may be linked to the complainant and the product or service they are complaining about.
[Documents]
All Inbound and Outbound documents should be detailed for your process. For example, a complainant may send a photo in support of a compensation claim, and an email or letter may need to be sent to the complainant.
[Access Rights (Permissions)]
Users of your system will be made part of ‘User Groups’. The degree of functionality they have access to will be governed by the ‘Permissions’ assigned to each User Group.
What User Groups are required in your process and what should the members of each Group have access to?
[Milestones]
Milestones are important dates during a process at which point certain activities take place. For example:
- Complaint raised;
- Resolution emailed;
- and Complaint closed.
The date these activities occur is entered against each Milestone, either manually by users or automatically by the system. This allows the progress to be monitored.
[Reports and Dashboards]
Does your process to need to utilise Reports and Dashboards? Reports display static data and dashboards present drill down and interactive data. Both make use of:
- Graphs;
- Pie Charts;
- Grids;
- Pivot Tables;
- and Images.
Detail the name, description and fields for each.
[Financial Transactions]
If your process must log financial transactions, detail the types of transaction and which User Groups are permitted to log them.
[Authority]
Is any authority required for parts of your process? If yes, log this and include those User Groups permitted to provide the authority. Those required to provide Authority receive a user task. This must be actioned by all recipients in order for the Authority request to be accepted.
[Integration]
The final key thing to consider is what other systems, if any, does your process need to integrate with?
