Our aim here is to advance a new approach to the rapid development of enterprise resource planning (ERP) systems using an OO mapping system. The OO approach combines methods for process modeling and organizational design that eliminate much of the time-consuming and costly manual customization characterizing deployment of many ERP systems.
We have developed and now offer the Enterprise Object Model (EOM) as a framework and mapping method for capturing user requirements in general terms, transforming them into detailed configuration settings for ERP software. For users and IT support staff, the effect is a dramatic reduction in the configuration effort and in the cost of maintaining such systems. We also describe a limited working EOM prototype we developed in Java.
EOM promises significant support for ERP system development and maintenance, thanks to a model of abstraction similar in some respects to the widely used database model. This abstraction model improves the ability of both user managers and nontechnical users to configure ERP systems through high-level statements of business requirements. EOM is also product-independent, separating specific ERP product-configuration details from functional objects that embody user requirements.
Cost and Complexity
Most Fortune 1,000 companies and an increasing number of their midsize counterparts employ ERP software to support major organizational functions, including sales, distribution, financial management, manufacturing, and human resource management. The appeal of ERP software is its integration of extensive functionality within a unitary software package in which all modules readily exchange information. ERP systems span extended supply chains to customers, suppliers, and business partners [1]. In 2002, the worldwide market for ERP software was $21 billion, according to AMR Research, which expects it to reach $32 billion by 2006. Leading ERP software packages include SAP R/3, PeopleSoft, and Oracle Applications.
ERP systems are radically different from the systems that preceded them; prior to today’s ERP software suites, most such software was custom-written or inflexible, off-the-shelf, and intended for narrow applications. MIS managers found deploying ERP systems inherently complex and costly, typically requiring inordinate effort (both human and financial) to deploy and maintain [5].
Compounding package complexity is the lack of a theory base to guide development of the systems in practice. Many of the individual modules contain built-in optimization subroutines and algorithmic solutions (such as the MRP routines in SAP R/3’s Production Planning module and the forecasting routines in SAP’s Materials Management module) [3]. However, no matter which vendor’s software suite is used, ERP software requires extensive customization in order to roll out production systems for two main reasons:
- Gap-fit analysis. ERP solutions are implemented in a variety of organizations, each with its own unique set of requirements and processes. The gap-fit analysis that typically accompanies a development effort represents a major financial drain.
- Complex master data specifications. Using SAP R/3 as an example, note the special complexity of master data, or the manual input of dynamic data (such as material pricing, temporal sales promotions, and changing reporting structures).
One option for developers is to avoid extensive customization and use the default or base functionality in the ERP software. Many application service providers, including Corio and USInternetworking, that offer ERP applications on a rental basis use this model. In essence, the organization renting the application accepts the constraints imposed by limited customization to the core ERP package in order to rent the ERP application [6]. But the downside is clear. If the organization’s unique processes enabled it to gain a competitive advantage in its industry or are better suited to its culture, the advantage is lost [4]. Moreover, this approach does little to aid another type of customization—the constant modification of dynamic data to reflect changing processes.
The lack of abstractions and models to assist in both areas of customization is responsible for many implementation cost overruns and ERP system failures [4]. Customization tends to be an arcane process, requiring deeply knowledgeable experts in specific modules who tend to be extremely expensive resources. Their knowledge is also seldom retained by the deploying organization, which must often maintain a standing army of such experts.
Here, we propose the development of an OO-based model to tackle the twin problems of customization of ERP software and scalability of ERP solutions. Inputs to this model consist of high-level user and organizational requirements, whereas outputs are specific changes to a system’s configuration. When given high-level user requirements through the user interface, EOM employs three tasks to transform these requirements into configuration specifications of the ERP package:
- Internal representations of user requirements;
- Built-in representations of configuration settings for the ERP package; and
- Mappings or transforms between the two sets of representations.
Addressing all three, EOM provides a number of capabilities, including encapsulation, inheritance, and polymorphism, to help create abstractions of user requirements and transform organizational requirements into detailed specifications or configuration settings for ERP systems.
Cheaper, Easier, Simpler
This modeling approach is preferable to either low-level ERP customization or modifying processes to fit the base ERP software. Each approach involves significant negative consequences, including cost (in the former) and loss of the organization’s best processes (in the latter). Our proposal makes for cheaper, faster, and simpler design of ERP systems, thus enabling organizations to preserve their best processes.
The key is the set of abstractions developed to represent and transform high-level user requirements into configuration settings for the ERP software. These abstractions are derived OO concepts and provide an effective way to deploy and maintain scalable enterprise systems.
Our approach is also applicable across different ERP software platforms, as its formalisms can be developed in a vendor-neutral format. We use Java as a tool for representing business processes and transforming high-level problem descriptions into configuration settings for ERP software.
Another major benefit of our approach is it enables the direct involvement of both functional area users and managers in the ERP development process. This convenience results from high-level statements of customization requirements, instead of the arcane, low-level customization settings of typical ERP packages. As the volume of transactions increases, along with the number of dynamic data structures, management effort remains low due to the higher-level objects accomplishing more of the customization effort.
Based on OO Principles
EOM is a means of modeling organizational structures and processes and detailing the specification of ERP systems effectively and efficiently. EOM comprises four layers—user interface, enterprise functions, enterprise schema, and ERP solutions—described in the following paragraphs (see Figure 1). They are analogous to the layers of the database model, a framework accepted and propagated throughout the design community [2].
User interface. The first layer enables users and managers to interact with the EOM model in order to configure ERP systems. Replacing the traditional Data Manipulation Language in the database model is a GUI with check boxes, pull-down menus, and list boxes. This interface allows configuration preferences to be acquired by the system in a user-friendly, high-level way. The data is then passed to the next layer, the enterprise functions layer.
Enterprise functions. This layer defines the major data sets and functions common across all commercial ERP packages. These definitions exist in the form of objects (representing data and methods) in a vendor-neutral fashion; for example, most ERP packages include common objects for pricing, order, delivery, and controlling area. Choices made through the user interface are mapped onto this layer. The objects in turn map onto the enterprise schema layer.
Enterprise schema. This layer straddles the generic enterprise objects and the layer of implementation-specific objects. It provides a mapping between the generic objects at the second layer and the ERP solution-specific objects in the final, or ERP solutions, layer. It is broadly equivalent to the concept of the schema in the database model and performs an analogous function. The Data Definition Language also consists of objects.
ERP solutions. The fourth and final EOM layer consists of implementation-specific objects combining configuration data and processes specific to individual ERP products (such as SAP R/3 and PeopleSoft); for example, R/3 and Peoplesoft would have separate pricing objects, as shown in Figure 1. It is analogous to the database model’s physical layer and includes various storage media and drivers (such as tape, hard disks, and CD-ROMs); each reflects a different form of storage organization, but the mappings between the schema and the (database) physical layer handle the differences. Therefore, the user input from EOM’s user interface is transformed into configuration settings for specific ERP packages, as shown in Figure 1.
Justification
An OO approach is particularly effective for helping create a schema for designing enterprise applications for several reasons:
- Unsatisfactory data-only approach. A data-only approach would be unsatisfactory for describing both abstract and implementation-specific entities. Methods are required to represent the functionality found in most enterprise entities; for example, in defining pricing in, say, SAP R/3, the condition technique, which is used for pricing, is part and parcel of the pricing structures themselves. Therefore, objects represent an ideal mechanism for enterprise modeling.
- Shared commonalities. In enterprise packages, many entities share common features and functions. Citing the pricing example again, but at a somewhat higher level, customer discounts, material discounts, and other types of discounts share intrinsic similarities (such as quantity discounts and pricing units). Inheritance can therefore play a critical role in managing the complexity of enterprise representations.
- Inherited properties. Many enterprise entities change over time, possibly inheriting the properties of multiple parent entities; for example, the customer/material discount has properties of both material and customer discounts. Multiple inheritance/polymorphisms support this feature in enterprise modeling.
The following example of an ERP configuration involves pricing and demonstrates the EOM approach to enterprise modeling. It assumes the user wants to create material discounts for all motorcycles sold in a specific sales area, as well as customer discounts for all customers in the same area. It steps through all four levels of EOM in order to configure pricing for an ERP package. For the ERP-specific layer, SAP R/3 is used as the example.
User interface. The user is asked several questions and presented with check boxes indicating various options. Instructions include:
- Select all categories of products the pricing mechanism applies to;
- Select the subgroups of customers to whom the pricing mechanism applies (such as by sales area, product line or division, and distribution channel);
- Select types and size of surcharges allowed during pricing (such as for freight); and
- Select types and size of discounts allowed during pricing (such as for material and customer discounts).
Enterprise functions. Data acquired through the user interface is stored in the form of objects representing pricing entities. Narrowing the focus to discounts, EOM selects several pricing-related objects. Java is used as a means of defining these objects for the purpose of the proposal. The object classes are:
- Discount. Defines the parent class for all discounts;
- Customer discount.Defines customer discounts;
- Material discount. Defines material discounts; and
- Customer-material discount. Defines a discount for one customer for one product only.
Figure 2 outlines the class hierarchy, demonstrating it is possible to create a set of objects capable of representing entities in enterprise models; though rudimentary, it also demonstrates the approach built into EOM.
Enterprise schema. The data collected from the enterprise functions layer is mapped to objects specific to an ERP implementation (such as SAP R/3 and Peoplesoft). The abstract is mapped to the specific; for example, a material-discount object is mapped to a K004 material discount in R/3 with the following settings:
K004 (R/3 Material Discount):
– Unit of Discount: Percentage
– Volume discount: Yes
– Discount Level: 5% off
A customer discount can also be mapped to a K007 customer discount in R/3, with the following settings:
K007 (R/3 Customer Discount):
– Unit of Discount: Percentage
– Volume discount: No
– Discount Level: 3% off
ERP solutions. The ERP-specific configurations (such as the K004 and K007 settings) are applied directly to the ERP software, thereby configuring the ERP system. This configuration interface application involves published application programming interfaces available for the major ERP packages in the formal EOM proposal.
Running the program, the user selects from the following menu choices (see Figure 3a):
Material list: Five materials numbered 1400-500-01 to 1400-500-05
Customer list: Three customers numbered 1300-01 to 1300-03
Sales organization: U.S.
Method of distribution: Retail
Product line (division): Automotive
Product grouping: Motorcycles
Material discounts: All items
Material discount %: 5%
Customer discounts: All customers
Customer discount %: 3%
The program’s output includes transaction codes and accompanying data for creating five material discounts in SAP R/3 (K004) and three R/3 customer discounts (K007). They may be entered directly into SAP R/3 or automatically through testing software interfacing with R/3 and running the data as scripts.
Figure 3(b) outlines how the configuration program is used in practice, outputting configuration data into a text or spreadsheet file. Each format is readable by an automated script-testing program (such as AutoTester). The script-testing program interfaces directly with R/3, automatically loading the configuration data and existing test scripts into R/3. R/3 then runs automatically, performing the input commands with the data.
Although the example includes only five materials and three customers, EOM’s advantages are readily projected onto situations involving thousands of materials and thousands of customers. With dialogue as efficient as the one in Figure 3(a), users can configure thousands of pricing records automatically or semiautomatically, yielding potentially significant savings in SAP R/3 (and other ERP) maintenance and configuration scenarios.
Conclusion
EOM deals with a critical issue concerning the future use of ERP. Despite their continuing popularity, difficulties have persisted in configuring and maintaining ERP systems; the costs of deployment and maintenance remain steep. The model uses OO concepts to create abstractions and mappings to enable nontechnical personnel to configure ERP systems.
Like the three-level database model, EOM employs OO formalisms to represent key ERP functions and translate high-level user requirements into specific ERP configuration settings. It employs a model of abstraction similar in some respects to the widely used database model, allowing configuration of ERP systems using high-level statements of business requirements. EOM is also product-independent, separating specific ERP product configuration details from functional objects embodying user requirements.
This approach is applicable across different ERP software platforms, as its formalisms are being developed in a vendor-neutral format. For the initial prototype, we used Java to represent business processes and to transform high-level problem descriptions into configuration settings for the ERP software. These descriptive tools enable users and managers to stay deeply involved in ERP development. As the volume of transactions increases, along with the number of dynamic data structures, the management effort remains minimal due to the use of high-level objects that accomplish more and more of the customization effort.
EOM will influence ERP system development and maintenance. Successful extension of the EOM prototype into a comprehensive system handling more configuration functions could result in significant savings in the configuration and maintenance of ERP systems for all types of users.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment