Definition of #BPM and related terms, again

This post is prepared to the LinkedIn discussion "Definition of BPM" http://www.linkedin.com/groupItem?view=&gid=70120&type=member&item=5812680199795388416 which is aimed to prepare a stand-alone definition of Business Process Management (BPM). See also http://social-biz.org/2014/01/02/bpm-definitions/

For me, before talking about a stand-alone definition, let us agree on some basics. Below,  the several terms, related to BPM, are defined.  The definition of a term is in bold; other occurrences are in italic. 

Discipline is a coherent set of governing rules .

Business activity is a unit of work. Individual business activities are interrelated. The relationships between business activities are static (expressed as structure) and dynamic (expressed as behaviour).

Enterprise functioning can be considered as business activity flows spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise.

Business process is an explicitly-defined coordination for guiding the purposeful enactment of business activity flows.
Note: In other words, a business process is an agreed plan (to follow some activities) and its enactment; the plan may include some variants and will possibly allow for some changes during its enactment.

Process template is an abstract description of a process.

Process instance is an enactment of a process template.

Relationships between process template and process instance are described in http://improving-bpm-systems.blogspot.ch/2010/12/illustrations-for-bpm-acm-case.html

Management discipline is a discipline for the better management of the enterprise functioning in support of the enterprise goals.

Process-based management discipline (TQM/QMS, BPR, TPS, 6Sigma, BPM, etc.) is a management discipline which exploit the concept of “business processes”.
Note: They are also called process-based management disciplines.

Business process management (BPM) is a process-based management discipline for the use of any meaningful combination of modeling, automation/implementation, execution, control, measurement and optimization of business processes.

Note 1:
"Meaningful" is an operative word, because execution of business processes differentiates BPM from other process-based disciplines.

Note 2: 

How BPM is differ from other process-based management disciplines? BPM considers all 6 functions (modelling, automation/implementation, execution, control, measurement and optimization) holistically, although they can be distributed in space (e.g. for different divisions of an enterprise) and in time (e.g. optimization based on process feedback). For example: 

• Classic workflow – model, automate, execute, control (primarily by monitoring) 
• TQM/QMS – model, control, optimise (primarily, with corrective actions) 
• BPR – model 
• TPS – everything is potentially in place, but rather implicit 
• 6Sigma – measure, optimise 
• Case management – execute, control 

Note 3:

This definition covers all spectrum from “fixed” to “chaotic” processes.  For example,

• A general plan is agreed and details are for the choice of performer = project (see http://improving-bpm-systems.blogspot.ch/2014/01/is-project-management-bpm-application.html ).
• A general plan does not exist, but there are standard procedures = case
• All pre-defined and fixed = classic workflows
• All pre-defined and changes are possible if justified = some old workflow systems allowed changed but not friendly to users
• Nothing is ever defined = process to be mined

Imagine having all of this in one box, like a gear box - lower transmission -> more manoeuvrability 

A possible stand-alone definition of BPM can be as the following (WHY it is need, HOW it is done, WHAT is used):

Business Process Management (BPM) is coherent set of governing rules to better management of the enterprise functioning in support of the enterprise goals for the use of any meaningful combination of modeling, automation/implementation, execution, control, measurement and optimization of explicitly-defined coordination for guiding the enactment of business activity flows spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise. 

A variant with the direct substitution:

Business process management (BPM) is < a coherent set of governing rules> for the use of any combination of modeling, automation/implementation, execution, control, measurement and optimization of business processes.

Thanks,

AS

#entarch, #bizarch, #BPM, #SOA, #ECM and patterns are working together, example 1

Recently, I was involved in a few discussions about what should be a target enterprise architecture for a decentralised enterprise. For example,

1. “Bank decentralisation” - bank wants to build the international presence and thinks about decentralisation, 
2. “Rationalisation of acquired businesses” – company, which bought several hundred businesses wold-wide, would like to align them, 
3. “Legacy ECM modernisation” - already distributed company wants to modernise applications (mainly based on ECM) at its local branches. 

The main concern of the target enterprise architecture is the enterprise application architecture. How to build an inexpensive (no duplications) and flexible (easy to innovate) business-execution environment?

As the first case “Bank decentralisation” has more input, it will be used further as the base. Only additional considerations will be mentioned separately for two other cases.

The situation

Now Bank establishes branches at international locations and there is a need to customize products and services, as well as processes (Currency Management, Risk and Compliance, etc.), as per a given location, i.e. Local Office (LO).

At present, there is a BPM practice at the Bank, i.e. at the Global Office (GO). Processes for Front Office, Back Office and Middle Office are identified for four levels. Also known list of technologies, applications and databases which are supporting business functions. No Enterprise Architecture in place. Plan is to set up an EA practice with a complete Enterprise Architecture in place.

Questions

1. Set of processes for the GO may be customised to the needs of a LO. How? Shall the structure of processes be the same? Shall separate BPM practices be established at each location? If “yes” then how to exercise the centralised control?

2. How to manage data for Global Operations and how services will relate to information required from various Local Operations and how processes will support that (say a Centralized Reporting System)?

3. What would be Enterprise Architecture for the Bank (what capabilities, processes at a global level, how capabilities interoperate, what will governance mechanism, what will be centralized functions etc.). How various change activities will be managed?

4. Centralized BPM practice or separate BPM practice for individual locations?

Answers

Sure, it is mandatory to have a solid EA practice to carry out the change like decentralisation. Also it is mandatory to achieve the synergy between BPM and EA.

Platform

When an enterprise is going to operate from various locations (with potentially different capabilities) then a corporate platform for the business execution should be created and deployed at each location to avoid unjustified duplications among various locations.

The enterprise pattern PEAS outlines the design of such a platform ( http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html and http://improving-bpm-systems.blogspot.ch/search/label/PEAS  ).

BPM (as a trio of discipline, practice/architecture and tools), should be the primary component of the platform to allow easily combining of common services/processes/patterns with location-unique services/processes. In some sense, BPM with executable processes is a tool for assembling business solutions from services.

De facto, this is a step towards SOA which is an architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services. SOA re-shapes the enterprise application architecture from the provisioning of monolithic applications to the assembling solutions from a validated set of in-house, commercial, open-source and rented services. (Service is an explicitly-defined and operationally-independent unit of functionality).

The proper use of BPM/SOA affects all levels of enterprise architecture:

• business – identification of processes and services from the business context;
• application – implementation and assembling of processes and services;
• data – transportation of data between services, and
• technology – running and monitoring processes and services not applications which may increase the number of units of deployment by factor 50.

At the business level, the following should be considered:

• Enterprise pattern “Anisotropically Distributed Organisation” (ADO) - http://improving-bpm-systems.blogspot.ch/2013/09/enterprise-patterns-anisotropically.html - handle variations between GO and LOs;
• Modelling procedure - http://improving-bpm-systems.blogspot.ch/2013/07/bpm-for-business-analysist-modelling.html - to have a common way for finding processes and services ;
• Business Decision Management (or business rules at the business level) as different LOs may have different decisions, and
• Other process patterns ( http://improving-bpm-systems.blogspot.ch/search/label/practical%20process%20patterns ), 

At the application level the following should be considered:

• The pattern “Cloud-Aware Processes and Services” (CAPS) - http://improving-bpm-systems.blogspot.ch/2011/07/enterprise-patterns-caps.html - to have a common structure for process-centric applications ;
• Cloud-related patterns- http://improving-bpm-systems.blogspot.ch/search/label/cloud - to have common rules for putting services into clouds , and
• Other enterprise patterns - http://improving-bpm-systems.blogspot.ch/search/label/enterprise%20patterns

Two examples can be useful as well:

1. e-government - http://improving-bpm-systems.blogspot.ch/2013/10/entarch-e-government-and-e-governance.html , and
2. healthcare - http://improving-bpm-systems.blogspot.ch/2013/10/entarch-to-help-heathcare.html .

Information collection

To collect all necessary data, processes should be enriched to proactively push business and execution data to required local and central repositories. Very similar to the http://improving-bpm-systems.blogspot.ch/2011/10/ea-view-on-enterprise-risk-management.html .

IMPACT on EA; governance and capabilities

Knowledge of “list of technologies, applications and database” is necessary but not sufficient for executable processes. Usually, more granular artefacts must be known: services, data structures (XSD), documents, KPIs, roles, rules, audit trails. EA will certainly is the right tool to find them and BPM is the right tool to link them together as executable processes. Again, the challenge is not only to add EA practice, but also to achieve the synergy between EA practice and BPM practice.

The GO provides a standard set processes, services and other artefacts; any LO may have (limits are explicitly defined) its own local set of customised processes / services and other artefacts (as a local copy of standard one). All processes, services and other artefacts are are under strict governance (versioning, life-cycle, etc.). Several version of the same artefacts may co-exist. If a LO uses a standard version of process/service then it can be executed centrally or locally or cloudly. See enterprise pattern #Cloud-Ready Estimation and Evaluation Procedure (CREEP) - http://improving-bpm-systems.blogspot.ch/2011/12/enterprise-pattern-cloud-ready.html to formalise the choice of the cloud.

It is important to establish good terminology (including relationships between capabilities and processes - http://improving-bpm-systems.blogspot.ch/2013/03/bizarch-artefacts-definition-again.html ) and make explicit the relationships between business and technical capabilities - http://improving-bpm-systems.blogspot.ch/2013/02/linking-business-strategy-and-it.html ).

Platform Centre of Experience (COE) organisation

It is necessary to talk about platform COE not just BPM COE. The target topology is a combination of the central/global COE (reflection, global optimisation, standards) and local/regional COEs (client care, flexibility, assembling of solutions).

The central COE distributes new services, new version of old services, new processes and new version of old processes. Local COEs estimate the impact and update their customised processes if necessary.

Case “Rationalisation of acquired businesses”

Pattern “Eclipse” shows how the transition from applications to processes & services - http://improving-bpm-systems.blogspot.ch/2013/06/enterprise-patterns-eclipse.html ,

Case “Legacy ECM modernisation”

The important requirement for the modernisation of legacy ECM is that current encoded-in-code business processes become explicit and executable (by BPMs) business processes. This will a) enable the future optimisation without big changes and b) avoid the repetition of the existing approach with new technology. So, such a modernisation is a transition from ECM to ECM+BPM.

Thanks,
AS

SlideShare - my content was among the top 2% of most viewed on SlideShare in 2013!

Exciting news! 

My content is among the top 2% of most viewed on SlideShare in 2013. http://slideshare.net/yearinreview/samarin/jeo4AA

Thanks,
AS

#BPM à la Zen style

Last week I had a chance to look at a new BPM product from www.effektif.com

I found very correct that this product starts with minimalistic and very simple interface. Something like BPM in Zen style – just define tasks, find them in the inbox and perform them, but perfectly straightforward for the end-user.

Why this approach is correct? Because

1. in a good tool simple things are done simple;
2. the end-users start with the minimum thus with less up-front learning;
3. the tool remains open for classic BPM, ACM, case management and project management (as we know that they are converging);
4. more complex techniques for creation and coordination tasks can be plugged-in to the tool (e.g. a simple definition of processes is already available);
   
   
   
5. a library of predefined process fragments or executable patterns can be added as well;
6. the end-users are allowed to do that they can without traditional limitations from the IT;

Another very useful feature of the tool is that it is available from the cloud. Again, it is a step to making the use of BPM simpler for small groups, training courses and enterprises. 

Hope that the company will add quickly some functionality to simulate processes. This would simplify the understanding of BPM by the end-users.

More information about the tool will be found at http://www.effektif.com/news/effektif-launch-webinars/

Thanks,

AS

Is project management an #BPM application?

At present, the BPM community is discussing a common definition of BPM (Business Process Management).

My favourite is "Business process management is the discipline to model, automate, execute, control, measure and optimize the flows of business activities that span the systems, employees, customers and partners within and beyond the enterprise boundaries."

This definition is emphasizing that BPM is helping you to carry out all this 6 verbs EXPLICITLY and TOGETHER. It is actually your choice if you want to carry out any combination of them.

Also, my definition of business process is an explicitly-defined purposeful coordination of works.

In the LinkedIn discussion (http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=5812680199795388416&gid=70120), I found that that project management is an BPM application! Because the project management discipline is doing everything as BPM and a project plan is a particular form of process:

• Modelling of future work by PMO which supplies some standard (or enterprise-wide) procedures as shown below and by the project team which defines Gantt diagrams; PMO does the modelling for all projects and project team does the modelling for its project by defining many interrelated business activities. 

• Automation by PMO which supplies some standard docs for all projects
• Execution (actually, self-execution) by all team members (and services involved, e.g. procurement) of business activities assigned to them
• Control by the project manager of schedule (planned, actual,  projected), resources (planned, actual,  projected), cost (planned, actual,  projected), scope (planned, actual,  projected),  etc.
• Measurement by the PMO of all projects
• Optimisation by the PMO of standard procedures and documents, and by SMEs recommendation for particular types of projects

Of course, the project management uses a simple way to model the coordination of work within projects (i.e. Gantt diagrams) thus making simulation rather easy. 

Shall we stop talking about "project management" vs "process management"?

Shall we start talking about how to use BPM to streamline project management? 

Thanks,

AS

I am supporting the WfMC Awards for Case Management

I am in the "List of Supporting Organizations" for WfMC Awards for Case Management
http://adaptivecasemanagement.org/orgs_list.html

Thanks,
AS