Nearly every enterprise resource planning (ERP) project begins the same way—a loosely defined requirement provided to a team. The team may be from information technology, operations, employee relations, or any other department. What happens next, though, is the first opportunity for success or failure of the project or initiative. What’s that? ERP requirements gathering.
This process can either be frustrating or productive and rewarding to those involved. By mastering the art and science of ERP requirements gathering, you can help make certain it’s the latter.
Requirements gathering must be more than just a science. It necessitates artful communication skills (in particular, empathetic listening), excellent technical understanding, a collaborative demeanor, and skill in asking the right questions. With certified experience in Microsoft Dynamics 365 Business Central and other ERP systems, we’ll highlight a few best practices that combine science and art.
1. Build Your Team
ERP systems, like Business Central, help organizations manage day-to-day business activities from a common database and avoid data duplicity. Some of the business functions and system integrations to review may include:
- Accounting and Financial
- Employee or Human Resources
- Sales and Inventory
- Customer Service
- Manufacturing and Distribution
- Materials and Stock
- Supply Chain and Logistics
Include decision makers from each of the departments that will use ERP most. However, a recommended best practice is to use discernment when building your ERP project team.
You want everyone who is necessary to be present. Discuss requirements in person (when possible) with as few people as possible. In general, a small team of key department leaders, along with your technology consultant and project manager, works well. Since business processes will be discussed during the requirements-gathering phase, it’s helpful to create a setting where people feel comfortable sharing and reviewing processes. Sometimes the probing questions that need to be asked may reveal things you and your teammates haven’t considered yet.
A phrase our technology consultants will say sometimes is that it’s our job “to lift the rock and note all of the critters living beneath.” Ultimately, the goal is to assess what your business requires from the ERP system as quickly and efficiently as possible.
2. Outline & Articulate Expectations
Next, expectations should be set. Technology projects, big and small, can be thrown off course when unexpected challenges occur. This is why outlining expectations during the requirements-gathering phase is essential.
Articulate your team’s expectations and set measurable goals. Outline project expectations and share and collaborate on these with your technology consultant. For instance: Do you have timeline expectations? Do you expect documentation from your technology consultant after each meeting? Do you have a list of integrations or customizations you want to be completed?
For example, imagine you’re an HVAC contractor, and a customer requests your company to install a new HVAC system in their 100-year-old home. Surely you would not deliver an HVAC system with power, a fuel source, and no ductwork. Similarly, you don’t want to miss “obvious” connection points—for both system requirements and team expectations.
3. Carefully Review System Requirements
Armed with all that preliminary work comes the more technical aspect of the process. One of the primary goals of nearly every ERP project is to help make business processes simpler and more efficient. That’s why it’s crucial to map existing processes and identify pain points. Doing so can help avoid recreating similar issues. It also is important to resist the urge to branch out into other areas too quickly. Instead, strictly focus on one business process or use case at a time. As an example, review the brief scenario below.
Scenario
At a medical supply company, the Regulatory Affairs and Quality Assurance (RAQA) Department needs to halt production whenever a technician detects a particular error for a customer who has had a recent complaint. In this scenario, we've named our Quality teammate Bill and our requirements gatherer Mary.
Mary: Now that we have established the expectations, Bill, please explain in brief what you'd like the system to do in this case.
Bill: Well, one of the hospitals we work with has recently issued several complaints for particulates in one of our products. I need to be able to stop the production line as soon as my team detects such an error.
Mary: OK. How is this detected on the production line?
Bill: In several ways; it may be noticed by an individual operator or the line inspector who reviews each item before it’s wrapped and sealed.
Mary: What should happen once the line is stopped?
Bill: Well, I need to be notified immediately.
Mary: OK, I've got that down. How do you want to be notified?
Bill: By email.
Mary: Is there anything else that needs to happen here?
Bill: No.
Mary: How will the line be cleared to start again?
As you can see in this scenario, Mary's questions have helped her frame what Bill needs. Her approach will allow her to review the steps and draft a specification with reasonable accuracy.
Another recommended best practice is to refrain from being satisfied with just surface answers. Dig down deep into the details until you have a clear picture of what’s needed. Don’t be afraid to ask questions. It’s better for you and your team to ask a question with a seemingly “knowable” answer than to make a wrong assumption unnecessarily.
4. Document & Review ERP Requirements
After you’ve reviewed the business processes and use cases your ERP system will be used for, it’s time to put the requirements in writing.
Once you put the requirements in writing, you or your technology consultant will often realize some elements need to be included. In addition, documenting the requirements may reveal additional questions you’ll need to answer to pass along a completed specification for the design and execution phases.
Lastly, review the documented requirements with your technology consultant before you approve them. Ask for clarity about any technical terms or assumptions that seem confusing or vague. To help prevent confusion at this critical juncture, a recommended best practice is to schedule a brief meeting with the team to review and discuss any questions. If this meeting goes smoothly, you can move on to the next phase. If it goes differently, and this isn’t uncommon, revise the document until your team is satisfied with the final specification.
How Forvis Mazars Can Help
Now that you know more about the art and science of ERP requirements gathering, how can we assist you? The Business Technology Solutions Team at Forvis Mazars is a Microsoft Dynamics Gold Partner and 2022–23 recipient of the Microsoft Inner Circle award. We provide analysis, design, implementation, upgrades, training, and support services for Business Central and other Microsoft Dynamics business applications. Use the Contact Us form below to get in touch.