9.23.2006

ERP Assessment and Software Selection Framework

We recently posted a white paper about best practices in ERP assessments and software selection. After reading the white paper, many readers sent emails asking for more detail on how one might go about the whole ERP selection process.

As a result, we have made a summary example of our typical ERP assessment and selection approach available to the ERP community. Click here to view the summary overview of the tasks and deliverables we typically recommend and deliver when we help clients through the ERP selection process.

Eric Kimberling
Panorama Consulting Group

Do Small Businesses Need ERP?

Ever since the early 1990s, Fortune 500 companies across the world have been on the ERP bandwagon. With millions of dollars required to implement and well-publicized coverage of ERP failures, many wonder if ERP is worth the cost and risk to small businesses.

The topic of small businesses and ERP has been of interest to me, especially lately. Approximately 75% of our new clients and prospects interested in having us conduct an ERP assessment and vendor selection are companies with annual revenues under $100 million. In fact, one of our recent contract signings for this type of work is for a company with annual revenue of $15 million. Ten years ago, this type of small business interest in ERP was very uncommon.

The key things driving small businesses to ERP seems to be 1) growth of the small business sector, and 2) more focus on the small business market from ERP software vendors. Most of our small business clients are considering or implementing ERP because of their rapid growth and the corresponding strain it puts on their legacy systems. In addition, large ERP vendors that typically focused solely on the Fortune 500 market are now developing lower-cost solutions with more appropriate functionality for smaller businesses.

A third and final possible reason is because many niche ERP players have entered the marketplace to provide functional solutions for specific industries. Open technologies such as .net have reduced barriers to entry into the ERP market, so many smaller, industry-specific niche players are able to fill the voids left by the big ERP comapnies at a lower cost.

Although this increasing focus on small business is good for companies with limited capital budgets, it also poses additional risks. Now, there are more choices than ever, and some vendors' products are much more proven than others. So small businesses should be especially thorough when evaluating and selecting an ERP package. They should engage in a vendor selection process that ensures they choose a solid software package that provides a strong ROI to the company.

Eric Kimberling
Panorama Consulting Group LLC

Fixing a Failed ERP 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.

Here is an approach I suggest to get a failed implementation moving in the right direction again:

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 business
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.

Eric Kimberling
Panorama Consulting Group LLC

To-Be or Not To-Be: When and How to Design Business Processes for your IT or ERP Project

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 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 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 reasons. 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 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 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 IT project, not the other way around.

Eric Kimberling
Panorama Consulting Group LLC

Planning for IT and ERP Success

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 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 instead "big bang" approach to migration - 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 cutover.
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.

Eric Kimberling
Panorama Consulting Group LLC

9.05.2006

Aligning ERP & IT with Your Overall Business Strategy

One of our recent blog entries discussed how to define to-be processes as part of a successful IT implementation. Based on this entry, one reader questioned whether or not this is feasible if the IT project is not aligned with overall business strategy.

This reader is aboslutely right: aligning an ERP implementation with a company's overall business strategy is a difficult and often overlooked component of a successful project. I think the main thing needed is to take a top-down approach to defining business processes and then ultimately arriving at an ERP solution that fits the overall business.

In other words, before you can configure a system to enable your desired to-be processes, you need to define what these to-be processes look like. In order to understand your to-be processes, you need to know your operational strategy. And before defining your operational strategy, you need to define your overall corporate strategy and objectives.

So this is why the appropriate approach to ensure a successful ERP project that is aligned with the overall corporate and operational strategy is to:

1) Define your corporate strategy and objectives. I typically look at a 3-5 year horizon when helping clients through the process. I also challenge them to answer the question: "where do you want the company to be in 5 years?" Also, "what operational strategy is required to enable this higher-level corporate strategy?"

2) Once you have clearly articulated the company strategy, then you need to
define your "to-be" business processes that will enable this corporate and
operational strategy.

3) Then, establish the performance measures at the corporate, operational, and
business process levels. These measures should help you identify how
successful you have been in executing against your defined strategy. They
should also align with reports that come out of your ERP system.

4) Finally, you can begin designing, configuring, and testing the system to ensure that it is aligned with #1-3.

The unfortunate thing is that most companies start with #4 and skip steps 1-3.
By following all four, however, companies can be better prepared to ensure ERP
alignment with overall company strategy.

Eric Kimberling
Panorama Consulting Group LLC

4.03.2006

Does It Matter Which ERP Vendor You Choose?

If you've been following the ERP market lately, you have probably seen SAP's assertion that companies that run SAP are 32% more profitable than those that don't. On the other hand, another recent study from The Hackett Group found that there is no correlation between performance and world-class performance.

So what's the real story? In my opinion, these conflicting statistics suggest two things. First, the ERP market is competitive and cutthroat. Second, it raises the question of whether it is the ERP technology itself or other factors that increases performance.

Based on my experience, the specific ERP tool is just one piece of the business performance puzzle. How you design your business processes, how well you establish KPIs and measure performance, how you design your organization and employee roles, and how well you train employees to use the new system are just a few aspects that can have a huge impact on the success of your ERP implementation.

In addition, I question the validity of both studies mentioned above. For example, the SAP study compared SAP companies to non-SAP companies, not to companies running competing ERP systems. So perhaps a majority of the comparison companies weren't running any type of ERP package, so it would be expected that the SAP companies would perform higher. But could it be that Oracle or Microsoft customers were 40% or 50% more profitable than the others? Or, could it be that companies that are more profitable choose SAP because they have the resources available to invest in such a large project?

As for the Hackett Group study, I'm not sure what they mean by "world-class performance." It sounds great, but what does it mean? In addition, their study was focused on the performance of finance organizations within the companies studied rather than the performance of all the functional departments.

However, all of this is not to say that the ERP software itself is not important. Obviously, you want to select software that best fits your business requirements and operational model. But the key is that ERP is simply an enabler, and not the sole reason, of increased business performance.

The main conclusion here is that ERP vendor selection is an important activity. However, it is just one component of successful ERP projects and should be combined with an ERP Business Benefits Realization program to ensure business value and ROI are achieved from the implementation.

Eric Kimberling
Panorama Consulting Group LLC

3.16.2006

ERP Readiness Benchmarks: Do Companies Know What They're Getting Themselves Into?

One of our recent posts highlighted the importance of assessing readiness before any ERP or large IT project. Panorama Consulting Group provides a free on-line ERP readiness assessment tool, and the preliminary results from participants so far reveal some interesting thoughts.

It should be noted that the sample size is still relatively small (38 companies so far) and the initial data analysis is not yet validated in detail, but the initial benchmarks are interesting. For example:

1) 42% of participants say that their operations are poorly integrated across office locations
2) Over 50% of participants rate their current organizations poor in all the major areas we asked about: responsiveness to customers, efficiency, effectiveness, visibility to operational data, and integration between systems
3) Over 90% of companies have experienced a significant organizational change (in addition to ERP) over the last 3 years
4) Only 20% of participants have dedicated business process, performance measurement, or organizational change management groups in their organizations
5) 55% say employees at their organizations are poor at adapting to change
6) Only 15% of those planning to embark on an ERP project have completed a business case or ROI analysis

While we can begin to draw several conclusions from some of the data we've collected so far, the most significant observation is that organizational change management will be crucial to the success of these projects. These companies will face great obstacles during their implementations, and they will find it very difficult to deliver measurable business value without solid organizational change and benefit realization plans.

More data analysis over time will continue to shed light on organizational readiness. I'll keep you posted on the results. In the meantime, feel free to complete the assessment and receive a complimentary readiness analysis by clicking here.

Panorama Consulting Group LLC

3.05.2006

ERP Readiness Assessment Tool

If you were interested in our recent post regarding ERP readiness, there is now an online ERP readiness assessment tool that will help assess your organization's current level of business preparation for an ERP or large IT project. ERP readiness is the first step of an overall ERP Benefits Realization program and it also assists in ERP project risk management and mitigation.

Click here to take the online assessment, which is a brief series of questions designed to assess fundamental aspects that should be in place for any ERP or IT project.

Eric Kimberling
Panorama Consulting Group LLC

2.12.2006

Integrating Six Sigma and ERP

I recently came across a good question on how to integrate Six Sigma with an ERP project. Using an ERP financials implementation as an example, there are three key items to keep in mind to link your Six Sigma and ERP initiatives:

First, to integrate Six Sigma with your ERP Financials, it will be important for you to define your business processes for key financial processes, such as period-end close, A/P, A/R, consolidation, reporting, etc. These processes should be documented in detail (at least level 2/3), along with the inputs, outputs, and employee responsible for each process.

Second, it is important to define what the key performance measures are for each of the sub-processes you define. For example, measures such as number of business days required to close the books, number of adjustments, A/R days outstanding, etc. will help you measure the efficiency and quality of your processes. These measures should also map and align with higher-level corporate goals and performance measures.

Finally, once you have defined the key business processes in detail along with their related performance measures, it is important to ensure your ERP reporting is aligned accordingly. If your performance measures are not easily attained from within your ERP's business analytics, then you may have to measure using report-writers, other systems, or manual processes. Either way, you will need to define the process for collecting performance measure data on a regular basis to measure process and performance quality.

www.panorama-consulting.com