Fault-tolerant context development and requirement validation in ERP systems

    Fault-Tolerant Context Development and Requirement Validation in ERP Systems S. Zafar Nasir, Tariq Mahmood, M. Shahid Shaikh, Zubair A. Shaikh PII: DOI: Reference:

S0920-5489(14)00069-5 doi: 10.1016/j.csi.2014.05.001 CSI 2970

To appear in:

Computer Standards & Interfaces

Received date: Revised date: Accepted date:

11 October 2011 6 January 2014 26 May 2014

Please cite this article as: S. Zafar Nasir, Tariq Mahmood, M. Shahid Shaikh, Zubair A. Shaikh, Fault-Tolerant Context Development and Requirement Validation in ERP Systems, Computer Standards & Interfaces (2014), doi: 10.1016/j.csi.2014.05.001

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

ACCEPTED MANUSCRIPT

PT

Fault-Tolerant Context Development and Requirement Validation in ERP Systems S. ZafarNasir1, Tariq Mahmood2, M. Shahid Shaikh3, and Zubair A. Shaikh4 Department of Computer Science, National University of Computer & Emerging Sciences, Karachi,

RI

1,4

Pakistan

SC

Email: [email protected], [email protected] 2 College of Computing & Information Sciences Karachi Institute of Economics and Technology, Karachi, Pakistan Email: [email protected] Department of Electrical Engineering

NU

3

Habib University, Karachi, Pakistan

MA

Email: [email protected]

ABSTRACT. This paper presents context development and requirement validation asthe primary

D

considerations in order to overcome the problems of obsolescence and maintenance in Enterprise

TE

Resource Planning(ERP) systems.In general, the process of knowledge integration can be employed in order to dynamically validatethe users’ requirements in information systems,Moreover, context development requires that the contributions of all stake holdersinvolved during interactions,

AC CE P

be properly gathered, analyzed, and represented by knowledge models. We have applied these concepts to the ERP domain. We use real-life data from diverse ERP processes of Pakistan State Oil (PSO), a well-known petroleum firm based in Pakistan.We employ the concept of “context awareness” in order to model a sustainable context of the PSO processes (the system model), along with a model of the users’ requirements (the requirement model). We also employ a context affinity measure in order to determine the impact of the systems model and the requirement model,on the validation of the users’ requirements.Moreover, we apply the concept of fault-toleranceto the systems and requirement models. Through an experiment, we demonstrate how data mining techniques (decision trees) can assist in pre-identifying diverse faults in PSO processes, e.g.,delays in timely delivery of petroleum products. In another example, we show how decision trees can assist in predicting faulty (or non-faulty) contextual product configuration in ERP-based software product lines. Keywords: Context awareness, Context development, Context validation, Context affinity measure, Systems model, Requirement model, Fault Tolerance, Software Product Line, Feature Model Conflicts, Trustable context, Data Mining, Classification, Decision Trees

1.Background and Motivation. Context is a critical component in the interaction between humans and computers. It is the outcome of situations associated with participants of an interaction, and generally describes the facts that are relevant in a particular environment of 1

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

interaction [10].Itcan be generally categorized as a physical context (e.g., location), computational context (e.g., a website analyzing the every-changing census information), and a user context (e.g., the demographic information about the user).These diverse contexts can assist in realizing semantics in order to support the development of reliable information systems critical in the areas of economy, health, and e-commerce. The modern economies focus on customer’s satisfaction, and therefore the importance of the evaluation of context is increasing [2]. An informationsystem developed without proper context evaluation and management is likely to become infeasible in a short span of time, resulting in eventual loss of precious investment[1].One of the challenges in the development of context-specific applications emanates in the area of “context modeling” which provides support to context management and reasoning.In this regard,modeling of real-lifeinteractionsrequiresboth processing and reasoning of context facts, in order to acquire a representation that is usable in typical applications. Not only does this result in the development of trustable context, but also contributes towards realization of quality objectives of the systems vis-à-vis reliability, usability and scalability. In order to acquire this goal, it is important to employ context for characterizing the situation of an entity [9, 3].Here, an “entity”can be a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and the application themselves. For instance, consider an online buyer interacting with some E-commerce portal. Then, the computer software being used by the buyer entity constitutes a subset of his context.Thisdefinition also allows the context to be either explicitly or implicitly indicated by a givenentity, e.g., the identity of the buyer entity can be established visually (implicitly) or via login dialogue (explicitly).Most importantly, it can assist in validating the requirements of the concerned entities. For instance, the requirements of the buyer entity can be validated by the context (behavior) of the computer software, i.e., whether this software is catering for the needs and preferences of the user (or not). This paper dwells at length on theapplication of the aforementioned conceptsto a particular class of information systems, i.e.,Enterprise Resource Planning (ERP) systems [12].ERPs integrate the dynamic flow of information between diverse operating units of an organization, e.g., sales, marketing, purchase, customer relationship management etc. Such an activity regulates the information flow, and leads to increased productivity and efficiency in the execution of theseunits. Moreover, each operating unit is characterized by its“business process”, e.g., the process of maximizing the sales, the process of an increased marketing activity etc. In our opinion, modeling the context of a given ERP (for some domain) implies the collective modeling of the context of each of the ERP’s dynamic business processes.In fact, any situation of a business process, which can assist in identifying specific requirements of this process, can be labeled as a dynamic context of this process [3].For instance, the “timestamp” and the “buyer” of a product sale are two possible contexts of the sale process. Considering these dynamic contexts collectively would require that the requirements and contribution of all ERP stake holders related to their respective business processes, be accurately captured, validated and integrated in the 2

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

design of the ERP. For instance, in a production process, the requirement (output)may be that of a product, while in a marketing process, it may be merchandise. Furthermore,the production process can possibly employ raw materials,components and sub-assemblies, while the marketing process can focus more on the features and attributes(properties) of the product. In this regard, appropriate dynamic context modeling of the ERP processes can leadto a more comprehensive and robust ERP processing, in which each requirement is appropriately modeled and validated throughout the ERP lifecycle. Therefore, we need to identify and create the right context in ERP specification and design practices, and to develop a context classification process that imposes constraints during context elaboration or requirements elaboration phases.In fact, the only research targeting these requirements is that of Daneshgar [6], who identifies objects (entities) within each business process, and proposes a model whereby these objects can collaborate with each other in order to satisfy the requirements of the ERP consumers. Another related work is that of Raban and Garner [1], who propose a “requirement model” for specifying the users’ requirements, and a “system model”for modeling the context of an information system. In both these works, the lacking factor is that of context classification, i.e., identifying the different types of contexts, for a given ERP. These context classes could be employed in order to better understand the users’ requirements, as well as the collaboration between different contextual entities. In fact, such a limitation has been identified by [1]. In this paper, we have specifically addressed this limitation, by applying context classification to the models presented in [1, 6].We have modeled this dynamic activity in the context of knowledge engineering, which is typically employed in order to develop trusted contexts in information systems [4]. In this regard, we prove that knowledge acquisition,representation, and integration techniques can be successfully combined with our contextmodeling method. This createsa context development environment which manages the ERPs context in order to (satisfy and) validate the users’ requirements. Moreover, we employ acontext affinity measure in order to determine the combined impact of the systems model and the requirement model, on the validation of the users’ requirements. One major contribution of this paper is that we add the dimension of “fault-tolerance” to context management. In fact, traditional ERPs provide robust fault-tolerant software services, which monitor the collaborative flow of business processes, in order to detect one or more anomalies [12]. Such services detect faultsafter they have occurred, e.g., a sale which has not been credited in the sales invoice, production goods that were procured but were not delivered to their destination etc. In this paper, we apply data mining [11] techniques in order to enhance the concept of fault tolerance in ERP systems. Specifically, we learn a classification model for each fault, which is able to forecast the occurrence of a fault before it actually occurs. To the best of our knowledge, such a technique has not been applied previously in the domain of ERP systems. In order to validate our two-fold contribution, we apply our context and fault

3

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

classification models to real-world ERP data of Pakistan State Oil (PSO)1, a well-known petroleum company based in Pakistan. We focus on three business processes of PSO, i.e., sales and delivery of products, product inventory management, and report (invoice) generation of sold/delivered products.We classify the contexts of these processes, and show how they collaborate with each other. We also identify possible faults in these processes, and through a data mining experiment, we demonstrate that one of these faults can be detected in advance, e.g., the delayed delivery of petroleum goods to their buyers. Another major contribution of this paper is that we add a similar dimension of “robust product feature selection” to context management. Specifically, ERP-based Software Product Lines (SPL) allow configuration of a unique product (e.g., mobile phone, automobile, computer hardware etc.) by configuring a set of constituent modules in a pre-defined context [17, 18, 19, 20]. Management of this context is a complicated task because context designers cannot easily concur on a unified selection of a set of feature in each module. When the modules are considered collectively in the final contextual configuration, a set of conflicts can arise which delay the final product and waste important business resources such as time, money, employee hours etc. Such a context can only be managed through automated mechanisms. Based on a previously conducted research [21], we show how data mining can be used to manage this context by predicting conflicting (or non-conflicting) feature selections in advance, while the product is currently being configured. We demonstrate this through a real-life data set of an anonymous ERP-based software product line. This paper is further divided as follows. In Section 2, we have described our proposed research methodology. Specifically, we initially describe our contextual classification scheme for the (PSO’s) ERP. Then, we employ this scheme while modeling the context of thediverse business processes of the ERP. Later on, we specify techniques for validating the requirements of these processes based on the modeled context. In Section 3, we have presented the details of our data mining experiment, in order to pre-detect one of the faults in the ERP, i.e., the delayed delivery of petroleum products to their respective buyers. In Section 4, we demonstrate how the context of ERP-based software product lines can be managed in a better way by using data mining, which can predict conflicting (faulty) product configurations in advance. Finally, in Section 5, we present the conclusions 2.Research Methodology. According to Raban, the main challenge in developing information systems is to transform the original user requirements into a working system that meets the complete set of these requirements [1]. This is a complex proposition and entails the development of comprehensive context and its representation to create a system model. A pioneering work in this regard has been done by Sowa and Zachmann [13], who propose a taxonomy that relates real-world concepts to the concepts that describe the architecture of an information system, and its implementation. In this paper, we are proposing a taxonomy as an extension to this work, in the form of a “contextual 1http://www.psopk.com/

4

ACCEPTED MANUSCRIPT

NU

SC

RI

PT

classification”that incorporates the stakeholders’perspective, focus and interrelated dimensions namely structural, technological, intellectual, and socio- emotional dimensions [5]. We use the term “system model” to refer to our classified contextual model, and the “requirements model” to refer to the set of users’ requirements mode.Our ultimate objective is to have the requirements and system models integrated with a working ERP system (information system), hence making the requirements verification and completeness realization even more comprehensive and efficient. The introduction of context classification is an important and necessary extension to the earlier definition of contextand is also justified on the premise that context can be represented by a set of relevant collaborative semantic concepts or “objects” [1,6].The identification of contexts can be helpful to provide explanation in terms of “an interaction of contextual conditions, actions and consequences” [5].

AC CE P

TE

D

MA

2.1.Contextual Classification.In this section, we classify the ERP context into three types, i.e., environment, organizational, and information system context. We describe them as follows. Environmental Context: This entails interactions involving customers, competitors, suppliers and technologies. All external entities having a significant role and bearing on business processes may be considered as contributors to environmental context. It is of particular importance in relation to the approach in which product related information and suppliers are managed. Organizational Context: This is based on interactions involving different internal tiers of an organization (staff working in various departments), cultural influences due to dealings with clients and suppliers, and efforts to achieve unique solutions through continuous innovations. Socio-emotional dimension can be made part of organizational context in view of the fact that users and stakeholders have emotional attachments to the organization and their contribution is essential for knowledge creation. Information Systems (IS) Context: This incorporates the contextual information related to the client, that will assist the IS designers to continuously and seamless integrate the clients’ requirements within the IS.This information base is acquired through direct interaction with the clients. 2.2.Contextual Knowledge and Awareness. The contextual classification is the penultimate step towards context development and needs to be followed up with contextual knowledge integration. In fact, ERP processes have a collaborative nature and incorporate wide knowledge flows through potentially related channels (sub-systems or sub-processes) [12]. Based on this, we use the objects that make up the channels within the ERP processes to represent contextual knowledge [6]. More precisely, the contextual knowledge is represented by a set of relevant objects contextualized to actors within the ERP process. Here,an actor is a human agent and has a role to perform certain task(s), and each object is 5

ACCEPTED MANUSCRIPT

TE

D

MA

NU

SC

RI

PT

associated with a particularsemantic information [6].We use the term “awareness” in order to denote how the collaborating objects are “aware” of each others’ presence. Our objective is to employ an awareness-based ERP methodology as a vehicle to promote contextual knowledge and knowledge sharing. In fact, identifying the awareness requirements of actors within the ERP is essential for the development of conceptual representation model, and it can be achieved using a set of collaborative semantic objects [6]. This model represents all the activities within a given ERP process as tasks to be performed by actors.Collectively, these activities have been referred to as ERP process Map. In this context, we assume two categories of resources, namely the “task resources” and “collaborative resources”. A task resource is one that is required for performing a task with no regard to task’s collaborative resource requirements. On the other hand, a collaborative resource is used to describe the additional resources required by a task in order to collaborate with others through their tasks.

AC CE P

Figure 1 Example of an ERP Process Map with three roles, five simple tasks and a collaborative task

Figure 1 illustrates a sample ERP process in which there are three actors, identified by their respective roles, i.e., ROLE 1, ROLE 2 and ROLE 3. In all, there are five tasks, i.e., T1, T2, T3, T4, and T5. T1 is executed in the context of ROLE 1, T2 and T5 are executed in the context of ROLE 2, and T3 and T4 are executed in the context of ROLE 3.From this perspective, all these tasks are simple tasks, in the sense that they don’t use any collaborative resources. However, Figure 1 also shows that all the roles are connected to each other through a collaborative task, through which T1 and T4 collaborate with T3, T2, and T5. The degree of awareness of collaborative objects is actually specialized knowledge about the objects that can provide an actor with various concepts of ERP processes.It can be defined in terms of semantic concepts such as roles, tasks, task resources and collaborative resources [6].Moreover, it is important to distinguish between the contents of knowledgeresources,fromthe contexts (channels) within which the flow of the knowledge is shared. Specifically, the knowledge resources are, more or less, rigid (fixed), while the flow of knowledge is continually changing according to the requirements model. The actual level of awareness of an actor may then be considered as the number of objects the actor can identify on the ERP process Map [6]. The required level of awareness is the minimum level of awareness that is expected from any actor (with a given role)who intends to 6

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

perform a particular task. In order to explain the aforementioned concepts more clearly,we now consider the ERP process of Pakistan State Oil (PSO), the top-most petroleum company in Pakistan. This processconstitutes several different channels, e.g., procurement of products, customer relationship management, software maintenance and diagnostics etc. However, the bulk of the ERP activity is centered around three channels, i.e., Sales Management (SM),Inventory Management (IM),and Report Generation (RG). Hence, in this paper, we will focus on these channels only.We describe them as follows. SM Channel:The SM channel is shown in Figure 2. It comprises those tasks that depict activities related to the management of PSO product sales. In Figure 2, the terms CT and ST represent a “collaborative task” and a “simple task”. So, T1 and T4 are collaborative tasks, and T2 and T3 are simple ones.We describe them below.  Task T1:Task T1 comprises three related tasks. The first of these is “Generation of the Delivery Chalaan (DC)”. The DC is a document that summarizes relevant information required in order to deliver a (petroleum) product to its buyer, e.g., the demographic information of the buyer, details of the bought product, the date of this purchase, the expected date of delivery, the medium of delivery (truck, bus, airplane etc.), the tracking number of the delivery etc. The second task of T1 is “Customer Interaction”, i.e., in order to generate the DC, it is important to interact with the customer (buyer), in order to understand his buying preferences, e.g., the exact product he desires, the desired quantity of this product, the expected timeframe within which this product is required etc. Finally, the third task of T1 is “Stock Reduction”, i.e., when the DC is generated, the quantity of the bought item is deducted from the stock. This requires a separate task because of several checks performed by the PSO personnel while making the reduction, e.g., verifying the quantity of the current stock, verifying the quality of the bought stock, managing the extraction of this stock from the PSO warehouse etc. In fact, PSO supports two types of stock reduction tasks: 1) Cash Payment, i.e., one in which the buyer pays all of his due amount in cash, at the time of the transaction, and 2) Deferred Payment, i.e., one in which PSO allows the buyers to defer the payment till the later date, but agrees to deliver the bought goods on time. The Stock Reduction task in Figure 2 supports Deferred Payment process. We note that, for the sake of privacy, we were not provided with specific details of the DC and Invoice.  Task T2:Task T2 is related to the execution of database related operations, e.g., adding products onto the DC, deleting previously sold product, updating the product definition etc.Within PSO, a separate team has been assigned in order to execute and monitor the performance of T2.  Task T3:Task T3 is related to the approval (or disapproval) of the DC by an administrative committee. This committee makes the approval decisions based on a set of business rules, which could themselves be modified in case of performance issues. For instance, if a set of business rules approve 100 DC’s over a couple of

7

ACCEPTED MANUSCRIPT

RI

PT



days, and 40 of these exceed their expected delivery date, then the committee could decide to modify these rules. Task T4:Task T4 comprises two related tasks. The first is the“Generation of the Sales Invoice”. The (Sales) Invoice can be considered as an accompanying document of the DC. It exploits some data from the DC (which is the second task of T4), e.g., the timestamp of the sale, the name and address of the buyer, details of the bought product etc.

AC CE P

TE

D

MA

NU

SC

IM Channel:The IM channel is shown in Figure 3. It comprises those tasks that depict the management of the product inventory (PSO’s product warehouse). In Figure 3, ST represents a “simple task”. The IM channel comprises three simple tasks, i.e., T5, T6, and T7. We describe them below:  Task T5: Task T5 is related to “Stock Reduction”, which has been described in Task T1. Contrary to T1, T5 supports both Cash Payment and the Deferred Payment processes. In this aspect, T1 is actually a sub-task of T5, and the management team of T1 is a subset of the whole team used to manage T5.  Task T6: Task T6, similarly to T2, is related to the execution of database-related operations. But whereas T2 applies these operations only to the DC, T6 applies and monitors their executions for both DC and the Invoice documents. In other words, T2 is a subset of T6.

Figure 2 Tasksfor the Sales Management Channel; CT = Collaborative Task, ST = Simple Task, T1, T2, T3 and T4 are labels for the four possible tasks

8

SC

RI

PT

ACCEPTED MANUSCRIPT

Task T7: Task T7 is related to PSO’s own purchasing process. Specifically, it maintains the stock amounts of those items which are bought by PSO, e.g., incrementing the total number of liters of gasoline immediately after it is delivered.

MA



NU

Figure 3 Tasksfor the Inventory Management Channel; ST = Simple Task, T5, T6, and T7 are labels for three possible tasks

AC CE P

TE

D

RG Channel:The RG channel is shown in Figure 4. It comprises those tasks that depict the generation of complete reports, of both purchases and sales. In Figure 4, ST represents a “simple task”. The RG channel comprises three simple tasks, i.e., T8, T9, and T10. We describe them below:  Task T8:Task T8 is related to the “Search Facility”, i.e., a search engine through which managers can query specific data about the PSO products, as well as about the PSO’s customers (buyers). The main limitation of this task is that both the product base and the customer base are quite expansive, and hence, the execution of the queries needs to be optimized, in order to provide results efficiently.

Figure 4 Tasks for the Report Generation Channel; ST = Simple Task, T8, T9, and T10 are labels for three possible tasks

9

ACCEPTED MANUSCRIPT

RI



Task T9: Task T9 is related to the generation of the complete sales history of PSO, for a given time period, e.g., for the year 2010 on a monthly basis. Such a report will contain all data from the related Delivery Chalaans and Invoices. Task T10: Task 10 is similar to T9, but contains comprehensive reports related to PSO purchases (rather than the sales). In fact, PSO has its own voucher (document) related to its purchases, but we were not provided with its specific details for the sake of privacy.

PT



AC CE P

TE

D

MA

NU

SC

At this point, we would like to mention the contextual classes related to the ten tasks illustrated in Figure 2, Figure 3, and Figure 4, i.e., environmental, contextual, and Information System (IS) contexts (refer to Section 2.1). We enlist this information below:  Task T1 is related to the environmental and IS contexts because it involves interaction with the (external) customer, in order to acquire information about his desired product. It is also related to the organizational context because both the generation of the DC and the reduction in stock are activities internal to the PSO.  Tasks T2 and T3 are both related to the organizational context because database modifications and (dis)-approvals of DC are internal to PSO.  Task T4 is related to the environmental context, because the generated sales invoice is passed on to the customer. It is also related to the organizational context, because the invoice generation involves internal mathematical calculations, according to the business rules of PSO, e.g., the rate of a bought product.  Tasks T5, T6, and T7 are related to the organizational context, because all stock-related and database-related activities are generated and managed only within PSO.  Tasks T8, T9, and T10 are related to the organizational context; the search activity performed by the PSO employees, and the sales/purchase histories generated by the managers, require execution of workflows that are internal to PSO, e.g., gathering sales data from the database, retrieving search results from the database etc. From the above discussion, it is obvious that a majority of the tasks are related to the context that models the internal workflows of the PSO’s ERP. In fact, external workflows model the context that is basically related to the interaction process with the customers, e.g., acquiring or confirming purchase information. Such a classification of context modularizes and facilitates the context modeling task, primarily through a seamless integration of the external context with the internal one, e.g., by catering for the customer’s preferences while recommending him products. 2.3.Requirement Alignment and Context Validation. Based on the aforementioned discussion, the ERP process map can now serve as the basis for the development of the ERP system model and finally, the enterprise requirement model. While the ERP system model can be used repeatedly, the requirement model is required to be constructed for each implementation separately. As both these models are related to the business processes of a 10

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

given ERP, it is logical to use the common modeling conventions that would serve as basis for issues related to requirement. In this context, we will use the Object Process Methodology (OPM) [7] to model both the ERP system and enterprise requirements. In OPM, we deal with two equally important classes of entities, i.e., objects and processes, which are connected by procedural links and contextual relations.As an example, let us consider Figure 5, which illustrates the OPM representation for the “Receiving Purchase Order” activity within PSO. Specifically, this activity involves all the tasks that are executed when a purchase occurs by some customer, generally termed as the “purchase order”. So, Figure 5 illustrates both the structure and behavior of different PSO objects when a purchase order is received. Here, the rectangles represent entities, i.e., something which has a potential of stable existence, the ovals represent processes (patterns) of transformations that the objects can undergo, and the directed arrows represent the links between the object and processes. We describe Figure 5 in detail as follows:  Customer: The customer who has purchased the product, and hence, generates the purchase order (Generate Purchase Order),  Invoice: The physical bill (also available digitally) for the purchasing customer, which is received by the PSO from one of its branches at which the purchase has been made (Receive Invoice),  Price List: The list of the prices of available products, which is used in order to maintain the purchase order (Receive Purchase Order),  Object/Item: The generic notation for an item offered by PSO, i.e., which can be purchased, whose detail is used to receive and maintain the purchase order (Receive / Maintain Purchase Order),  Supplier: The person who supplies the purchased product(s), who can request for shipping facilities (Request Shipping), and receives details related to the purchase order (Receive Purchase Order),  Shipping Providers:The shipping service that can be used by the Supplier, e.g., any standard delivery service like the US Postal Service 2 , DHL3 etc., which provides the shipping price (Send Shipping Price), and also prepares the consignment and delivers it (Prepare and Deliver Shipping),  Scheduler: The person who schedules the delivery of the purchased product, whointeracts with the requests PSO to initiate the scheduling activity (Request Scheduling), and delivers a shipping schedule (Send Shipping Schedule).

2http://www.usps.com/ 3

http://www.dhl.com/

11

TE

D

MA

NU

SC

RI

PT

ACCEPTED MANUSCRIPT

AC CE P

Figure 5 The OPM representation of the “Receiving Purchase Order” activity

OPM uses a single graphical tool, i.e., the Object Process Diagram (OPD) set, in order to model important details of the system, its structure and its dynamics. In fact, using a single view representation makes model matching rather convenient [7]. The requirement model will remain dynamic throughout the alignment process until the requirements are consolidated and rationalized. We describe these concepts in detail in the following two sections. 2.3.1. The Enterprise Requirements.The requirement perspective must be seen in terms of providing flexibility and adaptability to the existing processes with a view to incorporate changes as may be desired keeping in view the suitability and feasibility as per the context. Based on this premise, we are now proposing a framework which classifies the requirements into contextual packages [7]. The term “contextual packages” is justified as per the definition in the theory of conceptual graphs,where the context has been defined in terms of what propositions it allows and represents.It also provides semantics to the definition of context when used for packaging information[8]. We now describe different types of these packages. Core system package: The core system package comprises interfaces involving interaction with external agents (e.g. responding to customer queries, placement of orders to suppliers 12

ACCEPTED MANUSCRIPT

PT

and reporting to tax authorities).The system interfaces are represented in OPM as detailed inputs and outputs of the processes performed by the system. In this context, the core system package is related to the environmental context (refer to Section 2.1).

SC

RI

Core business process package:The core business process package entails processes which forms the core value for the enterprise, and generate the competitive advantage. These may include inventory management process (in case of PSO for instance, which must maintain reasonable inventory of oil), and other critical business processes.We note that no change occurs during the execution of these processes. Business processes are modeled as process in OPM and are related to the organizational context (refer to Section 2.1).

D

MA

NU

Business logic package:The business logic package signifies the broader organizational context, and provides a basis for the implementation of business processes. The organizational goals are realized through the proper application of business rules, which provide the relevant logic that remains unchanged during the execution of the requirement alignment process. The OPM representation of a business rule only identifies the requisite details of this process, along with itscorresponding contextual objects.

AC CE P

TE

Information objects package:This package is utilized by objects of specified business processes. Their structure and relationships are directly mapped by OPM.These objects have a strong relationship with the systems context. 2.3.2. The ERP System Model. The ERP system model represents the overall scope of alternatives and dependencies among business processes options supported by the system. Figure 6 illustrates the Object Process Diagram (OPD) for the “Receiving Purchase Order” activity, represented as a system model dependency graph. Specifically, each OPD is a node with arcs connecting it to descendent OPDs that expose details of one or more entities in parent OPD. It models the various aspects, structure and dependencies involved as part of the module. The use of OPDs is consistent with our approach to use OPM to specify the requirement model as well as system model to promote a coherent and single model representation.

13

D

MA

NU

SC

RI

PT

ACCEPTED MANUSCRIPT

AC CE P

TE

Figure 6 Object Process Diagram (modeled as a dependency graph) of the Receiving Purchase Order activity

Table 1 illustrates the details of the node dependencies shown in Figure 6. In all, we have a total of 12 OPDs, numbered from 0-11. Their details are as follows:  OPD 0 represents the complete Receiving Purchase Order activity, and hence, all the other OPDs are its descendants, i.e., follow from it,  OPD 1 represents the complete invoicing activity; its descendants include all tasks necessary for generating the invoice, i.e., calculating the price of the bought products(s) (OPD 2), sending the total shipping cost (OPD 3), and generating the actual invoice (OPD 4),  OPD 2 represents the calculation of the price, followed by that of the shipping cost (OPD 3) and the generation of the invoice (OPD 4), OPD 3 represents the calculation of the shipping cost, after which the invoice is generated, OPD 4 represents the task of generating the invoice; this completes the invoicing activity, and hence, has no descendants,

14

ACCEPTED MANUSCRIPT

OPD 5 represents the complete shipping activity, its descendants include all tasks necessary for shipping the bought product, i.e., preparing the shipping consignment (OPD 6), requesting to transact this consignment (OPD 7), and scheduling this consignment (OPD 8), OPD 6 represents the task of preparing the consignment, e.g., by extracting the bought product from the PSO warehouse and packing them for delivery; it is followed by a request to transact this delivery (OPD 7), along with its schedule (OPD 8), OPD 7 represents the task of formalizing a delivery of a purchased order; as a result, the PSO product becomes officially legal for delivery, and includes the calculation of the shipping cost (OPD 3), along with the scheduling activity (OPD 8), OPD 8 represents the actual receipt of the scheduling the shipping process, e.g., by determining the date and time of the expected delivery; once this schedule is ready, it can be dispatched to the concerned shipping personnel (OPD 11), OPD 9represents the complete scheduling activity, in which schedules can be requested (OPD 10), or sent in response to some request (OPD 11), OPD 10 represents the task of requesting for a schedule; this actually leads to a design of the complete schedule for a given shipping consignment, OPD 11 represents the task of sending the designed schedule to the shipping department.





  

AC CE P



TE

D



MA

NU

SC

RI

PT

OPD Number OPD Name Descendant OPDs 0 Receiving Purchase Order 1,2,3,4,5,6,7,8,9,10,11 1 Invoicing Activity 2,3,4 2 Initiate Price Calculation 3,4 3 Send Shipping Price 4 4 Generate Invoice 5 5 Shipping Activity 6,7,8 6 Prepare Shipping 7,8 7 Request Shipping 3,8 8 Receive Schedule 11 9 Scheduling 10,11 10 Request Scheduling 11 11 Send Shipping Schedule TABLE 1. Node Dependencies for the OPD of the Receiving Purchase Order activity

2.3.3.Context Affinity Measure. We now introduce a measure for context validation namely Context Affinity Measure (CAM) to check the compatibility of a requirement vis-à-vis the context of ERP system model. It consists of two phases [7]. 15

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

In the first phase, CAM computes a matching score for two measures, i.e., Entity Similarity (ES) and Relational Similarity (RS), in order to determine the validity of the particular requirement as per the context of ERP model reflected through the collaborative semantic objects. ES is the proportion of collaborative semantic objects (entities) that have a matching entity in E. ES can be determined by using a query, which may compare the entities in the system model with that of entities in the given requirement, based on the type and name.The resultsare matching pairs of (R, E), where R is the requirement model and E is the system model. The ES score of each pair (R,E) exceeds a given threshold. The next step is to assess the RS for each of the pairs of(R, E) by an exhaustive search for matching of each link in R. The link matching entails matching link of the same type, and relates matching entities for both the source and destination of the link[7]. The Link Match (LM) is then estimated by comparing the cardinalities of the links in R and E determined by participation constraints associated with source and destination. This may give rise to one of the following scenarios:1) The participation constraints of both source and destination are same, in that case the LM is considered as equal to 1, and (2) The participation constraints of either is identical or they are different altogether, and therefore, may be considered as equal to a constant C1or C2, where C1 and C2 are user-defined (0≤ C2≤ C1≤1), and reflect the degree (threshold) of match between the link of different cardinalities, in the opinion of the user. The overall matching score(MS) of a pair(R, E) can now be computed as a weighted sum of the two similarity measures subject to the condition that neither of ES(R,E) and RS(R,E) equal zero[7]. MS(R, E) =W1× ES(R, E) +W2×RS(R, E)(1)

ES(R, E) > 0, RS(R, E)> 0, W1 + W2 = 1 (2) Where W1 and W2 are weights assigned to ES and RS respectively. In the second phase, referred to as Bottom Up Aggregation (BUA), we determine the feasible combinations of requirements whose matching scores have been determined in the first phase [7]. The matching score in the first phase actually serves as an input to BUA which ultimately aggregates the matching scores up the system model dependency graph and identifies their feasible combinations.

16

D

MA

NU

SC

RI

PT

ACCEPTED MANUSCRIPT

TE

Figure 7 Comparison of the Requirement Model R (illustrated in (a)) and the System Model E (illustrated in (b)) in the context of computing the Context Affinity Measure (CAM)

AC CE P

Figure 7 shows the model of requirements R and its representation in the in ERP system OPD. Using the two step context affinity measure CAM, the computation of Matching Score for the pair of requirement can be carried out as follows. All the entities in Figure 7 (a) have matching entities in Figure 7 (b) imply that ES = 1. By opting for equal weights for ER and RS say W1 = W2 = 0.5, and assuming that C1=0.7 and C2 = 0.6 (based on the fact that in either case the participation constraints of source and destination are either different or identical. Therefore,the Relationship Similarity(RS) can be calculated as: RS = (1+1 +0.7 +0.6)/4 i.e. the average of all LMs of the links in R =0.825. The overall matching score, MS =0.5 × 1 + 0.5× 0.8 =0.9 which verifies that there is high degree of context affinity between requirement and ERP model and therefore the requirement stands validated. 3. Fault Tolerance in ERPs through Data Mining.In this section, we will apply data mining techniques to a particular business process of PSO, in order to pre-identify faults in this process, i.e., before they actually occur. In fact, the concept of “fault-tolerance” in the domain of ERP is quite limited.Specifically, the primary focus of many companies is to provide robust computer hardware that is capable of effectively and efficiently managing the workload of the ERP activities, e.g., the IBM Tivoli Workload Scheduler [14], Stratus ftServer [15], Itanium servers [16]etc. Such hardware carry out fault-tolerance in the sense 17

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

of preventing system crashes, e.g., of one or more ERP modules. They do not ensure fault-tolerance in the sense of software-based faults, e.g., detecting an anomalous (outlying) amount in a sales invoice, or a delayed delivery of the purchased goods etc. In fact, ERPs have generally a fault-tolerant design, which enable them to keep running in the case of system crashes, or software faults. In the latter case, this is ensured through the dynamic application of some business rules, e.g., the sales amount exceeding a certain threshold should not be invoiced, chance of a delayed delivery should be minimized through the selection of better transport and routes etc [12]. For instance, in PSO, the business rules ensure that several products can only be purchased in limited quantities, the scheduling activity should terminated within a specified time, the purchased goods should be delivered within an expected timeframe etc.Although such rules minimize the occurrence of faults to some extent, we believe that they are not appropriate tools for such activity. The reason is that these rules are based largely on human intuition and previous experience, and hence, might be both illogical and prone to error themselves.In fact, over the past couple of years, several business processes of PSO were temporarily faulted due to inappropriate managerial decisions4. In this context, we believe that there is a need to perform concrete analysis of the data related to a business process, which can assist us in pre-identifyingthe faults related to this process, i.e., indicate in advance that a particular fault is going to occur (or not). This requirement necessitates the application of data mining techniques [11]. Data mining involves the extraction of hidden, novel, interesting and potentially useful information from a large corpus of available data. In our task, we apply the data mining technique of classification, which involves the following basic steps:  The data, which typically resides in a database, is divided into different classes,  Each instance (record) of the database is assigned a symbolic label known as the “class label”,  A mathematical model, known as the classifier, is trained using the records in the database as input; after training, it is able to predict the class labels of unknown instances, i.e., those not used in the training,  The performance of the classifier is gauged by determining the accuracy of the predictions made for unknown instances, i.e., the percentage of instances for which the classifier was able to output. In our task, the fault that we have selected for pre-identification is the untimely delivery of purchased goods to the customer. Our database consists of the following seven attributes: 1. Destination, i.e., the location to which the goods are to be delivered; this is discretized into eight Pakistani cities, i.e., Karachi, Islamabad, Hyderabad, Thattha, Mianwali, Gujrat, Gujranwala, and Dera Ghazi Khan,

4

We cannot provide details of these faults for the sake of privacy.

18

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

2. Source, i.e., the location from which the goods are loaded onto the delivery truck5; this is also discretized into eight Pakistani cities, i.e., Lahore, Rawalpindi, Sialkot, Multan, Attock, Karachi, Sukkur, Hyderabad) 3. Delivery_Time, i.e., the expected time of the delivery, in the number of days, 4. Traffic, i.e., the average amount traffic on the delivery route; it is discretized into two symbolic variables, i.e., High (a large amount of traffic) and Low (very little or no traffic)6, 5. Distance, i.e., the distance in kilometers between the Destination and the Source, 6. Weather, i.e., the expected weather on the delivery route; it is discretized into three symbolic labels, i.e., “Rainy”, “Cloudy” and “Sunny”7, 7. Delivery_Status, i.e., the class variable depicting the final status of the delivery; it is discretized into two class labels, i.e., Successful (the delivery was successful) and Unsuccessful (the delivery was unsuccessful). Figure 8 shows an example of two instances. The first one depicts a successful delivery from Karachi to Lahore, which was delivered over 1500 kilometers in 8 days, with low traffic and a cloudy weather. The second one depicts an unsuccessful delivery from Islamabad to Lahore, where the expected delivery time was 2 days over a distance of 600 kilometers, and there was high traffic in rainy weather.

Figure 8 Instance with correct context Although PSO employs different transportation media, we have focused our task on delivery trucks, which are used most frequently. 6 We discretized in this way after consulting with the PSO personnel regarding the traffic activity on different routes. 7 We also discretized this variable after acquiring the weather information from PSO personnel. 5

19

ACCEPTED MANUSCRIPT

MA

NU

SC

RI

PT

3.1.Evaluation Methodology.In total, we have acquired 100 instances from PSO, out of which 55 are successful deliveries and the remaining 45 are unsuccessful ones. We apply the standard 10-fold cross-validation [11] on these instances. Specifically, we divide these instances 10 times, with each division being labeled a “fold”.In each fold, a different set of instances is used for training, and for determining the accuracy of the classifier. In this way, we ensure that each instance is used both for training, as well as for determining the accuracy, hence ensuring a more robust classification process (as compared to the technique in which there is just one fold).The classifier that we have selected is J48 [11], which is a well-knowndecision tree algorithm.A decision tree employ an attribute selection criterion in order to iteratively select attributeswhich optimize this criterion, e.g., the information gain. The selected attributes are represented as nodes of the tree, and the leaves of this tree form the class labels (illustrated in the next section). For carrying out the classification, we have used the Weka tool8, a machine learning software written in the Java language.

AC CE P

TE

D

3.2.Results and Discussion.In this section, we will present our results. The J48 decision tree learnt for our task is shown in Figure 9. Here, the ovals represent attributes, and the rectangles represent class labels. Out of seven available attributes, J48 has selected five, i.e., Delivery_Time, Traffic, Distance, Weather, and the class attribute Delivery_Status. This implies that the Destination and Source were not useful, i.e., they wouldn’t have been helpful in classifying our data.

8http://www.cs.waikato.ac.nz/ml/weka/

20

D

MA

NU

SC

RI

PT

ACCEPTED MANUSCRIPT

AC CE P

TE

Figure 9 The J48 Decision Tree learnt for the classification problem of Successful and Unsuccessful product deliveries within PSO

The first selected attribute (at the root) is Delivery_Time. So, if the Delivery_Time is less than 2 days, then the delivery will be successful. If it is greater than or equal to two days, then we need further information for classification. This is provided by the Traffic attribute. So, if the Delivery_Time≥ 2, and the Traffic is Low, then the delivery will be successful. In this way, we can write six possible classification rules as follows: 1. If Delivery_Time< 2, thenDelivery_Status=Successful 2. If Delivery_Time ≥ 2 and Traffic=Low, then Delivery_Status=Successful 3. If Delivery_Time ≥ 2 and Traffic=High and Distance≤1000, then Delivery_Status=Successful 4. If Delivery_Time ≥ 2 and Traffic=High and Distance>1000 and Weather=Sunny, then Delivery_Status=Successful 5. If Delivery_Time ≥ 2 and Traffic=High and Distance>1000 and Weather=Cloudy, then Delivery_Status=Unsuccessful 6. If Delivery_Time ≥ 2 and Traffic=High and Distance>1000 and Weather=Rainy, then Delivery_Status=Unsuccessful. In essence, there are two situations of weather that lead to an unsuccessful delivery, i.e., when the weather is either cloudy, or rainy.So, consider the scenario where PSO has a delivery consignment with an expected delivery time over two days, over a long distance route (>1000) which has a high amount ofexpected traffic. Then, if the expected forecast 21

ACCEPTED MANUSCRIPT

RI

PT

over this route is either cloudy or rainy, then that consignment should not be dispatched, until the weather becomes a bit clear (sunny).This is exactly what we mean by “pre-identifying” a fault, because if the consignment is dispatched, then the chances of an unsuccessful delivery are very high. In all other possible situations enlisted above, the consignment can be safely dispatched. We note that, as the consignment delivery data continues to be generated, the decision tree in Figure 9 can be re-learnt whenever desired, in order to possible update the rules generated above.

AC CE P

TE

D

MA

NU

SC

4. Predicting Non-Conflicting and Contextual Feature Selections in ERP-based Software Product Lines. A well-known ERP solution is a Software Product Line (SPL) which is used to manage the configuration of one or more products [17, 18, 19, 20]. An SPL divides a contextual product configuration into different modules, with each module being configured separately. The contextual (product-based) configuration proceeds through the selection of a set of available features in each module, and the collection of all individual feature set selections is typically called a feature model. All available features are selected through a centralized feature repository. The feature model for any product is selected manually by the product designers, based on their experience, domain knowledge and product knowledge. Moreover, the selection of features is guided by the following constraints:  Mandatory: It is mandatory to select a given feature F in product P, e.g., the selection of a Gear is mandatory in configuring a Car product.  Optional: A given feature F can be selected in P (or not), e.g., the selection of Anti Breaking System is optional in configuring a Car product.  OR: Given a set of available features {F1, F2, …, Fn}, any feature from this set can be selected in P, e.g., selection of a particular type of bolt for the car engine chassis cover from a set of available bolts (other bolts in this set can be used for other engine parts).  Alternative: Given a set of available features {F1, F2, …, Fn}, only one feature from this set can be selected in P, e.g., selection of one particular steering wheel design from a set of available designs for a given Car product (only one steering wheel can be used at one time). The configuration of each module is done by a separate team of designers, who attempt to cater for feature constraints. A major SPL problem is the set of conflicts which could be generated when the feature selections of each module are merged into the contextual feature model.As a generic example, consider that a car is being designed on a SPL in three separate modules, i.e., Modules A, B and C. Module A is concerned with the exterior design the car’s body, Module B is concerned with configuring the interior of the car, and Module C is for configuring the car’s engine. When the contextual feature model is generated, the following set of possible conflicts can be generated:  The design of the car’s dashboard and the design of the seating arrangement are more spacious than the space allowed by the car’s exterior design 22

ACCEPTED MANUSCRIPT

 

PT



The configuration of several parts of the engine in Module C is not optimized according to the requirements of the management The car’s exterior design may not facilitate the generation of speed as envisioned by the engine designers, hence leading to useless spending of petrol (gas) There is no compatible electrical connectivity linking electric dashboard elements with their counterpart components in the engine The designers of module B are unable to decide on an appropriate seating design

RI



AC CE P

TE

D

MA

NU

SC

Resolving these conflicts can be done through extensive deliberation between the module designers, which unnecessarily consumes resources, e.g., time, money, employee hours etc., in reconfiguring an SPL product.Hence, recent research has focused on automating this feature model selection process, particularly through the use of Artificial Intelligence (AI) techniques [21]. In this section, we present a novel example of how decision trees can be used to understand the current feature selection criteria of the designers, and also to predict conflicting contextual configurations in advance.

Figure 10 A snapshot of feature selection data to be used in understanding and predicting feature conflicts; the first row represents the attributes (features F1 to F50) with the last column representing the class label

Consider a snapshot of the decision tree training data shown in Figure 10 . This data has been taken from an anonymous ERP-based product line based in Karachi, Pakistan. Here, the first row represents 50 Boolean features, F1 to F50, while the last column represents the class label called “LABEL”. The Boolean features are subject to all the four constraints mentioned above, listed below:  F1, F4, F6, F8 and F10 are mandatory features  F2, F3, F5, F7 and F9 are optional features  F1 has three alternative children i.e. F11, F12, F13. F11 further includes F14 which has two children F15 and F16 (excluding each other), F16 also includes F17  F2includesF18 which has three children F19, F20 and F21. They all are ORed  F8includesF36 which has two ANDed children F37 and F38. F37 also excludesF46 23

ACCEPTED MANUSCRIPT



F9includes F39 and F39 excludes F40.

AC CE P

TE

D

MA

NU

SC

RI

PT

Each row represents one particular product configuration as a Boolean vector (selected features in a configuration are labeled YES while unselected ones are labeled as NO). LABEL informs whether each row is conflicting (C) or non-conflicting (NC). In all, there are 250 rows. In order to mine the decision tree, we use the Rapid Miner tool 9 which allows users to experiment with a host of decision tree algorithms, e.g., CHAID, Random Forest, ID3 etc., to determine the most accurate one. We use the CHAID algorithm (for its interactivity) along with 10-fold cross-validation to achieve the classification rules listed below:  In the situation where all mandatory features have been selected (F1, F4, F6, F8, F10) and no optional feature has been selected (F2, F3, F5, F7, F9): o Deselecting both F11 and F12 (alternative constraints) leads to no-conflicts in 12 configurations, which implies that F13 was selected as the alternative constraint in these configurations. o Deselecting F11 but selecting F12 leads to conflicts in 11 configurations and no conflict in 10 configurations; this implies that more information about attributes is needed for a perfect classification into NC and C which can be acquired by un-pruning the tree (considering the tree at a smaller depth). o Selecting only F11 leads to no conflicts in 10 configurations in which F12 is de-selected and a conflict in 12 configurations if F12 is also selected.  When mandatory feature F1 and optional feature F3 are selected together in any configuration, a conflict is produced. We can see that these classification rules are conveying the particular configurations that are leading to conflicting and non-conflicting feature models. The accuracy of the mined tree is close to 80% which can be considered quite reliable considering that the training data is not very large (and hence, a close-to-perfect classifier might not be achieved). In order to gauge the prediction accuracy of our tree on product configurations currently in progress, we used Rapid Miner to test the tree with 5 such configurations. When we compared the results, a correct prediction of a faulty configuration was made in 2 out of 3 cases, i.e., with an accuracy of 67%. This is accurate, considering the limited amount of training and testing data. We believe that the aforementioned process can have more accurate training and prediction results with a considerable input of feature selection data. This can help the designers understand how they are currently selecting feature models, which type of feature selections are leading to conflicts (or no conflicts) in eventual feature models, and a prediction of conflicts while product configurations are in progress. This will save valuable ERP business resourcesand allow context modeling of product configurations in a more effective, efficient and stream-lined fashion.

9http://rapidminer.com/

24

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

4. Conclusions.This paper has suggested a methodology for Enterprise Resource Planning (ERP) systems, based on context classification and context awareness. Our aim is to support the development of a comprehensive context which can be used to add “completeness” and verify requirements. We also present a classification of context, which marks an important extension to the definition of context as presented by Sowa andZachman [13]. In our work, context awareness has been used as an enabler to add semantics to a variety of occurring interactions, while highlighting the requirement perspective from the point of view of different stakeholders. We have achieved this through the introduction of context definition in terms of collaborative semantic objects which allowed the use of object process map to further context awareness and knowledge integration. Moreover, we have applieda Context Affinity Measure (CAM), as a two-step algorithm, in order to check the contextual validity of a requirement by comparing a requirement model of the users with the ERP system model.We also propose the application of a robust, fault-tolerant technique, based on data mining, to ERP systems. This technique is able to pre-identify faults in diverse business processes of an ERP. We apply the aforementioned concepts to a real-time ERP of Pakistan State Oil (PSO), a well-known petroleum firm based in Pakistan. We also conduct an experiment on PSO data, in order to pre-identify the fault of an untimely delivery of PSO products. Our analysis basically reveals that, including other things, if the weather is either cloudy or rainy on long distance routes, then the chances of an untimely delivery are considerably increased. Hence, it’s not feasible to dispatch a delivery consignment in such a situation. Finally, we have also applied data mining techniques to ERP-based software product lines, in order to support context management by predicting in advance those product configurations that are going to turn out faulty later on, i.e., which contain one more conflicts in the configuration of modules of the software product line. Such knowledge can be used to save valuable business resources, e.g., time, money, employee hours etc. Acknowledgment. This work is partially supported by three entities: 1) Pakistan State Oil (PSO), a well-known petroleum-based company based in Karachi, 2) an anonymous ERP-based software product line organization, and 3) Center for Research in Ubiquitous Computing (CRUC).In this regard, we would like to especially acknowledge Mr. Hisham and Mr. MoinBalkhi, both of PSO, who provided us the PSO data for fault-tolerance, and also information about the ERP processes of PSO.

25

ACCEPTED MANUSCRIPT

REFERENCES R. Raban, B. Garner. Contexts in information systems development.Proceedings of the 7th International

PT

[1]

Conference on Conceptual Structures: Standards and Practices, Springer-Verlag, London, 1999 [2]

C. Cappiello, M. Comuzi, E. Mussi and B. Pernici. Context management for adaptive information

[3]

RI

Systems,Electronics Notes in Theoretical Computer Science, vol 146, pp. 69-84, 2006. J. Pascoie, N. Ryan, and D. Morse.Issues in developing context-aware computing. Springer-Verlag

[4]

SC

Berlin Heidelberg 1999.

B.Garner, R.Raban. Context management in modeling information systems. Information and Software Technology 41, 957-961, 1999.

J. C. Huang, S. Newell, S. L. Pan, R. D. Galliers. Knowledge integration processes within the context of

NU

[5]

Enterprise Resources Planning(ERP) systems implementation. The 9thEuropian Conference on Information Systems Bled,Slovenia, June 27-29, 2001.

F.Daneshgar.Context management of ERP processes in virtual communities. Idea Group Publications,

MA

[6]

2003. [7]

P. Soffer, B. Golany, D. Dori. Aligning an ERP system with enterprise requirements:

An Object

Process Based Approach. Elsevier, 2005.

G. W. Mmaineau and O.Gerbe. Contexts: a formaldefinition of worlds of assertions.Lecture Notes in

D

[8]

TE

Artificial Intelligence, No. 1257, pp. 80-94, Springer-Verlag, 1997. [9]

A. K. Dey and G. D. Abowd. Towards a Better Understanding of Context and Context –Awareness. Proceedings of the workshop on the What, Who, Where, When and How of Context Awareness, ACM

AC CE P

press New York, 2000.

[10] S.Greenberg. Context as a dynamic construct. Human Computer Interaction, 16(2):257-268, 2001. [11] J. Han and M. Kamber, Data Mining: Concepts and Techniques, 2 nd Ed., Morgan Kaufmann Publishers, ISBN 1-55860-901-6, March 2006. [12] B. Wagner and E. Monk, Enterprise Resource Planning, Third Edition, Course Technology Publishers, February 4, 2008.

[13] J. F. Sowa and J. A. Zachmann, Extending and formalizing the framework for information systems architecture, IBM Systems Journal, 31 (3), pages 590-616, 1992. [14] IBM

Centralizes

ERP

Workload

Management,

http://www-01.ibm.com/software/tivoli/beat/03232010.html, 2011. [15] Customers

Count

on

Stratus,

http://www.stratus.com/~/media/Stratus/Files/Library/CaseStudies/rijkzwaan.pdf, 2004. [16] Low

Cost

and

Greater

Flexibility

for

ERP,

http://www.itaniumsolutions.org/files/resource_media/F80C44C0-D8DB-AE53-30F7AA5B15BEC27C. pdf, 2007. [17] Jules White, Brian Dougherty , Doulas C. Schmidt , David Benavides,

“Automated reasoning for

multi-step feature model configuration problems, Proceedings of the 13th International Software Product Line Conference, San Francisco, California, August 2009. pp.11-20.

26

ACCEPTED MANUSCRIPT

[18] Jules White, Brian Dougherty , Doulas C. Schmidt , David Benavides,

“Automated reasoning for

multi-step feature model configuration problems, Proceedings of the 13th International Software Product Line Conference, San Francisco, California, August 2009. pp.11-20.

PT

[19] EilaNiemelä ,TuomasIhme, Product line software engineering of embedded systems, Proceedings of the symposium on Software reusability: putting software reuse in context, 2001. pp.118-125.

Toronto, Ontario, Canada , May

RI

[20] EilaNiemelä ,TuomasIhme, Product line software engineering of embedded systems, Proceedings of the symposium on Software reusability: putting software reuse in context,

SC

2001. pp.118-125.

Toronto, Ontario, Canada , May

[21] Uzma Afzal and Tariq Mahmood, “Artificial Intelligence to Solve the Problem of Software Product

AC CE P

TE

D

MA

NU

Line Management”, Sindh University Research Journal, Vol. 45, No. A-1, March 2013

27

ACCEPTED MANUSCRIPT

Research Highlights Context-aware classification methodology for Enterprise Resource Planning (ERP) Semantics for ERP interactions regarding requirements of different stakeholders Contextual requirement validity by comparing requirement model of the users with ERP

 

Decision trees to predict successful consignment deliveries for a local oil company Decision trees to predict conflict-free feature models for configuring oil products

AC CE P

TE

D

MA

NU

SC

RI

PT

  

28