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

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

Info

Publication number
JPWO2009104276A1
JPWO2009104276A1 JP2009554181A JP2009554181A JPWO2009104276A1 JP WO2009104276 A1 JPWO2009104276 A1 JP WO2009104276A1 JP 2009554181 A JP2009554181 A JP 2009554181A JP 2009554181 A JP2009554181 A JP 2009554181A JP WO2009104276 A1 JPWO2009104276 A1 JP WO2009104276A1
Authority
JP
Japan
Prior art keywords
event
field
data
process instance
business
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
JP2009554181A
Other languages
English (en)
Other versions
JP5012911B2 (ja
Inventor
川村　旭
旭 川村
原　裕貴
裕貴 原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2009104276A1 publication Critical patent/JPWO2009104276A1/ja
Application granted granted Critical
Publication of JP5012911B2 publication Critical patent/JP5012911B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • Data Mining & Analysis (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

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）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
本発明は、業務プロセス分析のための情報処理技術に関する。
業務プロセス・リエンジニアリング（ＢＰＲ：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という遷移が行われるプロセスインスタンスが１つ含まれるグループとに分類される。従って、モデルデータ格納部２３には、図６３に示すようなデータが格納される。図６３の例では、上で述べた３つのグループのプロセスインスタンスと、それぞれの計数値が登録されている。なお、主要フローフラグの欄には、この段階では何も登録されない。
そして、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、フロー表示処理を実施する（ステップＳ２５）。フロー表示処理について図６４乃至図６６を用いて説明する。
まず、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているプロセスインスタンスのグループを計数値に基づき降順に整列させる（ステップＳ１４１）。そして、各プロセスのグループを主要フローとして扱うための判断基準となる、当該グループのプロセスインスタンスの総数に占める比率の閾値を、ユーザから入力された場合には当該入力値により、ユーザの入力がない場合には予め設定されている値で決定する（ステップＳ１４３）。例えば総数に占める比率の閾値２０％以上のグループを主要フローと分類する場合には、２０％を入力する。但し、予め設定されている値（例えば３０％）をそのまま用いるようにしても良い。
そして、プロセス表示処理部２５は、計数値上位より１つ未選択のプロセスインスタンスのグループを選択する（ステップＳ１４７）。この選択されたグループのプロセスを主要フロー（典型フローとも呼ぶ）に指定する（ステップＳ１４９）。具体的には、モデルデータ格納部２３のテーブルにおける主要フローフラグをオンにセットする。また、計数値から全体に対する比率を計算する（ステップS１５１）。そして、選択グループの全体に対して占める比率≧閾値であるか判断する（ステップＳ１５３）。この条件が満たされている場合にはステップＳ１４７に戻る。
例えば、図６３の例では、最初に第１レコードを選択すると、全体に占める比率が６０％となり、閾値が２０％であれば、ステップＳ１４７に戻る。次に、第２レコードを選択すると、全体に占める比率は３０％となり、同様に、ステップＳ１４７に戻る。このように第１レコード及び第２レコードについて主要フローフラグがオンにセットされる。
最後に、第３レコードを選択すると、全体に占める比率が１０％となり、全体に占める比率≧閾値という条件が満たされなくなるので、元の処理に戻る。このようにすれば、ステップＳ１４７で選択されたグループ以外のプロセスインスタンスは、主要フローフラグがオンにセットされていないので、例外フローとして特定されたことになる。
図３の説明に戻って、プロセス表示処理部２５は、モデルデータ格納部２３に格納されているデータを用いて、入出力部１１を介して処理結果を出力する（ステップＳ２７）。例えば、全てのプロセスインスタンスを重ね合わせて表示する場合には、図６５に示すような業務フローが表示されるようになる。図６５で示すように、継続を経由する手戻りと契約更新を経由する手戻りと、回収の繰り返しがそれぞれ１つだけ存在するような表示になる。
また、モデルデータ格納部２３に格納されている主要フローフラグのデータを用いて、主要フローと例外フローとを分けて表示する場合には、図６６に示すような表示がなされる。例えば、９０％を分類割合としていると、図６３に示したテーブルにおいて第１及び第２レコードのプロセスインスタンスが重ね合わされて、図６６の上段のような業務フローが主要フローとして表示される。また、図６３に示したテーブルにおいて第３のプロセスインスタンスが、例外フローとして表示される。
このような処理を実施すれば、図５２のような分類及び表示と比べて、非常に整理された形で業務フローが提示されるため、ユーザは、実際に実施されている業務フローの概要をより把握しやすくなる。すなわち、特徴を把握する上で業務の全体像の把握を困難にしている手戻りや繰り返しが省略されているので、繰り返しの有無や仕方、手戻りの有無や仕方を、把握しやすくなる。
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、例えば図１に示した機能ブロック図は一例であって、必ずしも実際のプログラムモジュールに対応しない。
また、業務の全体像の把握を困難にしている手戻りを削除してプロセスインスタンスを再構築する際には、図５９に示すように手戻りが１箇所に複数存在する場合には、その順番を一定のルールで定めておかないと異なるプロセスインスタンスとして認識されてしまう。例えば、手戻りの長さが短い順に並べてからプロセスインスタンスを再構築するというルールを採用すれば、手戻りの順番が異なる実質的に同じプロセスインスタンスが生成されることが無くなる。
また、各スコア表も一例であって、確度スコア値の設定の仕方は、経験的にさらに細かく決定される場合もある。さらに、スコア表の項目についても、より少ない項目が設定される場合もあれば、より多くの項目が設定される場合もある。
また、図３の処理フローにおいて、ステップＳ７乃至Ｓ１３については順番の入れ替えが可能であり、また並列に実施するようにしてもよい。
また、判定結果の出力では、各判定項目において「確定」判定や所定の閾値以上の確度スコアとなっているフィールドを自動的に選択してユーザに提示し、自動選択できない判定項目についてユーザに選択又は入力を促すようにしてもよい。
さらに、処理対象フィールドについてのループは、ステップＳ７乃至Ｓ１３内の各々で構成されているが、ステップＳ７乃至Ｓ１３の外側に処理対象フィールドについてのループを出すようにしてもよい。
なお、業務システム分析装置は、コンピュータ装置であって、図６７に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

Claims (7)

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

Applications Claiming Priority (1)

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

Publications (2)

Publication Number Publication Date
JPWO2009104276A1 true JPWO2009104276A1 (ja) 2011-06-16
JP5012911B2 JP5012911B2 (ja) 2012-08-29

Family

ID=40985171

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009554181A Expired - Fee Related JP5012911B2 (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)

Families Citing this family (6)

* 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
CN110795171B (zh) * 2019-09-18 2023-08-04 平安银行股份有限公司 业务数据处理方法、装置、计算机设备及存储介质
US11972296B1 (en) * 2023-05-03 2024-04-30 The Strategic Coach Inc. Methods and apparatuses for intelligently determining and implementing distinct routines for entities

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69811790T2 (de) * 1997-08-01 2003-11-20 International Business Machines Corp., Armonk 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
JP4287234B2 (ja) * 2003-10-03 2009-07-01 富士通株式会社 業務プロセストラッキング装置，業務プロセストラッキング方法，業務プロセストラッキングプログラム，業務プロセストラッキングプログラムを記録した記録媒体
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
JP2006197294A (ja) 2005-01-14 2006-07-27 Epson Toyocom Corp 対称インバーター対圧電発振器
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
EP1972093B1 (en) * 2005-12-28 2018-03-28 Telecom Italia S.p.A. A method for the automatic generation of workflow models, in particular for interventions in a telecommunication network
JP4904878B2 (ja) * 2006-03-27 2012-03-28 富士通株式会社 システム開発支援プログラム、システム開発支援装置およびシステム開発支援方法
WO2007132547A1 (ja) * 2006-05-16 2007-11-22 Fujitsu Limited 業務モデル生成プログラム、業務モデル生成方法および業務モデル生成装置
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

Also Published As

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

Similar Documents

Publication Publication Date Title
JP4832523B2 (ja) 業務プロセス分析のための情報処理方法及び装置
JP3302522B2 (ja) データベースシステムおよびその情報活用支援装置
JP4704461B2 (ja) 業務モデル生成プログラム、業務モデル生成方法および業務モデル生成装置
JP5012911B2 (ja) 業務フロー処理プログラム、方法及び装置
US20100042745A1 (en) Workflow diagram generation program, apparatus and method
US20110161132A1 (en) Method and system for extracting process sequences
JP2017091329A (ja) データベース分析装置およびデータベース分析方法
JP5169560B2 (ja) 業務フロー処理プログラム、方法及び装置
JP6623754B2 (ja) 表形式データ処理プログラム、方法及び装置
JP4953834B2 (ja) データ解析方法及びデータ解析システム
JP4529861B2 (ja) 階層データの検索装置および検索方法および検索プログラム
JP5246031B2 (ja) 業務フロー処理プログラム、方法及び装置
US8335759B2 (en) Work analysis device and recording medium recording work analysis program
JP2003016226A (ja) 製品市場品質情報解析支援装置、製品市場品質情報解析支援システム及び製品市場品質情報解析支援用プログラム
US20230143297A1 (en) Production knowledge management system, production knowledge management method, and production knowledge management program
Snipes et al. Code hot spot: A tool for extraction and analysis of code change history
JP6336922B2 (ja) 業務バリエーションに基づく業務影響箇所抽出方法および業務影響箇所抽出装置
JP2023141268A (ja) プロセスモデル作成システムおよび方法
JP4181330B2 (ja) 要約作成プログラム及びシステム並びにコンピュータによる要約作成方法
JP2007334393A (ja) 部品表データ管理方法およびシステム
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
JPH0830676A (ja) 開発実績の自動収集管理装置
JP2007140891A (ja) データ項目辞書作成方法

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120508

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120521

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150615

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees