システム導入の成否を決める企画・構想段階における3つのポイント

システム企画・構想段階のポイントは、ずばり①目的②スコープ③体制の3点です。
すなわち①何のために導入するか（why）、②どの業務に導入するか（where）、③誰が導入を進めていくか（who）、と言い換えることもできます。
言ってしまえば極めて単純なことにも聞こえますが、私自身もシステム導入プロジェクトに日々携わる中で、この3つのポイントを完全体に近づける作業が簡単でないことを肌で感じ、その大切さを肝に銘じ胸に刻み心に沁みているものでございます。
企画・構想段階を終えると当然に導入・構築段階へと入っていくことになりますが、後工程になってから「あの時もう少し突き詰めていればよかった」「決めきっていればよかった」と思ったとしても、取り返すには非常に大きなエネルギーが必要となります。

まずはポイントの1つ目、目的についてです。
多くのプロジェクトで、システムが古くなったから・保守切れが近いから刷新するという話をお聞きします。
確かに老朽化も保守切れの危険性も事実ではありますが、様々な立場の方がプロジェクトの重要性や大きな投資の必要性を認識するのに果たして十分でしょうか。
すなわち、たとえ老朽化対応・保守切れ対応が契機の一つとなってスタートするプロジェクトだとしても、企画・構想段階において大きなキャッシュフロー改善や売上増・利益増を実現する目的を立てる必要がある、ということです。
そのためには、現状業務の進め方ありきで、少しずつムダ取り・効率化をかき集めるような考え方だと不足します。時に大胆な目標を設定し、目標実現に向けて業務の進め方そのものを改革することが必要です。

保守切れが近いことを理由に立ちあげたプロジェクトで、現状業務を変えることなくその効率化を目標に掲げ、ギリギリ投資額を回収できる見込みというところで導入・構築段階に進むとどうなるでしょうか。
「システム要件定義を進めるうちに今の業務に合わせるためのカスタマイズが多いことが分かり開発費が想定より膨らみ…」「為替の影響を受けて来年以後のアカウント利用料は2割値上げされることが分かり…」
現実にはもちろん悪いことばかりではないのですが、ギリギリクリアで描かれた投資回収シナリオの成否は非常に不安定なものとなります。
そんな中、同じように苦しむ企業が数々いる現状を理解しているシステムパッケージベンダーから保守期間延長のニュースが入ると、いよいよ「何のためにこのプロジェクトをやってきた…？」という疑問が関わるメンバー全員の中に生まれ、いよいよプロジェクトを進めることも止めることも難しい判断が迫られることとなります。

ポイントの2つ目、スコープについてです。
企画・構想段階において重要なことは、必ず全社的な視点から、システム導入の対象とする業務を明確にすること、そして対象としない業務を明確にすることです。
すなわち、システムを稼働する段階で行われている業務の全体像・そこで使用されるシステムとデータの全体像を理解したうえで、これは業務に新システムを使用する、そしてこれは使用しない、と決めていくこととなります。
企画・構想段階で○○はスコープ外とする、と判断できることに大きな価値があります。
「売上や利益という軸で測ったときにココが大部分を占めるから」「新システムを導入したときに効果が出るのはココだから」といった理由で、企画・構想段階において全社的な業務の流れ・データの流れを理解することを放置して、新システムを使用するかどうか曖昧な業務を残して先に進むことはできません。
たとえ最終的にスコープ外とする、もしくは段階的に稼働する計画の中で第二段階以後のスコープとする決定がなされるとしても、全体像の整理は終えたうえでスコープ外やネクストステップとする判断が必要となります。

一部の業務の流れやデータの流れを整理することをせずに、スコープとするかどうかの判断を導入・構築段階に数多く先送りしているとどうなるでしょうか。
非常に困ったことに、企画・構想段階ではうっかり戦略的に自らに都合の良い絵を描いていたことが後々判明することが多いです。
誰かが「その業務が残るのであれば、廃止できると想定していたシステムを残さざるを得なくなり…」と話す一方で、誰かが「その業務をスコープとすると、当初想定していなかったカスタマイズやシステムインターフェースが発生して…」と話します。
いずれにしても企画・構想段階で思い描いた導入効果が目減りすることとなります。
しかも本来主役であるはずの、実際にシステムを利用する業務の担当者が参加していない状況が長く続くと、新システムを使用することに反対するリスクも、使用しないことに反対するリスクも、双方保持したまま時間軸が進んでいくこととなります。
そんなどちらが正解とは言えない状況に追い込まれた中で、QCDを踏まえた決定を下すということは、全体で意見が一致するのは非常に難しく、厳しい判断を迫られることとなります。

ポイントの3つ目、体制についてです。目的やスコープが明確に定まったとしても、関係者間で意見がいつも一致してシステムの企画・構想から導入・構築、そして稼働・運用を進められることはありえません。
課題に直面したときに解決できる体制・関係者間の利害を調整したうえでプロジェクトを前に進められる体制が不可欠です。
望ましい体制としては、経営層・トップがオーナーとなって主導する下に、関係する全部門を知るメンバーが参加してプロジェクトにコミットすることが重要となります。
すなわち、メンバーは可能であればプロジェクト専任として（兼任だとしても、元々担当した業務の一部は離れ、プロジェクトの作業に対して工数を保証されたうえで）、それぞれの持っている業務知識をフルに還元できる状況の下、メンバー間で意見交換したうえで、将来の新システムを使用した業務の絵を描くことが求められます。
また、体制には社内だけでなく社外を巻き込む観点もポイントとなります。
システムのソリューションベンダーと構築ベンダー（ソリューションベンダーと同一の場合もある）と共同で進める体制が必要となりますが、システムベンダーは会社・人によって特徴・性質がそれぞれ異なります。
そのため、各社・各者の得意なことを踏まえたうえで自社を含めた責任範囲の振り分けをハード・ソフト両面（契約面・実務面）でフェーズごとに決めながらチームメイクする必要があります。
企画・構想段階ではまず一緒にプロジェクトを進める会社を決めるところからということになりますが、自社メンバーと組み合わせたチームを組成したときに自社との役割分担のイメージができるかどうか・期待している役割を全うしてくれるかどうかが大きな確認点となります。

望ましい体制を構築できないとどうなるでしょうか。
部門を跨いで使用するシステムのプロジェクトを一部の部門だけで体制を組んで進めてしまうと、プロジェクトへの関与が大きかった部門の意に沿ったシステムができ上がるでしょう。
また、部門間の意見調整ができない体制になってしまうと、皆さまの会社でも文化的に声が大きい部門は存在するかと思いますので、その部門の意見が色濃く反映されたシステムが完成するでしょう。
いずれにしても比較的導入が進んだところで掘り下げられていなかった業務が存在すると、もっと効果の上がる業務の進め方が実はあったということが見えてきても、今さら反映できないということになってしまいますし、そもそも新システムの導入に反対されるかもしれません。
社外とのパートナーシップについても、会社・人によって異なる特徴・性質があるということを理解しないと、1つのシステムベンダーで「このやり方でうまくいったから」と別のシステムベンダーでも同様のやり方を当てはめても、期待したアウトプットが作成されず頭を悩ませることとなります。

部門間の調整・会社間の調整が必要となる課題対応においては、我々のような外部を巻き込んで成功に向かうことも一つの手段となりますので、その他の点も含めてシステムの企画・構想や導入・構築において、もし何かお困りごとがございましたらぜひお気軽にお問い合わせください。