Manufacturing Execution System (MES) Life Sciences projects can be costly and be a challenge to keep in control. The biggest contributor to these challenges are the defining and design of manufacturing workflows. A Workflow is an MES procedural object used to replace the paper batch record.
And for greenfield projects in particular, this can be a challenge. In order to define best practices for defining workflows, we should start by aligning on the objectives of workflows. In my opinion, workflows are used for the following purposes:
- Provide high-level guidance to an operator to perform a task, referencing the governing standard operating procedure (SOP)
- Recording data required by Good Manufacturing Practices (GMP) regulations (equipment, materials, sampling…)
- Error proofing production activities (Material Verification, Equipment Verification…)
- Presentation of data to the operator needed to perform a task
- Enforcing the appropriate sequencing of steps by the operator in a manual procedure
- Assuring the proper coordination of manual procedures with automated procedures performed by the process control system (PCS)
Some believe the use of workflows should obsolete the need for SOPs. This is often a debate and while there are no right and wrong answers, choosing to use workflows in place of SOP documents can result in higher costs and longer project schedules.
Why Defining Workflows is Challenging
Developing a workflow can be challenging because they must be developed based on specific directions from process engineers or process scientists. In a greenfield project, the specifics operating procedures of how equipment will be used may not be defined until later in a project. Different people may have different ideas about what should be contained in a workflow. A best practice is to develop a guideline for workflows documenting their purpose and the kinds of activities that will be performed (see bulleted items above).
Specification Documentation
How workflows are specified can also impact the cost and schedule of a project. Sometimes project teams debate if the specifications should be a Functional Specification (FS), Functional Design Specification (FDS), or a Configuration Specification (CS). The specification document name is not really too important, but the documentation philosophy is. There should be one lifecycle document. This may be called an FS, FDS, or CS depending upon the standards of the client. There should be one document developed and approved before design, implement, and test begins. This means there should not first be an FS document approved, then an FDS document approved for Design Qualification, then implementation.
My recommendation is that a single specification document be developed and upon its approval, design, implementation, and testing can be performed. In order to make this possible, there should be clarity between supplier and client on the objectives and content of the specification document. In my opinion, a workflow specification document must accomplish the following:
- A high-level description of the workflow, its purpose, and how it relates to the process.
- Define the steps a user will perform with the workflow including the actions the user must perform (scanning, data entry, selections, confirmations…)
- Define the specific sequencing of steps
- Define the verifications performed on each step and what occurs if a verification fails
- Define the integration points with other systems (LIMS, PCS, ERP…)
- Define the data needed to be transferred between systems
- Define the information the user will need to see on each step in order to accomplish the task requested by the step
- Define potential exceptions that are expected to occur during the performance of the workflow
- Define the data within the workflow that must be reported in the electronic batch record (EBR)
- Define signature requirements for each step
- Define the important parameters needed
- Contain detail needed for the user requirements specification (URS) trace matrix and for Design Qualification
A specification containing the above may not be so easy. However, I have found the use of work instruction display mock-ups accompanying procedure flow diagrams will drive the detail needed to accomplish the needed content. Developing a mock-up of each step, forces the consideration of the data needed for the workflow and provides an invaluable tool to collaborate with the process engineer or process scientist. This is almost like prototyping every workflow, but it can be done fast and by people who understand the process, but do not do system configuration.
The following figure is an example of a mock up on a workflow step that could be included as part of the workflow specification document. On my last project, all workflows in the project included this type of mock-up for all steps. This allows the client to understand specifically what will be developed and provides a good method for reviewing the workflow before development begins. I recommend these mock-ups are made part of the specification document and be approved by the client.
Alignment on the strategy for workflow specification should be accomplished during the front-end engineering design (FEED) phase of a project. A model specification for a workflow should be developed along with a prototype.
Summary of Workflow Specification Best Practices
In summary, the following items are suggested as best practices for developing workflow specifications:
- The supplier and client should develop alignment of the purpose of workflows and what kinds of information should be included. A design guideline document should be developed based on this alignment.
- During the FEED Phase a workflow prototype and model specification document should be developed.
- Careful consideration of cost and schedule should be made if the client wants to use workflows to replace SOP documents.
- Only a single specification document should be developed and approved before design, implementation, and testing begins. This document should be sufficient for Design Qualification, implementation, and test specification development. This document can be redlined as needed during implementation and reapproved before factory acceptance testing (FAT).
- Include work instruction mockups as part of the specification document.
From Jim: You can connect and interact with other MES, pharmaceutical and biotech experts in the Operations Management and Life Sciences groups in the Emerson Exchange 365 community.
