頼りになるシステム部門 システム子会社になる「自己改革プログラム」

システム部門、システム子会社の存在意義が問われている

システム部門、システム子会社に対するユーザー部門の満足度は、決して高くありません。

• システム部門、システム子会社に対するユーザー満足度調査（不満足）
  1. 言われる前からの積極的な提案がない。
  2. もっと早く支援に来て欲しい。
  3. ＩＴではなく業務革新の相談にのって欲しい。
  4. 自社グループのではなく競争相手の事例を示して欲しい。

　　　・・・・・

これらの不満は、期待の裏返しでもあります。しかし、不満足なユーザー部門の中には、コンサル会社やＩＴベンダーと先に検討を行い、開発が始まってから、運用保守のために情報システム部門やシステム子会社を呼ぶこともあります。そのような中で、システム部門やシステム子会社の中には、ユーザーとＩＴベンダーの間を行き来する「手配師」のような仕事をしている企業もあります。さらに、今後のクラウド化の中で、運用が外部に委託される可能性も出てきました。
システム部門、システム子会社の存在意義が問われています。

強みを活かして頼られる組織になる

では、システム部門、システム子会社が不要かといえば、そうではありません。ベンダーは、厳しく対応しなければ、不必要なシステムや機能を提案してくるかもしれません。１社に長期的なアウトソーシングを行うと、自社の交渉力が低下し、結局高い買い物になるかもしれません。部分的には最適でも、自社グループの全体最適の提案になっていないかもしれません。本当にユーザーが求めるタイミングで、必要な提案が成されず、ユーザーのシステム化が競争相手から遅れてしまうかもしれません。
結局、ＩＴベンダーやコンサル会社よりも、早く、妥当な提案を行い、ユーザーと共に企画を充実させ、強力なコンセプトを創造・共有し、ＩＴベンダーやコンサル会社を使いながらコンセプトを実現させる、「頼りになるシステム部門、システム子会社」が求められているのです。考えてみれば、システム部門、システム子会社は、ＩＴベンダーやコンサル会社よりも、上記をうまくできる、恵まれた環境にいます。ユーザーのビジネスやＩＴ化の計画は、幾らでも手に入ります。提案を持っていけば、必ず聞いてくれます。悩みを聞けば、答えてくれます。この強みを活かして、「頼りになる」部門に変わることが必要です。

自己改革プログラム

ただし、これまでの歴史の中で、問題は構造化しています。簡単な施策で、解決はできません。アクト・コンサルティングでは、以下の自己改革プログラムを確立し、頼りになるシステム部門、システム子会社になるための支援を実施しています。

• ＡＭ：アカウント・マネジメント

  ユーザーごとに中期提案テーマを明確化し、早め早めに提案して、ユーザーと共にテーマを育て上げる。

• ＣＰ：コンサルティング・プロモーション

  経営に資する業務革新とＩＴ化を企画提案し、関係者の合意形成、経営者の意思決定を支援する。

• ＢＭ：ベンチマーク

  競争相手、先進異業種と自社ユーザー部門の業務革新＋ＩＴ化の比較評価によって、重要な革新領域を明確化する。

• ＴＭ：テーマ・マネジメント

  グループ企業の実績の中期横展開計画、先進ＩＴの自社グループ内での適用の検討・中期推進計画を立て、計画的な提案・推進を行う。

• ＭＲＤＲ：マスタープラン・リクワイアメント・デザイン＆レビュー

  コンサルタントを使った基本構想確立プロジェクトで、コンサルタントをコントロールし、コンセプトを維持して、妥当な構想を立てさせる。

• ＰＲＤＲ：プロジェクト・リクワイアメント・デザイン＆レビュー

  企画提案、基本構想段階でユーザーと握ったコンセプトを、システム開発で維持し、むやみに要件が爆発することを防ぎ、計画通りにシステムを完成させる。

• ＩＴＭＤ：ＩＴマネジメント・デベロップメント

  業務革新＋ＩＴ化の企画を、他の設備投資と同様の視点でレビューし、投資後に、企画どおりの業務革新が達成されているかフォローする仕組みを作る。