Managing workflows performed by a product recall management system

Abstract

Example techniques for managing workflows executed by a product recall management system (PRMS) are described. Relevance information associated with a first step of a workflow for a product recall is retrieved. The first step includes a first action item to be performed by a first user, and the relevance information identifies a second action item associated with a second step of the workflow, initiation of performance of the second action item dependent on completion of performance of the first action item. A visual indicator depicting a logical association of the second action item pending to the first action item pending is presented to the first user based on the relevance information. States of the first step and the second step are determined based on performance of the respective action items. If the state of the first step is pending, a schedule of completion of performance of the first action item is generated based on a scheduled completion date of the recall, and the schedule is depicted to the first user through the visual indicator.

Description

Background Technology

[0001] A wide variety of products are manufactured, including medical devices, consumables, automobiles, toys, food, pharmaceuticals, and various types of equipment, for distribution to the consumer market. These products are designed to serve a variety of purposes and are expected to meet safety standards for consumer use. The manufacturing process for these products is typically predefined and may involve several stages, including production, testing, and post-manufacturing activities such as packaging and distribution. To ensure the intended quality of the products, each activity within these stages is performed according to Standard Operating Procedures (SOPs). For example, an SOP might specify testing parameters for a medical device or storage conditions for a pharmaceutical ingredient.

[0002] Despite these precautions, there may still be situations where a product is found to be unsafe after it has been provided to consumers. Such safety issues may stem from design flaws, manufacturing defects, or the unintentional use of hazardous substances. When faced with these problems, the product manufacturer may be obligated to take corrective action, which may include initiating a voluntary recall or complying with mandatory recalls required by regulatory agencies.

[0003] The recall process for affected products can be complex, requiring communication with stakeholders (including recipients) to facilitate product returns, coordinate product returns, disseminate information, and provide support to consumers. Financial and operational costs can be substantial, including recall execution, refunds, and compensation. Furthermore, recall decisions can have lasting impacts on the reputation of the manufacturer of the recalled product and on consumer trust. Therefore, managing recalls according to appropriate, predefined processes that comply with regulatory requirements and optimize communication efficiency is crucial.

[0004] Manufacturers can use a Product Recall Management System (PRMS) to effectively manage the product recall process, streamline communication, and ensure compliance with regulatory requirements. Summary of the Invention

[0005] This document describes systems, methods, and various implementations on nontransitory computer-readable media for managing workflows executed by a product recall management system.

[0006] Details of some embodiments of the subject matter described in this specification are set forth in the following drawings and description. Other features, aspects, and advantages of the subject matter will be apparent from the description, drawings, and claims.

[0007] According to an embodiment of this subject matter, a system for managing workflows executed by a Product Recall Management System (PRMS) is provided. The system includes a processor. For a workflow comprising one or more steps of a product recall process executable by the PRMS, the processor retrieves relevance information associated with a first step among the one or more steps. Each of the one or more steps includes an action item to be performed by a corresponding user. The relevance information identifies an action item associated with a second step among the one or more steps, the initiation of which will be triggered upon completion of the action item associated with the first step. The processor displays a visual indicator to the authorized user of the first step based on the relevance information. The visual indicator depicts the logical association between the pending action item associated with the second step and the pending action item associated with the first step. The processor determines the status of the first step and the second step based on the execution of the action item associated with the corresponding step. When the status of the first step is determined to be pending, the processor generates a completion schedule for the execution of the action item associated with the first step based on a predefined completion schedule for the execution of the action item associated with the second step. The visual indicator shows the generated schedule to the authorized user in the first step.

[0008] According to an embodiment of this subject matter, a method for managing workflows executed by a Product Recall Management System (PRMS) is provided. According to this method, relevance information associated with a first step of a workflow capable of executing a product collection recall is retrieved. The first step includes a first action item to be performed by a first user, and the relevance information identifies a second action item associated with a second step of the workflow, the initiation of which is triggered upon completion of the first action. A visual indicator is presented to the first user based on the relevance information. The visual indicator depicts the logical association between the pending status of the second action item and the pending status of the first action item. The status of the first step and the second step are determined based on the execution of the first and second action items, respectively. Finally, when the status of the first step is determined to be pending, a completion schedule for the execution of the first action item is generated based on the planned completion date of the product collection recall, wherein the visual indicator is used to depict the generated schedule to the first user.

[0009] According to another embodiment of this subject matter, a non-transitory computer-readable medium is provided, comprising instructions executable by a processing resource to manage a workflow executed by a Product Recall Management System (PRMS). Upon execution, the instructions cause the processing resource to obtain relevance information associated with a first step of a workflow capable of executing a product recall. This relevance information indicates that the execution of at least one action associated with a second step of the workflow will be triggered upon completion of the execution of at least one action associated with the first step. The instructions may also cause the processing resource to provide a visual indicator to an authorized user of the first step based on the relevance information. The visual indicator depicts the dependency of the execution of the at least one action associated with the second step on the execution of the at least one action associated with the first step. The instructions may also cause the processing resource to determine the status of the first and second steps based on the execution of the at least one action associated with the corresponding step by the corresponding authorized user. When the status of the first step is determined to be pending, the instructions may cause the processing resource to generate a completion schedule for the execution of the at least one action associated with the first step based on the planned completion date of the product recall. The visual indicator shows the generated schedule to the authorized user in the first step.

[0010] Based on the examples in this topic, the technology described herein for managing workflows executed by a Product Recall Management System (PRMS) indicates to users working on the PRMS how their current actions affect subsequent steps in the workflow and provides a clear timeline for the completion of the steps they are responsible for performing, based on the needs of subsequent dependent steps. It provides users with a clear indication of which steps will be blocked until the current step is completed. By providing this level of visibility and planning, effective coordination among users working on the PRMS is ensured. This also allows for the timely initiation of subsequent steps and facilitates the smooth, synchronized execution of the entire recall workflow. Therefore, the technology described herein minimizes delays and enhances the overall effectiveness of the product recall process. Attached Figure Description

[0011] The following detailed description refers to the accompanying drawings, in which:

[0012] Figure 1 An example network environment for implementing an example technique for managing workflows executed by a product recall management system, according to an exemplary embodiment of the present invention, is illustrated.

[0013] Figure 2 An example embodiment of the present invention illustrates a system for managing workflows executed by a PRMS;

[0014] Figure 3 An example of a system for managing workflows executed by PRMS, according to another embodiment of the invention, is illustrated;

[0015] Figure 4 An example user interface rendered by a system for managing workflows executed by PRMS is illustrated according to an exemplary embodiment of the present invention;

[0016] Figure 5A and Figure 5B Another example user interface rendered by a system for managing workflows executed by PRMS, according to an example of the present invention, is illustrated.

[0017] Figure 6 An example of a method for managing workflows executed by PRMS, specifically implemented according to another embodiment of the invention, is illustrated;

[0018] Figure 7 An example of a method for managing workflows executed by PRMS, specifically implemented according to another embodiment of the invention, is illustrated;

[0019] Figure 8 An example of a method for managing workflows executed by PRMS, specifically implemented according to another embodiment of the invention, is illustrated; and

[0020] Figure 9 An example implementation of the present invention illustrates a computing environment for managing workflows executed by PRMS.

[0021] In the accompanying drawings, the leftmost numeral of the reference numeral indicates the first drawing in which that reference numeral appears. The same numerals are used throughout the drawings to refer to the same features and parts. Detailed Implementation

[0022] Manufacturers may recall products or batches for a variety of reasons, including identifying safety issues or product anomalies that could harm consumers or subject the manufacturer to legal liability. Occasionally, recalls may also be initiated due to changes in regulations, rendering previously compliant products non-compliant. The purpose of a recall is to address these issues by removing affected products from the market or by correcting identified anomalies.

[0023] Manufacturers rely on PRMS to facilitate the recall process. A PRMS is a specialized tool designed to streamline the process of recalling products or batches of products from the market. As mentioned above, through the recall process, manufacturers remove defective, hazardous, or non-compliant products from the market to protect consumers from potential harm, comply with regulatory requirements, and mitigate liability risks. The recall process may vary depending on the industry and the severity of the problem associated with the defective product, but it typically involves identifying the problem associated with the product, notifying regulatory agencies or departments, identifying the affected products, regions, and consumers, developing strategies for communicating with stakeholders and taking corrective actions (e.g., refunds, replacements, and compensation), communicating with stakeholders, including recipients, and executing the recall. Therefore, the recall process involves the execution of complex workflows. These workflows can be implemented in multiple stages, and each stage of the workflow includes several interrelated steps. For example, a PRMS may include two main subsystems: a recall decision subsystem and a recall execution subsystem. The recall decision subsystem may be assigned the task of assessing the initial phase of whether to initiate a recall of a product or batch of products. The recall decision-making subsystem employs a workflow that provides the means for collecting data, conducting risk analysis, and supporting decision-making regarding product recalls. On the other hand, the recall execution subsystem is configured to implement the recall once a decision has been made, providing workflows and tools for doing so.

[0024] Each stage or step of the workflow can be handled by an authorized person, whose role can be based on predefined rules. PRMS is implemented to execute such complex workflows, where each step or sub-step requires precise validation by the appropriate authorized person. For example, a business administrator might be responsible for application configurations such as user management, role management, threshold configuration, and data source configuration; a Recall Project Manager (RPM) might be responsible for project management related to recall decisions, investigations, and execution. Process owners and quality managers can conduct scientific investigations and evaluations, and the execution manager can approve or reject based on the work done by other personnel.

[0025] Conventional PRMS systems allow multiple users to execute steps concurrently, accelerating the process rather than executing them sequentially, which can potentially delay workflows. However, situations may arise where the execution of a step depends on the completion of another step in the same or a different phase of the workflow. For example, a recall decision subsystem conducts a risk investigation to assess the severity and scope of an anomaly, and if a recall is required, it triggers the recall execution subsystem. More specifically, the outcome of the product recall approval / rejection step in the investigation phase of a workflow executed by the recall decision subsystem initiates a step in the recall execution phase of the workflow executed by the recall execution subsystem. Conventional PRMS systems do not provide authorized users executing workflow steps with indications of the interdependencies between different steps in the workflow. In such cases, users executing steps that depend on another step, or steps on which another step depends, cannot see where the bottleneck is. Consequently, workflow execution is delayed. This lack of synchronization in workflow execution can potentially lead to undesirable consequences, such as inefficiency in the PRMS's recall process.

[0026] Furthermore, conventional PRMS systems do not provide authorized users executing workflow steps with indications of how long it might take for them to perform the current step. For example, if user A knows they are blocking user B, user A might expedite the execution of the step that is blocking user B's responsibility. Unless A knows the planned completion date of the step to be executed, user A may not prioritize such execution, and product recalls may be delayed. Recall decisions can have lasting impacts on the reputation of the manufacturer of the recalled product and on consumer trust. Therefore, timely management of product recalls is crucial.

[0027] Based on specific implementation examples in this topic, techniques for managing workflows executed by PRMS are described. Example methods and systems for managing workflows executed by PRMS provide an efficient recall process by improving synchronization during the execution of related steps in the workflow.

[0028] According to the example implementation of this topic, PRMS can execute a workflow corresponding to a product recall process. The workflow includes one or more steps in the recall process. Each of these steps may include action items to be performed by a corresponding authorized user. These action items may be specific tasks or activities assigned to the authorized user within the corresponding step during the completion of the product recall process. In the example, action items may include assigning roles to various users (such as process owners or quality managers) and collecting detailed manufacturing data about the product, such as batch number, production date, raw material source, and recipient location. As mentioned above, one or more steps may be executed in a predefined order, and the execution of action items associated with a step in one or more steps may depend on the execution of action items associated with one or more related steps in the workflow. Relevance information may be associated with each step of the workflow to identify action items associated with a step whose execution depends on the execution of another action item associated with another related step.

[0029] In the implementation scheme, relevance information associated with a first step in one or more steps is retrieved according to the technology used to manage the workflow executed by the PRMS. This relevance information identifies an action item associated with a second step in the one or more steps, the initiation of which will be triggered upon completion of the action item associated with the first step.

[0030] In the example implementation, a visual indicator is presented to the authorized user of the first step based on relevance information. This visual indicator depicts the logical association between the pending action item associated with the second step and the pending action item associated with the first step. In the example, a block diagram representing the workflow steps as boxes can be displayed to the authorized user on the user interface. The visual indicator can be represented as a directional arrow between the boxes representing the first and second steps, with the arrow pointing towards the box representing the second step.

[0031] Furthermore, the status of the first and second steps is determined based on the execution of actions associated with the corresponding steps. In the example, the status of a step may be determined based on variable parameters or attribute values ​​that may change due to the execution of actions associated with that step. If the status of the first step is determined to be pending, a completion schedule for the execution of actions associated with the first step is generated based on a predefined completion schedule for the execution of actions associated with the second step. The visual indicator displays the generated schedule to the authorized user of the first step.

[0032] A visual indicator depicting the pending actions of the first step relative to the related second step provides the authorized user of the first step with visibility into which steps are blocked due to the execution of the first step. The indicator also depicts a schedule for the user of the first step based on a predefined schedule of the blocked second steps. Accordingly, the authorized user of the first step knows that the second step is blocked and is scheduled to complete on a date of XYZ, allowing the user to expedite the execution of the first step. This allows for the timely initiation of the blocked second step after the previous first step has been executed according to the generated schedule. Therefore, the synchronization provided between related steps ensures a timely, smooth, and efficient workflow execution.

[0033] refer to Figures 1 to 9 The above-described techniques are further described below. It should be noted that the specification and drawings are merely illustrative of the principles of the invention in conjunction with the examples described herein and should not be construed as limiting the invention. Therefore, it should be understood that various arrangements embodying the principles of the invention can be designed, although not explicitly described or shown herein. Furthermore, all statements herein recounting the principles, aspects, and specific embodiments of the subject matter, and their specific examples, are intended to cover their equivalents.

[0034] Figure 1 An example network environment for implementing an example technology for managing workflows performed by PRMS, according to an exemplary embodiment of the present invention, is illustrated.

[0035] Recall processes are implemented across a variety of industries, including automotive, pharmaceutical, consumer goods, electronics, and food manufacturing, to ensure consumer safety and compliance with regulatory standards. Recalls may be initiated for a range of reasons, including but not limited to safety concerns posing a risk to consumers, product performance issues that do not meet manufacturer specifications (such as functional or durability problems), potential contamination in food or pharmaceuticals, the use of non-compliant materials in the manufacturing process, or newly identified adverse reactions in medical devices or pharmaceuticals. In some cases, a recall may be a preventative measure in response to potential risks identified through post-market surveillance, even if no adverse events are reported. Regulatory agencies may also enforce recalls based on their own investigations or reports from consumers, healthcare providers, or other stakeholders in the supply chain.

[0036] Recall processes typically involve additional requirements such as timely response and minimizing negative impacts on the manufacturer's reputation and finances. Because products that may be recalled are designed for a wide variety of uses, the criteria and urgency of recalls vary considerably to address the corresponding safety and compliance issues associated with each type of product. Product recall management systems are tools used to streamline the recall process for products found to be defective, such as those due to anomalies or non-compliance with regulatory guidelines. In many cases, these systems are designed to align with and enforce recall-specific Standard Operating Procedures (SOPs). SOPs outline step-by-step instructions for initiating, executing, and documenting recalls, ensuring consistency and compliance across different recall scenarios.

[0037] In an exemplary implementation of this subject matter, network environment 100 includes a Product Recall Management System (PRMS) 102. In this implementation, PRMS 102 may be implemented and operated by the product manufacturer to manage recall instances of products manufactured by the manufacturer. PRMS 102 may be any computing device, such as a server, desktop computer, laptop computer, smartphone, or tablet computer. PRMS 102 may include one or more processors for executing instructions to implement a process for recalling products. In this example, the processor may be implemented as a microprocessor, microcomputer, microcontroller, digital signal processor, central processing unit, state machine, logic circuit system, and / or any means of manipulating signals based on operating instructions. PRMS 102 may include memory for storing instructions executable by one or more processors. The instructions may cause the processor to perform the product recall process. The memory may include any computer-readable medium known in the art, including, for example, volatile memory (e.g., RAM) and / or non-volatile memory (e.g., EPROM, flash memory, etc.). The memory may also be an external memory unit, such as a flash drive, optical disc drive, external hard disk drive, etc.

[0038] PRMS 102 can receive complaints about product anomalies or requests for product recalls via network 106, for example, from one or more computing devices 104-1, 104-2, ..., 104-N, including devices for consumers of the product or devices performing internal quality monitoring processes at the manufacturing location. In this example, network 106 can be a single network or a combination of multiple networks, and can use various different communication protocols. Network 106 can be a wireless network or a wired network or a combination thereof. Examples of such single networks include, but are not limited to, Global System for Mobile Communications (GSM) networks, Universal Mobile Telecommunications System (UMTS) networks, Personal Communication Services (PCS) networks, Time Division Multiple Access (TDMA) networks, Code Division Multiple Access (CDMA) networks, Next Generation Networks (NON), and Public Switched Telephone Networks (PSTN). Depending on the technology, network 106 includes various network entities such as gateways and routers; however, for the sake of brevity, these details are omitted.

[0039] Upon receiving a product complaint or a request to recall a product, the recall process can be initiated by an authorized user of the manufacturer's PRMS. The PRMS executes a workflow corresponding to the product recall process. The workflow may include one or more steps, and interrelated steps within these steps may be grouped into multiple phases. Each step of the workflow can be executed by a corresponding authorized user, whose role can be defined based on predefined rules (such as the user's role or appointment within the manufacturer's organization, or the user's expertise) or based on historical data instructing the user to execute various steps of the workflow corresponding to the product recall process.

[0040] Typically, a Product Recall Management System (PRMS) may include two main subsystems: a recall decision subsystem and a recall execution subsystem, to execute the product recall process. The recall decision subsystem executes a workflow for deciding whether to initiate a recall of a product or batch of products. Accordingly, this subsystem employs a workflow that provides the means for collecting data, conducting risk analysis, and supporting decision-making regarding product recalls. On the other hand, the recall execution subsystem is configured to execute a workflow for carrying out the recall once a product recall decision has been made, thus providing the workflow and tools for doing so.

[0041] When initiating a product recall process, authorized users can submit requests for product investigations to the recall decision subsystem. The workflow executed by the recall decision subsystem may include multiple steps to conduct an investigation (often referred to as a risk investigation), which aims to assess the validity, severity, and scope of anomalies in the product that prompt a request for a product recall. The risk investigation may involve collecting input from users, suppliers, and other stakeholders, and analyzing data such as customer complaints and safety issues related to the reported anomalies. The recall decision subsystem provides a workflow for implementing processes for collecting, updating, and maintaining predefined information related to the product, which is a prerequisite for any recall decisions and actions to be taken, and may be stored in the product database 108.

[0042] Product database 108 may additionally store data related to various stages of product manufacturing. Different types of data associated with product manufacturing can be stored in product database 108, including information related to compliance with SOPs, sensing physical conditions and events throughout the manufacturing process, and all additional data associated with each stage of product manufacturing (such as supplier ID, raw material ID, etc.). Data retrieved from product database 108 can be used to determine whether an anomaly poses a risk to consumers and whether a product recall is necessary. Based on the risk assessment, if a product recall decision is made—in other words, the product recall request is approved at the recall decision subsystem—a request to execute the product recall is sent to the recall execution subsystem.

[0043] The recall execution subsystem executes a workflow that provides the steps required to carry out a product recall. This includes notifying all stakeholders, managing the logistics of product returns, disposing of affected products, maintaining accurate records of the recall process, and providing customer support. The workflow executed within the recall execution subsystem to implement a product recall needs to ensure compliance with regulatory requirements, such as compiling reports on the progress of the recall process and allowing for assessment of the recall's effectiveness.

[0044] One or more action items may be associated with each step of the workflow and may need to be performed during the execution of the corresponding step. An action item may refer to an activity or task that will be performed during the execution of the corresponding step. For example, during the configuration step of the workflow corresponding to the Product Recall Decision Subsystem of PRMS 102, action items may include objects configuring detailed characteristics and identifiers of products that may help in making a recall decision, and filters configuring criteria or conditions for evaluating whether these product characteristics pose a sufficient risk to warrant a recall. These action items may be performed by the corresponding authorized user.

[0045] Because delays in the product recall process have a serious impact on the safety of consumers or users and the reputation of manufacturers, some steps of the workflow corresponding to both the product recall decision-making and product recall execution subsystems can be executed in parallel. Furthermore, the execution of one or more actions of a workflow step may depend on the execution of one or more actions of another step in the workflow. This invention provides a system 110 for managing workflows executed by PRMS 102, such that authorized users executing steps of a workflow for the product recall process can be aware of the dependency of that step's execution on another related step in the workflow. Therefore, steps that do not depend on other steps can run in parallel, and the system allows the execution of workflow steps to be planned based on the dependencies of dependent steps on other related steps, thereby accelerating the recall process.

[0046] According to the example implementation of this topic, system 110 may be coupled to PRMS 102. System 110 may be any computing device, such as a server, desktop computer, laptop computer, smartphone, or tablet computer. In another example, the functionality of system 110 may be implemented in a computing device implementing PRMS 102. In this example, the functionality of system 110 may be implemented within PRMS 102.

[0047] System 110 can be configured to display a visual indicator depicting the dependency of one step's execution on the execution of another. The visual indicator may include links between visual representations of related steps in a user interface depiction of the workflow. The user interface depiction of the workflow may be referred to as a navigation map. The visual representation of a step may include an icon or box of any shape, displaying text describing the step. The link may be in the form of an arrow starting from the representation of a dependent step and moving towards the related step, or vice versa. This allows a user to identify steps that may prevent the execution of the step they are responsible for performing. Similarly, the visual indicator may also depict other steps that depend on the execution of the step they are responsible for performing, thereby letting the user know whether they may be delaying the progress of the recall process.

[0048] Based on the examples in this topic, system 110 can also be configured to determine the status of each step in the workflow. The system can determine the status of one or more actions based on the execution of one or more actions within a step. If the status of a relevant step is determined to be pending, the system can also generate a completion schedule for the execution of the relevant step based on the planned completion date of the product recall process. The generated schedule can be communicated to authorized users of the relevant steps to avoid delays in the execution of dependent steps, thereby ensuring compliance with the planned completion date of the process.

[0049] Figure 2A system 110 for managing workflows executed by a product recall management system is illustrated, specifically implemented according to examples of this subject. System 110 may be one or more computing devices, such as desktop computers, laptop computers, smartphones, personal digital assistants (PDAs), tablets, and servers. In the example, system 110 may include processor 202. In the example, processor 202 may be implemented as a microprocessor, microcomputer, microcontroller, digital signal processor, central processing unit, state machine, logic circuit system, and / or any device that manipulates signals based on operating instructions.

[0050] As previously referenced Figure 1 As explained, System 110 manages the execution of a workflow that includes one or more steps that can be executed by PRMS 102 for a product recall process. For the purposes of this description, any reference to a product to be recalled may include a single product, a collection of products, a batch of products, or multiple collections of products or multiple batches of products. Each step of the process may have one or more actions associated with it. Actions may refer to specific tasks or activities that will be performed or carried out by the corresponding authorized user. These tasks may include assigning roles to key personnel (such as process owners or quality managers) and collecting product information such as lot number, production date, and source of raw materials.

[0051] The workflow follows a predetermined sequence, with some steps depending on the completion of others. This interdependence is tracked by associating correlation information with each step, thus identifying which actions must be completed before other actions can begin.

[0052] In the example, processor 202 can retrieve relevance information associated with a first step in one or more steps of a workflow. In this example, the relevance information may be created by an administrator based on business rules to comply with regulatory requirements. For example, consider a scenario where a statutory requirement stipulates that a complaint about a medical device can only be closed after a representative of the device manufacturer certifies that a risk assessment process has been conducted in accordance with the rules stipulated by regulations. Therefore, in this example scenario, there is a dependency between the closure of the complaint and the representative's certification. The relevance information identifies an action item associated with a second step in the one or more steps, the initiation of which will be triggered upon the completion of the action item associated with the first step. Accordingly, in the example scenario, the relevance information may identify that certification by a representative is required before the step that marks the complaint as "closed".

[0053] Once processor 202 retrieves the relevance information for a given step (indicating which subsequent steps depend on the completion of that step), it can present this information to the user via a visual indicator overlaid on the workflow depiction on the user interface, identifying the steps within it. The workflow depiction on the user interface may be referred to as a navigation map and may include links between related steps. In this example, the overlaid information may be dynamic and change with the current state of the respective steps. Therefore, processor 202 can present a visual indicator to the authorized user of the first step based on the relevance information. This visual indicator depicts the logical association between the pending action item associated with the second step and the pending action item associated with the first step. In this example, the visual indicator may be a directional arrow showing the relationship between steps on the navigation map.

[0054] Processor 202 can determine the status of the first and second steps based on the execution of actions associated with the corresponding steps. The execution of actions can be monitored via variable parameters, which may change or be set as actions are executed. For example, an action corresponding to a risk investigation step in the workflow might lead to the assignment of values ​​to variables indicating risk factors according to a predefined scale. The values ​​of parameters can be tracked or monitored to determine whether the risk investigation step is pending or completed.

[0055] If the status of the first step is determined to be pending, the processor can generate a completion schedule for the execution of the actions associated with the first step based on a predefined completion schedule for the actions associated with the second step. Therefore, for pending steps, the system generates a completion schedule that takes into account the timeline or schedule of dependent steps. For example, if the second step is scheduled to be completed on or before December 27, 2024, the generated completion schedule for the first step could include dates prior to December 27, 2024. The schedule can be generated considering the time required to complete the execution of the actions associated with the second step to provide sufficient time for the second step to be executed. In the example, to determine the time required to complete the execution of the actions associated with the second step, system 110 could rely on historical data related to the execution of the workflow to recall products or other similar products. The generated schedule can then be displayed to the authorized user responsible for the first step. In the example, the schedule can be overlaid on the visual representation of the first step on a navigation map. By providing visibility into which steps are blocked before the current step is completed and scheduling the completion time of those steps accordingly, PRMS ensures effective coordination among team members working on recall projects. This allows for the timely initiation of subsequent steps and facilitates the smooth, synchronized execution of the entire recall workflow.

[0056] Figure 3Another example implementation of system 110 according to this topic is illustrated. In the example, system 110 can be any computing device, such as a server, desktop computer, laptop computer, smartphone, personal digital assistant (PDA), and tablet computer.

[0057] In the example, system 110 includes a processor, such as processor 202 described above. In the example, processor 202 may be implemented as a microprocessor, microcomputer, microcontroller, digital signal processor, central processing unit, state machine, logic circuit system, and / or any device that manipulates signals based on operating instructions. System 110 also includes an interface 302 coupled to processor 202. Interface 302 may include various software and hardware interfaces that allow system 110 to interact with other communication and computing devices, such as network entities, web servers, external storage libraries, and peripheral devices. Interface 302 also enables internal components of system 110 to couple with each other.

[0058] In addition, system 110 includes memory 304 coupled to processor 202. Memory 304 may include any computer-readable medium known in the art, including, for example, volatile memory (e.g., RAM) and / or non-volatile memory (e.g., EPROM, flash memory, etc.). Memory may also be an external memory unit, such as a flash drive, optical disc drive, external hard disk drive, etc. System 110 may include module 306 and data 318 coupled to processor 202. In one example, module 306 and data 318 may reside in memory 304.

[0059] In the example, data 318 may include workflow data 320, correlation data 322, status data 324, visual indicator data 326, plan data 328, and other data 330. Module 306 may include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Module 306 also includes modules that complement applications on system 110, such as modules of the operating system. Data 318 particularly serves as a repository for storing data that can be retrieved, processed, received, or generated by one or more modules in module 306. Module 306 may include a correlation information module 308, a visual depiction module 310, a status determination module 312, a plan generation module 314, and other modules 316. Other modules 316 may include programs or coded instructions that complement applications and functions, such as programs in the operating system of system 110.

[0060] As previously referenced Figure 1As explained, System 110 can be implemented in a computing device that implements PRMS, and the functionality of System 110 can be integrated into PRMS (such as PRMS 102). Product manufacturers may need to recall products due to identified anomalies, regulatory compliance, or preventative measures based on potential risks. PRMS is used to streamline the product recall process. PRMS 102 can be designed to align with and enforce recall-specific Standard Operating Procedures (SOPs), thereby ensuring consistency and compliance across different scenarios.

[0061] To perform the functionality of PRMS 102, system 110 may include two subsystems: a recall decision subsystem and a recall execution subsystem. The recall decision subsystem is responsible for assessing risks and determining whether a recall is necessary. It analyzes data, evaluates potential hazards, and makes recommendations on whether to initiate a recall. Once a recall has been decided, the recall execution subsystem manages the actual implementation of the recall. In some implementations, including the recall decision subsystem in system 110 may be optional, and system 110 may operate solely with the recall execution subsystem. This configuration is useful when the decision to recall a product is made outside of system 110. For example, a recall may be initiated based on consumer complaints or regulatory requirements without going through a decision-making process. In such cases, the recall decision is given directly to the recall execution subsystem to initiate the recall process.

[0062] When system 110 receives a complaint or request for a recall of a set of products, for example from one or more computing devices (such as computing devices 104-1, 104-2, ..., 104-N) associated with a consignee or authorized person of a manufacturer, system 110 executes a workflow for recalling the products. A workflow can be an ordered or structured set of one or more steps to be performed for recalling products. One or more interrelated steps can be grouped into one or more phases specifying a particular objective. In addition to providing an ordered structure for different tasks, workflows can be used to assess the progress of different steps (or phases) and can help assess the degree of completion of a given process. For example, a workflow can be characterized by different milestones that mark different steps or phases and, accordingly, serve as markers identifying which steps or phases have been completed and which have not yet been initiated. Each step of the workflow can encompass one or more specific tasks or activities that need to be completed as part of the recall workflow, referred to as action items. The successful progress of a step typically depends on the performance of its associated action items, thus ensuring that all necessary activities are performed before moving on to subsequent steps in the workflow. One or more actions associated with a step in the workflow can be performed by an authorized user. For example, the process owner for a specific action to complete a step in the workflow corresponding to the recall execution subsystem can be identified based on the process owner's expertise, role, or permission level. Workflow-related information can be stored in workflow data 320. This information may include information about steps, stages, actions to be performed in each step, authorized users for each step, and the execution sequence of steps or stages.

[0063] In the example, the workflow corresponding to the recall decision subsystem may include multiple phases, such as configuration, signal detection, and investigation. Each phase may be specified to achieve a specific objective by performing one or more steps. For example, the configuration phase may be specified to set up tasks for assessing the risks associated with the product and whether a recall is warranted. The configuration phase may include steps such as object and filter configuration, user management configuration, and signal threshold configuration. Object configuration may refer to the specific attributes and characteristics of the product being evaluated for recall. Filter configuration may refer to the criteria or thresholds used to evaluate whether a product should be recalled based on certain factors or filters. User management configuration may refer to roles, responsibilities, and communication strategies to ensure a coordinated, efficient, and legally compliant recall process. In the context of the product recall decision process, signal threshold configuration refers to the criteria or thresholds used to determine when a product issue (such as a defect, hazard, or safety problem) is serious enough to trigger a recall. The signal detection phase may refer to the identification and analysis of signals or indicators that suggest the presence of potential safety issues, defects, or risks in products that may require recall. These signals may come from various sources, such as customer complaints, regulatory notices, manufacturing defects, or post-market surveillance. The signal detection phase may include steps of global partitioning or event review. Global partitioning can refer to dividing or segmenting the entire recall process based on different variables such as geography, product type, severity, market segmentation, or regulatory requirements. The investigation phase may include the following steps: creating actions to be performed during the recall process and assigning these actions to designated process owners; conducting quality investigations; conducting financial or risk investigations; and obtaining approval or rejection from the implementers. The investigation phase aims to verify the problem, understand its scope and impact, and make informed decisions about how to proceed. This phase involves identifying the defect, conducting root cause analysis, and assessing risks.

[0064] Once a decision to recall a product is made through the workflow corresponding to the recall decision subsystem of system 110 or outside of system 110, the authorized user of the recall execution subsystem can be notified to begin executing the corresponding workflow for recalling the product.

[0065] In the example, the workflow corresponding to the recall execution subsystem may include phases such as configuration and implementation. The configuration phase of the recall execution subsystem may include steps for facility configuration and language configuration, which are crucial for ensuring effective recall management, clear communication, and robust operational infrastructure. Establishing recall centers, logistics, and customer service operations, and ensuring all recall communications are available in the relevant language, helps ensure smooth recall processing and compliance with legal requirements. Another step in configuration may include creating communication templates, for example, for communicating with consumers to facilitate the return of affected products, coordinating product returns, disseminating information, and providing support to consumers. The execution phase may involve coordinating product returns, managing communication with recipients, providing solutions (refunds, replacements, repairs), and ensuring compliance with legal and regulatory requirements.

[0066] In a workflow, different steps or phases can be executed in parallel to expedite the recall process, or they can be interconnected. For example, in the example above, steps in the configuration phases of two workflows related to the recall decision and recall execution subsystems can be executed in parallel. Furthermore, the initiation of the execution of a step or phase may depend on the completion of another phase or step. For example, the executor's approval or rejection step in the investigation phase of the recall decision workflow may depend on the results of the quality investigation and financial risk investigation steps in the same phase. At a further granular level, the execution of one or more actions associated with a step may also depend on the completion of one or more actions associated with another step in the same phase or another phase. For example, the execution of the financial or risk investigation step may include actions that set the value of a variable parameter indicating the severity of the defect identified in the product based on an assessment of potential harm to consumers and the business. The executor's approval or rejection step may be based on the value of said parameter assigned during the financial or risk investigation step and other criteria that may need to be followed when making a recall approval or rejection decision. This correlation between one or more steps can be indicated by correlation information. Relevance information indicates whether the completion of any given step depends on or relies on the completion of another related or dependent step. Similarly, relevance information can indicate whether the pending status of any given step could prevent its execution by depending on the completion of that given step.

[0067] In the example implementation, the relevance information module 308 can define relevance information for each step. Relevance information can be defined by an administrator linking related steps, or it can be specified through programming that defines the workflow of the recall process to be implemented. In the example, relevance information can be defined by the relevance information module 308 based on one or more predefined rules. In this case, the predefined rules can be based on one or more criteria related to one or more steps. The relevance information module 308 can accordingly determine one or more common criteria between steps and provide relevance information linking steps to common criteria accordingly. Examples of such criteria may include, but are not limited to, the recall process that a step may correspond to, the priority of the step, whether the step is linked to one or more other common steps, etc. It can be noted that for such predefined rules, other criteria may also be relied upon, and the relevance information module 308 can define the relevance information between one or more steps based on these other criteria.

[0068] In this example, the relevance information module 308 can use a machine learning-based model to determine relevance information between steps. This machine learning model can be trained based on historical data related to the execution of the workflow used for product recall. The machine learning model, while being trained, can then be used by the relevance information module 308 to define relevance information between one or more steps. In the context of this example, the training data on which the machine learning model is trained can include one or more criteria, as discussed above. The training data may also include one or more attributes or variable parameters that can be historically updated during the execution of the product recall workflow. When trained, the relevance information module using the trained machine learning model can determine the relevance information for each step accordingly. At a granular level, the relevance information can indicate whether the initiation of the execution of an action associated with a step can be triggered upon the completion of the execution of an action associated with another step. The relevance information associated with each step of the workflow can be stored in the system's relevance data 322.

[0069] During the execution of a workflow for product recall, the relevance information module 308 may retrieve relevance information associated with each step of one or more steps in the workflow from the relevance data 322 to identify dependencies between related steps. For example, the relevance information module 308 may retrieve relevance information associated with a first step of one or more steps in the workflow from the relevance data 322 to identify steps related to the first step. In this example, relevances may be predefined by the relevance information module for each step of the workflow and pre-stored in the relevance data 322. Alternatively, when an authorized user accesses PRMS 102 to perform a step they are responsible for executing, the relevance information module 308 may determine the relevance information as described above. The relevance information identifies an action item associated with a second step, the initiation of which will be triggered upon completion of the action item associated with the first step. Therefore, the execution of the second step depends on the completion of the first step.

[0070] Once relevant information is retrieved for the first step, the visual representation module 310 can represent that information on a navigation graph corresponding to the workflow rendered on a user interface on a display device that can be coupled to the system. The navigation graph includes a visual representation of each step in the workflow and can be rendered based on data stored in the workflow data 320. For example, to visually represent a step, an icon or box with text describing the corresponding step can be displayed on the user interface. The text may include a title or identifier assigned to a step in the workflow. The icon can be a box of any shape.

[0071] The visual representation module 310 can also present a visual indicator to the authorized user of the first step based on relevance information. This visual indicator depicts the logical association between the pending action item associated with the second step and the pending action item associated with the first step. To depict the logical association between the action items of the first and second steps, the visual indicator can be overlaid on the navigation map. The visual indicator may include a common shape, a common color, a common annotation, a conceptual connector, or a combination thereof. Indicators can be provided for the visual representation of corresponding related steps (e.g., the first and second steps). In an example, a conceptual connector between the visual representations of the first and second steps can be provided on the user interface, having an arrow pointing to the visual representation of the second step and linking the first and second steps. For example, a quality survey and the step of the executor making an approval or rejection can be visually represented by various icons, with the title of the step displayed on the corresponding icon. An arrow starting from the icon corresponding to the quality survey step and pointing to the icon corresponding to the step of the executor making an approval or rejection can be provided as a visual indicator between the two icons to depict the logical association between the pending action item of the executor making an approval or rejection step and the pending action item of the quality survey step. In another example, the visual indicator may include visually representing the relevant step using the same color or the same icon. The data generated by the visual depiction module may be stored in visual indicator data 326.

[0072] Accordingly, the navigation map depicts the dependency of the execution of an action associated with a step on the execution of an action associated with another related step in one or more steps. The navigation map indicates to the authorized user that a particular step cannot proceed until all other previous steps have been completed, or vice versa, allowing them to move to that particular step without completing all previous steps.

[0073] In the example, dynamic information elements corresponding to steps (e.g., the first step) can be provided on the navigation graph. A dynamic information element can refer to one or more user interface elements configured to receive user input and generate events in response to that input. These events can cause output to be generated in response to the user input. Examples of such dynamic information elements may include text or radio buttons, checkboxes, text fields, dropdown lists, etc., which may be populated with text corresponding to the step's title or identifier. Dynamic information elements can receive user input. Dynamic information elements can be configured to allow authorized users of the first step to navigate to the user interface corresponding to that first step to perform actions associated with it. For example, a dynamic information element corresponding to a step configured with objects and filters can allow authorized users of that step to navigate to a user interface that can further allow users to perform one or more actions, such as determining specific attributes and characteristics of the product being evaluated for recall, such as product type, product specifications, manufacturing batch, and packaging.

[0074] In an example implementation, to identify steps that are blocked from execution due to pending execution of one or more related steps, the status determination module 312 may determine the status of each of the one or more steps based on the execution of actions associated with the corresponding step. For example, the status determination module 312 may determine the status of a first step and a second step based on the execution of actions associated with the corresponding step to identify whether the second step is blocked from execution due to the pending execution of the first step. In the example, the execution of actions associated with a step may result in updating the values ​​of variable parameters or attributes that can be stored in workflow data. These values ​​may be monitored by the status determination module 312 to determine the status of the corresponding step. For example, the execution of actions associated with a step involving signal threshold configuration may result in setting the values ​​of variables or parameters to reflect the criteria or thresholds used to determine when a product problem (such as a defect, hazard, or safety issue) is serious enough to trigger a recall. Such parameters may be monitored to determine whether the status of the signal threshold configuration step is pending or completed. In an example implementation, the status determination module 312 may also require an authorized user for each step to provide the status via visual cues and receive the status of each step from the corresponding user. The status of each step may be stored in status data 324.

[0075] In an example implementation, the visual depiction module 310 may, for example, depict the status of each step and the visual representation of each step on a navigation map. This depiction indicates to the user which parallel steps have been completed and which steps are now blocked from moving forward. The user can also see which steps they are allowed to execute. In the example, color coding can be defined for each status. For example, green can depict the "complete" status, and red can depict the "pending" status. Therefore, the visual representation of each step can be rendered with the color defined for the corresponding status of that step. For example, if the status of a step is determined to be complete, the text of the step displayed on the icon or identifier can be rendered in green, and if the status is determined to be pending, it can be rendered in red. In another example, an icon that displays the status and overlaps with the icon representing the step can be displayed on the user interface.

[0076] Once the status of each step is determined, the schedule generation module 314 can generate a completion schedule for pending steps, taking into account the timelines of their dependent steps. Accordingly, if the status of the first step is determined to be pending, the schedule generation module 314 can generate a completion schedule for the execution of actions associated with the first step based on a predefined completion schedule for the execution of actions associated with the second step. In this example, the completion date of the product recall process can be predefined and stored in the schedule data 328. In another example, the completion timeline or schedule for each step of the workflow for product recall can be predefined and stored in the schedule data 328. The schedule generation module 314 can retrieve the predefined completion schedule for the execution of actions associated with the second step from the schedule data 328 and generate a completion schedule for the execution of actions associated with the second step, enabling the second step to be completed according to its predefined schedule. For example, in the scenario described above, if the executor's approval or rejection step is scheduled to be completed on or before December 18, 2024, and is pending due to the quality investigation step, a schedule including dates prior to December 18, 2024, can be generated, taking into account the expected time required to complete the executor's approval or rejection step. The generated schedule can be stored in schedule data 328. The generated schedule can also be communicated to the authorized user of the first step. In the example, the generated schedule can be depicted to the authorized user of the first step via a visual indicator by displaying the generated schedule along with a visual representation of the first step. In the example, the visual indicator may include a pop-up message displayed on the user interface along with the visual representation of the first step. In another example, an icon displaying the schedule and overlapping the icon representing the first step can be shown on the user interface to depict the schedule to the authorized user of the first step. Other examples of the depiction of the schedule are also possible.

[0077] In the example, the schedule generation module 314 can generate a notification for the authorized user of the first step based on the generated schedule. This notification prompts the authorized user of the first step to perform an action associated with the first step within the time period defined by the generated schedule. The notification can be displayed along with a visual representation of the first step, for example, as a pop-up message. In another example, the schedule can be notified to the authorized user, for example, based on a registered email ID.

[0078] The status determination module 312 can monitor the execution of the first step to determine the completion of the action item associated with the first step. If the status of the first step is determined to be completed, the schedule generation module 314 can generate a notification for the authorized user of the second step. This notification prompts the authorized user of the second step to initiate the execution of the action item associated with the second step. The notification can be generated in the manner described above.

[0079] As described above, one or more action items are associated with a step, and the completion of that step requires the execution of one or more steps. In the example implementation, when more than one action item is associated with a first step and the status of the first step is determined to be pending, the schedule generation module 314 can suggest a sequence of executions for the action items associated with the first step of the workflow. Suggestions can be provided based on historical data relating to the role of the authorized user of the first step in the execution of the workflow. For example, actions taken by users with roles similar to the user of the first step during past workflow executions can be identified. Based on such identification of actions, a sequence of executions for the action items can be suggested. Historical data can be stored in workflow data 320. The pending execution of each action item in a step can have different effects on the execution of action items corresponding to dependent steps. Accordingly, in the example implementation, a sequence can be suggested based on the effect of the pending execution of corresponding action items on the execution of action items in a second step.

[0080] In the example, the schedule generation module 314 can classify each of one or more actions associated with the first step into one of a red, yellow, or green zone based on the impact of the pending execution of the corresponding action on the execution of the action in the second step. The red, yellow, and green zones can respectively indicate high, medium, and low priority for the execution of the corresponding action in the first step. For example, if filter configuration is not fully completed in the object and filter configuration step, the filter configuration can be classified as a yellow zone because this means that all data may need to be retrieved from the product database 108. However, if an object is not configured, the object can be classified as a red zone because this may prevent each subsequent step of the workflow, such as signal detection, investigation, and execution.

[0081] In this example implementation, data related to the execution of the workflow used for product recall can be provided as training data to a machine learning model. The machine learning model can be trained using the data to generate a sequence of execution steps corresponding to the workflow of the product recall process. In this example implementation, the machine learning model can be installed within system 110 itself. In this example, the machine learning model can be implemented using a machine learning algorithm that learns to optimize the execution of the workflow for the process of recalling products. The machine learning model may include routines, programs, objects, components, data structures, etc., that perform predictions or implement specific abstract data types. In this example implementation, the machine learning model can be integrated into PRMS 102.

[0082] Combination such as Figure 4 , Figure 5A and Figure 5B The example user interface shown in the document further illustrates the above method. Figure 4 An example user interface 400 rendered by system 110 is depicted. User interface 400 can be rendered onto a display device that can be coupled to system 110. In this example, user interface 400 may be rendered by visual rendering module 310. User interface 400 may include a visual representation or box 402 representing stage A of a workflow for product recall performed by PRMS 102. User interface 400 may also include another box 404 representing another stage B. It can be noted that although this example user interface 400 is shown as displaying boxes 402, 404 for two stages of the workflow, user interface 400 may depict several other stages without departing from the scope of this topic.

[0083] As previously discussed, stages A and B may each include one or more steps, such as steps 406-1, 406-2 and steps 406-3, 406-4. The corresponding steps 406-1, 406-2, 406-3, and 406-4 may also be represented by separate boxes 408 and 410. One or more action items may be associated with each step and require execution by the corresponding authorized user. For example, action items 406-11, 406-12, ..., 406-1N may be associated with step 406-1. Similarly, action items 406-21, 406-22, ..., 406-2N may be associated with step 406-2, action items 406-31, 406-32, ..., 406-3N may be associated with step 406-3, and action items 406-41, 406-42, ..., 406-4N may be associated with step 406-4. Relevance information can be associated with each step 406-1, 406-2, 406-3, and 406-4. The identification of the relevance information associated with a step depends on one or more related steps. The relevance information module 308 can retrieve relevance information from the relevance data 322. Based on the relevance information, the relevance information module 308 can determine that steps 406-2 and 406-3 are related, and the initiation of the execution of action items 406-21, 406-22, ..., 406-2N associated with step 406-2 will be triggered when the execution of action items 406-31, 406-32, ..., 406-3N associated with step 406-3 is completed. The correlation between steps 406-2 and 406-3 can be represented by the visual representation module 310 using a visual indicator, as discussed in conjunction with the previous diagram, which depicts the logical relationship between the pending action item associated with step 406-3 and the pending action item associated with step 406-2. The visual indicator can overlay the visual representations of steps 406-2 and 406-3. Figure 4In the diagram, the indicator is depicted as a straight line 412 linking the visual representation of step 406-2 to step 406-3, where both steps 406-2 and 406-3 are represented as boxes. The straight line includes an arrow pointing to step 406-3. Although the user interface 400 depicts line 412, it can be noted that additional indications can be provided by overlaying the visual representation of the steps with one or more such indicators. The state determination module 312 can determine the state of steps 406-1, 406-2, 406-3, and 406-4 based on the execution of one or more actions associated with the respective steps. Based on this determination, the states of steps 406-2 and 406-3 are marked as pending. Based on relevance information, step 406-3 can be determined to be pending due to the pending status of step 406-2. The visual indicator depicts the state of the steps. For example, various icons or other representative elements may cover steps 406-2 and 406-3 to indicate that steps 406-2 and 406-3 are pending, with line 412 depicting the pending relationship between steps 406-2 and 406-3. Such examples will also fall within the scope of this topic.

[0084] Figure 5A and Figure 5B Various other example illustrations of visual indicators are provided. It is important to note that such example illustrations are indicative and should not be considered as limiting the scope of this topic in any way. Figure 5A The visual indicators are depicted by using a common shape to represent steps 406-2 and 406-3. In this example, steps 406-2 and 406-3 are related and dependent, represented by dashed boxes 502 and 504 respectively, in contrast to the solid boxes representing the other steps 406-1 and 406-4. In another example, boxes 502 to 504 could be further annotated with additional icons or annotations that could further help identify pending and related tasks. This is in... Figure 5B The diagram depicts dashed boxes 502 and 504, further annotated by information elements depicting one or more pieces of information relating to the corresponding steps (such as steps 406-2 and 406-3). When step 406-2 is pending, the schedule generation module 314 can generate a completion schedule for the execution of one or more actions associated with step 406-2, based on a predefined completion schedule for the execution of one or more actions associated with step 406-3. A visual indicator can depict the generated schedule to an authorized user of step 406-2. In this example, annotations 506 and 508 provide information relating to steps 406-2 and 406-3. Examples of such information may include, but are not limited to, the status of the steps and the completed schedule. It should be noted that such examples are indicative and should not be construed as limiting the scope of this subject.

[0085] Figure 6A method 600 for managing workflows executed by a PRMS is illustrated according to an example. Although method 600 can be implemented in various computer-based systems, this description of an example method 600 is provided with reference to the system 110 described above for ease of explanation.

[0086] The order in which method 600 is described is not intended to be construed as limiting, and any number of the described method blocks may be combined in any order to implement method 600 or alternative methods. Furthermore, method 600 may be implemented by a processor or computing device via any suitable hardware, non-transitory machine-readable instructions, or a combination thereof.

[0087] It is understood that the blocks of method 600 can be executed by a programmable computing device. As will be readily understood, the blocks of method 600 can be executed based on instructions stored in a non-transitory computer-readable medium. Non-transitory computer-readable media may include, for example, digital memory, magnetic storage media (such as disks and magnetic tapes), hard disk drives, or optically readable digital data storage media.

[0088] As discussed above, a workflow can include an ordered set of steps, each comprising an action to be performed by a corresponding authorized user. For example, an action could be a specific task or activity, ranging from assigning roles to key personnel to collecting critical product data. Therefore, workflows follow a predetermined sequence, with some steps depending on the completion of others. This interdependence can be documented as relevance information for each step. This relevance information identifies which actions in subsequent steps depend on the completion of the current step. For example, the "recall decision" step might not begin until the "risk assessment" step is completed.

[0089] refer to Figure 6 At box 602, for example, the relevance information module 308 of system 110 may retrieve relevance information associated with the first step of a workflow for product collection recall that can be executed by PRMS. In this example, the relevance information may be predefined by the relevance information module 308 based on predefined rules. These rules may be based on predefined criteria, such as procedures for product collection recall and compliance with regulatory requirements. The first step may include a first action item to be performed by a first user. The relevance information may identify a second action item associated with a second step of the workflow. The initiation of execution of the second action item will be triggered upon completion of the first action.

[0090] Once relevant information is retrieved, it can be presented to an authorized user via a visual indicator. At box 604, the visual depiction module 310 can present a visual indicator to a first user based on the relevant information. The visual indicator can depict the logical relationship between the pending second action item and the pending first action item. The visual indicator can be information on a visual representation of a step overlaid on a user interface that can be rendered on a display device coupled to system 110. The visual representation of a step can include icons with information identifying the step overlaid thereon. For example, to depict the logical relationship between the first and second steps, a link between the visual representations of the first and second steps can be represented by an arrow that starts from the visual representation of the first step and points to the visual representation of the second step.

[0091] At box 606, the states of the first and second steps can be determined, for example, by the state determination module 314 based on the execution of the first and second actions. The state determination module can determine the state of a step by tracking changes in one or more variables or parameters that may be updated during the execution of one or more actions associated with the step. For example, the step of configuring a signal threshold in a food recall might involve assigning a value, such as 0.1 parts per million (ppm) of a certain pesticide, to trigger a recall. Alternatively, a complaint threshold could be set to five customer reports per day of illness caused by the edible product. The state determination module can track these parameters to determine the state of the signal threshold configuration step.

[0092] If the status of the first step is determined to be pending, then at box 608, a completion schedule for the execution of the first action item can be generated, for example, by the schedule generation module 314 based on the planned completion date of the product collection recall. For example, the schedule can be generated based on a timeline of dependent steps, which can be further based on the planned completion date of the process. The schedule can be depicted to the first user via visual indicators. The visual indicators can be updated to reflect information such as status or completion schedule. This visual representation and schedule provides the user with clear visibility of workflow dependencies and timelines. This facilitates the timely initiation of subsequent steps and promotes the smooth, synchronized execution of the entire recall process.

[0093] Figure 7 A method 700 for managing workflows executed by PRMS is illustrated according to an example. Although method 700 can be implemented in various computer-based systems, this description of example method 700 is provided with reference to the system 110 described above for ease of explanation.

[0094] The order in which method 700 is described is not intended to be construed as limiting, and any number of the described method blocks may be combined in any order to implement method 700 or alternative methods. Furthermore, method 700 may be implemented by a processor or computing device via any suitable hardware, non-transitory machine-readable instructions, or a combination thereof.

[0095] It is understood that the blocks of method 700 can be executed by a programmable computing device. As will be readily understood, the blocks of method 700 can be executed based on instructions stored in a non-transitory computer-readable medium. Non-transitory computer-readable media may include, for example, digital memory, magnetic storage media (such as disks and magnetic tapes), hard disk drives, or optically readable digital data storage media.

[0096] Workflows that can be executed by PRMS consist of interconnected sequences of steps, each involving a specific task or action assigned to an authorized user working on PRMS for the purpose of product recall. These actions vary widely, ranging from identifying the detailed characteristics and identifiers of the product being evaluated for recall to identifying the cause, scope, and potential impact of product defects or safety issues.

[0097] The workflow proceeds in an ordered manner, where certain steps depend on the completion of previous steps. This dependency structure is captured in the relevance information of each step based on predefined rules, detailing which subsequent tasks depend on the completion of the current step. For example, the "Executor Approval or Rejection" step can only be initiated after the "Risk Investigation" step has been completed.

[0098] refer to Figure 7 At box 702, the relevance information module 308 retrieves relevance information associated with a first step in one or more steps of a workflow that can be executed by PRMS. The relevance information identifies a second step that depends on the first step. Once the execution of one or more actions associated with the first step is completed, the execution of one or more actions associated with the second step can be initiated.

[0099] At box 704, the state determination module 312 of system 110 may determine the state of the first step, for example, based on monitoring the execution of one or more actions associated with the first step. In the example, changes in relevant variables or parameters may be monitored to determine the state.

[0100] Based on the determination made in step 704, at box 706, a determination is made regarding whether the status of the first step is pending. If the determination is negative, the method proceeds to box 708, where a notification can be generated for the authorized user of the second step to prompt completion of the first step and instruct completion of the second step.

[0101] If the determination at box 706 is positive, the method proceeds to box 710, where a visual indicator can be displayed by the visual depiction module 310 to the authorized user of the first step. This visual indicator illustrates the logical link between the pending states of the first and second steps. The visual indicator can be depicted on a user interface displayed on a display device coupled to system 110, overlaying a navigation graph including visual representations of the steps. In an example, the visual indicator may include directional connectors connecting the relevant steps to illustrate their interdependencies.

[0102] Method 700 further proceeds to box 712. At box 712, the expected completion date of the second step can be determined, for example, by the schedule generation module 314. The expected completion date of the second step can be predefined, for example, in the timeline for product recall specified by the project recall manager, or can be determined by the schedule generation module 314 based on the planned completion date of the product recall.

[0103] At box 714, taking into account the expected duration required to complete the second step, the schedule generation module 314 can generate a completion schedule for the first step based on the expected completion date of the second step. In the example, the expected duration required to complete the steps (e.g., the first and second steps) can be determined based on input from a machine learning-based model. The model can be trained based on historical data related to the execution of the workflow used for product collection recall.

[0104] At box 716, the authorized user of the first step can be notified of the schedule, allowing the user to expedite the completion of the first step to ensure timely completion of the second step. In the example, a visual indicator can depict the generated schedule. In the example, a notification can also be generated for the authorized user of the first step based on the expected time required to complete both steps, prompting the user to perform one or more actions associated with the first step.

[0105] This visual representation and dynamic planning provide users with a clear overview of workflow dependencies and timelines. For example, a quality assurance manager can see that they need to complete a risk assessment within 5 days to keep the recall process on schedule, thereby facilitating effective coordination and timely execution of the entire recall procedure.

[0106] Figure 8 A method 800 for managing workflows executed by a PRMS is illustrated according to an example. Although method 800 can be implemented in various computer-based systems, for ease of explanation, this description of an example method 800 for managing workflows executed by a PRMS is provided with reference to the system 110 described above.

[0107] The order in which method 800 is described is not intended to be construed as limiting, and any number of the described method blocks may be combined in any order to implement method 800 or alternative methods. Furthermore, method 800 may be implemented by a processor or computing device via any suitable hardware, non-transitory machine-readable instructions, or a combination thereof.

[0108] It is understood that the framework of method 800 can be executed by a programmable computing device. As will be readily understood, method 800 can be executed based on instructions stored in a non-transitory computer-readable medium. Non-transitory computer-readable media may include, for example, digital memory, magnetic storage media (such as disks and magnetic tapes), hard disk drives, or optically readable digital data storage media.

[0109] At box 802, one or more action items associated with a step in one or more steps of a workflow that can be executed by PRMS can be identified, for example, by the schedule generation module 314. The one or more action items can be executed by the corresponding authorized user of the step.

[0110] At box 804, the authorized user's role in the workflow execution can be identified, for example, by the schedule generation module 314. User roles can be predefined, for example, by a business administrator performing application configurations (such as user management, role management, threshold configuration, or data source configuration). In the example, the recall project manager typically manages the project for recall decisions, investigations, and execution. The process owner and quality manager conduct scientific investigations and evaluations. Finally, the execution manager approves or rejects based on the work done by other users.

[0111] At box 806, the planning table generation module 314 can retrieve historical data related to the execution of the workflow used for product recall. Historical data may include information related to roles in workflow execution. For example, if the authorized user's role is identified as a business administrator, historical data may reveal that the business administrator previously performed configuration phase steps in a workflow executed by PRMS.

[0112] At box 808, the execution sequence of one or more actions can be determined, for example, by the schedule generation module 314 based on historical data. For instance, if the authorized user's role is similar to that of a quality manager, actions previously taken by the quality manager in workflows used for product recalls can be analyzed. Based on this analysis, the optimal execution sequence of one or more actions to complete the current step can be determined. In another example, analysis of historical data can determine that a business administrator performed an object configuration action before a filter configuration action because pending object configurations have a more significant impact on the execution of subsequent steps in the workflow. Based on such analysis, the sequence of actions to be executed related to the object and filter configuration steps can be determined.

[0113] At box 810, a visual indicator can be generated by the visual depiction module to depict the execution sequence. The visual indicator can be overlaid on a navigation map that depicts a visual representation of the workflow rendered on a user interface displayed on a display device coupled to system 110. In this example, the visual indicator may include a dynamic information element corresponding to at least one of one or more action items. The dynamic information element can be overlaid on the navigation map. The dynamic information element allows an authorized user to navigate to the associated user interface to perform at least one action item. The dynamic information element can be a user interface element that can receive user input, such as a radio button or text button, a drop-down list, or a checkbox list. The dynamic information element corresponding to at least one of one or more action items, having text describing the corresponding action item, can be displayed according to the execution sequence.

[0114] By providing this prioritization sequence, users can focus on the most critical actions first, thereby ensuring a smoother workflow and minimizing potential bottlenecks in the recall process.

[0115] Figure 9 A computing environment 900 for managing workflows executed by a PRMS is illustrated according to an example. In a specific embodiment of the example, the computing environment 900 may include a computing device, such as system 110 described above. The computing environment 900 includes a processing resource 902 communicatively coupled to a non-transitory computer-readable medium 904 via a communication link 906. In the example, the processing resource 902 may be a processor of the computing device (such as processor 202 of system 110), which acquires and executes computer-readable instructions from the non-transitory computer-readable medium 904.

[0116] The non-transitory computer-readable medium 904 can be, for example, an internal or external memory device. In one example embodiment, the communication link 906 can be a direct communication link, such as any memory read / write interface. In another example embodiment, the communication link 906 can be an indirect communication link, such as a network interface. In this case, processing resource 902 can access the non-transitory computer-readable medium 904 via network 908. Network 908 can be a single network or a combination of multiple networks, and various different communication protocols can be used.

[0117] The processing resource 902 and the non-transitory computer-readable medium 904 are also communicatively coupled to the data source 910. In an example embodiment, the non-transitory computer-readable medium 904 includes executable instructions 912 for managing a workflow executed by the PRMS. The workflow, executable by the PRMS 102, implements a process for recalling products. The workflow may include one or more steps. The execution of a step in the workflow may include the execution of one or more actions associated with that step, and may depend on the execution of one or more other related steps in the workflow.

[0118] In the example, instruction 912 enables processing resource 902 to obtain relevance information associated with the first step of a workflow capable of executing a product recall. This relevance information indicates that the execution of at least one action associated with the second step of the workflow will be triggered upon completion of the execution of at least one action associated with the first step. The relevance information can be created by an administrator based on business rules or regulatory requirements.

[0119] Once the relevance information is retrieved, instruction 912 may also cause processing resource 902 to provide a visual indicator to the authorized user of the first step based on the relevance information. The visual indicator depicts the dependency of the execution of the at least one action associated with the second step on the execution of the at least one action associated with the first step. The visual indicator may be overlaid on a navigation graph that depicts a visual representation of one or more steps on a user interface rendered on a display device coupled to system 110. In the example, the visual indicator includes a directional connector between the visual representations of two related steps (such as the first step and the second step).

[0120] In the example, when instruction 912 is executed, it can also cause processing resource 902 to determine the state of the first and second steps based on the execution of at least one action item associated with the corresponding step by the corresponding authorized user. In the example, the state of a step can be determined by tracking the values ​​of one or more parameters that may be updated during the execution of at least one action item associated with the step. For example, in the case of recalling a specific model of coffee machine, the action item corresponding to the step of object and filter configuration may include determining the model, manufacturing batch, and specific type of heating element used in the coffee machine. Parameters identifying such data, as well as other parameters that may be updated due to the execution of other action items associated with the step of object and filter configuration, can be tracked.

[0121] When the status of the first step is determined to be pending, instruction 912 may also cause processing resource 902 to generate a completion schedule for the execution of at least one action item associated with the first step, based on the planned completion date of the product collection recall. The schedule for the first step may be generated based on the planned completion date of the recall, taking into account the expected time required to execute subsequent dependent steps, such as the second step. A visual indicator may also depict the generated schedule to an authorized user of the first step. In the example, the visual indicator includes information that includes the schedule overlaid on a visual representation of the first step.

[0122] In an example implementation, if the status of the first step is determined to be pending, instruction 912 may also cause processing resource 902 to generate a notification for the authorized user of the first step based on the generated schedule. This notification may prompt the authorized user of the first step to perform at least one action associated with the first step, allowing for the timely initiation of at least one action associated with the second step.

[0123] The pending status of each action item in at least one action item associated with a step may have different levels of impact on dependent steps. Accordingly, if the status of the first step is determined to be pending, instruction 912 may also cause processing resource 902 to prioritize the execution of at least one action item associated with the first step based on the associated impact of the pending execution of the corresponding action item on the execution of at least one action item in the second step. The impact of the pending execution of an action item in a step on the execution of at least one action item in another related step may be determined based on historical data related to the execution of the workflow for product recall. The execution of at least one action item associated with the first step may also be prioritized based on historical data related to the role of the authorized user of the first step in the execution of the workflow. Instruction 912 may cause processing resource 902 to notify the authorized user of the first step of the execution priority of at least one action item associated with the first step.

[0124] In an example implementation, upon determining that the first step is complete, instruction 912 may also cause processing resource 902 to generate a notification to an authorized user for the second step. This notification may include notification of the completion of the first step and instructions for initiating the execution of at least one action item associated with the second step.

[0125] Therefore, the methods and systems of this subject provide for managing workflows executed by PRMS. Although specific implementations of workflow management have been described in language specific to structural features and / or methods, it should be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations of workflow management.

Claims

1. A system for managing workflows executed by a Product Recall Management System (PRMS), the system comprising: Processor, the processor being used for: For a workflow that includes one or more steps of a product recall process that can be executed by the product recall management system, relevance information associated with a first step in the one or more steps is retrieved, wherein... Each of the one or more steps includes an action item to be performed by the corresponding user, and wherein, The relevance information identifies the action item associated with the second step in the one or more steps, and the initiation of the execution of the action item will be triggered when the execution of the action item associated with the first step is completed; Based on the relevance information, a visual indicator is presented to the authorized user of the first step, wherein the visual indicator depicts the logical association between the pending action item associated with the second step and the pending action item associated with the first step. The states of the first and second steps are determined based on the execution of the action items associated with the corresponding steps; and When the state of the first step is determined to be pending, a completion plan for the execution of the action item associated with the first step is generated based on a predefined completion plan for the execution of the action item associated with the second step, wherein, The visual indicator is used to depict the generated schedule to the authorized user in the first step.

2. The system of claim 1, wherein the processor is configured to: Based on the generated schedule, a notification is generated for the authorized user in the first step, wherein the notification is used to prompt the authorized user in the first step to perform the action item associated with the first step.

3. The system of claim 1, wherein the processor is configured to: When the state of the first step is determined to be completed, a notification is generated for the authorized user of the second step, wherein the notification is used to prompt the authorized user of the second step to initiate the execution of the action item associated with the second step.

4. The system of claim 1, wherein the processor is configured to: Generate a navigation graph corresponding to the workflow, wherein the navigation graph is used to depict the dependency of the execution of an action item associated with a step on the execution of an action item associated with another related step in the one or more steps.

5. The system of claim 4, wherein the processor is configured to: The authorized user of the corresponding step receives the status of each of the one or more steps, wherein the navigation graph is used to depict the status of each of the one or more steps.

6. The system of claim 5, wherein the processor is configured to: The navigation map provides dynamic information elements corresponding to the first step, wherein the dynamic information elements are used to allow the authorized user of the first step to navigate to the user interface corresponding to the first step to perform the action item associated with the first step.

7. The system of claim 1, wherein the processor is configured to: When more than one action item is associated with the first step of the workflow, an execution sequence of action items associated with the first step is suggested based on historical data relating to the role of the authorized user in the execution of the workflow.

8. The system of claim 1, wherein the processor is configured to: Data related to the execution of the workflow is provided as training data to a machine learning model, which is then trained to generate an execution sequence of steps corresponding to the workflow of the PRMS.

9. A method for managing workflows executed by a product recall management system, the method comprising: Retrieve relevant information associated with a first step of a workflow capable of executing a product collection recall, wherein the first step includes a first action item to be executed by a first user, and wherein the relevant information identifies a second action item associated with a second step of the workflow, the initiation of execution of the second action item being triggered upon completion of the execution of the first action; Based on the relevance information, a visual indicator is presented to the first user, wherein the visual indicator depicts the logical relationship between the unresolved second action item and the unresolved first action item. The states of the first step and the second step are determined based on the execution of the first action and the second action, respectively. When the status of the first step is determined to be pending, a completion schedule for the execution of the first action item is generated based on the planned completion date of the product collection recall, wherein the visual indicator is used to depict the generated schedule to the first user.

10. A non-transitory computer-readable medium, the non-transitory computer-readable medium comprising instructions executable by processing resources to perform the following operations: Obtain relevant information associated with a first step of a workflow capable of executing a product recall, wherein the relevant information indicates that the execution of at least one action associated with a second step of the workflow will be triggered upon completion of the execution of at least one action associated with the first step; Based on the correlation information, a visual indicator is provided to the authorized user of the first step, wherein the visual indicator is used to depict the dependency of the execution of the at least one action item associated with the second step on the execution of the at least one action item associated with the first step. The states of the first and second steps are determined based on the execution of at least one action item associated with the corresponding step by the corresponding authorized user; When the status of the first step is determined to be pending, a completion schedule for the execution of the at least one action item associated with the first step is generated based on the planned completion date of the product collection recall, wherein the visual indicator is used to depict the generated schedule to the authorized user of the first step.

Images