June 2012 Archives

前回、業務オペレーションのために必要な6つの要件の提示しましたが、さらに、抽象化してみると次の3つの機能に集約されます。

1.プロセス進捗ビュー
2.意思決定の場
2.アーカイブ

プロセスがどう進捗しているのか、いまどこのアクティビティがオンになっているのかが一覧で見えること、業務ルールや有用な参考情報を参照でき、承認者も含めた関係者のコミュニケーションを通してパフォーマンスを守った意思決定する場が用意されていること、そして、プロセス実行の結果が記録として残ることである。

さて、ここで「kintone」の持つ機能についてみていきましょう。ただし、機能というと開発のための機能ということを思い浮かべますが、ここではあくまでオペレーションのための機能という観点でながめていきます。詳しくはHPを参照してください。また無料お試し版もありますからそちらも試してみてはいかがでしょうか。

「kitone」のオペレーションする時に見る画面は大きく二つあります。ポータルの画面からアプリを選択すると最初に一覧表が出てきます。設定されたフィールドにレコードが並んだ表が案件ごとに表示されます。一覧表は様々な切り口で複数作ることができます。表面上はExcelの表と同じようになります。

そして、個別の案件をクリックすると、データ登録画面がでてきて入力されたデータが表示されます。要するに、データ登録フォームにあるフィールドにデータを入力すると、その結果が一覧表として表示されるというものです。その他にはレポート集計などもありますが、基本はいま言ったように一覧表とデータ登録の二つの画面になります。これは、どこのデータベースもほぼ同じです。

つまり、データを登録してそれらを見やすいように一覧にして管理するといういわば台帳システムがこれまでの業務システムの体裁だったのです。昔の大福帳からずっとその考え方が踏襲されてきているように思います。そこにプロセスの進捗がわかるような工夫を施すところがポイントです。

この機能を使って先に言った要件を満たすようにしていくわけです。さあどうしましょう。まずは、「プロセス進捗ビュー」はどうしたらよいのでしょうか。これは簡単に言えば、一覧表で各アクティビティでのステータスが表示できていればよさそうです。つまり、アクティビティ(1)は、完了したから"完了"というステータスがアクティビティ(1)というフィールドに表示されていればいいわけです。その次のアクティビティ(2)は"待機中"とか"仕掛中"とかの表示になっていて、そのステータスが変化してことになります。

本当は、これが色変わりするといいのですが残念ながらいまの「kintone」ではできませんので、言葉で判断します。こうしたプロセス進捗管理は案件ごとにステータスを表示するというやり方は多く見られますが、アクティビティのフローに対応したものはBPMS以外ではあまりみかけません。しかし、こうして俯瞰して流れを追えることは上位管理者にとっては、どこで滞留しているのかとか期日に間に合うのかといった監視ができるので助かるのではないでしょうか。

次回は、ではいったい複数のアクティビティのフローから成っているプロセスをどうやってオペレーションしていくのか、すなわち意思決定の場の使い方について考えていきます。

ついでにもう少しプロセス管理に必要な機能について考えてみます。なかなか「kintone」が出てきませんがしばらくご容赦ください。前回、プロセス管理ツールとしてのBPMSが保有する機能としてモデラー、プロセスエンジン、モニタリング、ワークフロー、シミュレーション、ルールエンジンといったものを挙げました。そして、プロセスエンジンについて必ずしも必須ではないと言った。自動化するためのエンジンはそれほど重要ではないということである。

他の機能はどうだろうか。モデラーとシミュレーションというのはセットで考えてもいいので両方を見てみるが、これらの役目は、プロセスをモデリングして、それに対してシミュレーションを行ない、最適なプロセスに改善していくというものである。そして、そこで作られたプロセスモデルを実際に動く環境にデプロイしさらに詳細設定をするわけです。

まず、プロセスモデラーというのは今言ったように簡単にいうとお絵かきツールです。ただ、シミュレーションができ、開発環境に移行できることがメリットとなります。このメリットは大きいのでしょうか。もし、これがなかったらどうするかを考えるとその必要性がわかってきます。モデラーは手書きで書いてみることになり、実際に使うプロセスは直接開発環境で作ることになるのと、シミュレーションはやらないというか、ちょっとしたケーススタディ程度になります。

シミュレーションをすると何となく最適化ができるように思いますが本当でしょうか。例えば、分岐があってその分岐でどちらに振り分けられるかという条件が決めらますが、そのパラメータはほとんど人間が恣意的に決めるわけです。それが正しく現実を反映しているとはならないから、最適化はしょせん無理な話なのはないだろうか。ということで、モデラーもシミュレーション機能も必須ではないと思うのである。

さて、残りのワークフロー、モニタリング、ルールエンジンであるが、ワークフローは申請―承認という機能は必須ですが、最低承認者の権限を付与してその人が承認するという機能で十分ではないかと思う。ルールエンジンは、別にBRM(Business Rule Management) というジャンルがあるくらいだから必須のように思いたくなるが、それは一部の複雑系のプロセスには必要かもしれないが、それほど複雑ではないところにエンジン付きでデシジョンテーブルを回すほどのことは少ないと思うのです。ルール集を参照する程度でおおかたの役目をはたせるのはないでしょうか。

モニタリングは、必須である。ここでよく考えなくてはいけないのは、何を監視するのかという前に、何のために監視するのかということです。つまり、どんなことをしたいがために何をどう監視するのかということが重要になってきます。ダッシュボードなんて言い方があるようにモニタリングというとBI(Business Intelligence)みたいなことを思い浮かべるひとが多いかもしれませんが、それは一部の話で、モニタリングには2通りのものがあると考えています。

プロセス管理の結果をモニタリングするのとその途中をモニタリングするこの二つです。つまり、最初に設定したKPIとかKGIが達成できたかどうかを測ることと、それらを達成するために制御しなくてはいけないパフォーマンスを測ることです。意外と忘れがちなのが後者のモニタリングです。むしろ、こちらの方が大事というかプロセス管理の狙いはここにあります。前者が死体解剖で後者が生体ドッグというわけで、死んでからその死因の探るのももちろん必要ですが、病気になる前に兆候を見つけて処置することの方が大事だと思いませんか。

結局、プロセス管理に必須の機能は何かというと、データベース、ビュアー、承認、パフォーマンスモニタリングといったぐらいで、これではちょっと味気ないので、もう少しメタレベルでみてみると、前のシリーズでも何度も出てきた業務オペレーションのため要件に集約されるのである。

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

次回から、この要件を満たすために「kintone」どうやって使っていくかの話に入ります。
  
さて、前回「Kintone」はそもそもWebデータベースなのでオペレーションプラットフォームとしては十分ではないようなニュアンスを書いた。それに加えてもうひとつ問題がある。それは、オペレーションはプロセスが対象だからそこでオペレーションができなくてはいけない。そのとき、プロセスの進捗をどうやるのかの問題である。

プロセス管理というと世の中にはBPMS(Business Process Management Suite)というのがある。これらの主な保有機能は、モデラー、プロセスエンジン、モニタリング、ワークフロー、シミュレーションといったものだが、主要なものとしてプロセス実行エンジンがある。これは、あるアクティビティが終わると(実際にはデータを投入すると)自動的に次のアクティビティがオンになり、それを繰り返すというものである。

つまりエンジンの主たる機能は自動化なのである。設計した業務フローの順番通りに自動的に進めてくれるのがプロセスエンジンということになる。BPMを実行するすなわちプロセスを動かすためには、エンジンが必須なような気がしますがどうでしょうか。プロセスを実行するのにアクティビティを進めることは必須だが、自動的にITにまかすことは必須でもないのでる。

ここを、皆さん勘違いというか思い込みがあるように感じる。このことは何もBPMに限ったことではなく、それ以外のITシステムンも言えることで、IT化イコール自動化というのは必ずしも正しくない。自動化しなくてもよい、あるいは自動化したくない部分は人間が手動でやってもいいのである。その方がかえってわかりやすく、効率的だったりすることもある。

例えば、固定的でない業務、つまり毎回やり方が微妙に変わるとかケースバイケースの処理といったものは、フローを事前に確定するのが難しい。それを無理やり固定しようとすると分岐と差し戻しの嵐になって、それでも対応できないものが出たりする。どこまで想定しきれるかがプロセス設計のキーになるなんておかしいでしょ。

このシリーズでは非定型業務のIT化というのが主題であるが、非定型業務というのは今言ったように固定化できない業務だからプロセスの自動化処理というのがなじまないということがおわかりになったでしょうか。そうなると、プロセスエンジンを持たないITツールを使ってもかまわないということが言えます。

BPMSがなかなか認知されない理由の一つにプロセスオートメーションを前面に出し過ぎていることもあるのではないだろうか。要するに、プロセスエンジンを使って自動的にシステム進行を行うには定型的な業務が合っているが、定型化できるのであれば、エンジンを使わなくて直接プログラミングしてしまえば(パッケージ化してしまえば)いいわけで、そこの矛盾を解いていないのである。

つまり、言い方を逆にすると非定型業務こそプロセス管理に対象とすべきで、そのプロセスは自動化できないあいあまいさを内包しているから自動化が難しいので、そこは人間が介在してプロセスを進めていくやり方が最も効果的ではないのかということである。従って、プロセスエンジンを持たない「kintone」でプロセス管理を行うことを提案しているのである。

About this Archive

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

May 2012 is the previous archive.

July 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