CASE DESCRIPTION: INFORMATION SYSTEMS AND CHANGE

The spectrum of change that EP was experiencing affected both systems currently in place as well as ongoing development efforts. It gave rise to a managerial challenge that could best be defined as a question; what could be the best development strategy for information systems where requirements seem to change on a day-to-day basis? It is easy to understand the challenge if one looks into the devastating effects that internally and externally induced changes had on EP's main information systems.

There were three major types of information systems misfits being experienced at EP. The first type reflected a change in the organizational structure that the information system had not been able to follow. A second type of misfit was due to the inability of a system to keep providing the same level of service to a business process that had changed. Finally, the third type was caused by a change in technology itself that made existing systems obsolete and cumbersome in the eyes of the users. Things had changed at EP during 1990–1997 while systems had not; and people had to adapt to the way the systems worked, rather than the other way round. A manager from Research and Engineering remarked:

"There are two points to the question ‘how well do I think my information systems fit my business now?’ How well does the IS fit with what we do, and how well we have to fit with what they do."

At EP, there were two types of systems: what managers called ‘intellectual’ systems, usually referring to Management Information Systems (MIS) and Decision Support Systems (DSS) such as the EMC and certain systems at Sales and Marketing, and the operational systems such as the Finance and PRISM systems. The first type of misfit seemed to address predominantly the operational systems, whereas the second type of misfit, the ‘intellectual’ systems. The level of the third type of misfit seemed to apply to both types of systems.

As far as the operational systems were concerned, these were built around the structure of the company as it emerged from the CEGB, and either just after they were implemented or at the point that they were implemented, the company changed. A review was carried out in the three months to February 1992 of the suitability of the information systems to operate following the devolution of business activities to power stations. The systems in question were mainly the Finance and PRISM systems. The findings of the review were that the systems available were suitable for devolved use with some minor modifications. Those modifications represented only those aspects of the systems that could directly prevent devolution. It was also recognized that as those systems were designed prior to devolution, other changes could be usefully made to enhance effectiveness or efficiency. In a time space of almost three and a half years (February 1992 to May 1995) where another review sought to examine how well they systems were faring in supporting business operations, one would expect that the modifications would have been completed successfully, resulting to no misalignment at all. However, this was not the case. The process of devolution made demands on the systems that could not be satisfied by simply maintaining them.

"The finance systems we put in, we set up for a particular structure, culture— whatever you want to say and that changed in the last couple of years tremendously. It was like trying to fit a square in a rounded hole, and the number of changes requests to the systems increased, and have been coming non-stop ever since."

Procurement for example, was a central activity that had specialist people dedicated to this task. Devolution meant that this task was now undertaken ‘part-time’ by non-specialist personnel, as people were required to be more flexible and to work on different job aspects. This meant that the task was now only four or five hours a week of an employee's time, resulting in a negative perception about the systems as being geared towards professionals, and hence too complicated and difficult to use.

"In the early days, we regretted some of the assumptions that we made, as we used to design systems to particularly reflect the structure of the organization, or the way people worked, and while it may have been true at the time, it wasn't always true in the longer term… and I think one of the major problem areas was in the procurement side of things, and still is…"

Another example of this type of misfit was the very clear division of the organization into distinct business units. The systems were designed to fit this structure, but in time, the business cycle had come to cross all the function areas; the systems fit the functional breakdown, but they did not fit the organization as one entity. In addition, systems were perceived as being too ‘big’ for what the organization needed for what it did. A senior developer explained:

"You cannot shrink the business continually and expect those projects of that size to remain unchallenged. So far as the changes concerned, the threat is that if the operation is reduced, we get to a particular financial level where the IS activity becomes disproportionately large in terms of operation. I think that is perhaps the single area where the greatest threat is."

At the process level, it would not be an exaggeration to say that no process had remained the same since the early stages of privatization; processes had not only changed, but they had kept on changing. Information systems that supported these kinds of business processes were the most vulnerable to change as they dealt with voluminous and complicated data at the half-hour level. The systems at the EMC had to be scrapped altogether and a new breed of systems had to be developed to account for the changed processes. A senior manager commented:

"The part of the systems that you can define—that you know it has to be a deliverable—your interfaces, getting the data from the power stations and into your offer file—that is the easy part. What it is, it is the analysis of all that—the kind of thinking—the strategy point of view. It is all around the main deliverable for the EMC—that's what is continually changing. It is impossible to define or specify in advance a deliverable. It changes every day!"

Such misfit was also evident with other business units such as Fuel:

"I have seen a couple of instances where management information systems have failed to cope with the pace of change and have caused the organization to make inappropriate decisions as a result, and we then had to run to catch up with the circumstances."

The so-called ‘operational’ systems, which were expected to be stable, were equally vulnerable to change. For example, the process of work management, although it might have seemed stable, had changed in the way the work was done much differently at the power stations. There was not the same number of personnel that used to be available at one time, and there were no planning departments, which there were before. There was a much greater emphasis on cost-benefit that determined the maintenance philosophy in deciding to change processes or operations. A manager from Generation said:

"Some of the changes were never at the outset envisaged as being as extensive as they actually were, which resulted in us making more changes to the systems that we have otherwise had anticipated. It also meant that some of the more refined facilities of the systems have become less used. So yes, they have been inflexible in the sense that it would require a large amount of effort to change or add some functionality."

Technological advancements seemed to affect all the main systems at EP as they were character-based and with busy screen representation. In the sense of usability, they were perceived as not being up to current practice standards. This meant that in order to use the systems, users had to get familiar with them for some time, and this was not always possible under the current situation—few employees, many tasks, little time. Users had to be able to switch from one system to another and perform various tasks at the same time—something that their systems were not allowing them to do.

In summary, these types of misalignment had caused the following problems at EP, as its information systems had not been designed to provide for change:

The quality of information provided limited the purpose, which particular systems were, designed to serve.
Accessing the information was difficult; users were asking for a lot of information but they did not know how to get at it.
Users needed the information in different ways and at the same time, the number of users who needed this information was increasing; this demanded a level of sophistication that existing systems could not provide.
The level of integration between the systems hardly approximated the one required; as a result, the information flows suffered considerably.
Management information had been neglected; attempts to provide for it by combining systems or building on top of operational systems had produced ones that were over-complicated and under-utilized.

The following remark sums up the situation, coming from a project manager responsible for the development of applications for the Sales and Marketing and Strategy and Financial Planning units:

"If everything is changing which it does do, then one thing that I have found is that it is actually quite difficult to alter the scope of an application whilst under development. You tend to fix your scope at the beginning, and you refine it into more and more detail, and by that stage it is quite difficult to stick your head above the parapet and see if you are still at the same place. Then you show it to the users for acceptance test, and they say “Oh! But that was all very well then—we do things differently now!"

However, and as far as information technology was concerned, the company's four main business systems—PRISM, ILM/EDL, EMC and the Finance Systems—painted only half of the picture. In true entrepreneurial spirit and in order to remain ‘state-of-the-art’ EP encouraged the consideration of alternative approaches to the development of systems and it was constantly assessing the viability of new roadmaps. As such, bespoke application development painted the other half of the picture. Following the decision to devolve, the emergent autonomous business units were given complete freedom regarding the development of bespoke applications that suited their own particular needs. The ITSP unit (see Figure 2) was formed to provide strategic technological directions and act as a buffer between the units and the management of the company. However, its recommendations were most of the time largely ignored and scoffed at by the units who approached it as an ‘ivory tower’, in safe distance from operations and the heat of the battle.

The above situation gave rise to the existence of two parallel but contrasting worlds that can be summed up by the two following development scenarios:

Business requirements were identified, and a system was designed, built, and tested to those requirements (the ‘classic,’ formal approach to development by which the four main enterprise information systems were put into place).
The user, when given tools, created added value to the business in the form of some kind of ‘informal’ application. Other users viewed this and requested to use the result, upon where the application was then used as a multi-user system (an alternative, informal approach to development which gave rise to a multitude of applications serving individual requirements at the business unit level).

Some managers from ITSP looking at this phenomenon from a macro perspective believed that any information system should fit into the overall business strategy of the company and therefore development should be totally driven by the latter. However, there were contrasting opinions. Managers from Group Finance (GF), for example, were in favor of the view to disregard the long term and instead concentrate on the short term by putting in place the application that they thought would suit the business needs of the moment. One manager commented:

"I tend to think these days that if you are looking at the long term fit at the application level, you are wasting your time because the business is changing. In the short term, the benefits are that you produce something very quickly, very cheaply, and you get reasonable user satisfaction because they get what they want quickly. But you are going to have problems in the long run because these systems run out of date, they are not cohesive, and they are going to loose this fit, and you will have a much bigger problem in replacing all these diverse elements."