So, you’ve done your own research, you’ve narrowed down the list of ERP products that you think would work for your company, and have found ERP partners for each of those products. That said, you don’t want to just be sold to and need to figure out which product is actually right for your company. What do you do?
The first step is usually sitting down with one or more of those ERP partners and doing an in-depth discovery. This process can be done by phone, or in person, and will usually (read: should) precede any demos of products. By going through the major points of your business and your needs, both current and with future plans, partners can build a picture of where you are at now and what your new system would need to be able to grow into or accommodate as your needs change down the line. The caveat here is that, as with all things, preparation is key. There are things you can do before the discovery process begins that can speed up or smooth out the entire project.
What does discovery cover?
The discovery process aims to unearth all of the processes, tasks, and needs of a business. The internal team of staff that will oversee the complete solution implementation are usually present, able to answer any questions about how things work in their particular area. The Pre-Sales teams from the ERP Partners, such as, oh I don’t know, The Answer Company, will often have a list of questions that guide the exploration of how your business operates, and where an ERP can help.
What questions do they normally ask?
- Metrics questions give a foundational understanding of your current business statistics. For example: How many employees do you have? What’s your typical annual revenue?
- Process questions give a better understanding of how your business works. For example: If you could draw a workflow chart, what would your sales process look like? What do your manufacturing processes look like? How does your inventory move through different departments?
- Security and Risk Questions give an insight into whether cloud or on-premises hosting is preferable. For example: Does your data need to stay in Canada? Do you have IT staff on-site? Do you collect sensitive personal data, like health information?
- Tasks and Responsibility questions help show on a detailed level what you need from your systems. For example: What does the day in the life of a salesperson look like? Who would be responsible for tracking inventory as it comes in? As it goes out?
- Qualitative questions help identify both a functional and cultural fit. For example: What attributes does your ideal solution have? What does it need to have in order to get your staff to actually use it?
- Pain Point questions are focused on identifying areas that need to be improved with your new solution, and ways that they can be improved. For example: What are the things you’re struggling with? What are staff complaining about with the current solution?
- Additional Solutions-based questions aim to determine what tasks could be handled by the ERP being proposed. For example: What systems are you using for Human Resources or Payroll? What solutions do you not have yet but are considering or may need in a year or two?
Two of the trickiest question areas here are around your processes and your tasks. When factors are overlooked at this stage, it can often lead to a project that requires late-stage changes, where additional work may be required shortly after go-live, or really hurt employee buy-in. This means more time, more money and, ultimately, more headaches for you.
Can you prepare for discovery?
Of course! Really, the bulk of preparation comes down to identifying and cataloguing your business processes in the real world, or “as-is”. When it comes to defining your business processes, everyone’s voice should be heard. We’re not talking about 2.5 minute intervals where each of your 442 staff drop in to outline their personal ERP wish list and grievances. Nor are we suggesting opening the floor at a company-wide meeting.
In practical terms, it usually means tasking a stakeholder (like a departmental head or project champion) with speaking to their team and uncovering the true state of processes. There may be “hidden” processes that are not formally catalogued, that only those in that department know about. There may be processes that look workable on paper, but do not really happen.
Oftentimes, work-arounds and processes that involve a large amount of human intervention are the result of limitations of your current system. Knowing these issues helps you avoid them with a new system. Let’s take a look at a few example situations, and how we can document the process either As-Is or, unhelpfully, As-It-Should-Be (according to your official written procedures).
A manufacturer requires sales staff to submit a work order to the production team before they can begin work. A work order is generated and automatically sent to the appropriate people.
However, the set-up of the current ERP is outdated and does not handle transfer. Admin staff spend hours a day emailing work orders, or printing and delivering them to the correct team members. If work orders get lost, there is no accountability trail.
A multi-national has just expanded into a new region. They handle their compliance monitoring from their ERP, which asks for all the required information at the time of processing.
While they have a system built around their local legislation, they spend hours manually checking and changing elements so that they meet the new region’s compliance factors. They are losing time and money because of this.
All vital, relevant information is logged in the correct place on assets in the ERP, in order to facilitate the proper use of EDI.
After years of trial and error, and countless time on the phone, the company’s accountant knows that a vital field is missing in AP documents. They have worked around the issue, and have a trick for including the vital info so they don’t waste more time in ironing out the clerical details.
Don’t be ashamed to present things, teeth and all, to your ERP partner. The As-Is analysis helps them pull together a picture of what your perfect system looks like. Think of it like the ‘Before’ and ‘After’ pictures of a house remodel. The impact is bigger when you can see the whole journey.
Who should be on the team?
That depends on your organization. In saying that, it’s common for ERP implementations that have been designated as projects for “just the IT Team”, or that don’t have proper buy-in from management across the company, to fail shortly after go-live.
So, the team members who have gathered the information from each department should likely be the people that are involved in the decision-making. However, the As-Is processes are not the only thing these stakeholders need to be able to visualize. They should also be able to take a high-level look at the department’s operation, and the business as a whole. The team put together to work directly with your partner should include as many of these bi-focal stakeholders as possible. This ensures that all voices get to the table, but are prioritized based on a macro view. This team then needs to be allocated resources and time to do the work both before the arrival of, and with, the partner doing the discovery.
If you’re thinking that this seems like a big undertaking, you’re right! The beauty of a completely fit-for-purpose ERP is that it can optimize processes and create new efficiency in every department; to do that, though, every department needs to move past the official documentation into the boots-on-the-ground working of the business. By mapping all of these out, your ERP Partner can help you move to a system that solves inconveniences and makes things easier for everyone involved. Forewarned is forearmed; getting into the nitty-gritty at the earliest stage helps you avoid it at a later time when it costs more money and time. In the long run, it eases the transition to an ERP that can transform your business.