システム・業務・会計に関するコンサルティング   人手やコストをかければ、管理や業務は誰でもできるが、それでは生産性は上がらない

  1. 経営のしくみ別冊

Vol.1 業務システムを成功に導く秘訣

「経営のしくみ別冊」は、弊所が発行している季刊誌です。
この記事は、Vol.1 2018.4「業務システムを成功に導く秘訣」です。

はじめに

コンピュータが企業の中に入ってきて40年近くたちました。今やスマートフォンやタブレットを使って、外出先からアクセスするのも当たり前です。

これほど月日がたったのにもかかわらず、システム構築の失敗は今もなくなりません。むしろビジネスが複雑化・多様化した分、増えている気がします。

なぜ、システムの失敗はなくならないのか?

よく理由として聞くのが「要件定義が悪いから」「現場の協力が得られない」などですが、それらは現象の一つにすぎません。本当の理由は別にあります。

このレポートで“本当の理由”を解き明かしていきます。そのメカニズムを知ることができれば、必ずやシステム構築の考え方や取り組み方が変わるでしょう。

本レポートは、経営者や経営幹部の皆さまにも読んでもらえるよう、あえて難しいシステム的な説明はしていません。ぜひ関係する皆さまで共有し、ムダなコストや労力をかけない、すばらしいシステムを構築してください。

目次

1.なぜ使えないシステムができてしまうのか?
2.システム構想こそ、システム成功のカギ!
3.これはやばい!資金が6億円も悪化するシステム
4.システム構想が上手くいく最大の秘訣

1.なぜ使えないシステムができてしまうのか?

本題にはいる前に、システムの失敗がいかに多いかを見てみましょう。下記はある会社の有価証券報告書(以下、有報)の注記です。上場会社は有報を年1回発表しています。

この会社は7億円の基幹システムを稼働することなく途中で廃棄したようです。
もう1社見てみましょう。

この会社は42億円の基幹システムとWEB販売システムを廃棄したようです。人ごとながら業績への影響が心配されます。

このようにシステムを稼働前に廃棄したと思われる事例は枚挙にいとまがありません。実際たった数分調べただけで、たくさんの事例を探すことができます。

システムがうまくいかないのは一般的に「開発の仕様をまとめる要件定義が悪いから」と言われています。たしかに日本情報システム・ユーザー協会のアンケート調査でも、遅延や予算超過の理由として「要件仕様の決定遅れ」「要件分析作業不十分」などがあげられています。

しかし、システムをすべて廃棄するようなケースとなると、ちょっと意味合いが違います。要件定義の問題というよりは、根本的なボタンの掛け違い、大きな間違いがあったと考えるのが普通です。

システム開発は次の流れで進みます。

通常のシステム開発は「要件定義」から「テスト」までです。要件定義がうまくいくとシステム開発がとどこおりなく進むので、要件定義がもっとも重要だと言われています。

しかし、要件定義は業務要求を受けてつくられます。業務要求が当初のまま変わらなければ何の問題もありませんが、もしシステム開発途中に変わってしまったらどうでしょう?システムは完成しますが、できあがったシステムは企業が求めるものでは無くなってしまいます。

ここに「使えないシステム」ができてしまう原因があるのです。

20年前、システムと言えばその部門だけで使う「部門システム」でした。営業部の部門システムを例としてあげると、利用者は営業部だけです。

同じ仕事をしている人ですから、あまり仕様でぶつかることもありません。対象となる業務は営業日報や案件管理など限られた範囲です。求める機能もシンプルでしょう。部門システムの業務要求はブレが少なく安定的です。

ですから部門システムの時代は、システム担当者やベンダーが関係者にていねいにヒアリングすれば、そのまま業務要求ができ、開発したシステムは問題なく動きました。ヒアリング主体の業務要求で良かったわけです。

しかしERP(全社統合システム)が登場したことにより状況は一変します。関係者は経営者を筆頭に営業部、製造部、購買部、総務部、経営企画部、経理部と多岐に渡ります。さらに対象となる業務は会社全体にまたがり、その内容は複雑です。業務要求のブレは大きく、不安定なものとなりました。

それにもかかわらず、システム担当者やベンダーの多くは、部門システム時代のなごりで、ヒアリング主体で業務要求を整理しています。経営者、営業部、製造部、購買部それぞれの所に行って一日ないしは半日かけてヒアリングし、各部門がシステムに求めることを集めて全社システムの業務要求としているのです。

しかし各部門の要求を単に寄せ集めても、それは全社システムの正しい業務要求にはなりません。なぜなら単なる寄せ集めでは部門間の要求や利害の隠された衝突が解消されていないからです。

部門間の要求や利害の隠れた衝突が解消されないまま業務要求を決めてしまうとどうなるか?

システム開発中ないしはシステム稼働後に“衝突”が顕在化します。それにともない、さかのぼって業務要求の大幅な変更を余儀なくされ、要件定義が二転三転するハメになります。システムの稼働は遅れ、予算は超過し、システムのバグが増えます。

そしてどうにも収拾がつかなくなると、そのシステムは廃棄されるのです。

1

2 3 4

経営のしくみ別冊の最近記事

  1. Vol.7 新・管理会計 財務会計からの脱却

  2. Vol.6 改革を成功させる生産性向上の急所

  3. Vol.5 消費税改正システム対応策

  4. Vol.4 売上が変わる!はじめての収益認識基準

  5. Vol.3 業務改革にRPAを活かす重要ポイント

PAGE TOP