January 2012 Archives

中庸」という言葉をご存知ですか。儒教の教書である「四書」うちのひとつにこの名前がある。意味は、偏ることなく、常に変わらないこと、過不足がなく調和がとれていることである。このことが大事であるということはどんな世界でも言えるのだが、ITのところで考えてみましょう。

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

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

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

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

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

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


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

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

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

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

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

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

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

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

アメリカなどではこうした調整とかすり合わせといったことはあまりやられていないので、業務の定型化ができパッケージが普及した。ただ、これからは調整のような文脈的なというかオントロジカルな行為が重要視されるだろうから、非定型業務をどうやってうまく実装して運用させるかは大きな課題になってきます。
 
前回は、非定型業務とはどんなものかを議論し、定型業務というのは、"確定したデータを処理する業務"のことであって、非定型業務というのは、"データを確定する業務"であると規定しました。今回は、定型業務と非定型業務の重要性についての比較をしてみましょう。

前回の定義でいくと、データを登録し処理する業務とそのデータを確定させる業務とどちらが大事なのかということである。もうちょっと具体的にみていきましょう。ビジネス活動というのは何度も書いていますが、お客さんに商材を知ってもらい、買ってもらうように働きかけて、注文をもらい、それに合致した製品なりサービスを作ったり、買ってきたり、組み立てたりしたものを届けて、その代金をもらうことです。

例えば、この買ってもらうように働きかけるというのはカタログを見てもらったり、見積もりを提示したり交渉して、最終的にオーダーをもらうことになります。この場合では、確定したデータを処理するというのは、作られた見積書を発行することや受注登録をすることに相当しそうですね。

一方、見積で提示する価格や納期を決めたり、受注に向けて見積もりを出し、値段交渉をしたり、特典をつけたりといったことをして受注に結びつけます。ここでは、データを確定するまでは行ったり来たりあるいはお客さんによってやることがまちまちといったようにいつも決まりきったやりかたではない非定型な業務になるわけです。

さて、どちらが重要かを考える場合、自分たちのビジネスに対する大げさに言えば戦略、簡単に言えば方針とかルールのようなものがどこに反映されているのかを見ていけばよさそうですね。ひとことで言えばビジネス要求がどこの局面で表現されるのかということになります。明らかに、データ確定するまでの動作にありそうですね。データを登録するところではビジネス要求が現れそうにありません。

例えば、見積金額をどうするかなんて戦略的、戦術的でもありますよね。今はまだ新製品が出たばかりだから、利益はあまり乗せないようにしようとか、この会社は優良顧客だし今後も期待できるので値引き幅を大きくしようなんていうのは、見積を作るまでのところでの判断に入り込んできます。

ということで、ビジネス要求は非定型業務に埋め込まれるということになります。だから、より重要なのは非定型業務なのです。つまり、非定型業務こそが競争力の源泉であり、差別化の源泉なのです。だからといって、定型業務が重要でないと言っているわけではなく、それはそれとして会社の実態、業績をきちんと報告、開示するという意味では重要なものです。ただ、これまでの業務システムは、非定型業務のIT化を避けていて、定型業務の方ばかりに目が行っていたように思うのです。
  
前回は、非定型業務がどこにあるのかということを議論しました。ビジネス活動とプロセス階層の交差点にあることを提示しました。今回は、定型と非定型の違いについて考えてみましょう。前回の議論の中でだいたいのイメージはわいたと思います。

先に定型の方をみていくと、どうもデータの登録・検索・出力をしているところとか、自動化ができている、そしてロジカルだからITにまかせられる、さらにシーケンシャルな処理、つまり逐次的に流れる処理のようだということが浮かんできます。

文字通り決まった形の処理やアクションですから、決まったロジックが書け、それをプログラミングして自動化することができるわけで、その行き着く先はパッケージであったりする。ところが、会社のビジネス活動はそれだけでは動きませんよね。すなわち、非定型的な処理や動作が必ずあるのです。

それでは非定型業務というのはいったいどんな業務なのだろうか。先ほどの定型の対立軸としてみていきましょう。まずは、データの登録・検索・出力というのが定型でしたから、その対立的なものは判断が伴う意思決定ではないかと思うのです。判断というのは様々な状況や条件の中でそのときの最善解(最適解は無理ですから)を出すということです。そうですよね、最善解といったとたん定型ではないことが分かると思います。

つぎに、自動化ということをみてみましょう。IT化イコール自動化であると考えられがちですが、自動化できるものは限られています。それを無理やり自動化したいがために分岐や差し戻しの嵐になってしまうこともあるように思います。自動化ということは人間の手から離れて機械にまかすことで人間が介在しない処理になるわけです。そうなると場合によっては何が起きているのか、どうやってこんな結果がでたのかわからなくなったりします。ですから、自動化すべき対象はよく選別する必要があります。

さて、ロジカルであればITで自動化できるのですが、それがどんどん進んでいくと前述したようにパッケージのような形に行きます。それは、仕事をパッケージに合わせてやりなさいということを意味します。ところが、現実には合わせられなくてカスタマイズやアドオンをしたわけです。それは、ロジックが違ったという面ももちろんあるでしょうが、定型化できない業務が多くあるということではないでしょうか。

実際に皆さんの職場でどうやって業務が遂行されるかをみてみればわかると思いますが、局面で多くの調整、相談やコミュニケーションを頻繁にしながら進めていっているでしょう。そして、それらは情報共有された場で行われていて、けっして決まりきった流れではないはずです。ワイワイガヤガヤやりながら、行ったり来たりして何かを判断し、決定しているはずです。ここが次回お話しますが、大変重要なのです。

さて、定型業務、非定型業務の違いがおわかりなったでしょうか。ぐだぐだ言いましたが、簡単にまとめて言いますと、定型業務というのは、"確定したデータを処理する業務"のことであって、非定型業務というのは、"データを確定する業務"であるということです。
  

昨年末にVCPC(バリューチェーンプロセス協議会)のセミナーで「非定型業務のIT化の事例と構築方法」というタイトルで1時間半もしゃべったので、この非定型業務のIT化ということについてシリーズで書いておこうと思う。

そもそも、非定型業務はIT化に適さないからということからこれまであまりやられていなかったと思う。しかしながら、よく眺めてみると非定型業務というのが非常に重要な位置を占めていることがわかる。その辺の話はおいおいするとして、まずは非定型業務とはいったい何なのかを考えてみましょう。

その前にちょっと角度を変えて、非定型業務ってどこにあるのかをみてみましょう。つまり、企業のビジネス活動においてどんなところに非定型業務があるのか、あるいは逆に定型業務はどんなところにあるのかということである。いつも決まりきったことをしているエリアとはどういった業務機能をもったところなのかということである。

企業活動モデルをシステム構造的にみると、水平方向にビジネス活動があるとすると垂直方向にプロセス階層があります。ビジネス活動というのは、お客さんからの要求があり、それに答えるためにプロセスを回し、その結果として事業成果が生まれるわけです。一方、垂直方向を見ると、上位には戦略や事業方針があり、その下に業務機能とかバリューチェーンのようなものがあり、更に下位に行くと業務プロセスに展開され、最後はITや人によるアクションといったレベルまで分解されます。

それらが、クロスする形で実際の企業活動が構造化され、実行されていきます。そのときに日常的な業務プロセスオペレーションを行う縦横が交差するところに非定型業務があります。

少し分かりにくいので、具体的に言うと、ビジネス活動としては前述したように、顧客からの要求とか依頼があって、それに答えるためにプロセス活動があります。それに答えるというのは、要求項目に対して製品やサービスの送り手側である意思決定を行うことになります。その意思決定の連鎖の結果としてデータが生成されて、それが成果となるわけです。成果は、決算システムにデータを登録することでPL/BSといったものとなり成果を表現することになります。

この流れの中で、定型的なものと非定型的なものを考えてみましょう。まずお客さんの要求はどうでしょうか。要求自体は定型のものとそうでないものがありそうですね。標準品のオーダーのように決まったフォームで依頼してくるものもありますし、特注品のようにいつも違った要求というのもあります。しかし、よくよく考えてみると提供側からすると要求のあいまいさは何らかの形で定型化しないと受けられないので結局処理としては定型業務になると思うのです。

また、後の方のデータ登録というアクションはもう定型ですよね。会計システムとかERPが口を開けて待っているところにデータを流し込むだけで、そのデータを使って所定のルールやロジックに従ってコンピューターが計算をし、決算書を出してくれるわけで典型的な定型業務になります。ということで、その間にあるプロセス活動が非定型になります。プロセス活動は意思決定の連鎖で、その意思決定は人間の判断業務が入りますからどうしても非定型になります。

一方、プロセス階層からみてみるとどうでしょうか。戦略とか事業方針、さらにその下の業務機能のようなレベルは定型なのか、非定型なのか。戦略とか事業方針そのものはもちろん各社、各事業でまちまちですが、決めるべきこと、書くべきこといったメタモデルはそう変わらないものです。ビジネスモデルの構造あるいはバリューチェーンとかハイレベルのプロセスといったものはどこも同じです。

例えば、サプライチェーンで言えば、計画・調達・製造・出荷なんてどこの会社にもあることですし、もう少し下のレベルでも見積作成、オーダ受領、在庫引当、輸送手配なんてプロセスも変わりありません。つまりそのあたりのレベルは定型的なものなのです。ですから、リファレンスモデル化ができるのです。世の中の標準モデルは定型的なレベルで行われています。

また、最下層のアクションレベルではITで言えば、データ処理みたいなことになるわけで、CRUDだとか検索、レポーティングといった機能は定型的なものです。人は担うところでも電話をするとか、ファイルするとか、運ぶとか、捨てるとか、そんな行為は定型業務になります。

ということで、その間の階層にある固有性をもった細かな業務プロセスが非定型なものになります。水平方向も垂直方向もこのように中間的な領域が交差したところに非定型業務は存在します。
  

About this Archive

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

December 2010 is the previous archive.

February 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