Featured Product
This Week in Quality Digest Live
Health Care Features
John Colmers
Maryland’s innovative and sound approach could be the solution for rescuing systems nationwide
Dawn Bailey
A legacy of forward thinking kept medical center on its award-winning path
Rich Tree
Management teams must shift their focus from a process qualification milestone to an operational readiness milestone
Dirk Dusharme @ Quality Digest
At the top of the list: Trust
Jay Arthur—The KnowWare Man
Trend rules are helpful in service industries but you need to know which one to use

More Features

Health Care News
The tabletop diagnostic yields results in an hour and can be programmed to detect variants of the SARS-CoV-2 virus
First Responder UAS Triple Challenge focuses on using optical sensors and data analysis to improve image detection and location
Free education source for global medical device community
Extended validation of Thermo Scientific Salmonella Precis Method simplifies workflows and encompasses challenging food matrices
‘Completely new diagnostic platform’ could prove to be a valuable clinical tool for detecting exposure to multiple viruses
Provides improved thermal stability for stored materials, risk mitigation advantages, and processes that are documented and repeatable
Patient safety is a key focus in update of ISO 14155, the industry reference for good practice in clinical trials.
Despite being far from campus because of the pandemic, some students are engineering a creative way to stay connected
Good quality is adding an average of 11 percent to organizations’ revenue growth

More News

Eric Cooper

Health Care

The Importance of Documenting Enterprise QMS Process Requirements

Unspoken expectations are the hardest to meet

Published: Monday, January 29, 2018 - 12:00

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 him 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-yourselfer, 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, request for proposal (RFP)-type requirements—for example, “The system must be accessible via an internet browser.” In fact, the RFP will have 50 to 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 entire process, from purchase of the correct solution to 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 the shiny things the software does—but not the things you need. Whether any of that shine will add 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 the software 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 on you the importance of business requirements, just how do we go about collecting them? There are a couple of techniques 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. The team should comprise 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 white board 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 include data entry, delegation of work, people involved in each step, decision points, approvals, and completion. By 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 so you can determine what data are 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 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 on 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 about 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!

Discuss

About The Author

Eric Cooper’s picture

Eric Cooper

Eric Cooper is the director of professional services at AssurX.