↗付きの用語リンクは、別タブで説明を開きます。
複数のECモールや自社ECを運営すると、受注内容の確認、伝票の書き換え、配送方法の振り分け、注文の分割など、受注後の定型作業が増えていきます。作業を自動化すると処理時間を減らせる可能性がありますが、通常注文だけを基準に設定すると、予約、欠品、温度帯、複数倉庫などの例外で手戻りが起こります。
e.canは、ネクストエンジンの受注伝票に対する確認・更新などを、設定したルールに沿って自動化するサービスです。本記事では公開されている公式情報をもとに、主な機能と導入前に整理したい業務を解説します。MO-LIBでの実利用成果を紹介する記事ではなく、比較・検討時の確認項目としてまとめています。
e.canとは
e.canは、ネクストエンジン上の受注伝票を対象に、条件判定と更新処理を組み合わせて受注業務を自動化するサービスです。プログラムを開発せずに条件や処理内容を設定でき、伝票の分割や処理対象の振り分けなどにも対応すると案内されています。
対応機能、利用条件、現在の料金は変更される可能性があります。検討時はe.can公式サイトで最新情報を確認してください。
e.canとOMSの役割を分けて考える
e.canだけで、商品、在庫、受注、出荷、顧客対応のすべてを管理するわけではありません。ネクストエンジンに集まった受注伝票へ、自社のルールに沿った処理を加える位置づけとして考えると整理しやすくなります。
| 領域 | 主な役割 | 確認したいこと |
|---|---|---|
| 販売チャネル | 注文を受け付ける | モール・カートごとの項目やステータス差 |
| ネクストエンジン | 複数チャネルの受注・在庫等を管理する | 連携範囲、伝票項目、受注ステータス |
| e.can | 受注伝票を条件に沿って確認・更新する | 実行条件、更新内容、優先順位、例外時の停止 |
| 倉庫・配送 | 出荷指示を受け、商品を発送する | 温度帯、倉庫、配送方法、同梱・分割のルール |
OMS全体の比較はEC一元管理システム比較も参考にしてください。
公式情報から確認できる主な機能
条件と更新内容を組み合わせる
注文内容や伝票の状態などを条件として、確認・更新する内容を設定します。定型処理をルールへ置き換えられる一方で、どの項目を基準にするか、複数ルールが重なったときにどちらを優先するかを決める必要があります。
伝票を分割する
温度帯、出荷倉庫、注文数などの条件に応じて伝票を分割する機能が案内されています。冷蔵と常温、別倉庫、納期の異なる商品を扱う場合は、送料、決済、ポイント、購入者への通知が分割後にどう扱われるかまで確認します。
処理対象を振り分ける
自動処理の対象にする注文と、人が確認する注文を分ける考え方が重要です。すべてを自動化するのではなく、判断材料が不足している注文や高額注文などを確認対象として残す方法もあります。
実行する時間を設定する
処理の実行時間を設定できる場合、モールからの受注取込、在庫更新、倉庫への出荷指示、購入者への通知と順序が競合しないようにします。締め時刻や休日運用も含めて設計します。
導入前に整理したい例外処理
| 例外 | 確認すること |
|---|---|
| 予約・取り寄せ | 通常商品との同時注文、在庫確保、出荷時期 |
| 欠品・在庫差異 | 自動処理を止める条件、連絡、キャンセル、在庫戻し |
| 温度帯・複数倉庫 | 分割条件、送料、配送会社、伝票番号、通知 |
| 同梱・注文分割 | 決済、ポイント、モール側ステータス、購入者表示 |
| 住所変更・キャンセル | 変更可能な時点、倉庫連携後の扱い、返金 |
| API・連携エラー | 再実行、重複処理の防止、担当者への通知 |
具体的な整理方法は、複数モール運営でシステム導入前に整理する例外処理でも解説しています。
導入判断で確認したい7項目
- 対象業務：現在の作業のうち、どこからどこまでを自動化するか。
- 正本となる項目：商品、在庫、配送、顧客情報をどのシステムで確定するか。
- ルールの優先順位：複数条件が一致した場合や、既存の自動処理と重なった場合の順序。
- 例外時の停止方法：自動処理しない条件と、人が確認するステータス。
- テスト方法：本番注文へ適用する前に、通常・例外のテスト伝票で確認できるか。
- 記録と復旧：実行履歴、エラー内容、再実行、元へ戻す手順を確認できるか。
- 運用担当：ルールを作る人、承認する人、エラーへ対応する人が決まっているか。
導入は一つの処理から始める
最初からすべての伝票を自動化するより、条件が明確で発生件数の多い一つの処理を選び、テスト伝票で確認してから対象を広げる方が安全です。通常注文だけでなく、対象外となる注文が正しく止まることも確認します。
確認後は、処理時間、手作業件数、エラー件数、差し戻し件数を記録します。作業時間が減っても確認や復旧が増えている場合は、条件を見直します。
運用体制による違い
少人数の運営では、複雑な条件を増やしすぎると担当者しか修正できない状態になりやすいため、ルール名、目的、対象、更新項目、停止条件を一覧へ残します。複数部門や外部倉庫が関わる場合は、受注、在庫、出荷、顧客対応の境界と、エラー発生時の連絡先を決めます。
既にネクストエンジン側の自動処理や別の連携ツールを使っている場合は、同じ項目を複数の仕組みが更新しないよう、現在の設定を棚卸ししてから追加します。
まとめ
e.canは、ネクストエンジンの受注伝票を条件に沿って処理し、定型業務を自動化する選択肢です。導入時は機能の有無だけでなく、対象業務、例外処理、実行順序、テスト、復旧、担当体制まで整理する必要があります。
自動化の効果は注文内容や運用体制によって異なります。一つの処理で安全性を確認し、記録を見ながら対象範囲を広げることが、安定した運用につながります。
