Presentation is loading. Please wait.

Presentation is loading. Please wait.

Acquiring IT Applications and Infrastructure

Similar presentations

Presentation on theme: "Acquiring IT Applications and Infrastructure"— Presentation transcript:

1 Acquiring IT Applications and Infrastructure
Chapter 14 Acquiring IT Applications and Infrastructure Information Technology For Management 5th Edition Turban, McLean, Wetherbe Lecture Slides by A. Lekacos, Stony Brook University John Wiley & Sons, Inc. Chapter 14

2 LEARNING OBJECTIVES Describe the process of IT acquisition or development. Describe IT project identification, justification, and planning. List the major IT acquisition options and the criteria for option selection. Describe the use of criteria for selecting an acquisition approach. Describe the role of ASPs. Describe the process of vendor and software selection. Understand some major implementation issues. Understand the issue of connecting IT applications to databases, other applications, networks, and business partners. Describe the need for business process redesign and the methodologies for doing it. Explain the IT support for process redesign and BPR, and describe redesign efforts, successes, and failures. Chapter 14

3 Information System Acquisition
Various Approaches to obtaining Information Systems Buying Leasing Building The Acquisition issue is still complex Chapter 14

4 The five major steps of Acquisition
Chapter 14

5 Acquiring IT Applications Option 1 - Buy
Chapter 14

6 Acquiring IT Applications Option 2- Lease
TYPES OF LEASING VENDORS Leasing can be done in one of two ways. The first way is to lease the application from an outsourcer and install it on the company’s premises. The vendor can help with the installation and frequently will offer to also contract for the operation and maintenance of the system. Many conventional applications are leased this way. The second way, using an application system provider (ASP), is becoming more popular. Chapter 14

7 Acquiring IT Applications Option 2 - Lease- Utility Computing
Chapter 14

8 Acquiring IT Applications Option 3 – Development In-House
IN-HOUSE DEVELOPMENT APPROACHES. There are two major approaches to in-house development: building from scratch or building from components. Build from scratch. This option should be considered only for specialized applications for which components are not available. It is an expensive and slow process, but it will provide the best fit. Build from components. Companies with experienced IT staff can use standard components (e.g., a secure Web server), some software languages (e.g., Java, Visual Basic, or Perl), and third-party subroutines to create and maintain applications on their own. (Or, companies can outsource the entire development process to an integrator that assembles the components.) From a software standpoint, using components offers the greatest flexibility and can be the least expensive option in the long run. However, it can also result in a number of false starts and wasted experimentations. For this reason, even those companies with experienced staff are frequently better off modifying and customizing one of the packaged solutions as part of the “buy” option. Chapter 14

9 Systems Development Life Cycle
Provides a comprehensive formal framework for designing and developing systems for the effective and efficient processing of information. There is no universal, standardized version of the SDLC however a typical eight stage model is shown below. Note that the stages overlap: One stage may start before the previous stage ends. This is in contrast to the traditional waterfall method, in which the work flows through all the tasks in one stage before going on to the next stage. Also note that the processes can go backward more than one stage. SDLC: Formal and disciplined approach to systems development Chapter 14

10  SDLC - Stages Stage 1: Project initiation. Projects often start when a manager has a problem or sees an opportunity. Stage 2: Systems Analysis And Feasibility Studies consists of two phases of analysis: systems analysis and feasibility studies. Systems analysis is the phase that develops a thorough understanding of the existing organization, its operation, and the situation that is causing a problem. Systems analysis methods include: observation review of documents interviews performance measurement. Chapter 14

11 SDLC – Stages Continued
Feasibility studies calculate the probability of success of the proposed solution and include: Technology. Economics. Organizational factors Legal, ethical, and other constraints. Stage 3: Logical Analysis And Design emphasizes the design of system from the user’s point of view. It identifies information requirements and specifies operations such as input, output, processing and storage. To represent logical processes and data relationships modeling tools such as data flow diagrams and entity-relationship diagrams can be used. The logical design is followed by a physical design. Chapter 14

12 SDLC – Stages Continued
Stage 4: Development or Acquisition the actual development or acquisition of the system. IS personnel use the specifications to purchase the hardware and software required for the system. Programmers write code for parts of the system. Technical writers develop documentation and training materials. IS personnel test the system Users test prior to the actual implementation. Stage 5: Implementation is an important stage; the system can fail here even if it has all the specified functionality. Users need training Forms need to be ordered Help desk needs to be created Chapter 14

13 SDLC – Stages Continued
Stage 5: Implementation - continued Also requires a conversion from a previous system. Conversion approaches include: Parallel conversion: The old and new systems operate concurrently for a test period, and then the old system is discontinued. Direct cutover: The old system is turned off, and the new system is turned on. Pilot conversion: The new system is implemented in a subset of locations (for example, some of the branches in a large banking chain) and is extended to remaining locations over time. Phased conversion: Large systems often are built from distinct modules. If the modules were originally designed to be relatively independent, it may be possible to replace the modules one at a time. Stage 6: Operation. Post production environment. Chapter 14

14 SDLC – Stages Continued
Stage 7: Post-Audit Evaluation reviews the stages and processes to determine best practice methods. Stage 8: Maintenance. Every system needs two regular types of maintenance: Fixing of bugs Regular system updating Therefore it is important that the design and development stages produce systems that are easy to maintain and are flexible enough to handle future expansion, upgrading and capacity increases. Chapter 14

15 Alternatives to SDLC methodologies
The traditional SDLC approach works best on projects in which users have a clear idea about their requirements. Projects that require major changes in existing processes, through reengineering or development of new processes or those that build upon inter-organizational and international systems using Web technologies indicate a need for alternatives or supplements to conventional SDLC methodologies. Some alternatives: Prototyping Joint application design (JAD) Rapid application development (RAD) Object-oriented development (OO) Extreme Programming (XP) Component-based development Chapter 14

16 Alternatives - continued
Prototyping (evolutionary development): Instead of spending a lot of time producing very detailed specifications, the developers find out only generally what the users want. The developers do not develop the complete system all at once. Instead they quickly create a prototype, which either contains portions of the system of most interest to the users, or is a small-scale working model of the entire system. After reviewing the prototype with the users, the developers refine and extend it. This process is continued until the final specifications. Joint application design (JAD) is a group-based method for collecting user requirements and creating system designs. It is used within the systems analysis and design stages of the SDLC. Unlike the traditional SDLC, where the analysts interview individual users of the new information system to understand their needs JAD has a meeting in which all users meet simultaneously with analysts. During the meeting, all users jointly define and agree upon systems requirements. Chapter 14

17 System Development Alternatives
Many organizations are using approaches that shift the construction of systems from their information systems department to others. End-User Development: Let users build their own systems Outsourcing: Outsource the entire systems development process Purchasing: (“The make-or-buy decision”) Let users use off-the-shelf software packages. Utility computing, consists of a virtualized pool of “self-managing” IT resources (computing power and storage capacity) that can be dynamically allocated for any application Chapter 14

18 System Development Alternatives
Outsourcing and Application Service Providers. Outsourcing: use of outside contractors or external organizations to acquire IT services. ASP-Application Service Provider, is an agent or vendor who assembles the software needed by enterprises and packages them usually with outsourced development, operations, maintenance, and other services. The main difference between an ASP and an outsourcer is that an ASP will manage application servers in a centrally controlled location, rather than on a customer’s site. Chapter 14

19 E-Business Application Development
The diversity of e-business models and applications, which vary in size from a small store to a global exchange, requires a variety of development methodologies and approaches. There are several options for developing e-business (e-biz) applications: Buying an existing package can be cost-effective and timesaving in comparison to in-house application development. Leasing is advantageous over buying in those cases where extensive maintenance is required, or where the cost of buying is very high. Develop in-house. Build from scratch. Build from components. Enterprise application integration Chapter 14

20 System Development Alternatives
Chapter 14

21 Advantages and Disadvantages
Chapter 14

22 Software Vendor Selection
A Six Step Selection Method Identify Potential Vendors Determine the Evaluation Criteria RFP-Request For Proposal List of users Evaluate Vendors and Packages Choose the Vendor and Package Negotiate A Contract Establish A Service Level Agreement-(SLA) Chapter 14

23 Software Selection Chapter 14

24 Connecting To Databases and Business Partners
EC MUST BE INTEGRATED Many IT Applications need to be connected to a Database IT must be connected to business partners, especially for B2B E-Commerce Chapter 14

25 Business Process Redesign (BPR)
Environmental pressures from customers, competition and market changes may require more comprehensive responses then typical organizational responses. These extensive changes in operations, processes or structure are called business process redesign. Drivers of Process Redesign Fitting commercial software Streamlining the supply chain Participating in private or public e-marketplaces Improving customer service Conducting e-procurement Enabling direct online marketing Reducing cost and improving productivity Automating old processes Transformation to e-business A business process is a collection of activities that take one or more kinds of inputs and create an output. Chapter 14

26 Business Process Redesign (BPR) continued
Business process redesign was preceded by business process reengineering, a methodology in which an organization fundamentally and radically redesigned its business processes to achieve dramatic improvement. Today, BPR can focus on anything from the redesign of an individual process, to redesign of a group of processes, to redesign of the entire enterprise. BPM A new method for restructuring, Business process management (BPM), combines workflow systems and redesign methods. This emerging methodology covers three process categories: people-to-people, systems-to-systems, and systems-to-people interactions. It is a blending of workflow, process management, and applications integration. Chapter 14

27 Business Process Redesign (BPR) Information Technology’s Role
The traditional process of looking at problems first and then seeking technology solutions for them may need to be reversed. A new approach is first to recognize powerful redesign solutions that restructuring and BPR make possible, and then to seek the processes that can be helped by such solutions. Thus the role of IT in redesigning business processes can be very critical. Integrating fragmented information systems Employing data warehouses Implementing an extended supply chain Utilizing B2B e-marketplaces Providing a single point of contact for customers Redesign of business processes often means a need to change some or all of the organizational information systems. This process is referred to as retooling Chapter 14

28 Business Changes Information Technology’s Role
Chapter 14

29 Business Process Redesign (BPR) Development Software
A large variety of IT tools can be used to support redesign and BPR. Some are generic, while others are specifically designed for redesign and BPR. Special BPR and process redesign software enables the capture of the key elements of a business process in a visual representation made up of interconnected objects on a time line. The elements include: Activities Sequencing Resources Times Rules BPR software also has “what-if” capabilities in that it enables process simulation and performance comparison of alternative process designs. BPR software may incorporate some aspects of project management in terms of allocating resources and costs to work activities and their time sequencing. Chapter 14

30 Business Process Redesign (BPR) Restructuring Processes
Redesign, restructuring, and reengineering efforts involve many activities on the value and supply chains. Efficient PO, to AP to Receiving system the classical “3-Way” Match Cross-docking, movement of just received merchandise to out going loading platforms Mass Customization, maintaining Work-In-Process inventory Cycle Time reduction, the time it takes to complete a process from beginning to end Vendor managed inventory Mobile devices Many more … Chapter 14

31 Business Process Redesign (BPR) Restructuring the Organization
The fundamental problem with the hierarchical organizational structure is that any time a decision needs to be made, it must climb up and down the hierarchy. Yet in thin structures there is a need for horizontal communications to minimize inefficiencies. Thick (many levels) hierarchical structure Thin (single level) structure Network structure Virtual Network structure or organization Why is an efficient Structure important? Management suited to strategy Better response to Opportunities and Threats Higher morale Developing Culture Control Chapter 14

32 Business Process Redesign (BPR) Change Management
Major organizational changes such as transformation to e-business are referred to as organization transformation. This process usually requires change management. Organization transformation refers to an organization with a “new face,” whose business processes, structure, strategy, and procedures are completely different from the old one. Such a radical transformation can be a lengthy, expensive, and complex process, which may involve organizational learning, changes in management and personnel, creation of a new structure, and employee retraining. Change Management refers to the implementation, control and guidelines to introduce change into organizations. Changing business processes, organizational structure and operating procedures are interrelated and depending upon the magnitude of the change can be met with employee resistance. Since change is a learning process its impact can be minimized if properly managed. Chapter 14

33 Business Reengineering (BANK)
Chapter 14

34 MANAGERIAL ISSUES Importance. Some general and functional managers believe that system development is a technical topic that should be of interest only to technical people. This is certainly not the case. Appropriate construction of systems is necessary for their success. Functional managers must participate in the development process and should understand all the phases. They must also participate in the make-or-buy decisions and software selection decisions. Inappropriate development methodologies can result in the system’s failure. Ethical and legal issues. Developing systems across organizations and countries could result in problems in any phase of system development. For example, in developing the Nagano Olympics system in 1998, IBM found at the last minute that pro-North-Korea groups in Japan took offense at a reference to the Korean War written on the Web site. Although the material was taken from the World Book Encyclopedia, it offended some people. IBM had to delete the reference and provide an apology. IBM commented, “Next time we’re going to do a ton of research first versus just do it and find out the hard way.” A special difficulty exists with Internet-related projects, where legislation is still evolving. User involvement. The direct and indirect users of a system are likely to be the most knowledgeable individuals concerning requirements and which alternatives will be the most effective. Users are also the most affected by a new information system. IS analysts and designers, on the other hand, are likely to be the most knowledgeable individuals concerning technical and data-management issues as well as the most experienced in arriving at viable systems solutions. The right mixture of user involvement and information systems expertise is crucial. Chapter 14

Tool use by developers. Development tools and techniques can ensure that developers consider all necessary factors and standardize development, documentation, and testing. Forcing their use, on the other hand, may unnecessarily constrain innovation, development efficiency, and personnel productivity. Quality assurance vs. schedules. Quality counts in the short term and the long term, but it can lengthen development and increase developmental costs. Trying to meet tight development schedules can induce poor quality with even worse schedule, cost, and morale problems. Control is done with ISO 9000 standards (see Online File W14.18). Behavior problems. People use information systems and often become quite used to how existing systems work. They may react to new systems in unexpected ways, making even the best technically designed systems useless. Changes brought about by information systems need to be managed effectively. Of special interest is the issue of motivating programmers to increase their productivity by learning new tools and reusing preprogrammed modules. Integration: The role of IT in redesign and BPR. Almost all major supply chain management (SCM) and/or BPR projects use IT. However, it is important to remember that in most cases the technology plays a supportive role. The primary role is organizational and managerial in nature. On the other hand, without IT, most SCM and BPR efforts do not succeed. Chapter 14

Perpetual development. Information systems are designed to meet organizational needs. When they don’t accurately meet these needs, or these needs change, information systems need to be redeveloped. Developing a system can be a major expense, but perpetually developing a system to maintain its usefulness is usually much more expensive. Risk level. Building information systems involves risk. Systems may not be completed, completed too late, or require more resources than planned. The risk is large in enterprise systems. For how to manage such risk, see Scott and Vessey (2002) and Levine (2004). Business process redesign. Business process redesign can be driven by the need to prepare for IT or by many other reasons. It can be done by methodologies ranging from BPR to BPM. Chapter 14

Structural changes. IT helps not only to automate existing processes but also to introduce innovations that change structure (e.g., create case managers and interdisciplinary teams), reduce the number of processes, combine tasks, enable economic customization, and reduce cycle time. Ethical and legal issues. Conducting interviews for finding managers’ needs and requirements must be done with full cooperation. Measures to protect privacy must be taken. In designing systems one should consider the people in the system. Reengineering IT means that some employees will have to completely reengineer themselves. Some may feel too old to do so. Conducting a supply chain or business process reorganization may result in the need to lay off, retrain, or transfer employees. Should management notify the employees in advance regarding such possibilities? And what about those older employees who may be difficult to retrain? Chapter 14

38 Chapter 14 Copyright © 2005 John Wiley & Sons, Inc.  All rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without the express written permission of the copyright owner is unlawful.  Request for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc.  The purchaser may make back-up copies for his/her own use only and not for distribution or resale.  The Publisher assumes no responsibility for errors, omissions, or damages, caused by the use of these programs or from the use of the information contained herein. Chapter 14

Download ppt "Acquiring IT Applications and Infrastructure"

Similar presentations

Ads by Google