JP7801385B2 - Data linkage system, data linkage method and data linkage program - Google Patents

Description

The present invention relates to a data linkage system, a data linkage method, and a data linkage program.

An example of a data linkage system is the technology described in Japanese Patent Application Laid-Open No. 2000-172770 (Patent Document 1). This publication states that "Operations and return values issued between a workflow management system and an application system such as an ERP system are converted using a pre-created data conversion rule database and operation conversion rule database, and then reissued in the recipient's format. In addition, monitored items are set, and if a data item is changed in either the workflow management system or the application system, the change is notified to the other system and automatically updated."

Japanese Patent Application Laid-Open No. 2000-172770 JP 2014-154120 A

Patent Document 1 describes how, when a data item in a business flow is changed, the data item in an application linked to that business flow is changed. Furthermore, Patent Document 2 describes how, for a main business flow and multiple secondary business flows that branch off from the main business flow, the main business flow manages the progress of the secondary business flows.

When linking a supply chain, which is a business flow related to supply, the final information from the preceding business flow is used as input for the succeeding business flow, but this method does not allow data to be linked when multiple business flows are running in parallel.

Patent Document 1 describes a method for reflecting data changes in a business flow in an application, but does not describe linking data when multiple business flows proceed in parallel. Furthermore, Patent Document 2 describes a method in which a main business flow manages a secondary business flow when the main and secondary business flows proceed in parallel, but does not describe linking data between the main and secondary business flows.

The present invention therefore aims to provide a data linkage system, data linkage method, and data linkage program that can link data between business flows that proceed in parallel.

To achieve the above objective, one representative data linkage system of the present invention is a data linkage system that links data between multiple business flows. The system includes a storage unit that stores business flow case data, including the business flows consisting of multiple linked business operations and information on the cases handled by the business flows, and linkage target data, including information maintaining the relationship between linkage source data items and linkage destination data items among the data items linked between the business flows. The system also includes a business data mapping unit that maps and links business data related to a first linkage source data item of a first main business flow among the business flows with business data related to a first linkage destination data item of a first sub-business flow, which is the business flow that receives data from the first main business flow and executes business. The business data mapping unit links business data related to the first linkage source data item of the first main business flow with business data related to the first linkage destination data item of the first sub-business flow during the execution of a first business operation related to the first linkage source data item of the first main business flow.

This invention enables data linkage between business flows that proceed in parallel. Issues, configurations, and advantages other than those mentioned above will become clear from the description of the embodiments below.

FIG. 2 is an explanatory diagram of data linkage according to the first embodiment. FIG. 2 is a diagram illustrating the configuration of a computer that realizes the system according to the first embodiment. FIG. 3 is an explanatory diagram of a specific example of business data according to the first embodiment. FIG. 4 is an explanatory diagram of a specific example of mapping data according to the first embodiment. FIG. 10 is an explanatory diagram of a specific example of the implemented tenant data according to the first embodiment. FIG. 4 is an explanatory diagram of a specific example of business flow data according to the first embodiment. FIG. 10 is an explanatory diagram of a specific example of business flow case data. FIG. 4 is an explanatory diagram of a specific example of linked target data according to the first embodiment. FIG. 4 is an explanatory diagram of a specific example of mapping data according to the first embodiment. 10 is a flowchart showing a processing procedure for generating a business flow and linking data according to the first embodiment. 10 is a flowchart showing a processing procedure when data is changed according to the first embodiment. FIG. 4 is an explanatory diagram of an output screen of the system according to the first embodiment. FIG. 10 is an explanatory diagram of data linkage according to the second embodiment. FIG. 10 is an explanatory diagram of a specific example of linked target data according to the second embodiment.

The following describes the examples using drawings.

Figure 1 is an explanatory diagram of data linkage according to Example 1. In this example, we will explain data linkage in a system that manages a supply chain for delivering products, particularly regenerative medicine products, by linking product wholesalers, delivery companies, and destination medical institutions through a business flow, which is a chain of operations.

Figure 1 is a conceptual diagram of a business flow, with circular shapes representing the tasks or events of each business flow. A task represents the work performed by a stakeholder, and an event refers to an occurrence in which data is linked to another business flow when the work of one business flow is performed, and is created in the business flow to which the data is linked.

Examples of tasks include registering product delivery quantities, delivery requests, and delivery company input. In this system, tasks or events are treated as nodes, and the supply chain is managed using a workflow in which nodes are connected by links. In this embodiment, these workflows are called cases, and a case ID is assigned so that each workflow can be uniquely identified. The progress of each case is then managed by associating implementation history and other information with each node.

In addition, the progress of each project is managed using business flow data. Business flow data is data that associates a project ID, which uniquely identifies the project, with various information related to that project. Note that the nodes shown in Figure 1 show the project name and the data that will be registered in the system as project data for that project.

There are two workflows for executing deliveries: a main workflow that manages the number of deliveries possible and executes the delivery work, and a secondary workflow that requests deliveries within the number of deliveries possible and manages the request until it is administered to the patient.

Here, we will explain the definitions of main workflows and secondary workflows in this invention. Main workflows and secondary workflows refer to workflows that have a relative relationship. A workflow that performs a task to manufacture, process, complete, or prepare goods, products, or parts is called a main workflow, and a workflow that performs a task by receiving goods, products, or parts from the main workflow is called a secondary workflow. Note that multiple secondary workflows may be linked to a main workflow. In other words, goods, etc. from the main workflow may be supplied to multiple secondary workflows.

In Figure 1, Case 1 is the main business flow. In this example, a case is created when task A1, "Register delivery quantity," is performed. At this time, the scheduled delivery date of 2023/8/31 and the deliverable quantity of 8 are registered in the system as case data for Case 1. In this example, the deliverable quantity is the number of products that a wholesaler can deliver to a medical institution on a specific day. Medical institutions have already purchased or plan to purchase products from pharmaceutical companies, etc., and wholesalers manage the product purchase quantities for each medical institution. For example, the number of products that can be delivered on the specific day of 2023/8/31 is 8.

In Figure 1, Case 11 is a sub-workflow. In this example, first, Task A11 "Delivery Request" is executed for Case 1 in the main workflow. If the delivery request can be executed, the delivery request is executed, and a case in the sub-workflow is generated. Then, in the main workflow, an event "Delivery Request Confirmation" is generated. At this time, the number of delivery requests, 2, is registered in the system as workflow data for Case 11, and is linked to the data on the number of deliveries possible for Case 1 in the main workflow (Event B1).

As a result, the "Available Delivery Quantity" for Item 1 will be linked to the "Number of Delivery Requests" for Item 11, and the number of products that can be delivered on 8/31 for Item 1 will be 6 (8 units minus the number of delivery requests for Item 11, 2). Details on how data is linked will be explained later.

In Figure 1, Case 12 is a sub-workflow. As with Case 11, Task A12 "Delivery Request" is executed for Case 1 in the main work flow, creating a sub-workflow case. At this time, the number of delivery requests (5) is registered in the system as work flow data for Case 12, and is linked to the data on the number of deliveries available for Case 1 in the main work flow (Event C1).

As a result, the "Available Delivery Quantity" for Item 1 is linked to the "Number of Delivery Requests" for Item 11 and Item 12, and the number of products available for delivery on 8/31 for Item 1 is 8 minus the number of delivery requests for Item 11 (2) and the number of delivery requests for Item 12 (5), resulting in 1. In other words, changes made in all sub-workflows linked to the main workflow are reflected immediately. For this reason, even when the management granularity of the workflows differs, such as when there are multiple sub-workflows linked to a main workflow, the work carried out in the main workflow and sub-workflows can proceed smoothly.

In Figure 1, after performing task B11 "Enter shipping information," case 11 performs task C11 "Change delivery request quantity," changing the number of delivery requests from 2 to 1. Furthermore, after changing the number of delivery requests, case 1 performs task C1 "Register shipping box."

At this time, the number of delivery requests, 1, is registered in the system as business flow data for Item 11 and linked to the data on the number of deliveries available for Item 1 in the main business flow (Event D1). As a result, the "number of delivery requests" for Item 11 and Item 12 are linked to the "number of deliveries available" for Item 1, and the number of products available for delivery on 8/31/2023 for Item 1 is 8 minus the number of delivery requests for Item 11 (1) and the number of delivery requests for Item 12 (5). Furthermore, Task C1 "Register shipping box" is then executed, and the number of shipping boxes, 6, is registered in the system as business flow data for Item 1 on the scheduled delivery date, 8/31/2023.

At this time, in the business flow of Item 1, before carrying out task C1, delivery request approval is carried out for task A1 "Delivery Quantity Registration." Delivery request approval is a task in the business flow of Item 1 to approve delivery requests that have been accepted from sub-business flows Item 11 and Item 12 up to this point, and is carried out after task A1 "Delivery Quantity Registration" is carried out and immediately before "Shipping Box Registration" is carried out. After the delivery request is approved, new delivery requests and changes to existing delivery requests are not accepted, and the delivery quantity in the business flow of Item 1 is finalized. By accepting data linkage related to the business while the business is being carried out in this way, when the main business flow and sub-business flow are carried out in parallel while linking specific data items, data linkage from the sub-business flow can be accepted in accordance with the progress of the main business flow.

Figure 2 is a configuration diagram of a computer 1 that realizes the system according to Example 1. The computer 1 shown in Figure 2 has an interface unit 21, a control unit 22, and a storage unit 23.

A computer 1, acting as a data linkage system that executes a data linkage method for linking data between multiple business processes, communicates with one or more terminals 2 via a communications network NT. The communications network NT is a mobile wireless communications network capable of high-capacity, high-speed communications, such as a fifth-generation mobile communications system. Base stations, switches, and other components of the mobile wireless communications network are not shown in Figure 2.

Terminal 2 is a mobile terminal capable of communicating with computer 1 via communication network NT. However, communication network NT and terminal 2 are not limited to these. In other words, communication network NT may be either a wireless line or a wired line, and may be either a public network or a closed network. Furthermore, terminal 2 may be any computer with communication capabilities, whether portable or stationary.

The interface unit 21 accepts input from an operator of the terminal 2, for example, via the communications network NT, and provides the operator with an operation screen displayed on the display screen of the terminal 2 via the terminal 2. Operators include builders who build supply chain models, operators who set access restrictions, and executors who carry out tasks involved in the supply chain.

The interface unit 21 can provide separate operation screens for the builder, operator, and executor.

The control unit 22 is, for example, a CPU (Central Processing Unit) and realizes various functions by expanding and executing programs in memory (not shown). The memory unit 23 is a storage medium such as a magnetic storage device and is used to store various data.

Specifically, the control unit 22 operates as a business flow management unit 31, a business flow generation unit 32, a business data mapping unit 33, an implementation tenant data management unit 34, and an access control unit 35.

The memory unit 23 stores case data 41, which associates a case ID that uniquely identifies the case with various information related to the case (product name, pharmaceutical company name), and business flow data 42, which stores data implemented in a business flow for each business. The memory unit 23 also stores business flow case data 43, which stores data items related to the product of the case related to the business flow, and linkage target data 44, which stores data items that are linked between business flows. The memory unit 23 also stores mapping data 45, which associates and manages business flows and data items related to data that is linked between business flows. The memory unit 23 also stores implementation tenant data 46, which associates cases with tenants, and area data 47, which associates implementation tenants with the areas to which the tenants belong.

The business flow management unit 31 stores and manages supply chain business flow data 42 in the memory unit 23. The business flow management unit 31 also stores and manages data items related to products of business flow cases as business flow case data 43 in the memory unit 23.

The business flow generation unit 32 generates a business flow for the supply chain and issues a case ID corresponding to the business flow. The business flow management unit 31 associates the generated business flow data with the case ID and stores it as business flow data 42 in the memory unit 23.

The business data mapping unit 33 links data items between business flows and generates mapping data 45 that associates and manages the business flows and data items related to the linked data between business flows. When there is a change in the data at the data link destination, the business data mapping unit 33 links and changes the data at the data link source based on the mapping data 45.

The implementing tenant data management unit 34 generates implementing tenant data 46 by associating the identification information of the tenant performing the business with the identification information of the case, and stores the data in the storage unit 23. Specifically, when a new case is registered, the implementing tenant data management unit 34 generates implementing tenant data 46 by pre-associating the implementing tenant with each business of the new case. Note that, when data on the area to which the implementing tenant belongs is provided, area data 47 that associates the implementing tenant with each area may be generated and stored in the storage unit 23.

When the access control unit 35 receives access from a user such as a business executor, it controls access based on the tenant assigned to that user. Specifically, when the access control unit 35 receives access from a business executor, it references the implementation tenant data 46 and permits access for the case associated with the tenant to which the executor belongs.

Figures 3A, 3B, 3C, 4A, and 4 are explanatory diagrams of specific examples of data.

Project data 41 shown in Figure 3A associates a project ID that uniquely identifies the project with various information related to the project (product name, pharmaceutical company name). Area data 47 shown in Figure 3B associates areas with stakeholders involved in projects within those areas. In Figure 3B, the area "Tokyo Area" and tenants "Medical Institution A," "Medical Institution B," "Wholesale Company A," and "Delivery Company A" are registered, respectively. In this way, if multiple stakeholders are involved in an area, it is sufficient to register as many as the number of stakeholders involved in the area.

The implementing tenant data 46 shown in Figure 3C is data that associates a case ID with the facility that will carry out the work for that case or the facility that will view the business data for that case. In Figure 3C, the combinations of case ID "1" and tenants "Medical Institution A," "Medical Institution B," "Wholesale Company A," and "Delivery Company A" are each registered. In this way, if multiple stakeholders are involved in a case, it is sufficient to register the same number of case ID and tenant combinations as the number of involved stakeholders.

The system disclosed in this embodiment uses this implementation tenant data 46, which associates project IDs with tenants, to implement access control so that only stakeholders involved in a project can access the project's business flow data, thereby maintaining the confidentiality of information.

In the implementing tenant data 46 shown in Figure 3C, delivery companies a and b/medical institutions a and b/wholesale company A are associated with case ID 1 as implementing tenants. Furthermore, delivery company a/medical institution a/wholesale company A are associated with case ID 11. Therefore, medical institution a can grasp not only the data for case 11, which is managing its own delivery requests, but also the data for case 1, which relates to the number of deliveries that can be made. In other words, data from the main business flow can also be confirmed from the secondary business flow, making it easy to link data from the secondary business flow to the main business flow (e.g., delivery requests).

The business flow data 42 shown in Figure 4A stores data for each business performed in the business flow. In Figure 4A, data related to the business or event (type, labels and data of registered items for the business or event) is stored in the business/event ID that uniquely identifies the business or event performed in the business flow related to case ID1 and ID11.

The workflow case data 43 shown in Figure 4B stores data items related to the products of the workflow cases associated with the workflow case ID. In Figure 4B, the data items related to the product of case ID 1 include "Available Delivery Quantity" and "Scheduled Delivery Date," and the values of these items are "8" and "8/31/2023," respectively. It should be noted that workflow case data may be aggregated and managed for workflows in which the data items related to the products of the workflow cases match or partially match. For example, the workflow for case 1 shown in Figure 1 is the main workflow, and the workflows for cases 11 and 12 shown in Figure 1 are sub-workflows. Therefore, the workflow data for case 1 may be managed as main workflow case data 43-1, and the workflow data for cases 11 and 12 may be managed as sub-workflow case data 43-2.

The linked data 44 shown in Figure 4C stores data items that are linked between business flows. In Figure 4C, the data link source is the "number of deliveries available," and the data link destination is the "number of delivery requests." The number of delivery requests, which is the data link destination, represents the number of products that a medical institution plans to administer on a specific day, and the number of deliveries available, which is the data link source, represents the number of products that a wholesaler can deliver on a specific day. For example, if the number of delivery requests at the data link destination increases, the data is linked so that the number of deliveries available at the data link source decreases accordingly.

The mapping data 45 shown in Figure 4D is data that links the case ID of the main workflow case and the data item that is the data link source with the case ID of the secondary workflow case and the data item that is the data link destination. In Figure 4D, the combinations of the case ID "1" of the main workflow case and the data link source "Available deliveries" and the case IDs "11", "12" and "Number of delivery requests" of the secondary workflow cases are registered. In this way, when a main workflow case is linked to multiple secondary workflow cases, it is sufficient to register the same number of combinations of the main workflow case and multiple secondary workflow cases as there are linked secondary workflow cases.

Figure 5 is a flowchart showing the steps for creating a business flow case.

(S101) When the workflow generation unit 32 receives input for a task related to a main workflow, it issues a case ID corresponding to the main workflow and generates a main workflow. In the example shown in Figure 1, this corresponds to the creation of a case by performing a delivery quantity registration task.

(S102) When the main workflow is generated, the workflow management unit 31 registers workflow data 42 related to the main workflow in the storage unit 23. Data items related to the products of the case related to the main workflow may also be registered in the storage unit 23 as workflow case data 43. In the example shown in Figure 1, this corresponds to the scheduled delivery date and the number of deliveries possible being registered as workflow data for Case 1.

(S103) The business data mapping unit 33 accepts a data linkage request entered by one of the implementing tenants related to the main business flow case by referencing the business flow case data of that case. In the example shown in Figure 1, this corresponds to the implementation of a data linkage request for case 1 by implementing business A11 "Delivery Request."

(S104) The business data mapping unit 33 checks whether it is possible to accept a data linkage request for the main business flow case, and if it is possible to accept it, proceeds to S1055. If it is not possible to accept it, the data linkage request is rejected. In the example shown in Figure 1, this corresponds to executing a check process to see if the "number of delivery requests" entered as the data linkage request is less than or equal to the "number of deliveries possible" for case 1. If the number of delivery requests is less than or equal to the number of deliveries possible, the data linkage request is accepted, and if the number of delivery requests is greater than the number of deliveries possible, the data linkage request is rejected.

(S105) Based on the data linkage request received via the input unit (not shown), the workflow generation unit 32 issues a case ID for the secondary workflow linked to the case of the main workflow, and generates a secondary workflow. The workflow management unit 31 then registers the business/event information in the workflow data 42. In the example shown in FIG. 1, this corresponds to generating a workflow for Item 11 as a secondary workflow linked to the main workflow for Item 1, and registering the number of delivery requests as workflow data for Item 11. This also corresponds to registering an event indicating that Item 11 has been linked to Item 1 as workflow data.

(S106) The business data mapping unit 33 links data items between the business flows of the main business flow and the secondary business flow, and generates mapping data 45 that associates and manages the business flows and data items related to the linked data between business flows. S106 is the business data mapping procedure. In the example shown in Figure 1, the "number of deliverables" of the main business flow related to Item 1 is mapped as the data link source, and the "number of delivery requests" of the secondary business flow related to Item 11 is mapped as the data link destination, and registered as mapping data 45.

Figure 6 is a flowchart showing the procedure for changing the number of delivery requests in a sub-workflow.

(S201) The business data mapping unit 33 receives a request from one of the implementing tenants related to the sub-business flow case to change the linked data for the main business flow case using the sub-business flow case. In the example shown in Figure 1, performing the delivery request quantity change task corresponds to a request to change the linked data for case 1 in the main business flow.

(S202) When the business data mapping unit 33 receives a request to change linked data, it checks whether the request to change linked data can be accepted, and if it can be accepted, proceeds to S203. If it cannot be accepted, the request to change linked data is rejected. In the example shown in FIG. 1, this corresponds to the execution of a check process to determine whether the number of delivery requests is equal to or less than the "number of deliveries possible" for case 1 as a result of changing the "number of delivery requests" input as the request to change linked data. If the number of delivery requests is equal to or less than the number of deliveries possible, the request to change linked data is accepted. If the number of delivery requests is greater than the number of deliveries possible, the data linkage request is rejected.

(S204) When the linkage data change request is received, the business flow management unit 31 changes the sub-business flow case data and registers the changed number of delivery requests in the business flow data.

(S205) The business flow management unit 31 links the changed number of delivery requests to the main business flow case due to the change in the number of delivery requests, and registers the changed number of deliveries possible for the main business flow case in the business flow data as business and event information.

Figure 7 is an example of an output screen D11 related to Example 1. Output screen D11 is displayed on the display unit (not shown) of terminal 2. As shown in output screen D11, computer 1 as a data linkage system can present the value of the deliverable quantity, which is the data link source as of August 31, 2023, to the implementing tenant of case 1 via interface unit 21. Computer 1 can also present the IDs of the cases (cases 11 and 12) that will receive supply from case 1. Computer 1 can also present the value of the delivery request quantity, which is the data link destination, and the approval status of the delivery request work. The output unit (not shown) of computer 1 associates the data shown in Figure 7 and outputs it as output screen D11. This allows the implementing tenant of case 1 to understand the progress of the business flow related to case 1 and the status of delivery requests from other business flows.

In this example, the management of a supply chain for regenerative medicine products is illustrated, and data linkage in a system that manages a supply chain for delivering regenerative medicine products in particular, in which a wholesaler of the product works in cooperation with a delivery company and the medical institution at the delivery destination, is used as an example. The supply chain for regenerative medicine products is merely one example, and the present invention can be used in any supply chain.

In the same way as in Example 1, Example 2 will be explained using a business flow, which is a chain of operations, particularly using data linkage for regenerative medicine products as an example. The data linkage system manages a supply chain for regenerative medicine products, in which product wholesalers, delivery companies, and destination medical institutions work together to deliver the products, and a supply chain in which pharmaceutical companies that sell the products work together with product wholesalers to sell the products. Differences between Example 2 and Example 1 will be explained in detail.

Figure 8 shows an example of hierarchical data linkage between business flows in Example 2. The business flow in Example 2 consists of multiple layers, and at each layer, the main business flow and sub-business flow are linked, with the main business flow at a certain layer being the sub-business flow at the layer immediately above.

In this example, the product sales quantity is the number of products that a pharmaceutical company can sell to a wholesaler on a specific day. Wholesalers can purchase products from pharmaceutical companies, etc., and pharmaceutical companies manage the number of products purchased by each wholesaler. For example, the number of products that can be sold on a specific day, August 31st, is 10.

In Figure 8, Case 0 is the main business flow. In this example, Case 0 is created when Business A0 Sales Quantity Registration is performed. At this time, the planned sales date of 8/31 and the available sales quantity of 10 are registered in the system as case data for Case 0.

Also, Case 1 is a sub-workflow. In this example, first, task A1 "Product Request Task" is performed for Case 0 in the main workflow. If the product request is executable, the product request is executed, generating Case 1 in the sub-workflow. Then, event B0 "Product Request Confirmation" is generated in the main workflow. At this time, the number of product requests (8) is registered in the system as workflow data for Case 1, and is linked to the data on the available product sales quantity for Case 0 in the main workflow. This task is the same as task A1 "Delivery Quantity Registration" shown in Example 1, and a case is created when delivery quantity registration is performed through the product request. At this time, the available delivery quantity (8), which is the same as the number of product requests (8), is registered in the system as case data 41 for Case 1.

As mentioned above, Item 1 is a secondary workflow in relation to Item 0, and a primary workflow in relation to Item 11. In this case, among the data items in Item 1, the data items linked to Item 0 and the data items linked to Item 11 may be the same data items, or may be linked within the workflow of Item 1. For example, the number of deliveries available, which is a data item in the primary workflow of Item 1, is linked to the number of manufacturing requests, which is a data item in the secondary workflow of Item 1, and the relationship is: number of deliveries available = number of product requests - number of delivery requests. In other words, if the number of manufacturing requests in Item 1 is 8, the number of products available to distribute to medical institutions is 8, and the number of delivery requests that have already been received is subtracted from this. If no delivery requests have been received, the number of deliveries available will also be 8.

When the data item of the data link source in the main business flow (number of deliveries possible (Figure 8)) is linked to the data item of the data link destination in the relationship with another business flow (number of product requests (Figure 8)), the following occurs: In other words, the results of a change to the data of the data link destination in the relationship with another business flow are immediately reflected as the result of a change to the data link source in the main business flow. For example, in Figure 8, as a result of performing task B1 "Change product request" in Case 1 and changing the number of product requests from 8 to 10, the number of deliveries possible also changes from 1 to 3.

As a result, when data linkage between business flows is performed hierarchically, the results of data changes made at the data link destination in a higher level are not only immediately reflected in the data link source in the higher level, but can also be immediately reflected in the data link source in the lower level. This means that data linkage between hierarchical business flows can also be supported.

Product request approval may be performed in the business flow of Case 0. Product request approval is a task in the business flow of Case 0 to approve product requests that have been accepted from Case 1, which is a sub-business flow, and is performed after task A0 "Sales Quantity Registration" is performed and immediately before "Shipping Box Registration" is performed. After the product request is approved, new product requests and changes to existing product requests are not accepted and the sales quantity in the business flow of Case 0 is finalized. By accepting data linkage related to the task while the task is being performed in this way, when the main business flow and sub-business flow are performed in parallel while linking specific data items, data linkage from the sub-business flow can be accepted in accordance with the progress of the main business flow.

In addition, product request approval for task A0 "Sales Quantity Registration" of Item 0 can be performed after approval of the delivery request quantity for task A1 "Delivery Quantity Registration" of Item 1. In other words, task A0 "Sales Quantity Registration" of Item 0 can be performed while task A1 "Delivery Quantity Registration" of Item 1 is being performed. This makes it possible for the business flow of Item 1 to adjust supply (product requests) at higher levels after understanding demand (delivery request quantity) at lower levels.

Figure 9 shows linked data 44B between business flows consisting of multiple hierarchies.

In Figure 9, as linked target data 44B, which replaces linked target data 44 in Example 1, the link between the main workflow and the secondary workflow is defined as one hierarchy, and hierarchical levels are defined. For example, at hierarchy level N, one level below hierarchy level N+1, the secondary workflow at the N+1 level becomes the main workflow. In addition, data items that are identical between levels or that are linked within a workflow are defined as data relationships between levels. For example, the data item "Number of product requests" at hierarchy level N+1 is linked to the data items "Number of deliverables" and "Number of delivery requests" at the next lower hierarchy level N to satisfy a specified relational expression, and strict linkage is established based on the relational expression.

Furthermore, as in Example 1, data linkage destinations and data linkage sources at the same hierarchical level are linked. For example, if the number of product requests at the data linkage destination increases, the data is linked so that the number of products available for production and sale at the data linkage source decreases accordingly.

In Example 2, data linkage between pharmaceutical companies, wholesalers, and medical institutions was explained, but the configuration and operation shown in the example are merely examples, and the present invention can be implemented by modifying the configuration and operation as appropriate.

For example, for data linkage between pharmaceutical companies and manufacturing plants, a data link source "available production quantity" and a data link destination "number of manufacturing requests" may be defined, and a data relationship may be defined in which the "number of manufacturing requests" and the "number available for manufacturing and sale" are linked. Also, for data linkage between cell banks and manufacturing plants, a data link source "number of available cells" and a data link destination "number of cell requests" may be defined, and a data relationship may be defined in which the "number of cell requests" multiplied by the number of products manufactured from one cell is the "available production quantity."

In this example, supply chain management for regenerative medicine products was illustrated, and hierarchical data integration in a system for managing a supply chain for regenerative medicine products was described as an example. Specifically, the combination of the first main business flow and the second main business flow was either administration and delivery of regenerative medicine products, sales and delivery of regenerative medicine products, or manufacturing and storage of regenerative medicine products. This enables prompt and appropriate delivery, sales, and storage of regenerative medicine products. The supply chain for regenerative medicine products is merely an example, and the present invention can be used for any supply chain.

The present invention is not limited to the above-described embodiments, but includes various modifications. Furthermore, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those that include all of the described configurations. Furthermore, not only can such configurations be deleted, but replacements and additions to configurations are also possible.

Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be implemented in part or in whole in hardware, for example, by designing them as integrated circuits. The present invention can also be realized by software program code that implements the functions of the embodiments. In this case, a recording medium on which the program code is recorded is provided to a computer, and a processor in the computer reads the program code stored on the recording medium. In this case, the program code read from the recording medium itself implements the functions of the above-described embodiments, and the program code itself and the recording medium on which it is stored constitute the present invention. Examples of recording media for providing such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs (Solid State Drives), optical disks, magneto-optical disks, CD-Rs, magnetic tape, non-volatile memory cards, and ROMs.

Furthermore, the program code that realizes the functions described in the above embodiments can be implemented in a wide range of programming or scripting languages, such as Assembler, C/C++, Perl, Shell, PHP, and Java (registered trademark).

In the above examples, the control lines and information lines shown are those considered necessary for explanation, and not all control lines or information lines in the product are necessarily shown. All components may be interconnected.

1: Computer, 22: Control unit, 23: Memory unit, 33: Business data mapping unit, 34: Implementation tenant data management unit, 35: Access control unit, 41: Case data, 42: Business flow data, 43: Business flow case data, 43-1: Main business flow case data, 43-2: Sub-business flow case data, 44: Linkage target data, 44B: Linkage target data, 45: Mapping data, 46: Implementation tenant data, 47: Area data, D11: Output screen.

Claims (10)

A data linkage system that links data between multiple business processes,
workflow case data including the workflow consisting of a plurality of linked tasks and information on cases handled by the workflow;
a storage unit that stores linkage target data including information that maintains the relationship between a link source data item and a link destination data item among the data items that are linked between the business flows;
a business data mapping unit that maps and links business data related to a first data item of the link source of a first main business flow among the business flows with business data related to a first data item of the link destination of a first sub-business flow, which is the business flow that receives a supply from the first main business flow and executes a business;
and
The business data mapping unit
A data linkage system characterized by linking business data related to the data item of the first link source of the first main business flow with business data related to the data item of the first link destination of the first sub-business flow during the execution of a first business related to the data item of the first link source of the first main business flow. The data linkage system according to claim 1,
The business data mapping unit
mapping and linking business data related to the second link source data item of a second main business flow, which is the business flow that supplies the first main business flow, with business data related to the second link destination data item of the first main business flow;
A data linkage system characterized in that business data related to the first link source data item of the first main business flow and business data related to the second link destination data item of the first main business flow are linked and linked. 3. The data linkage system according to claim 2,
During the execution of a second task related to the second link source data item of the second main task flow, task data related to the second link source data item and task data related to the second link destination data item are linked,
A data linkage system, wherein the first task is performed while the second task is being performed. The data linkage system according to claim 1,
The business data mapping unit
A data linkage system characterized by linking business data related to the data item of the first link source with business data related to one or more data items of the first link destination of a second secondary business flow, which is the business flow that receives supply from the first main business flow and carries out business. The data linkage system according to claim 1,
The storage unit further stores implementation tenant data including information on tenants involved in each business flow;
an input unit that receives a data linkage request for the first sub-workflow from a first tenant that is an implementing tenant of the first main workflow;
a workflow generation unit that generates the first sub-workflow based on the data linkage request;
A data linkage system further comprising: an implementing tenant data management unit that sets at least the first tenant as an implementing tenant of the first sub-business flow; and an access control unit that controls access to the business data of each business flow by tenants belonging to the implementing tenant data of each business flow. The data linkage system according to claim 1,
an output unit that outputs business data related to the data item of the first link source of the first main workflow and business data related to the data item of the first link destination of the first sub-workflow in association with each other;
and a display unit that displays an output from the output unit. 3. The data linkage system according to claim 2,
A data linkage system characterized in that business data related to the second link source data item of the second main business flow and business data related to the first link destination data item of the first main business flow are linked so as to satisfy a predetermined relational expression. 3. The data linkage system according to claim 2,
A data linkage system characterized in that the combination of the first main business flow and the second main business flow is any one of administration and delivery of regenerative medical products, sales and delivery of regenerative medical products, and manufacturing and storage of regenerative medical products. A data linkage method executed by a data linkage system that links data between multiple business flows, comprising:
The data linkage system includes:
workflow case data including the workflow consisting of a plurality of linked tasks and information on cases handled by the workflow;
a storage unit for storing link target data including information holding a relationship between a link source data item and a link destination data item among the data items linked between the business flows;
a business data mapping unit of the data linkage system having a business data mapping procedure for mapping and linking business data related to a first data item of the link source of a first main business flow among the business flows with business data related to a first data item of the link destination of a first sub-business flow, which is the business flow that receives a supply from the first main business flow and performs a business;
In the business data mapping step, the business data mapping unit:
A data linkage method characterized by linking business data related to the data item of the first link source of the first main business flow with business data related to the data item of the first link destination of the first sub-business flow during the execution of a first business related to the data item of the first link source of the first main business flow. Computer,
workflow case data including the workflow consisting of a plurality of linked tasks and information on cases handled by the workflow;
a storage unit that stores linkage target data including information that maintains the relationship between a link source data item and a link destination data item among the data items that are linked between the business flows;
a business data mapping unit that maps and links business data related to a first data item of the link source of a first main business flow among the business flows with business data related to a first data item of the link destination of a first sub-business flow, which is the business flow that receives a supply from the first main business flow and executes a business;
It functions as
The business data mapping unit
A data linkage program characterized by linking business data related to the data item of the first link source of the first main business flow with business data related to the data item of the first link destination of the first sub-business flow during the execution of a first business related to the data item of the first link source of the first main business flow.