Journal of the australian naval


MANAGING MANAGEMENT INFORMATION SYSTEMS



Download 5.37 Mb.
Page33/78
Date03.04.2021
Size5.37 Mb.
1   ...   29   30   31   32   33   34   35   36   ...   78
MANAGING MANAGEMENT INFORMATION SYSTEMS

By Group Captain P. Rusbridge

There is no doubt that we are all becoming pre-occupied if not obsessed by the possibilities opened up through the widespread and increasing use of computers. Attitudes range from uncritical enthusiasm to rejection based on unreasonable doubt. I was an unreasoning doubter. I am now travelling the road to Damascus, and, if I haven't seen a sudden blinding light. I at least can see a dull glow on the horizon.

Nevertheless, I still cannot help feeling that Man demeans his intelligence by glorying in his pathetic attempts to mimic in computers trivial examples of that intelligence or to replace with ponderous ineptitude the sublime aspects of that intelligence by crude and wasteful digital processes. For it is the invention of the digital computer that I hold chiefly to blame. It almost seems that the change from analogue to digital processes, coupled with the release of enormous processing power, make us believe that we have been relieved of the necessity to think.

Perhaps I exaggerate slightly. If I do, no matter, because my purpose in expressing these sentiments is not to make a point per se but to acquaint you with my prejudice against computers. What I have to say may be judged by the reader to suffer from that prejudice. However. I can guarantee that that prejudice will not reflect an unwarranted enthusiasm for computers.

The big fact about computers is that, whether we like it or not, we are stuck with them. In their applications to management information systems, we can see a virtual explosion of use The pace is quickening, too, with the rapid advent of second generation systems to replace the obsolete first generation. My acceptance of computers is based on the assumption that, if the rest of the world is adapting to computers, then I must do the same.

As a manager, I cannot afford to be left isolated with information systems which cannot communicate electronically with other information systems. I must be like Shaw's reasonable man who 'adapts himself to the world.'

So, reluctantly, and with severe misgivings, I venture into the minefield of computing. I've been doing it for two years now and have

overcome my reluctance to express an opinion on a subject I know so little about. Very few people know very much about computers anyway. Understanding computers isn't a matter of being able to write a programme on one's PC. or being able to tell the difference between a modem and a megabyte. It's much more than that.

It is more an understanding of what makes some computing systems outstanding successes and what makes others total failures Increasingly, I am coming round to the idea that what makes a successful system successlul is people, and that what makes an unsuccessful system unsuccessful is. once again, people.

Everyone nowadays has a horror story of a computing project that went wrong. My current favourite is that of a system installed by the US Post Office.' It was a work measurement system which was two years late, cost twice the original budget figure of $30m, required more staff to operate than the system it replaced, had a higher error rate, increased operating costs and produced unused reports. You could not envisage a more comprehensive disaster than that. What went wrong? Was it the wrong hardware, or software? Or was it the fact that the system was not acceptable to the work force who were required to make it work, or to the management who were going to use it?

How can a manager, responsible for conceiving, developing, planning, costing, implementing and operating a major computing system be reasonably confident that he is not creating or perpetrating just such a disaster for which he will be held responsible?

I've already stated that I suspect the key to answering these sorts of questions is to take careful account of people. Two groups are important: the users of the proposed system and the senior management of the organisation of which the manager and his proposed system is a part.

The Author

Group Captain Peter Rusbridge entered Dartmouth in January 1957 After 15 years in the Royal Navy he joined the RAAF in January 1972. He is now Director of Maintenance Policy in Air Force Office.

November '86. Journal ol Ihe Australian Naval Inslilule — Page 33

First, and perhaps most importantly: the users. Late one night, recently, in a hill-billy shack cafe in darkest Alabama. I took part in a deep, if slightly bacchic, discussion on the question of users Users are the people who foul up computers systems. Through their crass ignorance, often wilful, of computers, their hostility, their continual raising of irrelevant issues, their reluctance to change their ways of doing business to accommodate computers, their unjust criticisms, and their refusal to use computers as intended, users are the group of people of greatest frustration to computer people Yet, in the last (and perhaps the first analysis), they are the only people who count.

Let's face it.' said our genial host. It ain't user-friendly till the user says it is!' Some of his audience couldn't accept that It was going too far. It represented an ideal, but an impractical ideal Others generally agreed, although seeming to regard it as an exaggeration to make a simple point

What l have seen and learnt recently leads me to doubt that it is either an impractical ideal or an exaggeration. It represents the simple truth which a manager ignores at his peril.

It ain't user-friendly until the user says it is.' What does it mean, and what are its implications? It means that a system will not be accepted by the people who have to put the data into the system and by the people who have to get that data out of the system until it makes their jobs easier and not harder If they don't accept it then they will reject it with a range of possible adverse consequences from total failure to reduced effectiveness below expectations.

How can computers make peoples jobs easier and how. too often, do they make their |obs harder'' In order to develop these points. I must cease generalities and talk of the particular environment which I know best — making military aircraft fit to perform their required missions

An aircraft maintenance organisation can be likened to a giant engine with a control system The control system measures the output from the engine and feeds the information back to the controller to ensure that enough resources are fed in to keep the engine going at the required pace This analogy is almost too simple to convey this multiple needs for information at many different management levels which exist in the maintenance organisations Many functionaries need information in different forms which reflects how well the aircraft are performing and what their current and anticipated needs are.

Unfortunately, this information is collected by other people who are not particularly interested

in the information per se. as the information is generally not necessary directly to help them do their jobs These people dispatch an aircraft on its mission and receive it back after it has down They fill it up with fuel and weapons, they blow up the tyres and they do routine maintenance on the aircraft.

In the rapidly changing priorities of their world, they only have one overt interest and that is trying to find sufficient aircraft to fill an often rapidly changing flying programme There is never enough time to adopt a calm, methodical and incremental approach to their work. These people do not particularly want to collect information lor other people to use, even il they know that, ultimately, such information may help them in their jobs They have different priorities and. when the going gets tough, providing that information is often neglected in terms of completeness and accuracy

A proposal to computerise this information-gathering function may make the task easier However, if a manager is not careful, it may make the job harder.

What sort of information are we talking about7 You can imagine — flight times, details of replenishment, how much fuel, what stores, lists of faults in the aircraft which need to be fixed, records from onboard sensors which describe what the aircraft did on its previous flight (black box recorders), what new spare parts were installed and who did the work and inspected the work and certified that the work was necessary and sufficient.

I'm sure you can relate this scenario to your own environment. Every large organisation needs information such as I have outlined for my own organisation Hospitals, warships, infantry battalions, a retail store — organisations all have comparable needs

Potentially, computers ofter all sorts of advantages in the collection of the information. In various forms these are claimed to be increased accuracy, reduction in paper work, increased speed, increased volume of data. Potentially, these benefits are possible. However, whether thet are realised or not is another matter I maintain it depends on whether the user accepts the system or not.

Whether the user accepts the system or not depends on whether the system makes his job easier or not Whether the user as a person who puts the information into the system accepts the svstem depends on whether the system makes it easier tor him than before to put the data in.

This may seem a rather obvious point to make and hardly worth elaborating at such length Nevertheless. I am unrepentant. I have seen a $35m computerised maintenance management

Page 34 November 86. Journal ol the Australian Naval Institute

system slowly but inevitably being rejected by the users because it is slower and more difficult to use than the system of grease boards, intercom and bicycles it is intended to replace.

The fact is that all too rarely are users brought into the planning process and consulted sufficiently about what their needs and problems are. Even when they are so consulted, the fact that it is on a consultation basis is often a process of THEM developing a system for US, They, with their white coats, their computer jargon and their world of weird formulae and black boxes, do not really understand us, and we do not understand them

They say that they understand and yet they do not really understand. How could they have understood when they produce this system which we can't really use. or which is no better than what we had before7

It may be true, as they say, that budget problems have forced them to give us only one terminal between eight instead of the one between two that we were promised. However, at the end of a busy day. when I should be putting in my data, collected during the day on scraps of paper, I am not prepared to stand in a queue and wait for a terminal to come free. It may be true, as Ihey say, that difficulties with the contract resulted in a smaller CPU than was originally intended However, I haven't time to sit in front of a screen which will only flash 'Please waif af me when I want to use it.

It may be true that the software was not designed to handle components which are owned' by another squadron. However, when my workshop does an urgent job for another squadron and I find that the computer wont allow me to record what we have done to that component because the computer fails to recognise the component, then I haven't time to make the effort to record the information another way.

What was the point of so constituting the system that it can only tell me Orion flying hours? I want to know how many Orion flying hours were used for maritime surveillance and how many were ASW. and it can't tell me.

These hypothetical illustrations arc typical of user disappointment and frustration. The user reaction to such obstacles is to try to work around them. If data input is solely electronic, then, in these circumstances the data will almost certainly be lost. If the data is lost, then the data­base gradually becomes discredited. When that happens, then the people using or needing information from the computer also become disillusioned and frustrated.

It is my central point that none of these sorts of problems need happen. They may be claimed to

be the result of technical difficulties, budget restraints, contracting difficulties or a host of other reasons. However, they are basically 'people' problems caused directly and, usually exclusively, by failure to sufficiently involve the user in the development process.

A relatively modest, but properly planned system with proper user involvement may succeed where a higher budgeted system, trying to do the same job may fail. You cannot avoid trouble simply by outlaying more resources Possibly, you may never be able to buy your way oul of trouble at all. without scrapping and starting again.

Success, or at least avoidance ol the sorts of problems I have described can be assured by running a consultation process with users which ensures that they feel that the problems created by introducing and using a computerised MIS are their problems. In addition, the problem-solving process must be theirs so that, above all. the solutions are theirs.

How this close involvement can be contrived will vary according lo the organisation. My own approach includes the setting up of a centralised body with an appropriate mix ol computing professionals and user professionals as close to the users as possible, but with authority derived from the highest level of management. This body should be charged with the task of the overall planning or management of the project Each level of users must be represented by a user group or a delegate who has direct contact with the central body. At appropriate stages of a development process these user groups or delegates are drawn into the central body and they participate in the development of their particular phase to a degree such that they feel involved and responsible

Whether this approach will work or not remains to be seen You only get one crack at a task like this, and I am involved in the very early stages of our make-or-break project. It requires money and men up Iront and they are in short supply. Organisational changes will be necessary, and organisations are not historically very good at changing to meet the needs of fashionable upstarts such as computers.

However. I am assured that, in designing computer systems, it is even more true than in the design ol more tangible products such as aircraft that the major decisions are made sometimes unwittingly in the early stages of the life of a project and that, as time passes, one's Ireedom of manoeuvre to rectify any of these decisions which turn out to be wrong and lo do it within budget are steadily reduced.

November 86. Journal ol the Australian Naval Institute — Page 35

These factors indicate the need to sell one's ideas to senior management, and this leads to the second major point I wish to make.

It is simply that information-technology (the latest buzz-phrase for computers) is now pervasive in all organisations, big or small. Information in the computer age is now a major resource like money, men. materials and so on As such it must be managed with the same emphasis and commitment as we need to manage — say — money. The responsibility for involvement in and management of Information starts right at the top.

So. senior management nowadays must be involved whether they like it or not. It is no longer a case of setting aside relatively small sums of money for the purchase of computers which one's staff claim passionately will save time and resources The whole centre of gravity of computing power is beginning to shift upwards in the management chain. Senior management can no longer refuse to become involved. Their peers all around them are starting to demand information the use of which allows them to continue to take effective decisions in an environment of ever-diminishing resources.

By and large, existing management were brought up in a different and bygone era. Their luniors are a very different breed I was recently given a powerful demonstration of computer design and graphics, all in beautiful technicolor. In a few minutes the young engineer who was making the presentation re-designed a fuselage pressure bulkhead to reduce some maior stress concentrations which could have affected the structural safety of the aircraft. I watched the redesign taking place on a large screen.

When it was over. I said to him You know, you re very lucky When I was your age all I had was a slide rule and log tables ' Ah. yes. Slide rules!' he replied. I know what they are. I've got one hanging on the wall of my den.' Cheeky devil!

Not only does senior management find an increasing need for information from computerised management information systems, but the increasing cost of ihese systems is beginning to demand appropriate involvement from senior management. However, the technical complexities of computers are rapidly becoming such that there are virtually two environments to cope with. The first and lower

environment is that of the technical man. the computer specialist who designs and implements systems. The huge cost of what he does means the involvement of higher levels of management where the lingua franca is not of megabytes or CPUs, but of marginal costs and return on investment and productivity indexes

In between these two layers lies the minefield of maior project management — where managers must be competent enough technically to call the shots, literate and experienced enough managenally and organisationally to react to the requirements of the strategic thinking of top management. Quite a nice balancing trick. I can assure you.

Just as the users must feel that the system is theirs, its problems are theirs and the solutions are theirs, so must senior management be equally committeed to the major decisions taken in implementing a system. Without that commitment, success will inevitably be diminished. Disaster is possible.

I suppose that the title of this article is a bit of a misnomer in that I've discussed mainly implementation ol new systems rather than management of existing systems. However, on reflection, I don't apologise My experience of managing running systems is that much of the task consists of coping with problems inherited from the implementation phase. The inadequecies of the original installation remain to haunt the existing system continually Money and resources are consumed coping with problems caused in the installation in a process unfortunately called maintenance. The costs of this so-called maintenance are often so high that they prejudice if not completely outweigh the originally expected benefits. So. planning, developing and implementing are everything.

There is a blackboard I walk past regularly It says

'There's never enough time or resources

to do the job properly. There's always

enough time and resources to do the job

again.' Not a bad epitaph for a failed computing system.

Notes

1 Langford 4 Oliver, Principles for Successful Systems. Proceedings of ACC86. 20 SEP 86

2. Thomsett R , Pragmatic Project Management. Proceedings of ACC86. 20 SEP 86.

P.lljM » NovemftOI 96 Iinjlll.r .,1 lh.- Aij\ImI,j:i N.lv.H InSWlM




Share with your friends:
1   ...   29   30   31   32   33   34   35   36   ...   78




The database is protected by copyright ©essaydocs.org 2020
send message

    Main page