JPH08123869A - 情報処理システム - Google Patents

Abstract

(57)【要約】 【目的】 順序立てて処理すべき作業を複数個の作業工
程に分け、その作業工程の順序と、各作業工程の処理内
容と、各作業工程の担当者とを定めて、作業を支援する
情報処理システムで、時間経過や状況変化に対応した緊
急度を得る。 【構成】 保持手段４４で作業工程識別情報と、作業工
程で行なう処理に関する期限情報と、各作業工程の担当
者の識別情報とを当該作業工程に対応させて保持する。
期限情報を変更するための変更手段４７を設ける。作業
工程での処理に関する緊急度を求めるための判定基準を
保持する保持手段４５を設ける。保持手段４５に保持さ
れた判定基準と、期限情報と、現在の暦情報とに基づき
作業工程の緊急度を求める。担当者を特定して当該担当
者が処理すべき作業工程に関する前記緊急度を含む情報
の作成を要求する要求手段５２を設ける。要求手段５２
からの要求に応じて、作業工程識別情報と、期限情報
と、緊急度とを含む情報の一覧を表示する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、情報を媒介にして連
携する複数の作業工程からなる作業（ワークフローと称
する）について、複数の作業工程の順序と、各作業工程
の処理内容と、各作業工程の担当者とを定め、各作業工
程の間での情報の受け渡しなど、作業処理を支援する情
報処理システムに関する。特に、各作業工程の担当者に
伝えるその作業処理の緊急度に関する発明である。

【０００２】

【従来の技術】従来から、業務処理の作業効率化を図る
ために、コンピュータによる、いわゆるオフィスオート
メーション化が提案されている。しかし、従来は、業務
処理における個々の作業処理自体についての自動化が行
なわれているだけであった。つまり、作業間の連携の部
分については、従来のオフィスオートメーションでは考
慮されていなかった。

【０００３】この作業間の連携部分を自動化して作業処
理のトータルな効率化や迅速化を図ろうとするものとし
て、ワークフロー・オートメーションが提案されてい
る。ワークフロー・オートメーションにおいては、作業
対象となる情報を媒介にして連携する複数の作業工程は
ワークフローと呼ばれ、このワークフローを自動化する
ための支援システムとしての情報処理システムはワーク
フローシステムと呼ばれる。

【０００４】ワークフローシステムは、例えばネットワ
ーク化された分散処理環境などの処理環境において、業
務処理における複数の作業工程の担当者間の情報の受け
渡しと、情報を受けてから次の作業工程に渡すまでの間
に処理すべき作業などを、予め設計、定義することによ
り業務処理を管理する情報処理システムである。

【０００５】このワークフローシステムは、次のような
処理機能で構成される。 作業処理の流れ、各作業工程の作業内容や、各作業工
程におけるルール（約束事）を定義するための編集機能 定義されたワークフロー（以下、定義されたワークフ
ローをテンプレートという）を管理するテンプレート機
能 処理すべき情報が配達されたことを担当者に知らせる
通知機能 配達された情報を管理するデータベース機能 設定された作業の流れ、ルールなどに従って情報を次
の作業工程に渡すルーティング機能 作業の状況を管理するための進捗管理機能 実行中のワークフローの維持管理を行なうためのシス
テム管理機能。

【０００６】このワークフローシステムの概要は、文献
１：日経ＢＰ社発行の雑誌「日経情報ストラテジー」
１９９３年８月号、マイケル・Ｄ・カーン、安田誠寄
稿、「ワークフロー管理技術とその可能性」Ｐ１２３〜
Ｐ１３０に記載されている。

【０００７】上述したワークフローにおいて、各作業工
程（以下、作業工程をステップという）の担当者に対し
て、その仕事（作業処理）の緊急度を伝えることの重要
性は、前記雑誌に記載されているように、既に認識され
ている。

【０００８】そして、緊急度を伝達すると言うことに関
しては、電子メールシステムにおいて、発信する側が緊
急度や優先度をメールに付加し、それに応じて受信側に
おいてメール情報を格納するためのメールボックスの中
で、対応するメールの表示パターンを変え、重要性の違
いを識別しやすくするという提案が、既に行なわれてい
る（文献２：特開昭６３−３１２７４９号公報）。しか
しながら、従来の緊急度の担当者への伝達においては、
緊急度は、相手が受け取った後では変わることがなく、
固定的である。

【０００９】

【発明が解決しようとする課題】ここで、ワークフロー
システムにおける緊急度について具体的に考察すると、
緊急度に関する期限情報、例えば、ステップの担当者の
受け持つ仕事の終了予定日に変更がない場合でも、時間
の経過により終了予定日が近付くにつれて、必然的にそ
の仕事の緊急度は高まっていくものである。

【００１０】また、ワークフローシステムの管理者が、
当初設定した期限情報としての終了予定日を早める変更
を行なうと、現在の日付から終了予定日までの間隔が短
くなることから、当初の緊急度よりも緊急度が高くな
り、また、逆に終了予定日を延期すると、現在の日付か
ら終了予定日までの間隔は長くなり、当初の緊急度より
も緊急度は低くなる。

【００１１】しかし、上述したように、従来の緊急度の
伝達の仕方では、一旦設定された緊急度は、固定的であ
り、終了予定日が近付くにつれて緊急度を変化させるよ
うにすることができなかった。そのため、時間の経過に
伴う、緊急度の変更に対応できないという問題があっ
た。

【００１２】また、従来の緊急度の伝達の方法では、終
了予定日を変更する前に緊急度が通知されたときには、
その後にワークフローシステムの管理者に終了予定日が
変更されても、通知を受け取った時点における緊急度で
固定され、変わることがないため、担当者は、誤った緊
急度の情報を頭に置いて作業を進めてしまう問題があ
る。すなわち、従来の緊急度の伝達では、状況の変化に
伴う緊急度の変更に対応できなかった。

【００１３】この発明は、以上の点にかんがみ、時間の
経過や、状況の変化に伴ない、緊急度を変更して作業担
当者に通知することができるようにした情報処理システ
ムを提供することを目的とする。

【００１４】

【課題を解決するための手段】上記課題を解決するた
め、この発明による情報処理システムは、後述の実施例
の参照符号を対応させると、順序立てて処理すべき作業
を、複数個の作業工程に分け、その複数個の作業工程の
順序と、各作業工程の処理内容と、各作業工程の担当者
とを定めて、前記作業を支援する情報処理システムにお
いて、前記作業工程のそれぞれを一意に識別するための
作業工程識別情報と、前記作業工程で行なう処理に関す
る期限についての期限情報と、各作業工程の処理を実行
すべき担当者を識別するための担当者識別情報とを当該
作業工程に対応させて保持する第１の保持手段（４４）
と、第１の保持手段（４４）に保持された期限情報を変
更するための変更手段（４７）と、前記作業工程での処
理に関する緊急度を求めるための判定基準を保持する第
２の保持手段（４５）と、第２の保持手段（４５）に保
持された判定基準と、第１の保持手段（４４）に保持さ
れた担当者が処理すべき作業工程の期限情報と、現在の
暦情報とに基づき当該作業工程の緊急度を求める緊急度
判定手段（５６）と、前記担当者を特定して当該担当者
が処理すべき作業工程に関する緊急度を含む情報の作成
を要求する要求手段（５２）と、要求手段（５２）から
の要求に応じて、前記作業工程識別情報と、前記期限情
報と、緊急度判定手段（５６）により求められた緊急度
とを含む情報の一覧を、前記特定された担当者に付き作
成する一覧作成手段（５６）と、一覧作成手段（５６）
により作成された前記一覧を前記特定された担当者に対
して可視化出力する出力手段とを備えることを特徴とす
る。

【００１５】

【作用】上記の構成の情報処理システムにおいては、要
求手段から、担当者が特定されて、その担当者が処理す
べき作業工程に関する緊急度を含む情報の作成の要求が
発生すると、一覧作成手段では、この要求手段から要求
に応じて、作業工程識別情報と、期限情報と、前記緊急
度判定手段により求められた緊急度とを含む情報の一覧
が、要求手段で特定された担当者に付き作成される。そ
して、出力手段により、作成された情報一覧が、要求手
段で特定された担当者に対して可視化出力される。

【００１６】このため、要求手段により要求が発生する
毎に、要求手段で特定された担当者に対して、緊急度が
伝達される。このとき、各担当者が処理すべき作業工程
の期限情報は、変更手段により適宜変更されることがあ
るが、緊急度判定手段では、その変更された期限情報を
用いて緊急度の判定を行なう。したがって、状況の変化
に対応した緊急度の伝達が可能になる。

【００１７】また、緊急度判定手段では、第２の保持手
段に保持された判定基準と、第１の保持手段に保持され
た各担当者が処理すべき作業工程の期限情報と、現在の
暦情報とに基づき、当該作業工程の緊急度が求められ
る。したがって、時間が経過して現時点が変化するにし
たがって緊急度判定手段で求められる緊急度が変わる。
つまり、時間の経過に応じて適切に変化する緊急度が得
られ、これが要求手段からの要求の発生に応じて担当者
に伝達される。

【００１８】

【実施例】以下、この発明による情報処理システムの一
実施例を、図を参照しながら説明する。

【００１９】図２は、この例の情報処理システムの全体
の概要を示すもので、その機能をブロックとして示した
ものである。この情報処理システムは、前述したワーク
フローシステムの構成を有するものであって、いわゆる
サーバー／クライアントモデルに基づいたものとされて
いる。

【００２０】図２の例では、サーバー側は、ワークフロ
ーのデータに従って作業工程の遷移や、作業工程の担当
者（ユーザ）への情報の受け渡しを管理して、作業処理
を支援するシステム部１０とされており、また、クライ
アント側は、各作業工程（以下、作業工程をステップと
呼ぶ）の担当者による処理を支援するための作業環境を
提供するユーザインターフェース部２０とされている。

【００２１】システム部１０は、ファイル管理装置を内
蔵する例えばサーバー装置の構成とされている。また、
ユーザインターフェース部２０は、例えばワークステー
ションなどの情報処理端末装置により構成することがで
き、そのディスプレイに各作業工程の作業環境を表示す
ることができ、ユーザはその表示画面を見ながら作業処
理やシステム部１０への通知のための操作入力を行う。

【００２２】ユーザインターフェース部２０は、複数の
担当者が共通の１個を共有して使用するように構成する
こともできるが、この例では、担当者毎に設けられた構
成とされている。そして、システム部１０とユーザイン
ターフェース部２０とは、例えばＬＡＮ（ローカルエリ
アネットワーク）３０などの通信手段により接続され
て、分散処理環境として構築されている。

【００２３】なお、システム部１０とユーザインターフ
ェース部２０とを同一の装置において構成することもで
きる。

【００２４】システム部１０は、テンプレート管理機能
部１１と、ルーティング機能部１２と、通知管理機能部
１３と、進捗情報管理機能部１４と、ユーザ管理機能部
１５と、参照情報管理機能部１６と、システム管理機能
部１７とを備える。また、ユーザインターフェース部２
０は、編集部２１と、通知部２２と、進捗管理部２３
と、インターフェースコントロール部２４とを備える。

【００２５】ユーザインターフェース部２０の編集部２
１では、ユーザの操作入力に応じてテンプレートや実行
しようとするワークフロー（この実行しようとするワー
クフローを、以下、実行フローという）を編集する。

【００２６】通知部２２は、システム部１０からの通知
を受け取ってユーザに知らせたり、また、ユーザの操作
指示に応じてシステム部１０に指示や通知を送る。ま
た、進捗管理部２３は、ユーザインターフェース部２０
での作業遷移状態を管理する。

【００２７】システム部１０のテンプレート管理機能部
１１は、定義されたワークフローであるテンプレートを
記憶、管理する。

【００２８】ルーティング管理機能部１２は、実行フロ
ーにおいて、設定された業務の流れや、あらかじめ定義
されたルールにしたがって、あるステップの作業が終了
したときに、後続のステップの作業を開始させるか否か
を決定する。なお、あるステップの作業が終了したとき
に、後続のステップの作業を開始させることを、その後
続のステップに対してルーティングを行なうといい、後
続のステップに仕事を開始させない場合は、ルーティン
グを行なわないという。

【００２９】システム部１０の通知管理機能部１３は、
処理すべき情報の配達の、ユーザへの通知を管理する。
ユーザへの通知は、ユーザインターフェース部２０の通
知部２２が行なう。進捗情報管理機能部１４は、作業の
状況、作業の履歴を管理するための情報を管理する。ユ
ーザインターフェース部２０の進捗管理部２３は、この
情報を用いて作業の状況を管理する。

【００３０】ユーザ管理機能部１５は、各ステップを担
当するユーザを管理する。参照情報管理機能部１６は、
各ステップの担当者に与える、作業に必要な情報を管理
する。システム管理機能部１７は、実行中のワークフロ
ーのデータを管理するほか、システム部１０の全体を管
理する。

【００３１】この発明の一実施例の要部の説明の前に、
この例のワークフローシステムにおいて、定義されたワ
ークフローにしたがった仕事の受け渡しに関する処理の
流れについて説明する。

【００３２】図３は、この例の情報処理システムにおい
て、ワークフローの流れの管理に関する部分の機能を抽
出した機能ブロック図である。

【００３３】システム管理機能部１７は、実行フローに
関するデータを、その記憶部１７Ｍに記憶する。この実
行フローに関するデータはテーブル形式で記憶部１７Ｍ
に記憶されている。以下、この記憶部１７Ｍの実行フロ
ーに関するデータを、ワークフローテーブルと呼ぶこと
にする。

【００３４】なお、実行フローは、テンプレート管理機
能部１１にあらかじめ登録されている定義されたワーク
フローから選択することもできるし、選択したワークフ
ローを修正してシステム管理機能部１７の記憶部１７Ｍ
に登録することもできる。もちろん、初めから実行フロ
ーをすべて作成して定義し、記憶部１７Ｍに登録するこ
ともできる。

【００３５】ワークフローは、図４に示すように、作業
の単位であるステップと、各ステップ間をつなぐアーク
（矢印）とからなるグラフ構造によって表現される。複
数個のワークフローを同時に実行、管理することもでき
る。図４の例では２個のワークフローが実行される場合
として示してある。複数個のワークフローを識別するた
めに、各ワークフローにはワークフロー識別子（識別子
を以下、ＩＤという）が付与されている。

【００３６】また、図４において、四角で囲われたもの
は、各ステップを示しており、四角の中に記載された数
字は、各ステップを識別するためのステップＩＤを示し
ている。

【００３７】図５は、図４の例の場合のワークフローテ
ーブルの一例を示すものである。このワークフローテー
ブルは、横方向の各１行が１つのステップに関するデー
タとなっている。この例では、各行は、ワークフローＩ
Ｄ、ステップＩＤ、当該ステップの担当者、ステップの
状態、当該ステップの処理開始日、終了日、開始予定
日、終了予定日、親ステップＩＤ、子ステップＩＤを、
情報として有する。

【００３８】ステップの状態は、後述するように、ワー
クフローが実行されるにしたがって書き替えられる。開
始日、終了日は、当該ステップが実際に開始、終了され
た日である。開始予定日、終了予定日は、各ステップに
ついての緊急度の判定対象となる期限情報（判定対象
日）であり、後述するように、システム管理者により設
定され、実行中にも書き替え可能である。

【００３９】親ステップＩＤは、当該ステップの１つ前
のステップのＩＤである。また、子ステップＩＤは、当
該ステップの１つ後のステップのＩＤである。これによ
り、ステップの実行順序が規定される。

【００４０】ルーティング機能部１２は、この例の場
合、機能的には、ステップ状態管理部３１と、ルーティ
ング処理部３２と、パケット送受部３３とを備える。

【００４１】ルーティング処理部３２は、ワークフロー
テーブルのデータに基づき実際のルーティングの決定を
行なう。ルーティング機能部１２では、ワークフローの
各ステップの状態を、次の〜の４種の状態により管
理して、そのワークフローの流れを管理する。

【００４２】ステップがまだ作業を開始することがで
きない状態（以下、この状態を「実行待ち」という） ステップの開始準備ができており、担当者の仕事の開
始を待っている待機状態（以下、この状態を「実行可
能」という） 担当者が作業をしている実行状態（以下、この状態を
「実行中」という） 担当者が作業を終了した状態（以下、この状態を「完
了」という）。

【００４３】以上のステップの状態遷移に応じてルーテ
ィング機能部１２は、基本的には、次のような動作を行
ない、この動作が各ステップに対して繰り返されること
により、ワークフローは進行する。

【００４４】初期時には、ワークフローテーブルの各ス
テップの状態は「実行待ち」となっている。担当者によ
りワークフローの起動が行なわれると、システム管理機
能部１７の指示を受けたルーティング処理部３２により
最初のステップが次のステップとして決定される。ま
た、後述するように、前のステップが終了したとき
（「完了」の状態になったとき）に、ルーティング処理
部３２により次のステップが決定される。ワークフロー
テーブルにおいては、決定された次のステップは、ステ
ップ状態管理部３１により、その状態が「実行可能」と
される。

【００４５】また、ステップ状態管理部３１は、ステッ
プの状態が「実行待ち」から「実行可能」になるとき、
通知管理機能部１３に通知要求を出す。通知管理機能部
１３は、この通知要求に従って次ステップの担当者に対
して通知を行なって担当者の作業の開始を促す。通知管
理機能部１３は、通知内容のデータである通知テーブル
のデータを格納する記憶部１３Ｍを備えている。

【００４６】この通知に対して担当者が開始の合図をサ
ーバー側のシステム部１０に対して行なうと、この合図
を通知管理機能部１３が受け、ステップ状態管理部３１
にその旨を知らせる。ステップ状態管理部３１は、これ
に応じてワークフローテーブルの当該ステップの状態を
「実行可能」から「実行中」にする。

【００４７】そして、ステップ状態管理部３１は、パケ
ット送受部３３にパケット送信要求を出して、このパケ
ット送受部３３より、担当者が作業を行なうために必要
な文書、図面、データなどの情報をひとまとめにしたデ
ータの固まりであるパケットを、当該ステップの担当者
に対して送る。

【００４８】パケットは参照情報管理機能部１６により
管理され、参照情報管理機能部１６は、このパケットの
記憶部１６Ｍを有する。パケット送受部３３は、参照情
報管理機能部１６に管理されている情報を用いてステッ
プの担当者に送るパケットを形成する。参照情報管理機
能部１６は、ユーザから得たパケットを記憶部１６Ｍに
蓄える処理も行う。

【００４９】担当ユーザは、システム部１０から配達さ
れたパケットを元に作業を実行する。そして、指定され
た作業を終了すると、担当ユーザは、適宜、作業内容を
反映させたパケットとともに、システム部１０に対し、
終了の合図を送る。このとき、ステップ状態管理部３１
は、ワークフローテーブルの当該ステップの状態の欄を
「実行中」から「完了」とする。

【００５０】また、ステップ状態管理部３１は、ステッ
プの状態が「実行中」から「完了」になるときに、ルー
ティング処理部３２に処理要求を出す。ルーティング処
理部３２は、実際のルーティングの決定を行なう。すな
わち、次にルーティングを行なうステップを決定し、ま
た、担当ユーザを決定し、その決定したステップおよび
担当ユーザをステップ状態管理部３１に通知する。

【００５１】ステップ状態管理部３１は、ルーティング
処理部３２からの通知によりルーティングを行なうステ
ップの状態を、「実行待ち」から「実行可能」にする。
以下、上述と同様の処理を繰り返して、ワークフローを
進行させ、後続のステップがなくなるとワークフローの
処理を終了する。

【００５２】次に、この発明の要部である緊急度の伝達
に関する部分について説明する。図１は、この発明の要
部である緊急度の伝達に関する部分についての機能ブロ
ック図である。この図１の機能ブロック図においては、
サーバー側のシステム部１０の部分は、システム部４０
と表わし、また、クライアント側の各ユーザーインタ−
フェース２０の対応部分は、それぞれタスクボックス５
０と称するものとしている。

【００５３】図１において、システム部４０のワークフ
ローサービス手段４１は、システム管理機能部１７の機
能の一部であり、格納部４４（記憶部１７Ｍに対応）に
格納されているワークフローテーブルＴＷを管理すると
共に、格納部４５に格納されている、緊急度の判定の基
準となる判定基準テーブルＴＲを管理する。格納部４４
および４５は、それぞれシステム部４０のメモリに割り
当てられた所定のメモリ領域、あるいはそれぞれ単独の
メモリである。

【００５４】ワークフローテーブルＴＷのデータの例
は、前述した図５の通りである。そして、判定基準テー
ブルＴＲは、ワークフロー毎に設定された緊急度の判定
基準からなるテーブルであり、１つのワークフローにつ
いて、それぞれ複数個の判定基準を設定することが可能
である。この判定基準テーブルＴＲの判定基準の値は、
図示を省略した判定基準設定部を通じて、予めシステム
管理者により設定され、格納部４５に格納される。この
例では、判定基準は、日数で表わされ、現在の日付か
ら、緊急度の判定対象日（開始予定日あるいは終了予定
日）までの日数が、判定基準より長いか短いかにより緊
急度の高低が判定される。後述するように、この例で
は、緊急度の算出は、サーバー側から与えられる情報に
基づいてクライアント側の各タスクボックス５０で行な
う。

【００５５】図６は、判定基準テーブルＴＲの一例であ
り、これは、前述の図４に示したワークフローＩＤが
「１」と「２」の２つのワークフローに対してそれぞれ
設定されている。この例では、判定基準１のみが設定さ
れた場合を示しているが、システム管理者によっては、
判定基準として判定基準１と判定基準２との２つを設定
して運用することも可能である。なお、この場合、判定
基準１は、判定基準２に対してより高い緊急度の判定を
行なえるようにするため、（判定基準１の日数）＜（判
定基準２の日数）の関係になるようにしている。

【００５６】通知サービス手段４２は、通知管理機能部
１３の機能の一部であり、格納部４６（図１の記憶部１
３Ｍに対応）に格納される通知テーブルＴＣを管理す
る。前述したように、状態が「実行可能」になったステ
ップの担当者に対して通知が行なわれるが、このときに
各ステップの担当者に通知された情報内容が、通知テー
ブルＴＣとして保存されている。

【００５７】前述もしたように、通知サービス手段４２
は、ステップの状態が「実行可能」になったときに、ワ
ークフローテーブルＴＷを参照して、そのステップの担
当者に対して通知する通知情報を生成し、それを当該ス
テップの担当者に通知すると共に、通知テーブルＴＣ
に、通知した通知情報を登録する。

【００５８】図７は、この例の場合の通知テーブルＴＣ
の例を示すもので、各１つの行が１つの通知情報に対応
している。ステップの担当者に与えられる通知情報に
は、図７に示すように、ワークフローＩＤ、ステップＩ
Ｄ、宛名（通知の宛先である担当者名）、当該通知の送
信日、緊急度の判定対象日が含まれる。

【００５９】緊急度の判定対象日は、緊急度を算出する
ために利用される日付である。この通知テーブルＴＣの
判定対象日の欄は、システム管理者による判定対象日と
なる開始予定日あるいは終了予定日の設定入力あるいは
変更入力がされたとき、後述するように、判定対象日設
定部４３により、ワークフローテーブルＴＷの、対象と
なるステップの状態に応じて、そのステップの「開始予
定日」または「終了予定日」あるいは「なし」が記入さ
れる。すなわち、、ステップの状態が、「実行待ち」ま
たは「実行可能」であれば、開始予定日が、「実行中」
であれば、終了予定日が、「完了」であれば「なし」
が、それぞれ、判定対象日の欄に記入される。

【００６０】通知テーブルＴＣの判定対象日の欄は、ま
た、ワークフローサービス手段４１により、ワークフロ
ーの進行に応じて、ステップの状態が変化すると書き替
えられる。すなわち、ステップの状態が「実行可能」か
ら「実行中」になれば、そのステップについての判定対
象日が開始予定日から終了予定日に変更され、「実行
中」から「完了」になれば、判定対象日の欄は「なし」
と書き替えられる。

【００６１】前述したように、通知テーブルＴＣの判定
対象日は、ワークフローサービス手段４１と、通知サー
ビス手段４２との間に設けられる判定対象日設定部４３
とによりワークフローテーブルＴＷを参照して設定され
る。判定対象日設定部４３は、ワークフローテーブル変
更要求処理部４３１と、判定対象日決定部４３２とを備
える。

【００６２】そして、変更要求部４７は、システム管理
者によって、ワークフローおよびステップの指定と、そ
のステップにおける緊急度の判定対象日である開始予定
日あるいは終了予定日の変更入力（初期的な開始予定日
および終了予定日の設定入力を含む）がなされたとき、
その入力されたワークフローＩＤ、ステップＩＤ、日付
情報を含む変更要求をワークフローテーブル変更要求処
理部４３１に送る。

【００６３】ワークフローテーブル変更要求処理部４３
１は、この変更要求に応じてワークフローテーブルＴＷ
の、指定されたワークフローおよびステップの行の開始
予定日あるいは終了予定日として、システム管理者によ
り設定された日付を書き込むようにワークフローサービ
ス手段４１に依頼する。

【００６４】そして、判定対象日決定部４３２は、前述
したように、ワークフローテーブルの各ステップの状態
を参照し、通知テーブルの対応するステップの判定対象
日の欄に、ワークフローテーブル中の対応するステップ
の「開始予定日」または「終了予定日」もしくは「な
し」を書き込む。

【００６５】この判定対象日設定部４３の処理動作の流
れの例を図８のフローチャートについて説明する。

【００６６】図８のフローチャートの処理ルーチンは、
変更要求に対してシステム管理者から開始予定日あるい
は終了予定日の変更入力（初期的な設定入力を含む）が
あったときに開始する。まず、処理Ｓ１において、シス
テム管理者からの変更要求は終了予定日の変更要求があ
るか否か判断する。終了予定日の変更要求があれば、処
理Ｓ２に進んで、ワークフローテーブルＴＷにおいて、
指定されたワークフローＩＤ、ステップＩＤのステップ
の行の終了予定日の欄に入力された日付を記入する。

【００６７】処理Ｓ１で、システム管理者からの変更要
求は終了予定日の変更要求でないと判断されたときに
は、処理３に進んで、開始予定日の変更要求であるか否
か判断する。開始予定日の変更要求であれば、処理Ｓ４
に進んで、ワークフローテーブルＴＷにおいて、指定さ
れたワークフローＩＤ、ステップＩＤのステップの行の
開始予定日の欄に入力された日付を記入する。

【００６８】処理Ｓ２あるいは処理Ｓ４の次には、処理
Ｓ５に進む。処理Ｓ５では、ワークフローテーブルＴＷ
において、前記指定されたステップの状態が「実行待
ち」または「実行可能」であるか否か判断し、そうであ
れば、処理Ｓ６に進んで、通知テーブルＴＣ中の対応す
るステップの判定対象日の欄に、ワークフローテーブル
ＴＷの対応するステップの開始予定日の日付を設定す
る。

【００６９】処理Ｓ５で、指定されたステップの状態が
「実行待ち」または「実行可能」でないと判断したとき
には、処理Ｓ７に進み、指定されたステップの状態は
「実行中」であるか否か判断する。実行中であれば、処
理Ｓ８に進んで、通知テーブルＴＣ中の対応するステッ
プの判定対象日の欄に、ワークフローテーブルＴＷの対
応するステップの終了予定日の日付を設定する。実行中
でなければ、処理Ｓ９に進んで、通知テーブルＴＣ中の
対応するステップの判定対象日の欄に、「なし」を設定
する。以上で、この処理ルーチンは終了となる。

【００７０】通知サービス手段４２は、また、クライア
ント側であるタスクボックスからの緊急度の判定のため
の情報の転送要求を受信する。この例では、この転送要
求は、タスクボックスから所定の周期、例えば３時間ご
とや１日ごとに、繰り返し送られてくるもので、担当者
名の情報が含まれている。

【００７１】この転送要求は、宛名が、この転送要求に
含まれる担当者名と一致する通知テーブルの通知のワー
クフローＩＤ、ステップＩＤ、送信日、判断対象日と、
そのワークフローＩＤのワークフローについての判断基
準、そのステップＩＤのステップの状態の情報の取得を
要求するものである。

【００７２】通知サービス手段４２は、受け取った転送
要求をワークフローサービス手段４１に送る。ワークフ
ローサービス手段４１は、これを受けると、図９のフロ
ーチャートに示すような処理の流れで、要求を出したタ
スクボックスの担当者に送る情報を生成し、それを送出
する。この例では、要求を出したタスクボックスの担当
者に送る情報は、一時テーブルと呼ばれるテーブル情報
の形式でワークフローサービスにより作成されるもので
ある。

【００７３】すなわち、まず、ワークフローサービス手
段４１は、処理Ｓ１１で通知サービス手段４２から転送
要求を受けると、処理Ｓ１２に進んで、通知サービス手
段４２に対して、通知テーブルＴＣ中の担当者名が一致
する通知（行）があるか否かの検索要求を出す。

【００７４】この検索要求に対して、通知サービス手段
４２では、通知テーブルＴＣ中に担当者名が一致する通
知があるか否かの検索を実行して、その結果をワークフ
ローサービス手段４１に通知するので、処理Ｓ１３で、
この検索結果を受けて、担当者名と一致する通知がある
か否か判断し、なければこの処理ルーチンを終了し、あ
れば処理Ｓ１４に進む。

【００７５】通知サービス手段４２では、前記検索の結
果、通知テーブルＴＣ中に担当者名が一致する通知
（行）があれば、その行のワークフローＩＤ、ステップ
ＩＤ、送信日、判断対象日をワークフローサービス手段
４２に通知するので、ワークフローサービス手段４１で
は、処理Ｓ１４で、これらを取得する。そして、次の処
理Ｓ１５において、取得したワークフローＩＤ、ステッ
プＩＤ、送信日、判断対象日を一時テーブルＴＢに格納
する。

【００７６】次に、処理Ｓ１６に進んで、ワークフロー
テーブルＴＷ中から、処理Ｓ１５で一次テーブルＴＢに
格納したワークフローＩＤ、ステップＩＤと一致するス
テップの状態を取得し、処理Ｓ１７において、それを一
時テーブルＴＢに格納する。次に、処理Ｓ１８に進み、
判断基準テーブルＴＲから、処理Ｓ１５で一時テーブル
ＴＢに格納したワークフローＩＤと一致する判断基準を
取得し、それを処理Ｓ１９で一時テーブルＴＢに格納す
る。

【００７７】以上で、一時テーブルＴＢは完成となる。
そして、処理Ｓ２０において、その完成した一時テーブ
ルＴＢを、要求を出したタスクボックスの担当者宛てに
送出する。

【００７８】図１０は、ワークフローテーブルＴＢが図
５に示したような内容であり、通知テーブルＴＣが図７
に示したような内容であるときに、担当者名「Ｓｔｅｖ
ｅ」が、転送要求を出した場合の一時テーブルＴＢの例
を示すものである。

【００７９】この場合、処理１３で一時テーブルに格納
された判定対象日は、前述したように、前回の転送要求
から今回の転送要求の間に、システム管理者により開始
予定日や終了予定日が変更されたときには、その変更さ
れた日付となっている。後述するように、タスクボック
スは、取得した一時テーブルの情報を用いて緊急度の算
出を行なうが、以上のように、判定対象日がシステム管
理者により変えられたときには、その変更された日付を
タイムリーに取得することができるので、常に、状況変
化に応じた緊急度を得ることができるようになる。

【００８０】次に、タスクボックス側について説明す
る。図１に示すように、各タスクボックス５０は、同様
の構成をするものであるので、タスクボックス全体の制
御を行なうための制御部５１と、一定周期で転送要求を
発生する転送要求発生部５２と、判定基準設定部５３
と、判定基準テーブルを格納する格納部５４と、後述す
るタスクオーダーテーブルを格納する格納部５５と、タ
スクオーダー表示制御部５６とを備える。

【００８１】転送要求発生部５２は、当該タスクボック
ス５０の担当者名の情報を含む転送要求を、前述したよ
うに一定周期で自動的に発生し、この転送要求をサーバ
ー側のシステム部４０に送る。この転送要求に対して、
前述したようにして、システム部４０では、転送要求に
含まれる担当者が担当するステップについての一時テー
ブルＴＢを作成し、その担当者名を宛名として、当該作
成した一時テーブルＴＢをタスクボックス５０に送り返
してくる。そこで、タスクボックス５０では、その担当
者名を宛名とする一時テーブルを制御部５１を介してタ
スクオーダー表示制御部５６で受け取り、タスクオーダ
ー表示制御部５６の管理化の図示しない一時格納部に格
納する。

【００８２】そして、タスクボックス５０のタスクオー
ダー表示制御部５６では、受け取った一時テーブルＴＢ
の各１行のワークフローＩＤ、ステップＩＤ、送信日、
状態の情報を、１つのタスクオーダーを構成するための
要素として、タスクオーダーＩＤという識別子を割り当
て、それをタスクオーダーテーブルとして制御部５１を
介して格納部５５に格納する。

【００８３】図１１は、図１０の一時テーブルＴＢに基
づいて作成されたタスクオーダーテーブルの例である。
この図１１に示されるように、各１行のタスクオーダー
には、上記の情報のほかに緊急度の項目が設けられる。
一時テーブルＴＢを受け取ってタスクオーダーテーブル
を作成した時点では、タスクオーダーテーブル中のこの
緊急度の項目は埋まっていない。

【００８４】そして、この例の場合には、ステップ担当
者が、自己の能力や都合に応じた緊急度を取得すること
ができるように、タスクボックス５０側にも判定基準テ
ーブルが格納部５２に格納されている。このタスクボッ
クス５０側の判定基準は、判定基準設定部５３から担当
ユーザーが設定する。この例においては、このタスクボ
ックス５０側の判定基準は、サーバー側から送られてく
る一時テーブルＴＢ中の判定基準に優先して用いられる
ようにされている。

【００８５】図１２は、制御部５１を介して実行される
この判定基準の設定に関する流れ図である。すなわち、
まず、処理Ｓ２１で、判定基準設定部５３で担当ユーザ
ーによる判定基準の設定入力（設定要求）があったか否
かを判断し、設定入力がなければ判定基準設定のこのル
ーチンを終了し、設定入力があれば、処理Ｓ２２で、入
力された各ワークフローについての判定基準を格納部５
４の判定基準テーブルに登録して、このルーチンを終了
する。図１３は、担当ユーザーにより設定された判定基
準の判定基準テーブルの例である。

【００８６】この例では、上記のように、タスクボック
ス５０側で、担当者により緊急度の判断基準が別に定め
られている場合には、その担当者により設定された緊急
度を優先するように一時テーブルＴＢを書き替えて、更
新一時テーブルｔｂを生成して前記一時格納部に格納す
るようにする。この処理も、タスクオーダー表示制御部
５６が行なう。

【００８７】図１４は、タスクボックス側で作り直され
た更新一時テーブルｔｂの例である。この例では、担当
ユーザーにより、タスクボックス側の判定基準として、
ワークフローＩＤが「１」および「２」のワークフロー
について、図１３に示すように設定されているので、一
時テーブルＴＢの判定基準の項目は、格納部５４の判定
基準テーブルの判定基準１および判定基準２が上書きさ
れて更新され、タスクボックス５０側の判定基準が、サ
ーバー側の判定基準に優先するようにされている。

【００８８】タスクオーダー表示制御部５６は、更新さ
れた一時テーブルｔｂの判定対象日および判定基準の項
目と、現在の日付とから緊急度の算出を行ない、算出し
た緊急度の重要度、この例では「高」「中」「低」の判
定を行ない、その判定結果荷応じて、タスクボックス５
０に設けられているディスプレイに表示する。なお、こ
のタスクボックス５０のディスプレイは、各担当者がそ
れぞれのステップの作業を実行するときに、キーボード
やマウスなどの入力操作手段と協働して、ステップの作
業環境を提供するものである。

【００８９】図１５は、タスクオーダー表示制御部５６
の機能ブロック図の例を示すものである。すなわち、タ
スクオーダー表示制御部５６は、タスクオーダー取得部
５６１と、緊急度算出部５６２と、緊急度判定部５６３
と、通常表示処理部５６４と、特殊表示処理部５６５と
からなる。

【００９０】このタスクオーダー表示制御部５６の制御
処理の流れを図１６および図１７のフローチャートを参
照しながら説明する。

【００９１】まず、処理Ｓ３１において、サーバー側か
らの一時テーブルＴＢを取得する。次に処理Ｓ３２にお
いて、取得した一時テーブルＴＢの各行にタスクオーダ
ーＩＤを「１」から昇順に割り当てる。次に、処理Ｓ３
３で、タスクオーダーＩＤと、それに対応する一時テー
ブルＴＢのワークフローＩＤ、ステップＩＤ、送信日、
状態の項目を、昇順に割り当てたタスクオーダーについ
て、順次にタスクオーダーテーブルに書き込む。

【００９２】次に、処理Ｓ３４に進んで、緊急度の算出
を行なう。この緊急度の算出処理の流れは、この例では
図１７のフローチャートに示すものとされている。

【００９３】すなわち、図１７に示すように、まず、処
理Ｓ４１において、格納部５４の判定基準テーブルにタ
スクボックス側の判定基準データが設定されているか否
か判断する。設定されているときには、処理Ｓ４２に進
んで、サーバー側からの一時テーブルＴＢの判定基準の
項目について、タスクボックス側の判断基準を上書きし
て更新一時テーブルｔｂとした後、処理Ｓ４３に進む。
タスクボックス側の判定基準が設定されていなければ、
処理Ｓ４１から処理Ｓ４３にそのまま進む。

【００９４】処理Ｓ４３では、処理Ｓ３３で格納部５５
に格納されたタスクオーダーテーブル中で、緊急度が未
設定の行があるか否か判断する。未設定のものがなけれ
ば、緊急度算出のこのルーチンを終了して、図１６のフ
ローチャートの処理Ｓ３５に進む。

【００９５】処理Ｓ４３で緊急度が未設定の行があれ
ば、処理Ｓ４４に進んで、一時テーブルＴＢあるいは更
新一時テーブルｔｂの行のうちの、緊急度が未設定の行
のワークフローＩＤ、ステップＩＤと一致する行の判定
対象日と、判定基準を抽出すると共に、図示しないカレ
ンダー部から現在の日付情報を得る。そして、処理Ｓ４
５に進んで、現在の日付から、判定対象日までの日数
が、判定基準１が示す日数以内となったか否か判断し、
そうであれば、処理Ｓ４６に進んで、タスクオーダーテ
ーブルの対応するステップＩＤの行の緊急度の項目に
「高」を設定する。

【００９６】処理４６で、現在の日付から、判定対象日
までの日数が、判定基準１が示す日数以内でないと判断
したときには、処理Ｓ４７に進んで、判断基準２が設定
されているか否か判断し、判断基準２が設定されていな
ければ、処理Ｓ５０に進んで、タスクオーダーテーブル
の対応するステップＩＤの行の緊急度の項目に「低」を
設定する。

【００９７】処理Ｓ４７で、判断基準２が設定されてい
ると判断されたときには処理Ｓ４８に進み、現在の日付
から、判定対象日までの日数が、判定基準２が示す日数
以内であるか否か判断し、以内であれば処理Ｓ４９に進
み、タスクオーダーテーブルの対応するステップＩＤの
行の緊急度の項目に「中」を設定する。また、処理Ｓ４
８で、現在の日付から、判定対象日までの日数が、判定
基準２が示す日数以内でないと判断されたときには、処
理Ｓ５０に進み、タスクオーダーテーブルの対応するス
テップＩＤの行の緊急度の項目に「低」を設定する。な
お、ステップの状態が完了であるときには、一時テーブ
ルの判定対象日の項目は「なし」とされているが、この
ステップに対しては、緊急度は「低」に設定される。

【００９８】そして、処理Ｓ４６、Ｓ４９、Ｓ５０の後
は、処理Ｓ４３に戻り、タスクオーダーテーブル中に緊
急度の項目が未設定の行がなくなるまで、処理Ｓ４４以
下の処理を繰り返す。そして、タスクオーダーテーブル
中に緊急度の項目が未設定の行がなくなると、この緊急
度算出のルーチンを終了して、図１６の処理３５に進
む。

【００９９】処理Ｓ３５では、タスクオーダーテーブル
中に未表示のタスクオーダーがあるか否か、つまりすべ
てのタスクオーダーの表示を完了したか否か判断する。
未表示のタスクオーダー（１行）があれば処理Ｓ３６に
進み、その未表示のタスクオーダーを選択して、次の処
理Ｓ３７で、そのタスクオーダーの緊急度の「高」
「中」「低」の設定値に応じたパターンで、そのタスク
オーダーの行の表示を行なう。なお、この例では、タス
クオーダーテーブルの緊急度の項目を除く項目が、表示
される。緊急度の項目は、表示パターンに反映されるか
らである。この処理３７の次には、処理Ｓ３５に戻る。
そして、すべてのタスクオーダーについての表示処理を
行なうと、このルーチンを終了する。

【０１００】この例では、緊急度の「高」「中」「低」
の設定値に応じた表示パターンの例として、タスクオー
ダーの各行の背景パターンを変える方式が採用されてい
る。すなわち、この例では、タスクオーダー表示制御部
５６では、緊急度が「低」のときには、通常表示処理部
５６４がその表示を担当し、その行の背景には何等の装
飾は施されない。一方、緊急度が「中」あるいは「高」
であるときには、特殊表示処理部５６５がその表示を担
当し、その行の背景を、「中」と「高」とで区別できる
態様で表示を行なう。

【０１０１】なお、緊急度の重要度の区別のための表示
方法としては、この例のように、各行の背景を変える方
法に限らず、緊急度に応じたマークをタスクオーダーの
各行に付与する方法、緊急度の項の「高」「中」「低」
をそのまま文字表示すると共に、その緊急度の項のみの
表示について、「高」「中」「低」について表示を変え
る方法、また、カラーディスプレイであれば、緊急度に
応じてタスクオーダーの行の表示色を変えるようにする
方法など、その他種々の方法が採用可能である。

【０１０２】次に具体例を上げる。今、現在の日付が２
月１日であるときに、図１４の担当者「Ｓｔｅｖｅ」に
ついての一時テーブルｔｂに基づいてタスクオーダー表
示制御部５６で緊急度の算出がなされると、図１１に示
されるように、ワークフローＩＤ「１」のステップＩＤ
「１２」のステップの緊急度は「低」、ワークフローＩ
Ｄ「１」のステップＩＤ「１３」のステップの緊急度は
「低」、ワークフローＩＤ「２」のステップＩＤ「２
１」のステップの緊急度は「高」となる。

【０１０３】このタスクオーダーテーブルのデータを元
に、タスクオーダー表示制御部５６では、緊急度の項目
を除く項目について、タスクオーダーテーブルの各行の
表示を行なうが、前述したように、緊急度の項目の
「高」「中」「低」の設定値に応じたパターンでその表
示を行なう。図１８Ａは、このときのタスクボックス５
０のディスプレイの表示例を示している。図１８Ａで
は、タスクオーダーＩＤ「３」、ワークフローＩＤ
「２」、ステップＩＤ「２１」のタスクオーダーの行の
背景が、その緊急度「高」に対応したものとなってい
る。

【０１０４】なお、このタスクオーダーテーブルは、デ
ィスプレイ画面の担当ユーザーの作業環境中に、１つの
ウインドウとして表示される。そして、図１８に示され
ているように、このタスクオーダーテーブルのウインド
ウ表示を閉じる（表示消去）するために、ディスプレイ
画面には、「閉じる」のボタン（例えばボタンアイコ
ン）が表示されている。

【０１０５】転送要求がタスクボックスから発生する毎
に、以上の緊急度の算出およびタスクオーダーテーブル
の表示が行なわれる。したがって、現在の日付が判定対
象日に近付くにしたがって各タスクオーダーの緊急度は
変更されることになり、時間の経過に応じた緊急度を、
ステップの担当者は知ることができる。

【０１０６】次に、同じ担当者名「Ｓｔｅｖｅ」からの
転送要求が２月３日にあった場合において、その前日の
２月２日に、システム管理者により、担当者名「Ｓｔｅ
ｖｅ」が担当すべきステップＩＤ「１３」の終了予定日
が２月１４日から２月７日に変更されている場合につい
て説明する。

【０１０７】このとき、２月２日になされたシステム管
理者による終了予定日の変更要求が判定対象日設定部４
３で処理され、前述したようにして、格納部４４のワー
クフローテーブルＴＷは、図１９に示すように、図５に
示したものから、ステップＩＤ「１３」の終了予定日が
２月７日に変更されたものとなる。

【０１０８】そして、判定対象日設定部４３は、このワ
ークフローテーブルＴＷを参照して、ステップＩＤ「１
３」のステップの状態が「実行中」であることから、図
２０に示すように、通知テーブルＴＣの判定対象日に、
新たな終了予定日２月７日を設定し直す。

【０１０９】そして、２月３日に、担当者名「Ｓｔｅｖ
ｅ」として、タスクボックスから転送要求が到来する
と、システム部４０では、図２１Ａに示すような一時テ
ーブルＴＢが作成され、タスクボックス側に送られる。
担当者名「Ｓｔｅｖｅ」のタスクボックスでは、この一
時テーブルＴＢを受信して、タスクオーダーテーブルが
作成され、図２１Ｂに示すような更新一時テーブルｔｂ
が作成されることになる。

【０１１０】そして、図２１Ｂの更新一時テーブルｔｂ
に基づいて緊急度の算出が行なわれる。このときには、
終了予定日の２月７日が判定対象日であって、現在の日
付が２月３日であるので、現在の日付から判定対象日ま
での日数は、４日であり、これは判定基準１（＝３）よ
り大きく、判定基準２（＝７）以内である。したがっ
て、図２２に示すように、タスクオーダーＩＤ「１」お
よび「３」については、図１１のタスクオーダーテーブ
ルと変わらないが、タスクオーダーＩＤ「２」のステッ
プＩＤ「１３」のステップのタスクオーダーの緊急度
は、「低」から「中」に変化する。

【０１１１】そして、このタスクオーダーテーブルがタ
スクボックスのディスプレイに表示されると、図１８Ｂ
に示すようなものとなり、タスクオーダーＩＤ「２」の
行が、緊急度「中」に応じた背景表示パターンに変わ
る。これにより、担当ユーザーは、緊急度が変化したこ
とを認識できる。

【０１１２】こうして、システム管理者により、開始予
定日や終了予定日が変更されるなどという、状況の変化
に対応した緊急度の伝達が可能になる。

【０１１３】以上の実施例においては、システム管理者
や担当ユーザーは、判定基準をワークフロー毎に設定で
きるので、ワークフロー毎に異なる判定基準を持たせる
ことができる。しかも、担当ユーザーが判定基準を自分
の好みに合わせて設定することができるので、担当ユー
ザーの能力や好みに合わせて緊急度に対する定義を実現
することができる。

【０１１４】次に、この発明の他の実施例について説明
する。

【０１１５】以上の実施例では、一定周期でタスクボッ
クスから転送要求が発生するように構成されているが、
この転送要求に加えて、あるいはこの転送要求に代え
て、担当者が適宜要求を任意に出すようにしてもよい。
この場合に、担当者が要求を出す場合でも、一時格納部
に格納した一時テーブルを用いて、１日毎などのように
一定周期で緊急度を算出して、タスクオーダーテーブル
に反映させ、それをディスプレイに表示するようにする
とよい。

【０１１６】また、緊急度の算出をサーバー側で行なっ
て、その緊急度の情報をクライアント側に送るようにし
てもよい。その場合には、クライアント側では、緊急度
の算出部を設けなくともよくなり、サーバー側からクラ
イアント側に送る情報としては、判定基準の情報や判定
対象日の情報は含めなくてよくなる。この場合には、ク
ライアント側からの転送要求により、前記緊急度を含む
情報を、その要求したクライアント側の担当ユーザーに
対して、サーバー側が送るようにしてもよいし、サーバ
ー側が適宜、クライアント側の担当ユーザーを指定し
て、緊急度を含む情報を送るようにしてもよい。この場
合にも、クライアント側で設定した判定基準をサーバー
側に送っておくことにより、サーバー側において、クラ
イアント側の担当ユーザーが設定した判定基準を優先し
て緊急度を求めることも可能である。そして、このクラ
イアント側の担当ユーザーが設定した判定基準は、クラ
イアント側から転送要求を出す方式の場合には、その転
送要求に含めてサーバー側に送ることができる。

【０１１７】また、次のような実施例も可能である。す
なわち、サーバー側と、クライアント側の双方が判定基
準テーブルを備えるが、サーバー側は、クライアントの
転送要求により、緊急度を含む情報をクライアント側に
送るときに、必ず緊急度を算出して送るようにする。そ
して、クライアント側は、受け取った緊急度の情報が示
されるステップが、その判定基準テーブルに判定基準が
登録されているワークフローＩＤ内のステップである場
合には、サーバー側で求めた緊急度に代えて、クライア
ント側の判定基準に基づいて求めた緊急度を採用して、
それを表示するようにする。この例の場合には、サーバ
ー側で緊急度を求めるものであっても、判定対象日の情
報はクライアント側に送る必要がある。

【０１１８】また、ワークフローシステムは、ホスト装
置と端末装置とで構成し、サーバー側の機能と、クライ
アント側の機能の殆どとを、ホスト装置にて実現するよ
うにすることもできる。

【０１１９】さらに、上述の説明では、予め、判定対象
日である開始期限の情報（例えば開始予定日）または終
了期限の情報（例えば終了予定日）を設定するようにし
たが、緊急度を求める際に、ステップの状態を参照し
て、緊急度を求める対象日が開始期限か、終了期限かを
判定して、いずれかを選択し、その選択した対象日につ
いて緊急度を求めるようにすることもできる。

【０１２０】

【発明の効果】以上説明したように、この発明によれ
ば、要求が発生する毎に緊急度の算出を行なうようにし
ているので、時間の経過に伴った緊急度の変換を確実に
知ることができる。また、ある要求と次の要求との間に
おいて、緊急度を算出する基礎となる期限情報を変更し
たときには、前記次の要求の発生時点で、変更された期
限情報に基づいて緊急度が算出されるので、状況変化に
対応した緊急度を知ることができる。

【図面の簡単な説明】

【図１】この発明による情報処理システムの一実施例の
要部の機能ブロック図である。

【図２】この発明による情報処理システムの一実施例の
全体の概要の機能ブロック図である。

【図３】この発明による情報処理システムの一実施例の
動作の概要を説明するための機能ブロック図である。

【図４】ワークフローの一例を示す図である。

【図５】この発明による情報処理システムの一実施例の
説明に用いるデータテーブルの例を示す図である。

【図６】この発明による情報処理システムの一実施例の
説明に用いるデータテーブルの例を示す図である。

【図７】この発明による情報処理システムの一実施例の
説明に用いるデータテーブルの例を示す図である。

【図８】この発明による情報処理システムの一実施例の
動作の一部の説明に用いるフローチャートである。

【図９】この発明による情報処理システムの一実施例の
動作の一部の説明に用いるフローチャートである。

【図１０】この発明による情報処理システムの一実施例
の説明に用いるデータテーブルの例を示す図である。

【図１１】この発明による情報処理システムの一実施例
の説明に用いるデータテーブルの例を示す図である。

【図１２】この発明による情報処理システムの一実施例
の動作の一部の説明に用いるフローチャートである。

【図１３】この発明による情報処理システムの一実施例
の説明に用いるデータテーブルの例を示す図である。

【図１４】この発明による情報処理システムの一実施例
の説明に用いるデータテーブルの例を示す図である。

【図１５】この発明による情報処理システムの一実施例
の一部の機能ブロック図である。

【図１６】この発明による情報処理システムの一実施例
の動作の一部の説明に用いるフローチャートである。

【図１７】この発明による情報処理システムの一実施例
の動作の一部の説明に用いるフローチャートである。

【図１８】この発明による情報処理システムの一実施例
における緊急度の表示例を説明するための図である。

【図１９】この発明による情報処理システムの一実施例
の説明に用いるデータテーブルの例を示す図である。

【図２０】この発明による情報処理システムの一実施例
の説明に用いるデータテーブルの例を示す図である。

【図２１】この発明による情報処理システムの一実施例
の説明に用いるデータテーブルの例を示す図である。

【図２２】この発明による情報処理システムの一実施例
の説明に用いるデータテーブルの例を示す図である。

【符号の説明】

１０、４０ システム部 ２０ ユーザーインタ−フェース部 ４１ ワークフローサービス手段 ４２ 通知サービス手段 ４３ 判定対象日設定手段 ４４ ワークフローテーブルの格納部 ４５ 判定基準テーブルの格納部 ４６ 通知テーブルの格納部 ４７ 変更要求手段 ５０ タスクボックス ５２ 転送要求発生部 ５３ 判定基準設定部 ５４ 判定基準テーブルの格納部 ５５ タスクオーダーテーブルの格納部 ５６ タスクオーダー表示制御部 ＴＷ ワークフローテーブル ＴＲ 判定基準テーブル（サーバー側） ＴＣ 通知テーブル ＴＢ 一時テーブル（サーバー側） ｔｂ 更新一時テーブル（クライアント側） ＴＯ タスクオーダーテーブル

Claims (1)

【特許請求の範囲】
1. 【請求項１】順序立てて処理すべき作業を、複数個の作
   業工程に分け、その複数個の作業工程の順序と、各作業
   工程の処理内容と、各作業工程の担当者とを定めて、前
   記作業を支援する情報処理システムにおいて、 前記作業工程のそれぞれを一意に識別するための作業工
   程識別情報と、前記作業工程で行なう処理に関する期限
   についての期限情報と、各作業工程の処理を実行すべき
   担当者を識別するための担当者識別情報とを当該作業工
   程に対応させて保持する第１の保持手段と、 前記第１の保持手段に保持された期限情報を変更するた
   めの変更手段と、 前記作業工程での処理に関する緊急度を求めるための判
   定基準を保持する第２の保持手段と、 前記第２の保持手段に保持された判定基準と、前記担当
   者が処理すべき作業工程の前記期限情報と、現在の暦情
   報とに基づき当該作業工程の緊急度を求める緊急度判定
   手段と、 前記担当者を特定して当該担当者が処理すべき作業工程
   に関する前記緊急度を含む情報の作成を要求する要求手
   段と、 前記要求手段からの要求に応じて、前記作業工程識別情
   報と、前記期限情報と、前記緊急度判定手段により求め
   られた緊急度とを含む情報の一覧を、前記特定された担
   当者に付き作成する一覧作成手段と、 前記一覧作成手段により作成された前記情報の一覧を前
   記特定された担当者に対して可視化出力する出力手段と
   を備えることを特徴とする情報処理システム。