FutureStage導入の進め方/やり方/流れや方法/手法/工程/手順

FutureStageの導入は、構想・計画策定から始まり、本番稼働と移行・定着化で終わる5つのフェーズを順に進めます。途中では、要件定義で自社の業務要件とFutureStageの標準機能を照らし合わせ、設計・開発で設定とカスタマイズを整えます。テストは、単体から受入テスト(UAT)まで順に進みます。

  • 要件定義とFit/Gap分析
  • 設計・開発・パラメータ設定
  • テストと受入確認

導入期間は、対象モジュール、カスタマイズの範囲、データ移行の有無で変わり、目安は最短4〜6ヶ月から12〜18ヶ月です。

▼全体ガイドの記事
・FutureStage導入の完全ガイド

FutureStage導入の全体像と特徴

FutureStageは、国内の中堅・中小企業向けに設計されたERPパッケージです。

FutureStageは、財務会計、販売、購買、在庫、製造、物流の各モジュールを統合して提供しています。

OBCが培った奉行シリーズの業務ノウハウを元にしており、製造業や流通業の業務フローに特化した機能も標準で備えています。

国内では製造業を中心に導入が進み、従業員数50〜500名規模の中堅企業での採用事例も豊富です。

また、クラウド型のFutureStage Cloudも提供されており、オンプレミスとクラウドのどちらからでも、自社環境に合う形態を選べます。

主要モジュールと連携の強み

FutureStageの強みは、モジュール同士の連携と、奉行シリーズとの親和性にあります。

  • 奉行シリーズ:勘定奉行・給与奉行・販売奉行などと連携できます。
  • 財務:多通貨、連結決算補助、予算管理に対応しています。
  • 販売・購買:受発注、請求書発行、仕入先管理をまとめて扱います。
  • 製造:生産計画(MRP)、工程管理、原価計算を一体で扱えます。

すでに奉行製品を使っている企業は、既存のデータを活かして基幹系システムを統合・拡張できます。

導入期間の目安

導入期間は、企業規模とモジュール数、カスタマイズの範囲によって大きく変わります。

  • 中小企業:少数モジュールでカスタマイズが限られる場合、最短4〜6ヶ月です。
  • 中堅企業:製造管理を含む複数モジュールを展開し、既存システムからのデータ移行も必要な場合、12〜18ヶ月です。
  • クラウド型:インフラ整備の工数が減るため、オンプレミスより2〜3ヶ月程度短縮できるケースが多いです。

ポイント

自社に合うかは、奉行製品を利用中かどうか、必要なモジュール数、カスタマイズの範囲、データ移行の有無を並べて考えると判断しやすくなります。

フェーズ1:構想・計画策定

FutureStage導入プロジェクトの4層体制を、プロジェクトオーナーからIT担当者まで積み重ねて示す図。
各層の担当を分けると、計画から実務までの役割を見渡せます。

構想・計画フェーズでは、プロジェクトの成否を左右する基本的な計画を立てます。導入の目的を明確にしたうえで、スコープ(導入範囲)、体制、スケジュールを決めていきます。

経営層の支持を得て、全社的なDX戦略のなかでFutureStageが担う役割を決めておくと、この後の判断の拠り所になります。

現状業務(As-Is)の調査と課題整理

現状業務の洗い出しでは、部門ごとのシステム利用状況と業務の流れを確認します。

  • 対象部門:財務、販売、購買、在庫、製造、物流を調べます。
  • 手作業:ExcelやAccessに残る作業を洗い出します。
  • データ連携:部門間でデータを受け渡す手順を書き出します。

現場担当者へのヒアリングと業務フロー図の作成を組み合わせると、実態を把握できます。その結果、導入で解消すべき課題も明確になります。

導入スコープとモジュール選定

モジュールの導入範囲と展開の順序を決めておくと、無理のない計画につながります。

  • ビッグバン導入:すべてのモジュールを一度に導入します。
  • 段階導入:重要度の高いモジュールから展開します。

中堅企業では、財務・販売・購買から始め、製造・在庫を後から追加する例が多く見られます。

範囲が広がるほどリスクも高まるので、投資対効果と実現可能性を踏まえて範囲を決めます。

プロジェクト体制の構築

社内の体制は、意思決定から業務・ITの実務までを4つの層で担う構造が基本です。

  • プロジェクトオーナー:経営層が務めます。
  • プロジェクトマネージャー:情報システム部門長などが担います。
  • 業務キーユーザー:各業務モジュールの担当者。
  • IT担当者:システム面の実務を受け持ちます。

業務キーユーザーは、要件定義、受入テスト、社内教育を担います。そのため、各部門の業務に詳しい人を専任で配置することが推奨されます。ただし、準専任で配置する場合は通常業務と兼任になるため、プロジェクト期間中の人員を事前に確保しておきます。

ポイント

導入の範囲は、現状業務を洗い出した結果を見て決めます。一度に導入するか段階的に進めるかは、投資対効果と実現可能性で判断し、社内の体制も役割を分けて決めておきます。

フェーズ2:要件定義とFit/Gap分析

Gapへの対応方法としてカスタマイズ、業務変更、外部連携を並べた図。
標準機能に合わない業務は、開発・業務変更・外部補完から扱いを決めます。

要件定義では、自社の業務要件とFutureStageの標準機能を照らし合わせます。そのうえで、OBC認定パートナーのデモを通じ、各業務プロセスが標準機能(Fit)で対応できるかを確かめます。

追加開発が必要な範囲(Gap)が増えるほど、コストと開発期間も膨らみます。そこで、標準機能に業務を合わせるBPRの視点も持ちながら、要件を精査します。各業務プロセスがFitかカスタマイズ(Gap)かは、一覧にまとめます。

Fit/Gap分析の進め方

分析は、デモ環境で各業務プロセスを確かめながら、業務キーユーザーが参加するワークショップ形式で進めるのが標準的です。Gapと判定した項目には、次の3つの対応方法があります。

  • カスタマイズ:開発でGapに対応します。
  • 業務変更:業務プロセスをシステムに合わせ、Fitへ移行します。
  • 外部連携:外部ツールやExcelで補います。

現在の業務がシステムでどう変わるかを、具体的に把握しておきます。特に製造業は、生産計画(MRP)や工程管理でGapが起きやすいため、製造モジュールの分析に時間をかけることが推奨されます。

データ移行計画の策定

データの移行対象と品質確認の手順は、要件定義の段階で決めておきます。

  • マスタ:取引先、品目、勘定科目などを特定します。
  • 取引データ:未決済の受発注、在庫残高などが対象です。
  • 移行方法:品質確認の手順を含めて定めます。

移行は、手作業や独自ツールで行うケースが多くあります。なお、データクレンジング(整合性の修正・重複排除)には想定外の工数がかかるため、余裕を持たせたスケジュールを組むことが大切です。

ポイント

業務を標準機能に合わせられるかを、Gapが費用と期間を膨らませる点とあわせて検討します。移行するデータの範囲と品質確認の手順も、同じ段階で決めておきます。

フェーズ3:設計・開発・パラメータ設定

要件定義で作った資料をもとに、設定、カスタマイズ、帳票、連携機能を整えていきます。

基本的な業務フローは、パッケージのパラメータ設定でシステムに反映します。一方で、カスタマイズは追加開発で対応します。カスタマイズの範囲を抑えておくと、将来のバージョンアップに伴う対応コストを下げられます。

パラメータ設定の重要性

要件定義で確定した業務設計書をもとに、多数のパラメータを設定します。

  • 共通設定:会社コード、事業所、会計期間を登録します。
  • 業務設定:承認ワークフロー、帳票形式、税率区分を決めます。
  • 製造設定:製品コード、BOM(部品表)、工程コード、原価計算方式を定めます。

製造業では、製品コード体系やBOMなどの設定が複雑になりがちです。さらに、設定ミスは後工程のテストで大量の手戻りを生むおそれがあります。そのため、設定担当者と業務キーユーザーが密に連携して作業します。

インターフェース開発と既存システム連携

既存システムとのデータ連携が必要な場合は、インターフェース(IF)開発が発生します。

  • 連携先:販売、生産管理、WMS(倉庫管理)、EDIの各システムが対象です。
  • ファイル連携:CSV/Excel形式のデータインポート機能を標準搭載します。
  • リアルタイム連携:APIやIFバッチの開発が必要です。

IF開発は、工数と費用を見通しにくい領域です。そのため、要件定義の段階でIFの一覧を作り、開発規模を見積もります。

フェーズ4:テストと受入確認

単体テスト、結合テスト、総合テスト、受入テスト(UAT)の順に進む図。
確認範囲はモジュール単体から業務全体へと広がります。

テストは、単体、結合、総合、受入テスト(UAT)の順に進みます。

  1. 単体テスト:各モジュールが設計どおりに動くか確認します。
  2. 結合テスト:複数モジュール間の連携を検証します。
  3. 総合テスト:月次・年次などの業務サイクルを通して試します。
  4. 受入テスト(UAT):実際の担当者が本番に近い環境で操作します。

特に結合テストでは、受注入力から在庫引当、売上計上、請求書発行までの一連の流れを検証します。

受入テスト(UAT)の実施ポイント

UATは、業務担当者(エンドユーザー)が中心となって、業務要件を満たしているかを最終確認します。

  • シナリオ確認:実際の業務データを使い、操作と業務の流れを確かめます。
  • 実施時期:修正時間を確保するため、本番稼働の2〜3ヶ月前に始めます。
  • 進捗管理:JiraやRedmineなどのツールを活用するプロジェクトが増えています。
  • 完了判定:UAT完了後、経営層と関係部門長がGo/No-Goを決めます。

ポイント

テストは単体から受入まで段階を追って進め、稼働の判断は受入テストの結果を見て行えるよう、修正に使える時間を本番稼働の前に残しておきます。時間が足りないまま判定すると、稼働の可否を急いで決めることになります。

フェーズ5:本番稼働と移行・定着化

本番稼働(Go-Live)は、プロジェクトの節目であると同時に、リスクが最も集中する時期です。そのため、稼働直前の本番データ移行、ユーザー研修、サポート体制の整備を並行して進めます。

稼働初日から業務を止めないよう、万全の準備が求められます。稼働後2〜4週間は集中サポート期間とし、ベンダーや支援会社のエンジニアが常駐するか、即時対応できる体制をとるのが一般的です。

ユーザートレーニングと操作研修

操作研修は、利用者ごとに必要な内容が異なるため、役割に応じて組み立てます。

  • 対象別研修:管理者、業務担当、経営者向け閲覧のみなど、対象ごとに分けます。
  • トレーナー育成:業務キーユーザーが各部門へ教育を展開します。
  • 操作資料:業務シナリオに沿った手順書を整備します。

トレーナー育成型は、コスト削減と定着化の両面で有効です。また、問い合わせ窓口として、社内ヘルプデスクの設置も検討します。

初月の月次決算、棚卸し、請求書発行は初めての作業になります。そのため、事前に模擬演習を行っておくと効果的です。

稼働後の運用・改善サイクル

稼働後は、定期的に運用を振り返り、FutureStageを継続して改善していきます。

  • 活用状況:システム活用度と未活用機能を確認します。
  • 業務効率:効果を定量的に測定します。
  • レビュー時期:稼働後3ヶ月、6ヶ月、12ヶ月に実施します。

導入効果を高めるため、OBCが定期提供するバージョンアップの新機能を評価し、適用の計画を立てます。

中長期的には、蓄積されたデータを経営ダッシュボードやBIツールと連携させ、データに基づく経営判断につなげることを目指します。

FutureStage導入における失敗パターンと対策

失敗につながりやすい要因は、プロジェクトの早い段階で把握し、対策を講じておきます。

  • 要件定義の不徹底
  • スコープ管理の失敗:スコープクリープを招きます。
  • 現場の巻き込み不足
  • データ移行の過小評価

スコープクリープの防止策

スコープクリープを防ぐには、計画外の要望を適切に扱う方法を、あらかじめ決めておく必要があります。

  • 追加要望:要件定義後に「やっぱりこの機能も欲しい」という要望が出ることがあります。
  • 発生する影響:計画外の機能追加や変更が重なると、予算と期間が大幅に超過します。
  • 変更管理:要件定義書にない機能は本番稼働後の次期開発(第2期)以降に回すルールを、開始時に明文化します。
  • 追加要件の判断:ステアリングコミッティ(経営層の意思決定会議)で決めるプロセスが有効です。

現場担当者の巻き込みと変化マネジメント

現場担当者の「使いたくない」という抵抗感は、ERP導入で最も多く挙がる失敗要因です。また、旧システムから移行する場合は、操作方法や業務フローを学び直す負担も生じます。

  • 構想段階から参加:現場を巻き込み、新システムで業務がどう良くなるかを伝えます。
  • 伝達経路を組み合わせる:経営層からの発信と、現場キーユーザーから同僚への横方向のつながりで、定着化を促します。

現場を巻き込み、変化を支えるこうした活動を、チェンジマネジメントと呼びます。

ポイント

要件定義書にない要望の扱いを開始時に決めておくことと、現場を構想段階から巻き込むことの二つが、失敗を防ぐ判断の目安になります。

まとめ

導入は、構想・計画から始まり、本番稼働・定着化で終わる5段階で進みます。途中の要件定義からテスト・受入までは、各フェーズの成果を確認しながら次へ進むことが、成功の最大の鍵です。

  • 要件定義・Fit/Gap
  • 設計・開発・設定
  • テスト・受入

FutureStageは、中堅・中小の製造業・流通業の業務に合うよう作られたERPです。

導入プロジェクトの複雑さはどの企業にも共通します。そのため、経験豊富な支援パートナーと進めることで、リスクを大幅に低減できます。

パートナーの選び方や費用相場は、下の関連記事で取り上げています。

▼関連記事一覧
・FutureStage導入でおすすめの開発会社/ベンダー6選と選び方
・FutureStage導入の見積相場や費用/コスト/値段について
・FutureStage導入の発注/外注/依頼/委託方法について
・FutureStage導入の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。