(57)【要約】【課題】  ワークフローシステムにおいて、承認者の不在による案件の滞留、遅延を防止する。【解決手段】  審査・承認等の処理依頼を検知したことに対し、１０８人事テーブル、１０９予定テーブルに基づき、処理担当者の在席・不在を検索し、不在の場合は、１０７代理処理テーブルより、有効期限内の代理処理担当者を検索する。当該処理の処理期限を１０５文書テーブルの過去平均時間、処理担当者の在席している時間もしくは、在席となる時間、最終ノードの処理期限から逆算して求めたノード期限から処理期限を設定する。処理依頼をされている案件が処理期限を超過しても処理担当のＰＣから承認もしくは、却下処理通知を受け取っていない場合、再度処理担当者を検索し、検索結果の処理担当者の処理ＰＣに処理依頼を送信する。【選択図】  図１
2006079381.tif 000002
【特許請求の範囲】
【請求項１】
案件処理をするワークフローにおいて、審査・承認等の処理依頼を受付ける手段と、前記案件の処理担当者の不在/在席を検索する手段と、不在の場合は、代理処理テーブルを参照し、有効期限内の各々の代理処理担当者を検索する手段と、前記案件のノード毎の処理期限を決める手段と、前記処理担当者のＰＣ(パーソナルコンピュータ)もしくは、代理処理担当者のＰＣに案件を送信する手段と、前記案件のノードの処理期限が超過した場合、代理処理担当者を再検索し、検索された代理処理担当者に案件を送信する手段を有することを特徴とするワークフローシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、作成、審査、承認等の稟議処理を行うためのワークフローシステムに関し、最適な処理担当者を検索する機能を備えたワークフローシステムに関するものである。
【背景技術】
【０００２】
文書の審査、承認を行うためのワークフローシステムに関わり、例えば、特開２００１―３４４３９２号公報記載のように審査、承認等の処理を行う担当者が在席しているかどうか、行動予定表から確認し、当該担当者が不在の場合は、代行可能な処理権限を有する担当者を確認し、在席していれば代行担当者に書類を回付するワークフローシステムが知られている。
【０００３】
【特許文献１】特開２００１−３４４３９２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のワークフローシステムでは、処理担当者の在席状況を確認し書類を送るというシステムであったが、一度書類が回付された後は処理担当者が、審査、承認等の処理を行ったかどうか確認することはなく、処理前に処理担当者が不在になってしまうことがあった。
【０００５】
本発明の目的は、処理担当者の在席期間、過去の平均処理期間、最終処理期限から逆算した当該処理の処理期間から当該処理の処理有効期限を定め、これを超過した場合には代行担当者を自動で探し処理担当者を変更することにより、処理の滞留、遅延を防止することである。
【課題を解決するための手段】
【０００６】
案件処理をするワークフローにおいて、審査・承認等の依頼を受付ける手段と、前記案件の処理担当者の不在/在席を検索する手段と、不在の場合は、代理処理テーブルを参照し、有効期限内の各々の代理処理担当者を検索する手段と、前記案件のノード毎の処理期限を決める手段と、前記処理担当者のＰＣもしくは、代理処理担当者のＰＣに案件を送信する手段と、前記案件のノードの処理期限が超過した場合、代理処理担当者を再検索し、検索された代理処理担当者に案件を送信する手段を有するワークフローシステムにより、一度書類が回付された後に処理担当者が不在となっても処理の滞留、遅延を防止する。
【発明の効果】
【０００７】
一度案件を送付した後でも有効期限を超過した場合、処理担当者の変更を自動で行うことで、案件の遅延・滞留を防止することができるようになる。また、期限に遅れそうな場合は、申請者に目安の処理時間を通知することで、次の行動を取り易くさせることが可能となる。
【発明を実施するための最良の形態】
【０００８】
本発明の1実施形態を図面を用いて詳細に説明する。図１は本発明のシステム構成例を示す図である。図１において１０１はサーバであり、１０２，１０３，１０４，１０５，１０６，１０７，１０８及び１０９を持っている。１０２は文書管理部であり、文書の処理依頼の受付け、承認・却下処理、文書管理を行う。１０３は、時間管理部であり、処理期限を過ぎた文書の存在監視を行う。１０４は処理担当者決定部であり、文書の処理依頼を受付けた後、処理担当者の在席状況を確認し最適な処理担当者を検索する。１０２文書管理部、１０３時間管理部、１０４処理担当者決定部の詳細は、図１０、図１１、図１２、図１３、図１４のフローで示す。１０５は文書テーブル、１０６は代理処理テーブル、１０７は処理テーブル、１０８は人事テーブル、１０９は予定テーブルである。サーバ１０１はＬＡＮ１１０を介して作成ＰＣ１１１、処理ＰＣ１１２と接続されている。文書作成者は作成ＰＣ１１１で文書を作成し、サーバ１０１に対して処理依頼を行う。文書処理担当者は処理ＰＣからサーバにアクセスし、文書の処理を行う。
【０００９】
図２は文書テーブルの例である。このテーブルは、文書作成ＰＣから文書の処理依頼を受付けた時にデータが設定される。テーブルの属性として、文書毎にユニークに割当てられる文書ＩＤ、文書作成者の氏名を表す作成者、文書作成者が処理依頼したときに入力した処理期限を表す最終処理期限、文書種別を表す文書カテゴリを持っている。なお、作成者の氏名や文書カテゴリの名前は、ユニークに特定できればよく、コードやＩＤでもよい。
【００１０】
図３は処理テーブルの例である。このテーブルは、文書ＩＤとワークフローにおける審査、承認、合議などの各ノードを表すノードをキーとして、指定処理担当者、処理担当者、処理依頼時間、処理期限、処理時間、状態フラグを持つ。文書ＩＤ、ノード、文書作成ＰＣより指定された処理担当者を表す指定処理担当者は、文書が処理依頼されたとき、図１における文書管理部１０２により設定される。処理担当者、処理依頼時間、ノード毎の処理期限を表す処理期限、実際の処理時間を表す処理時間は、図１における代理処理担当者決定部１０４により設定される。文書の状態を表す状態フラグは、文書の処理依頼がされたとき、図１における文書管理部１０２により初期値「待ち」が設定され、文書が処理されたときに「承認」、却下されたときに「却下」が設定される。
【００１１】
図４は代理処理テーブルの例である。このテーブルは、氏名、その人の代理処理担当者の氏名である代理処理担当者、その代理処理担当者が有効である期間の開始時間を表す有効期限開始及び代理処理担当者が有効である期間の終了時間を表す有効期限終了を持つ。
【００１２】
図５は文書カテゴリテーブルの例である。「勤休登録」、「旅費生産」など文書種別ごとに１レコードが設定される。テーブルは、文書カテゴリ、代理処理担当者の最高職位、処理ノード数、過去の１ノード当たりの平均処理時間を表す平均処理時間、平均処理時間を計算した母数を表す母数を持つ。
【００１３】
図６は人事テーブルの例である。テーブルは、氏名、部門、職位をもつ。なお、部門や職位についても、氏名と同じく、ユニークに特定できればよく、コードやＩＤを設定してもよい。
【００１４】
図７、図８、図９は、予定テーブルの例である。各人の予定が日付と時刻で登録される。予定には内容及び不在か在席かを示す値が登録される。なお、空白は、在席していることを示す。
【００１５】
図１０は、作成された文書を受付け、処理担当者のＰＣに処理依頼通知をするフローチャートである。２０１の処理で処理依頼を受付ける。このとき文書作成ＰＣより全ノードの指定処理担当者と文書の最終処理期限を受け取る。次に処理２０２で処理担当者の初期値を指定処理担当者にし、処理２０３で最適な処理担当者を検索し、処理依頼の通知をする。この処理の詳細は、図１１に示す。
【００１６】
図１１は、処理依頼を受付けた後、処理担当者を検索するフローチャートである。３０２の処理で予定テーブルから次ノードの処理担当者のスケジュールを検索する。ここで処理担当者の初期値は、指定処理担当者である。
【００１７】
例えば、図２の文書ＩＤ００１についてみると、最終処理期限は２００４年５月３１日１３：００であり、図３より指定処理担当者は山田となる。
【００１８】
現在の時間、処理担当者が在席しているかどうか３０３で判定し、在席していれば、３０４の処理で対象としている処理担当者を処理担当者と確定する。同時に確定した処理担当者が在席している時間を記録する。ただし、在席している時間の最大値は1週間後というように決めておき、在席時間を確定できるようにしておく。３０５の処理で確定した処理担当者と初期値の処理担当者が異なる場合は、代理処理テーブルへ登録する。こうすることで、次回からの処理担当者決定処理を行わず、代理処理テーブルを参照するだけで代理の処理担当者を決定することができ、処理担当者の決定処理にかかる時間を短縮することができるようになる。処理担当者が在席していた場合のこの後の処理は、図１２で示す。３０３の判定で、処理担当者が不在の場合は、３０６の処理で予定テーブルを参照し、その処理担当者が在席となる時間を不在時間として記録しておく。ただし、最初の一人目の処理担当者が不在で２人目以降の処理担当者を対象としており、すでに不在時間が記録されている場合は、記録されている時間と対象としている処理担当者が在席となる時間を比較し、小さい方にする。こうすることで、候補となる処理担当者が誰も在席していない場合、候補となる処理担当者が在席となる最小の時間が記録されることになる。次に３０７で代理処理テーブルを参照し、有効なレコードがあるかどうか調べる。有効なレコードがあった場合は、代理処理テーブルの代理処理担当者を確定処理担当者とする。同時に、代理処理テーブルの有効期限を在席時間として記録しておく。この後の処理は、図１２で示す。３０７の判定で有効なレコードがなかった場合は、人事テーブルを参照し、代理処理担当者を探す。優先度は、同一部門の同一職位、上司、以下図５文書カテゴリテーブルの代理処理担当者最高職位まで探す。なお、同一部門の同一職位の人を調べる場合は、氏名順で初期値の処理担当者に一巡するまで探すというようにしておく。３０９の処理で代理処理担当者がみつかったかどうかを３１０で判定し、見つからなかった場合は確定処理担当者を初期値の処理担当者とする。３０９の処理で代理処理担当者が見つかった場合は、３１２で対象とする処理担当者を３０７で見つかった代理処理担当者として、処理３０２に戻る。
【００１９】
例えば、図２の文書ＩＤ００１が２００４年５月２７日１４：００に処理依頼されたとすると、まず、指定処理担当者山田のスケジュールを検索する。図７をみると、５月２８日９：００まで不在である。不在時間が記録される。図４の代理処理テーブルに有効なレコードがなかったとすると、図６の人事テーブルより、同一部門の同一職位の吉田が代理処理担当者として検索される。図８から、吉田の２００４年５月２７日１４：００のスケジュールを検索すると、２００４年５月２７日１５：００まで不在である。不在時間が、２００４年５月２７日１５：００に更新される。図６より、代理処理担当者として、上田が検索される。図９より、上田の２００４年５月２７日１４：００のスケジュールを検索すると、在席している。在席時間２００４年５月２７日１７：００が記録され、図４の代理処理テーブルに山田の代理処理担当者として上田が登録される。
【００２０】
図１２は、図１１で決った処理担当者の処理期限を決定し、処理担当者のＰＣに処理依頼通知するまでのフローチャートである。４０１で最終処理期限を現在から最終ノードまでのノード数で割り、1ノード当たりの期限を求める。これをノード期限として記録しておく。４０２で在席時間が記録されているかどうか、つまり現在誰かが処理可能かどうかを判定する。在席期間が記録されていなければ、４０３の処理で処理期限を不在時間にし、４０６の判定へ行く。在席期間が記録されていれば、４０４の処理で一時処理期限を在席時間とする。４０５で、一時処理期限、ノード期限、文書カテゴリテーブルから取得した過去の平均処理時間の３つを比較し、一番短い時間を処理期限と設定する。４０６で処理期限が１時間未満であるかどうか判定し、一時間未満であれば、処理期限を１時間とする。これは、処理期限の最低時間を与えるもので、３０分、２時間などにすることも可能である。４０８で処理期限がノード期限より大きいかどうかを判定し、大きい場合は、文書作成者のＰＣに処理が遅れる旨と処理期限に最終ノードまでのノード数を掛けて求めた想定の最終処理時間を通知する。この処理により、文書作成者は文書が処理されるまで目安の時間を知ることができ、別対策を考えることができるといった効果を得ることができる。４１０の処理で処理テーブルの処理担当者及び処理期限を更新し、処理担当者のＰＣへ処理依頼通知をする。
文書ＩＤ００１の例では、一時処理期限(在席時間)が２００４年５月２７日１７：００、ノード期限が２００４年５月２８日１３：４０、平均処理時間が、２００４年５月２７日１９：００となるので、処理期限は、２００４年５月２７日１７：００と決定される。
【００２１】
図１３は、処理依頼をされている案件が処理期限を超過しても、処理担当者のＰＣより承認もしくは、却下処理の通知を受け取っていない場合のフローチャートである。５０１の処理期限を超過した案件に対し、処理担当者が処理期限までの間、不在であったかどうかを５０２で判定する。図１１及び図１２によると処理依頼された時間に誰も処理可能な人がいなければ、処理可能になる時間が処理期限として設定されている。処理担当者が在席であった場合、つまり、承認もしくは却下処理が可能な状態であったにもかかわらず処理を行わなかった場合、５０３で現在の処理担当者とは違う処理担当者を初期値として与える。優先度は、同一部門の同一職位、指定処理担当者の上司、以下図５文書カテゴリテーブルの代理処理担当者最高職位まで探す。なお、同一部門の同一職位の人を調べる場合は、氏名順で現在の処理担当者から指定処理担当者まで探すというようにしておく。処理担当者が処理可能な状態で処理を行わなかった場合、５０４で現在の処理担当者のＰＣに警告の通知をする。５０２の判定で処理担当者が処理期限の間不在であった場合は、５０５で現在の処理担当者を処理担当者の初期値として与える。５０６で処理１を実行し、再度処理担当者及び処理期限を検索し、処理依頼をする。このようにすると処理期限を超過した場合、処理可能な処理担当者が存在する限り次々と自動で処理担当者を変更させることができるようになる。
【００２２】
図１４は、処理担当者のＰＣから承認もしくは却下の通知を受け取った場合のフローチャートである。６０１の承認もしくは却下された場合、６０２で図３の処理テーブルより処理依頼時間を取得して、処理に掛かった時間を計測する。処理に掛かった時間と図５の文書カテゴリテーブルの平均処理時間を使って、平均処理時間の再計算を行う。計算式は、平均処理時間＝(平均処理時間×母数＋処理時間)/(母数+1)とし、求めた平均処理時間を更新する。６０３で承認か却下を判定し、承認であれば、次のノードの処理担当者を検索し処理依頼通知を送るため、図１１及び図１２の処理を実行し、却下であれば、文書作成者のＰＣに却下通知を送り、処理テーブルを更新する。図３の文書ＩＤ００１では、審査ノードで上田が承認を行った後、承認ノードでも承認されているが、これは、上田が承認ノードの処理権限を持っているため、審査と承認を同時に行っているということである。
【００２３】
上記で記述した方法を使うことにより、処理担当者の在席状況から最適な処理担当者を検索できるようになり、処理依頼後に処理担当者が処理をする前に不在となった場合でも、処理期限を定めることで、処理担当者を自動的に変更させることができ、滞留による待ち時間を短縮できるようになる。
【図面の簡単な説明】
【００２４】
【図１】本発明が適用されるシステムの構成例を示す図である。
【図２】文書テーブルの例を示す図である。
【図３】処理テーブルの例を示す図である。
【図４】代理処理テーブルの例を示す図である。
【図５】文書カテゴリテーブルの例を示す図である。
【図６】人事テーブルの例を示す図である。
【図７】予定テーブルの例（１）を示す図である。
【図８】予定テーブルの例（２）を示す図である。
【図９】予定テーブルの例（３）を示す図である。
【図１０】本発明の実施例を示すフローチャート（１）である。
【図１１】本発明の実施例を示すフローチャート（２）である。
【図１２】本発明の実施例を示すフローチャート（３）である。
【図１３】本発明の実施例を示すフローチャート（４）である。
【図１４】本発明の実施例を示すフローチャート（５）である。
【符号の説明】
【００２５】
１０１…サーバ、１０２…文書管理部、１０３…時間管理部、１０４…処理担当者決定部、１０５…文書テーブル、１０６…処理テーブル、１０７…代理処理テーブル、１０８…人事テーブル、１０９…予定テーブル、１１０…ＬＡＮ、１１１…作成ＰＣ、１１２…処理ＰＣ。
【図１】
2006079381.tif 000003
【図２】
2006079381.tif 000004
【図３】
2006079381.tif 000005
【図４】
2006079381.tif 000006
【図５】
2006079381.tif 000007
【図６】
2006079381.tif 000008
【図７】
2006079381.tif 000009
【図８】
2006079381.tif 000010
【図９】
2006079381.tif 000011
【図１０】
2006079381.tif 000012
【図１１】
2006079381.tif 000013
【図１２】
2006079381.tif 000014
【図１３】
2006079381.tif 000015
【図１４】
2006079381.tif 000016