Introduction

According to AMR Research, total revenue in the enterprise application and services market in 1999 was US$18.3bn. (Gilbert, 2000). Enterprise application software implementation costs are often reported to be five to ten times the cost of software licenses (Davenport, 2000). If so, organizations worldwide spent something like US$90–180bn. on enterprise systems in 1999. Most organizations that have implemented enterprise systems expect to continue using them for many years.

Enterprise systems are integrated, enterprise-wide, packaged software applications that impound deep knowledge of business practices accumulated from vendor implementations in many organizations. Today, enterprise systems are evolving to incorporate new technologies, such as e-commerce and the internet, data warehousing, and customer relationship management. Enterprise software is a semi-finished product with tables and parameters that user organizations and their implementation partners configure to their business needs. Implementation of enterprise systems therefore involves both business and IT managers who work together to define new operational and managerial processes.

The question we ask in this chapter is as follows: If organizations around the world spent US$100bn. or more on enterprise systems in 1999, what sorts of benefits did they, or can they, achieve? To answer this question, we present a comprehensive framework of benefits that organizations may be able to achieve from their use of enterprise systems. Our focus is on business benefits only, not on costs. Our framework establishes a base for managing the implementation and operation of enterprise systems.

The Impact of Culture on ERP Implementations

A recent Standish Group report on ERP implementation projects reveals that these projects were, on average, 178% over budget, took 2.5 times as long as intended, and delivered only 30% of promised benefit, and a recent survey of 12 recent projects revealed that adapting the implementation to the prevailing cultural style was one important cause of this project underperformance (Densley 1999). These findings support anecdotal evidence for the impact of culture reported in the IT press (for example Warren, 1999). This importance of culture is hardly surprising. A customer who implements an ERP package has to change its business processes to the ERP supplier's best-practice processes (Curran and Ladd, 1998). The change both impacts on the customer's organizational culture (that is the ways that things are done in the organization) and is constrained by it. In Europe, the picture is even more complex because companies also have diverse national cultures which influence this organizational culture and make the successful implementation of multinational ERP implementations difficult, as reported in Gulla and Mollan (1999). Indeed, evidence suggests that ERP implementations in North America have been more effective because of the more complex European organizational and national cultures (Warren, 1999). If more ERP implementations are to deliver their promised benefits within budget, we need to understand how organizational and national culture impact on ERP implementations, and how this understanding will deliver better methods for implementation partners and customers to use.

Introduction

Some organizations report success and significant process gains resulting from enterprise system implementation, while many others encounter significant losses. It is readily apparent that the implementation of packaged enterprise system software, and associated requisite changes in business processes, has proved not to be an easy task. As many organizations have discovered, the implementation of enterprise systems can become a recipe for disaster unless the process is carefully handled. The following headlines provide a glimpse of the troubles encountered by organizations, ‘SAP: Whirlpool's Rush to Go Live Led to Shipping Snafus’ (Collett, 1999), ‘Delays, Bugs, and Cost Overruns Plague PeopleSoft's Services’ (Olsen, 1999) ‘ERP Project Leads to Court Fight’ (Stedman, 1999) and ‘PeopleSoft Problems Persist, Cleveland State Looks for a New Project Manager’ (Olsen, 2000). In 1995, US firms incurred an estimated $59 million in cost overruns on information system projects and another $81 million on cancelled software projects (Johnson, 1995). Furthermore, it is estimated that approximately 90% of enterprise system implementations are late or over budget (Martin, 1998).

Enterprise system (ES) implementations are different from ‘traditional’ system analysis and design projects (Davenport, 2000). Among the significant differences are the scale, complexity, organizational impact, and the costs of ES projects and subsequent business impact if the project does not succeed. An ES implementation impacts the entire organization, whereas a traditional project impacts often only a limited area of the organization. Furthermore, ES projects are often associated with the reengineering of business practices.

Introduction

Enterprise Systems (ES) offer configurable business solutions for typical functional areas, such as procurement, materials management, production, sales and distribution, financial accounting, and human resource management (Rosemann, 1999). These functions are typically individualized for industries, such as automobile, retailing, high-tech, etc. Consequently, ES tend to be very comprehensive and complex. This is mirrored in the software documentation, which was often measured in metres before online documentation was developed. To improve the understandability and to stress the process-oriented nature of their solutions, ES vendors have developed reference models which describe the functionality and structure of their systems. Enterprise system reference models exist in the form of function, data, system organization, object and business process models, although the latter is by far the most popular type. The dominance of reference process models results from the increasing popularity of process-oriented management concepts such as business process engineering (Hammer and Champy, 1993) or process innovation (Davenport, 1993), which led to the development of several new process modelling approaches (for example, Kim, 1995).

Enterprise system reference process models describe on different levels of abstraction selected ES processes, that is, sequences of functions supported by the system. Depending on the underlying methodology, these models include details about the control flow (including AND/OR splits or joins), the involved system organizational units, input and output data and business objects (Curran and Keller, 1998).

In recent years, an evolutionary change has occurred in the way modern systems are developed or, perhaps, we should now say “assembled”. Instead of building systems from the ground up – designing, constructing, and testing every part, thereby incurring time delays and huge costs – modern systems are being assembled from a combination of components to meet the needs of the business. These components or services might have been rented or bought from third-party suppliers, reused from previous systems, or built to provide a special set of services for the solution. The aim is to avoid building most of the solution.

This component-based development strategy can be summed up as “Reuse before you Buy before you Build”. It's the new approach to meet the needs of tomorrow. Interestingly, the UML, as well as 99 percent of this book, works fine with any of these alternatives, including a combination of alternatives. This chapter explains the background of many seemingly odd questions raised by IT people, which might seem to be too early in the project. As we show, components can early on play a key role in the bid/proposal stage of a project.

Yesterday's development approach was for large amounts of time and effort spent in developing basic parts of the system architecture, for example, visual controls, communications interfacing, and so forth with a smaller amount of time and effort spent in project-related activities, that is, delivering solutions, as shown in Figure 6-1.

Business modeling concerns process owners, reengineers, or business analysts with IT specialists in an advisory role. Later, in class modeling and especially in object interaction modeling, IT people become the driving force. Here, in adding rigor to the requirements through use-case modeling, there's a shared effort. Business experts provide the essence of the requirements, while IT specialists provide the structure. Having modeled the business, we now start aligning the system specification – most of it being the functional requirements – to the requirements of our business processes.

A diagram technique for this is very widespread: UML standard use cases that were pioneered some 20 years ago by Ivar Jacobson. Use cases are simply the ways in which the actors use the system. A similar step is natural in any knowledge industry because exact requirements minimize lead time and misunderstandings.

Use Cases

Human-computer interaction (HCI) is a vast field, to which use cases contribute with a practical, down-to-earth technique for the doers. To end users of the planned solution, the user interface often seems to be the entire system. Use cases extend this simplified view by modeling what's going to happen at the user interface, as well as interfaces to other systems. Use cases, interface layout examples, and prototypes complement each other, so they fully define the functional requirements of the system. Any remaining UML diagrams specify the inside/kernel of the system hidden behind that interface.

Yet another book about UML! Since its initial version, the Unified Modeling Language has gone an impressive way in the IT community. Over the past couple of years, we have been loading our bookcase with quite a few UML books. Many of them deal with applying or extending UML for a specific domain: UML for project management, UML for business modeling, UML for Java, real-time UML, UML for components, UML for web applications, and so forth.

This book takes a somewhat different and, in our opinion, long-awaited approach. It goes back to the basics of UML: improving the communication among different stakeholders of a (software) project. As the authors of the book write: “a UML made easy for people who specify, buy, or manage complex software systems”. Many of these stakeholders are non-IT professionals in much need of an easy-to-digest introduction to UML.

Looking back on the IBM SanFrancisco project – one of the real success projects in the field of object-oriented business applications – where we, at IBS, played a central role as initiators and principal development partner to IBM, a key success factor was the alignment among domain experts, sponsors, and object experts – through a minimum set of concepts and techniques.

In addition, this book focuses on the new paradigm in software development: fast delivery of applications based on components sourced from various suppliers.

Now that we've specified the external requirements, we begin mapping our system-to-be by sketching out its internal structure, gradually involving more IT personnel. Involvement of the stakeholders depends on the nature of the system. If the system is to be highly interactive, then much of the hard work has already been done during specifying and defining the use cases. If the system-to-be is more complex than interactive, such as a knowledge base, then you might have to do much more work at this stage, for example, detailing the rules that affect each part of the solution.

We're also dependent on the skills of our IT personnel. Throughout the project, experienced people familiar with both object methodology and conceptual thinking will ask many of the important questions early in the specification stage, whereas new converts will appreciate more input from other stakeholders, including help with first-cut key diagrams.

Because structure issues are key with most enterprise systems, we provide boxes on some advanced constructs, as well as extensive footnotes on details and semi-technical issues. We point out why some peripheral, or seemingly peripheral, questions often emerge during modeling.

Some methodologies encourage a two-step process on defining classes: first, model the business classes (the first cut), and then develop a complete class model. In a lightweight approach, we can view these as two levels of detail, which then gives an indication of the involvement of relevant business expertise.

Software – Yet Another Knowledge Industry

Knowledge industries such as electronics, space, pharmaceuticals, or software are special. On the surface, they're the hotly-argued-upon backbone of the new economy, a concept that's no longer new. In our opinion, it's the approach to business that makes the difference, rather than a company's niche or age. Some old-economy veterans, such as global-automation vendor ABB, have rapidly expanded their R&D initiatives and resources, employing many more IT specialists than many so-called new high-profile IT firms. IT provides a foundation to a variety of current business ideas, including customer-driven manufacturing where a web customer configures the product or even the software guiding an industrial robot in manufacturing the chosen customized product.

Obviously, knowledge industries are more special under the shell than at this slightly superficial mass-media/thematic level. On one hand, they have business processes similar to other industries but, on the other hand, production/operations is a small part of any business dominated by R&D and by marketing the know-how of that organization.

Awareness of knowledge-industry specifics is a project-time saver, both within the software industry itself and with the rapidly increasing number of its customers in the other knowledge industries. Knowledge industries are often interleaved with traditional industry sectors – today, you find computer chips and software in all the flagships of industrialism, from heavy trucks to railways. But, in a high-tech region, the complete knowledge-business value chain can sometimes grow remarkably long without any tangible (“hard”) products whatsoever (Figure 1-1).

Think Big, Start Small, and Sustain the Effort

Most people agree that analysis occurs only when the domain expert is in the room. In our experience, in addition to being present, experts are also supposed to understand the language “spoken” in the room. The language problem has often turned out to be even bigger than that of business-travel logistics. The UML, however, provides many powerful tools to make yourself understood in the room, which come in handy for the frequent visitor. By writing this book, we simply seized the opportunity and packaged much of the substance in a lightweight manner for this purpose.

Implementing UML models (and tools) to specify requirements doesn't take much time. Employing them in a practical approach preshrunk to fit your type of systems takes more training days and practical experience. Finally, adopting a component approach throughout the enterprise can take years of sustained effort, but it's definitely worthwhile.

UML Under Time Constraints

We believe the lightweight style of this book makes it possible for experts from many other areas to approach practical, basic UML. A frequent guest to the landscape of software can view this as a phrase book for the journey, keeping grammar detail at a minimum because many good grammar books already exist for this modeling language.

At the same time, we've provided some hints on cooperation with the hosts and on what parts of the language a guest typically becomes involved with in practice.

The excellent idea of writing a lightweight book on the Unified Modeling Language (UML) wasn't ours, we admit. This idea originated from Milan's customers. Having taught more than a hundred courses and seminars on component approaches to software development and on UML over the past few years, he was repeatedly asked for “UML made easy” for people who specify, buy, or manage complex software systems, yet don't program them. This demand seems logical given the way UML is being used in projects and read of in the success stories – as well as the increasing specification workload in any knowledge industry (see Introduction). However, as we moved on into this book project, both of us became increasingly enthusiastic about the idea, as did Cambridge University Press (CUP). Luckily, a majority of our readers are quite familiar with CUP from their own (variety of) fields; so this book is likely to be seen as accessible in most senses of the word.

Any system specification can state requirements on functionality, usability, reliability, performance, and supportability, as well as legal and technical constraints where relevant. In UML projects, we start from a view of the business – its processes and activities – and move into functionality, incrementing all the remaining, nonfunctional, bullet lists as we go.

Having set the stage with class diagrams, we'll now look more closely at what is likely to happen on that stage. We examine life cycles and (with the assistance of IT staff) interactions between all the small parts within the system.

State Diagrams

Some business entities have interesting life cycles because of real-world regularities and constraints, such as business rules, legislation, laws of nature, and so forth governing their “lives.” Because these business entities are represented by a class, we model this dynamic aspect in a state diagram per class.

In most enterprises, some key business entities have an interesting life cycle, which makes a state diagram necessary. These examples show the key states (life-cycle phases) for certain key entities in different industries:

• Banking: Account (in_credit – overdrawn – blocked – overdrawn and blocked – closed)

• Travel: Reservation (registered – on waiting list – reserved – paid)

• Brokerage, shares, bonds: Order (placed – activated at desired price – deal-confirmed – closed)

• Insurance: Retirement plan (employed – payment-aged – retired – deactivated)

We find such key entities in practically any business. The latter example simply mirrors the life cycle from a retirement plan point of view.

Strengths

A state diagram is a compact, yet quite intuitive, notation. These diagrams are versatile because they can mirror the lifetime dynamics of a rather long “life” in the kernel of an enterprise system, as well as a rather short “life” in a user dialogue or in a real-time system.

Data modeling has been covered thoroughly for decades. Like class diagrams, it provides a structural view. Unlike class diagrams, data modeling omits business-level operations that the proposed system will perform. Most often, it also omits some key relationships, such as generalization, despite the fact that various data-model notations for generalization have been around for almost two decades. Because most data models are on a design level, they already take into account some restrictions posed by the underlying implementation technology (data tables).

Strengths

Data models cope well with the data to be stored in the bottom layer of a system. Therefore, data modeling is a technique suitable later on, during design. The mapping to data models enables modern object-oriented systems to use ordinary relational database engines, which are standard in enterprise systems. In practice, brief previews with Database Administrators are a good idea to coordinate legacy and other systems with our models to come. By the time data modeling becomes really interesting in our project, we already have a more technical focus.

Limitations

Data models omit most of the behavior and business logic. Also, what data modelers call constraints or rules typically turns out to mean special data-related ones (such as rules of referential integrity across data tables), whereas UML includes a more versatile and powerful standard for declaring complex business logic, the UML Object Constraint Language (OCL).