背景

業務負荷改善を目的として、外部パッケージシステムの導入を決定。既存システムからのリプレースを実施。

業務量の増加や、取り扱うデータの変更などで現行のシステムでは対応ができない業務が増えてきており、これによる人件費の増加が目下の課題となっていた。この課題の解消のために現行システムのリプレースが計画された。

社内で協議された結果、スクラッチ開発よりも比較的安価なパッケージ型のシステムを導入することとなった。導入後の業務変更による混乱を避けるため、業務の流れは極力変えず、各業務に特化した別々のパッケージを導入し、パッケージ間のデータ連携はアドオンを追加する方針で決定した。

計画は順調に進み、パッケージの導入も計画期間内に終えることができた。しかし、導入後すぐにシステム障害が頻発し、ユーザーからの問い合わせ対応や運用作業の増加によりパッケージ導入以前よりも業務負荷が増加してしまった。 これにより、障害の根本的解消、および計画の見直しを余儀なくされた。

課題

業務負荷軽減のためのパッケージシステム導入が、更なる負荷増大を招く。

パッケージを導入したところ、「業務で使えない」と利用者からの不満の声が続出。運用作業や手順が増え、システム担当者が対応にかかりきりになるなどの問題が発生し、負荷を軽減するためにパッケージ製品を導入が、むしろ業務負荷を増大させる要因に。

調査・分析の結果、発生した事象をもとに以下「5つの課題」が挙げられた。

【課題①】
1つのシステムに対し、複数パッケージを併用導入。

■ 発生した事象
パッケージ間のデータ連携処理で異常終了する。
上流にあるパッケージでは正常データとして扱われるが下流にあるパッケージでは異常データとして扱われた結果、ユーザー入力は正常終了したがパッケージ間のデータ連携で異常終了する。

【課題②】
パッケージの機能を活かしつつ業務の大幅な変更を抑制するためのアドオンを追加した。

■ 発生した事象
画面操作の仕方によって不要なトランザクションが発生する操作が生まれる。
ユーザが一連の業務の途中で画面操作を中断すると、中断前の操作のみトランザクションが発生し、データ不正となる。

【課題③】
パッケージの制約をユーザマニュアルに記載し、現行システムとの並行運用を実施した。

■ 発生した事象
ユーザーの役割外の操作をされ、不正なデータが発生した。
パッケージは様々なユーザの入力に対応可能な柔軟なチェックとなっているが、連携データは役割毎に厳格に作成されるため、矛盾が発生しエラーに繋がった。

【課題④】
上流システムのデータを特定するためのキー項目をIF項目に設定した。

■ 発生した事象
上流システムからのデータの参照ができず、システム担当者でも参照ができない。
上流システムのデータを特定するためのキー項目をIF項目に設定したところ、IF項目はパッケージの非公開DBにのみ保持されており、画面表示やDBからキー項目による検索が出来ないため、IFファイルからテキスト検索して調査する手法が必要になった。

【課題⑤】
障害発生時には、ベンダーを巻き込んで対処と原因調査を最優先で実施した。

■ 発生した事象
定時外に発生した障害で、ベンダー担当者と連絡がつかず、調査が止まった。
本番稼動後一月ほど経ち保守契約へ切り替える前頃に発生したパッケージ画面のシステムエラーについて、上流システムから連携されたデータの問題かパッケージやアドオンの問題か判断がつかず、ベンダー担当者と連絡がつくまで参照可能な情報から想像のみで調査を行った。

取り組み

導入するパッケージの機能を最大限活用できるように、現行の業務から再編成を行った。

課題の分析から、パッケージそのものではなく、パッケージの選定・導入に問題があると推測。それぞれの課題に対応した取り組みを実施することとなった。

 

【課題①】に対する取り組み
パッケージ併用を止め、単一パッケージで構成。(図1)

■ 前提
●パッケージにはそれぞれに特有の思想があり、同じ思想のパッケージはない。思想の違いにより、データチェックの基準や実現方法も異なるため、利用可能なデータの範囲も異なる。そのため、思想の違いによるデメリットを考慮し、単一パッケージでの導入を推奨。

●パッケージベンダーはパッケージの思想に反する対応は出来ない。思想の違いをアドオンで解決しようにも、パッケージの思想に反する変更内容の場合、ベンダーはパッケージの品質保証のため、対応を拒否される。ユーザマニュアルでの注意喚起や、システム対応を検討する。

●パッケージ間のアドオンや独自対応は難しい。パッケージの設計・実装内容は導入企業に非公開であるため、ベンダーによるアドオン、独自対応による実装とも、十分なレビュー・テストが実施出来ないため、適切な対応の追加は難しい。

(図1)

 

【課題②】に対する取り組み
トランザクションの発生単位を変更するようなアドオンであれば再考する。(図2)

■ 前提
●トランザクションの発生単位の変更による影響を調べきることは難しい。
通常、トランザクションは複数の発生経路があり、その全てにおいてトランザクションの発生単位を変更することは困難。

●「テストで確認すれば良い」は通用しない前提で変更する。
パッケージは保証されている前提で業務パターンのみのテストになりがち。
そのため例外パターンはテストしきれず、本番障害に繋がりやすい。

（図2）

 

【課題③】に対する取り組み
並行運用を徹底してユーザの操作誤りによるエラー発生を本番前に低減させる。(図3)

■ 前提
●パッケージの標準機能で企業が想定する権限設定を行えるとは限らない。パッケージはどの企業でも通用する標準的な権限設定になっており、自社特有の権限設定を満たせるとは限らない。

●ユーザはなんとかして自身で業務を進めるため、システムの想定外の入力をされる。マニュアルの理解不足・記載不足や例外事項の対応のため、ユーザはシステムで想定していない操作をされる。パッケージの標準機能では入力を制限出来ないことがある。

（図3）

【課題④】に対する取り組み
画面でIF項目を確認出来るか、下流から上流データを特定出来るか事前確認を行う。(図4)

■ 前提
●周辺システムと連携時の制約事項、特にキー項目の保持・表示可否。システム間連携は必ず発生するため、連携可否だけでなく、保守・運用を見据えた連携データの検索方法やその操作性を押さえておく。

●ログの出力粒度やIFファイルの保存方法、参照可能範囲と検索性。画面に表示される情報は保持しているデータの一部となるため、画面で確認出来ないデータをユーザ・システム担当者がどこまで参照可能かを押さえておく。

（図4）

【課題⑤】に対する取り組み
障害の原因調査・対処に向け、保守体制前の問合せ体制を構築する。(図5)

■ 前提
●障害の原因切り分けにはパッケージのロジックを見れるベンダーが必須。障害には、システムの実装による不具合以外に、マスタの設定不備やユーザのルール順守不足、システム運用誤りなどがあり得るが、パッケージ内部構造が非公開のため、調査からベンダーの協力が不可欠となる。

●パッケージベンダーは業務を押さえていない。
契約上当然のこととして、パッケージベンダーはパッケージを提供するために必要な業務知識のみで、業務の詳細は押さえていない。
パッケージ導入後の運用・保守を検討する際にパッケージに詳しいことと業務に詳しいことを混同しないよう注意が必要。

（図5）

まとめ

パッケージ導入時によく見られる課題を事前に把握し対策する事ではじめて、
スムーズなシステム移行と業務改善を可能とする。

以下に改めて、そのポイントを整理する。

●思想の違いによるデメリットを考慮して1システム1パッケージに。
●業務とシステムのデータ粒度が異なる場合は、一致させるよう再考する。
●ユーザ教育と並行稼働は事前に入念な計画を立て、ユーザへの周知と理解を徹底する。
●IN/OUTの関連を後で参照可能なIF設計を。
●保守体制、問合せ体制はベンダーと密に連携し準備する。