JP2007172120A - 申請処理システム - Google Patents

申請処理システム Download PDF

Info

Publication number
JP2007172120A
JP2007172120A JP2005366217A JP2005366217A JP2007172120A JP 2007172120 A JP2007172120 A JP 2007172120A JP 2005366217 A JP2005366217 A JP 2005366217A JP 2005366217 A JP2005366217 A JP 2005366217A JP 2007172120 A JP2007172120 A JP 2007172120A
Authority
JP
Japan
Prior art keywords
application
data
database
user data
approval
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2005366217A
Other languages
English (en)
Inventor
Junichi Egawa
淳一 江川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EXGEN NETWORKS CO Ltd
Original Assignee
EXGEN NETWORKS CO Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by EXGEN NETWORKS CO Ltd filed Critical EXGEN NETWORKS CO Ltd
Priority to JP2005366217A priority Critical patent/JP2007172120A/ja
Publication of JP2007172120A publication Critical patent/JP2007172120A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】申請業務作業の効率面で改善の余地がある。
【解決手段】申請対象のユーザの個人情報を示すユーザデータの登録申請、変更申請または削除申請を受け付け、受け付けた申請の内容を当該システム上に反映する申請処理システムであって、そのシステム内の申請処理サーバ100は、複数のユーザデータを一括して処理する一括処理部120とユーザデータを一つずつ処理する個別処理部150とを備える。一括処理部120は電子申請表データを取得する申請表取得部122を備え、一方、個別処理部150は一ユーザのユーザデータを取得するユーザデータ取得部154を備える。申請表取得部122により電子申請表データが取得された場合に、申請処理サーバ100は一括処理部120による一連の処理を実行し、ユーザデータ取得部154により一ユーザのユーザデータが取得された場合に、申請処理サーバ100は個別処理部150による一連の処理を実行する。
【選択図】図2

Description

本発明は、ユーザデータをデータベースに登録する技術に関する。
従来から、企業において、従業員や顧客などの個人情報を示す大量のユーザデータをCSV(Comma Separated Values)形式やエクセル(登録商標)形式などの表データファイルに保存し、その表データファイルを処理することで大量のユーザデータをデータベースに一括して登録する技術が知られている。例えば、特許文献1には、自社の全顧客のIDと顧客ランクとを関連付けたCSVファイルを支援サーバにアップロードし、自社の全顧客のIDと顧客ランクとを顧客データベースに格納する技術が開示されている。
特開2005−32091号公報
企業において、申請者が申請対象のユーザのユーザデータの登録申請、変更申請または削除申請に関する申請業務を行う際にも、上述の表データファイルによるユーザデータの一括登録技術が一般的に利用されている。しかしながら、例えば、中途採用などの人事異動により少数の申請対象者が不定期に生じる場合、申請者は、その都度、その申請内容について、複数の承認者から口頭または書類による承認を取り付ける必要がある。さらに、申請者は、その都度、そのユーザデータをこの表データファイルに手作業で追加しなければならず、申請業務作業の効率面で改善の余地がある。
本発明はこうした課題に鑑みてなされたものであり、その目的は、ユーザデータの登録申請、変更申請または削除申請に関する申請業務作業を効率化する申請処理システムの提供にある。
上記課題を解決するために、本発明のある態様の申請処理システムは、申請対象のユーザの個人情報を示すユーザデータの登録申請、変更申請または削除申請を受け付け、受け付けた申請の内容を当該システム上に反映する申請処理システムである。このシステムは、申請対象のユーザのユーザデータを格納する主データベースと主データベースを補助する複数の従データベースとを有するサーバと、サーバに対しネットワークを介して接続され、少なくとも申請者端末と複数の承認者端末と当該システムの管理者端末と複数の従データベースの管理者端末とを有する複数の端末装置と、を備える。このサーバは、さらに一括処理部と個別処理部とを有する。
一括処理部は、申請対象のユーザのユーザデータとユーザデータを対象とした主データベースに対する処理の種別を示す処理種別データとを有する申請データを複数含む電子申請表データを前記ネットワークを介して取得する申請表取得部と、電子申請表データに含まれる複数の申請データのそれぞれに含まれるユーザデータと処理種別データとを関連付ける関連付け部と、複数の申請データのうち一の申請データに含まれるユーザデータを対象に、そのユーザデータに関連付けられた処理種別に基づいて定められる主データベースに対する登録、変更または削除処理のうちいずれかの処理を実行し、さらに、他の申請データについてもいずれかの処理を繰り返すことで複数の申請データを一括して処理する一括主データベース処理部と、複数の従データベースのうち一つ以上の従データベースの選択指示を受け付け、その選択指示に従って一つ以上の従データベースを選択する一括従データベース選択部と、一括主データベース処理部により処理された複数の申請データを対象とした一括処理を選択された従データベースに対して実行する一括従データベース処理部と、を有する。
個別処理部は、申請対象の一ユーザのユーザデータを項目ごとに入力するためのユーザデータ入力欄を有する電子申請書の入力フォームを申請者端末の画面上に表示する申請書フォーム表示部と、電子申請書の入力フォームのユーザデータ入力欄に入力されたユーザデータを申請者端末からネットワークを介して取得するユーザデータ取得部と、取得されたユーザデータを含む承認用の電子申請書をユーザごとに生成する承認用申請書生成部と、申請者ごとに定めた複数の承認者による承認の順序としてあらかじめ設定された承認ルートに従って、複数の承認者の承認者端末のそれぞれの画面上に承認用の電子申請書を順次表示する承認者表示部と、表示された承認用の電子申請書を承認するか否かの指示を複数の承認者の承認者端末のそれぞれから受け付ける承認者指示受付部と、複数の承認者の承認者端末から承認指示を受け付けた承認用の電子申請書に含まれる一ユーザのユーザデータを対象に、その承認用の電子申請書の種別に基づいて定められる主データベースに対する登録、変更または削除処理のうちいずれかの処理を実行することで、ユーザデータを個別に処理する個別主データベース処理部と、承認を受け付けた承認用の電子申請書をシステムの管理者端末の画面上に表示するシステム管理者端末表示部と、複数の従データベースのうち一つ以上の従データベースの選択指示をシステムの管理者端末から受け付け、その受け付けた選択指示に従って一つ以上の従データベースを選択する個別従データベース選択部と、選択された一つ以上の従データベースの管理者の管理者端末のそれぞれの画面上に承認を受け付けた承認用の電子申請書を表示する従データベース管理者表示部と、従データベースに対するユーザデータの登録、変更または削除処理に必要なシステムデータを表示された従データベース管理者の管理者端末のそれぞれからネットワークを介して取得するシステムデータ取得部と、取得されたシステムデータを参照することで、個別主データベース処理部により処理された一ユーザのユーザデータを対象とした個別処理を、選択された一つ以上の従データベースのそれぞれに対して実行する個別従データベース処理部と、を有する。
このシステムでは、申請表取得部により電子申請表データが取得された場合に、サーバは一括処理部による一連の処理を実行し、一方、ユーザデータ取得部によりユーザデータが取得された場合に、サーバは個別処理部による一連の処理を実行する。
ここで、個人情報とは本人を特定するための情報であり、具体的にはユーザの名字、名前、ID、パスワードなどが挙げられる。主データベースに対する処理の例として、主データベースへのユーザデータの登録処理、主データベース上のユーザデータの変更処理、および主データベース上のユーザデータの削除処理などが挙げられる。従データベースに対する処理の例もこの主データベースに対する処理の例と同様である。また、システムデータの例として、従データベースにアクセスするためのユーザのIDやパスワードなどが挙げられる。さらに、申請者とは、例えば、人事管理の業務を遂行する担当者を指し、所属する部署の別は問わない。
この態様によれば、申請表取得部により電子申請表データが取得されたか、あるいはユーザデータ取得部により一ユーザのユーザデータが取得されたかに応じて、一括処理部による一連の処理あるいは個別処理部による一連の処理のいずれかが実行される。これにより、申請者は、例えば、申請対象のユーザのユーザデータが一時に大量に発生する場合やメンテナンスなどの目的でユーザデータを一括に処理する必要が生じた場合に、一括処理部による一連の処理を、申請対象のユーザのユーザデータが少数であれば、個別処理部による一連の処理のいずれかを選択でき、その結果、ユーザデータの登録申請、変更申請または削除申請に関する申請業務作業の効率化を実現できる。
承認用の電子申請書は、システムデータを入力するためのシステムデータ入力欄を備え、システムデータ取得部は、承認用の電子申請書内のシステムデータ入力欄に入力されたシステムデータを取得してもよい。主データベースの数は当該システムに一つであってもよい。主データベースは、LDAP(Lightweight Directory Access Protocol)に準拠するものであってもよい。
本発明によれば、申請業務作業の効率化を実現できる。
図1は、社内で運用される業務システムのネットワーク構成の一部を示す。この業務システム10は部署ごとに領域分割されており、人事部内システム14や情報システム部内システム16などの複数の部署内システムと、それらシステム間の通信を可能にするLAN(Local Area Network)20と、内部への不正アクセスを防止するファイアウォールサーバ250と、そのサーバと外部のインターネット22とを接続するインターネット接続用ルータ252と、を備える。なお、図の煩雑さを避けるため、人事部内システムや経営企画部内システムといった他の部署内システムの記述は省略する。
本実施の形態に係る申請処理システム12はこの業務システム10内で運用され、顧客や社員などの申請対象者の個人情報を示すユーザデータの登録、変更または削除申請を申請者端末上で受け付け、受け付けた申請の内容に従ってユーザデータを処理する。例えば、この申請処理システム12は、派遣社員、パート社員や新入社員が新たに採用され、それらユーザのユーザデータをデータベース上に登録する必要性が生じたときに利用される。また、ある従業員が他の部署に異動しデータベース上のそのユーザのユーザデータを変更する必要性が生じたときに、他には、ある従業員が退職しそのユーザのユーザデータをデータベース上から削除する必要性が生じたときにも、このシステムが利用される。なお、個人情報とは本人を特定するための情報であり、具体的にはユーザの名字、名前、ID、パスワードなどが挙げられる。なお、本実施の形態に係る申請処理システム12は、人事部内システム14や情報システム部内システム16などの各部署内システムとLAN20とにより形成される。
図1に示す人事部内システム14は、申請者端末200と、第1承認者端末202aや第2承認者端末202bといった複数の承認者端末202とを有する。申請者端末200は、ユーザデータの登録、変更または削除申請を行う申請者により操作される。ここで、申請者とは、例えば、人事管理の業務を遂行する担当者を指し、所属する部署の別は問わない。すなわち、この申請者は、人事部に限らず、情報システム部や経営企画部などの他の部署にも所属していてもよく、後述のシステム管理者、主データベース管理者や従データベース管理者であってもよい。一方、複数の承認者端末202は、申請者により申請された申請内容についての承認指示または否認指示を行う複数の承認者のそれぞれにより操作される。複数の承認者とは、例えば、その申請者が所属する部署の上司を指す。それら端末は、パーソナルコンピュータ、携帯電話機やPDA(Personal Digital Assistance)などの電子機器で構成され、操作のためにマウス、キーボードやボタンなどの入力ユニットが用いられる。
図1に示す情報システム部内システム16は、一つの主データベース102と第1従データベース104aと第2従データベース104bとを有する申請処理サーバ100と、システム管理者端末204と、第1従データベース管理者端末206aや第2従データベース管理者端末206bなどの複数の従データベース管理者端末206と、を有する。以下、第1従データベース104aと第2従データベース104bとを適宜「従データベース104」と総称する。主データベース102は、顧客や社員のユーザデータを内部に保持し、さらに、従データベース104との間で同期化処理が施されている。すなわち、主データベース102内に格納されているユーザデータは、詳細は後述するが、システム管理者により指定された日時において、後述の一括従データベース処理部130により従データベース104内に反映される。
これら主データベース102および従データベース104は、例えば、社員による社内外からのアクセスに対する認証処理にも用いられ、申請処理サーバ100により参照される。具体的には、社員が申請処理サーバ100が提供するウェブページの入力フォーム内に社員番号とパスワードを入力したとき、申請処理サーバ100は、その社員番号とパスワードの対応関係が主データベース102内に存在するか否かをチェックする。存在していれば、申請処理サーバ100は、その社員を正当なユーザとして認証する。また、主データベース102内にその社員の対応関係が存在していなければ、申請処理サーバ100は、次に従データベース内をチェックし、その存在の有無をチェックしてもよい。その意味において、従データベース104は、認証時において主データベース102を補助する役割を果たす。他の例として、従データベース104は、主データベース102上のユーザデータをバックアップするために設けられるものであり、その意味において、主データベース102を補助する役割を果たしてもよい。
本実施の形態では、主データベース102はいわゆるLDAP(Lightweight Directory Access Protocol)ディレクトリで実装される。すなわち、このディレクトリへのアクセスはLDAPで行われる。さらに、第1従データベース104aや第2従データベース104bは、他のディレクトリサービスであるマイクロソフト社のアクティブディレクトリ(商標または登録商標)などで実装される。
システム管理者端末204は、申請処理システム12の管理権限を有するシステム管理者により操作される。このシステム管理者は、いわゆるスーパーユーザであり、主データベース102の管理の他、この申請処理システム12に必要なすべての操作や管理をするができる。第1従データベース管理者端末206aは、第1従データベース104aの管理権限を有する第1従データベース管理者により操作され、一方、第2従データベース管理者端末206bは、第2従データベース104bの管理権限を有する第2従データベース管理者により操作される。
申請処理サーバ100にはApache(登録商標)などのウェブサーバソフトウェアプログラムが搭載されている。一方、前述した人事部内システム14および情報システム部内システム16内の各端末にはウェブブラウザが搭載されている。そのため、申請者、承認者、システム管理者および従データベース管理者は、ユーザデータの登録、変更または削除申請、後述の電子申請書の回覧、承認や管理をその権限に応じて各端末上のウェブブラウザから行うことができる。
申請処理サーバ100は、一括処理部120および個別処理部150をさらに備える。一括処理部120は、複数のユーザのユーザデータの登録、変更または削除申請を一括的に処理(以下、適宜「一括処理」と呼ぶ)する。個別処理部150は、ユーザデータの登録、変更または削除申請を一ユーザずつ個別的に処理(以下、適宜「個別処理」と呼ぶ)する。例えば、前者は、定期的な人事異動などによって生じる大量の申請対象者、例えば新入社員のユーザデータを登録する場合や、メンテナンスなどの目的でユーザデータを一括に処理する必要が生じた場合に実行され、一方、後者は、不定期な人事異動などによって生じる少数の申請対象者、例えばパート社員などの中途採用者のユーザデータを登録する場合に実行される。以下、一括処理および個別処理のそれぞれについてさらに具体的に説明する。
一括処理を行う場合、申請者であるシステム管理者は、登録、変更または削除申請についての申請データが複数記録されたエクセル形式の電子申請表データをシステム管理者端末204上で作成する。なお、電子申請表データの具体的なデータ構造は後述する。具体的には、人事データベース(図示せず)に含まれる複数のユーザデータを電子表形式でエクスポートした後、システム管理者は、そのエクスポートされた電子表のデータ構造に基づいて、上述の電子申請表データを作成する。定期的な人事異動などによって生じる大量のユーザデータは、通常、最初に、人事部システム14内の人事データベース上にマスタデータとして登録されるため、人事部システム14内の人事データベースからユーザデータを抽出するのは効果的である。他の例として、人事データベースからユーザデータを電子表形式で出力するのではなく、申請者が手作業で直接、複数のユーザデータをマウスやキーボードなどのインタフェースを介して電子申請表データ上に入力してもよい。
ここで、企業などの業務施設内においては通常、ユーザデータの登録、変更または削除申請について承認者による承認を必要とするため、その電子申請表データの内容については、あらかじめ複数の承認者から口頭または書類による承認がなされている。必要であれば、さらに従データベース管理者から口頭または書類による承認がなされている。システム管理者端末204は、システム管理者端末204上で作成した、その内容について承認が得られた電子申請表データを申請処理サーバ100にLAN20を介して送信する。この場合、システム管理者である申請者は、電子申請表データを入力し送信するバッチプログラムを単に実行してもよいし、ウェブページ内の入力フォームに電子申請表データのファイル名を入力することで、そのファイル名の電子申請表データを申請処理サーバ100に送信してもよい。一括処理部120は、こうして取得した電子申請表データに含まれる複数の申請データを一括して処理する。他の例として、システム管理者ではなく、例えば、人事部に所属する申請者が、申請者端末200上で電子申請表データを作成し、その電子申請表データをLAN20を介して申請処理サーバ100に送信してもよい。
一方、個別処理を行う場合、申請者は申請者端末200のウェブブラウザ上に表示された電子申請書の入力フォーム内に一ユーザのユーザデータを入力する。個別処理の場合、申請者は、通常、情報システム部に所属するシステム管理者ではなく、他の部署、例えば、人事部に所属する申請業務担当者である。個別処理部150は、入力された一ユーザのユーザデータを含む承認用の電子申請書を生成し、複数の承認者端末202間で回覧させる。複数の承認者による承認を受け付けた後、個別処理部150は、承認用の電子申請書に含まれる一ユーザのユーザデータを対象に、詳細は後述するが、システム管理者により指定された日時において、主データベースの正規領域への登録、変更または削除処理を行う。さらに、個別処理部150は従データベース管理者端末206のウェブブラウザ上に電子申請書を表示する。最後に従データベース管理者による確認を受け付けた後、個別処理部150は承認用の電子申請表データに含まれる一ユーザのユーザデータを対象に、システム管理者により指定された日時において、従データベースへの登録、変更または削除処理を行う。
図2は、本実施の形態に係る申請処理サーバの構成を示す。本実施の形態に係る申請処理サーバ100は、前述のごとく、主データベース102と、第1従データベース104aと、第2従データベース104bと、一括処理部120と、個別処理部150とを含む。
最初に、一括処理部120内の構成要素を説明する。一括処理部120は、申請表取得部122と、関連付け部124と、一括主データベース処理部126と、一括従データベース選択部128と、一括従データベース処理部130とを含む。
申請表取得部122は、申請対象のユーザのユーザデータとユーザデータを対象とした主データベース102に対する処理の種別を示す処理種別データとを有する申請データを複数含む、詳細は後述する電子申請表データをシステム管理者端末204からLAN20を介して取得する。この電子申請表データは、エクセル形式やCSV形式で保存される。主データベース102に対する処理の例として、主データベース102へのユーザデータの登録処理、主データベース102上のユーザデータの変更処理、および主データベース102上のユーザデータの削除処理などが挙げられる。本実施の形態では、これら処理の種別を示す処理種別データをそれぞれ、「001」、「002」および「003」と表現するものとする。処理種別データと実際の処理との対応関係、例えば、「001」と「登録処理」との対応関係、「002」と「変更処理」との対応関係、「003」と「削除処理」との対応関係は、あらかじめ申請処理サーバ100内に保存されている。
申請表取得部122により取得された電子申請表データに含まれる申請データは、まず最初に、主データベース102内の中間領域上に登録される。このとき、申請表取得部122は、後述の第1マッピング表を参照する。この中間領域とは、電子申請表データに含まれる申請データを一時的に格納する領域であり、この中間領域内に格納された申請データは、最終的には、システム管理者により指定された日時において、主データベース102内の正規領域上に反映される。なお、本明細書において、説明の際に中間領域と正規領域とを区別する必要がないときは、適宜、中間領域と正規領域の別を省略する。本実施の形態では、申請処理サーバ100が、反映日時を入力するための入力フォームを含むウェブページをシステム管理者端末204に提供する。ユーザにより、反映日時がその入力フォーム内にマウスやキーボードなどのインタフェースを介して入力されたとき、申請処理サーバ100内の反映日時取得部(図示せず)は、入力フォーム内に入力された反映日時をLAN20を介して取得する。
関連付け部124は、主データベース102内の中間領域上に登録された、電子申請表データに含まれる複数の申請データのそれぞれに含まれるユーザデータと処理種別データとを関連付ける。一括主データベース処理部126は、複数の申請データのうち一の申請データに含まれるユーザデータを対象に、そのユーザデータに関連付けられた処理種別に基づいて定められる主データベース102に対する登録、変更または削除処理のうちいずれかの処理を実行し、さらに、他の申請データについてもいずれかの処理を繰り返すことで複数の申請データを一括して処理する。
具体的には、例えば、一の申請データ内のあるユーザデータに対し、関連付け部124により「001」が関連付けられていた場合、一括主データベース処理部126は、上述の処理種別データと実際の処理との対応関係を参照し、システム管理者により指定された日時において、そのユーザデータを主データベース102の正規領域内に登録する。他の例として、一の申請データ内のあるユーザデータに対し、「002」が関連付けられていた場合、上述の処理種別データと実際の処理との対応関係を参照し、システム管理者により指定された日時において、主データベース102の正規領域内のそのユーザデータを上書きすることでユーザデータを変更する。さらに、一の申請データ内のあるユーザデータに対し、「003」が関連付けられていた場合、上述の処理種別データと実際の処理との対応関係を参照し、システム管理者により指定された日時において、主データベース102の正規領域内に存在するそのユーザデータを削除する。なお、一括主データベース処理部126は、削除のかわりに、削除対象のユーザデータに無効化フラグを立ててもよい。以下、一括主データベース処理部126は、電子申請表データに含まれる複数の申請データについてこのような処理を繰り返すことで複数の申請データの一括処理を実現する。
一括従データベース選択部128は、複数の従データベース104のうち一つ以上の従データベースの選択指示を申請者端末200から受け付け、その受け付けた指示に従って一つ以上の従データベースを選択する。具体的には、一括従データベース選択部128は、申請者端末200上で受け付けた従データベースの選択指示をLAN20を介して取得し、その取得した指示に従って、複数の従データベース104のうち、例えば、第1従データベース104aまたは第2従データベース104bを選択する。一括従データベース選択部128は、従データベースの選択指示を受け付けるためのダイアログを申請者端末200の画面上に表示し、それにより選択指示を受け付けても良い。また、一括従データベース選択部128は、申請表取得部122により電子申請表データが取得される前に、あらかじめこの従データベースの選択指示をシステム管理者から受け付けていてもよい。
一括従データベース処理部130は、一括主データベース処理部126により処理された複数の申請データを対象とした一括処理を、一括従データベース選択部128により選択された従データベース104に対して実行する。このとき、一括従データベース処理部130は、後述の第2マッピング表を参照する。なお、従データベース104への一括処理は、主データベース102への一括処理の実行の直後に行われてもよいし、システム管理者により指定された日時に行われてもよい。後者の場合、その日時の取得方法は、上述の主データベースの正規領域に反映する際の日時の取得方法と同様に、ウェブページの入力フォームを用いたものであってもよい。他の例として、申請処理サーバ100は、システム管理者による指示により、日時を設定するためのスケジューラプログラムを起動してもよい。この場合、そのスケジューラプログラムによりシステム管理者端末204の画面上に表示された日時設定用入力欄内に反映日時が入力されることで、申請処理サーバ100は、システム管理者から指定された反映日時をLAN20を介してシステム管理者端末204から取得する。
いずれの場合でも、電子申請表データに記載された申請データの内容を主データベース102だけでなく、選択された従データベース104にも反映できる。これにより、主データベース102と従データベース104とを互いに同期化させることができる。さらに、例えば、主データベース102に障害が発生した時に、従データベース104上のユーザデータを主データベース102上に単にコピーするだけで主データベース102のリカバリを実現し、障害に対する信頼性を高めることができる。
次に、個別処理部150内の構成要素を説明する。個別処理部150は、申請書フォーム表示部152と、ユーザデータ取得部154と、承認用申請書生成部156と、承認者表示部158と、承認者指示受付部160と、個別主データベース処理部162と、システム管理者端末表示部164と、個別従データベース選択部166と、従データベース管理者表示部168と、システムデータ取得部170と、個別従データベース処理部172と、を含む。
申請書フォーム表示部152は、申請対象の一ユーザのユーザデータを項目ごとに入力するためのユーザデータ入力欄を有する電子申請書の入力フォームを申請者端末200の画面上に表示する。具体的には、申請書フォーム表示部152は、社員番号欄、名字欄、名前欄やパスワード欄などを有する電子申請書の入力フォームを申請者端末200の画面上に表示する。この電子申請書の入力フォームは、任意のテキストを入力できる入力欄の他に、例えば、男性または女性を簡単に選択できるラジオボタンをも有してもよい。ユーザデータ取得部154は、電子申請書の入力フォームのユーザデータ入力欄に入力された一ユーザのユーザデータを申請者端末200からLAN20を介して取得する。
承認用申請書生成部156は、申請者端末200からLAN20を介して取得された一ユーザのユーザデータを含む承認用の電子申請書をユーザごとに生成する。承認者表示部158は、申請者ごとに定めた複数の承認者による承認の順序としてあらかじめ設定された承認ルートに従って、複数の承認者の承認者端末202のそれぞれの画面上に承認用の電子申請書を順次表示する。この承認ルートはシステム管理者端末204の画面上であらかじめ設定されるものであり、設定された承認ルートは主データベース102内に格納される。
承認者指示受付部160は、承認者表示部158により表示された承認用の電子申請書を承認するか否かの指示を複数の承認者の承認者端末202から受け付ける。具体的には、承認者指示受付部160は、承認者端末202の画面上に表示された承認ボタンまたは否認ボタンによりいずれかの指示を受け付ける。画面上に表示された承認ボタンまたは否認ボタンのいずれかが承認者のマウス操作により押下された場合、承認者指示受付部160は、そのいずれかのボタンに対応する指示をLAN20を介して受け付ける。例えば、具体的には、承認者指示受付部160は、承認指示を表すデータとして「1」、否認指示を表すデータとして「0」を受け付け、受け付けたデータが「1」であるか「0」であるかに応じて、承認または否認を判断してもよい。個別処理部150内の状態表示部(図示せず)は、ある承認用の電子申請書について、ある承認者により承認されているか否かを示す情報を承認状態として申請者端末200や承認者端末202の画面上に表示してもよい。
複数の承認者の承認者端末202から承認指示を受け付けた承認用の電子申請書に含まれるユーザデータは、まず最初に、主データベース102内の中間領域上に登録される。さらに、そのユーザデータを含む承認用の電子申請書の種別を示す処理種別データがそのユーザデータに対応付けられ、この中間領域上に登録される。なお、承認用の電子申請書の種別としては、「登録用」、「変更用」および「削除用」などが挙げられ、処理種別データとしてはそれぞれ、「001」、「002」および「003」などが挙げられる。一括処理の場合と同様に、この中間領域内に格納されたユーザデータは、最終的には、システム管理者により指定された日時において、主データベース102内の正規領域上に反映される。なお、この主データベース102内の正規領域への反映日時の指定方法は、上述の一括処理の場合における主データベース102内の正規領域への反映日時の指定方法と同様である。
個別主データベース処理部162は、複数の承認者の承認者端末202から承認指示を受け付けた承認用の電子申請書に含まれる一ユーザのユーザデータを対象に、その承認用の電子申請書の種別に基づいて定められる、主データベースの正規領域に対する登録、変更または削除処理のうちいずれかの処理を、システム管理者により指定された日時において、実行することで、ユーザデータを個別に処理する。なお、承認用の電子申請書の種別としては、「登録用」、「変更用」および「削除用」などが挙げられる。個別主データベース処理部162は、主データベース102内の中間領域上に登録されたユーザデータを対象に、それら承認用の電子申請書の種別に応じて主データベースの正規領域に対する登録、変更または削除処理を実行する。
システム管理者端末表示部164は、複数の承認者の承認者端末202上で承認を受け付けた承認用の電子申請書をシステム管理者端末204の画面上に表示する。個別従データベース選択部166は、複数の従データベース104のうち一つ以上の従データベースの選択指示をシステム管理者端末204から受け付け、その受け付けた選択指示に従って一つ以上の従データベースを選択する。具体的には、個別従データベース選択部166は、システム管理者端末204上で受け付けた従データベースの選択指示をLAN20を介して取得し、その取得した指示に従って、複数の従データベース104のうち、例えば、第1従データベース104aまたは第2従データベース104bを選択する。これにより、承認用の電子申請書を、システム管理者により選択された従データベース104に振り分けることができる。
従データベース管理者表示部168は、個別従データベース選択部166により選択された一つ以上の従データベースの従データベース管理者端末206のそれぞれの画面上に、システム管理者により振り分けられた承認用の電子申請書を表示する。システムデータ取得部170は、従データベース104に対するユーザデータの登録、変更または削除処理に必要なシステムデータを、従データベース管理者表示部168により表示された従データベース管理者端末206のそれぞれからLAN20を介して取得する。このシステムデータの例として、従データベース104にアクセスするためのユーザのIDやパスワードなどが挙げられる。なお、承認用の電子申請書はシステムデータを入力するためのシステムデータ入力欄を備えており、システムデータ取得部170は、そのシステムデータ入力欄に入力されたシステムデータをLAN20を介して取得する。
個別従データベース処理部172は、システムデータ取得部170により取得されたシステムデータを参照することで、個別主データベース処理部162により処理された一ユーザのユーザデータを対象とした個別処理を、選択された一つ以上の従データベースのそれぞれに対して実行する。具体的には、例えば、主データベースの正規領域内に、社員番号「0001」のユーザデータが個別主データベース処理部162により登録された場合、システムデータに含まれる従データベース104に対するユーザデータの登録に必要な、IDとパスワードを従データベース104上に設定し、そのユーザデータを登録する。なお、従データベース104への一括処理の実行は、主データベース102への一括処理の実行の直後に行われてもよいし、システム管理者により指定された日時に行われてもよい。後者の場合、その日時の取得方法は、上述の主データベースの正規領域に反映する際の日時の取得方法と同様に、ウェブページの入力フォームを用いたものであってもよい。
いずれの場合でも、電子申請書に記載された申請内容を主データベース102だけでなく、個別従データベース選択部166により選択された従データベース104にも反映できる。これにより、主データベース102と従データベース104とを互いに同期化させることができ、上述の認証処理の際に使用されるべきデータベースの選択の余地を広げることができる。さらに、例えば、主データベース102に障害が発生した時に、選択された従データベース104上のユーザデータを主データベース102上に単にコピーするだけで主データベース102のリカバリを実現し、障害に対する信頼性を高めることができる。
本実施の形態では、申請表取得部122により電子申請表データが取得された場合に、申請処理サーバ100は一括処理部120による一連の処理を実行し、一方、ユーザデータ取得部154により一ユーザのユーザデータが取得された場合に、申請処理サーバ100は個別処理部150による一連の処理を実行する。これにより、申請表取得部122により電子申請表データが取得されたか、あるいはユーザデータ取得部154により一ユーザのユーザデータが取得されたかに応じて、一括処理部120による一連の処理あるいは個別処理部150による一連の処理のいずれかを実行できる。その結果、申請者は、例えば、申請対象のユーザのユーザデータが一時に大量に存在する場合であれば、一括処理部120による一連の処理を、申請対象のユーザのユーザデータが少数であれば、個別処理部150による一連の処理のいずれかを選択でき、その結果、ユーザデータの登録申請、変更申請または削除申請に関する申請業務作業の効率化を実現できる。
以下、最初に一括処理部120による一連の処理の流れを図3から図6を用いて具体的に説明し、次に個別処理部150による一連の処理の流れを図7から図11を用いて具体的に説明する。
図3は、電子申請表データのデータ構造の一例を示す。図3に示す電子申請表データ210は、複数の申請データをエクセル形式で保持するものである。この電子申請表データ210は、主データベース102の正規領域に対する処理の種別を保持する処理種別欄212と、申請対象のユーザのユーザデータを項目別に保持する社員番号欄214と名字欄216と名前欄218とパスワード欄220とを備える。他の項目として、住所欄や電話番号欄などをもさらに備えてよい。
処理種別欄212は、主データベース102(または、主データベース102の正規領域)に対する登録処理を示す「001」データ、主データベース102(または、主データベース102の正規領域)に対する変更処理を示す「002」データ、主データベース102(または、主データベース102の正規領域)に対する削除処理を示す「003」データのいずれかを保持する。社員番号欄214はユーザ本人を業務システム上で特定するための番号である社員番号を保持する。名字欄216はユーザの名字を、名前欄218はユーザの名前を保持する。パスワード欄220は、主データベースへのアクセスに必要なパスワードを含む。
例えば、申請データ222については、処理種別「001」データと、社員番号「0001」、名字「山田」、名前「一郎」およびパスワード「xxx」からなるユーザデータ224と、を含む。この申請データ222が一括処理部120により処理された場合、そのユーザデータ224が主データベース102(または、主データベース102の正規領域)上に登録される。申請データ226が処理された場合、主データベース102(または、主データベース102の正規領域)上の社員番号「0004」のユーザデータがユーザデータ228に変更される。さらに、申請データ230が処理された場合、ユーザデータ232と同一内容のユーザデータが主データベース102(または、主データベース102の正規領域)から削除される。このように、複数の申請データをまとめた電子申請表データ210の入力を受け付けることで、その電子申請表データ210に含まれる複数の申請データを一括的に処理できる。
図4は、電子申請表データの電子申請表列名と主データベースの主データベース属性名とを対応付けた第1マッピング表を示す。一括主データベース処理部126は、この第1マッピング表240を参照し、電子申請表データ210に含まれる複数の申請データを対象とした主データベース102(または、主データベース102の正規領域)に対する登録、変更または削除処理を行う。また、電子申請表データ210に含まれる複数の申請データが一度、主データベース内の中間領域内に登録され、それら登録された申請データに対してその登録、変更または削除処理が施されてもよい。この第1マッピング表240は、システム管理者の操作によりシステム管理者端末204の画面上で作成され、前述の電子申請表データを入力し送信するバッチプログラムやウェブページ上に搭載される。他の例として、この第1マッピング表240はあらかじめ作成され、申請処理サーバ100内に格納されてもよい。
図4に示す第1マッピング表240は、電子申請表列名欄260と主データベース属性名欄262とを保持する。電子申請表列名欄260は、図3に示す電子申請表データ210の列名、例えば、「社員番号」、「名字」、「名前」、「パスワード」などを保持する。主データベース属性名欄262は、主データベース上のエントリ内の属性名、例えば、「employeeNumber」や「sn」を保持する。電子申請表列名欄260内の列名と主データベース属性名欄262内の属性名はお互いに関連付けられており、例えば、「社員番号」は「employeeNumber」に、「名字」は「sn」に関連付けられている。一括主データベース処理部126はこの第1マッピング表240を参照し、例えば、電子申請表データ210内の社員番号「0001」を、主データベース上の属性名「employeeNumber」に関連づけて保持する。
図5は、主データベースの正規領域内における社員番号「0001」を示すユーザデータの保存状態を階層的に示す。図5に示すごとく、電子申請表データ210に含まれる社員番号「0001」のユーザデータ224は、主データベース102の正規領域上で「cn=0001,o=ABC,c=JP」と定義されて保持される。他のユーザデータについては省略する。ここで、「c」、「o」および「cn」はそれぞれ、国名、会社名、および社員番号を示す。名字や名前などの他の項目のユーザデータは、「cn=0001,o=ABC,c=JP」と定義されたDN(Distinguished Name;識別名)を有するエントリ内において、「sn」や「givenName」などの属性名に関連付けられて保持される。
図6は、主データベース上の主データベース属性名と従データベース上の従データベース属性名とを対応付けた第2マッピング表を示す。なお、すでに、一括従データベース選択部128により、複数の従データベース104のうち一つ以上の従データベースが選択されているものとする。一括従データベース処理部130は、この第2マッピング表270を参照し、電子申請表データ210に含まれる複数の申請データを対象とした従データベース104に対する登録、変更または削除処理を行う。具体的には、主データベース内の正規領域内に登録された、電子申請表データ210に含まれる複数の申請データに対して、その登録、変更または削除処理が施されてもよい。この第2マッピング表270は、システム管理者の操作によりシステム管理者端末204の画面上で作成され、前述の電子申請表データを入力し送信するバッチプログラムやウェブページ上に搭載される。他の例として、この第2マッピング表270はあらかじめ作成され、申請処理サーバ100内に格納されてもよい。
第2マッピング表は、主データベース属性名欄272と従データベース属性名欄274とを保持する。主データベース属性名欄272内のそれぞれの属性名は、従データベース属性名欄274内のそれぞれの属性名に関連付けられる。一括従データベース処理部130はこの第2マッピング表270を参照し、主データベース102上で属性名「employeeNumber」に関連付けられたデータ、例えば社員番号「0001」を、従データベース104上で属性名「employeeNumber」に関連付けて保持する。以上、一括処理部120による一連の処理の流れを説明した。
次に、個別処理部150による一連の処理の流れを説明する。図7は、システム管理者の端末上に表示された承認ルートの設定画面を示す。前述のごとく、複数の承認者による承認の順序を決定する承認ルートは、システム管理者により申請者ごとにあらかじめ設定され、その設定された承認ルートは主データベース102内に格納される。他の例として、承認ルートは、システム管理者により申請書ごとにあらかじめ設定されてもよい。本実施の形態では、申請者の社員番号は複数の承認者の社員番号に関連付けられて保持され、さらに、複数の承認者の社員番号は承認の順序を示す番号に関連付けられて保持される。他の例として、承認者の社員番号に申請者の社員番号が関連付けられてもよい。承認ルートの設定画面280は、ルート名欄282と、承認者欄284とを備える。ルート名欄282には、「人事部」など、申請処理システム12においてルートを一意に特定するための名称が入力される。なお、本実施の形態では、申請者ごとに承認ルートが設定されるが、同じ部署内の申請者であれば同一の承認ルートが適用される。
承認者欄284は、承認者操作欄290および承認者リスト欄298を含む。承認者操作欄290は、「申請者の直属上司」および「承認者を選択」のうちいずれかを選択するための第1ラジオボタン292aおよび第2ラジオボタン292bと、追加ボタン294と、削除ボタン296とを含む。承認者リスト欄298は、現在設定されている承認者の一覧を表示する。例えば、承認者操作欄290内の「申請者の直属上司」に対応する第1ラジオボタン292aがシステム管理者によりオンされ、さらに追加ボタン294が押下された場合、申請者の直属上司が承認者リスト欄298内に追加される。申請者の直属上司の社員番号と申請者の社員番号とはお互いに関連付けられてあらかじめ主データベース内に保持されており、申請処理サーバ100内部の抽出部(図示せず)が申請者の社員番号をキーにして申請者の直属上司の社員番号を検索することで、申請者の直属上司の社員番号を抽出できる。
一方、「承認者を選択」に対応する第2ラジオボタン292bがオンされ、さらに追加ボタン294が押下された場合、任意の承認者が承認者リスト欄298内に追加される。具体的には、プルダウンで表示される承認者の候補リストから任意の承認者が選択される。なお、本実施の形態では、承認者リスト欄において上から表示された順番に承認が行われる。すなわち、図7に示す例では、最初に「森田六郎」による承認、次に「中田七郎」による承認が行われる。削除ボタン296が押下された場合、オンされた状態のラジオボタンはオフ状態になり、初期状態に戻る。
図8は、申請者端末上に表示された登録用の電子申請書の入力フォームを示す。申請者端末200上に表示された電子申請書の入力フォーム310は、ユーザデータ入力欄群320の他、申請日欄312と、申請者欄314と、申請ボタン340と、削除ボタン342とを含む。ユーザデータ入力欄群320は、社員番号欄322と、名字欄324と、名前欄326と、氏名欄328と、組織欄330と、パスワード欄332と、メールアドレス欄334と、住所欄336と、TEL欄338とを含む。なお、図8に示す例では、登録用の電子申請書の入力フォームが示されているが、変更用の電子申請書の入力フォーム(図示せず)についても図8に示すユーザデータ入力欄群320を有する。この場合、申請者は変更対象となる項目のユーザデータ入力欄のみにユーザデータを入力してもよい。また、削除用の電子申請書の入力フォーム(図示せず)内のユーザデータ入力欄群320は、社員番号欄322のみを有する。
図8に示すごとく、電子申請書の入力フォーム310内のユーザデータ入力欄群320には、申請対象者である「鈴木一郎」のユーザデータが申請者である人事部の「山田太郎」によりすでに入力されている。この申請者により申請ボタン340が押下されたとき、電子申請書の入力フォーム310内のユーザデータ入力欄群320に入力されたユーザデータはLAN20を介して申請処理サーバ100に送信される。承認用申請書生成部156は、送信された一ユーザのユーザデータを含む承認用の電子申請書を生成する。なお、削除ボタン342が押下されたとき、ユーザデータ入力欄群320に入力されたユーザデータはすべてクリアされ、初期状態に戻る。
図9は、承認者端末の画面上に表示された承認用の電子申請書を示す。なお、図8と同様の構成については同一の符号を付し、適宜説明を略す。承認用の電子申請書350は、前述のごとく、承認用申請書生成部156により生成されたものである。この承認用の電子申請書350は、すでに入力済みのユーザデータ入力欄群320や申請日欄312や申請者欄314の他、複数の承認者による承認処理のプロセスを示す承認状態一覧表351と、承認ボタン360と、否認ボタン362とを含む。承認状態一覧表351は、承認状態欄352と、承認者欄354と、承認開始日欄356と、操作日時欄358とを含む。
承認状態欄352内においては、承認用の電子申請書に関する現在の承認の状態を示すものとして、「承認済」、「承認中」および「承認待」のいずれかが前述の状態表示部により表示される。承認者欄354内においては承認者の氏名および所属部署名、承認開始日欄356内においては承認者が電子申請書を最初に参照した日、操作日時欄358においては承認者による承認指示または否認指示を受け付けた日時が表示される。
図9に示す例では、「森田六郎」による承認はすでに行われており、「中田七郎」による承認は実行中である。ここで、承認者である「中田七郎」により承認ボタン360が押下された場合、承認指示がLAN20を介して申請処理サーバ100に送信され、承認者指示受付部160により取得される。一方、否認ボタン362が押下された場合、否認指示がLAN20を介して承認者指示受付部160により取得される。なお、ある承認者により電子申請書が否認された場合、その電子申請書は申請者の申請者端末200に戻される。この場合、申請者はその電子申請書の内容の一部または全部を修正して、あるいは修正なしで再申請できる。承認者欄354内に表示されるすべての承認者により承認された場合、個別主データベース処理部162により電子申請書の内容が最初に主データベースの中間領域内に反映され、その後、システム管理者により指定された日時に、主データベースの正規領域内に反映される。なお、ユーザデータ入力欄群320の各項目と主データベース102上のそれぞれの属性名とはあらかじめ関連付けられているため、主データベースへのユーザデータの反映が可能になる。例えば、社員番号欄322には属性名「employeeNumber」が関連付けられているため、社員番号欄322内に入力された「9999」を主データベース上の属性名「employeeNumber」に関連付けて保持できる。
図10は、システム管理者端末の画面上に表示された承認用の電子申請書を示す。なお、図8と同様の構成については同一の符号を付し、適宜説明を略す。システム管理者端末204の画面上に表示された承認用の電子申請書370は、複数の承認者によりすでに承認されたものである。この承認用の電子申請書370は、すでに入力済みのユーザデータ入力欄群320や申請日欄312や申請者欄314の他、従データベース104を選択するための従データベース選択欄372および完了ボタン376を含む。この従データベース選択欄372は、「第1データベース」に対応付けられた第1チェックボックス374aと、「第2データベース」に対応付けられた第2チェックボックス374bとを含む。
第1チェックボックス374aがシステム管理者によるマウス操作などによりチェックされた場合、第1データベースの選択が可能になり、一方、第2チェックボックス374bがチェックされた場合、第2データベースの選択が可能になる。なお、従データベース104の選択数は一つであってもよいし、複数であってもよい。チェックボックス374がチェックされた後、完了ボタン376が押下された場合、その従データベースの選択指示がLAN20を介して個別従データベース選択部166に送信され、個別従データベース選択部166は、その送信された指示に従って一以上の従データベースを選択する。この場合、個別従データベース選択部166は、後述の従データベースのシステムデータを入力するための入力欄群を含む承認用の電子申請書を、選択した従データベース管理者端末206にLAN20を介して提供する。
図11は、個別従データベース選択部により選択された従データベース管理者端末の画面上に表示された、承認用の電子申請書を示す。なお、図8と同様の構成については同一の符号を付し、適宜説明を略す。従データベース管理者端末206の画面上に表示された承認用の電子申請書380は、すでに入力済みのユーザデータ入力欄群320や申請日欄312や申請者欄314の他、前述のシステムデータを格納するためのシステムデータ入力欄群382と申請ボタン392と削除ボタン394を有する。このシステムデータ入力欄群382は、名前欄384と名字欄386とユーザ名欄388とパスワード欄390とを備える。削除ボタン394が押下されたとき、システムデータ入力欄群382に入力されたシステムデータはすべてクリアされ、初期状態に戻る。
図11に示すごとく、システムデータ入力欄群382には、従データベース管理者によりシステムデータがすでに入力されている。従データベース管理者により申請ボタン392が押下されたとき、システムデータ入力欄群382に入力されたシステムデータはLAN20を介して申請処理サーバ100に送信され、システムデータ取得部170により取得される。個別従データベース処理部172は、システムデータ取得部170により取得されたシステムデータを参照し、システム管理者により指定された日時に、承認用の電子申請書の内容を従データベースに反映する。なお、ユーザデータ入力欄群320の各項目と従データベース104上のそれぞれの属性名とはあらかじめ関連付けられているため、システム管理者により指定された日時に、従データベースへのユーザデータの反映が可能になる。
図12は、本実施の形態に係る申請処理の流れを示す。システム管理者の入力指示により、システム管理者端末204の画面上で承認ルートがあらかじめ設定される(S10)。例えば、申請者「山田太郎」に関する承認ルートとして承認者「森田六郎」および承認者「中田七郎」が定められ、主データベース102内に格納される。申請書フォーム表示部152は、申請対象の一ユーザのユーザデータを項目ごとに入力するためのユーザデータ入力欄を有する電子申請書の入力フォームを申請者端末200の画面上に表示する(S12)。
申請者端末200の画面上に表示された電子申請書の入力フォームを介することなく、申請表取得部122が電子申請表データを取得した場合(S14のY)、一括処理部120による以下の一連の処理、すなわち図12に示すステップ16からステップ22までの処理が実行される。申請表取得部122により取得された電子申請表データに含まれる申請データは、まず最初に、主データベース102内の中間領域上に登録される。このとき、申請表取得部122は、第1マッピング表を参照する。また、申請処理サーバ100は、主データベース102内の中間領域上に登録された申請データを正規領域内に反映する日時をシステム管理者からの指示により取得する。
関連付け部124は、主データベース102内の中間領域上に登録された、申請表取得部122により取得された電子申請表データに含まれる複数の申請データのそれぞれに含まれるユーザデータと処理種別データとを関連付ける(S16)。一括主データベース処理部126は、例えば、主データベース102内の中間領域内に含まれる、ある申請データ内のユーザデータについて、関連付け部124により「001」が関連付けられていた場合、そのユーザデータを、指定された日時に主データベース102の正規領域内に登録する。以下、このような処理を複数の申請データについて行うことで複数の申請データを一括処理する(S18)。
一括従データベース選択部128は、複数の従データベース104のうち一つ以上の従データベースの選択指示を申請者端末200から受け付け、その受け付けた指示に従って、例えば、第1従データベース104aおよび第2従データベース104bのうちの第1従データベース104aを選択する(S20)。申請処理サーバ100は、主データベース102内の正規領域内に登録された申請データを第1従データベース104a内に反映する日時をシステム管理者からの指示により取得する。一括従データベース処理部130は、一括主データベース処理部126により処理された複数の申請データを対象とした一括処理を、指定された日時に、一括従データベース選択部128により選択された第1従データベース104aに対して実行する(S22)。このとき、一括従データベース処理部130は、第2マッピング表を参照する。一括従データベース処理部130により、選択された第1従データベース104aに申請内容が反映されたとき、一括申請処理が終了する。なお、複数の従データベース104が選択された場合、すべての選択された従データベース104に対して申請内容が反映されたときに、一括申請処理が終了する。
申請表取得部122が電子申請表データを取得せず(S14のN)、ユーザデータ取得部154が、ステップ12により表示された電子申請書の入力フォームに入力された一ユーザのユーザデータを取得した場合(S24のY)、個別処理部150による以下の一連の処理、すなわち図12に示すステップ24からステップ46までの処理が実行される。一方、ユーザデータ取得部154が取得したユーザデータが一ユーザでない場合(S24のN)、ステップ14に戻る。承認用申請書生成部156は、ユーザデータ取得部154により取得された一ユーザのユーザデータを含む承認用の電子申請書をユーザごとに生成する(S26)。承認者表示部158は主データベース102に格納された承認ルートを参照し、申請者「山田太郎」に定められた、最初の承認者である「森田六郎」の承認者端末202の画面上に、承認用申請書生成部156により生成された承認用の電子申請書、例えば、登録申請書を表示する(S28)。
承認者指示受付部160は、承認者表示部158により表示された承認用の電子申請書、例えば、登録申請書を承認するか否かの指示を「森田六郎」の承認者端末202から受け付ける(S30)。承認者指示受付部160が「森田六郎」の承認者端末202から承認しない旨の指示を受け付けた場合(S32のN)、処理はステップ12に戻る。承認者指示受付部160が承認する旨の指示を受け付けた場合(S32のY)、申請処理サーバ100は主データベースに格納された承認ルートを参照し、次の承認者が存在するか否かを判断する(S34)。
次の承認者が存在すれば(S34のY)、承認者表示部158は、例えば、「中田七郎」の承認者端末202の画面上に、承認用申請書生成部156により生成された承認用の電子申請書を表示し、続いて、前述したステップ30以降の処理を行う。他に承認者が存在しなければ(S34のN)、その電子申請書、例えば登録申請書に含まれるユーザデータに、そのユーザデータを含む登録申請書の処理種別データ「001」を関連付けて、主データベース内の中間領域内に保持する。また、申請処理サーバ100は、主データベース102内の中間領域上に登録されたユーザデータを正規領域内に反映する日時をシステム管理者からの指示により取得する。個別主データベース処理部162は、主データベースの中間領域に登録された、ユーザデータ取得部154により取得された一ユーザのユーザデータを対象に、指定された日時において、そのユーザデータに関連付けられた処理種別データ「001」が示す登録処理を施し、主データベースの正規領域内に登録することで主データベースへの個別処理を実行する(S36)。
システム管理者端末表示部164は、「森田六郎」および「中田七郎」の承認者端末202上で承認を受け付けた承認用の電子申請書をシステム管理者端末204の画面上に表示する(S38)。個別従データベース選択部166は、複数の従データベース104のうち一つ以上の従データベースの選択指示を、システム管理者端末表示部164により表示されたシステム管理者端末204から受け付け、その受け付けた指示に従って第1従データベース104aおよび第2従データベース104bのうちの第1従データベース104aを選択する(S40)。従データベース管理者表示部168は、個別従データベース選択部166により選択された第1従データベース104aの管理者端末の画面上に、システム管理者により振り分けられた承認用の電子申請書を表示する(S42)。また、申請処理サーバ100は、主データベース102内の正規領域内に登録されたユーザデータを第1従データベース104a内に反映する日時を、システム管理者からの指示により取得する。
システムデータ取得部170は、第1従データベース104aに対するシステムデータを、従データベース管理者表示部168により表示された第1従データベース管理者端末206aからLAN20を介して取得する(S44)。個別従データベース処理部172は、システムデータ取得部170により取得されたシステムデータを参照することで、個別主データベース処理部162により処理された一ユーザのユーザデータを対象とした個別処理を、指定された日時において、個別従データベース選択部166により選択された第1従データベース104aに対して実行する(S46)。個別従データベース選択部166により選択された第1従データベース104aに申請内容が反映されたときに、申請処理が終了する。なお、複数の従データベース104が選択された場合、すべての選択された従データベース104に対して申請内容が反映されたときに、一括申請処理が終了する。
従来では、定期的に大量の申請対象者が生じたときも、不定期に少数の申請対象者が生じたときも、CSVファイルやエクセル形式の表データにその申請対象者のユーザデータを手作業で追加していた。後者の場合、申請者は、少数の申請対象者が不定期に発生するたびに、その都度、日常の業務を中断して、そのユーザデータ個々について承認者からの口頭または書類による承認を取り付けていたため、作業の効率面で問題がある。さらに、口頭や書類で承認を取り付けた後であっても、前者であれば、第三者がその内容について承認済みであるか否かを確認することが困難になり、後者であれば、他の書類に紛れるなどの理由による承認用書類の紛失の可能性があるため、申請手続きの管理面において問題が生じるおそれがある。また、承認者による承認が得られなかった場合、申請者は再度その申請内容を訂正して、再度承認者からの口頭または書類による承認を取り付けなければならず、申請者の作業負担もさらに大きくなる。
本実施の形態に係る申請処理システム12によれば、申請表取得部122により電子申請表データが取得されたか、あるいはユーザデータ取得部154により一ユーザのユーザデータが取得されたかに応じて、一括処理部120による一連の処理あるいは個別処理部150による一連の処理のいずれかを実行できる。その結果、申請者は、例えば、申請対象のユーザのユーザデータが一時に大量に存在する場合であれば、一括処理部120による一連の処理を、申請対象のユーザのユーザデータが少数であれば、個別処理部150による一連の処理のいずれかを選択でき、その結果、ユーザデータの登録申請、変更申請または削除申請に関する申請業務作業の効率化を実現できる。
さらに、本実施の形態に係る申請処理システム12によれば、ユーザデータの登録申請、変更申請または削除申請を行うための電子申請書を順次、申請者端末200、承認者端末202、システム管理者端末204および従データベース管理者端末206の画面上に表示する。そのため、申請者、承認者、システム管理者および従データベース管理者は、不定期に生じた申請対象者のユーザデータに関する申請や承認などの手続きを、各端末上に順次表示された電子申請書を介して実施すればよく、作業の効率化を図ることができる。この申請処理システム12によれば、申請者は承認者からの口頭や書類による承認を取り付ける必要がないため、申請者の作業負担をも軽減できる。
さらに、本実施の形態に係る申請処理システム12によれば、申請者、承認者、システム管理者および従データベース管理者の各端末間で電子申請書を回覧させることで、申請から承認、システムの反映までの時間を短縮できる。その結果、例えば、退職者のユーザデータを申請処理システム12上から削除する場合であれば、余分な時間をかけることなくデータベース上からその退職者のユーザデータを削除できるため、その退職者などによる不正アクセスの危険性を軽減できる。
本実施の形態に係る申請処理システム12では、ユーザデータを格納する主データベースの数はシステムで一つであるため、ユーザデータの一元管理を可能にする。さらに電子表データ、電子申請書や各端末上の操作をログして申請処理サーバ100内に保持できるため、申請手続きの管理面において優れている。
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。そうした変形例を以下に挙げる。
実施の形態に係る申請処理システム12の導入場所は企業内であったが、変形例として病院や大学などの他の施設内に設けられてもよい。この場合、病院であれば患者、医者や看護師のユーザデータ、大学であれば新入学生や卒業生のユーザデータの登録、変更または削除申請がこの申請処理システム12を用いて行われる。
実施の形態では、主データベース102、第1従データベース104aおよび第2従データベース104bは申請処理サーバ100内に含まれているが、変形例として申請処理サーバ100の外部にそれぞれ設けられてもよい。また、第1従データベース104aおよび第2従データベース104bは、リレーショナルデータベースやネットワーク型データベースであってもよい。また、LDAPに準拠した主データベース102を認証サービスに用いてもよい。
実施の形態では、電子申請表データ210の入力をシステム管理者端末204上で行ったが、変形例として、申請者端末200や従データベース管理者端末206上で行ってもよい。
実施の形態では、申請表取得部122により取得された電子申請表データに含まれる申請データや電子申請書に含まれるユーザデータは、まず最初に、主データベース102内の中間領域上に登録されたが、変形例として、直接、主データベース102内の正規領域上に登録されてもよい。この場合、上述した実施の形態において、中間領域と正規領域とを同一視でき、中間領域と正規領域とを区別する必要はなくなる。
社内で運用される業務システムのネットワーク構成の一部を示す図である。 本実施の形態に係る申請処理サーバの構成を示す図である。 電子申請表データのデータ構造の一例を示す図である。 電子申請表データの電子申請表列名と主データベースの主データベース属性名とを対応付けた第1マッピング表を示す図である。 主データベースにおける社員番号「0001」を示すユーザデータの保存状態を階層的に示す図である。 主データベースの正規領域上の主データベース属性名と従データベース上の従データベース属性名とを対応付けた第2マッピング表を示す図である。 システム管理者の端末上に表示された承認ルートの設定画面を示す図である。 申請者端末上に表示された登録用の電子申請書の入力フォームを示す図である。 承認者端末の画面上に表示された承認用の電子申請書を示す図である。 システム管理者端末の画面上に表示された承認用の電子申請書を示す図である。 個別従データベース選択部により選択された従データベース管理者端末の画面上に表示された、承認用の電子申請書を示す図である。 本実施の形態に係る申請処理の流れを示す図である。
符号の説明
12 申請処理システム、 102 主データベース、 104 従データベース、 120 一括処理部、 122 申請表取得部、 124 関連付け部、 126 一括主データベース処理部、 128 一括従データベース選択部、 130 一括従データベース処理部、 150 個別処理部、 152 申請書フォーム表示部、 154 ユーザデータ取得部、 156 承認用申請書生成部、 158 承認者表示部、 160 承認者指示受付部、 162 個別主データベース処理部、 164 システム管理者端末表示部、 166 個別従データベース選択部、 168 従データベース管理者表示部、 170 システムデータ取得部、 172 個別従データベース処理部、 200 申請者端末、 202 承認者端末、 204 システム管理者端末、 210 電子申請表データ、 212 処理種別欄、 222,226,230 申請データ、 224,228,232 ユーザデータ、 310 電子申請書の入力フォーム、 320 ユーザデータ入力欄群、 350,370,380 承認用の電子申請書、 382 システムデータ入力欄群。

Claims (4)

  1. 申請対象のユーザの個人情報を示すユーザデータの登録申請、変更申請または削除申請を受け付け、前記受け付けた申請の内容を当該システム上に反映する申請処理システムであって、
    前記システムは、
    前記申請対象のユーザのユーザデータを格納する主データベースと前記主データベースを補助する複数の従データベースとを有するサーバと、
    前記サーバに対しネットワークを介して接続され、少なくとも申請者端末と複数の承認者端末と当該システムの管理者端末と前記複数の従データベースの管理者端末とを有する複数の端末装置と、
    を備え、
    前記サーバは、さらに一括処理部と個別処理部とを有し、
    前記一括処理部は、
    前記申請対象のユーザのユーザデータと前記ユーザデータを対象とした前記主データベースに対する処理の種別を示す処理種別データとを有する申請データを複数含む電子申請表データを前記ネットワークを介して取得する申請表取得部と、
    前記電子申請表データに含まれる複数の申請データのそれぞれに含まれる前記ユーザデータと前記処理種別データとを関連付ける関連付け部と、
    前記複数の申請データのうち一の申請データに含まれるユーザデータを対象に、そのユーザデータに関連付けられた処理種別に基づいて定められる前記主データベースに対する登録、変更または削除処理のうちいずれかの処理を実行し、さらに、他の申請データについても前記いずれかの処理を繰り返すことで前記複数の申請データを一括して処理する一括主データベース処理部と、
    前記複数の従データベースのうち一つ以上の従データベースの選択指示を受け付け、その選択指示に従って一つ以上の従データベースを選択する一括従データベース選択部と、 前記一括主データベース処理部により処理された複数の申請データを対象とした前記一括処理を前記選択された従データベースに対して実行する一括従データベース処理部と、
    を有し、
    前記個別処理部は、
    申請対象の一ユーザのユーザデータを項目ごとに入力するためのユーザデータ入力欄を有する電子申請書の入力フォームを前記申請者端末の画面上に表示する申請書フォーム表示部と、
    前記電子申請書の入力フォームのユーザデータ入力欄に入力された一ユーザのユーザデータを前記申請者端末から前記ネットワークを介して取得するユーザデータ取得部と、
    前記取得された一ユーザのユーザデータを含む承認用の電子申請書をユーザごとに生成する承認用申請書生成部と、
    申請者ごとに定めた複数の承認者による承認の順序としてあらかじめ設定された承認ルートに従って、前記複数の承認者の承認者端末のそれぞれの画面上に前記承認用の電子申請書を順次表示する承認者表示部と、
    前記表示された承認用の電子申請書を承認するか否かの指示を前記複数の承認者の承認者端末のそれぞれから受け付ける承認者指示受付部と、
    前記複数の承認者の承認者端末から承認指示を受け付けた承認用の電子申請書に含まれる一ユーザのユーザデータを対象に、その承認用の電子申請書の種別に基づいて定められる前記主データベースに対する登録、変更または削除処理のうちいずれかの処理を実行することで、ユーザデータを個別に処理する個別主データベース処理部と、
    前記承認を受け付けた承認用の電子申請書を前記システムの管理者端末の画面上に表示するシステム管理者端末表示部と、
    前記複数の従データベースのうち一つ以上の従データベースの選択指示を前記システムの管理者端末から受け付け、その受け付けた選択指示に従って一つ以上の従データベースを選択する個別従データベース選択部と、
    前記選択された一つ以上の従データベースの管理者の管理者端末のそれぞれの画面上に前記承認を受け付けた承認用の電子申請書を表示する従データベース管理者表示部と、
    前記従データベースに対するユーザデータの登録、変更または削除処理に必要なシステムデータを前記表示された従データベース管理者の管理者端末のそれぞれから前記ネットワークを介して取得するシステムデータ取得部と、
    前記取得されたシステムデータを参照することで、個別主データベース処理部により処理された一ユーザのユーザデータを対象とした前記個別処理を、前記選択された一つ以上の従データベースのそれぞれに対して実行する個別従データベース処理部と、
    を有し、
    前記申請表取得部により前記電子申請表データが取得された場合に、前記サーバは前記一括処理部による一連の処理を実行し、一方、前記ユーザデータ取得部により前記一ユーザのユーザデータが取得された場合に、前記サーバは前記個別処理部による一連の処理を実行することを特徴とする申請処理システム。
  2. 前記承認用の電子申請書は、前記システムデータを入力するためのシステムデータ入力欄を備え、前記システムデータ取得部は、前記承認用の電子申請書内のシステムデータ入力欄に入力された前記システムデータを取得することを特徴とする請求項1に記載の申請処理システム。
  3. 前記主データベースの数は当該システムに一つであることを特徴とする請求項1または2に記載の申請処理システム。
  4. 前記主データベースは、LDAP(Lightweight Directory Access Protocol)に準拠することを特徴とする請求項1から3のいずれかに記載の申請処理システム。
JP2005366217A 2005-12-20 2005-12-20 申請処理システム Pending JP2007172120A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005366217A JP2007172120A (ja) 2005-12-20 2005-12-20 申請処理システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005366217A JP2007172120A (ja) 2005-12-20 2005-12-20 申請処理システム

Publications (1)

Publication Number Publication Date
JP2007172120A true JP2007172120A (ja) 2007-07-05

Family

ID=38298632

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005366217A Pending JP2007172120A (ja) 2005-12-20 2005-12-20 申請処理システム

Country Status (1)

Country Link
JP (1) JP2007172120A (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2011778A2 (en) 2007-06-29 2009-01-07 Noritake Co., Limited Composite ceramic body, method of manufacturing the same and ceramic filter assembly
JP2010039786A (ja) * 2008-08-05 2010-02-18 Ohbayashi Corp 情報共有システム及びユーザ登録方法
JP2012252573A (ja) * 2011-06-03 2012-12-20 Nippon Telegr & Teleph Corp <Ntt> 情報流通システム及び情報流通制御方法
CN104880224A (zh) * 2015-05-20 2015-09-02 巫立斌 一种环境检测方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002099829A (ja) * 2000-09-25 2002-04-05 Impress:Kk 個人情報管理サーバ、及び、個人情報管理システム
JP2003196434A (ja) * 2001-12-28 2003-07-11 At Work Corp 事務処理支援システム、サーバ装置、サーバ装置のプログラムが記録された記録媒体
JP2004227603A (ja) * 2004-04-02 2004-08-12 Casio Comput Co Ltd データ処理装置、データ処理システム及び記録媒体
JP2005084929A (ja) * 2003-09-08 2005-03-31 Toshiba Corp 人事処理システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002099829A (ja) * 2000-09-25 2002-04-05 Impress:Kk 個人情報管理サーバ、及び、個人情報管理システム
JP2003196434A (ja) * 2001-12-28 2003-07-11 At Work Corp 事務処理支援システム、サーバ装置、サーバ装置のプログラムが記録された記録媒体
JP2005084929A (ja) * 2003-09-08 2005-03-31 Toshiba Corp 人事処理システム
JP2004227603A (ja) * 2004-04-02 2004-08-12 Casio Comput Co Ltd データ処理装置、データ処理システム及び記録媒体

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2011778A2 (en) 2007-06-29 2009-01-07 Noritake Co., Limited Composite ceramic body, method of manufacturing the same and ceramic filter assembly
JP2010039786A (ja) * 2008-08-05 2010-02-18 Ohbayashi Corp 情報共有システム及びユーザ登録方法
JP2012252573A (ja) * 2011-06-03 2012-12-20 Nippon Telegr & Teleph Corp <Ntt> 情報流通システム及び情報流通制御方法
CN104880224A (zh) * 2015-05-20 2015-09-02 巫立斌 一种环境检测方法

Similar Documents

Publication Publication Date Title
US6856962B2 (en) Schedule management system
US7133833B1 (en) Lightweight directory access protocol workflow management system
US20100017223A1 (en) Electronic donor medical records management system
JP2006099751A (ja) プロジェクトを構成するタスクに人員を割当てるための方法、プログラムおよびコンピュータ
JP2007172120A (ja) 申請処理システム
TW476898B (en) A human resource management service system
JP2003085090A (ja) 情報共有システム
JP2008203909A (ja) アカウント管理システム
JP4431300B2 (ja) 電子文書回覧システム
JP2005228059A (ja) アカウント管理システム及びその方法
JPH1173459A (ja) ワークフロー管理システムおよびドキュメント管理操作方法
JP4080687B2 (ja) 電子手続システムのサーバ装置
JP2021103592A (ja) 文書管理装置および文書管理方法
US7379942B2 (en) Approval authority registration system and method
JP2006085705A (ja) データ処理装置及び記憶媒体
JP2003203145A (ja) 人事管理支援システムおよび方法
JP2003296529A (ja) メモ情報管理プログラム及びメモ情報管理装置
JP2001306766A (ja) 名刺管理・名刺交換システム
JP7317659B2 (ja) 計算機システム及び連携制御方法
JP3677448B2 (ja) 認証関係管理システム及びこれに用いるサーバ装置、認証関係管理方法、記録媒体
JP5145838B2 (ja) 組織異動情報管理システム、組織異動情報管理方法及び組織異動情報管理プログラム
JP2003162613A (ja) ワークフロー管理方法及びその実施装置
JP2005084929A (ja) 人事処理システム
JP6420597B2 (ja) 一覧表管理システム
JP2002304503A (ja) 就業データ管理システムおよび就業データ管理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20071126

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100316

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100706