システム投資の効果が出ない：利用・業務変更・成果のどこで止まるか
FAQも顧客データも研修もそろった。それでも顧客は、担当者へ同じ説明を繰り返している。そんな仮想のプログラムを一件たどると、追加開発が必要なのか、利用権限や引き継ぎを直すのかが分かれます。成果物の完成から利用、業務の変化、便益まで、途切れた箇所を見ていきます。
この記事が扱う選択は、遅れた案件を立て直すか、案件間と運用への受け渡しを直すかである。成果物が不足しているなら個別案件へ戻す。一方、成果物はそろっているのに利用、権限、業務手順、評価指標がつながっていないなら、プログラムとして便益までの経路を直す。
この記事の目次
FAQから担当者へ、一件の問い合わせを追う
仮に、顧客問い合わせを減らすプログラムが三案件から成るとする。AはFAQ基盤、Bは顧客データ統合、Cは担当者研修である。三案件が予定どおり完了しても、FAQで解決できない顧客を担当者へ渡す入口がなく、統合データを閲覧する権限も付与されなければ、問い合わせの再説明は減らない。
ここで「A、B、Cは完了した」と報告するだけでは原因を特定できない。次の順で一件を追う。
| 段階 | 確認する事実 | 止まっていた場合の戻し先 |
|---|---|---|
| 成果物 | 機能、データ、研修が受入条件を満たすか | 個別プロジェクト |
| 利用 | 対象者が権限と時間を持ち、実際に使えるか | 導入・運用責任者 |
| 業務変化 | 引継ぎ回数や処理手順が意図どおり変わったか | 複数案件を束ねる責任者 |
| 便益 | 待ち時間、再問い合わせ、費用などが変わったか | 便益責任者と事業責任者 |
成果物に不具合があれば案件へ戻す。しかし利用権限がない問題をFAQ開発案件の納期管理へ戻しても解けない。案件間の前提と、稼働後の業務責任を調整する必要がある。
公開・閲覧・解消・受付負担のどこで止まるか
FAQから問い合わせ削減へ至る経路を、公開→閲覧→疑問解消→受付負担減として読む。公開しても検索に出ないなら利用への接続、閲覧されても回答が古いなら内容、疑問が解消しても確認電話が必須なら業務手順が障害になる。FAQのページ数を増やす対策が効くのは、その不足が原因の場合に限られる。
問い合わせが減らないときは、該当経路を通った用件と、初めから対象外の用件を分ける。対象外が増えたために総件数が変わらないなら、狙った便益が失敗したと即断しない。反対に閲覧数だけが伸びても疑問が解消していなければ、便益を実現したとは数えない。便益責任の移管は稼働後の責任者、案件間の入力・出力は受け渡し条件で扱い、本稿では未達の原因診断に使う。
完成したものと、変わった業務を分ける
プロジェクトの完成条件は通常、システム、制度、データ、研修などの成果物で表される。便益の完成条件は、成果物が使われた結果として起きる変化である。たとえば営業支援システムの稼働は成果物、見積作成の短縮や失注理由の把握は中間成果、利益率や受注率の改善は事業上の便益になる。
英国Infrastructure and Projects Authorityの便益管理ガイドは、便益を構想から導入後の評価まで追う必要があるとし、便益はプロジェクトの後半に現れ、責任がプロジェクト外に置かれることもあると説明する。これは英国の大規模公共事業向け指針であり、日本企業の改善率を示す研究ではない。それでも「納品後に誰が何を変えるか」を計画へ含める論点は、複数案件を束ねる際に使える。
SerraとKuncは英国・米国・ブラジルを主な対象として調査し、その他の国からの36回答を含む331回答を全体分析に用いて、便益実現管理と成功認識の関係を調べた。関連は報告されたが、無作為化実験ではなく、成功の自己評価を含む。便益台帳を作れば利益が何％増える、と読むことはできない。また後続研究には、便益管理単独と成功の関係が弱い、または混合的だとする整理もある。形式を導入するだけで効果が出る証拠ではない。
便益が出ない理由を、指標未達だけで決めない
便益未達には少なくとも三種類ある。第一は成果物が足りない。第二は成果物はあるが、利用条件が整っていない。第三は利用と業務変化まで起きたが、想定した因果関係が成立しなかった場合である。
第三のケースでは、現場へ利用を強制するのではなく、事業仮説を見直す。FAQ利用が増え、再説明も減ったのに顧客満足が変わらないなら、待ち時間の主因は別工程かもしれない。便益責任者には、数字を追うだけでなく、追加投資、対象変更、中止を選べる権限が要る。
反対に、効果がまだ出ないという理由だけで早期に打ち切るのも危険である。利用者の移行期間が必要な施策では、観測期間が短いだけかもしれない。測定開始前に、先に動く指標と後から動く指標を分ける。研修受講率を最終便益にせず、実際の利用、業務の変化、事業結果へ順に接続する。
止まった経路の修正先を、月次会議で決める
月次会議は、便益一件の経路で前回から進まなかった矢印を議題にする。FAQが公開済みでも引継ぎを測れないなら計測経路を、引継ぎが動いても処理時間が増えたなら業務側の条件を調べる。日付だけを延期せず、次の観測で確かめられる原因仮説を置く。
対象は投資の存続理由に直結する便益を優先し、基準時点・対象者・算定方法の変更を残す。この会議方法は引用研究が直接検証したものではなく編集上の提案である。未所有の経路や未達への対応が改善しなければ、議題と記録を簡素化する。
診断後に、受け渡しと責任の設計へ進む
このサイトでは、案件同士の接続と、稼働後の責任を別の記事で扱っています。本稿で答えるのは、成果物がそろった後の未達を、どの責任者へ戻して直すかです。
| 困っている状態 | 読む記事・扱う判断 |
|---|---|
| 案件は進んでいるが、つなげて使えない | 受け渡し条件を合意する |
| 稼働後、成果を変える人がいない | 便益の責任と権限を決める |
| 使われているのに効果が出ない | 本稿の四段階で、実装・利用条件・事業仮説のどこへ戻すかを選ぶ |
FAQが完成しているなら、まず一件の用件で、閲覧から担当者への引き継ぎまで途切れた箇所を確かめる。足りない機能と、権限や業務の未調整を分けて戻せれば、追加開発だけに修正を集めずに済む。
参考資料
- UK Infrastructure and Projects Authority, Guide for Effective Benefits Management in Major Projects
- Serra & Kunc (2015), Benefits realisation management and its influence on project success
- PMI, Benefits realization management and strategic project success analysis
- Badewi (2016), The impact of project management and benefits management practices on project success