(Q&A)出版記念パーティでいただいた質問への回答集
普段は自分で勝手に問いを立てては、自分で長々と考察を述べる、という狂気じみたTwitterの運用をしています。
有難いことに先日の出版記念パーティでは多くの質問を頂戴できました。当日は時間の関係で1-2問しか拾えずでしたので、こちらで回答させて頂きます。
全体としてはとても長くなると思いますので、以下の目次より、お好みの質問と回答だけご覧ください。
また、これを機にQuerie.meを開設してみました。ゆるく質問を受け付けていこうと思います。今回は、その回答のデモンストレーションも兼ねてご覧ください。
Salesforce管理者の実務本である書籍「成果を生み出すためのSalesforce運用ガイド」の方も発売中です。合わせてよろしくお願いします。
Q.佐伯さん、Xの長文ポストに、いつもなにか狙って時間を投下されているはず。ポストされるとき大事にされていることは？
時間投下や仕事上の狙いという感覚はあまりなく、ライフワークですね。
苦も無く続けられる努力(?)というか趣味、を見つけたぞ！と自分でもびっくりしました。 朝のコーヒータイムとか、おやつタイムの楽しみに書いてます。 狙いという意味では、いくつか利点を兼ねて今の形になっています。
点を打っておく
大人になって社会経験を積むと点が繋がる、みたいな話はよく聞きますよね。
これは明確に目的に対して志向せずとも、何か予め考えたり勉強したことが、後々になって目的を助けるという構造が人生にはあるということだと思います。英語とかそういうソフトスキルは備えてる人が多くて素晴らしいなと思いますが、何かといざやるべき時に準備しはじめると、中々しんどい訳です。急に滑らない話をしてくれと言われても出来ないですしね。(準備しても出来ませんが・・・)
考えておく、頭に入れておくだけでもいいのですが、大体の場合は人に伝えたり言葉にしたりするのが重要になってしまうことが人生経験上わかっているので、文字で思考の下書きを残しておくのがよさそうだと思いました。いつか足しになるといいなとは考えています。
悩む人に貢献したい
人の課題に対して何か貢献するのが割と生きがいです。
過去のどの仕事にもその側面があったと思います。なので、日常で自分の経験や、人の様子などみて、”これはよくある課題や悩みな気がする”と思ったら拾って集めておこうと思いました。ちなみにXに載せる系じゃないですが、妻の体験談とかも一々メモってたりします。記録しておくのが重要です。
手元のメモでもいいのですが、Xに書くことで、品質が10点から50点くらいには上がります。手元のメモがパジャマ状態だとすると、Xに書くとコンビニに行ける格好ぐらいになります。人の目があるので。
よくある課題や悩みを拾ったら問いの形にしておくのがお勧めです。これをやっておくと、引き出しの取っ手が掴みやすくなります。
ポジションの発見と理解の練習
"問い"には強い結論を書かずに、複数のポジションとそれぞれの言い分を書くようにしています。複数人の言い分を併記するようなもので、そんなことをしてると、勝手に長くなります。
長文書く練習が必要かどうかは人によりますが、そんな人にはお勧めです。僕は学生もやっているので800文字とか2000文字のレポートが死ぬほどラクです。文字通り朝飯前です。顧客や上司などレビュワーのいる仕事をしている人はセルフチェックの練習にもなりますね。
本来、問いと結論のセットが短文でパンチラインになってる方がTwitter投稿としては面白いと思います。ただ、僕の場合は悩んでる人に答えを渡す仕事をしてる訳ではなくて考える支援をしてたりするので、ポジションを簡単に取らないよう気をつけています。
ポジションを取る場合は、その後にエビデンス並べて補強すれば良いのですが、取れるポジションがいくつあるかな・・・というのを考えておくと、相談された時に相手の望むポジションに合わせられます。その上で、僕も人間なので好みもありますし「正直こういうポジション取る人は合わないな・・・」みたいなものもあるので自分の個人的意見(当時のポジション)を書くこともあります。その場合は、”僕はこう思います”とか”僕はこう考えて行動したいと思います”みたいにしてます。
Q.”ビジネスプロセス”の定義にいつも迷います。ビジネスプロセスを外れるところ、境界はどこだと思いますか？
言葉の定義というよりも、プロセスを概念的にどう区切るかが難しいという話ですよね。
プロセスは全体を分解したものなので、何事も何らかのプロセスに入ってると考えますが、現実的にはどこか重点プロセスを置いて検討したいと思っているのだと思いますので、キリがなくなっちゃいますよね。その意味で、境界の設定は難しいです。
言葉遊びは絶対したくないのですが、基本的な考えとして、プロセスと作業手順を混同する人は多いので注意を払っています。
作業手順は作業結果が状態や成果物などアウトプットという詳細レベルのもの。ここをプロセスとして捉えてしまっても、大概は効果は時間削減にしかなりません。
売上や利益の基になるビジネス上の価値(アウトカム)が出てくる単位がプロセスとしておきます。アウトカムとかバリューとかいうとややこしいので、利益から売上や原価、と因数分解していった数値(SFAでお馴染みの商談数とか受注数みたいなやつとか、返品数とかでもいいいです)の何らかにプロセスの方が手順よりは大きい概念です。業務やITを含むオペレーションレベルの抽象度ではなくビジネスレイヤーのレベル感で捉えるという感じです。
プロセスを仮に捉えたとして、As-Isを考える時、や、ITツールの適用を前提にTo-Beを考える時などは分析が具体化しすぎて、手順で仕事を見てしまいがちな気がします。最終的にはオペレーションレベルまで解像度が高いのはいいことなのですが、プロセスが非生産的なまま手順の最適化を進めても早くすることしか出来ないので、改善は確実に進んでいるのにROIにヒットしないというジレンマに陥ります。(RPAで煩雑な事務処理を捌く場合にやるのは手順の可視化ですものね)
また、プロセスレベルで切らないと、仮に全体の生産性があがっても、その改善にあたったり個別のプロセスで望ましい活躍してくれているプレイヤーを定量的にも評価出来ませんので後々組織編成や人事評価上困ることになるので気をつけます。(The Model本にも書いてある通り、型をつくるのは大事ですが定量だけで評価しません。とはいえ定量は評価の後ろ盾になります)
境界の話がありましたね。
課題を広く捉えすぎないのも大事ですよね。僕のキャリアがまさにそうでしたが、直接管掌しておらず手の届かないプロセスの課題や解決策が気になったりします。やはり、境界は自身の現実的に管掌できる範囲、または管掌者を巻き込めている範囲とするのが良いと思います。実際にはもっと広くあるべきだとしてもです。
その上で、課題をたとえば受注や何やら、関与可能なもので、全社的にも関心の高いものに設定します。そこだけじゃ課題が解決しないのは見えてるけれど、全体的な課題に向かうために、足元を片付けようと動き、上層部にレポートします。新たな境界部分に課題があることの認識がとれてくるので、その上で新たに隣のプロセスの責任者も巻き込んで、全体的な課題をより明らかにするみたいな段階設計が重要に思います。人も組織も生き物なのであくまで一例です。
Q.佐伯さんがジェネラリストとしてベンチマークしている方はいますか？
尊敬している人が何人かいます。ジェネラリストを尊敬してるというよりは、尊敬してる人にはジェネラルな側面があるなという感じです。なのでベンチマークしてそこ目指そう、という感じではなかったりします。
具体の名前は控えておきますが、これまで所属した会社には1人はそういう人がいました。バックグラウンドも役割も違かったので、その人そのものになりたい訳ではないですが参考にしたり、一部真似たりはしました。
あと、僕が最初に企業したリゾルバという会社のメンバーは全員何らかの課題に対するジェネラリストで構成し各クライアントの支援にあたってもらっていました。全員僕を超えた部分が必ずあり尊敬してます。
ジェネラリストを尊敬してますし、構造上、不足感も重要性も増していく存在だというのは先日の講演の通りの理由で考えているわけですが、だからジェネラリストを目掛けている、という訳ではなく後述する目的志向性のある人は結果的にジェネラリストにならざるを得ないのだという理解です。
ジェネラリストを少し分解して考えてみた
ジェネラル、について少し考えてみると、本当の意味で何でもできちゃうジェネラルな人なんてのは基本いない訳で、全知全能を指すのはナンセンスとして、大きく２つに分けて考えてます。
1.マルチスキル
→仕事に必要なスキルを、専門分野に加えて複数領域バックグラウンドとして持っている(営業と技術とか、デザインとマーケティングとか、CRMとERPとか)
2.ボーダレス、目的志向
→仕事の担当領域や部署に関わらず、目的志向で課題や必要な取り組みがあれば、それに向き合って対処できる人(自身の主業務は及第点に載せた上で”加えて”できる)
1.がスキル面でジェネラリストになる素養、2.がマインドセット面でジェネラリストになる素養です。
2があった上で1があり、仕事をすると結果的に強いジェネラリストが生まれるイメージです。
一般的には1がジェネラリストとか、もしくは何でも屋とか器用貧乏と言われるものの実体に近いと思います。
機能しリスペクトされるジェネラリストというのは2の素養が必要なのだと考えています。
元々の質問に戻ると、
尊敬する皆さんは多くいるのですが、取り組まれている仕事、つまり社会的な課題が異なっていたりします。そのため、目的自体が異なっており、そこに必要なマルチスキルが異なってきます。そのため、ベンチマークにはしてませんが、参考にしつつ自分自身の目的に対して可能な限りあらゆる手段をつくしたいなと思っており、その過程でジェネラルになっていくと思っています。
Q.佐伯さんにとってSalesforceはどういう存在ですか？
“選択肢”の一つです。ただ、”選択肢”と表現すると軽んじられる風潮については反対です。
複雑で包括的な課題に対して、一連の解決策を持つような、選択肢として成立する手段というのは今の時代多くありませんので、選択肢自体が貴重です。
どういうことか少し図解します。
ビジネスは目的から実現のための戦略から実行まで裾野の広い活動、その継続で成り立ってる訳で、これらの活動は繋がらないと成果がでない訳です。
戦略に紐づかない活動は無駄になる可能性がありますし、戦略だけあっても絵に描いた餅です。
ただし、実際のところ戦術の要素やその実行にはITの活用が不可欠な時代になっており、異なる技術や素養の求められるITツール群を扱う際には外部のベンダーと組むケースが一般的に存在します。
ただ、こうなると、事業を営んでいる会社側からすると、ITは手段であり選択肢なので、何でもいい、という心理が自然と発生します。
これ自体は、市場競争的にもそうあるべきだとは思います。
ただ、最終的には企業の目的と整合する形で、戦略から実行までがつながる必要がある訳です。
そして手段、つまりツールが異なると、"流派が異なる"みたいなことが起きる訳です。同じ空手でも茶道でも、流派が異なれば背景や想定するシーンに違いが出てきます。
これを踏まえるとやはり企業側が手段を選ぶにしても、自社に合うかどうか、自社を手段に合わせられるだろうか、という検討が必要です。
そして手段となるITツールには多数の分野があり、分野ごとに多数の製品もあり、組み合わせは無限大です。
無限の組み合わせから目先のコスト最適で選び合わせると流派のことなるITを武装することになります。スーツ姿にサンダルとキャップをかぶってるような感じです。
個々のツールがソリューションなのではなく、ツール同士やツールと業務オペレーションがつながった姿がソリューションに近づいていく訳なので、一貫した流派で、ビジネス課題のほぼ全体像を包み込める一連のソリューション、という意味ではSalesforceの活用は数少ない選択肢だと思います。
質問に戻ると、キャリアとしてのSalesforceとか色々回答の切り口あるのですが今回はこういう切り口で勘弁を。
Salesforce社退職時にまとめたnoteを置いておきます。仕事場としてのSalesforce、製品としてのSalesforce、技術/キャリアとしてのSalesforceなどの切り口で書いてます。
Q.佐伯さんがSalesforceを使う中で失敗した経験はありますか？
“失敗”の定義のハードルが低すぎるからな気がしますが、あまりありません。
時間をかけすぎたとか、不要になって捨てたとか、振り返りとして思うことはありますが、そういう難しい局面が想定に含まれるステージというのは、前に進む価値の方が高いと思ってたりします。
あ、セキュリティとか不正データが大量に出来ちゃうとか事故には気をつけており、幸いなことに今のところ何もないですが、幸いなだけだと思っています。予防も大事ですし、発生した時に謝れるイメージをつけます。
但し、多くの間違いは組織の課題(人とかその連携とかルールとか他のシステムとか)で起きるように思いますので、例え何か失敗ぽいことが起きてもみんなの課題だと開き直って、むしろ改善のチャンスですね！と、うっかりこちらを責めてきそうな上長や他組織に言うぐらいの面の皮の厚さは持っていました。
最初はミスが怖かったですが、目線上げてしまえば、失敗が個人の責任で起きるようなことは少ないですし、全社に関わる仕事をしている訳ですから、失敗があったとしても会社全体の学びだと思います。良い課題を見つけたのに責められる謂れは、ありません。自己肯定感大事。
個人に起因するようなミスとか失敗が、重大な損失になるようなことがないようには注意しましょう。
今思い出しましたが一個ありました。
昔セミナーの申し込みページをVFで作って公開(Sites機能)したのですが、公開ページをhttpで出せてしまう時代がありまして、送信内容が暗号化されない平文で通信されるフォームを設置してしまったことがありました。
コンバージョンが入る前に、すぐに気づいて差し替えたのですが怖かったです。
Q.ジェネラリストに必要なことって何だと思いますか？
目的(≒課題)志向だと思います。
ジェネラリストが活躍する時代がくるという話はしましたが、そういうスキルを目指してきたこともないし、目指すというのも少し違う気がしています。ジェネラルさ、に含まれるスキルや知見は時代や場所で変わるためです。
目的志向があると、目的に向かうための構成要素をよく理解した上で、それらが良い具合に繋がらないことが気になってくるはずです。その場合に、視点を上げたり、低い視点のまま横に移動したりする必要があり、結果的にジェネラルになる、という構造があると思っています。
課題感やマインドセットが芽生えるということ、スキルが水平的になる、という点では対岸(売り手から買い手、社員から経営者など)または隣(マーケから営業、デリバリからCSなど)にいく、というキャリア戦略をとっていくのが強いジェネラリストになる意味ではおすすめです。
キャリアが点だと、色々と何でも出来ても価値が出にくい感じがします。
そういう場合は、後からでも、キャリアを抽象化して捉えて、それらが同時に必要になりそうな職業を目指すか、新しいキャリアを付け足して全体がつながるように意識するのが良いと思います。
ただ、僕はマルチスキル獲得の源泉として目的志向がないと、努力がしんどいでしょうし、複数スキル持ってても必要な場面でその強みを発揮しづらいと考えます。
Q.事業課題や組織課題を適切に吸い上げるプロセスについて、ポイントがあれば教えていただきたいです。※組織横断の部門を立ち上げてもなお、部門を適切に活かすのがなかなか難しいなと感じます
難しいですよね・・・どんな背景に置かれていらっしゃるのか伺ってみたいところです。タスクフォースやCoEや各種企画部署など横断の部門があるのは統合への課題認識を経営陣が持っているということだと思うのでそれ自体は大きなことですね。教えるなんて、おこがましいことは言えません。
が、2つほどポイントというか考え方があると思ってます。
一つは「吸い上げて考えない」という方向性です。
A,B,Cの事業または組織のどこかに課題がある場合も勿論あるものの、どこにも経営上重要なそれがないことが問題であったり、全体的にxxがない、という場合も多いからです。
経営視点または全体最適で考えた際に、各事業や組織からあがってくる課題の多くは死にはしない程度の、"抱えて進む問題"であったり、問題ではあるけど課題とは呼べない無視する問題だったりします。(現場的には切実なものも多いのであくまで客観論として)
また、恐らくですが部門を活かす、というお悩みの中には結局のところ
「組織構成や事業構成自体を変える必要があると思う」
「人事制度や評価制度も変えないと対処できない」
「そもそもの人材教育のレベルをあげたり、揃えないと施策が機能しないように感じる」といったものがあるのではないでしょうか？
こうした所には提言ができても裁量がないことも多く、できるところで改善の種を探そうとすると効き目の期待値の低い打ち手しか見つからないこともよくある話です。効き目の低い打ち手ばかりになると、数をこなす必要が出てきて、細かな改善をたくさんやることになるけれど、地味で大変な上に評価も得づらいというようなことになりがちです。
まとめると、全社的にインパクトのある課題を見つけることが課題、全社的な課題を進めるための課題(裁量や承認)のようなものがある、ということです。
もう一つは仮説のようなものですが「現状把握、"現状作成"に注力する」という方向性です。
前述の通り、吸い上げると経営視点だと課題ではないものが課題として検出されることも多くありますし、経営者のコメントからもそれが発生しますので中々厄介です。 向き合ってみた課題が課題じゃない可能性というのは案外多いように思います。
課題は本書にも書きましたが、単なる困りごとや問題と区別する必要があります。その際に拠り所になるのは、現状とゴール(未来)という基準です。このギャップを埋める際のインパクトの大きな要素が課題になります。
目指す”ゴール(未来)”は経営者が会社の意思として握っている場合が多く、また元々変動的/抽象性があるものですのである程度決め打ちで設定すれば良い訳です。ゴールは設定した日から動いていく感覚だけがあれば一旦OKです。
重要なのは、”現状”です。これは、既に具体的に存在し直近の過去については本来もう動きようがありませんので課題導出の足場としてはかなり重要です。もしここの可視化が十分されていないせいで、改善もままならなければ、抜本的な打ち手をどの方面で打てば良いか、も論理が構築できません。現状のより的確な把握、が課題なのではないか？という仮説は多くの現場に当てはまりました。
現状把握は考えてみると意外に難しいんです。
現状業務としてのプロセスや手順の可視化は手間はかかりますが文書化はできるでしょう、その結果数値も会計や販売管理システムなど下流方面であれば取れることも多いでしょう。
しかし、それをもって現状把握できているかというと、実際には会社の決めたルール通りに仕事をしていないケースも多くあります。その流動性が結果に影響を与えているとすると、原因と課題を定量的に拾うのは難しくなります。
例えば、過去から実施している効率性をあげるためのテンプレートの利用、手戻りを減らすチェックリストの運用、承認の運用といった現状業務が定義されていたとしても、実行者や管理者の業務負荷の問題で徹底しきれず形骸化していては仕事が増えているだけで効果が出ていない可能性があります。これらの業務が機能している前提で課題を考えると、不要な業務を捨てるのは難しいでしょう。
また、現状把握のための仕掛けとしてプロセスごとの数値入力が義務付けられているとしても月末や翌月に思い出して一括で入力したり、現場で都合良い数値に調整して入力されているようでは機能しません。課題が発見できなかったり誤った課題導出につながります。こう考えていくと、SFAの入力と管理の設計にも通ずる部分ですよね。現状把握と、把握が可能な現状業務を構築することが、組織の習慣なり文化をつくることでもあり、そもそもかなり難しいんです。
このように、課題と解決策のアーキテクチャに気を払うのも重要ですが、大事な足場となる、”現状業務”と”現状把握”のアーキテクチャにある課題を解決する方向性もあるのではないかと考えたりします。
まずは、"現状の業務"と捉えたものが変数として動いてしまわないように、きちんと最低限のルール・規律通りに運用させること、無理なら変えること。
ルール・規律通りに運用された上での現状数値を元にして、ゴールとのギャップで課題導出すること、これが大事な気がします。
課題に向き合う活動というのは地味で大変な仕事ですね・・・
Q.最初の1人のSalesforce管理者が、後に拡大するチームメンバーによる運用の為にやっておくべき重要な事ってどんなものがありますか？
やっておくべきことは多岐にわたるとは思いますが、強いていえば、"なるべく早くチームメンバーを迎える"だと思います。斜に構えた言い方になってしまい恐縮なのですが、本書でもチラと記載した意見に通じます。
できればDay1から、「明日チームメンバーが1人やってくる」、と考えて仕事をするのが意識としては良いと思います。そう考えると、後続のメンバーのために何をするか優先順位が思いつきやすいですし、それを考えるのが早ければ早いほど日々の活動の選択肢も絞られて収拾がつきやすくなります。
明日来る、と考えるとめちゃめちゃ困ると思いますが、そう考えると
「とりあえずありもので、あの辺の資料使って概要説明して、他には一旦何日からこの勉強してもらっておいて、歓迎ランチはあそこ連れて行ってその時に色々キャリアとかスキルとか探らせてもらってやってもらえそうなこと考えよう、あ、あととりあえずSalesforceログインできたらこの作業は簡単だし毎週ルーティン作業だから切り出してやってもらう、マニュアルはないから横について一回教えて作ってもらおう・・・週末は歓迎会開いて、上司のあの人とか、営業部のあの人とか連れてきて直接相談しにいける人増やしてもらおう、自分が多忙で構ってあげられる時間は少ないから、この辺みて学習計画とウェビナー参加予定立ててもらって、資格取得まではOJTということにしよう、その代わり週一はしっかり1on1しよう・・・」
などなど色々考えられると思うんです。
そう考えると、意外と準備しておくことって、あれば越したことないけどたくさんなくてもなんとかなりそうなんですよね。
自社のことを教えてくれる人は自分以外にもいますし、Salesforce自体のことを教えてくれる人は自分以外にもいます。
自社のSalesforceのことやその管理作業、今後のキャリアを教えるのが先輩の役目になると考えると、最初は自社やSalesforce自体の教えてもらい方をガイドしてあげて、その積み上がった理解の上で作業をいくつか任せて、作業を通じて積み上がった知識を使って、少しずづ大きな球の仕事をやってもらえばいいわけです。
"なるべく早くチームメンバーを迎える"が目標に入っていれば、初級者が手出しできるところを残した作業をしておこうとか、社内の関係性をつくっておこうとか、整理されてなくても履歴だけは残しておこうとか、そのために口頭の会話は極力やめて少なくともチャットには残しておくとか運用的な考慮もでてくると思います。
また、チームメンバーを迎えるにしても割り当て人数の価値観は各社様々です。業務が忙しく複雑化したあとに人を入れてもボトルネックで潰れてしまうので、早めにアラートをあげる必要があります。
アラートをあげてもペイしなければその判断はおりづらいので、Salesforceの役割をコスト削減系ではなく収益向上系に位置付けて管理人件費を予算に織り込んでもらうことを意識すべきです。
経営に口を出すのは気が引けるかもしれませんが、Salesforce管理者なくしてSalesforceは基盤になりません。管理者への投資がペイしないなら、Salesforceはコスト高です、解約した方がいいとも思います。
と、そんなことを言っても現実的ではないのかもしれないので、僕自身はSalesforceが価値あるシステムとして活用されることや、管理者の人材市場/人材流動性をつくることに貢献して、追い込まれる環境を減らしたいと思います。
Q.セールス/マーケの現場の解像度を高くするための手段として、実際にセールス/マーケを現場で経験するのはsalesforce管理者のキャリアとして得策でしょうか
端的すぎて恐縮ですが、とても得策だと思います。
ジェネラリスト関係の質問回答にも通じますが、隣や対岸のキャリアを持つことは横断的な役割を果たす人にとって重要です。疑似体験でもいいと思うのでおすすめです。管理者からするとユーザ側の体験は対岸にあたります。
一方で、Salesforceは戦略系のシステムの側面が強いシステムです。
販売管理等、下流の基幹系業務によるほど各企業ごとの事情が色濃くでて、自社が正解をよく知っている状態で、システムに対する要求もはっきりしてきますが、SFAやMAの活用、は多くの中小企業にとって初めての試みのことがあり、自社で正解を持っていません。
その場合、まずはSalesforce社のSalesforceの使い方、業務の仕方をサクセスナビやウェビナー、担当のAEさんからのレクチャーで把握して変革後のイメージを掴んでから、自社の営業業務等にDeepDiveすることで、気づきが豊富に得られると思います。
Q.Salesforceでやらない判断はどういうプロセス、どういう基準で決められますか？
これは難しい質問ですね。
システムに盛り込みたい機能とか要求が存在していて、それをSalesforce上で作るのか、他システムでつくるのか、あるいはシステム化しないのか、という話でしょうか。
基本的には、”論理的に必要な機能"を"物理的にはどのシステムでやるのか(人を含め)"というアロケーション(配置)の考え方になると思います。
この辺はアーキテクトコミュニティ等でもぜひ議論してみていただけると有意義かと思います。
書籍で語った範囲でいうと、
・システム化の期待効果がはっきりしなければ負債になるのでやらない、という話(第7章で触れた課題の扱い)
・ペースレイヤリングの考え方に基づいたアーキテクチャとSalesforceの位置付け(第8章)
あたりです。
Salesforceはいずれ大きくなるシステムなので、極力は個別最適な仕組みを細かく作らないようにします。特に主要なデータへのフロー等のレコードトリガでの書き込みや転記などの処理は他システムとも影響しますし、負債化しやすいので、作る場合はしっかりと設計ドキュメントをまとめます。この辺も7章の範囲です。
第８章のペースレイヤリングの話はやや難しいですが、
システムに求められる特性が３タイプに分けられるので、それごとに異なる場所に配置した方がよくない？みたいなのが趣旨です。
変化しすぎると監査的にも決算等の必須業務的にも怪しくなる業務と変化の激しいCRMシステムを同じ基盤にいれとくと、リスクは出てきます。
全部統合すれば分断のデメリットは避けられますが、統合したら統合したなりのデメリットがある訳です。
ざっくりいうと、Salesforceに向く、向かないはこういう感じだったりします。
一方で、Salesforce上に作るか、外部システムで持つか、のアロケーションは機能単位で見るとかなり迷う部分は各社ごとに出てくると思います。
会計システム自体をSalesforceで作ってしまうことは少ないとしても、会計システムで行う仕訳データの作成のうち、経費の一部やサブスク商品の一部だけはSalesforce側で作成した方が経理側の処理を効率化しやすそう、みたいな場合です。
こういう時は、その会社の現状からしてコストが低い方向性にアロケーションするのを基本としつつ、基本は選択の問題になるので、選択によるデメリットを明らかにすることが重要だと考えます。
上記の例だと、会計監査の際に仕訳データの元になっている取引やエビデンスが必要になりますので、それがSalesforceまで辿らないといけないことになる点はCFO等とようく打ち合わせて、要件を洗い出しておかないと、処理は回っても後で困ってくる、という事態になります。
最終的な答えに踏み込めず申し訳ないですが、こういう事情もあり
Salesforceは基幹に向かない、在庫管理は向かない、承認ワークフローは向かない、とか色々よく聞く訳ですが、必ずしも個別の事情を鑑みるとその限りではない訳です。
Q.サクセスナビは日本だけの情報ですか？
セールスフォース・ジャパン社公式の見解を僕が述べることは出来ないのでその点だけご了承いただいて、非公式な個人として見解を記載します。
元々、セールスフォースの日本法人独自の取り組みとして作られました。
チャネルとしては当時も今も日本独自のものと呼んで良いと思っています。コンテンツ自体は、実践的なものは日本のCS部隊の方が独自に作られたものもあるかもしれませんが、公式として出されているものなので、何らか本社にオリジンを持つナレッジであることが多いと思います。
各国ごとの施策は立ち上がっては本社管轄の取り組みと統合したり、連携したりということはこれまでもよくありましたので、今後または、現状すでになのか、がどうなるかは分かりません。
少し、補足をしておきます。
カスタマーサクセスの仕事は、マネージャという担当の方が人手で顧客と直接対応される取り組みもあれば(ハイタッチアプローチ)、ワークショップのような人手ですが一定の顧客を同時にサポートする取り組みもあれば(ロータッチ)、サクセスナビのようにWeb等デジタル接点で特定多数または不特定多数への発信によってサポートする取り組みもあります(テックタッチ)。
このうち、主にテックタッチのサポートを担当する部隊では、ウェビナーの企画や配信する資料の作成とコミュニティサイトへの投稿、ヘルプサイトのナレッジ記事(検索するとヒットする日本語のFAQ)、Trailheadの日本独自コンテンツなどの取り組みも元々されていました。
一方で、コミュニティサイト、Trailheadやヘルプ等多くのコンテンツは母体となるサイトがグローバル管轄ですので、日本向けだけを辿れるトップがないとか、検索してたどり着いたヘルプサイトの日本語ナレッジ記事から、他の有用な日本語ナレッジ記事に到達するための導線の問題などがありました。ログインしないと閲覧できないものも当然多くありました。
サクッと概要を知るとか調べるということだと基本はサードパーティのブログ記事の方が到達しやすく読みやすかったりして、僕の目からみて、情報を探そうとしている人や苦労した末の発信をされている方の多くに「公式の資料でとっても包括的で分かりやすいものがあるのに・・・」「これを読んだ上で、深掘りたい時はこれ、という流れも用意されてるのに・・・」というケースが散見され新しいチャネルの必要性を謳うこととなりました。
おわりに
改めまして、先日は有志開催の出版記念パーティにお越しいただき、また質問をお寄せいただきありがとうございました。
また、本記事をご覧いただいた方もありがとうございました。
書籍関連の記事はこれで完全に打ち終わりだと思いますが、引き続きエコシステム、この界隈のために何か頑張っていきたいと思います。
相談先のないこと、お金だすほどでもないけどどこにも聞けないこと、などあれば質問を書いてみてください。
拾えないもの、拾わないものもあるかもしれませんが、頂いた問いはありがたく頂戴し、回答を考えていきたいと思います。
いいなと思ったら応援しよう！
