Column by Dr. Friederike Schröder-Pander
(Source: Business Process Magazine 5-2010)

Last time, I discussed the business case for BPM. An important component of the business case is successful pilot projects that you can use as examples to show the benefit of process improvement. So, pilot projects must be successful – even in two ways: first, the objectives determined beforehand must be achieved; and second, it’s important to convince management of BPM’s added value.

Literature is readily available regarding how best to choose a pilot project (for example: to have sufficient chance of success, the underlying process must not be too complex; on the other hand, it must include enough areas that are painful for the business…). But it’s almost impossible to find literature regarding how you begin such a pilot project to bring it to a successful conclusion. I’m not talking about this or that improvement methodology, but rather the project as a whole. If your organisation is not yet familiar with processes, you usually have only a name for the process to be improved (which, on closer inspection, often does not cover the overtones), a handful of convinced and enthusiastic co-workers, and a crowd of uninformed colleagues and sceptics.

How do you define the right process? And how do you best model a process? This not only concerns the modelling technique itself, but also the way in which you gather the necessary information and reach consensus among the employees that are involved from the respective departments. To what level of detail should you model a process? These are important questions that are essential for success, and yet I see so many companies (still!) struggling with them.

I highly recommend – not only for beginners, but for advanced BPM practitioners as well – the book Workflow modeling: Tools for process improvement and application development” by Alec Sharp and Patrick McDermott (2009). This second edition, by the way, is much more extensive than the first (it’s nearly double the size). Contrary to what the main title “Workflow modeling” leads you to expect, it’s not only about modelling processes (the title was chosen to make it clear that it’s the “flow of work” that is being modelled). The book is also not a list of modelling rules and improvement methods, and you find no grand theories about process architecture or “management” in BPM.

So, what do you find? A collection of techniques, well-coordinated with each other, that lead you through the entire improvement project: it begins with clear rules regarding what a process is (and what it isn’t) and how you mark off a business process. This already reveals the book’s strength: the authors talk at length about conducting interviews and facilitating workshops. You notice immediately that the “lessons learned” in this book are derived from the authors’ practical experience. No scientific theories expounded; instead, highly applicable best practices, based on years of “learning by doing”.

The authors present a convincing approach for developing the process (the E2E process on the operational level) with increasing level of detail. The methods for developing the TO-BE process provide a good stimulus, but this is just one possible way. It was not the authors’ intention to reiterate the existing literature on improvement methods – everyone can look that up for themselves after reading this book.

At the end, a good impetus is given for going from process modelling to IT implementation via business services and use cases. Given the fact that, in my previous life (in the IT world), I ran into the same problems and pondered all of these questions, I really appreciate this part.

Not only the improvement techniques and the plentiful examples, but also the best practices & tips and common pitfalls make the book extremely valuable. You find that the authors are right at home in the business as well as the IT world – a rare combination with great added value. I recommend the book most highly – for business and IT analysts as well as for business and IT managers.