2014-04-29

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






2014-04-27

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

2014-04-16

Ideas for #BPMshift - Delenda est "vendor-centric #BPM" - enchancing the information #security

Enterprise functioning can be considered as business activity flows spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise. Staff as well as tangible and intangible resources are involved in each business activity. Ensuring of the information security implies the following characteristics of the enterprise functioning:
  • Any business activity is performed only as prescribed and any unintended use of information (e.g., access to information resources unrelated to the work performed) would be impossible in principle. 
  • Organization and initial planning of business activities must be validated for the compliance with the formal rules of information security. 
  • Execution and operational planning of business activities must be constantly validated for the compliance with the formal rules of information security. 
In this blogpost, it is show how BPM can contribute into enhancing the information security.


Control of access to an informational resource along the process


In simple cases, the control of access to an informational resource can be rigidly connected to the phases of the life cycle of the resource. The latter can be implemented as a business process. Explicit and executable business process is convenient because the whole dynamic of control access is embedded in the process.


This allows better control of access rights change.

Control of access to an informational resource within an activity


In more complex cases, information resources linked to specific business activities. An employee, appointed for the carrying out of a particular business activity, gets access to the information resources required for the carrying out this business activity, only for the duration of this business activity.


Objective operational data collected, who has/had access to what information resources will increase the level of information security.


Separation of duty within a business process


In a simple form, the separation of duty is a check that the actual work to be done (“Do” in diagram below) and the validation of the result of this work (“Check” in diagram below) are always carried out by separate staff members.



Thus, business processes can detect potential cases for the separation of duty by establishing relationships between business activities.


Separation and imposition of duty among several business processes


In a general form, relationships between business activities should be established and formally registered. A non-inclusive list of such relationships is the following: 
  • Other activities which validate the results of the given activity.
  • Other activities which define the governance for the given activity.
  • Other activities which do the handling exceptional situations for the given activity (error handling, escalations, send for review and delegate).
  • Other activities which audit the given activity (1st, 2nd and 3rd party audit).
  • Other activities which evaluate the risks before the given activity.
  • Other activities which evaluate the risks after the given activity.
  • Other activities which certify the given activity (1st, 2nd and 3rd party certification).
  • Other activities which do compensation (undo) for the given activity.

These relationships between activities define some limitations that roles and actors may carry out what activities: the same actor or a different actor from a different role or a different actor from the same role. For example, if the “Activity_B” validates the results of “Activity_A” then no actor should be in “Role_1” and “Role_2” simultaneously.


Thus, the separation of duty maybe formally validated at the design-time.


Management of risk along business processes


Managing any work by processes is the key business capability with allows to address the risk-related issues in a proactive manner. The risk is strongly related to how the business processes are carried out. By understanding a process (i.e. through being able to simulate it) the business may predict how the risk is changing during the execution of that process. The explicit description of processes permits to add a few “check-points” within any process to examine its risk-related “health”.

Business processes act as a skeleton to which the enterprise adds risk management (as shown on the picture below) – each usual activity is enriched by risk-related monitoring and evaluation.



The risk evaluation may initiate some risk mitigation processes. The risk evaluation may be as complex as necessary, and it may include simulations (e.g. value at risk and stress testing), and the conduct of statistical and scenario analysis.


Delenda est "vendor-centric BPM"
AS

2014-04-15

Ideas for #BPMshift - Delenda est "vendor-centric #BPM" - case for fusion of bank's front- and back-offices

The recent quotes digest in http://www.bpm.com/Blogs/bpm-quotes-of-the-week-april-11.html starts with my text "“Business is no longer a front and back office – all of your enterprise is the front office. Classic ad-hoc/dynamic processes and classic static processes will co-exist in the same BPM execution environment.”

This quote is based on the real story. It is usually not a problem for bridging front-office processes and back-office processes in their HAPPY PATH (see http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html ).  It is much more difficult to bridge them in their ERROR-RECOVERY PATH. 

The story details.
  1. A client has a standing order defined in an e-banking system (front-office). 
  2. The e-banking system passes the payment to the bank's back-office system on each 25th of month.
  3. Once, the transaction initiated by the back-office it was rejected by the recipient's bank
  4. The back-office (which is based on a good BPM suite) starts its recovery-error process.
  5. That error-recovery process got struck in the back-office and the client didn't know about the failed transaction although money were debited from the client's account.
  6. The recipient has complained to the client.
  7. The client replied to the recipient that the e-banking shows that the order has been processed.
  8. The recipient has complained again.
  9. The client submitted an inquiry via the e-banking system.
  10. Somebody has replied that the back-office can't process the order for some reasons.
  11. The client called the front-office contact person - conseiller.
  12. The latter did some magic, requested to repeat this transaction again and confirmed that the money will be refunded in a few days.
The total elapsed time for this saga was 20 days. This means that during 20 days the client's money were lost BETWEEN the front-office and the back-office of a world-wide bank. Just wander what adjustment of internal business processes was made in this bank to avoid similar cases.

This bank is using a BPM suite for its back-office; There is no information about the implementation of its e-banking system. Ideally, the latter should be also process-based. But, as there is a huge fragmentation of the vendor-centric BPM market, modern BPM tools create "islands of BPMing". 

Thus the BPM industry must moving from vendor-centric BPM to customer-centric BPM.

Delenda est "vendor-centric #BPM",
AS




2014-04-09

Ideas for #BPMshift - Delenda est "vendor-centric #BPM"

From http://blogs.gartner.com/elise-olding/2014/04/02/introducing-bpmshift-bpm-is-dead-long-live-big-change/ and http://www.linkedin.com/groupItem?view=&gid=1847467&type=member&item=5857498506226319361 and http://bpm.com/my-bpm/forums/is-a-big-change-ahead-for-bpm

“At Gartner we believe that BPM practices as we know them won’t cut it in the future.”

Agree, the current BPM practices are non sustainable - BPM is often the reinventing the wheel in each enterprise, in each process and in each BPM tool. I think that the root-cause is the vendor-centric nature of the current BPM.

As any normal industry, the BPM industry must have 
  1. commonly-agreed BPM terminology, 
  2. a BPM reference model (for example, http://improving-bpm-systems.blogspot.ch/2010/02/bpm-reference-model-fragment-01.html ), 
  3. BPM reference architecture, 
  4. process patterns (for example,http://improving-bpm-systems.blogspot.ch/search/label/practical%20process%20patterns ) and 
  5. view that enterprise is a system of processes (for example, http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html).

Ideal BPM practices should be able:

With the ideal BPM practices, the Elise’s list can be addressed in the following way:
  • is no longer a front and back office – all of your enterprise is the front office ==> classic ad-hoc/dynamic processes and classic static processes will co-exist in the same BPM execution environment.
  • employee is customer facing ==> a task for a customer may happen at any point in a process (and all exchange between an employee and a customer will be traceable).
  • will fall to the wayside – emerging organizational structures like holocracy will replace traditional org structures ==> process template will define the optimal org structure to execute the processes
  • view of end-to-end processes will be obliterated – order to cash will not exist ==> system of processes will may have more complex topologies
  • analysis will replace process analysis ==> process template and data collected from process instances will be used to analyse the behaviour of enterprises and customers
Delenda est vendor-centric BPM,
AS