ビジネス課題への解決策(アイディア)と、新たな発想(+α)が見つかるIT情報メディア

Menu
  1. TOP
  2. BPM
  3. モデリング講座4 “概要業務ヒアリングのコツ”
BPM

モデリング講座4 “概要業務ヒアリングのコツ”

  • LINEで送る
  • このエントリーをはてなブックマークに追加

このブログをご覧になられている方はIT部門の方が多いだろうと想像しますが、BPMといった話を考える上でIT部門の方が共通して感じられている課題として、若手を中心に「業務」そのものの理解が不足しているという事があるのではないかと思います。私は昨年ユーザ会にてBPM系の研究会のコーディネーターをさせて頂きました。BPMを語る上で論点は様々あり、例えば「モデリング」や「体制論」等が非常に重要な要素ですが、研究活動を通じて強く感じたのは、大前提として業務を理解し改善しようという気持ちが全ての発端だという事です。当然なのですが、最も大切な要素です。そこで、本日は業務の理解という側面から「概要業務ヒアリング」について書きたいと思います。これは言わば現状業務要件の理解であり、BPM云々以前の話ですが、汎用的なスキルでもあるので誰の役にも立つといえます。

そもそも、BPM(ビジネスプロセスマネジメント)って何ということを詳しく知りたい方は、以下の記事でその目的や課題などを詳しく解説していますので、ぜひご参照ください。

>> BPM(ビジネスプロセスマネジメント)とは?

地図を持とう!

ヒアリングを始める時に、漠然と個々のユーザの業務手順を聞きだしてはいませんか?礼儀としてもどういった業務領域の話を聞きたいのかは事前に提示する必要がありますし、抜け漏れなく聞き出すためには概要レベルで業務の範囲を事前に想定しておくことが大切です。これは、例えるなら地図を持つ様なイメージです。例えば漫然と道順を聞き始めると、「駅を出て右に曲がって、、、」という説明にならざるを得ないですが、これでは実際に行った事のある場所で無いとなかなかイメージが沸きにくく、どこで曲がるか不安を覚えます。ある程度あらましの地図を持つ事で地図を見ながら書き込んで貰えるとお互いの認識が一致しますし、別のルートの可能性等にも気づく事ができます。

業務範囲を明確化するフレームワーク(地図)

業務範囲の探索

では、業務の範囲を把握するためのフレームワーク(地図)となる情報とはどんなものでしょうか。我々は良くプロセスマトリクスという手法を用います。業務機能を縦軸、シナリオ(業務のバリエーション)を横軸にとった表を使い、概要レベルの業務を確認します。

イメージ図

 

自社機器販売

仕入販売

導入サービス

xxx

見積

 

 

 

 

受注

 

 

 

 

手配

 

 

 

 

発注

 

 

 

 

xxx

 

 

 

 

販売系の業務の流れで言うならば、見積→受注→手配→(その後購買発注へ流れる) といったものが概要業務機能となります。これで業務工程としての範囲が明示的に分かります。

一方でシナリオとは、業務が大きく異なるバリエーションを指し、例えば顧客や仕向け地種別、取扱商品等で分かれます。その結果、国内卸向けの受注、輸出の受注といった具合でどの業務での話かを明確にした上で確認が行え、二つのシナリオに差異が無いかという視点で物事を確認する事が出来ます。

業務機能(縦軸)の設定

業務機能はどういった単位で整理するのが良いのでしょうか。

モデリングを意識すると、本来であれば粒度感(抽象度の粗さ)を揃える事が必要で、Lv2 だとかLv3 という階層をしっかり定義しなければなりませんが、現状ヒアリングの時点では概要と詳細という階層でシンプルに仮置きする事で構いません。

一般的に業務は以下の様な区切りで切ってゆきます。

  • 責任・主管部門が変わる場合
    • 例えば、購買の手配(要求部門)と購買発注(購買部)は別の工程と切ります。
  • 伝票、データが変わる場合
    • 見積書、受注伝票、購買依頼、購買発注といった主要な伝票やデータに目を付け、主要な伝票・データに関わる処理が完了するタイミングで切るように考えます。

実際には一から考えていては時間が掛かってしまうので、何らかのリファレンス(参照)元を探す事を推奨します。

  •  J-Soxフローや既存のシステムドキュメントから抽出する。

自社内で既に作成されている業務一覧や業務フローでは、業務ユーザを交えて一定の認知がされている業務の単位(ブロック)で記載がされている事が多いので参考とすることができます。ただし、詳細なフローはあるものの、いい塩梅に整理した概要の業務単位は存在しないケース等もありますのでご注意下さい。

  •  ERP等の機能(伝票)の切り口で一旦合わせる。

自社でSAP等のERPを利用している様なケースでは、そのERPでの機能の単位が業務部門含めて共通言語化している事がよくあります。実際それなりに標準化されているので参考になります。(見積、受注、出荷や得意先マスタといった主要伝票やマスタの切り口で見ていくと分かりやすい)

  •  世の中の知識体系として整理されたフレームワークを利用する。

世の中(特に海外が主ですが)には、企業活動をモデル化したフレームワークが存在します。例えば、APQC(米国生産性品質センター)のPCF(Process Classification Framework)、APICS のSCOR(Supply-chain operations reference)、Value Chain Group の VRM(Value Reference Model)等のリファレンスモデル類があり、こういったものを活用されるケースもあります。我々の経験では、これを主として用いるというよりは抜け漏れを防ぐための参照先とするケースが多く、計画系や管理系の業務についても考慮する際などには、参考になります。

その他にも、コンサル業の様に様々な業種のお客様を相手にする場合、実務上は世の中の業界本等も参照先として活用するケースがあります。

シナリオ(横軸)の設定

次にシナリオの切り口ですが、ポイントは業務処理が異なる要因が何かという点です。一般的には、販売系であれば顧客種別、チャネル種別、仕向地、取扱商品等、購買系であれば仕入先種別、購入品目等が要因となり、業務手順、ルール、システム等が異なってくる事になります。

ここについてはビジネスの特性に応じて変わるため、標準的な参照先というものがある訳ではないので、先ずはベテランのシステム部員や業務の方に聞いてしまうのが手っ取り早いと言えます。また、上述の業務機能上は同じはずなのに既存システムが分かれているケースはシナリオが分かれていると考えられますし、システム上の主要なキー項目となっている情報はシナリオが分かれる要因を表しているので把握しておくと良いでしょう。

シナリオマトリクスのフレームワークの活用法

実際のヒアリングに際しての活用方法ですが、今までのステップで整理したマトリクスイメージを画面に映しながら、ヒアリングして確認した内容を目の前で記述していくのがオススメです。その場で間違いの指摘を受けられますし、回答者自身が抜け漏れに気づきやすくなります。

以上、今回のブログでは ヒアリングする際の地図(フレーム)を持っておこうという話とその整理の概要を説明しました。今後、実際の概要ヒアリングの場面での確認事項についてお伝えしたいと思います。

メールマガジンの登録はこちらから
メルマガ登録 お問い合わせ