8 file erp modeling comprehensive approach-too

8/13/2019 8 File ERP Modeling Comprehensive Approach-Too

1/18

Information Systems 28 (2003) 673690

ERP modeling: a comprehensive approach

Pnina Soffer, Boaz Golany*, Dov DoriFaculty of Industrial Engineering and Management, Technion-Israel Institute of Technology, Technion city, Haifa 32000, Israel

Received 20 February 2002; accepted 18 October 2002

Abstract

We present a generic reverse engineering process, aimed at developing a model that captures the available alternativesat different application levels of an Enterprise Resource Planning (ERP) system. Such a model is needed when ERPsystems are aligned with the needs of the enterprise in which they are implemented. In order to support the ERPimplementation process, the model should describe the entire scope of the ERP systems functionality and thealternative business processes it supports, as well as the interdependencies among them. We analyze the desiredproperties a modeling language should satisfy to be applied in constructing an ERP system model. This analysis, whichfollows the Cooperative Requirements Engineering With Scenarios classication framework in its adapted ERPmodeling form, results in a set of criteria for evaluating modeling languages for this purpose. Using these criteria, weevaluate the ObjectProcess modeling Methodology and apply it for generating a detailed ERP system model. Thegeneric process and detailed criteria we develop can serve for comprehensive ERP modeling, as well as for obtaining amodel of other process-supportive off-the-shelf systems that are of generic and congurable nature.r 2003 Elsevier Science Ltd. All rights reserved.

Keywords: Enterprise resource planning; Reverse engineering; Objectprocess methodology; Modeling languages

1. Introduction

Enterprise Resource Planning (ERP) systemsare off-the-shelf software packages that supportmost of the key functions of an enterprise, such as

logistics, sales, and nancial management. Thesesystems are generic, and the functionality theyprovide can serve a large variety of enterprises.

The implementation of an ERP system involvesa process of customizing the generic package and

aligning it with the specic needs of the enterprise.The alignment process simultaneously denes thesoftware conguration and the enterprise businesssolution. Due to the need to adapt the enterprise tothe software package rather than the other way

around, it often results in redesigned businessprocesses [1,2]. Enhancing the systems function-ality through software customizations, althoughnot desired [3], is sometimes required. The businessprocess alignment, affected by various environ-mental aspects, such as existing informationsystems prior to the ERP implementation [2] andorganizational culture [4], bears crucial conse-quences on the success of the ERP implementationproject and on the future business practice of theenterprise [5].

*Corresponding author. Tel.: +972-4-8294512; fax: +972-4-832-5194.

E-mail addresses: [email protected] (P. Soffer),[email protected] (B. Golany), [email protected](D. Dori).

0306-4379/03/$ - see front matter r 2003 Elsevier Science Ltd. All rights reserved.PII: S 0 3 0 6 - 4 3 7 9 ( 0 2 ) 0 0 0 7 8 - 9


2/18

This work is motivated by the need to providesupport for the alignment process in enterpriseswhose business processes are unique and form

their competitive edge. Such enterprises do notnecessarily wish to standardize all their processesdue to ERP implementation, as is often the case.Common tools that support the alignment processrefer to predened best practice models andcongurations [68], and therefore do not supportthe needs of these enterprises. Preserving theirunique processes may require these enterprises tomake software customizations in the ERP system,and take risks of a long implementation time andhigh costs for maintenance and upgrades in thefuture [3]. However, the functionality of ERPsystems is in many cases rich enough and capableof supporting business processes that are notincluded in the best practice solutions.

A requirement-driven alignment approach [9 11] enables the enterprise to identify the ERPconguration that satises stated requirementsthat do not necessarily match any predened bestpractice solution, and the gapsthe requirementsthat are not satised by the system.

Such an approach matches specications of theenterprise requirements with a model, specifying

the ERP system capabilities. This requires themodel of the ERP system capabilities to representthe entire scope of options available in the ERPsystem in a manner that enables matching with theenterprise requirements. A common basis of semantics and representation is needed for boththe ERP system model and the enterprise require-ments.

The enterprise requirements, discussed in detailin [11], are obtained through a requirementsengineering process and represented formally in

order to be matched with the ERP systemcapabilities. Some ERP systems, such as SAPand Baan, have embedded enterprise models,which represent their capabilities and best prac-tice solutions [6,8]. The model embedded in anERP system may serve as a basis for matching thesystem with the requirements. Thus, it makes senseto represent the requirements using the samemodeling approach. However, some ERP systemshave no embedded business model, and othersapply different modeling conventions, addressing

different aspects of the enterprise. The Architec-ture of Integrated Information Systems (ARIS)[6,12], applied in the reference models of SAP,

incorporates ve representation views. Theseinclude a function view, decomposing activities ina top-down manner, a business process view,represented as Event-driven Process Chains(EPC), a resource view, representing organiza-tional units and other resources, a data viewrepresented by Entity-Relationship Diagrams(ERDs), and an output view, representing physicalinputs and outputs. The Dynamic EnterpriseModeling (DEM) [8], applied in the Baan referencemodels, incorporates a business control view,which represents business functions, their structureand interaction, an organizational structure view,an enterprise structure view, showing geographi-cally distributed inner supply chain, and a businessprocess view, represented as Petri Nets [8].

Due to the lack of a standard modelinglanguage, the enterprise requirements must berepresented differently when implementing differ-ent ERP systems in order to be matched with theERP system capabilities. Furthermore, in order tobe matched, the issues addressed by the enterpriserequirements must correspond to the issues ad-

dressed by the modeling method applied in thepackage, which is being implemented. This doesnot make much sense, since the issues addressed bythe enterprise requirements are independent of thespecic ERP package implemented.

Rather than relying on the models embedded inthe various ERP packages, our goal was toestablish a proper ERP model and determine whatmodeling language is most appropriate for repre-senting the ERP system capabilities to be matchedwith the enterprise requirements. For this purpose

the desired model should represent businessprocesses and their corresponding underlyinginformation objects [11], and capture the entirescope of alternative options provided by the ERPsystem and their interdependencies.

Constructing an abstract model of an existingsystem is a process of reverse engineering. Reverseengineering processes are generally composed of three main activities: restructuring, comprehen-sion, and production of an abstract model of thesystem under investigation [13]. Restructuring,

P. Soffer et al. / Information Systems 28 (2003) 673690674


3/18

which is the process of transforming the structureof a system without changing the level of abstrac-tion, is applied when error correcting or recovery

of structure and consistency is needed, which is notour case. Existing reverse engineering approaches(e.g., [14,15]) that provide methodologies forobtaining a model from an information system,typically address legacy systems, and therefore donot focus on capturing optionality. Other works,addressing complex and congurable systems [16]and product families [17], deal with the systemsarchitecture in support of its evolution, rather thanits possible conguration options. Providing areverse engineering focus on optionality, which isessential for ERP modeling, is one of thecontributions of the present work.

We start by outlining the steps that enablesystematic construction of a model that capturesthe entire scope of alternative ERP system optionsand the interdependencies among them. Thesesteps are generic and not specied for anyparticular modeling language. They provide abasis for discussing the nature of modelinglanguages suitable for our purpose. The discussionis based on the Cooperative Requirements En-gineering With Scenarios (CREWS) classication

framework of modeling languages [18], which wasadapted for ERP representation in [10], and resultsin a set of evaluation criteria for a modelinglanguage to be applied in ERP modeling. Themodeling steps are rened into a modelingprocedure that applies the ObjectProcess Meth-odology (OPM) [19] as a modeling language. OPMhas been introduced and evaluated in [11] formodeling the requirements posed by an enterprise.Therefore, applying it for representing the ERPsystem provides a basis for aligning the system

with the requirements. The OPM modeling proce-dure can be applied as is, or serve as a meta-modelfor constructing a modeling procedure, which isimplemented with any other modeling languagethat ts the dened selection criteria.

The remainder of the paper is organized asfollows: Section 2 outlines the generic ERPmodeling procedure. The desired characteristicsof a modeling language that is useful for describingan ERP model and implementing the modelingprocedure are discussed in Section 3 and form

selection criteria for such a language. Section 4briey introduces the OPM and presents an ERPmodeling procedure that follows the steps outlined

in Section 2. Discussion and concluding remarksare given in Section 5.

2. Generic ERP modeling steps

The alternative options provided by an ERPsystem appear in different levels of application. Inthis section, we discuss the optionality levels, andpresent a generic reverse engineering approach,which is based on their structure. We illustrate ourapproach with examples based on the Purchaseand Inventory modules of the Baan IV ERPsystem, which concern purchasing of goods andinventory transactions in warehouses.

2.1. ERP optionality levels

Capturing the entire scope of options supportedby the ERP system in a model is a challengingtask, which is essential for identifying a goodsolution for the enterprise needs. The ERP optionsenable adapting the system to various enterprises

with different needs, and are controlled by a set of parameters, whose values are determined throughan alignment process.

Three levels of optionality are distinguished:System Conguration level, Object level, andOccurrence level.

The System Conguration optionality levelaffects the functionality of the ERP systemthroughout the entire system. The various optionsare controlled by the system parameters, whosevalues are set once when the system is implemen-

ted in an enterprise and remain static thereafter.An example of such a parameter is a Booleanparameter indicating whether warehouse locationcontrol is implemented in the system. By settingthe parameter value to True, all the warehouselocation-related processes, such as warehouselocations management and receiving purchasedgoods to locations, are enabled, while a Falsevalue of this parameter disables this functionality.

There are three types of system parameters. (1)High-level process denitions, which control the

P. Soffer et al. / Information Systems 28 (2003) 673690 675


4/18

system functionality by providing preconditionsto user-interface sessions. The location controlparameter is of this type. (2) Low-level process

denitions that control the systems internalfunctionality by indicating the specic algorithmsand rules to be applied when performing a specicaction. For example, a parameter of this typedenes what types of action require logging arecord of change history by the system. (3) Processparameter denitions that provide values thatdetermine how a specic action is performed.Examples of this parameter type are parametersdening the numerical range and structure in ordernumbering, and parameters indicating differentplanning horizons.

The Object level is an intermediate optionalitylevel, controlled by the parameters of single dataobjects, and can vary in different instances.Different parameter values cause different in-stances to be handled in a different manner. Anexample of such a parameter is a Boolean attributeof a warehouse indicating whether location iscontrolled in this specic warehouse. When loca-tion control is implemented in the system, eachwarehouse may either be location controlled ornot, as set by the value of this attribute. A

warehouse cannot be location controlled if loca-tion control is not implemented in the system, butin a conguration including location control, theremay still be one or more warehouses that aremanaged without location control. Since this is anattribute of a Warehouse, its True and False valuesenable performing inventory handling processesdifferently in different warehouses. Another ex-ample is a Boolean attribute of an item, indicatingwhether or not it should undergo a qualityinspection when received and be approved before

it can be used.The Occurrence level, which is the lowest level of optionality, applies to a single occurrence of aprocess, and facilitates variance in its performance.For example, when registering the receipt of purchased items that need to be inspected, theuser may select an option of a fast approval, andautomatically approve all the delivered goodsas being of good quality. Otherwise, the goodswill undergo a quality inspection as a separateprocess. The user can decide whether to apply this

option in each occurrence of the goods receivingprocess.

2.2. Systematic ERP modeling

The generic reverse engineering process pre-sented here is focused on two of the threefundamental reverse engineering activities: achiev-ing comprehension of the ERP system and itsoptionality controls, and abstracting it to a model.The sources of information for the process are thesystem database schema, as reected in the systemtables, the system on-line and off-line documenta-tion and help facilities, the user interface, anddomain knowledge of the modeler. If the systemincludes an embedded process model, such as SAP[6] and Baan [8], that model can serve as a basis forthe business process model, but should be treatedcarefully and checked for consistency with theother information sources.

The process, whose summary is provided inTable 1 , includes four modeling levels: a globallevel and three levels corresponding to theoptionality levels discussed above.

Global level: The initial level in the modelingprocess concerns the global functionality of the

system without addressing its various options.First, the ERP systems database schema isrepresented and abstracted in order to gainunderstanding of the business objects that partici-pate in the supported business processes. Thedatabase model is obtained in a bottom-upmanner, rst by extracting the physical datastructure and second by establishing generalizedobjects. The business processes are identied bygrouping the user-interface sessions in the ERPmodules into functional groups, and by following

the order in which transformations of the statusattributes of the objects may occur. In cases wherethe ERP system includes an embedded processmodel, this model can serve as a basis for theGlobal model. This top-level model species thesequence of activities that manipulate the maindata objects in the system but it does not representalternative processes.

System conguration level: The second step,which addresses the System Conguration level,concerns the alternative business processes that are

http://-/?-http://-/?-


5/18

determined by the system conguration. Thisentails identifying the effect of the system para-meters, which are included in the database modeland belong to the high-level process denition setof parameters. These parameters determine themain alternatives for performing the businessprocesses by controlling the access to user-inter-face sessions. Identifying their effect on theactivities of the Global process model leads torened business process alternatives in the SystemConguration-level business process model.

Object level: The third step addresses the Objectlevel, representing process variants that hold for asingle instance. It involves studying the activitiesof the business processes and the data objects theymanipulate in order to identify (a) the possiblevariants of the process activities, and (b) thepreconditions of each such variant in terms of dataobject attribute values. The preconditions may bea combination of system parameters and dataobject attribute values. The instance-specic pro-cess variants, along with their preconditions, are

represented at the Object-level business processmodel.

Occurrence level: The fourth and last step,addressing the Occurrence level, considers theoptions the user may select in each occurrence of a process, thus constructing the most detailed layerof the model. This layer expresses the alternativeoptions available for performing each processvariant. The enterprise operations can be con-trolled through a combination of higher-levelparameters of the rst three layers with low-level

process occurrence parameters. In this step theuser interface is studied in order to identify optionsthat the user can determine while performing atask. The effect of these options on the businessprocesses is dened and modeled.

The layers of the model obtained through theprocess steps are illustrated by the Purchase andInventory example, in which the database modelincludes objects such as Warehouse, Item, Supplier,Location, and Purchase order , along with theirrelations and attributes, as well as system

Table 1Generic ERP modeling process

Step Description Information sources Output

ERP global level 1. Constructing adata model in abottom-upmanner

2. Constructing aGlobal businessprocess model

* ERP database* ERP system modules

and sessions* Embedded business

process model* Status transformation of

objects

1. Databasemodel

2. Globalbusinessprocessmodel

Systemcongurationlevel

Identifying andmodeling the alternativebusiness processes,controlled by the systemparameters

* ERP database model:system parameters

* ERP system modulesand sessions

Systemconguration-level businessprocess model

Object level Identifying andmodeling businessprocess alternatives andoptions, controlled bydata object attributes

* ERP database model:system parameters andobject attributes

* ERP system modulesand sessions

Object-levelbusiness processmodel

Occurrencelevel

Identifying andmodeling activityoptions, controlled byuser-dened options

* ERP database model:system parameters andobject attributes

* ERP system modulesand sessions: user interface

Occurrence-levelbusiness processmodel



6/18

parameters, such as Location Control Implemented.The Global business process model speciesprocesses such as receiving purchased goods.

In the System Conguration level, two alter-native ways of receiving goods to a warehouse areidentied and modeled. These are controlled bythe system parameter Location Control Implemen-ted, whose False value means that the alternativeof receiving goods into a non-location controlledwarehouse is selected, while a True value allowsboth alternatives, one of receiving goods into alocation controlled and anotherto a non-loca-tion controlled warehouse.

Two examples illustrate the Object level. In therst one the combination of the system parameterLocation Control Implemented and the warehouseattribute Location Controlled serves as a precondi-tion for location controlled or non-location con-trolled receiving. In the second example the Itemattribute Inspection Required controls by itself theactivation of an inspection sub-process, includedas a variant in the purchase receiving process.

The Occurrence level is illustrated by the optionFast Approval , which the user may select whendealing with items that require inspection. Thisoption activates an activity of automatically

approving all the goods received.The Purchase and Inventory example demon-

strates the modeling steps, based on the para-meters that control the ERP functionality at thedifferent application levels. As the number of theseparameters increases through the entire softwarepackage, so does the number of process alter-natives and options.

The four modeling levels are independent of themodeling language applied. Nevertheless, in orderto be applicable for the proposed modeling process

and to properly express the systems rich andcomplex functionality, the modeling languageshould meet certain requirements. In the followingsection we discuss the properties of modelinglanguages suitable for ERP modeling.

3. Desired properties of an ERP modeling language

In this section we discuss the properties of aneffective ERP modeling language. The discussion

follows the CREWS classication framework of scenario representations [18], which was adaptedby Rolland and Prakash [10] to classication of

ERP modeling approaches. We make somemodications to their framework, whose summaryis given in the Appendix A. The extended frame-work, which enumerates the properties of model-ing languages that are of relevance to ERPrepresentation, is the basis of our discussion. Weconsider the consequences of each of the proper-ties, and indicate its desired values. Thus, we infact transformed the adapted CREWS classica-tion framework into an evaluation framework of modeling languages.

The adapted CREWS classies modeling meth-ods by four views: Content , Form , Purpose , andCustomization process . Each view has a set of associated facets, and each facet is characterizedby a set of relevant attributes.

The Content view refers to the knowledgecaptured in the model, dened according to fourfacets: Abstraction, Context, Coverage, and Argu-mentation.

Abstraction: The Abstraction facet is character-ized by a single attribute, Abstraction, whichclassies the scope of abstraction levels available

in a modeling language. This scope can beFlexible, allowing different levels of abstractionin a model; Fixed, indicating that once the abstrac-tion level is set in a model, it is not possible tochange it into a higher abstraction level or a lowerone; or the scope may be unique, allowing a pre-dened abstraction level only (e.g., details only).

For the purpose of ERP modeling Flexibleabstraction is required of the modeling language,in order to support a top-down/bottom-up model-ing process. Furthermore, due to the high level of

complexity and broad scope of ERP systems, axed level of abstraction (unique or even change-able) may either provide insufcient informationor become overloaded.

Context: The Context is characterized by threeBoolean attributes: Internal, Interaction, andContextual. The Internal attribute indicateswhether the internal system functionality is ad-dressed in the obtained model. The Interactionattribute indicates whether the interaction betweenthe system and its environment is represented. The



7/18

Contextual attribute indicates whether the modelrepresents the environmental context in which thesystem operates.

Since the purpose of ERP modeling is to alignthe ERP system with the enterprise requirements,the contextual and interaction properties are of relevance. As discussed in [11], the requirementstreat the system as a black box, specifying itsorganizational context and partly its interaction.In order to address the same issues as the require-ments, the ERP model should focus on the contextof the system and its interaction.

Coverage: The Coverage facet is expressed bytwo attributes: Functional, which characterizes thefunctional information captured in the model, andIntentional, whose Boolean value indicateswhether the model includes intentional informa-tion, such as objectives and goals.

While the ERP-adapted CREWS framework[10] treats the Functional attribute as a Booleanone, we chose to follow the original CREWSframework, and distinguish between structural,functional and behavioral information capturedby the modeling languages. This attribute, there-fore, indicates the types of functional informationcaptured in the model. Proper representation of

the ERP functionality requires the modelinglanguage to express all three types: structural,functional and behavioral information. Intentionalinformation is not an essential part of the ERPmodel, as presented in Section 2.

Argumentation: The Argumentation facet, relat-ing to the ability of a modeling language to expressoptionality-related information, is expressed bythree attributes: Variant, Arguments, and VariantDependency.

The Variant attribute, indicating whether the

modeling language is capable of expressing op-tions and variants, is essential for capturing theentire scope of options and business process variantssupported by the ERP system. The Argumentsattribute identies whether the modeling methodprovides for including arguments that support theselection. Such arguments, although possibly help-ful in the alignment process, are not mandatory.

While the third attribute, the Variant Depen-dency, was not included in the adapted CREWSframework, we consider it as an important element

of the framework. Dependencies and inter-rela-tions play a major role in the customizationdecision-making process, and should therefore be

reected in the model resulting from the modelinglanguage under consideration.Table 2 summarizes the facets and attributes of

the Content view and indicates the requiredattribute values of an adequate ERP modelinglanguage. If no required value is specied in thetable, every value is acceptable.

The Form view refers to the notation andstructure applied in the modeling language,through two facets: Notation and Structure.

Notation: The Notation facet has a singleattribute, Notation, which classies the formalitylevel of a modeling language. It should preferablybe either formal or semi-formal in order to supporta systematic matching with the requirements, orelse it may lead to inaccuracy and ambiguity in thealignment process.

Structure: The Structure facet, addressing thetypes of elements and relations in a modelinglanguage, has three attributes: Element Type,which is merely an identication of the elementtypes included in the model, Intra-element Rela-tionship, and Inter-element Relationship.

The Intra-element Relationship attribute indi-cates whether the elements of the model constitutea nested structure or a at one. This attribute isclosely related to the Abstraction attribute of theContent view, since a nested structure typicallycorresponds to a exible level of abstraction, whilea at structure typically indicates a single level of abstraction. Since a exible level of abstraction isdesired in ERP modeling, the Intra-elementrelationship should be nested, or a combinationof nested and at structures.

The Inter-element Relationship attribute, whichspecies the relationship types in the model,determines to a great extent the expressive powerof a modeling language, which should be as high aspossible. Nevertheless, relating this attribute to theIntra-element Relationship, a nested intra-elementstructure provides for generalization and rene-ment relationships to be reected by the abstrac-tion levels of the model. Therefore, within a singlelevel of the model, the lack of generalization andrenement is acceptable.

http://-/?-http://-/?-


8/18

Table 3 summarizes the facets and attributes of the Structure view and indicates the requiredattribute values of a modeling language adequatefor ERP modeling.

The Purpose view refers to the objectivesthat may be satised by using the model. It hasone facet, the Aim of Representation, expressedby three Boolean Attributes: Descriptive,

Table 2Required values for attributes of the Content View

Facet Attribute Explanation Required values

Abstraction Abstraction: ENUM{Unique, Fixed, Flexible}

The scope of abstractionlevels supported

Flexible

Context Internal: BOOLEAN The model representsinternal system functionality

Interaction: BOOLEAN The model representsinteraction between systemand environment

True

Contextual: BOOLEAN The model represents theorganizational environment

True

Coverage Functional: SET (ENUM{Structure, Function,

Behavior})

Notes the aspects of the ERPsystem captured in the

model

{Structure, Function,Behavior}

Intentional: BOOLEAN The model providesintentional information

Argumentation Variant: BOOLEAN Ability to represent optionsand variants

True

Arguments: BOOLEAN Argumentation guiding thevariant selection

Variant dependency:BOOLEAN

Ability to representdependencies among thevariants

True

Table 3Required values for attributes of the Structure View


Notation Notation: ENUM {Formal,Semi-formal, Informal}

The notation formality level Formal, Semi-formal

Structure Element type: SET The main element types inthe model structure

Intra-element relationship:SET (ENUM {Flat, Nested})

Type of structure constitutedby the elements

Nested

Inter-element Relationship:

SET (ENUM {Composition,Generalization, Precedence,AND, OR, XOR, Renement,Characterization})

Possible relationship types

between elements

{Composition,

Precedence, AND,OR, XOR,Characterization}

http://-/?-http://-/?-


9/18

Exploratory, and Explanatory. Since ERP systemshave many alternative options supporting alter-native business processes, their representation isexploratory in nature. The model may as well beexplanatory and provide further assistance bysuggesting guidelines for decision-making, but thisis not essential for aligning it with the enterpriseneeds.

Table 4 summarizes the facets and attributes of the Purpose view and indicates the requiredattribute values of a modeling language adequatefor ERP modeling.

The Customization process view refers to the

process of aligning and customizing an ERPsystem to the enterprise needs on the basis of themodel. It has one facet characterized by twoattributes: Customization Approach (e.g., top-down, bottom-up) and Customization Paradigm(e.g., data-driven, requirement-driven).

These two attributes were originally dened inthe ERP-adapted CREWS framework [10] asvariables of an enumerated type, implying that amodeling language is characterized as uniquelyserving a single customization approach or para-

digm. However, a modeling language can beapplied in different customization (or alignment)processes, taking different approaches and para-digms. We dene these two attributes as sets of possible customization approaches and paradigms,for which the modeling language is applicable.Therefore, this classication view does not affectthe selection of an ERP modeling language.Rather, it is a result of the selection andapplication of a modeling language in an align-ment process.

4. Objectprocess ERP representation

This section introduces the OPM, evaluates itaccording to our adapted CREWS frameworkcriteria, and provides an ERP modeling procedurein which OPM is the modeling language.

4.1. ObjectProcess Methodology

OPM, described in detail in [19], has beenapplied for various purposes, such as computerintegrated manufacturing [20], image understand-ing [21], modeling research and development

environments [22], algorithm specication [23],document analysis and recognition [24,25], andmodeling electronic commerce transactions [26].

The basic building blocks of OPM are twoequally important classes of entities: objects andprocesses, which are related through a variety of links among them. While most object-orientedmodeling methods require the use of a set of models, each with its diagramming symbols andconventions, to describe different aspects of thesystem, OPM uses a single graphic tool, the

ObjectProcess Diagram (OPD) set, as a singlemodel of the structural, functional, and dynamicsystem aspects. This eliminates the model multi-plicity problem [27], which requires special effortsto integrate the various views into a coherentsystem model and to keep consistency amongthem.

While using a single model representation, OPMkeeps simplicity through two abstracting-rene-ment mechanisms that control the visibility of thesystem details. Unfolding objects and zooming

Table 4Required values for attributes of the Purpose View


Aim of representation

Descriptive: BOOLEAN The model describes oneway of achieving a goal

Exploratory: BOOLEAN The model describes severalpossible different ways of achieving a goal

True

Explanatory: BOOLEAN The model includesexplanations of why to selecta certain way

http://-/?-http://-/?-


10/18

into processes allow a top-down analysis, yielding

a hierarchical OPD set, which species the systemat a spectrum of abstraction levels. Throughfolding and out-zooming, OPM may as wellsupport a bottom-up analysis, going up in levelsof abstraction.

The links employed between the entities in anOPD include structural relations, such as aggrega-tion, generalization, and characterization, andbehavioral links, classied into enabling, resulting,and triggering link types.

Aligning the ERP system with the requirements

of an enterprise can be achieved when the systemand the requirements are represented in the samemodeling language. An evaluation of OPMsability to represent the requirements posed byenterprises regarding ERP systems has found itsexpressive power adequate for this purpose [11],implying that both contextual and interactioninformation of the system can be represented inan OPM model. When applying the adaptedCREWS framework evaluation criteria presentedin Section 3, OPM is found to be suitable for ERP

modeling. Therefore, OPM can serve as a model-

ing language in an ERP-enterprise alignment, sinceit is suitable for representing both the enterpriserequirements and the ERP system. The evaluationof OPMs adequacy for ERP modeling is summar-ized in Table 5 .

4.2. Applying OPM for ERP modeling

The modeling method presented in this section isbased on the generic modeling steps introduced inSection 2, and includes specic instructions for

representing the ERP data and functionality inOPM terms. Each modeling step is illustrated byan example.

Step 1: Convert the database to an object model.In this step, the data model is constructed based onthe database tables. It involves two activities:representation and generalization. First, each of the systems tables is represented by an OPD.Then, structurally similar objects are generalizedinto higher-level objects. The representation activ-ity converts each database table into an OPD, in

Table 5Attribute values required for ERP modeling and the corresponding OPM values

View Facet Attribute Required Value

for ERPModeling

OPMs

Attribute Value

Content Abstraction Abstraction Flexible FlexibleContext Interaction True True

Contextual True TrueCoverage Functional (Structure,

Function,Behavior)

(Structure,Function,Behavior)

Argumentation Variant True TrueVariant dependency True True

Form Notation Notation Formal/Semi-formal

Formal

Structure Intra-elementrelationship

(Nested) Nested

Inter-elementrelationship

(Composition,Precedence,AND, OR, XOR)

(Composition,Precedence,AND, OR, XOR,Generalization,Renement)

Purpose Aim of representation

Exploratory True True

http://-/?-http://-/?-


11/18

which the tables title is an object characterized byeach one of its elds through characterizationlinks. Foreign keys in a table are represented either

by a tagged structural relation (e.g., Purchase orderIs Supplied by Supplier ) or by an aggregation link(e.g., Purchase order line to Purchase order ),depending on the context.

Second, the objects that share common features(attributes and operations) are identied as spe-cializations of a generalized object. Then thegeneralized object, its features and inheritancerelations constitute one OPD, and each of thespecialized objects with its unique features isrepresented in a separate OPD.

As an example, the OPDs in Fig. 1(a) and (b)are obtained in the initial representation activityfrom the database tables Standard Item andCustomized Item . For the sake of clarity, theOPDs in the Figure, as well as in the otherexamples, are simplied. Since both objects sharemany common features, the generalization activitydenes the object Item as their abstraction, whosefeatures, shown in Fig. 1(e) , are the features thatare common to both tables. Each table is modeledas a specialized object of Item and exhibits only itsunique features, as shown in Fig. 1(c) and (d) .

Step 2: Construct the Global business processmodel . In this step, both domain knowledge andERP system knowledge are applied in order todene the high-level generic business processessupported by the system. The sessions of thesystem are grouped into functional groups, such aspurchase order creating or purchased goodsreceiving. Each such functional group is repre-sented as an OPM process. The objects that enableand are manipulated by the processes are identiedand their links with the processes are established.

Objects included in the model are preferablygeneralized objects, or else the main objects relatedto database tables. Attributes are not included inthe model at this step.

This step is illustrated by the process PurchaseGoods Receiving in Fig. 2 .

This top-level process includes three sub-pro-cesses, Purchase Receipt Registering, Goods In-specting and Approving and Warehouse Allocating .The instruments used by this process are theobjects Item, Warehouse , and Supplier , while the

other objects, such as Purchase Order and In-ventory by Item , are objects that the processPurchase Goods Receiving affects by changing the

state or value of one or more of their attributes.Note that the renement of OPDs does notnecessarily correspond to the modeling steps.Rather, a modeling step may yield several levelsof the OPD set representing the system, or merelyadd details to one or more OPDs obtained inearlier steps.

Step 3: Identify System Conguration-level busi-ness process alternatives. In this step, the systemparameters in the data model are investigated andcategorized. The high-level process-dening para-meters are identied as preconditions to some of the user-interface sessions. The alternative busi-ness processes are represented in OPM as specia-lizations of the processes in the Global-levelmodel. Each process alternative is related bycondition links to the relevant states of the controlparameters, represented by objects. The sub-processes modeled for each business processalternative are the sessions it includes.

This step is illustrated in Fig. 3 , which shows thealternative specializations, obtained when zoom-ing into the Warehouse Allocating process. These

alternative processes are controlled by the systemparameter Location Control Implemented? , whoseYes state is related by a condition link to LocationControlled Warehouse Allocating. This modelingstep may also include zooming into the alternativeprocess specializations in order to represent theirsub-processes.

Step 4: Identify Object-level variants of thebusiness processes. This step identies variants of the business processes, which are controlled by theparameters of single data objects, either by

themselves or in combination with the systemparameters. The attributes of the objects thatparticipate in the modeled processes are studied toidentify their inuence on the process activities.The outcome in the OPM model can be specializedprocesses conditioned by object attribute states, oras specic sub-processes of a process, each of which is related by a condition link to an attributestate.

This step is illustrated by the OPDs in Fig. 4 and5. In Fig. 4 , the attribute, represented by the



12/18

Fig. 1. A part of the database model.



13/18

Boolean Object Location Controlled? of a Ware-house , allows for performing different processes indifferent Warehouse instances. The process is

controlled by the combination of the systemparameter Location Control Implemented? andthe Warehouse attribute values.

Fig. 2. A top-level business process model.

Fig. 3. System conguration-level business process model.



14/18

In Fig. 5 , the process Goods Inspecting and Approving is conditioned by the Boolean attributeInspection Required? of Item .

Step 5: Expose the Occurrence-level business process options. In this step, the options availableto the user in each of the sessions represented inthe model are investigated. These options aredetermined by the user in real time, and allow a

limited control of the process course. In the OPMmodel, a user-controlled option is an object insidea process, whose states are events that trigger sub-processes.

This step is illustrated by the example in Fig. 6 ,which shows the option Fast Approval? availableto the user in the process Purchase ReceiptRegistering.

Fig. 4. Business process variants controlled by an attribute of a warehouse.

Fig. 5. A business process variant controlled by an attribute of an item.



15/18

By selecting the state Yes of the Fast Approval option, the user triggers a step of AutomaticApproving as part of the registering process.

For the purpose of being matched against theenterprise requirements, the ERP model needs tobe modular, so that alternative processes are

represented in different OPDs. Then each OPDin the system model can be evaluated separately,so that the alignment rules out the OPDs thatspecify the ERP parts that do not match therequirements, and selects the ones that complywith them. The following modeling principlesensure that the constructed model is modularand complete.

* Separation of concerns: Each OPD in the modeldeals with a single issue and can be given a

single title that fully expresses its content. Thisprinciple addresses the tendency of modelers totry to squeeze as much information as possiblein an OPD (e.g., a process affecting an objecttogether with the structure of the object).According to this principle, different issues(process, object data structure) need to berepresented in different OPDs.

* Separation of alternatives: When there areseveral alternative specializations of a specicprocess, whose selection is controlled by a

system parameter or an object attribute, theirdetails should be specied in separate lower-level OPDs.

* Completeness of low-level OPDs: Where linksbetween an object and a process appear in thelowest-level OPDs (the leafs of the OPD set),

all the attributes that participate in the link(either as enablers or as objects which areaffected) must be specied. According to theseparation of concerns principle, structuralinformation of an object, rather than beingincluded in OPDs showing processes in which itis involved, is represented in a separate OPD.However, in the lowest level OPDs the completedetails of the relation are provided by showingthe specic object attributes that participate inthe processes. This principle is demonstrated in

Fig. 6 , which, as a low-level OPD, provides allthe affected attributes of the objects participat-ing in the process.

5. Conclusions

The ERP modeling approach suggested in thispaper addresses the construction of an ERPmodel, for the purpose of aligning an ERP systemwith the needs of an enterprise.

Fig. 6. Process option model.



16/18

The contribution of the paper is threefold. First,we introduce generic ERP modeling steps, aimedat capturing the entire scope of process variants

supported by the ERP system and the interdepen-dencies among them. These generic steps may beapplied using a variety of modeling languages.However, the complexity of the problem posesrequirements on properties that a modelinglanguage should satisfy to be suitable for thistask. The second contribution of the paper is theanalysis and characterization of these properties,which results in a set of evaluation criteria formodeling languages. This analysis extends theERP-adapted CREWS classication framework[10]. The main addition to the framework is theconsideration and representation of possible de-pendencies among variants and options in theERP system. The analysis and evaluation criteriaestablished led to the selection of OPM as themodeling language of choice for ERP modeling.Since OPM has been evaluated in [11] and foundadequate also for representation of enterpriserequirements, it is now shown to be applicable asa basis for ERP-enterprise alignment. Finally, thethird contribution is a detailed ERP modelingprocedure that we present in Section 4. The

modeling procedure can be used as is, or serve asan example showing how the generic modelingsteps are rened into a detailed procedure.

The ERP modeling process has been appliedand proven useful in obtaining a model of the partsof the Baan ERP system as part of a requirement-

driven alignment experiment. The model construc-tion was labor-intensive and required studying thedetails of the ERP system and the processes it

supports. Nevertheless, this is a one-time effort,which produces a model that can serve repeatedlyfor any number of implementation projects.

The modeling process, although developed forERP systems, is not limited only to this type of systems. The levels of optionality included in ERPsystems appear also in other off-the-shelf cus-tomizable information systems. Therefore, themodeling process may be relevant to any pro-cess-supportive generic off-the-shelf informationsystem. It may also be of importance to reverseengineering of product families, which includeparametric variability.

Future research addresses the application of theERP model in ERP-enterprise alignment. It canalso apply the evaluation criteria for evaluatingand comparing other modeling languages, anddevelop detailed modeling procedures for thoselanguages that are found suitable on the basis of the generic modeling steps. Another researchdirection is to relate our modeling process, whichdeals with optionality, to the architectural-oriented reverse engineering approaches of

product families.

Appendix A

See Table 6 .

http://-/?-http://-/?-


17/18

References

[1] T.H. Davenport, Putting the enterprise into the enterprisesystem, Harv. Business Rev. 76 (1998) 121131.

[2] C.P. Holland, B. Light, A critical success factors model forERP implementations, IEEE Software 16 (1999) 3035.

[3] B. Light, The maintenance implications of the customiza-tion of ERP software, J. Software Maintenance: Res.Practice 13 (2001) 415429.

[4] M. Krumbholz, N. Maiden, The implementation of enterprise resource planning packages in different organi-sational and national cultures, Inf. Systems 26 (2001)185204.

[5] J. Ghosh, SAP Project Management, McGraw-Hill, NewYork, 2000.

[6] T.A Curran, A. Ladd, SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2nd edition, Prentice-Hall, Englewood Cliffs, NJ, 1999.

[7] M. Daneva, Measuring reuse in SAP requirements: amodel-based approach, in: SSR 99, Proceedings of theFifth Symposium on Software Reusability, ACM Press,New York, 1999, pp. 141150.

[8] H.A. Post, R. Van Es (Eds.), Dynamic EnterpriseModeling: a Paradigm Shift in Software Implementation,Kluwer, Dordrecht, 1996.

[9] C. Rolland, Intention driven component reuse. In: S.Brinkkemper, E. Lindencrona, A. Solvberg (Eds.), Infor-mation Systems Engineering: State of the Art and ResearchThemes , Springer, Berlin, 2000, pp. 197208.

[10] C. Rolland, N. Prakash, Bridging the gap betweenorganizational needs and ERP functionality, Requirements

Eng. 41 (2000) 180193.[11] P. Soffer, B. Golany, D. Dori, Y. Wand, Modelling off-the-shelf information systems requirements: an ontologicalapproach, Requirements Eng. 6 (2001) 183199.

[12] A.W. Scheer, ARISBusiness Process Frameworks,Springer, Berlin, 1999.

[13] H. Yang, X. Liu, H. Zedan, Abstraction: a key notionfor reverse engineering in a system reengineering approach,J. Software Maintenance: Res. Practice 12 (2000) 197228.

[14] W.J. Heuvel, M. Papazoglou, M.A. Jeusfeld, ConguringBusiness Objects from Legacy Systems, in: Proceedingsof the CAiSE 99 (LCNS 1626), Springer, Berlin, 1999,pp. 4156.

Table 6ERP-adapted CREWS framework

View Facet Attribute

Content Abstraction Abstraction: ENUM {Unique, Fixed, Flexible}Context Internal: BOOLEAN

Interaction: BOOLEANContextual: BOOLEAN

Coverage Functional: BOOLEANIntentional: BOOLEAN

Argumentation Variant: BOOLEANArguments: BOOLEAN

Form Notation Notation: ENUM {Formal, Semi-formal,Informal}

Structure Element type: SET (STRING)Intra-element relationship: SET (ENUM {Flat,

Nested})Inter-element relationship: SET (ENUM{Composition, Generalization, Precedence,AND, OR, XOR, Renement})

Purpose Aim of Descriptive: BOOLEANrepresentation Exploratory: BOOLEAN

Explanatory: BOOLEAN

Customizationprocess

Customizationprocess

Approach: ENUM {Top-down, Bottom-up,Middle-out, Single-level, Breadth-rst, Depth-rst}Paradigm: ENUM {Data-driven,Requirements-driven, Quality-driven,Behavior driven}



18/18

[15] H. Lee, C. Yoo, A form driven object-oriented reverseengineering methodology, Inf. Systems 25 (2000) 235259.

[16] R.L. Krikhaar, Reverse engineering approach for complexsystems, in: Proceedings International Conference onSoftware Maintenance, IEEE, Los Alamitos, CA, 1997,pp. 411.

[17] B. Bellay, H. Gall, Reverse engineering to recoverand describe a systems architecture, in: Developmentand Evolution of Software Architectures for ProductFamilies, ARES 98 (LNCS 1429), Springer, Berlin, 1998,pp. 115122.

[18] C. Rolland, C. Ben Achour, C. Cauvet, et al., A proposalfor a scenario classication framework, Requirements Eng.3 (1998) 2347.

[19] D. Dori, Object Process Methodologya Holistic SystemsParadigm, Springer, Berlin, Heidelberg, New York,2002.

[20] D. Dori, Objectprocess analysis of computer integratedmanufacturing documentation and inspection functions,Int. J Comput. Integrated Manuf. 9 (1996) 339353.

[21] D. Dori, Analysis and representation of the image under-standing environment using the objectprocess methodol-ogy, Object-Oriented Programming 9 (1996) 3038.

[22] D. Meyersdorf, D. Dori, The R&D universe and itsfeedback cycles: an objectprocess analysis, R&D Manage.27 (1997) 333344.

[23] L. Wenyin, D. Dori, Objectprocess diagrams as anexplicit algorithm specication Tool, J. Object-OrientedProgramming 12 (1999) 5259.

[24] D. Dori, Arc segmentation in the machine drawingunderstanding environment, IEEE Trans. Pattern Anal.Mach. Intell. 11 (1995) 10571068.

[25] L. Wenyin, D. Dori, A generic integrated line detectionalgorithm and its objectprocess specication, Comput.Vision-Image Understanding (CVIU) 70 (1998) 420437.

[26] D. Dori, Objectprocess methodology applied to modelingcredit card transactions, J. Database Manage. 12 (2001) 212.

[27] M. Peleg, D. Dori, The model multiplicity problem:experimenting with real-time specication methods, IEEETrans. Software Eng 26 (2000) 742759.


8 file erp modeling comprehensive approach-too

Documents