ECサイトへの拡張
実店舗を複数展開している会社や、電話やFAXでの通信販売を行っていたような会社が新たにネットショップ（ECサイト）を立ち上げる場合、既に物流のシステムが稼働している場合がほとんどかと思います。ネットショップに最初から本腰を入れる場合であればその既存のシステムへの接続前提で構築すると思いますが、まずは様子見、ということでネットショップだけで単独で構築する場合も多いのではないでしょうか。
ネットショップの事業が成長し業務量が増えてくると、遅かれ早かれシステム統合の話がでてきます。とはいえ無用の混乱を避けるためにも、システムの改造範囲は最小限にとどめたいところ。大規模にやってしまうと、万が一うまくいかなかった場合の損害が大きくなる可能性があります。そこで現実的になってくるのがネットショップのシステムと物流のシステムの双方を橋渡しするシステムもしくはプログラムの開発です。いわば両方の仕組みを動かしながら、うまく間をとりもって必要なデータをやり取りするための仕組みです。
今回のテーマはこのネットショップと物流側のシステムを結ぶ橋渡しのシステムです。リスクとコストを最小化するために、要所に絞った改造を行い、両方のシステムをスムーズに連携させるためにはどうすればよいのか。いくつかのポイントに分けて考えてみたいと思います。
Point.1 物流システム側のフォーマットに沿って定時出力
両方のシステムをつなぐデータファイルは物流システムの仕様にもよりますが、CSV形式のファイルでやり取りすることが多いのではないでしょうか。そもそも物流側のシステムにそういったファイルで一括取り込みを行うような機能がない場合はそれを開発するか、プログラムを拡張してデータベースとやり取りできるようにする必要があります。
物流側のシステムが受け止める準備ができている前提で、ネットショップ側のシステムを拡張するか、もしくは同じデータベースにアクセスできるシステムを新しく設置します。一定期間の受注を抜き出し、CSVファイル形式に出力する部分があれば、まずは最低限の部分は完成します。あとはこれを1日の締め時間にあわせて定時実行するか、スタッフによる手動実行、または物流システム側からの自動ダウンロードといったかたちで物流システムへ取り込みます。
より高頻度に行いたい場合は、5分に1度など、取り込み頻度を設定できるようにするのも良いと思います。あまり高頻度である必要はないと思いますが、1日に何度も出荷作業を行う場合には、ある程度の頻度を担保するのが有効です。情報更新が失敗した場合も想定して、データ更新によって双方のデータがおかしくならないような設計にする必要もあるでしょう。
Point.2 出荷完了メールは自動送信
取り込んだ後の流れは在庫の引き当てから出荷までは通常と同じですが、問い合わせ番号を最終的にネットショップ側に返す必要があります。それもCSVファイル形式でやり取りし、出荷業務完了後に所定の画面からアップロードし、今度はネットショップ側のシステムに取り込みます。後は顧客対応担当が問い合わせ番号をメール送信して終了です。この出荷完了メールも自動化が可能なので、業務効率化を図るのであればあわせて開発します。
もちろん、備考で問い合わせをしてきた顧客や、何かしら伝達事項のある場合などは簡単にその顧客を送信対象から除外できるようにします。このように自動化しつつも柔軟にしておくことで、イレギュラーな対応時に余計な時間がかかることを防止します。顧客対応のスタッフを無くすための仕組みというよりは、顧客対応のスタッフが少人数でも手厚いサポートを行えるようにするための仕組みという考え方で取り組むほうが、結果が良くなる場合が多いと思います。
Point.3 最終的にはリアルタイム割当
コストを抑えるのであれば決められた時間にまとめてデータをやり取りするバッチ処理型の流れですが、さらに進んだかたちを目指すのであれば、リアルタイムにデータを橋渡しし、ネットショップ側で注文があった時点で物流側にデータ送信、在庫の割当を行うことも考えられます。これにより、在庫が引き当てられなかったといったエラーを防ぐことができますし、より締め時間ぎりぎりまで当日出荷注文を受け付けたり、分や秒単位などのより細かい単位での納期表示が行えるようになったりします。これはすべてネットショップにとっては非常に強力な機能です。
ネットショップ以外に在庫をとりあうチャネルがある場合はこうしたリアルタイム連携が現実的になってきます。ネットショップ側でのキャンセル処理や数量変更処理があった場合などの複数のケースを想定してシステムを開発しないといけないため工数は大きくなりますが、一度完成してしまえば、ネットショップ側のシステムを大きく変更することがない限り長く活用できます。
在庫割当の変更ができなくなる時間などの社内ルール決めは必要ですが、そういったルールに従って顧客対応からシステム開発まで行えば大きな混乱なく導入が可能です。難易度があがるかわりに、強力なアピール機能にもなり得るでしょう。
現実的な最適解を
システム統合の話は究極のところ、全てを統合する新しいシステムを作るのが理想ではあります。とはいえ、コストは跳ね上がりますし、期間もかかり、さらにはバグが続出して使い物にならないというのはよくある話です。
現実的には少しずつ既存システムを改良したり拡張したりを繰り返しながら、結果的に新しい機能をもったシステムに生まれ変わらせていくというのが主流ではないでしょうか。そしてその改良を高いレベルで行うことができれば、それが現実的な最適解になるのだと思います。
物流システムの仕様も多彩ですしネットショップの仕様も多彩です。自社のシステムでどういった現実解があるのか是非模索してみてください。悩まれた際にはお気軽にご相談ください。
開発スタッフのコメント
