今やシステムは企業活動と不可分のものとなりました。業務改善といえばシステム開発と言っても過言ではありません。しかし、システム開発のおよそ7割は、「導入したのに使われない」「改善されない」という失敗に陥るとも言われています。「数十億円かけてシステム構築を行ったが、業務プロセスとシステム機能のギャップにより、開発から2年が経過してもカットオーバーの目途がついていない」。そんな話は珍しくありません。システム開発においては、業務上の問題点の可視化と抽出ができていない状態でスタートしてしまうと、できあがるのは「そもそも方向性から違っている」という残念なシステムです。本稿では業務改善の観点から、システム導入で失敗しないための自立的な業務の可視化分析手法としての「BPEC」、それを利用してシステム要求につなげるための手法「B-NASS」について解説します。
結局、人がいないと業務が止まってしまう
企業の抱える共通の問題点としてよく挙げられるのが、「属人的な業務の多さ」です。特定のスキルを持つ人に業務が集中したり、担当者に休まれると業務が止まってしまうといった問題は、まさに属人的な業務が及ぼす悪影響の代表です。
ここから脱却するためにシステム導入を行うわけですが、それでも解決しなかったという声も少なくありません。例えば、例外的な対応であったり、より細かな対応が求められたりといったプロセスがうまくシステムに反映できず、結局人の判断を仰ぐ工程がかなりの分量を占めたりします。または、本来必要な機能ではない部分ばかりがシステム化され、必要な部分は相変わらず多くの人手を介しているといった悩みです。
ITのプロであるシステム・インテグレータにシステム導入を任せたにも関わらず、なぜこのようなことになってしまうのでしょうか。
業務を正しく抽出・可視化するために
一戸建てを立てる時のことを考えてください。建築会社は顧客要望に応じ、適切な設計、適切な材料、適切な納期をコントロールしながら家を建てます。起点はあくまで顧客要望です。ここで家族全員の「理想の家」に対するイメージは、はたして一致しているでしょうか。システム構築も同様です。起点はあくまでシステムに対する要求ですが、このシステム要求をまとめる要件定義が、各業務の担当者に要求をヒアリングすることから始まっていることが多く、これが失敗の原因になります。さしづめ、家族がバラバラに自分の関心領域に関する理想の機能を言い合っているような状態です。
システム構築のための要求定義、つまりRFI/RFPは、単なる「欲しい機能」のリストになってしまっています。それらの機能は本当に必要なのか、それらには正しい費用対効果があるのか、そもそも業務は改善するのか、すべてを正しく管理していくにはやはり業務の可視化と課題の抽出が必要となります。
「また業務の可視化か」と思われた方もいると思います。数々の業務改善コンサルティング会社がこれまで要件マネジメントのために業務分析を行い、現場ヒアリングを行い、改善点を示した詳細な報告書を提出してきました。これだけ労力をかけた業務分析結果からRFPを提出しているにも関わらず、プロジェクトが始まるとまた要件定義からやり直し、結局使われないシステムができあがる。こういった経験から、日本企業は一種の「コンサルティング・アレルギー」に罹っているのではないでしょうか。
ここで紹介する「BPEC（Business Process Engineering Cycle）」も同様にコンサルティング手法ですが、従来のコンサルティングとは一線を画す以下のような独自性があります。
- 現場担当者の負荷が少ない
- 業務を抜け漏れなく抽出
- 定量分析が容易
- 本当に改善が必要な業務だけ可視化
- 業務担当者が見落としがちな業務問題を抽出
BPECはコンサルタントが顧客先で手厚く実施する類のコンサルティング・メソッドではなく、担当者自らが継続的に業務を改善していくための手法です。
この記事は参考になりましたか？
- デジタルトランスフォーメーションのための超高速開発基盤！連載記事一覧
- この記事の著者
-
佐藤 彰広（サトウアキヒロ）
株式会社アシスト 情報基盤事業部 製品統括部プログレス推進部 Oracleデータベースのエンジニアとして、企画・プロジェクト管理に従事。その後、ビジネス開発部隊として新規ソフトウェアの調査・発掘を経て、BRMS「Progress Corticon」の日本での立ち上げを担う。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか？
この記事をシェア
