「ビジネスプロセスの “見える化” を、少しずつでも推進したい」
「究極の “あるべき業務フロー” を、徹底的に議論したい」
改善規模の大小を問わず、ビジネスプロセス改善の議論は容易ではありません。実際、議論自体が発散したり、決定事項が曖昧になったりと、手間の割に得るものが少ないと感じた経験を持つ方も多い事でしょう。では、どの様な順序でビジネスプロセスを定義して行けば良いのでしょうか。
本稿では、ホワイトカラーのビジネスプロセスを効率良く定義して行く方法について記述します。
まずはリーダ開始で運用すべし！
ビジネスプロセスの成果物（最終出力）や、その想定QCDが設定されれば、次は「キッカケ」を議論する事が有効です。
「成果物（最終出力）」がビジネスプロセスにとっての終了条件であるのとは対照的に、「キッカケ」は開始条件です。しかし実際、「プロセスを開始させるキッカケ」については意外と議論されない傾向にあります。
確かに、たとえば組織外部からの問い合わせに対応するプロセスや、組織外部から受け付けた申請を処理するプロセスなどでは、あまり議論する必要がありません。これらは、多くの場合「受動的に開始されているプロセス」と言っても良く、開始しないと言う選択肢が無いケースがほとんどです。
ただ他方、「提案書を提出するプロセス」は、組織としては「能動的に開始させるプロセス」です。たとえば「A社向け提案書」と言う成果物をイメージした時、そのプロセスを開始させるべき人は様々な選択肢が考えられます。
- A社担当のセールスメンバ
- 営業を統括するセールスリーダ
- あるいは会議を開いて多数決で決める
かも知れません。
ビジネスプロセスを運用するにあたっては、まずは「安定して週次10件の提案書が完成する事」を目指したい所です。その場合、リーダが提案書を作成するべき案件を10件選択し、組織内に対してそれらの作成を指示する形で、「提案書作成業務」を起動する形が有効だと言えます。
メンバ開始も検討すべし！
しかし当然ながら、リーダ指示が無ければ提案書が完成しないと言うルールには、少なからず問題があります。例えば、顧客要望のヒアリングを実際に担当したセールスメンバからすれば、「一日も早く提案書作成に着手したい」と考えることでしょう。ヒアリングシートを作成している時点で、とても素晴らしい提案を思い浮かんでいるケース等では、ビジネスプロセスやルールがどうあれ、リーダの指示を待っていられません。
プロセスオーナーは
- ビジネスプロセスの特性
- 組織の成熟度
- 事業進捗度
等を総合的に勘案して、誰がプロセス開始（起動）出来るのか、を決定する必要があります。機動的なビジネスプロセスを実現するために、「メンバがプロセスが起動するルール」に改める必要があるかも知れません。
開始パターンを複数用意すべし！
組織の中には、自ら進んで仕事を生み出す事が得意な人もいれば、上司などの指示を受けて仕事をこなす事で大きな貢献をする人もいます。現実問題として、プロセスを起動できる権限を「リーダだけ」、「メンバだけ」のどちらかに限定できないケースが多く存在します。その様な場合、両者ともに開始できるビジネスプロセスを定義する事が有効です。
しかし、例えば「提案書作成業務」と言うビジネスプロセスの例では、「概算見積」や「提案実現性の判断」など、セールスチーム以外が担当するタスクも想定されます（上図では「３．概算レビュー」に相当）。各セールスメンバが思いついた提案の数だけ制作チームのリソースを消費して良いものか、議論の余地があります。
仮に「見積書作成業務」と言うビジネスプロセスを考えれば、さらに「詳細な見積」や、「要因リソースの確保（アサイン）」など、制作チームのリソースを大きく消費するタスクも想定されるでしょう。
それぞれのビジネスプロセスの特性を考察し、誰がビジネスプロセスを起動できるのか、場合によっては起動できる回数に制限を持たせる必要があるのか、についても考察を深める必要があります。
入力を定義すべし！
ビジネスプロセスのキッカケ（起動）は、「誰が起動するか」と言う議論以外にも、「何をもって起動するか」と言う議論も大切です。
すなわち、リーダの「思いつき」であれ、メンバの「ノルマ達成のための取り組む意思」であれ、プロセス開始条件としての入力フォーマットを定義する必要があります。
例えば、提案書を作成する場合の入力フォーマットは
- 提案書提出先
- 提案書提出予定日
- 概算見積額
が想定されます。現実世界では、何となく提案書を作成しはじめているケースが非常に多いのですが、タスク発生を明確にするためにもプロセスの「開始」の定義が欠かせません。
