The Importance of Documenting Enterprise QMS Process Requirements

You’re in the market to build a new house. Would you tell the builder what you’re looking for or would you just tell them to build “something”? If the latter, what’s the likelihood that the house you end up with is going to be what you want? Documenting your requirements should be obvious, right?

Software Functionality vs. Business Requirements

Sometimes it’s not so obvious when it comes to the purchase and implementation of enterprise QMS software. I use the house analogy quite often, partly because I’m a home do-it-yourself’er, but mostly because it’s true. You might be amazed at the number of organizations that come to the table with little-to-no documented process requirements. Many will have high-level RFP type requirements, for example, “the system must be accessible via an Internet browser.” In fact, the RFP will have 50-60 pages of these types of things. However, in terms of actual functional business process requirements, many times they’re lacking.

Make Business Process Requirements a Priority

Documenting actual business process requirements is the single most critical activity of any successful enterprise software implementation. These requirements will drive the purchase of the correct solution through the actual implementation. When evaluating vendors, if you don’t have written requirements to help in your review, be wary. The sales representative might try to blind you with all of the shiny things their software does — but not the things you need. Whether any of that shine will add any value to your business is questionable. And whether a vendor can actually “make it shine” is another question.

When the time for implementation comes, if you don’t have a list of what you need it to do, it becomes ad-hoc. If I go back to the original analogy, this is the same as building a house without a blueprint.

Now that I’ve hopefully impressed upon you the importance of business requirements, just how do we go about collecting them? There are a couple of techniques that I’ve used in the past that have been successful.

Build the Right Team

The first thing to do is to make sure that you include the right people. This comprises of people from the executive level who might have reporting requirements, department managers responsible for the activities the software is supposed to address, and people doing the data entry. Review our blog “Avoid QMS Automation Failures with the Right Implementation Team” for best practices.

Divorce your Existing System

The second thing is to divorce yourself from any existing software system. If you’re implementing a new document management system and you currently have an existing one, don’t base your requirements off what the old system does. Remember, there’s a reason you’re moving away from it. Cherry-picking some of the good things that the system does is fine, but focus more on what you need rather than on what any system does.

Define your Needs for Enterprise QMS Business Processes

One method for documenting enterprise QMS business processes is the brainstorming method. Everyone gets into a room with several packs of sticky notes.  Then everyone just starts writing down what they want the system to do. Now start putting them up on the wall. You can move them around and easily decide which are really needed. This might seem old-school and low tech, but it works.

The method I use most often is to start by drawing out a high-level workflow, either on a whiteboard or in Visio. Once you have the high-level steps of what your process needs, you can start to drill down into each one to add detail to the workflow. At the end, you’ll have a detailed diagram that has each step of the process mapped out. It will be inclusive of data entry, the delegation of work, people involved in each step, decision points, approvals, and completion. Using this diagram, you will be able to discuss data requirements and business logic.

Instead of trying to map out all processes at once, define the most critical processes to address first.

Consider Reporting Requirements

The other component to consider is reporting. What sort of reports or metrics are important to your business? These requirements should include enough detail to be able to determine what data is needed to support the report. As a result, you can include these data requirements in the overall data inputs for the system.

Don’t Make Assumptions

Another point — do not assume. Do not simply assume that an enterprise software system will do something. If you have a requirement for specific functionality, then document it. I have been involved in several implementations where we met all the requirements that were asked for. However, when we turned it over to the customer they were disappointed that it didn’t also address some other things they had in mind. Unspoken expectations are the hardest to meet.

Focus on What You Need, not How it Works

Lastly, do not focus your requirements on the “how.” What I mean by this is don’t try to design the system.  Instead, focus on the “what.” What do you need? What does the business need in order to function and ensure that you’re addressing the problems that the software is supposed to help solve? Let the software vendor worry about how to meet those requirements. It will obviously be up to you to decide whether the solution is able to efficiently meet those requirements, but it is the vendor’s responsibility to deliver a quality management system that addresses the “what.”

Conclusion

Collecting and documenting requirements is not fun and no one really likes to do it, but it’s critical. The more information that you can collect on your business processes, the better the chances you have for, first, selecting the right EQMS and, second, smoothly implementing the software. So, do your homework.  You will thank me later!