Information processing device and program

Abstract

To provide an information processing device and a program capable of supporting creation of a check list.SOLUTION: An information processing device comprises: totalization means which totalizes the number of times of checks on business services performed by using a check list for each of kinds of the business services, and each of check items included in the checklist; reception means which receives an instruction for creation of a new check list designating check target business services; extracting means which extracts check items having the number of times of checks equal to or larger than a threshold, from the totalization result of the totalization means regarding check target business services; and generation means which generates the new check list on the basis of the check items extracted by the extracting means.SELECTED DRAWING: Figure 10

Description

Technical Field

[0001] Embodiments of the present invention relate to an information processing apparatus and a program.

Background Art

[0002] At sites such as stores, various business services (hereinafter also referred to as services) are being carried out. At such sites, by using methods such as the KPI (Key Performance Indicator) tree method and BPMN (Business Process Model and Notation), the processing procedures of each element related to the implementation of the service may be designed as a business process. For example, conventionally, a technique has been proposed that can automatically create a business process so that the input / output relationship between adjacent operations is continuous.

[0003] By the way, in the above-mentioned site, it is important to regularly or at any time check the check items such as the implementation requirements and effects of the designed service. Conventionally, it has been generally carried out to check using a checklist, but it is cumbersome and very difficult to create a checklist every time. In addition, there is a problem that the validity of the checklist depends on the ability of the creator who created the checklist.

Summary of the Invention

Problems to be Solved by the Invention

[0004] The problem to be solved by the present invention is to provide an information processing apparatus and a program capable of assisting in creating a checklist.

Means for Solving the Problems

[0005] The information processing device of this embodiment comprises an aggregation means, a receiving means, an extraction means, and a generation means. The aggregation means aggregates the number of times a business service has been checked using a checklist, for each type of business service and each check item included in the checklist. The receiving means receives an instruction to create a new checklist specifying the business services to be checked. The extraction means extracts check items whose number of checks is equal to or greater than a threshold from the aggregation results of the aggregation means relating to the business services to be checked. The generation means generates the new checklist based on the check items extracted by the extraction means. Furthermore, the aggregation means aggregates the number of times the business service has been checked using the checklist for each attribute of the customer performing the business service, and the extraction means extracts check items whose number of checks is equal to or greater than a threshold from the aggregation results of the aggregation means relating to the attributes of the customer performing the business service being checked. [Brief explanation of the drawing]

[0006] [Figure 1] Figure 1 is a diagram showing an example configuration of a business support system according to an embodiment. [Figure 2] Figure 2 shows an example of the hardware configuration of a terminal device according to this embodiment. [Figure 3] Figure 3 shows an example of the hardware configuration of a server device according to this embodiment. [Figure 4] Figure 4 shows an example of the data structure of the KPI tree database according to the embodiment. [Figure 5] Figure 5 shows an example of a visualized KPI tree according to the embodiment. [Figure 6] Figure 6 shows an example of the data structure of the business flow database according to the embodiment. [Figure 7] Figure 7 shows an example of a visualized business flow according to the embodiment. [Figure 8] Figure 8 shows an example of the data structure of the checklist database according to the embodiment. [Figure 9] Figure 9 shows an example of the data structure of a customer master according to an embodiment. [Figure 10] Figure 10 shows an example of the functional configuration of a terminal device and a server device according to an embodiment. [Figure 11]Figure 11 shows an example of a screen provided by the checklist creation support unit of the embodiment. [Figure 12] Figure 12 shows an example of a screen provided by the check support unit of the embodiment. [Figure 13] Figure 13 shows an example of the data structure of the check result aggregation DB according to the embodiment. [Figure 14] Figure 14 shows an example of a checklist generated by the checklist creation support unit of the embodiment based on aggregated information of the check results. [Figure 15] Figure 15 is a flowchart showing an example of the process related to the creation of a checklist executed by the server device of the embodiment. [Modes for carrying out the invention]

[0007] The embodiments will be described in detail below with reference to the drawings. However, the invention is not limited to the embodiments described below.

[0008] Figure 1 shows an example configuration of a business support system according to an embodiment. As shown in Figure 1, the business support system 1 includes a terminal device 10 and a server device 20. The terminal device 10 and the server device 20 are connected to each other via a network N such as a LAN (Local Area Network).

[0009] Terminal device 10 is a terminal device used by users of the business support system 1. Terminal device 10 performs various processes in response to user operations. For example, a user can use various functions provided by server device 20 by operating terminal device 10 to access server device 20. Terminal device 10 can be implemented as a stationary terminal device such as a PC (Personal Computer), or a portable terminal device such as a notebook PC, tablet, or smartphone.

[0010] The server device 20 is an example of an information processing device. The server device 20 provides various functions to the terminal device 10. For example, the server device 20 provides functions such as creating and viewing a KPI tree, a business process, and a checklist, which will be described later.

[0011] In this embodiment, an example in which the server device 20 is realized by a single information processing device will be described, but it is not limited thereto. For example, the server device 20 may be realized by a plurality of information processing devices by means of technologies such as cloud computing.

[0012] Next, the configurations of the terminal device 10 and the server device 20 described above will be described.

[0013] FIG. 2 is a diagram showing an example of the hardware configuration of the terminal device 10. As shown in FIG. 2, the terminal device 10 includes computer components such as a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, and a RAM (Random Access Memory) 13.

[0014] The CPU 11 is an example of a processor and comprehensively controls each part of the terminal device 10. The ROM 12 stores various programs. The RAM 13 is a workspace for developing programs and various data.

[0015] The terminal device 10 also includes a display unit 14, an operation unit 15, a storage unit 16, and a communication unit 17.

[0016] The display unit 14 is composed of a display device such as an LCD (Liquid Crystal Display). The display unit 14 displays various information under the control of the CPU 11. The operation unit 15 has a keyboard, a pointing device, etc. The operation unit 15 outputs the operation content received from the user to the CPU 11. Note that the operation unit 15 may be a touch panel provided on the display screen of the display unit 14.

[0017] The memory unit 16 is composed of a storage medium such as an HDD (Hard Disk Drive) or a flash memory, and maintains the stored content even when the power is turned off. The memory unit 16 stores programs that the CPU 11 can execute and various setting information. For example, the memory unit 16 stores application programs such as a web browser that can utilize various functions provided by the server device 20.

[0018] The CPU 11 operates according to a program stored in the ROM 12 and the memory unit 16 and expanded in the RAM 13, thereby executing various processes.

[0019] The communication unit 17 is a communication interface that can be connected to the network N. The communication unit 17 communicates with external devices such as the server device 20 via the network N.

[0020] FIG. 3 is a diagram showing an example of the hardware configuration of the server device 20. As shown in FIG. 3, the server device 20 includes a computer configuration such as a CPU 21, a ROM 22, and a RAM 23.

[0021] The CPU 21 is an example of a processor and comprehensively controls each part of the server device 20. The ROM 22 stores various programs. The RAM 23 is a workspace for expanding programs and various data.

[0022] In addition, the server device 20 includes a display unit 24, an operation unit 25, a memory unit 26, and a communication unit 27.

[0023] The display unit 24 is composed of a display device such as an LCD. The display unit 24 displays various information under the control of the CPU 21. The operation unit 25 has a keyboard, a pointing device, etc. The operation unit 25 outputs the operation content received from the user to the CPU 11. Note that the operation unit 25 may be a touch panel provided on the display screen of the display unit 24.

[0024] The memory unit 26 is composed of a storage medium such as an HDD or flash memory, and retains its contents even when the power is cut off. The memory unit 26 stores programs that the CPU 21 can execute and various setting information. For example, the memory unit 26 stores web application programs that can provide various functions to the terminal device 10. The CPU 21 executes various processes by operating according to programs stored in the ROM 22 and the memory unit 26 and loaded into the RAM 23.

[0025] Furthermore, the memory unit 26 stores KPI tree DB 261, business flow DB 262, checklist DB 263, customer master 264, and check result summary DB 265, etc.

[0026] The KPI Tree DB261 is a table or database for storing and managing KPI trees. Here, a KPI tree is tree data in a tree structure where the relationship between an organization's or company's management goals (the final goal described later) and the measures to achieve those goals (intermediate goals, factors, solutions, services, etc. described later) is set stepwise by nodes.

[0027] Figure 4 shows an example of the data structure of the KPI tree DB261. As shown in Figure 4, the KPI tree DB261 stores customer names, KPI trees, etc., associating each KPI tree with an identifiable tree ID.

[0028] The "Customer Name" field contains information that identifies the customer to whom the KPI tree applies. The "KPI Tree" field contains the actual data for the KPI tree (hereinafter also referred to as the data file) or an address indicating the location where the data file is stored.

[0029] A KPI tree is created using methods such as KPIs (Key Performance Indicators). A KPI tree can be represented in a visualized form, as shown in Figure 5, for example.

[0030] Figure 5 shows an example of a visualized KPI tree. Specifically, Figure 5 shows the visualized KPI tree applied to the customer "ABC Supermarket" shown in Figure 4.

[0031] As shown in Figure 5, a KPI tree consists of multiple nodes connected in a tree structure. Here, the root node, Final Goal Node A, is the node for setting the achievement goal. Final Goal Node A corresponds to, for example, a KGI (Key Goal Indicator). For example, if the ultimate goal is to increase store sales, then "Sales" would be set as Final Goal Node A.

[0032] The final target node A is connected to one or more intermediate target nodes B. It is also possible to connect one or more intermediate target nodes B to each intermediate target node B. Intermediate target nodes B are set with intermediate goals to achieve the goals (final or intermediate goals) set in the node directly above them. Intermediate target nodes B correspond to, for example, KPIs (Key Performance Indicators).

[0033] Figure 5 shows an example where, below the final target node A, intermediate target node Ba is set to increase the number of customers visiting the store, and intermediate target node Bb is set to increase the average spending per customer. It also shows an example where, below intermediate target node Bb, intermediate target node Bc is set to increase the number of stores, and intermediate target node Bd is set to increase the average price per item.

[0034] Furthermore, in the KPI tree, it is possible to place factor nodes C below the intermediate goal node B, which represent the factors necessary to achieve the intermediate goal set in intermediate goal node B. Factor node C corresponds to, for example, a KSF (Key Success Factor).

[0035] Figure 5 shows an example where, under the intermediate target node Ba, factor nodes Ca to Cd are placed, each representing a factor for increasing the number of customers visiting the store: "Quality Improvement," "Product Assortment," "Sales Floor," and "Advertising." It also shows an example where, under the intermediate target node Bc, factor nodes Ce and Cf are placed, each representing a factor for increasing the number of items sold: "Sales Promotion" and "Impulse Buying." Furthermore, it shows an example where, under the intermediate target node Bb, factor node Cg is placed, each representing a factor for increasing the average customer spending: "Improved Customer Understanding."

[0036] Furthermore, in the KPI tree, it is possible to place a Solution Node D below the Intermediate Target Node B or Factor Node C, which represents a solution that achieves (resolves) the intermediate objective or factor set in the node directly above it.

[0037] Figure 5 shows an example where solution nodes Da and Db, each configured for "store information visualization" and "product assortment optimization," are placed under factor nodes Ca to Cc. It also shows an example where solution nodes Dc to De, each configured for "coupon issuance," "point management," and "POP creation," are placed under factor node Ce. Furthermore, it shows an example where solution node Df, configured for "CRM (Customer Relationship Management)," is placed under factor node Cg.

[0038] Furthermore, in the KPI tree, it is possible to place a service node E under a factor node C or solution node D, which represents a specific service for realizing the factor or solution set in the node directly above it. Here, service node E corresponds to the strategy at the end.

[0039] Each node is assigned a node ID to identify it, and information about the corresponding node is stored in association with this identifier. For example, service node E is associated with a flow ID and checklist ID, which will be described later, to specify the business flow related to the execution of the service.

[0040] Figure 5 shows an example where a service node Ea, configured with "Service A," is placed under the solution node Df.

[0041] Each node in the KPI tree is assigned a node ID to identify it. The KPI tree is saved, for example, in JSON (JavaScript Object Notation) format. However, the KPI tree is not limited to JSON; it may also be saved in other data formats such as XML (Extensible Markup Language).

[0042] Returning to Figure 3, the business flow DB262 is a table or database for storing and managing business flows. A business flow is a data file that describes each element related to the execution of a business and the execution content performed by that element as a series of procedures. Specifically, a business flow describes the execution content and procedures performed by each element related to the implementation of a service. In other words, in this embodiment, a business flow is a concept that corresponds to a service. Hereafter, a business flow will also be referred to as a service.

[0043] Figure 6 shows an example of the data structure of the business flow DB262. As shown in Figure 6, the business flow DB262 stores the target service, flow ID, business flow name, and data file in association with each other.

[0044] The "Target Services" field registers information specifying the service corresponding to the business process described in the business flow. Specifically, it registers the node ID of the service node E designated as the target service, the tree ID of the KPI tree to which the service node E belongs, etc. However, this is not the only way to specify the target service.

[0045] The Flow ID field registers a Flow ID that identifies the business flow. The Business Flow Name field registers information indicating the name of the business flow. For example, the Business Flow Name may be the name of the service performed by the business flow (the node name of service node E). The Data File field registers the data file of the business flow or an address indicating the location where the data file is stored.

[0046] Business flows are created using methods such as flowcharts and BPMN (Business Process Modeling Notation). Business flows should be created according to the service content, but if the service content is common or similar, the same business flow can be used even if the KPI trees are different. Figure 6 shows an example in which the business flow with flow ID "F01" is used in service node Ea, which is included in the KPI trees with tree IDs T01 and T02, respectively.

[0047] Business processes are created using methods such as flowcharts and BPMN (Business Process Modeling Notation). Business processes can be represented in a visualized form, for example, as shown in Figure 7.

[0048] Figure 7 shows an example of a visualized business process flow. Note that Figure 7 is an example of the business process flow related to service node Ea (Service A) in the KPI tree shown in Figure 5.

[0049] As shown in Figure 7, in the business flow, the sequence of actions (or processes) related to the implementation of service A is described for each element that performs the action between the start event ST and the end event EN. The business flow in Figure 7 shows an example where the elements are described as "customers" visiting the store, "surveillance cameras" and "payment systems" installed in the store, and "store employees" working in the store.

[0050] Here, "surveillance cameras" are an example of hardware resources, and are installed, for example, at multiple locations within a store. Similarly, "payment systems" are an example of software resources, and are implemented through the collaboration of multiple PCs (Personal Computers), such as POS systems, and applications installed on those PCs. Furthermore, additional services provided in conjunction with payment (e.g., point services) may also be included in the business flow. Hereafter, the hardware resources, software resources, and additional services related to the implementation of the target services will be collectively referred to as "elements."

[0051] In the business flow diagram in Figure 7, the "customer" flow is first described as entering the store (step Qa), selecting the products to be purchased (step Qb), and proceeding to the cash register (step Qc). The "surveillance camera" flow installed in the store is described as taking a picture of the "customer" heading to the cash register (step Qd) and transmitting the captured image data to the payment system installed in the store (step Qe). The "payment system" flow is described as receiving the image data from the "surveillance camera" (step Qf) and displaying customer information such as the "customer's" attributes derived from the image data on a display device (step Qg).

[0052] Furthermore, the workflow for a "store clerk" operating the register is described as follows: confirming customer information displayed by the "payment system" (step Qh), and performing register operations for the items brought in by the "customer" (step Qi). In addition, it is described that the "payment system" executes the "payment processing" in conjunction with the "store clerk's" register operations (step Qj).

[0053] Furthermore, it is described that the "customer" pays for the goods (step Qk) in accordance with the "payment processing" of the "payment system" and leaves the store (step Ql). It is also described that the "payment system" stores data showing the details of this transaction upon payment (step Qm).

[0054] Furthermore, when implementing a points service, for example, the payment system identifies the member number of the "customer" represented in the photographic data by comparing the photographic data received in step Qf with the facial image of each member that has been registered in advance. The payment system then accumulates and stores the points issued according to the purchase amount, associating them with the identified member number.

[0055] The business process flow described above is saved, for example, in JSON format. However, the business process flow is not limited to JSON; it may also be saved in other data formats such as XML.

[0056] Returning to Figure 3, the checklist DB263 is a table or database for storing and managing checklists for checking requirements related to the implementation of a service and the effects of implementing that service.

[0057] Figure 8 shows an example of the data structure of the checklist DB263. As shown in Figure 8, the checklist DB263 stores the target service, flow ID, checklist ID, check target, and data file in association with each other.

[0058] The "Target Service" field registers information that identifies the service being checked. Specifically, it registers the node ID of the service node E corresponding to the service being checked, the tree ID of the KPI tree to which the service node E belongs, etc. The "Flow ID" field registers the flow ID of the business flow corresponding to the service being checked. Note that Figure 8 shows an example where both the target service and flow ID are registered, but in a configuration where the flow ID is identified from the business flow DB262 using the target service as a search key, the flow ID may be removed from the checklist DB263.

[0059] The "Checklist ID" field registers a checklist ID that identifies the checklist. The "Item to be checked" field registers information indicating the item to be checked. For example, the item to be checked may include the names of elements such as hardware resources and software resources related to the implementation of the target service. For example, if the service of service node Ea, as explained in Figures 5 and 7, is the target service, elements such as "surveillance camera" and "payment system" may be checked, as shown in Figure 8. Note that the item to be checked is not limited to hardware and software resources; the entire service may also be the item to be checked (corresponding to "entire service" in Figure 8).

[0060] The data file entries include the data file for the checklist or an address indicating the location where the data file is stored. A checklist is created for each item to be checked and contains one or more check items. For example, a checklist may include check items for non-functional requirements in addition to functional requirements. Here, "non-functional requirements" refer to requirements other than functional requirements, such as performance, availability, and security requirements for the item.

[0061] In this embodiment, the KPI tree and business flow may be pre-created, or they may be created via the terminal device 10 or the like with assistance from the server device 20. In the latter case, for example, the server device 20 provides the terminal device 10 with a screen (GUI (Graphical User Interface)) to assist in viewing, creating, and editing the KPI tree and business flow.

[0062] Specifically, the server device 20 provides the terminal device 10 with a screen that allows creation and editing of various nodes and the relationships between nodes in a visualized state. Then, once the creation or editing of the KPI tree is complete, the server device 20 stores the KPI tree in the KPI tree DB 261.

[0063] Furthermore, when any service node E included in the KPI tree is selected, the server device 20 provides a screen that allows the creation and editing of business flows and checklists for the service corresponding to that service node E. When either a business flow or a checklist is created, the server device 20 stores it in the corresponding database, associating it with the node ID and tree ID of service node E.

[0064] Returning to Figure 3, the customer master 264 is a table or database for storing and managing information about customers to whom the KPI tree will be applied.

[0065] Figure 9 shows an example of the data structure of the customer master 264. As shown in Figure 9, the customer master 264 stores information such as industry, sales, number of employees, region, customer attributes, and data update date, associated with the customer name. Here, the customer name corresponds to the customer name registered in the KPI tree 261 in Figure 4.

[0066] The "Industry" field registers information indicating the customer's industry. For example, the type of retail business or store format, such as supermarket or drugstore, may be registered as the industry. The "Sales" field registers information regarding the sales revenue of the customer's business. While there are no specific requirements for the sales revenue recognition period, it is preferable to use the same period for all customers. The "Number of Employees" field registers the number of employees working at the customer's company or store. The "Region" field registers information regarding the region in which the customer operates.

[0067] The customer attributes section registers information indicating the attributes of customers categorized according to predetermined criteria. The criteria for categorizing attributes can be arbitrarily set and can be used, for example, based on industry, sales, number of employees, region, etc. Figure 9 shows an example of customer attributes (S-1, S-2) where customers in the "supermarket" industry are represented by the symbol "S" and categorized into multiple levels according to sales or number of employees. It also shows an example of customer attributes (D-1) where customers in the "drugstore" industry are represented by the symbol "D" and categorized into multiple levels according to sales or number of employees.

[0068] The "Data Update Date" field will contain the date the customer's data was registered in customer master 264 or the date the customer's data was updated.

[0069] Returning to Figure 3, the Check Results Aggregation DB265 is a table or database for storing and managing the aggregated results of checks performed using the checklist. The data structure of the Check Results Aggregation DB265 will be described later.

[0070] The communication unit 27 is a communication interface that can be connected to the network N. The communication unit 27 communicates with external devices such as the terminal device 10 via the network N.

[0071] Next, the functional configuration of the terminal device 10 and the server device 20 will be described with reference to Figure 10. Figure 10 is a diagram showing an example of the functional configuration of the terminal device 10 and the server device 20.

[0072] As shown in Figure 10, the terminal device 10 includes a display control unit 111 and an operation reception unit 112 as functional units.

[0073] Some or all of the functional components of the terminal device 10 may be implemented as software through the cooperation of the terminal device 10's processor (e.g., CPU 11) and a program stored in its memory (e.g., ROM 12, storage unit 16). Alternatively, some or all of the functional components of the terminal device 10 may be implemented as hardware through dedicated circuits or the like mounted on the terminal device 10.

[0074] The display control unit 111 of the terminal device 10 controls the display unit 14 to display various screens on the display unit 14. For example, the display control unit 111 displays various operation screens on the display unit 14 based on information provided by the server device 20.

[0075] The operation reception unit 112 of the terminal device 10 receives user operations via the operation unit 15. For example, when the operation reception unit 112 receives an operation on the screen displayed on the display unit 14, it notifies the server device 20 of the details of that operation.

[0076] On the other hand, the server device 20 includes the following functional units: a GUI provision unit 211, a design support unit 212, a checklist creation support unit 213, a check support unit 214, a check result aggregation unit 215, a display control unit 216, and an operation reception unit 217.

[0077] Some or all of the functional components of the server device 20 may be implemented as software through the cooperation of the server device 20's processor (e.g., CPU 21) and a program stored in its memory (e.g., ROM 22, storage unit 26). Alternatively, some or all of the functional components of the server device 20 may be implemented as hardware through dedicated circuits or the like mounted on the server device 20.

[0078] The GUI provider unit 211, in cooperation with other functional units, provides the terminal device 10 with information that enables the display of various operation screens (hereinafter also simply referred to as "screens"). Here, the GUI provider unit 211 may provide data representing a screen, or it may provide various content data related to the display of a screen. Hereinafter, the provision of information related to the display of a screen by the GUI provider unit 211 to the terminal device 10 will be referred to as "providing" a screen or "displaying" a screen.

[0079] The design support unit 212, in collaboration with the GUI provision unit 211, provides screens to support the creation of KPI trees and business flows.

[0080] For example, the design support unit 212 provides a screen that allows the creation of a KPI tree by arranging various nodes, edges, etc., as drawing parts. Here, the design support unit 212 displays the visualized KPI tree in response to user operations. The design support unit 212 can also associate a business flow (flow ID) with the service node E of the KPI tree in response to user operations. When the design support unit 212 receives confirmation that the creation or editing of the KPI tree is complete, it generates a data file representing the KPI tree and stores it in the KPI tree DB 261.

[0081] Furthermore, the design support unit 212 provides a screen that allows the user to select a KPI tree to be viewed or edited based on the KPI tree DB 261. When a KPI tree is selected, the design support unit 212 reads that KPI tree from the KPI tree DB 261 and provides a screen that visualizes the KPI tree.

[0082] Furthermore, the design support unit 212 provides a screen that allows the creation of a business flow by arranging drawing parts and the like that correspond to the BPMN notation rules. Here, the design support unit 212 displays a visualized business flow in response to user operations. When the design support unit 212 receives confirmation that the business flow has been created or edited, it generates a data file representing the business flow and stores it in the business flow DB 262, associating it with the target service.

[0083] The checklist creation support unit 213 is an example of a receiving means, an extraction means, and a generation means. The checklist creation support unit 213 works in cooperation with the GUI provision unit 211 to provide a screen to support the creation of a checklist. Specifically, when the checklist creation support unit 213 receives an instruction to create a checklist specifying the services to be checked via a KPI tree or the like, it provides a screen to support the creation of the checklist.

[0084] Here, Figure 11 shows an example of a screen provided by the checklist creation support unit 213 (hereinafter also referred to as the creation support screen). Figure 11 shows the creation support screen when the service node Ea included in the KPI tree in Figure 5 is selected.

[0085] As shown in Figure 11, the creation support screen 30 has a tab TA corresponding to "Overall," a tab TB corresponding to "Surveillance Camera," and a tab TC corresponding to "Payment Service." Tabs TA to TC are provided for each item to be checked. The tabs may be automatically generated based on elements included in the business flow of the specified service, or they may be added or deleted by the user.

[0086] When any one of the tabs TA to TC is selected, the checklist creation support unit 213 displays an editable screen in the input area 31 that corresponds to the selected tab. Figure 11 shows an example where tab TA, which corresponds to "Overall," is selected.

[0087] The input area 31 is provided with an input field 311 where users can enter check items. Any string of text can be entered into the input field 311. Users set check items by entering a string of text representing the items to be checked into the input field 311. Users can also edit the string displayed in the input field 311. Furthermore, additional input fields 311 can be added by operating the add button 312.

[0088] Furthermore, the check items are divided into categories, for example, by common groups. Figure 11 shows an example where the check items are divided into operation-related and maintenance-related groups. In the input area 31, the user can arbitrarily set and edit the groups.

[0089] When the checklist creation support unit 213 receives an operation to instruct the user to complete editing, it generates a checklist (data file) for each item to be checked based on the check items set in the input area 31. The checklist creation support unit 213 then stores the generated checklist in the checklist DB 263, associating it with the target service and flow ID.

[0090] Furthermore, the checklist creation support unit 213 has a function to automatically generate checklists based on the information stored in the checklist result aggregation DB 265. The functions related to the automatic generation of checklists will be described later.

[0091] Returning to Figure 10, the check support unit 214 works in cooperation with the GUI provision unit 211 to provide a screen to support the checking process using a checklist.

[0092] When the checklist creation support unit 213 receives an instruction to perform a check operation specifying the target service to be checked via a KPI tree or the like, it provides a screen to support the check operation. Specifically, the check support unit 214 reads the checklist associated with the target service from the checklist DB 263. Then, the check support unit 214 displays a screen to support the check operation based on the read checklist.

[0093] Figure 12 shows an example of a screen provided by the check support unit 214 (hereinafter also referred to as the check screen). Here, Figure 12 shows the check screen of the checklist generated on the creation support screen in Figure 11. As shown in Figure 12, the check screen 40 has tabs TD to TF, which correspond to each of the tabs TA to TC shown in Figure 11, and it is possible to switch the check target by selecting the tab.

[0094] Specifically, the check support unit 214 generates a tab for each item to be checked and creates a check screen that allows switching between items using the tabs. The screen displayed when a tab is switched shows the checklist for the item corresponding to that tab. In other words, by switching tabs, the checklist can be switched.

[0095] Figure 12 shows the tab TD corresponding to "Overall" selected, and the check items for each group related to operation and maintenance, which are set in the "Overall" checklist, are displayed in input area 41. In addition, each check item has four associated options: "Not done," "On hold," "OK," and "NG," and it is configured so that one of these options can be selected.

[0096] This allows users to select the appropriate option while reviewing the content of the check items for the items they have selected in tabs TD to TF. Therefore, users can easily review the check items related to the implementation of the service. Here, the selection of options for each check item is at the discretion of the user performing the check. Furthermore, selecting an option is not mandatory; for example, if a user determines that a check item does not need to be checked, they can proceed to the next check item without selecting any options.

[0097] In Figure 12, there are four options for the check items, but the number and types of options are not limited to this. For example, the system may be configured to allow users to input text as answers to the check items. Furthermore, the system may be configured to allow users to set the method for answering the check items during the checklist creation stage.

[0098] Furthermore, when the check support unit 214 receives an operation to instruct the completion of the check, it stores the check results performed for each check item, associating them with the corresponding checklist of the item being checked.

[0099] Here, the storage location of the check results is not particularly specified. For example, the check support unit 214 may store the check results in the checklist DB 263 by directly associating them with the corresponding checklist (data file) in the checklist DB 263. Alternatively, the check support unit 214 may store the check results in a storage unit (database, etc.) different from the checklist DB 263. The check support unit 214 stores the check results for each instance in a way that allows them to be referenced by associating the date the check was performed with the check results and managing them as generations.

[0100] Returning to Figure 10, the check result aggregation unit 215 is an example of an aggregation means. The check result aggregation unit 215 aggregates the number of times a service was checked using the checklist for each check item and stores the aggregated results in the check result aggregation DB 265. Specifically, the check result aggregation unit 215 aggregates the number of times each check item of the checklist was checked for each service (business flow) that was the subject of the check, and for each customer attribute of the customer related to the KPI tree to which the service belongs. The check result aggregation unit 215 then stores the number of checks for each check item as the aggregated result in the check result aggregation DB 265.

[0101] Figure 13 shows an example of the data structure of the check result aggregation DB265. As shown in Figure 13, the check result aggregation DB265 stores the check target, group, check item, flow ID, customer attribute, number of checks, data update date, etc., in association with each other.

[0102] The "Items to be checked" field registers the items to be checked in the checklist being aggregated. The "Group" field registers the group name, etc., of the group included in the checklist being aggregated. The "Check items" field registers the check items included in the group being aggregated. In addition, the "Flow ID" field registers the flow ID associated with the checklist ID of the checklist being aggregated, i.e., the flow ID of the service being checked. The "Customer attributes" field registers the customer attributes of the customer related to the KPI tree that includes the service being checked.

[0103] The "Number of Checks" field registers the number of times each check item has been performed. Specifically, the check result aggregation unit 215 aggregates the number of checks performed for each check item included in a checklist with the same flow ID, for each customer attribute related to that checklist, and registers it as the number of checks for the corresponding data entry.

[0104] Here, the check result aggregation unit 215 counts the selection of any of the check items as 1, and the case where no options are selected as 0. Note that the method of aggregating the number of checks is not limited to this and can be set arbitrarily. For example, the number of times a specific option among the check item options is selected could be counted.

[0105] Additionally, the data update date field registers the date on which the check count was updated. The check result aggregation unit 215 updates the data update date to the current date at the time the check count is registered (updated).

[0106] Thus, the aggregation of check results is performed at the level of the checklist, group, and check item being checked. Furthermore, the aggregation of check results is performed at the level of flow ID and customer attribute. Therefore, for example, if customer attributes are common in different KPI trees and the services set in those KPI trees are checked using checklists with similar content, the check results will be aggregated in the same aggregation group. On the other hand, if the customer attributes of the customers to whom the KPI trees are applied are different, the check results will be aggregated in different aggregation groups for each customer attribute.

[0107] Furthermore, depending on the customer to whom the KPI tree is applied, even if the content of the check items means the same thing, the wording of the check items set in the checklist may differ. In this case, it is preferable for the check result aggregation unit 215 to use known natural language processing technology or the like to merge check items with similar content and aggregate the check results. For example, if the string of a check item means to confirm network availability, the check result aggregation unit 215 will merge it into a representative check item and aggregate the number of checks, even if there are differences in notation.

[0108] Furthermore, the data structure of the check result aggregation DB265 is not limited to Figure 13; for example, it may include other items. Specifically, the check result aggregation DB265 may include the operating period of the service corresponding to the business flow of the flow ID as an item. In this case, for example, the check result aggregation unit 215 aggregates the number of checks by dividing them into predetermined periods (e.g., one month) based on the operating period at the time the check was performed.

[0109] Incidentally, when the content of services provided to multiple customers is similar, that is, when the business flow is similar, it is highly likely that the items to be checked in the checklist will also be similar. Therefore, when the checklist creation support unit 213 is instructed to create a new checklist for a service that is similar to the business flow covered by an existing checklist, it generates a checklist with automatically set check items based on the data entries stored in the check result aggregation DB 265 (hereinafter also referred to as aggregation information).

[0110] Specifically, when the checklist creation support unit 213 receives instructions to create a new checklist specifying the services to be checked via a KPI tree or the like, it uses the flow ID of the business flow related to the services to be checked and the customer attributes of the customer as search keys, and searches the check result summary DB 265 for aggregated information that matches the search keys. If aggregated information matching the search keys exists, the checklist creation support unit 213 extracts aggregated information where the number of checks is equal to or greater than a threshold, based on the number of checks included in the retrieved aggregated information. Then, based on the check targets, groups, and check items included in the extracted aggregated information, the checklist creation support unit 213 generates a checklist with check items set for each check target.

[0111] If no aggregated information matching the search key exists, the checklist creation support unit 213 provides a creation support screen, as described above, allowing the user to set the checklist items from scratch.

[0112] Here, we consider a scenario where a new checklist is created for a service with flow ID "F01" in a KPI tree created for a customer with customer attribute "S-1". In this case, the checklist creation support unit 213 searches the check result aggregation DB 265 shown in Figure 13 for four data entries with check counts of 100, 50, 30, and 90, which are aggregate information that meets the conditions of customer attribute "S-1" and flow ID "F01". If the threshold for check count is 50 or more, the checklist creation support unit 213 extracts three data entries with check counts of 100, 50, and 90. Then, based on the check target, group, and check items included in the extracted data entries, the checklist creation support unit 213 generates a checklist with set check items and displays a screen representing the checklist.

[0113] Figure 14 shows an example of a checklist generated by the checklist creation support unit 213 based on aggregated information of the check results. The screen in Figure 14 is the same creation support screen as in Figure 11, and the check items related to the "overall" check item are displayed in the input area 31.

[0114] In the creation support screen shown in Figure 14, the input area 31 displays strings representing the items to be checked for the operation-related and maintenance-related groups, with the check items already set. Additionally, the check item "Can the network be secured?", which has been checked below the threshold, is removed from the input area 31.

[0115] Thus, when instructed to create a checklist, the checklist creation support unit 213 automatically generates a checklist with set check items based on the aggregated results of checks on existing checklists that share common customer attributes and service content. As a result, the checklist creation support unit 213 can generate a checklist that includes check items that were effectively used during the check, thus saving the user the trouble of creating a checklist from scratch.

[0116] Furthermore, the checklist creation support unit 213 can generate checklists that omit checklist items that are rarely used, thus enabling the generation of checklists that include essential checklist items. Consequently, the checklist creation support unit 213 can generate highly valid checklists that do not depend on the abilities of the checklist creator.

[0117] Furthermore, the checklist creation support unit 213 extracts check items by narrowing down the aggregated information that has common service (flow ID) and customer attributes, so it can generate a checklist that includes check items with similar perspectives, such as the scale of service implementation and the target of the service.

[0118] In the example above, check items were extracted based on the number of checks, but the extraction criteria are not limited to the number of checks. For example, the data update date could be added as an extraction criterion, and aggregated information whose data update date falls within a predetermined period could be extracted. In this case, the predetermined period could be set to, for example, within one month or six months from the current date. This allows the checklist creation support unit 213 to generate a checklist based on recent aggregated results.

[0119] Furthermore, if the check result aggregation DB265 includes the service operating period as an item, that item may be added to the extraction criteria. For example, if the service operating period is added to the extraction criteria, the checklist creation support unit 213 may extract aggregated information for the category to which the operating period belongs, based on the operating time of the service for which the checklist was created. This makes it possible to include or exclude check items that were frequently checked during a specific period, such as the start of the service, from the extraction target. Therefore, check items that are appropriate to the actual situation of the service for which the checklist was created can be efficiently extracted.

[0120] In the screen shown in Figure 14, the user is able to edit the checklist items automatically set by the checklist creation support unit 213. However, the system is not limited to this configuration, and it may also be configured so that editing of the checklist items automatically set by the checklist creation support unit 213 is not possible.

[0121] Furthermore, in this embodiment, the checklist creation support unit 213 is configured to generate a checklist that removes check items whose check count is less than a threshold, but this is not limited to this configuration. For example, the checklist creation support unit 213 may generate a checklist in which check items whose check count is less than a threshold are represented in an identifiable manner. In this case, the checklist creation support unit 213 may represent check items whose check count is less than a threshold in red, or otherwise make them identifiable from other check items.

[0122] Furthermore, in this embodiment, the checklist creation support unit 213 is configured to display the generated checklist on the screen in an editable state, but this is not limited to this configuration. For example, the checklist creation support unit 213 may immediately store the generated checklist in the checklist DB 263. Alternatively, the checklist creation support unit 213 may cooperate with the check support unit 214 to immediately display a check screen based on the generated checklist.

[0123] Returning to Figure 10, the display control unit 216 of the server device 20 controls the display unit 24 to display various screens on the display unit 24. For example, the display control unit 216 displays various screens provided by the GUI provider unit 211 on the display unit 24.

[0124] The operation reception unit 217 of the server device 20 receives user operations via the operation unit 25. For example, when the operation reception unit 217 receives an operation on one of the various operation support screens displayed on the display unit 24, it outputs the details of that operation to the CPU 21.

[0125] The following describes an example of the operation of the server device 20 mentioned above. Figure 15 is a flowchart showing an example of the process related to the generation of a checklist executed by the server device 20. It should be noted that this process assumes that an existing checklist is stored in the checklist DB 263, and that aggregated information of the check results performed using the said checklist is stored in the check result aggregation DB 265.

[0126] First, the design support unit 212 accepts the selection of the KPI tree to be displayed from the KPI tree DB 261 (step S11). Next, the design support unit 212 visualizes and displays the selected KPI tree (step S12).

[0127] Next, the checklist creation support unit 213 accepts the selection of the service node E to be used for creating the checklist from the displayed KPI tree (step S13). Once the service node E is selected, the checklist creation support unit 213 refers to the aggregated information of the checklist related to service node E stored in the check result aggregation DB (step S14). More specifically, the checklist creation support unit 213 searches the check result aggregation DB for aggregated information that matches the conditions of the customer attributes of the customer related to the KPI tree selected in step S11 and the flow ID of the business flow related to service node E selected in step S13.

[0128] Next, the checklist creation support unit 213 extracts check items from the aggregated information whose check count is equal to or greater than a threshold, based on the number of checks in the searched aggregated information (step S15). Then, the checklist creation support unit 213 generates a checklist based on the extracted check items (step S16) and displays a screen on which the checklist can be edited (step S17).

[0129] Here, the user operating the screen can edit or add check items, as explained in Figure 11. The user then signals "editing complete" after finishing the editing operation. Note that editing is not mandatory; the user may signal "editing complete" without performing any editing operations.

[0130] The checklist creation support unit 213 waits until it is instructed to complete editing (Step S18; No). Then, when the checklist creation support unit 213 receives the instruction to complete editing (Step S18; Yes), it stores the checklist displayed on the screen in the checklist DB 263 (Step S19) and terminates this process.

[0131] As described above, the server device 20 of this embodiment aggregates the number of times a service related to a business flow that has been checked using a checklist, for each type of business flow and each check item included in the checklist. Furthermore, when the server device 20 receives an instruction to create a new checklist specifying the services to be checked, it extracts check items whose number of checks exceeds a threshold from the aggregated results for the services to be checked, and generates a new checklist based on the extracted check items.

[0132] Thus, when the server device 20 is instructed to create a new checklist, it generates a checklist using checklist items that have been effectively utilized from checklists used for similar services. This allows the server device 20 to assist in checklist creation by saving the user the trouble of creating a checklist from scratch. Furthermore, the server device 20 can generate a checklist that includes essential checklist items by omitting checklist items that are rarely used. In this way, the server device 20 can generate a highly valid checklist that does not depend on the ability of the checklist creator.

[0133] Furthermore, the server device 20 aggregates the number of checks for each customer attribute of the customer providing the service, and extracts check items whose number of checks exceeds a threshold from the aggregated results related to the customer attributes of the customer providing the service that will be checked in the newly created checklist. As a result, the server device 20 can include check items with check perspectives appropriate to the attributes of the customer providing the service in the checklist, thereby generating a highly valid checklist.

[0134] Furthermore, the server device 20 can also categorize and aggregate the number of checks for each check item based on the service's operating period. In this case, the server device 20 extracts check items whose number of checks exceeds a threshold from the aggregated results for the category to which the operating period of the service being checked in the newly created checklist belongs. As a result, the server device 20 can include check items that are frequently checked during the operating period of the service being checked in the checklist, thereby generating a highly valid checklist.

[0135] Furthermore, the server device 20 provides an editable screen for the generated checklist and reflects the editing results made through this screen in the generated checklist. This allows the server device 20 to reflect the user's intentions in the generated checklist, thereby assisting in the creation of checklists.

[0136] Furthermore, the server device 20 receives instructions to create a checklist by selecting a service node E configured in the KPI tree. This allows the server device 20 to receive instructions to create a checklist based on the KPI tree, thereby improving user convenience in business support.

[0137] The embodiments described above can also be modified and implemented as appropriate by changing some of the configurations or functions of each of the devices described above. Therefore, several modifications of the embodiments described above will be described below as other embodiments. In the following, we will mainly describe the differences from the embodiments described above, and will omit detailed explanations of points that are common with what has already been described. Furthermore, the modifications described below may be implemented individually or in combination as appropriate.

[0138] (Variation 1) In the above embodiment, an example was shown in which the terminal device 10 and the server device 20 cooperate to display various screens provided by the server device 20 on the terminal device 10. However, the embodiment is not limited to this, and the terminal device 10 may also display the information on its own.

[0139] In this case, the terminal device 10 can display various screens related to the creation and editing of checklists by including, for example, the GUI provision unit 211, the design support unit 212, the checklist creation support unit 213, and the check support unit 214 described above. The terminal device 10 is assumed to be in a state where it can read and write to the various databases held by the server device 20.

[0140] In this case, some or all of the KPI tree DB261, business flow DB262, checklist DB263, customer master 264, and check result aggregation DB265 may be held by the terminal device 10, or by another device (or cloud) that the terminal device 10 can access.

[0141] (Modification 2) In the embodiment described above, the server device 20 stores and manages the business flow in association with the service node E of the KPI tree. However, it is not limited to this configuration, and the business flow may be stored and managed independently without being associated with the service node E.

[0142] (Variation 3) In the above embodiment, a configuration for aggregating check results for each customer attribute was described, but the system is not limited to this, and check results may be aggregated without using customer attributes. Alternatively, instead of customer attributes, check results may be aggregated for each detail such as the customer's name, industry, or region. In this case, the checklist creation support unit 213 shall extract check items using aggregated information corresponding to the customer name, industry, region, and other details related to the service specified in the checklist creation instruction.

[0143] The programs executed in each of the above-described embodiments are provided pre-installed in ROM, storage units, etc. Alternatively, the programs executed in each of the above-described embodiments may be provided as installable or executable files recorded on a computer-readable recording medium such as a CD-ROM, flexible disk (FD), CD-R, or DVD (Digital Versatile Disk).

[0144] Furthermore, the programs executed by each of the above-described embodiments may be stored on a computer connected to a network such as the Internet and provided by being downloaded via the network. Alternatively, the programs executed by each of the above-described embodiments may be provided or distributed via a network such as the Internet.

[0145] Although embodiments of the present invention have been described above, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments and their variations can be implemented in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents. [Explanation of symbols]

[0146] 1. Business support system 10 Terminal devices 20 Server Devices 111 Display Control Unit 112 Operation Reception Unit 211 GUI provision department 212 Design Support Department 213 Checklist Creation Support Department 214 Check Support Department 215 Check Result Aggregation Department 216 Display Control Unit 217 Operation Reception Section 261 KPI Tree DB 262 Business Flow Database 263 Checklist DB 264 Customer Master 265 Check Result Summary DB [Prior art documents] [Patent Documents]

[0147] [Patent Document 1] Japanese Patent Publication No. 2014-235470

Claims

1. A means for aggregating the number of times a business service has been checked using a checklist, for each type of business service and each check item included in the checklist, A means of receiving instructions to create a new checklist specifying the business services to be checked, An extraction means for extracting check items whose number of checks exceeds a threshold from the aggregation results of the aggregation means relating to the business services to be checked, A generation means that generates a new checklist based on the check items extracted by the extraction means, Equipped with, The aggregation means aggregates the number of times the business service was checked using the checklist for each attribute of the customer on whom the business service is performed. The extraction means is an information processing device that extracts check items whose number of checks is equal to or greater than a threshold from the aggregation results of the aggregation means relating to the attributes of customers who perform the business services to be checked.

2. The aggregation means aggregates the number of checks by dividing them into predetermined periods based on the operating period during which the business service is performed. The extraction means extracts check items whose number of checks is equal to or greater than a threshold from the aggregation results of the aggregation means for the category to which the operating period of the business service to be checked belongs. The information processing apparatus according to claim 1.

3. The generation means provides an editable screen for the generated new checklist and reflects the editing results in the new checklist. The information processing apparatus according to claim 1.

4. A tree structure in which the relationship between a customer's business objectives and measures to achieve those objectives is set in stages by nodes, wherein the tree data is associated with the customer's attributes and is associated with the last node of the tree data, and holds the business service corresponding to the measure of that node, the checklist related to that business service, and the aggregated result of the number of checks, and further comprises a display control means for displaying the tree data in a visible state on a display unit, The receiving means receives an instruction to create a new checklist by selecting the last node of the tree data displayed on the display unit. An information processing apparatus according to any one of claims 1 to 3.

5. The computer of the information processing device, A means for aggregating the number of times a business service has been checked using a checklist, for each type of business service and each check item included in the checklist, A means of receiving instructions to create a new checklist specifying the business services to be checked, An extraction means for extracting check items whose number of checks exceeds a threshold from the aggregation results of the aggregation means relating to the business services to be checked, A generation means that generates a new checklist based on the check items extracted by the extraction means, and make it work The aggregation means aggregates the number of times the business service was checked using the checklist for each attribute of the customer on whom the business service is performed. The extraction means is a program that extracts check items whose number of checks is equal to or greater than a threshold from the aggregation results of the aggregation means relating to the attributes of customers who perform the business services to be checked.

Images