M&Aに伴うシステム移行・統合におけるプロジェクトリスク管理 | KPMG | JP
close
Share with your friends

M&Aに伴うシステム移行・統合におけるプロジェクトリスク管理

M&Aに伴うシステム移行・統合におけるプロジェクトリスク管理

新たなITリスクに立ち向かう 連載シリーズ 第19回 - 近年M&Aは企業成長のための有力な選択肢として認知され、報道によると2015年通年での世界の企業合併・買収の総額は過去最大規模に達している。それに伴い、日本企業においても旧親会社グループからのシステムの切り離しや、買収先企業グループへのシステム統合の案件が増加している。

関連するコンテンツ

これらを実行することはM&Aの効果を得る上での大前提であるが、一方で適切に実行できない場合、企業は効果を得るどころか損失を被るおそれもある。

本稿では、M&Aに伴うシステム移行・統合の増加を踏まえ、これらの案件におけるプロジェクトリスク管理について解説する。

1. M&Aにおけるシステム移行・統合

新会社のIT部門にとっては、旧親会社グループのシステムからの完全切り離し(Day2、買収先企業グループへの統合も含む場合あり)が、新会社スタート後に迎える重要な山場となる。

図表1 M&AにおけるDay2の位置付け

M&Aでは基本契約締結時に、新会社スタート後も旧親会社の資産・サービスの使用を一定期間認める条項を定めることが通例である。新会社はこの期間内に新しいシステムを準備し、旧親会社に頼らない業務運営体制を整備する必要があり、新会社のIT部門はこの時間制約と限られた予算のなかで安定した品質のシステムを構築し、確実に移行しなければならない。M&Aに伴うシステム移行・統合は大規模なプロジェクトになるため、通常のプロジェクト管理業務(スコープ管理、進捗管理、課題管理等)と併せて、プロジェクトリスク管理が重要となる。

2. プロジェクトリスク管理のステップ

M&Aに伴うシステム移行・統合に係るプロジェクトリスク管理のステップは、通常の大規模システム構築の場合と同様である。すなわち、リスク要因を洗い出し、その要因ごとに想定されるプロジェクトリスクを検討し、これらへのコントロール(予防策、検知策、軽減策)を策定した上で、実施状況のモニタリングを行う。

図表2 プロジェクトリスク管理のステップ

銀行システムにおけるプロジェクトリスク(例)

リスク要因

顧客の入出金に係る業務を担うシステムである。

 

想定されるプロジェクトリスク
移行時にシステム停止が発生した場合、顧客が入出金できず、重大な社会的影響が発生する。

 

コントロール

  • 予防策
    翌営業日の顧客取引開始時間を見据えたタイムスケジュールを含む移行手順を整備し、訓練を実施する。移行作業中断の判断権者、判断ポイント、判断基準、切り戻し手順を含む移行コンティンジェンシープランを策定し、訓練を実施する。

 

  • 検知策
    移行訓練の完了、移行コンティンジェンシープランの策定・訓練の完了、発生時の顧客対応の準備完了を移行判定基準とし、経営陣のモニタリング対象とする。

 

  • 軽減策
    停止した場合の影響業務を洗い出し、関連する顧客対応(ホームページでの情報開示、コールセンター対応、手動での入出金手続等)の準備をする。

3. M&Aに伴うシステム移行・統合に係るプロジェクトリスク管理のポイント

M&Aに伴うシステム移行・統合においては、通常のプロジェクトリスク管理のステップを押さえた上で、M&Aに伴うシステム移行・統合に特有のリスク要因を意識する必要がある。特に注意が必要なリスク要因の例を以下に挙げる。

 

(1)期間制約
前述のとおり、一般的にM&Aでは新会社スタート後、旧親会社の資産・サービスの使用が一定期間認められるが、費用や保守期限等の問題から期間の延長が難しい。この場合、シナジー獲得のための効率化や新親会社グループとのシステムの融合等はDay2以降の課題とし、まずはシステム切り離しに注力する等、期間内に確実に完了するスコープを設定することが求められる。

 

(2)関係者の多さ
システム移行・統合においては、自社側だけでなく、相手側の親会社、経営陣、IT部門・業務部門、ベンダー等、一般的な大規模システム構築プロジェクトと比較しても関係者は多岐に渡る。このため、それぞれの業務の進め方や使用する用語も異なり、思わぬところで意思疎通に支障をきたすようなケースも見られる。また、対等合併が前提となる場合では、意思決定が問題となることがある。プロジェクトを確実に推進するには、これらの関係者の役割・責任・権限や、利用する用語の定義を文書として予め明確に定めた上で、プロジェクトを運営することが望ましい。

 

(3)異なるデータ構造
買収先企業グループへのシステム統合が前提となる場合は、データ構造の違いがボトルネックになることがある。データの整理には多くの人手と意思決定が求められるため、プロジェクト後半に想定以上の差分が発覚すると、予定納期までに完了することが難しくなる。データの差異についてはプロジェクトの早期に確認を行い、対応策を具体的な作業に分解してWBS(Work Breakdown Structure)に定義し、確実に実施することが求められる。

 

(4)当局への説明
金融機関等の規制業種の場合、システム移行・統合に係るプロジェクト管理状況が当局のモニタリング対象となることがある。プロジェクト管理状況の妥当性を当局に説明できない場合、改善が求められ、プロジェクトの計画が大きく狂うことも想定される。規制業種では当局が注視するポイントをもとに、外部説明力のあるプロジェクト計画の策定、説明を実施するタイミングを考慮したスケジュールの策定等、当局への対応を意識した運営が求められる。

4. 経営陣の関与の重要性

M&Aに係るシステム移行・統合では高度な意思決定を求められる場面が多々あるため、経営陣の継続的な関与が非常に重要となる。プロジェクトリスク管理の取組みにおいても、洗い出された重要リスクやそのコントロールの実施状況は意思決定の重要なインプットになるため、経営陣に向け可視化する必要がある。

このことは一部のガイドラインにおいても定められており、たとえば金融庁は「システム統合リスク管理態勢の確認検査用チェックリスト」※1(以下、「統合チェックリスト」という)」のなかで、金融機関の経営陣が自らリスク管理の重要性を認識し、必要な体制を整備することを求めている。

 

※1 金融庁「システム統合リスク管理態勢の確認検査用チェックリスト」(平成14年12月)[PDF: 355kb]

図表3 統合チェックリストにおける経営陣への要求事項(例)

 

チェック項目 概要
経営統合に係るリスクに対する認識 事務・システム等の統合準備が不十分な場合のリスクを十分に認識し、リスク管理の必要性・重要性を全役職員に周知すること
協調体制の整備 統合対象金融機関や外部委託先と十分な意思疎通が図られる体制を整備すること
顧客対応の重要性に対する認識等 顧客利便や変更内容に関する顧客説明、不測の事態が発生した場合の顧客対応態勢を整備すること
統合方針の確立 統合方針を明確にし、組織全体に周知すること
ビジネスモデルの確立 システム統合方式、統合後の組織体制、サービス、システム構成等を明確にすること
統合計画および実行計画の策定 期限、要員制約、リスク管理や資源配分等を踏まえて妥当性を十分検討した統合計画を策定すること
統合プロジェクトの管理 プロジェクトの進捗状況を的確に把握しプロジェクトの問題点に適切に対応できる体制・手続を整備すること
統合プロジェクトの移行判定 システム・業務の移行判定基準を承認し、基準に基づいて移行の可否を判断すること

出典:金融庁「システム統合リスク管理態勢の確認検査用チェックリスト」を基に筆者作成

5. まとめ

最後に、M&Aに係るシステム移行・統合におけるプロジェクトリスク管理におけるポイントをまとめる。

  • プロジェクトリスク管理は基本を押さえて確実に実施する
  • M&Aに係るシステム移行・統合特有のリスクを考慮する
  • プロジェクトリスク管理の主体は現場部門ではなく経営陣である

これらを考慮し、十分に準備することをお勧めする。

執筆者

KPMGコンサルティング株式会社
シニアマネジャー 中田 淳平

新たなITリスクに立ち向かう 連載シリーズ

お問合せ

 

RFP(提案書依頼)

 

送信