Quality Notification CAPA

There are many existing SAP sites that are doing Defects Recording but only
a few that are really using the full closed loop functionality (Defect
Locations, Tasks, Causes and Activities). The key to the Quality
Notifications are to correct processes that are out of control or are trending
in that direction. When companies only use the Defect portion they can
only do defect reporting which might look good for meetings and graphs but
it does nothing to ensure the defects/issues do not occur again. So in most
cases the sites are entering defects in SAP but are also still using the manual
or non integrated corrective action systems. So they never really reap the
full benefits of SAP Quality Notifications.

The actual CAPA processes are in most cases complex, involving many
people. Their current processes involve a lot of e-mails and phone calls to
try to ensure the processes are followed through. But these types of
systems inherently are flawed with a lot of loose ends that do not get
filled. Consequently the same types of defects/issues reoccur because of
poor follow through.

When using the full SAP QM Quality Notification functionality you can
ensure the notification is not closed out until all the corrective actions have
been performed and the approvers are satisfied with the results. Also, all
the processes are tightly integrated with the rest of the SAP system. For
example, if a defect is recorded against a material received from a vendor
then the notification has the key purchase order information linked to the
notification.

Following is an example of a full QM Quality Notification lifecycle:

1. Defect is identified, can come from various sources:

• Customer Complaints
• Internal Unplanned Deviations
• External Unplanned Deviations
• Customer Audits
• Vendor Audits
• Internal Audits
• Annual Product Reviews
• Quality Out of Specifications
• Trending Analysis
2. User enters the defect information into SAP Quality Notification
summary screen. The end user needs to provide the details of the
incident.
 3. Notification Coordinator is monitoring existing and new notifications,
they see the new notification
4. Notification Coordinator does an immediate assessment to determine
what type of action needs to be taken. Also, they fill out more of the
notification from the entered summary information:
α. Priority
β . Defect codes
χ . Defect Locations
δ . Contact Persons
2. If the defect requires corrective action then the Notification
Coordinator assigns Tasks to applicable departments that need to
investigate. These tasks will have due dates which will help the
departments manage their work load.
3. The departments are running the Notification Tasks Work List
periodically throughout the day. When they find a new task they set
its status to “In Process” and assign it to a person.
4. As each task is complete the department will enter what they found
during their investigation into long text and set the task User Status
to Complete.
5. The Notification Coordinator is monitoring tasks that are complete.
When they pick up the task they will look for completeness, if it is
not complete they will set the User Status to “Rework” and push it
back to the department. If it is complete they will set the task
System Status to “Complete”.
6. The Notification Coordinator reads the long text and extracts the
Root Cause information. Also, the Activities that were performed to
correct the process are identified. This information is translated into
Catalog Codes so the information can be reported against for trending
analysis.
7. If the immediate problem has been fixed but their needs to be a long
term investigation, the Notification Coordinator can open up a Long
Term Notification that is linked to the initial notification. This allows
the initial notification to be closed but the Long Term can now be
managed separately, which may involve a different group.
8. When all the tasks for a notification have been completed and the
Notification Coordinator is satisfied, the coordinator will send a Task
to the Approver for final review and closure.
9. The Approver periodically through the day runs the Task Work List to
see if there are new task for notification review. When satisfied they
will set the notification to “Closed”.
This is just one example of a full SAP Quality Notification lifecycle. SAP
Quality Notifications has a lot of flexibility to meet various business models.
In most cases it is the Change Management piece that is the hardest part of
the implementation, not the SAP notification functionality. Because CAPA
systems touch so many people and business scenarios within a company it is
a big stretch to get them to all commit to the new processes. So we manage
early on the Change Management portion to ensure everyone is on board
and the proper amount of training has been planned for.

It is crucial to have the right person on board to design and implement SAP
Quality Notifications to meet the business requirements and to ensure
successful project lifecycle management.