WO2009104276A1 - 業務フロー処理プログラム、方法及び装置 - Google Patents

業務フロー処理プログラム、方法及び装置 Download PDF

Info

Publication number
WO2009104276A1
WO2009104276A1 PCT/JP2008/053086 JP2008053086W WO2009104276A1 WO 2009104276 A1 WO2009104276 A1 WO 2009104276A1 JP 2008053086 W JP2008053086 W JP 2008053086W WO 2009104276 A1 WO2009104276 A1 WO 2009104276A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
process instance
field
data
business
Prior art date
Application number
PCT/JP2008/053086
Other languages
English (en)
French (fr)
Inventor
川村　旭
原　裕貴
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2008/053086 priority Critical patent/WO2009104276A1/ja
Priority to KR1020107016492A priority patent/KR101175475B1/ko
Priority to JP2009554181A priority patent/JP5012911B2/ja
Priority to EP08711854A priority patent/EP2256677A4/en
Priority to CN2008801269662A priority patent/CN101952843A/zh
Publication of WO2009104276A1 publication Critical patent/WO2009104276A1/ja
Priority to US12/849,163 priority patent/US20100318389A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45508—Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
    • G06F9/45512—Command shells
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0633—Workflow analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/109—Time management, e.g. calendars, reminders, meetings or time accounting
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/20—ICT specially adapted for the handling or processing of medical references relating to practices or guidelines

Definitions

  • the present invention relates to information processing technology for business process analysis.
  • 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.
  • an event indicates that a certain business has been executed in the business system, and is data including the start and end times of business and related attributes.
  • 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.
  • 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.
  • JMS Java (registered trademark) Message Service
  • 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).
  • the business data means data shared between a certain unit of business.
  • the business data is narrowed down based on the input search conditions (for example, event occurrence period, related attributes, etc.).
  • Data related to the narrowed down business data is expanded and displayed in a tree, and processing from arbitrary data is traced.
  • 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.
  • tracking refers to a method of confirming which business is being executed and which business is not being executed among the business processes that are the flow of the entire business across the business systems defined in advance.
  • an object of the present invention is to provide a technique for making it easy for the user to grasp the characteristics of the entire business flow that is performed so that the business flow can be appropriately classified.
  • the business flow processing method extracts a series of business data performed for each case from a database storing business processing results, and arranges the business names of the business performed for each case in time series.
  • the step of storing in the instance data storage unit, the step of counting the process instances stored in the simplified process instance data storage unit for each type, and the appearance frequency is equal to or greater than a predetermined reference based on the counting result;
  • the output step described above may include a step of superimposing the specified process instances. This is to make it easier to grasp the main business flow.
  • the output step described above may include a step of outputting a process instance other than the specified process instance as an exception flow. This is to grasp the occurrence status of the exception flow and use it for business improvement.
  • a step of determining whether or not a repetition of returning from the third task of the process instance to the third task has occurred For the process instance that has occurred, delete the repeated repetition of each repetition pattern type (that is, the repetition that makes it difficult to grasp the overall picture of the business), and the process instance after deleting the repeated repetition is replaced with process instance data And a step of storing in the storage unit. In this way, even if the same iteration occurs many times, it can be integrated into one iteration, and it becomes easy to identify the main business flow that is important in understanding the characteristics of the entire business flow. .
  • a step of determining whether or not a repetition of returning from the third task of the process instance to the third task has occurred For process instances where repetition has occurred, delete the repeated repetition of each repetition pattern type (that is, the repetition that makes it difficult to grasp the overall picture of the business), and process instances after deleting the repeated repetition, And storing the simplified process instance data in the simplified process instance data storage unit.
  • the deletion of repeated repetitions may be performed after the duplicate rework or first. In addition, deletion of duplicate rework or deletion of repeated repetitions may be performed independently.
  • 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.
  • 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.
  • digital signals are distributed over a network.
  • data being processed is temporarily stored in a storage device such as a computer memory.
  • FIG. 1 is a functional block diagram according to the embodiment of the present invention.
  • 2A to 2D are diagrams for explaining the outline of the embodiment of the present invention.
  • FIG. 3 is a diagram showing a main processing flow in the embodiment of the present invention.
  • FIG. 4A is a diagram showing schema information of an order DB as an example of extracted data
  • FIG. 4B is a diagram showing a record group of the order DB.
  • FIG. 5A shows the schema information of the production DB as an example of extracted data
  • FIG. 5B shows the record group of the production DB.
  • FIG. 6A is a diagram showing arrangement DB schema information as an example of extracted data
  • FIG. 6B is a diagram showing a record group of the arrangement DB.
  • FIG. 7A is a diagram showing schema information of a delivery DB as an example of extracted data
  • FIG. 7B is a diagram showing a record group of the delivery DB
  • FIG. 8A shows schema information of a product number DB as an example of extracted data
  • FIG. 8B shows a record group of the product number DB.
  • FIG. 9A shows an example of data in the order DB in the CSV format
  • FIG. 9B shows an example in which the data in the order DB is tabulated.
  • FIG. 10A shows an example of data in the production DB in CSV format
  • FIG. 10B shows an example in which the data in the production DB is tabulated.
  • FIG. 11A illustrates an example of data in the arrangement DB in the CSV format
  • FIG. 11B illustrates an example in which the data in the arrangement DB is tabulated.
  • FIG. 12A shows an example of data in the delivery DB in the CSV format
  • FIG. 12B shows an example in which the data in the delivery DB is tabulated.
  • FIG. 13A shows an example of data in the product number DB in the CSV format
  • FIG. 13B shows an example in which the data in the product number DB is tabulated.
  • FIG. 14 is a diagram illustrating a process flow of the time stamp determination process.
  • FIG. 15 is a diagram illustrating an example of a time stamp accuracy score table.
  • FIG. 16 is a diagram illustrating a processing flow of event ID / related ID candidate determination processing.
  • FIG. 17 is a diagram illustrating an example of an event ID / related ID candidate accuracy score table.
  • FIG. 18 is a diagram illustrating a process flow of the event name determination process.
  • FIG. 19 is a diagram illustrating an example of a table including a plurality of time stamps.
  • 20A to 20E are diagrams illustrating an example in which the table of FIG. 19 is divided into a plurality of tables for each event.
  • FIG. 21 is a diagram illustrating an example of determination display for each element of event candidate data in the order DB when schema information exists.
  • FIG. 22 is a diagram illustrating an example of a determination display for each element of an event candidate in the order DB in the case of CSV format data.
  • FIG. 23 is a diagram illustrating an example of a determination display for each element of event candidate data in the production DB when schema information exists.
  • FIG. 24 is a diagram illustrating an example of a determination display for each element of the production DB event candidate in the case of CSV format data.
  • FIG. 25 is a diagram illustrating an example of a determination display for each element of event candidate data in the arrangement DB when schema information exists.
  • FIG. 26 is a diagram illustrating an example of a determination display for each element of event candidates in the arrangement DB in the case of CSV format data.
  • FIG. 27 is a diagram illustrating an example of a determination display for each element of event candidate data in the delivery DB when schema information exists.
  • FIG. 24 is a diagram illustrating an example of a determination display for each element of the production DB event candidate in the case of CSV format data.
  • FIG. 25 is a diagram illustrating an example of a determination display for each element of event candidate data in the arrangement DB when schema information exists.
  • FIG. 28 is a diagram illustrating an example of a determination display for each element of a delivery DB event candidate in the case of CSV format data.
  • FIG. 29 is a diagram illustrating an example of a determination display for each element of event candidate data in the product number DB when schema information exists.
  • FIG. 30 is a diagram illustrating an example of a determination display for each element of event candidates in the product number DB in the case of CSV format data.
  • FIG. 31 is a diagram illustrating an example of a selection result for each element of event candidate data.
  • FIG. 32 is a diagram illustrating an example of event candidate data generated from data in the order DB when schema information exists.
  • FIG. 33 is a diagram showing an example of event candidate data generated from data in the order DB in the case of CSV format data.
  • FIG. 29 is a diagram illustrating an example of a determination display for each element of event candidate data in the product number DB when schema information exists.
  • FIG. 30 is a diagram illustrating an example of a determination display
  • FIG. 34 is a diagram illustrating an example of event candidate data generated from data in the production DB when schema information exists.
  • FIG. 35 is a diagram illustrating an example of event candidate data generated from production DB data in the case of CSV format data.
  • FIG. 36 is a diagram illustrating an example of event candidate data generated from the data in the arrangement DB when schema information exists.
  • FIG. 37 is a diagram showing an example of event candidate data generated from data in the arrangement DB in the case of CSV format data.
  • FIG. 38 is a diagram illustrating an example of event candidate data generated from data in the delivery DB when schema information exists.
  • FIG. 39 is a diagram illustrating an example of event candidate data generated from data in the delivery DB in the case of CSV format data.
  • FIG. 35 is a diagram illustrating an example of event candidate data generated from production DB data in the case of CSV format data.
  • FIG. 36 is a diagram illustrating an example of event candidate data generated from the data in the arrangement DB when schema information exists.
  • FIG. 40 is a diagram showing an example of event candidate data related to the draft in FIG. 41 is a diagram showing an example of event candidate data related to the approval of FIG.
  • FIG. 42 is a diagram showing an example of event candidate data related to the order shown in FIG.
  • FIG. 43 is a diagram showing an example of event candidate data related to delivery in FIG.
  • FIG. 44 is a diagram illustrating an example of event candidate data relating to the inspection in FIG.
  • FIG. 45 is a diagram illustrating an example of event data and an inter-event relationship tree.
  • FIG. 46 is a diagram for explaining process instance generation from event data.
  • FIG. 47 is a diagram illustrating an example of a process instance.
  • FIG. 48 is a diagram for explaining main and exceptional flow extraction processing.
  • FIG. 49 is a diagram showing a display example when the process instances shown in FIG. 48 are overlaid.
  • 50A to 50C are diagrams showing display examples when the process instances shown in FIG. 48 are classified into main flows and exception flows.
  • FIG. 51 is a diagram illustrating an example of a process instance for explaining the deduplication processing.
  • FIG. 52 is a diagram showing an example in which the process instances shown in FIG. 51 are simply classified.
  • FIG. 53 is a diagram illustrating a processing flow of the deduplication processing.
  • FIG. 54A is a diagram illustrating an example of a process instance having overlapping repetitions.
  • FIG. 54B is a diagram illustrating an example of process instances when overlapping repetitions are deleted.
  • FIG. 55 is a diagram showing a process flow of the return overlap elimination process.
  • FIG. 56 is a diagram showing an example of a process instance for explaining the return overlap elimination processing.
  • FIG. 57 is a diagram for explaining extraction of the return part.
  • FIG. 58A is a diagram for explaining classification of the return portion.
  • FIG. 58B is a diagram for describing processing for deleting duplication of a return part.
  • FIG. 59 is a diagram illustrating an example of reconstructing a process instance.
  • FIG. 60 is a diagram showing an example of superimposed display of process instances in FIG.
  • FIG. 61 is a diagram showing an example of superimposed display of process instances in FIG.
  • FIG. 62 is a diagram showing a process instance as a result of performing the deduplication processing on the process instance example shown in FIG. FIG.
  • FIG. 63 is a diagram illustrating an example of data stored in the model data storage unit.
  • FIG. 64 is a diagram showing a processing flow of flow display processing.
  • FIG. 65 is a diagram showing a display example when all the process instances registered in FIG. 63 are overlaid.
  • FIG. 66 is a diagram showing a display example when the process instances registered in FIG. 63 are divided into main flows and exception flows.
  • FIG. 67 is a functional block diagram of the computer apparatus.
  • FIG. 1 shows a functional block diagram 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).
  • database record group data collected from one or a plurality of analysis target systems
  • NDB network DB
  • 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
  • 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
  • a duplication resolving unit 17 that performs processing for deleting rework and repetition that makes it difficult to grasp the overall picture of the business
  • a duplication resolving unit 17 A simplified process instance data storage unit 19 that stores data of processed process instances, and a process instance that classifies the process instances stored in the
  • 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, and the process display processing unit 25.
  • 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. Furthermore, the duplication elimination unit 17 includes a repetition processing unit 171 and a rework processing unit 173.
  • 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, time (time stamp that is the date and time when the event occurred), other first value (value 1), A record group including a value of 2 (value 2) and the like is extracted.
  • event names and time stamps, and other data fields that are candidates for event IDs and related IDs are specified.
  • 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, time (time stamp which is the date and time of occurrence of the event), event ID (here ID1), and other values, A record group including an event name, time (time stamp), ID1 and ID2 is extracted, and a field value of ID2 which is a related ID of a record of the second event class (that is, event type) is the first, By taking any value of the field value of ID1 which is the event ID of the record of the event class (ie, event type), each record (ie, event instance) of the second event class becomes the first event.
  • 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. This publication is incorporated in the present application.
  • the process instance data is processed by the deduplication unit 17 and the process instance classification processing unit 21, and the process display processing unit 25 determines the process flow (also referred to as a business flow) from the data stored in the model data storage unit 23. Data) is generated and displayed on the display device via the input / output unit 11.
  • a business flow in which process instances are identified and specified is shown.
  • 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.
  • 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.
  • the field name, key setting data, data type, record length, and comment are registered for each of the fields 1 to 4.
  • 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
  • the order details are registered in field 4. I understand.
  • 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.
  • 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.
  • the field name, key setting data, data type, record length, and comment are registered for each of the fields 1 to 5.
  • 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
  • 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.
  • 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.
  • 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.
  • the field name, key setting data, data type, record length, and comment are registered for each of the fields 1 to 5.
  • 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
  • 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.
  • 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.
  • 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.
  • the field name, key setting data, data type, record length, and comment are registered for each of the fields 1 to 4.
  • 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
  • a delivery destination is stored in field 4. You can see that it is registered.
  • 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.
  • 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.
  • 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.
  • 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.
  • the data of the order DB is acquired in the CSV format
  • the data as shown in FIG. 9A is stored in the analysis target data storage unit 1.
  • 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.
  • 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.
  • FIG. 10A 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.
  • 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.
  • FIG. 10B 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.
  • FIG. 11A 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.
  • 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.
  • FIG. 11 (b) 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.
  • data as shown in FIG. 12A is stored in the analysis target data storage unit 1.
  • 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.
  • FIG. 12A 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.
  • FIG. 13A 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.
  • 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.
  • FIG. 13 (b) 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.
  • 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.
  • the time stamp processing unit 31 of the event candidate data generating unit 3 refers to the analysis target data storage unit 1 and identifies one unprocessed field in the analysis target table (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).
  • step S35 If the schema information is usable, the data portion of the processing target field is specified in the schema information, and it is determined whether 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.
  • step S37 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.
  • step S33 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).
  • 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 (%).
  • the accuracy score is 5 ( %)
  • the field value string is “YYYY / MM / If the format is Dhh: mm: ss, the accuracy score is set to 90 (%), and if the field value string 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 (%).
  • 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.
  • the field values include characters other than characters related to time.
  • the accuracy score is 5 (%).
  • the accuracy score is specified as 10 (%).
  • 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”.
  • the field value includes characters other than characters related to time. Specificity is specified as an accuracy score of 5 (%).
  • the accuracy score is 90 (%). Identified.
  • the fields 2 and 4 since the data type is not related, the same result as in the case where the schema information exists is obtained.
  • the field value includes characters other than characters related to time. Specificity is specified as an accuracy score of 5 (%).
  • the data type is not related, so that the same result as in the case where the schema information exists can be obtained.
  • 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.
  • step S43 it is determined whether all fields in the processing target table have been processed. 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.
  • 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.
  • step S9 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.
  • 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.
  • the event ID is an event identifier storage field
  • the field values do not overlap each other. Therefore, if there is a duplicate value in the event ID field, it can be determined that it is not an event ID.
  • step S55 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.
  • 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 NULL (step S62).
  • step S63 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. This is because the related ID is a value indicating which of the other events corresponds to the event, and if the field value does not have two or more values except NULL, a meaningful result cannot be obtained. .
  • 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.
  • 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.
  • step S55 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.
  • the event ID / related ID candidate probability score table stored in the score table storage unit 35, the corresponding data portion of the processing target field in the schema information, the label data indicating the field name of the processing target field, and the processing The accuracy is specified from the field value of the target field (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.
  • FIG. 17 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.
  • 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 (%).
  • the data type is a variable length character string, so the accuracy score is 1 (%).
  • 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 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.
  • the primary key is specified, an accuracy score of 80 (%) with a large deviation from 50% is adopted, and the accuracy score of 70 (%) is specified because the data type is a fixed-length character string for fields 3 to 4
  • the accuracy score 10 (%) is specified.
  • the accuracy score 50 (%) is specified for the field 1 to the field 5 because the corresponding item does not exist in the event ID / related ID candidate accuracy score table.
  • 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.
  • the accuracy score 50 (%) is specified for the fields 1 and 5 because the corresponding item does not exist in the event ID / related ID candidate accuracy score table. Is done.
  • 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 deviation from 50% is adopted, and the accuracy score of 70 (%) is specified because the data type is a fixed-length character string for fields 3 to 4 Is done.
  • 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 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).
  • step S61 it is determined whether all fields in the processing target table have been processed (step S61), and if there is an unprocessed field, the process returns to step S51. On the other hand, if all fields are processed, the process returns to the original process.
  • step S13 the event name processing unit 34 of the event candidate data generation unit 3 performs an event name determination process (step S13). This event name determination process will be described with reference to FIGS.
  • 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.
  • a threshold value such as an accuracy score of 70 (%) or higher is set.
  • the field identified as “determined” is a time stamp field.
  • 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”.
  • step S93 it is determined whether 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.
  • a time stamp for example, a product number DB
  • step S97 it is determined whether 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).
  • 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
  • the event name is “arrangement” in the case of the arrangement DB.
  • the event name is specified as “delivery”. Then, the process returns to the original process.
  • 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.
  • step S101 is executed.
  • 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.
  • the event candidate data generation unit 3 presents the determination result to the user via the input / output unit 11 (step S15).
  • 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.
  • 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.
  • the order DB in the CSV format shown in FIG. 9A data as shown in FIG. 22 is presented to the user.
  • 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.
  • 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.
  • data as shown in FIG. 23 is presented to the user.
  • 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.
  • 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.
  • data as shown in FIG. 24 is presented to the user.
  • 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.
  • 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.
  • data as shown in FIG. 25 is presented to the user.
  • 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.
  • 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.
  • 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.
  • 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.
  • data as shown in FIG. 27 is presented to the user.
  • 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.
  • 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.
  • data as shown in FIG. 28 is presented to the user.
  • 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.
  • 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.
  • step S ⁇ b> 15 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.
  • the table name “order received” is confirmed for the event name
  • the date / time field is confirmed for the time stamp
  • the order number field for the event ID / related ID candidate is stored in the event candidate data storage unit 5.
  • 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.
  • “order received” which is a table name is confirmed for the event name, 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.
  • the field is determined, for example, data as shown in FIG. 33 is stored in the event candidate data storage unit 5.
  • “arrangement” which is a table name is determined for the event name, the date / time field is determined for the time stamp, the arrangement number field and the order number field for the event ID / related ID candidate,
  • 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.
  • “delivery” which is a table name is confirmed for the event name, the date / time field is confirmed for the time stamp, the arrangement number field and the delivery flight field for the event ID / related ID candidate,
  • the delivery destination field is determined, for example, data as shown in FIG. 38 is stored in the event candidate data storage unit 5.
  • “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
  • the event candidate data storage unit 5 When finalizing the delivery destination field, for example, data as shown in FIG. 39 is stored in the event candidate data storage unit 5.
  • data as shown in FIGS. 40 to 44 is the event candidate data storage unit 5.
  • 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”.
  • 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.
  • 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 are all field names and field values as event ID / related ID candidates. The record is copied.
  • event candidate data used in the following processing is stored in the event candidate data storage unit 5.
  • step S3 If it is determined in step S3 that all the analysis target tables have been processed, the event data generation unit 7 uses the event candidate data stored in the event candidate data storage unit 5 to perform event data generation processing. Then, the processing result is stored in the event data storage unit 9 (step S17).
  • 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.
  • the generation method the above-described automatic extraction method of event data related information as described in Japanese Patent Application No. 2006-197294 described above may be used, or the event ID / relation of each event candidate data manually.
  • the relationship between the events may be determined by investigating and analyzing the correspondence relationship between the field values of the ID candidates.
  • 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
  • the delivery It is confirmed that the event ID of the event is an arrangement number and the related ID is a delivery flight.
  • each record of the production event that is, the event instance
  • each record of the production event 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.
  • 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).
  • a business process tracking method such as US Patent Publication No. 2005 / 076059A1 can be used.
  • FIG. 46 shows a schematic explanation of the process for generating a process instance starting from the order event instance of the order number JT01 using the event data of FIG.
  • a record that is, an event instance
  • JT01 order ID field value
  • two event instances from the production event and three event instances from the arrangement event are determined. Is done.
  • the arrangement number: TH01, TH02, TH03 which is the event ID of the confirmed arrangement event, is recorded as a record (that is, an event instance) having the field number of the related ID as three fields from the delivery event.
  • the event instance is finalized.
  • the process is performed by connecting the 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 instance of JT01.
  • An instance is created. That is, as the first process instance, a process instance is generated in which event instances such as orders, production, arrangement, arrangement, arrangement, delivery, production, delivery, and delivery are arranged in time series.
  • the second process instance is a process instance in which event instances of order receipt, arrangement, and delivery are arranged in time series.
  • the third process instance is a process instance in which event instances of order receipt, production, production, arrangement, and delivery are arranged in time series.
  • the fourth process instance is a process instance in which event instances such as orders, arrangements, and deliveries are arranged in time series.
  • the deduplication unit 17 performs deduplication 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.
  • a process instance is created to return to the billing through continuation and perform collection (return) to transition to contract expiration and final state.
  • C is configured.
  • one process instance is created in which collection is performed (repeated) again and the contract expires and the state transitions to final state.
  • FIG. A flow in which process instances of group B are superimposed is generated and presented to the user.
  • the exception flow is a process instance of group C shown in FIG. 50B (however, for the sake of explanation, the routed event instance and the transition of the return part are indicated by dotted lines), FIG.
  • the process instance of the group D shown in 50 (c) (however, for the sake of easy explanation, the transition representing the repetition is shown by a dotted line) is presented to the user.
  • the process of initial state, contract, voucher creation, billing, collection, contract expiration, and final phase is basically the same as creating a voucher, billing and collection once via a contract update event instance.
  • One process instance is generated that performs rework for repeating billing and collection three times.
  • one process instance is also generated that performs rework that repeats billing and collection once via a continuation event instance. Has been.
  • the deduplication unit 17 identifies one unprocessed process instance in the process instance data storage unit 15 (FIG. 52: step S111). Then, the specified process instance is inspected for repetition and rework (step S113). Identifies a transition that returns to or from another event instance that was executed before a specific event instance as a reversal, and a transition that returns to the same event instance as a repetition .
  • One process instance may include repetition and rework, and may include multiple locations, repetitive or rework.
  • the iterative processing unit 171 of the duplication eliminating unit 17 determines whether or not all repetitive portions have been processed for the identified process instance (step S115). If there is an unprocessed repeat location, the repeat processing unit 171 identifies an unprocessed repeat location (step S117), leaves only one iteration at the identified repeat location, and deletes the rest (step S119). . Then, the process returns to step S115.
  • the return processing unit 173 determines whether all the returned portions have been processed (step S121). If there is an unprocessed return part, the return processing unit 173 identifies one unprocessed return part (step S123). Then, a return overlap elimination process is performed (step S125). The return overlap elimination process will be described with reference to FIGS. 55 to 58B.
  • the return processing unit 173 cuts out the return portion at the specified return location (step S131).
  • a process instance as shown in FIG. 56 is processed is assumed. Specifically, in this process instance, Initial State, contract, slip creation, billing, contract renewal, proceed to billing start, return to billing, contract renewal, proceed to billing start, then return to slip creation, After proceeding to billing, contract renewal, and billing start, return to billing, proceed to contract renewal, billing start, billing end, and proceed to Final State.
  • step S131 as shown in FIG. 57, a first return part to return to billing, a second return part to return to bill creation, and a third return part to return to billing are cut out.
  • the return processing unit 173 classifies the patterns of the return portion (step S133). As shown in FIG. 58A, the three reworked parts cut out as shown in FIG. 58 are identified as pattern 1 in the two reworked parts until billing, contract renewal, and billing start. One return part is identified as pattern 2.
  • the rework processing unit 173 eliminates duplication for each pattern, that is, leaves one rework for each pattern and deletes the remaining rework (step S135).
  • the rework processing unit 173 eliminates duplication for each pattern, that is, leaves one rework for each pattern and deletes the remaining rework (step S135).
  • the return processing unit 173 reconstructs the process instance and stores it in the simplified process instance data storage unit 19 (step S137).
  • the reworked portions of patterns 1 and 2 are connected as event instances that occur in succession, and Initial State, contract, slip creation, billing, contract update, Process instances are generated in which event instances are generated in the order of billing start, billing, contract update, billing start, slip creation, billing, contract update, billing start, billing end, FinalFState.
  • step S121 If it is determined in step S121 that all reworked parts have been processed or if there are no reworked parts, the duplication eliminating unit 17 determines whether all process instances have been processed (step S127). If there is an unprocessed process instance, the process returns to step S111. On the other hand, if there is no unprocessed process instance, the process returns to the original process.
  • the process instance classification processing unit 21 classifies the process instances stored in the simplified process instance data storage unit 19, counts for each type based on the classification result, and calculates for each type.
  • the numerical value is stored in the model data storage unit 23 (step S23).
  • the process display processing unit 25 performs a flow display process using the data stored in the model data storage unit 23 (step S25). The flow display process will be described with reference to FIGS.
  • the flow 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).
  • a threshold value for the ratio of the total number of process instances in the group which is a criterion for handling each process group as a main flow
  • it is determined by a preset value (step S143). For example, when a group having a threshold of 20% or more of the total ratio is classified as a main flow, 20% is input. However, a preset value (for example, 30%) may be used as it is.
  • the flow display processing unit 25 selects one unselected process instance from the higher count value (step S147).
  • the selected process instance is designated as a main flow (also called a typical flow) (step S149).
  • the main flow flag in the table of the model data storage unit 23 is set to ON.
  • the ratio to the whole is 60%, and if the threshold is 20%, the process returns to step S147.
  • the ratio to the entire record is 30%, 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.
  • 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 flow display processing unit 25 returns to the original process.
  • 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.
  • the flow 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. 65 is displayed. As shown in FIG. 65, the display is such that there is only one rework through continuation, rework through contract renewal, and collection.
  • the display as shown in FIG. 66 is made. For example, if the classification ratio is 90%, the process instances of the first and second records are overlapped in the table shown in FIG. 63, and the business flow as shown in the upper part of FIG. 66 is displayed as the main flow. Also, the third process instance is displayed as an exception flow in the table shown in FIG.
  • the business flow is presented in a very organized form as compared to the classification and display as shown in FIG. 52, so the user can give an overview of the business flow actually being performed. It becomes easier to grasp. That is, since rework and repetition that make it difficult to grasp the overall picture of the work in grasping the characteristics are omitted, it becomes easy to grasp the presence and manner of repetition and the presence and manner of rework.
  • the functional block diagram shown in FIG. 1 is an example and does not necessarily correspond to an actual program module.
  • 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.
  • steps S7 to S13 can be changed, and may be performed in parallel.
  • 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.
  • 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. 67, 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: Operating System) 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.
  • OS Operating System
  • data in the middle of processing is stored in the memory 2501 and stored in the HDD 2505 if necessary.
  • an application program for executing the processing described above is stored in the removable disk 2511 and distributed, and installed from the drive device 2513 to the HDD 2505.
  • the HDD 2505 may be installed via a network such as the Internet and the communication control unit 2517.
  • Such a computer apparatus realizes various functions as described above by organically cooperating hardware such as the CPU 2503 and the memory 2501 described above, the OS, and necessary application programs.

Abstract

　業務フローの分類を適切に実施できるようにしてユーザに実施されている業務フロー全体の特徴を把握しやすくするために、本業務フロー処理方法は、業務処理の結果を格納するデータベースから案件毎に実施された一連の業務のデータを抽出して、案件毎に実施された業務の業務名を時系列に並べたプロセスインスタンスを生成するステップと、各プロセスインスタンスについて、当該プロセスインスタンスの第１の業務から先に実施された第２の業務に戻る手戻りが発生しているか判断するステップと、手戻りが発生しているプロセスインスタンスについて、手戻りのパターン種別毎に当該手戻りの重複手戻りを削除するステップと、重複手戻り削除後のプロセスインスタンスを、種別毎に計数するステップと、計数結果に基づき、出現頻度が所定基準以上となっており且つ重複手戻り削除後のプロセスインスタンスを特定し、主要な業務フローとして出力するステップとを含む。

Description

業務フロー処理プログラム、方法及び装置
　本発明は、業務プロセス分析のための情報処理技術に関する。
　業務プロセス・リエンジニアリング（ＢＰＲ：Business Process Re-engineering）のために現在企業で運用中の業務システムの分析を行う必要がある。このため、例えば特開２００５－１１５４９４号公報記載のような技術が用いられる。この公報には、以下のような事項が開示されている。
　すなわち、（１）異なる業務システムに配置される各アプリケーションの実行状態を示す情報であるイベントデータを、各アプリケーションに応じた方法で収集し、イベントキューにキューイングする。なお、この公報でイベントとは、業務システム内で、ある業務が実行されたことを示すものであり、業務の開始、終了時間、および関連属性を含んだデータである。イベントデータは、各業務システムに配置されたイベント抽出定義に従って、業務システム毎のイベントデータ抽出用のアプリケーションによって抽出される。各業務システム内で、抽出されたイベント情報を共通のＸＭＬ（eXtensible Markup Language）形式に変換し、イベントデータを管理するイベント管理装置のイベントキューにキューイングする。このキューイングには、例えばＪＭＳ（Java（登録商標） Message Service）等が利用される。
　（２）イベント管理装置内で、イベントキュー内にキューイングされたイベント情報について、業務データ毎にまとめ、業務データ間を関連付けてイベント管理データベース（ＤＢ）内に蓄積する。この公報で、業務データとは、あるまとまった単位の業務の間で共有されるデータを意味する。（３）入力された検索条件（例えば、イベント発生期間、関連属性等）に基づいて、業務データの絞込みを行う。（４）絞り込まれた業務データに関連するデータをツリーで展開して表示し、任意のデータからの処理の追跡を行う。（５）ツリーで展開された業務データに関連するイベントを検索し、このイベントに関連する業務をトラッキングビューで図示して、現在の業務の流れの実行状況を表示する。この公報で、トラッキングとは、あらかじめ定義された業務システム間を跨ぐ業務全体の流れである業務プロセスのうち、どの業務が実行され、どの業務が実行されていないかを確認する手法をいう。
　このような公報記載の技術では、業務システム毎にイベントデータ抽出用のアプリケーションを導入する必要があり、業務システムに改変を加えるか又は業務実行に不要な負荷を与えることとなる。
　また、このような公報記載の技術では、業務フローが実施される頻度を分析して、標準的な業務フローと例外的な業務フローとを分類するような構成は開示されておらず、また分類における問題点についても示唆も開示もなされていない。
特開２００５－１１５４９４号公報
　従って、本発明の目的は、業務フローの分類を適切に実施できるようにして実施されている業務フロー全体の特徴をユーザに把握しやすくするための技術を提供することである。
　本発明に係る業務フロー処理方法は、業務処理の結果を格納するデータベースから案件毎に実施された一連の業務のデータを抽出して、案件毎に実施された業務の業務名を時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、プロセスインスタンスデータ格納部に格納されている各プロセスインスタンスについて、当該プロセスインスタンスの第１の業務から先に実施された第２の業務に戻る手戻りが発生しているか判断するステップと、手戻りが発生しているプロセスインスタンスについて、手戻りのパターン種別毎に当該手戻りの重複手戻り（すなわち、業務の全体像の把握を困難にしている手戻り）を削除し、重複手戻り削除後のプロセスインスタンスを、簡略化プロセスインスタンスデータ格納部に格納するステップと、簡略化プロセスインスタンスデータ格納部に格納されているプロセスインスタンスを、種別毎に計数するステップと、計数結果に基づき、出現頻度が所定基準以上となっており且つ簡略化プロセスインスタンスデータ格納部に格納されているプロセスインスタンスを特定し、主要な業務フローとして出力する出力ステップとを含む。
　このようにすれば、何回も同じ手戻りが発生していても、１つの手戻りに統合することができ、業務フロー全体の特徴を把握する上で重要となる主要な業務フローを特定しやすくなる。
　なお、上で述べた出力ステップが、特定されたプロセスインスタンスを重ね合わせるステップを含むようにしてもよい。主要な業務フローをより簡単に把握できるようにするためである。
　さらに、上で述べた出力ステップが、特定されたプロセスインスタンス以外のプロセスインスタンスを、例外フローとして出力するステップを含むようにしてもよい。例外フローの発生状況を把握して、業務改善などに役立てるためである。
　さらに、本発明において、プロセスインスタンスデータ格納部に格納されている各プロセスインスタンスについて、当該プロセスインスタンスの第３の業務から当該第３の業務に戻る繰り返しが発生しているか判断するステップと、繰り返しが発生しているプロセスインスタンスについて、繰り返しのパターン種別毎に当該繰り返しの重複繰り返し（すなわち業務の全体像の把握を困難にしている繰り返し）を削除し、重複繰り返し削除後のプロセスインスタンスを、プロセスインスタンスデータ格納部に格納するステップとをさらに含むようにしても良い。このようにすれば、何回も同じ繰り返しが発生していても、１つの繰り返しに統合することができ、業務フロー全体の特徴を把握する上で重要となる主要な業務フローを特定しやすくなる。
　さらに、本発明において、簡略化プロセスインスタンスデータ格納部に格納されている各プロセスインスタンスについて、当該プロセスインスタンスの第３の業務から当該第３の業務に戻る繰り返しが発生しているか判断するステップと、繰り返しが発生しているプロセスインスタンスについて、繰り返しのパターン種別毎に当該繰り返しの重複繰り返し（すなわち、業務の全体像の把握を困難にしている繰り返し）を削除し、重複繰り返し削除後のプロセスインスタンスを、簡略化プロセスインスタンスデータ格納部に格納するステップとをさらに含むようにしても良い。重複繰り返しの削除については、重複手戻りの後に実施しても先に実施しても良い。また、重複手戻りの削除又は重複繰り返しの削除を独立に実施するようにしても良い。
　なお、本発明に係る方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ－ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
図１は、本発明の実施の形態における機能ブロック図である。 図２（ａ）乃至（ｄ）は、本発明の実施の形態の概要を説明するための図である。 図３は、本発明の実施の形態におけるメインの処理フローを示す図である。 図４（ａ）は、抽出データ例である受注ＤＢのスキーマ情報、図４（ｂ）は、受注ＤＢのレコード群を示す図である。 図５（ａ）は、抽出データ例である生産ＤＢのスキーマ情報、図５（ｂ）は、生産ＤＢのレコード群を示す図である。 図６（ａ）は、抽出データ例である手配ＤＢのスキーマ情報、図６（ｂ）は、手配ＤＢのレコード群を示す図である。 図７（ａ）は、抽出データ例である配送ＤＢのスキーマ情報、図７（ｂ）は、配送ＤＢのレコード群を示す図である。 図８（ａ）は、抽出データ例である品番ＤＢのスキーマ情報、図８（ｂ）は、品番ＤＢのレコード群を示す図である。 図９（ａ）は、ＣＳＶ形式の受注ＤＢのデータ例を示し、図９（ｂ）は、受注ＤＢのデータをテーブル化した例を示す図である。 図１０（ａ）は、ＣＳＶ形式の生産ＤＢのデータ例を示し、図１０（ｂ）は、生産ＤＢのデータをテーブル化した例を示す図である。 図１１（ａ）は、ＣＳＶ形式の手配ＤＢのデータ例を示し、図１１（ｂ）は、手配ＤＢのデータをテーブル化した例を示す図である。 図１２（ａ）は、ＣＳＶ形式の配送ＤＢのデータ例を示し、図１２（ｂ）は、配送ＤＢのデータをテーブル化した例を示す図である。 図１３（ａ）は、ＣＳＶ形式の品番ＤＢのデータ例を示し、図１３（ｂ）は、品番ＤＢのデータをテーブル化した例を示す図である。 図１４は、タイムスタンプ判定処理の処理フローを示す図である。 図１５は、タイムスタンプ確度スコア表の一例を示す図である。 図１６は、イベントＩＤ・関連ＩＤ候補判定処理の処理フローを示す図である。 図１７は、イベントＩＤ・関連ＩＤ候補確度スコア表の一例を示す図である。 図１８は、イベント名判定処理の処理フローを示す図である。 図１９は、タイムスタンプが複数含まれるテーブルの一例を示す図である。 図２０（ａ）乃至（ｅ）は、図１９のテーブルをイベント毎に複数のテーブルとして分割した例を示す図である。 図２１は、スキーマ情報が存在する場合における、受注ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２２は、ＣＳＶ形式のデータの場合における、受注ＤＢのイベント候補の各要素に対する判定表示の一例を示す図である。 図２３は、スキーマ情報が存在する場合における、生産ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２４は、ＣＳＶ形式のデータの場合における、生産ＤＢのイベント候補の各要素に対する判定表示の一例を示す図である。 図２５は、スキーマ情報が存在する場合における、手配ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２６は、ＣＳＶ形式のデータの場合における、手配ＤＢのイベント候補の各要素に対する判定表示の一例を示す図である。 図２７は、スキーマ情報が存在する場合における、配送ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図２８は、ＣＳＶ形式のデータの場合における、配送ＤＢのイベント候補の各要素に対する判定表示の一例を示す図である。 図２９は、スキーマ情報が存在する場合における、品番ＤＢのイベント候補データの各要素に対する判定表示の一例を示す図である。 図３０は、ＣＳＶ形式のデータの場合における、品番ＤＢのイベント候補の各要素に対する判定表示の一例を示す図である。 図３１は、イベント候補データの各要素に対する選択結果の一例を示す図である。 図３２は、スキーマ情報が存在する場合において受注ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３３は、ＣＳＶ形式のデータの場合において受注ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３４は、スキーマ情報が存在する場合において生産ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３５は、ＣＳＶ形式のデータの場合において生産ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３６は、スキーマ情報が存在する場合において手配ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３７は、ＣＳＶ形式のデータの場合において手配ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３８は、スキーマ情報が存在する場合において配送ＤＢのデータから生成したイベント候補データの一例を示す図である。 図３９は、ＣＳＶ形式のデータの場合において配送ＤＢのデータから生成したイベント候補データの一例を示す図である。 図４０は、図１９の起票に関するイベント候補データの一例を示す図である。 図４１は、図１９の承認に関するイベント候補データの一例を示す図である。 図４２は、図１９の発注に関するイベント候補データの一例を示す図である。 図４３は、図１９の納品に関するイベント候補データの一例を示す図である。 図４４は、図１９の検収に関するイベント候補データの一例を示す図である。 図４５は、イベントデータ及びイベント間関係ツリーの一例を示す図である。 図４６は、イベントデータからのプロセスインスタンス生成を説明するための図である。 図４７は、プロセスインスタンスの一例を示す図である。 図４８は、主要及び例外フローの抽出処理を説明するための図である。 図４９は、図４８に示したプロセスインスタンスを重ね合わせる場合の表示例を示す図である。 図５０（ａ）乃至（ｃ）は、図４８に示したプロセスインスタンスを、主要フローと例外フローとに分類した場合の表示例を示す図である。 図５１は、重複解消処理を説明するためのプロセスインスタンスの例を示す図である。 図５２は、図５１に示したプロセスインスタンスを単純に分類した場合の例を示す図である。 図５３は、重複解消処理の処理フローを示す図である。 図５４Ａは、重複する繰り返しを有するプロセスインスタンスの例を示す図である。 図５４Ｂは、重複する繰り返しを削除した場合のプロセスインスタンスの例を示す図である。 図５５は、手戻り重複解消処理の処理フローを示す図である。 図５６は、手戻り重複解消処理を説明するためのプロセスインスタンスの例を示す図である。 図５７は、手戻り部分の切り出しを説明するための図である。 図５８Ａは、手戻り部分の分類を説明するための図である。 図５８Ｂは、手戻り部分の重複を削除する処理を説明するための図である。 図５９は、プロセスインスタンスの再構築例を示す図である。 図６０は、図５６のプロセスインスタンスの重ね合わせ表示の例を示す図である。 図６１は、図５９のプロセスインスタンスの重ね合わせ表示の例を示す図である。 図６２は、図５１に示したプロセスインスタンスの例に対して重複解消処理を実施した結果のプロセスインスタンスを示す図である。 図６３は、モデルデータ格納部に格納されるデータの一例を示す図である。 図６４は、フロー表示処理の処理フローを示す図である。 図６５は、図６３に登録されている全プロセスインスタンスを重ね合わせた場合の表示例を示す図である。 図６６は、図６３に登録されているプロセスインスタンスを主要フローと例外フローとに分けた場合の表示例を示す図である。 図６７は、コンピュータ装置の機能ブロック図である。
　図１に、本発明の一実施の形態に係る業務システム分析装置の機能ブロック図を示す。本実施の形態に係る業務システム分析装置は、単数または複数の解析対象システムから収集されたデータ（所定期間において生成されたデータベースのレコード群、ログデータ、ネットワークＤＢ（ＮＤＢ）のレコード群、ジャーナルなど）を格納する分析対象データ格納部１と、分析対象データ格納部１からイベント候補データを生成するイベント候補データ生成部３と、イベント候補データ生成部３により生成されたイベント候補データを格納するイベント候補データ格納部５と、ユーザとのインターフェースとなる入出力部１１と、入出力部１１を介してユーザの指示を受け付けイベントデータを生成するイベントデータ生成部７と、イベントデータ生成部７により生成されたイベントデータを格納するイベントデータ格納部９と、イベントデータ格納部９に格納されているイベントデータからプロセスインスタンスを生成するプロセスインスタンス生成部１３と、プロセスインスタンス生成部１３によって生成されたプロセスインスタンスのデータを格納するプロセスインスタンスデータ格納部１５と、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスのデータを用いて業務の全体像の把握を困難にしている手戻り及び繰り返しを削除する処理を実施する重複解消部１７と、重複解消部１７によって処理されたプロセスインスタンスのデータを格納する簡略化プロセスインスタンスデータ格納部１９と、簡略化プロセスインスタンスデータ格納部に格納されているプロセスインスタンスを種別毎に分類して出現数をカウントするプロセスインスタンス分類処理部２１と、プロセスインスタンス分類処理部２１の処理結果を格納するモデルデータ格納部２３と、モデルデータ格納部２３に格納されているデータを用いて業務フローを表示するために必要な処理を実施するプロセス表示処理部２５とを含む。
　なお、入出力部１１は、イベント候補データ生成部３、プロセスインスタンス生成部１３、プロセス表示処理部２５についても、ユーザとのインターフェースとして動作する。また、各処理部は、処理結果などを読み出して入出力部１１を介してユーザに提示するなどの処理を実施することもある。
　また、イベント候補データ生成部３は、タイムスタンプ処理部３１と、イベントＩＤ・関連ＩＤ候補処理部３２と、イベント名処理部３４と、スコア表格納部３５とを有する。さらに、重複解消部１７は、繰り返し処理部１７１と、手戻り処理部１７３とを有する。
　次に、業務システム分析装置の大まかな処理内容について図２（ａ）乃至（ｄ）を用いて説明する。まず、イベント候補データ生成部３は、分析対象データ格納部１に格納された業務システムについてのデータからイベント候補データを生成する。イベント候補データの一例を図２（ａ）に示す。図２（ａ）の例では、例えば１つのテーブル（例えばデータベース）から、イベント名と、時刻（イベントの発生日時であるタイムスタンプ）と、それ以外の第１の値（値１）と、第２の値（値２）などを含むレコード群が抽出されるようになっている。すなわち、イベント名やタイムスタンプ、それ以外にイベントＩＤや関連ＩＤの候補となるデータ・フィールドが特定される。
　次に、イベントデータ生成部７は、イベント候補データ格納部５に格納されているイベント候補データからイベントデータを生成する。イベントデータの一例を図２（ｂ）に示す。図２（ｂ）の例では、複数のテーブル（例えばデータベース）から、イベント名、時刻（イベントの発生日時であるタイムスタンプ）、イベントＩＤ（ここではＩＤ１）及び他の値を含むレコード群と、イベント名、時刻（タイムスタンプ）、ＩＤ１及びＩＤ２などを含むレコード群とが抽出され、第２のイベントクラス（すなわち、イベントの種類）のレコードの関連ＩＤであるＩＤ２のフィールド値が、第１のイベントクラス（すなわち、イベントの種類）のレコードのイベントＩＤであるＩＤ１のフィールド値のいずれかの値をとることにより、第２のイベントクラスの各々のレコード（すなわちイベントインスタンス）が、第１のイベントクラスのどのレコード（すなわちイベントインスタンス）と関連しているかが特定される。このようなイベント間の関連などを抽出する処理自体は、本実施の形態における主要部ではなく、例えば日本国の特願２００６－１９７２９４号（２００６年７月１９日出願）及びその対応外国出願に開示されており、本願はその内容を取り込む。
　その後、プロセスインスタンス生成部１３は、イベントデータ格納部９に格納されているイベントデータからプロセスインスタンスのデータを生成する。プロセスインスタンスの一例を図２（ｃ）に示す。図２（ｃ）の例では、４つのプロセスインスタンスが例示されており、各々のプロセスインスタンスには、一連のイベントインスタンス（具体的なイベント）が含まれている。すなわち、例えば「受注」「起票」「納品」「検品」といったイベントクラスに属する連続するイベントインスタンス（具体的なイベントであり特定のレコードに対応するイベント）でプロセスインスタンスが構成される。ただし、プロセスインスタンスに含まれるイベントインスタンスは、すべてのイベントクラスに由来する必要はなく、ひとつのイベントクラスに属するイベントインスタンスが複数含まれていても良い。なお、プロセスインスタンス生成処理自体は、本実施の形態における主要部ではなく、例えば、米国特許公開公報２００５／０７６０５９Ａ１のような業務プロセストラッキング方法等を用いることができる。なお、本公報を本願に組み込む。
　そして、プロセスインスタンスのデータを、重複解消部１７及びプロセスインスタンス分類処理部２１によって処理をして、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータからプロセスフロー（業務フローとも呼ぶ）のデータを生成して、入出力部１１を介して表示装置に表示する。プロセスフローの一例を図２（ｄ）に示す。図２（ｄ）の例では、プロセスインスタンスが集約されて特定される業務フローが示されている。
　次に、図１に示した業務システム分析装置の処理の詳細を図３乃至図６６を用いて説明する。まず、ユーザは、業務システムにおける解析対象テーブルの指定を行い、そのデータをコピーして分析対象データ格納部１に格納させる（図３：ステップＳ１）。例えば、受注ＤＢ、生産ＤＢ、手配ＤＢ、配送ＤＢ、品番ＤＢが指定され、所定期間において生成され蓄積されていたレコード群をコピーして、分析対象データ格納部１に格納する。なお、これらのＤＢがリレーショナルデータベースであれば、スキーマ情報をもコピーして、分析対象データ格納部１に格納しておく。本ステップについては、予めユーザがコンピュータを操作して行う処理であるから、図３では点線ブロックで示している。
　例えば受注ＤＢがリレーショナルデータベースである場合には、図４（ａ）のようなスキーマ情報と図４（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図４（ａ）に示したスキーマ情報の例では、フィールド１乃至４のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図４（ａ）から、フィールド１には日時が登録され、フィールド２には主キーである受注番号が登録され、フィールド３には地域が登録され、フィールド４には受注内容が登録されることが分かる。具体的には図４（ｂ）のようなレコード群となるが、図４（ａ）のようなスキーマ情報を得れば、図４（ｂ）のようなレコード群の内容を容易に解釈することができる。
　同様に、生産ＤＢがリレーショナルデータベースである場合には、図５（ａ）のようなスキーマ情報と図５（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図５（ａ）に示したスキーマ情報の例では、フィールド１乃至５のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図５（ａ）から、フィールド１には日時が登録され、フィールド２には主キーである生産番号が登録され、フィールド３には副キーである受注番号が登録され、フィールド４には副キーである品番が登録され、フィールド５には納期が登録されることが分かる。具体的には図５（ｂ）のようなレコード群となるが、図５（ａ）のようなスキーマ情報を得れば、図５（ｂ）のようなレコード群の内容を容易に解釈することができる。
　また、手配ＤＢがリレーショナルデータベースである場合には、図６（ａ）のようなスキーマ情報と図６（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図６（ａ）に示したスキーマ情報の例では、フィールド１乃至５のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図６（ａ）から、フィールド１には日時が登録され、フィールド２には主キーである手配番号が登録され、フィールド３には副キーである受注番号が登録され、フィールド４には副キーである品番が登録され、フィールド５には納品先が登録されることが分かる。具体的には図６（ｂ）のようなレコード群となるが、図６（ａ）のようなスキーマ情報を得れば、図６（ｂ）のようなレコード群の内容を容易に解釈することができる。
　さらに、配送ＤＢがリレーショナルデータベースである場合には、図７（ａ）のようなスキーマ情報と図７（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図７（ａ）に示したスキーマ情報の例では、フィールド１乃至４のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図７（ａ）から、フィールド１には日時が登録され、フィールド２には主キーである手配番号が登録され、フィールド３には副キーである配送便が登録され、フィールド４に納品先が登録されることが分かる。具体的には図７（ｂ）のようなレコード群となるが、図７（ａ）のようなスキーマ情報を得れば、図７（ｂ）のようなレコード群の内容を容易に解釈することができる。
　また、品番ＤＢがリレーショナルデータベースである場合には、図８（ａ）のようなスキーマ情報と図８（ｂ）に示すようなレコード群とが分析対象データ格納部１に格納される。図８（ａ）に示したスキーマ情報の例では、フィールド１及び２のそれぞれについて、フィールド名、キー設定データ、データ型、レコード長及びコメントが登録されるようになっている。図８（ａ）から、フィールド１には主キーである品番が登録され、フィールド２には品名が登録されることが分かる。具体的には図８（ｂ）のようなレコード群となるが、図８（ａ）のようなスキーマ情報を得れば、図８（ｂ）のようなレコード群の内容を容易に解釈することができる。
　一方、受注ＤＢのデータをＣＳＶ形式で取得した場合には、図９（ａ）に示すようなデータが分析対象データ格納部１に格納される。図９（ａ）の例では、日時、受注番号、地域及び受注内容というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図９（ａ）をわかりやすくするためにテーブル形式にすると図９（ｂ）に示すようになる。すなわち、日時の列と、受注番号の列と、地域の列と、受注内容の列とを含むテーブルとなる。スキーマ情報はないので、データは皆文字列として格納される。また、キー設定データはない。
　同様に、生産ＤＢのデータをＣＳＶ形式で取得した場合には、図１０（ａ）に示すようなデータが分析対象データ格納部１に格納される。図１０（ａ）の例では、日時、生産番号、受注番号、品番及び納期というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図１０（ａ）をわかりやすくするためにテーブル形式にすると図１０（ｂ）に示すようになる。すなわち、日時の列と、生産番号の列と、受注番号の列と、品番の列と、納期の列とを含むテーブルとなる。
　また、手配ＤＢのデータをＣＳＶ形式で取得した場合には、図１１（ａ）に示すようなデータが分析対象データ格納部１に格納される。図１１（ａ）の例では、日時、手配番号、受注番号、品番及び納品先というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図１１（ａ）をわかりやすくするためにテーブル形式にすると図１１（ｂ）に示すようになる。すなわち、日時の列と、手配番号の列と、受注番号の列と、品番の列と、納品先の列とを含むテーブルとなる。
　さらに、配送ＤＢのデータをＣＳＶ形式で取得した場合には、図１２（ａ）に示すようなデータが分析対象データ格納部１に格納される。図１２（ａ）の例では、日時、手配番号、配送便及び納品先というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図１２（ａ）をわかりやすくするためにテーブル形式にすると図１２（ｂ）に示すようになる。すなわち、日時の列と、手配番号の列と、配送便の列と、納品先の列とを含むテーブルとなる。
　また、品番ＤＢのデータをＣＳＶ形式で取得した場合には、図１３（ａ）に示すようなデータが分析対象データ格納部１に格納される。図１３（ａ）の例では、品番及び品名というラベルデータが先頭に含まれ、その後は上記ラベルの順番にデータが羅列され、データ間はカンマにて区切られている。図１３（ａ）をわかりやすくするためにテーブル形式にすると図１３（ｂ）に示すようになる。すなわち、品番の列と、品名の列とを含むテーブルとなる。
　業務システム分析装置の例えばイベント候補データ生成部３は、全ての解析対象テーブルについて処理したか判断する（ステップＳ３）。未処理の解析対象テーブルが存在する場合には、未処理の解析対象デーブルを１つ特定する（ステップＳ５）。そして、タイムスタンプ判定処理を実施する（ステップＳ７）。このタイムスタンプ判定処理については図１４及び図１５を用いて説明する。
　まず、イベント候補データ生成部３のタイムスタンプ処理部３１は、分析対象データ格納部１を参照して、解析対象テーブルにおいて未処理のフィールドを１つ特定する（図１４：ステップＳ３１）。そして、分析対象データ格納部１において解析対象テーブルのスキーマ情報が使用可能となっているか判断する（ステップＳ３３）。
　スキーマ情報が使用可能となっている場合には、スキーマ情報において処理対象フィールドについてのデータ部分を特定し、その中で処理対象フィールドのデータ型がタイムスタンプ型であるか判断する（ステップＳ３５）。処理対象フィールのデータ型がタイムスタンプ型ではない場合にはステップＳ３９に移行する。例えば、図９（ａ）乃至図１３（ａ）のようなデータを処理する場合にはスキーマ情報はないので、ステップＳ３９に移行する。
　一方、処理対象フィールドのデータ型がタイムスタンプ型であると判断された場合には、処理対象フィールドのタイムスタンプ判定を「確定」と設定し、例えばメインメモリなどの記憶装置に格納する（ステップＳ３７）。そして、処理はステップＳ４３に移行する。
　例えば、図４（ａ）のようなスキーマ情報の場合、フィールド１のデータ型がタイムスタンプ型であるので、フィールド１が処理対象フィールドであれば、タイムスタンプ判定＝「確定」と設定される。図５（ａ）のようなスキーマ情報の場合、フィールド１のデータ型がタイムスタンプ型であるので、フィールド１が処理対象フィールドであれば、タイムスタンプ判定＝「確定」と設定される。図６（ａ）及び図７（ａ）についても同様である。図８（ａ）の場合には、全フィールドについて、ステップＳ３５からステップＳ３９に移行する。
　ステップＳ３３でスキーマ情報が使用不能と判断された場合又は処理対象フィールドのデータ型がタイムスタンプ型でない場合、スコア表格納部３５に格納されているタイムスタンプ確度スコア表を参照して、スキーマ情報における処理対象フィールドの該当データ部分、処理対象フィールドのフィールド名を表すラベルデータ、及び処理対象フィールドのフィールド値から確度を特定する（ステップＳ３９）。
　タイムスタンプ確度スコア表の一例を図１５に示す。図１５の例では、「フィールドのデータ型が可変長文字列」であれば確度スコアは１（％）と設定され、「フィールドのデータ型が実数」であれば確度スコアは５（％）と設定され、フィールド名の末尾が「時刻」「時間」などであれば確度スコアは９０（％）と設定され、フィールド名の末尾が「月日」「日」などであって時刻などが含まれない場合であれば確度スコアは７０（％）と設定され、フィールド名に「予定」「納期」など将来の時期を指定する場合であれば確度スコアは１０（％）と設定され、フィールド値の文字列に年号（記号）、「／」「：」「’」「．」「－」、数字、空白といった時間に関連する文字以外の文字が含まれている場合には確度スコアは５（％）と設定され、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ　ｈｈ：ｍｍ：ｓｓ」の形式であれば確度スコアは９０（％）と設定され、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ」の形式であれば確度スコアは７０（％）と設定され、フィールド値に同一となるものが含まれていれば確度スコアは３０（％）と設定され、該当する項目がなければ確度スコアは５０（％）と設定される。
　例えば、図４（ａ）のようなスキーマ情報で図４（ｂ）のようなレコード群の場合、フィールド２については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。フィールド３についても同様に、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。さらに、フィールド４については、データ型が可変長文字列であるので、確度スコア１（％）と特定される。なお、フィールド４については、フィールド値に時間に関連する文字以外の文字も含まれているので、タイムスタンプ確度スコア表において複数項目に該当しているが、本実施の形態では、５０（％）という中央値からより乖離した値の方を採用する。すなわち、フィールド値に時間に関連する文字以外の文字が含まれている場合の確度スコア５（％）よりも１（％）を採用する。
　一方、スキーマ情報が存在しない図９（ａ）の場合には、フィールド１については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ　ｈｈ：ｍｍ：ｓｓ」の形式であるので、確度スコア９０（％）と特定される。フィールド２及び３については同様であるが、フィールド４については、当該フィールドのデータ型が特定できないので、フィールド値に時間に関連する文字以外の文字が含まれている場合に該当すると判断され、確度スコア５（％）と特定される。
　また、図５（ａ）のようなスキーマ情報で図５（ｂ）のようなレコード群の場合にも、フィールド２乃至４については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。フィールド５については、フィールド名の文字列に「納期」が含まれているので、確度スコア１０（％）と特定される。なお、フィールド５については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ」の形式であるので、タイムスタンプ確度スコア表において複数項目に該当しているが、本実施の形態では、５０（％）という中央値からより乖離した値の方を採用する。すなわち、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ」の形式である場合の確度スコア７０（％）よりも１０（％）を採用する。スキーマ情報が存在しない図１０（ａ）の場合には、フィールド１については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ　ｈｈ：ｍｍ：ｓｓ」の形式であるので、確度スコア９０（％）と特定される。フィールド２及び５については、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。
　さらに、図６（ａ）のようなスキーマ情報で図６（ｂ）のようなレコード群の場合、フィールド２乃至５については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定される。スキーマ情報が存在しない図１１（ａ）の場合には、フィールド１については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ　ｈｈ：ｍｍ：ｓｓ」の形式であるので、確度スコア９０（％）と特定される。フィールド２及び５については、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。
　また、図７（ａ）のようなスキーマ情報で図７（ｂ）のようなレコード群の場合、フィールド２乃至４については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定と特定される。スキーマ情報が存在しない図１２（ａ）の場合は、フィールド１については、フィールド値の文字列が「ＹＹＹＹ／ＭＭ／ＤＤ　ｈｈ：ｍｍ：ｓｓ」の形式であるので、確度スコア９０（％）と特定される。フィールド２及び４については、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。
　さらに、図８（ａ）のようなスキーマ情報で図８（ｂ）のようなレコード群の場合、フィールド１及び２については、フィールド値に時間に関連する文字以外の文字が含まれているとして確度スコア５（％）と特定と特定される。スキーマ情報が存在しない図１３（ａ）の場合も、データ型が関係しないので、スキーマ情報が存在する場合と同様の結果が得られる。
　図１４の説明に戻って、処理対象フィールドのタイムスタンプ判定を特定された確度スコアに設定する（ステップＳ４１）。上で述べた数値が特定される。
　そして、処理対象テーブルにおいて全てのフィールドについて処理したか判断する（ステップＳ４３）。未処理のフィールドが存在する場合にはステップＳ３１に戻る。一方、全てのフィールドを処理した場合には元の処理に戻る。
　このように、イベントのタイムスタンプとして蓋然性の高いフィールドに高い値の確度スコアが設定される。また、データ型からタイムスタンプであることが明らかであれば「確定」という蓋然性を表すデータが設定される。
　図３の説明に戻って、次に、イベント候補データ生成部３のイベントＩＤ・関連ＩＤ候補処理部３２は、イベントＩＤ及び関連ＩＤ候補判定処理を実施する（ステップＳ９）。このイベントＩＤ及び関連ＩＤ候補判定処理については、図１６及び図１７を用いて説明する。
　イベントＩＤ・関連ＩＤ候補処理部３２は、分析対象データ格納部１に格納されている解析対象テーブルのうち未処理のフィールドを１つ特定する（ステップＳ５１）。そして、分析対象データ格納部１に格納されている、処理対象フィールドのフィールド値が、全レコードで一意となっているか判断する（ステップＳ５３）。処理対象フィールドのフィールド値が、全レコードで一意となっていない、すなわち値が重複しているレコードが存在する場合には、ステップＳ６２に移行する。
　イベントＩＤはイベントの識別子の格納フィールドであるので、そのフィールド値が互いに重複することはない。したがって、イベントＩＤのフィールドに重複する値が存在すれば、それはイベントＩＤではないと判断できるためである。
　一方、処理対象フィールドのフィールド値が、全レコードで一意である場合には、分析対象データ格納部１に格納されている、処理対象フィールドのフィールド値にＮＵＬＬが含まれているか判断する（ステップＳ５５）。処理対象フィールドのフィールド値にＮＵＬＬが含まれている場合には、ステップＳ６２に移行する。イベントＩＤはイベントの識別子の格納フィールドであるので、そのフィールド値がＮＵＬＬということはあり得ないためである。処理対象フィールドのフィールド値が全レコードで一意とは言えない場合、又は処理対象フィールドのフィールド値にＮＵＬＬを含む場合、分析対象データ格納部１に格納されている、処理対象フィールドのフィールド値が、ＮＵＬＬを除いて２以上あるか判断する（ステップＳ６２）。処理対象フィールドのフィールド値が、ＮＵＬＬを除いて２種類以上ない場合には、イベントＩＤ・関連ＩＤ候補判定に「否定」を設定し、例えばメインメモリなどの記憶装置に格納する（ステップＳ６３）。そして処理はステップＳ６１に移行する。関連ＩＤはイベントから他のイベントのどれに対応しているかを表す値であるので、そのフィールド値がＮＵＬＬを除き２以上の値を有しない場合は、意味がある結果が得られないためである。
　例えば図４（ｂ）や図９（ｂ）のようなテーブルの場合、フィールド１とフィールド２とフィールド４とについては、フィールド値に重複が存在せず、フィールド３ついてはフィールド値に重複が存在するが、ＮＵＬＬ以外の２種類以上の値をとるので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。
　また図５（ｂ）や図１０（ｂ）のようなテーブルの場合、フィールド１とフィールド２については、フィールド値に重複が存在せず、フィールド３乃至５については重複が存在するが、ＮＵＬＬ以外の２種類以上の値をとるので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。
　さらに図６（ｂ）や図１１（ｂ）のようなテーブルの場合、フィールド１とフィールド２については、フィールド値に重複が存在せず、フィールド３乃至５については重複が存在するが、ＮＵＬＬ以外の２種類以上の値をとるので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。
　また図７（ｂ）や図１２（ｂ）のようなテーブルの場合、フィールド１とフィールド２については、フィールド値に重複が存在せず、フィールド３及び４については重複が存在するが、ＮＵＬＬ以外の２種類以上の値をとるので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。
　さらに図８（ｂ）や図１３（ｂ）のようなテーブルの場合、フィールド１とフィールド２について、フィールド値に重複が存在しないので、イベントＩＤ・関連ＩＤ候補判定に「否定」は設定されない。
　ステップＳ５５において処理対象フィールドのフィールド値にＮＵＬＬが含まれていないと判断された場合、又はステップＳ６２において処理対象フィールドのフィールド値が、ＮＵＬＬを除いて２種類以上値を有すると判断された場合には、スコア表格納部３５に格納されているイベントＩＤ・関連ＩＤ候補確度スコア表を参照して、スキーマ情報における処理対象フィールドの該当データ部分、処理対象フィールドのフィールド名を表すラベルデータ、及び処理対象フィールドのフィールド値から確度を特定する（ステップＳ５７）。但し、イベントＩＤ・関連ＩＤ候補確度スコア表に該当項目が存在しない場合には、確度スコア５０（％）が特定されるものとする。
　イベントＩＤ・関連ＩＤ候補確度スコア表の一例を図１７に示す。図１７の例では、フィールドのデータ型が可変長文字列であれば確度スコアは１（％）と設定され、フィールドのデータ型が実数であれば確度スコアは５（％）と設定され、フィールドのデータ型が整数であれば確度スコアは８０（％）と設定され、フィールドのデータ型が固定長文字列であれば確度スコアは７０（％）と設定され、フィールドのデータ型がタイムスタンプ又は日付であれば確度スコアは１０（％）と設定され、フィールド名が主キー指定されていれば確度スコアは８０（％）と設定される。フィールド値又はフィールド名の文字列についての項目はここでは定義されていないが、定義されることもある。フィールド値についての項目が定義される場合にはステップＳ５７で参照される。
　例えば図４（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型がタイムスタンプであるので確度スコア１０（％）と特定され、フィールド２についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド３についてはデータ型が固定長文字列であるので確度スコア７０（％）と特定され、フィールド４についてはデータ型が可変長文字列であるので確度スコア１（％）と特定される。図９（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１乃至フィールド４について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。
　例えば図５（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型がタイムスタンプであるので確度スコア１０（％）と特定され、フィールド２についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド３乃至フィールド４についてはデータ型が固定長文字列であるので確度スコア７０（％）が特定され、フィールド５についてはデータ型が日付となっているので確度スコア１０（％）が特定される。図１０（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１乃至フィールド５について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。
　例えば図６（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型がタイムスタンプであるので確度スコア１０（％）と特定され、フィールド２についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド３乃至フィールド５についてはデータ型が固定長文字列であるので確度スコア７０（％）が特定される。図１１（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１及乃至フィールド５について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。
　例えば図７（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型がタイムスタンプであるので確度スコア１０（％）と特定され、フィールド２についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド３乃至フィールド４についてはデータ型が固定長文字列であるので確度スコア７０（％）が特定される。図１２（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１乃至フィールド４について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。
　例えば図８（ａ）のようなスキーマ情報の場合、フィールド１についてはデータ型が固定長文字列であって且つ主キー指定されているので５０％からの乖離の大きい確度スコア８０（％）が採用され、フィールド２についてはデータ型が固定長文字列であるので確度スコア７０（％）が採用される。図１３（ａ）のようなスキーマ情報が存在しない例の場合、フィールド１及び２について、イベントＩＤ・関連ＩＤ候補確度スコア表には該当項目が存在しないので確度スコア５０（％）が特定される。
　そして、イベントＩＤ・関連ＩＤ候補処理部３２は、イベントＩＤ・関連ＩＤ候補判定に、ステップＳ５７で特定された確度スコアを設定して、例えばメインメモリなどの記憶装置に格納する（ステップＳ５９）。
　その後、処理対象テーブルにおいて全てのフィールドについて処理したか判断し（ステップＳ６１）、未処理のフィールドが存在する場合にはステップＳ５１に戻る。一方、全てのフィールドについて処理した場合には元の処理に戻る。
　このようにすれば、イベントＩＤ又は関連ＩＤの蓋然性が高いものについては高い確度スコアが特定されるようになる。また、イベントＩＤ又は関連ＩＤの可能性が完全にないものについては「否定」という蓋然性を表すデータが特定される。
　図３の説明に戻って、次に、イベント候補データ生成部３のイベント名処理部３４は、イベント名判定処理を実施する（ステップＳ１３）。このイベント名判定処理については、図１８乃至図２０を用いて説明する。
　まず、イベント名処理部３４は、タイムスタンプ判定処理の処理結果として所定の確度スコア以上でタイムスタンプのフィールドとしてみなすことができるフィールドの数をカウントする（ステップＳ９１）。例えば確度スコア７０（％）以上などの閾値を設定する。当然ながら「確定」と特定されているフィールドはタイムスタンプのフィールドである。上で述べた例では、品番ＤＢを除き、フィールド名が日時であるフィールドがタイムスタンプのフィールドと判断され、フィールド数は「１」となる。品番ＤＢでは、タイムスタンプとみなすことができるフィールドはないので、フィールド数は「０」となる。
　そして、タイムスタンプのフィールド数が０であるか判断する（ステップＳ９３）。フィールド数が０であれば、解析対象テーブルを以下の処理の対象外として設定する（ステップＳ９５）。タイムスタンプがないテーブル（例えば品番ＤＢ）は、業務プロセス中に発生するイベントに対応しているテーブルではないと判断される。そして元の処理に戻る。
　一方、タイムスタンプのフィールド数が０ではない場合には、フィールド数が１であるか判断する（ステップＳ９７）。タイムスタンプのフィールド数が１であれば、イベント名にテーブル名を設定し、例えばメインメモリなどの記憶装置に格納する（ステップＳ９９）。上の例では、受注ＤＢであれば、イベント名は「受注」と特定され、生産ＤＢであれば、イベント名は「生産」と特定され、手配ＤＢであれば、イベント名は「手配」と特定され、配送ＤＢであれば、イベント名は「配送」と特定される。そして元の処理に戻る。
　また、タイムスタンプのフィールド数が複数である場合には、タイムスタンプとみなされたフィールドのフィールド名をイベント名に設定し、例えばメインメモリなどの記憶装置に格納する（ステップＳ１０１）。そして元の処理に戻る。
　例えば図１９のようなテーブルが処理対象テーブルである場合にステップＳ１０１が実行される。図１９の例では、起票日時、承認日時、発注日時、納品日時、検収日時がそれぞれイベントのタイムスタンプとみなされるフィールドとなり、１レコードにイベントが複数記録される形式となっている。このようなテーブルは、図２０（ａ）乃至（ｅ）に示したような起票テーブル、承認テーブル、発注テーブル、納品テーブル及び検収テーブルという複数テーブルとして扱うことができる。従って、このような場合には、「起票」「承認」「発注」「納品」「検収」がそれぞれイベント名として特定される。
　以上のような処理を実施することによって、業務プロセス中に発生するイベントに対応しているテーブルを特定すると共に、イベント名を抽出することができるようになる。
　図３の説明に戻って、次に、イベント候補データ生成部３は、判定結果を入出力部１１を介してユーザに提示する（ステップＳ１５）。例えば、図４（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の受注ＤＢの場合には、図２１に示すようなデータがユーザに提示される。図２１の例では、日時フィールド、受注番号フィールド、地域フィールド、受注内容フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、受注番号フィールド及び地域フィールドがイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。
　また、図９（ａ）に示したＣＳＶ形式の受注ＤＢの場合には、図２２に示すようなデータがユーザに提示される。図２２の例では、日時フィールド、受注番号フィールド、地域フィールド、受注内容フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。
　例えば、図５（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の生産ＤＢの場合には、図２３に示すようなデータがユーザに提示される。図２３の例では、日時フィールド、生産番号フィールド、受注番号フィールド、品番フィールド、納期フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、生産番号フィールドと受注番号フィールドと品番フィールドがイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。
　また、図１０（ａ）に示したＣＳＶ形式の生産ＤＢの場合には、図２４に示すようなデータがユーザに提示される。図２４の例では、日時フィールド、生産番号フィールド、受注番号フィールド、品番フィールド、納期フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。
　例えば、図６（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の手配ＤＢの場合には、図２５に示すようなデータがユーザに提示される。図２５の例では、日時フィールド、手配番号フィールド、受注番号フィールド、品番フィールド、納品先フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、手配番号フィールドと受注番号フィールドと品番フィールドと納品先フィールドがイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。
　また、図１１（ａ）に示したＣＳＶ形式の手配ＤＢの場合には、図２６に示すようなデータがユーザに提示される。図２６の例では、日時フィールド、手配番号フィールド、受注番号フィールド、品番フィールド、納品先フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。
　例えば、図７（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の配送ＤＢの場合には、図２７に示すようなデータがユーザに提示される。図２７の例では、日時フィールド、手配番号フィールド、配送便フィールド、納品先フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプのフィールドで「確定」となっており、手配番号フィールドと配送便フィールドと納品先フィールドがイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。
　また、図１２（ａ）に示したＣＳＶ形式の配送ＤＢの場合には、図２８に示すようなデータがユーザに提示される。図２８の例では、日時フィールド、手配番号フィールド、配送便フィールド、納品先フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、イベント名についてはテーブル名がイベント名とされるので、全て「否定」とされている。これを見れば、日時フィールドがタイムスタンプの可能性が高く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。
　例えば、図８（ａ）及び（ｂ）に示したようなリレーショナルデータベース形式の品番ＤＢの場合には、図２９に示すようなデータがユーザに提示される。図２９の例では、品番フィールド、品名フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、品番ＤＢはタイムスタンプがないと判断され、以降の処理対象外とされているため、イベント名については全て「否定」とされている。これを見れば、タイムスタンプのフィールドが存在する可能性が非常に低く、品番フィールドと品名フィールドはイベントＩＤまたは関連ＩＤの可能性が高いことが分かる。
　また、図１３（ａ）に示したＣＳＶ形式の品番ＤＢの場合には、図３０に示すようなデータがユーザに提示される。図３０の例では、品番フィールド、品名フィールドのそれぞれにつき、ステップＳ７乃至Ｓ１３の判定結果が提示されている。なお、品番ＤＢはタイムスタンプがないと判断され、以降の処理対象外とされているため、イベント名については全て「否定」とされている。これを見れば、タイムスタンプのフィールドが存在する可能性は非常に低く、イベントＩＤまたは関連ＩＤである可能性はいずれのフィールドも同等であることが分かる。
　図３の説明に戻って、ステップＳ１５が終了すると、ユーザは、入出力部１１を介して、イベント名、タイムスタンプ、イベントＩＤ・関連ＩＤ候補などについて修正入力又は確定入力を行い、レコードのコピーなどを行って又は命じて、イベント候補データを生成し、イベント候補データ生成部３にイベント候補データ格納部５へ格納させる（ステップＳ１６）。この作業は主に又は一部ユーザによって実施されるので、図３では点線ブロックで描かれている。そして処理はステップＳ３に戻る。
　例えば図２１の判定結果に従って、図３１に示すようにイベント名についてはテーブル名である「受注」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については受注番号フィールド及び地域フィールドを確定させる場合、例えば図３２に示すようなデータが、イベント候補データ格納部５に格納される。図３２に示す例では、イベント名「受注」が全てのレコードに付加され、日時フィールドのフィールド値の全レコード分がタイムスタンプのフィールドにコピーされ、受注番号フィールド及び地域フィールドがイベントＩＤ・関連ＩＤ候補として、フィールド名とフィールド値の全レコード分がコピーされる。
　例えば図２２の判定結果に従って、イベント名についてはテーブル名である「受注」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については受注番号フィールド及び地域フィールド及び受注内容フィールドを確定させる場合、例えば図３３のようなデータが、イベント候補データ格納部５に格納される。
　さらに例えば図２３の判定結果に従って、イベント名についてはテーブル名である「生産」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については生産番号フィールド及び受注番号フィールド及び品番フィールドを確定させる場合、例えば図３４のようなデータが、イベント候補データ格納部５に格納される。
　また例えば図２４の判定結果に従って、イベント名についてはテーブル名である「生産」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については生産番号フィールド及び受注番号フィールド及び品番フィールド及び納期フィールドを確定させる場合、例えば図３５のようなデータが、イベント候補データ格納部５に格納される。
　さらに例えば図２５の判定結果に従って、イベント名についてはテーブル名である「手配」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については手配番号フィールド及び受注番号フィールド及び品番フィールド及び納品先フィールドを確定させる場合、例えば図３６のようなデータが、イベント候補データ格納部５に格納される。
　また例えば図２６の判定結果に従って、イベント名についてはテーブル名である「手配」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については手配番号フィールド及び受注番号フィールド及び品番フィールド及び納品先フィールドを確定させる場合、例えば図３７のようなデータが、イベント候補データ格納部５に格納される。
　さらに例えば図２７の判定結果に従って、イベント名についてはテーブル名である「配送」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については手配番号フィールド及び配送便フィールド及び納品先フィールドを確定させる場合、例えば図３８のようなデータが、イベント候補データ格納部５に格納される。
　また例えば図２８の判定結果に従って、イベント名についてはテーブル名である「配送」を確定させ、タイムスタンプについては日時フィールドを確定させ、イベントＩＤ・関連ＩＤ候補については手配番号フィールド及び配送便フィールド及び納品先フィールドを確定させる場合、例えば図３９のようなデータが、イベント候補データ格納部５に格納される。
　また、例えば図１９のようなテーブル内に複数のタイムスタンプのフィールドが存在するようなテーブルを処理対象とする場合は、例えば図４０乃至図４４に示すようなデータが、イベント候補データ格納部５に格納される。図４０乃至図４４に示す例では、タイムスタンプとして確定されたフィールドである起票日時、承認日時、発注日時、納品日時、検収日時を元に、それらのフィールド毎に、各々イベント名を「起票」、「承認」、「発注」、「納品」、「検収」と確定させたイベント候補データを作成する。タイムスタンプについては、起票日時フィールド、承認日時フィールド、発注日時フィールド、納品日時フィールド、検収日時フィールドのフィールド値の全レコード分が各々のイベント候補データのタイムスタンプのフィールドにコピーされる。さらに、全てのイベント候補データ共通に、起票日時フィールド、承認日時フィールド、発注日時フィールド、納品日時フィールド、検収日時フィールド以外のフィールドが、イベントＩＤ・関連ＩＤ候補として、フィールド名とフィールド値の全レコード分がコピーされる。
　このようにして以下の処理で用いるイベント候補データがイベント候補データ格納部５に格納されるようになる。
　ステップＳ３で全ての解析対象テーブルを処理したと判断された場合には、イベントデータ生成部７は、イベント候補データ格納部５に格納されているイベント候補データを用いて、イベントデータ生成処理を実施し、処理結果をイベントデータ格納部９に格納する（ステップＳ１７）。
　受注イベント、生産イベント、手配イベント、配送イベントに対応して、各々、図３２、図３４、図３６、図３８に示されたイベント候補データのセット、または、各々、図３３、図３５、図３７、図３９に示されたイベント候補データのセットを用いて生成したイベントデータの例を図４５に示す。その生成方法としては、上で述べた日本国の特願２００６－１９７２９４記載のようなイベントデータの関連情報の自動抽出方式を用いても良いし、人手によって、各イベント候補データのイベントＩＤ・関連ＩＤ候補のフィールド値の対応関係を調査・分析することによって、イベント間の関連性を確定しても良い。
　図４５では、受注イベントのイベントＩＤは受注番号であり、生産イベントのイベントＩＤは生産番号、関連ＩＤは受注番号であり、手配イベントのイベントＩＤは手配番号、関連ＩＤは受注番号であり、配送イベントのイベントＩＤは手配番号、関連ＩＤは配送便であることが確定されている。また、生産イベントの関連ＩＤのフィールド値が、受注イベントのイベントＩＤのフィールド値のどれかの値をとることにより、生産イベントの各々のレコード（すなわち、イベントインスタンス）が、受注イベントのどのレコード（すなわち、イベントインスタンス）と関連しているかが特定されるというイベント間の関連性が確定されている。同様の関連性が、手配イベントの関連ＩＤと受注イベントのイベントＩＤとの間、配送イベントのイベントＩＤと手配イベントのイベントＩＤとの間に確定されている。
　また、プロセスインスタンス生成部１３は、イベントデータ格納部９に格納されているイベントデータを用いてプロセスインスタンス生成処理を実施し、処理結果をプロセスインスタンスデータ格納部１５に格納する（ステップＳ１９）。その生成方法としては、米国特許公開公報２００５／０７６０５９Ａ１のような業務プロセストラッキング方法等を用いることができる。
　図４５のイベントデータを用いて、受注番号：ＪＴ０１の受注イベントインスタンスを起点とするプロセスインスタンスを生成する処理過程の概略説明を図４６に示す。最初に、関連ＩＤのフィールド値として、受注イベントのイベントＩＤである受注番号のフィールド値：ＪＴ０１をとるレコード（すなわち、イベントインスタンス）として、生産イベントから２つ、手配イベントから３つのイベントインスタンスが確定される。次に、関連ＩＤのフィールド値として、確定された手配イベントのイベントＩＤである手配番号：ＴＨ０１，ＴＨ０２，ＴＨ０３を関連ＩＤのフィールド値としてとるレコード（すなわち、イベントインスタンス）として、配送イベントから３つのイベントインスタンスが確定される。最後に、確定された、受注番号：ＪＴ０１の受注イベントインスタンスを起点として、直接・間接的に関連性をもつイベントインスタンスを、そのタイムスタンプの値に基いて時間経過の順につなぎ合わせることによって、プロセスインスタンスが生成される。すなわち、第１のプロセスインスタンスとしては、受注、生産、手配、手配、手配、配送、生産、配送、配送というイベントインスタンスが時系列に並べられたプロセスインスタンスが生成される。
　同様にして、図４５のイベントデータを用いて生成した全プロセスインスタンスを図４７に示す。第２のプロセスインスタンスは、受注、手配及び配送というイベントインスタンスが時系列に並べられたプロセスインスタンスである。第３のプロセスインスタンスは、受注、生産、生産、手配及び配送というイベントインスタンスが時系列に並べられたプロセスインスタンスである。さらに、第４のプロセスインスタンスは、受注、手配及び配送というイベントインスタンスが時系列に並べられたプロセスインスタンスである。
　図３の処理フローの説明に戻って、次に、重複解消部１７は、プロセスインスタンスデータ格納部１５に格納されているプロセスインスタンスのデータを用いて、重複解消処理を実施する（ステップＳ２１）。この処理については、図４８乃至図６２を用いて詳細に説明する。
　まず、図４８乃至図５２を用いて重複解消処理を実施する趣旨について説明する。まず、図４８に示すように、プロセスインスタンスデータ格納部１５に１０個のプロセスインスタンスが格納されているものとする。ここで、Initial State、契約、伝票作成、請求、回収、契約満了及びFinal Stateというイベントインスタンスを含むプロセスインスタンスが５つ作成されてグループＡが構成される。また、Initial State、契約、伝票作成、請求及び回収の後に契約更新を介して伝票作成に戻って請求及び回収を実施（手戻り）した後さらに契約満了及びFinal Stateに移行するというプロセスインスタンスが３つ作成されてグループＢが構成される。さらに、Initial State、契約、伝票作成、請求及び回収の後に継続を介して請求に戻って回収を実施（手戻り）して契約満了及びFinal Stateに移行するというプロセスインスタンスが１つ作成されてグループＣが構成される。そして、Initial State、契約、伝票作成、請求及び回収の後に再度回収が実施（繰返し）されて契約満了及びFinal Stateに移行するというプロセスインスタンスが１つ作成されてグループＤが構成される。
　このようなプロセスインスタンスが生成されて、単純にグループＡ乃至Ｄのプロセスインスタンスを重ね合わせると、図４９に示すような全体フローが生成される。図４９の全体フローでは、グループＡのプロセスインスタンスをメインフローとして実線で示しており、グループＢ、Ｃ及びＤで含まれる、手戻りの経由イベントインスタンス及び手戻り遷移並びに繰り返し遷移を説明上見やすくするため、点線で示している。
　また、例えばグループの出現頻度の全体に対して占める比率２０％を閾値として、主要フローと例外フローとを分ける場合には、図５０（ａ）に示すように、主要フローとしては、グループＡとグループＢのプロセスインスタンスが重ね合わされたフローが生成され、ユーザに提示される。これに対して、例外フローは、図５０（ｂ）に示すグループＣのプロセスインスタンス（但し、説明上見やすくするため、手戻り部分の経由イベントインスタンス及び遷移については点線で示されている）、図５０（ｃ）に示すグループＤのプロセスインスタンス（但し、説明上見やすくするため、繰り返しを表す遷移については点線で示されている）がユーザに提示される。
　このような図４８のようなプロセスインスタンスのような場合には、主要フローと例外フローを分ける上で問題はあまりなく、ユーザは、図４９や図５０に示したような図で、業務フローの概況を容易に把握できるようになる。グループＡだけでも５０％の出現頻度を占めるため、グループＡのみを主要フローとして認めても、図５０と同様に、業務フローの概況を把握する上で特別に問題はない。
　一方、図５１に示すようなプロセスインスタンスが生成された場合には、図４８のような場合とは異なり、問題が生ずる。図５１の例では、Initial State、契約、伝票作成、請求、回収、契約満了及びFinal Stateという流れと基本として、回収というイベントインスタンスが１回繰り返されるプロセスインスタンスが２つと、回収というイベントインスタンスが２回繰り返されるプロセスインスタンスが１つと、回収というイベントインスタンスが３回繰り返されるプロセスインスタンスが１つと、回収というイベントインスタンスが４回繰り返されるプロセスインスタンスが１つと、回収というイベントインスタンスが５回繰り返されるプロセスインスタンスが１つ生成されている。残りのプロセスインスタンスについても、Initial State、契約、伝票作成、請求、回収、契約満了及びFinal Stateという流れと基本として、契約更新という経由イベントインスタンスを介して伝票作成、請求及び回収を１回繰り返す手戻りを行うプロセスインスタンスが１つと、契約更新という経由イベントインスタンスを介して伝票作成、請求及び回収を２回繰り返す手戻りを行うプロセスインスタンスが１つと、契約更新という経由イベントインスタンスを介して伝票作成、請求及び回収を３回繰り返す手戻りを行うプロセスインスタンスが１つ生成されている。さらに、Initial State、契約、伝票作成、請求、回収、契約満了及びFinal Stateという流れと基本として、継続という経由イベントインスタンスを介して請求及び回収を１回繰り返す手戻りを行うプロセスインスタンスも１つ生成されている。
　このように、手戻り回数が異なるだけのプロセスインスタンスが複数種類、また繰り返しの回数が異なるだけのプロセスインスタンスが複数種類生成されて、単純に分類を行うと、同じグループであると判断されるプロセスインスタンスは、非常に少なくなる。図５１の例では、回収というイベントインスタンスが１回繰り返されるプロセスインスタンスのみが２つあるのでグループとしても、その出現頻度はたったの２０％で、図５２に示すようにその他を例外フローとすると、８つも例外フローが生じてしまい、業務フローの概要を把握する上では、例外フローの意味づけが曖昧になってしまう。
　そこで、図５３乃至図６２に示すような処理を実施することによって、業務の全体像の把握を困難にしている手戻り及び繰り返しをプロセスインスタンスから削除することによって、プロセスインスタンスのグルーピングを容易にして、ユーザが業務フローの概要を容易に把握できるようにする。
　重複解消部１７は、プロセスインスタンスデータ格納部１５において未処理のプロセスインスタンスを１つ特定する（図５２：ステップＳ１１１）。そして、特定されたプロセスインスタンスについて、繰り返しの有無及び手戻りの有無を検査する（ステップＳ１１３）。特定のイベントインスタンスより前に実施された他のイベントインスタンスに、経由イベントインスタンスを介して又は介さずに戻るような遷移を手戻りとして特定し、同じイベントインスタンスに戻るような遷移を繰り返しとして特定する。１つのプロセスインスタンスに、繰り返しと手戻りが含まれている場合もあり、さらに複数箇所、繰り返し又は手戻りが含まれる場合もある。
　そして、重複解消部１７の繰り返し処理部１７１は、特定されたプロセスインスタンスについて全ての繰り返し箇所を処理したか判断する（ステップＳ１１５）。未処理の繰り返し箇所が存在する場合、繰り返し処理部１７１は、未処理の繰り返し箇所を特定し（ステップＳ１１７）、特定された繰り返し箇所において繰り返しを１回分のみ残し、残りを削除する（ステップＳ１１９）。そしてステップＳ１１５に戻る。
　例えば図５４Ａに示すようなプロセスインスタンスの場合、伝票作成において繰り返し４００１が３回、請求において繰り返し４００２が１回、請求開始において繰り返し４００３が４回生じているが、それぞれについて１回分のみが残るように重複する余剰繰り返しを削除する。そうすると、図５４Ｂに示すように、伝票作成における繰り返し４００１’は１回になり、請求における繰り返し４００２’は１回のままとなり、請求開始において繰り返し４００３’は１回になる。
　図５３の処理の説明に戻って、全ての繰り返し箇所を処理した場合又は全く繰り返しが存在していない場合には、手戻り処理部１７３は、全ての手戻り箇所を処理したか判断する（ステップＳ１２１）。未処理の手戻り箇所が存在する場合には、手戻り処理部１７３は、未処理の手戻り箇所を１つ特定する（ステップＳ１２３）。そして、手戻り重複解消処理を実施する（ステップＳ１２５）。手戻り重複解消処理については、図５５乃至図５８Ｂを用いて説明する。
　まず、手戻り処理部１７３は、特定された手戻り箇所における手戻り部分を切り出す（ステップＳ１３１）。ここで例えば図５６に示すようなプロセスインスタンスを処理する場合を想定する。具体的には、このプロセスインスタンスでは、Initial State、契約、伝票作成、請求、契約更新、請求開始まで進んだ後、請求まで戻り、契約更新、請求開始まで進んだ後、さらに伝票作成まで戻り、さらに請求、契約更新、請求開始まで進んだ後、また請求まで戻り、さらに契約更新、請求開始と進んで、請求終了、Final Stateへ進む。ステップＳ１３１では、図５７に示すように、請求まで戻る第１の手戻り部分と、伝票作成まで戻る第２の手戻り部分と、請求まで戻る第３の手戻り部分とを切り出す。
　そして、手戻り処理部１７３は、手戻り部分のパターンを分類する（ステップＳ１３３）。図５８Ａに示したように切り出された３つの手戻り部分は、請求、契約更新及び請求開始までの２つの手戻り部分がパターン１として特定され、伝票作成、請求、契約更新及び請求開始までの１つの手戻り部分がパターン２として特定される。
　そして、手戻り処理部１７３は、パターン毎に重複解消、すなわち各パターンにつき１つの手戻りを残し、残余の手戻りを削除する（ステップＳ１３５）。図５８Ａのような２つのパターンが存在する場合には、図５８Ｂに示すように、各パターンに１つの手戻りのみに統合される。
　その後、手戻り処理部１７３は、プロセスインスタンスを再構築して、簡略化プロセスインスタンスデータ格納部１９に格納する（ステップＳ１３７）。図５８Ｂのような場合には、図５９に示すように、パターン１及び２の手戻り部分を連続して発生するイベントインスタンスとして連結して、Initial State、契約、伝票作成、請求、契約更新、請求開始、請求、契約更新、請求開始、伝票作成、請求、契約更新、請求開始、請求終了、Final Stateというような順番でイベントインスタンスが発生するプロセスインスタンスが構築される。
　図５６の初期状態のプロセスインスタンスを、同一イベントインスタンスを重ね合わせて表示する場合、図６０のように複雑に遷移が入り組む形になるが、上で述べたような処理を実施すれば、図６１に示したように、手戻りが２箇所に生じていることが明確になり、全体像を把握しやすくなる。
　図５３の説明に戻って、ステップＳ１２５の後にステップＳ１２１に戻る。
　ステップＳ１２１で、全ての手戻り箇所を処理したと判断された場合又は手戻り箇所が存在しない場合には、重複解消部１７は、全てのプロセスインスタンスを処理したか判断する（ステップＳ１２７）。未処理のプロセスインスタンスが存在する場合にはステップＳ１１１に戻る。一方、未処理のプロセスインスタンスが存在しない場合には元の処理に戻る。
　図３の説明に戻って、プロセスインスタンス分類処理部２１は、簡略化プロセスインスタンスデータ格納部１９に格納されているプロセスインスタンスを分類し、分類結果に基づき種類毎に計数して、種類毎に計数値をモデルデータ格納部２３に格納する（ステップＳ２３）。図５１に示されたようなプロセスインスタンスが生成された場合には、ステップＳ２１を実施すると図６２に示すようなプロセスインスタンスが、簡略化プロセスインスタンスデータ格納部１９に格納される。すなわち、Initial State、契約、伝票作成、請求、回収、回収、契約満了、Final Stateという遷移が行われるプロセスインスタンスが６つ含まれるグループと、Initial State、契約、伝票作成、請求、回収、契約更新、伝票作成、請求、回収、契約満了、Final Stateという遷移が行われるプロセスインスタンスが３つ含まれるグループと、Initial State、契約、伝票作成、請求、回収、継続、請求、回収、契約満了、Final Stateという遷移が行われるプロセスインスタンスが１つ含まれるグループとに分類される。従って、モデルデータ格納部２３には、図６３に示すようなデータが格納される。図６３の例では、上で述べた３つのグループのプロセスインスタンスと、それぞれの計数値が登録されている。なお、主要フローフラグの欄には、この段階では何も登録されない。
　そして、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、フロー表示処理を実施する（ステップＳ２５）。フロー表示処理について図６４乃至図６６を用いて説明する。
　まず、フロー表示処理部２５は、モデルデータ格納部２３に格納されているプロセスインスタンスのグループを計数値に基づき降順に整列させる（ステップＳ１４１）。そして、各プロセスのグループを主要フローとして扱うための判断基準となる、当該グループのプロセスインスタンスの総数に占める比率の閾値を、ユーザから入力された場合には当該入力値により、ユーザの入力がない場合には予め設定されている値で決定する（ステップＳ１４３）。例えば総数に占める比率の閾値２０％以上のグループを主要フローと分類する場合には、２０％を入力する。但し、予め設定されている値（例えば３０％）をそのまま用いるようにしても良い。
　そして、フロー表示処理部２５は、計数値上位より１つ未選択のプロセスインスタンスを選択する（ステップＳ１４７）。この選択されたプロセスインスタンスを主要フロー（典型フローとも呼ぶ）に指定する（ステップＳ１４９）。具体的には、モデルデータ格納部２３のテーブルにおける主要フローフラグをオンにセットする。そして、各グループの全体に対して占める比率≧閾値であるか判断する（ステップＳ１５３）。この条件が満たされている場合にはステップＳ１４７に戻る。
　例えば、図６３の例では、最初に第１レコードを選択すると、全体に占める比率が６０％となり、閾値が２０％であれば、ステップＳ１４７に戻る。次に、第２レコードを選択すると、全体に占める比率は３０％となり、同様に、ステップＳ１４７に戻る。このように第１レコード及び第２レコードについて主要フローフラグがオンにセットされる。
　最後に、第３レコードを選択すると、全体に占める比率が１０％となり、全体に占める比率≧閾値という条件が満たされなくなるので、フロー表示処理部２５は、元の処理に戻る。このようにすれば、ステップＳ１４７で選択されたプロセスインスタンスのグループ以外のプロセスインスタンスは、主要フローフラグがオンにセットされていないので、例外フローとして特定されたことになる。
　図３の説明に戻って、フロー表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、入出力部１１を介して処理結果を出力する（ステップＳ２７）。例えば、全てのプロセスインスタンスを重ね合わせて表示する場合には、図６５に示すような業務フローが表示されるようになる。図６５で示すように、継続を経由する手戻りと契約更新を経由する手戻りと、回収の繰り返しがそれぞれ１つだけ存在するような表示になる。
　また、モデルデータ格納部２３に格納されている主要フローフラグのデータを用いて、主要フローと例外フローとを分けて表示する場合には、図６６に示すような表示がなされる。例えば、９０％を分類割合としていると、図６３に示したテーブルにおいて第１及び第２レコードのプロセスインスタンスが重ね合わされて、図６６の上段のような業務フローが主要フローとして表示される。また、図６３に示したテーブルにおいて第３のプロセスインスタンスが、例外フローとして表示される。
　このような処理を実施すれば、図５２のような分類及び表示と比べて、非常に整理された形で業務フローが提示されるため、ユーザは、実際に実施されている業務フローの概要をより把握しやすくなる。すなわち、特徴を把握する上で業務の全体像の把握を困難にしている手戻りや繰り返しが省略されているので、繰り返しの有無や仕方、手戻りの有無や仕方を、把握しやすくなる。
　以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、例えば図１に示した機能ブロック図は一例であって、必ずしも実際のプログラムモジュールに対応しない。
　また、業務の全体像の把握を困難にしている手戻りを削除してプロセスインスタンスを再構築する際には、図５９に示すように手戻りが１箇所に複数存在する場合には、その順番を一定のルールで定めておかないと異なるプロセスインスタンスとして認識されてしまう。例えば、手戻りの長さが短い順に並べてからプロセスインスタンスを再構築するというルールを採用すれば、手戻りの順番が異なる実質的に同じプロセスインスタンスが生成されることが無くなる。
　また、各スコア表も一例であって、確度スコア値の設定の仕方は、経験的にさらに細かく決定される場合もある。さらに、スコア表の項目についても、より少ない項目が設定される場合もあれば、より多くの項目が設定される場合もある。
　また、図３の処理フローにおいて、ステップＳ７乃至Ｓ１３については順番の入れ替えが可能であり、また並列に実施するようにしてもよい。
　また、判定結果の出力では、各判定項目において「確定」判定や所定の閾値以上の確度スコアとなっているフィールドを自動的に選択してユーザに提示し、自動選択できない判定項目についてユーザに選択又は入力を促すようにしてもよい。
　さらに、処理対象フィールドについてのループは、ステップＳ７乃至Ｓ１３内の各々で構成されているが、ステップＳ７乃至Ｓ１３の外側に処理対象フィールドについてのループを出すようにしてもよい。
　なお、業務システム分析装置は、コンピュータ装置であって、図６７に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

Claims (7)

  1. 　業務処理の結果を格納するデータベースから案件毎に実施された一連の業務のデータを抽出して、前記案件毎に実施された業務の業務名を時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、
    　前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第１の業務から、先に実施された第２の業務に戻る手戻りが発生しているか判断するステップと、
    　前記手戻りが発生している前記プロセスインスタンスについて、前記手戻りのパターン種別毎に当該手戻りの重複手戻りを削除し、前記重複手戻り削除後の前記プロセスインスタンスを、簡略化プロセスインスタンスデータ格納部に格納するステップと、
    　前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを、種別毎に計数するステップと、
    　前記計数結果に基づき、出現頻度が所定基準以上となっており且つ前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを特定し、主要な業務フローとして出力する出力ステップと、
    　を、コンピュータに実行させるための業務フロー処理プログラム。
  2. 　前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第３の業務から当該第３の業務に戻る繰り返しが発生しているか判断するステップと、
    　前記繰り返しが発生している前記プロセスインスタンスについて、前記繰り返しのパターン種別毎に当該繰り返しの重複繰り返しを削除し、前記重複繰り返し削除後のプロセスインスタンスを、前記プロセスインスタンスデータ格納部に格納するステップと、
    　をさらに前記コンピュータに実行させるための請求項１記載の業務フロー処理プログラム。
  3. 　前記簡略化プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第３の業務から当該第３の業務に戻る繰り返しが発生しているか判断するステップと、
    　前記繰り返しが発生している前記プロセスインスタンスについて、前記繰り返しのパターン種別毎に当該繰り返しの重複繰り返しを削除し、前記重複繰り返し削除後のプロセスインスタンスを、前記簡略化プロセスインスタンスデータ格納部に格納するステップと、
    　をさらに前記コンピュータに実行させるための請求項１記載の業務フロー処理プログラム。
  4. 　前記出力ステップが、
    　特定された前記プロセスインスタンスを重ね合わせるステップ
    　を含む請求項１記載の業務フロー処理プログラム。
  5. 　前記出力ステップが、
    　特定された前記プロセスインスタンス以外のプロセスインスタンスを、例外フローとして出力するステップ
    　を含む請求項１記載の業務フロー処理プログラム。
  6. 　業務処理の結果を格納するデータベースから案件毎に実施された一連の業務のデータを抽出して、前記案件毎に実施された業務の業務名を時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納するステップと、
    　前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第１の業務から、先に実施された第２の業務に戻る手戻りが発生しているか判断するステップと、
    　前記手戻りが発生している前記プロセスインスタンスについて、前記手戻りのパターン種別毎に当該手戻りの重複手戻りを削除し、前記重複手戻り削除後の前記プロセスインスタンスを、簡略化プロセスインスタンスデータ格納部に格納するステップと、
    　前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを、種別毎に計数するステップと、
    　前記計数結果に基づき、出現頻度が所定基準以上となっており且つ前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを特定し、主要な業務フローとして出力する出力ステップと、
    　を含み、コンピュータに実行される業務フロー処理方法。
  7. 　業務処理の結果を格納するデータベースから案件毎に実施された一連の業務のデータを抽出して、前記案件毎に実施された業務の業務名を時系列に並べたプロセスインスタンスを生成し、プロセスインスタンスデータ格納部に格納する手段と、
    　前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスの第１の業務から、先に実施された第２の業務に戻る手戻りが発生しているか判断する手段と、
    　前記手戻りが発生している前記プロセスインスタンスについて、前記手戻りのパターン種別毎に当該手戻りの重複手戻りを削除し、前記重複手戻り削除後の前記プロセスインスタンスを、簡略化プロセスインスタンスデータ格納部に格納する手段と、
    　前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを、種別毎に計数する手段と、
    　前記計数結果に基づき、出現頻度が所定基準以上となっており且つ前記簡略化プロセスインスタンスデータ格納部に格納されている前記プロセスインスタンスを特定し、主要な業務フローとして出力する出力手段と、
    　を有する業務フロー処理装置。
PCT/JP2008/053086 2008-02-22 2008-02-22 業務フロー処理プログラム、方法及び装置 WO2009104276A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
PCT/JP2008/053086 WO2009104276A1 (ja) 2008-02-22 2008-02-22 業務フロー処理プログラム、方法及び装置
KR1020107016492A KR101175475B1 (ko) 2008-02-22 2008-02-22 업무 흐름 처리 방법 및 장치
JP2009554181A JP5012911B2 (ja) 2008-02-22 2008-02-22 業務フロー処理プログラム、方法及び装置
EP08711854A EP2256677A4 (en) 2008-02-22 2008-02-22 PROGRAM, METHOD AND DEVICE FOR PROCESSING WORKFLOW
CN2008801269662A CN101952843A (zh) 2008-02-22 2008-02-22 业务流程处理程序、方法和装置
US12/849,163 US20100318389A1 (en) 2008-02-22 2010-08-03 Business flow processing method and apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2008/053086 WO2009104276A1 (ja) 2008-02-22 2008-02-22 業務フロー処理プログラム、方法及び装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/849,163 Continuation US20100318389A1 (en) 2008-02-22 2010-08-03 Business flow processing method and apparatus

Publications (1)

Publication Number Publication Date
WO2009104276A1 true WO2009104276A1 (ja) 2009-08-27

Family

ID=40985171

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/053086 WO2009104276A1 (ja) 2008-02-22 2008-02-22 業務フロー処理プログラム、方法及び装置

Country Status (6)

Country Link
US (1) US20100318389A1 (ja)
EP (1) EP2256677A4 (ja)
JP (1) JP5012911B2 (ja)
KR (1) KR101175475B1 (ja)
CN (1) CN101952843A (ja)
WO (1) WO2009104276A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110795171A (zh) * 2019-09-18 2020-02-14 平安银行股份有限公司 业务数据处理方法、装置、计算机设备及存储介质

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103247007A (zh) * 2012-07-09 2013-08-14 中国科学院沈阳自动化研究所 一种基于生产事件的生产过程跟踪方法
US20140343982A1 (en) * 2013-05-14 2014-11-20 Landmark Graphics Corporation Methods and systems related to workflow mentoring
US20160071043A1 (en) * 2014-09-04 2016-03-10 International Business Machines Corporation Enterprise system with interactive visualization
US11042506B2 (en) * 2016-07-20 2021-06-22 Microsoft Technology Licensing, Llc Compliance violation detection
US11972296B1 (en) * 2023-05-03 2024-04-30 The Strategic Coach Inc. Methods and apparatuses for intelligently determining and implementing distinct routines for entities

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050076059A1 (en) 2003-10-03 2005-04-07 Fujitsu Limited Apparatus and method for business process tracking and business process tracking program, and recording medium thereof
JP2006197294A (ja) 2005-01-14 2006-07-27 Epson Toyocom Corp 対称インバーター対圧電発振器
WO2007132547A1 (ja) * 2006-05-16 2007-11-22 Fujitsu Limited 業務モデル生成プログラム、業務モデル生成方法および業務モデル生成装置

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69811790T2 (de) * 1997-08-01 2003-11-20 Ibm Ableitung von Prozessmodellen aus Rechnungsprüfvorgängen für Systeme zur Verwaltung von Arbeitsflüssen
US6038538A (en) * 1997-09-15 2000-03-14 International Business Machines Corporation Generating process models from workflow logs
DE19954268B4 (de) * 1998-12-01 2005-07-21 Ibm Corp. Verfahren und System zur Verbesserung des Workflow in Workflow-Management-Systemen
JP3609333B2 (ja) * 2000-09-29 2005-01-12 株式会社リコー 営業管理方法、営業管理システム及び記録媒体
US20030065702A1 (en) * 2001-09-24 2003-04-03 Ravinder Singh Cache conscious load balancing
US7562339B2 (en) * 2002-01-15 2009-07-14 Bea Systems, Inc. System architecture for business process development and execution with introspection and generic components
US7398525B2 (en) * 2002-10-21 2008-07-08 International Business Machines Corporation Resource scheduling in workflow management systems
EP1639458A4 (en) * 2003-06-12 2010-05-05 Reuters America BUSINESS PROCESS AUTOMATION
US20070203589A1 (en) * 2005-04-08 2007-08-30 Manyworlds, Inc. Adaptive Recombinant Process Methods
US7712102B2 (en) * 2004-07-30 2010-05-04 Hewlett-Packard Development Company, L.P. System and method for dynamically configuring a plurality of load balancers in response to the analyzed performance data
US8010337B2 (en) * 2004-09-22 2011-08-30 Microsoft Corporation Predicting database system performance
JP4549231B2 (ja) * 2005-05-17 2010-09-22 富士通株式会社 サービス処理状況分析プログラム、サービス処理状況分析方法、およびサービス処理状況分析装置
US7739099B2 (en) * 2005-12-22 2010-06-15 International Business Machines Corporation Method and system for on-line performance modeling using inference for real production IT systems
JP5095629B2 (ja) * 2005-12-28 2012-12-12 テレコム・イタリア・エッセ・ピー・アー 特に通信ネットワーク介入用としてのワークフローモデルの自動作成方法
JP4904878B2 (ja) * 2006-03-27 2012-03-28 富士通株式会社 システム開発支援プログラム、システム開発支援装置およびシステム開発支援方法
US20090094074A1 (en) * 2007-10-04 2009-04-09 Nikovski Daniel N Method for Constructing Business Process Models from Task Execution Traces
US7912946B2 (en) * 2008-01-25 2011-03-22 International Business Machines Corporation Method using footprints in system log files for monitoring transaction instances in real-time network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050076059A1 (en) 2003-10-03 2005-04-07 Fujitsu Limited Apparatus and method for business process tracking and business process tracking program, and recording medium thereof
JP2005115494A (ja) 2003-10-03 2005-04-28 Fujitsu Ltd 業務プロセストラッキング装置，業務プロセストラッキング方法，業務プロセストラッキングプログラム，業務プロセストラッキングプログラムを記録した記録媒体
JP2006197294A (ja) 2005-01-14 2006-07-27 Epson Toyocom Corp 対称インバーター対圧電発振器
WO2007132547A1 (ja) * 2006-05-16 2007-11-22 Fujitsu Limited 業務モデル生成プログラム、業務モデル生成方法および業務モデル生成装置

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
HAVEY MICHAEL: "Shosetsu Business Process Modeling", 2 June 2006, O'REILLY JAPAN, INC., pages: 50 - 58 *
KATO K.: "Gyomu no Kashika o Okonau BPM Kiban no Shisaku", INFORMATION PROCESSING SOCIETY OF JAPAN KENKYU HOKOKU, vol. 2004, no. 87, 20 August 2004 (2004-08-20), pages 37 - 44, XP008140457 *
See also references of EP2256677A4 *
YUMOTO T.: "Scenario Test no Test Sekkei", SOFTWARE ? TEST PRESS, vol. 1, 15 April 2006 (2006-04-15), pages 50 - 54 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110795171A (zh) * 2019-09-18 2020-02-14 平安银行股份有限公司 业务数据处理方法、装置、计算机设备及存储介质
CN110795171B (zh) * 2019-09-18 2023-08-04 平安银行股份有限公司 业务数据处理方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
KR101175475B1 (ko) 2012-08-20
EP2256677A1 (en) 2010-12-01
JP5012911B2 (ja) 2012-08-29
EP2256677A4 (en) 2012-12-05
US20100318389A1 (en) 2010-12-16
CN101952843A (zh) 2011-01-19
JPWO2009104276A1 (ja) 2011-06-16
KR20100092981A (ko) 2010-08-23

Similar Documents

Publication Publication Date Title
JP4832523B2 (ja) 業務プロセス分析のための情報処理方法及び装置
JP3302522B2 (ja) データベースシステムおよびその情報活用支援装置
US10853387B2 (en) Data retrieval apparatus, program and recording medium
JP4704461B2 (ja) 業務モデル生成プログラム、業務モデル生成方法および業務モデル生成装置
US20100042745A1 (en) Workflow diagram generation program, apparatus and method
JP5012911B2 (ja) 業務フロー処理プログラム、方法及び装置
JP2017091329A (ja) データベース分析装置およびデータベース分析方法
JP5169560B2 (ja) 業務フロー処理プログラム、方法及び装置
JP4953834B2 (ja) データ解析方法及びデータ解析システム
JP4529861B2 (ja) 階層データの検索装置および検索方法および検索プログラム
JP5246031B2 (ja) 業務フロー処理プログラム、方法及び装置
JP2003016226A (ja) 製品市場品質情報解析支援装置、製品市場品質情報解析支援システム及び製品市場品質情報解析支援用プログラム
JP2016143106A (ja) 業務バリエーションに基づく業務影響箇所抽出方法および業務影響箇所抽出装置
JP7411489B2 (ja) 生産知識管理システム、生産知識管理方法及び生産知識管理プログラム
JP2023141268A (ja) プロセスモデル作成システムおよび方法
EP4068028A1 (en) Screen generation assisting program, screen generation assisting apparatus, and generation assisting method
JP2007334393A (ja) 部品表データ管理方法およびシステム
JP4663526B2 (ja) 帳票作成支援装置、帳票作成支援方法、および帳票作成支援プログラム
JP4181330B2 (ja) 要約作成プログラム及びシステム並びにコンピュータによる要約作成方法
Dara et al. A Robust Approach for Data Cleaning used by Decision Tree Induction Method in the Enterprise Data Warehouse‖
JP2006133883A (ja) プロジェクト管理方法、プロジェクト管理プログラム及びプロジェクト管理装置
JP2004086352A (ja) テキスト情報分析システム、分析結果の格納方法および提示方法
AU2012202032A1 (en) A web server, client computing device, computer implemented method and computer readable storage medium for processing intellectual property data
JP2007140891A (ja) データ項目辞書作成方法
JPH0830676A (ja) 開発実績の自動収集管理装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200880126966.2

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08711854

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2009554181

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20107016492

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2008711854

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE