ERP Implementation in Iran: (A Successful Experience in DGC)

World Academy of Science, Engineering and Technology - International Journal of Industrial and Manufacturing Engineering Vol:8, No:9, 2014 Rome, Italy

 Abstract—Nowadays, the amounts of companies which tend to have an Enterprise Resource Planning (ERP) application are increasing. Although ERP projects are expensive, time consuming, and complex, there are some successful experiences. These days, developing countries are striving to implement ERP projects successfully; however, there are many obstacles. Therefore, these projects would be failed or partially failed. This paper concerns the implementation of a successful ERP implementation, IFS, in Iran at Dana Geophysics Company (DGC). After a short review of ERP and ERP market in Iran, we propose a three phases deployment methodology (phase 1: Preparation and Business Process Management (BPM) phase 2: implementation and phase 3: testing, golive-1 (pilot) and golive-2 (final)). Then, we present five guidelines (Project Management, Change Management, Business Process Management (BPM), Training& Knowledge Management, and Technical Management), which were chose as work streams. In this case study we present lessons learned in Project management and Business process Management.

Keywords—Business Process Management, Critical Success Factors, ERP, Project Management.

I. INTRODUCTION

ODAY, the integration of companies’ business processes is, if not a necessity, a requirement linked to the reactivity imperative. Organizations ‘zeal to adopt integrated ERP systems is thus highly justified because these systems are believed to dramatically improve competitiveness. [1]. Enterprise Resource Planning (ERP) is a commodity, a product in the form of computer software and a key element of an infrastructure that delivers a solution to business. [2]. ERP systems are described as computer-based information systems designed to process an organization’s transactions and facilitate integrated and real-time planning, production and customer response [3]. These systems are designed to address the problem of fragmentation as they integrate and streamline internal processes by providing a suite of software modules that cover all functional areas of a business such as financial, project, supply chain management, human resource management, customer relationship management etc. [4]. ERP is not only an information technology (IT) solution, but also a strategic business solution [5].

As an IT solution, ERP system, if implemented fully across an entire enterprise, connects various components of the enterprise through a logical transmission and sharing of data it would enable companies to make decisions efficiently. As a strategic business solution, it will greatly improve integration across functional departments, emphasize on core business processes, and enhance overall competitiveness. In implementing an ERP solution, an organization can quickly upgrade its business processes to industry standards, taking advantage of the many years of business systems reengineering and integration experience of the major ERP vendors [6]. ERP implementation should be viewed as organizational transformation, not as a large IT project with a need to devote significant resources and energy to change management [7].

ERP implementation needs too many prerequisites top management commitment, an appropriate project management plan, skillful employee, and so on. Therefore, Implementing ERP system is a complex and time consuming project. [8] However, even under ideal circumstances, ERP implementation is fraught with formidable Challenges. It is said that about 70% of ERP implementations fail to deliver anticipated benefits [9] and three quarters of these projects are unsuccessful [10], [11]. Standish Group found that 90% of ERP implementations end up late or over budget [12] In some cases, the implementation time is extended indefinitely, which has negative consequences for both the companies and the morale of their employees [13], [14]. A lot of barriers have been found as Critical Failure Factors, inappropriate change management process, a fragile project management structure. To address and avoid these obstacles in organizations implementing ERP projects, a lot of researches have been conducted. Some of them present successful case studies and lessons learned acquired, others survey failure factors in a fail ERP project. Most of these researches devoted to developed countries rather than developing countries because only 10– 15% of global ERP sales belong to developing one. [15] Nevertheless, ERP projects are dramatically increasing in these countries [16] ERP projects are different in developing and developed countries because of many factors such as organizational culture, business processes etc. [17], [18]. 

Iran is a developing country which ERP market is raising so fast [19]. There is a little study which has investigated ERP case studies in Iran ERP market; besides major success or failure factors in these projects are vague. [20] Too many failures or success factors have been published by literature review or interview with project managers [21]. But there are little papers which depicts successful ERP project from beginning to the end and illustrate lessons learned in developing countries, especially Iran [22]. Subsequently, this paper is undertaken to explain a successful ERP implementation in the context of Iran and categorized the lessons learned which could be vital for any ERP implementation.  

In the following sections, Iran ERP market is reviewed. Then an ERP successful case study, DGC, is presented. Next, Implementation phases and project highlights are presented. Besides, key lessons learned which gathered during project are categorized and described. Finally, conclusions and implications for future research are highlighted.

II. IRAN ERP MARKET

ERP is a flourishing market in Iran. Based on a report that published in 2008, 42 vendors were active in Iran ERP market as a solution provider or implementer. 43% of these companies were agent of international and famous ERP providers and other ones were the local companies that have their own solutions [23]. The first group is vendors who present an international ERP application such as SAP, IFS, Logo Business Solutions, Dynamic, Mincom, Netsis Software, Oracle, SAGE, and 3i Info tech [20]. Although they are international and professional applications, they are not implemented in Iran as efficient as other countries because of some reasons such as: difference in organizational culture, inappropriate business processes and so on [24]. The second group is Iranian local solutions. There were more than 10 Iranian IS companies who claimed that their ERP systems in operates in the local language i.e. Persian. [5]. they can satisfy some Iranian companies’ requirements, however they have some fundamental problems. In general, Iranian developed ERP systems are designed based on the current status of organizations and not based on best practices in the industry or improved processes. Moreover, a majority of the ERP systems do not support operations and production management processes in manufacturing companies. In addition, most of the Iranian ERP systems merely support the inter-organizational processes and not intra-organizational interactions with customers and suppliers. The ERP systems also do not contain modules such as customer relationship management and supply chain management as well as inability to support the multi-languages and multi- currencies which are critical for the multinational and international companies in Iran. [25]

III. DANA GEOPHYSICS CASE STUDY

In this section, a case study conducted at DGC the implementation of ERP (IFS) is discussed. The case study starts with introducing the company and its background, presenting the company status before and after the implementation of IFS, and giving the detail methodology of the implementation of IFS in DGC. Also, lessons learned are categorized and presented.

A. Company Background

Dana Geophysics Company (DGC) is an Iranian company whose Head Office is located in Tehran, Iran. This company belongs to DANA holding, an important private company in Oil and Gas market in Iran, which his mission is to be involved in upstream sectors of Oil and Gas industry. DGC was established in 2003 with this mission “providing high standard services in geophysical seismic data acquisition, processing and interpretation for oil and gas exploration throughout IRAN and abroad”. DGC is a project based company therefore project management plays an active role in this company.

DGC main activities are Data Acquisition, Processing, and Interpretation. This company has done more than 20 Projects successfully. In 2012 DGC controlled about 80% of the market and lead the market in its field. It is major competitor is Oil Exploration Operations Company (OEOC) DGC should be agile to complete each project on time with appropriate cost, therefore integration between departments are quite necessary. Dana Holding, all branches are project base, planned to implement ERP to compete in this competitive market. After analyzing ERP applications IFS was chosen. In this time DGC has 4 data acquisition projects, Golestan, Nasr Abad, Bahar, and Bibi Hakime, also more than 5 processing and interpretation projects. Implementation of ERP, IFS, would help DGC to boost its processes and be an agile company, reducing the time delivery of goods, for example, which sometimes is a critical task in a project. An activity in a project could be stopped because lack of equipment. Says Mr. Daneshkhah, DGC CEO [42].

B. DGC Situations before ERP

DGC had used local systems, more than 30, before the project was started. These legacy systems were difficult to operate, maintain, and develop. Besides, lack of integration, for instance, between warehouses in sites and office in Tehran. Another problem was about data; DGC decided to run Knowledge Management (KM) but the problem was inadequate data and lack of flow of information. Integrity was missed between departments (for example, there was no data for Material Requisition (MR) in system and the relationship among this and Purchase Requisition or Purchase Order) and it had an adverse effect on decision-making process in DGC. These old, rigid, and not integrated systems could not help DGC to improve its business. Also, DGC is a project oriented company and project information is vital for company. (Cost control report, for instance, is one of them). Although DGC has a local cost control system, developed by DGC employee, it was not integrate to other departments and data accuracy was another problem. The last system developed in DGC was an Iranian ERP. It was used only in 2 modules, warehouse and financial, this system had following downsides.

• It has only 2 modules and could not support other functions such as procurement or project management.
• There was no integration between finance and warehouse
• Sites work offline, therefore data was not accurate
• It was a poor application in development

C. Scope of Implementation

The fundamental objective of the implementation of an ERP system at DGC was to be an agile organization, as well as integrity in all parts of organization. DGC tended to improve its supply chain management SCM) In particular, warehouses situation, each project has more than 5 warehouses. For different Goods, inventory turnover was not clear, part numbers was not clearly categorized, and there was not any connection between project activities and warehouse receipt. Therefore the costs of projects were not clear. IFS was selected as an appropriate ERP application for DGC, after searching by a team of consultants.

TABLE I

DGC SCOPE OF PROJECT

IV. HIGHLIGHTS OF DGC IMPLEMENTATION

DGC adopted a Big bang approach to ERP implementation. This approach was quite risky because it encompassed all process at the same time [26], [27] this approach was selected in order to implement in all DGC environment (office at Tehran (pilot) and then 3 operational sites out of Tehran, Nasr Abad, Bahar, Bibi Hakimeh). There is a variety of methodologies and steps which could be a guide line for an ERP project. 

Accelerated SAP (ASAP), for instance, is a famous guideline for implementation created by SAP Company. Or some companies use PMBOK or other methodologies. Although all of them are helpful, it is vital to choose a guideline based on the company situations. Selecting implementation methodology and strategy plays an active role in this project [28] in the following we will explain the highlights of implementation approach.

A. Work Streams

DGC implementation team selected 5 significant elements to pursue in all steps of the project. These elements were compiled after literature review in academic and empirical studies, interview with ERP consultants in other projects in Iran. Project management, Change management, Business process management, Training and Knowledge management, and Technical management were defined in all phases of DGC project (Fig. 1).

 Fig. 1 DGC project work streams

B. Project Team

In the first step, project organization team was defined with roles and responsibilities. DANA Energy is a holding company, with 9 branches, in the field of oil and gas in Iran.

Dana Geophysics Company (DGC) is one of them. Besides Dana group recruited 15 IFS expert consultants to implement and support after Go live and create a consultant team for implementation. Also a new position called ERP coordinator was added to organizational chart and an expert coordinator was hired. The head of planning department was announced as project manager he should participate in the planning project activities and manage the execution of activities according to plan. He also was responsible for managing relationships with stakeholders. ERP coordinator was assigned to all modules implementation; he was learned IFS application from technical aspect as well as best practices processes. He also should be involved in each department activities to design process map.

“He plays an important role in this project, from 7 companies involved in IFS implementation only 2 have an ERP coordinator and the results have shown that they were more successful than other companies in implementation’’ says IFS top manager in holding. Another box is Project Management Office (PMO), responsible for planning, monitoring, and reporting activities during project. Change Management Team members were CEO, ERP Project Manager, Head of HR department, and ERP coordinator. Change management plan and strategy was made by this team. Training and KM activities was planned and monitored by this team. The last box was implementation team with a matrix structure. From each department a key user was assigned by the department manager this key user should be trained for his specific module as well as his routine activities. “DGC ERP team, established in the first phase of the project, was a critical factor for a successful implementation”. (Says DGC CEO)[42] (Fig. 2). 

 Fig. 2 DGC IFS project team

V. THE MAJOR PHASES OF IMPLEMENTATION

This project started in12 October 2012 and ended in16 March 2014, Go Live-2 (final) phase was 2days before due date (Fig. 3). In DGC, this project was planned in 3phases, each phase includes of some steps and deliverables which considered in organizational levels, top management, business, and operation. 

 Fig. 3 DGC IFS project schedule

A. Phase 1

It consists of 2 main steps the first one is preparation. In this step DGC established organization project team, roles and responsibilities .the scope of project was defined and master schedule was planned. Also DGC strategy team set ERP strategies and objectives also DGC strategies were aligned with ERP strategies. Besides, the necessary infrastructures and best business practices were analyzed.

The DGC processes were evaluated for 2 reasons first, to find which processes should be modified and second to scheme DGC process map. In step 2, Business Process Management (BPM), steering committee had 2options1- change current processes and use IFS best practices 2- customizing the IFS application. The second option was chosen but some enhancement going to be done after Go live, in the second wave implementation

B. Phase 2: Implementation

It is the most important phase during project. IFS application is configured and tested in some steps. First the base line configuration was performed, tested, and approved. All development such as enterprise services, interfaces, data conversion programs, reports, and any required enhancements were built The production system is installed during realization. Besides detail schedule was made.

C. Phase 3

The final phase had 3 steps. Before Go Live all systems should work correctly, therefore, they were tested in TEMP server, there was three different servers Train, it was used to train and was sand box, TEMP, to test and confirm processes, developments, reports and so on, PROD, production server to be used after Go Live. At the end of this phase the team had to be sure there is no problem to Go Live. Detailed cut over plan was made. There was a critical obstacle; DGC office was in Tehran, Capital of Iran, and there was no problem for having IT infrastructure or recruiting capable employee, to work with IFS, but DGC had 3 projects NASR ABAD, in a desert area, Bibi Hakime, in a mountain area whit 150 KM distance from nearest city, and Bahar, in a mountain area whit 80 KM distance from nearest city, therefore there was not appropriate infrastructure such as poor Internet connection, inappropriate PCs, also the competence employee who can work with IFS was a little. The implementation team was decided to first bring Go Live at office (pilot) and enhance infrastructures and recruit competence employee for projects simultaneously. After testing, the cut over plan was run at office successfully. All paper works subsidized by IFS application, Purchase Requisition, for instance, was one of them and all process was done in IFS i.e. doing authorization, making Purchase Order (P.O), and so on. After 2 months working. With this system some gaps were identified and the consultant team solved them. But there was a highlight spot in this project which had a great risk and could fail all the system. While bringing to Go Live step in DGC sites it was crucial to Go Live happened at the same time especially in warehouse and procurement. Because sites had transactions together, particular material for example might be sent from one site to another site. So there is an approved guideline. First the financial module was brought live, although other functions worked with previous systems. The financial system is the hearth of ERP so first the financial training was dome while financial opening was made (financial basic data) after these requirements was done the financial department in projects brought Go Live they had worked for 4 weeks before warehouse face the Go Live. In this time the financial problems were solved such as lack of training, lack of authorization or access and so on. Financial coordinator plays an active role in this phase. At the same time subcontract, sales contract and project management modules were brought Go Live. The last module was warehouse. Competence employee were hired, trained and settled in sites. The point is that the warehouse goods should be counted and transported at the same time in all sites besides no transactions should be done in the time between counting and data migration in IFS, there is a fact that the work in sites are ongoing and they need goods from warehouse. All circumstances concerned and following steps were made.

• The departments requirements were gathered one day before counting
• On the special day warehouses activities were freezed.
• All warehouses were counted( it was a demanding task more than 6000 goods and all employee worked nonstop)
• After counting the list of materials were sent to financial manager to appraised the prices
• The data migration was done from office
• The previous system (Rayvarz) was stopped
• Go Live (Fig. 3)

VI. RESULTS

ERP implementation success can also be viewed from many perspectives, however the more common ones are based on two variables namely, user satisfaction and organizational impact. In DGC we consider 2 different criteria to assess the success of IFS project. In terms of project management we consider time and scope management. At the beginning of the project a time schedule was made and tracked through the project. The Go Live phase was brought 2 days before the due date (16 March 2014). From scope criteria, all objectives were achieved (Table II). From another aspect, to assess the successful of IFS project, user satisfaction was chosen. Based on the survey conducted by DGC IT department 80% announced that they fell satisfy from working with IFS application. In conclusion, consist in time, scope, and user satisfaction we called DGC IFS project successful.

TABLE II

SCOPE OF MODULES

VII. LESSONS LEARNED FROM THE IMPLEMENTATION

‘‘A well planned and well executed ERP implementation, in conjunction with a good change management program, can create a dramatic turnaround for a company [29]. The successful implementation of IFS at DGC confirms this point. Some key lessons have been learned from this project. Lessons learned were gathered, analyzed, and categorized based on work streams.

A. Project Management

Many ERP analysts have underscored the importance of project management and planning for successful implementation [22]. Project management plays a significant role in every ERP projects [30]. It also has been known as a critical failure factor (CFF) in Iran ERP market [31]. Because of the importance of project management in DGC, project management procedures, such as scope plan, time plan, cost plan, and so on, had been created before IFS project started. 

B. Risk Management

One of the most important categories in project management is risk management. Risk management has been considered as a major critical success or failure factor in many academic and empirical papers [32]-[36]. The first lesson learned in DGC is: Risk management is a vital task in an ERP implementation project, especially in developing countries with turbulent circumstances. Risk management steps were done step by step by DGC PMO. The first step was to make a risk management plan. The risk management plan defines how risks are discovered, defined, assessed (during risk reviews), and managed. It also describes how often risk reviews are conducted.

Every week risk management meeting was hold with consultants, project manager, and key users from each department. Risks discovered and defined in these categories, project scope, schedule, budget, resources infrastructure, project management, change management, Business process, and technical. (Appendix 1)

C. Issue Management

ERP projects are complex and with a lot of conflicts between consultants, implementation team, and key users. Many researchers have been mentioned issues in their articles as an important part of an ERP project [33], [37]-[40]. Issues would be raised in this environment and could be barriers for the project. Therefore, they should be managed efficiently through the project. To address this problem In DGC project, an issue management plan was created. The second lesson is: issue management was a critical success factor in DGC ERP project. Issue management was done in 4 steps, issue planning, issue identification, issue handling, and issue monitoring, during the project. (Appendix 2)

D. Business Process Management

‘‘If a company rushes to install an enterprise system without first having a clear understanding of the business implications, the dream of integration can quickly turn into a nightmare’’. [23]

Business process orientation is a significant factor in an ERP project. DGC has been certified for IMS. Therefore, there was a processes orientation view in DGC.

1. Business Process Re-Engineering Strategy

DGC decided to implement IFS by replacing legacy systems. There were 2 problems. First, in some processes DGC needs a quick re-engineering but it is a time consuming task, therefore, they decided to revise current DGC business process map and then decided to do re-engineering in which processes another problems would be fixed in the second wave of implementation. The second problem was, DGC wanted to implement with the minimum amount of development, because high amount of development is a major critical failure factor .The forth important lesson learned is that business process re-engineering in developing countries which has not appropriate business process should not be done suddenly, it could be done in 2 steps, first wave and second wave

2. Business Process Map

A picture is worth a thousand words" while describing current organization process, called AS-IS, it is highly recommended to make a business process map. ASAP, a wellknown methodology for ERP implementation, mentions that the purpose of the business process map is to derive and agree on the scope for the start of the Business Process Management (BPM) phase. During BPM, the process map builds the foundation for the process hierarchy [41].

 Fig. 4 DGC process map (level 0)

The fifth lessons learned is the importance of making an accurate and up-to date business process map from organization, especially in developing countries which a huge gap could be found between AS-IS situation and TO-BE, best practices (Fig. 4).

VIII. CONCLUSION

DGC has a large and complex business process with tremendous projects which should be done one time, with appropriate cost. Although DGC was the leader of market in Iran, they should struggle hard to compete with competitors. Also, DGC has understood that accurate information systems and direct communication with suppliers are vital when offering customers a committed promise to deliver a project. DGC decided to boost its business drastically, a project more than only an IT project. ERP IFS 7.5 was chosen to be implemented in financial, inventory, procurement, project, contracts (sub contract and sales contract), HR, payroll, and document management. DGC top management has figured out that this project would be faced with a lot of obstacles. Therefore, an implementation team was gathered. Project’s progress was monitored by Mr. Daneshkhah, CEO [42], from the start of the project to the end. There is no doubt that this top management commitment plays a significant role in success of this project. DGC implementation was done in three phases. In the first phase, the preparation of project was planned the project management was a highlight in this phase. Project management plan, training strategy, business process management road map, and master project schedule was prepared in this step. Then Business Process Management (BPM) would start the current situation and the best practices were analyzed and the gaps between them were identified. In phase 2 main configurations was done by consultants, company and sites were established, basic data was gathered, authorization rules were allocated to managers, and functional training was started. In the third phase, all transactions were tested in TEMP server, cut over plan was created. Finally, DGC brought Go Live two days before due date.

Before starting the project, five work streams were gathered by DGC team, Project management, Change management, Business process management, Training and Knowledge management, and Technical management. These work streams were highlights.

Throughout IFS project and lessons learned were categorized based on them. In project management, risk management was defined as critical success factor. Risk management plan was made and risks were managed by this procedure. Also, issues management was another major critical factor in DGC. All issues gathered, analyzed, and ranked by their priority. Then for each one, consist in their property, a solution was defined. Business process reengineering is an inevitable part of ERP projects. An accurate business process map could accelerate this re-engineering. Training strategy was a guild line made by DGC IFS team to improve training throughout project. Three levels were defined whit specific steps. In level one, in preparation, an ERP, IFS, overview was presented. In level two, in BPM, best practice processes courses were hold.  

APPENDIX I

TABLE III

DGC RISK  

APPENDIX II

TABLE IV

DGC ISSUE LOG  

ACKNOWLEDGMENT

The author gratefully acknowledges supports from DGC CEO, Mr. Daneshkhah, and DGC IFS project manager, Mr. Ashayeri.

REFERENCES

• Al-Mashari, M., Al-Mudimigh, A. ERP implementation: Lessons from a case study. Information Technology &People 16 (1) 2003, 21–33.
• Klaus, M. Rosemann, and G. G. Gable, “What is ERP?” Information Systems Frontiers, Vol. 2, No. 2, 2000, pp.141–162.H. Poor, An Introduction to Signal Detection and Estimation. New York: SpringerVerlag, 1985, ch. 4.
• O’Leary, 2000. Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk, Cambridge University Press.
• Koch, D. Slater, E. Baatz, The ABCs of ERP, CIO, London, 2001.
• Shahin Dezdar, Sulaiman Ainin, ERP Implementation Success in Iran.
• Ifinedo, “Impacts of business vision, top management support, and external expertise on ERP success”, Business Process Management Journal, Vol. 14, No. 4, 2008, pp. 551-568.
• Al-Mashari, and M. Zairi, “Information and business process equality: The case of SAP R/3 implementation”, The Electronic Journal on Information Systems in Developing Countries, Vol. 2, No. 4, 2000, pp.1-15.
• Motwani, J., Mirchandani, D., Madan, M., Gunasekaran, A.,2002. Successful implementation of ERP projects: Evidence from two case studies. International Journal of Production Economics 75, 83–96.
• Al-Mashari, Constructs of process change management in ERP context: a focus on SAP R/3, in: Proceedings of the Sixth Americas Conference on Information Systems, Long Beach, CA, 2000.
• Kumar, B. Maheshwari, U. Kumar, An investigation of critical management issues in ERP implementation: emperical evidence from Canadian organizations, Technovation 23 (10) (2003) 793–808.
• Griffith, R. Zammuto, L. Amian- Smith, Why new technologies fail, Industrial Management (1999) 29–34.
• Hong, Y. Kim, The critical success factors for ERP implementation: an organizational fit perspective, Information & Management 40 (1) (2002) 25–40.
• Umble, E.J., Haft, R.R., Umble, M.M., 2003. Enterprise resource planning: Implementation procedures and critical success factors. European Journal of Operational Research 146, 241–257.
• Rajapakse,P.Seddon, Why ERP May not be Suitable for Organizations inDevelopingCountriesinAsia.WorkingPaperNo.121, Department of Information Systems, University of Melbourne, Melbourne, Available at:/www.pacis-net.org/file/2005/121.pdfS(accessed 28June2009),2005.
• ShahinDezdar, Sulaiman Ainin.. ERP Implementation Success in Iran, 2010.
• Molla, A. Bhalla, Business transformation through ERP: a case study of an Asian company, Journal of information technology case and application research 8 (1) (2006) 34–54.
• Soja, Difficulties in enterprise system implementation in emerging economies: insights from an exploratory study in Poland, Information Technology for Development 14 (1) (2008) 31–51.
• Huang, P. Palvia, ERP implementation issues in advanced and developing countries, Business Process Management Journal 7 (3) (2001) 276–284
• Nikookar, et al., Competitive advantage of enterprise resource planning vendors in Iran, Information Systems 35 (3) (2010) 271–277.
• Amin Amid, MortezaMoalagh, AhadZareRavasan, Identification and classification of ERP critical failure factors in Iranian industries, Information Systems 37 (2012) 227–237.
• Umble, R. Haft, M. Umble, Enterprise resource planning: implementation procedures and critical success factors, European Journal of Operational Research 146 (2) (2003) 241–257.
• W. T. Ngai, C. C. H. Law, and F. K. T. Wat, “Examining the critical success factors in the adoption of enterprise resource planning”, Computers in Industry, Vol. 59, No. 6, 2008, pp. 548-564.
• N. Taheri, H.T. Ardekani, H.K. Bagheri, Iran ERP Market

Characteristics, 195 (2008) 42–48 (In Persian).

• Amin Amid, Morteza Moalagh, AhadZare Ravasan,2011, Identification and classification of ERP critical failure factors in Iranian industries. Information Systems,37/227-237
• Nikookar, et al., Competitive advantage of enterprise resource planning vendors in Iran, Information Systems 35 (3) (2010) 271–277.
• Welti, N., 1999. Successful SAP R/3 Implementation: Practical Management of ERP Projects. Addison Wesley, Reading, MA.
• Davenport, T., 2000. Mission critical, realizing the promise of Enterprise Systems. Harvard Business School Press, Boston, A.
• Aladwani, A.M., 2001. Change management strategies for successful ERP implementation. Business Process Management Journal 7 (3), 266– 275.
• Davenport, T., 2000. Mission critical, Realizing the promise of Enterprise Systems. Harvard Business School Press, Boston, MA.
• Umble, M. Umble, Avoiding ERP implementation failure, Indus- trial Management 44 (1) (2002) 25–33.
• Davenport, T., 1998. Putting the Enterprise into the Enterprise System. Harvard Business Review 76 (July–August),121–131.
• Xue, et al., ERP implementation failures in China: case studies with implications for ERP vendors, International Journal of Production Economics 97 (3) (2005) 279–295.
• O.R. Kholeif, M. Abdel-Kader, M. Sherer, ERP customization failure: institutionalized accounting practices, power relations and market forces, Journal of Accounting & Organizational Change 3 (3) (2007) 250–269.
• Kouki, R. Pellerin, D. Poulin, An exploratory study of ERP assimilation in developing countries: the case of three Tunisian companies, in: Proceedings of the Third International Conference on Software Engineering Advances, 2008: IEEE.
• H. Tsai, et al., Investigation of ERP Implementation Problems in Organization Environment, 2009: IEEE.
• Noudoostbeni, N.M. Yasin, H.S. Jenatabadi, To investigate the success and failure factors of ERP implementation within Malaysian small and medium enterprises, in: Proceedings of the 2009 International Conference on Information Management and Engineering, 2009: IEEE.
• Barker, M.N. Frolick, ERP implementation failure: a case study, Information Systems Management 20 (4) (2003) 43–49.
• Al-Mashari, A. Al-Mudimigh, M. Zairi, Enterprise resource planning: a taxonomy of critical factors, European Journal of Operational Research 146 (2) (2003) 352–364.
• Al-Mashari, A. Al-Mudimigh, ERP implementation: lessons from a case study, Information Technology & People 16 (1) (2003) 21–33.
• Wickramasinghe, V. Gunawardena, Critical elements that dis- criminate between successful and unsuccessful ERP implementations in Sri Lanka, Journal of Enterprise Information Management 23 (4) (2010) 466–485.
• sap.com/ roadmaps/ASAP.
• Mohsen Daneshkhah, DGC CEO.

Mohammad Reza Ostad Ali Naghi Kashani

Computerized Maintenance Management Systems (CMMS) and Enterprise Asset Management (EAM) applications both touch the industrial maintenance space. One might say that the relationship between the two is rather like that between a square and a rectangle … every EAM application can be used as a CMMS, but not every CMMS can be used as, or has the broad functionality of, an EAM application. More specifically, CMMS is essentially about managing maintenance work necessary to sustain an asset, whereas EAM has more to do with managing the asset over its lifecycle to minimize cost and risk while maximizing return. But how exactly do CMMS applications and EAM applications drive value? How do you know if your company ought to implement one versus the other?

CMMS

CMMS tends to focus on the maintenance management. It can also extend into inventory management and other disciplines, but is most often implemented for and used by maintenance personnel.

CMMS may be thought of as a communications tool that allows us to communicate about maintenance activities in the same way, using the same words, every time. It provides documentation of that communication through work orders so essential maintenance activities do not get forgotten. CMMS systems are in fact designed to do a lot of other things for us; collecting material costs and labor costs and serving as a repository for all of our maintenance information.

There are definite problems that a CMMS, as that communication too, can solve. Without a work order process that is used for every job, we have no documentation of what our most problematic pieces of equipment are. But once a company implements a CMMS system and takes on the attitude that “the work order is king, and nothing happens without a work order,” that problem is solved. Complete visibility into what work is being performed on which pieces of equipment can help us achieve things like Preventive Maintenance (PM) and Predictive Maintenance (PDM), and can even help with the repair or replace decisions as problems become more recurrent and expensive to solve. But technicians can be resistant to the idea of recording any and all work in the CMMS. Why? Often, it is because they think the CMMS is being used to monitor their activities and ensure they are doing their jobs. A better way to think about the CMMS and work orders is that it is a way to prove maintenance value to the organization. In effect, anytime maintenance is doing work outside of the work order system, regardless of whether you are using CMMS or EAM, you are doing work for free. Every maintenance organization feels they are understaffed, but few are able to accurately document what their true work load is. If they could, it would help them identify the appropriate staffing level. Documenting and managing work is one way to look at CMMS. Documenting and managing equipment is another. Consider the problem faced by a company with a three shift operation, with every shift spending 20 minutes doing a quick repair on the same piece of equipment. If that quick 20 minute job is not being captured by a work order within the CMMS, you have is an invisible problem because communication from shift to shift isn’t taking place. What that means is that in a manufacturing environment, the line can be down 20 minutes every shift every day for years, which really amounts to 60 minutes per day, up to 365 days per year. That is a tremendous waste. CMMS can help identify and ultimately eliminate that waste, provided it is documented. Lost productivity is one problem a CMMS can solve. Another is undocumented use of maintenance inventory, including parts and consumables. Many medium to small organizations don’t man their store rooms, and so often, someone will grab a part with the intention of documenting what they took later. But many times, they fail to or forget to document what they used and where they used it. The inventory system thinks those items are still on the shelf, causing shortages (stock-outs) that can in turn lead to down time when a necessary part is not available. Through the reinforcement of processes, procedures, and documentation one can create a culture of discipline across a maintenance organization can be established. If the CMMS work order system in place enables standardized, repeatable, and sometimes predictable processes that could prevent work from being missed or forgotten, documents problems so they can be fixed and ensures the usage of labor and parts or materials utilized are recorded.

Many CMMS systems are in fact capable of facilitating much more than work orders and maintenance inventory management. But even though a CMMS offers more advanced functionality, it often goes unused since it is considered a “maintenance program”.

The difference Some may say that there is not a whole lot of difference between a CMMS and EAM. EAM certainly offers a broader spectrum of functionality. And the delineation between the two may be drawn at purchasing functionality. Most CMMS applications have purchasing functionality, but it is often not used. A company using a CMMS will often integrate it point-to-point with a purchasing system, or the two functions may be handled in entirely separate applications. On the other hand, EAM applications have extensive purchasing, planning and financial functionality that the application is to a certain extent built around. Many CMMS packages will also start to look kind of similar to an EAM application because they allow you to manage projects. Some CMMS applications even have a project module that integrates and uses work orders and builds parent-child work orders, all aimed at shut downs and other maintenance events. It could be that this functionality is not strong enough or it is just not something those running the CMMS are aware of. Because it seems the natural tendency is to use Microsoft Project, or Primavera, which means we induce problems by doing things outside of the work order system. Again CMMS is seen as having to do with work orders and maintenance, and a company choosing CMMS over EAM may not be looking for that additional functionality. The choice between CMMS and EAM can also be influenced by the size of the maintenance organization and where, within the company, the software decision is made. When a software project is driven by the maintenance department, they are typically selecting CMMS, because they are not normally directly involved in selecting more enterprise-level systems or applications. Furthermore, a small to medium sized maintenance organization with 75 or fewer maintenance technicians in the organization will typically migrate to a CMMS. Once you have more than 75 maintenance technicians, they tend to migrate to an EAM application. As a company has more maintenance technicians, human resources and other roles to integrate with the maintenance work force probably becomes more desirable. Moreover, a company whose entire operation centers to a large degree around maintaining, sustaining and operating assets will want technicians and even contractors working with them to be managed directly in and from their enterprise systems. To most organizations, that level of sophistication in a system is exotic. And what happens, unfortunately, is that many organizations implementing CMMS or EAM may be advised to look at a full cradle to grave asset lifecycle management approach. But they balk, insisting “We just want to concentrate on getting the assets in there and making sure our PMs are getting done.” So they really pass up an opportunity to select an application capable of broader asset management duties or even, if a more powerful application is selected, lay the requisite ground work during implementation to use the functionality. Most selection and implementation teams are under pressure to quickly get assets into the system and keep the PM program rolling. Once they accomplish that initial implementation goal, they never make time to go back in and do more to or with the system. So whoever is helping them implement must drive them to try and embrace all of the capabilities of that system. Typically CMMS applications may be used at only 50 percent or less of the total system capabilities. EAM is very much the same way. I think from the EAM side, it is considered more cost driven because there is a lot more asset information, there is a lot more work and people may say to themselves, “I don’t have the time, the money or the resources to do this fully. I will do it over time.” But they never get back in there and do it over time.

EAM

In contrast to CMMS, EAM is an enterprise-wide application that can function just like an enterprise resource planning (ERP) application for an asset-intensive business – from the general ledger through to purchasing and projects and engineering and individual work orders. Or, as is the case of IFS Applications, it can be implemented to include as much enterprise functionality as is required and integrated through application programming interfaces (APIs) with other enterprise systems.

EAM must address the entire asset lifecycle, extending from design through decommissioning. all of the asset data ... as designed, as built and as maintained, must be held in EAM as a central repository.

While CMMS is designed, in its purest form, to manage the maintenance work so as to improve asset reliability, EAM is designed to allow the executive level to maximize the productive value of the asset, which of course means they need full visibility into maintenance costs. At the same time, they need visibility into the cost to initially construct the asset, the cost of replacement or lifecycle extensions, the cost of maintenance contractors and of course the human costs associated with salaries, benefits, and more. They also need to evaluate risks presented by the asset, so asset integrity management and risk management is of critical importance particularly for companies where asset failure can result not only in lost productivity but safety breaches or environmental impacts. At a base level, EAM must deliver the core requirements not just of maintenance management, but asset management. Those requirements are spelled out in ISO 55000, ISO 55001 and ISO 55002. ISO 55000 includes an overview of asset management. ISO 55001 is a requirements specification for an integrated asset management system, and ISO 5502 offers guidance for implementation. While ISO 55000 does not specifically address software, it does require that all asset data, across the lifecycle of the asset and across organizational boundaries, be contained in the same database and therefore, the same system. What does that mean? It means EAM must support the planning and engineering stage of the asset, including plant design. It must encompass the construction of the asset, so powerful project, document and contract management functionality is required. And it must support operation of the asset and even eventual decommissioning and replacement. This is a demanding requirement that CMMS alone cannot likely meet, and frankly, neither can most EAM applications that may not address the entire asset lifecycle. And whether or not a company considers adopting the ISO standard, if they are committed to complete visibility and control over their assets, they still need that full lifecycle support. Only a single system like EAM can deliver an accurate and consistent view of all asset information—one version of the truth—insuring policies, plans, and actions are based on an accurate understanding of the history and current status of your asset infrastructure. In order to accomplish this, an EAM software product must actually address all phases of the asset lifecycle, and not many do. It must also provide portals or other methods for outside parties like engineering firms and maintenance contractors to use the system so that everyone touching that asset data is interacting with a single database in real time. And by everyone, we mean people inside and outside the company. An EAM application must offer the ability to open portals to suppliers like engineering firms and maintenance contractors. As you plan maintenance work for the weeks ahead, if your contractors have visibility of your plans through your EAM system, they can be informed of the upcoming work, schedule their people and ensure that they have the right tools and materials available. If they are seeing that rolling schedule, they can be more responsive to your needs. This also reduces the amount of time necessary to manage those outside contractors by phone and email. Moreover, if the contractor can report their work activities directly into your system, you are getting real-time updates of work completed. That eliminates the delay that results when the contractor enters the data in their own system, and the data flows through reporting mechanisms within that contractor environment and back to the manufacturing maintenance team, which then has to enter that record of work back into the EAM, enterprises resources planning (ERP) or computerized maintenance management (CMMS) software. That repeated entry is wasteful and increases the likelihood of mistakes. Real-time data can also allow for tighter coordination between the contractor and internal maintenance staff or with other contractors working on that asset. Moreover, that real time data could allow for more efficient use of the asset, as in the resumption of a production schedule immediately after a contractor finishes work.

Advanced project management Project management is of interest not just to the maintenance or plant manager who may want to manage a plant shutdown, but the CEO, CFO, board or other stakeholders who may want to manage the lifecycle of an asset as one long project— a project that might last for as long as 20 or more years. The asset lifecycle is really just a project that starts with engineering and construction processes. The project then comes to include the cost to maintain, operate and refit, and culminates with a well-informed decision to decommission and replace the asset. In the absence of fully functional, flexible and integrated EAM and ALM systems, managing the lifecycle of the asset from cradle to grave is a challenge. What this means to a software selection process is that the ability of an EAM package to support plant design and engineering ought to be a major factor. Even in the vast majority of instances when an outside engineering group is responsible for design, their activities ought to be encompassed by the EAM platform to be used during the asset lifecycle so that design data flows naturally into the maintenance and operations systems that will sustain the asset during its productive life. Tight integration between ALM, project management and core EAM functionality is also necessary. Consider for a moment the situation faced by the chief executive and maintenance director at a coal-fired power plant that has one stop per year for major overhauls. There is a pressing need to meet the project timeline because each day of downtime is worth millions of dollars, and there is a significant degree of project complexity as outside contractors are hired, equipment is rented and perhaps additional maintenance shifts are added. Robust project management functionality that is integrated on a very granular level with a powerful EAM application can help manage the resources necessary to complete the required tasks in the time allotted. While the ability to manage to meet the deadline is one strong argument for integrated project and EAM functionality, even greater benefit can be realized of project and EAM functionality are tied into an overarching asset lifecycle management (ALM) system and the general ledger. The ability to look at a plant shutdown from an ALM and financial perspective can help determine if it makes sense to bring in additional outside resources in order to shorten the amount of down-time. To what extent will the outside cost of hiring contractors and equipment increase total return on the asset in the intermediate to longer term? Many asset-intensive companies do not have in place the proper tools to efficiently optimize the activities associated with a plant shut down, and certainly do not have the right tools to proactively reduce planned downtime. But this effort to track the cost of operating and maintaining the asset is dependent on effective cost tracking on thousands of smaller projects. On this micro level, integrated project, finance and EAM functionality is critical. When working in a properly-integrated enterprise application, it is much easier to structure a maintenance project to collect all of the cost, including procurement and work orders that are used to collect technicians’ time. Integrated functionality will also allow analysis of project cost by different breakdown structures, and each activity a can be assigned a different funding line. So it becomes that the difference between EAM and CMMS has to do not only with the breadth of functionality, but the degree to which that broader functionality is designed to work together to deliver a unified asset management platform.

The desired future state While CMMS is designed to meet immediate maintenance management needs, EAM is designed to manage the future state of the asset, providing visibility into the past and driving predictability into the future. It is this ability to look into the future state of the asset that is affecting everything from lifecycle extensions to plant location decisions. In Brazil, we are seeing tremendous growth in the paper pulp industry. Why is this? Because executives can see that the productivity of an asset in that location is much higher and lower cost than one in a more northern clime. In Brazil, there are entire valleys that are completely empty of trees after a thorough harvesting. But just seven years later, that valley is home to a full grown forest—a forest growing in flat fields so when they come in with your harvesters, there are no natural barriers. That seven-year harvesting cycle versus the 150-year harvesting cycle common to a more northern clime has real asset lifecycle implications. The future state a company implementing EAM can aspire to can be a lot simpler than this though. They may aspire to lower cost by truly managing an extensive maintenance inventory in an intelligent way. Inventory management requires a unique master ID for part Identification in the asset intensive industry. This ID must be standardized, and IFS has been on the forefront of identifying a universal standard for parts, and within IFS Applications certainly standardizes part numbers across all facilities a company may operate. Why is this important from an EAM standpoint? Because it allows management to reduce the ongoing investment required to manage the asset. If you look at a multisite, asset-intensive industry, there might be 100,000 different parts or objects in that asset environment. You might have 50,000 different spare parts in your inventory and all of these are named in a very localized way. That is because the part naming convention was likely developed site by site over the decades, and the problem may be a lot worse if the company has grown by acquisition. Therefore, it is impossible to know that a motor in company A, called Alpha, is the same motor as company B is storing under the name Beta. With part enterprise part standardization, you can suddenly you can start to treat stock levels at different sites with a higher degree of transparency because you suddenly understand that this motor is stored in all of the five sites in your group. And the expected level that you need to have on the shelf is maybe 0.2 of this motor, which means you need to store at least one. But if you suddenly treat these five sites as one common unit with different inventory locations for this motor, you would in theory be able to store just one motor to service all five sites and you would still be able to ensure coverage.

Mobility

The futurist William Gibson was right … the future is here, but it is just not evenly distributed. Some companies have achieved part standardization. The technology is there, but the will to implement is not yet universal. This is also the case with enterprise mobility, which a modern enterprise asset management application can also facilitate. Mobility comes through EAM in different ways to different people in the enterprise. For the executive, an EAM system will be able to notify them on their smartphone or other mobile device when urgent documents need to be approved. Those working in an office or managerial environment will have full access to their EAM suite on touchscreen devices like tablets. And technicians will be able to use consumer-grade smartphones and other mobile devices to access and complete work orders. The technology is here, and forward-looking companies are taking advantage of it.

Sophisticated EAM solutions like ifs applications are driving more and more functionality into the mobile environment, all with complete visibility of ongoing activities by management.

Conclusion

EAM and CMMS are related, with CMMS being used to address immediate maintenance management needs and EAM extending across other enterprise functions. Companies operating large, expensive or mission critical assets with many maintenance technicians will do well by selecting and implementing EAM. A company with more immediate needs may want to implement CMMS, but perhaps opt for an application that can grow with them, expending in a modular and flexible way to deliver full-blown EAM.

In industrial maintenance, utilities and other asset-intensive industries, plant managers are telling maintenance managers they want them to implement the RCM (reliability-centered maintenance) processes they keep reading about in trade magazines. But many don’t really understand what RCM means or what level of organizational commitment and development are necessary to achieve it.

As a business consultant with IFS, the global enterprise software company, I get asked by customers all the time about implementing RCM. I make sure to tell them that while enterprise asset management (EAM) software can support the goal eventually implementing RCM philosophies and methodologies.

In order to explain how to gauge where a company’s maintenance program stands and where its goals need to ultimately lie, we need a term that is all encompassing of the total maintenance-management-process approach and ultimate goal. I call this Quintessential Asset Management (QAM). The word quintessential comes from ancient physics as the fifth element that holds the other four elements of earth, wind, air and fire together. Think of maintenance as the fifth element that brings and keeps a profitable asset-driven business together. In modern English, quintessential has come to mean the model that a concept strives to become.

In embarking on your QAM journey, the first questions to ask yourself are where is your company’s maintenance program today and where do you want to take it. An enterprise needs to establish a valid benchmark of where it stands, set realistic goals and then evaluate its progress honestly and openly at predetermined intervals.

In this white paper, we’ll outline the five levels of asset-management development a company usually passes through leading to more advanced processes such as RCM to eventually achieve QAM. In describing these levels of development, it makes sense to use terminology we can already relate to, so we will compare it to a familiar analog—human development.

Level one—Disruptive/reactive (infancy)

The first stage of development in asset management can be compared to infancy. At this stage, a company’s maintenance program is starting from ground zero.

There is literally no maintenance department. Things are breaking down; operations personnel are screaming and every breakdown or failure results in production being thrown into crisis mode.

Anyone who has had an infant in their home can relate to being in a disruptive/ reactive mode day and night. Substantial resources and attention are devoted to responding to the child’s every need, and although first-time parenting usually comes without training, machine repair should be left to trained professionals. Unqualified personnel often try to repair or rig the machinery to get a run completed. Companies at this stage of development also depend heavily on contractors, which although safer are expensive and usually not a replacement for on-site personnel. In-house technicians who see the equipment every day get a feel for why disruptions occur and can help prevent the problems from recurring.

I have worked in various support and managerial capacities for companies that did not have a maintenance department. Knowing my technical background, many times, I’d be sitting at my desk when someone would run in and ask me if I would get out on the floor and see if I might be able to help repair a machine and get production back up least we miss an important order. If this happens in your company, you definitely need to consider the benefits of having onsite maintenance personnel and the genesis of a structured maintenance program.

Level two—folders and spreadsheets (Childhood)

As an infant develops into and through childhood, they become self-sustaining. A company whose maintenance function is entering this stage of development will begin to hire their first maintenance employees. They might hire one or two technicians, and perhaps even have one of them spend time in an administrative function, creating a maintenance program that is usually calendar-based in a personal information manager (PIM) like Microsoft Outlook. So at this juncture, the technician(s) begin plotting calendar-driven maintenance activities based on equipment manufacturer’s recommendations. On a daily or weekly basis, they print off a checklist route from a spreadsheet. The work is divided up among the available technicians and saved in folders along with manuals, receipts for more significant parts or materials and notes for future reference.

Many companies only move to this level to appease some quality standard for their industry such as QS or ISO. Some companies stay at this level indefinitely, perhaps due to a prevailing notion that if a technician isn’t turning tools on a broken machine, he’s wasting time. More proactive planning and management are not seen as value added items. These are counter-productive attitudes and this is where it becomes advantageous to consider graduating the maintenance program to a more organized approach through implementation of a Computerized Maintenance Management System (CMMS) or EAM software.

Level three—Basic CMMs (Adolescence)

A human being at the adolescent stage of development has a lot of energy and ideas that need structure, documentation, and direction in order for them to develop into a productive, efficient adult. Wouldn’t it be great to have a tool to log a person’s accomplishments and mistakes in order to more effectively grow up? One of the most crucial steps in a company’s maintenance evolution is realizing the value of tracking asset history and having a more organized method for referencing previous causalities and issues other than a technician’s memory. (This also helps preserve hard earned knowledge when experience technicians retire or move on.) Similarly, a maintenance department reaching this level of development will want to take on more accountability for the contribution they are making to the company’s success, and will want to implement systems to help them achieve these ambitions.

It is at this point in a maintenance department’s development that a CMMS is typically implemented. There are a number of CMMS products on the market that are adequate for handling rudimentary maintenance needs, but most maintenance departments opt to begin with CMMS products that give them a good start yet restrict their ability to move into more advanced modalities of maintenance management down the line.

Like adolescents, companies often get caught up in the moment, and are distracted from long term goals by matters that will not concern them in the next month, much less in a year or more. This means that a company will need to ensure that the CMMS product selected is not focused solely on dealing with their present situation, but rather has the capacity to grow with them as your organization’s level of maturity and development continues to advance towards QAM and utilizing the tools of RCM.

Once they commit to implement a more systematic CMMS, organizations often tend to be short-sighted on two fronts:

• Selecting a CMMs that will only ever be a CMMs. There are a lot of CMMS products out there that do an adequate job of scheduling the work of maintenance workers and recording that work. But many of them are not part of an overall suite of applications that provide a pathway to RCM. Some application suites, including IFS Applications, do allow for basic CMMS functionality to be implemented so that additional, enterprise-wide functionality can be added later to allow for more advanced management techniques. Many CMMS tools also keep equipment structure in a flat file rather than a hierarchical, navigable structure.
• Shortcutting implementation. For many organizations rolling out their first CMMS solution, the cost of the software license is a big investment. They are hesitant to have the vendor or any other outside party help them with implementation. But the lack of experienced and qualified help with implementation may at the very least lengthen the implementation timeline, consuming exponentially more staff time. Trying to implement CMMS on your own can also result in a suboptimal instance of the software. Either one of these outcomes can cost you many times over what it takes to have professional help with implementation.

Along with CMMS implementation, this is a good time to introduce simple, less expensive conditional components such as oil sampling and Infrared thermography. A year into a CMMS project and with simple conditional checks, there should be enough information to start developing and harvesting KPIs and Trends.

Level 4—integrated CMMs or EAM (young Adulthood)

At this stage of development, a maintenance organization begins to seriously consider how its CMMS interfaces with other systems in the company, including enterprise resource planning (ERP), equipment monitoring and project management software. If a maintenance team is cutting purchase orders and doing material requisitions in an ERP system while doing double entry by also entering them in the CMMS, it’s time to invest in an integrated package or perhaps consider bidirectional interfaces between the two systems so that they modify the same set of data.

I’ve witnessed several companies that have elected to go from Level 2 (Folders and Spreadsheets) to Level 4 (Integrated CMMS) while implementing Enterprise Resource Planning (ERP) software like IFS that offers an Enterprise Asset Management (EAM) module—and they were quite successful. I see implementing an EAM that is integrated with the ERP’s financial, supply chain and human resource pieces akin to taking college credited courses in High School and skipping your senior year to get on with college and a career. This can save a lot of time and money given a planned and disciplined approach.

If a plant has a supervisory control and data acquisition (SCADA) system, it’s time to start considering a direct interface of data (hours, strokes, alarms). Pretty much all the monitoring programs and some CMMS products are compatible through OLE Process Control (OPC) interfacing. It makes sense to have remote sampling and real-time monitoring feed directly into the CMMS in order to cut back on the man-hours necessary to collect and enter data, and to avoid misreading that leads to junk data in the CMMS.

During the integrated CMMS phase, a maintenance organization can also look at integrating its maintenance software tools with project management software that can deliver equipment data directly into its CMMS. This is a huge step toward greater efficiency and the ability to manage assets over their entire lifecycle from engineering, installation, commissioning, operations, maintenance and straight through the decision to refit or replace. Machine installations, plant expansions and relocations all have asset-management relevance. The ability to manage the total cost, productivity and return on assets is only possible when early asset lifecycle stages including planning, engineering and construction are addressed in the enterprise application. This integrated approach allows for what is called asset lifecycle management (ALM)—which is a true cradle-to-grave management approach.

A condition based program can be incorporated into the maintenance program in order to garner value by doing less replacement before failure and requiring less preventative maintenance hours. We’ve discussed oil sampling and infrared thermography which can be relatively inexpensive. Some other prevalent types include; Vibration Monitoring & Analysis, Ultrasonic Noise Detection, and Non-Destructive Testing. These are all areas that require specific expertise and assessment on their potential value before implementing. A lot of people want their CMMS to do this specific data collection and analysis for them, but this is impractical. No software can do everything effectively and I’d question anyone who says they can. The CMMS just needs to have the ability to have the data attached to it. Let the specialist specialize where it makes sense and don’t fall into that “one size fits all” pit.

Once a maintenance organization has developed good basic practices outlines in this article, a definite RCM strategy should begin being developed. There are a lot of good vendors out there and this is another area where a qualified consultant should be brought in to help a dedicated maintenance team further develop their practices using RCM principles and procedures. It should be incorporated into the basic maintenance plan with defined evaluation periods and tangible benchmarks.

Level five—Quintessential Asset Management (Mature Adulthood)

At this stage, an organization has the requisite integrated applications, equipment history and processes in place, as well as the backbone of an RCM program. You have the data on hand to help decide what equipment is truly critical instead of making that determination based on simple tribal knowledge—which often turns out to be wrong. You will have dashboards and key performance indicators that put real time data at your fingertips. You can make repair/replace decisions quickly and easily. You can make “run-to-failure” decisions with more confidence.

The above progression is a model of how an asset-management program develops in a real-life situation. You can throw all the buzzwords you want at it, but it comes down to common sense and a plan that unfolds over a period of time. While the right technology is important, it is your organizational culture that will really separate the wheat from the chaff and determine if you actually develop a dynamic, productive maintenance program with build in RCM principles and methodologies. A company needs a vision of where it’s going and how to get there, other than a few rows and columns on a budget spreadsheet. The people, processes, dedication and discipline are what make a maintenance program successful. Software, monitoring equipment, reliability premises and performance indicators are just tools that automate, guide and gauge your success.

In the process of implementing an enterprise application suite like enterprise resources planning (ERP) or enterprise asset management (EAM), an almost infinite number of things can go wrong. A successful implementation depends not only on selection of the correct application, but on the quality of the communication between you and your application vendor or implementation consultants.

Some of the more disastrous ERP implementations that you read about in the news—the ones that public companies blame for their poor financial performance, going well over budget and taking years to complete—might be blamed on the complexity of the product being implemented or perceived unresponsiveness of the implementation consultants. But the success of the implementation often depends on the customer organization and the project management ability of their implementation team. Those on the receiving end of an implementation are in a very challenging position because in many cases, none of the team members has been through an implementation before. Ostensibly, the team representing an application vendor or implementation consultant should be more experienced and professional, but miscues on their part are not unheard of either.

In white papers, there is no shortage of advice about what best practices can lead to success. But equally important is a thorough understanding of what worst practices are to be avoided during an implementation. Problems during implementation are never deliberate. But in this white paper, we will review four practices that should be avoided unless one wants to go out of one’s way to cause their implementation to tank.

UNDERESTIMATE THE STRATEGIC IMPORTANCE OF THE IMPLEMENTATION PROCESS

This is a very broad topic, but a failure to understand the various ways that an enterprise application implementation is strategically critical to your business can cause a number of problems. But perhaps the most common result of this cognitive failure is reflected in the type of people a company might assign to an implementation team and the problems that naturally ensue.

Some companies are understandably reticent to devote their most valuable human assets to a months-long implementation process and instead, assign more Junior people to the team. This tends to create problems of vision as younger, less experienced employees of a company or those in staff-level positions tend to have an excellent grasp of their own jobs but a lack of understanding when it comes to the company’s strategic goals or company operations as a whole. They may be more likely than their more experienced peers to be interested only in making their own job easier, perhaps at the expense of others in the organization, skewing project resources accordingly.

Another common error is to heavily load the team with C-level executives. These senior players have an excellent grasp of where the company is today and where it needs to go tomorrow, so their buy-in is vital to the project. However, senior executives are often lacking when it comes to the specific processes and activities that are used within the company. A hands-off manager will be at a loss when it comes to discussing precisely how things are done within the company today and how, on a granular level, it is reasonable and desirable for business processes to be executed in the new software.

So who belongs on the implementation team? Choose middle managers who are key users of the software and have extensive knowledge of both company strategy and detailed processes. They must be empowered to make decisions regarding the implementation, necessitating C-level buy-in and support, and will be responsible for determining how the application is used and dictating the business’ process flows for a long time.

Another way that a failure to appreciate the strategic importance of the implementation manifests itself is to assign what might be the right team but then give them no time to work on the implementation. Once the team is chosen, it is vital to make sure their regular jobs are backfilled so they have time to concentrate on the implementation. In too many circumstances, I have seen situations where someone is assigned to an implementation team and are told they still need to do their job and need to implement this ERP package on the side. That is not a viable situation as the implementation will be starved for resources. It will either grind to a halt or will be forced to move ahead with inadequate information, resulting in multiple problems at go-live.

BITE OFF MORE THAN YOU CAN CHEW

There are two ways to try to do too much too fast with an ERP implementation. One is to try to implement too much with regard to geography or sites all at one time. Some ERP vendors and implementation providers advocate the “big bang,” encouraging companies with multiple locations to take their entire organization live all at once. But often, that proves to be too much for an organization to handle.

In many cases, it is better to implement an enterprise application at one or two sites at a time. This allows a company and its implementation consultants to work kinks out of the business models and process flows that were decided upon by the implementation team.

Another way to bite off more than you can chew is to make too many dramatic changes in your organizational culture all in one felt swoop. When you buy packaged software, you are not only buying technology, but a way of doing business that can improve the efficiency of your organization. In many cases, elements of an application’s functionality may represent business practices that you currently do not engage in, either because they have not been a part of your corporate culture or because they are not supported by your legacy system. Each of these process improvements and best practices are likely good opportunities to move your business forward, but trying to implement all of this functionality at the same time may prove to be too much for a business’ management structure and employee base to absorb. Consider that Vitamin C is a very good thing, but trying to take too much of it at one time can upset your stomach!

In order to avoid disruption that can result from change that comes too quickly, it often makes sense to take a more gradual approach. At the initial implementation, reach out to your functional leaders to see whether or not adding various elements of new functionality creates too great a burden. Sometimes better to go live with functionality you currently have in your legacy system, and then schedule add-ons when you are genuinely ready for them after an initial stabilization period.

REPLICATE YOUR LEGACY SYSTEM ON NEW SOFTWARE

While trying to change too quickly is one way to hobble your enterprise application implementation process, trying to avoid change altogether can be just as damaging.

Some people just don’t like change, and the idea of abandoning the way they have done things in the past upsets them. These people, if they are part of an implementation team, come into the project with their own paradigms and their own ideas of how things should work, which are often based on the old system. Oftentimes, it does make sense to go live first on just enough functionality to replace the legacy system, but resistance to change of this nature can bring an implementation to a halt. A fervent desire to replicate an existing environment can be very granular, and team members may even have a specific idea of what screens they should see, what reports they should get and what buttons they click. People who are reticent to move away from their legacy system focus on the functions of the software rather than the business requirements behind those functions, and often request numerous modifications to the new environment, which cause cost to spiral without real business benefit.

It is important for an implementation consultant to understand the current processes and how the legacy system is being used. That is why a consultant will ask not only what processes are currently being followed, but what are the underlying reasons for each of these process. Sometimes, these questions are asked to make sure that each process is necessary, but this line of questioning can also determine the business need that process is fulfilling. An implementation consultant or applications vendor should understand that anything their customer does in their current process is likely done for a good reason, and it is their job to find what that reason is and then find the best way to satisfy that underlying need in the new software. Their goal should not be to replicate the way things are done in the legacy system. Indeed, most times, an implementation may bring a slightly different process flow, different screens and different reports. People assigned to a company’s implementation team have to be able to think outside the box and realize that their business requirements are being met even if the screens and buttons are not exactly the same.

There is a relationship between the ability to successfully navigate this process and the degree to which the right people were assigned to be a part of the implementation team. It is crucial that the implementation team be able to look beyond the superficial elements of the legacy system, and see past the screens and reports to which they have become accustomed. They need to envision how the new application will be made to meet their underlying business requirements.

Implementation team members must be comfortable opting for a slightly different approach or a slightly different process in order to meet the strategic goals a new enterprise application is meant to achieve. In some cases, team members should even be empowered and unafraid to suggest organizational changes outside the application that will better accommodate a new process flow and make for a smoother implementation. Perhaps certain departments should be merged, or people who had worked on opposite sides of a building should be moved to better facilitate the new way things are to be done. With too great an attachment to the past, it is hard to realize a more productive and streamlined future!

REINVENT THE WHEEL

A fourth and final way to kludge an enterprise applications implementation process is to reinvent the wheel by disregarding established implementation methods. Regardless of the implementation provider you choose or the enterprise software product you choose, your implementation team will come in with an implementation method, with specific steps to go through in order to ensure success. This implementation method is proven, and has been developed over long experience at dozens, hundreds or even thousands of companies.

An implementation consultant or application vendor follows this method because it suits their approach and the software in question. While methods of different implementation providers may vary, a viable method will generally include four distinct steps:

Mapping: At this stage of the project, a consultant will identify the business processes you will implement and determine how, at a business process level, they will be handled by the software. IFS, for instances, uses its own IFS Business Modeler software for documentation of all process levels, automating the process of finding functional gaps and working them through to a solution.

Implementation/Definition: During the implementation/definition phase, the consultant and implementation team will take the process maps and work through the details. There might be several rounds of work routine documentation, modeling data migration to make sure processes are well-documented and they will work.

Testing: During the testing phase, the consultant and implementation team will tie all of the processes together and test them to make sure they will work. One way to do that is to run several days of the company’s transactions through the system end-to-end in a controlled business simulation environment.

Rollout: After mapping, implementation/definition and testing are completed, it is time to roll the application out to users in the organization. This step involves training of the end users and ensuring that the IT infrastructure is in place to run the application prior to going live.

All of these steps are absolutely necessary. But sometimes, in a budget crunch or on a tight timeline, there is the temptation to cut out some testing or cut out some mapping. Even if you are not trying to reinvent the wheel in its entirety, it is not advisable to simply remove a few spokes to see how it holds up under load! Skimping on any of these steps comes with a degree of risk that needs to be recognized. Straying from the established implementation method creates the opportunity for things to go wrong at a critical time—during go-live week or after go-live as poor preparation comes home to roost. Typically, problems that result from diverging from proven methods cost more to fix than a more thorough and systematic implementation would have cost to begin with.

There are entire books, thorough training and certification processes all devoted to lean supply chain practices. But within any manufacturing environment, there are a few relatively simple steps that will help any enterprise lean their supply chain. In this white paper, we will touch on these simple measures—measures that any company can take.

Lean in a supply chain context is about a holistic view of procurement, manufacturing distribution and sales order processing. This means that some level of enterprise technology is necessary to view the organization in an integrated context instead of as functional islands. However, before technology can facilitate the lean supply chain, manufacturing executives need to start thinking in lean supply chain terms. We will be reviewing those terms and sharing the key concepts that are the foundation for the lean effort.

 In short, we will discuss:

• Four tips to help you bring lean supply chain improvements to your manufacturing operation.
• Six technology tools that help automate these lean supply chain practices.

We will use a few practical examples along the way to illustrate these concepts, but our main goal will be to define the specific things manufacturing executives can do to lean their supply chain.

Tip one: resolve conflict Between Manufacturing efficiency and customer service

One company that I have been involved with from a lean supply chain perspective is a manufacturer of paints and coatings. After implementing their new enterprise application (ERP), they wanted to use the new-found visibility of their operations to implement a lean supply chain program. They found that before you can lean an organization, you have to have a good idea of what your current operations and processes really are. Then, once you know what you are doing, you can decide on process changes and then measure to what extent those changes have reduced nonvalue-added work.

What became immediately apparent is that like most manufacturers, this company faced the same conflict between the need to be efficient in production and the need to be responsive to customers. The manufacturing department tended to schedule for maximum efficiency by producing very large batches. This enabled efficient purchase or raw materials, maximum return on machine set-up time, manufacturing personnel and other costs. Large batches are simply a good way to minimize the cost per produced unit. Low cost-per-unit is attractive, but it is in conflict with the goals of the sales organization. While manufacturing is rewarded for efficiency, the sales department is rewarded for serving the customer, which in turn leads to increased revenue and commissions. If manufacturing commits production capacity to large runs that are not immediately tied to customer demand, it might be difficult to meet the needs of customers as those needs change and fluctuate during the year. An item that is requested might not be in stock and may not be scheduled for production at a time when immediate capacity is committed due to the high-volume production schedule. Moreover, these large production runs mean that large amounts of capital are tied up in finished product inventory long before any revenue can be realized.

In the case of food and beverage and some other process industries, these large production runs can also result in spoilage as the effective life of raw materials and finished goods is spent sitting on the shelf.

The paint manufacturer did the obvious thing … decrease their batch sizes. Going forward, manufacturing would not be making unilateral decisions about batch sizes and production schedules, circumventing their natural tendency to focus on manufacturing efficiency. Instead, they would now be obliged to produce only enough to cover a certain period of time based on the sales projection. That means that every product will now be produced more frequently and in smaller batches. To encourage this behavior other metrics and KPI’s can be introduced that are more holistic and based on customer service levels and inventory turns, rather than just production output.

There are any number of formal disciplines designed to tie production in with sales forecasts. Sales and Operations Planning is one such method. By tying manufacturing schedules on sales projections that typically look a short distance into the future, you will be manufacturing what customers are actually asking for, improving customer service and allowing greater responsiveness. Your inventory levels will decrease in proportion to your inventory turns. The higher the speed through the supply chain, the higher the inventory turns and the less capital tied up in inventory at any given time. At the same time, the faster the raw materials move through the supply chain, the less obsolescence you have and less expired materials you have.

Tip two: extend systems to suppliers

Once the basic problem of aligning manufacturing schedules with demand is taken care of, the greatest bottleneck to improved supply chain efficiency is often the disconnect between internal scheduling processes and those of external suppliers. Companies who are vendors to major OEMs know that large manufacturers are working to eliminate this bottleneck, and are often working with suppliers on a proactive basis to help them become more responsive.

Technology can play a vital role in eliminating this constraint. In the case of our paint and coatings manufacturer, one of their main bottlenecks was packaging. They outsourced printing on the cans their product was shipped in, which meant that the supplier cannot finalize their own can production schedule until they know the exact product numbers that will be filled. Their packaging actually took longer to produce than the manufacture of the product itself. Even though the cost of the packaging is low in comparison to the actual product to be filled, the scheduling of the packaging supply is one of the most critical and difficult parts of the production planning.

The solution was to set up supplier portal so that the packaging vendor and other suppliers could look into the production plan and prepare their own schedule accordingly. This eliminates a lot of the manual and administrative work involved with interfacing with a supply chain partner in real time, removing all manual intervention and administrative delays. Portals of this nature can also provide a longer view of anticipated production so that vendors can manage their own inventories and plan their own capacity according to anticipated demand.

Tip three: run parallel MRP processes

To clarify, this tip does not have as much to do with running parallel systems for manufacturing resources planning (MRP) as much as it is about delaying the commitment to manufacture to a point where demand is visible, known or certain. Even as companies try to focus on the disciplines normally associated with the idea of a lean supply chain, this is another fundamental paradigm shift that must take place within their organization, and it is often overlooked.

For instance, many companies operate with one single manufacturing resources planning (MRP) process. Consider that company that manufactures in a make-to stock (MTS) mode, whose executives feel that this single MTS enterprise system is adequate for their needs. This attitude is fine if a manufacturer has a stable, predictable demand for all of its products. But in reality, few manufacturers have the luxury of flat demand. More often the rule of Pareto is applicable. This rule suggests that 20 percent of products have a stable demand, and you can manufacture them efficiently in large quantities. But the other 80 percent of a manufacturers’ part numbers are ordered less frequently, and therefore need to be treated differently in the company’s processes, systems and scheduling. This is why virtually any MTS manufacturer should run in multiple manufacturing modes. Most MTS manufacturers would benefit from a parallel make-to-order (MTO) system. This will avoid the stockpiling of a large number of items that are more effectively handled in MTO mode, freeing up both capital and production capacity for other products, all without sacrificing responsiveness or customer service. By continuously analyzing demand patterns and inventory turns, the point of postponement can be changed over time to achieve the optimal balance between efficiency and responsiveness.

A modern, agile enterprise application (ERP) will include all of the necessary tools to handle these multiple modes. Apart from ensuring that they have the proper enabling technology, manufacturers will need to carefully analyze the demand patterns for their finished goods and divide them into MTS and MTO.

Tip four: Master the demand forecasting process

Too many companies fail to give demand forecasting the attention it deserves, and this is often the undoing of even the most aggressive lean supply chain project. If you think of a demand forecast, the more accurate it is, the better position you are to supply to the market what the market needs. Conversely, basing a lean supply chain effort on an inaccurate demand forecast is like building a house on a foundation of sand.

If you can increase the demand forecast accuracy, you can decrease your inventory and increase your level of customer service at the same time. Unfortunately, most companies divide responsibility for the demand forecast among multiple departments.

Sometimes, the process is owned by the sales department, and they tend to be too optimistic because optimism is in their nature and they want to avoid disappointing a customer by being out stock. At the end of the day, no one is specifically responsible for forecast accuracy, perhaps in part because the company lacks the proper tools to develop an accurate forecast. It is not surprising that, as a result, this crucial role tends to fall between chairs in many enterprises. It is imperative that a manufacturing enterprise assign demand forecasting to an independent party within the company that has more of a holistic point of view than would sales, manufacturing or any other specific department.

Technology tools to look for

There is no technology or enterprise application (ERP) that will, all by itself, deliver lean supply chain benefits. However, as you embark on your lean journey, you will be much more successful if your enterprise software supports and streamlines your lean efforts instead of preventing barriers to the adoption of lean supply chain practices. Here are five things to look for in enterprise technology to help you make sure that your new enterprise environment is helping and not hurting.

That means that there are some specific things you will want to look for in an enterprise application (ERP). It should almost go without saying that an application should be well-integrated company-wide and provides the visibility necessary to facilitate lean processes. Remember—you cannot improve what cannot measure, so visibility into processes company-wide is necessary for lean supply chain improvements. There are other, less obvious things to look for as well, including:

An integrated solution for quality management that will support your effort to do things right the first time. Without a viable system for getting the appropriate quality out of manufacturing and supply chain processes, it is entirely possible that apparent efficiencies gained in one part of the process will be wiped out by the added effort involved in correcting errors at another part of the process. You need a system that will report and allow you to record quality results and analyze performance on every lot or batch you manufacture through statistical process control. You will then be in a position to see how your process is aligned with your ideal values and then improve the process to reduce the quality failures.

The better the demand forecasting tool in your enterprise application (ERP), the leaner your supply chain will be. The better you know what the customers will ask for, the leaner your supply chain will be. Make sure that demand planning functionality allows multiple users to simultaneously review and give input on demand plans, thereby shortening review cycles and increasing accuracy. It is also import that the demand forecasting tool allows you to export forecasts to various common office applications and emailed to key people throughout the enterprise. In order to increase accuracy, you must be able to easily monitor and take action based on the forecast error, so look for robust error management functionality, including Mean Error, Mean Absolute Error, Mean Absolute Percentage Error, Theil’s U-statistic, and others.

Regardless of your manufacturing mode, make sure that an enterprise application (ERP) supports multiple modes including MTO, engineer to order (ETO), configure to order (CTO) and others. Even straightforward MTS manufacturers need to account for the different levels of demand for various products and part numbers. This will allow you to be efficient on products that make sense to manufacture in large quantities and responsive on products that are best handled as special orders.

An enterprise application (ERP) ought to offer tools that allow production to become pull-based, facilitating processes like Kanban. Strong Kanban functionality will allow companies to pull products through their supply chain, thus leaning the supply chain, minimize work in process, maximize responsiveness and avoid stock piling of finished goods.

Regardless of how many sites you manufacture at, your enterprise application should provide for operations at multiple sites. Because as you begin to think in terms of your supply chain the encompassed vendors, distributors, and customers, plus distribution centers and warehouses, you really are by default operating in a multi-site environment. The better you can integrate and plan for cohesive operations between these different sites, the more responsive you can come as the information flows seamlessly through these nodes, hubs, customers and suppliers—regardless of whether these sites are under your direct control or not. Begin to see multi-site functionality for what it is … a tool for collaboration up and down the supply chain.

Fundamental changes are happening in the global drilling industry. In the midst of an unprecedented capital investment boom, the global drilling industry is undergoing significant structural change as well as a fundamental shift in requirements for operational performance. International drilling contractors face a situation in which strong growth requires new ways of handling increased pressure on human resources, equipment utilization, and asset performance. This growth coincides with rapidly evolving legislative and political environments in which the “license to operate” puts procedures, systems, visibility, and traceability to the test.

Drilling contractors are continuously exposed to regulatory (e.g. Brazil Nota Fiscal) and commercial changes (e.g. pricing/rates) together with frequent alterations of customer demands. In fact, the industry is affected by operational, financial, and regulatory processes that are far more complex than in any other industries. Consequently, companies that strive to be successful in this project- and contract oriented business must be able to quickly recognize and act upon industry changes and changes within on-going projects and contracts.

For most contractors, long-term assets management and maintenance still remains the number one priority. Asset upgrades or lifecycle extensions on drilling rigs or production platforms are met with strict quality requirements. Unwarranted downtime directly affects the bottom line and must be avoided via all means. To secure an optimized asset management process, several key functions must be in place: (i) a well-functioning logistics operation in which spare parts and plans for execution must be secured; (ii) full visibility, whereby complete offshore and onshore replication of data is essential; and (iii) traceability across all varying layers.

Information technology can certainly play a major role in fulfilling the above challenges. Unfortunately, many drilling contractors still struggle with fragmented business solutions with several varying, non-integrated, proprietary IT systems that result in poor information flow; inaccurate, cumbersome data retrieval; and reduced decision-making capability.

This white paper looks at several factors to consider when looking for an ERP system and emphasizes areas of particular importance. Its overall aim is to describe what you must consider and account for when selecting a solution that will ultimately enable organizational responsiveness and optimization of your processes.

VISIBILITY & TRACEABILITY IN THE VALUE CHAIN

Full visibility and traceability of the complete equipment and material lifecycle is crucial in the oil and gas industry. All material transactions and completed equipment documentation from “as designed” to “as installed” must be accounted for.

Regardless of where a piece of equipment, system or component is used, you must always be able to trace it back to the relevant (i) requisition, purchase, or shop order; (ii) project, supplier, or stock number; and (iii) receipt or certificate. It must be convenient to search for relevant data, and you need a high level of confidence that information is secure and accurate.

But today’s industry still struggles with fragmented business solutions that lack integration; this makes it difficult to produce a comprehensive asset lifecycle view. In your current operations, you probably face these and other issues:

• Extensive data silos
• Poor quality data in information systems; limited value for operational teams
• Difficulties in gathering information; poor visibility across the value chain (i.e. projects, purchase, operations)
• Difficulties in using frame agreements
• Non-integrated cost management; mostly done in Excel (except recording of actual and committed costs that are stored in the financial database)
• Incomplete decision support; consolidating reporting is cumbersome

Needless to say, this produces several inefficiencies for operations (in decision-making) and for financial budgeting and control. But with a strategic ERP approach, you can eliminate these inefficiencies. How? By enabling an integrated ERP system that can connect your business processes onshore and offshore and between rigs and sites.

When facilitating information flow across varying disciplines, you will increase efficiency and get full visibility and traceability of equipment, material, and people in the operations.

FINANCIAL MANAGEMENT & CONTROL

Use of non-integrated and fragmented systems is time consuming. Getting the overall financial picture is cumbersome—and even more complex for drilling companies that operate globally with varying regulations and tax regimes. One critical success factor for offshore service companies is the ability to financially track asset transactions such as movements of rigs between asset owners and contract or operating companies, yard stays, and modification jobs. At the same time, the accounting department must perform daily financial activities.

The ERP solution should support:

• One common solution for asset, logistics, contract, projects, and finance—to secure traceability and visibility throughout the lifecycle of the asset/rig and to be able to trace and monitor total cost of ownership
• High data quality, which minimizes risk for errors and manual handling and facilitates follow-up
• Regulatory compliance in a global environment, such as Nota Fiscal in Brazil, local GAAP versus IFRS and US GAAP
• Complex rig and corporate structure
• Improved performance management based on real-time data
• Traditional accounting such as invoicing and payment; supplier invoice workflow; currency calculations and adjustments; budgeting and forecasting; and fixed assets and project accounting

PROJECTS AT THE CORE OF THE BUSINESS

For most drilling contractors, projects are the very cornerstone of the business. Therefore, capability to efficiently manage projects of various sizes and complexity is crucial for staying competitive. But a common obstacle is how projects are being organized and supported. Traditional organizational structures and systems normally make it difficult to understand real-time operational situations,  which delays corrections to resourcing   and supply. The delays are expensive and almost make it impossible to determine whether or not an opportunity will ultimately be profitable.

Instead, structuring a business around    a network of integrated projects—rather than fixed departmental or geographic silos—is fundamental for success within projects and on an overall basis. This can be achieved via a truly  holistic ERP system that enables companies to move from being departmentally constrained to truly embracing end-to-end processes. In addition, this (i) gives managers better progress visibility, (ii) enables efficient risk management, and (ii) allows for instant adjustments.

New Builds & Modifications

Drilling companies that order new drilling rigs, or must modify critical equipment, typically organize these new buildings or modifications as projects. Why? Plain and simple: to facilitate execution as per cost, progress, and delivery time. To track complex projects, it is necessary to establish a structured, controlled way of managing them via the ERP system. The system should let you:

• Monitor all cost, progress, and changes
• Plan for verifications, audits, or non-conformance reports of the asset, and personnel utilization
• Visualize status of all projects using built-in reporting tools
• Be flexible; rig or unit set-up as a company or project/contract to improve cost forecasting and to gain better visibility of critical cost elements.

ENTERPRISE ASSET MANAGEMENT

Regardless of whether you own and manage your own assets, outsource maintenance of your assets, or perform service on other companies’ assets, it is important to look for a solution that enables management of the complete asset lifecycle. Why? Because over the years, a wealth of experience data is generated from, for example, work orders, failures, spare part usage, projects, and process data. Through thorough analysis of this accumulated data, you can shed light on bad equipment, root causes, ineffective maintenance tasks, and unnecessary costs— ultimately leading to decisions that will improve the maintenance program.

Your ERP solution should:

• Provide a more cohesive, real-time-based view of your operations
• Enable a high level of equipment availability and safety
• Increase asset life, reduce manual work, and facilitate cost-effective maintenance planning
• Meet the need for global standards

Enterprise asset management (EAM) is a broad and sometimes all-encompassing enterprise software option, and this is how it varies from software that only manages maintenance tasks and work orders. Selecting EAM that offers strong functionality beyond maintenance—specifically in the area of advanced inventory management, procurement and logistics—will drive more rapid ROI on the software investment.

Management of Subcontracts

Subcontractors are vital for delivery in the value chain, and the contracting process is becoming increasingly critical in managing offshore operations. Joint ventures, outsourcing, and sub-contracting all constrain managers’ abilities to stay on top of projects. So it is essential to standardize these processes to secure quality—including work performed internally and work performed externally by outside contractors and subcontractors.

Your contracting solution should:

• Provide lifecycle management of a contract from bid and tendering through completion and handover
• Allow flexible invoicing features and capabilities to manage variations to scope
• Handle simple or complex sub-contractor activities that are critical for improving follow-up of suppliers and enabling better cost control

Operations Planning

Operations planning include activities and procedures to optimize planning of client-related services to be executed on rigs or via supply vessels. Efficient execution of maintenance and logistics for material and personnel are critical for developing efficient operations and reducing cost. Day rates and cost of downtime are high; consequently, planning must focus on continuous operations without unplanned stops in drilling activity. Close links between logistics, maintenance, and people guarantee more efficient competence management and planning on all levels.

Workforce availability, material availability, and preventive maintenance programs are the most important focus areas to keep the rig in production and to minimize frequency of unplanned production stops.

Your ERP system should let you:

• Use project functionality as the high-level planning and follow-up tool for rig operation
• Plan every activity that should  occur, including start time and duration
• Connect material requirements, personnel resources, work orders (operation and maintenance), and documents to the activities
• Coordinate operation plans with maintenance plans and ensure that personnel resources are available when needed

FULL SUPPLY CHAIN, INCLUDING OFFSHORE LOGISTICS

Delivery of equipment and spare parts is a critical activity for drilling companies, especially in complex off-shore environments. It is essential to use an ERP system that helps streamline material transfer—thus reducing shipping costs and unwarranted downtime risk. It should also include management of containers and other load carriers for on- or offshore deliveries. To support these offshore processes, functionality for efficient transport order management is essential.

In addition, it is also critical to have full traceability of hired-in equipment—to fulfill requirements and cut operation costs. A comprehensive solution for hire-in must support these processes in the supply chain.

OFF- AND ONSHORE DATA COMMUNICATION

Any enterprise with multiple locations can benefit from an enterprise solution that can run all of the locations, divisions, or subsidiaries on a single database and a single installation of the software. In the offshore industry, this is still important. But achieving this goal is more difficult, given the great distances involved and the unstable nature of satellite communications among drilling platforms or ships and a corporate office. That is why ERP vendors, with focus on the offshore industry, offer a built-in data replication solution. While many offshore operators may run software that relies on a third-party replication solution, ERP software, with its own offshore replication functionality, offers ROI benefits that originate from reduced cost and increased utility.

Replication involves one or more application databases onshore and one application database located on each offshore vessel or oil rig. Each vessel must be represented in the enterprise environment in the enterprise application data onshore and in the enterprise application data on the vessel. Replication keeps business critical and transactional data at these sites more or less identical.

When ERP vendors offer the replication functionality, it is much easier for that data to be replicated at the application level rather than directly within the database. Consequently, data exchanged among systems goes through data integrity controls built into the software.

Replication generally supports basic data, such as parts and suppliers, but other types of basic data may also be defined for replication. At a minimum, bidirectional replication of purchase requisitions and order arrival data and onshore-to-vessel replication of purchase orders are required. Relocation of parts can also be covered, including relocation within a site (moving parts from one location on the vessel to another location on the vessel), between vessels, and from shore to vessel. Serial structures, such as blowout preventers (BOPs), can be relocated like other parts, and a replication solution must support relocation of such structures.

Most data replication functionality focuses on transactional data rather than data objects, because CAD drawings and other documents can be quite large.

But transactional data must be replicated, and ERP software with built-in replication functionality offers greater data integrity and costs less to license and implement— compared to third-party solutions that must be configured, integrated, and then tested. So ERP software increases ROI.

REGULATORY COMPLIANCE, QA AND HSE

Accidents, such as the BP Horizon in the Gulf of  Mexico (Macondo) and similar   incidents, drive stricter health safety and environment (HSE) regulations. An effective HSE policy reduces risk of accidents, which has direct impact on an organization’s efficiency. When looking for a supportive solution, go for a complete solution that protects the safety, health, and welfare of people engaged in work or employment.

Optimally, the solution should support:

• Regulatory compliance
• Fulfill international, regional, national, and local legislation—including industry specific legislations
• Safety policy management, risk assessment, incident management, and key performance indicator reporting
• Global expansion by complying with legal requirements in regions that are crucial for the oil and gas industry

USABILITY DRIVES PRODUCTIVITY

The extensive growth plans for many drilling contractors and requirements for training existing and next-generation employees, put pressure on usability of new IT systems. In addition, environments in which drilling contractors operate and the rotation schedules for technicians and other front-line employees require a system that is easy to use—a system that does not present functional barriers to individual jobs. Offshore maintenance workers, for example, need a simple user interface that supports role-based information for standard work order handling and standard permit and isolation flow processes.

An outstanding user experience increases productivity, encourages people to use information, and ultimately lets you run a better business. Access to the right information at the right time is essential; everyone who uses the business software—from casual users to super-users—should find it equally fit for purpose and for ease of use. In essence, usability is crucial for productivity.

MOBILITY DRIVES EFFICIENCY AND BETTER DECISION-MAKING

Asset management and maintenance are critical for oil and gas companies, because asset downtime and process inefficiencies have a direct impact of the bottom line. Mobility can underpin a more effective field service and maintenance and allow for more efficient work across large plants and facilities. There is an upcoming trend in the oil and gas industry to use mobile solutions more efficiently, because mobile solutions allow staff to send updates or report on maintenance work on the spot— without having to return to a hub location to check spare parts inventory or look up technical information. In this way, mobilization can lead to reduced overtime and overall asset maintenance cost—by delivering information to enable decision-making on the spot, at the point of maintenance.

Your selected solution for mobility should facilitate access to applications and information and ensure ease of use and consistency in field operations—on- and offshore.

CONCLUSION

We hope this white paper shed some light on matters you must consider when selecting your ERP system. Capabilities for managing change, meeting visibility and traceability demands, and supporting the entire asset and project lifecycle are key requirements within offshore service. So if you strive to optimize operation assets and streamline operations, you need to take a holistic approach and turn your back on the ecosystem of scattered IT systems.

Executives at contracting, engineering, equipment suppliers and professional service companies serving the asset-intensive oil and gas industry know that this is a challenging time to be in the industry. Customer organizations are more demanding than ever, and are asking their vendors to take on more risk, compete more aggressively on price and toe the line on quality.

Information technology certainly has a role to play in meeting these challenges, particularly since many companies serving the industry are still running their businesses on older enterprise applications not really suited for the information intensive nature of the industry. Enterprise applications designed to meet these needs are relatively new to the market, and ought to be considered carefully by industry executives charged with succeeding in the market today.

In this whitepaper, we will discuss the market trends affecting vendors to the oil and gas industry, how these trends are affecting operations and specific ways that enterprise technology can automate the best practices that will ensure success.

THE PRICE OF OIL

Whereas vendors in the oil and gas industry are affected by the same economic mega trends as everybody else, they are more directly affected by wild fluctuations in the price of oil than most other industries. Since the financial crisis in 2008, where we saw a steep drop in oil prices, we have seen a steady growth in the oil price and in the past two years, price stabilization at pre-recession levels. In addition, over the past few years we have seen annual double digit growth in offshore investments and in oil services. This large investment growth has led to intense competition for talent and resources, similar to what happened in the years prior to the financial crisis. In combination with increased global competition, this has caused cost levels to increase significantly, with the ensuing strong pressure on margins. As a result, wages and the other costs associated with oil exploration, extraction and processing have never been higher. This dynamic has created the need for oil companies to increase capacity while placing downward pressure on what can be spent to build new production assets or expand or extend the lifecycle of existing assets. Because of the stresses this combination has placed on the industry, many of the project owners in the industry have found that the vendors are more frequently not meeting their quality expectations.

Deadlines are missed, cost over- runs have become more frequent, and specifications are not met or are not communicated adequately between the different disciplines involved in these asset-intensive projects. Even though the blame for these problems probably lies jointly with the operator and the contractor, the oil company/operator is the customer, and they are demanding more accountability and greater control of their contractors and vendors.

This demand for accountability is one reason project owners/operators are moving over to an engineer, procure, construct (EPC) business model. With separate engineering, fabrication and construction, there is a lot of room for finger-pointing and blame-throwing when projects go wrong. To ensure that EPC contractors and other vendors have the capabilities necessary to meet budgets and timelines, operators are paying more attention to the IT infrastructure their suppliers are using. Technology is seen as the key to vendors’ ability to collaborate better internally, as well as with customers and sub-contractors. And this technology- enabled collaboration is the way to ensure that an EPC contractor, equipment vendor or other partner can plan, communicate and execute effectively enough to meet project deliverables.

ROLE OF TECHNOLOGY

Suppliers to this industry—equipment fabricators, maintenance and operations service companies and EPC contractors or those on their way to becoming EPC contractors —have slightly different technology needs. But they have one thing in common. They are being asked to do more with less, are being asked to take on more risk and need to collaborate more effectively internally and with trading partners and customers.

Moreover, as industry needs and the type of project available change, suppliers need to prepare for these new projects—which might have more to do with extending the life of existing assets than building new ones. Economic pressures may also drive many industry vendors toward new revenue streams, including aftermarket service and warranty work.

All of these changes place new demands on an IT infrastructure. In order to succeed in the industry now, oil and gas industry suppliers need enterprise applications that:

• Harmonize the working processes across disciplines, including engineering, fabrication, on-site construction, aftermarket service management and project management.
• Standardize processes to better secure quality, including work performed internally as well as work performed by outside contractors and subcontractors.
• Provide a complete overview of project risk, along with tools to manage risk pro- actively and in real time.

Given the multi-disciplined nature of EPC contractors and their need to manage often large and far-flung teams of contractors and subcontractors in a deadline- sensitive environment, their needs are perhaps the most extreme. But as more and more engineering, fabrication and contracting outfits are pressed into EPC contracts, they ought to consider the full EPC scope when selecting an enterprise application to ensure that all of these areas are supported.

Following is a breakdown of the specific needs of the various oil and gas industry suppliers, starting with the EPC contractors whose needs are, perhaps, the most complex.

EPC contractors need to pay attention to four essential elements:

1. Project-driven materials management. Instead of letting a product structure and traditional manufacturing resources (MRP) planning system drive functions like demand, fabrication and testing, an EPC contractor needs to ensure that its enterprise application provides robust project resources planning tools. This allows it to better schedule tasks in parallel rather than in sequence. In an EPC environment, for instance, fabrication starts long before drawings and product structures are completed.
2. Multidiscipline engineering register. Integration between engineering and purchasing/fabrication and other disciplines is beneficial for any industry, but is absolutely essential for an EPC contractor. Engineering functionality and a centralized engineering register deliver what is in essence a combined ERP and PLM solution. For companies that are involved in both engineering/ design and purchasing/material management—and maybe even fabrication/ installation—this central repository for engineering data that is shared throughout the enterprise allows for efficient and error-free handover of data between functions. It facilitates handover from engineering to purchasing, between fabrication and installation and maybe even, in the case of last- minute changes to the design, between engineering and installation. This level of integration delivers detailed tracking of those difficult and unexpected project changes. These changes are often difficult to manage because when there are design changes, it is not the part numbers that change, but rather the attributes of those part numbers, the documents attached to the part number and the tagged information. These details are lost if communication from engineering consists of a simple list of part numbers released to a fabrication department, hindering the ability to handle changes and increasing project risk.
3. Re-contracting and Subcontracting. Traditional purchase orders are fine for acquiring materials and receiving them into inventory. But are they as good for specifying the amount and qualities of concrete to be put into place or outlining the scope of services for a subsea cabling contract? Contracts and subcontracts are not items received into inventory, but rather, represent complex agreements that involve careful development of the scope of services and then require careful performance management culminating in the application for payment process. Technology designed to handle the typical customer order—as is found in a traditional ERP application—will not adequately deal with the complexities of the subcontract, once again exposing an EPC contractor to risk due to the inability to proactively manage contractors and subs.
4. Forecasting and project accounting. This enables project controllers to look at project data and make future projections of project performance rather than just seeing—after the fact—how they wound up over budget, behind schedule or off of the specification. This allows better project forecasting than many generic MRP-driven enterprise tools that are the equivalent of reading a newspaper—you can see what happened, but only when it is much too late to do anything about it, and it is impossible to look into the future. This real-time view of the project, which provides visibility into how project milestones are on-track or off-track and the implications for the project going forward, also enables cut-offs, reporting and forecasting independent of traditional transaction periods. It presents automated features for fetching cost data that need to be reported into the general ledger each period. It will also allow for automation of routines for revenue recognition, an important task to ensure timely payment by the customer.

Service companies working in the oil and gas industry are a diverse lot. Companies that undertake project-driven services will need to ensure that their enterprise environment addresses the critical process of mobilization—ensuring that you have people and equipment available to do your job at the right place and at the right time. An enterprise application will also need to allow for the charging of equipment that you have for hire, and tracking of revenue generated by each piece of equipment. Services can encompass a broad spectrum of business models ranging from well servicing to cutting and abandonment, and it is hard to make generalizations of how enterprise needs will change over time. But many of these companies are also expanding their offering into elements of EPC, taking on more risk and managing the work of more outside entities, so they should plan to move onto a technology platform flexible enough to handle these potential future needs with minimal business disruption.

Equipment fabricators and manufacturers serving the industry often operate in an engineer to order (ETO) mode. ETO manufacturers have some of the same needs as EPC contractors in that they require the ability to handle material management through project-driven structures, using Project ERP to automate the demand and supply processes. These companies also, early in many projects, need to buy long lead-time materials well before engineering has been completed. This means that they need a system that allows fluid movement of data back and forth between engineering, purchasing and fabrication. At later stages, they need to be able to record what long lead time items they used as the project progresses. They also need to be able to match what parts and materials they have in inventory with what they need at a certain point in the project. You will not be able to do this with traditional MRP, which does not allow parallel processes. Traditional MRP relies on product structures, and as an ETO company, you do not have any static product structures.

While these equipment manufacturers or fabricators are not technically in the contracting business, they will do well to implement strong contracting/subcontracting functionality, because they often purchase assemblies or subassemblies from other companies. They can operate more as systems integrators than companies that own all of their own technology. That means their needs in the area of product data management are much more complex, since they need to maintain specifications and information not only for what they fabricate but for the technology and components they purchase from others. They also need technology that facilitates innovation so that, working with their extended supply chain and subcontractors, they can develop new products as the market requires.

Like services companies, equipment companies will want to be prepared for an eventual, opportunistic, move into at least some aspects of EPC or aftermarket service. One valuable asset the equipment manufacturer has, particularly if they have powerful PDM capabilities, is in-depth knowledge of the equipment asset installed on the customer site. More and more of these equipment manufacturers are expanding their business model beyond simple fabrication and into aftermarket service by selling maintenance contracts, parts or other services for installed systems, turning that product data into an ongoing revenue stream. But this paradigm shift requires supporting technology that goes beyond what the equipment company may currently require, so it would be very smart if executives in these firms ensured that their technology platforms could easily be expanded to allow for service management and maintenance functionality.

CONCLUSION

Many suppliers to the oil and gas industry went through a software selection prior to the turn of the century in an effort to avoid problems associated with Y2K. Unfortunately, in 1998 or 1999, application suites designed to meet the specific needs of the industry did not exist. Many companies chose and implemented traditional manufacturing solutions that were a poor fit for their complex project business processes, or opted for an assortment of point solutions that result in a fragmented IT infrastructure and disjointed business processes. Others developed their own homegrown solutions that lack the reliability, 24-7 support and flexibility of modern, SOA-driven technology. The lack of industry-appropriate enterprise project software has reduced the efficiency of these companies over the years. It is hurting them now as they try to adapt to a more competitive market and it will prevent them from pursuing new revenue streams in the future. Fortunately, today, project-enabled offerings are available that cater to the specific needs of the industry.

The above points should help executives in these companies understand how these offerings can help them adjust to current market demands and identify the best enterprise application for their business.