May 2012 Archives

このブログで盛んに"プラットフォーム"という言葉を使っているのでちゃんと定義しておかなくてはいけない。プラットフォームというとeWordには「あるソフトウェアやハードウェアを動作させるために必要な、基盤となるハードウェアやOS、ミドルウェアなどのこと。また、それらの組み合わせや設定、環境などの総体を指すこともある。」と書いてある。

ただ、これだとコンピュータシステム的な表現であるので、業務システムを対象とするともうちょっと変えて、業務システム開発プラットフォームとか業務オペレーションプラットフォームといった何かの活動を行うための基盤といった趣で考えてみます。今世の中にあるプラットフォームらしきものではグループウエアや業務パッケージがオペレーション向けというと感じですが、他のおおかたは開発に向けてではないでしょうか。

少なくとも、できあいではなく業務システムを構築しようとするときにオペレーションを前面に出したソフトウエアってあるのだろうか。つまり、オペレーションの道具としてこんな機能が付けられるとか、画面レイアウトが作れるといった見方で設計していくようになっていないように思うのである。要するに、極論するとデータベースを作るために、データの登録画面と検索画面を作ることが実装だと思っている節がある。

悲しいかなほとんどがデータ登録フォームをつくれば、そこにデータを入力し、検索してレポートを出力することができるのでそれがオペレーションであると思っているのではないだろうか。しかし、データが確定してからあとはそうかもしれませんが、そのデータを確定しようとか、ある判断をするとかいったアクションは業務オペレーションとは違うということなのだろうか。

これまでの業務システムの最大の問題点は業務オペレーションという概念が乏しいことに尽きる。コンピュータが計算するためにコンピュータが要求しているところにデータを入れてやっているわけで、これではコンピュータのオペレーションのためのプラットフォームでしかないといえる。だから、これからプラットフォームは日々リアルタイムで業務オペレーションを行うためにどういったUIが必要で、どんな機能を持つべきかをちゃんと考えたものにしていかなくてはいけない。システムを作るためプラットフォームはもいい。

では、「kintone」は業務オペレーションのためのプラットフォームなっているかというと残念ながら基本的には従来型のWebデータベースである。オペレーションからの発想というより、開発からの発想である。だから、フォームの設計・配置とかいったことはいとも簡単にできる。またあとで詳しく説明していきますが、本当にぼくにでもできるくらい簡単です。

さて、その「kintone」をいかに業務オペレーションを見据えたプラットフォームに近づけるかがこの稿の最大のテーマになる。そんなことよりコードを書いた方が早いのではという人もいると思いますが、単に画面を作るだけではないわけで、セキュリティだとかパフォーマンスだとか、ユーザ管理など様々な機能が付帯されて初めて業務システムとして体をなすから、それらを全部作り込みますかという話である。

しかも、開発、テストといった工程もけっこうな工数を取られるわけで、それよりも多少機能不足のところがあってもいいとして、そこは手作業でカバーするといった対応がベストだと思うのである。さて、どうしたら既成のWebデータベースでオペレーションプラットフォームの要件を満たすことができるのだろうか。
これまで、プロセスの構造や機能をどんなもににするのか、それをどう設計するのかということを議論してきました。これからは設計されたプロセスをどうやって実装するのかという話になります。ここでもすごく重要なのはオペレーション発想です。オペレーションからの発想で構造を考え、それらがうまく機能するような設計をしたわけですが、それを実際に動かすプラットフォームに植えつけることをしていきます。

ここで、設計したものからプログラム仕様書に落としてコーディングするなんて考えないでくださいよ。もちろんそうやってもできますが、労多くして報い少なしです。設計のところでも見ていただけると分かると思いますが、特殊なこと、難しいことをやっているわけではありません。最初にオペレーション発想と言いましたのでもう一度「オペレーションとはいったい何をすることなのか?」をみていきましょう。何度もでてきたものです。

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

簡単に言えば、これが実現できる仕組みと仕掛けをもったプラットフォームを持ってくればいいのです。ところが、こうした条件をすべて満たしてくれるものはないのです。じゃあ、やはりコーディングするかとは考えないでくださいよ。既成のソフトウエアを使ってできるだけ近づけるようにすべきです。

個々にはありそうですよね。例えば、①のプロセス進捗だとガントチャートなんかかもしれません。②では、検索やポップアップとかハイパーリンクですかねえ。③では掲示板やコメント、メールですね。④はアクセス権とかワークフロー、⑤はアラート、⑥はBIのようなものかもしれません。ですから、既存のソフトウエアそのものあるいはその中のひとつの機能といったものにあるわけです。

ほとんどを持っているのがBPMS(Business Process Management Suite)です。ただ、それなりの価格ですので、コストパフォーマンスを考えたときに採用できる企業は限られてくるかもしれません。では、お金をあまりかけられない、あるいは効果がわからないのでスモールスタートしたいなんていう場合はどうしたらいいのでしょうか。

BPMS以外の安価な市販ソフトを利用することになります。場合によっては組み合わせて使うことをします。安価になるということは基本的には機能不足になるわけで、そこは人力で補足することになります。自分たちの身の丈にあったコストパフォーマンスを選択することを勧めます。

さて、具体的にどんなプラットフォームがあるのでしょうか。それを見るとき、プロセスの構造を思い出してください。2段プロセスです。プロセスの進捗をみるマクロフローと単位意思決定を行うミクロフローの組み合わせになります。簡単に言うとそれぞれを何でやるかになります。それらの組み合わせ例(マクロフロー+ミクロフロー)をご紹介します。

Case-A  BPMS(メインプロセス)+BPMS(サブプロセス)
Case-B  BPMS+コミュニケーションツール(CMS、wiki、BTSなど)
Case-C  手書きあるいは進捗管理ツール+Webデータベース(デヂエ、Salesforceなど)

Case-Bのコミュニケーションツールは例えばPlone とかMTといったCMSではWebサイトの編集作業をそこで行うが、リンク情報を参照したり、承認ワークフローがあり、コメントも書き込めるので意思決定の場として使えます。その決定結果をBPMSに渡し、BPMSでプロセスを進めるといった動きになります。

Case-Cはプロセスエンジンを持たないケースです。ですからそこは人間が回すことになります。こんなことを言うとプロセスエンジンを使って自動化しないと意味がないという指摘をされそうですが、プロセスエンジンの重要性はそれほどないというのが現実です。この話はまた別途します。意思決定というのは最終的には決定された情報を登録しまうから、データベースソフトを利用します。例えば、サイボウズデヂエ(最近はKintone)のようなものが使用可能です。

少し飛躍するかもしれませんが、ARISとSAPの組み合わせでプロセス管理をする事例がありますが、この考え方も基本的には同じです。つまり、ARISでプロセス記述をしておき、そこの進捗に従って、SAPの機能と連動させるものです。

さて。この次からは具体的な実装の話になるわけですが、上記のプラットフォームのうち、サイボウズ社が昨年からデヂエの後継として売り出しているクラウド型のWebデータベース「Kintone」を使った実装についてシリーズを改めてエントリーすることにします。
  
どうやって実装するかの前に「ITを考えないで業務オペレーションを描いてみる」ことをしてみましょう。このエントリーのタイトルが「非定型業務のIT化」ですからそれを否定するような言い方で矛盾していると指摘されそうですが、単にIT化するのが目的でなくて、言外にビジネスの役に立つためのITという意味が含まれています。

つまり、ビジネスに貢献できないようなITなら入れない方がよいということです。ですから、大事なことは最初からIT化ありきではなく、ITを考えない中でその業務システムをオペレーションできるか、どんなオペレーションになるのかをみておくことも必要ではないかということです。

さて思い出してほしいのですが、業務プロセス設計でどんなことを決めたでしょうか。まずはプロセスフローを決めることをしました。そしてプロセスフローとは、アクティビティ(意思決定項目)の選定と順番というふうにしました。このことはオペレーションという観点では何を意味しているかというと、意思決定の進捗を管理することになります。

プロセスフローが決まると、確定情報、参照情報、適用業務ルール、ロール、制御変数などのアクティビティの属性を決めていきます。つまり、意思決定というのは結果としてある情報を確定することなので、その決定すべき情報とそのためにどんな参考情報やルールをみるのか、だれが決定・承認するのか、何をコントロール・監視するのかを決めることになります。

これも、オペレーション的には、迅速で質の高い意思決定を行えるように多くの有用情報を素早く取り出せ、知恵を持った人たちの助言を受けたり、上司と相談でき、また制約やコンプライアンスのチェックがなされる環境があることでしょう。こうしたことはパフォーマンスという面を考慮しなければITがあろうとなかろうと関係ない行動です。

そうなんですよね、ITがなければこうした行動、活動ができないのではなく、ITはあくまで早く、速く、多く、強く、高くなど"形容詞的"効果をもたらすものなのです。主語・述語・目的語、そして名詞・動詞はITには無関係です。では、プロセス設計されたものをITなしでのオペレーションをした場合を考えてみましょう。すなわち、コンピュータがない時代の業務です。

プロセスフローというと箱を矢印で結んで書かないといけないように思えますが、昔は"仕事の段取り"だとか、"工程表"などを紙に書いたり、黒板に書いたり、またカレンダーにマグネットを置いて管理したりしていました。有用情報は紙でキャビネットにあるバインダーに綴じられているものがほとんどです。そのページを指でめくって探したものです。他にも新聞の切り抜きをスクラップブックに貼ったりしました。マイクロフィルムというもありましたね。

コラボレーションというのも、隣のひととメール交換する現代よりもっとまともなコミュニケーションをしていたような気がします。何かあると皆が机の回りに集まって来てなんだかんだと議論しましたし、電話やFAXでやりとりもよく行われました。もちろん、契約書だってありますからちゃんとチェックしていました。期日管理なんていうのも大きな張り紙があったりしました。

こうしてみると、やっていることはいつの時代でも同じだったのです。しかし、それが効率的であるのか、迅速性がないのか、狭量的になっていないのかといった問題を抱えていたわけです。もっと早くやりたい、もっと多くのことを知りたい、もっと高度にしたいといった欲求不満を解消してあげる必要が生じたのです。

例えば、プロセス管理をホワイトボードでやると何が問題なのかというと、ホワイトボードに書ける情報量が少ないこと、書いてあることを手元で見られないあるいは遠隔地と共有化できないといった問題が出てきます。同じように、いつも紙をキャビネットから取り出してめくるのは嫌だなとか、書き写す手間が大変だなとか、情報を得るのに役所や図書館までいかなくてはとなるのです。

さて、もうおわかりかと思いますが、そういった欲求を満たしてあげるものとしてITが存在しています。この領分ではコンピュータが登場してからずいぶんと大きな貢献をしていると思います。取得する情報の量と速さはとてつもなく多くそして速くなっています。ただ、だからといってやみくもにITを導入すればいいというのではなく、身の丈にあった導入をはかるべきだと言っています。

ITがなくてもやってきたわけですから、それほど多くの情報量が必要でない会社、簡単なプロセスしかない会社は無理にIT化しなくても人間が介在することでも十分できるならそれでもよいと思う。つまり、人間とITがうまく役割分担して、ベターな仕組みを作ればよいのです。こうして考えると、業務システムをプログラミングして自動化を図るというアプローチが何だかおかしく思えてきませんか。
  

About this Archive

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

April 2012 is the previous archive.

June 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