合併の際のシステム対応 失敗事例(業務プロセス変更もれ)
企業の合併時、基幹システムについては、多くの場合、どちらかの会社のシステムを継続して使用する「片寄せ」が採用されます。
特に同業者間の合併の場合は
「同業同士の合併だから業務プロセスは殆ど変わらないし、システムの追加開発もないから特にリスクはないだろう」
とお考えのシステム責任者の方もいらっしゃるかもしれませんが、油断していると大きなトラブルにつながりかねません。
特に、お客さまとの接点に関連する業務プロセスについては、詳細フローまで入念に確認し、すり合わせをしておく必要があります。
ここでは、卸売業のA社(存続会社：システムを継続利用)とB社(消滅会社：今後A社のシステムを使用)の注文処理プロセスにおける失敗例と改善ポイントについて考えてみましょう。
【失敗例】
A社とB社で、注文から出荷までのプロセスに大きな違いはありませんでした。
しかし、注文ステータスの変更に伴う顧客への通知プロセスにおいて、2社のプロセスは以下のような差異がありました。
A社：営業担当者がシステム上で納品予定日を確認し、メールか電話で顧客連絡
B社：納品予定日はシステムから顧客担当者へ自動で直接メール通知される
B社システムに慣れ親しんだ元B社所属の営業担当者は、
「納期変更があった場合は顧客へ個別連絡する」
という手順を認識しておらず、納期変更情報が顧客に伝わらないことによる
クレームが殺到する事態に陥りました。
【改善ポイント】
この例のように、見た目上は同じ業務をおこなっていても、詳細プロセスに差異があればトラブルの種となります。
システムが変わる側(今回だとB社)においては、業務プロセスの変更点を洗い出し、実際にシステムを使用したテストを徹底しておく必要があります。
特に、今回のように直接顧客とやり取りをおこなう業務においては、B社出身者による入念なレビューと全担当者向けのトレーニングも必須となります。
このように、組織再編時において「業務プロセスの変更確認」は、ビジネスに大きな影響を与え得る、非常に重要な論点となります。
一見、そんなに大きな問題のようには見えないものですが、事前に十分な検討が必要です。
（執筆：本庄）
