JP2010061303A - 情報管理システム及び情報管理方法 - Google Patents

情報管理システム及び情報管理方法 Download PDF

Info

Publication number
JP2010061303A
JP2010061303A JP2008225158A JP2008225158A JP2010061303A JP 2010061303 A JP2010061303 A JP 2010061303A JP 2008225158 A JP2008225158 A JP 2008225158A JP 2008225158 A JP2008225158 A JP 2008225158A JP 2010061303 A JP2010061303 A JP 2010061303A
Authority
JP
Japan
Prior art keywords
incident
information
data
overall
management server
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.)
Granted
Application number
JP2008225158A
Other languages
English (en)
Other versions
JP5256946B2 (ja
Inventor
Takashi Shimamura
隆 島村
Shinichi Chino
伸一 千野
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.)
Ricoh Co Ltd
Original Assignee
Ricoh 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 Ricoh Co Ltd filed Critical Ricoh Co Ltd
Priority to JP2008225158A priority Critical patent/JP5256946B2/ja
Publication of JP2010061303A publication Critical patent/JP2010061303A/ja
Application granted granted Critical
Publication of JP5256946B2 publication Critical patent/JP5256946B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】独自ルールが異なっていても、画一的にインシデント情報を統括して管理することができる情報管理システム及び情報管理方法を提供する。
【解決手段】統括管理サーバ20は、複数の企業内管理サーバ10に接続されている。企業内管理サーバ10の制御部11は、インシデントデータがインシデントデータ記憶部13に登録されると、独自ルールがある場合にはルール変換を行ない、変換した値を用いて通報条件を満足するか否かを判断する。制御部11は、通報条件を満足した場合には、通報データを統括管理サーバ20に送信し、統括データ記憶部25に登録する。モーニングコール時刻になった場合、企業内管理サーバ10は、更新データ送信要求を統括管理サーバ20に行ない、統括管理サーバ20からインシデント更新情報を取得し、インシデント情報の更新処理を実行する。
【選択図】図1

Description

本発明は、インシデント情報を管理する情報管理システム及び情報管理方法に関する。
近年、企業において、事件等の各種インシデントが発生した場合には、これらの再発防止を行なっている。この場合、各種インシデントの再発を防止するためには、発生したインシデントについての情報(インシデント情報)を各部署間で共有することが有効である。特に、最近では企業形態も多様化しており、複数のグループ企業からなる形態もある。そこで、グループ会社において共有する情報を、データベースを用いて管理する情報管理システムが検討されている(例えば、特許文献1参照。)。この特許文献1に記載の技術では、グループ企業内において、グループ内の物品の調達や経理処理などのフォーマットを統一し、グループ社内をイントラネットで結び、このイントラネット上に集中データベースを設ける。この場合、集中データベースにアクセスする場合には、社内サーバに設けられている社員マスタと、入力された社員番号及びパスワードとが照合されて、データベースへのアクセス権の認証が行なわれるとともに、この社員の所属する会社コードが取得される。そして、この会社コードをキーとしてデータベースへのアクセスが行なわれ、各社のパラメータ等に従って表示画面の制御等が行なわれ、入力された情報が保存される。保存された情報は、経理システムの端末や受発注を行なうシステム等に提供される。
特開2005−149392号公報(図5〜図7)
ところが、グループ会社で共有する情報を管理する情報管理サーバに、グループ会社の各クライアント端末から個別にアクセスを受けた場合、この情報管理サーバの負荷が大きくなる。負荷が大きくなった場合には、各クライアント端末に対して、円滑なデータの提供を行なうことができない。
一方、最初から基準を統一しているのであれば、統一したルールの構築は容易であるが、各グループ会社が既に独自ルールに基づいて、情報の管理を行なっている場合がある。この場合、一方的に独自ルールを統一ルールに変更すると、余計な手間や混乱を招く場合がある。また、各グループ会社において周知するまでもないと考えているインシデント情報であっても、他のグループ会社にとっては有意義な情報の場合もあるため、各グループ会社の独自ルールに縛られずに、画一的に管理することも必要である。
本発明は、上述の課題に鑑みてなされ、その目的は、独自ルールが異なっていても、画一的にインシデント情報を統括して管理することができる情報管理システム及び情報管理方法を提供することにある。
上記問題点を解決するために、請求項1に記載の発明は、インシデント情報を記憶するインシデントデータ記憶手段、独自ルールと統括ルールとの対応情報を記憶するルール対応データ記憶手段、及びクライアント端末に接続されるローカル制御手段を備えたローカルサーバと、インシデント情報を記憶する統括データ記憶手段、及び前記ローカルサーバに接続する統括制御手段を備えた統括管理サーバとを有する情報管理システムであって、前記ローカル制御手段は、前記クライアント端末からインシデント情報を取得した場合、このインシデント情報を管理登録情報として前記インシデントデータ記憶手段に記録するインシデント情報記録手段と、前記インシデントデータ記憶手段に前記管理登録情報を記
録した場合、この管理登録情報に含まれている前記独自ルールに基づいて設定された設定値を、前記ルール対応データ記憶手段の前記対応情報を用いて、前記統括ルールに基づく設定値に変換し、変換したインシデント情報を含めた管理登録情報を前記統括管理サーバに送信する報告手段とを備え、前記統括制御手段は、前記ローカルサーバから前記管理登録情報を取得した場合、この管理登録情報を前記統括データ記憶手段に記憶する統括情報記録手段を備えたことを要旨とする。
請求項2に記載の発明は、請求項1に記載の情報管理システムにおいて、前記ローカル制御手段は、前記統括管理サーバにインシデント情報を送信する通報条件を記憶した通報条件記憶手段に接続されており、前記報告手段は、前記統括ルールに基づく設定値に変換した後、この変換した設定値と前記通報条件の値とを比較し、変換した設定値が通報条件を満たした場合には、この管理登録情報を前記統括管理サーバに送信することを要旨とする。
請求項3に記載の発明は、請求項1又は2に記載の情報管理システムにおいて、前記ローカル制御手段は、予め定めたコール時刻毎に、前記統括管理サーバにインシデント情報の送信要求を行ない、これに応じて取得したインシデント情報を前記インシデントデータ記憶手段に記憶する情報更新手段を更に備え、前記統括制御手段は、前記ローカルサーバからの要求に応じて、前記統括データ記憶手段に記録されたインシデント情報を前記ローカルサーバに送信する情報配布手段を更に備えたことを要旨とする。
請求項4に記載の発明は、請求項3に記載の情報管理システムにおいて、前記情報更新手段は、前記統括管理サーバからインシデント情報を取得した場合、このインシデント情報に含まれる前記統括ルールに基づく設定値を、前記ルール対応データ記憶手段の前記対応情報を用いて、前記独自ルールに基づく設定値に変換し、変換したインシデント情報を前記インシデントデータ記憶手段に記憶することを要旨とする。
請求項5に記載の発明は、インシデント情報を記憶するインシデントデータ記憶手段、独自ルールと統括ルールとの対応情報を記憶するルール対応データ記憶手段、及びクライアント端末に接続されるローカル制御手段を備えたローカルサーバと、インシデント情報を記憶する統括データ記憶手段、及び前記ローカルサーバに接続する統括制御手段を備えた統括管理サーバとを有するシステムにおける情報管理方法であって、前記ローカル制御手段が、前記クライアント端末からインシデント情報を取得した場合、このインシデント情報を管理登録情報として前記インシデントデータ記憶手段に記録するインシデント情報記録段階と、前記インシデントデータ記憶手段に前記管理登録情報を記録した場合、この管理登録情報に含まれている前記独自ルールに基づいて設定された設定値を、前記ルール対応データ記憶手段の前記対応情報を用いて、前記統括ルールに基づく設定値に変換し、変換したインシデント情報を含めた管理登録情報を前記統括管理サーバに送信する報告段階とを実行し、前記統括制御手段は、前記ローカルサーバから前記管理登録情報を取得した場合、この管理登録情報を前記統括データ記憶手段に記憶する統括情報記録段階を実行することを要旨とする。
(作用)
本発明によれば、ローカル制御手段は、入力端末からインシデント情報を取得した場合、このインシデント情報を管理登録情報として前記インシデントデータ記憶手段に記録する。ローカル制御手段は、インシデントデータ記憶手段に管理登録情報を記録した場合、この管理登録情報に含まれている独自ルールに基づいて設定された設定値を、ルール対応データ記憶手段の対応情報を用いて、前記統括ルールに基づく設定値に変換し、変換したインシデント情報を含めた管理登録情報を統括管理サーバに送信する。統括制御手段は、ローカルサーバから前記管理登録情報を取得した場合、この管理登録情報を統括データ記
憶手段に記憶する。このため、独自ルールに基づいて設定された設定値を、統括ルールに基づいて設定され設定値に変換したインシデント情報を統括管理サーバに送信する。従って、統括管理サーバは、独自ルールが異なるローカルサーバからのインシデント情報を、画一的に管理することができる。
本発明によれば、ローカル制御手段は、統括ルールに基づく設定値に変換した後、この変換した設定値と通報条件の値とを比較し、変換した設定値が通報条件を満たした場合には、この管理登録情報を前記統括管理サーバに送信する。このため、統括管理サーバは、統括ルールに基づく一定の基準で、各ローカルサーバからインシデント情報を取得することができる。従って、統括管理サーバは、通報条件が満たされたインシデント情報を自動的に取得して管理することができる。
本発明によれば、ローカル制御手段は、予め定めたコール時刻毎に、統括管理サーバにインシデント情報の送信要求を行ない、これに応じて取得したインシデント情報をインシデントデータ記憶手段に記憶する。統括制御手段は、ローカルサーバからの要求に応じて、統括データ記憶手段に記録されたインシデント情報をローカルサーバに送信する。このため、統括制御手段からはローカル制御手段に対して自由にアクセスできない場合であっても、ローカルサーバから取得して管理しているインシデント情報を、ローカルサーバに定期的に提供することができる。このため、ローカルサーバに接続されるクライアント端末は、統括管理サーバに直接アクセスしなくても、他のローカルサーバにおいて登録されたインシデント情報を取得することができる。
本発明によれば、ローカル制御手段は、統括管理サーバからインシデント情報を取得した場合、このインシデント情報に含まれる統括ルールに基づく設定値を、ルール対応データ記憶手段の対応情報を用いて、独自ルールに基づく設定値に変換し、変換したインシデント情報をインシデントデータ記憶手段に記憶する。このため、ローカルサーバにアクセスしてインシデント情報を閲覧する者は、他のローカルサーバにおいて登録されたインシデント情報を、自分のところの独自ルールに従った設定値で把握することができる。
本発明によれば、独自ルールが含まれている場合には、統括ルールに変換したインシデント情報を統括管理サーバに送信するので、統括管理サーバは、独自ルールが異なるローカルサーバからのインシデント情報を、画一的に管理することができる。
以下、本発明を具体化した一実施形態を図1〜図6に基づいて説明する。本実施形態においては、複数のグループ会社と、これらグループ会社を統括する統括会社において、インシデント情報を共有する場合を想定する。図1に示すように、各グループ会社のローカルサーバとしての企業内管理サーバ10と、統括会社の統括管理サーバ20とを備えた情報管理システムとして説明する。本実施形態では、企業内管理サーバ10は、各会社内において発生したインシデントに関する情報(インシデント情報)を管理する。ここで、インシデントには、発生した事件等の事象だけでなく、実際には事件に至らなかったが事件になった可能性のあった事象(いわゆる「ヒアリ・ハット」と呼ばれる事象)も含む。また、統括管理サーバ20は、各グループ会社内で発生したインシデント情報を統括的に管理し、企業内管理サーバ10からの要求に応じて管理している各インシデント情報を各企業内管理サーバ10に配信する。
企業内管理サーバ10は、統括管理サーバ20を含め外部装置からの書き込みはできないものとする。この企業内管理サーバ10は、各会社内において使用される複数のクライアント端末(図示せず)に接続され、これらクライアント端末からの書き込みを許容する
。クライアント端末は、各種データや指示等を入力したり選択したりするためのキーボード及びポインティングデバイスと、各種処理画面を表示するためのディスプレイを備える。
企業内管理サーバ10は、ローカル制御手段としての制御部11、接続データ記憶部12、インシデントデータ記憶部13、ルール対応データ記憶部14及び通報条件データ記憶部15を備える。ここで、インシデントデータ記憶部13はインシデントデータ記憶手段として機能し、ルール対応データ記憶部14はルール対応データ記憶手段として機能し、通報条件データ記憶部15は通報条件記憶手段として機能する。
制御部11は、図示しないCPU、RAM及びROM等を有し、後述する処理(インシデント情報記録段階、報告段階及び情報更新段階等を含む処理)を行なう。そして、このための企業内管理サーバ用プログラムを実行することにより、制御部11は、接続手段110、設定処理手段111、インシデント報告手段112、ルール変換手段113及び、情報更新手段としてのモーニングコール処理手段114として機能する。更に、制御部11は、クライアント端末からインシデント情報をインシデントデータ記憶部13に記憶するインシデント情報記録手段として機能する。
接続手段110は、統括管理サーバ20に接続するための処理を実行する。この接続手段110は、統括管理サーバ20を特定する接続先特定データを記憶しており、この接続先特定データを用いてネットワークを介して接続された統括管理サーバ20にアクセスする。
設定処理手段111は、統括管理サーバ20の接続先特定データ及びモーニングコール時刻を取得して、統括管理サーバ20への接続及びモーニングコール処理の開始時刻等の設定処理を実行する。この設定処理手段111は、企業内管理サーバ10が最初に統括管理サーバ20に接続した場合に処理を実行する。
インシデント報告手段112は、インシデント情報を統括管理サーバ20に送信する処理を実行する。このインシデント報告手段112は、クライアント端末を介してこの企業内管理サーバ10に登録されたインシデント情報のみを送信する。
ルール変換手段113は、この企業内管理サーバ10において用いられるルールに基づいて付与された設定値を、統括管理サーバ20において用いられるルールに基づいた設定値に変換する処理を実行する。
モーニングコール処理手段114は、毎朝、所定時刻になる度に、統括管理サーバ20にアクセスしてインシデント情報を取得し、インシデントデータ記憶部13に記録する。これにより、モーニングコール処理手段114は、インシデント情報の更新処理を実行する。
一方、接続データ記憶部12は、図2(a)に示すように、各企業内管理サーバ10が統括管理サーバ20に接続するために用いる接続データ120を記憶している。この接続データ120は、企業内管理サーバ10が統括管理サーバ20に最初にアクセスした場合に記録される。この接続データ120には、組織コード、データベース番号(DB番号)、モーニングコール時刻に関するデータが含まれる。
組織コードデータ領域には、この企業内管理サーバ10がインシデント情報を管理している組織(本実施形態では、各グループ会社)を特定するための識別子(組織コード)に関するデータが記録される。
DB番号データ領域には、この組織においてインシデント情報を管理しているデータベースを特定するための識別番号(DB番号)に関するデータが記録される。このDB番号及び組織コードによって、企業内管理サーバ10を特定することができる。
モーニングコール時刻データ領域には、この企業内管理サーバ10が統括管理サーバ20に毎朝、アクセスするための時刻に関するデータが記録される。
インシデントデータ記憶部13は、図2(b)に示すように、各グループ企業において管理しているインシデントデータを記憶している。このインシデントデータには、インシデント属性データ131及びインシデント文書データ132が含まれる。インシデント属性データ131は、インシデント情報の属性に関するデータである。インシデント文書データ132は、インシデント情報について作成された文書に関するデータである。
インシデント属性データ131には、インシデント識別子、統括識別子、分類項目、重要度及び登録日時に関するデータ等が含まれる。
インシデント識別子データ領域には、各インシデントを特定するための識別子(インシデント識別子)に関するデータが記録される。本実施形態では、このインシデント識別子は、この企業内管理サーバ10に接続されているクライアント端末から登録されたインシデント情報に対してのみ付与される。
統括識別子データ領域には、このインシデントを特定するために統括管理サーバ20において付与された識別子(統括識別子)に関するデータが記録される。
分類項目データ領域には、このインシデントの分類項目を特定するデータが記録される。ここでは、分類項目として、事件を示す項目、又はいわゆる「ヒアリ・ハット」を示す項目が用いられる。
重要度データ領域には、このインシデントの重要度を示す値に関するデータが記録される。この重要度として、企業内管理サーバ10が管理する会社内における独自の重要度が用いられる。
登録日時データ領域には、このインシデント情報が登録された年月日及びに時刻に関するデータが記録される。
一方、インシデント文書データ132には、インシデント識別子、統括識別子、アクセス制限フラグ、文書種別、文書内容及び更新登録日時に関するデータ等が含まれる。
インシデント識別子データ領域には、各インシデントを特定するための識別子(インシデント識別子)に関するデータが記録される。本実施形態では、このインシデント識別子は、この企業内管理サーバ10に接続されているクライアント端末から登録されたインシデント情報に対してのみ付与される。
統括識別子データ領域には、このインシデントを特定するために統括管理サーバ20において付与された識別子(統括識別子)に関するデータが記録される。
アクセス制限フラグデータ領域には、この文書に対するアクセス制限の有無を示すフラグに関するデータが記録される。本実施形態では、この企業内管理サーバ10に接続されているクライアント端末からインシデント文書データ132が登録された場合にのみ、アクセス制限が「有」に設定することができる。アクセス制限が「有」ことを示すフラグが記録された場合、企業内管理サーバ10は、このインシデント文書データ132を統括管理サーバ20に報告しない。一方、統括管理サーバ20から取得してインシデントデータ記憶部13に記憶したインシデント文書データ132は、アクセス制限が「無」のフラグが記録される。
文書種別データ領域には、この文書の種類を特定するための識別子に関するデータが記録される。文書種別としては、例えば、経過報告書や再発防止書等の文書の種類を特定する識別子データが用いられる。
文書内容データ領域には、この文書の内容に関するデータが記録される。
更新登録日時データ領域には、この文書を登録した日時(年月日及び時刻)、又は文書が更新された場合には文書を更新登録した日時に関するデータが記録される。
ルール対応データ記憶部14は、図2(c)に示すように、独自ルールに基づいて設定された設定値と統括ルールに基づいて設定された設定値とを対応付けた対応データ140を記憶している。具体的には、この対応データ140は、対応項目識別子と、独自ルールに基づくローカル値と、統括ルールに基づく共通値とが対応付けされたデータである。ここで、対応項目識別子は、項目を特定する項目識別子である。また、独自ルールは、各社で用いられる社内ルールである。統括ルールとは、統括会社で用いられる社内ルールである。例えば、重要度を特定する識別子が対応項目識別子として記載されている場合、独自ルールに基づく重要度(ローカル値)と、統括ルールに基づく重要度(共通値)とが対応付けされている。
通報条件データ記憶部15は、通報条件データを記憶している。この通報条件データは、クライアント端末から企業内管理サーバ10に登録されたインシデント情報を統括管理サーバ20に自動的に通報するために満たされる条件に関するデータである。この通報条件データは、企業内管理サーバ10が稼動する前に記録される。通報条件データは、通報条件識別子及び通報条件に関するデータが含まれる。
通報条件識別子データ領域には、各通報条件を特定するための識別子に関するデータが記録されている。
通報条件データ領域には、自動通報するときに満たされる通報条件(データの種類を示す項目識別子及びその値)に関する条件が記録されている。例えば、インシデント属性データ131の分類項目が「事件」で、共通値が予め定められた通報条件値以上のときに自動通報を行なう場合、通報条件のデータの種類として「分類項目」及び「重要度」の項目を示す項目識別子が記録され、それぞれの値として、「事件」及び「通報条件値以上」を示す値が記録される。
一方、この企業内管理サーバ10にネットワークを介して接続されている統括管理サーバ20は、統括クライアント端末(図示せず)に接続されている。この統括クライアント端末は、各企業内管理サーバ10に対して通知する連絡内容を入力したりアラームを出力したりするために用いられる。この統括クライアント端末は、各種データや指示等を入力したり選択したりするためのキーボード及びポインティングデバイスと、各種処理画面を表示するためのディスプレイを備える。
統括管理サーバ20は、統括制御手段としての統括制御部21、組織管理データ記憶部22、コール時刻データ記憶部23、連絡データ記憶部24、統括データ記憶手段としての統括データ記憶部25、及び対応支援要件データ記憶部26を備える。
統括制御部21は、図示しないCPU、RAM及びROM等を有し、後述する処理(統括情報記録段階及び情報配布段階等を含む処理)を行なう。そして、このための統括管理サーバ用プログラムを実行することにより、統括制御部21は、アクセス対応処理手段210、接続データ決定処理手段211、統括情報記録手段としてのインシデント情報登録手段212、対応支援処理手段213及び、情報配布手段としての情報提供手段214と
して機能する。
アクセス対応処理手段210は、企業内管理サーバ10からの要求に応じて、接続データ決定処理手段211、インシデント情報登録手段212及び情報提供手段214に処理を振り分ける処理を実行する。
接続データ決定処理手段211は、企業内管理サーバ10から初めてアクセスがあった場合に、この企業内管理サーバ10に対して、接続を行なうためのデータを決定する処理を実行する。具体的には、接続データ決定処理手段211は、企業内管理サーバ10から組織名を取得し、この組織名に関連付けられている組織コードを特定する。更に、接続データ決定処理手段211は、予め記憶されている時間帯(本実施形態では、6時〜8時)において、既に登録されているコール時刻に対して、処理負荷が大きくならない時刻を新たなコール時刻として決定する。更に、接続データ決定処理手段211は、この統括管理サーバ20に接続するために、統括管理サーバ20を特定する接続先特定データを記憶している。
インシデント情報登録手段212は、企業内管理サーバ10から送信されたインシデント情報を受信した場合に、このインシデント情報を統括データ記憶部25に登録する処理を実行する。
対応支援処理手段213は、統括データ記憶部25に登録したインシデント情報に応じて、このインシデントに対して行なう対応を支援するための処理を実行する。具体的には、登録したインシデント情報が対応支援要件データ記憶部26に記憶された対応支援要件を満足する場合には、この要件に関連付けられた対応内容(例えば報道発表やリコール調査等)を実行するようにアラームをクライアント端末に出力する。
情報提供手段214は、企業内管理サーバ10からの情報取得要求に応じて更新情報送信要求を取得した場合に、統括データ記憶部25に記憶されたインシデント情報を企業内管理サーバ10に送信する。
一方、組織管理データ記憶部22は、図3(a)に示すように、組織を管理するための組織管理データ220を記憶している。この組織管理データ220には、各組織名及びこれに対応する組織コードが含まれる。
組織名データ領域及び組織コードデータ領域には、この組織の名前及びこの組織を特定するための識別子(組織コード)が記録される。本実施形態では、組織名としてグループ会社の会社名を用いる。
また、コール時刻データ記憶部23は、図3(b)に示すように、各企業内管理サーバ10が統括管理サーバ20にアクセスしてくるモーニングコール時刻に関するコール時刻データ230を記憶している。このコール時刻データ230は、接続データ決定処理手段211が、企業内管理サーバ10からのアクセスが分散されるように、新たなコール時刻を決定するために用いられる。更に、このコール時刻データ230は、新たなコール時刻データが決定されると記録される。コール時刻データ230には、組織コード、DB番号及びモーニングコール時刻に関するデータが記録される。
組織コードデータ領域には、この企業内管理サーバ10がインシデント情報を管理している組織を特定するための識別子(組織コード)に関するデータが記録される。
DB番号データ領域には、この組織においてインシデント情報を管理しているデータベースを特定するための識別番号(DB番号)に関するデータが記録される。このDB番号
及び組織コードによって、企業内管理サーバ10を特定することができる。
モーニングコール時刻データ領域には、この企業内管理サーバ10が統括管理サーバ20に毎朝、アクセスするための時刻に関するデータが記録される。
連絡データ記憶部24は、各企業内管理サーバ10に対して連絡する連絡内容に関するデータが記録される。この連絡データは、統括管理サーバ20に接続された統括クライアント端末を介して入力された場合に登録される。この連絡データには、各企業内管理サーバ10に連絡する連絡日及び連絡内容に関するデータが含まれる。
統括データ記憶部25は、インシデント統括データを記憶している。このインシデント統括データには、図3(c)に示すように、インシデント統括属性データ251及びインシデント統括文書データ252が含まれる。インシデント統括属性データ251は、統括管理サーバ20で管理しているインシデントの属性に関するデータである。インシデント統括文書データ252は、統括管理サーバ20で管理しているインシデント情報について作成された文書に関するデータである。
インシデント統括属性データ251には、統括識別子、組織コード、DB番号、インシデント識別子、分類項目、重要度及び登録日時に関するデータ等が含まれる。
統括識別子データ領域には、各インシデントを特定するために統括管理サーバ20において付与された識別子(統括識別子)に関するデータが記録される。
組織コードデータ領域及びDB番号データ領域には、このインシデントが発生した組織を特定するための識別子(組織コード)に関するデータ及びこのインシデントに関する情報が登録されて管理している企業内管理サーバ10を特定するための識別番号(DB番号)に関するデータが記録される。本実施形態では、これら組織コード及びDB番号から、このインシデント情報をクライアント端末から取得して管理している企業内管理サーバ10を特定することができる。
インシデント識別子データ領域には、このインシデントに関する情報を管理する企業内管理サーバ10において、このインシデントを特定するための識別子(インシデント識別子)に関するデータが記録される。
分類項目データ領域には、このインシデントの分類項目を特定するデータが記録される。
重要度データ領域には、このインシデントの重要度を示す値に関するデータが記録される。この重要度として、グループ会社全体で標準化された重要度が用いられる。
登録日時データ領域には、このインシデント情報が登録された日時に関するデータが記録される。
一方、インシデント統括文書データ252には、統括識別子、文書種別、文書内容及び更新登録日時に関するデータ等が含まれる。
統括識別子データ領域には、このインシデントを特定するために統括管理サーバ20において付与された識別子(統括識別子)に関するデータが記録される。
文書種別データ領域及び文書内容データ領域には、この文書の種類を特定するための識別子に関するデータ及びこの文書の内容に関するデータが記録される。
更新登録日時データ領域には、この文書を登録した日時(年月日及び時刻)、又は文書が更新された場合には文書を更新登録した日時に関するデータが記録される。
対応支援要件データ記憶部26には、対応支援要件データを記憶している。この対応支
援要件データは、企業内管理サーバ10から取得したインシデント情報に対応して取り得る対応を実行するために満たされる条件に関するデータである。この対応支援要件データは、統括管理サーバ20が稼動する前までに登録される。対応支援要件データは、対応内容識別子、対応内容及び対応要件に関するデータが含まれる。
対応内容識別子データ領域及び対応内容データ領域には、各対応内容を特定するための識別子に関するデータ及びこの対応内容に関するデータが記録されている。
対応要件データ領域には、各対応内容を実行するときの条件が記録されている。例えば、インシデント統括属性データ251の分類項目が「事件」で、重要度の値が予め定めた対応基準値以上のときに予め定めた対応(例えば報道発表)を行なうとする。この場合には、報道発表を示す識別子及びこの対応内容(報道発表)に関連付けて、対応要件となる項目識別子(分類項目及び重要度を示す項目識別子)と、その各値(「事件」を示す値及び「対応基準値以上」を示す値)とが記憶されている。
以上のように構成された情報管理システムが実行する処理について、図4〜図6を用いて説明する。ここでは、接続設定処理、インシデント報告処理、モーニングコール処理及び閲覧処理の順番に説明する。ここで、接続設定処理では、企業内管理サーバ10が統括管理サーバ20に最初にアクセスした場合に、企業内管理サーバ10と統括管理サーバ20とのデータの送受信を行なうための設定を行なう。インシデント報告処理では、企業内管理サーバ10においてクライアント端末から取得したインシデント情報を統括管理サーバ20に報告する。モーニングコール処理では、毎朝、企業内管理サーバ10からの要求に応じて、統括管理サーバ20がインシデント情報を配信する。閲覧処理では、企業内管理サーバ10に接続されたクライアント端末を用いて、各会社のインシデント情報の管理者が他のグループ会社において発生したインシデントの情報を閲覧する。
(接続設定処理)
まず、企業内管理サーバ10が、新たに設けられて、統括管理サーバ20に最初にアクセスした場合に行なわれる接続設定処理について、図4を用いて説明する。
企業内管理サーバ10の制御部11は、最初に統括管理サーバ20にアクセスして、組織コード及びDB番号の問い合わせ処理を実行する(ステップS1−1)。具体的には、制御部11の設定処理手段111は、クライアント端末からの指示に応じて、統括管理サーバ20にアクセスして接続設定要求を実行する。
この接続設定要求を受信した統括管理サーバ20の統括制御部21は、組織名入力画面データを企業内管理サーバ10に送信する。具体的には、統括制御部21のアクセス対応処理手段210は、インシデント情報を管理する組織名を取得する組織名入力画面データを送信する。企業内管理サーバ10は、クライアント端末のディスプレイに、組織名入力画面を表示する。この組織名入力画面には、組織名を入力する入力欄と送信ボタンとが含まれる。ここで、企業内管理者は、自分の組織名(グループ会社名)を入力欄に入力し、送信ボタンを選択する。クライアント端末は、組織名入力画面に入力された組織名に関するデータを統括管理サーバ20に送信する。
次に、統括管理サーバ20の統括制御部21は、モーニングコール時刻の設定処理を実行する(ステップS1−2)。ここで、統括制御部21は、接続設定要求を送信した企業内管理サーバの組織コード及びDB番号の特定を行なう。具体的には、統括制御部21の接続データ決定処理手段211は、この組織名を含む組織管理データ220を組織管理データ記憶部22から抽出して、この組織名に対応する組織コードを特定する。
次に、接続データ決定処理手段211は、この組織コードを含むコール時刻データ23
0をコール時刻データ記憶部23において検索する。ここで、該当するコール時刻データ230を抽出しなかった場合には、接続データ決定処理手段211は、DB番号として「1」と特定する。また、この組織コードを含むコール時刻データ230を抽出した場合には、このコール時刻データ230の最後のDB番号を特定し、このDB番号の次の番号を、DB番号として特定する。
次に、接続データ決定処理手段211は、コール時刻データ記憶部23に記録されているコール時刻データ230の各モーニングコール時刻を抽出する。そして、接続データ決定処理手段211は、予め記憶されている時間帯と、抽出した各モーニングコール時刻とを用いて、新たなコール時刻を決定する。
そして、接続データ決定処理手段211は、特定した組織コード及びDB番号と、設定したモーニングコール時刻とを関連付けたコール時刻データ230を生成して、コール時刻データ記憶部23に記憶する。
次に、統括管理サーバ20の統括制御部21は、組織コード、DB番号及びモーニングコール時刻の提供処理を実行する(ステップS1−3)。具体的には、統括制御部21の接続データ決定処理手段211は、設定データを企業内管理サーバ10に送信する。この設定データに、コール時刻データ記憶部23に記憶した組織コード、DB番号及びモーニングコール時刻に関するデータを含める。更に、この設定データに、統括管理サーバ20を特定する接続先特定データを含める。
企業内管理サーバ10の制御部11は、組織コード、DB番号及びモーニングコール時刻の記憶処理を実行する(ステップS1−4)。具体的には、制御部11の設定処理手段111は、取得した設定データの組織コード、DB番号及びモーニングコール時刻を含む接続データ120を生成して、接続データ記憶部12に記憶する。また、制御部11の設定処理手段111は、接続手段110に対して統括管理サーバ20を特定する接続先特定データを記憶する。以上により、接続設定処理が終了する。
(インシデント報告処理)
次に、企業内管理サーバ10に接続されているクライアント端末から企業内管理サーバ10に登録されたインシデント情報を、統括管理サーバ20に報告するインシデント報告処理について、図5を用いて説明する。
企業内管理サーバ10の制御部11は、クライアント端末から取得したインシデント情報の登録処理を実行する(ステップS2−1)。具体的には、制御部11のインシデント報告手段112は、クライアント端末からアクセスがあった場合、制御部11に記録されている初期画面データをクライアント端末に送信する。クライアント端末は、各種メニューボタンを含む初期画面をディスプレイに表示する。この各種メニューボタンには、接続設定ボタン、インシデント情報新規入力ボタン、インシデント情報更新入力ボタン及び情報閲覧ボタン等が含まれる。
ここで、インシデントの管理者が、新たに発生したインシデントに関するインシデント情報を新規登録する場合には、初期画面のインシデント情報新規入力ボタンを選択する。クライアント端末は、新規入力画面要求を企業内管理サーバ10に送信する。企業内管理サーバ10は、インシデント属性情報入力欄及び文書選択欄とを含む新規入力画面データを生成して、クライアント端末に送信し、クライアント端末のディスプレイに新規入力画面を表示する。この新規入力画面において、管理者は、インシデントの属性情報として分類項目及び重要度を入力する。
更に、管理者は、文書選択欄において「報告書」の文書を選択する。文書選択欄が選択された場合、クライアント端末のディスプレイには、文書作成画面が表示される。この文書作成画面には、アクセス制限フラグを選択する選択欄、文書内容を記載する記入欄、登録ボタン及び通報ボタンが含まれる。管理者は、選択欄においてアクセス制限フラグを選択して、記入欄に文書内容を記入する。そして、管理者は、このインシデント情報を統括会社に報告して他のグループ会社においても情報共有すべきであると考えた場合には、通報ボタンを選択する。また、管理者が、このインシデント情報をこの企業内管理サーバ10のみで管理し他のグループ会社において情報共有しなくてもよいと考えた場合には、登録ボタンを選択する。
一方、企業内管理サーバ10に既に登録したインシデント情報について更新登録する場合には、初期画面のインシデント情報更新入力ボタンを選択する。クライアント端末は、インシデント情報更新入力画面要求を企業内管理サーバ10に送信する。企業内管理サーバ10の制御部11は、インシデントデータ記憶部13においてインシデント識別子を含むインシデント属性データ131を抽出する。この場合、この企業内管理サーバ10に接続されたクライアント端末から登録されたインシデント情報に関するインシデント属性データ131が抽出される。そして、制御部11は、抽出したインシデント属性データ131を含む一覧リスト画面を生成して、クライアント端末のディスプレイに表示する。
ここで、管理者は、この一覧リスト画面において、更新登録する対象のインシデント情報のインシデント識別子を選択する。クライアント端末は、選択されたインシデント識別子を企業内管理サーバ10の制御部11に送信する。
企業内管理サーバ10の制御部11は、受信したインシデント識別子を含むインシデント属性データ131及びインシデント文書データ132をインシデントデータ記憶部13から抽出して、更新情報入力画面データを生成し、クライアント端末に送信する。クライアント端末は、更新情報入力画面をディスプレイに表示する。この更新情報入力画面には、インシデント文書データ132の文書内容と、追加入力欄と、新たに文書を作成するための新規文書作成ボタンと、新たに作成する文書の種類を選択するボタンと、登録ボタンと、通報ボタンとが含まれている。
ここで、例えば、発生したインシデントの報告書に経過報告を追加する場合には、管理者は、追加入力欄に追加する内容を入力する。また、新たな書類(例えば再発防止書等)を作成して、既に登録したインシデント情報に関するインシデント文書データ132を追加する場合には、新たに作成する文書の種類を選択して、新規文書作成ボタンを選択する。クライアント端末のディスプレイには、文書作成画面が表示される。この文書作成画面には、上述したように、アクセス制限フラグを選択する選択欄、文書内容を記載する記入欄、登録ボタン及び通報ボタンが含まれる。管理者は、この文書作成画面の選択欄においてアクセス制限フラグを選択して、記入欄に文書内容を記入する。そして、管理者は、このインシデント情報を他のグループ会社に対して報告する場合には通報ボタンを選択し、その他の場合には登録ボタンを選択する。
文書作成画面や更新情報入力画面において通報ボタン又は登録ボタンが選択された場合、クライアント端末は、登録データを企業内管理サーバ10に送信する。新規登録の場合、この登録データに、設定された分類項目、重要度、選択された報告書に対応する文書種別、選択されたアクセス制限フラグ、記入欄に入力された文書内容に関するデータを含める。また、更新登録の場合には、インシデント識別子、アクセス制限フラグ、入力された文書の文書種別及び文書内容を含める。更に、通報ボタンが選択された場合には、報告フラグを登録データに含める。
そして、企業内管理サーバ10の制御部11は、インシデント情報を登録する。具体的には、制御部11は、登録データにインシデント識別子が含まれていない場合、インシデント識別子を付与する。そして、制御部11は、このインシデント識別子、取得した新規登録データに含まれる分類項目及び重要度を含むインシデント属性データ131を生成して、インシデントデータ記憶部13に記録する。更に、制御部11は、このときの現在時刻と年月日とを登録日時として、このインシデント属性データ131に含める。そして、制御部11は、付与したインシデント識別子と、受信した登録データの文書種別、アクセス制限フラグ及び文書内容を含むインシデント文書データ132を生成して、インシデントデータ記憶部13に記録する。更に、制御部11は、このときの現在時刻を更新登録日時として、インシデント文書データ132に記録する。なお、この段階では、インシデント属性データ131及びインシデント文書データ132の統括識別子データ領域は空欄とする。
一方、登録データにインシデント識別子が含まれている場合、制御部11は、登録データのインシデント識別子及び文書識別子を含むインシデント文書データ132をインシデントデータ記憶部13において検索する。該当するインシデント文書データ132がある場合には、インシデント報告手段112は、このインシデント文書データ132に、登録データに含まれる文書内容を追加して更新登録する。更に、インシデント報告手段112は、このときの現在時刻を更新登録日時として、インシデント文書データ132に含める。
一方、該当するインシデント文書データ132がない場合には、制御部11は、インシデント識別子、受信したアクセス制限フラグ、文書種別及び文書内容を含むインシデント文書データ132を生成して、インシデントデータ記憶部13に記憶する。更に、制御部11は、このときの時刻を更新登録日時として、このインシデント文書データ132に含める。
次に、企業内管理サーバ10の制御部11は、報告指示の有無についての判断処理を実行する(ステップS2−2)。具体的には、制御部11のインシデント報告手段112は、登録データにおける報告フラグの有無に基づいて判断する。
ここで、登録データに報告フラグが含まれておらず、報告指示がないと判断した場合(ステップS2−2において「NO」の場合)には、企業内管理サーバ10の制御部11は、独自ルールの有無について判断処理を実行する(ステップS2−3)。具体的には、制御部11のインシデント報告手段112は、ルール対応データ記憶部14に対応データ140が記憶されている場合には、独自ルールがあると判断する。
ここで、独自ルールがある場合(ステップS2−3において「YES」の場合)には、企業内管理サーバ10の制御部11は、ルールの変換処理を実行する(ステップS2−4)。具体的には、制御部11のルール変換手段113は、各対応項目識別子に対応するインシデント属性データ131の各設定値(ローカル値)を含む対応データ140をルール対応データ記憶部14から抽出する。そして、ルール変換手段113は、抽出した各ローカル値に対応する対応データ140の共通値を特定し、このインシデント属性データ131のインシデント識別子に関連付けて、メモリに一時記憶しておく。
次に、企業内管理サーバ10の制御部11は、通報条件を満たしたか否かの判断処理を実行する(ステップS2−5)。具体的には、制御部11のインシデント報告手段112は、通報条件データの項目毎の各値と、このインシデント識別子に関連付けてメモリに一時記憶された変換後の共通値とを比較する。
そして、インシデント報告手段112は、登録したインシデントデータが通報条件データの条件を満足し、かつアクセス制限がないことを意味するアクセス制限フラグが登録されていた場合には、このインシデントデータが通報条件を満たしたものと判断する。
ここで、通報条件を満たしていない場合(ステップS2−5において「NO」の場合)又は独自ルールがない場合(ステップS2−3において「NO」の場合)には、インシデント報告処理が終了する。
一方、報告指示がある場合(ステップS2−2において「YES」の場合)又は通報条件を満たした場合(ステップS2−5において「YES」の場合)には、企業内管理サーバ10の制御部11は、通報処理を実行する(ステップS2−6)。具体的には、制御部11のインシデント報告手段112は、この報告フラグが含まれていた登録データから生成したインシデントデータ又は通報条件を満たしたインシデントデータを通報対象とする。そして、接続手段110は、接続先特定データを用いて統括管理サーバ20に接続する。この接続手段110を介して、制御部11のインシデント報告手段112は、通報対象の通報データを統括管理サーバ20に送信する。接続手段110は、この通報データに、接続データ記憶部12の組織コード及びDB番号を含める。
ここで、通報対象のインシデントデータに統括識別子が含まれていない場合、インシデント報告手段112は、このインシデント属性データ131と、これに含まれるインシデント識別子を含むインシデント文書データ132の文書種別、文書内容及び更新登録日時とを通報データに含める。この場合、インシデント属性データ131にローカル値が含まれている場合には、このローカル値の代わりに、変換した共通値を通報データに含める。また、通報対象のインシデント属性データ131に統括識別子が含まれている場合には、インシデント報告手段112は、統括識別子と、この統括識別子を含むインシデント文書データ132の文書種別、文書内容及び更新登録日時とを、通報データに含める。
インシデント通報データを受信した統括管理サーバ20の統括制御部21は、統括データ記憶部25の登録処理を実行する(ステップS2−7)。ここで、統括制御部21のインシデント情報登録手段212は、通報データに統括識別子が含まれているか否かを判断する。
通報データに統括識別子が含まれていない場合には、インシデント情報登録手段212は、統括識別子を付与する。そして、インシデント情報登録手段212は、この統括識別子、インシデント通報データに含まれる組織コード、DB番号及びインシデント属性データ131を含むインシデント統括属性データ251を生成して、統括データ記憶部25に記録する。更に、統括制御部21は、このときの現在時刻を登録日時として、このインシデント統括属性データ251に含める。
更に、インシデント情報登録手段212は、付与した統括識別子と、インシデント通報データに含まれる文書種別、文書内容及び更新登録日時とを含むインシデント統括文書データ252を生成して統括データ記憶部25に記憶する。更に、統括制御部21は、統括識別子をインシデント識別子に関連付けて企業内管理サーバ10に送信する。企業内管理サーバ10は、このインシデント識別子を含むインシデント属性データ131及びインシデント文書データ132の統括識別子データ領域に、取得した統括識別子に関するデータを記録する。
一方、インシデント属性データ131が含まれていない場合には、インシデント情報登録手段212は、受信したインシデント識別子及び文書種別を含むインシデント統括文書データ252を検索する。
この場合、該当するインシデント統括文書データ252を抽出できなかった場合には、インシデント情報登録手段212は、インシデント識別子、受信したインシデント通報データに含まれる文書種別、文書内容及び更新登録日時を含むインシデント統括文書データ252を生成して、統括データ記憶部25に記録する。
一方、該当するインシデント統括文書データ252を抽出できた場合には、インシデント情報登録手段212は、抽出したインシデント統括文書データ252の文書内容及び更新登録日時を記録することによりデータ更新を行なう。
次に、統括管理サーバ20の統括制御部21は、支援要件に該当するか否かの判断処理を実行する(ステップS2−8)。具体的には、統括制御部21のインシデント情報登録手段212は、登録したインシデント統括属性データ251の各項目の値及びインシデント統括文書データ252の各項目の値を、この項目に対応する対応支援要件データの対応要件データ領域に記録された各項目の値と比較する。
そして、統括管理サーバ20の統括制御部21は、このインシデント統括属性データ251及びインシデント統括文書データ252が対応要件の条件を満足した場合(ステップS2−8において「YES」の場合)、アラーム出力処理を実行する(ステップS2−9)。具体的には、統括制御部21の対応支援処理手段213は、満たされた対応要件を含む対応支援要件データの対応内容に関するデータをクライアント端末のディスプレイに表示する。以上により、インシデント報告処理が終了する。
(モーニングコール処理)
次に、企業内管理サーバ10からの要求に応じて、統括管理サーバ20がインシデント情報を配信するモーニングコール処理について、図6を用いて説明する。このモーニングコール処理は、毎日、モーニングコール時刻に実行される。
ここでは、企業内管理サーバ10の制御部11は、現在の時刻がモーニングコール時刻になった場合、更新データ送信要求処理を実行する(ステップS3−1)。具体的には、制御部11のモーニングコール処理手段114は、現在時刻と、接続データ記憶部12に記憶されたモーニングコール時刻とを比較する。そして、モーニングコール処理手段114は、現在時刻がこのモーニングコール時刻を経過した場合、接続手段110を介して統括管理サーバ20に接続する。そして、制御部11のインシデント報告手段112は、更新データ送信要求を送信する。この場合、接続手段110は、接続データ記憶部12に記憶した組織コード及びDB番号を更新データ送信要求に含める。
更新データ送信要求を受信した統括管理サーバ20の統括制御部21は、インシデント更新情報及び連絡情報の提供処理を実行する(ステップS3−2)。ここでは、統括制御部21は、前回のときから現在までに他の企業内管理サーバ10から受信したインシデントデータを提供する。具体的には、統括制御部21の情報提供手段214は、前回(昨日)のモーニングコール時刻から今回(現在日)のモーニングコール時刻までの日時を登録日時とするインシデント統括属性データ251を統括データ記憶部25において検索する。ここで、このインシデント統括属性データ251を抽出した場合、情報提供手段214は、このうち、更新データ送信要求に含まれた組織コード及びDB番号を含むインシデント統括属性データ251を除くインシデント統括属性データ251を特定する。
更に、情報提供手段214は、前回のモーニングコール時刻から今回のモーニングコール時刻までの日時を更新登録日時とするインシデント統括文書データ252を統括データ記憶部25において抽出する。情報提供手段214は、このうち、更新データ送信要求に
含まれた組織コード及びDB番号を含むインシデント統括属性データ251の統括識別子を含まないインシデント統括文書データ252を抽出する。
次に、情報提供手段214は、現在日を連絡日とする連絡内容データを連絡データ記憶部24から抽出する。そして、情報提供手段214は、抽出した連絡内容データと、抽出したインシデント統括文書データ252の統括識別子、文書種別及び文書内容を含む更新提供データを企業内管理サーバ10に送信する。更に、インシデント統括属性データ251が特定できた場合には、情報提供手段214は、このインシデント統括属性データ251の統括識別子、分類項目及び重要度に関するデータを更新提供データに含める。
次に、企業内管理サーバ10の制御部11は、インシデント情報の更新及び連絡情報の更新処理を実行する(ステップS3−3)。具体的には、統括制御部21のモーニングコール処理手段114は、更新提供データの連絡内容データを制御部11のメモリに一時的に記録する。更に、モーニングコール処理手段114は、更新提供データに、インシデント識別子、分類項目及び重要度に関するデータが含まれている場合には、これらを含むインシデント属性データ131を生成して、インシデントデータ記憶部13に記録する。更に、モーニングコール処理手段114は、このときの現在時刻を登録日時として、インシデント属性データ131に含める。
そして、モーニングコール処理手段114は、更新提供データに含まれている統括識別子及び文書種別を含むインシデント文書データ132を生成して、インシデントデータ記憶部13に記録する。更に、モーニングコール処理手段114は、このときの現在時刻を更新登録日時として、インシデント文書データ132に含め、「無」のアクセス制限をこれに含める。以上により、モーニングコール処理が終了する。
(閲覧処理)
各社内におけるインシデント情報の管理者は、新たに更新されたインシデント情報を閲覧する。この場合、管理者の操作に応じて、クライアント端末は、企業内管理サーバ10から初期画面データを取得して、ディスプレイに初期画面を表示する。
ここで、初期画面の新着情報閲覧ボタンが選択されると、クライアント端末は、新着情報取得要求を企業内管理サーバ10に送信する。企業内管理サーバ10の制御部11は、現在日又は前日を登録日時としているインシデント属性データ131を抽出する。更に、制御部11は、現在日又は前日を更新登録日時としているインシデント文書データ132を抽出する。制御部11は、抽出したインシデント文書データ132のうち、アクセス制限フラグが記録されていないインシデント文書データ132のみを抽出する。更に、制御部11のメモリに一時的に記録した連絡内容データを抽出する。そして、制御部11は、抽出したインシデント属性データ131及びインシデント文書データ132と、連絡内容データとを含む新着情報閲覧画面データを生成して、クライアント端末に送信する。クライアント端末は、新着情報閲覧画面をディスプレイに表示する。管理者は、この新着情報閲覧画面を閲覧することにより、他の企業内管理サーバ10でクライアント端末から登録されたインシデント情報及び連絡事項を把握することができる。以上により、閲覧処理が終了する。
本実施形態によれば、以下のような効果を得ることができる。
・ 本実施形態では、企業内管理サーバ10の制御部11は、クライアント端末から取得したインシデント情報を登録し(ステップS2−1)、独自ルールがある場合(ステップS2−3において「YES」の場合)には、ルールの変換処理を実行する(ステップS2−4)。そして、企業内管理サーバ10の制御部11は、通報処理を実行する場合(ステップS2−6)、インシデント属性データ131にローカル値が含まれている場合には
、このローカル値の代わりに、変換した共通値を通報データに含める。このため、独自ルールに基づいて設定されたローカル値を、統括ルールに基づいて設定される共通値に変換したインシデント情報を統括管理サーバ20に送信する。従って、統括管理サーバ20は、独自ルールが異なる各企業内管理サーバ10に登録したインシデント情報を、画一的に管理することができる。
・ 本実施形態では、企業内管理サーバ10の制御部11は、通報条件データの各項目の値と、変換後の共通値とを比較し、通報条件を満たした場合(ステップS2−5において「YES」の場合)には、通報データを統括管理サーバ20に送信する通報処理を実行する(ステップS2−6)。統括管理サーバ20の統括制御部21は、統括データ記憶部25の登録処理を実行する(ステップS2−7)。このため、統括管理サーバ20は、統括ルールに基づく一定の基準で、各企業内管理サーバ10からインシデント情報を取得することができる。従って、各企業内管理サーバ10からの報告指示がない場合(ステップS2−2において「NO」の場合)であっても、統括管理サーバ20は、予め設定した通報条件を満たすインシデント情報を自動的に取得して管理することができる。
・ 本実施形態では、企業内管理サーバ10は、統括管理サーバ20を含め外部装置からの書き込みはできない。企業内管理サーバ10の制御部11は、現在の時刻がモーニングコール時刻になった場合、更新データ送信要求処理を実行する(ステップS3−1)。この更新データ送信要求を受信した統括管理サーバ20の統括制御部21は、インシデント更新情報の提供処理を実行し(ステップS3−2)、企業内管理サーバ10の制御部11は、インシデント情報の更新及び連絡情報の更新処理を実行する(ステップS3−3)。このため、企業内管理サーバ10に接続されているクライアント端末は、統括管理サーバ20にアクセスしなくても、この企業内管理サーバ10にアクセスして、登録されたインシデント情報を取得することができる。従って、統括管理サーバ20にかかる負荷を小さくすることができる。
・ 本実施形態では、企業内管理サーバ10が統括管理サーバ20に最初にアクセスした場合の接続設定処理において、統括管理サーバ20の統括制御部21は、モーニングコール時刻の設定処理を実行する(ステップS1−2)。この場合、統括制御部21は、コール時刻データ記憶部23に記録されているコール時刻データ230の各モーニングコール時刻を抽出する。そして、接続データ決定処理手段211は、予め記憶されている時間帯(本実施形態では、6時〜8時)において、既に登録されているコール時刻に対して、処理負荷が大きくならない時刻を新たなコール時刻として決定する。このため、各企業内管理サーバ10が統括管理サーバ20にアクセスするコール時刻を変更できるので、統括管理サーバ20が統括管理サーバにアクセスする場合の負荷を低減することができる。
また、上記実施形態は以下のように変更してもよい。
○ 上記実施形態のモーニングコール処理において、企業内管理サーバ10の制御部11は、更新提供データを取得した場合、インシデント情報の更新及び連絡情報の更新処理を実行した(ステップS3−3)。この場合、この更新提供データに含まれる設定値を独自ルールに基づく設定値に変換し、変換後の値を用いて、インシデント情報の更新処理を実行してもよい。具体的には、図7に示すように、企業内管理サーバ10の制御部11は、現在の時刻がモーニングコール時刻になった場合、上記ステップS3−1と同様に、更新データ送信要求処理を実行する(ステップS4−1)。次に、更新データ送信要求を受信した統括管理サーバ20の統括制御部21は、上記ステップS3−2と同様に、インシデント更新情報及び連絡情報の提供処理を実行する(ステップS4−2)。
そして、企業内管理サーバ10の制御部11は、上記ステップS2−3と同様に、独自ルールがあるか否かを判断する。ここで、独自ルールがある場合(ステップS4−3にお
いて「YES」の場合)、制御部11は、この独自ルールによる変換処理を実行する(ステップS4−4)。具体的には、制御部11のルール変換手段113は、各対応項目識別子に対応する更新提供データの各値(共通値)を含む対応データ140をルール対応データ記憶部14から抽出する。そして、ルール変換手段113は、抽出した各共通値に対応する対応データ140のローカル値を特定し、このインシデント属性データ131の値として記憶する。そして、企業内管理サーバ10の制御部11は、インシデント情報の更新及び連絡情報の更新処理を実行する(ステップS4−5)。この場合、企業内管理サーバ10の制御部11は、更新提供データに含まれる項目に、対応データ140を用いて変換可能な共通値がある場合には、変換後のローカル値をインシデント属性データ131として記憶することができる。従って、企業内管理サーバ10に接続されているクライアント端末を介してインシデント情報を把握する管理者は、他の企業内管理サーバ10において登録されたインシデント情報を、自分のところの独自ルールに従った設定値で把握することができる。
○ 上記実施形態のモーニングコール処理において、対応データ140には、対応項目識別子に関連付けて、独自ルールに基づくローカル値と、統括ルールに基づく共通値とを関連付けた。この場合、対応データ140を、組織内で使用される用語と統括会社で使用される用語とを対応付けたデータとしてもよい。具体的には、対応データ140を、対応項目識別子として「用語」を特定する識別子を記録し、組織内で使用される組織用語と、統括会社で使用される共通用語とを対応付けて、ルール対応データ記憶部14に記憶する。企業内管理サーバ10の制御部11は、通報処理(ステップS2−6)において、用語ルールの変換を行なってもよい。具体的には、通報処理を行ない場合、制御部11のルール変換手段113は、通報データに含める文書内容の語句と、対応項目識別子として「用語」を特定する識別子の組織用語とを比較する。一致する語句を含む対応データ140の共通用語を抽出し、この用語に置換した文書内容を通報データに含める。
○ 上記実施形態においては、企業内管理サーバ10に通知する連絡内容は、統括管理サーバ20が、統括クライアント端末から取得した。これに代えて、統括管理サーバ20が、企業内管理サーバ10から取得したインシデント情報に応じて、連絡内容を生成してもよい。例えば、同じようなインシデントが多数発生している場合や重大なインシデントが発生している場合等には、これについて注意を促す連絡内容を作成してもよい。具体的には、連絡内容と、この連絡内容を生成する連絡内容生成条件とを関連付けた連絡作成データを、統括管理サーバ20に記憶しておく。連絡内容生成条件には、例えば複数のキーワードや、キーワードと出現個数等がある。統括管理サーバ20の統括制御部21は、モーニングコール時刻が行なわれる時間帯より前の予め定めた時間に、予め定めた期間内に企業内管理サーバ10から受信したインシデント情報の統括識別子を特定する。具体的には、統括制御部21は、インシデント統括属性データ251の登録日時から、前日から現在日までに受信したインシデント情報の統括識別子を特定する。統括制御部21は、特定した統括識別子と、「報告書」の文書種別とを含むインシデント統括文書データ252を特定する。統括制御部21は、特定したインシデント統括文書データ252の各文書内容と、連絡内容生成条件とを比較する。例えば、連絡内容生成条件が複数のキーワードである場合には、これらキーワードが各文書内容に含まれているか否かを検索する。そして、該当する文書内容のインシデント統括文書データ252があった場合には、この連絡内容生成条件に関連付けられている連絡内容を特定する。また、連絡内容生成条件がキーワードと出現個数の場合には、統括制御部21は、同じキーワードを含む文書内容のインシデント統括文書データ252の数をカウントし、出現個数と比較する。出現個数を超えた場合には、統括制御部21は、この連絡内容生成条件に関連付けている連絡内容を特定する。そして、統括制御部21は、特定した連絡内容に関するデータを、現在日を連絡日とする連絡データに含ませておく。これにより、統括管理サーバ20は、企業内管理サーバ10から取得したインシデント情報に応じた連絡内容を自動的に生成して、企業内管理サー
バ10に提供することができる。
実施形態におけるシステムの構成を説明する説明図。 企業内管理サーバが有するデータ記憶部のデータ構成を説明する説明図であり、(a)は接続データ記憶部、(b)はインシデントデータ記憶部、(c)はルール対応データ記憶部である。 統括管理サーバが有するデータ記憶部のデータ構成を説明する説明図であり、(a)は組織管理データ記憶部、(b)はコール時刻データ記憶部、(c)は統括データ記憶部である。 接続設定処理の処理手順を説明するための流れ図。 インシデント報告処理の処理手順を説明するための流れ図。 モーニングコール処理の処理手順を説明するための流れ図。 変更例におけるモーニングコール処理の処理手順を説明するための流れ図。
符号の説明
10…企業内管理サーバ、11…制御部、12…接続データ記憶部、13…インシデントデータ記憶部、14…ルール対応データ記憶部、15…通報条件データ記憶部、20…統括管理サーバ、21…統括制御部、22…組織管理データ記憶部、23…コール時刻データ記憶部、24…連絡データ記憶部、25…統括データ記憶部、26…対応支援要件データ記憶部、110…接続手段、111…設定処理手段、112…インシデント報告手段、113…ルール変換手段、114…モーニングコール処理手段、120…接続データ、131…インシデント属性データ、132…インシデント文書データ、140…対応データ、210…アクセス対応処理手段、211…接続データ決定処理手段、212…インシデント情報登録手段、213…対応支援処理手段、214…情報提供手段、220…組織管理データ、230…コール時刻データ、251…インシデント統括属性データ、252…インシデント統括文書データ。

Claims (5)

  1. インシデント情報を記憶するインシデントデータ記憶手段、
    独自ルールと統括ルールとの対応情報を記憶するルール対応データ記憶手段、及び
    クライアント端末に接続されるローカル制御手段を備えたローカルサーバと、
    インシデント情報を記憶する統括データ記憶手段、及び
    前記ローカルサーバに接続する統括制御手段を備えた統括管理サーバとを有する情報管理システムであって、
    前記ローカル制御手段は、
    前記クライアント端末からインシデント情報を取得した場合、このインシデント情報を管理登録情報として前記インシデントデータ記憶手段に記録するインシデント情報記録手段と、
    前記インシデントデータ記憶手段に前記管理登録情報を記録した場合、この管理登録情報に含まれている前記独自ルールに基づいて設定された設定値を、前記ルール対応データ記憶手段の前記対応情報を用いて、前記統括ルールに基づく設定値に変換し、変換したインシデント情報を含めた管理登録情報を前記統括管理サーバに送信する報告手段とを備え、
    前記統括制御手段は、前記ローカルサーバから前記管理登録情報を取得した場合、この管理登録情報を前記統括データ記憶手段に記憶する統括情報記録手段を備えたことを特徴とする情報管理システム。
  2. 前記ローカル制御手段は、前記統括管理サーバにインシデント情報を送信する通報条件を記憶した通報条件記憶手段に接続されており、
    前記報告手段は、前記統括ルールに基づく設定値に変換した後、この変換した設定値と前記通報条件の値とを比較し、変換した設定値が通報条件を満たした場合には、この管理登録情報を前記統括管理サーバに送信することを特徴とする請求項1に記載の情報管理システム。
  3. 前記ローカル制御手段は、予め定めたコール時刻毎に、前記統括管理サーバにインシデント情報の送信要求を行ない、これに応じて取得したインシデント情報を前記インシデントデータ記憶手段に記憶する情報更新手段を更に備え、
    前記統括制御手段は、前記ローカルサーバからの要求に応じて、前記統括データ記憶手段に記録されたインシデント情報を前記ローカルサーバに送信する情報配布手段を更に備えたことを特徴とする請求項1又は2に記載の情報管理システム。
  4. 前記情報更新手段は、前記統括管理サーバからインシデント情報を取得した場合、このインシデント情報に含まれる前記統括ルールに基づく設定値を、前記ルール対応データ記憶手段の前記対応情報を用いて、前記独自ルールに基づく設定値に変換し、変換したインシデント情報を前記インシデントデータ記憶手段に記憶することを特徴とする請求項3に記載の情報管理システム。
  5. インシデント情報を記憶するインシデントデータ記憶手段、
    独自ルールと統括ルールとの対応情報を記憶するルール対応データ記憶手段、及び
    クライアント端末に接続されるローカル制御手段を備えたローカルサーバと、
    インシデント情報を記憶する統括データ記憶手段、及び
    前記ローカルサーバに接続する統括制御手段を備えた統括管理サーバとを有するシステムにおける情報管理方法であって、
    前記ローカル制御手段が、
    前記クライアント端末からインシデント情報を取得した場合、このインシデント情報を管理登録情報として前記インシデントデータ記憶手段に記録するインシデント情報記録段
    階と、
    前記インシデントデータ記憶手段に前記管理登録情報を記録した場合、この管理登録情報に含まれている前記独自ルールに基づいて設定された設定値を、前記ルール対応データ記憶手段の前記対応情報を用いて、前記統括ルールに基づく設定値に変換し、変換したインシデント情報を含めた管理登録情報を前記統括管理サーバに送信する報告段階とを実行し、
    前記統括制御手段は、前記ローカルサーバから前記管理登録情報を取得した場合、この管理登録情報を前記統括データ記憶手段に記憶する統括情報記録段階を実行することを特徴とする情報管理方法。
JP2008225158A 2008-09-02 2008-09-02 情報管理システム及び情報管理方法 Expired - Fee Related JP5256946B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008225158A JP5256946B2 (ja) 2008-09-02 2008-09-02 情報管理システム及び情報管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008225158A JP5256946B2 (ja) 2008-09-02 2008-09-02 情報管理システム及び情報管理方法

Publications (2)

Publication Number Publication Date
JP2010061303A true JP2010061303A (ja) 2010-03-18
JP5256946B2 JP5256946B2 (ja) 2013-08-07

Family

ID=42188047

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008225158A Expired - Fee Related JP5256946B2 (ja) 2008-09-02 2008-09-02 情報管理システム及び情報管理方法

Country Status (1)

Country Link
JP (1) JP5256946B2 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002073639A (ja) * 2000-08-31 2002-03-12 Nri & Ncc Co Ltd ナレッジマネジメントシステム
JP2003058523A (ja) * 2001-08-21 2003-02-28 Nippon Telegr & Teleph Corp <Ntt> 構造化文書の変換ルール作成方法および装置と変換ルール作成プログラムおよび該プログラムを記録した記録媒体
JP2003162590A (ja) * 2001-11-27 2003-06-06 Fujitsu Ltd 総合的アウトソーシング管理システム
JP2003208382A (ja) * 2002-01-10 2003-07-25 Hitachi Ltd Edi利用ユーザ企業間でのデータフォーマット変換方法とそのシステム
JP2003242007A (ja) * 2001-12-14 2003-08-29 Ricoh Co Ltd 電子データ管理装置、電子データ管理方法、電子データ管理プログラム、記録媒体、及び電子データ管理システム
JP2007148768A (ja) * 2005-11-28 2007-06-14 Keakomu:Kk 看護支援システム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002073639A (ja) * 2000-08-31 2002-03-12 Nri & Ncc Co Ltd ナレッジマネジメントシステム
JP2003058523A (ja) * 2001-08-21 2003-02-28 Nippon Telegr & Teleph Corp <Ntt> 構造化文書の変換ルール作成方法および装置と変換ルール作成プログラムおよび該プログラムを記録した記録媒体
JP2003162590A (ja) * 2001-11-27 2003-06-06 Fujitsu Ltd 総合的アウトソーシング管理システム
JP2003242007A (ja) * 2001-12-14 2003-08-29 Ricoh Co Ltd 電子データ管理装置、電子データ管理方法、電子データ管理プログラム、記録媒体、及び電子データ管理システム
JP2003208382A (ja) * 2002-01-10 2003-07-25 Hitachi Ltd Edi利用ユーザ企業間でのデータフォーマット変換方法とそのシステム
JP2007148768A (ja) * 2005-11-28 2007-06-14 Keakomu:Kk 看護支援システム

Also Published As

Publication number Publication date
JP5256946B2 (ja) 2013-08-07

Similar Documents

Publication Publication Date Title
US8572080B2 (en) Methods and systems for analyzing a network feed in a multi-tenant database system environment
US20070067370A1 (en) Information processing apparatus, information displaying apparatus, and information processing method
CN101867595A (zh) 投影设备
JPH09153050A (ja) 文書情報収集方法および文書情報収集装置
JP2007004694A (ja) コンタクトセンター・システム、個人情報配信装置、配信方法、および配信プログラム
JP6852483B2 (ja) データ管理システム、データ管理方法およびデータ管理プログラム
JP2008269256A (ja) 勤務シフト作成支援装置
JP2008257475A (ja) 情報管理システム、個別管理サーバ、集約管理サーバ及び情報管理方法
JP2019194860A (ja) 求人情報提供サーバ及び/又は求職情報提供サーバ並びに求人情報受領プログラム
JPWO2006046395A1 (ja) 連絡情報管理システム
JP4599036B2 (ja) 業務管理システム
JP5256946B2 (ja) 情報管理システム及び情報管理方法
JP2015109015A (ja) 接続先解決システムおよび接続先解決方法
JP4327686B2 (ja) Eaに基づく個別システムの構築を支援する方法およびシステム
JP4809053B2 (ja) データ連携処理システム、データ連携処理方法及びデータ連携処理プログラム
JP7173619B2 (ja) 脆弱性情報管理装置、脆弱性情報管理方法、およびプログラム
JP6581682B1 (ja) 名刺管理システム
JP2010134552A (ja) コンテンツ管理システム、コンテンツ管理方法及びコンテンツ管理プログラム
JP2001005748A (ja) 共用のデータ表示装置及び記憶媒体
JP2012063896A (ja) データアクセス制御システム、データアクセス制御方法及びデータアクセス制御プログラム
JP2019194823A (ja) 求人情報提供サーバ及び/又は求職情報提供サーバ並びに求人情報受領プログラム
JP2004295531A (ja) 進捗情報管理システム、進捗情報管理装置および進捗情報表示装置
JP2016045532A (ja) 見守りシステム、システム側装置、見守り方法、表示端末、及びコンピュータプログラム
JP7249452B1 (ja) 契約締結プログラム、情報処理装置、情報処理システム、情報処理方法
JP2012190354A (ja) 文書管理システム、及び文書管理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110803

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130321

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130326

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130408

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160502

Year of fee payment: 3

R151 Written notification of patent or utility model registration

Ref document number: 5256946

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees