プロセスの設計作法
「Kailas」におけるプロセス設計の手順についてです。手順といっても詳細なものがあるわけではありません。できるだけシンプルなものにしたほうがいいと思っていて、どんなものに対しても大体同じであるという意味で“作法“と言ったほうが適切かもしれません。
なぜシンプルになるかというと、プロセスの構造がシンプルだからです。これまで議論したように、プロセスは性格が違うものを分けて考えることで2段プロセスになると提案しています。上位のプロセスは、依頼受付をして意思決定を連鎖させ、報告・登録をするというマクロフローとして定義しました。
下位のプロセスは、単位意志決定を起案-確認-確定-承認というミクロフローであるとして、それらは、人間系であいまいさを抱えているため、行ったり来たりしてもいいように情報共有の場で実行させることと規定しました。
この考えに基づいて、まずはマクロフローの設計をしてみましょう。プロセスを大きく捉えると、最初に何らかの依頼が来ます。これは外部からも内部からも、そしてシステム的にあるいはスケジュール的にやってくることもあります。しかし、いずれにしろ、プロセスの始点は「依頼受付」です。
そして、この「依頼項目」について答えていくことになるわけで、それが単位意志決定で、そのあとに作業があって、その結果を報告・登録するということになります。単位意志決定が中間点で、報告・登録が終点になります。
ですから、プロセス名を付けてそのプロセスの始点を決め、そこにある依頼者の特定と依頼項目(答えるべきデータ項目)を定義します。たとえば、見積依頼プロセスと命名し、依頼者名・所属・所在地、依頼日などと、堤供商品名、価格、納期などになります。
つぎに単位意志決定では、アクティビティ名を付けて、そこで確定するデータ項目を定義します。たとえば、納期確定というアクティビティであれば、納期になります。終点の報告・登録では依頼に対する答え、すなわちそこまでに確定したデータが定義されます。このデータのデータ型やデータ長などのバリデーションのための制約も定義しておきます。
これで、プロセスが書けることになりますが、もうひとつ大事な定義があります。それは参照情報の定義です。単位意志決定というアクティビティでは、何もなしに決めているわけではありません。必ずと言っていいほど何らかの情報を参照しながら意志決定を行っています。参照情報には、業務ルールであったり、各種のリソース状況、計画・履歴データ、シミュレーション結果、契約・規制値など様々な種類のものがあります。
単位意志決定の各局面でどんな情報を見ているのかを定義するわけです。そして、その実体がどこにあるのか、内部のデータベースなのかそれと外部からSaaSとして取得するものなのかといったことも定義しておきます。
マクロフローはもうこれで終わりです。簡単に言うと、プロセスの始点と終点を決め、中間の単位意志決定の確定データを特定し、それらに使う参照情報をリストアップするというだけです。
一方のミクロフローはどうでしょう。ここでは、ロールの設定を行います。ロールには、起案、確認、確定、承認を誰にやらせるのかということです。実はこれとてもマクロフローで設計してしまってもかまわないので、実質的にミクロフローで設計することはないとも言えます。
以上が、「Kailas」におけるプロセス設計のやりかたです。たったこれだけと思われるでしょうが、最低限のオペレーションはこれでできます。もちろん、ここから、各社の固有性を盛り込むのはいっこうにかまわないわけなのですが、大事なのは、基本部分と応用部分は分けて考えないといけないということなのです。
まずは基本を押さえて、それから応用問題に入り、さらに飾りや癖などを表現するということが非常に大切な作法になります。しつこいようですが、基本はマクロフローの定義です。“何を依頼されて、どう答えて何を報告するか”をきちんと書くことなのです。