JP2010271806A - Work flow processing program, method and device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To detect, as apparent transition, transition between events in a process instance created by sequentially arranging event instances (EIs) each belonging to any of an event classes (ECs) of a plurality of work events implemented during work processing, the events being independently implemented in parallel with each other with no causal relationship between the works corresponding to the source and destination events. <P>SOLUTION: When the transition from a source EI to a destination EI is the apparent transition where works corresponding to the ECs including the EIs have no causal relationship and are independently implemented in parallel with each other, a value of an evaluation expression prescribed by use of occurrence probability of the EI belonging to a destination EC of the transition T and conditioned probability that the EI belonging to the destination EC of the transition T is calculated when the EI belonging to a source EC of the transition T to be determined, for each transition, based on a property that phenomena generated by the source EI and the destination EI are stochastically independent phenomena, and detects the transition wherein the value of the evaluation expression becomes less than a threshold value. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  This technology relates to business process analysis technology.

  For business process re-engineering (BPR), it is necessary to analyze the business system currently used in the enterprise. For this reason, the following technologies exist.

  That is, (1) event data, which is information indicating the execution state of each application arranged in different business systems, is collected by a method corresponding to each application and queued in an event queue. Here, the event indicates that a certain business has been executed in the business system, and is data including the start time, end time, and related attributes of the business. The event data is extracted by an event data extraction application for each business system according to the event extraction definition arranged in each business system. Within each business system, the extracted event information is converted into a common XML (eXtensible Markup Language) format and queued in an event queue of an event management apparatus that manages event data. For this queuing, for example, JMS (Java (registered trademark) Message Service) is used.

  (2) In the event management apparatus, event information queued in the event queue is collected for each business data, and the business data is associated and stored in the event management database (DB). Here, the business data means data shared between a certain unit of business. (3) The business data is narrowed down based on the input search conditions (for example, event occurrence period, related attributes, etc.). (4) Data related to the narrowed down business data is expanded and displayed in a tree, and processing from arbitrary data is traced. (5) An event related to the business data expanded in the tree is searched, the business related to this event is illustrated in the tracking view, and the current execution status of the business flow is displayed. Here, tracking refers to a technique for confirming which business is being executed and which is not being executed, among business processes that are the flow of the entire business across the business systems defined in advance.

  In such a technique, it is necessary to introduce an application for extracting event data for each business system, and the business system is modified or an unnecessary load is applied to business execution.

  As a countermeasure, there is an analysis method using business system database backup data, business log data, or the like without modifying the business system and applying unnecessary load to the business execution. That is, for a plurality of tables in the database, for each item in each table, an item evaluation step for calculating an item score that is a value based on the number of appearances for each value in the item is different from the plurality of tables. Select table as related source table and related destination table, select related source item that is item in related source table and related destination item that is item in related destination table, and combination of related source item and related destination item For each relationship generated by the relationship generation step, the number of occurrences of each value in the related source item in the related destination item, the item score of the related source item, and the item score of the related destination item The relationship evaluation step for calculating the relationship score, which is a value based on the It can be.

  Here, as an example, each table name is the event name, the item storing the date and time data is the time stamp item that is the event occurrence date and time, and the related source item and the related destination item extracted in the above analysis are By setting the event ID and the related ID as items, it is possible to extract event instance data.

  On the other hand, as a prior art for extracting a flow model between events from an event log that is an accumulation of records composed of event names, event IDs, and time stamps, it is determined whether adjacent contexts, causal relationships, parallels, or irrelevance There is an α algorithm that applies rules to all flow instances. Since the α algorithm is rule-based, it is vulnerable to noise present in the actual data obtained from the operating business system, and in principle, if the workflow of the target business contains repetitions and rework, it is wrong in principle. There is a problem that it cannot be applied because

JP 2005-115494 A JP 2008-27072 A

Ana Karla Alves de Medeiros, "Process Mining: Control-Flow Mining Algorithms", [Online] [Search March 8, 2009], Internet (URL: http://prom.win.tue.nl/research/wiki / processminingcourse)

  By using the above technology for business system database backup data and business log data, event instances (records) and correspondences between them can be extracted, and event IDs can be shared. Alternatively, the process instances created by simply connecting event records (corresponding) via the related IDs in series based on the date and time of occurrence are the actual instances corresponding to the event class to which each event instance belongs. When the business flow of a business includes a main route and a parallel route branched from the main route, the business flow does not correspond to the actual business flow. That is, when event instances that occur on the main route and event instances that occur on the parallel route are mechanically linked in the order of occurrence date and time, an apparent transition that has no meaning in business is included.

  Therefore, the purpose of this technology is the transition between events in process instances created by chronologically arranging event instances belonging to any of the event classes of a plurality of business events executed during business processing related to a specific matter. It is to provide a technology for apparently detecting a transition that has been performed independently and in parallel without any causal relationship between the tasks corresponding to the originating event and the terminating event of the transition between the events. . Note that a transition source event of an inter-event transition is referred to as an originating event, and a transition destination event is referred to as a destination event.

  In this business flow data processing method, (A) process instance data created by arranging in a time series event instances belonging to any of the event classes of a plurality of business events executed during business processing related to a specific matter. The occurrence frequency of transitions from the event class to the destination event class from the transitions between the event instances included in each process instance stored in the stored process instance data storage unit is counted as the transition frequency between events. By dividing the frequency of occurrence of transition between events stored in the statistical information storage unit by the frequency of occurrence of event instances belonging to the corresponding originating event class, Event instances belonging to the originating event class In addition to calculating the conditional probability that an event instance belonging to the destination event class will occur if it occurs, the frequency of event instances belonging to each event class is divided by the sum of the occurrence frequency of event instances belonging to all event classes. To calculate the occurrence probability of the event instance belonging to each event class and store it in the statistical information storage unit, and (C) the event class of a plurality of business events executed during the business processing related to a specific matter Transition between events in a process instance created by arranging event instances belonging to one of them in chronological order, and there is no causal relationship between the tasks corresponding to the originating event and the terminating event of the transition between the events. That are being implemented in parallel This is an evaluation expression for detecting the event, and when an event instance belonging to the originating event class of the transition to be judged occurs, there is a condition that an event instance belonging to the destination event class of the transition to be judged occurs The evaluation formula value defined using the probability and the occurrence probability of the event instance belonging to the event class on the arrival side of the transition to be judged is the value related to each event transition frequency stored in the statistical information storage unit. A step of calculating the transition and storing it in the statistical information storage unit; and (D) a value of the evaluation formula stored in the statistical information storage unit that is less than a predetermined threshold among the evaluation formula values of each transition. And apparently detecting such a transition as a transition.

  A transition between events in a process instance created by arranging in a time series event instances that belong to one of the event classes of a plurality of business events executed during business processing related to a specific matter. There is no causal relationship between the tasks corresponding to the originating side event and the destination side event, and it can be detected as an apparent transition that has been performed independently and in parallel.

It is a functional block diagram in an embodiment of the present invention. It is a functional block diagram of a parallel processing estimation part. (A) thru | or (d) is a figure for demonstrating the outline | summary of embodiment of this invention. It is a figure which shows the main processing flow in embodiment of this invention. (A) is the schema information of order DB which is an example of extracted data, (b) is a figure which shows the record group of order DB. (A) is the schema information of production DB which is an example of extracted data, (b) is a figure which shows the record group of production DB. (A) is the schema information of arrangement DB which is an example of extracted data, (b) is a figure which shows the record group of arrangement DB. (A) is the schema information of delivery DB which is an example of extraction data, (b) is a figure which shows the record group of delivery DB. (A) is the schema information of product number DB which is an example of extraction data, (b) is a figure which shows the record group of product number DB. (A) shows an example of data in an order DB in CSV format, and (b) is a diagram showing an example in which data in an order DB is tabulated. (A) shows the example of data of production DB of a CSV format, (b) is a figure which shows the example which tabulated the data of production DB. (A) shows the example of data of arrangement DB of CSV format, (b) is a figure which shows the example which tabulated the data of arrangement DB. (A) shows an example of data in a delivery DB in CSV format, and (b) is a diagram showing an example in which data in the delivery DB is tabulated. (A) is an example of data in the product number DB in the CSV format, and (b) is a diagram showing an example in which the data of the product number DB is tabulated. It is a figure which shows the processing flow of a time stamp determination process. It is a figure which shows an example of a time stamp accuracy score table | surface. It is a figure which shows the processing flow of event ID and a related ID candidate determination process. It is a figure which shows an example of an event ID and related ID candidate accuracy score table. It is a figure which shows the processing flow of an event name determination process. It is a figure which shows an example of the table containing multiple time stamps. (A) thru | or (e) is a figure which shows the example which divided | segmented the table of FIG. 19 into several tables for every event. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of order DB in the case where schema information exists. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of order DB in the case of the data of CSV format. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of production DB in the case where schema information exists. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of production DB in the case of the data of CSV format. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of arrangement DB in the case where schema information exists. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of arrangement DB in the case of the data of CSV format. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of delivery DB in the case where schema information exists. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of delivery DB in the case of the data of CSV format. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of product number DB in the case where schema information exists. It is a figure which shows an example of the determination display with respect to each element of the event candidate data of article number DB in the case of the data of CSV format. It is a figure which shows an example of the selection result with respect to each element of event candidate data. It is a figure which shows an example of the event candidate data produced | generated from the data of order DB in the case where schema information exists. It is a figure which shows an example of the event candidate data produced | generated from the data of order DB in the case of the data of CSV format. It is a figure which shows an example of the event candidate data produced | generated from the data of production DB when schema information exists. It is a figure which shows an example of the event candidate data produced | generated from the data of production DB in the case of the data of CSV format. It is a figure which shows an example of the event candidate data produced | generated from the data of arrangement DB in the case where schema information exists. It is a figure which shows an example of the event candidate data produced | generated from the data of arrangement DB in the case of the data of CSV format. It is a figure which shows an example of the event candidate data produced | generated from the data of delivery DB when schema information exists. It is a figure which shows an example of the event candidate data produced | generated from the data of delivery DB in the case of the data of CSV format. It is a figure which shows an example of the event candidate data regarding the draft of FIG. It is a figure which shows an example of the event candidate data regarding the approval of FIG. It is a figure which shows an example of the event candidate data regarding the order of FIG. It is a figure which shows an example of the event candidate data regarding the delivery of FIG. It is a figure which shows an example of the event candidate data regarding the inspection of FIG. It is a figure which shows an example of event data and an event relationship tree. It is a figure for demonstrating the process instance production | generation from event data. It is a figure which shows an example of a process instance. It is a figure for demonstrating the extraction process of a main and exception flow. It is a figure which shows the example of a display in the case of superimposing the process instance shown in FIG. (A) thru | or (c) is a figure which shows the example of a display at the time of classifying the process instance shown in FIG. 48 into the main flow and the exception flow. It is a figure for demonstrating the problem of a prior art. It is a figure for demonstrating the problem of a prior art. It is a figure for demonstrating the problem of a prior art. It is a figure which shows what extracted only the business flow including the parallel processing on business in the business flow of FIG. It is a figure which shows an example of the process instance containing the main path | route and the parallel path | route branched from the said main path | route. FIG. 57 is a diagram showing an example of classification of main flows and exception flows when the process instance groups A to E of FIG. 51 are replaced with the process instances of FIG. It is a figure which shows the whole work flow including the parallel processing on work. FIG. 56 is a diagram showing an overall flow when the process instances shown in FIG. 55 are overlapped. It is a figure which shows the processing flow of a parallel process estimation process. It is the figure which showed typically the preparation method of the transition frequency table between events. It is a figure which shows an example of the transition frequency table between events. It is a figure which shows a part of transition frequency table between events. It is a figure which shows typically calculation of the generation probability of each event. It is a figure which shows calculation of a conditional probability typically. It is a figure which shows an example of the generation probability of each event. It is a figure which shows an example of a conditional probability table | surface. It is a figure for demonstrating the independence of an event. It is a figure which shows the example of calculation of an evaluation index value. It is a figure which shows the processing flow of a parallel process estimation process. It is a figure which shows an example of the data stored in a parallel process applicable process instance data storage part. It is a figure which shows the processing flow of a parallel process estimation process. It is a schematic diagram for demonstrating the setting of an alternative transition. It is a schematic diagram for demonstrating the setting of an alternative transition. It is a figure which shows the processing flow of a parallel process estimation process. It is a figure which shows an example of the process instance at the time of deleting a transition apparently. It is a figure which shows an example of the process instance at the time of setting the alternative transition of apparent transition. It is a figure which shows an example of the data stored in a model data storage part. It is a figure which shows the processing flow of a flow display process. It is a figure which shows an example at the time of superimposing the main flows of the process instance shown in FIG. It is a functional block diagram of a computer apparatus.

  1A and 1B are functional block diagrams of a business system analysis apparatus according to an embodiment of the present invention. The business system analysis apparatus according to the present embodiment includes data collected from one or a plurality of analysis target systems (database record group, log data, network DB (NDB) record group, journal, etc. generated in a predetermined period). Analysis target data storage unit 1 that stores event candidate data generation unit 3 that generates event candidate data from the analysis target data storage unit 1, and an event that stores event candidate data generated by the event candidate data generation unit 3 Candidate data storage unit 5, input / output unit 11 serving as an interface with the user, event data generation unit 7 that receives user instructions via the input / output unit 11 and generates event data, and event data generation unit 7 An event data storage unit 9 for storing the event data that has been received, A process instance generation unit 13 that generates a process instance from event data stored in the event data storage unit 9, a process instance data storage unit 15 that stores data of a process instance generated by the process instance generation unit 13, and a process The process instance data stored in the instance data storage unit 15 is used to detect the apparent transitions resulting from the parallel processing, the process instances including them are extracted, and the flow of the process instance is changed to the apparent transition. A parallel processing estimation unit 17 that is corrected by adding a transition of parallel processing estimated after deletion, a process instance that has been corrected by the parallel processing estimation unit 17 and a process instance that has not been processed by the parallel processing estimation unit 17 Process instance data storage unit 19 after parallel processing estimation that stores the data of the process, and the process instance that classifies the process instances stored in the process instance data storage unit 19 after the parallel processing estimation based on the arrangement of events and counts the number of occurrences The classification processing unit 21, the model data storage unit 23 that stores the processing results of the process instance classification processing unit 21, and the processing necessary for displaying the business flow using the data stored in the model data storage unit 23 And a process display processing unit 25 to be implemented.

  The input / output unit 11 also operates as an interface with the user for the event candidate data generation unit 3, the process instance generation unit 13, the parallel processing estimation unit 17, and the process display processing unit 25. In addition, each processing unit may perform processing such as reading a processing result and presenting it to the user via the input / output unit 11.

  The event candidate data generation unit 3 includes a time stamp processing unit 31, an event ID / related ID candidate processing unit 32, an event name processing unit 34, and a score table storage unit 35.

  As shown in FIG. 1B, the parallel processing estimation unit 17 includes a statistical information extraction unit 171 that calculates various statistical data from the event occurrence status in the process instance stored in the process instance data storage unit 15, and a statistical information extraction. A statistical information storage unit 173 that stores statistical information calculated by the unit 171, and exists as a component of a process instance stored in the process instance data storage unit 15 using data stored in the statistical information storage unit 173 The transition includes an apparent transition detection unit 175 that detects an apparent transition that is a transition that is estimated not to occur in actual business, and a process that includes the apparent transition detected by the apparent transition detection unit 175. Detect instances and remove apparent transitions in the process instance An apparent transition deletion unit 177, a parallel processing corresponding process instance data storage unit 181 for storing process instance data including the apparent transition extracted by the apparent transition deletion unit 177, and a parallel processing corresponding process instance data storage unit And an alternative transition determination processing unit 179 that identifies a transition to be set instead of an apparent transition using the data stored in 181.

  Next, a rough processing content of the business system analysis apparatus will be described with reference to FIGS. First, the event candidate data generation unit 3 generates event candidate data from data on the business system stored in the analysis target data storage unit 1. An example of event candidate data is shown in FIG. In the example of FIG. 2A, for example, from one table (for example, a database), the event name, the date and time (time stamp that is the date and time when the event occurred), the other first value (value 1), the first A record group including a value of 2 (value 2) and the like is extracted. In other words, event names and time stamps, and other data fields that are candidates for event IDs and related IDs are specified.

  Next, the event data generation unit 7 generates event data from the event candidate data stored in the event candidate data storage unit 5. An example of event data is shown in FIG. In the example of FIG. 2B, from a plurality of tables (for example, databases), a record group including an event name, date and time (time stamp which is an event occurrence date and time), event ID (here ID1), and other values, A record group including an event name, date and time (time stamp), ID1, ID2, and the like is extracted. The field value of ID2 which is the related ID of the record of the second event class (ie, event type) is the field value of ID1 which is the event ID of the record of the first event class (ie, event type). Is taken to identify which record (ie, event instance) of the first event class is associated with each record (ie, event instance) of the second event class. The process itself for extracting the association between events is not the main part in the present embodiment, but is already disclosed in, for example, Japanese Patent Application Laid-Open No. 2008-27072.

  Thereafter, the process instance generation unit 13 generates process instance data from the event data stored in the event data storage unit 9. An example of the process instance is shown in FIG. In the example of FIG. 2C, four process instances are illustrated, and each process instance includes a series of event instances (specific events). That is, for example, a process instance is composed of consecutive event instances (specific events that correspond to specific records) belonging to event classes such as “order received”, “draft”, “delivery”, and “inspection”. However, the event instances included in the process instances do not have to be derived from all event classes, and a plurality of event instances belonging to one event class may be included. The process instance generation process itself is not a main part in the present embodiment, and for example, a business process tracking method such as US Patent Publication No. 2005 / 076059A1 can be used.

  Then, the process instance data is processed by the parallel processing estimation unit 17 and the process instance classification processing unit 21, and the process display processing unit 25 uses the process flow (business flow) from the data stored in the model data storage unit 23. Data) is also displayed on the display device via the input / output unit 11. An example of the process flow is shown in FIG. In the example of FIG. 2D, a business flow in which process instances are identified and specified is shown.

  Next, details of the processing of the business system analysis apparatus shown in FIGS. 1A and 1B will be described with reference to FIGS. First, the user designates the analysis target table in the business system, copies the data, and stores it in the analysis target data storage unit 1 (FIG. 3: step S1). For example, an order DB, a production DB, an arrangement DB, a delivery DB, and a product number DB are designated, and a record group generated and accumulated in a predetermined period is copied and stored in the analysis target data storage unit 1. If these DBs are relational databases, the schema information is also copied and stored in the analysis target data storage unit 1. Since this step is a process performed in advance by the user operating the computer, it is indicated by a dotted line block in FIG.

  For example, when the order DB is a relational database, schema information as shown in FIG. 4A and a record group as shown in FIG. 4B are stored in the analysis target data storage unit 1. In the example of schema information shown in FIG. 4A, the field name, key setting data, data type, record length, and comment are registered for each of the fields 1 to 4. From FIG. 4A, the date and time is registered in field 1, the order number as the primary key is registered in field 2, the region is registered in field 3, and the order details are registered in field 4. I understand. Specifically, the record group is as shown in FIG. 4B, but if the schema information as shown in FIG. 4A is obtained, the contents of the record group as shown in FIG. 4B are easily interpreted. be able to.

  Similarly, when the production DB is a relational database, schema information as shown in FIG. 5A and a record group as shown in FIG. 5B are stored in the analysis target data storage unit 1. In the example of schema information shown in FIG. 5A, the field name, key setting data, data type, record length, and comment are registered for each of the fields 1 to 5. From FIG. 5A, the date and time is registered in field 1, the production number as the primary key is registered in field 2, the order number as the secondary key is registered in field 3, and the secondary key is registered in field 4. It can be seen that the product number is registered and the delivery date is registered in the field 5. Specifically, the record group is as shown in FIG. 5B, but if the schema information as shown in FIG. 5A is obtained, the contents of the record group as shown in FIG. 5B are easily interpreted. be able to.

  Further, when the arrangement DB is a relational database, schema information as shown in FIG. 6A and a record group as shown in FIG. 6B are stored in the analysis target data storage unit 1. In the example of schema information shown in FIG. 6A, the field name, key setting data, data type, record length, and comment are registered for each of the fields 1 to 5. From FIG. 6A, the date and time is registered in field 1, the order number as the primary key is registered in field 2, the order number as the secondary key is registered in field 3, and the secondary key is registered in field 4. It can be seen that the product number is registered and the delivery destination is registered in the field 5. Specifically, the record group is as shown in FIG. 6B, but if the schema information as shown in FIG. 6A is obtained, the contents of the record group as shown in FIG. 6B are easily interpreted. be able to.

  Further, when the delivery DB is a relational database, schema information as shown in FIG. 7A and a record group as shown in FIG. 7B are stored in the analysis target data storage unit 1. In the example of schema information shown in FIG. 7A, the field name, key setting data, data type, record length, and comment are registered for each of the fields 1 to 4. From FIG. 7A, date and time are registered in field 1, an arrangement number as a primary key is registered in field 2, a delivery flight as a secondary key is registered in field 3, and a delivery destination is stored in field 4. You can see that it is registered. Specifically, the record group is as shown in FIG. 7B, but if the schema information as shown in FIG. 7A is obtained, the contents of the record group as shown in FIG. 7B can be easily interpreted. be able to.

  When the product number DB is a relational database, schema information as shown in FIG. 8A and a record group as shown in FIG. 8B are stored in the analysis target data storage unit 1. In the example of schema information shown in FIG. 8A, field names, key setting data, data types, record lengths, and comments are registered for fields 1 and 2, respectively. From FIG. 8A, it can be seen that the product number which is the primary key is registered in the field 1, and the product name is registered in the field 2. Specifically, the record group is as shown in FIG. 8B, but if the schema information as shown in FIG. 8A is obtained, the contents of the record group as shown in FIG. 8B are easily interpreted. be able to.

  On the other hand, when the data of the order DB is acquired in the CSV format, data as shown in FIG. 9A is stored in the analysis target data storage unit 1. In the example of FIG. 9A, label data such as date / time, order number, region, and order contents are included at the top, and thereafter, the data is listed in the order of the labels, and the data is separated by commas. If the table format is used to make FIG. 9 (a) easier to understand, it will be as shown in FIG. 9 (b). That is, the table includes a date / time column, an order number column, a region column, and an order content column. Since there is no schema information, all data is stored as character strings. There is no key setting data.

  Similarly, when the data of the production DB is acquired in the CSV format, data as shown in FIG. 10A is stored in the analysis target data storage unit 1. In the example of FIG. 10 (a), label data such as date / time, production number, order number, product number, and delivery date is included at the head, and then the data is listed in the order of the labels, and the data is separated by commas. Yes. To make FIG. 10A easy to understand, a table format is shown in FIG. 10B. That is, the table includes a date / time column, a production number column, an order number column, a product number column, and a delivery date column.

  Further, when the data of the arrangement DB is acquired in the CSV format, data as shown in FIG. 11A is stored in the analysis target data storage unit 1. In the example of FIG. 11A, label data such as date / time, arrangement number, order number, product number, and delivery destination is included at the top, and then the data is listed in the order of the labels, and the data is separated by commas. ing. In order to make FIG. 11 (a) easy to understand, a table format is shown in FIG. 11 (b). That is, the table includes a date / time column, an arrangement number column, an order number column, a product number column, and a delivery destination column.

  Furthermore, when the data of the delivery DB is acquired in the CSV format, data as shown in FIG. 12A is stored in the analysis target data storage unit 1. In the example of FIG. 12A, label data such as date / time, arrangement number, delivery flight, and delivery destination is included at the top, and thereafter, the data is listed in the order of the labels, and the data is separated by commas. . To make FIG. 12A easy to understand, a table format is shown in FIG. That is, the table includes a date / time column, an arrangement number column, a delivery flight column, and a delivery destination column.

  Further, when the data of the product number DB is acquired in the CSV format, data as shown in FIG. 13A is stored in the analysis target data storage unit 1. In the example of FIG. 13A, label data of a product number and a product name is included at the head, and thereafter, the data is arranged in the order of the labels, and the data is separated by commas. If the table format is used to make FIG. 13 (a) easier to understand, it will be as shown in FIG. 13 (b). That is, the table includes a product number column and a product name column.

  For example, the event candidate data generation unit 3 of the business system analysis apparatus determines whether all the analysis target tables have been processed (step S3). If there is an unprocessed analysis target table, one unprocessed analysis target table is specified (step S5). Then, a time stamp determination process is performed (step S7). This time stamp determination process will be described with reference to FIGS.

  First, the time stamp processing unit 31 of the event candidate data generation unit 3 identifies one unprocessed field in the analysis target table from the analysis target data storage unit 1 (FIG. 14: step S31). Then, it is determined whether the schema information of the analysis target table is usable in the analysis target data storage unit 1 (step S33).

  If the schema information is usable, the data portion for the processing target field is specified in the schema information, and it is determined whether or not the data type of the processing target field is a time stamp type (step S35). ). If the data type of the processing target field is not the time stamp type, the process proceeds to step S39. For example, in the case of processing data as shown in FIGS. 9A to 13A, there is no schema information, so the process proceeds to step S39.

  On the other hand, when it is determined that the data type of the processing target field is a time stamp type, the time stamp determination of the processing target field is set to “confirmed” and stored in a storage device such as a main memory (step S37). ). Then, the process proceeds to step S43.

  For example, in the case of schema information as shown in FIG. 4A, since the data type of field 1 is a time stamp type, if field 1 is a processing target field, time stamp determination = “determined” is set. In the case of schema information as shown in FIG. 5A, since the data type of the field 1 is a time stamp type, if the field 1 is a processing target field, the time stamp determination = “determined” is set. The same applies to FIGS. 6A and 7A. In the case of FIG. 8A, the process proceeds from step S35 to step S39 for all fields.

  If it is determined in step S33 that the schema information is unusable or the data type of the processing target field is not a time stamp type, the time stamp accuracy score table stored in the score table storage unit 35 is referred to, and the schema information The accuracy is specified from the corresponding data portion of the processing target field, the label data indicating the field name of the processing target field, and the field value of the processing target field (step S39).

  An example of the time stamp accuracy score table is shown in FIG. In the example of FIG. 15, the accuracy score is set to 1 (%) if the field data type is a variable-length character string, and the accuracy score is 5 (%) if the field data type is a real number. If the field name ends with "Time", "Time", etc., the accuracy score is set to 90 (%), and the field name ends with "Monday", "Day", etc. If not, the accuracy score is set to 70 (%). If a future time such as “plan” or “delivery date” is specified as the field name, the accuracy score is set to 10 (%). If the string contains characters other than time-related characters such as year (symbol), “/”, “:”, “′”, “.”, “−”, Numbers, and blanks, the accuracy score is 5 ( %) And the field value string is “YYYY / MM / If the format is “Dhh: mm: ss”, the accuracy score is set to 90 (%). If the character string of the field value is “YYYY / MM / DD”, the accuracy score is set to 70 (%). If the same field value is included, the accuracy score is set to 30 (%), and if there is no corresponding item, the accuracy score is set to 50 (%).

  For example, in the case of the schema information as shown in FIG. 4A and the record group as shown in FIG. 4B, the probability score is assumed that the field value includes characters other than characters related to time. 5 (%) is specified. Similarly, the probability score 5 (%) is specified for the field 3 on the assumption that the field value includes characters other than the characters related to time. Furthermore, since the data type of the field 4 is a variable length character string, the accuracy score is specified as 1 (%). For field 4, since the field value includes characters other than time-related characters, it corresponds to a plurality of items in the time stamp accuracy score table, but in this embodiment, it is 50 (%). The value that deviates from the median is adopted. That is, 1 (%) is adopted rather than the accuracy score of 5 (%) when the field value includes characters other than characters related to time.

  On the other hand, in the case of FIG. 9A in which schema information does not exist, for field 1, since the character string of the field value is in the format of “YYYY / MM / DD hh: mm: ss”, the accuracy score 90 ( %). The same applies to fields 2 and 3, but for field 4, the data type of the field cannot be specified. Therefore, it is determined that the field value includes characters other than those related to time. Score 5 (%) is specified.

  Also, in the case of the record group as shown in FIG. 5B in the schema information as shown in FIG. 5A, for the fields 2 to 4, the field values include characters other than characters related to time. The accuracy score is 5 (%). For field 5, since the character string of the field name includes “delivery date”, the accuracy score is specified as 10 (%). Note that the field value character string in the format of “YYYY / MM / DD” corresponds to a plurality of items in the time stamp accuracy score table, but in the present embodiment, 50 (% ), Which is more deviated from the median. That is, 10 (%) is adopted rather than the accuracy score 70 (%) when the character string of the field value is in the format of “YYYY / MM / DD”. In the case of FIG. 10A in which schema information does not exist, for field 1, since the character string of the field value is in the format of “YYYY / MM / DD hh: mm: ss”, the accuracy score 90 (%) Identified. As for the fields 2 to 5, since the data type is not related, the same result as the case where the schema information exists is obtained.

  Further, in the case of the record group as shown in FIG. 6B in the schema information as shown in FIG. 6A, regarding the fields 2 to 5, it is assumed that the field value includes characters other than characters related to time. An accuracy score of 5 (%) is specified. In the case of FIG. 11A in which schema information does not exist, for field 1, since the character string of the field value is in the format of “YYYY / MM / DD hh: mm: ss”, the accuracy score 90 (%) Identified. As for the fields 2 to 5, since the data type is not related, the same result as that in the case where the schema information exists can be obtained.

  Further, in the case of the record group as shown in FIG. 7B in the schema information as shown in FIG. 7A, regarding the fields 2 to 4, it is assumed that the field value includes characters other than characters related to time. An accuracy score of 5 (%) is specified. In the case of FIG. 12A in which schema information does not exist, for field 1, since the character string of the field value is in the format of “YYYY / MM / DD hh: mm: ss”, the accuracy score is 90 (%). Identified. Since the data types are not related to the fields 2 to 4, the same result as that when schema information exists is obtained.

  Further, in the case of the record group as shown in FIG. 8B in the schema information as shown in FIG. 8A, regarding the fields 1 and 2, it is assumed that the field value includes characters other than characters related to time. An accuracy score of 5 (%) is specified. In the case of FIG. 13A in which the schema information does not exist, the data type is not related, so that the same result as in the case where the schema information exists can be obtained.

  Returning to the description of FIG. 14, the time stamp determination of the processing target field is set to the specified accuracy score (step S41). The numerical values mentioned above are identified.

  Then, it is determined whether all fields in the processing target table have been processed (step S43). If there is an unprocessed field, the process returns to step S31. On the other hand, when all fields are processed, the process returns to the original process.

  As described above, a high accuracy score is set in a highly probable field as an event time stamp. If the time stamp is clear from the data type, data indicating the probability of “determined” is set.

  Returning to the description of FIG. 3, next, the event ID / related ID candidate processing unit 32 of the event candidate data generating unit 3 performs an event ID and related ID candidate determination process (step S9). The event ID and related ID candidate determination processing will be described with reference to FIGS.

  The event ID / related ID candidate processing unit 32 identifies one unprocessed field in the analysis target table stored in the analysis target data storage unit 1 (step S51). Then, it is determined whether the field value of the processing target field stored in the analysis target data storage unit 1 is unique among all records (step S53). If the field value of the processing target field is not unique among all records, that is, there is a record with a duplicate value, the process proceeds to step S62.

  Since the event ID is a storage field for an event identifier, the field values do not overlap each other. Therefore, if a duplicate value exists in the processing target field, it can be determined that it is not an event ID.

  On the other hand, if the field value of the processing target field is unique in all records, it is determined whether NULL is included in the field value of the processing target field stored in the analysis target data storage unit 1 (step S55). ). If NULL is included in the field value of the processing target field, the process proceeds to step S62. This is because the event ID is a storage field for an event identifier, and the field value cannot be NULL. When the field value of the processing target field is not unique among all records, or when the field value of the processing target field includes NULL, the field value of the processing target field stored in the analysis target data storage unit 1 is It is determined whether there are two or more except for NULL (step S62). If there are not two or more field values of the processing target field except NULL, “No” is set in the event ID / related ID candidate determination, and the result is stored in a storage device such as a main memory (step S63). Then, the process proceeds to step S61. Since the related ID is a value indicating to which of the other events a certain event corresponds, if the field value does not have two or more values except NULL, a meaningful result cannot be obtained. is there.

  For example, in the case of the tables shown in FIGS. 4B and 9B, there is no duplication in the field values for field 1, field 2 and field 4, and there is a duplication in the field values for field 3. However, since it takes two or more values other than NULL, “No” is not set in the event ID / related ID candidate determination.

  In the case of the table shown in FIG. 5B or FIG. 10B, field 1 and field 2 do not have duplicate field values, and fields 3 to 5 have duplicates, but other than NULL. Therefore, “No” is not set in the event ID / related ID candidate determination.

  Further, in the case of the table as shown in FIG. 6B or FIG. 11B, there is no duplication in the field values for the fields 1 and 2, and there are duplications for the fields 3 to 5, but other than NULL. Therefore, “No” is not set in the event ID / related ID candidate determination.

  Further, in the case of the tables as shown in FIG. 7B and FIG. 12B, field 1 and field 2 have no duplicate field values, and fields 3 and 4 have duplicates, but other than NULL. Therefore, “No” is not set in the event ID / related ID candidate determination.

  Further, in the case of the tables as shown in FIG. 8B and FIG. 13B, since there is no duplication in the field values for field 1 and field 2, “denial” is not set in the event ID / related ID candidate determination.

  When it is determined in step S55 that the field value of the processing target field does not include NULL, or when it is determined in step S62 that the field value of the processing target field has two or more types of values excluding NULL. Are the corresponding data portion of the processing target field in the schema information, the label data representing the field name of the processing target field, and the processing target field according to the event ID / related ID candidate probability score table stored in the score table storage unit 35 The accuracy is specified from the field value (step S57). However, when there is no corresponding item in the event ID / related ID candidate accuracy score table, the accuracy score 50 (%) is specified.

  An example of the event ID / related ID candidate accuracy score table is shown in FIG. In the example of FIG. 17, if the field data type is a variable-length character string, the accuracy score is set to 1 (%), and if the field data type is a real number, the accuracy score is set to 5 (%). If the data type of is an integer, the accuracy score is set to 80 (%). If the data type of the field is a fixed-length character string, the accuracy score is set to 70 (%). If it is a date, the accuracy score is set to 10 (%), and if the field name is designated as a primary key, the accuracy score is set to 80 (%). An item for a field value or field name string is not defined here, but may be defined. If an item for the field value is defined, it is referred to in step S57.

  For example, in the case of schema information as shown in FIG. 4A, the data type for field 1 is a time stamp, so the accuracy score is 10 (%), and the data type for field 2 is a fixed-length character string. And since the primary key is specified, an accuracy score of 80 (%) with a large deviation from 50% is adopted, and since the data type of field 3 is a fixed-length character string, it is specified as an accuracy score of 70 (%). For 4, the data type is a variable length character string, so the accuracy score is 1 (%). In the case where the schema information does not exist as shown in FIG. 9A, the accuracy score 50 (%) is specified for the field 1 to the field 4 because the corresponding item does not exist in the event ID / related ID candidate accuracy score table. The

  For example, in the case of schema information as shown in FIG. 5 (a), the data type for field 1 is a time stamp, so the accuracy score is 10 (%), and the data type for field 2 is a fixed-length character string. And since the primary key is specified, an accuracy score of 80 (%) with a large divergence from 50% is adopted, and for field 3 and field 4, the data type is a fixed-length character string, so an accuracy score of 70 (%) is specified. Since the data type of the field 5 is date, the accuracy score 10 (%) is specified. In the case where the schema information does not exist as shown in FIG. 10A, the accuracy score 50 (%) is specified for the fields 1 to 5 because there is no corresponding item in the event ID / related ID candidate accuracy score table. .

  For example, in the case of schema information as shown in FIG. 6A, since the data type for field 1 is a time stamp, the accuracy score is specified as 10 (%), and for field 2, the data type is a fixed-length character string. And since the primary key is specified, an accuracy score of 80 (%) with a large discrepancy from 50% is adopted, and for field 3 to field 5, the data type is a fixed-length character string, so an accuracy score of 70 (%) is specified. Is done. In the example in which schema information does not exist as shown in FIG. 11A, since there is no corresponding item in the event ID / related ID candidate accuracy score table for fields 1 to 5, an accuracy score of 50 (%) is specified. .

  For example, in the case of schema information as shown in FIG. 7A, since the data type for field 1 is a time stamp, the accuracy score is specified as 10 (%), and the data type for field 2 is a fixed-length character string. And since the primary key is specified, an accuracy score of 80 (%) with a large divergence from 50% is adopted, and for field 3 and field 4, the data type is a fixed-length character string, so an accuracy score of 70 (%) is specified. Is done. In the case where the schema information does not exist as shown in FIG. 12A, since there is no corresponding item in the event ID / related ID candidate accuracy score table for fields 1 to 4, an accuracy score of 50 (%) is specified. .

  For example, in the case of schema information as shown in FIG. 8A, since the data type of field 1 is a fixed-length character string and a primary key is designated, an accuracy score 80 (%) having a large deviation from 50% is obtained. For field 2, since the data type is a fixed-length character string, an accuracy score of 70 (%) is adopted. In the case where the schema information does not exist as shown in FIG. 13A, since there is no corresponding item in the event ID / related ID candidate accuracy score table for fields 1 and 2, an accuracy score of 50 (%) is specified. .

  Then, the event ID / related ID candidate processing unit 32 sets the accuracy score specified in step S57 for the event ID / related ID candidate determination, and stores it in a storage device such as a main memory (step S59).

  Thereafter, it is determined whether all fields in the processing target table have been processed (step S61). If there are unprocessed fields, the process returns to step S51. On the other hand, if all fields are processed, the process returns to the original process.

  In this way, a high accuracy score is specified for those having a high probability of event ID or related ID. In addition, data indicating the probability of “No” is specified for those having no possibility of event ID or related ID.

  Returning to the description of FIG. 3, next, the event name processing unit 34 of the event candidate data generation unit 3 performs an event name determination process (step S <b> 13). This event name determination process will be described with reference to FIGS.

  First, the event name processing unit 34 counts the number of fields that can be regarded as time stamp fields with a predetermined accuracy score or higher as the processing result of the time stamp determination processing (step S91). For example, a threshold value such as an accuracy score of 70 (%) or higher is set. Of course, the field identified as “determined” is a time stamp field. In the example described above, except for the product number DB, the field whose field name is date / time is determined to be a time stamp field, and the number of fields is “1”. In the product number DB, since there is no field that can be regarded as a time stamp, the number of fields is “0”.

  Then, it is determined whether or not the number of time stamp fields is 0 (step S93). If the number of fields is 0, the analysis target table is set to be excluded from the following processing (step S95). A table without a time stamp (for example, a product number DB) is determined not to be a table corresponding to an event that occurs during a business process. Then, the process returns to the original process.

  On the other hand, if the number of fields in the time stamp is not 0, it is determined whether or not the number of fields is 1 (step S97). If the number of fields in the time stamp is 1, a table name is set as the event name and stored in a storage device such as a main memory (step S99). In the above example, the event name is specified as “order received” in the case of the order DB, the event name is specified as “production” in the case of the production DB, and the event name is “arrangement” in the case of the arrangement DB. If it is specified and is a delivery DB, the event name is specified as “delivery”. Then, the process returns to the original process.

  When there are a plurality of time stamp fields, the field name of the field regarded as the time stamp is set as the event name and stored in a storage device such as a main memory (step S101). Then, the process returns to the original process.

  For example, when a table as shown in FIG. 19 is a processing target table, step S101 is executed. In the example of FIG. 19, the draft date / time, approval date / time, order date / time, delivery date / time, and inspection date / time are fields that are regarded as event time stamps, and a plurality of events are recorded in one record. Such a table can be handled as a plurality of tables such as a drafting table, an approval table, an ordering table, a delivery table, and an inspection table as shown in FIGS. Therefore, in such a case, “draft”, “approval”, “ordering”, “delivery”, and “acceptance” are specified as event names.

  By performing the processing as described above, it is possible to specify a table corresponding to an event that occurs during a business process and to extract an event name.

  Returning to the description of FIG. 3, the event candidate data generation unit 3 presents the determination result to the user via the input / output unit 11 (step S <b> 15). For example, in the case of an order entry DB in the relational database format as shown in FIGS. 4A and 4B, data as shown in FIG. 21 is presented to the user. In the example of FIG. 21, the determination results of steps S7 to S13 are presented for each of the date / time field, the order number field, the region field, and the order detail field. As for the event name, the table name is used as the event name, so that all of the event names are set to “deny”. From this, it can be seen that the date / time field is “fixed” in the time stamp field, and the order number field and the region field are highly likely to be event IDs or related IDs.

  In the case of the order DB in the CSV format shown in FIG. 9A, data as shown in FIG. 22 is presented to the user. In the example of FIG. 22, the determination results of steps S7 to S13 are presented for each of the date / time field, the order number field, the region field, and the order detail field. As for the event name, the table name is used as the event name, so that all of the event names are set to “deny”. From this, it can be seen that the date / time field is likely to be a time stamp, and the possibility of being an event ID or a related ID is the same for any field.

  For example, in the case of a production DB in the relational database format as shown in FIGS. 5A and 5B, data as shown in FIG. 23 is presented to the user. In the example of FIG. 23, the determination results of steps S7 to S13 are presented for each of the date / time field, production number field, order number field, product number field, and delivery date field. As for the event name, the table name is used as the event name, so that all of the event names are set to “deny”. From this, it can be seen that the date / time field is “fixed” in the time stamp field, and the production number field, the order number field, and the product number field are highly likely to be event IDs or related IDs.

  In the case of the production DB in the CSV format shown in FIG. 10A, data as shown in FIG. 24 is presented to the user. In the example of FIG. 24, the determination results of steps S7 to S13 are presented for each of the date / time field, production number field, order number field, product number field, and delivery date field. As for the event name, the table name is used as the event name, so that all of the event names are set to “deny”. From this, it can be seen that the date / time field is likely to be a time stamp, and the possibility of being an event ID or a related ID is the same for any field.

  For example, in the case of an arrangement DB in the relational database format as shown in FIGS. 6A and 6B, data as shown in FIG. 25 is presented to the user. In the example of FIG. 25, the determination results of steps S7 to S13 are presented for each of the date / time field, the arrangement number field, the order number field, the product number field, and the delivery destination field. As for the event name, the table name is used as the event name, so that all of the event names are set to “deny”. From this, it can be seen that the date / time field is “fixed” in the time stamp field, and the arrangement number field, the order number field, the product number field, and the delivery destination field are highly likely to be event IDs or related IDs.

  In addition, in the case of the CSV format arrangement DB shown in FIG. 11A, data as shown in FIG. 26 is presented to the user. In the example of FIG. 26, the determination results of steps S7 to S13 are presented for each of the date / time field, the arrangement number field, the order number field, the product number field, and the delivery destination field. As for the event name, the table name is used as the event name, so that all of the event names are set to “deny”. From this, it can be seen that the date / time field is likely to be a time stamp, and the possibility of being an event ID or a related ID is the same for any field.

  For example, in the case of a delivery DB in the relational database format as shown in FIGS. 7A and 7B, data as shown in FIG. 27 is presented to the user. In the example of FIG. 27, the determination results of steps S7 to S13 are presented for each of the date / time field, the arrangement number field, the delivery flight field, and the delivery destination field. As for the event name, the table name is used as the event name, so that all of the event names are set to “deny”. From this, it can be seen that the date / time field is “fixed” in the time stamp field, and the arrangement number field, the delivery flight field, and the delivery destination field are highly likely to be event IDs or related IDs.

  In the case of the CSV delivery DB shown in FIG. 12A, data as shown in FIG. 28 is presented to the user. In the example of FIG. 28, the determination results of steps S7 to S13 are presented for each of the date / time field, the arrangement number field, the delivery flight field, and the delivery destination field. As for the event name, the table name is used as the event name, so that all of the event names are set to “deny”. From this, it can be seen that the date / time field is likely to be a time stamp, and the possibility of being an event ID or a related ID is the same for any field.

  For example, in the case of a product number DB in the relational database format as shown in FIGS. 8A and 8B, data as shown in FIG. 29 is presented to the user. In the example of FIG. 29, the determination results of steps S7 to S13 are presented for each of the product number field and the product name field. Since the product number DB is determined not to have a time stamp and is not subject to subsequent processing, all event names are set to “No”. From this, it can be seen that the possibility of the presence of a time stamp field is very low, and the product number field and the product name field are highly likely to be event IDs or related IDs.

  Further, in the case of the product number DB in the CSV format shown in FIG. 13A, data as shown in FIG. 30 is presented to the user. In the example of FIG. 30, the determination results of steps S7 to S13 are presented for each of the product number field and the product name field. Since the product number DB is determined not to have a time stamp and is not subject to subsequent processing, all event names are set to “No”. From this, it can be seen that there is a very low possibility that the time stamp field exists, and that the possibility of the event ID or the related ID is the same for any field.

  Returning to the description of FIG. 3, when step S <b> 15 is completed, the user performs correction input or confirmation input for the event name, time stamp, event ID / related ID candidate, and the like via the input / output unit 11, and copies the record. The event candidate data is generated by performing or commanding, and the like, and is stored in the event candidate data storage unit 5 in the event candidate data generation unit 3 (step S16). Since this operation is mainly or partly performed by the user, it is drawn as a dotted block in FIG. Then, the process returns to step S3.

  For example, according to the determination result of FIG. 21, as shown in FIG. 31, the table name “order received” is confirmed for the event name, the date / time field is confirmed for the time stamp, and the order number field for the event ID / related ID candidate. When the area field is determined, for example, data as shown in FIG. 32 is stored in the event candidate data storage unit 5. In the example shown in FIG. 32, the event name “order received” is added to all records, all records of the field value in the date / time field are copied to the time stamp field, and the order number field and the region field are the event ID / related ID. As a candidate, all records of field name and field value are copied.

  For example, according to the determination result of FIG. 22, “order received” which is the table name for the event name is confirmed, the date / time field is confirmed for the time stamp, the order number field, the region field, and the order contents for the event ID / related ID candidate. When the field is determined, for example, data as shown in FIG. 33 is stored in the event candidate data storage unit 5.

  Further, for example, according to the determination result of FIG. 23, “production” which is the table name for the event name is confirmed, the date / time field is confirmed for the time stamp, the production number field, the order number field and the event ID / related ID candidate are When determining the product number field, for example, data as shown in FIG. 34 is stored in the event candidate data storage unit 5.

  Further, for example, according to the determination result of FIG. 24, “production” which is a table name for the event name is confirmed, the date / time field is confirmed for the time stamp, the production number field, the order number field for the event ID / related ID candidate, When the product number field and the delivery date field are determined, for example, data as shown in FIG. 35 is stored in the event candidate data storage unit 5.

  Further, for example, according to the determination result of FIG. 25, “arrangement” which is a table name for the event name is confirmed, the date / time field is confirmed for the time stamp, the arrangement number field, the order number field for the event ID / related ID candidate, When the product number field and the delivery destination field are determined, for example, data as shown in FIG. 36 is stored in the event candidate data storage unit 5.

  Further, for example, according to the determination result of FIG. 26, “arrangement” which is a table name for the event name is confirmed, the date / time field is confirmed for the time stamp, the arrangement number field, the order number field for the event ID / related ID candidate, When the product number field and the delivery destination field are determined, for example, data as shown in FIG. 37 is stored in the event candidate data storage unit 5.

  Further, for example, according to the determination result of FIG. 27, “delivery” which is the table name for the event name is confirmed, the date / time field is confirmed for the time stamp, the arrangement number field, the delivery flight field and the event ID / related ID candidate are confirmed. When the delivery destination field is determined, for example, data as shown in FIG. 38 is stored in the event candidate data storage unit 5.

  Also, for example, according to the determination result of FIG. 28, “delivery” which is a table name for the event name is confirmed, the date / time field is confirmed for the time stamp, the arrangement number field, the delivery flight field and the event ID / related ID candidate are confirmed. When finalizing the delivery destination field, for example, data as shown in FIG. 39 is stored in the event candidate data storage unit 5.

  For example, when processing a table having a plurality of time stamp fields in the table as shown in FIG. 19, for example, data as shown in FIGS. 40 to 44 is the event candidate data storage unit 5. Stored in In the examples shown in FIGS. 40 to 44, the event name is set to “start” for each field based on the draft date / time, the approval date / time, the order date / time, the delivery date / time, and the inspection date / time, which are determined as time stamps. Create event candidate data that is confirmed as “voting”, “approval”, “ordering”, “delivery”, and “acceptance”. As for the time stamp, all records of the field values of the draft date / time field, the approval date / time field, the order date / time field, the delivery date / time field, and the inspection date / time field are copied to the time stamp field of each event candidate data. In addition, common to all event candidate data, fields other than the draft date / time field, approval date / time field, order date / time field, delivery date / time field, and inspection date / time field, as field ID / related ID candidates, All records are copied.

  In this way, event candidate data used in the following processing is stored in the event candidate data storage unit 5.

  Returning to the explanation of FIG. 3, when it is determined that all the analysis target tables have been processed in step S <b> 3, the event data generation unit 7 uses the event candidate data stored in the event candidate data storage unit 5. Event data generation processing is performed, and the processing result is stored in the event data storage unit 9 (step S17).

  Corresponding to the order event, production event, arrangement event, and delivery event, the set of event candidate data shown in FIG. 32, FIG. 34, FIG. 36, and FIG. 38, respectively, or FIG. 33, FIG. FIG. 45 shows an example of event data generated using the set of event candidate data shown in FIG. 37 and FIG. As a generation method thereof, an automatic extraction method of related information of event data as described in JP 2008-27072 A described above may be used, or an event ID / related ID of each event candidate data manually. The relationship between events may be determined by investigating and analyzing the correspondence between candidate field values.

  In FIG. 45, the event ID of the order event is the order number, the event ID of the production event is the production number, the related ID is the order number, the event ID of the order event is the order number, the related ID is the order number, and the delivery It is confirmed that the event ID of the event is an arrangement number and the related ID is a delivery flight. In addition, when the field value of the related ID of the production event takes any one of the field values of the event ID of the order receiving event, each record of the production event (that is, the event instance) is changed to which record ( That is, the relevance between events is determined so that it is specified whether it is related to the event instance). Similar relevance is determined between the event ID of the arrangement event and the event ID of the order event, and between the event ID of the delivery event and the event ID of the arrangement event.

  Further, the process instance generation unit 13 performs a process instance generation process using the event data stored in the event data storage unit 9, and stores the processing result in the process instance data storage unit 15 (step S19). As the generation method, a business process tracking method such as US Patent Publication No. 2005 / 076059A1 can be used.

  FIG. 46 shows a schematic explanation of a process for generating a process instance starting from an order event instance of the order number: JT01, using the event data of FIG. First, as a record (that is, an event instance) in which the field value of the related ID is the event ID of the order receiving event, which is the event ID of the order receiving event, two event instances from the production event and three event instances from the arrangement event are determined. Is done. Next, three event instances are confirmed from the delivery event as records (that is, event instances) that take the arrangement numbers: TH01, TH02, and TH03, which are event IDs of the confirmed arrangement events, as field values of related IDs. Finally, the process is performed by connecting event instances that are directly or indirectly related to each other in the order of time based on the value of the time stamp, starting from the confirmed order number: JT01 order event instance. An instance is created. That is, as the first process instance, a process instance is generated in which event instances whose event class is order, production, arrangement, arrangement, arrangement, delivery, production, delivery, and delivery are arranged in time series.

  Similarly, all process instances generated using the event data of FIG. 45 are shown in FIG. The second process instance is a process instance in which event instances whose event classes are order receipt, arrangement, and delivery are arranged in time series. The third process instance is a process instance in which event instances whose order is an order, production, production, arrangement, and delivery are arranged in time series. Furthermore, the fourth process instance is a process instance in which event instances whose event classes are order receipt, arrangement, and delivery are arranged in time series.

  Returning to the description of the processing flow of FIG. 3, the parallel processing estimation unit 17 performs parallel processing estimation processing using the process instance data stored in the process instance data storage unit 15 (step S <b> 21). ). This process will be described in detail with reference to FIGS.

  First, the purpose of executing the parallel processing estimation process will be described with reference to FIGS. 48 to 56-2. First, as shown in FIG. 48, it is assumed that 10 process instances are stored in the process instance data storage unit 15. The process instances are classified and grouped on the basis of the arrangement of event classes to which the event instances constituting the process instances belong, and are arranged in the descending order of the number of member process instances as follows. Such processing is performed by the process instance classification processing unit 21. First, a group A is composed of five process instances whose event classes are arranged in the initial state, contract, slip creation, billing, collection, contract expiration, and final state. Group B is composed of three process instances where initial state, contract, slip creation, billing and collection are returned to contract creation via contract renewal after billing and collection, and contract expiration and final state occur. Is done. Further, after initial state, contract, voucher creation, billing and collection, return to billing through continuation, and group C is configured with one process instance in which collection, contract expiration, and final state occur. Then, after initial state, contract, voucher creation, billing, collection and collection are repeated, group D is configured with one process instance in which contract expiration and final state occur. However, Initial State and Final State are virtual event classes attached to the beginning and end of each process instance.

  When such process instance groups of groups A to D are superimposed and displayed by the process display processing unit 25, an overall flow as shown in FIG. 49 is displayed. In this display, only one ellipse indicating each event class is displayed, and only one arrow indicating the same transition between event classes is provided to avoid complication.

  Further, for example, when dividing the main flow and the exceptional flow by using a ratio of 20% of the total appearance frequency of the group as a threshold value, as shown in FIG. A flow in which process instances of group B are superimposed is generated and presented to the user. In this display, there is only one arrow indicating the same transition between event classes to avoid complication. On the other hand, in the exception flow, the process instance of group C shown in FIG. 50B and the process instance of group D shown in FIG. 50C are presented to the user.

  In the case of the process instance shown in FIG. 48, there is not much problem in separating the main flow and the exception flow, and the user can easily grasp the overview of the business flow with the diagrams as shown in FIG. 49 and FIG. become able to. Since group A alone has an appearance frequency of 50%, even if only group A is recognized as the main flow, there is no particular problem in grasping the general situation of the business flow as in FIG.

  On the other hand, as shown in FIG. 56, when the processing from steps S1 to S19 is performed on data obtained from a system having a business flow (FIG. 54) in which a part of parallel processing exists in actual business, As shown in 51, a process instance including an apparent transition that does not exist in the actual business as a component is generated. The reason is that events having relevance to each other's ID are simply connected in time series, so in the business flow including the parallel processing of FIG. 54, the apparent transition between the events in the partial flows that are in parallel with each other This is because of erroneous setting.

  The business flow including the parallel processing shown in FIG. 54 includes a partial flow in which event classes such as initial state and contract are arranged, followed by a partial flow in which event classes of slip creation, billing, and collection are arranged, and continuation and contract update. The partial flows in which the event classes are arranged continue in a parallel relationship with each other, and then the contract expires and merges into the partial flow in which the event classes called Final State are arranged. If it is known that the analysis target business system / work flow includes such partial flows that are in parallel with each other, data pre-processing that reflects those parallel relationships, for example, in parallel with each other It is necessary to perform processing for deleting event class data constituting other partial flows while leaving only one of the partial flows.

  However, there is not enough information about the existence of parallel processing in the business system / workflow to be analyzed and what kind of parallel processing exists, and data pre-processing cannot be performed, so steps S1 to S19 are not performed. There are cases where processing is unavoidable. In that case, a process instance as shown in FIG. 51 is generated. Specifically, there are four basic process instances that are lined up with event instances belonging to the event classes of Initial State, Contract, Voucher Creation, Billing, Collection, Contract Expiry, and Final State. is doing. On the other hand, as described above, the event of the component of the partial flow in which the event classes such as slip creation, billing, and collection are arranged in parallel with each other and the partial flow in which the event classes of continuation and contract renewal are arranged in parallel A group composed of one process instance such as A to E in which an apparent transition that is not related to the actual business flow is set between the instances is obtained. Group A includes process instances in which event instances belonging to the event class of Initial State, contract, “slip creation, continuation, billing, contract renewal, collection”, contract expiration, and final state are arranged. Group B includes process instances in which event instances belonging to event classes of Initial State, contract, slip creation, “billing, continuation, collection, contract renewal”, contract expiration, and final state are arranged. Further, the group C includes process instances in which event instances belonging to event classes of Initial State, contract, slip creation, billing, “collection, continuation”, contract renewal, contract expiration, and final state are arranged. Further, the group D includes process instances in which event instances belonging to event classes of Initial State, Contract, Continuation, “Contract Renewal, Form Creation”, Billing, Collection, Contract Expiration, and Final State are arranged. Further, the group E includes process instances in which event instances belonging to event classes of Initial State, Contract, “Continuation, Form Creation, Contract Renewal, Billing”, Collection, Contract Expiry, and Final State are arranged. Thus, the transition between the event instances indicated by “” is apparently a transition. FIG. 73 shows these apparent transitions indicated by dotted lines. In FIG. 51, apart from groups A to E, there is one process instance in which event instances belonging to the event classes Initial State, contract, slip creation, billing, billing, collection, contract expiration, and final state are arranged. There is also a group G that contains it. In group G, event instances belonging to the event class of billing are repeated.

  When all such process instances are simply overlapped, a business flow as shown in FIG. 52 is obtained. As can be seen from FIG. 52, it is too complicated to grasp the entire business flow. Similarly to the above description, when the main flow and the exceptional flow are separated by the threshold of 20%, the result is as shown in FIG. That is, the group F is determined to be the main flow in 40% of the total, but the groups A to E and G are all determined to be exception flows because they are 10%. However, in fact, groups A to E are processes in which transitions appear as components because event instances generated from a business flow including parallel processing as shown in FIG. 54 are simply connected in the order of date and time. It was created as an instance. In other words, the process instance that should be generated is the main route in which event instances are generated in the order of contract, slip creation, billing, collection, contract expiration, branch from contract, continuation and contract renewal, and transition to contract expiration A process instance including a parallel path.

  When the groups A to E are modified to process instances including the original parallel path as shown in FIG. 54-2, these (group AE) occupy 50% of the whole as shown in FIG. These become the first main flow, and Group F becomes the second main flow. Therefore, the exception flow is only group G. Even if all process instances are overlapped, as shown in FIG. 56-2, it is possible to present to the user a business flow that is much more organized than FIG. 52 and is easy to grasp.

  Therefore, by performing the processing as shown in FIGS. 57 to 74, the process instances generated by the conventional technology are apparently transitions that are unlikely to cause transitions in actual business. By detecting and estimating the existence of parallel processing in the business flow, the user can grasp the outline of the original business flow.

  The statistical information extraction unit 171 of the parallel processing estimation unit 17 generates an inter-event transition frequency table from the process instances stored in the process instance data storage unit 15 and stores it in the statistical information storage unit 173 (FIG. 57: Step S111). ). Occurrence of transition between events for the combination of the corresponding originating event instance and the corresponding terminating event instance in the process instance stored in the process instance data storage unit 15 for each combination of the originating event class and the terminating event class Count the frequency and register it in the inter-event transition frequency table. As schematically shown in FIG. 58, for example, when attention is paid to the combination of “billing” as the originating event class and “collection” as the terminating event class, the portions surrounded by dotted lines are counted. That is, since the process instances C, D, E, and G are counted once and the process instance F is counted four times, the total is eight times. Therefore, as shown in the lower table of FIG. 58, “8” is registered in the corresponding cell of the originating event class “billing” and the terminating event class “collected”. If such processing is performed for all event class combinations, an inter-event transition frequency table as shown in FIG. 59 is generated. In the example of FIG. 59, the arrival event classes are listed in the horizontal direction, and the calling event classes are listed in the vertical direction. However, Initial State and Final State are virtual event classes attached to the beginning and end of each process instance, and there are no transitions between events that arrive at Initial State and transitions between events that start from Final State. "-" Is described in the cell corresponding to them.

  Next, the statistical information extraction unit 171 calculates an approximate value of the occurrence probability and conditional probability of each event from the inter-event transition frequency table stored in the statistical information storage unit 173, and stores it in the statistical information storage unit 173. (Step S113). In this step, as shown in FIG. 60, each originating event X is fixed and the sum of the inter-event transition frequencies F (Y | X) is obtained for each event class X by combining all the incoming events. The occurrence frequency T (X) of the event instance to which it belongs is calculated. Hereinafter, in order to avoid complicated description, the occurrence frequency of event instances belonging to each event class X is abbreviated as the occurrence frequency of each event X. In the case of a state transition frequency table having an initial state and a final state, which are virtual event classes attached to the beginning and end of each process instance handled in this embodiment, the event Y on the called side is fixed. Then, by calculating the sum of the frequencies F (Y | X) for the combinations with all the originating events, the same value can be obtained even if the occurrence frequency T (Y) of each event Y is calculated. Next, the sum GT of the occurrence frequencies of all events is calculated. Further, the occurrence frequency T (X) of each event X may be obtained by directly counting the number of event instances included in all process instances and belonging to the event class X. Next, the total event occurrence frequency GT is calculated by calculating the sum of T (X) for all event classes. Note that the total event occurrence number GT is obtained by directly counting the number of event instances included in all process instances and belonging to event classes other than the virtual event classes Initial State and Final State. Also good.

  Then, as shown in FIG. 61, the approximate value of the occurrence probability of the event instance belonging to each event class X is calculated as P (X) ≈T (X) / GT, and stored in the statistical information storage unit 173. Hereinafter, the occurrence probability of an event instance belonging to each event class X is abbreviated as the occurrence probability of each event X in order to avoid complicated description. Similarly, as shown in FIG. 62, when the originating event X occurs, the approximate value of the conditional probability P (Y | X) that the terminating event Y occurs is represented by P (Y | X) ≈F ( Y | X) / T (X) is calculated and stored in the statistical information storage unit 173. Hereinafter, in order to avoid complicated description, the conditional probability that the arrival side event Y occurs when the originating event X occurs is abbreviated as the conditional probability as appropriate when it is not ambiguous.

  When the approximate value of the event occurrence probability P (X) is calculated based on the example of FIG. 59, data as shown in FIG. 63 is stored in the statistical information storage unit 173. Similarly, when the approximate value of the conditional probability P (Y | X) is calculated based on the example of FIG. 59, data as shown in FIG. 64 is stored in the statistical information storage unit 173.

  Next, the statistical information extraction unit 171 calculates an apparent evaluation index value for each transition based on the occurrence probability and conditional probability of each event stored in the statistical information storage unit 173, and the statistical information storage unit It stores in 173 (step S115). As described above, an apparent transition is a process in which the processing from steps S1 to S19 is mechanically applied to data obtained from a business system, and an event ID is shared or a corresponding relationship is obtained via a related ID. This is a transition that constitutes a process instance created by simply connecting event instances (records) in series based on the date and time of occurrence, but does not exist in actual business.

  The apparent transition detection evaluation index value is defined using the following statistical properties. First, the conditional probability P (B | A) that event B occurs when event A occurs is equal to the probability P (A∩B) that event A occurs and event B occurs, etc. It is defined as satisfying the expression P (A∩B) = P (B | A) P (A). On the other hand, as shown in FIG. 65, when event A and event B occur independently, there is no overlapping portion between event A and event B. That is, the necessary and sufficient condition that event A and event B are independent events is that the probability P (A∩B) that A and B occur simultaneously is the probability P (A) and event B that event A occurs. P (A∩B) = P (A) P (B) holds for the probability P (B) to be performed. Therefore, when event A and event B occur independently, for conditional probability P (B | A) that event B occurs when event A occurs, P (B | A) = P ( B) is derived. Similarly, P (A | B) = P (A) is derived for the conditional probability P (A | B) at which event A occurs when event B occurs.

  When a process instance includes a main route and a branched parallel route, that is, a process instance generated from a business flow including parallel processing, an event instance of an event class in the main route and an event in the parallel route Since the event instances of the class are irrelevant in business, they can be considered to occur independently. Therefore, the conditional probability P of the apparent transition (apparent transition arrival event | apparent transition originating event) and the occurrence probability P of the event instance belonging to the event class of the apparent transition arrival event (apparent) P (apparent transition arrival event) = ap (apparent transition arrival event) = P (apparent transition arrival event) is established.

  That is, | 1-P (apparent transition arrival event | apparent transition originating event) / P (apparent transition arrival event) | = 0 is derived. Therefore, as an evaluation index expression for the apparent transition in the present embodiment, | 1-P (the determination side transition arrival event | the determination target transition arrival event) / P (the determination target transition arrival event) | Is adopted. Further, for example, “1” is adopted as the threshold value. However, an optimum value may be obtained experimentally and used. Further, other evaluation formulas defined according to the same purpose may be adopted.

  When apparent transition evaluation index values are calculated from FIGS. 63 and 64, values as shown in FIG. 66 are obtained. When the originating event is the same as the terminating event, it indicates a return and is not related to the parallel processing, so that the evaluation index value is not calculated as indicated by “−”. Then, the transition corresponding to the hatched cell has an evaluation index value less than “1”. That is, transition from slip creation to contract renewal, transition from slip creation to continuation, transition from billing to contract renewal, transition from billing to continuation, transition from collection to contract renewal, transition from collection to continuation, contract Transition from renewal to slip creation, transition from contract renewal to billing, transition from contract renewal to collection, transition from continuation to slip creation, transition from continuation to billing, and transition from continuation to collection Is less than the threshold.

  Returning to the description of the processing in FIG. 57, the apparent transition detection unit 175 apparently transitions (specifically, the originating event class) in which the evaluation index value stored in the statistical information storage unit 173 is less than or equal to the threshold value. And a pair of arrival event classes), and output to the apparent transition deletion unit 177 and the alternative transition determination processing unit 179 (step S117). The processing shifts to the processing in FIG.

  Shifting to the description of the processing in FIG. 67, the apparent transition deletion unit 177 identifies one unprocessed process instance in the process instance data storage unit 15 (step S <b> 119). Then, the apparent transition deletion unit 177 identifies one unprocessed transition among the apparent transitions received from the apparent transition detection unit 175 (step S121). Then, the apparent transition deletion unit 177 confirms whether the specified process instance includes the specified apparent transition (step S123). When the evaluation index values as shown in FIG. 66 are calculated, since 12 types of transitions with hatching are detected as apparent transitions, process instances including any one of the apparent transitions are extracted. To do. If the identified process instance does not include the identified apparent transition, the apparent transition deletion unit 177 determines whether all apparent transitions have been processed (step S125). If an unprocessed apparent transition exists, the process returns to step S121.

  On the other hand, when all the apparent transitions are processed, but no apparent transition is detected in the specified process instance, the apparent transition deletion unit 177 estimates the data of the specified process instance in parallel processing. The data is stored in the post-process instance data storage unit 19 (step S127). Then, control goes to a step S135. Process instances that are apparently not including transitions, that is, that are determined not to include parallel processing, are stored in the post-parallel processing estimation process instance storage unit 19 for processing subsequent to step S23.

  On the other hand, when the identified apparent transition is included in the identified process instance, the apparent transition deletion unit 177 converts the data of the identified process instance into parallel process corresponding process instance data. The data is stored in the storage unit 181 (step S129). Then, the apparent transition deletion unit 177 deletes the specified apparent transition in the specified process instance (step S131). For example, when the process instance A of FIG. 51 is specified in step S119, a transition corresponding to the transition detected as an apparent transition in the process instance A (transition from slip creation to continuation, transition from continuation to billing) , Transition from billing to contract renewal, contract renewal to collection transition) is deleted in step S131. In FIG. 68, all apparent transitions have already been deleted. For example, a pointer indicating a connection from a data block corresponding to slip creation to a data block corresponding to continuation is deleted.

  Furthermore, the apparent transition deletion unit 177 determines whether or not the remaining apparent transition is included in the specified process instance, and if it is included, deletes the corresponding transition (step S133). For example, it is determined whether each unprocessed apparent transition that has not yet been specified in step S121 is included in the specified process instance. If included, all the corresponding transitions are deleted. In the case of process instance A, as shown in FIG. 68, the pointer for the transition marked with a cross is deleted. Thereafter, the process proceeds to step S135.

  In step S135, the apparent transition deletion unit 177 determines whether all process instances in the process instance data storage unit 15 have been processed. If there is an unprocessed process instance, the process returns to step S119. On the other hand, when all process instances have been processed, the processing shifts to the processing in FIG.

  Moving to the description of the processing in FIG. 69, the alternative transition determination processing unit 179 specifies one unprocessed extraction process instance in the parallel processing corresponding process instance data storage unit 181 (step S137). Then, the alternative transition determination processing unit 179 identifies one unprocessed event instance among the event instances that are not connected at least one end in the identified extraction process instance (step S139). In the example of FIG. 68, for example, continuation is specified.

  Then, the alternative transition determination processing unit 179 determines whether the front (before time) of the identified event instance is unconnected (step S141). If the front of the identified event instance is connected, the process proceeds to step S157. On the other hand, if the front of the identified event instance is not connected, the alternative transition determination processing unit 179 initializes a pointer n for searching for a connection destination to 2 (step S145). Since n = 1 is a transition deleted in the process of FIG. 67, the process starts from n = 2. Then, the alternative transition determination processing unit 179 determines whether there is an nth previous event (step S147). If there is no event before n, it means that there is no event instance that can be connected forward for the specified event instance, so the alternative transition determination processing unit 179 sets the transition from “Initial State” to this event instance. (Step S155). Since “Initial State” is a virtual event, as shown in FIG. 68, the data itself may not be held. In the case of holding, the address of the data block for this event instance is added to the pointer indicating the transition destination in the data block of “Initial State”. On the other hand, if the data is not held as shown in FIG. 68, data representing “Initial State” is added to the data block for this event instance as data representing the transition source. The process proceeds to step S157.

  On the other hand, when n event instances exist, the alternative transition determination processing unit 179 confirms whether the transition from the n event instances to the identified event instance is an apparent transition. (Step S149). In the case of process instance A, if the identified event instance is “continuation”, the event instance two events before is an event instance of the event class “contract”, and thus it does not appear to be a transition. When the transition from the n-th previous event instance to the event instance related to the process does not seem to correspond to the transition, the alternative transition determination processing unit 179 performs the transition from the n-th previous event instance to the event instance related to the process. Set (step S153). In the case of “continuation” in FIG. 68, a pointer to the data block for “continuation” is added to the data block for “contract” as schematically shown in FIG. The process proceeds to step S157.

  On the other hand, as shown in FIG. 71, when processing an event instance of the event class “continuation” of the process instance B, the event instance two events before is an event instance of the event class “slip creation”, The transition from “Create” to “Continue” appears to be a transition and cannot be selected.

  In other words, if the transition from the n-th previous event instance to the event instance related to the process apparently corresponds to the transition, the alternative transition determination processing unit 179 increments n by 1 (step S151), and proceeds to step S147. Return.

  In the example of FIG. 71, the event instance three events before is an event instance of the event class “contract”, and the transition from “contract” to “continue” does not seem to correspond to the transition, so Add a pointer to the data block for “continue” to the data block.

  In step S157, the alternative transition determination processing unit 179 determines whether the back (temporally behind) the identified event instance is unconnected. If the transition has already been confirmed, the process proceeds to step S171 in FIG. On the other hand, if the back of the identified event instance is not connected, the process proceeds to step S159 in FIG.

  Shifting to the description of the processing in FIG. 72, the alternative transition determination processing unit 179 initializes n to 2 (step S159), and determines whether there is an nth event instance in the identified extraction process instance. (Step S161). If there is no event after n, it means that there is no event instance that can be connected backward for the specified event instance, so the alternative transition determination processing unit 179 sets the transition from this event instance to “Final State”. (Step S163). Since “Final State” is a virtual event, as shown in FIG. 68, the data itself may not be held. In the case of holding, the address of the data block for “Final State” is added to the data block for this event instance as a pointer representing the transition destination. On the other hand, if not held as shown in FIG. 68, data representing “Final State” is added to the data block for this event instance as data representing the transition destination. The process proceeds to step S171.

  On the other hand, if n event instances exist, the alternative transition determination processing unit 179 confirms whether the transition from the identified event instance to the n event instances is an apparent transition ( Step S165). In the process instances A and B, if the identified event instance is “continuation”, the event instance after the second event is an event instance of the event class “contract update”, so that it does not seem to be a transition. When the transition from the identified process instance to the nth event instance does not seem to correspond to the transition, the alternative transition determination processing unit 179 performs the transition from the identified process instance to the nth event instance. Setting is made (step S169). In the case of “continuation” in FIG. 70 and FIG. 71, a pointer to the data block for “contract update” is added to the data block for “continuation”. The process proceeds to step S171.

  On the other hand, when the transition from the identified event instance to the nth event instance apparently corresponds to a transition, the alternative transition determination processing unit 179 increments n by 1 (step S167), and proceeds to step S161. Return.

  In step S171, the alternative transition determination processing unit 179 determines whether all event instances that are unconnected at least one end have been processed. If there is an unprocessed event instance, the process returns to step S139 in FIG. On the other hand, if all event instances that are not connected at least one end have been processed, it is determined whether all extracted process instances stored in the parallel process relevant process instance data storage unit 181 have been processed (step S173). ). If there is an unprocessed extraction process instance, the process returns to step S137 of FIG. When all the extracted process instances have been processed, the alternative transition determination processing unit 179 converts the process instance data stored in the parallel process relevant process instance data storage unit 181 into the process instance data storage unit 19 after the parallel processing estimation. (Step S175).

  When such processing is performed, the process instances A to E are disconnected for the transition that is statistically determined to be an apparent transition instead of the original transition, as indicated by a dotted line in FIG. For the event instances at both ends of the transition, the event instances that occur closest in time on the disconnected side and whose transition to the event instance does not appear to be a transition are searched When a transition between the event instance and the found event instance is set as a new transition, process instances A to E as shown in FIG. 74 are obtained.

  The newly generated transition is difficult to understand because it is indicated by an arrow deviating from the event instance column, but in the end, the process instances A to E are the business parallel processing shown in FIG. It has the same form as the business flow including

  In the above explanation, an example of automatically performing deletion of apparent transition and setting of alternative transition has been shown. For example, the corresponding process instance and apparent transition are presented to the input / output unit 11. The user may be confirmed whether or not the apparent transition may be deleted. In this case, if deletion is instructed, it is deleted accordingly. Further, the alternative transition may be set after confirmation from the user. That is, the alternative transition may be specified and presented by the above-described processing, or may be input by the user without being presented at all.

  Returning to the description of FIG. 3, the process instance classification processing unit 21 classifies the process instances stored in the process instance data storage unit 19 after the parallel processing estimation, and counts each type based on the classification result. The count value is stored in the model data storage unit 23 (step S23). When a process instance as shown in FIG. 55 is generated, data shown in FIG. 75 is stored in the model data storage unit 23 when step S23 is performed. In the example of FIG. 75, the process instances of the three groups described above and their respective count values are registered. Note that nothing is registered in the main flow flag column at this stage.

  And the process display process part 25 implements a flow display process using the data stored in the model data storage part 23 (step S25). The flow display process will be described with reference to FIGS.

  First, the process display processing unit 25 arranges the process instance groups stored in the model data storage unit 23 in descending order based on the count value (step S141). When the user inputs a threshold value for the ratio of the entire process instances of the group, which is a criterion for handling each process group as a main flow, there is no user input according to the input value. In that case, it is determined by a preset value (step S143). For example, when a group having a threshold value of 20% or more of the total is classified as a main flow, 20% is input. However, a preset value (for example, 30%) may be used as it is.

  Then, the process display processing unit 25 selects one unselected process instance from the upper count value (step S147). The selected process instance is designated as a main flow (also called a typical flow) (step S149). Specifically, the main flow flag in the table of the model data storage unit 23 is set to ON. Then, the ratio to the whole is calculated (step S151), and it is determined whether or not ratio ≧ threshold (step S153). If this condition is satisfied, the process returns to step S147.

  For example, in the example of FIG. 75, when the first record is selected first, the ratio to the whole is 50%. If the threshold is 20%, the process returns to step S147. Next, when the second record is selected, the ratio to the entire record is 40%, and the process returns to step S147. In this way, the main flow flag is set on for the first record and the second record.

  Finally, when the third record is selected, the ratio to the whole is 10%, and the condition that the ratio to the whole is equal to or greater than the threshold value is not satisfied, so the process display processing unit 25 returns to the original process. In this way, process instances other than the group of process instances selected in step S147 are identified as exceptional flows because the main flow flag is not set on.

  Returning to the description of FIG. 3, the process display processing unit 25 outputs the processing result via the input / output unit 11 using the data stored in the model data storage unit 23 (step S27). For example, when all process instances are displayed in a superimposed manner, a business flow as shown in FIG. 56-2 is displayed. In this display, only one ellipse indicating each event class is displayed, and only one arrow indicating the same transition between event classes is provided to avoid complication. FIG. 56-2 is the same as the business flow including the parallel processing of the data generation source, and shows that the original business flow can be restored from the system data.

  When the main flow flag data stored in the model data storage unit 23 is used to separately display the main flow and the exception flow, the display as shown in FIG. 77 is performed. For example, assuming that 80% is a classification ratio, the process instances of the first and second records are overlapped in the table shown in FIG. 75, and the business flow as shown in the first line of FIG. 77 is displayed as the main flow. . In the main flow display, there is only one arrow indicating the same transition between event classes in order to avoid complexity. In the table shown in FIG. 75, the third process instance is displayed as the exception flow on the second line in FIG.

  Although the embodiment of the present technology has been described above, the present technology is not limited to this. For example, the functional block diagrams shown in FIGS. 1A and 1B are examples and do not necessarily correspond to actual program modules.

  Each score table is also an example, and the method of setting the accuracy score value may be determined more finely empirically. Furthermore, as for the items in the score table, there may be a case where fewer items are set or a case where more items are set.

  Further, in the processing flow of FIG. 3, the order of steps S7 to S13 can be changed and may be performed in parallel.

  In addition, in the output of the determination result, a field that has a “determined” determination or an accuracy score equal to or greater than a predetermined threshold is automatically selected and presented to the user for each determination item, and a determination item that cannot be automatically selected is selected by the user. Or you may make it prompt an input.

  Furthermore, although the loop for the processing target field is configured in each of steps S7 to S13, a loop for the processing target field may be provided outside steps S7 to S13.

  The business system analyzer is a computer device, and as shown in FIG. 78, a memory 2501, a CPU 2503, a hard disk drive (HDD) 2505, a display controller 2507 connected to the display device 2509, and a removable disk 2511. Drive device 2513, input device 2515, and communication control unit 2517 for connecting to a network are connected by a bus 2519. An operating system (OS) and an application program for executing the processing in this embodiment are stored in the HDD 2505, and are read from the HDD 2505 to the memory 2501 when executed by the CPU 2503. If necessary, the CPU 2503 controls the display control unit 2507, the communication control unit 2517, and the drive device 2513 to perform necessary operations. Further, data in the middle of processing is stored in the memory 2501 and stored in the HDD 2505 if necessary. In the embodiment of the present invention, an application program for executing the processing described above is stored and distributed in the removable disk 2511 and installed from the drive device 2513 to the HDD 2505. In some cases, the HDD 2505 may be installed via a network such as the Internet and the communication control unit 2517. Such a computer device realizes various functions as described above by organically cooperating the hardware such as the CPU 2503 and the memory 2501 described above with the OS and necessary application programs.

  The present embodiment can be summarized as follows.

  In this business flow data processing method, (A) process instance data created by arranging in a time series event instances belonging to any of the event classes of a plurality of business events executed during business processing related to a specific matter. The occurrence frequency of transitions from the event class to the destination event class from the transitions between the event instances included in each process instance stored in the stored process instance data storage unit is counted as the transition frequency between events. By dividing the frequency of occurrence of transition between events stored in the statistical information storage unit by the frequency of occurrence of event instances belonging to the corresponding originating event class, Event instances belonging to the originating event class In addition to calculating the conditional probability that an event instance belonging to the destination event class will occur if it occurs, the frequency of event instances belonging to each event class is divided by the sum of the occurrence frequency of event instances belonging to all event classes. To calculate the occurrence probability of the event instance belonging to each event class and store it in the statistical information storage unit, and (C) the event class of a plurality of business events executed during the business processing related to a specific matter Transition between events in a process instance created by arranging event instances belonging to one of them in chronological order, and there is no causal relationship between the tasks corresponding to the originating event and the terminating event of the transition between the events. That are being implemented in parallel This is an evaluation expression for detecting the event, and when an event instance belonging to the originating event class of the transition to be judged occurs, there is a condition that an event instance belonging to the destination event class of the transition to be judged occurs The evaluation formula value defined using the probability and the occurrence probability of the event instance belonging to the event class on the arrival side of the transition to be judged is the value related to each event transition frequency stored in the statistical information storage unit. A step of calculating the transition and storing it in the statistical information storage unit; and (D) a value of the evaluation formula stored in the statistical information storage unit that is less than a predetermined threshold among the evaluation formula values of each transition. And apparently detecting such a transition as a transition.

  According to the conventional method, event instances are simply connected in chronological order according to the date and time of occurrence, and process instances are generated, so a business process including a main route and a parallel route branched from the main route Problems arise when implemented. That is, the business flow is not handled between events in the partial flows that are in parallel with each other, and the apparent transition is erroneously set, so that the user cannot properly grasp the business flow. By performing the processing as described above, it becomes possible to statistically detect an apparent transition between an event instance belonging to the parallel route and an event instance belonging to the main route, For example, the acceptance / rejection can be determined with the user's confirmation.

  In addition, this method determines whether each process instance stored in the process instance data storage unit includes a transition corresponding to the specified apparent transition, and if so, deletes the transition corresponding to the apparent transition. Then, it may further include a step of storing the data of the process instance after apparently deleting the transition in the data storage unit. In this way, it is possible to eliminate a transition that is automatically estimated not to occur in actual work.

  In addition, this method has the closest occurrence date and time for each unconnected event instance included in each process instance after the apparent transition deletion stored in the data storage unit instead of the apparent transition deleted. Further, it may further include a step of detecting an event instance that does not seem to correspond to the transition in the same process instance, and setting an alternative transition with the detected event instance. If the alternative transition is automatically determined in this way, the burden on the user can be reduced. However, after the alternative transition is determined in this way, it may be further automatically or manually corrected.

  In addition, when the above-described evaluation formula generates an event instance that belongs to the transition-side event class of the transition to be judged, a conditional probability that an event instance that belongs to the destination-side event class of the transition to be judged will occur May be an expression that calculates the absolute value of the difference between 1 and the value obtained by dividing the occurrence of the event instance belonging to the event class on the arrival side of the transition to be determined. Such an evaluation formula is based on the property that the event instances of the main route and the event instances of the parallel route are generated independently. Become.

A program for causing a computer to execute the method according to the present invention can be created, and the program is a storage medium or storage device such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, and a hard disk. Stored in Note that data being processed is temporarily stored in a storage device such as a computer memory.
The following supplementary notes are further disclosed with respect to the embodiments including the above examples.

(Appendix 1)
Stored in the process instance data storage that stores data of process instances created by arranging event instances belonging to one of the event classes of multiple business events executed during business processing related to a specific matter in time series A step of counting the frequency of occurrence of transition from the originating event class to the destination event class as the frequency of occurrence of transition between events from each transition between the event instances included in each of the process instances being stored in the statistical information storage unit When,
An event instance belonging to the originating event class is generated by dividing the frequency of occurrence of transition between the events stored in the statistical information storage unit by the occurrence frequency of the event instance belonging to the corresponding originating event class. In this case, a conditional probability that an event instance belonging to the destination event class will occur is calculated, and the occurrence frequency of the event instance belonging to each event class is divided by the sum of the occurrence frequencies of the event instances belonging to the event class. Calculating the probability of occurrence of an event instance belonging to each of the event classes, and storing it in the statistical information storage unit;
A transition between events in a process instance created by arranging in a time series event instances that belong to one of the event classes of a plurality of business events executed during business processing related to a specific matter. This is an evaluation formula for apparently detecting a transition that has been executed independently and in parallel without any causal relationship between the tasks corresponding to the originating event and the terminating event, and the originating event of the transition to be judged When the event instance belonging to the class occurs, the conditional probability that the event instance belonging to the destination event class of the transition to be determined occurs and the event instance belonging to the destination event class of the transition to be determined The value of the evaluation formula defined using the probability of occurrence is stored in the statistical information. A step of calculating for each of said transitions according to each of said inter-event transition occurrence frequency stored is stored in the statistical information storage section, the
Detecting the transition related to the value of the evaluation formula that is less than a predetermined threshold among the values of the evaluation formula of each transition stored in the statistical information storage unit as the apparent transition;
Is a business flow data processing program for causing a computer to execute.

(Appendix 2)
For each of the process instances stored in the process instance data storage unit, it is determined whether the transition corresponding to the specified apparent transition is included, and if included, the transition corresponding to the apparent transition is deleted. The business flow data processing program according to appendix 1, further causing the computer to execute a step of storing the data of the process instance in the data storage unit after the apparent transition is deleted.

(Appendix 3)
For each unconnected event instance included in each of the process instances after deletion of the apparent transition stored in the data storage unit, the occurrence date and time is the closest instead of the deleted apparent transition and the The business flow data processing program according to appendix 2, for causing a computer to further execute a step of detecting an event instance that does not appear to be a transition in the same process instance and setting an alternative transition with the detected event instance.

(Appendix 4)
The evaluation formula is
When an event instance belonging to the originating event class of the transition to be determined occurs, the conditional probability that the event instance belonging to the arrival event class of the transition to be determined occurs will be determined as the transition of the transition to be determined. The business flow data processing program according to any one of supplementary notes 1 to 3, which is an expression for calculating an absolute value of a difference between a value obtained by dividing the event instance belonging to the arrival-side event class by the occurrence probability and 1.

(Appendix 5)
Stored in the process instance data storage that stores data of process instances created by arranging event instances belonging to one of the event classes of multiple business events executed during business processing related to a specific matter in time series A step of counting the frequency of occurrence of transition from the originating event class to the destination event class as the frequency of occurrence of transition between events from each transition between the event instances included in each of the process instances being stored in the statistical information storage unit When,
An event instance belonging to the originating event class is generated by dividing the frequency of occurrence of transition between the events stored in the statistical information storage unit by the occurrence frequency of the event instance belonging to the corresponding originating event class. In this case, a conditional probability that an event instance belonging to the destination event class will occur is calculated, and the occurrence frequency of the event instance belonging to each event class is divided by the sum of the occurrence frequencies of the event instances belonging to the event class. Calculating the probability of occurrence of an event instance belonging to each of the event classes, and storing it in the statistical information storage unit;
A transition between events in a process instance created by arranging in a time series event instances that belong to one of the event classes of a plurality of business events executed during business processing related to a specific matter. This is an evaluation formula for apparently detecting a transition that has been executed independently and in parallel without any causal relationship between the tasks corresponding to the originating event and the terminating event, and the originating event of the transition to be judged When the event instance belonging to the class occurs, the conditional probability that the event instance belonging to the destination event class of the transition to be determined occurs and the event instance belonging to the destination event class of the transition to be determined The value of the evaluation formula defined using the probability of occurrence is stored in the statistical information. A step of calculating for each of said transitions according to each of said inter-event transition occurrence frequency stored is stored in the statistical information storage section, the
Detecting the transition related to the value of the evaluation formula that is less than a predetermined threshold among the values of the evaluation formula of each transition stored in the statistical information storage unit as the apparent transition;
A business flow data processing method executed on a computer.

(Appendix 6)
Stored in the process instance data storage that stores data of process instances created by arranging event instances belonging to one of the event classes of multiple business events executed during business processing related to a specific matter in time series Means for counting the frequency of occurrence of transitions from the event class of the originating side to the event class of the incoming side from the transitions between the event instances included in each of the process instances as the frequency of occurrence of transitions between events, and storing in the statistical information storage unit When,
An event instance belonging to the originating event class is generated by dividing the frequency of occurrence of transition between the events stored in the statistical information storage unit by the occurrence frequency of the event instance belonging to the corresponding originating event class. In this case, a conditional probability that an event instance belonging to the destination event class will occur is calculated, and the occurrence frequency of the event instance belonging to each event class is divided by the sum of the occurrence frequencies of the event instances belonging to the event class. Means for calculating the occurrence probability of the event instance belonging to each of the event classes, and storing it in the statistical information storage unit;
A transition between events in a process instance created by arranging in a time series event instances that belong to one of the event classes of a plurality of business events executed during business processing related to a specific matter. This is an evaluation formula for apparently detecting a transition that has been executed independently and in parallel without any causal relationship between the tasks corresponding to the originating event and the terminating event, and the originating event of the transition to be judged When the event instance belonging to the class occurs, the conditional probability that the event instance belonging to the destination event class of the transition to be determined occurs and the event instance belonging to the destination event class of the transition to be determined The value of the evaluation formula defined using the probability of occurrence is stored in the statistical information. Means for each said related to each of said inter-event transition occurrence frequency stored calculated for the transition, stored in the statistical information storage section, the
Means for detecting the transition related to the value of the evaluation formula that is less than a predetermined threshold among the values of the evaluation formula of each transition stored in the statistical information storage unit as the apparent transition;
A business flow data processing apparatus.

DESCRIPTION OF SYMBOLS 1 Analysis object data storage part 3 Event candidate data generation part 5 Event candidate data storage part 7 Event data generation part 9 Event data storage part 11 Input / output part 13 Process instance generation part 15 Process instance data storage part 17 Parallel processing estimation part 19 Parallel Process estimation post-process instance data storage unit 21 Process instance classification processing unit 23 Model data storage unit 25 Process display processing unit 31 Time stamp processing unit 32 Event ID / related ID candidate processing unit 34 Event name processing unit 35 Score table storage unit 171 Statistics Information extraction unit 173 Statistical information storage unit 175 Apparent transition detection unit 177 Apparent transition deletion unit 179 Alternative transition determination processing unit
181 Process instance data storage section for parallel processing

Claims (6)

Stored in the process instance data storage that stores data of process instances created by arranging event instances belonging to one of the event classes of multiple business events executed during business processing related to a specific matter in time series A step of counting the frequency of occurrence of transition from the originating event class to the destination event class as the frequency of occurrence of transition between events from each transition between the event instances included in each of the process instances being stored in the statistical information storage unit When,
An event instance belonging to the originating event class is generated by dividing the frequency of occurrence of transition between the events stored in the statistical information storage unit by the occurrence frequency of the event instance belonging to the corresponding originating event class. In this case, a conditional probability that an event instance belonging to the destination event class will occur is calculated, and the occurrence frequency of the event instance belonging to each event class is divided by the sum of the occurrence frequencies of the event instances belonging to the event class. Calculating the probability of occurrence of an event instance belonging to each of the event classes, and storing it in the statistical information storage unit;
A transition between events in a process instance created by arranging in a time series event instances that belong to one of the event classes of a plurality of business events executed during business processing related to a specific matter. This is an evaluation formula for apparently detecting a transition that has been executed independently and in parallel without any causal relationship between the tasks corresponding to the originating event and the terminating event, and the originating event of the transition to be judged When the event instance belonging to the class occurs, the conditional probability that the event instance belonging to the destination event class of the transition to be determined occurs and the event instance belonging to the destination event class of the transition to be determined The value of the evaluation formula defined using the probability of occurrence is stored in the statistical information. A step of calculating for each of said transitions according to each of said inter-event transition occurrence frequency stored is stored in the statistical information storage section, the
Detecting the transition related to the value of the evaluation formula that is less than a predetermined threshold among the values of the evaluation formula of each transition stored in the statistical information storage unit as the apparent transition;
Is a business flow data processing program for causing a computer to execute. For each of the process instances stored in the process instance data storage unit, it is determined whether the transition corresponding to the specified apparent transition is included, and if included, the transition corresponding to the apparent transition is deleted. The business flow data processing program according to claim 1, further causing the computer to execute a step of storing the data of the process instance in the data storage unit after the apparent transition is deleted. For each unconnected event instance included in each of the process instances after deletion of the apparent transition stored in the data storage unit, the occurrence date and time is the closest instead of the deleted apparent transition and the The business flow data processing program according to claim 2, further causing a computer to execute a step of detecting an event instance that does not seem to correspond to a transition in the same process instance and setting an alternative transition with the detected event instance. The evaluation formula is
When an event instance belonging to the originating event class of the transition to be determined occurs, the conditional probability that the event instance belonging to the arrival event class of the transition to be determined occurs is determined as the transition of the transition to be determined. The business flow data processing program according to any one of claims 1 to 3, wherein the work flow data processing program is an expression for calculating an absolute value of a difference between a value obtained by dividing the event instance belonging to the arrival-side event class by the occurrence probability. Stored in the process instance data storage that stores data of process instances created by arranging event instances belonging to one of the event classes of multiple business events executed during business processing related to a specific matter in time series A step of counting the frequency of occurrence of transition from the originating event class to the destination event class as the frequency of occurrence of transition between events from each transition between the event instances included in each of the process instances being stored in the statistical information storage unit When,
An event instance belonging to the originating event class is generated by dividing the frequency of occurrence of transition between the events stored in the statistical information storage unit by the occurrence frequency of the event instance belonging to the corresponding originating event class. In this case, a conditional probability that an event instance belonging to the destination event class will occur is calculated, and the occurrence frequency of the event instance belonging to each event class is divided by the sum of the occurrence frequencies of the event instances belonging to the event class. Calculating the probability of occurrence of an event instance belonging to each of the event classes, and storing it in the statistical information storage unit;
A transition between events in a process instance created by arranging in a time series event instances that belong to one of the event classes of a plurality of business events executed during business processing related to a specific matter. This is an evaluation formula for apparently detecting a transition that has been executed independently and in parallel without any causal relationship between the tasks corresponding to the originating event and the terminating event, and the originating event of the transition to be judged When the event instance belonging to the class occurs, the conditional probability that the event instance belonging to the destination event class of the transition to be determined occurs and the event instance belonging to the destination event class of the transition to be determined The value of the evaluation formula defined using the probability of occurrence is stored in the statistical information. A step of calculating for each of said transitions according to each of said inter-event transition occurrence frequency stored is stored in the statistical information storage section, the
Detecting the transition related to the value of the evaluation formula that is less than a predetermined threshold among the values of the evaluation formula of each transition stored in the statistical information storage unit as the apparent transition;
A business flow data processing method executed on a computer. Stored in the process instance data storage that stores data of process instances created by arranging event instances belonging to one of the event classes of multiple business events executed during business processing related to a specific matter in time series Means for counting the frequency of occurrence of transitions from the event class of the originating side to the event class of the incoming side from the transitions between the event instances included in each of the process instances as the frequency of occurrence of transitions between events, and storing in the statistical information storage unit When,
An event instance belonging to the originating event class is generated by dividing the frequency of occurrence of transition between the events stored in the statistical information storage unit by the occurrence frequency of the event instance belonging to the corresponding originating event class. In this case, a conditional probability that an event instance belonging to the destination event class will occur is calculated, and the occurrence frequency of the event instance belonging to each event class is divided by the sum of the occurrence frequencies of the event instances belonging to the event class. Means for calculating the occurrence probability of the event instance belonging to each of the event classes, and storing it in the statistical information storage unit;
A transition between events in a process instance created by arranging in a time series event instances that belong to one of the event classes of a plurality of business events executed during business processing related to a specific matter. This is an evaluation formula for apparently detecting a transition that has been executed independently and in parallel without any causal relationship between the tasks corresponding to the originating event and the terminating event, and the originating event of the transition to be judged When the event instance belonging to the class occurs, the conditional probability that the event instance belonging to the destination event class of the transition to be determined occurs and the event instance belonging to the destination event class of the transition to be determined The value of the evaluation formula defined using the probability of occurrence is stored in the statistical information. Means for each said related to each of said inter-event transition occurrence frequency stored calculated for the transition, stored in the statistical information storage section, the
Means for detecting the transition related to the value of the evaluation formula that is less than a predetermined threshold among the values of the evaluation formula of each transition stored in the statistical information storage unit as the apparent transition;
A business flow data processing apparatus.

Images