ERP クリーンコア導入を成功させる鍵は、カスタマイズを一律に禁止することではありません。差別化しない業務は標準へ寄せ、競争力に直結する要件はアップグレード可能な境界の外で拡張し、残る例外には責任者・期限・廃止条件を与えることです。本稿では、タイ・ASEAN工場がRFP、Fit-to-standard、90日診断、受入試験まで一貫して使える判断基準を示します。
ERP クリーンコアとは「変更しない」ではなく「変更を統治する」こと
クリーンコアは、ERP本体を聖域にして現場の要求を拒む標語ではありません。ERPの標準リリースに追随できる状態を維持しながら、必要な業務差別化を実装するための設計・運用規律です。SAPの公式資料は、クリーンコアを業務プロセス、拡張、データ、統合、運用の5つの観点で捉えています。したがって、アドオン本数だけを減らしても、重複マスタ、監視されないインターフェース、属人運用が残れば「クリーン」とは言えません。
タイ工場では、本社テンプレート、タイ税務、顧客固有ラベル、ローカル倉庫運用、設備連携、日本語・タイ語の承認が同時に存在します。標準に寄せるだけでは現場が回らず、現場要求をすべてコアに入れれば次回更新が止まります。必要なのは、要求を議論可能な単位に分解し、どこに置くか、誰が認めるか、いつ見直すかを決めることです。
| 誤解 | 実務上の意味 | 確認すべき証拠 |
|---|---|---|
| カスタマイズは全面禁止 | 差別化しない変更を減らし、必要な拡張を安全な境界へ移す | 要件分類表、拡張台帳 |
| 標準化率が高ければ成功 | 業務成果、アップグレード性、統制を同時に満たす | KPI、回帰試験範囲、例外期限 |
| クラウドにすれば自動的にクリーン | データ、統合、運用も設計し直す | API台帳、データ所有者、監視記録 |
| アドオンを削除すれば完了 | 廃止後の業務手順と責任を定着させる | 廃止判定、教育記録、利用ログ |
判断の中心は「標準か個別か」だけではありません。まず、その業務が顧客価値や法令順守に必要かを確認します。次に、標準設定で吸収できるか、ERP内で動く軽量拡張が必要か、外部アプリへ分離すべきかを判断します。それでも決められないものだけを期限付き例外とします。この順番なら、現場の声を消さずに技術負債を制御できます。
SAP クリーンコアの5原則を工場の確認項目へ翻訳する
SAP公式が示す5つの観点は、製品用語のままRFPへ貼るのではなく、工場の証拠に翻訳すると機能します。評価単位は「説明」ではなく「台帳、責任者、テスト結果が残るか」です。
| 原則 | 工場で問う質問 | 最低限の成果物 |
|---|---|---|
| Business processes | その差異は競争力・法令・顧客要求のどれか | プロセス差分表、KPI |
| Extensibility | 拡張は標準APIと許可された方式を使うか | 拡張方式、所有者、廃止条件 |
| Data | 重複マスタと変換責任はどこか | データ辞書、品質ルール |
| Integration | 接続方式、監視、再送、障害責任は明確か | インターフェース台帳、SLA |
| Operations | 更新後の回帰試験と障害対応を回せるか | テストパック、運用Runbook |
業務プロセスでは、現行手順をそのまま要件にしないことが重要です。「三重入力を続けたい」は要件ではなく現状です。本当の要件は、例えば「ロット放出の責任者が承認履歴を10分以内に確認できる」のように、成果と制約で表現します。すると標準ワークフローや外部承認アプリでも満たせる可能性が見えます。
データでは、品目、BOM、設備、取引先、ロット、単位の正本を決めます。統合では、点対点接続を増やすのではなく、標準API、イベント、ファイルの使い分けと監視を決めます。運用では、四半期更新やバージョンアップのたびに誰が何を再試験するかまで含めます。この5面を同じ審査会で扱うことで、開発だけクリーンで運用は属人的という分断を避けられます。
Fit to Standardワークショップは現行画面の再現会ではない
Fit-to-standardでは、最初に標準シナリオを実機または具体的なプロセスで見せ、参加者が「現行と違う箇所」を述べるだけでなく、「違いが事業成果を損なうか」を検証します。現行帳票の列や画面順を先に聞くと、既存システムの再構築になりがちです。標準デモ、業務結果、統制要件、差分の順に議論します。
推奨する参加者は、業務責任者、現場のキー利用者、品質・財務・IT、統合担当、導入パートナーです。現場担当だけでは全社標準を決められず、本社だけでは実行可能性を見誤ります。各差分は会議中に「受理」「追加証拠」「却下」「期限付き保留」のいずれかへ進め、議事録に埋めたままにしません。
| ワークショップ段階 | 主要な問い | 出力 | 承認者 |
|---|---|---|---|
| 標準シナリオ確認 | 標準で業務成果を達成できるか | Fit記録 | 業務責任者 |
| Delta記述 | 何が、誰に、どの頻度で不足するか | Delta要件 | プロセスオーナー |
| 根拠評価 | 法令、顧客、差別化、慣習のどれか | 根拠資料 | 品質・財務・経営 |
| 方式選定 | 4分類のどこへ置くか | 決定記録 | 標準化審査会 |
| 受入定義 | 何を示せば完了か | 受入基準 | 業務・IT双方 |
SAPのホワイトペーパーが扱うSolution Standardization Boardの考え方は、名称より権限設計が重要です。審査会は単なる承認印ではなく、拠点横断の再利用、標準への回帰、技術負債の期限を判断します。申請者、業務所有者、アーキテクト、セキュリティ、財務の役割をRACIで示し、拒否理由と再申請条件も記録します。
要件をSTANDARD・IN-APP・SIDE-BY-SIDE・EXCEPTIONへ4分類する
全要件を次の4分類へ置くと、ERP標準化の議論が具体化します。分類名は製品によって多少異なっても、判断原則は共通です。
STANDARD：設定と業務変更で実現する
差別化しない会計、購買、在庫移動、基本的な生産実績などは、まず標準を前提にします。標準に合わせることで、将来更新の試験範囲と独自マニュアルを減らせます。ただし「標準だから正しい」とは限りません。権限分離、タイの税務書類、顧客契約、品質承認を満たすことを受入試験で確認します。
IN-APP：ERP内で必要な軽量拡張
項目追加、画面調整、許可されたロジック、帳票補助など、トランザクションの直近で動く必要があり、製品が提供する公開拡張ポイントで実現できるものです。技術者は使用API、拡張ポイント、更新互換性を記録します。「ERP内の方が作りやすい」だけではIN-APPを選びません。
SIDE-BY-SIDE：差別化をコアの外に置く
高度な計画、顧客ポータル、AI支援、設備データ処理、複雑な承認などを外部アプリとして構築し、公開APIやイベントでERPへ接続します。SAP公式は複雑な拡張にBTP上のside-by-sideを推奨していますが、個別案件では対象ERP、既存クラウド、セキュリティ、運用能力を比較して選びます。外へ出せば自動的に安全になるわけではなく、API契約、データ所有、可用性、障害時の手順が必要です。
EXCEPTION：期限付きで残し、廃止条件を付ける
法令の解釈待ち、標準機能の提供待ち、短期の顧客契約、移行期間など、今すぐ整理できない要件を置きます。例外には、業務所有者、技術所有者、認めた理由、影響、期限、次回審査日、廃止条件、代替手順を必須にします。期限を過ぎても自動延長せず、審査会へ戻します。
| 分類 | 選定条件 | 必須の証拠 | 見直しタイミング |
|---|---|---|---|
| STANDARD | 標準設定と手順で成果を満たす | 設定、業務手順、Fit証跡 | リリース更新時 |
| IN-APP | ERP内実行が必要で公開拡張を利用 | API/拡張点、単体・回帰試験 | 四半期または更新時 |
| SIDE-BY-SIDE | 独立展開・差別化・複雑処理が必要 | API契約、SLA、監視、復旧 | 契約更新・構成変更時 |
| EXCEPTION | 即時解消不能で期限を設定できる | 根拠、所有者、期限、廃止条件 | 指定日、最長でも半年ごと |
ERPアドオン削減は「本数」よりリスクと利用実態で優先する
アドオンを100本から50本へ減らしたという数だけでは、事業効果を判断できません。未使用の帳票30本と、受注を止める高結合ロジック1本ではリスクが違います。棚卸しでは、利用頻度、業務重要度、コア結合度、標準代替、試験工数、障害履歴、データ機密性を評価します。
最初に実利用ログを集めます。申告だけでは「念のため必要」が増えるため、呼出回数、利用者、最終利用日、処理対象を確認します。次に、標準機能で代替できるもの、同じ目的の重複、法令上の根拠が失効したものを候補化します。廃止は削除ボタンではなく、業務手順変更、教育、権限削除、アーカイブ、監査証跡の保持まで含みます。
優先順位は、例えば「コア結合度×変更頻度×業務影響」で置けます。点数は企業内の比較に使うもので、市場標準ではありません。高リスクかつ標準代替があるものを先に減らし、高リスクだが差別化に必要なものはSIDE-BY-SIDEへ移す設計を検討します。
| 評価軸 | 低 | 中 | 高 |
|---|---|---|---|
| 利用頻度 | 90日超未使用 | 月次 | 日次・常時 |
| コア結合度 | 公開APIのみ | 許可拡張点 | テーブル直結・改変 |
| 業務影響 | 参考情報 | 一部手作業へ退避可 | 出荷・会計・品質が停止 |
| 標準代替 | 即時代替可 | 設定・教育が必要 | 代替なし |
| 回帰負荷 | 自動試験済み | 部分自動 | 手作業・属人 |
この棚卸しはシステム刷新時だけでなく、半年ごと、主要リリース前、M&Aや新工場展開時にも行います。利用されないアドオンを保守し続ける費用と、使われるが危険なアドオンを移す費用を分けて予算化すると、経営判断がしやすくなります。
ERPサイドバイサイド拡張を許す境界と禁止事項
side-by-sideは、ERPを守りながら差別化を速くする有力な方法です。しかし境界を曖昧にすると、今度は外部アプリ群が新しいレガシーになります。設計時に「ERPが正本のデータ」「外部アプリが正本のデータ」「一時キャッシュ」「分析コピー」を区別し、双方向更新を最小化します。
許可する代表例は、設備データの前処理、現場UI、顧客・仕入先ポータル、AIによる提案、複雑なスケジューリング、短い改善サイクルが必要なアプリです。一方、仕訳整合性や在庫評価のようにERPトランザクションと不可分な処理を、理由なく外へ複製するのは避けます。切断時に工場が続行できるか、復旧後に二重登録を防げるかも受入条件です。
拡張のRFPには、公開APIだけを使用すること、認証・認可、監査ログ、冪等性、再送、タイムアウト、バージョン管理、監視、障害責任、データ削除、契約終了時の移行を記載します。製造業API連携開発の記事で扱う接続契約を、クリーンコアの審査条件へ組み込みます。
インターフェース統治でERP COREを守る
クリーンコアでは、ERP本体だけでなく接続も管理対象です。工場にはMES、WMS、設備ゲートウェイ、ラベル、品質、EDI、銀行、税務、BIなどがあり、同じデータが複数経路で流れます。インターフェース台帳には、送信元・宛先、データ所有者、方式、頻度、最大遅延、再送、重複防止、監視、個人情報、停止時の手順を記録します。
SAP HelpのClean Core Integrationは、インターフェースを技術分類し、準拠度、監視範囲、改善候補を見える化する考え方を示しています。実務では、単に「APIである」と分類するだけでなく、公開・非公開、同期・非同期、管理対象・野良、監視あり・なしを区別します。直接DB参照や共有フォルダ受け渡しが残る場合は、即時禁止ではなく、影響と移行期限を付けて例外化します。
| 台帳項目 | 受入時の質問 | 不合格例 |
|---|---|---|
| データ契約 | 必須項目、単位、時刻、コード体系は合意済みか | 暗黙の列順に依存 |
| エラー処理 | 再送、隔離、補正、承認の責任者は誰か | 失敗をメールだけで通知 |
| 冪等性 | 同じメッセージを再送しても二重計上しないか | 再送で二重入庫 |
| 監視 | 業務件数と技術状態の両方を監視するか | HTTP成功だけを見る |
| 変更管理 | APIバージョンと廃止予告を管理するか | 相手側更新で突然停止 |
| 事業継続 | 停止中の手順と復旧後の照合があるか | 紙運用後の再入力が未定義 |
監視はシステム稼働だけでなく、注文数、出庫数、エラー滞留時間など業務の完全性を見る必要があります。緑色のサーバー監視でも、メッセージが一部欠落していれば工場は困ります。運用会議では、障害件数と同時に例外インターフェースの残日数、監視未実装数、非公開APIの解消計画を確認します。
5年TCOは初期費用だけでなく回帰・保守・更新を分けて比べる
ERP クリーンコア導入は、初期構築だけを見ると外部化やテスト自動化が追加費用に見えることがあります。そこで、初期、年間回帰・保守、アップグレードを分けて比較します。以下は意思決定の会話を具体化するための仮定であり、ベンダー相場、実績平均、見積保証ではありません。
前提は、タイ工場1拠点、利用者120名、5年間です。
| シナリオ | 初期 | 年間回帰・保守 | 3年目更新 | 5年総額 |
|---|---|---|---|---|
| A：コア改変中心 | 4.80M THB | 1.20M THB × 5年 | 2.40M THB | 13.20M THB |
| B：標準＋IN-APP/SIDE-BY-SIDE | 5.40M THB | 0.65M THB × 5年 | 0.80M THB | 9.45M THB |
算式は、Aが 4.80 + (1.20 × 5) + 2.40 = 13.20M THB、Bが 5.40 + (0.65 × 5) + 0.80 = 9.45M THB です。差額は 13.20 − 9.45 = 3.75M THB、A比では 3.75 ÷ 13.20 × 100 = 28.4%（小数第2位四捨五入）です。Bは初期が0.60M THB高いものの、この仮定では5年総額で逆転します。
この28.4%を一般的な削減率として広告してはいけません。実際の結果は、既存アドオン、データ品質、ライセンス、クラウド契約、拠点数、停止可能時間、内製能力、統合数で変わります。RFPでは、各社に同じ費目表で初期・5年運用・更新・廃止・移行を回答してもらい、含有範囲を比較します。
加えて、金額化しにくいリスクも別表にします。アップグレード延期、セキュリティ修正遅延、属人化、監査対応、停止時間、変更リードタイムなどです。金額とリスクを混ぜて一つの「ROI」に見せるより、仮定と証拠を分けた方が経営会議で検証できます。
90日診断で現状を測り、合意できるロードマップへ変える
90日診断は、すべてを設計し切るプロジェクトではありません。現状の不透明さを減らし、投資判断に必要な対象範囲、優先順位、概算前提、受入方法をそろえる活動です。4段階をDISCOVER、DECIDE、BUILD、VERIFYとして進めます。
1〜20日：DISCOVER
アドオン、インターフェース、ジョブ、帳票、マスタ、権限、障害、変更履歴を収集します。工場を歩き、端末、紙、Excel、ラベル、設備接続を現物確認します。利用ログが取れない場合は、その不確実性自体を記録します。経営層には事業目標、現場には停止条件、ITには更新制約を聞きます。
21〜45日：DECIDE
主要プロセスでFit-to-standardを行い、差分を4分類します。高リスクアドオンとインターフェースを抽出し、標準化審査会で原則と例外を決めます。この時点で全要件の詳細仕様を作る必要はありませんが、例外所有者と期限は決めます。
46〜70日：BUILD
代表シナリオを使い、標準設定、IN-APP、SIDE-BY-SIDE、監視の実現性を小さく検証します。PoCは見栄えのよい画面だけでなく、エラー、切断、再送、権限、監査ログまで含めます。RFPの回答形式と価格表も準備します。
71〜90日：VERIFY
ロードマップ、TCO仮定、移行波、受入基準、体制、リスクを経営と現場でレビューします。未確定事項は隠さず、追加調査の担当と期限を付けます。最終成果は「製品を買う結論」ではなく、続行・範囲縮小・段階導入・保留を判断できる資料です。
| 期間 | 成果物 | Exit条件 |
|---|---|---|
| 1〜20日 | 現状台帳、課題、利用証跡 | 重要システムと所有者が特定済み |
| 21〜45日 | 4分類、例外台帳、原則 | 優先要件の判断者と期限が明確 |
| 46〜70日 | 代表検証、RFP草案、費目表 | 技術リスクと回答形式を確認 |
| 71〜90日 | ロードマップ、受入、投資仮定 | 経営・工場・ITが次の意思決定に合意 |
生産管理システム導入期間の記事で扱う全体日程と組み合わせると、診断90日と本導入の期間を混同せずに計画できます。診断のExit条件を満たしてから製品選定へ進めば、曖昧な要件のまま見積を比較するリスクを下げられます。
RFPに入れるべきERP標準化とクリーンコアの質問
RFPでは「クリーンコアに対応していますか」というYes/No質問を避けます。提案者が、方式、制約、証拠、責任、費用を同じ形式で答えられるようにします。
- 標準プロセスとDelta要件をどの手順で分類し、誰が承認するか。
- STANDARD、IN-APP、SIDE-BY-SIDE、EXCEPTIONの選定基準を示せるか。
- 使用する公開API、拡張ポイント、非推奨機能、更新互換性を一覧化するか。
- データ正本、同期、再送、重複防止、監査ログをどう設計するか。
- 四半期更新・年次更新時の回帰試験範囲、工数、責任をどう見積もるか。
- 既存アドオンの利用実態をどのデータで確認し、廃止をどう受け入れるか。
- 例外に所有者、期限、廃止条件を付け、どの会議でレビューするか。
- 契約終了時にソース、設定、ログ、データ、運用知識をどう引き渡すか。
回答には「標準です」という文だけでなく、画面、設定、API仕様、テストケース、監視画面、責任分界を求めます。ライセンス費、導入費、外部クラウド、統合基盤、監視、5年保守、更新試験、廃止支援を分け、前提ユーザー数とトランザクション量も記載させます。
提案評価は価格点だけでなく、標準適合、拡張安全性、運用可能性、移行、受入証跡、タイ現地支援を評価します。製品デモには、自社シナリオ、例外処理、エラー復旧、権限制御を含めます。成功事例は参考になりますが、同じ期間や効果を約束する証拠にはしません。
FAT・SAT・受入証跡で「標準化できた」を検証する
クリーンコアは設計書だけでは完成しません。FATでは設定、拡張、API、例外処理を管理環境で確認し、SAT/UATでは工場のネットワーク、端末、ラベル、周辺システム、権限、実データに近い条件で業務を通します。
受入基準は、正常系だけでなく、接続断、タイムアウト、重複メッセージ、設備停止、誤ったマスタ、権限不足、承認者不在、再開後照合を含めます。各テストには前提、入力、期待結果、実績、証跡、判定者、不具合IDを持たせます。STANDARDなら設定と業務結果、IN-APPなら許可拡張点と回帰、SIDE-BY-SIDEならAPI契約と復旧、EXCEPTIONなら期限と代替手順を証明します。
| 分類 | FATの重点 | SAT/UATの重点 | 完了証跡 |
|---|---|---|---|
| STANDARD | 設定、権限、標準フロー | 現場手順、統制、処理時間 | シナリオ結果、承認 |
| IN-APP | 拡張点、単体、回帰 | 実端末、帳票、権限 | API/拡張記録、回帰結果 |
| SIDE-BY-SIDE | 契約、エラー、監視 | 切断、再送、照合、SLA | ログ、監視、復旧記録 |
| EXCEPTION | 影響、代替手順 | 暫定運用の実行可能性 | 所有者、期限、廃止計画 |
Go-Live後は安定化期間で証跡を継続し、例外を新たな恒久運用にしないようにします。ERP Hypercareの記事で扱う30日管理とつなぎ、障害、回避策、恒久対策、標準への回帰を同じバックログで追跡します。
タイ工場で確認するdepa制度とローカル要件
タイのdepa Thailand Digital CatalogのTax 200%ページでは、対象SMEについて払込資本金500万THB以下かつ年間売上3,000万THB以下、登録されたデジタル製品・サービスの購入・賃借等、特別控除の上限30万THB、対象期間2025年6月24日から2027年12月31日と案内されています。これは制度ページの記載を要約したもので、個別企業の適用を保証するものではありません。対象支出、証憑、関連者取引、申告方法などは税務・会計の専門家とdepaの最新情報で確認してください。
クリーンコア案件では、補助・税制の有無だけで製品を決めないことが重要です。対象サービスが登録されているか、契約主体がタイ法人か、支出時期が期間内か、控除上限に対して申請コストが妥当かを確認します。制度で初期費用が軽くなっても、運用・統合・更新の5年総額が増えれば本来の目的に反します。
タイ固有の要件として、税務書類、個人データ、タイ語表示、拠点ネットワーク、現地休日、輸入・輸出、BOI関連運用などを早期に洗い出します。ただし、法令要件と「昔からそうしている」を同じ優先度で扱わず、根拠資料と責任者を確認します。本社テンプレートとの差異はEXCEPTIONへ放置せず、標準設定、ローカライズ機能、外部サービスのどれで解決するか決定します。
公開事例から学べることと、一般化してはいけないこと
SAPが2026年9月に公表したColombinaの事例では、16か国同時移行、7工場・39物流拠点を持つ企業でのERPと周辺システムの統合が紹介されています。Damen Shipyardsの事例では、業務の80%を単一SAP基盤へ統合し、Reuse before Buy before Buildを採用したとされています。Evatecの事例では、Cloud ERP Public Editionを10か月で導入し、その後6か月のHypercareを行ったと紹介されています。
これらはベンダーが公表した個別事例です。16か国、80%、10か月、6か月をタイ工場の標準値や市場平均として使うことはできません。学ぶべきなのは数字そのものではなく、複数拠点を一つの原則で扱うこと、再利用・購入・構築の順序を決めること、本稼働後の安定化を計画に含めることです。自社では現状台帳、停止条件、データ品質、利用者数、統合数をもとに見積もります。
導入後のKPIと標準化審査会の運営
標準化率だけをKPIにすると、必要な差別化まで削る行動が起きます。KPIは、結果、アップグレード性、例外、運用品質を組み合わせます。
| KPI | 定義例 | 注意点 |
|---|---|---|
| 標準採用率 | 標準で受け入れた要件／判定済み要件 | 高さだけを目標にしない |
| 非公開API数 | 本番で利用中の非公開接続 | 期限と代替計画を併記 |
| 例外期限超過率 | 期限超過例外／有効例外 | 自動延長を禁止 |
| 更新回帰時間 | 更新ごとの総テスト工数 | 範囲縮小による見かけ改善に注意 |
| 自動試験率 | 自動化済み重要ケース／重要ケース | 実行成功だけでなく検証品質を見る |
| インターフェース検知時間 | 障害発生から検知まで | 業務欠落の検知も含める |
| 廃止完了数 | 証跡付きで退役した拡張 | 本数ではなくリスク減も記録 |
標準化審査会は月次またはリリース単位で開催し、新規要求、期限到来例外、非推奨API、更新影響、障害からの改善を扱います。会議資料は、決定待ちを上に置き、情報共有だけの項目を減らします。各決定には理由、選択肢、影響、所有者、期限を残し、半年後に再現できる状態にします。
よくある質問（FAQ）
ERP クリーンコア導入とは何ですか？
ERP本体への無秩序な改変を避け、業務プロセス、拡張、データ、統合、運用を継続的に統治する導入方法です。標準機能を優先しつつ、必要な差別化は公開された拡張方式やside-by-sideへ配置し、例外には所有者・期限・廃止条件を設定します。
SAP クリーンコアはカスタマイズ禁止ですか？
一律禁止ではありません。標準で満たせない正当な要件を、更新可能性と運用責任を保てる方式で実装します。ERP内実行が必要なら許可されたIN-APP/on-stack、複雑で独立展開すべきならside-by-sideを検討し、理由と証跡を残します。
Fit to Standardでは現場の要望が無視されませんか？
進め方次第です。現行画面をそのまま再現する要求と、法令・顧客・品質・競争力に必要な成果を分けます。Delta要件の根拠、頻度、影響、代替を確認し、標準化審査会で透明に判断すれば、現場要求を無視せず優先順位を付けられます。
ERPアドオン削減は何から始めますか？
実利用ログ、業務重要度、コア結合度、標準代替、回帰工数、障害履歴を棚卸しします。未使用・重複を廃止し、危険だが必要なものは公開拡張やside-by-sideへの移行候補にします。削除だけでなく、手順・教育・権限・監査証跡まで完了させます。
ERPサイドバイサイド拡張の注意点は何ですか？
データ正本、API契約、認証、冪等性、再送、監視、SLA、障害責任、契約終了時の移行を定義することです。外部化すれば自動的にクリーンになるわけではありません。ERPと外部アプリの双方向更新を必要最小限にし、切断・復旧を受入試験します。
クリーンコアの費用対効果はどう比較しますか？
初期費用だけでなく、年間保守・回帰試験、更新、統合基盤、監視、廃止、教育を同じ期間で比較します。本稿の13.20M THB対9.45M THBは計画対話用の仮定で、市場平均ではありません。自社の拠点数、利用者、統合、アドオン、停止条件で再見積もりしてください。
まとめ：例外を無期限・無責任にしない
ERP クリーンコア導入の目的は、標準化率を競うことではありません。差別化しない業務を標準へ寄せ、必要な差別化をアップグレード可能な境界へ置き、例外を所有者・期限・廃止条件付きで管理することです。5原則、Fit-to-standard、4分類、インターフェース台帳、FAT/SAT、運用KPIを一つの意思決定系につなげると、現場実行と将来更新を両立しやすくなります。
製品選定前の拡張棚卸し、Fit-to-standardワークショップ、RFPや受入基準づくりの検討段階でもご相談いただけます。タイ工場の現状台帳から始め、標準へ寄せる範囲と残す差別化を一緒に整理したい場合は、TOMAS TECHへお問い合わせください。
参考情報
- SAP Help: Clean Core Extensibility for SAP Cloud ERP
- SAP Help: Clean Core Integration
- SAP: Clean Core Business Processes for SAP S/4HANA Cloud
- SAP News: Colombina—faster delivery, stronger security, AI readiness（2026-09-18）
- SAP News: Damen Shipyards（2026-09-14）
- SAP News: Evatec Cloud ERP implementation（2026-09-16）
- depa Thailand Digital Catalog: Tax 200%
*本稿は2026年9月20日時点の公開情報をもとにしています。法令・税務・製品仕様・制度の適用は、公式情報および専門家へ最新条件をご確認ください。事例値とTCO試算は市場平均や成果保証ではありません。*
