System and method for displaying causal loop diagrams to a user - Patents.com

Abstract

To facilitate the visualization of a causal loop diagram from a different user viewpoint.SOLUTION: A system stores information of one or more causal loop diagrams, and first management information for associating a user with a node. A weight is given to each of nodes included in the one or more causal loop diagrams. The system acquires a user identifier for identifying a first user. The system selects a node related to the first user in the nodes included in the one or more causal loop diagrams with reference to the first management information, and increases the weight of the selected node. The system highlights nodes whose weight is a first threshold or more in a display of a causal loop diagram including nodes of the one or more causal loop diagrams.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] The present invention relates to a technique for displaying a causal loop diagram to a user. [Background technology]

[0002] Patent Document 1 discloses a method for integrating CLD (Causal Loop Diagram) of quality meters using online data. With the aim of determining the quality of information systems that support management, operations, and decision-making, the method considers combining technical and non-technical data measured at different intervals and obtained from different sources using QI (Quality Intelligence tools).

[0003] The dashboard layer of QI can provide users with a real-time view of the quality value of their information systems. The QI system can accommodate many different users or user roles (CEO, CIO, CFO, customer service, project manager, etc.), who can choose to view information about the system qualities that are important to them. Users can select the views that are appropriate for them, or can adapt the views to their specific purposes as appropriate for them.

[0004] The results can be viewed in the dashboard unit. The results are arranged to provide a GUI (Graphical User Interface), which displays the results of each quality indicator, the validity of the internal structure of the causal loop model, and the values ​​of each parameter that show the relationship between the quality indicators. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] US Patent Application Publication No. 2017 / 0052867 Summary of the Invention [Problem to be solved by the invention]

[0006] Efficient CLD integration methods exist, but the complexity of CLDs makes their usefulness difficult to see, especially since it is difficult to achieve visualization from different user perspectives. [Means for solving the problem]

[0007] One aspect of the present invention is a system for displaying a causal loop diagram to a user, the system including one or more computing devices and one or more storage devices, the one or more storage devices storing information of one or more causal loop diagrams and first management information associating users with nodes, a weight being assigned to each of the nodes included in the one or more causal loop diagrams, the one or more computing devices acquiring a user identifier that identifies a first user, and referring to the first management information, selecting a node associated with the first user from among the nodes included in the one or more causal loop diagrams, increasing the weight of the selected node, and highlighting nodes whose weight exceeds a first threshold in a display of the causal loop diagram including the nodes of the one or more causal loop diagrams. Effect of the Invention

[0008] According to one aspect of the present invention, visualization of a CLD from different user perspectives can be made easier. [Brief description of the drawings]

[0009] [Figure 1] An example of the configuration of an urban CLD visualization system is shown below. [Figure 2A] 1 shows an example of the configuration of a user table. [Figure 2B] 13 shows an example of the configuration of a user type table. [Figure 2C] 13 shows an example of the configuration of a default PDCA-KPI relationship table. [Figure 2D] 13 shows an example of a user relationship table. [Figure 2E] 1 shows an example of the configuration of a default stakeholder interest table. [Figure 3A] 1 shows an example of a KPI list table configuration. [Figure 3B] An example of the configuration of the collected CLD table is shown below. [Figure 3C] 13 shows an example of the configuration of a node relationship link table. [Figure 4] 1 shows an example of the configuration of sensor and city data. [Figure 5A] 1 shows an example of the configuration of an analysis result table-relationship model. [Figure 5B] 13 shows an example of the configuration of a bottleneck countermeasure pattern table. [Figure 6] 13 shows a flowchart of an example of a method for collecting CLD information and registering the data in a database by a CLD formation unit. [Figure 7] 13 shows a flowchart of an example process of CLD filtering and CLD visualization. [Figure 8] 1 shows a detailed flowchart of the CLD visualization steps. [Figure 9] 1 shows a flowchart of the detailed Stakeholder Relationship CLD integration steps. [Figure 10] 1 shows a sequence diagram of the stakeholder relationship CLD integration steps. [Figure 11] 1 shows an example of a visualized CLD image that may be presented to a user. [Figure 12A] An example of a loop in the CLD of FIG. [Figure 12B] An example of a loop in the CLD of FIG. [Figure 13] 1 shows an example of a visualized CLD image that may be presented to a user. [Figure 14] 1 shows an example of a visualized CLD image that may be presented to a user. [Figure 15] 1 shows an example of a visualized CLD image that may be presented to a user. [Figure 16] 1 shows an example of a visualized CLD image that may be presented to a user. [Figure 17A] Here is an example of how inserting countermeasure KPIs can change a negative loop into a positive loop. [Figure 17B] Here is an example of how inserting countermeasure KPIs can change a negative loop into a positive loop. [Figure 17C] Here is an example of how inserting countermeasure KPIs can change a negative loop into a positive loop. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] In the following, when necessary for convenience, the description will be divided into multiple sections or embodiments, but unless otherwise specified, they are not unrelated to each other, and one is related to the other as a partial or complete modification, detail, supplementary explanation, etc. Furthermore, in the following, when the number of elements, etc. (including the number, numerical value, amount, range, etc.) is mentioned, it is not limited to the specific number, and may be more than or less than the specific number, unless otherwise specified or clearly limited in principle to a specific number, etc.

[0011] This system may be a physical computer system (one or more physical computers) or a system built on a group of computing resources (multiple computing resources) such as a cloud infrastructure. The computer system or the group of computing resources includes one or more interface devices (including, for example, a communication device and an input / output device), one or more storage devices (including, for example, a memory (main memory) and an auxiliary storage device), and one or more arithmetic devices.

[0012] When a function is realized by a program being executed by a computing device, the defined processing is performed using a storage device and / or an interface device, etc. as appropriate, and therefore the function may be at least a part of the computing device. Processing described with a function as the subject may be processing performed by a system having a computing device. The program may be installed from a program source. The program source may be, for example, a program distribution computer or a computer-readable storage medium (for example, a computer-readable non-transitory storage medium). The description of each function is an example, and multiple functions may be combined into one function, or one function may be divided into multiple functions.

[0013] In the following, a system is described that utilizes Causal Loop Diagrams (CLDs) as a visualization tool for decision making, urban planning, and open data. The system visualizes data for planning and decision making based on dynamic change predictions. In the following, an example system is described that displays personalized CLDs for urban planning. The features of this specification can be applied to CLD visualization systems for other applications.

[0014] 1 shows an example of the configuration of an urban CLD visualization system 100. CLD stands for causal loop diagram. The urban CLD visualization system 100 includes a main memory device 110 configured with a volatile memory element such as a RAM, and an auxiliary memory device 120 configured with an appropriate non-volatile memory element such as an SSD (Solid State Drive) or a hard disk drive. The urban CLD visualization system 100 further includes a calculation device 130 such as a CPU that reads out programs stored in the auxiliary memory device 120 or the like into the main memory device 110 and executes them, performs overall control of the system itself, and performs various judgments, calculations, and control processes.

[0015] The city CLD visualization system 100 includes a communication interface 132 for connecting to a network 140 and exchanging data. These components of the city CLD visualization system 100 can communicate with each other via an internal bus. The city CLD visualization system 100 further includes an input / output device 131. The input / output device 131 includes input devices such as a keyboard, mouse, and touch panel that accept input operations from a system user, and output devices such as a display that shows processing results to the user.

[0016] The auxiliary storage device 120 stores information databases (DB) 121-124 that store data required for various processes, in addition to programs for implementing functions required for the urban CLD visualization system 100 of this embodiment. Specifically, a master database 121, a CLD collection database 122, a collected sensor and city data database 123, and a relational model database 124 are stored. The contents of the databases will be described in more detail later in relation to the processing flow.

[0017] 1 shows programs loaded into a main memory device 110. Specifically, the main memory device 110 stores a CLD formation unit 111, a filtering unit 113, an analysis and bottleneck detection unit 114, and a visualization unit 115.

[0018] The arithmetic unit 130 operates according to the instruction codes of the above programs to operate as the corresponding functional units. That is, the arithmetic unit 130 can operate as a CLD forming unit, a filtering unit, an analysis and bottleneck unit, and a visualization unit. The operation of these programs will be described below in relation to an example of the process flow of the city CLD visualization system 100.

[0019] The communication interface 132 is an interface for the computing device 130 (the city CLD visualization system 100) to communicate with an external system via the network 140. Specifically, the city CLD visualization system 100 can communicate with a relationship modeling system 150, a government system 160, an enterprise system 161, and a private system 162.

[0020] 2A to 5B, a description will be given of the configuration of a database stored in the city CLD visualization system 100. The data stored in the database is used in the data processing described later.

[0021] 2A to 2E show examples of data (information) stored in the master database 121. The master database 121 includes a user table 200, a user type table 210, a default PDCA-KPI relationship table 220, a user relationship table 230, and a default stakeholder interest table 240. The information in the master database 121 can be entered by a system administrator based on the information in the CLD collection database 122.

[0022] FIG. 2A shows an example of the configuration of a user table 200, which is user information. The user table 200 manages user information. The user table 200 is composed of a user ID 201, a user name 202, a stakeholder type 203, a customized concern (KPI category) 204, and a main PDCA task 205. The user ID 201 is an identifier for a user and is a key for identifying each record in the table. The user name 202 indicates the name of the user. The stakeholder type 203 indicates the type of organization to which the user belongs. The customized concern 204 represents the concern of the user. The concern is shown in a KPI category. The main PDCA task 205 indicates the main task assigned to the user in the PDCA cycle of urban planning.

[0023] 2B shows an example of the configuration of a user type table 210, which is user type information. The user type table 210 manages information on organizations to which a user belongs. The user type table 210 includes a stakeholder type ID 211, a stakeholder type name 212, and KPI access permissions 213. The stakeholder type ID 211 is an identifier of the user's organization, and is a key for identifying each record. The stakeholder type name 212 indicates the name of the organization. The KPI access permissions 213 indicate the KPI categories and KPIs that the organization can view.

[0024] FIG. 2C shows an example of the configuration of a default PDCA-KPI relationship table 220. The default PDCA-KPI relationship table 220 manages information related to PDCA tasks for urban planning. The default PDCA-KPI relationship table 220 includes a PDCA 221 and a KPI ID 222. The PDCA 221 is an identifier of the task and also a primary key. The KPI ID 222 indicates the KPI referenced in the task. The P, D, C, and A indicated by the PDCA 221 are the same as the P, D, C, and A indicated by the main PDCA task 205. PDCA stands for Plan Do Check Act. The PDCA cycle indicates a cycle for continuously improving the quality of an object.

[0025] Note that even for the same KPI, the positioning of PDCA may be different for each user. For example, kpi_1 may be a KPI referenced at stage P for one user, but a KPI referenced at stage C for another user. In this case, a column for user ID may be added to the default PDCA-KPI relationship table 220 in order to change the positioning of PDCA for each user.

[0026] FIG. 2D shows an example of the configuration of a user relationship table 230. The user relationship table 230 manages information on stakeholders related to a user. The user relationship table 230 includes a user ID 231 and a stakeholder user ID 232. The user ID 231 is an identifier of a user and is a primary key. The stakeholder user ID 232 indicates a user ID of a stakeholder related to the user. In this case, similar to the user relationship table 230, a separate table indicating the relationship between the stakeholder type of a user and the stakeholder type of a user of the stakeholder may be prepared, and the user relationship table may be automatically created based on the table indicating the relationship between the stakeholder types.

[0027] 2E shows an example of the configuration of a default stakeholder interest table 240. The default stakeholder interest table 240 stores information on KPIs in which an organization is interested. The default stakeholder interest table 240 includes a stakeholder type ID 241 and a KPI category 242. The stakeholder type ID 241 is an identifier of an organization and is a primary key. The KPI category 242 indicates a category of KPIs in which a stakeholder is interested.

[0028] Next, a description will be given of the CLD collection DB 122. Figures 3A to 3C show information contained in the CLD collection DB 122. Specifically, the CLD collection DB 122 includes a KPI list table 300, a collected CLD table 310, and a node relationship link table 320.

[0029] 3A shows an example of the configuration of a KPI list table 300. The KPI list table 300 manages KPI information. The KPI list table 300 includes a KPI ID 301, a KPI name 302, a KPI category 303, an importance weight 304, and a weight threshold 306. The KPI ID 301 is an identifier of the KPI, and is a key for identifying each record in the table. The KPI name 302 indicates the name of the KPI.

[0030] The KPI category 303 indicates the category of the KPI. The importance weight 304 is a weight used to determine the display of the KPI. The weight threshold 306 indicates a threshold of the importance weight 304 for determining the display of the KPI. The importance weight 304 and the weight threshold 306 are set by a user or calculated by the system in a preset manner from the values ​​of related sensors of the city data values ​​405 of the sensor and city data 400. In the example of FIG. 3A, the weight threshold value is common to all KPIs. Different weight threshold values ​​may be set for different KPIs.

[0031] 3B shows an example of the configuration of a collected CLD table 310. The collected CLD table 310 manages CLD information acquired from an external government system 160, an enterprise system 161, and a private system 162. The collected CLD table 310 includes a CLD ID 311, a link ID 312, a CLD type 313, a link source KPI ID 314, a link destination KPI ID 315, and a relationship 316. The CLD ID 311 is an identifier of the CLD, and is one of the keys for identifying each record. The link ID 312 is an identifier of a link connecting nodes of the CLD, and is one of the keys for identifying each record.

[0032] CLD type 313 indicates the type of organization that created the CLD. Link source KPI ID 314 indicates the start node (KPI) of the link. Link destination KPI ID 315 indicates the link destination node (KPI). Relationship 316 indicates the relationship between link source KPI ID 314 and link destination KPI ID 315. If the value of link destination KPI ID 315 increases when link source KPI ID 314 increases, relationship 316 is "+". On the other hand, if the value of link destination KPI ID 315 increases when link source KPI ID 314 decreases, relationship 316 is "-".

[0033] 3C shows an example of the configuration of a node relationship link table 320. The node relationship link table 320 stores CLD information, similar to the collected CLD table 310. The node relationship link table 320 includes a link ID 321, a CLD type 322, a link source KPI ID 323, a link destination KPI ID 324, and a relationship 325. These are the same as the components of the collected CLD table 310.

[0034] Next, the collected sensor and city data DB 123 will be described. Fig. 4 shows an example of information stored in the collected sensor and city data DB 123. Specifically, the collected sensor and city data DB 123 includes sensor and city data 400. The information in the collected sensor and city data DB 123 is collected, for example, from an external system by the system.

[0035] The sensor and city data 400 manages statistical data of sensors or cities. The sensor and city data 400 includes an item ID 401, a city data item 402, an attribute 403, a KPI name 404, and a city data value 405. The item ID 401 is an identifier of the data, and is a key for identifying each record in the table. The city data item 402 indicates the name of the data. The attribute 403 indicates the attribute of the data. The KPI name 404 indicates the name of the related KPI. The city data value 405 indicates the value of the data indicated by the city data item.

[0036] Next, the relational model DB 124 will be described. Figures 5A and 5B show examples of information stored in the relational model DB 124. Specifically, the relational model DB 124 includes an analysis result table-relational model 500 and a bottleneck countermeasure pattern table 510. For example, information on the analysis result table-relational model 500 is collected from an external relational modeling system 150, and the bottleneck countermeasure pattern table 510 is set and registered in advance by an administrator.

[0037] 5A shows an example of the configuration of an analysis result table-relationship model 500. The analysis result table-relationship model 500 stores information on city measures and their effects. The analysis result table-relationship model 500 includes a KPIID 501, a measure 502, and an effect 503. The KPIID 501 is an identifier of the KPI, and is one of the keys for identifying each record in the table. The measure 502 is the name of the measure, and is one of the keys for identifying each record in the table. The effect 503 indicates the effect of the measure.

[0038] 5B shows an example of the configuration of a bottleneck countermeasure pattern table 510. The bottleneck countermeasure pattern table 510 stores information on city countermeasures and the effects of the countermeasures on bottlenecks. The bottleneck countermeasure pattern table 510 includes an ID 511, an original relationship 512, and a countermeasure relationship 513. The countermeasure relationship 513 includes kpi_a→x 514 and x→kpi_b 515.

[0039] ID 511 is an identifier of the pattern of change in positive / negative relationship due to a countermeasure, and is a key for identifying each record in the table. Original relationship 512 indicates the relationship between linked nodes before the countermeasure is applied. Countermeasure relationship 513 indicates the relationship between linked nodes after the countermeasure is applied. After the countermeasure is applied, KPI_a→x 514 and x→KPI_b 515 are added to the CLD instead of original relationship 512.

[0040] That is, before the measure node is added, kpi_a is the link source node and kpi_b is the link destination node. A measure node x is added between these nodes. For example, in pattern p1, the original relationship between kpi_a and kpi_b is positive (+). A node x is added between these KPIs. The relationship between kpi_a and x is negative (-), and the relationship between x and kpi_b is positive (+).

[0041] In pattern p3, the original relationship between kpi_a and kpi_b is negative (-). A node x is added between these KPIs. The relationship between kpi_a and x is positive (+), and the relationship between x and kpi_b is positive (+).

[0042] The following describes the processing performed by the city CLD visualization system 100. As a first step, the CLD formation unit 111 collects information on original causal loop diagrams before being processed for visualization by a user from an external system as follows: Fig. 6 shows a flowchart of an example of a method for the CLD formation unit 111 to collect CLD information and register data in a database.

[0043] 6, in step S601, the CLD formation unit 111 collects information of existing CLDs from external sources, i.e., government systems 160, enterprise systems 161, and private systems 162, and stores them in the CLD collection database 122. As shown in the collected CLD table 310 of FIG. 3B, node relationship data is held in fields 314, 315, and 316 as in the original CLD, where field 313 indicates the source.

[0044] In the next step S602, the CLD formation unit 111 reads out the collected CLD information from the main storage device 110 and the CLD collection database 122, and in step S603, checks each node one by one. In steps S604 and S605, the CLD formation unit 111 adds each node to the KPI list table 300 of the CLD collection database 122. At this time, duplicates are discarded. In addition, link information including the link source KPI, link destination KPI, and relationship type is added to the node relationship link table 320. Furthermore, information on the city data value of each node is stored in the sensor and city data 400.

[0045] Here, multiple CLDs may be read, integrated, and connected to one CLD, which may be used as the subsequent CLD. In this case, nodes showing the same KPI may be automatically combined as the same entity, and links connected to the nodes may also be automatically connected, or the combining and connecting may be performed manually, or a combination of both may be used. Also, a publicly known method may be used.

[0046] As described above, part of the information in the master database 121 is selected and stored by the administrator from the information collected as described above. Part of the information in the relational model database 124 is collected and stored from the relational modeling system 150 as described above. Part of the information is set and registered by the administrator.

[0047] After the necessary information is stored in the databases 121 to 124, the system 100 starts the process of CLD filtering and CLD visualization, which can assist the user in making decisions. The process of CLD filtering and personalization begins as follows:

[0048] 7 shows a flowchart of a processing example of CLD filtering and CLD visualization. In the first step S701, the filtering unit 113 acquires a user ID via the input / output device 131. The filtering unit 113 refers to the user table 200 of the master database 121, and acquires the values ​​of the main PDCA task 205, the stakeholder type 203, and the customized concern 204 from the record whose value of the user ID 201 matches.

[0049] Next, in step S702, the filtering unit 113 refers to the default PDCA-KPI relationship table 220 in the master database 121, and obtains the value of the KPI ID 222 from the record of the PDCA 221 that is equal to any one of the values ​​of the obtained main PDCA task 205.

[0050] The filtering unit 113 refers to the KPI list table 300 in the CLD collection database 122, and searches for records in which the value of the KPI ID 301 or the KPI category 303 is equal to the acquired value of the KPI ID 222 or the customized interest 204. The filtering unit 113 updates the importance weight 304 of the found record so as to increase the value. This makes it possible to increase the weight of the KPI node related to the user. The increase value of the importance weight 304 is set in advance by the system administrator. The filtering unit 113 may update the importance weight only in records that match either the KPI associated with the main PDCA task of the user or the customized interest.

[0051] Next, in step S703, the filtering unit 113 acquires information on relationships between stakeholders. The filtering unit 113 refers to the user relationship table 230 of the master database 121, and searches for a record whose user ID 231 value matches the acquired user ID value. The filtering unit 113 acquires existing default user relationship information indicated by the stakeholder user ID 232 of the found record.

[0052] Furthermore, the filtering unit 113 updates the importance weight 304 to increase it as described above based on each user ID of the acquired stakeholder user ID 232 instead of the user ID in steps S701 and 702. This makes it possible to increase the weight of the KPI node related to the user through the stakeholder associated with the user. Specifically, the filtering unit 113 refers to the user table 200 of the master database 121, and acquires the values ​​of the customized concern 204 and the main PDCA task 205 from the record having the value of the user ID 201 that matches each user ID of the acquired stakeholder user ID 232.

[0053] The filtering unit 113 refers to the default PDCA-KPI relationship table 220, and acquires the value of KPI ID 222 from records of PDCA 221 that are equal to any of the values ​​of the acquired main PDCA task 205. The filtering unit 113 refers to the KPI list table 300, and increases the value of importance weight 304 for records of KPI ID 301 that are equal to the acquired customized subject of concern 204 or KPI ID 222 value.

[0054] Furthermore, the filtering unit 113 refers to the user type table 210 of the master database 121, and searches for a record whose stakeholder type name 212 matches the value of the stakeholder type 203 of the current user. The filtering unit 113 obtains the value of the KPI access permission 213 from the found record.

[0055] The filtering unit 113 refers to the KPI list table 300 in the CLD collection database 122, and updates the importance weight 304 of the record whose KPI category 303 value is not equal to the acquired value of the KPI access permission 213 to "0". This is because only users with access permission are allowed to view KPIs. Note that nodes below a threshold other than 0 may be set as unviewable.

[0056] In step S704, the analysis and bottleneck detection unit 114 obtains the value of the KPI ID 301 of a record having a non-zero value for the importance weight 304 from the KPI list table 300 of the CLD collection database 122.

[0057] Next, the analysis and bottleneck detection unit 114 refers to the node relationship link table 320 in the CLD collection database 122, and searches for a record having a link source KPI ID 323 equal to the value of the acquired KPI ID 301. The analysis and bottleneck detection unit 114 acquires the values ​​of the link ID 321 and the link destination KPI ID 324 from the found record. In other words, link and link destination information is acquired from a record having a link source KPI ID 323 equal to a value of KPI ID 301 whose importance weight 304 value is not 0.

[0058] Next, the analysis and bottleneck detection unit 114 refers to the KPI list table 300 and searches for a record with the obtained value of the linked KPI ID 324. The analysis and bottleneck detection unit 114 extracts the value of the linked KPI ID 324 whose importance weight 304 value is not 0, and sets this as the new linked KPI ID 323. At this point, the analysis and bottleneck detection unit 114 repeats the above steps.

[0059] Here, if the value of the importance weight 304 of the linked KPI ID 324 extracted before it is used as the new linked KPI ID 323 is 0, the analysis and bottleneck detection unit 114 repeatedly searches for a new linked KPI ID with the linked KPI ID as the linked KPI ID until a linked KPI ID 324 value with an importance weight other than 0 is obtained.

[0060] Specifically, the analysis and bottleneck detection unit 114 sets the value of the extracted link destination KPI ID324 as the value of the link source KPI ID323 and obtains a new link destination KPI ID324 value from the node relationship link table 320. The analysis and bottleneck detection unit 114 repeats obtaining the value of the link destination KPI ID324 until the value of the importance weight 304 for the obtained new link destination KPI ID324 is not 0.

[0061] Next, the analysis and bottleneck detection unit 114 replaces the value of the first link destination KPI ID324 (weight=0) for the value of the first link source KPI323 (weight≠0) with the value of the current link destination KPI ID324 (weight≠0). This results in multiple pairs of the first link source KPI ID with an importance weight other than 0 and the link destination KPI ID with an importance weight other than 0.

[0062] For each pair, the analysis and bottleneck detection unit 114 counts the number of "-" relationships 325 from the value of the first linked KPI ID 324 to the value of the current linked KPI ID 324. The analysis and bottleneck detection unit 114 sets the value of the relationship 325 for each pair according to the count. If the count is an odd number, the value of the relationship 325 is "-". If the count is an even number, the value of the relationship 325 is "+".

[0063] As a result, the analysis and bottleneck detection unit 114 obtains elements consisting of a link ID 321, a link source KPI ID 323, a link destination KPI ID 324, and a relationship 325. As described above, since all nodes that the user does not have permission to view have not been extracted, these nodes are nodes that the user has permission to view and are connected to each other by links.

[0064] Through the above processing, KPIs filtered based on the user information and information on the relationships between KPIs are obtained. The analysis and bottleneck detection unit 114 copies the node relationship link table 320 and updates the node relationship link table 320 with information on the extracted KPI nodes whose importance weights are not 0.

[0065] Next, the analysis and bottleneck detection unit 114 obtains the link destination KPI ID324 from the node relationship link table 320 based on the link source KPI ID323, and further, the analysis and bottleneck detection unit 114 obtains the next link destination KPI ID324 based on the link source KPI ID323 that is equal to the previous link destination KPI ID324.

[0066] The analysis and bottleneck detection unit 114 repeats these steps until the first link source KPI ID 323 is found as the link destination KPI ID 324. At this point, the analysis and bottleneck detection unit 114 has obtained a series of linked KPI IDs.

[0067] The analysis and bottleneck detection unit 114 counts the negative "-" relationships 325 in the previously acquired series (discovered loops). If the count is odd, the loop relationship is negative "-". In other words, a negative / balanced loop has been detected. If the count is even, the loop relationship is positive "+". In other words, a positive / reinforcing loop has been detected. A detected negative loop contains a bottleneck, and is therefore defined as a "bottleneck loop". The analysis and bottleneck detection unit 114 judges whether all loops are positive or negative. Here, the interpretation of positive and negative bottlenecks may be reversed, and a positive / reinforcing loop may be defined as a bottleneck loop to judge a bottleneck loop.

[0068] After the above process is completed, the analysis and bottleneck detection unit 114 acquires the values ​​of all link source KPI IDs 323 in the bottleneck loop. The analysis and bottleneck detection unit 114 refers to the KPI list table 300 and searches for all records having a KPI ID 301 equal to the acquired value of link source KPI ID 323. The analysis and bottleneck detection unit 114 acquires the value of importance weight 304 and the value of weight threshold 306 from the found records.

[0069] Next, the analysis and bottleneck detection unit 114 adds up all the importance weights 304 values ​​of the bottleneck loop. The sum of the importance weights 304 values ​​becomes the weight of that bottleneck loop. The analysis and bottleneck detection unit 114 adds up the weight thresholds 306 values ​​of all KPI nodes of the bottleneck loop. In this example, the value of weight threshold 306 is common to all KPIs. Therefore, the product of the number of KPIs in the bottleneck node and the value of weight threshold 306 becomes the weight threshold of the bottleneck loop.

[0070] The analysis and bottleneck detection unit 114 compares the importance weight of the bottleneck loop with the weight threshold to identify a bottleneck loop (critical loop) having an importance weight equal to or greater than the weight threshold. The same process as described above is repeated for all detected bottleneck loops. Note that the method of comparing the importance weight of the bottleneck loop with the weight threshold may be a specific algorithm specified separately. For example, the importance weight 304 of an arbitrary node in the bottleneck loop may be compared with its weight threshold 306, and if there is even one node with an importance weight equal to or greater than the weight threshold, the bottleneck loop may be determined to have an importance weight equal to or greater than the weight threshold (second threshold), and a bottleneck loop having an importance weight equal to or greater than the weight threshold may be identified.

[0071] The next step S705 is a CLD visualization step. The flowchart of Fig. 8 shows the details of the CLD visualization step S705. The CLD visualization step S705 will be described with reference to Fig. 8.

[0072] Before describing the details of the CLD visualization step S705, an example of a visualized CLD image will be described first. Figures 11, 13 to 16 each show an example of a visualized CLD image that can be presented to a user. Figures 12A and 12B show an example of a loop in the CLD shown in Figure 11.

[0073] In the example images shown in Figures 11 to 16, each KPI node in the CLD is represented by a circle, and the KPI name is shown inside the circle. The connections between KPI nodes are visualized with arrows, and the relationship between the source KPI node and the destination KPI node is visualized with "+" or "-". In the example image in Figure 16, the number near the KPI circle indicates the KPI value, i.e., city data value 405.

[0074] The loops formed by connecting KPIs are indicated by circular arrows. A circular dashed bold arrow indicates a bottleneck loop, and a circular continuous bold arrow indicates a non-bottleneck loop. A KPI node with a double bold circle indicates a bottleneck node for which measures are proposed. In the examples of Figures 11 to 16, the KPI "N. Of polluting vehicles" is proposed as a bottleneck node (critical node) for which measures should be taken.

[0075] The user can select a KPI from section 1101. The KPIs manually selected by the user according to their preferences are highlighted with a thick line circle. In Figs. 11 to 16, the KPI for QoL is selected by the user. In section 1102, the user can select a PDCA stage. In Figs. 11 and 13, "PLAN" is selected, in Figs. 14 and 15, "DO" is selected, and in Fig. 16, "CHECK" is selected.

[0076] After the CLD has been filtered as described above, the user can see all nodes related to his / her main PDCA task 205 in the user table 200. At this point, the user is given the option to manually select other filters. There are four selectable PDCA steps: Plan, Do, Check, and Act.

[0077] As shown in Fig. 2C, in the default PDCA-KPI relationship table 220 of the master database 121, the above four stages are expressed as P, D, C, and A. Each user can select a specific PDCA stage based on his / her authority (Primary PDCA Task 205 of the User Table 200). Some users may only be able to select a limited number of PDCA stages.

[0078] Depending on the selected PDCA phase, in addition to updating the CLD in steps S702 and S703, the following processing may be performed on the screen: In phase P, the user can visualize the filtered CLD. Here, for example, this is the phase selected by default, and may be the first screen the user sees, where a list of selectable KPIs is displayed.

[0079] When one selection is made (either KPI is selected or stage D is selected), the visualization unit 115 displays it as if stage D was selected, and further displays a selectable options section on the screen, where a relationship with other users can be specified and a request can be sent.

[0080] In step C, the user can display on the screen the values ​​of the city data values ​​405 of the sensor and city data 400. The city data values ​​405 are associated with a KPI name 404, which is equal to the KPI name 302 of the KPI list table 300 in the CLD collection database 122.

[0081] When stage A is selected, the user can insert a countermeasure node proposed by the relationship modeling system 150 or a countermeasure node manually created by the user into the CLD on the screen. This is just an example, and the user may be able to insert a countermeasure node into the CLD even in stages P to C.

[0082] Figure 11 shows an example of a CLD image personalized (customized) for a business user. Figure 11 shows multiple loops including selected QoL KPI nodes. Figures 12A and 12C respectively show two loops in the CLD shown in Figure 11. Figure 12A shows a positive loop and Figure 12B shows a negative loop (bottleneck loop).

[0083] Figure 13 shows another example of a personalized CLD image for a business user. In Figure 13, the CLD sources are highlighted. Specifically, CLD sources such as "LOCAL GOVERNMENT" and "RESIDENT" are represented by dot patterned boxes. The hidden KPI "Company customers" of the stakeholder "AUTOMOBILE B" is highlighted.

[0084] 14 shows an example of a personalized CLD image for business user "Real-estate Developer A" who has specified a relationship with "Automobile B". When the user specifies a relationship with stakeholder "Automobile B", the hidden KPI connections are revealed and the hidden KPI value sharing request panel 1103 is displayed.

[0085] Figure 15 shows an example of a personalized CLD image for stakeholder Automobile B ("Automobile B"), where a panel 1104 is displayed to approve or reject a request to share hidden KPI values, and a panel 1105 to create a new KPI.

[0086] Figure 16 shows an example of a personalized CLD image for "Real-estate Developer A". The PDCA stage is "CHECK" and the KPI value (city data value) is displayed. With the permission of the automobile-related company B, the value (city data value) of the originally hidden KPI "Company customers" is also displayed.

[0087] 8, in step S801, the visualization unit 115 retrieves information on KPI nodes filtered based on relationships between stakeholders regarding access permissions, relationships between KPI nodes, and information on bottleneck loops. The visualization unit 115 visualizes and displays this information on a screen for the user in accordance with the KPIs and PDCA stages designated by the user.

[0088] In step S802, the visualization unit 115 determines whether or not a bottleneck loop was detected in step S704. If a bottleneck loop has been detected (S802: YES), the visualization unit 115 checks the value of the importance weight 304 of each KPI node in the detected bottleneck loop (S803), and compares the value with the value of the weight threshold 306 (S804).

[0089] If the importance weight is equal to or greater than the threshold (first threshold) (S804: YES), the KPI node is determined to be a bottleneck node (critical node). The visualization unit 115 highlights the bottleneck node with a double-lined circle as described above (S805). In this example, the highlighted bottleneck node is "N. Of polluting vehicles". The KPI concern selected by the user is "QoL". This step is repeated for all detected bottleneck loops.

[0090] For example, see Figure 13, which shows all loops related to QoL KPIs accessible to the user. Detected positive loops are highlighted with a circular continuous thick arrow. Negative loops (bottleneck loops) are displayed with a circular dashed thick arrow.

[0091] A user identified by the user ID 201 in the user table 200 of the master database 121, and whose main PDCA task 205 value related to that user ID 201 includes the "C" (Check) stage of PDCA, can visualize the city data value 405 of the collected sensor and city data 400 in the sensor and city data database 123 on a new screen. An example of this is shown in FIG. 16.

[0092] The visualization unit 115 refers to the KPI list table 300 to identify records having a value of KPI ID 301 equal to the KPI ID of each KPI node in the series of nodes acquired and visualized. The visualization unit 115 acquires the values ​​of KPI name 302 of those records, and searches the sensor and city data 400 for records having a KPI name 404 that matches the acquired value. The visualization unit 115 displays the value of city data value 405 of the found records.

[0093] At this point, while predicting the city dynamics, the user is aware of the existing bottlenecks. What the user wants to do next is to find ways to strengthen the city or eliminate the bottlenecks. In other words, the next step is to develop ways to strengthen the city or measures to prevent the bottlenecks. This leads to step S706 in the flow of CLD filtering shown in Figure 7.

[0094] To assist in this process, the analysis result table-relational model 500 of the relational model database 124 is collected from the relational modeling system 150. Also, information input by the user is registered in a bottleneck countermeasure pattern table 510. The KPI ID 301 of the KPI list table 300 in the CLD collection database 122 is equal to the KPI ID 501 of the analysis result table-relational model 500 of the relational model database 124. The KPI ID 501 is associated with a countermeasure 502 and an effect 503 that is either "up" or "down".

[0095] Among the series of nodes, the KPI ID is found among KPI IDs 501, and related measures 502 are proposed as measures to further strengthen the city's strengths or to further reduce the city's weaknesses. On the other hand, in order to eliminate bottleneck loops, a new "measure" KPI node to be inserted next to the detected series of bottleneck nodes is accepted by the user through screen operations.

[0096] Alternatively, in a set of detected bottleneck nodes, the KPI ID may be found among KPI IDs 501, the countermeasure 502 may be extracted, and the countermeasure 502 may be proposed as a new "countermeasure" KPI node to be inserted next to the bottleneck node as a countermeasure that can change the bottleneck loop into a positive / reinforcing loop.

[0097] Here, in order to propose measure 502, a KPI ID that is identical or similar to measure 502 may be searched for within KPI ID 301 as the "measure" KPI node. Here, whether they are identical or similar may be determined by referring to a synonym list that is separately stored, or may be determined using language analysis technology.

[0098] Here, by inserting the node for measure 502 next to KPI ID 501, it is considered that a measure has been proposed by inserting a "measure" KPI node. At that time, as an attribute of the "measure" KPI node, a link is set from the node for measure 502 to KPI ID 501, and if the effect 503 of measure 502 is "up", the relationship of the link is set to "+", and if the effect 503 is "down", the relationship of the link is set to "-".

[0099] Here, this relationship ("+" or "-") corresponds to x → KPI_b 515. Next, records in which the previous relationship ("+" or "-") and x → KPI_b 515 match are extracted from bottleneck countermeasure pattern table 510, and further, for link source KPI ID 323 with KPI ID 501 as link destination KPI ID 324, records in which the relationship 325 matches original relationship 512 are extracted from the previous records, and kpi_a->x 514 for that record is obtained.

[0100] Here, if a positive correlation must be shown between the link source KPI ID 323 and the node of measure 502 in order to eliminate the bottleneck loop, then a measure with the pattern of ID 511 where kpi_a->x514 is "+" must be taken. Also, if a negative correlation must be shown between the link source KPI ID 323 and the node of measure 502 in order to eliminate the bottleneck loop, then a measure with the pattern of ID 511 where kpi_a->x514 is "-" must be taken.

[0101] Here, if a "+" relationship is required to resolve the bottleneck loop, the user is recommended to manually select a measure 502 that shows a positive correlation with the link source KPI ID 323. Alternatively, if a "-" relationship is required to resolve the bottleneck loop, the user is recommended to manually select a measure 502 that shows a negative correlation with the link source KPI ID 323. Here, when making a recommendation to the user, a mechanical correlation analysis may be performed on the relationship between the KPI of the measure 502 and the link source KPI ID 323, and based on the result, measures 502 to be selected by the user may be narrowed down and presented in advance.

[0102] As shown in the bottleneck countermeasure pattern table 510 in FIG. 5B, after inserting the countermeasure KPI, the negative loop can be changed to a positive loop. An example of changing a negative loop to a positive loop by inserting the countermeasure KPI will be described with reference to FIGS. 17A to 17C. The CLD shown in FIG. 17A includes two bottleneck loops, as indicated by the circular dashed bold arrows. The highlighted bottleneck node is "N. of polluting vehicles".

[0103] In the CLD shown in Figure 17B, a node called "Investments on electric vehicles productions" is added to the loop as a link source KPI node for the bottleneck node "N. of polluting vehicles."

[0104] "N. of polluting vehicles" becomes the destination KPI node. Effect 503 acts on the bottleneck node "N. of polluting vehicles" to make it "down." This creates a negative relationship between the newly added source KPI node (measure node) and the destination KPI node (bottleneck node). The relationship 512 between the source KPI ("Company customers" in this example) and the destination KPI ("N. of polluting vehicles" in this example) is "+."

[0105] This is equivalent to pattern p2 in the bottleneck countermeasure pattern table 510 in the relational model database 124. Specifically, in the original relationship 512, kpi_a->kpi_b="+". The countermeasure KPI node "Investments on electric vehicles productions" is inserted as a link destination node to the link source node "Company customers". The countermeasure relationship 513 corresponds to kpi_a->x 514. x is a countermeasure node, and the relationship is "+". The relationship between the "Investments on electric vehicles productions" KPI node (link source node) and the "N. of polluting vehicles" KPI node (link destination node) corresponds to the relationship x->kpi_b 515. x is a countermeasure node, and the relationship is "-".

[0106] As mentioned above, the insertion of a new negative connection affects the next connection in the loop. All relationship links in the loop are checked by the analysis and bottleneck detection unit 114, and the "-" relationships are recounted in the obtained sequence. If, as in this case, the number of "-" is even, the loop becomes a positive "+". The addition of a "-" relationship turns the negative loop into a positive loop.

[0107] A similar pattern can be seen in the CLD shown in Fig. 17C. Another countermeasure KPI is added to the last remaining bottleneck loop from the analysis result table-relational model 500 in the relational model database 124, changing the negative loop into a positive loop.

[0108] From step S707 onwards, the user is able to specify different preferences. After each input from the user, the steps are repeated from step S701 onwards. The filtering unit 113 re-filters the CLD based on the new selection.

[0109] Starting from step S707, user A can specify a relationship with another user. When user A decides to specify a relationship with user B, the visualization unit 115 acquires, via the input / output device 131, the value of the user ID 201 in the user table 200 in the master database 121, which is associated with the user name specified by user A.

[0110] The filtering unit 113 adds the value of the specified user ID 201 of “user B” to the stakeholder user ID 231 corresponding to the user ID 231 of user A in the Users relationships Table 230 in the master database 121 .

[0111] As described above, in response to a change in the user relationship, the filtering unit 113 updates the importance weight 304. That is, step S703 is executed in a state in which user B is included in the stakeholders. If user B has decided to hide the KPIs, when the relationship is established by user A, user A will be able to see the hidden KPIs on the CLD, as in step S709 described below.

[0112] In step S708, User A submits access permissions to view the city data values ​​of the KPIs that User B has hidden, along with the connections between the hidden KPIs and User A's associated KPI nodes (see FIG. 14).

[0113] Details of step S709 will be described with reference to the stakeholder relationship CLD integration step shown in Fig. 9, the process of displaying hidden arrows shown in Fig. 10, and further with reference to the screen examples of Fig. 13 to Fig. 16. Here, taking into consideration the terminology of Fig. 10, user B is assumed to be stakeholder B1001 and user A is assumed to be stakeholder A1002.

[0114] 9, if stakeholder B1001 selects to hide any KPI values ​​or connections (S901: YES), the visualization unit 115 displays the non-hidden KPI values ​​and connections of stakeholder B1001 to stakeholder A1002, but does not display the hidden KPI values ​​(city data values) or connections. For example, if stakeholder B1001 hides connections with other parties' CLD branches, the CLD branch of stakeholder B1001 is not connected to other parties' CLDs, and only the CLD branch of stakeholder B1001 is displayed (S902).

[0115] 10, the CLD creation unit collects a CLD from an external system (S1004), and stakeholder B 1001 selects to hide any KPI values ​​or connections (S1005). The visualization unit 115 hides the selected KPI values ​​and connections (S1006), and in response to a specification of a relationship with stakeholder B 1001 from stakeholder A 1002 (S1007), displays only the values ​​of unhidden KPI nodes and connections to KPI nodes to stakeholder A 1002, without displaying the hidden KPI values ​​and connections.

[0116] Next, as shown in step 903 of FIG. 9 and step S1009 of FIG. 10, Stakeholder A 1002 sends a request to Stakeholder B 1001 to view the values ​​of the hidden KPI nodes and the potential links to Stakeholder A's 1002 CLD branches.

[0117] Assume that stakeholder B 1001 accepts the request of stakeholder A 1002, as shown in YES at step S904 in Fig. 9 or S1010 in Fig. 10. As shown in step S905 in Fig. 9 or step S1011 in Fig. 10, the visualization unit 115 displays a link or "arrow" connecting the newly displayed KPI node of stakeholder B 1001 to the related KPI node of stakeholder A 1002, and the KPI node value.

[0118] An example of the processing result of step S902 or S1008 is shown in Fig. 14. The initially hidden "Company customers" node is now displayed to the user, real estate developer A (stakeholder A or user A). Also, only the connections within the node (see Fig. 13) of automobile-related company B (stakeholder B or user B) are displayed. In step S903 or S1009, real estate developer A uses section 1103 in Fig. 14 to send a request to automobile-related company B to view the hidden KPI values ​​and connections.

[0119] If automatic affiliate B accepts the request in step S904 or S1010, the visualization unit 115 displays the hidden KPI node values ​​and the arrows connecting to the CLD of real estate developer A, if any, according to the information collected by the CLD formation unit 111 (S905, S1011). In the KPI list table 300, the value of KPI ID 301 of the KPI name 302 of "Company customers" is obtained. In the node relationship link table 320, the record whose value of link source KPI ID 323 matches the KPI ID of "Company customers" indicates the link destination of the KPI node "Company customers".

[0120] The filtering unit 113 checks permission for real estate developer A based on the linked KPI ID 324 related to the linked KPI ID 323, and if permission is not granted, updates the database so that permission is granted. The value of the linked KPI ID 324 is searched for in the KPI ID 301 of the KPI list table 300. The value of the KPI category 303 of the matching record is obtained. The obtained value of the KPI category 303 is searched for in the KPI access permission 213 of the user type table 210.

[0121] The value of the stakeholder type name 212 of the matching record is obtained. The obtained value of the stakeholder type name 212 is searched in the stakeholder type 203 of the user table 200. Property developer A is searched in the user name 202 of the matching record. The user ID of property developer A is found in the user ID 201. Based on the found user ID 201, the KPI access permission 213 of the user type table 210 for the corresponding user is set to allowed and the database is updated.

[0122] As mentioned above, if User A specifies a relationship with User B, and User B has conditionally displayed KPIs (don't display values, don't display certain links), then the KPIs will be displayed to User A to the extent that the conditions are met, but the KPI values ​​and connections to nodes (if any) that do not meet the conditions will only be displayed if User B gives permission to do so. The nodes associated with the users are shown in Figure 13, and the new display of KPI values ​​and connections is shown in Figure 16. In Figure 15, the connections between the hidden KPIs and the KPIs associated with logged in User A are shown with thick arrows. In Figure 16, the previously hidden KPI values ​​(city data values) are shown.

[0123] After this process, steps S701 to S706 are repeated as shown in Fig. 7. Bottlenecks are identified and the visualization is updated for each input from the user, where the input from the user corresponds to a relationship specification.

[0124] The corresponding filtered links (source KPIID 323-destination KPIID 324 pairs) related to those link IDs 321, including the connections of the initially hidden "Company customers" KPI node, are shown by the visualization unit 115, based on the permissions given to real estate developer A, as shown by the arrows highlighted in bold in Figure 15.

[0125] Furthermore, as in steps S906 and S1011, the initially hidden KPI values ​​are shown to real estate developer A along with all other filtered KPI values. For example, when the PDCA step selected by the user is "Check(C)", city data values ​​405 in sensor and city data values ​​400 associated with KPI name 404 "Company customers" are displayed as shown in FIG.

[0126] Returning to the next step of the CLD filtering and judgment flow diagram in Fig. 7, once again after step S709, when the system completes the bottleneck detection and visualization step, the user can specify the object of interest in the form of a KPI selected from the list displayed on the screen, as shown in steps S710, S711. In the example shown in Figs. 13 to 16, the user selects a KPI in the QoL category from the KPI list menu on the left side of the screen. More specifically, the visualization unit 115 obtains the ID of the KPI in which the user is interested via the input / output device 131 in response to the user's operation. For example, the ID of the KPI "QoL" is obtained.

[0127] The visualization unit 115 searches the node relationship link table 320 of the CLD collection database 122 for all records whose value of link source KPI ID 323 is equal to the value of KPI ID 301 from the KPI list table 300 selected by the user (for example, the ID of the KPI "QoL"), and obtains the link destination KPI ID 324 from those records.

[0128] Next, the visualization unit 115 obtains the next linked KPIID 324 from the record having a value of linking source KPI ID 323 equal to the value of the previous linked destination KPIID 324 (e.g., the ID of the "Urban Attractiveness" KPI). The visualization unit 115 repeats these steps for all instances of the found "QoL" KPI ID until the value of the first linking source KPI ID is found as the value of the linked destination KPI ID. Thus, all loops connected to KPIs of interest to the user are found. At this point, the visualization unit 115 has obtained a set of KPI IDs.

[0129] Next, the visualization unit 115 updates the KPI list table 300 in the CLD collection database 122 to increase the value of the importance weight 304 based on the KPI ID 301 being equal to a KPI ID from the previously obtained set of KPIs, and further based on the importance weight 304 not being equal to "0" (i.e., all KPI nodes that the user is allowed to see).

[0130] After the KPI selection steps S710 and S711, the detection and visualization of bottlenecks are repeated again. The final input from the user is the selection of PDCA, as can be seen from steps S712 and S713.

[0131] As mentioned above, PDCA has four stages: Plan, Do, Check, and Act. Each user can select a specific PDCA stage from his / her authority indicated by the main PDCA task 205. Steps S701 to S706 are repeated according to the selected PDCA stage. In addition, the following process may be performed on the screen.

[0132] As shown in the examples of Figures 11 and 13, stage P may be the stage selected by default and may be displayed to the user first. As shown in the example of Figure 14, when one KPI or stage D is selected from the KPI list, the visualization unit 115 changes the display as if stage D was selected, and further displays selectable options.

[0133] As shown in the example of Fig. 16, in the C stage, the user can visualize the connection between the KPI value (city data value 405) and the hidden KPI nodes of other stakeholders and his / her own CLD on the screen. Also, when the A stage is selected, the user can insert the measure node proposed by the relationship modeling system 150 or the measure node created manually by the user.

[0134] In the above example, the system visualizes CLD for urban planning. The system can visualize CLD in fields other than urban planning. For example, in the disaster field, stakeholders can be police, fire, doctors, local governments, the government, companies, etc. An example of a CLD loop is: Increase in evacuees -> Local governments procure supplies from companies such as food manufacturers for evacuees -> Increase in supply of supplies in disaster areas -> Decrease in supply of supplies in areas other than the disaster area -> Increase in demand from residents in areas other than the disaster area -> Companies supply supplies to areas other than the disaster area -> Decrease in supply of supplies in the disaster area.

[0135] As another example, in the field of automobiles, the stakeholders may be automobile manufacturers and suppliers, etc. Increase in automobile sales->increase in parts orders from automobile manufacturers->increase in parts prices->increase in automobile prices->decrease in automobile sales, etc. Note that some of the above configuration examples may be omitted, for example, identification of bottleneck loops and integration of CLDs based on user relationships may be omitted.

[0136] As described above, the system may determine that a node in a negative loop whose weight is equal to or exceeds a threshold is a critical node and highlight the critical node. In another configuration example, the system may highlight a node whose weight is equal to or exceeds a specified threshold regardless of the nature of the loop, i.e., whether it is a negative loop or a positive loop.

[0137] As described above, the system may construct a causal loop diagram for display to a user with nodes selected from multiple CLDs. In another configuration example, the system may determine weights for the nodes in the constructed causal loop diagram and highlight nodes with weights equal to or greater than a threshold in the display of the causal loop diagram.

[0138] The present invention is not limited to the above-mentioned embodiment, but includes various modified examples. For example, the above-mentioned embodiment has been described in detail to clearly explain the present invention, and is not necessarily limited to those including all of the configurations described. It is also possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.

[0139] In addition, the above-mentioned configurations, functions, processing units, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. In addition, the above-mentioned configurations, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information such as the program, table, file, etc. that realizes each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card or SD card.

[0140] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are connected to each other. [Explanation of symbols]

[0141] 100 City CLD Visualization System 110 Main storage 111 CLD forming part 113 Filtering section 114 Analysis and Bottleneck Detection Department 115 Visualization section 120 Auxiliary storage 121 Master Database 122 CLD Collection Database 123 Collected sensor and city data collection database 124 Relational Model Database 130 Arithmetic equipment 131 I / O Devices 132 Communication Interface 200 User Table 210 User Type Table 220 Default PDCA-KPI Relationship Table 230 User Relationship Table 240 Default Stakeholder Interests Table 300 KPI List Table 310 Collected CLD Tables 320 Node Relationship Link Table 400 Sensor and City Data 500 Analysis Results Table-Relational Model 510 Bottleneck Countermeasures Pattern Table

Claims

1. 1. A system for displaying a causal loop diagram to a user, comprising: one or more computing devices; one or more storage devices; The one or more storage devices include One or more pieces of causal loop diagram information; first management information associating users with nodes; A weight is assigned to each node included in the one or more causal loop diagrams; The one or more computing devices, Obtaining a user identifier that identifies a first user; selecting a node associated with the first user from among the nodes included in the one or more causal loop diagrams with reference to the first management information; Increasing the weight of the selected node; The system highlights nodes whose weight is equal to or greater than a first threshold in a display of a causal loop diagram that includes nodes of the one or more causal loop diagrams.

2. 2. The system of claim 1, The first management information includes user information for managing a type of a node of interest to a user; The one or more computing devices increase a weight of an interest node associated with the first user.

3. 2. The system of claim 1, The first management information is User information for managing the user's related tasks; task-node relationship information that associates tasks with nodes; The one or more computing devices increase a weight of a node associated with a task associated with the first user.

4. 2. The system of claim 1, The one or more storage devices include The first management information includes user information for managing stakeholders associated with a user; The one or more computing devices increase a weight of a node associated with a stakeholder associated with the first user.

5. 2. The system of claim 1, The one or more computing devices, determining a weight of a negative loop in the one or more causal loop diagrams based on weights of nodes constituting the negative loop; A negative loop whose weight is equal to or greater than a second threshold is determined to be a critical loop; The system highlights, in the display of the causal loop diagram, nodes in the critical loop whose weight is equal to or greater than the first threshold.

6. 2. The system of claim 1, The one or more storage devices include user information associating a user identifier with a user type; user type information associating the user type with a node type that is permitted to be displayed; The one or more computing devices, determining a node type that can be displayed to the first user by referring to the user information and the user type information; The causal loop diagram to be displayed is configured with nodes of a displayable node type.

7. 2. The system of claim 1, The one or more computing devices, In displaying the causal loop diagram, only part of information of nodes hidden by the source of the one or more causal loop diagrams is displayed; forwarding a request from the first user to display the hidden node to the source; In response to an acknowledgement from the source, the system displays information about other portions of the hidden nodes.

8. 6. The system of claim 5, The information of the one or more causal loop diagrams includes information of positive and negative relationships between nodes; The first management information includes information for managing measures and positive and negative effects on nodes, The one or more computing devices, determining a node whose weight is equal to or greater than the first threshold in the critical loop as a critical node; A system that selects and displays a measure for the critical node from the first management information, the measure changing the critical loop to a positive loop.

9. A method for a system to display a causal loop diagram to a user, comprising: The system comprises: One or more pieces of causal loop diagram information; first management information associating users with nodes; A weight is assigned to each node included in the one or more causal loop diagrams; The method comprises: Obtaining a user identifier that identifies a first user; selecting a node associated with the first user from among the nodes included in the one or more causal loop diagrams with reference to the first management information; Increasing the weight of the selected node; highlighting nodes whose weight is equal to or greater than a first threshold in a display of a causal loop diagram that includes the nodes of the one or more causal loop diagrams.

Images