生産管理システムやERPを、スクラッチ開発ではなくパッケージで導入する。そこまでは社内で決まったものの、次に出てくるのが「導入支援サービスは具体的に何をしてくれるのか」という疑問ではないでしょうか。パッケージソフト導入支援は、ソフトを売る役務ではなく、自社の業務で使える状態になるまで伴走する役務です。本記事ではその中身を、Fit&Gap分析の4ステップとGap対応の3つの選択肢を軸に整理し、タイ拠点固有の論点まで順に扱います。
パッケージソフト導入支援とは何か|「売る」のではなく「使えるようにする」役務

最初に、導入支援という言葉が指す範囲を揃えます。ここが社内でずれたまま見積もりを取ると、提案書に書かれた作業項目の意味が読み解けず、金額の大小だけで比較することになります。
導入支援の守備範囲は要件定義から稼働後フォローまで
パッケージソフトの導入支援とは、製品を選定した後に、要件定義、Fit&Gap分析、設定作業、データ移行の設計、現場教育、稼働後のフォローまでを一連の役務として引き受ける仕事を指します。ライセンスを販売して納品書を出したら終わり、ではありません。
この違いは、契約書の作業範囲に明確に表れます。ライセンス販売だけの契約であれば、納品されるのはソフトウェアの使用権と初期セットアップまでです。一方で導入支援を含む契約では、自社の業務フローを聞き取り、パッケージの標準機能で回せる部分と回せない部分を切り分け、回せない部分をどう扱うかまでを決める作業が入ります。
言い方を変えると、導入支援は「ソフトを渡す仕事」ではなく「業務をソフトに乗せる仕事」です。パッケージは汎用品として作られている以上、そのままでは自社の業務の形と完全には一致しません。この不一致をどう埋めるかを設計するのが、導入支援の中心的な役割になります。
スクラッチ開発かパッケージかの分岐は、すでに越えている
導入支援を検索している時点で、多くの読者は「ゼロから開発するか、既存のパッケージを買うか」という分岐をすでに越えています。開発費用と期間を考えて、パッケージを選ぶ方向に傾いた。あるいはもう製品の候補が2〜3社に絞られている。そういう段階です。
この段階で必要な情報は、製品の機能比較表でも費用相場の一覧でもありません。「選んだパッケージを、自社の業務でどう使える状態にするのか」という手順の話です。ところが検索して出てくる情報の多くは製品紹介か機能比較で、導入支援の作業そのものを説明したものは多くありません。本記事はそこを埋めることを目的にしています。
「システム開発の委託」と「パッケージ導入支援」は何が違うか
もうひとつ整理しておきたいのが、システム開発を外部に委託する場合との違いです。両者は似た体制で進みますが、決めるべきことの順番が逆になります。
スクラッチ開発の委託では、まず自社の業務を要件として書き出し、それを満たすシステムを設計して作ります。要件が先で、システムが後です。一方でパッケージ導入では、すでに完成しているシステムが先にあり、そこに自社の業務を照らし合わせます。システムが先で、業務の当てはめが後になります。
この順番の違いが、そのまま作業内容の違いになります。スクラッチ開発の中心が設計と実装であるのに対し、パッケージ導入の中心は「照合」と「差の扱い方の決定」です。そして、この照合作業に付いている名前がFit&Gap分析です。
| 観点 | スクラッチ開発の委託 | パッケージ導入支援 |
|---|---|---|
| 起点になるもの | 自社の業務要件 | 完成しているパッケージの標準機能 |
| 中心となる作業 | 要件定義、設計、実装、テスト | Fit&Gap分析、設定、差分への対応方針決定 |
| 業務側の前提 | 現行業務を基本的に維持できる | 標準機能に合わせて業務を変える判断が発生する |
| 費用が膨らむ経路 | 要件の追加と仕様変更 | Gapに対するカスタマイズの積み上げ |
| 稼働後の負担 | 保守は原則として自社専用の作りに対して発生 | バージョンアップのたびに追加開発分の検証が発生 |
この表の最下段の2行が、本記事で最も強調したい部分です。パッケージを選んだからといって費用が読みやすくなるわけではなく、費用が膨らむ経路が別の場所に移るだけ、というのが実務上の感覚です。
なぜ導入支援が必要なのか|つまずきの原因は機能不足とは限らない
パッケージ導入プロジェクトが計画どおりに進まない例は珍しくありません。稼働が遅れる、予算を超過する、稼働はしたが現場が使わない。こうした結果になったとき、社内では「選んだ製品が悪かった」「機能が足りなかった」と総括されがちです。
ここからは弊社が支援の現場で見てきた実務所見として述べます。プロジェクトを振り返ったとき、原因が製品の機能不足そのものだったという例は、思ったほど多くありません。むしろよく見かけるのは、業務とシステムの照合を十分に行わないまま導入を進め、稼働直前や稼働後になって差が次々に発覚し、そのたびに追加の開発を発注する、という流れです。
失敗の典型は「Fit&Gap分析を経ずに導入する」こと
Fit&Gap分析は、日本語ではフィット&ギャップ分析とも呼ばれ、新しいシステムを導入する際に、企業の現行業務や要求事項と導入システムの機能を比較し、適合点であるFitと乖離点であるGapを洗い出す分析手法とされています。以下、本記事では表記をFit&Gap分析に統一します。名前は難しく見えますが、やっていることは業務とシステムの突き合わせです。
この工程を省いた場合に何が起きるかは、順を追うと見えてきます。まず、契約時点では標準機能で回る前提の見積もりが出ます。次に、設定作業を進める段階で「この帳票の様式が違う」「この承認ルートが再現できない」という差が個別に見つかります。その時点ではすでに稼働予定日が決まっているため、業務を変える議論をする時間がなく、追加開発で対応する判断になります。そしてこの追加開発は当初の見積もりに入っていないため、すべて追加費用になります。
重要なのは、この流れのどこにも「悪意」も「手抜き」もない点です。導入する側もされる側も、それぞれの時点では合理的に動いています。にもかかわらず費用が膨らむのは、差を洗い出す工程が前工程に置かれていなかったという構造の問題です。
カスタマイズ費用は、発生した年だけの費用ではない
もうひとつ押さえておくべきなのが、カスタマイズ費用の性質です。追加開発の費用は、その年に一度だけ発生する支出のように見えますが、実際にはそうではありません。
パッケージには定期的にバージョンアップが提供されます。標準機能だけで運用していれば、バージョンアップは基本的にベンダー側の作業で完結します。ところが独自の追加開発を抱えていると、バージョンアップのたびに、その追加開発部分が新しいバージョンでも動くかを検証し、動かなければ手直しする作業が発生します。
つまり、カスタマイズは初回の開発費用に加えて、以後のバージョンアップごとの検証費用と改修費用を将来にわたって呼び込みます。導入時に「この程度の金額なら」と判断した追加開発が、5年後の保守費用の水準を決めているという構造です。
「カスタマイズを前提としない」設計のパッケージもある
一方で、パッケージ側にもこの問題への対応があります。中堅・中小企業向けの国産ERPパッケージには、特定の業態に特化し、その業態で必要になる各業務をあらかじめ基本パッケージに組み込むことで、特別なカスタマイズを要しない設計にしているものもあるとされています。
自社の業態と製品の想定業態が合っていれば、Gapの数はそもそも少なくなります。逆に、汎用性の高い製品を選んで自社の業態に寄せていく場合は、Gapの数が増えるかわりに適用範囲が広くなります。どちらが良いという話ではなく、Gapの量と柔軟性のどちらを取るかという選択です。
この選択を意識せずに製品を選び、後からGapの多さに驚くというのが、最も避けたい進め方です。だからこそ、製品を絞り込む段階でFit&Gap分析の考え方を知っておく必要があります。
Fit&Gap分析の4ステップ|導入支援の中身はここに集約される

ここからが本記事の核です。導入支援サービスが具体的に何をしてくれるのかという問いに対する最も実質的な答えが、このFit&Gap分析の4ステップです。Fit&Gap分析は、現状把握、システム機能調査、適合性評価、対応方法決定の4つのステップで進めるとされています。順に見ていきます。
ステップ1|現状把握。全部署の業務フローを洗い出す
最初のステップは現状把握です。全部署の業務フローを洗い出し、業務フローチャートと要件リストを作成します。
ここで鍵になるのは「全部署」という点です。生産管理システムであれば製造部門、購買部門、生産管理部門が中心になりますが、実際には品質保証、出荷、経理も業務フローの一部を担っています。中心部門だけで要件を作ると、周辺部門の業務がシステムの外に取り残され、稼働後にExcelでの補助作業が残ります。
もうひとつ、現状把握で頻繁に起きるのが「文書化されている業務フローと、実際に現場が動いている手順が違う」という状況です。フロー図はあるが数年前のもので、その後の改善が反映されていない。あるいは担当者ごとに手順が微妙に違う。この状態のまま要件リストを作ると、実在しない業務に合わせてシステムを設計することになります。
導入支援会社に期待すべきなのは、既存の資料を受け取って要件リストに転記する作業ではなく、現場に入って実際の手順を確認し、資料との差を指摘してくれることです。この工程に人と時間を割いているかどうかは、提案書の作業内訳を見れば判断できます。
ステップ2|システム機能調査。デモで操作性と設定可能性を確認する
2つ目のステップは、導入するシステム側の機能を調べることです。ここでは製品情報を読むだけでなく、デモや説明会を通じて実際の操作性や設定の可能性まで確認するとされています。
カタログや機能一覧には「対応」と書かれていても、実際には運用に耐えない、という場面は少なくありません。例えばロット管理に対応と書かれていても、入力画面でロット番号を都度手入力する仕様であれば、1日に数百件の実績を登録する現場では使われません。多言語対応と書かれていても、画面は翻訳されるがマスタに登録する品名は1言語しか持てない、ということもあります。
したがってこのステップで確認すべきは、機能の有無ではなく次の3点です。第一に、その機能を現場の担当者が実際に操作したときの手数。第二に、設定画面から自社の運用に合わせられる範囲。第三に、設定では届かず開発が必要になる境界線がどこにあるかです。
3点目が特に重要です。設定で対応できることと開発が必要なことの境界線が見えていないと、次のステップで出てくるGapの重さを判断できません。
ステップ3|適合性評価。Fit/Gapと業務影響度を記録する
3つ目が適合性評価です。業務要件とシステム機能を照合し、Fitなのか、Gapなのかを判定します。そしてGapについては、乖離の理由と業務への影響度まで記録するとされています。
ここで記録される内容が、導入支援の成果物として最も価値のある部分です。単に「対応」「非対応」の一覧を作るのではなく、なぜ合わないのか、合わないままだと業務にどういう支障が出るのかを、要件ごとに残します。この記録があるからこそ、次のステップで「業務を変えるか、開発するか」の判断ができます。
実務で使う記録の形は、次のような粒度になります。
| 記録項目 | 内容 | 判断への使われ方 |
|---|---|---|
| 業務要件 | 画面、入力、処理、出力まで具体的に記述する | 曖昧な要件は評価もできない |
| 優先度 | 必須か希望かを区別する | Gap対応の投資判断の前提になる |
| 判定 | Fit、設定で対応可、Gapの3区分 | 設定で届く範囲を明示する |
| 乖離の理由 | 何が、どう足りないのか | 対応方法の選択肢を絞り込む |
| 業務影響度 | 対応しない場合に業務がどうなるか | 業務プロセス変更が可能かを判断する |
成功のポイントとして挙げられているのが、全部署の現場担当者を巻き込むこと、要件に必須と希望の優先順位をつけること、既存システムとの連携でデータ連携の追加開発が必要かを考慮すること、そして要件を画面・入力・処理・出力まで具体的に記述することです。
このうち実務上いちばん効くのが、必須と希望の区別です。区別がないまま一覧を作ると、すべての要件が同じ重さで並び、結果として全部に対応しようとして費用が膨らみます。逆に必須と希望を分けておけば、希望に分類された要件は「標準機能の範囲でできる形に運用を寄せる」判断がしやすくなります。
既存システムとの連携も見落とされやすい項目です。会計システム、勤怠システム、既存の在庫管理といった周辺システムとどのデータをやり取りするのかを、この段階で洗い出しておかないと、連携部分の開発費用がまるごと見積もりの外に出ます。
ステップ4|対応方法決定。3つの選択肢から選ぶ
最後のステップが対応方法の決定です。洗い出したGapのそれぞれについて、業務プロセスを変更するのか、システムをカスタマイズするのか、別のツールを併用するのか、この3つから最適な方法を選定します。
ここで大切なのは、Gapが見つかったこと自体は失敗ではないという認識です。パッケージは汎用品ですから、Gapがゼロになることはまずありません。問題になるのは、Gapが見つからないまま進むこと、そして見つかったGapに対して選択肢を検討せず自動的にカスタマイズを選ぶことです。
この3択の判断軸は本記事の中心テーマですので、章を改めて詳しく扱います。
Gapが見つかったときの3つの選択肢と判断軸
Fit&Gap分析でGapが洗い出されたら、次はその扱い方を決めます。ERPパッケージの導入では、Gapへの対応策としてパッケージのカスタマイズ、不足機能のアドオン開発、業務プロセスをパッケージの標準機能に合わせて変更する、という3つの選択肢が一般的に挙げられます。またFit&Gap分析の対応方法決定のステップでは、業務プロセス変更、システムカスタマイズ、別ツール活用の3択から選定するとされています。
本記事では、実務で判断しやすい形にするため、性質が近いカスタマイズとアドオン開発をひとつにまとめ、そこに別ツール併用を加えた3つの選択肢として整理します。
選択肢1|業務プロセスを標準機能に合わせて変更する
最初の選択肢は、システムではなく業務のほうを変えることです。費用の面では最も軽く、稼働後の保守の面でも最も負担が小さい選択肢になります。
一方で、実行の難易度は3つの中で最も高くなります。現場に手順の変更を受け入れてもらう必要があり、変更の理由を説明し、教育をやり直し、定着するまで見届ける工数がかかるためです。金銭的な費用が小さいかわりに、社内の調整コストがかかると考えるのが実態に近いと思います。
判断の目安として、弊社が実務でよく使う問いは「その手順は、なぜそうなっているのかを説明できるか」です。法令や顧客要求に根拠がある手順は変えられません。しかし「昔からそうしている」「前任者がその形で引き継いだ」という理由しかない手順であれば、標準機能に寄せられる可能性があります。現状把握のステップで手順の理由まで聞き取っておくと、この判断が早くなります。
選択肢2|カスタマイズ・アドオン開発で埋める
2つ目は、パッケージ側に手を入れる選択肢です。既存機能の挙動を変えるカスタマイズと、不足している機能を追加で作るアドオン開発があります。
業務を変えずに済むため現場の抵抗は小さく、短期的には最も摩擦のない選択に見えます。だからこそ、検討を尽くさないまま自動的にこの選択肢に流れやすい、という点に注意が必要です。
前章で触れたとおり、この選択肢の費用は初回の開発費用だけでは終わりません。バージョンアップのたびに追加開発部分の動作検証が発生し、標準機能側の仕様変更によっては作り直しが必要になります。カスタマイズを重ねるほど、稼働後の保守費用は構造的に上がっていきます。稼働後にどのような費用が継続的に発生するかについては業務システムの保守費用は何にいくら払っているのかで内訳を整理していますので、カスタマイズの可否を判断する前に一度目を通しておくことをおすすめします。
導入時の費用全体の考え方についても、ライセンス費用以外に何が乗るのかを把握しておく必要があります。生産管理システムを例に、ライセンス以外に発生する費用の内訳は生産管理システムの費用はライセンス以外に何がかかるのかにまとめています。Gap対応の費用を見積もりに載せる段階で、この枠組みに沿って項目を確認していただくと漏れが減ります。
選択肢3|別ツールを併用して外側で処理する
3つ目が、パッケージ本体には手を入れず、その業務だけを別のツールで処理する選択肢です。帳票作成ツール、BIツール、あるいは既存のExcelでの処理を残す形も含まれます。
この選択肢が有効なのは、Gapが業務の中核ではなく周辺にある場合です。例えば、特定の顧客だけに提出する集計表の様式が標準の帳票機能で作れない、という程度のGapであれば、データを出力して別ツールで整形するほうが安く早く済みます。
注意すべきは、データが二重に存在する状態を作らないことです。パッケージから出力したデータを別ツールで加工するだけであれば問題ありませんが、別ツール側でもデータを入力・更新する形にすると、どちらが正しいのかわからない状態が生まれます。併用する場合は、データを入力する場所を1つに限定するという原則を先に決めてください。
3つの選択肢を比較する
3択の性質を並べると、判断のときに見るべき軸がはっきりします。
| 選択肢 | 初期費用 | 稼働後の負担 | 現場の抵抗 | 向いている場面 |
|---|---|---|---|---|
| 業務プロセスを変更する | 小さい | 小さい | 大きい | 手順の根拠が慣習にとどまるGap |
| カスタマイズ・アドオン開発 | 大きい | 大きい | 小さい | 法令・顧客要求に根拠があり業務の中核にあるGap |
| 別ツールを併用する | 中程度 | 中程度 | 中程度 | 業務の周辺にあり、出力側で吸収できるGap |
この表を使う際の実務的な進め方は、Gapを一覧にしたうえで、必須要件かつ業務の中核にあるものだけをカスタマイズの候補に残し、それ以外は業務変更か別ツール併用で処理できないかを先に検討するというものです。順番が逆になると、検討の余地があったGapまで開発の対象に入ってしまいます。
導入支援会社の力量が最も出るのが、この3択の提示の仕方だと考えています。Gapに対して開発の見積もりだけを出してくる会社と、業務を変えた場合の影響と別ツールで処理した場合の構成まで並べて出してくる会社では、最終的な投資額が変わります。
タイ拠点でのパッケージソフト導入支援に固有の論点

ここからはタイの現場に引き寄せます。日本国内での導入と比べたとき、タイ拠点のパッケージ導入にはいくつか固有の事情があります。
タイのERP導入支援市場は、選択肢の幅が大きい
タイでは中小製造業向けに、複数のグローバルERPパートナーが活動しています。Odooについては現地パートナーがISO 29110認証を取得したうえで導入と現地税制対応を支援しており、SAP Business Oneについても導入支援を行うパートナーが存在します。Microsoft Dynamics 365についてはライセンス保有パートナーが導入を支援しています。これに加えて、日系企業向けのローカルベンダーや日系ITベンダーも活動しています。
本記事の立場として、どの製品やどのパートナーが優れているかという比較はしません。押さえていただきたいのは、同じ「ERP導入支援」という言葉で提示される役務の規模と費用感が、事業者によって大きく異なるという点です。グローバル製品のパートナーとローカルベンダーでは、体制も標準的な作業範囲も違います。
したがって、複数社から見積もりを取る際は、金額の比較の前に「その金額に何の作業が含まれているのか」を揃える必要があります。特に、Fit&Gap分析が作業項目として明示されているか、それとも要件定義の中に暗黙に含まれているかは必ず確認してください。
日本本社の標準システムとタイ拠点の現地要件のGap
ここからは弊社の実務上の見解として述べます。日系工場のタイ拠点では、Fit&Gapの構造が日本国内の導入とは一段違ったものになります。理由は、比較の対象が「パッケージの標準機能と自社の業務」の1組ではなく、「日本本社の標準システム」「タイ拠点の実際の業務」「パッケージの標準機能」の3者になるためです。
本社が全社標準としてあるパッケージを採用している場合、タイ拠点にも同じ製品を展開する方針が出ることがあります。この方針自体は合理的です。ただし、そのまま展開すると、タイ側の現地要件との間にGapが生まれます。典型的なのは税務関連の帳票、現地の言語での画面と帳票、そして商習慣に由来する伝票の流れです。
さらに厄介なのが、このGapの判断権限が本社側にあり、現地に決定権がないケースです。現地でGapが見つかっても、本社の標準を崩す判断は現地ではできず、かといって現地の法令要件は譲れない。この板挟みでプロジェクトが止まる例を実際に見てきました。
対策としては、Fit&Gap分析の適合性評価の段階で、Gapを「現地固有の法令・税制に起因するもの」と「現地の運用慣習に起因するもの」に分けて記録することをおすすめします。前者は本社の標準を崩さずに現地対応として個別に処理すべき対象であり、後者は本社標準に寄せる交渉の余地がある対象です。この2つを混ぜたまま本社に上げると、議論が「現地のわがまま」対「本社の押し付け」という構図になり、判断が長期化します。
現地語サポート体制の有無が定着を左右する
もうひとつ、実務上きわめて大きいのが現地語サポートの問題です。導入支援のうち、Fit&Gap分析や要件定義は日本語と英語で進められることが多い一方、実際にシステムを毎日使うのは現地スタッフです。
教育の場面を考えるとわかりやすいと思います。操作研修が英語のみで行われた場合、内容を理解できるのは一部のスタッフに限られ、残りは隣の人のやり方を見て覚えることになります。この状態で稼働すると、正しい入力手順が伝わらないまま運用が始まり、データの品質が安定しません。
稼働後の問い合わせ対応も同様です。現場が疑問を持ったときに、現地語で質問できる窓口がなければ、質問そのものが起こらなくなります。質問が起きないのは順調だからではなく、あきらめられているからだという可能性を、導入する側は疑うべきです。
したがって、導入支援会社を選ぶ際には、マニュアルと研修が現地語で提供されるか、稼働後の一次窓口に現地語で対応できる担当者がいるかを、契約前に確認してください。これはオプションの快適さではなく、投資が回収できるかどうかを左右する条件だと考えています。
タイのSME向けデジタル化支援制度について
費用面では、タイの中小企業向けにデジタル化を支援する制度が存在するとされています。DEPA、すなわちタイ王国デジタル経済振興庁のd-transformプログラムがそれにあたり、年間売上3億バーツ以下の中小企業を対象に、初年度費用の一部を補助する枠組みがあるとされています。この記述は特定ERP製品を扱う事業者のブログ記事に基づくもので、補助率や上限額を含む制度の詳細については、必ず公式の制度概要と最新の募集要項をご自身で確認してください。
日本国内の状況もあわせて紹介しておきます。日本の中小製造業のうち受注生産で従業員10〜200名規模の企業では、パッケージ型生産管理システムの導入費用は100万円〜500万円程度が目安とされ、段階的な導入であれば100万円台からの着手も可能とされています。また2026年時点で活用できる制度として、デジタル化・AI導入補助金が挙げられています。
なお、この日本国内の費用感とタイでのクラウドERPの費用感は、通貨も対象範囲も異なるため、そのまま比較することはできません。日本本社に対してタイ拠点の予算を説明する際も、日本の相場をそのまま持ち込むのではなく、現地で取得した見積もりの作業内訳をもとに説明していただくのが確実です。
導入支援会社を選ぶときに確認すべきポイント
ここまでの内容を、発注先を選ぶ際の確認項目に落とし込みます。
Fit&Gap分析を作業項目として実施してくれるか
第一に確認すべきなのが、Fit&Gap分析が提案書の作業項目として明示されているかです。工程名として書かれていない場合、その作業に工数が割かれていない可能性があります。
確認の仕方としては、次の3つを質問するのが実務的です。現状把握のために何部署に、何日間ヒアリングを行うのか。適合性評価の成果物として、どのような形式の一覧が納品されるのか。その一覧に、Gapの業務影響度は記録されるのか。この3点に具体的に答えられる会社は、実際にその工程を回している会社です。
なお、Fit&Gap分析の前段として、そもそも要件を整理して発注先を選ぶ段階の進め方については生産管理システムのRFPで見積もりの差が3倍になる理由で扱っています。まだ発注先が固まっていない段階であれば、RFPに何を書くかによって集まる提案の質が変わりますので、そちらを先にご覧いただくのが順序としては自然です。
Gap対応の選択肢を複数提示してくれるか
第二に、Gapが見つかったときに、カスタマイズの見積もりだけを出してくるのか、業務プロセス変更や別ツール併用も含めた選択肢を提示してくれるのかです。
この点は、提案段階では判断しにくい部分でもあります。ひとつの見分け方として、過去の導入案件で「Gapに対して業務側を変えた事例」を具体的に説明できるかを聞いてみてください。開発案件としての実績は語れても、業務を変えて解決した事例を持っていない会社は、実質的にカスタマイズが前提になっている可能性があります。
契約形態と作業範囲が明確か
第三に、契約形態です。導入支援は、成果物を定義しやすい工程と、伴走の性格が強く成果物を定義しにくい工程が混在します。前者は請負、後者は準委任という形が一般的ですが、どの工程がどちらなのかが曖昧なまま契約すると、追加費用の発生条件をめぐって認識の相違が起きます。
契約類型ごとの責任範囲や検収基準の考え方についてはシステム開発の委託契約で押さえるべき請負と準委任の実務で詳しく整理しています。導入支援の契約書を確認する段階では、そちらを手元に置きながら、工程ごとの契約類型と検収の条件を照らし合わせてください。
現地語のサポート体制があるか
第四に、前章で述べた現地語サポートです。マニュアル、研修、稼働後の問い合わせ窓口の3つについて、それぞれ何語で提供されるのかを確認してください。「対応可能」という回答だけでなく、実際に対応する担当者が常駐しているのか、都度手配になるのかまで踏み込むと実態がわかります。
稼働後のフォロー範囲が定義されているか
第五に、稼働後です。導入支援の契約が稼働日で終わるのか、稼働後の一定期間を含むのかで、実際の負担は大きく変わります。
稼働直後は、想定していなかった業務パターンが必ず出てきます。イレギュラーな受注、月末月初の処理、期末の棚卸し。これらは稼働から数週間から数ヶ月経って初めて発生するため、稼働日で支援が終わる契約だと、最も支援が必要な時期に相談先がない状態になります。最低でも、初回の月次処理と初回の棚卸しを通過するまでを支援範囲に含めることをおすすめします。
自社に当てはまるか確認するチェックリスト
導入支援の検討がどの段階にあるかを確認するための項目です。社内会議でそのまま使える粒度にしてあります。
- 導入候補のパッケージについて、標準機能で回せるかどうかを確認したい業務を一覧で挙げられるか
- 現状の業務フローが文書化されており、その文書が現場の実際の手順と一致しているか
- 要件に必須と希望の優先順位が付けられているか
- 会計、勤怠、既存の在庫管理など周辺システムとの連携要件が洗い出されているか
- 提案書にFit&Gap分析が独立した作業項目として記載されているか
- Gapに対して、カスタマイズ以外の対応策も提示されているか
- カスタマイズを実施した場合の、バージョンアップ時の追加負担について説明を受けているか
- 契約書で、工程ごとの契約類型と検収の条件が区別されているか
- マニュアル、研修、稼働後の問い合わせ窓口がそれぞれ何語で提供されるか確認済みか
- 稼働後の初回の月次処理と初回の棚卸しが、支援範囲に含まれているか
- 日本本社の標準方針と現地の法令要件が衝突する箇所を、事前に特定しているか
上から4つに「はい」と答えられない段階で見積もりを取ると、各社の金額が何を根拠にしているのか比較できません。逆に、下から3つを確認せずに契約すると、稼働後に想定外の負担が発生しやすくなります。
よくある質問
パッケージソフト導入支援とは何をしてくれるのか
製品を選定した後に、要件定義、Fit&Gap分析、設定作業、データ移行の設計、現場教育、稼働後のフォローまでを伴走する役務です。中心にあるのはFit&Gap分析で、現状把握、システム機能調査、適合性評価、対応方法決定の4ステップで、自社の業務とパッケージの標準機能を照合し、合わない部分の扱い方を決めます。ライセンスを販売して初期設定を行うだけの契約とは、作業範囲が大きく異なります。
導入支援の費用はどれくらいかかるのか
対象範囲と拠点の状況によって幅が大きく、一律の相場を示すことはできません。日本国内の目安として紹介されている水準は本文の費用の項に記載していますが、タイでの導入は通貨も対象範囲も異なるため、その数字をそのまま当てはめることはできません。実務的には、複数社から見積もりを取り、Fit&Gap分析、データ移行、教育、稼働後フォローの各工程が金額の中にどう含まれているかを揃えたうえで比較してください。金額そのものより、Gapへの対応方針が決まる前の見積もりなのか、決まった後の見積もりなのかを確認するほうが、判断の材料になります。
Fit&Gap分析は自社だけで実施できるのか
現状把握と要件の洗い出しについては、自社で進められる部分が多くあります。全部署の業務フローを書き出し、要件に必須と希望の優先順位を付けるところまでは、社内で着手できます。難しいのはシステム機能調査と適合性評価で、設定で対応できる範囲と開発が必要になる境界線を判断するには、その製品の設定項目を熟知している必要があります。現実的には、現状把握までを自社で進め、その資料を持って導入支援会社の機能調査と適合性評価を受けるという分担が効率的です。
Gapが見つかったら、カスタマイズするべきか
まず選択肢を3つ並べることをおすすめします。業務プロセスを標準機能に合わせて変更する、カスタマイズやアドオン開発で埋める、別ツールを併用して外側で処理する、の3つです。判断の目安として、その業務手順に法令や顧客要求という根拠があり、かつ業務の中核にあるGapだけをカスタマイズの候補に残し、慣習に由来する手順や業務の周辺にあるGapは、業務変更か別ツールでの処理を先に検討してください。カスタマイズは初回の開発費用だけでなく、バージョンアップのたびの検証と改修を将来にわたって呼び込むためです。
システム開発の委託とパッケージ導入支援はどう違うのか
決めることの順番が逆になります。スクラッチ開発の委託は、自社の業務要件を先に定義し、それを満たすシステムを設計して作ります。パッケージ導入は、完成しているシステムが先にあり、そこに自社の業務を照らし合わせて、合わない部分の扱いを決めます。前者の中心作業は設計と実装、後者の中心作業は照合と差分への対応方針の決定です。費用が膨らむ経路も違い、前者は要件追加と仕様変更、後者はGapに対するカスタマイズの積み上げによって膨らみます。
タイ拠点で導入支援会社を選ぶときの注意点は何か
3点あります。第一に、タイのERP導入支援市場にはグローバル製品のパートナーからローカルベンダーまで幅があり、同じ「導入支援」でも作業範囲と費用感が大きく違うため、金額の前に作業内訳を揃えて比較することです。第二に、マニュアル、研修、稼働後の問い合わせ窓口がそれぞれ何語で提供されるかを契約前に確認することです。第三に、日本本社の標準システムと現地の法令・税制要件が衝突する箇所を、Fit&Gap分析の段階で「法令に起因するGap」と「運用慣習に起因するGap」に分けて記録し、本社と現地の議論を整理しやすい形にしておくことです。
まとめ
パッケージソフトの導入支援について、本記事で扱った要点を整理します。
- 導入支援はソフトを売る役務ではなく、要件定義、Fit&Gap分析、設定、データ移行設計、教育、稼働後フォローまでを伴走し、自社の業務で使える状態にするための役務である
- パッケージ導入プロジェクトがつまずく典型は機能不足ではなく、Fit&Gap分析を経ずに導入し、後からカスタマイズ費用が積み上がる構造にある
- Fit&Gap分析は、現行業務や要求事項とシステム機能を比較してFitとGapを洗い出す手法で、現状把握、システム機能調査、適合性評価、対応方法決定の4ステップで進めるとされている
- 適合性評価では、Fit/Gapの判定だけでなく、乖離の理由と業務影響度まで記録することが、その後の判断の質を決める
- 成功のポイントとして、全部署の現場担当者を巻き込むこと、要件に必須と希望の優先順位を付けること、既存システムとの連携を考慮すること、要件を画面・入力・処理・出力まで具体的に書くことが挙げられている
- Gapへの対応策は、業務プロセスの変更、カスタマイズやアドオン開発、別ツールの併用という3つが一般的で、必須かつ業務の中核にあるGapだけをカスタマイズの候補に残すのが実務的な順序である
- カスタマイズは初回の開発費用に加えて、バージョンアップのたびの検証と改修を将来にわたって呼び込むため、稼働後の保守費用の水準を導入時に決めていることになる
- タイではグローバルERPパートナーからローカルベンダーまで選択肢の幅が大きく、同じ導入支援という言葉でも作業範囲と費用感が異なるため、金額の前に作業内訳を揃える必要がある
- 日系工場のタイ拠点では、本社標準システムと現地要件のGapが構造的に大きくなりやすく、法令に起因するGapと運用慣習に起因するGapを分けて記録することが有効である
- 現地語でのマニュアル、研修、問い合わせ窓口の有無は、快適さの問題ではなく投資が回収できるかを左右する条件である
最初にやるべきことは、製品の再比較でも見積もりの取り直しでもありません。自社の業務フローを全部署ぶん洗い出し、要件に必須と希望の優先順位を付けるところまでを社内で進めることです。この資料があるかないかで、導入支援会社から返ってくる提案の具体性がまったく変わります。
TOMAS TECHは、タイで操業する日系製造業向けに、生産管理システムPEGASUSをはじめとする現場のDX支援を行っています。パッケージの導入支援についても、「Fit&Gap分析をどこまで自社で進めればよいのか」「本社標準と現地要件の衝突をどう整理すべきか」といった手前の相談からお受けしています。導入を決める前の情報収集の段階でも構いませんので、お問い合わせページからお気軽にお声がけください。
参考情報
- DTPネット – フィット&ギャップ分析とは。4ステップの進め方と成功のポイント
- アーツアンドクラフツ – ERP導入におけるフィット&ギャップ分析とGapへの対応策
- IT trend – ERPパッケージの種類と中堅・中小企業向け国産ERPの特徴
- SF Solutions – タイにおけるOdoo ERPの導入支援と現地税制対応
- NEXUS – SAP Business Oneのクラウド導入パートナーによる支援内容
- Acclime Thailand – Microsoft Dynamics 365のタイにおける導入支援
- MineERP – タイのSME工場向けERPとDEPA d-transformプログラムに関する記述
- improbe – 中小製造業における生産管理システムの導入費用の目安と補助金