Scenario 72 - Request Corrective Action Plan

72.0 Overview

Scenario #72 describes the integration of business software supporting the process through which a Customer’s Quality Department is requesting corrective action as a result of repeated non-conformance reports sent to a Supplier. These are received by the Supplier’s corresponding Quality Department for their analysis. The review, analysis, and implementation of these corrective and preventive actions (typically known as ‘CAPA’) is the scope of this scenario

The purpose of this scenario is to describe the participants in a mainstream business process, and to illustrate how the business systems of those participants can be integrated through messages exchanged to realize the goals of that business process. This scenario is not meant to be the only model for integrating customer and supplier Quality Management System applications to address supply quality issues. It is simply one model that may be used to guide one’s own integration efforts.

Since the function and composition of business software components that might be used to produce or exchange the information described in the scenario vary widely, specific software components will not be described. Software components which might be involved in realizing this scenario include:

  • Enterprise Resource Planning Systems
    • Inventory Management
    • Receiving
    • Shipping
  • Quality Management Systems
  • Purchasing / Procurement
  • Lab Management Systems

This is not a complete list but is meant to be a representative sample of systems that might be involved in generation or exchange of the information involved in a supplier non-conformance corrective action process.

72.1 Scenario Diagram

The scenario below contains the participants involved in the interaction, the dialog flows or conversation between them, certain assumptions about the sequence of events, and assumptions about the technical approach.

This is a model to be used as a design recommendation, not a required approach.

72.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach with transaction management required but not explicitly defined.

This scenario describes how one or more of a Customer’s business systems can interact with one or more of the business systems of a Supplier to request corrective and preventative action. The environment for this integration may include a single external organization or several external organizations, although it is not depicted in our scenario. There may be instances where all of the data is contained in the documents and other instances where additional information accompanies the CorrectiveActionRequest, CorrectiveActionPlan, and CorrectiveAction documents.

The exchange of physical evidence related to the associated ItemNonconformance(s) and CorrectiveActionRequest is not depicted, but may be necessary in the scope of this business process. Similarly, verification that corrective actions are implemented properly and audit are referenced but not detailed in the exchange of the CorrectiveAction(s).

In some cases, there may be ‘corrections’ made to specific item instances to resolve the problem at hand. Examples of corrections include 100% inspection to sort the entire lot into good and non-conforming item instances, reclassification of the item instance to a different item, waiver of the non-conforming characteristic (or feature). Corrections are often made due to time pressures from operations in a Just-in-Time manufacturing setting. Corrections are not the same as Corrective Action(s), where the latter addresses future item instances.

Several potentially multi-step manual processes, such internal review of the request, development of the corrective action plan, and approvals of the plan and actions, are included in the diagram to provide a more complete illustration of the business process. By convention, these activities are depicted as messages that start and end at the same business process participant, and do not indicate that actual messages between systems need to be implemented for the processes to take place.

The diagram and descriptions of the business process for this scenario focus on how a successful execution of the business process should take place. There may be several places in this business process where corrective actions may begin to be implemented, but it is discovered that a better corrective action or a more preventative action can be taken. These activities may result in many additional or revised actions, and may require further approvals, funding, and modified timelines for implementation.

72.3 Participant Definitions

This scenario contains two major participants: the customer (CustomerParty) and the supplier (SupplierParty). The role of the QualityDepartment within the SupplierParty is also described in the Business Workflow section below. The definitions and details of the applications supporting these participants are left to the designer but are assumed to contain the functionality as defined by what is commonly sold in the commercial marketplace today. This definition is broadly accepted by the scenario designers and is a direct result of the decision not to define how the processing takes place within any individual application. Typical capabilities of these participants are described:

  • CustomerParty is the participant that receives the shipment, inspects the item, discover the repeated non-conformance, requests corrective action, and evaluates the proposed plans to correct the problem. In many organizations, the management of supplier quality is centralized, and may also include a Quality Review Board that includes procurement, engineering, manufacturing, inventory, and receiving departments.
  • SupplierParty receives the CustomerParty corrective action request, reviews the request, and determines how to respond to the CustomerParty. In many organizations, the management of finished goods quality is also centralized, and may also include a Quality Review Board that includes sales, engineering, manufacturing, inventory, and shipping departments.
  • The LabManagement participant uses an application often referred to as a Lab Information Management Systems (LIMS). LIMS will manage testing services, test methods, test specification, collect data off test instruments, and analyze the data and create the report of test results.

Each application must be able perform the services defined by the message BOD (business object document), but the internals of the application are not required or desired to be exposed at this level of standardized abstraction.

The most important factors in defining these participants is to ensure that an integration designer can communicate the requirements precisely enough to specify and design the integration processes needed and their interrelationships.

Note that the evolution of eCommerce has yielded independent trading exchanges and other intermediaries between business operations and inventory management providers. Requirements and operations for intermediaries should be similar to direct links between the two components

72.4 Business Workflow (Sequence)

The business workflow is graphically represented by starting at the Scenario top and reading from top down and from left to right. The arrows in a sequence diagrams shows the message exchanged, and the response to the message. A ConfirmBOD provides an acknowledge to the initial request that the original request was received and understood as a valid. The Acknowledge(noun) message indicates that the transaction was processed (committed), and a business person has reviewed and provided information related to the next step (accepted, rejected, etc.).

The exchange of OAGIS BODs such as the ItemNonconformance, CorrectiveActionRequest, CorrectiveActionPlan, and CorrectiveAction may follow several different workflows, depending on if the use case fits within discrete manufacturing (e.g., electronics) or process manufacturing (e.g., animal or human food), and if other issues or opportunities are discovered in the process of implementing a corrective action. The process also depends on the type of product or products involved and the entities exchanging the documents.

The sequence diagram illustrates the data exchanges involved within the business process, following these steps:

  1. This integration scenario begins with the shipment notice from the SupplierParty to the CustomerParty and receipt of the product. A NotifyShipment BOD is used to convey this message in this integration.
  2. Internally, CustomerParty inspects the product and finds the product does not meet specification, and notifies the SupplierParty. A ProcessItemNonconformance BOD is used to convey this message in this integration.
  3. SupplierParty-Quality Department receives the non-conformance report and sends an acknowledgement to the CustomerParty, and because this is a repeated occurrence (not shown here) authorizes return of the product. An AcknowledgeItemNonconformance BOD is used to convey this message.
  4. The shipment is returned to the vendor (RTV). No OAGIS BOD message is used to convey information for the RTV.
  5. CustomerParty then requests a corrective action plan from the SupplierParty. A ProcessCorrectiveActionRequest BOD is used to convey this message.
  6. The SupplierParty receives the request and determines if it will create a plan and when it expects the plan to be completed. An AcknowledgeCorrectiveActionRequest BOD is used to convey this status and schedule information.
  7. The SupplierParty meets internally (likely by a Quality Review Board) to formulate a plan to provide to the CustomerParty, ideally by the requested date.
  8. After a period of time, the SupplierParty provides a corrective action plan that details the list of actions (one to many) they plan to take to correct the problem. A ProcessCorrectiveActionPlan BOD is used to convey this message.
  9. The CustomerParty reviews the plan internally (likely by a Quality Review Board), and determines if the plan meets their objectives and timelines. An AcknowledgeCorrectiveActionPlan BOD is used to convey this message, which could communicate acceptance or rejection of the plan. If the plan is rejected, this cycle could iterate until an agreeable plan is achieved.
  10. SupplierParty-Quality Department will send information when a specific corrective action referenced in the plan has been scheduled, initiated, and completed. There may be additional actions identified in the course of the implementation of an action, where a better approach may supercede a prior action (and referenced accordingly), or supercede an action already implemented. A ProcessCorrectiveAction BOD is used to convey this message.
  11. The CustomerParty will review these corrective action(s), and determine if they need to be verified through a supplier audit usually through a site/facility visit to determine if the action was actually completed, and if so, whether the action was effective (often through sharing of statistical reports). There is no OAGIS BOD communication during this process.
  12. On acceptance or rejection of each corrective action, the CustomerParty will notify the SupplierParty of the disposition of the action using an AcknowledgeCorrectiveAction BOD.

72.5 Exception Handling

Exception handling is highly localized as the result of how business capabilities are implemented including the deployed infrastructure, management and business rules. As such, this section of the Scenario documentation is planned to be used as a guide to help understand the additional intent of these Scenarios. If no exceptions are noted here, then it can be assumed that the Scenario designers agreed that the Scenario is straightforward and has no additional needs:

  • The Confirm BOD is typically intended to be used by the original receiving application to communicate to the sending application that the information it sent in the message BOD (business object document) was received and understood and can be processed.

  • If the information was not received or understood, or contained errors of any type, it is accepted practice for the OAGIS users to presume that the data was not acted on.

  • In the absence of a Confirm BOD within a previously agreed time limit (e.g., SLA, normally defined in an out-of-band agreement), the originator will resend the original message.

  • As errors and assumptions are the bane of any implementation, it is strongly recommended that the Confirm BOD be used to prevent any potential problem although it is not a requirement by OAGIS use.


OAGi and its members welcome your feedback.