This is part 1 of a 6 part series. See the entire series here.

Discovery & Planning

The adventure begins! Implementing a new ERP system in an organization is a long iterative process with definite phases (with a tendency to overlap) – even extending beyond “go-live”, the point at which the new system is actively in place. If you’re still not sure about whether or not your organization should invest in a new ERP system check out this past series regarding the Repair or Replace decision. The end destination is a new era of an integrated, growth-friendly business management system, bringing with it, new heights of productivity and effective communication within an organization.

Understanding the Business’ Needs

Discovery and planning is the first stage, lasting up to roughly 4 weeks, where the main goal is for the implementation team to get to know the business and its processes. Discovery starts during the sales cycle (if it is done right) and discovery and planning continues on after the sale is made, as the implementation team works with the project team to create a solid project plan – the end goal of this phase of the ERP project. This involves looking at a company’s corporate structure, lines of business, departments, product lines, etc. The team will also dive into the business processes such as quote to cash, procure to pay, cash management, and period closing.

5 Steps for a Successful Discovery

Establish the Project Team

The project team should represent all aspects of the business. There should be someone from Sales, Customer Service, Purchasing, Materials, Operations, Accounting, and IT. Team members should have strong knowledge of current procedures in their area and be active system users with hands on experience, knowing what the current system does as well as its limitations.

The team leader should be someone who is higher up in the organization chain – having an understanding of how the business operates and where the business is heading. Often times an ERP project can be interpreted by others as just an IT project, particularly if a person with an IT background is the team leader. Watch out for this. It must be seen as a project that involves and affects the entire business – not just IT.

The best project team I have worked with was at a company that had a retail store, an online store and a production facility that built products for stock and for specific customer orders. This was a fairly complex system with two systems involved and a custom application to hook them together.

At the kickoff meeting the President started the meeting by explaining to the project team members that they had been selected because they were the best from each department and as such, were being entrusted to figure out the best way to implement the system. The project team leader was the Controller and he took full ownership of the project and did an excellent job of facilitating the work. As she concluded her remarks at the kickoff meeting, the President transferred authority to the team to complete the project and asked for frequent updates on the status. She stayed actively involved at a high level making sure the team had the resource and bandwidth to complete the task.

Hold Discovery Meetings

This is where members of the implementation team interview members of the project team to get an in-depth understanding of various parts of the business at detail level. The team will want to know what are you currently doing, and what you want to do in the future? They will discuss current processes thoroughly and identify pain points with the current system.

Document Key Processes and Requirements

Overall, this round of documentation will become the foundation for configuring the new system and also helps the implementation team with building out the project plan. This involves meetings with the implementation team and the project team, as well as executive members – looking for red flags, or gaps between the customers’ needs and system capabilities. These holes can greatly affect the requirements of the new system and the better they are understood, the better job the implementation team can do guiding the implementation.

Also, this includes discussing broader strategy with the executive team. It may be that there are new initiatives underway that can impact the requirements of the system. For instance, if the company is planning on opening 30 new stores in the US, there are most likely important implications on how the new system should be set up.

Identify Potential Gaps, Risks, and Solutions

Continuing from the discussions in the previous step, this is where the implementation team will work to identify all of the areas where the current system doesn’t meet the company’s needs. Then, based on those findings, they will begin formulating potential solutions based on the new system. Areas that require work-arounds outside the system like extensive spreadsheets are prime candidates. The team will use this information to formulate suggested solutions for the project team to evaluate and test.

In my experience, if you find a system that addresses 90% of your needs out of the box you have made a good selection. The balance of those needs can be addressed by adapting your procedures to the way the software works, customizing the software or a combination of the two. Systems like Acumatica are highly customizable. Arming the implementation team with the knowledge of your company directions and needs will arm them to guide the project team through selecting the best approach to address the remaining 10%.

It is important to identify any risks that might push out the implementation date or that make the conversion more complex. Risks to identify might include things like complex chart of accounts, inaccurate financial records and operational data, significant planned absences of project team members during the implementation and so on. These risks should be listed and steps taken to mitigate them.

Build the Project Plan

The implementation project plan will serve as a road map for the implementation. Depending on the project it may be fairly detailed or it may be higher level. It will include information from the last three steps and evolve as you work through the upcoming Design and Development processes. Think of it as a sort of backlog list of tasks used to guide the implementation team, the development team and the project team. It is a communication tool for all involved to have visibility of open items and priorities.

The bottom line for the discovery process is that the implementation team and project team must both understand and agree on the business processes and the objectives of the project. The project plan is the end goal of the discovery process and it is the foundation of the rest of the project.