Introduction

In the previous chapter we assessed the value of Templates in terms of their creativity and ideation. The results indicate that templates are likely to enhance creativity. However in marketing and new product development fields it is important to explore the relevance of a method not only with respect to its originality, but also to market success and failure rates. This chapter provides some information about and insights into this applied perspective.

Particularly in view of the distressingly low rate of success in new product introduction, it is important to identify predictive guidelines early in the new product development process so that better choices can be made and unnecessary costs avoided. In this chapter, we posit that the Templates and the Function Follows Forms principle can be utilized as a framework for early analysis based on the success potential embodied in the product idea itself and the circumstances of its emergence. We suggest that these factors, along with already known factors relating to success or failure, may aid estimation of the potential of a concept early in its development.

Predicting new product success

Introduction of new products is a major activity of firms. However, most of the 25,000 products introduced each year in the US fail [1,2].

This template was illustrated briefly in the introduction: the Polo Harlequin®, Domino's pizza delivery and the dynamization of the credit in the lighthouse are all examples of ideas that share the structure of this Template. In this chapter we will focus on this Template and on ways to implement it successfully in new product ideation.

An antenna in the snow – a detailed illustration

The following example shows how illusive creative ideas may often be. A company specializing in the production of transmission and reception sets participated in a bid for the production of military receiving antennas in a region where winter temperatures reach a low of −40°C. The company itself is located in a warm climate where even light snow is a rare event. It may be for this reason that the company engineers forgot to take into account a common phenomenon in the target market: The accumulation of ice on the antenna causes an overload on the pole, which may cause it to buckle down and collapse (see Figure 4.1). They therefore designed a light pole, which was not quite suited for the task. Ironically, because of the importance assigned to the weight issue (the pole should be light as it had to be carried by a team of three soldiers), the army accepted this bid.

At various points in this book we have provided configurations of products to exemplify how well defined they are and how they can be used for creativity tasks in a relatively straightforward manner. In this chapter the inference and development of the Templates is presented as part of a formal presentation that can also assist in generalizing and applying them in a variety of other contexts.

Before describing the Creativity Templates themselves, let us revisit and elaborate the procedure for constructing the configuration of products. Several background definitions and rules of operation are required at the outset.

Space

Space is the field of operation. Templates operate in two spaces:

1. The component space consists of static objects – the fundamental component parts that make up the product as a whole, or the fixed external elements that have a direct impact on the product.

2. The attribute space consists of variables of the product or its components that can be changed.

Recall the chair example, the legs and seat of the chair would be components; the color and height of the chair would be attributes.

Note that the Creativity Templates approach considers only those attributes that consist of factual information. Abstractions or inferences, such as esthetics [see definitions in 1], are considered only at the later, development stage.

Characteristics

The characteristics of a product are its components and attributes.

Creativity Templates depict discernable, measurable and learnable regularities or patterns in innovations and novelties emergence. They enable us to understand general mechanisms of past product alterations, as well as to foresee the next alteration in the series.

The Creativity Templates approach is a counter-intuitive view for product emergence and a novel method for ideation, yet it does not contradict any current marketing theory. It does, however, add an important perspective to the process of product innovation by drawing on the primacy of the idea itself as a driving force toward new product success. Creativity templates are derived by inferring patterns in the evolution of products, such as those that can be inferred from the following illustrations.

Gates, computers and extraterrestrial intelligence

Thomas Alva Edison – Life Magazine's “Number One Man of the Millennium” – was one of the outstanding geniuses in the history of technology. Listed under his name are 1,093 US patents (including the incandescent light bulb, the phonograph and the motion picture projector). Many tales are told of this colorful personality.

One legend about Edison tells that Edison's guests were always complaining that the gate to his house opened with great difficulty, and they were required to exert great force in order to open it. Jokes were rampant about the obstinate gate and the clever inventor who could not find a way to fix it.

Not all ERP implementations are successful. Implementations succeed and fail for a number of different reasons. Although we have pointed to a number of elements of risk or failure in ERP implementations, the purpose of this chapter is to provide a framework to facilitate risk identification and to identify some additional risks that can lead to ERP success or failure.

A risk is something that can go wrong. Risk is an exposure that can be a success factor if properly handled and a failure factor otherwise. Success factors and failure factors are two sides of the same risk. As in other settings, there is a trade-off between risk and return. Exposing the firm to risk may ultimately provide a greater benefit. For example, as we shall discuss, linking ERP to other applications increases the risk but also increases the potential return from the project.

One model for categorizing risk in the ERP system is given in Figure 15.1. In this matrix, risk is categorized along two dimensions: location in the ERP life cycle and type of application (technical, business, or organizational).

Types of Risk

Risks occur throughout the ERP system life cycle, which ranges from the go-no-go decision on ERP until after the system has gone live, including training issues. The types of risks and the extent of their impact on the organization vary as we move through the life cycle.

Enterprise resource planning systems ultimately result in the reengineering of organizational processes. For example, in many legacy systems data is gathered at the loading dock, filtered through accountants, and then entered into the system. However, ERP systems are designed so that their usage can be pushed to the point of data generation, often in operations. As a result of this reengineering (see Hammer 1990), there are a number of changes in the process, including who gathers the data, how it is gathered (actually gathering more data, bypassing paper and entering data straight to a computer-based environment), gathering the data where it is generated, removing accountants and replacing them with information gatherers from operations, and changing when the data is generated to correspond to a process focus.

Each of these system changes can have a significant impact on capturing data inputs (e.g., who does data input, where is data input done, and how often is input data gathered), and this ultimately influences the quality of the data. As a result, reengineering changes to data inputs can have a major impact on the corresponding benefits and costs of an ERP implementation.

Assessing benefits is often more difficult than assessing costs – probably because benefits are not yet actualized and often are less direct. As a result, in order to understand the contribution of benefits, those associated with system changes need to be identified.

This chapter initiates our dialogue into enterprise resource planning (ERP) systems, focusing on the following questions.

• Why investigate ERP systems?

• How does ERP create value?

• What is the purpose and scope of this book?

• What is the outline of this book?

Why Investigate Enterprise Resource Planning Systems?

Enterprise resource planning systems are a corporate marvel, with a huge impact on both the business and information technology worlds, including each of the following dimensions:

• ERP affects most major corporations in the world;

• ERP affects many SMEs (small and medium enterprises);

• ERP affects competitors' behavior;

• ERP affects business partner requirements;

• ERP has changed the nature of consulting firms;

• ERP provides one of the primary tools for reengineering;

• ERP has diffused many “best practices”;

• ERP gave client server computing its first enterprise product;

• ERP has changed the nature of the information systems function;

• ERP has changed the nature of jobs in all functional areas;

• ERP cost is high;

• ERP has experienced huge market growth.

ERP Affects Most Major Corporations in the World (Bowley 1998). A single ERP system (SAP's R/3) is used by more than 60% of the multinational firms. Further, according to Arthur D. Little's global strategy leader, an ERP company (SAP) “is conquering the world. Almost every important company is more or less in its hands.”

After going live with the ERP implementation, it is not time to forget about ERP because it is “done.” Instead, at that time the organization enters a stabilization period that typically drags down organizational performance. As a result, firms need to work to mitigate that negative effect. The firm also needs to build an organization to handle the day-to-day issues associated with the ERP system, and management needs to determine what else must be done and whether the implementation matches the system plan. Also, management must address what upgrades, extensions, or linkages can or should be made to the ERP system. Finally, the firm needs to evaluate the success of the project.

The Stabilization Period

After a system goes live there is what has been referred to as a “stabilization period” that typically lasts from three to nine months. During that period, as noted by a director at Benchmarking Partners, “[m]ost companies should expect some dip in their business performance at the time they go live and should expect that they'll need to manage through that dip” (Koch 1999). For example, a recent survey by Deloitte Consulting found that, after their ERP systems went live, one in four firms suffered some drop in performance.

During the stabilization period, all those processes that once were just plans are now being used. New software and processes may be unfamiliar to the users.

As part of choosing ERP software, firms face a design “reengineering policy” decision regarding the amount of software customization and organizational reengineering that must be done. On one hand, since no software is likely to meet all of a firm's needs, some firms have chosen to substantially customize the software to fit their processes. On the other hand, many businesses have used adoption of new software as a chance to change their basic business processes, reengineering their organization to match the “best practice” processes in the ERP software. In order to clarify the extent to which different firms pursue different policies, Forrester Research conducted a survey (Lamonica 1998) and found the following percentage of firms following policies:

• choose applications that fit their business and customize a bit – 37%;

• customize applications to fit their business – 5%;

• reengineer business to fit application – 41%;

• no policy – 17%.

This chapter analyzes two basic questions.

1. (1) How does the reengineering policy influence the software application choice process?

2. (2) Should business processes or ERP software be changed?

How Does Reengineering Policy Influence Software Choice Processes: On the Relevance of “As Is” and “To Be” Modeling

The decision to modify software or reengineer business processes (or both) influences the relevance and use of “as is” and “to be” modeling.

The purpose of this chapter is to provide some basic background information about ERP systems. As a result, we will address a number of specific questions.

• What is an ERP system?

• Who are the ERP vendors?

• What are ERP “partners”?

• What are some sample ERP modules?

• What does it mean to talk of “best of breed”?

• What are “add-ons” to ERP?

• What are ERP MAPs?

• How do ERP systems work?

Since SAP is the dominant ERP system, I will use it to illustrate some of the general ERP concepts.

What Is an ERP System?

In this book, ERP systems are computer-based systems designed to process an organization's transactions and facilitate integrated and real-time planning, production, and customer response. In particular, ERP systems will be assumed to have the following characteristics.

• ERP systems are packaged software designed for a client server environment, whether traditional or web-based.

• ERP systems integrate the majority of a business's processes.

• ERP systems process a large majority of an organization's transactions.

• ERP systems use an enterprise-wide database that typically stores each piece of data once.

• ERP systems allow access to the data in real time.

• In some cases, ERP allows an integration of transaction processing and planning activities (e.g., production planning).

One of the critical sets of decisions that needs to be made in any ERP concerns the choice of common standard MAPs – that is, models (e.g., organization models), artifacts (e.g., vendor numbering schemes and lists), and processes (e.g., order management). Two expressions, “common … and global” and “input by many,” have received attention as guidelines to help implement those common MAPs in some companies (see CIO 1996). Rather than following the historical process of each business unit choosing its own MAPs, as is often done in legacy systems, an ERP-structured company will use the same MAPs for each business unit. However, the choice, implementation, and use of common MAPs is not easy. Within a given firm there are likely to be conflicts over those MAPs. As a result, this chapter addresses the following questions.

• Why are MAPs important?

• Where do common MAPs come from?

• Why do firms need common MAPs for ERP systems?

• Why didn't firms have common MAPs prior to ERP systems?

• Why is it difficult to choose common standards?

• What are some choice motivations?

• In order to develop “common … and global” processes, what methods have been used to choose common ERP models, artifacts, and processes so that there is “input by many”?

Why Are MAPs Important?

The quality of the MAPs will have a huge impact on the overall success of the ERP implementation.

This chapter examines how firms choose between different ERP systems. Two primary approaches are used to guide ERP choice: requirements analysis and gap analysis. This chapter defines these approaches and examines the advantages and disadvantages of each, and it briefly discusses an alternative approach. In addition, this chapter examines the assumptions behind requirements analysis and gap analysis as well as some limitations of these two processes. Also discussed are two companies that have mitigated these limitations in their evaluation of ERP software by going beyond requirements and gap analyses. Finally, this chapter summarizes the shortcomings of broader evaluation approaches.

Requirements Analysis

Requirements analysis is a review of system requirements for organizational models, artifacts, and processes (MAPs). In some cases requirements are cataloged as to their importance – for example, required or optional, or ranked (say) from 1 to 3. Requirements are then summarized in a requirements document (request for proposal, or RFP) that is provided to different vendors. The organization uses that set of requirements to judge how well different pieces of software meet their needs.

How Many Requirements?

Requirements documents can be quite extensive. For example, one company (Firm A) with $40 million in sales produced a document with about 1,000 requirements listed. Timberjack, with over $35 million in sales, listed 1,042 requirements. A much larger and privately held company (Firm B) also had a requirements document with over 1,000 items.

The purpose of this chapter is to provide some brief background information on systems and technology to facilitate understanding of ERP issues. In order to do that, some background on computing, networking, databases, software, software choice, and reengineering is provided. Within each category, the background information is applied to some related ERP (in particular, SAP) concepts in order to tie the background material directly to ERP.

Computing

Historically, enterprise computing was heavily mainframe based. In roughly 1993 (see e.g. Frye 1994), client server versions of enterprise computing applications began to be more available.

Mainframe Computing

In a mainframe computing environment, all the computing is done on a single computer (box). Typically, this is handled by allowing users to share (e.g., via time sharing) the computing resource – the mainframe computer. The user would typically be at a terminal that had no computing capabilities (or at a personal computer that emulated a terminal).

Client Server Computing

Over time, the user began to have increasing computing capabilities locally. As a result, computing began to shift some of the processing to the user's computing facilities. This ultimately resulted in what is now called “client server” computing, where client and server are linked so that the computing and storage can be distributed between the client and the server. The term “client” refers to the user's computer, while the “server” refers to some other (e.g., centrally located) computing source that provides computing resources, software, or data.