【連載】業務フロー物語(2)業務の全体像を捉える

業務フロー物語

諸事情により本連載は中止となりました。

業務改善ワークショップの第1週です。業務の全体像を把握することから始めます。
細かいことを気にし過ぎると全体が見えなくなるので、ハンドオフの視点を中心にヒアリングを進めようとしています。人と人がやり取りする様子を確認しながら、業務プロセスにおける各員の役割を把握しようとしています。

対象プロセスにわかりやすい名前をつけるとすると、何がよいですか?

製品サポート依頼対応プロセス」でよいと思います

このプロセスは何をキッカケに始まりますか?
誰が最初に動きますか?

プロセスが始まるキッカケから始めて、順を追ってハンドオフが発生する状況を確認しようとしています。

顧客からの「サポート依頼」を受け付けることから始まります。
受け付けるのは顧客窓口です。

最初に依頼を受けた顧客窓口は、どのような作業を実施しますか?

まずはサポート依頼の内容を確認します。
不具合や質問の場合には「顧客がサポート契約中かどうか」を確認します。
契約中の場合は技術にサポート対応を依頼します。
契約外の場合には営業にサポート契約の提案を依頼します。

顧客からのサポート依頼が評価版利用申請の場合には、顧客窓口だけで対応します。

技術や営業に引き継いだ後に残っている作業はありますか?

ハンドオフの視点で整理するとハンドオフが生じた後の作業が漏れやすいので、主人公はこの質問を必ず聞くようにしてます。

技術や営業に引き継いだ後は、一端やることはなくなります。
次の作業は技術からのサポート対応結果を受けてからです。

ハンドオフが生じた後に引き続き行う残作業がないので、ここまでの作業を1つのアクティビティとします。
具体的には、サポート依頼内容の確認、サポート契約有無の確認、技術・営業への依頼、評価版利用申請対応、それら全てをまとめて1つにします。

サポート対応結果を受けた後の話は、後ほど教えてください。

顧客窓口からのサポート依頼を受けて、技術では何を行いますか?

不具合の場合は、不具合調査を実施して調査結果を顧客窓口に伝えます。
質問の場合は、質問回答を作成して同じく顧客窓口に伝えます。

顧客への回答は顧客窓口が担うということですね。
顧客窓口に引き継いだ後に残っている作業はありますか?

不具合の場合は、さらに不具合内容を精査して不具合管理システムに登録しています。
登録した不具合は、製品改良のために利用されます。
質問の場合は、質問データベースに登録します。

製品改良の業務は最近改善活動を実施したと聞いています。
今回の業務分析の対象外としようと思いますが、何か気になることはありますか?

業務分析の対象範囲をどこまでとするかを考えながらヒアリングしています。
対象外の業務の流れは別プロセスとします。業務フローを描くときはブラックボックスプール(中身を描かないプール)としても大丈夫です。

製品改良に関する問題は、この前の改善活動で解決済みと考えて大丈夫です。

では次に営業担当の作業内容について教えてください。

顧客窓口から依頼を受けたら、その顧客にサポート契約を提案します。
提案の結果、契約を締結できたら技術担当サポート対応を依頼します。
契約の意思がない場合には、顧客にサポート依頼に対応できない旨を通知します。

技術担当にサポート対応を依頼した後にも作業が残っていますか?

残っている作業はありません。

技術担当の方に伺います。営業からサポート依頼を受けて場合も先ほど確認した作業を実施すると考えてよいですか?

はい。
顧客窓口からの依頼でも、営業からの依頼でも扱いは一緒です。

顧客窓口の方に伺います。
技術担当からサポート依頼対応結果を受け取った後にどのような作業をしますか?

サポート依頼対応結果を顧客に伝えて終わりです。

本日確認したかったことは以上です。
ありがとうございました。

以上のヒアリング内容をもとに業務フローを描いてみてください。
次回は、主人公が描いた業務フローのレビューから始まります。