Before you build a process automation solution using PMX, or any other technology, you need a clear idea of what you are trying to achieve.
Process automation challenges
Process automation poses some specific challanges. These are easy to state, though harder to avoid.
-
If you currently have a business process which doesn't work, automating the process won't fix it.
-
If there are organisational issues, such as confused areas of responsibility or competing priorities, then automating processes will not fix these. You cannot use process auomation to paper over the cracks in the organisation. Automation requires greater clarity and agreement of who does what, unlike manual processes which can rely on more informal, human contact to smooth over differences.
-
Automation can add its own bureaucracy. Once there is an opportunity to capture nuances of a process, there is a tempation to build a solution that implements all of these, or that requires an excessive number of controls. Automation should be an opportunity to streamline processes, not to add more complexity.
These problems can be made worse by a rapid development approach. Showing people process models and forms is great for building engagement, but can hide processes that are inefficient or misaligned with organisational responsibilities.
To avoid these challenges, you need to analyse the business opportunitity to discover where process automation could add value.
Business change
Process automation is often implemented as part of a business change, to automate and enforce new working practices.
Where this is the case, you need to ask where process automation is really worthwhile. Just because a new process is required, does it need to be automated? Would it be better to run the process manually for a time to see how it works, and then to automate the areas where automation would add value?
If you are not implementing a business change, but trying to improve an existing process, you also need to consider what value automation would bring.
Value
You need to be very specific about how a process automation solution will deliver value. Although we might use terms like "efficiency savings" and "collaborative working" to justify a project, these are not statements about how value will be delivered. We need to get under the surface of these statements in order to understand what actual process automation can deliver this value.
The only way that process automation (or any other IT solution) can deliver value is by delivering valuable information to people, or to other systems. This applies even if you are dealing with physical processes such as, say, tree surgery. Although the value of the process may be something physical, such as chopped down trees, the process automation only helps inasmuch as it delivers information, such as which trees to chop down when. Don't confuse the value of the process with the value of the automation.
This valuable information has to have come from somewhere. Maybe it was entered on this or a different system, or from a different person, or calculated from other information. And to add value, the information that is delivered has to be otherwise unavailable, or it must be made available more quickly, more accurately, more securely, more reliably, with less effort, or with less cost.
Grasping this value is hard. It is tempting to draw up process models and talk about efficiency, but solutions that are not based on an analysis of value will not deliver value.
Use cases
Use cases are a good way of capturing requirements, and of making sure that there are value statement that can be analysed.
Use cases can be presented very simply using a sentence of the form
As a role I want to receive information in order to value.
Here are some examples.
- As a design engineer I want to get feedback on designs from colleagues quickly in order to reduce rework at later stages of the design.
- As a kitchen fitter I want to get full details of the required kitchen layout and orders online in order avoid delays associated with missing paperwork and to know exactly who to contact if there are problems.
- As a purchasing manager I want to analyse supplier delivery performance against orders in order to make better decisions about who are the most reliable suppliers for future purchase decisions.
Writing requirement like this makes it easier to see what the organisational roles are, what information needs to be automated, and what value that will bring.
Partitioning and prioritisation
Once you have a good set of use cases, and before designing the solution, you need to partition those use cases into different modules. Each module must have coherent purpose and ownership. This means that the operation and future changes to the processes can be managed.
Within the Metrici process automation approach, processes are split between owners and participants. You need to know who owns the process, i.e. who initiates and controls the process. You can then use ownership as the basis for partitioning the use cases into modules. The process owner is not necessarily the person doing the process. The kitchen fitter process may be owned by an installation manager. In other cases, the process owner may also carry out the process, as in the supplier delivery performance use case.
Many solutions will only require a single module because all the processes are owned by the same role or closely-related roles that all fall in the same mangement area. Guard against partitioning solutions around the boundaries of development projects: projects may involve multiple modules, plus amendments to existing modules.
Once you have understand partitioning, you can then prioritise your use cases within those modules, to give you an order in which the solution can be delivered. Use cases with fundamental capabilities should come before more nuanced ones, and use cases with high value propositions should come before ones with lower value propositions.