(ERP) operations support system for maintaining process integration

International Journal of Production Research, Vol. 43, No. 19, 1 October 2005, 3959–3982

Enterprise resource planning (ERP) operations support system for maintaining process integration K. PARKy and A. KUSIAK*z yDepartment of Business Administration, Hanyang University, Ansan, Gyung-Gi-Do, 425-791, Korea zDepartment of Mechanical and Industrial Engineering, 3131 Seamans Centre, University of Iowa, Iowa City, IA 52242-1527, USA

(Revision received March 2005) A successfully adopted and implemented enterprise resource planning (ERP) system does not automatically guarantee full benefits. It is important that ERP is operated as planned and thus provides the real-time information with a desired level of process integration. Any ERP system pushes a company toward full process integration and solves the fragmentation of information. However, the tight process integration involves operational issues that must be carefully managed. Thus, a conjecture can be made that a centrally coordinated support system is required to assist ERP users and administrators find problems, perform tedious validation and verification, and maintain the process integration of ERP with great consistency. This paper proposes an ERP operations support system (EOSS) that aims to achieve and maintain the process integration of ERP. EOSS monitors the operational status of process integration, prevents anomalies as early as possible and conducts repairs as soon as possible. Keywords: Enterprise resource planning (ERP) operations; Process integration; Operations support system; Agent

1. Introduction Enterprise Resource Planning (ERP) is recognized as the most imperative information technology (IT) infrastructure of modern companies (Shar et al. 2002). Recently, a range of technologies has emerged that can enhance the capability of ERP, e.g. sell-side e-commerce, electronic procurement, customer relationship management (CRM), supply chain management (SCM) and so on (James and Wolf 2000). Expanding e-business trends demand that manufacturing companies operate internal processes digitally and collaborate with their partners using standard interfaces (Foley 1999, Gilbert and Swear 1999, Scheer and Habermann 2000). Companies often fail to reconcile the technological imperatives of ERP with the business needs of the enterprise itself (Bingi et al. 1999) that lead to out-of-control

*Corresponding author. Email: [email protected] International Journal of Production Research ISSN 0020–7543 print/ISSN 1366–588X online # 2005 Taylor & Francis Group Ltd http://www.tandf.co.uk/journals DOI: 10.1080/00207540500140799

3960

K. Park and A. Kusiak

or failed ERP projects (Davenport 1998). This is because ERP, by its very nature, imposes its own logic on a company’s strategy, organization and culture (Davenport 2000). Asian companies might be more vulnerable to ERP failures because the reference process models underlying most ERP systems reflect European or US industry practices (Soh et al. 2000). As an example, the South Korean government in 2001 launched a funding programme to support 30 000 small- and medium-sized manufacturing companies to adopt ERP (SMBA 2003). The programme has been expanded to include SCM and advanced manufacturing systems by 2007. However, it is shown that most of the companies that adopted ERP have not been fully operating the system, although a formal survey on this issue has not been completed. In general, for a company to gain fully the benefits of ERP, it must follow a four-phase framework defined by Markus and Tanis (2000): project adoption, project configuration (implementation), shakedown (testing) and system operation. The earlier phases of the ERP life cycle have gained research attention, especially the adoption phase (Davenport 1998, Markus and Tanis 2000, Kumar et al. 2002) and implementation (Bingi et al. 1999, Holland and Light 1999, Markus et al. 2000, Hong and Kim 2002). Also, agreeing with an argument that the previous research on information system still holds for ERP-like new information technologies (Lee 2000), one could see that most of the previous empirical and field studies on IS success (Olson and Chervany 1980, Delone 1981, Cheney and Dickson 1982, Lehman 1985, Raymond 1985, 1900, Sanders and Courtney 1985, Ein-Dor and Segev 1978, Srinivasan and Kaiser 1987) are applicable to the earlier phases of the ERP life cycle. However, assuming that an ERP system is successfully adopted and implemented at the expected level in a company does not automatically guarantee the ultimate success of the ERP system because of some operational issues (discussed in detail in section 2). A recent empirical study on the relationship between the completeness of each of the ERP development phases and its impact on system performance reports that the final phase, system operation, has the most positive impact on the system performance (Park et al. 2002). So far, relatively little research has been conducted on successful ERP operations, the final phase of the ERP life cycle. Recently, the Model-driven Business Management (MDBM) environment (Gulla and Brasethvik 2002) was proposed to support system operations, maintenance and development effectively. Although the MDBM concept provides a useful framework for supporting dynamic and adaptable system operation and maintenance, it does not focus on process integration aspects of ERP operations and has limited functionality to support and train users, only concentrating on semantic lexicons and simple query interpretations. This paper proposes an ERP operations support system (EOSS) that aims at achieving and maintaining process integration of ERP at the highest possible level. With EOSS, the process execution is monitored, with anomalies prevented as early as possible and repaired as precisely as possible. The prototype system is geared toward Õ uniERPII though it is applicable to other ERP systems as well. UniERPII is an ERP solution for small- and medium-sized manufacturing companies developed by Samsung SDS which is one of the leading IT companies in South Korea.

ERP operations support system for maintaining process integration

3961

This paper is structured in six sections. Section 2 discusses four types of ERP operational issues. Section 3 presents the basic models and tasks that should be effectively performed to take full advantage of process integration in ERP systems. Section 4 describes the architecture and components of EOSS. Section 5 discusses the experiences that companies have had in the use of the system with an illustrative example. Finally, section 6 presents conclusions and suggestions for further research.

2. ERP operational issues Once adopting an ERP system, a company should prepare for costs due to differentiation among departments (Goodhue et al. 1992, Soh et al. 2000, Gattiker and Goodhue 2002). When the ERP system is implemented across differentiated departments even with well-planned designs, some departments may incur costs (Gattiker and Goodhue 2004). These costs include decreased operational performance or data relevance due to one or more departments having to use an ERP that is not well-tailored to the peculiarities of the tasks that the department must execute. However, these costs are still associated with issues of the ERP adoption. In successfully operating ERP systems, four types of ERP operational issues should be considered: propagation costs, continuous training, data quality and internal control. These issues eventually give rise to needs for supporting ERP operations. In order to work out the problems due to tight integration, to provide effective and continuous training, to ensure data quality, and to provide systematic internal control of business operations, a sophisticated ERP operations support system is required. 2.1 Propagation costs As a collection of highly integrated subsystems, ERP systems can be described as ‘tightly coupled’. To be sure, tight coupling facilitates coordination among subsystems and solves the fragmentation of information (Davenport 1998). As a result, it streamlines a company’s data flow and provides management with direct access to a wealth of real-time operating information. For many companies, these benefits have translated into dramatic gains in productivity and speed of business operations. However, as stated in Bingi et al. (1999), the tight process integration could propagate mistakes made in one department into other departments. Also, the original mistake is easily magnified due to the flow through the associated process chain. Due to such tight coupling, one ERP operational issue refers to propagation costs. A department encounters propagation costs due to modified transactions that have been referred by subsequent transactions of other departments. A modification to such a previous transaction must be well propagated to every single subsequent transaction so that none of these subsequent transactions refers to a non-existing or a wrong transaction. In some cases, the propagation cannot be executed easily when some of the subsequent transactions cannot be undone because the executions of the transactions are permanent, i.e. production orders for a sales order in a make-to-order manufacturing company have already been executed to actually make final products.

3962

K. Park and A. Kusiak

As described in the case study section, the propagation costs are high in companies with more complex relationships among processes. More complex relationships require involve propagation of more transactions. Thus, companies must be aware of the potential risk of ERP operations due to propagation costs. Proper policies need to be established, such as how to locate and modify the target transactions, how to compromise among departments when the modifications cannot be executed completely. A formal plan of action describing the steps to be taken if modifications are propagated is needed. Means to communicate to all the departments affected by the modifications as soon as they are attempted is extremely important. 2.2 Continuous training Training provides the hands-on mechanism that allows users of the ERP system to explore the system both from a technical as well as from a functional perspective (Amoako-Gyampah and Salam 2004). It allows the users to obtain first-hand information and experience. It also allows them to explore the perceived ease of use of the system. However, once an ERP system is deployed, consultants are to leave and the training stops there. Hence, operation managers must undertake strong and effective communication initiatives coupled with effective training on ERP systems (Cheney and Dickson 1982). The previous findings imply that an appropriate level of training for users greatly influences the success of ERP operations. Such training must be continuous. However, it has been shown that the training tasks become increasingly complex and indeterminate in nature and place increasingly heavy burdens on communication and decision making of systems management departments and end users (Thompson 1967). 2.3 Data quality Research on data quality has gained great attention since information systems started to be formally operated in manufacturing companies. Data quality is the measure of the agreement between the data views presented by ERP and that same data in the real world. Poor data quality at the operational level increase operational cost because time and other resources are spent detecting and correcting errors (Redman 1996). With much tighter integration incorporated, ERP systems suffer more from poor data quality than conventional functional information systems. However, to ensure data quality, conventional data quality approaches employ control techniques such as edit checks, database integrity constraints and program control of database updates. These approaches have improved intrinsic data quality substantially, especially the accuracy dimension (Strong et al. 1997, Redman 1998). Attention to accuracy, which concerns only the consistency of data values, alone does not correspond to data consumers’ broader data quality. Furthermore, controls on data storage are necessary but not sufficient. Beyond the intrinsic aspects of data quality, the focus on data quality in ERP operations should extend to contextual and accessibility data quality issues. Examples of contextual data quality issues in operating ERP are missing data, inadequately defined or measured data and data that could not be appropriately aggregated. The major dimension of the

ERP operations support system for maintaining process integration

3963

accessibility data quality category in operating ERP is timeliness that assures relevant data should be provided in a timely manner. Positing that a mechanism synchronizes the data in the system with changes in the real world must be in place, some research proposed a real-world feedbackcontrol system (FCS) with data quality rules (Orr 1998) and a total data quality management framework (Wang 1998), aiming at increasing the use of the data. The previous research on improving data quality should be incorporated into successful ERP operations. 2.4 Internal control In recent years, in response to tightened regulatory requirements and more cost-competitive auditing practices, there has been considerable interest in improved support for data quality assessment (Kaplan et al. 1998). In order to establish public company accounting and investor protection, needs for internal control over ERP systems are emerging. As the Securities and Exchange Commission implements the internal control Provisions of section 404 of the Sarbanes-Oxley Act of 2002 (SEC 2003), public companies should provide financial statements and maintain records that are reasonably detailed and fairly reflect the transactions and dispositions of the assets of the registrant. Internal control is broadly defined as a process, affected by a company’s board of directors, management and other personnel, designed to provide reasonable assurances regarding the achievement of objectives (COSO 2004). Internal control consists of five interrelated components. These are derived from the way management runs a business and are integrated with the management process. Although the components apply to all companies, small- and mid-sized companies may implement them differently than large ones. Its controls may be less formal and less structured, yet a small company can still have effective internal control. The components are control environment, risk assessment, control activities, information and communication, and monitoring. Although the needs for internal control emerge from accounting and financial perspectives, the scope of internal control encompasses all business processes of a company as their performance results in accounting reports. Thus, a proper means for monitoring risk factors embedded in ERP operations must be established in order to perform the internal control. Every number appearing in an accounting report is aggregated from a series of transaction data accumulated on ERP on daily basis. A small error in daily ERP operations may end up with totally unexpected disastrous results in account reports.

3. Process integration perspective of ERP operations 3.1 Process integration model A fully adopted ERP system consists of process chains each of which represents a sequence of unit operations (functions) within a functional department. A process chain begins with its starting function, proceeds one by one to an intermediate function and ends with its finishing function. A process chain in a department can

3964

K. Park and A. Kusiak

be related to process chains of other departments such that the progress of the process chain may depend on the progress of the other related process chains. As the result of function executions, transaction data can be produced and modified. As functions and associated process chains are interrelated, the transactions reference each other resulting in a great complexity interrelationship. From the process integration point of view, ERP can be modelled with PROCESS CHAIN TYPE, PCLINK, FUNCTION, FLINK and TRANSACTION DATA TYPE classes, as shown in figure 1. This process integration model represents the fundamental definitions to abstract the process integration: integration objects, the relationships among them and the cardinalities of the relationships. The classes are formally defined below. Definition: ERP is an ordered triple (P, PL, g) where P is a non-empty set of PROCESS CHAIN TYPEs; PL is a set of PCLINKs; g is a set of FUNCTIONs associating with each PCLINK pl an ordered pair (p1, p2) of PCLINKs where p1 is the predecessor PROCESS CHAIN TYPE and p2 is the successor PROCESS CHAIN TYPE of the pl. Definition: PROCESS CHAIN TYPE is a totally ordered triple (F, FL, h) where F is a non-empty set of FUNCTIONs; FL is a set of FLINKs; h is a set of functions associating with each FLINK fl an ordered pair (f1, f2) of FUNCTIONs where f1 is the predecessor FUNCTION and f2 is the successor FUNCTION of the fl. Since PROCESS CHAIN TYPE is totally ordered, it has a start and a finish FUNCTION and, therefore, must be executed in a strictly sequential order from the start FUNCTION to the finish FUNCTION.

ERP

1..* PROCESS CHAIN TYPE processChainTypeNo; processChainTypeName; startFunctionNo; finishFunctionNo; create(); getStartFunctionNo(); getFinishFunctionNo(); getNextFunction(fn); getPreviousFunction(fn);

TRANSACTION DATA TYPE

FUNCTION

1..*

1..*

1..*

PCLINK

functionNo; functionName; transactionDataNo; predecessorFLinkNo; successorFLinkNo; predecessorPcLinkNo; successorPcLinkNo;

1..* 1..*

1..*

getPcRelationType();

Figure 1.

1..*

create(); getPrimaryKey();

create(); getTransactionDataNo(); getNextFunctionNo(); getPreviousFunctionNo(); getNextPcLinkFunctionNo(); getPreviousPcLinkFunctionNo(); getpredessorFLinkRelationType(); getsuccessorFLinkRelationType(); getpredessorPcLinkRelationType (); getsuccessorPcLinkRelationType();

pcRelationType;

transactionDataTypeNo; primaryKey; headerTableID; itemTableID;

1..* FLINK

1..*

linkNo; linkType; predecessorFunctionNo; successorFunctionNo; relationType; create(); getPredecessorFunctionNo(); getSuccessorFunctionNo(); getrelationType();

ERP process integration model in UML.

ERP operations support system for maintaining process integration

3965

Definition: A PCLINK is a unary relation on P and connects two PROCESS CHAIN TYPEs. It is a specialized form of FLINK that will be defined below. Two types of PCLINKs are defined: Unconstrained: the predecessor PROCESS CHAIN TYPE can proceed regardless of the status of the successor PROCESS CHAIN TYPE. . Constrained: the predecessor PROCESS CHAIN TYPE can proceed only after the successor PROCESS CHAIN TYPE finishes completely. .

Definition: A FUNCTION is symbolized by f: V ! T, where V is the domain of input values and T is the range of TRANSACTION DATA TYPEs. It is a fundamental unit of ERP operations that creates a TRANSACTION DATA TYPE as a result of its execution and references its predecessor FUNCTION except start FUNCTIONs. Thus, given a set of FUNCTIONs, F, a binary relation on F is defined as FLINK that is defined below. Definition: A FLINK defines a binary relation on F & T. That is, it connects two adjacent FUNCTIONs or TRANSACTION DATA TYPEs. Four basic types of relations are defined in terms of the cardinalities of relationships: separate (one-to-one); consolidated (many-to-one); split (one-to-many); and split & consolidated (many-to-many). Definition: A TRANSACTION DATA TYPE defines a data type that is created as a result of a FUNCTION execution. Given a set of TRANSACTION DATA TYPEs, T, a binary relation on T is defined as FLINK. In that sense, the relations on T and F, respectively, are isomorphic. In most cases, TRANSACTION DATA TYPE is defined as a ‘header-item’ structure: a header record with multiple associated item records. Thus, TRANSACTION DATA TYPE is created in a ‘stereotype’ structure: header-items. However, for the simplicity, the structure is implicitly embedded in the model. A typical process integration model of ERP consists of Sales, ProductionPlanning, QualityAssurance, Payment, Purchasing, Outsourcing, Production PROCESS CHAIN TYPEs each of which in turn is composed of a set of FUNCTIONs with PCLINKs, respectively. For example, the Sales PROCESS CHAIN TYPE starts with Order Entry FUNCTION and finishes with Invoicing FUNCTION. It is connected to three other PROCESS CHAIN TYPEs such as Production Planning, QA (Quality Assurance), and Payment. The PCLINK from RequestDelivery to QA PROCESS CHAIN TYPE is constrained because Shipping FUNCTION can start only after QA PROCESS CHAIN TYPE finishes. On the other hands, the other two PCLINKs from Order Entry and Invoicing FUNCTION are unconstrained because those PROCESS CHAIN TYPEs can proceed independently.

3.2 Process instantiation model Having defined the process integration model, the paper explores the operational aspect of process integration of ERP and presents a process instantiation model. While the process integration model shows the fundamental definitions of the process integration, the process instantiation model abstracts actual instances of ERP operations by PROCESS CHAIN, TRANSACTION DATA HEADER,

3966

K. Park and A. Kusiak PROCESS CHAIN pcNo; processChainTypeNo; startDate; finishDate;

TRANSACTION DATA HEADER

1..*

1..*

getAllTransactionData(); getState(); computeState(); computeDuration(); TRANSACTION DATA ITEM

1..*

trNo; itemNo; foreignKeyTableID; foreignKeyValue; state; computeState(); getTransactionData(); findPropagationTris();

1

triNo; transactionDataTypeNo; functionNo; primaryKeyValue; firstItemNo; lastItemNo; trType; trDate; trSQL; getTransactionData(); getReferencingTdiNos(); getReferencedTdiNos(); computeState(); getNextItemNo(in); getPreviousItemNo(in);

1..*

1..*

Figure 2.

Process instantiation model in UML.

and TRANSACTION DATA ITEM classes, as shown in figure 2. Next, the internal structure of TRANSACTION DATA TYPE is explicitly represented in the process instantiation model. It should be noted that FUNCTION executions are omitted to simplify the model. Also, we will use TRANSACTION DATA as the single term to comprehend TRANSACTION DATA HEADER and TRANSACTION DATA ITEM. The classes of the process instantiation model are defined below. Definition: A PROCESS CHAIN is an actual instantiation of the corresponding PROCESS CHAIN TYPE and comprises of a series of TRANSACTION DATA. Definition: A TRANSACTION DATA HEADER is the general information about the transaction itself such as transaction number (primary key), transaction date, user, etc. Since a PROCESS CHAIN involves many FUNCTIONs to execute, it is associated with many TRANSACTION DATA (HEADER). Also, since a TRANSACTION DATA (HEADER) includes many TRANSACTION DATA ITEMs each of which is created by other PROCESS CHAINs, there exists a many-to-many relationship between PROCESS CHAIN and TRANSACTION DATA (HEADER) classes. Definition: A TRANSACTION DATA ITEM belongs to a TRANSACTION DATA HEADER and, therefore, is created only when the TRANSACTION DATA HEADER is created. Normally, many item instances are created for a particular header instance. A PROCESS CHAIN is instantiated when a user executes its start FUNCTION and wants to save the transaction. Actually, from the same start FUNCTION, many different instances of PROCESS CHAIN TYPEs can be instantiated. For example, various sales PROCESS CHAINs can be instantiated from OrderEntry

ERP operations support system for maintaining process integration

3967

FUNCTION: DomesticSales, ExportSales, Local L/CSales, Refund, etc. Thus, the target PROCESS CHAIN TYPE for the instantiation is identified as a user enters data into a ‘hub’ control (i.e. text box) of the start FUNCTION. The value of a hub control decides which PROCESS CHAIN TYPE should be instantiated from the program execution. For example, when a user enters ‘DSO(Domestic Sales Order)’ into the SalesType control in OrderEntry program (FUNCTION) in Õ uniERPII, a DSO(Domestic Sales Order) PROCHAIN CHAIN is created. After a PROCESS CHAIN is created, a series of TRANSACTION DATA HEADERs and their dependent TRANSACTION DATA ITEMs are created by executing the associated FUNCTIONs. Those TRANSACTION DATA are interrelated with each other sequentially as defined in the corresponding PROCESS CHAIN TYPE. The interdependency of TRANSACTION DATA is transitive such that if B refers to A, C refers to B, then C refers to A through B. Thus, it is possible for a PROCESS CHAIN to track all transitive TRANSACTION DATA associated with. The longer span of a PROCESS CHAIN TYPE results in the longer chain of TRANSACTION DATA. Admitting that most TRANSACTION DATA are unforgiving data that have little margin for error (Wallace and Kremzar 2001), one can see that effective support systems must be devised because operational mistakes and errors in the process of creating TRANSACTION DATA increase the propagation costs. For management purposes, it is assumed that a PROCESS CHAIN becomes ‘complete’ when its TRANSACTION DATA created by its first FUNCTION are ‘completely referenced’ by the subsequent TRANSACTION DATA. Here, ‘completely referenced’ implies that the TRANSACTION DATA are referenced completely by any successor TRANSACTION DATA so that no more direct and transitive references are possible. Thus, a PROCESS CHAIN is in one of two states: {incomplete, complete}. With the FLINK types defined, four types of interdependencies of TRANSACTION DATA can be defined: separate (one-to-one); consolidated (many-to-one); split (one-to-many); and split and consolidated (many-to-many).

3.3 Abnormal use cases In practice, PROCESS CHAIN TYPEs do not always proceed as defined. A PROCESS CHAIN TYPE specifies, in fact, a normal execution flow of its FUNCTIONs included. However, there are abnormal use cases as defined in Jacobson (1992). For the executions of any PROCESS CHAIN TYPE, it must be anticipated that cancellations or corrections take place. Such abnormal use cases represent modifications of the whole or a part of previous executions. However, the cancellations or corrections cannot be performed in an isolated fashion due to the nature of tight process integration. Especially, when a particular PROCESS CHAIN proceeded to the later FUNCTION and one of the earlier FUNCTIONs must be cancelled or modified, users normally have difficulties in finding what particular TRANSACTION DATA must be updated exactly. Although most ERP systems provide online status information of a particular PROCESS CHAIN, it is not enough to help users complete such abnormal transactions easily.

3968

K. Park and A. Kusiak

For example, price errors on purchase orders could mislead financial analysts by giving a distorted view of how much the company is spending on materials. Companies must be aware of the potential risks of the errors and take proper steps, such as monitoring the transactions and taking immediate steps to rectify the problems should they occur. They must also have a formal plan of action describing the steps to be taken if an error is detected. A proper means to communicate to all the parties who are victims of the errors as soon as the errors are detected is extremely important. Consider another example of a Korean manufacturing company that has implemented the ERP software. Suddenly experiencing a shortage of manufacturing materials, production managers noticed that it was due to incorrect bills of materials and made necessary adjustments. However, the company did not have any procedures to notify others of the error. The domino effect of the errors had already affected other functional areas. It took almost 8 weeks to clean up the incorrect bills of materials in the database. Furthermore, many different users or user groups from different departments may execute the same PROCESS CHAIN TYPE. It implies that potential communication problems may occur during the execution. As a PROCESS CHAIN proceeds, there exist potential delays and errors due to hand-offs. Apparently, abnormal use cases make these problems worse. Abnormal use cases can be classified into two types: deletion and update. A deletion must take place in a part of TRANSACTION DATA of the corresponding normal PROCESS CHAIN TYPE and proceed in the opposite direction. Actually, the range of the whole deletion is defined dynamically, depending on the state of the corresponding PROCESS CHAIN TYPE and the FUNCTION where the original deletion takes place. Sometimes, a different PROCESS CHAIN TYPE is defined for an abnormal use case rather than undoing the previous executions. For example, Refund PROCESS CHAIN TYPE is for cancelling (deleting) a previous Sales PROCESS CHAIN TYPE, when the Sales PROCESS CHAIN TYPE is ‘complete’. Updates occur in many different results. A simple update can take place in a FUNCTION for a particular TRANSACTION DATA TYPE without involving other FUNCTIONs. A propagation update is more complicated such that all the TRANSACTION DATA that are referencing the target TRANSACTION DATA must be updated. A deletion update is one that can be accomplished only by deletions. There are two ways to carry out the deletion update. One way is to use a diversion FUNCTION that is an additional FUNCTION for a special update. The diversion FUNCTION is employed when the PROCESS CHAIN is ‘complete’ so that deletions for the update must take place in the entire PROCESS CHAIN. Another way is to delete the first affected TRANSACTION DATA from the propagated FUNCTION back to the original update FUNCTION and then recreate TRANSACTION DATA from the original update FUNCTION forward to the propagated FUNCTION. The definition of abnormal use cases is embedded in the process integration model in figure 1. The FUNCTION class where an abnormal use case take place must know how to proceed and thus provide the information of the appropriate sequence (i.e. opposite direction to the normal use cases) of FUNCTION execution for either deletion or update. Also, with such definitions, the range of updates is identified by the process instantiation model. For example, the

ERP operations support system for maintaining process integration

3969

Users

P1

P2

…

Pn

IA Instance agent

User interface

B1

B2

…

SA Support agent

RA

MA

Bn

Business logic

Monitoring agent

Report agent

Transaction data

Operation data

Database

Database

ERP System

EOSS

Figure 3.

Agent EOSS architecture.

findPropagationTris() operation defined in TRANSACTION DATA ITEM class in figure 3 generates a list of TRANSACTION DATA that must be updated completely.

3.4 Metrics and anomalies of the process integration Process integration of ERP involves a great deal of complexity. The fundamental nature of enterprise information integration is thoroughly investigated in Giachetti (2004). The operational complexity in manufacturing is defined (Frizelle and Woodcock 1995, Frizelle 1998) and recently expanded to operational complexity between partners within a supply chain (Sivadasan 2002). In this paper, we define metrics to evaluate the status of the ERP operations. The first category of the metrics is concerned with the fundamental complexity of ERP operations. In this category, the following metrics are defined: the fundamental complexity of the process integration (FCPI), the number of PROCESS CHAIN TYPEs (NPC); the number of FUNCTIONs (NF); the number of TRANSACTION DATA TYPEs (NTD); the number of FLINKs (NFL) and the number of PCLINKs (NPCL) for each link type, respectively. These metrics are used firstly to compute the fundamental complexity of the individual process chain (FCPC) and then all the FCPCs are added up to FCPI. A simple computation model of FCPI and FCPC can be formulated as equations (1) and (2), respectively: FCPI ¼

N X i¼1

FCPCi ,

ð1Þ

3970

K. Park and A. Kusiak

where N is the total number of NPCs: 4 X ðwij
ðNFLij þ 2
NPCLij ÞÞ, FCPCi ¼

ð2Þ

j¼1

where if link type ¼ separate, j ¼ 1; if link type ¼ consolidated, j ¼ 2; if link type ¼ split, j ¼ 3; if link type ¼ consolidated and split, then j ¼ 4; wi1 ¼ 1, wi2 ¼ wi3 ¼ 2; wi4 ¼ 4. The level of FCPI of a company can be computed against the reference FCPI. For an ERP system, the maximum level of the FCPI can be computed assuming that all of the process chains are associated with the most complex link types. Thus, the formula for the FCPI level for a company P (FCPILP) can be designed as equation (3): FCPILP ¼

FCPIP , FCPIR

ð3Þ

where FCPIP is the FCPI of a company P, FCPIR is the maximum FCPI of the ERP system. The second category of the metrics is concerned with the operational complexity of ERP operations for a given period. In this category, the following metrics per each PROCESS CHAIN TYPE are defined: the number of complete PROCESS CHAINs (NCPC); the number of incomplete PROCESS CHAINs (NIPC); the average duration of complete PROCESS CHAINs (ADPC); the maximum duration of complete PROCESS CHAINs (MDPC); the number of abnormal PROCESS CHAINs (NAPC); the number of TRANSACTION DATA (NTD); the average number of TRANSACTION DATA per PROCESS CHAIN(ANTDPPC); the maximum number of TRANSACTION DATA (MNTD). The abnormal PROCESS CHAIN is defined for each PROCESS CHAIN TYPE as an instance which has not been completed within the normal cycle time. Such abnormality damages two different quality factors of ERP operations: cost and service. Abnormally delayed PROCESS CHAINs can increase business operation costs such as inventory holding cost, labour cost, equipment utilization cost, etc. On the other hand, the quality of customer services also can be degraded when just-in-time actions are not taken appropriately. The third category of the metrics is concerned with the work complexity of ERP operations for a given period. The monthly work complexity represents a workload of a particular user (or group) who is in charge of the execution of FUNCTIONs assigned for each month. In this category, the following metrics are defined: the number of TRANSACTION DATA of the predecessor FUNCTION that have been referenced completely (NTDIR) by each FUNCTION; the normal TRANSACTION DATA man day (NTDIMD); the total TRANSACTION DATA man day (TTDIMD); the number of TRANSACTION DATA of the predecessor FUNCTION that have not been referenced completely (NTDINR) by each FUNCTION. The NTDINR represents the backlog for the user (or group). Then, the monthly workload (MWL) of each user can be computed by equation (4): MWL ¼

AVGðTTDIMDÞ , SMD

where SMD is standard man-days in a month (i.e. 22 days in June).

ð4Þ

ERP operations support system for maintaining process integration

3971

With metrics defined above, the paper defines the anomalies embedded in process integration of ERP operations. The first type of anomaly is the fundamental complexity anomaly (FCA) and can be measured by FCPI or FCPC. FCA represents the overall complexity of the underlying ERP system operation, and, thus, occurs simply because the process integration is itself complex. The higher FCPI implies the higher FCA. This is because ERP systems inherently produce mass amounts of transaction data that are interrelated. The higher FCA implies more propagation costs, training costs, data quality management costs, and tighter internal control. The second type of anomaly is the operational complexity anomaly (OCA). OCA represents abnormal states of ERP operations due to either negligent or intended executions of FUNCTIONs by users. Each anomaly of OCA can be computed by the operational complexity related metrics defined above. For example, a PROCESS CHAIN may have been in a partially complete state for a long time. Such a symptom implies the longer process chain intervals that cause operators to forget to complete partially executed process chains. If an order was released a long time ago while picking required inventory of items and the delivery has not yet taken place, then, the items have been put on hold for nothing, causing substantial inventory holding costs. Such unprocessed data may result in a reduction in productivity of the organization (Ben-Arieh and Pollatscheck 2002). Thus, it should be pursued to reduce NIPC and shorten ADPC and ANTDPPC. The third type of anomaly is the work complexity anomaly (WCA). WCA is a kind of bottleneck symptom that the workload of a particular user (or group) is too high. If MWL is too high, then the quality of corresponding customer services must be low. There are three causes for this anomaly: Work overload: the workload of the user (or group) is too high. Under-skilled user: the user (or group) is not well trained to operate FUNCTIONs. . Over-complex process chain: the process chain is too complex for the user (or group) to operate adequately. . .

Therefore, the workload must be adjusted according to the causes: Workforce support: for work overload, work force must be added or adjusted. . Training: for under-skilled users, training sessions can cure the problem. . Process chain adjustment: for over-complex process chains, if possible, there is significant potential for simplifying the process integration, reducing the complexity to a manageable level for the user (or group). .

4. Architecture for EOSS 4.1 Support tasks Although ERP promised huge improvements in efficiency, for example, shorter intervals between orders and payments, lower back-office staff requirements,

3972

K. Park and A. Kusiak

reduced inventory, and improved customer service (Foley 1999, Gilbert and Swear 1999), installing ERP was traumatic. It is not always cost-effective to integrate all of an organization’s data and, therefore, some companies try to integrate partially to achieve the most important benefits and avoid the most burdensome costs (Goodhue et al. 1992). Thus, in order for companies to accomplish fully the benefits of ERP from full integration, effective support for ERP operations is required. Before discussing the architecture of EOSS, let us define the support tasks. First, there is a significant potential for simplifying the fundamental complexity of the process integration. The continuous splitting and combining of the process is the major cause of its complexity. If the causes can be simplified by some organizational efforts, then the complexity may be greatly reduced to a manageable level. The task of simplification, however, is not easy. Partners involved in the target process must cooperate and endure some level of inconvenience. Nonetheless, simplifying the complexity of process integration is worthwhile the effort. Thus, the first support task is to reveal the FCPI of ERP operations by providing various FCPI metrics. The next support task for ERP operations is to support users in various ways. For normal use cases, the system can guide executions of PROCESS CHAIN TYPEs, informing what to do with a particular program (FUNCTION), what to do next after the current program, and what has been done for the PROCESS CHAIN TYPE associated with the program. Consultants and users tend to pay less attention to abnormal use cases. However, the abnormal use cases are indeed major causes of making ERP operations very difficult. Cancelling a previous execution for a FUNCTION is not easy in a highly integrated information system. Especially when the PROCESS CHAIN TYPE associated with the FUNCTION has been executed deep down to the last FUNCTION and an execution of the start FUNCTION has to be cancelled, the cancellation should start at the end of the PROCESS CHAIN TYPE and continuously move backward to the start FUNCTION. Also, individual cancellation must be carried out carefully not to affect the other instances of the PROCESS CHAIN TYPE. In this regard, it is effective to help users execute such operations, informing them where to start, what to do next, how the cancellation has proceeded so far, and what exactly to delete or update. Also, periodically, it is required to generate an process integration report that shows various operational complexity metrics such as NCPC, NIPC, ADPC, MDPC, NAPC, NTD, ANTDPPC, and MNTD. Especially, NIPC and NAPC metrics reveal potential abnormality of ERP operations. With such supports, users can continually perform an interactive check to see if the ERP operations go as intended. User inquiries can be answered based on up-to-date information regarding the ERP operations. The last support task for ERP operations is to handle WCA. In order to maintain a desirable level of service, bottleneck operations and users must be identified and their workload must be adjusted. If shipping is a bottleneck FUNCTION, the delivery service may be provided poorly. If payment is a bottleneck FUNCTION, the account receivable may not be cashed in within a tolerable time. By providing WCA information, ERP administrators can make appropriate adjustments to solve the anomalies according to the causes.

ERP operations support system for maintaining process integration

3973

4.2 System architecture In order to carry out the support tasks defined, agents are defined and employed. As defined in Russell and Norvig (2002), our agents accept transaction data as precepts from the underlying database and generate appropriate advice either interactively or automatically in order to help users perform the desired operations as intended. Since the tasks are too burdensome, agents are a practical alternative for ERP operators as well as users. With agents dispatched, the data record accuracy is maintained and users can operate the ERP system exactly as expected. As shown in figure 3, EOSS is equipped with four types of agents: Instance Agent (IA); Support Agent (SA); Monitoring Agent (MA); and Report Agent (RA). Users may execute ERP FUNCTIONs without noticing our agents. The agents are running in the background and support ERP operations by communicating with business logic components of ERP. Relevant messages and guides are provided through the user interface of ERP. However, sometimes, users may communicate with agents interactively, requesting support. The definitions and instances for information of ERP operations are stored in the operations database.

4.2.1 ERP operations database. The process integration model represents system requirements and business processes constructed as a part of the implementation project. The definitions in the model are the framework for ERP operation afterwards. Users are to obey the business rules and flows defined in the model. If there is a case where a user cannot digitally perform a particular business practice with the ERP system implemented, the model must be updated dynamically. On the other hand, the process instantiation model defines how to create and use ERP operation instances. It represents how underlying transaction data are created and modified rather than the actual transaction data. When the instances are created, the process integration model is accessed because it knows about them: which instance should be created, how it should be related with others, etc. The ERP operations database stores data about both models. It can be viewed as a projection of the transaction database reflecting the integrational aspect. Thus, as shown in figure 4, the operation database contains definition data and instance data. Internally, the definition data designate how to create and relate the instance data.

Operation Database Process Integration Model Integration Transaction Database

Definition Data

aspect

Instance Data

Figure 4.

Process Instantiation Model

Operation database architecture.

3974

K. Park and A. Kusiak

Create transaction data

FUNCTION (Program)

Save transaction data

ERP Transaction Database

Call to create/retrieve PCIA Call to create TDIA

Figure 5.

Create /retrieve PC Create TD

ERP Operation Database

Architecture of instance agents.

4.2.2 Instance agent. Basically, instance agents are responsible for creating, retrieving, updating, and deleting the instance data in the operation database such as PROCESS CHAINs (PCs) and TRANSACTION DATAs (TDs) objects. Thus, two types of instance agents are designed: process chain instance agent (PCIA) and transaction data instance agent (TDIA). The following is a sample scenario for which users might want to make use of the PCIA and the TDIA when they execute a program to create a new transaction data (figure 5): . . . . . .

User executes a program to create new transaction data. The program saves the transaction data into the ERP transaction database. The program calls PCIA to either create or retrieve a PC. PCIA either creates or retrieves a PC. The program calls TDIA to create a TD. TDIA creates a TD.

One of major roles of instance agents is to provide a snapshot of a particular PROCESS CHAIN and its dependent TRANSACTION DATAs. Figures 6 and 7 show a snapshot of the Sales PROCESS CHAIN and the Shipping TRANSACTION DATA, respectively. 4.2.3 Support agent. Support agents assist users in execution of either normal use cases or abnormal use cases. They may be implemented as wizards that pop up during users’ execution. Since an execution of a FUNCTION may be associated with many PROCESS CHAIN TYPEs and TRANSACTION DATA TYPEs, support agents for the FUNCTION must get access to definition data and the instance data in the operation database. Two types of support agents are defined: normal use case support Agent (NUSA) and abnormal use case support Agent (AUSA). When a user tries to create new TRANSACTION DATA, a corresponding NUSA wizard is instantiated and assists the user executing the FUNCTION adequately. The NUSA wizard can play in an interactive mode. That is, the NUSA wizard displays information about the associated PROCESS CHAIN TYPE such as how the particular PROCESS CHAIN has proceeded at that point, what FUNCTION follows the current FUNCTION, how the previous TRANSACTION DATA are referenced, i.e. separate, split, consolidated, and split & consolidated. Double-clicking on a FUNCTION displayed in the PROCESS CHAIN screen, the user is taken directly

ERP operations support system for maintaining process integration

3975

PROCESS CHAIN: DSO - SI20030122008

SalesEntry

DeliveryRequest

Shipping

DR000009

SP000005

DR000012 Incomplete

SP000007

SN000011

Invoicing IC000003

PCI Information Created: Status: Total No of TR data: Progress: Duration: Amount of complete processing: Amount of incomplete processing:

2003/03/05 Incomplete 6 Delivery Request DR000012 partially completed 7 days $43,700,000 $300,000

Figure 6.

PROCESS CHAIN screen.

TRANSACTION DATA: Shipping – SP000019

DeliveryRequest DR000101

Shipping SP000019

Invoicing IC000011 IC000027

DR000164 TDI Information Created: Status: PCI: Duration: Amount of complete processing: Amount of incomplete processing:

Figure 7.

2003/02/24 Incomplete SI20030222003 & SI20030307001 20 days $3,700,000 $1,300,000

TRANSACTION DATA screen.

to the ERP program for execution. Furthermore, it can send messages to the next user to notice the current transaction after the current FUNCTION execution finishes. The following is a sample scenario for which users might encounter a NUSA while they execute a program (figure 8): User executes a program and enters a value into the hub control. The program creates and calls NUSA. . NUSA accesses the corresponding definitions about its PROCESS CHAIN. . .

3976

K. Park and A. Kusiak

Execute

FUNCTION (PROGRAM) create Operation Database

Send emails

Definition Data

NUSA

Access

Assist

Figure 8.

Execute

NUSA architecture.

FUNCTION (PROGRAM) Operation Database TDIA Create

Access

PCIA

Send emails

Instance Data

Access

Access Access AUSA

Assist

Figure 9.

Definition Data Access Access

AUSA architecture.

NUSA displays a wizard screen that provides the definition information of the PROCESS CHAIN. . NUSA sends an e-mail to the next user when the current user finishes. .

An AUSA is instantiated and launched when users try to cancel or update existing TRANSACTION DATAs. Since TRANSACTION DATA may be referenced by several other TRANSACTION DATAs, such modifications are not easy. With the primary key of the TRANSACTION DATA to be deleted, the AUSA first analyses the current reference status of the TRANSACTION DATA and finds all TRANSACTION DATA that the deletion must propagate through. Then, it advises the sequence of deletions from the last TRANSACTION DATA backward to the initial TRANSACTION DATA to be deleted. It may even show a simulation of such sequential deletions. Also, double-clicking a program in the wizard screen, the user can be taken to the FUNCTION where the deletion should start. When a PROCESS CHAIN is ‘complete’ so that the deletion must take place in the entire PROCESS CHAIN, then the AUSA may advise them to use a diversion FUNCTION. The architecture of AUSA is more complicated because it may have to show related TRANSACTION DATA as well as PROCESS CHAINs. The following is a sample scenario for which users might encounter a AUSA while they execute a program (figure 9): . .

User executes a program and tries to delete transaction data. The program creates and calls AUSA.

ERP operations support system for maintaining process integration . . . . . .

3977

AUSA accesses the corresponding definitions about its PROCESS CHAIN. AUSA displays a wizard screen that provides the definition information of the PROCESS CHAIN. User wants to see all the transaction data to be deleted. AUSA accesses PCIA and TDIA to compute the range of deletions and associated TRANSACTION DATA. AUSA displays the TRANSACTION DATA and the sequence of deletion on another wizard screen. AUSA sends e-mails to the other users each of whom should help the user delete the responsible TRANSACTION DATAs.

4.2.4 Monitoring agent. Monitoring agents are continuously monitoring various process integration metrics and signalling anomalies when they are found. Especially, anomalies from abnormal PROCESS CHAINs must get quick attentions from responsible users. For example, consignment goods that have not been invoiced for some time may damage the overall inventory turnover rate. This anomaly is found in most Sales PROCESS CHAIN TYPEs. Stock shortage in production lines may decrease the productivity and machine utilization. This anomaly is detected when the WithdrawPart FUNCTION is delayed and thus the cycle time of work orders is getting longer in the Production PROCESS CHAIN TYPE. Sometimes, anomalies may involve more than a single PROCESS CHAIN TYPEs. A long receivable turnover period is found between a Sales PROCESS CHAIN TYPE and a Payment PROCESS CHAIN TYPE. If an invoice has not been cashed in for a long time, it may be a bad receivable. A disused articles anomaly may involve several PROCESS CHAIN TYPEs such as Sales, SalesPlanning, ProductionPlanning, Procurement, etc, because the causes of this anomaly may be distributed over the PROCESS CHAIN TYPEs as follows: When an order for a make-to-order (MTO) product turns out to be placed with the wrong specifications. . When a sales plan for a make-to-stock (MTS) product turns out to be over estimated. . When a production plan is ordered to produce a product in too high a quantity. . When a purchase order request for a part is placed in too high a quantity. .

Since monitoring agents involve company-specific business rules as well as industry common business rules, they may have to be customized for each company. However, the following four typical monitoring agents may be required: consignment goods monitoring agent (CGMA); stock shortage monitoring agent (SSMA); bad receivable monitoring agent (BRMA); disused article monitoring agent (DAMA). For example, a DAMA provides a list of disused articles and the causes of this anomaly. The following is a sample scenario for which users might encounter a monitoring agent (figure 10): . .

MA is activated automatically in a fixed interval. MA accesses target instance data in the operation database.

3978

K. Park and A. Kusiak

Operation Database

Instance Data

Access MA Send e-mail

Self-activate

Figure 10. MA architecture.

Request reports

Operation Database Access

Instance

RA Provide reports

Figure 11. RA architecture. . .

MA computes the target anomaly. If MA finds the anomaly, it sends an e-mail to the responsible user.

4.2.5 Report agent. As shown in figure 11, periodic or real-time reports for ERP operations may help operators or users to make appropriate decisions in order to maintain the desired level of the ERP process integration. There are three types of report agents: fundamental complexity report agent (FCRA), operation complexity report agent (OCRA), and work complexity report agent (WCRA). FCRA shows the overall complexity of the ERP system under operation. By FCPIL, the relative complexity of the ERP system can be judged. OCRA shows the current operational complexity by showing various operational complexity metrices. Abnormalities are identified such that that long-delayed PROCESS CHAINs and overly referenced TRANSACTION DATA are listed on the operational complexity panel. Finally, WCRA shows the workload of a particular user group and relevant balancing efforts may be made for overloaded user groups. 5. Discussion of case studies One of the authors has consulted on ERP implementations and operations for eight small- and medium-sized manufacturing companies (owned and operated by a ‘group’) over a decade. At the moment, about 300 service requests are received monthly at the call centre and about 40% are related to system operations. In fact, many more informal service requests for system operations are received but not recorded. Even if most of the ERP systems have been operated for more than two

ERP operations support system for maintaining process integration

3979

years, the ERP users ask the systems management personnel to help when they encounter a difficult operational situation such as: deleting a sale order transaction for which the corresponding invoice has been issued and registered already in ERP, changing order type from local L/C order to domestic order after delivering the ordered items, cancelling a delivery transaction that has occurred in a previous month even after all transactions for that month are closed and, therefore, monthly accounting statements are formally generated and reported to stakeholders, and so on. Furthermore, recently it has been found out that ERP systems are not operated as intended and a tight monitoring and control mechanism should be in place to regain the initial achievements. Typical abnormal operational cases in sales functional area detected by internal audit activities are as follows: Many delivery requests are not fulfilled more than 6 months after the requests are registered. . More than 15% of delivered items are not invoiced more than 3 months after the items are delivered. . Some users enter a set of serial of transaction data suddenly at the end of the month. . Some transactions are cancelled at the end of the month and re-registered at the beginning of the month. .

An in-depth investigation of such abnormal operations has concluded that all of the cases are due to tight process integration. Especially, in an unstable manufacturing business environment in Korea, transactions are frequently cancelled or modified. Just-in-time, time-to-market, and make-to-promise manufacturing concepts make the industry very dynamic. Decision-making is done more frequently and soon will be modified. Thus, a PROCESS CHAIN may take a long time to be completely finished with many modifications. Also, most transactions are related with adjacent transactions in a split and consolidated (many-to-many) manner. Since most of transactions are referenced by many adjacent transactions, it is very difficult to find the correct target of transaction data when cancellations and modifications must be reflected into ERP. Now, this group applied metrics defined in a previous section and classified them into five different risk types: temporal, relational, real-time, actor, and cancellation/modification. For each month, the systems management group generates formal operation reports summarized from the operations database. Also, the current error message based on-line guides are extended with some of the agents defined in EOSS architecture. With agent screens shown in figures 6 and 7, users and administrators now see how their ERP system operates and control critical metrics such as NIPC, ADPC, and ANTDPPC at the desired levels. The entire functionalities of EOSS are planned to be gradually implemented because the whole implementation is very costly.

6. Conclusions and suggestions for further research As companies aim at a higher level of information system integration, successful ERP operations increasingly depend on the level of process integration achieved.

3980

K. Park and A. Kusiak

At the lowest level of process integration, a large amount of transaction data is intermingled with great complexity. As discussed in case studies, users tend to make mistakes, leaving many incomplete transactions that have been intact for a while and may end up causing financial losses. Complex cardinality between functions (programs) or transaction data threatens ERP operations with running out of control. However, most commercially available ERP systems do not provide sophisticated functions to support ERP users. Only the status of transaction processing is provided on-line in some ERP packages such as Õ SAP. In summary, individual responses to such information overloads include omission of data and errors (Vickery and Vickery 1987). In this regard, the present paper presents a support system for successful ERP operations. The process integration models presented in section 3 helps ERP operators understand the fundamental nature of process integration. Based on these models, the architecture of EOSS is presented. Employing various agents, the system will help companies better operate ERP and continuously improve the status quo to the highest of business excellence. Our agent-based support system can serve multiple purposes. Support agents may especially guide existing users to execute ERP programs without messing up transaction data. Also, new users can be trained so that they can take charge of ERP operations as quickly as possible. Operators and administrators may receive the most beneficial assistance because these agents prevent users’ mistakes at an early stage and, therefore, minimize errors in operating ERP. Also, monitoring agents as well as report agents help users find anomalies as early as possible by generating alarms and various analysis reports. Arguments about EOSS are based on case studies or anecdotal evidence. The system is valuable; however, it is important to apply the system across larger samples. Therefore, perhaps this paper’s greatest contribution to academia and to practice is simply its empirical findings: ERP requires a sophisticated operational support framework to exploit its promising benefits fully. The research limits the scope of process integration to only within a company, or so-called internal process integration. It does not include external aspects of processes such as customers, distributors, suppliers and so on. However, admitting that up-to-date ERP systems must be expanded into external information integration (Li 1999), EOSS must include the external aspects of process integration in further research. In addition, the implementational issues must be attacked in order to make EOSS more practical in terms of performance, acknowledging that it involves additional operational data and computations. Finally, the methods to compute the complexities of the process integration and underlying metrics must be refined more accurately and objectively.

References Amoako-Gyampah, K. and Salam, A.F., An extension of the technology acceptance model in an ERP implementation environment. Inform. Manag., 2004, 41, 731–745. Ben-Arieh, D. and Pollatscheck, M.A., Analysis of information flow in hierarchical organizations. Int. J. Prod. Res., 2002, 40, 3561–3573.

ERP operations support system for maintaining process integration

3981

Bingi, P., Sharma, M.K. and Godla, J.K., Critical issues affecting an ERP implementation. Inform. Sys. Manag., 1999, 16, 7–14. Cheney, P. and Dickson, G.W., Organizational characteristics and information systems: an exploratory investigation. Acad. Managerial J., 1982, 25, 170–184. COSO, Internal Control—Integrated Framework Executive Summary, 2004. Davenport, T.H., Mission Critical: Realizing the Promise of Enterprise Systems, 2000 (Harvard Business School Press: Boston, MA). Davenport, T.H., Putting the enterprise into the enterprise system. Harv. Bus. Rev., 1998, 76, 121–131. Delone, W.H., Firm size and the characteristics of computer use. MIS Quart., 1981, 5, 65–77. Ein-Dor, P. and Segev, E., Organizational context and the success of management information systems. Manag. Sci., 1978, 24, 1067–1077. Foley, J., ERP and e-business: Perfect together? Available online at: www.informationweek.com (accessed on 13 September 1999). Frizelle, G., The Management of Complexity in Manufacturing, 1998 (Business Intelligence: London). Frizelle, G. and Woodcock, E., Measuring complexity as an aid to developing operational strategy. Int. J. Oper. Prod. Manag., 1995, 15, 26–39. Gattiker, T.F. and Goodhue, D.L., Software-driven changes to business processes: an empirical study of impacts of enterprise resource planning (ERP) systems at the local level. Int. J. Prod. Res., 2002, 40, 4799–4814. Gattiker, T.F. and Goodhue, D.L., Understanding the local-level costs and benefits of ERP through organizational information processing theory. Inform. Manag., 2004, 41, 431–443. Giachetti, R.E., A framework to review the information integration of the enterprise. Int. J. Prod. Res., 2004, 42, 1147–1166. Gilbert, A. and Swear, J., Reinventing ERP. Available online at: www.informationweek.com (accessed on 13 September 1999). Goodhue, D.L., Wybo, M.D. and Kirsch, L.J., The impact of data integration on the costs and benefits of information systems. MIS Quart., 1992, 16, 293–311. Gulla, J.A. and Brasethvik, T., A model-driven ERP environment with search facilities. Data Knowledg. Eng., 2002, 42, 327–341. Holland, C.P. and Light, B., A critical success factors model for ERP implementation. IEEE Softw., 1999, May/June, 30–36. Hong, K. and Kim, Y., The critical success factors for ERP implementation: an organizational fit perspective. Inform. Manag., 2002, 40, 25–40. Jacobson, I., Object Oriented Software Engineering, 1992 (Addison-Wesley, Reading, MA). James, D. and Wolf, M.L., A second wind for ERP. McKinsey Quart., 2000, 2, 100–107. Kaplan, D., Krishnan, R., Padman, R. and Peters, J., Assessing data quality in information. Comm. ACM, 1998, 41, 72–78. Kumar, V., Maheshwari, B. and Kumar, U., Enterprise resource planning systems adoption process: a survey of Canadian organizations. Int. J. Prod. Res., 2002, 40, 509–523. Lee, A., Researchable directions for ERP and other new information technologies. MIS Quart., 2000, 24, 3–8. Lehman, J.A., Organizational Size and Information System Sophistication. Working Paper 85-18, 1985 (MIS Research Centre: University of Minnesota). Li, C., ERP packages: What’s next? Inform. Sys. Manag., 1999, 16, 31–35. Markus, M.L. and Tanis, C., The enterprise system experience: from adoption to success. In Framing the Domains of IT Management: Projecting the Future Through the Past, edited by R.W. Zmud, 2000 (Pinnaflex Educational Resources: Houston, TX). Markus, M.L., Tanis, C. and Van Fenema, P.C., Multisite ERP implementations. Comm. ACM, 2000, 43, 42–46. Olson, M.H. and Chervany, N.L., The relationship between organizational characteristics and the structure of the information services function. MIS Quart., 1980, 4, 57–68. Orr, K., Data quality and systems theory. Comm. ACM, 1998, 41, 66–71.

3982

K. Park and A. Kusiak

Park, M., Lee, J. and Jeoung, S., An explorative study of ERP system implementation: relationships between completeness of each phase and its impact on system performance. Inform. Sys. Rev., 2002, 4, 237–256. [in Korean] Raymond, L., Organizational characteristics and MIS success in the context of small business. MIS Quart., 1985, 9, 37–52. Raymond, L., Organizational context and information systems success: a contingency approach. J. Manag. Inform. Sys., 1990, 6, 5–20. Redman, T.C., Data Quality for the Information Age, 1996 (Artech House: Boston, MA). Redman, T.C., The impact of poor data quality on the typical enterprise. Comm. ACM, 1998, 41, 79–82. Russell, S.J. and Norvig, P., Artificial Intelligence: a Modern Approach, 2nd edn., 2002 (Prentice-Hall, Englewood Cliffs: NJ). Sanders, G.L. and Courtney, J.F., A field study of organizational factors influencing DSS success. MIS Quart., 1985, 9, 77–93. Scheer, A. and Habermann, F., Making ERP a success. Comm. ACM, 2000, 43, 57–61. Securities and Exchange Commission, SEC Implements Internal Control Provisions of Sarbanes-Oxley Act; Adopts Investment Company R&D Safe Harbor. SEC Press Release No. 2003-66, 27 May 2003. Shar, R., Goldstein, S.M. and Ward, P.T., Aligning supply chain management characteristics and inter-organizational information system types: an exploratory study. IEEE Trans. Eng. Manag., 2002, 49, 282–292. Sivadasan, S., Efstathiou, J., Frizzle, G., Shirazi, R. and Galinescu, A., An informationtheoretic methodology for measuring the operational complexity of supplier–customer systems. Int. J. Oper. Prod. Manag., 2002, 22, 80–102. SMBA, The Korean SMEs—improvement of the information system for SMEs, 2003. Available online at: http://www.smba.go.kr/english/sub3/sub3_3_4.htm Soh, C., Kien, S.S. and Tay-Yap, J., Cultural fits and misfits: is ERP a universal solution? Comm. ACM, 2000, 43, 47–51. Srinivasan, A. and Kaiser, K.M., Relationships between selected organizational factors and systems development. Comm. ACM, 1987, 30, 556–562. Strong, D.M., Lee, Y.E. and Wang, R.Y., Data quality in context. Comm. ACM, 1997, 40, 103–110. Thompson, J., Organizations in Action, 1967 (McGraw-Hill: New York). Vickery, B.C. and Vickery, A., Information Science in Theory and Practice, 1987 (Butterworths: London). Wallace, T.F. and Kremzar, M.H., ERP: Making It Happen, 2001 (Wiley: New York). Wang, R.Y., A product perspective on total data quality management. Comm. ACM, 1998, 41, 58–65.