, ,

SaaSタイプのERPにおける各フェーズの完了基準判定  その３：完了基準を満たしていないときのケーススタディー

評価基準があるからこそ、現状がどこにあり、何が足りていないのかが分かります。そして、その差分が次の行動につながります。

本稿では、業務構築フェーズの終盤で完了基準を満たしていなかった二つのケースを取り上げ、どのように判断し、どのような対処を行うべきかを整理します。

ケース1：業務構築フェーズ終盤で、MoSCoWの要求が大量に残っているケース
評価水準を満たせなかった評価項目

業務構築フェーズの終盤において、MoSCoWで起票された要求が、実機検証で評価されないまま数多く残っていました。一見すると、完了基準を満たしておらず、NoGoと判断すべき状態にも見えます。しかし、この時点で確認すべきなのは、要求が残っていることだけではなく、残っている要求の分類です。

評論

残っていた要求の多くは、現行業務を前提としたAs-Is起点の要求でした。To-Be業務へ移行することが前提でありながら、見直されないままMoSCoWに残っていたものです。

一方で、ビジネスプロセスそのものは標準機能に適合しており、ビジネスデータモデルも標準に準拠した形で実機検証を終えられる見通しが立っていました。Mustに該当する要求、Shouldに分類される外部取引要求は、業務構築フェーズで成立していました。

また、課題管理を確認すると、「ビジネスプロセス課題」に分類されていたものは概ね解消されており、残っている課題は習熟度に関するトレーニング課題や権限およびセキュリティ課題でした。

帳票についても、ECRSのEliminate（排除）やCombine（統合）の整理が不十分なままではありましたが、標準プロセスでの検証自体は成立していました。これは、As-Is帳票が不要であった、もしくは標準帳票のRearrange（再配置）で対応可能であることを意味しています。仮に確認漏れがあったとしても、インプットとなるデータ検証が終わっていれば、アウトプット側の帳票はデータ取得タイミングを整理した上でSimplify（拡張機能）として後続フェーズで対応できます。

判断

以上を踏まえ、このケースではMoSCoWの消化率だけを理由にNoGoとする必要はないと判断しました。確かにMoSCoWや習熟度は未達ですが、ビジネスプロセス自体は網羅的に稼働検証されており、残差分の影響は限定的です。そのため、業務構築フェーズは完了基準を満たしていると捉え、「Go」と判断しました。

対策・申し送り

ただし、未評価のMoSCoW要求が残っている事実は、そのまま次フェーズへ申し送る必要があります。

具体的には、業務構築フェーズで評価できなかったAs-Is起点の要求については、運用モデル評価の対象として次フェーズに申し送ります。運用モデル評価は本来ユーザー主体で進める工程ですが、習熟度が完了基準を満たせていないことなど、本ケースでは当初計画から差分が生じているため、その差分対応に限ってベンダーがサポートに入る前提とします。

残MoSCoWや帳票の要求については、ECRSの観点で再整理します。ユーザーは業務運用の観点から実務影響を評価し、ベンダーは標準機能での代替可否や最小限の拡張対応について助言する役割を担います。

ケース2：業務構築フェーズでもなおインターフェースが定まらないケース
評価水準を満たせなかった評価項目

業務構築フェーズに入ってから、インターフェースに関する検討が大きくぶれました。最終的なインターフェースの総数自体は大きく変わっていないものの、フェーズ内で入れ替えが頻発していました。

インターフェース構成が安定せず、次フェーズに進むための前提が揃っていない状態だったのです。

評論

構想策定フェーズでは、インターフェースはシステムマップとして一度整理されていました。しかし、業務構築フェーズで実機検証が進むにつれて、「実績収集は別システムの方が入力しやすい」「輸送システムと連携したい」「配送センター新設に伴いWMS連携が必要になる」といった判断が次々に出てきました。その結果、データ連携はシステム単位で増えていったのです。

一方で、CSVやEDIでの受注取込、多種類あるWMSシステムなど複数存在していた同種の連携について「中間に連携システムを設けてまとめる」という方針も示されインターフェース本数削減に貢献しました。しかし、この施策は方向性にとどまり、具体的な連携項目やデータの受け渡し方法までは整理されていませんでした。

さらに、外部システムベンダーとの調整も円滑に進んでいませんでした。ビジネスデータとトリガーイベントの整理が十分でないため、「どの業務イベントを起点に、どのデータを、どのキー項目で連携するのか」が時系列で確定せず、システム間のステータス更新の整合も取れないまま検討が続いていたのです。

判断

この状態は、ビジネスプロセスとデータ準備の双方が未成立であることを示しています。外部連携の仕様が固まらないまま開発に持ち込まれると、その影響はデータ移行実施やシステム間テストにも及び、工程の遅延を招きます。さらに、システム統合テスト期間中の仕様変更を引き起こすことも想定されます。これらのタスクはいずれもクリティカルパス上にあるため、結果としてマイルストーンの遅延につながります。

このため、本ケースでは「NoGo」と判断します。

対策

業務構築フェーズで一度立ち止まり、まずビジネスプロセスとトリガーイベントを整理し直します。その上で、対象となるCRP検証を通じて時系列でデータフローを確認し、インターフェース構成を再確定することが必要です。

ケーススタディから見える完了基準の役割

これら二つのケースが示しているのは、完了基準が単なるチェックリストではないという点です。

完了基準の役割は、「すべての評価項目が終わったかどうか」を確認することではなく、評価結果と基準との差を可視化し、その差分をどう扱うかを判断することにあります。

業務構築フェーズでMoSCoWの要求が残っていても、評価水準が次のフェーズに進めるレベルに達していれば、Goと判断することは可能です。一方で、インターフェースのように、ビジネスプロセスやトリガーイベントが不安定な状態では、たとえ作業量が多く進んでいたとしても、NoGoと判断せざるを得ません。違いを生むのは、消化率や進捗率ではなく、次のフェーズで検証や構築を成立させられるかどうかという評価水準です。

こう考えることもできます。「100点を目指して立ち止まるのか」「評価水準を満たした段階で次に進み、80点、90点と引き上げていくのか」という判断です。60点から80点へ引き上げるために必要な時間と、80点から100点に仕上げるために必要な時間は同じではありません。完了基準を満たしているのであれば、残る改善余地を次のフェーズに申し送り、引き上げながら進む判断が、結果として全体最適につながります。

完了基準があるからこそ、「なぜGoなのか」「なぜNoGoなのか」を属人的な感覚ではなく、構造として説明できます。そして、その判断は必ず次の行動に結びつきます。完了基準とは、プロジェクトを止めるためのルールではなく、前に進むための判断軸なのです。

まとめ

本シリーズでは、SaaSタイプのERP導入における完了基準を、前提整理、フェーズ別チェックリスト、ケーススタディの三つの観点から解説してきました。

各フェーズで到達すべき評価水準を確認し、その水準を満たした上で次の段階へ進んでいく。この積み上げによって、最終的な本稼働判定は確かなものになります。

完了基準を正しく使えるようになると、単に評価項目の達成・未達を見るのではなく、評価項目同士の関係や因果を捉えた上で、次に進むべきか、立ち止まるべきかを判断し、必要な手を打てるようになるのです。