eコマース統合ソリューションの選び方

公開: 2018-12-06

切断されたシステムでビジネスを継続すると、時間とコストがかかる可能性があります。 Magento、Shopify、BigCommerce などの e コマース プラットフォームと ERP または POS システムの間で、注文、配送/追跡情報、在庫の更新などを常に手動で管理する必要性に圧倒されるかもしれません。

より効率的な運用方法があるはずです。 そして幸いなことに、あります! 現在、マーチャントは、e コマース プラットフォームとバックエンド システムを接続して注文処理などの重要なプロセスを自動化するさまざまなソリューションから選択できます。

ただし、eコマースプラットフォームの統合プロジェクトは大きな仕事になる可能性があります. 適切な統合アプローチとパートナーを選択することは、プロジェクトの成功に不可欠です。 誤って管理されたプロジェクトは、非常に複雑で時間がかかり、何千ドルも無駄にしてしまう可能性があります。 そして、あなたが把握しようとしている間、顧客体験は引き続き悪化し、満足度の評価が低くなり、顧客サービスチケットが増加し、売上が失われます. あなたの評判がかかっています!

初めて統合する場合でも、既存の統合ソリューションを置き換える場合でも、統合方法と理想的な e コマース統合ソリューションを探すための 3 つの異なるアプローチを比較します。

eコマース統合への3つの異なるアプローチ

何が統合を必要とするようになるかは問題ではありません。 初めて統合しようとしている人もいれば、うまくいかないソリューションを交換する必要がある人もいます。

初めて統合する理由

  • 過剰販売し続ける
  • システム間の手動データ入力に数え切れないほどの時間を費やす
  • 間違った商品を発送するなど、コストのかかる間違いを犯す
  • 注文は常に遅れて発送され、配達時間を保証することはできません
  • サプライヤーのデータを可視化できない

現在の統合ソリューションを置き換える理由

  • システムのクラッシュや注文エラーが原因で、定期的に Web 注文を失う
  • 製品のコンテンツや価格がオンラインで十分な速さで更新されていない
  • 在庫の更新が遅くなり、過剰販売が発生する
  • オンラインで購入して店舗で受け取るなど、より競争力のある機能を追加したい

統合はこれらの問題の解決に役立ちますが、e コマース プラットフォームを金融、POS、または 3PL システムに接続するための最適な統合アプローチを選択した場合にのみ解決されます。

この記事では、推奨されるアプローチを示しながら、3 つの統合アプローチのリスク、利点、およびコストを比較します。 最初から適切なアプローチを選択するか、新しいソリューションにアップグレードしてください。 ビジネスとしての運営を改善し、顧客が求めるエクスペリエンスを提供する必要があります。

この記事で取り上げる主な統合ソリューションは次の 3 つです。

  • カスタムビルド:システムを直接結び付けるカスタム コードを作成することによる、システムの 1 回限りの統合。
  • ソフトウェア アドオン (アプリ、モジュールなど):ポイント ツー ポイント統合を使用して統合の 1 つまたはいくつかの部分を処理するための基本的なソリューション。
  • ミドルウェア:運用ハブはエンドポイント システム間に配置され、事前に構築されたコネクタを使用してそれらを接続します。

カスタム構築された e コマース統合アプローチ

小売業者としての最初の本能は、カスタム構築された統合ソリューションに目を向けることかもしれません。 これらは、eコマース代理店、ソフトウェアコンサルタント、または統合の専門知識を持っているかどうかにかかわらず別のベンダーによって提供される傾向があります. あなたはベンダーに精通しており、彼らはあなたのビジネスを知っており、値札が好きです。 では、彼らにカスタム統合を構築させることの害は何でしょうか?

何百ものマーチャントと話をして、カスタム構築された統合ソリューションで繰り返し発生する共通のリスクがあることを学びました。 この道をたどる前に、次のことを考慮してください。

プロジェクト全体を実行しているのは 1 人ですか?

あなたのプロジェクトは、社内の 1 人の開発者に委任されますか? もしそうなら、これは 1 人がソリューション全体を構築、保守、およびサポートすることを意味します。 これは、リソースが限られているために、これらのプロジェクトでよく発生します。

その開発者が休暇を取ったり、働けなくなったり、ベンダーの会社を辞めたりしたらどうなるでしょうか?

あるホラー ストーリーでは、「自動化されたソリューション」があると考えていたマーチャントと協力しました。 しかし、彼らはまだ一貫してウェブ注文を失っていました. 彼らが調査したところ、彼らの解決策は、実際には 1 人の開発者が夜間に 8,500 万ドルの取引をすべて一人で行っていたことがわかりました! 当然のことながら、マーチャントの統合は日常的に壊れていました。

彼らはあなたのエンドポイント システムをどの程度知っていますか?

統合の専門知識が限られている、またはまったくないベンダーは、統合プロジェクトごとにカスタム コードを作成する傾向があります。 彼らは通常、システム用に事前に構築された接続を備えた統合プラットフォームを活用しません。

各システムがデータを受信する方法の要件を理解することは、深刻な学習曲線です。 データのどのフィールドに対して読み取りまたは書き込みを行う必要があるかを理解する必要があります。 対応するビジネス ルールとプロセスを理解する必要があります。 仕事で誰かに学んでほしいものではありません。

たとえば、e コマース プラットフォームを ER​​P に統合する場合、一般的な要件は、製品の品揃えを Web にシンジケートする必要があることです。 これは、ERP プラットフォームから e コマース プラットフォームにアイテム データを挿入することを意味します。 課題は、アイテム データが ERP システムと e コマース プラットフォームではまったく異なる方法で使用されることです。 ERP では、主に在庫管理と GAAP 会計慣行 (会計/運用上の焦点) に使用されます。 e コマース プラットフォームでは、Web コンテンツとして使用され、注文を生成します (e コマース/マーケティングの焦点)。

ベンダーは、エンドポイント システムのそれぞれのニュアンスにどの程度精通していますか? それらを接続するためのベスト プラクティスに従っていますか? 各システムがどのように使用され、その理由をどの程度理解していますか?

ベンダーは、エンドポイント システムの統合に関する経験が不足しているため、加盟店の一般的な要件を満たすためのすべてのシナリオを把握していないことがよくあります。

統合は長期にわたって維持されますか?

データが欠落している、または不完全であるすべてのシナリオを統合が考慮していない場合、e コマース注文の価格が ERP システムの価格と異なるなどの単純なことが原因で、統合が機能しなくなる可能性があります。

ソリューションが事前にすべての要件を満たしていない場合、このような問題に常に対処することになります。 統合プロバイダーにバグを修正してもらい、統合を正常に実行し続けるための機能強化を実装してもらうために、最終的にはより多くの費用を支払うことになります。

統合により、ビジネスの規模を拡大できますか?

ハードコーディングされたカスタム ソリューションは、実装ベンダーと永遠に結びつく可能性があります。 ソフトウェアを変更したり、新しい販売チャネルを追加したりする場合、ベンダーは各システムを直接結び付けているため、統合を最初からやり直す必要があります。

統合の費用はいくらですか?

カスタム統合プロジェクトは、価格タグが異なる場合があります。 場合によっては、ソリューションが基本的なものであり、要件を無視しているため、価格が低いか安価である可能性があります。 一方、ベンダーはソリューション全体をゼロから構築しているため、20,000 ドルから 30,000 ドルを見積もる場合があります。 彼らはあなたのビジネスにのみ役立つ新しいものを構築しています。 プロジェクトを完了するには、彼らの側で多くの時間と労力がかかります。

何にお金を払っているのか、そして受け取っている価値をよく理解してください。

結論

カスタム統合プロジェクトが理にかなっている場合があります。 接続が容易でないレガシーまたは珍しいシステムを使用している可能性があります。 SKU の管理や注文処理のロジックに関して、考慮が必要な真に独自のビジネス プロセスが存在する可能性があります。 ただし、ほとんどのビジネスはこれらのカテゴリに分類されません。

カスタムのハードコード化された統合に関しては、特に統合の目的はプロセスのスケーリングを支援することであるため、拡張するソリューションに自分自身を閉じ込めないでください。


eコマース統合のためのソフトウェアアドオン

マーチャントが注目する次の統合戦略は、e コマースまたは金融システムのアプリ マーケットプレイスで、あらゆる種類の安価な (月額 100 ~ 200 ドルなど) 統合ソリューションを見つけることができます。 ただし、アドオンをダウンロードする前に、次の点を考慮してください。

アプリはポイントツーポイント統合を使用していますか?

これらのソリューションの多くは、ポイント ツー ポイント統合を使用して e コマース プラットフォームとバックエンド システムを接続しています。つまり、システム間に運用ハブはありません。 代わりに、e コマース プラットフォームは、データを送信するために金融、POS、または ERP システムに「向けられ」ます。 このタイプの接続は、多くの場合、送信するデータ、その量、および同期の頻度を制限します。これは、大量のデータまたは複雑な操作がある場合に特に問題になる可能性があります.

どのような種類のデータを処理しますか?

アドオンは通常、注文や在庫などの 1 つまたは 2 つのタイプのデータのみを処理する、より基本的な統合ソリューションです。 商品の価格変更、販売チャネル全体にわたる大規模な製品カタログの管理、または 3PL またはロジスティック システムでの配送/追跡データを処理できない場合があります。 自動化できるプロセスが制限され、複数の場所での注文フルフィルメントやサプライヤー統合などの複雑なクロスチャネル機能を処理できなくなります。

新しい販売チャネルを追加するのにどれくらいの労力がかかりますか?

ビジネスが成長するにつれて、これらの統合アプリも拡張できなくなる傾向があります。 販売チャネルを追加したり、新しい倉庫を追加したり、財務システムを更新したりすると、複数の統合を追加してシステムを接続する必要があります。 ただし、既存のソリューションを追加または変更するのは簡単ではありません。 代わりに、新しいシステムに統合を追加することは、毎回ソリューション全体を再構築することを意味する可能性があります。これは、ポイント ツー ポイントの統合ではシステム間の 1 対 1 の関係のみが可能になるためです。 3 ~ 4 つのシステムがある場合、それらのシステムを統合するには 12 以上の接続が必要になる場合があります。

ポイントツーポイント統合

結論

基本的な統合アプリは、大量の注文、大規模な製品カタログ、または直送などの複雑なフルフィルメントのニーズがない場合に開始するのに適した場所です。 在庫更新などのデータの同期は 1 日 1 回以下で十分です。 これらのソリューションは、1 つの Web サイトでのみ販売していて、注文または在庫管理システムに同期したい場合にも役立ちます。

しかし、多くのマーチャントは、このような単純な統合を必要とする段階をすでに過ぎています。 いくつかのシナリオを挙げると:

  • 複数のブランドの Web サイトや、Amazon や eBay などのマーケットプレイスなど、複数の販売チャネルでの販売
  • Microsoft Dynamics NAV などのより堅牢な ERP システムを運用する
  • 複数の倉庫、直送業者またはサプライヤーの接続を伴う複雑なフルフィルメント プロセス
  • 顧客固有の価格設定が必要な B2B 顧客に販売する
  • マトリックス アイテム、キット/バンドル、またはダイヤモンドのような複雑な製品を含む複雑な製品カタログ

これらのアプリは開始するのに適した場所のように思えるかもしれませんが、上記のようなニーズは多くの場合複雑すぎるため、すぐにその機能を超えてしまいます. 多くのマーチャントは事後にこれに気づき、これらのソリューションをはぎ取って統合プロジェクトを最初からやり直しています。


ミドルウェア e コマース統合ソリューション

最後の統合アプローチは、ミドルウェア プラットフォームを使用することです。 これらのタイプのソリューションには、エンドポイント間のデータ トランザクションを自動化するために、e コマースと金融、POS、および/または 3PL システムの間に位置する「ハブ」があります。 ハブは、システム間のデータの接続、データ変換、およびオーケストレーションを管理します。 理想的には、プラットフォームは、ハブを介してシステムを接続する事前構築済みのコネクタを利用する必要があります。

これは、いくつかの理由から、成長するマーチャントにとって魅力的な統合アプローチです。

  • 統合は既製のソリューションであり、カスタムまたはポイントツーポイントの統合ではありません
  • さまざまなエンドポイント システムの統合に関する豊富な経験を持つ統合をコア ビジネスとするプロバイダーが提供
  • 注文、在庫、顧客、アイテム、配送/追跡データなどの重要なデータ タイプを同期します
  • 追加の販売チャネルや、倉庫や物流システムなどのフルフィルメント ロケーションへの複数のコネクタを使用できるため、ソリューションはお客様とともに成長します
  • システムのクラッシュやプロセスの遅延なしに、より大量のデータを処理

ただし、選択できるミドルウェア統合プロバイダーがいくつかあります。 比較するのは圧倒されるかもしれませんが、プラットフォームを互いに際立たせる考慮すべきいくつかの領域を以下に示します. これらのタイプの質問をして、本当に十分なミドルウェア プラットフォームを見つけてください。

Shopify LightSpeed とハブスポークの統合

eコマースや小売向けに設計されていますか?

利用可能なミドルウェア統合プロバイダーは多数ありますが、そのすべてが小売りや e コマースに重点を置いているわけではありません。 eコマースプラットフォームで認定されている代理店と協力したいのと同じように、小売のニーズを内外で理解している統合ベンダーと協力する必要があります. 直送注文、クロスチャネル在庫の可視性、複数の場所/複数店舗の注文フルフィルメントなどの機能を有効にするために小売用に統合する場合、固有の要件とベスト プラクティスがあります。 統合パートナーは、システム API から API へのデータ同期だけでなく、競争力のあるショッピング エクスペリエンスを顧客に提供するソリューションの定義を支援する必要があります。

データはリアルタイムで処理されますか?

ソリューションがデータを同期する頻度は? 同期は 1 日 1 回ですか、1 時間ごとですか、それともリアルタイムですか?

リアルタイム処理以外で妥協しないでください (それがシステムの API で処理できる場合)。 リアルタイムのデータ処理により、在庫切れ商品の過剰販売、プロモーション価格の予想以上の上昇、オンラインでの製品リストの遅延、注文処理の遅延など、多くの問題を防ぐことができます。 全体として、顧客があなたのブランドとより積極的に交流できるようにします。

私のデータを監視していますか?

統合ソリューションについて受けるサポートのレベルについては、必ずお問い合わせください。 データをプロアクティブに監視し、問題があれば警告してくれますか? 彼らはあなたのためにデータの再試行を行いますか? サポートチームはどこにありますか? サポート チームの支援が早ければ早いほど、自社の顧客の問題をより迅速に解決できます。

自分のデータをどの程度可視化できますか?

プラットフォームは、データが各エンドポイント システムから送受信されることを確認する必要があります。 データの詳細な監査により、各トランザクションを可視化して、カスタマー サービス チームがシステムを通じて注文の経路を追跡できるようにする必要があります。 また、成功したトランザクションのはるかに大きなデータセットにそれらを埋め込むのではなく、対処する必要がある失敗または例外を強調するためのツールも提供する必要があります。

複数の異なるシステムを接続できますか?

多くのミドルウェア プラットフォームは、e コマースおよび金融システム用のさまざまな事前構築済みコネクタを提供します。 複数の e コマース、マーケットプレイス、POS、ERP/会計、および 3PL システムを提供するプロバイダーを探します。 プラットフォームを追加または切り替える必要がある場合は、統合のニーズに対して同じプロバイダーを引き続き使用できることを確認する必要があります。

データが欠落している、または正しくない場合、データをどのように処理しますか?

ERP に e コマース SKU が存在しない場合のように、トランザクションのデータが欠落したり正しくない場合、堅牢なソリューションには組み込みのプロセスがあります。 適切に構築されたソリューションは、さまざまな種類のデータ例外をすべて処理したり、データの問題を通知したりできるため、不満を抱く顧客やサポートにかかる時間を節約できます。

システムの 1 つが何らかの理由でオフラインになるとどうなりますか?

ほとんどの小売業者は、重要なシステム (ERP など) のクラッシュを経験しています。 フラッシュ セールやホリデー シーズンなど、最も重要な時期に必ず行われるようです。 システムがオンラインに戻るまで、十分なミドルウェア プラットフォームがデータ トランザクション (特に注文) を保存または調整できる必要があります。 これにより、ダウンタイム中に注文や顧客データが失われることはありません。

プラットフォームとコネクタを維持しているのは誰ですか?

プロバイダーが SaaS または iPaaS プロバイダーの場合、プラットフォームとエンドポイントのコネクタを定期的に維持する必要があります。 これは、統合に影響を与えるセキュリティ更新、バグ、またはその他のシステム更新を担当し、プラットフォームとそのコネクタに修正を自動的にプッシュすることを意味します。

このタイプのモデルでは、顧客はこのレベルのプラットフォーム メンテナンスに対して毎月のサブスクリプション料金を支払うため、統合が実行され続けているという安心感が得られます。

結論

うわー! それは多くの情報でした。 統合プロジェクトが大事業であることは冗談ではありません。 ただし、事前に綿密な調査を行うことが、最適なソリューションを確実に選択できる唯一の方法です。 統合は、ビジネスの非常に重要な側面であり、今日の業界で競争することができます。

ここ nChannel では、どのマーチャントも適切なビジョンとテクノロジーとの統合を達成できると信じています。 お客様のビジネスに最適なアプローチを見つけるお手伝いをいたします。

nChannel ミドルウェア統合プラットフォームが適切かどうかを確認したい場合は、ここをクリックしてください。