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.
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.
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.
+ 
Omnichannel ECommerce Customer Experience Transformation
Learn how fashion retailer AKIRA built a digital roadmap and managed stakeholder expectations to transform its processes and systems.
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.
+ 
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.
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.
+ 
ECommerce Supply Chain Transformation
Learn how LockNLube transformed its inventory and supply chain challenges by consolidating over 20 systems.
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.
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.
FAQs
Related Posts:
