Who is doing #BPM within an enterprise?

In this post, I would like to share my understanding in what extend different people within an enterprise are involved in BPM.

As usual, I have to be very explicit with the BPM (Business Process Management). I distinguish the three concepts of BPM:
1. BPM as a discipline (better management of an enterprise via modeling, automating, execution, controlling, measuring and optimising the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries),
2. BPM as software product (e.g. BPM suite or BPMS) and
3. 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 or enterprise BPM-centric solution).

Below I consider an enterprise which has accepted and implemented a process-centric way of management of the enterprise. Each stakeholder (leftmost column in the table below) of the enterprise BPM system works in some extend with some of those BPM as tools. The keys used in the table below are the following:
“—“ none (not important tool to do the job)
“-+” a bit (general knowledge about tool is necessary and some occasional use of it is needed)
“+-“ some (good knowledge about tool is mandatory and systematic use of it is needed)
“++” a lot (critical and daily-used tool)

For example, a line manager knows how to use processes to manage his/her area of responsibility, has some exposition to the selection of BPM software and uses the BPM-centric solution for daily supervision and coordinating of work of his/her subordinates.

And for architects, I added the rightmost column which is about architecting the use of these three BPM together.

A few modifications (thanks to Adam's comments) are marked in red. Two roles "BPM initiate sponsor" and "Organisational unit" are added. The latter is a group in some organisations which is responsible for improvement of work of the whole organisation.

Another modification to reflect the comment from acguitarte (Thanks)  in blue.  I consider that Strategist is, in some sense, an architect (a person who translates a customer’s requirements into a viable plan and guides others in its execution).

Thanks,
AS

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

What's the best way to pitch BPM to a company that doesn't know that it needs it?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1062077&discussionID=3125251&sik=1274510902551&trk=ug_qa_q&goback=.ana_1062077_1274510902551_5_1" />


A good pitch needs a good context. In the case of BPM, the context should cover: 1) concrete people, 2) their concrete problem(s) to be solved 3) your good knowledge how to use BPM as a powerful tool and 4) relevant stories.

Particular complexity of BPM is that it should be explained to different people (within an organization) in their language, in different ways, and all these explanations should not contradict each other.

Particular beauty of BPM is that it can be used for solving problems which are not usually associated with BPM. For example, a company wanted to select a common electronic publishing tool instead of 30 different tools but each from 30 departments claimed that their use of their tool is unique and it is impossible to select one common tool. As a proof each department showed their publishing processes. We remodeled all these processes with the same modeling procedure and demonstrated that all these processes use a limited set of basic services (but sometimes in different orders). As the result, we have selected a common tool which provides those basic services and can assemble them into different publishing processes.

Thanks,
AS

OMG BPM/SOA Community of Practice sub-group meeting (2010-04-21) review

This post is some elaboration of topics discussed at the first meeting of the sub-group (Design Patterns / Integration Scenarios and Methodologies & Approaches) on 2010-04-21. In some cases, my comments are just to understand better the topics. Next meeting is planned for 2010-05-05.

Topic “Connecting business architecture to BPM/SOA/EA"

Within business architecture, there are patterns/templates which can be used to drive BPM/SOA

<comments>
One of the patterns can be the following: the whole enterprise is usually presented by different levels of abstractions and for each level we have to be clear with the triple.

1. WHY – A reason, an end goal or something you want to ultimately achieve (in functional and non-functional characteristics, i.e. including performance
2. HOW – Activities (verbs) that help to achieve the WHY
3. WHAT – Things (nouns) physical or non physical you use when performing the HOW

At the top level, we mainly deal with organisational artefacts: vision, plans, business models, etc. In deeper levels, WHY is a set of KPIs, HOW is a process and WHAT are different resources and assets. Here we deal with BPM artefacts: events, processes, activities, rules, roles, data structures, documents, audit trails and KPIs. Majority of these artefacts are implemented as services. At bottom levels, we deal with technical and physical artefacts.

HOW+WHAT of a particular level define WHY for next deeper level.

This structure and number of levels are unique for each enterprise.
</comments>

Topic “BPM/SOA methodology and approach”

Should it be centralized to be successful? Design / Technical authority should be centralized and limited

Does the methodology differ based on the technology you have selected? You’d like to think so, but in reality it’s not.

Longer term objectives often exist in BPM/SOA projects which have to be considered in the kickoff of the project. Or – are we seeing a trend to departmentalized implementations.

Funding drives the level of departmental vs enterprise level approaches.

<comments>
One of the main advantages of BPM is that it can be implemented step-by-step – different departments may start BPM at different time and advance with their pace. This advantage should be supported by a set of commonly-agreed guidelines which should help different people (in their creative work) find similar solutions for same problems and take similar decisions in same situations. This usually implies

1. Common architectural framework (principles, agreements, know-how and models)
2. Common business process modelling procedure
3. Naming conventions for artefacts
4. Catalog of available components
5. Technology recommendations (just desired functionality, no tools)
6. Open flow of knowledge and experience between central and departmental BPM projects

For items 1-3 find something existing and adapt for your needs. The central project should help a departmental BPM project be the best by learning from the rest.

As you can see, the central project proposes a set of technology-independent guidelines which streamlines the use of technology and tools. This approach allows even to start with a simple BPM tool to better understand needs, build internal competence, etc. and later to switch to a more powerful BPM tool.
</comments>

Topic "All together"

How do we go from design to implementing into production (including maintenance and support).

</comments>
I use a business process modelling procedure which delivers an executable process implementation that is simple (i.e. it is comprehensible by all stakeholders involved) and complete (i.e. it does something very similar to the final result).

The purpose of the modelling procedure is to analyse a building block (what is it supposed to do and should it be considered as a whole?) and to synthesize its implementation (how does it carry out its function and should it be considered as a composite?) as the explicit coordination of other building blocks (processes or activities). It is an iterative procedure – we can apply it until we only have left indivisible building blocks (i.e. activities).

See slides 36-46 from http://www.slideshare.net/samarin/how-to-use-bpmn-for-modelling-business-processes which describe this modelling procedure.

This is a process-centric view; another useful view is a system-centric one – see http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation
</comments>

Topic “Modeling for execution vs static documentation”

How do we define static documentation?
Now we are able to model strategy and execution – the gray line is leaning toward modeling more within the BPMS because it is “living documentation”.
Use living documentation as an example.

<comments>
Not sure that that I understood the question. Below I provide a few examples of “unusual” use of BPMN diagrams.

1. Top manager’s view of an end-to-end process

2. Presentation of a manual process to find out potential improvements

3. Description of several inter-communicating automatic processes as documentation for an IT architect

4. Illustration of the coordination within a small servicing department.

</comments>

Topic "Standards and Compliance"

Nothing yet.

Thanks,
AS