会計システム刷新シリーズ総集編（その5）

会計システム刷新のシステム要件定義フェーズは、導入対象となる製品・サービスを前提に、標準機能設定などシステム要件を具体化するフェーズであり、ERPや会計パッケージをFit to Standardで導入できるか否かが決まる重要なフェーズです。したがって、ここで安易な検討を行うと、導入できたものの業務で使えず、想定以上のコストと期間がかかり、プロジェクトが頓挫することも少なくありません。

そこで「第27回 システム要件定義フェーズの秘訣は何か（前編）」では、会計システム刷新のシステム要件定義フェーズについて、システム環境の構築、実機検証による標準機能検証、標準機能とのギャップ解消のための業務改革推進を中心として解説しました。

主なポイント

• システム要件定義フェーズの位置付け
  導入対象となる製品・サービスを前提に、今後目指す新しい業務プロセスを検証しながら、標準機能設定やアドオン要件、インターフェース要件を具体化し、今後のプロジェクトのQCD計画を詳細化する重要なフェーズ
   
• システム環境構築
  ERP・会計パッケージ環境、アドオン環境、インターフェース環境について、開発環境・テスト環境・本番環境の観点で準備
   
• 標準機能検証
  デモ・CRP・POC等と呼ばれる実機検証で、実際のシステムをつかって業務を行い、標準機能とのギャップを明確化
  ギャップについては、ギャップ対応策（設定変更・代替業務フロー・アドオン案）を固める
   
• 業務改革の徹底
  ギャップは業務改革でできるだけ標準機能での実現を図る
  妥協しない要件検討と業務改革検討により、「導入できたが業務で使えない」を防ぐ

システム要件定義フェーズでは、導入対象となる製品・サービスを前提に、今後目指す新しい業務プロセスが実現できるかを、標準機能を基に検証しながら、アドオン要件、インターフェース要件として具体化し、今後のプロジェクトのQCD計画を詳細化します。

そこで「第28回 システム要件定義フェーズの秘訣は何か（後編）」では、標準機能で実現できない機能を実装するためのアドオン機能要件定義、関連システムとのインターフェースを具体化するインターフェース要件定義、今後のプロジェクトのQCD計画を見直すプロジェクト計画更新を中心に解説しました。

主なポイント

• アドオン機能要件定義
  標準機能でカバーできない機能要求を精査し、安直なアドオン開発を抑制
  保守やバージョンアップの足かせを避けるため、ルール変更・業務プロセス変更も含め「聖域なき改革」を検討
   
• インターフェース要件定義
  ETLツール等を前提に、連携元・連携先、データ形式・タイミングを具体化
  マスタ統合、データ発生源の明確化（Master of Record）、コード変換（マッピング）の厳密化、エラーハンドリングの設計、既存システムの制約の早期特定を行い、連携リスクを低減
   
• プロジェクト計画更新
  導入費用（ライセンス、システム開発費用、保守費用等）とアドオン開発・インターフェース開発の見積もりを踏まえ、詳細コスト・投資計画を作成
  ステアリングコミッティ等の承認手続きに沿ってプロジェクトのQCD計画を最新化

精緻なRFPを作って製品と導入ベンダーを選定したにも関わらず、システム要件定義フェーズにおいて、実際には自社に適合しなかったり、結果としてアドオン開発が多くなってしまったり、という話もよく耳にします。このようなリスクを減らすために、企業が取り得る手段にはどのようなものがあるのでしょうか。　

そこで「第29回 Fit to Standardで要件を決める秘訣は何か」では、全体構想策定段階から製品候補を調査し、システム要件定義の前に標準機能とGAPになりそうな業務について、Fit to Standardで導入できるか否かを検証する方法を解説しました。

主なポイント

• RFPの問題
  RFPは提案品質の均一化や客観的評価に有効
  しかし、RFPは作成工数がかかり、選定後にシステム要件定義で想定外のギャップが多発する可能性あり
   
• Fit to Standardの早期検証の重要性
  システム要件定義で行う実機検証（POC、CRP）を前倒しし、標準プロセスで業務が遂行できるかを、構想段階や業務要件定義段階で早期に判断
  ギャップを早めに掴んで、業務改革で業務を変更
   
• 製品候補、ベンダー候補の早期把握
  製品候補とベンダー候補については、全体構想策定段階から選定開始
  RFIで候補ERPを2社～3社に絞り込み
   
• 業務要件定義でのFit to Standard早期検証
  業務要件定義段階ではFit to Standard早期検証で製品適合性と導入ベンダーの実力値（製品知識、Q&A対応等）を把握したうえで決定
  RFPは、従来の「製品・ベンダー選定のためのRFP」から、「導入計画・見積もりの依頼としてのRFP」へ位置付けを変え、システム要件定義で見積もりがブレるリスクを低減

会計システム刷新のシステム開発フェーズ（設計・開発・テスト）は、導入対象となる製品・サービスを前提に、システム要件定義フェーズで決定した機能要件や非機能要件をシステムに実装し、各種テストを実施することによってそれを検証する重要なフェーズです。

システム開発フェーズは、一般的にシステム部門とERPや会計システムの導入ベンダーが中心となって進めますが、ユーザー部門である経理財務部門もその内容を理解しておくことが、プロジェクトのスムーズな推進において重要です。なぜなら、システム開発フェーズの品質が、ユーザー部門が行う業務運用テスト（UAT）や、本番への移行に大きな影響を与えるからです。

そこで「第30回 システム開発フェーズ（設計・開発・テスト）の秘訣は何か」では、導入対象となる製品・サービスに対して機能要件を実装し、各種テストで品質を検証する進め方を解説しました。

主なポイント

• システム開発フェーズの位置付け
  システム要件定義できまった要件をシステムとして実装するとともに、システムの品質を確保するための各種テストを行い、それらを検証する重要なフェーズ
   
• 標準機能設計
  システム要件定義で決定した機能要件を実現するために、標準機能設計（マスタ設定・パラメーター設定等）を実施
   
• アドオン設計・インターフェース設計
  IPO（インプット、プロセス、アウトプット）について、基本設計→詳細設計（画面設計書・処理設計書・帳票設計書・DB設計書・インターフェース設計書）へと落し込み
   
• 開発・テスト
  標準機能設計・アドオン設計・インターフェース設計に基づきシステムに実装
  単体テスト・結合テスト・システムテストで品質を確保
  システムテストでは非機能要件（性能・負荷・セキュリティ・可用性）も検証

会計システム刷新の業務運用整備フェーズは、導入対象となる製品・サービスを前提に、業務要件定義フェーズで検討した業務改革施策を具体化したり、新システム移行後の業務運用を設計したり、ユーザー教育や業務運用テストなどを実施したりする重要なフェーズです。

業務運用整備フェーズは、ユーザー部門である経理財務部門が中心となって行います。並行してシステム要件定義フェーズが開始されるため、そちらに注力してしまい、業務運用整備が後回しになることも少なくありません。その結果、新システムの導入直前で準備不足が露呈し、導入が遅れることもあります。
業務運用整備フェーズは、主管部門の経理財務部門が責任（自覚）をもち推進することが不可欠です。

そこで「第31回 業務運用整備フェーズの秘訣は何か（前編）」では、業務運用整備フェーズとして、新システム導入に向けての業務改革施策（ルール・プロセス・体制等）を具体化する業務改革推進、新システムを前提とした業務マニュアル・手順書等を具体化する業務運用設計、新システムを前提としマスタ定義を中心に解説しました。

主なポイント

• 業務改革推進
  業務要件定義フェーズの施策を、実行施策として具体化
  実行のための目標設定や実行計画を策定
  経営層や他部門・取引先との調整を早めに推進
   
• Fit to Standard
  標準機能で実現できないGAPは業務改革で業務を変更
  関連部門ユーザーの抵抗に対して「なぜ必要か／不都合は何か」の理をもって説明
   
• 業務運用設計
  As-IsとTo-Be対比で変革点を明確化し、End-to-Endで業務を体系化・見える化（文書化）
  徹底して業務の属人化やブラックボックス化を防ぐ
   
• マスタ定義
  勘定科目マスタ・組織マスタ・取引先マスタを、ERPや会計パッケージの仕様（階層構造、キー項目、コード体系等）を踏まえて定義
  移行計画に沿ってマスタ設定タイミングを管理

業務運用整備フェーズには、業務改革推進、業務運用設計、マスタ定義を行った後、新システムや新業務を行うためのユーザー教育、新システムを実際に使って新しい業務を検証する業務運用テスト（UAT）があります。

そこで「第32回 業務運用整備フェーズの秘訣は何か（後編）」では、ERPや会計パッケージのユーザー教育と業務運用テスト（UAT）を経理財務部門主導で進め、安定稼働を実現する要点を解説しました。

主なポイント

• ユーザー教育
  キーユーザー、一般ユーザー、システム運用者に分け、システム操作・新業務手順・ハンズオン・システム設定を体系的に習得
   
• ユーザー教育のポイント
  ユーザーのスキルやサブシステム特性に応じた教育プログラム設計、余裕をもった実施タイミング、Q&A対応の専任窓口・ヘルプデスクなどユーザーサポート体制が鍵
   
• 業務運用テスト（UAT）
  業務シナリオに基づき、機能・画面、データ整合性、エラー・例外処理を検証し、標準機能に加えてアドオン機能まで業務運用に耐えるか最終確認
   
• 業務運用テスト（UAT）のポイント
  適切なテスト参加者（経理財務部門＋一般ユーザー＋関連部門）を選び、上流システムからのインターフェースデータを含めて一気通貫で検証
  各種シナリオを準備し、イレギュラー対応まで潰し込み

会計システム刷新における移行・展開フェーズは、既存システムから新システムへシステムを切り替え、新業務での運用を開始する最終段階のフェーズです。

システムテストや業務運用テストで検証された新システムを本番環境に移し、実際にユーザーが利用を開始する重要なフェーズです。特に、会計システムは関連システムが多いため、テスト環境ではテストしきれないケースもあります。主管部門である経理財務部門は、移行・展開を情報システム部門に任せきりにせず、自らイニシアティブをもって推進していくことが重要です。

そこで「第33回 移行・展開フェーズの秘訣は何か」では、移行計画策定、移行手順書作成、移行ツール開発、移行リハーサル、本番移行、展開の流れに沿って解説しました。

主なポイント

• 移行・展開フェーズの位置付け
  新システムの導入企業・拠点において、旧システムから新システムへシステムを切り替え、新業務での運用を開始する最終段階のフェーズ
   
• 移行計画策定
  元帳残高データ、仕訳データ、残高明細データ、マスタデータなどの移行対象を定義し、既存システムと新システムの利用範囲や利用時期も踏まえて移行計画を策定
   
• 移行手順書作成と
  具体的な移行の作業手順、役割分担、チェックポイント、ロールバック手順を移行手順書として明確化
   
• 移行ツール開発
  移行のためのデータ抽出・変換・登録・検証を効率的かつ正確に行うための移行ツールを準備
   
• 移行リハーサルと本番移行
  移行リハーサルで、データ整合性、作業時間、関係者の習熟、監視体制を確認
  移行リハーサルは、経理財務部門も実務観点で参画することで、移行リスクを低減
  移行手順書に基づき移行を実施し、移行後も監視体制を保持
   
• 展開
  会計システムをグループ会社に導入する場合には、各社に対してどのように展開して行くかを展開計画として策定
  展開計画に応じて順次会計システムを導入

会計システム刷新においても、「システム導入プロジェクト」ですから、プロジェクトマネジメントが不可欠です。一般にシステム導入の失敗は、このプロジェクトマネジメントが十分機能していなかったことに起因するケースも少なくありません。

以前は、こうしたプロジェクトマネジメントは情報システム部門やITベンダーが主に行うことが一般的でしたが、クラウドサービスの導入などではユーザー部門が主体となるケースも増えてきました。
会計システム刷新の主幹部門である経理財務部門は、プロジェクトマネジメントの基本を理解し、実践していくことが重要です。

そこで「第34回 会計システム刷新でプロジェクトマネジメントって何をするの？」では、会計システム刷新におけるプロジェクトマネジメントの必要性と実践ポイントを解説しました。

主なポイント

• プロジェクトマネジメントの必要性
  システムプロジェクトでの納期遅延や予算超過の原因は、現行業務・システムの複雑さ、計画時の考慮不足、仕様変更の多発などが挙げられ、プロジェクトマネジメントの成否が鍵
   
• プロジェクトマネジメントの標準的方法論
  プロジェクトマネジメントの標準的方法論はPMBOK（Project Management Body of Knowledge）が有名
  PMBOK（第6版）では、立ち上げ、計画、実行、監視・コントロール、終結という5つのプロセスと、統合管理、スコープ管理、スケジュール管理、コスト管理、品質管理、資源管理、コミュニケーション管理、リスク管理、調達管理、ステークホルダー管理の10個の知識エリアでプロジェクトマネジメントを定義
   
• PMOによるプロジェクト運営
  多くの調整課題を多チーム間で迅速かつ適切に対策化するため、プロジェクトマネジメントを組織としてPMO（Project Management Office）を編成
  クラウドサービスやパッケージを組み合わせるプロジェクトでは、ベンダー間・部門間の隙間を埋めるPMOが、進捗管理、課題管理、品質管理を行い、コンフリクトを解消

今回は会計システム刷新シリーズ総集編（その5）として、第27回～第34回を振り返り、会計システムの導入方法論として、システムを動かすための要件に落とし込むシステム要件定義と開発・テスト、新システム稼働後の業務を具体化する業務運用整備、新システムを実際に稼働させる移行・展開、プロジェクトマネジメントのポイントを中心にご紹介しました。総集編としては今回が最終回になります。

今後の会計システム刷新は、ERPや会計パッケージに限らず様々なクラウドサービスやAIサービスを活用して「真に経営に資する情報システム」として実現する必要があります。個別のERPや会計パッケージ、クラウドサービスの活用のポイントについて、レイヤーズ・コンサルティングでは多数のご支援実績をもとに、貴社の課題感に合った内容をご紹介することが可能です。是非お気軽にお問い合わせください。