さて、いちおう第1章の「心構えと下準備」から第6章の「業務適用」まで(本は第5章が「プロモーションと運用」なっていますが、業務アプリなので、「アプリ作成」と「業務適用」に分けました)を書いてきましたが、書いているうちに補足したほうがよいものが出てきましたのでそれを付記しておきます。

ここで取り上げた事例である「標準品見積提示プロセス」では、プロセスがすんなりと一本になっていますが、現実にそういうものばかりでしょうか。また、作業アクティビティが見積書作成といった簡単な作業だけなのだろうかという疑問を持たれたかもしれません。そう単純にはいかないようですね。そこで、ここから「ケース分割」と「タスク分解」という考え方を採り入れることにします。

まずはケース分割という考え方です。プロセスはアクティビティが順番に並んだものですが、全部が独立してあるとは限りません。前のアクティビティの結果に影響される、あるいは前の結果が決まらないと次のアクティビティの内容が定まらないといったことがあります。そうした場合にアクティビティの確定データが複数になたったときにケース分割ということをします。たとえば、営業プロモーションでキャンペーンの方法を選定するというアクティビティで展示会への出展とWebサイトを活用というのが選ばれたようなケースです。この2つの方法では、後のアクティビティが違ったものになります。 

これは分岐ですねと言われそうですが、分岐とはちょっと違います。分岐はorが主ですがあくまでand回路だからです。そのとき同じプロセスで扱うと複雑になり混乱してしまいますから、ケースを分けてプロセス化したほうがよいと思います。まあ兄弟プロセスを作るというイメージですね。この検討は、プロセス要素表を書く前に、「業務コンテ作成」というステップを入れてそこでやることにします。コンテというのは、どんな依頼があって、確定すべきことや判断すべきことだけを並べて見ることで、その時複数になったら、別の名のプロセスにするということです。

次に、作業アクティビティをどう扱うかという問題です。何が問題かというと、作業を外側においてしまって(ブラックボックス化)いいのだろうかということです。簡単な作業、例えば書類を作成 するなんてはそれでいいかもしれませんが、この例のように複数の人間が多くの作業を協働するなんていう場合は、ちゃんと見えるようにしておいたほうがいいと思うからです。そこで「タスク分解」という考え方をとって、別にタスク管理アプリを作成(kintone で作成できます)して連携するのがよいでしょう。作業依頼をして作業結果を返してもらう感じです。

これもサブプロセスを作ればいいのではと言われそうですが、この場合はプロセス的な部分が薄いタスク管理なのでサブプロセスとは呼ばないようにしています。では、サブプロセスとはどういうものなんのでしょうか。メインプロセスがあってそこから従属的なプロセスへ落とし込むも親子関係になるわけですが、この方法論だとあまりないように思います。むしろ、サービス要求を別のプロセスへ投げることと考えられるので入れ子構造のプロセス間連携というふうに捉えています。

いずれにしろ、きっちりとしたフォームに嵌めこまなくてはいけないということではありません。意思決定の項目と順番を決め、各意思決定を素早く正しく行うために必要な要素を定義し、必要とあらば他プロセスやタスク管理、データベースなどと連携する仕組みと仕掛けができれば、組織目的を達成する業務オペレーションがやりやすくなるのではないでしょうか。(完)
  




No TrackBacks

TrackBack URL: http://blog.wadit.jp/mt/mt-tb.cgi/111

Leave a comment