Successful Re-engineering - Learning by Doing

International Journal of Logistics: Research and Applications, Vol. 4, No. 3, 2001

Successful Re-engineeringÐ Learning by Doing È 2 TIINA TISSARI1 & JUSSI HEIKKILA 1

Nokia Networks, PO Box 300, FIN-00045 Nokia Group, Finland, 2 Helsinki University of Technology, TAI Research Centre, PO Box 9555, FIN-02015 HUT, Finland

Plenty of documented experience tells that re-engineering projects often fail at bringing about radical business benefits. In this paper we describe how reengineering programmes can benefit from organisational learning. We start by presenting both the business process re-engineering paradigm and the organisational learning paradigm, followed by reported experiences of re-engineering programmes. Then we present observations of a large-scale re-engineering project. An in-depth case study in the telecommunications industry illustrates how radical and extensive changes can be successfully implemented if the organisation is capable of learning comprehensively during the re-engineering process. It is necessary but not sufficient to learn about the new tools and processes defined in the planning phase of the process. But we claim that the difference between success and failure in large-scale reengineering efforts is defined by the capability to learn within and about the whole reengineering process itself. ABSTRACT

Introduction Managing change is undoubtedly one of the most critical factors for successful management of business. Nowadays, companies must not only cope with the accelerating pace of change, but also be able to leverage benefits from it. Since the introduction of business process re-engineering (BPR) in 1990, it has been a widely practised approach for bringing about change in the company (e.g. Davenport & Stoddard, 1994; Dixon et al., 1994; Grover et al., 1995), although it has been subject to a lot of criticism, and the reported success rates of the initiatives have not been impressive (Davenport, 1995). Correspondence: Jussi HeikkilÈa, Helsinki University of Technology, TAI Research Centre, PO Box 9555, FIN-02015 HUT, Finland International Journal of Logistics ISSN 1367-5567 Print/ISSN 1469-848X online © 2001 Taylor & Francis Ltd http://www.tandf.co.uk/journals DOI: 10.1080 /1367556011008414 8

330

T. Tissari & J. HeikkilÈa

The objective of this article is to study the relationship between organisational learning and re-engineering: How does organisational learning during re-engineering contribute to the success of the programmes? The basics of both the BPR paradigm as well as organisational learning are presented. An in-depth case study in the telecommunications industry illustrates how radical and extensive changes are successfully implemented when the organisation is capable of learning during the change process. The challenging targets and business benefits of re-engineering can be realised through constant improvement of project management, targeted processes and implementation principles. Business Process Re-engineering Business process re-engineering is the ª fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service and speedº (Hammer & Champy, 1993, p. 32). Re-engineering is not about incremental improvements in the old processes, but about inventing a better way of delivering value to customers (Hammer & Stanton, 1995). BPR Principles Re-engineering emerged from two different paradigms: sociotechnical systems change that considers change to affect both the people and the technical elements of an organisation; and total quality management that proved to have limited contribution to radical transformation while focusing on improvement of the current practices in an incremental, continuous manner (Jaffe & Scott, 1998). Business process re-engineering is based on viewing business as a process instead of functions, and the aim is to optimise processes so that they bring maximum value to internal or external customers as efficiently as possible (Davenport & Short, 1990). Optimised processes can be realised through changes like combining several jobs together, bringing the decisionmaking part of the actual work and performing the work where it makes the most sense regardless of the functional boundaries (Pollalis, 1996). The new ways of performing processes are often realised through innovative use of information technology, which can be both an enabler and implementor of the new processes (Davenport & Short, 1990; Hammer, 1990). Re-engineering is carried out through projects or programmes with a clear start and end, as well as defined targets. The initiatives are considered to consist of different phases, and several practitioners and researchers have proposed their own sequential models of how re-engineering should be carried out in an organisation. Lowenthal proposes a four-stage model that consists of: (1) preparing for the change; (2) outlining the change; (3) design of the change; and (4) evaluation of the change (Lowenthal, 1994). Petrozzo & Stepper (1994) also divide re-engineering into four phases called ª discoverº , ª hunt and gatherº , ª innovate and buildº and ª reorganize, retrain, retoolº . A third model outlines general phases of a re-engineering project to include: (1) determining the requirements; (2) designing the new process/system;

Successful Re-engineering

331

(3) ª buildingº the new process/system with organisation structures, roles and responsibilities; and (4) implementing and deploying the change (Moosbroker & Loftin, 1998). Change Management Originally, BPR was about achieving major business benefits through designing optimum business processes. However, it is clear that no process improvements can be implemented in an organisation without successful change management. Dozens of studies show evidence that in addition to excellent process solutions, successful re-engineering efforts include elements like strong leadership engagement and employee participation to eliminate change resistance and motivate people to change (Jaffe & Scott, 1998; Johansson et al., 1993; Lanning, 1996; Lowenthal, 1994; Tulloch, 1993). Successful change management is about communication, leadership, project management, enablement and involvement. The vision, objectives and progress of the change effort need to be communicated, as well as what is expected and how it affects the employees (Rigg, 1993). The leaders must be committed and able to create a shared vision of the organisation as a result of the change (Beer et al., 1990). In addition to committed leadership, employees need to be involved: they need to understand the requirements and effects of the change and what they mean for them personally (Rigg, 1993). To provide the organisation and individuals with the capabilities to change calls for reorganisation as well as training (Duck, 1993). Also, discipline in project management is required to ensure that the objectives of the project are achieved as agreed (Hammer & Stanton, 1995). BPR Experiences Change management has been acknowledged as an essential part of reengineering, but still lots of projects and programmes fail, and criticism towards the approach is presented. The approaches for implementing change through BPR have a common characteristic of being sequential. They all suggest that the changes, target processes and organisational structures are first planned and designed and then implemented throughout the organisation through a massive rollout. Somehow they support the idea of a deterministic project where plans are to be realised as such. The missing elementÐ or an issue difficult to describe in textbooks in all its richnessÐ seems to be flexibility and readiness to change plans during the re-engineering effort. This may be required due to the fast-changing business environment, differences between the customers, suppliers or different parts of the internal organisationÐ or learning during the re-engineering programme. As the world today is unpredictable and fast changing, it is unrealistic that major business benefits can be realised through re-engineering programmes that focus only on executing and adhering to plans made at the beginning of the effort. An approach that relies on planning, measuring and controlling is too rigid for reacting to the changes in the business environment. The real business complexity should not be ignored by simply executing the plans once made (Wilson, 1999).

332


Especially in large companies, flexibility is needed because a solution developed and piloted in one part of an organisation, with several customers or suppliers, may not prove applicable for all of them. It is next to impossible to design the right solutions from the top down, so the approach needs to be flexible for adapting the processes or implementation practices for different circumstances (Hoover et al., 1996). Although one aim of re-engineering is to harmonise processes throughout the company, differences in, for example, legislation, geographical location or customer segments may result in a need to have slightly different solutions or several alternatives to be developed and implemented. Also, the best way to learn how to re-engineer or implement change is by doing it. It is unrealistic to think that the perfect processes can be developed on paper without connection to real business cases, or that the best argumentation for overcoming change resistance can be gathered without connection to reality. Undoubtedly a lot of learning from success, failures and mistakes happens during the re-engineering process, so it would not make sense not to update plans, processes and concepts according to the experiences (Jarrar & Aspinwall, 1999a). Organisational Learning Organisational learning can be defined as the capacity or processes within an organisation to maintain or improve performance based on experience (Nevis et al., 1995). According to Gephart and his colleagues, a learning organisation has an enhanced capacity to learn, adapt and change. It is an organisation in which learning processes are analysed, monitored, developed, managed and aligned with improvement and innovation goals (Gephart et al., 1996). While re-engineering is based on the model of linear, even deterministic change process, the theory of organisational learning views change as a continuous cycle of improvement at all levels and parts of the organisation. The roots of the learning organisation paradigm lie in the Japanese kaizen philosophy, carried further in the theories of total quality management (TQM) as Deming (1993) introduced the so-called plando-check-act (PDCA) cycle for structured identification and solving of problems and recognition of improvement opportunities. We present next the essential concepts related to organisational learning as a basis for analysing learning in our re-engineering case in the telecommunications industry. Single and Double Loop Learning According to Argyris, learning can be either single loop or double loop learning, as illustrated in Figure 1. Single loop learning means learning for carrying out tasks better or more efficiently to achieve the desired results. Double loop learning calls for deeper understanding: identifying a mismatch between the desired and achieved results, and accomplishing the reconstructive actions. Double loop learning is not just better execution of tasks to achieve results based on the governing variables, but questioning even the targets set for the actions. Single loop learning is focused on how to execute


333

FIG U R E 1. Single and Double Loop Learning (Argyris, 1993).

the current actions better, whereas double loop learning is more about setting the right targets and only then acting towards them (Argyris, 1993). Single loop learning is sufficient in routine-like, repetitive situations, whereas solving more complex problems requires double loop learning. Both types of learning are needed in a learning organisation and for any type of learning a common requirement is implementing the corrective actions in practice; just observing a problem and defining a solution is not enough (Argyris, 1993). Methodology Based on the BPR and organisational learning paradigms, we formulated the following research question to focus our work on studying the role of organisational learning in a real BPR programme: How does organisational learning contribute to the success of reengineering initiatives? The research question was explored by studying an existing re-engineering programme called ª Breakthrough Inventory Rotation Daysº (BIRD), a major corporate-wide re-engineering programme in Nokia Networks, a company providing telecom and IP networks with related services for different technology standards. Our study was a single, embedded case study (Yin, 1989) that considered both the programme as a whole, as well as the individual BIRD customer case implementations included in the programme as sub-projects. The research can be classified as action research, as the first author of this text was deeply involved in the case programme. The author worked full time on the case programme, first as a specialist in a pilot case and as a project manager in two implementations as well as in the central programme management team responsible for the processes to be implemented and supporting the local implementations. The data consisted of documentation of the programme, including: (1) minutes of the steering group and programme management team meetings; (2) project plans and closure reports of the implementation projects; (3) communication material used for presenting the targets, implementation content and the methods for implementing the change

334


throughout the organisation; and (4) presentation material about the programme plan and progress review. The researcher working on the case programme allowed active participation, observation and interpretation of the numerous intangible factors contributing to the programme success that are often not included in the formal documentation. Case BIRD The BIRD programme aimed at improving customer satisfaction and productivity through implementing more efficient processes for the demand chains. While the implementation was still going on during the writing of this article, about 40% average reduction in inventory levels despite substantial growth in sales had already been reached during 1.5 years. BIRD focused on Nokia Networks’ European customers and the most important product group that form a significant part of Nokia Networks’ sales. The new processes were implemented for customer projects in 17 different European countries by the end of year 2000. Based on the BPR and organisational learning frameworks, we used the following sub-questions to explore and document organisational learning in a real large-scale business process re-engineering case in the fast-growing telecommunications industry: What were the changes and improvements in the BPR programme throughout the implementation of the whole case programme? How did changes take place and what elements in the programme were objects of change? How can the changes be classified in terms of the object of learning (content of the programme or implementation of the programme) and in terms of the type of learning (single or double loop learning)? d

d

d

In other words, we were trying to look at the issues that were fundamental for achieving success in the change programme. Programme Initiation Nokia Networks provides equipment and services for building and maintaining telecommunications networks for the customers. The customers traditionally used to be experienced state-owned network operators, but in the past few years new mobile operators with no telecommunications background have entered the market. Thus, the focus of Nokia Networks’ business has been shifting from selling the equipment to delivering a value added bundle of equipment and services, e.g. taking full responsibility for the project for planning and building a network. The time pressure to build up the networks fast for generating money is extremely high in the projects, and as a result Nokia Networks had ended up having large warehouses in each country to enable fast equipment deliveries. Now, especially with the new types of customers, it has become increasingly critical to manage the demand chains efficiently. The first major effort to re-engineer Nokia Networks’ demand chains was made in 1997 and 1998. Nokia attempted to improve its demand chain performance by implementing a time-based management initiative together


335

with several of its customers. This initiative assumed that the quality of planning could be improved with all the customers and that that would enable radical improvement of demand chain efficiency through removal of customer-specific warehouses and by making direct deliveries of full product configurations from the factory. This approach proved successful with some customers and failed with others. The BIRD re-engineering programme was launched at the beginning of 1999 by the European area and logistics organisations based on a strategic intent to reduce radically inventory levels in all the demand chains. Another ambitious target of the programme was to provide the customers with fastest time to profit when having Nokia as their network equipment supplier. In the planning phase of the BIRD programme the means for reaching the targets were defined: implementation of one of alternative standard end-toend delivery processes; implementation of a demand planning process; common performance metrics; and efficient logistics service provider management. Concretely, the objective was to eliminate country warehouses by first implementing the most suitable of two defined basic demand chain structures, and later gradually to develop all demand chains towards direct deliveries of full product configurations to installation sites. The original two alternative demand chain structures were: (1) customer-specific kanbancontrolled buffer of units that could make up any needed end product configuration; and (2) direct delivery of final product configurations from a manufacturing plant to installation sites. The original idea of how the programme would be carried out was very similar to the phase models suggested by several authors, as described above. The programme was planned to consist of initiation, piloting, standardisation and implementation phases that would happen in sequence, as illustrated in Figure 2. The initiation and standardisation phases would be carried out on a global level, whereas pilots and implementation would happen in local country organisations with support from the global organisation. In the initiation phase the targets and scope of the programme were set and the principles of the process changes to be implemented were defined. Three pilots were selected to verify that the principles, i.e. the content, were correct, as well as to define an approach for rolling out the principles to all customer projects within the scope. After the pilots, both the process content and the implementation methods were standardised, and finally the processes were implemented in the local organisations according to the global methods.

FIG U R E 2. Original BIRD Rollout Approach.

336


Piloting

d

d

d

d

The processes were piloted in three customer cases: two customer projects with direct delivery process and one with country buffer process. In the pilots, the detailed processes were designed based on the guidelines given when initiating the programme. IT system solutions were defined and taken into use and the commitment to the new way of working was created in different kinds of workshops internally and together with the customer. Before the pilots, the underlying assumption was that the delivery mode is the main attribute for differentiating between the cases. However, the projects were different also from the business scope point of view: one of the direct delivery cases was a so-called turnkey project where Nokia took care of the whole network building and was thus responsible for all the phases in the site process (see Figure 3). The other two pilots were so-called telecom deployment projects where the customer took care of the planning and preinstallation and Nokia delivered, installed, commissioned and integrated the equipment. The difference in the service scope in the direct delivery cases meant that it did not make sense to implement identical processes in both projects. The reasons were related to differences in the business cases: Different responsibility share between Nokia and the customer. Different product scope. One customer purchased all equipment for a site from Nokia, whereas the other customer purchased only one part of it. For one customer, equipment from three different Nokia business units needed to be consolidated to have a complete site delivery, but for the other customer only one business unit was delivering, so no consolidation was required. One of the customers was a mature operator optimising its network and thus using hundreds of different product configurations, whereas another customer was building geographic network coverage and using only three basic product configurations. So, the mature operator was ordering kits that form the final configuration to ease product data management, whereas the other was always ordering one of the three configurations per site. The invoicing trigger in the contracts was different: in one it was based on a delivery to a site, and in the other it was based on the whole region being completed including dozens of sites. So, the invoicing logic and timing in the process were different.

FIG U R E 3. Site Process.


337

Also, another underlying assumption that the inventories were mainly caused by inefficiencies in the logistics organisation needed to be reconsidered in the pilots. To achieve any sustaining results, the deliveries had to be integrated to the whole site process carried out by a dedicated project organisation. As in the turnkey cases the whole site process was Nokia’s responsibility, in the turnkey pilot the changes could be carried out by having tight co-operation between Nokia project organisation and logistics. However, the internal cooperation between Nokia logistics and projects did not help very much in the telecom deployment type of projects where the customer was responsible for the overall site process and Nokia for equipment delivery and installation. In those cases integrating the customer’s processes with Nokia’s processes was essential for implementing the intended changes and reaching the targets (i.e. organisational learning on the content and implementation of the reengineering programme). Standardisation After 3± 4 months of piloting, the results were reviewed. The ultimate targets had not yet been reached in any of the projects, but the trend in each of them was very promising. So, it was concluded that the rollouts for both the direct delivery and country buffer processes should start. Before the start, the rollout approach was standardised, i.e. the experiences gathered during the pilots were documented in the form of templates for project plan, status and final reporting as well as a general communication set to be used as a basis in each rollout. Also, a recommendation of the rollout team composition was defined based on the pilots: rollout manager and/or supporting expert from the global development organisation and local members from the operations that were affected by the change, i.e. logistics managers and their subordinates, people from the customer project interface and account managers. Also, the target processes including information systems use were standardised for further implementation. Because the business case turned out to be such a decisive factor for designing the target process, the original idea of creating one monolithic target process for direct delivery and another for country buffer did not feel suitable any more. The two direct delivery processes were not identical, and the direct delivery for telecom deployment project had a lot in common with the country buffer process due to the similarities in the business case. Thus, instead of defining two monolithic processes based on the pilots, direct delivery and country buffer processes were broken down to modules. The modules were partly common to both processes, so the similarities between the two basic processes could be taken into account, as well as the differences inside one basic process due to different customer cases (i.e. learning on content of the programme). The process for any customer case could now be defined by selecting a suitable combination of the standard modules. Despite the successful results in each pilot, in the other direct delivery case the standard lead time was considered to be too long by the project organisation. However, the country buffer process was planned only for exceptionally challenging customer cases, and it was regarded as a too costly solution to be implemented for all the customers that considered the direct

338


delivery lead time as too long. So, at the same time as the direct delivery and country buffer processes were standardised for further implementations, the idea of combining the benefits of the two processes came up: a regional distribution centre (RDC) with a fast rotating non-customer-specific buffer close to the main customers (i.e. learning on content). Thus, the rollouts for the country buffer and direct delivery processes were started where suitable, but at the same time a pilot for RDC process was initiated. Implementation In the implementation phase customer-specific rollout teams were responsible for making the changes happen in the local organisation, i.e. running the local re-engineering project. In addition, there was a global team that was responsible for managing the whole programme, co-ordinating the projectspecific rollouts and providing the guidelines of the target processes to be implemented. During the implementation, the importance of integrating the equipment deliveries to the site process became evident, and thus the involvement of the project organisation was considered crucial for a successful rollout. In the rollouts, it was also experienced that the customers did not become excited and motivated to change by the target of reducing Nokia inventories. However, in many cases the other target of improving customer satisfaction proved to be more difficult to make concrete. The customers had somewhat different needs, different focus areas in their process development and different internal processes and organisation. It was much more straightforward to streamline the internal process, and Nokia’s internal improvement was a lot easier to measure and demonstrate. In some cases this resulted in heavy concentration on Nokia’s own issues. However, in the best cases a good match was found between Nokia’s and customers’ interests. In practice it required new kinds of communication and arguments for selling the changes to the customer and studying carefully how the Nokia processes interfaced with the customers’ processes in the best possible way (i.e. learning on content and implementation). Country buffer process implementation continued in different kinds of business situation as the original implementation in the pilot. During the first rollout it was discovered that the piloted process was not suitable as such for the different customer project. First the inventory levels in the buffer started to increase and then came a period of shortages; also the project management responsible for building the network lost their faith in the whole process. In the pilot, the customer had a mature situation with relatively stable demand over time. In the new case, the customer was just starting to build the network, and this was done in phases. Owing to delays and problems in acquiring and constructing the sites, the demand at the end of the site construction phase was many times higher than at the beginning. The kanbancontrolled buffer turned out to be too inflexible, because the buffer was replenished only and always when something was consumed and was thus meant always to stay at approximately the same level. The risk of having too high buffers at the beginning of the phase and too low at the end was evident. Thus, the original country buffer process was complemented by starting to


339

adjust the buffer levels according to the demand on a weekly basis (i.e. learning on content). The local logistics started to follow up the project plan including the progress of each site and adjusting the buffer levels based on the plan. The actual replenishment ordering was still done using the kanban cards. The same learnings of the improved process were also applied in the few new country buffer rollouts. The composition of the rollout team was changed during the implementation phase. In the pilots and first rollouts there was at least one person from the global development organisations and the idea was to have a standard composition of the team. As the time of mass implementation started, it was realised that there was no possibility of having rollout managers from the global organisation in each rollout due to the lack of competent resources. Actually it was not even favourable in all cases, because it sometimes decreased the commitment of the local people and made the hand-over at the end of the rollout difficult. Also, as the implementation progressed, more and more people in the local organisations were aware of the new standard processes, targets and changes to come and their competence to handle the implementation themselves increased. Some countries even started to prepare and implement elements of the BIRD processes before the rollout, so the starting point in the countries varied a lot and thus different numbers and types of resources were needed depending on the case. After the first rollouts Nokia decided to rely on local resources whenever possible and use the global people only when specially needed or suitable from individual people’s point of view (i.e. learning on implementation). The rollout approach evolved during the implementation of the reengineering programme. The rather extensive approach developed in the standardisation phase was no longer justified when the programme had been ongoing for more than 1.5 years and there were almost 30 rollouts either complete or in progress. The people inside the programme, in the local country organisations and outside the programme were rather familiar with the objectives, target processes and changes required. There was no more need for heavy and detailed documentation of each rollout, so the templates were revised to concentrate on a selected set of key issues, i.e. achievements and learnings, rather than all the actions going on in the country (i.e. learning on implementation). Summary of the Case The case illustrates how organisational learning can increase success for BPR. BIRD was a re-engineering programme that evolved based on the experiences during the initiative, and from the case description it can be summarised that the following manifestations of learning took place: (1) Modular processes: in the standardisation phase one important lesson was that due to the project-specific differences in the business cases it was more sensible to design the target processes as modular rather than monolithic. (2) Regional distribution centre: during the pilots it was learnt that RDC was needed as an additional process solution that combined the lead time

340

(3)

(4)

(5)

(6)

(7)

T. Tissari & J. HeikkilÈa benefit of the country buffer process and the cost efficiency of the direct delivery process. Project involvement: the BIRD programme was initiated by the logistics organisation, but during the pilots it became evident that it was not possible to reach the targets by improving only the logistics part of the chain. Integration between the site process and planning and the logistics process became essential for the success of re-engineering. Customer focus: in addition to learning the importance of internal cooperation between the functions, it quickly became evident that involving the customer in the change, especially in the cases where responsibility of the site process was shared between Nokia and the customer, was crucial as well as challenging. Demand plan-adjusted kanban: in the country buffer rollouts another lesson was that pure kanban replenishment in the buffer could not support projects in a dynamic stage where demand was unstable, but additionally the buffer levels needed to be adjusted based on a plan of the project progress. Rollout team composition: learning happened also in relationship with the participants in the rollout teams. When the programme matured, more responsibility was shifted from the global to the local people as the number of resources needed and the competence of the local people increased. Rollout approach: in the rollout approach the evolution was from a rather extensive documentation and reporting towards simpler procedures.

Part of the programme success can be explained by the fact that both failures and success during the programme were actively communicated and acted upon. Also, the focus of the programme was on reaching the agreed business targets, which were given by the business owners, but the authority for defining the required solutions lay in the programme itself. Changes during the programme took place to reach the targets and even to reformulate the targets according to the learning throughout the organisation. Organisational Learning in the BIRD Programme The case shows that in a large and relatively long-lasting programme a lot of useful learning takes place and results in changing and improving the plans, concepts and approach for implementation. We observed learning through two objectives of learning: learning related to the content of the programme, goals and the target processes; and learning related to the way of implementing and organising the programme. In Figure 4 the examples are mapped according to the type of learning in Argyris’s theory of single and double loop learning and according to the object of learning (content or implementation of the programme). The numbers represent the manifestations of learning summarised earlier in our text. We conclude that both single and double loop learning happen in a successful extensive re-engineering programme, and we learn both better


341

FIG U R E 4. Examples of Learning in the BIRD Programme.

solutions to be implemented and better ways to implement the solutions. It can be seen in Figure 4 that single loop learning is primarily related to the way of implementing the programme, whereas double loop learning is related to the changes in the content of the programme. Based on this observation we make the claim that the fundamental issue behind a successful large-scale reengineering programme is the capability to make changes in the content of the programme during the implementation. It is necessary to make improvements to the way of implementing the programme, but that is not sufficient to capture all the learning that takes place. It is more important to adapt the content of the programme according to the learning related to the different customer-specific business cases, the structure of the processes and the integration between different processes. Implications for Management and Further Research

d

Creating a learning organisation as a mean to cope with the increasingly turbulent environment is considered as the target state to be achieved by organisations aiming at long-term success (Beer & Eisenstat, 1996). Our case study demonstrates how learning during the implementation of a major change programme Ð such as BPRÐ can be an essential element of a true learning organisation. Our study sheds light on various mechanisms that facilitate transferring and leveraging learning when the management focus changes in the implementation of a BPR programme: Piloting: d Creating an understanding of the most common business cases and the customer needs in the alternative business cases. d Starting with a couple of basic processes to serve the customer needs in the most common business cases. d Establishing a good understanding of the co-operation needs across functional and organisational boundaries when implementing re-engineering across several organisational units in the own organisation and with the customer.

342


Standardisation: Documenting and analysing the piloting experiences and taking these experiences into consideration in the implementation plans. d Creating an implementation model for individual rollout implementations, including templates for a rollout plan, reporting routines and rollout team composition. d Sharing roles and responsibilities between the global programme management and the rollout teams. Establishing rules for co-operation between the local rollout implementations and the global programme. d Selecting target processes for the alternative basic business cases according to the pilots. Making the processes modular to enable flexible configuration of the process modules when new customer cases arise. Defining the use of information systems to support the individual rollouts. Rollout implementation: d Being flexible to adjust implementation plans when implementation experiences accumulate. d Being sensitive to limitations set by poor communication due to, for example, relationship characteristics, power structures or earlier bad experiences of cross-organisational co-operation. These challenges might be a fundamental reason to select one delivery process model instead of a more ideal one. d Moving implementation responsibility consistently from the global programme to the local organisations, including selection of members of the local teams. Transferring learning throughout the whole programme: d Ensuring two-way learning between the local and global levels during all the stages of the programme. d When the programme proceeds, relaxing the reporting needs of the local rollouts. Revising the communication practices to reflect the need for experience sharing, e.g. how to share learning and achievements between the local and global levels as well as between the local rollouts. d

d

d

d

d

d

In this paper we have addressed the question of how organisational learning contributes to the success of a BPR programme. Our study documents an example of a successful BPR programme, makes observations of the implementation of the programme and suggests that comprehensive organisational learning during the programme implementation contributes to successful management of change. However, based on this study we cannot provide normative tools or models for ensuring organisational learning as part of a change effort or give evidence of factors prohibiting or favouring learning. These are interesting topics for further research. Therefore, the following research questions would deserve further attention: How does one combine flexible programme implementation on the local level and dedication to the overall programme goals on the global level? What kind of evidence would best be used to analyse systematically various implementation approaches and their contribution to organisational learning?


343

Conclusions According to the experiences reported in the literature as well as observed in the case programme, we claim that re-engineering initiatives should not just be a result of a planning (learning) process, but learning should happen throughout the re-engineering programme. The sequential approach that separates planning, piloting and implementation from each other and relies on top-down information sharing fails in bringing about the intended radical changes that a re-engineering project aims to achieve. Instead of a rigid approach, re-engineering should foster organisational learning through questioning and developing the content of the programme, through flexibility and frequent interaction between the global and local levels of the programme andÐ most naturallyÐ through continuous improvement of the programme implementation. Learning while re-engineering is important not just because it makes individuals working in the organisation more motivated and committed, but because it is the way to achieve challenging business transformations. In today’s constantly changing, complex world, organisational learning lets us improve our plans and concepts according to the changes inside the company and in the environment. This does not mean that we carry out re-engineering unsystematically without a good plan and clear targets. It is not a failure in execution, but learning by doing.

REFERENCES AR G Y R IS , C. (1993) On Organizational Learning (Cambridge, Blackwell). BE E R, M., EIS E NS TAT, R.A. & SP E CT O R , B. (1990) Why change programs don’t produce change, Harvard Business Review, 68, (6), pp. 158 ± 166. BE E R, M. & EIS E NS TAT, R.A. (1996) Developing an organization capable of implementing strategy and learning, Human Relations, 49, (5), pp. 597± 619. DAV E N P O RT, T. (1995) The fad that forgot people, Fast Company, 1, (1), P. 70. DAV E N P O RT, T.H. & SH O R T, J. (1990) The new industrial engineering: information technology and business process redesign, Sloan Management Review, 32, (3), pp. 11± 26. DAV E N P O RT, T.H. & ST O D D A R D , D.B. (1994) Re-engineering: Business change of mythic proportion?, MIS Quarterly, June, pp. 121± 127. DE M IN G , W.E. (1993) The New Economics for Industry, Government, Education (Cambridge, MA, MIT Centre for Advanced Engineering Study). DIX O N , J.R., AR N O L D , P., HE IN E K E , J., KIM , J.S. & MU L L IG AN , P. (1994) Business process reengineering: improving in new strategic directions, California Management Review, Summer, pp. 93± 108. DU C K , J.D. (1993) Managing change: the art of balancing, Harvard Business Review, 71, (6), pp. 109± 118. GE P HA RT, M.A., MA R S ICK , V.J., VA N BU R EN , M.E. & SP IR O , M.S. (1996) Learning organizations come alive, Training & Development, December, pp. 35± 45. GR O V E R , V., JE O N G , S.R., KE T TIN G E R , W.J. & TE N G , J.T.C. (1995) The implementation of business process reengineering, Journal of Management Information Systems, 12, (1), pp. 109 ± 144. HA M M E R , M. (1990) Reengineering work: don’t automate, obliterate, Harvard Business Review, 71, (4), pp. 104 ± 112. HA M M E R , M. & CH A M P Y, J. (1993) Reengineering the Corporation: A Manifesto for Business Revolution (New York, Harper Collins). HA M M E R , M. & STA N TO N , G. (1995) The Reengineering Revolution (London, Harper Collins).

344


HO O V E R , W.E., JR , TY R E MA N , M., WE S T H , J. & WO L L U N G , L. (1996) Order to payment, McKinsey Quarterly, 1, pp. 38± 49. JA F F E , D.T. & SC O T T, C.D. (1998) Reengineering in practice. Where are the people? Where is the learning?, Journal of Applied Behavioral Science, 34, (3), pp. 250± 267. JA R R A R , Y.F. & AS P INWA L L , E.M. (1999a) Business process reengineering: learning from organizational experience, Total Quality Management, 10, (2), pp. 173± 186. JA R R A R , Y.F. & ASP IN WA L L , E.M. (1999b) Integrating total quality management and business process reengineering: Is it enough?, Total Quality Management, 10, (4/5), pp. 584± 593. JO H A N S S O N , H.J., MC HU G H , P., PE N D L E B U R Y, J.A. & WH E E L E R III, W.A. (1993) Business Process Reengineering Ð BreakPoint Strategies for Market Dominance (West Sussex, John Wiley). LA N N IN G , H. (1996) Organisaation Muutoksen Toteuttaminen (Carrying out Organisational Change) (Turku, Nordmanin Kirjapaino). LO W E N T H A L , J.N. (1994) Reengineering the Organization: A Step-by-Step Approach to Corporate Revitalization (Milwaukee, ASQC Quality Press). MO O S B RO K E R , J.B. & LO FT IN , R.D. (1998) Business process redesign and organisational development: enhancing success by removing the barriers, Journal of Applied Behaviora l Science, 34, (3), pp. 286 ± 304. NE V IS , E.C., DI BE L L A , A.J. & GO U L D , J.M. (1995) Understanding organizations as learning systems, Sloan Management Review, 36, (2), pp. 73± 86. PE T R OZ Z O , P. & ST E P P E R, I. (1994) Successful Reengineering (New York, Van Nostrand Raynhold. PO L L AL IS , Y.A. (1996) A systematic approach to change management. integrating IS planning, BPR and TQM, Information Systems Management, Spring 1996, pp. 19± 25. RIG G , M. (1993) Organisational and individual behavior, Industrial Engineering, 25, (12), pp. 12± 13. TU L L OC H , A. (1993) The strategic management of change, Management Decision, 31, (3), pp. 62± 65. WIL S ON , J. (1999) Winning through chaosÐ Part 1, Credit Control, 20, (4), pp. 27± 32. YIN , R.K. (1989) Case Study Research: Design and Methods (Newbury Park, Sage Publications).