<第1実施形態>
図1は、第1実施形態における業務管理システムの概略構成の例を示すブロック図である。このシステムは、文書管理サーバ10、クライアント端末20−1,20−2,・・・(以下、クライアント端末20と総称する)、及び業務管理サーバ50がネットワーク60を介して互いに接続された構成を備える。
クライアント端末20について図2を用いて説明する。クライアント端末20は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複写機、スキャナ、及びFAX(ファクシミリ)装置などがその一例である。クライアント端末20は、文書に対して実行された操作の結果として生じた文書を文書管理サーバ10に登録する処理を行う。クライアント端末20は、文書操作部200及び登録処理部210を備える。
文書操作部200は、文書に対する操作を実行する手段である。文書に対する操作には、例えば、文書の表示(ユーザから見れば「閲覧」)、編集、印刷出力、紙文書の読み取り、紙文書の複写、等がある。図2では、文書操作部200を1つだけ示したが、それら個々の操作を別々の操作部(例えば、編集用のアプリケーション、読取制御用のアプリケーションなどといった別々のアプリケーション)が担当してもよい。例えば、文書操作部200がワードプロセッサ等の電子文書を作成・編集するためのソフトウエアであれば、文書操作部200は、ユーザの指示に応じて電子文書を表示したり、電子文書に編集を加えたりする。文書操作部200は、文書に対して操作を行った場合、その操作の結果を文書管理サーバ10へ登録することを指示するユーザからの登録指示に応じて、その操作の結果を表すID付き文書300を出力する。
ID付き文書300は、図3に示すように、メタ情報310と文書内容320を含んだ電子文書である。文書内容320は、文書操作部200の操作の結果生成された文書の内容データである。文書操作部200が電子文書を作成・編集するためのソフトウエアであれば、文書内容320はそのソフトウエアによる編集の結果生成される文書ファイルである。また、文書操作部200が電子文書を印刷する装置であれば、文書内容320は、例えば、印刷される電子文書の内容データとすればよい。また、文書操作部200が紙文書をスキャンする装置又は紙文書を複写する装置であれば、文書内容320は、例えば、その紙文書を読み取って得られる画像データとすればよい。
メタ情報310は、文書管理のための情報であり、管理ID312,親ID314,及びログ情報316を含む。
管理ID312は、当該ID付き文書300自体の一意な識別情報である。親ID314は、当該ID付き文書300の親のID付き文書の管理IDである。すなわち、本実施形態では、あるID付き文書と、このID付き文書に対して操作を加えた結果得られる新たなID付き文書とを、親と子の関係として取り扱う。第1のID付き文書を操作して第2のID付き文書が得られた場合、第1のID付き文書は第2のID付き文書の親であり、第2のID付き文書は第1のID付き文書の子である。したがって、例えば、管理ID「A」のID付き文書を文書操作部200で操作して、その結果得られた新たなID付き文書の管理IDが「B」である場合、後者のメタ情報310における管理ID312は「B」であり、親ID314は「A」である。このような親子の関係を、以下では「(管理IDの)派生関係」という。
なお、本システムに未登録の電子文書を新たに登録する操作を実行した場合や、未登録の紙文書をスキャン又は複写する操作を実行した場合(この場合、紙文書を読み取った画像を文書内容とするID付き文書が生成され、本システムに登録される)に生成されるID付き文書300では、親ID314は空(すなわち、親は存在しない)となる。
ログ情報316は、当該ID付き文書が生成された際の操作についての、各種のログ項目の情報である。ログ項目には、例えばその操作が行われた日時、その操作の種別、その操作を指示したユーザ(操作者)などがあるが、もちろんこれに限るものではない。操作の種別には、例えば登録(本システムに新規の文書を登録すること)、閲覧、編集、更新(更新版の登録)、印刷、スキャン、紙文書の複写、等がある。例えば、ユーザが文書操作部200を用いて第1のID付き文書に対して編集を加え、編集完了の指示を行った場合、その結果生成される第2のID付き文書のログ情報316は、編集完了の日時と、その編集を指示したユーザの識別情報と、操作の種別として「編集」と、を含んだものとなる。
ここでログ情報316に組み込まれる操作の種別は、ログ記録の目的での分類に従った種別であり、文書操作部200が実行する操作の種別そのものでなくてもよい。例えば、文書操作部200が実行する1つの操作の種別を、異なるログ記録目的に応じて異なる操作種別として区別してもよい。例えば、文書編集アプリケーションにおけるID付きの電子文書に対する「編集」という操作について、ユーザが操作メニュー上で「編集結果の文書として登録」を指示した場合はログ情報316に組み込まれる操作種別の値を「編集」とし、ユーザが操作メニュー上で「承認版として登録」を指示した場合はログ情報316に組み込まれる操作種別の値を「承認」としてよい。逆に、文書操作部200が実行する複数の操作の種別を、同じ1つのログ記録目的の操作種別に対応づけてもよい。例えば、文書編集アプリケーション上でID付きの電子文書に編集を加え操作メニュー上で「承認版として登録」を指示した場合も、スキャナで管理ID付きの紙文書を読み取り読取制御用アプリケーションの操作メニュー上で「読み取った文書を承認版として登録」を指示した場合も、ログ情報316に組み込まれる操作種別の値は「承認」としてよい。
また、本実施形態の例では、ID付き文書300のログ情報316に組み込まれる操作種別の値は、そのID付き文書300に関する業務における1つの作業工程に対応するものとする。言い換えると、作業工程の完了の前にID付き文書に対して閲覧や編集などの操作が実行されても、これらの操作の結果のID付き文書は生成されず、文書管理サーバ10に登録されることもない。
例えば、ユーザは、あるID付き文書に対して操作を実行し、そのID付き文書に関して自分が担当する作業工程が完了したときに、その作業工程に対応する操作種別の値を文書編集アプリケーションの操作メニュー上で選択した上で、操作結果のID付き文書の文書管理サーバ10への登録を指示する。この指示に応じて、作業工程の完了時の操作の結果を表すID付き文書が文書操作部200により生成されて出力され、出力されたID付き文書が登録処理部210により文書管理サーバ10に登録される。
また例えば、各ユーザが自らの担当の作業工程の操作を行ったID付き文書を次の作業工程の担当者であるユーザに対してFAXで送信する場合、その送信に用いられるFAX装置に文書操作部200及び登録処理部210を実現しておいてもよい。ユーザは、例えば、ID付き文書をFAX送信するときに、FAX装置に実現された文書操作部200を用いて、自分の担当の作業工程に対応する操作種別の値を指定する。FAX装置に実現された文書操作部200は、例えば、FAX送信の対象のID付き文書を読み取り、読み取ったID付き文書の管理IDを親IDとし、読み取ったID付き文書と同じ文書内容を有し、かつユーザが指定した操作種別の値を有する新たなID付き文書を生成する。この新たなID付き文書をユーザにより指定された送信先にFAX送信し、文書管理サーバ10に登録することで、完了した作業工程に対応するID付き文書について、次の作業工程の担当者に対する受け渡し及び文書管理サーバ10への登録が行われる。
図2の説明に戻り、文書操作部200は、操作結果として上述のようなID付き文書300を作成するために、ID割り当て部202及び派生関係組込部204を備える。ID割り当て部202は、操作結果のID付き文書300に一意な管理IDを付与する手段である。管理IDは、少なくとも本システム内で一意な識別情報である必要がある。例えば、操作の結果生成するID付き文書300(ただし管理ID312を除いたもの)のハッシュ値を求め、このハッシュ値をその文書300のID付き文書とすればよい。ハッシュ関数としてSHA-256(SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である)などのような耐衝突性を持つ暗号学的ハッシュ関数を用いれば、実用上十分な一意性を持つ管理IDを生成することができる。もちろん、システム内で一意な管理IDを各クライアント端末20で生成する方法は、これに限らない。管理IDを、クライアント端末20固有の識別情報を含むものとすれば、システム内で一意な管理IDを各クライアント端末20で生成することができる。
派生関係組込部204は、操作結果の文書に対しID割り当て部202が割り当てた新たな管理ID312と、その操作の元になった親文書の管理IDである親ID314(新規登録の場合は、親IDは無し)と、その操作についてのログ情報316と、を含むメタ情報310を生成する。ここで、派生関係組込部204は、文書操作部200が実行する個々の操作の種別が、ログ記録目的上の操作種別のどれに対応するかを表す対応関係の情報を保持しており、この情報を用いることでログ情報316に組み込む操作種別の値を求める。そして、派生関係組込部204は、そのメタ情報310を操作結果の文書内容に付加することにより、操作後のID付き文書300を生成して出力する。
文書操作部200がアプリケーションソフトウエアである場合、ID割り当て部202及び派生関係組込部204は、そのソフトウエアに対して追加される、いわゆるプラグイン(plug-in)プログラムとして実現してもよい。
登録処理部210は、文書操作部200が出力したID付き文書300を文書管理サーバ10に登録するための処理を実行する。このように各クライアント端末20が、自ら実行した操作の結果であるID付き文書300を文書管理サーバ10に登録することにより、文書管理サーバ10は各ID付き文書300間の派生関係を把握することができる。
文書操作部200が操作の結果出力するID付き文書300は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。電子メール送信用のソフトウエアは、この例では本システムに準拠していないので、この送信操作はID付き文書には反映されず、したがって文書管理サーバ10にも記録されない。他の人からID付き文書300を受け取った人が、自分のクライアント端末20の文書操作部200を用いてそのID付き文書300を操作すると、その操作に応じて新たな管理IDを付与されたID付き文書が生成されることになる。
また、文書操作部200が電子文書を印刷する場合、管理IDを生成し、その電子文書の印刷結果にその管理IDを埋め込んでもよい。管理IDの埋め込みは、例えば電子文書の印刷画像に、管理IDを示すコード画像を重畳する等の方法で行うことができる。また、用紙がRFID(Radio Frequency Identifier)タグを備えている場合、そのRFIDタグに管理IDを書き込んでもよい。このように印刷を行った場合、文書操作部200は、その管理IDや操作種別「印刷」等のメタ情報を含んだID付き文書を文書管理サーバ10に登録する。なお、ID付き文書を印刷した場合には、そのID付き文書の管理IDを親ID314として含んだID付き文書が生成される。印刷操作に対応するID付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データをなどの印刷データ、又は印刷された文書ファイルを、文書内容320として組み込んでもよい。
また、管理IDが埋め込まれた紙文書を文書操作部200が読み取った場合、文書操作部200は、その読み取り操作に対して新たな管理IDを付与し、読み取り結果の画像を文書内容320として含んだID付き文書を生成して文書管理サーバ10に登録する。このID付き文書の親ID314には、紙文書から読み取った管理IDがセットされる。管理IDが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。また、管理IDが埋め込まれた紙文書のFAX送信の際には、例えば、受信側のFAX装置で上述した読み取り時の処理が実行され、送信側のFAX装置で管理IDの埋め込みを伴う上述の印刷処理が実行される。
次に、文書管理サーバ10について説明する。文書管理サーバ10は、システム内の複数のクライアント端末20から送られてくるID付き文書300を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。図4に示すように、文書管理サーバ10は、文書DB100、派生関係DB110、文書登録部130、及び要求処理部140を備える。
文書DB100は、クライアント端末20から送られてきたID付き文書300のうちの文書内容320を格納するデータベースである。文書DB100に格納された各文書内容320は、一意な内容IDにより管理してもよい。内容IDとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末20が内容IDを付与してもよく、この場合、内容IDをメタ情報310に組み込んでもよい。また、内容IDの代わりに、その文書内容320を、当該文書内容に対応するID付き文書300の管理IDと対応づけて文書DB100に格納してもよい。
文書登録部130は、クライアント端末20から受信したID付き文書の中の文書内容を文書DB100に、メタ情報を派生関係DB110に、それぞれ登録する。そのうち、メタ情報の登録を担当するのが派生関係登録部132である。
派生関係DB110は、そのようなID付き文書300のうち、派生関係の情報を主としたメタ情報を蓄積するデータベースである。図5に、派生関係DB110のデータ内容の一例を示す。図5に示した表における1行の情報が、1つのID付き文書300に対応するメタ情報レコードである。
図5の例の表では、各ID付き文書300の管理IDに対応づけて、ツリーID、親ID、操作種別、操作者、役割、操作日時、ファイル名、物品種別、分岐条件、及び結合種類の各項目が登録されている。このうち、ツリーID以外の項目の値は、クライアント端末20から文書管理サーバ10に対して送信されるID付き文書300中に含まれる。ツリーIDは、文書管理サーバ10が生成して各管理IDに対応づけて派生関係DB110に登録する。派生関係DB110内の管理IDの派生関係は、複数の「登録」操作をそれぞれの根とする複数の独立した木構造を表す。ツリーIDは、この複数の木構造(ツリー)を識別する識別情報である。ID付き文書300から値が取得される項目のうち、管理ID、親ID、操作種別、操作者、及び操作日時については既に説明した。「役割」は、対応する操作者の業務上の役割を表す。「ファイル名」は、ID付き文書300の電子文書ファイルの名称を表す。なお、本例では、ファイル名の項目には、電子文書ファイルの名称を表す文字列のうち、その文書の種類(各種の依頼書、申請書など)を表す部分が登録される。図5に例示する各管理IDのID付き文書のファイル名は「見積依頼書」であり、各ID付き文書が物品の見積依頼に係る業務において用いられる文書であることがわかる。「物品種別」は、見積依頼書で見積の対象となる物品の種別である。これは、見積依頼書のID付き文書を(新規)登録する操作者が文書操作部200を用いて入力する。「分岐条件」及び「結合種類」の各項目の値は、後述の業務管理サーバ50においてワークフローを生成するときに用いられる。分岐条件は、ワークフローで生じる分岐処理において、ある分岐先に進む条件を表す。結合種類は、ワークフローで分岐処理が行われ、各分岐先における一連の処理のあとに1つの作業工程が行われる(つまり、ワークフローの処理経路が結合する)ときの、結合の態様を表す。分岐条件及び結合種類についての詳細は後述する。
なお、図5に例示したメタ情報の項目は一例に過ぎない。例えば、ID付き文書が用いられる業務の内容に応じて、図5に示す項目の他の項目を追加してもよい。あるいは、管理目的上必要なければ、図5の例の項目の一部を省略してもよい。
また、図5は派生関係DB110が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係DB110は、一般的なリレーショナルデータベースとして構築することもできるし、管理IDを除くメタ情報を記述したXML(eXtensible Markup Language)文書を、管理IDをキーとして登録したデータベースとして構築することもできる。
図5に示した派生関係DB110のデータ内容は、図6のような木構造を成す。これは、管理IDをノードとし、管理ID間の親子関係をエッジとする木構造である。以下の説明では、派生関係DB110内の情報が構成する木構造を履歴ツリーとも呼ぶ。
図5及び図6の例は、物品購入の費用の見積に関する業務における文書の操作の履歴の例を示す。文書管理サーバ10へのID付き文書の登録を指示する各ユーザは、少なくとも、業務においてID付き文書に対して自分が行うべき作業の内容(操作種別)と自分の次の作業工程の担当者(操作結果のID付き文書を渡す相手)とを把握している。しかしながら、各ユーザは、必ずしも業務の全体の流れを把握しているとは限らない。
図5及び図6の例が示す文書の履歴を時系列順に説明すると、以下のようになる。
まず、文書管理サーバ10に登録されていなかった文書の「登録」操作がuserAのクライアント端末で実行される。「登録」操作は、文書管理サーバ10に未登録の文書(すなわち、管理IDを有していない文書)を当該サーバ10に登録するための操作である。また、userAは、この操作のときに、自己の役割である「開発」及び見積の対象の物品の種別である「文房具」を設定する。さらに、userAは、分岐条件を「${物品種別}=”文房具”」に設定する。これは、「物品種別の項目の値が”文房具”である」ことを意味する。本例では、新規登録された見積依頼書に対して次の作業工程を行う担当者は、物品種別の値によって異なる。次の作業工程の担当者の候補が複数あるということは、その業務を表すワークフローにおいて分岐が生じていることを意味する。このような場合、ユーザは、次の作業工程の担当者を決定する条件、つまり、業務の処理経路の分岐先を決定する条件を分岐条件として登録する。図5の例で、新規登録された見積依頼書に対して次の作業工程の操作を実行する担当者は、物品種別の値によって決定されるので、userAは、「物品種別の項目の値が”文房具”である」ことを分岐条件として設定する。
図7に、分岐条件の設定のためにクライアント端末20で表示される表示画面の例を示す。図7の例の表示画面は、例えば、文書操作部200を用いてユーザが分岐条件の設定を望む旨の指示を入力した場合に、クライアント端末20の表示装置(図示しない)に表示される。図7の例では、破線で囲んだフィールド40において、分岐先を決定する属性項目(派生関係DB110中のレコードの各項目)の指定を受け付ける。また、破線で囲んだフィールド42では、フィールド40で指定された属性項目の値に含まれる文字列の指定を受け付ける。さらに、破線で囲んだフィールド44では、フィールド40で指定された属性項目とフィールド42で指定された文字列との間の関係の設定を受け付ける。ユーザが各フィールド40,42,44の値を設定し、設定ボタン46をマウスなどの入力装置(図示しない)によって押下すると、フィールド40,42,44の値で定められる分岐条件が処理対象のID付き文書に設定される。
再び図5及び図6を参照し、userAによる以上の操作に応じて、管理IDが"Doc1"、親IDが空、操作種別が「登録」であるメタ情報と、その文書の文書内容とを含むID付き文書"Doc1"がuserAのクライアント端末から文書管理サーバ10に送られる。これに応じ、文書管理サーバ10は、そのID付き文書"Doc1"中の文書内容を文書DB100へ、メタ情報を派生関係DB110にそれぞれ登録する。このとき、文書管理サーバ10の派生関係登録部132は、ID付き文書"Doc1"の親IDを確認し、その値が空であることから、管理ID"Doc1"が履歴ツリーの根ノードに対応すると判断する。そして、管理ID"Doc1"を根ノードとする履歴ツリーのツリーID"Tree0"を新たに生成し、派生関係DB110の管理ID"Doc1"のレコードのツリーIDの項目の値として登録する。
その後、userAは、登録したID付き文書"Doc1"を、例えば、電子メールにそのID付き文書を添付して送信することで、文房具の購買の担当者であるユーザuserBに渡す。文書"Doc1"を受け取ったuserBは、自分のクライアント端末20の文書操作部200でID付き文書"Doc1"に対して編集を加える。例えば、文書"Doc1"に文房具の見積の内容を記入する。userBは、文書"Doc1"への編集が完了すると、文書操作部200を用いて、その操作結果の文書の文書管理サーバ10への登録をクライアント端末20に指示する。この指示に応じて、文書操作部200は、userBによる編集操作の結果としてID付き文書"Doc2"を生成し、登録処理部210によりID付き文書"Doc2"が文書管理サーバ10に登録される。このとき、文書管理サーバ10は、管理ID"Doc2"のツリーIDとして、ID付き文書"Doc2"の親ID"Doc1"に関連づけられたツリーID"Tree0"を登録する。ID付き文書"Doc2"のメタ情報における管理IDは"Doc2"であり親IDは"Doc1"である。また操作者はuserBであり、操作種別は「編集」である。また、userBは、自己の「役割」として「文房具購買」を入力し、この役割の値「文房具購買」がログ情報に組み込まれる。また、見積依頼書に係る本例の業務において、見積依頼書を編集した結果の文書は、その見積依頼書を新規登録したユーザに返送されるものとする。よって、userBの操作結果の文書に関しワークフローの分岐は生じない。したがって、ID付き文書"Doc2"に対する分岐条件の設定は行われない。
なお、この操作の前にuserBのクライアント端末20内にあったID付き文書"Doc1"は、この操作に伴い、派生関係組込部204によりID付き文書"Doc2"に置き換えられる。この置き換え処理では、派生関係組込部204は、元のID付き文書"Doc1"のうち、メタ情報310の管理ID312を新たに発行したID"Doc2"へ変更すると共に、元の文書"Doc1"の管理ID"Doc1"を親ID314の値にセットする。また、派生関係組込部204は、ログ情報316中の操作種別の値を今回の操作の種別である「編集」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuserBに変更し、役割の値を「文房具購買」に変更する。また、文書内容を編集後の文書内容とする。なお、ファイル名及び物品種別の各値「見積依頼書」及び「文房具」は変更されない。
このようにID付き文書"Doc1"は、編集されて登録指示がなされると、編集後のID付き文書"Doc2"に置き換えられる。したがって、その置き換えの後は、ID付き文書"Doc1"自体はそのクライアント端末20には存在せず、その代わりにID付き文書"Doc2"が存在することとなる。
次に、userBは、電子メールなどによって、ID付き文書"Doc2"をuserAに渡す。userAは、自己のクライアント端末20において、文書"Doc2"を閲覧してその文書内容を確認し、文書操作部200を用いて当該閲覧操作の結果の文書の文書管理サーバ10への登録を指示する。このとき、userAは、自己の役割「開発」を入力する。この操作に応じて、新たな管理ID"Doc3"のID付き文書が生成され、操作前のID付き文書"Doc2"と置き換えられる。この置き換え処理では、派生関係組込部204は、元のID付き文書"Doc2"のメタ情報のうち、管理IDを"Doc3"に変更すると共に、親IDの値を元の文書の管理ID"Doc2"に設定する。そして、操作種別を「閲覧」、操作者を「userA」、役割を「開発」に書き換える。操作日時には当該閲覧操作の日時が設定される。さらに、派生関係組込部204は、userAが設定した結合種類の項目の値「OR-Join」をメタ情報に設定する。userAは、見積依頼書の物品種別によって異なる相手から記入済みの見積依頼書を受け取ることがある。これは、見積依頼書に関する業務のワークフローにおいて、分岐の後の複数の処理経路の結合が生じていることを意味する。このようなワークフローの結合が生じる時点での作業工程を担当するユーザは、ID付き文書に対する操作結果のID付き文書について、ワークフローにおける結合の態様を表す結合種類を設定する。図5の例では、文書"Doc3"に対し、結合種類は、「OR-Join」に設定される。「OR-Join」は、ワークフローの実行時に複数の分岐のいずれかから1つだけ入力(文書)を受け付けて、その入力を通過させて次の作業工程へ進めることを意味する。クライアント端末20で生成されたID付き文書"Doc3"は、登録処理部210により文書管理サーバ10に登録される。なお、派生関係DB110において、管理ID"Doc3"のツリーIDは、親ID"Doc2"のツリーIDと同じ"Tree0"に設定される。
その後、userAは、見積依頼書の内容を承認する担当者であるuserCに対し、電子メールなどによってID付き文書"Doc3"を渡す。userCは、クライアント端末20の文書操作部200を用いて、ID付き文書"Doc3"の文書内容、つまり、文房具についての見積の内容、を確認した上で、例えば、電子承認印を押印し、操作メニュー上で「承認版として登録」を指示する。この操作に応じて、新たなID付き文書"Doc4"が生成されて文書管理サーバ10に登録される。ID付き文書"Doc4"のメタ情報の管理IDは"Doc4"、親IDは"Doc3"に設定される。また、操作種別は「承認」、操作者は「userC」、役割はuserCが入力した「開発管理」に設定される。また、文書管理サーバ10は、管理ID"Doc4"のツリーIDとして、その親ID"Doc3"のツリーIDと同じ"Tree0"を設定する。
さらに、userCは、承認操作の結果のID付き文書"Doc4"をuserAに返す。userAは、クライアント端末20において文書"Doc4"を閲覧して、見積の内容が承認されたことを確認し、見積依頼書に関する業務を終了する。そして、文書操作部200を用いて、この業務完了時の文書"Doc4"を複製し、例えば、複製結果の文書を予め定められた格納位置に格納する操作を行う。この操作の結果、管理ID"Doc5"、親ID"Doc4"、操作種別「複製」、操作者「userA」、役割「開発」である新たなID付き文書"Doc5"が生成されて文書管理サーバ10に登録される。なお、複製結果の文書の格納位置は、例えば、承認後の見積依頼書の保存場所として予め定められたファイル共有サーバ(図示しない)中の格納位置などであってよい。
図5及び図6は、この時点での派生関係DB110内の、"Doc1"から派生する文書あるいは操作の様子を示している。なお、以上の説明では、ユーザの役割は、各ユーザがクライアント端末20において文書の登録指示を行う度に自ら入力する。他の処理の例では、各ユーザの役割を記述した設定ファイルをクライアント端末20に保持させておき、文書操作部200は、ID付き文書の生成の際に、この設定ファイルを参照して役割の項目の値をログ情報に組み込んでもよい。あるいは、クライアント端末20は、各ユーザの役割を記憶したデータベース(図示しない)にアクセスして、文書の操作者であるユーザの役割を取得してもよい。
以上、派生関係DB110のデータ内容を例に取り、本システムにおける文書操作の履歴情報の登録の様子を説明した。
図4の説明に戻り、要求処理部140は、クライアント端末20又は業務管理サーバ50からのサービス要求に応じて、派生関係DB110を用いたサービスを提供する。例えば、管理IDを含むサービス要求をクライアント端末20から受けた場合に、サービス要求中の管理IDに関連する文書についてのログ情報を提供する。例えば、サービス要求中の管理IDの来歴、すなわち始祖からその管理IDまでに文書が経てきた操作の履歴(例えば誰がいつどんな操作をしたのかを示す情報のリスト)を表示するサービスを提供したり、サービス要求中の管理IDが生成された後に文書に対して行われた操作の履歴を表示したりする。また例えば、業務管理サーバ50から、特定の検索条件を含むサービス要求を受けた場合に、要求処理部140は、サービス要求中の検索条件を満たす文書についてのログ情報を提供することもある。例えば、特定のファイル名を有する文書や、ある時間内の操作日時を有する文書を派生関係DB110から検索し、検索結果の文書についてのログ情報を業務管理サーバ50に提供することがある。
次に、図8を参照し、業務管理サーバ50について説明する。業務管理サーバ50は、文書管理サーバ10の派生関係DB110を参照し、ID付き文書300が用いられる業務の流れを管理する。業務管理サーバ50の機能の一部は、本発明の各種の実施形態の業務管理支援装置として機能する。業務管理サーバ50は、履歴ツリー取得部500、履歴ツリー統合部520、ワークフロー処理部530、及びワークフローDB540を備える。
履歴ツリー取得部500は、文書管理サーバ10の派生関係DB110から履歴ツリーを取得する。ここで、「履歴ツリーの取得」とは、派生関係DB110において同じツリーIDを含むすべてのレコードを取得することを意味する。例えば、履歴ツリー取得部500は、文書管理サーバ10に対して、特定の検索条件を満たす履歴ツリーを提供することを要求し、それに応じて文書管理サーバ10から送信される履歴ツリー(つまり、当該履歴ツリーに属する管理IDのレコード)を受信する。履歴ツリーの検索条件は、例えば、特定のファイル名を有する文書を含む履歴ツリーを検索する条件であってよい。履歴ツリーの検索条件は、例えば、システムの管理者などにより、図示しない入力装置を介して指定される。
履歴ツリー統合部520は、複数の履歴ツリーを統合して、その業務の流れを表すワークフローに対応する1つのグラフ構造を生成する。統合元の複数の履歴ツリーに含まれる各ノードは、ワークフローに対応するグラフ構造に含まれるノードのうちのいずれかに対応する。また、このグラフ構造は、統合元の履歴ツリーにおけるID付き文書(ノード)間の親子関係を保持した有向グラフとなる。なお、以下の説明において、「ワークフロー」の用語は、履歴ツリー統合部520が生成するグラフ構造を指すこともある。
ワークフロー処理部530は、履歴ツリー統合部520が生成したワークフローに対する処理を行う。ワークフロー処理部530は、分岐・結合検出部532、分岐種類判定部534、分岐条件設定部536、及び結合種類設定部538を備える。
分岐・結合検出部532は、ワークフローにおける分岐点及び結合点を検出する。
分岐種類判定部534は、分岐・結合検出部532で検出された分岐点のそれぞれについて、その分岐の種類(態様)を判定する。分岐の種類には、例えば、ワークフローの実行時に分岐条件に従って複数の分岐先のいずれか1つの処理経路のみが実行される排他的な分岐(OR-Split)、複数の分岐先のすべての処理経路が実行される並行分岐(AND-Split)、複数の分岐先の処理経路の実行を許容する分岐(Multiple Choice)、などがある。
分岐条件設定部536は、分岐種類判定部534で排他的な分岐であると判定された分岐点に対して、統合元の履歴ツリー中のノードに設定された分岐条件に基づいて分岐条件を設定する。
結合種類設定部538は、統合元の履歴ツリー中のノードに設定された結合種類に基づいて、分岐・結合検出部532で検出された結合点のそれぞれの種類を設定する。
ワークフローDB540は、ワークフロー処理部530による処理の結果のワークフローに関する情報を記憶するデータベースである。
以下、業務管理サーバ50が行う処理の例を説明する。
図9に、複数の履歴ツリーを統合してワークフローを生成するときの業務管理サーバ50の処理手順の例を示す。図9を参照し、まず、履歴ツリー取得部500は、文書管理サーバ10に対し、特定の条件を満たす履歴ツリーの提供を要求し、その要求に応じて文書管理サーバ10から送信される履歴ツリーを取得する(ステップS10)。ステップS10で取得される履歴ツリーは、ワークフローの生成の材料となる。
説明のための具体例として、以下では、ステップS10で、「ファイル名が「見積依頼書」である」文書を含む履歴ツリーの提供を履歴ツリー取得部500が文書管理サーバ10に対して行ったとする。また、文書管理サーバ10の派生関係DB110には、図5の例のデータ内容に加えて、図10に例示するデータ内容が登録されているとする。図10の例の表において、管理ID"Doc11"〜"Doc15"までの文書は、ツリーID"Tree1"の履歴ツリーに含まれる。図10の例の表の管理ID"Doc11"〜"Doc15"のレコードは、コンピュータの見積依頼書であるID付き文書"Doc11"がuserHにより新規登録され、その文書"Doc11"に対してuserIが編集操作を行ってID付き文書"Doc12"が登録され、さらに、userHにより閲覧操作("Doc13")、userJにより承認操作("Doc14")が行われた後に、userHにより複製操作が行われた("Doc15")ことを表す。また、管理ID"Doc21"〜"Doc25"までの文書は、ツリーID"Tree2"の履歴ツリーに含まれる。図10の例の表の管理ID"Doc21"〜"Doc25"のレコードは、文房具の見積依頼書について、userPによる新規登録("Doc21")、userQによる編集("Doc22")、userPによる閲覧("Doc23")、userRによる承認("Doc24")、及びuserPによる複製("Doc25")の各操作が順に実行されたことを表す。図10に例示する文書の操作の履歴情報の登録時のクライアント端末20及び文書管理サーバ10の動作の詳細は、図5及び図6を参照して説明した上述の動作と同様である。図11に、図5に例示するツリーID"Tree0"、図10に例示するツリーID"Tree1","Tree2"の履歴ツリーを表す。
本具体例では、図9のステップS10の結果、文書管理サーバ10において派生関係DB110中でファイル名が「見積依頼書」である文書を含む履歴ツリーが検索され、業務管理サーバ50に対し、文書管理サーバ10から、図11に例示する3つの履歴ツリー"Tree0","Tree1","Tree2"が送信される。つまり、図5及び図10の例の表における管理ID"Doc1"〜"Doc5","Doc11"〜"Doc15","Doc21"〜"Doc25"の各レコードの情報の内容が文書管理サーバ10から業務管理サーバ50へ送信される。なお、以下の説明において、業務管理サーバ50の各部が「履歴ツリー」に対して行う処理は、ステップS10で取得された各レコードのうち、処理対象の履歴ツリー中のすべてのノードのレコードの情報の内容を用いて行われる処理である。また、業務管理サーバ50の各部が「履歴ツリー中のノード」に対して行う処理は、ステップS10で取得された各レコードのうち、処理対象のノードに対応するレコードの情報の内容を用いて行われる処理である。
文書管理サーバ10から送信された履歴ツリーを取得した履歴ツリー取得部500は、取得した履歴ツリーを履歴ツリー統合部520に渡し、履歴ツリー統合部520は、これらの履歴ツリーを処理対象として、履歴ツリー統合処理を行う(ステップS20)。
図12は、履歴ツリー統合処理(図9のステップS20)の詳細手順の例を示すフローチャートである。図9のステップS20が開始されると、図12を参照し、履歴ツリー統合部520は、処理対象の履歴ツリー中の各ノードについて、子ノードへの参照情報を生成する(ステップS200)。各ノードの子ノードは、処理対象の履歴ツリーを表す情報レコード(図5,図10参照)において各ノードの管理IDを親IDの値として有する情報レコードを検索することで得られる。また、ステップS200で生成される参照情報は、各ノードが有する属性項目(派生関係DB110のレコード中の各項目)のうち、履歴ツリー統合処理において着目する属性項目として予め設定された着目属性によって記述される。着目属性は、例えば、システムの管理者などにより、図9の例の手順の処理を開始する前に設定される。図5を参照し、「操作種別」及び「役割」が着目属性として予め設定されている場合、図5の例の表の管理ID"Doc1"のノードの子ノードへの参照情報は、"Doc1"を親IDとして有する管理ID"Doc2"に対応づけられた操作種別「編集」及び役割「文房具購買」により表され、例えば、「操作種別:編集,役割:文房具購買」と記述される。なお、以下の説明では、操作種別及び役割が着目属性として設定されているものとする。
ステップS200の処理では、ワークフローを表すグラフ構造に含まれる各ノードを着目属性で表すことになる。よって、ステップS200の処理は、処理対象の履歴ツリー中の各ノードをワークフロー中のノードとして生成し、ワークフロー中の各ノードの子ノードへの参照情報を生成する処理であるとも言える。
ステップS200の後、履歴ツリー統合部520は、処理対象の履歴ツリー中のノードから、未処理のノードを1つ選択する(ステップS202)。そして、選択したノードと着目属性のすべてが同一であるノードが他に存在するか否かを判定する(ステップS204)。例えば、図11を参照し、履歴ツリー"Tree0"の管理ID"Doc1"のノードをステップS202で選択した場合、着目属性である操作種別及び役割の各項目の値が"Doc1"のノードと同一であるノード、つまり、操作種別が「登録」かつ役割が「開発」であるノードを検索する。本例では、操作種別が「登録」かつ役割が「開発」であるノードは、管理ID"Doc11"及び"Doc21"のノードである(図10,図11参照)ため、これらのノードが検索結果として得られる。よって、この管理ID"Doc1"のノードがステップS202で選択される本具体例では、ステップS204でYESと判定され、処理はステップS206に進む。一方、ステップS202で選択されたノードと着目属性のすべてが同一であるノードが他に存在しない場合は、処理はステップS212に進む。
ステップS206では、ステップS202で選択したノードと、ステップS204の検索結果のノードと、を1つのノードに統合する処理が行われる。この統合処理では、例えば、統合される各ノードで共通する着目属性を含む1つのノードの情報が生成される。このとき生成される1つのノードの情報は、統合元の各ノードの子ノードへの参照情報を含む。ステップS202で管理ID"Doc1"を選択する上述の具体例の場合、ステップS206で、管理ID"Doc1"のノードと、ステップS204で検索された管理ID"Doc11"及び"Doc21"のノードと、の3つのノードが1つに統合される。統合された結果のノードの情報は、統合元の3つのノードで共通の着目属性「操作種別:登録,役割:開発」を含む。また、統合された結果のノードの情報は、さらに、管理ID"Doc1"のノードの子ノードへの参照情報「操作種別:編集,役割:文房具購買」、管理ID"Doc11"のノードの子ノードへの参照情報「操作種別:編集,役割:機械購買」、及び管理ID"Doc21"のノードの子ノードへの参照情報「操作種別:編集,役割:文房具購買」を含む。
次に、ステップS206で統合した結果のノードの情報に含まれる子ノードへの参照情報に重複があるか否かが判定される(ステップS208)。管理ID"Doc1","Doc11","Doc21"のノードを統合する上述の具体例の場合、管理ID"Doc1"のノードの子ノードへの参照情報と管理ID"Doc21"のノードの子ノードへの参照情報とが、いずれも「操作種別:編集,役割:文房具購買」で重複する。
統合した結果のノードの情報に含まれる子ノードへの参照情報に重複がある場合(ステップS208でYES)、重複する複数の参照情報を1つの参照情報に統合する(ステップS210)。例えば、重複する複数の参照情報のうち1つだけを残して他を削除する。ステップS210の後、処理はステップS212に進む。一方、統合した結果のノードの情報に含まれる子ノードへの参照情報に重複がない場合(ステップS208でNO)は、ステップS210の処理を行わずにステップS212に進む。
ステップS212では、処理対象の履歴ツリー中のノードのうち未処理のノードがあるか否かを判定する。ここで、「未処理のノード」とは、ステップS202で選択されたノード及びステップS206で統合の対象となったノードの他のノードを意味する。未処理のノードがあれば、処理はステップS202に戻り、未処理のノードがなければ、処理はステップS214に進む。
ステップS214では、履歴ツリー統合部520は、処理済の各ノードについて、親ノードへの参照情報を生成する。例えば、各ノードについて、当該ノードの着目属性の値を子ノードへの参照情報として有するノードを検索し、検索結果のノードの着目属性の値を親ノードへの参照情報とする。なお、履歴ツリーの根ノードに対応するノードは、親ノードを有しないため、そのノードについての親ノードへの参照情報は空となる。
ステップS214の後、履歴ツリー統合処理は終了する。履歴ツリー統合処理の結果として、1つのグラフ構造が生成される。グラフ構造の各ノードは、統合元の履歴ツリー中の1以上の文書(ノード)に対応する。グラフ構造のノード間を結ぶ辺は、統合元の履歴ツリーにおける文書間の親子関係に対応し、グラフ構造の各ノードについて生成される子ノードへの参照情報又は親ノードへの参照情報で表される。
図13に、図11に例示する履歴ツリー"Tree0","Tree1","Tree2"を処理対象として図12の例の履歴ツリー統合処理を行った結果として生成されるグラフ構造(ワークフロー)の例を示す。図13のノードNode0は、図11の管理ID"Doc1","Doc11","Doc21"のノードが統合されて生成されたノードである。ノードNode1は、図11の管理ID"Doc2","Doc22"のノードの統合の結果であり、ノードNode2は、図11の管理ID"Doc12"のノードに対応する。また、ノードNode3、ノードNode4、及びノードNode5は、それぞれ、図11における、管理ID"Doc3","Doc13","Doc23"の3つのノード、管理ID"Doc4","Doc14","Doc24"の3つのノード、及び管理ID"Doc5","Doc15","Doc25"の3つのノードを統合した結果のノードである。図13の各ノードNode0,…,Node5は、ワークフロー中の1つのアクティビティ(作業工程)を表す。また、図13のノード間を接続する矢印は、親ノードから子ノードへ向かう方向を示し、その矢印の方向の順に各ノードのアクティビティが実行されることを示す。
履歴ツリー統合部520は、履歴ツリー統合処理の結果として生成したワークフローをワークフローDB540に記憶させる。例えば、生成したワークフロー中の各ノードの識別情報に対応づけて、当該ノードの着目属性の値、当該ノードの親ノードへの参照情報、及び当該ノードの子ノードへの参照情報がワークフローDB540に登録される。
再び図9の例の手順の説明に戻り、履歴ツリー統合処理(ステップS20,図12)が終了してワークフローが生成されると、ワークフロー処理部530の分岐・結合検出部532により分岐・結合の検出処理が行われる(ステップS30)。分岐・結合検出部532は、ワークフローDB540を参照し、履歴ツリー統合部520が生成したワークフローに含まれる分岐点及び結合点を検出する。分岐・結合検出部532は、例えば、処理対象のワークフロー中のノードのうち、複数の子ノードへの参照情報を有するノードを分岐点(に対応するノード)として検出し、複数の親ノードへの参照情報を有するノードを結合点(に対応するノード)として検出する。図13に例示するワークフローが処理対象である場合、複数の子ノードを有するノードNode0が分岐点として検出され、複数の親ノードを有するノードNode3が結合点として検出される。
分岐・結合の検出処理(ステップS30)において分岐点が検出された場合(ステップS32でYES)、検出された分岐点に対応する分岐ノードが生成される。また、結合点も検出されていた場合は、検出された結合点に対応する結合ノードが生成される。生成された分岐ノードは、ワークフローにおいて、分岐点として検出されたノードとその子ノードとの間に挿入される。また、結合ノードが生成された場合、この結合ノードは、ワークフローにおいて、結合点として検出されたノードとその親ノードとの間に挿入される(以上、ステップS34)。図13に例示するワークフローの場合、分岐点として検出されたノードNode0に対応する分岐ノード及び結合点として検出されたノードNode3に対応する結合ノードが生成される。分岐ノードは、ワークフローにおいて分岐点のノードNode0とその子ノードNode1,Node2との間に挿入され、結合ノードは、ワークフローにおいて結合点のノードNode3と親ノードNode1,Node2との間に挿入される。
図14は、図13の例のワークフローに対してステップS34の処理を行った結果のワークフローの例を示す。
図14の例の分岐ノードSは、分岐点として検出されたノードNode0を親ノードとして有し、図13の例においてノードNode0の子ノードであるノードNode1,Node2を子ノードとして有する。分岐ノードSのワークフローへの挿入は、例えば、以下の手順で行えばよい。まず、ワークフローDB540において、分岐点のノードNode0の子ノードへの参照情報を複製して分岐ノードSの子ノードへの参照情報として登録した上で、ノードNode0の子ノードへの参照情報について分岐ノードSを示すように書き換える。さらに、分岐ノードSの親ノードへの参照情報についてノードNode0を示すように設定する。そして、分岐ノードSの子ノードとなるノードNode1,Node2のそれぞれについて、親ノードへの参照情報を、分岐ノードSを示すように書き換える。
また、図14の例の結合ノードJは、結合点として検出されたノードNode3を子ノードとして有し、図13の例においてノードNode3の親ノードであるノードNode1,Node2を親ノードとして有する。結合ノードJのワークフローへの挿入は、例えば、以下の手順で行えばよい。まず、ワークフローDB540において、結合点のノードNode3の親ノードへの参照情報を複製して結合ノードJの親ノードへの参照情報に設定した上で、ノードNode3の親ノードへの参照情報について結合ノードJを示すように書き換える。さらに、結合ノードJの子ノードへの参照情報についてノードNode3を示すように設定する。そして、結合ノードJの親ノードとなるノードNode1,Node2のそれぞれについて、子ノードへの参照情報を、結合ノードJを示すように書き換える。
図9の例の手順の説明に戻り、分岐ノード・結合ノードのワークフローへの挿入処理(ステップS34)の後、各分岐ノードについて、分岐種類判定部534による分岐種類判定処理(ステップS40)が行われる。ステップS40の分岐種類判定処理は、ワークフローを生成する元になった統合元の履歴ツリーを用いて行われる。統合元の履歴ツリーのそれぞれが、生成されたワークフロー中のいずれの経路に対応するかを確認し、各分岐ノードにおける分岐の態様を検出することで分岐の種類を判定する。
本実施形態の例では、分岐種類判定部534は、各分岐ノードが図15の表に示す3種類の分岐種類のいずれに該当するかを判定する。図15の表は、統合元の複数の履歴ツリーにおける分岐ノードの状態と当該状態に対応する分岐種類の例を示す。すべての履歴ツリーにおいて、ワークフロー中の分岐ノードのすべての分岐先(分岐ノードの子ノード)に進む処理経路が存在する場合、分岐種類は「And-Split(並行分岐)」と判定される。また、1つの履歴ツリーにつき、分岐ノードの分岐先のいずれか1つに進む処理経路のみが存在する場合、分岐種類は「OR-Split(排他的分岐)」と判定される。さらに、各履歴ツリーにおいて、分岐ノードの複数の分岐先に進む処理経路が存在する場合、分岐種類は「Multiple Choice(多項選択)」と判定される。
以下、図16から図18を参照し、分岐種類判定処理(図9のステップS40)の詳細手順の例を説明する。
分岐種類判定処理が開始されると、まず、図16のステップS400で、分岐種類判定部534は、処理対象のワークフローを生成する元となった統合元の複数の履歴ツリーのうちの1つを選択する。そして、選択した履歴ツリーの根ノードを注目履歴ノードとし、処理対象のワークフローの根ノード(親ノードへの参照情報が空であるノード)を注目フローノードとする(ステップS410)。例えば、図14の例のワークフローが処理対象であり、図11の例の履歴ツリー"Tree0"をステップS400で選択したとすると、ステップS410で、注目履歴ノードは管理ID"Doc1"のノードとなり、注目フローノードはノードNode0となる。
次に、注目履歴ノード及び注目フローノードの遷移の状態を確認する遷移チェック処理(ステップS420)が行われる。
図17に、遷移チェック処理の詳細手順の例を示す。図17を参照し、遷移チェック処理(ステップS420)が開始されると、注目履歴ノードの着目属性の値と注目フローノードの着目属性の値とが一致するか否かが判定される(ステップS422)。一致する場合はステップS424に進み、一致しない場合はステップS436でエラー処理を行って遷移チェック処理を終了する。エラー処理では、例えば、この時点での注目履歴ノード及び注目フローノードを特定する情報と、これらのノードの着目属性の値が一致しなかった旨を表す情報と、をワークフローDB540に記憶させる。
ステップS424では、注目履歴ノード及び注目フローノードのそれぞれが子ノードを有するか否かを判定する。注目履歴ノードの子ノードの有無は、注目履歴ノードが属する履歴ツリー中のノードに対応する各レコードのうち注目履歴ノードの管理IDの値を親IDとして有するレコードが存在するか否かにより判定される。また、注目フローノードの子ノードの有無は、注目フローノードが子ノードへの参照情報を有するか否かにより判定される。両者に子ノードが存在すればステップS426に進み、いずれか一方又は両方に子ノードが存在しなければ遷移チェック処理は終了する。
ステップS426では、注目フローノードの子ノードが分岐ノードであるか否かが判定される。分岐ノードであれば、処理は図18のステップS440に進み、分岐ノードでなければ、処理はステップS428に進む。
ステップS428では、注目フローノードの子ノードが結合ノードであるか否かが判定される。結合ノードでなければ、現在の注目フローノードの子ノードを新たな注目フローノードとし(ステップS430)、結合ノードであれば、当該結合ノードの子ノードを新たな注目フローノードとする(ステップS432)。
ステップS430又はステップS432で新たな注目フローノードが設定されると、注目履歴ノードの子ノードが新たな注目履歴ノードとして設定される(ステップS434)。ステップS434の後、新たな注目フローノード及び注目履歴ノードに対して図17の例の遷移チェック処理(ステップS420)を再帰的に呼び出して実行する。
以下、図18を参照し、注目フローノードの子ノードが分岐ノードであると判定された場合(ステップS426でYES)に実行される処理の手順の例を説明する。図18を参照し、注目履歴ノードの子ノードごとに、ステップS440,S442,S444,S420の処理が実行される。
まず、当該分岐ノードの分岐先のノードのうち、当該子ノードと着目属性の値が一致するものを選択する(ステップS440)。次に、現在の処理対象の履歴ツリーに関し、選択した分岐先のノードに対応する文書の存在を遷移テーブルに記録する(ステップS442)。ここで、遷移テーブルとは、ワークフロー中の各分岐ノードに関連づけてワークフローDB540に記憶されるテーブルであって各履歴ツリーにおいて分岐ノードに対応する部分の処理経路を表すテーブルである。図19に、遷移テーブルの例を示す。
図19は、図14の例のワークフローの分岐ノードSに関連づけられた遷移テーブルの例である。図19の例の表の各行は、図14の例のワークフローの統合元の各履歴ツリーに対応し、図19の例の表の各列は、図14の例のワークフローにおける分岐ノードの分岐先の各ノードに対応する。各行と各列とが交差する欄の値は、当該行の履歴ツリーにおいて、当該列のノードに対応する文書の有無を表す。図19の例において、値「1」は、当該行の履歴ツリーにおいて当該列のノードに対応する文書が存在することを示し、値「0」は、対応する文書が存在しないことを示す。図19の例の表は、すべての履歴ツリー"Tree0","Tree1","Tree2"に関する遷移チェック処理(図16のステップS420)が終了した後の遷移テーブルの値を示すが、遷移テーブル中の各値は、分岐種類判定処理(図16)の開始時に例えば「0」に初期化しておく。
図19の例の遷移テーブルを参照して図18の例のステップS440,S442の具体例を説明する。例えば、現在の処理対象の履歴ツリーが"Tree0"であり、現在の注目履歴ノードが"Doc1"である場合、注目履歴ノードの子ノード"Doc2"と着目属性の値が一致する分岐先のノードNode1がステップS440で選択される。そして、ステップS442で、図19の例の遷移テーブルにおいて、履歴ツリー"Tree0"の行と分岐先のノードNode1の列とが交差する欄に値「1」が設定される。この例のように遷移テーブルに値を設定することで、処理対象の履歴ツリーにおいて、ワークフローの分岐ノードのいずれの分岐先に進む文書が存在するかが記録される。
ステップS442の後、当該子ノードを新たな注目履歴ノードとし、選択した分岐先のノードを新たな注目フローノードとした上で(ステップS444)、これらの新たな注目履歴ノード及び注目フローノードに対して図17の例の遷移チェック処理を再帰的に呼び出して実行する。
図16の例の手順の説明に戻り、遷移チェック処理(ステップS420)が終了すると、未処理の履歴ツリーがあるか否かが判定される(ステップS450)。未処理の履歴ツリーがあれば、処理はステップS400に戻り、未処理の履歴ツリーの中から1つを選択してステップS410以下の処理を繰り返す。未処理の履歴ツリーがなければ、ステップS460に進む。
ステップS460では、各分岐ノードに関連づけられた遷移テーブルを参照し、分岐種類を特定する。例えば、遷移テーブルを参照することで、その分岐ノードについての履歴ツリーの状態が図15に例示する3つの分岐種類のいずれに該当するかを判定する。図14の例の分岐ノードSの場合、図19の例の遷移テーブルを参照し、1つの履歴ツリーにつき、分岐ノードの分岐先のいずれか1つに進む処理経路のみが存在するため、分岐種類は「OR-Split」となる(図15)。各分岐ノードについて特定された分岐種類は、ワークフローDB540に記憶される。ステップS460の後、分岐種類判定処理は終了する。
再び図9を参照し、分岐種類判定処理(ステップS40)が終了すると、ワークフロー中の分岐ノードのうち、分岐種類が排他的な分岐(OR-Split)であると判定されたものが存在するか否かを判定する(ステップS45)。排他的な分岐が存在する場合、分岐条件設定部536により分岐条件設定処理(ステップS50)が行われ、排他的な分岐が存在しない場合、ステップS50を行わずに処理はステップS60に進む。
図20に、分岐条件設定処理(図9のステップS50)の詳細手順の例を示す。分岐条件設定処理が開始されると、分岐条件設定部536は、まず、排他的な分岐である分岐ノードを1つ選択し(ステップS500)、次に、ワークフローにおける分岐ノードの親ノードを取得する(ステップS502)。そして、統合元の履歴ツリーを1つ選択し(ステップS504)、選択した履歴ツリーにおいて、ステップS502で取得した親ノードに対応するノードを取得する(ステップS506)。ステップS506の処理は、例えば、履歴ツリーのノードの中から、ワークフロー中の分岐ノードの親ノードと同一の着目属性を有するノードを抽出することで実現される。
ステップS506で取得したノードに分岐条件の設定が存在すれば(ステップS508でYES)、当該設定された分岐条件と取得したノードの子ノードの着目属性とを対にして分岐ノードの分岐条件の属性としてワークフローDB540に記憶させる(ステップS510)。例えば、図14の例の分岐ノードSが図20の例の手順の処理の対象であるときに、ステップS504で選択された履歴ツリーが"Tree0"である場合、ワークフローにおいて分岐ノードSの親ノードNode0に対応する履歴ツリー中のノード"Doc1"に設定された分岐条件「${物品種別}=“文房具”」(図5参照)と、"Doc1"の子"Doc2"の着目属性「操作種別:編集,役割:文房具購買」と、を対にして分岐ノードSの分岐条件の属性とする。また、ステップS504で選択された履歴ツリーが"Tree1"であれば、分岐ノードSの親ノードNode0に対応する履歴ツリー中のノード"Doc11"の分岐条件「${物品種別}=“コンピュータ”」(図10参照)と、"Doc11"の子"Doc12"の着目属性「操作種別:編集,役割:機械購買」と、を対にして分岐ノードSの分岐条件の属性とする。これにより、分岐ノードSの分岐条件の属性は、分岐ノードSから着目属性「操作種別:編集,役割:文房具購買」を有する分岐先Node1へ進む条件が「${物品種別}=“文房具”」であり、着目属性「操作種別:編集,役割:機械購買」を有する分岐先Node2へ進む条件が「${物品種別}=“コンピュータ”」であることを表すものとなる。
ステップS506で取得したノードに分岐条件の設定が存在しなければ(ステップS508でNO)、エラー処理を行う(ステップS516)。このエラー処理では、例えば、ワークフローの分岐点に相当する当該履歴ツリーのノードに分岐条件が設定されていない旨を表す情報をワークフローDB540に記憶させる。
ステップS510又はステップS516の後、統合元の履歴ツリーのうち、未処理のものであって、処理済の履歴ツリーと異なる分岐先に進む経路を有するものがあるか否かを判定する(ステップS512)。この判定は、例えば、処理対象の分岐ノードの遷移テーブルを参照して行う。異なる分岐先に進む経路を有する履歴ツリーがあれば、ステップS504以降の処理が繰り返され、そのような履歴ツリーがなければ、ステップS514に進む。
ステップS514では、ワークフローにおいて排他的な分岐である分岐ノードのうち、未処理の分岐ノードがあるか否かが判定される。未処理の分岐ノードがあれば、処理はステップS500に戻り、未処理の分岐ノードがなければ、分岐条件設定処理は終了する。
図9の例の手順の説明に戻り、分岐条件設定処理が終了すると、結合種類設定部538により、結合種類の設定が行われる(ステップS60)。ステップS60で、結合種類設定部538は、例えば、ワークフローにおける結合ノードの子ノードに対応する履歴ツリーのノードに設定された結合種類を取得し、取得した結合種類を当該結合ノードに関連づけてワークフローDB540に記憶させる。
図21に結合種類の例を示す。図21の例の表は、5つの結合種類「OR-Join」,「AND-Join」,「Multiple-Merge」,「Discriminator」,「Synchronizing-Merge」と、各結合種類の結合ノードにおける動作と、各結合種類の結合ノードと対となる分岐ノードの分岐種類と、を示す。図21に例示する分岐種類は、図15の例の表を参照して説明した分岐種類と同様である。図21の例の表の内容を予め記憶装置に記憶させておき、この表を参照して、ステップS60で取得した結合種類が、つまり、ユーザが設定した結合種類が、当該結合ノードと対となる分岐ノードの分岐種類に対応するものであるか否かを判定してもよい。対応するものであれば、上述のように、取得した結合種類を処理対象の結合ノードの結合種類としてワークフローDB540に登録する。対応するものでない場合は、例えば、その旨を図示しない表示装置に表示させ、取得した結合種類のワークフローDB540への登録は行わない。
ステップS60が終了すると、図9の例の手順の処理は終了する。
以上、図9〜図21を参照し、複数の履歴ツリーからワークフローを生成する処理の例を説明した。以上で説明した例では、排他的な分岐ノードの分岐条件の設定は、ユーザが文書を操作する際に設定した分岐条件を履歴ツリーから取得することで行われる。他の例では、ユーザが設定した分岐条件を用いずに分岐ノードの分岐条件の設定を行ってもよい。
図22は、分岐条件の設定処理の他の例の手順を示すフローチャートである。
まず、処理対象の分岐ノードの遷移テーブルを取得する(ステップS70)。次に、取得した遷移テーブルを参照して、同一の分岐先へ進む処理経路を有する2つの履歴ツリーを特定して選択する(ステップS72)。例えば、図14の例のワークフローの分岐ノードSが処理対象である場合、図19の例の遷移テーブルを参照し、同一の分岐先へ進む処理経路を有する履歴ツリーとして、履歴ツリー"Tree0"及び"Tree2"(図11)が選択される。
ステップS72で取得した履歴ツリーそれぞれから、ワークフローにおいて処理対象の分岐ノードの親ノードに対応するノードを取得する(ステップS74)。図14の例のワークフローを参照する上述の例の場合、分岐ノードSの親ノードNode0に対応する履歴ツリー"Tree0","Tree2"中のノード"Doc1","Doc21"が取得される。
そして、分岐条件設定部536は、ステップS74で取得されたノード間で属性情報を比較し(ステップS76)、同一の値を有する属性を条件候補属性として抽出する(ステップS78)。同一の分岐先に進む条件となる属性を得るために、同一の値を有する属性を抽出する。図23に、ノード"Doc1","Doc21"の属性情報を比較した場合にステップS78で抽出される条件候補属性の例を示す。図23を参照し、"Doc1","Doc21"の間で同一の値を有する属性「操作種別」、「役割」、「ファイル名」及び「物品種別」が条件候補属性として抽出される。また、抽出された属性の他の属性(図23の例の表で斜線を引いた属性)は、条件の候補から除外される。
その後、ステップS70で取得した遷移テーブルを再び参照し、ワークフローにおいて異なる分岐先へ進む処理経路を有する2つの履歴ツリーを特定して選択する(ステップS80)。図14の分岐ノードSの例の場合、例えば、履歴ツリー"Tree0"及び"Tree1"が選択される。
ステップS80で選択された履歴ツリーのそれぞれから、ワークフローにおいて分岐ノードの親ノードに対応するノードが取得される(ステップS82)。例えば、履歴ツリー"Tree0"及び"Tree1"から、図14のノードNode0に対応するノード"Doc1","Doc11"が取得される。
そして、ステップS82で取得した2つのノード間で、ステップS78で抽出された条件候補属性の値を比較し(ステップS84)、異なる値を有する属性を分岐条件の属性として抽出する(ステップS86)。図24に、抽出される分岐条件の属性の例を示す。図24を参照し、破線で囲んだ属性「物品種別」が分岐条件の属性として抽出される。このように、ステップS86では、同一の分岐先へ進むノード間の属性の比較から抽出された条件候補属性(図23)のうち、異なる分岐先へ進むノード間の属性の比較において互いに異なる値を有する属性が分岐条件の属性として抽出される。抽出された分岐条件の属性は、異なる分岐先へ進む各ノードにおける値と、その分岐先の着目属性の値と、を対にして分岐ノードの分岐条件の属性としてワークフローDB540に登録される。
以上で説明したように生成されるワークフローに対して、業務管理サーバ50は、ワークフローの各ノードのラベル付けの設定を受け付けても良い。例えば、図14の例のワークフローを図示しない表示装置に表示させてワークフローを管理する管理者などに提示し、ラベルの設定を受け付ける。業務管理サーバ50は、管理者などによるラベルの設定を受け付けると、ワークフローDB540において、各ノードに設定されたラベルの内容を記憶しておく。図25に、ラベルの設定を受け付けた後のワークフローを図式化した例を示す。図25では、各ノードNode0,…,Node5に設定されたラベルの内容(「文書を登録する」,「文房具を見積する」など)を示す。例えば図25のような図を表示装置に表示させることで、図式化したワークフローが管理者やユーザなどに提示される。
以上、図9の例の手順の処理により生成されるワークフローは、各作業工程に対応するノードと共に、分岐ノード及び結合ノードを含む。また、分岐ノード及び結合ノードには、その分岐・結合の種類や分岐条件などの属性情報が設定される。このように生成されたワークフローは、例えば、ワークフロー図の記述法の1つであるBPMN(Business Process Modeling Notation,ビジネスプロセスモデリング表記法ver.1.0, 2004年5月3日,著作権者Business Process Management Initiative)に従って図式化できる。
以上で説明した第1実施形態の例では、実際に業務が行われる過程で生成されて文書管理サーバ10に登録されたID付き文書の操作の履歴を用いて、ワークフローを構成する。各作業工程を担当するユーザが業務の全体の流れを把握していなくても、各自が業務における作業を実行して当該作業工程に対応するID付き文書を文書管理サーバ10に登録すれば、業務管理サーバ50によりワークフローが抽出される。
<第2実施形態>
以下、第2実施形態の例を説明する。第2実施形態においても、業務管理システムの構成は、第1実施形態における図1の例のシステム構成と同様であってよい。
第2実施形態では、実際に業務を行った結果の文書の操作の履歴を文書管理サーバ10に登録する代わりに、業務における文書の操作及び授受の履歴を試験的に実現して文書管理サーバ10に登録する。業務における文書の履歴を試験的に実現する(以下、「業務の試行」を行うとも言う)場合、業務の各作業工程を担当するユーザは、ID付き文書の文書内容には着目せずに、自己の作業工程に対応するID付き文書の文書管理サーバ10への登録及び次の担当者へのID付き文書の受け渡しを行う。また、本例の業務の試行では、ワークフローの分岐点に相当する作業工程の担当者は、すべての分岐先のそれぞれに対応するID付き文書を生成して文書管理サーバ10に登録する。例えば、分岐点に相当する作業工程の担当者は、まず、分岐先のうちの1つの担当者に渡す文書として、自分の前の作業工程の担当者から渡されたID付き文書の管理IDを親IDとする新たなID付き文書を文書管理サーバ10に登録する。その後、当該新たなID付き文書を、残りの分岐先の数だけ複製し、複製した各ID付き文書をさらに文書管理サーバ10に登録する。文書管理サーバ10に登録された各分岐先に対応するID付き文書は、各分岐先の作業工程の担当者に渡される。
以上のような業務の試行により、当該業務のワークフローに対応する文書の履歴が文書管理サーバ10に登録される。また、ワークフローが分岐を含む場合、すべての分岐先それぞれに進む経路に対応する文書の履歴が文書管理サーバ10に登録される。なお、業務の試行を行う場合も、実際に業務を行う場合と同様に、各ユーザは、自分の担当の作業の内容と次の作業工程の担当者とを把握してさえいれば、業務の流れ全体を把握していなくてもよい。
図26に、第2実施形態のクライアント端末20の内部構成の例を示す。図26の例のクライアント端末20は、図2に例示する第1実施形態におけるクライアント端末20が備える各構成要素に加えて、文書操作部200において分岐時処理部206を備える。図26の例のクライアント端末20において、分岐時処理部206の他の各構成要素は、図2の例のクライアント端末20と同様である。
分岐時処理部206は、業務の試行において、ワークフローの分岐点に相当する作業工程の担当者からの指示に応じて、各分岐先に対応するID付き文書を生成する処理を行う。例えば、分岐点の作業工程の担当者であるユーザの指示により、まず、分岐先のうちの1つの担当者に渡されるID付き文書が、図2を参照して説明したのと同様の文書操作部200の処理により生成され、登録処理部210により文書管理サーバ10に登録される。このとき生成されるID付き文書には、例えば図7の例の設定画面により、対応する分岐先への分岐条件が設定される。その後、当該ユーザは、文書操作部200を用いて、生成されたID付き文書を残りの分岐先の数だけ複製する。そして、当該ユーザは、複製後の各文書を指定して、文書操作部200の操作メニュー上で「分岐時新規登録」を指示する。この指示に応じて分岐時処理部206は、ID割り当て部202に依頼して、複製後の各文書に対して付与する新たな管理IDを生成させる。そして、分岐時処理部206は、派生関係組込部204に依頼して、複製後の各文書のメタ情報として、ID割り当て部202が生成した新たな管理IDを管理IDとし、親IDを「なし」とするメタ情報を生成させる。これにより、複製後の各文書は新たなID付き文書となる。また、複製後の各ID付き文書のメタ情報では、ログ情報中の操作種別の値は「分岐時新規登録」に設定され、かつ、ログ情報中に複製元のID付き文書の管理IDが「分岐元」として組み込まれる。さらに、分岐時処理部206は、複製後の各ID付き文書について、それぞれ対応する分岐先へ分岐する分岐条件の設定のユーザ入力を受け付ける。受け付けられた分岐条件は、派生関係組込部204により複製後の各ID付き文書のログ情報に組み込まれる。
以上のように生成された操作種別「分岐時新規登録」の各ID付き文書は、登録処理部210により文書管理サーバ10に登録される。
第2実施形態の例の文書管理サーバ10は、図4に例示する第1実施形態における文書管理サーバ10と同様の構成を有していてよい。ただし、派生関係DB110において、操作種別の項目の値として「分岐時新規登録」を有するレコードが登録され得る。さらに、操作種別が「分岐時新規登録」であるレコードには、そのレコードに対応するID付き文書の「分岐元」が含まれる。
以下、図27〜図32を参照し、業務の試行においてクライアント端末20が行う処理及び文書管理サーバ10に登録される文書の履歴の一例を説明する。
まず、図27〜図29を参照し、説明のために用いる業務の具体例を説明する。
図27は、本具体例の業務のワークフローを図式的に示す図である。図28は、図27に例示するワークフローの各作業工程の内容を示す。図27及び図28の例が示すワークフローでは、まず、作業工程「業務1」において、役割「開発」のユーザにより操作「新規登録/起案」が行われ、次に、作業工程「業務2」で、役割「開発管理」のユーザにより操作「進達」が行われる。その後、ワークフローは分岐ノード「分岐1」で2つの分岐先に分岐し、一方の分岐先である「業務3」では、役割「開発管理」のユーザによる操作「承認/部長」が行われ、他方の分岐先である「業務4」では、役割「開発管理」のユーザによる操作「承認/課長」が行われる。「業務3」又は「業務4」の後、ワークフローは結合ノード「結合1」で結合し、最後に「業務5」で役割「開発」のユーザが操作「アーカイブ」を行うことで終了する。
図29(a)及び図29(b)は、それぞれ、図27及び図28の例のワークフローにおける分岐ノード「分岐1」の分岐条件及び結合ノード「結合1」の結合種類を示す。図29(a)を参照し、「分岐1」では、「決済額が20万円を超える」という条件を満たす場合に「業務3」に進み、「決済額が20万円以下」という条件を満たす場合に「業務4」に進む。また、図29(b)を参照し、「結合1」は、その結合種類が「OR-Join」であり、ワークフローに従った文書の操作実行時に文書の入力を1つだけ受けて当該文書を通過させて「業務5」に進む結合ノードである。
図27〜図29を参照して以上で説明した例の業務について業務の試行を行った場合、文書管理サーバ10の派生関係DB110には、例えば、図30のようなデータ内容が登録される。
図30を参照し、第2実施形態において派生関係DB110に登録されるデータ内容の例を示す。図30の例の派生関係DB110の各ID付き文書に対応するレコードは、管理ID、親ID、ツリーID、操作種別、操作者、役割、操作日時、分岐条件、結合種類、及び分岐元の各項目を含む。このうち、「分岐元」以外の項目の意味は、図5の例の派生関係DB110を参照してすでに説明したとおりである。「分岐元」は、分岐点に相当する作業工程(つまり、ワークフローにおける分岐ノードの親ノードが表す作業工程)の担当者がクライアント端末20において「分岐時新規登録」を指示したときに生成されるID付き文書の複製元のID付き文書の管理IDを表す。
また、図31は、図30に例示するデータ内容を派生関係DB110が有する場合の履歴ツリーの例である。
以下、図30及び図31に例示する文書の履歴を例に取り、業務の試行の様子を説明する。なお、図30の例の表では、全レコードを時系列順(操作日時の順)で示すのではなく、同じツリーIDを有するレコード毎に時系列順で示している。
まず、図27〜図29の例のワークフローの「業務1」の担当者userAは、文書管理サーバ10に未登録の文書をクライアント端末20上で作成し、「業務1」の操作種別である「新規登録/起案」をID付き文書の操作種別として指定して文書管理サーバ10への登録を指示する。この指示に応じて、クライアント端末20の文書操作部200は、管理ID"Doc31"、親ID「なし」、操作種別「新規登録/起案」、操作者「userA」、役割「開発」であるID付き文書"Doc31"を生成する。ID付き文書"Doc31"は文書管理サーバ10に送られて派生関係DB110に登録される。文書管理サーバ10は、ID付き文書"Doc31"の親IDが「なし」であることから、このID付き文書"Doc31"を根とする履歴ツリーのツリーID"Tree3"を新たに生成して管理ID"Doc31"のレコードに登録する。
なお、ID付き文書"Doc31"の文書内容は、実際の業務を行うときに操作種別「新規登録/起案」の文書が備えるべき内容を備えていなくてよい。この文書内容は空であってもよいし、例えば、当該ID付き文書が業務の試行に係る文書であることを表す情報を含んでいてもよい。図30及び図31を参照して以下の説明で言及するID付き文書の文書内容についても同様である。
ID付き文書"Doc31"は、「業務1」の次の「業務2」の担当者であるuserBに電子メールなどにより渡される。「業務2」は、ワークフローの分岐が生じる作業工程であるため、userBのクライアント端末20では、分岐時処理部206による上述の処理が行われる。まず、userBは、クライアント端末20において、userAから受け取ったID付き文書"Doc31"を文書操作部200により操作し(ここでは、例えば、単に「閲覧」するだけでよい)、「業務2」の操作種別である「進達」を指定して文書管理サーバ10へのID付き文書の登録を指示する。この指示に応じて、新たなID付き文書"Doc32"が生成され、文書管理サーバ10に登録される。ID付き文書"Doc32"の親IDは"Doc31"、操作種別は「進達」、操作者は「userB」、役割は「開発管理」である。また、userBは、ID付き文書"Doc32"について、「業務2」の後の分岐先のうちの1つに対応する分岐条件を設定する。例えば、文書操作部200は、分岐条件の設定を望む旨のuserBからの指示を受けて、クライアント端末20の表示装置に図32の例のような表示画面を表示させ、userBによる分岐条件の設定を受け付ける。本例では、userBは、図32の例の表示画面を用いて、ID付き文書"Doc32"について、2つの分岐先のうち「業務3」へ進む条件「決済金額が20万を超える」を設定したとする。なお、文書管理サーバ10において、ID付き文書"Doc32"のツリーIDは、親文書である"Doc31"と同じ"Tree3"に設定される。
さらに、userBは、ID付き文書"Doc32"をクライアント端末20上で複製する。そして、この複製後の文書を指定して、文書操作部200の操作メニュー上で「分岐時新規登録」を指示する。この指示に応じて、分岐時処理部206により、新たなID付き文書"Doc41"が生成される。ID付き文書"Doc41"の親IDは「なし」、操作種別は「分岐時新規登録」に設定される。また、ID付き文書"Doc41"のログ情報には、「分岐元」として、複製元のID付き文書"Doc32"の管理ID"Doc32"が組み込まれる。さらに、userBは、例えば図32の例の表示画面を用いて、ID付き文書"Doc41"の分岐条件として、残りの分岐先「業務4」へ進む条件「決済金額が20万円以下」を設定する。ID付き文書"Doc41"をuserBのクライアント端末20から受け取った文書管理サーバ10は、ID付き文書"Doc41"の親IDが「なし」であることから、ID付き文書"Doc41"を根とする新たな履歴ツリーのツリーID"Tree4"を生成して派生関係DB110に登録する。
以上で説明したuserBの操作によって、「業務2」の後の2つの分岐先「業務3」及び「業務4」のそれぞれに対応するID付き文書"Doc32","Doc41"が文書管理サーバ10に登録される。そして、ID付き文書"Doc32"は、userBから「業務3」の担当者であるuserCに渡され、ID付き文書"Doc41"は、userBから「業務4」の担当者であるuserDに渡される。
ID付き文書"Doc32"を受け取ったuserCは、クライアント端末20上で、ID付き文書"Doc32"を指定し、自己が担当する「業務3」の操作種別「承認/部長」を指定して文書管理サーバ10へのID付き文書の登録を指示する。これに応じて、親IDを"Doc32"とする新たなID付き文書"Doc33"が生成されて文書管理サーバ10に登録される。userCは、ID付き文書"Doc33"を次の作業工程「業務5」の担当者userAに渡す。
一方、ID付き文書"Doc41"を受け取ったuserDにより、クライアント端末20上で、ID付き文書"Doc41"に関し、「業務4」の操作種別「承認/課長」を指定して文書管理サーバ10へのID付き文書の登録の指示が行なわれると、新たなID付き文書"Doc42"が文書管理サーバ10に登録される。ID付き文書"Doc42"の親IDは"Doc41"に設定される。userDは、この新たなID付き文書"Doc42"を次の作業工程「業務5」の担当者userAに渡す。
userAは、userC及びuserDからそれぞれ受け取った各ID付き文書"Doc33","Doc42"に関して、「業務5」の操作種別「アーカイブ」に対応するID付き文書の文書管理サーバ10への登録を指示する。これに応じて、親IDを"Doc33"とするID付き文書"Doc34"と、親IDを"Doc42"とするID付き文書"Doc43"と、が文書管理サーバ10に登録される。また、userAは、自己の担当する「業務5」がワークフローにおける結合点に対応する作業工程(つまり、ワークフローの結合ノードの子ノードの作業工程)であることから、各ID付き文書"Doc34","Doc43"について、結合種類(本例では、「OR-Join」)を設定する。
ID付き文書"Doc34","Doc43"が文書管理サーバ10に登録されると、図27の例のワークフローに関する業務の試行は終了する。業務の試行が終了すると、図30及び図31に例示するように、派生関係DB110には2つの履歴ツリー"Tree3","Tree4"が登録される。履歴ツリー"Tree3"は、ワークフローの「業務1」,「業務2」,「業務3」,「業務5」にそれぞれ対応するノード"Doc31","Doc32","Doc33","Doc34"から成り、「業務2」から「業務3」へ分岐した場合の文書の履歴を表す。履歴ツリー"Tree4"は、「業務2」に対応する"Doc32"を分岐元とする分岐時新規登録のノード"Doc41"と、「業務4」,「業務5」に対応するノード"Doc42","Doc43"から成り、「業務2」から「業務4」へ分岐した場合の文書の履歴を表す。ただし、履歴ツリー"Tree4"は、分岐点に相当する「業務2」に至るまでの文書の履歴を含まない。
図33は、第2実施形態の例の業務管理サーバ50の内部構成の例を示すブロック図である。図33では、図8に例示する第1実施形態における業務管理サーバ50と同様の構成要素については図8と同様の符号を付し、その詳細な説明を省略する。図33を参照し、本実施形態の例の業務管理サーバ50は、履歴ツリー統合部520において、分岐時新規登録ノード処理部522を備える。分岐時新規登録ノード処理部522は、文書管理サーバ10から履歴ツリー取得部500が取得した履歴ツリーの中に、操作種別が「分岐時新規登録」である根ノード(以下、「分岐時新規登録ノード」と呼ぶ)を有する履歴ツリーが存在する場合に、当該分岐時新規登録ノードの「分岐元」を参照して、当該分岐時新規登録ノードに至るまでの文書の履歴を取得する処理を行う。また、分岐時新規登録ノード処理部522は、分岐時新規登録ノードを根とする履歴ツリーに分岐時新規登録ノードに至るまでの文書の履歴を接続して補足した履歴ツリーを生成する処理を行う。履歴ツリー統合部520は、分岐時新規登録ノード処理部522により補足された履歴ツリーを処理対象の1つとして、第1実施形態の例の履歴ツリー統合処理(図12)と同様の処理を行う。
以下、本実施形態の例の業務管理サーバ50がワークフローの生成の際に行う処理の手順の例を説明する。本実施形態においても、処理手順の全体的な流れは、図9に例示する第1実施形態の例の業務管理サーバ50の手順と同様のものであってよい。ただし、本実施形態では、履歴ツリー取得処理(ステップS10)と履歴ツリー統合処理(ステップS20,図12)との間に、分岐時新規登録ノード処理部522による処理が行われる点が第1実施形態における処理手順と異なる。
図34に、分岐時新規登録ノード処理部522の処理の手順の例を示す。まず、分岐時新規登録ノード処理部522は、図9のステップS10で文書管理サーバ10から取得した履歴ツリーの中に、操作種別が「分岐時新規登録」である根ノード(以下、「分岐時新規登録ノード」と言う)を有するものが存在するか否かを判定する(ステップS150)。存在しなければ図34の手順の処理は終了し、存在すればステップS151に進む。例えば、図30及び図31に例示する履歴ツリー"Tree3","Tree4"を図9のステップS10で取得していたとすると、分岐時新規登録ノード"Doc41"が存在するため、ステップS150からステップS151に進む。ステップS151では、分岐時新規登録ノードの分岐元までの文書の履歴を記録しておくリストを初期化して空にする。
ステップS151の後、分岐時新規登録ノードの分岐元として設定されている管理IDのレコードを取得する(ステップS152)。分岐時新規登録ノードが"Doc41"である場合、分岐元として設定された管理ID"Doc32"のレコードが取得される。分岐元のレコードを取得すると、分岐時新規登録ノード処理部522は、取得したレコードをリストに追加する(ステップS154)。そして、ステップS154でリストに追加したレコードに含まれる親IDの値を調べ、親IDが存在すれば(ステップS156でYES)、当該親IDを管理IDとするレコードを取得し(ステップS158)、取得したレコードに対してステップS154,S156の処理を繰り返す。
ステップS154,156,S158を含む処理ループにより、分岐時新規登録ノードの分岐元のノードを起点に、当該分岐元のノードが属する履歴ツリーを根ノードまで遡った経路上の管理ID(ノード)のレコードがリストに記録される。分岐元の管理IDが"Doc32"である場合、分岐元のノード"Doc32"を起点に履歴ツリー"Tree3"を根ノードまで遡った経路上の管理ID"Doc32","Doc31"のレコードがリストに記録される。
一方、リストに追加したレコードに親IDが存在しない(値が「なし」である)場合(ステップS156でNO)、分岐時新規登録ノードを根とする履歴ツリーに対し、リストに記録されたレコードを接続して、分岐時新規登録ノードに至るまでの文書の履歴を補足した履歴ツリーを生成する(ステップS159)。処理対象の分岐時新規登録ノードが"Doc41"、リストに記録されるレコードの管理IDが"Doc32","Doc31"である上述の例の場合、例えば、分岐時新規登録ノード"Doc41"をリスト中の"Doc32","Doc31"から成る部分木で置き換えた履歴ツリーを生成する。ただし、分岐時新規登録ノード"Doc41"に設定された分岐条件は、置き換え後の履歴ツリーにおいても保持しておく。本例で生成される補足された履歴ツリー中の各ノードの情報レコードを図35に示す。また、補足された履歴ツリーを図式化した例を図36に示す。図35及び図36を参照し、履歴ツリー"Tree4"において、分岐時新規登録ノード"Doc41"(図31参照)が削除され、代わりに、"Doc41"に至るまでの文書の履歴を表すノード"Doc31","Doc32"を有する。ステップS159の前に分岐時新規登録ノード"Doc41"の子であったノード"Doc42"の親IDは、分岐元の管理ID"Doc32"に書き換えられる。ただし、図35の例の表において"Doc32"の分岐条件は、履歴ツリー"Tree3"中の"Doc32"の分岐条件「決済額が20万円を超える」(図30参照)ではなく、分岐時新規登録ノード"Doc41"に設定されていた分岐条件「決済額が20万円以下」である。
なお、本例のステップS159の処理の結果として履歴ツリー"Tree4"に含まれることになる"Doc31","Doc32"は、履歴ツリー"Tree3"にも含まれる。履歴ツリー統合部520は、後の履歴ツリー統合処理(図9のステップS20,図12)において、異なる履歴ツリーに含まれるノードについては管理IDが同一であっても区別して取り扱う。
ステップS159の処理の変形例では、分岐時新規登録ノードと置き換えた部分木の各ノードの管理IDを元の値と異なる値に書き換えてもよい。例えば、履歴ツリー"Tree4"で"Doc41"と置き換えられる"Doc31","Doc32"の各管理IDを、"Doc31-4","Doc32-4"などの値に書き換える。本変形例では、ステップS159で補足された履歴ツリー"Tree4"は、ノード"Doc31-4","Doc32-4","Doc42","Doc43"を含み、初めから分岐時新規登録ノードを含まない履歴ツリー"Tree3"は、ノード"Doc31","Doc32","Doc33","Doc34"を含む。
ステップS159の処理の更なる変形例では、分岐時新規登録ノードをリスト中の管理IDのノードから成る部分木と置き換える代わりに、分岐時新規登録ノードの管理IDを残してもよい。例えば、分岐時新規登録ノード"Doc41"の操作種別を「分岐時新規登録」から分岐元"Doc32"の操作種別「進達」に書き換え、"Doc41"の親IDを分岐元"Doc32"の親ID"Doc31"に書き換える。この変形例では、ステップS159の結果として得られる補足された履歴ツリー"Tree4"は、ノード"Doc31","Doc41","Doc42","Doc43"を含むことになる。
ステップS159の後、処理はステップS150に戻り、未処理の分岐時新規登録ノードがあれば(ステップS150でYES)、当該分岐時新規登録ノードに関してステップS151以下の処理を行う。
第2実施形態の例の業務管理サーバ50の履歴ツリー統合部520は、分岐時新規登録ノードを含む履歴ツリーを図34の例の手順の処理により補足した上で、履歴ツリー統合処理(図9のステップS20,図12)を第1実施形態の例の場合と同様に行う。図9の例のステップS30〜ステップS60についても、第1実施形態の例と同様に行ってよい。
以上で説明した第2実施形態の例では、業務管理サーバ50が分岐時新規登録ノード処理部522を備えるが、第2実施形態において、文書管理サーバ10が分岐時新規登録ノード処理部522を備えていてもよい。例えば、業務管理サーバ50に提供する履歴ツリーとして検索された履歴ツリーに関して、文書管理サーバ10が図34の例の手順の処理を実行し、分岐時新規登録ノードを根とする履歴ツリーを分岐時新規登録ノードまでの履歴により補足した上で、業務管理サーバ50に履歴ツリーを送信する。この例の場合、業務管理サーバ50では、図34の例の手順の処理を行わず、履歴ツリーの取得(図9のステップS10)の後、履歴ツリー統合処理(図9のステップS20,図20)を実行すればよい。
以上に例示した第1実施形態及び第2実施形態の例では、管理IDの発行は各クライアント端末20で行われていたが、この代わりに文書管理サーバ10が管理IDを発行してもよい。この場合、クライアント端末20は、ID付き文書に対して操作を行った場合、操作前のID付き文書内の管理IDを親ID314として含み、更にその操作についてのログ情報316と操作後の文書内容320とを含み、管理ID312は空欄の文書データを生成し、文書管理サーバ10に送る。文書管理サーバ10は、受け取った文書データに対して新たな管理IDを付与し、この管理IDとその文書データとに含まれる情報を、文書DB100及び派生関係DB110に登録する。また、文書管理サーバ10は、付与した管理IDを当該文書データにセットすることによりID付き文書を生成し、これをクライアント端末20に返す。クライアント端末20は、操作前のID付き文書を、受け取ったID付き文書に置き換える。このように、文書管理サーバ10が管理IDを付与する構成でも、上述の各例の処理は同様に実行できる。
以上に例示したシステムにおける文書管理サーバ10、クライアント端末20、及び業務管理サーバ50の各装置は、典型的には、汎用のコンピュータにて上述の各装置の各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図37に示すように、CPU(中央演算装置)80、メモリ(一次記憶)82、各種I/O(入出力)インタフェース84等がバス86を介して接続された回路構成を有する。また、そのバス86に対し、例えばI/Oインタフェース84経由で、ハードディスクドライブ(HDD)88やCDやDVD、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ90が接続される。このようなドライブ88又は90は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがCDやDVD等の記録媒体を経由して、又はネットワーク経由で、HDD88等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されCPUにより実行されることにより、実施形態の処理が実現される。
なお、文書管理サーバ10及び業務管理サーバ50は、それぞれ異なるコンピュータを用いて実現してもよいし、上述の文書管理サーバ10及び業務管理サーバ50が備える各機能を1つのコンピュータに実現してもよい。