EC業界の変化への追従や、自社固有のビジネス要件を叶えるためにはカスタマイズが求められます。
カスタマイズは画面の変更やサーバーサイドの処理、バックオフィスの自動化など多くが求められるようになります。その際には、コストをおさえや拡張していくような柔軟性が求められます。
本物のクラウドでは、「カスタマイズをしても製品のアップデートが可能」というようにカスタマイズの柔軟性と製品のアップデートを両立させる必要があります。また、カスタマイズをしても大きなコストがかからないような仕組みになっていることも重要です。
従来のパッケージシステムと本物のクラウドECシステムの違い
従来のパッケージシステムだと、「一度カスタマイズをしてしまうとアップデートできない」という問題点がありましたが、本物のクラウドのECシステムだとAPIとの連携部分をカスタマイズすることによって、プロダクトを直接カスタマイズしなくても、APIとの連携後にカスタマイズできるようになります。
この特徴による最大のメリットは、製品に手を入れずにカスタマイズできるようになるので、製品側がアップデートしても、カスタマイズ側には問題がないという形を取ることが出来ます。
次にCommerbleの主な特徴を説明します。
デザインとデータ定義が自由な高機能CMSを装備
画面を表示、編集する機能をCMSと呼びます。まず、このCMSが機能としてあるか、どのような機能を備えたCMSかは重要なポイントになります。
●制限のない自由なテンプレート機能
Commerbleの場合、画面を表示するデザイン(HTML、CSS、JS)はCMSの内部にテンプレートとして管理されており、テンプレートの改変に関する制限はありません。 テンプレートはHTMLをベースに記述します。サイトのTOP、商品⼀覧、商品詳細等多種多様なテンプレートを作ることができますが、その際デザインの制限はありません。そのため、各社自分達の理想とするサイトの見た目を構築することが出来ます。見た目の部分については、導入事例 から例を確認することが可能です。
●制限のない自由なデータ構造
表示するデータは、例えば、商品の情報についてもテナントの特性に合わせて⾃由に組み⽴てることが出来ます。項⽬の増減はもちろん、関連するテーブルとのデータ定義も⾃由に設定できます。
カテゴリ構造、記事などコンテンツ情報、店舗の情報、その他独自情報も自由に定義して扱うことが出来ます。特集ページや記事コンテンツの定義も⾃由に設定できます。実店舗のデータ定義や、その他サイトの特徴に合わせて定義するデータも⾃由に組み⽴てることが出来ます。そのため、通常のECでは扱わないような情報も拡張して表示することが可能です。
●動的な情報をテンプレートに表示するには
テンプレートに検索結果の商品を表示したり、レコメンドなどの動的な部分を表示するために、サーバーサイドの言語としてRazorを利用します。
●コマーブルからコマーブルへのリニューアルも
サービスインして6年が経過しましたが、コマーブルからコマーブルへのリニューアルと言う形も事例としてよくあるようになってきました。
「データの定義やバックオフィスの業務は変わらないけど、⾒た⽬を新しくしたい」「データの定義と見た目を新しくしたい」という場合にも、ECシステムを作り直す必要はありません。フロントのCMSの改修だけで対応可能です。
柔軟で拡張性に優れたAPI
Commerble内で保有するすべてのデータにAPIが備わっています。webAPIはoData形式で柔軟に利用することが可能です。APIから取得、更新するデータは、バッチや管理画面など様々な場所で利用することが可能です。
詳しくは、COMMERBLE DOCS Web APIをご覧ください。
●業務フローの自動化を実現するバッチ
WMS側で出荷が行われた際のメール送信や決済の確定処理、注文がキャンセルされた際の決済キャンセル処理、これらを人力ではなく自動化するにはバッチが必要です。
●管理サイトの見た目や機能も柔軟に変更可能
また、API利用で管理サイトのUIも変更することができます。最大公約数的に作られた標準管理画面では業務の生産性が上がらなかったり、受注業務でEC以外の固有の情報(基幹システムの情報やその他固有の追加情報)も同時に扱いたい場合など、見た目と取得するデータを個別にカスタマイズ可能です。
他にも、管理画面のダッシュボードにPowerBIを利用したレポートの表示ができます。自社の業務に最適にフィットした管理画面を使い続けることが出来ます。
パイプライン
パイプラインとは、処理の工程です。標準の処理は実装されているため、初めから全部作る必要がありません。
テナント固有のカスタムの処理は、パイプラインに追加することができるので、柔軟に要求に対応できます
詳しくは、COMMERBLE DOCS パイプラインをご覧ください。
ミドルウェア層、OS層、ハードウェア層
本物のクラウドCommerbleでは、OS層以下のメンテナンスはCommerble側で行うため、お客様が意識する必要はありません。また、冗長化しているため、サービス停止時間無しで随時更新しております。
他の実現手段との比較
・ASP,SaaSので構築した場合
一般的にある機能をそのまま使うか、アプリストアがある場合はそちらにある機能を有償で利用します。そのため、自社に完全にフィットしたものを作るというのは難しいです。ただし、ECを始めた直後の段階で知識が足りない場合は、まずあるものを使って知見を得ていくという形では望ましいでしょう。
・パッケージ製品で構築した場合
カスタマイズの柔軟性は比較的あると言えますが、カスタマイズによってパッケージ製品のアップデートができなくなることが問題なのと、自分達でインフラの管理をしなくてはならないという点でコストや手間が多く発生します。自称クラウドの場合は、製品にもよると思いますが、「カスタマイズ内容とアップデートの関係性」「インフラの制限(負荷対策やインフラのカスタマイズ)」について、Commerbleと比較してみると良いでしょう。
まとめ
このように本物のクラウドCommerbleでは、柔軟なカスタマイズを可能にしつつ、継続的にアップデート可能でインフラを意識しなくてよいという、継続的に成長、更新可能なECシステムを提供するための機能が備わっています。より詳細な情報は、Commerble DOCSをご覧ください。