(57)【要約】【課題】予めワークフロー経路を網羅的に定義せず、尚且つ、過去に関係した帳票に関しては、たとえ所有権を失っても最後まで参照可能とする制御を実現すること。【解決手段】回付の対象である帳票と、帳票の回付先を表現する回付箱と、帳票が回付される毎に回付箱への参照を追加保持する回付履歴一覧と、回付箱のアクセス権限及び帳票のアクセス権限を決定するための条件要素となるアクセス権限一覧と、該アクセス権限一覧の構成要素である、ユーザと、グループと、回付箱のアクセス権限を取得するための回付箱アクセス権限取得部と、回付箱のアクセス権限を設定するための回付箱アクセス権限設定部と、帳票のアクセス権限を取得するための帳票アクセス権限取得部とを有することを特徴とする。【選択図】図１
2006172302.tif 000002
【特許請求の範囲】
【請求項１】
回付の対象である帳票と、帳票の回付先を表現する回付箱と、帳票が回付される毎に回付箱への参照を追加保持する回付履歴一覧と、回付箱のアクセス権限及び帳票のアクセス権限を決定するための条件要素となるアクセス権限一覧と、該アクセス権限一覧の構成要素である、ユーザと、グループと、回付箱のアクセス権限を取得するための回付箱アクセス権限取得部と、回付箱のアクセス権限を設定するための回付箱アクセス権限設定部と、帳票のアクセス権限を取得するための帳票アクセス権限取得部とを有することを特徴とするワークフロー制御方式。
【請求項２】
アクセス権限一覧中の権限の拡張属性として、回付先となる特定回付箱、回付元となる特定回付箱の識別子を備えることにより、ワークフロー経路を確定することを特徴とする請求項１記載のワークフロー制御方式。
【請求項３】
アクセス権限一覧中の権限の拡張属性として、帳票全体でなく、帳票内の個別限定部分のみに対するアクセス権限を定義することを特徴とする請求項１記載のワークフロー制御方式。
【請求項４】
一意に決定される帳票のアクセス権限を強制的に変更するための帳票アクセス権限設定部を有することを特徴とする請求項１記載のワークフロー制御方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子文書を回付するためのワークフローを制御する技術に関する。
【背景技術】
【０００２】
複数の人、チーム、組織、の間で１つの申請書、稟議書等（以下、帳票）を回覧する行為が仕事としてルール化できるとき、このルール一般のことを指してワークフローと呼ぶ。
【０００３】
帳票も含めてワークフローを電子化する際、最も留意すべき機能の１つに、帳票に対するユーザのアクセス権限制御がある。通常、帳票は或るまとまり毎に１つのデータベース（以下、ＤＢ）内に保存される。１つのＤＢに対して１つの静的なアクセス権限を設定をするのみで実運用が可能となる場合もある。
【０００４】
しかし、より厳密で柔軟なワークフローを設計する場合、帳票毎に別個のアクセス権限の設定が必要になり、又、帳票状態に応じてアクセス権限を変化させることも必要になる。このように厳しいアクセス制限が要求される一方、ユーザが一度アクセスした帳票に関しては、回付行為によりたとえ所有権利を失ったとしても、帳票内容の参照機能限定で良いから見せて欲しい、又は、帳票状況の追跡をさせて欲しい、等の要求も存在する。
【０００５】
もう１つ留意すべき機能の１つに、ワークフロー経路の自由度がある。例えば、厳密な承認行為の繰り返しによりワークフローが形成される場合、そのワークフロー経路は予め確定している場合が多い。
【０００６】
しかし、一方、次の回付先を予め確定できず、回付行為を行う瞬間にユーザ判定により決定したい、という要求が存在する。帳票を作成し最初に発行した段階では、以降の配布先若しくは回覧先が完全に未確定な場合が当て嵌る。
【０００７】
ワークフローを制御するためのシステムとして、従来では、ワークフローを制御するためのアプリケーションソフトウェアの開発工数を大幅に削減することを目的に、アプリケーション開発の設計若しくは実装上の土台（以下、フレームワーク）を提供するものが開発されている。
【０００８】
該システムのアクセス権限制御の仕組みとしては、予め帳票種類毎に、帳票状態とアクセスユーザの組み合わせによる結果、アクセス権限を定義しておく。この定義内容次第では、回付行為により一度所有権を失った帳票に関する権利を予め確保することが可能である。しかし、該方法によりアクセス権限を定義することは、言い換えると、ワークフロー上の経路を予め全て規定しなければならないことを意味する。なぜなら、この規定を行わないと、別途、アクセス権限を確定できないからである。
【０００９】
又、ワークフロー管理システム及び方法（特許文献１）においては、ワークフロー内を流れる帳票のアクセス権制御に関して、以下のような仕組みで実現している。
【００１０】
電子稟議書を次の回付先に回付可能かどうかは、文書DB内のアクセス制御情報により決定される。ワークフローはこの点によってのみ決定されるため、ワークフロー経路を予め網羅的に規定しておく必要性がない。
【００１１】
一方、電子稟議書を次組織に回付する際、電子稟議書は次組織内のＤＢにコピーされる。この後、電子稟議書のコピー元と先間にて関連付けが行われないため、特にコピー元組織内において、その後の電子稟議書内容を追跡することが不可能となる。
【００１２】
【特許文献１】特開２００２−０９９６８７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明は、予めワークフロー経路を網羅的に定義せず、尚且つ、過去に関係した帳票に関しては、たとえ所有権を失っても最後まで参照可能とする制御を実現することを目的とする。
【課題を解決するための手段】
【００１４】
上記目的を達成するため、本発明は、回付の対象である帳票と、帳票の回付先を表現する回付箱と、帳票が回付される毎に回付箱への参照を追加保持する回付履歴一覧と、回付箱のアクセス権限及び帳票のアクセス権限を決定するための条件要素となるアクセス権限一覧と、該アクセス権限一覧の構成要素である、ユーザと、グループと、回付箱のアクセス権限を取得するための回付箱アクセス権限取得部と、回付箱のアクセス権限を設定するための回付箱アクセス権限設定部と、帳票のアクセス権限を取得するための帳票アクセス権限取得部とを有することを特徴とする。
【発明の効果】
【００１５】
本発明によれば、ワークフローの全ての経路を予め定義しない自由なフローを実現しつつ、回付実行したことにより所有権を失っても、後から参照可能とするための方法を提供することができる。
【発明を実施するための最良の形態】
【００１６】
以下に本発明の実施の形態を添付図面に基づいて説明する。              図１は本発明の構成図であり、同図において、５は回付箱、６は帳票の作成場所、終了場所、若しくは、その中間における場所であり、帳票６の状態の意味に置き換えても良い。帳票６が回付箱５を回付する毎に該回付箱への参照情報が回付履歴一覧８中に追加される。帳票６自体は帳票のアクセス権限を直接決定するための情報は何も保持しないが、この回付履歴一覧８を調査することで、回付箱５、アクセス権限一覧７の順序で辿り着き、回付箱５のアクセス権限を取得することが可能となる。この回付箱５のアクセス権限が帳票のアクセス権限を決定するための要素となる。
【００１７】
特に、回付履歴一覧８中に複数の回付箱参照情報を持つ場合の帳票アクセス権限を解決するための論理手段は必須である。該論理手段は、帳票アクセス権限取得部３の中に予め保持されている。尚、本発明においては、論理手段の内容に関しては規定していない。例えば、この論理手段の中において、過去に回付経験のある回付箱の中で一度でもアクセス権限を有したことのあるユーザに対しては、たとえ最新の回付箱にてアクセス権限を有していなくても、参照権限を与える、等の定義が可能である。
【００１８】
次の回付箱５に対して回付可能かどうか及び別の回付箱５から回付受け取り可能かどうかは、回付箱５や帳票６のアクセス権限属性の１つである。回付可能権限、回付受け取り可能権限の両方を持つユーザのみが回付実行可能となる。本発明の中においてワークフローを制御する要素は唯一この部分のみである。逆にワークフロー全体の経路、例えば特定回付箱から別の特定回付箱への回付の流れ全体を定義している部分は無い。この意味で、ワークフロー制御方法として自由な経路が実現可能である。
【００１９】
尚、もし、予め経路を固定的に定義した上で厳密なワークフローを実現したいならば、回付可能権限及び回付受け取り可能権限の両方に対して拡張属性を付加し、即ち、特定の回付箱に対して回付可能な権限及び特定の回付箱から受付可能な権限の両者を設ければ実現可能である。以上が第２態様に関するワークフローのアクセス権限制御方法である。
【００２０】
又、帳票に対する権限の拡張として、帳票全体でなく、帳票内部の個別部分に対する権限定義も可能である。例えば、単なる書き込み権限としてでなく、帳票内部の一部を示す属性とともに書き込み権限を設けることにより実現可能となる。以上が第３態様に関するワークフローのアクセス権限制御方法である。
【００２１】
又、第１態様に関するアクセス権限制御により決定された帳票のアクセス権限を、例外的に特例としてその帳票だけに特殊なアクセス権限として変更することも要求される場合がある。例えば、或る帳票の中に極秘事項が記載されていたことがワークフロー運用途中で発見されたが、第１態様に関するワークフローに基づきアクセス権限を決定すると参照許可すべきでないユーザにまで権限を与えてしまうため、敢えて帳票のアクセス権限を限定することが可能である。第１態様の構成に加えて、本発明の構成図中の帳票アクセス権限設定部４を有することにより実現可能である。以上が第４態様に関するワークフローのアクセス権限制御方法である。
【００２２】
又、回付履歴一覧８は、帳票アクセス権限の解決のみでなく、他用途でも利用可能である。例えば、回付箱に回付された日時を同時に保存しておけば、各回付箱での停滞時間を後から追跡可能である。
【００２３】
本発明の実施に係る一例として、製造業者が自社内において開発中製品を評価した際の結果入力と関連部門への回付状況を追跡するシステム、障害追跡システムを挙げる。
【００２４】
該システムのハードウェア構成を図２に示す。
【００２５】
該システムは、サーバ、クライアント型のシステムであり、システムサーバ２１ではＤＢによるデータの一元管理やクライアントリクエストの一括制御を行うための装置及びソフトウェアを備え、又、クライアント端末２４，２５では、障害情報の閲覧、情報入力、更新、といったリクエストを発行可能とするための、モニタ画面及びキーボード、マウス等の入力装置を備える。
【００２６】
又、障害票を回付する毎に、回付が行われたことを回付先に通知するためにメールを送信しても良い。メールの送受信を制御するために、メールサーバ２２とクライアント端末２４，２５のメールソフトウェアが準備される。尚、サーバ及びクライアント端末は、一般的な情報処理装置（ＲＯＭから読み出されたプログラムに基づいて各処理を実行するＣＰＵ、ＲＡＭ、ハードディスクドライブ等の記憶装置）のハードウエア構成から成る。
【００２７】
図３は害障害追跡システムにおけるワークフロー全体を表現した状態遷移図である。各状態から別状態に向けて矢印が記載されている。これは、もしユーザに権限さえあれば、矢印に従って状態を遷移させることが可能であることを意味する。又、１つの状態から複数の矢印が外に向かって出ている場合は、ユーザの判断を伴い、そのどれかを決定可能なことを意味する。
【００２８】
図３におけるこれら状態は、図１本発明の構成図で言い換えると回付箱５に相当する。帳票が現在の回付箱から次の回付箱に回付される様子は、図３で言うところの現在の状態から次の状態に遷移するものと同等である。
【００２９】
システム運用開始前の準備としては、ユーザ及び必要であればグループを登録し、更に、各回付箱毎にアクセス権限を設定することである。アクセス権限としては図９のように４種類を設定可能である。アクセス権限を付与する対象としてはユーザとグループのどちらでも可能である。ここでは、図１０のようなユーザとグループを用意した。
【００３０】
ユーザとグループ登録及びアクセス権限設定のためには、図９に用意した権限とは別種の管理者特権が必要である。もし、この権限を持つユーザが該システムにログインすると、図４ログイン後の障害追跡メニューより、管理者ボタンをマウスクリック実行することが可能となる。ここで遷移した先画面にて、ユーザとグループの登録を行う。同じく遷移先画面にてアクセス権限の設定を行うべく、図８と同じ意味の情報を入力、設定することが可能となる。この図では各回付箱に対して各種アクセス権限を定義しているため、この設定により、本発明が機能することとなり以降、帳票のアクセス権限はあらゆる場面で解決されることになる。以上でシステム運用のための前準備が完了する。
【００３１】
ｕｓｅｒＢは、製品評価中に問題を発見したため、障害票を起票し、障害に関する詳細情報を入力することとする。先ず、クライアント端末２４のコンソール操作にて該システムにログインを行う。次に、障害票を起票するために図４の障害票追跡システムメニュー画面に遷移する。ここで障害票作成ボタンをマウスクリックする。このとき、ｕｓｅｒＢがマウスクリックして次画面に遷移可能かどうかは、発行待ち箱５の回付箱アクセス権限取得部１より、ｕｓｅｒＢのアクセス権限を取得し、その権限が、ｐｏｓｔ若しくは、ｗｒｉｔｅかどうかで決定される。もし、どちらの権限でもない場合は、予め障害票作成ボタン自体を制御不能状態にしておいても良い。実際には、ｕｓｅｒＢの発行待ち箱の権限は、図８よりｐｏｓｔとｗｒｉｔｅとｒｅａｄ権限を保有しているため、次画面即ち新規に障害票を作成するための画面に遷移することができる。障害票画面例は、図６であり、ここで画面下部、編集ボタンをマウスクリックすることにより、画面は文字入力可能なモードに変化する。この画面にて文字入力を行い、画面下部の保存ボタンをマウスクリックすると、入力データ全てがサーバに送信される。
【００３２】
この時点で、サーバ上では、帳票実体が１つ生成され帳票のアクセス権限も完全に確定している。例えば、ｕｓｅｒＣが該システムに対してログインしたとする。図４のシステムメニュー画面にて発行待ちボタンをマウスクリックした場合、図５の障害票一覧画面が開くが、ここで表示される障害票はｕｓｅｒＢにとって参照権限を持つもののみである。この権限を調査するために、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作する。
【００３３】
ｕｓｅｒＢの場合、Ｓ１にてｕｓｅｒＢを取得し、続けてＳ２にて発行待ち箱を取得し、続けてS3にて発行待ち箱のアクセス権限を取得する。次いで、Ｓ４にて取得したアクセス権限を調べると、ｕｓｅｒＢはｇｒｏｕｐＡに含まれること及びｇｒｏｕｐＡに対してｐｏｓｔとｗｒｉｔｅとｒｅａｄ権限が与えられていることが判明するため、Ｓ１１にてこのｐｏｓｔとｗｒｉｔｅとｒｅａｄ権限をｕｓｅｒＢの権限として決定される。結果、該障害票が１つ、障害票一覧画面上に一覧される。ここで、更に所望の障害票No部分をマウスクリックすることにより、図６の障害票詳細画面を表示することが可能である。
【００３４】
続けて、ｕｓｅｒＣが、障害票を関連部門０へ回付することを試みた場合の動作を説明する。ｕｓｅｒＣは、今閲覧している図６の障害票詳細画面の下部回付ボタンのマウスクリックを行う。回付ボタンがマウスクリック可能かどうかは、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１に従い決定される。前述と全く同じ動作が行われ、結果、ｐｏｓｔ権限ありと判定される。従って、次画面遷移が成功する。次画面の表示例は、図７の回付先選択と回付実行画面である。該画面にて表示される回付先は、ｕｓｅｒＣにとって回付受け付け可能な権限であるｒｅｃｖを持つ回付箱のみである。実際には、図８にある全回付箱のアクセス権限を調べると、回覧中箱０のみｐｏｓｔ権限を持つことが判定されるため、該画面にて表示される回付先は、この部門回覧中箱０のみとなる。
【００３５】
本実施の形態においては、回覧先部門として１つ、０部門を取り上げたが、例えば同様の回覧先部門として別部門を別途設けても構わない。この場合、例えば、Ｐ部門用に、ｇｒｏｕｐＰとその構成ユーザ及びＰ回覧中箱、Ｑ部門用にｇｒｏｕｐＱとその構成ユーザ及びＱ回覧中箱、といった具合に別途新設し、更に、図８の要領で新設した回付箱と各々与える権限を追加すれば良い。この追加行為をシステム運用の開始後に後付けで行っても構わない。この際重要なことは、回付箱毎に権限を設定するのみで、即ち、障害票のワークフロー全体のフロー経路に関しては一切考慮することなしに、運用が成り立つ点である。この点において、ワークフロー設計の自由度が高いと言える。
【００３６】
ｕｓｅｒＣは、図７の回付先選択画面において、回覧中箱０を選択するために同画面左部のボタンにマウスにてチェックを入れる。その後、画面下部の回付ボタンをマウスクリックすると、回覧箱０への障害票回付が行われる。
【００３７】
このとき同時に、メール送付が行われても良い。メール送信先は回覧箱０にｒｅａｄ権限を持つユーザやグループである。例えば、この場合はｇｒｏｕｐ０である。メール本文の中には、このとき回付された障害票へのリンク情報があり、任意メーラソフトを使用してこのリンク情報を辿ると、障害票詳細画面が直接開く仕組みを設けることが可能である。
【００３８】
又、上記のようにメールでなく、別途、ｕｓｅｒ０がシステムにログインし、図４の障害管理追跡システムメニューを表示した上で、回覧中ボタンをマウスクリックする、という操作手順を行なっても良い。この操作を行った場合、次に図５のの障害票一覧画面が開くが、ここで表示される障害票はｕｓｅｒ０にとって参照権限を持つもののみである。この権限を調査するために、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１に従い決定される。ｕｓｅｒ０の場合、Ｓ１にてｕｓｅｒ０を取得し、続けてＳ２にて回覧中箱０を取得し、続けてＳ３にて回覧中箱０のアクセス権限を取得する。次いで、Ｓ４にて取得したアクセス権限を調べると、ｕｓｅｒ０はｇｒｏｕｐ０に含まれること及びｇｒｏｕｐ０に対してｐｏｓｔとｒｅａｄ権限が与えられていることが判明するためＳ１１にてこのｐｏｓｔとｒｅａｄ権限をｕｓｅｒ０の権限として決定される。結果、障害票が１つ、障害票一覧画面上に一覧される。
【００３９】
ｕｓｅｒ０は、図６の障害票詳細画面より障害票の中身を閲覧した上で、再度、発行待ち箱に回付することを行う。このためには、先ず、画面下部の回付ボタンをマウスクリックすることにより図７の回付先選択と回付実行画面を開く。回付ボタンがマウスクリック可能かどうかを判定するために、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作する。前述と全く同じ動作が行われ、結果、ｐｏｓｔ権限ありと判定される。従って、次画面遷移が成功する。次画面にて表示される回付先は、該ｕｓｅｒ０にとって回付受け付け可能な権限であるｒｅｃｖを持つ回付箱のみである。実際には、図８にある全回付箱のアクセス権限を調べると、発行待ち箱のみｒｅｃｖ権限を持つことが判定されるため、該画面にて表示される回付先は、この発行待ち箱のみとなる。
【００４０】
ｕｓｅｒ０は、図７の回付先選択と回付実行画面において、発行待ち箱を選択するために同画面左部のボタンにマウスにてチェックを入れる。その後、画面下部の回付ボタンをマウスクリックすると、発行待ち箱への障害票回付が行われる。
【００４１】
このとき同時に、メール送付が行なわれても良い。メール送信先は発行待ち箱にｒｅａｄ権限を持つユーザやグループである。例えば、この場合はｇｒｏｕｐＡである。メール本文の中には、このとき回付された該障害票へのリンク情報があり、任意メーラソフトを使用してこのリンク情報を辿ると、障害票詳細画面が直接開く仕組みを設けることが可能である。
【００４２】
ｇｒｏｕｐＡにはｕｓｅｒＡが含まれるため、ＵｓｅｒＡは、このメールを受信後、メール本文の該障害票リンクを辿ると、先ず、システムへのログイン画面が表示され、そこでログイン操作を行う。認証動作に成功すると、該障害票の図６の障害詳細画面が表示される。
【００４３】
ｕｓｅｒＡは、障害票の中身を閲覧した上で、該記入内容を承認し、障害票を開発部門へ回付することを行う。このためには、先ず、画面下部の回付ボタンをマウスクリックすることにより図７の回付先選択と回付実行を開く。回付ボタンがマウスクリック可能かどうかを判定するために、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作する。ｕｓｅｒＡの場合、Ｓ１にてｕｓｅｒＡを取得し、続けてＳ２にて発行待ち箱を取得し、続けてＳ３にて発行待ち箱のアクセス権限を取得する。
【００４４】
次いで、Ｓ４にて取得したアクセス権限を調べると、ＵｓｅｒＡはｇｒｏｕｐＡに含まれること及びｇｒｏｕｐＡに対してｐｏｏｓｔとｗｒｉｔｅとｒｅａｄ権限が与えられていることが判明するため、Ｓ１１にてこのｐｏｓｔとｗｒｉｔｅとｒｅａｄ権限をｕｓｅｒＡの権限として決定される。結果、ｐｏｓｔ権限ありと判定される。従って、次画面遷移が成功する。次画面の表示例は、図７の回付先選択と回付実行である。該画面にて表示される回付先は、ｕｓｅｒＡにとって回付受け付け可能な権限であるｒｅｃｖを持つ回付箱のみである。実際には、図８にある全回付箱のアクセス権限を調べると、回覧中箱０と、回答待ち箱と、回答中箱と、終了箱にｒｅｃｖ権限を持つことが判定されるため、該画面にて表示される回付先は、この回覧中箱０と、回答待ち箱と、回答中箱と、終了箱となる。
【００４５】
ｕｓｅｒＡは、図７のの回付先選択と回付実行画面において、回答待ち箱を選択するために回答待ち箱左部のボタンにマウスにてチェックを入れる。この後画面下部の回付ボタンをマウスクリックすると、回答待ち箱への障害票回付が行われる。
【００４６】
障害票の回付実行が行われたことにより、以前に障害票に係った、例えば評価部門のユーザであるｕｓｅｒＢによる該障害票へのアクセス時の様子を検証する。
【００４７】
このときのアクセス権限決定のために、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作する。ｕｓｅｒＢの場合、Ｓ１にてｕｓｅｒＢを取得し、続けてＳ２にて回答待ち箱を取得し、続けてＳ３にて回答待ち箱のアクセス権限を取得する。次いで、Ｓ４にて取得したアクセス権限を調べると、ｕｓｅｒＢはどこにも存在しないことが判明する。従って、次のＳ５で回覧中箱０を取得し、続けてＳ７にて回覧中箱０のアクセス権限を取得する。次いで、Ｓ８にて取得したアクセス権限を調べると、ｕｓｅｒＢはここでも存在しないことが判明する。再度、Ｓ５で発行待ち箱を取得し、続けてＳ７にて発行待ち箱のアクセス権限を取得する。次いで、Ｓ８にて取得したアクセス権限を調べると、ｕｓｅｒＢはｇｒｏｕｐＡに含まれることが判明するためＳ１０にてこのｕｓｅｒＡの権限は強制的にｒｅａｄとして決定される。
【００４８】
上記例のようにたとえ現在の回付箱にはアクセス権限が無くても、過去に回覧した回付箱でアクセス権限が定義されていれば、必ず閲覧する権限が保証されることとなる。
【００４９】
ｕｓｅｒＡによる回付実行と同時に、メール送付が行われても良い。このときのメール送信先は回答待ち箱にｐｏｓｔ若しくはｗｒｉｔｅ権限を持つユーザやグループである。例えば、この場合はｕｓｅｒＸである。メール本文の中には、この時回付された障害票へのリンク情報があり、任意メーラソフトを使用してこのリンク情報を辿ると、障害票詳細画面が直接開く仕組みを設けることが可能である。
【００５０】
ｕｓｅｒＸは、このメールを受信後、メール本文の該障害票リンクを辿ると、先ず、システムへのログイン画面が表示され、そこでログイン操作を行う。認証動作に成功すると、該障害票の図６の障害票詳細画面が表示される。
【００５１】
ｕｓｅｒＸは、障害票の中身を閲覧した上で、該記入内容を承認し、障害票を適切な開発担当者へ回付することを行う。このためには、先ず、該画面下部の回付ボタンをマウスクリックすることにより図７の回付先選択と回付実行画面を開く。回付ボタンがマウスクリック可能かどうかを判定するために、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作する。ｕｓｅｒＸの場合、Ｓ１にてｕｓｅｒＸを取得、続けてＳ２にて回答待ち箱を取得し、続けてＳ３にて回答待ち箱のアクセス権限を取得する。次いで、Ｓ４にて取得したアクセス権限を調べると、ｕｓｅｒＸはｇｒｏｕｐＸに含まれること及びｇｒｏｕｐＸに対してｒｅａｄ権限が与えられていることが判明するため、Ｓ１１にてｐｏｓｔとｗｒｉｔｅとｒｅａｄ権限をｕｓｅｒＸの権限として決定される。結果、ｐｏｓｔt 権限ありと判定される。従って、次画面遷移が成功する。
【００５２】
次画面の表示例は、図７回付先選択と回付実行である。該画面にて表示される回付先は、ｕｓｅｒＸにとって回付受け付け可能な権限であるｒｅｃｖを持つ回付箱のみである。実際には、図８にある全回付箱のアクセス権限を調べると、回答中箱と、回答承認待ち箱と、確認待ち箱にｒｅｃｖ権限を持つことが判定されるため、該画面にて表示される回付先は、この回答中箱と、回答承認待ち箱と、確認待ち箱となる。
【００５３】
ｕｓｅｒＸは、図７の回付先選択と回付実行画面において、回答中箱を選択するために回答中箱左部のボタンにマウスにてチェックを入れる。その後、画面下部の回付ボタンをマウスクリックすると、回答中箱への障害票回付が行われる。
【００５４】
又、このとき同時に、メール送付が行われても良い。メール送信先は回答中箱にｒｅａｄ権限を持つユーザやグループである。例えば、この場合はｇｒｏｕｐＸである。メール本文の中には、このとき回付された該障害票へのリンク情報があり、任意メーラソフトを使用してこのリンク情報を辿ると、該障害票詳細画面が直接開く仕組みを設けることが可能である。
【００５５】
ｇｒｏｕｐＸにはｕｓｅｒＸとｕｓｅｒＹとｕｓｅｒＺが含まれるため、三者はこのメールを受信後、メール本文の該障害票リンクを辿ると、先ず、システムへのログイン画面が表示され、そこでログイン操作を行う。認証動作に成功すると、図６の障害票の障害画面が表示される。
【００５６】
三者が該障害票を閲覧した結果、ｕｓｅｒＹが回答作業を行うことを決定したと仮定する。回答作業は、図６の障害票詳細画面上にて情報入力を行うことで成立する。このためには同画面下部編集ボタンをマウスクリックすることによって行う。マウスクリック可能かどうかは、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作することで判定される。
【００５７】
ｕｓｅｒＹの場合、Ｓ１にてｕｓｅｒＹを取得し、続けてＳ２にて回答中箱を取得し、続けてＳ３にて回答中箱のアクセス権限を取得する。次いで、Ｓ４で取得したアクセス権限を調べると、ｕｓｅｒＹは、ｇｒｏｕｐＸに含まれること及びｇｒｏｕｐＸに対してｐｏｓｔとｒｅｃｖとｗｒｉｔｅとｒｅａｄ権限が与えられていることが判明するため、Ｓ１１にてｐｏｓｔとｒｅｃｖとｗｒｉｔｅとｒｅａｄ権限をｕｓｅｒＹの権限として決定される。結果、ｗｒｉｓｔｅ権限ありと判定される。この場合はマウスクリック動作成功し、同障害票の入力編集画面に遷移する。同入力編集画面にて入力作業を行った後、画面下部の保存ボタンをマウスクリックすると、入力データ全てがサーバに送信される。
【００５８】
次に、ｕｓｅｒＹは、回答入力した内容に関して承認を得るため、該障害票を回答承認待ち箱に回付することを行う。このためには、先ず、該画面下部の回付ボタンをマウスクリックすることにより図７の回付先選択と回付実行画面を開く。回付ボタンがマウスクリック可能かどうかを判定するために、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作する。前述と全く同じ動作が行われ、結果、ｐｏｓｔ権限ありと判定される。従って、次画面遷移が成功する。
【００５９】
次画面の表示例は、図７の回付先選択と回付実行画面である。該画面にて表示される回付先は、userY にとって回付受け付け可能な権限であるrecvをもつ回付箱のみである。実際には、図８にある全回付箱のアクセス権限を調べると、回答中箱と、回答承認待ち箱にrecv権限を持つことが判定されるため、該画面にて表示される回付先は、この回答中箱と、回答承認待ち箱となる。
【００６０】
ｕｓｅｒＹは、図７の回付先選択と回付実行画面において、回答承認待ち箱を選択するために回答承認待ち左部のボタンにマウスにてチェックを入れる。この後画面下部の回付ボタンをマウスクリックすると、回答中箱への障害票回付が行われる。
【００６１】
又、このとき同時に、メール送付が行なわれても良い。このときのメール送信先は回答承認待ち箱にｐｏｓｔ若しくはｗｒｉｔｅ権限を持つユーザやグループである。例えば、この場合はｕｓｅｒＸである。メール本文の中には、このとき回付された障害票へのリンク情報があり、任意メーラソフトを使用してこのリンク情報を辿ると、障害票詳細画面が直接開く仕組みを設けることが可能である。
【００６２】
ｕｓｅｒＸは、このメールを受信後、メール本文の障害票リンクを辿ると、先ず、システムへのログイン画面が表示され、そこでログイン操作を行う。認証動作に成功すると、障害票の図６の障害票詳細画面が表示される。
【００６３】
ｕｓｅｒＸは、障害票の中身を閲覧した上で、該記入内容を承認し、該障害票を評価部門へ戻すための回付を行うことをする。このためには、先ず、画面下部の回付ボタンをマウスクリックすることにより図７の回付先選択と回付実行画面を開く。回付ボタンがマウスクリック可能かどうかを判定するために、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作する。ｕｓｅｒＸの場合、Ｓ１にてｕｓｅｒＸを取得し、続けてＳ２にて回答承認待ち箱を取得し、続けてＳ３にて回答承認待ち箱のアクセス権限を取得する。次いで、Ｓ４にて取得したアクセス権限を調べると、ｕｓｅｒＸはｇｒｏｕｐＸに含まれること及びｇｒｏｕｐＸに対してｒｅａｄ権限が与えられていることが判明するため、Ｓ１１にてｐｏｓｔとｗｒｉｔｅとｒｅａｄ権限をｕｓｅｒＸの権限として決定される。結果、ｐｏｓｔ権限ありと判定される。従って、次画面遷移が成功する。
【００６４】
次画面の表示例は、図７の回付先選択と回付実行である。該画面にて表示される回付先は、ｕｓｅｒＸにとって回付受け付け可能な権限であるｒｅｃｖを持つ回付箱のみである。実際には、図８にある全回付箱のアクセス権限を調べると、回答中箱と、回答承認待ち箱と、確認待ち箱にｒｅｃｖ権限を持つことが判定されるため、該画面にて表示される回付先は、この回答中箱と、回答承認待ち箱と、確認待ち箱となる。
【００６５】
ｕｓｅｒＸは、図の７回付先選択と回付実行画面において、確認待ち箱を選択するために確認待ち箱左部のボタンにマウスにてチェックを入れる。この後画面下部の回付ボタンをマウスクリックすると、確認待ち箱への障害票回付が行われる。
【００６６】
又、このとき同時に、メール送付が行なわれても良い。このときのメール送信先は確認待ち箱にｐｏｓｔ若しくはｗｒｉｔｅ権限を持つユーザやグループである。例えば、この場合はｇｒｏｕｐＡである。メール本文の中には、この時回付された該障害票へのリンク情報があり、任意メーラソフトを使用してこのリンク情報を辿ると、該障害票詳細画面が直接開く仕組みを設けることが可能である。
【００６７】
ｕｓｅｒＸは、このメールを受信後、メール本文の該障害票リンクを辿ると、先ず、該システムへのログイン画面が表示され、そこでログイン操作を行う。認証動作に成功すると、該障害票の図６障害票詳細画面が表示される。
【００６８】
ｇｒｏｕｐＡにはｕｓｅｒＢが含まれるため、ｕｓｅｒＢは、このメールを受信後、メール本文の該障害票リンクを辿ると、先ず、該システムへのログイン画面が表示され、そこでログイン操作を行う。認証動作に成功すると、図６に示す障害票の障害詳細画面が表示される。
【００６９】
ｕｓｅｒＢは、開発部門が入力した内容及び別途送付された製品の次改定版を評価することで確認作業とし、その結果を障害票に入力することを行う。このためには同画面下部編集ボタンをマウスクリックすることによって行う。マウスクリック可能かどうかは、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作することで判定される。
【００７０】
ｕｓｅｒＢの場合、Ｓ１にてｕｓｅｒＢを取得、続けてＳ２にて確認待ち箱を取得、続けてＳ３にて確認待ち箱のアクセス権限を取得する。次いで、Ｓ４で取得したアクセス権限を調べると、ｕｓｅｒＢはｇｒｏｕｐＡに含まれること及びｇｒｏｕｐＡに対してｐｏｓｔとｒｅｃｖとｗｒｉｔｅとｒｅａｄ権限が与えられていることが判明するため、Ｓ１１にてｐｏｓｔとｗｒｉｔｅとｒｅａｄ権限をｕｓｅｒＢの権限として決定される。結果ｗｒｉｔｅ権限ありと判定される。この場合はマウスクリック動作成功し、同障害票の入力編集画面に遷移する。同入力編集画面にて入力作業を行った後、画面下部の保存ボタンをマウスクリックすると、入力内容が保存され、入力データ全てがサーバに送信される。
【００７１】
ここで確認の結果、障害が修正され製品仕様通りの動作に改められたとする。ｕｓｅｒＢは、続けて障害票を終了させることを行う。このためには、先ず、画面下部の回付ボタンをマウスクリックすることにより図７の回付先選択と回付実行画面を開く。回付ボタンがマウスクリック可能かどうかを判定するために、帳票アクセス権限取得部３内における帳票アクセス権限を決定するための処理フローである図１１が動作する。ｕｓｅｒＢの場合、Ｓ１にてｕｓｅｒＢを取得、続けてＳ２にて確認待ち箱を取得、続けてＳ３にて確認待ち箱のアクセス権限を取得する。次いで、Ｓ４取得したアクセス権限を調べると、ｕｓｅｒＢは、ｇｒｏｕｐＡに含まれること及びｇｒｏｕｐＡに対してｐｏｓｔ権限が与えられていることが判明するため、Ｓ１１にてｐｏｓｔ権限をｕｓｅｒＸの権限として決定される。結果、ｐｏｓｔ権限ありと判定される。従って、次画面遷移が成功する。
【００７２】
次画面の表示例は、図７の回付先選択と回付実行である。この画面にて表示される回付先は、ｕｓｅｒＢにとって回付受け付け可能な権限であるｒｅｃｖを持つ回付箱のみである。実際には、図８にある全回付箱のアクセス権限を調べると、回覧中箱０と、終了箱にｒｅｃｖ権限を持つことが判定されるため、該画面にて表示される回付先は、この回覧中箱０と、終了箱となる。
【００７３】
ｕｓｅｒＢは、図７の回付先選択と回付実行画面において、終了箱を選択するために確認待ち箱左部のボタンにマウスにてチェックを入れる。この後画面下部の回付ボタンをマウスクリックすると、終了箱への障害票回付が行われる。
【００７４】
以上で１つの障害票が起票されてから終了するまでの回付経路の一例を示した。回付経路に関しては先述したように、回付ボタンをマウスクリックする毎に操作ユーザの権限内で回付可能な回付先を選択可能なため、自由度が高く臨機応変な回付を実現可能である。又、回付が行われることで障害票の所有権を失ったり、他部門へ回付されてしまった後でも、一度権限を得たことのある障害票に関しては最低でも参照権限を確保している。
【図面の簡単な説明】
【００７５】
【図１】本発明のワークフロー制御のための構成図である。
【図２】本発明を障害追跡システムに適用した場合のハードウェア構成例を示す図である。
【図３】本発明を障害追跡システムに適用した場合の状態遷移例を示す図である。
【図４】クライアント端末上での障害追跡システムメニュー画面例を示す図である。
【図５】クライアント端末上での障害票一覧画面例を示す図である。
【図６】クライアント端末上での障害票詳細画面例を示す図である。
【図７】クライアント端末上での次回付箱選択のための画面例を示す図である。
【図８】回付箱に権限を割り当てたときの設定例を示す図である。
【図９】回付箱に割り当て可能な権限の全ての例を示す図である。
【図１０】権限を割り当てる対象の登録例を示す図である。
【図１１】帳票アクセス権限取得部内にて帳票のアクセス権限を決定するための処理フローの例を示す図である。
【符号の説明】
【００７６】
１      回付箱アクセス権限取得部
２      回付箱アクセス権限設定部
３      帳票アクセス権限取得部
４      帳票アクセス権限設定部
５      回付箱
６      帳票
７      アクセス権限一覧
８      回付履歴一覧
９      ユーザ
１０    グループ
２１    システムサーバ
２２    メールサーバ
２４    ネットワーク
２５，２６  クライアント端末
３１    発行待ち
３２    回答待ち
３３    回覧中
３４    回答中
３５    確認待ち
３６    回答承認待ち
３７    終了
【図１】
2006172302.tif 000003
【図２】
2006172302.tif 000004
【図３】
2006172302.tif 000005
【図４】
2006172302.tif 000006
【図５】
2006172302.tif 000007
【図６】
2006172302.tif 000008
【図７】
2006172302.tif 000009
【図８】
2006172302.tif 000010
【図９】
2006172302.tif 000011
【図１０】
2006172302.tif 000012
【図１１】
2006172302.tif 000013