ITやRPAの導入を進める際に避けて通れないのが「業務プロセスの可視化」です。現場が現在やっていることをフローチャート状に記述してゆけば一見完成した様に見えるので「可視化作業は難しいことではない」と思われるのですが、現実はかなり大変です。
これはある企業の受注製造業務の可視化を支援した際に遭遇した状況なのですが・・・
『鈴木さん、ご指示頂いた通り、業務プロセスの可視化ができました。これがその成果です。』
と言われ、A3縦長のフローチャートを見せて頂きました。ところがこの会社さんは社員と部門数が多いので、直感的に「A3一枚程度で記述し尽くせるほど単純ではないはず」と感じました。そこで意地悪なことを始めてみました。
鈴木「では受注登録と書いてありますが、これは受注システムに登録するのですね？」
担当者「はい。そうです。」
鈴木「それだけですか？それしか書いてありませんが。」
担当者「実は・・・」
色々とヒアリングしてみたところ、「受注」と二文字で書かれている業務をもう少しかみ砕くと、「受注システムへの手入力」と「Excelでの受注管理表への手入力」の二つの業務をやっている、ということが事実だとわかりました。それをプロセスに記載することを忘れていた（？）担当者にその理由を聞いたのですが、結局「可視化して何がおきるのか良く解らなかったので、わざわざ紙に書く必要は無いと思った」ということでした。
皆様の多くがここでお気づきかと思いますが、これは「可視化の粒感」が粗すぎたのです。この粒感の考え方をお伝えするのが非常に難しく、可視化チームの人数が多くなればなるほどやっかいな問題になります。
では、どうすれば良いのでしょうか？
私の経験では対策は１つしか無く、「業務で負担となっている課題の拾い出しを平行して行う」ことです。
業務の担当者はプロセス可視化には無関心ですが、日常業務の負担とか頑張っていることはかなり具体的に生々しく語ることができます。下手をすると聞かなくても答えてくれる程饒舌に話しをされる場合もあります。この課題が発生している箇所がプロセスのフローの中に登場していない場合、「粒感が大きすぎる」と言えます。
言い方を変えれば、「課題が発生していない業務は可視化されなくても（IT化の為には）あまり大きな問題にはならない」とも言えます。
ただし、このやり方を進めると、「現状肯定型の課題設定」に留まってしまう副作用があります。要するにITによる会社の改革をしようとしているのに、現状を単純に追認した状態でシステムの要件を検討してしまう、というリスクを内包しているのです。これを避ける為には、経営課題や経営方針も含めた課題の抽出が必要であり、そこの部分に高度なファシリテーション能力が要求とされるのです。
このように、「業務プロセスの可視化」を通り一遍にやってしまうと、可視化が完了したかの様に誤解したり満足してしまう可能性が高く、後々使える情報資産になりません。
経営戦略にしっかり紐付けされた現状分析を実現するためにも業務プロセスの可視化の粒感は非常に重要なものであり、これに失敗するとIT化もうまくいきません。
是非、上手に可視化スキルを上げていける様、人材育成を進めて頂きたいものです。