注文を受けると、「セールス」がプロセスを開始し注文内容を入力します(1. 注文情報入力)。次に「業務」が入力の内容を確認します。NGであればセールスにタスクを戻して訂正してもらいます。問題がなければ、在庫引き当てを行います(2. 在庫引き当て)。引き当てがされた後、セールスが顧客に納期を通知します(3. 納期通知)。
提示した納期に対する顧客の回答をセールスが入力します(4. 納期顧客了解受信)。返答がNoだった場合、業務が在庫引き当てを解除し(5b. 引当解除)、プロセスは終了します。回答がOKだった場合は、業務が商品を発送(5. 発送完了)し、「経理」が請求書を送付します(6. 請求)。
商品発送後は、セールスが顧客からの返品があるか待ちます(7. 返品対応期間)。返品期間内に返品が無ければプロセスは終了します。返品があった場合には、業務が返品対応を行い(8. 返品確認)、経理が返金処理を行い(9. 返金処理)、プロセスは終了します。
顧客からの注文を受けて商品を発送する業務を、「納期提示の上で注文を受け付けるシステム」の導入により変更したものです。
今回は、注文は外部システムにて納期提示の上で受け付けます。そのため、プロセスは外部システムから自動で開始され、納期も提示済みなので注文確定状態で受け付けます(1. 注文確定)。
注文を受け付けると、「セールス」には注文があったことが通知されます(2a. 確認)。またそれと並行して、「業務」には発送作業の依頼(2b. 発送完了)、経理には請求処理の準備作業の依頼(2c. 請求準備)が行われます。発送作業が完了すると、経理に請求書の送付が依頼されます(3c. 請求)。
セールスが返品を待ち(3a. 返品対応期間)、期間が経過すればプロセス終了、返品があれば業務に返品確認が依頼され(8. 返品確認)、経理に返金処理が依頼されます(9. 返金処理)。
注文が入ってからの業務の流れをBPMで実現しましたが、注文をどのような仕組みで受けるかで結果的にプロセスが大きく変わりました。
最初のプロセスの業務の流れは理解しやすく、おそらく業務実施においてもミスの発生も少ないでしょう。また、「在庫引き当てしたが注文が取れなかった率」や「返品率」も簡単かつ正確に集計できます。
後者のプロセスは納期を提示して注文を受け付けるシステムを導入した場合でした。業務は全体としてシンプルになりましたが、特にセールスでは業務内容が大きく変わりました。このように業務の一部を変更する事で、業務全体に様々な変更が生じることがあります。
業務を効率化するつもりでシステムを導入した、しかし導入してみると予想外に業務の変更が必要になり現場が混乱した、あるいは従来の業務システムに大幅改修が必要だとわかり困った、そういうことも起こるかもしれません。
BPMならば必要に応じて業務を作り変えることができます。業務を改善し続けるだけでなく、システムの導入や変更のような様々な変化にも対応することができます。
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License
本記事のサンプルは ワークフローサンプル様の
受注プロセスは「最上流タスク」次第で大きく変わる を元にしております。
ダウンロード&インポートで、記事で紹介したプロセスフローをすぐに利用できます。
業務プロセスのモデル化から業務の進捗、処理状況、ボトルネックまでPDCAに必要な要素をすべて「見える化」ビジネスプロセスの最適解を導く
お気軽に製品の機能を体験いただける「DataSpider BPM」の無償評価版をご用意。
評価版のご案内