Importance of executable processes and BPMN

Importance of executable
processes and BPMN
Alexander Samarin for LAMS EPFL
May 2014, Lausanne

• A digital enterprise architect
– from a programmer to a systems architect
– have created systems which work without me
• WHY I do what I do
– I believe that many improvements (“sooner, better, cheaper, more
flexible”) in operational excellence and strategy execution are
achievable with reasonable efforts and commodity tools
• HOW I do what I do
– architecting synergy between strategies, technologies, tools and
best practices for client’s unique case and transfer the knowledge
• WHAT is the result of my work for clients
– less routine work, less stress, higher performance, higher security,
less risk, higher predictability of results, better operations, and
liberating the business potentials for innovations
Importance of executable processes and BPMN v3 2
About me
© A. Samarin 2014

• Context
• Why BPM is critically important for EA?
• Enterprise as a system of processes
• The power of executable processes
© A. Samarin 2014 Importance of executable processes and BPMN v3 3
Agenda

– It is not about “just the website”, “online services” or
“transactions”
– Everything becomes digital:
products, information, content, documents, records, processes, m
oney, rights, communications
– If digital then intangible thus news tools and new execution speed
“immediately”
– Digital things are at new scale – petabytes and exabytes
– With this new speed and scale, there is no time for human
intervention and errors in routine operations and at interfaces
Digital age

• Experience shows that business wants separate requests
for change to be implemented quickly in existing IT
solutions and systems
• These changes are typically small (from the point of view
of the business) and unpredictable (from the point of
view of the IT)
• To carry out these changes easily and in a managed way,
business systems must be properly architected / designed
/ engineered
Business reality

• Different estimations of the development/maintenance
life-cycle cost ratio
Solutions need to be adaptive
2 – Estimated average in the IT
industry
maintenance
development 80 %
20 %
2
40 %
60 %
1
95 %
5 %
3
3 – A real scenario (governmental
client)
1 – Estimated by an IT staff member

• Co-existence of many artefacts
– vision, plans, processes,
capabilities, services, etc.
• Dynamic and interrelated
• Not all relationships between
artefacts are explicit
• Not all relationships between
artefacts are interpreted
consistently by different staff
members and systems
• Small changes can be very destructive
Complexity

• There are two different sources of complexity:
– natural as we use more and more complex products produced by
more and more interlinked companies and
– undesired as we do things with inadequate tools, without using
the best available knowledge, via communicating in not the
“same” language, by reinventing the wheel, following
contradictory recommendations, drawing a process and executing
something else, etc.
• The purpose of enterprise architecture (EA)
– guide solution architecture to follow the natural complexity to
avoid adding undesired complexity
– promote the use explicit and executable techniques to reduce
the natural complexity
– “liberate” resources to better handle the natural complexity
Managing complexity

• Context
Agenda

• EA coordinates people, processes and technologies in 4D
1. Business domain span (organisational
unit, segment, enterprise, supply
chain, government, country, region, continent, …)
2. Architecture span
(business, data, application, technology, security, information, …)
3. Time span (solution life-cycle, technology life-cycle, tool life-
cycle, project life-cycle, enterprise life-cycle, …)
4. Sector span (common patterns in unique processes from different
sectors)
EA is a systemic coordinator

EA views: business domains vs time
span

• There are no:
– common dictionary / terminology / reference model
– common recognition
– common certification
– common professional organisation
• Considered as too bureaucratic, “ivory tower”, expensive
and useless paperwork
• A lot of fight among (often self-proclaimed) “enterprise
architects”
• You may become an “enterprise architect” in 4 days
• So far, we, enterprise architects, are alchemists
Enterprise Architecture is not a “normal”
profession yet

BPM is a tool for improving enterprise
business performance
The theory
BPM as a discipline
(use processes to
manage an
enterprise)
The tools
BPM as software:
BPM suite (BPMS)
The practice
Any process-centric enterprise has some BPM (as discipline and
tool), but how can we industrialise this BPM?
A natural evolution of
BPR, Lean, ISO 9001, 6
Sigma
The aim is to have a single
description of business
processes:
- model in design
- input for project planning
and execution
- executable program for
coordination of work
- documentation for all staff
members
- basis for management
decisions
An enterprise portfolio of
the business processes
as well as the practices
and tools for governing
the design, execution
and evolution of this
portfolio
A multitude of tools “handle”
processes

Be ready for common
(mis-)understanding

• 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 activity is a unit of work
• A business process is an explicitly-defined coordination
for guiding the purposeful enactment of business activities
• Process-based disciplines (TQM/QMS, BPR, TPS,
6Sigma, BPM, etc.) exploit the concept of business
processes for the better management of the enterprise
functioning in support of the enterprise goals
BPM definitions (1)

• Business Process Management (BPM) is a process-
based discipline involving any combination of
1. modeling,
2. automation/implementation,
3. execution,
4. control,
5. measurement and
6. optimization
• of business processes
BPM definitions (2)

• An enterprise is a complex, dynamic and adaptive
system; one can improve it by:
– measuring
– observing
– deciding
– implementing
BPM reference model:
Improvement loop
1
2
3
4
© A. Samarin 2014

Process-based disciplines
© A. Samarin 2014

Process-oriented view of an enterprise
(before BPM)
© A. Samarin 2014

Process-oriented view of an enterprise
(with BPM)
© A. Samarin 2014

BPM suite components

BPM suite components (extended list)

• 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
Does BPM help with 50% of EA?

• Events
• Roles
• Data structures
• Documents
• Rules
• Audit trails
• KPIs
• Processes
• Services
BPM artifacts
KPIs
Processes
Services
Events
Roles
Data structures
Documents
Rules
Human
“workflow”
Audit trails

• Who (roles) is doing What (business objects), When
(coordination of activities), Why (business rules), How
(business activities) and with Which Results (performance
indicators)
• Make these relationships explicit and executable
What you model is
what you execute
“The map is the app”
Business processes are complex
relationships between artefacts

• BPM, by revealing the artefacts and the relationships
between them, provides the necessary context (e.g.
granularity) for the definition of services
• SOA provides recommendations for the implementation,
execution and governance of services
• BPM provides a mechanism for the explicit and executable
assembling of bigger services from smaller ones
Synergy between BPM and SOA (1) –
structuring relationships

• The relationship between services and processes is
“recursive”
– All processes are services
– Some operations of a service can be implemented as a process
– A process includes services
in its implementation

• Each enterprise is a complex, dynamic, unique and
“recursive” relationship between services and processes
– Services can be replaced by processes
– Processes can be replaced by services
– Some of them are moved to clouds
service process

from legacy application to processes and
services
Monolithic application
GUI screen 2
GUI screen 1
GUI screen 3
Business logic
Business object
“Partner”
persistence
Business object
“Competition”
persistence
Business object
“Event”
persistence
BPM/SOA modular solution
Business logic
service
Interactive
service 1
Interactive
service 2
Interactive
service 3
Coordination service
Business object
“Partner” persistence
service
Business object
“Competition”
persistence service
Business object
“Event” persistence
service

no applications – just coordination of
services

• Context
Agenda

• In the context of enterprise functioning, business
activities must be coordinated
• Various coordination techniques
– template-based
– state-based
– event-based
– role-based
– rule-based or decision-based or intelligence-based
– managerial (tacit knowledge)
– community-based
– instance-based or inter-process
– resource-based or life-cycle-based
– goal-based
Enterprise as a system of processes (1)

• Coordination maybe strong (e.g. as in the army) or
weak (e.g. as in an amateurs football team)
• Coordination maybe implicit or explicit
• Coordination maybe declarative (laws) and imperative
(orders)
• Based on coordination, let us think about “levels of
cohesion” between activities and thus find out
coordination constructs (in addition to activities)
1. process patterns (coordination within processes)
2. processes
3. cluster of processes (coordination between processes)
4. system of processes (coordination between clusters of processes)
Enterprise as a system of processes (2)

• Business case: typical “claim processing” process –
claim, repair, control, invoicing, and assurance to pay
Process fragments – patterns
SI
PAR
SI
IPS
Click for animation

• Business concern: Interactions between two independent
parties – public administration and partner (citizen, local
business, etc.)
• Logic
– partner submits some documents (including forms) to
administration
– administration checks those documents
– administration may request partner to provide more documents or
to carry out some corrections
– administration checks those documents again
– and so on
Process pattern:
Submission Interface (SI)

SI animated diagram
Click for
animation

• Simple event-based (which looks like a state machine)
Coordination between processes (1)

Coordination between processes (2)
1. state-machine
2. synchronous invocation
3. asynchronous invocation
4. fire and forget
5. parallel processes
6. co-processes (pattern SI)

• CLOPs are usually functional processes which are
implemented a particular business function, e.g. Field
Services
• And a “halo” of extra processes
1. monitoring
2. operating
3. governance
CLuster Of Processes (CLOP)

Enabler group, supporting group and
customer group of clusters

Is a system of processes like a PCB?

Implicit coordination between CLOPs (1)

Functional view at a system of processes (1)

• Context
Agenda

• Situation
– a company (3rd world-wide biggest in its sector) has about 800
semi-independent business units (BU); 130+ ERPs; 5 000 apps
– the strategy of the company has two contradictory objectives 1)
“Make the diversity efficient” and 2) “Standardize wherever it
bring value”
– several company-wide IT initiatives to bring standard solutions to
all BUs have failed
– as all BUs have different level of computerization, a standard
solution from the IT department is not good for everyone
Anisotropic enterprise and shared
services (1)
BU1 BU2 BU3 Standard
solution
Level of
computerization

Anisotropic enterprise and shared
services (2)
BU1 BU2 BU3
Level of
computerization
A CBB BAC
1) Standard
solution is based
on processes and
shared services
2) Each BU is
moving to
platform-based
architecture

• From disparate IT applications to a business execution
platform which will “liberate” people for business
innovations
• Agile (with the pace of business) provisioning of solutions
• Step-by-step technical transformation in two interrelated
and intermixed streams:
1. Disassemble into services
2. Assemble via processes
• Business evolution to drive technical transformation
• Combine various tactics: assemble, rent, buy, build,
outsource, centralised vs. kept locally, standardised, re-
engineered or automated
Legacy application architecture
modernisation

Disassemble a legacy ERP into services
Legacy ERP functionality
DM service B
DM service A
DM service C
Industrial ECMIndustrial ERP
HR
Fin
Procurement
Business logic
suite (BRM)
Coordination
suite (BPM)
Specific
service 1
Specific
service 2
Specific
service 3
In-house
development
10-15 % 10-15 %20-40 %10-20 %
Industrial generic suites Industrial specific
tools
Event
management
…
20-30 %
Note: Specified values are just estimations

• Make a platform with common capabilities
• Delivery unique solutions via processes and services
• Examples:
– E-government
– Healthcare
Other examples for processes + services
A2
A1
A3
Platform
S2
…S
1
S3
Functionality
Delivery by solutionsDelivery by applications
Scope

• First executable BPMN processes
• 10+ years on the BPM market
• Version 7 is just announced
• Intalio Create is a companion to Intalio BPM
• Intalio want to merge predefined processes and ad-hoc
processes
Executable processes from Intalio

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

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

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

Variant 4 – proactive planning (similar
to variant 3, but a few next activities
[fragment] are executed together)

Variant 5 – scenario-based (similar to
variant 4, but a few scenarios are
considered)
Process fragments are used; those may be patterns

• Customer value delivery
– Better fit to the customer experience because it is be considered as a
process (http://improving-bpm-systems.blogspot.ch/2013/06/practical-
process-patterns-cxaap.html ).
– Higher business agility (speed-to-market) because many of
improvements are anticipated by design (seehttp://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
(seehttp://improving-bpm-systems.blogspot.ch/2014/04/bpmshift-
delenda-est-vendor-centric-bpm.html ).
How can a company benefit from a BPM
initiative? (1)

• 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 ).
initiative? (2)

• 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 ).
– 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 ).
initiative? (3)

• Boosting employee motivation
– By eliminating manual, tedious work, people focus on higher value (core
business value-added intellectual) activities.
– Finally, BPM allows 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.
initiative? (4)

• QUESTIONS?
• Personal website: http://www.samarin.biz
• Blog http://improving-bpm-systems.blogspot.com
• LinkedIn: http://www.linkedin.com/in/alexandersamarin
• E-mail: alexandre.samarine@gmail.com
• Twitter: @samarin
• Mobile: +41 76 573 40 61
• Book: www.samarin.biz/book
Thanks
© A. Samarin 2014

Importance of executable processes and BPMN

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Importance of executable processes and BPMN

Similar a Importance of executable processes and BPMN (20)

Más de Alexander SAMARIN

Más de Alexander SAMARIN (16)

Último

Último (20)

Importance of executable processes and BPMN

Notas del editor