Behik Blog

IT-based change is about process change. It involves people doing different things in different ways with different inputs and different outputs. New or improved IT systems are brought in to either increase efficiency or to allow innovation to occur, not to simply automate what is already there, so process change almost always occurs. But how is this best achieved?

In this section we compare two different approaches to process change. These are BPR (business process re-engineering) and socio-technical design. We look at the pros and cons of these two approaches, and investigate how these two approaches can be combined to offer a new way of successfully improving processes using IT as a lever.

BPR

BPR is one of the best known approaches to achieving IT-based change in organizations. It was first set out in a article by Hammer and Champy in 1993, entitled Reengineering the Corporation: A manifesto for business revolution, and was received with much enthusiasm from the business community, appearing to offer the answer to how to achieve radical change and maximize effectiveness. The tenets of this approach are:

1. Rigorous focus on business processes that deliver value to the customer.
2. Radical process redesign from scratch, leading to radical transformation.
3. All unnecessary process detail is eliminated.
4. Old processes are obliterated.
5. Redesign produces processes that give significant strategic improvements in competitive performance.
6. Enabled by IT.

AN EXAMPLE OF BPR

A car leasing organization in the UK decided to completely redesign its customer service processes, with the goal of gaining competitive advantage over other car leasing companies by being much faster and much more responsive. It also intended to offer some self-service operations to customers via the Internet. A task force was selected from the existing customer service team, and these people worked alongside a team of specialized BPR consultants to radically redesign the customer service processes over a period of three to four months.

The new process designs looked excellent, but problems came in the form of resistance when teams had to work on implementing processes that were obviously going to lead to staff redundancies. The roll-out was done over an intensive six-month period, which was very stressful for managers and staff alike. Customers noticed a significant dip in service, so much so that two key accounts were lost during the roll-out period. Things are better now, with new teams in place and improved processes, but if anyone was brave enough to do a cost–benefit analysis, the results would probably not look good.

Unfortunately the number of BPR successes where expectations have been fully realized is said to be quite small. Advocates of BPR take some pride in this. They claim that the potential gains of this approach are so great, it is bound to be risky. However, Sauer and Yetton (1997) say, ‘Not only is the risk [of BPR] substantial, but the stakes are unusually high. The cost of failure for a project that involves organizational transformation is likely to be much greater than the simple loss of investment. The time lost in undertaking a project that fails may give competitors a lead that cannot be recovered.’

This is a mechanistic approach that spends little effort on the social or organizational side of the process. A typical BPR approach follows the steps seen in A typical BPR approach. There might be some team work, some multi-skilling and some group problem solving; there is usually quite a strong prescriptive element to the IT solution. Also, although the impact on structures, skills, culture and standards is thought about, it is often not acted upon until the later phases of the programme of change, as an add-on. Many believe that this approach is not the most effective way of engaging people in defining what process improvements are needed, and in making them happen. Resistance may be encountered, which will waste effort, or cause the initiative to fail.

BPR therefore offers the very attractive prospect of radically transforming key processes by starting from a totally blank sheet. The downside comes during implementation, when resistance from those who have not been involved may be encountered. Radical process improvements which lead to staff redundancies are difficult to manage, and team performance will dip during the implementation period. Staff read the signs of a new systems implementation where redundancies will result, and are demotivated at an early stage in the lifecycle.

Socio-technical design

The principles of socio-technical design are concerned with getting a balance between:

1. the strategic vision of the organization;
2. the technology and the tasks needed to provide the product or service;
3. the needs of the staff.

This school of thought stems from a systems view of organizations, based in the organism metaphor (see Senge in Organizational change), and is a much more incremental, evolutionary approach. The approach is less widely used than BPR, and seems more cautious and humanistic than traditional BPR processes, which have a rather macho feel to them, advocating throwing everything out and starting again.

The underlying principles of socio-technical design are identified in Mumford and Beekman (1994). These principles were originally developed by the Tavistock Institute of Human Relations in London in the late 1960s, but still appear to hold good today:

1. The principle of minimum critical specification: tell people what to do but not how to do it.
2. The principle of variance control: problems must be corrected as close to the point of origin as possible, and preferably by the group that caused them.
3. The principle of multiskilling: give individuals a range of tasks including some routine and some challenging.
4. The principle of boundary management: identify boundaries between groups or functions and ensure that these are well managed and that the people on them have the necessary information to pass the product smoothly to its next transformation stage.
5. The principle of information flow: information systems should be designed so that information goes directly to the place where action is to be taken, or to the source that originated it.
6. The principle of design and human values: an important objective of organizational design should be to provide a high quality of working life for employees, for instance to fulfil the need to feel the job leads to a desirable future.
7. The principle of incompletion: the need to recognize that design is an ongoing and iterative process.

Socio-technical design involves more forethought, planning and incremental change than BPR, which is faster, more risky and more exciting. As defined by the Tavistock Group, this process was facilitated by either a consultant or a manager, and followed the steps below. Some of these activities may look a bit quaint these days. When compared with BPR, the focus might appear rather ‘fluffy’ as much attention is given to the psychological needs of the workforce.

Socio-technical design is still alive and well in some companies, but has been rather overtaken by the speed and promise of BPR. Although the incremental, developmental approach is seen to work well, it is often too slow for many environments where big results are sought quickly, without taking people off the job to do the research and take action.

Combination approach: PROGRESS methodology

The PROGRESS methodology for process improvement is also offered by Mumford and Beekman (1994), and brings together the principles of socio-technical design and the technology focus and efficiency emphasis of BPR (see The PROGRESS methodology for process improvement ). Key to this method is the belief that the future users of a system must play a major role in its design. Cross-group design teams must be set up, sponsored by senior management and facilitated by a skilled facilitator to achieve their goals.

It is useful to illustrate the PROGRESS approach using a case study.

County planning office case study

The county planning department was overstretched and ‘in crisis’. Plans were stacking up, and a three-month delay was the normal experience of those submitting plans for approval. This was starting to become untenable, as people in the community wanted to get on with building work and could not do so without planning approval.

A consultancy firm using the PROGRESS approach was called in to work with the planning team. The planning process itself was identified by the team as being cumbersome and slow, but although they could see the problems, they had never had the time to sort them out. The consultants planned in some intensive half-day sessions with the planning team to map out the process and identify weak links. Although the impact of spending time in the workshop sessions caused even more backlog to build up for the team, they were confident that they could reduce the planning cycle time (from arrival of the application to sending out of approval) by 30 per cent if they focused on it for long enough and drew out some simple agreed actions.

Various core problems were identified:

1. Seating arrangements were not optimal. The department was split between two buildings for historical reasons. Time was being wasted going to and fro, looking for people and searching for things.
2. Lack of knowledge of different roles in the team was causing misunderstanding and friction.
3. One administrator was particularly overloaded with tasks that she was finding extremely boring.
4. Lack of a cataloguing system meant that time was wasted searching for paper-based items.
5. The planning officers were often out of the office, but were not accessible. It was impossible to get messages to them, which was in turn holding up decision-making processes.

The following actions were agreed:

1. The team was moved so that they could all sit in the same office.
2. Four people were asked to learn more about each other’s roles by spending two hours a week together on joint projects.
3. The administrator shared out her ‘boring’ tasks on a weekly basis.
4. A simple computer-based cataloguing system was introduced.
5. Planning officers were given a shared mobile phone, which they used to check every half-day for messages.

These simple measures resulted in a 27 per cent reduction in cycle time of the planning process. The department started to reduce the backlog, and life became less stressful for everyone.