(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0010】
(システム概要)
本実施の形態に係るISO認証取得支援装置はコンピュータシステム上で実現され、CPU(Central Processing Unit)と、ROM(Read Only Memory)と、RAM(Random Access Memory)と、画像処理部と、メモリを備えている。CPU、ROM、RAM、画像処理部及びメモリは、バスを介して相互に接続されている。
【0011】
CPUは、ROMに記録されているプログラム、又はメモリからRAMにロードされたプログラムに従って各種の処理を実行する。RAMには、CPUが各種の処理を実行する上において必要なデータ等も適宜記憶される。
【0012】
画像処理部は、DSP(Digital Signal Processor)や、VRAM(Video Random Access Memory)等から構成されており、CPUと協働して、画像のデータに対して各種画像処理を施す。
【0013】
メモリは、DRAMやキャッシュメモリ、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等何らかの記憶媒体が挙げられる。メモリは、バスにより接続されるもののみならず、ドライブを介して読み書きされるものも含まれる。本実施形態で記憶されたデータは、一時的記憶も不揮発性メモリによる長期記憶の場合も、このメモリにいったん記憶するものとして説明する。
【0014】
本実施の形態に係るISO認証取得支援装置には入出力インターフェースが接続されている。入出力インターフェースを介して、表示部、撮像部、入力部、通信部が接続されている。入力部は、各種ボタンにより構成され、ユーザの指示操作を受け付ける。通信部は、インターネットを含むネットワークを介して他の装置との間で行う通信を制御する。
【0015】
本実施の形態に係るISO認証取得支援装置は、それぞれ以上の各構成を備えるが、機能的構成についてはそれぞれ後述する。各機能的構成は、CPU、ROM、RAM、画像処理部及びメモリの協働動作により機能的に実現される。これらの各部の機能は電子回路又はプログラムによって提供されるモジュール構成であり、プログラムについてはROMに格納され、CPUにより適宜読み出しながら各部と協働することで実行される。
【0016】
(データベース概要)
本実施の形態に係るISO認証取得支援装置は、その機能的構成として、規則の主体と項目をISO認定基準に沿って記述した複数の手順を、それぞれ対象者を識別して記憶する手順記憶部(ルールDB)を備える。また、複数の手順に関連する規格を定めた規格データを記憶する規格記憶部(規格DB)をさらに備える。すなわち、手順、ルール、規格の各コンテンツをモジュールデザインで設計し、規格/ルールのDBとする。
【0017】
また、時期ごとの実行すべき複数の行動計画を、それぞれ対象者を識別して記憶する計画データ記憶部(計画DB)を備える。すなわち、計画PLAN、実行DO、評価CHECKも上記と同様の手法で、DB(データベース)化し、計画/実行のDB(データベース)とする。また、手順記憶部に記憶された複数の手順のいずれかからそれぞれが関連付けられた複数の参照情報を記憶する参照情報記憶部(参照情報DB)をさらに備える。なお、以上の手順記憶部(ルールDB)、規格記憶部(規格DB)、計画データ記憶部(計画DB)、参照情報記憶部(参照情報DB)については、単にDBと記載して説明する。
【0018】
(フィルタリング概要:抽出部)
さらに、対象者を選択して、複数の手順から当該対象者に該当する対象者手順を抽出し、複数の行動計画から対象者に該当する対象者計画を抽出する抽出部を備える。抽出部による抽出処理の一例としてフィルタリング処理があり、認証システムで、DBのカラム、レコードの条件を選択指定し、そのフィルタリングにて、各規格の複数の手順文書を部署、担当、テーマごとに自動生成する。サイト頁上で、ルールのDBと計画のDBからフィルタリングし、Iframeを利用した各テーブルの組合せ配置で、各規格の複数の手順文書を部署、担当、テーマごとに自動生成し、手順文書の最小化を可能にする。以下、本システムのフィルタリング処理として説明するものは、本実施の形態の抽出部によって実行される処理である。
【0019】
(画面表示概要:表示部)
さらに、本システムは、表示部を備える。表示部は、本システムにおいて前日の画像処理部によって画像処理された画像を表示するディスプレイ装置として実現される。表示部は、選択された対象者について、抽出部によって抽出された対象者手順及び対象者計画を、それぞれ別フレームの1画面上にまとめて表示する。
【0020】
表示部は、上記、2種のDBからフィルタリングされた各テーブルをiframeにて、サイト頁上で配置することにより、サイトページ内のテーブル間同士で検索・照合を可能にしかつ、紙媒体として利用する時、印刷は頁全体を一括出力する。また、各種計画書、記録書(教育計画、監査計画、全体計画、年間計画、是正報告など)はそのDB内で、日時または期間を基準にフィルタリングしたテーブルにて、過去文書として表示できるので、旧版ファイルの保持を不要にする。以下、本システムの表示処理として説明するものは、本実施の形態の表示部によって実行される処理である。
【0021】
(PDCA概要:反映部)
さらに、表示部によって表示された対象者手順と対象者計画について、活動記録を入力し、入力結果を手順記憶部(ルールDB)に記憶された複数の手順及び計画データ記憶部(計画DB)に記憶された複数の行動計画に反映する反映部を備える。反映部により、各専用画面上に承認機能を置き画面からPDCAを展開できる。以下、本システムのDB、フィルタリング、表示処理を除くすべての処理は、本実施の形態の反映部によって実行される処理である。特に監査、承認などのPDCAにかかる処理は反映部によって実行される。
【0022】
以上のISO統合認証取得及び維持装置によれば、DBに構築されたテーブル間同士で、操作による検索・照合が可能になり、DBに構築されたモジュール間のリンクで、反映部による審査対応が容易になる。また、参考情報の配置にてコンサルの支援を不要、または最小化する構成をDBでもつことにより、反映部により、二者、三者監査、内部監査ではリモート監査で、同じ画面の共有にて双方向のコミュニケーションと証跡表示と監査基準、監査結果の設定、登録が簡易化される。このように、各サイト画面上に管理者の承認機能をおくことで、部署、担当、テーマごとにサイト上でPDCAが展開できる。
【0023】
そして、サイトコンテンツと上記各テーブルのモジュール(カラム)をa href(エーエイチレフ)で結合させたデータベースを備えることで、顧客の理解と反映部を介した審査対応が容易になる。また、二者、三者監査、内部監査ではリモート監査にて実施し、画面共有にて、双方向のコミュニケーションと証跡表示を可能にし、監査の設定基準を簡易化する。
【0024】
以上の構成によれば、各種自動化エンジンの実装で、画面上から、PDCAを展開でき、(データレス)各規格、手順は、共有モジュールを含むため、文書修正に不整合、矛盾は、発生せず、1度の修正で、変更履歴が自動生成されかつ、共有モジュールを含むため、顧客ごとのISO統合認証の構成を容易にする認証システムであり、二者、三者監査、内部監査を実装した認証システムである。以上の各要素の概要につき、さらに詳細に説明する。
【0025】
図1は、本実施の形態の設計コンセプトとシステム連携の概略を示す。
図1に示すようにISO基準に準拠したマニュアル及び関連画面をディスプレイに表示する(左上)。表示部は、この表示画面はルールDB、計画DB、規格DBの各データベースの内容をそれぞれ対応する表示画面上の位置に割り当てて表示する。そこで、ルールDB、計画DB、規格DBに対してユーザが操作をすることで、単に画面上にマニュアルを表示するというだけにとどまらず、実行すべき事案を計画し、実際に実行に移し、実行結果を確認して、軌道修正する、いわゆるPDCAサイクルに沿った活動を本システムに反映することが可能となる。
【0026】
従来のISO準拠の手順書では、
図1の右上に示すマニュアル、一般規定、システム規定、運用規定、各種手順、を1つの冊子として羅列をしていたため非常に扱いづらかった。本実施の形態では、ルールDBにデータを保管し、これを利用者の属性ごとにフィルタリングして表示すると共に、確認結果の入力を促す。そして、このシステム全体を従来の単純なドキュメントの集まりではなく、モジュール設計するので、データをコンパクトにし、自動化を実現する。特に担当、管理層、事務局にとって、表示画面上のボタン操作だけで、「教育を受ける、展開する、監査・審査を受ける、活動の記録を残す」という点を簡単に実現することができる。
【0027】
以上の情報について、従来では膨大な量を表示しなければならなかったが、本実施の形態によれば、最小画面で実質的に大量の情報を表示すると共に、照合、検索も可能となる。
【0028】
図2は、文書体系・コンテンツ構成の差異とモジュール設計について説明する。ISO準拠の手順書については、従来は方針を上位にして、規定、手順、そして記録類の順に下位になっていくいわゆるピラミッド型の文書体系を採用していた。本実施の形態では、各DBに、手順書の各要素を、5W1Hで記述した基幹部分の最小構成別にまとめたものとしている。すなわち、方針、マニュアル規定、手順、計画、記録、承認を文書化情報の具体的な内容としてまとめている。その上で参考情報、すなわち参考、ガイドライン、解説、自社独自ルール、FAQなどの、ISO基準上特に必須ではない部分について、規格から分離し、参照DBに構成する。このようにして、手順書の各要素をフラット型で構成する。
【0029】
一方でコンテンツ構成については、従来はシステム上で実現する場合は、サイトページに直接記載し、ファイルサーバとリンクをするという構成にしていた。本実施の形態では、ルールDB,計画DB、規格DBとそれぞれ独立したデータ群として用意した上で、これらに対するPDCAの行為をPDCAモジュールとしてそれぞれ用意し、モジュール間でリンクを構成して保管する。その結果、表示部は、ユーザの表示画面上に、ルールDB,計画DB、規格DBのそれぞれに基づくテーブルの組み合わせを、それぞれ別フレームとして表示することで操作及び確認を容易にしている。
【0030】
データについては、従来はファイルごとにアップロードで保存され、保存されたままの状態で表示されるいわゆる静的なコンテンツであったところ、本実施の形態では、個別の電子ファイルの集合という形式をとらずシステムとして提供し、利用者の状態に応じて表示項目や操作項目を変更する動的なコンテンツとして本システムを提供する。
【0031】
図3は、各データベースの概要を示す。本実施の形態によれば、手順書として保存の対象となっているのは、ルールDB、計画DB,規格DBであり、それぞれ別の構成となっている。一方でこれらの各DBは、本体としてのマニュアル部分の他に、一般規定、部門規定、運用規定(D−実行)、監査規定(C−点検)、承認(A−改善)、年間計画(P−計画)、そして参考情報へと、それぞれ抽出部によりフィルタリングされる。抽出部は、フィルタリングの結果として、マニュアルの表示操作に対して、マニュアル管理用TB(テーブル)、変更履歴TBを抽出する一方で、一般規定に対しては一般規定TB、部門規定に対しては部門規定TB、というようにフィルリングしていく。
【0032】
<各DBの概要:文書階層化⇒DB化⇒情報の動的連動>
Webサイト上で、「マニュアル」を市販規格書ベースにSVO,5WIHの追加登録で簡易にデータベース構築して、規格の根幹部分(比較的固定的な部分)とする。根幹部分のスリム化は、全体像を把握しやすくする。文書階層の概念は、フラットな階層とし、上記の部分と手順+「参考情報(流動的な部分)」で区分けする。参照DBの参考情報(ノウハウ、FAQ、教育情報、解説)の初期配置は、コンサルの支援を不要または、最小化する。参考情報は、運用時、ユーザーが、社内事情に合わせ容易に、追加、削除、変更ができ、規格の要求事項でないため、不適合を防止できる。この構成より、各業種、業態ごとの雛形マニュアルは不要となる。
【0033】
「マニュアル」「手順書」群の”文書内の情報”と活動をモジュールとし、データベース化して、DBとしてシステムに内蔵する。そのDB化により、文章の重複部分が削除できるため、文書体系の最小化に効果がある。ISO統合認証システムの場合は、各ISOの共通部分を作成し、規格ごとにページを追加する。
【0034】
反映部による「手順書」群の更新時は、1箇所の変更で、各手順書、関連文書と更新履歴が連動しているため、手順書間の不整合は生じず、自動化につき、管理負荷が軽減されている。全サイト文書を承認一覧にて管理し、更新、作成、承認の氏名、日時の情報は連動する。「計画、活動、点検、改善」の各要素も同様の処置で、複数のデータベースを構成する。
【0035】
「規格」DBの各テーブルは、「ISMS,QMS,EMSなどの規格」「適合宣言書」「内部監査基準」「二者監査基準」などで構成する。「ルール、管理策」DBの各テーブルは、「マニュアル」「ハンドブック」「運用点検」「変更履歴」などで構成する。「計画/活動」DBの各テーブルは、「全体計画、監査計画、月間計画、実績、来期計画」などで構成する。旧版、現行、未来文書は、抽出部による日時のフィルタリングで一元管理し、ファイルでの保持を不要にする。
【0036】
図4は、本システムを適用するシステム全体構成の概念図を示す。左側の図に示すように、ISO準拠の二者監査のシステムを、会社ごとのサーバにインストールする一方で、コンサルタントが各社サーバへのアクセス権限を有し、管理を行う。各社のサーバには各社の顧客が、それぞれ登録・閲覧を介してアクセスして各社に対応したシステムをそれぞれ利用する。
【0037】
各社ごとのイメージは、
図4の右側に示すとおりである。システムをインストールしているA社のサプライヤがD社であり、二者監査に際して本システムを利用するとき、データベース全体のうちの監査画面を、A社が監査側として、D社が被監査側としてアクセスしてフィードバックを行う。
【0038】
図5は、ルールDBの構成を示す。
図5に示すように、各手順を「内容」に示した項目別にルールデータベース内のテーブルとして保存する。そして各手順について、点検状態などのステータスと、区分などの各種属性情報を関連付けて保存する。
【0039】
図6Aは、ルールDBの各種テーブルと文書の動的連携の仕組みを示す。
図6Aに示す各項目を入力することにより、ルールDBとして保存する各手順を登録していく。各手順の項目として、まず点検月があり、入力された月ごとに点検を行うための項目である。表示部は、これに関して、月が替わるごとに運用点検表という項目として表示画面上に自動表示する。
【0040】
さらにその下に、不適合、監査、マニュアル、担当、についての各項目をチェックボックスへのチェックにより入力することで各項目を入力してDBを再構築する。それによりマニュアル、ハンドブック、監査規定、等の専用文書を作成することができる。さらに
図6Aに示すように、管理策として具体的な内容を登録する。そして、「変更」のチェックボックスをチェックすることにより、変更履歴として内容を入力していくことができる。
【0041】
図6Bは、運転点検表の自動表示を示す。
図6Aに示したようにルールDBを登録すると、表示部は、月が替わるたびに、
図6Bに示す運転点検表を自動表示する。業務については毎月点検が必要な事項があるので、この点検が必要な事項を、
図6Aに示した登録事項に沿って、
図6Bに示す運転点検表として表示する。ここで、IDが28、31、32、と割り振られたそれぞれの項目が、マニュアルに記述された規則であり、これらの規則の集合によりマニュアルが構成されている。
【0042】
例えばここでは「担当が」というようにそれぞれ主語を記載することにより、規則に服する主体が明確化されて記述されるが、文の中に明確に主語がなければならないわけではなく、ID28のように主語はないものの、従業員全体が対象となるのが明確な規則もあり、何らかの形で各規則の対象者が明確となっている。これらの規則は、言い換えると手順であり、この複数の手順を含むマニュアルが各データベースに記憶されている。
【0043】
なお、対象者はフィルタリングの項目と対応した動作及び規則の対象者であり、例えば事務局、一般社員、管理者、経営者、担当者などが図示されている。データベースに登録されている多数の手順の中から、対象者を選択してフィルタリングすることにより、対象者手順が選択され、
図6Bから
図6Eの各図に示す対象者ごとの規則が表示される。これは
図7以降も同様である。
【0044】
表示部によって表示された対象者手順と対象者計画について活動記録を入力することにより、反映部は、入力結果を前記手順記憶部に記憶された複数の手順及び前記計画データ記憶部に記憶された複数の行動計画に反映する。ここで活動記録とは、本システムのいずれかの対象者による操作入力により、アクションの結果としての活動の記録である。例えば計画に対する実行内容を記録したものや、単にクリックの結果、証跡として記録されるものも含む。反映部の処理を
図6Cを参照して説明する。
【0045】
図6Cは、トップ画面のマニュアル表示から、事務局側の使用者がクリック操作により、マニュアル、ハンドブック、監査規定などの専用文書を作成する際の表示画面を示す。データベースでは、各項目のうち、a hrefコードとしてリンク先を設定しておくことにより、証跡を表示する項目を設けてもよい。証跡とは、データベースに対する操作記録であり、例えばマニュアル上にリンクを張った状態でデータベースに記録があって、ユーザがそのリンク先をクリック操作により参照した場合は、反映部は、そのクリック操作をしたことを、証跡として記録する。そして監査において、その証跡を後日確認することができるようにする。
【0046】
図6Dでは、左側に一般社員用ハンドバックについての専用文書を例を示す。
図6Eは、是正一覧の自動表示を示す。操作により表示部は、是正一覧を自動表示する。
図6Fは上に監査規定を示し、監査目的、プログラム、責任についてのフィルタリング後の表示画面を示す。下は変更履歴の表示画面であり、その右図に示すように、権限を有する者がクリック操作をすることにより、「変更履歴」を承認することができる。
【0047】
図7Aは、計画(活動)DBの概要を示す図である。具体的には、全体計画TB、監査計画TB,月間計画TB、実績TB,来季計画TB,教育計画TB,議事録TBなどで構成する。これらの各項目は単一の行動計画として記述され、対象者ごとにフィルタリングをかけることにより、対象者ごとの対象車計画が抽出される。上述の各TBはフィルタリングの結果である。
図7Aに示すように、各手順はそれぞれ、対象部署、開始及び終了時刻、タイトル、対象者、内容、評価の各項目を含む。
【0048】
図7Bは、計画DBの入力画面を示す。反映部は、入力結果に基づき、以下の活動記録をデータベースに反映していく。操作者はまず、
図7Bに示す入力画面から、手順を1つずつ入力して計画DBに登録していく。最初の入力項目としては評価があり、この項目で、社員の計画に対して、管理者が実施したかどうかの評価をする。さらに
図7Aでも説明した各項目を入力する。入力項目にはタイトルがあるが、タイトルと対象者の組み合わせによるフィルタリング(チェックのみ)により、担当別、部門別の全体計画、教育計画、監査計画、運用計画などの目的に応じたテーブルを作成することができる。
【0049】
また、開始時刻と終了時刻を入力、登録事項を参照することにより、各計画の過去、現在、未来と区分表示することができる。よって、各TBの組み合わせ方法で、使用目的に応じて、01サイトでは管理者用のルール、月間計画を、02サイトでは一般社員のルール、全体計画、実績、評価を、03サイトでは情報システム部のルールと計画を、04サイトでは運用時のルール、計画、実績、評価、承認を、05サイトでは、監査時のルール、計画、実績、評価、承認を、それぞれ表示することができる。
【0050】
図8Aは、計画(活動)DBのテーブルの概要を説明する図である。今回の年間計画及び実績を選択した場合、左上の1全社年間計画に示すように表示画面に表示する。さらにフィルタリングによっては、右上に示すように昨年実績として表示をすることも可能である。日付によるフィルタリングをすることで、過去文書の保持も不要となり、未来文書も一元管理をすることができる。また右下に示すように日時のフィルタリングにより、来年の年間計画を表示してもよい。
【0051】
図8Bは、計画(活動)DBのテーブルの概要を説明する図である。左上に全社の月間計画を月間カレンダーの形式で表示する。所定の項目をクリックすることにより、右下のデポ年間計画として該当する計画テーブルをフィルタリングして表示する。
図8Cは、内部の監査計画の一覧を示す。内部監査についてフィルタリングすることにより、計画DBについては
図8Cの上の通り表示する。一方で二者監査についてフィルタリングすることにより、
図8Cの下の通り表示する。
【0052】
図9Aは、規格DBの概要を示す。規格記憶部(規格DB)は、上述の複数の手順に関連する規格を定めた規格データを記憶する。規格データには、項目ごとに、それぞれタイトルと管理策が列挙されている。規格DBは、規格TB,適合宣言書TB,内部監査基準TB,二者監査基準TBを共通のデータベースとして有する。フィルタリングの結果として、これらの各TBを抽出表示する。
【0053】
図9Bは、規格DBの入力画面を示す。それぞれ、タイトル、管理用項目、などの入力項目があり、採否理由、実施、監査などの各項目をチェックボックスを介して入力する。監査のチェックボックスには内部管理、内部担当、二者監査、情報システムなどの様々な項目があり、選択した監査項目に従って画面表示し、入力を受け付ける。
【0054】
図10Aは、規格DBの各テーブルを説明する図である。
図10Aは特に、ホーム画面で表示する照合用の規格DBのテーブルを示す。
図10Bは、規格DBのテーブルのうち、適用宣言TBを上の図に示す。それぞれ規格DBから項目選択で作成する。案件ごとに、電子承認の段階として、起案、審査、承認のそれぞれの段階が示されており、反映部の処理として、それぞれチェックボックスにより承認する。そして、各段階について、承認者の役職、氏名、承認の日時が対応付けられて表示する。
図10Bの下には、規格DBの具体的な対応する内容を示す。それぞれタイトル、項目・管理策の他、採否理由と実施の有無がそれぞれ用意されている。
図10Cは、内部監査及び二者監査用の規格DBの概要を示す。監査時に監査基準を選択すると、内部監査用を選択した場合は左の画面、二者監査用を選択した場合は、右の画面が表示される。
【0055】
図11は、参考情報の例を示す。上述の各DBに対応付けられる各項目については、リンクにより参考情報を提示することができる。マニュアルの手順書については、ISOの基準に沿って作成するが、ISOの基準に沿う部分は最小限の資料として作成し、ISO基準とは関係のない部分については、参考情報として分離して構成する。参考情報の例を
図11の左に示すが、例えばサイトの操作方法、教育用の情報、参考用の動画などを用意することができる。参考情報へのアクセスについては、
図11の右に示すように、上部のバーをクリックすることにより、例えば対応する操作方法の動画を表示してもよい。
【0056】
<機能、役割の専用画面、TBの組合せ>
図12A及び
図12Bは、マニュアル全体のサイト画面を示す。
図12に示すサイトのトップメニューで、ルールを左側に示し、PDCAを右側に示す。さらに、その右側に示すように、
図11に示した参考情報を組合せたサイトを配置する。ルールサイトは、「01-HOME(事務局用)」「02-ハンドブック(一般社員用)」「03-部門用」「04-運用規定」「05-監査規定」とする。各サイト内で、複数DBからフィルタリングした各テーブルをiframeのプログラムコードで囲い、組合せる。
【0057】
以上のように構成することにより、文書体系の最小化と文書表示の最大化が両立し、かつ文書間検索・照合、(項番の照合)表示が可能で、読込み速度が向上する。紙媒体としての利用をする時、印刷は頁全体を一括出力できる。
【0058】
担当ごとの専用画面で、サイト頁に対応した「計画(目標を含む)、手順、文書化した情報、証跡、参考情報」などをフラットに一括表示し、かつ管理者、経営者の点検、承認機能などを具備する。各専用担当の画面から、ルールと計画を確認したうえで、PDCAが展開できる。コンテンツは、文書と記録の一体化構造であり、審査員の質問順に並べて配置され、各手順書のタイトルまたは内容、テーブルのカラムのモジュール間をahrefで結合し、担当ごとの専用画面で、審査対応を容易にした。
【0059】
図13A及び
図13Bは、ハンドブックのサイト画面を示す。
図14A及び
図14Bは、運用規定のサイト画面を示す。
図15は、監査規定のサイト画面を示す。
図16は、二者監査のサイト画面を示す。ハンドブック、運用規定、監査規定、二者監査についても、対応関係は
図12の各図と同様である。
【0060】
図17Aは、監査チェックリストを示すサイト画面を示す。上に監査チェックリストを示し、下に是正報告を表示し、さらに右上側に計画DBの内部監査に関する項目、右下側に企画DBの不適合及び是正処置に関する項目を表示する。これらが一画面にまとめられる。左上の監査チェックリストは、左下の是正報告書の情報と連動し、右側の計画DB及び企画DBとの組み合わせで構成され、互いに自動連動する。
図17Bは、承認文書のサイト画面を示す。承認文書の管理画面と各サイトのページは連動し、作成、更新日時、氏名は連動化してそれぞれ画面表示される。
【0061】
二者監査、内部監査はリモート監査で、同じ画面を共有し、双方向のコミュニケーションができるため、柔軟な質問が可能になる。回答は、システムに登録し、必要時、関係者のみ閲覧可能にする。なお被監査側の一方的な登録でも運用可能の設計とする。 内部、二者監査の画面では、「計画書、計画承認書、監査基準、手順、報告書、監査結論」など一体構造であり、規格DB化より、監査基準を容易に設定できる。
【0062】
なおアクセス権、設定について、各画面には、必要な権限者のみ操作、登録、閲覧などの選択が可能なアクセス制限が設定されている。承認システムは、AD連携とアクセス制御、プログラム制御されたログの取得で、承認を可能とする。
【0063】
図18は、台帳のシステム化の概要図を示す。台帳としては情報管理台帳があり、その例を
図18の左側に示す。左上が保管用のデータであり、右下がリスク分析に関するデータである。それぞれ文書名としての資産名称が定義づけられており、各資産にそれぞれの項目が登録されている。このうちの資産の1つをクリックすることにより、登録画面が表示され、情報管理台帳用の資産に関する項目について登録する。
図18の右側にはリスクアセスメント手順が示されている。リスクアセスメント手順の情報を、ユーザの作業手順の参照用に表示する。
【0064】
通常は、各種管理台帳を東京支店、大阪支店、または、人事部、経理部など部署または、拠点ごとに作成し、内容の多くは共通項目である。従来の台帳を用いる場合には、特に更新時に修正箇所が多いと、その台帳は、管轄ごとの管理者のミスによって、共通項の不一致が発生する場合がある。当システムでは、多くの重複する項目は、一元管理で一人で入力できるため、その懸念はなくなる。それをフィルタリングしたTBにて、部署、拠点ごとの表示と入力が可能となる。すなわち、各種台帳も当システムにて、一元管理ができるので、部署ごとの作成が不要になる。
【0065】
<構築、運用フロー>
ユーザー側での構築時、「マニュアル」は市販規格書をベースに最小で構成するため、SVOまたは5WIHを主体としてデータベース登録する。必要事項は、
図11の「参考情報」を参照しながら登録する。運用時は、その手順と計画が各画面に自動表示されるので、それに従い、PDCAを展開する。活動の証跡は、文書でなく、クリックで完結する事で、運用の負荷を軽減する。
【0066】
図19は、構築、運用フローを示す。本実施の形態では、
図19に示す通りのPDCAの順序に従ってサイトを構築していく。最初に経営者が認証範囲を決定して、適用範囲を設定してから、一連の処理に進む。計画PLANフェーズでは、最初に各種文書を作成する。具体的には、ルールDB,計画DB,規格DBに登録される各種情報をここで登録していく。すなわち、事務局が登録手順に従ってマニュアル及び規格文書を「ルールDB」に登録し、各種計画を「計画DB」に登録し、規格及び基準を「規格DB」に登録する。さらに参考情報(目標含む)を登録し、それぞれ関連付ける。
【0067】
これらのDB文書を、文書化情報として登録し、モジュール設計により登録し、自動連係手段により相互に連携する。その結果、ルールDB,計画DB,規格DBが構築される。次に、事務局により、
図18に示した情報管理台帳を作成して登録する。そしてリスクアセスメントによる管理策を追加登録する。
【0068】
図3と説明が共通するが、文書化情報としては、一番上の参照情報として、参考情報、各種台帳ガイドラインが含まれる。ルールDBのTBとして、マニュアル、監査規定、運用規定、一般規定、変更履歴が含まれる。計画DBのTBとして、年間計画、月間計画、監査計画、教育計画、実績、が含まれる。規格DBのTBとして、監査基準、是正報告、適用宣言書、が含まれる。
【0069】
それから実行DOフェーズに移行する。ここでまずリスク対応計画及び運用を行い、それから教育及び訓練を、サイト上のマニュアルや参照資料などに基づいて行う。特に管理層は、計画DBからフィルタリングされた各計画とルールにより、リスク対応計画を運用して、教育を行う。その結果は、システムに適宜登録する。
【0070】
それから点検CHECKフェーズに移行する。ここで、有効性評価、内部監査を行う。以上の各フェーズで、登録参照処理を行った場合には、文書化情報、ルールDB,計画DB,規格DBとの間で適宜連携処理を行う。特に管理責任者は、有効性を評価し、システムに登録する。NGの場合には再教育する。一方で監査員は、監査計画により、内部監査を全社で実施する。結果を評価し、システムで登録する。NGの場合には管理策の見直しを図る。
【0071】
最後に改善ACTフェーズに移行する。まず経営者がマネジメントレビューでそう評価する。そして今後の方針をアウトプットとしてシステムに登録する。NGの場合には、システム全体の見直しを図る。その上で、継続的改善を続けることになる。すなわち、システム全体を進化させ、PDCAを有効に典型することで、継続的な改善を続けていく。
【0072】
以上のように、各データベースのテーブルをシステムに登録し、監査、運用、一般向けなどの各種用途に合わせて、フィルタリングして画面表示することで、PDCAサイクルに沿った操作入力を促す。従来のISOマニュアルでは、共通するデータについても各種用途別に繰り返し文書化していたのでデータ量が非常に冗長になっていたが、データを共通化して登録し、必要に応じてフィルタリングを掛ける構成にしたことで、データ量の大幅な削減が可能となった。
【0073】
その上で、計画DBなどのPDCAサイクルの入力により、ISOマニュアルの利用状況を適宜管理することができるので、単に持っているだけの有用性の低かったマニュアルを、利用状況を把握しやすくし、利用を促進された有用性の高いマニュアルにしていくことができる。その結果、二者監査などの外部への利用にもより使い勝手が高くなり、効果の高いISO準拠マニュアルを提供できる。
【0074】
以上、本発明について実施例を用いて説明したが、本発明の技術的範囲は上記実施例に記載の範囲には限定されない。上記実施例に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。その様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。