Enterprise Resource Planning Systems

Definition of ERP System

Enterprise resource planning systems are packaged software to support corporate functions such as finance, human resources, material management, or sales and distribution (Slater, 1998). Most ERP packages also provide multiple language and currency capabilities, allowing operations in different countries to become more integrated.

Main Characteristics of an ERP System

Despite the differences existing among ERP products, most enterprise resource planning systems share a number of common characteristics, both from a technological as well as a business perspective.

From a technological perspective, the characteristics include:

• Client/server, open systems architecture. Nearly all ERP systems employ client/ server technology, separating the core processing and data management—which are carried out by the server(s)—from the user interface—done by the clients. Connection between servers and clients is usually provided through a local/wide area network. Consequently, most ERP packages follow an open systems architecture that separates data, application, and presentation (user interface) layers, guaranteeing cross-platform availability and systems integration. As a consequence, the data management system of an enterprise resource planning system is not addressed by the ERP package itself but relies on third-party database software. Finally, a separated presentation layer provides a common user interface across different technological platforms. Figure 1 depicts the Client/Server architecture of an ERP system and the separation into layers. Finally, in order to interoperate with existing business applications or information systems, most of the ERP systems in the market adhere to most of the common standards for data exchange or distributing processing, such as XML, DCOM, OLE, etc.

  
  Figure 1: Client/Server Architecture of ERP Systems.

• Enterprise-wide database. One of the most distinguishable characteristics of ERP as compared with traditional information systems is the strong centralization of all relevant data for the company. Usually, centralization not only means logically centralizing but also physical centralization as well. When the physical centralization is not possible, synchronization mechanisms among the different databases should be implemented in order to ensure data consistency throughout the entire enterprise.

• Kernel architecture. Some ERP systems support more than 1,000 different business functionalities (Bancroft et al., 1998), covering nearly all relevant business aspects for most of the enterprises. Indeed, it has been claimed that on the average an enterprise employing an ERP package is using only 10 percent 15 percent of the system's functionalities. To efficiently handle the enormous number of business features, most ERP systems are designed under a kernel-based architecture. The application layer (the ERP server) contains the basic features for system management and communication with the presentation and the data layers. Therefore, most of the features of the ERP system are not kept in the server's main memory but are stored independently, usually in the database layer. When a user requires a certain feature of the ERP server via the presentation layer, the kernel loads that feature in the application server so it is available for the user. Often, these stored functionalities are not saved as executable programs but as source code of a proprietary, fourth generation, programming language (such as ABAP/IV in the case of SAP R/3). Therefore, the mission of the kernel is also to serve as interpreter of the language for the users. Storing the functionalities as source code in the ERP system's database allows their easy updating—either by the vendor or by the enterprise—as well as providing a point to develop new functionalities not originally covered by the ERP package. The latter is usually facilitated by an Integrated Development Environment (IDE), which is also packaged in most ERP products.

• Multi-enterprise environment. Most of the ERP systems may separately store the business data and procedures from several non-related enterprises. This is relevant not only from an Application Service Provider (ASP) perspective but also for a single enterprise. This feature allows maintaining several separated workspaces (i.e., testing and production environments) so the current operative system is kept in the production environment while modifications of the current system are being made. The modified version must be first debugged in the testing environment and subsequently 'transported' to the production environment once it is free of bugs. On the other hand, most ERP systems allow the creation of related companies that, although seen as independent entities from a legal/taxes viewpoint, also belong to the same enterprise or group of companies, thus it may be useful to offer consolidate results. Here, the above mentioned multiple currency and country capabilities of ERP systems are of maximum interest.

From a business perspective, the characteristics include:

• Process-oriented, business reference model. ERP is process-oriented software. That means that it does not recognize individual functions rather than a series of functions that carry out an overriding task by providing the customer with a meaningful result (Kirchmer, 1999). Implicit to this is that process orientation is more efficient than the once prevailing function orientation of the software and organizations. On the other hand, as packaged software that intends to efficiently support all relevant business functions of an enterprise, all ERP systems have been developed starting from an implicit or explicit business reference model in order to appropriately describe at a high level the relevant business functions covered by the ERP system. For most ERP vendors, this model is explicit and takes the form of the 'best practices' extracted from the ERP vendor experience. This has a number of advantages. First, as a high level description of the business logic underlying the ERP system, it may be easily understood for the enterprise personnel without the need of ERP training and, therefore, may be used in the configuration process as an interface between the enterprise personnel (non experts, in general, on the logic of the ERP system to be implemented), and the ERP consultants (which, in contrast, are experts regarding the ERP system logic but are not familiar to the enterprise's specific business processes). Secondly, it can be used to analyze and evaluate current business processes in the enterprise prior to the implementation of the ERP package, serving thus as benchmark processes for business process reengineering (BPR).

• Adaptation to the enterprise. Because ERPs are designed to operate in different companies, they should allow the adaptation of the system to the specific enterprise needs. Besides, they should support the changes in the enterprise information requirements as the enterprises change through time. In order to meet the specific requirements of a specific enterprise, ERP systems are highly configurable. That means that all specific requirements such as the enterprise's fiscal year, its costs structure, the wages schemes or the depreciation procedures, have to be customized to fit the enterprise's business procedures. The customization process may take several months, or even years, depending on the enterprise. Besides, for most of the cases, the bulk of the customization process is not carried out by the enterprise staff but from an ERP-implementation consultancy firm, who must work closely together with the enterprise's employees. The configuration process is a key issue in ERP implementation and greatly influences success or failure for the subsequent ERP operation.

• Modularity. Although conceived as an integral, process-oriented solution for the enterprise, most of the ERP packages are composed of a set of function-oriented, tightly-integrated modules which in many cases can be separately purchased and installed. Typical modules are the financial/accounting module, production/manufacturing module, sales/distribution module, or human resources module. The main reason argued for modularity by the ERP-vendors is easing the integration of the new ERP system with existing information systems.

Evolution of ERP Systems

The early stage of ERP was carried out in the middle of the seventies through Materials Requirement Planning (MRP) systems (Orlicky, 1975). The focus of MRP software is on production planning, calculating time requirements for sub-assemblies, components, procurement, and materials planning. Originally, these systems assumed in their calculations infinite resource capacity and, therefore, quite often produced unfeasible schedules. A next step was given by Capacity Requirements Planning (CRP) systems, where several loops were executed until feasible schedules were found. The next generation of these systems was introduced by the middle of the 1980s under the name of Manufacturing Resources Planning or MRP II. MRP II systems crossed the boundaries of the production functionality and started serving as Decision Support Systems as well as Executive Information Systems, supporting not only manufacturing but also finance and marketing decisions.

Current ERP systems appeared in the beginning of the 1990s as evolved MRP II, incorporating aspects from CIM (Computer Integrated Manufacturing) as well as from EDP (Electronic Data Processing). Therefore, ERP systems become enterprise-wide, multi-level decision support systems. Currently, the term ERP II is sometimes used to define the next-generation ERP systems supporting cross-enterprise functions such as Customer Relationship Management (CRM), Supply Chain Management (SCM), or e-business capabilities. Figure 2 depicts the evolution of ERP systems.

Figure 2: Evolution of ERP Systems.