EPILOGUE: THE CHALLENGE OF MANAGING CHANGE AND INFORMATION SYSTEMS DEVELOPMENT

A question that should be asked at this stage is thus: how, on one hand, is it possible for such a level of information system misfit to exist, and yet an organization as heavily dependent on its systems as EP, to be able to flex and adapt successfully to the continuous environmental contingencies? Although it can be safely said that there was a negative overall perception regarding the alignment of the systems, with a large percentage of those not being used as they were supposed to—user activities and tasks did not seem to be disrupted in any way. Paradoxically, users were not tied down by the systems. What explained this phenomenon is perhaps the simple rule of survival: threatened by adverse circumstances, one has no choice but to adapt. One manager from Group Finance commented:

"You think that you have a financial accounting system, and you think you are producing the company's trading account, and one day you find that everybody is doing it in a different way by the spreadsheets. And you could say, 'You shouldn't do that! It is all there. It is a waste of time!' But people do not waste their time for the sake of it, do they? It is obvious then that they are doing it because there is some great hole in there."

The same phenomenon was evident in what a manager from Generation said:

Systems have fallen away and people are not using them as much as they should. And just about everybody, everywhere, is taking data out of the main systems, and either re-keying it in, or use whatever method is available to them to get data into little applications, so that they can then move the data around and use it the way they want to, because they see that the system they access—the PRISM system—is inflexible. What we are trying to do now is to recognize that this is a key requirement, and just deal with the data—not to deliver them any systems.

The Sales and Marketing business unit was a heavy user of the Finance systems. This is what a manager there said:

"As changes occur in the business world, if you cannot get to change the system because the money or the project team has gone—they do it with a spreadsheet— they do not bother with the system that you have spend half of your life to develop—that's a hidden problem as well. I mean, we look at systems and say 'Oh! We never change the system. It is a bloody success!' But really, what happens is that the buggers put a Lotus spreadsheet there to do their work with it. I mean our Finance systems are crap. If I want to know how much money I have spent on contracts at the end of this month, I go and get a bloody spreadsheet. Walker cannot tell me—not in the way I want to say it. So people do bits and bobs around the edges, don't they?"

The ITSP unit had a name to describe this situation. They were calmly referring to it as the ‘Lotus Cult.’ An appropriate name—‘cult’ signifying a kind of underground alliance— for the groups of users who had a disregard for the formal information system imposed on them, and in a way had taken control of their own ‘fate’. However, this underground activity had come to be seen as essential even by the ‘authorities’ themselves. One member of the ITSP team said that if one ever attempted to take this away, parts of EP would stop operating within a day, and the company would soon collapse. Hence, EP was facing an obvious challenge. What were the plans for future systems development in the light of this situation? The leader of the ITSP team said:

"Why don't we just build them a Lotus system that does all that? Well, the real reason is that they will not use it—they all got a slightly different view of what they want it to be."

Such was the extent of the issue facing the company, that in late 1996, a new business unit called Business Systems Department (BSD) was established to address this seemingly problematic situation. Its objectives were clear: to scale down and maintain the complexity quotients of the infrastructure as low as possible, and create an integrated high-caliber UK business systems competency. Thus, having started from nothing in 1990, EP went through a period of major information technology investments, through a period of devolved budgeting and responsibility for development, and was heading towards one of more coordinated control, having as few products to be used to deliver bespoke applications as possible. The argument for that form of policy was that the liberty given to the business units with respect to developing their own applications had culminated in a highly complex, and hence difficult to manage infrastructure. A senior manager noted:

"One of the factors that has happened to EP, is that we are disintegrating, we are devolving in terms of development and as a result of that, we lost a lot of coordination, so department A is using one tool, and the department B is using another tool. I mean, if you give users a lot of autonomy, you should not be surprised that they use it."