March 2012 Archives

前回は、業務プロセスの骨格ということで、始点が依頼を受付けることで、中間点として意思決定というアクティビティをつなげて作業をおこない終点である報告・登録で終えるというものを提示した。今回はそれをもう少し骨組みの中味を探ってみることにします。

非定型業務をIT化するときこのプロセスの構造ということが非常に重要になります。つまり、非定型といってもはなから非定型ではなく階層化された中で、あるレベルになると非定型になるというものだからです。その一歩手前の定型化された構造をきちんと設計しモデル化することが大事なのです。

さて、そのプロセスの基本構造ですが、前回の骨格をプロセス化すると、依頼受付―単位意思決定の連鎖―作業―報告・登録となります。次に検討しなくてはいけないのが、単位意思決定の中味はどんなことをすることなのかになります。実はこの中もプロセスになっています。ですので、最初の方がマクロフローで、意思決定のところがミクロフローということがいえます。

つまりこの2段プロセスが基本構造の重要な考え方となります。マクロフローのレベルではほぼ定型的な動きになりますが、ミクロフローでは非定型的、すなわち行ったり来たり、ケースバイケース、人間の判断、調整といった決まりきった動きではないことが多くなります。ですから、順序が定型化されたものとして構造化できないのでこれ以上分解をしない方がよいということになります。

皆さんが普段やられている仕事や組織としての業務をごらんになればわかると思いますが、おおまかな流れは決まっていますが、細かいところでは決まりきったものってそう多くはないと思います。そうですよね、もしそうならば、派遣社員にまかせればいいし、中国へアウトソーシングすればいいわけです。非定型業務こそが差別化や競争優位の源泉であるのです。そんなところって単純なITではできるわけではないということがわかると思います。

さて、それでは意思決定プロセスというのはどうなっているのかですが、前回サイモンの意思決定プロセスということを提示しました。具体的に考えてみましょう。最初の情報活動とは意思決定に必要となる情報を収集することです。次の設計活動は代替案の探索・代替案の評価、つまり起案したものを検討・評価してこれでいこうという最終案を提示し、選択活動では代替案の選択、つまり意思決定と承認を行うわけです。

こうした活動を行う場合、前に言ったように定型的ではありませんから、手順を自動化するようなIT化はできません。ですから簡単に言うと"質の高い意思決定を早くできるような環境を提供する"ことが求められるのです。ではそうした環境とはいったいどんなものなのでしょうか。

それは、情報共有・コミュニケーションと有用な情報サービスの取得による意思決定ができる場ではないでしょうか。非定型業務では、チーム間や外部とでコミュニケーションをとりながら、調整や相談をすることをします。また、それぞれの活動で情報を必要としています。例えば、情報活動では事実情報、設計活動では判断情報、選択活動では制約情報といった種類のものがあると意思決定の質は上がります。

結局、プロセス構造は依頼を受付けて答えるまでのマクロフローとそこにあるミクロフローである単位意思決定を行う情報共有・コミュニケーションの場と情報サービスを受けられる仕組みがプロセス基本構造となるのです。
 

前回は、オペレーションプラットフォームが持つべき6つの要件について考えてみました。今回からは、こうした要件を満たしてくれるプロセスの構造について考えていきます。こうして、オペレーションから発想したプロセス設計が大事なってきます。

業務オペレーションはいったい何をすることなのかというと超簡単に言うと、顧客の依頼あるいはサービス要求に答えることです。そして、その答えを作るのにはいくつかの意思決定を行うのが普通です。そうした意思決定の連鎖つまり答えを作っていく過程をプロセスと規定しています。ここで顧客と言いましたが、狭い意味のお客さんだけではなくて、取引先、サプライヤー、経営者、従業員といったところからも依頼がきますので、それらを含めた広い意味での顧客を想定しています。

プロセスは大まかに言うと、始点と終点があってその間にアクティビティとよばれるものがある構造になるわけです。アクティビティはだいたいは単位意思決定というふうに考えてもらってかまいません。ではまずプロセスの出発点すなわち始点は何なのでしょうか。それは最初にいったように依頼が来てから始まるわけですから、「依頼を受付ける」ことが最初になります。

この場合の依頼の来方は様々です。電話やFAX、メールなんていうこともありますし、注文書とか依頼書とかいった紙で来る場合もあります。最近ではEDIみたいなシステム的な依頼形態もあります。しかしいずれも一旦受付けてその依頼内容を確認することをします。非定型業務だと必ずしますが、定型業務だとそのままエスカレーションすることもあります。

依頼を受付けるとその依頼項目に従って答えを作ることになります。答えを作るのが意思決定でこれも実はプロセスでもあります。意思決定プロセスというとH・A・サイモンのものが有名ですが、もうそのままです。サイモンの意思決定プロセスは、情報活動、設計活動、選択活動、検討活動の4つから成り立っています。

意思決定に必要となる情報を収集(情報活動)して、代替案の探索・代替案の評価(設計活動)を行い、代替案の選択(選択活動)し、実施し、その結果をフィードバック(検討活動)することです。日常のプロセス管理では初めの3つが重要な要素となります。

こうして、意思決定を行って、答えを作るのに何か作業がいるようなら、作業というアクティビティが入ってきます。例えば、見積を出すのに見積書作成という作業があってそれが入ることがありますし、修理依頼がきたら実際に修理作業を行って修理調製品として返すなんてこともあります。

作業が終わって、依頼に対する回答がそろうとそれを依頼元へ返事を返さなくてはいけませんし、結果をデータベースに登録しなくてはいけません。このアクティビティが終点となります。報告・登録を行ってこのプロセスが完了するわけです。こうした構造がプロセスの骨格となります。
  

前回は、Whatすなわちプロセスの仕組みはオペレーションから発想すべきという提案をしました。このプロセスオペレーションというのはおおかたは非定型業務になります。定型の場合は自動化できるので人間によるオペレーションという範疇からは外れるからです。ITに任せてしまうようなプロセスではなく、人間が介在して扱うプロセスは非定型でそのオペレーションを適切に行うためにはどんな道具が必要であるのかという発想です。

このことは何回も繰り返しますが、システムは使ってナンボ、使われてナンボだからです。決して作ってナンボではありません。従来のシステム開発の発想が作るところが主眼になっていて、それがどう使われようとも、いやもっときつい言い方をすると使われなくてもかまわないとういうスタンスだったように思います。そこを逆転させる必要があるわけで、作ったものを使ってもらうではなく、使われるものしか作らないということになります。

こうした発想になると、ITシステムというよりオペレーションプラットフォームをどうするか、どんなものの上で業務を遂行するのかというアプローチになります。そうしたプラットフォームが持つべき要件にはいったいどんなものあるのでしょうか。こんなものがあったら、こんなことができたらいいなあというものです。次のように考えています。

①ビジネス活動(プロセス)の進捗がわかること
②意思決定(データ確定・判断)に必要な参照情報を得られること
③コミュニケーションをしながら意思決定が行えること
④プロセス全体と単位意思決定の責任者が明確になっていること
⑤パフォーマンスの状況がわかり対応アクションがとれること
⑥オペレーションの結果がアーカイブされて、次に生かされること

このことは、別にITシステムだからというわけではないのがお分かりだと思います。ITがなかった昔から行われていました。例えば、進捗管理は黒板や模造紙に書いて眺めていたり、電話や机の前の会話で意思疎通を図ってしたし、参照情報はキャビネットのファイルを拡げたり、新聞のスクラップブックを見たりしていました。責任者にしても、昔の方がちゃんとしていたかもしれないし、対応アクションも現場の課長が的確に指示し早かったかもしれない。記録も紙だったけど報告書を書いていた。

つまり、何を言いたいかと言うと、ITに関係なく業務プロセス、仕事を効率的にかつ質の高いものにできるなら、そこにITを入れていくという心構えが大切であるということです。何も、ITで今までと違う特別なことをするわけではなく、ITを使うことで早くできたり、多くの選択肢から選べたり、助言や指導が受けやすかったりできるようになるということなのです。

ただ、ここで忘れてはいけないのが、今までと違う特別なことをするわけではないと言いましたが、それはあくまでITのレベルの話なのであって、業務プロセスのところでは、従来と違ったものを設計していくことが大事であるということです。こんなことを言うと、インターネットや、最近のスマートフォンやiPADの登場で仕事のやり方が変わりじゃないかと突っ込まれそうですが、確かにビジネスモデルが変わって、プロセスの変更もあると思いますが、あくまでHow toのところの話が主なような気がします。

結局大事なのは、ビジネスに貢献するための業務プロセスの仕組みと仕掛けの設計のところで、ここが肝だということなのです。それをはき違えるとやれクラウドだiPADだとか、ビックデータだとかが出てくると右往左往してしまうのです。そうしたデバイスやテクノロジーを有効に使えるようなプロセス設計ができていないといくらハイテクを入れても猫に小判システムができるだけで意味がないと言いたいのです。
 

前回は、Whatすなわちプロセスの仕組みを考えるとき既成概念から離れて新しいコンセプトのもとで考察すべきだとし、「Process Oriented」」「Operation Excellence」「Collaborative Work」というコンセプトを提示した。この考え方をベースにWhatをみていきます。

なぜ、オペレーションから発想すべきなのでしょうか。ここはなかなか気がつかないのですが、非常に重要なことです。つまり、上にあげたコンセプトの二番目にあるOperation Excellenceというのは、従来のように作ったら終わりではなくオペレーションして成果を上げて初めて終わりになるということを意味しています。ですから、成果をあげられるものでなくては使わないぞというユーザの意思であり、使ってもらってこそのシステムの価値が出るのです。

もう何度も言っていますが、作ってナンボではなくて使ってナンボなのです。使ってナンボと言っても単に使うだけではなく、結果的に目標を達成して事業成果に結び付かないと意味がありません。従って、オペレーションという中には、コントロールという意味合いも含んでいることを忘れてはいけません。コントロールというのは、制御対象の測定値が目標から乖離していた場合、それを近づけようとして手を打つことです。

プロセスマネジメントの重要な要素にこのコントロールという概念があることも忘れてはいけません。というかある意味肝のところでもあります。戦略目標からKGIとかKPIといった定量的な指標に落ちてきて、さらにプロセスメトリクスというようなオペレーションレベルの指標となります。こうして、定性的であいまいな指標ではなく、具体的な目標値をコントロールすることで成果を出すことが求められているわけです。

それと、コントロールできるかどうかは、測定値をきちんとモニタリングできているのかも大事になってきます。当然正しく、そして所定のタイミングでセンシングできないと適切なレスポンスが返せないのである。このセンス&レスポンスが不十分だと、手を打つタイミングを逃したり、危険を察知するのが遅れたりする。化学プロセスなどはここが命でうまくいかないと事故を起こしたりしてしまいます。ビジネスプロセスも基本的には同じ考え方でみていくべきだと思います。

以上のように、正確なモニタリングにより、適正なコントロールが行われ、結果的に効率的なオペレーションが維持されている状態が必要があって、それを実現させるために使う道具は何かという話です。よくそれはプラントのように自動制御でやればよいのではと言われます。

しかし、実は化学プランスのようなものとビジネスプロセスの違いがあって、何が違うかというと、科学的、論理的なのか、そうでないのかということです。ビジネスプロセスは、人間の判断という要素がたっぷり入りこんでいますので、非科学的で非論理的な部分が多いからです。ですから、多くのビジネスプロセスには、自動化されたシステムではなく、人間が使う道具が欲しいのです。
  

前回は、WhatはHowに優先するということが非常に大事であるという指摘をした。悪いWhatをいくら良いHowで作っても意味がないのである。それなのに、巷ではHowの話ばかりしていて肝心のWhatの議論がほとんどない。30年間ずっと変わらないWhatの疲労がきているのにもかかわらず。

さて、Whatとは何か。まずは少し抽象的ですが、概念を言おうと思います。「Whatとは、ビジネスの貢献する仕組みと仕掛け」としてみました。仕組みというのは別の言葉で言うと構造ですね。おなじく仕掛けは機能とでも言ったらいいかもしれません。要するに、単なる箱ではなく、仕掛けをもった、機能を具備した構造体を指しています。

ここで具体的な中味を議論する前に、コンセプトレベルでもこれまでと違った見方をする必要があります。小手先だけ変えるのでは本質的な変革はできません。これはおおげさに言えばパラダイムの転換ということです。では、これまでの「ものの見方や捉え方」はどうであってこれからどう変えるべきなのでしょうか。

システム開発あるいは業務システムの世界での従来の考え方の特徴を3つあげると、「Function/Data Oriented」「Development Excellence」「Independent Work」だと考えています。最初のFunction/Data Orientedというのは、システムを作る時に画面から、あるいはデータから考えるということです。もちろん、データ、機能、プロセスのどれもが必要なのですが、どれを中心に、あるいは先行してアプローチするかということで、これまでは画面やデータを中心にというやりかたが多かったのです。

Development Excellenceというのは、開発が目的化しているという意味になります。システム屋さんに開発してもらったはいいが、プロジェクトが終わるとさっさと引き上げてしまい、どんなふうに使われているかは無関心ということが多いと思います。要するに作ってナンボの世界なのである。

後のIndependent Workというのは、作られたシステムは、個人が画面に向かってデータを打つ、帳票を出すためのものになっていることを言っている。コンピュータは決まった時間に決まったフォーマットでデータを入れろと命令してくる。それに個人が一生懸命答えているという姿が浮かんできますよね。

どうもこれではいけないと感じていると思うのですが、ではどう「ものの見方や捉え方」を変えるのでしょうか。上に挙げた3つに対しての新しいコンセプトは、「Process Oriented」「Operation Excellence」「Collaborative Work」です。画面やデータに対してプロセスを中心に考えましょうということ、作ってナンボではなく使ってナンボなんですよということ、個人の作業ではなくチームとして情報共有の場で仕事しようよという意味になります。

新しいコンセプトと言いながらふと考えたのは、別に新しいことではなく昔から業務や仕事の場では当たり前のことなのではないかということである。だから、システムの世界が現実から乖離していたという言い方もできる。なぜもっと素直に現場で行われていることを写像しなかったのかと思うのであるが、これは別のところで書く。

とは言え、業務システムにとってはコンセプト変えることであり、着手点もHowではなくてまずはあるべきWhatの姿を考えて見ようというのが大切な態度だと思うのである。
  

昨日、目黒の雅叙園で開かれた第7回BPMフォーラムに参加する。もう7回目になるわけだが、終わってから事務局の人たちと打ち上げしたとき感慨深けによく続いたたなあと言っていた。ぼくはほとんど出ているので、その変遷というか流れを見てきたが、今回の特徴はおそらくユーザの人たちの割合が増えてきたことではないだろうか。

はじめた当初は、ベンダーの人たちの参加も多く、どちらかというと開発メソッド的な捉え方でBPMは見られていたように思う。そしてある種の期待感があってこれから導入企業が増えてきそうだという観測もあったのである。ところが、IT投資が抑制されているという面もあって、新たな投資案件にBPMを適用するという例がなかなかあらわれないという現象が続いている。

従って、最近の傾向としては開発ツールとしてのBPMSといったトーンが薄れてきて、プロセス改革に向けた、いわゆるビジネスマネジメントの活動といった側面が表に出てきているといえる。これは本来のBPMに近づいたわけだから非常によい方向である。だから、ユーザ企業の人たち関心に答えることをしていかなくてはいけない。

知り合いの何人かのベンダーの人と話していたら、単にBPMSを売ろうとしてもなかなか売れないと言っていた。ツールを売るというスタンスだとシステム屋さん向けにプロモーションすることになるが、情報システム部門のひとたちにプロセス改革といっても通じないと嘆いていた。だから、経営者と事業責任者へアプローチしないといけないのだが、それが不十分で今後の課題だと言っていた。

そうした流れを象徴的に発信した(と思っている)のが、日本BPM協会のBPM推進フレームワークで、フォーラム冒頭でも事務局長の横川さんの方から紹介があり、それを受ける形で午後の最後のセッション「これからの業務改革アプローチ:BPMは、こう取組む~実践事例に見る新・推進フレームワークの有効性~」で報告を行った。

このセッションでは、推進フレームを作ったコモンセンス部会(ぼくもメンバーです)のリーダの岩田アキラさんからフレームワークのコンセプトや意義について話して、そのあとぼくのほうから実践事例を紹介し、後は協会理事である太田大作さんがモデレータとなったパネルディスカションを行った。

全部で55分という短い時間だったので、ぼくのプレゼンも15分しかなく言いたいことが言えなかった面もあるのだが、最低限のことは主張できたかなあと思っている。新しいフレームワークのポイントは、まずは従来のデータベースアプリケーション主体からBPMアプリケーションに軸足を移そうよねというパラダイムの転換を訴えたことがあります。このことは以前からずっと言い続けたぼくとしては大変心強く感じました。

それと、PC、PD、POという3つの環をシンボリックに表現したことです。Process Change(プロセス改革推進)、Process Development(プロセス開発)、Process Operation(プロセスオペレーション)が三位一体となって動く姿を提示している。特にオペレーションの位置を引き上げたことが特記されるところです。従来のBPMではあまり表にでてきていなかったところで、オペレーションできちんと成果をあげなければいくらいい戦略をたてても、いくらいいツールを使ったとしても何ら意味のないことなのである。

ということで、ぼくの年来の主張が埋め込まれたものになり、こうしてプレゼンもさせていただけたことが大変うれしく思う。セッションが終わったあとに出席者のアンケートを見せてもらったのだが、もっと詳しく聞きたいといった声も多く好評だったようななので早速追加セミナーを開こうという話になった。ぜひ、皆さんと一緒になって議論する形で実現できたらいいと思っている。

他のセッションや基調講演にも触れなくてはいけないのだが、まだちょっとプロセスという概念がばらばらのような気がする。ただ、わりと事例を中心にな話されているという印象でよいことだと思うのだが、欧米の金融、保険、証券といった例はまだこれからという日本の企業には突出しすぎているように感じられた。プロセスの適用というのは様々なところがあり、あまり製造業でいう工場のような領域(例えばATM、株取引、切符発券、空港オペレーションなど)は、少し分けて考えた方がいいように思う。
  
前回は組み合わせで効果を出すということで、対立概念のいいとこどりのようなことを書いた。今回は、人とITの組み合わせということについて考えてみようと思う。いまの情報システムについていちばん大きな過ちというか勘違いは、システム化イコールIT化だと思っていることである。

おそらくコンピュータの出自からして勘違いしやすい歴史がある。元々「電子計算機」として登場してきたので、手で計算するとかそろばんを使って計算するといった人間の所作の代替を行うことが役割であったから、それがシステム化であると考えたのである。それがだんだんとコンピュータによる自動処理という方向に行って、システム化イコール自動化へと進んでいった。

一方で自動化できないものもあるのだが、そこはシステム化の対象外ということで片づけてしまっている。一時、人工知能(AI)なんていうのがもてはやされていたが、結局一部の定型的な処理に近い領域でしか生き残れない。それは当然で、人間の判断をコンピュータが替わってやれるとは思えないからである。

ですから、会社における業務も、もっと広く人間の営みは必ずコンピュータ、ITでは代替できない部分があるということである。そう考えると、発想を変えてみる必要があるのに気づく。つまり、主体をどちらに置くかという問題で、従来はシステム化というとITを使って自動化をめざすことに軸足がいっていたのを逆にすることを薦めたい。

主体をITから人間に置くという意識が重要になると思う。いずれにしろ、"人とITの組み合わせ"でやっていくしかないのだから、そのとき人間がITを使うという関係が実は最も効率的で、経済的であるのではないでしょうか。すなわち、人間がITを使うという意味は、使えないITは使わないという単純な関係をも言っているわけで、役に立たないITを導入することはあり得ないのである。

こうして、人とITの組み合わせという中でその割合なり、重心をどこに置くかはケーバイケースである。会社の規模や成熟度、あるいは対象とする業務、投資能力といったものに左右されてくる。それと大事なことは、アウトプットの完成度というか、あくまで100点をとろうとするのか、70点でよしとするかという考え方で、その会社の事情にあった最善のコストパフォーマンスをねらうことだろう。

従来のアプローチだと、ITシステムを導入することが目的化していて、そこは人間にまかせればいいというような部分にもITを導入するというムダを平気でやっていたと思う。ムダならまだいいかもしれなくて、かえって逆効果になることもある。例えば、自動化が進み過ぎて、そこでひとたび異常が発生してもだれも修復できないという悲惨なことも起きる。

結局、人とITのその時点での最適な役割分担を自分たちの組織能力や手持ちリソースあるいは風土などを勘案して決めていくことが大切である。そして、その"システム"を運用していくうちにIT化したほうがいいところを後から追加して行けばいいのである。こうした柔軟な取り組みをぜひ行っていってほしいと思う。
  

About this Archive

This page is an archive of entries from March 2012 listed from newest to oldest.

February 2012 is the previous archive.

April 2012 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Pages

Powered by Movable Type 4.34-en