SOPs, Work Instructions, and User Guides: Enterprise Systems

When you’ve expended resources selecting, defining, implementing, and testing an enterprise system, surely you’d want to make sure users are using it in the manner in which it was designed. This ensures consistency of use, data integrity, and increases the reliability of the system and associated data.

How do you make sure this is done? By providing users with standard operating procedures, work instructions and user guides.

For controlled systems (SOX, GxP validated), these are essential for establishing and maintaining control beginning with IT related system procedures (as I wrote about in IT SOPs for Controlled Systems in Life Sciences) all the way down to end user instructions that may be referred to as work instructions, user guides, or desktop instructions.

I recommend that these be drafted prior to acceptance or integrated testing so that the procedures and work instructions can be verified during testing. After testing, they are updated to reflect any required changes resulting from testing, and provided to end users during training. Prior to Go Live, they should be finalized, approved (if required), and stored in a user-accessible, centralized location.

How these are constructed really depends on the system and the users. Sometimes I will put in an entire business process into a single work instruction even if there are different users / user groups performing tasks. For example, in an ERP system, vendor maintenance tasks are typically assigned to users in purchasing or procurement with approvals by the Controller or Accounting Manager. It’s simpler to include the entire process in a single work instruction or procedure.

Other times, I will create separate procedures or work instructions for user groups that perform tasks in a larger business process. For example, in an ERP/MRP system, the process from requisition to payment (the Procure to Pay process) are separated into individual instructions for requisition creation, requistion approval, PO creation, receiving, AP invoice entry, AP invoice approval, and AP payments.

While this may appear to be a burdensome task to a project team, and getting end users to adhere to the work instructions and procedures may be challenging, it’s all worth the effort of ensuring consistent use of the system and data reliability.

Who creates: the internal Business Analyst, assuming there’s one on the project team. If not, these should be assigned to the functional leads responsible for the business processes. For system administration procedures and instructions, the internal administrator should be assigned. Note: these are client documents and should not be left to the implementation partner to create.

Who approves: for controlled systems (SOX, GxP), approvals are generally required. For others, it depends on internal business process requirements and what was defined in the Project Document. Systems subject to SOX have documents that are approved by the functional leads and Business Sponsor. Validated system (GxP) documents are approved by functional leads, the Business Sponsor, and QA in alignment with document control procedures.

When: these should be drafted prior to integrated or end user testing, confirmed during testing, and finalized / approved prior to Go Live.

What’s Included

Purpose: defines what is included in the document and why the document exists.

Scope: details what is and is not within the scope of the document and for the most part, what is in and out of scope for the system, too.

Document owner: specifies who is responsible for ensuring that the document is maintained and updated for the life of the system, and in most cases, who is responsible for the business process contained within the procedure/instruction document.

Applies to: list who has tasks within the work instruction or who is responsible for adhering to the procedure. Note: this can be included in a Responsibilities section.

Related documents or references: if other documents are referenced in the document, include in this section. Then, when changes are made, it is easier to identify what other documents may need to be updated as well.

Process flows: if the procedure or work instruction is part of a larger business process flow that may be used in other documents, include the reference in this section and include the process flow at the end of the document. Process flows are a great way to provide a visual to end users on the overall business process and how the tasks or activities fit into the overall flows.

General notes: I like to see assumptions and context provided for all project and system documents to provide readers / consumers with a complete picture of the document, the scope, and it’s purpose. This is the section for all of this and for anything that may provide greater clarity, assuming it’s not captured elsewhere in the document.

Procedure steps or instructions: include sufficient detail (with screenshots if they would be helpful), so the user / reader can follow the process or perform the specific tasks or activities. Include additional notes to provide clarity. Note: for GxP validated systems, failure to follow the procedure or instructions could result in a deviation or discrepancy so proper construction of the procedure or instruction is important.

Other Things to Note

The format will depend on what is required by the company and what makes sense for the system and end users. For less controlled systems, the documents may be more informal. For GxP validated systems, we always have to comply with the company’s document control / management SOPs.

These should be revisited 3–6 months after implementation to review for changes in business practices and/or actual use of the system. If there are areas where users are consistently having issues, the procedures or instructions should be updated to provide additional guidance or clarity.

As the system is updated and/or changed, the procedures and/or work instructions may need to be updated to reflect the changes.

As the procedures and instructions are updated and revised, end users should be notified, and possibly trained, on the new processes or instructions.

How long are these documents? Each document should be long enough to provide sufficient guidance and instruction to effectively adhere to the procedures and for end users to execute the processes in the system.

Why Share This Now?

Back when I was an accountant, working for my dad’s accounting firm, we had a lot of small businesses as clients. The owners of the small businesses struggled with basic bookkeeping and accounting which meant that we couldn’t add value to them and their businesses because we were so focused on the fundamentals. We created a few accounting classes for them in the form of Accounting 101, 102, 201, and 202 so we could do more with them.

I’m applying the same principles here. If I can help my clients (prospective or current) help themselves with projects and project deliverables, then I get to elevate my role beyond the day-to-day and into a strategic and advisory role which, frankly, is a lot more fun!

Check out my blog post Project Deliverables: Enterprise Systems for the complete list of deliverables with links other blog posts.

Have Questions or Require Assistance?

Feel free to reach out to Terri with any questions you might have via email at terri.mead@solutions2projects.com or through the company website SolutionsProjects, LLC.

About the Author

Terri Hanson Mead, MBA, PMP, is a technology and compliance strategist for biotech, pharma, medical device, diagnostic, and digital health companies. Through her company, Solutions2Projects, she helps life sciences companies align technology roadmaps with corporate objectives and meet IT compliance requirements in a complex and regulated industry. As an expert witness, Terri provides pre-litigation consulting and expert witness services for failed technology projects, including enterprise systems.