前回は「プロセス進捗ビュー」を一覧表の機能で、そこのフィールドにステータスを表示させることで実現させました。今回は、意思決定の場をどうするかになります。また何度も出てくる話ですが、意思決定を行うプロセスは、情報活動―設計活動―選択活動というサイモンの意思決定プロセスが基本です。

すなわち、意思決定するのに必要情報を収集し、いくつかの案を考え、評価し、その中から現実解を選択します。あくまで"現実解"であり、"最適解"ではありません。サイモンも人間の合理性に限界(限定合理性)があるので一定の評価基準に照らして最も有利な選択を行うという最適化原理に基づく(できるだけ最適に近づける)意思決定にならざるを得ないと言っています。

ついでにサイモンの限定合理性の話をすると、人間はこの限定合理性ゆえに大きな問題に一挙に対処することはできず、複雑な問題の解決にあたる場合、問題を分解して組織の目的の階層化を行うといっています。その組織目的の階層化に併せて組織の意思決定も階層化して、人間の合理性の限界を克服しつつ、組織目的の合理的達成を追求するわけです。

つまり、トップマネジメントの意思決定のレベルとミドルマネジメント、現場担当者の意思決定のレベルは当然違っていて、プロセス的に言うと抽象度の高いハイレベルなプロセスの意思決定はトップがやるし、現場のタスクレベルの単位意思決定は担当者がやるというふうになります。

よく日本の企業は、トップが細かいことまで口を出すとか、現場が強すぎて本来部長がやるべきことを係長がやっているとか揶揄されることがある。これは、組織目的と意思決定の階層化がちゃんとできていないことに起因しているのだが、もっと言うと業務プロセスの階層化ができていないことに帰結する。

ちょっと話がそれてしまったが、意思決定プロセスは現実的には一回で終わることは少なくいくつかの意思決定が連鎖しているのが実際です。つまり、大きな意思決定の流れ(マクロプロセス)とそのなかのアクティビティのひとつずつが小さな意思決定プロセス(ミクロプロセス)となっているわけです。前回はマクロプロセスを一覧表で閲覧する話をしました。

ここでは、ミクロプロセスである単位意思決定をkintoneのデータ登録フォームで行うことを見ていきます。意思決定する場とは、何回も言っていますが、業務ルールや参考となる情報を参照でき、承認者も含めた関係者のコミュニケーションを通してパフォーマンスを守ったオペレーションができることが重要です。先述したように最適解に近づけるために、どれだけ適正なルールや有用な情報を参照できるか、どれだけ有効な知恵を獲得できるかが大事なのです。

意思決定した結果はデータ登録という形でそのフィールドが作られます。登録されるのは、数値データだけとは限りません。判断結果と作成文書などもそれに該当します。可否、要否、有無などの結果はラジオボタンが使われることが多く、作成文書はラベルに張り付けたりリンクといった方法や参照設定で登録されます。

また、業務ルールや参考とする情報の参照はkintoneではラベルかリッチエディターのリンクで引っ張ってくるか、もし同じkintoneのライブラリーにあるものであれば、ルックアップされます。コミュニケーションについては、kintoneでは、登録フォームの右横にコメントを書き込む欄があるのでそこで関係者間の意見交換を行うことができます。とういうことで何とか意思決定の場で必要な機能は装備できます。詳しい設定の仕方などは、設計・実装方法で説明します。さて次回は、マクロプロセスの記述をどうするかを議論します。
  

No TrackBacks

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

Leave a comment