JP2006338140A - ワークフロー処理プログラム - Google Patents

Abstract

【課題】 社員の異動を含む組織変更があった場合でも、従来のようにシステムを停止させることなく、またユーザが組織構成を意識せずにワークフローを運用する。
【解決手段】 ワークフロー処理プログラムは、社員の異動を含む組織変更を考慮して社員毎の所属部門と役職との定義に基づいて各部門毎に階層構造として組み立てられた組織変更前後の組織情報が少なくとも年月毎に予めデータベース１２に登録されており、コンピュータに対してデータベース１２に登録された年月毎の組織情報のうちデータ申請時に運用している組織情報に基づく組織構成に従った申請データの提出経路を確定する機能を実現させる。
【選択図】 図１１

Description

本発明は、例えば売上や経費を含め、個人・組織に係わる各種データ（経営情報）を一元管理するシステムに採用され、特にデータの申請時に組織構成に基づくデータの提出経路を自動的に算出設定し、社員の異動（異なる部署への移動）を含む組織変更があった場合でもユーザが組織構成を意識することなく、業務に関する情報の流れ（ワークフロー）の処理を組織構成に従って運用することができるワークフロー処理プログラムに関するものである。

複数の部門からなる組織構成において、例えば時間外勤務、立替精算などのように、審査・承認が必要な書類を提出する場合には、予め決められた書式に従って作成された書類に必要事項を記入し、この書類を例えば自身が所属する部門の上長に提出し、所定の提出経路（審査・承認経路）を経て最終的に総務や管理部門に提出されるといったように、紙媒体ベースによって書類の提出を行うことが一般的になされている。

しかし、上述した紙媒体ベースによる書類の提出では、提出する書類の種類によっては審査・承認を行う提出経路も異なるため、書類を回覧する過程において書類自体を紛失したり、書類の内容が外部に漏洩するおそれもあり、処理の迅速化やセキュリティ面において課題があった。

このような従来の紙媒体ベースによる書類提出の課題を解消すべく、書類の提出経路をシステム上で実現するものとして、例えば下記特許文献１に開示されるようなワークフローシステムが知られている。

この特許文献１に開示されるワークフローシステムでは、ワークフローサーバが、組織における役割名と該役割名に対応するユーザを定義する役割実ユーザ対応情報を役割実ユーザ対応情報に各ユーザ毎に登録しておき、ワークフロークライアントからの承認要求に応じて、ワークフロークライアントから指示される伝票データの次承認者の役割名に対応するユーザを、承認要求したユーザに対応する役割実ユーザ対応情報に基づいて特定するとともに、この特定された伝票データの次承認者の役割名に対応するユーザを変更する構成としている。

これにより、ワークフロー管理者の管理負担を軽減し、フローする経路を役割で停止することで、不慣れなユーザでも容易に使用でき、伝票が本来通るべき経路を逸脱する等の事態の発生を抑えている。
特開２００４−１７８１４５号

しかしながら、上述した特許文献１に開示される従来のワークフローシステムは、各申請者側で情報管理・メンテナンスする仕組みについてのアプローチであり、組織所属者全員に組織状況の適切な理解が求められる。このため、データ（文書データ、書類データ、伝票データ等を示す。以下同様）の申請を行う際には、自分が誰の上長で、誰が自分の部下かを意識して運用する必要があり、組織変更があった場合には組織構成の変更に伴う経路情報の特定が明確でなく、データの申請を行った時点での組織構成による提出経路が確保できていないという問題があった。

また、この種のワークフローシステムは、従来、紙媒体ベースで行われていた、書類の提出経路をシステム上で実現することにより、データの紛失やデータの漏洩といったセキュリティ面への不安を解消するとともに、書類提出の高速化を可能として従来より存在しているが、これらは個々の対象文書に個別対応した状態管理を行っており、組織構成の階層に対応した進捗管理・表示による提出状況の確認を行うことができなかった。

そこで、本発明は上記問題点に鑑みてなされたものであって、第一に、社員の異動を含む組織変更があった場合でも、従来のようにシステムを停止させることなく、またユーザが組織構成を意識せずにワークフローを運用することができ、更には組織を構成する各部門毎の階層に応じた申請データの提出状況を表示画面上で容易に把握することができるワークフロー処理プログラムを提供することにある。

上記目的を達成するため、本発明の請求項１に記載されたワークフロー処理プログラムは、社員の異動を含む組織変更を考慮して社員毎の所属部門と役職との定義に基づいて各部門毎に階層構造として組み立てられた組織情報を組織変更に対応して少なくとも組織変更前の組織情報と組織変更後の組織情報とが予めデータベースに登録されており、
コンピュータに対して前記データベースに登録された組織情報のうち現在運用している組織変更後の組織情報に関わらず、データの申請時に運用していた組織情報に基づく組織構成に従った申請データの提出経路を確定する機能を実現させることを特徴とする。

請求項２に記載されたワークフロー処理プログラムは、社員の異動を含む組織変更を考慮して社員毎の所属部門と役職との定義に基づいて各部門毎に階層構造として組み立てられた組織変更前後の組織情報が少なくとも年月毎に予めデータベースに登録されており、
コンピュータに対して前記データベースに登録された年月毎の組織情報のうちデータの申請時に運用している組織情報に基づく組織構成に従った申請データの提出経路を確定する機能を実現させることを特徴とする。

請求項３に記載されたワークフロー処理プログラムは、請求項１または請求項２のワークフロー処理プログラムにおいて、
前記データの申請時の段階で運用していた組織情報を前記データベースから取得し、この取得した組織情報を基にデータ種別に応じて当該申請されたデータの提出経路を決定する機能を実現させることを特徴とする。

請求項４に記載されたワークフロー処理プログラムは、請求項１乃至請求項３の何れかのワークフロー処理プログラムにおいて、
前記組織情報の各部門の階層毎に申請データの提出状況を表示する機能を実現させることを特徴とする。

本発明によれば、従来のような組織変更に伴ってシステムを停止することなく、新旧の組織情報がオーバラップした運用が可能となり、組織変更があっても、データの申請時点で有効な組織構成に従った提出経路に切り替えてデータの申請や審査・承認が行える。

また、従来確認できなかった申請データの提出状況も、組織構成に従った表示によって容易に把握できる。

以下、本発明の実施の形態を図面を参照しながら具体的に説明する。図１は本発明に係るワークフロー処理プログラムが実行されるネットワーク形態の一例を示す概念図、図２は本例においてデータベースに登録される新旧の組織情報の概略構成図、図３は組織情報と各種情報（部情報、課情報、グループ情報、社員情報、役員情報、兼務情報）との関係図、図４は組織情報と社員情報、部情報、課情報、グループ情報との関係を示す概念図、図５は組織情報と社員情報、役員情報、兼務情報との関係を示す概念図、図６は本例のワークフロー処理プログラムを実行する際のログイン時の表示画面例を示す図、図７〜図１０はログイン後にメニュー表示される表示内容の一例を示す図、図１１は組織変更時の処理内容の一例を示す図、図１２および図１３はデータの申請時における処理内容を説明するためのフローチャート、図１４は組織変更時の処理の流れを示す概略図、図１５は組織変更時の具体例を示す図、図１６は新旧の組織情報の選択画面の一例を示す図、図１７および図１８は図１６において選択された新旧の組織情報に基づく申請データの提出状況画面の一例を示す図、図１９は提出状況画面から選択される項目の詳細情報の表示例を示す図、図２０は権限委譲の概略説明図、図２１は代理ログインの概略説明図である。

本例のワークフロー処理プログラム（以下、単に処理プログラムとも言う）は、例えば売上や経費を含め、個人・組織に係わるデータなどで構成される企業の経営情報を一元管理するシステムにおいて、特に社員の異動（異なる部署への移動）を含む組織変更前後の組織情報（旧組織情報、新組織情報）をデータベース化し、データの申請時に、その時点で申請者に有効な組織情報（データの申請時に運用している組織情報）の組織構成に従ったデータの提出経路（審査・承認経路）を自動的に算出設定している。これにより、社員の異動を含む組織変更があった場合でもユーザがこれを意識することなく運営できるシステムを実現している。

本例の処理プログラムは、例えば図１に示すように、クライアントとなる複数のユーザ端末１と、サーバ２とがイントラネット３を介して相互にデータ通信可能に接続されたネットワークシステムに採用することができる。

ユーザ端末１は、例えば組織を構成する各部門単位、各部門の職位に応じた階層（例えば課、グループなど）単位、個人単位で配設される端末であり、ユーザがシステムにログインしてサーバ２にアクセスすることにより、データの申請や審査・承認を含め、各種データの送受信をサーバ２との間で行う際に操作される。

サーバ２は、Ｗｅｂサーバ２ａとデータベースサーバ２ｂを有している。Ｗｅｂサーバ２ａは、イントラネット３やインターネットで公開するＷｅｂページのデータを保存し、ユーザ端末１のＷｅｂブラウザなどからの要求に従ってＨＴＭＬなどのファイルをＨＴＴＰで送信するサーバである。

データベースサーバ２ｂは、本例の処理プログラムが取り扱う後述するデータベース１１のデータ更新、検索、削除などを処理するサーバであり、Ｗｅｂサーバ２ａのバックグランドで稼働する。

尚、本例では、同一サーバで申請者や審査・承認者（ユーザ：各社員）が同一ファイルを取り扱うため、データの申請や審査・承認処理に関して例えば公開鍵暗号発生装置を用いた暗号化処理の必要がないネットワーク構成となっているが、例えば図１において、イントラネット３と他の外部ネットワーク（複数の端末やサーバなどで構成）との間がファイアウォールにより保護した状態でインターネットを介して接続し、ユーザ端末１やサーバ２と他の外部ネットワークとの間で相互にデータ通信することも可能である。その際、データに暗号化処理を施したり、ユーザ企業が通信事業者のＶＰＮサービスを介して接続するＶＰＮにより各支社や各支店との間でデータ通信を行うことができる。また、図１は本例の処理プログラムが採用されるネットワーク形態の一例であって、図示のものに限定されるものではない。

ところで、本例では、組織を構成する社員に対して、社員毎の部門コードと役職を定義し、企業の組織情報を組み立てる構成となっている。また、部門コードは、部・課・グループを階層的に構成する仕組みを持ち、各社員に所属する部門コードを設定するデータ構造となっている。

また、組織の複数の部門を構成する要素の部には、その部に従属する複数の課を定義することが可能なデータ構造となっている。同様に、課には、その課に従属する複数のグループを定義することが可能なデータ構造となっている。さらに、各部門（部・課・グループ）には、役職を明らかにする部門長を定義する仕組みを持ち、部・課に複数の管理者と部門長の兼務者を定義することができる仕組みを持つデータ構造となっている。

そして、本例では、各社員の所属部門と所属長のデータ関連から、データの申請時の提出経路（審査・承認経路）を自動的に確定し、組織におけるデータ運用、管理を簡易化させている。また、本例では、組織情報を少なくとも月毎にデータ管理し、データの申請時点での組織構成（データの申請時に運用している組織情報に基づく組織構成）に従った提出経路（審査・承認経路）でデータを管理・運用できるデータ構造となっている。

次に、上記データ構造を実現するためにデータベースサーバ２ｂに予め登録されるデータベース１１について図２〜図５を参照しながら説明する。

データベース１１は、人事権を持つ総務や管理者によって予めデータベースサーバ２ｂに登録される。このデータベース１１は、予め書式化されたフレーム構造に従って１件ずつ登録する他、フレーム構造に合わせて作成された各種情報をファイル化してインポートすることにより複数件纏めて一括登録することもできる。また、データの申請時には、そのデータに基づいて申請情報１３（図１１、図１４に図示）が作成され、データベース１１に記憶される。

データベース１１には、組織情報１２、申請情報１３、経路情報１４（図１１、図１４に図示）を含む各種情報が記憶される。組織情報１２は、図２に示すように、社員の異動（異なる部署への移動）を含む組織変更がある度に登録され、最新の組織情報（図２の例では、年月（１）、（２）…（ｎ）の組織）から過去に遡って月毎に保存されている。尚、本例では、システムの時間管理により月初（予め管理者が設定した運用開始日）に新組織によるシステムの運用を行うことを前提として、組織情報１２が最新の年月から遡って年月単位に登録されているが、更に最新の年月日から遡って年月日単位に登録することも可能である。

そして、組織構成として、複数の各部門が例えば部、課、グループ、役員に分かれている場合、各年月毎の組織情報１２は、図２に示すように、まず各部毎にその部に従属する課やグループの情報を含み、また各課毎にその課に従属するグループの情報を含み、さらに各グループ毎にそのグループに従属するグループ長とグループメンバの情報を含んでいる。また、これらとは別に各役員毎の情報が各組織情報１２には含まれている。さらに、図２に示すように、各社員の情報には、部門情報（部、課、グループ）、役職、兼務の情報が含まれている。

すなわち、本例では、組織を構成する複数の部門がその部門毎に職位に応じた階層間（上位階層と下位階層との間）でデータの関連付けがなされて各月毎の組織情報１２を構成するデータ構造となっている。

さらに説明すると、各月毎の組織情報１２は、図３〜図５に示すように、社員情報１２ａ、部情報１２ｂ、課情報１２ｃ、グループ情報１２ｄ、役員情報１２ｅ、兼務情報１２ｆとの間で関連付けされて構成される。

社員情報１２ａは、社員個人単位の情報であり、図３および図４に示すように、例えば社員ＩＤ、氏名、等級、勤務先、入社年度、電話番号（ＴＥＬ）、Ｅ−Ｍａｉｌアドレス、原価、売価などの情報で構成される。この社員情報１２ａは、図４および図５に示すように、社員ＩＤによって組織情報１２との間が関連付けされている。

部情報１２ｂは、社員が所属する部門の情報であり、図３に示すように、例えば部毎に固有の部ＩＤおよび部コード、部名称、部種別、部が発足された部年月などの情報で構成される。この部情報１２ｂは、図４に示すように、部ＩＤによって組織情報１２との間が関連付けされている。

課情報１２ｃは、社員が所属する課の情報であり、図３に示すように、例えば課毎に固有の課ＩＤおよび課コード、課名称、その課が属する部の部ＩＤ、課種別、課が発足された課年月などの情報で構成される。この課情報１２ｃは、図４に示すように、課ＩＤによって組織情報１２との間が関連付けされている。また、課情報１２ｃは、部ＩＤによって部情報１２ｂとの間が関連付けされている。

グループ情報１２ｄは、社員が所属するグループの情報であり、図３に示すように、例えばグループ毎に固有のグループＩＤおよびグループコード、グループ名称、グループが属する部の部ＩＤおよび課の課ＩＤ、グループが発足されたグループ年月などの情報で構成される。このグループ情報１２ｄは、図４に示すように、グループＩＤによって組織情報１２との間が関連付けされている。また、グループ情報１２ｄは、部ＩＤによって部情報１２ｂとの間が関連付けされるとともに、課ＩＤによって課情報１２ｃとの間が関連付けされている。

役員情報１２ｅは、役員に関する情報であり、図４に示すように、例えば役員毎に固有の役職ＩＤ、役職名称などの情報で構成される。この役員情報１２ｅは、図５に示すように、役職ＩＤによって組織情報１２との間が関連付けされている。

兼務情報１２ｆは、１人の社員が複数の役職を兼務する場合の情報であり、図４に示すように、例えば兼務毎に固有の兼務ＩＤ、兼務名称などの情報で構成される。この兼務情報１２ｆは、図５に示すように、兼務ＩＤによって組織情報１２との間が関連付けされている。

尚、データベース１１における組織情報１２は、組織構成に応じて変わるものであり、図２〜図５に示す情報に特に限定されるものではない。

次に、図１４を用いて、申請情報１３、経路情報１４を説明する。
申請情報１３は、システムへのログイン後にユーザがデータの申請を行ったときの情報に基づいて作成されるもので、例えば申請種別、申請年月、申請者ＩＤ、申請者組織情報、審査・承認ルート情報、審査・承認ステータスＩＤ等で構成される。

申請種別は、システムへのログイン後にユーザが申請したデータの種類を示す情報である。申請年月日は、データが申請された年月日の情報である。申請者ＩＤは、ログイン後にデータを申請したユーザを特定する情報（例えば社員ＩＤ）である。申請者組織情報は、データを申請したユーザが所属する組織の情報（例えば部、課、グループなど）である。

審査・承認ルート情報は、申請種別を基に設定された経路情報１４の承認役職ＩＤによるルート情報である。審査・承認ステータスＩＤは、申請されたデータに対する役職毎の審査・承認の有無を示す情報である。この審査・承認ステータスＩＤは、対象者のログイン時における審査・承認の有無に応じて書き換えられる。

経路情報１４は、申請時のデータ種別に応じた最終提出先までの経路を示す情報として、例えば申請種別、担当部門ＩＤ、承認役職ＩＤ等で構成される。

申請種別は、申請情報１３の申請種別と同一のもので、ユーザがシステムにログインしてデータの申請を行ったときの情報から取得される。担当部門ＩＤは、最終的な審査・承認先となるワークフローの最終担当部門に関する情報である。承認役職ＩＤは、管理部門（担当部門）が役職（職位）によって定義して決定するワークフローのルート情報（例：一般→グループ長→課長→部長→担当部門、一般→グループ長→課長→担当部門、グループ長→課長→部長→担当部門、課長→部長→担当部門、部長→担当部門など）である。

尚、設定されるワークフローは申請種別によって異なる。また、ワークフローは上位の部門長、すなわち人としてではなく、上位部門情報として設定するため、上位部門に属する全社員が審査・承認権限を持つことになる。

次に、本例の処理プログラムが実行する各種処理内容について図６〜図２１を参照しながら説明する。

図６はユーザがシステムにログインして本例の処理プログラムを実行する場合のログイン画面２１を示している。クライアントとなるユーザ端末１からシステムにログインしてサーバ２にアクセスする場合には、例えば図６に示すようなログイン画面２１が表示される。ログイン画面２１には、例えばユーザＩＤ、パスワード、代理ＩＤの入力項目２２がある。システムへのログイン時には、ログイン画面２１上のユーザＩＤ（後述する代理ログインを行う場合には代理ＩＤを含む）とパスワードに各々必要事項を入力する。

そして、システムへのログイン後、ログインした申請者（ユーザ）に関係する組織変更が無ければ、ログインした申請者が所属する組織に従ったメニューが一覧表示される。

図７〜図１０は一覧表示されるメニューの表示内容の一例を示している。図７は例えば勤怠情報、時間外勤務、休暇取得状況、プロジェクト、製番振替、給与明細／賞与明細、立替・経費精算などの全社員が使用する全社員用メニュー、図８は例えば予算、社員情報、資格情報、長時間残業管理、有給休暇管理、組織情報、総務保守、給与明細／賞与明細などの総務部門が管理に使用する総務部門メニュー、図９は例えば製番振替依頼書、仕掛品増減表、収支実績表、予算、諸表読込、検収表示、原価計算、立替・経費精算などの経理部門が管理に使用する経理部門メニュー、図１０は売上予定表、検収、プロジェクト管理、顧客管理、顧客別単金などの営業部門が管理に使用する営業部門メニューであり、各項目がさらに細分化されて階層表示される。尚、各図における太線で囲んだ部分のメニューは、ワークフローに係わるメニューである。

また、本例では、システムへのログイン後、ログインした申請者（ユーザ）に関係する組織変更が有れば、その申請者による処理が有効な組織変更前後の新・旧組織情報に従った職務選択画面２３が表示される。さらに説明すると、本例では、社員の異動を含む組織変更が生じた場合でも、システムを停止せずに旧組織情報と新組織情報でのオーバーラップしたシステムの運用を可能にしている。このため、組織変更が申請者に関係する場合には、その申請者による処理が有効な新・旧組織情報に従った職務を選択するための職務選択画面２３が表示される。

図１１は申請者Ａが２００５年ｎ−１月（旧組織）の時点ではグループ１に所属し、翌月の２００５年ｎ月（新組織）にグループ２に異動になった場合の職務選択画面２３の表示例である。図１１の例では、申請者Ａによる有効な権限選択として、新組織情報に基づく職務選択項目「２００５／ｎ グループ２ 申請者Ａ」と、旧組織情報に基づく職務選択項目「２００５／ｎ−１ グループ１ 申請者Ａ」とが職務選択画面２３に表示される。

そして、図１１において、ユーザが職務選択項目「２００５／ｎ−１ グループ１ 申請者Ａ」を選択すると、データベース１１の組織情報１２の中から旧組織情報（２００５年ｎ−１月）による旧組織の各役職に従った、「申請者Ａ」→「グループ長Ｂ」→「課長Ｃ」→「部長Ｄ」→「役員Ｅ」→「担当部門」の提出経路からなるワークフローが選択設定される。尚、ワークフロー（提出経路）の自動算出処理については後述する。

これに対し、ユーザが職務選択項目「２００５／ｎ グループ２ 申請者Ａ」を選択すると、データベース１１の組織情報１２の中から新組織情報（２００５年ｎ月）による新組織の各役職に従った、「申請者Ａ」→「グループ長Ｆ」→「課長Ｇ」→「部長Ｈ」→「役員Ｅ」→「担当部門」の提出経路からなるワークフローが選択設定される。

そして、ユーザが図１１に示すような職務選択画面２３から職務選択項目を１つ選択して実行した場合には、上述したログイン時に有効な組織情報に従ったワークフローが選択設定され、その職務選択項目を選択したときに有効なメニュー（図７〜図１０に示すようなログインしたユーザに関係するメニュー）が一覧表示される。

次に、データの申請時におけるワークフロー（提出経路）の自動算出処理について図１２および図１３のフローチャートを参照しながら説明する。例えば図１のネットワークシステムにおいて、ユーザがユーザ端末１からシステムにログインしてサーバ２にアクセスし、所定のデータの申請を行うと、サーバ２ではこのデータの申請時の画面情報、ログイン時の申請者情報に基づいて申請情報（申請されたデータの申請種別、申請年月、申請者ＩＤ、申請者が所属する申請者組織情報）１３を作成してデータベース１１に記憶する（ＳＴ１）。

次に、データベース１１に記憶された申請情報１３から申請種別、申請年月、申請者組織情報を取得する（ＳＴ２）。続いて、データが申請された申請年月の段階で有効な新・旧の組織情報１２をデータベース１１から取得する（ＳＴ３）。次に、申請種別、申請者組織情報と、データベース１１から取得した組織情報１２とを基に経路情報１４に沿った審査・承認ルート情報を取得する（ＳＴ４）。そして、取得した審査・承認ルート情報を申請情報１３に登録する（ＳＴ５）。

その後、申請情報１３の審査・承認ステータスＩＤを提出状態に設定する（ＳＴ６）。そして、以下では、審査・承認が必要な職位（例えば部長、課長、グループ長など）としてワークフローの提出経路を自動的に確定している。まず、本例では、グループ長の審査・承認が必要か否かを審査・承認ルート情報に基づいて判別する（ＳＴ７）。すなわち、グループ長が審査・承認ルート情報によるワークフロー上に存在するか否かを判別する。そして、グループ長の審査・承認が必要と判断すると、グループ長の審査・承認か差戻しかを審査・承認ステータスＩＤに基づいて判別する（ＳＴ８）。ここで、グループ長へ差戻しと判断すると、処理を終了して申請情報作成前のステップに戻る。グループ長の審査・承認済みと判断すると、課長の審査・承認が必要か否かを審査・承認ルート情報に基づいて判別する（ＳＴ９）。尚、ＳＴ７において、グループ長の審査・承認が必要無しと判断すると、ＳＴ９の処理に移行する。

ＳＴ９において、課長の審査・承認が必要と判断すると、課長の審査・承認か差戻しかを審査・承認ステータスＩＤに基づいて判別する（ＳＴ１０）。ここで、課長へ差戻しと判断すると、処理を終了して申請情報作成前のステップに戻る。課長の審査・承認済みと判断すると、部長の審査・承認が必要か否かを審査・承認ルート情報に基づいて判別する（ＳＴ１１）。尚、ＳＴ９において、課長の審査・承認が必要無しと判断すると、ＳＴ１１の処理に移行する。

ＳＴ１１において、部長の審査・承認が必要と判断すると、部長の審査・承認か差戻しかを審査・承認ステータスＩＤに基づいて判別する（ＳＴ１２）。ここで、部長へ差戻しと判断すると、処理を終了して申請情報作成前のステップに戻る。部長の審査・承認済みと判断すると、役員の審査・承認が必要か否かを審査・承認ルート情報に基づいて判別する（ＳＴ１３）。尚、ＳＴ１１において、部長の審査・承認が必要無しと判断すると、ＳＴ１３の処理に移行する。

ＳＴ１３において、役員の審査・承認が必要と判断すると、役員の審査・承認か差戻しかを審査・承認ステータスＩＤに基づいて判別する（ＳＴ１４）。ここで、役員へ差戻しと判断すると、処理を終了して申請情報作成前のステップに戻る。役員の審査・承認済みと判断すると、最終提出先である担当部門の審査・承認か差戻しかを審査・承認ステータスＩＤに基づいて判別する（ＳＴ１５）。そして、差戻しと判断すると、処理を終了して申請情報作成前のステップに戻り、審査・承認済みと判断すると、処理を終了する。以上の処理によってワークフローの提出経路が確定される。

次に、データの申請時に組織変更があった場合の処理について図１４を参照しながら説明する。

上述したデータの申請時の処理の結果、例えば図１４に示すように、ユーザが申請するデータの申請種別が「ｎ−１月分」、すなわち「ｎ−１月」に申請したデータであれば、データベース１１に登録された組織情報１２のうち、「ｎ−１月組織情報」に従ったワークフローが選択される。図１４の例の場合、「ｎ−１月組織情報」において、申請者Ａは、役員Ｅが担当する組織の部１（部長Ｄ）、課１（課長Ｃ）、グループ１（グループ長Ｂ）に所属するので、「申請者Ａ」→「グループ長Ｂ」→「課長Ｃ」→「部長Ｄ」→「役員Ｅ（代表取締役等）」→「担当部門」の順に設定された提出経路が申請データのワークフローとして選択設定される。尚、上記「担当部門」とは、申請データの最終提出先を示している。

これに対し、ユーザが申請するデータの申請種別が翌月の「ｎ月分」、すなわち「ｎ月」に申請したデータであれば、データベース１１に登録された組織情報１２のうち、「ｎ月組織情報」に従ったワークフローが選択される。図１４の例の場合、「ｎ月組織情報」において、申請者Ａは、「ｎ−１月組織情報」のときと同一の役員Ｅが担当する組織の部２（部長Ｈ）、課２（課長Ｇ）、グループ２（グループ長Ｆ）に所属するので、「申請者Ａ」→「グループ長Ｆ」→「課長Ｇ」→「部長Ｈ」→「役員Ｅ（代表取締役等）」→「担当部門」の順に設定された提出経路が申請データのワークフローとして選択設定される。尚、上記「担当部門」とは、申請データの最終提出先を示している。

ここで、更に組織変更時の具体例について図１５を参照しながら説明する。図１５は組織変更があった場合のワークフローの切り替わりの具体例を示している。図１５の例では、組織変更前の２００５年４月において、申請者Ａは、開発部（部長Ｄ）、ＡＥＡ１（課長Ｃ）、ＡＥＡ１１（グループ長Ｂ）に所属する社員であった。そして、組織変更後の２００５年５月において、申請者Ａは、営業部（部長Ｈ）、ＡＥＳ１（課長Ｇ）、ＡＥＳ１１（グループ長Ｆ）に所属する社員に組織異動となった。尚、役員Ｅは組織変更前後における移動でも変わらない。

この例では、申請者Ａがシステムにログインしてデータの申請を行うと、職務選択画面２３の職務選択項目として「２００５／５ ＡＥＳ１１ 申請者Ａ」と「２００５／４ ＡＥＡ１１ 申請者Ａ」が表示される。

ここで、申請者Ａが職務選択画面２３から「２００５／４ ＡＥＡ１１ 申請者Ａ」の職務選択項目を選択すると、組織変更前の旧組織情報に従ったワークフローの提出経路が「ＡＥＡ１１ 申請者Ａ」→「ＡＥＡ１１ グループ長Ｂ」→「ＡＥＡ１ 課長Ｃ」→「開発部 部長Ｄ」→「役員Ｅ」→「担当部門」に自動設定される。

これに対し、申請者Ａが職務選択画面２３から「２００５／５ ＡＥＳ１１ 申請者Ａ」の職務選択項目を選択すると、組織変更後の新組織情報に従ったワークフローの提出経路が「ＡＥＳ１１ 申請者Ａ」→「ＡＥＳ１１ グループ長Ｆ」→「ＡＥＳ１ 課長Ｇ」→「営業部 部長Ｈ」→「役員Ｅ」→「担当部門」に自動設定される。

尚、組織情報１２のうち旧組織情報に基づくデータの有効期限は、そのデータに関する処理の決定権を持つ管理部門（例えば総務部門の管理者）の判断により締め処理が行われるまで継続する。また、データの有効期限が切れ、提出経路（審査・承認経路）上に存在しない責任者が出た場合には、データ責任部門長が処理を行える仕組みとなっている。

このように、本例では、組織変更が生じた場合にデータの申請があっても、従来のようにシステムを停止することなく、旧組織と新組織とのオーバーラップした運用を可能にしている。

次に、申請データの提出状況の表示処理について図１６〜図１９を参照しながら説明する。図１６の例では、組織変更前の「２００５年４月組織」（旧組織）において、部が部１、部２から構成されている。そして、部１に従属する課が課１１と課１２から構成され、課１１に従属するグループがグループＡ，Ｂから構成され、課１２に従属するグループがグループＣ，Ｄ，Ｅから構成されている。また、部２に従属する課が課２１、課２２、課２３から構成され、課２１に従属するグループがグループＦから構成され、課２２に従属するグループがグループＧ，Ｈから構成され、課２３に従属するグループがグループＩから構成されている。

これに対し、組織変更後の「２００５年５月組織」（新組織）では、部が部１、部２、部３から構成されている。そして、部１に従属する課が課１１から構成され、課１１に従属するグループがグループＡ，Ｂ，Ｃから構成されている。また、部２に従属する課が課２１と課２２から構成され、課２１に従属するグループがグループＤから構成され、課２２に従属するグループがグループＥから構成されている。さらに、部３に従属する課が課３１から構成され、課３１に従属するグループがグループＦ，Ｇ，Ｈ，Ｉから構成されている。

そして、上記組織変更前後における申請データの提出状況を表示により確認する場合には、システムへのログイン後のメニュー画面から提出状況の表示に関するメニュー（例えば図１６に示す「社内経営情報システム」メニュー２４）を選択する。図１６の「社内経営情報システム」メニュー画面の例では、提出状況一覧画面を表示する際の組織の年月を指定する入力画面が表示される。図１６の例では、年として「２００５」を選択し、月として「４」又は「５」を選択すれば、図１７又は図１８に示すような指定された年月の組織情報に従った申請データの提出状況一覧画面２５が表示される。

図１７は図１６のメニュー画面２４において、年として「２００５」、月として「４」を選択したときのデータの提出状況一覧画面２５の表示例を示している。この提出状況一覧画面２５には、画面上の左側から部、課、グループの職位に応じた階層順に各々名称と対象者（人数）とが表示され、さらに各階層毎に更新日時とステータスが表示される。ステータスは、例えば担当者提出済み、グループ長差戻し、グループ長承認済み、グループ長提出済み、課長差戻し、課長承認済み、課長提出済み、部長差戻し、部長承認済み、部長提出済みなど、データ提出の有無や審査・承認の有無が階層単位の進捗状況を示している。尚、この提出状況一覧画面２５において、提出必須者を提出情報（データ）に応じて色分け表示することもできる。また、図１７や図１８の提出状況一覧画面２５において、下線が施された項目（例えば部１、課１１、グループＡ等）を選択すれば、選択された項目に対する詳細情報が羅列された詳細情報画面２６が表示される。この詳細情報画面２６には、図１９に示すように、例えば対象者、更新日時、ステータス、電話番号、Ｅ−Ｍａｉｌアドレスが対象者毎に一覧表示される。

尚、上述した申請データの提出状況一覧画面２５は、セキュリティ面を考慮して、管理部門（システム管理部門や人事権を有する総務部門など）のみに権限を持たせるのが好ましいが、システムにログインする全てのユーザ（全社員）に権限を持たせることも可能である。この場合には、各社員が、自分を含めて申請されたデータの進捗状況を容易に把握することができる。

次に、権限委譲時の処理内容について図２０を参照しながら説明する。権限委譲は、例えば外出等の不在時に、自身の権限を他社員へ移行するもので、委譲期間を設定して運用される。

具体的に、図２０は部１の部長である社員Ａから同じ部１の課１の課長である社員Ｂに権限委譲された例を示している。この場合、部１の部長である社員Ａの部長権限が社員Ｂに付与される。これにより、社員Ｂは、部１の部長と課１の課長を兼任し、委譲期間を設定して部長権限が社員Ａから委譲される。そして、設定された委譲期間を超過した後は、社員Ｂにおける「部１：部長」の情報が破棄される。尚、本例では、権限を委譲する社員が所属する部下にのみ委譲可能としている。

次に、代理ログイン時の処理内容について図２１を参照しながら説明する。代理ログインは、同一部門に属する部下のみ可能とし、同一部門でも同一メンバレベル（社員レベル）では代理ログインを不可能としている。

具体的には、図２１に示すように、部１の社員Ａ、部１内に従属する課１の社員Ｂ、さらに課１内に従属するグループ１の社員Ｃは、同一の部１・課１に従属するグループ１内のメンバである社員Ｄ，Ｅ，Ｆに代理ログインが可能となっている。これに対し、同一グループ１内でもメンバレベルである社員Ｄ，Ｅ，Ｆ間では代理ログインが不可能となっている。そして、代理ログインを行った場合には、その作業内容の履歴が作業履歴情報として記憶される。具体的には、図２１に示すように、対象社員ＩＤ、変更年月日、変更箇所、変更内容、編集社員ＩＤ、編集社員役職ＩＤ、修正日時が作業履歴情報として記憶される。

以上説明した処理を実行する本例の処理プログラムは、コンピュータに上述した各種処理を実行させるためのプログラムとしてシステムを構築する各種コンピュータ（端末）にインストールされる他、コンピュータ読み取り可能な各種記憶媒体に記憶することもできる。

このように、本例の処理プログラムによれば、データの申請時や審査・承認時の組織の定義に従って申請データの提出経路に必要なワークフローを正確に運用することができる。しかも、組織情報に変更が生じた場合でも、新・旧組織情報に従ったワークフローを持って運用することができるので、従来のような組織変更に伴ってシステムを停止することなく運用切替を行うことができる。

すなわち、本例では、ログイン後に、ログインしたユーザによる処理が有効な組織情報（データの申請時に運用している組織情報）に従った新組織と旧組織のワークフローをユーザが選択して用いることができる。そして、申請者や審査承認者はユーザ端末からシステムにログインした際に、新組織又は旧組織の選択のみを行うことで、ユーザが組織構成について意識することなくデータの提出経路に対する配慮は全てシステムに依存することが可能となっている。これにより、基本的には、全社にまたがる多くのデータ（個人データを含む）を管理部門が一括して収集するためのシステムを簡易化することができる。

そして、本例では、ログイン時に有効な組織情報（データの申請時に運用している組織情報）に従った提出経路（ワークフロー）が自動設定されるので、データの申請時に申請者が審査・承認者を特定することなく運用することができる。すなわち、データ申請時には、自分が誰の上長で誰が自分の部下かを意識せず、組織構成が変わっても自分が所属する部門に申請するイメージでデータの申請を行うことができる。その際、申請するデータは、組織構成上の単位でまとめ、申請時に構成されている組織メンバ及び部門単位で管理し、組織情報を基に最終的には担当部門（例えばデータ収集部門やデータ管理部門）によって審査・承認される。これにより、例えば勤務データや残業データなどのようなほぼ全社員が管理部門（例えば総務など）に申請しなければならないときでも、個人単位だけではなく、組織情報に基づいた各部門単位や各部門の階層単位のまとまったデータとして見ることができる。

また、組織変更時には、ユーザが新旧の組織を使い分けることも可能であり、これにより組織の大変更（例えば部門消滅や新規設立）にも、新旧組織単位のデータ管理が可能となる。

ここで、データは、全社及び多くの部門に申請と審査・承認を必要とする組織構成単位に管理された勤務データ、残業申請データ等の文書、書類、伝票に関するデータを対象とし、管理部門における組織変更や人事異動といった組織構成上の変化に依存されず、正確な運用を実現することができる。

しかも、同一サーバで申請者、審査・承認者が同一データ（例えばファイル等）を扱うので、審査・承認処理に関して公開鍵暗号発生装置を要する暗号化の必要性がなく、また審査・承認の伝達に関する状況も表示画面上で確認可能なので、特別な通信手段を用いる必要性もない。

また、不在時のワークフロー運用を回避するため、権限委譲、代理ログインを用いることで、上述した新・旧切り替え機能との組合せにより、組織変更直後や、ルート上の人員不在時などにおいても、迅速で的確な運用を実現することができる。

さらに、兼務者は、システムへログイン後、兼務リストから職務を変更することにより、業務を行うことができる。

また、ログイン時には組織構成に従った画面表示を行うことで、従来確認できなかった申請データの提出状況も容易に把握することができる。

本発明に係るワークフロー処理プログラムが実行されるネットワーク形態の一例を示す概念図である。 データベースに登録される新旧の組織情報の概略構成図である。 組織情報と各種情報（部情報、課情報、グループ情報、社員情報、役員情報、兼務情報）との関係図である。 組織情報と社員情報、部情報、課情報、グループ情報との関係を示す概念図である。 組織情報と社員情報、役員情報、兼務情報との関係を示す概念図である。 本例のワークフロー処理プログラムを実行する際のログイン時の表示画面例を示す図である。 ログイン後にメニュー表示される表示内容であり、全社員用メニューの表示内容の一例を示す図である。 ログイン後にメニュー表示される表示内容であり、総務部門メニューの表示内容の一例を示す図である。 ログイン後にメニュー表示される表示内容であり、経理部門メニューの表示内容の一例を示す図である。 ログイン後にメニュー表示される表示内容であり、営業部門メニューの表示内容の一例を示す図である。 組織変更時の処理内容の一例を示す図である。 データの申請時における処理内容を説明するためのフローチャートである。 図１２に続くデータの申請時における処理内容を説明するためのフローチャートである。 組織変更時の処理の流れを示す概略図である。 組織変更時の具体例を示す図である。 新旧の組織情報の選択画面の一例を示す図である。 図１６において選択された旧組織情報に基づく申請データの提出状況画面の一例を示す図である。 図１６において選択された新組織情報に基づく申請データの提出状況画面の一例を示す図である。 提出状況画面から選択される項目の詳細情報の表示例を示す図である。 権限委譲の概略説明図である。 代理ログインの概略説明図である。

符号の説明

１ ユーザ端末
２ サーバ
２ａ Ｗｅｂサーバ
２ｂ データベースサーバ
３ イントラネット
１１ データベース
１２ 組織情報
１２ａ 社員情報
１２ｂ 部情報
１２ｃ 課情報
１２ｄ グループ情報
１２ｅ 役員情報
１２ｆ 兼務情報
１３ 申請情報
１４ 経路情報
２１ ログイン画面
２２ 入力項目
２３ 職務選択画面
２４ 選択メニュー
２５ 提出状況一覧画面
２６ 詳細情報画面

Claims (4)

1. 社員の異動を含む組織変更を考慮して社員毎の所属部門と役職との定義に基づいて各部門毎に階層構造として組み立てられた組織情報を組織変更に対応して少なくとも組織変更前の組織情報と組織変更後の組織情報とが予めデータベースに登録されており、
   コンピュータに対して前記データベースに登録された組織情報のうち現在運用している組織変更後の組織情報に関わらず、データの申請時に運用していた組織情報に基づく組織構成に従った申請データの提出経路を確定する機能を実現させるためのワークフロー処理プログラム。
2. 社員の異動を含む組織変更を考慮して社員毎の所属部門と役職との定義に基づいて各部門毎に階層構造として組み立てられた組織変更前後の組織情報が少なくとも年月毎に予めデータベースに登録されており、
   コンピュータに対して前記データベースに登録された年月毎の組織情報のうちデータの申請時に運用している組織情報に基づく組織構成に従った申請データの提出経路を確定する機能を実現させるためのワークフロー処理プログラム。
3. 前記データの申請時の段階で運用していた組織情報を前記データベースから取得し、この取得した組織情報を基にデータ種別に応じて当該申請されたデータの提出経路を決定する機能を実現させるための請求項１または請求項２記載のワークフロー処理プログラム。
4. 前記組織情報の各部門の階層毎に申請データの提出状況を表示する機能を実現させるための請求項１乃至請求項３の何れかに記載のワークフロー処理プログラム。

Images