関連部門の積極的な協力
IT導入対象の主体となる業務部門だけではなく、そこに関連する部門のことも充分考慮しなければ、IT導入は成功しないとした。
しかし、IT導入を議論する時に情報システム部門はもちろん、導入対象の業務部門については多く議論されているが、関連する部門についての議論はついぞ見かけたことがない。
例えば、生産管理システムを導入するとき、製造部や生産管理部がどのように関わるべきかについて議論されるが、そこに関連する部門、例えば設計、資材、品質管理、倉庫、運輸、営業などの部門がどのように関わるべきかが主要テーマとして語られることはまずない。なぜなら、関連部門はあくまでも補助部門という認識が強くあり、主部門のシステム構築に一緒に付いて来るのは当然だと思われているからだろう。しかし、関連部門の積極的な協力がなければシステムは効果を発揮しないし、ましてや反旗をひるがえされては、システム構築は崩壊の危機の可能性さえある。
関連部門についても、IT導入対象のメーン部門の付随テーマとしてではなく、独立テーマとしてIT導入への関わり方を議論しておく必要がある。
関連部門が非協力的だったために、システムが効果を発揮できなかった例を2つ挙げる。
対岸の火事として眺めている関連部門
中堅機械部品メーカーA社は、SCMの考え方を取り入れたシステムを構築した。システム導入の主体は、生産管理部門とされた。そして、関連部門の中でも営業部門と資材部門は重要視され、メンバーをプロジェクトチームに派遣したり、緊密な打ち合わせが行われたりしたが、しかし運輸・倉庫部門についてはプロジェクトチームにも加えられなかったし、プロジェクトの情報も打ち合わせ議事録が送られてくるだけだった。プロジェクトの側から運輸・倉庫業務を軽視していることに加え、運輸・倉庫部門自身もシステム構築は対岸の火事という感覚だった。当然問題は起きた。システムが稼働を始めたが、そもそも運輸・倉庫部門の意識が低いため、肝心のデータ入力がいい加減で、さらにプロジェクトチームや生産管理部門から運輸・倉庫部門に出されるいろいろな指示が徹底しないし、場合によっては指示された事項が無視された。結果的に、システムが軌道に乗らないだけでなく、運輸・倉庫部門自体も業務の流れに混乱をきたした。
この例の場合、システム導入主体が運輸・倉庫部門を軽視したことが問題だが、運輸・倉庫部門にしてもシステム導入の動きを察知したり、噂を聞いたりしたら、対岸の火事として見守るのではなく、自ら動き出さなければならない。ヒトゴトでいるから、結局自部門の業務が混乱するし、自部門は進化しないし、いずれかの機会に自部門に対する協力を得ることも難しくなる。自部門のためにも、自ら積極的に参加していくべきである。
もう一つは、B電気機器販社がSFAを導入した例である。B社は社内の関連部門や、親会社であるメーカーC社の営業部門と緊密な連絡をとってシステム構築を進めたが、C社の設計部門や配送・出荷部門との意思疎通を欠いた。営業部門に設計や配送・出荷部門との意思疎通を期待したつもりだったが、不充分だった。その結果、B社から見て設計情報の内容に欠陥があり、C社との配送・出荷情報交換に齟齬が発生した。
B社・C社は会社が違うので難しい面があるが、逆にそれであるだけに、B社はC社営業部門にC社の取りまとめを期待することを明確に伝え、そのフォローアップを充分に行うべきだし、場合によっては設計や配送・出荷部門にも声をかけてプロジェクトチームに取り込むべきである。
設計や配送・出荷部門自身も、B社でSFAを構築するという噂を聞いたら、自ら参加を申し出なければならない。対岸の火事でいると、結局火の粉が自分に降りかかってくる。
Copyright © ITmedia, Inc. All Rights Reserved.