Selecting the right ERP solution for your organization is a monumental task for any industry. For public sector organizations, this is a particularly tall order.

It’s difficult to earn the support from project leadership who are changing every election, or to mobilize an aging workforce who has no appetite for change. Other challenges include documenting requirements and ensuring the chosen solution meets specialized needs.

We recently published a report on the Top 10 Public Sector ERP Systems to provide ERP selection advice to states, cities, agencies and tribal governments. Before you dive into the specific technologies in the report, let’s talk about the do’s and don’ts of public sector ERP selection on the path to becoming a digital government:

7 ERP Selection Tips

1. Don’t Start Meeting with Vendors Until You’ve Achieved Strategic Alignment

What is strategic alignment? For ERP selection, strategic alignment means the alignment of all stakeholders around project goals and timelines.

Let’s look at an example of how not reaching strategic alignment can sabotage the ERP selection process:

Let’s say the Chair of the county school board wants to implement a new time and attendance tracking system. She believes that teachers are spending too much time entering attendance records because their outdated system is difficult to use. She sees this as a minimal risk, high reward project that can be completed in the short term.

However, the Vice Chair wants to implement an entirely new e-learning system for all schools in the county. Both ideas are perfectly fine and will make a positive impact in the long term, but imagine how discussions with potential ERP vendors would go if these two stakeholders are not in strategic alignment.

2. Don’t Aim to Overhaul Your IT Ecosystem in One Phase

A memorable proverb says this in a different way – “How do you eat an elephant? One bite at a time.”

When implementing an ERP system, it’s best not to overhaul your entire IT ecosystem in a single roll out. Phasing out one system or business segment at a time minimizes the amount of risk introduced to your organization during an ERP implementation.

Throughout the process of becoming strategically aligned, you should have determined an overall goal and a corresponding timeline. To reach your overall goal, smaller milestones should have been discussed with their corresponding timelines.

During the ERP selection process, it’s important to share these milestones and timelines with potential ERP vendors. Some ERP systems are modular and make it simple to implement a little at a time. Others are more invasive and require a huge lift and shift to go-live.

3. Don’t Only Think of Your Immediate Needs

In the public sector, processes may seem like they’ve been the same forever. However, don’t let this mentality blindside you into only thinking of your immediate needs when selecting digital technology.

An ERP system and ERP project are huge investments both in time and money. Selecting the right system with your future in mind will set your organization up for streamlining processes and adding new capabilities down the road.

For example, today you might be looking for ERP software that can handle your payroll, HR and accounting. You choose an ERP system that has limited functionality to only meet those needs. However, a year later, your organization wants to move their customer record management into the same ERP system but discover it’s not possible without heavy modifications.

We don’t advise organizations to select the most robust ERP solution in the off chance a capability will be needed in the future. Instead, we recommend narrowing your scope down to the processes you currently support, especially if the systems supporting those processes are inefficient or outdated.

4. Do Give Small Vendors a Chance

When most people think of ERP software, one of the big vendors come to mind. SAP, Oracle and Microsoft Dynamics are all easily recognizable. These vendors built their brands over time by implementing their software in a variety of industries. To ensure their product was versatile, they established standard business processes and incorporated those as flows into their modules.

For example, in the procurement module of an ERP system workflows often can be created to gain approvals based on specified thresholds related to purchase orders. These thresholds tend to be universal, such as total amount and line amount. Other factors like the vendor on the purchase order or the buyer can also be used to determine workflow requirements.

In a public sector organization, stricter or more complicated workflows may be required. Your workflows may be dependent on the segment in the organization in which the buyer works, or the types of items or services on the purchase order.

For a non-public sector specific ERP system, this would involve some customization. For niche vendors that work in the public sector industry, this may be something already designed. In fact, smaller ERP vendors tend to specialize in one or only a few industries. These ERP vendors have extensive industry-specific experience on their resume and likely have a set of standard operating procedures designed with your industry in mind.

5. Do Document and Map Your Business Processes

At public sector organizations, this can be difficult as most processes are executed based on long-time employees’ tribal knowledge. Workers with the tribal knowledge may feel it’s to their advantage to keep this knowledge to themselves, whether it be for job protection or pride.

One way to lessen this resistance is to include these workers as part of the ERP project team in the selection process. This increases information sharing and employee buy-in.

5. Do Enlist the Help of a Third Party

In the public sector, it can be difficult to choose a vendor without being influenced by bias. Even if your ERP selection process is completely fair and impartial, we’ve unfortunately come across vendors protesting to continue in the request for proposal (RFP) process because of accusations of favoritism. When this happens, your RFP process can be sidelined while any investigations take place.

This risk is one of the many reasons why more and more organizations are leveraging third party consulting firms to handle the vendor RFP process. As an independent party, the consulting firm assumes the liability in rejecting some vendors’ proposals.

For example, when we work with public sector clients, we highly advise that everything related to the ERP selection process be documented. The dates, attendees and agendas for all meetings and demos should be captured. The conditions in which you evaluate each vendor should also be documented to prove that each vendor was held to the same evaluation standards.

Mitigating risk is not the only reason you should enlist the help of a third party during your ERP vendor selection. Independent ERP consultants, like Panorama Consulting Group, are technology-agnostic, so we investigate all possibilities to find the right ERP system for your organization.

5. Do Consider Return on Citizenship

In the private sector, it’s common for organizations to calculate their ROI before an ERP project. However, with no profit margins and lack of competition, public sector organizations have a difficult time measuring ROI for a new ERP system.

Instead, there is another goal that public sector groups can strive for: return on citizenship (ROC). ROC can be described as the return on government services and social value to the citizens.

With this goal in mind, you should ensure that each ERP system considered can help you to achieve it.

Modernizing Your Organization

Our Top 10 Public Sector ERP Systems not only highlights ERP vendors suitable for public sector organizations, but it examines some of the challenges the public sector is facing that are creating a need for modernization.

If you are wondering how to modernize your own organization, you will find our report useful as it provides guidance on how to prepare for software selection and navigate selection challenges.

Panorama’s ERP consultants are experienced in digital government and digital transformation best practices. We can help you more efficiently and effectively deliver services to citizens.

ERP software can be a multi-million-dollar investment, but companies often don’t invest the same time, expertise and resources into negotiating these deals as they do negotiating other major capital outlays.

This is not to say that companies aren’t concerned about the cost of ERP software or of implementing ERP software, but they do tend to overlook certain cost variables. Companies, often, are most concerned about the obvious variables: software costs, maintenance costs, hourly rates and scope of services.

While these are all important, they typically are not the things with the most impact on total cost of ownership. Instead, it’s the things lurking beneath the surface that make a difference.

Contents

1. 9 Tips for ERP Negotiation

2. The Unintended Consequences of Fixed-Cost Contracts

3. Are Fixed-bid Contracts Always Bad?

4. Qualities to Look for in a Software Sales Rep

5. What is Your ERP Consultant’s ERP Contract Negotiation Methodology?

6. Conclusion

9 Tips for ERP Negotiation

1. Understand Roles and Responsibilities

Some of our clients go into vendor negotiations ready to beat up their vendor on cost. However, negotiating a contract with your software vendor isn’t just about minimizing cost. It’s also about managing risk and clarifying roles and responsibilities.

A low-cost deal isn’t going to do you much good if the vendor has shifted all the risk to you to help get to the desired number. Fortunately, most vendors are willing to negotiate roles and responsibilities.

Here are some questions to ask yourself as you’re reviewing the vendor contract and statement of work:

• Who is responsible for training end users?
• Who is responsible for data cleansing and migration? How much historical data will be converted?
• Who will handle overall project management of internal and external resources?
• What are the assumptions surrounding changes to the configuration of the software? This is especially pertinent if you have been sold an “industry pre-configured” solution.
• How many internal resources does the vendor assume you will dedicate to the project?
• Who is responsible for system testing, business process testing and integration?
• Who will create system and security profiles in the system?
• Who will handle Sarbanes-Oxley, FDA, system validation and other regulatory compliance requirements?

2. Understand the Scope of Modules and Functionality

Constant updates to software versions, multiple variations of available modules and disconnects between the demo and proposal cycle can create ambiguities.

For example, not all ERP vendors group functionality within the same modules. While a customer relationship management (CRM) module for one system may include a robust way to convert a lead into a customer with a corresponding order, other systems may require use of an order entry module.

Companies also may experience confusion when sales teams demo one version of a product, while the proposal team assumes a different version of the software without explaining the difference.

3. Consider Annual Maintenance Costs

This is where vendors make their real profit. As such, vendors will usually hold the line on this annual fee, especially if you’ve negotiated an aggressive deal on software licenses.

At the very least, you should remember to include a maximum amount that vendors can raise their annual maintenance fee. Asking if the vendor can hold the price steady for at least three years is a good way to control costs.

4. Don’t Assume the First Offer is the Best Offer

As with any negotiation, vendors typically start by offering software at their list price and reducing from there.

Don’t be afraid to ask your vendor to reduce their software pricing, particularly as it relates to license costs. Vendors typically are flexible in their software pricing because they have several other ways to make money, whether it be through ongoing maintenance, professional services or training.

5. Review the Contract Terms and Conditions

Some common things to look for include payment terms (you don’t want to pay for everything up front), and what happens if you don’t like the vendor’s technical implementation resources.

In general, you want to look for other conditions that can be more advantageous to the vendor than to your company.

6. Don’t Buy More Software Than You Need

One common pitfall is purchasing more software than you need, whether it be in terms of unnecessary modules or too many users. For example, we recently worked with a mid-size manufacturing company that estimated it had purchased $600,000 of licenses that were not going to be used by the company anytime in the near future.

It’s always easier to add to your purchase over time, but nearly impossible to scale back on licenses you’ve already committed to. Even if your ERP vendor is offering you a “once-in-a-lifetime” deal on software licenses, you likely are going to overcompensate for the cost savings by purchasing software you don’t need.

Don’t let these “time-sensitive” discounts create a sense of urgency. Most sales reps will continue to honor discounted pricing after the discount period.

We recommend purchasing what you need when you need it and pre-negotiating the price on future purchases to avoid license cost increases. When we negotiate deals for clients, they’re able to purchase additional licenses, modules or users at pre-defined costs for three years or more.

7. Distinguish Between FUD (Fear, Uncertainty, Doubt) and Reality

One of the most common sales tactics in any industry is to create fear, uncertainty and doubt in the minds of potential buyers. Buyers of ERP solutions face similar tactics, whether it’s being told that only the vendor’s direct professional services group is able to handle the implementation, or that the maintenance contract will be void if a non-certified consultant installs and configures the software.

The key is to understand which messages are real versus FUD. This is a skill that comes with extensive knowledge and experience in the industry.

8. Benchmark Against Other Deals

Here are some questions you can ask yourself to help identify points of negotiating leverage:

• What is the vendor offering companies that are similar to yours?
• What are competing vendors offering?
• Does your incumbent vendor provide some additional leverage via upgrade or migration credits that may put cost pressure on other vendors?

We see too many companies zero in on one vendor without receiving proposals from and conducting an evaluation of other vendors. If you have competing offers, you can ask your preferred vendor to meet the pricing offered by a lower-cost vendor. You also can make concessions based on any functionality gaps or concerns.

9. Consider People and Processes

It’s amazing how often vendors’ project plans do not assign critical project activities to either the vendor or customer but completely omit them.

For example, most change management activities are not included in the project plan, aside from basic end-user training. In addition, business process management is oversimplified to entail the adoption of the software workflows out of the box with no modifications.

We recommend improving and documenting your processes before issuing a request for proposal (RFP). This ensures the vendor understands your unique processes and doesn’t assume you’ll implement everything out of the box.

While this tip may seem unrelated to traditional contract negotiations designed to pinch project costs, the long-term cost savings of realistic expectations can be just as significant as the direct cost savings you negotiate.

You don’t want to come out of negotiations thinking you’ve scored a great deal only to find you’ve merely shifted your costs to other budget categories, incurred greater costs in the future or elevated your implementation risk.

With that said, companies should not enter into fixed-cost contracts without completely understanding them . . .

The Unintended Consequences of Fixed-cost Contracts

On paper, it’s a brilliant idea: 100-percent cost predictability and shifting the risk from your own company to your ERP vendor. However, fixed-bid contracts have some potentially disastrous consequences that are even more destructive than the problems they were intended to address.

In our experience serving as software expert witnesses for many failed ERP projects, we have found that fixed-bid contracts are often the root cause of ERP failure. It’s never a good idea to enter into a fixed-cost contract without fully understanding the costs and risks.

Here are three consequences of entering into a fixed-bid contract with your ERP vendor or systems integrator:

1. Incentives are Misaligned

2. Your Company Takes no Responsibility for the Project’s Success

Executives typically don’t understand the complexity and magnitude of a successful ERP project, so they lean on their ERP vendor to guide them. However, only internal executives and management team members can provide the direction, resources, operational decisions and oversight required to make an ERP project successful.

In fact, the way the non-technical aspects are managed will ultimately determine the success of your project. These non-technical aspects include activities such as business process reengineering and organizational change management. No vendor is going to magically improve your processes and gain employee buy in without involvement from your executive team.

3. The Fixed-bid Buffer can be More Costly Than Managing Time and Materials

When we advise clients in their ERP software selection initiatives and contract negotiations, it is rare to see vendors fix-bid a proposal without including a buffer – often ranging from 30- to 40-percent. In other words, they will take their estimated time and hourly rates and add a buffer to insulate them from the risk of overruns.

In addition, as noted in point #1, they will at the same time reduce their scope, leaving more the more costly and time-consuming activities for the client to manage.

At the end of the day, this doesn’t reduce cost, it simply shifts costs from the vendor to the implementing company. To add insult to injury, most companies don’t fully understand the magnitude of the costs being shifted from one party to the other, so they end up having extremely unrealistic expectations.

Are Fixed-bid Contracts Always Bad?

You can definitely leverage the potential benefits of fixed-cost contracts without running into the challenges outlined above. Here are some tips for making the most of fixed-bid contracts:

1. Ensure You Have a Solid Contract Review and Negotiation Process

2. Invest in Project Auditing

Independent ERP consultants, like Panorama, can ensure you are tightly managing scope, milestones, budget and vendor activities. Our project auditing services will help you maintain an on-time and on-budget project.

3. Don’t Forget About the Non-technical Aspects of Your Project

This is true of any ERP project, but it is especially true for fixed-bid engagements. Make sure you’ve designated enough time and resources for business process management and organizational change management. Odds are your vendor will not include these in their scope.

Qualities to Look for in a Software Sales Rep

The overwhelming majority of ERP vendor sales reps are good people. In fact, it’s in their best interest to give you a good rate because the idea behind making a sale is to turn you into a long-term customer. Vendors want long-term revenue streams that are predictable.

How do you tell if your sales rep is one of the good ones? Look for the following signs:

• Sells you the modules you absolutely need and never encourages you to purchase everything at once
• Includes hardware costs, project resources, integration, customization and other hidden costs in the total cost of ownership
• Includes all critical project activities in proposal and contract
• Estimates a deployment time based on the scope of all critical project activities
• Knows how to differentiate between processes that add value and competitive edge to your company and those that don’t

What is Your ERP Consultant’s ERP Contract Negotiation Methodology?

During the ERP selection process, many companies struggle to understand and compare vendors’ statements of work. Some of these companies hire ERP consultants to help them navigate the cost variables and negotiate favorable terms.

However, choosing the right ERP consultant can be just as confusing as selecting an ERP system. Any ERP consultant can claim to deliver vendor negotiation services, but not all consultants have an effective methodology. When evaluating an ERP consultant’s vendor negotiation methodology, consider whether it includes these four activities and deliverables:

1. Strategy Development

An ERP consultant should collaborate with you to develop an ERP contract negotiation strategy. Ideally, they’ll ask you about your goals and priorities. For example, is it more important for you to reduce operational expenses or reduce capital expenditures?

They’ll also help you determine which contract terms are most important to you. These may include terms, such as:

• Licensing payments should be spread over deliverables.
• Organization will spend x amount per year.
• Subscription costs will not be increased for x years.

2. In-depth Price Comparisons

You may have found that vendors’ quotes are not easy to compare. As such, the most valuable deliverable an ERP consultant can provide is a negotiation workbook showing apples-to-apples comparisons of your top contenders.

This is valuable because there is no universal standard for how ERP software solutions should be priced. For example, some vendors price their software with named users, while others price with concurrent users.

Apples-to-apples comparisons are also helpful due to the fact that vendors’ statements of work make various assumptions, such as:

• You’ll use all software functionality right away
• You’ll use x amount of out-of-the-box functionality
• You’ll need x amount of customization
• You’ll take x implementation approach
• You’ll use mostly internal resources
• You’ll be responsible for all ERP data migration

A negotiation workbook helps you understand statements of work based on your unique requirements and digital strategies instead of vendors’ assumptions. Your ERP consultant should help you understand your requirements by facilitating activities, such as:

• Determining an ideal level of software customization, and ensuring you’re only customizing when absolutely necessary (i.e., to improve your competitive advantage)
• Understanding how many internal full-time resources you can reasonably dedicate to the project and how many vendor resources you’ll need
• Understanding how long it takes to automate workflows in the system and how complicated it is, as well as who will be configuring workflows
• Determining which activities should be included in each project phase

Below is a sample negotiation workbook. The spreadsheet allows “what if” scenarios (i.e., what if you get a 30% discount):

3. Total Cost of Ownership Analysis

A long-term view of cost is just as important as a short-term view. The ideal ERP consultant will provide a three-year total cost of ownership analysis – or use whatever timeframe makes sense for the length of your ERP implementation.

This analysis should be included as part of the negotiation workbook. The analysis considers factors, such as:

• Payback Period – Panorama clients typically recoup the cost of their ERP project within three years.
• Benefits Realization Timeframe – Panorama clients typically realize full ERP business benefits from out-of-the-box functionality within 9-12 months of go-live.
• Deployment Model – Most ERP vendors encourage a cloud-hosting model and a SaaS licensing model. If you’re considering SaaS licensing, you may incur escalating annual charges for additional functionality, data or transactions.
• Licensing Structure – The number of users and types of users will affect your cost if you choose a user-based pricing model. Many ERP vendors underestimate the number of users to make their system seem less expensive.
• Implementation Approach – Will you use a phased, big bang or hybrid approach? If phased, will you phase per function or per module? Make sure your ERP vendor doesn’t expect you to buy all licenses upfront.
• Software Costs vs. Service Costs – You should aim for a ratio of 2:3 for software costs to service costs.
• Software Configuration – How long will it take you to configure each of your business processes? Are there any process dependencies (processes that need to be set up before other processes)?
• Resource Rates – Panorama clients typically pay $175-225 per vendor resource. If you negotiate this too low, you may end up with rookies on your ERP project team.

4. ERP Negotiation Guidance and Coaching

Your team has made large purchases in the past, and you don’t want ERP consultants taking control. The ideal ERP consultant will take a collaborative approach and be flexible enough to respond to your unique needs: they can negotiate on your behalf, prepare you for negotiating with ERP vendors yourself or attend calls with you.

Whichever method you choose, you should aim for cost savings of 30-60%. Your savings will vary depending on your organization size and your chosen ERP vendor. Some vendors don’t go below a 20% discount. You can achieve additional cost savings overtime by ensuring maintenance costs are based on purchase price rather than list price.

Panorama clients typically go through three to four rounds of negotiation, which can last anywhere from three weeks to several months.

Conclusion

It’s not easy finding an ERP consultant that focuses on all four of these activities. Panorama is one of the few that does.

If you’re not convinced these activities will save you money, take a look at these case studies:

• Panorama recently negotiated more than $15 million in savings on licensing costs alone for a large, multi-national client.
• Panorama negotiated cost savings for a client that could not afford their top-choice vendor and was about to settle for their second choice.
• Panorama saved a city government more than $500,000 in negotiations. The vendor was able to provide a lower price due to well-defined ERP requirements and expectations.

Typically, Panorama clients achieve cost savings that are ten times the cost of the negotiation services. And Panorama’s performance warranty ensures every client gets a significant discount on their software purchase or they don’t pay us a dime for our time spent negotiating on their behalf.

Engaging Panorama to assist with vendor negotiations will help you lower your total cost of ownership and mitigate risk.

At a glance, organizing ERP demos can seem like a simple task – find a system that seems to fit your needs, call the vendor and have a representative conduct a demo. By following this method, you are guaranteed to see several impressive software solutions, but you are not likely to find one that truly fits your needs.

While ERP vendors may genuinely believe they have the best ERP solution for your company, it is the responsibility of the ERP project team to read between the lines. In addition, your employees should provide input as to which ERP systems best fit your company’s processes and digital strategy.

The best way for employees to provide this input is by attending software demos and providing quantitative and qualitative feedback. Your company should schedule a demo for each of the enterprise resource planning systems on your vendor shortlist and invite employees from every affected department.

With the right methodology and independent guidance, you can organize ERP demos that help your company narrow down its vendor shortlist. Based on our client experience, we have provided several tips for preparing for and conducting effective software demos:

How to Prepare for an ERP Demo

Like most things in life, the more prepared you are for something, the better the outcome. That same principle applies to conducting a successful ERP software demo.

1. Prepare Your Processes

Reengineer Your Processes

Conducting business process reengineering prior to scheduling software demos will help you maximize ERP business benefits. You don’t want to simply pave the cow paths of what has worked in the past.

For example, if your company needs access to real time data to improve the customer experience, you’ll want to design processes to support this. These new processes then translate into business requirements, which help you evaluate the business intelligence functionality of various ERP systems.

Prioritize Your Business Requirements

Determine which processes give your company competitive advantage. These processes determine your highest priority ERP requirements and should not be standardized. While standardization in areas such as financials is usually advisable, areas like customer service should be protected from standardization.

High-priority requirements should meet two criteria: 1) They provide competitive advantage, and 2) They represent functionality that differentiates between different ERP systems.

While most organizations have a decent sense of what requirements meet the first criterion, they don’t have the internal knowledge base to address the second criterion. This is where independent ERP consultants are useful, as consultants like Panorama have extensive experience with a variety of ERP systems.

For example, many of our clients want to understand the difference between different systems’ inventory management and supply chain management functionality. We help them understand some of the differentiating factors, such as artificial intelligence and IoT.

2. Prepare the ERP Vendor

Explain Your Company’s Business Requirements

ERP demos are the finale of the requirements gathering process. You spent countless hours gathering business requirements, so make sure the ERP vendor understands them. This is important because an ERP vendor can’t demo what they don’t understand.

A vendor shouldn’t have to ask clarifying questions during the demo, so be sure they have access to subject matter experts long before the demo.

You should also create detailed business scenarios and ask vendors to run through the same processes in the same amount of time. This allows for apples-to-apples comparisons.

Provide a Demo Script

We’ve all attended software demos that are more generic sales pitches than personalized and relevant presentations. Some sales reps are especially skilled at selling their software’s “best practices” as one-size-fits-all functionality.

The key to finding the functionality best suited for your unique processes is creating a demo script based on your business requirements. If a vendor refuses to follow the script, consider it a red flag.

Your script should include a section that allows employees to see data move from the beginning to the end of a process. For example, if your demo is specific to showing the creation of a quality order, employees may want to see how the order is executed, how the variables are set up and how goods are quarantined when they don’t pass quality criteria. While these peripheral processes might not be the main objective of the demo, employees need to understand the full context. 

You’ll also want to ensure your script specifies that reporting work streams should be demoed alongside functional work streams. This gives employees a holistic view and gets them thinking about reporting requirements for implementation.

While a script is useful, you can’t predict everything employees will want to see. Employees may be eager to see a particular feature even it isn’t scheduled to be demoed. This impromptu demo request can be met if the right configurations are in place and the relevant data exists. 

Provide Data

Speaking of data, you’ll want to provide demo data to vendors, so they can demonstrate specific processes requested by employees. For example, the vendor’s existing demo data may be suitable to demonstrate typical manufacturing industry processes, but if your company is a car manufacturer it may not strike a chord if they are shown the quality management process for a batch of soda.

When a vendor createa data on the fly, this can derail a demo. Employees could become distracted, for instance, with the creation of a production order when the demo is about the quality management process.

Set Expectations

You should provide vendors with specific meeting times and a detailed agenda. Don’t let a vendor control the pace of your evaluation process by requesting to demo last or at a later date.

In our engagements with clients, we typically have the vendors spend the first hour of the day with subject matter experts addressing cross-functional requirements. This ensures vendors don’t waste time on these dashboards and workflows during the functional sessions.

Ensure an Adequate Number of Demo Staff

Having an extra demo resource who can illustrate actions taken by different roles can help employees visualize how the ERP system can pass data between different roles to accomplish a process. An extra demo resource can also be useful if the vendor needs to create impromptu demo data.

3. Prepare Employees

Be Informative

Provide information, such as the demo script and agenda, ahead of time, so participants have adequate time to plan for their absence within their departments.

Provide Guidelines

Oftentimes, ERP vendors steer away from the demo agenda to showcase special features, so participants must be trained to recognize this. Additional features that are not relevant to your requirements, should not be factored into participants’ final scores.

Another scoring guideline you’ll want to address is the importance of basing scoring on business requirements. Participants should evaluate ERP software based on requirements as opposed to vendor performance. When all is said and done, your daily life will revolve around the software, not the best performing vendor.

In addition, attendees should be instructed to be on time and attend the same sessions for each vendor. If participants aren’t consistent with attendance, they can’t provide reliable scoring. Our clients typically provide participants with scoring sheets based on demo scripts, so they can write comments as they go. This helps jog their memory when inputting their scores digitally.

5 Tips for Organizing Software Demos

1. Focus on the Goal

If you set expectations upfront, you are now in position to table questions that are not aligned with the goals of the demo. While you should be prepared to show certain features that are peripheral to your main objectives, you should also remind your audience of the expectations. After all, ERP software is too vast to demo every single feature.

2. Designate a Timekeeper

Once a demo starts to venture off track, it becomes difficult to make up for lost time. A demo that runs over schedule allows little time for questions and answers. While Q&A can always be conducted remotely, it’s most effective in person, so be sure your timekeeper alerts the room when it’s time for questions.

3. Develop a Method to Analyze Results

Feedback from participants must be recorded in a way that the project team is able to analyze afterwards. Make sure that everyone understands what each score represents and that you have a solid analysis process established to analyze the data.

4. Schedule Multiple Demos

It is important to schedule at least two to three ERP demos to give participants a chance to compare systems. Only demoing one software and making a decision by default does not ensure a best fit.

5. Leverage Several Data Points

While demos are a good starting point to help you evaluate long-list vendors, keep in mind that this information is provided by biased sources that have a vested interest in nudging you toward selecting their software.

In order to neutralize or validate any biases, it is important to leverage other data points from independent sources. For example, Panorama provides a number of free and unbiased data sources to aid your ERP selection process, including our 2019 ERP Report and 2019 Clash of the Titans Report.

Conclusion

A lot of prep work goes into guaranteeing successful demo sessions and a successful ERP selection. Panorama’s ERP consultants can assist your team in gathering requirements, preparing demo scripts, analyzing demo scores and assisting in all of the other activities outlined above.

While artificial intelligence (AI) is a relatively new technology, it has already demonstrated its disruptive potential and created a buzz in the software market. In fact, according to Gartner, as much as 80% of emerging technologies will have artificial intelligence as a key component by 2021.

Artificial Intelligence Within ERP Systems

AI allows ERP vendors to improve ERP systems using machine learning and natural-language interfaces. The AI in ERP systems provides actionable data insights enabling companies to improve their operational efficiency.

A good example of an AI-driven ERP solution is SAP Leonardo, which includes a number of microservices integrated with a cloud platform. Oracle also has introduced a number of AI-based tools for its ERP solutions, including digital assistants, advanced access and financial controls, and smart supply management.

Another example of an AI ERP solution is Coleman AI from Infor. You can ask this bot to suggest the next offer for a certain customer, create a requisition for a particular item and help you with many other tasks.

9 Ways AI Improves ERP Software

1. Advanced Analytics

AI’s ability to work with massive amounts of data enables real-time, accurate data insights. For example, AI can analyze the buying behavior of different categories of customers, enabling you to tailor your products or services to the needs of a certain audience.

2. Warehouse Management

Artificial intelligence can test countless demand forecasting models with precision, adjusting to different types of variables, including changes in demand, supply chain disruptions and new product introductions.

For instance, BMW uses learning algorithms to track an item from the manufacturing stage until the moment it’s sold, monitoring 31 assembly lines in different countries.

3. Forecasting

AI-driven solutions can process historical data and make predictions for the future. These tools identify seasonal patterns in your business, offering suggestions on whether you should decrease or increase production.

Not only does AI reduce the costs of forecasting, but it also makes forecasting much more accurate. You can significantly reduce the risk of underproduction or overproduction, when you manufacture the right amount of inventory.

4. Financial Management

AI can automate quarterly and monthly processes and closing operations by verifying reports for accuracy and comparing account balances between independent systems.

For example, AI can categorize invoice data into different accounts and discern the difference between a phone purchase and a monthly phone bill.

5. Interdepartmental Processes

Connecting sales, inventory and accounting is not an easy task. However, AI is not afraid of massive amounts and various types of data, making it the perfect solution for creating a centralized platform.

6. Customer Service

If your company does field service, AI can use information about performance evaluations and employee qualifications to schedule service calls and assist with planning.

7. Production Processes

When integrated with an ERP system, AI can detect inefficient processes and suggest a solution that will cut costs.

AI also can identify processes that use too much energy. It enables predictive diagnostics, minimizing the waste of resources.

8. Human Resources

Another advantage of AI-enabled ERP software is that it can be proactive. For example, it can detect what employees need a raise. In addition, it can analyze data on the skills and experience of applicants, expediating the recruiting process.

9. Sales Automation

Chatbots powered by AI not only help customers but also conduct the whole sales triangle. Now, bots can cope with segmentation and provide responses in real time.

Should You Select an ERP System With AI Capabilities?

While ERP systems have always been able to integrate various functions within an organization, AI takes this integration to the next level. It does this by analyzing large amounts of data, making predictions and suggesting next steps.

Panorama’s ERP consultants can help your company select an AI-enabled ERP system that increases your operational efficiency and improves your customer experience.

About the Author
Ester Brierley is a competent QA Engineer in a software outsourcing company. Also, she is a virtual assistant and a seasoned content creator for College-Writers, and knows the secret for balancing freelancing and her full-time job.

Note: The inclusion of guest posts on the Panorama website does not imply endorsement of any specific product or service. Panorama is, and always will remain, completely independent and vendor-neutral.

What’s one of the most important questions to ask before beginning ERP implementation?

Is our data clean?

If your answer is no, you’re not alone. Most companies have data spread across multiple platforms and formatted in various ways. Our advice to these companies is to cleanse and import data before implementation to ensure their ERP software delivers accurate, real-time data. Proactive data migration also ensures minimal downtime at go-live and reduces the duration of operational disruption.

However, ERP data migration is easier said than done. Most ERP vendors do not take responsibility for data migration or cleansing because it’s extremely costly. Therefore, your ERP project team must take on this responsibility.

Contents

1. 5 Ways Data Issues can Cause ERP Failure

2. 11 Data Migration Tips

3. Conclusion

5 Ways Data Issues can Cause ERP Failure

The perfect analogy to describe what an ERP system’s function is for a business is the heart to a human body. If the ERP system is the heart, then data is the blood moving from one part of the business to another – all flowing from and returning to the ERP system.

When data issues exist in your system, there are several ways this can cause ERP failure. Like the importance of blood in the human body, data cleanliness and integrity are essential for a successful ERP project.

Unfortunately, many ERP vendors exclude data migration from their deliverables. As such, it’s not surprising that 41% of respondents in our 2019 ERP Report reported that data issues caused their ERP project to run over-schedule. We also have seen data issues contribute to budget overruns.

So, how do data issues slow down an ERP implementation and propagate unexpected costs?

1. Your Integrations can Fail

If your business operations rely on partner data, such as shipping information, gift card balances or currency exchange rates, you probably have a few integrations to your enterprise resource planning system. When the data being passed back and forth between your ERP solution and a third party is unclean, it can cause your integrations to fail.

For example, let’s say your shipping methods are “Next Day” and “Standard Ground.” However, your shipping carrier has methods called “Next Day Air” and “Next Day Air Freight.” If your ERP system’s data is too specific (or in this example, not specific enough), the carrier might send back data that your system cannot accept. This will cause any records attempting to be created to error out. Your integration might attempt once more to create the failed records, and the cycle repeats itself. This can cause system performance to decrease and can slow down your ERP implementation process making it run over-schedule. Even though you’ve already gone live, the project recovery process still counts toward your total implementation duration.

We help companies avoid integration issues by preparing them for data conversion before implementation. This preparation involves developing a data strategy, defining the scope of data conversion and determining a data conversion approach.

2. ERP System Performance can Slow

Whether it’s from integrations attempting to repeatedly create records or from batch jobs running and erroring out, bad data can take a toll on your ERP system’s resources. This system lag can be amplified if your transaction volume is large, like during peak times in your business operations.

For example, data issues can cause a batch job to error out. Let’s say that your business runs both its master planning operations and point-of-sales operations through the enterprise system. Master planning is a system-intensive process as it accounts for many different variables like current sales, future orders and current stocking levels. For your point-of-sales operations, your registers and the ERP system need to communicate via a series of batch jobs to push the data back and forth.

If some of your future orders don’t have dates on them, the master planning job can error out. Your ERP system will continue to run the job, allocating more resources to it to balance the load. If your point-of-sales batch jobs start running at the same time, there will be minimal resources allotted to those jobs. As a result, cashiers may experience slower response times or no response at all.

Returning to the analogy of ERP software as the heart of business operations and data as the blood, when a person has a blood clot or blockage, the heart must pump even harder and expend more energy to deliver blood to the body. Sometimes, this can be fatal to a human body (or to a business).

3. Your Customer Satisfaction can Take a Hit

When your system has data issues, your customers notice. This is a data issue that has several prime examples. Consider a returning customer shopping online on your e-commerce site. She wants to buy running shoes to break in for a 5k she is running at the end of the month. She can’t remember what size in your brand fits her, so she looks up her order history to see what size she ordered in the past. Using her name and email she attempts to recall her profile, but the ERP system has duplicate records for her.

Let’s say the customer remembers her size and is ready to order. She checks the inventory levels that your site displays because a quick delivery is a key factor in her buying decision. The product seems to be in stock, so she makes the purchase.

However, it turns out the inventory levels displayed on your site were incorrect because of bad data in your system – your customer will not get her order for another two weeks. If you put yourself in her shoes, would you be a repeat customer?

Once a customer loses trust in your system’s data integrity, it’s nearly impossible to get it back. Consumers today rely on social media and review sites to determine where to spend their money. Disgruntled customers are more than happy to share their unpleasant encounters with the world, preventing you from gaining new customers without even interacting with them.

Improving the customer experience is an important business benefit for many companies. However, some companies do not cleanse their customer-facing data before migration. We recommend discussing data with all departments, so you can understand the various data sources and entry procedures.

If your business hopes to improve the customer experience, you should outline this goal before ERP selection so you can align every component of the project around this goal, especially the data component. Our ERP implementation methodology focuses on organizational alignment as this ensures the ERP software (and its data) support the organization’s goals.

4. Your System can Become Corrupted

Invalid data can cause your ERP system to become corrupted. Whether the data is invalid from a user error or from an automated system update, bad data can wreak havoc on your ERP system and cause functionality to behave unexpectedly.

For example, let’s say your business captures physical dimensions for products in various units of measure. You sell milk in liters and cheese in kilograms. Your ERP system has two item groups – one for liquids and another for solids. If your products are mistakenly assigned to the wrong item group, your cheese could be sold in liters, costing you money by charging much less than the quantity provided is worth.

This single mistake of assigning the wrong item group can cause a chain of downstream issues. When goods are shipped, the system may prompt the user to capture the weight in liters. As a result, all customer- and vendor-facing documentation may display orders for cheese in liters, making it confusing and even a little embarrassing to correct your ERP system’s data mistake.

5. Business Users can Make Bad Decisions

Arguably, the biggest failure that data issues can cause is allowing users to make key business decisions based on bad data. When users believe the system is correct, they don’t hesitate to order ten dozen more corrugated boxes because the warehouse inventory says they have zero on hand.

With bad data being the foundation of user decisions, inventory can be depleted or inflated. The same check to a vendor could be cut twice or not at all, causing your account standing to be damaged. Customers on an “opted out” list could be accidentally emailed by your marketing department and your company could be the target of a lawsuit. While some of these examples sound dramatic, they can be a reality if your ERP system is receiving or pumping out bad data.

Along these lines, once your business users distrust the data in the system, they will forever second guess your ERP system’s accuracy. For example, if a human resources manager denies a pay increase request for an employee because the data in the system says there is no budget, the employee might leave the company. If the human resource manager finds out later that the budget was incorrect, he or she might lose trust in the system’s data integrity.

In some companies, users distrust the data so much that they do their own data validation before making a decision, like exporting data into Excel and doing their own data massaging. This extra step of data validation outside of the system can cause inefficiencies in business processes and lead to low benefits realization.

Our ERP consulting services focus on change management during the data migration process. Designating process owners and data owners not only increases system buy-in, but it improves data integrity as these “owners” are accountable for ensuring data cleanliness and reliability.

11 Data Migration Tips

1. Assign Responsibility for Data Cleansing

There is a general misconception that the IT team can handle all the data cleaning. While there is data cleansing software, these packages can only help identify potential areas to be cleansed.

Someone still needs to know, for example, out of two different address records for a company, which one is correct. Also, someone knowledgeable needs to verify that a closing balance is in fact correct.

In most cases, the person who should cleanse these records is not in the IT department but is within the specific department that owns these records. These are called data owners, and they are critical for establishing standards and guidelines to maintain quality data.

IT staff should assist data owners by identifying the data flow, integration points where the data is being updated and what data sources exist.

Examples of Data Needing Cleansing

• Duplicate customer or supplier accounts
• Master data that isn’t classified with a common taxonomy
• Blank description fields for products
• Old product codes no longer in use
• Data for a customer that has gone out of business
• Critical data in Excel that is not in your system of record

2. Remove Duplicate Data

Duplicate items can be identified in two main ways: 1) Direct duplicates include two or more items possessing the same manufacturer name, part number and description. 2) Fit-form-function duplicates include two or more items that possess different manufacturer names and part numbers but have the same fit, form and function.

3. Don’t Migrate All Your Data

Companies continue to persist in the idea that they can migrate all the data from the legacy system over to new ERP software, and the software will somehow magically scrub and standardize it. That’s just not the case.

If you’re moving to a new house, would you put trash and clutter in the moving truck? Probably not, so when you’re moving to a new ERP system, you don’t need to bring over every single piece of data. Some of this data is unclean, unnecessary or pure junk.

The more useless data you bring over, the harder time you will have finding the data you really need, which can delay go-live.

Companies tend to hoard data, believing that someone, somewhere down the line just might need that one nugget of information. An ERP project is a great opportunity to clean house.

4. Determine What Data to Migrate

This can depend on what industry you’re in and your forecasting needs. Determining what data is important should be a collaborate effort that involves all departments.

5. Determine Resource Requirements

You will need developers to convert data and data owners to review and cleanse data. In addition, you may need executives to review certain types of data. Most likely, this will include data elements that relate to the core of the organization’s culture. These may be items your organization has avoided because they seem too hard to address.

Other resources you may need include resources for change management and business process management as you likely will need to train employees on how to input, manage and analyze data once the new system is implemented.

6. Consider Industry Regulations

Different industries have different regulatory requirements. For example, some regulations restrict the ability to change and/or export certain kinds of data records, such as HIPAA with electronic medical records.

You should carefully consider your method of data cleansing (e.g., in-system vs. Excel) if your company has industry-specific regulatory requirements.

7. Consider the Data Complexities of Global Projects

In global ERP projects, you’ll encounter different systems speaking a variety of ERP languages layered on top of cultural and language differences. It is vital to identify these complexities early and communicate to your project team where you see the need for executive decisions. This will eliminate slow periods in the data conversion, allowing developers to stay engaged.

If your project is global, you also will need a signed document from the executive steering committee stating who is responsible for data at the global, regional and country level for both master and transactional data.

8. Define Taxonomies and Attributes

Most ERP systems use some sort of taxonomy to classify items. Master records must be classified correctly, completely and to a level of detail that makes the record easy to identify for search and reporting functions.

While it is not necessary to choose one particular taxonomy, it is necessary to have a taxonomy that supports your company’s business initiatives. Therefore, you should ensure your ERP consultant has experience with taxonomy selection and deployment.

Item record attributes play a similar important role. Attributes define the item and are important for successful parametric searches. Incomplete or incorrect attributes prevent items from being found, resulting in proliferation of parts and bloated inventories.

To ensure a successful ERP data migration project, we recommend extracting, normalizing and completing item attributes beforehand. Because of the sheer volume of attributes to be extracted and enriched, an automated approach is the only practical way to execute this.

9. Develop New Processes

Once the initial data cleansing is complete, you will have more data to cleanse – unless you ensure employees adopt new processes that enable data accuracy. Even though these processes may be designed for legacy systems that will soon be retired, these processes are still worth developing. Consider the fact that most ERP projects last years. Can you endure two more years of dirty data?

We recommend that companies redesign their business processes and train employees both for the future state and this interim state. Both business process reengineering and organizational change management play a critical role in maintaining data cleanliness.

10. Test Before Migrating

Discover if you’re on the right track with your data by moving data to test environments. This will be time consuming and typically requires the development of unique code. Don’t make the mistake of leaving it until the last minute.

11. Use Your Data to Make Business Decisions

With your data migrated, your new processes established and your employees on board, you can almost breathe a sigh of relief – but not quite yet. Now, you must figure out what to do with your data insights.

Companies that have their eye on realizing business benefits from their ERP systems tend to address this issue early with change management and business process management. Knowing that an ERP software solution will enable increased data visibility, forward-thinking companies take advantage of this benefit by establishing data analysis processes. These companies also spend time training employees on these new processes.

Conclusion

Data migration is not usually a priority at the beginning of an ERP project. Instead, the focus is often on planning and design, while data migration is a muddled topic that people tend to avoid.

When companies avoid or delay data migration, their new system will provide unreliable data leading to technical challenges, customer dissatisfaction, low system usage and low benefits realization.

While data migration and cleansing may add cost to an already expensive ERP project, the effort will pay for itself almost immediately through the identification of excess inventory, reduced equipment downtime and improved data insights.

Panorama’s ERP consultants can help your organization develop a data migration strategy that ensures your ERP software provides reliable data to all stakeholders from the minute it goes-live until it’s retired.

When your organization decides to implement a new ERP system, it can be an exciting time for employees. There is hope on the horizon that the tedious workarounds or functional gaps within the current system will be replaced with a better and more advanced system.

It’s likely that your employees started making wish lists as soon as you announced the ERP project. These wish lists will continue to grow until someone (likely project management) reminds the team of the project constraints.

Anyone experienced in organizational change management will tell you that excitement around a new ERP implementation is a key success factor in user adoption. While turning away employees’ wish lists due to budget or time limitations may dampen the excitement, you also must control project scope.

So, how do you implement a new ERP solution while ensuring both project feasibility and employee engagement? The answer is prioritization of ERP requirements before ERP selection.

Prioritizing ERP software requirements may sound like a simple task, but when all parts of the business believe their functional requirements are the most important, you may find yourself in a stalemate. Luckily, there are several strategies you can use to help your team reach a consensus and ensure a successful ERP project:

1. Clarify the Project Goals and Scope

You may be familiar with the “project management triangle” or “triple constraint” where scope, time and cost are depicted on each corner of a triangle with quality in the center. Usually, before an ERP project has begun, all three of these constraints are already decided. While time and cost are easy to quantify as the project progresses, scope can run amok – especially when it comes to meeting business requirements.

It’s because of this scope ambiguity that project kick-offs are important. With all team members (business users, analysts, ERP consultants, stakeholders, etc.) present, you should clearly define the business objective of the project and identify items that are definitely out of scope.

The goal of your project could be as simple as moving off your legacy system due to end of support or as complex as overhauling your e-commerce experience to modernize your customer service. Whatever your goal, make certain that all team members understand it, as this will minimize the amount of non-critical business requirements that arise during ERP requirements gathering.

2. Define Baseline Business Processes

Identifying the business processes that will be impacted by the ERP project helps you define project scope. In addition to identifying these processes, your team should document them as they exist in the current system. This will help establish a list of minimum requirements needed to keep the business operating.

When documenting business processes, the ERP project team should focus on business needs and not confuse current system limitations with what is truly needed. This is not the time to define future state processes but just to listen to employees’ needs.

3. Improve Your Processes

If you need to increase efficiency, break down silos or achieve another important business benefit, then business process reengineering is your new best friend. We recommend conducting business process reengineering before considering standard ERP functionality. Why before? It’s because functional areas that bring competitive advantage – such as customer service or supply chain management – should not be standardized.

Once you’ve improved the processes that differentiate your company from competitors, you can begin looking at ERP functionality. This will help you determine how to improve processes that may need to be standardized. These might be processes related to finance or human resources.

While differentiated processes should not be standardized, this is not to say that standardized processes can’t bring competitive advantage. In fact, ERP vendors spend countless dollars and hours refining system capabilities to meet the most frequently asked for features to appeal to the widest customer base. Taking advantage of a process recommended for your industry can help you to stay competitive.

4. Perform a Fit Gap Analysis

Now that you’re looking at ERP functionality, you can perform a fit gap analysis. This helps you identify where a new system fits your company’s requirements and where it doesn’t. Basically, for each requirement gathered, you should determine if each ERP system on your long list can meet the requirement natively (fit) or requires a modification (gap).

Requirements that are considered “fits” and can easily be configured are usually no-brainers when it comes to priority. Fit requirements that involve some additional effort, like a data conversion for example, can also be prioritized as these are usually easy wins for the project team.

Gap requirements, however, should be put lower on the priority list. Having a long list of gaps makes prioritization challenging, so you may want to weed through the erp requirements list to determine if the system can support these requirements in a different way than anticipated.

If there are any remaining gaps, you can justify these gaps by conducting a cost analysis. Here are some questions to keep in mind when justifying gaps:

• What is the business impact if this requirement is not met?
  • Additional labor requirements?
  • Dollars lost?
  • Customer satisfaction impact?
  • Compliance issues?
• Will this impact the project timeline?
  • How many hours are required?
  • Does the project have the appropriate resources to complete the work?

Based on this analysis, a cost can be associated with each gap requirement to determine if it can remain as a lower priority.

5. Classify Business Requirements

Now that all valid requirements are on the table and the gaps have been justified, the project team can classify each requirement into one of three categories: must have, value added and nice to have.

Must-have

Any requirement that falls into this bucket is mission critical. Classifying a requirement as a must-have, signifies that the business cannot operate without it.

The dollar amount determined during the cost analysis of this requirement should be subtracted from the project budget since it is assumed this requirement will be met. Continue to subtract from the overall budget as requirements fall into this category as seeing the dollar amount decrease will help the team keep perspective as to which requirements are really a priority.

Value-added

Value-added requirements are not mission critical. However, requirements that fall into this category could greatly enhance the business.

For example, let’s say your project mission is to simply replace the legacy system with new ERP software. As such, you are not designing new business processes that don’t already exist in the current system. If the current system does not have the ability to send customers an email when their online order has shipped, then this requirement is not technically within the project scope and is not a must-have requirement.

Considering that email confirmations are pretty standard in the e-commerce industry, meeting this requirement could add a lot of value to your company if you operate within this industry. That’s why this is an example of a value-added requirement.

Nice-to-have

Requirements that are classified as nice-to-have are often addressed in a later phase of the project. These types of requirements are those that are neither mission critical nor add a great amount of value to the business.

For example, a business user might want the ability to request a report that identifies the amount of late deliveries per vendor. While this data is readily available in the system, the user wants a report that provides a summary view. This would be considered a nice-to-have requirement.

When classifying requirements, we recommend keeping the project budget, timeline and scope top of mind. Also, it’s important to ensure collaboration among all departments and stakeholders, so you have a well-rounded perspective on what the business should prioritize.

What ERP System Fits Your Company Best?

The only way to answer this question is to prioritize your business requirements. This calls for organizational alignment around project goals, a clearly defined scope and, more often than not, process improvement.

Panorama’s ERP consultants are experts in business process reengineering and software selection. We can help your company find an ERP software solution that meets your highest priority requirements as well as several value-added and nice-to-have requirements.  

If your company is beginning ERP selection, you’re probably thinking a lot about cost. How much does system A cost compared to others? Does this fit within our budget? As important as these questions are, they miss the bigger picture – the total cost of ownership. In other words, how much will the implementation cost in addition to the cost of the technology itself?

A company’s unrealistic expectations regarding total cost of ownership is often the first domino to fall in an ERP failure. This leads to failure because companies end up cutting corners on activities that are critical success factors.

Inaccurately estimating ERP project costs is more common than you might think. In fact, ERP vendors typically outline a one-dimensional estimate of implementation costs. These estimates often fail to include hidden expenses, like internal resources, external consultants and hardware upgrades.

Further, a software vendor will usually estimate implementation costs to be a 1:1 ratio between software licenses and technical implementation costs. This technical implementation cost is woefully low for most companies.

So, why do vendors make such low estimates? Sometimes, sales reps are trying to lowball their estimates to get the deal closed. Other times, sales reps do not truly know the costs required to make an implementation successful.

Contents

1. Common ERP Project Costs

2. How to Scope Your ERP Project

3. How to Control Costs

Common ERP Project Costs

Below are some common project costs, beyond the cost of the software itself. We recommend carefully quantifying these costs before investing in ERP software, so you can accurately weigh ERP business benefits vs. costs.

While these are not all the costs associated with an ERP project, they are the ones that are most likely to be overlooked during the budgeting and planning process.

1. Change Management

Many companies assume that the ERP vendor or systems integrator will handle this, but many don’t. Those that do, still require involvement from your internal employees.

Training, for example, is one component of organization change management that requires internal resources. Vendors and systems integrators will typically train the internal core team on how to use the “vanilla” software, but rarely customize the training to reflect the company’s unique software configurations and customizations.

As a result, your internal ERP project team must take charge of training activities. Not only should they customize training materials for software configurations, but they also should customize them for employees’ unique business processes.

In addition, there are a host of other change management activities that the internal ERP project team should be responsible for, including communication planning, business readiness assessments and focus groups, to name a few.

2. Business Process Management

Enterprise resource planning software presents an opportunity to standardize your operations across multiple locations and redesign processes that need improvement. This requires internal time and resources.

Don’t assume that the software will provide all the answers on how to run your business. Instead, recruit an internal team to help design your future state.

3. Resources for Backfilling

This might include contract or other employees you hire to manage the day-to-day activities of project team members who are no longer able to commit to their usual jobs.

4. Hardware and Infrastructure Upgrades

It is rare that an organization can implement a modern ERP system without a modern IT infrastructure to support it. Servers, databases, bandwidth, PCs and other components of an organization’s IT infrastructure often need to be upgraded to support the new enterprise system.

In addition, IT staff often need to be augmented with additional resources, training or outside consulting to support the new environment.

These costs are significant. Many companies implement cloud based solutions to save money on resources and infrastructure.

5. Longer Than Planned Implementation Duration

Given the amount of resources, time and money dedicated to an ERP project, even the slightest delays will affect the budget. To avoid delays, be sure your project plan includes overlooked activities, like requirements gathering, system design, testing, ERP data migration and interface development.

How to Scope Your ERP Project

Your project scope directly influences your project budget. While many organizations scope their project based on number of modules or number of users, we recommend considering other factors, such as the scope of change required to achieve business goals and your employees’ level of change readiness.

Here are three tips to keep in mind when scoping your ERP project:

1. Account for the complexities of your business.

Is your business relatively simple, or is your business a complex set of business processes supporting a diverse line of products? Be sure to get an independent view of your organization’s complexity when planning your ERP implementation. In other words, seek input from someone besides the person selling you the software.

Many complex businesses need a full ERP software solution that addresses all of their functional areas (human resources, supply chain management, etc.). Less complex companies may be looking for a point solution to address one specific area, like customer relationship management. Standalone CRM software or human capital management software can be integrated with a company’s main ERP system to extend the functionality.

2. Focus on people and processes.

Technical activities are rarely the cause of project scoping issues. Instead, the primary causes are related to business process reengineering and change management activities. For example, failing to improve your business processes before selection can lead to unexpected costs during implementation.

3. Benchmark against other organizations.

We have all heard the anecdotal stories about what to expect from ERP projects. However, these isolated examples are rarely indicative of what the average project looks like. We recommend looking at broad sampling of organizations similar to yours to gain an understanding of what your project costs may be.

For example, our 2019 ERP Report reveals that SMBs use an average of seven full-time internal resources, and large enterprises use an average of 24 full-time internal resources. This does not necessarily mean that these people were committed 100% to the project. While some organizations may have had seven people spending half their time on the project, other organizations may have had 14 people spending a quarter of their time on the project.  

How to Control Costs

There is a fine line between cutting costs to save money and undermining the success of an EPR project. Cuts to ERP budgets that look good on paper can have disastrous consequences in the long-term.

Here are a few tips to help you control project costs without cutting essential activities:

1. Set realistic expectations.

More often than not, ERP vendors and their system integrators mismanage expectations on what total costs will look like. This makes it difficult for your company to set realistic expectations. As a result, you may end up presenting an inaccurate business case to executives.

When you realize your mistake, you may find that executives aren’t willing to increase the budget. While you may still encounter executive resistance if you have realistic expectations upfront, this is much less painful than losing your job because you set unrealistic expectations that resulted in a botched implementation.

Our ERP selection methodology helps clients develop a realistic business case. A business case should be used for more than just convincing executives to approve the project. It should also be used to prevent budget overruns.

2. Detail each of the cost components.

Setting realistic expectations requires an understanding of all essential project costs. This includes the obvious costs as well as the hidden costs: hardware upgrades, maintenance, internal resources, external consulting support, customization and a host of other budgetary items that companies often overlook or underestimate.

If you’re not sure what costs to include, we recommend developing a project plan. When we help clients develop project plans, they typically avoid incurring unexpected costs.

Once you have identified all the major cost components, you can then benchmark these line items to actual costs for companies similar to yours. Our 2019 ERP Report can be a good starting point for setting realistic benchmarks.

3. Respect the “untouchables” of your ERP budget.

There are certain, critical elements of an ERP project that should never be considered for the chopping block. One example is organizational change management. On paper, it may appear that you could save millions of dollars by removing all change management activities from your project plan. However, this doesn’t reflect the financial impact of employee resistance, project delays and other common risks of neglecting change management.

On the flip side, you will want to identify the areas that you can remove from your budget if necessary. For example, customization is one area that many companies decide not to spend too much money on, and this usually has few, if any, consequences.

As a general rule, if you want your project to be successful, then your budget should reflect a heavier focus on the business aspects of the project rather than the technical aspects.

4. Take your time during ERP selection.

Too many companies rush into ERP as if the world is going to end without it, and they don’t take the time to clearly lay out their business requirements. We recommend involving employees in ERP requirements gathering sessions to ensure your potential ERP solution can support the most important processes from each functional area.

One of our recent clients saw significant cost savings during implementation by investing in a thorough selection process. The CFO of the organization commented that the investment in selection did not increase the total project budget because money that would have been spent later in the project was simply spent earlier.

5. Negotiate with ERP vendors.

Did you know vendors may give you a discount if you negotiate with them? It’s true!

However, this is easier said than done, so most companies that want to negotiate their ERP software contract, hire an expert. When we help clients negotiate with vendors, we provide a total cost of ownership analysis that helps clients compare software contracts. In addition, we typically conduct three to four rounds of negotiation to reduce licensing fees and implementation costs.

How Much Does ERP Implementation Cost?

If you want an accurate estimate for your project, be sure to accurately scope your project and account for some of the most overlooked costs. Panorama’s ERP consultants can help you set realistic expectations that won’t scare executives nor get you fired for causing budget overruns.

ERP projects can be lengthy. Depending on the scope of the project, implementation can last anywhere from six months to three years. After implementation, ERP software should support an organization for at least five to ten years. As you can imagine, choosing an ERP solution to scale with your business is an important consideration when selecting an ERP system.

Software scalability refers to a system’s ability to keep pace with your businesses’ trajectory. This means that an ERP solution should be able to take on new markets and handle exponential increases in transactional volume, workload and amount of data.

When looking for a scalable ERP solution, we recommend asking ERP vendors about factors, such as global functionality, infrastructure options and integration capabilities. Most importantly, ask them how they address the latest technology trends, and how they can adapt to your future business needs.

In addition to asking questions of vendors, you should also investigate several questions on your own:

4 Scalability Questions 

1. Does the ERP System Have Global Capabilities?

One way that many businesses expand is through globalization. If your company currently is in the US market but plans to expand to the rest of North America and eventually to Europe and Asia, you may want to consider an ERP system that offers a global solution out-of-the-box. Here are some considerations:

There are some countries for which many ERP systems have difficulty complying with their tax rules and government regulations.

For example, Brazil has one of the most complex tax systems in the world, and oftentimes ERP consultants will need to specialize in – or at a minimum – have experience with Brazilian implementations to be successful. Knowing this challenge, some ERP vendors have come up with “localizations” specific to countries to help companies doing business in other countries stay compliant.

Another example is the data localization laws in Russia. The laws require that data relating to Russian customers must reside on servers within the country. This poses a challenge for companies beginning a new ERP implementation or expanding an existing ERP system.

Other countries, like China, are adopting similar data localization laws, forcing many ERP vendors to build localizations for their customers.

Languages

If your business wants to compete in the global marketplace, it must advertise and transact in a multitude of different languages.

For example, vendor-facing documents, like requests for proposal (RFPs) or purchase orders, must be in the local language. Customizing reports for different languages can be costly and time consuming.

The same thing can be said for customer-facing documents, like sales orders and invoices. If your business maintains an e-commerce presence, this adds another layer of complexity regarding languages and translations.

Many ERP vendors today provide out-of-the-box language translations to support global customers. When assessing if an ERP system is the right fit for your business, make sure to ask about language options to prevent an unwelcome surprise when you scale your company in the future.

2. Does the ERP System Have a Scalable Infrastructure?

As your business grows, you want your ERP system infrastructure to be able to grow with you. This may look different depending on your IT infrastructure:

Cloud Scalability

It’s easy to change the specs of your underlying cloud infrastructure by talking with your cloud service provider (CSP). Some CSPs, like Microsoft or Amazon Web Services, offer different subscription plans based on your business needs. They can also see your transactional volume and tune your virtual machines accordingly to give you high performance.

The ability to scale has become even easier today with SaaS ERP systems. The CSP assesses your unique situation to determine how many database servers you need with what specs. This is just one of many advantages of SaaS ERP systems.

On-premise Scalability

If your organization must keep its technology on-premise, there are still some scalable ERP solutions available. Consider ERP systems that tune performance based on the number of servers dedicated to it. This allows your business to procure additional servers to accommodate larger transactions sets.

Scaling on-premise infrastructures is doable but more costly compared to scaling cloud solutions. Data storage, for example, is more costly in an on-premise system, especially when you’re dealing with a large amount of data.

3. Does the ERP Vendor Have a Futuristic Outlook?

The ability for employees to perform tasks from mobile devices is becoming the norm, and if your company doesn’t already allow this, there’s a high chance it will need to in the future. ERP systems that offer mobile solutions and integrate with IoT and machine learning are considered on the visionary end of Gartner’s scale.

Even if an ERP solution does not have these capabilities built in, an ERP vendor should at least have these ideas on their roadmap. If an ERP vendor can’t speak to their future vision in relation to these technology trends, it is a red flag that their software might not be scalable for your business.

Many companies we work with have a futuristic outlook, so they are looking for an ERP vendor that does, as well. We recommend conducting business process reengineering before ERP selection, so you know what the future state of your business looks like and can find an ERP vendor that meets your needs.

4. Does the ERP System Have Adaptability?

During ERP selection, adaptability is a key factor to keep in mind. Even though your organization may not take advantage of all the features offered by the software immediately due to budget constraints, there may come a time in the future that you will.

ERP software that has feature sets across a wide variety of industries can be helpful in the future, as you may be able to use some components to meet new ERP requirements – as opposed to purchasing a third-party software for a specific need.

If you plan to expand your company’s business model and offer different products or new services, here are some ERP selection considerations:

Business Model Expansion

Perhaps your current business model is only for the manufacturing and sales of a certain product, but in the future, you want to expand to offer installation services, as well. Your current ERP system may not have a services module or feature set that will allow you to take advantage of this without disrupting your current manufacturing processes. You could purchase another software package to handle selling and providing the installation services, but eventually your disparate systems will need to exchange data. This requires a custom (and expensive) interface and an internal or external IT team dedicated to database management.

The ability to add new features or modules without affecting current business processes is a key indicator of whether an ERP solution will scale with your business.

Easy Integrations

Another feature to keep in mind when selecting an ERP system is the ease of integration. Luckily, ERP vendors today often partner with third parties to build “plug and play” connectors that provide holistic solutions to customers, especially for certain industries.

For example, several ERP systems that cater to the retail industry have pre-built credit card payment connectors that allow businesses to accept credit card payments. If your business doesn’t accept credit card payments now, but you have plans to in the future, then asking about potential connectors is a wise choice.

Realistically, every ERP system will not have pre-built connectors for every interface requirement. Asking about the ease of building custom integrations is important, as it’s very likely you’ll need to build one in the future. You might bring a new vendor into your business environment, or your reporting requirements may change from sending PDFs to a form of electronic exchange. Whatever the need is, finding an ERP solution that will allow you to easily integrate with outside systems will help you to scale in the long term.

Workforce Expansion

If your company plans to make any acquisitions or push for a big hiring campaign, you’ll need to determine if the ERP system can handle a large increase in users.

Every ERP vendor markets their software based on the size of the business supported. For example, SAP Business One targets small- to mid-sized businesses.

When vetting your ERP choices, it’s good to be realistic in your predictions of the future. You don’t want to pay for hundreds of extra licenses if you will never use them.

4 Tips for Scaling Your Company for Growth

While finding a scalable ERP system will help your company grow and transform, an exclusive focus on technology limits your ability to do so. Following are four tips for preparing your company for aggressive growth:

1. Standardize Your Processes

Eliminating non-value-added activities and increasing operational efficiency is just part of the equation when it comes to scaling for growth. You also should standardize business processes across business units and office locations. This enables you to decrease costs and provide a repeatable operational and system template.

2. Enable Flexibility

While it may appear to conflict with the standardization mentioned above, businesses in growth mode also need flexibility. After all, business processes in the Asia-Pacific region likely will look much different than those you design for North America. As such, we recommend localizing your processes by region, customer and product line when applicable.

3. Integrate Your Operations

Lack of integration of information and processes is one of the more common pain points we hear from clients. For example, when a manufacturing group becomes aware of production bottlenecks that will likely delay key work orders, that information isn’t always accessible to sales teams.

While ERP systems enable this integration, you also should equip your people and processes. In other words, design end-to-end processes and train your employees to perform them.

4. Ensure Access to Real-time Data

Just as different departments should have access to integrated information, your executive team should have visibility into the entire organization. For example, COOs want to know what demand the sales team is forecasting so they can plan their production accordingly.

This type of decision-making information is one of the most effective ways to scale for growth. If you want to ensure access to this type of information, then paying close attention to data migration during selection and implementation is essential.

What Can Change in Ten Years? A lot!

An ERP system should last your organization at least ten years. During this time, your company likely will go through some major changes. It’s important to determine if an ERP system can support these changes, before you select and implement it.

Panorama’s ERP consultants can help your company assess the scalability of various ERP solutions, and help you select a system that can deliver long-term ERP business benefits.

If you’re considering an ERP implementation, you’re probably not enjoying the process of obtaining budget approval. Executives have a litany of questions, some of which you aren’t prepared to answer.

While you can’t anticipate all of their questions, we will help you answer one of executives’ most common questions: “Who needs to be on the ERP project team, and how much time will they need to dedicate to the project?”

Providing a detailed answer will require an understanding of what it takes to build a winning core team.

Contents

1. Who Should be on Your ERP Project Team?

2. Project Team Personality Traits

3. How to Build an ERP Project Team

4. How to Find a Good ERP Project Manager

5. What Other Internal Resources Will You Need?

6. 5 Roles of a Change Management Team

7. What About Outsourcing?

Who Should be on Your ERP Project Team?

Depending on the size of the organization and the scope of your project plan, your team might range anywhere from 15 members to just a few. At minimum, you need representation from each of your organization’s functional areas. Look for people who understand multiple parts of the business, not just their own little world.

If you’re using ERP consulting services, the consultants likely will recommend that you secure a certain level of commitment from certain internal groups in order to augment external resources. Leveraged appropriately, the following groups can facilitate a more effective ERP selection, implementation and/or business transformation:

1. Executives

Every successful ERP project needs an engaged executive team. Executives must be ready and willing to kick-off the project and remain active participants.

It’s important to have an executive sponsor for your ERP project. This person will be heavily involved in the selection and implementation process, giving guidance when difficult decisions arise. Executive sponsors will encourage employee buy-in by displaying unwavering commitment to the ERP project.

2. IT Team

An ERP project should be a collaborative endeavor, where your IT team is heavily involved. Your IT team will be essential, not just in implementation, but also in maintaining your ERP system.

However, as the demand for skilled IT professionals continues to rise, many companies are finding it difficult to procure IT resources for their ERP projects. If your team is lacking IT skills, consider providing training opportunities or look for outsourcing opportunities.

3. HR Team

You might not know it, but the human resources professionals that you employ might be some key contributors to your ERP project. HR professionals can help you obtain external resources for the ERP project. Many companies need external resources for backfilling.

In addition, HR has their ear to the ground and will often know about the roadblocks employees encounter. This is helpful for identifying pain points as well as processes that are redundant or inefficient. Your HR department also can be of great assistance with organizational change management.

4. Employees who can Help With ERP Selection

ERP selection involves requirements gathering. Your project team can prepare employees for requirements gathering sessions by developing workshop guides, which get employees thinking about their processes. The project team also is responsible for conducting requirements gathering sessions and ensuring all essential requirements from all departments are documented and prioritized.

ERP selection also involves business process reengineering and ERP vendor demonstrations. Your project team can ensure the right people are involved in these activities. While these people may not be project team members, they should be heavily involved in the selection process. Involvement facilitates project buy-in and organizational alignment.

5. Employees who can be Change Agents

Change agents are team members across the organization who support your ERP implementation strategies and goals. The most important change agent is the project manager. This point person should be capable of leading the project team and demonstrating accountability and transparency.

Change agents are responsible for communicating goals and status updates to employees. Change agents create excitement and help diffuse rumors by being accessible and willing to answer questions.

6. Employees who can Manage Training

Other change agents are the team members responsible for training. They often take on the role of the “super user,” – people who not only buy into the change, but who also know how to make the most of the new system.

Super users might host workshops or provide personalized instruction and assistance to ensure employees are ready and able to operate the new ERP solution. While super users don’t replace formal training, they make it comfortable for employees to ask questions.

Project Team Personality Traits

Organizations must identify skill sets and personality traits that contribute to business transformation success. Professors Kenneth Benne and Paul Sheats published a study, Functional Roles of Group Members, in which they identified key personality traits that contribute to strong teams. Here are five of those personality traits:

1. The Cheerleader

This team member should encourage other project team members to participate and recognize them for their contributions. This role is useful for encouraging engagement on both the project team and throughout the organization.

2. The Peacemaker

This member helps project team members reach a consensus when compromise is necessary. Peacemakers focus on the success of the organization as a whole. This role is useful when defining and prioritizing business processes.

3. The Sergeant-at-Arms

This member ensures the project team meets deadlines and expectations while adhering to the organization’s core values. This role can help develop strong project controls and governance and gently remind team members of these guidelines.

4. The Good-Humor Man

This member helps relieve the tension and anxiety of business transformation. The right amount of jest can lighten the mood and reenergize team members.

5. The Contrarian

This member is a critical thinker and innovator who is not afraid to share their opinion. This role can challenge project team members to think about the project from a people and process perspective instead of a technical perspective. The contrarian can also ensure that the project team preserves the organization’s competitive advantage during business process management. They are long-term thinkers who can help align the ERP project with the organizational vision.

How to Build an ERP Project Team

It is important to start building your ERP implementation team before ERP selection to avoid falling into the trap of poorly resourced teams, lack of representation from key business areas or low accountability. Below are a few things to consider when assembling your project team:

1. Seek Executive Sponsorship

Executives can have a strong influence on who is selected to serve on a project team so it’s critical that executives are on board with the goals of the project. The project manager is responsible for ensuring that executives are well-aware of project scope, project budget and project resource requirements – and aligned in terms of overall goals and project priority – so that executives can make informed decisions when helping project managers choose team members.

2. Look for Strong Communicators

Some organizations build their project team based on who they believe to be the smartest or most technically skilled. While technical expertise and operational knowledge are important, communication skills are also valuable, especially when the project team must execute a change management plan.

Communication is also essential during requirements gathering. Team members will need to be vocal during this phase to ensure the business requirements from their department are represented. Ensuring all business requirements are met in the new ERP system is essential for ERP selection.

3. Make the ERP Implementation the Team’s Top Priority

At key points throughout the project, your project team may need to devote their entire focus to the ERP project rather than their day jobs. In a perfect world, the project team would be fully dedicated to the project during these times, but that’s not feasible for most organizations.

Project managers and executives must help the project team prioritize work, so the project is a top priority. Some organizations staff their project teams with a certain amount of external resources to ensure project team members can more fully focus on the ERP project.

If your organization’s communication about the project have been sparse, your project team probably doesn’t understand the importance of the project’s success. Overcome this hurdle by taking the time to talk to address concerns on an individual basis before assigning responsibilities. If some of your staff are already up to their ears in another major project, respect the preexisting situation and try to limit their involvement in the ERP project until the time is right.

4. Clearly Define Roles, Responsibilities and Accountability Measures

Project team members should be assigned responsibilities in accordance with their strengths, experience level and bandwidth. Begin defining roles and responsibilities at the beginning of the project to ensure accountability and representation from key business functions. Responsibilities can include anything from process definition to end-user training.

You can use a project charter to assign responsibilities for each phase of the project. The project charter defines exactly who is responsible for what as well as how decisions should be made and how issues should be resolved.

In addition to defining what team members are responsible for, you also should define what they’re not responsible for. For example, final sign-off on future state business processes and decisions about the organization’s operational model should not be driven by the project team but the executive steering committee. In several of our expert witness engagements, we have seen steering committees delegate everything to the project team.

5. Avoid Bad Hires

Not only can a bad hire derail an ERP project by not performing their duties, but they can impact the attitude of other employees. These employees may already be on edge because of organizational changes when a bad hire comes along and gives them another reason to resist change.

Many companies don’t know how to hire for an ERP project. They don’t know what questions to ask, how to evaluate technical skills or how to assess cultural fit. Panorama’s IT Staffing services help organizations overcome this hurdle. We offer a flexible array of contract, contract-to-hire and permanent placement services.

How to Find a Good ERP Project Manager

If a company has a weak project manager, no one knows who is responsible for what or whether progress is being made. Here is a list of five qualities a project manager must possess for your ERP project to succeed:

1. Organized

People waste time when they are hunting for lost emails or switching between devices to find what they need. Being organization not only increases efficiency but helps make and reinforce good impressions.

Every workplace has at least one desk that is heaped with files. If keeping a desk tidy is difficult for your project manager, how are they going to handle more complex tasks?

2. Punctual

Punctuality sets the tone for organizational conduct. If a project manager is late to meetings or misses deadlines, this sets the tone for all employees. The best project managers are always early. “I didn’t have time,” is never an unacceptable answer unless there was an extenuating circumstance.

3. Transparent

When project managers are upfront with employees about the status of the ERP project, it helps build trust between management and employees. Additionally, making information available to all employees empowers them to make better decisions and produces a product of higher quality.

Closely related to transparency is receptivity toward the thoughts and opinions of employees. The best project managers listen to the people who are in the weeds, performing the details of a much bigger picture.

4. Experienced in Your Industry

Given the choice between a fledgling project manager with deep industry knowledge or an experienced project manager with shallow industry knowledge, choose the former.

A project manager must have industry experience in order to ask detailed questions about business processes and methodologies. Project managers with no industry experience may have a high-level understanding of how things operate but almost everyone in the company should possess that knowledge anyway. When a project manager understands the inner-workings of an industry, fewer blind spots exist.

5. Communicative

When people do not know what is expected of them, this indicates the project manager is not doing their job. For a successful ERP project, every employee needs to understand their role and should be held accountable.

The best project managers hold status meetings to keep tabs on the progress of various tasks. If a team member needs help completing a task, they can ask during these meetings. Status meetings are also helpful in keeping everyone motivated because employees can see how the project is progressing towards its goals.

What Other Internal Resources Will You Need?

1. Executive Steering Committee

This group includes executives and members of the board of directors. The steering committee communicates the importance of the project and explains how it supports the organization’s mission and vision. The committee also participates in milestone meetings regarding software recommendations, organizational alignment and organizational change management.

In addition, the committee helps select project team members in accordance with the project scope, budget and resource requirements. The steering committee has a good understanding of project goals and organizational vision, so their input is valuable when choosing project team members.

While some department managers may be resistant to lending resources, your steering committee can work with them to ensure the right resources focus on the ERP project when necessary.

2. Subject Matter Experts

Much like the project team, this group includes representatives from each functional area. Subject matter experts participate in requirements gathering, requirements validation and vendor demonstrations. These are your “super users,” “change agents” and advocates for your project.

3. Change Management Team

Without the contributions and encouragement of a change management team, the ERP project team would most likely be overwhelmed by project fatigue and conflicting priorities. The change management team is responsible for working with third-party implementation partners to develop strategies that address communication, training and benefits realization.

5 Roles of a Change Management Team

1. Leading by Example

The change management team should not only communicate that the ERP project is a priority, they also should demonstrate this in their actions and decisions.

There’s no doubt that the team will have to make tough decisions, such as postponing or suspending another initiative outside of the ERP project. In order to make such decisions, the team needs to understand the pressures of competing priorities and be able to communicate their concern to the project team.

2. Recognizing Achievements

When the project team loses sight of priorities, reinforcing these priorities through recognition of effort goes a long way. The change management team should regularly acknowledge and celebrate the work being done and sacrifices being made by the project team, SMEs and end-users.

3. Promoting Accountability

Speaking to project team members about their responsibilities will reinforce their accountability to each other and to the organization as a whole. The change management team should encourage team members to hold each other accountable and to voice disagreements constructively.

Regular meetings are a great way to lay everything on the table for discussion and to encourage the project team to come to a consensus. Once a consensus is reached, the change management team should ensure everyone understands the shared responsibilities and reinforce overall expectations.

4. Including Change Agents

Change agents may be a part of the change management team, or they may just serve as liaisons between the project team and end-users. Either way, change agents can redirect employees’ attention to what really matters – the goals and objectives of the organization as a whole and their individual role in the success of the project.

5. Communicating Effectively

Organizations should staff their change management teams with strong verbal and written communicators. Team members should be empathetic but persistent.

What About Outsourcing?

Project managers walk a fine line between the use of internal resources and external resources. A lack of external resources can mean limited expertise. On the other hand, a lack of internal resources can mean poor project ownership and a lack of organizational alignment. Only internal stakeholders can make the ultimate decisions on how your business will run going forward. 

It’s no secret that ERP projects require a dizzying array of skills and competencies. Organizations embarking on business transformations are hard-pressed to assemble project teams that have a vision for how the business can evolve, have business process reengineering and change management competencies, and have a host of other skill sets that are difficult for most organizations to develop internally.

Because of the challenges associated with assembling such a rare and broad set of collective skills, many organizations turn to outside resources to augment their internal skills. Here are a few considerations to help you determine when it may be most appropriate to outsource your ERP project:

1. Focus on People and Processes

It can be easy to take a myopic view of ERP projects, focusing almost exclusively on finding external pinch-hitters with software-specific functional and technical expertise. While these skills are important, they are also somewhat of a dime a dozen. Let’s face it: compared to the people and process aspects of an implementation, configuring and implementing ERP systems are fairly cut and dry propositions.

The business components of implementations – such as change management, project management and business process reengineering – are much more difficult. These skill sets are harder to find. When looking for outside help, it is critical to find a partner that has a comprehensive skill set and a strong ERP implementation methodology.

We’ve found through our implementation and expert witness experiences that ERP success and ERP failure typically has very little to do with how well technical aspects were handled during the project.

Instead, success or failure is more commonly determined by how the business components of a project are handled. While the technical skills may seem more specialized and therefore more important – especially if you’re a CIO or IT manager – it’s actually the more intangible areas that will determine your project’s success or failure.

2. Don’t Outsource Everything

Some companies take more of a hands-off outsourcing approach. While you certainly want to rely on outside assistance wherever it makes sense, you won’t be successful if you don’t step up to the plate to provide a minimum level of internal support and skill sets.

For example, outside consultants – no matter how talented they may be – can’t make decisions about how to run your business for you. In addition, they can’t tell you if the designed and delivered enterprise resource planning system does exactly what you want it to. Only people within your organization can provide these inputs.

Therefore, it is important to identify and recognize those skills and responsibilities that your internal team should provide versus those that can be outsourced to outside parties.

3. Look for the Biggest Gaps

It can be helpful to conduct a gap analysis of the required skills versus the skills you currently possess in-house. The biggest gaps are going to be the ones that you’ll want to outsource to ERP consultants and other external resources.

An independent ERP consultant can be a smart addition to your team. A consultant will often see trends or risks before other members of the team, since they are not caught up in day-to-day activities. Often, teams with previous experience implementing an ERP system, may have a false sense of security. The world of ERP software is dynamic and ever changing.

What’s Your Project Scope?

Your project team structure mostly depends on the scope of your project. Is it simply an ERP implementation or is it a broader business transformation?

Panorama’s ERP consultants can help you determine the scope of your project and the degree of organizational change entailed. This insight will guide the structure and size of your project team.

In a matter of a few years, IT departments across most industries have fully embraced cloud computing and its benefits. While cloud computing is popular, is it secure?

It is often a huge headline in the news when an organization’s ERP software is comprised due to a cloud security breach. This negative press was once the motivating factor for organizations to stay on-premise, but with the overwhelming advantages of moving to the cloud, businesses are making the move in order to stay competitive.

While moving from an on-premise infrastructure to a cloud-based one shifts some of the responsibility from the organization’s IT department to the cloud service provider (CSP), security remains a focal point for which both parties should bear responsibility.

Understanding who is responsible for which security measures is crucial to keeping your organization’s data safe in the cloud. According to Gartner, “In nearly all cases, it is the user – not the cloud provider – who fails to manage the controls used to protect an organization’s data.”¹

This is similar to what we’ve found in our ERP implementation experience – people, not technology, determine the success of an ERP project. We’ve seen all different aspects of ERP implementations – including security – fail based on a lack of organizational alignment between people, processes and technology.

In fact, our 2019 ERP Report shows that more than a third of organizations experienced budget overruns due to organizational issues, and more than half of organizations experienced timeline overruns due to organizational and/or training issues.

Whether you are currently using cloud computing, are planning to a move to the cloud or are staying on-premise, it’s important to know the difference in security design. Below we’ve outlined the key differences between on-premise and cloud security, as well as some of the advantages and disadvantages to both.

Differences Between On-premise and Cloud Computing

1. Ownership of Responsibilities

The biggest difference between on-premise and cloud security design is the amount of responsibility that rests on the organization itself. With an on-premise infrastructure, a business is responsible for ERP system security from end to end. They procure the servers where the data will be housed, build and manage the firewalls used to control access to the network and control the ability to query and extract data from the system.

In a cloud world, these security responsibilities are shared between the organization and the cloud service provider (e.g. Amazon Web Services or Microsoft Azure). This is often referred to as the “shared responsibility model.” Depending on what type of service a cloud customer is subscribed to, the security responsibilities of the customer differs:

Infrastructure as a Service

In the case of infrastructure as a service (IaaS), cloud customers are not responsible for physical elements, such as the actual hardware that applications are hosted on or data centers. Instead, they need only to manage the provisioning of virtual machines, secure the virtual network and monitor all applications and interfaces within the network.

Platform as a Service

When it comes to platform as a service (PaaS), the cloud service provider inherits additional security responsibilities. Since the customer is now paying for an entire platform, as opposed to only the cloud infrastructure, the CSP now manages the duties listed for IaaS as well as the provisioning of virtual machines and securing the virtual network. The cloud customer is still responsible for their data, monitoring their interfaces and securing their applications.

Software as a Service

For software as a service (SaaS), the CSP is responsible for all the previously mentioned duties for IaaS and PaaS, plus they are responsible for the application itself. This makes sense as now the cloud customer is paying to use the CSP’s application hosted on their platform and cloud infrastructure. In this case, the cloud customer is responsible for the security of their data and all interfaces.

In all cases, it is the sole responsibility of the customer to ensure that their specific security requirements are being met. If your organization is planning a move to the cloud, it’s helpful to list all your security requirements. When meeting with potential CSPs, give them the list of your requirements, and let them vet how their service can meet your requirements.

It’s extremely important to note – even though in a cloud-based environment many of the responsibilities now lay with the CSP, the cloud customer must follow the appropriate processes and procedures and hire knowledgeable personnel in order to maintain the integrity of a secure cloud. Designing and documenting processes around ERP security can help the organization prepare its IT staff for new roles and responsibilities. A strong business process management methodology is essential when defining new business processes.

2. Points of Access

Another key difference between on-premise security and cloud security considerations is the means in which the network is accessed. On-premise ERP systems only exist on the devices they are installed on. When business users need to access their company data in an on-premise environment, they need to be physically in the office (on the company’s network).

For example, an employee could have SAP installed on their work laptop, allowing them to view company data from that device (on the company network, of course). The same employee could also have a personal laptop that does not have SAP installed. This makes controlling access to applications and data simple, as there is only a single access point.

While this may pose challenges for employees working remotely, they can always use a virtual private network (VPN) to log into their in-office device. VPNs are secure because they require a security key or other means of identity management

In a cloud-based environment, employees can access company applications via a web browser. This means that any device with internet access becomes an entry point to business critical data.

Cloud-based environments also allow the use of application program interfaces (APIs). While APIs can be used with applications running on-premise, their use didn’t become normalized until cloud service (and software) providers began pre-building them into their platforms. Now, interfacing with third party software applications is as easy as exposing the appropriate API and allowing third party access to your environment.

This ease of interfacing has its benefits but adds an additional layer of complexity when it comes to security design. In an on-premise environment, interfacing with outside systems is usually driven by the IT department, and the communication channel must be built in collaboration with the third party. With this approach, security considerations can be designed into the communication channel up front.

When utilizing an API to create, read, update or delete data in another system it is crucial that proper planning takes place. Not all permissions are typically needed by an API to perform its designated function. Identifying proper permissions and their repercussions is just as important. We always advise against taking the easy road and just giving full permissions to an API.

When creating the API, you should investigate the security of the system you are interfacing with. One question to ask when interfacing is this: “If this system security is breached how can it affect our data?” Developing your connector or API with this in mind can save you headaches and potential lawsuits down the road.

The Advantages and Disadvantages of On-premise and Cloud Computing

Whether you have an on-premise infrastructure or are already in the cloud, there are some strong advantages to both in terms of security:

Advantages of Cloud Security

A huge advantage when it comes to security in the cloud is the accessibility of security tools built by the cloud service provider or ERP vendor. Usually, for an additional fee, CSPs like Amazon, Microsoft and Google offer built-in security tools that help your IT department identify and remediate network vulnerabilities and provide suggestions on how to improve your security design.

Cloud service providers have a lot riding on the security of your data – namely, their reputation. Even if a data breach is the fault of a cloud customer, the reputation of the CSP also takes a hit. Because of this, CSPs have heavily invested in machine learning to help identify weak spots in your system and notify you immediately in case of an attack.

Another benefit of security in the cloud is the level of automation that can be achieved leveraging APIs. These APIs make it simple to orchestrate incoming and outgoing messages between your company’s network and third parties, ensuring that the proper authentication methods are in place each step of the way.

Disadvantages of Cloud Security

While the use of APIs can be considered an advantage in terms of automation, it can also be seen as a disadvantage when looking at the amount of access points to manage. If you have several third parties automatically accessing your environment, it can be difficult to monitor all the inbound and outbound traffic. In the case of a breach, it is even more problematic to find out where your security issues lie.

Advantages of On-premise Security

An obvious advantage of an on-premise security design is the clarity of responsibilities and ownership around security requirements. With a physical data center, it’s easy to see that access to the facility must be protected by the customer. The ownership of security requirements falls 100-percent on the organization.

As long as the organization prepares its people and processes, its data security will be strong. An organization must not only prepare its IT department but its end users, as well. While end users have a very different set of security responsibilities, their role is no less important. Some organizations develop an organizational change management plan to prepare employees for the security considerations of a new ERP system.

Disadvantages of On-premise Security

With the ownership of the data center resting solely on the business, the amount of security responsibilities given to your IT department is more than double that of cloud-based security.

Additionally, in an on-premise environment, there is usually little to no automation in terms of communicating with third parties. This means your IT department must securely build and manage a channel of communication each time a new vendor is added to your ecosystem.

Lastly, as if your IT department doesn’t have enough on its plate, the majority of security tools made for on-premise environments are outdated. With new ways for cybercriminals to access sensitive company data, security tools must constantly evolve to keep up with new threats. When the defense is no match for the threat, IT professionals must be even more diligent in monitoring your network’s security.

The most common form of attack on company networks is not so much a virus or brute force hacking. It is social engineering and elevated permissions granted to individuals or groups not requiring full access.  This is the result of not having a solidified IT plan and documentation.

You can address social engineering by having official training for all staff on the attackers’ methods and tactics. Non-essential security permissions can be audited and refined by your in-house IT security professional or an external IT auditing firm.

Where Should You Host Your ERP System?

During ERP selection, cyber security is a concern for many organizations. Ultimately, security depends less on technology and more on your people and processes.

For example, cloud hosting may be more secure than on-premise hosting if your internal IT department is not large enough, skilled enough or prepared enough to manage the full security of an on-premise ERP system. However, a cloud environment still requires internal security responsibilities, so a strong internal team and clearly defined processes are still essential.

Panorama’s ERP consultants take the time to understand your organization’s unique situation. We can help you prepare your people and processes for the challenges of either cloud or on-premise security.

1. Gartner, Is the Cloud Secure?, https://www.gartner.com/smarterwithgartner/is-the-cloud-secure/, March 2018

Many organizations that are using Microsoft Dynamics AX are considering an upgrade to Microsoft Dynamics 365 for Finance and Operations (D365). If your organization is considering this upgrade, you may be interested in learning more about the differences between these two systems before you commit to an ERP project.

Before delving into these differences, we’d like to share one caveat:

Before beginning an ERP project or digital transformation, we always recommend that organizations take a step back and evaluate their business goals. According to our 2019 ERP Report, less than half of organizations find the technology aspects of their ERP projects to be difficult. In contrast, more than half of organizations find the business aspects of their project to be difficult. These findings show the importance of focusing on organizational alignment before technology.

We recommend that businesses align their organization and conduct a comprehensive ERP selection to determine if an upgrade is preferable to moving to a completely new ERP vendor. Evaluating multiple ERP vendors allows organizations to see which systems align with their business goals.

Nevertheless, we recognize that an upgrade to a D365 is a popular choice for many Dynamics AX customers, so in this post, we’ll focus on these two systems. First, we’ll provide a brief history of how AX has evolved over time, and then we’ll review the key differences between AX and D365.

A Brief History of Dynamics

Originally developed in 1998, IBM Axapta was created through a collaboration between IBM and Damgaard Data to fulfill the need for a computer-based accounting program geared towards enterprise-level businesses.

A few years later, Damgaard Data merged with Navision Software A/S to create the company Navision A/S, which Microsoft later acquired. During this time, the ERP system was known as Axapta.

Over time, Microsoft further developed Axapta to cater to businesses across a variety of industries, including financial services, manufacturing and retail. Axapta then became known as Dynamics AX.

Several versions of Dynamics AX were released by Microsoft, each continuing to establish the business software as a contender in the market – from AX 4.0 to AX 2009 and finally AX 2012. The ERP system was widely adopted, and many customers are still using a version of Dynamics AX as their means of operating their businesses.

Fast forward to 2019, and Microsoft is proudly marketing and implementing D365 as the greatest version of their ERP software to date. The transition started with moving AX into the cloud, allowing users to access the application via a browser. Briefly, the name of this version was AX7. Later on, when Microsoft was rebranding their product line, they changed the name to Dynamics 365 for Finance and Operations.

Dynamics AX vs. Dynamics 365: 5 Differences

Although they are essentially two different versions of the same business solution, there are a few key differences between the two ERP solutions. For the sake of this post, we will compare Dynamics AX 2012 to Dynamics 365 for Finance and Operations.

1. Infrastructure

The biggest difference between Dynamics AX and Dynamics 365 is the infrastructure the systems are built on. When Microsoft committed to putting cloud technology first when CEO Satya Nadella took over in 2014, they moved the Dynamics products into the cloud, as well. This meant that Microsoft’s cloud service, Azure, would host D365 and any other applications from the Dynamics 365 suite of products. In contrast, Dynamics AX 2012 can still be run on-premise, meaning that customers can host the application on their own servers that are physically onsite.

Initially, there was some resistance to the cloud-driven model. Organizations were used to storing their production data locally and having the ability to access it at any time. For example, with an on-premise ecosystem, a system administrator could write a SQL query to view data in real-time.

Customers who had a production environment of AX did not want a cloud based application, as they would have to request copies of their production database from Microsoft to pull from the cloud.

The process for code deployment to production was also changed in the cloud. System administrators could no longer promote code to production on-demand, and instead, had to schedule a deployment, which Microsoft would do on the customer’s behalf.

Despite the initial resistance, cloud based infrastructure has become an accepted and, oftentimes, preferred method of managing an ERP system. Creating and maintaining an on-premise ecosystem is an administrative project on its own – you must acquire the necessary hardware, build the network in a way that allows employees around the globe to access it and plan for disaster recovery. All of this can be extremely costly and a headache to maintain.

With Microsoft Azure hosting your software system, these steps are done by Microsoft in collaboration with the customer, making environment management convenient and simple.

2. Custom Development

Another key difference between Dynamics AX and D365 is the method in which custom code is written and implemented.

With any ERP implementation, there is bound to be some software configuration or customization needed to meet specific business requirements. With Dynamics AX, custom development can be applied using the over-layering method. Over-layering is a concept that allows the core product, customer code and any value-added reseller (VAR) code to be separated from each other in different layers. The different sets of code are then layered on top of each other within the ERP system. Sometimes, when the code is merged, compatibility issues arise, and developers must adjust their code before it can be deployed.

D365 requires the use of the extensibility model as opposed to over-layering. This means the core code of the ERP system is locked down, not allowing any customizations. Developers must customize the software through built-in extension points.

Only objects that have extension points can be customized, but if a customer has a need for a new extension, they can request it from Microsoft. Microsoft often provides extensions directly to customers or includes them in future releases. When it comes to upgrading, the extensibility model is highly preferred as it causes significantly fewer compatibility issues than the over-laying method.

While Dynamics products are easier to customize than many other vendors’ products, it should be noted that extensive customization is a key failure point we see in many of our software expert witness engagements. We recommend that organizations carefully manage customizations by developing project governance and controls to ensure customizations are made only when absolutely necessary.

3. Upgrade Model

Upgrading to a newer version of Dynamics AX – like AX 2009 to AX 2012 – often requires a new implementation. Many AX customers considering an upgrade find that they first need to evaluate the business impact of the upgrade and improve their business processes. This requires a new implementation because new processes often require new configurations and/or customizations.

Other AX customers see the need for a new implementation when they realize that their custom code conflicts with the code delivered by Microsoft in the new software version. In these cases, developers must change and sometimes entirely rewrite their customizations.

Upgrades from AX 2012 to D365 can typically be done without a new implementation, depending on the amount of custom code involved. However, upgrades from AX 2009 to D365, require a new implementation since there is no direct upgrade path from one to the other.

With the move to the cloud came the opportunity for Microsoft to adopt a new upgrade model, similar to the upgrade model of modern applications consumers are familiar with today.

This model, used in D365, does not require a new software implementation. Instead, monthly updates are pushed out to customers on the ERP application. Large feature changes are delivered as parameters or configuration keys, allowing customers to decide if they want to turn on the new functionality. For customers with custom code, the chances of conflicts with the upgrade are drastically reduced.

4. User Interface

A very apparent difference between Dynamics AX and D365 is the user interface. With Dynamics AX, a user can launch the application from a desktop and perform their work within the program. Dynamics AX has the aesthetic of most ERP systems, which is, to be honest, a little out of touch with today’s typical ERP user.

With D365, a user can launch a web browser and enter a URL. Within the browser, the user can perform his or her work and open additional tabs if necessary. D365 can be launched from desktops and mobile devices alike – anywhere with an internet connection. The look and feel of D365 is more aligned with Microsoft’s branding and matches the style of other Microsoft products, like the Office 365 suite.

In Dynamics AX, the homepage defaults to an area called Role Centers. Here, users can create custom queues and links that make performing their daily functions easier.

In D365, the homepage defaults to an area called Workspaces. While similar to Role Centers, Workspaces are prebuilt queues, links, lists and graphics that are related to specific modules and security roles.

An unfriendly user interface can exacerbate the user adoption challenges inherent with ERP implementations. When organizations experience user adoption issues – user interface-related or otherwise – they often seek guidance from ERP consultants. If user adoption issues are severe enough, this can be considered an ERP failure. ERP consultants, like Panorama, have extensive experience recovering ERP implementation failures caused by variety of factors.

5. Navigation

Navigational differences, though minor, are worth noting.

A common theme across ERP systems is that certain screens can be launched from several different places in the system. In Dynamics AX, a user must know the menu path to a specific screen. For example, to create a new sales order, a user can navigate to Sales and marketing > Sales orders > All sales orders. However, this is not the only place to launch the sales order screen, which makes it difficult and time consuming for users to memorize any particular path.

In D365, a new search capability was added to allow users to type in the name of the screen they are looking for and click from the results to launch the page.

Should You Upgrade Your AX System?

Now that you know the basic differences between AX and D365, you may be more confident that you need to upgrade to D365. This is a wise decision for organizations seeking a more manageable production environment, easier customizations and upgrades, or an improved user experience.

However, an upgrade from AX to D365 is no easy task. Our ERP consultants can help you understand the business impact of an ERP upgrade. We will guide you through organizational change management activities and other essential project activities that make upgrades smoother and more beneficial to your bottom line.