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