Examples on how BPM helps to enable innovations

This post is inspired by the discussion http://www.ebizq.net/blogs/ebizq_forum/2010/05/will-bpm-projects-start-to-fade-as-businesses-go-into-growth-mode.php in which I wrote (again) that the proper use of BPM helps enterprises to enable innovations. In this post I will concentrate on practical examples which illustrate my contribution that that discussion. This is because Max Pucher commented (thanks Max for your time) some of my previous posts/presentations as “theoretical exercise”(e.g. http://kswenson.wordpress.com/2010/04/29/can-bpm-be-rearchitected-into-to-acm/, http://www.slideshare.net/samarin/achieving-synergy-between-bpm-soa-and-ea-3950413, and https://www.blogger.com/comment.g?blogID=4560463190032436692&postID=3054041712702200514 ). Hope that these practical examples will help Max to better understand the practical roots of the BPM/SOA architectural approach which I described in my book http://www.improving-BPM-systems.com/book

As usual, I have to be very explicit with the BPM (Business Process Management). I distinguish the three concepts of BPM: BPM as a discipline (how to use processes to manage an enterprise), BPM as software product (e.g. BPM suite or BPMS) and BPM as a portfolio of the business processes of an enterprise, and the practices and tools for governing the design, execution and evolution of this portfolio (enterprise BPM system).

In other words, those three concepts are: the theory, the software tools and the practice.

The “proper use of BPM” means a well-architected ensemble of all three concepts of BPM, but especially the third one – an enterprise BPM system which is architectured to provide the level of flexibility requested by the business.

Below I mention some practical positive effects of the proper use of BPM in enterprises

1. Business artefacts (roles, rules, data structures, documents, processes, services, events, audit trails and KPIs) become versionable and external (thus easier to evolve) in contract of being diluted within monolith applications. For example, a company wanted to change a simple, but fundamental, business logic which has been implemented twice: a) in a BPM/SOA part of the business system and b) in a popular ERP via some custom development. In the first case, the change took 1 hour; in the second case the same change took 1 year. Of course, with such speed of evolution discourages the introduction of changes.

2. The process-centric way of building IT systems improves their flexibility. For example, a document management solution for HR has been developed from a few COTS products. After a few years of evolution of this solution, it was in a state which fully prevented any modifications – a small change required touching all parts at the same time. We used processes as the focal point of integration of different parts of the solution and thus the further evolution was enabled because different versions of a process template can easily co-exist.

3. BPM/SOA helps to combine functionality of existing IT tools to deliver a new way of working. For example, the management of a distributed organization wanted to reduce the number of face-to-face stakeholder meetings by enabling discussions and formal voting on some policy issues BETWEEN meetings (i.e. by Internet). The management wanted this functionality within an existing extranet implemented on top of an industry-leading ECM commercial product. CEO outlined the functionality for CIO, CIO asked the vendor of this ECM product and the vendor answered that it is not possible (specs are not detailed enough, too short time, etc.). The CEO’s innovation met the IT reality. Then we used the BPM/SOA approach to develop the missing functionality OUTSIDE the ECM product and to wrap everything together as a few processes. It took 10 man-days (5 for dev and 5 for doc).

Thanks,
AS