Computer information - Part 2
Introduction On February 5, 2007, the Management Information System Division (MISD) of Riordian Manufacturing Phone Company will implement a company-wide integrated management information system providing decision support services to all major functional units of the company starting from the Human Resource Management department’s personnel databases linking its data with the Finance, Purchasing, Logistics, Engineering, and Manufacturing organizations. The data of the Marketing & Sales department are linked to Engineering and Manufacturing. The Manufacturing organization is likewise linked with Purchasing, Logistics, and Finance organizations. The MISD is mandated to conduct company-wide orientation and training on the new integrated information system designed and developed for the company.
More Essay Examples on Computer Rubric
Purpose and scope The purpose of this research paper is to draw up a plan for computer information system implementation and maintenance for Riordian Manufacturing Phone Company. The third topic covered by this paper is prototyping—a “working system to explore implementation or processing alternatives and evaluate the results” (Award, 1998)—aimed at providing guidelines and simplified approach to fine-tuning solutions for system development to be followed by system analysts, programmers, database administrators, and users, as necessary.
System overview Figure 1 illustrates the interface of the major functional units of Riordian Manufacturing Phone Company. At the core of the system is the IT infrastructure (not shown) playing its critical role in the background. The infrastructure includes the computers, the networks, softwares, applications and customized programs developed for specific internal customers.
Figure 1. Interface of major functional units of Riordian Manufacturing Phone Company
System Implementation The following system implementation plan has been reviewed by the MISD and senior management for implementation.
· Review test documentation and the implementation plan
· Copy the files from one hardware to another
· Incorporate audit control procedures for file integrity
· Initiate a processing routine—(a) parallel processing (b) pilot processing (c) direct conversion
· Log the results for reference
· Plan for postimplementation
· The goal of file conversation is to prepare files that are compatible with the new system configuration and format. Copying the ‘old’ files intact is a primary concern during conversion.
· File conversion is more than dealing with new files. Follow these pointers: (a) role of the user—the user must ultimately assume responsibility for it (b) the file conversion procedure—the first step in conversion is to decide on the information that will load that installation (c) be selective in the conversion—converting everything just because it is in the file does not make sense and can be dangerous.
· A summary of the conversation guidelines is: secure user commitment; decide on the information that will load the system; discourage major changes; be selective in the conversion.
· A major component of the system implementation is training the users on the new system.
· The level and duration of the training depends on the user’s knowledge level and the system’s requirements.
· The level of training should consider these: (a) the user’s knowledge of computers (b) the complexity of the system and how well it accommodates the average user (c) the trainer’s skill (d) the environment in which training is carried out.
· Successful user training relies on: (a) a well-written and highly illustrated user manual (b) availability of graphics, templates, and other tools for quick reference or as teaching aids (c) HELP screens to guide in correcting syntactic errors (d) job aids and schematics to diagnose problems.
Combating resistance to change
· Resistance is displayed in these personal reactions: (a) projection—hostility toward peers (b) avoidance—withdrawal from the scene (calling it sick) (c) aggression—sabotage of the system, because they are unsure of its operation or use.
Copy right. Adopted from Awad, 1988, pp. 517-522.
System Maintenance Since the system has to be implemented yet, the following critical system maintenance review questions are necessary and are dedicated to the MISD team of the company. They must be answered even before the implementation of the new integrated information system.
How have information systems changed the accuracy and timeliness of information?
Has the information system caused organizational changes? How constructive have they been?
Has the information system changed the attitudes of the end users affected by the system?
How has the information system affected the number of users that access data from the database?
How has the new system changed the cost of operating the business?
In what way has the new system affected the relationships among end users in the organization?
How does the information from the new system justify the cost of investment?
How has the new system changed the ay various operations are performed?
Copy right. Adopted from Awad, 1988, pp. 522-523.
Software maintenance “accounts for up to 80 percent of total system development. Most systems require it. Programmers detest it. It is boring because it deals with the ongoing features of the system, not the discrete begin-end orientation of a project. As with the system, however, maintenance is a necessity,” writes Awad (1988, p. 523). Awad likewise mentions of two aspects of software maintenance—these are: (a) corrective in which programmers work on problems that were in the initial design, and (b) perfective which deals with changes that users require as a result of their experience with the system.
“A successful program maintenance is a reflection of the programmer’s skills and motivation. Because maintenance demands more training than any other programming activity, the MIS department must reward maintenance engineers in line with their contributions,” suggests Awad (1988, p. 23).
Prototyping In most of information system post-implementation (and even during the design phase), the biggest problem besetting system analysts and programmers is a request for “change” in the system—be it apparently small or a major one. “A completely different problem,” writes Gilb and Finzi (1988) “is that a change involves updating of a number of documents—which is often a time-water and an unpleasant job which doesn’t always get done” (p. 276). One approach developed and adopted by professionals in the computing industry is what is known as the “prototyping.” Prototyping “differs from evolutionary designing in one significant way. A prototype is often considered to be a model of a proposed system. It is built to illustrate the feasibility of the new system and then virtually thrown away,” writes Hawryszkiewycz (1991, p. 324). “This working environment is very fruitful when solving problems which are not perfectly defined, and where all requirements can not be formally specified,” notes Gilb and Finzi (1988, p. 276). Oliver and Langord (1987), on the other hand, write, “The computing field is starting to recognize that organizations inevitably change. Developments such as prototyping, decision support systems, and fourth-generation languages, as well as the burgeoning applications of micro computers, are making it easier for organizations to adapt rapidly to changing circumstances” (p. 120).
1. Awad, E. M. (1988). Management Information Systems Concepts, Structure, and Applications. Menlo Park, CA: The Benjamin/Cummings Publishing Company, Inc.
2. Gilb, T., & Finzi, S. (1988). Principles of Software Engineering Management. Menlo Park, CA: Addison Wesley Publishing Company.
3. Hawryszkiewycz, I. T. (1991). Introduction to Systems Analysis and Design. New York, NY: Printice Hall.
4. Oliver, I., & Langford, H. (1987). Myths of Demons and Users: Evidence and Analysis of Negative Perceptions of Users. In Information Analysis Selected Readings (pp. 113-123). Galliers, R. (Ed.) Menlo Park, CA: Addison-Wesley Publishing Company.