Business process architecture and business change #3
This is the third in a series of articles adapted from a paper on Business Process Architecture and Business Transformation [Lawrence (2008)1] which appeared in the 2008 BPM and Workflow Handbook published by the Workflow Management Coalition (WfMC). The full paper is available from www.makeworkmakesense.com.
Previous articles in the series:
The series explores the relationship between logical process architecture and business change. As in the earlier series on Business processes and business rules the discussion employs a proven business process meta-model. The meta-model is one not derived from technology, but from an analysis of what it is to be a business process.
A false paradigm
Business systems deliver functionality, which is specified by users and business analysts and designed and built by developers. Users interact with systems as they do their work. A series of interactions with one or more systems (plus related off-line activities and/or relevant automation) is a business process. If workflow organises, distributes, delivers or automates the work, then it is a workflow-supported business process.
The paragraph above may be true as history but a business process management (BPM) initiative based on it may not succeed as well as it could.
It assumes a business process is nothing but an empirical fact:
Person X does Activity1
Then person Y does Activity2 using system S1
Then person Z does Activity3
…and so on.
Using the same paradigm we generate optimised processes by getting person X, person Y and person Z in a room with other stakeholders and experts to map and debate until leaner, tighter, ‘to-be’ models emerge, complete with lists of system changes to make everyone’s lives easier.
The problem is the ‘nothing but’. It ignores the elephant, perhaps because it is a supplier-centric paradigm. Consider an organisational entity – say division D1 in Figure 4 from Business process architecture and business change #2. Figure 4 is repeated below for convenience:
Division D1 will be responsible for a set of functions. It employs a number of people and uses and invests in one or more systems. It will be rewarded on how efficiently and effectively it carries out its functions. Its IT investment will be geared to optimising its functions. It may have close relationships with internal or external IT suppliers, who will be rewarded on how efficiently and effectively they maintain, develop and support the systems D1 depends on. Anything likely to extend the functionality and deployment of those systems will be in the IT suppliers’ interest, as careers and incomes depend on it. This is a world where ‘business analysts’ specialise in system S1 or system S2 or ‘workflow’; where it would be incomprehensible to see a business process other than in terms of the systems which happen to be implemented. This is a world as in Figure 8:
It is a world where system boundaries influence the organogram. But local ownership of systems and devolved IT funding also entrench system boundaries – so we have a circle. Key to extending the functionality and deployment of systems is the successful promotion of the design patterns the systems are based on. The more they are promoted, the better the fit. It is as if the systems and the business context were made for each other!
Eventually the patterns become the cognitive models the support teams think and communicate with. Workflow team D3.5 sees the business context in terms of workflow system S5. Team D3.2 supporting product P1 sees the business context in terms of system S2. All well and good unless the axioms of S2 and the axioms of S5 conflict with each other, and until S2 and S5 need to integrate. Then if they do clash, shared self-interest will bring a negotiated truce. So what if this means duplication? Both teams get work.
A good example of what I’m talking about is the business process itself. For workflow team D3.5 the business process is a set of queues plus allowable pathways. For support team D3.2 the business process is a series of screens in system S2, along with automated processing when a long-running transaction reaches specific statuses. As psychologist Abraham Maslow would say: It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.2
It is in the interest of both teams to see two separate things which need to be kept in step, as the alternative is for the business process to be only in S2 or only in S5. Either decision throws a different baby out with the bathwater, as the real issue is that neither system treats process very well – because the original designers had a flawed process paradigm or no process paradigm at all. Which in turn would mean the teams’ cognitive models are flawed – an inconvenient truth. In the (rather sexist) words of novelist Upton Sinclair: It is difficult to get a man to understand something if his salary depends on his not understanding it.3
The next article will suggest an alternative paradigm.
1 Lawrence, C.P. (2008). Business Process Architecture and Business Transformation. In Layna Fischer (Ed.), BPM & Workflow handbook 2008. Lighthouse Point, Florida: Future Strategies Inc, in association with the Workflow Management Coalition. The paper is available from www.makeworkmakesense.com.
© Chris Lawrence 2008.