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. Visit our resource center to view the summary overview of the tasks and deliverables we typically recommend and deliver when we help clients through the ERP selection process.
9.23.2006
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 companies 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 software 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.
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 companies 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 software 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.
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 and 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.
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 and 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.
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.
Read more blog entries in our corporate ERP blog on our website.
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.
Read more blog entries in our corporate ERP blog on our website.
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.
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.
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 absolutely 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.
This reader is absolutely 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.
Subscribe to:
Posts (Atom)