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

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

まずは、ポイントの1つ目「目的」についてご説明します。
多くのプロジェクトでシステムが古くなったからや、保守切れが近いからという理由で刷新するという話をお聞きします。確かに老朽化も保守切れの危険性も事実ではありますが、様々な立場の方がプロジェクトの重要性や大きな投資の必要性を認識するのに果たして十分でしょうか。

すなわち、たとえ老朽化対応や保守切れ対応が契機の一つとなってスタートするプロジェクトだとしても、企画・構想段階において大きなキャッシュフロー改善や、売上増・利益増を実現する目的を立てる必要があるということです。そのためには、現状業務の進め方ありきで、少しずつムダ取りや効率化をかき集めるような考え方だと不足します。時に大胆な目標を設定し、目標実現に向けて業務の進め方そのものを改革することが必要です。

保守切れが近いことを理由に立ち上げたプロジェクトで、現状業務を変えることなくその効率化を目標に掲げ、ギリギリ投資額を回収できる見込みというところで導入・構築段階に進むとどうなるでしょうか。「システム要件定義を進めるうちに、今の業務に合わせるためのカスタマイズが多いことが分かり、開発費が想定より膨らみ…」や、「為替の影響を受けて来年以後のアカウント利用料は2割値上げされることが分かり…」などが想定されます。

現実にはもちろん悪いことばかりではないのですが、ギリギリクリアで描かれた投資回収シナリオの成否は非常に不安定なものとなります。そのような中で、同じように苦しむ企業が数々いる現状を理解しているシステムパッケージベンダーから保守期間延長のニュースが入ると、いよいよ「何のためにこのプロジェクトをやってきた…？」という疑問が関わるメンバー全員の中に生まれ、いよいよプロジェクトを進めることも止めることも難しい判断が迫られることとなります。

次に、ポイントの2つ目「スコープ」についてご説明します。
企画・構想段階において重要なことは、必ず全社的な視点からシステム導入の対象とする業務を明確にすること、そして対象としない業務を明確にすることです。すなわち、システムを稼働する段階で行われている業務の全体像や、そこで使用されるシステムとデータの全体像を理解したうえで、これは業務に新システムを使用する・使用しないと決めていくこととなります。

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

一部の業務の流れやデータの流れを整理することをせずに、スコープとするかどうかの判断を導入・構築段階に数多く先送りするとどうなるでしょうか。非常に困ったことに、企画・構想段階でうっかり自分に都合のよい絵を描いていたことが後々判明することが多く見受けられます。「その業務が残るのであれば、廃止できると想定していたシステムを残さざるを得なくなり…」と誰かが話す一方で、「その業務をスコープとすると、当初想定していなかったカスタマイズやシステムインターフェースが発生して…」と誰かが話すとします。いずれも企画・構想段階で思い描いた導入効果が目減りすることとなります。

しかも本来主役であるはずの、実際にシステムを利用する業務の担当者が参加していない状況が長く続くと、新システムを使用することに反対するリスクも、使用しないことに反対するリスクも、双方保持したまま時間軸が進んでいくこととなります。そのようなどちらが正解とはいえない状況に追い込まれた中で、QCDを踏まえた決定を下すということは、全体で意見が一致するのは非常に難しく、厳しい判断を迫られることとなります。

最後に、ポイントの3つ目「体制」についてご説明します。
目的やスコープが明確に定まったとしても、関係者間で意見がいつも一致してシステムの企画・構想から導入・構築、そして稼働・運用を進められることはありえません。課題に直面した時に解決できる体制や関係者間の利害を調整したうえで、プロジェクトを前に進められる体制が不可欠です。望ましい体制としては、経営層やトップがオーナーとなって主導する下に、関係する全部門を知るメンバーが参加してプロジェクトにコミットすることが重要となります。

すなわち、メンバーは可能であればプロジェクト専任として、（兼任だとしても元々担当した業務の一部は離れ、プロジェクトの作業に対して工数を保証されたうえで）それぞれの持っている業務知識をフルに還元できる状況の下、メンバー間で意見交換したうえで、将来の新システムを使用した業務の絵を描くことが求められます。

また、体制には社内だけでなく社外を巻き込む観点もポイントとなります。システムのソリューションベンダーと、構築ベンダー（ソリューションベンダーと同一の場合もある）とが共同で進める体制が必要となりますが、システムベンダーは会社や人によって特徴や性質がそれぞれ異なります。そのため、各社や各者の得意なことを踏まえたうえで、自社を含めた責任範囲の振り分けをハード・ソフト両面（契約面・実務面）でフェーズごとに決めながら、チームメイクする必要があります。

企画・構想段階ではまず一緒にプロジェクトを進める会社を決めるところからということになりますが、自社メンバーと組み合わせたチームを組成した時に、役割分担のイメージができるかどうか、期待している役割を全うしてくれるかどうかが大きな確認点となります。

では、望ましい体制を構築できないとどうなるでしょうか。
部門を跨いで使用するシステムのプロジェクトを一部の部門だけで体制を組んで進めてしまうと、プロジェクトへの関与が大きかった部門の意に沿ったシステムができ上がるでしょう。また、部門間の意見調整ができない体制になってしまうと、皆さまの会社でも文化的に声が大きい部門は存在するかと思いますので、その部門の意見が色濃く反映されたシステムが完成するでしょう。

いずれにしても比較的導入が進んだところで掘り下げられていなかった業務が存在すると、より効果の上がる業務の進め方が実はあったということが見えてきたとしても、今さら反映できないということになってしまいますし、そもそも新システムの導入を反対されるかもしれません。社外とのパートナーシップについても、会社や人によって異なる特徴や性質があるということを理解しないと、1つのシステムベンダーで「このやり方でうまくいったから」と別のシステムベンダーでも同様のやり方を当てはめても、期待したアウトプットが作成されず頭を悩ませることとなります。

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