If it’s time to replace your existing legacy system with a new Enterprise Resource Planning system, the choices available may seem overwhelming. Your business needs one of the top ERP systems, but which one? There is no one checklist to choose ERP. An experienced ERP Consultant, organizing and researching during the ERP selection process, can lessen the frustration, and get the project moving. Pilotcount Business Solutions is just such a resource. An independent, technology-agnostic consultant that is not obligated to any software vendor or hardware manufacturer, is what the project requires to avoid the risk of taking the cheapest product, or the one with the most personable sales representative. We will bring proper methodology to the table and lead your team through a well-organized process to help you arrive at the best decision for you and your organization. The process includes the below areas of consideration:
-
Guidance in creating a business case for evaluating the software.
-
Ensure the software you ultimately select supports your strategic business goals.
-
Creation and issuance of Requests for Proposal, and/or Requests for Information.
-
Help determining what ERP functionality is required for a successful go-live.
-
What features can be added later as part of your wish list of enhancements.
-
Providing you with a vendor evaluation model that reflects your priorities, and supporting your team in making the final selection.
The approach will vary based on the business, the personal experience and observations of your staff and the decision support consultant. Whether ultimately the best system for you is cloud ERP, on-site ERP, or open source ERP, we’re there for you. Smaller businesses often choose cloud based ERP or open source as a Legacy alternative because of the lower initial cost and faster implementation time. Medium to large businesses often select traditional, on-site software for the greater functionality. Either way, we’ll help you make the best choice.
Selection Process
You will, of course, also need a project manager to oversee the ERP implementation process, and Pilotcount can handle that as well.
The project “Kickoff” will charter the project, gather basic company information, and introduce the client’s team to the selection process. Some of the project items to be reviewed will be:
-
Goals
-
Scope
-
Timeline
-
Roles and Responsibilities
-
Expectations
-
Communications
-
Questions
An internal “champion” will be selected for the project. This should occur at the beginning of the system selection project to ensure their commitment and agreement with the system selected. In addition, functional leads and training “super users” will be assigned.
One of the most important questions to be answered is, “Are you organizationally prepared for the selection and implementation”?
Key personnel will be interviewed and a business case will be created to develop a vision for the future system, along with anticipated costs, benefits, and ROI. Infrastructure will be assessed and discussed, as will organizational readiness, including organization preparation, communication, and training. Among the topics are:
-
What business challenges do you expect ERP to solve?
-
What necessary functionality do you think your current system is missing?
-
What are the key issues and concerns with the current system?
-
How will we define success for the new ERP system?
-
Software Requirements Analysis
Based on the interviews with key personnel, a more detailed Software Requirements Analysis, or Needs Analysis will be created to define a complete set of key functional requirements and operational constraints as criteria for selection. We will document and prioritize your unique business requirements.
It’s very important to get employee involvement in the process. A significant amount of knowledge exists, no doubt, only in the heads of the employees. Their input will be crucial. Not only are they the only ones with some of the information, but it’s essential to include them in the process to secure their buy-in for the endeavor.
We will also decide together which modules and functions are part of the initial implementation, and which ones can and should be implemented after go-live, in a “phase 2”.
Next, a “Long List” of software vendors will be created using our research tools, industry publications we monitor, our ERP contacts, and so forth. Large general vendors as well as smaller vertical market specific vendors will be considered.
In most cases, lengthy Request for Proposal’s (RFP) are usually unnecessary, because ERP software in general is standardized, and most systems handle the basic functions well, but it is important to insist that the company’s unique set of business needs and requirements be documented. It is then that a Request for Information should be sent to the “long list” of vendors. Some of the questions to consider are:
-
What are the different levels of support plans offered by the vendor?
-
What is the availability of after-hours support?
-
What on-going services should you require from your ERP vendor?
-
What response times can the vendor promise?
-
Is the vendor experienced and comfortable with companies of similar size?
-
What deployment options are offered? (Software-as-a-service, or on-site)
-
Is there a one-time license fee, or do they charge by monthly subscription?
-
Does the vendor have special expertise in your industry?
Based on our review of the various vendor responses, Pilotcount will prepare a “short list”. We will also engage with software vendors and resellers for considering:
-
Insight into their value addition and experience.
-
Interest in the project.
-
Reasons and after sales support.
Together, we will meet with and screen the shortlisted candidate vendors, and ask them to demonstrate how their software fits your business, using the customized demo script which we will prepare based on the needs analysis. We will ask each vendor to show, step-by-step, how its software can accomplish the most difficult and time-consuming processes. This will help us assess the product’s look and feel, learn about the company, and verify the first impressions we may have formed during the research. If software modifications are required to accomplish these processes, the vendor should indicate exactly how it can be done, and how expensive it is likely to be.
Keep in mind that vendors who can quickly understand what your business requires, and can determine a relatively easy-to-accomplish change on the spot, may well be the best, and least expensive choice in the long run. These situations will be encountered many times during implementation, and a group who can get past them easily is invaluable. This skill is often particular to an individual rather than to the company. We need to make sure that we will be working with the right person(s). Many businesses try to reach a purely quantitative conclusion, but ultimately it comes down to which vendor will be the best cultural fit. We will need to decide which of the vendors you feel most comfortable moving forward with.
When calculating ERP deployment costs, they should always be calculated over a period of between five and ten years. Ten years is recommended since companies generally rely on their ERP system for at least that long. The evaluation will be based on the Total Cost of Ownership (TCO) approach.
Now is the time to use the leverage we have. Once the contracts are signed, future discounts are much more difficult to achieve. As soon as you implement the ERP, you’re locked in. It’s usually prohibitively expensive to switch ERP systems, and the vendor knows it. We never have more negotiating power than we do before the deal is signed. Our negotiation expertise will most often will save you more money than our fee.
The long-term operating cost of the ERP software is of special interest in the selection process. The software’s upgrade path is vital to the discussion. We will insist that the vendor disclose the real cost of future upgrades. The total cost of some ERP system upgrades can be extremely expensive because their software architecture requires that all programming modification be redone on the new version. Programming modifications should be undertaken with this topic in mind.
Of fundamental importance when selecting an ERP system is the economic stability of the ERP vendor, and its future strategy. The support structure and ongoing software development have to be ensured over many years.
After the results are evaluated, references verified, prices and contracts negotiated, and budget finalized, the winning vendor is selected. Keep in mind that if we have followed the plan, we’ll probably be selecting among two or three vendors who can all satisfy the requirements. While it is very important to follow the right process and not to decide just on gut feel, this part of the process is often “splitting hairs”. It may all come down to who is trusted more, or who is more local.
The guidance of our expert ERP Selection Consultant will maximize the likelihood that the new system will be selected and implemented with the least possible business interruption, at the least possible cost, and in the shortest timeframe.
In order to achieve another successful implementation, Pilotcount Business Solutions employs the strategy which follows. Every client’s business is different, however, and the process is customized for each client so that we not only realize a successful implementation, but that we do it in the shortest possible time, and the least possible investment.
Project Management Process
We will discuss these questions, and make sure each has been addressed in the best way possible.
-
Why are you implementing a new ERP application? The most important business reasons for implementing a new application should be identified. The Core Team leaders must understand the motives.
-
Has an evaluation and/or analysis of various ERP applications been conducted?
-
Have stumbling blocks to beginning an implementation project been discussed and identified?
-
What are the final expectations of an implementation project? Functionality, technology, performance
-
How long do you expect the implementation project to take?
-
Has sufficient time been allocated to the project during the implementation? Team leaders should be in agreement that the timeframe will be met. Pilotcount will employ a sophisticated estimation tool to arrive at the expected timeframe.
-
Has a budget been drafted or approved for the project?
-
What does that budget cover?
-
Are people ready for the change?
Recognize that change will be an issue for people. There are three phases of change – ending the old ways, an intermediate “neutral” zone, then creating the new beginning. People’s readiness to change happens at different speeds. “Innovators” and “Early Adopters” will be the quickest to adapt to change, then there is an “early” and “late” majority, and there will always be “skeptics” who are slow to change. Understanding the reasons behind resistance to change is the key to a smooth transition so these reasons can be addressed in a positive and structured way. Awareness, buy-in and ownership mark the changes in attitude as people take on responsibility and become committed to the success of the project.
-
Project Management Consultant (Pilotcount Business Solutions)
Pilotcount will be your project management consultant. We will create, manage, and publish the project schedule, task list, and other communications. It is also very important that we create formal documentation of processes unique to the organization, including step-by-step instructions showing how they will be accomplished with the new software. -
Implementation Core Team
The Core Team should consist of a cross functional group that understands your business, the project goals and knows the history of the organization. -
Systems
Determine what systems and procedures are required to support the new application. What interfaces are required to other applications? -
Business Processes
Verify that current processes are documented. These will be the baseline to determine how well the new application meets your business requirements and how the new application will impact current processes.
-
Scope Management
The scope of the project should be defined before it begins (for example, will Business processes be changed as part of the implementation, will new modules be implemented, what data will be converted, etc.) -
Communication
Pilotcount will coordinate communication between client team members, ERP vendor personnel, network support personnel, and third party vendors, to ensure that all parties know what is expected of them and when tasks and assignments are due. -
Risk Management
If the scope of the project changes, determine the associated risk to the timeline or budget. This must be clearly communicated to upper management. -
Business Process Impact Analysis
Determine how business processes will change with the new application. Some tasks may no longer be required, or workflows may be altered. Some of the people may be concerned for their jobs, and this must be addressed and handled diplomatically. -
Process Ownership
The Core Team should take ownership of their functional areas. Ownership includes communication, coordination with subject matter experts, and using their insights to identify how new functionality or processes will affect other departments and business processes.
-
Functional Overview Training. This is the initial, guided tour through the application for the Core Team. It facilitates activities including learning about the new application, system conventions, identifying/documenting high-level gaps, identifying and documenting business process changes, and more.
-
Formal Training For Super Users
During this phase, each functional area receives formal training. It normally includes “Super Users” who are part of the implementation team and are subject matter experts (SME). Formal training should include hands-on workshops. -
Conference Room Pilot Testing
This is one of the most significant areas of the implementation and is conducted at two levels: functional area and cross functional teams. It allows testing new functionality, identifying business process changes, proposing solutions, validating proposed business process changes, forms, and more. -
Critical Business Process must be tested and validated
During the conference room pilot, prototyping and adjustment toward final system must be accomplished. This includes testing, programming, bug fixing, and rework. Each item must be identified as either “must fix before live day”, or “can be fixed after live day”. -
Report Testing
Critical standard system reports must be tested by the Core Team. Gaps must be handled with reporting software such as Crystal Reports. At least one person must be designated as the person who will be writing reports on an ongoing basis. -
Documentation
One of the most valuable tools that the implementation team can have is documentation that is customized to fit your business environment. This is accomplished by each functional team validating and documenting their business processes throughout the testing phase. Standard documentation can be incorporated into this to make comprehensive user documentation guides. -
Data Migration
‘Clean’ data is another of the more significant requirements to a successful data migration. The data migrations should be coordinated with pilot testing and user training. -
User Training
This step is generally at the end of the implementation process, shortly before go-live. Training should be conducted by the implementation team and the “Super Users” using documentation created by the implementation teams. User training is best conducted after all business processes have been tested and validated, and after all customizations are in place. Training on the “conference room pilot” is always desirable.
In all the areas mentioned above, there are multiple approaches which will make them work best for a given business environment.
When Enterprise Resource Planning implementation projects first begin, it means the long purchasing cycle has finally ended. All those surveys, quotes, demonstrations, and evaluations are concluded. Everyone has their own idea of how great it will be to finally have a modern system. Upper management expresses their commitment to eliminate any barriers that may present themselves. There is usually a “kickoff” meeting, where estimated hours are revealed, and the time frame is outlined.
Unfortunately, reality soon creeps in. According to a study most ERP projects fail to be fully implemented even after three years. Many are not even “live” after that amount of time.
There are many causes for this to be true. In the next section, we’ll examine the most important ones.
Keeping track of the project through active Project Management is crucial. Unfortunately, many ERP implementation projects fail, or take much longer than budgeted for, because companies sometimes believe they can supervise the vendor’s implementation staff without the assistance of an outside consulting project manager. For many reasons, that is seldom the case. Pilotcount Business Solutions can manage the project and get it on track.
Rescue Plan
The eagle eye view shows only a few factors one needs to keep track of to produce a successful ERP implementation. They are functionality, resources, and schedule. If one is watching those factors carefully from a ground view, warning signs often appear.
Top 10 failure reasons:
-
Lack of cooperation
-
Management team members late for, or absent from meetings
-
Team members become reassigned to other projects
-
Core team members failing to achieve their project commitments on time (or at all)
-
Excessive functionality allocated to “phase 2”
-
Fluctuating project priorities by management
-
Mission creep
-
Ongoing schedule delays
-
Vague project status reporting
-
Non-availability of accurate plan-versus-actual budget
Analyse Your Implementation
Effective Project Managers recognize the signs of failing projects and address the root causes.
There are always underlying issues.
How many of these do you recognize from your implementation project?
-
Lack of accountability
-
Unrealistic projected completion dates
-
Delays caused by management postponing decisions on crucial issues
-
Postponements of project updates and/or status meetings
-
Core team members taking vacations at inopportune times
-
Project tasks seem to be low priority
-
Project manager given responsibility without authority
-
Upper management failed to get staff input before the system was purchased
-
Low morale
-
Excessive mention of how the legacy system is better or easier at certain things
-
Some users seem to be afraid for their job
-
Training issues
-
Infrastructure issues
-
Project status seems ambiguous
-
Excessive finger-pointing
-
Unclear implementation methodology
-
Constantly shifting project target dates
-
Unresponsive project management
-
Unclear or incomplete business requirements
-
Difficulty finding the owner of various issues
-
Project status reports are late or missing
-
Over budget with no end in sight
-
Project paralysis
-
Indefinite expectations
-
Lack of direction
-
Project sponsorship is low
If your project has more than a few of these problems, it could very well be in need of rescue. Once it is realized that the ERP project is at risk of failing, we must develop a plan to get back on track. The normal tendency is to continue, and hope that the project issues will somehow resolve themselves – often while looking for whom to blame.
Assuming the hardware and software are a reasonable fit for the business, Pilotcount Business Solutions will perform a focused assessment. A rescue plan can then be created if the project is believed to be worthy of saving. It is at this point that bringing in an unbiased outside resource can be of most value. It’s important to realize that the same forces impeding progress will also cause an assessment to fail. Let’s interrupt the project and evaluate the situation.
Prioritization, organization, sorting, and allocation for the project must be conducted by an independent and objective outsider. Internal resources have been at it for a long time, and have proven to be inadequate. Ordering them to do better is highly unlikely to succeed. Pilotcount Business Solutions will swiftly amass and analyze the facts and the situation, and tender a recommended course of action to upper management. The rescue package will be based on the input and requirements of the various business units. It must be comprehensive, and consider the culture of the company. An evaluation of the original project critical success factors, as well as any business change since the original project launch must all be factored in to this assessment.
Since Pilotcount Business Solutions will be new to the situation (a good thing), a new assessment of how the software needs to be adapted to suit the business is in order. Since a great deal of time has already been expended on the new system, and everyone is much more familiar with it, the new assessment will occur much more quickly than the original one.
We’ll also need to examine the financial situation, and perform a re-budgeting of the project. The money already committed, wisely or not, is in the past.
It’s now time to create a Rescue Plan. Based on our assessment, we’ll “reassemble” the manner in which the project will be managed. It’s highly important for all concerned to witness the quick, successful resolution of issues, especially at the beginning of the rescue. We make sure that everyone, for the first few weeks at least, plans on working as late as necessary. Nothing propagates success like success. This includes upper management whose quick decisions will be vital to the endeavor. There is not one checklist of items which will insure success. The approach will depend and vary based on personal experience and observations of the Pilotcount project manager. Your Pilotcount Business Solutions Project Manager must have the authority to make and enforce critical project decisions. Here are some of the steps we’ll require.
-
An action plan must be created and agreed to by all of the key players, including the software vendor.
-
Institute Project Management controls including a running list of both open and closed issues. The closed issue list serves to remind everyone of the progress being made.
-
There must be a regularly scheduled Project Status Meeting, with a specific agenda distributed ahead of time. Key players need the ability to add items to the agenda. It needs to be clear that meetings are mandatory. To that end, everyone should receive an Outlook reminder each week. It’s important to keep the length of the meetings to thirty minutes or less, and only review items of general interest. Additional breakout meetings should be scheduled for items pertinent to specific people. These meetings are best held immediately following the Project Status Meeting.
-
Requested programming changes must be channeled through the department managers, not the users. They must be quoted by programming, and approved by Pilotcount Business Solutions and upper management. Hours spent on each must be tracked and compared to the quote. Likewise, the completion dates must be tracked and compared to the estimate. It’s very important to consider future software versions when deciding if a change should be made. The manager requesting a change must formally approve each. (An email will do.)
-
One or two people opposed to change can cause serious damage to the project. The Pilotcount Business Solutions project manager must get to know everyone, and look for and deal with any potential problems. Upper management will be invaluable to this effort.
-
Training must be thorough, and confined to departmental “super users”, usually the manager. Attempting to train all the users will ensure that nobody in the department sees the entire picture. If the super user is unsure of exactly what each user does, and why, now is the perfect time to learn. If necessary, they will have to find the time to shadow each user for a day.
-
Some software functions are not mission critical. There should be a discussion among all the key players to decide which are better left to a “phase 2”. Make sure that a phase 2 list is published and available to everyone in order that nothing is forgotten.
-
Consolidate all documentation on a common server and create a shortcut for everyone.
-
Make sure that the software vendor is aware of, and on-board with all of the above. They may need to reallocate their resources, and more information will help them do that. This may impact project deadlines, so make sure to include their input at the beginning.