Enterprise Resource Planning (ERP) systems have fundamentally changed the work of IT organizations. The sheer size and complexity of ERP implementations makes managing these projects difficult. There are really two basic sides- managing people and implementing technology. An ERP package touches the entire organization and can affect nearly every employee. And in some cases, an ERP project manager may not be able to know who will be affected, which can lead to some nasty surprises. One mismanaged ERP implementation left a southeastern electronics manufacturer unable to accept deliveries and nearly closed a plant. It's also difficult to get a clear vision of the technological portion of the implementation because of the vast combination of hardware and software involved.
Whether the project manager is implementing one module or multiple modules, s/he must ensure consistency and full integration across the various sub projects, which is an enormous effort, even for an experienced system architect.
A list is presented below on the basis of a survey of experienced ERP project managers from various corporate IT departments and Big 5 consulting companies, and assembled an unofficial list of the major problems faced by ERP project leads and managers. Almost everyone mentioned size first. Staff problems and organizational politics also ranked in the top ten.
- Project Size 2. Staffing (Includes Turnover) 3. Risk Management 4. Unreasonable Deadlines 5. Funding 6. Organizational Politics 7. Scope Creep 8. Unexpected Gaps 9. Interfaces 10. Resistance To Change
Lifecycle of ERP Implementation/ Phases of ERP Implementation Project:
An ERP Implementation Project Lifecycle generally includes the following phases.
⇒ Pre-evaluation Screening
⇒ Package Evaluation
⇒ Project Planning Phase
⇒ Implementation Team Training
⇒ Going Live
⇒ End-user Training
Pre-evaluation Screening: When the company has decided to implement the ERP the search for the convenient and suitable ERP package begins.
Package Evaluation: The objective of this phase is to find the package that is flexible enough to meet the company’s need or in other words, software that could be customized to obtain a ‘good fit’.
Project Planning Phase: This is the phase that designs the implementation process. Time schedules, deadlines, etc. for the project are arrived at. The project plan is developed in this phase. In this phase the details of how to go about the implementation are decided. The project plan is developed, roles are identified and responsibilities are assigned.
Once the packages to be evaluated are identified, the company needs to develop selection criteria that will permit the evaluation of all the available packages on the same scale.
- Gap-Analysis Flexibility and scalability
- User friendliness
- Quick implementation
It is better to have a selection committee that will do the evaluation process.
This phase will also plan the ‘What to do’ in case of contingencies; how to monitor the progress of the implementation; The phase will plan what control measures should be installed and what corrective actions should be taken when things get out of control.The project planning is usually done by a committee constituted by the team leaders of each implementation group headed by CIO.
Gap Analysis: This is the most crucial phase for the success of the ERP implementation. Simply it is the process through which companies creating a complete model of where they are now, and in which direction they want to head in the future. The trick is to design a model which both anticipates and covers any functional gaps. Some companies decide to live without a particular function.
Other solutions include:
- Identify the third party product that might fill the gap
- Design a custom program
- Altering the ERP source code, (the most expensive alternative; usually reserved for mission-critical installation)
Re-engineering: This phase involves human factors. In ERP implementation settings, re-engineering has two connotations. The first connotation is the controversial one, involving the use of ERP to aid in downsizing efforts. In this case ERP is purchased with aim of reducing the number of employees. Every implementation will involve some change in job responsibilities as processes become more automated and efficient. However it is best to regard ERP as investment and cost-cutting measure rather than a downsizing tool. ERP should endanger business change but not endanger the jobs of thousands of employee.
The second use of the word ‘re-engineering’ in the ERP field focuses on the Business Process Re-engineering (BPR).
The BPR approach to an ERP implementation implies that there are two separate, but closely linked implementations-
- Technical Implementation
- Business Process Implementation
The BPR approach emphasizes the human element of necessary change within organizations. This approach is more time consuming and has received a lot of criticism for creating a big budget and extended projects. But those who support it argue that you cannot ignore human element.
Configuration: This is the main functional area of ERP implementation. The Holy Grail (unwritten rule) of ERP implementation is, synchronizing existing company practices with the ERP package rather than changing the source code and customizing it to suit the company. In this case business process has to be understood and mapped in such a way that the incoming ERP solutions match up with the overall goals of the company. It is not required to shut down company operations while you do a mapping process. Instead a prototype (a simulation of the actual business processes of the company) will be used. The prototype allows for thorough testing of the “to be” model in a controlled environment. Configuring the system reveals both the strength and the weaknesses of the company business processes. It is important for the success of ERP implementation that those configuring the system are able to explain what won’t fit into the package where the gaps in functionality occur. ERP vendors are constantly make efforts to lower configuration costs. Strategies that are currently being done include automation and pre – configuration.
Implementation Team Training: Synchronously when the configuration is taking place, the implementation team is being trained. This is the phase where the company trains its employees to implement and later, run the system. For the company to be self-sufficient in running the ERP system, it should have a good in-house team that can handle the various solutions. Thus the company must realize the importance of this phase and selects right employees with good attitude.
Testing: This is the point where you are testing real case scenarios. The test cases must be designed to specifically to find the weak links in the system and these bugs should be fixed before going live.
Going Live: This is the phase where all technicalities are over, and the system is officially declared operational. In this phase all data conversion must have been done, and databases are up and running; and the prototype is fully configured and tested. The implementation team must have tested and run the system successfully for some time. Once the system is ‘live’ the old system is removed and the new system is used for doing business. The implementation team must have tested and run the system successfully for some time. Once the system is ‘live’ the old system is removed and the new system is used for doing business.
End-user Training: This is the phase where the actual users of the system will be trained on how to use the system. The employees who are going to use the new system are identified and their skills are noted.
Based on their skill levels are divided into groups. Then each group is given training on the new system. This training is very useful as the success of the ERP system is in the hands of end-users. The end-user training is much more important and much more difficult than implementation team training since people are always reluctant to change.
Post-implementation: This is the very critical phase when the implementation phase is over. There must be enough employees who are trained to handle the problem that might be occurred when the system is running. There must be technical people in the company who have the ability to enhance the system when required. Living with ERP systems will be different from installing them. Projects for implementing the ERP systems get a lot of resources and attention. However an organization can only get the maximum value of these inputs if it successfully adopts and effectively uses the system.
We can show the whole steps and activities through a model called “V- Model”
Strategies of ERP Implementation
The following table is showing integration among “Steps of ERP Implementation Project” and “Strategies of ERP Implementation Project”.
|1. Strategic Planning||2. Procedure Review||3. Data Collection and Clean-Up||4. Training and Testing||5. Go Live and Evaluation|
|Assigning A Project Team||Reviewing Software Capabilities||Collecting and Converting Master Data||Pre-test the Database||Develop A Final Go-Live Checklist|
|Examining Current Business Processes and Information Flow||Identify Manual Processes||Master Data Cleansing||Verify Testing||Evaluate the Solution|
|Setting Objectives||Develop Standard Operating Procedures||Master Data Migration||Train the Trainer|
|Developing A Project Plan||Adding New Data||Performing Final Testing|
Big Bang Approach:
- In Big Bang integration testing, all components or modules are integrated simultaneously, after which everything is tested as a whole.
- In this approach individual modules are not integrated until and unless all the modules are ready.
- In Big Bang integration testing all the modules are integrated without performing any integration testing and then it’s executed to know whether all the integrated modules are working fine or not.
- This approach is generally executed by those developers who follows the ‘Run it and see’ approach.
- Because of integrating everything at one time if any failures occur then it become very difficult for the programmers to know the root cause of that failure.
- In case any bug arises then the developers has to detach the integrated modules in order to find the actual cause of the bug.
Phase by Phase Approach: A phased approach is based on the principle that any project may be broken down into a series of steps i.e. phases. Each phase has a clear start point, some well-defined tasks, and a defined end point. It is usual to review each phase to enable those responsible for the project to make informed decisions about what to do next and why. The end of a particular project phase will often be the production of a particular deliverable. The deliverable can be a document such as a progress report, or a tangible product such as an architect's model of a building.
The benefits of using a phased approach include:
- reducing risk by working through the project step by step
- ensuring the involvement of the right people at the right time with the right tasks
- reducing the complexity of planning and control by adopting a two-level planning approach
- maximizing control through the use of formal phase reviews
- encouraging careful specification of requirements
- encouraging the breakdown of work into understandable packages.
Waterfall Approach: Waterfall is a linear approach to development. In this methodology, the sequence of events is something like:
- Gather and document requirements
- Code and unit test
- Performing system testing
- Performing user acceptance testing (UAT)
- Fix any issues
- Deliver the finished product
In a true Waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin. There is also typically a stage gate between each; for example, requirements must be reviewed and approved by the customer before design can begin.
Vanilla Approach: An approach to investing or to business decision-making that is basic and common. Some investors and businesses excel because they choose an ordinary, vanilla strategy, while others succeed through innovation. In derivatives trading, a vanilla strategy is the use of two different plain vanilla instruments, such as swaps, at the same time.
Oracle Application Implementation Methodology (Oracle AIM): The Application Implementation Methodology (AIM) for Oracle Financial Services Analytical Applications is designed to effectively plan and manage Oracle Financial Services implementations for Risk and Regulatory Compliance. This methodology, offered by Oracle Financial Services Consulting, is executed in phases, providing a systematic and end-to-end approach for implementation. It addresses planning, managing, execution, design, construction, testing, and support. The Application Implementation Methodology for Oracle Financial Services delivers high-quality data to facilitate improved decision making.
The implementation phases of AIM include:
- Start-up:This phase ensure that the basic prerequisites for onsite implementation are accomplished. These activities need to be understood by the user and implementation teams before initiating implementation.
- Information study:This phase involves gathering information on a customer's current business operations and their OLTP systems. It also addresses collecting information based on the requirements specifications and source extraction specifications.
- Harmonization:This phase involves integrating Oracle Financial Services Analytical Applications with the customer's information needs and addresses customization requirements.
- Testing and Go Live:This phase ensures that the system is ready to go live, when the system functions meet customer specifications.
Success Factors of ERP Implementation
The following factors play major role in ERP Implementation:
- Strong Executive Sponsorship
- Focused Project and Scope Management
- Minimize / Eliminate Customization
- Approved Solution Design
- User/SME Participation and Engagement
- Process Owner Led User Training and Sign-off
- Documented User Procedures
- Targeted Data Migration Strategy
- Thorough System Testing
- Knowledge Transfer
Roadblocks of ERP Implementation
The main obstacles of ERP Implementation are described below:
- Resistance to Change: It is true that implementation of an ERP means change. The basis of ERP is a complete remodeling of the company’s business processes. Change on this level isn't comfortable and it will produce resistance. Part of the ERP implementation process is meeting and overcoming the resistance to change. Without that, the ERP process will fail no matter how technically successful the implementation is.
- Inadequate Sponsorship: A successful ERP implementation needs strong, consistent support from the top of the organization. Without that the implementation may lack the drive to push through the inevitable barriers/roadblocks.
- Unrealistic Expectations: ERP isn't a silver bullet that will solve all the companies’ problems and it isn't easy to implement. It's important that the organization’s expectations don't outrun the reality of ERP.
- Poor Project Management: A project as complex as implementing ERP needs competent project management. This usually means assigning an experienced project manager to ride shotgun on the project full time. Not having effective project management makes it very hard for an ERP project to succeed.
- No Compelling Case for Change: ERP means change, big change. There has to be a clearly understood need for change to drive the ERP implementation forward. If there is no good reason to change, or, more commonly, if the case for change isn't effectively communicated, it is very hard to keep the momentum necessary for an effective ERP programmer.
- Project Team Lacks Skills: The people working on the project must be capable of handling the project, both the IT part and the business parts. One of the most common failings is to consider an ERP implementation as an IT project and try to let IT run everything. This does not work because the IT department is limited in view and in business related skills. The project team needs a much broader perspective and skill set.
- Scope Creep: While you can't know everything in advance, you should have the scope of your ERP implementation well-designed well before you begin. Changing requirements in the middle of the project adds time, money and confusion to the project. You can realistically expect to make some changes, but strive to keep them as minor as you can.
- No Change Management Program: Fundamentally, ERP is about business process change. Without changes in the way you do things, you'll get only minimal benefits from an ERP implementation, no matter how “successful.” Change doesn't happen naturally. It has to be actively managed and a large part of an ERP implementation is managing change in a consistent, systematic manner. It's important that the process for handling changes to business processes is laid out at the beginning of the ERP effort and that it is adhered to throughout the process.
- No end to end Process View: The implementation team needs to focus on the entire process, not just concentrate on certain areas. It is important that the people leading the effort have a full 360-degree view of the implementation process and keep all aspects of the project in mind at all times.
- IT Perspective Not Integrate: This is the opposite of putting the ERP implementation under the IT team and it is equally a barrier to a successful ERP project. Here IT is mostly ignored in favor of emphasis on other parts of the project. IT may not be the totality of the ERP implementation, but it plays a vital role and IT considerations can't be ignored.
Barriers/Roadblocks to ERP implementation have to be recognized and overcome in order to have a successful project. The first step is to recognize the barriers/roadblocks. The next step is to deploy your team in such a way that the barriers/roadblocks can be overcome.
Why most of the Projects Fail?
You may be wondered but it is true that 72% of projects fail due to some common reasons. The reasons are very common and not too difficult to solve.
Let’s have a look on those problems:
|1. Poorly Managed||2. Undefined Objectives and Goals||3. Lack of Management Commitment|
|4. Lack of a Solid Project Plan||5. Lack of User Input||6. Lack of Organizational Support|
|7. Centralized Proactive Management Initiatives to Combat Project Risk||8. Enterprise Management of Budget Resources||9. Provides Universal Templates and Documentation|
|10. Poorly Defined Roles and Responsibilities||11. Inadequate or Vague Requirements||12. Stakeholder Conflict|
|13. Team Weaknesses||14. Unrealistic Timeframes and Tasks||15. Competing Priorities|
|16. Poor Communication||17. Insufficient Resources (Funding And Personnel)||18. Business Politics|
|19. Overruns of Schedule and Cost||20. Estimates for Cost and Schedule are Erroneous||21. Lack of Prioritization and Project Portfolio Management|
|22. Scope Creep||23. No Change Control Process||24. Meeting End User Expectations|
|25. Ignoring Project Warning Signs||26. Inadequate Testing Processes||27. Bad Decisions|