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
- 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
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 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).
- 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
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.
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.
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).
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.
- if a resource is not available then processes are queuing for it.
- resource requires replenishment if its capacity is below a threshold.
- offering new services and products as the result of the field servicing.
- changing of legal conditions (to renegotiate a maintenance contract).
- market campaigns.
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
Error-recovery relationships between processes
Other factors to considerNote, 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.