Large organisations often start Business Process Management (BPM) implementation projects to model processes and automate them using a Business Process Management System (BPMS). However, they frequently struggle to apply an iterative approach to the implementation project. This article addresses prototyping as part of an iterative BPMS implementation.
A popular BPM example is a straightforward linear pizza delivery process:
This might be a useful basis for discussing the delivery process, but if you want to implement this in a BPMS then you’ll have a figure out things like what how to structure the data for each order, who’s involved in the process, how tasks are assigned and how to integrate with a payment system. These complications are going to make things difficult.
Part of the reason why it is difficult to adopt an iterative approach to BPMS implementation is that it requires integrating a number of components, such as process models, role and group assignments, access control, data definitions, an application user interface and integration with other systems.
In practice, it takes a long time before these different aspects of the implementation fit together well enough to get something working. Only then can you proceed in iterations, and start getting feedback from stakeholders on what you deliver.
Prototyping process execution
Prototyping is the art of discovering that an idea isn’t going to work on day one, instead of after you’ve committed a large budget and engaged a complete project team. The purpose of a prototype is to fail-fast, so you can start again with a better idea.
To prototype the pizza delivery process, you need to run the process to discover whether having separate tasks for preparing, baking, packing and delivering the pizza helps coordinate the work rather than getting in the way. You would need to work on a realistic number of pizza orders at the same to find out whether the process model tasks correspond to how the kitchen staff and delivery staff divide the work.
Given a process model, prototyping its execution means finding a way to run a simplified version of the process with minimal set-up. You can use this prototype to discover whether the sequence of tasks and the different task roles make sense.
Generally, a prototype won’t demonstrate the details of a complete implementation, such as integration with other systems or custom user interfaces. However, if some part of the process automation is risky, then you may be able to use the prototype to demonstrate a ‘spike’ - a deep implementation of a very narrow scenario, in order to prove that something is possible.
The BPMS problem
Prototyping the pizza delivery process is going to run into a problem if you want to try it in a conventional BPMS. Before you know it, you’ll be stuck trying to work out how to install the software, and whether it’s okay to put the server on top of the fridge in the kitchen. You’ll get bogged down trying to understand BPMS features while the pizza orders pile up, and chances are you can’t actually afford the software licenses and process analysts on your retail business’ narrow margins. Even worse, you’ll discover that the development team seem to be able to eat infinite quantities of pizza.
Unfortunately, traditional BPMS are not well-suited to prototyping simple executable process models. The problem is that a BPMS is typically focused on providing comprehensive support for complex use cases that take months or years to develop, rather than the ability to get something simple running in a few minutes.
The problem, then, is that you need programmers to get started with a BPMS. Developing a prototype, on the other hand, shouldn’t require a development team and the associated budget.
General-purpose BPMS acknowledge The Zero-Code delusion, and provide a platform that software developers use by writing custom code. However, although Zero-Code BPM Systems are indeed ‘the wish-fulfillment myth of the BPM industry’, in the words of Keith Swenson, a zero-code prototype is a far more reasonable proposition.
Using Signavio Workflow for prototyping
Trying out the pizza delivery process with Signavio Workflow is much more feasible, because there’s no software to install, and because you only need to use its web interface to set-up the process model, the web-based pizza order form, the task assignments and the email notifications that staff can read on the telephones (or smart watches).
Signavio Workflow is ideally suited for prototyping, because creating a new process and running it for the first time is a matter of a few mouse clicks. Of course an empty process isn’t very interesting, but the point is to immediately start iterating the model and exploring how it works when you execute the process.
When you develop a process model in Signavio Workflow, it is natural to iterate the model by adding activities to the process model, process data using the form builder, role assignments, and access rights. You can even use script tasks to build spikes for systems integration using web services.
Instead of attempting to prototype process execution using a traditional heavy-weight BPMS, you can start off with Signavio Workflow. You can use Signavio Workflow to experiment with running process models to discover business processes that merit more detailed analysis and more sophisticated automation, in the form of a conventional implementation project.
Fail fast, fail cheap
If you really are attempting to prototype a pizza delivery process, then you’re probably going to discover that workflow automation doesn’t really help with process execution in the kitchen. And if you are going to abandon the idea because the melted cheese keeps clogging up the laptop keyboard, then the best thing to do is to figure this out before you’ve spent a lot of time and money on the exercise.