WORLD PICKS
世界の事例から、仕事の見方を変える。
← 分類の記事一覧へ

稼働したのに利益が増えない。その後を引き受ける「便益の責任者」は何をするのか

システム稼働後の成果。導入を完了する。事業の効果を出す

例えば、新しい営業支援システムが予定どおり稼働したとする。必要な機能はそろい、利用者への研修も終わった。それでも受注は増えない。開発担当は納品済み、営業部門は現場が忙しいと説明し、投資会議では「定着に時間がかかる」と報告が続く。

この場面で足りないのは、成果を報告する資料とは限らない。受注へつながる仕事の変更を、稼働後に決めて実行する人がいない可能性がある。

プロジェクトの成果物から事業上の便益へは、いくつかの段階がある。システムが使える、担当者が使う、行動が変わる、顧客や業務の結果が変わる。その途中で止まっているなら、稼働率を上げるだけでは利益に届かない。

本稿は、便益が生まれる過程のどこが止まったかを特定し、その部分を変える権限と予算を運用側へ引き継ぐことを提案する。便益の責任者を置く目的は、数字の達成を一人に押し付けることではなく、稼働後の介入を選べる状態にすることだ。

この記事の目次
  1. 納品と事業成果は、同じ成功ではない
  2. 「売上を増やす」を、介入できる過程へ分ける
  3. 引き継ぐのは、目標だけでなく変更する権限
  4. 時間が浮いたことと、お金が残ること
  5. 次の改善にも、使える資源の上限がある
  6. 続けるべき改善と、見直すべき投資

納品と事業成果は、同じ成功ではない

SerraとKuncの2015年の研究は、ブラジル、英国、米国の実務家への調査を通じ、便益実現管理の実践と、戦略的価値を生む意味でのプロジェクト成功との正の関連を報告している。331人のプロジェクト実務家のデータを分析した調査であり、責任者を任命した企業の利益増加を無作為実験で示したものではない。Benefits Realisation Management and its influence on project success

回答者が管理の実践と成功を評価しているため、もともと実行力のある組織が両方を高く評価している可能性も残る。ここから「責任者を置けば成功率が何割上がる」とは言えない。

一方、納期・予算・仕様を満たすことだけで投資価値を説明し切れない、という問いは重要だ。複数の案件が関係するなら、営業システム、料金設計、商品供給の各担当がそれぞれ完成しても、それらを組み合わせて顧客へ届ける活動が必要になる。

その活動をプロジェクト間の隙間に落とさないため、成果物の責任と便益の責任を分けて定義する。前者は何を作り渡すか、後者は何を変えて事業成果に結び付けるかを担う。

「売上を増やす」を、介入できる過程へ分ける

便益の責任者に売上目標だけを渡しても、天候や市場変化まで制御できるわけではない。必要なのは、目標を自分たちが働きかけられる過程へ分けることだ。

営業支援の例なら、商談情報が記録される、次の対応が決まる、期限内に顧客へ連絡する、提案が顧客の検討に進む、受注する、という流れが考えられる。どの段階をシステムが支え、どこを運用変更や営業判断が担うかを分ける。

観測した状態 まず変える対象
必要な情報が登録されない 入力負荷、データ取得方法、利用目的
情報はあるが次の対応が決まらない 案件の担当、判断権限、優先順位
対応しても顧客が検討を進めない 提案内容、対象顧客、価格などの事業仮説
成果は出るが運用費が想定を超える 提供方法、支援範囲、運用契約

これは本稿の判断例であり、売上を因果的に説明し尽くすモデルではない。ただ、すべての不振に追加研修で対応するより、次に使う時間と費用を選びやすくなる。

例えば利用率は高いのに成果が出ない場合、利用率をさらに上げることが主要な解決策とは限らない。利用された機能が事業上の行動へどうつながったかを確かめ、必要なら当初の便益仮説自体を変更する。

引き継ぐのは、目標だけでなく変更する権限

英国政府のGate Review 5は、稼働後のサービス運用と便益の実現を確認し、運用側への引継ぎ、資源、継続的な責任を扱う。公共投資の運用指針であり、日本の民間企業が同じ時期・様式で審査すべきという意味ではない。GOV.UK「Operational Review and Benefits Realisation」

この考え方を実務に用いるなら、引継ぎでは「営業部長が責任者」と名前を書くところで止めない。その人が営業手順を変えられるか、追加の分析を依頼できるか、運用費の使い方を変えられるかを確認する。

また、営業だけでは決められない価格や供給能力の問題は、上位の事業責任者へ判断を求める経路を持たせる。担当者に数字を要求しながら、必要な変更権限を渡さない構成では、報告が丁寧になるだけかもしれない。

複数案件が一つの便益に寄与する場合は、同じ増収を各案件へ重ねて計上しない。どの成果を共有し、どの費用を負担しているかを一つの見取り図で示す。案件ごとの評価表を合算するだけでは、二重計上を見落とし得る。

時間が浮いたことと、お金が残ること

仮に新しい仕組みによって毎月100時間の作業が減り、社内の評価単価を1時間3,000円とすると、時間の価値は月30万円と置ける。ただし給与や契約支出が変わらなければ、30万円の現金が会社に残るわけではない。これは説明用の仮定である。

便益の責任者は、その100時間をどう使ったかまで追う。残業支出を減らせたのか、追加の顧客対応に回したのか、余裕ができただけなのか。どれも同じ欄へ「費用削減」と書かない。

英国政府の効率化枠組みも、現金支出に反映する節約と、同じ資源でより多くの成果を出す改善を区別している。ここでは分類の考え方を参照し、日本企業の会計処理を定めるものとしては使わない。GOV.UK「The Government Efficiency Framework」

追加の顧客対応が増えた場合も、それがすべて新システムの効果とは限らない。繁忙度や人員、価格変更の影響を確かめる。可能なら同種業務の未導入範囲と比較し、比較できない場合は「導入後の観測」であることを明記する。

次の改善にも、使える資源の上限がある

稼働後に便益を追うことは、当初の投資を正当化するまで費用を追加することではない。残る課題への追加費用と、得られる見込みの便益を改めて比較する。既に使った開発費の大きさだけで、次の改修の価値は決まらない。

例えば、入力負荷を減らす小さな修正と、顧客層を変える大規模な再開発は別の判断である。便益の責任者には、承認済みの運用改善の範囲と、新しい投資判断が必要になる範囲を示す。これにより、成果の追跡が無期限の追加開発へ変わることを避けやすくなる。

稼働後、どこへ介入するか。情報が登録されない場合は、入力負荷・運用を変える。使われても顧客に届かない場合は、事業の仮説を見直す。成果より提供費用が増える場合は、提供条件・追加投資を見直す。
本文の営業システムの仮想例。各状態は診断の入口であり、売上の原因を確定するモデルではありません。

続けるべき改善と、見直すべき投資

仮の営業システムで、案件が登録されない原因が入力項目の重複だと確認できたとする。項目を減らす試行で記録が増え、担当者が次の対応を決められるようになったなら、運用改善を続ける根拠がある。まだ受注までの期間が十分に経過していない場合、すぐ失敗と判定するのは早い。

条件を変え、情報登録と対応は十分に行われているが、対象顧客が商品を必要としていないと分かった場合はどうか。この場合に入力を徹底させても、主要な問題は解けない。対象顧客や提案を変えるか、その用途への追加投資を止める判断が先になる。

さらに、受注は増えたが個別対応の費用が増収を上回るなら、拡大より提供条件の変更を優先する候補になる。成果の件数だけで便益を判定しないことで、次の投資を選び直せる。

これらの判断には、確認する時期も必要だ。営業周期を無視して毎週の売上で結論を変えることも、期限を決めず「定着待ち」を続けることも避けたい。先行する行動の変化と、後から現れる成果を分け、どの時点で仮説を見直すかを引継ぎ時に決める。

便益の責任者の仕事は、稼働したシステムを擁護し続けることではない。成果へ至る過程の詰まりを見つけ、運用を変えるのか、事業仮説を変えるのか、追加投資を止めるのかを選ぶことである。その判断権限と資源まで引き継いで初めて、納品後にも投資を育て、必要なら見直す主体が残る。