September 2014 Archives

さて、7つの作法の最後になります「実装する」です。最終的にはITに実装して、それを使って日々オペレーションしていくことが大事になります。前回作成した「プロセス要素表」から実装していきます。こういうと、要件定義をしてプログラム仕様書を書いてそれから実装するのでしょう、あるいはパッケージを持ってきてFitGapをやるのでしょうと言われる。

ここでは、そんなことはしません。まず対象が"意思決定プロセス"であることがあります。また、プロセス要素表を見てもらうとわかるようにプログラムできっちりと作れるような定型的なものではないということです。つまり、非定型で人間が介在するような仕組みでプロセス要素表にある各要素が仕込めるプラットフォームがあればそこに"設定"すればよいのです。

プラットフォームは基本的にデータ管理とプロセス管理そしてコミュニケーションができるものであればいいのです。そういったものにBPMSがありますが、意外と定型業務向きなので、ここではサイボウズ社の「kintone」を採用することにします。kintoneの謳い文句である"データとプロセスとコミュニュケーションを一体化させた"というのがコンセプトですからぴったりですね。多少使い方の工夫が要りますが十分使えるツールと言えます。
   
kintoneを使った実装の手順は本ブログの「ビジネスサービスのつくり方」という記事に詳しく出ていますのでそちらの方を参照してください。ざっとした手順だけは記しておきます。

1. Portalからアプリケーション作成方法を選択します。


portal.JPGのサムネール画像

2.はじめから作成の場合
  ステップ1  アプロの名前を入力します
  ステップ2  一般設定(アイコンやデザインテーマなど)
  ステップ3  フォームの設定(データの入力フォームを作る)
  ステップ4  一覧の追加(データの一覧画面に表示する項目を選ぶ)
  アプリの運用を開始するために「設定完了」をクリックする。


フォーム設定.JPGのサムネール画像


このように、設定だけでアプリケーションを組むことができます。フォームの設定でも、あらかじめ用意されたフィールドパーツ(ラベル、文字列、数値、日付、ラジオボタン、チェックボックス、ドロップダウンなど)をドラッグ&ペーストで貼り付けるだけです。その他にも、通知の設定やアクセス権の設定、グラフ化なども簡単にできます。最近ではAPI連携とかJavaScript/CSSカスタマイズもできるようになりかなり機能が充実してきています。ということで、7つの作法を終わることにします。
  

前回からの続きで「プロセス要素表を作成する」です。プロセスオペレーションプラットフォームの要件となぜそうした要件になったかをサイモンの意思決定プロセスで説明しました。ここでは、具体的にプロセス要素表とはどんなものか、どうやって書いていったらいいのかを見ていきます。このテーマのタイトルが「イノベーションを支援する」ですからそういった目的に合っているかどうか考えてみてください。

まずは、プロセス要素表を示しておきましょう。

ProcessElment.jpg
表の一番左のアクティビティの列には意思決定プロセスの基本の項目が入ってきます。そして、次の「確定データ・判断」では、意思決定とはデータを確定することとある判断をおこなうことだと定義してありますからその要素を入れます。「依頼受付」「要求仕様確定」「作業」「報告・登録」も一種の意思決定ですから同じように記します。例えば、依頼受付だと依頼内容とか依頼受付日といったものが確定データになります。

「付帯登録情報」は必須情報ではないが参考のためとか、付記したほうがわかりやすいといった情報になります。例えば、住所に対する地図だとか納期に納入条件を入れるとかいったことです。「業務ルール」は意思決定を行うための則るもので、その中には概念ルール、数値ルール、アクションルールなどがあります。非常に重要なものでサイモンの意思決定プロセスでも代替案の選択の基準もこのルールになります。

ルールは単純なものから、ある条件を入れてデシジョンテーブルを通して答えを返してもらうなんていうものもあります。BPMとBRMが連携するというのはこういうケースのことです。参照情報は意思決定するときは何らかの情報を参照しながら行うのが普通です。できるだけ有用な多くの情報に基づくほうがより正しい意思決定が行われるはずです。参照情報には、マスタとか履歴といった事実情報、リソース状況、シミュレション結果などの判断情報、契約とか規約などの成約情報があります。業務ルールも判断情報のひとつですが重要であるので独立した要素として抜き出しています。

「ロール」は起案、チェック、承認などを規定しておくところです。プロセス全体もさることながら、単位意思決定でも責任者を決めておくべきでしょう。パフォーマンス指標は、コントロールすべき対象と閾値を書きます。例えば、報告日の3日前に作業が終わっていなかったら担当者にアラートを出すとかいったことになります。最後のデータ連携は取り込みデータ、提供データ、連携システムとの関係などを記入します。

もちろんこの表を全部埋める必要はありません。最初に設計すると大抵は書くセルが少ないでしょうが、大事なのはオペレーションを重ねていきながら増や
していくことなのです。例えば、最初は業務ルールもちゃんとしていなくてもまずは慣例でもいから運用してみて、やっていくうちにルール化されたら、それを業務ルールとして記述していく。他の項目についても絶えずブラッシュアップしていいものに近づけることが非常に重要なのです。

意思決定プロセスのシステム化の最も重要な過程はここの「プロセス要素表」の記述です。この表が適切に書けること、すなわちこのレベルのプロセス設計ができれば実装に移ることができます。
 

今回は(8)の「プロセス要素表を作成する」になります。実装に近いプロセス設計です。前回、プロセスを構成するアクティビティのモデルは「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」というふうに定義しました。ここでは、作業プロセスがない単純な意思決定プロセスを例にとって見ていきます。

プロセスを設計するときに大事なことは、オペレーションから発想することです。どういうオペレーションをすれば戦略の実行が可能か、ひいてはビジネスに貢献できるのかという観点です。これがちょっと大げさなら、こんなことができれば自信をもってマネジメントができるというものは何かということです。

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

こうした要件を導き出した背景には、ハーバート・サイモンの「意思決定論」があります。少々長くなるが引用します。

■限定合理性と満足化原理に基づく意思決定
人間が完全に合理的な存在であるなら、あらゆる代替案のなかから、一定の評価基準に照らして最も有利な選択を行うという最適化原理に基づく意思決定ができる。しかし、合理性に限界(限定合理性)があるゆえに、人間は満足化原理に基づく意思決定をせざるを得ない

■意思決定プロセス
情報活動(情報収集 )➝設計活動(代替案の探索・評価 )➝選択活動(代替案の選択)➝ 検討活動(代替案の実施 ・フィードバック)

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

簡単に言うと意思決定を自動化してロジカルに意思決定できないので、意思決定プロセスを通じてより合理的な決定をくだすしかない。また、ひとりで全部意思決定できなから組織を作って分担させなくてはいけないということです。プロセス構成要素の各アクティビティは広義の意味で単位意思決定ですから、サイモンの理論を適用することができます。

オペレーションプラットフォームの要件がこの考え方に沿っていることがお分かりになったでしょうか。次回に具体的な「プロセス要素表」の要素と書き方を説明します。