事業説明
Our Business
私たちは、オペレーション改革を単なるコスト削減の手法として考えていません。オペレーション改革こそ売上アップ・単価アップを実現する最も優れたアプローチだと確信しています。どのようにオペレーション改革を行い、売上アップ・単価アップを実現していくのか、その前提となる現状の営業組織の解説を先に行った上で具体的なオペレーション改革のステップを解説します。
目次
table of contents
隣の課とは共創ではなく競争
見込客発見から販売、フォローまで全部実施
アポ数、商談数等のシンプルな行動管理
新しい企画は営業企画で思案
従来型の営業体制は、基本的にアナログ主体で活動することが前提です。最近は営業活動でも少しづつデジタルを活用し、データ管理や、一部業務を自動化するなど営業DXに取り組もうとする会社が増えています。その際に組織体制も変化します。
CRO(Chief Revenue Officer)の元に構築されます。
営業フローを分業化し、競争ではなく共創する
みんなで全体の売上利益をあげようという思想
行動管理よりも数値指標(CPL/CAC/ARPU等)
各チームで企画や施策を思案
理想系の営業組織として語られることが多いですが、組織体制の大幅な変更において多くの課題が生じます。
- ※以下、表記略称
- マーケティングMKT
- インサイドセールスIS
- フィールドセールスFS
- カスタマーサクセスCS
共創と言いつつ最終利益責任はどこかという摩擦が生じる
ISの所属はMKTかFSかといった枝葉の議論に終始する
全体の業務を横ぐしで把握している人がいない
各チームでツールを導入し連携していない
全体最適な企画が立案されず徒労な活動が増える
売れない / 売りたくない人がISやCSにいきがち
指標ばかり管理し、行動管理をせず量が落ちる
このように、課題をあげるときりがありません。経験者となるCROが存在せず、参考になる事例も少なく、教科書通りにやろうとするも解決に至りません。
このように、課題をあげるときりがありません。経験者となるCROが存在せず、参考になる事例も少なく、教科書通りにやろうとするも解決に至りません。
従来の営業組織が良い悪い、ザ・モデル型の営業組織が良い悪いという話ではありません。根本的に行動管理のみ行いオペレーション・マネジメント(OpM)を行っていないことが問題です。往々にして営業活動や顧客サポート(CS)活動では、数値だけ課され、あとは自分たちで考えて行動しろ!という組織になります。KPIという名のもとに、行動量を増やせと指示があり、やり方は臨機応変に工夫しろ、それが営業の醍醐味だというわけです。
システム開発を行う上では常識であるプロジェクト・マネジメント(PM) / プロダクト・マネジメント(PdM)という役割が営業部隊やCS部隊にないことで生じる現象です。
開発行程において、隣のチームと競争することはありません。常に全体を統括しなければ、一つのエラーで全てが駄目になります。もし、システム開発において、PM / PdMが設置されなかった場合にはどうなるのでしょうか。
各々のエンジニアに、期限だけ設け、その日までにプロダクトが仕上がるなら開発言語は自由で、自分の好きなようにコードを書いてよいと指示していることになります。いつまで経っても、正常に動くシステムは完成しないでしょう。
システム開発部のアウトプットは言わずもがなプロダクト・システム・ツールです。開発過程において各業務を細かく区切り、都度進捗を確認して、ズレがないかすり合わせていきます。
プロダクトを徹底的に磨き上げるためにプロジェクト・マネジメント(PM) / プロダクト・マネジメント(PdM)という役割が必須で設置されます。優れたプロダクトの先にユーザー満足という結果が手に入ります。
では、営業部のアウトプットは何でしょうか?営業は売ってなんぼという視点では、アウトプットは受注数だと勘違いしてしまいます。しかし、受注数とは飽くまでもアウトプットから生じる結果です。営業部がコントロールできるアウトプットではありません。
開発部がプロダクトを磨くように本当なら営業部はオペレーションを徹底的に磨き上げることが必要です。
開発において一つのエラーやバグによって、一瞬で全ての機能に響が出ます。だからこそ「プロジェクト・マネジメント」「プロダクト・マネジメント」という役割が重要です。
営業においても、一つのオペレーションのエラーが、最終成果である成約に大きく関わってきます。どのオペレーションでエラーが生じたのか、それを見つけ素早く改善していくために、オペレーションを仕組化・可視化しておかなければなりません。
成果を上げる営業組織になるために、体制よりも横ぐしでオペレーション・マネジメント(OpM)が行われているか否かが重要です。営業組織としてのアウトプットであるオペレーションの品質管理・向上を行う役割です。
このオペレーション・マネジメント(OpM)という役割が私たちの提供サービスです。
基本的には、システム開発におけるプロジェクト・マネジメント手法を土台とし、営業組織に当てはめてアレンジしています。
ヒアリング・設計
プロジェクト・オーナー(社長 / 営業役員)へのヒアリング 目指す理想やゴールとそこに至るギャップや課題感を伺い視覚的にまとめます。
課題と解決策の可視化
社長、役員、実行する関係者へのヒアリング(部長・現場担当者) 各々が考えている課題感や解決の方向性などを伺い、整理整頓し可視化します。この課題と解決策の可視化のステップは非常に重要です。重要な理由は4つあります。
-
1.社員の本音を引き出すことが第一歩
ヒアリングを行うと課題というカタチではなく、文句や不満といったカタチで表現されることもあります。単純に愚痴というカタチで出てくることもあります。社長や役員にとっては耳の痛い話です。
しかし、本音を隠し綺麗ごとだけ言っている場合、行動せず成果を生まない組織となります。思ったことを隠さず言えて、自ら行動し成果を生み出す組織となるために必要なステップです。
-
2.役職によって見えている課題が違う
その差が何か、整理整頓しないと当事者同士は誰もわかりません。この状態では議論を重ねているようで重ねていません。ただ、見えている景色による理解の差分を埋めようとしているだけに過ぎません。同じような課題を半年経っても1年経っても議論しているならば、原因はここにあります。
役職が違うと役割が違うわけなので、その差を埋めようとすること自体が不毛で無意味です。それぞれの意見を、誰かが可視化し整理整頓することで、初めて適切な議論が始まります。
-
3.課題と解決策が玉石混交で話される
人は課題だけ、もしくは解決策だけ話し続けることはしません。常に課題と解決策や自分の感情や第三者の意見などが混ざった会話を行います。一つの解決策で、複数の課題が解決することもありますが、頭の中だけで紐づけることは困難です。
だからこそ、課題と解決策を図解で紐づけて整理することで初めて議論が積み重なります。
-
4.社長は口だけ
決して嘘つきという話ではありません。多くの社長や役員は口頭で指示するだけです。インプットが多く、決断を行うことが役割なので自分の考えをドキュメントに整理する時間はありません。まとめる人も稀にいますが自分の考えをまとめるだけであって、このステップのように各役職の考えを整理することはしません。
この課題と解決策が整理整頓されれば、オペレーション・マネジメントの8割型は成功します。
解決策ごとに実行プランを作成
解決策を確実に実行するための計画を作成 誰がいつ見ても行動できるように「実施の背景」「仮説」「実行プラン」「実行概要」「アウトプット」まで丁寧に落とし込んで明記していくことがポイントです。
作成するドキュメントの一覧
オペレーションの品質を管理し、向上させていくための基準となるアウトプットを一覧化 「マニュアル」「ガイドライン」「管理フォーマット」「スキルマトリクス」 「マインドマトリクス」「スクリプト」「可視化レポート」「戦略方針」「資料テンプレート」「MTGテンプレート」などオペレーションが明確で迷いなく、常に自走して磨かれる状態になっていきます。
スケジューリング・WBS作成
アウトプットの作成、定着、オペレーション品質向上のタイムラインを作成 営業組織、オペレーションの仕組化・可視化を行い、属人的業務からの脱却を行います。プロジェクトマネジメント同様に、タスクまで細かく落とし込み確実にオペレーションの改善を実行します。
プロジェクトチーム組成・キックオフ
OpM(オペレーション・マネジメント)チームの組成 私たちもプロジェクトの伴走支援を行いますが、クライアントの内部にもPMO(プロジェクト・マネジメント・オフィス)スタッフを配置していただき連携して進めていきます。
実際に作成したプロジェクト設計書を見てみる
オペレーション・マネジメントの実行ステップでお見せした設計書の実例をダウンロードできます。会社の規模別、課題別に実際のクライアントに提供したサンプル(機密情報を省いたもの)をご覧いただけます。
お気軽に
ご相談ください
属人的な業務を脱却させたい、仕組で事業を伸ばしたい、DXに適応した業務改革を行いたい等
オペレーションに関する悩みや不明点は全てクリアにできます。お気軽にご相談ください。