Give us a Call +1 (720) 515-1377

ERP Implementation: Do It Right or Pay Later

by | May 28, 2008 | 360 ERP Blog, Implementation

When dealing with clients who want to short-cut their ERP implementation process, one of the Project Managers at our company likes to state that “you can pay now, or you can pay later.” This may seem self-promoting since we are consultants earning a living on helping clients with their ERP implementations, but the reality is that it’s a true statement.

We see many companies that spend hundreds of thousands or millions of dollars on ERP software licenses, only to devote limited resources to implementation. Some think they can do everything themselves with team members that lack implementation expertise, while others simply want to minimize their budgets as much as possible.

The reality of ERP projects is that 86% go over budget, and a full 60% of implementations cost 10% or more than planned (according to Panorama’s ERP benchmark study). We suspect that a big reason for this is that many companies try to cut corners, only to find themselves in a mess that costs more to get themselves out of than if they would have spent the time and money to do it right in the first place.

Obviously we don’t recommend unlimited or unmanaged implementation budgets, but we also like to be realistic about how much time, effort, and cost it really takes to implement ERP successfully. Here are some tips for ensuring you have a realistic and manageable ERP implementation budget.

Tips for Staying on Budget in ERP Implementions

  1. Leverage experienced resources. Whether they are internal employees or external consultants, it is important to ensure you have team members that have navigated their way through implementations in the past.
  2. Fully define your business processes and requirements. Most of today’s ERP software options are very flexible and provide many options for improving your business processes. However, it’s up to you to decide what those new business processes will look like. Too many companies expect the software to drive their business processes, but the reality is that most software is very flexible and requires definition on how the processes and workflows should look for your particular business.
  3. Don’t skimp on training or organizational change management. While these are often viewed as “soft” activities, ERP organizational change management is extremely important to the success of your project.
  4. Take the time to get it right. Make sure you budget time to thoroughly test new business processes, security roles, customization, etc. Too many companies rush to slam in their ERP systems because they didn’t adequately budget time for these key activities.
  5. Choose the right software. This is arguably the most important one. Companies that choose software that isn’t a good fit for their business or requires significant customization to support their key requirements are the ones that are most likely to overspend on their implementation budgets. A diligent ERP software selection process minimizes the risk of choosing a solution that is not a good match for your situation.

A good rule of thumb that we share with our clients, and one that is confirmed in our ERP benchmark research, is that software licenses will likely consume only 25% of your total ERP implementation budget. In other words, implementation will likely cost three times what you spend on the software itself. Understanding this early in the process will save you a great deal of heartburn later on.

Five Worst ERP Implementation Mistakes

by | May 6, 2008 | 360 ERP Blog, Implementation

ERP isn’t usually a laughing matter, at least not for most of us. However, the other day a colleague of mine forwarded a blog entry with a humorous take on the five worst mistakes that you can take during implementation (click here to read the blog).

Although my list isn’t as funny, here are a few other common mistakes and pitfalls from past ERP implementation experiences (in no particular order):

  1. Lack of executive sponsorship
  2. Lack of focus on organizational change management and training (click here to read a recent article on why OCM and training should focus on more than system training)
  3. Lack of project resources, both internal and external
  4. Lack of budget, often due to unrealistic expectations during implementation
  5. Lack of focus on defining business processes and workflows

Poor project leadership management, including managing resources and scope, leveraging best practices, etc.

Poor fit between your chosen ERP software and your business requirements (click here to read about best practices in ERP software selection to make sure this doesn’t happen to you)

This is just a starting point – what else have I missed?

Closing the Gap Between New ERP Processes and the Old Way of Doing Things

by | Mar 8, 2008 | 360 ERP Blog, Implementation

For many companies we help implement enterprise systems for, the goal is to limit customization and leverage the ERP system’s “vanilla” out-of-the-box functionality as much as possible. However, even if an organization has identified a system that is a very close fit to what it is trying to achieve as an organization, a new ERP system will inevitably require changes to business processes, job roles, and organizational structures.

So how does an organization close the gap between the “as-is” way of doing things and the future “to-be” processes of new ERP software.

First, it is important to conduct a thorough gap analysis as part of an overall process and organizational analysis. This step entails identifying how exactly the software will be used in the context of how an organization conducts business. Modern enterprise software is generally very flexible and can be set up any number of ways, so it is up to the client to define how the business processes and workflows should be set up.

Second, once these business processes and workflows are defined in the new ERP system, key stakeholders and employees need to conduct a “Day In the Life” (some refer to it as a Conference Room Pilot) and follow a new customer through order fulfillment through collection of cash. This should be done in multiple iterations to ensure kinks in the process have been ironed out, issues have been addressed, and key business process decisions have been made.

After the detailed process definition and simulation takes place, then it is much easier to conduct training in a way that is tailored to each function’s specific workflows. Training, communications, and organizational change management activities should leverage the findings and changes identified during the process and organizational gap analysis to communicate key changes to employees.

A big part of the challenge of ERP implementations is related to business processes and people, not the software itself. The above actions help address some of the challenges and focus ERP project teams on defining streamlined business processes so there are no surprises during go-live.

Alternative ERP Implementation Strategies: What’s the Best Approach?

by | Oct 9, 2007 | 360 ERP Blog, Implementation

Last week, we cited an industry article about alternative ways of implementing ERP systems. The article gives an example of a large ERP implementation that challenged the traditional notion of going live via a “hard” cutover at go-live. Instead, the profiled organization stuck to strict deadlines, went live on time, and made changes to the system as needed going forward to address any functionality gaps that were missing at the initial go-live.

In some ways, a more iterative approach to ERP software design, development, and go-live is a refreshing change from the typical project that misses duration and budget milestones. However, there are three significant risks to this approach:

  1. Organizational Change Issues. First, this approach creates organizational change management issues. On the one hand, this approach helps create buy-in and ownership of the new system. However, ERP change is significant enough as it is, so going live without having worked through at least the major issues can be disruptive and demoralizing to the average employee. In addition, users become very frustrated when their system changes from week to week due to new enhancements or updates to the system
  2. Business Risk. The organization that was profiled was an educational institution, and the ERP focus was on financial functionality. The article notes that there were problems processing paychecks as a result of going live without hashing out all the kinks. One could argue that a few missed paychecks aren’t too big of a deal, but the consequences could be much more severe for a manufacturing or distribution company that finds it can only ship a fraction of its normal volume after go-live. If I were the CEO of a manufacturing or distribution company, there is no chance of me being comfortable with this approach given the high level of business risk and uncertainty around this style of implementation.
  3. Lack of Clear Requirements and Functionality. There is something to be said for drawing a line in the sand and saying that you won’t go-live with the new system until key business requirements and functions are fully developed and tested. Going live without ensuring that key business needs are met and thoroughly tested is risky and irresponsible at best.
  4. Difficulty Managing System Changes. The flexibility of ERP makes a more iterative approach more possible; software can constantly be changed as needed to meet evolving business requirements. However, such flexibility can create somewhat of an operational mess if not managed appropriately prior to and after go-live.

So what’s the “right” way to implement ERP, assuming there is a right way? The answer is somewhere in between the two spectrums. There’s something to be said for both approaches. The traditional “design-build” ERP implementation strategy has some structure that helps minimize risk, but it lacks some of the urgency that the alternative approach affords. The alternative approach, on the other hand, creates a sense of ownership and urgency by ensuring a broad set of employees are working out the kinks in the system, but it also neglects key functionality that should be in place prior to go-live.

The best thing is to try to get the best of both worlds. Clearly defining requirements and making sure the system meets these requirements prior to go-live is critical. At the same time, there is some value to having people start using the system before all the detailed kinks are worked out.

When we at Panorama Consulting advise our clients through ERP implementations, we typically suggest a “soft” go-live with a core group of employees several weeks before the official cutover, which serves as a way to get people comfortable with the system, test the system using real data, and work out kinks along the way. This helps balance managing business risk with creating a sense of ownership among employees, which is critical to an ERP organizational change management program.

ERP Risk Mitigation: Planning For ERP Success

by | Jul 20, 2007 | 360 ERP Blog, Implementation

Ensuring a smooth ERP migration is complex, and every implementation entails a certain level of business and technical risk. There are a number of factors that affect an ERP implementation’s level of risk, including the number of sites that you are going live with, how many legacy systems are being replaced, and how many users will be affected.

In general, the variables that are most likely to reduce the business risk of your migration include:

  1. Phased ERP Implementation Instead of a “Big Bang” Approach. Cutting over your systems all at once generally increases your risk, particularly on large projects across multiple geographies/countries.
  2. Sufficient Training. The better training you provide users, the less problems you will see.
  3. Legacy System Planning. What are you going to do with your systems after go-live? Will you run them in parallel for a short-period until you know the new ERP system is functional? If so, have you budgeted these costs in your ROI? Failure to answer these questions before go-live will create significant problems at cut-over.
  4. Thorough Testing. Unit and integration testing is very important; you significantly reduce your implementation risk if you have thoroughly tested the solution with real data and real user profiles before go-live.
  5. Provide Plenty of IT Support. Expect more support center call volume and staff accordingly during go-live. You will also want to make sure you have clearly defined escalation procedures in place for ERP issues that your support staff isn’t able to handle.
  6. Develop a Contingency Plan. What will you do if your system does go down? Do you have manual processes you can revert to if needed? By expecting the worst case scenario, even though it is unlikely, you will reduce the risk of a massive business failure.

It all boils down to ERP risk mitigation, and the addressing the above issues will help minimize the level of risk exposed to your business. It is important to ensure that your project plan, budget, and staffing all consider these items.

ERP and Business Processes: As-Is Or To-Be?

by | Jun 30, 2007 | 360 ERP Blog, Implementation

One of the most contentious issues in the world of ERP and IT is how much attention to give to as-is and to-be ERP business processes.  Opinions on the issue run the whole spectrum on how this should be addressed; some people feel that companies should let their ERP systems dictate what new processes will be, while others feel that as-is and to-be processes should be documented and analyzed in detail before selecting IT software. Many people, including myself, feel that the approach should fall somewhere in between.

It is helpful to break down the issues and look at each individual aspect of business processes to decide which approach is best for your company and your IT or ERP implementation.

As-Is Business Processes

This is one of the more controversial aspects of ERP projects. In my experiences with clients implementing ERP, IT, or any other large business change initiative, there needs to be a decent amount of attention devoted to defining current business processes. The benefits of doing so are three-fold:

  1. It helps get alignment and understanding among various business units and geographies on how things currently operate. More often than not, especially in very large organizations, many managers and key stakeholders do not have a big-picture view of what other parts of the organization are doing. Documenting as-is business processes helps develop clarity on what is working well and what is broken with the current business processes.
  2. It helps define how employees are doing their work now, which will help define the gaps between the current and future states. This is critical when it comes to organizational change management and training initiatives later on in the project.
  3. It helps determine the key operational pain points, and therefore the to-be processes and business requirements during the ERP software selection process.

This is not to say, however, that companies should spend an excessive amount of time documenting or over-analyzing current processes. At a minimum, organizations should develop level 1 detail around their current processes.

To-Be Business Processes

This area is very important as well. In order to develop the appropriate business requirements and select the software that is most effective for your business, you need to understand how you want your business processes to look in the future. Doing so provides four key benefits:

  1. It helps you define your future operational model and business processes independent of software. This allows you to think out of the box and look for opportunities to score big wins by leveraging IT as a tool to enable measurable business improvements. If you skip this step, you are more likely to be influenced by sales messages instead of functional fit.
  2. In conjunction with the as-is processes, it helps you identify the gaps between the current and future jobs, roles, and responsibilities. This is critical from an organizational change management perspective.
  3. It helps define key performance indicators to help drive business improvements and accountability. With new processes come new responsibilities and opportunities for improvement, so you need performance measures to enable this.
  4. It helps prioritize customization, integration, and report-writing needs after the software is selected. Without this understanding of where you want your organization to go from an operational perspective, it is very difficult to determine where customization and additional development is appropriate.

In short, I have found it helpful to view the business process aspects of your IT projects independent of the software itself. Your future strategic direction and business processes should drive the ERP project, not the other way around.

ERP Post-Implementation Audits Are Important

by | Mar 8, 2007 | 360 ERP Blog, Implementation

It’s easy to forget that successful ERP implementations don’t end at go-live. If anything, it’s after the system is implemented that makes or breaks the success of the system.  However, most companies fail to conduct a post-implementation audit to see how their ERP systems are fitting in with the business. Inevitably, there are going to be ongoing changes and adjustments to optimize the way the system is operating and to improve the way it supports your business.  Therefore, conducting a post-go-live audit is very important.

Post-Implementation Audit Focus Areas

  1. Baseline and post-implementation performance measures. Every ERP project should have a solid business case well before the system is selected or implemented. However, the only way to understand the level of ERP business benefits is to measure performance before and after go-live. It is important to establish baseline performance levels, then compare those to the performance levels after go-live. This will help identify areas of under-performance and opportunities for ongoing improvement.
  2. Identify ongoing training opportunities. No matter how well you’ve prepared and trained your employees, there will be a decrease in productivity immediately after go-live. They key is to minimize this drop and help them to eventually be more productive than they were before ERP. Post-implementation audits should explore areas where employees are under-trained or could benefit from ongoing training. This will help optimize the business benefits of your ERP system in the longer-term.
  3. Identify opportunities to improve business processes. Just because you have implemented ERP doesn’t mean that your business processes are going to be perfect. There are always going to be process inefficiencies and breakdowns that can be improved. By working with employees to identify process pain points and following this up with root cause analysis for these pains, you will identify opportunities to improve your processes and make them more efficient and effective.

The above three steps are important steps to ERP benefits realization and part of an ongoing organizational change management program. The focus is to leverage the investment you have made in ERP technology to realize a strong return on investment.

First Step to Successful ERP Implementations: Get Your House in Order

by | Oct 11, 2006 | 360 ERP Blog, Implementation

I’ve posted quite a few articles on this blog about how common it is for companies to jump on the ERP bandwagon without first conducting the due diligence and planning required to make a project successful. Many companies do not get their houses in order before going down the path of an ERP implementation.

What do I mean by “getting your house in order”? In particular, I’m referring to understanding exactly who you are as an organization and what you want to be in the future. This covers everything from understanding your strengths, your weaknesses, your core competencies, and the areas you would like to improve. Making these decisions in the midst of an ERP implementation can be a very rushed process, and making key strategic decisions like these in a sloppy fashion will create significant pain and confusion in the future.

I work with many companies that do not define these important areas early in the ERP evaluation process. The companies that are able to implement ERP software the fastest, at the lowest costs, and with the least amount of pain are the ones that have a clear sense of direction and strategic priorities. These companies are in a strong position to let their business drive ERP technology, not the other way around. Many companies that fail at their ERP projects let the technology drive their business.

The key takeaway is that ERP cannot be implemented successfully without clear requirements, which are key to ERP implementation success. By the same token, clear requirements cannot be defined until business processes are well defined. And business processes cannot be defined until organizations establish a clear sense of strategic direction. Organizations should ensure that these areas are taken into consideration during their ERP assessment and software selection processes.

Can Technology Hide a Flawed Corporate Strategy?

by | Sep 5, 2006 | 360 ERP Blog, Implementation

This may be more of a rhetorical question, but recent web-poll results on our web page begs the question: if a company is struggling with its overall corporate strategy, is technology going to help?

First, a bit of background. Our company’s main page has been running an ongoing poll asking visitors what their biggest organizational challenge is. The results are interesting: 34% said lack of strategic direction, while 26% say the company operates in silos, and 17% blame process breakdowns. The remaining choices (poor IT systems, globalization, and employees are overworked) all received small portions of the votes.

The interesting thing about these results is that most visitors to our site are people in the ERP and IT communities who are looking to implement ERP or other large, enterprise-wide software. Our company does not tend to draw a lot of interest from companies that are looking to fix flawed strategies. Which leads me to believe that many companies that are either implementing or planning to implement large IT projects point to strategic direction as their biggest problem.

So the question is, then, is a new IT system going to help? It may help improve process breakdowns and start to remove silos within the organization, but it is certainly not going to help a company decide which strategic direction to go. It may provide better visibility to customers, vendors, and the overall supply chain and help drive better decision-making, but other than that, it is not going to replace a sound strategy.

In fact, the lack of a strong overall strategic direction is one of the biggest ERP and IT failure points and obstacles to benefits realization. Companies that have a clear strategic direction and vision typically are much more successful at implementing technology and realizing its benefits.

Fixing a Failed ERP Implementation

by | Apr 17, 2006 | 360 ERP Blog, Implementation

Most of my entries in this blog have focused on proactive measures that can be taken to ensure ERP or IT success. However, what happens if you’re already in the middle of a failed ERP implementation?

The good news is that troubled IT implementations can be fixed, even if they are way over budget, behind schedule, and creating great organizational strain. In these types of instances, I often advise clients to reposition their projects as business improvement projects rather than IT projects.

At this point, you have forget about ERP. During or after a failed implementation, the software is likely creating huge difficulties. Just the mere mention of the letters E, R, and P probably cause employees to cringe, so it’s important to focus less on ERP per se and more on how you are going to fix your business operations. With this change in mindset, you use ERP only as necessary to make business improvements to get your organization back on track.

Steps to Fix a Failed ERP Implementation

  1. Assess each area and department of the business that ERP is affecting. What are your key performance measures (order fill rate, time to close books, order accuracy, etc.)? Where are your biggest operational pain points? This will require you to reach out to key business stakeholders to get them involved, if they aren’t already.
  2. Develop two-tiers of potential solutions: stop-gap / “quick fix” solutions and long-term solutions. Determine the costs and time required to implement each of the options.
  3. Prioritize your problem / solution combinations to arrive at the top 5-10 areas where you will realize the most immediate business impact at the lowest cost (low hanging fruit). Many of these solutions may or may not involve ERP functionality. It may require more training of the system, configuring the system to support new solutions. My experience has shown that bussines processes and organizational change management are the most common problem areas in failed ERP projects, so many of your solutions may not even involve changing the system or implementing new functionality.
  4. Begin implementing these low-hanging fruit solutions. The goal should be to build organizational momentum and confidence with these “quick wins.”
  5. Once you get some quick wins in place with the shorter-term solutions, begin prioritizing and implementing your long-term, more permanent fixes the same way you did with your short-term problems.
  6. Begin implementing long-term solutions as time and resources allow.

By following this approach, you will better position your organization to make your troubled implementation a success and optimize the business benefits of ERP.

It’s Not a Small World After All: Managing Change on International ERP Projects

by | Mar 4, 2006 | 360 ERP Blog, Implementation

When implementing ERP software in multiple countries, corporate executives face the issue of managing organizational change in an international environment. For any large change initiative, organizational change management is a challenging and difficult issue to address; however, with the addition of additional variables such as differing cultures, values, and languages in the international arena, the difficulty increases substantially. When introducing organizational changes at an international level, there are several factors to consider:

Language Barriers. While most managerial types in countries outside the US speak English of some sort, not all front-line employees speak English or speak it well. Therefore, getting key messages across regarding organizational or process changes is a delicate and complex issue. It often involves translating messages into their native languages and reiterating the same message via different channels depending on the culture of the audience (e.g. email, phone conferences, meetings, etc.) .

Culture and Values. Not all people in the world value or are motivated by the same things as Americans. Many western European countries value history, tradition, and work-life balance, while many developing Asian countries value hard work, entrepreneurship, and teamwork. Managing change in these very different environments requires differing approaches and messages.

Propensity for Change. More established and developed countries have business operations that have worked well for a long time, while many developing countries have less mature operational models. Therefore, it is often common to see more resistance to change in developed countries versus those that are still emerging. For example, a small company in India that is struggling to keep up with new demand with a very limited staff and manual processes may be more welcoming of an operational improvement than a large office in the UK that has refined its operational model and implemented automated processes over a long period of time. On the other hand, the small office in India may have less available employee resources to assist with a change effort.

Consideration of Local Requirements. Global changes that are pushed to the local level by corporate headquarters often do not adequately consider local needs and requirements. Each country has its own regulatory, resource, and employee constraints, so it is important to plan accordingly when implementing the changes. Obviously, completely localizing a global initiative defeats the purpose of having a single global change, but no solution is going to work for 100% of the world, no matter how well-designed it may be.

Varying Degrees of Understanding of Best Practices. Employees in different countries have different levels of understanding of business and technical best practices and methodologies, which may affect the amount of change management required to “sell” the ideas to affected employees. For example, employees in eastern Europe may be less likely than Americans to understand the value and benefits of Six Sigma or business process management methodologies, which increases change management effort.

Buy-in Is Important. This is true for domestic ERP projects, but it is even more true for global initiatives. Involving affected employees across the globe early in the process will help identify and address some of the issues mentioned above. It also helps overcome potential pockets of resistance by ensuring that employees across the globe are involved in the decision-making and planning surrounding the particular change.

By incorporating the above aspects into your overall ERP project plan and organizational change management plan, executives are much more likely to ensure that their respective change initiatives are embraced across the globe. This ultimately leads to increased business performance and ROI on a global scale for your ERP project.