ECサイトを適切にリプレイス・リニューアルすることが、
今後のビジネスの成否を分けるといっても過言ではありません。

ECサイトリプレイス・リニューアルのステップ

これまでECサイトのリプレイス・リニューアルの理由として多くあげられていたのは、システムの経年による機能不足の露呈、新たな業務への対応性の低下、システムの最新化ニーズなど、どちらかと言えばネガティブで、現状の問題を改善したい内容がほとんどでした。
しかし、今求められているECのビジネスモデルは、在来の「改善型」のリプレイス・リニューアルでは達成することが困難です。
リニューアルの機能要求水準を既存システムの改善に振り切った場合、多くのケースで失敗してしまいます。

EC-ORANGEでは、主に以下のステップでECサイトリプレイス・リニューアルの検討、システム開発を実施しています。

ステップ1ビジネスプロセスの再設計

ECサイトは単にモノを売るための場所から、デジタルチャネルのコミュニケーションのコアへと変化し続けています。そのため、OMOやオムニチャネルなどの全社的なアプローチが必要となるケースが多く見られます。

EC-ORANGEは、潮流の変化にいち早く対応し、ECサイトのあり方や期待される効果などが大きく変化する状況に対して優位性の高いシステムコンセプトで対応を行うことが可能です。また、弊社が提供しているコンサルティング、プロダクトを活用したサービス開発支援などと組み合わせ、複雑な業務プロセスを解読し、正しいビジネスプロセスの立案までご協力することが可能です。

ステップ2業務フローの整理と再設計

自社システムや外部システムを含め、どのような業務フロー・業務プロセスを実現するべきか、どのような業務を実現するシステムとしていくべきか、などの課題を解決していく必要性があります。特に、ECシステムのリプレイス・リニューアルに伴う自社システムとの連携内容の変更や、外部システムとの新たな連携など、どのシステムと、どのタイミングで、どのようにデータを処理するのかを緻密に検討を進めていく必要性があります。

かつて、ECがシンプルだった時代では、購買の完了とともにチェックアウト情報が流れ、在庫が引き当てられ、配送する、という極めて簡単な構成でした。しかし、オムニチャネルやOMOなどの次世代の購買システムが必要となった現在、業務全体のプロセスの再設計、ワークフローの精緻化が必要です。

EC-ORANGEでは、数多くのお客様のECサイト、オムニチャネルシステム、関連するPoC導入などの経験を通じて、最適な業務フローの設計・業務プロセスの設計・ECサイトのリプレイス計画の立案などを実施する事が可能です。

ステップ3業務要件の立案

システム化を行うためにはシステム要件定義が必要ですが、その前段階として業務要件を確定させる必要があります。
前述のとおり、オムニチャネル化、OMO化が進んだシステムでは、検討の範囲が広くなるばかりではなく、その複雑性も大きく増加しています。このため、業務要件を明確に定義できなければ、その後のシステム実装においても明確に出来ない機能などが生じ、プロジェクト全体へ大きな課題を生じさせることがあります。

複雑化したオムニチャネルシステムの時代において、業務全体を正しく把握する必要性

既存業務だけではなく、新たに発生する業務についても正しく予測し、正しく手当が出来るよう用意を行うことが必要です。
既存業務の「改善型」で業務要件を定義していく場合には、既存課題の解決だけが担保されていればよいケースが大半ですが、新しい概念に基づく設計の場合は、リスクや業務要件そのものに変更を加えることを見据えて柔軟に設計できるようにしておく必要があります。

業務が複雑化しているからこそ、ベンダーがノウハウを持っていることが重要

オムニチャネル、OMOなどの仕組みやシステムを導入することで、業務要件がどのように変更され現時点の業務が変わっていくのかを、ベンダー側がある程度以上サポートできる体制がなければ、プロジェクトはリリース後に課題を抱える可能性が高くなります。
EC-ORANGEでは、これまでに数多くのEC/オムニチャネル/OMOの導入経験があり、様々な業務要件のノウハウを集積しています。導入後の業務要件に関わる課題を予め指摘共有し、より安全なリプレイス・リニューアルプロジェクトの推進が可能です。

ステップ4導入・移行計画の立案

リプレイス・リニューアルプロジェクトにおいて、ECシステムの構築やECサイト構築に関わる導入計画は重要ですが、それ以上に、現行システムから新システムへの移行計画の立案、周知徹底、実行が重要になります。
特に、オムニチャネルシステムなどを新規導入する場合には、既存ECシステムだけではなく、顧客管理システム、店舗で利用されているPOSシステム、その他業務管理システムとの連携も必要です。これらのシステム全体を俯瞰し、リプレイス後のシステム移行、業務移行計画を立てていく必要があります。

ECシステムの統括する範囲が広がったため、多段階的な判断が求められるようになってきています。

• ECシステムだけのリプレイスではなく、サブシステムも含めた移行計画を立案する必要がある
• 場合によっては、業務実施方法の移行なども必要であり、拠点毎、業務毎の多段階移行が発生する
• 平行稼働の場合、どのような業務段階の達成をもって全移行を実施するのか判断が必要

EC-ORANGEでは、システムソースがオープンである特色を生かし、サイト構築をマルチベンダー体制で実行しすることが可能です。構築時の省力化を実現できるばかりではなく、後に必須であるデータ移行や業務移行などの作業にも大きな効果を発揮します。例えば、構築ベンダーと移行ベンダーを別のベンダーとした場合、機能開発の平行開発だけではなく、移行計画を含めたプロジェクト全体をパラレルで進行する事も可能です。(※)
これらのシステム的なバックボーンに基づき、より適切な移行実行が可能となります。
※特定の業務整理や設計が終わっていることが前提条件となります