Ideas for #BPMshift - Delenda est "vendor-centric #BPM" - Does BPM help with 50% of EA #entarch ?

BPM as a trio of methodology, architecture/practice and tools (often COTS or FOSS) defines a lot for enterprise architecture.

Let us see at the TOGAF layers: (values are approximate and calculated on number of non-trivial issues)

• 60 % of business architecture
• 50 % of data/information architecture
• 70 % of application architecture
• 20 % of technology architecture 

(60+50+70+20) / 400 = 200 / 400 = 50/100

In addition,

1. BPM can improve information security (see http://improving-bpm-systems.blogspot.ch/2014/04/ideas-for-bpmshift-delenda-est-vendor.html ).
2. BPM provides a powerful company-wide governance capability because a company is a system of processes (see http://improving-bpm-systems.blogspot.no/2014/03/enterprise-as-system-of-processes.html ).

Maybe to start your EA from a properly architected  BPM? Benefits are huge - http://improving-bpm-systems.blogspot.ch/2014/05/ideas-for-bpmshift-delenda-est-vendor_9.html

Thanks,

AS

Ideas for #BPMshift - Delenda est "Vendor-centric #BPM" - How can a company benefit from a BPM initiative?

This blogpost lists some company-wide benefits of BPM (as a trio methodology, practices/architecture and COTS & FOSS tools).

Customer Value Delivery

Better fit to the customer experience because it is be considered as a process ( see http://improving-bpm-systems.blogspot.ch/search/label/CX ).
Higher business agility (speed-to-market) because many of improvements are anticipated by design (see http://improving-bpm-systems.blogspot.com/2014/05/ideas-for-bpmshift-delenda-est-vendor_8.html ).

Quicker adoption of best business practices (i.e. patterns – see http://improving-bpm-systems.blogspot.ch/search/label/practical%20process%20patterns ) and in-house innovations.

Higher quality of service because an interaction with a customer may happen at any point in a process (not just from the front-office) and all exchanges between an employee and a customer are traceable (see http://improving-bpm-systems.blogspot.ch/2014/04/bpmshift-delenda-est-vendor-centric-bpm.html ).

Operational excellence

Collection of objective performance measurements.

Total transparency and traceability.

Real-time view on operations for various roles.

Proactive risk management and mitigation as it is based on processes (see http://improving-bpm-systems.blogspot.ch/search/label/ERM ).

Predictability of operations including automatic detection of performance bottlenecks ( see http://improving-bpm-systems.blogspot.ch/2010/03/linkedin-how-do-we-measure-work-flow.html ).

Better information security (see http://improving-bpm-systems.blogspot.ch/2014/04/ideas-for-bpmshift-delenda-est-vendor.html ).

Objective and predictive balancing of workload.

Compliance by design.

Ability to quickly improve and repair processes (see http://improving-bpm-systems.blogspot.ch/2013/04/bpm-for-developers-improve-agility-of.html ).

Link between the strategy and its execution

Provisioning a powerful company-wide governance capability because a company is a system of processes (see http://improving-bpm-systems.blogspot.no/2014/03/enterprise-as-system-of-processes.html and http://improving-bpm-systems.blogspot.ch/2015/02/iceberg-of-processes-within-enterprise.html ).

E2E incremental improvements can be carried out in accordance with business pace and business priorities (http://improving-bpm-systems.blogspot.no/2014/05/ideas-for-bpmshift-delenda-est-vendor_8.html ).

Faster path to a digital company (see http://improving-bpm-systems.blogspot.ch/2013/02/towards-paperless-or-digital-or-less.html ).

Better impact analysis of changes because of explicit linking between events, rules, roles, documents, KPIs, etc.

Provisioning a solid foundation for enterprise architecture because BPM defines a lot for enterprise architecture. (see http://improving-bpm-systems.blogspot.ch/2014/05/ideas-for-bpmshift-delenda-est-vendor_11.html ).

Boosting employee motivation

By eliminating manual, tedious work, people focus on higher value (core business value-added intellectual) activities.

Allowing staff to focus on more added-value work.

Better visibility on what people and others are doing in the company.

More accurate job descriptions and fact‐based performance evaluation metrics.

Improving working relationships by common language between various roles (primary between business and IT).

Organisational structure is derived from processes (with fine-turning around talents).

Smoother change management because of transparent design, transparent decisions, transparent execution which make people more comfortable with changes.

Better application architecture

See http://improving-bpm-systems.blogspot.ch/2016/08/better-application-architecture-apparch.html and http://improving-bpm-systems.blogspot.ch/search/label/%23microservices
Thanks,
AS

Ideas for #BPMshift - Delenda est "vendor-centric #BPM" - How E2E optimisations with BPM are different from other enterprise-wise software initiatives?

This blogpost is an improved comment to the discussion Should Processes Be End-to-End? among BPM experts on BPM.com.

Many of participants consider that end-to-end (E2E) process optimisations are "Big Bang projects" which are more often "wasteful and expensive" and BPM should be deployed tactically. I disagree.

As an enterprise is a system of processes ( http://improving-bpm-systems.blogspot.no/2014/03/enterprise-as-system-of-processes.html ) then BPM (a trio of a discipline, architecture/practices and BPMS COTS products) is, by definition, strategic.

The essential beauty of BPM is that (unlike many other enterprise-wise software initiatives) BPM can improve the enterprise incrementally with the pace of the business and in accordance with the business priorities.

• It is not mandatory to model all business processes up-front.
• Doing E2E process does not imply one huge project – just proper governance of several mini-projects.
• It is possible to start small with mini-projects and build them up together.
• The next E2E “place” to improve can be determined by the business dynamically.
• Each incremental improvement may combine business improvements and technological improvements.

Often, E2E processes cannot be presented as a “normal” business process template. It is actually, a group of processes which are coordinated by other than “classic” template techniques (e.g. event-based technique, see  http://improving-bpm-systems.blogspot.fr/2014/03/coordination-techniques-in-bpm.html ).

To add other coordination techniques to current BPMS, it is necessary to go to enterprise architecture (or enterprise application architecture) level. This make E2E process optimisation project difficult for “classic” BPM specialists.

Right way of doing E2E business process optimisation implies:

1. doing the overall architecture ( consider a platform for execution of your business );
2. knowing how to build a platform incrementally ( http://improving-bpm-systems.blogspot.fr/search/label/PEAS ), and
3. carring out several mini-projects ( give them to “classic” BPMers ) under strong governance. 

If the architecture and governance are good then mini-projects can be done in parallel, thus the whole implementation can be shorter and smoother.

Thanks,
AS

Presentation at a #BPM mini-conference in Bergen, Norway

My presentation at BPM mini-conference in Bergen, Norway on 2014-05-06.

How EA, BPM, SOA and ECM work together from Alexander Samarin

As I didn't have a ready-to-show presentation "How can a company benefit from implementing BPM", I promised to provide a blogpost with this title.

It was first time I gave a presentation in a brewery.

Thanks,
AS

Ideas for #BPMshift - Delenda est "vendor centric #BPM" - How to bring shared services

In a few recent discussions, I was asked a question “How to introduce shared services”?

A typical context is that there are several semi-independent business units (BUs) with their own IT environments and, at one moment, the top management decided to introduce shared services.

Certainly, it is a daunting task because it touches application portfolio and operations. There is experience from a big company (500+ BUs) that several company-wide IT initiatives to bring standard applications to all BUs have failed. Because all BUs have different level of computerization, a standard application from the IT department is not good for everyone.

It seems that “application” (as a container of functionality) is too “big” and “smaller” containers of functionality are necessary. Thus services (as small containers of functionally) and processes (as a practice to assemble bigger services from smaller ones) should be used. In this case, shared services can be introduce as the following.

How to disassemble an application into services is described in http://improving-bpm-systems.blogspot.com/2014/04/ideas-for-bpmshift-delenda-est-vendor_27.html

Thanks,
AS

Practical Process Patterns: PAACP

A blogpost to outlines a typical procurement process in a highly-regulated environment -Procurement As A Cluster of Process (PAACP) (about cluster of processes - see http://improving-bpm-systems.blogspot.com/2014/03/enterprise-as-system-of-processes.html )

The main process start from a submitted Purchase Requisition (PR).
In accordance with the procurement policy, any PR are check against the corporate Delegation of Authority Matrix (DAM - http://improving-bpm-systems.blogspot.com/2012/07/practical-process-pattern-dam.html ) if the submitter are allowed to request this purchase.
Any goods/services in the valid purchase requisition can be sourced in three complementary methods. As one PR may contain several purchase items then many combinations of the sourcing methods may be initiated.

Sourcing 1 is just delivery from the corporate stock. PR becomes Purchase Order (PO).

Sourcing 2 is just ordering from an approved supplier. Of course, a contract must be prepared.

Sourcing 3 is (the most complicated case) to choose a supplier via an open bid.

The open bid process can be as the following (several variations are possible to determine "potential suppliers").

A process for annual planning of the procurement (thus replenishing the corporate stock) is trivial and not mapped.

Thanks,
AS

Ideas for #BPMshift – Delenda est “vendor-centric #BPM” – How to modernise a legacy ERP

I was recently asked for advice on how to modernise a legacy ERP. It was developed long time ago to handle the core business. Right now it shows the following symptoms of difficult maintenance:

• integration
• incorporation of new technologies
• old programming techniques
• heavy releases
• availability of industrial products for previously unique functionality (e.g. event management)
• some generic functionality is commodity
• just slow to evolve

Sure that the root cause is that the ERP had emergent/historical grow not being architected for such evolution.

The goal of modernisation can be formulated as the following:

1. Agile (with the pace of business) provisioning of business solutions
2. From disparate IT applications to a business execution platform which will “liberate” people for business innovations
3. Combine various provisioning methods: assemble, rent, buy, build, outsource, centralised vs. kept locally, standardised, re-engineered or automated

The principles of the modernisation are defined in the following way:

• Step-by-step technical transformation in two interrelated and intermixed streams:
1. Disassemble ERP functionality into services
2. Re-assemble business functionality via processes
• Business evolution has to drive technical transformation (each transformational step brings something to business and does some modernisation)

Let us start from the simplest part - assemble via processes

• A processes defines Who (roles) is doing What (business objects), When (coordination of activities), Why (business rules), How (business activities) and with Which Results (performance indicators)
• Business processes make bigger services from smaller services

Disassemble an application into services schematically looks as the following:

Of course, disassemble of an ERP is more complex:

Advantages of this approach are the following:

• Use of specific functionality from COTS (e.g. event management)
• Use of generic functionality from “suites”
• In-house developing ONLY specific-business-core-functionality
• Integration of commodity or best-to-fit functionality
• Faster evolution is possible because of BPM/SOA architecture

In case of transformation of a group of related legacy applications – please see http://improving-bpm-systems.blogspot.com/2013/06/enterprise-patterns-eclipse.html

Thanks,
AS