241
Case Studies
Systems Analysis in a Complex Environment: An Interactive Educational Approach 1. Introduction
James F. Cox Department of Management, 30602, USA
University of Georgia, Athens,
GA
and Charles
A. Snyder
Department of Management, AL 36849-3501, USA
Auburn Unwersity, 322 Thrrch Hall,
Many approaches have been proposed for systems analysis but few researchers propose a continuous educational exchange between users and systems analysts. This type of exchange is critical to successful system implementation when the environment is complex and subject to change. Both users and systems analysts must be informed of the others’ roles and the purposes and objectives of the system. This paper presents a conceptual model of providing education to both users and analysts in each phase of system development and an application and discussion of the model. Keywrds:
System Analysis and Design, System Development. Life Cycle Approach, User involvement, Analyst involvement, analyst education, user education.
James F. Cox,, CPIM *, is Professor of management m the College of Business Administration at the University of Georgia. He obtained his Ph.D. in Engineering Management from Clemson University. He has published over thirty articles primarily covering the fields of operations management and manufacturing information systems. He has worked in Production Planning and Control and Industrial Engineering prior to entering the teaching profession. Jim has held numerous positions in the American Production and Inventory Control Society and is currently Region IV Vice President and on the National Board of Directors.
North-Holland Information & Management 037%7206/85/$3.30
8 (1985) 247-252
‘0 1985. Elsevier Science Publishers
While there are many models for systems analysis and design, most of them fail to address the educational requirements of the process adequately. Consequently, information systems are often designed and implemented that provide inadequate or marginally acceptable user information. This deficiency is often a result of the failure to educate the user in basic concepts and alternatives and perhaps more importantly, failure to educate the systems analyst in the technical aspects of the functions of the proposed system. The problem becomes particularly serious as the alternatives become more complex. This paper describes an approach involving a joint continuous learning process and a case study which utilized this concept. Although couched in the system development life cycle framework, this model differs from the classical “phased” (freeze-the-project) approach in that education is a major factor in any model education of the user and of the system analyst. This education relates to providing the user a basic ____.
____
Charles A. Snyder is Associate Professor of Management. School of Business, Auburn University. Alabama. His Ph.D. is from the University of Nebraska-Lincoln. Before joining Auburn University he held a number of command and staff positions in a 20 year career in the U.S. Air Force where he had extensive systems and telecommunications management experience. He has done a wide variety of information systems consulting. His research interests include developing strategies for implementing and integrating emerging information technologies, analysis and design methodologies, and management of information systems. Dr. Snyder is a member of APICS, AIDS, SMA. and other professional societies.
B.V. (North-Holland)
248 Cusf Studies
understanding of information systems as it relates to the project and to providing the analyst an understanding of the technical aspects of the application. The educational approach facilitates more meaningful involvement by both the user and analyst.
2. Literature
Review
Although most systems analysis and design models emphasize training, few acknowledge the importance of education. We wish to differentiate between these. Training traditionally involves instructing the users or operators in the technical features or operational procedures of a specific system. On the other hand, education is broader. It should provide: 1. Users with a general knowledge of systems methods, equipment, software, and communications features and capabilities. 2. Systems analysts with a broad knowledge of the target system’s functions so that the user’s needs may be better satisfied. A review of the literature reveals that most researchers emphasize training of the user. (See, for example, [2,5,9,11,14,15]. Keen [6] states that data_ processing management must educate the users by gradually defining what the user needs. In addition, DeMarco [3] has identified the need to have corrections to the system imposed by the user (who understands the overall system better than the analyst). The analyst is seen as responsible for the training of the user in how the information system will work and how to use it. This view acknowledges the two-way educational process for successful systems design. Roberts [lo] has noted the importance of education in supporting a specialized information system, material requirements planning (MRP), and clearly separates education from training. Awad [l] states that user training is a prerequisite for system implementation and that it takes place in parallel with programming. In Murdick’s [9] view, training is done in four parts: (I) management orientation, (2) management use of the system, (3) operating personnel use of the system, and (4) programmer training. However, all this is included in the implementation phase. Wetherbe [ 151 also includes user training as a part of the implementation phase, but acknowledges that an early
start is desirable. The importance of training is emphasized by Davis [2] who states that it is probably the most overlooked aspect of system implementation. Tapscott [13] stresses the importance of more emphasis on the user in the design process in office automation. This importance of the user really belongs in UN management information system analysis and design processes and it underscores the necessity for education throughout the process.
3. Methodology Although Gane and Sarson [4] state that the systems analyst need not become expert in the functional area for which the system is being developed, we believe that the systems analyst should thoroughly understand the functional area for which a complex system is being designed. Additionally, the users should be educated in available implementation alternatives. In this manner, a continuous dialog may be established between the analyst, the project team members, management. and the users. Although little agreement exists on the phases in information systems development, most approaches employ a life cycle approach or framework [12]. While some approaches, most notably prototyping, do not follow these phases, the need for education remains crucial. The phases of problem definition, analysis, logical system design, physical system design, programming and procedures, test and implementation, operation, and evaluation and modification are typical in life cycle approaches and although the terms may differ from others, the basic activities are much the same. Since the case that follows was in a life cycle format, the relevant phases are outlined. Problem definition. In the initial phase, the problem or objective of the information system is identified and defined. In this phase, the need for an information system’s change is recognized [ll]. A statement of the proposed system’s purpose, scope and objectives is generated. A preliminary survey determines whether a more detailed feasibility study is justified. Usually a feasibility study of the proposed system is conducted to determine whether to initiate the project [8]. Even in non-life cycle approaches such as prototyping, the feasibility study is usually conducted. The need for
J. F. Cm,
education in this phase should be obvious in conveying the requirements of the system to all concerned individuals. After sufficient educational exchange there should be a clear understanding by the users, the analysts and management about the problem, the proposed system objectives, the scope of the project, and an estimate of costs and benefits of the proposed system. A methodology should be employed to assure that knowledge and understanding by both users and analysts are attained. AnaJ~~i.s. The present information system should be documented in some detail and the system’s boundaries should be defined [8]. Considerable interaction between the analysts and users will be required to properly perform systems analysis. Logical system design. The user should be heavily involved in developing these statements since they require considerable interaction and feedback. This entire phase might be thought of as an intense educational process for it is here that the analysts and users discuss, criticize and detail specifics of the functional design. The users should help in decisions on data base sizing, record and file specification, basic procedures design, and physical processing alternatives. Without proper education, this phase can provide a weak foundation for physical system design. Physical system design. Upon completion of the logical systems design, a more detailed design phase is undertaken which provides the complete specification of the new system. The detailed systems design serves for requests for vendor quotes. Part of the process involves establishing the procedures for vendor qualification and for software and hardware evaluation methods. Programming andprocedures. During this phase, the information systems applications are constructed to meet the system specifications and the hardware requirements are fulfilled. The emphasis, however, is on applications software. Detailed programming, data bases, files, and records development must take place. Most of the activity will focus on files, file manipulation, and data oriented tasks. It is very important to reemphasize the importance of system documentation to the user. A proper educational approach should help insure that documentation is an integral part. Since the system was designed for and preferably by, the users, they must be educated to understand their interaction with the system.
C. A. Snyder / S)stems A ncr!>‘s~s 249
Test and implementation. The testing of programs, often in a modular fashion, is usually followed by a test of the total system. By testing the entire system, the interrelations and interdependencies of the modules are checked for proper linkages. The interfaces between applications modules may also be verified for compatibility. Proper education means that users, analysts, programmers, and management will be vigilant to assure that system deficiencies are detected, reported, and corrected before implementation. The users should be trained in system operation by this point. The training actually should extend to all users whether they provide input or use the outputs of the system. A properly phased educational program should vastly simplify the communication of expected changes in roles and relationships, and the interactions required. Regardless of the conversion method, an educational approach will help in the process. This fact is especially important in the direct or immediate cutover method since it is heavily dependent on the concentrated efforts of all concerned to make it work. Operation. Additional training of personnel may be required as the system becomes operational and users become more familiar with the system. It is necessary to plan a training program for replacement personnel. This training should include total system objectives, physical system characteristics, company policies, system procedures, and other relevant system facets. In addition, the initial systems evaluation should begin during the operation phase. Because of previous system educational efforts, the users will be far better prepared for this important activity. Evaluation and modification. To objectively assess the system, an evaluation should be conducted. Both users and systems personnel should be actively involved in measuring and monitoring the system’s performance. If the system is operating improperly or providing output that doesn’t support the users, this must be determined and the system subsequently modified. At times the system will have to be adapted to serve new requirement:. For example, if the organization’s strategy changes, it should trigger an assessment of the system’s ability to support users in the new environment. Users require education in order to make the evaluations and to assist analysts and programmers in designing system modifications.
250 Cuse Studres
In addition to modifications aimed at meeting changing needs, management should take advantage of emerging technology. Managers, users, and systems personnel must be continually educated in new technological developments that might provide significant advantages for the organization. The evaluation and modification phase provides continual assessment and adaptation of the system.
4. A Case To illustrate the educational concept in systems analysis and design, an actual case is provided. A large corporation requested assistance in performing analysis and design of an information system for its corporate aviation division. The problem as stated was simply to mechanize the existing manual system. However, from the initial interviews, it became obvious that the aviation department personnel had little knowledge of the computer and applications alternatives. Additionally, it was evident that the system’s functions were far more complex than the personnel realized. Management initially identified three specific objectives: 1. The generation of passenger schedules and manifests for the firm’s regularly scheduled shuttle flights. 2. The provision of schedules for executive flights with nationwide destinations. 3. A means of identifying company employees with reservations on commercial airlines with the same destinations as the company aircraft. Currently two clerks were employed to receive telephone reservation requests and to book passengers. If space was available, the clerk completed the passenger schedule. If all seats were booked, the caller could be placed on a waiting list to stand-by for a possible cancellation. Two shuttle aircraft, each completing a four-segment flight daily, were used; passengers could and did book all possible combinations of segments. Additionally, some reservations were being made up to three months in advance. Although some flights were recurring (monthly board meetings, periodic visits to plants, to company headquarters meetings, etc.), the majority were on a demand basis. In the event of high-priority conflicts, the aviation division chartered supplemental aircraft that also required scheduling. In
scheduling the executive aircraft, its various operating characteristics had to be matched to destination airfields. Departure times had to be calculated based on the meeting time, from airport to meeting site time, flight times (based on type of aircraft, winds, fuel required), times zones, etc. Flight times were manually estimated using a string, map and scale. An attempt was made to identify and request that employees use company aircraft to reduce travel costs and improve company aircraft utilization. A computer tape containing reservations made on commercial aircraft was obtained on a daily basis. Commercial airfares amounted to a quarter of a million dollars per month, but it was not possible to make daily searches of computer printout to identify company passengers. Based upon these initial requirements, a time sharing in-house computer was identified as the suitable hardware alternative and in-house programming was suggested for developing the software. However, a minimum of three dedicated communication !ines was required for scheduling passengers and in-house programming was unavailable. After further investigation a microcomputer based configuration and the use of contract programming were identified as a candidate method. A search of existing commercial microcomputer software was undertaken; this proved rather unproductive, however, several minicomputer software packages were identified. In examining these systems, the management began to realize the full potential of the computer. Their menu of desired applications increased significantly. A decision was made to examine several of the packages in detail and to redefine the scope of the project. Some companies operating similar systems were located and contacted to determine their satisfaction with the systems. User and system personnel inspected two such systems and attended a demonstration of another. Based upon this, the redefinition of scope and benefits was considerable. The management still considered the initial system objectives important, but identified several other equally important applications. 1. Automation of employee personnel records and pilot training records. Pilot hours for training, operations (take-offs and landings) and other licensing requirements were to be stored, and updated.
J. F. Cox, C.A. Sn_yder / Systems Ana(vsis
2. Automation of the scheduled aircraft maintenance by monitoring the number of flight hours, take-offs and landings for various parts, components, and assemblies. 3. Automatic monitoring of fuel prices at various airports and recommendation of locations to purchase fuel and a calculation of optimum fueling at each location. 4. The link-up with a continuous weather monitoring service. 5. Automation of the aircraft parts and inventory system and a link-up with scheduled maintenance to ensure parts availability. 6. A computerized cost accounting system to provide billings to other departments. This was a tedious manual process in the present system. Several other cost effective functions were identified and included in the menu of applications desired. In addition to these applications, the aviation division environment underwent considerable change in this three month period. For example, the company merged with another and the aviation divisions were consolidated (though not geographically). The aircraft operations expanded from three aircraft of two types to seven aircraft of five types with charter flights becoming a daily activity at both locations. Centralized scheduling was to be accomplished. Instead of two fixed shuttles daily, six were scheduled. Pilot training, etc. had to be scheduled and maintained for more than twice the number of employees. Based upon the knowledge gained by the users and system analysts during the various phases a more comprehensive and realistic definition of the problem and alternatives was provided. Some difficult programming was eliminated by purchasing a software package and some unique features that were identified were contracted outside. The end result was a system configuration based upon a comprehensive understanding of the state-of-theart software and segments of the system tailored to the unique requirements of the user.
5. Discussion
The approach taken in this paper is not recommended for all projects. However, it can be very
251
useful where the users are not familiar with computer applications and the area is so highly specialized that the analyst must gain a substantial knowledge of it. This method prevents the systems analyst from “reinventing the wheel,” and provides the users an opportunity to gain insight in their use of computers. Without a thorough knowledge of the function and of existing software, this project would have been designed piecemeal and the initial configuration would soon have been scrapped. Joint examination of the literature on existing commercial software, discussions with employees of companies with similar problems, and attendance at demonstrations conducted by vendors provide both users and the systems analyst with an education on the existing state-of-the-art. A careful evaluation of this information, however, is essential to identify those cost-effective applications the user desires. At this juncture, the team may consider purchasing a software package, purchasing selected modules and programming the rest or programming the entire system. However, if the last alternative is chosen, knowledge of alternatives will help insure an acceptable design. This approach has the major drawback of being time consuming. However, if complete system acceptance and use are a high priority, it is the recommended approach. The educational approach described in this case is applicable in evolving system development concepts as well as the traditional life cycle. The concept of iteration, for example is one in which the educational approach becomes essential for management acceptance (see [7], pp. 182-184). Also in the prototyping approaches currently receiving great attention, there is a requirement for interactive education throughout the process. The educational requirement begins before the prototyping process begins and must permeate each of the iterations until a final system has evolved. Clearly the same sort of intensive educational involvement also exists with the use of nonprocedural languages (so-called fourth generation languages) or user-developers will not adequately cope, with complex environments or the continuing stream of new types of products. As technological developments continue to increase, these educational requirements will be more important.
252 Case Studies
References [l] Awad, E.M. Systems Analysis and Design. Homewood, Illinois: Irwin. 1979. [2] Davis, W.S. S_wtems Analysu and Design: A Structured Approach. Reading. Mass.: Addision-Wesley, 1983. [3] DeMarco, T. Structured Analysis and System Spectfrcation. Englewood Cliffs, N.J.: Prentice-Hall, 1979. [4] Gane, C. & Sarson. T. Structured S_vstems Analysts: Took and Techmques. Englewood Cliffs, N.J.: Prentice-Hall, 1979. [S] Gore, M. & Stubbe, J. Elements of Systems Analysts for Business Data Processing, 2nd. ed. Dubuque, Iowa: Brown. 1979. [6] Keen, J.S. Managing S_vstems Deoelopment. New York: Wiley, 1981. [7] King, D. Current Practtces in Software Development: A Guide to Successful Systems. New York: Yourdon, 1984. [8] Lucas, H.C.. Jr. The Analys:s, Desrgn, and Implementation
[9] [lo]
[II] [12]
[13] [14] [15]
of Information Systems, Zd. ed. New York: McGraw-Hill, 1981. Murdick, R.G. MIS. Concepts and Design. Englewood Cliffs, N.J.: Prentice-Hall, 1980. Roberts, B.J. “Education and Training Programs to Support MRP Implementations.” Production and Inuentocy Management, Vol. 23. No. 2. 1982, 45-64. Senn. J.A. Information Systems m Management, 2nd ed. Belmont, Cahf.: Wadsworth. 1982. Snyder, C.A. & Cox, J.F. “A Dynamic Systems Development Life Cycle Approach: A Project Management Information System.” Journal of Management Information S_vsterns, Vol. 2, No. 1 Summer, 1985. 58-71. Tapscott, D. Office Automation: A User-Drwen Method. New York: Plenum, 1982. Thierauf, R.J. & Reynolds, G.W. Systems Am&is and Design: A Case Study Approach. Columbus: Merrill, 1980. Wetherbe, J.C. S_ystems Analysis for Computer- Based Information Systems. St. Paul: West, 1979.