Making the change needs obvious The critical role of interfacing activities | |
Objectives
No organizational change programme should be undertaken, obviously, without first establishing a mechanism to identify forensically where the change is required. Ideally, the method used should make the opportunities visible to those who are planning the changes as well as engage those who have to put the changes into effect. This chapter will provide an understanding of interfacing activities as well as discuss how the knowledge gained from interface mapping will displace the use of pure guesswork or, at best, âjudgementâ which is so often associated with defining major change initiatives.
The chapter will demonstrate how interface mapping speeds up and improves the delivery of outcomes by enabling the gaps and weaknesses in business processes to be pinpointed and quantified efficiently. The gaps include the non-compliance with the best-practice principles for focusing on strategic intent described in the last chapter. Finally, the chapter will explain why such a high level of engagement and enthusiasm is generated by the interface mapping approach.
How it all started
The decade from the mid-1970s onwards will have been purged from the minds of all managers and employees who were in the UK at the time. It was not a pleasant time to work in industry or commerce. Virtually every organization, private and public sector, seemed to be downsizing to reduce operating costs. In the manufacturing sector the focus for cost-down exercises had expanded to embrace the whole organization because management had recognized that the âblue collarâ areas then occupied an ever-shrinking proportion of the cost base. What had remained of the brass bands, tea ladies, chauffeurs and tiered dining facilities were being phased out. The scope of most cost reviews were expanded to include the âwhite collarâ and management areas and service industries, especially banking, finance and the public sector, were no longer exempted.
The change outcomes from these exercises affected everybody. Those who lost their positions were stunned by the suddenness of the decisions that affected them. Those who were âluckyâ and were retained were almost always dazed by the increased workloads and longer hours which were the inevitable consequence of ill-informed, and poorly planned âdownsizingâ or âright-sizingâ.
It was against this backdrop that one of the authors was engaged on a project to raise productivity and define a new computer system for the downstream marketing operations of an international oil company. A team of six consultants was assigned to do the work using analytical tools which were much the same as those in common use today. The tools included process mapping to understand the physical goods and information flows and high-level timesheets to estimate resource allocations and costs.
An area of focus was the fuel depots or terminals where fuel bowsers were filled with the companyâs products for onward distribution to the petrol stations and commercial customers such as airlines, shipping lines and road fleet operators. The business processes in the terminals were apparently straightforward. For example, trucks arrived, were checked in, product was dispensed and volumes dropped were recorded and subsequently billed to the customer or the distributor. At first sight there was little complexity other than from the shared âliftingâ of product arrangements where competitors servicing that geographical area also obtained product from the companyâs facilities. Staff levels in each terminal were modest â three staff covering two shifts five days per week.
The inherently hazardous nature of the volatile petroleum products handled defined the culture. Procedures were seen by everyone as important and were carefully adhered to. This made the job of documenting the activities they carried out apparently straightforward. Process maps and resource allocations were developed well within schedule with excellent, if concerned, cooperation from the staff. A quick first analysis revealed a problem for the consultant. Virtually all of the activities which had been documented were easily reconciled back to the procedures and thus the business needs. There were few opportunities for improvement because the staff were doing what they were required to do. Nearly all the activities documented were value-adding activities and were being strictly adhered to. The only exception found was in the product replenishment process through the cross-country pipelines, where some procedures were unclear and therefore there was an opportunity to remove significant duplication of the work. However, the opportunity presented would be well below the expectation of senior managers, even though their own company benchmarking clearly showed that they were close to best in class on a world scale on customer service, safety and productivity.
A chance remark, made at what should have been the last meeting with three terminal staff to thank them for their input, turned upside down the orderly world in which the terminal staff apparently operated. The comment uncovered what was to become over the following 20 years for the consultant (and potentially the next 20 years for you) an almost bottomless pit of opportunity shallowly buried under the surface calm. One of the members of the terminal team was late so we were all sitting around waiting for him to arrive in the terminal meeting room. When he entered, he apologetically explained that he had been detained dealing with an issue that had arisen that morning. He was somewhat embarrassed by keeping everyone waiting and felt obliged to explain that a truck driver had not been able to produce his security pass and entry key. This had led to a series of phone calls to the driverâs company and to the oil companyâs head office. This had been rather protracted as the person with the required authority was absent on a company training programme and it had taken an inordinate amount of time to track her down. The apparently unusual incident had obviously caused significant delays and extra work for the terminal, head office and the driver.
I, the author, casually asked whether these types of things occurred regularly. The terminal superintendent shocked me with his immediate answer. He said that these types of things occurred several times a day in almost everything they did. I blurted out the glaringly obvious question. âWhy on earth have we not documented these activities in the exercise we have just completed in the past week?â âJust part of the job,â said the superintendent casually, âand anyway they donât occur on every transaction, just a few of them, and they are not in the company proceduresâ. It was almost funny to see the lights go on for everyone in the room. What had been a relaxed meeting was electrified. They realized that significant opportunities had been missed in the documentation they had just developed. As a group, we excitedly and quickly revisited each functional task which we had so carefully documented over the past week adding what were later to be recognized and defined as interfacing activities.
The first tentative use of interface mapping had occurred. We used some simple questions for the terminal staff to ask. What do we do if the truck driver is late? What do we do if the driver does not have the right documentation or authority or equipment? What do we have to do if there is a malfunction in the equipment and then how do we get it rectified? What do we have to do for the customers when a problem happens? The tasks were the essential, absolutely undocumented tasks that were second nature to the staff. They had to do these interfacing activities to get through the day to enable them to do the tasks so precisely defined in their job descriptions and procedures.
I did my best in the next three days to complete the documentation we had started in the meeting by interviewing the team members. I was attempting to document the nature and impact on resources of every one of the interfacing activities we had talked about. There were so many interrelated tasks and dependencies that I quickly abandoned flowcharting when I reached connector 100 and moved to using hierarchical lists. The listing approach subsequently proved to be ideal for resource allocation. As before, I circulated the now much larger documentation packs to the terminal staff for their comment and sign off.
There was a nasty surprise in store for me at the review meeting â they were very, very disappointed by my efforts and were hardly shy in expressing their views. They felt that I had left out far too many things that routinely disrupted their working day. So, supported by the terminal superintendent, they spent a week changing it to their satisfaction. They then proudly (and I did not realize how critically important their change in attitude would prove to be) presented me with the catalogue of the real work they did every day. The number of tasks from the original had increased tenfold. Most of the additions were activities required to keep the system running smoothly by dealing with the all too frequent issues that occurred, so that the next step in the process could be executed. The result from the work was an almost indigestible amount of data laden with opportunities. The other outcome, which we were only to value much later, was the staffâs change in attitude. If I had been more experienced I would have realized that something unusual had taken place. Fear and suspicion had been replaced by outright enthusiasm. At last they had made visible all the things they actually had to do. All I saw at the time was the quantity and quality of the data. What they now expected was to get in there and fix the problems.
However, at the time there were two far-reaching conclusions that we drew from this experience and we later found them to hold in all situations. First, the staff who do the work are the only people capable of documenting what really happens in the workplace â the activities we have defined as interfacing activities. An external agent, in this case a consultant, could simply not do the job to the satisfaction of the staff. Second, conventional process mapping tools are not suited to detailed and rigorous end-to-end mapping of all the activities undertaken.
Exploring interfacing activity
We have given several examples in the book so far to illustrate the role interfacing activity plays in organizations to enable âstuffâ to be passed from one person to another in a business process, enabling each person to apply their specific expertise and thus add value. We have also described a number of situations to demonstrate that where these interfaces have been poorly designed, or more commonly just left to chance, the nature and quantum of the interfacing activities starkly reveal process failure. One incident that gave rise to the idea to write this book was the experience one of the authors had as a result of an accident when he fractured his spine in Austria. The experience gives some unique insights into interfaces and interfacing activities. He was the âstuffâ which was to pass through the medical repatriation process. He was handed on from one person to the next benefiting progressively from each personâs skills and the interfacing activities should have been managed to facilitate delivery back to his home in Australia. The contrast between the professional way the medical skills were expertly applied and the mayhem and distress caused by the poorly managed repatriation interfacing activities could hardly be starker. Case study 3.1 sets the scene so that you can share the experience and evaluate the various activities that made up the business process variously referred to as the âpatientâs journeyâ by those who have studied medical processes in the past.
CASE STUDY 3.1 The patientâs journey
| |
First letâs introduce the players in this case study, many of whom are among the most respected names in their field in the world. A top-ranked insurance company provided its top of the range travel insurance package and another international insurance company through its Australian office administered the scheme on the insurerâs behalf. The service providers included several airlines, three airports, three ambulance services, two hospitals and two travel agents.
The accident was completely unexpected, it happened very fast and I was immediately totally incapacitated. I had fallen and fractured my spine while on holiday in Austria and simply could not move. Even breathing was excruciatingly painful. I passed out and awoke to find members of an ambulance crew had arrived and they had administered oxygen. When I thought about it afterwards, I concluded that the interfacing activities in these early parts of the process were efficient, quick and routine â just what one might have h...