Among computer programmers, the first task in a new programming language is to write a trivial program that outputs the text ‘Hello, World!’. This is like tapping the microphone before you start talking, to check that nothing’s broken. The BPM equivalent of a ‘Hello, World!’ programme is a simple approval workflow: a vacation request.
There are three reasons why a vacation request process is interesting: its simplicity, familiarity and a number of additional details.
The vacation request process’ simplicity makes it easy to understand. There is a single task: to make a single decision based on a small amount of information about the planned vacation.
There are many ways that the process can be more complex than this, but this is a good start to a discussion. After all, everybody requests vacation, one way or another.
The vacation request process’ familiarity makes it easy to talk about, because everyone who’s ever worked for a company knows what a vacation request is. This experience of having used this process in practice is a great source of variations in everything from the process model to what tools the company uses. Everybody handles vacation requests, but not in the same way.
The most interesting thing about the vacation request process, like any real business process, is its hidden complexity that emerges when you automate the process in a workflow management tool. As always, the devil is in the details, especially when it comes to workflow automation.
The basic way to submit a vacation request is as text, perhaps via an email. However, you need structured data – process variables – for form-based data entry, case reporting, and automatic decisions. This means extending the process definition to include its own data definitions for the requesting employee and the vacation dates, and deciding whether to capture any other information.
Once you have structured data, you’ll want to define how you enter the data using forms. This means choosing a form layout, naming fields and perhaps writing instructions for people who will use the forms. A single form can easily be as complex as the overall process model.
Assuming for the sake of this example, that the Human Resources (HR) approves vacation requests, then the ‘Review dates’ approval task should be assigned to someone who is acting in an HR role. To do this, you need to decide which users and groups are candidates for this process role.
The whole point of the vacation request process is that someone else is supposed to approve or reject the request. If you implemented this process without restricting access to the ‘Review dates’ task, then people would be able to approve their own request. Instead, you need to define who can approve requests and restrict task access to the right people.
An important part of the vacation request process that isn’t part of the simplified model above is to somehow inform the person requesting vacation whether their request was approved. You can do this manually, of course, by sending an email but ideally this would be automatic. This means extending the process with a notification task and creating an email template.
All of the variations above, as well as additional steps in the process, mean that you will make changes to the process model over time. For example, you may need to first check that the person requesting the vacation hasn’t already used their vacation allowance. To make these changes, you need to be able to start new requests with a new version of the process while existing cases continue with the old version.
Most organisations record approved vacations in some kind of HR system, to keep track of how many vacation days have been used. They may also publish approved vacations in some kind of calendar, so everyone knows who’s out of the office. This means exchanging data with external systems, usually via web services interfaces.
When you consider all of the additional details, you realise that a vacation request isn’t so simple after all. The underlying process is simple, but when you actually perform this process there’s more to consider, such as assignment, notifications and versioning. Not only are there a number of these details, but they are also what varies between organisations so you’ll need to work them out for yourself.
The process is not so simple after all because of the differences between the simplified model, and the actual implementation, which is why we call them ‘implementation details’. Actually, ‘implementation pitfalls’ would be a better name.
You probably don’t use a workflow management tool like Signavio Workflow to automate your vacation request process, because the process seems too simple. In practice, there are implementation details to consider, which is why Signavio Workflow has built-in support for:
Depending on how you currently handle vacation requests – perhaps via a spreadsheet or some dedicated software, you might not have control of these details. That probably doesn’t matter, because vacation requests aren’t core business, but what about your more important business processes?
The vacation request might be the simplest business process you have, and even that has enough complexity to benefit from automation and enough of your own way of doing things to make dedicated software problematic. That might not matter either, because it isn’t that hard to handle vacation requests, but what about the business processes that are more complex?
These are tricky questions that make it worth thinking about how you organise your team’s work. Alternatively, if it all seems like too much, you should probably plan a vacation.