 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| 何を計測するのかが決まっていなければ、計測できない
|
まず、当然のことですが、何かを計測するときには、計測対象・指標とその基準が決まっていなければならず、且つそれらが客観性を持っている必要があります。
例えば、陸上競技の100m競争は、人間が100m移動する時間という指標を計測し、その指標が小さいことを基準として競います。誰が見ても一目瞭然です。そこで、100m競争の指標を100m移動した直後の心拍数というように変更すると、競うべき基準はその心拍数の高さということになります。この心拍数という指標とその心拍数が高いという基準は、誰が見ても100m競争にふさわしいという客観性はあるでしょうか？
ビジネス・プロセスの計測・評価も同様です。まず、第一に、計測すべき対象となるプロセスは、企業活動のどの部分なのか？そのプロセスはどのようなものなのか？を明確にしなければなりません。次にそのプロセスをどのような指標で、且つ、どのような基準を設けて計測するのかを明確にしなければなりません。
例えば、受注プロセスを対象とした場合、受注受付〜出荷指示までのリードタイムという指標や、受付作業品質としての手戻り回数という指標を計測すべきということを明確にします。
BSC（Balanced Score Card）では、この指標のことを業績評価指標：KPI（Key Performance Indicator）と呼びます。
KPIを洗い出しただけでは、この先が進めません。このKPIに対して、評価基準を明確にしなければなりません。受注受付〜出荷指示までのリードタイムは2±0.5日以内でなければならないとか、受付作業品質としての手戻り回数は3±1回以内でなければならない等、基準と許容値の設定が必要です。
また、これらKPIを分析するための様々な視点も事前に決めておく必要があります。受注受付〜出荷指示までのリードタイムについて、製品別に分析するのか？事業所別に分析するのか？顧客別に分析するのか？という具合に、分析の視点もあらかじめ取り決める必要があります。
更に、当然、この基準と許容値の設定には、現状がどのくらいで、目標としてどこを目指すかという定義に加え、どの地点を計測点にするかという定義も必要です。これらの作業は、図2に示すように、ビジネス・プロセスにセンサーを貼り付けて、どの測定点で何を計測するのかの取り決めを行うようなものです。
図2：ビジネス・プロセスにセンサーを貼り付ける
ここまでの一連の作業は、プロセス評価フェーズで行うことが一般的です。しかし、指標・基準の取り決めや、測定ポイントや測定点の決定は、プロセス・システム導入前のプロセス設計フェーズで行われることが、後のプロセス導入作業やプロセス評価作業のためには望ましいと考えられます。しかしながら、初めてのプロセス設計フェーズで、でき上がっていない業務プロセスやITシステムを思い描いて指標や基準を決定することは、多大な困難が伴うことが予想されます。
おそらく、プロセス設計フェーズで上記のようなシステム稼動後の指標や基準を決定できるスキル・経験は、少なくとも一度BPMライフサイクルを回さないと、なかなか身につかないと思われます。
これらの作業を経た後は、次は如何にしてその指標を収集するか？という検討を行う必要があります。
|
| KPIを収集するには
|
プロセスをKPIで評価するためには、KPIがどこに格納されているかを知り、KPIを収集する必要があります。KPIは、様々なITシステム内に蓄積されている場合もあれば、紙媒体に蓄積されている場合もあります。まずは、KPIとなりうる情報が既存の環境のどこにあるのかを調査する必要があります。例えば、次のように調査していきます。
- 受注情報であれば、ERPシステム内のどのテーブルに存在するのか？
- 出荷情報であれば、SCMシステム内のどのテーブルに存在するのか？
- 顧客問い合わせ情報であれば、CRMシステム内のどのテーブルに存在するのか？
- マーケティング資料は、どのExcelシートにあるのか？
- 株価情報は、どの株式レポートに記載されているのか？
ここで重要なことは、各情報が、いつ生み出され、更新され、消去されるのかという動的履歴情報を有しているか、いないか、ということです。動的履歴情報が記録されない状態であれば、当然プロセス評価はできません。従って、システムの改修なり、紙媒体情報の取り込みなどを行い、動的履歴情報を蓄積できる環境を構築する必要があります。
また、どのようなシステム・インターフェースを介して、それらの情報・データを抽出できるのかという調査も必要です。例えば下記のような具合で調査していくのです。
- DBに直接アクセスするのか？
- FTPやSOAPなどを利用して抽出するのか？
ここで、どの情報を、どのシステムから、どのようなインターフェースで抽出するかという調査は、プロセス評価のためだけでなく、前回ご紹介したプロセス導入フェーズでのWebサービスの規定作業にも大いに役立ちます。なぜなら、Webサービスを規定するWSDLの仕様は、情報を抽出するためのINPUT情報／OUTPUT情報はどのようなデータ定義なのか？そのインターフェースはなんなのか？を規定するものだからです。
最近では、ITシステムから情報・データを抽出するために、ETL（Extract/Transform/Load）を利用することが多く、効率的に作業が行われているかと思います。また、前述のSOA的なアプローチで開発されたシステムからは、Webサービスやエンタープライズ・サービスを介して、情報・データの抽出が可能になると思います。この技術は、動的情報を取り扱うプロセス評価だけではなく、静的情報を取り扱う従来の評価・分析の際のデータ収集作業を効率化すると考えられます。
ここで、エンタープライズ・サービス設計情報として規定されているWebサービスを呼び出す順番、つまり、BPELファイルで記述されるプロセスは、プロセス評価の際のKPI収集作業を更に効率化するものだと予想されます。
さて、計測すべきプロセス、計測すべきKPI、そしてKPIがどこに存在し、どうやって抽出するかという調査が終わり、データが収集された状態になると、いよいよプロセス評価が可能となるわけです。
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
IDSシェアー・ジャパン株式会社 渡邉 一弘
工場でのHDD製品設計を経験後、SEとしてシステム構築を担当。日々、現場の業務とシステム機能の「ギャップ解消」に悩み、業績に直結するシステムやROIを求める経営者に対し、解決策として見出したのが「プロセス管理」というキーワード。現在は、IDSシェアー・ジャパンにてプロセス管理ツール「ARIS」のプロセスコンサルタントとして従事。
|
|
|
|
|
|
