ERP

Searching for an ERP solution that suits your business model? If so, the first thing you would need is to understand the functional behavior of the system based on the processes you plan to host in the ERP system. As well as how it would affect your business. While each business might need a few specific modules, most would need these common ERP modules.

Not familiar with what a module is? They are a collection of transactions or functionality like AR, AP, or inventory management. Like puzzle pieces, each module does its part of the business. The most important thing to know is how these common ERP modules fit together. And which ones you would need to wire your business model.

Each ERP system might differ in functionality and contain different modules. Some ERP systems contain industry-specific capabilities, while others are likely to be slightly more generic. Some modules are also more common and often included with most ERP systems. So which are the top 10 common ERP modules with widespread application? But most importantly, would they be relevant for your business? Review the sections below to find these answers.

1. Financial Management

The financial management module is the foundation of any ERP system, and it’s essentially inseparable. In other words, if you plan to use an ERP system, you need to replace your current accounting system. Said another way, if a system doesn’t require you to replace your current accounting system, then it’s probably not an ERP. Generally, the finance module of an ERP helps with the following activities. Things like managing accounts receivable (AR), accounts payable (AP), general ledger (GL), fixed assets, taxes, and financial reports.

For some large organizations and certain business types, the financial management module might also help with financial risk management. As well as basic budgeting. However, suppose a company has more sophisticated budgeting needs such as planning, budgeting, forecasting, scenario modeling, and performance reporting. In that case, specialized financial planning & analytics (FP&A) or corporate performance management (CPM) would be a better fit.

While most ERP systems might appear alike, the key difference between large and smaller peers would be their multi-entity and globalization capabilities. If you have a global multi-entity structure with financial synergy among them, you might need a bigger ERP system. You would need a bigger system to support the localization needs of these countries. Regardless of whether you plan to utilize any other modules, you would use a finance module with an ERP.

2. Inventory Management

Primarily used with product-centric organizations, Inventory management is another core module included with ERP systems. But even service-centric organizations may require their product and services to be coded as inventory SKUs. They need this for costing and scheduling, regardless of whether they are stocked or not. Yet another example of inventory management that differs per industry would be manufacturing, which generally has one of the most complex inventory layers such as raw materials, work-in-progress (WIP), finished goods, MRO, quality control items, kanban, fixtures, or tooling. 

Maintaining inventory layers also require keeping their appropriate units depending upon their purposes, such as sales, purchase, or consumption. So if something is measured one way when it’s bought, consumed (or sold) another way – the module automatically translates that. Lastly, this module ensures that the accounting layers are in order by handling First-In-First-Out (FIFO), Last-In-First-Out (LIFO), or average costing. 

Also, if this is your first time using an ERP (and you were on an accounting system before), you may not have your inventory formalized. It’s because the accounting systems don’t require inventory to be SKUed and instead can manage with text-based line items. Without formal inventory, you might not have issues with financial reporting and taxes. But you are likely to struggle with other issues such as costing, scheduling, and inventory planning. This is why an ERP requires you to formalize your inventory, which means each inventory item needs to have an SKU and its layers. That said, the inventory module may not be relevant for your business if you plan to use ERP just for financial reporting. 

3. Project Management

The project management module in an ERP system is relevant for companies that offer professional services or engineer-to-order products. Companies use this module to manage projects for their clients or any internal project where they need integrated costing, resource management, and scheduling. 

Since there is a very thin line between a job management of an ERP and a project, some companies might struggle to understand when they might need a project management module. In general, a project is an overarching financial wrapper that can not only account for operational project management tasks but also incorporate engineering, manufacturing, or service installation. So a project may have multiple jobs. The overarching costs for the project would account for and schedule all jobs that might be part of the project.

A project generally has a different lifecycle than a job. It might have several milestones and a payment schedule. The project management functionality also incorporates change order functionality, the changes to the original expectations of the contract or scope. Any change orders generally lead to changes in milestones and the revenue recognition cycle. The larger ERP systems are likely to contain comprehensive project management functionality, including keeping track of all invoices generated per milestone and revenue recognition cycles. But most importantly, the project management module would help you with the micro-profitability analysis. As well as consolidated scheduling, combining the demand for resources from all projects. 

4. Cost Management

The cost management module in an ERP system helps track costs across all business processes regardless of the industry or business model. While pricing depends upon costing, and most people collate them together, the scope of the cost management module doesn’t include pricing. They generally have very different lifecycles and structures and are often part of different modules of ERP systems.

For product-centric businesses, this module allows capturing different materials, labor, and overhead costs across all cost categories, such as fixed, variable, or burden. The material costs may include any costs related to manufacturing or procurement depending upon the sourcing strategy of that material. The procurement costs would include accounting layers such as FIFO, LIFO, or average, given the accounting standards, and would account for all costs, including custom, brokerage, duties, or whatever you include as part of your procurement costs. Regardless of whether the costs are likely to be direct or through a sub-contract arrangement, the costing module would help compute the total costs of your offerings.

Even for service-centric businesses, this module is crucial. Their human resources costs are likely to be higher based on their skill sets. This module tracks this across all categories, such as salary, benefits, overhead, etc., for each process that consumes human resources. The cost management functionality of different ERPs might vary based on their size. Smaller ERP systems and ones for service-focused businesses might have fewer layers of costs they track. But the bigger ERP systems provide detailed information about all the operational costs. More layers generally lead to more granular traceability and detailed analysis that companies need to plan and manage their costs. 

5. Procurement Management

The procurement management module in an ERP system is helpful in managing the execution aspect of the procurement function, whether they offer services or products. When companies require advanced procurement capabilities such as Amazon-like catalog management, guided buying, or vendor network, they might not be part of this module and instead need an advanced system such as P2P.

For product-centric companies, the procurement process is generally intertwined with their production process, as the production function is dependent upon procurement and the timely availability of materials. This module handles the entire procure-to-pay process, including purchase order (PO) management, PO matching, RFP, and RFQ management. On the other hand, service-centric companies have their procurement processes embedded with their project workflows. 

6. Service Management

The service management module in an ERP system caters to various service-centric needs. This is important for businesses that provide services along with their products, post-sale service inquiries, or pure-play field service organizations.

Depending on the design and size of the ERP system, the features included in this module might differ. For companies that offer services along with their products, this module might consist of capabilities for processing service orders, service scheduling, service inventory management, technician scheduling, and field service management. For companies offering post-sale services, this module can also handle incidents, cases, after-market serial number management, etc. The customer service module might also include the workflow of a call center or customer support work.

As far as the functionality of this module goes, there is generally an overlap between an ERP and other systems, such as CRM, OMS, or eCommerce. But the overlap is likely to be limited to the customer service side of things and not to the operational and financial aspects of service management. Regardless of whether you host this process in one system or multiple systems, if you need to measure and track the costs and centrally manage your resources, you might require a service management module of an ERP.

7. Customer Relationship Management

The customer relationship management(CRM) among common ERP modules manages different parts of the customer journey. Inside this module, you can find capabilities such as sales funnel management, marketing spend management, territory management, commission management, quoting, estimation, etc.

However, suppose your business needs more advanced features for managing your pre-sales processes, such as social media management, marketing channel attribution analysis, content management, marketing automation, etc. In that case, you might need a specialized CRM designed just for that. The CRM module in an ERP system usually focuses on operational and financial business processes, the processes that generally touch the workflow of other departments. And not the siloed processes that don’t require operational and financial collaboration with other departments.

Regardless of whether you use a specialized CRM in your architecture or not, you might still need a CRM module of an ERP unless you don’t plan to host your customers inside your ERP and use it primarily for financial reporting. Also, generally, most ERP systems are designed for B2B customers because of their structure. And since they are not the most efficient for B2C customers, you might use a specialized system such as POS or an eCommerce depending upon the channel. Based on the architecture and business processes, the need for a CRM module might vary.

8. Manufacturing Management

The manufacturing management module inside an ERP system is helpful for manufacturing industries or industries that might have similar workflows as manufacturing. This module helps manage several things, such as bills of materials, manufacturing requirements planning (MRP), advanced planning and scheduling (APS), mixed-mode manufacturing processes management, and preventive maintenance of assets.

However, suppose your manufacturing needs are more advanced, like machine integration, statistical process control, operational data collection, or edge device communication. In that case, you might need specialized software focused on these tasks. This kind of operational technology software is called MES, which stands for Manufacturing Execution System.

The manufacturing module is perhaps the most misunderstood module. In some cases, companies feel that ERP systems are generally relevant for either manufacturing companies or manufacturing processes. In other cases, they just overgeneralize manufacturing and feel that everything can be a manufacturing process, including construction or software development. While the intent of the manufacturing module of an ERP is generally operational or financial in nature. Basically, anything and everything that is manufacturing-like operations, like event management, might use the manufacturing module of an ERP.

9. Warehouse and Logistics Management

The warehouse and logistics module in an ERP system helps companies manage their storage and moving of goods through processes such as pick, pack, and ship, warehouse, and location management. 

Advanced ERP systems have even richer capabilities. These capabilities can help manage wave and batch management, carts and tote handling, cycle counting, data collection using barcode scanners, paperless and direct picking, container loading and unloading, license plate and ASN management, and global trade management. But if your business needs more specialized capabilities, like ASRS or AGV integration, slotting, 3PL capabilities, supply chain control tower, etc., you might need a specialized WMS, TMS, or a supply chain suite.

Traditionally, the boundaries of ERP and WMS systems were separate, with ERPs being primarily responsible for keeping the inventory counts while WMS was for location management. Also, some industries that were primarily designed for distribution or retail always required a specialized WMS system, so the warehouse and logistics management module of these systems was leaner or virtually negligent. In some industries, the warehouse architecture might be so different that using a warehouse module included as part of the ERP might not make sense. The newer breed of ERP systems, especially the ones that target SMB companies, generally package some basic warehouse capabilities to allow companies to manage their warehouses and logistics functions without requiring expensive integration and IT capabilities. Depending upon whether you plan to use a specialized WMS or TMS system in your architecture or not, the usage and features required as part of your warehouse module might vary.

10. Quality Management

The quality management module in an ERP manages the execution workflows of quality teams. Most companies with similar operations as manufacturing will likely require quality processes embedded with any external touch points such as procurement, returns, or production. Inside this module, you can find capabilities for different aspects of quality control, such as supplier, in-process, and RMA quality management.

This module supports features such as material review boards, quality inspections, quality certifications, and corrective action workflows if something doesn’t meet the expected quality. It also manages non-conformances and tracks how they are resolved. The presence of quality management processes can vary in different ERP systems. Some ERP systems come with these quality processes built-in, while others might not have them at all. It all depends on how the ERP system is designed.

Companies that are quality-heavy are likely to require reporting capabilities with their quality module. While the quality management module might support features such as document management or version control, it might not support operational capabilities such as documentation templates, redlining of documents, or document collaboration. For these capabilities, a quality add-on is generally a better fit. The quality module is useful for companies where quality processes are likely to impact the financial and operational workflow and is tightly embedded with the operational processes. That’s why some companies might host their quality processes externally and might not use this module.

Final Words

As you are starting the ERP journey, understanding how these common ERP modules differ is the first step to start with your selection process. While reviewing different systems, these modules are likely to appear very similar. But they each are very different and require careful review.

Once you have a good grasp of their scope, their usage might differ based on your business model and needs. So before concluding which modules you need, make sure you have a good understanding of their scope and capabilities, and hopefully, this list could provide a good foundation to start your journey.

FAQs

Regardless of how cutting-edge ERP technology might be, your current enterprise data is a major driver of operational efficiency. The efficiency that you will gain (or lose, equally likely) using your newly implemented ERP system. Understanding ERP data re-engineering issues requires mastery of cross-disciplinary processes, information modeling, and multi-system expertise. But most importantly, enterprise alignment of different processes across system boundaries. The unfortunate part about ERP data re-engineering is that even seasoned consultants struggle with it.

The biggest disconnect always is understanding the difference between data and UI/system flows as they are generally intertwined. Also, ERP data re-engineering issues are extremely challenging as they might disrupt legacy processes and transactions. So, unfortunately, no clean slate. Instead, the only option is to find a middle ground, which drives overengineering of your processes and architecture.

The ERP data re-engineering issues also make implementing ERPs for each business incredibly unique due to their differences. In other words, two exactly similar businesses and operations might yield very different ERP outcomes because of their current ERP data differences. Your data issues might be even more severe if you lived on a poorly architected system (home-grown or commercial) that substantially deviated from the enterprise software data dictionary. That’s probably the reason why moving from QuickBooks or Mainframe to an ERP is more challenging than between two standard ERP packages. The only way to cure them is to have a rollout strategy, requiring careful planning and enterprise-level control (and governance) over several years. The following candidates are the most common culprits, requiring ERP data re-engineering.

10. Work Orders/Projects

Common Issues

• Separate work orders for each routing step. The inability of legacy systems to handle long-standing transactions required segmenting into multiple work orders. But companies still carry them as part of their information model.
• Not combining all steps of a  project within it. Adjusting service or engineering costs through GL entries than incorporating them as part of the project workflow. This leads to biased total costs of projects and products/services. 
• Not implementing co- and by-products using out-of-the-box workflows. Two issues why companies struggle with them: 1) capabilities not supported with their existing ERP system. 2) Not fully understanding the intricacies of how to implement them properly.

Risks

• Misleading total costs of projects, services, and products. The disconnected information model and cost layers lead to misleading total costs.
• Overengineering of downstream workflows. Companies need to overengineer their downstream processes to resolve issues caused by these over-engineered datasets.
• Increased admin efforts to connect each work order to get consolidated insights. Connecting these individual cost drivers requires substantial admin efforts to keep track of micro profitability and costs.

Solution

• Understand the out-of-the-box data model deeply before implementing it. Don’t rush to implement. Spend time to understand the intricacies of out-of-the-box data models.
• Re-engineer your data model first before implementing it. Re-engineer as much as you can. Do it at the enterprise level, involving every function and not siloed approach.
• Vet the data model of ERP systems before buying them. Compare the data model of newer systems before selecting them. Buy only systems that closely follow enterprise software data dictionaries.

9. Inventory Allocation

Common Issues

• Different allocation states in different systems. Companies that struggle with organizational alignment often end up keeping the allocation algorithm in multiple systems, often leading to frequent departmental confrontations.
• Warehouses and channels don’t have their own inventory for allocation and reconciliation to work. Without a formal strategy for warehouses, locations, and channels, companies often end up mixing them, throwing off the allocation equation.
• Ad-hoc cycle counting processes. Ad-hoc cycle counting processes lead to inventory discrepancies, misbalancing the allocation equation.
• No formal allocation strategy or governance process. Without a formal allocation strategy and governance, the allocation equation very rarely balances for companies, causing substantial inventory issues.

Risks

• Customer experience issues. Examples such as customers not being able to place orders or not having the right amount of inventory when they require it.
• On-time delivery issues. Allocation issues lead to not being able to reserve inventory for the right customer at the right time, leading to on-time delivery issues.
• Fire fighting among departments. Not uncommon for departments to steal inventory or have physical blocking (and not keeping a record of inventory inside the system). 
• Substantial inventory planning problems. Even minor discrepancies can lead to substantial consolidated planning issues.

Solution

• Map SKUs per channel and have a dedicated inventory pool per channel. Not only maintain the SKUs per channel but also keep an accurate account of inventory per channel.
• Design enterprise allocation flows. The allocation flows are not possible unless all departments agree on a centralized allocation strategy across enterprise boundaries.
• Implement formal cycle counting processes for each inventory pool and ensure that physical and digital inventory remain close and not too far off.

8. ECN Workflows

Common Issues

• No formal ECN processes. Companies struggle to implement formal ECN processes as that requires aligning product models and a streamlined change process.
• Allowing changes throughout the process without a formal governance plan. This is especially prevalent in industries where a formal product may not exist, such as construction, sign manufacturing, or custom machinery. Their processes are different from product-centric industries, and they believe that the ECN processes might not work for them.
• No formally defined product model, making implementing ECN workflows incredibly challenging.

Risks

• Downstream issues with costing and scheduling. The shortcuts taken for the ECN process will lead to overengineered downstream processes, leading to costing and scheduling challenges.
• Issues with SKU number maintenance. ECN issues might lead to having multiple SKUs for each change or product model not connected, driving substantial part maintenance issues.
• Misleading insights.  Not accounting for the costs of changes appropriately will lead to misleading insights. 

Solution

• Define the product model. Even if you might feel that you don’t have one. The foundation of ECN relies on a streamlined product model.
• Formalize ECN processes. Build ECN workflows and build consensus with all stakeholders involved throughout the ECN process to ensure compliance.
• Re-engineer legacy processes because of poorly implemented ECN controls. Re-engineer any legacy over-bloated processes due to the poor implementation of ECN prior to implementing a new ERP.

7. BOMs and Revision Numbers

Common Issues

• Revision numbers not utilized. Separate SKUs for each revision. This is a major issue with companies when they might not have a formalized process for maintaining revisions.
• Return implemented as a routing step. This is common with companies that may not have had return capabilities baked as part of their legacy system and had to take a shortcut to implement it. But these companies still carry them as part of their information model.
• Mixing of different hours limits the traceability of different activities. Companies on legacy systems that didn’t support reporting of hours individually or took shortcuts because of the perceived increased effort generally struggle with the traceability of different activities and their cost implications.

Risks

• Costing and scheduling issues with BOMs. The issues with the underlying structure of BOMs and revisions generally lead to substantial costing and scheduling issues. 
• Unreliable insights produced despite substantial admin effort reconciling various data silos.

Solution

• Implement BOMs and revision process using the out-of-the-box functionality. Understand the intricacies of out-of-the-box capabilities of BOMs and revision numbers and implement them without hijacking any existing workflows.
• Re-engineer BOMs and revision numbers as much as possible before implementing a new ERP system. Don’t implement them as is. Analyze BOMs and revision numbers and assess if re-engineering them might be possible without disrupting the support for legacy processes and transactions.
• Reduce manual intervention for BOM data entry. The more manual intervention you have in the process, the more data quality issues you are going to have. So replace the entry of BOM and revisions using CAD add-on if possible.

6. Chart of Accounts

Common Issues

• Too verbose. The companies outgrowing accounting or smaller ERP systems generally tend to have flatter structures for charts of accounts due to their limited number of hierarchies and layers. 
• Chart of accounts barely mapped with lean hierarchies. The legacy systems might support the mapping of a chart of accounts, but the hierarchies may be leaner, limiting the traceability.
• Reconciling through GL entries. Companies outgrowing smaller systems have a tendency to reconcile account balances using GL entries.

Risks

• Maintenance issues. The verbose chart of accounts would increase the admin efforts in maintaining the flatter hierarchy and reconciling them.
• Challenging to get insights from ERPs. Getting insights may not be possible with the flatter hierarchy as the underlying layers may not be enough for the required traceability.
• Significant financial control issues. The practice of updating GL balances directly may cause substantial financial control issues because of the limited traceability of the original transactions. GL entries should be limited to non-operational ad-hoc transactions and definitely not to reconcile operational accounts.

Solution

• Model chart of accounts after the system-provided chart of accounts. ERP charts of accounts are different from accounting software, and they need to be re-engineered and mapped in appropriate hierarchies to get desired insights.
• Utilize ERP hierarchies than making them verbose. Follow ERP hierarchies as much as possible. Bypassing them may cause traceability issues.
• Avoid direct GL entries for operational transitions. Avoid GL entries for operational accounts as much as possible, especially accounts that might be harder to reconcile, such as inventory or channels.

5. Customer/Vendor Master

Common Issues

• Customer/vendor master model mixed with another master data business object. Companies end up mixing the master data models, such as implementing 3-tier hierarchies of the customer master using a dropdown on a product maintenance screen. 
• Inconsistent modeling of child and parent business objects. Mixing child objects with parents, such as implementing ShipTos as customers or vice versa.
• Three-tiered hierarchies are not maintained in the system. 3-tier hierarchies, such as buying groups or holding companies, require implementing them using out-of-the-box capabilities. Instead, they take shortcuts such as making them 2-tier and then overengineering processes to get insights.
• Retail customers modeled as orders. Making decisions such as bundling all retail transactions under one customer account causes substantial performance and maintenance issues.

Risks

• Slowed customer service. Overly bloated business objects cause performance issues, increasing the total time required to serve customers.
• Overengineered workflows. Overengineered workflows may require further over-engineering to overcome the shortcomings of underlying workflows.
• Scalability issues. Without understanding the implications of mixing technologies, issues such as using EDI for integrating internal customer channels may lead to scalability issues of codes, causing issues with onboarding new customers.

Solution

• Maintain the natural hierarchy of business objects. Don’t deviate from the real-world hierarchy of the customers and re-engineer it if possible to align with the selected ERP system.
• Have a master data governance plan in place. Implement master data governance plan and implement them using workflow technologies if possible to reduce the number of variations with inputs touching customer master.
• Limit the creation of customers/vendors to power users. Limit the number of users adding records impacting master data.

4. Sub-accounts

Common Issues

• Implementing too many unnecessary sub-accounts. Companies with a limited understanding of sub-accounts might end up using too many of them, adding unnecessary steps with each transaction.
• Not modeling the right dimensions with the sub-accounts to get the desired traceability. Not implementing sub-accounts where they are fit leads to uncontrolled growth of chart of accounts or overengineered processes.
• Implementing sub-accounts as a chart of accounts. Implementing sub-accounts as the chart of accounts causes charts to be too verbose.

Risks

• Slowed processes because of unnecessary data entry at each step. The unnecessary work just to enter data required for sub-accounts may increase additional steps with each process and may slow down operations.
• Lost traceability. Not modeling sub-accounts where they would be appropriate would lead to the lost traceability of transactions.
• Bloated chart of accounts.  The verbose chart of accounts causes sustainability issues in the long term.

Solution

• Thoroughly analyze sub-accounts. Think  10x before deciding to implement sub-accounts. They can break your entire implementation and are much harder to reverse.
• Don’t implement too many sub-accounts if they are not really part of the operational workflow. Unless absolutely required by operational workflows, don’t implement them.
• Implement sub-accounts in the FP&A software if possible. The FP&A software provides much more flexibility in adding more dimensions without disrupting operational workflow.

3. Serial/Lot Numbers

Common Issues

• Using project numbers or dates as serial numbers. Companies often mimic serial or lot numbers using random numbers such as project# or dates and then would be required to build the entire workflow to support serial or lot number processing that would have been available out-of-the-box with the system.
• Mixing of serial or lot numbers. Companies that don’t fully understand the lot and serial numbers end up mixing the schemes, causing traceability issues and increased admin efforts.
• Not implementing lot numbers appropriately. Some companies that may not fully appreciate the out-of-the-box lot control functionality end up hijacking processes and overengineering workflows.

Risks

• Traceability issues with serial and lot numbers. The biggest implication would be traceability as you build workflows that are dependent upon serial and lot numbers.
• Hijacked processes lead to further over-engineering. The ERP processes are so interdependent and intertwined that once you hijack one process, the dependent processes would start breaking and would require further hijacking.

Solution

• Use the serial numbers model as provided by the system. Understand the workflow fully. Buy a system that has serial number capabilities aligned with your processes.
• Don’t hijack out-of-the-box workflows to accommodate broken processes. Stop the urge to hijack processes. Instead, invest effort in understanding the intricacies of the out-of-the-box processes.

2. UoMs

Common Issues

• UoMs don’t mimic the natural hierarchy of data. Companies that don’t use a natural hierarchy compliant with sales, purchase, and production processes often struggle with substantial planning or operational issues. An example, such as implementing a product that is generally sold in rolls as EA would cause downstream issues.
• UoMs modeled as dropdown options or form fields as opposed to coding at the SKU level. Companies that don’t fully understand the difference between the data and UI flows end up implementing UoM issues as dropdown values.
• Purchase, production, or consumption UoMs not modeled appropriately. Companies that don’t fully understand the implications end up opting out from modeling each of these categories, causing issues with the downstream processes.

Risks with

• Over-customization of workflows to fix the issues caused by data. Unnecessary hierarchies of data often drive substantial overengineering of downstream processes and operational inefficiencies.
• Business performance issues such as MRP etc. Not following the natural hierarchies of UoM will lead to requiring substantial admin efforts with MRP suggestions before they are meaningful for business operations. It also leads to lost trust in system data.

Solution

• Follow the natural hierarchy of UoMs. Follow the natural hierarchies of UoM. Trace every single transaction and vendor and identify the UoMs on how materials are being sold, procured, or consumed.
• Fix UoM issues first before implementing a new system. Re-engineer UoMs prior to selecting and implementing a new system. Not aligning UoMs will lead to substantial planning issues even with the new system.

1. SKU Numbers 

Common Issues

• Flat SKU numbers without hierarchy. Modeling revision numbers as SKUs. Implementing each UoM as individual SKUs. Flattening the variable or dimensional inventory. These are examples of where companies flatten their inventory.
• Too much intelligence built into SKU numbers. Companies on legacy SKUs that they can’t retire might have substantial intelligence built as part of the numbers or in the description, which leads to scalability and maintenance issues.
• Mixing of automated and manual numbering schemes. Inconsistent numbering scheme. Using an outside number generator to generate SKUs without native controls built up might lead to maintenance issues with inventory.

Risks

• Difficulty in extracting SKU-level insights. The intelligence built as part of SKUs or flattening them might make extracting SKU-level insights challenging and would require substantial admin efforts to reconcile each SKU-parts to extract insights.
• Challenging to plan at the SKU level. The planning cycle assumes getting reliable data at the SKU level. Poor modeling of SKUs poses challenges in extracting reliable data at the SKU level, which is the foundation of most planning cycles done at the SKU level.
• Misleading business decisions. Flattening of SKUs and the inventory model being all over the place lead to misleading business decisions.

Solution

• Don’t build too much intelligence with SKUs. Be especially careful with any intelligence embedded as part of the SKUs or descriptions. 
• Use the automated numbering scheme. The one that is natively built with the system.
• Clean the SKUs before implementing a new system. Try to re-engineer the SKUs as much as possible before implementing a new system. And if ERP data re-engineering is not possible, try to come up with a rollout plan.

Final Words

Unfortunately, there is no way to get rid of ERP data re-engineering issues due to the need to support legacy processes and transactions. But not re-engineering them prior to implementing an ERP can lead to overengineered processes and overly bloated systems, sometimes leading to overall operational efficiency loss despite your investments.

So if you are thinking of replacing a new ERP, invest some time thinking through how you plan to re-engineer your current data. You also need to find a system (or combination of systems) that’s closer to your current information model. But don’t stop there, as ERP data re-engineering would require a roll-out plan spanning over years if you want to be even closer to getting rid of all of your ERP data issues. 

FAQs

Who wants to deal with an ERP selection RFP? Literally no one. They are boring, dry, and unnecessary. Everyone is generally super frustrated with them. Because of this issue, some companies choose not to compete in opportunities requiring an RFP. The customers are equally afraid of writing one because of the fear of not getting traction from ERP vendors. But the problem is not necessary with the RFP process. It’s how companies write them. Not understanding their true intent and not realizing that the ERP vendors are running businesses as well. A process that they might perceive as unfair or unnecessarily difficult will make it challenging to drive their interest.

The intent of an RFP must be to document details that might require weeks or months for vendors to comprehend. Capturing it into an organized document helps them understand the need and assess if their solution would be fit or not. Write them to reinforce details covered during the demo. Because with systems as complex as ERP, most attendees are likely to retain only 10% of the demo, missing out on critical details. Reinforcing through the written process helps ERP buyers and vendors avoid missing critical details, which might be vital for the success of an ERP project.

The more experienced the writer is in relationship-oriented roles, especially in sales and negotiations, the higher the quality of RFPs. Generally, writers with little exposure to customer-facing roles such as finance or IT are likely to make it overly difficult. These components will help you structure your ERP RFP with the right amount of details.

10. Selection Process

Its Importance

• Communicating the seriousness of the project. Believe it or not, ERP vendors are super selective about deals unless it’s a VAR or a smaller vendor. They might not want to complete the deal if they perceive that you are not serious. Setting expectations about the selection process helps avoid unnecessary churn and disinterest.

Common Mistakes

• Not spelling out the ERP selection process. Not including the right amount of details that vendors would need to get approval at their end. As well as to assess that this would be the right opportunity for them.
• Not agreeing on the steps of the process. Companies considering ERP selections in the DIY mode might not formalize the process and may take forever to decide, disengaging credible ERP vendors.

Details That Matter

• Steps of the ERP selection process. Details such as how many phases would be part of the process. How you will make decisions. Who will advance, and who will not? What will be the decision criteria, and who will be the decision-makers? Communicating steps of the ERP selection process not only helps in aligning expectations but also in managing scheduling and ensuring that key resources are available to support the ERP selection process.
• Dates and timelines of key activities. Do you have a defined timeline for ERP selection? How about dates for the activities, such as ERP selection or demo? Including dates and timelines helps set the expectations that you have a structured process and you are not going to take forever to decide, giving the credible vendors the confidence they would need to engage with you.

9. Proposal Evaluation Criteria and Delivery Instructions

Its Importance

• To communicate that the process will be fair. Communicating fairness is critical to encourage vendors to have their best shot. Without this, getting sufficient details to evaluate a solution would be a challenge.
• To convey that RFP is not just a formality. Vendors disengage as soon as they feel that ERP selection RFP is just a formality and may be written to favor a specific vendor.
• To let the vendors evaluate if they are the right fit for this opportunity. Provide proposal evaluation criteria to help them assess their fit. They are likely to be more honest at the beginning of the process if they have not invested as much time in the opportunity.

Common Mistakes

• Making the process overly complex. Making the evaluation process overly complex might discourage vendors who might be an ideal fit for your business.
• Coming across as wasting ERP vendors’ time. They might not choose to compete If you come across as wasting their time, even if they might feel that their product might be a fit.
• Making the process unnecessarily difficult, like only accepting mail. Overly difficult processes miscommunicate that you might be difficult to work with, and they might disengage.

Details That Matter

• Detailed evaluation process. Specifics about the evaluation process, such as elimination rules and variables of decisions about how ERP vendors will advance at each round. 
• Clear delivery instructions such as point contact and how they can reach the contact person if they might have any questions.

8. Current Team and Org Chart

Its Importance

• To communicate that the right decision-makers are involved. Including information about the team and their titles help vendors understand the process has been thought through and that you are serious about the ERP project.
• To let them research the team members involved and tailor the communication to their needs. Details about team members help them research team members’ backgrounds and tailor communication to their needs and make it relatable for users.

Common Mistakes

• Being overly secretive about the team members. Regardless of the reasons why you might not choose to communicate about the team involved, being secretive will raise doubts about your seriousness.
• Not communicating their roles and responsibilities and alignment with the project. Including team members is important, but what is even more critical is communicating their project roles. Details such as their responsibility for specific business processes or their decision-making authority for specific functions or processes.

Details That Matter

• Names and the titles of the team members involved. Allowing them to research their background to help tailor communication.
• Their role in the project. It helps them create role-play stories and tailor demo scripts.
• Expected during the demo. Including who is expected during the demo will help not waste time in creating stories and scenarios from the perspective of users who are likely, not present during the ERP demo.

7. General Guidelines

Its Importance

• To communicate any general expectations not related to the project, such as vendors’ financial standing or legal proceedings
• Communicating overall expectations from the relationship. They help in communicating any regulatory constraints and overall expectations that might not be directly related to the ERP project.

Common Mistakes

• Being overly verbose with rules that might frighten ERP vendors. The companies that either use boilerplate RFPs or just copied and pasted text might discourage savvy vendors who might be a potential fit for your business.
• Including boilerplate rules that might not be relevant to the project. Including boilerplate rules not directly related to the project is likely to cast doubts on your seriousness with the project.

Details That Matter

• General rules such as highlighting add-ons, white-label products, and integrations. Details such as add-ons vs. white-label products help clear up the ownership if there might be any third-party components used to power the entire solution. As well as any other overall expectations not specific to the project.
• The cost of the RFPs. Include details, such as proof of concepts if they are likely to be paid.
• Any legal obligations. Any legal obligations, such as pending judgment against the vendor, and if that might be a factor in deciding against a vendor. Legal details such as copyright or NDA.

6. Business Goals

Its Importance

• To communicate overarching project objectives. Spell out what you are trying to accomplish, be specific.
• To let vendors help in assessing the feasibility of the to-be state. Without this, challenging would be if their solution is a fit.
• To connect the dots with other components of the ERP Selection RFP. How other sections relate to each other.

Common Mistakes

• Not including business goals. Without business goals, they might struggle to evaluate if their solution would be fit or not and unknowingly overcommit.
• Being too vague with goals. Generic goals are likely to mislead as they might misinterpret them differently than how you intended them to be.

Details That Matter

• What are you trying to get from this project? Details such as overall objectives from the project and any specific KPIs that you might be thinking of hitting.
• Expectations for your goals. Sets clear expectations on your priorities so there is no confusion in how they interpret them in their heads vs. what you want.

5. Business Challenges 

Its Importance

• To communicate the overall drivers. The challenges help them understand what’s driving the project and if the solution is going to be a good fit or not.
• To help them connect the dots about your needs. The business challenges help connect the dots about the critical success factors and key needs outlined.

Common Mistakes

• Not including the challenges. Not including the challenges is likely to communicate a biased perspective,  missing out on crucial details required to evaluate a solution.
• Being too vague with challenges. Be as specific as possible to avoid misinterpretation.

Details That Matter

• What challenges are the trigger for the project? Specific details such as drivers and triggers for the project.

4. Future State

Its Importance

• To connect the dots on what might not be relevant from the as-is state. The future state is important to understand the rollout plan for legacy processes and transactions and if they need to treat legacy processes as requirements in the new model and architecture.

Common Mistakes

• Including the wishlist might confuse them more than it could help. The wishlists, which are not specific, may be assumed as needs, putting the entire ERP project at risk.
• Not identifying the future state. Missing the future state assumes the broken as-is needs as requirements.

Details That Matter

• Specific details about the future state. What’s going to be relevant in the to-be state? What’s going to be changed? Include the rationale for what’s being included and what’s not.

3. Current State

Its Importance

• To help them understand the complete story. The current state of the business is important for them to understand the as-is state if they might drive any issues with the future architecture. 
• To help them assess if their solution is a fit. The as-is details will help them assess if their solution would be a fit or not. Without the as-is state, it’s hard to assess if there might be any required customizations, especially why legacy processes can’t be streamlined and aligned with out-of-the-box capabilities.

Common Mistake

• Intentionally hiding the critical details for fear of miscommunication. The ERP buyers often choose to hide details that, they feel, might confuse the ERP vendors.
• Missing critical details of the current state. Not documenting the current state with the right specificity will lead them to assume details that might not be intended.

Details That Matter

• Specific current processes. Details about current processes, such as how they are done right now and what was the rationale behind doing it this way.
• The rationale for any changes. The rationale why the processes would need to be changed.

2. Current and Future Systems

Its Importance

• To communicate how many systems are involved in the architecture. Depending on how many systems are involved and their role, the scope of the new system might vary.
• To communicate the need for integration and process boundaries. The systems would help understand the integration and process boundaries of the new system.

Common Mistakes

• Only including a few systems. Companies tend to ignore systems that they feel might not be relevant, only to learn later their importance for architectural feasibility.
• Including systems that might not be relevant to the project. Not having a clear understanding of which systems to include might lead to over-communicating systems that might be completely irrelevant, confusing the ERP vendors.
• Not including versions and specific product names etc. Not including specific details such as product name and version numbers might lead to vendors making assumptions, leading to a biased system selection.

Details That Matter

• Name of the products and their versions. Include the name of specific products and their versions.
• How the products are being used in the current architecture. Describe their role in their current architecture, including their integration flows with other systems in the architecture.
• How they are expected to be used in future architecture. What would their role be in the new architecture, including any integration needs?

1. Critical Success Factors

Its Importance

• To avoid brush-offs during demos. Including the critical success factors and asking vendors to respond as part of an RFP can help where vendors might brush off if they might be weaker with those capabilities.
• To stay focused on factors that are likely to make or break the implementation. 
• What’s most important for selection and that the system will be a good fit? The critical success factors help communicate the factors most critical for selection and implementation.

Common Mistakes

• Including factors that might not be as critical. ERP buyers not savvy with requirements analysis with limited knowledge of the ERP industry include critical success factors that might not be as critical.
• Being too vague with critical success factors. Identifying specific critical success factors requires deep ERP implementation expertise that most companies don’t understand and end up choosing that is too generic, giving ERP vendors a leeway to brush off capabilities where they are likely to be weaker.

Details That Matter

• Critical success factors. The factors that make or break implementation are likely to influence the budget and timelines of the project.
• The questions related to the critical success factors. Which questions are you seeking answers related to these critical factors? These questions will provide the context of why these factors are critical for you.
• Whether the critical success factor is a show-stopper or not. Some systems may require workarounds as their capabilities might not be fully hashed out around these success factors. So they might not choose to compete. Identifying show-stoppers would help give them confidence that they have a shot at winning this opportunity.

Final Words

Treat the RFP process with the true intent, which should be to make the selection process easy and convenient, and not difficult. Avoid boilerplate details as much as possible. Write it because it will help teams consume the same information through multiple channels several times, making sure that most critical success factors have been hammered thoroughly. Also, document because it will align the expectations of both parties.

Including an RFP with the selection process will help reinforce and ensure not to miss out on critical details while creating a fair and comfortable process for all ERP vendors involved. But make you hit on these components to provide a convenient experience for all vendors so they feel that you are the kind of customer they would go out of their way to help.

FAQs

Where do you draw the line between the ERP selection process and implementation? It’s a tricky question. Because of this, various schools of thought exist: does it make sense to invest in process documentation? When to clean your data? Let me give an easy answer: it depends. Easy, wasn’t it?

Opinions differ primarily because of varying expertise among ERP selection vendors. Also, what exactly is ERP selection? Is it just meeting a bunch of functional requirements the way you would buy shampoo? Or would the selection process be as involved as the engineering phase of a large aircraft? Some ERP vendors without implementation expertise argue against a thorough selection process. They emphasize project and change management as the keys to success. Although there is no consensus on the lines of change management, one thing is clear: if you don’t re-engineer your data and processes, the new ERP is just a lipstick on a pig. So whether you perform process and data re-engineering during the selection or implementation phase, it’s a vital step in the ERP selection process.

The other challenge with the ERP selection process is even trickier. A challenge that the entire ERP industry faces, primarily because it’s chicken and egg. And that is, you can’t be confident in design and architecture until you’ve selected a system. But once you choose, you’re locked into a contract and constrained by that system’s boundaries. Also, investing too much in the selection process might kill the project even before it starts. Understanding these ERP selection steps will help structure your project based on your needs.

1. Project Initiation

Project Charter. The components of a project charter include identifying a specific project vision and objectives and as-is and to-be KPIs. But most importantly, a budget/timeline that you can use as a measuring stick throughout the ERP project. A common mistake organizations make is not writing down the project charter. Or not being specific enough that it ends up collecting dust on a shelf. But why do organizations struggle with this? Well, it requires mastering critical reasoning skills to craft compelling objectives and choose the right KPIs. 

Stakeholder Matrix. The stakeholder matrix is perhaps the second most critical item of the ERP selection process. It identifies the different stakeholders involved, their hierarchies, the escalation matrix, and how decisions will be made. Not having clear accountability and people’s names printed against decisions generally result in each decision taking forever. Or the most authoritative figures simply highjacking processes without fully understanding the implications. Here are other elements that are equally critical: Identify the core team, a steering committee, and a communication plan.

Discovery Workshops. Let’s face it. 40% of the processes inside an organization are just tribal knowledge. The role of discovery workshops is to uncover trial knowledge through a series of demos. Also, don’t believe everything that users report. Verify and validate it through multiple sources. Gather as much data as possible, dig into the systems, and analyze data hierarchies. And use a process mining tool if you are a large, complex enterprise. Embrace your inner detective and leave no blood drop untraced. 

2. Requirements Workshops

Requirement Matrix Draft. Once you wrap up the discovery phase, you’ll have hundreds of requirements for each division. You’ll know which systems currently hold them and which ones will in the future. This information is crucial for shaping your enterprise architecture and interaction workflows. However, many functional ERP selections overlook this step, assuming that ERP is a solution to all problems. Don’t fall into that trap—and host the requirements where they make sense and where they would be compliant with architectural and master data governance guidelines.

Requirements Workshops. The purpose of these workshops is to go over each requirement and make sure that the team understands the as-is and to-be state. The team must also agree on the process boundaries and critical success factors. These workshops act as a second validation to catch any missed requirements from the discovery phase. Successful workshops will uncover important details that can impact the selection and enterprise architecture.  But don’t forget to build consensus on critical success factors, as well as a priority for each requirement.

The Critical Success Factors. Critical success factors are the key needs that can make or break an implementation. They are the ones you must prioritize during the demo. However, many companies get caught up in non-critical details like how a system processes a sales order or the availability of an Outlook add-on. While important, these details may not be the critical success factors. Here’s a rule of thumb: just as having too much sugar is bad for you, having more than ten critical success factors missing can lead to overlooked critical details and implementation issues. 

3. Business Process Re-engineering Workshops

Process Visualization. Unless your users implement ERP for a living, their expectations of a system are likely to be vague, with risky financial and technical assumptions. It’s similar to buying a house and agreeing on a specific color without understanding if the chosen shade of color will fit the context. To align expectations, you need iterative exercises of visual models designed to refine your understanding of as-is and to-be states without locking in a contract. 

Process Re-engineering Maps. This step restructures your process in compliance with enterprise software or ERP dictionary in a vendor-agnostic manner. While the ideal outcome would be a clean state aligned with the ERP dictionary, it might not always be possible. Because the legacy processes might be required in the new architecture to support legacy transactions. So perform a careful analysis of which processes can be restructured. As well as how that would impact information models and enterprise architecture and what would require a rollout plan so you can follow an iterative approach to phase out legacy transactions and processes.

Balancing of Perspectives with Maps. While re-engineering is helpful to avoid expensive overengineering and customizations, it may not fully satisfy every stakeholder unless the maps are translated from their unique perspectives. Users and technical teams have different needs. So, it’s important to create two versions of the maps: one tailored to the users’ perspective and another focused on implementation. While the internal team can handle the as-is version, creating effective to-be and implementation-centric maps requires specialized expertise. Drawing maps may seem simple, but it’s far from it. It takes years of experience with ERP implementations to create truly impactful maps.

4. Data Re-engineering Workshops 

Data Re-engineering. Understanding how data hierarchies impact the process and system decisions is perhaps the hardest part. In general, data is not easy to re-engineer. Maintaining the state of master data over a period of time is equally difficult, even for the most disciplined organizations. Also, once the master data is printed on labels or communicated to external parties, refactoring and communicating why it’s needed becomes extremely challenging. So you might not be able to start with a clean state, but you need to re-engineer as much as possible.

Master Data Governance. Master data governance is not just a system concept. It requires defining organizational workflows across system and process boundaries. Things such as where master data gets generated, who maintains it, and how it is augmented across enterprise boundaries. As part of this step, build the source of authority matrix for each dataset. Examples of datasets would be the dependencies embedded with the main master data objects such as customer, master, items, and chart of accounts. But don’t forget to build the governance processes, such as what is a customer vs. what is a parent account? How to set up various master datasets such as charts of accounts and customer classes etc.

Reconciliation Workflows. The reconciliation workflows analyze the transactional data and how it will be reconciled across system boundaries. Analyze every GL reconciliation scenario and perform the root cause analysis to understand if the current GL reconciliation might be a symptom of weaker reconciliation upstream. Your goal should be to analyze the source of the variance both in the as-is and to-be state. Reconciliations workflows will help make decisions about process and system boundaries. 

5. Enterprise Architecture Development

User/Department and System Workflow Mapping. Think of these flows as very similar to process maps, but rather than mapping process boundaries per department and function, you are overlaying the system layer per user and role. As well as how each department would be interacting with systems. You not only identify the primary systems that every user, role, or department would use, but you would also identify the second and third systems for the root cause analysis and reconciliation. While you are defining the system view, it is only done at the category level and not necessarily from the perspective of specific technology or vendor. 

High-Level Design. The high-level design is the business view of enterprise architecture. Its role is to define the roles and responsibilities of each component and major messages exchanged among systems. The high-level view does not account for technical concerns, such as how every technical error will be handled. This helps technical teams understand the business outcome from their perspective. 

Detailed Design. The detailed design specs are prepared by the technical teams in response to high-level design. The detailed design identifies most technical exceptions and workflows and major pseudo code to identify the test cases and stories. As well as the integration messages in the format the systems would consume. The detailed design helps align the business and technical teams on the expectations of business outcomes. The detailed design also identifies any proof of concepts that need to be done to remove any technical or financial risks.

6. RFP Development

Write RFP. The challenge with vendor-agnostic architecture is that it might feel like shooting in the dark without a frame of reference. And sometimes, RFP development may occur before the detailed design is fully hashed out. Also, whether you plan to include an RFP as part of your ERP selection process or not, writing it saves time as you don’t have to repeat details with every vendor. The RFP contains sections such as as-is and to-be state, current and future systems, business channels and goals, but most importantly, critical success factors. 

Design Evaluation Framework. The evaluation framework is a quantitative framework that helps shorten the long list of systems and create a short list of vendors and solutions identified to vet through the selection phase. The evaluation framework also identifies weights for each critical success factor and decision criteria that the teams can understand and use to evaluate different systems and vendors. The sooner you get agreement on the evaluation framework prior to the demo, the less confused your team members are likely to be. The evaluation framework will be updated throughout the ERP selection process and will be the foundation for vendor scorecards. 

Evaluate Written Responses. While some people disagree with the need for written responses, they can help reinforce findings or discover additional questions that may not have surfaced during the initial phase. It also helps teams understand the layout of different systems prior to looking at demos. The written responses would also allow you to vet your critical success factors thoroughly or change them as you learn more about vendors’ capabilities.

7. Vendor Demonstrations

Demo Scripts. This step focuses on designing scripts that vendors use to structure their demos. Most vendors will try to focus on the strong aspect of the system, brushing off critical features where they might be weak, ending on a positive vibe. Demo scripts help you stay organized and focus on the factors that matter most for your implementation.

Brief Vendors. Vendors are likely to have millions of questions just to prepare the ERP demos. Sometimes, you might want to do this prior to the written responses, while other times, it might be right before the demos. But briefing vendors is a crucial step. They need to understand enough about your business for them to be able to prepare the demo in a way that would resonate with the users who might not understand how different ERP systems compare.

Organize Demos. This step focuses on organizing demos with each of the vendors. Some ERP vendors might be open to onsite demos, while other vendors might prefer a virtual option. In general, your goal should be to organize demos in 2-4 hrs windows. If you keep the demo duration longer than this, the users might struggle with their attention span. If you keep it short, the vendors might not appreciate it as they may not be able to describe the capabilities in detail. You might require several rounds of demos depending upon the comfort level of the team with different systems. The first round is likely to be more of a high-level understanding of the system. The next round of demos is likely to be around specific critical success factors or roles.

8. Vendor Score Cards and  Fit Gap Analysis

Update Vendor Scorecards. After each round of demos, you might need to create vendor scorecards, which are likely to have a very similar structure to the evaluation framework. The vendor scorecards help keep track of things and maintain their ongoing ranking. Not having access to vendor scorecards will lead to teams being confused and might end up choosing a system that might not be the best fit. The vendor scorecards also help neutralize the biased powerful voices that are likely to hijack decisions in their direction, misleading the ERP selection processes and resulting in technical and financial risks in the implementation phase.

Perform Fit-gap Analysis. The fit gap analysis goes hand in hand with analyzing customization and data migration efforts required with each solution set. This step compares as-is processes and data with each solution and identifies gaps that would require more than just simple configurations and testing in the system. Depending upon the sequencing need, this step might run parallel to the detailed step or may be sequenced before or after. This step is essentially flavored for each potential solution and is a brief risk assessment for each solution considered. The ERP implementation phase will merge the detailed design and the finalized solution from this phase and build on top of it.

9.  SOW and Contract Negotiation

User License Access and Cost Analysis. This step maps out all users (or user groups) and their access requirements across different solutions considered. It will also dig deeper into the enterprise architecture and user-system mapping matrix to map appropriate access rights for each user profile. The user license access then needs to be aligned to each solution type to identify any licensing risks which might result in overages or toll charges after signing the contract. If not analyzed thoroughly, these charges may end up eating savings gained through negotiations. The licensing needs also need to be analyzed for any API or system-related access rights.

TCO and ROI Analysis. This step builds out a cost schedule for each solution considered over a pre-determined time horizon. By accounting for all cost elements, including internal and external costs, this step will help plan the budget for the entire initiative throughout the project. This step will also identify potential cash flows expected over the period of time based on the synergies and efficiencies expected over a period of time. The financial analysis helps executives gain confidence in the initiative and help plan the cash flow over a period of time.

Contract Analysis and Negotiation. The goal of this step is to analyze any financial and legal risks buried in the contracts. By combining insights from enterprise architecture and user access rights, this step analyzes issues such as storage, bandwidth, data migration, vendor conflicts, and vendor support. After identifying major risks with contracts, a negotiation strategy is developed with each vendor. Based on vendors’ counter strategy, revisions might be required with the overall plan before finalizing a vendor and awarding the contract.

10. Implementation Planning

User Stories and Sprint Planning. This step plans the implementation phase in how different sprints will be structured and sequenced depending upon the configuration, customization, and integration required. It expands on the requirements captured in the requirements matrix and develops acceptance criteria that are used to create a quality plan and testing strategy. The sprint planning is also aligned with other change and program management deliverables that need to be planned together to avoid any cost overruns.

Quality Assurance Plan and Test Cases. The quality assurance plan develops the test strategy aligned with each testing step, such as unit and integration testing, as well as UAT. It also develops a compliance framework to ensure accountability from each user and department. Aligning the acceptance criteria identified with user stories, the quality plan is used throughout the implementation phase to avoid surprises post-implementation because of untested code and scenarios.

Implementation Readiness Prep. This step is used to finalize the risk management plan, resource planning, current system refactoring plan, data migration strategy, and change management plan, along with how each will impact the critical path. The goal of this step is to track all dependencies that need to be captured as part of the project plan to avoid any financial and schedule surprises.

Final Words

Most companies struggle with the decision of whether to invest in a selection phase. But deciding how much to invest and how to structure your selection phase could be an even more difficult decision. 

So if you are planning for your ERP project, make sure to include these phases as part of your ERP project. Don’t wait for that day when the lines between the selection and implementation phase would become clearer. That may never happen due to the nature of the beast. 

FAQs

Understanding why ERP selection matters requires alignment on the output of the process, but what’s the output? Right software? Consensus among teams? Sweet discount? ERP selection deliverables? But watch out, even success can be tricky. What if your initial success might fall on its face? What if your implementation teams shred the initial recommendations? And what if users or customers don’t buy into critical assumptions made during the selection phase? All Investments might go down the drain. Ouch! 

Once you understand these ERP selection deliverables, comparing ERP selection vendors is generally much easier. Some vendors might not even understand their importance and might argue against them. But they argue because of their skillset, claiming this responsibility is to be of tech vendors. Holding tech vendors accountable for these deliverables is like hiring two parties who speak two completely different languages, and none of them have the capabilities to translate confidently without losing something in translation. They not only need to deliver them but with the right depth that technical teams feel comfortable taking over.

Without consensus on ERP selection deliverables, building a business case for the project might be equally harder. How do you estimate the costs of something if you haven’t defined what it is that you are estimating? Even movers need to know the details of the shipment to estimate the costs. ERP implementation is like moving the whole city. Too many variables. And this is where these deliverables can not only help vet the qualified ERP selection vendors. But they can set the tone of the project to be successful with it.

1.  Project and Implementation Charter

The role of the project charter is to list the key objectives and KPIs that are going to set the tone of the project. It also outlines the scope, budget, and timeline expectations at the 30K foot level. The goal of the implementation charter is generally a similar document but primarily for the implementation phase, which would be written at the end of the selection phase.

Why it’s important

• Without it, it’s very hard to build a consensus. Aligning teams requires a set of guidelines that they can refer to in case of conflict.
• Hard to stay on track. The guardrails help them stay on track.
• Hard to measure success. Measuring success require clearly defined objectives.

Common issues

• Objectives are not specific enough. Test your objectives with SMART criteria. S = specific, M = measurable, A = achievable, R = realistic, and T = timely.
• KPIs are not measurable. KPIs need to be specific and measurable. 
• Does not evolve over time. Project charters are meant to be ongoing documents that need to be updated as constraints change in the project.
• Doesn’t capture the budget, timeline, and scope. No budget or timeline expectations can lead to researching ideas that might not be worth exploring and may result in sunk costs.

How to do it right? 

• Follow SMART criteria. Following the SMART framework will help you identify objectives and KPIs that will serve as the guardrails for the project.
• Don’t let it dust on the shelves. Go back to it when you have a conflict within the team and evolve if it is already outdated.

Project and implementation charter documents set the tone for the project. They are essential to build consensus and resolve conflicts.

2. Stakeholder Matrix

The stakeholder matrix helps define the roles and responsibilities and sets the right expectations with teams and stakeholders when conflict arise. It also defines the escalation path when things go awry.

Why it’s important

• Who is going to be making decisions and when. Identifies the responsibilities of each stakeholder with a RACI matrix.
• How many different subsidiaries be aligned, and who is the point contact? Defines the relationships between different subsidiaries and entities and their interaction model.
• What is the escalation hierarchy if things don’t go well? Identifies the escalation matrix in how escalations will be handled.

Common issues 

• Not involving the right teams and decision-makers in the process. Not involving the users in the process who might not buy into the decisions made by stakeholders identified in this matrix.
• Not defining the RACI chart for everyone. RACI chart sets the right expectations with everyone and holds them accountable for decisions.
• Not defining the definition of RACI. Communicating the roles of RACI and explaining their roles is equally critical.

How to do it right? 

• Define the definition of RACI. Even if the stakeholders might feel that they might not be qualified to make decisions. Asking them to make their own decisions will drive their commitments and engagements to the project.
• Not identifying the right roles for everyone. Expecting executives to make all the decisions or executives micromanaging.
• Not communicating their roles and responsibilities so they are clear with expectations. As much is critical to define the responsibilities as is communicating the expectations.

The stakeholder matrix is like an org chart for ERP projects. It defines everyone’s roles and responsibilities and sets clear expectations, especially in resolving conflicts.

3. Requirements Matrix/Business Requirements Document

The role of the requirements matrix is to serve as an inventory of requirements, provide critical success factors, and help with system boundaries.

Why it’s important

• Inventory of the requirements in one place. This helps us quickly analyze requirements in the as-is and to-be state in one place.
• In setting the boundaries for each system. Setting boundaries for each system is critical. Without them, despite not being optimum, most companies end up assuming that ERP is the default choice.
• Identifying the right critical success factors. Not understanding which critical success factors would be critical for ERP selection may lead to false positives and negatives.

Common issues

• Not identifying the right critical success factors. Most companies end up focusing on generalized factors such as “superior user experience” or “tighter security” while ignoring the other factors that are likely to make or break implementation.
• Not defining system boundaries. The inability to define system boundaries generally leads to integration and reconciliation issues in later phases.
• Not following SMART criteria for the requirements. The requirements that don’t pass the SMART framework often carry substantial technical and financial risks, misleading the ERP selection and implementation process.

How to do it right? 

• Follow SMART criteria for capturing the requirements. Learning to be efficient with the SMART framework requires deeper expertise and years of experience.
• Don’t identify more than ten critical success factors. Focusing on more than ten critical success factors will lead to not sufficient attention to some critical success factors.

Before diving into the ERP sea, equip yourself with a requirements matrix, one of the most critical ERP selection deliverables. Sail towards success by identifying those critical success factors to steer your selection process right!

4. Business Process Re-engineering Maps

Despite the requirement matrix being detailed with clear demarcation of system boundaries, the users would still struggle to visualize their workflows. And this is where process re-engineering maps help.

Why it’s important

• Refines understanding of technical teams with as-is processes. The as-is workflows are easiest for them to understand and visualize. Drawing them helps develop a language that is easier to follow with to-be workflows. 
• Helps business users understand workflow changes and identify potential adoption risks. 
• Helps simplify processes that are going to have embedded technical and financial risks. Not simplifying the processes would lead to overengineering of newer systems, leading to adoption risks.

Common issues. 

• Not identifying the persona and developing them for each stakeholder involved. Not developing process maps from each stakeholder’s perspective may lead to lost confidence in process documentation.
• Having too much boilerplate with process maps. Having too much boilerplate might be harder to follow for business users.
• Not aligning with the enterprise software process model. Companies doing it in the DIY mode struggle to align with the enterprise software data model.

How to do it right? 

• Build at least two sets of maps, one for the technical teams and one for each user persona. The user maps are likely to be more detailed than the technical maps required for implementation.
• Build standards for process documentation. Develop and communicate the language of how to read those maps. Otherwise, users might feel motivated to use them.
• Have ERP data and process model expertise for process documentation. Hire experts with this expertise than trying in DIY mode.

Don’t forget to build the process re-engineering maps. They help uncover issues that may still be buried even with the requirements matrix.

5. Data Re-engineering Maps and Reconciliation Workflows

Data drives overengineered processes, and that, in turn, drives bloated systems. It helps unwire intertwined changes, promotes the governance processes, and helps build reconciliation flows that are likely to lead to increased admin efforts through overcomplicated reconciliation flows to cover up for simplified front-end processes.

Why it’s important

• Data drives processes, and processes drive systems. Analyze master data and figure out if that is aligned with the enterprise software data dictionary. And if not, simplify it.
• Analyzes admin efforts with new architecture or system. Without doing this, you might end up increasing admin efforts with processes.
• Sets the tone for master data governance. These changes are foundational to defining the master data workflows.

Common issues

• Data gets no attention. Most companies struggle to understand how data may drive process and system issues. 
• Data is left for technical teams. Data is very rarely analyzed during the selection issues, finding surprises in the downstream processes.
• Reconciliation flows not analyzed. Companies often make decisions based on gut feeling, leading to reconciliation and integration issues.

How to do it right? 

• Build as-is and to-be data models and align them with process models. 
• Analyze reconciliation efforts with each technical decision. Each technical decision is likely to result in a changed reconciliation workflow, so analyze them.
• Define augmentation journies of each data set. When different systems are involved, understand the augmentation journeys of each system, which one owns the data, and which ones update it.

Data, processes, and systems are connected to hips. And data is that wheel that moves them together. So don’t forget to oil your data if you want your processes and systems to work for your business.

6. Organizational Change Management Deliverables

Each change item identified might have an impact on the physical processes, which could drive the overall costs, making it harder to justify the value of digital initiatives. This is where organizational change management deliverables come to the rescue, helping you understand financial risks and adoption challenges.

Why it’s important

• Identifies the impact on the physical processes because of digital efforts. Comprehensive analysis of financial risks. This will help understand the total cost of initiatives.
• Avoid losing investments in initiatives with adoption risks. The lack of adoption may lead to losing investment completely.

Common issues

• Change items not formally documented. Companies that don’t understand the importance of change management struggle to formally capture the changes.
• The cost of changes is not analyzed completely. Tracking change management items but not accounting for their costs in the decision-making of digital initiatives.
• The timeline of changes is not aligned with all the changes. Not aligning project plans of change items may lead to scheduling and budget issues with digital initiatives.

How to do it right? 

• Build a project plan for each change item. And align it with the digital plan.
• Perform TCO analysis of each change item comprehensively. The total cost must include the cost of each change, including its implications.
• Don’t build or sign contracts without getting buy-in on each change item. Signing software contracts without understanding the cost of each change might eat up cost savings procured through software contracts.

The change items have their own lifecycles and require analyzing costs in conjunction with digital initiatives. So make sure you are not treating them as training items that generally get attention at the last minute.

7. Transformation Roadmap and Business Case

The roadmap would dig into one of the initiatives based on the business case and takes a much deeper dive of the agreed solution. And if the main path may turn out to be more expensive than originally planned, alternate plans may be explored.

Why it’s important

• Helps create a comprehensive business case for each solution. Before ignoring any solution, understand their business case.
• Helps avoid financial and technical risks with the approaches. The business case would avoid the financial and technical risks embedded with each solution.

Common issues

• Roadmap does not include the cost of change management. Not including the cost of change management might lead to a biased financial analysis.
• Changes are not communicated with the stakeholders who might influence the adoption of change. Not communicating changes with the stakeholders might lead to adoption risks and financial surprises in the downstream processes.
• Business cases assume too many technical risks. Not enough due diligence of the business case might include financial and technical risks, leading to biased decision-making.

How to do it right? 

• Assess the transformation roadmap comprehensively. Don’t leave any stones unturned with the roadmap.
• Due diligence to remove technical risks. Perform enough due diligence to understand the risks before implementation or signing contracts.
• Involve users whose influence may lead to adoption or financial risks. Don’t ignore users who might influence the change.

The transformation roadmap and business case help select the right solution that is most technically feasible and with the least financial risks.

8. Enterprise Architecture and Master Data Governance Plan

Once a solution is selected based on the business case, the enterprise architecture and master data steps help in digging into the solution further and building technical specs in agreement with the technical teams.

Why it’s important

• Defines the roles and responsibilities of each system. Technical analysis with roles and responsibilities is equally important as business analysis.
• Defines their interaction flows. The interaction flow helps in understanding how each system would communicate and the data they will share among themselves.
• Defines the master data governance flows across the system boundaries. Just like reconciliation flow is from a business perspective, master data governance flow is from a technical perspective and is equally important.

Common issues

• Typically delayed for the implementation phase. Companies not as savvy with technical skills believe that managing master data is the technical teams’ responsibility.
• Not detailed enough to be meaningful for the technical teams. Companies with limited implementation and technical background might not be detailed enough for it to be meaningful for technical teams.
• Misalignment between technical and business perspectives. The technical teams might not have enough business background, and the business might not have enough technical background, leading to misalignment.

How to do it right? 

• Do it in the prep phase. Doing it in the prep phase will help you uncover technical and financial risks commonly responsible for going over budget with digital transformation projects.
• Get agreement from technical teams. Involve technical teams during the selection phase and get their buy-in on the solution.
• Define master data governance flows from the technical perspective. And don’t wait for the implementation phase to do that.

Enterprise architecture and master data governance analysis must be done in the prep to uncover technical and financial risks, generally discovered during an implementation phase.

9. Solution Matrix, Vendor RFP, and Demo Scripts

The role of the solution matrix, vendor RFP, and demo scripts is to provide a framework for the selection process. Without a framework, most solutions might appear similar and confusing.

Why it’s important

• Reduces the amount of time with vendor briefings. Documenting details helps reduce time with vendor and team briefings.
• Provides a quantitative framework to select the right system. Having access to a quantitative framework leads to teams being confident with a solution and owning it. 
• Provides structure for vendor demos and streamlines the selection process. Creates a fair process for vendors and sets the right expectations on the critical success factors. 

Common issues

• Writing too much boilerplate with RFPs. Companies that write too much boilerplate with RFPs run the risk of frightening seasoned vendors as they are likely to be sensitive to their time.
• Not identifying the right critical success factors to compare solutions, which would generally mislead the selection process.
• Demo scenarios are not captured with the right depth. The superficial demo scenarios generally lead to vendors brushing off the critical ones.

How to do it right? 

• Have the right balance of detail with the RFP. The RFP needs to have the right level of detail for vendors to find it credible.
• Get buy-in on the framework. The team needs to agree on the framework for how you plan to evaluate different solutions.
• Align expectations of the demo with each party. Align team members to the demo script, or the most vocal team members are likely to hijack the demo. 

Make sure you have a framework for your ERP selection, including these ERP selection deliverables, but don’t forget to align your teams on the framework for it to be effective.

10. Contract Analysis and Vendor Score Cards

The role of contract analysis is to identify the red flags with the contract based on the agreed architecture and solution, whereas the purpose of vendor scorecards is to rank each vendor based on the learnings during the demo.

Why it’s important

• Uncovers hidden risks embedded with contracts. Identify risks such as overage charges, storage and bandwidth limits, tier structure, and user license limitations.
• Aligns implementation with licensing. Helps remove any financial surprises because of misalignment in the licensing and implementation plan.
• Provides a framework to compare vendors. To have an unbiased comparison.

Common issues

• Not hiring software contract experts for analysis. Mastering contracts takes years and requires deeper expertise in architecture and legal.
• Not creating a framework to compare vendors. Without having a framework to compare vendors, the team might make decisions based on superficial factors.
• Signing contracts before understanding fine lines. Signing a contract without understanding the fine lines might eat up all your discounts.

How to do it right? 

• Understand contract variables and how they impact the TCO. And not just at the surface level.
• Align licensing with the implementation plan. The licensing access must be compliant with the implementation plan or expect financial risks in the later phases. 

Don’t underestimate the expertise required to interpret software contracts. Without it, you might be sitting on financial and legal risks that will fire back in ways you might not expect.

Final Words

Not defining deliverables for your ERP selection is like running without a finish line. And that’s probably the reason why companies struggle to understand the importance of the ERP selection phase. Once you set the expectations on ERP selection deliverables, the ERP selection phase will make a lot more sense. 

It will also help your executives understand why it exists and why they should be investing in it. But most importantly, ERP selection isn’t just about reading brochures and making life hard for implementation companies!

FAQs

ERP selection biases run rampant, even evading the experts’ radar unless they follow a quantitative framework. But beware, even frameworks can mislead without deep subject matter expertise and an intimate familiarity with “political forces.” What’s worse? They nudge you to feel confident in your decisions, only to face disappointment in the business results later.

So, are all ERP selection biases created equal? Kickbacks take the crown as the most common bias, often highlighted by “unbiased” ERP consultants. Also, just because you hired an “unbiased” consultant, it does mean that they won’t have their own set of biases. They all do, and they all are equally dangerous. Sneaky, right? But hold on tight; there’s more! ERP selection biases like solution, preference, skillset, or prestige lurk in the shadows, masked as positivity, nudging you astray.

These ERP selection biases aren’t just minor headaches; they’re the top culprits behind digital transformation failures. They lead to selecting ill-fitting software and over-customization that sabotages the expected marathon post-live. They cloud executives’ judgment to a point where even genuine consultants struggle to deliver results. Fear not! Reviewing the following list will help clear the fog and spot warning signs in your ERP selection journey.

10. Bigger-the-better

Bigger is not better. This bias assumes that large ERP systems can handle any level of complexity, smaller operations or larger. ERP sales reps swear you’ll never outgrow those big systems. But hold on a sec! Those mammoth systems, while comprehensive, can bring unnecessary complexity to mid-market organizations. Cue change management headaches and adoption struggles.

Several versions exist. ERP sales reps have a sneaky plan to boost their deal size: push those larger ERP systems! They know most people select based on functional checklists, so they aim for high scores on those lists. It’s like a game of ERP sales strategy—bigger is better, right? Well, not always! Don’t get caught in their bias trap, my friend. When evaluating ERP systems, ditch the “bigger is better” lens. 

The bias is not just with ERP sales reps. Defining the “to-be” state is a struggle for most organizations. They harbor wild growth assumptions like the Cannabis industry expecting overnight riches or dreaming of hitting a billion in revenue within three years. But here’s the truth bomb: Growth doesn’t work that way. ERP systems aren’t magic wands with infinite elasticity. Companies opting for oversized systems hoping for infinite flexibility end up growing slower. Bloated processes without the operational synergies of a larger organization become roadblocks. In the world of ERP systems, bigger isn’t better. 

The consultants are at fault too. Most consultants specializing in one ecosystem, such as SAP, Oracle, or Microsoft, have a tendency to default to bigger solutions when smaller solutions may be short of those features. This assumption overlooks other add-ons with the current solution than defaulting to the larger solution. Their tunnel vision in one ecosystem fuels the “bigger is better ” among top ERP selection biases.

9. Brand Bias

No one ever got fired for selecting SAP or Microsoft. Just like the “Bigger-the-better” bias, this bias is just to select the most popular brand. Two implementations, even on the same product, are likely to be different. So just because you were not fired in the last job for selecting this publisher, it does not mean that the ERP publisher would work for the current business as well. This bias mistakenly puts its money on more-popular-the-better.

ERP sales pitch wrapped in a shiny package called the “ERP publisher.” ERP selection biases such as this, sales reps focus on the credibility of the publisher than focusing on the specific capabilities and their efficiencies for the current business model and transactions. An example would be 90% of the Fortune 500 use SAP; Oracle has run the world for the last 40 years; or NetSuite has over 40K installations – what could go wrong with it? Literally, everything, in ways you won’t expect. 

Not all products will be equally fit within ERP Publishers’ portfolio. Just because Infor M3 is a fit for your business doesn’t mean that Infor LN would be equally fit as well. This bias focuses on the publisher than on the capabilities and alignment of specific products.

Not all products will get the same attention from the ERP publishers. This bias assumes that all products in an ERP publisher’s portfolio get the same amount of attention. That’s not true at all. Focus on the product and look for the roadmap of the product as opposed to focusing on details from the ERP publisher.

8. Industry Bias

My competitor/industry uses this ERP software, so I should too. All of our competitors and the industry use this software, and they have had no problems with it. While following your competitors could be a great strategy, it might fire back too. What if your transactions and business model are different from theirs? If so, the ERP that worked for them might not work for you.

My competitor/industry uses this ERP software, so I should NOT. We can’t use the same software as our competitors; otherwise, what will be our differentiator? Let’s face it: the ERP itself is not your differentiator; it’s how you are going to implement it. Most ERP systems can support millions of business model variations. So by ignoring software just because your competitors use it, you are likely to have ERP selection biases in your approach.

I have never heard of this software in my industry. Let’s face it. Unless you practice in the ERP industry for a living, you might not know all the solutions out there. Also, just because you have not heard about it doesn’t mean it might not be a potential fit. 

I have heard of failures of this software in my industry, so I would rather stay away. There are millions of reasons why an ERP implementation might fail. So ignoring it just because it failed for other companies may not be the wisest idea. What if it failed because they didn’t invest in change management or their data was a complete train wreck?

7. Knowledge bias

The team knows a solution(s). Let’s not worry about anything else. Don’t select solutions based purely on teams’ familiarity. For example, the team might be comfortable with Microsoft. What if Microsoft does not fit the current business model and transactions?

I don’t know any other solutions that could work for this business, so what choice do we have? Don’t pigeonhole yourself on some requirements. It could be proof of delivery or scheduling with a specific machine. Finding an ERP purely from the lenses of a few requirements might not be the best idea. Do they even belong to an ERP? What if these requirements might be better suited for add-ons? 

Consultants select solutions based on their expertise on a solution. Hiring consultants with limited solution familiarity can result in biased selections. Review their background and affiliations, but best of all, their content strategy: Can they discuss each solution with equal depth? Or do they seem biased toward a few solutions? 

Executives have used a solution in their previous company; what could go wrong with their stamp? Ah, the executives and their pre-meditated success stories! The more they stick to a few solutions, the cloudier their judgment becomes. Their bias grows stronger, fueled by their own triumphs and maybe a touch of ego.

Let’s pick one value stream, like O2C or P2P, to show “value.” ERP selection biases such as this are very common among lean or six sigma consultants just because they are coached to think in terms of value streams. While this could work great with physical processes, it’s a receipt for disaster for system architecture and master data governance. 

6. Budget Bias

I only have this much budget; what choice do I have? If your pockets are tight, skip the ERP. It’s a budget-buster, often blowing expectations by 2-3 times, even if you follow the rulebook. Hold off until you can afford the whole package: the right system, implementation, and change management.

I have no shortage of budget, so why should I not buy the largest solution? Well, just because you can afford a solution doesn’t mean that it’s the best fit. Affordability should not be the only factor in finding a solution. Instead, cut down your urge to find the largest solution and invest more in solution selection, implementation, training, and change management.

I only have a budget to afford the software, so the only choice is DIY mode. Limited budget for implementation? Not ready for a real ERP. DIY mode risks lost investments and business disruptions.

I want the best deal, with as many features as possible. Don’t get caught up in the race for features and discounts! It can blind you to the lurking financial risks in ERP projects. Remember, it’s not a rat race of features. 

I don’t have a budget to afford the license fee; we have to build it ourselves. Don’t fall into the trap of thinking you can build your own “drill” when you can’t afford one. Let’s be real: building something from scratch has never been cheaper, and it never will be. We rely on mass production for everything we consume. Software production follows the same principle.

5. Prestige Bias

What would our customers think if we used anything less than SAP? While a great addition, choosing an ERP just to strengthen your pitch is a disaster waiting to happen. Let your choice be driven by what truly suits your needs, not just for the sales pitch.

How will I get the next job if I don’t have SAP printed on my resume? Sure, you can brag in your next job only if the current implementation is successful and the other company might care for a brand as much as you do. Building your resume is a good strategy, but not while choosing ERPs.

We have always been a Microsoft shop. What would people think if we changed? Sure, picking a political candidate based on how you see yourself might be OK. But unfortunately, implementing ERP is not a branding competition.

I have always dreamed of going to those SAP wild parties. Not settling for anything less. You will only be able to go to the parties if the implementation is successful. Remember, you might never be settled if you used wild parties as a factor for selection.

4. Preferential Bias

I have always been successful with Epicor; let’s go with Epicor. Just because you have been successful with a product in the past, it does not mean you will be successful with it again. What if the business model and transactions were different? Two implementations of the same product could feel like apples to oranges. 

Selecting a solution familiar to the consulting company. What is more important, a consultant or a solution? Sure, you may have heard that consultants are more critical. But choosing a solution just because you found a really knowledgeable consultant with a specific solution is not smart either. They just don’t know what they don’t know.

Selecting an ERP based on a preferred technology or an operating system such as Java or Linux. The underlying technology is generally an enabler, and most tech or operating systems are likely to be fairly comparable in terms of business outcome. While technology might drive the overall user experience, don’t use tech buzzwords randomly as a selection criterion without understanding their business impact.

We have always failed on Infor, wouldn’t make too much sense to select them. A million variables could drive a failure. It’s very rarely just one factor. Rejecting a solution purely based on past failures might still lead to failure; it’s just that this time you might not be able to blame Infor.

3. Solution Bias

Pricing is always hosted in eCommerce, so we should keep pricing there. Just because you haven’t seen pricing hosted anywhere else, it doesn’t mean it’s always hosted in the eCommerce or ERP layer. Unnecessary constraints without rationale can lead to implementation failure.

ERP systems are notoriously difficult; who wants them? Easy or difficult is a design choice. Easy systems have fewer business rules and leaner data stores with limited constraints built at the database level. And it’s like a three-legged stool: if you lengthen one leg, it throws off the balance. Don’t choose systems based on ease vs difficulty. Understand their impact on business outcomes and each team instead.

Operational Systems + Accounting Software = ERP. Here’s the truth: An operational architecture integrated with an accounting system will only be able to report financials, not the immersive finance experience that ERPs offer. So don’t be fooled into thinking you can replicate that by calling a bunch of APIs. The immersive experience requires the integration of data hierarchies natively built as part of the data model. Replicating the same hierarchies with a collection of APIs will not only cost a fortune, but you might never get the same results and scalability.

Why do I need more software when buying an ERP? Most ERP systems are likely to be a collection of software. Going for one brand may never be the ultimate solution. In reality, you’ll likely deal with multiple companies and support contracts. So don’t pigeonhole yourself with just one brand or software. Sometimes, having multiple software might be a superior option depending upon the architectural needs.

2. Departmental Bias

No one made money with accounting; focus on the processes differentiator to our business. Great strategy from the business perspective, not so much from the technical architecture standpoint. Instead, review briefly and watch out for red flags. ERP projects require aligning most processes, departments, master data, and reconciliation flows. 

Manufacturing was too complicated the last time we touched. Can we not touch manufacturing for this implementation? Unless having two ERPs in your architecture makes sense, given your business drivers, you can’t ignore processes as involved as manufacturing for ERP implementation. Anything that involves inventory should be thoroughly analyzed to ensure a successful implementation.

My people are busy. It’s very hard to get their time. Can we manage just with IT for the implementation phase? One department represented in the ERP projects means designing the system from their perspective. ERPs are similar to the way our heads are wired. Everyone thinks and works differently. So aligning departments and equal representation is key to the success of ERP implementation.

The last time we integrated APIs for eCommerce, it was very difficult. Can we not touch that and just implement the ERP for the rest of the functions? Ignoring architecture and reconciliation workflow is like designing an organ without knowing whose body it’ll be used in. Just as our bodies can reject foreign objects, enterprise architecture can be equally finicky. So take a holistic approach and analyze the entire enterprise architecture while shoving an “ERP” in your “company’s body.”

1. Alliance Bias

Asking a VAR or OEM to select an ERP. Value-added resellers generally represent only a few solutions, and even if they are completely genuine with their advice, they are likely to be biased, either unknowingly or because of conflicts of interest.

Employees receiving kickbacks. Offering kickbacks to customers’ employees as referral money isn’t as uncommon. 

VARs gang up to come across as independent. They join forces together to offer demos and POCs on multiple solutions and a perception of being independent.

VARs Carrying multiple solutions claiming to be independent. Even though they are a VAR with multiple solutions in their portfolio, they might pretend to be independent. 

Trusted accounting or tax firms claiming to be independent ERP consultants. Most large accounting firms have very similar business models as VARs. Their selection department might claim to be separate, but their true goal is to structure deals to favor their solutions.

An ISV offering free selection advice. ISVs offer free selection advice in the hope of getting business for one of their alliance partners.

Your current IT company running ERP selection for free. Most IT companies seek similar arrangements with ERP vendors as their referral relationship with their hardware OEMs when they offer free procurement help.

Private equity or buying groups pushing the same solution to their portfolio companies. Private equity and buying groups generally try to push specific solutions to unify their portfolio companies. Regardless of whether the bias is strategic or deliberate, it fires back equally.

My wife’s brother is the ERP sales rep. I have no choice but to buy from him. This is classic. You might need to decide between your marriage and ERP but remember, ERP might not be as forgiving as your wife.

Final Words

These biases are no joke; they can lead to catastrophic transformation failures. So, keep an eye out for kickbacks, but don’t get too comfy just because an “unbiased” ERP consultant promises a refund clause. You need deep expertise to detect these ERP selection biases, both within consultants and your internal team.

Oh, and don’t forget to take a good look in the mirror! You’re likely biased, too, just like the consultants. Regardless of the source, biases have an equal impact on the outcome. Use this list as a handy checklist to sniff out any potential ERP selection biases. Stay vigilant!

FAQs

System integration is like a commute, getting you from A to B. So why is there an overload of ERP integration tech options? Well, sometimes the destination is a system or an external business, and that determines the right integration technology choice. These options aren’t just programming languages but products of industry collaboration for interoperability. They may seem like business jargon to developers, but each plays a vital role.

The problem starts when companies blindly adopt these technologies without grasping their strengths and weaknesses. API or webhooks are classic examples. While they have made system integration easier, they might not be the best fit for every scenario. And let’s face it, dismissing a tech simply because it’s seen as “legacy” is like ditching radio for TV. So unless the enterprise technology is positioned as a clear successor, using something just for the “cool factor” might not be the wisest move.

Also, there are generally three layers in the architecture: web/UI, services, and database. Each integration technology option is optimized for one of these layers. For example, ETL’s design allows it to be efficient for quick and bulk movement of data, bypassing the business rules. But, newbies, listen up closely: bypassing business rules is a design choice but not always the best idea. Integration technologies optimized for web layers aren’t fit for every situation either. They have their own set of nuances, like UI layers may include additional presentation-centric logic only applicable to that layer. So how to select an appropriate option for your unique situation? Get a grip on the pros and cons of each tech option from the following list.

10. Natively built within ERP code/Custom-built and Externally Deployed

Most newbie ERP buyers mistakenly assume that business systems package unlimited bandwidth, oblivious to the fact that integrating additional code can strain system performance. ERP OEMs don’t typically plan for extra firepower in their core offering.

While minor customizations and some ERP integration logic can coexist within an ERP system, it’s not meant to cram ten passengers into a four-seater car. ERP Integration native to the platform comes in different forms: some people code it recklessly, bypassing security rules and tampering with the database directly, while others use add-ons or external components for deployment.

What’s it good for?

• For tightly integrated processes that touch master data, such as inventory. Customizations that seem inseparable from the core codebase. 
• The code base is not likely to change. The state of code must not break because of invariability in inputs. The integration code requires frequent changes because of the changes in interfaces or inputs.  
• The code base that the OEM must own regardless of technical or political drivers.

Myth

• Host the entire integration code inside the ERP to save costs. Don’t be fooled by this idea. You might pay much higher in the long term because of increased maintenance or slowed performance of systems.
• ERP integration logic can carry the additional workload. No, the planned capacity assumes that you must be running ERP with minimum customizations.

Best practices

• Host integration code inside the ERP that is tightly coupled with master data. Master data elements like inventory master or customer and vendor master.

• Host any native add-ons inside the ERP. The add-ons that are natively built for the embedded experience must be hosted inside the ERP.
• Don’t host the integration code inside the ERP that requires frequent changes or is prone to errors.

In short, don’t rush to host everything in the ERP. If your integration code simply moves data from A to B, it’s better off outside the legal and code boundaries of the ERP package.

9. Workflow Automation/RPA

Workflow Automation and RPA technologies are the newest entrants among integration technologies. While the flavors of workflow automation have been around, they weren’t as lean and efficient to automate user-driven processes embedded with system-driven. The tricky part is differentiating these technologies from iPaaS, which focuses on system-to-system integrations.

What’s it good for?

• Users and desktop-centric workflows and processes. Think of automating the responsibilities of a clerk performing monotonous tasks such as data entry or approvals.
• Good for tightening the processes of transactional systems. Such as ERP or eCommerce. Processes like improving the quality of master data: SKU numbering scheme or customer names.
• Good for ad-hoc processes. Think one time and not something that is part of your operational fabric.

Myth

• Replacement for other transactional technologies. It’s not meant to be better or worse than other technologies. They all have a role to play.
• Workflow automation and RPA are more cutting-edge. Everything is cutting-edge if you use it for the right use case.
• They are easier than other technologies, such as ERP. Every technology could be easy or hard, depending on how it’s being used.

Best practices

• Define the architecture and roles of the RPA and workflow technologies. Drawing architectural boundaries will help you clarify the roles and responsibilities of technologies.
• Analyze the admin effort first to ensure it’s not a symptom of broken processes. As well as to avoid automating broken processes.
• Don’t implement RPA and workflow tech just because they are cutting-edge. 

In short, Workflow Automation and RPA technologies are great for ad-hoc and desktop-centric tasks, but they fall short when it comes to handling transactional, operational processes.

8. eCommerce and Marketplaces

You might be surprised to find eCommerce listed as an ERP integration technology. But believe it or not, eCommerce, EDI, or P2P could be substitute technologies and serve a similar role to integrating with sales channels, especially if the purpose of eCommerce is just to capture orders. The same applies to marketplaces. They have their own integration platform that could serve the role of integration layer. 

What’s it good for?

• Smaller eCommerce brands that can’t afford expensive ERP integration just yet. Don’t fall for the temptation of point-to-point plug-and-play integration! While it may seem easy at first, you’ll end up with more reconciliation headaches downstream.
• Integrating with marketplaces that are a natural extension of that channel.
• Marketplaces and channels where segmentation of inventory for each channel is not as critical.

Myth

• Most channels must be routed through eCommerce, including punchouts. Based on the enterprise architecture and traceability needs, sales channels can be integrated through eCommerce or ERP.
• Pricing must belong to eCommerce. Depending upon the pricing segmentation and control required, it can belong to eCommerce or ERP.
• Bi-directional syncs are easy to implement through APIs. Without workflow design and control, bi-directional sync is likely to corrupt the data, challenging to reconcile.

Best practices

• Define the role of eCommerce, marketplaces, and channels. The clarity in roles will help you define your architecture.
• Define the traceability required for pricing and discounting and host in appropriate channels.
• Treat eCommerce as an order capture channel and then move to the central, downstream system to minimize the hops for reconciliation.

Use eCommerce and marketplace channels primarily for order capture. But for more complex scenarios, don’t forget to define your architecture, including reconciliation workflows, to ensure simplifying the front-end doesn’t lead to complicating the backend.

7. API 

Most people misunderstand the role of APIs in ERP integration. The APIs hide the technical boilerplate of underlying technologies obeying the same security rules as the user interface. This prevents the tempering of databases directly and separates integration from core system concerns. Not meant to be plug-and-play, though often perceived, so designing architectural and reconciliation workflow is critical with APIs.

What’s it good for?

• To easily communicate with internal systems. Unified communication without worrying about translations and protocols required to communicate with each underlying technology.
• To integrate easily without tempering the state of the core system. Unified security and business rules layer across channels and integration points.
• To isolate core systems from the integration logic. Easier debugging and maintenance through clarity in the roles and responsibilities of the integration layer and logic

Myth

• APIs are replacements for architecture. APIs only provide easier access to data from applications implemented in different technologies, but how you want to mesh them together to achieve the desired outcome requires thoughtful design.
• As long as you have APIs, you can integrate anything. Yes, you can, as long as you have workflows and architecture vetted out.
• APIs are better than EDI. Not true at all. EDI allows external B2B communication where pre-agreed, industry-wide messaging is critical. Since most companies define their own standards for APIs, they don’t have the same canonical model as EDI.

Best practices

• Define security architecture before incorporating integration through APIs
• Isolate ERP integration code completely from the core system
• Define system interaction flows, and master data governance path with APIs

APIs have made ERP integration easier as they hide the underlying technical details and allow integration easily with wide-ranging technologies and systems. But they can’t create the integration flows themselves, and not meant to be plug-and-play.

6. P2P and Punchouts

Larger companies generally use a procurement system to streamline their procurement processes. The P2P systems may have a gateway built with eCommerce systems to communicate between the client’s P2P and the vendor’s eCommerce. They can share their catalog, complete transactions, and receive updates on their orders. 

What’s it good for?

• The customer is too big to go to vendor’s websites to place orders. As big companies grow, they graduate from browsing vendor websites to place orders. The natural next steps? P2P or EDI
• Integrating with suppliers when you aim to consolidate and centrally govern your procurement processes. 

Myth

• Punchouts and P2P systems are superior to ERP. P2P systems tend to decouple the downstream processes to expedite purchase flow but at the expense of workload for downstream systems.
• P2P systems are best for any procurement organization. Only good for larger companies who prefer to simplify their front-end processes at the expense of the backend.
• Punchout must go through the eCommerce channel. Depending upon the architecture, organizational structure, and traceability needs, integrate P2P systems with ERP or eCommerce.

Best practices

• Integrate with P2P if your large customers have mandated them. While integrating with it might not be optional, how you will integrate is your architectural decision.
• Define the roles and responsibilities of P2P vs. ERP vs. eCommerce. Identifying clear boundaries for each system will help define the architecture.
• Define the reconciliation and master data governance workflows for P2P, ERP, and eCommerce systems. To help decide: ease of use vs. increased overhead for downstream processes.

P2P and punchout integration are great when customers might mandate them to integrate with their systems. They might also be good for streamlining your vendor processes. But they are neither replacements for nor easier than any other integration technologies.

5. ISV Add-ons 

Some ISV add-ons could provide the same capabilities as integration technologies, as well as augmenting business objects for improved traceability and collaboration with business partners. Despite their plug-and-play integration capabilities, analyzing architecture and reconciliation flows is still critical.

What’s it good for?

• Integrating with vendors that might not be able to afford other expensive integrations. Compared to P2P, EDI, or eCommerce, ISV add-ons could provide automated communication at a much lower cost.
• Providing additional granularity with the business objects and workflows. 
• Hosting additional data that might not be relevant for the ERP and doesn’t need to be centralized.

Myth

• Enterprise architecture is not relevant to ISV add-ons. ISV add-ons are nothing but data siloes, and they should be treated just like any other systems in the architecture.
• Master data governance and reconciliation flows are not relevant for ISV add-ons. While they might be plug-and-play to integrate, the analysis of reconciliation workflows and master data governance is still critical.
• ISV add-ons are easier than ERP. Easier because they decouple the underlying systems but increase the admin efforts for downstream processes. It’s a design choice.

Best practices

• Use ISV Add-ons, but only if it makes sense architecturally.
• Where vendors or customers might not have any other means of integrating with your systems and are willing to communicate through the ISV add-ons.
• When underlying data make sense to augment in an add-on system than in the ERP.

ISV add-ons provide additional traceability and datasets that might be more expensive to build inside an ERP. They also provide cheaper ways of integrating than P2P, EDI, or eCommerce.

4. WebHooks

WebHooks allow communicating with external systems as business objects advance. While they can support more intricate integration scenarios than APIs, they are also not meant to be plug-and-play. Not inherently providing transactional consistency or seamless communication, designing integration flows isn’t optional with them.

What’s it good for?

• Easier web-centric integrations that don’t require tight master data governance. If the integration is primarily to notify or log/report in the destination system, use WebHooks.
• Easier to use with web-centric technologies. Not as useful if there are any non-web channels involved in the architecture.
• Good for integration flows where tight security may not be of concern. 

Myth

• Webhooks are easier than other integration technologies, such as EDI. Not meant to be replacements, Webhooks don’t support industry-adopted canonical messages like EDI.
• Webhooks are modern ways of integration. Despite allowing tighter embedding of web apps without tempering with the core, they are not better than any other integration technologies.
• The technologies that don’t support webhooks integration are legacy. What if legacy technologies don’t have a use case for Webhooks?

Best practices

• Use webhooks integration for commerce and web-centric technologies, especially where a tighter collaboration of web apps would make sense.
• Analyze the impact on omnichannel architecture if webhooks are still a good fit. 
• Understand the security needs and master data governance before integrating it with Webhooks. Design, architecture, and reconciliation workflows are not optional, even with webhooks.

Webhooks are great for additional granularity that APIs might not support, as well as allowing tighter collaboration of web apps. But they are not meant to be a replacement for any other integration technologies.

3. ETL

ETL is faster at bulk data movement, but it’s not the best choice always. It’s faster because you bypass the business rules to get quick access to raw data without impacting operational performance. It’s like using a service elevator while moving. But replacing passenger elevators with service ones is not the best choice. 

What’s it good for?

• Bulk data transfer among databases. No other interactions at the UI and service layers through ETL.
• Nightly load to get data in a snapshot to perform analysis. Only when you need raw data for analysis, without touching operational workflow.
• Where faster processing at the database level is required. Think quick-moving without disrupting the passenger flow of an apartment building.

Myth

• ETL can cater to most integration scenarios. Calling the service layer and processing EDI transactions through the ETL layer is like exploiting your superpower. 
• Even service and UI integration scenarios can be done through ETL. This would be very similar to accessing databases directly. APIs exist to prevent direct database access for unified security and business logic.

Best practices

• Use ETL only for the database-to-database integration. Using ETL for anything other than moving bulk raw data is an antipattern.
• Don’t use ETL where service layer integration may be a better fit. Just like the passenger elevator is perhaps the safest choice when in doubt, ETL access should be a privilege.
• Don’t use ETL for EDI or external integration with other businesses. This is like letting passengers go through the service elevator without security protocols or scrutiny. 

Think of ETL as a special privilege allocated for one-off scenarios for bulk data transfer without impacting operational performance. So don’t let ETL touch other layers except for the database.

2. EDI

More than an integration technology, think of EDI as “electrical codes” designed for industry collaboration. Replacing EDI with API would be similar to leaving red vs. green for interpretation. Also, just because you prefer to swap out red with green in your home, it’s your personal choice. APIs are superior for personal choice, while EDI helps with regulated communication across industries.

What’s it good for?

• For B2B communication, where regulated communication is critical. Where each message is coded with the same standard without requiring interpretation.
• Where standardized messages are a requirement across all vendors, think of how terms such as receipt or profit could have different meanings in different contexts. EDI helps us prevent this confusion.
• Integrating with vendors that might already understand EDI or may have systems that are EDI-compliant. 

Myth

• EDI is a legacy communication method. EDI is perhaps the most concise industry communication language ever designed. Get used to it! 
• EDI should never be used. APIs are a better choice for integration. Using APIs where EDI would make more sense is like skipping electrical codes just because you don’t appreciate them. There will be consequences when you let an unlicensed electrician repair your home.
• EDI is slow and error-prone. Only when it’s being overly used and poorly designed. 

Best practices

• Use EDI where systems might already be EDI-compliant. 
• Implement EDI where standardized communication could reduce churn with vendor communication.
• Don’t use EDI for internal communication. Not designed for internal integration. APIs would be a better choice for that, or you will outgrow EDI codes.

Just like technology does not answer every question, EDI is a communication and collaboration language. Use EDI for externally regulated communication but avoid it for internal system integration.

1. iPaaS/Middleware

iPaaS and middleware are probably one of the most overused terms. The role of iPaaS and middleware is to connect external wiring among different systems in the architecture. Not just that, though. Translation, transformation, and quarterbacking, when you might have systems that might operate at different speeds, would be other benefits.

What’s it good for?

• To implement integration logic. Integrating two or multiple systems through a variety of communication methods and technologies.
• To have room for load throttling. Cloud technologies don’t offer the same infrastructure control as was available in on-prem settings. The point-to-point connections assume that all systems can operate at the same speed, which might be OK at a smaller scale but not at a transactional inflection point when you need to decouple your workloads.
• To isolate integration logic from core systems. The separation helps with debugging, maintenance, and isolating issues.

Myth

• Unnecessary license fee. The additional license fee might come across as unnecessary, but keep the slower performance or increased fee due to the higher tier of your ERP infrastructure in mind.
• IT-centric systems are only relevant for large enterprises. Even smaller companies might use the baby version of iPaaS, such as Zapier. They might not be as capable as their larger peers.

Best practices

• Don’t host business rules and logic that must be hosted in the core system
• Keep only the integration and transformation logic inside the iPaaS layer
• Host only the workflows geared toward system-to-system communication. User-centric workflows might not be the best candidate for iPaaS. They are better suited to workflow-centric technologies.

Always use iPaaS in the architecture unless your needs are to use one system without requiring integration. But don’t assume that you have one system when you might be using a collection of apps underneath with the branding of one, like an ERP system.

Final Words

Just like attempting to “fly” to your neighbor’s house may not be the wisest move. It’s important to use integration technologies purposefully. Overusing them can lead to scalability and performance problems, even if they might be the trendiest tech around.

Moreover, integration isn’t just about moving data from point A to point B. That’s the easy part. The real challenge lies in tackling compliance issues and building an enterprise architecture that aligns with business and performance goals. So, if you’re new to the integration game, don’t get swayed by the latest technologies. Dig deep into their origins and intended use, and apply them wisely. Hopefully, this list can serve as a helpful 101 guide.

FAQs

The enterprise software (or ERP) industry has always struggled to justify its hefty price tags. Seriously, why is software still breaking the bank when the hardware is on a discount spree? Remember the good ol’ days of on-prem software? Customers were just getting used to paying for support and licenses. But then the cloud came in like a storm, demanding they shell out nearly ten times more! Talk about a shocker. It’s enough to give enterprise software reps nightmares. Result? They had to downplay the importance of design, architecture, implementation, and change management to close deals. And that’s when things took a wild turn in this industry.

Welcome to the era of marketing genius! But let’s be real. These practices might be dragging the ERP industry down, despite the tech advancements. The race to come up with buzzwords and peddle misleading conclusions like “easy-peasy software implementation” has become a sport. It’s almost a joke to ERP implementation consultants when reps claim that anyone with a laptop might be able to integrate cloud ERP software. Who needs enterprise architecture in the cloud? The never-ending race, right?

Buzzwords, buzzwords, and more buzzwords! They promise the moon and stars, faster value, and lightning-fast implementation. But guess what? It’s all a bunch of baloney! Those buzzwords are more deceptive than a politician’s speech. And you know what happens next? Customers end up making silly decisions like rushing to go live or skipping user training. And the result? Their confidence in digital transformation takes a nosedive. And who’s to blame? These practices, my friend.

10. Marketing Hype

Marketing hype like the Bill of Rights is meant to show how much ERP vendors care, but let’s be real; it’s mostly fluff. In fact, it can backfire if you don’t evaluate it carefully.

• Functional checklists. Provided by OEMs and resellers to help customers manage the ERP selection process in the DIY mode. But they’re often biased (written from their perspective) and leave people confused. They make all solutions seem similar and distract from what really matters (leaving people to focus on other “touchy-feely” issues). Technical issues get downplayed, too.
• Consumption-based business model. Pitched as a generous favor from vendors, but it’s not always better. Both named and consumption-based models could be equally good depending on the context. The consumption-based model comes with a performance tier, which is often overlooked while unlimited users take the spotlight.
• Bill of Rights. Some OEMs promote their Bill of Rights as if they’re the only fair players, but most of it lacks tangible value. It’s just a marketing gimmick, so don’t fall for it. Access to data sounds good, but it’s useless without their software.
• Fake cloud. Don’t be fooled by those offerings claiming to be cloud-based; they lack essential cloud perks. They’re just slapping on the word “cloud” to give you that “cloudy” feeling. It’s like putting lipstick on a pig – it’s still a pig.

Don’t buy into marketing hype. It’s all about putting down the competition or slyly nudging you in their direction, even if they dress it up with a smile.  Whether it’s negative marketing or shiny hype, they’re just playing the same game.

9. Perception of APIs or Low-code/No-code

Traditionally, there’s always been a misalignment in expectations between business users and technical teams. Business users think tech wizards can work magic with vague instructions, while techies want clear specs before diving in. This gave birth to low-code/no-code tools, where business users could try their hand at coding. Sadly, though, low-code/no-code only adds to the mess of brittle code and lousy architecture.

• Overselling of low-code and no-code and APIs. Instead of hyping up no-code and low-code, the ERP industry should emphasize the value of writing solid requirements without ambiguity.
• Overselling of giving control to citizen devs. Citizen devs, listen up! It’s time to channel your inner tech guru. Instead of trying to do it all, focus on providing clear inputs. 
• Over-emphasizing the importance of code. Let’s face it. Writing code is like following a recipe for mac and cheese—pretty straightforward. The real challenge lies in whipping up a delicious design and nailing those specs. So instead of obsessing over mastering new programming languages, prioritize writing requirements that can pass the “SMART” test. That way, you’ll be cooking up success in no time!
• Undermining the importance of good requirements, design, and test cases. When it comes to software, requirements, design, and test cases are like a dynamic trio. They’re BFFs, inseparable! Their quality determines how tasty your implementation will be and how smoothly your processes will run. 

The obsession with low-code and no-code is dragging the industry back and causing architectural messes. It’s time to shift gears and prioritize coaching business users on creating solid specs and designs. 

8. Delayed Involvement of Implementation Teams

Enterprise software vendors often sideline their implementation teams during the sales process, fearing they’ll reveal too much information and jeopardize their competitive edge in the deal. Sadly, it’s the ERP implementation teams left to deal with the fallout of unrealistic commitments made by the ERP sales reps, limiting their capabilities despite their competence.

• Implementation teams are only involved after the damage is already done. When dealing with ERP vendors, insist on involving the person accountable for implementation and have their name on the contract.
• Major architectural decisions are already made by decision-makers with very little hands-on implementation experience. Success in ERP implementation comes from balancing business and technical perspectives. It’s not a one-and-done affair where you throw the “WHAT” at your technical teams and expect them to magically conjure the “HOW.” The process is iterative, involving decision-making and feasibility analysis. So, hold off on decisions until you have someone with solid implementation experience to guide you through the pros and cons, both financially and technically.
• The gap between the implementation and the sales teams. Flipping through marketing brochures to answer sales objections is not the same as implementing. It requires much deeper probing of design and architectural issues that ERP sales reps don’t have exposure to.
• The selection teams with very little implementation expertise. Avoid ERP selection consultants who rely solely on tech vendors for architectural and technical decisions—look for hands-on implementation expertise instead.

Regardless of the reasons, political or genuine, keeping implementation teams out during the ERP selection and design phase harms the ERP industry. And yes, technical teams might be perceived as too detailed oriented, but lacking implementation experience in the pre-implementation phase is equally risky.

7. Overselling of Frameworks and Technical Certifications

The enterprise software and ERP industry is brimming with frameworks and certifications, each claiming its own formula for success. But here’s the catch: these frameworks often assume constraints that don’t align with clients’ unique environments. To achieve true operational efficiency in ERP implementations, judgment is more important than frameworks.

• Frameworks and certifications are used as a shield for implementation success. Certifications and frameworks don’t guarantee implementation success. It’s not about parroting concepts but how you apply them that counts in ERP implementations. So, don’t judge a book by its certification!
• ERP project is successful but limited tangible business results. Can you Imagine working harder after a “successful” ERP implementation? Siloed approaches promoted by frameworks and certifications without a business-focused analysis can still leave you swimming in inefficiencies, despite all the investments.
• Technical certifications designed with the product boilerplate. Certifications often drown in product jargon that may not even apply. They can lead you so deep into the product rabbit hole that you lose sight of the real world.
• Certifications are too biased toward the product than toward the customers’ success. Product certifications tend to get too wrapped up in the product concept. While they may offer best practices from their perspective, every installation has its unique context. It’s like trying to fit a square peg in a round hole of possibilities!

Avoid vendors that oversell the importance of certifications. The certifications and frameworks go only so far. The industry needs to water down the importance of certifications and frameworks and design them that test consultants’ judgment on customer success and industry knowledge.

6. Architectural Immaturity

ERP vendors selling cloud often downplay the importance of architecture. And remember, architecture isn’t just about technology—it’s about getting all Fs equally represented: form, fit, function, finance, fanbase, and future-proofing. 

• APIs are used as a shield for architecture. APIs have successfully masked the proprietary boilerplate of underlying technologies, providing a secure and unified way to access information, just like a user interface (UI). However, some ERP sales reps, lacking implementation and technical prowess, tend to exaggerate the capabilities of APIs, mistakenly believing they can replace the need for solid architecture and workflow design.
• Significant communication issues with systems. ERP implementations that postpone integration and communication workflows to the implementation phase can stumble upon reconciliation challenges. 
• System adoption issues. Poor architectural choices can turn your user experience into a bumpy ride, tempting them to hijack processes and create parallel siloed systems. And guess what? That leads to some serious adoption issues. 
• Involve technical teams with architectural experience during ERP selection. When technical and implementation teams join forces during solution design, magic happens! It’s like assembling the Avengers of the enterprise world!
• Misunderstanding of data stores and reconciliation workflows in the architecture. User experience and operational overhead are like two rival forces locked in an eternal struggle. The more data siloes, the more reconciliation efforts and operational overhead you’ll face. 

As we leap ahead with technological advancements, our architectural maturity seems to lag behind. While technology can streamline workflows and processes, it’s no magic wand that conjures up flawless architecture with a simple flick.

5. Lack of Emphasis on Change Management

While most regard change management as a critical component for successful digital transformation initiatives, the boundaries often get blurred. The truth is, effective change management requires aligning perspectives, documenting to mitigate risks, and treating it like a central function, just like a general contractor who takes responsibility for the entire project. 

• Change management is not meaningful without ERP subject matter expertise. Change management without ERP expertise is like trying to drive a car without knowing how to steer. To effectively manage and align everyone’s expectations, you need change management consultants who have ERP subject matter expertise and understand different technologies to be able to communicate effectively with all teams involved. Don’t settle for a change management team that’s all talk and limited ERP know-how.
• Too much emphasis on users who might not understand the implications of architectural experience. Putting untrained and unqualified users in charge of critical business processes and architectural decisions is like handing the car keys to a toddler. Sure, their opinions matter, but expecting them to make informed choices without proper information and guidance? It’s a recipe for disaster. Empower your users with the right knowledge and support, so they can contribute meaningfully to the decision-making process. Remember, architecture and business process decisions are best left to the experts. The right experts excel at facilitating decisions without applying pressure. They guide, not impose.
  

Change management is the secret sauce that keeps the system sizzling. Ignoring its importance is like going in circles without making progress. If the ERP industry gave change management the spotlight and the right ingredients, customers would feast on business results, fueling industry growth.

4. Overemphasis on Cloud and SaaS Technologies

The ERP industry loves to hype up SaaS and cloud technologies as plug-and-play fixes. They mistakenly believe that a bunch of SaaS solutions patched up together automatically equals tightly integrated processes and financial control achieved through ERP-like architecture. 

• Cloud is a solution to all problems. Cloud is not meant to be a solution to all problems. Purchasing SaaS won’t automatically solve your business and performance issues.
• Too much licensing fee, very little results. Yes, SaaS is more expensive than on-prem as vendors need to follow the guidelines related to cybersecurity and data loss, which are often ignored when managed internally. But unfortunately, paying more for SaaS is not a replacement for good design. ERP vendors need to justify their costs, and they do so by downplaying the importance of change management, the cost of implementation, and the efforts involved with good solution architecture. Listening to them is like taking advice from your competitors.
• New problem? Throw a new SaaS. Lacking proper architecture and solution design can result in a never-ending loop of purchasing SaaS without experiencing any real business improvements or, worse, undoing the benefits you’ve already gained.
• Architecture, business systems, and master data governance teams were not involved before buying SaaS. The ERP industry often misguides companies by suggesting that SaaS purchase decisions can be made at the department level, without considering the enterprise architecture, master data governance, and impact on other departments. This approach only results in duplicated efforts, more data siloes, and a loss of overall enterprise value.

A tool is just a tool, no matter how powerful it claims to be. So don’t expect a pricey tool to magically generate money or enterprise value for you. Life isn’t as simple as SaaS sales reps make it sound.

3. No Consensus on the Definition of ERP

The ERP industry struggles with defining ERP due to differing industry expectations. They simplified the term ERP for business users to grasp, but this misunderstanding leads to misguided decisions, ultimately leading to lost confidence in digital transformation initiatives.

• Every business has a new definition of ERP. Sadly, without considering business processes, reconciliation workflows, and operational overhead, grasping the true value of ERP is like chasing a ghost. The ERP industry should move beyond the term “ERP” and focus on the importance of ERP-like architecture, the key ingredient for operational growth and unlocking enterprise value.
• Misunderstanding of the importance of ERP. Unfortunately, unless you have hands-on experience in growing businesses with an ERP-like system, grasping the true essence of a real ERP is as elusive as a unicorn. Also, the added noise with systems claiming to be ERPs just because they tick a few boxes does not help either. 
• The role of add-ons and auxiliary systems. Most ERPs started as siloed apps, but then they had to become tightly integrated as that’s what businesses needed to scale. The role of add-ons is generally misunderstood. Whether add-ons are third-party or included as part of the solution, they are just another data silo if you think from the perspective of architecture.

The ERP industry is the master of confusion, cashing in on ERP misunderstandings and preconceived notions. But what we truly need is a clear message about the significance of ERP-centric architecture and operational process design.

2. Shiny Object Syndrome

The ERP industry loves to come up with shiny objects, and let’s admit it, we all have a weakness for them. But chasing after shiny objects often leaves companies disappointed with technology initiatives, as well as missing out on the opportunity to seek the right help that could truly transform their businesses.

• New technology must solve all business problems. Don’t be blinded by the glimmer of shiny new tech. Before diving in, ask: Will it truly add value? Take a deep dive into operational data and workflow assessments, perform root cause analysis through process models, and vet potential solutions diligently before procuring and implementing them. But remember, if broken processes and data are the core issue, a fancy tech will only make the mess grow at a faster speed.
• Rat race towards technology. Ever heard the team chant, “Must we follow the tech trend or will we be left behind?” Or worse, do you find yourself beating that drum? Well, here’s the truth: Technology alone won’t boost your business prowess. It’s all about how you use it that makes a difference.
• Technology-centric ERP system selection decisions. Transforming initiatives shouldn’t be fueled solely by the need to modernize IT. Focus needs to be on the business’s beating heart instead.

Hey ERP industry, stop caching on customers’ shiny object obsession! And companies, wake up! Chasing shiny objects will only lead to digital transformation doubt and put the brakes on ERP industry growth.

1. Faster Implementation Times

ERP publishers engage in a rat race for implementation speed to secure contracts and ensure renewals, sacrificing adoption risks in the process. Ironically, analyst firms inaccurately rely on implementation time as a metric, failing to consider the true measure of technological advancements and efficiency gains. This needs to stop!

• The misunderstanding of the term “implementation.” The problem with faster implementation is that it’s not just about system setup. While some systems are user-friendly, human learning and consensus-building take up the majority of the time in ERP projects.  The problem with faster implementation is that it assumes data and processes are ready to go, with all specifications fully vetted. It also assumes you’re a pro at making decisions on countless variables for operational efficiencies. 
• Rat race of faster implementation times. The rat race began because software vendors had to meet quarterly targets. While technology has sped up the process, expecting to go live within 90 days is trouble waiting to happen. Also, comparing implementation times is like comparing apples to oranges. Just because your peers did it in two weeks doesn’t mean you can too. What if they spent years perfecting their processes before signing the contract? 

Asking for a faster implementation is like asking for a one-way ticket to hell. Don’t expect a happy ending when going live on an unstable system with untrained users. Time to wake up and ignore those ERP vendors pushing for speed just to boost their stats. Hell isn’t the dream getaway for your ERP project, trust me!

Final Words

Enterprise software will never catch up with the hardware’s discount extravaganza. It’ll always burn a bigger hole in your pocket because of the nature of the beast.

It’s high time for ERP software vendors to learn how to prove their worth instead of endorsing practices that’ll ultimately harm the industry. Wise folks say there are no shortcuts in life, and faking it will only take you so far! Now, the big question is, will the ERP industry let go of its cloudy judgment for the greater good of the ERP community?

FAQs

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