Packaged Software and Enterprise Resource Planning

Systems Analysis and Design in a Changing World

Chapter 18: Packaged Software and Enterprise Resource Planning

ISBN: 0619213256 Author: John W. Satzinger, Robert B. Jackson, Stephen D. Burd, Richard Johnson
copyright © 2004 Course Technology
Packaged Software and Enterprise Resource Planning
Learning Objectives

After reading this chapter, you should be able to:

* Discuss three major analysis and design issues associated more often with packages than with custom-developed software
* Name the three types of package customization and explain when each would be necessary
* Identify and explain the four major characteristics of ERP systems and discuss several reasons for adopting ERP
* Identify and explain several critical success factors for ERP implementation
* Distinguish the three major approaches to ERP system development
* Discuss how methods used for ERP systems deployment differ from those used for conventional system development
* Identify and explain the four major steps to ERP package selection
* Discuss the major areas of expansion for ERP
* Identify the four high-level work areas of SAP R/3
* Identify and discuss the five types of master data in SAP R/3
* Describe the function of R/3 Basis software
* Describe how transactions are entered in SAP R/3

Chapter Outline

* Packaged Software
* Enterprise Resource Planning
* A Closer Look at One ERP Package: SAP R/3

Premier Candy Corp.: The Possible Pitfalls of ERP

Enterprise resource planning (ERP) systems have become notorious for problems encountered during installation and final implementation. Perhaps the best example of the pitfalls is illustrated by the Premier Candy Corporation of Roanoke, Virginia. The company decided to implement an ERP system during early summer, right at the time retailers were placing large orders for back-to-school sales and Halloween. The new $120 million enterprise information system, which also included a customer relationship management (CRM) package and a production forecasting and scheduling application (both from other third-party vendors), was designed to replace scores of legacy systems that were running everything from inventory to order processing to human resources. The system was installed with high expectations for improved efficiency and effectiveness.

Instead, the end result was nearly disastrous. By late summer, the company was still trying to fix glitches in its order-processing and shipping functions. During the busiest season of the year, big retail chains turned from Premier to its major competitors to meet the extra demand for candy. Inventory levels in Premier warehouses mushroomed. The bottom line was that third-quarter sales dropped significantly compared with the previous year, and earnings plummeted.

What went wrong? The ERP vendor said that Premier's initial difficulty wasn't due to any problems with the ERP software. Like most companies with snarled ERP projects, Premier didn't offer many details. But outsiders point to two notable errors the company made. The first involves timing. The busiest season of the year is not the time to install a famously complex product like an ERP system and take it live. Snags always arise, and it's far easier to iron them out during less busy periods of the year.

Second, Premier attempted to do too much at once. Installing ERP software is complicated enough. Throw in a CRM program and a logistics package, and the project becomes dangerously complex. Premier probably felt rushed to get all three integrated systems up and running. The ERP vendor noted that Premier tried to implement “a complex system on a very aggressive project plan.” Premier and four different teams of consultants squeezed into just 30 months the massive ERP system that was originally estimated to be a four-year project. Most companies install ERP systems in stages, especially when applications from multiple vendors are involved. An all-at-once rollout is tempting because it's faster and potentially cheaper, but it is also extremely risky.

Yet another potential problem at Premier involved massive changes to business processes. The new system required enormous changes in the way Premier's workers did their jobs. Premier drastically underestimated the effects of an ERP system on its people. For example, instead of completing all shipping documents manually, long-time Premier employees (who had never used a computer) had to learn to navigate through complex software to print them.

Is that the end of the story? No. A full year after the debacle, Premier reported that revenue and profits in the third quarter rose dramatically. The ERP systems as well as a revamped distribution facility in the eastern United States were credited with the turnaround. Premier officials declined to elaborate on the steps the company took to straighten out the system. While a complex ERP system requires extreme care in installation and sound implementation strategy and execution, the results can be very rewarding.

The information systems of many companies are often very complex. Even though Rocky Mountain Outfitters (RMO) is a relatively small company, it has many of the same needs as large corporations, needs that possibly can be addressed with stand-alone software packages, or even ERP software, instead of custom-developed software. This chapter begins by looking at the key issues of working with application packages in general, followed by a survey of ERP—what it is, why it is an important option for system improvement, and how it is implemented. Finally, one ERP package, SAP R/3, will be examined to give you a better understanding of how ERP works.

Figure 18-1 illustrates a computer-based information system consisting of many tightly linked components (hardware, software, data, networks, procedures, and people) working together to provide the information needs of one or more business functions. The process of systems analysis and design must address adequately all these components to satisfy the needs of users— the ultimate judges of system success. The focus of this text has been on the analysis and design of business application software— computer programs created to solve specific business problems. At issue in this chapter are two major questions related to business application software. First, what is the best way to procure this software? Second, after obtaining the software, how does a firm best utilize it to achieve the firm's objectives? The way in which individual companies, large or small, answer these questions has a tremendous impact on the future of IS organizations, the future of the enterprises they serve, and the future of the global economy.

Figure 18-1 IS components serving multiple business functions.

[Click to enlarge]

Let's consider the first question: How is software best procured? Throughout the early history of business computing, applications consisted almost entirely of custom-developed software—software created on demand according to the unique specifications of the intended users. The two parties primarily involved in system creation were in-house developers and in-house users. As the field of information systems matured, enterprising individuals realized that certain business applications, such as financial accounting functions, were fairly standardized. As third-party developers outside the business firm, they began to create packaged software to perform common or standardized functions. The intention was and is to sell these packages to a large number of customers with little or no need for modification. Today, the continuing demand for rapidly deployable, functional, and affordable software still drives third-party developers to explore new applications founded on various industries' “best practices,” fairly standard procedures commonly accepted as the optimal way of performing a given function. Such packages enable firms to avoid reinventing the wheel every time they need a new application. Some systems analysts maintain that the best way to procure software is by purchasing a package, provided the package can meet most user requirements.

Now for the second question: How is application software best utilized in a business environment? Should software be used only to satisfy the needs of individual, isolated departments, or is the entire organization best served when the information produced in one department is readily available for use in another? Software integration, a process that combines separate components or subsystems and addresses problems in their interactions, has long been a goal of many organizations. A rudimentary form of integration is often achieved through batch processing, but that approach delays the availability of critical information. Recent advances in client-server technology and telecommunications have fueled the integration of business applications in real time across departments, functions, and divisions of corporations, and even between a firm and its external suppliers and customers. The combination of the availability of packaged software and the push toward real-time integration has spawned a new branch of management information systems called enterprise resource planning (ERP). As discussed earlier, ERP uses software to manage companywide business processes in real time using a common database and shared management reporting tools. Several system development firms—such as SAP AG, Oracle, PeopleSoft, SAGE, and Microsoft—offer ERP systems. The key components in enterprise computing are shown in Figure 18-2.
software integration

the process of combining separately produced components or subsystems and addressing problems in their interactions

Figure 18-2 The key components in enterprise computing.

[Click to enlarge]

As chief information officer at Rocky Mountain Outfitters, Mac Preston is keenly aware that an ERP approach to system development is a definite possibility for RMO. In fact, Mac had been reading some trade journals that discuss the feasibility of purchasing a customer relationship management (CRM) package, either used as a stand-alone application or possibly integrated with an ERP system. Mac decided to alert his boss, JoAnn White, of this alternative to the in-house development of the proposed customer support system (see the accompanying memo).

[Click to enlarge]
Packaged Software

As we've already discussed, packaged software traditionally focused on performing isolated business functions. More recently, the emergence of packaged suites, such as ERP systems, has completely reengineered the information systems function in many large corporations. Stand-alone packages cannot share information unless forced to do so through the efforts of system integrators, individuals who are specially trained in integrating application software across various computing platforms. With an ERP system, however, the advanced application software for all functional departments in an organization can easily share information, improving effectiveness and efficiency tremendously. Organizations are now faced with critical decisions concerning the futures of their information systems. Should they continue to maintain their existing legacy systems or scrap them entirely? If they plan to acquire new application software, should it be through continued custom development or by purchasing packages? If packages are involved, should firms integrate separate vendors' products, or should they purchase a comprehensive ERP system? Or, should organizations pursue a combination of custom development, packages, and an ERP system? Recent changes in licensing practices among software package vendors (such as Microsoft) are making upgrades of packages much more expensive. In the case of RMO, it plans to develop custom software and purchase packaged software. The company also plans to integrate several of its key applications. However, RMO has not yet addressed a possible need for ERP. Obviously, the choices are not easy or simple.
system integrator

an individual who is specially trained in integrating application software across various computing platforms
The Trend Toward Packaged Software

As discussed in Chapter 8, custom development may be preferred when a package cannot provide the required functionality. However, current trends appear to favor the packaged software solution. A recent survey reported that during a one-year period, spending on new in-house application development had dropped 34 percent, while spending on software packages had doubled. If this trend continues, how will in-house system development be affected? Obviously, the decision to purchase a software package, in lieu of developing a custom program, can have far-reaching consequences for an organization's information technology (IT) function and for the organization as a whole.

What are the key considerations behind the acquisition of packaged software? First and foremost, an enterprise is concerned with the effectiveness of its information systems. A firm wants quality information to make better business decisions, perhaps to create or sustain a competitive advantage, or just to survive in a turbulent economic environment. Second, an enterprise is concerned with the efficiency associated with both the development and use of its information systems. The efficiency with which a firm creates, operates, and maintains its information systems contributes greatly to its cost of doing business, which ultimately affects its ability to compete or survive. The primary goal of packaged software is both to improve the quality and reduce the cost of information. Whether packaged software actually achieves this two-part goal is debatable.
Implementation and Support of Packaged Software

Chapter 8 introduced the issues of analysis and design when packaged software is part of the solution. The analysis phase defines user requirements for the system. If a package can be found that meets all the critical requirements and the vast majority of the users' preferences, it will be seriously considered. The design phase addresses many more detailed issues, such as what computing platform is required for the package, how users will be trained to use the new package, and how the changeover from the existing system will take place. Such issues actually differ little from those that arise from custom development.

However, three critical considerations of analysis and design are unique to packages: customization, integration, and future upgrades. First, a software package quite often fails to meet all the requirements or preferences identified in the analysis phase. Therefore, the package may require some customization before it is acceptable for installation and use. Second, a software package, as part of a larger system, must often receive data from several systems, either custom or packaged, and provide data to still others. So, the package may require integration with existing legacy applications or databases or with other new packages. Third, a package undoubtedly will undergo at least one upgrade by the vendor during the life of the overall system. Customization, integration, and upgrades of packages must be addressed in planning and analysis, thoroughly planned in design, flawlessly executed in implementation, and continually monitored in support. These relationships are illustrated in Figure 18-3. For example, RMO is planning to acquire accounting/finance and human resources packages. The staff should address the cost of future package upgrades in the planning phase and then must successfully install the upgrades in the support phase. The following sections discuss the three major considerations of packaged software in detail.

Figure 18-3 Three critical issues of packaged software spanning all phases of the SDLC.

[Click to enlarge]
Customizing Packages

Packages are usually designed with the hope that little or no customization will be required, since the best practices of the industry or business function and an abundance of options and features are often built in. However, users may desire to customize a package to meet personal preferences or satisfy unique functional requirements. Since excessive customization can lead to problems later in the systems development life cycle, it should be considered only with foresight and careful planning.

There are three types of customization: configuration, modification, and enhancement. Configuration involves selecting from an assortment of options, such as assembling software modules into a complete system or defining values of parameters in a software package. Configuration can be as simple as changing the format of interfaces to suit a user's preference or adding company-specific details to printed invoices. On the other hand, configuration can be as complex as integrating several different package modules, possibly from different vendors. An in-house developer usually can perform simple configuration tasks through utilities provided with the package. But, the assistance of a package's vendor or an experienced third-party consultant may be needed for more complex configuration, especially in the case of ERP systems.

the process of selecting from an assortment of options, such as assembling software modules into a complete system or defining values of parameters in a software package

Modification of a package involves changing program code to alter the existing form of processing. In many cases, the in-house developer may not have access to the program code of the package. In other cases, the program code may be accessible, but the package vendor may discourage and even fail to support modification. Modifications made to an existing package can cause problems when the user later decides to install an upgraded version.

the process of changing program code to alter the existing form of processing

Enhancement involves adding program code or program modules to provide additional functionality to software. Enhancement does not alter the existing processes in the package—it just adds to them. For example, a comprehensive ERP system may be enhanced with a custom-developed forecasting module.

the process of adding program code or program modules to provide additional functionality to software

Some form of customization is nearly always required for large, complex packaged solutions. Most of the customization involves configuration or enhancement, not modification. Consultants who install ERP systems often extensively configure various modules as requested by the customer. To facilitate the process, a package should support interoperability with legacy and other systems through standards such as COM+, an extension of Microsoft's Distributed Component Object Model, or OMG's Common Object Request Broker Architecture (CORBA). Firms that develop and market packaged solutions usually emphasize creating reusable components that are easily customized by deployment teams.
Integrating Packages

Information systems of the past were implemented primarily as “islands of automation” within functional departments. A company would ordinarily run several different applications in different areas—such as human resources, finance, marketing, manufacturing, and distribution—without giving much thought to shared interests. However, it soon became apparent that an application in one area may need data created by an application in another area. For example, a manufacturing department in Mexico and a distribution facility in Australia may both need sales forecasts produced by the marketing department at corporate headquarters in the United States. Sharing such data often meant the IS department had to create and maintain separate programs to produce data files with specific contents and formats, to mail data tapes overnight when and where needed, to load data into local computers, and then to run the applications. The disadvantages of such an approach to sharing information are obvious.

To improve performance, organizations are attempting to integrate many of their most important applications so that all functions can access needed data in a standardized format in real time. Doing so should improve significantly the efficiency of operations and the effectiveness of decision making. The need for real-time application integration is even greater when firms are seeking to expand into electronic commerce, extend supply chains, compete globally, and enhance customer service. A recent survey reports four major obstacles to integration, as shown in Figure 18-4. Note that the most formidable barriers are technical, resulting from a shortage of knowledgeable system integrators and the difficulty of integrating disparate applications. However, other obstacles (getting executive buy-in and building consensus) are organizational in nature.

The current trend toward sharing data among what were once islands of automation is called enterprise application integration (EAI), the process of linking applications to support the flow of information across multiple business units and IT systems. There are essentially two ways to integrate applications: Use middleware to link individual packages, or purchase a comprehensive ERP package that already has the middleware built in.
enterprise application integration (EAI)

the process of linking applications to support the flow of information across multiple business units and IT systems

As we discussed previously, middleware is special software that sits between different applications and translates and routes data between them. An organization can obtain middleware by purchasing a packaged integration tool or through custom development. A recent survey indicated that as many as 73 percent of large companies are currently involved in real-time application integration using a combination of commercial integration tools and custom coding. Custom development of middleware has its drawbacks, since it is very costly and the resulting programs are very difficult to maintain.

Figure 18-4 Obstacles to integration.

[Click to enlarge]
Upgrading Packages

Software vendors are notorious for releasing frequent upgrades of their packages. An upgrade usually adds functions or makes the software easier to use. Sometimes a new release, or patch, is needed to fix a bug in the previous version of the package. Upgrades are often fairly straightforward for in-house staff or vendors, because the upgrade is designed to be compatible with the previous version. However, when extensive customization and integration have occurred with previous versions at the user's site, upgrades can be particularly challenging. This is why customization and integration must be carefully planned and documented during system development.
Enterprise Resource Planning

The previous section discussed general issues of software packages. Once a package is acquired as part of an information system, it may be customized, integrated, or upgraded within a single function or department of an organization. This section explores information systems that are designed to reach beyond the needs of a single department. The goal of such systems is to improve the operation and competitiveness of an entire organization. Such software is at the hub of ERP. This section explores what ERP is, why firms choose ERP, how ERP is implemented, and how ERP functions.

RMO plans to integrate its customer support system, inventory management system, and retail store system, but it has not addressed whether to integrate these systems with its new accounting/finance and human resources packages. Successfully doing so would essentially constitute an ERP system.
ERP and the Business Environment

Many organizations today have turned to ERP to help them compete locally and globally in the electronic marketplace. Such well-known firms as Boeing and Federal Express have implemented ERP systems for both traditional and Internet applications. Organizations worldwide are continuing to spend tens of billions of dollars on ERP in an attempt to replace outdated legacy systems, integrate applications, save on IT costs, and achieve competitive advantage. Figure 18-5 illustrates the basic differences between nonintegrated systems and systems integrated using ERP: In the former, only one function segregates and accesses data; in the latter, all functions can quickly and easily share a common database. With today's global organizations and widespread Internet use, ERP offers extraordinary advantages due to the tight integration of systems and easy accessibility to employees, customers, and strategic partners. Spending on ERP systems is expected to grow substantially in the new millennium, fueled by expansion into areas such as customer relationship management (CRM) and supply chain management (SCM). However, ERP implementation is not without its challenges.

Figure 18-5 (a) Nonintegrated IS.(b) Integrated IS in an ERP system.

[Click to enlarge]
Objectives of ERP

ERP is designed to provide best practice functionality within departments and a high level of integration across all enterprise functions, such as human resources, finance, and manufacturing. Not only is ERP designed to integrate functions, but it is also designed to integrate organizational units, such as plants and divisions, across the country or around the world. Going one step further, ERP is capable of integrating previously separate and independent organizations—that is, integrating a firm with its suppliers and customers. Thus, ERP is intended to help integrate the entire value chain, the sequence of all processes within (and possibly between) organizations that adds value to the product or service.
value chain

the sequence of all processes within an organization that add value to a product or service offered

Additionally, ERP can bridge the gaps in the value chain in real time, making critical data available to a host of different users (inside or outside the firm) exactly when needed. Thus, ERP is designed to break down significant barriers of function, space, and time. RMO could use ERP to link its financial, human resource, manufacturing, inventory, retail, and distribution systems. Managers could instantly see sales and inventory at the Park City and Denver retail outlets or examine the performance of mail-order, phone-order, or Internet sales. ERP could tie manufacturing plants in Salt Lake City and Portland directly to all these sales systems and to the inventory systems for the Salt Lake City, Portland, and Albuquerque distribution centers. To plan the training and movement of personnel within the various manufacturing, distribution, and sales functions, RMO could integrate these functions with the human resource system and instantly update the bottom line by integrating all these systems with the financial system. An ERP approach to doing business can be a powerful competitive weapon.
ERP and Business Information Systems

As discussed in Chapter 1, there are many types of business information systems within organizations, including transaction processing systems (TPS), management information systems (MIS), and decision support systems (DSS). ERP is often used first to integrate the core TPSs in human resources, finance, and manufacturing and later to integrate the MISs and DSSs of various departments. Not only does ERP integrate functional departments, but it does so on-line in real time, not a day or week later. ERP can span functional departments within a single facility as well as geographical boundaries of large, multinational corporations. It can also reach beyond the boundaries of a firm to include external suppliers and customers in the information system, further extending the firm's supply chain. These aspects of ERP are illustrated in Figure 18-6. The integrated, real-time, global, and extended characteristics of the information obtained through the TPS of an ERP system make the MIS and DSS of the organization more valuable. Through ERP, the firm can make faster and better decisions to become more effective, efficient, and, ultimately, competitive.

Figure 18-6 Four major characteristics of an ERP system.

[Click to enlarge]
Major ERP Vendors

The major players in the packaged ERP market are (in descending market-share order) SAP AG, Oracle, PeopleSoft, SAGE, and Microsoft Business Solutions. But SAP AG represents more than three and one-half times the share of its next leading competitor. These companies have exhibited phenomenal growth in recent years, although that growth now appears to be slowing or even declining due to the state of the economy in general and published reports of failed implementations. These ERP vendors began offering integrated packages for managing the three core business functions: finance, manufacturing, and human resources. Recently, they have expanded by offering added functions in the following areas: customer relationship management (meeting the needs of all customers from initial inquiry to support after the sale), supply chain management (managing all resources and processes involved from raw-material acquisition to finished goods delivery), sales-force automation (helping sales personnel to service customer accounts), e-commerce (buying and selling goods and services on the Internet, especially the World Wide Web), and business intelligence (acquiring and using information designed to improve competitiveness).
sales-force automation

processes that make it easier for sales personnel to service customer accounts
business intelligence

the acquisition and use of information designed to improve competitive advantage
Why Consider ERP?

The changing climate of business and advances in information technology are leading many firms away from the legacy systems of the past and toward the packaged systems of today. The recent increases in mergers, government deregulation, and globalization have pressured firms to search for new ways to compete. These competitive measures include total quality management (TQM), the process of achieving the highest levels of quality throughout the entire organization, and business process reengineering (BPR), radical, large-scale improvements in business processes to improve efficiency and effectiveness significantly. Also, recent advancements in client-server technology, object-orientation, telecommunications, and the Internet have opened new opportunities for applying software solutions to business problems. All these changes have combined to open the door for advanced software packages to take over wherever homespun legacy systems may be falling short.
total quality management (TQM)

the process of achieving the highest levels of quality throughout the entire organization
Reasons for Implementing ERP

Firms are constantly looking for ways to survive and thrive in a complex competitive environment. Many firms are losing their competitive edge by relying on obsolete systems. From a broad perspective, there are several reasons that firms are turning to ERP. First, many believe that information technology (IT) is an excellent way to enhance their competitiveness. They may, however, question their ability or desire to continue to maintain a staff that is expert in all areas of increasingly complex technologies. ERP is one means of updating a firm's information systems without investing in costly inhouse software development. Second, some firms go beyond the goal of simply improving IT and subscribe to the philosophy of business process reengineering. These firms may choose to implement ERP and reengineer their processes to match the model of the ERP system. Third, reorganization through mergers or expansion into global markets has motivated some firms to integrate geographically dispersed systems within one ERP system. All these reasons essentially point to the need to replace outdated technologies.

From a business's perspective, there are several reasons to embrace ERP. Based on several case studies, the most common reasons given for ERP projects in major companies are:

* Reducing the workforce in core transaction processing systems (such as order processing and inventory management) by eliminating manual tasks and duplication
* Supporting global business operations (such as having one order-processing system for all customers worldwide)
* Achieving economies of scale by replacing division-level systems (such as replacing plantwide purchasing with corporatewide purchasing)
* Improving communication and information exchange among departments
* Reducing information system development staff by using packaged solutions
* Improving customer service through better logistics based on more complete and accessible information
* Improving data integrity through a common database
* Improving decision support via more timely reports and drill-down capability

Of course, some firms are moving toward ERP simply because they desire to keep pace with competitors that have already done so.
Costs and Benefits

Investing in an ERP package may cost upwards of $5 million for a midsize firm (one with annual sales of about $200 million to $1 billion) and upwards of $50 million for a large corporation (one with annual sales exceeding $1 billion). Midsize firms can expect implementation to take up to two years to complete; it takes several more years for a large firm. The cost of the software itself is usually very competitive among the major vendors, but the cost of consulting services can be quite high, primarily due to the shortage of qualified people. The payback is usually estimated to take between 6 and 30 months, depending on the size and complexity of the system. Vendors usually estimate a 30 percent reduction in administrative and information systems costs. Payback can also be calculated in terms of the ability to continue to compete in the long term against firms that are currently upgrading their information systems with ERP. An enterprise should be able to generate revenue more effectively by providing better data more quickly for decision support, by creating products at lower cost, and by offering better service to suppliers and customers.

A firm must ultimately gauge its need for ERP by comparing the current information system with the proposed ERP system. The annual cost of operation and maintenance of the existing system should be compared with the initial cost of installing the ERP system plus its annual cost of operation and maintenance. Although benefits are difficult to quantify, the ERP system should add to revenue by enabling better and faster decisions and providing better customer service. RMO may be unable to survive in the highly competitive outerwear industry without extremely fast, effective, and integrated information systems, such as those provided by ERP.
Implementing ERP

Since ERP systems are so complex and they affect the entire organization, it is critical to implement them systematically and carefully. So, what are the factors that can help ensure success?
Critical Success Factors of ERP

ERP projects can be extremely complex, time-consuming, and expensive, and there are always high levels of risk involved in overhauling an information system. Based on several case studies to date, some of the most critical factors for successful implementation are:

* A realistic ERP budget and proper allocation of resources (hardware, software, people, knowledge, and tools)
* Education of all key management personnel about ERP and consensus that ERP is really needed
* Strong top management support
* Centralized project management with a business leader (as opposed to an IT leader) in charge
* Strong IT management and staff support
* Selection of the right approach to ERP
* Heavy user involvement (from all affected areas) in project management and implementation
* Business process reengineering to standardize on the capabilities of the software, rather than customization of the software to existing business processes
* Retraining of existing software developers in ERP implementation and maintenance
* Extensive training of end users in the new system
* Use of consultants (knowledgeable in specific business functions and experienced in specific ERP modules) to lead in implementation and training
* A respected and effective champion for ERP within the organization
* Effective and continuous communication among all parties involved in the ERP project
* Top-notch systems analysts with excellent business knowledge and technical skills
* Retention of top-notch systems analysts throughout the project and beyond
* Sensitivity to user resistance to new systems

Approaches to ERP

In addition to recognizing the critical success factors for ERP implementation, an organization should understand that there are essentially three approaches to ERP Figure 18-7. One option is to purchase a comprehensive packaged system, such as those offered by the leading ERP vendors. Such systems attempt to cover the information needs of all critical business functions (finance, manufacturing, human resources, marketing, and distribution). This approach may be best for the enterprise as a whole, but some modules for certain departments may lack needed functions. The comprehensive package may also not be flexible enough to accommodate rapid changes that the firm needs to undergo to compete.

Figure 18-7 Three approaches to ERP.

[Click to enlarge]

A second approach is known as best-of-breed, in which an organization selects the presumed best available software (custom or packaged) for a particular application (such as production scheduling or e-commerce) and integrates it with other best-of-breed solutions in other functional areas. This approach provides individual functions or departments with the latest and greatest software solution. Although each business function may be extremely well served under the best-of-breed approach, the company as a whole may suffer due to a lack of integration, since disparate packages cannot often be integrated easily. However, the availability of middleware can make best-of-breed a viable option. With the use of middleware and a skilled systems integrator (either an in-house developer or a consultant), functional areas can use the best software for their application and still share important data with other functions in the firm. Currently, RMO is banking on this approach by purchasing packages for accounting/finance and human resources; developing its own systems for customer support, inventory management, and retail stores; and integrating the latter three systems.

a software package developed for a particular application that is usually considered to incorporate the most current and best practices within the industry

A third approach is a hybrid of the comprehensive package and best-of-breed approaches. A particular comprehensive package may have many desirable features but may not provide all the functionality an organization needs. For example, a firm may choose a well-known ERP vendor to provide a backbone system for human resources, manufacturing, and finance but plug in various best-of-breed solutions for supply chain or sales forecasting applications. Instead of connecting many best-of-breed applications, the firm limits the number of applications it must link to the ERP backbone system, thus simplifying integration. The hybrid approach may be necessary if a company cannot afford to modify certain key business processes significantly to fit the process supported by a comprehensive package. The hybrid approach is also recommended if a firm must develop its own software in certain areas to provide unique effectiveness and to achieve a competitive edge. The firm can add this custom software to the package of core applications that provide basic efficiencies.
Organizational Structure for an ERP Project

Chapter 3 discussed the roles and responsibilities of the oversight committee and project teams for a system development project. The same principles of project management apply to an ERP project. Since ERP would usually be considered mission critical, an oversight committee, consisting of clients and key executives, should be formed. The members of the committee should represent all functions affected by ERP—finance, marketing, human resources, manufacturing, distribution, engineering, and information systems.

The project team usually consists of in-house IS personnel (managers, analysts, programmers, and technical specialists) and key in-house users. For an ERP project, the team might add vendor representatives and consultants because of the complexity of ERP software. In-house IS personnel must often be hired and trained to help ensure successful implementation. With the comprehensive package approach, the focus of IS personnel is on understanding, implementing, and supporting the system. Under the best-of-breed approach, IS personnel need a better understanding of how to create custom middleware or use packaged middleware to integrate the application packages. A hybrid approach requires both an understanding of the comprehensive package and of middleware. System users should also be educated and trained in all aspects of ERP that affect their jobs.

Since ERP projects are often large and extensive, an organization should provide comfortable meeting rooms to accommodate committee and team meetings; workspaces for project managers, team members, and consultants; computers, telephones, desks, chairs, bookshelves, and file cabinets; and administrative support to make arrangements for travel, lodging, meals, and meetings. A hypothetical organizational structure for an ERP project is provided in Figure 18-8.

RMO, with its $100 million annual sales, would be considered a small company. If RMO considers an ERP project, the oversight committee would consist of its president and three vice presidents. The project team could include the assistant vice president of production, director of operations, director of catalog sales, assistant vice president of accounting and finance, and assistant vice president of systems. Various workgroups could include systems personnel and managers and operators from manufacturing, distribution, purchasing, warehousing, retail sales, telephone sales, human resources, and accounting. The project team and workgroups could also include vendor representatives and consultants.

Figure 18-8 Organizational structure for an ERP project.

[Click to enlarge]
An ERP System Development Methodology

There are many horror stories of failed attempts to implement ERP packages, regardless of vendor. Such failures are usually due to poor project management. As with any other system development project, a well-defined methodology is essential for successful implementation and continued, problem-free operation. The systems development life cycle, presented in Chapter 2, is just as applicable to a comprehensive or best-of-breed ERP system as to any custom-developed system. An ERP project differs from a more typical system development project in two important ways. First, an ERP project has a much greater scope than a typical project, involving virtually every function or department in the organization. Second, the ERP project often uses packaged software extensively, either a comprehensive package or several best-of-breed packages, instead of custom software. These important differences affect the systems development life cycle in many ways.
Phase 1: Planning

An oversight committee is formed to initiate the project. The primary task of the oversight committee is to identify the general purpose and overall scope of the ERP project and to appoint a project manager and project team members to develop the system.

The project team clearly defines the problem to be addressed by the ERP system and determines the detailed scope of the project. The team must then evaluate alternative approaches to ERP—custom solution, comprehensive package, integrated best-of-breed packages, or some combination—and make at least an initial selection. After selecting an approach, the project team develops a proposed project schedule and budget, addresses feasibility, and presents its findings to the oversight committee, both orally and in writing.
Phase 2: Analysis

Once the analysis phase has been reached, the oversight committee has decided to proceed with the project and has probably committed to a specific approach. However, specific vendors have not yet been selected. The project team begins creating workgroups within the different functions of the organization to gather information and define requirements. In-house IS personnel or outside consultants may be employed to assist the workgroups in this effort.

After all requirements have been defined, a major responsibility of the project team is to evaluate the vendors that could meet the requirements and to make its recommendation to the oversight committee. A comprehensive package approach requires evaluation of the major vendors. A best-of-breed package approach requires evaluating several competing packages for a given function or department. A custom approach may require the evaluation of only a few software development tools. (Keep in mind that a typical ERP project could involve all three approaches simultaneously.) The oversight committee makes the final vendor selections. Details on vendor evaluation are presented later.

Another major responsibility of the project team during analysis is to identify any business process reengineering (BPR) initiatives that will be required, based on the selection of software packages. Again, workgroups within various functions may be involved in the step. The amount and type of BPR may depend on the ERP approach and packages selected.

Although doing so is not highly recommended, a firm may choose to change a package-instead of changing its business procedures. During analysis, the team determines areas where such customization is most likely to occur and their impact on project schedule and cost.

Once a vendor or vendors have been selected, their representatives and possibly new consultants may be added to the analysis process. If a comprehensive package is selected, the oversight committee and project team members should receive intensive training in its purpose and operation. If several best-of-breed packages are chosen, then committee and team members representing certain functions should receive training on the respective packages. If custom development is involved, technical specialists should begin training on the specific tools to be used.

Finally, prototype ERP systems may be developed in all areas to demonstrate the integration of modules to users and further refine requirements. At this point, the alternatives considered earlier (that is, which ERP approach and which ERP vendor) are revisited and reevaluated. The project team may swing from comprehensive package to best-of-breed, or from one vendor to another. If so, the project team presents its recommendations, written and orally to the oversight committee for approval and continuation.

The analysis phase should take less time with a comprehensive package approach and more time with a custom development approach. Regardless of the approach, however, analysis for an ERP project usually takes much longer than for a stand-alone system serving only one department or function.
Phase 3: Design

The design phase begins after the final selection of an ERP vendor. The extent of the design depends on the ERP approach. If packages are chosen, user interfaces are largely predetermined, although some minor customization may be desired. The design of user interfaces would be most extensive under a custom approach. Comprehensive packages usually require minimal use of middleware since they need to interface with only a few legacy systems or third-party packages. The best-of-breed approach may require complex system interface design since many different packages must communicate. A custom approach would require a normal degree of system interface design.

Designing applications, prototypes, and databases is very involved under a custom approach, minimal for a comprehensive approach, and somewhere in between for a best-of-breed approach. Prototype development is highly beneficial to continue the refinement of requirements, even when using a comprehensive package.

Hardware design is very important in ERP systems since several business functions will share many resources. A distributed client-server architecture may be more suitable than an existing mainframe system because networks may connect departments, buildings, or cities in the new system. Also, certain vendors' software may be designed to run on platforms not currently in use.

End users should receive intensive training in ERP packages during the design phase. In addition to preparing users for the new system, training helps refine requirements during prototyping and makes it easier to reach design decisions.

During design, the project team fleshes out more of the details of BPR. From a process perspective, new procedures for business activities are documented. For personnel, the team creates new job descriptions and makes plans to reorganize and retool the workforce, especially for those whose jobs are changing dramatically.
Phase 4: Implementation

When custom software is chosen, this subphase is known as construction. However, for a comprehensive package, programs are already constructed in modules for such functions as accounts payable, purchasing, and inventory control. Yet modules do vary based on the type of business process used (for example, discrete versus continuous manufacturing). Such modules must be configured into a cohesive system. With best-of-breed packages, the project team must use middleware to integrate programs from different vendors. With comprehensive or best-of-breed packages, integration of new components with legacy components takes priority. For example, existing data may need to be reformatted for compatibility with new programs.

Once team members have configured and integrated modules with other programs and components, the remaining subphases of implementation are very similar to those of a conventional custom software project. First, a prototype of the system is usually created, validated over several iterations, and revised until a production-ready system is obtained. Second, the completed system is thoroughly verified and tested, then tuned for performance. Third, the system is thoroughly documented and end users receive final training. Finally, the new system is installed throughout the organization according to the rollout plan created during the design phase (pilot implementation, parallel implementation, or total cutover).

During the implementation phase, the project team implements BPR changes. Since hardware, software, data, and networks have already been implemented, the only components of the new system that remain are people and procedures. Organizational structures are changed, placing personnel in their new positions. The new procedures, in which all personnel have been previously trained, are also implemented.
Phase 5: Support

The purpose of this phase is to ensure the short-term and long-term success of the new system. End-user support is critical for such an enterprisewide, integrated system. Extensive training can prevent catastrophes, but a certain degree of ongoing staff support is necessary with such a drastic, comprehensive change. A well-staffed and well-managed help desk should help to ensure a smooth transition.

Maintenance of the ERP system is also a key element of success. Corrective maintenance fixes bugs that users discover, but extreme care taken in analysis, design, and implementation should minimize these bugs. When they do occur, rapid response by knowledgeable consultants will ensure good public relations. Adaptive maintenance is needed when current versions of packages are upgraded or when comprehensive package modules, best-of-breed packages, or custom software programs are added or removed to meet changing requirements. Perfective maintenance may be needed to fine-tune the system for optimal performance. A system audit could be undertaken periodically to determine whether the objectives of the ERP system are being achieved.
Special Topics in ERP Development

Now that we have presented general ERP system development methodology, we turn to some details critical to ERP development: selecting a comprehensive package, customizing a package, linking applications within a system, and using packages for application development.
Selecting a Comprehensive ERP Package

Guidelines for selecting individual software packages were presented earlier in Chapter 8. But a firm has additional considerations when it is contemplating the purchase of a comprehensive ERP package. Both the costs and the risks are much higher, so the selection process should be thorough. Following are some detailed steps for evaluating comprehensive packages.

Step 1: Preliminary Evaluation To begin, a firm evaluates ERP packages by looking at broad, general requirements. Four or five packages are typically considered at this preliminary stage. The decision makers could be members of the project team or the oversight committee, depending on a firm's management style. Package vendors and consultants may both be involved to provide needed information. Independent sources of information such as trade journals and personal contacts can provide insight also. Some of the key items to consider in a preliminary evaluation of an ERP package follow:

* Critical functionality, such as ability to deal with multiple currencies, to do simulations, and to support e-commerce.
* Up-front cost of the package. Initial quotes may vary widely among vendors, but they are often willing to negotiate.
* Cost of ongoing support for the package (upgrades, add-ons, and so on).
* The long-term viability of the vendor. How long will the company be around?
* The fit between the business model of the package and the actual business processes of the firm. Often it is easier for a firm to consider reengineering its processes before significantly altering the software.
* Satisfactory, guaranteed implementation time.
* A sizable installed base (at least 20 successful installations) so the firm is not one of the “guinea pigs.”
* Local support (in multiple countries, if applicable) with a guaranteed, acceptable level of service.
* Proven success in the international environment (if applicable).
* Availability of customization tools to bolt on third-party packages or link to legacy systems.
* The best accommodation of the firm's management style (for example, whether the firm prefers to see the big picture or to drill down to detailed data).

Sometimes, a given package exhibits what may be called a showstopper —a missing feature or unsupported business process that transforms an otherwise good fit into a complete mismatch.

The result of this preliminary evaluation is a short list of perhaps two competing ERP packages.

Step 2: Detailed Evaluation Once the field of packages is narrowed, lower-level managers, staff, or even operating personnel may assist in the selection process through meetings or workshops. Such workshops could be organized by major function (for example, finance or manufacturing) or by department (such as accounts payable within finance or production scheduling within manufacturing) to consider detailed evaluation criteria, based on information from vendors and advice from consultants. Just a few examples of the detailed criteria are the package's ability to accomplish the following:

* Set prices according to different criteria
* Provide financial information in multiple currencies
* Control commissions of sales representatives
* Support just-in-time (JIT) production

Such workshops provide two important benefits. First, staff can determine the candidate's ability to address both mandatory and optional functionality. Second, users of the new system are involved in the evaluation process, which increases their understanding and acceptance of the package and ERP in general. The results of the detailed evaluation process should also be documented.

Step 3: Vendor Presentations After the detailed selection criteria have been applied to all candidate ERP packages, the project team can schedule vendor presentations for both the oversight committee and for the lower-level managers, staff, and operators. Both the form and substance of these presentations can assist staff in making the final recommendation.

Step 4: On-Site Visits An additional evaluation method is on-site visits to different-firms that use the packages under consideration. The names of such firms may be supplied by the vendor or, better yet, uncovered by the project team. During an on-site visit, information about the quality and quantity of vendor support, the amount of customization required for the package, the performance and reliability of the software, requirements for hardware and additional software, and implementation time can be obtained and added to the set of evaluation criteria.

Step 5: The Final Decision After all previous steps have been completed, the project-team usually performs a formal and structured evaluation based on (1) weights assigned to the criteria and (2) vendor scores on these criteria. The result is a total weighted score for each ERP candidate. Other factors may also influence the decision, especially where total scores are extremely close. One vendor may have a very high total score but may also have one glaring weakness that could make the package unsuitable. Intangible factors may also come into play. Whatever the considerations, the project team must select a vendor to continue the project. Consensus helps ensure the future success of the project. The project team's recommendation of a vendor is usually submitted to the oversight committee for final approval.
Linking Applications to an ERP Package

A popular approach to ERP is the hybrid approach: implementing a comprehensive ERP package from a major vendor and “bolting on” various best-of-breed software solutions to the main ERP backbone. One strategy for increasing success with a hybrid approach is to select a package that is already partnered with the ERP vendor. However, true partnering implies actual shared development, not just joint marketing, to ensure that the applications will work together smoothly.

Once a best-of-breed package is selected, some firms have the vendor integrate the package with the ERP system. Other firms have their own developers create the interfaces between the ERP system and the third-party application, often using tools provided by the third party. This approach gives the organization more control and the ability to test the links thoroughly.

An alternative to creating interfaces is purchasing enterprise application integration (EAI) tools to produce middleware. Since this technology is relatively new, a team must carefully select a middleware vendor. An additional strategy is to hire a third-party consultant with experience in the industry and its applications to oversee the integration.
Using ERP Packages for Application Development

One potential advantage of a comprehensive ERP package approach is that the package can serve as a platform for continued application development and integration. Project teams can extend functions by incorporating custom code to meet special requirements not provided by the package. A number of software vendors, including the major ERP package vendors, provide tools ranging from high-end development environments to specialized integration technologies. For example, SAP offers connectors to such tools as IBM's WebSphere Studio and Microsoft's Visual Studio to make it easier to link, for example, a Visual Basic application to SAP R/3. Other vendors have built their ERP packages using certain fourth-generation language (4GL) tools (tools that utilize natural language commands), making it easier for the customer to use the same tool to create custom applications.

This approach to application development is certainly not traditional. Developers in an ERP environment often become system integrators, adding new packages to the ERP framework or extending the functionality of an ERP application through custom development. However, linking custom applications to ERP packages is complex since many such packages were not developed using standard architectures and because much of the ERP package's inner workings may be proprietary. Also, many of the application development tools currently offered by the major vendors are seriously lacking. For example, a given package may include a low-level programming language and may reveal its underlying data schema, but it may not provide the testing and debugging functionality that developers have come to expect. Using an ERP package for true application development is, therefore, still a distant dream.
The Future of ERP

ERP systems were originally intended to integrate the information systems of departments in an organization to drive down costs. As many firms have largely accomplished these objectives, they are looking for new integration capabilities beyond the walls of the factory or corporate headquarters. The major areas of expansion for ERP systems that are currently undergoing rapid development and growth are supply chain management, business intelligence, and application service providers (ASPs).
Supply Chain Management

Companies compete by supplying high-quality products and services faster and cheaper through superior management of materials, information, cash, and work processes. By integrating each functional area into a comprehensive strategy, an organization can address the key issues of cost, speed, complexity, flexibility, and customer needs. An ERP platform is ideal for driving down costs and improving response along the entire supply chain, from raw materials to finished goods.

The supply chain has three major links: suppliers, in-house processes, and customers. Suppliers and customers can be linked to the firm's ERP system via e-commerce. In-house processes are improved through the integrated, real-time, and global characteristics of an ERP system. One often-overlooked way that ERP can accomplish better response to demand is through improved human resource management. Internal human resources are an extremely vital link in any supply chain. HR management is more than just handing out paychecks or helping an employee navigate through a cafeteria-style benefit plan. An ERP system can, for example, provide intranet-based learning to employees and maintain information on employee skills to determine the best way to deploy the workforce to meet rapidly changing requirements. At present, RMO has no plans to integrate its HR package with other systems, but perhaps it should reconsider.
Business Intelligence

Businesses can collect all types of information on customers, operations, competitors, products, and employees, into what is often called a data warehouse. However, the key to using this information for competitive advantage is integrating it into a robust decision-support tool. ERP systems often provide such tools, helping a firm to identify strengths, pinpoint weaknesses, uncover new opportunities, and capitalize on trends by combining historical and predictive views of its performance with information about the business. RMO could capitalize on such business intelligence applications since it is in the highly competitive retail sales industry.
Application Service Providers

An application service provider (ASP) is a firm that delivers software applications to a client over a network, usually the Internet. Clients do not hold a license to the application software, nor do they need to invest in server hardware or software. The burden of installing, configuring, and updating the software, such as an ERP or CRM package, rests with the ASP. The client purchases the service for a monthly or yearly fee or on a per-use basis. The advantages of using ASPs include lower start-up costs, less time to put the system into production, and less cost to keep the system running (due to the economies of supplying the software to many clients). Significant disadvantages exist as well. Using an ASP means that someone else may have access to your sensitive company data. Accessing the system over a busy network or the Internet can also reduce response time. The ASP may provide only basic ERP functionality to keep its costs down. Finally, the ASP may know the ERP or CRM system very well but not the unique needs of a business. As with any emerging software market segment, economic downturns and fierce competition can result in instability, so clients should be very careful before entering into long-term relationships with ASPs.
A Hypothetical ERP Scenario

An ideal scenario, enabled by an integrated, real-time, global, extended ERP system, could go something like this:

1. A consumer orders a car (or major appliance, computer, books, clothing, or so on) at home from a Web-based retailer.
2. The retailer's Web-based order-entry system is also linked to one or more banks to provide the consumer with on-line loan approval.
3. The banks' loan approval systems are linked to one or more credit bureaus' expert systems to determine the creditworthiness of the individual and the appropriate interest rate and term of the loan.
4. Upon approval, the consumer's order of the product automatically triggers a shipping order at the distributor to deliver the goods.
5. The shipping order at the distributor automatically triggers an assembly order at the assembly plant to replace the shipped item in inventory.
6. The assembly order at the assembly plant automatically triggers subassembly orders at sister plants.
7. The subassembly orders at the sister plants automatically trigger inventory withdrawals.
8. The inventory withdrawals at the subassembly plants automatically trigger purchase orders directed to their suppliers of raw materials.
9. The purchase orders at the raw materials plants automatically trigger shipping orders, inventory withdrawals, production orders, purchase orders, and so on.

This entire hypothetical process could actually take only a few minutes (or seconds) in real time, linking the customer's order backward through the value chain to the most basic raw materials, using ERP and computer networking technologies. The rapid, real-time response of the ERP system helps to ensure a smooth, constant flow of goods and materials, minimizing the need for excessive inventories and providing excellent customer service as well. Firms that use ERP systems to their fullest capabilities could gain significant competitive advantage in the marketplace of the future.
A Closer Look at One ERP Package: SAP R/3

The first part of this chapter discussed packaged software in general, and then discussed packaged software in the context of ERP. This section examines a particular ERP package, SAP R/3. The purpose of this section is not to empower you to become an SAP consultant but simply to provide a better understanding and appreciation of ERP systems through the exploration of SAP R/3.
What Is SAP?

SAP AG is a German software development firm Figure 18-9) that created and markets the SAP R/3 enterprise resource planning system. SAP (pronounced S-A-P, not “sap”) began creating software in 1972. In 1983, it introduced the R/2 (meaning real-time system, version 2) system of integrated business application software for mainframe architectures. In 1989, SAP AG released SAP R/3, which utilized the increasingly popular client-server architecture and relational database technologies. SAP is currently the third-largest software vendor in the world and by far the market leader in ERP systems. There are now more than 60,000 installations of SAP in over 120 countries.

Figure 18-9 SAP's home page.

[Click to enlarge]

ERP systems are perhaps the most complicated information systems that a firm can implement, and SAP R/3 is considered to be the most complex ERP system available. SAP R/3 requires more than 15 gigabytes of disk space just to install and contains nearly 10 million lines of code. At, you can find an almost dizzying array of products, technologies, and services for small, medium, and large organizations, including the basic SAP R/3 solution, SAP R/3 Enterprise, and mySAP Business Suite. Although the complexity of SAP R/3 provides it with a high degree of flexibility and utility, it also makes for challenging implementation.
Organization of SAP R/3

Implementation of SAP R/3 within a company consists of a set of modules tailored to the needs of the enterprise. Tailoring means configuring several related application modules, not modifying or enhancing existing code. The modules within SAP R/3 are organized into four high-level work areas:

* Logistics
* Accounting
* Human Resources
* Business Tools

The first three areas represent the major functional groupings within most enterprises. Within Logistics are functions such as Materials Management, Production Scheduling, and Plant Maintenance. The Accounting area contains modules such as Financial Accounting, Controlling, and Project Management. Under the Human Resources area are modules such as Personnel Administration, Payroll, and Benefits. Not every firm, however, would choose to implement all available modules in these three areas. The Business Tools area provides the systems integrator the means to perform R/3 system installation and administration, including configuration and programming activities.

SAP R/3's integrated software modules are designed to meet information needs across the entire enterprise. The modules selected by a given firm become its SAP R/3 configuration. A firm just starting out with SAP R/3 may choose to implement only the core modules: Financial Accounting, Sales and Distribution, Materials Management, and Production Planning. After a firm successfully implements and uses these modules, it may choose to add others over time, such as Controlling, Warehouse Management, Plant Maintenance, Quality Management, Project System, Treasury Management, and Asset Management.
SAP Industry Solutions

SAP R/3 is a highly configurable system designed to meet the ERP needs of a wide variety of industrial segments. The SAP system includes the basic core functionality common to most organizations: finance, human resources, and logistics. To better serve the needs of different industries, SAP has created Industrial Business Units (IBUs) to provide system solutions for nearly two dozen distinct industries, based on what are generally considered “best practices.” A brief overview of some of these industry-specific solutions can provide a better understanding of how SAP R/3 may be applied:

* The automotive industry. SAP's solution for the automotive industry includes a customer-pulled supply chain and a global infrastructure for the value chain, including component suppliers, after-market parts suppliers, and wholesalers. Additional functionality includes flow manufacturing, Kanban, shipping scheduling, and global available-to-promise capability.
* The electronics industry. Time to market is a key to success in this industry. New products with high quality and low prices are in demand. A real-time, integrated system can provide many benefits. SAP R/3 offers product data configuration management, configure-to-order quoting and estimating, product data management, bill of material, and routing development. The SAP High-Tech module provides a knowledge- and rule-based product configuration engine to forecast and monitor dynamic pricing and supply scenarios.
* The public sector industry. Public organizations should operate as efficiently and effectively as private enterprises. The SAP solution for this industry includes a Human Resources module that provides employee self-service (ESS), benefits administration, and event management capabilities, among others. The Purchasing and Materials Management module enables automatic day-to-day purchasing, supplier selection, and electronic data interchange (EDI).
* The retail industry. This industry is characterized by a wide variety of distribution possibilities (including walk-in traffic, catalog sales, and e-commerce) and small margins. Retailers must carefully manage inventory and monitor customer preferences. SAP provides Merchandise Logistics Tools to track customer buying behavior. The Retail module includes software for goods receipt, labeling, inventory management, and promotions management. RMO falls within this category and would be most interested in SAP's offerings within this IBU.

Other SAP IBUs include insurance, telecommunications, aerospace and defense, banking, chemicals, consumer products, health care, oil and gas, pharmaceuticals, and utilities. Obviously, SAP is endeavoring to tailor its ERP system to an extremely wide variety of business applications.
Master Data

The SAP R/3 system revolves around several standardized databases utilized by various application programs Figure 18-10. At the core of SAP R/3 are five master databases: the Material Master, the Vendor Master, the Customer Master, the Human Resources Master, and the General Ledger. The Material Master is used to store data relating to all materials tracked in the system. Logistics modules such as Materials Management, Sales and Distribution, Production Planning, Plant Maintenance, and Quality Management use these data. Materials within a firm are defined in SAP R/3 as one of several types, such as Finished Products, Semi-Finished Products, Raw Materials, Operating Supplies, and Packaging. The types of fields associated with an item of material may include material number, unit of measure, procurement type, temperature conditions, shelf life, and price.

Figure 18-10 The five master databases for SAP R/3.

[Click to enlarge]

The Vendor Master contains information about external suppliers, such as address, telephone, tax codes, bank accounts, payment terms, and order currencies. The Customer Master stores data about a firm's business partners that buy products or services. Customers may be one of several types, including sold-to partners, ship-to partners, payers, or bill-to partners. For example, when you buy a gift for a friend, you may be the sold-to partner, your friend may be the ship-to partner, and your credit-card company may be the payer. All the information associated with these various parties—such as names, goods receiving hours, preferred shipping method, payment terms, and tax classifications—must be stored in the Vendor Master.

The Human Resources Master contains information about a firm's employees. This information is stored in various infotypes—logical groupings of similar data fields. For example, the Personal Data infotype contains name, birth date, marital status, and number of children. The Address infotype consists of various subtypes such as Permanent, Temporary, and Mailing. The Events infotype tracks important events for an employee, such as hire date, pay change, or change in organizational assignment.

The General Ledger accounts are the backbone of the entire SAP system and are used to produce reports to meet legal requirements. These accounts reflect all transactions that affect external reporting requirements. For example, billing a customer will increase the receivables account, and shipping an item will reduce the inventory account.
Implementing SAP R/3

As mentioned earlier, implementing SAP R/3 can be complex and time-consuming. This section highlights general issues of architecture, middleware, configuration, and accelerated installation.
Architecture of SAP R/3

The R/3 system is designed for a three-tier client-server architecture Figure 18-11. The three tiers, or levels, are presentation, application, and database. The user of R/3 works on a client machine at the presentation level with SAPGUI (SAP graphical user interface) software, enabling the user to work in a familiar Windows environment. Through SAPGUI, the user sends and receives data from what is called R/3 System software on various SAP application servers. It is at this application level that specific modules, such as Payroll or Materials Management, function. The R/3 System at the application level communicates with myriad SAP data tables within a relational database management system (RDBMS) on a database server. The language SAP applications use to interface with the RDBMS is standard SQL.

Figure 18-11 The three-tier architecture of SAP R/3.

[Click to enlarge]
R/3 Basis

R/3 Basis is the middleware that enables the integration of various SAP R/3 application programs on various computing platforms. Basis also provides R/3 administration tools (the data dictionary and the function library). Basis allows the R/3 system to run on a variety of platforms (such as AS/400, UNIX, or Windows NT) and to utilize different database systems (such as Oracle or DB2). Basis controls three different types of interfaces: user, programming, and communications.

The user interface is a graphical user interface (GUI) that makes work easier for users, developers, and administrators. For example, a developer may use the GUI of the data dictionary to create a table by pointing and clicking, rather than using SQL directly. The programming interface utilizes the ABAP/4 Development Workbench, which is required to create or change database tables and programs in the R/3 system. The communications interface provides the link among internal programs, as well as between R/3 and third-party programs. SAP uses standard relational database technology to store all three types of R/3 data: master, transactional, and configuration.
Accelerated SAP (ASAP)

Over the past decade, SAP and many other vendors have acquired a reputation for very expensive and slow ERP implementations. To address this issue, SAP has developed a methodology for a quicker, more efficient implementation called Accelerated SAP, or just ASAP. ASAP is designed for small to midsized companies and should require only about six months to implement, as opposed to one to two years for a normal SAP implementation in a large firm. ASAP follows the same basic phases just presented but places added emphasis on implementing the system with virtually no modification. Under this plan, the company may be forced to change its processes to fit the software. However, such BPR should be much more feasible for a small to midsized company than for a large one. RMO would be a very good candidate for ASAP.
Using SAP R/3

This section gives you a feel for how a user would navigate through SAP R/3. SAPGUI is loaded on a client computer that is networked to the server on which the SAP R/3 system has been installed. In a Microsoft Windows environment, the user starts the SAP R/3 program like any other program (by selecting Start, Programs, SAP Frontend, SAP R3). The logon screen then appears requiring the user to provide a user ID and password. Menus and buttons are available on this window for such functions as logging off or creating a new password.

Once logged on, the user will see the main SAP R/3 screen. The menu bar on this screen contains several options: Office, Logistics, Accounting, Human resources, Information systems, Tools, System, and Help. The Logistics, Accounting, and Human resources options represent the basic core of the SAP R/3 system. Selecting the Logistics option displays a pull-down menu with the following options: Materials management, Sales/distribution, Production, Plant maintenance, Service management, Quality management, and Project management. Selecting Accounting displays the following options: Financial accounting, Treasury, Controlling, Enterprise control, Capital investment management, and Project management. Selecting Human resources displays the following options: Personnel administration, Time management, Incentive wages, Payroll, Benefits, Planning, Recruitment, Travel expenses, and Information system. Ultimately, the user navigates through the various menus to accomplish the desired task, such as entering an order for a customer Figure 18-12 or viewing a materials requirements planning record Figure 18-13. Of course, the availability of all such menu options is contingent on having the associated modules configured and installed in the system.

Figure 18-12 SAP R/3's Create Standard Order: Overview screen.

[Click to enlarge]

Figure 18-13 SAP R/3's MRP List screen.

[Click to enlarge]

At the heart of the SAP R/3 system is the entry of business transaction data, followed by the use of those data to operate the firm efficiently and effectively. At the main SAP R/3 screen, the user can enter a four-digit transaction code in lieu of traversing a lengthy menu path to enter a valid SAP transaction. For example, to obtain a screen for confirming production work performed, the user can enter the code C011 instead of selecting Logistics, Production, Production control, Confirmation, Enter, For operation, and Time ticket. Obviously, a user well acquainted with transaction codes in a particular functional area would much rather enter the codes than use the menu. Figure 18-14 shows a screen called the Stock/Requirements List, which shows a real-time version of the MRP process. This output shows forecast demand and planned orders plus any dynamic changes such as completed production orders or material withdrawals.

Figure 18-14 SAP R/3's Stock/Requirements List screen.

[Click to enlarge]

A button bar is also available in SAP R/3. Clicking the Back button will move you backward through the path just traversed. The Exit Session button closes down the current session. The Help button provides on-line help. The Dynamic Menu button displays a listing of menu bar options in a tree structure until it terminates in a particular task's transaction code. The user can click that option or enter the transaction code to access the desired task.

After a user has logged on to SAP R/3, he or she may create up to six different sessions in SAP R/3 at the same time. To create a session, the user selects System, Create Session from the main screen menu. Multiple sessions, available on the taskbar in Windows, allow the user to work on different tasks without spending extra time moving around through menus. A user trying to access the same record in a database in different sessions will be locked out of that record until the original update is completed.

To log off SAP R/3 when finished for the day, the user either selects System, Log off from the menu system or clicks the Close button in the SAP R/3 window.

The issue of how best to procure business application software—custom-developed versus packaged—is extremely critical for the future of IS organizations and business enterprises. Equally important is the question of how best to deploy business application software—integrated versus stand-alone. The most recent trend in IS development is the deployment of integrated packages to increase both the efficiency and effectiveness of information technology as it serves to boost the competitiveness of the entire enterprise.

Software vendors design packaged software to be very easy to use and highly functional for its intended users. Application packages are now becoming more popular as both business processes and information systems requirements are becoming more complex. The debate rages whether a firm should custom-develop its own applications to match many of its unique system requirements or whether the firm should alter its processes, through business process reengineering, to match many of the “best practices” supported by recent packages. The three major issues that differentiate application packages from custom software are customization, integration, and upgrades. The systems analyst must address these three issues during the systems analysis and design phases.

A major class of packaged software is the comprehensive enterprise resource planning (ERP) system. ERP is the process of running virtually the entire organization with highly integrated application software. The approaches to deploying an ERP system include creating the system inhouse, assembling the system from a diversified set of “best-of-breed” application packages, and purchasing the system as a comprehensive package. One of the most popular approaches to ERP is the comprehensive package. ERP is purported to increase efficiency throughout the organization, reduce IS staff, and improve customer service. However, implementing such a comprehensive, enterprisewide system can be extremely challenging, with many potential pitfalls. Properly organizing people (employees, vendors, and consultants) for an ERP project is a major key for success.

The current market leader in comprehensive ERP systems is the German company SAP, which offers its R/3 system worldwide. SAP R/3 software is organized around three major application areas (Logistics, Accounting, and Human Resources) plus Business Tools, which allow for the continuing administration of the system. SAP R/3 can be configured for a wide range of industries, such as automotive, electronics, public sector, and retail. SAP R/3 is usually installed on a client-server platform by system integrators with the assistance and guidance of in-house systems analysts. While very large corporations typically install more of the available modules with some customization (requiring more time and expense), SAP offers the scaled-down ASAP system to midsized and small firms for more rapid deployment.
Key Terms

* best-of-breed
* business intelligence
* configuration
* enhancement
* enterprise application integration (EAI)
* modification
* sales-force automation
* software integration
* system integrator
* total quality management (TQM)
* value chain

Review Questions

1. What is meant by a “best-of-breed” software package?
2. What are the two most critical success factors for the development of software packages?
3. What are the three most common types of software packages?
4. What are the advantages and disadvantages of using an ASP as an alternative to purchasing a software package?
5. What are the three types of package customization?
6. What are the four major characteristics of ERP systems?
7. What are the three types of employee teams or committees that would usually be involved in an ERP project?
8. What are the major areas into which ERP vendors are expanding?
9. How can a firm use ERP as a strategic weapon to achieve competitive advantage?
10. What does the R/3 in SAP R/3 stand for?
11. What are the four major high-level work areas of R/3?
12. What are the five master data sets found in R/3?
13. What are the three tiers found in the R/3 architecture?

Thinking Critically

1. Under what conditions would a firm prefer to develop custom software rather than purchase one or more packages?
2. How have the purposes of business information systems changed over the past 50 years?
3. Discuss when BPR would and would not be necessary when implementing an ERP system.
4. Discuss how the role of a traditional systems analyst will change when his or her firm adopts an ERP system.
5. Give several examples of how both efficiency and effectiveness are improved with the implementation of ERP.
6. Discuss how ERP could make substantial improvements in all four types of business information systems.
7. Which should come first: ERP or BPR? Defend your position.
8. Discuss the major differences between a system development methodology for a custom project and that for an ERP project. Cover all five phases of the SDLC.
9. What does ASAP stand for in the context of SAP software? Under what conditions would you recommend ASAP to a company?

Experiential Exercises

1. Do a search on the Web for ERP or enterprise resource planning. Find an article that discusses a recent development in ERP or provides more detail about a topic introduced in this chapter. Prepare a written or oral presentation of this article.
2. Form two teams of students to debate the issue of custom versus packaged software development. Provide arguments and evidence, pro and con, for the statement, “Custom development is essential for creating and sustaining competitive advantage.”
3. Form two teams of students to debate the issue of best-of-breed versus comprehensive ERP systems. Provide arguments and evidence, pro and con, for the statement, “A comprehensive ERP package is superior to a best-of-breed approach.”
4. Do some Web research on the term middleware. Prepare a written or oral report on some recent developments or other interesting aspects of this subject.
5. Perform the following role play for the class: You are the IS manager. It is your job to explain to four other students in the class (who are playing the roles of IS analysts and programmers) why the company is adopting ERP and how it will affect their jobs. The IS staff have heard rumors that at least 50 percent of them will probably be laid off.
6. Prepare a hypothetical cost/benefit analysis for an ERP system, showing the expected payback.
7. Select a particular type of enterprise (such as electronics manufacturer, governmental agency, or pharmaceutical company). Assume that your company is either small (less than $200 million sales), midsized ($200 million to $1 billion sales), or large (greater than $1 billion sales) and operates either domestically or globally. By simply reviewing the Web sites of several (at least five) ERP vendors, draw up a preliminary evaluation reducing the number of candidates to two. Make sure you provide sound reasons and evidence for your decision.

Case Studies
Tools-R-Us, Inc., and Sales Quota Automation

Software packages are now being designed to perform very specialized tasks. One challenge for a marketing organization is to set sales quotas that are realistic enough to be attained and to motivate salespeople to excellence but not so easily attained as to create a financial burden for compensating salespeople for such excellence. It's a process that's too often unscientific and inexact.

Tools-R-Us, Inc., a maker of tooling machinery for General Motors, John Deere, United Technologies, and other manufacturers, starts from scratch each year by collecting spreadsheets and paper reports from field salespeople. It formerly set sales quotas by simply adding a percentage on top of last year's sales. Tools-R-Us now plans to install the quota module in Ockham Technology's SalesRazor 3.0 software, which automates the quota-setting process by analyzing new product launches and buying trends in different regions, industry sectors, and the broader U.S. economy. Tools-R-Us is considering plans to deploy modules for sales tracking in the fall.

The resulting quotas make sure salespeople in a historically strong region don't have an unfair-advantage over others. They also give the $2 billion company better control over what percentage of salespeople meet or exceed quotas, thereby containing compensation costs. “Setting accurate quotas helps us not blow the sales budget,” said Jack Hammer, Tools-R-Us's manager of marketing information systems. “If they're set consistently and everyone understands the methodology, you end up with a sales force that understands how to reach that goal.”

Tools-R-Us is coupling SalesRazor with data warehouse software from SAS Institute. The data warehouse gathers information from the company's SAP software and an Oracle database that houses point-of-sale information from partners such as distributors and integrators. Tools-R-Us chose SalesRazor in part because of Ockham's willingness to host the application while Tools-RUs's 100 IT staffers focus on upgrading the company's SAP enterprise software. Tools-R-Us plans to bring the application in-house in the near future. The licensed version of SalesRazor starts at $165,000 for a 250-person sales force.

1. What kinds of challenges does Tools-R-Us face as it attempts to integrate SalesRazor with software from SAS, SAP, and Oracle?
2. Do you believe this type of software should be purchased in a package or developed in house? Why?
3. Who should be responsible for getting SalesRazor up and running at Tools-R-Us: Ockham, SAP, or Tools-R-Us IT staffers?

Springfield General Life Insurance Co.

ERP installations don't always go smoothly. Springfield General Life Insurance Company contracted with Enterprise Solutions, Inc. (ESI) to install a finance system for $5 million. Springfield General later claimed that it had to develop its own homegrown software after ESI failed to deliver the new system as promised. In its lawsuit, the company also claimed that ESI had more than doubled its original price for the software and indicated the cost could go even higher. ESI countered that there was nothing wrong with the software it provided, but that Springfield General wasn't able to adopt the system due to its own internal problems.

In mid-2003, Springfield General paid the $5 million up front to ESI for software licenses, technical support and implementation, and customization services. Late in 2003, Springfield General personnel began to suspect that the ESI team was having difficulty with the customization and implementation services. Springfield General further claimed that ESI “failed to properly customize and implement” the promised software, leaving it “inoperable and entirely useless.” ESI replaced the workers assigned to the project and sent in a crisis management team. But then early the next year, Springfield General charged that ESI said the original project bid was flawed and raised the price to $12 million, with the possibility of another 20 percent increase on top of that amount.

1. What are some of the possible causes in the breakdown of the relationship between Springfield General and ESI?
2. What are some of the possible “internal problems” that could cause problems adopting such software?
3. Do you agree with the steps apparently taken by ESI, such as sending in a crisis management team and subsequently adjusting the price to $12 million? Why or why not?

Integration Specialists, Inc. (ISI)

Integration Specialists, Inc. (ISI) has recently introduced its latest customer relationship management (CRM) package, the myISI CRM 3.0 suite. However, some analysts are warning customers to be wary of the applications unless they install or already use ISI X/4 enterprise resource planning software. Carol Oakley, senior vice president of Worldwide CRM Business Development for ISI, says customers can take advantage of ISI's latest CRM suite even if they haven't installed ISI on the back end. But Lance Speer, service director for IT research, says the only way to achieve the full functionality of the CRM software is to link to ISI's financial and order-management applications, because the CRM software is dependent on business processes and functionality built into ISI's ERP applications.

Even if users are willing to forgo some capabilities in the CRM suite, they will still have to tackle some tough integration issues. Speer says “bits and pieces” of the CRM applications are written in Java, but more than 50 percent of the CRM code is still written in ISI's proprietary language. That makes it difficult, and costly, to extend the suite to the Web or other vendors' applications.

One current ISI customer, Business International Corporation (BIC), is looking forward to installing the new release. BIC, a machine manufacturer in Stillwater, New Jersey, last week rolled out the ISI call center as part of a year-long deployment of its myISI 2.0 CRM release. Tony Shaeffer, director of MIS, plans to begin upgrading his company to CRM 3.0 early next year, primarily to leverage enhanced usability and functionality in the new call-center applications. ISI's Speer says that for existing ISI customers, the latest version of ISI's CRM software delivers better-than-average analytics, data-mining, order-management, and field-service functionality. However, Speer adds, the suite lags behind Clarity Systems in sales-force automation.

1. Should customers of myISI CRM 3.0 be very concerned that much of it is written in ISI's proprietary language? Why or why not?
2. What are some of the potential hazards of using myISI CRM 3.0 on the front end (the user interface) without having ISI X/4 ERP software on the back end (applications that perform detailed processing)?
3. What are the pros and cons if Business International decides to go with the current market leader, Clarity Systems, for its CRM applications?

Rayco Products Corporation

Dave Chen works as a production planner for Rayco Products Corporation (RPC), a very successful multinational, Fortune 500 company. It is Dave's responsibility to create monthly production plans for five plants in the United States and Canada. To be closer to the action, Dave works at one of the five plants in Texas instead of at corporate headquarters in Ohio. One of the primary inputs to Dave's production planning process is an 18-month, item-level sales forecast that groups literally thousands of distinct part numbers into dozens of product families. One of Dave's major problems is creating the production plans in a timely manner so that the plants can adjust their material, manpower, and equipment requirements to meet expected customer demand.

The process works something like this: Corporate IS in Ohio runs the sales forecast program based on historical sales figures and input received from marketing personnel. Several copies of the forecast data tape are produced and mailed overnight to the plant IS departments where the three production planners are located, including Dave in Texas. When the IS department at the Texas plant receives the tape, it runs a program on the mainframe to produce a very large printout, and a data file on disk, of the forecast for all product families and their individual part numbers. When the file is created, Dave runs a program to download the file to his PC. He then imports the text file into an Excel spreadsheet. From there, Dave runs several macros to manipulate the data into an initial production plan.

The entire process of creating, mailing, and running the forecast tapes, then downloading the data to the PC and running the spreadsheet macros, takes at least three days (barring any glitches in computer operations or in the shipping of tapes). This puts Dave in an extreme bind to interpret the data and create the production plans in time for the scheduled monthly meeting at corporate headquarters. The plants are also in a hurry to receive the final production plans so they can begin ordering material, scheduling overtime, and shifting production to other plants, if necessary. The entire process—from the monthly close of business to the creation of material, manpower, and machine requirements at the plants—takes at least seven business days, or about one-third of a business month.

1. What major courses of action would you recommend for RPC in terms of ERP, and why?
2. What specific benefits would RPC derive for production planning via an ERP implementation?
3. What potential problems would RPC face during and after an ERP implementation?

Rethinking Rocky Mountain Outfitters

William McDougal, vice president of marketing and sales, just returned from a seminar on customer relationship management (CRM) sponsored by ISI, the ERP software vendor mentioned in the earlier case study. At the seminar, ISI promoted its most recent release, myISI CRM 3.0. Upon returning, William read some recent articles about packaged CRM software, particularly ISI's product. The articles pointed out the many possible advantages of using CRM software but also warned of integration problems.

As a result of this investigation, William was beginning to wonder whether RMO's customized approach to the CSS project was indeed the best option. He called in Mac Preston, chief information officer, to get an up-to-the-minute progress report on the CSS project, and to get his opinion on the possibility of switching to a packaged solution. The CSS project team was still in the process of identifying system requirements.

Mac reminded William that a packaged CRM product had been considered about six months ago but that a customized approach was judged best by the entire oversight committee, including William. William countered that he had not fully understood the capabilities of a CRM package at that time and that the latest versions of CRM software are much more powerful than previous versions. William now says he is leaning very strongly toward reopening the question of a CRM package with RMO president John Blankens.

1. What would be the major advantages and disadvantages of using a CRM package rather than a customized CSS?
2. What impact would using a CRM package, instead of a customized solution, have on various RMO personnel? Consider both user and developer groups.
3. Should RMO consider the myISI CRM 3.0 package without first having an ERP system, such as ISI R/3, already in place? Would your answer change if RMO decided to proceed with the customized CSS instead of a CRM package?
4. Based on what you know about RMO and ERP, what would you recommend regarding an ERP system for RMO? Completely discuss all important aspects of the reasoning behind your recommendation.

Focusing on Reliable Pharmaceutical Service

In Chapter 8, you considered whether Reliable should (a) contract for custom development, (b) purchase a “stock” prescription system and contract to modify the package, or (c) opt for some combination of these approaches. Suppose that Reliable is indeed leaning toward packaged software and contemplating one further step—purchasing an ERP system that would enable it to integrate nearly all functions of the company. Based on what you know about Reliable from previous chapters, perform the following:

1. Discuss Reliable's potential need for an ERP system specific to its operations.
2. List and discuss the most likely benefits that Reliable would achieve using an ERP system. Also list and discuss the most significant risks that Reliable would face with such a system.
3. Identify and discuss the most important critical success factors to ERP implementation in Reliable's case. Be specific.
4. Explore SAP's Web site at to learn what specific products and services SAP might recommend to Reliable. Report your findings.
5. Using the ERP system development methodology and special topics in ERP development as presented in this chapter, create and discuss an overall plan, start to finish, of how you see Reliable deploying a successful ERP system. Create a rough Gantt chart to illustrate your plan.

Further Resources

* George W. Anderson, SAP Planning: Best Practices in Implementation, Pearson Education, 2003.
* Joseph A. Brady, Ellen F. Monk, and Bret E. Wagner, Concepts in Enterprise Resource Planning. Course Technology, 2001.
* Erin Callaway, Enterprise Resource Planning: Integrating Applications and Business Processes across the Enterprise. Computer Technology Research Corporation, 1999.
* Steven Harwood, ERP: The Implementation Cycle, Butterworth-Heinemann, 2003.
* Jose Hernandez, Roadmap to, Course Technology, 2001.
* Bradley D. Hiquet, SAP R/3 Implementation Guide: A Manager's Guide to Understanding SAP. Macmillan Technical Publishing, 1998.
* Daniel E. O'Leary, Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk, Cambridge University Press, 2000.
* Murrell G. Shields, E-Business and ERP: Rapid Implementation and Project Planning. John Wiley & Sons, 2001.
* Avraham Shtub, Enterprise Resource Planning (ERP): The Dynamics of Operations Management. Kluwer Academic Publications, 1999.
* Norbert Welti, Successful SAP R/3 Implementation: Practical Management of ERP Projects. Addison Wesley Longman, Inc., 1999.
* Liane Will, SAP R/3 System Administration: The Official SAP Guide. Sybex, 1999.

eBook Collection

* Home
* Table of Contents
* Read Book Online
* Buy This Book
* Download eBook
* Print Chapter
* Search
* Preferences
* Help

Useful Links

* Reference and Citation Generator
* APA Information
* Grammar and Writing Guides

Home | Classroom | Library | Program | Account
Sitemap | Downloads | Community Relations | System Status | Terms of Use
Contact Us
Report a problem | Ask a question | Share a thought
Copyright © 2009 University of Phoenix. PWAXDNET008

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License