Dependent linking task

Abstract

A method for associating tasks across different monitored processes is described. In an example, correlation parameters are obtained for a first task and a second task implemented within an organization. The relevance parameter links the first task to the second task and will indicate that initiation of the first task will be caused after completion of the second task. Thereafter, first state information and second state information of the first task and the second task are determined, respectively. The relevance parameter, the first state information, and the second state information may be processed to determine a relevance state of the first task relative to the second task. Based on the correlation state, a visual indicator depicting a pending logical association of the first task and a pending logical association of the second task may be generated.

Description

Background Art

[0001] Any organization within a vertical industry can implement multiple processes. The process can be implemented in stages, wherein each stage may include one or more interrelated tasks or activities that can be performed to achieve a process goal or end result. Examples of process goals include, but are not limited to, products manufactured, services provided, information processed, or any other activity that can be performed to complete a predetermined function or operational task within an organization. The process can be implemented manually or can be automated (completely or partially) by instructions that can be executed on a processor-based system. In some instances, the process can be monitored by a monitoring application. The monitoring application can then report various metrics, which can be represented on a user interface or visual dashboard. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Systems and / or methods according to examples of the present subject matter will now be described with reference to the accompanying drawings, in which:

[0003] Figure 1 A system for associating tasks across different monitored processes according to an example is illustrated;

[0004] Figure 2 An environment within an organization according to an example is illustrated that implements a system for associating tasks across different monitored processes;

[0005] Figure 3 illustrates a workflow and task management system for associating tasks across different monitored processes according to another example;

[0006] Figure 4 illustrates an exemplary user interface presented by a workflow and task management system according to an example;

[0007] Figures 5A to 5B illustrates additional examples of user interfaces presented by a task management system;

[0008] Figure 6 illustrates a configuration dashboard for a task management system according to an example;

[0009] Figure 7 A method for associating tasks across different monitored processes according to an example is illustrated;

[0010] Figure 8 Another method for associating tasks across different monitored processes according to another example is illustrated; and

[0011] Figure 9 A system environment is illustrated for implementing a non-transitory computer-readable medium for associating tasks across different monitored processes according to an example. DETAILED DESCRIPTION

[0012] Organizations within vertical industries can implement multiple processes, which can be implemented in stages, wherein each stage includes one or more interrelated tasks or activities. Such tasks can be performed periodically to achieve one or more intermediate results within a predetermined time period. When a group of tasks included in a stage is completed, the stage can be considered to be completed. Between different stages, the intermediate results from the previous stage can be used as input to the next stage. Such processes can continue until the process goal or final result is achieved. As previously mentioned, the process goal can be the product being manufactured, the service provided, the information being processed, or any activity that can be performed to complete the predetermined function or operational task within the organization. Examples of such operational activities include, but are not limited to, manufacturing activities, sales activities, advertising activities, quality management activities, and marketing activities. The process can be manually implemented or can be automated (completely or partially) by instructions that can be executed on a processor-based system or a programmed machine or device.

[0013] For the sake of efficiency, predictability, and manageability, tasks within a given phase can be divided into sequential steps, known as a workflow, to accomplish process goals. A workflow can represent the manner in which the different tasks or activities of a given phase are to be performed in a logical manner. The various stages of any workflow within a given process can be tracked by a computer-implemented monitoring application. Such an application can monitor the tasks or activities that form part of the process. The status or progress of the monitored tasks can be determined and reported by such a monitoring application.

[0014] This status can be described to specific personnel within the organization through indicators or metrics. Based on the status or progress of the monitored stage, such personnel can take other decisive measures to effectively complete the monitored stage. Generally speaking, monitoring of the workflow of a given stage is performed using a corresponding monitoring application, which can be adapted or configured to evaluate the status of the corresponding activity or task. The status of a task can be captured or represented by various parameters or attributes, which can be obtained by monitoring the task. For example, such status can be determined based on values ​​associated with the parameters or attributes.

[0015] It can be noted that a given monitoring application may be suitable for a predetermined phase of the monitoring process and therefore may not be suitable for monitoring tasks in other phases. Such situations arise due to different types of parameters and attributes, which may have to be monitored for different phases. As a result, different applications may be used to monitor different phases of a given process. For ease of reference and review, a plurality of monitoring applications may be linked to a user interface, wherein the output or reported metrics provided by different monitoring applications may be presented in different presentation formats. Such user interfaces (which are also referred to as dashboards) provide summaries or snapshots of the different states of tasks as reported by different monitoring applications. The interface can be programmed with other executable instructions that can process the reported metrics generated by the monitoring application to present information.

[0016] Managing multiple tasks and monitoring applications presents several technical challenges. Different applications can provide information related to their respective monitored stages. This aspect is explained with respect to stages A and B, which can be monitored by corresponding applications A' and B'. Each of stages A and B can implement one or more tasks. In this example, application A' can determine that one task is pending for completion in stage A, while application B' can report that five tasks are pending in stage B. Anyone reviewing the implemented process (i.e., including stages A and B) based on the reported metrics can initially conclude that stage B may require intervention based on the number of pending tasks. However, if all tasks in stage B depend on tasks in stage A to be completed, intervention may be necessary for the tasks in stage A. It can be noted that since the reported metrics can be specific to the corresponding stage, any insights that can be gleaned can be related to the corresponding stage and therefore may not be suitable for resolving any bottlenecks that may exist in or across different stages. As is apparent from the foregoing examples, different types of monitoring applications may not be suitable for assessing the interdependencies of different tasks between phases, nor for determining any interrelationships between workflows of different phases forming part of a process.

[0017] A method for associating tasks across different monitored processes is described. As previously described, a workflow can include different stages of a process monitored by one or more monitoring applications. Each stage in the stage can include one or more tasks. The monitoring application can determine whether some or all tasks within a given stage have been executed or completed. The monitoring application can report tasks as completed or pending for completion during its operation. When incorporated into a visual dashboard, different monitoring applications can provide snapshots of various stages and provide an indication of the pendingness of one or more tasks within the stage. The dependency of different tasks across different workflows allows the status of a given task to be accurately determined by determining the status of other tasks that may be related to the given task (e.g., completed or pending). The dependency of different tasks that are related to each other across different workflows can be represented on a dashboard or user interface.

[0018] To this end, a workflow management system can be implemented. The specific implementation of such an exemplary workflow management system is described in the context of a process including at least a first phase and a second phase. Although described with reference to the first phase and the second phase, the process can also include multiple other phases without limitation. Continuing with this explanation, the first phase and the second phase can include a first task and a second task. The first task can be associated with a first task ID and a first state. In a similar manner, the second task can be associated with a second task ID and a second state. The first state and the second state can indicate the states of the first task and the second task, respectively. The state can indicate whether the task (i.e., the task corresponding to the state) has been completed or whether it is pending to be completed.

[0019] In the case where the current task is dependent on another task, the current task will be started when the associated dependent task has been completed. To this end, the workflow management system can associate the first task and the second task with a dependency parameter. The dependency parameter can be used to indicate another task that the current task may depend on. For example, a dependency parameter associated with a first task that links it to a second task will mean that the first task will be started once the second task is completed.

[0020] Continuing further, a workflow management system (hereinafter referred to as the system) can obtain a first task ID, a first state, and a corresponding dependency parameter of a first task. In a similar manner, the system can obtain a second task ID, a second state, and a dependency parameter of a second task. Based on the first state, the second state, and the dependency parameter of the first task (which references the second task), the system can determine a dependency state of the first task relative to the second task. The dependency state of the first task will indicate whether the first task is pending due to the pending nature of the second task (if determined to be pending).

[0021] In an example, the system can generate a visual indicator based on the relevant status of the first task, wherein the visual indicator depicts a logical association between the pending status of the first task and the pending status of the second task. If the first task is depicted as pending or not yet initiated, the system can control the appearance of the visual indicator based on whether the second task has been initiated. For example, the visual indicators for the first and second tasks can be in the form of a common shape, a common color, a common annotation, a concept connector, or a combination thereof.

[0022] If the second task has not yet been initiated, the second task may be referenced for decision-making interventions that may be implemented by the administrator. In another example, if the second task is pending, one or more control instructions may be generated. Such control instructions, when executed, may initiate the second task. It is noted that such control instructions may be generated based on predefined programmable instructions that may be programmed to execute in response to a command from a user or in response to the occurrence of one or more conditions or events.

[0023] A visual representation depicting the first task and the second task can be presented on a user interface or dashboard. Along with the visual representation, the user interface can depict the status of the first task and the second task, while also depicting the dependencies of the tasks. A user of the dashboard can review the status of different tasks and determine whether the pending of one or more tasks is linked to other related tasks. It can be noted that although provided in the context of a first stage and a second stage being monitored by a first application and a second application, respectively, the above method can be extended to any number of stages with multiple tasks monitored by multiple monitoring applications. The monitoring application can also be used to monitor multiple other processes implemented and monitored within an organization. Such other examples will also be within the scope of the present subject matter.

[0024] Figure 1 A system 102 for associating tasks across different monitored workflows according to one example is illustrated. A workflow includes multiple stages of a process, wherein the stages and their constituent tasks are monitored by one or more monitoring applications. Within each stage, a set of tasks is defined. The monitoring application systematically evaluates the execution and completion status of one or more tasks in a given stage. The monitoring application can continuously report the status of tasks within each stage, classifying them as completed or pending for completion. In an example, the monitoring application can store data or other metrics corresponding to tasks within different stages of a given process in separate repositories or databases ( Figure 1 The system 102 may acquire these metrics, analyze them and present the same analysis on a visual dashboard.

[0025] System 102 includes a processor 104 and a machine-readable storage medium 106 coupled to and accessible by processor 104. System 102 can be implemented in any computing system, such as a storage array, a server, a desktop or laptop computing device, a distributed computing system, etc. Although not depicted, system 102 may include other components, such as interfaces for communicating with other systems or data repositories over a network, communicating with external storage devices or computing devices, displays, input / output interfaces, operating systems, applications, data, and other software or hardware components (all of which are not depicted for the sake of simplicity). In an example, machine-readable storage medium 106 may further include instructions 108.

[0026] The processor 104 may be implemented as a dedicated processor, a shared processor, or multiple individual processors (some of which may be shared). A machine-readable storage medium 106 may be communicatively coupled to the processor 104. Among other capabilities, the processor 104 may fetch and execute computer-readable instructions, including instructions 108, stored in the machine-readable storage medium 106. The machine-readable storage medium 106 may include non-transitory computer-readable media, including, for example, volatile memory such as RAM (random access memory), or non-volatile memory such as EPROM (erasable programmable read-only memory), flash memory, or the like.

[0027] In operation, processor 104 may retrieve and execute instructions 108 for performing one or more actions, as discussed further below. In an example, execution of instructions 110 may retrieve or obtain a dependency parameter associated with a first task and a second task. It should be noted that the first task and the second task may be tasks of a process that may be implemented within an organization. In an example, the dependency parameter links the first task to the second task. When linked, the dependency parameter may indicate that completion of the second task will cause the first task to be initiated.

[0028] Continuing further, instructions 112 may be executed to determine first status information and second status information related to the first task and the second task, respectively. The first status information and the second status information may indicate whether the first task or the second task is pending. It may be noted that instructions 110 and 112 may be executed simultaneously or in any order without departing from the scope of the present subject matter.

[0029] In the event that the first state information and the second state information are obtained, instructions 114 may be executed to process the relevance parameter, the first state information, and the second state information to determine a relevance state of the first task relative to the second task. In an example, the relevance state of the first task (relative to the second task) may indicate whether the second task (which is pending) has prevented the first task from completing. Once the relevance state is determined, instructions 116 may be executed. When executed, instructions 116 may cause a visual indicator to be generated based on the relevance state of the first task. Among other things, the visual indicator depicts a logical association between the pending of the first task and the pending of the second task. In an example, based on the state conveyed by the visual indicator, a decision-making intervention may be influenced by appropriate stakeholders.

[0030] The above aspects of system 102 will be combined with Figure 2 Discuss in further detail. Figure 2 An example environment is illustrated, including an exemplary organizational environment 200 and its various elements. The exemplary organizational environment 200 can implement multiple stages 202-1, 202-2, ..., 202-N (collectively, stages 202) of a given process. Although this example is explained in the context of a process implementing different stages 202, this should not be considered limiting. Stages 202 can be directed to achieving a goal or end result. Examples of such goals include, but are not limited to, the manufacture of a product or good, the provision of a service, the processing of information for research, development in various technical fields (such as life sciences, engineering, computing, etc.).

[0031] Different processes within an organization can be implemented through multiple stages. Each stage associated with the corresponding process can include one or more tasks. Tasks can correspond to predefined steps that will be implemented or performed for the final completion of the stage and the process. The flow or sequence of different tasks can be such as to ensure that the process can be implemented in a performant manner. The order in which tasks are defined is called a workflow. A workflow can represent the way in which different tasks or activities of a given stage are to be performed in a logical manner. In addition to providing an orderly structure to different tasks, workflows can also be used to evaluate the progress of different stages (or tasks) and can help evaluate the degree of completion of a given process. For example, a workflow can be characterized by different milestones that can depict different stages and, accordingly, serve as markers to identify which stages have been completed and which stages have not yet been started.

[0032] exist Figure 2In the context of the example shown in , a stage 202 may include multiple tasks. For example, stage 202-1 may include tasks 204-1 and 204-2, while stage 202-2 may include tasks 204-3 and 204-4, and stage 202-N may include tasks 204-(N-1), ..., 204-N. Different stages 202 may be linked to each other. For example, the start of stage 202-2 may depend on the completion of stage 202-1. At a further level of granularity, the completion of tasks within stage 202-2 may also depend on the completion of tasks within stage 202-1. In such cases, once a task within stage 202-1 (such as tasks 204-1 and 204-2) is completed, any task within stage 202-2 (such as tasks 204-3 and 204-4) may be started. Although depicted as separate blocks (for purposes of explanation only), each of tasks 204 may be implemented on a specific machine or system, or for any other specific infrastructure element within organizational environment 200 .

[0033] Continuing further, tasks 204 can be monitored by a monitoring application. For example, tasks 204-1 and 204-2 can be monitored by monitoring application 206-1, while tasks 204-3, ..., 204-N can be monitored by monitoring applications 206-2, ..., 206-Q (collectively, monitoring applications 206). Monitoring applications 206 can also be implemented on a separate computing system or can be deployed on a system on which the relevant tasks 204 can be implemented.

[0034] In operation, monitoring application 206 may determine one or more attributes related to task 204 to determine its current state. Such attributes may be reported as metric information or other inputs that may be provided to monitoring application 206. Attributes of task 204 executed within a machine, device, or under the control of a programmed machine or computing device may be monitored by one or more sensors ( Figure 2 204 ), such sensors may be deployed within a machine, equipment, or under the control of a programmed machine performing such tasks 204. Such sensors may continuously capture various data or metric information, which may then be transmitted to the monitoring application 206. Capturing data or metric information related to the various tasks 204 may not be automatic. For example, values ​​associated with one or more attributes or metric information may be manually recorded, stored, and ultimately retrieved by the monitoring application 206.

[0035] Monitoring application 206 can store the metric information in a structured format or an unstructured format in repository 208 when it is obtained. The metric information stored in repository 208 can then be retrieved from repository 208 by workflow and task management system 210 (referred to as system 210). System 210 can retrieve and process the metric information to correlate different tasks (such as task 204) to determine whether the pending of any given task is due to the pending of another dependent task, that is, linked to the pending of another dependent task. In an example, the correlation parameters can be used to generate one or more visual indicators once determined. In an example, the visual indicators can depict the logical associations between the pending tasks 204. The visual indicators can be presented in the form of shapes, colors, annotations, concept connectors, or a combination thereof.

[0036] In another example, system 210 may generate control instructions for starting pending tasks (from task 204), upon which the completion (or start) of other tasks depends. In this way, any bottlenecks caused by such pending tasks may be resolved. The control instructions thus generated may be based on the underlying workflow to which the pending tasks may correspond. To this end, system 210 may determine task-related parameters for the pending tasks. For the pending tasks, a corresponding workflow may be determined, and executable instructions may be generated corresponding to the workflow. In addition to visual indicators, system 210 may also generate various analyses based on metric information that may have been obtained from repository 208. The analyses may be in the form of charts or other such understandable graphics that can convey meaningful information corresponding to the underlying metric information. The visual indicators and analyses may be presented on an output display (e.g., display 212) communicatively coupled to system 210. In an example, the layout or other functional aspects of the interface providing the visual indicators and / or analyses may be configurable using one or more selectable display elements.

[0037] like Figure 2 The different elements shown in the figure can be used with the network ( Figure 2 The network may be interconnected by a network of networks (not depicted in the figure). In an example, the network may be a private network or a public network and may be implemented as a wired network, a wireless network, or a combination of a wired network and a wireless network. The network may also include a collection of separate networks that are interconnected with each other and act as a single large network, such as the Internet. Examples of such separate networks include, but are not limited to, a Global System for Mobile Communications (GSM) network, a Universal Mobile Telecommunications System (UMTS) network, a Personal Communications Service (PCS) network, a Time Division Multiple Access (TDMA) network, a Code Division Multiple Access (CDMA) network, a Next Generation Network (NGN), a Public Switched Telephone Network (PSTN), Long Term Evolution (LTE), and an Integrated Services Digital Network (ISDN).

[0038] The above-described methods implemented in the organizational environment 200 are exemplary. Other examples are possible without departing from the scope of the present subject matter. Figure 3 These and other examples are explained further. Figure 3 Various functional blocks of the system 210 according to an example are depicted, and one or more functional blocks of the data processing system 210 are illustrated. The system 210 includes a processor 302, an interface 304, and a memory 306. The processor 302 can be implemented as a microprocessor, a microcomputer, a microcontroller, a digital signal processor, a central processing unit, a state machine, a logic circuit, and / or other devices that manipulate signals based on operational instructions. The interface 304 can allow the system 210 to be connected via a wired connection (e.g., a local area network, i.e., a LAN) or via a wireless connection (e.g., a The interface 304 may also enable communication between the different logical components and hardware components of the system 210. The interface 304 may also enable the system 210 to communicate with other entities, such as the repository 208, the output display 212, or other devices or systems.

[0039] The memory 306 may be a computer-readable medium, examples of which include volatile memory (e.g., RAM) and / or non-volatile memory (e.g., erasable programmable read-only memory, i.e., EPROM, flash memory, etc.). The memory 306 may be an external memory or an internal memory, such as a flash drive, an optical drive, an external hard drive, etc. The memory 306 may further include data that may be utilized or generated during operation of the system 210.

[0040] The system 210 may further include an engine 308 and data 310. The engine 308 may be implemented as a combination of hardware and programming (e.g., programmable instructions for implementing the various functionalities of the engine 308). In the examples described herein, such a combination of hardware and programming may be implemented in several different ways. For example, the programming for the engine 308 may be executable instructions. Such instructions may be stored on a non-transitory machine-readable storage medium that may be directly or indirectly (e.g., via networking means) coupled to the system 210. In an example, the engine 308 may include processing resources (e.g., a single processor or a combination of multiple processors) to execute such instructions. In this example, the non-transitory machine-readable storage medium may store instructions that, when executed by the processing resources, implement the engine 308. In other examples, the engine 308 may be implemented as an electronic circuit.

[0041] The engines 308 include task engines 312 and other engines 314. The other engines 314 may further implement functionality that supplements the functions performed by the system 210 or any of the engines 308. On the other hand, the data 310 includes data stored or generated as a result of the functions performed by any of the engines 308 or the system 210. It may be further noted that the engines 308 may utilize the information stored and available in the data 310 for various functions performed by the system 210. In the example, the data 310 may include dependency parameters 316, status information 318, dependency status 320, indicators 322, task dependency parameters 324, task workflow 326, visual elements 328, and other data 330. It may be noted that, as Figure 3 Such examples of the various functional blocks depicted in are indicative. The present method may be applied to other examples without departing from the scope of the present subject matter.

[0042] Combined Figure 2 The operation of the system 210 is explained using various elements of the organizational environment 200 discussed above. In operation, the task engine 312 can determine one or more tasks that may be pending for completion. The tasks can be any of the tasks 204. As previously discussed, the tasks 204 can correspond to one or more stages 202 of a process implemented by an organization such as the organizational environment 200. Although this example has been explained in the context of a single process including multiple stages 202, the present method is equally applicable to other processes that can be implemented by the organizational environment 200.

[0043] Returning to this example, the task engine 312 may determine one or more pending tasks. Considering task 204-2 and task 204-3, this example is explained. Figure 2 As depicted in FIG, task 204-2 corresponds to phase 202-1, while task 204-3 corresponds to phase 202-2. Task 204-2 and task 204-3 are monitored by monitoring applications 206-1 and 206-2, respectively. Monitoring applications 206-1 and 206-2 can monitor the progress of task 204-2 and task 204-3. Information related to task 204-2 and task 204-3 can be obtained by monitoring applications 206-1 and 206-2 and stored in repository 208. In an example, the information related to task 204-2 and task 204-3 can include metric information for such tasks. The metric information can provide values ​​of attributes associated with the corresponding tasks. Examples of such attributes include, but are not limited to, launch events, application or user status, dependencies, and characteristics.

[0044] The task engine 312 can retrieve information related to task 204-2 and task 204-3 from the repository 208. Once obtained, the task engine 312 can process the information from the repository 208 to determine whether task 204-2 is related to task 204-3. In an example, the relevance can be determined based on a relevance parameter 316. The relevance parameter 316 can describe whether the completion of any given task is dependent on or depends on the completion of another related or dependent task. As can be appreciated, in any process that includes multiple stages, the output of one stage can be utilized or provided as input to another stage. Tasks that are dependent on each other do not necessarily correspond to different stages. Tasks can be dependent on each other within a given stage without departing from the scope of the present subject matter.

[0045] Task 204-3 is dependent on task 204-2. Therefore, once task 204-2 has completed, task 204-3 (which is dependent on or related to task 204-2) will be initiated. Therefore, any issues that may have prevented or may be preventing the completion of task 204-2 will also affect the initiation of task 204-3. The linking of task 204-2 to task 204-3 (to depict the pending nature of task 204-3 due to task 204-2) can be specified by dependency parameter 316.

[0046] The dependency parameters 316 can be defined by an administrator linking the tasks, or can be specified by programming that implements a workflow that defines the process to be implemented. In an example, the dependency parameters 316 can be defined by the task engine 312 based on one or more predefined rules. In such cases, the predefined rules can be based on one or more criteria related to one or more tasks 204. The task engine 312 can accordingly determine one or more common criteria between the tasks 204 and accordingly provide dependency parameters 316 that link the tasks to the common criteria. Examples of such criteria can include, but are not limited to, the application or process to which the task 204 can correspond, the priority of the task, or whether the task is linked to one or more other common tasks. It can be noted that other criteria can also rely on such predefined rules, based on which the task engine 312 can define the dependency parameters 316 between one or more tasks 204. In an example, the criteria can be task-related parameters 324 related to the task in question.

[0047] The task engine 312 may use a machine learning model to determine correlation parameters 316 between tasks 204. Such a machine learning model may be initially trained based on a set of previously related tasks. In such an exemplary training data set, one exemplary task may be related or linked to one or more other exemplary tasks, where the exemplary tasks may be related based on historical monitoring within the organizational environment 200. The training data including such related tasks may be trained by the training engine ( Figures 1 to 3 204 ). The machine learning model is used by the task engine 312 to train the machine learning model. The machine learning model, when trained, can then be used by the task engine 312 to define dependency parameters 316 between one or more pending tasks. 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 in the previous example). The training data can also include one or more attributes (which can be historically determined by the monitoring application 206). Other parameters related to the task 204 can also form part of the training data based on which the machine learning model can be trained. When trained, the task engine 312 using the trained machine learning model can determine the dependency parameters 316 for the task 204 accordingly.

[0048] Once the dependency parameters 316 are determined, the task engine 312 can determine status information 318 for the tasks 204-2 and 204-3. In an example, the status information 318 can indicate the status of the corresponding tasks. The status information 318 can depict whether one or more of the tasks 204 are pending or completed. After determining the status information 318 for the tasks 204-2 and 204-3, the task engine 312 can process the status information 318 and the dependency parameters 316 to determine a correlation status 320 for the tasks 204-2 and 204-3. In an example, the correlation status 320 can be used to depict whether the pending status of any given task is due to the pending status of another dependent task.

[0049] If both task 204-2 and task 204-3 are pending, then the correlation state 320 may depict that the pending of task 204-3 is due to the pending of task 204-2. For example, the correlation state 320 may be captured as a flag or similar value within the system 210. Continuing further, the correlation state 320 may be set (e.g., to "1") for both pending tasks 204-2 and 204-3 to indicate that task 204-3 may be pending due to pending task 204-2. In an instance where task 204-2 is not pending but task 204-3 is, the correlation state 320 may be set to "0," thereby depicting that, although pending, task 204-3 may be pending due to other factors other than the pending of some other task.

[0050] In an example, the related state 320 can be used to generate and present an indicator 322 on a display device 212 coupled to the system 210. In an example, the indicator 322 will depict a logical association between the pending of a first task (e.g., task 204-3) and the pending of another second task (e.g., task 204-2). It can be noted that in such cases, the indicator 322 can link the visual representation of task 204-3 to another visual representation of task 204-2, thereby indicating that the pending of task 204-3 is due to the pending of task 204-2, that is, linked to it. The indicator 322 can be presented in different visual forms. For example, the indicator 322 can include a common shape, a common color, a common annotation, a concept connector, or a combination thereof. In related cases, the indicator 322 can be provided for the visual representation of the corresponding related task.

[0051] Combined with Figure 4 The above method is further explained with reference to the exemplary user interface shown in FIG. 5 . Figure 4 An exemplary user interface 400 is depicted. The user interface 400 can be presented on a display device (such as the display device 212) that can be coupled to the system 210 and can be presented based on display instructions generated by the task engine 312. The user interface 400 can include a visual representation or box 402 representing a stage, such as the stage 202-1. The user interface 400 can further include another box 404 representing another stage 202-2. It can be noted that while the present exemplary user interface 400 is shown as displaying boxes 402, 404 for two stages of a given process, the user interface 400 can depict multiple other stages and even processes without departing from the scope of the present subject matter.

[0052] As depicted, phases 202-1 and 202-2 can further include multiple tasks 204, such as task 204-1 and task 204-2, as well as task 204-3 and task 204-4, respectively. The respective tasks 204 can again be represented by separate boxes 406 and 408. Similar to the previous example, task 204-2 and task 204-3 can be related, with both tasks 204-2 and 204-3 pending for completion. Because task 204-2 and task 204-3 are pending and related, the task engine 312 generates an indicator 322 that provides a logical and visual association between task 204-3 and task 204-2.

[0053] exist Figure 4, indicator 322 is depicted as a line 410 linking the visual representation of task 204-3 to task 204-2, where both task 204-2 and task 204-3 are represented as boxes. Although user interface 400 depicts line 410, it should be noted that other indications can be provided by overlaying the visual representation of task 204 with one or more such indications. For example, various icons or other representative elements can overlay task 204-2 and task 204-3 to indicate that task 204-2 and task 204-3 are pending, where line 410 depicts the association of task 204-2 and task 204-3. Such examples are also intended to fall within the scope of the present subject matter.

[0054] Figures 5A to 5B Various other exemplary illustrations are provided of the indicator 322. It is noted that such exemplary illustrations are indicative and are not to be considered as limiting the scope of the present subject matter in any way. Figure 5A Indicator 322 is depicted by representing task 204-2 and task 204-3 with a common shape. In this example, task 204-2 and task 204-3 are related and dependent, as represented by dashed boxes 502 and 504, respectively, as opposed to solid boxes representing other tasks. In another example, boxes 502-504 can be further annotated with additional icons or annotations that can further help identify pending tasks and related tasks. This is in Figure 5B , wherein dashed boxes 502 and 504 are further annotated with information elements depicting one or more information related to corresponding tasks (such as task 204-2 and task 204-3). In this example, annotations 506 and 508 may provide information related to task 204-2 and task 204-3. Examples of such information may include, but are not limited to, the status of the tasks, the tasks on which such current task depends, and the like. It should be noted that such examples are illustrative and are not to be construed as limiting the scope of the present subject matter.

[0055] A dependency status 320 may be provided to the user interface 400 to determine whether the pending nature of any given task is due to the pending nature of another related or dependent task. In the example, upon determining that task 204-2 (due to which task 204-3 is pending) is pending, the task engine 312 may generate one or more control instructions to initiate task 204-2. The initiation of any task may require parameters, values, or inputs based on which the task may be initiated. In the example, the task engine 312 may obtain one or more task-related parameters, values, or inputs corresponding to the pending task 204-2. Task-related parameters 324 may refer to operational settings or configurations (e.g., the nature of input data, operational parameters of task 204-2, etc.) based on which task 204-2 may be implemented. Task-related parameters 324 may also include parameters such as priority, phase details, available resources, and dependencies on other tasks.

[0056] In the event that task 204 is to be implemented by processor-executable instructions, task-related parameters 324 may be specified as one or more variables in such executable instructions. In the example, task-related parameters 324 may also include various performance indicators that may be associated with task 204-2. Task-related parameters 324 may therefore include such aspects that will be relevant to the completion of the task under consideration (in this case, task 204-2).

[0057] Once the task-related parameters 324 are determined, the task engine 312 can identify one or more process workflows. A process workflow includes one or more steps that may need to be performed to complete any given task. The process workflow can be identified based on the task-related parameters 324 of task 204-2. In an example, the determined workflow can be stored in the system 210 as a task workflow 326. Once the task workflow 326 for task 204-2 is determined, the task engine 312 can generate one or more control instructions that, when executed, can cause task 204-2 to be initiated. Once task 204-2 is completed, task 204-3 can be started accordingly. In an example, the task workflow 326 can be generated using various systems or tools. For example, the task workflow 326 can be generated using tools for workflow automation, business process management (BPM) software, etc. In another example, the task workflow 326 can be generated using a workflow generation model based on machine learning. The exemplary workflow generation model can be trained based on a dataset that includes one or more workflows associated with parameters such as the task-related parameters 324. Once trained, task engine 312 using the trained workflow generation model can generate one or more task workflows 326 based on task-related parameters 324 corresponding to pending tasks. These are some examples of how task workflows 326 can be generated; other examples for generating task workflows 326 also fall within the scope of the claimed subject matter. The manner in which task 204-2 can be automated and implemented is applicable to any of tasks 204, regardless of whether they are related to task 204-2.

[0058] Once completed, task 204-2 (since task 204-3 is pending) can be annotated with one or more visual cues. Such visual cues can be in the form of icons. For example, when task 204-2 is pending, task 204-2 can be annotated with a first icon. On the other hand, when it is not completed, task 204-2 can be annotated with another icon. The task engine 312 can also cause the visual appearance of tasks to change when they are completed. For example, the task engine 312 can change the visual representation of task 204-2, which can be depicted in a first color when task 204-2 is pending. Once task 204-2 has been completed, the task engine 312 can change the visual representation of task 204-2 to a different color. Other examples involving changing the visual appearance of one or more tasks can be used without limiting the scope of the present subject matter.

[0059] In an example, the user interface 400 can be configurable, wherein the user interface 400 can be provided with any one or more display elements. The display elements can be of different types. For example, the display elements can include dynamic information elements, static information elements, or control elements. Dynamic information elements can refer to one or more user interface elements that can be populated with dynamic information. Such dynamic information can change in response to user input. Therefore, dynamic information can include output that can be generated by the system 210 in response to user input. Such output can be presented within a dynamic information element. Examples of such dynamic information elements include tables, graphics, or text fields that are populated based on information that can be retrieved from the monitoring application 206. Dynamic information elements can also be used to provide various analyses that are provided based on processing of information related to different tasks 204.

[0060] On the other hand, static information elements can refer to elements that can display static information. Examples of such static information elements include but are not limited to pictures, icons, static text or their combinations. This type of information element can remain consistent during the operating process of system 210. Control elements can include one or more functional elements that can ultimately be used to perform one or more functions. It can be noted that such functions can be implemented in corresponding control elements when activated by user input. In other instances, control elements can execute one or more control instructions when activated, and these control instructions can be integrated in user interface 400 or can be implemented in system 210 (or any other computing system that can be coupled to system 210 communication). Control elements can refer to input controls (such as check boxes, radio buttons, drop-down lists, list boxes, buttons, toggle keys, text fields, date fields, etc.). Control elements can include one or more navigation elements that can allow user interface 400 to be navigated.

[0061] In this example, the task engine 312 can provide a configuration dashboard. The configuration dashboard can refer to a dashboard user interface that can enable selection of one or more display elements that can be provided on the user interface 400. Figure 6 An exemplary configuration dashboard 600 is provided. In an example, the configuration dashboard 600 can be generated or provided by the task engine 312. Continuing further, the configuration dashboard 600 includes an information section 602 and an elements section 604. The information section 602 can initially be blank or can be provided with a set of default display elements. On the other hand, the elements section 604 lists a collection of dynamic information elements, static information elements, and control elements (denoted as elements 606-1, 606-2, ..., 606-N, and collectively referred to as elements 606). The number of elements 606 can vary based on the type of process being implemented or based on the stage 202 that can currently be monitored.

[0062] The elements 606 provided by the task engine 312 on the configuration dashboard 600 are selectable based on user input. For example, a system administrator can select any one or more of the elements 606 from the elements section 604. Once selected, the selected elements can be added to the information section 602. In this way, the task engine 312 can allow configuration of display elements for the user interface 400. The user interface 400 can also include visual representations corresponding to different monitoring applications 206 and multiple tasks. In an example, the configuration dashboard 600 can list such elements 606 that can be related to any one of the stages 202. The configuration dashboard 600 can also depict different stages 202. The selection of any one of the stages 202 can correspondingly provide a filtered list of elements 606, which can be related to any one of the selected stages from the stages 202. Based on the user selection, the selected elements can be added to the information section 602. Once the appropriate elements 606 are added to the information section 602, the task engine 312 can present the user interface 400 with the selected elements 606.

[0063] In the example, the configuration dashboard 600 can be populated with appropriate elements 606 by the task engine 312 using another machine learning model. The machine learning model can be trained based on training data that includes attributes corresponding to different stages 202, or tasks 204 related to one or more attributes of display elements. The machine learning model can be trained by the training engine. Thereafter, the task engine 312 can use the trained machine learning model to automatically determine the elements 606 to be selected for a given stage and add them to the information portion 602 of the configuration dashboard 600. Once configured, the task engine 312 can generate the user interface 400 based on the configuration dashboard 600. It can be noted that other methods for configuring the configuration dashboard 600 can also be employed without departing from the scope of the present subject matter.

[0064] Once configured, the user interface 400 may depict one or more elements, such as element 606, along with visual representations corresponding to different stages 202, tasks 204, or different monitoring applications 206. In an example, the task engine 312 may provide information related to different tasks 204 to different users. The system 210 may implement an authentication mechanism by which users may be authenticated, based on which access to the user interface 400 may be provided. In an example, the number of elements 606, the visual representations corresponding to different stages 202, tasks 204, or different monitoring applications 206 provided may vary based on the user. For example, the stages 202, tasks 204, and monitoring applications 206 may be associated with one or more users.

[0065] To this end, the task engine 312 can display a limited set of elements 606, visual representations corresponding to different stages 202, tasks 204, or monitoring applications 206, based on the user's authentication. In an example, the user credentials can be linked to the stage 202, task 204, or monitoring application 206. Depending on the identity of the logged-in user, the corresponding user interface 400 can be provided. In an example, the role of the user accessing the user interface 400 can be determined, based on which the user interface 400 can be presented. In some cases, historical data can be considered to determine which stages 202, tasks 204, or monitoring applications 206 can be provided when presenting the user interface 400. Other conditions, factors, or predefined rules can also be used to provide the user interface 400 without departing from the scope of the present subject matter.

[0066] Figure 7 A method for associating tasks across different monitored processes according to an example is illustrated. The order in which the above method is described is not intended to be construed as a limitation, and some of the described method blocks can be combined in a different order to implement the method or an alternative method.

[0067] In addition, the above method can be implemented in appropriate hardware, computer-readable instructions or a combination thereof. The steps of such method can be performed by the system under the instructions of machine-executable instructions stored on a non-transient computer-readable medium, or performed by a dedicated hardware circuit, a microcontroller or a logic circuit. For example, the method can be performed by a workflow and task management system (such as system 210). In a specific implementation, the method can be performed under a "as a service" delivery model, wherein the system 210 operated by the provider receives the programmable code. In this article, some examples are also intended to cover non-transient computer-readable media, such as digital data storage media, which are computer-readable and encode computer-executable instructions, wherein the instructions perform some or all of the steps of the above method.

[0068] In an example, method 700 can be implemented by system 210 to determine dependencies between tasks within a workflow, where one or more of such tasks may be pending. Method 700 is explained from the perspective of a first task and a second task, both of which are part of a process implemented within an organization. While this explanation is provided with respect to a first task and a second task, these methods can also be applied to a greater number of tasks. Such specific implementations will also fall within the scope of the present subject matter.

[0069] At block 702, a dependency parameter associated with a first task may be obtained. In an example, the dependency parameter links the first task to the second task and indicates that completion of the second task will cause the first task to be initiated. For example, the task engine 312 may determine the dependency based on the dependency parameter 316. The dependency parameter 316 may describe whether the completion of any given task (say, task 204-3) is contingent upon or dependent upon the completion of another related or dependent task (such as task 204-2). The dependency parameter 316 may be defined by an administrator linking the tasks, or may be specified by programming that implements a workflow that defines a process to be implemented.

[0070] At block 704, first and second status information related to the first and second tasks, respectively, may be determined. The first and second status information may indicate whether either of the first and second tasks is pending at the current moment. For example, the task engine 312 may determine status information 318 for task 204-2 and task 204-3. The status information 318 may, in turn, indicate the status of the corresponding tasks. For example, the status information 318 may indicate whether any one or more of the tasks 204 are pending or have been completed.

[0071] At block 706, the dependency parameter can be processed along with the first state information and the second state information to determine a dependency state of the first task relative to the second task. For example, once the state information 318 for task 204-2 and task 204-3 is determined, the task engine 312 can process the state information along with the dependency parameter 316 to determine a dependency state 320 for task 204-2 and task 204-3. The dependency state 320 indicates whether the pending of any given task is due to the pending of another dependent task. If dependent tasks 204-2 and 204-3 are pending, the dependency state 320 can depict that the pending of task 204-3 is due to the pending of task 204-2. The dependency state 320 can be captured as a flag or similar variable value within the system 210. Further, if tasks 204-2 and 204-3 are pending and indicate that task 204-3 may be pending due to the incompleteness of task 204-2, the dependency state 320 can be set (e.g., to "1").

[0072] At block 708, a visual indicator may be generated based on the related state. The visual indicator will provide a logical association linking the pending of the first task with the pending of the second task. The visual indicator may be provided on a user interface. For example, the task engine 312 may generate and present an indicator 322 based on the related state 320. The indicator 322 may be presented on a display device 212 that may be communicatively coupled to the system 210. The indicator 322 presented in this manner will depict the logical association between the pending of a first task (e.g., task 204-3) and the pending of another second task (e.g., task 204-2). It may be noted that in such a case, the indicator 322 may link the visual representation of task 204-3 to another visual representation of task 204-2, thereby indicating that the pending of task 204-3 is due to or linked to the pending of task 204-2. The indicator 322 may take different visual forms. For example, the indicator 322 may include a common shape, a common color, a common annotation, a concept connector, or a combination thereof.

[0073] Figure 8 Another method for associating tasks across different monitored processes according to another example is illustrated.The order in which the above methods are described is not intended to be construed as a limitation, and some of the described method blocks can be combined in a different order to implement these methods or alternative methods.

[0074] In addition, the above methods can be implemented in appropriate hardware, computer-readable instructions or a combination thereof. The steps of such methods can be performed by the system under the instructions of machine-executable instructions stored on a non-transient computer-readable medium, or performed by a dedicated hardware circuit, a microcontroller or a logic circuit. For example, these methods can be performed by a workflow and task management system (such as system 210 or system 102). In a specific implementation, these methods can be performed under a "as a service" delivery model, where system 102 or system 210 receives programmable code. In this article, some examples are also intended to cover non-transient computer-readable media, such as digital data storage media, which are computer-readable and encode computer-executable instructions, where the instructions perform some or all of the steps of the above methods.

[0075] At block 802, information related to one or more tasks of a process implemented in an organization is obtained. For example, the task engine 312 may obtain information related to task 204-2 and task 204-3. In this example, task 204-2 corresponds to stage 202-1, while task 204-3 corresponds to stage 202-2. Task 204-2 and task 204-3 are monitored by monitoring applications 206-1 and 206-2, respectively, which can monitor the progress of tasks 204-2 and 204-3. Information related to tasks 204-2 and 204-3 may be obtained by monitoring applications 206-1 and 206-2 and stored in repository 208. In this example, the information related to tasks 204-2 and 204-3 may include metric information for such tasks. The metric information may provide values ​​for attributes associated with the corresponding tasks. Examples of such attributes include, but are not limited to, launch events, application or user status, dependencies, and characteristics.

[0076] At block 804, status information associated with the tasks may be determined. The status information so determined may indicate whether the corresponding tasks are pending. For example, the task engine 312 may determine whether task 204-2 and task 204-3 are pending based on metric information such as obtained by one or more monitoring applications 206. In this example, the information associated with the different tasks may include status information 318 corresponding to task 204-2 and task 204-3. Based on the status information 318, the status information 318 for task 204-2 or task 204-3 is pending.

[0077] At box 806, the dependencies between one or more tasks can be determined. For example, the task engine 312 can process the information (e.g., metric information) of the corresponding tasks to determine whether task 204-2 and task 204-3 are related. In the example, the dependencies can be determined based on dependency parameters 316. The dependency parameters 316 can depict whether the completion of any given task depends on or is dependent on the completion of another related or dependent task. As can be understood, in any process that includes multiple stages, the output of one stage can be utilized or provided as the input of another stage. The dependency parameters 316 can be defined by an administrator or can be defined based on one or more predefined rules. Without departing from the scope of this theme, other examples by which the dependency parameters 316 can be defined can also be implemented.

[0078] At block 808, the dependency status of the pending tasks can be determined. For example, the task engine 312 can process the status information 318 of task 204-2 and task 204-3, as well as the dependency parameters 316 between task 204-2 and task 204-3, to determine a dependency status 320. In an example, the dependency status 320 can depict whether the pending of any given task is due to the pending of another dependent task. As also previously explained, if the dependent tasks 204-2 and 204-3 are pending, the dependency status 320 can depict that the pending of task 204-3 is due to the pending of task 204-2. In an example, the dependency status 320 can be represented as a flag, a variable, or the like.

[0079] At box 810, the related state can be used to generate an indicator that logically associates the pending of a given task with another pending task. For example, the task engine 312 can generate an indicator 322 on the display device 212 coupled to the system 210. In addition, the indicator 322 depicts the pending logical association of a first task (for example, task 204-3) with the pending of another second task (for example, task 204-3). It can be noted that in such cases, the indicator 322 can also link the visual representation of task 204-3 to another visual representation of task 204-2, thereby indicating that the pending of task 204-3 is due to the pending of task 204-2 or is linked to it. The indicator 322 can be in different visual forms. For example, the indicator 322 can include a common shape, a common color, a common annotation, a concept connector, or a combination thereof.

[0080] At block 812, one or more task-related parameters may be obtained. For example, the task engine 312 may obtain one or more task-related parameters corresponding to task 204-2. As previously discussed, the task-related parameters may be stored within the system 210 as task-related parameters 324. Examples of such task-related parameters 324 include, but are not limited to, operational settings or configurations (e.g., the nature of input data, operational parameters of task 204-2, etc.) based on which task 204-2 may be implemented. Task-related parameters 324 may also include parameters such as priority, details of the phase, available resources, and dependencies on other tasks. In the example, task-related parameters 324 may also include various performance indicators that may be associated with task 204-2.

[0081] At block 814, one or more process workflows may be determined based on the task-related parameters. For example, the task engine 312 may identify one or more process workflows based on the task-related parameters 324. The process workflows thus determined may include one or more steps that may have to be performed to complete any given task. With respect to task 204-2, the task engine 312 may determine the process workflow based on the task-related parameters 324 corresponding to task 204-2. In a similar manner, the task engine 312 may determine the process workflow for task 204-3 based on the task-related parameters 324 corresponding to task 204-3. In the example, the process workflows may be predefined and stored as task workflows 326.

[0082] At block 816, one or more control instructions for starting the pending task may be generated. For example, the task engine 312 may generate one or more control instructions when determining the corresponding task workflow 326. The control instructions may cause the startup of task 204-2 when executed. Once task 204-2 is completed, task 204-3 (which is pending due to the pending of task 204-2) may be started accordingly. The task workflow 326 may be defined by an administrator of the system 210. In another example, the task workflow 326 may be generated using various systems or tools, examples of which include, but are not limited to, tools for workflow automation, business process management (BPM) software, and the like. Once completed, task 204-2 may be annotated with one or more visual cues to indicate its completion. Alternatively, another visual indication may be used without departing from the scope of this subject matter.

[0083] Figure 9 A computing environment 900 is illustrated that implements a non-transitory computer-readable medium for processing a file that includes data corresponding to multiple control systems for managing alarms in an industrial system. In the example, the computing environment 900 includes a processor 902 that is communicatively coupled to a non-transitory computer-readable medium 904 via a communication link 906. In an exemplary implementation, the computing environment 900 can be, for example, the system 210. In the example, the processor 902 can have one or more processing resources for retrieving and executing computer-readable instructions from the non-transitory computer-readable medium 904. The processor 902 and the non-transitory computer-readable medium 904 can be implemented, for example, in the event processor 218 (as described in conjunction with the previous figures).

[0084] The non-transitory computer readable medium 904 may be, for example, an internal memory device or an external memory device. In an exemplary implementation, the communication link 906 may be a network communication link. The processor 902 and the non-transitory computer readable medium 904 may also be communicatively coupled to a computing device 908 via a network.

[0085] In an exemplary implementation, the non-transitory computer-readable medium 904 may include a set of computer-readable instructions 910 (referred to as instructions 910 ) that may be accessed by the processor 902 via the communication link 906 . Figure 9 In an example, the non-transitory computer readable medium 904 includes instructions 910 that cause the processor 902 to provide a dashboard user interface to a display device (such as the display device 212) coupled to a system (such as the system 210). In an example, the dashboard user interface can be the exemplary user interface 400 (such as in conjunction with Figure 4 described).

[0086] In addition, the dashboard user interface (e.g., user interface 400) may depict one or more tasks, such as task 204. Task 204 may be part of a process implemented within an organization. In an example, tasks 204 may include a first task (e.g., task 204-2) and a second task (e.g., task 204-3). Instructions 910 may further cause a dependency parameter (e.g., dependency parameter 316) associated with the first task (e.g., task 204-2) to be retrieved. In the example, dependency parameter 316 links task 204-2 to the second task (i.e., task 204-3). Furthermore, the dependency parameter indicates that completion of task 204-3 will cause task 204-2 to be initiated. It may be noted that the dependency of task 204-2 on task 204-3 is an example. Without departing from the scope of the present subject matter, task 204-3 may be dependent on task 204-2 (or any of tasks 204).

[0087] Once the dependency parameter 316 is determined, the instructions 910, when executed, will determine first state information and second state information related to the first task and the second task. In the example, for task 204-2 and task 204-3, the first state information and the second state information can be captured as state information 318. In the example, the state information 318 will indicate the state of task 204-2 or task 204-3 (i.e., whether the task is pending, completed, etc.).

[0088] Once the state information 318 is determined, the instructions 910, when processed, may cause the dependency parameters 316 to be used together with the state information 318 for the tasks 204-2 and 204-3 to determine a dependency state, such as the dependency state 320. In an example, the dependency state 320 may be used to depict whether the pending of any given task is due to the pending of another dependent task. If the dependent tasks 204-2 and 204-3 are pending, the dependency state 320 may depict that the pending of the task 204-3 is due to the pending of the task 204-2.

[0089] Upon determining the correlation state 320, instructions 910 may accordingly generate a visual indicator on the dashboard user interface based on the correlation state of the first task (e.g., task 204-2). The visual indicator (i.e., indicator 322) will depict the logical association between the pending of task 204-2 and the pending of task 204-3.

[0090] Although the examples of the present disclosure 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. Instead, these specific features and methods are disclosed and interpreted as examples of the present disclosure.

Claims

1. A system, comprising: processor; as well as A machine-readable storage medium comprising instructions executable by the processor to: For a first task and a second task of a process implemented within an organization, obtaining a dependency parameter associated with the first task, wherein the dependency parameter links the first task to the second task and indicates that completion of the second task will cause initiation of the first task; determining first status information and second status information related to the first task and the second task, respectively, wherein the first status information and the second status information indicate whether either the first task or the second task is pending; processing the dependency parameter, the first state information, and the second state information to determine a dependency state of the first task relative to the second task; as well as A visual indicator is caused to be generated based on the related status of the first task, wherein the visual indicator depicts a logical association of the pendency of the first task and the pendency of the second task.

2. The system of claim 1 , wherein the instructions are executable to further: If the second status information indicates that the second task is pending, generating a control instruction, wherein the control instruction, when executed, will cause the second task to be launched; and The second status information is monitored to determine completion of the second task.

3. The system of claim 2, wherein to generate the control instructions, the instructions are executable to further: determining task-related parameters corresponding to the second task; identifying a process workflow including base parameters corresponding to the task-related parameters; and The control instructions are generated based on the identified process workflow.

4. The system of claim 2 , wherein upon completion of the second task, the instructions are executable to cause one of the following to occur: generating a visual cue for a user of the system, wherein the visual cue prompts completion of the second task and initiation of the first task; and Another control instruction is generated, wherein the another control instruction will initiate the first task, another set of tasks, or a combination thereof. 5 . The system of claim 1 , wherein the relevance parameter associated with the first task is defined based on one of user input and a set of predetermined rules, wherein the predetermined rules specify a set of criteria related to the first task and the second task.

6. A method comprising: obtaining a dependency parameter associated with a first task, wherein the dependency parameter links the first task to a second task and indicates that completion of the second task will cause initiation of the first task, and wherein the first task and the second task are processes implemented within an organization; determining first status information and second status information related to the first task and the second task, respectively, wherein the first status information and the second status information indicate whether either of the first task and the second task is pending; processing the dependency parameter, the first state information, and the second state information to determine a dependency state of the first task relative to the second task; as well as The logical association of the pendency of the first task and the pendency of the second task is represented by a visual indicator, wherein the visual indicator is generated based on the related status of the first task and presented on a dashboard user interface.

7. The method according to claim 6, wherein the method comprises: generating a control instruction to cause initiation of the second task after second status information indicates that the second task is pending; as well as The second status information is monitored to determine completion of the second task.

8. The method according to claim 7, wherein generating the control instruction comprises: determining task-related parameters corresponding to the second task; identifying a process workflow including base parameters corresponding to the task-related parameters; as well as The control instructions are generated based on the identified process workflow.

9. The method according to claim 6, wherein the method comprises: presenting the dashboard user interface on a communicatively coupled display, wherein the dashboard user interface provides: a first display element corresponding to a first monitoring application monitoring the first task; as well as A second display element corresponds to a second monitoring application that monitors the second task.

10. The method of claim 9, wherein presenting the dashboard user interface comprises: determining a user identifier of a user attempting to interact with the dashboard user interface; providing an information section and an elements section on the dashboard user interface, wherein the elements section lists a set of dynamic information elements, static information elements, and control elements, wherein the set of dynamic information elements, static information elements, and control elements is provided based on the user identifier; receiving, by user input from the user, a selection of an element from the set of the dynamic information elements, the static information elements, and the control elements; as well as In response to the selection received via the user input, the element is added to the information portion.

Images