企業変革は準備で成否の8割が決まる──企画・構想・選定の全体像と要点

企業変革のために基幹システムの刷新に踏み切る──。そのプロジェクトの成否は、「企画・構想・選定」という準備の成否で8割が決定づけられると、マネジメント・プロセス・コンサルティング代表取締役社長の巻幡雄毅氏は言い切ります。果たしてそれは、どういうことなのでしょうか。巻幡氏のWebセミナーの内容を要約して紹介します。
情報提供/監修:
▼次世代リーダー必見!巻幡氏のWebセミナーをオンデマンド配信中!
【セミナータイトル】企業変革、準備が成否の8割を決める~「企画・構想・選定」の全体像~
では、何に留意しながら実行プロジェクトに臨むべきなのでしょうか──。
重要なポイントは2点に集約できます。それは、実行プロジェクトを開始するまでに「組織として合意形成をすること」と「着実に準備を進めること」です。具体的には、「企画・構想・選定」のフェーズが、実行プロジェクトを成功させるための準備活動となります。
この準備活動に着手したばかりの時点では、敷かれたレールはなにもありません。そのため、議論が堂々巡りになりがちです。
そのため、プロジェクト推進の担当者は、往々にして、「何度役員会で打診しても、その都度さまざまな指摘事項がでてきて予算承認に至らない」「役員の合意形成は役員会でやってほしい」「社長は『やれ』と言うが、事業部門側は『うちは特殊』という話ばかりで協力を得られない」「何から手を付けたらよいのか段取りが見えない」「そもそも全社プロジェクトなんてやったことがない」といった悩みを抱え込みます。
かたや経営者は、「ベンダーの提案書の中身が理解できない」「いつまでに何を実現し、費用がいくらかかるのかが示されないとGOサインはだせない」「担当者に検討を指示しているが、いつまでたっても要領を得ない」「変革に向けた取り組みの話をしているのに、なぜシステム部門がパッケージベンダーを呼んでいるのか」「社内での議論を早く終わらせ、今すぐ着手して結果を出したい」といった不満を募らせていきます。
このように、いつまでたっても議論が噛み合わない状態が続けば、当然、実行プロジェクトは立ち上げられません。結果、すぐにでも実行すべき企業変革の取り組みが後ろ倒しになり、競争優位を確保することが日増しに難しくなっていきます。ゆえに、堂々巡りという非生産的なループから、いち早く脱却する必要があります。

図1:プロジェクトの実行を阻む堂々巡りのループ
したがって、「企画・構想・選定」のフェーズにおいては、「目的達成への道筋を明らかにする」ことが重要です。
そこで実行プロジェクトを、「実行計画の遂行」と「目的の達成」の2軸から評価することにします(図2)。

図2:プロジェクト実行の成否を2軸で評価する
言うまでもなく、実行計画どおりにプロジェクトが完了し、なおかつ変革を達成できたならば、そのプロジェクトは「成功」です。
また、多少スケジュールやコストがオーバーしたとしても変革が達成できたらならば、「長期視点では合格」と見ることができます。
その逆に、実行計画どおりにプロジェクトが完了したとしても、変革が達成されずに現状から変化がなければ、「投資に対するリターンはなし」となることから、プロジェクトは失敗と判断せざるを得ません。
変革の達成という本来の目的を置き去りにし、いつの間にか予算どおり、スケジュールどおりにシステムを導入することが目的化してしまう実行プロジェクトが少なくないだけに、この辺りには注意が必要です。
企画段階では「何のためにそのプロジェクトをやるのか?」、構想段階では「何を、いつまでにやるのか?」「費用感はどれくらいか?」、選定段階では「何を使う?」「どのベンダーと組む?」「支払いをどうする?」といったことを議論し、最後に実行プロジェクトの準備段階で「だれが、いつ、何を決めるのか?」「どんな作業をするのか?」といった内容について関係者の意見をすり合わせます。
現実には、1日も早くプロジェクトをスタートさせたいと、しっかりとした実行計画を策定しないまま、見切り発車するケースが少なくありません。ただし、このようにしてスタートさせたプロジェクトは途中で頓挫し、決して成功に至らないことを肝に銘じておくべきでしょう。
ではなぜ、このような失敗が起こるのでしょうか──。その原因として目立つのは、準備の段階でいきなり「業務処理の検討」から始めているケースです。
例えば、基幹システムの変革を既存業務の延長線上にあるもと見なし、「決算処理ができればよい」「日常業務が回ればよい」「これまでどおりの管理帳票が出せればよい」「現状のサービスレベルを満たせればよい」といった観点で要求仕様を策定し、ベンダーに発注してしまうわけです。このようにして構築されたシステムは、結果的にマネジメントの要件が反映されていない伝票処理を行うだけのシステムになってしまいます。
では、変革の目的を分解・具体化するには、何をどうするべきなのでしょうか──。
その第1ステップでは、変革の狙いや効果を明確にした組織横断の「取り組みテーマ」を、論理的なプロセスのかたまりである「施策」に分解します。続く第2ステップとしては、分解した「施策」を前後関係や準備期間を考慮しながら、例えば、3年間の実行計画といった「ロードマップ」にまとめていきます。
そして第3ステップとして、直近で取り組む施策を、業務や部門の役割変更点、業務の規定基準、システム要求事項、想定効果および測定方法といった要素別に分解していきます。
この結果として、さまざまな施策の相互関係と整合性が担保され、具体的で実現可能な取り組みを推進していくことが可能となります(図3)。

図3:変革の目的を分解、具体化する
ここで言うマネジメントプロセスとは、ビジネスの状況チェック、問題点の共有、対策の実施というサイクルを回していくことを意味します。まず、業務処理結果が反映された情報環境を用いて、「業務は上手く実行されているか」「計画との乖離状況はどうか」といったチェックを行います。次に、そこで明らかになった問題が仮に複数の部門を横断するものであれば、関係者を集めて問題を共有し、全員で解決策を検討します。そして対策責任者を決めて問題解決の対策を推進するというわけです。
マネジメントに求められるのは、組織の目標達成にほかなりません。この大前提に立ち、マネジメントプロセスをどう確立するか、マネジメントプロセスと業務処理プロセスの両方の要件を満たす情報環境をどう築くかを、「企画・構想・選定」の中で議論していく必要があります。また、それによってはじめて、目標を達成するためのプラットフォームを構築し、組織としての的確な舵取りを行っていくことが可能になるのです。

図4:マネジメント要件の検討
情報提供/監修:
マネジメント・プロセス・コンサルティング株式会社
代表取締役社長 巻幡 雄毅氏
▼次世代リーダー必見!巻幡氏のWebセミナーをオンデマンド配信中!
【セミナータイトル】企業変革、準備が成否の8割を決める~「企画・構想・選定」の全体像~
議論が堂々巡りになるのはなぜか?
経営の体質強化や収益性向上を喫緊のテーマに掲げ、基幹システムの刷新やデジタル化に取り組む企業が増えています。ところが、実行プロジェクトを立ち上げるまでの準備の段階で、多くの企業が困難に直面しているのが現実なようです。では、何に留意しながら実行プロジェクトに臨むべきなのでしょうか──。
重要なポイントは2点に集約できます。それは、実行プロジェクトを開始するまでに「組織として合意形成をすること」と「着実に準備を進めること」です。具体的には、「企画・構想・選定」のフェーズが、実行プロジェクトを成功させるための準備活動となります。
この準備活動に着手したばかりの時点では、敷かれたレールはなにもありません。そのため、議論が堂々巡りになりがちです。
そのため、プロジェクト推進の担当者は、往々にして、「何度役員会で打診しても、その都度さまざまな指摘事項がでてきて予算承認に至らない」「役員の合意形成は役員会でやってほしい」「社長は『やれ』と言うが、事業部門側は『うちは特殊』という話ばかりで協力を得られない」「何から手を付けたらよいのか段取りが見えない」「そもそも全社プロジェクトなんてやったことがない」といった悩みを抱え込みます。
かたや経営者は、「ベンダーの提案書の中身が理解できない」「いつまでに何を実現し、費用がいくらかかるのかが示されないとGOサインはだせない」「担当者に検討を指示しているが、いつまでたっても要領を得ない」「変革に向けた取り組みの話をしているのに、なぜシステム部門がパッケージベンダーを呼んでいるのか」「社内での議論を早く終わらせ、今すぐ着手して結果を出したい」といった不満を募らせていきます。
このように、いつまでたっても議論が噛み合わない状態が続けば、当然、実行プロジェクトは立ち上げられません。結果、すぐにでも実行すべき企業変革の取り組みが後ろ倒しになり、競争優位を確保することが日増しに難しくなっていきます。ゆえに、堂々巡りという非生産的なループから、いち早く脱却する必要があります。

図1:プロジェクトの実行を阻む堂々巡りのループ
実行プロジェクトの成功と失敗をどう判断するか
「企画・構想・選定」の最大の目的は、「リアリティのある実行計画を策定する」ことにあります。また、目的達成は、実行プロジェクトの開始前にその目的そのものをどれだけ明確に分解・具体化できたかに依存します。したがって、「企画・構想・選定」のフェーズにおいては、「目的達成への道筋を明らかにする」ことが重要です。
そこで実行プロジェクトを、「実行計画の遂行」と「目的の達成」の2軸から評価することにします(図2)。

図2:プロジェクト実行の成否を2軸で評価する
言うまでもなく、実行計画どおりにプロジェクトが完了し、なおかつ変革を達成できたならば、そのプロジェクトは「成功」です。
また、多少スケジュールやコストがオーバーしたとしても変革が達成できたらならば、「長期視点では合格」と見ることができます。
その逆に、実行計画どおりにプロジェクトが完了したとしても、変革が達成されずに現状から変化がなければ、「投資に対するリターンはなし」となることから、プロジェクトは失敗と判断せざるを得ません。
変革の達成という本来の目的を置き去りにし、いつの間にか予算どおり、スケジュールどおりにシステムを導入することが目的化してしまう実行プロジェクトが少なくないだけに、この辺りには注意が必要です。
根拠を明確にしながら段階的に合意形成を行う
先に触れた「リアリティのある実行計画」を策定する過程で、根拠を明確にしながら段階的に合意形成を行うことも大切です。企画段階では「何のためにそのプロジェクトをやるのか?」、構想段階では「何を、いつまでにやるのか?」「費用感はどれくらいか?」、選定段階では「何を使う?」「どのベンダーと組む?」「支払いをどうする?」といったことを議論し、最後に実行プロジェクトの準備段階で「だれが、いつ、何を決めるのか?」「どんな作業をするのか?」といった内容について関係者の意見をすり合わせます。
現実には、1日も早くプロジェクトをスタートさせたいと、しっかりとした実行計画を策定しないまま、見切り発車するケースが少なくありません。ただし、このようにしてスタートさせたプロジェクトは途中で頓挫し、決して成功に至らないことを肝に銘じておくべきでしょう。
目的を達成できない本質的な原因は何か?
上述したとおり、実行計画どおりにプロジェクトが完了したとしても、変革が達成されなければ投資に対するリターンはなく、プロジェクトは失敗となります。ではなぜ、このような失敗が起こるのでしょうか──。その原因として目立つのは、準備の段階でいきなり「業務処理の検討」から始めているケースです。
例えば、基幹システムの変革を既存業務の延長線上にあるもと見なし、「決算処理ができればよい」「日常業務が回ればよい」「これまでどおりの管理帳票が出せればよい」「現状のサービスレベルを満たせればよい」といった観点で要求仕様を策定し、ベンダーに発注してしまうわけです。このようにして構築されたシステムは、結果的にマネジメントの要件が反映されていない伝票処理を行うだけのシステムになってしまいます。
変革の目的を分解・具体化
今日では、多くの企業が、「筋肉質な経営体質への転換を図り、競争力を高め、収益を向上させる」といったビジョンを掲げ、変革を目指しています。ところが、その議論は単なる希望や方向感の域を出ず、具体的に何を成すべきかという検討作業が行われていません。変革に必要とされるのは、ビジネスや業務そのものの再設計です。そのためには、変革の目的を、テーマ、施策、アクションに分解して、取り組むべきことを具体化させていくことが不可欠と言えます。では、変革の目的を分解・具体化するには、何をどうするべきなのでしょうか──。
その第1ステップでは、変革の狙いや効果を明確にした組織横断の「取り組みテーマ」を、論理的なプロセスのかたまりである「施策」に分解します。続く第2ステップとしては、分解した「施策」を前後関係や準備期間を考慮しながら、例えば、3年間の実行計画といった「ロードマップ」にまとめていきます。
そして第3ステップとして、直近で取り組む施策を、業務や部門の役割変更点、業務の規定基準、システム要求事項、想定効果および測定方法といった要素別に分解していきます。
この結果として、さまざまな施策の相互関係と整合性が担保され、具体的で実現可能な取り組みを推進していくことが可能となります(図3)。

図3:変革の目的を分解、具体化する
マネジメント要件を検討する
変革を遂行するに当たっては、マネジメント要件を検討し、マネジメントプロセスを確立しておくことも重要です(図4)。ここで言うマネジメントプロセスとは、ビジネスの状況チェック、問題点の共有、対策の実施というサイクルを回していくことを意味します。まず、業務処理結果が反映された情報環境を用いて、「業務は上手く実行されているか」「計画との乖離状況はどうか」といったチェックを行います。次に、そこで明らかになった問題が仮に複数の部門を横断するものであれば、関係者を集めて問題を共有し、全員で解決策を検討します。そして対策責任者を決めて問題解決の対策を推進するというわけです。
マネジメントに求められるのは、組織の目標達成にほかなりません。この大前提に立ち、マネジメントプロセスをどう確立するか、マネジメントプロセスと業務処理プロセスの両方の要件を満たす情報環境をどう築くかを、「企画・構想・選定」の中で議論していく必要があります。また、それによってはじめて、目標を達成するためのプラットフォームを構築し、組織としての的確な舵取りを行っていくことが可能になるのです。

図4:マネジメント要件の検討