前回、システム構造や開発にも「中庸」の考えかたが必要だということを書いた。そして、対立概念のバランスとか組み合わせが大事であるということを言った。その組み合わせという意味を少し考えてみようと思う。

世の中というものは「陰陽説」を持ち出すまでもなく、大小、長短、明暗といった類から、収縮・膨張、遠心力・求心力といったものまで様々な対立的な概念が存在する。ただ、そうした対立概念のどちらか一方しかないということはあり得なくて、どっちに軸足があるかといった差であると思う。また、場合によってその軸足を変えることもある。

ここでシステム構築のケースについてみてみるとトップダウンアプローチかボトムアップアプローチかという議論がある。具体的には「非定型業務のIT化」というエントリーでも言及しているのでそちらを読んでもらうとして、コンセプト的な話をここではする。

簡単に言うと、トップダウンというのは、上位の戦略からだんだんと分解・詳細化してシステムを開発するというやり方で、一方のボトムアップというのは、システム構造からそれに合うようにセットアップしていくやり方である。もちろんどちらがいいのかということではなく、その特徴をよく理解して使い分ける、あるいはそれらを組み合わせて最適化することが重要になってくる。

ここで少し話はとぶのですが、別のアプローチ法として問題解決型か仮説検証法かなんて議論もある。これも使い分けと組み合わせであることは言うまでもない。さて、トップダウンとボトムアップでは上記のものとどういう組み合わせになるのだろうか。

おそらくトップダウンは、問題解決型アプローチとの組み合わせになり、ボトムアップは、仮説検証型アプローチになると思うのである。トップダウンというのは、上位の戦略とか事業方針、ビジネスモデルというようなところで問題点や課題を抽出することを行う。つまり、そうしたビジネス要求を実現するための課題をどう解決していくのかという観点でシステム化を行うわけである。

それに対して、ボトムアップでは、業務プロセスをオペレーションするためにはどんな仕組みと仕掛けにしておくのかという見方をする。そして、そのコンセプトはある程度構造化できるので、その構造と機能を仮説として提示するわけである。そこに実際の要求事項を埋め込み、オペレーションの実行性を検証するのである。

どちらか一方だけでやりきれるかというと難しいというのはお分かりだと思います。トップダウンで分解・詳細化しても実際にオペレーションに供する仕組みと仕掛けは出てきません。また、ボトムアップで口を開けて待っていてもビジネス要求は出てきません。

ですから必然的に役に立つシステムを構築しようとするとトップダウンとボトムアップの組み合わせにならざるを得ないのである。トップダウンの下降点とボトムアップの上昇点を適当なところで出会わすことが大事になるのです。これを「ハイブリッド型アプローチ」と呼んでいる。
  
昨日に引き続いてPRめいたエントリーになります。今月の15日に「ICT経営パートナーズ協会」の2回目の理事会がありました。この協会は昨年の11月に発足して、様々なことを詰めてきてようやく実質的にスタートが切れる態勢が整ってきました。

元NECソフト社長で、昨年6月までITコーディネータ協会会長を務めた関隆明さんの熱い思いがあって、その人脈から多くの人材が集まりました。こうして集まったIT経験の深い専門家の人たちが協働してICTを活用した経営のお手伝いをしようではないかということで組織化されたわけです。

最初は各自が保有しているスキルやソリューションをセミナーやWebサイト、メルマガなどで発信し、お客さんをつかんでいきます。そして実績を積み上げることで知名度もあがり信頼を得ると、逆にお客さんから相談を持ちかけられるようになることを企図しています。売り込み型から受け入れ型へ変換していきたいのです。

何でも相談サロンにいけばどんなことでも解決してくれるという風になるといいなあと思っています。そのためには、単発的なソリューションではなく、経営からITまで総合的かつ複合的な解決策を提供しないといけなくなります。メンバーのスキルセットを組み合わせて新たなソリューションパッケージやサービス化をする必要があります。

ともあれ、ぼくは一応理事ということで名を連ねているのですが、他の理事の人がみな社長さんばかりで、肩書のないのはぼくぐらいなのですが、いまやっているプロセス中心アプローチでのシステム構築をもって実績を積んでいきたいと思っています。この記事をお読みになっている方々も機会があったらお声かけ下さい。
  

3月6日に目黒の雅叙園で開かれる「第7回BPMフォーラム2012」で登壇することになりました。BPM実践事例/ソリューショントラックの最後にあるセッション「これからの業務改革アプローチ:BPMは、こう取組む~実践事例に見る新・推進フレームワークの有効性~」で事例の紹介のプレゼンとそのあとのパネルディスカッションに参加します。

内容的には、岩田アキラさんのほうでBPM協会で作成したばかりの「BPM推進フレームワーク」の説明をしていただいて、私の方から事例ということで一昨年、昨年にわたって製造業を営むある中小企業で行った「業務見える化」プロジェクトの成果について発表します。実践した例が、結果的にこの推進フレームワークに準じたものになっていたいうトーンの話をします。

「BPM推進フレームワーク」は以前からありましたがその改訂版となります。このたびのポイントは、ニュースにもありますように、3つの輪のコンセプトにあります。すなわち、「プロセス改革推進」「プロセス開発」「プロセスオペレーション」の3つの輪が連動して動くことです。このことはずっとこのブログでも言い続けてきたことで、特にオペレーションの重要性を引き上げていることに特徴があると思っています。

要するに、従来のように開発に重きを置いたものから実際の業務運用のところにも重心を向けたことです。つまり、作ってナンボの世界から使ってナンボという世界へ移行させたところです。そうなると、必然的にユーザが主体となった取り組みとなり、先日も書いたように、BPMはIT活動ではなくビジネス・マネジメント活動であるという色合いが濃くなります。これがBPMがめざす本来の姿ではないでしょうか。

そんな考え方や姿勢が伝わればいいと思っています。ぜひ「BPMフォーラム」に足を向けてビジネスに貢献するためのアプローチとしてのBPMを感じていただきたいと思っています。私にご連絡いただければ参加費の割引が受けられますのでお申し出ください。
 
岩田研究代表の岩田アキラさんが、米国のBPMコミュニティ誌「BPTrends」におけるポール・ハーモンとセリア・ウォルフの最新の投稿について記事を書いている。それによると、BPMもだいぶ変化を見せてきたようだ。

大きく5つのポイントをあげている。

1.BPMは"IT活動"ではなく"ビジネス・マネジメント活動"との認識が広まった
2.プロセス改革アプローチを強調するプロフェッショナルの堅実な需要
3.プロセス・モデリングの企業内浸透と組織パフォマンス向上の多様なテクニック論
4.BPMS市場の変化
5.BPMへの国際的な関心の高まり

詳しくは記事を読んでもらえればよいのですが、岩田さんも最初に"この変化傾向は、日本BPM協会メンバー間でも予見していた事項で、同レポートを読んで「やはり..海外でも..」といった感想である。"と言っているが、ぼくもこの協会メンバーの一員で岩田さんともしょっちゅう議論しているので確かに最近の論点によく似ている。

このたび日本BPM協会では「BPM推進フレームワーク」をリニューアルしたが、BPMは"IT活動"ではなく"ビジネス・マネジメント活動"という意識が強く働いている。従って、BPM推進には「プロセス改革推進」「プロセス開発」「プロセスオペレーション」の三位一体の取り組みが大事だと謳っている。

そして、それを担う人材として、ぼくはビジネスエンジニアと呼んでいるが、レポートにあるようなビジネス・アナリストとかビジネス・アーキテクトといった人材が望まれるようになったのである。システム・エンジニアとかITアーキテクトではなくあくまでビジネス視点を持った技術者である。

3に書いてあることは、1に呼応しているわけだが、以前はBPMというとBPMソフトウエアを使ってシステム開発を行うという意味合いが強く、従ってユーザ側も開発方法だからベンダーにまかせればいいやという感じでもあった。

しかし、プロセスを設計することは、ITシステムを設計することではなく、自分たちの業務を設計すること、しかも業務は戦略や改革要求を実現するものとして設計しなくてはいけないことに気がついて、そうなるとベンダーなんかにやらせるわけにはいかないとなってきていると思うのである。

やっと、ビジネス寄りでBPMを考える機運が海外で出てきたことをうれしく思っている。日本では、いくら国内で声をあげてもなかなか取り上げてくれないので、海外でのこうした声が早く日本に届いて理解が進むことを願ってやまない。
 
前回、プロセス参照モデルからレベル4までの分解を行いました。具体例でいうと受注生産品の見積提示プロセスの引合見積プロセスを見積依頼の受領・確認―見積条件の検討(与信)―見積条件の検討(プロダクト・価格)―見積条件の検討(納入条件)―見積回答の作成―見積回答の送付というふうに分解しました。

更にその中身を見ていくと、例えば前回も例にしましたが、見積条件の検討(プロダクト・価格)というプロセスがあります。そこのプロセス定義をどうするかというと、プロセス名、目的・機能、インプットデータ、アウトプットデータ、ルール、パフォーマンス、担当責任といったところを記述します。インプットデータは指示情報とか参照情報で、アウトプットデータはプロセスの成果物になります。例で言うと、要求仕様や製品カタログ、価格表、原価、見積履歴などがインプットで、商品番号や見積価格がアウトプットになります。

さてこうした定義がされたあと、どう実装するのかを見ていきます。というとこのレベルで実装するのかという質問が飛んできそうです。おいおい分かってきますが、このレベルで実装してしまうというのがポイントになってきます。これを従来のやり方だとどうなるのでしょうか。従来のやり方というとスクラッチでコードを書く、パッケージを持ってくる、フレームワークをカスタマイズする、クラウドを利用するなんてことになるかもしれません。   

これでできるでしょうか。見積書に記載するプロダクトとその価格を決めるプロセスをコードで書くのか、パッケージを持ってくるのかですが、実は従来の開発ではここのところは無視されています。どういうことかと言うと、プロダクトと価格が決まったあとにその情報を登録する画面を開発することが行われていたということです。

レベル4のプロセスをそのまま実装したいという意味は、登録するデータを決めるまでが大変重要でそこをITを活用して効率的に質の高い決定を行いたいからです。このあたりはもうすでに書いてきたなので繰り返しませんが、せっかくプロセス記述でビジネス要求を埋め込んであるのでそれが反映できるようにしたいのです。単に、データを登録するだけだとビジネス要求がどこかへ行ってしまいます。

世の中に多くの見積システムというのが提示されています。SFAとかCRMの中にも入っていたり、クラウドでも提供されています。しかしながら、このシステムの構造をよくみていただきたいのですが、ほとんどが「見積書作成・承認プロセス」です。見積書のフォームが出てきて、そこに必要なデータを登録して、それを上長が承認し、プリントアウトするという仕組みだと思います。

くどいようですが、そこに登録された価格や納期はだれがどうやって決めたのでしょうか。そこが重要であり、後々にも活かされるノウハウになるかもしれないのです。また、さきほどクラウドでという話がありましたが、クラウドだからいいアプリケーションがあるということではありません。あくまで運用のプラットフォームでしかないのです。ということで、従来のやり方ではビジネス要求を実現するための非定型業務の実装は難しいのです。
  

ちょっと前に、特許庁のシステム開発プロジェクトが55億円もの予算を突っ込んだ挙句にとん挫してしまったことが話題になった。2006年から始まったプロジェクトであるが、設計ができずにあきらめたようだ。特許庁は開発ベンダーである東芝ソリューションの能力不足を責め立てているが、どうもそんな単純な問題ではないように思う。

ぼくはむしろシステム化以前の要求定義のところに問題があったと思う。そうなると、ITベンダーというより発注者側の特許庁の方に責任があるのではないだろうか。役所も大企業もそうなのだが、日本ではSIerにお任せという姿勢がほとんどで、RFP(Request for proposal)も自分たちが書かないでSIerが書く場合も多い。従って、お任せされてもやりきれる大きなSIerしか受注できないという構図である。

つまり、発注者側であるユーザのシステム開発に対する姿勢とそう仕向けているSIerに大きな問題が横たわっているのがわかる。自分たちの要求を抽出して定義することができないユーザとそうした情報の非対称性を悪用して大きな利益を得ようとするベンダーが反目するのではなく馴れ合っているのである。

こうした慣習はずいぶんと前から指摘されているにもかかわらず、またぞろ同じような失敗を繰り返したことにショックを受ける。ある意味日本の縮図みたいなもので既得権益をお金の出し側ともらい側の両方が守ろうとしている。いまや変革の要請が至る所から発っせられているのに直らないのだ。

ではこうした事態を防ぐにはどうしたらよいのだろうか。今までの延長線上にあるような小手先の対策では無理だろうと思う。やれプロジェクト管理ができていなかったとか、スキルが不足していたとか、要件定義のやり方がまずかったとか、こうしたHowの領域での改善では立ちゆかないと思う。もっと抜本的な方策を編み出さない限り同じような失敗が今後も続いて行くような気がする。

その方策として、3つくらいが考えられると思う。まず一つ目は、このブログでも口を酸っぱくして言ってようにHowではなくWhatを優先して考えるという態度である。そのWhatはオペレーションから発想するということである。特許システムとはどういう使い方をしたいのか、ユーザは誰でその人たちにどのように使われるのかという視点で、そのための道具を定義してからHowに入るべきなのである。聞くところによると特許庁の1000人に業務フローを書かせたらしいのですが、みんなに使われる道具という観点に立てばそんなアプローチはしないはずです。

2つ目は、どうして100億近いシステムを一気にやろうとしたのでしょうか。少なくとも特許の検索の仕組みと特許庁の人たちの業務とは切ってもできるのではないでしょうか。近頃は、SOA的なアーキテクチャがあって、ビックバン方式ではなく段階的、部分的のシステム構築が可能になっています。これは投資リスクの回避にもなりますし、その組織の成熟度の進展に合わせて作って行くことで"猫に小判"的なシステム構築を防ぐことができます。

3つ目は、契約の問題です。本件も東芝ソリューションにお金が払われるのかどうか分かりませんが、通常準委任契約が多いので工数をかけたらそれに見合った費用をもらえます。こうした契約により成果が出ようと出まいと、使われようが使われまいがお金が払われるのはやはりおかしいわけで、理想的には成果報酬型が望まれると思う。

ただ、現実的にはその成果をどう測るのかが難しいし、成果が出ない時の最低保証をどこまでも持たせたらいいのかといったことがありなかなかできないでいます。しかし、見積りのところの工夫はある程度できるように思えます。設計までは準委任でやっておいて、開発は請負にして、成果がでたらそれをある割合で還元してもらうといったやり方もある。しかし、もっと進んで前に言ったように家電を買うようにできたらこうした問題はなくなると思うのだがいつことやら。
  
来る3月6日(火)に目黒雅叙園で「第7回BPMフォーラム2012」が開かれます。「これからの企業革新を支えるビジネス・プロセス・マネジメント(BPM)」というタイトルで3人の方の基調講演とBPM実践事例/ソリューショントラックとBPMソリューション/テクノロジートラックに分けて8つのセッションが組まれています。

今回は冒頭で「BPM推進フレームワーク」の紹介がありますが、このフレームワークはコモンセンス部会の中でずっと検討されてきてようやく出来上がったものです。おそらくβ版ということで説明されると思いますが、私はこの部会のメンバーなのでこの作成には最初から参加して、一部を担当しています。

以前から推進フレームワークというものはあったのですが、現在のBPMの考え方にそぐわなくなってきていましたので改訂したわけです。個別の内容についてというより、大きなコンセプトとか概念的なモデルが重要なのですが、それがかなりよいものができたと自負しています。

詳しくは当日の説明を聞いてもらえればよいのですが、私が評価したいのは、3つの輪のことで、つまりプロセス改革推進(PC)、プロセス開発(PD)、プロセスオペレーション(PO)という3つの機能を設定してそれぞれの推進ステップを明示したことです。特にオペレーションを重視したことは大変重要なことでこのブログでも再三指摘したことでもあります。

やはり、BPMは実際に実行して、あるいは設計したプロセスを動かして、その結果としてビジネスの成果を出すことができてこそ意味があるのです。そんな話も聞けますが、もちろん基調講演や各セッションの話も大変参考になりますのでぜひ参加してみてはいかがでしょうか。なお、私に連絡いただければ割引価格でのご提供ができますのでよろしくお願いいたします。
  

ここからは、業務機能をプロセス展開していくと多くの非定型業務に落とされていくという話をします。最初のエントリーで企業活動モデルをシステム構造的にみると、水平方向にビジネス活動があるとすると垂直方向にプロセス階層があるということを言いました。このプロセス階層を上から下位レベルに分解していくとどうなるかを考えてみましょう。

分かりやすくするためにプロセス参照モデルを例にとって説明したいと思います。プロセス参照モデルはサプライチェーンの領域ではデファクトに近いSCOR(Supply Chain Operations Reference)です。このモデルではレベルが3つあって、レベル1がプロセスタイプ、レベル2がプロセスカテゴリー、レベル3がプロセスエレメントという表現になっています。

プロセスタイプというのは、Plan、Source、Make、Deliver、Returnの5つです。日本語いうと、計画、調達、製造、出荷、返品といったところです。戦略的な見方をするレベルとなります。海外に生産拠点をもつとか、販売は販社にまかせるとかいったことをみていくレベルになります。次のプロセスカテゴリーは、見込生産品とか受注生産品あるいは設計生産品といった分け方になります。業務機能ドメインとでもいったらよいレベルになります。

レベル3になるとだいぶプロセス的になってきて、引合見積、オーダ受領、在庫引当、出荷といったものになってきます。これで上位のプロセスというイメージがわいたでしょうか。SCORはこのレベル3までのモデルが提示されています。ただ、これだけでは具体的な実行プロセスとはいきませんのでさらに分解した下位レベルのプロセスにしなくてはいけません。

余談ですが、標準モデルというのは誰からもコンセンサスを得られるようなものでなければいけませんので、どうしても高い抽象度となってしまいます。細かくすればするほど固有性が出てきますから標準から外れることになります。ですから、リファレンスモデルを実行レベルで使うことはできません。

このSCORのレベル3プロセスをその下のレベル4まで分解した人がいます。M&ERPインテグレーションの渡辺和宣さんで、そのモデルをESCORTと言います。このレベル4のプロセスは例えば、引合見積だと、見積依頼の受領・確認―見積条件の検討(与信)―見積条件の検討(プロダクト・価格)―見積条件の検討(納入条件)―見積回答の作成―見積回答の送付といったプロセスになります。ここまでくると、具体的なプロセスイメージになってきます。

さて、こうして分解されたプロセスを見てどう思いますか。例えば、見積条件の検討(プロダクト・価格)というのがありますが、見積依頼が来てその依頼内容に応じた商品を選んで、出し値を決めることを意味しています。まずこの業務を考えてみますが、これは定型業務でしょうか、それとも非定型業務でしょうか。

もうお分かりだと思いますが、非定型業務ですよね。見積依頼の内容や依頼元、依頼時期など決まりきってはいなくて、いつも違っていることがほとんどです。もちろん全部が全部ではなく、決まりきったリピートオーダーだとか、汎用品の購買だとかは定型的かもしれません。

ただ、そこのシステム化は簡単で決まったロジックで自動化すればいいわけで、いま議論しているのはビジネス要求をどう実現していくかなので、このレベルに現れた非定型業務の様相をどうさばくかが難しいところでこれから議論していこうとするのはこの部分になります。つまりレベル4プロセスをどう実装したらよいのかというのが論点となります。
   
中庸」という言葉をご存知ですか。儒教の教書である「四書」うちのひとつにこの名前がある。意味は、偏ることなく、常に変わらないこと、過不足がなく調和がとれていることである。このことが大事であるということはどんな世界でも言えるのだが、ITのところで考えてみましょう。

システム屋さんって、どちらかというと"反"中庸の人が多いような気がしませんか。自分の流儀や好きな技術に偏るし、新しいトレンドにすぐにとびつくし、うまくバランスをとることが苦手なように思えます。中庸というのは足して2で割るということではなく、両方のいいとこどりといった意味なので、自分が好きではないものもよければ使う精神が大切である。

だから、中庸的なシステム構造、中庸的なシステム開発がどうしたらできるのかを考えるのは意味があると思うのである。システム構造でいえば、昔から較べると今はSOA的な指向が出てきてインターフェースさえあればうまくサービスコンポーネント組み合わせてバランスをとれるようになった。別な言い方をすると、中庸的な組み立てをしないとSOAをやる意義はないということでもある。

一方のシステム開発の局面をみてみると、まずは開発アプローチでデータ、プロセス、機能のそれぞれでどうやるかの議論があるが、どれでなくてはいけないというのではなく、ここでも調和させてやることが大事になってくる。何でもDOAでやるべきではないし、パッケージ開発だけでやるべきでもない、もちろんプロセス志向だけでいいというわけではない。

このブログでは、プロセス中心アプローチを推薦しているじゃないかと言われそうですが、それだけだとは言っていない。ビジネス活動の部分においてはプロセスから考えることを推しているが、リソースデータの管理についてはDOAでやるべきだと言っている。リソースデータというのは、個別のプロセスとは関係なく会社全体で見渡すべきで、会社としてビジネス活動を行う資源にはどんなものがあって、どういう能力があるのかをつかむためにあるからである。ですから、リソース系のデータはDOAで、イベント系のデータに関しては、プロセスから考えるべきなのである。こうした中庸的な見方が必要である。

また、業務システムの開発アプローチで上流から下りてくるトップダウンアプローチとシステム構造から迫るボトムアップアプローチがあるが、ここでも同様に両者を融合した取り組みが重要である。このことは本ブログでも何度も取り上げていてそれをハイブリッド型アプローチと呼んでいる。実は、ハイブリッドとは中庸の精神であると思いだしている。

要するに、多くは2項対立的な世界にあるわけでその時どちらか一方に偏ってはいけないのであって、2項のバランスというか組み合わせといったことをよく考えることがシステムを作る上でも大事になってくるのである。
  


これまでは、非定型業務とは何なのかということで、データを確定するまでの業務であって、そこにビジネス要求が降りてくるので非常に重要であるということを議論しました。今回からそうした非定型業務をどうやって実装したらいいのかという話になります。

非定型業務というのは意思決定すなわちデータを確定する動きですが、それをどうやってITに乗せるかという問題です。ではその非定型業務は今はどうなっているのでしょうか。従来の業務システムでできていたのでしょうか。

できていないというのが正直なところではないかと思います。前回、非定型業務のIT化を避けていて、定型業務の方ばかりに目が行っていたと書いたが、非定型であるが故にIT化は難しいからである。あいまいさ、多様性、個別性、例外などを論理的に処理しようとすると壁にぶつかります。

ところが、実際のビジネスの現場ではいつも予想通り、想定したと同じ流れ(Happy Pass)で進むことはめったにありません。あっち行ったりこっちへ行ったりの非定型的な業務ばかりで、それを様々な手段をつかいながら日々こなしています。そして従来の考え方では、人間がやることの代替するものとしてのITを想定しています。

そうした考えだと、あらゆる人間の行動に対応したものにするのは不可能であると言わざるを得ません。いつも違った動作になるわけだから、それらをいちいち記述していてはたまったものではありません。「If then else」の嵐になってしまいます。

こうしたことから非定型業務のIT化が避けられてきたということが言えます。いやそんなことはなくてグループウエアとかCRM、ERPを使って、あるいは手づくりでもやっていますよと手をあげる人がいると思いますが、非定型業務を実行するために必要な機能の一部までで全体を包含できているものはないと思います。

要するに、従来のシステム化の考え方の延長では無理なのです。コンセプトそのものを変えていく必要があります。あいまいさ、多様性、個別性、例外などをどうするかではなく、それがあるという前提に立たなくてはいけません。

その前提に立った時に浮かんでくる考え方は、違った動作がやりやすいような"場"を提供するという考え方にすることです。点を線で結ぶようなことではなくて、空間を与えてやることです。その場では自由に動いてよいとするわけです。
この考え方は特別で新しいものではなくて、ITがなかった昔から会社の組織としての動作そのものなのです。特に日本の職場では、メンバーがお互いに電話や直接の会話による調整を行いものごとを決めたり、決めたことを黒板に書いて周知させていたり、部下を走らせて他部署へ連絡したりということをやっていました。

アメリカなどではこうした調整とかすり合わせといったことはあまりやられていないので、業務の定型化ができパッケージが普及した。ただ、これからは調整のような文脈的なというかオントロジカルな行為が重要視されるだろうから、非定型業務をどうやってうまく実装して運用させるかは大きな課題になってきます。