まずはSalesforceを手放してみる〜BizOpsの思考法〜
この記事はBizOpsアドベントカレンダー 25日目クリスマスの記事です。前回は株式会社hacomonoの上村さんによる「オペレーショナル・エクセレンス of BizOpsチームのカルチャーづくり」でした。
はじめまして。ナレッジワークの澤と申します。
この記事では、ビジネスプロセスを再構築していく過程で、私がどのような視点で物事を見て、仕事をつくっていくかについて書いていきたいと思います。特にその過程の背景にある、BizOpsの思考法に焦点を当てて解説していきます。
先に大まかな道筋を書いておくと、「ビジネスサイドにおける生産性の解像度をいかに上げるか」が一つの肝だと思っています。
※長文なので、「思考法まとめ」の欄だけでも見てってください
簡単に自己紹介
2023年の7月から株式会社ナレッジワークというセールスイネーブルメントのsaasを提供する会社のBizDevチームでBizOpsっぽい動きをしています。
本記事は、「生産性」が一つのキーになるのですが、私は前職から長らく販売組織の生産性向上に取り組んでいます。
きっかけは前職の上長に徹底的に仕込まれたことですが、2019年から営業生産性についてひたすらに考え動き回りながら、まあまあの失敗とささやかな成功の経験を積んできました。
前職もSaaSのスタートアップで働いており、経歴としては、
セールスのマネジメント（SMB〜Enterprise）
ISのマネジメント（SDR〜BDR）
マーケのマネジメント（広告とサービスサイト以外全部）
CS企画
ビジネスサイドを横断したBPR（business process reenginiering）の部門の立ち上げ・管掌
現職ではBizDev（BizOps）
とかなり幅広く携わりました。
現場マネージャーとしての実践（マーケ、IS、セールス）と、企画サイドとしての実行（BPR、BizOps）の両面から関わってきたこの経験が皆様の一助になればと思っております。
最後に経歴の補足ですが、ビジネスパーソンとしては現職が2社目です。
35歳まで職歴がなく、大学卒業後10年間お笑い芸人をやっていたというちょっと変わった経歴です。
芸人活動とビジネスの共通項は意外と多いので、いつかどこかにまとめていきたいです。
※以上のような経歴なので、本記事の有効射程はスタートアップです。射程外の有効性はわかりません。
思考法を整理する
先立って予告したように、わたしが考えるBizOpsとして仕事を作っていくキーは「ビジネスサイドにおける生産性の解像度を高めること」です。
以下3つの切り口で、ビジネスサイドの生産性の解像度を上げ、どう関わっていくかを整理していきます。
原理原則
実践
メタルール
さっそく原理原則から見ていきたいと思います。
原理原則 1:生産性を分解する
BizOpsの主なミッションは生産性の向上です。
一般的には、生産性は「生産量/投下コスト」という式で表されます。
この定義をBizOpsの観点で再解釈すると、
顧客体験の最大化 × スループットの最大化
こんな切り口になると考えています。
ここで一つポイントになる考えが、過去にXでPOSTもしているんすが、
師匠（と勝手に思っている方）の影響もあって、2019年位から販売組織の生産性をどう上げるかをずっと考えている。
— 澤 遼平 / ナレッジワーク (@tenplaza1212) October 29, 2023
そして生産性って言葉にすると、どうしてもリソースやコストの削減がイメージされるんだけど、まずは生産量の最大化から考えるべきだと思っている。すなわち顧客体験の最大化が1st issue
ビジネスサイドの生産性を考える際には、生産量＝顧客体験の最大化が1st issueだということです。
生産量がないチームが生産性の向上を目指すのはナンセンスです。
さらに、生産性は簡単に「ハック」することができるため、生産量を増やさずに生産性を追求するのは危険です。そのため、生産量が少ない組織は、まずどのように量を増やすかを考えるべきです。
そして、これは言うまでもないですが、顧客体験を損なうようなコスト削減は避けるべきです。
投下コストに関しても、スループットの最大化と角度を変えて捉えるようにしています。
顧客体験とスループットの最大化、
これを追求することがBizOpsのミッションだと考えています。
原理原則 2：「戦略実行」の視野を広げる
BizOpsの重要な役割の一つは、戦略を具体的な実行に落とし込むことだと言われています。
この定義についてはわたしも同意見なのですが、ではビジネスサイドでの「実行」とは具体的に何を指すのでしょうか。わたしはこれを「コミュニケーション施策の実行」と定義します。
販売組織は、戦略によって規定された方法で、顧客に価値を届けるために「コミュニケーション施策の実行」を行います。
戦略 > BizOpsの仕事 >コミュニケーション施策 > 顧客
このプロセスの中で、顧客体験の最大化とスループットの最大化を目指すのがBizOpsの仕事なわけですが、体験と伝達の最大化を目指した際のプロセスの階層を、わたしは以下のように整理しています。
定められた戦略を実行に移すために、それを支える組織を構築し、その上で仕組みやルールを施行し、最終的にコミュニケーション施策を実行する。
戦略を実行まで落とし込み、顧客体験の最大化とスループットの最大化を目指すのであれば、仕組み化やルールの選定だけではなく、組織化まで足を踏み込む必要があると考えています。
BizOpsの仕事の射程は、べき論で言うのであれば、ここまで伸ばすべきであるとわたしは考えています。
※これは勿論、組織ごとに、現時点でのケイパビリティのキャップがあるため、組織に規定された戦略、の指針に従った組織化です
原理原則 3：Salesforceを手放してみる
BizOpsのミッションは、顧客体験とスループットの最大化です。
一般に、BizOpsはテクノロジー重視の解決策を提供する役割として捉えられがちですが、わたしは全ての解決策が技術依存である必要はないと思っています。
というよりも、techこだわりすぎることで解決手段が限定されてしまう危惧もあります。
そもそも上であげている「組織化」はtechで解決策を実行する類のものではありません。
実際、オペレーション上の多くの課題は、プロセスの整備やルールの施行などの非テック的手段で解決できることが多いように思います。
重要なのは、どのような状態を目指すかをまず明確にし、その後に手段を検討することです。この順序が逆になると、選択肢が狭まり、根本的な解決への道を見失うリスクが高まります。
もちろん手法に関する引き出しが少ないと、最終的な落とし込みがチープになる可能性もあります。
具体のhowに関する情報収集や学習を進めつつ、施策実行の際はhowを一度手放す。そんなイメージが広い打ち手を呼び込むと考えています。
例えばSalesforceはとても強力なソリューションですが、Salesforceありきで考えるのではなく、オペレーションのあるべき姿をイメージした上で、必要であれば迷わず使う。
言うまでもなく、使い方にも濃淡があるので、人の力、ルールの力、ツールの力などを組み合わせて、あるべき姿に近づける。そんな業務の設計が大事だと考えています。
原理原則の整理
BizOpsの思考法について、3つの原理原則をまとめてみました。
以下のように整理します。
これらの原則に基づいて、もう少し具体的な思考法を探り、その解像度を高めていきたいと思います。
特に、「顧客体験の最大化」と「スループットの最大化」という二つの目標の達成方法に焦点を当てます。
理想的には、これらの目標をツリー状に分解し、実践的な観点から具体的なアプローチを導き出せれば良かったんですが、BizOpsの視点という縛りがあるせいか「どっちにも効く」ものが多くなりました。
実践 step 1:専任性を見極める
専任制を見極め、正しい人に正しい仕事をしてもらう。これが1st stepだと考えています。
別の言い方をすると、販売組織のユニットごとの役割を明確にし、コア業務とノンコア業務を切り分ける、と言えるかもしれません。
これによって、顧客体験の最大化とスループットの最大化を目指します。
専任制というと「やる業務」に焦点が当たりがちですが、やらない業務を定義することも大事です。
何をやり、何をやらないか。を明確にする。
業務範囲を明確にすることで、専任性を高めるわけですが、それと同時に、組織自体を役割に応じて区切ることで、専任性の高まりは加速されると感じています。
言うまでもなく、「The Model」はこの考え方の一つの大きな潮流だと思います。
ただあくまでも「The Model」は一つのモデルでしかないので、各組織での戦略の実行、またはコミュニケーション施策の最適化から鑑みられたモデルの創出が必要です。
だから、場合によっては組織の分化ではなく、融化が解になることもあるかと思います。
では、その「役割」を切り分けるための判断軸はなんなのか？これは「どの顧客に」「なんの価値を届けるか」です。
故に、顧客の明確化や大まかな個別化の推進もこの観点の裏側には潜んでいます。
実践 step2:Pathを設計する
専任性を高め、ファンクションを分けることで、ファンクション間をつなぐpathが生まれます。ここで重要なのは、これらのpathが適切に設計されていないと、ファンクション内でのサイロ化やKPIのハックが発生し、専任制のメリットが活かされなくなることです。
これはthe model関連の議論で散々こすり尽くされているかと思います。また、顧客体験とスループットを最大化するという観点でも大きなボトルネックになることがイメージしやすいと思います。
故に、ファンクションを分けることで生じたpathを上手く設計する必要があります。「思考法」の観点で整理をすると「pathを逆用すること」が有効だと考えています。
Pathが増えることで品質が低下するとよく言われますが、これは単にpathの数が問題ではなく、pathの品質、つまり設計が鍵となります。pathに対して摩擦として抗うのではなく、pathの存在を意識した上でプロセスを設計することが重要です。
例えば、Pathによって「体験」が毀損する可能性があるのであれば、毀損していないものしか通さない設計にすればいいわけです。
別の見方をすると、pathがなければ可視化出来なかったものを、pathを通すことで可視化して管理をする。
この設計によってPathは工場でいいうところの品質管理のプロセスに当てることが出来るはずです。
次のプロセスに進める品質をクリアできているのか否か。できていなのだとすればそれはなぜなのか。
このようなpathに対する設計思考によって、品質に対するフィードバックループがより効果的に機能すると考えています。
実践 step2.5 専任制とpathは表裏一体
2.5の出現によって、文字数どこまで行くんじゃい、という様相を帯びてきましたが、もう少し続けます。
Pathを上手に立てつけて専任性を切り分けても、しっかり観測しているうちにどうしても上手く回らないということが表出することは多々あります。
その場合は、pathの設計ではなく、専任制の設計の問題なので融化させる、あるいはもっと分けるなどを実行するのが良いと思います。
なので作ったら作りっぱなしではなく、しっかり観測することが大事です。
そして専任制の設計もpathの設計も顧客に正しい価値をよどみなく届けることが目的です。
届けたい顧客像の明確化、そしてその顧客にどんな価値を届けたいか、そしてそこから逆算して「輸送手段」を考えるのが肝だと感じています。
例えば、新鮮な高級果実を届けるのか、大量生産された加工肉を届けるのか、届けるものによって「輸送手段」は大きくかわります。
「何」を「どう」届けるのかをしっかり理解した上で、届けたいものが腐ったりなくなったりしないように、「輸送手段」を考えていく。
専任制とpathの設計に関してこのあたりの観点はとても効いてくると実感しています。
実践 step3:平準を育てる
ファンクションとその間の整合性が確立されたので、次にファンクションごとの実行へと話が移ります。
専任性を高め、スループットを拡大するために、ツールの利用方法や手順書、ルールの作成などによる業務プロセスの平準化を進めます。
まさにBizOpsの本領というべき箇所ですが、ここで重要なのは平準化を単に完遂させることではなく、平準を育てていくという指向性です。
平準は単なる「箱」ではなく、「土台」として捉えるべきです。
平準化は箱の中に閉じ込めてオペレーションやルールを遂行させるものではなく、一定の品質を保証する基盤を提供します。
箱に閉じ込めてしまう行為は、個の創造性による跳躍を封じます。
対象的に、平準を土台であると定義し、一定の品質を担保した上で、試行錯誤によるアウトプットを推奨することで、平準自体が強化される機会を作ります。
足場がないカオスな状態では、跳躍先もカオスとなります。結果カオスが増殖し、オペレーションの崩壊に近づきます。
しかし、しっかりした基盤があれば、次のステップへの評価が可能になります。高いのか低いのか美しいのか汚いのか。
新しい足場を評価し、平準化に適しているかを判断することで、平準を育成し、オペレーションをブラッシュアップすることができます。
もっと言うと、個人的には、場合によって足場自体をひっくり返したっていいと思っています。
確固たる基盤があるからこそ、「この基盤を覆す理由はこうだ」という新しい動きが生まれるのです。根拠なき変革は避けるべきですが、適切な根拠があれば、基盤を覆すことも大切です。
より高い専任性を創出するために、平準化があくまで足場であることを合意しより強固な専任性を築くために、帰納的にアイディアを集結する。
平準化は専任性を殺すものではなく、高めるものであることを握ることによってより組織が強固になると感じています。
また、挑戦を推奨することで、「確立された平準は本当に最適か」という観点からのフィードバックも促されます。
あなたの平準は、あなたにとっての平準でしかない。
プロセス設計をする上では、これを肝に銘じた上で常に臨んでいきたいです。
昔こんなの書きました
実践 step 4:品質を定める
平準化された業務プロセス（対顧客・対社内両方）の裏側には、それの良し悪しを評価する「品質」という基準があります。
さて、では品質とはなんなのでしょう？
引用します。
品質は誰かにとっての価値である。
つまり、闇雲に「品質」を歌い磨き上げたところで、それが本当の品質なのかは定かではありません。誰か=顧客が何を要求しているのかをキャッチした上で品質を定める必要があります。
定めた基準に対して、毀損しているのか、満たしているのか、超えているのかを判断されたものが、品質の質です。
もう一歩踏み込むと、顧客に対して高い品質を「高い品質」として受け取ってもらうには、品質の基準に対する顧客との合意が必要です。
我々が定めた「高い品質」が顧客にとって「低い品質」であればそれは低い品質なのです。顧客と提供者の間にも基準が必要になってきます。
ゆえにサービスレベルを定めて、顧客と握ること=SLA（Service Level Agreement）の設計が必要です。
SLAの設計が顧客体験の最大化に寄与することはイメージしやすいかと思います。またSLAは、いわゆる「顧客の言いなり」を回避する強い武器にもなります。SLAを定め顧客と合意することで適切なサービスの提供と、ときに必要なNOをのカードを持つことが可能になります。
さらに、SLAを基盤としてSLO（Service Level Objective：サービスレベル目標）を効果的に設計し、これらの目標を達成することにより、顧客体験を大きく高めることができます。SLOは、サービスの品質とパフォーマンスの具体的な基準を示すものであり、これによりサービス提供者は顧客の期待を正確に把握し、それを超えるサービスを提供するための具体的な目標を持つことができます。
このプロセスを通じて、顧客の驚きや感動を引き出す「wow!」の瞬間を創出し、顧客満足度を向上させるとともに、長期的な顧客関係の構築に寄与します。
これは対顧客だけではなく、対社内にも有効です。
そして、SLAの設計は顧客体験の最大化だけではなく、スループットの最大化にも効果的です。
SLAが明確に定められていない状況では、path間のコミュニケーション（対顧客・対社内を問わず）で期待値のズレが生じやすくなります。
この期待値のズレはエラーの原因となり、単なる一回のミスを超えて、非線形的に拡大し、大きな問題（例えばクレーム対応など）を引き起こす可能性があります。
SLAの明確な設計は、このような期待値のズレとそれに伴うエラーを防ぐことにより、効率的でスムーズな運営を可能にし、結果として組織全体のスループットを最大化します。
定められたサービスレベルに対して合意形成した上で、実行することは顧客体験だけではなく、スループットの最大化にも寄与します
実践 step 5:非線形的コストを討ち取る
KPIに載せづらい非線形的なコストに目を向けることは、業務を構築していく上で見過ごされがちですが、大切な観点だと感じています。これらのコストは、業務プロセスの効率や生産性に大きく影響を与え、組織のパフォーマンスに直接作用します。
大きく6つのコストとそれに対する4つの打ち手の観点で整理してみます。
communication cost（コミュニケーションに関するコスト）
Interruption cost（業務中断によるコスト）
Waiting Time Cost（プロセス間の中断によるコスト）
ignition cost（プロセスがスタートするタイミングでかかるコスト）
Rework Cost（手戻りやエラーによって起こる再実行のコスト）
Learning/Training Cost（業務を実行する技術を習得するコスト）
これらのコストは深く掘り下げることもできるんですが、今回は大まかに理解にとどめます（というか力尽きました）。例えば、Slackのメンションが多すぎる、承認ルートが不明瞭、同じ問い合わせが繰り返される、多くの工数を要する依頼プロセスなど、可視化しづらい「隠れた負債」がこれらに含まれます。
それぞれのカテゴリに対する具体的な対策は次のようになります。
コミュニケーションの効率化→communication cost
割り込み業務の削減:→Interruption cost、Waiting Time Cost
フローベースのプロセス最適化→ ignition cost、Rework Cost
スキル向上とナレッジ共有の促進→ Learning/Training Cost
これらの対策は、適切なコミュニケーションチャネルの設計、CRMを活用した情報の集約、SFAなどによる自動化やプロセスの可視化、Pathの数や質の見直し、エラーの可視化、適切なナレッジ管理などによって達成できます。
最後はかなり具体の業務レベルまでおり、いわゆるBizOpsっぽい業務の捌きっぽい話になりました。
以上が、5つの実践的思考法でした。
最後にメタルールを見ていきたいと思います。
2つのメタルール
メタルールに関しては文中に何度も登場しているものを抜き出しています。ルールは2つで、
常に顧客視点であること
観察し反応し続ける体制を作ること
「顧客視点であること」に関しては本文中で掘り下げてきたので、ここでは「観察し反応し続ける体制を作ること」に焦点を当てます。
たとえプロセスが精緻に組み立てられていても、観測の効かないプロセスはいつかもろく崩れ去ります。
重要なのは、プロセス自体の強固さよりも、観測とそれに基づくフィードバック設計の強固さです。
故に、これまで見てきたあらゆるファンクションに対して観察可能な体制を構築することは、BizOpsのメタルールとなります。
このアプローチの目的は、組織の自律性を確保することにあります。効果的なフィードバックループの実現によって、組織の各ファンクションは変化に柔軟に対応する能力を獲得できます。
戦略、組織、仕組み、コミュニケーション施策に対するフィードバックを含む、全方位的なフィードバックシステムの構築。
速いスピードで正しいデータがフィードバックされることで、組織の意思決定のスピードを早めます。これは言うまでもなくスループットの最大化に寄与しますし、狭義のBizOpsの腕の見せ所の一つだと思います。
また、観測は以下のように細部に渡って実行されます。
結果だけでなくプロセスの観測
線形的な指標だけではなく、非線形的な事象の観測
発生したエラーの観測
数値化できない肌感覚の観測
結果指標や線形的指標以外の状態を観測できる状況の構築で、「上手くいっているから、上手くいっているのだ」という思考停止を避け潜在的な危機を事前に察知することが可能になります。
実践的思考の実装と観測の統合によって、販売組織は自律性と柔軟性を獲得した活きたチームとなります。
顧客に価値を提供するという目的から逆算されたビジネス組織の実行は、観測に基づくフィードバックループによって完成されると考えています。
思考法のまとめ
ざっくりスライドでまとめます
文章のまとめ
とりあえず吐き出しきりました。
色々つっこみはあるかと思いますが、現時点での見ている景色を余すことなく書いてみました。
こういう機会がないと絶対挫折していたので、運営の皆様、チャンスを頂き本当にありがとうございます。
いろいろ言いましたが、現職では2割も出来ていないです。
転職し半年ですが、もっとも大切なのは、対象とする組織に合わせることであると改めて感じています。
組織をより有機的に稼働させるため、組織の中の血管に血を通わせる。
過去の経験を元に大上段からナタを振るうのではなく、組織に合わせた問診を繰り返すことで、顧客や社内の色々な人や業務を理解する。その上でより良くするために手を打つ。これによって初めてオペレーションが機能するという実感が強まりました（東洋医学っぽいですね）。
コミュニケーションがめちゃくちゃ大事。
また、新しい環境に飛び込んでみて感じたのは、とはいえ業務プロセスや顧客や組織を理解するのはなかなか骨が折れるということ。
骨が折れるからやらない、という結論ではもちろんなく、ビジネスオペレーションの最適化には、現場の感覚や顧客の理解が深い実務者とオペレーションに関するナレッジのある企画者のバディ制がもっとも早く成果が上がり、強力なソリューションを生むのではないかと感じました。
如何に共創するか、共創を促すディレクションをするか、こんな観点も大事になってくる印象です。
最後に
ナレッジワークでは仲間を募集しています。
2023年末現在だと、もっとゴリゴリsalesforce周りを改修する必要があるので、salesforce adminの知見を持った方を大大大大大募集中です。
また今回大風呂敷を広げましたが、皆様からフィードバックいただき知見を広げていければと思っています。情報交換などさせてください。
この記事が気に入ったらサポートをしてみませんか？