An Information System: System Analysis, Design Methods, System Building Blocks

A company has many functional departments (such as Finance, Human Resources, etc.) Explain or describe the process that should be taken to develop an automated information system and or software

An information system designing process is a key stage to the implementation of an information system in an organization. The importance of design is well recognized in the IS literature (Glass, 1999 ). Benbasat and Zmud (1999, p. 5) argue that the relevance of IS research is directly related to its applicability in design, stating that the implications of empirical IS research should be “implementable … synthesize an existing body of research … [or] stimulate critical thinking” among IS practitioners.”

A system design is important and affects all functional areas in an organization because it primarily aims at the integration and coordination of all functionalities. In describing the procedure for designing systems in an organization it is important to first identify the underlying assumptions that are made by the management who are responsible for such implementation. The assumptions are as follows:

1. Most managers do not have adequate relevant information which is a deficiency under which they operate. Managers suffer from an overabundance of irrelevant information (Ackoff, 1967).
2. This reduces the flow of information that the manager needs for such an implementation process.
3. If the manager has the information he needs his decision-making will improve. There arises the problem of the need for a highly customized system and the delivery of a generic system by designers (Hong & Kim, 2002).
4. Better communication between managers improves organizational performance. Ackoff (1967) believes that it is not a necessary prerequisite and he doubts if this seldom occurs.
5. A manager does not have to know how the information system works. All he needs to know is how to use it. Perceived shortcomings of IT management include a failure to demonstrate business benefit, a lack of business focus, and a failure to communicate in business terms (Bostrom & Heinen, 1977) while the general management side may fail to understand IT issues or relevance (Chang, 2006).

These are the assumptions that are usually taken by system designers which often lead to erroneous decisions (Ackoff, 1967; Chang, 2006). A process for designing an information system in an organization has been presented by Ackoff (1967).

The first step as described by Ackoff (1967) is to analyze the design system. All the important management decisions required by the organization under study should be identified and the relationships between them should be determined in a flow chart. In other words, it is important to identify the organizational critical success factors (CSF) (Shank, Boynton, & Zmud, 1985; Hong & Kim, 2002). CSFs are not necessarily the decisions that are made.

The importance of this analysis is that it reveals decisions that are being made that are basic and occur by default. To a great extent, there are interdependencies in these decisions which are being made independently (Ackoff, 1967). As because these decisions have to be used continuously and repetitively, these decision flow charts, according to Ackoff are:

1. Self-justifying;
2. Suggest changes in managerial responsibility, organizational structure, and measure of performance which can correct the deficiencies mentioned above.

Prior analysis of management information system (MIS) which has been implemented is important. MIS implemented without prior analysis of the managerial activities prevent the system designers from developing a sufficiently broad definition of the purpose and have resulted in a generally inefficient allocation of resources (Gorry & Morton, 1971).

The second step in the decision-making process is to analyze the information requirements for the implementation of the IS. The decision can be classified into three types:

1. Decisions that have pre-existing models can be incorporated into an information system in totality.
2. Decisions for which adequate models can be constructed, but from which optimal solutions can be extracted.
3. Decisions for which adequate models cannot be constructed.

All these decisions along with their predicted outcomes should become essential inputs in management control systems.

The third step is to identify the overlapping decisions in organizations. These decisions have to be grouped together as a single task. This will reduce the information a manager requires to do his job and is likely to increase his understanding of the system.

The fourth step involves designing of collection, storing, retrieving, and treating of information. In other words, it is necessary to design information processing.

The system that is designed will be deficient in many ways. The fifth step is to necessarily identify the areas where these deficiencies may lie/arise so that adequate corrections and/or improvement can be done. Hence the system, thus, design should be flexible and adequate.

Another approach for designing of information system is the socio-technical theory of implementation (Bostrom & Heinen, 1977). They described three phases in the designing process:

• Phase I: Strategic Decision Process The purpose of this phase is to make the goals and responsibilities pertaining to the project explicit. The issues related to users’ participation and responsibility can have to deal with in this stage.
• Phase II: Socio-technical system design process In this stage the analysis of the problems for which the system needs to be designed has to be analyzed and joint consideration of the technical, as well as social aspects of systems requirements, has to be dealt with.
• Phase III: Ongoing Management Process The third phase is the action research process. In this phase, constant monitoring of the new system is done in order to judge its effectiveness.

A recent addition in the design science of IS has evolved (Hevner, March, Park, & Ram, 2004). Two other design necessities for IS implementation is:

1. Integration of different systems serving different levels and functions in firms. Though this is a costly process and integration is difficult this has to be attained in order to free the flow of information.
2. Enlarging the scope of management thinking so that they can take decisions beyond their scope and area of expertise.

Considering the critical success factors of systems implementation (specifically for ERP) developed by Holland and Light (1999) is shown in figure 1.

The authors asked the manager to ask himself or herself the following questions while designing the process for implementation of ERP systems are as follows:

• “What is the status of the company’s legacy systems and how will they affect the transition to ERP and common business processes?
• Is there a clear business vision with quantifiable objectives that can be achieved and delivered through the ERP project?
• Would a fully functional system or a skeleton one be more suitable to the organization? What are the implications of both approaches on the speed of implementation and service to our customers?
• Does the senior management understand the magnitude and pace of organization and technical cost five times more than the original estimates change that is implicit in large-scale ERP projects? Are they prepared to allocate sufficient resources?
• Do we have clear project schedules and plans?” (Holland & Light, 1999, p. 35)

An enterprise software package has recently been installed. Describe in detail the steps that should be taken to solve the problems of this new installation? What should be done to overcome the human and personnel issues?

After the basic design of the information, the system is made and an implementation procedure has been planned, it is important to ascertain the problems that arise due to the implementation of such systems and what can be done in order to avoid these problems. In order to ascertain the problems pertaining to an enterprise software package like ERP (Enterprise Resource Planning) software, it is imperative to appreciate what they do.

As businesses become more competitive and face the challenge of increasing competition, expanding markets, and rising customer expectations, the corporate world moves to a more collaborative model of business. In the face of such stiff competition, companies must improve their systems and procedures. Companies must also increasingly share with their suppliers, distributors, and customers the critical in-house information they once aggressively protected (Loizos, 1999).

And functions within the company must upgrade their capability to generate and communicate timely and accurate information. To accomplish these objectives, companies are increasingly turning to ERP systems. ERP provides two major benefits that do not exist in non-integrated departmental systems:

1. a unified enterprise view of the business that encompasses all functions and departments; and
2. an enterprise database where all business transactions are entered, recorded, processed, monitored, and reported.

This unified view increases the requirement for, and the extent of, interdepartmental cooperation and coordination. But it enables companies to achieve their objectives of increased communication and responsiveness to all stakeholders (Umble, Haft, & Umble, 2003; Dillon, 1999).

The key problems and solutions as identified in ERP diffusion are:

• Failure of the ERP implementation process is a primary problem in the implementation process of the system (Hong & Kim, 2002). The reasons behind such imminent failures are the invisibility of the implementation process (Griffith, Zammuto, & Aiman-Smith, 1999).
• Another critical issue withers implementation is a mutual adaptation between IT and user environment (Volkoff, 1999). Such a mutual adaptation process brings the organization’s existing operating processes and packaged software’s embedded functionality into alignment through a combination of software configuration and organizational change (Volkoff, 1999). But there exist conflicting views about which type of adaption, package or organizational adaptation, is more desirable.
• Since ERP implementation is process-based rather than function-based, it requires disruptive organizational change (Hammer & Stantton, 1999; Volkoff, 1999). This problem can be solved by handling the ERP implementation process as a wide-ranging organizational change initiative rather than a software installation effort (Hammer & Stantton, 1999). This requires a change in the organization’s socio-technical system, which is intermingled with technology, task, people, structure, and culture (Laudon & Laudon, 2005).
• Another problem that arises with ERP implementation is organizational resistance to change which has been identified as a critical success factor for ERP implementation (Hong & Kim, 2002).

Once these problems are identified, it becomes important to identify the critical success factors for ERP implementation so that these imminent problems can be solved. There is extensive research into identifying the success factors for ERP implementation, and the most prominent ones are listed below:

• A clear understanding of strategic goals: ERP implementations require that key people throughout the organization create a clear, compelling vision of how the company should operate in order to satisfy customers, empower employees, and facilitate suppliers for the next three to five years. There must also be clear definitions of goals, expectations, and deliverables. Finally, the organization must carefully de.ne why the ERP system is being implemented and what critical business needs the system will address (Umble, Haft, & Umble, 2003).
• Commitment by top management: Successful implementations require strong leadership, commitment, and participation by top management. Since executive-level input is critical when analyzing and rethinking existing business processes, the implementation project should have an executive management planning committee that is committed to enterprise integration, understands ERP, fully supports the costs, demands payback, and champions the project. Moreover, the project should be spearheaded by a highly-respected, executive-level project champion (Hong & Kim, 2002).
• Excellent project management: Successful ERP implementation requires that the organization engage in excellent project management. This includes a clear definition of objectives, the development of both a work plan and a resource plan, and careful tracking of project progress (Umble, Haft, & Umble, 2003). And the project plan should establish aggressive, but achievable, schedules that instill and maintain a sense of urgency (Laughlin, 1999). A clear definition of project objectives and a clear plan will help the organization avoid the all-too-common ‘‘scope creep’’ which can strain the ERP budget, jeopardize project progress, and complicate the implementation (Laughlin, 1999). The project scope must be clearly defined at the outset of the project and should identify the modules selected for implementation as well as the affected business processes. If management decides to implement a standardized ERP package without major modifications, this will minimize the need to customize the basic ERP code. This, in turn, will reduce project complexity and help keep the implementation on schedule (Umble, Haft, & Umble, 2003).
• Organizational change management: The existing organizational structure and processes found in most companies are not compatible with the structure, tools, and types of information provided by ERP systems. Even the most flexible ERP system imposes its own logic on a company’s strategy, organization, and culture. Thus, implementing an ERP system may force the reengineering of key business processes and/or developing new business processes to support the organization’s goals (Minahan, 1998). And redesigned processes require the corresponding realignment in organizational control to sustain the effectiveness of the reengineering efforts. This realignment typically impacts most functional areas and many social systems within the organization. The resulting changes may significantly a.ect organizational structures, policies, processes, and employees. Unfortunately, many chief executives view ERP as simply a software system and the implementation of ERP as primarily a technological challenge. They do not understand that ERP may fundamentally change the way in which the organization operates. This is one of the problematic issues facing current ERP systems. The ultimate goal should be to improve the business––not to implement software. The implementation should be business-driven and directed by business requirements and not the IT department (Minahan, 1998). Clearly, ERP implementations may trigger profound changes in corporate culture. If people are not properly prepared for the imminent changes, then denial, resistance, and chaos will be predictable consequences of the changes created by the implementation. However, if proper change management techniques are utilized, the company should be prepared to embrace the opportunities provided by the new ERP system––and ERP will make available more information and make attainable more improvements than at first seemed possible. The organization must be flexible enough to take full advantage of these opportunities (Hong & Kim, 2002).
• A great implementation team: ERP implementation teams should be composed of top-notch people who are chosen for their skills, past accomplishments, reputation, and flexibility. These people should be entrusted with critical decision-making responsibilities (Griffith, Zammuto, & Aiman-Smith, 1999). Management should constantly communicate with the team, but should also enable empowered, rapid decision-making (Minahan, 1998). The implementation team is important because it is responsible for creating the initial, detailed project plan or overall schedule for the entire project, assigning responsibilities for various activities, and determining due dates. The team also makes sure that all necessary resources will be available as needed.
• Data accuracy: Data accuracy is absolutely required for an ERP system to function properly. Because of the integrated nature of ERP, if someone enters the wrong data, the mistake can have a negative domino effect throughout the entire enterprise. Therefore, educating users on the importance of data accuracy and correct data entry procedures should be a top priority in an ERP implementation (Volkoff, 1999; Umble, Haft, & Umble, 2003).
• Extensive education and training: Education/training is probably the most widely recognized critical success factor because user understanding and buy-in are essential. ERP implementation requires a critical mass of knowledge to enable people to solve problems within the framework of the system. If the employees do not understand how a system works, they will invent their own processes using those parts of the system they are able to manipulate (Hammer & Stantton, 1999).

Companies constantly struggle to improve performance, increase profits, and efficiency. Explain in detail the role of the systems analyst in the process of achieving these company goals. How does the information systems architecture help or hinder this process?

System analysts confirm that the designed system will meet requirements. Typical analyses include system weight, power, throughput, and output predictions for hardware systems, and memory usage, interface traffic, and response times for software systems. Usually, the more complex parts of the system need to be modeled in order to demonstrate that they will work properly and interface properly with the external world. Modeling also helps the systems engineer and others understand how the system will be operated. Most systems engineers do some modeling, with the amount increasing with the availability of cheap and powerful simulation tools. The extent of analysis varies with the type of program: the more complex and riskier programs need more analysis.

The primary function of a system analyst thus comes in the system analysis workflow. The system analyst has the primary role in this workflow. The system analyst should have problem domain expertise and an understanding of the problem and should be able to describe a process that he or she believes will solve the problem. Active involvement from various project stakeholders is required and all relevant stakeholder requests should be considered.

A system analyst in a development team may facilitate a session to help the initial stakeholders describe the problem they want to be solved. It’s important to gain agreement on a concise statement of the perceived problem. Key elements of a problem statement are shown in the following table:

The problem statement succinctly explains the purpose of the project. Problem analysis stimulates further investigation into all stakeholder requests and the initial business case, including compelling benefits and roughly estimated costs. In parallel with defining problem statements, the team should also compile a glossary by keeping track of commonly used terms and agreeing on their definitions.

Information system architecture (ISA) is a part of a vaster field of architectures and models relevant to the organization. Considering the architectural scope and level, one can distinguish the following architectures:

• Enterprise Architecture: Enterprise Architecture is a group of models defined for getting a coherent and comprehensible picture of the enterprise (Tissot & Crump, 1998). The models define different “perspectives or viewpoints from which the company is considered, focusing on some aspects and ignoring others in order to reduce complexity” (Vernadat, 1996). Thus, a model of the company can contain several activities, processes, organization, information, and behavior diagrams of the company.
• Information System Architecture (ISA): ISA addresses the representation of the IS components structure, its relationships, principles, and directives (Garlan, 1995) with the main purpose of supporting business (Maes, Rijsenbrij, & Goedv, 2000).
• Software Architecture (SA): SA’s main study area is on how programs or application components are internally built.

Quoting IEEE Architecture Working Group (1998), the ISA level should be high. Thus, ISA is distinguished from software representation and analysis methods (as E-R diagrams, DFD), presenting an abstraction of internal system details and supporting organization business processes (IEEE Architecture Working Group, 1998).

ISA usually distinguish three aspects, defining three “sub-architectures”:

• Informational Architecture, or Data Architecture, represents the main data types that support business
• Application Architecture defines applications needed for data management and business support.
• Technological Architecture represents the main technologies used in application implementation and the infrastructures that provide an environment for IS deployment – as network, communication, distributed computation, etc.

ISA description is a key step in ensuring that IT provides access to data when, where, and how is required at the business level. However, having an ISA does not ensure these benefits just by existing; the representation of the information systems and its dependencies to business is a necessary, but not sufficient, step towards addressing key problems as the IS integrity and flexibility, IS ROI, IS, and business alignment, among others.

Works Cited

Ackoff, R. L. (1967). Management Information Systems. Management Science vol. 14, no. 4 , 148-156.

Benbasat, I., & Zmud, R. (1999). Empirical Research in Information Systems: The Practice of Relevance. MIS Quarterly vol. 23, no.1, 3-16.

Bostrom, R. P., & Heinen, J. S. (1977). MIS problems and failures: A socio-technical perspective Part II: The Application of socio-technical theory. MIS Quaterly, 11-29.

Chang, H. H. (2006). Technical and management perceptions of enterprise information system importance, implementation and benefits. Information Systems Journal 16 , 263-292.

Dillon, C. (1999). Stretching toward enterprise flexibility with ERP. APICS––The Performance Advantage, 38-43.

Elam, J., & Marakas, G. (1998). Semantic Structuring in Analyst Acquisition and Representation of Facts in Requirements Analysis. Information Systems Research vol 9, no. 1 , 37-63.

Garlan, D. e. (1995). Architectural Mismatch (Why It’s Hard to Build Systems Out of Existing Parts). Proceedings 17th International Conference on Software Engineering, (pp. 170-185). Seatle, WA.

Glass, R. (1999). On Design. IEEE Software (16:2), 103-104.

Gorry, G. A., & Morton, M. S. (1971). A Framework for management information system. Sloan management Review (Fall) , 65-80.

Griffith, T., Zammuto, R., & Aiman-Smith, L. (1999). Why new technologies fail? Industrial Management , 29-34.

Hammer, M., & Stantton, S. (1999). How processes enterprise really work? Harvard Business Review , 108-119.

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. MIS Quaterly , 2-54.

Holland, C. P., & Light, B. (1999). A Critical Success model for ERP Implementation. IEEE Software, 30-37.

Hong, K.-K., & Kim, Y.-G. (2002). The Critical Success Factors for ERP implementation: an organizational fit perspective. Information and Management 40 , 25-40.

IEEE Architecture Working Group. (1998). Recommended Practice for Architecture Description. IEEE.

Laudon, K. C., & Laudon, J. P. (2005). Management Information Systems. NJ: Prentice Hall.

Laughlin, S. (1999). An ERP game plan. Journal of Business Strategy, 32–37.

Loizos, C. (1999). ERP: Is it the ultimate software solution. Industry Week 7 , 33.

Maes, R., Rijsenbrij, O., & Goedv, H. (2000). Redefining Business – IT Alignment Through a Unified Framework. Web.

Minahan, T. (1998). Enterprise resource planning. Purchasing 16 , 112–117.

Shank, M., Boynton, A. C., & Zmud, R. W. (1985). Critical Success Factor Analysis as a Methodology of MIS Planning. MIS Quarterly, 121-31.

Tissot, F., & Crump, W. (1998). An Integrated Enterprise Modeling Environment, P. Bernus, K. Mertins, G. Schmidt (Eds.), Handbook on Architectures of Information Systems. Springer , 59-79.

Umble, E. J., Haft, R. R., & Umble, M. M. (2003). Enterprise resource planning: Implementation procedures and critical success factors. European Journal of Operational Research 146 , 241–257.

Vernadat, F. (1996). Enterprise Modeling and Integration. London, : Chapman & Hall.

Volkoff, O. (1999). Enterprise System Implementation: a process of individual metamorphosis. American Conference on Information Systems.