Systems differ in terms of their size and technological complexity and in terms of the organizational problems they are meant to solve. A number of systems- building approaches have been developed to deal with these differences. This section describes these alternative methods: the traditional systems life cycle, prototyping, application software packages and cloud software services, end- user development, and outsourcing.
1. Traditional Systems Life Cycle
The systems life cycle is the oldest method for building information systems. The life cycle methodology is a phased approach to building a system, dividing systems development into formal stages, as illustrated in Figure 13.9. Systems development specialists have different opinions on how to partition the systems-building stages, but they roughly correspond to the stages of systems development we have just described.
The systems life cycle methodology maintains a formal division of labor between end users and information systems specialists. Technical specialists, such as systems analysts and programmers, are responsible for much of the systems analysis, design, and implementation work; end users are limited to providing information requirements and reviewing the technical staff’s work. The life cycle also emphasizes formal specifications and paperwork, so many documents are generated during the course of a systems project.
The systems life cycle is still used for building large, complex systems that require a rigorous and formal requirements analysis, predefined specifications, and tight controls over the system-building process. However, the systems life cycle approach can be costly, time-consuming, and inflexible. Although systems builders can go back and forth among stages in the life cycle, the systems life cycle is predominantly a “waterfall” approach in which tasks in one stage are completed before work for the next stage begins. Activities can be repeated, but volumes of new documents must be generated and steps retraced if requirements and specifications need to be revised. This encourages freezing of specifications relatively early in the development process. The life cycle approach is also not suitable for many small desktop systems, which tend to be less structured and more individualized.
2. Prototyping
Prototyping consists of building an experimental system rapidly and inexpensively for end users to evaluate. By interacting with the prototype, users can get a better idea of their information requirements. The prototype endorsed by the users can be used as a template to create the final system.
The prototype is a working version of an information system or part of the system, but it is meant to be only a preliminary model. Once operational, the prototype will be further refined until it conforms precisely to users’ requirements. Once the design has been finalized, the prototype can be converted to a polished production system.
The process of building a preliminary design, trying it out, refining it, and trying again has been called an iterative process of systems development because the steps required to build a system can be repeated over and over again. Prototyping is more explicitly iterative than the conventional life cycle, and it actively promotes system design changes. It has been said that prototyping replaces unplanned rework with planned iteration, with each version more accurately reflecting users’ requirements.
2.1. Steps in Prototyping
Figure 13.10 shows a four-step model of the prototyping process, which consists of the following:
Step 1: Identify the user’s basic requirements. The systems designer (usually an information systems specialist) works with the user only long enough to capture the user’s basic information needs.
Step 2: Develop an initial prototype. The systems designer creates a working prototype quickly, using tools for rapidly generating software.
Step 3: Use the prototype. The user is encouraged to work with the system to
determine how well the prototype meets his or her needs and to make suggestions for improving the prototype.
Step 4: Revise and enhance the prototype. The system builder notes all changes the user requests and refines the prototype accordingly. After the prototype has been revised, the cycle returns to Step 3. Steps 3 and 4 are repeated until the user is satisfied.
When no more iterations are required, the approved prototype then becomes an operational prototype that furnishes the final specifications for the application. Sometimes the prototype is adopted as the production version of the system.
2.2. Advantages and Disadvantages of Prototyping
Prototyping is most useful when there is some uncertainty about requirements or design solutions and is often used for designing an information system’s end-user interface (the part of the system with which end users interact, such as online display and data entry screens, reports, or web pages). Because prototyping encourages intense end-user involvement throughout the systems development life cycle, it is more likely to produce systems that fulfill user requirements.
However, rapid prototyping can gloss over essential steps in systems development. If the completed prototype works reasonably well, management may not see the need for reprogramming, redesign, or full documentation and testing to build a polished production system. Some of these hastily constructed systems may not easily accommodate large quantities of data or a large number of users in a production environment.
3. End-User Development
End-user development allows end users, with little or no formal assistance from technical specialists, to create simple information systems, reducing the time and steps required to produce a finished application. Using user- friendly query languages and reporting, website development, graphics, and PC software tools, end users can access data, create reports, and develop simple applications on their own with little or no help from professional systems analysts or programmers. A query language is a software tool that provides immediate online answers to questions that are not predefined, such as “Who are the highest-performing sales representatives?” Query languages are often tied to data management software (see Chapter 6). For example, CEMEX, an international supplier of products for the construction industry, used Information Builders WebFOCUS to create a self-service reporting portal to visualize financial and operational data.
On the whole, end-user-developed systems can be completed more rapidly than those developed through the conventional systems life cycle. Allowing users to specify their own business needs improves requirements gathering and often leads to a higher level of user involvement and satisfaction with the system. However, end-user software tools still cannot replace conventional tools for some business applications because they cannot easily handle the processing of large numbers of transactions or applications with extensive procedural logic and updating requirements.
End-user computing also poses organizational risks because it occurs outside of traditional mechanisms for information systems management and control. When systems are created rapidly without a formal development methodology, testing and documentation may be inadequate. Control over data can be lost in systems outside the traditional information systems department. To help organizations maximize the benefits of end-user applications development, management should control the development of end-user applications by requiring cost justification of end-user information system projects and by establishing hardware, software, and quality standards for user-developed applications.
4. Application Software Packages, Software Services, and Outsourcing
Chapter 5 points out that much of today’s software is not developed in-house but is purchased from external sources. Firms can rent the software from an online software service provider, they can purchase the software from a commercial vendor as a package to run in-house, or they can have a custom application developed by an outside outsourcing firm.
4.1. Application Software Packages and Cloud Software Services
Today many systems are based on commercially available application software packages or cloud software as a service (SaaS). For example, companies can choose to implement Oracle enterprise resource planning, supply chain management, or human capital management software in-house or pay to use this software running on the Oracle Cloud platform. Microsoft Office desktop productivity software comes in both desktop and cloud (Office 365) versions. Many applications are common to all business organizations—for example, payroll, accounts receivable, general ledger, or inventory control. For such universal functions with standard processes that do not change a great deal over time, a more generic system will fulfill the requirements of many organizations.
If a commercial software package or cloud software service can fulfill most of an organization’s requirements, the company does not have to write its own software. The company can save time and money by using the prewritten, predesigned, pretested software programs from the software vendor. Package and SaaS vendors supply much of the ongoing maintenance and support for the system, including enhancements to keep the system in line with ongoing technical and business developments. When a package or SaaS solution is pursued, end users will be responsible for supplying the business information requirements for the system, and information systems specialists will provide technical requirements.
If an organization has unique requirements that the package does not meet, these tools include capabilities for customization. Customization features allow a commercial software package or cloud-based software to be modified to meet an organization’s unique requirements without destroying the integrity of the software. (See the chapter-opening case on Cameron International and the chapter-ending case on Hitachi Consulting for examples.) If a great deal of customization is required, additional programming and customization work may become so expensive and time-consuming that they negate many of the advantages of software packages and services.
When a system is developed using an application software package or a cloud software service, systems analysis will include a formal evaluation of the software package or service in which both end users and information systems specialists will participate. The most important evaluation criteria are the functions provided by the software, flexibility, user-friendliness, hardware requirements, database requirements, installation and maintenance efforts, documentation, vendor quality, and cost. The package or software service evaluation process often is based on a request for proposal (RFP), which is a detailed list of questions submitted to software vendors.
When software from an external source is selected, the organization no longer has total control over the systems design process. Instead of tailoring the systems design specifications directly to user requirements, the design effort will consist of trying to mold user requirements to conform to the features of the package or software service. If the organization’s requirements conflict with the way the package or software service works and this software cannot be customized, the organization will have to adapt to the package or software service and change its procedures.
4.2. Outsourcing
If a firm does not want to use its internal resources to build or operate information systems, it can outsource the work to an external organization that specializes in providing these services. Cloud computing and software as a service (SaaS) providers, which we described in Chapter 5, are one form of outsourcing. Subscribing companies use the software and computer hardware provided by the service as the technical platform for their systems. In another form of outsourcing, a company could hire an external vendor to design and create the software for its system, but that company would operate the system on its own computers. The outsourcing vendor might be domestic or in another country.
Domestic outsourcing is driven primarily by the fact that outsourcing firms possess skills, resources, and assets that their clients do not have. Installing a new supply chain management system in a very large company might require hiring an additional 30 to 50 people with specific expertise in supply chain management software licensed from a vendor. Rather than hire permanent new employees, most of whom would need extensive training in the new software, and then release them after the new system is built, it makes more sense, and is often less expensive, to outsource this work for a 12-month period.
In the case of offshore outsourcing, the decision is much more cost-driven. A skilled programmer in India or Russia earns about $10,000-$30,000 per year compared with about $60,000 or more per year for a comparable programmer in the United States. The Internet and low-cost communications technology have drastically reduced the expense and difficulty of coordinating the work of global teams in offshore locations. In addition to cost savings, many offshore outsourcing firms offer world-class technology assets and skills. Wage inflation outside the United States has recently eroded some of these advantages, and some jobs have moved back to the United States. Firms generally do not outsource the conception, systems analysis, and design of IT systems to offshore firms, but often do outsource programming, testing, maintenance, and daily operation of IT systems.
A firm is most likely to benefit from outsourcing if it takes the time to evaluate all the risks and to make sure outsourcing is appropriate for its particular needs. Any company that outsources its applications must thoroughly understand the project, including its requirements, method of implementation, anticipated benefits, cost components, and metrics for measuring performance.
Many firms underestimate costs for identifying and evaluating vendors of information technology services, for transitioning to a new vendor, for improving internal software development methods to match those of outsourcing vendors, and for monitoring vendors to make sure they are fulfilling their contractual obligations. Companies will need to allocate resources for documenting requirements, sending out RFPs, handling travel expenses, negotiating contracts, and project management. Experts claim it takes from three months to a full year to fully transfer work to an offshore partner and make sure the vendor thoroughly understands your business.
Outsourcing offshore incurs additional costs for coping with cultural differences that drain productivity and dealing with human resources issues, such as terminating or relocating domestic employees. All of these hidden costs undercut some of the anticipated benefits from outsourcing. Firms should be especially cautious when using an outsourcer to develop or to operate applications that give it some type of competitive advantage.
General Motors Corporation (GM) had outsourced 90 percent of its IT services, including its data centers and application development. The company later decided to bring 90 percent of its IT infrastructure in-house, with only 10 percent managed by outsourcers. Lowering costs is important, but GM’s primary reason for cutting back outsourcing was to take back control of its information systems, which it believes were preventing the company from responding quickly to competitive opportunities. Bringing information systems in-house will make it easier for GM to standardize and streamline its systems and data centers. Figure 13.11 shows best- and worst-case scenarios for the total cost of an offshore outsourcing project. It shows how much hidden costs affect the total project cost. The best case reflects the lowest estimates for additional costs, and the worst case reflects the highest estimates for these costs. As you can see, hidden costs increase the total cost of an offshore outsourcing project by an extra 15 to 57 percent. Even with these extra costs, many firms will benefit from offshore outsourcing if they manage the work well.
Source: Laudon Kenneth C., Laudon Jane Price (2020), Management Information Systems: Managing the Digital Firm, Pearson; 16th edition.
There is noticeably a bundle to learn about this. I assume you made sure nice points in features also.