An ERP Implementation Method : Studying a Pharmaceutical Company

Analysing the development process for an ERP solution, in our case SAP, is one of the most critical processes in implementing standard software packages. Modelling of the proposed system can facilitate the development of enterprise systems not from scratch but through use of predefined parts who represents the best knowledge captured from numerous case studies. This aim at abstracting the specification of the required information system as well as modelling the process towards this goal. Modelling plays a central role in the organisation of the information systems development process and the information systems community has developed a large number of conceptual models, systems of concepts, for representing conceptual schemata. In the area of ERP systems, because of the characteristics that distinguishes them, conceptual modelling can help in all aspects of the development process, from goal elicitation to reuse of the captured knowledge, through the use of the appropriate modelling schemata. SAP offers a standardised software solution, thus making easier the alignment of SAP requirements to enterprise requirements in a goal form, and the correspondent business processes.


Introduction
ERP systems provide a software solution comprising several interconnected modules covering most of the key functions. For example, SAP has modules for humanresource, material logistics, treasury, etc. This paper proposes a framework for the treatment of goal acquisition, alignment and reuse within the enterprise in order to facilitate the use of SAP. In the following section the ontology of the Reusable Organizational Change (ROC) framework is presented through the case of Electro Tech.
"Electro Tech is a fictional company, created from the collection of a variety of true-life business practices" [7]. It is manufacturer of electrical components and factory automation products. It has been in the business since late 50s and has demonstrated a consistent growth during 60s, 70s and 80s. The problems it faces are not unique but typical of a company who come across, IT evolution, globalization, integration, mergers etc.

Ontology of the Methodology
The ROC framework consists of four (4) static affinities, namely: (1) Organizational Goals (2) Business Process Models (3) Project Deliverables (4) Requirement Reuse Plan. The elicitation phase of the framework includes the determination of the high-level objectives of the enterprise as well as the more functional one. Product of this phase is the goal-graph notation (see figure 3).
In the second stage the outcome is the Petri-net notation of the As-Is state. In the third stage we can see the alignment of the processes of both SAP and enterprise. In this stage we have a more concrete idea of what to expect from the project itself. Product of this stage is the Petri-net notation (The To-Be state).
Finally, the Reuse Evaluation phase stores the knowledge captured during the project implementation process for future use. Especially stores the strategy followed during the third phase of the framework so that we use this knowledge in possible similar forthcoming projects.

Goal Elicitation Sub-model
The goal-elicitation sub-model is illustrated in figure 2. Central to this view is the concept of organizational goal. An organizational goal is a desired state of affairs that needs to be attained. Typical goals in the case of Electro Tech are: "improve IS services" or "Automate payroll" or "satisfy customer need for information from their suppliers" etc. Goals are pertained to stakeholders. A stakeholder is defined as someone who has an interest in the system design and usage. Examples of stakeholders are: managers, system designers, system users, customers etc.
Systems are built to primarily satisfy organizational needs. These needs may either be long term strategic needs or more immediate operational needs. These two needs support each other and are often more detailed in a goal hierarchy. We must distinguish between goals and needs. Goals derived from needs which are expressed in a more abstract manner. For example, "need for information" is a general organizational need for Electro Tech. From this need derived the goal "automate payroll" and "satisfy customer need for information from suppliers" System objectives are elicited from organizational needs and are determined by stakeholders. For example, the objective: "supply with the latest technology" is an objective of the system determined by stakeholders, probably management but depends on organizational needs for leading edge technology. Operational needs lead to the formulation of operational goals and strategic needs to the formulation of strategic goals. For example, "Buy a VP of sales and marketing state of the art system" is a strategic goal whereas "Buy a VP of sales and marketing system using lotus 1-2-3" is an operational one.
The requirements of the system are generated from system objectives because high level goals are too vague to be called requirements. Requirements must be more specific to proceed further.
In figure 3 we have an example of the elicitation of the enterprise goals in a notation as it has been used from [13]. We start from the high-level objectives of the enterprise such as "need for information" and we end with the low-level objectives, more concrete goals such as "automate payroll", "automate invoicing" and "update inventory". These goals could lead as it has been stated before into operational goals such as "Buy a VP of sales and marketing system using lotus 1-2-3". This goal graph depicts mainly the strategic goals derived from strategic needs. The realization of these goals comes from the process "implement an ERP package" in our case SAP. If we proceed further than the strategic goals, we have the elicitation of the operational goals. The operational

Specification of the Business Processes Sub-model
The specification sub-model is illustrated in figure 4. Central to this meta-model are the change goals. Change goals are elicited from current organizational goals and with the help of Business Process Models.
Organizational needs lead to change requirements. For example, the "need for an integrated IS because of very diverse citation" leads to the change requirement "improve MIS services". That means that we model the business process then the goals are derived from the models and are specified in Petri-nets notation. A current organizational goal can be "satisfy customer need for information from suppliers" and a change goal "develop a homegrown IS".

Validation Sub-model
In this stage it is being examined if the business objectives can be fulfilled and what changes must be made in the business processes of the enterprise in order to realize these. This is an interactive process that transforms the enterprise's business requirements into a future SAP solution. This interactive process provides continuous feedback mechanisms that initially identify gaps and then evolve to filling the gaps.
Installations of ERP systems are difficult to align to specific requirements of the enterprise because of the low level at which functionality is described. Central to this metamodel is the compliance procedure. The following terms are defined: SAP goals: The tasks carried out by an SAP function. SAP process: The process who realizes an SAP goal. SAP strategy: The combination of all necessary SAP processes, in order to reach an SAP goal.
The main reason for thinking in terms of goals (intentional level) and strategies (Strategy level) is that we need a common way of communication between SAP and enterprise. Organizations think in terms of their objectives and their strategies and SAP functions have a supportive role. SAP goals must support and implement enterprise goals.

Reuse Evaluation
The purpose is to reduce significantly the task of creating application-specific models and systems: the user select relevant parts of the reference model, adapts them to the problem at hand, and configures an overall solution from these adapted parts. Since the analysis of a domain can take an enormous effort when started from scratch, the use of reference models has been reported to save up to 80% in development costs for systems in standardized domains [19]. According to Ramesh and Jarke [17] reference models have become highly successful in many industries and among the best-known examples is the SAP approach. Each case can be considering a scenario S. The retrieval of a scenario S can follow the algorithm [

Aligning ERP to Enterprise
In this section we examine and model in more detail the stage between (1) elicitation and (3) validation of the framework whereas the alignment of both SAP and enterprise processes takes place and the most vital work is being done. We study the current state of the enterprise (As-Is) and then we study the desired state (To-Be) of the proposed SAP solution. Both states are representing in Petri-nets, a modelling element where the correspondent strategy for each transition is the key feature for the alignment.

Logical Organization
The levels of abstraction are ( Figure 6):  The Strategy level defines concepts such as SAP strategy or enterprise strategy.
The Operational level includes concepts such as SAP processes or enterprise process, namely the process that realizes the enterprise goals.
So, we have alignment of the processes in a strategy level, expressed in Petri-nets and the SAP goals support enterprise's high-level objectives.

Modelling the Current State
Petri-nets [16] are to model the current state of the enterprise, in our case Electro Tech. The production planning module (PP) of SAP is used as an example. The PP module is a flexible module containing several alternative strategies adjusted to each particular enterprise according to its objective and the targeted process the stakeholders want to implement. Because of the modularity which distinguishes SAP the Petri-net notation is a particularly suitable modeling tool for ERP systems in our case SAP.
Each node in the Petri-net notation corresponds to a state in the production planning process. Using the triplet form <source state, target state, strategy> we can have the correspondent textual notation for the transmission from a node to another node. This graphical notation used to represent the correspondent fragments of the SAP production planning process, having same milestones but probably different strategy can be used for adjusting the SAP planning strategy into the targeted enterprise process. The current status of the enterprise as it is described is [7]: (a) There is a serious problem in the control of approve vendors which is fragmented and controlled manually. The manual purchasing system can cause errors at the first place and at the second, there is no history option or any possibility for anticipation. As a result, the Sales and Operations plan is created manually.
(b) There is no demand management strategy in the supply of raw material. That means no forecasting strategy within the supply chain.
(c) There is no real time production planning strategy. That means need for production in advance and application of a stock strategy. (Make-to-Stock strategy).
(d) Lack of an on-line order processing system even automated.
As it comes up from the previous conclusions the identified problems are fall into two categories: 1. Supply Chain Management problems, for example (a) and (b), 2. Demand Side problems, for example © and (d). I0: start, I1: support material, I2: work with material, I3: Stock. Figure 7. The Current Status of Electro Tech.
Using the notation described previously we can depict all the above making thus possible the comparison or better the adjustment of the future SAP solution into business processes of the enterprise (figure 7) Each fragment of the above representation corresponds to a business situation, illustrating the problems stated. We use the triplet form <source state, target state, strategy> to represent the transition from one place to another place, and the strategy element depicts how this is being done.
In a few words we can describe the functionality of the company as: PF 1 :<(start), (support material), manual strategy>: Production scheduling is reacting to the occurrences in the plant. All planning strategy is based on word-of-mouth. PF 2 :< (support material), (work with material), not demand management strategy>: As commonly defined, demand management is the function of recognizing all demands for a product, including forecasts, customer orders, interplant orders, etc. The output of demand management is referred to as the demand program. It consists of a list of independent requirements for each material specifying the quantities and dates the material is needed. Multiple versions of the planned independent requirements can be useful for segregating and managing different components of demand. In Electro Tech the sales demand is composed of direct sales and warranty replacement. The warranty replacement demand is calculated manually based on reliability data and total number of units in service. PF 3 :< (work with material), (stock), not real time production planning strategy>: As a result of the previous problems there are delays in the production process of Electro Tech. Especially when a company has several plants depended one to another as far as the production process is concerned. PF 4 :<(stock), exit, manual order processing strategy>: What is really needed is a truly integrated system, without redundancy and with real-time transactional integration between business functions.
The correspondence between the identified problems and the process fragments is as illustrated in Figure 8:

Modelling the Proposed System
In the same manner we modeled the current state of the enterprise we model the future SAP solution (Figure 9). Because we are referred to Production Planning process and the Production Planning module of SAP is a highly flexible module consisting of several implementation strategies, we must select an appropriate implementation strategy for the particular company. It is difficult to present a general overview of the SAP production planning process. The production planning functionality is a highly flexible collection of sub-modules and functionality that can be linked together to form a coherent planning and scheduling process. Every SAP implementation has the opportunity to use all or a part of the SAP planning functionality in order to meet organization's specific planning needs [9]. Figure 10 depicts an example of how the functional submodules or according to our determination components can be used in order the specific planning needs of the company to be fulfilled. In this example the sales representative creates sales plan in the sales and operations component. These sales plans are then copied into Demand Management by the master production scheduler and smoothed out from weekly basis into daily basis. Once the master plan (in Demand Management) is satisfactory, master production scheduling is performed, followed by detailed material requirements planning. Figure 10. Sample SAP production planning process [7].
The detailed material requirements are fed into the capacity planning system for finite production scheduling and dispatching.
This process would be applicable for a company that has accurate sales forecast information based on sales account representative feedback from customers, or some form of accurate market predictors. The production environment would typically be a job shop with relatively expensive finished goods being produced in a complex manufacturing and assembly process.
For Electro Tech we selected a make-to-stock strategy consisting of the Sales and Operations component, Master Processing Scheduling, Material Requirements Planning (MRP), Quality Management (QM), and Product Costing (PC) component. The representation in Petri-nets of the above module is the one in figure 9 whereas I 0 : start, I 1 : support material, I 2 : work with material, I 3 : Stock.
The business process in SAP concerning the PP module with the above planning strategy has the following fragments: PF 1 <(start), (Support material), planning strategy> PF 2 < (Support material), (work with material), backward strategy> PF 3 < (Support material), ( Each of the above fragments treats a specific problem of the enterprise. For example, the fragments PF1, PF2, PF3, PF4, PF5 resolve problems related to supply chain, whereas the fragments PF6, PF7, PF8 resolve problems related to demand side of the enterprise. The adjustment of the components of the Production Planning module of SAP has been done in such a manner so that to implement the selected planning strategy.
Diagrammatically this can be proved as it is depicted below.

Study
We have seen so far, the methodology and the ontology of the ROC framework for assisting mainly the alignment of the enterprise requirements to SAP requirements and the reuse of the captured knowledge. This section presents the empirical results and observations from applying the above framework in an industrial application capture from the literature.
The intention of this discussion is twofold: The first is to assess the applicability of the ROC framework on a nontrivial application. The second is to discuss a number of challenging issues that need to be addressed in order the proposed Framework to support real, complex tasks in the context of business modelling and reuse within the ERP domain and particularly SAP.
The application considered is that of the implementation of SAP R/3 in a large pharmaceutical company. "This case highlights initial mistakes during this journey, strategies that helped overcome these mistakes, and how R/3 delivered operational efficiencies and competitive advantage under difficult business circumstances." [2].
We concentrate in the production planning module of SAP and thus we study the reengineering of the manufacturing process of the company. The considered case study was selected because it represents a unique real industrial application. The company is a typical example of today's multinational companies that went through acquisitions and mergers to reach today's status.
Following the application process of the ROC framework, firstly we consider the goals of the company as they stated from the stakeholders. A goal graph is created depicted the targets of the company and their abstraction from intentional features to operational ones.

Application Background
Geneva pharmaceuticals, Inc. is one of the largest generic drug manufacturers and the North American hub for the generic drugs division of Swiss pharmaceutical and life sciences company Novartis International AG. Geneva's primary business processes are manufacturing and distribution. Its manufacturing process is scientific, controlled, and highly precise. Until 1996, Geneva's information systems consisted of multiple software programs for managing mission-critical functions such as procurement, manufacturing planning, accounting, and sales. The systems infrastructure was predominantly oriented around IBM's technologies. The primary hardware platform was a mid-range IBM AS/400. The software platform was based primarily on IBM's DB/2 database. Desktop microcomputers were connected to the AS/400 via a token-ring local area network.
Business units funded and deployed applications as needed in an ad hoc manner, without concern for maintenance or enterprise-wide interoperability. Data shared across business units (e.g., accounts receivable data was used by both order management and financial accounting, customer demand was used both in sales and manufacturing) were double booked and re-keyed manually. The above configuration led to data entry errors, error processing costs and data inconsistency. Furthermore, the above status did not support value-added processes that cut across the enterprise, for example end-toend supply chain management. It was apparent that a common, integrated company-wide solution was needed to improve data accuracy and consistency, reduce maintenance costs and enable value-added processes. The acquisition of the enterprise goals is illustrated in figure 10. The main objective of the company is twofold: growth via acquisition thus balancing manufacturing and purchasing, and internal growth through the reduce of operational cost.
Goals carried out by SAP functions are supportive to highlevel enterprise goals or more specific are sub-goals of the high-level enterprise goals. The alignment of the SAP processes to enterprise processes is being done according to ROC framework in a strategy level carried out in Petri-nets.
The alignment in this case is being done from the SAP side towards the goals of the enterprise. For example, we don't have the implementation of SAP modules as a unity but the adjustment of different SAP components to targeted business processes of the enterprise (figure 13).

Demand Side Implementation
The main target of demand side implementation was to redesign demand side processes such as marketing and sales, order fulfillment, customer service, accounts receivable, and implementing the reengineered processes using SAP. As it is depicted from Figure 2 two components of PP module are implemented as far as the order management process of the enterprise is concerned. These are demand management and MPS/MRP (Master Production Scheduling/Materials Requirements Planning). Moreover, they are implemented inventory management from MM (Material Management) module and Financing and control. The current situation of the enterprise will be as follows: The states are the following: I 0 : Customer inquiry, I 1 : Order generation, I 2 : Goods issue, I 3 : Goods delivery, I 4 : Billing.
The main problems identified as they are extracted from the representation of the current status of the enterprise are: Before the initiation of the SAP project there were not forecasting strategy for all the customers. The only existed forecasting strategy was concerning key customers accounts. In the whole process there was a shortage of data integration and real time access capabilities. Prior to SAP orders were coming once a night, chargebacks were coming once a day, invoicing was done overnight, shipments were getting posted once a day.
The SAP process for order management is the following: Whereas I 0 : Customer inquiry, I 1 : Order generation, I 2 : Goods issue, I 3 : Goods delivery, I 4 : Billing.
The alignment of these two processes for order management generates the targeted process of figure 13. This representation in Petri-nets helps us to distinguish which components should be implemented. This representation is a high-level one, but we could go in a lower level through refinement.
The alignment will be done in the triplet form < (source state), (target state), (strategy)>.
The process fragments of the enterprise are the following ( Figure 14 Each from the above process fragments of SAP corresponds to a component (Table 1). From the comparison of the above process fragments we are coming into the following conclusions: PF 1 : The demand management module includes materials forecast so if demand management sub-module be implemented then the order management process of the enterprise will have the possibility to forecast requirements. PF 2 : With MPS and MRP components we can have interactive planning and date and time scheduling. PF 3 : With inventory management material stocks are recorded in the system according to both quantity and value with receipts and withdrawals, returns, transfers, and goods reservations being implemented. Inventory management is characterized by real time recording which enables checking and correction in the material flow [9]. PF 4 : Finance and control offers data integration with sales, distribution and accounting so the enterprise can have accurate accounts.
Following the alignment process, we know what to implement. We could have proceeded into a lower level through refinement. For example, the MPS/MRP component could be ( Figure 16): Figure 16. Refinement of MRP sub-module.
The planning strategy within MRP can be either deterministic or consumption based. In deterministic planning it is possible to decide whether and how materials are to be planned. Consumption based planning is based on a series of consumption values and is used together with forecast to plan future consumption.
The above could be proceeded further down. But because of the low level into which SAP functionality is described we remain into a higher level and thus the comparison is carried out with the models of figure 14 and figure 15.

Integrating Supply and Demand
Enterprise quest for integrating supply and demand was an old one and it began with its supply chain management initiative. The main goal is to implement "just-in-time" production scheduling, by dynamically updating manufacturing capacity and scheduling in response to continuously changing customer demands (both planned and unanticipated). The targeted processes are manufacturing resource planning (MRP-II), and more specifically, the Sales and Operations Planning (SOP) process within MRP-II.
The classic MRP-II integrates all business-related and logistics components. MRP-II takes into consideration all activities connected with the output of goods and services. It includes the following planning levels [3]: 1. Business Planning (operating results planning) 2. Sales and Operation Planning 3. Master Production Scheduling

Material Requirements Planning 5. Shop Floor Control
The starting point of the MRP-II planning chain is business planning, which usually turns production planning figures into money. The goal of sales and operation planning is to specify a production plan on the product group level (aggregate level). Using the aggregate production plan data, master production scheduling specifies the quantities to be produced of specific items in detail. Using data from the production plan, the MRP run produces either order proposals or direct vendor schedule releases. The shop floor control not only supports the creation and release, but also the monitoring of production orders.
Sales and Operations Planning is linking planning activities in upstream (manufacturing) and downstream (sales) operations.
In Petri-nets the sales and operations planning process of the enterprise (not the Sales and Operations component of SAP) will be: Prior to SAP, enterprise sales and operations planning were manual. In this approach, after the financial close of each month, sales planning and forecast data were aggregated from order entry and forecasting systems, validated, and manually keyed into master scheduling and production planning systems. In the same manner production and inventory data from the prior period were entered into order management systems. Two separate teams of demand analysts and supply planners were performing independent analysis and the results who could be different, were reconciled to determine the target production and target sales. Once an agreement was reached, in a business planning meeting senior executive were analyzing the final production plan and demand schedule based on business assumptions, financial goals and other strategic parameters.
While the manual SOP process was a major improvement compared to pre-SOP era, it was time consuming and error pruned in data re-entry and validation across sales production and financial systems. Furthermore, the whole process took one month and it was not sensitive into changes and customer requests less than the period of one month. For example, once the plan for sales and production was issued, any additional request from any customer was considered after one month, when the new plan was issued.
The corresponding Sales and Operation process with SAP is: Figure 19. Sales  In the same manner as in the previous section, we distinguish the process fragments of both models represented in figure 17 and figure 19: Enterprise: PF 1 < (order entry), (requirements), (planning strategy)> PF 2 <(requirements), (requirements plan), (aggregation strategy)> PF 3 < (requirements plan), (proposed plan), (not integration strategy)> PF 4 < (proposed plan), (final plan), (business planning strategy)> SAP: PF 1 < (order entry), (requirements), (forecasting strategy)> PF 2 <(requirements), (requirements plan), (supply planning strategy)> PF 3 < (requirements plan), (proposed plan), (integration strategy)> PF 4 < (proposed plan), (final plan), (business planning strategy)> The conclusions from the above comparison are: PF 1 : The planning strategy prior to SAP is mainly manual carried out by a number of meetings. In the case of SAP is fully automated carried out for example from the forecasting component of APO.
PF 2 : Requirements prior to SAP were aggregated from order entry and forecasting systems and they were fed into production planning systems. In the case of SAP plans and schedules are derived live from status data, collected live from the system. PF 3 : Integration of supply and demand data was not realtime. Data were located in different databases. SAP supports real time integration of supply and demand data. For example, SAP APO uses SAP Live Cache technology which processes data objects that are located in the memory. PF 4 : Business planning in the pre-SAP era carried out in a meeting from the senior management and it lasted one day. This lack business intelligence is fulfilled by the combination of SOP component together with the ATP component. Available to Promise (ATP) component can provide customers with accurate dates for complete or partial order fills.
The correspondence between process fragments of Figure  17, Figure 19 and SAP components is:
The above notation explains what is described in the Petri-nets of figure 20. Accordingly, PF 2 could be refined as:

Conclusion
In this paper we have seen so far, the ontology of the proposed methodology applied into a Pharmaceutical Company. The modeling of the current state of the enterprise and the proposed SAP solution is in Petri-nets, giving us the opportunity to represent the planning strategy from one state to another.
The levels of abstraction in each phase are three namely intentional, strategical, and operational. We think in terms of goals because organizations think in terms of their objectives [18] and not in terms of their processes and functions. Supplementary to this we take into consideration the correspondent strategy in order to align the business processes of SAP to these of the enterprise.
SAP goals are supportive to enterprise goals, and are used to implement enterprise high level objectives such as increase of the profit, which is an objective of every commercial organization, as well as, improvement of the customer satisfaction, improvement of the quality of service and as a result to this, consistent growth and increase of the market shares. Perhaps every commercial organization has to choose within a variety of computer systems solutions but when it chooses ERP and more specifically SAP, it must have the possibility of gaining the most out of this choice.
ERP systems are often large systems, of many interacting components. Each component interacts with other components within the system. Thus, despite the diversity of the systems we want to model, several common points stand out. These points are modularity and concurrency. Modularity because systems consisting of separate interacting components. Each component may be itself a system and its behavior can be described independently from other components, apart from well-defined interactions. Concurrency because activities of one component of a system may occur simultaneously with other activities of other components.
The conclusions are summarized in the following: (1) Firstly, the way of approach in a real project. SAP is not being developed as a unity, but we have a targeted process. An adjustment in a targeted process is being done and all the necessary components are implemented. In the case of the demand side implementation only one component from the PP module was implemented. So, the intention is not to develop SAP itself, but to adjust all its necessary components to facilitate the implementation of a targeted process.
The above conclusions can be represented in a metamodel, the SAP implementation method metamodel.
Central to this metamodel is the SAP Implementation method entity. This is depended upon the targeted process which every SAP project realizes and the enterprise type. By the type we mean the nature of the enterprise and therefore the appropriate SAP project type. For example, the enterprise can be located in a single plant or distributed within differently located plants possibly even to alternate continents.
The enterprise is ruled by the stakeholders who determine enterprise goals. On the other hand, supportive to enterprise goals are SAP goals. These are realized by the SAP functions. Finally, SAP structure is depicted by the presence of the entity's module and functions. (2) Secondly the applicability of the framework is satisfactory. We have a very good representation of the current situation of the enterprise as well as the future's solution with SAP. The comparison or better the alignment (validation phase) is carried out in a high strategy level but we can proceed further down in a lower level through refinement. (3) Finally, a correspondence of the process fragments and components of SAP is carried out as a result of the proposed solution with SAP and the implementation aspects of the project.