, ,

SaaSタイプのERPにおける各フェーズの完了基準判定 その２：フェーズ別チェックリスト

前回の投稿「前提整理」では、フェーズごとの判定がいかに重要かを解説しました。今回はそれを実践レベルに落とし込み、プロジェクトマネージャーやPMOがそのまま利用できる「フェーズ別完了基準チェックリスト」として公開します。


本記事を読む前の重要なお知らせ
本チェックリストでは、ERP導入プロジェクト特有の専門用語やフレームワーク（ECRS、MoSCoW、ILUOなど）を使用しています。これらの用語の定義や詳細な進め方については、過去の「ERP知識シリーズ」などで詳しく解説しています。理解を深めるために、必要に応じて以下のリンク先をご参照ください。

本稼働判定との関係性について
本記事で紹介するリストは、過去に解説した以下の「本稼働判定」シリーズと密接に関係しています。

「本稼働判定」は、各フェーズの完了基準（ゲート判定）を確実にクリアしていく積み重ねが、最終的な本稼働判定のリスクを低減させ、客観的なGo/No-Go判断を可能にします。
以下に、5つのフェーズ（構想策定、業務構築、システム構築、導入移行、運用開始）と、6つの評価領域（ビジネスプロセス、データ、技術、人材、移行、運用）に基づいたチェックリストを提示します。

フェーズ1：構想策定

テーマ：全体像の把握と実機検証のための仮決め
このフェーズのゴールは、スコープを明確にし、次フェーズの実機検証を迷いなくスタートできる状態にすることです。

P1：ビジネスプロセス準備
  • スコープ定義：プロジェクトスコープとその境界（やらないこと）が明確に定義されている
  • 標準適合：洗い出した業務プロセスが、ERPの標準プロセスフローへマッピングされている
  • To-Be決定：採用する「To-Be（あるべき姿）」のビジネスプロセスフローが選択されている
  • 物流フロー：ものの流れが拠点間などのFrom-toの組み合わせとして整理されている
  • イベントトリガー：情報の発生源となるトリガーイベントがプロセスに紐づけられている
  • 要求管理：業務上の制約（3M+Method）や必須要件（Must）がMoSCoWで起票され、フローと対応づけられている
  • 課題方針：BPRなどの重要な課題が起票され、対応方針が定まっている
  • 帳票整備：帳票（伝票やラベル含む）が棚卸され、ECRSの排除（Eliminate）と統合（Combine）による削減方針が決まっている
P1：ビジネスデータ準備
  • モデル定義：標準データモデルを前提とした主要データ（在庫階層、取引パターン、品目、BOM、顧客、仕入先、勘定科目等）の構成・粒度・ルールが定義されている
  • システムマップ：システム間連携について、ファイルレベルでのシステムマップが整理されている
P1：技術準備
  • 環境構築：クラウド環境が構築され、ユーザー登録とログインが可能である
  • 稼働確認：ウォークスルーレベルでの稼働確認ができ、検証が開始できる状態にある
  • システム連携方式：連携構成や接続方式、通信・文字コードなど技術仕様を統一している
  • データ連携・管理方針：データ保管場所や連携ツール利用基準、ファイル運用ルールを定義している
  • エラー処理・監視方針：エラー検知の役割や監視通知、リカバリ手順の運用方針を整理している
  • インフラ・セキュリティ要件：インフラ稼働要件やDB接続禁止等のセキュリティ方針を明文化している
P1：人材準備
  • 検証体制：業務構築フェーズで検証を担う担当者と役割が定まっている
  • 教育計画：教育計画およびスキル評価方法（ILUO等）が定義されている
  • 合意形成：重要課題に対するワーキンググループ体制が組成され、主要ステークホルダーがスコープに合意している
P1：移行準備
  • 範囲棚卸：会社や事業・業務・システム・データの移行対象範囲が棚卸しされている
  • 移行方式：ビッグバン移行（一括）か段階移行かの方針が決定されている
  • 並行稼働：新旧システムの並行稼働を行うか否か（リスクとコストのトレードオフ判断）が決定されている
  • 本稼働時期：業務の繁忙期、決算期、工場稼働スケジュール等を考慮した上で、有力な本稼働日（案）が提示され、経営層との合意形成プロセスが含まれている
  • 移行方針：移行手段、検証方法、切り戻しを含む移行方針と責任分担が決まっている
  • システム環境：移行元システムの環境数やOSバージョン等の前提が確認されている
P1：運用準備
  • 運用設計：問い合わせ・障害対応・変更管理の体制方針と役割分担が定まっている
  • リスク管理：主要リスクが認識され、軽減策とコンティンジェンシー（緊急時対応）方針が整備されている
  • 他プロジェクト：関連する他プロジェクトのマイルストーンと相互影響が明確化されている
フェーズ2：業務構築

テーマ：実機検証によるブループリント確定
机上の空論ではなく、SaaSの標準機能で業務が回ることを「実機」で証明し、標準機能への適合性（Fit to Standard）を確定させるフェーズです。

P2：ビジネスプロセス準備
  • 標準検証：標準機能のプロセスフローでの稼働確認が完了している
  • スコープ管理：実機検証で追加されたプロセスが「分母（全対象）」に反映され、管理されている
  • 重要課題の解決：フェーズ1で起票された重要課題（BPR等）に対し、実機検証を通じて解決策が確定している
  • プロセス課題の解決： 実機検証（CRP）で発生した課題管理表上の「プロセス課題」が消化（対処・合意）され、次フェーズへの持ち越しがない（または許容範囲内である）
  • 拡張判断：標準で成立しない箇所が拡張機能要求として起票され、扱い（運用回避・アドオン開発・連携等）のソリューションが記録されている
  • 帳票要件：帳票（伝票やラベル含む）の実用性が検証され、ECRSの再配置（Rearrange）と単純化（Simplify）の評価が完了している
P2：ビジネスデータ準備
  • コード定義：主要マスタのコード定義、採番ルール、属性定義および名称ルールが確定している
  • 構造定義：会社、事業部、倉庫、場所（ロケーション）の物流・組織階層構造がシステム設定レベルで定義されている
  • 会計・原価モデル：勘定科目体系、会計ディメンション（分析軸）、原価計算モデル（標準原価、実際原価の算出ロジック）が定義されている
  • データ検証：少量データを用いた登録・参照・更新の検証が完了している
  • 分析要件：分析などアウトプット側を想定したデータ利活用定義と、入力データとの整合性が取れている
P2：技術準備
  • 周辺機器：ハンディターミナルやラベルプリンタなどの利用方針と機種選定が進んでいる
  • I/F設計：周辺システムとのインターフェース要件（項目マッピング等）が定義されている
  • 環境設定：次フェーズ（システム統合テスト）に向けた環境定義計画が立っている
P2：人材準備
  • スキル習得：検証メンバーのスキルがILUOの「U（理解）」に到達している（シナリオ検証を理解し自立して検証可能）
  • 判断能力：検証メンバーが検証中の判断内容を説明できる
  • 内製化：（内製化の場合）拡張機能開発などのトレーニングを受講済みである
P2：移行準備
  • 前提反映：CRP（検証）で判明したデータや業務の前提が移行対象へ反映されている
  • 手順具体化：移行方針書に基づき、移行のリハーサル計画、本番移行のスケジュール、役割分担が合意されている
  • データ整備：現行データのクレンジング計画が立案され、現行ベンダーへの協力要請が必要な範囲で行われている
  • 移行マッピング：移行対象データ（マスタおよびトランザクション）のフィールドレベルでのマッピング（移行元→移行先）が完了している
P2：運用準備
  • 管理試行：検証中の問い合わせ・不具合・変更要求がルールに沿って管理されている
  • インシデント管理：インシデント登録の実績がある（ツールやフローの試行ができている）
  • 本稼働判定基準：本番稼働判定に向けた評価領域と評価軸（網羅性、可動性、適合性など）のドラフトが作成されている
フェーズ3：システム構築

テーマ：システム統合による稼動確認
単体ではなく、外部システムを含めた「統合状態」での稼働品質を確認します。

P3：ビジネスプロセス準備
  • 拡張開発完了：拡張機能の開発が完了している
  • 課題対応の実装： 確定した重要課題の解決策（業務フロー・機能）がシステム上に実装され、確認されている
  • 統合検証：ERPに連携する全システムを含めた統合状態で、対象プロセスの稼働確認が終わっている
  • 例外処理：例外処理の取り扱いが運用ルールとして確定している
P3：ビジネスデータ準備
  • 品質担保：統合状態においても、定義したデータ構造とデータ品質が破綻していない
  • SITデータ品質： データ移行リハーサルを経た本番相当の全量データを用いて、システム統合テストが実施されている
  • エラー対応：データ登録後に残るエラーについて、テストへの影響と対応方針が記録されている
P3：技術準備
  • 外部接続：外部システム接続が成立している
  • 性能評価：負荷テストによる性能評価が完了している
  • ジョブスケジュール：ジョブスケジュールが作成され、時間軸に沿った稼働検証がされている
  • セキュリティ実装：フェーズ1で定義したセキュリティ要件（接続制限等）や権限設定が統合状態で実装・確認されている
  • 障害テスト：フェーズ1で定義したエラー処理方針に基づき、異常系（エラー発生、再送、ログ出力、アラート通知）のシステム動作が検証されている
  • 監視と権限：監視設定と権限設定が統合状態で成立している
  • 障害管理：テストで発生した障害や残課題の業務影響が整理され、扱いが決まっている
  • 本番環境：本番環境が構築され、拡張開発物が移送されている
P3：人材準備
  • 自走：プロジェクトメンバー主体で運用モデルを実践し、ほぼ自走できている
  • スキル評価：メンバーのILUO「O（指導できる）」到達状況が把握できている
  • 操作マニュアル：ユーザーが操作マニュアルを作成できる仕組み（またはドラフト版）が準備されている
  • 内製化実践：（内製化の場合）標準機能での業務設計を前提とした実践が始まっている
P3：移行準備
  • 手順確定：業務・システム・データの全移行手順が確定している
  • リハーサル：移行手順と検証手順が整理され、データ移行リハーサルが実施されている
  • クレンジング完了：フェーズ2で計画されたデータクレンジングが完了し、移行可能な状態になっている
  • マスター確定：マスターデータが移行対象として確定している
  • トランザクション：トランザクションデータの移行テストができている
P3：運用準備
  • ヘルプデスク：問い合わせ・障害・変更管理の運用設計が整っている
  • 運用試行：システム統合テスト期間中に、ヘルプデスク運用（エラー通知を受けた後の対応フローやエスカレーション）を試行できている
  • UAT準備：ユーザー受入テスト（UAT）の計画・シナリオ作成が完了し、実施体制が整っている
フェーズ4：導入移行

テーマ：移行の実行準備とリハーサル
本稼働判定に向けた最終試験期間です。「本稼働判定 実践編」におけるスコアリングの基礎データはここで出揃います。

P4：ビジネスプロセス準備
  • 初動確定：切替後、初日から回す主要業務の手順と担当が確定している
  • メニュー：システムメニューが定義され、エンドユーザートレーニングで活用されている
P4：ビジネスデータ準備
  • 最終品質：最終移行データの品質が担保されている（移行後の業務運用が再現できる）
  • 反復準備：繰り返しデータ移行リハーサルを行うためのマスターデータ整備ができている
P4：技術準備
  • 周辺機器：現場でハードウェア（Wi-Fi、ハンディ端末、プリンター等）が利用可能である
  • 権限適用：役割に基づいた本番の権限設定が適用されている
P4：人材準備
  • 引継ぎ：操作マニュアルが完成し、プロジェクトメンバーからエンドユーザーへ引き継がれている
  • 役割：エンドユーザーの役割が把握でき、未達者への補講計画が実行可能である
  • 習熟度：エンドユーザーが担当領域のオペレーションをILUO「U（理解・実行可能）」水準で実行できる
P4：移行準備
  • 時間計測：移行リハーサルにより、所要時間と検証方法が確認済みである
  • 初動体制：切替当日の監視体制と初動対応の手順が確定している
  • 切り戻し：切り戻し（フォールバック）の仕組みと手順が検証できている
P4：運用準備
  • 体制確立：問い合わせ対応と障害対応の体制が立ち上がり、エスカレーションが実践できる
  • 現場支援：現場（拠点・店舗）のサポート体制が確立している
  • 判定基準：本稼働判定基準（Go/No Go）が明確かつ客観的である
  • 合意形成：エンドユーザーからのフィードバック回収と対策、社内外への本稼働通達準備ができている
フェーズ5：運用開始

テーマ：安定稼働と定着
本稼働後の安定化（ハイパーケア）期間の完了基準です。

P5：ビジネスプロセス準備
  • 業務継続：例外処理を含め、業務が止まらずに稼働している
  • ルール遵守：定めた運用ルールが現場で適用されている
P5：ビジネスデータ準備
  • 品質維持：定義したデータ構造が、本稼働後も品質を保ったまま維持されている
P5：技術準備
  • 監視：監視システムが継続稼働している
  • 性能：性能問題が業務運用に悪影響を与えていない
P5：人材準備
  • 属人性排除：特定個人への依存（属人性）が抑えられている
  • 教育：引継ぎや追加教育が運用手順（プロセス）として機能している
P5：移行準備
  • 残課題：残存している移行タスクや安定化タスクが管理され、収束に向かっている
P5：運用準備
  • 運用実践：問い合わせ・障害・変更管理が運用として実践されている
  • 数値管理：エラー発生件数、対応件数、残件数が数値管理されている
  • 引継ぎ：プロジェクトメンバーから保守サポートメンバーへの引き継ぎが完了している
まとめ

SaaS ERP導入における完了基準は、上記のリストをゲート判定時のチェックリストとして用いることで、抜け漏れを防ぐことができます。重要な点は、「分母（スコープや対象）」が変化した場合、必ずその変化を反映して検証対象として管理することです。この積み上げこそが、最終的な本稼働判定（Go/No Go）の材料となります。

しかし、実際のプロジェクトでは、すべての項目が完璧に「完了」とならないケースも多々あります。次回の投稿では、「基準を満たせない項目」が出てきた際に、単にNGや課題対応とするのではなく、評価項目同士の関係性に基づいた現実的な判断基準について解説します。ある項目が未達であっても、関連する別の項目で網羅性が担保できていれば「次フェーズに進んでも手戻りのリスクは低い」と判断できるケースがあります。そのような実践的な判定のロジックを、ケーススタディ形式でご紹介します。