THE IMPORTANCE OF CHANGE MANAGEMENT IN INFORMATION SYSTEMS SUCCESS AND FAILURE
Nội dung chính
- Which of the following statements best describes the effect that project structure?
- Which of the following best describes the relationship between system implementation and user involvement and management support?
- Which of the following is an example of using an external integration tool?
- Which of the following is a tangible benefit of an information system?
Benefits from information technology investments are reduced if firms do not consider the costs of organizational change associated with a new system or make these changes effectively (Irani and Love 2000�2001; Ryan and Harrison, 2000). The introduction or alteration of an information system has a powerful behavioral and organizational impact. It transforms how various individuals and groups perform and interact. Changes in the way that information is defined, accessed, and used to manage the organization�s resources often lead to new distributions of authority and power. This internal organizational change breeds resistance and opposition and can lead to the demise of an otherwise good system.
A very large percentage of information systems fail to deliver benefits or to solve the problems for which they were intended because the process of organizational change surrounding system building was not properly addressed. Successful system building requires careful change management.
Information Systems Problem Areas
The problems causing information system failure fall into multiple categories, as illustrated in Figure 15-4. The major problem areas are design, data, cost, and operations.
FIGURE 15-4 Information systems problem areas
Problems with an information system�s
design, data, cost, or operations can be evidence of a system failure.
The actual design of the system may fail to capture essential business requirements or improve organizational performance. Information may not be provided quickly enough to be helpful; it may be in a format that is impossible to digest and use; or it may represent the wrong pieces of data.
The way in which nontechnical business users must interact with the system may be excessively complicated and discouraging. A system may be designed with a poor user interface. The user interface is the part of the system with which end users interact. For example, an input form or an online data entry screen may be so poorly arranged that no one wants to submit data. The procedures to request online information retrieval may be so unintelligible that users are too frustrated to make requests or the requested data may be displayed in a format that is too difficult to comprehend (Spier and Morris, 2003).
Web sites may discourage visitors from exploring further if the Web pages are cluttered and poorly arranged, if users cannot easily find the information they are seeking, or if it takes too long to access and display the Web page on the user�s computer (Palmer, 2002). This is what happened to Quixtar.com, a major e-commerce sales channel for the Amway Corporation. This site is considered highly successful, but it is not providing as much value as it could because of poor design. The Window on Organizations explains how Quixtar.com�s design affected its ability to convert Web site visitors to buyers and how Quixtar fixed these problems.
An information system can be deemed a failure if its design is not compatible with the structure, culture, and goals of the organization as a whole. Historically, information systems design has been preoccupied with technical issues at the expense of organizational concerns. The result has often been information systems that are technically excellent but incompatible with their organization�s structure, culture, and goals. Without a close organizational fit, such systems create tensions, instability, and conflict.
DATA
The data in the system may have a high level of inaccuracy or inconsistency. The information in certain fields may be erroneous or ambiguous, or it may not be organized properly for business purposes. Information required for a specific business function may be inaccessible because the data are incomplete.
COST
Some systems operate quite smoothly, but their costs to implement and run on a production basis may be way over budget. Other system projects may be too costly to complete. In both cases, the excessive expenditures cannot be justified by the demonstrated business value of the information they provide.
This registration form pops up when a visitor to the Quixtar.com Web site places his or her first item in the site�s electronic shopping cart, interrupting the
shopping process. This feature could discourage some potential buyers from completing their purchases.
OPERATIONS
The system does not run well. Information is not provided in a timely and efficient manner because the computer operations that handle information processing break down. Jobs that abort too often lead to excessive reruns and delayed or missed schedules for delivery of information. An online system may be operationally inadequate because the response time is too long.
Some of these problems can be attributed to technical features of information systems, but most stem from organizational factors (Keil, Cule, Lyytinen, and Schmidt, 1998). System builders need to understand these organizational issues and learn how to manage the change associated with a new information system.
WHAT�S WRONG WITH QUIXTAR.COM?
Amway is the largest multilevel marketing organization in the world, selling billions of dollars a year of products such as soap, water purifiers, vitamins, and cosmetics. Amway runs its business through a network of independent business owners, or IBOs. The IBOs sell Amway products to retail customers, recruit other sellers, and are paid a percentage of sales booked by newcomers.
Amway no longer sells face-to-face in the United States. In September 1999, it set up a Web site called Quixtar.com to enable its IBOs to sell over the Web to new IBOs or retail customers. IBOs earn income on sales to other IBOs, Members, and Clients they register at the site. IBOs participate in Quixtar�s compensation plan, while Members pay an annual fee to order products at special pricing. Clients purchase products at full retail price. Quixtar�s brands include Nutrilife nutritional supplements, Atristry skin care and cosmetics, XS Sports Nutrition, and eSpring water purifiers. Through its Store for More, Quixtar also offers products from leading brands such as Maytag, Adidas, and Calvin Klein. The site handles 2.5 million registered users and 930,000 unique users, reflecting the company�s multiple levels of membership.
Sales at Quixtar.com have surpassed $1 billion during each of the last two years, making Quixtar one of the top online retailers in the United States. In June 2004, Internet Retailer ranked Quixtar.com first in its online Drug/Health and Beauty category and twelfth among all e-commerce sites in its annual Top 300 Guide to the Web.
Quixtar.com works hard at making its Web site available and reliable. It takes in about $3 million in sales each day, spiking to $10 million on the last day of each month. It uses RealiTea software from TeafLeaf Technology in San Francisco to monitor the activities of its visitors to help it pinpoint application failures or bottlenecks. RealiTea tracks every click and keystroke, and these data are captured in a 2-terabyte database that can store 10 days� worth of user activity. When a problem occurs, Quixtar staff can pinpoint the error by accessing the database to play back specified user sessions. The TeaLeaf replay highlights the visitor�s session history to help Quixtar staff see every field a customer typed in or link that a customer clicked.
But something is not quite right. Quixtar�s Web site is not as good as it could be because it has usability problems. Mark Hurst, president of Creative Good, an Internet consultancy, estimates that fixing Quixtar�s design flaws could produce another $100 million annually.
Both IBOs and individual shoppers who are not part of the Quixtar network can use the site to place orders. Veteran IBOs were able to muddle through because they�re very familiar with the Quixtar lingo and procedures. But most retail shoppers backed away, creating losses because Quixtar wants very much to sell to the general public and the Web site�s confusing interface thwarts sales. Let�s see how.
Claudia Case, a usability consultant at Keynote Systems, a Web measurement company, found that Quixtar.com lacked a consistent look and was organized to reflect how Quixtar works rather than how customers shop. Quixtar itself encountered problems with its checkout procedure. In the fall of 2003, the site automatically filled out an incorrect shipping address for 14 online orders without customers� knowledge. Quixtar called the affected customers, and its technicians then fixed the software problem.
Keynote Systems found several design flaws in Quixtar.com�s purchasing process that prevented the system from converting as many visitors as it could to buyers of its products. For instance, every time a customer puts his or her first item in a shopping cart, a registration form pops up, interrupting the shopping process before it is completed. The form does not acknowledge that the shopper has chosen any items and could annoy a visitor before that person has committed to spending money at that site. If a user makes a mistake while filling out this or other forms, there is no easy way to correct such errors during the checkout process. These problems could be avoided if Quixtar.com asked for registration or identification information when the customer was ready to pay and if it introduced a process to correct forms on the spot.
Quixtar.com assigns each customer a 9-to-11 digit account number that is required for shopping at the site. The account number is not meaningful to the customer and obviously is difficult to remember. Customers could only change their passwords by themselves but not their account numbers themselves. Hard-to-remember account numbers could slow down or even deter customers from shopping. Quixtar could remedy the situation by providing a capability for customers to personalize their passwords.
Quixtar.com�s Order History page contains confusing language. Customers who want to view past and pending orders have to decipher unclear terminology. For example, the page contains a �hint� to the customer to �Select a display option. Your current selection is all orders in the current month.� Customers would have to work to understand the meaning. If a drop-down bar was labeled �View open and past orders,� a hint would not be necessary.
Sources: Kim S. Nash, �Cleaning Up,� Baseline Magazine, June 2004; www.quixtar.com, accessed July 14, 2004; RSA Security, �Quixtar Accelerates Business with Identity and Access Management Solution from RSA Security,� PR Newswire, December 6, 2004; and www.tealeaf.com, accessed July 14, 2004.
To Think About: How does the design of Quixtar.com�s Web site affect the way it runs its business? Evaluate the features that both enhance and impede its performance.
Change Management and the Concept of Implementation
To manage the organizational change surrounding the introduction of a new information system effectively, you must examine the process of implementation. Implementation refers to all organizational activities working toward the adoption, management, and routinization of an innovation, such as a new information system. In the implementation process, the systems analyst is a change agent. The analyst not only develops technical solutions but also redefines the configurations, interactions, job activities, and power relationships of various organizational groups. The analyst is the catalyst for the entire change process and is responsible for ensuring that all parties involved accept the changes created by a new system. The change agent communicates with users, mediates between competing interest groups, and ensures that the organizational adjustment to such changes is complete.
One model of the implementation process is the Kolb/Frohman model of organizational change. This model divides the process of organizational change into a seven-stage relationship between an organizational consultant and his or her client. (The consultant corresponds to the information system designer, and the client to the user.) The success of the change effort is determined by how well the consultant and client deal with the key issues at each stage (Kolb and Frohman, 1970). Other models of implementation describe the relationship as one among designers, clients, and decision makers, who are responsible for managing the implementation effort to bridge the gap between design and utilization (Swanson, 1988).
Causes of Implementation Success and Failure
Implementation outcome can largely be determined by the following factors:
- The role of users in the implementation process
- The degree of management support for and commitment to the implementation effort
- The level of complexity and risk of the implementation project
- The quality of management of the implementation process
FIGURE 15-5 Information systems success or failure factors
The implementation outcome can be largely determined by the role of users, the degree of management support, the level of risk and complexity of the implementation project,
and the quality of management of the implementation process. Evidence of the information system�s success or failure can be found in the areas of design, cost, operations, and data.
User involvement in the design and operation of information systems has several positive results. First, if users are heavily involved in systems design, they have more opportunities to mold the system according to their priorities and business requirements, and more opportunities to control the outcome. Second, they are more likely to react positively to the completed system because they have been active participants in the change process. Incorporating user knowledge and expertise leads to better solutions.
Thanks to widespread use of the Internet and fourth-generation tools, today�s users are assuming more of a leadership role in articulating the adoption, development, and implementation of information technology innovations (Kettinger and Lee, 2002). However, users often take a very narrow and limited view of the problem to be solved and may overlook important technology issues or alternative information systems solutions. The skills and vision of professional systems designers are still required much the same way that the services of an architect are required when building a new house (Markus and Keil, 1994).
The relationship between consultant and client has traditionally been a problem area for information systems implementation efforts. Users and information systems specialists tend to have different backgrounds, interests, and priorities. This is referred to as the user-designer communications gap. These differences lead to divergent organizational loyalties, approaches to problem solving, and vocabularies.
Information systems specialists, for example, often have a highly technical, or machine, orientation to problem solving. They look for elegant and sophisticated technical solutions in which hardware and software efficiency is optimized at the expense of ease of use or organizational effectiveness. Users prefer systems that are oriented toward solving business problems or facilitating organizational tasks. Often the orientations of both groups are so at odds that they appear to speak in different tongues.
These differences are illustrated in Table 15-3, which depicts the typical concerns of end users and technical specialists (information systems designers) regarding the development of a new information system. Communication problems between end users and designers are a major reason why user requirements are not properly incorporated into information systems and why users are driven out of the implementation process.
TABLE 15-3 The User-Designer Communications Gap
Systems development projects run a very high risk of failure when there is a pronounced gap between users and technicians and when these groups continue to pursue different goals. Under such conditions, users are often driven out of the implementation process. Because they cannot comprehend what the technicians are saying, users conclude that the entire project is best left in the hands of the information specialists alone. With so many implementation efforts guided by purely technical considerations, it is no wonder that many systems fail to serve organizational needs.
MANAGEMENT SUPPORT AND COMMITMENT
If an information systems project has the backing and commitment of management at various levels, it is more likely to be perceived positively by both users and the technical information services staff. Both groups will believe that their participation in the development process will receive higher-level attention and priority. They will be recognized and rewarded for the time and effort they devote to implementation. Management backing also ensures that a systems project receives sufficient funding and resources to be successful. Furthermore, to be enforced effectively, all the changes in work habits and procedures and any organizational realignments associated with a new system depend on management backing. If a manager considers a new system a priority, the system will more likely be treated that way by his or her subordinates (Doll 1985; Ein-Dor and Segev, 1978).
LEVEL OF COMPLEXITY AND RISK
Systems differ dramatically in their size, scope, level of complexity, and organizational and technical components. Some systems development projects are more likely to fail or suffer delays because they carry a much higher level of risk than others. The level of project risk is influenced by project size, project structure, and the level of technical expertise of the information systems staff and project team.
Project size. The larger the project�as indicated by the dollars spent, the size of the implementation staff, the time allocated for implementation, and the number of organizational units affected�the greater the risk. Very large-scale systems projects have a failure rate that is 50 to 75 percent higher than that for other projects because such projects are complex and difficult to control. The organizational complexity of the system�how many units and groups use it and how much it influences business processes�contributes to the complexity of large-scale systems projects just as much as technical characteristics, such as the number of lines of program code, length of project, and budget (Xia and Lee, 2004; Concours Group, 2000; Laudon, 1989; U.S. General Services Administration, 1988).
Project structure. Some projects are more highly structured than others. Their requirements are clear and straightforward so outputs and processes can be easily defined. Users know exactly what they want and what the system should do; there is almost no possibility of the users changing their minds. Such projects run a much lower risk than those with relatively undefined, fluid, and constantly changing requirements; with outputs that cannot be fixed easily because they are subject to users� changing ideas; or with users who cannot agree on what they want.
Experience with technology. The project risk rises if the project team and the information system staff lack the required technical expertise. If the team is unfamiliar with the hardware, system software, application software, or database management system proposed for the project, it is highly likely that the project will experience technical problems or take more time to complete because of the need to master new skills.
The Navy/Marine Corps Intranet described in the Window on Management is an example of a very complex systems project�perhaps the largest outsourcing project ever contracted. It is much more than a private Web site, involving servers, computer centers, 4,000 locations, 345,000 personal computer �seats,� and 100,000 legacy applications that must either be retired, converted, or maintained as is in separate systems. Navy and Electronic Data Systems (EDS) planners underestimated both the sheer amount work involved and the difficulties they would encounter during implementation.
MANAGEMENT OF THE IMPLEMENTATION PROCESS
The development of a new system must be carefully managed and orchestrated, and the way a project is executed is likely to be the most important factor influencing its outcome (Wallace and Keil, 2004). Often basic elements of success are forgotten. Training to ensure that end users are comfortable with the new system and fully understand its potential uses is often sacrificed or forgotten in systems development projects. If the budget is strained at the very beginning, toward the end of a project there will likely be insufficient funds for training and documentation (Bikson et al., 1985).
The conflicts and uncertainties inherent in any implementation effort are magnified when an implementation project is poorly managed and organized. As illustrated in Figure 15-6, a systems development project without proper management will most likely suffer these consequences:
Costs that vastly exceed budgets
Unexpected time slippage
Technical shortfalls resulting in performance that is significantly below the estimated level
Failure to obtain anticipated benefits
FIGURE 15-6 Consequences of poor project management |
How badly are projects managed? On average, private sector projects are underestimated by one-half in terms of budget and time required to deliver the complete system promised in the system plan. A very large number of projects are delivered with missing functionality (promised for delivery in later versions). The Standish Group International found that only 9 percent of all technology investments were completed on time, on budget, or within scope. Between 30 and 40 percent of all software projects are �runaway� projects that far exceed the original schedule and budget projections and fail to perform as originally specified (Keil, Mann, and Rai, 2000). Why are projects managed so poorly and what can be done about it? Here we discuss some possibilities.
Ignorance and optimism.The techniques for estimating the length of time required to analyze and design systems are poorly developed. Most applications are �first time� (i.e., there is no prior experience in the application area). The larger the scale of systems, the greater the role of ignorance and optimism. The net result of these factors is that estimates tend to be optimistic, �best case,� and wrong. It is assumed that all will go well when in fact it rarely does.
The mythical man-month. The traditional unit of measurement used by systems designers to project costs is the man-month. Projects are estimated in terms of how many man-months are required. However, adding more workers to projects does not necessarily reduce the elapsed time needed to complete a systems project (Brooks, 1974). Unlike cotton picking�when tasks can be rigidly partitioned, communication between participants is not required, and training is unnecessary�building systems often involves tasks that are sequentially linked, that cannot be performed in isolation, and that require extensive communications and training. Adding labor to software projects where there are many task interdependencies can often slow down delivery as the communication, learning, and coordination costs escalate and detract from the output of participants (Andres and Zmud, 2001�2002). For comparison, imagine what would happen if five amateur spectators were added to one team in a championship professional basketball game. The team composed of five professional basketball players would probably do much better in the short run than the team with five professionals and five amateurs.
Falling behind: Bad news travels slowly upward. Among projects in all fields, slippage in projects, failure, and doubts are often not reported to senior management until it is too late (Keil and Robey, 2001; Smith, Keil, and Depledge, 2001). The CONFIRM project, a very large-scale information systems project to integrate hotel, airline, and rental car reservations, is a classic example. It was sponsored by Hilton Hotels, Budget Rent-A-Car, and the Marriott Corporation and developed by AMR Information Services, a subsidiary of American Airlines Corporation. The project was very ambitious and technically complex, employing a staff of 500. Members of the CONFIRM project management team did not immediately come forward with accurate information when the project began encountering problems coordinating various transaction-processing activities. Clients continued to invest in a project that was faltering because they were not informed of its problems with database, decision-support, and integration technologies (Oz, 1994).
THE NAVY/MARINE CORPS INTRANET TURNS INTO A BATTLEGROUND
The U.S. Navy/Marine Corps Intranet (NMCI) is a giant project for consolidating hundreds of disparate networks and 100,000 legacy applications into a single, integrated, secure architecture with standardized hardware and software linking 345,000 computers at 4,000 Navy and Marine Corps bases in the United States and abroad. (Tactical networks used aboard ships or in combat zones are not included.)
Desktop computers, servers, software, and networking equipment must all be consolidated and replaced with more up-to-date technology. When completed, the project is expected to reduce the total cost of ownership (TCO) from $3,851 to $3,741 per laptop or desktop.
In 2000, the military hired Electronic Data Systems (EDS) to head the project, which was considered the largest outsourcing project on record, with an initial price tag of $6.9 billion. (In 2002, the total cost was expanded to $8.8 billion.) EDS was responsible for overseeing the work of other vendors, including Microsoft, Dell, Cisco Systems, and Raytheon.
The project has been fraught with delays and implementation problems since its inception. Navy planners expected an upgraded and secure network in 2001, but may not have all of the Navy computers converted until 2005. EDS, which contracted to deliver the project at a fixed cost, has already lost $1.6 billion on the assignment and stands to lose much more over the next few years.
Congress held up work for 18 months so that EDS could provide new network performance tests. EDS appears to have underestimated the complexity of the project. Many Navy networks were established years ago by base commanders, who procured their own hardware and software, and the project had to replace or separately maintain those legacy applications. It turned out that there were about 100,000 applications to deal with instead of 9,000, as the Navy had originally estimated.
About 3,000 applications were approved for use with NMCI. Another 24,000 have been �quarantined,� meaning that they can�t be run on new NMCI systems but will continue to be used until they are replaced or retired. Because not all of the old applications could be immediately eliminated, sailors and officers were allowed to use both their old and new computers. This dramatically increased technical support and equipment costs. Moreover, the large number of legacy applications that had to be integrated into the intranet, combined with testing delays, caused implementation to fall further and further behind.
The project had to surmount serious cultural hurdles. Insiders describe the Navy as a conglomerate of hundreds of information technology fiefdoms that fiercely resist losing control over their systems and networks. Though organized as a branch of the Navy, the Marine Corps wanted to opt out of the project and continue managing its own networks. (Congress, which had been skeptical about the business value of the project, kept the Marines from being included.) Massive cultural change would be required to get the Navy to accept the intranet in the interests of the enterprise as a whole.
Critics charge that the initial implementation plans for the intranet were overly ambitious and mismanaged. Although EDS had met project targets during the initial testing and evaluation phase, the remainder of the project started to fall behind schedule. Until the Navy established a central project office in 2002, EDS had to work out implementation plans separately with different organizations within the Navy, including Naval Air Systems Command (NAVAIR) and NAVSUP (supply management).
Taking advantage of poor coordination among EDS managers, some naval commanders made their own deals with EDS teams. Ranking officers sometimes ordered security restrictions loosened for their own convenience, although everyone was supposed to adhere to the same standards.
The project called for Navy personnel to order customized computers from EDS, and EDS would configure and install them. However, EDS installers were sometimes turned away from bases because they lacked proper security clearance or because the users of these computers were busy or overseas. EDS�s order-processing systems could not complete an order without a serviceperson�s rank. EDS, however, neglected to tell the Navy to provide information about rank on orders. Boxes of computers for orders that could not be completed piled up in warehouses. Unfilled orders meant lost revenue for EDS, which had agreed to pay for the computers and not bill the Navy until after they were installed.
To deal with these problems, EDS decided to install computers at the largest Navy bases first instead of trying to work at many bases simultaneously. It has stopped individually customizing computers, providing the same computer configuration to servicepeople with similar jobs. It is reusing expensive hardware such as network firewalls and installing computers that are already in the warehouses before ordering new ones.
Sources: Gary McWilliams, �After Landing Huge Navy Pact, EDS Finds It�s in Over Its Head,� Wall Street Journal, April 6, 2004; David F. Carr, �Half Speed,� Baseline Magazine, April 2004; and Dan Verton, �DOD IT Projects Come Under Fire,� Computerworld, May 20, 2002.
To Think About: What management, organizational, and technology factors caused NMCI to have so many problems? How could these problems have been prevented?
Change Management Challenges for Business Process Reengineering, Enterprise Applications, and Mergers and Acquisitions
Given the challenges of innovation and implementation, it is not surprising to find a very high failure rate among enterprise application and business process reengineering (BPR) projects, which typically require extensive organizational change and which may require replacing old technologies and legacy systems that are deeply rooted in many interrelated business processes. A number of studies have indicated that 70 percent of all business process reengineering projects fail to deliver promised benefits. Likewise, a high percentage of enterprise applications fail to be fully implemented or to meet the goals of their users even after three years of work.
Many enterprise application and reengineering projects have been undermined by poor implementation and change management practices that failed to address employees� concerns about change. Dealing with fear and anxiety throughout the organization; overcoming resistance by key managers; changing job functions, career paths, and recruitment practices; and managing training have posed greater threats to reengineering than the difficulties companies faced visualizing and designing breakthrough changes to business processes. All of the enterprise applications require tighter coordination among different functional groups as well as extensive business process change (see Chapter 14).
SYSTEM IMPLICATIONS OF MERGERS AND ACQUISITIONS
Mergers and acquisitions (M&As) have been proliferating because they are major growth engines for businesses. Potentially, firms can cut costs significantly by merging with competitors, reduce risks by expanding into different industries (e.g., conglomerating), and create larger pools of competitive knowledge and expertise by joining forces with other players. There are also economies of time: A firm can gain market share and expertise very quickly through acquisition rather than building over the long term.
Although some firms, such as General Electric, are quite successful in carrying out mergers and acquisitions, research has found that more than 70 percent of all M&As result in a decline in shareholder value and often lead to divestiture at a later time (Frank and Sidel, 2002; Lipin and Deogun 2000). Many deals suffer from poor planning and from unrealistic expectations about the synergies that could result from merging companies.
Architects of mergers and acquisitions often fail to appreciate the difficulty of integrating the systems of different companies. Mergers and acquisitions are deeply affected by the organizational characteristics of the merging companies as well as by their information technology (IT) infrastructures. Combining the information systems of two different companies usually requires considerable organizational change and complex systems projects to manage. If the integration is not properly managed, firms can emerge with a tangled hodgepodge of inherited legacy systems built by aggregating the systems of one firm after another. Without a successful systems integration, the benefits anticipated from the merger cannot be realized, or, worse, the merged entity cannot execute its business processes and loses customers.
Once a company targeted for acquisition has been identified, information systems managers need to identify the realistic costs of integration; the estimated benefits of economies in operation, scope, knowledge, and time; and any problematic systems that require major investments to integrate. In addition, IT managers can critically estimate any likely costs and organizational changes required to upgrade the IT infrastructure or make major system improvements to support the merged companies.
Which of the following statements best describes the effect that project structure?
Which of the following statements best describes the effect that project structure has on overall project risk? Highly structured projects tend to be larger, affecting more organizational units, and run both the risk of out-of-control costs and becoming too difficult to control.
Which of the following best describes the relationship between system implementation and user involvement and management support?
Which of the following best describes the relationship between system implementation and user involvement and management support? System implementation benefits from user support, but does not require management support.
Which of the following is an example of using an external integration tool?
Which of the following is a tangible benefit of an information system?
More timely information is a tangible benefit of information systems.