PR

連載「経営に役立つ情報システム」では,経営者がどのような視点でシステムを見ているかについて考えた。それは,最終的に承認をして支出を決める経営者の視点がわからなければ,情報化に踏み切れなくなったという時代の変化を受けてのことである。今回からは,挫折や失敗,計画の変更といった「うまくいかなかった事例」の検証を通じて,情報化の成功に押さえるべきポイントを探ってみる。

本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが,この記事で焦点を当てたITマネジメントの本質は今でも変わりません。

 食品加工の受注生産を行っているM社ではプロセス系の生産工程全般にわたるシステム再構築を計画した。全社からメンバーを選抜してプロジェクト・チームを結成し検討に入った。

 生産システムの再構築は長年の課題だが,それだけにとどまらない。社長自ら具体的な注文を出すなど,M社にとって今後の業務拡大を狙うための重要なテーマである。社長からは「原価管理を徹底するように」という厳命がくだった。得意先の意向や生産工程の複雑さ,季節ごとの生産量の違いなどを理由にして原価管理の徹底を先延ばしにしてきた現場も,今度ばかりは真剣に取り組む姿勢を見せている。

 新システムの検討は,現在の業務の問題点摘出から始めた。次に,現システムには盛り込まれていない現場の要望,経営陣の要請など約400項目の洗い出しを行った。その中から,表現は違うが同じことをいっているものや細かいレベルのものをまとめる作業を経て,12項目の重要検討課題にまとめ上げた。プロジェクト・チームが一丸となって取り組んだこともあって,ここまでにわずか1カ月しかかからなかった。

 新システムが目指す方向性の承認を受けるために,この段階で経営トップへの中間報告をすることになった。社長からは業務の細かい仕様に関する質問もあったが,それは今後の検討で詰める旨を確認して,現段階の方向性について経営陣の承認を得た。経営陣からは「今まで長年の懸案だった生産システムの方向性が,1カ月で固まったことは評価できる」という声も出た。

 承認された方向性に基づいて新しい業務フローの作成を行い,現場業務についてさらに詳しいやり方の検討を着々と進めた。検討の結果は,「生産システム再構築基本計画書」としてまとまり,経営会議の承認を経て本格的なシステム開発へいよいよ動き出した。開発にあたってはさまざまな可能性を検討した結果,最終的に将来の営業・研究部門への拡張性も含めてパッケージを導入することになった。ただし経理部分についてはパッケージの機能が弱いので,そこはベンダーにデータを別途作成してもらって作りこむことにした。

 実際の開発作業は,ベンダーのSEのF氏と生産工程/管理に詳しいM社の担当者がペアになって取り組んだことが功を奏して,パッケージの導入としては比較的スムーズに進んだ。カスタマイズも当初の予想に比べて大幅に少なくてすみそうだった。処理方法や伝票形式の変更といった予期せぬ問題が起こった場合も,SEのF氏が基本計画書を参照しながら迅速に解決していったので,開発はどんどんはかどった。開発スケジュールに多少の遅れはあったもののほかに問題も見あたらないため,プロジェクト・リーダーを務める本部長も安心していた。

運用開始後にトラブルが続出

 ところが実際の運用を開始してみると,大きなトラブルが次々に発生した。まずマスター登録をしようとした入力担当者がマスターを入力できないという深刻な不具合が続出した。下書き原稿を書いた担当者数人の間でフォーマットの統一を怠ったためにマスターの整合性がとれなかったり,原稿をつくる以前にマスターの内容を整理しなかったために重複や不要な登録があったことが原因である。

 実際のシステム運用に関する教育も不徹底だったので,システムそのものを動かせない事態が頻発した。そうなると,現場はその場しのぎで何とか動かそうとするため,結果的にさらに面倒な不具合を誘発した。例えば検品が終わっていないと入力ができないのに,勝手に新しいロットナンバーをつけて入力したり,出荷処理をする前に製品を倉庫から持ち出すなど業務は混乱を極めた。

 問題はこれだけで終わらなかった。基本計画書で決めた新しい業務フローが徹底されていないため,システムと実際の業務の動きが一致しないことも日常茶飯事だった。もともと弱いといわれていた経理に関しては,データの受け渡しがうまくできないため,経理部員がいちいち手で打ち直して整合性をとる始末だった。出力される伝票にも検印が押されておらず,システムが機能していないことは一目瞭然だった。

 新システムで新たに改善しようとした取り組みもうまく行かなかった。たとえば受注生産という業務の形態上,お得意様のいうなりに変更してきた部分をパッケージによってある程度まで標準化しようとした。しかし最初の意図とは裏腹に,例外処理ばかり増えてしまい,それを入力する手間だけでも相当な労力がかかっていた。

 これらの問題を片付けながら何とか新システムを使いこなしてきたが,1年たった時点で各現場の作業負荷を調べてみると驚くべきことがわかった。新しいシステムを導入してからの残業代が1億円近くも余分にかかっていることが判明したのだ。

 この数字を把握した社長はプロジェクト・リーダーの本部長を呼んで,「昨今の不況で売り上げ自体が落ちている。システム導入に1億円近くを投入したのに,残業代がそれと同じくらいかかっているとは何事か」と厳しく叱責した。当の本部長も途中までスムーズに進んだシステム開発がどこで間違ってしまったのか皆目検討がつかない。やむを得ず,もう一度検討することを約束して社長の部屋を出た。