EC2つを大型リプレイス、ついでに14モール含めた全体運用フローも劇的改善させたお話

経緯

15年モノのスクラッチECと、多種多様なモール展開

Webセールスチーム

長年愛されているECサイトって、
システムも独自の進化を遂げていることが多いって本当ですか？

外谷

本当ですよ。
ビジネスの規模が大きくなったり、新しい販路が増えたりするたびに、その都度ベストな機能を追加していくわけですからね。

今回ご相談いただいた企業様も、15年以上スクラッチ（独自開発）でBtoBとBtoCの自社ECを運用されていて、時代に合わせてたくさんの機能を組み込んでこられました。

Webセールスチーム

長年の成長があったからこそ、次のステップへ進むタイミングだったんですね。

外谷

しかも自社ECだけでなく、主要ECモール（楽天、Amazon、Yahoo!ショッピング等）やキャリア系、計14のモールを展開されていました。

長期運用を見据えて、安定した基盤に整えたい

外谷

そうして年月が経つにつれ、「これからの長期運用を考えたときに、セキュリティ面やサーバー管理の負担を減らし、もっと安定した基盤に整えたい」というご要望が出てきたんです。

今回のお話は、自社EC2店舗の大型リプレイスとともに、「長期運用・安定基盤」のためにEC業務全体の運用フロー改善を実現させたお話です。 

Webセールスチーム

うおおお！

現状整理（AsIs）

外谷

多数の店舗および自社ECにおいて、15年間で様々な機能を継ぎ足した形となり、かなりの独自運用が展開されていました。

以下が基本的な運用フローです。

【基本データフロー】注文、発注、発送、基幹システム連携

Webセールスチーム

ほとんどのデータで、担当者による手作業が必須になってるような…
それに、自社EC(toC)に機能が盛りだくさんですね！

ペンさん

その通りです。楽天やAmazonからの注文はネクストエンジンを経由するものの、基本的にはほとんどの受注データが、手動でのデータ整形＆入出力を必要としていました。
さらに無在庫販売であったため、発注後は仕入れ先業者が顧客へ直送。その後、業者から送られてくる出荷データをEC担当者がマクロでファイル変換して自社ECに取り込む必要があります。
また基幹システム連携においても、月次でデータをエクスポート、マクロで変換して連携させる、という手動運用でした。

次は「注文データ」に注目してみていきます。

【注文データ】自社ECに集約、多数の手動処理、複雑な設計

外谷

注文データの詳細は以下です。

大手ショッピングモール：ネクストエンジンに連携されデータレイアウトを整形後に、自社EC（toC）に取り込み注文データを作成。
行政サービスEC：ショッピングモールと同様にExcelのマクロやAccessといった変換ツールを手動で通して、自社ECに取り込み注文データを作成。

作成した注文データは、データベースの多くのバリデーションを解除しており、それぞれのショッピングモールや行政サービスECに合わせたデータで構成。
 軽減税率の判定ルールや、税込税別、送料無料などの設計が複数あり、とても複雑なデータ構成となっていました。

Webセールスチーム

各ショップごとに、それぞれの手動処理があるんですね・・
設計も、とっても複雑です！

※上記に対応するためバリデーション(入力チェック)を解除している

【その他データ】全ての商品データ、会員データも自社ECに集約

外谷

それだけではなく、注文データ作成のため、全モール＆ECの商品データ、会員データも持つ必要がありました。
これらも自社EC(toC)に集約されていたんです。

課題のまとめ

外谷

ここで、運用を煩雑にしている課題をまとめしょう。
主には、手動のエクスポート＆データ処理が必要な以下2つと考えました。

①発注機能
②基幹システム連携

自社ECや各モールの注文データを発注用CSVとして出力する仕組みはあった。
しかし、データをエクスポートした後、Excelのマクロやデータベース構築ツールのAccessを使って手動の処理を行い、それぞれの発注機関へインポートする煩雑な運用だった。

②基幹システム連携

商品、顧客、受注、発注のCSVデータをダウンロードする機能自体はあった。
しかし、①と同様にExcelマクロを使った手動の処理が必要だった。

Webセールスチーム

いったいこれらの課題を、自社ECリプレイスとあわせてどのように解決したのでしょう？

あるべき姿へ（ToBe）

外谷

解決のポイントは、ずばり以下の2つです。

• SaaSカートへのリプレイス。あえて作りこまない選択

• システムの役割を明確に分割。業務効率化＆データフローの簡略化を実現

SaaSカートへのリプレイス。あえて作りこまない選択

ペンさん

まずは、自社EC2つのリプレイスです。
今回は、SaaSカートの「Bカート」を選択しました。

Webセールスチーム

あれ…？自由度の高いオープンソースではないんですね。
外谷さんは「EC-CUBE」のエバンジェリストですし、そっちの方が色々な機能を実装できたんじゃ…

外谷

確かに「EC-CUBE」を利用すれば現仕様をそのまま再現できますね。
ただ今回のケースだと独自のカスタマイズを重ねることとなり、再び「魔改造」状態を作りだすことになるんです。

現行のECサイト同様に様々な開発を組み込むことになり、セキュリティリスク、サーバー管理が必要となってきます。数年後にバージョンアップ（再度のリニューアル）を迫られる可能性も発生しますね。

外谷

お客様のご要望は「この先も長く、安定して使えること」でした。
それならば、保守・セキュリティ面を考慮し、あえて限られたカスタマイズ性のSaaSカートを選択。足りない機能要件は別のシステムに持たせる。

そうすることで、各ツール＆システムの役割も明確化され、整理された綺麗なデータフローも実現できると考えたんです。

Webセールスチーム

なるほど、お客様が「本当に求めていること」を読み解いたうえでの判断だったんですね…！

システムの役割を明確に分割。業務効率化＆データフローの簡略化を実現

Webセールスチーム

でも外谷さん、自社ECをシンプルなSaaSに変えちゃうと、注文データや、あの複雑な税率計算、送料無料ルールはどこで処理するんですか？

外谷

そこが今回の肝です！
これまでは自社ECがすべてを無理やり背負っていましたが、今回はそれぞれのツールの「役割」を明確に分割しています。

注文・在庫・商品データを一元管理するマスターとして、OMS（一元管理システム）の「ネクストエンジン」を全体の軸に据えました。

そして、ネクストエンジンだけでは対応できない業務をピンポイントで解決するために、「ConnectFlow」という独自の連携システムをOEMで開発して組み合わせたんです。

Webセールスチーム

データの流れがスッキリしましたね！！
今まであちこちにあった、手動のデータ整形業務も無くなってます！

外谷

これによって、運用を煩雑にしていた2つの課題が解決しました。

もちろんSaaSのサービスを利用しているので、サービスに合わせた運用に運用フロー自体を変更していただくことも必要でしたが、それを加味してもトータルの運用リソースの改善は実現できました。

自社ECや各モールの注文は、自動連携された「ネクストエンジン」に集約。
担当者がステータスを「印刷待ち」に変えるだけで、「ConnectFlow」と自動連係。仕入れ先へのメール発注やFAX送信（e帳票・SFTP連携）をボタンひとつで自動完了。手動のマクロ変換を完全に撤廃した。

②基幹システム連携の簡略化

「ConnectFlow」に、基幹システム専用のレイアウトへ自動整形するCSVダウンロード機能を実装。出力ファイルをそのまま基幹システムへインポートできる仕様へと変更し、月末に発生していた面倒なマクロ作業を撤廃した。

行政サービスECは他のECとは管轄部署が異なるため、「ネクストエンジン」を基盤とした連携フローとは別に実装。 「ConnectFlow」にデータをアップロードし、メール発注は「ConnectFlow」から直接メール送信、FAX発注と基幹システム用のデータはそれぞれに合わせた形式でダウンロードできる仕様とした。

ECのお悩みはTOPPANクロレへ

外谷

今回の構築は運用の多くがブラックボックス化されており、一緒に紐解いていくことで無駄を削ぎ落とすことで実現することができました。

私たちTOPPANクロレは、ECサイトの構築や運用の伴走支援だけではなく、業務フローの改善も得意としております。

運用業務の煩雑さにお悩みの皆様、まずは現状の棚卸しから一緒に始めてみませんか？ぜひお気軽にご相談ください。

関連サービス