Project Management In Erp Implementation

  • June 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Project Management In Erp Implementation as PDF for free.

More details

  • Words: 4,096
  • Pages: 13
Effective Project Management in ERP Implementation The sheer size and complexity of ERP implementations makes managing these projects difficult. ERP management involves mainly two things, people and technology. An ERP package impacts the entire organization and can affect nearly every employee in the organization. And in some cases, it will not be possible to know who will be affected and how, which can lead to many problems. It is also hard to get a clear vision of the technological portion of the implementation because of the combination of hardware and software involved. Irrespective of whether one module or multiple modules are being implemented, one must ensure consistency and full integration across the various subprojects, which is an enormous effort. Perhaps the single most decisive element of ERP success or failure is the knowledge, skills, abilities, and experience involved in project management. An ERP project manager must understand both the business and the technology. To avoid customization, businesses frequently change their business processes to fit the new software. An ERP project manager must understand the impact of the ERP implementation on the business, and work with business managers to ensure a smooth transition from the "as is" to the "to be" business operating environment. A project manager must have certain charctersistics if he is to pull off a successful implementation. A few of these are 1. Flexibility to roll with the changes as the project progresses. 2. They must be able to work with nearly every individual in the organization 3. They must possess the ability to learn extremely fast, because they will need to understand business issues in areas of the organization with which they are unfamiliar. 4. They must be able to clearly envision the project end game, and then hold the entire organization to the road that leads to that successful end. In order for efficient project management, one must understand the main activities involved in ERP Implementation. The main activities that help to achieve an efficient and streamlined ERP project are (2) (3)

1. Embrace Overall Goals and Objectives The main questions to ask in this phase are What is the project trying to achieve?- Why are we doing this?- What is the payback going to be? It is imperative that senior management defines these objectives and embraces the project up front. This is usually done by forming a steering committee composed of senior executives to drive these goals and objectives. The executive steering committee has two functions. The first is to advise and act as a sounding board for the ERP project team. The second is to help with the resolution of issues that cannot be settled by the ERP project team. One of the main reasons for failures of ERP projects is caused by the lack of direction and support by senior management. Senior management must provide the oversight and support required to make the project successful. The goals and objectives must be disseminated through the organization and become well known to all levels of the organization. The goals and objectives should be put into a formal project charter before the project begins. The Project Charter is a document that should basically state in concise terms: what the goals and objectives of the ERP project are, who is responsible for the outcome of these objectives, who will participate in the project, what the timeframe will be, a list of deliverables, what are the project policies and procedures, and how will people know when the project is completed. The project charter becomes the formalization of the first activity. 2. Defining Requirements ERP implementations are the designing of the information system for a business. If the requirements are not defined in advance and well understood, the result may turn out to be a composite of what other people think the system should be rather than what is right for the business. Defining requirements should consist of an overview of how the new system will function, a list of specific required business functions and processes that must be able to be performed in the new system, and finally the policies and procedures that will need to be in place to

support the new system. Input will be required from many parts of the organizations to fill in the detailed requirements (similar to Software Requirement Specifications document). It is this input from throughout the organization that makes the requirements reflective of the organization. The defining of the project charter and defining of requirements should be completed before the ERP project is officially started. 3. Review As Is and Create To Be It is necessary to make sure that all business processes are in place and supported with documentation before the ERP system is implemented. To construct processes to either support software after the implementation, or to design business processes during implementation is a clear recipe for disaster. “Review As Is/Create To Be” means to review the current business processes (As Is) and define any desired changes or new processes (To Be) that the organization would like to put into place. Reviewing As-Is processes serves two major purposes. The first is that gaps in existing functionality and missing processes come to light. This exercise can be considered a gap-analysis for comparison with the To-Be design. This forces to the forefront any processes or procedures that conflict with the business and gives visibility to make sure that any new process are compatible. The second phase of this exercise is to define the To-Be i.e. the way the functionality of the system will interface with the business processes. This is where the possibilities of the new system come into reality. It is at this point in the project that the users of the system can put forward their ideas on how the system should be. 4. Use of Education and Training The training that is provided by the software vendor is one of the most critical elements of risk in the ERP implementation. The project manager must make sure exactly what kind of training is going to be provided before the contract is signed. Many software vendors use test data in the education of their software. This test data more often than not consists of products and items that do not reflect what the customer makes and many times will not have any resemblance to the working environment of the customer.

Training should be done using real company data in a test environment to simulate the ERP package software running the business. This means loading a subset of the items, bills-ofmaterials, routings, customers, suppliers, etc. into a test environment for simulation with the ERP software. By loading the actual data, the user has a look and feel of the information that they use every day and any gaps in the software will be much more visible. This method combines the software-training phase with prototyping. The user learns the software while testing with data that is used in the business. The added benefit is that, in many cases, a total of up to six weeks can be shaved from the implementation timeframe by using this technique. This is based on an implementation timeframe of six months or more. The time saved can be put into other areas of the project such as Conference Room Pilot, etc. It not only saves time, money, and reduces the risk of project failure; it provides a much more comprehensive and cohesive way to introduce the user to the software. 5. Business System Test or Conference Room Pilots The definition of the Conference Room Pilot (CRP) is a trial run of pre-defined business processes through the new system in a test environment using real business data from the organization. The CRP is designed to be the final verification that the new system is set-up correctly to function in the live business environment. It is also the last chance to test the people and processes that are going to support the system before going live. The CRP can last anywhere from a couple of days to a couple of weeks. The general rule is that the larger the system and the more functionality being installed, the longer the CRP. All functions, plants, and personnel should take part in the CRP. The Conference Room Pilot should be conducted by the end users of the software with as little assistance as possible by the implementation consultants. The ability of the software to successfully conduct business should be shared with end user and senior management alike. A successful CRP sets the stage for transition into the cutover phase.

6. Execute Timely Cut-over After all of the analysis, education and testing of the new ERP system, a decision is made to begin the go-live process and cutover. Cutover means that data from the legacy system is moved into the new ERP system. Parameters are set, interfaces completed, end user education is completed, and final system preparations are carried out to support going live. This phase of the project carries perhaps the greatest risk to project management. Once the conversion begins, a company is committed to going live and any slippage of the cutover schedule has a financial price that will have to be paid. A clear schedule must be defined in advance and carried out to exact detail to assure success of this phase of the project. One of the biggest problems that occur in this phase is the mapping of data. In many cases the data is mapped in advance from one system to another then automatically loaded. This is a good technique that can run into serious problems if the mapping i.e. matching of information fields from one system to another is not correct. Other issues such as when to stop production, when to stop taking of sales orders in the legacy system are other timing issues that will have to be decided to effectively manage ERP Implementation 7. Going Live and Beyond After the Go-Live, People within the organization now consider the implementation a success and the ERP implementation team has been disbanded. In many organizations that have just gone live on a new ERP system this is the scenario. The reality is that the real work is just beginning. The ROI and goals that had justified the purchase the system has yet to be achieved. In fact, it may be months before any detectable signs of improvement are noticed. It is well known that when any new task or activity is learned, that a period of inefficiency occurs as part of the learning curve. As the activity becomes more familiar to the person performing the task, the previous efficiencies return. When a new enterprise-wide business system is implemented at a company, a learning curve happens, but on a much larger scale. If the scale of the change is large enough in a company, a different and more complex phenomenon occurs.

A learning curve does occur on an individual level, but also a sharp decline in performance metrics can also occur at the company level. This phenomenon of declining performance at the company level is sometimes referred to as the ‘Valley of Despair’. This valley describes a fall in performance metrics followed by a slow rise to previously established performance levels. The ‘Valley of Despair’ is a natural reaction to a major change that occurs at the company level when the new business system is implemented. But it can be lessened and managed with the setting of proper expectations during the initial stages itself. A few major areas of concern for Project Management (4) are 1. Deciding On Project Scope Scope management procedures must also be created and enforced to prevent "never ending project" syndrome. Constant scope changes, whether increases or decreases, cause confusion among project team members. If the project scope is not defined properly, required work is missed, jeopardizing the project success. On the flip side, work outside the scope of the project may be done, hurting the budget. The scope of an ERP project has several components. The ERP project team must decide which business processes will be included in the implementation. If an organization has more than one business unit or line, the team must decide which divisions and technologies need to be included in each phase of the rollout. To prevent scope problems, the project charter or mission statement is used. Also, clearly define change control procedures and hold everyone to them. 2. Managing Risk on ERP Projects Managing risk on an ERP project is crucial to its success. To keep the failures at bay there are generally 5 steps to managing risk: a. Find potential failure points or risks b. Analyze the potential failure points to determine the damage they might do c. Assess the probability of the failure occurring

d. Based on the first three factors, prioritize the risks e. Mitigate the risks through whatever action is necessary One of the easiest and most effective ways to find potential failure points is to talk to other organizations that have done the same projects. Cost estimates are probably the most common potential project failure point. Other potential failure points include lack of an executive sponsor, an under-qualified project manager and no clear objectives for the project. Assessing the likely impact and the probability of the failure requires in-depth knowledge of both the ERP package and the business. A risk management team should be built that brings together those individuals that have the knowledge and experience to know what might happen. Based on the first two factors decide which risks should be eliminated completely, because of potential for heavy impact on critical business processes. Set up a monitoring plan for risks that should have regular management attention and make the entire team aware of those risks sufficiently minor to avoid detailed management attention, but which the team should watch for potential problems. Risk Mitigation can be done by reducing either the probability or the impact. The probability can be reduced by action up front to ensure that a particular risk is reduced. The project risk plan should include a set of steps to recover from each risk, should failure occur. The team must know the person accountable for recovery from each specific risk, and the action to be taken to resolve it. 3. The Right Staff It is absolutely critical to get the right people involved early. Each business area with which the ERP software will communicate must be involved. A project manager can develop recognition programs that help retention. ERP projects can be long and frustrating so it is also helpful to set up events for employees to communicate and vent about the working environment. Another trend is to implement flextime to allow employees greater flexibility in setting work hours within limits.

4. Preventing Brain Drain Another problem faced by ERP project managers is the need to integrate consultants with corporate staff and ensure a smooth knowledge transfer when the consultants leave. This can be done by pairing up consultants with corporate employees in both technology and business areas. The consultants and corporate staff work side-by-side throughout the implementation thereby ensuring a nearly constant flow of information from consultants to corporate staff, and prevent the "knowledge drain" that usually occurs when consultants roll off projects. A method to offset the troubles caused by brain drain is to document each and every step of the implementation so that in case any key person leaves, his replacement will be able to quickly come up to speed and takeover. Also, back-up plans need to be put in place so that the backup for each role can be identified in case of such issues. Other method like incentives, salary increase and providing accelerated career growth can be adopted, 5. Monitoring Progress Project Managers must create very specific work assignments for software developers. They should schedule technical and management reviews at least once a week and track progress carefully against the original plan. It's also important to do a project review at the end of each phase and the project as a whole. Success criteria for ERP projects are frequently inadequate or even non-existent. The success criteria should be clearly defined in the procedures, methods, and techniques that are part of a high quality project control system. Standards and techniques for measuring the quality of performance expected from the new system should be defined early, and redefined as needed over the life of the project.  6. Managing Chaos Managing an ERP project is a huge effort because of the number of variables, people and risks involved. The complete replacement of an organization's information systems has a tremendous impact on the people in the organization, the company, its suppliers and even its customers. An ERP project manager must guide the project with a firm hand that both encourages and motivates project team members and ensures that everyone and everything is

moving in the right direction. An ERP project manager must possess an intimate understanding of the business and how it will change when the ERP system is rolled out, and must also have a solid technical foundation.

Agile Project Management (PM) Methods This is a recent trend in PM for ERP Implementation. In today’s world of faster time to market pressures, rapidly changing requirements, the Internet, and powerful programming languages, there is a need to bring in developments like ERP faster so as to grab competitive advantage. \ Wikipedia defines Agile methods as “promoting a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.”. Any agile process must include three major attributes (7) •

Incremental, Iterative, and Evolutionary – allowing adaptation to both internal and external events.



Modular and Lean – allowing components of the process to come and go depending on specific needs of the participants and stakeholders.



Time Based – built on work cycles, which contain feedback loops, checkpoints, and guidance on using this information in the next cycle.

Applying Agile Principles Assume Simplicity – As the project evolves the simplest solution is best. Overbuilding the system or any artifact of the project must be avoided. The project manager should have the courage to not perform a task or produce an artifact that is not needed for the immediate benefit of the stakeholders.

Embrace Change – Since requirements evolve over time, the stakeholder’s understanding of these requirements evolve as well. Project stakeholders themselves may change as the project makes progress. Project stakeholders may change their point of view, which in turn may change the goals and success criteria of the project. These changes are a natural part of an ERP project and processes must be able to accommodate them. Enabling The Next Effort – The project can still be considered a failure even when the team delivers a working system to the users. Part of fulfilling the needs of the stakeholders is to ensure the system is robust enough to be extended over time. Incremental Change – The pressure to get it right the first time can overwhelm the project. Instead of trying to develop an all–encompassing project, incremental developments i.e. develop a small portion of the system. Maximize Stakeholder Value – The project stakeholders are investing resources, time, money, facilities, and etc. to create a system to meet their needs. They will expect a return on this investment. Manage With A Purpose – This can be done by creating artifacts that have stakeholder value. Multiple Project Views –There is need for a wide range of presentation formats in order to effectively communicate with the stakeholders, participants, and service providers so as to ensure acceptability of the ERP system. Rapid Feedback – The time between an action and the feedback on that action must be minimized. For this the project manager must work closely with the stakeholders, to understand the requirements, to analyze those requirements, and develop an actionable plan, which provides numerous opportunities for feedback so as to minimize rework. Working Software Is The Primary Goal – Not the production of extraneous documentation, software, or management artifacts. Any activity that does not directly contribute to the goal of producing working software should be examined to determine its value. Travel Light – Since every artifact must be maintained over its life cycle, the effort needed to maintain these artifacts must be balanced with their value.

SME Vs Large Enterprises The obvious difference between SMEs and LEs lie in the obvious leverage LEs have in terms of resources like money, people etc. Studies (1) (5) (6) have suggested that 1. SMEs experience more knowledge constraints than LEs in ERP adoption. 2. SMEs differ from LEs in important ways affecting their information-seeking practices that impact information and technology (IT) adoption. These differences include lack of information systems management, concentration of information-gathering responsibilities to a small number of individuals, lower levels of resources available for informationgathering 3. There is a lack of knowledge and expertise, with respect to project management, in how modification, feedback and management should be made and organized to enable ERP systems implementation. From this, one can see that in terms of project management, which is but one of the critical success factors in ERP, SMEs and LEs differ widely. SMEs are subject to much more constraints and ERP project management should be tuned in to these restraints and develop plans accordingly.

An Example for ERP Implementation Failure due to PM I was able to see a good example of the ERP implementation failure due to ineffective project management (PM) in my SIP organization (AIG). Almoayyed International Group (AIG), established in 1979, is a global business group with a wide range of interests in Information Technology, Business Automation, Integrated Engineering Solutions, Safety and Security, Ironmongery and Fabrication, Electrical and Instrumentation Solutions, Packaging, Freight Forwarding and Logistics Services. AIG has split its operations into diversified business sectors, mainly Almoayyed Computers, Almoayyed Commercial Services, Almoayyed Trading and Contracting, Almoayyed Safety and Industrial Centre, Apple Centre, Almoayyed Ironmongery and Fabrication Services, Almoayyed Electrical and Instrumentation Systems, Almoayyed-AGIL and Freight Logistics and Season

International Trading apart from its operations in other GCC countries. Its main area of operations is in the Middle East and it has forged alliances with the major players in each network and serves as the main dealer for their products in the Middle East. The company had decided to go in for Oracle ERP and implemented the financial module first. However, they saw ERP as just a software instead of appreciating the change it brought to the organization. No proper training was provided to the end-users and they were also not included in the testing of the ERP also. Also, after implementation, some of the employees who were familiar with ERP left the organization which adversely affected them. Scheduling of ERP implementation was too short (5 to 6 months) which did not take into consideration the factors listed above, The company lacked any previous experience with ERP and as a result did not have enough domain and technology expertise to go forward with it. They had recruited fresh people and consultants to implement ERP. However, from whatever I was able to understand, this had caused a friction between the managers and the implementation team. As a result of this, there was a huge resistance to change and a lot of grumbling was going around regarding why they should use the new ERP system.

Conclusion The focused management of the above mentioned activities by the ERP project manager will enhance the success of any ERP project. Placing a major focus on these activities and setting expectations around them will help create a sense of direction within the project and organization that may not otherwise occur. Assuming the software purchase is viable for running the business, unsuccessful projects can be traced back to an activity mentioned above that was not well managed.

References 1. “Experiences of ERP Use in SMEs” by Paivi Iskanius 2. “A model of ERP project implementation” by Anne Parr 3. “ERP Project Management – An Activity Based Approach” 4. “ERP Project Management is key to a successful implementation” by Charles Trepper 5. “The ERP Project Risk Assessment – A case study” 6. “Critical Success Factors of ERP Implementations in Belgian SME’S” by Claude Doom and Koen Milis 7. “Agile Project Management Methods for ERP: How to Apply Agile Processes to Complex COTS Projects and Live to Tell About It” by Glen B. Alleman

Related Documents