Re: BPM vs. BPMS: How To Think Big and Act Small

This is a reply to http://isismjpucher.wordpress.com/2012/08/27/bpm-vs-bpms-how-to-think-big-and-act-small/ blogpost.

Thanks Max for a good post which is commented below from my "managing by business processes (BPM) methodology" (www.samarin.biz/book and http://improving-bpm-systems.blogspot.com/).

I disagree with you that BPM == "flow-charting". Certainly, BPM may use several coordination techniques – see http://improving-bpm-systems.blogspot.com/2012/07/coordination-techniques-in-bpm-social.html 

Also, I disagree with you that "adaptive processes" are not possible in BPM – see http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html

I agree with you that BPM as discipline and BPMS are very different things. In my experience, they can be perfectly used within a proper architecture (i.e. “to think big”).

My experience relative “The NINE Contradictions in BPM Implementation Principles” (BTW, what is the origin of those principles?) is below.

• If BPM would be capable of being business-driven then there is no need for executive enforcement.
  AS: It is possible to be business-driven if BPM is properly architected.
• If the implementation of processes would really happen through users there is no need for governance.
  AS: It is for business to decide. Some governance is always necessary, maybe business one not IT one. 
• As business users can maybe draw a flow-diagram but can’t make it executable, the BPM stages are all performed by experts, actually reducing agility.
  AS: Not necessary “reducing”, as the IT agility maybe higher (thanks to the architecture) than the business agility. 
• Both BPM methodology and BPMS ignore that users understand processes in terms of content and context and not in flow-diagrams.
  AS: Not at all. Processes are positioned as the help for the users to carry out their work including also the handling the content. 
• To change business culture is a long term prospect and collides with short ROI time frames.
  AS: BPM applications are the best example of agile projects. The ROI is great. 
• What kind of culture change should be necessary to motivate people to follow flow-diagrams all day.
  AS: Again, disagree that BPM == “flow-diagrams” 
• To reduce scope creep and ensure ROI, governance limits end-user requirements and achievable quality.
  AS: IT governance or business governance? In any case, late changes of user’s requirements are very welcome. 
• A holistic BPM methodology is then fragmented over many different software products for implementation.
  AS: Yes, BPM is vendor-driven so far. 
• As the fragmentation requires governance, any change requires long-term planning and therefore reduces actual business agility.
  AS: The architecture enables the agility. 
• If a BPMS is chosen to match current needs and maturity level then it has to be replaced frequently as the business matures.
  AS: The architecture also helps with this. 

At the same time, I agree with your “ ...the following is needed to make BPM work” list.

Obviously there are several different BPMS, few BPM methodologies, a huge number of BPM implementations, but still missing parts are BPM reference model and BPM reference architectures.

Thanks,
AS

Illustration to ebizq.net "How big is a process?"

An illustration to http://www.ebizq.net/blogs/ebizq_forum/2011/02/how-big-is-a-process.php

From my book "Improving enterprise business process management systems":

We recommend introducing control-oriented coordination using a step-by-step approach
via the “eclipse” pattern (see figure 5.6). At first, we “cover” only a tiny area of the whole process. Usually we start with the intra-application coordination, because this part of IT is considered as boring and not very rewarding. The first fragment of explicit coordination may be quite primitive; it is a duplication of some existing functionality which is just eclipsed by this process. Then we introduce more and more fragments. With time, we cover bigger and bigger areas by explicit coordination of existing fragments.

Figure 5.6 Use of the “eclipse” pattern for making coordination explicit

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

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: Why Process Approach?

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

I am with Scott – processes can be a company’s most valuable asset. To realize potentials of this asset I used the following “techniques” in implementing enterprise business process management (BPM) systems (see the difference between BPM discipline, BPM system and BPM suite - http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html):

1.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. (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.

2. It is not enough to capture processes – they have to work or “be actionable”. The aim is to have a single description of business processes which is used by different people in different parts of an enterprise:
• model in design
• input for project planning and implementation
• executable program for coordination of work
• documentation for all staff members
• base for taking management decisions

Sure that a good architecture which combines BPM, SOA, EA and other technologies and methods is very desirable to realize potentials of processes.

Thanks,
AS

Linkedin: How do you look at BPM ? Is it a link between IT and Business?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=70120&discussionID=12657424&sik=1264751381706&trk=ug_qa_q&goback=.ana_70120_1264751381706_3_1" />

Although, the classic EA documents enterprise assets (or artefacts), there is still a lack of explicit knowledge about how the “enterprise genotype” (a full nomenclature of enterprise artefacts) defines the “enterprise phenotype” (a set of observable characteristics such as performance).

Agree with previous posts that proper use of BPM is the way to structure such explicit knowledge. I recommend to consider enterprise BPM systems (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 - see http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html ) and to architect them with the following principles:

• All artefacts (events, processes, services, rules, roles, data, documents, activities, KPIs, etc.) 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 (e.g. a business process is a complex relationship between many other artefacts).
• All models are made to be executable (this is the essence of the BPM discipline – what you model is what you execute).

Considering that EA does a great job in describing the “enterprise genotype” and there are many techniques to evaluate the “enterprise phenotype”, then the BPM with its executable models of relationships between artefacts can form the bridge (an enterprise executable model) between the “enterprise genotype” and the “enterprise phenotype”.

Thanks,
AS

Linkedin: Is it required for a BPMS to have IT systems like CRM, ERP etc. in an organisation or is BPMS alone capable of handling such complexity???

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=41075&discussionID=12709315&sik=1264408758735&trk=ug_qa_q&goback=.ana_41075_1264408758735_3_1" />

I would say that existing specialized systems can be eclipsed by a BPM suite (similar to a astronomical event).

From the architecture of the business as a system, a process is an executable and explicit relationship between many artefacts: processes, services, events, rules, roles, business objects (data structures and documents) , audit trail, KPIs, etc. Any modern BPM suite greatly facilitates assembling those artefacts into processes. But, very often those artifacts are actually locked and “diluted” into existing applications, e.g. CRM and ERP. So, if you can externalize atrefacts from existing applications then you can move any coordination of work (i.e. workflows) from existing applications to your BPM suite.

Such approach – coordination of several specialized systems by a specialized system (i.e. BPM suite) can help you to use better some commercial off-the-shelf (COTS) or “canned apps”. Because they are eclipsed by a BPM suite, their missing functionality can be added with some generic tools (such as business rules engines, BAM, BI, etc.) connected directly to the BPM suite. So, there is no need to customize COTS. This is like the renovation of an old farm when good old walls are amalgamated with the new structure.

My opinion is that BPM suites should concentrate first on the full life cycle of business processes (model, automate, execute, control, measure, optimize) and leave other artefacts to other specialized systems. For example, ECM for documents. CRM and ERP may become repositories for business objects such as materials, customers, etc. as well as some business rules. Such repositories may produce some business events which initiate some processes.

Thanks,
AS

LinkedIn: Process Mapping - How to Stop the madness?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=2057992&discussionID=12653567&sik=1264241010512&trk=ug_qa_q&goback=.ana_2057992_1264241010512_3_1" />

A few recommendations.

1. Clarify the context

It is necessary to ask a few times WHY they need 2000 processes to get a fuller context as Kenneth said. ( your < aligning everything with the customer and correspondingly aligning the business strategy to that and so on down to the process level> is a good approximation)

2. Discover the architecture (as a tool)

What “process architecture” do they have or envisage? It is
a) a nomenclature of main artefacts (i.e. processes)?
b) a set of principles for governing the design, execution and evolution of this portfolio? c) a holistic approach with balanced amount descriptive (i.e. the item “a” above) and prescriptive (i.e. the item “b” above) aspects?

Is this processes architecture aligned with business architecture? Or do they want that this processes architecture will be a “centre of crystallization” for future business (and enterprise) architecture?

In any case, some understanding HOW this set of processes will EVOLVE and will be USED is necessary.

3. Defined your way how to eat an elephant [tip: together and piece-by-piece]

3.1 Start from top-down step-by-step detalisations of the big picture by structuring TOGETHER processes/services/capabilities and other artefacts (something like http://improving-bpm-systems.blogspot.com/2009/11/linking-concepts-and-expressions-used.html ). The top of the enterprise (i.e. business model, business architecture) is a slow-moving part of the enterprise (agree with Susan), so “AS-IS” is very valuable – agree with Dick.

This can be done by a BPM architecture team together with the top management. A few important considerations about this horizontal span over the organization:
• Please, do not forget to include into models EXPLICITLY external participants (customers and partners).
• Where to stop this detalisation? Sensing the feedback of the top management – this big picture should be understandable by everyone.

3.2 Then carry out a few vertical spans to demonstrate and develop internal modeling/etc. practices. This can be done by the BPM architecture team and line management/super users/IT architects/etc. If necessary, develop a few quick prototypes.

3.3 Present the results to the top management, listen/reflect their feedback, and tune the practices.

3.4 Train line managers to use those practices and let them advance with their processes by themselves.

3.5 Monitor and help/guide them if necessary.

Note: After the first iteration you may get a mixture of "as-is", "to-be", executable, etc. maps. This will show the maturity of processes and experience of people within the organisation. Use it for next iteration.

Thanks,
AS

Linkedin: Process Consulting ! Steps / Tools / Input / Output

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=113496&discussionID=8252361&commentID=7342881#commentID_7342881" />


1) visit their production to look over the shoulders what they are doing
2) choose a group of super-users and train them about BPM and business process modeling
3) select a few business areas and do business process modelling with the super-users for these areas
4) train their IT about BPM/SOA
5) implement with their IT a few operational prototypes for the selected business areas
6) present the results to the top management
7) listen/reflect their feedback
8) tune the used methodology (i.e. my book "Improving enterprise BPM systems") for their needs
9) let them improving their processes by themselves
10) help/guide them if requested



Thanks,
AS

Linkedn: Is there more to modern application architecture than SOA? How do we include BPM, data management and Web 2.0?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36604&discussionID=7512884&commentID=7157050&goback=.anh_36604#commentID_7157050" />

The business world understood a long time ago that services and processes are the backbones of most enterprise business systems.

A service is defined as "an explicitly-defined and operationally-independent unit of functionality". A process is defined as "an explicitly-defined coordination of services to create a particular result". So, at a process-centric enterprise we may have many elementary nano-services which are organised into a mega-service, i.e. the whole enterprise.

Services and processes are related in the following way:
- all our processes are services,
- some operations of a service can be implemented as a process, and
- a process includes services in its implementation.

Often, it may be useful to consider a service as a black box where no information about its implementation is available. Alternatively, it may be useful to consider a service as a white box where implementation details of all its operations are available.

Although the relationships between processes and services are unique and rather complex in each enterprise, the use of explicit definitions allows the formalisation of dependencies between them.

If we look at BPM then we can see three different concepts:

1. 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

2. BPM system -- enterprise portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

3. BPM suite -- coherent set of software tools for facilitating the implementation of a BPM system

At the same time, SOA -- architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services

The relationships are between SOA and BPM are:
SOA provides recommendations for the implementation, execution and governance of services. The BPM discipline, by revealing the BPM artefacts and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services. Ideally, a BPM system is built with the use of SOA and a BPM suite often acts as a tool to provide composite services.

Business processes are VERY important because they serve as an EXPLICIT implementation of some services thus allowing determine/calculate the performance of those services. So, the capabilities of those services are known, proven and controllable – what the business wants.

In addition, the proper design of business processes and architecting BPM system can add a lot of flexibility into a business system.

Thanks,
AS

Linkedin: Architecting BPMS Platforms...

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36248&discussionID=7932821" />


The abbreviation BPMS is assumed to be “BPM suite” -- coherent set of software tools for facilitating the implementation of a BPM system. The latter is a portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio.

So, architecting of BPMS depends on architecting of enterprise BPM systems. In the latter, business rules are building blocks used within business processes.

The relationships between services and processes are the following:
- all processes are services,
- some operations of a service can be implemented as a process, and
- a process includes services in its implementation.

As the result, any enterprise has its own unique structure of services/processes; but there are some common patterns. Please note, that this is a product-independent view which may be different from ESOA.

Actually, services which are fully implemented by processes may be considered as capabilities.

Thanks,
AS

Linkedin: What is the connection/relation between Biz Architecture and BPMS?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=84758&discussionID=7932497&sik=1254599906913&commentID=7082844&goback=.anh_84758.ana_84758_1254599906913_3_1#commentID_7082844" />


At first, talking about business architecture (BA) is relevant if the business is considered as a system. So, BA concentrates on the conceptualisation and evolution of the form and structure of the top level view of an enterprise as a system for conducting the business.

Remark 1: This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals.

Remark 2: The issues of greatest importance for BA are the following:
- the core end-to-end business processes (also known as value streams);
- the governance structures;
- the core business information (semantics);
- the communication with the core business partners.

The abbreviation BPMS is assumed to be “BPM suite” -- coherent set of software tools for facilitating the implementation of a BPM system. The latter is a portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

Remark: Any process-centric enterprise has its own enterprise BPM system. The enterprise BPM system may not be perfect (e.g. some processes may be only documented on paper, some details are only “located” only in the minds of certain people, etc.), but it does exist.

So, your enterprise BPM system has to be design in accordance with your BA and BPM suite is a tool (which is necessary, but not sufficient) for implementing your enterprise BPM system.

Thanks,
AS

Blog: Demo vs. Production BPM-based Systems

<discussion ref="http://mainthing.ru/item/212/" />

Bravo, Anatoly. This is an excellent overview of some problems originated in mixing of "BPM as software" (a.k.a. BPM suite) and "enterprise BPM system" (what is implemented within an enterprise to manage its business processes). See also --- http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html

Sure that a modern BPM suite is necessary, but not sufficient for a good enterprise BPM system - "an aircraft carrier should never operate alone".

In the absence of agreed reference models and proper standards, creating good enterprise BPM systems implies serious architecting efforts. Below I comment your list from the architectural point of view.

1. Your own enterprise "worklist" application has to be considered regardless of a BPM suite "web portal". The users want to handle business processes in conjunction with their business objects, e.g. business cases.
2. Business events (receiving an order) are often already available somewhere in your enterprise systems. Just link them with your processes.
3. Automatically generated forms are usually considered only for quick prototyping.
4. Existing reports are usually considered only for quick prototyping.
5. By definition, business objects as BPM artefacts have to be externalised. Dreaming to keep them within a BPM suite is wrong from the beginning.
6. Audit trails and KPI are other BPM artefacts -- put them out of a BPM suite, by definition.
7. Documents are yet another BPM artefacts. Keep them out and do not forget about records management.
8. Handling of roles (also a BPM artefact) is usually difficult. I usually recommend to create a set of groups oriented to processes, e.g. process owner, activity workers, etc. and to populate these groups from available resources (processes are useful for that).
9. Agree - patterns and anti-patterns are necessary for constructions of complex processes (see my blog http://improving-bpm-systems.blogspot.com/ for some practical process patterns).

I think that any discussion about the architecture of enterprise BPM systems is step from the current vendor-centric BPM to customer-centric BPM.

Thanks,
AS

Linkedin: Failure to manage processes can become expensive

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1062077&discussionID=6365776&commentID=5952169#commentID_5952169" />

I think, this is an example that the use of BPM is repeating "Pitfalls of automation" (see a good article in http://www.geocities.com/CapeCanaveral/Hangar/2883/automate.html ). Another sign of this repetition is some discussions about human processes vs automated processes.

In my experience, there are neither only human processes nor only automated processes. Each automated activity within a process should be encapsulated into an "error-recovery loop" which may include a human activity. For example, a fully automated conveyer at a car factory has some side lines to "do" some cars manually.

A fully "automated" process may have a human task to watch the process - in the same way that an observation window allows one to observe the workings of a turbine.

Each human activity is surrounded by automated activities - similar to a good secretary who prepares documents for a boss and later takes care about them.

So, to comment Thomas' list:
- Don’t only rely on automation,
-- more automation requires adequate controls (also automated)

- augment it with appropriate process management methods,
-- In addition to production (or horizontal) processes, I recommend to develop some controlling (or vertical) processes; the latter helps people to validate execution of production processes.

- define proper rules for process managers that don’t only cover system functionality but also address process results,
-- controlling processes may signal potential problems to humans as well as propose some adjustments. For example, an assurance company guarantees that each claim is processed in less than N days (i.e. there is an SLA) and claims over 50$ are checked manually; when this company receives a wave of claims, a controlling process by detecting this wave may propose either to increase the staff for checking those claims or to adjust a limit (from 50$ to 100$) so more claims will be treated without manual check.

- responsibility and accountability should play equal parts in process management jobs and should address clearly defined processes,
-- who is responsible for a process template, a process instance, a process activity.

- don’t design your processes for the sunshine case only – also look at process risk management issues.
-- fault-tolerance, error-recovery, comprehensive traceability, etc. are important for BPM design and execution; actually, the power of BPM helps us to address those issues in different ways, e.g. if a problem is caused by a user then a super-user may receive a task to resolve this problem.

Thanks,
AS

Blog: Is Enterprise Architecture sociotechnical systems (STS) design ?

<discussion ref="http://beyondinformation.blogspot.com/2009/07/is-enterprise-architecture-social.html" />

As any modern enterprise is a socio-technical system then any enterprise-wide activity, e.g. EA, enterprise BPM, should explain to all stakeholders of this activity how this activity will address their concerns and improve their work. For detail, please, see the second part (from slide 23) of http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation


Thanks,
AS

Inside Business Architecture: End to End Process Optimization is Overrated

<discussion ref="http://insidebusinessarchitecture.ning.com/profiles/blogs/end-to-end-process" />

I think, it would be useful to _explicitely_ separate the e2e optimisation of process template vs the e2e optimisation of process instance. See for details a recent post -- http://improving-bpm-systems.blogspot.com/2009/07/linkedin-bp-group-soapbox-1-process-is.html

Thanks,
AS

Linkedin: Are You Prepared to Practice 3-Dimensional Process

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1062077&discussionID=4933019&commentID=4950034&goback=.anh_1062077#commentID_4950034" />

Very interesting discussion about “dimensions”. Try to contribute from the architecture side.

I think that any enterprise BPM system (see http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html for its definition) is a complex and dynamic set of interconnected and interdependent artefacts. For BPM the most important types of business artefact are:
- events
- processes
- activities
- rules
- roles
- objects(data and documents)
- audit trails
- key performance indicators (KPIs)
- services

The evolution of some artefacts and the relationships between them is necessary to accommodate typical changes in enterprise policies, enterprise priorities, compliance, technology, laws, etc. So, to be agile and responsive in business, it must be easy to modify all artefacts and their relationships without causing any negative effects (e.g. unexpected delays and undesired consequences) in any part of the BPM system.

I think that the four main architectural principles are necessary to achieve a high level of flexibility:
1. All artefacts must be versionable throughout their lifecycle.
2. All artefacts must evolve to become digital, externalised, virtual and components of clouds.
3. All relationships between artefacts must be modelled explicitly.
4. All models must be made to be executable.

More relationships are explicit and executable –> more knowledge about functioning of the enterprise -> more predictable results -> more rational decisions -> more comprehensive optimisation.

The best example of explicit and executable relationships between business artefacts is process -- who (role) is doing what (objects and activities), when (coordination of activities), why (rules), how (activities) and with which results (KPIs).

I think this approach follows the discussion, especially the previous post from Michael.

Thanks,
AS

Linkedin: BP GROUP SOAPBOX 1: Process is an Effect

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=4785748&gid=1062077&commentID=4815511&trk=view_disc" />


Re "... a much more complex process architecture" I offer the follow fragment from my docs.

<quote>
1.6 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 below). 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.



</quote>

Thanks,
AS

LinkedIn: Survey Finds BPM Projects Lack Architecture -- Redmond Developer News

<discussion ref="http://www.linkedin.com/newsArticle?viewDiscussion=&articleID=47812036&gid=1062077&trk=NUS_RITM_more" />

Architecture (as an architectural framework) is ready for BPM projects -- see http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation

This architectural framework is designed to help architects to translate a customer’s requirements into a viable plan and to guide others in its execution.

Thanks,
AS