結局、人がいないと業務が止まってしまう
企業の抱える共通の問題点としてよく挙げられるのが、「属人的な業務の多さ」です。特定のスキルを持つ人に業務が集中したり、担当者に休まれると業務が止まってしまうといった問題は、まさに属人的な業務が及ぼす悪影響の代表です。
ここから脱却するためにシステム導入を行うわけですが、それでも解決しなかったという声も少なくありません。例えば、例外的な対応であったり、より細かな対応が求められたりといったプロセスがうまくシステムに反映できず、結局人の判断を仰ぐ工程がかなりの分量を占めたりします。または、本来必要な機能ではない部分ばかりがシステム化され、必要な部分は相変わらず多くの人手を介しているといった悩みです。
ITのプロであるシステム・インテグレータにシステム導入を任せたにも関わらず、なぜこのようなことになってしまうのでしょうか。
業務を正しく抽出・可視化するために
一戸建てを立てる時のことを考えてください。建築会社は顧客要望に応じ、適切な設計、適切な材料、適切な納期をコントロールしながら家を建てます。起点はあくまで顧客要望です。ここで家族全員の「理想の家」に対するイメージは、はたして一致しているでしょうか。システム構築も同様です。起点はあくまでシステムに対する要求ですが、このシステム要求をまとめる要件定義が、各業務の担当者に要求をヒアリングすることから始まっていることが多く、これが失敗の原因になります。さしづめ、家族がバラバラに自分の関心領域に関する理想の機能を言い合っているような状態です。
システム構築のための要求定義、つまりRFI/RFPは、単なる「欲しい機能」のリストになってしまっています。それらの機能は本当に必要なのか、それらには正しい費用対効果があるのか、そもそも業務は改善するのか、すべてを正しく管理していくにはやはり業務の可視化と課題の抽出が必要となります。
「また業務の可視化か」と思われた方もいると思います。数々の業務改善コンサルティング会社がこれまで要件マネジメントのために業務分析を行い、現場ヒアリングを行い、改善点を示した詳細な報告書を提出してきました。これだけ労力をかけた業務分析結果からRFPを提出しているにも関わらず、プロジェクトが始まるとまた要件定義からやり直し、結局使われないシステムができあがる。こういった経験から、日本企業は一種の「コンサルティング・アレルギー」に罹っているのではないでしょうか。
ここで紹介する「BPEC（Business Process Engineering Cycle）」も同様にコンサルティング手法ですが、従来のコンサルティングとは一線を画す以下のような独自性があります。
- 現場担当者の負荷が少ない
- 業務を抜け漏れなく抽出
- 定量分析が容易
- 本当に改善が必要な業務だけ可視化
- 業務担当者が見落としがちな業務問題を抽出
BPECはコンサルタントが顧客先で手厚く実施する類のコンサルティング・メソッドではなく、担当者自らが継続的に業務を改善していくための手法です。
