ERP

Navigating the ERP industry could be hard with so many different ERP company types. If this is your first time engaging with ERP companies, you might be confused about their role. The problem starts with marketing verbiage sounding similar. Each of them claims to be an expert at business transformation or process re-engineering. While marketing is easy, being proficient with ERP transformation projects is a multi-year process. This process requires thousands of cycles under their belt to master the art. Engaging with a company that may be overcommitting its capabilities is a sure recipe for disaster.

The challenge is not just their overlapping focus and claims. It is also their tendency to guard their revenue, sometimes through practices perceived as unethical. Through their alliance strategy, the ERP publishers may have an NDA with their resellers. The NDA has a clause of favorably marketing their products. These clauses will prevent them from revealing the weaknesses of the products, even if they might want to be completely honest.

Legal issues are not the only problems the ERP industry faces. You might run into technical or architectural challenges. The competing vendors might not integrate well with the other good solutions sold in alliances by their rivals. So what do you need to know about different ERP companies involved with an ERP transformation project?

1. ERP Publishers

ERP publishers are the producers or manufacturers of ERP products. Their role would be similar to a manufacturing OEM that publishes the original equipment. The OEMs such as a car or a material handling system that their ecosystem partners can sell or service. Examples of such companies include tier-1 vendors such as SAP, Oracle, and Microsoft. Tier-2 vendors such as Infor, Epicor, Sage, IFS, Unit4, QAD, Acumatica, Plex, or Deltek. And Then tier-3 vendors such as ECi software solutions, Global Shop, ProShop, Genius, Blue Link, or Alox.

Depending upon the publisher type and their business model, they each may have different strategies. Some horizontal vendors such as SAP, Oracle, Microsoft, Sage, and Acumatica might offer basic ERP capabilities out-of-the-box. But they might rely on their VARs and ISVs to provide the industry functionality. Vertical vendors such as Infor, Epicor, Plex, QAD, or Unit4 might package the entire enterprise architecture out of the box. They might also offer consulting support and services.

In general, most ERP publishers care for the license revenue and may have legal limitations in providing support outside of their product. Even the ERP vendors that might have their internal professional service might engage with other partners to provide integration support and services. Also, the vendors that don’t have developed channels and ecosystems are likely to have poorer documentation for their products. Why? Because they might manage their products with tribal knowledge and few key employees (or departments). Regardless of whether you sign a contract through them or through one of their channel partners, you will most certainly be using products published by these OEMs.

2. ERP Resellers/System Integrators

ERP resellers (also known as value-added resellers or VARs) are the distributors of the ERP OEMs. Their role is similar to a distributor in the traditional retail and manufacturing value chain. A third-party sales extension of their ERP OEMs, most resellers might carry only a couple of products, depending upon the restrictions posed by their OEMs. Examples of resellers would be SAP or Oracle partners, Infor or Epicor resellers, or Acumatica or NetSuite VARs. Examples of system integrators would be companies such as Accenture, CGI, Capgemini, NTT Data, TCS, Wipro, Infosys, or HCL.

Some OEMs might require exclusive relationships, while the other ones might be slightly more flexible. They divide their resellers’ focus into different territories, just like their internal sales teams. At one time, there could either be a reseller or an internal sales rep allocated to the deal. Changing the reseller might be possible but often difficult, as OEMs might want to guard their resellers.

Primarily interested in the consulting revenue, the system integrators also have a very similar business model as ERP resellers. But they might not sell the software. They will have internal practices set up for each vendor and product. And each practice might compete with each other for clients and revenue. And this competition sometimes may be at the expense of customers. Neither the reseller nor the system integrators are independent. They may have biases with their advice as they are only experts in a few products. They would try to create solutions around those technologies, ignoring the other potentially superior options out there in the market. 

3. ERP ISVs or Add-on Companies

ISVs (independent software vendors) are software publishers that may sell their software on ERP marketplaces, with the primary motivation to sell their licenses. Typically installed on top of the ERP systems, the ISV solutions come in various shapes and sizes. Some of these ISVs are well-funded companies by private equity and VCs. The other add-ons, however, are developed by VARs that may not be as well capitalized. 

In general, the ISVs that are also not VAR tend to have superior go-to-market strategy and development teams. The companies that try to do both end up mixing their business model. They might not have as much capital and install base to maintain the high-quality code, as well as documentation. Examples of ISVs could include sales tax software, AR/AP automation, and EDI vendors. As well as iPaaS solutions, eCommerce plugins, and customer and vendor portals. Sometimes these ISVs could be as big as the largest enterprise vendors, such as Salesforce, Adobe, or ServiceNow. 

The ISVs are likely to have very strong alliances with the OEMs and VARs. At times, offer free independent advice, including ERP selection. They do so in the hope of winning the license business. Some ISV solutions might be native, while others may have a completely different look and feel and UI than the native solution. Also, unless you live and breathe in the ERP space, it might be harder to know the difference between a white-labeled solution sold on OEMs ‘ papers vs. the code owned by the OEM.

4. Independent ERP Consultants

Just like other ERP companies, even independent ERP consultants come in various shapes and sizes. Some of them are business transformation experts involved from the strategy phase until the successful adoption. The others are just affiliate marketing companies, selecting based on a checklist approach. As well as walking out right after the ERP selection phase, handing over the implementation phase to ERP subject matter experts.

Also, unlike other pureplay change management companies, some independent ERP consultants may not only offer change management expertise. But also help with enterprise architecture and program management, combining many different technologies, including hardware. Generally, these companies offer CIO-level expertise, helping you manage the entire program. This is especially true if you might not have the internal bandwidth or expertise to do it on your own. 

Due to the nature of their business, they don’t have affiliations with any ERP vendors and might not have access to certifications and training programs. So they are likely to work with a VAR or OEM and use them as the product and technical experts while they act as the business consultants covering not just technology but also process or data decisions to avoid implementation failure due to overengineering of systems. If independent ERP consultants claim that they don’t need to work with a VAR or OEM, that means they are most likely a VAR or a system integrator trying to pretend to be independent.  An example of such companies would be ElevatIQ, Third Stage Consulting, Panorama Consulting, Ultra Consultants, ERP Advisors, and Pemeco Consulting.

5. Change and Project Management Consulting Firms

While the core offering of independent ERP consultants includes change and project management, the pure-play change management consulting firms lack the ERP subject matter expertise – critical for ERP projects. Most of the change management consulting firms have HR and learning backgrounds, which is great for other change management programs, such as the adoption of a specific type of tool that might not be as complex or a physical process that might not require as deep subject matter expertise. 

The same goes for project management companies as well. While project management is important, it’s not as critical as the ERP subject matter expertise to be successful with these projects. Also, since pure-play change management consulting companies may undertake a wide variety of projects, they might not go through as many cycles and may not be keeping up with the changes with each product and vendor. 

Due to their limited understanding of the industry, they are also likely to struggle to work with ERP vendors. Finally, they would not have access to as many quotes and contracts to be able to negotiate with the ERP vendors. Some change management companies may also have partnerships set up with the vendors in the market and might not be completely independent. An example of such companies would be change and project management consulting firms run by ex-trainers and project managers.

6. Accounting/Fractional CFO Firms

Some people perceive ERP systems as accounting systems, and you are likely to go to your current accounting firms for advice about ERP systems. But their perspective is limited to finance, which is not even 10% of the overall ERP processes, not to mention other technologies and the enterprise architecture. Also, just like other ERP firms, even accounting and fractional CFO firms come in various shapes and sizes, with the majority of them claiming ERP selection and project management expertise.

There might be big accounting firms through your audit relationship. Each of them will claim to have ERP selection and implementation expertise, but their approach has biases (and is very similar to VARs). They might claim that they have separate divisions, with the selection being completely independent. But since they are part of the same company, their selection is likely to have biases. Generally carrying horizontal solutions such as SAP, Oracle, or Microsoft, they might ignore everything else, as these solutions provide an opportunity for them to create an IP on top of them. Also, their business model is to make money by creating dashboards and reports, resulting in unnecessary development and maintenance costs, generally pre-packaged with other solutions in the market.

Finally, the major challenges with most ERP implementations are likely to be supply chain, inventory, and operations related. Just because these issues require cross-functional alignment of data and processes, most accounting and fractional CFO firms are likely to be perceived to be biased by other functions and departments, even if they are completely unbiased, resulting in adoption issues.

7. Freelance Consultants/Fractional Executives

Freelance consultants and fractional executives are very common in the ERP industry as well. Sometimes these executives might be in between jobs, and other times they might be running a lifestyle business. They typically don’t have a strong team backing them and don’t go through enough cycles for their expertise to be comparable with other ERP companies. Typically ganging up with other freelance and fractional executives, hiring them might lead to attrition issues as each executive might be working on competing priorities.

With limited exposure and involvement in the ERP industry, they might not be well-versed in the political factors that generally lead to issues with ERP selection and implementation. Not understanding the financial risks comprehensively, they might make mistakes such as asking for unreasonable discounts or unknowingly conceding on factors that might have much deeper consequences.

Also, without a clear market position and having to worry about legal consequences, as with independent ERP consulting firms, they might accept kickbacks in the background. They are also likely to be biased to the solutions to their familiarity, just because they might have implemented only a couple of solutions and not necessarily tracking the industry on a daily basis. An example of such companies would be executives who are freelance and may not represent a company with several employees.

8. Business Process/Lean/Supply Chain Consultants

Most business process, lean, and supply chain consultants are likely to be the users of ERP systems, without real implementation experience. Even if they may have been involved with an implementation, they mistakenly assume that using and implementing them require similar expertise. Just like freelance consultants, they might not understand the political forces of the ERP industry. 

Also, just like them, they are likely to be familiar with a couple of solutions and might not track the industry on a daily basis. Also, they will not go through as many deals per year to be able to see enough trends and be informed with their recommendations. The ERP selection and implementation require an understanding of processes and data from the lenses of ERP. So while they might be able to improvise the physical processes, they might struggle with digital processes because of the lack of ERP subject matter expertise.  An example of such companies would be supply chain and lean and six sigma consulting firms.

9. Web Development/Marketing Agencies/IT Companies

While most ERP-like systems can be perceived as IT or software applications. And most companies have a tendency to assume that most software applications must be similar. Also, while IT companies and marketing agencies may have a great depth with programming languages and technologies, they mistakenly assume the depth of business processes and subject matter expertise required for ERP implementation. 

The consultants that shape up an ERP implementation are functional consultants, consultants that have educational backgrounds or training in accounting, supply chain, and operations management. Unfortunately, most software engineers that might be building technical systems on a daily basis aren’t the best fit for ERP-like systems.

It takes many years and thousands of implementations to be the subject matter expert with ERP implementations, along with formal training and certifications on many ERP systems. Without this training, web development, marketing agencies, and IT companies would struggle with ERP implementation. They are also likely to be biased with their assessment as even selecting an ERP requires a deep understanding of business processes, business data, and the ERP data model,  as well as enterprise architecture. An example of such companies would be Shopify and BigCommerce partners, SEO and branding firms, and Salesforce and HubSpot partners.

10.  Affiliate Marketing Companies

There are several affiliate marketing companies and marketplaces that generally rank higher on Google because of their content. And because of their rankings, most prospects and customers are likely to land on their sites first. Their primary business model is to sell leads to enterprise software companies. While they might claim ERP selection and procurement expertise, they don’t have subject matter expertise with ERP implementation. 

Just like independent ERP consulting companies and ERP selection consultants who might only help with ERP selection, these marketing companies take a very check-list-centric approach to ERP selection. Their recommendations are highly generalized and lack the depth required to save ERP implementation failures. Also, while they might come across as vetting thousands of software vendors, their ERP selection is still biased as they are likely to select the solutions listed in their network or the companies that have paid them to create a listing on their site. 

Also, they might offer cheaper ERP selection services just because they not only charge the customer for the selected services but also charge each vendor for lead generation, lead sharing, listing creation, ranking maintenance, etc. An example of such companies would be Select Hub, Technology Advice, G2, Capterra, Trust Radius, Software Connect, Software, GetAPP, and Technology Evaluation Center. As well as most media properties owned by analyst firms such as Gartner, Forrester, and IDC.

Final Words

Understanding the business models involved in the ERP industry can help you find companies that can help you succeed with your goals. Not only do you need to pay attention to their positioning, but you also need to understand how their contracts are structured. Gauging only from the marketing material could be challenging. And you might need an insider expert, such as an independent ERP consultant, who can help you understand the industry.

So if this is your first time implementing an ERP, make sure you are not judging a company by the cover page of their website. Choosing a company that might be overclaiming its capabilities might not only mislead your ERP selection process but can also result in an ERP implementation failure. So use this list as a starting point for your ERP journey.

FAQs

ERP selection is not just about filling functional checklists. Asking teams to vote. Or picking a system that works for everyone. It’s a lot more than that. Done right, ERP selection addresses several perspectives, including change management and business transformation. As well as technical and financial feasibility, program management, and enterprise architecture. Depending upon their strengths and prior expertise, each ERP selection consulting company may have varied approaches, with very few being “truly independent” and capable of performing exhaustive searches across hundreds of solutions.

The challenge starts with the misalignment of the ERP term. Is ERP supposed to be every single system in the enterprise architecture? A functional system catering to the needs of a specific department, such as accounting or finance? A reporting and planning system? Or a crystal ball that can provide answers to your questions? In reality, ERP is none of that. In fact, the ERP term, per se, doesn’t have much meaning. It’s the enterprise architecture that matters.

But an ERP system (or several ERP-like systems) is generally the foundation of this architecture. Also, the ERP companies have evolved so much that they can offer the entire enterprise architecture out-of-the-box, which only adds to the confusion due to the overlapping boundaries and their broadened scope. Understanding different ERP selection types and their pros and cons is the first step to aligning the expectations of what ERP means to your organization and what you might need to do to be successful with it. So which are the top ERP selection types in 2023?

1. Change-focused Business Transformation Driven Selection

This ERP selection approach is perhaps the most comprehensive, taking the enterprise view, combining most cross-functional processes, and identifying key business transformation objectives. It starts with building a couple of process model versions: the first focused on user training and another on technical implementation. The as-is processes often combine financial forecasts, driving the to-be processes based on financial goals. 

Due to their nature, either the private equity or the board will drive them – in the hope of a complete overhaul of business and financial operations. Depending upon the organization’s size, the CEO might lead these projects with the help of business transformation consulting firms. These projects might require substantial changes in the organizational structure, key personnel changes, business model transformation, reconfiguration of business processes, as well as operational capacity.

Covering the majority of cross-functional business processes, including order-to-cash, hire-to-retire, and forecast-to-deliver, they might implement these processes using one system. Or a couple of systems, including ERP, CRM, eCommerce, and BI, taking the enterprise view for the architecture. The projects might result in the selection of just one technology or a combination of technologies. The overwhelming nature of these projects requires a business transformation consulting firm to continue through the implementation phase to ensure success. 

Pros

• Much higher chances of getting business results from technology investments
• Happy users with cross-functional alignment and adoption
• Lower technical and financial risks during the implementation phase

Cons

• Expensive
• The selection phase might take longer, demotivating champions hoping for short-term results.
• Requires commitment from the top. It can’t be done at the department level.

2. Business Transformation-Driven Selection

The major difference between business transformation-driven and change-focused ERP selection is that this one would not invest as much time in user-centric processes. It starts by identifying financial forecasts and KPIs and might document the process only from the technical and business perspective. The users might not be involved during the selection phase or may have limited involvement.

These projects are still driven at the CEO or board level due to the cross-functional changes and alignment required. Limiting the scope to only the business or technical issues, they might still use a business transformation consulting firm. While the process and data re-engineering may be done, it might not be successful. Why? Because users might not be willing to make changes because of their limited end-to-end visibility of drivers requiring these changes. 

The limited documentation may lead to biased decision-making and users making assumptions. Including committing and then backing off due to their gaps in understanding. Like change-focused selection, this approach would cover all the cross-functional processes, taking the enterprise view for the architecture. The selection phase may require choosing different systems and technologies. The overwhelming nature of these projects requires a business transformation consulting firm to continue through the implementation phase to ensure success.

Pros

• Less expensive than change-focused business transformation due to the reduced time for user-centric processes
• Shorter implementation time than change-focused transformation
• Focus on the business drivers ensures alignment of business goals with technical implementation.

Cons

• The users might not accept the system, leading to data and process siloes.
• Longer selection phase than the functional ERP selection
• Requires commitment from the top. 

3. Enterprise Architecture Replatform-Driven Selection

The major difference in this approach from the previous two is that this is a very technical implementation, ignoring the user and business transformation perspective. It might start by defining technical problem statements such as the outgrowth of current systems or digitally transforming processes. But doesn’t go through the financial analysis of identifying the KPIs or analyzing user-centric processes.  

These projects are driven by IT or CIO with limited involvement of the business or users. Due to their perception of these projects being technical in nature and not yielding short-term results aligned with the compensation structure of business executives, IT teams might struggle to get traction from other business groups. Limiting the scope of the consulting firms, they might hire an independent ERP consultant to lead the selection. 

While their projects are likely to have a sound enterprise architecture, they might fall short due to the lack of process and data re-engineering and over-bloatedness caused by the lack of control in changing business processes or data. Like the previous two approaches, this approach would cover all the cross-functional processes, taking the enterprise view for the architecture. The ERP selection phase may require choosing different systems and technologies. Due to the way this selection type is approached, even if a business transformation firm is involved, it might struggle to get business results. 

Pros

• Technical issues such as master data governance may not be a problem.
• Shorter implementation time than business transformation-centric initiatives
• Time savings for business

Cons

• Adoption issues.
• Longer selection phase than the functional ERP selection
• The systems might be substantially over-engineered because of the missing process and data reengineering step

4. Functional Checklist Approach

The major difference in this approach from the previous ones is that this is a siloed functional implementation, ignoring the technical and integration perspective. It might start by defining business transformation objectives but does not dig deep enough to realign the data and processes meaningful for the technical teams. Due to the misalignment, the technical teams might completely ignore the recommendations provided by the selection consulting firm. The siloed perspective might lead to choosing an outdated technology, which might be functionally complete but never work for users because of the integration or master data issues.

These projects might be driven by CFO or controllers with limited involvement of other teams. The business executives might expedite the process to meet short-term business results, leading to substantial technical debt. Limiting the scope of the consulting firms, they might hire an independent ERP consultant to lead the selection. 

Due to the missing technical and integration perspective, the overall admin efforts might increase in reconciling various ledgers and resolving integration issues. This selection approach would force every single process from the ERP lenses without capitalizing on the synergies offered through other best-of-breed systems. The ERP selection phase would require selecting only the ERP, delaying the other integration decisions for the implementation phase. 

Pros

• Cheaper
• Faster
• Can be done at the department level

Cons

• Substantial technical debt and higher costs in the long term
• Increased work for operational teams in reconciling different data siloes and integration issues
• Higher chances of implementation failure, even after investing in the selection phase

5. Accounting/Fractional CFO Firms Led

Companies not familiar with the ERP industry often ask for advice from their current accounting or fractional CFO firms due to their fear of being non-compliant with tax authorities. While most accounting firms and fractional CFO firms might claim to be independent, they are not necessarily independent ERP consultants. These companies generally have internal practices for a few mainstream accounting systems and try to sell their IPs on top of that, making their business model similar to a VAR or ISV. 

The business model of accounting and CFO firms generally revolves around creating manual reports and bookkeeping, so they will not include any solutions where they would earn reduced revenue for their services. Since these consultants may have implemented only a couple of systems, their selection advice is likely to be biased toward those systems. 

These companies don’t run hundreds of ERP selection engagements every year. Not to mention tracking the evolution of the ERP systems and vendors on a daily basis. Ignoring other potentially relevant solutions, they might compare a couple of systems of their knowledge. They might also ignore other systems in the architecture, leading to bigger integration issues and creating a backlog that might drive much higher maintenance costs in the future.

Pros

• Cheaper
• Faster
• Can be done at the department level

Cons

• Biased selection approach towards their IP, revenue, and solutions of their familiarity
• Increased admin work in reconciling different ledgers
• Higher chances of implementation failure, even after investing in the selection phase

6. Business/Technology Consultants Led

In this approach, companies not familiar with the ERP industry might hire a business or technology consultant for the selection advice. Examples of such consulting companies would be IT companies, lean consulting firms, HR, or business process consulting firms. Since these consultants may have implemented only a couple of systems, their selection advice is likely to be biased toward those systems. Despite their claims to be independent, they are not necessarily independent ERP consultants, as they don’t run hundreds of ERP selection engagements every year. Not to mention tracking the evolution of the ERP systems and vendors on a daily basis. 

Some of these companies might also have partnerships set up in the background and might recommend solutions where they might receive kickbacks. The easiest way to find out if a vendor is tied to any solution or not is to look at their content strategy. If the content strategy compares many different solutions and publishes a list of many providers, the ERP publishers won’t sign the partnership with them due to their fear of their IP falling into their competitor’s hands.

They might also ignore other systems in the architecture, leading to bigger integration issues and creating a backlog that might drive much higher maintenance costs in the future.

Pros

• Cheaper
• Faster
• Can be done at the department level

Cons

• Biased selection approach towards the solutions of their familiarity and where they will receive kickbacks
• Might drive substantial process overhead because of the increased work in reconciling different ledgers
• Higher chances of implementation failure, even after investing in the selection phase

7. Resellers Led

In this approach, companies not familiar with the ERP industry might engage with a reseller who might offer ERP selection advice for free (or at lower costs)  in the hope of receiving kickbacks from the software provider they resell. Or earning the implementation business. They would structure the selection process in a way that favors their solutions. In the hope of locking down the customers with a contract, they might emphasize not spending much time during the selection process. 

Ignoring other potentially relevant solutions, they might compare a couple of systems of their knowledge. They might recommend against most practices, such as process documentation or change management, as that will delay their deal. Since the process of re-engineering might be done only from the perspective of their tool, it might fire back if you use any other systems or tools that are not compliant with their ecosystem. 

For example, going for another freight solution to get better deals on rates might throw off the architecture completely or force you to use the tool in their ecosystem that might not have the most friendly rates. They might also ignore other systems in the architecture, leading to bigger integration issues and creating a backlog that might drive much higher maintenance costs in the future.

Pros

• Might be free
• Faster
• Can be done at the department level

Cons

• The misguided selection process leans toward reseller’s systems
• Higher chances of ERP implementation failure due to selecting a system that does not fit
• Biased architecture may result in substantial operational efficiencies

8. Freelance Consultant Led

Offering ERP selection advice, these freelance consultants are generally ex-executives and hobbyists consultants. They might have a couple of ERP implementations under their belt but may not understand the ERP industry as well. Having implemented only a couple, their selection advice is likely to be biased toward those systems. While these companies might claim to be independent, they are not necessarily independent ERP consultants, as they don’t run hundreds of ERP selection engagements every year. Not to mention tracking the evolution of the ERP systems and vendors on a daily basis. 

Savvy ERP vendors might not prefer to engage with them as they might be perceived to be affiliated with a solution or vendor, and they fear a biased selection process, leaving out potentially relevant solutions. They would not have enough data and insights to identify the red flags in the contracts or “selection gotchas” that you learn only if you track these systems on a daily basis. Some of these companies might also have partnerships set up in the background and might recommend solutions where they might receive kickbacks. 

Ignoring other potentially relevant solutions, they might compare a couple of systems of their knowledge. They might also ignore other systems in the architecture, leading to bigger integration issues and creating a backlog that might drive much higher maintenance costs in the future.

Pros

• Might be free
• Faster
• Can be done at the department level

Cons

• The misguided selection process leans toward consultants’ expertise with few systems.
• Higher chances of ERP implementation failure due to selecting a system that does not fit
• Biased architecture may result in substantial operational efficiencies.

9. Affiliate Marketing Company Led

These companies are primarily content marketing companies that make money by selling qualified leads. Some of these companies might claim to be helping with ERP selection, but they are not necessarily the subject matter experts on ERP systems. Their recommendations are likely to be based on the providers in their network who are willing to pay for their lead-generation services.

By offering match-making services without technical and functional subject matter expertise, they generally work with OEMs and resellers and don’t charge their customers for the recommendations. Conducting hardly one interview of a few attributes to identify the ERP vendors, they would recommend ERP vendors. Their advice is not meant to be the selection advice, and they are most certainly not independent ERP consultants. Examples of such companies include G2, Capterra, Software Connect, Software Advice, Technology Advice, and many more.

Their role ends as soon as they make an introduction to the ERP vendors. Helping with process reengineering, contract analysis, or enterprise architecture would be a stretch for them. 

Pros

• Might be free
• Easy way of shortlisting potential solutions
• A centralized place to learn about various solutions in the market

Cons

• Their recommendation might mislead your ERP selection
• No technical or functional expertise to be informed with recommendations
• Not really an ERP selection

10. Internally Managed

Companies implementing an ERP system for the first time underestimate the expertise required in selecting an ERP.  Researching over the internet, they might follow generalized recommendations such as building a checklist, asking vendors to demonstrate the solutions, and selecting a system that might be fit. 

Despite hiring additional capacity exclusively for the ERP project, the internal resources might struggle to build consensus due to the power struggle. Getting the attention of different internal groups due to the lack of their framework might be equally challenging. Finally, most teams might have preferences for a tool of their choice and might not be willing to give up on them to create a streamlined architecture.

Since the internal teams don’t track the ERP space on a daily basis, they generally have overarching assumptions in their model, such as assuming API means easier to integrate, or just because the company website says the tool is integrated with Salesforce, there wouldn’t be any surprises. What if the selected version of the ERP might not be compatible with this version of Salesforce? Assumptions such as this might fire back and make the cheapest deal the most expensive.

Pros

• Perception of it being cheaper
• Might be easier to collaborate with internal teams
• Can be done at the department level

Cons

• The internal team might take forever due to the missing framework
• Powerful forces might shut down other departments, leading to a biased selection process.
• Sweeping assumptions might drive much higher licensing fees and overengineered systems.

Final Words

Most ERP selection consultants feel that the ERP system is all about documenting and meeting the requirements. It’s actually the opposite. With enterprise systems, complying with requirements on their face value almost always leads to overengineered processes and overbudgeted projects. The prescriptive suggestion of software engineering to push back on the needs is often ignored by ERP selection consultants, who might not have a deep background in software implementation and engineering.

So if you are thinking of including an ERP selection phase, ensure you don’t treat it as any different than how you would approach a software development project. The SDLC phase has never been optional – and it will never be, regardless of whether you opt for modular assembly – or build from scratch. But most importantly, stay away from companies who walk away right after the ERP selection. Because the technical teams will likely shred those recommendations as soon as they take over, defeating the entire purpose of the ERP selection phase.

FAQs

No two change management projects are the same. Each project has its own nuances,  thus requiring a different level of subject matter expertise. While change management is often thought of as a function to support the business users’ needs, it’s more than that. Why? Because enterprise business transformation initiatives typically result in substantial refactoring of the customer- and vendor-centric processes. So, you need to have a plan, as well as change management deliverables, in place to avoid disruptions.

The impact on the customer and vendor processes might be so intense that each change impact could be a project in itself. Not only do you need to understand the financial implications, but you might need to sequence it with other corporate priorities, making it harder to schedule. In general, the changes could be as simple as rewiring the process of how you pack your goods. Or as impactful as changing the lot number scheme printed on the packaging.

And if the other departments might not be willing to concede to the necessary changes, it might complicate the technical implementation. So communicating and making business users understand the importance of these changes is vital for the overall health of the project. In fact, external communication could be even trickier and might require a “marketing touch” to your communication. Without it, the customers and vendors might choose to ignore it. Regardless of whether you use an industry-recognized framework or build one of your own, you need at least the following change management deliverables. Because they can help you stay organized with the change management aspect of your ERP implementation.

1. Change Impact Repository

Think of a change impact repository of the list of all change-related items identified in one place with the stakeholder map, in how their processes will be impacted because of each change item. It also helps in staying organized and keeping track of each item.

In summary, this database is the bird-eye view of each change as you collaborate with each stakeholder to understand the impact of each change.

2. Change Business Case

The purpose of a change business case is to understand the financial implications of each change item. The impact could be on user and customer experience, branding, or market share. The changes, such as changing the lot number, might require printing the new packaging and shipping to each vendor. 

You might also need to align with the planning for the old packaging, which might eat up the costs that might be sitting on the vendor’s shelves as they might not be able to use the old packaging. 

All of these factors will drive the costs, impacting the costs of your business transformation initiatives. The change business case would lead to the decision-making of specific change ideas that are feasible, and that can be explored further.

3. Change Transformation Roadmap

The purpose of change transformation is to create a detailed roadmap of change items. Each of which may have their own roadmap, depending upon the size of the change. It will include a high-level analysis of each accepted change that needs to be aligned with the technical implementation.

4. Change Program Dependency Analysis

The dependency analysis helps understand the relationships between different programs and how they need to be sequenced to ensure their timely execution.

5. Change Risk, Compliance, and Mitigation Strategies

Each change item may have its own risks, and the appropriate compliance and migration strategies need to be identified. The risks could be internal or external, technical or business. For example, what if the vendors don’t agree with the ASN process, would that result in finding new vendors or moving to the ones that are able to comply with the requirements? 

6. Staff Augmentation Plan

Depending upon the size of the new change, new resources might be required. This plan would include everything that is required to hire and onboard these resources.

7. Communications Plan

The purpose of the communication plan is to build a comprehensive strategy, including channels, touchpoints, messaging, personas, and stakeholders’ journeys.

8. Training Plan

The purpose of the training plan is to capture each of the personas and identify their unique training needs. So this could include as-is and to-be workflows for each user to make sure they are completely aligned with the new process. As well as cheat sheets to ease the transition. Not to mention any other training aids they might need to avoid disruptions and ensure data and process integrity.

9. Change Execution Plan

The purpose of the change execution plan is to have a detailed plan about how the change items will be executed. The activities captured as part of the change execution plan might be out of the scope of the digital plan. But since there will be cost and schedule dependencies, this plan is essential.

10. Change Readiness Assessment

The purpose of change readiness assessment is to understand if the organization is ready to change. It answers the questions such as, has the training been effective? Do they understand the to-be process state? Have they been testing seriously? Are they comfortable with the new systems or processes? This assessment will determine if they are ready to go live or would they need more training.

Final Words

Change management is an essential ingredient for a successful ERP implementation. But getting a budget approved for change management is easier said than done. Most initiatives that struggle to get approval don’t have a clear strategy, milestones, and deliverables defined, making it challenging for executives to assess the ROI.

This list will not only help provide structure for your change management initiatives. But it will also help avoid disruptions. If nothing else, this list can provide you with a good starting point for your change strategy.

FAQs

Before we touch on why test-driven ERP implementation is superior, let’s do a quick recap on software testing. First, who likes to rehearse? No one. Practice is boring, regardless of whether you talk about stage performance or ERP implementations. Understanding the importance of testing is even more difficult unless you test for living. That’s probably the reason why software development teams have a dedicated role in quality assurance. These professionals go through years of training to master the art of identifying boundary scenarios in order to catch the issues before they cause disruptions.

When professionals need so much training, how would you expect an average ERP user without training to test with similar expertise? Sure, consultants might help them document the test cases, but the users often end up not testing (or not testing enough). Because? They might not have the same level of appreciation for testing. And for these reasons, poor testing is the major cause of ERP disruptions. The examples of such disruptions? In the post-implementation phase, the system would not behave as per users’ expectations.

The issues could be as minor as struggling to log in. Not being able to print the forms. Or being unable to complete the transactions. Most of these issues exist due to the lack of testing. And this is where automated testing can really help. Why? Because it reduces the workload for users by helping with the testing in an automated manner. It not only helps ensure the test coverage but also validates how thoroughly users have tested the system. This is why you need test-driven ERP implementation. And the following reasons will help you understand its benefits.

10. Auto Generation of Test and Test Results in Documentation Easier

One major challenge with cross-functional ERP test cases is that documenting them is extremely challenging. Primarily because? They have many different steps with hundreds of prerequisites. Equally challenging is identifying the right test cases to ensure sufficient coverage.

This is where the automated testing tools can help generate test case documentation and validate the coverage from the platform itself. They have these capabilities built as part of the platform. Debugging and tracing the coverage is easier as well. While even the automated testing tools would require organizational skills, the framework helps them stay on track. As well as offering good quality documentation friendly for business users (who might not have as deep testing background).

9. Be Confident in Rewiring the Processes

Without an automated test stub, refactoring is always the most frightening experience. Because? What if you forget a few scenarios? Each refactoring may require retesting every single scenario. The reason? Because it’s hard to predict what may break.

With ERP systems, even a minor configuration change, such as pricing or UoM, may have implications in hundreds of places. 

The test-driven approach allows you to test right after each change (without going through the boring cycles of manual testing). So you could be confident with rewiring.

8. Increased Adoption Because of Fewer Issues

Why do users struggle to adopt the systems? Because the systems may not work as per their expectations. Going back to spreadsheets is always easier than learning the complex processes of a new system, leading to data siloes.

The automated tests map the workflows, just the way users would test and detect the challenges sooner, resulting in better adoption of the new systems.

7. Detect Cybersecurity and SOX Compliance Issues

The granularity of permission for each user and feature set in ERP systems is so complex that it’s harder to track. The more users there are, the harder it is to track access levels. Unless you have a methodological approach to creating user access, it’s likely to be chaotic and unorganized. Collectively, these issues lead to cybersecurity and SOC compliance issues. Testing the user access levels is even more challenging. Why? Because each user needs to be tested, making it a monotonous experience and leaving security issues because of manual errors.

The automated test stub could run on a daily basis and detect security loopholes as soon as configuration changes occur. This approach reduces the workload for users and provides traceability without coming across as looking over their shoulders. The automated test stub can also provide the traceability log for regulatory needs if the system might not have these workflows natively built.

6. Incorporate Issues with the Test Framework as Discovered

The challenge with ERP systems is the layered hierarchy of business rules and data. The fixes may have downstream implications. Also, the same error may pop up again, making the experience cyclical and frustrating for business users. 

The test-driven approach captures the test case first before fixing it, helping avoid repetitive errors.

5. Avoid Issues with Environmental Migrations

Unless you are super organized, environmental migrations will always lead to disruptions. Why? Because most ERP systems don’t have features that allow easy migration between environments because of the costs involved in building such features. Cloud ERP systems are especially trickier to migrate because of the database lockups.

The test-driven ERP implementation detects issues much sooner in the process. Without requiring manual test runs with an environmental upgrade. The same stub could be used to test across environments by supplying environmental-specific parameters.

4. Measure Test Coverage

You are often shooting in the dark with manual testing as it’s hard to ensure the test coverage. The users might not take the testing seriously, waiting to go live and for issues to surface, with a reactionary mindset.

The automated stubs can provide the coverage level at any given time to gain confidence in the ERP processes and to ensure that you are not shooting in the dark.

3. Centralized Coverage for the Enterprise Architecture

Just because you might not get issues with your ERP, it doesn’t mean that you will never get disruptions. The disruptions could be because of the integration point not being tested as well or due to the master data conflicts. 

The automated test stub helps in creating a centralized stub for the enterprise architecture, covering every single system and integration point.

2. Avoid Disruptions Because of Untested Code

Most companies implementing ERP systems have limited experience with these projects. And because of this limited experience, they might not appreciate the process and might feel that they can make it leaner. The leaner process often leads to a reduced budget. And the reduced budget, in turn, will lead to vendors cutting corners with testing and leaving untested code in production. 

The automated test stub can not only detect the untested code. But it can help prevent any disruptions because of the untested code.

1. Reduce the Implementation Time

Unless you have a test-driven ERP implementation, 70% of the time with most other ERP implementation projects is spent with manual testing. So much so that it might feel that you are working in circles. Also, if you have multiple entities, each entity might require a similar amount of time with manual testing.

Once created, the automated stub can be used for each entity with minor configuration changes, saving repetitive time with each entity. Collectively, this might lead to savings of up to 50% of the overall implementation time and, as a result, much cheaper implementation. The cost savings are likely to be higher with larger implementations.

Final Words

The monotonous execution of the ERP test cases might frustrate even the most excited champion. ERP tests are especially difficult, with sequences of workflows and hundreds of data inputs and outputs. Capturing them and ensuring test coverage requires a skilled consultant. 

Automated testing helps in ensuring the right amount of coverage and removes duplicate efforts with testing. But, most importantly, avoids disruptions before it’s too late.  So if you are ready for your project, make sure it’s a test-driven ERP implementation.

FAQs

Most new executives underestimate the implications of failed digital transformation initiatives, not taking them seriously until they go live on the solution. But unfortunately, just like baseball, the ERP projects bite the unprepared the most. The more planning you do, the higher chances you have of predicting various sliders and handling them.

As with baseball, ERP projects have a lot at stake. Poorly tested systems might prevent the processing of sales orders. It might take days to stabilize them. And if you don’t have your processes documented, consultants might struggle to keep up with code complexity. One fix may lead to another defect. And, just like in baseball, as you get more issues, the morale of the team will be so down, leaving them with negative thoughts, such as the ERP system being too complex or poorly configured. Completely giving up on the new system and going back to the old methods isn’t uncommon either.

Sometimes, the issues are so hard to explain that ERP consultants will rarely have an answer as to why a particular step during your strategy phase may be necessary. Just like the way coaches might not be able to explain why every player needs to run on a daily basis.  Just like baseball, the secret formula for success with an ERP project is discipline. And not of just a few players. But everyone from the top floor to the field. And without the chemistry working, get ready to face the following implications with failed digital transformation initiatives.

10. Lost Investment

Believe it or not, a large majority of the projects never go live, especially among first-time ERP buyers. The lost investment could be losing the licensing and implementation money completely and getting stuck in a contract.

The major cause for this issue is the misalignment in expectations. First-time ERP implementers have a tendency to underestimate the process and expertise required to find the right ERP software. They might not provide enough details to the vendors to enable them to do the due diligence. Also, vendors will have certain assumptions about clients’ data, processes, and internal expertise. Depending upon the skill set of both sides, the software may not have the capabilities promised or might not work as expected due to the state of the client data. 

Underestimating the amount of expertise required, companies might take the path of ERP customizations, getting into the never-ending investment-sucking rabbit hole. Even after years of testing and development, the business users might not feel confident in going live on the system, losing all of their investments.

How to Avoid?

1. Don’t look for discounts or the cheapest hours; instead, figure out why other vendors are charging more. 
2. Find the competitive pricing in the space, and go for the vendor that has a lot of specific details (not canned) in the SOW. 
3. Don’t customize anything at all. If you are on a budget, figure out how you might be able to perform the task manually where customization may be required.
4. Hire an independent ERP consultant, at least for the contract review. Document as much as possible for them to review to reduce the consulting fee.

9. Inferior Customer Experience

Failed digital transformation initiatives might end up increasing overall cycle time for transactions, increasing delivery times for customers, or increasing stockouts because of poor inventory management. 

The major cause is the misbelief that newer technologies will always provide a superior customer experience. The companies also miss to draw the processes both in the as-is and to-be state and estimate the number of steps increased for each department in the pre-selection phase. Not able to forecast trivial decisions such as the GL mappings at the customer level or customer master and how that would impact the KPIs or customer-centric workflows

How to Avoid?

1. Understand if there is a genuine concern from the customer service team about the increased time, and if so, figure out the optimum changes that need to be made in the processes, data, or technology – to get the desired metrics. 
2. Customer experience changes need to be traced, measured and agreed upon before selecting the software. 
3. Identify the KPIs that are expected to be improved after implementation and forecast the financial statements for the next five years. Trace KPIs, and see what process or data changes may be required. Also, design both as-is and to-be process and data models around the desired KPIs and keep track of the changes that might impact the to-be model of these KPIs, such as batch reconciliation or frequent cycle counting.
4. Follow out-of-the-box ERP processes as much as possible. The hijacking of processes with failed digital transformation might lead to increased admin and reconciliation steps that might impact operational workflows.
5. Have a good master data governance plan in place to ensure the data quality issues do not lead to the slower performance of the system, increasing the cycle time for the transactions.

8. Cybersecurity and Data Loss

Not having a deep understanding of the code quality and the deployment infrastructure might lead to cybersecurity and data loss issues. This issue is especially common among ERP vendors that might not be deployed on mainstream cloud platforms. As well as not being well-capitalized to afford a cybersecurity team for the upkeep. 

The major cybersecurity and data loss incidents would be with the solutions that are deployed in the on-prem settings or in tier 2 and below cloud providers. The smaller ERP vendors might sell their licenses at a discounted price and deploy the code in non-mainstream cloud providers, running into data quality and cybersecurity issues. The legacy code or unpatched and open-source libraries used as part of the assembly may leave vulnerabilities open.

How to Avoid?

1. Review the cloud infrastructure provider being used by the ERP vendor.
2. Ensure all of the add-ons, integration glues, and ERP systems are not leaving any security holes.
3. Check the backup policies of your cloud providers. How long do they keep the backup? How many times? How far back can you go to retrieve the data? Do they also back up for the test environment or only production?
4. Have standardized roles that can be assigned to all users to avoid losing track of permissions. Have a governance process for creating new roles and assigning new permissions to each role. Have good onboarding process documentation, including the right roles to be assigned to the team members. Limit the admin access and user maintenance to only super users.
5. Pay special attention to the apps and add-ons accessing the system. What level of access do they have? Understand what they are allowed to modify. And even with controlled access, avoid external modifications of financial documents.

7. Key Employee Attrition

Most failed digital transformation leads to some sort of blame game, even if it might not be anyone’s fault. The disruptions typically lead to overworked employees in debugging and reconciliation, resulting in the attrition of key employees.

In most cases, the issue is with the lack of expertise and most stakeholders overcommitting their capabilities and underestimating the efforts and investment required to get the failed digital transformation initiatives right. The transformation that runs into issues are the ones where the teams are not as seasoned with multiple ERP implementations under their belt and ignore the discovery process.

How to Avoid?

1. Involve employees from day one.
2. Build the as-is and to-be state models and a framework for team-based decisions that everyone is willing to own regardless of the outcome.
3. The leadership must enable the process owners, leading them to make decisions and not making decisions for them. Chime in when there is a misunderstanding of the overarching goals and cross-functional conflict.
4. Invest in the discovery process and seek feedback from users. Create a hotline for submitting any questions or concerns on the decisions made and address each of them publicly and explain the rationale behind every decision.
5. Take the implementation seriously and pay special attention to the training and testing phase. Don’t go live until the key employees feel comfortable and commit to going live.

6. Lost Window of Opportunity

If the goal of ERP implementation is to help with an opportunity that might have timeliness associated with it. For example, capturing a market share before competitors become known in that market space, or trying a new channel before it becomes crowded, the failed digital transformation and its disruptions might lead to losing the market share or window of opportunity.

The major causes for the delay or disruptions with a failed digital transformation project are related to the miscalculation of the efforts and time required to get it right.

How to Avoid?

1. Have realistic expectations with your team.
2. Keep digging until the scope of the ERP project is relatively known. If there are elements that might be too unknown as part of the project, they probably require more research and discovery to at least have a mitigation plan in place.
3. Have a reasonable time for stabilization before sequencing it with the opportunity. 
4. The more you invest in the ERP discovery phase, the fewer disruptions you will get during the implementation and post-implementation phases.

5. Brand Reputational Damage

Disruptions caused by the ERP failure could be as severe as not being able to process sales orders or cut invoices. Or not able to receive goods in the warehouse. Companies that have an impact on their brand because of the ERP failure were required to disclose them publicly. Or the customers end up reporting on social channels, causing permanent negative connotations about the brand.

The major causes are disruptions being received as the quality issues with the brand. The cyber and data loss issues might even have graver implications on the brand where the customers might not feel safe in their bank accounts etc.

How to Avoid?

1. Analyze the impact of each disruption. 
2. Document the implications of each change and how that might lead to a disruptive experience for the customers.
3. Don’t ignore any risks, and even if you might not be able to resolve them, document them and have an action plan if they do occur.
4. Avoid disruptions by overpreparing for the implementation and post-go-live

4. Lost Key Customers, Partners, or Vendors

The disruptions can lead to the loss of key customers, partners, or vendors. The customers that ended up losing them were the ones that faced material disruption with their deliveries, inventory allocations, and impact on their production schedule.

The new ERP implementation may not be aligned with the physical layout, posing challenges in keeping track of customer-allocated inventories, shipment delays, and not being able to fulfill customers’ expectations. The vendors, if larger ones, might be disrupted by your processes, such as not being able to receive the goods in the warehouse in the allocated time window and not paying overages that might be expensive at their end. These issues collectively might lead to issues in relationships with customers or vendors.

How to Avoid?

1. Include the impact on the customer and vendor processes in the as-is and to-be documentation.
2. Have multiple touchpoints and channels for customer and vendor communication to ensure that they are ready for change at their end
3. Ensure that the physical processes are in sync with the digital process to avoid inventory allocation issues.
4. Don’t simply kill the processes in the to-be architecture without understanding their impact.

3. Regulatory Penalties and Lawsuits

Regulatory penalties are more common than you would think with ERP implementation. They would result in not having integration or reconciliation issues between different systems, leading to misreported data, or not being able to file timely. Lawsuits might ensue if there are any issues with contract obligations.

The major issues with a regulatory penalty are related to buying systems from unreliable or unproven ERP vendors without understanding if they have been thoroughly tested and adopted in the market. They are also because of over-engineering of systems that might void the warranty from the vendor, leaving them off the hook for any regulatory or compliance issues.

How to Avoid?

1. Buy proven systems, especially the ones that touch financial regulatory compliance, such as ERP or HCM.
2. Don’t overengineer by building unnecessary customizations 
3. Have a clear separation of concern for the integration logic and packaged software
4. Keep a good log of the customizations and if they might have any impact on the reported data

2. Temporary Disruptions

Most ERP implementations will experience some levels of temporary disruptions, such as users getting locked down or not being able to print the forms. The issue could also be as severe as not able to send sales orders or close invoices. But most of these issues can be resolved quickly during hyper care.

The major cause of temporary issues is the lack of training and testing. As well as a framework for the change process that will help mitigate some of these issues.

How to Avoid?

1. Have a good framework to track the testing and measuring the readiness
2. Utilize automated testing to avoid repeat issues and augment manual coverage
3. Utilize automated testing to test the workflows, access rights,  and logins that might be harder to coordinate with end users
4. Have a training cheat sheet by the desk of each user on the day of go-live if they run into any issues.

1. Increased Permanent Work

While the temporary issues can be fixed easily through technical debugging and training, the permanent issues are far more serious. And they might have serious implications for your operations. And most of these issues are related to system design that might be unforeseen during the implementation and discovery phase. But the users might come to know them only after going live.

The permanent issues could be requiring unnecessary entry of sub-account with each transaction. Or it could be having users use unnecessary fields, increasing the total time to create a quote or sales order. It could also be due to the increased number of variances in the backend processes just because of poor system setup.

How to Avoid?

1. Design the to-be workflows and measure how much additional work will increase for each team.
2. Incorporate users’ feedback in designing processes to ensure coverage of most unforeseen issues.
3. Pay close attention to how the teams are capturing the master data and fix master data issues before it is too late.
4. Don’t ignore integrations and their implications for operational processes.

Final Words

Preparation is key to success in baseball, and so are digital transformation initiatives. The more prepared you are, the more confident you will be with the systems and the higher the adoption rate you will have of the systems. While technical issues may be easier to fix, what is harder to solve is perception. 

Once your team has decided that the problem is with the systems, it might be much harder to persuade them to enter the right data that will lead the accurate KPIs. So don’t wait for the implications to bubble up and be ready to put in the discipline required to be successful with the failed digital transformation initiatives.

FAQs

Getting the hang of the ERP implementation process takes time. Just the way it’s practically impossible to get a Ph.D. as soon as you enroll in a school, it’s also not pragmatic to get to one of the highest ERP maturity stages on your first attempt. In fact, you should not aim for that, as the success of your ERP implementation would depend upon finding the right tools designed for your ERP maturity stage.

In general, the first-time ERP implementation is likely to be the most immature, with very little process integration and, as a result, substantial manual overlaps (and admin efforts) across departments (and ledgers). Believe it or not, these implementations might even increase the overall workload without any tangible business outcome, discouraging first-time executives from any future digital transformation initiatives. When a company is past this ERP maturity stage, they hire slightly seasoned executives who are comfortable managing accounting and finance operations internally. As well as standardizing and modeling products (or services).

Sometimes, the ERP requirements of the company are driven by customers. In such cases, the front end typically takes priority over backend operations. But these implementation projects still have process and integration issues, creating planning siloes inside the company. As they advance with their backend processes, the 3rd and 4th ERP maturity stages are when they start experiencing material financial improvement from their operations. This is also where they would get true business agility. And the benefits of this agility? They can easily experiment with newer offerings and business models, allowing them to scale linearly. How about the overarching benefits? Gaining faster ERP maturity allows companies to grow rapidly. 

Stage 0: Outsourced Accounting

This is perhaps the ERP maturity stage of most startups where they would be working with an outsourced accounting firm (to manage their books). They might use siloed systems (without embedded financial layers) to help with their operational processes, such as inventory, project management, and manufacturing. But at this stage, no integration with the accounting system exists. 

The executive teams generally share their invoices, bills, and monthly statements with the accounting firm to manage their books. The accounting firm might provide reporting to the management teams to help with the decision-making. The internal team may have very limited visibility or control over how the accounting firm produces reports or insights. The operational teams might need to do data crunching at their end to handle their workflows and perform their jobs. 

For industries heavier in transactions, these companies are generally under $10M in revenue. The other industries might be able to survive at this ERP maturity stage with much higher revenue. At this stage, they have no CFO or controller in place. The team may not have an accounting, finance, or supply chain background. And the founder might manage most strategic functions, sales, operations, IT, and finance. The team may not have the skillsets to undertake the data and process translation required to implement a tightly integrated ERP system. The product industries may have their SKU and BOMs modeled. However, no modeling might exist for customers and vendors. The services industries may not have any modeling at all. 

Pros

1. Easy for the team. 
2. Does not require expensive resources such as Ops and finance executives. 
3. Does not require as much consulting help to automate the processes.

Cons

1. Limited traceability across processes. 
2. Substantial admin costs in reconciling ledgers. 
3. Data quality and financial control issues.

Stage 1: Assumed ERP

Once they outgrow the first ERP maturity stage, they can no longer rely on the outsourced accounting firm. But why? Because of the limited control and increased bookkeeping costs. At this stage, the companies in the product industries are in the range of $5M-$30 in revenue but higher for service-centric industries. They might still not have a CFO or controller in place. And neither is a CIO or Chief Supply Chain Officer. Most functions are still primarily controlled by the founder or President. 

The system architecture? The team may be living on multiple disparate systems such as QuickBooks, Shopify, and CRM such as Salesforce or HubSpot, and financial planning and budgeting might be done at the department level, in siloed software, or in spreadsheets. And the state of their data? SKU and BOMs may be modeled for product-centric industries. Customers and vendors might be coupled with raw GL codes without the reusable customer classes or layers of GL codes to enforce business rules.

The only difference between stage 0 and stage 1 is that the accounting instance is managed internally as opposed to with the help of an accounting firm. As well as some light integration for sending bills, invoices, and GL codes in the raw form, with very little financial control across the processes. So the financial insights are generally limited – or would require substantial data crunching as the data model of various systems are isolated and not modeled. As a result, the end-to-end traceability of transactions is extremely challenging.

Pros

1. Easy for the team. 
2. Does not require expensive resources such as Ops and finance executives.
3. Does not require as much consulting help to automate and integrate the processes.

Cons

1. Limited traceability across processes. 
2. Substantial admin costs in reconciling ledgers. 
3. Significant inventory, supply chain, customer experience, financial control, costing, and scheduling issues.

Stage 2: Transactional

With the growth of each department, the companies would struggle to grow (or might run into financial performance challenges) past $30M point. But why? Due to the increased marginal admin costs. And they would need to consolidate their processes and systems while keeping at least the main transactions (sales, purchase, and job orders) inside one core ERP system. In warehouse-centric industries, they might need to implement basic barcoding to reduce cycle time and transaction costs. 

The companies in this ERP maturity stage are generally between $30M-$100M in revenue for product-centric industries and higher for service-centric ones. The team skills? CFO or Controller might be in place but not seasoned (with at most 2-3 ERP implementations under his/her belt). Ops might exist only as an execution function.No CIO or Chief Supply Chain Officer might be in place. Developers or IT managers might act as the CIO, with very limited ERP experience.  The organizational structure might exist, but the CEO may not be as seasoned to build consensus and processes for cross-functional collaboration.

The system architecture? One or multiple ERP systems might exist, but the data, processes, and systems are only capable of transactional processing. The implementation may be finance-led, and the operational or supply chain perspective might be missing from the implementation, forcing them to use spreadsheets or siloed systems for their workflows. The implications? Significant variance and admin efforts are generally required to reconcile different books, ledgers, and master data.

Pros

1. Easy for the team
2. Does not require expensive resources such as Ops and finance executives to model various datasets
3. Does not require as much consulting help to automate and integrate the processes

Cons

1. Traceability limited across processes
2. Substantial admin costs in reconciling ledgers
3. Significant inventory, supply chain, customer experience, financial control, costing, and scheduling issues.

Stage 3: Automated Customer and Vendor Communication

Once they hit this stage, the transactional stage may not be enough with the growing transaction volume and, as a result, increased process overhead. Along with the growth, there are other factors, such as targeting larger customers — that might mandate seamless integration with their procurement systems – or having a specific certification or audit to win the large accounts. And this might drive another ERP implementation with the integration in mind.

Some companies may try to integrate their eCommerce systems or point-to-point integration offered through several SaaS tools. While the integration may be possible, the inclusion of additional channels and integration points will drive additional overhead. But the reconciliation is still done primarily through GL entries, with significant inventory inconsistencies and supply chain issues across channels.

Generally, multiple ERP systems are present at different warehouses and sites, with the role of ERP still very transactional in nature, with the majority of scheduling, planning, and costing happening outside of the ERP system or through ad-hoc adjustments. The consolidation is primarily done using the GL entries either inside the ERP system or using an FP&A tool. Significant manual reconciliation across the processes, but automated communication using punchouts, EDI, etc.

Pros

1. Automated transactions with customer and vendor systems
2. Does not require cross-functional alignment to operate on shared master data
3. Functions can independently plan and use the tools of their choice

Cons

1. Traceability limited across processes
2. Substantial admin costs in reconciling ledgers
3. Significant inventory, supply chain, customer experience, financial control, costing, and scheduling issues.

Stage 4: Department-Level Planning

While the customer and experience-driven requirements would take priority, the transactional nature of the processes and ad-hoc planning may lead to financial performance issues at this stage. And they will require teams to rethink their planning and scheduling processes. The increased workload and the pressure to hit the KPIs from the executive teams may lead departments to host their planning and scheduling processes inside the ERP system.

The planning would still be done at the department level due to the issues with the master data. And the site level or centralized planning may not be possible due to the differences between various departments. As well as the lack of experience of executive teams to build cross-functional consensus on the shared data. The executive team at this stage might still be relatively inexperienced in scaling global companies. Also, planning and scheduling might still take the backseat with the other easier priorities that might not require cross-functional alignments, such as public reporting or other compliance. 

The system architecture? Multiple ERP systems may be present at different warehouses and sites, as well as operating in siloes, with no centralized planning or optimization. Consolidation of financial reports may be done manually or using FP&A software due to the disconnected data sources from various departments. So the implications? Significant manual reconciliation across the processes.

Pros

1. Automated transactions with customer and vendor systems
2. Does not require cross-functional alignment to operate on shared master data
3. Functions can independently plan inside the ERP system without requiring cross-functional alignment on the master data

Cons

1. Traceability limited across processes
2. Significant issues with planning and scheduling.
3. Oranization-wide synergies not explored, and significant admin effort to reconcile cross-functional processes.

Stage 5: Site-Level Planning

At this stage, the department-level planning will lead to significant outgrowth of the finance and IT department. But why? Due to the reconciliation efforts among various ledgers because of the disconnected systems and processes. The implications? Profitability or sales growth issues due to the limited marketing budget. Also, at this size, the disconnected planning across departments may lead to operational issues in meeting fulfillment targets( or scheduling resources). These issues will force executive teams to cross-functionally align the teams. Or hiring executive teams experienced in aligning teams and with several ERP implementations under their belt.

These executives might hire a business transformation consultant (a.k.a independent ERP consultants) to redesign their processes and master data optimized for site-level planning and scheduling. While executives may be convinced with the site-level centralized planning, they might not foresee the value in global planning and finding synergies across geographies. So there might still be multiple ERP systems across geographies with limited communication and collaboration among entities. And the multi-site consolidation and planning? They would use FP&A software in the reactive mode. 

Pros

1. The site is fully optimized with their internal processes
2. Scheduling, costing, and planning are optimized at the site level
3. traceability is possible

Cons

1. Multi-entity and multi-geo synergies not explored
2. Significant issues with planning and scheduling at the global level
3. Heavier reconciliation cycle and longer close time due to the substantial variances among entities and translation required.

Stage 6: Consolidated Multi-entity Planning

While the site-level planning may be enough for domestic companies, they will outgrow that as their geographic footprint increase. As well as they get involved with substantial M&A cycles. This would require financial governance processes at the global level and finding synergies across geographies. At this stage, they would also require mapping out their material flow and supply chain processes across geographies to find synergies. But how? By consolidating the procurement of raw materials or reallocation of manufacturing capabilities.

Moving from site planning to consolidated multi-entity planning would require executive or private equity change that may be experienced in rewiring companies for global processes. A leading consulting firm may be involved in leading the international change process. As well as creating shared master data models that can be used across geographies. At this stage, while the business executives might be seasoned, the problems are not big to require large IT departments to do the workload planning and building an architecture that may require splitting the processes or systems because of the increased workload.

Pros

1. Multi-entity and multi-geo operational synergies
2. Shared master data across geos and shared planning and forecasting
3. Multi-geo traceability possible

Cons

1. Financial synergies not explored at the global level
2. Training and learning synergies not accounted
3. Might slow down the planning and forecasting cycles

Stage 7: Joint Planning and Forecasting/Shared Services

Once the operational synergies are fully exhausted, the next priority would be to align the vendor and customer processes for joint planning and forecasting. This would require mandating customer and vendor channels to share their data and be on the same/electronic systems, so the data can be gathered for joint forecasting and planning. Exploring the financial shared services model would require measuring transaction times and costs across geographies.

The shared services models and joint planning and forecasting would require a strong IT COE, which might only be possible after a company reaches a certain stage in ERP maturity. But the IT expertise is still limited to rewiring the business processes and designing the processes compatible to explore financial synergies. And the system architecture? There might be multiple ERP systems involved to segment the shared services model, but the operational processes would still be able to perform joint planning and forecasting.

Pros

1. Predictive forecasting opportunities because of shared data from customers and vendors
2. Ability to control disruptions in the end-to-end supply chain
3. Ability to explore global financial synergies utilizing shared services

Cons

1. Requires very expensive IT capabilities and consulting support
2. Training and learning synergies not accounted
3. Might slow down the planning and forecasting cycles

Stage 8: Enterprise Architecture/Best-of-breed

At this stage, the companies may be processing millions of journal entries, and so to handle the workload, the ledgers need to be designed to balance global planning and transactional performance. The processes need to be thought through from the technical perspective in terms of where the transaction volume and reconciliation effort are too high to keep the processes outside of the core ERP system. Also, due to the increased employee counts, the training and learning costs may drive the adoption of best-of-breed systems in specific functions.

This architecture would require a rethinking of enterprise architecture across system boundaries, in how the master data is produced and how it’s augmented, including reconciliation flows. Enterprise integration is so complex at this stage that companies need to implement a centralized integration architecture at the global level. They might as well require an MDM, mapping out all the producer and consumer workflows. This architecture may require testing throughput for each component to ensure that the global architecture is capable of handling the processing of these transactions. Most companies will have a very seasoned CIO as well as an IT department capable of designing the architecture at this scale.

Pros

1. The decoupled architecture allows the scaling of transactions
2. Business agility and faster M&A cycles because of clearly defined architecture
3. Learning and training synergies explored

Cons

1. Requires very expensive IT capabilities and consulting support
2.  Might be very expensive to build and maintain
3. Lack of enterprise architecture expertise may lead to failed transformation initiatives

Stage 9: Decision Support System and AI-augmented Workflows

Clearly defined architectural boundaries and globally modeled master data allow mining quality data and building a decision support system layer on top of the core architecture. The decision support system would help complete the incomplete data by combining external datasets, build a data science layer that would help detect GL anomalies, superior revenue recognition workflows that will further optimize the profitability and revenue, and find opportunities by optimizing container space or better packaging strategies.

At this stage, all of your control centers are consolidated and have completely connected planning and forecasting data across the geographies, systems, processes, functions, customers, and vendors, as well as overlaying external industry datasets. Building and maintaining these capabilities requires not only the IT department but a very strong team of data scientists with deep capabilities of building models on top of the enterprise architecture to find revenue and profit opportunities, building real-time integrations with machines and sensors that can be reliably controlled using AI-augmented workflows.

Pros

1. Connected planning allows for finding new revenue and profit optimization opportunities.
2. Clearly separated boundaries for operational and data workflows allow scaling analytical workflows without impacting operational performance.
3. Connected models allow operating on one planning data for the entire supply chain.

Cons

1. Requires very expensive IT and data science capabilities
2.  Might be very expensive to build and maintain
3. Lack of enterprise architecture expertise may lead to failed transformation initiatives.

Final Words

There are several variables that drive ERP maturity. And most companies go through many different cycles before they can realize true business value. So while you might feel that you are fairly successful with your ERP implementation, unless you are on stage 9, you have no idea what you have been missing out on.

And if you are curious whether you can get more juice from your existing digital transformation investments, try to grade yourself on this scale and gauge if you might have further room for improvement.

FAQs

Going through an ERP implementation is like heart surgery for your business. And just like with surgeries, everything matters your body type (your business model), your psychological state (the changes in the state of your business with time), doctors (ERP consultants), doctor’s expertise (their skillset and experience), equipment (ERP solution), procedure (implementation approach), and the hospital (your data, processes, and architecture). Most surgeons planning the surgery for the first time go unprepared and end up killing patients. They may have watched other surgeons and might not fully appreciate the craft required to be successful. 

Understanding and articulating why they are so challenging requires you to go through multiple surgeries on a daily basis. The same goes for ERP implementations. Luckily, with heart surgeries, we have regulations that help prevent failed surgeries. With ERP implementations, there are none. And that’s why the experience and results vary so much, with only a few lucky ones getting business results and using them as their competitive advantage.

First-time implementors are very similar to first-time surgeons. They underestimate the amount of effort involved and the expertise required. And as SaaS technologies are becoming easier to use, this tendency is only hurting them more. Generally, it takes at least 2-3 implementations in the company’s life cycle to appreciate the whole process and be informed about the efforts required to avoid business disruptions or million-dollar ERP disasters. It might take another 2-3 to achieve tangible financial performance improvement, which is attributed purely to this investment. So, what are the different approaches for ERP implementation?

1. Change-focused Phased Business Transformation

This transformation starts with the overarching business strategy or business model changes, including planning for managing the change and the communication plan for employees, customers, and vendors. This initiative is very similar to how you would plan your inventory or operational capacity, starting with the business and annual operating plan, followed by identifying the right KPIs that need to be improved through potential digital initiatives. The process starts with building as-is and to-be process (and data) models, including financial statements and KPIs forecasted for the next 5-10 years. 

Depending upon the companies’ budget and skillset, they may manage the entire change and business case process internally while hiring consultants primarily for the subject-matter expertise of enterprise software and ERP. The other companies, on the other hand, may want them to lead the entire project, including strategy and planning, selection, and implementation. The strategy phase of such engagements is likely to be close to 6 months – 2 years, depending upon the size of the organization. The implementation and execution phase could be 2-10 years, with multiple phases managed as part of the global rollout.

Engagement Structure:

It consists of a selection phase with only the selection consulting firms managing the entire process, whereas the implementation phase may involve ERP OEM, ERP resellers, ISVs, and enterprise software vendors.

Pros: 

1. Complete alignment of corporate strategy with digital execution. 
2. Superior definition of success.
3. Motivated teams due to the end-to-end visibility of goals.

Cons: 

1. Might be harder for larger organizations to build future financial models. 
2. Expensive. 
3. The costs involved with the strategy phase might demotivate executives who might be hoping for quicker returns with digital initiatives.

2. Phased Business Transformation

Unlike the change-focused phase business transformation initiatives, these initiatives might not have formally planned change management activities. Identifying the business priorities from the business and annual operating plans without putting as much emphasis on documenting as-is and to-be process models would be the primary difference. The executives and business teams might drive these initiatives as they might have specific business performance issues or a set of issues that they might be looking to resolve. The structure of these engagements would be similar to the change-focused business transformations, with the primary difference being in the length of the selection phase, which is likely to be shorter, while the implementation phase would be a bit longer.

Engagement Structure:

During the selection phase, typically, only strategy and independent ERP consulting firms would be involved. ERP OEM, ERP resellers, ISVs, and enterprise software vendors might lead the implementation. 

Pros: 

1. Less time spent on discovery. 
2. Superior definition of success. 
3. Clear visibility into business goals and KPIs.

Cons: 

1. Adoption risk issues due to less time spent on discovery and change management. 
2. Longer implementation time due to the iterations required during the implementation phase. 
3. The costs involved with the strategy phase might demotivate executives who might be hoping for quicker returns with digital initiatives.

3. Business Transformation

Unlike phased business transformation, in which a substantial amount of time is spent on the overarching corporate strategy before deciding the right phases and planning their sequencing. Business transformation is all about planning for specific ad-hoc issues. Sometimes they are done at the department level, and the other times corporate. The biggest difference in this transformation engagement is that there might be duplicate efforts across the enterprise to solve similar problems. While these initiatives may be successful at the project level, the business might not get the overarching results due to the misalignment of different initiatives.

Engagement Structure:

The engagement structure and the vendors are very similar to the phased business transformation. 

Pros: 

1. Less time spent on discovery. 
2. Definition of success. 
3. Visibility into business goals and KPIs.

Cons: 

1. Questionable success due to the misalignment between corporate goals and execution.
2.  Adoption risk issues due to less time spent on discovery. 
3. Longer implementation time due to the iterations required, as well as in aligning the plan with the corporate strategy. 

4. Process and Data Re-engineering Transformation

Unlike business transformation-focused transformation, where the deep analysis of the financial and process model is performed of both as-is and to-be, the starting point for these initiatives might not be the business or annual operating plan. And obviously, no KPIs analysis. Specific business challenges, such as outgrowing the current ERP system or reaching an inflection point in the company’s growth journey, are typically the starting point, followed by the rounds of deep process and data re-engineering prior to selecting the technology.

Engagement Structure:

Since these engagements are process and data re-engineering led, independent ERP consultants might take the lead with these projects and be involved during and post-implementation to ensure that the to-be state is successfully implemented.

Pros: 

1. Process and data re-engineering would increase the chances of successful selection. 
2. Alignment between users and implementation teams. 
3. Reduced risk of over-engineering and over-customization.

Cons: 

1. Questionable success due to the misalignment between corporate goals and execution. Assumed to-be state may result in implementation failure. 
2. Longer implementation time due to the iterations required to align with the corporate strategy. 

5. Enterprise Architecture Implementation

While the entire architecture implementation takes a comprehensive view from the technology standpoint, they might miss the business, process, and data viewpoint. Unlike other implementation types where only one product or area might be in scope, this implementation type considers all the systems in scope, such as ERP, CRM, eCommerce, WMS, TMS, MES, etc. This implementation type would address core technical challenges such as master data governance, reconciliation flows, and data migration.

Engagement Structure:

Since these engagements might be IT-led, they might recruit independent ERP consulting firms for selection, enterprise architecture, 3rd party QA, and managing the program. The ERP OEMs, resellers, and ISVs would be involved during the implementation phase.

Pros: 

1. Less risk of data siloes due to the enterprise architecture perspective. 
2. Alignment between enterprise architecture and implementation team. 
3. Less duplication of code and capabilities across the enterprise.

Cons: 

1. Questionable success due to the misalignment between corporate goals and execution. 
2. Assumed to-be state may result in implementation failure. 
3. Longer implementation time due to the iterations required to align with the corporate strategy. 

6. ERP Implementation (Cross-functional Integration)

Unlike the enterprise architecture implementation, this approach takes a siloed perspective on ERP where they might have several initiatives, such as WMS and MES implementation, running in parallel to ERP. The ERP implementation may make assumptions about the master data reconciliation and integration flows. But might not spend as much time on the discovery and planning of the overarching architecture and business transformation, as well as change management at the corporate level.

Engagement Structure: 

Since these engagements might be finance- or CFO-led, they might recruit independent ERP consulting firms for selection. The selection is primarily siloed, considering only the ERP-centric workflows and processes. Some selection firms focused only on ERP might not be comfortable engaging during the implementation phase, and the implementation might be led by the ERP OEMs, resellers, and ISVs.

Pros: 

1. Cheaper 
2. Faster Implementation 
3. Great for teams where they might not have control over corporate strategy or enterprise IT.

Cons: 

1. Significant integration risks 
2. The risk of admin efforts due to disconnected ledgers and master data 
3. Missing technical perspective might lead to selection and implementation issues.

7. ERP Implementation (Functional Best-of-breed)

This is probably not an ERP implementation but is often misunderstood. The functional ERP is one of the best-of-breed apps for a specific function such as HCM, CRM, accounting, or eCommerce. While they might be perceived as an ERP, the cross-functional integration is very lean and fragile (and, most often, non-existent), causing significant integration and reconciliation issues across processes and departments.The budget and planning for these initiatives are done at the department level.

Engagement Structure:

Since these engagements are primarily LOB or department-led, such as HR, marketing, or Supply Chain, a selection firm may not be involved. The implementation is primarily siloed, considering only the function-centric workflows, with minimum visibility into cross-functional processes.The CRM, HCM, WMS, TMS, eCommerce OEMs, resellers, and ISVs might lead the implementation, with minimum involvement of the selection and change management consulting firms.

Pros: 

1. Cheaper 
2. Faster 
3. Great for teams where they might not have control over other departments or might need to implement a system for quicker, siloed results.

Cons: 

1. Significant reconciliation and master data governance risks 
2. The risk of increased admin efforts due to disconnected ledgers and master data 
3. Missing cross-functional perspective might lead to selection and implementation issues. 

8. Handoff ERP Implementation/Checklist and Data Upload

While often promoted by ERP OEMs and Resellers as an implementation or consulting project, this is really a setup. The responsibilities of the OEM and their reseller are limited to the tool and training provided on the tool. Due to the limited budget planned for these engagements, they will not be able to spend as much time with processes or data engineering. Their answers would be limited to how the tools would handle the processes and their best practices, primarily due to legal compliance issues and their limited understanding of other areas of business transformation. The process would start with filling out a series of checklists and spreadsheets, but you would be responsible for identifying the right GL codings, customer master, SKU normalization, and reconciliation workflows.

Engagement Structure:

With this implementation, the client would engage with the ERP OEMs and resellers directly during the sales process, and the process would start upon signing the ERP contract. The client would manage the implementation directly with their internal resources and work directly with the reseller or OEM. The implementation time may be longer without any prep, but you would be required to pay the license fee from day one.

Pros: 

1. Cheaper 
2. Faster 
3. Ideal for companies with deep internal ERP COE and master data experience

Cons: 

1. Significant integration risks 
2. Significant data translation risks due to the gap in understanding of as-is and to-be data models 
3. Risk of implementation failure due to inadequate process and data reengineering.

9. Templated ERP Implementation

This ERP implementation is often promoted by ERP OEMs and resellers as a quicker implementation approach. Sometimes the price of these implementations could be as low as $30K. These implementation templates are pre-configured with the chart of account mappings, item SKUs, etc., and you are expected to change your business processes and data within the framework of the template. Any deviations would be billed separately. While they sound great on paper, these templates assume that all businesses are alike and that their data, processes, and transactions would be in the exact same state as the other businesses. But unfortunately, every business has its own nuances. And even with process and data re-engineering, the templated approach might not work.

Engagement Structure:

With this implementation, the client would engage with the ERP OEMs and resellers directly during the sales process, and the process would start upon signing the contract. The client would manage the implementation directly with their internal resources and work directly with the reseller or OEM. They might rush to go live but expect substantial disruptions and adoption issues post-implementation, with huge dollars with ERP customizations and support.

Pros: 

1. Cheaper 
2. Faster 
3. Ideal for companies with substantially limited implementation budget

Cons: 

1. Significant integration risks 
2. Significant data translation risks due to a gap in understanding of as-is and to-be data models 
3. Risk of not going live because the users might not feel comfortable going live on templated processes.

10. No Go-live Implementations

Most unplanned and first-time implementation result in not going live and are a complete waste of investment. Regardless of whether you go live or not, you would still spend your time and money with these implementation projects and sometimes be locked in the ERP contract as well, even though you were not able to use the software at all. The main cause of this implementation failure is overcommitment and misunderstanding during the sales process. 

The misunderstanding could be because of any reason, whether you forgot to share crucial details during the sales process or the reseller or OEM couldn’t spend much time and overcommitted. While cheapest on the surface, these implementation projects might turn out to be the most expensive of all due to unproven capabilities, overengineering of the solutions, or poor data driving substantial process issues. Inexperienced clients might not have enough experience in vetting vendors’ capabilities. The vendors might overcommit because of poor discovery or pressure to close sales.

Engagement Structure:

With this implementation, the client would engage with the ERP OEMs and resellers directly during the sales process, and the process would start upon signing the contract without the involvement of an independent ERP selection Or change management consultant. 

Pros: 

1. Cheaper 
2. Faster 
3. Ideal for companies who can afford to lose their investment with R&D.

Cons: 

1. Significantly over budget 
2. Total waste of time and money 
3. Business Disruptions

Final Words

While it’s always critical to undertake the implementation type that suits your budget and goals, try to understand the different options available and their implications for your business. Choosing a templated approach is almost similar to productizing heart surgeries, assuming all hearts and bodies are the same. And this mindset may end up costing way more than what you might save on the surface. 

So if your goal is to get business value from an ERP implementation, talk to an independent ERP consultant who can guide you through the process and walk you through the pros and cons of the various options available. But most importantly, run away from people who might claim that ERP implementation is easy.

FAQs

Marrying without planning is likely to be a painful journey, with consequences as severe as personal bankruptcy. Just like planning for your marriage, the enterprise digital transformation readiness step is not optional. It’s mandatory to avoid implementation disasters — and post-implementation disruptions. The more preparation you put in, the less painful the journey gets, with the lower total cost of ownership. Regardless of whether you pay during the prep phase or during implementation, you will end up paying about the same. So, the only difference with the prep phase is that you can save yourself a ton of headaches.

Also, some people could perceive the digital transformation readiness step as abstract (and requiring sunk costs). They might be tempted to find shortcuts, such as keeping additional funds for unexpected risks or doing unnecessary chores.  While these strategies might help to some degree, digital transformation readiness is about comprehensive planning, involving putting the entire plan on a piece of paper (blueprinting). It will also identify the issues with the initial plan (process re-engineering), assess the financial feasibility (business case), and finally test if the current resources can withstand the pressure exerted by new demand (enterprise architecture plan).

The phases would differ depending on the current state of your data (and processes) and how you want to segment your prep and implementation phases. But even with a prep phase, a structured process is necessary, leading to the following most common deliverables. These deliverables will help you stay on track without feeling lost in your journey.

 1. Business and Strategic Plan

Creating a business and strategic plan is fundamental to your digital transformation readiness. It’s essential because it not only drives the annual operating plan but also helps plan the volumetric capacity expectations from digital systems. 

Why it matters:

• No destination? Keep wandering. Even if you are completely off, that’s OK. 
• Can’t define the destination? No Odds of getting there. Just defining it will help improve the chances of being closer to your destination. 
• Writing it down will help define the destination. When you write something down, you will be slightly more informed. Otherwise, most executives like to dream of growing by 60% or 300% but would be clueless when asked about the execution plan.

Essential Ingredients:

• Business model and SWOT analysis. For example, the basic documentation of customers, channels, offerings, and SWOT analysis.
• Customer and supply chain journey mapping. E.g., High-level customer and supply chain journey that will be used as input for the process re-engineering step.
• Offerings and bundle strategies. Such as offerings, bundles, and how they map to each customer and customer channel. % split of revenue per offering and bundle. Strategic vs. non-strategic offerings. And pricing and discounting strategies.
• Strategic goals, execution plan, and expected results. Strategic goals and execution plans for each goal, as well as the desired KPIs that you plan to hit with each goal. Justification of why you believe technical changes are necessary to hit these goals.
• Financial Model. Detailed pro-forma financial statements of at least five years with forecasted ratios and KPIs aligned with the financial goals.

Make sure you don’t ignore this step, as it will help firm up an understanding of the direction and help you communicate the vision better.

2. Annual Operating Plan

Annual Operating Plan is a detailed forecasting and planning step that also outlines physical infrastructure growth. It uses a strategic plan as input and outlines a detailed plan for each individual function.

Why it matters:

• Wishlists are great, but can you afford them? In other words, each system and architecture assume a specific operational and transactional capacity. Define the capacity that is consistent with your growth plans.
• Helps firm up the strategic plan. Eliminates vague assumptions that might not be financially feasible and help you focus on the right objectives.
• Helps measure the outcome of transformation initiatives. Said another way, helps define the right KPIs that will be a true definition of success.

Essential Ingredients:

• Market, facility, site, product line, and warehouse expansion plan. Expands on the objectives defined in the strategic plan and build a financial model for each chart of account and dimensions.
• Human resources plan. Identifies the growth of human resources in each department, helping forecast the transactions and licensing requirements.
• Digital transformation strategic plan. Identifies the budget and high-level financial feasibility of different technology needs outlined in the strategic plan.
• Expected transactional volume. Details such as # of sales orders, purchase orders, sites, facilities, # of products, and production lines – all of which dictate the transaction volume and expected capacity from the architecture.
• KPIs and OKRs for measurement. Specific detailed KPIs per department, per role, in the as-is and to-be state.
• Key planned activities and stakeholders mapping. Mapping of stakeholders with defined activities, who does what, and which department is responsible for what.

Without an annual operating plan, it’s hard to estimate the internal capacity, transaction volume, and KPIs that will define the success of your digital transformation readiness.

3. KPI-Role-Compensation Plan As-is and To-be

This step analyzes the impact of the current compensation structure on KPIs and how that might influence the behavior of each role. As well as drive the resistance to change.

Why it matters:

• Let’s face it. Needles won’t move until compensation moves. Technology only goes so far. You need a lot more than technology to ensure people embrace the technology.
• Not willing to change the comp? Don’t even bother making a change. Regardless of how cutting-edge the technology might be, people won’t adopt it. So, change the compensation aligned with the expected change.
• Digital transformation initiatives are like financial markets. Not much difference between “bank runs” and “system runs.” The resources will run as fast as they can if they don’t see a personal benefit. 

Essential Ingredients:

• As-is compensation. List down different variables of the current compensation of each role and department.
• Compensation-department-behavior mapping. Additionally, the analysis of current behavior with the compensation variables and how each department might be influencing these behaviors.
• As-is behavior and change impact analysis. As well as analysis of as-is behavior on the proposed changes and forecasting of any resistance expected motivated by compensation impact.
• To-be behavior and change impact analysis. Not to mention analysis of the desired behavior on the changes proposed and how the compensation variables need to be changed to influence the right behavior.

This step will decide the fate of your digital transformation readiness. So don’t forget to map the benefits with people’s paychecks for the enterprise’s digital transformation to be successful.

4. Role-Department-System Org Chart As-is and To-be

This step maps the role and department with the systems in both the as-is and to-be states. This is a crucial step both for change management as well as system architecture, as the to-be state needs to be designed depending upon teams’ comfort level in whether they are willing to give up on the processes or not.

Why it matters:

• Role system mapping is like an org chart for systems. No org chart → pure chaos. Disagreement among users might result in data siloes, process hijacking, data quality issues, and reconciliation nightmares.
• Forms the foundation of change management. Helps them understand their as-is and to-be workflows and helps them articulate the unforeseen issues or implications only known to them.
• Helps each resource visualize why the change is necessary. Enforces the buy-in as they are able to visualize cross-functional challenges of why a certain system or a process changes.

Essential Ingredients:

• Role and department mapping in the as-is and to-be plan. How each role would map in the new architecture. Would there be changes in the reporting structure or organizational hierarchy, as well as process ownership?
• Communication plan on why the org change is necessary. Identify the workflows for each change and provide a tailored plan for each stakeholder.
• How each role would map, including the owner of each system and dataset. How each role would map to each system in the as-is and to-be process model and what they need to do to be ready with the new system.
• Process boundaries of each role and data interaction workflows. The expectations from them during process handshake and their responsibilities for data ownership.

This is perhaps the first step in building a consensus on the draft-to-be process state and architecture.

5. Business Case and Transformation Roadmap

This step is where the rubber meets the road. This step reviews each of these proposed initiatives and build a brief business case, phased priorities, and appropriate sequencing based on technical and financial feasibility. 

Why it matters:

• Helps eliminate “binary” vision and unqualified resources. Help executives filter out noise from the signal.
•  Helps prioritize initiatives. Including the dollars in the conversations helps focus on the most essential without wasting time.
• Helps build a phased roadmap. The phased roadmap is essential to avoid the big bang approach and the risk of demotivating sponsors.

Essential Ingredients:

• ROI analysis of each initiative. Cost velocity and cash flow analysis of each initiative to help compare different options.
• Potential solutions and costs of each initiative. Focus on the entire solution rather than taking a siloed approach, including the costs of each integration, maintenance, support, etc.
• Buy vs. build vs. outsource analysis. Compute and compare costs based on the opportunity costs of internal resources, additional hiring, etc.
• Internal staffing needs vs. outsourced capabilities map. Include the map of what is expected to be done internally vs. outsourced. Identify the internal staffing needs. The poor internal hiring results into schedule slippage and overbudget issues.
• KPIs and definition of success of each initiative. Identifying KPIs for success will help stay on track and communicate the value of the initiatives.

Once agreed on a specific path and the total spend, the following steps will build on the solution path identified but come back to the roadmap and consider alternatives if the original solution might be financially or technically risky.

6. Change Management Plan

The changes may have wider implications and need to be planned and communicated. For example, say the to-be state requires a new SKU numbering or new configuration for license plates, which might require vendor and customer communication, along with making sure that the packaging team has the bandwidth to accommodate the changes timely. 

Why it matters:

• Helps develop organization-wide language that everyone can understand and speak. Builds consensus on changing processes and customer/vendor communication elements.
• Provides cross-functional visibility and implications. Also helps identify and track cross-functional dependencies and builds the communication plan.
• Documented agreement on the current challenges. Documented processes help trace the root cause of the current challenges.
• Helps differentiate tangibly executable initiatives. Helps assess the cost and impact of the change on the branding and market share.
• Alignment on the to-be changes and why users’ contributions and commitment will make or break the initiative. Helps users see the big picture about why their contributions and commitment are important for the success of the program.

Essential Ingredients:

• Documentation of as-is workflows and process maps. Complete documentation of each role and their workflows for them to be able to relate, connect, and get trained.
• Identified changes aligned with strategic priorities and business case. Perform business case analysis as the cost of change is a factor for the overarching cost of the initiatives. 
• Implications of changes on the business processes, roles, workflows, and the steps required to be successful. As well as the mapping of each change in the business processes, roles, workflows, etc.
• Documentation of key decisions, risks, and mitigation plans. Along with any proofs-of-concept that need to be performed to mitigate these risks.

Depending on the degree of the change and implication, appropriate plans and solutions need to be identified that are not only financially not feasible but technically not too risky.

7. Organizational Ledger Reconciliation Plan

Organizational ledger reconciliation requires tracking each of the datasets and how they will be reconciled. For example, decisions such as how many systems should be used in the architecture by building the reconciliation plan and estimating the cost of reconciliation. For example, if the team is fighting for an additional system, but the cost of reconciliation might be more than the 2 FT employees, then the additional system may not be worth it. 

Why it matters:

• Helps define ownership of each dataset and agreement on the reconciliation. 
• Help avoid reconciliation nightmares and whether reconciliation will be more expensive than simplifying processes or technology. 
• Helps understand the transactional integrity and whether a specific process must reside inside ERP, best-of-breed, eCommerce, or Analytics warehouse. 
• Set the tone for the enterprise architecture. Without a reconciliation plan, there might be issues with enterprise architecture with master data governance and process conflicts.

Essential Ingredients:

• Documented interactions of organizational ledgers AR, AP, GL, Inventory, cash, sales operations, marketing analytics, shop floor data, HCM, and supply chain forecasting.
• Documented impact on the financial or statistical ledgers. Classification of financial vs. statistical ledgers and their impact.
• Documented data ownership and reconciliations models, real-time or non-real-time posting. Real-time posting vs. batch? Summary vs. detailed?
• Defined ownership of KPIs and data marts and their interaction workflows. Reporting and data requirements from each ledger. Analysis vs. financial integrity of operations.

The ledger reconciliation plan help build how many datasets need to be reconciled, how many times, and how many variances will be expected, which will drive the expected capacity of the finance department.

8. Master Data Governance and Reconciliation Plan

Just like an organizational ledger reconciliation plan covers the functional aspect of the account and inventory reconciliation workflows, master data governance is the technical aspect (at the definition or at the metadata level) of reconciliation. 

Why it matters:

• Helps understand the origins of each master data such as customer, vendor, products, services, chart of accounts, bank accounts, machines, equipment, human resources, credit cards, payment terms, etc. 
• Helps understand the master data augmentation journeys and ownerships of each delta. 
• Helps define processes for future master data integrity. Poor master data governance might lead the performance issues and the re-implementation of the system.
• Provides clear guidelines for the master data reconciliation plan in case of a conflict. 

Essential Ingredients:

• Master data to system mapping at the field level. Map each master data at the field level to the system and who owns it. 
• Master data augmentation journey per system at the field level. Define the augmentation journey at the field level, where the dataset gets originated, modified, and consumed.
• Master data relationships change across journeys. Flatting the layered data? Define the reconciliation path for each changed hierarchy.
• Master data mapping to key use cases. Define the master data structure for complex use cases such as buying groups, warehouse and location architecture, and transit locations.
• Admin and approval flow, given the implications of each master data. Define the approval flows and the stakeholders involved in approving datasets, including the governance process or automation needs.
• Producer-to-MDM and MDM-Consumer Workflow mapping. Using MDM for master data management? Define workflow for each MDM interaction across systems and departments.

A master data reconciliation plan helps refine the enterprise architecture and avoids data quality issues such as duplicate data, data siloes, and financial control.

9. Process Re-engineering Plan

The process re-engineering plan documents all the process re-engineering candidates in detail with their as-is and to-be workflows, including the migration plan for the new processes.

Why it matters:

• Identified process re-engineering candidates to stay within budget. Each broken process might lead to millions of dollars in overengineering of systems and architecture.
• Impact of process engineering on the current process. How much impact would the current processes have because of the re-engineering? Is that financially and commercially feasible?
• Impact of process re-engineering on the customer-facing workflows. Would customers be willing to adapt to the changes? Do the changes impact customers’ workflows?
• Impact on the product, branding, warehouses, facilities, and shop floors. Any physical changes needed in the warehouse layouts, packaging, etc., needed for process engineering to be successful.

Essential Ingredients:

• Cutover and training plan for current users. Training plan in coaching the current core team on the process of reengineering to be able to forecast the implications.
• Training plan and guides for the customer service and sales reps. Training plan and guides for the end users for the to-be state.
• Mock scripts to rehearse the process re-engineering scenarios. Design mock scripts for the current users to rehearse the new processes.
• Framework to enforce readiness and learning. Plan for compliance and digital transformation readiness, including automated governance processes and sustainability in the to-be state.
• Communication and training plan for the customers, resellers, and partners. Including any PR campaigns and asset development such as websites or internal portals.

Having a good process and re-engineering plan helps you avoid overengineering the systems or the critical success factors that lead to poor system selection.

10. Enterprise Architecture Plan 

The enterprise architecture plan is written from the perspective of the technical teams to help align the technical and business teams. It helps the technical teams to challenge the assumptions and demonstrate the technical and financial feasibility of the plan.

Why it matters:

• Helps align technical teams with business, process, information, and technology. As well as helps align strategy, execution, quality, and KPIs.
• Reassesses the business case from the perspective of technology.
• Identifies red flags. As well as their mitigation plans.
• Sets the boundary of each system in the architecture, and their interaction flows
• Defines integration flows. Not to mention the cost of each integration.
• Defines users to system interaction flows. As well as setting their boundaries

Essential Ingredients:

• Detailed documentation of data. As well as process flows across system boundaries
• Pseudo code for major business rules and translations at the component level
• Mapping of each interface at the field level, inputs, and outputs. As well as the processing needed from each component.
• Documented requirement matrix, broken down at the story level and verified by technical teams, not to have more than 4-8 hrs of work.
• Documented quality plan, with acceptance criteria of each system, integration, and process.
• Documented release plan for how the systems will be released in production (including mitigation plans). As well as how stories map to sprints and how sprints map to releases. Finally, how each story maps to the goals in the business case.
• Documented production planning, including cut-over planning, financial translation of fixed assets, historical data migration plan, and production sanity check plan.
• Detailed migration plan, including identification of test environments of each system, how each system environment maps to another system environment, and how the finalized data and processes will be migrated to the upstream systems.

Having a good enterprise architecture plan allows you to foresee the technical issues that would otherwise not be visible with the siloed approach. 

Final Words

So, just like marriage requires comprehensive planning, the digital transformation readiness step is necessary. But the prep step is not about drawing a bunch of flow charts (like doing a bunch of chores with marriage) and writing a string of buzzwords to impress your executives; it’s almost similar to implementing an ERP on a piece of paper (being ready for marriage in your heart), which is more challenging than actually implementing it. 

Just like you would not hire interns for your ERP implementation, asking interns to run the prep phase is worse than not doing it at all. So if you don’t want any headaches in your life, make sure these deliverables are as complete before you kick off your ERP implementation.

FAQs

The first-time ERP implementation project is like getting married for the first time. Over 50% of them are likely to end up in failure. Most savvy executives who have gone through multiple implementations share that it might take up to 6 implementations – to get tangible business results from ERP projects. But, unfortunately, just like marriages, by the time they are on their 4th or 5th, they would have retired. Or they would rather not touch ERP implementations again because of the previous nightmares.

Regardless of how hard you try, you will have challenges with your first marriage (or ERP implementation). The challenges exist mostly in the misalignment of expectations, how you envisioned your life (your expectations from technology) versus your partner’s expectations of life (your ERP vendors’ expectations of your data and processes). Also, just like marriages, the issues with ERP implementations aren’t very logical or technical. Most of them are likely to be highly irrational, emotional – and, at times, strange.

There is only one way to save your first marriage (or ERP project): to marry someone who has been married at least once (hire very seasoned consultants with several years of implementation experience). Or do a ton of research before tying the knot (pre-selection phase). Most importantly, be mentally and financially prepared for the possibility of surprises. And you need to be super open-minded to be successful. So, what are the core reasons why the first ERP implementations fail?

10. Misunderstanding of Architecture. 

Architecture is like a blueprint for your house. Regardless of how small a house might be, architecture is still critical. The newer technologies and SAAS platforms are likely to mislead you into thinking that the technology is plug-and-play. Not true!

Issues:

• Thinking that Architecture is Not Important for Smaller Companies. A misunderstanding that APIs are supposed to integrate magically. Not to mention a belief that pre-baked integrations can cover any use cases.
• Ignoring the Interests of the Technical Teams Completely. Believing that technical folks can figure out any requirements thrown their way. 
• Misassumption that Technology is about Plug-and-Play. A belief that any number of SaaS apps can be meshed together to form an ERP. And an assumption that the only thing you need to integrate two or more apps is the credentials.

Recommendations:

• Don’t Ignore the Architecture. Have well-articulated business specifications, followed by technical. Also, vet pre-baked integrations with your use cases.
• Ignoring the Interests of the Technical Teams Completely. Don’t ignore the technical perspective. Additionally, pay close attention to technical teams, as not listening might result in withdrawal issues. They might code poorly to get short-term results. However, the code may not be scalable or may have downstream implications.
• Even the Plug-and-play Technologies Require an Architectural Mindset. Don’t fool yourself into thinking that “Ikea” assemblies can meet any needs. Most SMB data and processes are so ad-hoc that even the most custom furniture shop will fall short of their needs. So, streamline your business model to fit into “Ikea” assemblies or better have resources and funds for expensive “custom furniture.”

What may work for SAAS doesn’t work for ERP, and this misunderstanding is the leading reason for the failure of the first ERP implementation.

9. Internal Skillset. 

Regardless of how experienced consultants you hire, the experience of your internal team is still important. The first-time ERP implementation projects fail because going through a few cycles helps relate to the process and data re-engineering needed.

Issues:

• Team Misalignment. Teams disagreeing on the design? Data ownership? Process design? Also, disagreements on how the source of authority is supported to work. In general, the more inexperienced the team, the more misalignment.
• Lack of Experience with Similar Initiatives. No prior experience with similar initiatives? In fact, only experience as a user. Generally, only a few implementations are under their belt to be informed of the decision-making. The more limited the experience with similar initiatives, the more likely it is to fail the implementation.
• Power Struggle. Are teams not willing to give up on favorite processes or tools that might have a downstream impact? Few users too powerful and dragging the architecture in their direction? The more the power struggles, the higher the chances of failure.

Recommendations:

• Aligning Teams Require Cross-functional Visibility. Break those “walls” and increase visibility. Coach teams on cross-functional processes. So they can visualize the implications for other teams because of their decisions.
• Hire Experienced Team Members. Pair interns with experienced resources. But have experienced resources who are going to be making policy decisions.
• When Technology Falls Short, Compensation Wins. Don’t underestimate the power of compensation. When technology falls short, compensation wins. Align compensation with the right KPIs, with a tangible impact on the top and bottom lines. Trace back and identify the root cause of the barrier to hitting those KPIs.

First-time implementors are likely to have inexperienced resources, but their data and processes require a lot more work. And that is the reason why first-time ERP implementation projects fail.

8. Stakeholder Commitment. 

Most teams implementing an ERP for the first time are controlled significantly by founders. Due to the nature of how they started their business, it’s very hard for them to learn the art of delegation and collaboration, especially if they might not have as much experience working in larger corporations or teams.

Issues:

• Considering the Initiatives as IT Project. Thinking that the ERP project is all about technology. A belief that technology is the solution for any process or data-related issues.
• Not Able to Balance How Much to Get Involved. Monopolizing the conversation. Not setting the right communication framework to have a clear engagement model of when to get involved and when to back off.
• Not Able to Build Consensus Among Teams. There is not enough leadership experience to dig through details and help teams make decisions. Not enough experience going through similar projects to help teams make decisions.

Recommendations:

• Don’t Take Hand-Off Approach with Cross-functional Initiatives. Don’t execute the ERP projects in a hands-off fashion. Stay engaged, and ask clarifying questions. But don’t push, or they are likely to withdraw because of your power position. 
• Build Processes and Reporting Structure That Allow You to Have the Right Involvement. Make sure to let consultants set the framework. Save your commentary only for mission-critical issues; otherwise, listen and learn. Report, but don’t recommend it unless you are absolutely sure. 
• They Haven’t Seen it. They Can’t See It. So They Can’t Agree. Show Them to Build Consensus. Help consultants champion their ideas. Understand the underlying reasons for disconnect, propose solutions, and maybe draw visuals to help build consensus.

The first-time ERP implementation projects fail because of the founders’ lack of experience working with knowledge workers. It’s a skill set that takes a long time to master.

7. Process Re-engineering. 

90% of the smaller businesses feel that their businesses are unique, while only less than 1% when you talk to larger enterprises. The challenge is not the unique nature of their processes. But their lack of experience in standardizing their process. 

Issues:

• Not Documenting the Processes. Processes so ad-hoc that you can’t even draw them? Not enough appreciation of how documentation will help with the implementation? Not calling documentation the tangible work.
• Not Documenting the Right Amount of Details. A bunch of flow charts but not enough meaning for the technical teams to use? Leaving assumptions with processes that processes are subject to interpretation?
• Not Willing to Change Proprietary Processes. So, are you married to proprietary processes to be blindsided by them? Nonnegotiable position on the proprietary process and ignoring consultants’ position completely?

Recommendations:

• First Time Implementors Especially Struggle to Draw the Processes. Firm up the understanding of your processes by drawing them. 
• Not Enough Subject-matter Expertise to Provide the Right Details All Stakeholders Need. Hire experts with ERP implementation experience to draw the processes. Change management consultants with the same credentials as the ERP implementation teams or consultants, who can balance both perspectives of the business users, also of the technical teams.
• Analyze the Cost of Keeping Proprietary Processes and Tools in the Architecture. Build detailed functional and technical specs to analyze the cost of keeping the proprietary processes.

With limited experience seeing several organizations and their processes, first-time founders can’t differentiate when the process is broken vs. where it’s truly unique. This misunderstanding leads to ERP implementation failure.

6. Data Re-engineering. 

It takes a long time to master data modeling that drives business results from ERP systems. The incompatible datasets cause process over-engineering and customizations, leading to ERP implementation issues. 

Issues:

• No Experience with Data Modeling. No experience formalizing SKUs, BOMs, customers, and vendors compliant with the ERP dictionary.
• Not Able to Connect the Dots About Why Even Trivial Data Decisions Could Fire Back. Divisibility and modeling of the UoMs and SKUs. Using invoice objects to make decisions for warranty. Shipment line items are used as the sales order line items in the backend system. Decisions as trivial as this have the potential to kill your entire implementation.
• Not Understanding How the Source of Authority Works in Various Enterprise Datasets. No real experience with enterprise design or integration patterns? 

Recommendations:

• Take Baby Steps in Modeling Your Data. Don’t go hard on yourself if you don’t understand how the modeling would impact your core processes. Be ready to fail your first implementation. The ERP data modeling is more than 20-dimensional. It takes years to master.
• Try to Research As Much As Possible and Try to Compare Your Data Model with Other Industries. Try to visualize how other industries have modeled their SKUs and BOMs and be truly curious in probing into their model. Compare as many industries as possible and try to learn.
• Map Out the Data Flow at the Field Level Across System Boundaries. Map data at the field level. The more mapping you do, the clearer the data modeling will become.

The loose data model of systems such as QuickBooks or Excel has a tendency to promote bad data hygiene, misleading founders on data hierarchies and relationships, leading to ERP implementation issues.

5. Change Management.

Most first-time ERP implementors struggle to visualize the impact of technical decisions on the business processes, leading to ERP implementation issues.

Issues:

• Firing the Change Management Company Right After Selection. We do not understand that defining change is not the end of the change management process. It’s the start. Not appreciating the value of change management.
• Hiring the Change Management Company Without Subject Matter Expertise. I do not understand the difference between different change management consultants. Not able to vet the expertise of the change management company.
• Not Able to Make Personnel or Compensation Changes to Drive the Right Behavior. Thinking that technology is the solution to all problems. Don’t have control over personnel or compensation changes.

Recommendations:

• Change Management Requires Consistent Monitoring and Pivoting During the Implementation Phase. Have the change management company involved during the implementation phase. Hire ERP selection companies that are willing to manage the ERP implementation. Don’t hire companies that are not willing to be held accountable for the success of the implementation.
• Subject Matter Expertise Matter Even For Change Management Companies. Don’t hire change management companies specializing in other fields. Hire change management companies with related experience.
• Be Ready to Solve Issues by Making Personnel and Compensation Changes. Involve stakeholders that have the clout to make personnel or compensation changes. Don’t rely completely on technology to drive change.

Most first-time ERP implementation projects struggle with change management or in hiring the right experts, leading to implementation issues.

4. Pre-selection Phase.

The percentage of companies engaging directly with the technology vendors is much higher among the companies implementing an ERP for the first time. More seasoned companies, on the other hand, with a couple of implementations under their belt, will most certainly have a pre-selection phase, sometimes as long as a couple of years.

Issues:

• Thinking that Pre-selection is the Sunk Cost.  Underappreciating the value of the pre-selection phase. Taking a binary approach to ERP selection. Following the boilerplate checklist for the selection process.
• Not Involving Users During the Design Phase. Not building the as-is and to-be workflows and involving users during the design phase.
• Can’t Decide How Much to Invest in the Pre-selection Phase. Not able to decide the value of a selection phase. And how much discovery needs to be performed in the selection phase.

Recommendations:

• The pre-selection Phase is not Optional. Don’t shoot yourself in the foot by not having a pre-selection phase. Engaging directly with the technology vendors (OEMs or resellers) with a limited budget of less than $50K results in ERP projects not even going live. As well as a pure waste of money.
• Involve Users from Day One During the Pre-selection Phase. Make sure users agree to change the processes and have clear visibility into the cross-functional implications. Build a language that they have agreed on for as-is processes and replicate the to-be processes using the same.
• The More You Invest in the Pre-selection Phase, the Shorter would be the Implementation Phase. Have a shorter implementation phase by incorporating a pre-selection phase. Spend roughly the same but much easier transition and adoption without the risk of a failed implementation.

First-time implementors don’t appreciate the efforts involved in ERP implementation and want to take shortcuts with the discovery, leading to implementation issues.

3. Internal Selection Process

Selecting an ERP requires mapping data and process models to the new ERP, performing gap analysis, and estimating transaction volume. And not to mention saving you from legal troubles by helping you with cryptic software contracts. 

Issues:

• Hiring interns to lead the selection process. Misunderstanding that ERP selection is all about researching a bunch of web pages and copying and pasting boilerplate requirements.
• Following the traditional selection process. A belief that the traditional selection process of looking at the demos will lead to a successful ERP selection and adopted solution. 
• Trusting an ERP reseller or a freelancer for the ERP selection guidance. A misunderstanding that a reseller and freelancers can provide unbiased recommendations without preferential- or incentive bias.

Recommendations:

• Don’t risk a million-dollar disaster by letting an intern lead the selection process. Don’t waste your money with interns as the work they might do in 6 months in designing processes that a professional ERP selection consultant might finish in weeks. And save your ERP implementation.
• Don’t let the traditional selection process fool you into an ERP system that might never work for your business. Don’t trust the traditional selection process, as you are at a disadvantage because of their information parity. Hire an industry insider on your side!
• Hire a professional ERP selection consultant who is living this on a daily basis. Hire professional independent ERP consultants who can save you tons of money and get you discounts by comparing quotes and saving with unused software that you will never get from a reseller as they are losing their own commission.

The internal resources don’t have enough resources under their belt to run a selection that will lead to a successful ERP implementation.

2. Underestimating the Efforts

First-time implementors underestimate the efforts involved with an ERP implementation. They will intentionally look for shortcuts and discounts and understaff their internal resources in the hope of saving money. But they end up paying a lot more, including the risk as big as losing their investments completely.

Issues:

• Fixated on the Budget. Don’t have enough experience managing large projects. Negligent on the basic project management equation that changing budget means a reduction in scope or quality.
• Looking for Shortcuts. A misbelief that there is an easier way of doing ERP implementation projects. An attitude to ignore the warnings of consultants.
• Custom Software is the Answer to all Problems. A “binary” thinking that if ERP solutions are expensive and difficult and maybe custom-built solutions will be cheaper.

Recommendations:

• Budget Drives Quality. Try to understand the deeper implications of where the vendors are likely to cut corners if you reduce the budget. Be competitive while hiring vendors.
• Shortcuts Don’t Exist. Don’t be a kid who gets lured by candy, as there is no easy way of implementing an ERP. Be realistic to avoid a nightmare.
• Creating Custom Software is Way Harder than Documenting Your Processes. Don’t be fooled by the idea that custom software will be any easier than ERP. Try to document all your processes first, as that would be the first step in building custom software. Pat yourself on the back if you can document everything within a year.

First-time implementors have a tendency to underestimate the efforts involved with an ERP implementation, leading to ERP implementation disasters.

1. Coachability

Coachability is one of the biggest factors why first-time implementors fail their ERP implementations because of their limited experience working with consultants.

Issues:

• Not Listening to the Consultants. Being completely ignorant about consultants’ advice. Making decisions with knee-jerk reactions without understanding the implications on the business.
• Not Willing to Provide the Right Details for Consultants to Work. Unwilling to provide the details to the consultants as they assume that the consultants are supposed to feed them cooked meals as they are getting paid. 
• Not Doing the Homework Required to be Successful. Ignoring the tasks assigned and not learning during the training or testing workshops.

Recommendations:

• Be a Good Student. Let them coach you. Be patient while working with them as they try to teach you multiple languages, all at the same time. It takes time, and you are the only one who can do it.
• Not providing them with the right details will only fire them back. Understand that if you don’t provide enough details, they are likely to build something that you may not want. Know that they have nothing to lose.
• Don’t Ignore the Homework or Testing to Avoid Issues Post-implementation. Understand that ERP implementations require a lot more practice to hit the ground running from day one. Follow homework religiously if you want to avoid any issues post-implementation.

Working with knowledge workers is a skill that takes years to master. The first-time implementors struggle to understand how to work with them, facing ERP implementation issues. 

Final Words

Some people have chosen to lead their lives without getting married, given the horror stories. And it’s their choice of life. But marriage (or ERP implementation) is a test of your ability to build rapport with other teammates. Your ability to lead and grow an organization.

What is critical with these two is to understand and appreciate the process. As in life, there are no shortcuts. Your tendency to look for shortcuts will only make your journey more challenging. So, if this is your first time, try to understand the “ERP” psychology rather than complaining that ERPs (or marriages) don’t work.

FAQs

Non-profit organizations face ERP challenges distinct from inventory-centric businesses. Their diverse models, incorporating complex features such as membership types, grants, and intricate workflows, vary across verticals. Educational and healthcare non-profits, for instance, may necessitate different processes than city governments. Associations and membership communities also differ from foundations and elderly care groups.

Vanilla ERP systems lack native support for grant and fund accounting, posing a challenge for non-profits. Similar to publicly traded companies, non-profits face public reporting requirements for each grant and fund, but with a crucial distinction. While publicly traded companies report at the macro level, non-profits must segment and report based on the fund structure.

Each fund and grant often brings unique constraints, prohibiting resource sharing between competing funds or specifying usage for particular purposes, such as community or religious benefits. Compliance requirements, like The Patriot Act, may stipulate data residency, narrowing choices to US- or UK-hosted solutions. Non-profit-specific HCM and CRM packages are crucial for managing distinctive recruiting, training, and enablement workflows. However, custom development capabilities may be necessary to address unique needs within each micro-vertical of the non-profit sector, given its ever-changing business models. Curious about the leading non-profit ERP software in 2024? Let’s delve into the options.

Criteria

• Definition of a non-profit company. These are companies of any size in the non-profit ecosystem, such as cities, governments, schools, associations, foundations, charities, churches, charitable subsidiaries of large corporations, etc.
• Overall market share/# of customers. The higher the market share among non-profit companies, the higher it ranks on our list.
• Ownership/funding. The more committed the management to the product roadmap for the non-profit companies, the higher it ranks on our list.
• Quality of development. The more cloud-native capabilities, the higher it ranks on our list.
• Community/Ecosystem. The larger the community with a heavy presence from non-profit companies, the higher it ranks on our list.
• Depth of native functionality for specific industries. The deeper the publisher-owned out-of-the-box functionality, the higher it ranks on our list.
• Quality of publicly available product documentation. The poorer the product documentation, the lower it ranks on our list. 
• Non-profit company market share. The higher the focus on non-profit companies, the higher the ERP system ranks on our list.
• Ability to natively support diversified business models. The more diverse the product, the higher it ranks on our list.
• Acquisition strategy aligned with non-profit companies. The more aligned the acquisitions are with the non-profit companies, the higher it ranks on our list.
• User Reviews. The deeper the reviews from non-profit companies, the higher the score for a specific product.
• Must be an ERP product. It can’t be an edge product such as QuickBooks, Freshbooks, Xero, Zendesk, HubSpot, or Salesforce. It also can’t be an add-on owned by ISVs or VARs that sits on top of other accounting platforms.

10. Workday

Workday focuses on large non-profit organizations with substantial HCM requirements, making it an ideal choice for those already using or contemplating Workday as their HCM solution. However, it may not be the best fit for companies seeking suite-centric offerings with deep operational capabilities, particularly for managing workflows for members, students, and donors. Workday retains its position as a compelling option as a non-profit ERP, securing the #10 spot.

Strengths

• Strong HCM and CPM Capabilities. Pre-integrated and Pre-baked. Workday has one of the strongest HCM products in the market, with deep workflows for hire-to-retire, training, and talent forecasting. The CPM capabilities are also tailored for service-centric organizations.
• Non-profit Accounting and PSA Capabilities Offered Out of the Box. Expect out-of-the-box capabilities for the fund and grant accounting along with PSA capabilities. The most important capabilities required for non-profit verticals.
• Designed to Handle Enterprise Workloads. Workday has been proven with installations where the HCM and financial ledger might process millions of journal entries per hour, often a requirement for Fortune 500 accounts.

Weaknesses

• Weak Financial Capabilities. Workday’s financial capabilities might not be as robust as SAP, Oracle, or Sage Intacct as of today in the areas of ASC606 compliance, subscription-based revenue recognition, or multi-element allocations.
• Limited Install Base for the Finance Module. Most of the Workday installations are still limited to HCM and Adaptive planning. So it might not be the best fit for deeper finance capabilities.
• Might not Have Operational Capabilities for Niche Non-profit Sectors. The operational capabilities for niche non-profit sectors such as membership organizations or cities requiring integration with specific databases or CRM might be limiting.

9. FinancialForce/Certinia

FinancialForce caters to mid-to-large non-profit organizations, making it an excellent choice for those using or contemplating Salesforce as their CRM solution. However, it may not be the optimal fit for companies seeking suite-centric offerings with pre-integrated P2P and HCM capabilities. It maintains its position at #9, with a consistent ranking from the previous year, reflecting limited momentum in its portfolio as a non-profit ERP.

Strengths

• Salesforce Look and Feel. The biggest advantage of FinancialForce is the Salesforce look and feel throughout the suite. The same developers that can support Salesforce must be able to support FinancialForce as well.
• Deeply Integrated with Other Salesforce Products Such as Communities and CRM. The integration with the Salesforce offerings and the ecosystem is one of the biggest pluses for FinancialForce.
• Non-profit Accounting and PSA Capabilities Offered Out of the Box. Expect non-profit accounting capabilities and one of the strongest PSA modules with skillset-based scheduling and forecasting out of the box.

Weaknesses

• Limited Install Base. The install base for FinancialForce is significantly limiting. Not even close to other systems on this list.
• Ecosystem and Community. The community and ecosystem are not as prolific. While the Salesforce talent can support the technical needs, they would lack the business consulting and financial expertise required to be successful with the product.
• The Financial Workflows Might not be as Intuitive for Financial Leaders. The Salesforce look and feel might not be intuitive for finance leaders, who might not be comfortable seeing things such as the edit or delete button right by the posted journal entries.

8. Blackbaud

Blackbaud focuses on SMB non-profit organizations seeking suite-centric solutions. It’s perfect for those outgrowing QuickBooks and desiring suite-centric offerings with minimal expertise needed for data mapping. However, it may not be suitable for medium-to-large companies aiming to streamline operations for inorganic growth or consolidate disparate datasets. Despite its technology lagging behind in cloud adoption, Blackbaud maintains its #8 ranking as a non-profit ERP on this list.

Strengths

• Deep Operational Functionality with Tailored Capabilities for Specific Non-profit Micro-verticals. Expect capabilities such as pre-integrated and pre-configured student and teacher workflows tailored for specific micro-verticals, generally requiring significant development effort on other solutions.
• Non-profit Accounting Provided Out of the Box. While the accounting capabilities might not be as deep with ASC606 compliance or multi-element accounting, grant, and fund accounting capabilities are offered out of the box.
• Might not Require As Much Customization and Configuration as Other Larger Offerings. The data and workflows may be tailored to your micro-industry, not requiring as much consulting expertise as with other vanilla solutions.

Weaknesses

• The Reliability of the Infrastructure for Larger Workloads. Blackbaud has recently experienced an outage with its infrastructure, making it less reliable than other solutions running mission-critical and larger workloads than Blackbaud.
• Not Designed for Larger Companies with Multiple Entities. Consolidations, multi-entity accounting, and dimensional reporting might be a challenge for larger non-profits.
• Ability to Handle larger workloads. Blackbaud is great for companies outgrowing QuickBooks but may not be the best fit for companies with thousands of employees, members, etc., requiring financial control and financially integrated processes.

7. SAP S/4 HANA

SAP S/4 HANA is designed for large non-profit organizations requiring the processing of millions of transactions and the capability to host multiple countries and business models with significant collaboration. It may not be the ideal choice for companies outgrowing smaller ERP systems or QuickBooks due to the IT maturity required for implementation. If you’re a large non-profit organization or a publicly traded entity aiming to consolidate global subsidiaries in one system, SAP S/4 HANA is the perfect solution. Thus, securing the #7 position on our list of non-profit ERP systems.

Strengths

• Non-profit Accounting and PSA Capabilities Provided Out of the Box. Expect a non-profit accounting package including grant and fund reporting with a PSA tailored for non-profit-centric organizations and skill-based scheduling.
• Best of Breed Capabilities Pre-integrated. The best-of-breed software, such as Concur, SuccessFactors, and CRM, are pre-integrated with SAP S/4 HANA, a pre-baked integration with the potential to save millions of dollars.
• HANA and Financial Traceability for Large, Global Organizations. Because of the power of HANA, SAP S/4 HANA can process very complex transactions with visual traceability across entities, along with end-to-end traceability, auditability, and approvals of SOX compliance workflows.

Weaknesses

• Non-profit CRM and Membership Capabilities. It might require extensive customization or configuration to enable non-profit workflows.
• Best-of-breed Pre-built Integration Options May be Limited. The marketplace options are limited for non-profits, with the best-of-breed options requiring substantial translations to be successful with the product, driving consulting dollars and experienced internal IT resources with several ERP implementations under their belt.
• Overwhelming for Smaller Organizations. The data model is designed for large, complex organizations, overwhelming for smaller non-profit organizations, outgrowing QuickBooks, or smaller ERP systems.

6. Oracle Cloud ERP

Oracle Cloud ERP is designed to meet the needs of large non-profit organizations seeking extensive global financial capabilities. However, it may not be the optimal choice for smaller non-profits that are outgrowing compact ERP or accounting systems and require suite-centric offerings but lack substantial internal IT expertise. If you are a sizable, global non-profit organization focused on financial and procurement functionalities, along with an integrated and customizable HCM tailored for service-centric industries, Oracle Cloud ERP is the perfect solution. Thus, it holds the #6 position on our list of non-profit ERP systems.

Strengths

• Designed for Large Non-profit Organizations. The embedded HCM and CRM processes are suitable for large non-profit organizations. The P2P workflows are friendlier for the indirect procurement needs of non-profit organizations.
• Native Capabilities for Grant and Fund Accounting. Expect native capabilities for grant and fund accounting provided as part of the package with very robust budget planning tools pre-integrated and pre-populated, easily merged with external datasets.
• Embedded HCM and PSA Processes. Expect HCM and PSA to be fully immersed with the ERP, as well as grant and fund compliance processes.

Weaknesses

• Non-profit CRM and Membership Capabilities. While Oracle Cloud ERP might support the needs of membership from the perspective of finance and ASC606, the operational capabilities would require translation of data and process model, requiring expensive consulting and internal IT expertise.
• Best-of-breed Pre-built Integrated Options May be Limited. Expect substantial efforts in integrating non-profit-specific CRMs and tools, as options may be limited for specific non-profit organizations.
• Overwhelming for Smaller Organizations. The data model and translations required to be successful with the product may be too overwhelming for companies outgrowing QuickBooks or other smaller ERP systems.

5. NetSuite

NetSuite caters to SMB non-profit organizations with operations spanning multiple countries, making it an ideal choice for those with diverse business models, such as schools with campus stores or healthcare organizations with warehouses. Additionally, NetSuite can serve as an excellent tier 2 solution for non-profit subsidiaries of larger corporations. Given these strengths, NetSuite holds the #5 spot on our list of non-profit ERP systems.

Strengths

• In-built Package with Fund and Grant Accounting Capabilities Offered out of the box. Expect native capabilities for grant and fund accounting provided as part of the package with very robust budget planning tools for SMB non-profit companies pre-integrated and pre-populated, easily merged with external datasets.
• Marketplace and Ecosystem. Vibrant marketplaces and ecosystems, with tons of pre-baked integrations and add-ons available for diverse business models.
• Ideal for Global Companies Growing Through M&A. Supports several diverse and global business models out of the box, making it ideal for companies part of the private equity portfolio and growing through M&A. 

Weaknesses

• Experience Not as Intuitive for Finance Leaders. While financial auditability and multi-dimensional reporting are built as part of the system, the experience may not be as intuitive as other solutions tailored for non-profit finance users.
• Multi-entity Accounting Not as Straight Forward for Finance Leaders. While multi-entity accounting is supported by the ability to host multiple entries in hundreds of countries in one database, the multi-entity capabilities are not as intuitive for finance users.
• Unnecessary Bloatedness of the Product-centric Capabilities Not as Relevant for the Non-profit. While the product-centric capabilities could be a huge plus for large organizations, the data model may have unnecessary layers that might not be relevant for nonprofit organizations.

4. Microsoft Dynamics 365 Business Central

Microsoft Dynamics 365 Business Central is tailored for SMB non-profit organizations with specialized capabilities in grant and fund accounting, along with a PSA module designed for professional services. It’s perfect for global non-profit SMBs operating in multiple countries. However, it may not be the ideal choice for mid-to-large companies dealing with extensive journal entries and long-standing transactions. If you seek global financial capabilities and can invest in consultants for data translation, change management, and workflow customization, consider Microsoft Dynamics 365 Business Central. Given its strength, it ranks at #4 on our list of non-profit ERP systems.

Strengths

• Designed for Global Companies. Natively supports global regions and localizations. Ideal fit for countries where the other suite-centric solutions, such as Blackbaud, Unit4, or FinancialForce, might not be present.
• Non-profit Accounting and PSA Capabilities Provided Out of the Box. Expect a non-profit accounting package including grant and fund reporting with a PSA tailored for non-profit-centric organizations and skill-based scheduling.
• Marketplace and Ecosystem. Augments core capabilities with a very vibrant marketplace, supporting diverse business models such as rental, membership, or church-specific operations management software.

Weaknesses

• Financial Traceability and SOX Compliance. It might not be the most Intuitive for finance leaders. The financial traceability may not be as intuitive as SAP for global, publicly traded non-profit companies.
• Technical Focus and Limited Business Consulting Expertise in the Microsoft Ecosystem. The ecosystem has technical companies but with limited business consulting experience, which might drive over-customization and overengineering of Microsoft products, ultimately leading to implementation failure.
• Limited Microsoft Support for Smaller Partners. Unlike other ERP companies, Microsoft doesn’t offer any support or control to its smaller partners, leading to implementation issues because of the limited control over its channel.

3. Microsoft Dynamics 365 Finance & Operations

Microsoft Dynamics 365 Finance & Operations stands out as one of the most comprehensive cloud solutions, offering built-in support for various business models through its non-profit accounting package and pre-configured PSA module. It is well-suited for global non-profits operating in multiple countries. However, it may not be the best fit for smaller companies with revenue under $250 million, outgrowing QuickBooks or other compact ERP systems. Microsoft Dynamics 365 Finance & Operations is a strong non-profit ERP solution, securing the #3 spot on our list.

Strengths

• Designed for Large Organizations. Ideal for large, global companies with complex business models operating in multiple countries.
• Non-profit Accounting Package Capabilities Offered Out of the Box. Embedded non-profit accounting capabilities offered out of the box, supporting complex fund allocations, reporting, budgeting, and scheduling.
• Data Center Options and Data Locations of Choice Might be Available in Most Countries. With the backing of Azure, complying with regulations such as the Patriots act may be easier.

Weaknesses

• It may not be the best fit for publicly traded companies. The traceability requirements for publicly traded companies might not be as intuitive as the other ERP solutions designed from the CFO’s perspective.
• The CRM Might Not be the Most Friendly for Non-profit Organizations. The Microsoft CRM might not be the most fluid for non-profit organizations, with the tightness of the data model designed primarily to support product-centric organizations. Extending existing business objects would require developer support or an add-on.
• Overwhelming for Smaller Organizations. Companies under $250M in revenue or outgrowing smaller ERP or accounting systems such as QuickBooks might struggle because of the data modeling and translation expertise required.

2. Sage Intacct

Sage Intacct commands a significant market share in the non-profit sector, offering marketplaces and pre-baked integrations tailored to various micro-verticals. It excels for service-centric SMB organizations in non-profit, SaaS, healthcare, and financial services. However, it may not be the ideal choice for diverse organizations or those undergoing M&A, where evolving business models could pose challenges. Additionally, non-profit subsidiaries of large corporations may find Sage Intacct struggling to accommodate the parent entity’s diverse business model. Sage Intacct is a strong choice for specific non-profit scenarios, particularly within service-centric SMBs. Thus, securing its rank at #2 on this list of non-profit ERP systems.

Strengths

• Deep Non-profit specific last-mile capabilities. Sage Intacct has one of the strongest non-profit-centric capabilities, including fund and grants accounting, pre-populated KPIs, and reports.
• Globalized and Localized in over 120 countries. Sage Intacct can natively support multi-entity collaboration features of over 120 countries.
• Salesforce, HR, and Marketplace Integrations for the Non-profit Sector. Salesforce and payroll integrations are owned and maintained by Sage, ensuring the quality of development.

Weaknesses

• May Require Subscriptions for Best-of-breed CRMs. Primarily an accounting solution. So the solution doesn’t have any CRM capabilities at all. As well as limited supply chain capabilities, even for indirect procurement.  Non-profit and healthcare organizations needing inventory and warehouse capabilities might struggle with the solution.
• Will Require Consulting Expertise Compared to Other Smaller Systems. While Sage Intacct is designed for maximum audibility and compliance, the added layers would require consulting expertise and internal IT maturity to be successful with the product.
• Too Many Moving Pieces During Implementation. While the integration required for Brightpearl, ADP, and Salesforce is supported by Sage, there will be multiple parties involved during the implementation, with all of them pulling architecture and design decisions in their direction, increasing the implementation failure risk.

1. Unit4

Unit4 focuses on medium-to-large non-profit organizations seeking suite-centric capabilities, making it an ideal choice for large universities and schools with deep operational workflows supported out of the box. Organizations outgrowing QuickBooks or planning inorganic growth through M&A don’t find it the best fit. If you are a mid-to-large non-profit in search of a tailored, suite-centric alternative to SAP S/4 HANA or Oracle Cloud ERP, Unit4 is a great solution, claiming the #1 position on our list.

Strengths

• Strong HCM and Indirect Procurement Capabilities Pre-integrated and Pre-baked. Tailored to educational institutes and non-profits. 
• Non-profit Accounting and PSA Capabilities Offered Out of the Box. The non-profit package includes native capabilities for the fund and grant capabilities with a strong PSA module to manage resources and projects.
• Designed to Handle Global Enterprise Workloads. The unit4 solution has two versions, one for large enterprises and another for mid-market. It has been proven with one of the largest non-profit institutes looking for a tailored replacement for SAP S/4 HANA or Oracle Cloud ERP.

Weaknesses

• Legacy Solution. While the solution has been rearchitected for the cloud, it’s a legacy solution. So, the user and mobile experience might not be as great as other options born in the cloud.
• Limited Install Base in North America. Primarily a European solution with a very limited presence and ecosystem in North America. So, you might struggle to find consulting companies and marketplace add-ons focused on the North American market.
• It might be too overwhelming for smaller organizations. Due to the data translation and mapping required for the enterprises, smaller companies outgrowing Quickbooks or smaller ERP systems might find it to be overwhelming.

Final Words

Non-profit organizations have unique needs, encompassing specialized accounting requirements that accommodate the constraints of funds and grants, as well as custom workflows demanding flexibility through custom development. Stringent data privacy requirements further limit options to those compliant with specific country or state mandates.

Implementing a vanilla ERP for non-profits can be risky and costly, involving custom development and error-prone add-ons. When evaluating ERP systems, avoid being overwhelmed by generalized features. This list is designed to simplify your options for non-profit ERP systems. For success, consult with an independent ERP consultant who can offer tailored insights based on your organization’s distinct requirements.

FAQs