{{item.title}}
{{item.text}}
{{item.text}}
DXの進展に伴い、企業が長年使い続けてきた基幹システムを、クラウドやAIなどを取り込んだ最新の技術基盤にモダナイズする動きは加速しています。しかし、いざ基幹システムの刷新プロジェクトを始めてみたものの、思うように前に進まなくなったり、プロジェクトが止まってしまったりするケースも少なくありません。
それでも何とかしてプロジェクトを進めても、予定期間の大幅な延長や予算超過といった問題も起こるかもしれません。最悪の場合には「プロジェクト管理義務」を主な理由に発注者がベンダーに損害賠償の裁判を起こしたり、逆にベンダー側が「協力義務」などを理由に発注者に反論したりするリスクも想定されます。
こうした基幹システムの刷新にまつわる「失敗」を回避し、成功に導くにはどのようにすればよいのでしょうか。本稿ではさまざまな失敗の原因を追求し、その防止策について考えます。
システム刷新プロジェクトがうまく進まない根本原因の1つは、提案・契約の前段階で発注者とベンダーの想いが一致していないことです。
発注者側は、システム選定の段階で「システム刷新を通して、こんな課題を解決したい」という漠然としたイメージを持っていたとしても、「それに適しているのは、どのベンダーのどのシステムなのか」ということまでは、明確に特定できていないケースが多いものです。
実際に、プロジェクトを進めていく過程でシステムの仕様や機能が発注者側の業務に合わないことや、結果として追加の機能開発が必要で追加コストが掛かってしまうことが明らかとなり、「イメージと違った」と後悔する企業も少なくありません。
発注者の業務要件を実現するためには追加の機能開発が必要となることも多く、その場合は当然ながら費用が発生します。ここでベンダー側がこれまで掛かったコストも踏まえ「標準パッケージ」をベースにしたシステムを提案した場合は注意が必要です。
確かに自社業務をシステムの「標準パッケージ」に合わせながら、業務の進め方を変革することができれば問題のない話でしょう。しかし複雑化した業務の場合は標準機能では足りず、追加開発が必要となることが少なくありません。システム刷新プロジェクトを成功させるためには、提案をそのまま受け入れず、自社のありたい姿をしっかりと持つことが求められます。
またこのような失敗を避けるためにも、提案された内容については「費用の安さ」や「手軽さ」だけでなく、「自社の理想とする業務を実現できるのか」「妥当な金額なのか」を相見積もりや第三者の視点を入れて評価することが大切になります。
ベンダーとの契約が完了し、システム刷新プロジェクトが実際に動き出した後も、さまざまな原因によってプロジェクトが行き詰まってしまうことがあるでしょう。
中でも、発注者側が特に陥りやすい失敗の原因は3つあります。以下、詳しく見ていきましょう。
発注者側が主体的にプロジェクトに関与せず、ベンダーに任せきりにしてしまうのは、失敗に陥りやすい大きな原因の1つです。
特に要件定義において、ベンダーはITやシステムのプロではありますが、現行のビジネスや課題について深く理解しているのは実際に業務を行っている発注者側であることを忘れてはなりません。発注者側のシステム部門、業務部門が主体的に要件定義に関与し、新システムで実現したい姿をベンダー側と議論することが重要です。
発注者側のプロジェクトへの参加が十分でない場合、実際の業務にそぐわないシステムができ上がってしまい、結果として手戻りなどの無駄な時間と費用が発生します。最悪の場合、多額の費用を投じて刷新したシステムがまったく使い物にならず、損失計上せざるを得なくなるケースも考えられます。
業務を行う現場の担当者は、長年やり慣れている業務の方法や手順を変えることに強い抵抗感を覚えるものです。特に基幹システムを刷新に伴う業務の見直しは、それまでと異なる方法や手順を強いられるため「今までのやり方が続けられるようにしてほしい」という現行踏襲の要求が高まりやすくなります。
しかし、そうした要求に合わせてシステム導入を進めると、追加開発に伴う期間と費用は増してしまいます。システム刷新は、既存の業務のやり方を見直し、改善や効率化を図るチャンスでもあります。いかに現場を巻き込み業務変革につなげられるか――これは、刷新プロジェクトを円滑に進めるための重要なポイントの1つです。
システム刷新に限らず、あらゆるプロジェクトの進捗と成否は意思決定者の判断と指示に大きく左右されるものです。
特に意思決定者やステアリングコミッティによる承認が曖昧な場合は、プロジェクトが思うように進まず手戻りを起こす可能性もあります。
こうした原因を踏まえ、基幹システム刷新プロジェクトを成功に導くために押さえてほしいポイントは以下の3点です。
このうち3では、要件定義から設計、開発、テスト、リリースといったフェーズごとに工程評価を行いながらプロジェクトを進めることで、手戻りを抑えることができるはずです。
以上、基幹システム刷新プロジェクトの「失敗」の原因と予防策について見てきました。
失敗の原因に共通するのは、発注者側の主体的関与の不足、現場の「現行踏襲」バイアス、意思決定・工程評価の曖昧さといったもので、主に人の意識や慣習に起因しています。PwCコンサルティングでは、第三者の立場からそうした原因の「本質」を客観的に見極め、意識変革も含めた伴走型の支援を行います。
また、発注者とベンダーの間に立って意思疎通を図り、プロジェクトの円滑な遂行を担うことも可能です。基幹システムや、業務変革に課題をお持ちの企業は、ぜひお気軽にご相談ください。
{{item.text}}
{{item.text}}
{{item.text}}
{{item.text}}