August 2014 Archives

7つの作法の4つ目は「作業プロセスがある場合はそれをサブプロセスとして記述する」です。毎回言っていますが、プロセスの基本構成は、「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」ですが、その作業プロセスのことになります。作業プロセスは前回例に出した見積提示プロセスのようなものだとほとんど作業らしきものがない場合もあります。

一方で主として作業プロセスからなる場合もあります。例えば製造プロセスのようにもうやるべきことが決まっていて、依頼がきたら手順に従って実行するといった場合です。要求仕様は逆に決まったものを受け付けるから与件としてあるし、段取りにあたる意思決定も既定のものとして扱うからです。ですから、プロセスの性格が意思決定が大事なのか作業が主たるプロセスかで多少構成が変わってくることもあります。

作業プロセスの基本構成は、「作業依頼受付」「作業項目確定」「期日決定」「担当者割当」「作業結果報告」というものになります。意思決定に基づき作業すべき内容がこの作業プロセスに受け渡されます。それを受けた作業プロセスでは、作業内容に従って、作業項目(タスク)にブレークダウンし、タスクごとに期日と担当者を決めて、作業の結果を集約することを行います。

意思決定プロセス→作業プロセス→タスク管理というようにつながって行くわけですが、キーとなる作業名、作業内容、期日はちゃんと継承されていきます。こうして実行された作業結果はデータ、報告書などの帳票、制作物などとして大元の意思決定プロセに戻されます。

さて次に5つ目の作法である「プロセス構成モデルからケース分割とタスク分解を検討する」になります。これはわかりにくいかもしれませんが、作業プロセスがいくつかのケースに分割されることがあるのでそれを見ていきましょうということです。作業プロセスに受け渡す作業内容が複数の作業プロセスになる場合です。

例をあげると、新規顧客獲得プロセスというものを考えてください。いつまでに何人を見込顧客として獲得しなくてはいけないのでキャンペーンを行うというようなプロセスの場合です。例えば、展示会たけのキャンペーンでいいなら1つの作業プロセスで済みますが、他にもDMだとか訪問だとかといったものも実施するとなると作業プロセスが複数になる場合です。こうした時にはケース分割とタスク分解を行います。
  

始点と終点と中間アクティビティが決まったら、主要なアクティビティである意思決定で確定すべきデータあるいは判断項目を定義することになります。この辺になるとわかりづらくなりそうなので具体的なプロセスを例にして説明していくことにします。

「見積提示プロセス」を例に今までのおさらいも含めて見ていきましょう。このプロセスの始点は「見積依頼」で、終点は「見積書提出」です。このプロセスは典型的な顧客接点プロセスですから、始点から先に決めます。お客さんはこういうものが欲しいから見積書を作って送ってくれと言いますのでそこが出発点になります。

見積依頼は見積書をお客さんが受領して終わります。つぎの商談から受注までを一つのプロセスと考えてはいけません。顧客は見積をもらってから発注するかどうかはわかりませんから別のプロセスとして扱います。このように、リクエストに対するレスポンスという関係がプロセスの骨格となるわけです。

次に中間アクティビティをみていきましょう。意思決定プロセスでは、「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」という要素からなっていることを前回示しました。ですから、「見積依頼受付」が最初で最後が「見積結果報告」ということになります。2番目の「要求仕様確定」というのは、どんなものあるいはどんなことを見積もって欲しいかを確定することです。

お客さんの頼み方も様々できちんとした依頼書を書いて提出してくれる場合もあるでしょうし、逆にだいたいこんなものでといった曖昧な表現で頼んでくる場合もあります。話は少しそれますが、この両極端の場合は注意が必要です。きちんと仕様を決めてくれるというのは一見良さそうですが、あまりに詳細に決められると提供側の裁量を入れられないという事態が起こるケースもあってやめたほうがよいと思います。

普通は見積を依頼する側よりも提供側のほうが情報が高度で多いはずだからプロの意見を取り入れたほうがいいからです。素人が玄人のことに口出しするなですね。反対に、曖昧な依頼も困ったものです。往々にしてベテラン同士のやりとりにあったりします。手戻りに泣かされることになります。

ここでの主題は「意思決定」の中身の定義の話ですから、「見積提示プロセス」ではどうなるのでしょうか。その前に意思決定と言うのはどういうことをすることなのでしょうか。それは、"データを確定すること"と"ある判断をすること"と考えています。データ確定も原則一つのデータです。こういう数値にするという決定のことです。

ここでおわかりかと思いますが、「依頼」から「要求仕様」を確定するというのは、確定してほしいデータ、判断をしてほしいことを書き出すことに等しいのです。「見積提示プロセス」では、実際には顧客要求を聞いてから意思決定アクティビティが決まりますが、理解しやすいように常識的なものをあげておきます。

見積書に記入する項目として主なものは、「商品仕様」「数量」「納期」「価格」といったものになるでしょう。こうしたデータをプロセスの中で順番に決めて行くわけです。そして、意思決定ともう一つの中間アクティビティに「作業」というのがあると言いました。この例では、「見積書作成」というのが作業になるわけですが、今どき手書きではないので、確定データを中間登録しておけば自動的に作成してくれるでしょうから、ほとんど作業なしでプロセスオペレーションできることになります。
  

プロセス名を決め、始点と終点を決めると、次はプロセス構成に従って中間アクティビティを記述することを行います。ここでプロセス構成に従ってと言っているからには、プロセス構成について説明しておかなければいけませんね。基本的な構成は下記のようになっています。

プロセス構成.JPG

まず大きく意思決定プロセスと作業プロセス、タスク管理から成り立っています。ここで詳細に行く前にこのプロセス構成のバリーションを考えてみます。現実のプロセスでは意思決定プロセス、作業プロセス、タスク管理の重要度というか構成割合が違ってきます。そのバリエーションが下図となります。
 

構成バリエーション.JPG
 

ここも大きく3層と2層の構造に分かれます。3層では意思決定主体か作業主体かがあります。また、2層のものもあって、同じように意思決定が主体か作業が主体かでタイプが違ってきます。それぞれの説明は省きますが、従来システム化の対象となったのはDタイプです。どんな作業をすべきかがすでにあって、それをいかに効率的に実行するのかが焦点となるケースです。

ですから、ここはITを使って自動化することが目的になる場合が多く見られます。ところが、このプロセス構成では、段取りが与件としてあるという前提なのですが、実はこの段取りをどうするかが重要なのです。段取りが悪いものをいくら効率的にやったとしても手戻りが発生したりしたら何もならないわけです。

さて、プロセスの構成にある中間アクティビティを見ていきましょう。意思決定プロセスでは、「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」という要素が提示されています。前回始点と終点を先に決めると言いましたが、その始点は「依頼受付」、終点は「報告・登録」になります。つまり、内部でも外部でもいいのですが、何かこうしてほしいという依頼が出発点となります。その依頼に対する答えを作って依頼主に報告しでデータベースに登録するのが終点になります。

その間にあるのが中間アクティビティです。まず依頼がきたらその依頼の内容、どんな要求なのかをきちんと把握して固めておくことが大事です。あいまいなままにしておくと手戻りが発生してしまいます。依頼者は往々にしてこんな感じにといった抽象的な依頼をしてくる場合が多いのできちんとつめておいたほうがよいと思います。

その後は、単位意思決定を連鎖させたものになります。要求項目は複数のものがほとんどですから、複数の意思決定や判断になります。そして、作業がある場合には作業プロセスに落とし込みます。意思決定したものと作業プロセスから生成されたデータを合わせて報告・登録に持って行くことになります。


作業プロセスでは始点が「作業依頼受付」から作業指示がだされ、終点が「作業結果」ということになります。そして中間アクティビティは基本的には様々なアクションのつながりになります。このように、どんなリクエストがあってその内容を確定し、どんな答えを返してあげればよいのかを決め、どんな意思決定や判断を行うのか、作業な何があるのか定義していくことになります。
  

今回からは、実際にプロセスをどう設計していくかというお話になります。

2. プロセスデザインの進め方  
(1) 対象プロセスの特定
「特注品で新分野を開拓し売上げ・利益をのばす」という戦略に対して「ベテランの営業に依存しない要求確認」「収益性を確保した見積」「役割分担の明確化」といった課題が抽出されました。

特注品だと顧客がどんなものを望んでいるのかをきちんと把握する必要があります。しかし、これはある程度の経験やノウハウがないと難しいのでどうしてもベテランの営業にたよってしまいます。若手でも的確な要求確認ができるような仕組みが要るなあということになります。また、原価を計算しないで要求通り作ってみたら赤字だったなどということも出てきます。特注品は粗々の設計をしますから、顧客要求に対する設計の関わり方も問題になってきます。

こうした問題点をみていくと、最も優先して整備すべきものは何かが見えてきて、それが「見積提示プロセス」であると結論付けました。このように、戦略からそれを実現するための阻害要因を検討し、課題化したものを解決するための狙い所のプロセスを特定していったのです。いきなりこのプロセスにBPMを適用してみましょうといった取組を見聞きすることもあるのですが、単に効率化の手段としてという意味は多少はあるかもしれませんが、大事なことは、戦略とか事業方針といったものとの連動性を持ったBPM適用が効果的です。

さらに、その後特注品という新規商品へシフトしても既存顧客の範囲では限界が出てきて売上げの伸びが止まったため、(STEPⅠ)顧客の範囲を拡大した新たなビジネスモデルを設定し、それを実行するために営業プロセスの中の別のプロセスである「プロモーションプロセス」を対象としたBPMを実行しました。(STEPⅡ)
  

このように、BPMをいきなりプロセス設計や実装から入ってしまうのではなく、新しい戦略に沿ったビジネスモデルからBPMを適用すべきプロセスを選定していくアプローチが大事になってきます。つまり、ビジネス上の要求の受け皿としてプロセスがあるということなのです。
 
【成功のポイント】
ビジネスモデルに戦略や課題を記述して、そこを起点としてプロセスにマッピングすること

  

5つの誤解のあとは、7つの作法になります。いよいよシステム構築のHowの領域に入っていきます。その7つの作法というのが下記のとおりです。

(1) プロセス名を決め、始点と終点を決める
(2) プロセス構成に従って中間アクティビティを記述する
(3) 主要なアクティビティである意思決定では確定すべきデータあるいは判断項目を定義する
(4) 作業プロセスがある場合はそれをサブプロセスとして記述する
(5) プロセス構成モデルからケース分割とタスク分解を検討する
(6) プロセス要素表を作成する
(7) 実装する

ここで"作法"と言っているのは、厳格な技法でその通りにやらなくてはいけないというものではないことを意味しています。だいたいのやり方があって、人によって違っても構わないということでもある。ただ、勝手にやっていいかというわけではなく、最低限の決まりは守ってよねというものです。

では、最初の「プロセス名を決め、始点と終点を決める」です。プロセスというのは必ず始まりと終わりがあります。その時何を持って始まって、どうなったら終わるのかは決めておいたほうだがいいですよね。というか、それがないと業務という意味がなくなってしまいます。目的がないことをやるのは組織では許されませんから、きちんと始点と終点を決めないといけません。しかも、始点と終点は密接に関係していて始点が決まれば必然的に終点が決まるし、その反対もあるということです。

では、始点と終点はどちらを先に決めたらよいのでしょうか。これはプロセスの性格によって違ってきます。ざっくりと言うと顧客接点プロセスか、内部プロセスで決め方が変わります。顧客接点では始点を先に決めていきます。お客さんの要求が起点になるからです。

一方、内部プロセスでは逆に終点から決めていきます。内部プロセスというのは、企業としての事情で起こされたプロセスを指していて、例えば、決算で売上の集計が欲しいといったような場合は、初めにアウトプットがあってそのためにどういうインプットがいるのかという流れになるからです。

始点と終点が決まると自ずとプロセス名も決まってきます。この時気を付けなくてはいけないのが、プロセスの具体的な動きがわからないような曖昧な名前にしないことです。よくつけられる名前に〇〇管理プロセスというのがありますが、こういった名前は避けましょう。単に「見積管理プロセス」なんてつけないで「標準品見積提示プロセス」というふうにします。