Enterprise as a System Of Processes

This blogpost is an attempt (inspired by www.bpm.com forums and http://thebusinessarchitect.accelare.com/2014/03/10/a-systems-view-of-business-architecture/ ) to understand how separate processes work together as one functional whole (i.e. a System Of Processes -- SOP) at the scale of an enterprise. Use of processes (and related to them constructions) will reduce the undesired complexity of an enterprise, improve understanding of its structure and behaviour, thus facilitates the management and evolution of the enterprise.

Basics of the management by processes

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). Those flows and individual business activities within them are interrelated. Flow emphasises that business activates are interrelated in time as well. So, the relationships between business activities are static (expressed as structure) and dynamic (expressed as behaviour).

Although any enterprise has its naturally complexity, the lack of explicit and codified knowledge about all relationships (static and dynamic) adds a lot of undesired complexity. The latter is the root cause why it is difficult to manage and improve enterprises. Often, even small changes provoke big disasters.

Historically, business process is the basic business concept to bring some order into the structure and the behaviour of interrelated business activities. A business process is explicitly-defined coordination for guiding the purposeful enactment of business activities.

In its simplest form, the explicitly-defined coordination is an initially agreed plan to follow a defined sequence of activities; the plan may include some variants and the plan allows some changes during its execution. A detailed, formalised and unchangeable plan (e.g. in a form of process template expressed in BPMN) is one of the several coordination techniques (see http://improving-bpm-systems.blogspot.fr/2014/03/coordination-techniques-in-bpm.html ). The explicitly-defined coordination reveals the structure and the behavior and thus reduces the undesired complexity.

Because the coordination can be strong (e.g. as in the army) or weak (e.g. as in an amateurs football team), it is possible to discover various constructs (in addition to business processes) within the whole structure and behaviour of business activities within an enterprise. Usually, the coordination between business activities which belong to a particular construct is stronger that the coordination between similar constructs. The number of relationships between business activities which belong to a particular construct is higher than the number of relationships between business activities which belong to different (but similar) constructs.

Thus, the knowledge about constructs reduces the number of potential relationships between business activities and allows concentrating on constructs themselves and relationships between constructs. Note that relationships between constructs can be implemented by different coordination techniques (see http://improving-bpm-systems.blogspot.fr/2014/03/coordination-techniques-in-bpm.html ).

Coordination within processes

It was observed that although all business processes are unique, they are actually composed from similar process fragments or process patterns. For example, let us consider a typical “repair” process in housing management which comprises claim making, evaluation, selection of a service provider, repair, control, invoicing and insurance to pay the activities. This process several is actually composed from a few process patterns as shown in illustration below (an original process model is covered by patterns).

Patterns used in this illustration are:

• Pattern SI – “Submission Interface” see SI presentation from the www.slideshare.net/samarin
• Pattern PAR – “Propose, Act and React” see 8.3.12 from www.samarin.biz/book
• Pattern IPS – “Initial Process Skeleton” see 8.3.7 from www.samarin.biz/book

Although any pattern is a highly-cohesive construct, patterns can be adapted to particular needs. For example, the Delegation of Authority Matrix (DAM) pattern is implemented differently in the procurement and in the project management.

Some process patterns are available at http://improving-bpm-systems.blogspot.fr/search/label/practical%20process%20patterns

In general, process templates must not be considered as something “fixed forever” – see http://improving-bpm-systems.blogspot.fr/2010/12/illustrations-for-bpm-acm-case.html

Coordination between processes

The coordination between processes is usually event-based (see the illustration below). In the simplest variant, the finish of a process is the start of another process. Note that it looks like the state-based coordination between processes.

In the reality, there are more complex interactions between processes (see the illustration below)

• the finish of one process is the start of another process – marked with circled “1”;
• starting another process and just waiting for its finish (aka synchronous invocation) – marked with circled “2”;
• starting another process and waiting for its finish sometimes later (aka asynchronous invocation) – marked with circled “3”;
• starting another process and not waiting for its finish at all (aka “fire and forget”) – marked with circled “4”;
• staring another process from one process and waiting for its finish in third process – marked with circled “5”, and
• co-processes (e.g. a pair of rock climbers tied together by a rope agree to climb one after the other, and not simultaneously -- see http://www.slideshare.net/samarin/process-practical-patterns-si).

Additional coordination techniques are also necessary because

• some event are generated outside of processes (typical case is a database trigger which is the data-base coordination technique);
• events are filtered between processes (see an example at http://improving-bpm-systems.blogspot.fr/2011/01/explicit-event-processing-agents-in.html for the event-based coordination). 

  

Cluster of processes

Processes ,which are strongly related to each other, form Cluster Of Processes (CLOP). They are usually functional processes which are implemented a particular business function, e.g. Field Services.

Halo of processes (HLOP) is a set of processes which helps to execute a particular CLOP; the former are monitoring, operating and governance processes for the latter. The processes from HLOP are also called leading processes.

• Monitoring processes are responsible for analysing the running functional processes – some sort of operational intelligence. 
• Operating processes are used for implementing operational (via available parameters or controls) changes. 
• Governance processes are used for detecting, designing and implementation of structural changes, e.g. “customer satisfaction and loyalty development”, “quality”, “strategy and planning” etc.

All together, they constitute two control loops – operational and strategic. Sometimes, extra health-check-points may be introduced for better monitoring of complex clusters.

At the operational loop, the following coordination techniques can be used:

• intelligence-based – using the data about the execution of processes, it is possible to predict the future behaviour of processes and to take proactively some mitigation measures to avoid troubles. For example, an insurance claim (functional) process has an SLA related to the maximum execution time and some threshold to automatically accept small-value claims; otherwise a claim should be checked by an operator. If the monitoring process has detected that there is a “wave” of claims and there is a risk that the SLA can’t be kept because of the staff limitation then the operating process can temporary increase the threshold to absorb the “wave”. 
• goal-based – as a typical business goal can be very hierarchy-structured (imagine a complex “fish-bone” diagram) and different sub-goals are supported by different processes, then some analysis of the actual situation related to achieving of goals may lead to adjusting some parameters in related processes or, even, starting of some processes. For example, if the HR cannot fill some positions then a process for reviewing the job descriptions for those positions can be initiated. 

Each CLOP may relate to the enabling group of clusters (EGOC), the supporting group of clusters (SGOC) and the customer group of clusters (CGOC). EGOC are typically specific for this CLOP while SGOC are common for several CLOPs.

Because of the natural recursion, a CLOP can be SGOC for some CLOPs. For example, a particular enterprise value system is a CLOP with SGOC of finance CLOP, IT CLOP, HR CLOP and procurement CLOP. Note that an enterprise may have several value systems.

Using the popular terms “core processes” and “supporting processes”, it is possible to say that “core IT processes” are “supporting processes” for “core business processes”.

Value streams and end-to-end enterprise processes are usually formed from a few CLOPs. In some sense, the whole enterprise is a “printed circuit board” in which CLOPs are connected “microchips”.

Coordination between CLOPs

Let us look at situations when some activities from a CLOP initiate (maybe even indirectly) activities in other CLOPs. The explicit coordination via event-based techniques is used in the form of “fire and forget”. For example, a service technician found that a particular piece of equipment must be replaced and he/she has to initiate an order to carry out this replacement.

The implicit coordination between CLOPs may happened as well. There are many situations in which one process is changing a business object and some non-trivial actions may be taken because of those changes. Also, a chain of changes may happen: a trivial change in a business object necessitates a change in another business object which necessitates a non-trivial action. And the business objects maybe of different types.

For example, a field service technician updated (in an activity in the process “close services”) his/her work order (business object 1) with a report which contains some lessons learnt. Those lessons learnt, after some validation, may be incorporated into the product maintenance guide (business object 2) or to the customer’s profile (business object 3). An analysis of customer’s profiles may reveal a need for some preventive maintenance (business object 4) or an opportunity for a custom project (business object 5).

Illustration below shows the separation between the update logic (change the state as the result of an external stimulus) and life-cycle logic (performing some activities that are related to a particular state).

More examples are below.

Coordination cases for business objects like products:

• product’s life-cycle which requires some works in future (e.g. a technical service of the car after each 20 000 km) – aka scheduling.
• eco-system influence, e.g. end of support/production for some components of a particular product.
• technology progress, e.g. the availability of a cheaper material/component of a particular product.

Coordination cases for business objects like resources:

• if a resource is not available then processes are queuing for it.
• resource requires replenishment if its capacity is below a threshold.

Coordination cases for business objects like customers:

• offering new services and products as the result of the field servicing.
• changing of legal conditions (to renegotiate a maintenance contract).
• market campaigns.

Typically, business object life-cycles are supported by custom applications and COTS (e.g. ERP, ECM). This makes difficult adding the coordination to existing life-cycles logic. A possible solution is to consider life-cycle as a process - http://improving-bpm-systems.blogspot.fr/2013/11/practical-process-patterns-lifecycle-as.html .

There are a couple of related techniques fro implementing the implicit coordination between CLOPs. A data integration process may be used for propagating data among several business objects (actually data repositories) as shown in illustration below.

Another technique is the “big data” or “business intelligence” approach when the data from various business objects is collected in one data warehouse and analysed by

Which technique is the best – all depends on a particular situation.

Functional view of system of processes

There is a definition of cross-functional (or end-to-end) process -- process which is understood differently by all participating organisational functions. This root cause of this effect is that separate organisational functions see the system of process from their functional silos. For example, department ZZ understands their process as show below.

Actually, their process is as show below.

And activities A and B are from processes of other departments as show below.

Again, implementation of functional processes separately will create a lot of undesired complexity.

Error-recovery relationships between processes

Another type of relationships which are very explicit. How CLOPs are linked for the error-recovery. For example, a client ordered a payment in an e-banking system (front-office). The e-banking system passes the payment to the bank's STP system (back-office) The latter tried to execute the payment and it was rejected by the recipient's bank. The back-office starts its recovery-error process which must start front-office recovery process BEFORE the client gets complains from the recipient.   Sounds simple, but it does not work in, even, in my world-wide bank.

Other factors to consider

Note, so far, both implicit and explicit forms of processes were treated equally. Typically, implicit processes are implemented within custom-built applications and ERP systems. Extracting important events from existing applications/ERPs is mandatory to exploit the power of processes.

In the worst case scenario, some processes are defined only on paper by the business and ignored by the IT.

Ideally, the target is explicit and executable business processes.

Thanks,
AS