JP2012226777A - ワークフロー管理方法 - Google Patents

Abstract

【課題】文書の作成者によるワークフローの特定が不要で、汎用性が高く、複数の既存システムの有機的結合により柔軟性・拡張性に優れたメンテナンスの容易なワークフロー管理方法を提供する。
【解決手段】第１の情報とワークフロー情報とを対応付けた管理情報に基づきワークフローを管理するワークフロー管理装置がワークフローの実行を管理するワークフロー管理方法であって、ワークフローを特定する第２の情報を受信する受信工程と、前記第２の情報と前記管理情報に基づき、前記第２の情報に対応付くワークフロー情報から実行するワークフローを特定する特定工程と、前記対応付くワークフロー情報から、前記実行するワークフローに含まれる審査または承認の依頼処理を、前記ワークフロー情報に基づいて特定したユーザ宛に実行する依頼工程とを備える。
【選択図】図１

Description

本発明はワークフロー管理方法に関する。

企業等の組織内での文書の審査・承認を電子的に行うワークフローシステムとして種々のものが提案されている（例えば、特許文献１参照。）。

ワークフローシステムでは、一般に、文書の作成者（起案者）が組織内の運用ルール等を確認してワークフローを特定し、特定されたワークフローで定められた回議者を設定することで順次に審査・承認が行われていく。

従来のワークフローシステムは上述したように処理が行われるものであったが、次のような問題点が指摘されていた。
（１）文書の作成者が組織内の運用ルール等を確認してワークフローを特定しなければならず、作業が煩雑である。
（２）ワークフローの対象となる文書やタスクに特化したシステムとなっており、
・メンテナンスが煩雑である
・専用のクライアントソフトウェアを必要とする
・柔軟性・拡張性に乏しい
・ワークフロー機能を持たない既存の文書管理システム等を有効活用できない
等の問題がある。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、文書の作成者によるワークフローの特定が不要で、汎用性が高く、複数の既存システムの有機的結合により柔軟性・拡張性に優れたメンテナンスの容易なワークフロー管理方法を提供することにある。

上記の課題を解決するため、本発明にあっては、第１の情報とワークフロー情報とを対応付けた管理情報に基づきワークフローを管理するワークフロー管理装置がワークフローの実行を管理するワークフロー管理方法であって、ワークフローを特定する第２の情報を受信する受信工程と、前記第２の情報と前記管理情報に基づき、前記第２の情報に対応付くワークフロー情報から実行するワークフローを特定する特定工程と、前記対応付くワークフロー情報から、前記実行するワークフローに含まれる審査または承認の依頼処理を、前記ワークフロー情報に基づいて特定したユーザ宛に実行する依頼工程とを備える。

本発明のワークフロー管理方法にあっては、文書の作成者によるワークフローの特定が不要で、汎用性が高く、複数の既存システムの有機的結合により柔軟性・拡張性に優れたメンテナンスの容易なワークフローシステムを構築することができる。

本発明の一実施形態にかかるワークフローシステムの構成例を示す図である。 システム構成のバリエーションを示す図である。 メタデータＤＢの例を示す図である。 タグ解釈ルールＤＢの例を示す図である。 ワークフローＤＢの例を示す図である。 文書登録ＤＢの例を示す図である。 所属・認証ＤＢの例を示す図である。 ワークフローシステムの大まかな処理の流れを示す図である。 ネットワーク上での処理の流れを示す図である。 ユーザの処理の流れを示す図である。 文書登録からワークフローの開始までの処理例を示すシーケンス図（その１）である。 文書登録からワークフローの開始までの処理例を示すシーケンス図（その２）である。 文書登録のＵＩ例を示す図である。 ワークフロー提示のＵＩ例を示す図である。 ＲＳＳ配信におけるフィルタリングの概念図である。 ユーザ端末のＲＳＳリーダからメタデータ管理部へ送信されるＲＳＳ取得のリクエストの例を示す図である。 ＲＳＳフィードおよびその表示例を示す図（その１）である。 ＲＳＳフィードおよびその表示例を示す図（その２）である。 審査の処理例を示すシーケンス図である。 審査・承認のＵＩ例を示す図である。 タグの自動提示を行うためのタグ管理部の構成例を示す図である。 文書登録までの処理例を示すシーケンス図である。 文書登録のＵＩの他の例を示す図である。 文書種類および所属と対応するタグとの関係を記述するデータの例を示す図である。

以下、本発明の好適な実施形態につき説明する。

＜システム構成＞
図１は本発明の一実施形態にかかるワークフローシステムの構成例を示す図である。

図１において、ワークフローシステムは、回議の対象となる文書に付与されたタグをメタデータとして管理するとともに、ワークフローシステムの中心的な役割を果たすメタデータ管理部１と、メタデータ管理部１からの要求に基づいてワークフローを特定するワークフロー特定部２と、回議の対象となる文書情報を保持する文書登録部３と、メタデータ管理部１もしくは文書登録部３からの要求に応じてアクセスするユーザを認証する認証部４と、ワークフローシステムを利用するユーザが操作するＰＣ（Personal Computer）等のユーザ端末５Ａ、５Ｂ・・・とがネットワークに接続されて構成される。

メタデータ管理部１は、ユーザ端末５Ａ、５Ｂによるユーザからのアクセスに対応するユーザ対応部１１と、メタデータの管理を実行するメタデータ管理実行部１２と、ユーザ端末５Ａ、５Ｂに対してＵＩ（User Interface）を生成するＵＩ生成部１３と、ユーザ端末５Ａ、５Ｂからのリクエストに応じ、回議の対象となる文書のメタデータをＲＳＳ（RDF(Resource Description Framework) Site Summary、Rich Site Summary、Really Simple Syndication）形式で生成して配信（送信）するＲＳＳ生成部１４と、文書に付されたタグを解釈するタグ解釈部１５と、ワークフロー特定部２に対してワークフローの特定を要求するワークフロー特定要求部１６と、ワークフローのステータスを管理するワークフローステータス管理部１７と、回議の対象となる文書に付与されたタグをメタデータとして保持するメタデータＤＢ（Data Base）１８と、タグの解釈ルールを保持するタグ解釈ルールＤＢ１９とを備えている。ＲＳＳ生成部１４は、ユーザ端末５Ａ、５Ｂからユーザ対応部１１を介してＲＳＳ取得のリクエストを受け付けるリクエスト受付部１４１と、リクエストに含まれる条件（後述）に応じ、メタデータ管理実行部１２によりメタデータＤＢ１８から該当する文書をタグに基づいて検索するタグ検索部１４２と、検索して得た文書についてのメタデータ（ＲＳＳ）を生成するデータ生成部１４３と、生成したＲＳＳをリクエストのあったユーザ端末５Ａ、５Ｂに送信するレスポンス送信部１４４とを備えている。

ワークフロー特定部２は、ネットワークを介したアクセスに応答するワークフローサーバ２１と、ワークフローの定義情報を保持するワークフローＤＢ２２とを備えている。

文書登録部３は、ネットワークを介したアクセスに応答する文書登録ＷＷＷサーバ３１と、回議の対象となる文書情報を保持する文書登録ＤＢ３２とを備えている。なお、文書種類ごとに異なるサーバを設けてもよい。

認証部４は、ネットワークを介したアクセスに応答する認証サーバ４１と、各ユーザの所属情報および認証情報を保持する所属・認証ＤＢ４２とを備えている。なお、所属・認証ＤＢ４２を所属ＤＢと認証ＤＢの二つに分けてもよい。

ユーザ端末５Ａ、５Ｂは、ＲＳＳの配信を受け付けるＲＳＳリーダ５１と、配信されたＲＳＳに含まれるリンクからページの閲覧等を行うブラウザ５２とを備えている。

図２はシステム構成のバリエーションを示す図であり、（ａ）は図１に示したメタデータ管理部１とワークフロー特定部２と認証部４が分離したタイプ、（ｂ）はメタデータ管理部１と認証部４を一体にしたタイプ、（ｃ）はワークフロー特定部２と認証部４を一体にしたタイプ、（ｄ）はメタデータ管理部１とワークフロー特定部２と認証部４を一体にしたタイプ、（ｅ）はメタデータ管理部１とワークフロー特定部２を一体にしたタイプである。

図３はメタデータＤＢ１８の例を示す図であり、レコードを識別する「ｉｄ」と、対応する文書を識別する「文書ｉｄ」と、文書に付加された「タグ」とを含んでいる。タグは単数でも複数でもよい。なお、タグはメタデータの一部であり、メタデータは文書ＵＲＬ、タグ等の文書関連情報を含む総称である。

ワークフロー提示に関連するタグの例としては、タスクやドキュメントの種類に関する「発明届出書」「技術報告書」「稟議書」・・・、所属等に関する「ＸＸ研究所」「ＯＯ課」、正式な組織でない準所属的な「〜分科会」「〜検討会」、状況やステータスに関する「作成中」「作成中：誰某」「審査依頼中」「承認済」「承認済：誰某」「非承認」「ＴＯ：誰某」「ＣＣ：誰某」「ＴＯ：アーカイブ」等がある。所属等のタグは認証を経てからでないと付与できないようにすることができる。

また、ワークフローや登録文書のステータスなどを表すタグは第３者に勝手にまたは利用者に不正にもしくは誤って書き換えられると都合が悪いため、これらのタグはシステムタグとしてシステム側が自動で作成、変更するものとし、利用者側では変更できないものとする。システムタグの例としては、「作成：誰某」「作成：誰某(2006-08-31/23:59:59)」「変更：誰某」「変更：誰某(2006-08-31/23:59:59)」「TO:誰某」「CC:誰某」「審査依頼中」「審査済み：誰某」「審査済み：誰某(2006-08-31/23:59:59)」「承認依頼中」「承認済み：誰某」「承認済み：誰某(2006-08-31/23:59:59)」「非承認」「非承認：誰某」「非承認：誰某(2006-08-31/23:59:59)」等がある。

図４はタグ解釈ルールＤＢ１９の例を示す図であり、レコードを識別する「ｉｄ」と、解釈の対象となる「タグ」と、解釈内容を示す「解釈」とを含んでいる。図では解釈を人間向きに記載したが、実装上はシステムが実行可能な関数等を記述する。

図５はワークフローＤＢ２２の例を示す図であり、「タグ」と、対応する「ワークフロー」と、ワークフローの「説明」とが含まれている。複数のタグの組み合わせでワークフローを特定することで、同じタグに複数のワークフローを定義することが可能である。また、ワークフローの説明を併せて保持することで、メンテナンス性を高めることができる。

図６は文書登録ＤＢ３２の例を示す図であり、レコードを識別する「ｉｄ」と、「文書名」と、当該文書の保存場所を示す「ＵＲＬ」とが含まれている。

図７は所属・認証ＤＢ４２の例を示す図であり、レコードを識別する「ｉｄ」と、ユーザの「氏名」と、「所属」と、「役割」と、認証用の「パスワード」とが含まれている。

＜動作＞
図８はワークフローシステムの大まかな処理の流れを示す図である。

図８において、作成者（起案者）は回議の対象となる文書をユーザ端末上で作成し（ステップＳ１）、ワークフローシステムへの登録時にワークフローを特定するタグを付与する（ステップＳ２）。

ワークフローシステムはワークフローを特定するタグからワークフローを特定し（ステップＳ３）、作成者の確認を経て、最初の回議者を示すタグおよびワークフローのステータスを示すタグを追加する（ステップＳ４）。

次いで、回議の対象となる文書のメタデータ（タイトル、説明、ＵＲＬ等）をＲＳＳによりタグに基づく該当するユーザに配信する（ステップＳ５）。

ＲＳＳの配信を受けたユーザは審査・承認等を行い（ステップＳ６）、ワークフローシステムは審査・承認の結果に応じてワークフローのステータスを示すタグおよび存在する場合に次の回議者を示すタグを更新し（ステップＳ７）、ワークフローの終了でない場合はＲＳＳ配信（ステップＳ５）から同様の処理を繰り返す。

最後の回議者の処理が終了した場合もしくは途中で否認等がなされた場合は処理を終了する（ステップＳ８）。

図９はネットワーク上での処理の流れを示す図である。

図９において、作成者はメタデータ管理部１に対して文書に対するタグ付けを行い（ステップＳ１１）、メタデータ管理部１は認証部４に対して作成者の認証を行った上で（ステップＳ１２）、ワークフロー特定部２によりワークフローの特定を行い（ステップＳ１３）、作成者は文書登録部３に対して文書のアップロードを行う（ステップＳ１４）。

また、ユーザＡさん、Ｂさん、Ｃさんは、メタデータ管理部１からＲＳＳ配信を受け、これに基づいて文書登録部３から文書を閲覧するとともに、メタデータ管理部１に対して審査・承認を行う（ステップＳ１５、Ｓ１６）。この際、文書登録部３へのアクセス時に認証部４による認証が行われる（ステップＳ１７）。

図１０はユーザの処理の流れを示す図であり、図９におけるユーザＡさん、Ｂさん、Ｃさんのメタデータ管理部１および文書登録部３に対する処理をより詳細に示したものであり、図１０の右側の省略表記を図９では用いている。

図１０において、ユーザＸＸさんは、メタデータ管理部１からユーザ端末５のＲＳＳリーダ５１によりＲＳＳを取得すると（ステップＳ２１）、ＲＳＳに含まれる文書リンクからブラウザ５２により文書登録部３から文書の閲覧を行い（ステップＳ２２）、内容を検討の上、メタデータ管理部１に対してブラウザ５２上から審査等を行う（ステップＳ２３）。

図１１および図１２は文書登録からワークフローの開始までの処理例を示すシーケンス図である。

図１１において、作成者のユーザ端末５Ａからメタデータ管理部１のユーザ対応部１１に対して登録要求を行うと（ステップＳ１０１）、ユーザ対応部１１はＵＩ生成部１３に登録ＵＩの生成要求を行い（ステップＳ１０２）、登録ＵＩを取得し（ステップＳ１０３）、ユーザ端末５Ａに登録ＵＩを提供する（ステップＳ１０４）。図１３は文書登録のＵＩ例を示す図であり、登録する文書（回議の対象となる文書）の文書名を入力する文書名入力欄５０１と、文書の登録先のＵＲＬ（文書登録ＷＷＷサーバ３１上のＵＲＬ等）を入力する文書ＵＲＬ入力欄５０２と、文書に付すワークフローを特定するタグを入力（直接入力してもよいし、後述するタグ選択欄５０４から選択してもよい）するタグ入力欄５０３と、タグ入力欄５０３に入力するタグを選択可能なタグ選択欄５０４と、入力した条件でワークフロー（ＷＦ）を検索して提示させることを要求するＷＦ提示ボタン５０５とが設けられている。

図１１に戻り、作成者がユーザ端末５Ａから登録ＵＩに対して文書名、ＵＲＬ、タグを入力して登録を要求（ワークフローの提示を要求）すると（ステップＳ１０５）、メタデータ管理部１のユーザ対応部１１は文書登録部３の文書登録ＷＷＷサーバ３１に文書名とＵＲＬを指定して登録を要求する（ステップＳ１０６）。

文書登録ＷＷＷサーバ３１は認証部４の認証サーバ４１に認証を要求し（ステップＳ１０７）、認証サーバ４１はメタデータ管理部１のＵＩ生成部１３に認証を要求し（ステップＳ１０８）、ＵＩ生成部１３は認証ＵＩを生成してユーザ対応部１１に提供し（ステップＳ１０９）、ユーザ対応部１１はユーザ端末５Ａに認証ＵＩを提供する（ステップＳ１１０）。

作成者がユーザ端末５Ａから認証ＵＩに対してｉｄ、パスワード等を入力すると（ステップＳ１１１）、メタデータ管理部１のユーザ対応部１１は認証情報を認証部４の認証サーバ４１に送り（ステップＳ１１２）、認証サーバ４１は所属・認証ＤＢ４２により照合を行い（ステップＳ１１３、Ｓ１１４）、認証がＯＫであればその旨を文書登録部３の文書登録ＷＷＷサーバ３１に送り（ステップＳ１１５）、文書登録ＷＷＷサーバ３１はメタデータ管理部１のユーザ対応部１１を介してユーザ端末５Ａに文書アップロードを要求する（ステップＳ１１６、Ｓ１１７）。

ユーザ端末５Ａはこれに応じて文書ファイルを文書登録部３の文書登録ＷＷＷサーバ３１に送り（ステップＳ１１８）、文書登録ＷＷＷサーバ３１は文書登録ＤＢ３２に文書ファイルを登録する（ステップＳ１１９）。そして、文書登録ＷＷＷサーバ３１は登録が行われた旨の通知と文書ｉｄをメタデータ管理部１のユーザ対応部１１に送る（ステップＳ１２０）。

次いで、図１２において、メタデータ管理部１のユーザ対応部１１は、文書ｉｄとタグをメタデータ管理実行部１２に送り（ステップＳ１２１）、メタデータ管理実行部１２はメタデータＤＢ１８に登録する（ステップＳ１２２）。

次いで、ユーザ対応部１１はワークフローステータス管理部１７にタグを伴ってワークフローの発生要求を行い（ステップＳ１２３）、ワークフローステータス管理部１７はワークフロー特定要求部１６に同要求を伝える（ステップＳ１２４）。

ワークフロー特定要求部１６はワークフロー特定部２のワークフローサーバ２１にタグを伴ってワークフロー特定要求を行い（ステップＳ１２５）、ワークフローサーバ２１はワークフローＤＢ２２により照合を行ってワークフローを特定する（ステップＳ１２６、Ｓ１２７）。

次いで、ワークフローサーバ２１は認証部４の認証サーバ４１に所属情報の確認を行い（ステップＳ１２８）、認証サーバ４１は所属・認証ＤＢ４２により照合を行い（ステップＳ１２９、Ｓ１３０）、照合結果をワークフロー特定部２のワークフローサーバ２１に返す（ステップＳ１３１）。例えば、タグが「○×研究所」で、ワークフローの回議者に「リーダ」がある場合、「○×研究所のリーダは誰か？」という照合を行い、「○×研究所のリーダは佐藤さん」という照合結果を得る。

次いで、ワークフローサーバ２１は照合結果を含んだワークフロー情報をワークフローステータス管理部１７に送り（ステップＳ１３２）、ワークフローステータス管理部１７は同内容をユーザ対応部１１に送る（ステップＳ１３３）。

次いで、ユーザ対応部１１はＵＩ生成部１３に確認ＵＩの生成要求を行い（ステップＳ１３４）、ＵＩ生成部１３は確認ＵＩを生成し（ステップＳ１３５）、ユーザ対応部１１を介してユーザ端末５Ａに提供する（ステップＳ１３６）。図１４はワークフロー提示のＵＩ例を示す図であり、登録内容である文書名５１１、文書ＵＲＬ５１２、タグ５１３とともに、特定されたワークフロー回議者５１４が表示され、ＷＦ開始ボタン５１５によりワークフローの開始を指示できるとともに、前に戻るボタン５１６により直前の状態に戻ることができる。

図１２に戻り、作成者がユーザ端末５Ａからワークフロー開始を指示すると（ステップＳ１３７）、ユーザ対応部１１はタグ解釈部１５に追加すべきタグを要求し（ステップＳ１３８）、タグ解釈部１５はタグ解釈ルールＤＢ１９を参照して（ステップＳ１３９、Ｓ１４０）、取得したタグをユーザ対応部１１に返す（ステップＳ１４１）。具体的には、ワークフロー回議者を記述するタグ「ＷＦＺ：（人)：（人）：・・・」、審査依頼中のステータスを記述するタグ「審査依頼中」、次の回議者を記述するタグ「Ｔｏ：（人）」等を取得する。

次いで、ユーザ対応部１１は文書ｉｄとタグをメタデータ管理実行部１２に送り（ステップＳ１４２）、メタデータ管理実行部１２はメタデータＤＢ１８に登録する（ステップＳ１４３）。図１４に示した例では、ＷＦ開始ボタン５１５によりワークフローの開始を指示した場合、作成者が「山田」である場合、この文書のタグは「発明届出 ○×研究所 ＷＦＺ：鈴木：佐藤：田中 作成：山田 審査依頼中 Ｔｏ：鈴木」となる。

図１２に戻り、メタデータ管理部１のユーザ対応部１１は、ユーザ端末５Ａ、５Ｂ、・・からＲＳＳ取得のリクエストを受けると、ＲＳＳ生成部１４にＲＳＳ生成を要求し（ステップＳ１４４）、ＲＳＳ生成部１４は該当する文書のＲＳＳを生成し、リクエストを行ったユーザ端末にＲＳＳ配信を行う（ステップＳ１４５）。

図１５はＲＳＳ配信におけるフィルタリングの概念図であり、「Ｔｏ：Ａさん」タグの付いた文書、「Ｔｏ：Ｂさん」タグの付いた文書、「Ｔｏ：Ｃさん」タグの付いた文書のワークフローが走っている場合、Ａさんには「Ｔｏ：Ａさん」タグの付いた文書情報のみがフィルタリングされてＲＳＳ配信される。また、「発明届出」や「報告書」といった文書内容を示すタグに基づいてフィルタリングすることもできる。このように、様々な文書、タスクを同じ仕組で扱うことができ、従来は困難であった個別システムの有機的結合を容易に実現することができる。

図１６はユーザ端末５Ａ、５ＢのＲＳＳリーダ５１からメタデータ管理部１へ送信されるＲＳＳ取得のリクエストの例を示す図である。（ａ）は第１の形式を示し、最初の「http://server/」はＲＳＳフィードを配信するサーバ（メタデータ管理部１）のアドレスであり、次の「tag/」および最後の「/rss」はその間で指定されるタグによる絞り込みを行ったＲＳＳフィードの取得を意味する。[tags]はタグを示し、[値]はそのタグの値を示している。「Ｔｏ：（人）」のようにシステム上で特別な意味を持つものは、タグと値とを分離して指定することで、タグ部分の解析処理が楽になるという利点がある。（ｂ）は（ａ）の具体例であり、タグ「Ｔｏ」の値が「Ａさん」であるＲＳＳフィードに絞り込むことを示している。メタデータ管理部１のＲＳＳ生成部１４（図１）は、図１６（ｂ）のリクエストをリクエスト受付部１４１により受け付けると、タグ検索部１４２はタグ「Ｔｏ」および値「Ａさん」によりメタデータ管理実行部１２によってメタデータＤＢ１８を検索し、該当する文書（複数可）を特定し、データ生成部１４３によりその文書についてのＲＳＳを生成し、レスポンス送信部１４４によりレスポンスとして送信する。

（ｃ）は第２の形式を示し、最初の「http://server/」がＲＳＳフィードを配信するサーバ（メタデータ管理部１）のアドレス、次の「tag/」および最後の「/rss」はその間で指定されるタグによる絞り込みを行ったＲＳＳフィードの取得を意味するのは同様であるが、[tags]で特定されるタグが含まれていれば、その値を問わないようにしたものである。（ｄ）は[tags]として１つのタグ「tag1」を指定する場合であり、（ｅ）はその具体例である。この場合、タグ「○△研究所」が含まれる文書に絞り込まれる。

（ｆ）は[tags]として２つのタグ「tag1」「tag2」を指定する場合であり、空白文字をＵＲＬ用にエンコードした「%20」で両者を連結し、「tag1%20tag2」としている。（ｇ）はその具体例であり、タグ「○△研究所」とタグ「発明届出」が含まれる文書に絞り込まれる。

（ｈ）は（ｂ）を第２の形式と同様な形式で記述したものであり、タグ「Ｔｏ」に空白文字「%20」を挟んで値「Ａさん」を連続して記述したものである。このようなシステム上で特別な意味を持つタグについては、別々のタグとは認識せず、タグが「Ｔｏ」、その値が「Ａさん」と認識して絞り込みを行う。

図１７はタグ「Ｔｏ:○○」が付いている文書についてのＲＳＳフィードおよびその表示例を示す図であり、（ａ）はＲＳＳフィード例、（ｂ）はユーザ端末での表示例を示しており、○○さん宛であれば「Ｔｏ:○○ 審査依頼中」の文書と「Ｔｏ:○○ 承認依頼中」の文書とが混在して表示される。

図１８はタグ「Ｔｏ:○○ 審査依頼中」が付いている文書についてのＲＳＳフィードおよびその表示例を示す図であり、（ａ）はＲＳＳフィード例、（ｂ）はユーザ端末での表示例を示しており、○○さん宛でかつ審査依頼中の文書のみが表示される。

図１９は審査の処理例を示すシーケンス図である。

図１９において、メタデータ管理部１のＲＳＳ生成部１４から審査者のユーザ端末５ＢにＲＳＳ配信（ステップＳ１５１）がされた後、審査者はユーザ端末５ＢからＲＳＳ中の文書リンクに基づいて文書登録部３の文書登録ＷＷＷサーバ３１に閲覧要求を行う（ステップＳ１５２）。

文書登録ＷＷＷサーバ３１はメタデータ管理部１のワークフローステータス管理部１７にワークフロー確認を行い（ステップＳ１５３）、ワークフローステータス管理部１７はタグ解釈部１５にタグ解釈を要求する（ステップＳ１５４）。

タグ解釈部１５はタグ解釈ルールＤＢ１９を参照し（ステップＳ１５５、Ｓ１５６）、タグ解釈結果（ステータス、回議者等およびその後に必要となる処理）をワークフローステータス管理部１７に返し（ステップＳ１５７）、ワークフローステータス管理部１７は文書登録部３の文書登録ＷＷＷサーバ３１にワークフローのステータスを返す（ステップＳ１５８）。

次いで、文書登録ＷＷＷサーバ３１は認証部４の認証サーバ４１に認証要求を行い（ステップＳ１５９）、認証サーバ４１はユーザ端末５Ｂに認証要求を行い（ステップＳ１６０）、審査者はユーザ端末５Ｂからｉｄ、パスワード等の認証情報を認証部４の認証サーバ４１に送る（ステップＳ１６１）。

認証サーバ４１は所属・認証ＤＢ４２により照合を行い（ステップＳ１６２、Ｓ１６３）、認証結果を文書登録部３の文書登録ＷＷＷサーバ３１に返し（ステップＳ１６４）、文書登録ＷＷＷサーバ３１はメタデータ管理部１のユーザ対応部１１に認証結果を送る（ステップＳ１６５）。

また、文書登録ＷＷＷサーバ３１は文書登録ＤＢ３２から該当文書を取得し（ステップＳ１６６、Ｓ１６７）、これをユーザ端末５Ｂに送って閲覧を行わせる（ステップＳ１６８）。

一方、メタデータ管理部１のユーザ対応部１１はＵＩ生成部１３に審査ＵＩの生成要求を行い（ステップＳ１６９）、ＵＩ生成部１３は審査ＵＩを生成し（ステップＳ１７０）、ユーザ対応部１１を介してユーザ端末５Ｂに提供する（ステップＳ１７１）。図２０は審査・承認のＵＩ例を示す図であり、文書名５２１、文書ＵＲＬ５２２、開くボタン５２３、ワークフロー回議者５２４が表示されるとともに、「審査ＯＫ」「非承認」の処理ボタン５２５、５２６により審査処理を行うことができる。

図１９に戻り、審査者がユーザ端末５Ｂから審査操作を行うと（ステップＳ１７２）、メタデータ管理部１のユーザ対応部１１はワークフローステータス管理部１７に審査通知を行い（ステップＳ１７３）、ワークフローステータス管理部１７はタグ解釈部１５に審査処理に応じたタグ生成を要求する（ステップＳ１７４）。

これを受けて、タグ解釈部１５はタグ解釈ルールＤＢ１９を参照し（ステップＳ１７５）、メタデータ管理実行部１２にメタデータ反映を要求し（ステップＳ１７６）、メタデータ管理実行部１２はメタデータＤＢ１８にメタデータを反映する（ステップＳ１７７）。図２０の例では、直前のタグが「発明届出 ○×研究所 ＷＦＺ：鈴木：佐藤：田中 作成：山田 審査依頼中 Ｔｏ：鈴木」であった場合、「審査ＯＫ」の処理により「発明届出 ○×研究所 ＷＦＺ：鈴木：佐藤：田中 作成：山田 審査済：鈴木 Ｔｏ：佐藤」となり、非承認の処理により「発明届出 ○×研究所 ＷＦＺ：鈴木：佐藤：田中 作成：山田 非承認：鈴木 Ｔｏ：山田」となる。

次いで、図１９に戻り、メタデータ管理部１のワークフローステータス管理部１７はＲＳＳ生成部１４にＲＳＳ生成を要求し（ステップＳ１７８）、ＲＳＳ生成部１４はＲＳＳ配信を行う（ステップＳ１７９）。

＜タグ設定の容易化＞
図２１はタグの自動提示を行うためのタグ管理部６の構成例を示す図である。タグ管理部６は、（ａ）に示すように、ネットワークを介したアクセスに応答するタグ管理サーバ６１と、ユーザもしくは所属に対応するタグの情報を保持するタグ管理ＤＢ６２とを備えている。タグ管理部６は図１のネットワーク上に配置され、システムの一部を構成する。

（ｂ）はタグ管理ＤＢ６２の例を示しており、レコードを識別する「ｉｄ」と、ユーザもしくは組織を識別する「ユーザ／組織」と、ユーザもしくは組織に対応する複数のタグを示す「タグ」とを含んでいる。

図２２はタグ管理部６を用いた文書登録までの処理例を示すシーケンス図であり、図１１に置き換わるものである。その後の処理は図１２と同様になる。

図２２において、作成者のユーザ端末５Ａからメタデータ管理部１のユーザ対応部１１に対して登録要求を行うと（ステップＳ２０１）、ユーザ対応部１１は認証部４の認証サーバ４１に認証を要求する（ステップＳ２０２）。認証サーバ４１はメタデータ管理部１のＵＩ生成部１３に認証を要求し（ステップＳ２０３）、ＵＩ生成部１３は認証ＵＩを生成してユーザ対応部１１に提供し（ステップＳ２０４）、ユーザ対応部１１はユーザ端末５Ａに認証ＵＩを提供する（ステップＳ２０５）。

作成者がユーザ端末５Ａから認証ＵＩに対してｉｄ、パスワード等を入力すると（ステップＳ２０６）、メタデータ管理部１のユーザ対応部１１は認証情報を認証部４の認証サーバ４１に送り（ステップＳ２０７）、認証サーバ４１は所属・認証ＤＢ４２により照合を行い（ステップＳ２０８、Ｓ２０９）、認証がＯＫであれば認証情報をメタデータ管理部１のユーザ対応部１１に送る（ステップＳ２１０）。

次いで、メタデータ管理部１のユーザ対応部１１は、タグ管理部６のタグ管理サーバ６１に認証情報を送り（ステップＳ２１１）、タグ管理サーバ６１はタグ管理ＤＢ６２によりユーザもしくは所属の照合を行い（ステップＳ２１２、Ｓ２１３）、対応するタグ群のリストをメタデータ管理部１のユーザ対応部１１に送る（ステップＳ２１４）。

次いで、ユーザ対応部１１はＵＩ生成部１３に登録ＵＩの生成要求を行い（ステップＳ２１５）、登録ＵＩを取得し（ステップＳ２１６）、ユーザ端末５Ａに登録ＵＩを提供する（ステップＳ２１７）。文書登録のＵＩは図１３に示したものと同様になるが、タグ入力欄５０３にはタグ管理部６から取得されたタグが予め設定されている点が異なる。

図２２に戻り、作成者がユーザ端末５Ａから登録ＵＩに対して文書名、ＵＲＬ、タグを入力して登録を要求（ワークフローの提示を要求）すると（ステップＳ２１８）、メタデータ管理部１のユーザ対応部１１は文書登録部３の文書登録ＷＷＷサーバ３１に文書名とＵＲＬを指定して登録を要求する（ステップＳ２１９）。文書登録ＷＷＷサーバ３１はメタデータ管理部１のユーザ対応部１１を介してユーザ端末５Ａに文書アップロードを要求する（ステップＳ２２０、Ｓ２２１）。

ユーザ端末５Ａはこれに応じて文書ファイルを文書登録部３の文書登録ＷＷＷサーバ３１に送り（ステップＳ２２２）、文書登録ＷＷＷサーバ３１は文書登録ＤＢ３２に文書ファイルを登録する（ステップＳ２２３）。そして、文書登録ＷＷＷサーバ３１は登録が行われた旨の通知と文書ｉｄをメタデータ管理部１のユーザ対応部１１に送る（ステップＳ２２４）。

図２３は文書登録のＵＩの他の例を示す図であり、タグを直接に入力するのではなく、文書種類および／もしくは所属のボタンを選択することで、適切なタグが設定されるようにしたものである。図２３において、ＵＩには、登録する文書（回議の対象となる文書）の文書名を入力する文書名入力欄５３１と、文書の登録先のＵＲＬ（文書登録ＷＷＷサーバ３１上のＵＲＬ等）を入力する文書ＵＲＬ入力欄５３２と、カテゴライズされたツリーからボタン（予算、購入、技術、販売のように四角で囲んで示す）により文書種類を選択する文書種類選択欄５３３と、ボタン（○×研究所、△△所のように四角で囲んで示す）により所属を選択する所属選択欄５３４と、入力した条件でワークフローを検索して提示させることを要求するＷＦ提示ボタン５３５とが設けられている。

図２４は上記のＵＩにおける文書種類および所属と対応するタグとの関係を記述するデータの例を示す図である。図２４において、データには、「<dept〜〜</dept>」で囲まれた所属毎の複数の記述Ｄ１と、この記述Ｄ１内に含まれる、「<doc_type>〜〜</doc_type>」で囲まれた文書種類の記述Ｄ２と、この記述Ｄ２内に含まれる、「<item〜〜</item>」で囲まれたカテゴリー毎の複数の記述Ｄ３と、この記述Ｄ３に含まれる、「<button〜〜>」で囲まれたボタン毎の複数の記述Ｄ４とから構成されている。

所属毎の記述Ｄ１の先頭行には、属性名nameの属性値として「○×研究所」等の見出しが設定されている。カテゴリー毎の記述Ｄ３の先頭行には、属性名nameの属性値として「経理」等の見出しが設定されている。ボタン毎の記述Ｄ４には、属性名nameの属性値として「予算」等の見出しが設定されているとともに、属性名tagの属性値として「予算承認書」等のタグが設定されている。

上記のデータはメタデータ管理部１内に保持され（他のサーバに配置することも可能）、ＵＩ生成部１３は文書登録のＵＩの生成にあたり、所属毎の記述Ｄ１の属性名nameの属性値から所属の選択候補を取得し、ボタンを伴うＨＴＭＬに加工して図２３の所属選択欄５３４を表示する。また、ＵＩ生成部１３は、カテゴリー毎の記述Ｄ３の属性名nameの属性値からカテゴリを取得するとともに、その下層のボタン毎の記述Ｄ４の属性名nameの属性値から文書種類の選択候補を取得し、ボタンを伴うＨＴＭＬに加工して図２３の文書種類選択欄５３３を表示する。なお、複数の所属毎の記述Ｄ１から取得したカテゴリおよび文書種類は重複するものが存在するため、ソートおよびマージを行なってからボタンを伴うＨＴＭＬに加工する。

図２３のＵＩにおける文書種類選択欄５３３および所属選択欄５３４からボタンの選択が行なわれた場合、図２４の記述による対応関係からタグを特定し、ユーザにより設定されたタグとして扱う。例えば、図２３の文書種類選択欄５３３から「予算」が選択され、所属選択欄５３４から「○×研究所」が選択された場合、図２４において、所属「○×研究所」から先頭の記述Ｄ１が特定され、文書種類「予算」から記述Ｄ４が特定され、対応するタグ「予算承認書」が得られる。

＜総括＞
以上説明したように、本発明の実施形態によれば、次のような利点がある。
（１）文書の作成者は文書内容を示す直感的なタグを付すだけでワークフローの特定が自動に行われるため、従来のように組織内の運用ルール等を確認してワークフローを特定する必要がなく、煩雑な作業から解放される。
（２）ワークフローの対象となる文書やタスクに特化したシステムではないため、
・メンテナンスが容易である
・クライアント側は汎用ブラウザで済む
・柔軟性・拡張性に富む
・ワークフロー機能を持たない既存の文書管理システム等を有効活用できる
（３）ＲＳＳリーダが定期的にＲＳＳを取得する機能を有しているため、ワークフローを遂行するために別途メール等で配信する必要がなく、配信情報の更新を効率的にチェックすることができ、手間・労力の軽減を図ることができる。
（４）ＲＳＳリーダは配信内容が見やすくなるように工夫されているため、配信された依頼の見出しのチェックが容易に行なえ、作業性を向上させることができる。
等の利点がある。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

１ メタデータ管理部
１１ ユーザ対応部
１２ メタデータ管理実行部
１３ ＵＩ生成部
１４ ＲＳＳ生成部
１４１ リクエスト受付部
１４２ タグ検索部
１４３ データ生成部
１４４ レスポンス送信部
１５ タグ解釈部
１６ ワークフロー特定要求部
１７ ワークフローステータス管理部
１８ メタデータＤＢ
１９ タグ解釈ルールＤＢ
２ ワークフロー特定部
２１ ワークフローサーバ
２２ ワークフローＤＢ
３ 文書登録部
３１ 文書登録ＷＷＷサーバ
３２ 文書登録ＤＢ
４ 認証部
４１ 認証サーバ
４２ 所属・認証ＤＢ
５、５Ａ、５Ｂ ユーザ端末
５１ ＲＳＳリーダ
５２ ブラウザ
６ タグ管理部
６１ タグ管理サーバ
６２ タグ管理ＤＢ

特開２００６−６５８７４号公報

Claims (12)

1. 第１の情報とワークフロー情報とを対応付けた管理情報に基づきワークフローを管理するワークフロー管理装置がワークフローの実行を管理するワークフロー管理方法であって、
   ワークフローを特定する第２の情報を受信する受信工程と、
   前記第２の情報と前記管理情報に基づき、前記第２の情報に対応付くワークフロー情報から実行するワークフローを特定する特定工程と、
   前記対応付くワークフロー情報から、前記実行するワークフローに含まれる審査または承認の依頼処理を、前記ワークフロー情報に基づいて特定したユーザ宛に実行する依頼工程と
   を備えることを特徴とするワークフロー管理方法。
2. ユーザを特定する第１のユーザ特定情報と、ユーザの役割を示す役割情報とを対応付けたユーザ情報と、前記管理情報に基づきワークフローを管理する前記ワークフロー管理装置がワークフローの実行を管理する請求項１に記載のワークフロー管理方法であって、
   前記ワークフロー情報は、実行するワークフローおよび当該実行するワークフローに含まれる審査または承認の依頼処理の依頼先の特定に用いる前記役割情報を含み、
   前記依頼工程は、前記依頼処理を、前記ワークフロー情報に含まれる前記役割情報と前記ユーザ情報に基づき、当該役割情報に対応する第１のユーザ特定情報のユーザ宛に実行する
   ことを特徴とするワークフロー管理方法。
3. 請求項２に記載のワークフロー管理方法であって、
   前記ユーザ情報は、前記第１のユーザ特定情報と、前記役割情報と、ユーザの所属を示す所属情報とを対応付けた情報であり、
   前記受信工程は、前記第２の情報および第２のユーザ特定情報を受信し、
   前記依頼工程は、前記依頼処理を、前記ワークフロー情報に含まれる前記役割情報と前記ユーザ情報と前記第２のユーザ特定情報とに基づき、当該役割情報に対応する第１のユーザ特定情報であり、かつ前記第２のユーザ特定情報に対応する前記所属情報と同じ所属情報で対応付く第１のユーザ特定情報のユーザ宛に実行する
   ことを特徴とするワークフロー管理方法。
4. 請求項１乃至３のいずれか一項に記載のワークフロー管理方法であって、
   前記依頼工程は、ユーザ端末にＲＳＳ配信することで、前記依頼処理をユーザ宛に実行する
   ことを特徴とするワークフロー管理方法。
5. 第１の情報とワークフロー情報とを対応付けた管理情報に基づきワークフローを管理するワークフロー管理装置であって、
   ワークフローを特定する第２の情報を受信する受信手段と、
   前記第２の情報と前記管理情報に基づき、前記第２の情報に対応付くワークフロー情報から実行するワークフローを特定する特定手段と、
   前記対応付くワークフロー情報から、前記実行するワークフローに含まれる審査または承認の依頼処理を、前記ワークフロー情報に基づいて特定したユーザ宛に実行する依頼手段と
   を備えることを特徴とするワークフロー管理装置。
6. ユーザを特定する第１のユーザ特定情報と、ユーザの役割を示す役割情報とを対応付けたユーザ情報と、前記管理情報に基づきワークフローを管理する請求項５に記載のワークフロー管理装置であって、
   前記ワークフロー情報は、実行するワークフローおよび当該実行するワークフローに含まれる審査または承認の依頼処理の依頼先の特定に用いる前記役割情報を含み、
   前記依頼手段は、前記依頼処理を、前記ワークフロー情報に含まれる前記役割情報と前記ユーザ情報に基づき、当該役割情報に対応する第１のユーザ特定情報のユーザ宛に実行する
   ことを特徴とするワークフロー管理装置。
7. 請求項６に記載のワークフロー管理装置であって、
   前記ユーザ情報は、前記第１のユーザ特定情報と、前記役割情報と、ユーザの所属を示す所属情報とを対応付けた情報であり、
   前記受信手段は、前記第２の情報および第２のユーザ特定情報を受信し、
   前記依頼手段は、前記依頼処理を、前記ワークフロー情報に含まれる前記役割情報と前記ユーザ情報と前記第２のユーザ特定情報とに基づき、当該役割情報に対応する第１のユーザ特定情報であり、かつ前記第２のユーザ特定情報に対応する前記所属情報と同じ所属情報で対応付く第１のユーザ特定情報のユーザ宛に実行する
   ことを特徴とするワークフロー管理装置。
8. 請求項５乃至７のいずれか一項に記載のワークフロー管理装置であって、
   前記依頼手段は、ユーザ端末にＲＳＳ配信することで、前記依頼処理をユーザ宛に実行する
   ことを特徴とするワークフロー管理装置。
9. 第１の情報とワークフロー情報とを対応付けた管理情報に基づきワークフローを管理するワークフロー管理装置を構成するコンピュータを、
   ワークフローを特定する第２の情報を受信する受信手段、
   前記第２の情報と前記管理情報に基づき、前記第２の情報に対応付くワークフロー情報から実行するワークフローを特定する特定手段、
   前記対応付くワークフロー情報から、前記実行するワークフローに含まれる審査または承認の依頼処理を、前記ワークフロー情報に基づいて特定したユーザ宛に実行する依頼手段
   として機能させることを特徴とするワークフロー管理プログラム。
10. ユーザを特定する第１のユーザ特定情報と、ユーザの役割を示す役割情報とを対応付けたユーザ情報と、前記管理情報に基づきワークフローを管理する請求項９に記載のワークフロー管理プログラムであって、
    前記ワークフロー情報は、実行するワークフローおよび当該実行するワークフローに含まれる審査または承認の依頼処理の依頼先の特定に用いる前記役割情報を含み、
    前記依頼手段は、前記依頼処理を、前記ワークフロー情報に含まれる前記役割情報と前記ユーザ情報に基づき、当該役割情報に対応する第１のユーザ特定情報のユーザ宛に実行する
    ことを特徴とするワークフロー管理プログラム。
11. 請求項１０に記載のワークフロー管理プログラムであって、
    前記ユーザ情報は、前記第１のユーザ特定情報と、前記役割情報と、ユーザの所属を示す所属情報とを対応付けた情報であり、
    前記受信手段は、前記第２の情報および第２のユーザ特定情報を受信し、
    前記依頼手段は、前記依頼処理を、前記ワークフロー情報に含まれる前記役割情報と前記ユーザ情報と前記第２のユーザ特定情報とに基づき、当該役割情報に対応する第１のユーザ特定情報であり、かつ前記第２のユーザ特定情報に対応する前記所属情報と同じ所属情報で対応付く第１のユーザ特定情報のユーザ宛に実行する
    ことを特徴とするワークフロー管理プログラム。
12. 請求項９乃至１１のいずれか一項に記載のワークフロー管理プログラムであって、
    前記依頼手段は、ユーザ端末にＲＳＳ配信することで、前記依頼処理をユーザ宛に実行する
    ことを特徴とするワークフロー管理プログラム。

Images