1 Introduction
This blogpost was inspired by the following documents/discussions:
a) “BA and BPM Alignment Position Paper”
http://c.ymcdn.com/sites/www.businessarchitectureguild.org/resource/resmgr/BAtoBPMAlignmentPositionPape.pdf
b) “Harmon on BPM: Processes and Capabilities”
http://www.bptrends.com/processes-and-capabilities/
c) Linkedin discussion “Business Architecture and Process”
https://www.linkedin.com/groupItem?view=&gid=84758&type=member&item=195960665&commentID=-1&trk=groups_item_detail-b-jump_last#lastComment
In addition, the several related blogposts are listed at the end of the document.
2 About definitions, as usual
There are two basic architectural concepts which must be clearly defined:
- capability because it is essential for bizarch – as stated in ref. a).
- business process because it is essential for BPM
Having them defined, it is possible to define bizarch and BPM. But, a definition of “function” is useful as well.
2.1 Function
Function is abstract grouping of activities that collectively satisfy a specific operational purpose (e.g. management of relationships with partners). Functions deliver identifiable changes to assets.
A business function typically has the suffix ‘management’ in its name (e.g. ‘Customer Relationship Management’), but it can also be a noun (e.g. ‘Marketing’); usually, function name specifies something that is performed continuously.
Functions are unique within the enterprise and should not be repeated. Functional viewpoint has a hierarchical structure. Its structure is very static (with a low rate of change).
The functional viewpoint emphasizes WHAT the whole enterprise does to deliver value to the customer (without the organizational, application, and process constraints).
Some organisational units can span several functions; furthermore, organization charts (organigrammes) may change while the function does not.
2.2 Business process
The several definitions of process mentioned in refs a) and b) are correctly saying that process is
HOW work is accomplished in an enterprise, but they emphasize on non-important details such as “set of activities” or “series of activities” or “inputs into outputs”
Considering an enterprise as a set of activities or as a “magic” box with inputs and outputs is a bit shallow approach (like defining a forest as a group of trees instead of Complex ecosystem in which trees are the dominant life-form). The essence of the process is the coordination of business activities for desired functioning of an 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 coordinate some activities) and plan’s enactment; the plan may include some variants and will possibly allow for some changes during its enactment, i.e. by re-planning.
Also, popular related terms are:
Process template is an abstract description of a business process.
Process instance is an enactment of a process template.
Relationships between process templates and process instances are described in ref. 10) which shows that processes maybe very flexible and they cover “case management”.
Properly done, a business process serves many purposes:
- a model and communication tool during the design period;
- input for project evaluation (including impact analysis);
- input for project planning and execution;
- an executable program for the coordination of work;
- documentation for all staff members;
- a “single source of truth” for operating control and monitoring;
- a framework for internal control and security enhancement;
- the basis for management decisions.
2.3 Clearing several wide-spread misunderstandings about business processes
1 No explicit separation between “planning of work” (i.e. process template) and “observing work” (i.e. process instance)
Because practically all definitions of “business process” does not emphasize the fundamental difference between “planning of work” and “observing work”, then the majority of people understand “process” as “process instance”. Because that natural processes are actually observed sequences of connected changes, people equate “natural processes” with “business processes”.
But, the line managers’ primary interest is in “planning work”, not “observing work”.
2 Process transforms inputs into outputs
This resource-centric view of processes is popular because flow of resources is very visible (especially before the digital era) and it is used by the IDEF0 notation, but the visible moving resources is managed by a less visible coordination. Business process is a flow of control and not a flow of resources (tangible and intangible ones including value). Also, there are processes without input, output or both.
3 Business process is consider as a flowchart
It is fundamentally wrong to equate business processes to flowcharts. The latter is only one, although very popular, coordination technique that can be exploited by the former. See ref. 9) for details.
Flowcharts are used for expressing strong coordination (and thus tight coupling) between business activities. Inter-functional or inter-departmental coordination is much weaker thus other coordination techniques (e.g. event-based or goal-based) are used to express coordination between processes from different functions or departments. But, explicit weak coordination can improve the enterprise flexibility and agility.
4 Business process equals to BPMN
The BPMN standard makes explicit only a few, primarily, flowchart-based and, slightly, event-based coordination techniques. Other coordination techniques are covered by other various industry and de-facto standards such as CMMN, TDM, EPN, etc.
Business process may use many coordination techniques – see ref. 9).
5 An end-to-end process can be expressed as a flowchart
End-to-end processes cross many organisational units and functions. Such processes require, in general, several coordination techniques not just flowcharts. For example, ordering physical items (e.g. books) from an Internet shop (e.g. Amazon) is a group of flowchart-like processes: 1) order a group of books, 2) process single book and 3) collect books into a parcel. Some of these processes handle multiple objects per instance, others handle one object per instance (thus exist as several instances). Coordination between processes should be implemented by events.
6 Business process is just an illustration of the real work
The well-known catch-phrase “all models are wrong, but some are useful” is mistakenly applied to process models. Properly done, process model is a key for an “algorithm” to run the business. Such a process model is a skeleton for an implementation.
The power of business process is in their ability of being executable that means that process instances are enacted, which may include automated aspects. Conceptually, the process instance executes itself, following the process template, but unfolds independently of the author or owner of the process template.
The following table compares illustrative
processes and executable.
Usage of
business processes
|
Illustrative
model
|
Executable
model
|
Example
|
|
|
Coordination
of work
|
Subject to personal interpretation
|
Commonly agreed and objective
|
Corporate
knowledge
|
Usually disconnected from reality
|
What we know is what we do
|
Source for
operating control
|
Post factum
|
Proactive
|
Framework for
internal control
|
Based on willingness
|
Enforced objectively
|
Framework for
information security
|
Usually not considered
|
Dynamic and proactive
|
Basis for
management decisions
|
Subjective and post mortem
|
Objective and on-demand
|
7 Coordination may be implicit
Often, the explicitness of the coordination is forgotten and the same process is modelled “service-like” (as the right part of the illustration below) instead of being a normal flowchart (as the left part of the illustration below).
8 Process is a flow-of-resources - see
http://improving-bpm-systems.blogspot.ch/2015/01/business-process-in-bpm-flow-of-control.html
Not exactly. By definition, process is a flow-of-control and the flow-of-resources can be derived from the flow-of-control.
Note: Flow-of-control uses a special marker (token) to indicate which activities are active. This is analogous to a well-organised meeting where the chairperson decides who talks next.
2.4 Capability
In accordance with ref. a):
business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.
From the systemic point of view, capability is an attribute of a component of a system and not a component in its own right. The word “business” in the above definition may mean any structural component of an enterprise, e.g. the whole enterprise or a particular function. It is correct to say “capability of an enterprise”, “capability of a particular business function” or “capability of a particular business process”.
Capability is a performance-estimation of a component-in-focus as a black-box with all other components which are used by this component-in-focus as shown in the illustration below. (green arrows are values, red arrows are expenses, width of arrows is proportional amount of values or expenses). See ref. 5 for details.
Because the definition in ref. a) does not mention any quantifiable measures (thus sounds binary – possess vs not possess) then this definition probably is about performance-
qualitative-estimation.
As just performance-qualitative-estimation, capabilities are classifications not hierarchies.
Although capability-as-a-performance-
qualitative-estimation is a very useful concept, it is not sufficient to reply to all questions from business leaders. For example, the president of a regional development bank asked: our investment fund will be twice bigger next year – do we need to double the IT department to manage this new fund?
Thus, it is necessary to consider also capability-as-a-performance-quantitative-estimation. Although, quantitative measurements are more difficult to obtain than qualitative ones, the former are more useful than the latter as decision-taking input. An example of such measurements is given in ref. 11). Executable processes is the base for performance-quantitative-estimation of the business.
The relationships between capabilities, functions, processes and services are illustrated below.
2.5 Business Process Management (BPM)
A reduced copy from refs 6) and 7).
Discipline is a coherent set of governing rules.
Business activity is a unit of work. Individual business activities are interrelated somehow. The relationships between business activities are static (expressed as structure) and dynamic (expressed as behavior).
Enterprise functioning can be considered as business activity flows (or streams) spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise.
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”.
Business Process Management (BPM) is a process-based management discipline for the use of any combination of
- modelling,
- implementation (potentially including automation),
- execution,
- control,
- measurement and
- optimization
of business processes.
2.6 Business architecture
In accordance with ref. a):
Business Architecture is a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.
It is commonly agree that a business is a system thus architecture of a system is more than, in accordance with ref. a), “a logical scheme for defining system’s interfaces and arranging system’s components”. Enterprise architecture practice considers that architecture of a system is about:
- relationships between its components and
- the principles governing the design, implementation and evolution of a system.
Structure is only visible (often static) part of relationships; behaviour is (often invisible) dynamic part of relationships. It seems that the above definition of business architecture is taking into consideration only the visible relationships (blueprint is an architectural plan for people who are creating a particular version of an enterprise).
It seems that the Business Architecture Guild (www.buisnessarhcitectureguild.org) considers bizarch as a discernible representation of the current state of enterprise from particular viewpoints – which is mainly the item 1 from the previous list. At the same time, “the principles governing the design, implementation and evolution of a system” are not explicitly addressed by the business architecture from Business Architecture Guild yet.
2.7 Value stream
In accordance BIZBOK 3, value stream is “An end-to-end collection of activities that create a result for a customer, who may be the ultimate customer or an internal end-user of the value stream.” Value stream is decomposed into stages which are “A distinct, identifiable phase or step within a value stream that has a unique name, entrance criteria, exit criteria, and identifiable participating stakeholder(s).”
Although value stream sounds like processes, the ref. a) provides an explanation why value-stream and process are different. This explanation will be discussed below.
3 Comparison framework from the ref. a)
The ref. a) defines a comparison framework based on four key concepts. Below these concepts are applied to BPM and business processes without the mentioned above wide-spread misunderstanding.
Span of control – As processes are flows-of-control and processes may use various coordination techniques (not only flowcharts) then processes may span the applications, employees, customers and partners within and beyond the boundaries of the enterprise. The “longest” processes we manage are “end-to-end” processes.
Decomposition – Decomposition (analysis) is only a half of process implementation and it is followed by composition (synthesis) to get the desired performance (output, expenses and value). Composition is responsible for obtaining more than just a sum of components (synergy). Decomposition and composition are defined by a practicing process modelling procedure, e.g. as presented in ref. 14.
Triggering and End states – A process must have a start and, maybe, some finishes; they are as precise as contracts because each process behaves as a service from an external point of view.
Exchange interfaces – A process may use some services in its implementation. A service may be implemented as another process or not.
4 Value-streams vs processes
4.1 Resume
With a proper understanding of processes and BPM, a value-steam is a value-centric viewpoint of end-to-end processes which highlights value-achievement milestones and some value-added activities. The use of BPM makes value-streams quantitate.
4.2 Span of control
Processes’ span of control is not artificially limited. It is a choice of stakeholders. Thus there is not difference between processes and value-streams.
4.3 Decomposition
Because value-streams are decomposed into stages, this management construct (value stream and its stages) looks like a set of sequential value-based milestones because they are concentrated on achieving some results (i.e. created value).
Making explicit such big steps or stages is a normal process modelling technique – see modelling procedure in ref. 14.
4.4 Triggering and end states
Value-streams are equivalent to end-to-end processes concerning begin and end states.
4.5 Exchange interfaces
The explicit way of composition of processes (formal) and value-streams (informal) shows how a “big” value is created from “smaller” ones.
5 Capabilities vs processes
5.1 Resume
With a proper understanding of processes and BPM, capability is a performance-oriented viewpoint on processes as black-boxes. The use of BPM makes capabilities quantitate.
5.2 Span of control
Because a capability is a performance viewpoint on a particular business functionality which can be rather complex (i.e. an enterprise) then a single flowchart (which is the understanding of processes used in ref. a) cannot be matched to a capability.
With the proper understanding of processes, a group of linked (via explicitly coordinated) processes expressed as flowcharts can correspond to a capability.
5.3 Decomposition
It is very correct that processes equated to flowcharts are difficult (and often just impossible) to present as a consistent hierarchy. The use of various coordination techniques allows to implement (and thus match) a complex capability as a group of linked (via explicitly coordinated) processes which are expressed as flowcharts.
5.4 Triggering and end states
Capability is a static viewpoint. Processes are dynamic viewpoint. Obviously their start/finish events are differently. But, capabilities, processes, services and functions are about a functional entity within an enterprise.
5.5 Exchange interfaces
Process is an explicitly-defined relationships between events, rules, roles, data, documents, services, audit trails and KPIs. Thus processes are richer constructs than capabilities.
6 Enterprise-is-a-system but a system-of-what?
No doubts that an enterprise is a system with many components of various artefacts (or concepts or types). There are many (static and dynamic) relationships between these artefacts. Some of the artefacts are “free” variables in these relationships and other artefacts are “bound” variables. For example, an enterprise may add more and more staff members (free variable) into a project, but this only will make the project later (project time is a bound variable) as it is stated in the Brooks’ law, “Nine women can't make a baby in one month”.
What are the essential artefacts for bizarch?
Ref. a) lists some of them: “As part of the practice of business architecture, we separate the concern of what we do (capability), from who does it (organisation), from how value is achieved (value stream), from how it is done (process), from the information that is needs from the systems that are use, and so on.”
Actually, there are many business-related artefacts which are listed below.
Strategy artefacts
- business drivers
- business goals
- strategic objectives
Governance artefacts
- business directions
- business model
- functions
- capabilities
- organisational structure
- portfolios
- policies
- operational model
- AS-IS and TO-BE states
Management artefacts
- risks
- compliance
- decision rules
- projects
- KPIs
Operations artefacts
- services
- processes
- staff members
- decision rights
- knowledge
- audit trails
- events
Value artefacts
- products (tangible)
- benefits (intangible)
- customer experience (intangible)
- value system, value chains, value streams
- cost
- assets (tangible)
- capabilities (intangible)
- information (intangible)
- expenses (negative cost)
All these artefacts are somehow interrelated to each other. Is there an artefact X which “defines” all other artefacts? Is there a system-forming artefact? Then we can say that an enterprise-as-a-system-of-artefact-X. How to find this artefact X?
Let us select some of them (capability 1, capability 2, process, value, expenses) and make a table with relationships between them: e.g. artefact A (in a row) influences artefact B (in a column).
We can see that there is a circular relationship between capability and process. Problem? No, just a natural recursive. Higher-level capability is WHY for a process and the process defines WHY for lower-level capabilities as shown in illustration below.
Important, that only the top-level WHY is coming from “outside”; but all other WHYs are results of the process modelling. It means that an enterprise-is-a-system-of-processes. Practically all others artefacts may be derives from processes. See ref. 8).
Note that capability is WHY for a service, but the latter does not make its composition explicit thus no further recursion.
7 bizarch and BPM reconciliation
Just a few points:
- Value-stream is a value-centric viewpoint on processes (especially, end-to-end or high-level processes). value-stream is a flow-of-assets.
- Capability is a performance-oriented viewpoint on functions (and process & services).
- Capability is a measure of performance – quantitate or qualitative.
- Quantitate measures require proper (primarily executable) composition model of how a bigger component is made from the smaller components, e.g. process-based.
- Basic terminology for business architecture (primarily, capability, function, service and process) should be publicly discussed and commonly-agreed.
- Business architecture (as defined by Business Architect Guild) should progress from “blueprint” to normal architecture (probably under guidance of the enterprise architecture).
- Business architecture (as defined by Business Architect Guild) should progress from a static/qualitative architecture to dynamic/quantitate one.
- Vision “enterprise-is-a-system-of-processes” should be further discussed to be, potentially, commonly-accepted.
- BPM and executable processes are the key to enterprise-is-a-system-of-processes.
- Enterprise-is-a-system-of-processes is the key for dynamic and quantitate business architecture.
Some BPM benefits are listed in ref. 12).
Posts
