各タスクの順序経路を決める – ビジネスプロセス モデリング の鉄則（4）

「ビジネスプロセスの　“見える化”　を、少しずつでも推進したい」
「究極の　“あるべき業務フロー”　を、徹底的に議論したい」

改善規模の大小を問わず、ビジネスプロセス改善の議論は容易ではありません。実際、議論自体が発散したり、決定事項が曖昧になったりと、手間の割に得るものが少ないと感じた経験を持つ方も多い事でしょう。では、どの様な順序でビジネスプロセスを定義して行けば良いのでしょうか。

本稿では、ホワイトカラーのビジネスプロセスを効率良く定義して行く方法について記述します。

並行処理も検討すべし！

ビジネスプロセスの「キッカケ（開始）」と「成果物（終了）」さらにはビジネスプロセスを構成する「タスク」が定義されれば、およそビジネスプロセスの概要は想定されている事と思います。

最後は、各タスクの順序や経路を決めます。

順序や経路を議論する上で、常に検討すべき事は、

• タスク滞留の発生確率を低減する
• タスク待ちの発生確率を低減する
• リスクの発生を検証する

などです。ただ実際問題、ビジネスプロセスを運用する前に論理的に改善方法を検討するより、実際にビジネスプロセスを運用し実際に発生した（発生してしまった）問題に対処する経験的改善の方が有効である事は確かでしょう。

なお、あまり実現されるケースは多くありませんが、多くの課題に対して意外と有効な手法に、「並行処理化」が挙げられます。たとえば、制作チームメンバの複数人が「内部工数見積タスク」をそれぞれ独立して対処することで、それらを平均化して「より確からしい見積内部工数」を実現する事が出来ます。あるいは、一人の見積担当者が中々見積もり作業に着手できない場合でも、期限に間に合う見積があれば見積内部工数を決定でき、クリティカルな滞留を回避する事が出来ます。

ショートカットも設置すべし！

ビジネスプロセスを運用すると、必ずと言って良いほど発生する問題に「放置」があります。「滞留」と同義と言っても良いかも知れませんが、「放置」はタスクを処理する意味がなくなった状態を指します。

原因は実に様々で、組織によっても傾向が異なりますが、多く見受けられるケースとして「締切問題」が挙げられます。すなわち、完了させようと思って開始したプロセスも、実際にビジネスプロセス定義に従って流れている途中で締切が迫り、定義通りには進められなくなるようなケースです。たとえば、すでに提出済みの提案書を「リーダチェック」に回す意味はありません。

この様な時間制約のあるケースにおいては、逐一プロセスを中途終了させ作業指示を行うより、想定経路として途中タスクを飛ばすルートを定義しておく事が極めて有効です。

他のビジネスプロセスとの共通化を検討すべし！

たとえば、「有給休暇申請」と「長期休暇申請」を別々のビジネスプロセスとして定義する必要性は極めて低いと言えます。
申請事項に多少の違いがあったとしても、同じ様な流れ方、同じ様なタスクの数であれば、「有給休暇申請ならびに長期休暇申請」として一体化して定義する方が合理的です。また何より、年に数度しか利用しない申請者の立場に立って考えれば、一つのビジネスプロセス定義で、もっと多くの申請が出来る方が有難いでしょう。

現実問題として、データの閲覧権限や、過去データの検索性を考察するまでもなく、闇雲に共通化・汎用化を推し進めるべきではありません。ただ少なくとも、新たなビジネスプロセスを検討する際には、既存のビジネスプロセスを確認把握しておく必要があると言えます。

運用目標を設定すべし！

ビジネスプロセスは実際、その運用後に定義変更を余儀なくされる事が少なくありません。ただ、その改善活動が目指すべきものとして、「あるべき成果物のQCDや完了件数」を常に把握し、組織内で共有したい所です。

たとえば、

• 「週次10件」の提案書を完成させるにはどうしたら良いか
• 「成約率60%」を実現する提案書品質を保つにはどうしたら良いか

と言う議論の中で、「ヒアリングシート作成後、1週間以内に提案書を完成させてみよう」、と言う「新たな目標」が生まれるかも知れません。

ビジネスプロセスの定義は、BPM活動（ビジネスプロセスマネジメント活動）の中でもっとも重要な活動です。実行時のKPIを十分に見越した設計が期待されるでしょう。

〔完〕