「S/4 HANAでクラウド化」No.13 S/4 HANAのクラウドで失敗！？体験談を踏まえた対策について解説

１．はじめに

大規模なシステム移行プロジェクトでは何かしら失敗してしまうケースがあります。可能な限り失敗しないように準備していても、認識不足などから失敗してしまうのです。

今回はS/4 HANAのような大規模なシステムのクラウド移行に関する失敗事例をご紹介します。どのような失敗が生じる可能性があるのか理解して、自分たちのプロジェクトに先人の経験を活かしましょう。

２．S/4 HANAの失敗談：文章管理の不徹底で作業工数が増加

こちらはシステムに関する文章を正確に管理できていなかったことで、システム移行前に状況が正しく把握できなかったものです。その結果、S/4 HANAへの移行作業で考慮漏れが生じてしまい、想定よりも作業工数が増加してしまいました。

２－１．失敗の内容

このプロジェクトではS/4 HANAへの移行が完全に失敗したのではなく、期間が延びてしまったという観点での失敗です。S/4 HANAをクラウド環境に構築してデータを移行する大規模なプロジェクトです。

そもそもの想定期間が長いプロジェクトでしたが、各種テストの過程でビジネス部門より移行内容に不足があることが指摘されました。これにより要件定義フェーズへの手戻りが発生し、全体としてはリリースが4ヶ月も遅れる事態となったのです。

２－２．失敗の背景

このプロジェクトではS/4 HANAの前にSAPが導入され、導入時にはシステム構成図やカスタマイズの一覧などシステム管理に必要な資料がすべて納品されていました。システム導入プロジェクトに何かしらの問題があったとは考えられない状況であり、これらの資料をもとに移行の準備をすすめました。

しかし、クラウド上にS/4 HANAを構築して内容を移行するにあたって移行対象の不足が発覚します。確かに文章は納品されていたものの、それ以降の更新について正しく管理されていなかったからです。部分的に古いバージョンの資料が残っていたため、最新の情報を得られずプロジェクトが失敗する原因となりました。

２－３．失敗からの教訓

このプロジェクトが失敗した原因は文章管理が徹底されていなかったことにあります。社内で管理すべき文章が正しく管理されていなかったため、要件定義のもとになる資料に不足がありました。

文章管理が徹底されていなかった背景を深掘りしてみると以下のとおりです。

・担当者変更の際に引き継ぎされていなかった

・最新バージョンが提供されても放置されていた

・変更変更対象となる文書の存在を知らなかった

・文章を改訂する運用があると理解されていなかった

一部の理由については推測の域ではありますが、このような理由から文章は管理が徹底されなかったと考えられます。ただ、このような事象は基幹システムを導入しているどのような企業でも起こりうるものです。業務の変化に伴いシステム改修をしたにも関わらず、文章への反映漏れが起こるかもしれません。

既存システムの文章はシステム移行にあたって非常に重要なものです。クラウドのような新しい環境への移行でも既存の文章は非常に重要と考えておきましょう。

３．S/4 HANAの失敗談：担当者のITリテラシー不足でプロジェクト遅延

S/4 HANAの移行プロジェクトにアサインされた担当者のITリテラシーが低くプロジェクト全体が遅延したものです。IT側の担当者に問題はありませんでしたが、ビジネス側 担当者に問題がありました。システムのことが正確に分からず誤った判断を下してしまい、要件定義フェーズに遅延が発生しました。

３－１．失敗の内容

このプロジェクトではS/4 HANAへの移行において要件定義フェーズで失敗が発生しました。最終的なレビューの段階で誤りに気付いたため、リリースされた システムに影響はありませんでしたが要件定義を2回実施したような状況に陥っています。

３－２．失敗の背景

このプロジェクトではビジネス部門からワークストリームごとに 担当者がアサインされていました。ただ、その中に「業務はわかるが システムはわからない 担当者」が含まれていたのです。この人がシステム的に適切な判断をできず、要件定義で 誤った判断を下したのです。

また、アサインされた 担当者は当該部門の経験が長くビジネス部門の担当者としては 特に問題がありませんでした。しかし、 システムは決まった業務を中心に操作していたため「周りがそう決めたならば 正しいのだろう」と内容を 吟味しなかったことが失敗に繋がりました。

３－３．失敗からの教訓

このプロジェクトが失敗した原因はシステムに詳しい担当者がアサインされなかったことにあります。S/4 HANAのような基幹システムの移行プロジェクトでは、幅広い知識を持つ担当者をアサインしなければなりません。

ただ、以下のとおり、今回の担当者のアサインが必ずしも間違っていたとも 言い切れません。

・当該部門の経験は10年以上あった

・入社してから15年以上経過していた

・業務については教育係になれるほど理解できていた

業務的な知識不足が原因ではなく、システムの仕組みを理解できていなかったことが問題です。システムの仕組みについて詳しければ、状況は大きく異なるでしょう。

このような事例は他人事ではなく、どこの企業でも起こりうるでしょう。「業務は わかるが システムには詳しくない人」はどのような部門にもいるからです。業務的な理解だけでアサインする人を決め がちですが、ITスキルも考慮して 決めなければなりません。

４．S/4 HANAの失敗談：新機能に慣れずプロジェクトの方針変更

こちらはS/4 HANAに実装されている機能が既存と異なることで、プロジェクトの方針転換を余儀なくされたものです。想定外の作業が発生してしまい、プロジェクト期間もコストも大幅に超過してしまいました。

４－１．失敗の内容

SAPの移行プロジェクトが進められていましたが「クラウド化される」という部分だけが周知され「バージョンが変化する」という部分が周知されていませんでした。

結果、「使い勝手や業務フローが変化する」との内容が話題に上がったタイミングで一部から猛反発が生じ、プロジェクトの推進に影響が出てしまいました。最終的には部分的に既存の業務フローを採用する方針に修正され、S/4 HANAにカスタマイズを施すなどの影響が出ました。

４－２．失敗の背景

このプロジェクトが進められた環境では、アドオン開発を多用したSAPが稼働していました。そもそも標準的なSAPではなく、カスタマイズありきのSAPだったのです。

しかし、このようなSAPは「保守性が悪い」「運用コストが高くなる」などの問題を抱えていて、それが社内でも指摘されていました。そのため、S/4 HANAへ移行することを機に可能な限り標準機能へ業務フローを落とし込み、問題を解決する方針となっていたのです。ただ、このような方針は上層部だけで決定され、各担当者からのヒアリングは実施されておらず、これが失敗の原因となりました。

４－３．失敗からの教訓

今回のような業務フローやユーザーインターフェースの変化は社内からの反発を受けやすい部分です。このプロジェクトに限らず社内からの反発で進捗に影響が出るケースはよく見られます。

今回の事例では上層部が一方的に移行方針を決定したことが問題です。深掘りしてみると以下のような問題点が見えてきます。

・システムを利用していない上層部だけで意思決定した

・業務フローの変化について説明しなかった

・移行によって生じる問題は実質的に現場へ押し付けられた

・テスト環境で評価してもらうなどの期間が設けられなかった

・担当者へのヒアリングが実施されなかった

失敗の原因となる要素を挙げるとキリがありません。このような状態でプロジェクトを成功させる方が難しいといっても過言ではないでしょう。

５．まとめ

S/4 HANAの移行プロジェクトでどのような問題が起きる可能性があるのかご説明しました。基幹システムの移行は難易度の高いプロジェクトであるため、何かしらのほころびがあると失敗する可能性が高まります。ご説明した内容を踏まえて、最大限の準備に取り組みましょう。

また、プロジェクトの準備は重要となるものの、それだけでS/4 HANAへの移行が成功するわけではありません。特にクラウド環境へ移行する際は、オンプレミスでシステムを構築するのとは話が違います。その点も考慮して準備やプロジェクト推進に活かすようにすべきです。