Buying ERP is a big deal. I know because I’ve done it. I was a Plant Manager in the mid-90s, and we were running production with a homegrown system that could not be modified because we didn’t have the source code. It was better than nothing, but not by much. We were not managing our capacity, our scheduling consisted of pushing product through the plant day in and day out. It was exhausting, and our on-time delivery range fluctuated from OK to bad. The results we got did not reflect the work we put into it.
This is no way to run a company. I knew there had to be a better way, so I went out to find it. There was no internet, but there was an APICS magazine that listed ERP companies. I called a lot of ERP companies and talked to a lot of people. I learned every step of the way. Eventually, I was able to develop a vision of what we needed. Based on that, we found potential fits, and finally chose one.
I knew buying software and using it were two different things. Once we had it, I ran our implementation. That also taught me a lot. The functionality was relatively easy to learn; getting people to change was the harder part.
We did persevere and went live successfully. Within a month, we were scheduling the shop floor with the ERP. We started making promises to our customers that we could keep. Our on-time delivery improved drastically. It was a real success. We became a reference for other companies looking at the ERP product we choose.
About a year after we went live, I changed careers. I became an ERP consultant. I helped other companies implement what they bought, or learn how to use what they had to get better results. This is where my ERP education went into overdrive. I got to see all the different ways the functional footprint of the ERP can be used to solve business issues.
From there I starting selling ERP, then running sales, and eventually running the company that sold me the ERP in the mid-90s – Visual South.
I believe for a project to be successful, it’s important to understand what the goal is. I would argue that buying the right ERP is not your goal. Your goal is to solve your business issues. Buying ERP is only the first step in that goal. Chapter 1 covers that. The second step is implementing the ERP (Chapter 2). Knowing why implementations fail is an important education in making sure yours succeeds (Chapter 3). Lastly, the ERP needs to continue to run smoothly long after the implementation is over (Chapter 4).
I hope you find the following information helpful. Let us know if there is anything we can do to help.
The first step is to create a ERP comparison committee. The members of this committee should be made up of a select group of decision makers in the organization. There are no hard and fast rules here, but there are guidelines:
I know the last point is sometimes not possible. If the final decision maker is not going to be part of the committee, that person will not be part of the learning process that the rest of the committee members will go through. So how will that person make the right decision with less knowledge? Will that person have faith in the committee’s decision? Don’t kid yourself on this one. It’s rare the person who will sign the check acts as a “rubber stamp” to the ERP comparison committee. This is a big decision for any company, so it’s important it have the final decision maker involved as much as possible.
Related: Common Structures of an ERP Team
Related: ERP Implementation Roles & Responsibilities: How to Build Your Team
The second step is to define 3-5 business goals you want to achieve for each business area. From that list, pick the top 3-5 goals for the overall business. Notice I didn’t say, “Goals that I want to achieve with software.” Software is not a part of this step. You want to develop a list of what you want the company to achieve, not what you want the software to do. It may sound like a subtle distinction, but it’s not. If your mindset is on what the software will do, you will come up with items like:
Emailing a PO to a vendor or producing a report aren’t goals, they’re features. Goals sound like this:
Notice how the goals sound far more noble than the features? That’s because they are. Features are usually accomplished with a few clicks of a mouse. Goals involve training and procedures, not just software. The ERP comparison you do isn’t just against the different ERP systems, it’s also comparing those systems against your goals.
OK, you have a nice list of achievements for your company. Now you need to prioritize the items on that list. Pick the top 3-5 items that your company needs to achieve. Notice again, I didn’t say, “…with software.” This isn’t about software yet. It’s about developing a focused vision for your company. Do the executives in your company agree with your vision? If they agree – great. If not, either convince them of your wisdom so they do agree or change the list. In the end, the team must agree on the list. Because that list contains your goals, and you will compare all ERP systems on how well they will help you achieve your goals.
As for the items on your list that didn’t make the final cut, they still have value. We’ll talk about these items later.
Congratulations! By creating a vision, you have achieved something a vast majority of search teams have not; you have goals. As silly as that sounds, it’s true. Usually companies (or the consultants they hire) create long lists of items the software must do. The items are then grouped by function (Order Entry, Shipping, etc.) and then graded by level of importance (must have, nice to have, etc.). It all looks important and official, and discussing all the items with potential software vendors makes you feel like you are doing your software homework, but it doesn’t replace the fundamental need for goals. I would argue that it creates noise and confusion, not clarity.
But you won’t have that problem because you created goals. Nice work. Sit back and enjoy the moment.
Before you start looking for a vendor, there are a few more decisions you need to make:
Armed with your goals and some basic stats on your business, you can now begin your search for ERP solutions to compare. I’m sure this is the part where you expect I will reveal to you “The List”. You know, the list of the software companies that will meet your needs and save you all the trouble of research and creating your own list of possible solutions. Sorry, that list does not exist. Oh, you can get on the internet and find all sorts of websites that will provide lists for you and help you find the right software for your company. Note all the banner ads on these websites. Those ads aren’t free, software companies pay for them. You can decide for yourself how strong the correlation is between the advertising dollars software companies pay and how often they are recommended. For me, I can’t decide between really strong and really, really strong.
Related: Why Top 10 Lists Are Worthless
Does this mean you should avoid these sites? No, they are a source of information on what ERP products are out there. Many of them have very informative white papers you may find interesting. Just realize there are a lot of advertising dollars floating around those sites.
The reality is this: You need to do your own research. Don’t despair; it’s not as bad as it sounds. Remember, you have a list of goals, you know what platform you want to run on, you have an approximate number of users defined, and you know your business model. Start searching the internet with your favorite search engine for ERP products buy using keywords such as “manufacturing ERP” and “manufacturing software”. Believe me, you will get results back on these searches. Now, start looking at the software developer’s websites. By design, these sites cast a pretty wide net. That’s OK. Choose 8-10 you feel may have an ERP package that addresses your needs.
Related: 3 Things to Consider When Choosing an ERP Development Company
Related: Types of ERP on the Market Today
It’s time to contact your list of possible ERP vendors. There are many ways to contact them, but I recommend email for this step. Email allows you to tell each vendor the same thing; it also allows the vendor to pass all the information you provide to the appropriate person in their organization. In your email, let them know you are heading up a search for an ERP solution. Then, provide the information you have already defined:
Ask if they have a possible solution for you. If they feel they don’t have a solution for you, ask if they can recommend a solution. If they recommend a solution that is not on your list, you should add that vendor to your list and contact that vendor.
For any vendor who feels they have a solution for you, they need to provide 10 references. Let them know you will not be contacting the references; in fact, you don’t want any contact information. What you do want is the company name, number of employees, yearly revenue, and business model. So why do you want the references? It’s not to judge the performance of the software and the level of customer satisfaction (that comes later); it’s to see if the list they provide you feels like a group you belong in. Here’s an example: Let’s say you are a 100-employee manufacturer with revenue of $25 million a year. Are the references a vendor provides you also manufacturers? If they are not, that’s a red flag. (Note: Their product doesn’t have to be like yours. If you make stuff and the reference makes stuff, it’s a match for that category.) How about the size of the reference companies? If a reference has revenue exceeding hundreds of millions of dollars per year, you are not in the same league as that reference. If many of the references are like this, that’s a red flag. The same holds true if the reference companies are too small. The point of the references is to see if the prospective vendor has successfully sold to companies that “feel” like your company. Every ERP vendor has a sweet spot that their product is geared for. You want to make sure you are in their sweet spot.
If the vendor pushes back on providing references to you or pushes back on the number of references you want, that’s a red flag. First, the vendor is not listening to you. Second, if a vendor has hundreds or thousands of happy customers, why would providing 10 references be a problem? Maybe they aren’t as happy as you are led to believe?
In addition to references, require each vendor to give you a ballpark price for software and implementation. The goal here isn’t to hold them to a price; it’s to find out if, at a high level, you can afford what they are selling.
You will find that many of the vendors will want to contact you by phone after they receive your email. This isn’t necessarily a sign of a pushy salesperson. It could be a sign of a sincere salesperson who is taking your inquiry seriously. Take the call. You’ll be able to judge what type of person is on the other side.
I would suggest that you will only want 3-5 possible vendors before you start the next step. The next step involves spending time with each vendor, and you only have so many hours in the day. The goal in each step in this process is to be thorough. If you invite too many vendors to this next step, you could become overwhelmed and then start taking shortcuts. You don’t want that to happen, so choose the 3-5 vendors you feel comfortable with that have provided solutions to similar companies as yours.
Here’s the mistake many companies make at this step in the process: They try to control the process. They do this by telling the vendors what they are going to do. Here is your demo script, here is the allotted time for each section, here is the data to put in the demo database, and this is the date when you will show us your product. They do this because this process appeals to their sense of order and fairness. After all, you want the ERP comparison to be “apples-to-apples” don’t you?
The problem with this logic is you are setting up a scenario where everyone ends up looking the same! If they all look the same, how are you going to differentiate them? How are you going to reduce the list down to two possible vendors? I’ll tell you how – screen colors, whiz-bang features, and cool stuff. In the end, salesmanship becomes the driving force behind the decision. Wasn’t the goal of controlling the process to avoid this?
If you really want to be in control, don’t try to control the process. Observe, don’t direct. Let the vendors who made the 3-5 vendor list know they made the cut. Then ask them how they would like to proceed.
Are you feeling uncomfortable yet? Well, hang with me. Let’s jump to the finish. You are at the end of the process, and you just chose an ERP package. What are you really buying? Of course, you are buying ERP software. You are also entering into an implementation relationship with your vendor. They will be working with you to help configure your software and develop procedures to meet your business needs. So, during your software evaluation process, shouldn’t you really be evaluating not only the software, but also how your vendor proposes to use the software to address your business needs?
This is exactly what you want to do. So, ask your vendor how they would like to proceed, but remind them they have a list of your top 3-5 business goals. Tell them you want to see how they would address those goals with their software. Tell them the first demo needs to be limited to addressing these goals. If you don’t like how they would address your top 3-5 goals, it really doesn’t matter what other features the software has. How the vendors conduct themselves from this point on will give you keen insight into who you may end up partnering with. Remember: Observe, don’t direct. Does the vendor want to visit your company to get a better insight into your issues, or do they just want to demo? Does your vendor ask for data to put into the presentation? When they do demo, are they addressing your 3-5 business goals or are they running through a canned demo? Do they understand your business issues, or do they just know their software? Are they addressing your goals, or are they showing you what THEY think is important?
Thanks for hanging with me on this. Hopefully, it makes sense now. Remember the biggest mistake you can make here is to offer guidance (e.g. offering demo data to all the vendors). Set the goal for the vendors and then observe and judge. Doing this will assure you are setting up a good comparison of ERP systems.
Take good notes at the demo. This is critical, because after the passage of time, the different solutions you saw will start to blend together, making the comparison of the ERP systems more difficult. It’s also important to have the entire selection team in the ENTIRE demo. It’s a good idea to discuss each demo as a group within 24 hours of the demo. Get everyone’s thoughts out and keep a running demo-to-date ranking. In other words, which solution is in first place, second place, and so forth. As a reminder, the criteria for the ranking are ONLY how well the vendor handled your top 3-5 business goals. Cool, whiz-bang stuff for the sake of cool, whiz-bang stuff does not have a place here. (Read the previous two sentences repeatedly until it is engrained into the fiber of your being.)
Don’t be surprised if you or your committee members start thinking that a few of the solutions you saw could work; this is normal. Usually, this is heard when the focus is just on the software. Fold into the judgment the attentiveness, preparation, and professionalism of the vendor. You need to compare the vendors as closely as you compare their ERP software. This should start separating the products.
After your 3-5 vendors have completed their demos, it’s time to make another cut. The question is, how many vendors should be remaining after the cut? Many times, companies like to bring it down to three vendors. Although this is conventional wisdom, it doesn’t make it right. I believe the correct number has a lot to do with how the first round of demos went. Was there a vendor that the entire team thought was head and shoulders above everyone else, based on the 3-5 business goals? If so, there is nothing wrong with moving forward with one vendor. If during that process you don’t like what you see, you can always invite another vendor to the final round. If this is not in your comfort zone, or one vendor doesn’t stand out, choose two vendors. I believe you should try to limit your selection to no more than two vendors.
There are many reasons for this; time commitment is one. The next steps will involve a deeper look into the software and vendor, reference calls and site visits. You want to be thorough; you don’t want to take shortcuts in your ERP comparison. Limiting the selection to two finalists reduces the time invested by your company in making the final decision. It also reduces the amount of noise that will start creeping into the selection process. Lastly, it assures that the product you select is supported by the majority of your selection committee. Let’s look at the math on that. If you had nine members on your selection team and four liked Product A, three liked Product B, and two liked Product C; Product A wins. The result, however, means four members got what they wanted, but five members didn’t get what they wanted. So, the majority of the committee didn’t want the software that was chosen. That can lead to a bad dynamic during implementation.
Your goal at this stage of the process is to get a closer look at the vendor and the software solution your vendor is proposing, so you will be requesting a complete demo of the software. The same rules for the first demo still apply: Observe, don’t direct. Remember the list of goals you created at the beginning of this process? To date, you have only provided the top 3-5 goals to the vendors. Provide the remaining goals to your vendor. Let the vendor know you want to see how their product would handle these goals. Also, let them know you want to see their entire product, but only the modules that they are proposing, and only the version of the software they are proposing. To know exactly what they are proposing, require a written proposal (pricing for software modules and implementation services) from your vendor before the final demo. You don’t want your evaluation of the software influenced by seeing something that you are not going to buy. One last thing: Get a list of references, with contact information, from your vendor.
While the vendor is preparing for the final demo, you can be checking references by phone (I don’t suggest a site visit yet). There is no need to wait until the demo is over to check references. In fact, you will find it is a great learning experience that will help prepare you for the demo. You will hear what the references like and dislike about the software and the vendor. These are items that can be further explored during the demo.
What type of information do you want from the references? Here are some guidelines:
You should hear some negatives during your conversation with the reference. This is normal. (Actually, you should be suspicious if you don’t hear any negatives. If this happens, I would completely disregard the reference. Chances are they are a paid reference.) Some of the negatives you may discard because it doesn’t apply to you, or you don’t consider the issue a negative. But what should you do with the negative information that concerns you? Discuss it with the vendor. Your goal is to learn as much as you can about your vendor and the solution they are proposing to you. There are usually two sides to every story, give the vendor a chance to tell their side of the story. In the end, you’ll decide where the truth lies.
No new advice here, but the guidelines are worth repeating:
The best software you find is useless if it is not implemented properly. It’s important for you to understand the implementation process of the vendor. I highly recommend a separate meeting with your vendor to discuss implementation. If you try to tack this discussion on at the end of the demo, the discussion will be rushed because everyone in the room is worn out from the demo. Another benefit by having a separate meeting is it gives you a chance to discuss follow-up questions that are developed in your post-demo recap meetings. These meetings should take place quickly after the demos are complete.
As in the demos, your rule is to observe, don’t guide. Is the estimate of services provided created through a collaborative process; or does your vendor inform you of what services you need? If there is a lack of a collaborative process, that is a red flag. There is no canned approach to implementation because the variables are the levels of experience in integrated systems your implementation committee has. If many members of your committee have experience implementing an integrated system, you will probably need less guidance than normal. If your committee’s experience is running a company off spreadsheets, you will probably need more guidance than normal.
Related: Why Evaluating ERP Implementation Consultants is as Important as Evaluating ERP Software
Related: How to Implement an ERP System Sep-By-Step
Related: It’s Not a Solution Until It’s Implemented
What do you mean decision time? Don’t we have to do site visits and negotiate the best price out of the vendors first? Nope, that comes after you make a decision, but before you sign a contract. There is a big difference between the two, and many companies mistakenly lump them together.
You have all the information you need to decide as to which solution you feel would work best in your company. In this entire process, the focus has been on your business needs, and how the proposed solutions will address those needs. You have also observed how attentive the vendors are to your needs and how well you feel they understand your business, along with how successfully you feel they will be in assisting you in your implementation. In addition, you have gathered information from other customers when you conducted your phone references, and you have discussed any disturbing comments you heard with your vendors.
What other information do you need? You don’t need any other information. You have come this far, and it’s time to decide. But don’t worry; you are not ready to sign a contract yet.
The two final steps before signing a contract are doing a site visit and finalizing the price. Let’s discuss the site visit first, since it is the optional step.
As I mentioned, a site visit is not required. You really do have all the information you need to make a good decision. However, it is understandable to want to see the software in action before you sign a contract. If this will give you or your committee a good comfort level, do it. Please keep in mind that the company you will visit has their own business to run. The site visit should be just that – a visit. Don’t plan on spending the whole day there so you can explore and discuss every tiny detail of their operation. Your goal is not to implement your system on the visit. Your goal is to get a comfort factor that the software does work by observing a company that is using it.
Now let’s talk about finalizing the price. The reason I advised against getting your vendors to “sharpen their pencils” before deciding on which solution would fit your company the best is simple: Final price is noise. This entire process is designed to keep you focused on the issues that are important to your company. To do this, you need to filter out the noise. You are about to enter into a long-term relationship with the vendor of your choice. Making a good decision is critical to your company (to say nothing of your career). Don’t cloud your decision with the allure of saving a few thousand dollars by picking one package over the other. That “savings” will quickly evaporate if you choose the wrong package. There is something else to consider. If a vendor feels their solution is not the best fit, they lower their price. They have nothing to lose, everything to gain. If you allow price into your decision-making process, it usually becomes the center of attention. All the work you have done to carefully evaluate the solutions is quickly forgotten and a decision is made on price. If you allow this to happen, you could have saved yourself a lot of time by skipping the reference calls, final demos, post demo meetings and implementation meetings, and simply informing the finalists that the best price wins.
The fear is you are giving up your negotiating power if you inform one vendor you would like to move forward with them. I don’t think you are. I’m not going to turn this into a negotiating article (there are certainly enough guides on that subject), but here are the facts you can present to the vendor you choose:
I’d be surprised if you and your vendor couldn’t come to a mutually beneficial agreement. If your chosen vendor becomes very difficult to work with, or starts introducing costs you were unaware of, you always have the option of not signing a deal with them and moving on. Again, this is highly unlikely because of the time, effort, and investment the vendor put into your process to get to this point.
Congratulations! I hope by following this advice, you feel comfortable with your decision and purchase. Take a moment to bask in the glory of your accomplishment.
Simply surviving an implementation and going live on your new solution is not enough. A true ERP implementation success means that all objectives originally defined in the scope of the project were met and exceeded.
Measuring success can be fairly objective, and in many cases opinionated. In this article, we’ll look at some of the factors we at Visual South consider to be ERP implementation success factors. While this isn’t a complete list, these are the five most common factors we come across.
On time and on budget really have very little to do with the overall success of an implementation; it’s more about correctly assessing the time you need with the budget you have. Finishing on time does not necessarily mean it was done right.
Every company has a different budget, so if you were limited by a minimal budget, it’s possible corners were cut, or proper training and process development was left out. By no means does this mean you won’t be successful though. Visual South has many customers who dedicated their internal resources and time to make implementation successful with a small budget. This is not easy to do when trying to run the business at the same time. It also means the timeline is longer than a typical ERP project. When you align your time with your budget to do every step of the implementation right, you are successful.
Don’t take any of this to mean timeline and budget aren’t important. The important takeaway here is that both the timeline and budget need to be realistic. Setting proper expectations for the team allows the team to accept the expectations and that increases the chances of meeting them.
Related: ERP Implementation Roles & Responsibilities: How to Build Your Team
Inventory problems are one of the top reasons a lot of companies start looking for ERP solutions. This is typically more of an issue with process than software. Any good, modern ERP solution will have the tools necessary to maintain accurate inventory – from robust material planning or advanced planning & scheduling functionality, to easy-to-use inventory transaction recording.
However, the best software in the industry will be useless without a foundation of clearly defined procedures, along with automated checks and balances (workflows) to validate those processes regularly, and you’ll still struggle to maintain inventory accuracy. ERP implementation success is a newfound confidence that what the system is telling you is on hand, is actually on hand. You no longer need to walk out to the shop to ask someone if a certain item is in inventory – or actually looking for it yourself.
The important take-away here is that software – on its own – doesn’t solve issues. Software is a tool; and how well that tool is integrated into your processes and procedures determines the success of the project. Companies achieved inventory accuracy before computers and ERP software. Computers and ERP software make it easier for companies to maintain accurate inventory; they don’t create accurate inventory. ERP doesn’t need inventory locked down to function; but you may determine your processes and procedures require it.
Spreadsheets! Everyone loves their spreadsheets. You can create some fancy pivot tables and charts, you can do all kinds of mad formulas for your status meetings, and you can even link multiple spreadsheets together and perform some wild VLOOKUPs. And if you’re a finance aficionado, you might turn green if someone tried to take your spreadsheets away!
But spreadsheets are not always a good thing. For one, they are silos of information that usually only one person is in control of. The data is manually inputted, so there’s also the risk of typos (to say nothing of the time involved to manually enter the data). And a spreadsheet is very specific to the person who created it, which means if someone else comes along, they won’t know what to do to keep it living – so they create their own. There are folders and folders full of spreadsheets that are not centrally controlled. Sure, this can work in small environments, but it usually becomes unmanageable once the business grows.
Everyone we work with understands the downsides of spreadsheets. So why does everyone use them? First, most people understand how spreadsheets work. They understand the tool, so they apply that tool to business problems they are dealing with. Second, even with all the problems, using a spreadsheet is better than the alternatives. The lesser of all evils, if you will.
Successful ERP implementations provide a single system of record for all your critical data. This means information is automatically tabulated, with easy access to extract that information from one solution. You can still use spreadsheets to view, chart, and pivot your data (although a good ERP system such as Infor CloudSuite Industrial will even export into a pivot format), but the difference is that the data is now coming from a single source of information into your spreadsheet, not manually entered and maintained.
Keep this in mind: Spreadsheets were used extensively because it was a tool the employees understood. You want better results, so you bought a better tool (ERP). For that tool to become a “go-to” solution, employees need to be comfortable using that tool. That’s where training comes in.
Other examples of disparate systems that can be brought into a single system of record would be solutions such as CRM, Quality Assurance, Time and Attendance, Human Resources, etc. Having a modern ERP solution that incorporates all of these normally third-party solutions into a single, robust solution would be a clear sign of a successful implementation.
Overtime is usually a product of too much work and too little time, right? It’s simple math. We have 10 hours of work to do, but only 8 hours to do it in. The easy solution is to have some folks in the “bottleneck” areas work 10 hours a day. Problem solved – or is it?
I like to use an example from a case study on ERP implementation success—one of my first implementations many years back with a very large sheet metal shop. Prior to implementation, they worked a lot of overtime to keep up with demand. They believed their bottleneck was the stamping department since that seemed to be where most of the materials were piling up. Their solution was to buy a state of the art, automated shearing and laser cutting machine. To everyone’s dismay, this did not improve throughput at all as it only shined a light on the next bottleneck in the process that could not keep up with the speed of the new laser cutter.
Once we implemented their new ERP system, we had a much better way to identify what the bottlenecks really were. Hint – it wasn’t the laser cutters after all. And even better, we could use “what-if” scheduling scenarios to determine if running 10 hours a day in a certain area would truly improve output. In many cases, capacity wasn’t the metal shop’s bottleneck at all. Material availability was the culprit, which no amount of overtime could fix. A proper planning process was the solution.
In short, it’s very likely that some, if not all overtime may be completely unnecessary. Gaining the ability to see effects of adding overtime is one of the common ERP implementation success factors.
One of the most difficult positions in an organization is the customer service representative (CSR). Every promise they make to a customer turns into an often-futile exercise of trying to keep that promise. Most CSRs truly see a broken promise as a personal failure on their part, even if the ultimate reasons for it were beyond their control.
Providing customer service with the ability to easily and quickly get the information that will allow them to give or keep a promise to a customer is a big part of a successful ERP implementation. Everything in the manufacturing process development is geared toward providing accurate data for the production and planning schedule, which allows the CSR to simply click a button to determine if dates and quantities for a product can be met. And if not, when can they be?
If I could choose only one characteristic of a successful ERP implementation, this would be it. The ability to keep a promise to a customer means that just about every other facet of the manufacturing process is a success.
True ERP implementation success should be measured in years, not days, weeks, or months. Anyone can be successful immediately after going live on a new solution. The true measure is how well the processes hold up over the years, and how well they withstand inevitable changes, such as employee turnover, business expansion and mergers, and other potentially unsettling events.
Ensuring the success of your investment in a new ERP solution starts with understanding what NOT to do also! Read on.
Clear signs of risk and unavoidable challenges can usually be identified from the start of every ERP implementation. Similarly, challenges that are completely unanticipated almost always arise throughout the implementation. Every issue, big or small, should be identified as a risk to the project that might lead to failure.
In this article, we will focus on the five most common characteristics of ERP implementation failures. But let’s first define the term “failure.” The complete abandonment of an implementation can certainly be considered a failure by anyone’s measure. However, I would suggest that even a seemingly successful implementation can be considered a partial failure if all expectations weren’t met. Failure could simply mean that an important requirement in the original scope of the solution was never fulfilled. Or perhaps the implementation was originally a success but thought to be a bust several years down the road.
While this isn’t a complete list of all characteristics of an ERP implementation failure, these are the more common reasons we come across. The more you know, the better your chances are for success.
During initial planning discussions, the scope of the implementation is often separated into different phases to meet time and budget considerations. Generally, phase I consists of the “must have” items necessary to replace your current system and process at the time of go-live. You will also include other key features that you don’t currently have, but for the most part, you are covering all existing business requirements.
When companies lose sight of the goals and scope for each phase of implementation and try to implement everything in one phase, the stress on the internal resources to learn new processes and keep up with the project timelines can become overwhelming. There’s only so much time that they can dedicate to the project while performing their normal job activities each day. This can lead to frustration and loss of momentum in the implementation as your resources become unable to keep up with all the additional requirements. Don’t underestimate how much time each resource may have available to work on the project!
Related: ERP Implementation Roles & Responsibilities: How to Build Your Team
While this should be done in the initial ERP training, it is very important to have an ongoing plan for inter-departmental cross-training for all users, not just the ERP project members. End users will gain a much broader understanding of how their role in the ERP software affects and is affected by other users’ roles. Not including this training as part of the initial scope or continuous improvement phases is an often-overlooked opportunity to improve upon procedures and could lead to ERP implementation failure (either immediately or down the road).
For example, an engineer developing the bills of material and operations (bill of manufacture) would better understand the effects of the detail they are entering if they understand how the buyer will see and react to the demand for the materials in the job. Advanced ERP solutions can associate a material with a specific operation on a bill of manufacture. This allows materials to be purchased in a ‘just in time’ format, according to the schedule. If an engineer doesn’t understand how scheduling or planning works, they may just associate all materials to the front end of a bill of manufacture. The bill of material would still be correct; however, it can lead to purchasing materials before they are required. This would lead to excess inventory and unnecessary cash burn. Scheduling would not start the first operation until all materials are due in – even if they aren’t needed until further in the process. Not only is purchasing affected, but so is inventory, scheduling, and finance.
During phase I of implementation, processes and operational procedures are developed and recorded to help mitigate ERP implementation challenges. Once the system is in full use under load, additional processes may be discovered or changes to the original procedures may be required. This should lead to additional ERP training for the affected users and departments. Not having a plan for how to handle process refinement generally leads to the new or updated process being ignored or completed incorrectly, which can be a primary cause of ERP implementation failures.
Changes to original procedures should be expected and encouraged as part of the continuous improvement effort, and it’s critical to include the necessary training as part of those changes.
Employee turnover can have a significant impact on the continued success of any ERP implementation. After all, the system is only as good as the input it is given. During implementation, key users and end users are provided with the proper training and guidance on the new solution. Unfortunately, users that were involved in the initial project may change over the years. New users enter the scene without the same structured instruction given to their predecessor. Oftentimes they are trained by someone else who believes they know how the previous person was doing procedures and valuable information is lost along the way.
Having a policy for new user ERP training, along with keeping updated processes and standard operating procedures, is critical to mitigating the risk caused by turnover. Develop a plan to meet with all users over specific periods of time to be sure any process changes or improvements they may have developed on their own are properly documented and recorded. Ongoing training programs and success always go together!
This is a very important step to help avoid failure in the post-implementation training process. Months of hard work went into getting all the data and procedures just right for your go-live day. To keep everything in order, there needs to be a training plan for checking all transactions and processes on a daily, weekly, and monthly basis. This is one of the most pivotal steps to success, and not keeping the ongoing process validation consistent will surely lead to issues down the road.
For example, if your new system allows negative inventory transactions, you want to be sure someone is trained to check them on a daily schedule. Negative inventory transactions can be a normal part of the process but become a classic case study of ERP implementation failure if they aren’t corrected with the proper positive transaction on a timely basis.
A weekly process example would be checking and validating efficiencies and utilization of resources. Confirming users are properly recording labor time on jobs is crucial to accurate costing and scheduling, so someone should be trained to always check those transactions.
And a typical monthly process would be training for month-end close procedures. If all other daily and weekly validations are being performed, the month-end process should be fairly smooth.
Ensuring the success of your investment of a new ERP solution includes an understanding what NOT to do! Understanding how these risks can affect the overall achievement of your goals is an important step in the journey.
A lot of focus is put on how to evaluate, select, and implement ERP. But once the implementation is over, how do you keep things running as smoothly as possible?
An ERP implementation is a high risk, potentially disruptive project that takes up time and resources for a typical manufacturing company. It can be difficult for employees because many are asked to take on additional ERP project responsibilities, along with the current roles they fill to run the business on a day-to-day basis. A mentality develops that as soon as you go live on the new system, the project is OVER and everything can go back to normal. In fact, the opposite is true—the project is just BEGINNING.
Once your new ERP is live, you will experience immediate benefits if it has been implemented correctly. But there is still a fair amount of muscle memory to get accustomed to. New tools like ERP require new procedures and those take time to adopt.
Once you are in the post-ERP implementation phase, you will inevitably encounter issues you never predicted. This is normal; it is impossible for a team to think of every possible scenario when designing and testing a new ERP. The mistake some companies make is disengaging with the company that helped them implement the system once it’s live. While being self-sufficient is a good long-term goal, it is typically not realistic for the first six months after go-live. Make sure you continue to get input from resources who are more knowledgeable and experienced than your team—it is well worth it to avoid ERP post-implementation issues!
In every implementation, little things come up that would be helpful, cool, nice to have, etc. These typically get tossed to the side during implementation, but companies that are thinking ahead will capture those items as they arise. This becomes a fantastic list of continuous improvement projects that you can execute to get even more out of your ERP system. You have invested in a platform to run the business, and if you have done your homework, you also have a solution in place that will allow you to “grow into” it. These items typically do not involve large investment in software—you already have the functionality in your ERP, so it’s simply a matter of turning it on to integrate these improvements!
I see lots of companies suffer greatly from turnover, attrition, and placing too much trust in one person, as it relates to knowledge of processes and how the ERP supports those processes. This is because those companies did not place strategic importance on documenting their business process procedures, and how to execute the supporting transactions in the ERP. When someone walks out the door, all of the knowledge between that person’s ears walks out, too. Or, when a new hire comes on board, that new hire “sits with” someone to learn all the processes and that constitutes their new employee training.
If your company invested in ERP, then you should invest in creating documentation of how that ERP supports your business—period. Having documentation in place makes onboarding and cross-training easier, and dramatically reduces your risk when critical resources move on. A lot of companies avoid it because of the sheer size of the project, but there are tools available these days that make it VERY easy to create documentation by simply running the transactions in the ERP and letting the tool create the content for you!
Related: The Benefits of Documenting your ERP System Procedures
We hope the information provided here brings some clarity to your ERP search. Visual South’s mission is to help organizations reach their potential. We do this through software solutions we sell, but mostly through our staff of consultants who understand manufacturing organizations, and how to configure the software to address business issues.
If you feel we can help your organization, we can talk. No obligation, no cost. Just let us know.
Related: Looking for ERP? This is our process and some resources