JP2015001819A - 承認ワークフロー管理システム - Google Patents

Abstract

【課題】多数の店舗や部署における承認ルートを包括的に定義できるようにし、これにより店舗や部署の相違、更には人事異動にも柔軟に対応できるようにして、承認ルートの定義や変更の維持管理に要する労力を効果的に抑制する。
【解決手段】（Ａ）において、承認ルートを仮想ユーザＩＤで定義する。実ユーザに関するユーザ定義情報の登録は、仮想ユーザＩＤの登録や承認ルートの定義の前でも、後でも可能である。又、各店舗における回覧・承認にあたっては、仮想ユーザＩＤに対する実ユーザを、ユーザ定義情報を用いつつ、参照権や実行権に基づいて自動的に決定することにより、（Ｂ）〜（Ｅ）のような承認ルートが設定される。従って、多数の店舗や部署における承認ルートを包括的に定義でき、組織変更に伴う承認ルート定義の変更を不要とすることができる。
【選択図】図１２

Description

本発明は、多数の店舗や部署における承認ルートを包括的に定義できるようにし、これにより店舗や部署の相違、更には人事異動にも柔軟に対応できるようにして、承認ルートの定義や変更の維持管理に要する労力を効果的に抑制することができる承認ワークフロー管理方法、承認ワークフロー管理装置、又、これら承認ワークフロー管理方法及び承認ワークフロー管理装置を実施するためのコンピュータ・プログラムに関する。

従来から、サーバ装置を用いたオンラインにより、回覧対象の文書や帳票（総括して以下帳票と称する）を回覧対象者に順に回付して承認を得ていくということが行われている。このようなシステムにおいて、緊急時には、初期設定とは別の回付ルートで書類を回覧するものでは、もともと初期設定の回付ルートに含まれていた回付対象者に書類が回らなくなるという問題がある。このため、特許文献１では、承認案件がユーザに回付された時点から承認猶予期間を管理しつつ、自動設定期限を超過した承認案件に対しては仮承認を行うなどして、対象者全員に承認案件を回すリードタイムを短縮しつつ、対象者全員が承認案件の承認を確実に行うようにしている。

又、このような回覧対象の帳票を回付して順に承認を得ていくシステムについては、全社的なものも望まれる。特許文献２については、特に知的財産業務に限定されているが、一連の知的財産業務を社員レベルで効率的に遂行する、全社的な特許管理システムが提案されている。

ここで、このような一連の担当者承認のワークフローでは、該当の承認者が不在の場合、業務が滞ってしまうという問題が生じる。このため、特許文献３では、所定条件を満たした業務の緊急重要性に基づいて、代理承認させるかを判断するようにしている。又、承認者が当該ワークフローに、最後にログインしてから一定期間経過したかに基づいて、代理承認をさせるかを判断するようにしている。

特表２００５−７８４２８号公報 特開２００６−１３９７６１号公報 特表２０１２−１４６１０６号公報

ここで、リードタイムを短縮しつつ、対象者全員の承認案件の承認を確実に得るために、更には、該当の承認者が不在の場合にも柔軟に対応できるためには、該当承認帳票の最適なワークフローを設定する必要がある。しかしながら、特許文献１〜特許文献３のいずれにおいても、随時発生する個々の承認帳票に対して、承認者の選定やその順序の設定登録など、最適なワークフローを設定する点については記載されていない。

特に、特許文献２のように、全社的なシステムであれば、より高度な柔軟性が要求されるが、このような点についても記載されていない。承認対象の帳票によっては、全社的に統一して作成され、回覧及び承認については、各部署において個別に行われるものも存在するが、従来においては、このような承認帳票に対して、承認者の最適なワークフローを設定する点については開示されていない。

ここで、ワークフローでも特に、複数の店舗において帳票を配布し、各店舗にて回覧・承認する承認ルートの定義や変更について考える。例えば、各店舗毎のデータベースに配布する帳票データを格納して電子的に回覧・承認する場合、各店舗毎の承認ルートを定義する必要がある。又、人事異動などがあった場合、承認ルート定義を変更する必要がある。従来、このような定義や変更を行う、承認ルートの維持管理については、店舗数が多い場合、多大な労力を要することになる。

本発明は、前記従来の問題点を解決するべくなされたもので、多数の店舗や部署における承認ルートを包括的に定義できるようにし、これにより店舗や部署の相違、更には人事異動にも柔軟に対応できるようにして、承認ルートの定義や変更の維持管理に要する労力を効果的に抑制することができる承認ワークフロー管理システムを提供することを課題とする。

本発明は、該当の帳票を順に回覧して承認を得ていくワークフローの承認者の選定や順序を設定登録することができる承認ワークフロー管理方法において、予め、承認者候補の仮想ユーザＩＤを登録しておき、複数の部署や店舗に配布される帳票の承認ルートを、前記仮想ユーザＩＤで包括的に定義し、前記仮想ユーザＩＤ登録や前記承認ルート定義を行う前、又は後に、承認者となる個々の実ユーザに関するユーザ定義の情報を登録し、実ユーザによる回覧・承認に際しては、前記仮想ユーザＩＤに対する実ユーザを、少なくとも前記ユーザ定義情報を用いつつ、自動的に決定するようにしたことにより、多数の店舗や部署における承認ルートを包括的に定義できるようにし、これにより店舗や部署の相違、更には人事異動にも柔軟に対応できるようにして、承認ルートの定義や変更の維持管理に要する労力を効果的に抑制することができる。

なお、本発明の承認者候補は、承認ワークフローの作成時には実ユーザが未割当てであっても、帳票を順に回覧して承認をする際までには、実ユーザが割り当てられる。この承認者候補は、仮想のユーザ、仮想の承認者などとも言うことができる。

なお、本発明における情報格納手段については、用いるハードウェアの種類やデータの保存形式などについて、特に限定されるものではなく、例えばハードディスクや半導体メモリなどのハードウェア上に、テーブル形式やデータベース形式で情報を格納するものであってもよい。又、上記の実ユーザに関する定義情報については、特に限定されるものではないが、具体的には、後述するユーザ定義や参照権や実行権の定義などに関連する情報である。このような実ユーザに関する定義情報は、例えば後述する図４の参照権定義テーブルや図５のユーザ定義テーブルの情報のように、実ユーザを特定するユーザＩＤを用いて設定や登録を行うような、実ユーザに直接関与する部分は、仮想ユーザＩＤ登録や承認ルート定義の後でも設定や登録が可能であり、従って、仮想ユーザＩＤ登録や承認ルート定義を行う前後を問わず可能である。つまり、本発明では、仮想ユーザＩＤ登録や承認ルート定義は、実ユーザ定義情報への依存度がかなり低く抑えられており、極めて自由に行うことができる。なお、本発明における実ユーザとは、実際に閲覧や承認を行うユーザである。

ここで、本発明の承認ワークフロー管理方法において、まず、帳票の利用を許可する実行権の登録を、実行権ＩＤ毎に個別に設定し、前記ユーザ定義の情報の登録を、前記実行権ＩＤを適宜用い、ユーザ定義情報格納手段に対して行い、前記仮想ユーザＩＤの登録を、前記実行権ＩＤを適宜用い、仮想ユーザ定義情報格納手段に対して行うことができる。

又、本発明の承認ワークフロー管理方法において、前記ユーザ定義の情報の登録の少なくとも一部として、個々の実ユーザについて、帳票のファイルアクセスを許可する参照権の登録を、参照権定義情報格納手段に対して行い、前記仮想ユーザＩＤの登録を、仮想ユーザ定義情報格納手段に対して登録し、該当の回覧承認帳票を順に閲覧し承認する承認者を、前記仮想ユーザＩＤによりワークフロー定義情報格納手段に登録し、閲覧承認をする実ユーザは、ワークフロー定義情報格納手段に登録されている前記仮想ユーザＩＤをキーとして、参照権についての前記ユーザ定義を参照しつつ、前記仮想ユーザ定義情報格納手段を検索して判別するようにしたことにより、ワークフローの設定登録を、承認者候補の仮想ユーザＩＤを用いながらきめ細かに柔軟に行うことができる。

ここで、帳票の利用を許可する実行権の登録が、表示処理、印刷処理、検索処理、及び、編集処理の個々の実行の可否として、実行権定義情報格納手段において、実行権ＩＤ毎に個別に予め設定され、前記ユーザ定義が、前記参照権の登録に加えて、該実行権ＩＤを用いて、ユーザ定義情報格納手段において、該当の実ユーザのユーザＩＤをキーとして設定し登録するものとすることで、承認対象帳票に対する実ユーザの実行権の様々な内容や可否をきめ細かに設定することができる。

又、前記仮想ユーザ定義情報格納手段の登録が、個々の仮想ユーザＩＤに対して、前記ユーザＩＤを用いて直接的に、又は前記実行権ＩＤを用いて間接的に設定することで、承認者候補に対する実ユーザの対応付けを登録するものであることで、承認対象帳票に対する実ユーザのアクセスの可否や、実行権の様々な内容や可否をきめ細かに設定することができる。

次に、本発明は、該当の帳票を順に回覧して承認を得ていくワークフローの承認者の選定や順序を設定登録することができる承認ワークフロー管理装置において、回覧して承認を得ていく対象となる帳票の承認を行う、承認者となる個々の実ユーザについて、帳票のファイルアクセスを許可する定義登録を行う参照権定義情報格納手段と、前記実ユーザについて、帳票の利用を許可する実行権の定義登録を行うユーザ定義情報格納手段と、前記ワークフローの設定登録の際に、承認者候補として設定登録するために用いる仮想ユーザＩＤを登録する仮想ユーザ定義情報格納手段と、該当の回覧承認帳票を順に閲覧し承認する承認者を、前記仮想ユーザＩＤにより登録するワークフロー定義情報格納手段と、を備え、閲覧承認をする実ユーザは、ワークフロー定義情報格納手段に登録されている前記仮想ユーザＩＤをキーとして、前記仮想ユーザ定義情報格納手段を検索して判別するようにしたことにより、ワークフローの設定登録を、承認者候補の仮想ユーザＩＤを用いながらきめ細かに柔軟に行うことができる。

ここで、更に、個々の実行権ＩＤに対して、表示処理、印刷処理、検索処理、及び、編集処理の実行の可否を個別に、設定登録する実行権定義情報格納手段を備えると共に、
前記ユーザ定義情報格納手段は、前記実ユーザのそれぞれのユーザＩＤに対して、上記実行権ＩＤを設定登録することで、前記実ユーザについて、帳票の利用及びその種類を許可する実行権の定義登録を行うものとすることで、承認対象帳票に対する実ユーザの実行権の様々な内容や可否をきめ細かに設定することができる。

以上の承認ワークフロー管理方法及び承認ワークフロー管理装置は、コンピュータ・プログラムによって実現することができる。

本発明によれば、ワークフローの設定登録を、承認者候補の仮想ユーザＩＤを用いながらきめ細かに柔軟に行うことができる。従って、多数の店舗や部署における承認ルートを包括的に定義できるようにし、これにより店舗や部署の相違、更には人事異動にも柔軟に対応できるようにして、承認ルートの定義や変更の維持管理に要する労力を効果的に抑制することができる。

更には、実ユーザの参照権や実行権をきめ細かに設定することができ、情報の不用意な流出や改ざん防止を図ることができ、セキュリティ確保の向上を可能とすることができる。

本発明が適用される実施形態の承認ワークフロー管理システムが導入された企業基幹システムの全体的な構成を示すブロック図 前記企業基幹システムで用いられるコンピュータ装置のハードウェア構成を示すブロック図 前記実施形態の主要部である承認ワークフロー管理装置の構成を示すブロック図 前記実施形態における参照権定義テーブルを示す線図 前記実施形態におけるユーザ定義テーブルを示す線図 前記実施形態における実行権定義テーブルを示す線図 前記実施形態における仮想ユーザ定義テーブルを示す線図 前記実施形態におけるワークフロー定義テーブルを示す線図 前記実施形態におけるワークフロー運用業務を示すフローチャート 上記ワークフロー運用業務におけるユーザ業務運用処理を示すフローチャート 本発明が適用された第１実施例のワークフロー定義テーブルを示す線図 上記ワークフロー定義テーブルにより実施される承認ルートを示す線図 上記ユーザ業務運用処理による実ユーザのユーザＩＤの確定進捗の第２実施例及び第３実施例を示す線図

以下図面を参照して、本発明の実施形態を詳細に説明する。

図１は、本発明が適用される実施形態の承認ワークフロー管理システムが導入された企業基幹システムの全体的な構成を示すブロック図である。

この図において、承認ワークフロー管理装置１０が、本発明が適用された主要部である。業務データ保存装置２０は、本発明を適用した承認の対象になる帳票のデータを含め、様々な業務データを保存するものである。クライアント装置５については、これら承認ワークフロー管理装置１０及び業務データ保存装置２０に接続することができ、情報データの作成、表示（閲覧）、印刷、検索、及び、編集などに際し、又、本発明を適用した様々な設定登録や承認作業に際して、端末装置として用いられる。

又、図示されるように、これら承認ワークフロー管理装置１０、及び業務データ保存装置２０は、相互に、ネットワーク１により接続されている。加えて、これら装置に接続するクライアント装置５も、ネットワーク１により接続されている。該接続により、汎用形式や専用形式のファイル交換がなされる。

なお、ネットワーク１は、特に限定されるものではない。公衆回線あるいは専用回線を用いるものでも、インターネットやＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）を用いるものでも、あるいはこれらを複合的に接続し構成するものであってもよい。

図２は、本実施形態の各装置に用いるコンピュータ装置のハードウェアの構成を示すブロック図である。

この図２においては、承認ワークフロー管理装置１０、業務データ保存装置２０、更にはクライアント装置５の各装置として利用可能な、ある種のコンピュータ装置のハードウェア構成が示される。しかしながら、各装置は、このようなものに限定されるものではない。

図２の該コンピュータ装置は、ＯＳ（Operating System）は一例として米国マイクロソフト社のＷｉｎｄｏｗｓ（登録商標）を搭載する、一般的なＰＣ（Personal Computer）装置であってもよく、特に限定されるものではない。あるいは、ＰＣ装置以外のハードウェアを用いてもよく、例えばＥＷＳ（Engineering Work Station）などの、いわゆるワークステーションなどのハードウェアを用いるようにしてもよい。なお、この図において、ハードウェア構成は、説明の関係上一部抽象化されている。

この図において、コンピュータ装置は、ＣＰＵ（Central Processing Unit）３１０と、ＲＡＭ（Random Access Memory）３１１と、ＲＯＭ（Read Only Memory）３１２と、ＬＡＮ−Ｉ／Ｆ（Inter Face）３１３と、ＭＯＤＥＭ（modulator-demodulator）３１４と、種々のＩ／Ｆ３２０〜３２２とを有している。これらは、バス３０１によって相互接続されている。

なお、ＬＡＮ−Ｉ／Ｆ３１３は、ネットワーク１に対して接続するために用いられる。

又、バス３０１に対して、Ｉ／Ｆ３２０を介して、画面表示装置３３０が接続されている。又、バス３０３によって相互接続されている、キーボード３３１と、マウス３３２と、プリンタ装置３３３とは、バス３０１に対して、Ｉ／Ｆ３２１を介して接続されている。

更に、バス３０１に対して、Ｉ／Ｆ３２２を介して、ＨＤＤ（Hard Disc Drive）装置３４０と、ＣＤ（Compact Disc）ドライブ装置３４１と、ＦＤＤ（Floppy（登録商標） Disc Drive）装置３４２とが接続されている。これらはバス３０２によって相互接続されている。

以上のようなハードウェア構成において、記憶手段、又記憶装置は、ＲＡＭ３１１、ＲＯＭ３１２、ＨＤＤ装置３４０、ＣＤドライブ装置３４１、ＦＤＤ装置３４２などである。このような記憶手段や記憶装置において、ＣＰＵ３１０で実行される様々なプログラムや、本実施形態においてアクセスされるデータベースや諸ファイルやデータが保存され、電子的にアクセスができるようになっている。例えば、ＯＳや、データベースやＪＡＶＡ（登録商標)やＪＳＰ（Java（登録商標) Server Page）などのソフトウェア資源を利用する環境を提供するためのプログラム、本実施形態に係るアプリケーション・プログラム、又ウェブ・ブラウザ・プログラムは、ＨＤＤ装置３４０に格納されていて、実行時には、ＲＡＭ３１１に読み出されてＣＰＵ３１０によって実行される。なお、ＣＰＵ３１０で実行されるアプリケーション・プログラムには、ネットワーク１経由で取得される、ＪＡＶＡ（登録商標)のアプレットや、ＡＳＰ（Active Server Page）の機能によって提供されるものも含まれる。

又、ＯＳやアプリケーション・プログラムその他の実行に際して、オペレータは、画面表示装置３３０に表示出力される情報を参照しつつ、キーボード３３１によって文字入力や諸操作を行ったり、マウス３３２によって座標入力や諸操作の入力を行ったりする。例えば、マウス３３２によって、一覧表示される電子的な帳票の選択をしたり、閲覧中の電子的な帳票において、検索などの範囲指定を行ったり、その他、クリック操作や、いわゆるドラッグ・アンド・ドロップ操作により様々な操作を行ったりする。又、適宜、プリンタ装置３３３からは必要な情報を印字出力したりすることができる。言うまでもなく、これら諸出力や入力は、ＣＰＵ３１０で実行されるプログラムによって、電子的な処理によって行われるものである。

なお、ＣＤドライブ装置３４１やＦＤＤ装置３４２は、本願発明を適用して実施する際の、アプリケーション・プログラムのインストールや、その他のオフラインでの情報交換に用いられる。

図３は、本実施形態の主要部である承認ワークフロー管理装置の構成を示すブロック図である。

図示されるように、前述の承認ワークフロー管理装置１０は、実行権定義登録処理部３０と、ユーザ情報登録処理部３２と、仮想ユーザ定義登録処理部３４と、ワークフロー情報登録処理部３６と、ユーザ業務運用処理部４０とを備える。更に、承認ワークフロー管理装置１０は、実行権定義テーブル５０と、ユーザ定義テーブル５２と、参照権定義テーブル５４と、仮想ユーザ定義テーブル５６と、ワークフロー定義テーブル５８とを備える。

図４は、本実施形態における参照権定義テーブル５４を示す線図である。又、図５は、本実施形態におけるユーザ定義テーブル５２を示す線図である。

本実施形態の実ユーザにはユーザＩＤが割り当てられ、個々の実ユーザがアクセス可能なファイルは図４の参照権定義テーブル５４により、個々の実ユーザの実行権は図５のユーザ定義テーブル５２により設定登録される。これら設定登録は、ユーザ情報登録処理部３２の処理によって、該ユーザ情報登録処理部３２に接続されるクライアント装置５から行われる。

まず、図４に示すように、参照権定義テーブル５４における各レコードにおいては、「ユーザＩＤ」、「店舗ＩＤ」、及び、１つ以上の「帳票ＩＤ」が設定される。「ユーザＩＤ」の項には、そのレコードによって設定される実ユーザを示すユーザＩＤが設定され、「店舗ＩＤ」の項には、そのレコードの実ユーザが所属する店舗を示す店舗ＩＤが設定され、「帳票ＩＤ」の項には、そのレコードの実ユーザにアクセスが許可されている帳票（コンピュータ上のファイル）を示す帳票ＩＤが設定される。複数の帳票に対するアクセスが許可されている場合には、複数の帳票ＩＤが設定される。

なお、本実施形態では、この帳票には、本実施形態の承認ワークフローにおいて、承認対象となるものが含まれている。又、そのレコードの実ユーザが複数の帳票に対するアクセスを許可されている場合、該当のレコードにおいて、許可されている帳票を示すＩＤ（帳票ＩＤ）が該当レコードにおいて複数羅列される。

なお、上述のように実ユーザが複数の帳票に対するアクセスを許可されている場合、該当実ユーザのユーザＩＤ、及び、この実ユーザに許可されている、それぞれ異なる帳票を示すＩＤ（帳票ＩＤ）の対を、複数のレコードに格納することによって、このような複数帳票のアクセスの許可を登録するようにしてもよい。

なお、本実施形態において、それぞれの帳票は、店舗単位で格納されたり、店舗単位でアクセス権が管理されたりしているが、本発明はこのようなものに限定されるものではない。

次に、図５に示すように、ユーザ定義テーブル５２における各レコードにおいては、「ユーザＩＤ」、及び、１つ以上の「実行権ＩＤ」が設定される。「ユーザＩＤ」の項には、そのレコードによって設定される実ユーザを示すユーザＩＤが設定され、「実行権ＩＤ」の項には、そのレコードの実ユーザが有する実行権を定義するための実行権ＩＤが設定される。そのレコードの実ユーザが複数の実行権を有する場合、該当のレコードにおいて、それらの実行権を指定するＩＤ（実行権ＩＤ）が該当レコードにおいて複数羅列される。なお、設定されている実行権ＩＤによって許可されている具体的な実行権の内容は、実行権定義テーブル５０を参照することで判別することができる。

ここで、図中の「実行権ＩＤ」の項において、課長（実行権ＩＤ）及び部長（実行権ＩＤ）は、いずれも実行権ＩＤであり、後述する課長（仮想ユーザＩＤ）や部長（仮想ユーザＩＤ）とは異なる。後者の課長（仮想ユーザＩＤ）及び部長（仮想ユーザＩＤ）は、いずれも仮想ユーザＩＤである。

図６は、本実施形態における実行権定義テーブル５０を示す線図である。

図６に示すように、実行権定義テーブル５０における各レコードにおいては、「実行権ＩＤ」、「表示」、「印刷」、「検索」、及び「編集」が設定される。「実行権ＩＤ」の項には、そのレコードによって設定される実行権を示す実行権ＩＤが設定される。この設定登録は、実行権定義登録処理部３０の処理によって、該実行権定義登録処理部３０に接続されるクライアント装置５から行われる。

この実行権定義テーブル５０において、「表示」、「印刷」、「検索」、及び「編集」のそれぞれの項では、該当の表示、印刷、検索、及び編集のそれぞれの実行の可否が設定され、図６において、実行の許可を設定する場合は「○」、不許可を設定する場合は「×」が設定される。

この図の「レコードNo.」が「１」のレコードでは、「課長（実行権ＩＤ）」の実行権ＩＤに対して、表示、印刷、及び検索の実行が許可されているが、編集の実行は許可されてない。「２」のレコードでは、「部長（実行権ＩＤ）」の実行権ＩＤに対して、表示、印刷、検索、及び編集のすべてについて、実行が許可されている。

なお、設定される実行権の内容については、上述した表示、印刷、検索、及び編集に限定されるものではない。更に別の実行権内容を設定するのであれば、図中の例えば「編集」の項の右側に羅列するようにしてもよい。

図７は、本実施形態における仮想ユーザ定義テーブル５６を示す線図である。

本実施形態においては、承認のワークフローの設定登録において、承認者の設定登録は、ユーザＩＤを用いて直接行うのではなく、この図７に示す仮想ユーザ定義テーブル５６にある、仮想ユーザＩＤを用いて間接的に行うようになっている。この仮想ユーザ定義テーブル５６における各レコードにおいては、「仮想ユーザＩＤ」、「店舗ＩＤ」、「実ユーザ指定方法」、及び、１つ以上の「実ユーザ」が設定される。本実施形態においては、１つの「仮想ユーザＩＤ」に対して、複数の「実ユーザ」を羅列して設定することが可能となっている。これらの設定は、仮想ユーザ定義登録処理部３４の処理によって、該仮想ユーザ定義登録処理部３４に接続されるクライアント装置５から行われる。又、ワークフロー定義テーブル５８などにおいて、仮想ユーザＩＤで示される閲覧承認をする実ユーザは、承認のワークフローに登録されている仮想ユーザＩＤをキーとして、仮想ユーザ定義テーブル５６を検索して判別する。

「仮想ユーザＩＤ」の項には、承認のワークフロー（承認ルート）を設定登録する際に用いる仮想ユーザＩＤが設定され、「店舗ＩＤ」の項には、該当の仮想ユーザＩＤの設定がどの店舗に関するものであるか設定される。「レコードNo.」が「３」や「４」において、「店舗ＩＤ」の「その他」の設定は、ワイルドカードの設定であり、すべての店舗を指定するものである。

ここで、この仮想ユーザ定義テーブル５６は、該当の「仮想ユーザＩＤ」が、「店舗ＩＤ」で示されるどの店舗の、どの実ユーザを示すもの（実ユーザの特定）であるかを定義し設定するものである。本実施形態では、この実ユーザの特定方法として、実ユーザのユーザＩＤによる直接的な第１の特定方法に加えて、実行権ＩＤによる間接的な第２の特定方法を備えている。

又、この第１の特定方法によるものか、あるいは第２の特定方法によるものかの区別は、仮想ユーザ定義テーブル５６における、「実ユーザ指定方法」の項において、「ユーザＩＤ」あるいは「実行権ＩＤ」の定義設定によって行っている。「ユーザＩＤ」の定義設定であれば、第１の特定方法であり、この仮想ユーザ定義テーブル５６の「実ユーザ」の項には、直接的に実ユーザを特定するための、該当実ユーザのユーザＩＤが定義設定される。あるいは、「実ユーザ指定方法」の項において、「実行権ＩＤ」の定義設定であれば、第２の特定方法であり、この仮想ユーザ定義テーブル５６の「実ユーザ」の項には、実ユーザを特定するために、該当実ユーザが有すべき実行権ＩＤが定義設定され、間接的に実ユーザが定義設定される。

このように、第１の特定方法であれば、１つの仮想ユーザＩＤは、１名の承認者候補を特定するものである。これに対して、第２の特定方法であれば、１つの仮想ユーザＩＤは、該当実行権ＩＤを有するのであれば複数ともなり得る、承認者候補を特定するものである。

ここで、図中の「仮想ユーザＩＤ」の項にある、課長（仮想ユーザＩＤ）及び部長（仮想ユーザＩＤ）は、いずれも仮想ユーザＩＤであり、前述した課長（実行権ＩＤ）や部長（実行権ＩＤ）とは異なる。後者の課長（実行権ＩＤ）及び部長（実行権ＩＤ）は、いずれも実行権ＩＤである。

なお、仮想ユーザＩＤは、課長や部長といった職位別に設定することに限定されない。例えば、経理担当といった役職別や部署別に設定するようにしてもよい。

図８は、本実施形態におけるワークフロー定義テーブル５８を示す線図である。

このワークフロー定義テーブル５８によりなされる承認ワークフローの設定登録は、例えば、本社で作成されて各店舗に送付される、毎週の週報の閲覧や、本社から各店舗に指示があって、各店舗において、担当者が企画書を作成して店舗内で順次承認を得るものである。このように、このワークフロー定義テーブル５８では、該当する承認のワークフローにおいて順次承認を行う実ユーザを、仮想ユーザＩＤを用いて設定登録するものである。又、この仮想ユーザＩＤは、仮想ユーザ定義テーブル５６や実行権定義テーブル５０を参照しつつ、実ユーザに結びつけられる。

本発明では、このように仮想ユーザＩＤを用いて承認ルートなどのワークフローの定義を行うので、多数の店舗や部署における承認ルートを包括的に定義できる。これにより、店舗や部署の相違、更には人事異動にも柔軟に対応できるようにして、承認ルートの定義や変更の維持管理に要する労力を効果的に抑制することができる。

なお、このワークフロー定義テーブル５８にある仮想ユーザＩＤを、上述のように仮想ユーザ定義テーブル５６や実行権定義テーブル５０を参照するなどして、実ユーザに結びつける際、１つの仮想ユーザＩＤに対して、複数の実ユーザが結びつけられることがある。このように複数の実ユーザが結びつけられる際、本実施形態では、ＯＲ承認及びＡＮＤ承認の定義を可能としている。図８に示されるワークフロー定義テーブル５８において、ＯＲ承認及びＡＮＤ承認のテーブル列において、「○」又は「×」を設定することにより、これらＯＲ承認及びＡＮＤ承認の可否を定義することができる。

ＯＲ承認が設定されると、結びつけられた複数の実ユーザにおいて、いずれかの実ユーザから承認が得られれば承認済とされる。これに対して、ＡＮＤ承認が設定されると、このような複数の実ユーザすべての承認が得られなければ承認済とはされない。

ここで、このワークフロー定義テーブル５８の設定登録は、ワークフロー情報登録処理部３６の処理によって、該ワークフロー情報登録処理部３６に接続されるクライアント装置５から行われる。なお、図８の承認ワークフローの設定登録例では、本社において設定登録されたもので、複数の店舗を対象として設定登録されたものである。

この図８のワークフロー定義テーブルにおいて、まず、承認の第１段階では（図８の第１行目）、仮想ユーザＩＤが「課長」に対応する実ユーザによって、第１段階の承認を得るという設定である。続いて、承認の第２段階では（図８の第２行目）、仮想ユーザＩＤが「部長」に対応する実ユーザによって、第２段階の承認を得るという設定である。

図９は、本実施形態におけるワークフロー運用業務を示すフローチャートである。

本実施形態のワークフロー運用業務では、まず、ステップＳ１０２では、前述した実行権定義テーブル５０により、個々の実行権ＩＤの具体的な実行権の内容を設定登録する。一般的には、実行権の内容は部長や課長などの職位単位で設定されるが、このようなものに限定されるものではない。例えば、経理担当などといった、役職単位や部署単位で設定するようにしてもよい。又、このステップＳ１０２では、個々の実ユーザについて、参照権定義テーブル５４により、個々の実ユーザがアクセス可能なファイルを設定登録すると共に、ユーザ定義テーブル５２により、個々の実ユーザの実行権を設定登録する。

次に、ステップＳ１０４では、ワークフロー定義テーブル５８により、個々の承認のワークフローについて、順次承認を行う実ユーザを、仮ユーザＩＤを用いて設定登録するものである。

この後、ステップＳ１０６では、図１０のフローチャートで示されるユーザ業務運用処理を行う。

図１０は、本実施形態において行われるワークフロー運用業務におけるユーザ業務運用処理を示すフローチャートである。

このユーザ業務運用処理は、ワークフロー定義テーブル５８において承認者として指定されている仮想ユーザＩＤから、店舗ＩＤで示される特定の店舗、及び、帳票ＩＤで示される特定の帳票（帳票ファイル）の指定に基づいて、実際の承認を行う実ユーザのユーザＩＤを判別したり、選定したりする処理である。

例えば、図８のワークフロー定義テーブル５８において、承認第１段階の仮想ユーザＩＤから実際の承認を行う実ユーザのユーザＩＤを、このようなユーザ業務運用処理により判別して、該ユーザＩＤの実ユーザに電子メールなどで承認を促す通知をすることもできる。そうして、この実ユーザによって承認された場合は、続く承認第２段階の仮想ユーザＩＤから実際の承認を行う実ユーザのユーザＩＤを、同様にユーザ業務運用処理により判別して、このユーザＩＤの実ユーザに電子メールなどで承認を促す通知をすることもできる。

まず、ステップＳ１２２及びステップＳ１２４は、仮想ユーザ定義テーブル５６を参照し、選定対象となる「仮想ユーザＩＤ」、且つ、指定されている「店舗ＩＤ」となっているレコードから、実ユーザ、あるいは実ユーザ候補を選定するものである。具体的には、ステップＳ１２２は、仮想ユーザ定義テーブル５６のレコードにおいて、「実ユーザ指定方法」の項の定義が「ユーザＩＤ」であるレコードを参照し、実ユーザの候補を選定するものである。又、ステップＳ１２４では、仮想ユーザ定義テーブル５６のレコードにおいて、「実ユーザ指定方法」の項の定義が「実行権ＩＤ」であるレコードを参照し、実ユーザの候補の実行権ＩＤを一旦求めるものであり、以降において、該実行権ＩＤを有する実ユーザの候補を選定することになる。

なお、これらステップＳ１２２及びＳ１２４において、いずれも該当レコードが存在しない場合、該仮想ユーザＩＤに対する実ユーザはなしとする。このように実ユーザなしの場合、例えば、図８のワークフロー定義テーブル５８において、該承認ステップはスキップされ、次の承認者による承認ステップに移行するようにしてもよい。

なお、ステップＳ１２２において、何ら実ユーザ候補を選定できなかった場合にのみ、つまり、該ステップＳ１２２において該当のレコードが見出されない場合にのみ、ステップＳ１２４を行うようにしてもよい。あるいは、これらステップＳ１２２及びステップＳ１２４を必ず共に行うようにしてもよい。

次に、ステップＳ１２６では、ステップＳ１２４により実行権ＩＤを選定した場合、該実行権ＩＤをユーザＩＤに置換する。この置換処理は、ユーザ定義テーブル５２を参照し、この「実行権ＩＤ」のレコードを見出し、該レコードのユーザＩＤを実ユーザ候補に追加するというものである。

続いて、ステップＳ１２８では、承認対象の該当する帳票のファイルの参照権に関する処理を行い、これまでに選定され追加されている実ユーザ候補から、該帳票を参照できないユーザＩＤを削除する。この削除処理は、参照権定義テーブル５４を参照し、追加されている実ユーザ候補それぞれについて、該当の「ユーザＩＤ」、且つ、「店舗ＩＤ」、且つ、「帳票ＩＤ」のレコードが存在しない場合、そのユーザＩＤを実ユーザ候補から削除するというものである。

ステップＳ１３０において、最終的に残った実ユーザ候補が、該仮想ユーザＩＤに対するユーザＩＤとなる。又、残ったユーザＩＤが複数の場合、これらユーザＩＤの複数の実ユーザは、前述したＯＲ承認やＡＮＤ承認の対象となる。

図１１は、第１実施例のワークフロー定義テーブル５８を示す線図である。図１２は、このワークフロー定義テーブル５８により実施される承認ルートを示す線図である。

まず、図１１のワークフロー定義テーブル５８では、担当者、課長、部長、及び店長の仮想ユーザＩＤによって、承認第１段階〜承認第４段階の承認ルートのワークフローが、複数の店舗を対象として包括的に定義されている。又、承認第２段階については、図中「ＡＮＤ承認」の列に「○」が設定され、ＡＮＤ承認が定義されている。これ以外の承認第１段階、承認第３段階、及び承認第４段階については、図中「ＯＲ承認」の列に「○」が設定され、ＯＲ承認が定義されている。

このような図１１のワークフロー定義テーブル５８の複数の店舗に亘る承認ルートの定義は、図１２の（Ａ）のとおりである。又、この包括的な承認ルート定義の対象には、図１２の（Ｂ）〜（Ｅ）に示されるように、少なくとも東京店、千葉店、埼玉店、及び神奈川店が含まれている。

ここで、図１２の（Ｄ）に示される埼玉店の承認ルートは、承認第３段階がＯＲ承認となっており、大木部長及び田中部長補佐の少なくとも一方の承認が得られれば承認済みとされ、承認第４段階の竹中店長の承認へと進む。又、図１２の（Ｅ）に示される神奈川店の承認ルートは、承認第２段階がＡＮＤ承認となっており、小池係長及び酒井課長の承認が共に得られれば承認済みとされ、承認第３段階の中井部長の承認へと進む。なお、このＡＮＤ承認において、承認する実ユーザの承認順序は順不同とすることもできる。

以上に説明した第１実施例では、その図１２において、店舗数は、便宜上、東京店、千葉店、埼玉店、及び神奈川店の４店舗のみである。しかしながら、ワークフローや承認ルートの対象になる部署や店舗の数が数十、数百と、多数になる会社や団体は多々存在する。このように対象が多数になると、ワークフローや承認ルートの定義や変更の維持管理に要する労力は多大になる。しかしながら、本発明を適用することで、異なる店舗や部署におけるワークフローや承認ルートを包括的に定義することができる。これにより、このような定義や変更の維持管理に要する労力を効果的に抑制することができる。

そして、以下に説明するように、図１０の処理を行って、図１１のワークフロー定義テーブル５８に定義されている仮想ユーザＩＤを実ユーザに結びつけていくことで、図１２の（Ｂ）〜（Ｅ）のような、東京店、千葉店、埼玉店、及び神奈川店の承認ルートが得られる。

図１３は、本実施形態において行われる上記ユーザ業務運用処理による実ユーザのユーザＩＤの確定進捗を示す第２実施例及び第３実施例の線図である。

この図において、まず第２実施例は、配布先店舗ＩＤが「東京」、帳票ＩＤが「帳票Ａ」である帳票の承認ルートに指定されている仮想ユーザＩＤ「課長」を、承認を実際に行う実ユーザのユーザＩＤに置換する処理である。例えば、この置換処理は、図８のワークフロー定義テーブル５８において、承認第１段階の「課長（仮想ユーザＩＤ）」の仮想ユーザＩＤをキーとして、配布先店舗ＩＤが「東京」、且つ、帳票ＩＤが「帳票Ａ」を前提とし、承認を実際に行う実ユーザのユーザＩＤを判別し、選定する処理である。又、前述の第１実施例の図１２における（Ｂ）の東京店において、承認第２段階の「山田課長」の置換に相当する処理である。

なお、図１０及び図１３において、ステップＳ１２２、Ｓ１２４、Ｓ１２６、及びＳ１２８については、図示されるように、それぞれ手順１、２、３、及び４とも称する。

まず、図１０におけるステップＳ１２２では、図７の仮想ユーザ定義テーブル５６において「実ユーザ指定方法」の項の設定が「ユーザＩＤ」であるレコードを参照する。すると、本第２実施例となる、「仮想ユーザＩＤ」の項が「課長」、且つ、「店舗ＩＤ」の項が「東京」、且つ、「実ユーザ指定方法」の項が「ユーザＩＤ」である、「ユーザＩＤ＝山田」、及び「ユーザＩＤ＝下田」の２つのレコードを見出すことができ、これらユーザＩＤの２名を実ユーザ候補とする。

続くステップＳ１２４では、図７の仮想ユーザ定義テーブル５６において「実ユーザ指定方法」の項の設定が「実行権ＩＤ」であるレコードを参照する。すると、「仮想ユーザＩＤ」の項が「課長」、且つ、「店舗ＩＤ」の項が「東京」、且つ、「実ユーザ指定方法」の項が「実行権ＩＤ」であるレコードは見出されない。又、「実行権ＩＤ」に基づいて実ユーザ候補を見出して追加するという、ステップＳ１２６も行われない。

ステップＳ１２８では、図４の参照権定義テーブル５４において、ステップＳ１２２〜ステップＳ１２６で選定した実ユーザ候補のユーザＩＤを検索する。具体的には、参照権定義テーブル５４において、ユーザＩＤ「山田」、且つ、店舗ＩＤ「東京」、且つ、帳票ＩＤ「帳票Ａ」のレコードが存在するため、ユーザＩＤ「山田」を実ユーザ候補に残す。他方、ユーザＩＤ「下田」、且つ、店舗ＩＤ「東京」、且つ、帳票ＩＤ「帳票Ａ」のレコードが存在しないため、ユーザＩＤ「下田」を実ユーザ候補から削除する。

最後に、ステップＳ１３０において、残った実ユーザ候補「山田」が該仮想ユーザＩＤに対するユーザＩＤとなる。

次に、図１３において、第３実施例は、配布先店舗ＩＤが「千葉」、帳票ＩＤが「帳票Ａ」である帳票の承認ルートに指定されている仮想ユーザＩＤ「部長」をユーザＩＤに置換する処理である。例えば、この置換処理は、図８のワークフロー定義テーブル５８において、承認第２段階の「部長（仮想ユーザＩＤ）」の仮想ユーザＩＤをキーとして、配布先店舗ＩＤが「千葉」、且つ、帳票ＩＤが「帳票Ａ」を前提とし、承認を実際に行う候補となる実ユーザのユーザＩＤを判別し、選定する処理である。又、前述の第１実施例の図１２における（Ｃ）の千葉店において、承認第３段階の「川田部長」の置換に相当する処理である。

まず、図１０におけるステップＳ１２２では、図７の仮想ユーザ定義テーブル５６において「実ユーザ指定方法」の項の設定が「ユーザＩＤ」であるレコードを参照する。すると、本第３実施例となる、「仮想ユーザＩＤ」の項が「部長」、且つ、「店舗ＩＤ」の項が「千葉」、且つ、「実ユーザ指定方法」の項が「ユーザＩＤ」であるレコードは存在しないので、実ユーザ候補は選定しない。

続くステップＳ１２４では、図７の仮想ユーザ定義テーブル５６において「実ユーザ指定方法」の項の設定が「実行権ＩＤ」であるレコードを参照する。すると、「仮想ユーザＩＤ」の項が「部長」、且つ、「店舗ＩＤ」の項が「その他」、且つ、「実ユーザ指定方法」の項が「実行権ＩＤ」であるレコードが見出され、該レコードの実ユーザを特定する「実行権ＩＤ＝部長」を実ユーザ候補とする。

続いて、ステップＳ１２６では、ステップＳ１２４にて実ユーザ候補とされた「実行権ＩＤ＝部長」を検索キーとし、図５のユーザ定義テーブル５２を参照すると、ユーザＩＤが「川田」及び「上田」の２つのレコードを見出すことができ、これに基づいて、実行権ＩＤ「部長」に換えてこれらレコードの２名を実ユーザ候補に追加する。

ステップＳ１２８では、図４の参照権定義テーブル５４において、ステップＳ１２２〜ステップＳ１２６で選定した実ユーザ候補のユーザＩＤを検索する。具体的には、参照権定義テーブル５４において、ユーザＩＤ「川田」、且つ、店舗ＩＤ「千葉」、且つ、帳票ＩＤ「帳票Ａ」のレコードが存在するため、ユーザＩＤ「川田」を実ユーザ候補に残す。他方、ユーザＩＤ「上田」、且つ、店舗ＩＤ「千葉」、且つ、帳票ＩＤ「帳票Ａ」のレコードが存在しないため、ユーザＩＤ「上田」を実ユーザ候補から削除する。

最後に、ステップＳ１３０において、残った実ユーザ候補「川田」が該仮想ユーザＩＤに対するユーザＩＤとなる。

１…ネットワーク
５…クライアント装置
１０…承認ワークフロー管理装置
２０…業務データ保存装置
３０…実行権定義登録処理部
３２…ユーザ情報登録処理部
３４…仮想ユーザ定義登録処理部
３６…ワークフロー情報登録処理部
４０…ユーザ業務運用処理部
５０…実行権定義テーブル
５２…ユーザ定義テーブル
５４…参照権定義テーブル
５６…仮想ユーザ定義テーブル
５８…ワークフロー定義テーブル
３０１〜３０３…バス
３１０…ＣＰＵ
３１１…ＲＡＭ
３１２…ＲＯＭ
３１３…ＬＡＮ−Ｉ／Ｆ
３１４…ＭＯＤＥＭ
３２０〜３２２…Ｉ／Ｆ
３３０…画面表示装置
３３１…キーボード
３３２…マウス
３３３…プリンタ装置
３４０…ＨＤＤ装置
３４１…ＣＤドライブ装置
３４２…ＦＤＤ装置

Claims (8)

1. 該当の帳票を順に回覧して承認を得ていくワークフローの承認者の選定や順序を設定登録することができる承認ワークフロー管理方法において、
   予め、承認者候補の仮想ユーザＩＤを登録しておき、
   複数の部署や店舗に配布される帳票の承認ルートを、前記仮想ユーザＩＤで包括的に定義し、
   前記仮想ユーザＩＤ登録や前記承認ルート定義を行う前、又は後に、承認者となる個々の実ユーザに関するユーザ定義の情報を登録し、
   実ユーザによる回覧・承認に際しては、前記仮想ユーザＩＤに対する実ユーザを、少なくとも前記ユーザ定義情報を用いつつ、自動的に決定するようにしたことを特徴とする承認ワークフロー管理方法。
2. 請求項１の承認ワークフロー管理方法において、
   まず、帳票の利用を許可する実行権の登録を、実行権ＩＤ毎に個別に設定し、
   前記ユーザ定義の情報の登録を、前記実行権ＩＤを適宜用い、ユーザ定義情報格納手段に対して行い、
   前記仮想ユーザＩＤの登録を、前記実行権ＩＤを適宜用い、仮想ユーザ定義情報格納手段に対して行うことを特徴とする承認ワークフロー管理方法。
3. 請求項１又は請求項２の承認ワークフロー管理方法において、
   前記ユーザ定義の情報の登録の少なくとも一部として、個々の実ユーザについて、帳票のファイルアクセスを許可する参照権の登録を、参照権定義情報格納手段に対して行い、
   前記仮想ユーザＩＤの登録を、仮想ユーザ定義情報格納手段に対して登録し、
   該当の回覧承認帳票を順に閲覧し承認する承認者を、前記仮想ユーザＩＤによりワークフロー定義情報格納手段に登録し、
   閲覧承認をする実ユーザは、ワークフロー定義情報格納手段に登録されている前記仮想ユーザＩＤをキーとして、参照権についての前記ユーザ定義を参照しつつ、前記仮想ユーザ定義情報格納手段を検索して判別するようにしたことを特徴とする承認ワークフロー管理方法。
4. 帳票の利用を許可する実行権の登録が、表示処理、印刷処理、検索処理、及び、編集処理の個々の実行の可否として、実行権定義情報格納手段において、実行権ＩＤ毎に個別に予め設定され、
   請求項１乃至請求項３のいずれか１つの前記ユーザ定義が、前記参照権の登録に加えて、該実行権ＩＤを用いて、ユーザ定義情報格納手段において、該当の実ユーザのユーザＩＤをキーとして設定し登録するものであることを特徴とする承認ワークフロー管理方法。
5. 請求項２乃至請求項４のいずれか１つにおいて、前記仮想ユーザ定義情報格納手段の登録が、個々の仮想ユーザＩＤに対して、前記ユーザＩＤを用いて直接的に、又は前記実行権ＩＤを用いて間接的に設定することで、承認者候補に対する実ユーザの対応付けを登録するものであることを特徴とする承認ワークフロー管理方法。
6. 該当の帳票を順に回覧して承認を得ていくワークフローの承認者の選定や順序を設定登録することができる承認ワークフロー管理装置において、
   回覧して承認を得ていく対象となる帳票の承認を行う、承認者となる個々の実ユーザについて、帳票のファイルアクセスを許可する定義登録を行う参照権定義情報格納手段と、
   前記実ユーザについて、帳票の利用を許可する実行権の定義登録を行うユーザ定義情報格納手段と、
   前記ワークフローの設定登録の際に、承認者候補として設定登録するために用いる仮想ユーザＩＤを登録する仮想ユーザ定義情報格納手段と、
   該当の回覧承認帳票を順に閲覧し承認する承認者を、前記仮想ユーザＩＤにより登録するワークフロー定義情報格納手段と、を備え、
   閲覧承認をする実ユーザは、ワークフロー定義情報格納手段に登録されている前記仮想ユーザＩＤをキーとして、前記仮想ユーザ定義情報格納手段を検索して判別するようにしたことを特徴とする承認ワークフロー管理装置。
7. 請求項６において、
   更に、個々の実行権ＩＤに対して、表示処理、印刷処理、検索処理、及び、編集処理の実行の可否を個別に、設定登録する実行権定義情報格納手段を備えると共に、
   前記ユーザ定義情報格納手段は、前記実ユーザのそれぞれのユーザＩＤに対して、上記実行権ＩＤを設定登録することで、前記実ユーザについて、帳票の利用及びその種類を許可する実行権の定義登録を行うものであることを特徴とする承認ワークフロー管理装置。
8. 請求項１乃至請求項５のいずれか１つに記載の承認ワークフロー管理方法、請求項６に記載の承認ワークフロー管理装置、又は請求項７に記載の承認ワークフロー管理装置を実現するためのコンピュータ・プログラム。

Images