大島 正善(MBC:Method Based Consulting)
今回も、前回に引き続いて、「ビジネスの変化に迅速に対応できない情報システム」ということについて、その問題の本質と解決策を探っていきます。今回は、ビジネス・モデルの構成要素のうち、前回あまり触れなかったビジネス・プロセスについて、以下の点について書いてみたいと思います。
(1) ビジネス・プロセスは戦術である
(2) ビジネス・プロセスは、目的志向である
(3) ビジネス・プロセスの最適化は「情報の回転率」の向上が狙いである
ビジネス・プロセスという言葉は企業の中で、日常的に使われる言葉になっているといってよいでしょう。“業務プロセス”という言葉を使う企業もあるでしょう。では、その言葉が意味するところについて共通認識はあるでしょうか? “一連の作業の流れ” といった程度の理解しかしていないことはないでしょうか? ワークフローという言葉もあります。それとは違うことを意味しているのでしょうか? あるいは、同じことを別の言葉で言っているにすぎないのでしょうか?
ビジネス・モデル全体の中で、ビジネス・プロセスはどのような位置づけがされるのでしょうか?皆さんは、自分の会社のビジネス・プロセスを意識して行動していますか? 「わが社には、明確なビジネス・プロセスはないし、そんなものなくてもうまくやっているさ」、とか、「ビジネス・プロセスはどこか神棚に飾った事務規定集に書いてあるかもしれないけど、そんなものを意識して仕事しているわけではない」 という答えが返ってくるところもありそうですが、はたしてそれでよいでしょうか?
BPM(Business Process Management:ビジネス・プロセスの管理)という言葉がここ10年ほど前から使われ、2011年にはガートナーも、“BPMは企業がこれから10年の間に取り組むべき重要なテーマである”と語っている(*1)ように、特定のグループの人たちにはBPMは企業が優先順位を高くして取り組むべきテーマと映っているようです。それはなぜでしょうか? それほど重要なBPMであれば、そもそも管理すべきビジネス・プロセスというものをきちんと理解しておくことが必要でしょう。
前回、ビジネス・モデルを構成する主要要素を列挙し、それらの関連を示す情報モデルがn次元になるということを書きましたが、情報モデルというのはスタティック・モデル(静的モデル)と言われるように、ある一時点の状態を示すもので、要素と要素の間でのやり取り(動作)を示すことは得意ではありません。ダイナミック・モデル(動的モデル)を策定しないと、モデルの要素間のやりとりを表現することは困難です。ビジネス・プロセスは、その意味で、ビジネス・モデルを構成する要素間の動的モデルの一つです。より具体的には、業務機能間の関係を示すのがビジネス・プロセス・モデルです。あるいは、同時に組織間のやりとりを示すこともあります。
ビジネス・プロセスは、業務機能間や組織間のモノや情報のやりとりの動きを表現するものです。ビジネス・モデルの構成要素には業務機能や組織のほかにビジネス目標や戦略、商品、顧客、地域などの要素があります。それらの間には動的モデルは必要ないのでしょうか?
実は、それらの要素も、ビジネス・プロセスに反映されます。ビジネス目標や戦略、商品も顧客もビジネス・プロセス間を流れる情報やモノ、あるいは、活動が開始されるトリガー(たとえば顧客からの注文)という形で表現されます。つまり、ビジネス・プロセスは、単に仕事の手順、流れを示すだけでなく、プロセス間をどのようなモノや情報がやりとりされるのかを示すもので、そのことによって、戦略がどのように実現できるのかを示す戦術そのものなのです。ですから、ビジネス・プロセスを明確に可視化することが重要になります。
世の中では、ビジネス・プロセスをどのように定義しているでしょうか。たとえば、Wikipedia (日本語版)には、作成中とのコメントがありますが、現時点では次のように書かれています。(“ビジネス”を“事業”と翻訳しています)
「事業プロセスまたは事業メソッドは、特定の顧客または顧客のため、特定のサービスまたは(特定の目標を提供する)プロダクトを創り出す、アクティビティまたはタスク (tasks)の構造と関係の集合である。」
この記述は短いものですが、重要なキーワードがいくつか含まれています。「顧客」、「サービス」、「プロダクト」、「創り出す」、「構造」、「関係」、「集合」です。つまり、ビジネス・プロセスは、顧客に商品やサービスを提供する活動(*2)の一連の流れであるということです。この定義に見られるように、ビジネス・プロセスが目標達成との関係で語られており、まさにビジネス戦略を実現するための具体的手段(戦術)であることがわかります。
ちなみに、ビジネス活動に限らず“プロセス”は、Process-Activity-Taskという構造で示すのが一般的です。ビジネス・プロセスも例外ではなく、そのような構造で考えられています。なお、作業(資料を作る、顧客と会う、会議をする、調査するなどのToDoレベルの仕事)は、プロセスの定義には含まれず、Taskの目的を達成するために行う行為という位置づけと考えるのがよいでしょう。
ビジネス・プロセスの定義で、もう一点重要な点は、「創り出す」という動作を示す言葉です。ビジネス・プロセスの定義にはこの他にもいくつかあり(最後の参考「ビジネス・プロセスの定義」を参照ください)、少しずつ言い回しが違うのですが、“目的を意識して何らかのインプットからアウトプットを生み出す”ということが共通的に書かれています。(参考資料では、goalやobjectivesという言葉が使われています)
この点に、ビジネス・プロセスのもう一つの本質があります。“ゴール(到達点)を目指した活動の連鎖”であるということです。ワークフローで扱うような単なる“作業の連鎖”とは違います。顧客にどのような商品・製品やサービスを提供するのか という観点からビジネス・プロセスを見ます。顧客への製商品・サービスの提供という観点からの活動の連鎖を扱うので、研究開発、マーケティング、生産、購買、販売、物流、会計、情報提供などのすべてのプロセスの連鎖を扱います。
ワークフローはどちらかというと、タスクレベルの仕事の流れです。ワークフローを改善することが重要でないということではありません。しかし、“BPMに取り組むことは喫緊の課題である“といわれるのは、顧客への価値提供という観点から、組織の仕事の仕組みを最適化することが競争力の観点から重要だと言っていると考えるべきでしょう。
ビジネス・プロセスはインプットから何らかのアウトプウトを創り出すのですが、アウトプットにはどのようなものがあるでしょうか? 生産現場では、プロセスのアウトプットには多くは物理的な“モノ”があります。アウトプットの種類はそれだけでしょうか?
生産現場でも“モノ”以外に、もうひとつ“情報”というアウトプットが作られています。作られた“モノ”の製品番号、名称、生産日付、構成部品、製造工場名など様々な情報を“モノ”と同時にアウトプットしています。それは、コンピューターが導入される前から変わらないことで、IT化が情報の収集タイミングを一気に早めたにすぎません。物流の現場も生産現場と似た状況です。モノと同時に情報をアウトプットしています。(場所、モノの状態など)
生産や物流ではない、マーケティング、販売、購買、会計などのプロセスは何をアウトプットしているでしょうか。そうです、“情報”です。そして、情報しかアウトプットしていません。(*3) このことは、ビジネス・プロセスを分析するためだけではなく、業務活動そのものにとっても重要な認識です。
生産(モノを作り出す)や物流活動(モノを保管し移動させる)ではない業務の活動は、情報をアウトプットすることが目的であるということを理解するために、3つ例をあげて説明します。
最初は、自動車の販売活動の例です。営業担当者は販売店に来る新規顧客や長年の顧客に対して、新製品の説明や保守サービスなどの説明をすることがあります。そういう営業活動の目的は、新しい自動車を購入してもらうことです。では、この販売活動のアウトプットは、自動車という“モノ”でしょうか? 販売活動で自動車を生産しているわけではありませんし、販売が成功しても多くの場合、納車は後日ですから“モノ”をアウトプットするわけではありません。販売活動のアウトプウトは、自動車が売れたのか売れなかったのか、あるいは、顧客がどういう反応を示したのかといった情報ということになります。企業全体のプロセスとの関係でいえば、そういった情報は販売プロセスに閉じているのではなく、マーケティングや生産(改善要件)や研究開発(次の車の開発へのインプット)へ連携されるべき情報が含まれていると考えることができます。また、販売活動の結果の売上実績情報は、販売管理プロセスへフィードバックされ、販売計画情報と付き合わされて、営業活動の改善活動にフィードバックされます。つまり、販売活動の結果である情報は、PDCAでいえば、Doレベルの他のプロセス(出荷、発注など)へ情報連携するとともに、PlanやCheckあるいはActionという活動へも連携する可能性があります。
二つ目は病院の医師の活動の例です。医者は患者に対して、何を目的として何をアウトプットしているのでしょうか。外科医であれば、物理的なモノ(人体の一部)を直すというということが目的で、アウトプットは、表現が適切かどうかはわかりませんが、回復した人体機能ということになります。それと同時に、どのような手術をしたのか、どのような薬剤を使ったのか、回復の程度はどの程度なのか といった情報もアウトプットすることになります。内科医の場合はどうでしょう。内科医の場合は、患者に対するアウトプットは、病気の種類や病気への対応の仕方(薬の飲み方、日常生活における注意事項など)という情報ということになります。アウトプット情報は患者向けのものと、病院での各種管理のための情報があります。(患者への対応時間、次回予約のための情報など)
三つ目はサービスということを考えてみます。サービスを顧客に提供するということも、モノか情報を提供する活動だという話をします。たとえば、ホテルのコンセルジュの仕事を考えてみましょう。一流ホテルのコンセルジュは、顧客のあらゆる要望にこたえるということに仕事の価値をおいているそうです。彼らはレストランの予約、映画や演奏会、鉄道のチケットの入手から観光地の相談、苦情処理などあらゆる顧客の要望に対応します。映画、演奏会や鉄道のチケットは“モノ”のアウトプットですが、顧客サービスの本質は、観光地の見どころといった情報提供であり、また、コンセルジュとしての品格とでもいうその人格が醸し出す雰囲気という“情報”そのものであるといってもよいのではないかと思います。顧客は、コンセルジュの対応の仕方を情報として受けとって満足感を得たり不満を覚えたりするわけです。たとえ希望した“モノ”が手に入らなくても、十分な努力をしたことがわかれば不満を覚えることなくあきらめることができます。それも、コンセルジュが顧客に“情報”をどのように見せるかということと関係しています。
このように、業務活動はモノか情報を生み出し、保管し、移動させることを目的として行われます。したがって、ビジネス・プロセスを分析するということは、あるプロセスにはどのような次工程があり、関係する次工程(顧客)に、どのような情報やモノを提供すべきかを分析するということを意味します。そういうことを意識して、ビジネス・プロセスを分析し見直していきます。
さて、業務改善や業務改革の仕事にかかわった経験がある方は、今までやってきた業務改善や改革が、顧客(次工程)への価値提供プロセスの見直しという観点から実施してきたかどうかを考えてみてください。多くは、改善や改革の視点は、自分の仕事の改善を目的としていて、次工程である顧客(社内の他部門も含む)へ早く情報や製商品を提供するにはどうしたらよいのか という視点がどの程度はいっていたでしょうか? もしそうであれば、改善したビジネス・プロセスにはまだ課題が残っているといって差し支えないでしょう。
「後工程はお客様」ということは、生産工程では当たり前になっていますが、事務プロセスでも同じです。つまり、プロセスのアウトプットは、後続工程が活用しやすいようなものを生み出すことが求められます。
ビジネス・プロセスを語るときに忘れてはならない点がもう一つあります。それはPDCAとの関係です。
ビジネス・プロセスは企業全体のプロセスを考えます。したがって、PDCAの観点からすると、実施プロセス(D)だけでなく、計画(P)や管理(C)にかかわるプロセスとの関係も考えることが重要です(Aはすべてのプロセスに関わる)。単に実施プロセス間の連携だけを考えていては、計画との乖離が発生した時の対応に遅れが出てしまいます。市場での競争の中で、変化に対応できるビジネス・プロセスにするためには、PDCA全体のプロセスを検討し、活動の実施結果のフィードバックを計画や管理プロセスへ回す仕組みを確立することが必要です。フィードバックが遅くなると、知らぬ間に損失が大きくなることがあります。
ビジネス・プロセスは戦略を実行する手段であり、目的志向であると書きました。では、ビジネス・プロセスを最適(*4)なものとするには、どのような考え方で設計していくことが必要なのでしょうか?
ビジネス・プロセスの最適化の基準について、どこかに標準があるわけではありません。あまり議論されることはないようです。ここで、一つの考え方を提示したいと思います。
「ビジネス・プロセスを最適化するとは、PDCA全体のプロセスを流れる情報流(および物流)のスピードを可能な限り上げることである。」
つまり、あるプロセスでインプットされた情報が、あるプロセスの連鎖をたどって、最終目的地であるプロセスやタスクにたどり着くのにかかる期間をできるだけ早めること、ということです。具体的には、受注情報を受け取ってからから出荷指図を出すまでの時間、発注情報を作成してから納品完了情報を受け取るまでの時間、売掛情報が作成されてから入金完了報告があがるまでの時間、クレーム情報を受け取ってから、対策の完了報告があがるまでの時間などです。
プロセス間を流れる情報のスピードを今以上に早めることができないか、情報が滞留している時間が長いのはどのプロセスなのか、Doの結果のフィードバックが適切なタイミングでPlanやCheckのプロセスに戻っているか、といった視点でプロセスを見直すことにより、ビジネス・プロセスを最適なものにしていくことが可能となります。この観点でプロセスを見直すと、現状の仕事には無駄な作業が多く見つかるでしょう。
実際に作成されているビジネス・プロセス・モデル(ビジネス・プロセス図、業務プロセス図、業務フロー図、業務フロー、ビジネス・ユースケースなど)を見ると、作業の順序は示されていても、プロセス間でやりとりされるモノや情報があいまいなものをよく見かけます。情報やモノがあいまいなモデル図では、議論して検討した結果、担当者が抱える問題を解決できたとしても、“情報流を最適化する” という観点からプロセスを見直すことはできないので、問題の本質的な解決になっているのかどうか怪しいと思われます。
当たり前ですが、ビジネス・プロセス・モデルの構造は、情報システムのアプリーションの構造と密接な関係があります。情報システムの構造の設計作業でも、そのビジネス・プロセス(その他、ビジネス・ルール、および、ビジネス情報の構造)の理解は前提となります。
今回は、ビジネス・プロセスについて考察しました。「ビジネスの変化に迅速に対応できない情報システム」への解決策には、まだほど遠いところを歩いています。しかしながら、ビジネスの変化には、市場の変化とそれにともなう戦略や組織の変化だけでなく、ビジネス・プロセスの変更やプロセスで行われる活動の変更も含まれているということは、ご理解いただけると思います。それらの変化が情報システムにどのように影響を与え、その変化に迅速に対応するためには、どのような仕組みを構築したらよいのか、という点について今後触れていきたいと思います。また、最近よく語られる「俊敏な経営」との関係から、ビジネス・プロセスについてはまだ語っておくべきことがありますが、ページ数が多くなったので次回のテーマにしたいと思います。
今回触れた、PDCAの視点からDoの結果の情報(実績、クレーム情報など)をPlanとCheckのプロセスへ適切なタイミングでフィードバックする仕組みを作るという視点は、“ビジネスの変化”に迅速に対応する仕掛けの一つとして考慮すべきことではないかと思っています。それは情報システムでの対応とは別のこととして、ビジネス・プロセスそのものを見直す視点として有効ではないでしょうか。
************************************************************************
参考: ビジネス・プロセスの定義について。
ビジネス・プロセスという言葉の定義は一つではありません。以下にいくつか紹介します。