ERP (Enterprise Resource Planning) vendors have seen a dramatic increase in their sales this decade. Even though several vendors are producing great products and making huge profits, there are some problems to be resolved to make ERP applications a continuous success in the next decades. Current ERP applications have the low reusability and interchangeability of various modules among different vendors� packages. One of the main reasons for these shortfalls is a tight coupling of ERP domain knowledge with the particular implementation tools. Also, efforts in establishing and using the standards in specifications of ERP applications have been inconsequential. In this article, strategic steps to wield a dominant power in the future ERP market are discussed. These steps are as follows: 1. Knowledge Modeling: Abstraction of Domain Knowledge from Tools; 2. Componentization of Domain Knowledge; 3. Implementation of Componentized Domain Knowledge; 4. Marketing Strategies for Domain Knowledge Components.

Introduction

Since the early 1990s, a notion of business reengineering has been very popular in many companies, especially in the USA. One of the contributions of business reengineering is that corporate information systems should be viewed as an enabler to transform the business processes and consequently organizational structures. To fulfill the mission of an enabler of business transformation, corporate executives found that corporate information systems should be planned, designed and implemented from an enterprise-wide perspective. A collection of islands of software located in various divisions of an organization could not satisfy the new needs of large corporations.

ERP (Enterprise Resource Planning) vendors promise to deliver an integrated set of software systems for various functions of a company, including accounting, manufacturing, logistics and others. Recently, ERP vendors such as SAP, Baan, PeopleSoft, Oracle and J. D. Edwards have seen their sales growing exponentially. Behind the successful stories of ERP, however, there are several issues to be dealt with in order to adapt to the ever-changing computing environment and maintain the competitive advantages.

Borrowing the idea from the industrial manufacturing, software components built based on standard specifications can be a building block for resolving the current problems in designing ERP applications. To build software components, however, we need to have a set of specifications at the knowledge level. In this article, knowledge modeling abstracted from the implementation tools is discussed as a precursor for building the components for ERP applications after the problems of current ERP applications are discussed and core competencies of ERP vendors are reviewed from a perspective of overall computing architectures.

Problems of Current ERP Design

Currently, each ERP vendor has been developing its own proprietary systems in various domain areas. Since ERP customers prefer the seamless systems across their business functions, ERP vendors are continuously expanding into new domain areas. However, one vendor does not necessarily produce superior ERP packages across all business functions. Each vendor maintains superiority in some functional domains, e.g., PeopleSoft for human resource management.

From a perspective of ERP customers, they have to opt for using all ERP applications primarily from one vendor or selecting many packages from different vendors. If customers can choose the best from different ERP vendors without worrying about the compatibility among different vendors� ERP packages, they can maximize the productivity gains by installing the best ERP applications in their organization. From an ERP vendor�s perspective, it is very difficult to specialize in any particular domain functions (e.g., manufacturing, financials, etc.) because many customers want a smorgasbord of ERP packages from one vendor. If ERP packages from different vendors are interchangeable or compatible, some problems aforementioned can be somewhat resolved.

There have been overlaps in efforts developing virtually the same type of applications (e.g., accounting packages) by many different vendors. Reinventing a wheel is a last thing we need to do. Current ERP designs in industry lacks reusability and interchangeability of domain application components. To develop a successful and dominant company in the ERP market, a strategic move to a component-based ERP design and marketing will be required. ERP vendors should be in a business of specifying the ERP components as well as building them. Once the design of specifications for ERP components is produced, manufacturing of each component can be outsourced to third-party developers.

Core Competencies of ERP Vendors

Currently, ERP vendors� core competency appears to reside in its conceptualizations of application domain knowledge in financials, manufacturing, distribution and others rather than the application development tools (e.g., OneWorld from J. D. Edwards). Even though they are making profits by selling the ERP software on different machines, there will be even more profitable and huge markets for specifying and producing various components of each application. Readers are reminded that automobile companies make huge profits specifying and selling the automobile parts (or components). For example, GM controls an automobile business by specifying how the third-party manufacturers produce the parts for GM cars and trucks. Controlling the standards for specifications of parts endows an intrinsic dominant power to GM. GM does not produce all the parts. GM basically controls the specifications of parts.

By breaking down a huge complex application package into many independently packaged components, we can sell each component to all types of customers. Customers of ERP products do not have to be a mid-sized company wishing to have the financial applications installed. We can expand the market to software developers and end-users as well as our traditional mid- to large-sized companies. For example, if we package the accounts receivable application as a separate independent product using DCOM (Distributed Component Object Model) standard in Microsoft Windows 98/NT environment, potential profits could be immense.

Component-Based ERP Design

What is important is that we need to rethink how we develop the applications. Software design should be more or less like designing and manufacturing automobiles. GM and Ford make money by specifying components and assembling cars as well as by manufacturing parts. ERP vendors should be prepared to design and sell components of applications as well as the final whole ERP solution. Packaging of each component needs to be done using the industry standards. Once we conceptualize and build each component, we can package it using Microsoft DCOM, OMG�s (Object Management Group) CORBA (Common Object Request Broker Architecture), SUN�s JavaBeans or whatever. ERP vendors are not in a business of setting the standards for packaging. Their strength should be in conceptualization and specification of components and packaging them in various forms.

Currently, most of conceptualizations of knowledge in application domains are already available in the forms of computer code and some high level designs. Unfortunately, however, they are frequently hidden and dormant. They are tightly coupled with the tools (e.g., OneWorld). What we need to do is to abstract the knowledge from the tools and specify each knowledge component independently of any tools. Then, each knowledge component can be manufactured using whatever tools in a massively distributed environment. Thereby, we can give a new profitable life to this latent asset of ERP vendors. We need to recreate and repackage the knowledge. For effective packaging and distribution, it is very important to adopt a distributed object-oriented approach in software development and to normalize the database systems.

More specifically, the following needs to be done: