こんばんは。it-daxです。

BPR（業務改善）やDX（デジタルとランスフォーメーション）でも、AsIs分析は必ず行うと思います。
その際、BPMNやフローチャートを書く→意見を聞く→課題を書く といったことをしている方は多いと思います。
この流れ自体は大きく間違いではないのですが、いまあるFWだけでは重要な観点が不足しています。

スキルが高いコンサルになると重要な観点をヒアリングで聞いたりするかもしれませんが、わたしはほとんど見たことがありません。

今回はAsIs分析においてBPMNやフローチャートに不足している観点と整理の方法をご紹介していこうと思います。

AsIs分析に必要な観点

BPMNやフローチャートの課題は、業務や行動をそのままトレースするだけ となっていることにあります。
ToBeであればそれでも良いと思います。業務要件の業務フローでもそれでも良いと思います。
しかし、AsIs分析だけはダメです。あるべき姿を描くためのインプットとなるのですから、最低限重要な情報を洗い出すべきです。
ではどのような観点を、どのように整理すればよいのでしょうか。

業務単位の観点

• 業務全体の課題

  • 作業単位の分析をした結果

• ヒアリングした課題

  • 現場ユーザーからのヒアリング

• 新たなる価値創出の観点

作業単位の観点

• 時間軸

  • タイムスケジュール

  • 作業にかかる時間

• 登場人物

  • 役職

  • 人数

• コスト

  • 人的コスト

  • 物的コストなど

• 作業の目的・理由

• 作業に必要なインプット

• 作業の結果のアウトプット

• 作業内容

• 制約事項

  • 法律による制約

  • 社内ルールによる制約など

• デジタルツール

• システム操作

• システム処理のインプット

• システム処理のアウトプット

• システム処理内容

• 作業の課題

• 新たな価値創出・課題解決の観点

• インプットやアウトプットのリアルデータ

必要最低限の観点でこれだけ必要となります。

業務単位とは下記の図の青枠の部分を指します。
業務の全体概要を整理するかと思いますが、そこで出てくる最小の単位がここにあたります。

作業単位とは、この業務単位で作成されるBPMNで表記されるフロー1つ1つの単位を指します。

これらをまとめてあるべき姿を策定した結果、事業部や会社に対してどのような効果をもたらすのかを最終的にまとめていくのがITやDXのコンサルティングになります。
EA（エンタープライズアーキテクチャ）のビジネスアーキテクチャ後半部分にも流用可能ですね。

理由

ではなぜここまで細かい粒度で整理する必要があるのでしょうか。
それは整理した結果を客観的に分析するためというのが大きな理由です。

クライアントとの打ち合わせや現場へのヒアリングを行うと、どうしても主観的になってしまうことがあります。
主観的な意見も大事ですが、それはクライアント側の意見であり、コンサルタントの意見になってはいけないと思います。

情報を情報として捉えて分析するために細かい観点での調査や整理が必要です。
プロジェクトによっては他にも追加すべき観点があると思いますので、調査や整理をしながら足していくと良いでしょう。

他にも有識者へ意見を伺う際に、口頭や散らばった資料で説明するよりも遥かにスムーズです。

作成方法

オススメはLucidChartというツールで、作業単位のオブジェクトに記載していくことです。
オブジェクトに様々なデータを付与することができます。便利です。
エクセルやパワポではどうしても難しいですし面倒臭いです。
最後のまとめに利用する以外に利用する機会はないでしょう。

もしくは以前の記事で紹介したツールのMiroで整理する方法もあります。

終わりに

わたしがまだ20代ながらも自社やクライアントから評価された理由として、こういったファクト重視の分析を徹底していたことがあると思います。
クライアントからも納得感をもって進められたという評価をいただいたこともあります。

よくAsIsを分析し過ぎるとToBeがAsIsに引っ張られてしまうという話を聞きます。
私の見解は、おそらくToBeの作り方が悪いです。
AsIsと細部まで比較したり、ToBeを作業単位の細部から作っているのだと思います。
AsIsは具体→抽象ですが、ToBeは抽象→具体です。
そして比較すべきは抽象の部分であったり、特筆すべき具体の点のみです。
他に細かく比較する必要はありません。フローとして成立するというクライアントからのコンセンサスがあればいいのです。