(C)2009 Questetra, Inc.

ビジネスプロセスモデリングの鉄則「ビジネスプロセスの “見える化” を、少しずつでも推進したい」「究極の “あるべき業務フロー” を、徹底的に議論したい」
改善規模の大小を問わず、ビジネスプロセス改善の議論は容易ではありません。実際、議論自体が発散したり、決定事項が曖昧になったりと、手間の割に得るものが少ないと感じた経験を持つ方も多い事でしょう。
では、どの様な順序でビジネスプロセスを定義して行けば良いのでしょうか。
本稿では、ホワイトカラーのビジネスプロセスを効率良く定義して行く方法について記述します。

１．ビジネスプロセスの成果物を決める

３．役割を分け、タスクに分解する

各ビジネスプロセスの成果物を定義し、さらに成果物一つあたりにかけられるコストを想定しましょう。

開始方法と成果物が決まれば、コストを意識しながらタスクに分割して行きましょう。

1-1. まずは出力をイメージすべし！
1-2. 最終出力を定義すべし！
1-3. 無理してでも最終出力を定義すべし！
1-4. 出力QCDを予想すべし！

3-1. 専門分化すべし！
3-2. 極力分業すべし！
3-3. 成果物にはリーダが責任を持つべし！
3-4. コスト構造を検証すべし！

２．ビジネスプロセスのキッカケを決める

４．各タスクの順序経路を決める

各ビジネスプロセスの開始方法を、組織にあわせて検ビジネスプロセスのタスクが決まれば、色々な検証をし討定義しましょう。
ながら、その流れ方を決めましょう
2-1. まずはリーダ開始で運用すべし！
2-2. メンバ開始も検討すべし！
2-3. 開始パターンを複数用意すべし！
2-4. 入力を定義すべし！

4-1. 並行処理も検討すべし！
4-2. ショートカットも設置すべし！
4-3. 他のビジネスプロセスとの共通化も検討すべし！
4-4. 運用目標を設定すべし！

1. ビジネスプロセスの成果物を決める(C)2009 Questetra, Inc.
1-1. まずは出力をイメージすべし！

1-3. 無理してでも最終出力を定義すべし！

例えば・・・、プリンタに「印刷データ」を送ると、「印刷物」が出てきます。
自動販売機に「希望とお金」を渡すと、「商品」が出てきます。

成果物（最終出力）を定義し辛いビジネスプロセスも、実は多数存在します。例えば、 「個人情報削除依頼への対応フロー」と言うビジネスプロセスは何を成果物とすべきなのでしょうか。

貴方の担当するビジネスプロセス（ワークフロー）は、そもそも何を「出力」するのでしょうか？ 毎日こなしている業務であっても、明確に表現する事は意外と難しいものです。

一般に、格納されている情報を、閲覧するだけ・更新するだけ・削除するだけと言うビジネスプロセスは、新たに情報を生成する事が無いため、成果物定義が困難です。確かに「作業報告書」と言った類の成果物を設定する事は可能ですが、場合によっては、セキュリティ上の都合などで「作業報告書」に記録できる情報がほとんどない場合もあります。そして、業務の主目的が達成されているため、成果物（最終出力）を完成させずにプロセスが終了してしまいがちです。

例えば・・・、
問合窓口に「問い合わせ」をすると、「回答」が返ってきます。
セールスに「希望する事」を伝えると、「見積書」が返ってきます。
人事部に「採用応募」を申し込むと、途中のやり取りがあるかも知れませんが、最終的に「採用合否通知」が返ってくるでしょう。
組織内部では複雑な処理をしているかも知れません。
誰かの独断で済ませているのかも知れません。
ただ、何らかの処理を経て出力があります。ビジネスプロセスを議論する時には、まずは「どの様な出力がなされるべきか」、ビジネスプロセスを極力客観的にとらえる事が大切です。

1-2. 最終出力を定義すべし！
「材料（material）が入力で、B/SとP/Lが出力だ」
やや極端な意見ですが、確かに間違った意見ではありません。しかし、物事を巨視的に捕えすぎると議論効率は下がります。BPM活動の最大の狙いは定常的な改善であり、会社全体を適切に分割したビジネスプロセス単位で、改善を検討したいところです。
では「最適な分割」は、どの様に考えればよいのでしょうか。ホーム
ページ制作会社を例に考えてみます。
ホームページ制作会社が出力するものに、「見積書」、「作品」、「設定マニュアル」など、様々なものが思い浮かびます。しかし当然ながら、思い浮かんだすべての出力単位でビジネスプロセスを定義する事は非効率です。
例えば、「作品」と「設定マニュアル」は、共に制作チームが主管し、同じタイミングで、しかも1対1の関係で制作されるものです。この様な出力は、「Web制作ビジネスプロセスから生み出される出力」として一つのビジネスプロセスから生み出されるものと考えるべきです。この場合、「納品CD」と言う出力を「Web制作プロセス」の最終出力として想定し、「作品」や「設定マニュアル」は途中タスクで制作されるものとしてとらえるべきです。
ビジネスプロセスを設計する時には、まずはその最終成果物としての「成果物」を定義することが重要です。

しかし、それでも成果物を定義し、毎回完成させておく事が重要です。
１．個々のプロセスの終了条件が明確になる。
２．個々のプロセスの最終記録として、以後参照できるようになる
特に、記録として残す事は組織として極めて有意義です。過去の反省に立って新しいプロセス処理を効率化させたり、あるいはビジネスプロセスの改善議論の資料としたりすることが可能になります。
自動記録やシステム連携など、極力省力化する工夫は別途必要ですが、成果物を定義し辛いビジネスプロセスにおいても、作業時刻や作業内容の記録、あるいは作業に対する反省や評価等を「作業記録書」として成果物定義する事が望ましいと言えます。

1-4. 出力QCD
出力QCDを予想すべし！
QCDを予想すべし！
ビジネスプロセスの評価は、実際に生成される成果物のQCD（品質・コスト・期間）比較によって行われるケースが多いと言えます。言うまでもなく、成果物の品質は高いに越した事はなく、成果物作成にかけるコスト（労力）は小さいに越した事はなく、また成果物完成までの期間は短いに越した事はありません。
しかしQCD指標は、「コストをかければかけただけ品質が高まる」など、トレードオフの関係にあるため、別途巨視的な観点から「あるべきQCD」を想定しておく事が大切です。
ホームページ制作会社のビジネスプロセスを、それぞれの成果物とともに列挙してみます。
１．顧客ヒアリング報告 （ヒアリングシート）
２．提案書作成業務 （提案書）
３．見積書作成業務 （見積書）
４．受託契約業務 （契約書）
５．詳細仕様合意プロセス （仕様書）
６．制作・品質管理・納品プロセス （納品CD）
ここでは５．６．が「制作チーム」20人が主管するビジネスプロセスとし、それ以外が「セールスチーム」5人が主管するビジネスプロセスとします。もし仮に、Web制作事業全体の目標が、 「標準案件で週次4件こなす」 であるならば、平均受注率（経験値）から考えて、例えば「見積書は週次6件」、「提案書は週次10件」、「ヒアリングシート週次20件」等の成果物の完成数目標が想定されます。この場合、自ずと標準案件に対してかけられるコストや品質が想定されます。
ヒアリングシート： 50%が提案書提出に繋がる品質・1件5時間程度
見積書： 50%程度の受注率・1件2時間程度組織が置かれたビジネス環境にあわせ、最初に成果物のQCDを想定しておけば、効率良い「その後の議論」が期待できるでしょう。

2. ビジネスプロセスのキッカケを決める(C)2009 Questetra, Inc.

ビジネスプロセスの成果物（最終出力）や、その想定QCDが設定されれば、次は「キッカケ」を議論する事が有効です。
「成果物（最終出力）」がビジネスプロセスにとっての終了条件であるのとは対照的に、「キッカケ」は開始条件です。しかし実際、「プロセスを開始させるキッカケ」については意外と議論されない傾向にあります。

組織の中には、自ら進んで仕事を生み出す事が得意な人もいれば、上司などの指示を受けて仕事をこなす事で大きな貢献をする人もいます。現実問題として、プロセスを起動できる権限を「リーダだけ」、「メンバだけ」のどちらかに限定できないケースが多く存在します。その様な場合、両者ともに開始できるビジネスプロセスを定義する事が有効です。
1.提出先指定

メンバ

2.提案書
2.提案書
草案作成

制作T

4.評価

3.概算
レビュー

5.提出
結果メモ

リーダ

1.提出先
指定

4.評価

メンバ

提案書作成B＜提案書作成業務：リーダ開始＞

2.提案書
2.提案書
草案作成

制作T

確かに、たとえば組織外部からの問い合わせに対応するプロセスや、組織外部から受け付けた申請を処理するプロセスなどでは、あまり議論する必要がありません。これらは、多くの場合「受動的に開始されているプロセス」と言っても良く、開始しないと言う選択肢が無いケースがほとんどです。
ただ他方、「提案書を提出するプロセス」は、組織としては「能動的に開始させるプロセス」です。たとえば「A社向け提案書」と言う成果物をイメージした時、そのプロセスを開始させるべき人は様々な選択肢が考えられます。
１．A社担当のセールスメンバ
２．営業を統括するセールスリーダ
３．あるいは会議を開いて多数決で決めるかも知れません。

リーダ

2-3. 開始パターンを複数用意すべし！

提案書作成A

2-1. まずはリーダ開始で運用すべし！

3.概算
レビュー

5.提出
結果メモ

＜提案書作成業務：リーダ・メンバ開始＞

ビジネスプロセスを運用するにあたっては、まずは「安定して週次10件の提案書が完成する事」を目指したい所です。その場合、リーダが提案書を作成するべき案件を10件選択し、組織内に対してそれらの作成を指示する形で、「提案書作成業務」を起動する形が有効だと言えます。

しかし、例えば「提案書作成業務」と言うビジネスプロセスの例では、「概算見積」や「提案実現性の判断」など、セールスチーム以外が担当するタスクも想定されます（上図では「3.概算レビュー」に相当）。
各セールスメンバが思いついた提案の数だけ制作チームのリソースを消費して良いものか、議論の余地があります。
仮に「見積書作成業務」と言うビジネスプロセスを考えれば、さらに「詳細な見積」や、「要因リソースの確保（アサイン）」など、制作チームのリソースを大きく消費するタスクも想定されるでしょう。
それぞれのビジネスプロセスの特性を考察し、誰がビジネスプロセスを起動できるのか、場合によっては起動できる回数に制限を持たせる必要があるのか、についても考察を深める必要があります。

2-2. メンバ開始も検討すべし！

2-4. 入力を定義すべし！

しかし当然ながら、リーダ指示が無ければ提案書が完成しないと言うルールには、少なからず問題があります。例えば、顧客要望のヒアリングを実際に担当したセールスメンバからすれば、「一日も早く提案書作成に着手したい」と考えることでしょう。ヒアリングシートを作成している時点で、とても素晴らしい提案を思い浮かんでいるケース等では、ビジネスプロセスやルールがどうあれ、リーダの指示を待っていられません。

ビジネスプロセスのキッカケ（起動）は、「誰が起動するか」と言う議論以外にも、「何をもって起動するか」と言う議論も大切です。
すなわち、リーダの「思いつき」であれ、メンバの「ノルマ達成のための取り組む意思」であれ、プロセス開始条件としての入力フォーマットを定義する必要があります。

プロセスオーナーは

１．提案書提出先
２．提案書提出予定日
３．概算見積額

１．ビジネスプロセスの特性
２．組織の成熟度
３．事業進捗度
等を総合的に勘案して、誰がプロセス開始（起動）出来るのか、を決定する必要があります。機動的なビジネスプロセスを実現するために、「メンバがプロセスが起動するルール」に改める必要があるかも知れません。

例えば、提案書を作成する場合の入力フォーマットは、が想定されます。現実世界では、何となく提案書を作成しはじめているケースが非常に多いものですが、タスク発生を明確にするためにもプロセスの「開始」の定義が欠かせません。

3. 役割を分け、タスクに分解する(C)2009 Questetra, Inc.
3-3. 成果物にはリーダが責任を持つべし！

「見積書」は顧客との商談の中で提出されるものです。およそ「見積書作成業務」と言うビジネスプロセスはセールスチームが主管し、あるべき姿の検討も、セールスチームが主導して実施すべきです。
見積書完成のためのビジネスプロセスが、仮に、
１．見積書提出先
２．見積書提出予定日
３．見積想定金額範囲と言う入力フォーマットで定義されているとすれば、たとえば
１．A社
２．2010年4月1日に見積書提出予定
３．100万円～150万円と言う情報がこのプロセスの入力となります。他方、成果物は
１．A社様向けホームページ仕様書
２．見積有効期限：2010年4月15日
３．納期：2010年5月31日
４．納入物：納品CD（ホームページデータ・設定マニュアル）と言った具体的な提案書となるでしょう。
５．見積内部工数、内部工数見積者および内部工数見積時刻
６．受託時の想定制作メンバ
７．見積書の決裁者および決裁時刻
８．決裁者の仕様書評価などの内部記録も有効です。
このケースでは、必然的に「仕様書」が制作チームのタスクとなり、その他の作業がセールスチームのタスクとなります。

成果物の完成件数や成果物品質には、責任者が責任を負う事になります。ビジネスプロセスをタスク分割する際には、成果物（最終的な出力）の完成工程で、責任者自身による評価タスクやレビュータスクを設置する事を検討したいところです。

4.評価

メンバ

見積書作成

1.提出先指定
2.見積書
2.見積書
草案作成

制作T

リーダ

3-1. 専門分化すべし！

3.納入物定義
仮アサイン

3-4. コスト構造を検証すべし！
5.提出
結果メモ

＜提案書作成業務：リーダ・メンバ開始＞

このケース様に、複数チームにまたがる様なビジネスプロセスは、自然と「スペシャリストによるタスク」に分割されるでしょう。

3-2. 極力分業すべし！

メンバ
制作T

提案書作成

リーダ

分業は「下流タスク作業者のチェックを受けられる」と言う副次効果もあって非常に有効です。では「顧客ヒアリング報告」の様にセールスチーム内に閉じたビジネスプロセスはどの様に分業すべきなのでしょうか。結論から言って
１．セールスチーム同士で分業し、成果物の品質を高める方針
２．セールスチーム内で、構成とデザイン等の職能を分ける方針等が考えられます。１．の場合、「素案作成」と「レビュー」や「評価」をセールスチーム内で分業し、ヒアリングシートの書き方や、記録として残すための工夫を切磋琢磨する事になるでしょう。
なお、分業するほどではないと言う結論であるならば、 「顧客ヒアリング報告」を独立したビジネスプロセスとしてとらえるのではなく、「提案書作成業務」の1タスクとして考える事も可能です。
2.提案書
提出判断
1.ヒアリングシート

3.提案書
3.提案書
草案作成

まず一つ目の効果として、プロセス完了条件を厳格化が期待されます。換言すれば「仕事をいい加減に終わらせない」とも言えるでしょう。一般に執行と監督を分離する事で、納期は遅くなるかも知れませんが、品質は確実に向上します。
もう一つの効果として、ナレッジ整備が期待されます。成果物完成時点で、各成果物の採点をすれば、以降同様のプロセス実行時のベストプラクティスの検証が促進されるでしょう。

5.提案書
評価
6.提出
結果メモ

4.概算
レビュー
＜顧客ヒアリングを提案書作成業務に組み入れた例＞

ビジネスプロセスの開始と終了を定義し、タスクに分割していくと、自ずと標準的なプロセスを1件完了させるために必要なコスト（社内工数）が精緻に導出されます。
仮に受注活動に関するビジネスプロセスの内、セールスチームのタスクにフォーカスした場合、以下の様な必要コストが算出されるでしょう。
１．顧客ヒアリング報告 （ヒアリングシート） 《目標：週次20件》
1-1. 面談および原文作成タスク： 2時間×20件
1-2. 同行者コメントタスク： 1時間×20件
1-3. ヒアリングシートのリーダレビュータスク： 0.5時間×20件
２．提案書作成業務 （提案書） 《目標：週次10件》
2-1. 提案書原文作成タスク： 2時間×10件
2-2. 提案書デザインブラッシュアップタスク： 1時間×10件
2-3. 提案書レビュータスク： 0.5時間×10件
2-4. 提案書リーダ評価タスク： 0.5時間×10件
３．見積書作成業務 （見積書） 《目標：週次6件》
3-1. 見積概要定義および案件説明タスク： 2時間×6件
3-2. 制作チーム仕様書のレビュータスク： 1時間×6件
3-3. 見積書リーダレビュータスク： 2時間×6件
3-4. 見積書顧客説明タスク： 2時間×6件
４．受託契約業務 （契約書） 《目標：週次4件》
4-1. 契約書案作成タスク： 1時間×4件
4-2. 契約書リーダレビュータスク： 0.5時間×4件
現実には、定義されたビジネスプロセスの各タスクを実行する時間
以外にも、他部署が主管するビジネスプロセス内のタスク処理、あるいはビジネスプロセスを改善議論するための時間や、非定型業務に投じられる時間も必要となります。
上記の例では、合計週次158時間となりますが、実際の構成員数、たとえば「5人」で処理しきれるのか、検証する必要があるでしょう。
ビジネスプロセスを不用意に多くのタスクに分割し過ぎると、現実の要員では事業目標を達成できない事態になりかねません。場合によっては、成果物の定義からやりなおす必要があります。

4. 各タスクの順序経路を決める(C)2009 Questetra, Inc.
4-3. 他のビジネスプロセスとの共通化を検討すべし！

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

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

メンバ
人事総務

汎用申請

リーダ

4-1. 並行処理も検討すべし！

2.申請
承認
5.申請結果
確認

1.申請
1.申請

申請内容によって自動的に情報分岐

3a.申請処理

経理

順序や経路を議論する上で、常に検討すべき事は、
１．タスク滞留の発生確率を低減する
２．タスク待ちの発生確率を低減する
３．リスクの発生を検証する＜汎用的な申請ワークフローの例＞などです。ただ実際問題、ビジネスプロセスを運用する前に論理的に改善方法を検討するより、実際にビジネスプロセスを運用し実際に発生した（発生してしまった）問題に対処する経験的改善の方が有効である事は確かでしょう。
なお、あまり実現されるケースは多くありませんが、多くの課題に対して意外と有効な手法に、「並行処理化」が挙げられます。たとえば、制作チームメンバの複数人が「内部工数見積タスク」をそれぞれ独立して対処することで、それらを平均化して「より確からしい見積内部工数」を実現する事が出来ます。あるいは、一人の見積担当者が中々見積もり作業に着手できない場合でも、期限に間に合う見積があれば見積内部工数を決定でき、クリティカルな滞留を回避する事が出来ます。

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

メンバ

提案書作成

4.チェック

2.提案書
2.提案書
草案作成

制作T

リーダ

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

3.概算
レビュー

3b.申請処理

6.評価
5.提出
結果メモ

＜提案書作成業務：リーダチェックを省略可能＞

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

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

4-4. 運用目標を設定すべし！
ビジネスプロセスは実際、その運用後に定義変更を余儀なくされる事が少なくありません。ただ、その改善活動が目指すべきものとして、「あるべき成果物のQCDや完了件数」を常に把握し、組織内で共有したい所です。
たとえば、「週次10件」の提案書を完成させるにはどうしたら良いか「成約率60%」を実現する提案書品質を保つにはどうしたら良いかと言う議論の中で、「ヒアリングシート作成後、1週間以内に提案書を完成させてみよう」、と言う「新たな目標」が生まれるかも知れません。
ビジネスプロセスの定義は、BPM活動（ビジネスプロセスマネジメント活動）の中でもっとも重要な活動です。実行時のKPIを十分に見越した設計が期待されるでしょう。

＜Key Performance Indicator＞
１．ヒアリングシート
完了件数： 目標週次20件
２．提案書
提出件数： 目標週次10件
３．見積書
提出件数： 目標週次6件
見積額計： 目標週次1000万円
４．契約書
受注件数： 目標週次4件
受注額計： 目標週次600万円