OMS更改の選定ポイント/選び方/種類

保守契約の満了通知やEOS/EOLの案内が届いてから候補探しを始めると、比較検討にかけられる時間は数ヶ月しか残っていないことが珍しくありません。OMS更改の選定とは、動かせない期限から逆算しながら、パッケージ・SaaSへの乗り換え、フルスクラッチでの再構築、両者を組み合わせるハイブリッドという3つのアプローチのうち、自社の受注ロジックとスケジュールに見合う進め方を絞り込む作業を指します。

本記事では、OMS更改を検討する前に整理すべき自社課題、更改アプローチの3つの種類、ベンダー・製品を比較する評価軸、RFP作成から契約までの選定プロセス、PoCとデータ移行リハーサルの設計方法、よくある失敗とその回避策を解説します。契約満了やEOS/EOLの期限を前に、何から手をつければよいか迷っている担当者の方が、比較表の項目をそろえて2〜3の候補まで絞り込めるように整理しています。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・OMS刷新の完全ガイド

OMS更改を検討する前に整理すべき自社の課題

候補製品やベンダーを集める前に行うべきは、なぜ今このタイミングで更改が必要になったのかを明文化することです。期限、対象範囲、現行システムの制約を一文で説明できれば、比較すべき候補と不要な検討を切り分けやすくなります。

まず確認すべきは、保守契約やハードウェア・ミドルウェアのEOS/EOLがいつ到来するかという事実です。システムリプレース全体には規模に応じて数ヶ月から1年以上、ベンダー選定・契約だけでも1.5〜2.5ヶ月を要するため、残り期間が半年を切っている場合はスケジュールがすでに逼迫している可能性があります。特別保守として通常の1.5倍から数倍の費用を払い続ける延長サポートを、いつまで許容できるかも合わせて確認します。

期日を確認する際は、保守契約書やベンダーからの通知だけでなく、ハードウェア本体、OSやミドルウェア、周辺連携で使っているAPI基盤など、複数のレイヤーで別々にEOS/EOLが設定されていないかも点検します。どれか一つでも見落とすと、後工程で想定より早く対応を迫られることになりかねません。

自社EC、ECモール、実店舗POS、卸売取引先という接続先が多いほど、更改先候補に求める連携要件は増えます。分割出荷やセット商品の分解、複数倉庫への振り分けといった自社特有の複雑な注文パターンを洗い出し、それが標準機能(Fit to Standard)で処理できるか、追加開発が必要になるかを事前に見立てておくと、後工程のPoCで検証すべき項目が具体化します。

あわせて、移行対象とするデータの範囲も早い段階で方針を決めておきます。未出荷のオープンな注文データのみを新システムへ移すのか、出荷済みのクローズなデータも一部含めるのかによって、必要なデータ移行の作業量とリハーサル回数は大きく変わります。「移さない合理的な理由」を明確にできる範囲まで対象を絞り込む姿勢が、後工程の負荷を抑えるうえで重要です。

OMS更改アプローチの3つの種類

OMS更改の進め方は、大きくパッケージ・SaaSへの乗り換え、フルスクラッチでの再構築、両者を組み合わせるハイブリッドの3つに分けられます。どれを選ぶかは、期限までの残り時間と、独自ロジックへの依存度で判断が分かれます。

標準機能に自社業務を合わせるFit to Standardのアプローチで、開発の長期化による期限超過リスクを抑えられる点が最大の利点です。トライアル環境やモックアップでFit&Gap分析を行い、標準機能で吸収できない部分だけを見極めることで、長期のPoCを簡略化・短縮できます。期限が半年を切っているなど、時間的な余裕が少ない更改案件では、まずこのアプローチを軸に検討するのが現実的です。

独自の受注ロジックが競争優位に直結し、標準機能では代替できないと判断される場合はフルスクラッチが選択肢になります。ただし期限が迫る更改案件では、開発長期化によって期限を超過するリスクが極めて高いため、「受注受付→在庫引当→出荷指示」という核となる機能を先行して開発し、詳細な分析レポートやロット管理といった付加機能は期限後に段階的に追加する進め方が、リスクを局所化するうえで現実的です。

標準的な受発注・請求処理はパッケージやSaaSに任せ、独自性の高い在庫引当ロジックや基幹システム連携部分だけを個別に開発するハイブリッドは、標準化できる業務と自社固有の業務を切り分けられる企業に適しています。このコア・サテライト型の構成では、パッケージ・SaaS側と個別開発部分のどちらを正のデータとするか、注文データの再送や取消時にどちらが処理を担うかをあらかじめ決めておく必要があります。API連携の工数は対象システムや仕様によって差が大きいため、固定的な相場を前提にせず、入出力項目と例外処理を具体的に示して個別に見積もることが重要です。

ベンダー・製品を比較する評価軸

候補が絞れたら、技術力や実装力、TCO、契約上のリスクという複数の軸で横並びに比較します。営業説明の分かりやすさに評価が引っ張られないよう、確認方法まで統一することが重要です。

SIerはメーカー系・ユーザー系・独立系・外資系・コンサル系の5つに分類され、得意領域が異なります。POSレジなどハードウェア連携に強いメーカー系、親会社の受注業務フローに精通したユーザー系、特定製品に縛られず中立提案ができる独立系、グローバル基準の開発手法を持つ外資系、経営戦略とIT戦略の統合を得意とするコンサル系のうち、自社が最も重視する条件に合うタイプへ絞り込みます。同じ分類の中でも得意分野は企業ごとに差があるため、分類はあくまで一次的な絞り込みの目安として使います。

料金体系は月額固定か従量課金かを確認し、初期費用に加えて5年間の運用費・保守費・ライセンス費、トランザクション課金やAPI従量課金といったOMS特有の変動費まで含めてTCOを算出します。ロックイン回避の観点では、オープンな技術・標準プロトコルの採用、設計書やマニュアル等ドキュメントの完備、データ所有権とCSV等でのエクスポート・返却権が契約に明記されるかを確認します。財務面では帝国データバンクの評点で50点以上、可能であれば66点以上のBランクを一つの目安にし、倒産予測値がG1〜G3の安全圏にあるかも合わせて確認すると、契約途中の頓挫リスクを抑えられます。

「連携できる」という説明だけでは、実際にAPIでリアルタイム同期できるのか、CSVの手動出力にとどまるのかが分かりません。WMS、基幹システム、決済システム、ECモールとの連携について、対象データ、同期方向、頻度、エラー発生時の復旧方法まで具体的に確認し、「デモで確認」「仕様書で確認」「契約条項で確認」のように証拠の残し方まで統一しておくと、選定後の認識違いを防げます。

RFP作成から契約までの選定プロセス

RFP作成から契約締結までは、段階を追って絞り込むプロセスとして設計すると、期限内に必要な精査を終わらせやすくなります。

RFPには、対象チャネル数、月間受注件数、現行システムの構成、更改の期限、移行対象とするデータ範囲(未出荷のオープンな注文データか、出荷済みのクローズなデータまで含むか)を明記します。一括移行と段階移行のどちらを想定しているか、権限・操作ログ・バックアップ・障害時対応・データ保管場所・エクスポート形式といった非機能要件も、必須・望ましい・将来の3段階に分けて記載すると、条件を満たさない候補を早期に除外できます。

Step1として技術適合評価のためのRFIを送付し、1〜2週間で書類上の適合性を確認します。Step2ではPoCなど実地検証に3〜6週間をかけ、最も複雑な注文パターンでの動作を確かめます。Step3ではコンプライアンス・契約精査に1〜2週間を充て、データ所有権やエクスポート権、SLAといった契約条件を確定させます。この3ステップは合計で1.5〜2.5ヶ月程度を要するため、RFP作成・社内稟議の数週間から1ヶ月と合わせて、逆算スケジュールに組み込んでおきます。

PoCとデータ移行リハーサルの設計方法

PoCとデータ移行リハーサルは、要件を網羅する検証ではなく、致命的なリスクを早期に発見するための場として設計します。

3〜6週間のタイムボックスの中で、自社EC・ECモール・実店舗POS・WMSといった各チャネルからの注文取り込みと在庫引当ロジックが標準機能で処理できるかを最優先で確認します。分割出荷やセット商品の分解など、実際に発生している最も複雑な注文パターンを検証シナリオに組み込み、API連携の疎通確認まで一通り実施することで、デモの説明だけでは見えない実装上の限界を洗い出せます。

本番同等の条件で複数回のリハーサルを行い、所要時間や手順を把握するとともに、リハーサル後から本番切替までに発生した差分データ(新規注文)をどう更新し新旧を突合するかというルールを厳密に定義します。致命的なエラーが発生した際に切り戻すコンティンジェンシープランについても、リハーサル段階で実効性まで確認しておくことが重要です。稼働直後の初期流動管理では、重大障害が週にどの程度以下であれば安定稼働とみなすかという定量的な終了基準を、計画段階で設定しておきます。

UATでは、現場の担当者が本番同等の環境を実際に操作し、一部キャンセルや特定顧客への値引き、複数倉庫への分割出荷、セット商品の在庫分解や同梱処理といったイレギュラー対応まで含めたシナリオで検証します。各チャネルの在庫連携が正しく反映され、二重販売や売り越しが起きないか、注文ステータスに矛盾がないかを、選定段階のPoCと稼働直前のUATの両方で確認する体制を整えておくと、切替後のトラブルを大きく減らせます。

OMS更改の選定でよくある失敗と回避策

更改特有の失敗は、期限に追われるあまり検証や契約条件の確認を省略してしまうところから生まれます。よくあるパターンを把握しておくことで、同じ轍を踏まずに済みます。

残り期間が数ヶ月しかない段階で、独自要件へのこだわりからフルスクラッチを選んでしまうと、開発長期化によって期限を超過するリスクが高まります。標準機能で吸収できる部分と、どうしても譲れない独自ロジックを事前に切り分け、後者だけを段階的に個別開発する方針に早めに転換することが、期限内にリスクを抑える現実的な対応です。

価格や機能だけを見て契約を急ぐと、データ所有権やエクスポート権が明記されないまま、次の更改時に身動きが取れなくなることがあります。設計書やマニュアルの納品有無、標準プロトコルの採用状況、中途解約時のペナルティも契約前に確認します。財務が不透明なベンダーとやむを得ず契約する場合は、ソースコードエスクローや親会社保証といった手段も検討し、契約後に判明する事態を減らします。具体的な製品の候補はOMS更改のパッケージ・クラウド製品一覧を参照すると、共通軸で比較しやすくなります。

もう一つ見落としやすいのが、選定に関わる部門の偏りです。情報システム部門だけで機能や価格を比較し、現場の受注・出荷担当者や、決済・会計を扱う部門を後工程で初めて巻き込むと、稼働直前になって業務要件の抜け漏れが発覚することがあります。RFP作成の段階から、現場・情報システム・経理といった関係部門を交えて必須要件を洗い出しておくことが、期限内の選定を確実にする土台になります。

OMS更改の選定前に確認しておきたいポイント

候補を絞り込んだ後も、期限や契約形態によって判断が分かれやすい点があります。ここでは、選定の最終段階で確認しておきたい事項を整理します。

ベンダー選定・契約だけで1.5〜2.5ヶ月、開発・テスト・データ移行に数ヶ月を要するため、残り期間が半年を切っている場合は、フルスクラッチよりも標準機能での対応を軸に検討する方が現実的です。独自要件は、コア機能の稼働後に段階的な個別開発で対応する計画に切り替えることを検討します。

3〜5年の複数年契約でライセンス・月額保守費用が10〜20%程度割引されるプランもありますが、中途解約時のペナルティやベンダーロックインのリスクとのトレードオフになります。次回の更改を見据え、データ所有権とエクスポート権が契約に明記されているかを確認したうえで、割引率だけで契約年数を決めないようにします。

帝国データバンクの評点は100点満点で平均40点台とされ、50点以上が標準的な信用力の目安、66点以上のBランクであれば優良企業とされます。評点や倒産予測値だけで契約可否を決めるのではなく、財務が不透明な場合はソースコードエスクロー契約など、追加のリスクヘッジ手段と組み合わせて判断します。

まとめ

OMS更改の選定は、保守契約満了やEOS/EOLという期限を起点に、残り時間を確認したうえでパッケージ・SaaS、フルスクラッチ、ハイブリッドのどのアプローチを軸にするかを決めることから始まります。SIerの5分類やTCO、ロックイン回避の契約条件、ベンダーの与信という評価軸で候補を横並びに比較し、最も複雑な注文パターンを使ったPoCとデータ移行リハーサルで実装力とリスクを検証することが欠かせません。

保守契約満了やEOS/EOLの期日を確定させ、残り期間からベンダー選定・契約・開発・データ移行に必要な期間を逆算します。そのうえで、対象チャネル数や在庫引当ロジックの複雑度に応じて、パッケージ・SaaS、フルスクラッチ、ハイブリッドのどれを軸にするかを早期に決めることが、期限内に選定を完了させる鍵になります。優先順位を決めずに全ての選択肢を並行検討しようとすると、比較に時間を取られて肝心のPoCやデータ移行リハーサルにかける時間が削られてしまう点にも注意が必要です。

資料上の機能一覧ではなく、自社で実際に発生している複雑な注文パターンを使ったPoCとデータ移行リハーサルで、標準機能の限界と実装力を確認したうえで最終決定してください。既製のパッケージやSaaSだけでは独自の在庫引当ロジックや基幹システム連携を吸収できない場合、フルスクラッチやハイブリッド構成も現実的な選択肢になります。riplaはフルスクラッチ開発の立場から、更改先の選定基準の整理や、既存システムとの連携を含む個別構築を支援しています。

▼全体ガイドの記事
・OMS刷新の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。