The Richard Ivey School of Business had recently introduced a wireless network and required all students to purchase laptops and network cards. After a year of use, the faculty decided to restrict laptop usage in class by disallowing the use of network cards. They felt the students were using the network cards for unrelated activities in class and that this was compromising the learning process. Reaction from the students was mixed, with some students quite vocal about the (un)fairness of this new policy. The section head for one of the MBA sections knew that finding a long-term solution would be a difficult process. There were valid points in the arguments to both restrict and not restrict the use of the cards. She had to evaluate the advantages and disadvantages in order to make a recommendation to the faculty at a section meeting the following day.
The controller of AMP of Canada learned that her existing transactional processing system was not year 2000 compliant. She must choose between three alternatives: upgrading the existing transactional processing system, implementing a customized software package that many AMP companies already used, or implementing SAP. She knew that Canadian management preferred to implement the very popular SAP system, but her information systems manager did not think that users were ready for SAP and preferred an option involving the existing system. The controller wondered which solution to choose and how to persuade Canadian management, the Canadian information systems department, and headquarters management to support this decision.
The second of the AMP of Canada case series (see the (A) case, 9A99E030 and the (C) case, 9A99E032), this case describes the decision to implement SAP, the project's history, and culminates with the final decision about whether to go live. Not all functionality is complete, but some may be completed before the go live on October 5, 1998, and some may not be immediately required to run the business. With only two weeks left, the project team is divided. The decision in the case is whether to go live, and how to handle the consequences of either decision.
The third in the AMP of Canada case series (see the (A) case, 9A99E030 and the (B) case, 9A99E031), this case describes events immediately after the (B) case. Although the project is officially a success, the organization has changed dramatically since the project began. The two key questions are revisiting the same decisions in cases (A) and (B): should the project have gone live, and was it the right decision to implement SAP.
The sales director of Xerox (Hong Kong) has a vision to transform sales force management processes that would require radical changes to both the organization and the information technology infrastructure. The design includes a companywide database to be available to the sales force by remote access through Intranet/Internet. From this database the sales force could manage their territory using notebook computers while traveling, working at client sites, sitting in meetings, or talking on the phone. At the time of sale, they could check inventory, quote prices, notify delivery or service schedules, and make billing arrangements. Successful implementation of the plan requires the sales director to overcome financial constraints, ingrained habits, traditional cultural values, an inadequate information technology infrastructure, and the effects of the change beyond the sales organization.
With changes in both technology and the environment, Nortel has had to evolve from a company that sells a collection of telecommunication products to a company that sells integrated packages of products that satisfy specific customer needs. In the past, I/S has been spread across the various product divisions, supporting a highly decentralized corporate structure. Now it has been charged with transforming itself to facilitate the company's need for greater integration, including a move to standardized systems. I/S must re-define its role and restructure itself to fulfill its new mandate. After an extensive analysis and design exercise, the I/S function has been re-visualized as centering on three key processes: client management, solution delivery, and business support. This represents a significant change from a traditional I/S shop that focuses on building applications and infrastructure. While there is broad support for the changes in principle, actually getting the new processes fully articulated and implemented presents a significant challenge.
Describes the situation faced by Nortel's Information Systems (I/S) department as the company tried to respond to changes in its environment. With the evolution and convergence in the telecommunications industry and expansion onto the global stage, the company saw the need to improve integration across business units. The I/S department was charged with helping the business units reengineer their process. Brad Taylor, director of I/S, is trying to reengineer the I/S department itself so that it could fulfill the new role. Unfortunately, the existing structure--a fragmented I/S group struggling to meet existing expectations--was poorly positioned for this role. Brad's dilemma was not only to change his own department, but to change the way in which it related to the rest of the company. Can be used to discuss the role and structure of an I/S department. Can also be used as the basis for a class on business process reengineering and/or managing organizational change.
This case documents the origins and development of a collaborative interorganizational system. This system is an experimental broadband network being used to trial both ATM technology and new applications such as the transmission, retrieval and archiving of medical images. Director of LARG*net confronts the difficulties of technological innovation and interorganizational management. It provides an illustration of the technical difficulties in integrating different systems, ensuring security, and the ramifications to an organization's own systems when connectivity with other organizations is attempted. It highlights the fact that IT infrastructure is more than just physical hardware. At the same time it raises the issues of handling accountability and responsibility across organizational boundaries.