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.
ERP Selection: The Ultimate Guide
This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.
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.
+ 
Omnichannel ECommerce Customer Experience Transformation
Learn how fashion retailer AKIRA built a digital roadmap and managed stakeholder expectations to transform its processes and systems.
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.
+ 
ERP Implementation Failure Recovery
Learn how Frederick Wildman struggled with Microsoft Dynamics 365 ERP implementation failure even after spending over $5M and what options they had for recovery.
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.
+ 
ERP Optimization And Integration Architecture Development
Learn how Work Sharp fixed their broken ERP implementation that caused customer service issues and improved Supply Chain planning.
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.
The 2024 Digital Transformation Report
Thinking of embarking on a ERP journey and looking for a digital transformation report? Want to learn the best practices of digital transformation? Then, you have come to the right place.
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
Related Posts:
