企業規模にあわせたRevOpsの役割

企業規模にあわせたRevOpsの役割

RevOpsはあらゆる規模の企業で役割が設けられるようになってきました。しかしその役割は画一的なものではなく、それぞれの企業の運用スタイルはさまざまです。例えば、スタートアップなどは柔軟性やスピードという利点がありますが、少ない予算内で良さそうなものをとりあえず使ってみる、という傾向にあります。一方大企業はシステム導入にかかるプロセスが多く、決断に時間がかかる傾向があります。
また変化のスピードだけでなく、独自の傾向もあります。スタートアップ企業はCRMをリプレイスしがちでシステム管理者が存在しなかったり、企業規模が拡大するにつれて対応しなければならない技術的負債が多く発生します。
成長中の企業のRevOpsはGTM戦略の修正をサポートしながら、過去のシステム構成による不具合に随時対応しなければなりません。大企業はセキュリティ意識が高いためシステムを固定化したがり、運用を外部企業に依存し、複数のCRMインスタンスを統合しようとする傾向があります。
この記事では、さまざまな規模の企業のRevOpsはどのような役割を担うとよいのか、関連する観点も含めて紹介していきます。

スタートアップ企業の場合

スタートアップ企業のRevOpsは、システムやオペレーションなどあらゆる観点で一から基盤を作り上げていく必要があります。一方で、予算やリソースには限りがあるため、全てのものを最良な形に仕上げることには限界があります。現時点のビジネスに必要なものはなにかを意識しながらRevOpsの業務を進めていくことが重要です。

必要最低限のCRMを構築する

‍ほとんどの場合、最良のテクノロジーを最初から導入できるわけではありません。多くの企業は十分な資金を調達するまではフリーミアムのサービスや、場合によってはエクセルシートからスタートすることもよくあります。無料のプラットフォームから始めるのであれば、将来的な移行を見据え、次のCRMやMAに必要なデータ構造をよく考えましょう。標準オブジェクトやプラグインについて学び、利用するフィールドの数を制限しましょう。CRMの使い方が複雑であればあるほど、利用頻度も次のシステムへ移行する際の柔軟性も低くなります。条件付きページレイアウト、オブジェクト処理、不要になったフィールドの定期的な削除などを行い、ユーザーが欲しい情報にアクセスしやすくしましょう。

本格的な導入・実装は専門家に依頼する

本格的なCRMへ移行する資金が確保できたら、システムの導入・実装は専門家に依頼しましょう。社内で完結させることで予算を節約しているように感じられるかもしれませんが、テクノロジーツールはそれぞれに基本の理念や意図された使い方が存在します。それに逆らって運用プロセスを組んでしまうと、どこかのタイミングで既存インスタンスをリプレイスしなければならなくなるケースを、私たちも何度も見てきました。不適切なデータ構造をしたり、カスタムオブジェクトを多く使いすぎる、アドオンツールが乱立する、データ定義が統一されていないなど、これらは雪だるま式に大きな問題に発展します。

‍命名規則やデータ管理をないがしろにしない

今のうちから、2年後、5年後のレベニュー活動を見据え、それらを正しく効果測定できるようなデータ管理方法を考えることは非常に重要です。現状はまだ使用していないが、将来使うだろうチャネルや、データ収集項目を想定し、適切なレポーティングをするために必要なデータ管理のアプローチを考えつつ、予想外になった場合のある程度の柔軟性が求められます。

テクノロジーによる制限の周知

見込み客から商談に至るまでのレベニュープロセスや重要な指標を経営層と合意しましょう。RevOpsの運用が始まると、経営層や各部門からデータに関するさまざまなリクエストがくるでしょう。しかし、どんなシステムにも限界があります。特に新興サービスや安価なサービスでは、ドキュメント上は実現可能と記載されていることが、実際には実現できないことがあります。稀なケースですが実際にあるCRMシステムでは、テクニカルサポートにケースを上げても数週間も解決されず、最終的にはシステムの不具合であることを知らされ、開発チームの機能改善リストに追加されて終わったことがありました。
特に経営層には現状トラッキングできる指標をしっかり伝え、同意をとっておくことが重要です。

適切なCRM運用を考える

現場の営業メンバーは、難しいターゲットを課されて日々の営業活動を行っています。一方で経営層は、意思決定のためのデータを分析し、そのデータを得るためにCRMへのデータ入力を求めます。経営層からすればそれは当然のことであり、データ入力は確かに現場の営業メンバーの業務内容の一部です。
しかし、入力項目が多ければ多いほど入力は雑多になる上、本当に必要ではない項目を一生懸命入力しているケースも多く見受けられます。そもそもデータは、利用シーンが明確でないと活用はできないものです。システム内のあらゆる検証ルールと必須フィールドのカタログを作成して、本当に必要な情報だけ記録してもらいましょう。これらをきちんと担当する管理者がいなければ、ユーザーはシステムエラーに疲労し、データ入力がずさんになり始めます。適当に値を選択したり、空白にしたりということが多く起きるようになります。

テクノロジースタックの監査プロセスの確立

こちらのブログでもご紹介していますが、マーケティングからカスタマーサクセスまで様々なツールを導入するようになったことで、コストや機能、セキュリティの観点から適切にスタックを維持することが求められるようになりました。定期的にレビューを行う慣習をつけておくことが重要です。

成長企業の場合

スタートアップ企業が安定した成長フェーズに入ってくると、RevOpsの役割が少しずつ変化し、専任の担当者がアサインされることが増えてきます。このフェーズではこれまで手探り状態でレベニューオペレーションをしており必ずしもベストな状況ではないことがほとんどです。
MAツールの管理は雑然とし、CRMは使用には耐えうるものの不便な状況、カスタマーサクセスは、部分的に統合された別のシステムを使用している、といったようなケースが多いでしょう。営業組織の規模を拡大しているこのタイミングこそ、デマンドジェネレーションに真剣に取り組み、カスタマーサクセスへの引き継ぎをスムーズに行えるようにする必要があります。
設立当初から会社に在籍していれば、システムを構築した当時の理由を把握するのは簡単です。カスタマイズは今となっては役に立たないかもしれませんが、ある時点では、組織の誰かが必要としていたケースも多くあります。組織に入ったばかりの人は、その背景が見えません。特に大企業から転職した場合には、なぜそんな不便な使い方をしているのか、ベストプラクティスと異なる使い方をしているのか、不思議に思うこともあるでしょう。まずはこれまでの背景を理解し、なぜそのようなことが行われたのか、その根本に迫りましょう。

1つの問題にとらわれすぎない

既存の構成を確認していくと、もう使われていない古いカスタマイズを見つけたりすることがあるでしょう。そういったカスタマイズがもう使用されていないことをいくら示しても、現状維持するよう主張する人は現れます。すべての障害に固執し問題を悪化させず、優先順位を降り直して、そこにエネルギーを注ぐことも時には重要です。

技術的負債への対応の優先順位を高める

これまでその場しのぎでテクノロジーを使ってきた場合、多くの改修項目があることでしょう。中には軽視できず迅速に解消しなければいけないこともあります。これまでSalesforceのエクスポートやExcelファイルを使って売上を管理したり、毎月、時間をかけて複数のマーケティングシステムからデータを手作業でマージしたり、レポーティングソリューションを購入せずに、オブジェクト結合に制限のあるCRMレポートで何とかしようとしているチームを多く見てきました。
RevOpsによるプロセス改善のインパクトを経営層に理解してもらうのは時に困難です。リーダーシップを説得する際は、積み上がった技術的負債への対処を先送りし続けた場合、どれくらいの機会損失となるかを計算し証明すると効果的です。

外注や担当者の追加採用を検討する‍

外注はいつもよくないというわけではありません。大規模なプロジェクトや、外部からの推進力が必要な場合は積極的に検討すると良いでしょう。

古いソリューションに執着しすぎない

既存のソリューションの限界を感じている方も多いでしょう。新しいものに切り替えるのは大変に見えますが、同時にテクノロジースタックを改善しないとスピーディーにビジネスを拡大する機能を失うことになりかねません。適切な判断ができるよう、随時検討していくことが必要です。

エンタープライズ企業の場合

エンタープライズ企業は、成熟したプロセスと多額の予算を持っています。とはいえ、「昔からそうだったから」という理由で非効率的なプロセスにしがみついたり、経験豊富な社員がすでに使っているシステムを採用することで、より革新的な中小ベンダーを見落としたりしがちです。既成概念にとらわれず、常に現状に挑戦する革新的なRevOpsテクノロジーのプロフェッショナルがいる企業は、市場の変化に迅速に適応することができます。

“Garbage in, Garbage out”の原則

マーケティングアトリビューション、売上フォーキャスト、顧客エンゲージメントツールなど、世の中には素晴らしいサービスが増えてきています。しかしながら、大きな組織でよく見られる大きな誤りの一つは、高価なツールを導入さえすれば既存のテクノロジーに統合され、これまで自社で得ていた情報よりも優れた情報を出力してくれると思い込んでいることです。実際にこれを実現するには、データの重複排除、統合、関連オブジェクトの紐づけなど、データ管理ツールに十分投資し、関連するすべてのツール間でデータが完全に統合されている必要があります。これには多くの時間とスキルが必要ですが、正しいインサイトを得るためには必要不可欠です。
広告費やWebの行動データなど、企業と個人のデータを関連付ける方法（特にB2B組織の場合）が備わっていないマーケティング分析ツールを利用すると（特に高価なものを使っていれば）結果的にコストが無駄になります。また、CRMユーザーの活用度も重要ですです。システムが使いにくかったり（検証ルールが多すぎたり、フィールドが散在してい たり、プロセスフローが不便だったり）、管理職がCRMの利用を徹底していなかったり、 報酬体系にCRMの利用を求める要素がなかったりすると、CRMの利用率は低くなります。機械学習を活用した高価な売上フォーキャストツールを導入しても、営業チームがCRMに正しくデータを入力しなければ価値を発揮しません。

データ基盤の検討

これまではCRMの導入をしっかりできればOKでした。しかし、すべてのシステムのすべてのフィールドをCRMに繋げる意味はありません。営業チームは、あるキャンペーンにどれだけのデジタル広告費が使われたかなんて気にしないでしょうし、カスタマーサクセスチームは、販促物が納期通りに届いたかどうかは気にしないでしょう。一方で部門間で統合するべきデータも多くあります。あらゆる部門のユーザーを1つのシステムで管理し、すべてのデータを一箇所に集約することを強制することがあります。データレイクやデータウェアハウスを活用し、データ変換レイヤーを持つことで、システム管理者、データアナリスト、エンドユーザーは非常に楽にデータを活用できるようになります。

‍データ定義の標準化

一貫性のないデータ定義は大きな問題を引き起こす可能性があります。例えば、マーケティングと営業が、同じ指標について異なるデータを持ち出し喧嘩するなんてこともあるでしょう。定義を標準化し、レポーティングを一元化することで、重要なインサイトを分析できるようになります。

レポーティングの役割を全て外出しにしない

レポーティングはシステムが大きく関わる領域であり、どの部門がオーナーシップを取るかは非常に悩ましい問題です。IT部門にレポーティングを集中させると、ビジネスサイドではデータの正規化するために何百行ものSQLコードを書く必要がなくなります。しかし欠点もあり、新しいシステムを追加するたびに、システム間の連携に何週間も待たなければなりませんでした。CRMやMAの修正には、複数のチーム間での細かな調整が必要でした。
レポーティングを専門に行うビジネスインテリジェンスチームがあれば理想的ではありますが、ビジネスサイドの誰もがこの領域の専門家になることは不可能です。BIチームがビジネスサイド専用の担当者を置き、ビジネスプロセスと状況を学びながら進めるか、ビジネス側のチームのアナリストがデータを調査できるようにする必要があります。できれば後者の方が、アドホックなニーズにも迅速に対応できるため、好ましいです。

いつシステムを切り替えるか

システムをビジネスに合わせて拡張するには各個人の努力や工夫が必要です。既存のシステムでまだ改善が図れるのか、どうしようもないためアップグレードするのか、その時期を見極めるのが難しくなります。システムを乗り換えるのはかなり大変ですが、ツールの定着度や活用度、実現したいことを実現できているかを評価し、他の選択肢を検討する価値もあります。

大企業が必ずしも優れているわけではない

大企業では、大きな組織がいかに現状維持に甘んじてしまうかがよくわかります。市場シェアが大きく、自分たちのビジネスが利益を生んでいるのであれば、既存の顧客層に受け入れられるかわからないような変化を起こすよりも、現状の路線を維持する方が簡単です。
同じことが大手テクノロジーベンダーにも言えます。継続的なイノベーションで知られるベンダーもありますが、ほとんどの企業はそうとは言えません。小規模なベンダーはピボットが容易ですし、他社と協業することで独自性を見出すことに積極的なため、新たな問題を解決するソリューションを生み出しやすいです。時には積極的に柔軟な思考をすることも必要かもしれません。

まとめ

企業のフェーズに応じてRevOpsに求められる役割が変わってきますし、立ち向かうべき問題も異なってきます。それを理解したうえで自らに求められるものがなにかを考えながら業務を進めていければ、ビジネスやチームへの貢献が進み、信頼されるRevOpsとしての立ち位置を確立できるでしょう。