今回も、前回に引き続いて、「ビジネスの変化に迅速に対応できない情報システム」 ということについて、その問題の本質と解決策を探っていきます。今回は、この数年話題となっている「俊敏な経営」とビジネス・プロセスとの関係について書いてみたいと思います。ポイントは、以下の点です。
1.俊敏な経営を目指すためには、ビジネス・プロセスをイベント・ドリブンにしていくことが必要である
“俊敏な経営”とは、ビジネス環境の変化に即座に対応できる経営スタイルであり、意思決定の仕組みです。戦略の変更、組織の変更、サプライ・チェーンの変更、ビジネス・プロセスの変更などを環境変化に合わせてダイナミックに変えていける企業風土とすることともいえます。
このような企業風土にしていくためには、従来型の“標準化された作業の流れ”では対応しきれません。“プロセス”という言葉には、“手順が事前に決まっている”という意味が含まれているように思いますが、俊敏な経営を可能とするためには、事前に決まったプロセスではなく、発生する事象(イベント)ごとに次行程を変化させる仕組みを作ることが必要となります。
“俊敏な経営”あるいは“Agility”という言葉が出ている記事をネットで検索すると、「IT経営」、「ビジネス・プロセス・マネジメント」、「イベント・プロセシング」、「情報流の高度化」、「ITのフル活用」、「フラットな組織」などというキーワードが見つかります。(*1,*2,*3,*4,*5)。なぜ、そのようなことが言われるのでしょうか。また、具体的にはどうすべきと言っているのでしょうか。納得するためには、やはりその理由をきちんと理解することが必要です。
前回、ビジネス・プロセスの構造を図1のように示しました。
この図の示す意味は、一つのビジネス・プロセスは複数のプロセス(工程)から構成され、一つのプロセスは複数のアクティビティ(活動)から、一つのアクティビティは複数のタスク(仕事)から、一つのタスクはToDoレベルの複数の作業から構成されるということです。そして、“ビジネス・プロセスを明確にする(定義する)”ということの目的は、作業レベルを除いて、タスク・レベル、あるいはアクティビティ・レベルまでの活動を整理するということにあるということです。
「プロセス」レベルの活動には、決まった手順や流れがあります。たとえば、生産計画があっての製造活動であり、企業活動があっての会計プロセスがあるということです。製造してから生産計画をたてることはなく、会計処理が販売活動や生産活動に先行することはありません。プロセス単位の活動には前後関係(順序)があると考えられます。
それに対して、「アクティビティ」レベルの活動には、流れがある場合と流れが事前に決まらない活動があります。販売プロセスを考えると、在庫品であれば、受注→在庫引当→出荷→納品→入金という流れです。受注生産では、受注→生産指示→生産→出荷→納品→入金という流れになります。いずれのアクティビティにも順序があり標準があって、その順序を変えて活動を行うことはありません。
ただ、市場の変化に俊敏に対応するということは、そのような標準化された活動では対応できないことがあります。「俊敏な経営をする」ということは、わかりやすく言えば「何らかの課題やリスクに敏感に反応する」と言い換えてもよいと考えられます。問題がほとんど発生せず安定的にビジネス活動を行うことで確実な収益が得られるのであれば、「俊敏な経営」が必要であるとは必ずしも言えないでしょう。そのような市場では、「俊敏さ」よりも「製品への信頼性」や「品質」がより重要となると思われます。かつてのように、モノを作れば売れ、プロダクトアウトの発想が通じた時代はともかく、現代は、顧客や消費者の声に耳を傾けずに製商品を販売することは不可能といってよいでしょう。
市場の変化に敏感に反応するということは、市場が発する“企業活動への警告情報”に的確な対応を取るということでもあります。“警告情報”への対応は、警告の内容に応じて異なります。消費者からのクレーム情報への対応は、クレームの内容に応じて、製商品の改善が必要なこともあるでしょうし、営業や店員の顧客対応の見直しや社員教育の見直しが必要になるかもしれません。
このように、課題やリスク対応のアクティビティは情報の種類によって次工程が多様であるアクティビティとなります。ここ数年の間を見ても、製商品にたいする消費者からのクレームへの対応に敏感に反応した企業とそうでない企業の例を思い浮かべることができると思いますが、今の時代は、標準化されたプロセスに従って企業活動を行うだけでは市場の変化に対応できないということでもあります。俊敏な経営を目指すのであれば、たとえば“危機管理プロセス”をビジネス・プロセスとしてきちんと定義し、市場でのイベントの発生から適切に情報をくみとって対応するビジネス・プロセスを確立することが求められていると思います。
このようなイベントに基づく活動の連鎖を示したのが図2です。この図は、前回提示した図3とはだいぶ違っています。
アクティビティをさらに分解するとタスクになります。業務としての受注というアクティビティの中には、注文の受付、受注確定、受注取消、受注変更、顧客からの問い合わせへの対応、あるいは必要であれば顧客との受注契約というタスク(仕事)が考えられます。あるアクティビティを構成する複数のタスク間には、必ずしも作業の順序関係があるわけではありません。順序関係はひとつのアクティビティに閉じていず、複数のアクティビティ間をまたがります。それが業務フローとかワークフローと言われるものです。
業務フローで示す活動の単位は、最下位レベルではタスク・レベルと考えられます。商談、契約社内手続き実行、契約締結、受注、在庫引当、発注、納入、検品、出荷、配送、納品、請求、入金、売掛手続きなど複数のアクティビティをまたがるタスクが連携します。
業務フローやワークフローは多くの企業で作成しています。表記法もいくつかあります。しかし、問題があります。業務フローやワークフローを作成することで、ビジネス・プロセスを可視化していると誤解していることが多いということです。業務フローやワークフローは、“一連の完結した仕事の流れ”について、その開始から終わりまでの手順を示しますが、残念ながら、ビジネス活動のPDCAという全体像を示すことはできません。
PDCAのプロセス・レベルの関係とその下位のアクティビティ・レベルの活動を可視化せずに業務フローを作成していることが多いのではないでしょうか。それでは、業務フローに示されたタスクの網羅性や妥当性(必要、不要の判断を含む)をどう判断したらよいのでしょうか?また、業務フローを作成する単位をどのように決めるのでしょうか?ビジネス・プロセス図とアクティティ・レベルの図があれば“完結した一連の業務の開始と終点”をとらえることが可能です。ここでは、それを“業務シナリオ”と呼ぶことにします。たとえば、「商談から契約締結」、「受注から納品」、「請求から入金」までというような流れが、「業務シナリオ」の単位です。「俊敏な経営」との関係をいえば、イベントの発生をトリガーとして開始される業務フローでは、発生したイベントに応じて後続タスクが決定される流れとなります。また、情報の正確性と後続のタスクを決定するためのコントロール・タスクと呼ぶべき仕事を実施するような流れが必要となるでしょう。
タスクを実際に実行するためには、それをさらにToDo(やるべきこと)レベルまで作業を落とし込むことが必要になります。調査したり、関係者を集めて検討会を開催したり、資料を作成したり、あるいはコピーを取ったりなどの作業です。もちろん、そういうことはビジネス・プロセス・モデルとは関係ないことですので、図には表現しません。
ここまで、俊敏な経営を行うためには、標準化された業務活動の流れでだけではなく、「危機管理プロセス」のようなイベントに応じて異なる対応ができる仕事の仕組みを作りだすことが必要であると述べてきました。また、業務フローやワークフローだけではビジネス・プロセスを可視化したことにはならず、企業活動のPDCA全体を俯瞰するプロセスを描いてはじめて、プロセスの可視化を行ったといえるということを強調したいと思います。
2.組織構造は多段階の階層型からフラット型のマトリックス管理が必然となる
俊敏な経営を行うということは、市場の変化を迅速に取り込むために、ビジネス・プロセスをイベント・ドリブンにしていくだけでは十分ではなく、収集した情報に基づき迅速に意思決定をしていくことが求められます。それを実現するには、組織構造と権限の見直しが必要になります。
ビジネス・プロセスの構造は多段階で、組織構造への役割の割り当ても多段階になりがちでした。図1に示した構造からなるビジネス・プロセスはタスク・レベルまでブレークダウンすると、何階層くらいになるでしょうか。実際に業務を分析するとタスク・レベルまでで3−5階層になるのが普通です。そして、タスク・レベルで定義される機能が組織に割り当てられ(ひとつの組織に複数の機能)、組織の階層をたどって意思決定(経営レベルの意思決定や稟議の承認行為など)を行っていると、変化の激しい市場環境に直面している企業は、その変化に対応していくことが困難になるのは容易に想像がつきます。変化に迅速に対応できない企業では、意思決定に関わるビジネス・プロセスが多段階であることがひとつの理由になっています。このことは読者の皆様の多くが認識している通りと思います。
俊敏な経営を実現するためには、意思決定のスピードを早めることが必要です。そのためには、意思決定者である上位階層のマネジメントに市場の変化の情報を迅速にあげるか、あるいは、意思決定の権限を現場レベルに与えることが必要です。
また、もう一つ重要な点は、PDCAとの関係です。ビジネス・プロセスを最適化する視点は、ビジネス・プロセスの中を流れる情報の回転率を高めることです。俊敏な経営との関係でいえば、Doのプロセス間の情報流を早くするだけでなく、C(Check)やA(Action)のプロセス、アクティビティやタスクに情報を迅速にフィードバックし、適切な対応をとるということが欠かせないということでもあります。つまり、PDCAの観点では、ビジネス・プロセスの一つ一つのプロセスの中で、アクションやタスク・レベルの活動として、イベント・ドリブンに集まる情報をCやAの観点から判断して対策を打つ仕組みを組み込んでいくことが必要です。
従来型の古い組織と権限のモデルは縦割り構造であり、特定の事業に関わる活動にのみ責任を負う構造です。また、Doレベルの仕事を担当する組織はあくまでDoの仕事(与えられた決まり切った仕事)のみを行い、Cの権限を持つ組織(あるいは担当者)のみが、計画と実績との乖離や市場の動向をチェックする責任を持っていました。現代のように変化が激しく、市場のどこから変化が発生するかとらえどころのない競争市場では、社員が事業の視点だけでなく、顧客、取引先、を含めたマトリックス構造(一人の顧客が、複数の事業と取引があることはよくあることです)からなる市場に目を向けて、変化を敏感にとらえていくことが必要です。先進企業ではマトリックス管理は当たり前になっていますが、意思決定のスピードが求められる今日は、社員一人一人が意思決定に関与する(可能性がある)という意味でのフラットな組織構造、あるいはバーチャルな組織構造を通じたマトリックス管理を実施していくことが必要になるでしょう(社員の評価制度に影響が及びます)。
今ではSNSというネットワークを通じて市場の状況をとらえることが可能となっています。(ビッグデータの収集と分析の必要性が声高に叫ばれる所以です)その中には、ドラッカーが「ネクスト・ソサイエティ」の中でいみじくも語ったように、“非顧客からの情報”も含まれます。変化の兆候は“役割を与えられた組織”だけでなく、企業のあらゆるところから正確な情報を集めることが必要になっています。集めるだけでなく、トレンドや評判、売上状況などを分析して次のアクションにつなげるという、PDCAサイクルを回すことが重要です。
このことは、日本企業の製造現場における改善活動と相通じるものがあるかも知れません。事務作業の現場においては、現場が拾う情報の範囲は、製造、物流、営業活動あるいは研究開発と幅広いものになりますが、製造現場と同じような業務改善活動が必要なのかも知れません。製造現場以外の販売、物流、マーケティングなどの場において、情報を入手、分析、判断する活動を通じて戦略から組織やビジネス・プロセスの改革・改善にいち早く結びつけるためには、組織構造や企業風土の見直しも求められていると思います。
現在、基幹業務のシステムは完成されていると考えている企業が多いように見えます。関心は、基幹業務ではなく、基幹業務へ情報を渡すまでの、顧客との接点となる情報機器(タブレット端末、スマートフォンなど)のユーザーインタフェースか、あるいは、BI(Business Intelligence)と言われる情報の活用分野に関心が集まっていますが、俊敏な経営を目指すとなると、あらためて基幹業務のビジネス・プロセスの再検討も必要になるように思います。すぐに対応できることではないと思いますが、中長期での検討課題ではないでしょうか。
最後に、ビジネス・プロセスを可視化することの意義について一つ補足したいと思います。システム開発に携わった経験があるかたはご存じと思いますが、CMMI(Capability Maturity Model Integration)というシステム開発の成熟度モデルがあります。ビジネス・プロセスにもビジネス・プロセス成熟度モデルというのがOMGにより規定されています(*6)。日本では、多くの企業のビジネス・プロセスの成熟度はレベル1ではないでしょうか。特定のビジネス・エリアのビジネス・プロセスが可視化されてはじめてレベル2であり、それが全社的に行われてはじめてレベル3です。業務上の判断(ビジネス・ルール)がプログラム・コードの中に埋没している企業が多い中、ビジネス・プロセスが可視化されていることは“まれ”と言えましょう。ビジネス・プロセスを定義し可視化することは、ビジネス・プロセスの成熟度レベル3を目指すことと同義だということを併せて認識しておくことが大切です。
今回はここまでとします。ビジネス・モデルの構成要素の中で、まだ語っていないものとして“ビジネス・ルール”があります。次回はその点について触れていく予定です。そして、その後に本題である、情報システムのモデルとの関係について触れていくことにします。
以上
************************************************************************