What is a Requirements Definition? (ERP Best Practices)

So what is a requirements definition? In this video, I'm going to talk about what exactly it is, what goes into it, how do you do it, and how important it is in your E R P implementation. A requirements definition is just a comprehensive list of your requirements. It's as simple as that, but how do you find those requirements? I've seen clients have a 15 line e r p requirements definition, and that's not good enough. I've also seen clients with 3000 line items on every functional area that might be overkill. We have to find the sweet spot between how well your requirements are documented so that the vendors can then respond to your requirements in an efficient way and help you find the right product for your practice. So how do you do a requirements definition? It can be as simple as documenting your requirements on an Excel sheet, but you have to be really careful here.

Processes

You can't just say, I need a system that does accounts payable for us. Any system can do that, but what does that mean for your organization? What are the nuances of accounts payable at your organization or your city or county? What are the nuances of timekeeping in your organization? What policy decisions and local ordinances impact those requirements? You can't just say, I need a system to do checks for us. You need to really define what that means to see whether or not a system that's in the market can fit your needs. So the first thing to do again, is define your processes. Define your future processes. Document them, map them. And if you're using a tool like IBM's Blueworks Live, it can actually automate the process of at least starting on the requirements definition for you. At Avera, what we do is we run our clients through Processory design and visioning sessions, document those in a live environment in IBM's Blueworks Live.

Functions

And then as people are in these meetings looking at processes and how they're being changed and how it impacts our operations. Once that's finalized, you can then distill those automatically into requirements definition, at least a very basic one. These days, when we do requirements definition, we use IBM's Blueworks live to come up with the base level of requirements, and then we build on top of them using Excel. And when a finalized requirements definition is produced, it ends up being two to 3000 lines long and with multiple different tabs attached per functional area. So let's take an example of a financial system and the requirements definition associated with that. What do you think goes into a requirements definition and how would you break it down? So the first tab or function or component that we look at is general ledger. And keep in mind, as you're populating different areas of the requirements definition, you might end up populating some other areas as well, like general leisure.

It's well defined what goes into it. But as you're filling out, let's say an inventory line or a functional area of the requirements definition, you might find other things to put into the general leisure component. So think about a requirements definition document as broken down into functional areas that relate to finance or HR or payroll. You'll have general leisure. You'll have a tab for accounts payable, accounts receivable. You'll have requirements for human resource management, benefits administration, all of these different tabs within an Excel sheet or a Word document that helps you track what requirements must go into an A R P solicitation or an rfp. So the different components of a requirements definition follow closely with the different functional areas within your organization. And then there are specific items like it, security, cybersecurity, vpn securities requirements definition, who gets to see what part of the system.

Integrations

All of that needs to be included in this document. The other important element of a requirements definition is the integration requirements. When you buy an r P system, you need the system to talk to other elements of your IT organization. You might have a very specialized system in your organization that won't go away because how specialized it is, but it needs to be integrated with your E R P system. So you have to have a tab or a function within the requirements definition that specifically talks about which external systems they may be owned by you or by the state or by the county. Which systems does your E R P system need to interface with? And that needs to be clearly defined. Another important element is gis. How does GIS function within your organization? Is it a countywide initiative? Do you use the state system? Who feeds the data that goes into these layers? And how is your new E r P system going to consume this data in the gis? All of that needs to be documented and defined in a very specific way in your requirements definition. If you are in the process of defining requirements for your organization, that will then go into an rfp. Please get in touch with us if you need help coming up with a set of requirements that will protect you through the implementation and beyond.