PR
岩井 孝夫・佐藤 三智子

情報システムが計画通りに動くことなどあり得ない。本稼働直後はソフトの不具合や業務運用への配慮不足など,トラブルが多数発生する。ここをうまく乗り切るかどうかで,良いシステムに成長するかどうかが決まる。まず,利用者の不満やシステム変更依頼に辛抱強く耳を傾ける。そして利用者の声を,改善行動に移すもの,耳を傾けるだけのもの,利用者を説得して思いとどまらせるもの,などに切り分ける必要がある。


 とかく新システムの本稼働直後は情報システム部も利用者も混乱している。このためお互い,必要以上に神経質になるし,声の大きい人のクレームや要望にはすぐにこたえなければならない状況に追いこまれる。

 しかしシステム・ダウンやバグはともかく,仕様変更については早計に行動に移すと後で思わぬしっぺ返しがくる。会社全体の問題なのか個人固有の問題なのかが分からぬまま,闇雲に言われた通りに変更していては,システム全体の整合性がとれなくなる危険がある。

本稼働後のトラブル処理がカギ(1)
クレームの整理を怠る

 ファイナンス会社のA社にとって,業務の一大改革であった新受付システムが本稼働したのは4カ月前のことである。新システムは,これまで各営業店で受け付けていた案件を本部で集中処理するもの。その目標は,案件当たりの処理時間を極力短くすることであった。特に問題のない案件は数分で処理を終えられるように設計した。全国の営業店で1日に処理していた案件は相当な数に上っていたため,A社の経営陣は新システムによる効率化・省人化に大きな期待をかけ,相当な投資をしていた。

 もっとも,A社の情報システム部の担当課長は経営陣の過剰な期待に対し,ばくとした不安を持っていた。案の定,システム開発は常に遅れ気味だった。現場部門が出してくる非常に抽象的な要望をきちんとしたシステム仕様としてまとめることに多大な時間が費やされた。さらに,会議のたびに現場部門から出てくる新しい要望を実現可能かどうか判断することにも時間がかかった。

 しかし,本稼働の日程をずらすことはできず,実際のシステム開発の期間はかなり切りつめられた。テスト期間が非常に短くなり,さまざまなテストやシミュレーションを十分にできなかった。本稼働前に全国の業務担当者を何回かに分けて集め,新システムの操作と業務変更に関する研修を何度か行ったものの,担当者たちは膨大な情報を覚えきれぬまま,本稼働へ突入していった。

 本稼働後はさまざまなトラブルが発生した。システムがダウンする,正しく入力したにもかかわらずエラーが出る,レスポンスが遅い。予期していたトラブルもあったが,大抵は予期できぬものであった。

 それ以上に大変だったのが利用者から来る業務変更に関する問い合わせだった。情報システム部の電話は朝から晩まで鳴り続けた。情報システム部は本稼働に合わせてサポート要員を各現場に派遣していた。

 しかし現場で一つのことに対応している間に別な問題が起き,とてもすべての問題に対応しきれなかった。しかもサポート要員が足りなかったため,A社の社員だけでなく,ソフト開発を委託した企業のSEも動員し,現場へ派遣していた。彼らは業務内容にからむ問題には答えられず,結局本社の情報システム部へ問い合わせが殺到する結果となった。

 情報システム部はとりあえず急を要するトラブルの対処を優先する方針をとった。操作や業務内容,システム内容に関する問い合わせや要望については,即答できるものは答えたが,後は聞きおく程度にとどめた。寄せられた質問や要望を整理して記録しておく余裕などとてもなかった。

 しかし,本稼働から2カ月がたってようやく日々の作業が進むようになってくると,各営業店の店長から次々と,しかも今まで以上に強い,クレームが上がってきた。「本稼働から現在に至るまで毎日同じ問い合わせや質問,クレームを繰り返している。だが,情報システム部から一向に返事がない。そもそも,前に何度も問い合わせている内容についても,システム部は全く把握していない」。

 稼働開始後にシステムにはさまざまな変更が加えられ,現場の担当者には日々,「変更連絡」が山のように届く。現場担当者としてみれば,自分たちの意見や問い合わせには答えてくれないのに,情報システム部の都合による変更ばかりが押し付けられる,という意識にならざるを得ない。しかも,その変更内容はたまたま要求を早く出したり,声が大きかった営業店の意見が反映されたものだったため,よけい反発が強まっていた。

 A社の情報システム部では遅まきながら,利用者からの過去の問い合わせや要望,クレームについてすべて抽出し直し,対応の仕方を再検討しているところだ。