3.1 Process Oriented vs Service oriented?

It is interesting to note that the process centred approach has followed its own hype cycle, with the greatly inflated expectations for business process reengineering (BPR) of the early 90s, followed by stories of failure and almost dismissal by the late 90’s. And yet over the last few years business process management (BPM) has emerged, supported by many ICT suites of modelling and process design tools whose outputs can be passed to process engines for coordinate live processes. These operate at both the level of coordination of human level processes and at the level of coordination of machine level services.

So it would seem that Business Process Management is also climbing up the Slope of Enlightenment and nearing the Plateau of Productivity. At this stage then, it should be possible to review what has been learned over that period.

Insights

• Look at processes as ‘value chains’ and identify all elements that add value to the ultimate customer of a product or client of a service.

• Remove those elements in a process that don’t add value, perhaps those still there for historical reasons,

• ‘Don’t Automate, obliterate’ – meaning don’t automate an already bad process, it’ll only continue to make its mistakes, but faster

• There can be significant efficiency gains

Issues

• Early efficiency gains were not replicated. Not surprisingly, great efficiency gains only occur where processes are very inefficient to start with.

• Those processes that are repetitive, relatively simple, i.e. without many variations and exception handling, make the best candidates for process redesign.

• Activities that demand interpretation and generation of meaning from disparate observations and data are not good candidates. Much of the work in F/HEIs is knowledge based and not easily amenable to standard approaches to process improvement.

• Where a process is already quite good, obliterating and redesigning from scratch can do more harm than good.

• Processes that seemingly don’t add value may turn out to be essential to the effective coordination of more obviously value generating activities

• To make them work, many processes require tacit knowledge which is embedded in practices and difficult to formalise explicitly (e.g. how to ride a bike). Process designers, particularly when not intimately familiar with the nature of the work in hand or working closely with people who are, often overlook this.

• More generally the role of practices as a core part of the how-to within processes as well as essential to the smooth running of processes is not recognised

• The practices that overrule an established process are necessary when unplanned for exceptions occur. The process has to allow for this.

• When such practice interventions start to occur with increasing frequency, it is a sign that the world has changed and the process needs to be reviewed.

• Only routine and regular processes can be fully formalised, and only the most routine of these can be fully automated

• Reorganising work structures around processes took specialists out of their support context and either

1. created a ‘matrix structure, where people had both departmental and process managers, which could result in conflicting demands

or

1. without a pool of the experience provided by others from their department readily available to discuss issues with, performed less well

• Where ICT support was built in to the redesigned processes, while it may have worked well at first, as their operating context continued to change, and the processes needed to be adapted, the ICT systems have often been found to be inflexible and thus become a barrier to further process change or improvement.

Lessons from BPR

As a general antidote to over zealous process redesign, the work of John Seely Brown, former Director of Xerox PARC, and Paul Duguid, professor at UC Berkeley is strongly recommended. Chapter 4. ‘Practice makes Process’ of their book The Social Life of Information[1] or their paper, Balancing Act [2] , published in the Harvard Business Review, are good places to start. Essentially they put forward the view that practices and processes are both necessary and complementary. Where the work to be modelled has a well defined linear process with clear inputs and outputs at the beginning and end of the process and between each step, the more the process aspect comes into play, while the more it depends on sense-making and expert knowledge, the more the practice side comes into play. Practices that become regularly repeated become easier to articulate and become candidates for formalising as processes, while processes which need increasing intervention and supporting with practices, are likely to be getting out of synch with the world and analysis of the practice interventions can give clues as to how the process should be improved. The much of the rest of their book ‘The Social Life of Information’ is also relevant in the F/HE context.

Given how much of the work in F/HEIs is knowledge-based, it might be argued that there is little that process based approach can help with. While this may have some truth, there are still many ways in which ICT can be used to assist and enhance the work. There are often routine parts to a job, which can be addressed and improved, leaving people more time for what they are best at. Thomas Davenport in his Thinking for Living [3] selects two, of many possible, as useful dimensions against which to classify knowledge work:

• Level of Interdependence (work done individually or in groups)

• Complexity of Work (from routine to work involving interpretation &/or judgment)

and he uses these to create a classification matrix with four types of knowledge work:

• Transaction – individual, routine, e.g. registering students

• Integration – group, routine, e.g. handling student applications

• Expert – individual, judgement, e.g. writing a book (single author!)

• Collaboration – group, judgment e.g. multidisciplinary research team

He goes on to consider the nature and requirements of these types of work and the ways in which ICT can be best used to support them. His work is based on research and experience with over one hundred companies and six hundred knowledge workers, with useful insights.

While his work provides a useful guide to the difficult task of improving the performance of knowledge workers, it may be best for SOA purposes to start out with areas of work that lie in the left hand column, Integration and Transaction.

He also provides some useful general guidance when working with knowledge workers:

• Knowledge workers differ from others in their autonomy, motivation and attitudes, which should be taken into account

• Knowledge workers enjoy their autonomy so be careful about improvements that impinge upon it

• Knowledge work tends to be unstructured. Specifying a detailed workflow is sometimes possible, but is probably not the best way to improve a knowledge work process

• Knowledge work often needs to be observed in detail and at some length before it can be truly understood

• Knowledge workers are usually intelligent, so be careful about assuming that a particular work task is unnecessary, or that a work process can be improved upon easily

• Commitment matters to knowledge work. Don’t do anything to damage the knowledge worker’s commitment the job and to the organisation

His approach is more relevant to typical F/HEI tasks and services than more mechanical process modelling approaches developed to address very routine, high throughput work.

To conclude this part, here are some further useful guidelines:

• Choose your candidates for process mapping carefully and be prepared to take the necessary practices into account also.

• Even high level knowledge work generally contains some aspects that are routine. These are often seen as a chore and can make good candidates for improvement

• In particular (from Enid Mumford), select as candidates for improvement those aspects of people’s work that they dislike, find difficult, frustrating, boring and/or are the most error prone, but make sure that you don’t take away what they like, links them with other people, is necessary for them to engage in order to do other parts of their job etc.

• When developing new ICT support for a previously manual task:

1. Distinguish what can currently be done easily from what is difficult or too difficult to do.
2. Then make sure the software replicates as nearly as possible what is currently easy and familiar, in addition to adding new features to address the difficult or impossible. Failure to do this, that is, if it makes what is already easy more difficult then, regardless of all the new benefits, it will be rejected by users. [4]

References

[1] John Seely Brown & Paul Duguid, The Social Life of Information, 2000 & 2002 (pbk), Harvard Business School Press

[2] John Seely Brown & Paul Duguid, Balancing Act: How to Capture Knowledge without Killing It, HBR, May-June 2000, reprinted in HBR on Organizational Learning, 2001, Harvard Business School Press

[3] Thomas Davenport, Thinking for Living, 2005, Harvard Business School Press

[4] Terry Winograd, Bringing Design to Software, 1996, ACM Press particularly Chapter 6 Peter Denning & Pamela Dargan, Action Centered Design, and more specifically, pp 112-114