2010-05-23

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

2 comments:

Max Pucher said...

Alexander, I think I understand BPM/SOA well enough. I do not just consult, but I actually designed and developed the Papyrus Platform which supports but goes way beyond basic BPM/SOA. The distinction of BPM as model, system and methodology (practice) is more than obvious to anyone involved. It is the substantial complexity of the systems and the methodology that actally hinders innovation.

For the benefit of the readers please elaborate how BPM/SOA enables innvoation through the process owner/actor without innovation processes. Your samples don't.

You now also name-drop about all the resources necessary for adaptive processes but you do not clarify how the usual complex BPM/SOA construct enables authorized process owners/actors to create/modify such resources.

Alex said...

Thanks Max for comments. Gland to know that we have almost similar profiles except that I specialise in architecting and delivering of solutions constructed from software products.

I agree with you that "the substantial complexity of the systems" is the barrier for innovations. And my examples show how a BPM/SOA-centric architecture reduces such complexity thus making enterprise systems easier to evolve. This is how BPM help to enable innovations.

Perhaps I don't understand what you mean by "BPM/SOA enables innvoation through the process owner/actor without innovation processes". Please explain then.

For your general question about resources I give a general answer: process is explicitly-defined coordination of services to create a particular result; some resources are handled by some services.

Thanks,
AS