5 More Critical Insights for Implementing ERP

In part I of this series on ERP, we interviewed Brian Schaffner about five of the things he wishes he’d known before he started implementing his first ERP solution. This week, our interview continues with five more lessons for CIOs, IT directors, and IT managers who are staring down the gullet of an ERP implementation deadline.

ToolTalkWeekly:  Testing an ERP may take as long, or longer, than to do the development and configuration

Brian Schaffner: During a typical software lifecycle, you perform rigorous testing of the solution to be sure it meets your requirements and does what you need it to do. On smaller scale systems, you can often predict the testing effort using various formulas and rules of thumb. With an ERP implementation, however, the rules can be different.

Because an ERP system usually supports many more processes than a smaller, more focused system, and because the processes within the ERP are more integrated – there can be many more dynamics at work than in a typical software solution. As a result, the number of permutations that can arise grows exponentially as you define and build the system. You will need to think about the effort required to test and validate all of these variations. Automated testing solutions can be a tremendous help in this area, as you will need to not only test the system during the initial development and deployment, but will also need to regression test it as you make changes.

TTW: Implementing a system-wide ERP platform is a huge cultural change for an organization

BS:  As with overlooking your customers – some organizations overlook their internal people and culture when implementing a solution of this magnitude. Change is difficult for many people – and especially for organizations where there is an ingrained culture. Culture can take many forms – and in this case can be affected by changes in the roles that people have, in the tasks and processes they carry out, the skills required, and even whether their job exists after the system is in place.

It’s important to understand how the process of implementing the new system, and how the operational rollout of it will affect the organization as a whole. You don’t want everyone to come in on a Monday morning and have a crash course on how to deal with the system, customers who are complaining and anything else that’s going wrong. This can be addressed partially through normal training curriculums which train users on how to perform specific functions within the system. Usually, though, that’s not enough. You should also think about how you will transition into the new system and how you will socialize those changes – organization-wide. You’ll want to make sure that the non-IT people understand that the new system isn’t going to be perfect – and will definitely have issues. As the organization learns about the changes, and adapts to them over time, the process of adopting the new system will go much smoother.

TTW:  The cost to implement an ERP are probably 2x to 10x whatever you think the initial estimate is

BS:  IT news sources have no shortage of stories of failed and expensive ERP implementations. So – you probably already know this one, but it bears repeating. Your ERP will cost significantly more than you are planning. Very few ERP implementations cost anywhere near the initial plan.

You should go in expecting to spend between 2 and 10 times your initial cost plan. This may seem like too much – and possibly there are ways to reel in the costs. The reality, however, is that ERP systems are complex and planning them out in a way that’s accurate is very difficult to achieve. That complexity often comes from many of the issues listed above, such as the ERP doesn’t fit your business processes, so you pay extra to customize it (or your processes) so that they match. Or maybe your business process requirements are all in the head of the mainframe programmer that retired last year, and now you need to pay a hefty consulting fee to bring him back to help you. Perhaps you thought you were going to have a 1 year, big-bang implementation – but half-way through you realize that a 3-year phased plan is much easier for the organization to consume. Some of these you can plan up-front – but many of them are hard to predict until you are already in the middle of the project.

TTW:  ERPs are long cycle projects – and they take a heavy toll on the IT team and the business users

BS: Most ERP projects take 12 months or longer to complete. That can be a long time for everyone involved to continually keep focus and motivation. The IT team often has some idea of the impact coming their way when they sign up for a project like this. IT groups are usually familiar with the process of system development and implementation, and have grown accustomed to the steps and timeframes involved.

Business users, on the other hand, are usually in a different boat. Many non-ERP projects that involve business users only require limited involvement and input. During an ERP implementation, the demand on the business users can be very high. At times, the business users will work as many or more hours than the IT team – helping to articulate their processes and how they work, helping to test and verify that the system does what it’s supposed to do, and even participating in and leading training of their departments. All of that effort can be a drag on their morale, and also a major impact to their normal daily duties.

TTW:  A clear understanding of the benefits is crucial to prioritizing the work, and to measuring the success of the project.

BS: Many ERP implementations start off with a grand vision of how great things will be when the project is over and everyone is reaping the benefits of a great implementation. What usually happens over time is that trade-offs and compromises are made in order to keep the project schedule on track and keep the costs in line. When that happens, the goals and benefits of the project can erode.

A clear understanding of the benefits and priorities can and should be the backbone of decision making when reviewing costs, schedules, and other project risks. It’s understandable to back off of certain features because they are going to take too much time or effort to implement; but if not implementing the feature compromises a core benefit of the system, it’s important to understand that when it occurs, not when the project is completed and the CFO doesn’t understand why the ROI doesn’t match expectations.

What’s your take on ERP?

To share your experiences with ERP implementations, please post a comment below or send a note to the editor.

Featured Toolkit: IT Project Management

If you’re looking for a great set of templates and tools for implementing an ERP solution in your shop, check out The IT Project Manager’s Toolkit.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply