Perhaps the hardest thing about getting started with workflow management is choosing which process to start with. Other people can tell you which software to use, for example, but you have to choose the process yourself. You can use other people’s software, but it has to be your own process.
A good way to get started with workflow management is to start with a small pilot project, to build up some local knowledge and experience before trying to use workflow management extensively. Although there may be several business processes that you would like to automate, you need to find the one that – like the porridge in– is .
To choose a good business process to automate first, you make trade-offs between competing tensions. The ideal process is:
There are other dimensions to consider, but simplicity, relevance and complexity are enough to start with.
The most obvious way to start is to start small. Choosing a simple process limits the scope of the pilot project, so you can get results quickly. To borrow a phrase from, you’re looking for the Minimum Viable Process.
A process may be too complex because there are too many steps, for example, which means you can get bogged down with all of the combinations of exceptions – things that can go wrong. Once a process has six or seven steps, say, then additional tasks and decisions probably won’t add anything to the pilot project, except more work.
A process may also be too complex because it involves too many people or even separate departments, which means more people involved in the pilot project. A better choice would be a business process that a single person can model. Again, what this process is depends on the organisation.
However, a process can also be too simple for a pilot project. The canonical example business process in Business Process Management (BPM) might just be the employee vacation request. This is probably too simple to benefit from software support, so the results of a pilot project to automate vacation requests won’t mean much. You might as well stick with that spreadsheet for now.
An initial automated process must be relevant to the organisation: a process that is not organisation-specific, but which benefits from software support, is probably served by standard off-the-shelf software. Software developers in different organisations, for example, tend to use the same tools as other developers because their work is similar enough. Similarly, many finance processes are well served by standard accounting tools.
A business process is too specific or niche has a different problem: there may be too few people in the organisation who understand the process for the pilot project to be a good example. In a company that makes physical products, details of the manufacturing process might not mean anything to all of the workflow management stakeholders.
The process’ importance to the organisation – its business value – is a bigger factor than simplicity or relevance, but is easy to overlook. But it is important. There’s no point automating an organisation-specific process that’s just the right size and complexity if the process results aren’t important enough to justify the effort. For example, a workflow for organising office parties is likely to be too far down the list of priorities for senior management to pay much attention to the pilot project’s results.
The most important processes tend to be those related to core business, and getting paid, in particular. However, these aren’t necessarily a good choice for a first automation either, because the risks of mistakes and teething troubles with a new process implementation may be unacceptable. To the extent that the first process automation project is a learning exercise, it makes sense to choose a process where you can tolerate and easily correct mistakes.
Given the contradictory requirements, choosing a first business process to automate seems like a daunting task, but there are some common patterns. In particular, the size of the organisation provides the first clue about where to look.
For small organisations that operate as a single business unit and department, good choices tend to be core business processes. In large organisations, the core business process tend to span too many parts of the organisation to be a good choice: instead, look for support processes that are the ‘core business’ of a single department, such as personnel (HR) management.
Two great examples of suitable HR processes for a workflow management pilot are:
As well as being likely to satisfy the requirements for simplicity, relevance and importance, these processes have other advantages for demonstrating process automation.
These two finance examples are also both parts of a larger process that you can split in order to choose a balance between simplicity and complexity:
Of course, perhaps the best way to get management support for workflow initiatives is to provide workflow support for their own work. A simple management process often takes the form of a:
The challenge with management approval workflows is to pick one with a good balance of simplicity and complexity. The work ideally involves at least one other person, and one or more tasks that time to complete.
It isn’t easy to choose the first process to automate, and the choice will have a big impact on your first workflow management pilot project. However, thinking about a few of the trade-offs, and comparing your ideas with some other examples will help you avoid the worst choices.
This blog post is part of the Workflow management for beginners white paper.