July 2012 Archives

それでは、サンプルをベースに実際に設計から実装までを行ってみます。サンプルとして、標準在庫品の見積依頼を受付けて見積書を提出するまでのプロセスを考えてみましょう。前回説明した設計作法に則ってやってみます。

作法その1 「プロセスの始点と終点を決め、プロセス名を付けます」
この場合は、顧客接点のプロセスになりますから、始点から先に決めて行きます。標準品ですから、要求がはっきりしていますので、要求を以来に変えるまでもなく「見積依頼受付」が始点で、「見積書提出」が終点となります。プロセス名は「標準品見積提示プロセス」でよいでしょう。

作法その2 「中間となるアクティビティは単位意思決定と作業が主なものになります」
お客さんが見積を依頼するとき何を教えてくれと言っているのでしょうか。言い換えれば、どんなことが記載されている見積書を出してくれと言っているのでしょうか。ここでは、あまり詳細にはしないで基本的な事項で考えて行きます。それはどんな商品をいつまでにいくらで売ってくれるのか、つまり商品仕様と納期、価格ということになります。

作法その3 「コンテを書いてプロセス概要表にまとめる」
ということで、見積を提示する業務のあらすじは、お客さんからの見積要求を受付け、最初の意思決定はお客さんの要求に合った商品名、型番、数量を確定することになります。次が納期と納入条件といったこと、そして売価ですね。それと確定されたデータを基にして見積書を作成される作業があります。作成された見積書が承認されるとお客さんに送付して、データベースに登録されます。これがコンテです。

次に「プロセス概要表」を作成することになります。それぞれのアクティビティでどんなデータを確定し、そこで使う業務ルール、参照情報は何かを書き出します。ここでは、簡単のために付帯情報やロール、メトリクスは外してごく基本的なことしか定義していません。それを書くと次のようになります。実際には多くの情報が定義されることになります。
 
   アクティビティ   確定データ・判断・作成文書        業務ルール       参照情報
見積依頼受付  案件No、案件名、依頼日、依頼者  
商品選択     商品名、型番、数量                           商品カタログ
納期確定     納入日、納入条件          
価格決定     見積価格                  見積価格決定ルール
見積書作成     見積書
見積書送付     送信日

これで設計が終わりになります。この情報を基にkintoneのフォームと一覧表の設定を行っていきます。
  
さて、これからは実際の設計と実装を行っていきますが、その前にキーポイントとなる業務プロセス設計ついてその作法をおさらいしてみましょう。おさらいというのはブログで何回か紹介していたので繰り返しになるからである。ただ、以前にエントリーしたものより、大幅に簡略化しています。超簡単に作ってしまおうと言っているのに多くの作法があるというのもおかしいわけで、たった3つの作法から成っています。

まずは、前提を確認しておきます。プロセス設計をするのに対象となるプロセスをどうやって特定するのかということがあります。最初から狙いが定まっている場合はよいのだが、そうでない場合、例えば戦略があってそれを実行するためのプロセスといった場合は、ひとつには、ビジネスモデルからプロセス分解していくやり方と参照モデルを使うやり方があります。ここでは、そうした絞り込みが済んでいるという前提にしておきます。

作法その1 「プロセスの始点と終点を決め、プロセス名を付けます」
・顧客接点のプロセスの場合は始点を先に、内部プロセスの場合は終点を先に決めます。
・始点は「依頼を受付ける」ところから始まります。通常「○○依頼受付」が最初のアクティビティとなります。5W1Hをベースに依頼内容を確定しておきます。
・終点は依頼に対して答えるためのアクティビティとなります。報告、提示、納入、情報提供、DB登録などが終点アクティビティとなります。
・プロセス名は終点のアクティビティ名をベースにした表現にします。ただし、○○管理プロセスのような表現は避け、業務活動を表す表現にします。 
・顧客の要求が不明確な場合は、要求の内容を聞き取り、要求内容を明確にし、要求形態を確定するプロセスを前に置いて、要求を依頼に変えてから「依頼受付」に行ってください。

作法その2 「中間となるアクティビティは単位意思決定と作業が主なものになります」
・単位意思決定とは①データを確定すること②判断を行うこと③文書などを完成させることです。
・単位意思決定では原則一つのデータ確定、判断、作成としますが、主データと付帯情報のような場合、意思決定するときの関係者や参照する情報がほぼ同じである場合、データ同士の相関性が強く同時に決めた方がよい場合は、複数のデータを同時に確定してもかまいません。                

作法その3 「コンテを書いてプロセス概要表にまとめる」
・コンテは、業務・仕事のあらすじを表現したもので、業務プロセスの構造で見てきたように要求(起)、依頼受付(承)、意思決定(転)、報告(結)で構成されています。
・映画の絵コンテと同じようにだいたいのストーリーとカット割がわかるものを作ります。紙と鉛筆かホワイトボードでアナログ的に書いた方がよいでしょう。
・プロセス概要表は各アクティビティで意思決定を行う(データ確定、判断、文書作成)ために使う業務ルールや参照情報、さらにロールやメトリクスを表に記入したものです。

たったこれだけで実装できます。え、うそでしょと言われそうですが、本当です。これならITを知らない人でもできますよね、というかむしろ業務側のユーザ自身しか設計できません。ITのところは汎用ソフト(この場合はkintone)にお任せして業務シナリオを書くことに専心しようということなのです。
   

前回、データベースソフトを使うが、データベースアプリケーションを作るわけではないとうこと、プロセスはマンガのようにストーリーがあるのでそれをそのままデータ登録画面に埋め込んだらどうだという話をした。今回は、kintoneを使って具体的にどう記述していくのかを見ていきます。

Kintoneもそうですが一般データベースソフトは基本的にデータ登録は1回で済ませるようになっています。入力するべきデータや情報を手元にもっていてそれを該当するフィールドに入力することをします。ですから、マンガではなくて絵とかイラストみたいなものと考えられます。ではそうした登録画面を使ってプロセスをどう表現したらよいのでしょうか。

簡単に言うと、マンガをそのまま書いてしまうことです。ただ、マンガと言っても4コママンガを章として連鎖させているようなものと理解して下さい。起承転結がはっきりしているものです。それを見やすいように章ごとに罫線を入れ、かつアクティビティの番号と名前を書きます。アクティビティというのは単位意思決定のことですから、その罫線で囲まれたところでどんな意思決定をするのかを明確にするわけです。

ですから、意思決定の数だけ章を配置します。罫線で囲まれたなかには前に書いたように確定データや判断などの登録フィールドとともに付帯情報や参照情報がすぐに見えるようにし、関係者とコミュンケーションができるようにしていきます。これだけで、データベースアプリケーションからプロセスアプリケーションへ変貌することになります。

BPMSならこんなことはすぐにできると思っている方も多いと思いますが、そうはうまくできてはいません。BPMSが登場したころにはもちろんできませんでした。プロセスエンジンでタスクの進捗を自動化するという意識が強かったので、そんな作りになっていました。ただ、最近では、プロセスを階層化できるようにもなり、掲示板のような機能も追加されてきてだいぶよくはなって来ていますが、まだまだコラボ―レーションによるデシジョンチェーンという概念とは違っています。

さて、こうして業務の物語を書いていくのですが、業務プロセスでは、最初はセリフや人物がまだ入ってはいないのです。背景や情況が描かれていて、そこに順番にセリフを入れていくイメージになります。「○○にしよう」とか「こっちがいい」あるいは会話が入ってくるわけです。さらに、物語がうまく進むように、またどう進んでいるのかがわかるような説明文を挿入することができるので誘導されて進行するのです。そのガイドは経験豊富なベテランの人に書いてもらえば、新人の人でもある程度はベテランの人に近い仕事ができるわけです。

Kintoneには「ラベル」とか「リッチエディター」といったパーツがありますので、そこに説明文やガイドを書き、外部の情報にリンクを貼るようにします。今のところ、Web化されたものでないとリンクされないので、普通のファイルを参照してというのができないので若干不便ではあります。例えばExcel表なんかならそれをWeb化して持つとかの工夫が要ります。

さて、kintoneで業務システムをどう実装したらいいのかの概要を説明しましたが、言葉での説明であることもあってイマイチ具体的なイメージがわかなかったかもしれないので、次回からは具体的なサンプル業務を使って、かつ実際にkintoneの画面を作りながら議論していこうと思います。
  

マクロプロセスの記述の話に入る前にしつこいようですが再確認です。標題にある「データベースソフトを使うのだがデータベースアプリケーションを作るのではない」ということを理解できないと意味がなくなりますので非常に大事なところですので繰り返して言っておきます。データベースアプリケーションというのは、基本はデータベースに格納するためのデータを登録するためのものです。

そして、記録されたデータを集計したり、計算、加工したりしてデータ保存状態にします。それは、レポートにしたり、分析したりするために扱いやすいように編集するわけです。そこから、必要なデータを検索して一覧で見えるようにしたり、帳票という形で出力するようになっています。

これはずっと昔から変わらない形です。古い汎用機の仕組みにしても現代のSalesforceの仕組みにしても、かたやグリーンディスプレーキャラクターが並んだものでもWebのかっこいい画面になっても基本的には同じです。画面設計をすると、登録・更新画面、検索画面、一覧表示画面、画面の承認などをすぐに考えますよね。

プロセス中心で業務システムを作ろうとするとき、こうした画面だけでプロセスを表現できるでしょうか。プロセスには、もちろん確定したデータを登録するあるいは判断結果を登録する機能は大事ですが、もっと重要なのはそうしたデータを確定するに至った過程、またどんな根拠で判断したのか、さらにそれらがどういった順番で行われたかがわかるようになっている必要があります。

すなわち、途中経過がシステム上で表現されなくてはいけません。これが業務オペレーションの場ということになります。オペレーションプラットフォーム上で様々なやりとり、そこには人と人というのもありますし、情報とのコンタクトというのもありますが、そうしたコラボレーション、コミュニケーションによって業務が完遂するわけです。

それを単に、データを登録し検索しレポ―ティングするだけではオペレーションプラットフォームとしては不十分であると言わざるをえません。ですから、従来型のデータベースソフトを使ってプロセスアプリケーションを作ろうとするとそれなりの工夫が要ることになります。

もちろんBPMSを使えばできますが、ここでは市販の安価な汎用データベースソフトを使おうというのですから知恵を絞らないといけません。最大の問題は、マクロプロセスの表現とどうオペレーションするのかということになります。ひとつには意思決定の連鎖を見渡すようにしなくてはいけません。また、例えば最初の意思決定をしたら次は何を決めなくてはいけないのかがわかるようになっているのかといった工夫である。

結局、少し飛躍した言い方になりますが、データ登録画面のなかにマンガを入れ込むことがポイントである。プロセスには起承転結があるし、マンガも起承転結で成り立っている。そのストーリーを全部埋め込んでしまえというのがここでの提案である。次回に具体的なやり方を見て行きます。
  

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

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

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

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

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

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

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

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

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

About this Archive

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

June 2012 is the previous archive.

August 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