店舗と中心とした従来型の販売モデルは、インターネットに代表されるコミュニケーション手段の多様化にともなって、近年大きな変動を遂げています。すなわち、店舗・電話・インターネットなど受注形態の多様化、商品の引き当て方法の複雑化、決済手段の多様化などです。
このような背景のもと、受注から始まって、出荷・配送、さらには、請求・決済にいたる業務管理プロセスを総称してフルフィルメントという言葉が用いられるようになってきました。
従来、受注、出荷、配送、請求・決済という業務は、管理プロセス的にも、システム的にも分断されていましたが、フルフィルメントという概念においては、これらの業務を統合的に管理し、単一のシステムとして運用することが重要とされています。
クラウドERPを選択する際には、フルフィルメントに関わるこれらの業務を統合的に管理する機能を確認する必要があります。
受注チャネル統合
店舗での販売や訪問営業による受注などの従来の形態に加え、電話やFAX、EDI、インターネットなど販売チャネルが増えたため、一つの商品についても多様な受注形態が存在するようになってきています。
しかし、従来型のシステムでは、販売チャネルが追加されるたびにそのビジネス・プロセスの流れに合わせてシステムを作り組み込んできたというのが実情です。この結果、特定の販売チャネルについては、アプリケーションやデータは統合されていますが、複数の販売チャネルに対しては、別々のアプリケーション、別のデータベースが存在するようになっています。
このようなシステムの状態は、結果として全体の受注状況が管理できないなど、様々な業務上の問題を引き起こします。また、システムの安定的な保守を困難にし、運用コストの増大をも招きます。
受注チャネルを大別すると、訪問営業（SFA）、店舗（POS）、通販（受注センター）、eコマース（インターネット）の４つに分かれます。これらの複数の受注システムは、ユーザーインターフェースは異なっていても、注文トランザクションの処理と受注データの管理については、統一されていなければなりません。
クラウドERPには、このような複数チャネルからの受注を統合的に処理する機能が必要です。
商品の引当
複数のチャネルからの受注を行うビジネス・モデルにおいて、商品の引き当ては複雑です。
業務プロセス及びシステムを単純化するためには、受注チャネルごとの在庫を確保するやり方が簡単ですが、そうすると、あるチャネルでは在庫が余っているのに、別のチャネルでは欠品しているという大変非効率な状況が発生します。つまり、このやり方では、不良在庫による財務的損失と欠品による機会損失という２つのマイナスを同時にかかえてしまうことになります。
したがって、複数のチャネルからの受注を行うビジネス・モデルにおいては、在庫を一元的に管理する必要があります。例えば、ECサイトでの受注が予想を大幅に上回った場合など他チャネルの受注状況を確認しながら在庫を調整するといった処理が必要となります。
クラウドERPには、このような複数チャネルからの受注に対しても、在庫を一元的に管理する機能が必要です。
また、倉庫（及びサプライヤ）が複数にまたがる場合もありえますので、この場合は受注チャネルと倉庫（及びサプライヤ）が多対多の関係となり、商品引き当ては、より複雑化します。
加えて複数の倉庫（及びサプライヤ）が存在する際には、配送料、納期の回答において、複数のパターンが存在する可能性があります。このような場合は、あらかじめ決まられた判断基準（ロジック）に従って、営業担当者、店員、オペレータなどが一定の回答を行えるようになっていなければなりません。
たとえば、東京と大阪に倉庫があって、関東からの注文には東京の倉庫の商品を引き当てるとします。しかし、東京には在庫がなくて、でも大阪には在庫がある。このときに、大阪の在庫を引き当てるのか、東京に商品が補充されるまで待つのか。こういった判断は、配送料の問題などもあり意思決定が難しく、これまではその場その場で適当に判断されたり、あるいはある特定のスタッフに任されたりすることで、非効率であり、かつ受注チャネルやタイミングによってことなる回答が行われる可能性があります。
従って、統合されたシステムの中であらかじめ定められたロジックに従って納期、配送料などの回答が行われるようにする必要があります。
クラウドERPには、複数の倉庫（及びサプライヤ）が存在する場合、そのパターンで回答するかのロジックを定義し、受注担当者が一定の回答ができるような情報を提供する機能が必要です。
発注点にもとづく自動的な定量発注
在庫を補充するための発注のやり方には、定量発注点方式と定期発注点方式の２つがあります。定量発注点方式では、あらかじめ決められた在庫量（発注点）を下回った時点で、一定の数量を発注します。定期発注点方式では、定期的に在庫の量を確認し、需要予測ななどに基づいて、その都度、数量を計算して発注を行います。この２つの方式は、以下のような商品の特性に応じて使い分けられます。
しかし、定量発注点方式は自動化しやすく、定期発注点方式に比べると発注担当者の負担が少なく、効率的なフルフィルメント業務を追及する際には、定量発注点方式が好まれます。つまり、定量発注点方式の場合、発注点に到達したかどうかは、常に発注担当者がモニタリングしておく必要がありますが、このような監視・アラートはシステムで処理することで、担当者の負荷を軽減し、発注ミスを防止することができます。また、発注量も決定しているため、担当者の承認のみで自動的に発注を行う処理も可能です。
クラウドERPには、このような発注点にもとづく自動的な定量発注を行う機能が必要です。
決済
個人消費者向けの決済手段は、近年、多様化の一途をたどっています。現時点でも、現金払い以外の主な決済手段として、以下のような多くの種類が存在します。
- )銀行振込
銀行振込は公共料金を支払う場合などに利用される決済手段で、支払金額があらかじめ記載され、支払期限までに金融機関で支払う方法です。顧客から見ると銀行振込のメリットは支払い期限内であればいつでも振込ができるといった利便性があります。一方、請求する側にとっては、振り込みの有効期限まではいつ振り込まれるかわからないことと、振り込まれても 入金を確認できるまで時間がかかるなどのデメリットがあります。 - 代金引換
代引きは、商品の発送を先に行い、代金と引換えに商品を引き渡す方法です。顧客から見ると、商品の未着を防ぐことができるので便利なシステムですが、現金を準備する手間がかかるというデメリットがあります。 - クレジットカード
クレジットカードは、利用できる加盟店で、商品の購入に際しクレジットカードを提示すると、いったんクレジットカード会社が加盟店への支払いを肩代わりし、後でカード利用者へ代金を請求する仕組みです。 - コンビニ決済
コンビニエンスストアの代金収納サービスを利用した決済方法です。商品の購入時に出力される払い込み依頼票を使ってコンビニエンスストアで代金を支払う方法と、払い込み依頼票番号のみで支払う方法（ペーパーレス）の２つの方法があります。
クラウドERPには、これら多様な決済手段に対応する機能や、決済代行サービスとのインタフェースが必要です。
フルフィルメントという概念においては、受注、出荷・配送から請求・決済に至る一連の業務を統合的に管理し、単一のシステムとして運用することが重要となります。これにより、多様な販売チャネルにより複雑化した業務を正確、迅速、かつ効率的に管理・運用できるようになります。
しかし、フルフィルメントのゴールはこれだけではありません。販売チャネルの多様化により、ある特定の顧客が、複数のチャネルを通じてアクセスしてくる可能性も増大しています。このような顧客に対しては、企業は特定のチャネル担当者だけではなく、その企業全体が、単一の顧客にたいして情報を共有し、対応していかなければなりません。
つまり、受注チャネルの統合を始めとするフルフィルメント業務のシステム化要件は、単なる業務改善・効率化の観点だけではなく、顧客満足度の向上をゴールとした顧客サービスの観点からも検討されなければなりません。従来、このような業務要件はCRM機能として、別システムとして扱われてきましたが、フルフィルメントにおいては、このような業務要件を同時に解決する必要があります。
クラウドERPを選択する際には、顧客満足度の向上を実現するためのCRM機能が統合されているかどうかを確認する必要があります。
顧客データの一元管理
販売チャネルの多様化により、ある特定の顧客が、複数のチャネルを通じてアクセスしてくる可能性も増大しています。たとえば、テレビコマーシャルや雑誌といった広告媒体を通じて商品を認知し、次に、インターネット経由で、価格や機能などの商品の情報を収集し、リアルな店舗に来店して実物を確認し、最終的にはインターネットで購入する、といったような行動をとる顧客が増大しています。
このような顧客は、アクセスするチャネルが変わっても、自分に対して一貫した対応を受けられるかどうかで、その企業に対する評価を決めてしまいます。たとえば、インターネットで一度見積もりを取った顧客が、店舗で購入を希望した際に、異なる条件で見積もりを行ってしまうと、それ自体が顧客満足度を下げる要因となってしまいます。
このような顧客に対して、競合企業と比較した場合により高い顧客満足度を獲得するためには、広告、インターネット、店舗といったチャネル単位ではなく、その企業全体が、単一の顧客にたいして情報を共有し、ひとつの企業として顧客に対応していく必要がありますが、そのためには、まず最初に顧客データの一元管理が実現されなければなりません。
クラウドERPには、複数の販売チャネルにまたがって、コンタクトが発生する顧客データを、一元的に管理し、企業全体から、単一の顧客として認識できるような顧客データ統合機能が必要です。
ケース管理
ワークフローに代表される定型化された業務プロセスの定義と自動化には、従来、BPM（ビジネスプロセス管理）という手法で対応してきました。しかし、クレーム処理に体表される、フルフィルメントにおける顧客対応の業務プロセスは、多くの場合、定型化するのが難しいため、ケース管理と呼ばれる手法で対応する必要があります。
ケース管理においては、詳細な業務ステップ（申請、承認など）を定義するのではなく、 ケースの登録、割り当て、エスカレーションといった重要な業務ステップのみを管理するかわりに、個別の詳細ステップを処理するために必要な情報を、様々な部署の担当者が、様々な手段を通じてアクセスし、場合により担当者間でコミュニケーションを取り合えるようなシステムが必要となります。
ケース管理において必要となる主な機能は以下のとおりです。
- 顧客サポートケースの担当者への自動的な割り当て
- 長期間停滞しているケースや、内容が重大であると思われるケースのエスカレーション
- 顧客サポートケース全体のなかでのプライオリティ付けを迅速かつ的確におこなうためのルーティング
- 顧客サポートケースに対応するためのEメール、電話、Faxなど、様々なチャネルのサポート
- 顧客サポートケースにおけるコミュニケーション内容の履歴管理とその内容の検索・分析
- 適切な専門担当者が対応するための、商品、問題、ケース別、パートナー、顧客それぞれに対しての割り当てとルーティング
このようなケース管理の手法を使って、顧客サポートを迅速、正確に行うことで、顧客満足度を向上させることができます。
クラウドERPの選択においては、ケース管理における、これらの主要な機能が含まれているかどうかを確認する必要です。
ナレッジベース
ナレッジベースとは、過去の顧客サポートケースの内容とその対応方法を体系的に蓄積したデータベースのことです。ナレッジベースには、FAQ、一般的な問題と解決方法、既知の問題、ヒントなど、様々な種類やレベルのコンテンツが蓄積されます。
このナレッジベースを構築・活用することで、経験豊富な専任担当者が対応できない状況でも、顧客サポートケースへの対応の内容を一定レベルに保つことができます。また、様々な部署の担当者が、様々な手段を通じてナレッジベースへアクセスできれば、顧客対応を迅速に行うことができます。さらに、ナレッジベースは、経験のない担当者に対する研修コンテンツとしても活用することができます。
さらに、このナレッジベースを次に説明するカスタマーポータルを通じて公開すると、顧客がセルフサービスでアクセスすることで、より一層、顧客への情報提供や回答を迅速化させることができます。
クラウドERPには、このようなナレッジベースを構築し、社内及び顧客に対して公開できる機能が必要です。
カスタマーポータル
従来、顧客からの様々な問い合わせには、電話、FAX、Eメールをチャネルとして、営業担当者やコールセンターのオペレータが対応してきました。しかし、最近では、顧客向けに、オンラインで、注文、支払履歴並びに配送状況などの情報を提供することにより、顧客満足度を向上させ、顧客サポートのコストを削減するためのカスタマーポータルの利用が盛んになっています。
カスタマーポータルにおいて必要となる主な機能は以下のとおりです。
- ケース番号の自動発行と、顧客への通知
- 顧客に対して、注文状況や返品承認などの情報をリアルタイムに提供
- オンラインフォームからのサポートの要請、資料請求
- ナレッジベースへのアクセス
- 顧客の属性に応じたコンテンツのカスタマイズ
このようなカスタマーポータル機能を使って、顧客がセルフサービスでサポートを受けられるようにすることで、顧客満足度を向上させることができます。
クラウドERPの選択においては、カスタマーポータルを提供するための、これらの主要な機能が含まれているかどうかを確認する必要です。
No.1 クラウドERP
ソフトウェア