コマースのリプラットフォーム
オムニチャネルだけではなく、コマース ブランドにとって、コマースプラットフォームの再構築は常に多くの期待を伴うエキサイティングなプロジェクトです。
プラットフォームの再構築により、柔軟性が向上し、メンテナンス コストが削減され、顧客エクスペリエンスが向上し、売上高の成長に大きな影響を与えることが目的のはずです。
プラットフォームの再構築は非常にストレスがかかるものでもあり、適切に計画または実行されないとすぐに悪夢になってきていました。
どんな小さなブランドであっても、企業にとっては、相対的に大規模で取り返しのつかないプロジェクトであるために、重要なことを見逃して、気づくのが手遅れになることもよくある話と聞きます。
ビジネスの成長を促進するはずだったものが、取締役会、チーム、顧客は不満を感じていることになります。
顧客の不満は重大事ですが、チームは業務や顧客体験の再設計ができない理由をプロジェクトにぶつけてきている場合が多々あります。
noteで綴ってきた、新しい 顧客体験を実現するためのe コマース プラットフォーム（オムニチャネルかどうかは別）の選択から実装と立ち上げまでや、プラットフォームの再構築を通じてクライアントをガイドする際に私が考えていることをいくつか紹介します。
次回のプラットフォームの再構築の不安が少しでも軽減されるよう、私がお手伝いできれば幸いです。
理由から始める
これはビジネスのどのパートでも明白な動議のはずですが、プラットフォームの再構築を実行する理由を明確に説明できないコマースストアーオーナーがいかに多いかは驚くまでもありません。
プラットフォーム再構築プロジェクトは、さまざまな観点から見て大規模な事業であり、顧客体験を再設計して、それを支えるサービス＝ワークフローを再構築するプロジェクトです。システムを更新することではありません。
時間がかかります。（本当はかけるべきではないのですが、かかります。）
プラットフォームの再構築には、チームの時間とエネルギーが多く消費されます。
私の経験では、オンライン ストアの複雑にして「しまったさ」に応じて、ほとんどのプラットフォームの再構築には 2 ～ 5 か月かかります。
企業のERPとの連携や、継ぎ足しの連携システムが多い場合は、そちらの改修も必要になると、プラットフォームの再構築には何年もかかる場合があります。
費用がかかります。（時間がかかれば、費用もかかります。システム構築費用だけではありません）
社内チームを使用するか構築パートナーと協力するかに関係なく、プラットフォームの再構築は費用のかかるプロジェクトです。
限られた予算の中にプラットフォームの再構築を詰め込もうとすると、大失敗を招くことになるため、適切なリソースを割り当てられるようにしてください。（とっても、社内調整用のコンサルタントは不要です。）
それは危険です:プラットフォームの再構築には本質的に危険が伴っています。
ほとんどのソフトウェア プロジェクトは段階的に、改修という手法でも取り組むことができますが、プラットフォームの再構築にはビッグバン移行が必要なので実施しているはずです、問題が発生する可能性が大幅に高まります。そもそも、５年とか７年とかリース、償却要因で更新するってどうなのか議論はありますが。
それは士気にも影響を及ぼします。
チーム メンバーの中には、プラットフォームの再構築により学習曲線が急峻になり、既存のワークフローに大きな混乱が生じて、さらにはキャリアの機会に対する不安 (「この新しいスキルセットにより、自分の関連性が薄れるのではないか?」) が生じることが多くあります。
そして、「この子にはこの業務があるからこのワークとシステムを無くさないで」と言われた分にはあきれて反論できません。結果数年たって見直しをすることになりますが、それまでのSaaSに限らずシステムと人的運用コストは数百から数千万になっているはずです。（これが無くなっていたかも）
すべてが危機に瀕しているため、プラットフォームを再構築する必要がある理由を明確に理解したいと考えていくべきです。
それは顧客、チーム、そしてブランドの一員である自分自身に対する義務です。
そもそも、常日頃からRFI RFPなどを積み上げて行けば良いだけなのですが、まとめてするから大変で整理がつかないなのですし、後述しますが、コンポーザブルならこんな問題は興りづらいです。
柔軟性を高めるため。
プラットフォームが常にデジタル ロードマップの実行を妨げているからプロジェクトがあるはずです、よりフィットしたベンダーやコマースシステムを探す時期が来ているということです。
データ情報や、ワークフローの改善に問題があるが、既存のシステムでは対応できない（＝更新、改修コストが身に合わない＝ＲＯＩとも）からです。
成長をサポートするために。
既存のプラットフォームが成長に苦しんでいるということでもあります。（多くの日本のカート系はそうです。）は、ブランドの長期計画をサポートする、よりスケーラブルなソリューションに切り替えることをお勧めします。
メンテナンスコストを削減するため。
多くのプラットフォーム（特にパッケージ型は、年間の保守＝実際は何もしてくれない）は、維持および実行するために、新しい設計思想のプラットフォームよりも高価になります（当たり前ですが、機能が充実して高価になっているシステムはそもそも外すべきです。外資にありがち）です。
これは、特定のメリット (追加機能での顧客体験の改善、業務効率化＝これ人件費換算でするとほぼ見合いませんなど) のために支払う許容可能なコストであるケースもあれば、正当化できないコストであるケースもあります。
新エコシステムにアクセスするため。
協力してくれるパートナーやシステム インテグレータが見つからず、そのためにビジネス目標の達成が妨げられている場合は、変更の時期が来たかもしれません。
また、プラットフォームの再構築を行う悪い理由も数多くあります。
チームが特定のスタックの経験しかない (新しいテクノロジーを学ぶことができるかも知れませんが)、
他のブランドが異なるソリューションを使用しているためチャンスを逃すのではないか
〇〇ブランドが使っているから使えばいいことがある(彼らはあなたではないのですが)、システムを変えれば、事業が成長すると思っている（ツールは何もしてくれません）
または、外部の誰かがあなたに切り替えを強く勧めます（彼らがあなたのビジネスニーズを完全に理解している可能性は低いです）。 などです。
再プラットフォームについてRFC（Request For Comments）を活用して整理することをお勧めします。
これは、動機と仮定を分析し、潜在的な代替案を評価し、プラットフォームの再構築が e コマース ストアにとって正しい選択であることを確認するためです。（この手の手法はいくらでもありますので、自分が理解しやすいものを選択してください）
RFC には、コミットメントを構築し、社内でプロジェクトの調整を行うのに役立つという追加のメリットもあります。
ベンダーを第一に考えるのではなく、ブランドを第一に考える
あたらしいコマースサービスについてチームと議論し、全員の動機が一致しました。
次の質問は、さまざまなベンダーが提供する機能をどのように比較するかということです。
現在、数十の e コマース プラットフォームから選択することができます。
最も混雑したソフトウェア カテゴリでもあります。
当たり前ですが、それらはすべて、基本的な機能のベース レイヤーと、それらを区別するための一定数の差別化要因を提供しています。
これらの差別化要因の中には、特定のニーズに役立つものもありますが、その他の差別化要因は、お客様を誘惑する単なるマーケティング戦略に過ぎません、そして、最終的には無関係であることが判明します。それも発注してから。
プラットフォームの再構築に取り組むとき、私たちは通常、ビジネス要件を 3 つのバケツ (Big Rocks、Pebbles、Sand) のいずれかに分類します。
Big Rocks:これらは主要な機能です。
これらは、ブランドの約束とビジネス モデルにとって非常に具体的です。
たとえば、メンバーシップベースのブランドの場合、No.1 の Big Rock はメンバーシップ請求機能です。（Amazonなどを想定してください。悪い慣習であれば日本の単品リピートです。）
Pebbles:重要ですが、緊急ではないタスクです。
これらの要件は重要ですが、あなたのブランドに固有のものではありません。
たとえば、ERP または 3PL の統合が挙げられます。
ほとんどのブランドでは、これらは基本的な e コマース機能にはそれほど多くの革新性はありません。
Sand:重要でも緊急でもないタスクです。
これらは、多かれ少なかれ当然のことと考えられる小さな要件です。
PDP の画像カルーセルなど、ほとんどの外観上の改善は、このカテゴリに分類されます。
マッピングを取得すると、評価しているプラットフォームが要件をどのように解決するかを理解し、分類方法に応じて各要件に優先順位を付けることができる手法です。
この段階で、検討中のベンダーに遠慮なく支援を求めてください。
彼らは自社のソリューションを知り尽くしています。ただし、彼らの主張には必ず偏見と誇大見積ががあるため、常に再確認する必要があります。
どのような場合でも、各ベンダーが主張しようとしている説明や製品に関する誇大な拡張された機能や事例の広告ではなく、実際の要件に基づいて比較するようにすることです。
e コマース ソリューションが提供する機能やアプリの数は、そのうちのごく一部しか使用しない場合、最終的には関係ありません。
テクノロジーは単なるツールです。
プラットフォームはブランドに適合する必要があり、その逆ではありません。
プラットフォームにとらわれないパートナーは、この種のプロジェクトにとって最適なパートナーです。彼らはあなたにアドバイスする専門知識を持っていますが、特定のソリューションに固執していないため、最善の道であると心から信じているものを自由に提供できます。
（と、いっても・・・・コンサルティングファームに高額のフィーを払うかは別です。）
すべての費用を負担する
プラットフォーム構築費用と月次トランザクションなどの取引手数料や保守費用は、eコマース ブランドの損益計算書の重要な部分を占めてきます。
（これには、関係する他のシステムや、決済プラットフォームのリカーリング費用も大きく変動して発生します。マーケットプレイスに展開している場合は、OMSなどの一元管理を二重にフローしていたりします。）
プラットフォームを再構築する際、不快な思いをしたくない場合は、新しい技術スタックの下で発生するコストを明確に理解する必要があります。
残念ながら、多くのブランドはここで飛びつき、初年度のプラットフォームの取引手数料など、最も明白で当面のコストのみを計上していることが多くあります。
その結果、それほど目に見えないものの同様に重要な他の変数を無視し、後戻りするには手遅れになったときに、新しく採用したベンダーによって焼き討ちにされます。（だからSaaSが言いわけではないです。そもそものアーキテクチャーが重要です。）
プラットフォームの再構築に取り組む場合、通常はコストを分類します。
ライセンス料金:
サービスへのアクセスに対してベンダーに支払う金額です。
ほとんどのブランドでは、ここには e コマース プラットフォームのコストのみが含まれていますが、必要となるサードパーティのアプリやサービスも考慮する必要があります。取引手数料:
支払いの際に支払う手数料で、通常は固定要素と変動要素があります。
一部のプラットフォームには、より低い取引手数料で支払いゲートウェイが統合されている場合もありますが、多くのプラットフォームではサードパーティとの連携が必要です。メンテナンス料金:
メンテナンスが不要な e コマース プラットフォームを使いたいと誰もが思っていますが、実際にはそうはいきません。（日本の多くのなんちゃってSaaSやカートであれば、ほぼメンテナンスは不要というかできませんからご安心を、その変わりあれ出来ないって文句を言わないでくださいね）
新しいプラットフォームで必要な設計と開発の労力を正確に計算することはできませんが、知識に基づいて推測し、どのように代替え手段や、現在のシステムでの追加コスト比較して理解する必要があります。プラットフォーム再構築の費用:
プラットフォーム再構築の実行にはどれくらいの費用がかかりますか。
同じRFPを提示しても、桁が違いすぎることがよくあります。契約後、要件定義で数倍になることはなぜ、そして、開発遅延＝開発コストの肥大化、カットオーバー後の不具合での損失、は武勇伝ではありません。
エンジニアリング支出を削減することが目標だと仮定すると、新しいプラットフォームの下でその初期投資を回収するのにどれくらい時間がかかりますか。
これらのコストを評価するときは、ブランドが成長するにつれてコストがどのように変化するのかも理解しておきたいと思います。というかベキですが。
つまり、現在の規模が 2 倍になった場合、コストはどうなるでしょうか。
価格は直線的に増加しますか、直線以上に増加しますか、それとも直線未満でしょうか。
交渉の余地はあるのでしょうか。
それともこの商業構造に永遠に縛られるのでしょうか。
新しいベンダーには最低限の約束はありますか。
機能変更・機能追加はどう実行されるのか。（これはコスト＝時間です＝長ければ機会損失です）
すべてのプラットフォームは独自のものですが、総所有コスト（TCO：Total Cost of Ownership）と各オプションに関連する長所/短所を明確に概説する同一条件で比較するように最善を尽くすことです。
段階的に仕事に取り組む
新しいプラットフォームに切り替えるには、ほぼ一夜にしてブランドを新しい技術スタックに切り替えるビッグバンリリースが必要になります。
アプローチは通常、ソフトウェア開発では嫌われます。同時に導入する変更が増えるほど、問題が発生する可能性が高くなるからです。（大手アパレルや、総合通販系での失敗事例は検索すれば山のように出てきます。）
ほとんどのプラットフォーム変更ではビッグバン リリースがある程度避けられないことです。
しかし、一方で、幸いなことには、それに伴う不確実性の量を最小限に抑えるためのアプローチがいくつかあるということです。
新しいプラットフォームへの移行を完了する前に何かできることがある場合はそうすべきとなります。
私が通常採用するいくつかのテクニックは
社内チームまたは社外パートナーと緊密に連携して、作業内容をできるだけ頻繁にデモおよびテストします。
チームが 数か月間孤立して作業し、その後一度にテストを行うことは望ましくありません。
何かを見逃したり、何もすることができなくなってから重大な問題を発見したりすることは必至です。
良い取り組みは、チーム全体に QA を実行してもらうことです。
グループで検索すると、さらに多くの情報を見つけることができることができます。
が、そもそもここまできて仕様・機能変更を言い出すから問題なのですが。再プラットフォームと互換性を持たせるために統合または外部システムに変更を加える必要がある場合は、古いスタックと新しいスタックの両方と互換性のある方法で事前に変更を適用できるかどうかを確認してください。
これが一番のコストと迷走要因です。
通常、ERP、CRM（MAや、コミュニケーションプラットフォームシステム）、POS、BI、WMS、および 3PL に当てはまりますが、他のSaaSベンダーの機能にも一般化できます。OMSや決済は実装されているでしょうから問題はないとは思いますが、OMSの無いコマースシステムもあります。事前にデータ移行をテストし、発売までの数日間は継続的に実行し続けます。
そうすれば、発売日にデータのすべてではなく、ほんの一部を移行するだけで済みます。
ポイントデータ（ロイヤリティプログラムを変更していても）や、サブスクリプションのデータはシステムによって持ち方が違うので要注意です。プラットフォームの再構築前、再構築中、再構築後に行うことのチェックリストを作成します。
発売日は非常にストレスがかかるものなので、チームが何をするかについてあまり考えすぎないようにすることが重要です。
まあーチェックしてもリリースするといろいろとバグが出てきます。それは開発をするからで、設定をベースにすればそれは多くは発生しませんし、リリースも早くなり、コストも低減されることはだれでも理解できます。
これらはほんの一部のアイデアであり、実際の効果はセットアップやアーキテクチャの複雑さによって異なります。
経験則としては、少しずつ作業を進めて、大部分の作業は事前に行う必要があるため、リリース日にトリガーを引くだけで済みます。
再設計したいという衝動に抵抗する
このnoteで伝えたいことが 1 つは。
プラットフォームの再構築と同時にブランド変更や再デザインを行わないことでください。
10 年以上、あらゆる規模の e コマース ブランドと協力してきましたが、この試みが非常に多く失敗しているのを目の当たりにしてきたため、このような行為は強くは推奨しません。
やりたい気持ちはわかります。
再設計が Replaform とバンドルされる理由はいくつかあります。
ブランドエグゼクティブのほとんどはビジュアル担当です。
プラットフォームの再構築中、彼らは当然のことながら、顧客エクスペリエンス：ＣＸに対する 数00 万もの潜在的な改善案を考え出して、それが全面的な再設計になるこがよくあります。企業ではプラットフォーム再構築のスポンサーが、ブランド変更や再設計などの具体的な成果物を通じて上司に投資を正当化することがよくあることです。
これは、誰かにそのお金はどこに消えたのか尋ねられたときに、指し示すための明確な「もの」が得られることです。（失敗しても、〇〇が利用しているシステムだから、××で成功している事例のシステムだから、▲▼の会社のシステムだから が通りやすいことも往々にしてあります。）残念ながら、一部の e コマースエージェンシーは、取り組みの範囲を拡大し、最終結果を魅力的なケーススタディに簡単に変えることができるように、プラットフォームの再設計のプロジェクトを利用して、自身のプラットフォームの再設計を行っていますのでご注意を。
これはほとんどの場合悪い考えだと誰もが気付きます。
プラットフォームの再構築は複雑でリスクが伴うため（そうしてしまいがちです。それは捨てないからです。）、その範囲をできるだけ小さく、制御する必要があります。（捨てると結果そうなります）
コマースサイトだけではなく、リアルのバックオフィスや関連するシステムの技術スタックを根絶しながら再設計しないと、公開中または公開後に問題が発生するリスクが大幅に増加します。
また、顧客エクスペリエンスに対する特定の変更がビジネスに与える影響を切り分けて測定することも大切なことです。
新しいコマースサイト、再プラットフォームを立ち上げた後は、新しい技術スタックの機能を最大限に活用する時間が十分にあるため、急ぐ必要はありません。毎日が改善です。（それができるシステムを選定するべきです。５年後まで待っている必要はありますか）
怖いものを優先する
先ほど話した分類「Big Rocks」、「Pebbles」、「Sand」を覚えていますか。
これは、ビジネス要件をマッピングするための単なる方法ではなく、再プラットフォームに含まれるさまざまな機能に優先順位を付けるときに覚えておくべき優れたメンタル モデルでもあります。
「Big Rocks」大きな岩は解決すべき最も重要な問題であり、最も高いリスクと不確実性を伴うため、できるだけ早く解決する必要があります。
「Pebbles」小石は不可欠ですが、リスクはそれほど高くありません。ビッグ ロックを完了する前ではなく、早めに実行してテストする必要があります。
「Sand」砂は無関係です。これらの機能の一部はビジネスにとって重要ですが、実装が迅速かつ簡単であり、最後に残しておくこともできます。
残念なことに、私たちは物事が逆の順序で取り組まれているのをよく見かけます。大きな岩よりも砂の上の方が先に進むのが簡単で早いため、彼らは最も簡単に達成できる成果に焦点を当て、大きな声を上げている大きくて恐ろしい問題を無視しようとします。
私たちが過去に話を聞いたあるブランドは、サブスクリプションベースですが、まだサブスクリプションのモデル変更に何も取り組んでいないまま、プラットフォーム再構築の最終週を迎えました。
最終的に、選択したプロバイダーがニーズに対応できないことがわかり、立ち上げをキャンセルして振り出しに戻らなければなりませんでした。（ここからサポートして、そのベンダーより１桁低いコストで実装して、モデルの変更テストを随時できるようにしています。）
チームの集中力を維持するには、プロダクト オーナー/プロジェクト リーダーを任命することです。
この担当者は、プロジェクト管理の経験があり（といってもそうあるはずはありません）、ブランドを徹底的に理解して、こうありたいと意識していることが理想で、プロジェクトの進捗状況を追跡し、チームが作業に適切な優先順位を付けていることを確認して、ナビゲートする責任を負います。
チームの各機能やワークフローの改善策をどんどん出させることです。それを系統、優先順位をつけて、実装、非実装、こうなったら実装、これはこうテストして実装（それまでは手動でとか）を考えて理解させることです。
ここで最後の警告です。
「完璧は善の敵」であることを忘れないでください。再デザインの場合と同様、ローンチ後もオンライン ストアを改善するための時間は十分にあり、しつつづけていきます。
そのため、大きな成果を犠牲にして小さな最適化を追求することに夢中にならないということです。
今こそ、新しい e コマース スタックの真の力を最大限に発揮できるときです。システムの設計技術が進化しているので（これはビジネス環境が数年も同じではないのでそうせざるを得ないからでもあります）固定的ではなく使いこなせるようになりました。
いつものように、意図的に行動し、データに基づいた情報を得るようにしてください。
アジャイルで柔軟なシステムマネージメントのプラクティスを確立すると、先走りして、多大なコストをかけて実装機能不活用するのではなく、実際に顧客の体験のための「針」を１つ１つスムーズに動かす機能に取り組むことができるようになり驚くべき効果（先ずは、顧客が買いやすいことから、生まれる収益）が得られます。
ブランドにとって長くて混乱を招くプロセスについて、これからも少しでも光を当てることができれば幸いです。
プラットフォームの再構築に関してさらにサポートが必要な場合は、お気軽にお声がけください。私はさまざまな e コマース プラットフォームを使用していましたし、セールスもしていました。
ブランドにとって最適な選択について喜んでアドバイスをするパートナー（ベンダー）を紹介はできます。
私が、実装と立ち上げのプロセス全体でサポートすることはその経営者やプロジェクトマネージャーの志次第になります。むしろ、私がいなくても、顧客とクライアントとそのスタッフために実装してくれるパートナーをご紹介をします。
この記事が気に入ったらサポートをしてみませんか？