July 2014 Archives

(4)期待と効果
BPMに何を期待するのでしょうか。その期待に既存の手段では応えられなかったからBPMに期待するのでしょうか。もし、このあたりが明確になっていて、効果が実感できれば、今頃は大ブームになっているはずです。ところが、徐々に浸透してきているとはいえまだまだのようです。ということは、期待するところがないのか、期待することはあるのだがBPMではできそうもないと思っているのかのどちらかなのでしょう。

おそらく今の経営者は期待するところというか、自分たちを取り巻く環境の変化に対して臨機応変に手を打っていかないと持続的な発展どころか事業の継続さえ危なくなるという危機感は持っていると思います。ですから、俊敏にかつ的確に経営の舵取りができる仕組みと仕掛けを期待しているはずです。

そうした期待をかつてはERPやCRMなどに求めたと思いますが無理だったというのが定まりつつあると思っています。ただ、まだまだERPを入れればプロセス改革ができると思っている人もいるように、大金をかけた割には効果がないと分かっていながら、ではどうしたらいいのかと悩んでいるのかもしれません。そうした人たちがそこはBPMだとなぜ飛びつかないのでしょうか。

プロモーションの不足といえばそうなのだが、難しいのは、これこれの問題があるからそれを解決するものとしてBPMがあるといった単純さで訴求できないところがあることです。たとえば、在庫が多いからそれを削減するために在庫管理システムを作ろうといった場合などはわかりやすいのですが、BPMと在庫削減が結びつかないと言われてしまうのです。

つまり、BPMというのは大前提が"ビジネス(事業)全体のプロセスを記述する"ということなのですが、そこがなかなか始められないのです。大前提という意味は、プロセスを書くことで自分たちのやっている事業がいったいどんなものなのか、どんなことをしているのかが俯瞰できるからなのです。すべてはそこから始まるのです。先ほどの在庫の問題にしても単に在庫の部分だけを見ていては、真の原因を見損なってしまうこともありえるのです。

自分たちの事業をプロセスという姿で掌中に納めれば、そこにどんな問題が潜んでいるのか、こういう戦略を実行するにはどこのプロセス改革を行えばいいのかがわかるようになります。これがBPMに期待する大きな理由です。ただ、いま言ったように直接的な問題解決にすぐにいけないので、"せっかち"な経営者になかなか理解してもらえないのかもしれません。

BPMのプロセスを記述して俯瞰して見るということは多くの効果をもたらします。本事例でも、まずプロセスを書いてそれを皆で眺めているとさまざま問題点や課題が浮かんできました。というのも、プロセスというのは多くの要素から成り立っていますから、どの要素に問題があるのかがわかるわけです。業務ルールの不備で混乱しているとか、責任の所在がはっきりしていないとか、同じような仕事を重複してやっているといったようなものが抽出され、そこを改善することで多面的な成果が生まれてきます。成果の主なものは次の3点でした。

事業成果の実現
人材育成、組織能力の向上
IT投資の低減

事業成果の実現では、当初の狙いが、標準品から特注品にシフトして売上を増加させることでしたが、それは特注品の売上を前年比でほぼ倍増させることができて成果を確認できたのですが、予想外というかうれしい誤算だったのが②の人材育成、組織能力の向上という成果です。

え、BPMで人材育成、組織能力の向上?と思われるかもしれませんが、実際に成果が上がったことです。プロセスで自分たちの業務も捉えるわけですから、自分が何をすべきか、他の人が何をやっているのかが見えてきます。そうすると、チームで働くことの意義を自覚でき、結果的に組織能力も向上し、人が育つことにつながるのです。

【成功のポイント】
ビジネス成果を得るには自分たちのビジネスプロセスを手のひらに乗せること、またBPMの大きなメリットである人材育成・組織能力の向上には、多くの人を参加させて大いに議論し成果を共有できる体制をとること
  

さて、最後の誤解は「ワークフローのことである」です。これはよくある誤解ですね。ただ、プロセスとワークフローの違いについて明確に規定したものはないでしょう。ということは定義の仕方でプロセスにもなるしワークフローにもなると言えます。ですから、ここは筆者の定義をベースに明らかにワークフローなのに業務プロセスと名乗っていることの間違いを指摘したいと思います。

また、ワークフローとBPMの違いをいう人がいますが、これは土俵が違うので比較することに意味がありませんので注意してください。業務とか仕事の流れをどう呼ぶかという観点になります。両者とも言い方としては、インプットがあってそれに対して何らかの処理を経てアウトプットを出すということでは一緒です。従って、どんな構造をもっているのか、どんなことをするのか、どういう使われ方をするのか、そして何のためにあるのか、という切り口でみていくことにします。構造、機能、使い手、目的の違いを検討するということななります。

まずは構造という問題です。先ほど言ったように両者ともインプットとその中間の過程とアウトプットから成っているといいましたが、ワークフローの場合は、そのフローが基本的には一層になっています。つまり、中間の過程がアクションとか単位作業になっていてそれは分解できない構造になっていることです。それに対してプロセスは、しばしば階層構造をとることになります。

プロセスでは中間過程は複数のアクティビティから構成されますが、その個別アクティビティにサブプロセスを持つことがあります。そして、そのサブプロセスがワークフローであることもあるわけです。中間過程の粒度が違うのです。つまり、プロセスはワークフローも内包したような大きな包括的な構造をもったものなのです。

次にどんなことをしたいのか、どのような機能をもたせているのかというところです。モニタリング機能が大きいように思います。そこから、パフォーマンス管理やプロセスコントロールといったところへ持っていくことがプロセスの重要な機能です。

使い手の問題が一番わかりやすいかもしれません。ワークフローは基本的には個人が使うものです。典型的なワークフローに申請承認ワークフローというのがありますが、これは個人が願い出てそれを承認してもらうという流れですから割と単純なフローで個人用になります。プロセスは組織としてチームとして業務処理を行うためのものです。要するに個人競技と団体競技の違いです。

最後の目的という側面では、ビジネスとの結びつきの程度が問題になります。ビジネス上の要求に応えられるかどうかです。戦略とか事業方針、あるいは改革課題といったところから絶えずビジネス要求が出てきますが、その受け皿にワークフローはなれるでしょうか。個人の仕事の流れであるところでは無理です。すなわち、重要な差異はビジネス要求を実行する仕組みとしてプロセスがあり、個人レベルのタスクを処理する仕組みとしてワークフローがあるということではないでしょうか。
  



(3)継続的な活動
BPMの非常に重要な考え方に継続的な活動というのがあります。よくBPMとBPR(Business Process Reengineering)が混同されますが、BPRというのは、時限的に改革するイメージです。それに対してBPMは継続的な活動です。ここまでやれば終わりということがないのです。

プロセスというのは、化学プロセスや生産プロセスなどをみてもわかるように所定のアウトプットを出すために連続的に稼働させるものですから、そうしたコントロールすることと同時により早くとかより多くといった改善を行って行きます。ビジネス・プロセスも同じように絶えずプロセスの状態をセンシングして、管理範囲から外れないようにコントロールしなくてはいけません。

継続的な改善活動は、プロセス内での改善、たとえばアクティビティを中抜するとか、適用ルールを変えるとか、参照情報を増やすとかいった改善もさることながら、新しいプロセスを追加するといったこともあります。ビジネスモデルを変えた結果、それに見合ったプロセスが求められた場合とかです。

本事例では、取り扱い商品を標準在庫品から特注品へとシフトしました。そこでのキープロセスは「見積提示プロセス」でした。顧客要求をきちんと把握して、それを設計部門にエスカレーションして、粗々の設計を行い、提案図面や原価を算出してもらい、製造部門と相談して納期を決め、見積書を作成するといったプロセスです。

最初の重要なポイントは顧客要求確認シートです。特注品の場合は顧客の真の要求を聞き出すのはなかなか難しいものです。ベテランの営業だと経験から導き出すことができるかもしれませんが、若手だとインタビュー項目に抜けがあったままで設計に渡したりするので、聞き取りをやり直すこともしばしばでした。そこで、あらかじめ聞くべき項目を設定してそのシートに埋め込むことにしました。

ただ、最初から完璧なものはできるわけではありませんから、とりあえず必要最低限のものを用意しておいて、不足するものがあったらあとで追加するといったやり方をしました。ですから、常に追加、修正を繰り返すしながらブラッシュアップするわけです。こうした継続改善は他のアクティビティでも同様にやっていきます。

こうしたことで特注品の売上も伸びたのですが、既存顧客を相手にしているとやはり頭打ちになってきます。そこでビジネスモデル上の顧客セグメントを見直すことになります。新規顧客の開拓が必要になるわけです。そうなると、いままでのプロセスだけではうまく行かなくなります。ビジネスモデル要素のどこがポイントとなるかによってキープロセスも違ってきます。

この場合は言うまでもなく「新規顧客開拓プロセス」ということになります。どういう業種業態なのか、地域はどこなのか、会社の規模はとかのターゲットを決め、キャンペーンをどんな風にやるのかといったことが並んだプロセスが対象となります。といったように、日常的な課題を解決するようなところから、ビジネスモデルの変化に対する対応といったところまで、継続的な活動を行うことが大変大事なことになのです。

【成功のポイント】
継続的な取組みでプロセスを進化させること
誤解の4つ目は「データや機能は重要ではない」ということで、ITでよく出てくる3文字熟語とかキャッチフレーズは、ぱっと注目されて流行りだすと、あたかもそれ一辺倒になることがしばしば起こります。昔のことでいうとクライアント・サーバーが言われた時は、メインフレームは全部駆逐されるのではないかくらいの勢いだったし、ERPの登場は猫も杓子もERPだと叫んでいた。だからBPMというと(まだは流行っていませんが)プロセスだけだと誤解するかもしれません。

システムだからどれか一つだけということはありえないわけで、さまざまな要素が複合して構成されているから、どこを重要視するのか、どこから始めるのかとかいった軸の置き方が違って来るだけなのです。筆者はITシステムは大きくプロセス、データ、機能(UI)から構成されているという捉え方をしている。フローとストックとインターフェースということです。

このシリーズで強調しているのはITシステム構築はプロセス中心、プロセス先行で行こうよねということです。そうなると、データとかUIはどうなるのかということなります。もちろん両方とも絶対に必要です。ただ、イノベーションを支援するという目的を考えると、データをマネジすること、UIを充実させることがそれにあてはまるかというとこうではないように思います。

画期的な商品の開発とか、圧倒的な市場占有率の獲得とか、卓越した商品提供力といったことはプロセスを重視したアプローチが有効であると言えそうです。では、データとかUIの出番はどこなのだろうか。まず、データですが、以前DOAというのが注目されました。データ中心アプローチでシステム開発をするというもので、せっせとER図を書いたものです。
  
しかしながら、それはあくまでITシステム、もっと正確に言うとデータベースシステムを作るためのものであったと言わざるを得ないと感じています。つまり、データの登録・更新、検索、帳票出力の仕組みをDOAで作ったわけです。DOAにおけるデータの捕捉を画面と帳票から行うということはそれを意味しています。ですから、プロセス表現が難しいしわかりにくいのです。

では、データ中心は必要ないのかというとそうではありません。データには大きくリソース系のものとイベント系のものがありますが、リソース系すなわちマスタデータはデータ中心で捉えるべきなのです。ビジネスを行うためのリソースを整理しておかなくてはビジネスモデルを変えるにしても、プロセスを改革するにしてもできないわけで、先行してデータベースを設計しておかなくてはいけません。

一方、UIは最近ではスマホに代表されるデバイスの多様化、進化があります。これは、顧客やサプライヤーといった外部接点にしても、あるいは内部の従業員にとっても使い勝手のよい、効率的な機能を要求していけるようになったわけです。ですから、プロセスサイドからの要求としての機能は当然ありますが、マンマシンインターフェースはプロセスとは必ずしも関連しないでも設計していくことになります。繰り返しますが、プロセス、データ、UIは重要となるエリアが違うのでそれ相応のアプローチが必要であるということです。
  

(2) 戦略課題の具体化と解決
リーマンショックのような経済全体が減速してしまうような場合、売上の落ち込みが激しいのは標準在庫品です。何がなんでも必要というわけではなくユーザにも在庫もあるでしょうから買い控えもできるからです。つまり標準在庫品の販売は景気の変動に弱いという性格をもっています。景気が安定して経済成長も右肩上がりの時は問題なかったのですが、経済成長は停滞しているがビジネス環境のへ変化が激しい時代ではそうした時代にマッチしたビジネスモデルに変える必要がでてきました。

ビジネスモデルを変えるには戦略が必要です。そこでよくとられるものが顧客・市場戦略です。事例では、標準在庫品では景気に左右されるというのなら特注品にシフトしたらどうかというのが新たな戦略として出てきました。こうした戦略立案には理論あるいは技法のようなものがあるのかというとありません。おそらく経営者のひらめきがいちばんではないでしょうか。

しかし、単なる思いつきというわけではありません。大事なのは経営者の頭のなかにこうした会社にしたいという経営理念、こんな事業をやりたいというビジョンがしっかりともっていなくてはいけないということです。そしていったんやると決めたら従業員に対して明確に考えを伝え、思いを共有することが重要です。

ところが、その掛け声だけでは新しい戦略の実行はできません。必ず、何か新しいことをやろうとするとそれを阻害するものが現れます。一番大きな阻害要因はいったい何でしょうか。これもよく言われるかと思いますが、従業員の意識の問題です。大部分の人は基本保守的ですから、今やっていることを変えたくないという意識が働きます。

ここでもまた、「意識を変えろ」とか叫ぶだけでは変わりません。従業員は変化の結果として自分の仕事がどう変わり、負荷がどうなるのか、責任が重くなるのかといったことが気になります。それがわからないうちは不安のほうが先にあって、そのためにどうしても保守的にならざるを得ないわけです。

また、会社として収益がどうなるのか、売上が増えてくれるのかといったことを示してくれたら、儲かりそうだからがんばってもいいかなと思うのです。つまり、会社として、事業としての変化の仕方とその結果についても、そして個人としてのタスクがどうなるかを見える化することが大変重要なのです。

それと、現実的な阻害要因の洗い出しも必要になっていきます。リソースの問題として不足はないのか、業務管理として不備はないのか、いまの組織や責任の所在で対処できるのかといって検討である。事例では、特注品へシフトするわけですから、顧客要求をきちんと聞き取らなくてはいけませんし、また設計者の負担も増え、ちゃんと見積もりをしないと赤字なのに受注してしまうといったことが浮かび上がってきます。そこから課題を抽出していくわけです。事例では下記のような課題が出てきました。

・ベテランの営業に依存しない要求確認
・収益性を確保した見積
・役割分担の確化

BPMアプローチでは、プロセスを記述することで会社全体、事業全体といったマクロな視点での見える化ができ、また詳細化したプロセスでは、課題を解決するために必要な機能がはっきりしてきますので、新しい戦略を実現するオペレーションのイメージが出来るのです。

【成功のポイント】
トップマネジメントが経営理念に基づいて明確なメッセージを発信し、強いリーダーシップを発揮すること
  


次なる誤解は「新たな業務プロセスを開発する」ということになりますが、誤解が誤解を生むかもしれないので少し注意が必要です。というのは、新たな業務プロセスを全く開発しないのかというとそんなことはなくて、場合によっては開発することもあるからです。

ここであえてこういう表現をしたのは、最初から新しいプロセスをつくり上げるのだと意気込まないほうがよいという警鐘をならしたかったからです。業務システム構築のプロジェクトが発足すると、IT化されていない部分がプロセスがないかのように錯覚して、そこが問題だと言わんばかりに新業務システムを開発するのだということになる。

ただ、最初に言ったように結果的には新たなプロセスにはなるのだが、順序が逆なのです。つまり、AsIsとかToBeというのをあまり意識せずに素直に業務プロセスを記述することから始めたらどうだろうか。なぜなら、業務プロセスというのは、ビジネスをやっている以上必ず存在するもので、意識、無意識に関わらず日々プロセスを回しているのです。

それは、マクロレベルのプロセスを見ればわかると思いますが、会社の大小、業種・業態に関係なしに共通的なもので、例えば販売、購買、受注出荷、生産なんていうプロセスは同じプロセスです。ですから、それをIT化しているから高度なプロセスであるというのも一概には言えないわけです。ホワイトボードとメールで仕事していても良いプロセスということだってありえます。

システム化のアプローチとして、最初に新しい業務プロセスを開発するのを目的化するのではなく、あくまで、自分たちのビジネスをオペレーションするためにはどんなプロセスになっているのがよいのかの観点でプロセスを記述することです。そこから、さまざまな問題が浮かび上がってきます。

個人の裁量で進めていたり、お客さんを無視して自分たちの都合だけで処理していたり、時間がかかっても平気だったり、ルールに従わなかったりといったプロセスの仕組みというより、プロセスを進めるための仕掛けのところの不備だとかが問題になってくる。こうしたプロセス管理に不可欠な組織能力をどう醸成していくかが大きいような気がします。

広義の意味ではこれもプロセスとも言えるのですが、フロー的な部分よりもこちらのほうが開発要素が多くあるのではないでしょうか。例えば多く見受けられるのはルールの欠如と役割の不明確です。このことは、別な言い方だと業務フローを変えるのが業務プロセスを開発することだとは必ずしも言えないのです。ルールがない中で業務フローを変えても意味がないのです。今回はプロセスとはが頭に入っていないとちょっとわかりづらかったかもしれませんね。