Re: BPMN In Outer Space

Reply on http://mainthing.ru/item/396

Four processes so far:
“BATTLESHIP-sensing” for observing the space (any number of ships and any number of sensing devices are allowed)
“BATTLESHIP-weapon” (maybe several per ship)
“CENTER-decision” for assignment of targets per weapon(s)
“CENTER-tracking” for maintaining the list of targets (only this process can alter this list; others can read it only)

Thanks,
AS

Interview with Peter of eBizQ -- Taking an enterprise architecture approach to #BPM

From http://www.ebizq.net/blogs/2010/12/taking_an_enterprise_architect.php

Listen to Peter of eBizQ.net podcast with Dr. Alexander Samarin, who is Chief Enterprise Architect of the African Development Bank. Dr. Samarin is author of the book, and continues to blog at this site, Improving Enterprise Business Process Management Systems. In this podcast we discuss how companies should first approach BPM and how to avoid some of the initial deployment problems.


And the full story http://www.ebizq.net/topics/social_bpm/features/13176.html?asrc=EM_NLN_13093658&uid=10000098

Thanks,
AS

Illustrations for #BPM, #ACM, Case management, adaptive processes

The aim of this post is to illustrate possible relationships between process-template and process-instance which have been discussed in several blogs (my main contribution is http://improving-bpm-systems.blogspot.com/2010/04/let-us-architect-use-of-existing.html ), LinkedIn discussions and at the OMG meeting in Jacksonville.

BPM as “process-oriented management discipline to help an enterprise to realise its vision, by managing the flow of business activities in a holistic way thus considering together modeling (or planning), automation (or instrumentation), execution, control, measurement and optimization of business processes”. Below I illustrate a few variants of how those 6 functions can be applied.

Variant 1 – classic (one template is used for many instances)

Variant 2 – tailoring (a template is adjusted for each instance)

Variant 3 – reactive (no initial template and next activity is selected based on the current situation)

Variant 4 – proactive planning (similar to variant 3, but a few next activities [fragment] are executed together; whose fragments can be predefined [e.g. patterns] or designed as needed)

Variant 5 – scenario-based (similar to variant 4, but a few scenarios are considered [e.g. optimistic, realistic and pessimistic)]

1. Optimise / Reflect / Refactor + Model / Plan / Simulate + Automate / Instrument

2. Execute + Control + Measure

3. Execute + Control + Measure

4. Execute + Control + Measure

Variant 6 ...


Example for this variant is from the healthcare - thanks @Karl

Note 1 – Those illustrations show only diagrams, not all other necessary parts of the business process such as roles, rules, services, data, documents, and KPIs. Obviously, all parts have to be treated equally.

Note 2 – Ideally, some of those variants have to be intermixed within a process – selecting one of them should be easy as changing the gear.

Thanks,
AS

About Outside-In, BPM and EA

Just an opinion about the “outside-in” because of the recent debates in the BPM blogsphere, e.g. http://process-cafe.blogspot.com/2010/11/great-outside-in-debate.html

I found the Steve’s training course rather good and I consider outside-in (OI) as a good process optimization technique. 6 Sigma optimizes process to reduce number of errors within the process; OI optimizes the process from the customer’s participation perspective.

To be able to use OI, it is necessary to make in your BPM practice a customer as the EXPLICIT PARTICIPANT of the process – please, allocate a pool for this role (as Thomas shown in his great presentation -- http://taraneon.de/blog/2009/10/01/let-coffee-be-your-guide-to-process-experience/). My example is the submission interface pattern -- http://www.slideshare.net/samarin/process-practical-patterns-si (download it first to play the animation).

You don’t see a customer (end-user who pays our salaries) in your process? Do not worry! Exploit your enterprise architecture to find out all RELATIONSHIPs between your processes, roles and other artefacts and make them (relationships) EXPLICT thus trace a way from “a nail the shoe was lost” to “a battle the kingdom was lost”.

Thanks,
AS

Yet another explanation of the Business Process Management (BPM) discipline

Using processes to better manage an enterprise involves the following operations with processes (very similar to PMI methodology - http://improving-bpm-systems.blogspot.com/2010/11/methodological-similarities-between-bpm.html):
- modelling / planning
- automation / instrumentation
- executing
- controlling
- measuring
- optimising

In many enterprises those operations are carry out by different people (actually by different roles) and often different "languages" to describe processes are used by those roles (IT is the worth example among them). Each time when information (i.e. process description) moves from one role to another, there are some "translation" errors.

Imagine that you want to prepare a corporate document within an enterprise in which everyone translates this document in his/her unique language before making modifications. It is a very inefficient way of communication and coordination.

Exactly this issue is addressed by BPM which recommends to use one master description of business processes for all mentioned above operations. Of course, such a master description may be transformed (translated) to some secondary languages for particular purposes of a particular operation. For example, some international organisations produce their documents in many languages, but the master copy is developed in only one language.

Thanks,
AS

EBIZQ.net: What key methods do you use for applying design patterns in BPM?

<discussion ref="http://www.ebizq.net/blogs/ebizq_forum/2010/11/what-is-the-best-way-to-apply-workflow-patterns.php" />

I believe in tools that worked in practice. For this reason I like patterns. Unfortunately some of them e.g. some “workflow patterns” are a bit difficult for the users. So, I collected about 20 practical patterns (simple and advanced) in my book and in my blog http://improving-bpm-systems.blogspot.com/search/label/practical%20process%20patterns

I would like to be able to construct a business process (a template or an instance on on-a-fly) from small process fragments (similar to the chess game in which we have standard combinations). Some of them will be predefined in a library of process patterns, some of them have to be created on demand. (More about this in http://improving-bpm-systems.blogspot.com/2010/04/let-us-architect-use-of-existing.html).

For me, the closest match to patterns are macro-commands which we had in assemblers at run-time. Of course, now we need them at design time.

Thanks,
AS

Methodological similarities between BPM and PMI

I noticed a good match between methodologies:

BPM discipline	PMI
model (or plan) automate (or instrument)	initiating planning
execute	executing
control measure	monitoring and controlling
optimise	closing

Thanks,
AS

Linkedin: ACM is a very naughty boy

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=34067598&gid=2452802&trk=SD">

@Syed “BPM as a business discipline (not as a technology) should consists of at a high level two different kind of process architecture patterns, sequential (e.g. flow charting) and non-sequential & ad-hoc processes”

If we go back a reference model and define BPM as “process-oriented management discipline to help an enterprise to realise its vision, by managing the flow of business activities in a holistic way thus considering together modeling (or planning), automation, execution, control, measurement and optimization of business processes” then we can see that there is no fundamental difference between “sequential” and “non-sequential” processes. All depends on how OFTEN those 6 BPM functions (model, automate, execute, control, measure, and optimise) are applied:

• once before many process instances
• once before each process instance
• a few times within the process instance or
• before/after each activity in the process instance.

Classic BPMS (BPM as technology) do well the first option. The business want to have a possibility to change option as necessary (similar to the gearbox). So, no need for yet another process-oriented discipline – “just” make better tools based on a good theory (which is still lacking a reference model and reference architectures).

See also http://improving-bpm-systems.blogspot.com/2010/04/let-us-architect-use-of-existing.html
Thanks,
AS

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

Comparison of technologies for BPM - BPMS vs Workflow

This post is inspired by two discussions http://mainthing.ru/item/204/ and http://blogs.gartner.com/janelle-hill/2010/04/22/do-you-understand-the-difference-between-workflow-and-bpm/.


Just briefly repeat that I see three concepts behind Business Process Management (BPM):

[the theory] BPM as a management discipline (i.e. using process to manage business)
The purpose of this BPM is to help an enterprise to realise its Vision,
by considering and governing explicit flows of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries, and with using modeling, automation, execution, control, measurements and optimization of such flows.

Those 6 steps in the BPM loop (model, automate, execute, control, measure, and optimise) are applied iteratively, continuously and not necessary in the same order each time. There are no limits on “how often” to apply them and there are limits on “optimisation criteria”.

[the tools] BPM as a software (BPM suite or BPMS)

[the practice] 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 (BPM system)

One can implement a BPM system without any automation, for example, an ISO 9001 Quality Management System is a BPM system in which (very often) processes exist in paper and employers’ minds. Such a BPM system is difficult to use and to evolve.

Usually, it is necessary, but not sufficient, to use a BPMS to implement a BPM system. Because one of its the most important and less visible characteristic of any BPM system - flexibility - should be carefully architectured.

Previously, we used workflow technology to implement enterprise BPM systems. BPMS is certainly a better fit for this job.

WF	BPMS	in BPM loop
0.4	1	in model
0.3	1	in automate
0.4	1	in execute
0.4	1	in control
0.1	1	in measure
0	0.2	in optimise
1.6	5.2	total

WF vs BPMS for coverage of BPM artefacts

WF	BPMS	comment
0	0.5	for events
0.2	1	for rules
0.9	1	for roles
0.3	0.8	for activities
0.3	1	for data
0.8	1	for documents
0.4	0.8	for audit trails
0	1	for KPIs
0	1	for services
2.9	8.1	total

Thanks,
AS

Should the current crisis in some European countries be considered as an opportunity for e-government?

Just an idea - use a fraction of the proposed/promised financial help from the EU+IMF to some European countries to create an e-government in these countries. Should be not difficult with joint European efforts and coherent use of modern technologies such as: BPM, SOA, EA, etc.

Pros:
- more transparency
- cheaper government
- re-use in several countries
- test-bed for the whole Europe
- guarantee of avoid the repetition of the same problems
..

Cons:


Thanks,
AS

Presentation "Creating a synergy between BPM and electronic archives" at the conference ECA 2010

My presentation "Creating a synergy between BPM and electronic archives" at the conference ECA2010 "8th European Conference on Digital Archiving" is available at

http://www.slideshare.net/samarin/creating-a-synergy-between-bpm-and-electronic-archives

Thanks,
AS

Let us architect the use of existing technologies instead of blaming them for bringing complexity/inflexibility/etc. in enterprises

The aim of this paper/post is to share my opinion about a BPM (Business Process Management, of course)-related topic which is extensively discussed during last few months in many forums, blogs, articles, conferences and seminars. Sure, this is about Case Management with all its variations such as Adaptive Case Management, dynamic BPM, etc.

What do we discuss: a new management discipline, a new class of software products or a new practice of addressing existing business needs by existing technologies? As this is not clear in each piece of text, I will be very explicit. I will discuss the last option which is about how to shape a business system to become flexible enough to really help the business to deal with individual cases (not just with the mass production).

Considering that many technologies, methods, standards, enterprise roles are intermixed within this topic, I will address it through a few views:

• systems thinking view
• BPM (as a discipline) view
• case manager (or relevant authority) view
• business system architecture view

But, at first some examples of CM. The OMG’s RFP for the Case Management Process Modeling gives the following set:
Applications of case management process modeling include licensing & permitting in government, insurance application and claim processing in insurance, patient care and medical diagnosis in healthcare, mortgage processing in banking, problem resolution in call centres, sales and operations planning, invoice discrepancy handling, maintenance and repair of machines and equipment, and engineering of made to order products.

I would add: crisis management, classic project management, legal cases, plane building, developing and publishing an international standard, preparing a multi-stakeholder document (e.g. an international treaty or a public law which should be checked by many governmental agencies and potentially discussed in the Internet). May I also include some games, please? Like the chess?

What is common in these examples?

• there are some rules how to carry out cases;
• human-being’s knowledge, creativity and abilities are the critical success factor;
• it is not possible (or practical?) to predict an exact sequence of “non-creative” (or mechanical) actions for the whole case lifecycle,
• it is highly desirable to plan ahead some next actions to evaluate potential risks, time, resources, values, etc.

Systems thinking view

Generally, case is a complex, dynamic, adaptive, open, self-evolving and socio-technical system.
The socio-technical aspect is primary important and any automation should be designed with the human-centred perspective by keeping the “operator” in command of the whole system, requiring that the operator be informed and involved with monitoring the automation.
All parts of the system are important (participants, rules, documents, data, etc.) and, in accordance with the “systems thinking”, they can best be understood in the context of their relationships to one another and to the external environment, rather than in isolation. So, to provide better guidance of the “trajectory” (course of evolution/changes/actions) of the system then it is necessary to obtain / preserve / reflect more knowledge of relationships between the parts.

Some of such knowledge may come from the history of a case (i.e. its trajectory).

Because of very dynamic and open (high degree of influence from the external environment) nature of cases, it is not possible to predict a future trajectory of the system, but it is possible plan it. As any plan is an approximation, to be better prepared unknown, a few different scenarios may be considered. Three types of scenarios can be recommended: optimistic, pessimistic and realistic.

To guide the trajectory of the system, the feed-back control loop approach can be used. Smaller loops and/or nested loops can improve the ability to follow to the real situation. The frequency of loops may change during the time – the system may have periods with a turbulent behaviour and some quite time.

BPM (as a discipline) view

BPM as a management discipline (how to use processes to manage the enterprise) is about “to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries”.

The meaning of the word “model” has to be clarified. It means to make known, to describe or to communicate a plan (or plan of work or process template) of how to carry out future actions to obtain a desired outcome. Such a plan may have non-functional characteristics (risks, time, resources, values, etc.) and can be tested by some simulation. Usually, such a plan of work is prepared by the case manager and is subject to approval by some stakeholders of a particular case.

The meaning of the word “automate” has to be clarified also. It means to instrument the proposed plan of work by some existing or new tools.
Obviously, those 6 BPM functions (model, automate, execute, control, measure, and optimise) are applied iteratively and continuously. How often? It is a choice of the people who implement a BPM-centric system. BPM discipline does not limit them. Possible variations are:

• 1 (to be precise, the same version) process template for N process instances – a traditional use of workflow technology.
• 1 process template for 1 process instance – individual tailoring of a generic process template for a particular case. An example is “Defined Process” [capability level 3] from CMMI; another example is a legal procedure [bankruptcy procedure] defined by the law which is actually a skeleton (with a lot of exceptions) for all instances.
• No process template before the process instance – the template is built as needed within the process instance (or at runtime). Small process fragments are used. Some of them are predefined in a library of process patterns, some of them have to be created on demand.

What are optimisation criteria? Again, it is a choice of the organisation. The latter may use the BPM for perfecting internal work (inside-out) or serving each customer differently (outside-in).

So, the BPM discipline is rather applicable for managing of cases.

Case manager (or relevant authority) view

Any tools for case management shouldn’t try to replace a human, but assist him/her to carry out repetitive or complex calculation/data processing activities. Planning of future actions at runtime is mandatory. Such a planning may comprise several scenarios, may have different horizons (next action only, a few next actions, all further actions, etc.), may involve some simulation and may use different characteristics (risk, values, money, impact, etc.) Planning can be nested: the top-level planning is the case lifecycle.

Support of decision making is necessary because of increasing amount of information involved in the decision making. Sensing of this information and events is vital.

Perfect capturing of relevant data and information is certainly the area for automation. Especially, for handling of small fragments of information in addition to whole documents. For example, patient’s data must become anonymous for a review by a group of external experts. Each fragment (and any logical aggregation of fragments) should be treated as a separate unit with its own history, identification, permissions, relationships, presentations, audit trails, etc.

And finally, help people with coordination of actions. Coordination may be between organisations, units, people, systems, etc. Also coordination can be static, dynamic, un-structured and networked. It is important to provide and enrich a library of coordination patterns (e.g. a review by a group of experts).

Again the OMG’s RFP for the Case Management Process Modeling gives a good overview:
Typical elements of a case management process are assessment of needs, evaluation of potential solutions, implementation of a selected solution and monitoring and evaluation of results. Case management typically requires a great deal of knowledge work, undefined interactions between a case manager and other participants, long running case resolution efforts, multiple process fragments and engagement of supporting services.

Business system architecture view

The aim is to provide an “actionable work execution coaching/guidance” for the business. It seems that a good set of existing technologies should be deployed and employed TOGETHER: BPM, BRM, ECM, CEP, EDA, SOA, MDM, RBAC, process/data mining, .
The current situation with BPM software products shows that vendors are trying to add more and more features from different technologies into their products (e.g. by acquisition of separate tools). So, products are more and more complex, expensive and heavy (difficult to test and to evolve). Is it a time when the “created” complexity became an obstacle for further progress (including innovations)?

The solution for reducing complexity is well-known – use architecture with pluggable (through commonly-agreed and standard interfaces) blocks of specific functionality. Also, this should bring the flexibility thus enable business innovations.

Imagine that each case is handled by a personalised and dedicated "virtual" business micro-system. The micro-system is optimised for a particular case and evolves together with the case lifecycle – see below.

Conclusion

The title of this post is its conclusion – let us architect the use of existing technologies instead of blaming these “speechless means” for brining complexity into enterprise systems.

Thanks,
AS

Reply to Post: Does BPM need a W3C type Standard? No way!

<Blogpost ref="http://andrewonedegree.wordpress.com/2010/04/06/does-bpm-need-a-w3c-type-standard-no-way/" />


BPM (as a discipline, tools and the practice) needs standards – they are steps (like in a ladder) to move forward. Example of W3C is a bit “wider” then you mentioned – there is a set of coherent standards: a) xHTML for structure and content, b) CSS for presentation, c) DOM-based API for dynamic modifications, and d) some other specialized standards. And, very important, there is an architecture which gives the context for all those standards.

Good acceptance of HTML (all vendors are checking their product with acid3.acidtests.org) considerably reduces development efforts – previously 25 % has been spent for covering “specific features” of popular Web browsers. As well as this is a base for moving to HTML5.

In the case of BPM we have neither real standards (just publicly available specifications) nor architecture. But by having commonly agreed and executable BPMN we can use it within wider range of applications (i.e. innovate), e.g. in the traditional “case management” for planning and execution of short chains of steps (or activities). Similar as in the chess game some players think only about the current move and some players think for several moves in advance.

Thanks,
AS

ebizq.net: Has BPM Evolved To a Point Where Only Incremental Improvements Can Be Made?

<discussion ref="http://www.ebizq.net/blogs/ebizq_forum/2010/03/has-bpm-evolved-to-a-point-where-only-incremental-improvements-can-be-made.php" />

I think that BPM (discipline + tools + your enterprise system) is an enabler for evolving the business at the business pace. In a properly architected BPM system, it is easy and cheap to introduce small improvements; also the risk of big changes can be mitigated by some simulation.

I saw projects in which BPM was “eclipsing” a production system and I saw projects in which BPM is the core of a production system. The general conclusion is that the business and the IT (and sometimes a BPM vendor!) do not know yet how to use all power of BPM.

Thanks,
AS

Practical Process Patterns: CAAP

Cooking As A Process (CAAP) pattern illustrates "coordination by instances": as a typical culinary recipe comprises many "smaller" actions, they are modelled as instances of the sub-ordinated process. The main process is to follow the recipe.

Note that the same person can be in two roles: CHEF and sub-ordinate.

Obviously, monitoring of this process should be more "practical" than just following tokens within this diagram.

Thanks,
AS

Linkedin: BPM Ecosystem - Blurring boundaries or systematic convergence?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1062077&discussionID=15656302&sik=1268813838851&trk=ug_qa_q&goback=.hom.ana_1062077_1268813838851_3_1" />


It is normal because BPMS (BPM as software) is an enabler for disruptive changes on how IT deliver tools (currently applications) to the business (see http://improving-bpm-systems.blogspot.com/2010/03/ebizqnet-is-bpms-just-new-name-for.html ).

I think there is the convergence (which is based on managing business by processes) and to make it explicit I propose a BPM reference model ( http://improving-bpm-systems.blogspot.com/2010/02/bpm-reference-model-fragment-01.html ).

Thanks,
AS

Linkedin: EA Practitioners, What's your profile: Strategist, Generalist, Versatilist, or Specialist?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36781&discussionID=15367455&sik=1268340693254&trk=ug_qa_q&goback=.hom.ana_36781_1268340693254_3_1" />

From my book:

13.6 Different roles of an enterprise architect

Below is a list of the roles which should be effectively fulfilled by any enterprise architect in order to use EA as a tool for improving an enterprise.

• Scribe who keeps up to date the documentation about EA artefacts and the relationships between them. This is the traditional role of an enterprise architect.
• Scout who brings new technologies into the enterprise.
• Salesman who finds good arguments for investments in not-so-obvious improvements.
• Superman who is usually asked to provide a quick rescue for a rotten IT project, often by completing during the weekend work that should have been done over many man-months!
• Sociologist who has to understand the concerns and fears of everyone in the enterprise.
• Servant who is at the service of all others in the enterprise.
• Scientist who uses scientifically proven methods in his/her work.
• Student who is ready to learn quickly new technologies, new tools and new business domains.
• Shepherd who can guide others.
• Secretary “de luxe” who helps others to do some work (although this may be considered as a rather low qualification, it is nonetheless important to achieve the common goal).
• Skipper who can lead complex projects.

Thanks,
AS

Practical Process Patterns: MINT

Migration Instances to New Template (MINT) pattern illustrates an approach for moving running instances from one version of their template to another version. The idea is to allow such a migration at some control points of template.

The figure below shows a version of template v1 and a two its instances.

The figure below shows a new version if this template – template v2 and two its short versions: template v2’ and template v2’’.

When instance 2 has reached control point A1 then we have to instantiate template v2’ to continue this instance. When instance 1 has reached control point B1 then we have to instantiate template v2’’ to continue this instance. See the figure below.

Of course, all audit trails and KPIs should be externalized from the business process execution engine.

Thanks,
AS

Linkedin: How do we measure work flow across multiple business units? Managers are finding it difficult to monitor and follow up with process on priority basis.

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=61365&discussionID=14793570&sik=1267787964487&trk=ug_qa_q&goback=.ana_61365_1267787964487_3_1" />

I am with Ralph – just priority is not enough and some performance (and other) information should be used at some control points.

Below is a fragment from my book (www.samarin.biz/book):
One of the possible interpretations of performance information is a proactive control of the SLA. As any process is a service, so it has to have an SLA, e.g. an agreed execution time. Typically, process engines are good for generating an alarm (e.g. an e-mail) that a particular process instance took more time than that agreed. But this is not sufficient because it addresses the effect and not the cause.

The imposition of a fixed SLA on all activities within a process template leads to a fussy BPM system which produces too many “false alarms”, e.g. if some execution time has been saved at the beginning of a process instance then the control on subsequent activities can be loosened somewhat; alternatively some activities may “catch up” the time lost by some preceding activities.

Ideally, the process owners have to be warned in advance about any potential non-respect of the SLA by a particular process instance. Control points are good places to run “health check-ups” of SLAs. These check-ups should evaluate the current situation and provide proactive control to achieve flexibility in the execution of the complete process, thus really helping business process managers. In addition to the process SLA, each activity is considered as a “spring” with some limits to stretch and to compress. The activity SLA needs to be defined to include both the nominal size of the “spring” together with its upper (stretched) and lower (compressed) limits.

Figure 7.3 provides an example of the dynamics of such a proactive control. As completion of the activity “Activity01” took more time than planned, then the SLAs for the other two activities were reduced (i.e. the springs were compressed). As completion of the activity “Activity02” again took more time than planned then the last activity needs to be compressed even more. It may happen that the last “spring” doesn’t reach its lower limit and thus the process instance may be completed within its SLA. Otherwise the process owner has to take some action because this process instance will break its SLA.

Thanks,
AS

ebizq.net: Is BPMS Just the New Name For Application Development?

<discussion ref="http://www.ebizq.net/blogs/ebizq_forum/2010/03/is-bpms-just-the-new-name-for-application-development.php" />

I think that BPMS (BPM as software) is an enabler for disruptive changes on how IT deliver tools (currently applications) to the business. Each enterprise has a historical set of “solid” applications and each of those applications dilutes and mixes several business artefacts: processes, services, events, data structures, documents, rules, roles, activities, audit trails, KPIs. BPMS, by enabling explicit and executable processes, is a step forward to externalise (later virtualise and “send” to clouds) ALL those artefacts. Of course, with the help of many other technologies, e.g. ECM for documents, BRM for rules, MDM for data, etc.

This considerably increases flexibility – improving of processes will be assembling of better compositions from better artefacts; use of DSLs will simplify handling of artefacts, owners of business artefacts will be able to change them directly, etc. Because in many cases, processes are such compositions – this is the reason of the importance of BPMS.

Should we invent a name for it? Business Artefacts Development? Business Artefacts Provisioning? I think, that more important is to come up with a commonly agreed reference model and reference architectures to help everyone to move forward faster.

Thanks,
AS

Linkedin: Is BPMS Just the new name for Application Development?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=70120&discussionID=14249147&sik=1267196069489&trk=ug_qa_q&goback=.hom.anh_70120.ana_70120_1267196069489_3_1" />


Agree with Max that the goal is to be able to improve processes by the business without the existing burden of application development. To reach this goal it is required to architect the flexibility of enterprise BPM systems (BPM system is a portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio).

In many cases, an enterprise BPM system is a historical set of applications and each of them dilutes and mixes processes, events, rules, data, services, KPIs, etc. With the help of BPMS (software) and other modern tools we can externalize, make explicit and implement via DSLs those artefacts. This considerably increases flexibility – improving of processes will be assembling of better compositions from better artefacts. So, BPM (as discipline/concept, software and system used together) is disruptive innovation vs. application development.

Thanks,
AS

...


Thanks Mark, I will try to be more explicit ….

An enterprise is a complex, dynamic and self-evolving socio-technical system which consists of many artefacts. Some of them: processes, services, events, data structures, documents, rules, roles, data, documents, activities, audit trails, KPIs. Those artefacts are interconnected and interdependent. Because of new policies, priorities, compliance, technology, etc. we have to change the enterprise. Implementation of such changes necessitates the evolution of some artefacts and the relationships between them. It must be easy to modify all artefacts and relationships without causing any negative effects.

With the traditional application development the majority of artefacts is implicit (because they are coded in, for example, Java) and cannot be modified by their owners thus making the whole enterprise difficult to evolve. Principles for creating creating flexible systems are:
- All artefacts must be evolved to become digital, external, virtual and components of clouds
- All artefacts must be versionable throughout their lifecycle
- All relationships between these artefacts are modelled explicitly
- All models are made to be executable

Business process is the best example of a relationship between other artefacts: who (roles) is doing what (business objects), when (coordination of activities), why (business rules), how (business activities) and with which results (KPIs). So, business processes should be explicit and executable and this is done by BPM suites (or BPMS). Other artefacts are handled by different technologies/tools, e.g. ECM for documents, BRM for rules, MDM for data, etc. Now, instead of developing applications, we can assemble (of course with the help of SOA) artefacts around business processes thus increasing flexibility.

As processes (and services) are the major artefacts of this architecture, the use of BPM (as a discipline for using processes to manage business), BPMS (as a tool) and BPM system should be aligned. Sure, those three concepts can be used in separation – good processes are implemented in a Java program or BPMS as the only tool which includes all other technologies. But this still limits the agility of the enterprise.

A few extra resources are in my blog http://improving-bpm-systems.blogspot.com/2010/02/bpm-reference-model-fragment-01.html

Thanks,
AS

Linkedin: From a business management standpoint, which is more important: Business Capability (the WHAT) or Business Process (the HOW)?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1847467&discussionID=14428836&sik=1266999647752&trk=ug_qa_q&goback=.ana_1847467_1266999647752_3_1" />

Support Gaby about “focus on business performance”. In my books, capability is the possession of characteristics required to produce a particular outcome. The latter is a pair “right things” (assets) and “done well” (performance, reliability, etc.) as the result of work of a function (regardless how this function is implemented). So, a capability combines functional and non-functional characteristics (timeliness of outcome, data accuracy, quality of result, efficiency, effectiveness, impact on stakeholders, SLA, SLE, etc.) of a function. See http://improving-bpm-systems.blogspot.com/2009/11/linking-concepts-and-expressions-used.html

Sure, decision-makers should monitor the business performance. Such a monitoring may be reactive by measuring the outcome (function is a black-box), or it may be proactive by measuring the process of achieving the outcome (function is a white-box and its business processes are visible). My experience – business line managers like the proactive monitoring, because it helps them to prevent problems.

Actually, we speak about GRANULARITY of performance monitoring which may be different for different decision-makers and may change over the time. I would recommend asking decision-makers explicitly about their needs for performance monitoring. Then it will be clear where to measure – just at the level of some capabilities or add a few check-points within some business processes.

Thanks,
AS

BPM reference model - fragment 09 - Your flexible BPM system will become an enabler for business innovations

... continued from fragment 08

1.9   Your flexible BPM system will become an enabler for business innovations

A typical task for a BPM system is to balance the final added-value of the product against the overheads associated with restructuring and/or tuning the enterprise business system to create this added-value. Today market success is often based on offering personalised products for less overhead. This book is not about how to make your products better, different or more attractive for the market -- this is for you to decide. What this book can offer is to help you reduce the overheads in doing so -- your flexible BPM system will become an enabler for your business innovations.

Imagine that each product is handled by a personalised and dedicated "virtual" business micro-system. The micro-system is optimised for a particular product and evolves together with the product lifecycle (see figure 1.10). As a result, any exception becomes the norm. Instead of reducing the number of variations and considering exceptions as a loss in productivity ("20 % of the work takes 80 % of the time") all products are treated equally. Of course, this is already the case for the manufacturing of expensive products such as aircrafts, cars and, to some extent, computers, but such an approach is also applicable to a wider range of commodities, especially those treated/handled with software-intensive systems.

Figure 1.10   The co-evolution of the enterprise business system and business micro-systems

... This is the end of the chapter 1. Maybe I will make also publicly available the chapter 13 "The BPM opportunity and challenge for enterprise architecture".

Thanks,
AS

BPM reference model - fragment 08 - The flexibility of your BPM system must be explicitly architected

... continued from fragment 07

1.8   The flexibility of your BPM system must be explicitly architected

1.8.1   The hidden cost

The flexibility of a BPM system is a characteristic which can be elusive and difficult to achieve. The main difficulty comes from the fact that, as already mentioned in 1.4, in a process-centric enterprise, the BPM system covers most of the enterprise business system. Hence it inherits most of the existing problems from different parts of the enterprise and adds new problems of collaboration between those parts. Of course, this brings new challenges in reaching the required level of flexibility, as well as new opportunities. Below, we make those challenges explicit and later explain how we address them via a proper architecture.

Our experience shows that the business usually wants separate requests for change in the IT environment to be implemented quickly. These changes are typically small (from the point of view of the business staff) but unpredictable (from the point of view of the IT staff). The current practices of software development have failed to provide a good solution to this challenge. The usual practice is that an IT application is released with a fixed set of business functions, and then it is maintained to accommodate new business and technological needs until the release of the new application at a later date.

It is thus not surprising that [10]

• "80 % of software lifecycle costs occur during the maintenance phase", and
• "80 % of maintenance is due to unmet or unforeseen user requirements; only 20 % is due to bugs or reliability problems".
  

These values were reported in 1992 as an average for the IT industry; the current situation for some enterprises is worse -- the development and deployment of an application can be only 5 % of the total cost of its ownership. What is also disturbing is that these values are not widely known to many people from the IT industry, and IT staff typically estimate these values completely differently (see figure 1.9).

Figure 1.9   Different estimations of the development/maintenance lifecycle cost ratio

Considering the critical role of the IT services in any modern enterprise, it is obvious that an inability of the existing IT environments to implement quickly unexpected requests for change reduces the speed at which the enterprise can carry out its performance improvement. Meanwhile, improving the speed and quality of software development although necessary is not sufficient by itself, because any IT application has to be tested and deployed, data have to be migrated for this new IT application, the users have to be trained to use it efficiently, etc.

1.8.2   Conceptual integrity

Our experience shows that the best way to address this problem is to architect all existing methodologies and IT technologies in such a way that they work together -- there is no magic wand, only the concerted use of different technologies, knowledge and practice around the BPM discipline.

The biggest difficulty is to have a clear understanding of which piece should be taken from which IT tool in a particular case. It is well known that modern IT tools have a lot of overlapping functionality. Also, many IT staff members naturally want to embed/insert/use their favourite IT tool in as many IT solutions as possible. Furthermore, many IT tools offer some customisation to adapt to business needs, and vendors offer to develop a special extension for your need. As a result, the rationale behind many architectural decisions is "we use this tool because we can". Such decisions should be avoided along the lines of the famous "spandex rule" -- "just because you can doesn't mean you should".

In some senses, this is similar to mastering a chess game, which requires an understanding of how to "play" all chess mates in the right direction and in the right sequence. And this is the essence of what this whole book is about.

1.8.3   Collaboration between the business and the IT

In addition to mastering the combination of methods and tools, the internal collaboration between the business and the IT is essential. It is not a secret that in many enterprises there is a lack of good collaboration. We think that our approach for improvement of BPM systems facilitates the step-by-step establishment of trust and helps to minimize (or ideally eliminate) this collaboration gap. In reality, both the business staff and the IT staff work with different views of the same enterprise business system. In a simplified way we can say that the business staff see the enterprise business system as a coherent set of processes which are under the control of the business. Typically these processes constitute the management model. The IT staff see the enterprise business system as a set of IT services which are under the control of the IT system. Typically, these services constitute the implementation.

Convergence of the business and IT views is within reach. The IT world recently "re-discovered" and accepted the notion of services, and so emerged SOA. But IT is still not very comfortable with processes. Also, how processes and services work together has not been clear, and typically both processes and services are "diluted" in existing monolithic applications. This makes the enterprise business system difficult to evolve as changes to program code are often necessary to effect even minor business changes.

The architectural framework presented in this book provides guidelines and patterns for structuring processes and services in such a way that they can be changed easily, without disproportionate efforts and destructive side-effects.

1.8.4   Common understanding among everyone involved

We have observed that improving a BPM system requires a lot of communication with practically everyone within the enterprise, and everyone should be treated as a stakeholder of the BPM system. Each group of stakeholders has different views, different concerns and a different understanding of the BPM system. The different groups of stakeholders are generally the following:

• top managers
• enterprise architects
• business line managers
• process owners
• super-users
• normal users
• project managers
• business analysts
• IT managers
• IT solutions architects
• IT developers
• IT operators

It is necessary to explain to each group of stakeholders how their concerns will be addressed and how their current working practices will be changed for the better (see also 3.3 and 3.4). (This is a typical duty of the chief architect of the BPM system.) Coherent and clear explanations in the business language are vital for the success of a BPM project. Success is not about saying "Yes" to all requests from the "more important" staff members; it is about building a common understanding and agreement between all stakeholders. This book is intended to help you achieve such success by giving some real examples of communication with the business staff (see chapters 3 and 7).

1.8.5   Coordination at the scale of the whole enterprise

Coordination between artefacts is also important because of the high level of complexity of modern enterprise business systems. There is not only static complexity at the design level, but there is a lot of dynamic complexity during the execution (in the same way that the assembly of a car engine from its parts represents a static complexity, but the car also needs to run with a reasonable performance).

Also the modification of enterprise business systems to accommodate typical changes in policies, priorities, technology, laws, etc. necessitates the evolution of some artefacts, and the relationships between them, simultaneously as a complete system. So, it must be easy to modify all artefacts and relationships without causing any negative effects.

The improvement of any BPM system is a difficult task. It is a transformation

from a system of systems that has grown over years under different influences
   to a coherent, smoothly evolving, enterprise business system which is easy to maintain and develop further
      subject to socio-technical aspects, because how you do something is sometimes more important than what you do; 3.3 covers some of the human-related concerns.

Industry experience has demonstrated that the strategic transformation of an enterprise is more effective and efficient if it is based on an agreed architecture, an "enterprise-wide architecture" [or an Enterprise Architecture (EA) as it has come to be known]. EA (14.3.4) is defined as a coherent and proven set of principles, recommendations, practices, and tools which provides guidance and practical help for the design and evolution of IT and business to achieve enterprise vision and strategy. Thus it is basically the actionable master plan for the enterprise; a comprehensive plan for how to build, to use and to evolve all enterprise artefacts (including the data, business processes, business rules and IT assets).

The concept of using EA is old and has always been appealing for enterprises. But there is a wide-spread perception that a large (and useless) amount of paper work has to be prepared before any results can be obtained. We have experience that it does not have to be this way -- if done correctly, the use of EA can bring significant improvements faster, better and less expensively than the use of any other approach.
EA and a BPM system are both enterprise-wide initiatives, and the best results are achieved by using them together -- in chapter 13 we will discuss how to achieve synergy between them.

... to be continued in fragment 09 ...

Thanks,
AS

BPM reference model - fragment 07 - All attention at enterprise BPM systems

... continued from fragment 06

1.7   All attention at enterprise BPM systems

The situation with the second enabler is much more difficult. We have observed that some BPM systems are complex, a "problem" of their history, and chaotic and inefficient. In such systems, the control and operations parts of the enterprise business systems have been constructed separately under different management policies, and they have different speeds of evolution, are not well integrated, etc. Certainly, such BPM systems cannot implement changes at the required pace.

An example of inflexibility can be workflow-based solutions which are often very difficult to evolve. Workflow technology, as a general rule, makes the flow of human work explicit and executable. It also covers to some extent other artefacts such as roles, rules and data, but not explicitly. Everything that is not explicit is usually "spread" somewhere in the program code, and thereby becomes difficult to maintain.

The BPM discipline inherits a lot from workflow technology, but by extending it the BPM discipline handles explicitly more business artefacts (i.e. services, events, etc.). Also, the BPM discipline considers the whole cycle of continual process improvement. Thus, potentially, BPM systems can be more flexible than are workflow-based solutions.

Of course, high flexibility does not happen automatically simply by buying a modern BPM suite. The ability of a particular BPM system to evolve at the required pace must be properly architected -- i.e. designed, planned and supervised during its implementation.

This book constitutes practical guidance and help for transforming your existing enterprise environment into a BPM system which is easy to evolve. It provides many recommendations, principles, methods and examples.

... to be continued in fragment 08 ...

Thanks,
AS

BPM reference model - fragment 06 - BPM and some information technologies

... continued from fragment 05

1.6   BPM and some information technologies
The growing popularity and great potentials of the BPM discipline created the impetus for a new class of enterprise software -- the BPM suite or BPMS (14.3.9) -- a coherent set of software tools for facilitating the implementation of BPM systems. Typical components of BPM suites are the following.

• Process modelling tool, designer or modeller -- an ergonomic graphical environment for manipulating artefacts such as events, rules, processes, activities, and services.
• Process testing tool -- an environment for functional testing which allows a process to be "run" with different testing scenarios, e.g. various inputs, various rules, and various responses from the services.
• Process template repository -- a store of process templates comprising different versions of the templates.
• Process instance repository -- a store of executing and executed process instances.
• Work list or task list -- an interface between the BPMS and a human carrying out some activities within processes.
• Dashboard -- an interface between the BPMS and the humans controlling the execution of processes, e.g. a BPMS administrator (who should know that "everything is working") or a business process owner (who should know "how well everything is working").
• Process analytics tool -- an environment for analysing audit trails and KPIs to find out historical, current and predictive tendencies of business operations.
• Process simulation tool -- an environment for performance testing which allows a process to be "run" as for functional testing, but where the dominant considerations are the expenditure of time and other resources.

These components are spread across different parts of the enterprise business system as shown in figure 1.7.

Figure 1.7   Components of a BPM suite

Unfortunately, just managing processes using a BPM suite is still not sufficient because many additional artefacts are not considered. This has lead to the creation of another new class of enterprise software -- Business Process Platform (BPP) -- which attempts to cover more artefacts together. Typical technologies associated with BPP are the following.

• Business Event Management (BEM), which captures real-time business events and assigns them to their proper processing. Also, BEM is related to Complex Events Processing (CEP) and Event-Driven Architecture (EDA).
• Business Rules Management (BRM) and Business Decision Management (BDM), which allow the explicit, formal and, preferably, user-friendly handling of business rules. As business rules are often present in many business processes, a BRM can simplify considerably the maintenance of their business logic.
• Enterprise Content Management (ECM) system and collaboration facilities, which capture, manage, store, preserve and deliver content (documents as well as e-mails, blog posts, forms, etc.) in a collaborative manner. ECM is important since about 70 % of business information is stored in such a way, and many business processes need to handle such types of non-structured information.
• Master Data Management (MDM), to store, manage and preserve highly-structured data even if they are spread between many databases
• Configuration Management DataBase (CMDB), to store and manage different configuration information about artefacts.
• Role-Based Access Control (RBAC), which facilitates the secure management of resources and provides explicit, formal and, preferably, user-friendly handling of business roles.
• Business Activity Monitoring (BAM), which facilitates the operations control of an enterprise through the processing of audit trails which are produced during the execution of business processes. The BAM aggregates, analyses and presents real-time information about activities.
• Business Intelligence (BI), which facilitates the analysis of the functioning of an enterprise by processing audit trails. Some KPIs may be derived by BI tools. BI tools collect, integrate, analyse and present business information.
• Service-Oriented Architecture (SOA) (14.3.10), which provides guidance on a) how to construct complex software-intensive systems from a set of universally interconnected and interdependent services and b) how to govern the evolution of such systems.
• Enterprise Service Bus (ESB), to facilitate inter-service communication within SOA-based environments.

These technologies are spread across different parts of the enterprise business system as shown in figure 1.8. Only the highlights of BPP systems are illustrated. IT governance is not mentioned because it is everywhere.

Now that we have all necessary elements in a BPM-centric "melting pot", let us come back to the two major enablers (discussed in 1.1) for carrying out the optimisation of the enterprise as a whole: 1) better decision making and 2) the ability to implement the necessary changes at the required pace.

The BPM discipline can help with better decision making by providing

1. a formal and executable description of the business processes, which can be used in different specialised tools such as process modelling tools, process simulation tools and
   process executions tools, and
2. real data collected during the execution of business processes (audit trails, KPIs), which can be reused for simulation and performance evaluation (using BAM and, mainly, BI).

Figure 1.8   Different technologies associated with BPP

... to be continued in fragment 07 ...

Thanks,
AS

BPM reference model - fragment 05 - Artefacts important for BPM

... continued from fragment 04

1.5   Artefacts important for BPM

As already mentioned in 1.2, processes and services are the principal artefacts (14.2.6) of enterprise business systems. But enterprise business systems operate in addition with the following artefacts which are important for the BPM discipline:

• events (14.4.7) -- incidents of importance to the business; they occur within and beyond the enterprise boundaries and may give adequate reason for some action from the business (for example, receiving a customer's order, detecting a performance bottleneck, etc.);
• rules (14.4.8) -- constraints and conditions under which the enterprise operates (for example, a claim for more than 10 000 CHF must be endorsed by a group leader, the working week is 40 hours long, etc.);
• activities (14.4.9) -- elementary or indivisible units of work which constitute processes;
• roles (14.4.10) -- sets of responsibilities (for example only a manager is authorised to approve a particular document);
• objects (14.4.11) -- formal descriptions of real things and people which constitute the business [there are two big groups of objects: data structures (14.4.12), e.g. partners, products, etc., and documents (14.4.13), e.g. forms, reports, etc.];
• audit trails (14.4.14) -- factual information about process instances (for example, when a particular activity has been completed);
• KPIs (14.4.15) -- quantifiable measurements that express how well something or somebody is achieving its or his/her objectives.

Figure 1.6 provides an overview of how these artefacts are spread across different parts of the enterprise business system. The various artefacts are used to a different extent at different places within the enterprise; but taking into consideration that the implementation part owns the shared description part, figure 1.6 shows them only in the owner (or master) parts. These artefacts will be discussed in more detail in chapter 7.

In figure 1.6, the expression "processes (as templates)" means abstract descriptions (or models or plans) of processes; the expression "processes (as instances)"  means the results of execution of the corresponding templates. Usually, a process template may be used to produce many instances (similar to a blank form which can be copied to be filled in by different people, or similar to a document template from which documents can be derived).

The expression "services (as interfaces)" means formal descriptions of services which are available for their consumers, whereas the expression "services (as programs)" means implementations of services.

Figure 1.6   Some artefacts in the enterprise business system

To handle the complexity illustrated in figure 1.6, any process-centric enterprise needs to have its own BPM system (14.3.8): a portfolio of business processes of the enterprise, as well as the practices and tools for governing the design, execution and evolution of this portfolio as a system. In other words, the BPM system is responsible for ensuring that the functioning of the different parts of the enterprise business system occurs in synergy.

For any process-centric enterprise, the BPM system may not be perfect (e.g. some processes may be only documented on paper, some details may be "located" only in the minds of certain individuals, etc.), but it does exist. Any implementation of the ISO 9001 Quality Management System can be considered as an example of a BPM system.

... to be continued in fragment 06 ...

Thanks,
AS

BPM reference model - fragment 04 - The essence of the BPM discipline...

... continued from fragment 03

1.4   The essence of the BPM discipline -- what you model is what you execute

By combining all ideas mentioned so far, a process-centric enterprise can be represented in more detail as illustrated in figure 1.4. Processes are used everywhere: in the execution to drive the work, in the decision making to identify improvements and in the implementation to realise these improvements.

Figure 1.4   Feedback pattern for a process-centric enterprise

What is the major barrier to enterprise optimisation in this figure? It is that different parts of the enterprise business system use different descriptions of the same process. Usually, these descriptions are constructed separately by different people and do not exchange the necessary information, and some of them may not even exist explicitly in a particular enterprise.

The use of software-intensive systems to automate the operations part of process-centric enterprise business systems allows the elimination of this barrier by creating a single formal description of the business processes. This description should be explicitly and formally defined to be good as both a simulation model and an executable program.

Such a description is the main concern of the BPM discipline, which allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise's systems, employees, customers and partners within and beyond the enterprise boundaries.

Different functions of the BPM discipline are spread throughout the enterprise business system as shown in figure 1.5.

Figure 1.5   BPM discipline in the enterprise business system

All these functions use a formal description of business processes. At the moment of writing of this book, within the BPM industry there is no appropriate system of standard formats for the formal description of business processes. The three most popular formats (BPMN, BPEL and XPDL) were created by different groups and for different purposes:

• BPMN -- Business Process Modeling Notation, was created by the OMG (www.omg.org) to provide a graphic representation of models of business processes [7];
• BPEL -- Business Process Execution Language, was created by OASIS (www.open-oasis.org) to provide a formal execution of the interaction between web services [8];
• XPDL -- XML Process Description Language, was created by WfMC (www.wfmc.org) to provide the exchange of models of business processes between various BPM tools [9].

Unfortunately, these standards are not sufficiently complementary despite the standardisation efforts expended to date. The situation is aggravated by the fact that behind each format, there are various software vendors, and each of them is trying to "push" its format on the market. As has been seen many times in similar struggles, the interests of the customers are insufficiently taken into consideration (and at present there is not a sufficiently powerful organisation lobbying for the interests of the BPM customers).

Ideally, there should be a single master format which can be transformed into different formats suitable for different needs. [This is similar to the case of electronic documents which may be available at the same time in XML, PDF and PostScript but, in the majority of cases, only the master format (i.e. XML) is truly editable.]



... to be continued in fragment 05 ...

Thanks,
AS