(57)【要約】      （修正有）【課題】システム修正変更作業において、作業手順を徹底し、効率的な作業が行えるようにする。【解決手段】案件開発／障害対応からシステム修正変更管理、システム修正変更の承認管理、ＳＩ管理（プログラム貸出、本番環境への登録管理等）を連携させ、データベースで一元管理する。また、案件管理／生涯管理、システム修正変更管理、ＳＩ管理は情報を登録する定型画面ビューアを有し、また本ビューアは前記データベースアクセスを行い、案件管理番号、システム修正変更管理番号、ＳＩ管理番号のいずれからでもすべての情報を取得可能とする。【選択図】  図７
2006178798.tif 000002
【特許請求の範囲】
【請求項１】
システム修正変更対応時における、案件開発／障害対応からシステム修正変更管理、システム修正変更の承認管理、ＳＩ管理を一元的にデータベースで管理するシステムで、ネットワークが繋がっている環境であれば、どこでもシステム修正変更対応が可能であり、又、システム修正変更に関する情報が即座に入手可能とするシステム。
【請求項２】
案件管理／障害管理、システム修正変更管理、ＳＩ管理は情報を管理（登録）する定型画面ビューアを有し、該当画面ビューア手段は各管理データベースアクセスを行う表示画面を有し、案件管理番号／システム修正変更管理番号、ＳＩ管理番号いずれからでも全ての情報（案件情報／障害情報、システム修正変更情報、ＳＩ情報）を取得可能とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、案件開発／障害対応に関するさまざま管理情報を一元的にデータベース化し、システム修正変更管理からＳＩ管理まで連携した管理システムに関する。
【背景技術】
【０００２】
案件管理システムとして案件管理情報をデータベースで管理し、案件管理情報の登録、表示させる定型画面ビューアがある。
【０００３】
障害管理システムとして障害管理情報をデータベースで管理し、障害管理情報の登録、表示させる定型画面ビューアがある。
【０００４】
案件開発／障害対応を行う場合のシステム修正変更管理として、システム修正変更管理情報をデータベースで管理し、システム修正変更管理情報の登録、表示させる定型画面ビューアがある。
【０００５】
ＳＩ管理として定型フォーマットを用意しＳＩ情報を一覧化することでＳＩ管理を行う仕掛けがある。又、プログラム貸出／プログラム登録等は手作業で行う。
【０００６】
プログラム登録時、ＳＩ情報を一覧にする事でプログラム本数の把握は可能であったが、案件名／障害名等の把握が困難であった。特にプログラム登録本数が多くなるほど困難であった。
【０００７】
案件管理／障害管理、システム修正変更管理、ＳＩ管理と個別に管理を行っていた為、それぞれに開発（修正）承認／本番環境への登録承認が必要となり作業効率の劣化となる問題点がある。
【０００８】
案件票や障害票が起票されていなくても、システム修正を行う事が可能な手順となっており、セキュリティ面で不安があった。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上記従来技術で記載したように、案件管理／障害管理、システム修正変更管理、ＳＩ管理迄が一元的に管理されていない為、案件管理からＳＩ情報迄の関連付け機能や登録するプログラムからの案件名／障害名の把握が困難であった。
【００１０】
案件管理／障害管理、システム修正変更管理、ＳＩ管理迄を一元的に管理する機能を用意することで、作業手順の徹底、効率的な作業が行えるようなシステムを提供することである。
【００１１】
又、システム修正変更を行う場合は必ず案件票／障害票が必須となるシステムを用意し、セキュリティ面での向上を図ることにある。
【課題を解決するための手段】
【００１２】
上記課題を解決する為に、本発明では各管理ツール（案件管理ツール／障害管理ツール、システム修正変更管理ツール、ＳＩ管理ツール）を一元的に管理する為に、各ツールのデータベースを共有化することにより情報の共有化を図る。
【発明の効果】
【００１３】
本発明では各データベース（案件管理データベース、障害管理データベース、システム修正変更管理データベース、ＳＩ管理データベース）で各種情報を収集・蓄積し、一元管理する事で情報の共有化を図るという効果がある。
【００１４】
また、本発明ではシステムを一元化する事により手順の統一化が可能となり、作業ミスの撲滅、作業効率の向上につながるという効果がある。
【００１５】
さらに、案件管理／障害管理とシステム修正変更管理を連携させる事により、システム修正変更時は必ず案件票もしくは障害票が必要となり、不正なシステム修正変更が不可となる。その事により不正なシステム修正変更を防止することができセキュリティ面が強化できるという効果がある。
【００１６】
さらに、本発明では承認機能の制御や承認されたデータを承認済みであると識別できる文書として印刷するような電子承認の効果的な利用ができるという効果がある。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施の実施形態について図面より詳細に説明する。図１は本発明を適用したシステムの案件が発生した場合の運用フローを示している。図２は本発明を適用したシステムの障害が発生した場合の運用フローを示している。
【００１８】
次にデータベースに蓄積されるデータ（案件管理情報、障害情報、システム修正変更情報、ＳＩ情報）のフィールドについて説明する。
【００１９】
案件管理（「案件票」）のフィールドの例を図３に示す。概略的に「案件票」は、基礎情報として提出先（案件を提出した部署（銀行））、提出日、提出先承認ステータス（提出先作成者、提出先承認者）、依頼件名、完了希望日（提出先からの案件完了希望日）、案件内容、案件対応理由、案件管理番号、対応可否区分、対応条件種別（詳細打合せ要／新規案件扱い／その他）、完了予定日（要求元への対応完了報告予定日）、完了日（要求元への対応完了予定日）、影響範囲別の対応工数（影響業務別の見積工数／実績工数）、問題課題（案件対応する為の問題点）、方針（案件対応する方針）、要求元承認ステータス（要求元回答担当者、要求元回答承認者名）、完了報告日（要求元への完了報告日）からなる。
【００２０】
ここで、案件管理番号は案件毎に一意なように採番登録される。提出先承認ステータス（提出先作成者、提出先承認者）は、提出先による案件内容が承認済み／未承認の何れであるかを示す。対応可否区分は、要求元が案件対応可能／案件対応不可能の何れであるかを示す。対応条件種別は、案件内容について、詳細な打合せが必要なのか／その他条件有／特に無しの何れであるかを示す。要求元承認ステータス（要求元回答担当者、要求元回答承認者名）は、要求元による案件対応内容が承認済み／未承認の何れであるかを示す。
【００２１】
図３において、フィールド（提出先、提出日、提出先承認ステータス、依頼件名、完了希望日、案件内容、案件対応理由）は、案件票作成者がデータ作成する。フィールド（案件管理番号、対応可否区分、対応条件種別、完了予定日、完了日、影響範囲別の対応工数、問題課題、方針、要求元承認ステータス、完了報告日）は要求元にてデータ作成する。
【００２２】
障害管理（「障害票」）のフィールドの例を図４に示す。概略的に「障害票」は、基礎情報として発生日（障害が発生した発生日）、発生時間（障害が発生した時間）、担当者（障害発見者）、障害管理番号、件名、障害発生現象概要、業務区分（障害が発生した業務区分）、ＬＰＡＲ種別、店番／機番（障害が発生した店番／媒体の機番）、画面番号（障害が発生した端末画面の管理番号）、ＮＥＴ／ＪＯＢＩＤ（障害が発生したＮＥＴＩＤ／ＪＯＢＩＤ）、障害原因概要、対応策、原因判明日（障害の原因が判明した日）、完了予定日（障害対応完了予定日）、完了日（障害対応が完了した日）、修正要因区分（障害が発生した要因）、不良区分（不良を作り込んだ要因）、障害対策責任業務（障害対応する業務）、未発見原因（障害を発見出来なかった原因）、発生箇所（障害が発生したプログラム箇所）、作りこみ時期（障害を作りこんでしまった工程）、ドキュメント修正要否、修正ドキュメント名、類似見直し／自業務内見直要否、類似見直し／他業務展開要否、他業務展開先、見直し内容、修正プログラム（障害により修正したプログラム）、修正ステップ（修正したプログラムの変更／追加／削除ステップ）、承認ステータス（対応内容に対する承認）からなる。又、障害管理情報として重要度（障害が発生した事による影響度合）、対応工数（調査、設計／開発、テスト毎の対応工数）がある。
【００２３】
ここで、障害管理番号は障害毎に一意なように採番登録される。業務区分は障害が発生した業務区分を示す。ＬＰＡＲ種別は障害が発生したＣＰＵ（ホスト名）を示す。障害発生要因区分は障害を発生させてしまった要因区分を示す。例えば、製造不良や仕様／設計不良等。不良区分は不良を作りこんでしまった要因を示す。例えば、ロジック不良やインターフェース不良、エリア設計不良等。未発見原因は障害が発見出来なかった要因を示す。例えばテスト漏れ／テスト確認ミス等。発生箇所は障害が発生したプログラム部分を示す。例えば入力チェック部分やファイル更新部分、ファイル関連チェック部分等。作りこみ時期は障害を作りこんでしまった工程を示す。例えば、基本設計時／詳細設計時等。修正ドキュメント要否は各仕様書（ファイル仕様書／テーブル仕様書等）へ修正有無を示す。類似見直し／自業務内見直要否は発生した障害で類似した障害が他にないかの見直要否を示す。
【００２４】
図４において、フィールド（発生日、時間、障害管理番号、件名、障害発生現象概要、業務区分、ＬＰＡＲ種別、店番／機番、画面番号、ＮＥＴ／ＪＯＢＩＤ）は、運用管理者にてデータ作成する。フィールド（障害原因概要、本対策、修正要因、不良区分、障害対策責任業務、未発見原因、発生箇所、作り込み時期、原因判明日、完了予定日、完了日、自業務内見直要否、他業務展開要否、見直要否）は障害対応者にてデータ作成する。
【００２５】
システム修正変更管理のフィールドの例を図５に示す。概略的に「システム修正変更管理票」は、基礎情報として発行番号（システム修正変更の発行管理番号）、承認ステータス（担当者、承認者）、発行日（システム修正変更を発行した日）、依頼名称、発行者氏名、発行部署（システム修正変更依頼書を発行するチーム（業務））、対象システム名称（システム修正が発生するシステム名）、対象機器名称（サーバー名、機器名）、対象ソフトウェア・ファイル・テーブル名称、修正変更作業実施期間、修正変更実施作業場所、修正変更の実施予定日、確定日（修正変更実施確定日）、変更内容（作業種別、稼動種別、作業内容）、変更理由・目的、影響内容・範囲（リスク度、作業時間帯、作業時間、本番への影響内容と対策）からなる。
【００２６】
ここで、発行番号はシステム修正変更依頼毎に一意なように採番登録される。承認ステータスは、システム修正変更に対する承認／未承認の何れかを示す。対象ソフトウェア・ファイル・テーブル名称はシステム修正変更を行う、ソフトウェア名称、ファイル名称、テーブル名称を示す。作業内容の作業種別は今回実施する修正変更の定例作業／随時作業／特別作業を示す。
【００２７】
図５において、フィールド（発行番号、承認ステータス、発行日、依頼名称、発行者氏名、発行部署、対象システム名、対象機器名称、対象ソフトウェア・ファイル・テーブル名称、修正変更作業実施期間、修正変更実施作業場所、修正変更の実施予定日、確定日、変更内容、変更理由・目的、影響内容・範囲）は、システム修正変更者がデータ作成する。
【００２８】
ＳＩ管理は概略的に、ＳＩ管理番号、本貸出依頼（貸出先環境／貸出希望日／依頼者／作業完了日／作業者）、リカバリ貸出依頼（貸出先環境／貸出希望日／依頼者／作業完了日／作業者）、本登録依頼（登録元環境／登録希望日／依頼者／作業完了日／作業者）、リカバリ登録依頼（登録元環境／登録希望日／依頼者／作業完了日／作業者）、リカバリ削除依頼（削除希望日／依頼者／作業完了日／作業者）からなる。又、本貸出／リカバリ貸出、本登録／リカバリ登録、削除依頼を行うプログラム名、モジュール区分からなる。
【００２９】
ここで、ＳＩ管理番号はＳＩ依頼毎に一意なように採番登録される。貸出先環境／登録先環境はプログラム貸出／登録するライブラリ環境名称を示す。ライブラリ環境名称の例を図６に示す。貸出／登録希望日は依頼者のプログラム貸出希望日、プログラム登録希望日を示す。作業完了日はライブラリ管理者が、プログラム貸出／プログラム登録作業を完了した日を示す。
【００３０】
フィールド（ＳＩ管理番号、貸出先環境、貸出希望日、依頼者、登録元環境、削除依頼日）は、ＳＩ依頼者がデータ作成する。フィールド（作業完了日、作業者）は、ライブラリ管理者がデータ作成する。
【００３１】
案件管理データベース、障害管理データベース、システム修正変更管理データベース、ＳＩ管理データベースは、全てマイクロソフトアクセスで管理されている。各データベースはサーバーで管理されており、各担当者はクライアントＰＣから各ツールを使用しデータベースとアクセスし、データベース情報の参照／更新／検索／蓄積／追加／削除を可能とする。
【００３２】
案件管理／障害管理からシステム修正変更管理、ＳＩ管理迄のシステムイメージ図を図７に示す。
【００３３】
案件管理／障害管理からシステム修正変更管理に連携する仕掛けについて説明する。
【００３４】
案件票は要求もとから案件対応依頼がきたあと、案件管理ツールを使用して、案件管理番号の採番、対応内容を登録し案件票を作成する。案件管理番号は、年度別の発生順としている。
【００３５】
障害票は障害が発生した時点で障害管理ツールを使用して、障害管理番号の採番、障害内容を登録し障害票を作成する。障害管理番号は発生した年月日、障害検知場所が分かるような番号体系としている。障害対応の承認方法についてはあらかじめ承認者を選定しておき、承認者は自分のパスワードをデータベースに登録しておく。障害対応の暫定対策時／本対策の承認時に承認者の氏名を入力し承認ボタンをマウスでクリックすると、パスワードをきいてくるのでパスワードを入力すると承認状態となる。承認を解除する場合は承認されている状態で承認ボタンを押下すると、パスワードをきいてくるのでパスワードを入力すると承認解除状態となる。
【００３６】
システム修正変更管理ツールへの登録は、案件票もしくは障害票が作成されていればいつでも良い。逆にいえば案件票もしくは障害票が作成されていなければシステム修正変更管理ツールへの登録は出来ない仕掛けとしている。システム修正変更依頼を登録する画面例を図８に示す。
【００３７】
システム修正変更管理ツールの登録する手順は、案件対応によるシステム修正変更を実施する場合は、まず案件管理ツールに登録されている案件番号を入力し案件名を表示する。案件名を確認し、間違いなければシステム修正変更管理番号の採番、内容の登録を行う。障害対応によるシステム修正変更対応を実施する場合も同様の手順で、障害管理ツールに登録されている障害管理番号を入力し障害の件名を表示する。障害の件名を確認し間違いなければシステム修正変更管理番号の採番、内容の登録を行う。システム修正変更管理番号採番後は、システム修正変更管理ツールの画面に従って必要な項目を入力する。
【００３８】
システム修正変更管理番号については、リリースする年月がわかるような番号体系としている。システムを一元管理している事とリリース年月が分かるような番号体系とする事で、リリースされる案件名／障害名、プログラム名が即把握することが可能。又、リリースされる年月毎の案件数／障害件数、プログラム件数といった員数面でも即把握することが可能となる。他にもさまざまな還元帳票を作成する事が可能となる。例えば、案件毎の追加／削除／修正ステップ数の把握、障害毎の追加／削除／修正ステップ数の把握。案件の発生傾向の分析。障害については、発生傾向はもちろんのこと、障害要因／障害発生業務／障害発生箇所等のさまざまな分析が可能となる。
【００３９】
システム修正変更の承認方法についてはあらかじめ承認者を選定しておき、承認者は自分のパスワードをデータベースに登録しておく。システム修正変更の承認時に承認者の氏名を入力し承認ボタンをマウスでクリックすると、パスワードをきいてくるのでパスワードを入力すると承認状態となる。承認を解除する場合は承認されている状態で承認ボタンを押下すると、パスワードをきいてくるのでパスワードを入力すると承認解除状態となる。
【００４０】
ＳＩ管理ツールへの登録は、システム修正変更依頼書が作成されていればいつでも良い。逆にいえばシステム修正変更依頼が作成されていなければＳＩ管理ツールでの登録（プログラム貸出等）が出来ない仕掛けとしている。
【００４１】
データベースに蓄積してある情報をもとに、未回答案件／未対応案件／未対応障害の洗い出し、フォローアップ等の期限管理、統計情報及び分析報告書の作成にも活用できる。また、情報を共有する事で対応の迅速化や情報の再利用も可能となる。
【図面の簡単な説明】
【００４２】
【図１】案件が発生してから案件対応完了までの処理の流れを説明するフローチャート。
【図２】障害が発生してから障害対応完了までの処理の流れを説明するフローチャート。
【図３】「案件票」のフォーマット図。
【図４】「障害票」のフォーマット図。
【図５】「システム修正変更管理票」のフォーマット図。
【図６】ＳＩ管理をするライブラリ名称の例を示す図。
【図７】案件管理／障害管理からシステム修正変更管理、ＳＩ管理迄のシステムイメージを示す図。
【図８】システム修正変更管理依頼表を起票する画面例を示す図。
【符号の説明】
【００４３】
案件管理ＤＢ…案件管理、システム修正管理ＤＢ…システム修正変更管理、ＳＩ管理ＤＢ…ＳＩ管理。
【図１】
2006178798.tif 000003
【図２】
2006178798.tif 000004
【図３】
2006178798.tif 000005
【図４】
2006178798.tif 000006
【図５】
2006178798.tif 000007
【図６】
2006178798.tif 000008
【図７】
2006178798.tif 000009
【図８】
2006178798.tif 000010