インドのジュエリーEC・小売の CaratLane が、レガシーシステムを Oracle Fusion Cloud の ERP と SCM に置き換えたという発表が出た。380店舗・150都市、FY26 で前年比34%成長という規模の会社が、成長のさなかに基幹を入れ替えた事例である。この記事では、報じられた事実を整理したうえで、同じ判断を迫られる日本の事業会社と、それを請ける開発会社が何を読み取るべきかを書く。
要点
- CaratLane はタタ傘下のオムニチャネル・ジュエリー小売企業。2008年創業で、380以上の店舗を150以上の都市に持ち、並行してECを運営している。
- FY26 の成長率は前年比34%と報じられている。
- 導入したのは Oracle Fusion Cloud ERP（財務）と Oracle Fusion Cloud SCM（サプライチェーン・製造）。プラットフォームに組み込まれたAI機能も含む。
- 目的として挙げられているのは、レガシーシステムの置き換え、季節変動への対応、自動化の推進、オムニチャネルの連携改善。
- 共同創業者で Chief Product and Technology Officer の Gurukeerthi Gurunathan 氏は「Oracle Fusion Applications は、より連携が取れて機動的な運営モデルを作る助けになった」と述べている。
私が注目したのは「成長率34%の最中に入れ替えた」という一点
事実として面白いのはプロダクトの選定結果ではない。年34%で伸びている会社が、基幹システムの入れ替えという最も業務を止めやすいプロジェクトを、そのタイミングでやったということだ。
受託開発の現場で基幹刷新の相談を受けるとき、決断が遅れる理由はほぼ常に同じである。「今は忙しいから、落ち着いてからやる」。そして落ち着くことは無い。伸びている会社は伸びているから忙しく、伸びていない会社は別の理由で余裕が無い。結果として、レガシーが本当に限界を迎えてから、つまり最も選択肢が少ない状態で刷新に入ることになる。
380店舗・150都市・ECの併走という構成は、在庫と会計のデータが最も割れやすい形をしている。店舗ごとの在庫と、ECの在庫と、会計上の数字が別々のシステムに載っていれば、成長するほど不整合の絶対量が増える。成長は既存システムの歪みを増幅する装置であって、時間が解決してくれる問題ではない。この会社が成長率のピークで踏み切ったのは、そこを見誤らなかったからだと私は読んでいる。
「AI機能つき」を評価するときに見るべきなのは、AIではない
発表には embedded AI が含まれている。この種のリリースでAI機能が語られるとき、作る側として私が見るのは、AIそのものではなくその手前でデータが1箇所に集まったかどうかである。
在庫・受注・会計が別システムに分かれたままなら、どれだけ賢いモデルを載せても、入力されるデータは部門ごとの部分最適な数字にしかならない。逆に、統合基盤の上にデータが揃った時点で、需要予測にせよ異常検知にせよ、価値の大半は「AIの精度」ではなく「データが揃っていること」から出てくる。
つまりこの事例で本質的に効いているのは、AI機能の追加ではなく ERP と SCM を同時に入れたことだと考えている。財務だけ、あるいは在庫だけを入れ替えると、境界に手作業の突き合わせが残り、その突き合わせがそのままAI活用の上限になる。同時に入れるほうがプロジェクトは重いが、後から連携で埋める前提で分割すると、埋めるための開発費が後年に積み上がる。基幹システムとERPの守備範囲の違いは基幹システムとERPの違いと選び方の判断基準に整理しているので、範囲設計の前に一度確認してほしい。
パッケージを選ぶということは、業務を変えると決めることでもある
Oracle Fusion のような標準パッケージを選ぶ判断は、製品の機能比較の結論ではなく、「自社の業務を標準に合わせる」という経営判断である。ここを曖昧にしたまま進めると、要件定義の途中で現場から例外業務が出てきて、アドオン開発が膨らむ。作り込まれたERPはバージョンアップできなくなり、数年後に「またレガシー」になる。
私が発注側に必ず確認をお願いしているのは次の2点だ。
- 標準に合わせる業務と、合わせない業務の線引きを、着手前に経営レベルで文書にしているか。 この線引きを現場に委ねると、全部が「合わせられない業務」になる。
- マスタデータのコード体系を統一する意思決定者がいるか。 取引先・品目・勘定科目のコードが部門ごとに割れている状態でのデータ移行は、ERP導入そのものと同じくらいの難所になる。
刷新プロジェクト全体の進め方は基幹システム刷新の必要性・進め方・失敗しないためのポイント、要件の固め方は要件定義の進め方と5ステップの手順にまとめてある。
開発会社・SIerにとって、この事例が意味すること
同業として読むなら、示唆は「ERPの導入支援案件が増える」という話ではない。
- 戦う場所が実装から前工程に移っている。 パッケージを入れる意思決定をした顧客が求めるのは、機能を作る力ではなく、業務をどこまで標準に寄せるかを一緒に決められる力になる。ここで価値を出せないと、パッケージベンダーの下請けとしての実装工数の切り売りに落ちる。
- 周辺と接続の領域が残る。 ERP標準では吸収できない自社固有の業務（この事例なら店舗とECの受注連携、ジュエリー特有の在庫単位の扱いなど）は残り続ける。中核はパッケージ、差別化領域はスクラッチという構成が現実解になり、そこが受託の主戦場になる。
- 人材要件が変わる。 言われた仕様を実装できる人ではなく、業務の例外を聞いて「これはやめましょう」と提案できる人が必要になる。この転換は採用より育成の設計に効いてくる。要件定義そのものの捉え方については要件定義は「守る約束」ではないにも書いた。
外注と内製の切り分けをどう考えるかは、システム開発を外注する7つのメリットと判断スコアシートに判定の道具を用意している。
まとめ
CaratLane の事例から取り出せる実務的な教訓は3つある。成長のピークは基幹刷新の適期であること。AI機能の価値はその手前のデータ統合で決まること。そしてパッケージ選定は業務を変える経営判断であること。製品名を追う前に、この3つを自社の状況に当てはめてみてほしい。
出典: CaratLane polishes its edge with Oracle Fusion Cloud Applications
