mark-wada blog

来月から、標記のようなテーマで勉強会（BPP研）をやろうと思っています。なぜこうしたことをやろうとしているのかというと、オバマではないですが、変わらない、変わろうともしない業務システムを抜本的に“Change”させたいからです。

ビジネスプロセスパターンというのは、あまり聞きなれないと思いますが、その意味するところは、業務を階層化し、ある粒度に分解していくとそれぞれの階層でパターン化できるのではないかという仮説に基づいています。

これを「業務の構造化」と考えていますが、そうした構造化により、システム構築の方法もシステム構造そのものもひいては仕事のやり方も変えられるかもしれないということです。

それを皆さんの知恵を借りながら仕上げていこうと思っています。そして、パターン化された業務コンポーネントをベースにどう業務プロセスを設計し実装していくかという実践的な議論をしようと考えています。

そこで、このブログでもテーマごとに問題点や論点について書いていくことにします。ただ、その前に大前提を書いておきます。その大前提というのは、議論を進めていく際にいつも頭の中に入れておいてほしい考え方なり、態度です。

１． ITのことは忘れる
特に３文字熟語は忘れてください。BPM、SOA、ERP、CRM、UML、DOAなどなど。なぜかというと、業務のことが中心ですから、まず業務ありきからスタートするのに邪魔になります。その言葉の枠にはめようという意識になるからです。

２． ビジネス視点、ユーザ目線
これまでシステムは、ベンダー視点、開発者目線で多く語られてきています。それを逆の見方に変えてみると言うことです。そうすると違ったものに見えるはずです。

３． 論理的な思考アプローチ
業務システムは工学的なモデルになりにくいと言われています。しかし、それではいつまでたっても職人芸の域から抜け出せないことになる。いかにして、工学的に扱えるようにするのかを追求する姿勢を持ち続けましょう。

４． ビジネスの実相を実装する
システム化というと、従来の発想でいうところのITにのせられるものしか対象にしていません。ITができることだけが業務システムなのでしょうか？逆ですよね。できるかどうかわかりませんが、まずは人間が行う業務をそのままITにのせることを考えることから始めましょう。

５． Simple is Beautiful
「とにかくシンプルに」を心がけます。シンプルなものほど機能的です。機能的なものは美しいのです。これは非常に難しいことですが、つい易きに流れ、複雑なものにしてしまうのはやめにしましょう。

このことは、何をいっているのか別の言い方をすると「自分の頭で考えろ」ということに他なりません。

もちろん勉強し、学習するのは大切なことです。しかし、それをそのまま自分の中で消化しきれず単に本に書いてあることの受け売りになってはいないでしょうか。自分の頭で徹底的に考え抜き、絞り出すようにおのれの考えにまとめる作業がものすごく重要なことだと思うのです。

だから、こういう勉強会はみんながゼロベースで考えてみることが必要で、そうした行為により真のスキルが身につくのではないでしょうか。こうした考える場で皆さんと議論をして、少しでもお役に立てたらオジサン望外の幸せです。
　

前回の主旨で述べたように今の業務システムを変えたいと言っています。ということは、現状に様々は問題があって、その問題を解決していこうということでもあります。その問題あるいは課題とはいったい何なのだろうか。そこをきちっと分析して本質的な課題を抽出しないと方向がずれてしまいます。

個々の領域については細かく見ていくことにしますが、現状の業務システムおよびそれを取り巻く環境を俯瞰してみると、どうも「ビジネスとIT」、「ユーザとベンダー」といった両岸の間に流れる“誤解”の川があるような気がします。そこにかなりの部分の問題が潜んでいるように思えるのです。

何年もの間、「経営とITの融合」、「ビジネスに貢献するIT」、「ビジネスマインドをもったSE」だとか両者をうまくつなぐことの必要性は謳われていながら、現実には乖離があるのは否めないのではないでしょうか。

その誤解について少し見ていくことにします。そして、この誤解を解くことがギャップを埋める第一歩かもしれません。

（１）業務システムは開発するものだ
　ほとんどの人が業務システム開発という。これから販売管理システムを開発するのだという。では一体誰が開発するのですか？システム側の人が業務の仕組みを開発するのですか？

どうも、開発プロジェクトを起こし、そこで業務システムを開発してしまっているのではないのだろうか。だから、プロジェクトは混乱するわけで、そこでは業務（プロセス・機能）を開発してはいけないのです。DevelopmentとConstructionの違いであることを理解すれば、実際のシステム構築の場ではコードを書かないことが大切だとわかると思います。

業務システムというものはユーザがITとは関係なく自分たちのビジネスを強くするためにプロジェクトとは別に開発しておくわけで、それをあらかじめ開発されたソフトウエアを使って組み立てればいいのです。

これって、建築のケースで考えればわかりやすいと思いますが、家を建てるとき“家を開発する”とは言いませんよね。都市とか生活スタイルを開発するとはいいますし、機能的な建材を開発するともいいますよね。そういう感覚で業務システムを作ることを薦めます。

（２）システムを作ることが目的である
さて、業務システムを構築するというが、それだけが目的になってやしないだろうか。もうおわかりでしょうが、作って終わりではなく、それを使ってビジネスや業務を行い、それが役に立ってもらうことが真の目的になります。

そして、この役に立つというのは、皆さんつい忘れがちですが、オペレーションエクセレンスということで、作った瞬間ではなく、それを使っている日々の中で優れた機能やサービスを提供し続けられるかです。

（３）正しいシステムが役に立つ
だれでも、システムを“正しく”作ろうとします。そのための作り方の本もたくさん出ているし、それに異を唱えるひとはいません。しかし、それでいいのでしょうか。少なくとも正しいシステムであれば必ず役に立つとは言い切れないのは確かだと思います。

このことは何を意味しているかというと、見方を逆にすること、すなわち、役に立つシステムであれば正しくないシステムでもいいということになります。

システム屋さんはこういうことを言うとすぐに、正しくないシステムを作るとパフォーマンスが出ないとか、セキュリティが問題だとか言う。そういうことを言っているのではなく、まずは役に立つものを作ってからの話でしょということです。極端なことを言えば、何もシステム化しないほうが役に立つかもしれない、そんなこともあり得るということを頭に入れておくことも必要ではないでしょうか。

（４）業務知識がないとだめだ
よく言われることに、システムエンジニアの人たちに向かって、業務の経験がないからだめだとか、業務知識をもったユーザのいうとおりにすればいいのだとかがあります。これはほんとうでしょうか。そんなに業務経験、業務知識が必要なのでしょうか。

すこし意地悪風に考えてみましょう。まず、その業務経験と業務知識って標準的かつ普遍化されたものでしょうか。違いますよね、もろ属人的なものです。ですから、いつも豊かな経験と豊富な知識がある人がいるとは限りません。わずかな経験と貧弱な知識の人がプロジェクトにアサインされることはいくらでもあって、悲劇の引き金になります。

せっかく、要求定義をしてもプロジェクトの後半やテストの段階になって、”比較的”豊かな経験と知識をもつ、いわゆるキーパーソンが出てきて今までのものを覆してしまうこともよく見かけることです。その人でも本当に客観的に標準にできる要求を出せているかというとおおかたの場合心もとないのではないでしょうか。

ですから、どうしてもユーザがビジネス要求定義をしなくていけないとは思わないのです。前に言ったようにいい加減なユーザが定義したものをシステム化するほうが厄介になることもあるわけで、そうであれば、ユーザ側もシステム側のない、科学的な定義のしかたができれば、こうした誤解は解消されるのです。

ただ、誤解の誤解をしてはいけないのは、だからといってユーザがだめだと言っているのではありません、むしろユーザは意外と賢いということを肝に銘じたほうがいいと思っています。その賢さを引き出すことが大事なのです。

（５）要件定義が大事である
ここでは、「要求定義」と「要件定義」の違いを理解することです。「要求定義」というのは最近やっとその重要性が指摘され出してきていますが、これまでは特にわが国ではあまり語られることが少なかったように思います。

いきなりRFPを書いて（これもユーザではなく、ベンダーが書いてしまうケースもあります）、要件定義に入ります。そうするとどうなるかというと、前に書いたように要件定義に従って、そのとおりにシステムは作ったのだが、いざ動かしてみると使い物にならなかったという事態になります。

それは、要求定義でビジネス上の要件を抽出してそれを仕様化することをしていないからです。ですから、要件定義も大切ですが、それ以上に重要なことはこの要求定義をきちんとやることなのです。

そういうことができていないから、ビジネスの要求がシステムに反映されていないというユーザ側の不満と、ちゃんと言ってくれないからそうなるのだというシステム側の不満がぶつかることになってしまうのです。

（６）経営者はITを使って経営をすべきだ
一見なるほどそうだと思われるでしょうが、そうなのでしょうか。まず、ビジネスと一括りで言っていますが、その中には、経営・事業・業務というようなレベルがあります。

この最上位に経営というものがあって、これは経営者（陣）がこれにあたります。そして経営というのはいったいどういうことなのかであるが、それを考えるとき“社長の関心事は何か”という問いに答えるのがわかりやすいかもしれない。

おそらく多くの経営者の関心は、「事業構造論」と「人事」だと思っています。自社の事業ポートフォリオをどうするのか、そのために企業あるいは事業買収あるいは売却をどうするのかです。そして、それをだれにやらせるのか、おれの後継者をだれにするのかを絶えず考え続けているのです。

そうなると、はたしてそうしたことにITが要るのでしょうか。ある程度の情報は要るかも知れませんが、ITを使って何かをするというふうにはならないでしょう。

ですから、むしろここで言いたいのは、ITは事業に貢献するものであり、業務の効率を上げることに寄与できるもとと位置づけるのがよいでしょう。あまり大上段にふりかぶって「経営とITの融合」なんて言わないほうがいいように思うのです。あくまで、「事業とIT」くらいでいいのではないでしょうか。

これらの“誤解”をよく考え、それを解いていくことが大事であると思うのです。このことは何を意味するかというと、視点を変えてみたら、常識を疑ってみたら、既成概念をこわしてみたらという、今までと違う見方をあえてしてみることでまた新たな発想が生まれてくるような気がするのです。
　

いまの業務システムの課題をさぐるために業務システムの過去と現在をみていきましょう。と言ってみたが、この業務システムってやつがここ何年も変わっていないことに気がつきます。１５年いや２０年前とほとんど変わっていない。

もちろん、それを動かすインフラやハードウエアは怖ろしいほど変化しているが、業務システムそのものは大きな変化もなく同じようなものです。

ホスト－端末構成からクライアントサーバー型に変わっても、手組みからERPなどのパッケージ開発に変わっても本質的な変化はありません。単に新しい技術を取り入れただけでは、それで変化したとは言いません。根本的にビジネスの変化に対応して進化することができていないのです。

一方のビジネス側は、企業を取り巻くビジネス環境のすさまじい変化に対応していっています。そうでなくては、企業が存続できなくなるからです。

従って、変化対応力をつけるためにITへの期待があるにもかかわらず、変わらない業務システムとの乖離がますます拡がっているように思えます。

ですから、何としてもビジネスとITが同期できるようにしていかなくてはいけません。では、そのビジネス（事業）とITが同期しているとはどういう状態なのでしょうか。そこを少し考えてみましょう。

それは、次の３つであると考えています。

１．業務プロセスを可視化しコントロールしている
２．事業全体の適正なオペレーションができている
３．業務パフォーマンスの把握と戦略へのフィードバックがなされている

それに加えて、もうひとつ大事なことがあります、それは、企業で働く個人のひとたちの働きかたです。ITが企業に持ち込まれて久しいのですが、従業員ひとりひとりのの働き方が改善されたのでしょうか。組織の動きが円滑になったのでしょうか。

ひょっとすると、ITが現れる以前の職場より悪くなっているかもしれません。コミュニケーションの退化が起こっている可能性も感じることがあります。

こうしてみると、どうも今の業務システムは、個人・組織・事業のそれぞれにおいて、表面的なところではない根本的なところに問題があり、それが徐々に顕在化していると思うのである。
　

今度始めるビジネスプロセスパターン研究会について、それに参加するbegiramaさんがご自身のブログに書いてくれている。ありがとうございます。ところで、その中で最近話題になった秋田県大館市の事例について下記のように言及しているのでそのことについてコメントしてみる。

また、秋田県大館市の事例のようなエンドユーザが本当に自分たちが欲しいと思うものが安価に、早く作れる（冗長なものは要らない。）ということができたら、素晴らしいなーと思っています。

この例のような全部自分たちでやるのが良いかどうかは、構築時など一時的にパワーが必要な場合や、平時は必要ないスキルを持った人を短期的に集める、アウトソースした方が良いケースはもちろんあるはずなので、バランスが必要だと思いますけどね。

一見すると、すごいと思うかもしれないが、begiramaさんも言っているように必ずしも全面的によいことであるともいえないと思う。エンドユーザがどこまでやるべきなのかという議論になるが、ぼく個人としては、上記の例はエンドユーザがやるべきことからはみ出しているような気がする。

なぜかというと、本来の業務の延長ではなくて、異質のスキルもいることだし、専門家ではないところの危うさもあるわけだから、敷設後の運用･保守などを含めた総合的な得失を見たとき、本当に効果的であったのかどうか疑問である。

むしろこうした領域は複数の専門家に競争させ、それでその見積をきちんと査定して、適正な価格にすることがとるべき道であるような気がするがいかがでしょうか。

一方で、これから勉強会でも議論になると思うが、業務プロセスを設計し、ユーザ自身で実装してしまうようなことはどうなんだろうかということがある。ここのところはみんなでよく考えてみましょう。
　

前回、いまの業務システムがビジネスの変化に追随できていないということを指摘した。そこでもう少し具体的に問題点を探ってみましょう。大きくつぎのような分類をしてみました。

１） 構造上の問題
２） 技術上の問題
３） 制度・慣習上の問題

まずは、構造的な問題について考えてみます。いろいろな領域でその構造の問題点が浮かび上がってきます。

（１）システムのつくりの問題（システム構造）
（２）ユーザとベンダー間の問題（業界構造）
（３）組織と個人の問題（人材構造）

システムそのものの構造については、前にも触れたように変化対応力に乏しい硬直的な構造になっています。それは、手組み開発であれ、パッケージ開発であれ、プログラムに機能が埋め込まれた構造になっていて、手組みだとそこにプログラムを継ぎ足し、スパゲッティ状態を作りだしています。

パッケージの場合はそうではなくモジュール単位になっているじゃないかと言われますが、結局、カスタマイズやアドオンという形でロックインされてしまいます。ですから、基本的にみな密結合で形成されているといえます。これが、柔軟性、すなわち変化対応力がない原因ではないでしょうか。

つぎに、ユーザとベンダーとの関係をみていきましょう。ユーザといっても直接現業部門ということもあり、IS部門が窓口という場合もあるでしょう。また、ベンダーといっても、SIerであったり、パッケージやソフトウエアベンダーであったり、単なる開発ソフトハウスだったりします。そのなかで一番悩ましい問題を抱えているのは、ユーザ企業のIS部門とSIerとの間の問題ではないでしょうか。

そして最大の問題は、「情報の非対称性によるインセンティブの歪み」から生じる利害の不一致です。どういうことかというと、ITに関する情報はたいていの場合SIerが多く持っています。ユーザはSIerがどんなことをしているの容易にはわからないし、自分たちの要求がどう実現されるかはできてみないとわからないという意味で情報不足の立場にあります。

この非対称性によってどうなるかは、コストや品質などについての合意形成の難しさとして表出してきます。しばしば、ここの争いでプロジェクトが紛糾することになります。

組織と個人の問題という点では、簡単に言うと、IS部門であれ、SIerであれ、自分のキャリアパスをどう描くが焦点になるでしょう。３K職場と揶揄されるように、ITSSのようなものがあったとしても、必ずしも実際の現場レベルにはきちんとした人材育成ロードマップやロールモデルがあるとは言えないのではないでしょうか。

ついで技術問題をみていきます。これは何回も言っていますが、簡単にいうとつぎの開発のジレンマのことになります。

（１）アプリケーション仕様のほとんどが、結局、ユーザの恣意でしか決まらないこと　　
仕様を決定付ける科学的、工学的なモデルが存在しないということ
（２）実業務の様々な例外をコンピュータ上に乗せるか否か
情報システムと人間の境界が、元来不安定であること
　　
こうしたジレンマを抱えながら技術者は日々苦闘しているのではないでしょうか。このジレンマから解いてあげることを真剣に考えないといけません。

最後の制度や慣習みたいなものもあるがここではそれほど重要ではないということで取り上げないことにします。

勉強会のテーマについての記事以外に、留意事項や補足的説明も折々に書いていこうと思います。

これまで、業務システムの抱える問題ということで構造上のいくつかの課題を指摘しています。そこで、この構造の問題、あるいは構造化について考えてみましょう。

構造的に問題があるという場合、今が悪構造になっているからそれを｢構造改革｣する必要があるということになります。

しかし、このとき気をつけなくてはいけないのは、構造化されていないものをいくら改革しても意味がないのです。ですから、まずは適正に構造化して、それに対して今の構造とギャップがあるので、それを変えていくというアプローチになるはずです。

ここは重要なところで、ちゃんと構造化したものを見せなくてはどこが問題なのかよくわからないことになります。

例えば、小泉構造改革は、構造化した姿を国民の前に提示して、その中のこの部分を改革するということをしなければいけなかったのですが、それが十分やられていなかったからいまの揺り戻しのようなことがおきているのではないでしょうか。

ですから、繰り返しますが、まずはきちんと構造化できれば改革のターゲットがあぶりだされてきて、おおかたの目的が達成できてしまうように思います。

それでは「構造化する」とは、どういうことでしょうか。下記のように定義してみました。

　（1）全体を俯瞰したうえで、構成要素に分解し　
　（2）それらの構成要素間の関係を分かりやすく整理し
　（３）統合化されたモデルを作ること

こうした観点からながめてみると、業務システムが対象にしている業務そのものも性格の違った要素から成り立っています。基幹系業務とか情報系業務とか言われたりしますが、それだけではなく、定型的なのか非定型なのか、日常的なのかプロジェクト的なのかといった、さまざまな区分にわけることができます。

もちろん、そうして分解された業務に対して、適用すべきシステム技術やソリューションが変わってきます。業務の特性に合致したものをもってこないと使いづらいシステムであったり、無理が生じてしまいます。

また、そのシステム構造についてもただ対象アプリケーションだけを見るのではなく、システム間の連携だとか、システムが動くプラットフォームにおける機能・プロセス・データの分離といった「構造化」の視点が大事になってきます。

そして、次に重要なのは、その構造をどうながめるか、ギャップを掘り起こすかといった分析眼になります。

よく行なわれるのが、2次あるいは3次元的な見方です。2次元というのは、適正なスコープであるかどうか、簡単なところでは、4象限の図を思い浮かべるといいかもしれません。3次元というのは階層を見ることです。要するに縦横の面で切るということを指します。

ところがそれだけでは不十分なような気がします。4次元的な見方も必要になるのではないでしょうか。4次元的というのは時間軸としてリーズナブルなのかといったことです。この観点は意外と忘れがちで、未成熟な技術を今は使わないとか、人材を育成する時間がいるとかといった分析が重要です。

おわかりいただけたでしょうか、システム構築を考えるとき、構造化する意味はここにあります。従来ではひょっとすると構造化の必要はなかったかもしれません。どーんと一気に大きなシステムを作ってしまうやりかたであったわけで、そうなると構成要素はどうであれ、全体として動けばいいやという思想になってしまいます。

ＳＯＡやＢＰＭの概念が出てきたのもそういうやり方のアンチテーゼであったわけです。ですから、こうした概念を具現化するための前提は「構造化」であると言っているのです。

適正な構造化ができれば、部分的（2・3次元的）かつ段階的（4次元的）構築ができるのです。この恩恵は非常に大きいと思うのですがいかがでしょうか。
　

前回、主に構造的な問題と技術上の問題をとり上げたが、それではそういう課題をどう解決してくのか、そのためにどんな議論をしていったらいいのかを考えてみます。

前の議論を踏まえてみてみると、つぎのようなことが論点になりそうである。

１） ビジネスの要求とＩＴを一貫化させるためにはどうしたらいいのか
２） 変化対応力に優れたシステム構造とはどんなものなのか
３） 開発生産性や保守性を上げるにはどうしたらいいのか

こうしたことを解決できれば、前回指摘した業界構造や人材の問題もかなり改善されていくと思われます。ここが、最も重要で基本となるところです。

すなわち、なぜビジネスとＩＴが乖離するのか、どこで乖離がおきているのか、阻害要因は何かといった議論である。ユーザは何を考えているのか、技術の進展がカバーできるのかとかいったことも含めて多角的な視点でみていく必要がありそうです。

システム構造は、SOAやSaaS、クラウドといった概念が提示されているが、それを当てはめて考えるのではなく、逆に使い手側あるいは作り手側の要請があったからこそそういった概念が登場してきたという見方から考えてみてください。

開発生産性の問題は永遠のテーマです。しかし、そのときの発想はプログラミング効率をいかに上げるかということが多いように思うのです。その考えを変えてみることも必要ではないでしょうか。どうも今の開発現場をみてみると、いつの時代もいたるところで同じようなことをやり続けていると思いませんか。おそらく、世界中で、日本中で全く同じプログラミングを毎日せっせてやっているのではないでしょうか。

いったい新たに書かなくてはいけないコードがそんなあるのでしょうか、それは何なのか考えてみてください。だって、業務システムってそんなに変わっていなのですよ。ひょっとしたらコードを書かないですむことがあるかもしれません。

繰り返しますが、主な議論のポイントは、要求定義から要件定義、設計・実装の一貫化ということ、Flexible & Adaptiveな構造、コードを書かない開発といったところではないでしょうか

先日、あるセミナーでブログを見ていますよといって声を掛けてくれたＭさんと、先日大船のＭさん行きつけの秋田料理の店に行く。ぼくのブログを読んでもらっているから“話が早い”のである。のっけから意気投合で、いろいろな話をして非常に楽しかった。

その話の中で、ふつうの人にはなかなかわかってもらえない領域だが、同意してもらったのが業務ルールに関してのことである。Ｍさんも以前デシジョンテーブルを使ったり、人口知能をやったりしていたので、すぐに理解してくれ、これから一緒に勉強することにした。そのとき、ぼくが話したことはおおよそ次のようなことである。

ビジネスプロセスパターンを議論しようとすると、もちろん業務プロセスを主体に考える。ところが、プロセス以外で大事なのが広義の意味ではデータなのかもしれないが、業務ルールである。

業務ルールというとデシジョンテーブルとか、ルールエンジンとかという話が出てくる。だが、ここで言いたいのは、もう少しあいまいで必ずしも論理的でないルールのことである。こういうものが重要であることが多いのである。

それは、その会社の差別化要因だったり、競争優位の源泉だったりする。

だから、極論すれば、業務プロセスはほぼどこの会社でも同じようなもので、そこに大きなノウハウがあるわけではないのだ。みんな自社の特徴ある固有プロセスがあると思っているが、どこもほとんど同じようなものだと思う。

例えば、顧客によって価格や品質を変えたり、依頼主や内容によって担当作業員を変えたりするようなことで、こうした複合的な要素で意思決定するようなケースでは一義的に決められないから難しいのである。

単純なルールやいつも決まったフローであれば、プロセスの順序や分岐などで表現すればいいのだが、そうはいかない場合、往々にしてそういうところにノウハウがあるものだが、そこをどうやって業務システムに組み込むかが重要になってくる。

しかも、そうしたルールは、属人的であったり、環境により刻々変化したりするという厄介なものなのである。

ではどうしたらいいのだろうか。まだ、抽象的な概念の域を出ないのだが、日々の局面で使ったルールを蓄積し、そのルールを使った意思決定の結果がどうであったかの相関関係を記録する。それを解析してモデル化して、そのモデルに従って次の意思決定を行う。そうしたことを繰り返しながら、アップデートされたルールの質を高度化していくというような成長する仕組みができないだろうか。

それは、Amazonのレコメンデーションのようなものなのか、そうではない他のものなのか、そのアルゴリズムをどうするのかということになるのだろうけど、面白いテーマではあると思う。

このことを「進化する業務ルール」であると考えている。以前にも言ったことがあるが、業務プロセスは作って終わりではなく、Control&Operationして始めて有効な仕組みになる。そして、優れたControl&Operationとは、意思決定の質とスピードを絶えず向上させていることである。差し戻しのない適切な意思決定を早くするためには、有効性が保証された業務ルールが不可欠である。

実は、この業務ルールともう一つそれ以外の意思決定を支援する参照情報のギャザリングとフィルタリングの仕組みについてもこれからの課題であるという話もした。これについてはまた別の機会に記すことにする。
　

昨日は銀座のルノワールでビジネスプロセスパターン研究の第１回の勉強会を行なった。家を出るときてっきり6時半からだと思い込み、少し早めに出たつもりだったのだが、新橋から銀座に向かう途中で、そうだ6時からだったと気がつきあわてて走って向かう。若干遅れて到着。早めに出てよかったと胸をなでおろす。遅れて来る二人を除いてもう7人が席についていて、はあはあ言いながら始める。

昨日は第１回目なので、趣旨説明や自己紹介を行う。メンバーは主に20～30代（中にひとり気持ち20代の40歳の人がいます）のベンダー系に勤めている人たちで構成されています。ぼくがブログやBPMオフ会で出会った人とうちの社長関係で知り合った人たちです。

議論の第一歩は、「現状の業務システムはビジネスの要求に答えられているか」である。ぼくの方から、ここ15年間業務システムが変わっていないので何とか変革しなくてはいけないという話をする。ビジネス環境やITインフラなどはものすごい勢いで変化しているのに、業務システムそのものは旧態依然のままである。

そんな切り出しで、だいたいこんな問題点に集約されるのではないかという風に言った。戦略や事業とITの乖離、変化対応力に乏しいシステム構造、低い開発生産性である。

で時間がない中で議論になったのは、システム屋に業務知識は要るのか、会社規模、成熟度、あるいは業種･業態によるプロセスの違いと共通性、ビジネス要求をどう獲得するのか、といったことであった。こうした問題意識は重要なことで、ビジネスの要求がクリアになっていないと、役に立たないシステムを作ってしまうわけで、そうならないためにどうしたらいいのかといういことになる。

ユーザの人たちにちゃんと要求を出してよね、戦略をどう実現するのか考えてよねといったところで、特に日本ではそれができているところは少ないように思う。さすれば、手をこまねいているだけではなく、システムサイドから、そうした要求を吐き出す手助けしてあげるやり方はないだろうかということになる。

それを考えるとき、会社の状況や業務についてよく知っていないとできないのか、そうではなく、要求吐き出しの手助けなのだから、基本的なところだけ分かっていればできるのか、これからの議論の中であぶりだしていこうと思う。

ヒントは人間って道具を自ら作り出すのは難しいが、与えられるとこうした方がいいとか、別の使い方を考えるとかができるようになるということだと思っているが、さてどうなるだろうか。

昨日の議論で問題点の共通認識は概ねできたようなので、次回から「ビジネスと業務の構造化」ということで、会社経営の仕組みや業務形態からそれらを構成要素に分解していき、業務プロセスとはどういうものなのかということを中心に議論しようと思います。

さて、次は「ビジネスと業務の構造化」についてです。

業務プロセスを考える場合、企業はそれぞれの事業を行なうためにどんな会社構造になっているのか、事業遂行のプロセスはどんなものがあるのか、そのプロセスにはどんな機能を持たせているのかといったことを探っていくことが必要です。

業務プロセスには必ず目的があります。ときたま、目的が不明あるいはプロセスの終点がない場合があったりします。事業遂行上必要だからこそ目的が存在するわけですから、その必要性をみるためにもこうしたアプローチが大切なのです。

私は長いこと製造系の会社にいましたので、どうしてもサプライチェーン中心に見てしまいます。しかし、非製造業でも実体がないサービスのようなものでも基本的には同じだと考えています。

よく、業種・業態に分けてその事業プロセスの違いを言う人がいますが、少なくとも業務プロセスレベルの話をするときはそれほど重要ではないのではないでしょうか。

例えば、生産財の製造だと、受注－生産計画－生産－出荷というのがコアプロセスになりますが、サービス業だと、契約－設定（工事／担保）－サービス－検収となります。もちろんそこには“差”がありますが、これは、採るべき業務機能の種類と数が違うだけで、このレベルであれば、他の消費財製造業、建設業、卸売業、小売業なども同じようにコアプロセス描いて、共通化してしまえば、その中のどのプロセスを経るのかだけになります。

その、最大コアプロセスチェーンは、販売計画－生産・調整計画－見積－契約－前発注－仕入・調達・手配計画－仕入・調達・手配－生産・建設・サービス提供－後発注－引当－販売・出荷－検収となります。それぞれの業種でどこのプロセスを通って、どこのプロセスをスキップするのかになります。

また、非コアのプロセスでは、例えば、代金回収、資材購買、人材調達、設備保全などは、基本的にはどの業種・業態でもやることはあまり変わりません。ですから、このレベルでは各業種とも共通的な見方でよいと思います。さらに下位レベルに分解したときにどうなるかです。

一方、最下層の業務プロセス、というよりアクションというほうがいいでしょうが、そのレベルになるとまた同様に業種も関係ないようになります。例えば、入力するとか、帳票を出力するとか、承認するようなことは同じだとわかります。

従って、これから上からの分解と下からの展開を行なっていった場合どうなるのかを見ていくことになります。

順序が逆になりましたが、もう少し高い位置で会社の構造をながめると、コアプロセスは前述したようなサプライチェーンとのプロセスが中心ですが、それだけではなく、大きな括りとしてＰＤＣＡサイクルがあります。

文字通りPlanである企画・計画、事業実行であるDo、これがサプライチェーンです。そして、Checkとしての管理・統制、具体的には財務会計や監査で、Actionとして、また最初の企画・計画に戻ってきます。

非コアプロセスはサポートプロセスと呼んでもいいのですが、大きく意思決定サポート、サプライチェーンサポート、定型業務サポートの3つあると考えています。

意思決定サポートというのは、法務・税務、資金調達、人材情報、管理会計などのプロフェッショナルサービスのことです。サプライチェーンサポートは、環境・品質・設備・物流などの管理です。最後の定型業務サポートは、一般会計、給与計算、汎用購買、従業員サービス、それと情報処理サービスもこれに当たります。

こうして、会社の業務を構造化していくと、それぞれの役割や機能とその重要性がだいたい見えてきて、それを実行させるためのプロセスもどうあるべきかも分かってきます。このように全体感をつかんで、そこから「構造化」のところでも述べたように各構成要素に分解していく作業が必要になります。

これはトップダウンアプローチではありますが、戦略の落とし込みのような意味ではなく、全体を分解していくという感じになります。そのとき、非常に参考になるのが、というかそれを利用すればいいと思うのですが、デファクトになっているようなリファレンスモデルです。例えばSCOR（supply-chain operations reference-model）やAPQC（米国生産性品質センター　Aremican Productivity and Quality Center）のプロセス分類フレームワークなどです。
　

前回は事業を実行するための企業の構造についてみましたが、まだかなり大きな括りですので、これを分解していくことになります。

前回最後の方で書いたリファレンスモデルでは、そこの落としこみをおこなっています。しかしながら、これもまだ粗いのでさらに細かくしていく必要があるのですが、リファレンスモデルではそこまでできていません。

ここは例をあげて説明した方が分かりやすいので、ごくオーソドックスな受注して出荷するというプロセスで考えてみます。

まず大きなプロセスである「受注―出荷」があり、それを分解すると、「受注」、「在庫引当」、「輸送手配」といったものに分解できます。つぎに、「受注」というものをみると、その中にもプロセスが内在しています。「受注受付」、「与信」、「納期確定」、「オーダー発行」といったものがあります。そして、最終アクションとして「受注メモ作成」、「連絡」、「承認」、「入力」といったものになります。

ここでは4段階に分解していますが、この程度の粒度で分けるのがいいと思っています。呼び方としては、上から「業務プロセス」、「業務サービス」、「アクティビティ」、「アクション」としていますが、どんな呼称でもかまわないと思っています。

要は、同じ粒度で分解していくことが重要で、下流にいくほどプロセスというより機能的な色合いが強くなります。また、人間系の処理に近くなりますのであいまいさが出てくるようになります。

そして、ここで大事なところは、下位2プロセスというか業務機能と言った方がマッチしますが、その機能である「アクティビティ」をどういう粒度で定義するのかが肝になるということです。上述のリファレンスモデルもこのアクティビティレベルに落とし込んでいないのです。

また、このアクティビティとその下のアクションレベルとの分離も非常に重要な考え方になります。
実は、この両者ではプロセスの特性や処理形態が違うことがわかります。そこを一緒くたにしてしまうと複雑になってしまいます。

このあたりの階層化の考え方や粒度設定については大いに議論するところになります。大きな括りから徐々に細かく分解していくことで、プロセスを表現していくアプローチでは、それぞれのレベルでの粒度の定義をしなくてはいけませんので、その考え方が納得できるものなのかが問われるわけです。

これまでは、いわばトップダウンアプローチ（ToBeモデルベース）でしたが、AsIsからみるボトムアップアプローチではどうなるでしょうか。それも基本的には一緒で、上流にはいかないので、アクティビティレベルを並べていくことになります。

もちろんここでもアクティビティとアクションの明確な分離が必要条件になります。対象プロセスを抽出して、プロセスの始点と終点を決めて、その間にアクティビティを配置することが基本になります。詳しくは、後のプロセス設計で出てきます。

繰り返しますが、最大のポイントはこの階層化と粒度設定にあります。ですから、粒度に求められる要件は何か、その要件を満たすための粒度の大きさと性格付け（何をもってアクティビティと定義するのか）を真剣に考えてみてください。
　

ちょっと前にbegiramaさんが、「SOAとデータベース」ということについてブログに記事を書いていた。その指摘するところは非常に重要なので、そのことについて少し触れてみる。

いま、ビジネスプロセスパターン研究ということで主としてプロセスの議論を行なっていますが、忘れてはいけないのが、プロセスにはデータと機能が必ずついて回るということで、分離して考えなくてはいけないが、それと同時にその関係性をきちんと理解しておかなくてはいけないのです。

特に今はSOAと言われるような構造が多くなってくると、機能・プロセス・データ関係性がこれまでと違ったものになっています。ですから、従来の思想ではついていけない可能性があります。新たな考え方や概念を持ち込む必要があるかもしれません。

そのなかでデータに関しても、いまの考え方はまだメインフレームでの手組み開発あるいはERPの時代のものであるような気がします。すなわち、統合化という目的でひとつのフレームの中に全部入れ込むことが指向されたわけですが、その場合は当然データベースも統合ということが是であったわけです。

ERPが登場して普及したのは、サイロ化したシステム、スパゲッティ化したシステム、重複分散したデータベースを統合するというのが、いちばん大きい理由であったと考えられていますから当然だったのです。

しかし、今はSOAという時代になってきました。サービスが内外で分散する時代です。そうなると、システム統合、データ統合は大変難しいことになります。そこでは、しょうがないからサービスごとにデータを持つかという風になってしまう危険性があります。

これも、昔から言い続けられている「分散と集中の最適化」をしていくということだと思います。すなわち、データも集中すべきものと分散せざるを得ないものとを弁別して管理する必要があるのではないでしょうか。

じゃあ、一体どうするのだということですが、begiramaさんはデータの持ち方として次のように言っています。

１．データベース統合
２．各システムの共通データ項目を抜き出し、共通データベースに統合
３．各システムが個別にデータベースを持ったまま
３－１．共通データ項目をマスタから各システムに配信
３－２．ESBの様な層でデータを仮想的に統合

データというのは大きくリソース系とイベン系に分かれますが、それぞれで考え方が違うように思います。リソース系すなわちマスタデータは、当然データベース統合をすべきです。「One Fact In One Place」の原則を守る必要があります。ただし、そうはいっても現実的にはかなり難しいところがあります。

これは、システム間を横断する話ですし、経営やビジネスに関わることなので、利害関係者が多くなりその調整にすごい時間と手間がかかるからです。ですから重要なのはデータ辞書を整備し、仮想的に統合するのが現実的であるように思えます。

そうしたことを反映してか、最近「MDM」（Master Data Management）という言葉も語られることが多くなってきました。また、IBM InfoSphere MDM Server、SAPNetWeaver MDM、Oracle MDM Data Hub、Sun MDM Suite、ASTERIA MDM Oneのような製品も出てきています。これらの中でも、統合マスタ型とデータハブ型に分かれてもいます。

ぼくは、個人的にはデータハブ型のASTERIA MDM Oneの考え方がいいように思います。MDMの基本必要機能というのは、データクレンジングとデータ配信とでデータ統合管理だと思いますが、それぞれを個別にもって要求ごと段階的に入れるのがいいと思っています。

この製品でもいきなり統合管理に行くのではなく、マスタが分散されていてもいいという前提で、ただ、統合的なリポジトリーを持ち、そこにクレンジングされきれいになったデータを格納します。そして、そこからハブを介して配信されるところからはじめ、徐々に統合データベース化していくのだが、それは物理的な統合ではなく、仮想的な統合でいいという考え方です。

つぎに、イベントデータの扱いになるが、これも理想的には統合データベースということかもしれないが、それもかなり難しいことになる。ぼくは、イベントデータ（トランザクションデータ）というのは、プロセスの実行の結果として生成されるものであると考えている。そうであれば、プロセス先行でみていってそこで生じるデータ項目がイベントデータになるとしたらいいのではないだろうか。

すなわち、統合ではなくプロセス依存である。そこではもちろんデータ辞書との突合せをしておくが、言うならばプロセスの正規化（これも定義がいるが。これこそプロセスパターンということでもある）をすれば、おのずとデータも正規化されていくと考えるのはどうだろうか。そうしておけば、分散されていてもいいのではないだろうか。

このあたりもずいぶんと議論の余地があると思います。ただ、まえに書いたように、従来のシステム構造とは違ったものになりつつある現状の仕組みに合致したデータ管理のあり方を模索する必要性、重要性は十分にあるように思え、皆さんにもよく考えてもらいご意見をいただきたいと思うのです。
　

前回、業務を分解し、階層化していきました。そのとき、どのレベルの粒度をアクティビティとして、業務プロセスに組み込むかが重要であることを提示した。

すなわち、ビジネスプロセスをフローで描いたときの“箱”（アクティビティ）をどうするのかということである。それでは、その粒度に求められる要件とはいったいどんなことなのでしょうか。議論のたたき台として次の4点をあげてみました。

１． 論意的であること
２． 粗すぎず細かすぎないこと
３． 均一で均質であること
４． コントロールできること

１の論理的であるということは、曖昧さを排除して、できるだけ工学モデルに近づけることにあります。論理的であれば、ある程度その論理に基づいてやれば、標準的になり、属人性を持ち込まないですむようになります。

２は、あまり粗い単位で並べると大雑把過ぎて内容がよく分からないことになります。一方、細かすぎるとどうなるでしょう。きっと、アクティビティそのものの数や分岐も増え、複雑になってしまいます。細かいというものは、連絡、確認、調整といった類のものが該当します。こういうものは、あれも入れておいたほうがいい、この人にも連絡が必要だとなって際限がなくなり、フローを見ても何がなんだかわからないということになります。

３の均一･均質というのは１と２に似ていますが、ちょっと違います。大きさやつなぎ方は同じようにするというのが１と２ですが、その中味を揃えてみるということです。こうしたことができれば、パターン化や標準化が可能になるわけです。

最後のコントロールできることという意味も前述の要件を満足できればいいのではないかと考えられますが、これも、だれがそのプロセスをコントロールしているのかということがちゃんと対応付けられていることが大事ですから、そのコントロール対象が何であるかが明確であることが必要なのです。

さてこうした要件に対して、その要件を満たすアクティビティとはいったいどんなものなのでしょうか。

まずは、分かりやすい粗さからみてみると、前回プロセスと機能を分解しましたが、あの分解能で探ると業務サービスあたりで括るとちょっと大きすぎであるとわかると思います。すなわち、例えば、オーダ受領だとか在庫引当です。

また、アクションレベル、例えば、受付メモ作成、承認といった粒度であると細かすぎると思うでしょう。そうなると、どうも文字通りアクティビティと規定したところがよさそうにみえます。

では受注確認、オーダ発行といったアクティビティレベルでフロー記述するとして、そのものが論理的でかつ均一･均質なものにするにはどんな定義になるのでしょうか。

ここが、全体の議論でも最も重要な部分です。さあみなさんよーく考えてください。
　

最近、かなりの数のBPMツールが登場してきて、まさに百花繚乱といった趣ですが、BPMツールというのはいったいどんなものなのかが明確には定まっていないようだ。

しかし、ぼくは別にこうでなくてはいけないと定める必要はないと思っているが、「ビリオネアの華麗なるIT」でそのことに言及しているので一緒に考えてみる。

その記事ではBPMツールの定義を「人やシステムが行うビジネスプロセスの管理・監視を自動化するためのソフトウェア」としている。うーんちょっと自動化するソフトウェアというのが気になる。

IBMなんかも、BPA（Business Process Automation）というような言い方をするが、以前、「自動化のワナ」というエントリーでも書いたのだが、“自動化”をあえて言うのはちょっと無理があるように思える。

ここは、軽く“BPMを実行するソフトウェア”でいいのではないだろうか。そうなると、BPMの定義をちゃんとしなくてはいけないのと、どこまでできるかはそれを導入する会社の成熟度によって変わるということをみておくことが大事である。

まずは、BPMの定義では、よく使われるガートナーと日本BPM協会のものをあげておく。

ガートナーの定義

「BPMとは、経営における俊敏性の改善やオペレーション上の業績改善といった経営目標を実現するために、ビジネスプロセス環境を統括していこうとする経営手法である。BPMとは、組織内のアクティビティやプロセスをマネジメントし、継続的に最適化させるための経営手法、施策、経営指標、経営慣行、ソフトウェアを利用した構造的アプローチである。」

日本BPM協会の定義

「企業活動の俊敏性・業績・コンプライアンスの改善といった経営目標の改善に向けて、ビジネスプロセスの改善サイクルを、人とITにより迅速に実現する新しいマネジメントの考え方・領域」

これらの定義から導かれるBPMSの機能はビジネスプロセスを管理・改善できるツールということになります。うーん難しそうですね。ただ、BPMには次に示すようなライフサイクルがあるということがわかります。

１． プロセスを作る
２． プロセスを動かす
３． プロセスを制御する
４． プロセスを維持する
５． プロセスを監視する
６． プロセスを改善する

では、実際のBPMSの機能にはどんなものがあるのでしょうか。一般にBPMS（BPM Suite）と呼ばれる製品が出回っていますが、その装備している機能はだいたい下記のものが含まれています。

■BPM実行エンジン
■プロセスモデラー
■シミュレーション機能
■組織モデラー
■ワークフロー機能
■ビジネスルール管理
■ソフトウェア開発
■システム連携機能
■プロセスモニタリング機能

「ビリオネアの華麗なるIT」ではつぎのようにしています。だいたい似てますね。

1. モニタリング（プロセス監視、イベント発生時の通知）
2. ワークフロー（プロセス定義、実行）
　　　1. モデリング（ビジネスプロセスの定義）
　　　2. プログラム呼出（プロセスからWebサービスなどのプログラムを実行）
　　　3. フロー実行（BPELなどで記述されたフローを実行）
3. EAI（システム統合）

ではこれらの機能とライフサイクルの関係を見ていきましょう。

最初のプロセスを作る段階では、プロセスモデラーや組織モデラーを使って設計します。それを単純に動かすのは、BPM実行エンジンです。そしてワークフロー機能で制御します。ここでツールにない必要機能はシステム開発します。

さらに業務ルール管理とシステム連携機能を使いプロセス全体をオペレーションします。そして、プロセスモニタリング機能で監視し、その結果から改善策を引き出し、シミュレーション機能で確認して、改善プロセスを再設計するということになります。

確かに、そうなのですが、一度にこんなことはできませんから、段階的にならざるを得ません。ざっくり言うと、最初は何でもいいからプロセスを動かしてみるということが重要ではないでしょうか。

ToBeモデルではなくてもいいから動かしてみると、自分たちの業務の動きが見えてきますし、何か改善の芽が出てくると思います。そこから発展させればいいのであって、最初からきれいにPDCAサイクルをまわそうというのはやめた方がいいと思います。

ということは言い換えると企業の成熟度に応じて導入していくことと同じだと言えます。これについても、以前「成熟度に応じたBPM導入」というエントリーをしているのでそれを見てください。

結局、何を言いたいかというと、BPMの最も大事なことはまずは自分たちのプロセスを動かすことなのです。ですから、ビジネスの実体をそのまま動かして、しかもそれをみなに共有的に見せることができるツールが最も望まれるでしょう。

極論すると、それができさえすれば、BPMSであろうとなかろうと、BPMNで書かれていようがいまいが、BPELで動こうがそうでなかろうが、どうでもいいように思うのです。

なぜなら、BPMはシステムを開発してナンボではなく、動かしてナンボ、すなわち、BPMライフサイクルがきちんと機能することが最大の目的だから、そうしたControl、Operation、Monitoringといったところにシステムのポイントが移っているからである。

ここも、ITを外してプロセス設計したあとの実現方法の議論として重要になるのでみなさんもよく考えてもらいたいと思うのです。
　

前回の議論でアクティビティの粒度はだいたいこんものかという見当をつけましたが、それだけでは、工学的であるとは言えません。中味が問題になります。

それを検討するとき、分かりやすいようによくある見積依頼のプロセスを例に考えてみましょう。

前回の設定した機能レベル２のアクティビティで簡単に表現すると、見積依頼受付―プロダクト確定―納期確定―価格確定―見積回答作成―見積書送付となります。もう少し細かくみていくと、見積書を誰に書かせるかとか、差し戻しとかがありますが、基本的な流れとしてみてください。

これをみると依頼受付という始点と見積書送付という終点、それと見積書作成という実作業の間にはさまれるアクティビティに共通的な機能を見出すのではないでしょうか。

すなわち、見積依頼項目に対して答えなければいけないどんな製品を提供するのか、その納期をいつにするのか、価格はいくらで出すのかというデータ項目を確定していっていることがわかります。

このデータ確定すなわち意思決定を順番にやっていくことでプロセスが構成されていきます。最初にあった依頼に対する答えが出揃った時点でプロセスは終わります。

ここでは、それぞれの意思決定がどうやられているかは関係ありません。このプロセスではひとつの意思決定が終わると次の意思決定を“あるところ”に投げてその結果返してもらうことというフロー制御を行ないます。

こうしておけば、決めなければいけないこと（最初の依頼項目）を“あるところ” に依頼して、そこで処理した結果を受付けるというだけのハンドリングですので、均一で均質なもので連なることがわかると思います。この“あるところ”は別な言葉では”サービス”と言い換えることもできます。ここらあたりはまた後で議論しましょう。

さて、そうなると“あるところ”が何なのかが気になりますよね。すなわち、意思決定の場をどうするのかということになります。これには、決まったものはありません。質の高い意思決定が早くできる場であれば何でもかまいません。

会社の形態やプロセスの性格だとかで選択肢が変わるかもしれません。ただ言えることは、この中にもフローがあるということです。少なくともデータ確定には承認という行為がありますから、ワークフローには変わりません。

ということで、仮に最初のフローをマクロワークフロー、そして意思決定の場をミクロワークフローと規定してみると、この2段ワークフローがなんだか分かりやすくなったと思えませんか。この両者では、処理形態や業務の性格が違うのでそれを分離してみたという意味もあります。

さてその違う意味とはなんでしょうか。そのあたりを大いに議論していきたいと考えています。
　

昨日は2回目の「BPP研究会」を行なう。テーマが「ビジネスと業務の構造化」で、企業における業務の構造を考え、それを構成する要素に分解してみようということです。要素分解するには、ただやみくもにばらすのではなく意味ある粒度にする必要があります。そのあたりの議論をした。

まずは、企業の構造として、サプライチェーンを中心としたコアプロセスと、その周辺として、意思決定サポート、サプライチェーンサポート、定型業務サポートがるという話をする。そして、そうした構造の業務から、業務プロセスや業務機能を抽出するにはといった議論を行なう。

そのとき寄り道としておもしろかったのは、業務プロセスに差別化要素あるいは競争優位の源があるのかどうかという問題である。

ぼくは、以前から業務プロセスそれ自体にはそうした差別化するものはなく、もっと別なところにあるのではと思っていたが、いろいろな意見がでる。

そのなかで、ぼくはプロセスというか業務のフローそのもののことを言っていたが、プロセスにはそのパフォーマンスで違いがでてくるので、やはりプロセスも差別化できるのではないかという話がでた。

ここはけっこう重要なところで、というのは今までのシステム化というのはシステムを作って終わりみたいなところがあるので、それをうまく使いこなして効果を上げたということが少ないため、単にITを入れただけで競争優位性を埋め込んでいないのだ。

だから、BPMという考え方は、このシステムを作っただけでなく、それを効果的にオペレーションすることで差をつける意味が大きいのである。そういうことを議論できることがうれしかった。

そして、その時の効果を測定するメジャメントをどうするのかという議論に続いていく。プロセスの何をモニタリングしてその結果として、どう改善につなげていくかが非常に大事なことなのである。

このパフォーマンスについても、個別局面での効果判定と全体プロセスの効果判定の両方がある。個別最適が決して全体最適につながらないケースも当然でてくるので、そのあたりの評価基準も必要になってくる。

ぼくは、プロセスは意思決定の連鎖であると規定しているので、ただ昨日言われたがプロセス全体も“意思決定”でもあるのだが、そこでモニタリングするのは、「意思決定の質とスピード」だと思っている。

ここでは、スピードはわかると思うが、では質って何よとなる。質とは手戻り率（差し戻し率）や顧客応答時間みたいなもになると思っている。

そして、この質とスピードはトレードオフでもあって、早く処理したいがためにいい加減な意思決定をして、全体としてパフォーマンスがあがらないことにもなりかねない。その両方をバランスさせることが重要なのである。

ちょっと長くなったが、この話はプロセスパターンとはちょっと違うのでテーマに入れてなかったが、別の機会でもいいから議論した方がいいかもしれない。

さて、業務プロセスを抽出して、それをフロー化するとき、そのアクティビティの粒度をどう決めていくかが、主テーマであって、それに対して、ぼくのほうから「マクロとミクロの2段ワークフロー」という考え方を提示した。

すなわち、マクロワークフローのところの粒度は定型的でシーケンシャルに並べられる。その時の箱すなわちアクティビティは“単位意思決定”であるとした。

その単位意思決定をするのがミクロワークフローで、それは非定型なのもので、それを行なう場は、3種類あって、情報共有の場、一般的なワークフロー、そして画面や帳票であるという提案をした。

それぞれについてケースバイケースでどう使い分けるのかといった論議は次回にするが、こうして2段に分けることによって分かりやすくなると思うのだが、まだまだ議論の余地がありそうで大いに意見交換をしていきたい。

そして、議論で考えさせられたのは、2段にできるのは定型的なルーティン業務なのではないかということで、それ以外にプロジェクト的に動く業務や定型とプロジェクトの中間のような業務があるが、そうしたものへの適用をどうするのかという意見もあった。ここら辺も次回に議論しようと思う。

要するに、業務プロセス・機能の持つ“性格”が違うのである。性格の違うものを一緒くたにしないことで、アプリケーション的にもプラットフォーム的にも分けて考える必要があると考えている。来月のテーマはここですので、みんなでよーく考えましょう。
　

このあいだ、「SOA時代のデータ管理」というエントリーを書いたが、そこではデータベース設計をどうやるかには言及していない。それで、最近そのことについてずっと考えているが、なかなか答えが見つからない。

データベース設計というと、DOAが浮かんできます。データ総研の椿さんはいつも、DOAの条件として、「データ先行・リソース先行・概念先行」ということをおっしゃっています。データをプロセス／処理に先行して考え、イベントデー タ（受注・出荷・請求など）より先にリソースデータ（社員・顧客・商品など）を固め、物理データベースより概念データベースを先行するという意味です。

では、POA（という言葉があるとすれば）だとどうなるのでしょうか。「プロセス先行・マクロプロセス先行・概念先行」といったところでしょうか。しかしデータベースはどうするのだの答えにはなっていません。

DOAだと一般的に言われるのは、画面と帳票からデータを抽出するということですが、プロセス志向だとどうなるのでしょうか。

まずプロセス志向の開発のやり方を自分流に考えてみると、最初に画面と帳票は考えずに、というかITを意識することなくプロセスを書き出します。そのあと、そのプロセスで確定していくデータや参照するデータを捕捉していきます。そのあと、そうしたデータを確定していく場としての画面を考えていくわけです。

そして、帳票は原則登場してきません。もちろん、法定帳票やデータ分析の帳票などはありますが、その他は考えないようにします。なぜなら、帳票の使われ方のひとつは、電子化されている業務と電子化されていない業務の橋渡しですから、全部の業務を電子化してしまえば、必要なくなのです。

ですから、データの捕捉のアプローチが従来と違ったものになるわけですから、データベースの設計の方法も違ってくるのではないかと思っています。

しかし、いまその答えがあるわけではなく、一生懸命考えている最中である。そこで、救いの神が、羽生章洋さんが書いた「楽々ERDレッスン」（翔永社CodeZineBooks）である。

この本に書いてあるデータベース設計のことが非常に参考になる。（羽生さん、おとといも山本陽平君とふたりでこの本はすばらしいと称え合いました）いまこの本を何度も読み返しながら頭をひねっているのである。
　

これからはビジネスプロセスを実行するプラットフォームについて考えていきましょう。これまでに、業務プロセスの階層化とコンポーネントをおこなってきましたが、その階層化された業務コンポーネントを機能させるためにもプラットフォームの階層化が必要になります。

業務機能の性格が違うのだから、動かし方も違うので、それぞれにフィットしたものを用意してあげる必要があるからです。

業務プロセスはマクロワークフローとミクロワークフローに分けましたので、これからその呼び方で議論していきます。

そして、マクロワークフローは単位意思決定＝データ確定の連鎖であり、ミクロワークフローはその単位意思決定の場であるというふうに規定しました。

では、この二つのワークフローでどういう性格の違いがあるでしょうか。まず、ミクロワークフローである単位意思決定をみていきます。

これは簡単に言うと４W２Hを決めることだと思ってください。すなわち、「何を（What）いつまで（When）にどこの（Where）誰が（Who）いくら（How much）でどのように（How to）作業して決める」（Whyはプロセス依頼の起点となる依頼には必ず理由がすでにあるものだから、後から決めるものではありません）のかです。

そこでこの仕事の特徴をみてみると、非常に不定形で不安定であることに気がつくと思います。依頼元がどこなのか、対象商品は何なのか、急ぎなのか、また季節だとか、決算期だとかで違ったりと、ケースバイケースであるのが多いでしょう。とくに顧客接点から始まるプロセスでは、決まりきった処理というほうが珍しいかもしれません。

一方、単位意思決定の連なりであるマクロワークフローは、決まったことを流すわけですから、わりと定型化されたフローになります。

こうしや高次レベルの仕事のやり方というのは、業種、業態や会社の規模などにあまり左右されません。例えば、オーダーが来て、それに対して、プロダクトを選定し、価格を決め、納期を確定するといったことは、どこも大差ないと言えます。

違いが出るのは、それらの決め方のところです。大きな会社では決定ルートが長いが、小さな会社では一人で何でも決めてしまうというようなことです。

このように、マクロワークフローとミクロワークフローではそのフローの持つ性格が違うということが理解できたでしょうか。

そして、さらに特徴的なのは、そのフローを回す主体も違うということです。非定型で不安定な処理であるミクロワークフローは、人間主体にならざるを得ません。ここではたえず人間の判断が優先します。

ところが、定型で安定なマクロワークフローは、その会社や組織の決められたルールに沿って回すことができます。それは、人間が介在しなくてもシステムが主体で流してくれます。

今回は、業務処理の性格や特徴が違うこと、その違いによって処理の担い手も変わることを議論しました。次回はそれを実現する“場”について考えてみます。
　

先日のBPP研で、マクロとミクロのワークフローという概念を提示した。要するに、業務プロセスを分解していったとき、BPMS記述するようなレベルでは、2段構えでプロセスをわけた方がよいことを説明した。このマクロワークフローとミクロワークフローにし、それぞれでつなげる機能の粒度を合わせることで、分かりやすくするメリットがある。

マクロ経済とミクロ経済ということもあるように、いろんな領域でマクロの眼とミクロの眼をもってながめることがなされる。

同じように、物理学では量子力学の視点をミクロ、古典力学の視点をマクロと呼ぶ。他にも木を見て森を見ずとか言われるように微視的と巨視的視点の両方が大事なのである。

先に言ったのは業務プロセスのことですが、システム全体にもこのことは言える。SOAの時代では特にこの視点をもっていないと個別サービスだけを見ているとサービス同士の有効なつながりができなくなる。
このように、鳥の眼で俯瞰し、虫の眼で凝視することを片方ではなく相互に繰り返すことが必要なのである。

この思考方法は、分かりやすくは囲碁を考えてみるといい。ずっと昔にもこのブログでも書いたが、囲碁は布石があってこそ、４隅の生死が重要なのに、いきなり４隅の生死にいってしまう人がいる。結局、局面では勝利しても全体では負けたとなる。これは戒めなくてはいけない。

最初のところから若干ずれてしまったが、マクロとミクロの２段でものごとを見ていくということがいかに大事であると言いたかったのである。個別事項にのめりこんでいるときにふとそこから離れて大きな眼で眺めて見るということである。

それは、日常の仕事でも言えることで、細かい部分で仔細にチェックし、その集まりは少し視点を上げて整合的であるかをチェックすることが求められているのである。だから、この２段思考アプローチを業務プロセスへ敷衍してみたのである。
　

前回は、マクロワークフローとミクロワークフローとでは業務処理の性格も違い、処理の担い手も違うことを提示しました。そうした違いがあるのなら、それらの機能を実現する“場”も変えたらいいというのがここでの立場です。

従来は、これらを一緒くたに考えていて、下手するとそれを全部コードで書いていたのではないでしょうか。あるいは、あらかじめ同じプラットフォームに組み込まれたパッケージというものを使っているかもしれません。餅は餅屋というか適材適所を考えるべきであると思います。そういうことができるようになったのもSOAという概念のおかげでもあります。

さて、それではまず、ミクロワークフローである単位意思決定をどういうところで行なうかを考えていきましょう。意思決定プロセスはサイモンを持ち出すまでもなく、いろいろな情報を参照しながら、選択肢を見つけ、調整しながら最終的な答えを導き出し、業務だと承認されて終わります。

ですから、この営みをどこでやるかになるわけですが、意思決定をする“場”には、3種類のものがあると考えられます。一つは、従来のような画面や帳票回付で、二つ目が、一般的なワークフローです。そして、3つ目が、情報共有型Webサイトです。

画面･帳票は、担当者が画面を開いて、あるいは帳票を回して意思決定していくもので、一般的なワークフローは、申請(起案)－承認ワークフローと呼ばれるようなもので順番に回していくわけです。情報共有型というのは、SNS、Blog、Wikiといった参加型の仕組みを持ったWebサイトのことです。

それらをどう使い分けていくのかを検討するには、意思決定の形態について考えてみるとよいと思います。まず単独行動なのか、それとも複数の人間が関係するグループ行動なのかを考えましょう。

従来は、単独行動で行なっているケースがけっこうあったのではないでしょうか。例えば、今のシステムの画面操作を考えてください。担当のオペレータが一人で画面を開いて入力するシーンでは、少ない参照情報のもと単独で意思決定しているのではないでしょうか。

もちろん、重要なものは電話、メール、FAX、直接の会話などで調整や確認をしながら意思決定をするでしょうが、おおかたは担当の単独意思決定があり、最後に承認をもらうパターンではないでしょうか。

こうしたやり方は、一般的なワークフローもそうですが、決まりきった流れの定型的な処理であればいいのでしょうが、各所と調整をとらなくてはいけないとか、差し戻しが頻繁に起こるようなケースでは、手作業に頼らざるをえないか、複雑なワークフローを書いてわけがわからなくなるような気がします。

こうしたことを考えていくと、従来の画面と帳票はもはや役目は終えたように思うのですが、いかがでしょうか。重要なことだけではなく、通常の意思決定もできるだけ関係者の参加で意思決定ができるようにするほうが意思決定の質と速さが向上します。

現実的には、定型的なものもあるので、一般的なワークフローと情報共有型Webサイト（これをCollaborative Work Spaceと呼びたい）の組み合わせになると思っています。

次回は、マクロワークフローの実現の場を中心に議論していいます。
　

いまビジネスプロセスパターンで意思決定の場として、Collaborative Work Space ということを提案しています。それは具体的には、SNS、Blog、WikiといったWeb2.0技術を使った情報共有サイトを指しています。
ここで、なぜそうした技術や機能を使うのかということを考えてみましょう。

あるところで、もうWeb2.0という言葉は使わないほうがいいのではと言われた。そうした言われ方には、もう陳腐化して使い物にならないということと成熟して当たり前になったという2つの解釈が成り立つのですが、Web2.0の場合はどちらでしょうか。おそらく後者のことだと思います。ネットの世界では当たり前のように若い人たちは使いこなしています。

このWeb2.0がもたらした変化は何だったのでしょうか。従前のものとの違いは何なのかをみると、３つの大きな特徴があると考えています。

１） 双方向コミュニケーション
２） オンデマンド
３） ハイパーリンク

双方向コミュニケーションというのは、言い方を変えると、だれでもが情報発信できる手段を持ったということです。これまでは、マスメディアにみられるように普通の人は一方的に情報を受信するだけでした。

それが、一方通行ではなく、双方で情報の行き来ができるようになったわけです。そこから、集合知だとか参加型のコミュニティができました。コミュニケーションの広がりや知識の獲得が容易になったのです。

オンデマンドというのは、好きなときに好きなところへアクセスして情報を得ることです。テレビの例でもわかるように、こちらの事情には関係なく情報を垂れ流してきます。自分の生活のリズムをそちらに合わせなくてはいけないという変な関係でもあったのです。

いまや、テレビもとりあえずHDDで全部録画しておいて、後から好きな時間に見るといったスタイルも増えてきています。人間は機械に使われるのではなく、人間が機械を使うという主体性を持ちたかったのです。

ハイパーリンクはインターネットの基本のところで、当たり前と思っている人が多いと思いますが、実はこのおかげで情報へのリーチとスピードが格段に向上したと思いませんか。

そうです、このリーチとスピードを得たことで「フラット化した世界」が現出したのです。それは組織のヒエラルキーを破壊することを意味し、閉じられた情報を握っているからこそ高い地位にいる人たちの存在感を薄めて行きます。

こうしてみると、企業の中でも非常にインパクトを与えそうな変化がもうネットでは当然のように起こっていて、それは人々にメリットを与えているのです。何よりもそういうスタイルが確立してきているのです。

ですから、これから企業にもどんどん若い人たちが増えてくるわけで、仕事のやり方も変わらざるを得ないわけで、そういう意味でWeb2.0技術を使ったCollaborative Work Spaceはこれから必須になっていくように思うのです。いいものは早く使いましょう。
　

さて今回は、マクロワークフローの実現の場を中心に議論していきます。マクロワークフローというのは、意思決定の場で決められたことを受け取って、次の単位意思決定に流す役割を担っています。

前回あまり言っていなかったのですが、単位意思決定の場は、ミクロワークフローと言っていますが、むしろワークフローというより、ステータス（状態遷移）制御の方が理解しやすいと思います。

すなわち、最初は決定してほしいという素案が提出されます、その素案のステータスがだんだん遷移して最終的に確定・承認というステータスで終わるわけです。

一方、マクロワークフローの方は、上述したようにフローを制御します。分かりやすく言うと何かを決めてくれと依頼して、その結果を受け取ったら、つぎに決めなければいけなことをまた依頼していきます。

その順番や、場合によっては分岐したりということ、あるいはBPMらしくということであれば、滞留を検知して早く処理するように催促したりするわけです。

このフロー制御の場はBPMSになります。BPMS(Business Process Management Suite)は、BPMを実行するための機能群のことで、そのなかには、必要最低限の機能とあった方がいいものや徐々に高度化していくための機能があります。

モデリングやモニタリングなどは後者にあたり、これらの機能を初めから全部使ってBPMを実践する必要はありません。ですから、ここで言うフロー制御の場は、必須機能であるBPM実行エンジンとワークフローとなります。

最近では、BPMSは市販のものからオープンソースのものまで数多くの製品があり、搭載機能もいろいろです。ではどれを使えばいいのでしょうか。

ここでよく考えてほしいのは、2段ワークフローという考え方を採用した場合のBPMSは一般的な評価でいいのかという問題です。いま出回っている製品はこうした考え方に基づいて作られていませんので、既存のBPMSのもつ機能がどうのというより、2段ワークフロー方式が要求するものから見てみます。

必要な機能は、前述したように依頼と受付というイベントを回すことですから、とりあえずは必須機能であるエンジンとワークフローがあればいいと言っているのです。言ってみれば、多くの機能があるよりも非常にシンプルで頑丈なエンジンでいいのです。そのあたりが選択のポイントになります。

しかしながら、それだけでもないケースももちろん出てきます。たとえば他システムやデータベースとの連携があります。また、業務ルール管理やBAM（Business Activity Monitoring）などです。ただ、こうした機能はビジネスプロセスパターン研究とは少しずれてきますのでここでは議論しないことにします。

ということで、業務フロー（マクロワークフロー）はBPMSの必須機能であるプロセスエンジンとワークフローを使って制御することになります。
　

これまで、非定型で不安定な人間主体の単位意思決定とそれらを回す定型で安定なシステム主体の業務フロー制御という観点から、マクロワークフローとミクロワークフローの“場”について議論してきました。

ただし、業務システム全体について考えたとき、それだけではないことに気がつくと思います。すなわち、基幹システムとの関係やデータはどうなっているのということです。その関係が定義できなかったらただのワークフローで終わってしまいます。

プロセスで生成されたデータは、データベースに登録されますが、最終的には勘定系の決算システムでデータを更新することになります。ビジネス活動の結果がデータとして集約されます。すなわち、従業員数といったヒト、出荷量や在庫量といったモノ、売上高や経費といったカネというものになるわけです。

従って、システムの構造は3層構造になります。抽象的な言い方だと、機能とプロセスとデータの3層です。もう少し具体的に言うと、表層的な業務処理を行なうのが機能ですがユーザインターフェースと言ってもかまわないと思います。そして、中間層に位置するのがプロセスでこれはさんざん議論してきたとことになります。

そして、バックヤードにあるのがデータ層ですが、これは単にデータベースだけではなく、先ほどのように決算システムのようなものを指してもかまわないと思います。ERPの根幹のところです。会計システムでもいいかもしれません。

こうして3層にするのは、最初のエントリーでも書いてありますが、業務処理の性格が違うからです。非定型で不安定であいまいな人間系処理は機能で、定型で安定な逐次フロー型の処理がプロセスで、それらを集約して決算につなげるデータという区分けになります。

その他、構造的には、今まで言ってきたコアの構造での仕掛けを動かすためにサポート的に機能したり、サービスを要求したりすることも往々にしてあります。そうした連携もできる構造が望まれていて、これもSOA的で、Integration Centric BPMということになるのかもしれません。

実は、これからは定常、非定常も含めて業務プロセスの処理をサポートするための情報提供の充実がカギになるような気がしています。それは、いまやさまざまな情報が蓄積され、それを簡単に取り出せるようになったために、その情報の活用度の違いがビジネス遂行の優劣につながる可能性があるからです。

これを、BI（Business Intelligence）などと呼んでいますが、従来は結果の分析に使われるのが主だったように思いますが、それだけではなくプロセス実行時にも有用な情報を提供するようなBIが望まれるのではないでしょうか。
　
こうした、業務アプリケーションとそれが動くプラットフォームを３層にして、お互いに疎にして連携させるという概念が非常に重要です。BPM on SOAという概念の具体的な実行形態としての表現がここにあります。
　

昨日、3回目となるBPP研の勉強会を行ないました。大型連休明けすぐということもあり、仕事の都合で欠席の人が多かったのですが、かなり突っ込んだ議論ができたように思います。

この日のテーマは、「柔軟なプラットフォームをつくる」と題して、業務アプリケーションをどういったプラットフォームで動かしたらいいのかという話である。

前回に業務の階層化を行い、そこでマクロとミクロの2段ワークフローという概念を提示した。さらに、その業務の階層化に対応して、プラットフォームも構造化する必要があるということを提起した。その時のベースになる考え方は、機能とプロセスとデータを分離した3層構造を採用することである。その構造に、業務の階層レベルを当て込むのである。

重要なのは、その機能・プロセス・データの分離と疎結合ということである。ここがミクロSOAの肝のところである。ミクロSOAというのは、勝手につけた名前だが、要するにサービスの粒度が小さいSOAである。その小さい粒度のサービスをプロセスでつないで業務システムを作るという考え方である。

ではマクロSOAというのは、サービス単位が大きい、例えば、SFA、CRMなどをサービスの単位としていることで、コンポジットアプリケーションなどとも呼ばれている。BPMはミクロSOAの基盤で動かす仕組みであると考えている。

また、話はそれますが、今言った３層構造というのがこれからの大事な考えかたになるわけですが、従来はこれができなかったのです。システムの成り立ちのそもそもは全部一緒くたになっていました。機能もプロセスもデータも一つのプログラムという形で埋め込まれていました。

そして、RDBMSの登場により、データは分離されましたが、機能とプロセスはそのまま密になっていました。それが、BPMSが出てくると機能とプロセスを分離することができるようになったのです。

ただし、実際にはBPMSはそんな意識がなくて作られて、ほとんどのBPMSベンダーはここに気がついていません。BPM on SOAのポイントはこの３層構造なのですから、単純にBPMSを使っただけのシステムを構築したところで、柔軟なシステム構造にはならないのです。

さて、こうした3層構造と業務階層の対応はどうなっているのでしょうか。まずは機能のところですが、前回議論したように単位意思決定機能をもったミクロワークフローを実現するところにあたります。

それは少しはしょった言い方かもしれませんが、ユーザインターフェースということになります。実は、このユーザインターフェースということもよく検討する必要があると思います。ユーザインターフェースというとすぐに従来型の画面を思い出すと思いますが、プロセスを分離して、単位意思決定の場としてUIをもってきたのですから、そこをちゃんと機能させるために従来の画面はふさわしいのでしょうか。

昨日も議論になったのですが、こうした意思決定には多くの参照すべき情報や守るべきルールなどがあって、それを見ながら処理するわけで、そう考えただけでもこれまでのデータ登録を主体にした画面では限界があるのがわかると思います。

この観点で見ると、いまのBPMSの画面も使い物にならないことがわかります。実際にもBPMSの画面ではなく別箇に画面を作る例が多いという話が昨日も出ていました。

次にプロセスはもちろんBPMSというプラットフォームを使いますが、ここでの考え方はBPMSベンダーが言っていることとだいぶ違うように思えます。先ほどの画面もそうですが、プロセスの稼動管理なんかも単にタスク一覧にその時点のステータスがでるだけでいいのでしょうか。

また、モニタリングなども成熟度の低い企業ではすぐにできやしないわけで、そうなるとBPMSは一体何なのかと思ってしまうのである。プロセスエンジンとワークフローがまずあればそれでいいというのは言いすぎだろうか。

データについては、以前から言っている“プロセス志向におけるデータベース設計のありかた”をよく検討していく必要があると思っている。

結局、プロセス志向で考えた場合のプラットフォームが、従来型とはずいぶんと違っていたり、ツールベンダーの言う売り込み機能とも違っていたりということをきちんと理解しないと利点を生かせないことになる。

従って、新たな視点で捉えたプラットフォームを再設計する必要があると思っている。幸い、スクラッチで作る必要はなく、ウエッブ系にある技術やサービスをうまくモディファイして、それらをアセンブルすることで実現できると考えている。そこには一旦ゼロベースにして考える柔らかな頭が要るわけで、若い人たちがぜひ挑んでほしいと願っている。
　
次回はいよいよプロセスパターンについての議論になる。　
　

いよいよプロセスパターンの検討に入っていきます。業務プロセスをパターン化して、その基本的な構造をテンプレート化できなかということです。

しかし、いきなりそこには入れませんので、オーソドックスにボトムアップでプロセスを設計してみましょう。といっても、この普通に設計するのも意外に難しいのではないでしょうか。どこまで粗く、どこまで細かく表現したらいいのだろうかが悩むところです。

そこをちゃんとガイドしてくれるものが要るように思います。ただ、きっちりと杓子定規的に決められるものでもありませんから、だいたいこんな風にすればできるといった”お作法”になります。

前回までに、プロセスは意思決定の連なりであるということを言ってきました。ですから、その意思決定のためのアクティビティを抽出していけばいいのですが、それだと少し抽象的なので、ここでは、アクティビティーシートで中味を定義して並べていくというやり方にします。

ですから、シートはわかりやすいように書類名、例えば、「見積依頼書」とか「納期確定書」といった名前がいいでしょう。ただ、それでなくてはいけないということではありませんから、別の名前でもかまいませんが、どういう意思決定を行なったかがわかるようなネーミングにしてください。

まずは、大まかな手順をみてください。

１．プロセスの始点と終点を決めます
２．始点は「依頼を受付ける」ところから始まり、受付タスク管理表に依頼事項や受付状況を記載します
３．終点は最終的なシートで、登録や報告といったアクティビティになります
４．コンテ（業務・仕事のあらすじ）を作ります
５．最終シートの必須データ項目を依頼に対する答えとしてリストアップします
６．コンテに従って中間シートを並べていきますが、終点から遡ってデータを確定していくようにします
７．中間シートには誰が何を参照して何を決めるかを書き、それが途切れがない連続性のあるものにします
８．サポートシートに、参照情報としての業務ルール名やリソース情報、計画情報などとともに連携するデータベースやサービスもここに記述します

まだ、細かいところがありますが、主要な作法はこんなところになります。

大事なことは、繰り返して言っているように「シンプルで一貫化されたきれいなプロセス」を作ることにあります。この作法に従って設計すればそうした業務プロセスができるはずです。少なくとも、マクロワークフローレベルのプロセスはシンプルで論理的なものになります。

次回からは、個別に詳しく見ていくことにします。

作法の最初は、プロセスの始点と終点を決めることです。業務プロセスは何から始まって、どこで終わるかですが、あまり深く考えないで適当に決めてはいませんか。

プロセスというのは、それが意味なく存在するわけではもちろんないわけで、そうすると始点も終点も定義しておく必要があります。

本作法では、○○から○○までというように書き出します。例えば、受注から出荷までとか引合から見積とかいった表現になります。

では、始点とはいったい何なのかを考えて見ましょう。これは、ひとことで言うと「依頼」ということになります。プロセスは必ず何らかの「依頼」によって始まります。この依頼には、いろいろなタイプがあります。大きくは、外部からの依頼、内部からの依頼、ルール化されたトリガーによるものがあります。

また外部からの依頼もそれが特定顧客からのものか不特定多数からのものかがあり、それにより受け付け方が変わってきます。内部のものは、上司からであったり、関係部署からであったりです。ルール化されたものでは、DBが更新されたら動くとか、決められたスケジュール例えば月初になると定期的にスタートするとかがあります。

こうして様々なタイプの「依頼」に対してプロセスが起動するわけです。

さて、プロセスの始点と終点を特定すると言いましたが、どちらから先に決めるのでしょうか。基本的な考え方は、顧客接点のプロセスでは始点を先に決め、内部プロセスの場合は終点を先に決めることになります。

要するに、顧客接点では、お客様からの要求が何かが最優先となり、その要求に答える形でプロセスを設計します。一方、内部プロセスでは、最終的にはBS/PLにつながることを意識して終点から決めていきます。

この考え方は、BPMの企業情報システムのなかにどう登場してくるのかに関係しています。ざっくり言うとBPMは、受発注や調達などの基幹業務プロセスと顧客接点業務（広義の意味で従業員接点業務も含むサービス業務）にその主要な役割があると思っています。

ここまで言ったことは、「プロセスの目的合致性」と呼んでいますが、なぜそのプロセスが存在するのかを明確にすることなのです。ただし、気をつけなくてはいけないのが、“目的の明確性”ということではないということです。

目的が明確になっているプロセスでも会社にとって必要でない場合もあるからです。ですから、必ず会社にとってあるいは事業活動にとって必要なプロセスでなくてはいけなくて、それゆえ顧客への対応とプロセスの終点が事業活動の結果として決算書に反映されることが重要なのである。

次に、依頼の受付をどうするかが問題になります。前述したようにいろいろなタイプの依頼が飛んできます。ルーティン化されたあるいはそのままエスカレーションしてもよいものは、「依頼受付」というアクティビティからプロセスをスタートすることができます。

問題は、ルーティン化されてない非定型な依頼の場合である。こういうケースでは、そのまま後ろに流すわけにはいかないので、依頼の内容をよく吟味してOKならエスカレーションするという仕組みが必要になります。

いわゆる案件管理システムとかチケット管理システム、イシュートラッキングシステムといったものです。こうしたことを言っている人はいないのですが、BPMの先端にはこういったシステムが必須に近いように考えています。

「依頼受付」のアクティビティで考慮することは、５W１Hを頭の中に入れて依頼事項を受付タスク管理表のような形で整理することです。すなわち、どこの誰からの依頼なのか、依頼内容とその理由、いつまでどうやって答えたらいいのかということを明確にしておくことです。

今回は始点と終点の決め方と依頼受付管理についてで、次回はその間のプロセスをどうやって設計していくかになります。
　

引き続いて個別作法のお話です。前回では、プロセスの始点、終点と依頼受付機能のようなお話をしましたが、今回は終点とプロセスの流れを見ることが中心となります。

それでは、プロセスの終点となるアクティビティとはいったい何なのでしょうか。どうなるとプロセスが終わるのか、どうやって終わらせるのかということです。前回、プロセスが起こされるのは、顧客接点からと内部から生じる場合のケースを提示しました。この二つのケースで終点の考え方が変わってきます。

お客さんからの依頼の場合は、その依頼に対して回答しなくてはいけませんから、その報告や情報提供といったことが終点となります。例えば、見積の依頼が来て、それに対して見積結果を返してやるといったプロセスがそれに該当します。

一方、内部プロセスの場合は、最終的には基幹DBを更新することがそれにあたります。それは、“ヒト・モノ・カネ”の出入りを表現したものになります。入出金、入出荷データなどの登録・更新ですが、この場合のプロセスの切り方をどうするかは考慮が要ります。

例えば、入出荷といっても厳密に言うと最後は代金請求して入金されてプロセスは完結するとも言えます。ところが、それだとプロセスが長くなるのと、性格が違うプロセスをつなぎますので、現実的には、ヒト・モノ・カネは別のプロセスとして一旦切った方がいいと思います。

その場合、DBへの登録・更新で終わる事が前提であること、ですから中間の過程でも例えば個別で一旦登録しておいて、それらを集約して続きのプロセスが走るような場合もそこで一旦切ってもかまいません。

こうしてプロセスの終点を見ていくと、基本的に「BS/PL」につながっているのかどうかという観点が必要です。別な言い方をすると、“勘定科目データ“を生成するためにプロセスがあると考えることになります。もしそうではなかったら（顧客接点の場合はこういうケースはもちろんあります）、そのプロセスの存在そのものを見直すべきでしょう。

次に、この終点のアクティビティで最終的に確定する必須データ項目を定義します。いままで述べてきたように、依頼から始まるケースでは、依頼された内容に対して登録・報告すべきデータ項目になります。例えば、見積依頼であれば、対象商品名、スペック、数量、価格、納期などになります。

内部プロセスの場合は、出荷、購買、製造などの商品別の量だとか売上高などといったものが対象となります。

さて、こうして最終的にどんなデータを確定するのかがわかると、その複数のデータをどういう順番で確定していくのかを考えていきます。この場合のデータというのはあくまで必須データのことです。参照データや付帯情報などはここでは外しておきます。

このデータ項目と順番を見るときにわかりやすいように「コンテ」というものを作ることを薦めています。コンテというのは映画などでも絵コンテといって映画を撮る前にだいたいのストーリーとカット割がわかるものを作りますが、それと同じです。業務では仕事のあらすじを決めておくといった感じになります。

ここで頭に浮かべてほしいのは、業務プロセス（マクロワークフロー）は、単位意思決定の連鎖であるということです。ですから、単位意思決定をコンテの一枚に埋め込むということがポイントになります。もう少し分かりやすく表現すると「依頼を受付けて何かを決めて次に依頼する」という動作のつながりとなり、決めるとはデータを確定していくイメージとなります。

ですから、コンテ1枚には、○○の依頼を受付けて、○○を決め、○○を依頼するという流れになります。例えば、見積の依頼を受けて、仕様を決め、見積依頼書作成を購買部に依頼するというような感じです。

そしてそこに、参照情報（業務ルール含む）、連携サービス、分岐を記入していきます。下図にそのイメージを示します。ただしここでは、参照情報、連携サービスはここでは厳密に書かなくてもだいたいのことでかまいません。

こうすると、業務プロセスのおおよその流れが見えてきます。次回から、その中間のアクティビティの作り方を考えていきます。
　

　

さて、コンテを作ってアクティビティが特定されその順番も決めましました、そして、最終的に確定すべきデータ項目も設定しました。次はその中間のアクティビティのプロパティを見ていきます。

この場合、終点から遡って決めていくことになります。それぞれのアクティビティで確定するデータを定義するのに、終点のひとつ前は何を決める、その前はという見方の方が分かりやすいからです。しかし、結果的には、始点からデータを追記して行くというイメージでもあります。簡単な例として見積依頼プロセスでのデータ項目表を末尾に載せておきました。

中間のアクティビティにはそこに記入するデータ項目や参照情報といったものを記入するシートで整理した方がいいので、そうしたシートを使うことにします。遅ればせながら、始点も終点も同じようにシートに記入していきます。

コンテでは簡単に書いていた参照情報などはここではきちんと定義しておきます。必要情報は下記のような項目となります。

・ 前シート名、No
・ プロセス名、アクティビティ名（書類名）、シートNo
・ 作成者、メンバー、承認者
・ データ（確定データおよび参照データ）
・ 分岐
・ 参照情報、連携サービス
・ ビジネスルール
・ 後シート名、No

そして、これらに付随する関係性を表現するためのカードを用意します。そのカードの種類としては、参照カード、連絡・確認カード、サービスカード、分岐カードがります。そこに必要事項を記入し、シートとの関係を明確にしておきます。

もうひとつ、必要に応じてサポートカードを用意します。これは、意思決定を行なうために、例えば計算をしてみるとか、設備の稼動スケジュールが知りたいだとかといった支援機能を記入します。

ここまで書ければプロセス設計はおおかた終わりになります。始点シート－中間シート－終点シートという並びがマクロワークフローになります。そのそれぞれのシートに書かれた内容がミクロワークフロー（情報共有サイトのサイト構造）を表現しています。

中間シートでどんな情報をもとに、誰に確認をとって意思決定（データ確定）し、誰が承認したかを記述し、それをインプットとアウトプットを整合させて途切れずつないで業務プロセスが出来上がることが理解できたでしょうか。

プロセス設計作法について書いてきたが、その作法で表現したいプロセスはどんなものでしょうか。それは再三、言っているように「シンプルで一貫化されたきれいなプロセス」です。

そのためにチェックしておかなくてはいけないいくつかのチェックポイントがあります。それは次の7つであると考えています。

①なぜそのプロセスが存在するかが明確になっているか　【合目的性のチェック】
②業務プロセスとデータが途切れず流れているか　【一貫化のチェック】
③業務プロセスが複雑で分かりにくくなっていないか　【シンプル化のチェック】
④業務機能で似て非なるものを一緒にできないか　【共通化のチェック】
⑤同じ業務処理なのに部署によって違っていないか　【内なる標準化のチェック】
⑥業務機能で例外処理がないか、へんなこだわりはないか　【外なる標準化のチェック】
⑦電子化やシステムに置き換えができないか　【IT化のチェック】

それでは、ひとつづつ簡単に見ていきましょう。合目的性では間違えてはいけないのが、目的の明確化とは違うということである。目的が明確になっていればいいというわけではなく、それが会社の目的とつながっていることが重要です。

一貫化ということでいうと、プロセスが途中で切れてしまっているとか、前後でつながっていないとかがないようにすることです。

シンプル化は見える化の重要な前提条件となります。冗長的なプロセスにならないように、アクティビティの数はできるだけ少なく、分かりやすい構造にしなくてはいけません。

社内には似たような業務処理が散在していることがあります。少しくらいの差だったら共通化したらどうでしょうか。逆に言うと、共通化できる粒度でプロセスを描けないかということなのです。

標準化には内なる標準化と外なる標準化があります。本来同じ業務処理をおこなっているはずなのに、部署によって違うというケースがよくあります。確かに、仔細なレベルではそうかもしれませんが、あるレベルでは標準化できるはずです。

また、業界標準とはかけ離れたり、へんなこだわりプロセスがないかというチェックも必要です。
最後は、プロセスを描いていくと手作業でつなぐケースも出てきます。そんなときIT化をしたらどうかという見方をすることも大切です。

以上、7つのチェックポイントを示しましたが、これまで提示した作法はこうしたチェックが自然にできるように作られています。ここでは、繰り返しませんが、作法のひとつひとつを吟味していくときれいなプロセスのためにそうなっていることがおわかりになると思います。

これからはパターン化の話になります。これまで3回にわたって設計作法を見てきましたが、その作法に基づいてプロセスを記述していくとだいたい同じようなパターンになってきます。

事例をもとにそこを考えていきますが、前にも言ったように、プロセスには顧客起点と内部プロセスがるといいましたが、これからは分かりやすいように顧客起点（広義の意味で従業員起点も含めます）のプロセスについて取り上げてみます。どちらも結局は同じなのですが、プロセスも短くなじみやすいのでそうしています。

前回のデータ項目の例で出てきた見積依頼プロセスについて見ていきましょう。これは、あるお客さんから見積依頼がきて、それに答える形で見積書を提出するというプロセスを想定します。見積の対象は何でもかまいません。プロダクトでもいいですし、工事みたいなものでも、開発工数でもかましません。

作法に従えば、依頼受付は案件管理の仕組みで受けるというようになっていますが、ここでは、簡単にするために依頼をそのまま受付けてエスカレーションするということにします。

まずは受付内容を明確にします。ここでは、ある設備工事の見積依頼として、依頼先部署・氏名(who)、工事名（What）、依頼内容・理由（Why）、場所（Where）、工事希望日（When）、希望施工方法（How to）を確認しておきます。できたら、予算（How much）も聞けたら聞いておきます。

これが分かると、この依頼に対する答えが最終アクティビティのデータ項目になります。そうすると、最終確定データは、「見積作成者」「工事仕様」「納期」「見積金額」などになります。

ですから、これらのデータをどういう順番で決めていくかを並べて“コンテ”を書きます。普通に並べると、まず見積する人を決め、次に中味の仕様と納期を決め、そして最後に見積金額を確定するということになるでしょう。その結果を依頼先に返して、その履歴を保管してプロセスは終わります。これはあくまでサンプルですのでバリエーションはあると思いますが、基本的なパターンになります。

そして、それぞれのデータ確定においては、いくつかの情報を参照することがあります。見積作成の担当を決めるにも、今誰がどんな仕事を抱えていて空いているのかといったこと、工事仕様では過去の工事履歴も知りたいでしょうし、関係部署からのアドバイスも欲しくなります。

また、納期にしても外注業者の状況とか資材の在庫状況もあるかもしれません、そして、金額決定も原価計算結果や業務ルールも参照するでしょう。

そうした各アクティビティにおける関係性について書き出していきます。ここはケースでまちまちですからここまでにしておきます。

ここで気付かれたかと思いますが、依頼されたことを、だれが、どのように、いつまでに作業して答えるかというパターンになります。ただし、それがそのまますんなりと流れていくとは限りません。従って、作業指示を行なう前にレビューというアクティビティを入れています。すなわち、作業前の最終確認で、もしそこでNGなら差し戻すようにします。

一方、アクティビティの中味の方は、参照情報や連携がきまれば、それを情報共有型ウエブサイトに配置し、そこの中で設定された関係する情報を参照しながらデータ確定を行ないます。

この基本的なプロセスパターンを下図に示します。

さて、みなさん、このパターンで様々な業務を考えてみてください。実は、このプロセスは“顧客（従業員）サービスプロセス”と呼べるもので、従来の業務システムでは意外とカバーしきれていない部分です。ですから、以前にも言いましたが、BPMをいきなり基幹のところに持って行くのは抵抗があるかもしれませんが、こうしたところから始めるのがいいかもしれません。

また、ミクロワークフローの実現の場である情報共有サイトや情報参照などではウエブ系の技術が生かされるところでもあります。ここはそうクリティカルなところではありませんので、新技術の適用もやりやすいでしょう。

それでは、宿題です。似たような顧客サービスプロセスである修理サービスについてプロセスとデータ項目を設計してみてください。修理サービスというのは、それこそ修理対象は何でもよく、コピー機かもしれませんし、生産設備かもしれませんが、ここでは店舗の修理サービスを想定してみてください。

フランチャイズ店があってそこの店舗の修理依頼が管理会社に来て、それを施工会社へつなぎ、作業員が行って修理して、修理結果を報告するというプロセスを考えてください。パターンに従って自分で書いてみてください。すぐに描けると思いますがいかがでしょうか。
　

いま、こうして業務プロセスパターンの研究をしていますが、なぜパターン化するのか、パターン化すると何がいいのかといったことを提示しなくてはいけないと思っていたところに、Yuzoさんという方から下記のようなコメントをいただきました。

非常に本質的で、示唆的なご意見だったので、本文で紹介しつつそれに答える形で標題の疑問について考えてみたいと思います。コメントほんとうにありがとうございました。

私もビジネスプロセスを研究しております。

研究にいたった経緯は、企業の経営コンサルティングや事業再生に携わる中で、中長期で成果がでない企業や倒産してしまう企業を目の当たりにして、”なぜ短・中・長期で業績が改善しないのか”を自省も交えて悩んだ結果、ビジネスプロセスに行き着きました。

最近のある企業でCOOという役割を頂く機会があり、試しに商品設計・販促・契約・調達?サービス提供・アフターフォロー・クレーム対応までのビジネスプロセスをすべて1人で行ってみました。試しとは言っても、もちろん、仕入先やお客様も含めて本番です。

ここで、ビジネスプロセスの究極は、1人ですべてを行うことだということに気がついたのです。
逆に言えば、多くの企業は機能別組織で分業化され、階層化されて組織自体が肥大化していくうちに、セクショナリズムや職位やでき、現場（仕入先やお客様）から遠ざかっていることにより様々な問題が行っているということを体感しました。

早速、私は、お客様との面前での反応やお声を拾って、商品設計や仕入先にフィードバックしましたが、あっという間に売上が10倍になったり、提供までのリードタイムが3日→30分に飛躍的に短縮されたり、労働生産性が2倍以上になったりと効果が現れはじめました。

このビジネスプロセスを1人で行ったことの教訓として、

（1）プロセス（人の活動）は標準化すべきではなく、お客様に合わせて柔軟に対応できるように人の活動を見直す

（2）機能（営業部やマーケ部や購買部）でビジネスプロセスを細切れにするのではなく、お客様を基点に商品や地域といったプロセスで組織を再構築する
→こうすることで、営業・マーケ・購買が1つの部になり、その目標はお客様満足や売上として一本化されるため、今までのお客様ではなく各部の上司の顔色をうかがった活動が是正される

（3）経営層や中間管理職は、機能ごとではなく、プロセスごとに責任をもつ
→数字しかみない経営陣や中間管理職は、プロセスに責任をもつようになることで、自ずと現場検証や自分が旗を振ることになり、余剰人員や労働生産性を改善せざるをえなくなる

ほかにも気づきはありますが、このあたりで。

私自身は、上記の理由からビジネスプロセスをパターン化することに意味はないと考えております。
ビジネスプロセスはお客様の心変わりやシーンに合わせて柔軟にスピーディに良いものとして提供するものだと考えているからです。

パターン化してしまうと誰でもできるようになりますが、人は考えて行動する生き物ですから、パターン化せずに個性を活かす方向が自然ではないかと考えています。

では順番にみていきましょう。

「ビジネスプロセスの究極は、1人ですべてを行うことだということに気がついたのです。」

ということですが、ビジネスプロセスは人や組織に左右されるものではなく、あくまでその会社のビジネスにとって必要なプロセスはどうあるべきかを追求したものであるべきです。以前にも書いた作法でもスイムレーンは書かないほうがいいと言ったのはこのことです。

ですから、一人ですべてを行なうことというのは裏返して言うと、プロセスが人や組織を前提としないようになっているからこそ一人でできるとも言えます。しかも一人ですから一貫化されたものになります。

（1）プロセス（人の活動）は標準化すべきではなく、お客様に合わせて柔軟に対応できるように人の活動を見直す

これが、私が主張している2段ワークフローで言っているところです。すなわち、人間の活動を主体にしたプロセスをミクロワークフローとして、その上位階層のプロセスは、システム主体で動かせるマクロワークフローというふうにして分けて考えています。そして、標準化あるいはパターン化すべきと言っているのはシステム主体で構成できるマクロワークフローのレベルのことを指しています。

ご指摘のお客様に合わせて柔軟に対応できるようにするための仕組みはミクロワークフローのレベルのことで、ここは“ゆるく”作りますが、それでもどんな種類の情報をもとに人は活動するのかというようなことはある程度パターン化してもいいように考えています。

（2）機能（営業部やマーケ部や購買部）でビジネスプロセスを細切れにするのではなく、お客様を基点に商品や地域といったプロセスで組織を再構築する

これもその前のご指摘と似ていると思いますが、組織から独立したプロセスにするということと、それが途切れることなく一貫したものであることは大事です。おっしゃるとおりプロセスありきから組織を見ることが必要になると思います。

（3）経営層や中間管理職は、機能ごとではなく、プロセスごとに責任をもつ

この場合、機能の定義がありますが、組織という感じに受け取れますが、そうだとおっしゃるとおり、プロセスごとに責任を持つことが必要です。ただし、この場合でも、誰がどのレベルのプロセスに責任を持つかがあります。トップやミドルマネージメントが現場レベルの細かいところまでは責任をもてませんから、切り分けが要るように思います。

すなわち、ミクロワークフローである現場での単位意思決定（私はこれを機能と呼んでいます）のようなレベルは、現場のリーダが責任を持つものだと思います。

その単位意思決定の連なりとなるマクロワークフローである業務プロセスに対しては、事業部長などのような事業の責任者がその責任を負うというのが必要となります。（中小企業の経営者は別としてプロセスの責任者は経営者ではなく事業部長のような立場の人だと思います)

こうしてみていくと、業務プロセスの階層化という考え方やビジネスの競争力の源泉がプロセスのどこにあるのかといった議論になるかもしれません。

私の主張しているパターン化というのは、マクロワークフローレベルのプロセスパターンとミクロワークフローレベルの意思決定“支援機能”のパターンのことを言っています。ですから、パターン化すべきプロセスとそうでないところがあるということを言いたいのです。

繰り返しますが、お客様との接点のようにケースバイケースで不安定で非定型なプロセスまでパターン化しろということではなく、そこはむしろ“情報共有の場”を提供することで人の知恵や個性が生きるようにすることを提案しています。

最後に、なぜパターン化する（マクロワークフローレベルです）かですが、それがビジネスの競争力の源泉がプロセスにあるのかという提起につながります。言い換えれば、プロセスに差別化要因がなければパターン化してもかまわないとも言えます。

私は、このマクロワークフローレベルのプロセスにはそれがないように思うのです。ですから、工学的な扱いができると思っていて、工学的ということはモデル化できるということで、そのためにはパターン化するということです。

そうすれば、その部分では属人的にならず、人や組織が変わっても、同じようなプロセスを維持できるのでそのたびに変更するようなことをしないですむからです。

このことは、SCOR（Supply Chain Operation Reference model）のような標準化されたリファレンスモデルを見るとわかるかもしれません。

SCORでは、計画プロセス（PLAN）と4つの実行プロセス（SOURCE、MAKE、DELIVER、RETURN）を徐々に分解していきます。ところが、細かく分解していくとだんだ人間系になったり、分岐が増えたり、固有性が出てきます。ですから、SCR自体ではレベル３までが共通フレームワークとなっているわけです。

言い換えると、上位プロセスでは標準化ができているのです。ですから、どこのレベルまで標準化でき、どこのレベル以下は標準化できない（標準化しないほうがいい）かを吟味していく必要があります。私はSCORで言えば、レベル４までを標準化したらと言っています。

では、どこに差別化要因があるのでしょうか。もちろん最大のものは商品やサービスにあるのですが、業務プロセスのところで言えば、私はプロセスそのものではなくて、そのプロセスをオペレーションするところの優劣ではないかと思っています。

迅速で効率的な質の高い、そして顧客満足度を高められるオペレーションができるかどうかで差がつくように思うのです。そこでは、的確な業務ルールや判断基準、優れたリソース、有益な参考情報取得、さらに不断の改善努力などが相まって他社と違うビジネスオペレーションを実現し、それがビジネスに貢献していくのではないでしょうか。
　

マクロとミクロの2段ワークフローでプロセスを設計していくと、ミクロワークフローすなわち単位意思決定のアクティビティでは様々な情報を参照することになります。ある意思決定（データ確定）を行なうために、様々なデータベースを参照したりルールや基準に基づいたりといったことが起こります。

そのために必要な情報類を配置するわけですが、そういった情報にはどんなものがあるかを考えてみましょう。参照情報の種類を次の８つに分類してみました。

①業務ルール・判断基準
②マスタデータ
③履歴情報
④計画情報
⑤リソース状況
⑥外部環境情報
⑦シミュレーション・計算結果
⑧契約・規制

業務ルールや判断基準については、意思決定では不可欠の情報になります。この業務ルールや判断基準が競争優位の源泉だったりしますので、きちんとルールに従うということと、絶えず実績や環境変化に応じてブラッシュアップすることが大事になります。

マスタデータはいわゆるマスタで顧客、商品、取引先、従業員などのデータです。

履歴情報は文字通り過去に行なったプロセス実行の結果を参考にします。なんだかんだと言ってもあの時はどうだったかいう情報は貴重です。前例踏襲では進歩がないかも知れませんが困ったときは有効です。

計画情報というのは参照情報ではなく、プロセスに組み込まれるものだと言われるかもしれませんが、だいたいが実行プロセスに直結するような計画プロセスは少ないように思うのですがいかがでしょうか。それはそれとして、例えば予算なども計画情報と考えればよく参照することになります。

リソース状況というのは、ヒト・モノ・カネという保有資源が今どういう状況にあるかということで、マスタデータということでもあるのですが、もう少し現状で動いている状況も知りたいものです。例えば、担当者をアサインする場合、誰が今どんな仕事をしていて、あるいは予定が組まれているかだとか、設備の稼動状況なども重要な情報となります。

外部の動向といった情報も時として参照します。同業他社あるいは業界の動きなどやそれこそ為替レート、原油価格などといったものもあるかと思います。

意思決定する場合、単に今ある情報を参照するだけの場合もありますが、一旦計算してみてとか、シミュレーションをしてみてとかいったことも考えられます。与信チェックなんかもある意味シミュレーションのようなものでしょう。今風の言い方だと意思決定のためのサポートを外のサービスから得るということかもしれません。

最後の、契約や規制はコンプライアンス上必要ですから、いつでもチェックできるようにしておく必要があります。

その他にもあるかもしれませんがおおかたこんなところだと思います。これからの時代、どんどんデータは蓄積され、またクラウドでも膨大な情報が格納されて、いくらでも使えるようになっています。しかし、それを活用しきっているかというとまだぜんぜんできていないように思います。

そういうとすぐにデータウエアハウスを作ってBIツールでデータ解析しましょうというような話になるのですが、そのデータ活用をどんな場面で行なうかの議論ができていないように思います。単に個人の知的生産性の向上のためでは限界のような気がします。

そうではなくて、ビジネス実行の場面でより質の高い意思決定をするために活用することでデータの価値が生かされると思います。そのための第一歩として、業務プロセスと参照情報の関係をきちんと整理して、そこに有用なデータを配備することから始めることが重要であると考えています。