Printer Friendly

True user involvement: successful system design.

The education, experience, and the common sense of system analysts and designers tells them that user involvement when developing a new system is essential for success. So we invite the user to participate with us in the analysis and design process, talk to users and user managers, and with walkthroughs and reviews of flow charts, make sure that our representation of information flows, etc., are as accurate as possible. This produces better information needs and wants, so we can proceed to produce the system specified by this activity. But is this true user involvement? We suggest it is not and that great rewards await those who go beyond these routine "textbook" steps.

The kind of user involvement described above, though practiced widely, can, at its best, expose the user. At its worst it accomplishes nothing; after all the users are busy doing their own jobs, attending meetings, travelling, and doing those things that make the company work. System analysis and design is like programming, best left to the specialists anyway. Right? Wrong! Opportunities for significant contributions abound for the system designer who applies true user involvement to produce systems that are truly integrated with the user and the users' work. Is it possible, then, that we have interpreted the phrase "user-involvement" wrongly all these years? Or possibly stopped too soon in our interpretation? Perhaps it should mean more than exposing the user to the design process. Maybe true user involvement means involving the designer in the user's work process so that he or she can move from reacting to crises to proactively designing systems that support total user productivity. So that we may better understand the reasons for these questions and attempt to find some convincing answers, we illustrate using a manufacturing plant in the southeast.

A Case Study

This particular plant has six major machine lines producing various company products. These machine lines were maintained by a staff of 150 mechanics on a three shift basis. The mechanics were having trouble getting parts for repair and preventive maintenance from the stockroom which stored 18,000 parts valued at $9 million. These parts are of two types; company-unique parts made for one of the six major machine lines and generic parts such as bearings, o-rings, fasteners, and air cylinders. The unique parts were identified by a drawing number and the generic parts by the manufacturers' number. Generic parts were also assigned a consecutive number by purchasing, such as OR1010 which stood for 1,010th O-Ring entering the system. The stockroom staff of 12, over the three shifts, was young and low in seniority.

A Problem Solving Opportunity

Problems had only surfaced recently so that the analyst was curious about how they had developed, and explored the history of the system. The previous stockroom personnel had been recruited from the mechanics' crew and probably were older mechanics who wanted to be in a less strenuous environment. The numbering and access system, such as it was, evolved to fit these circumstances; these people didn't need a numbering system. They brought with them years of experience on the machine lines, they also possessed detailed knowledge of the machines and could discuss repairs, suggest alternative parts and warn against potential problems. They were, in fact, consultants as well as stockroom clerks. Things reportedly worked smoothly for many years -- until the "system" changed. "System" means not just the numbering and access system but the bigger environment within which the detailed system must function. Over time, the machine lines grew, the number of parts stocked grew, and the experienced stockroom staff retired.

So a new system came into existence. New staff were recruited from traditional stock clerk candidates, and were lower paid and less experienced; no one could justify putting senior mechanics into the stockroom. The fact that this was a new system was not recognized. The system had been altered, specifically the skills of the staff, but it had not been restructured to take this into account. Something had to be added or changed to make up for the lack of machine knowledge among the new stockroom staff. Their performance, no matter how they tried, could never equal that of the old staff. A truly user-oriented analyst should have foreseen what the change in skills meant, and initiate redesign of the system before a problem arose. A true user orientation would break the analysts out of the traditional patchwork reactive mode -- jumping from one crisis to another. Instead they should develop and maintain an understanding of what is going on in the users' work environment such as changes in equipment, processes or skills. Then they must proactively and systematically design systems that would apply their technology and expertise to total support of the user.

The Numbering System

The task of the analyst team was to implement a computer based, on-line system for access to the pertinent stockroom parts data with emphasis on a new numbering system to compensate for the lack of machine experience in the stockroom. The goal was to eliminate the mechanics' waiting time at the stockroom window caused by the clerk's inability to identify parts. The basic "information system" solution involved developing a unified numbering system to identify parts. Obviously, the question of significance vs. non-significance was raised at the outset. Nonsignificant numbering systems (i.e. numbering all the parts sequentially from 10-17000), have their place in many circumstances, but in this case, to meet the requirement that the system be easily understandable and usable by both the experienced mechanics and the inexperienced stockroom employees, we would have to incorporate meaning into the scheme. Systems must be designed to succeed with employees who vary in motivation and ability. In such a situation, it is a challenge for the designer to design a numbering system so logical that people learn it naturally.

As usual, the accountants required only that each part be uniquely identified, thus giving the designers a lot of room. The key to designing such a natural system is to understand how the users describe the items and base the system on that. The classical type of user involvement would have resulted in meetings with maintenance supervision and possibly production supervision. It would have called for prototype numbering systems being proposed and reviewed with these supervisors, with those supervisors reviewing the information flows and data base structures planned for the system as they became clearer. However, in this case it was recognized that the users were the mechanics themselves and the analysts spent a lot of time with them understanding their work.

This system design activity took the problem of user involvement to the next step. Instead of involving users with the design, the designers became involved with the users, spending time with the mechanics to discover how they saw the world in question, walking in their shoes, discovering how the mechanics thought about the machines they serviced and the parts they used. Instead of assuming the users would and could learn the analyst's terminology and procedures to fit into their new role as "designer assistant", the analysts here went out to meet them half way by becoming "user assistants."

They discovered that mechanics visualized the parts by basic function, rather than by vendor or unique part number. A bearing was thought of in terms of inner diameter (ID) and outer diameter (OD). Specifying these dimensions in the numbering scheme with a prefix BRG would suffice, with a description field adding any further required information. Obviously, this simple scheme would not discriminate between all the bearings of similar dimensions that exist in the world but it would do a fine job of identifying all the bearings used in this company.

How to make sense of the thousands of parts used on the six machine lines? The answer turned out to be something like the product structure tree or indented bill of materials. Break each line down into logical subsystems, then divide these into subsystems until the listing of individual parts is reached. Think of a car, for example, a Thunderbird. The first set of subsystems might be body, suspension, engine, or electrical. This breakdown doesn't have to be real or absolute, or discriminate between the Thunderbirds and Monzas, just consistent with the way that the users see the system. After discussions with mechanics, a way was found to break each line into six to eight subsystems, some related to position along the line, others to function, such as electrical. Analysts were tempted to develop a perfect identification scheme; designers often feel this urge, this challenge. The objective was, however, not a perfect system but rather a sufficient system. The wise designer resists the temptation to let his own objectives rule the design and allows the user to dominate.

Access to the System

A conventional system would have implemented the access system with terminals in the stockroom for inquiry into location, inventory levels, etc. by the stockroom workers. Parts manuals would have been distributed around the six machine lines about the numbers of the parts they needed for repairs. They would then fill out a requisition form for the stockroom which would reduce waiting time by reducing the time that the inexperienced stock clerks took to access the information that they needed to deliver the parts. And this was the objective of the entire design effort, wasn't it? Well, yes, but these designers realized that it wasn't the whole goal. The goal of any system development is to make the company run better.

Recognizing the Real Goal

In this particular system, the way to make the company run better was to reduce the time that elapsed between the recognition of a machine problem on the line and the completion of the repair. A second goal, implicit in the first but never stated, was to increase the utilization of the mechanics: to reduce to a minimum the time they spent in non-productive activities such as waiting in line. The designers' involvement with mechanics led them to the realization that mechanics resented this wasted time away from their work as much as any so-called "professional" would. They learned that the mechanics were involved with their work. Why not, then, let the mechanics become involved in the system; make the system a part of their work. Make it so that user-system integration enhances the user's productivity and is not merely a provider of reference part number information. Since the real goal of the system is to reduce downtime, it became apparent that the system must be a mechanics' system, not a stockroom system. Designing it this way, while at the same time providing needed assistance to the stockroom, sends a powerful message to the crew. It says that management recognizes that they are a valued and respected part of the company team; they are involved in the company and the company is involved in them. In this case the message is truly in the medium.

Improved Planning

As the system design evolved and as the mechanics and stockroom workers became involved in the system design, so the system was designed to become involved in the work of the mechanics and the stockroom clerks. The system could be used by the mechanics as an aid in trouble shooting because of the indented breakdown nature of the part numbering system. Since the entry point to the numbering system was patterned after the way in which the mechanics thought about each machine line, the system was constructed to step down through indenture levels, giving system, sub-system and finally detail part numbers and descriptions of each successive indenture level. Merely having access to the parts that make up the successive levels gives an experienced mechanic valuable clues to the probable cause of trouble, even before he starts tearing down the system. Further, since inventory levels of detail parts and subassemblies are also returned at each level of inquiry as appropriate, the mechanic can decide not to start teardown if a likely cause of the trouble is not in stock. When the time comes, the mechanics can prepare a stockroom order and have it printed out in the stockroom so that the order can be ready and waiting.

Constructing A User Data Base

The analysts realized that the system must be "owned" by the mechanics; that the system must be involved in their work and not merely provide reference support. Therefore, ways to further involve the system in the work process were sought. The search was short. Consider the wealth of information that a mechanic could possess after working 20 years on a set of machines, although few of them had that much experience, and the experience they had was usually in localized areas rather than in all machine lines and all subsystems. Also, when the mechanics changed jobs, their experience was lost and the learning process started all over again. Lost productivity, lost efficiency, lost effectiveness. But could the system provide a way to help preserve these years of experience? Quite easily, by adding a notes table to the parts data base linked to each part and subsystem. This means that if a bolt breaks easily, the mechanic can note it, so when a less experienced mechanic works on that system they will be forewarned. Also, if experience shows that it is best to replace part B whenever part A is replaced, that too can be noted. Over a very short number of years, data base of tremendous value to the company will be built up, and it will be built not because of the value to the company but because of its value to the mechanics.

Increasing Access

There was considerable discussion about who should be allowed to enter these notes. Allowing just anyone on the system might lead to abuse, jokes, or other improper inputs. True, but this would be more an annoyance than a critical failure. Also, is this a bias; would we have such fears if the users were fellow analysts and not mechanics or other "outsiders"? If the object is to produce a system that is truly a mechanics' system, then the mechanics must truly own it; they can't own it if one of the most important features is controlled by maintenance engineers or by supervisors. What good is experience if it is filtered by someone without the experience themselves? A typical screen from the computer may show 12 sub-systems on machine 811. Access to the contents of the sub-system can be obtained in a variety of ways; entering the sub-system number on the "Enter Bill #--#--Bill #-- line, inputting an "X" next to the number of the sub-system of interest, or by tabbing through the fails until the sub-system needed is reached, the user has several choices, such as:

* Look at the quantity on hand and location,

* Begin to build an order file,

* See any notes, with an unlimited length of file allowed,

* Print the list of parts for the mechanic,

* Send the order to the stockroom.

Increasing Implementation Success

As the analysts looked forward to implementation, they applied two lessons that systems developers have learned from experience. The first is that the most risk-filled phase of the systems development life cycle is the end game, the implementation phase. Everything has to come together and work without problems at this time in order to have truly successful implementation. The second lesson is that of the value of a "champion," someone who will enthusiastically support the system and advertise its benefits to others, and by his or her enthusiasm, infect the others. So, rather than holding the traditional, high profile system kick-off, it was decided to turn it on in one small department which had given the designers a warm welcome and extensive cooperation during the involvement process. The members of this department seemed to be convinced of the value of the system to them and to the company and everyone from the mechanics to the department head had contributed ideas and criticism throughout the design. Thus the system to a large extent was theirs and they had an interest in seeing it succeed. The system was tested in this department as elements were completed by the data processing department and for a period as a complete system.

The long term involvement of the department members paid off in another way. As any analyst knows, it is important, and very difficult, to respond objectively to criticism. In this case, since the users and the analysts had worked together during the earlier design stages, the atmosphere was one of "how can we make the system work right?" rather than "why did you do that wrong?" The give and take during implementation was objective and a better system resulted.

When a fully integrated system had been operational in this small area, it was expanded into a larger department where support had also been good. Then, the company wide, high profile, kick-off was held. There were still problems, naturally, and some resistance, but with the momentum of success built from trouble shooting, actual size, and demonstrated benefits in the two smaller departments the project moved to successful completion.


Increasing technical capabilities of modern computer-based information systems and the advancing ingenuity of both system designers and system users are allowing, even requiring, information systems to be more closely integrated into the users' work style. This results in an informational tool that supports the users' work just as a power wrench does. This problem could have been solved with manuals of part numbers located in the work area and quantity/location access system in the stockroom. But by keeping in mind the true goals of the company, by taking the time to become involved in the mechanics' work, and by thinking through the effects of the design on the behavior of the people, much more was achieved. The new system will be used more fully, the company will gain a data base of plant wide knowledge on machine repairs, repairs will have more planning, delays at the stockroom will be reduced, the skills and effectiveness of the mechanics will be upgraded, and they will feel more valued and respected by the company. All these additional benefits were accomplished at little extra cost.

This was the case of true user involvement. User involvement of the traditional kind, where users are exposed to our design deliberations, invited to design reviews and walked through data flow diagrams and data base hierarchical charts will not result in a system that is fully integrated into the users' work life unless the user has the time and the awareness to insist that we, as analysts provide it. We must provide the integrative leadership to meet this objective. The analyst must think about how the system fits into what the users do. What effect will a design have on people, what effect would be better, how can we obtain that better outcome? The difficulty is that the process is not easy. A possible satisfying system can result without extra effort. Also, there are other barriers, unchallenged assumptions, hidden agenda, complacency, and the comfort of the status quo that make generating fundamental change a real challenge. But opportunities abound for the systems designer who applies true user involvement to produce systems that are truly integrated with the user and the users' work.

Frank C. Barnes is Professor of Management Information Systems and Operations Management, University of North Carolina, Charlotte, and Chandler M. Bush is Associate Professor of Management Information Systems and Operations Management, University of North Carolina, Charlotte, N.C.
COPYRIGHT 1992 St. John's University, College of Business Administration
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1992 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Barnes, Frank C.; Bush, Chandler M.
Publication:Review of Business
Date:Dec 22, 1992
Previous Article:Administrative ethics in health care resource allocation.
Next Article:Market power and successful global competition.

Related Articles
Computerizing small business.
The user is the key.
Human Capital: DOD's National Security Personnel System Faces Implementation Challenges.
Assistive technology; from virtuality to reality; proceedings.
Eight steps to successful taxonomy design: when users are not involved in classification system design, their deployments frequently fail.
Developing user involvement in HIV services in London.

Terms of use | Copyright © 2016 Farlex, Inc. | Feedback | For webmasters