Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
20230122_BTCONJP_C15
Search
barusu
January 22, 2023
Business
0
250
20230122_BTCONJP_C15
具体的な改善内容は口頭補足する予定だったので資料としては簡素です
barusu
January 22, 2023
Tweet
Share
More Decks by barusu
See All by barusu
20230719_JWUG.pdf
barusu
0
130
20230628_情シスSlack_ChatGPTの話
barusu
0
56
2021-07-17_一番良いLT会
barusu
0
110
かつてパチンコ屋で見た景色
barusu
0
120
2021-06-24_12周年だよssmjp_
barusu
1
290
2020-12-12情シス振り返り
barusu
0
220
2020-11-28
barusu
0
90
2020-07-25_8時だよ!全員ToGo#1
barusu
0
360
2020-06-13_誤家庭の話_インフラ勉強会.pdf
barusu
1
140
Other Decks in Business
See All in Business
Cloud Run で作るサーバーレス アーキテクチャ 30 連発 - これのときはこう!
googlecloudjapan
24
7.5k
対話をする前に 知っておくべきこと -人格主義を基本とする関係構築-
rakuraku0615
0
180
パシフィックメディカル会社説明資料/ PMed Company Guide
medley
0
120
エンジニアと関係組織をつなぐ社内 DevRel のとりくみ / Why DevRel works in-house
nttcom
3
530
test
sayuri_f
0
500
家族アルバム みてね 事業紹介 / Our Business
familyalbum
2
20k
From Strategy to Practice: Insights on How Team Topologies Drives Organizational Success
mfpais
PRO
0
290
ネクストビートコーポレートガイド/corporate-guide
nextbeat
1
75k
モベンシス株式会社 会社紹介資料
movensys
1
1.4k
会社紹介資料 | booost technologies株式会社
booost
0
900
Cloud Run で作るサーバーレス アーキテクチャ 30 連発 - これのときはこう!
googlecloudjapan
0
100
レイド株式会社_会社紹介資料
rayd
0
220
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
65
9.9k
The Language of Interfaces
destraynor
154
24k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
How to train your dragon (web standard)
notwaldorf
87
5.6k
A designer walks into a library…
pauljervisheath
201
24k
Atom: Resistance is Futile
akmur
261
25k
We Have a Design System, Now What?
morganepeng
49
7.1k
Docker and Python
trallard
40
3k
Unsuck your backbone
ammeep
667
57k
Clear Off the Table
cherdarchuk
91
320k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Building a Scalable Design System with Sketch
lauravandoore
459
32k
Transcript
0 PUBLIC 営業フローの問題点を Salesforceで改善した話 なぜ企業はSFA/CRMで悩まされるのか Presented by barusu @BTCON C15
1 ⾃⼰紹介 あるときは情シス あるときはPM あるときはエンジニア かくしてその実態は
2 barusuです ⾃⼰紹介 情シス歴 :7年 年齢 :32歳 所属会社 :クラウドネイティブ スキル
:⾊々チョットデキル 得意 :Salesforce,問題解決 不得意 :朝,猛暑,極寒 経験企業 :30社 +α 好きなカフェイン :モンスター緑
3 Twitterやってますけど、有益情報は皆無です ⾃⼰紹介
4 結構いろんな案件やってきました ⾃⼰紹介おわり
5 PUBLIC 営業フローの問題点を Salesforceで改善した話 なぜ企業はSFA/CRMで悩まされるのか Letʼs go !!
6 アジェンダ 1 SFA/CRM導⼊の落とし⽳ P7 2 なぜ企業はSFA/CRMに悩むのか P15 3 失敗しないために必要なこと
P19 4 おわりに P39 5 Appendix:営業フローの問題点を Salesforceで改善した話 P43
7 SFA/CRM導⼊の落とし⽳ SFA/CRMがうまくいってる会社、マジで少数説
8 ⽣の声@Twitter SFA/CRM導⼊の落とし⽳
9 ⽣の声@Twitter SFA/CRM導⼊の落とし⽳
10 よくある失敗例-Web ① CRMの対策は導⼊前から!5つの失敗事例から学ぶ効果的な対策⽅法 | 【GENIEEʼs library】営業組織課題を解決するメディア SFA/CRM導⼊の落とし⽳
11 よくある失敗例-Web ② CRMの対策は導⼊前から!5つの失敗事例から学ぶ効果的な対策⽅法 | 【GENIEEʼs library】営業組織課題を解決するメディア SFA/CRM導⼊の落とし⽳
12 よくある失敗例-Web ③ CRM導⼊成功のために知っておきたい!5つの失敗要因 ‒ CRM(顧客管理)ならオープンソースのF-RevoCRM SFA/CRM導⼊の落とし⽳
13 よくある失敗例-Web ④ CRM導⼊成功のために知っておきたい!5つの失敗要因 ‒ CRM(顧客管理)ならオープンソースのF-RevoCRM SFA/CRM導⼊の落とし⽳
14 よくある失敗例-体験談 ① ⽬的がはっきりしない - このシステム何のためにあるんでしたっけ? - 営業「これ導⼊するっつったの誰だよ出てこいよ」 - 部⻑「社⻑が⾔ってた」
営業「あっ...(察し)」 ② データ揃えるのが⼤変 - 営業が⼊⼒/更新しない - 営業「単に⼿間だけ増えて地獄」 - データが他システムと連携されていない - ⼈事DBとか販売管理系とか会計とか ③ 使うってレベルじゃねえぞ - 営業部⻑⽂句しか⾔わねえ - 要望その他全ての⾯倒ごとは管理者に丸投げ ポイー - ごん...お前だったのか案件 SFA/CRM導⼊の落とし⽳
15 なぜ企業はSFA/CRMに悩むのか おしえて!ChatGPT
16 ChatGPTに聞いてみた なぜ企業はSFA/CRMに悩むのか まあそうだよねって回答
17 barusuが回答してみた まだまだChatGPTには負けねえ! なぜ企業はSFA/CRMに悩むのか 色々あんのよ!!!!!!! 事情が!!!!! 会社それぞれよ!!!
18 barusuの⾒解:なぜ企業はSFA/CRMに悩むのか SFA/CRMシステムの機能不全が多いのはだいたいデータフローと体制のせい 1 企業の営業戦略の上に⼿段としてのSFA/CRMがある • 顧客の属性、何を持っていれば商談時に役⽴つのかとか、基本情報と変更される情報ってなんだっけとか • そもそも弊社の営業戦略 is
何 が決まってないのにシステムがどうこうできるわけないじゃん 2 SFA/CRMの課題 = 企業のデータフローの課題 • データフローを整理するには上流から下流に⾄るプロセス全てを網羅的に整理する必要がある • システム化すると機能不全となり、プロセスの課題が浮き彫りになる 3 使う⼈と管理する⼈の連携ができてない なぜ企業はSFA/CRMに悩むのか • システム導⼊してハイ終わり!はありえん
19 失敗しないために必要なこと 具体的にどーすんのって話
20 SFAの問題と対策 問題と戦うには 1. ⽅針が定まっていない 2. データが不⾜している 3. 体制が脆弱 失敗しないために必要なこと
⾃社ビジネスの特性と戦略を元に SFA/CRMシステムの役割を定める データのライフサイクルを定義して 使いどころを決める 意思決定者とエンジニアの双⽅が 協⼒できる体制を整える
21 ⽅針はシステムの存在意義① ⾃社ビジネスの特性や戦略を元にSFA/CRMシステムの役割を定める - ⾃社事業の特⾊、顧客の特徴を把握して適切な営業スタイルを理解する - ⽅針の全てを定める必要はないが、解像度が⾼ければシステム導⼊効果も相応に期待できる - 対応すべき問題と無視できる問題の区別がつく -
重要なデータの取得基準やデータ廃棄の判断がしやすい - システム管理者だけでどうにかできることではない - 意思決定者を巻き込むべし 失敗しないために必要なこと
22 ⽅針はシステムの存在意義② ビジネス特性の要素⼀例 • BtoB?BtoC? • モノ売り?サービス? • プル型?プッシュ型? •
既存顧客中⼼?新規開拓が中⼼? • 顧客流⼊経路は?割合は? • 国内?国外? • CSは?拡販は? • 店舗?⾮店舗? • 在庫?無在庫? to B to C モノ 売り サー ビス プル プッ シュ 既存 新規 国内 国外 - 企業の事業戦略 - SFA/CRMシステムの基本⽅針と役割 (その他、多数の要素) 失敗しないために必要なこと
23 データはシステムの⾎液-① データの持ち⽅が重要。 Q. データフローと⾔うけど、どこから着⼿すればいいの? A. 基本的にはデータの上流から抑えていく。 👉 元になるデータがあれば、加⼯⽅法は後から変えられる 例え話)⽬⽟焼きが必要だったけどやっぱオムレツが欲しいってなった。どうする?
👉 ⽬⽟焼きからオムレツは作れないよね 👉 ⽣卵があれば、作り直しで対応できるしいいやーってなるよね 失敗しないために必要なこと
24 データはシステムの⾎液-② Q. どんなデータを持っておくべき? A. 過去を遡及して取れないデータは先⼿を打つべし 例)契約までのリードタイムを計測したいから商談のステータス変更履歴と⽇付が欲しい 👉 変更の度に⽇付等の履歴データを記録する設定が必要 👉
後からは取得できない 👉 新たに収集開始してからデータ利活⽤まで、最低でも1ヶ⽉はかかる 失敗しないために必要なこと
25 データはシステムの⾎液-③ Q. ⼿当たり次第なんでもかんでもデータを残すべきなのか? A. No。データ量が増えるとメンテナンス⼯数も増える。 👉 ユーザーの⼊⼒はなるべく減らすべき 👉 ⼊⼒が必要なデータはアウトプットで欲しい型から逆算する
👉 ユーザーの⼊⼒不要で取得できるデータは積極的に収集する 失敗しないために必要なこと
26 データはシステムの⾎液-③ こういうデータフロー図があるとヨシ 失敗しないために必要なこと
27 体制はシステムの⾁体-① 各役割について ユーザー側の役割 - 意思決定者 - 組織の事業戦略及び営業戦略からKPIを定める - システムへの要求事項を定義する
- システム導⼊効果の計測を定期的に⾏う - オペレーター - ⼊⼒と更新を主に担当する - 運⽤上の問題点を発⾒次第、意思決定者に報告・連絡・相談する - 改善要望をAdminに依頼する 失敗しないために必要なこと
28 体制はシステムの⾁体-② 各役割について システム管理者側の役割 - Admin - 要求事項をシステム要件に翻訳する役割 - セキュリティ/データガバナンス/利便性/KPI計測の有効性などを考慮して開発者と連携する
- 開発者 - 実現可能な技術を⽤いて現実的な開発を⾏う - 要求事項を満たすための解決策提案及び実現をする 失敗しないために必要なこと
29 体制はシステムの⾁体-③ 意思決定者=システムの頭脳 ▼特徴 - 主に部⻑とか役員 - システムをカスタマイズしすぎてしまうのは意思決定者の責任 - 意思決定者は代替が最も難しい
- 正直なところ、システム管理者やオペレーターは探せばなんとかなる - システムに理解があり、能動的に⽅針を決められる意思決定者は貴重 ▼意思決定者との関わり⽅ - Admin - システムをビジネスに合わせすぎてはいけない - ビジネスロジックを理解し対等な⽴場で会話すること - オペレーター - 報連相の頻度と質、業務上の距離感が意思決定に作⽤すると⼼得る - 開発者 - 意思決定者の⽴場を理解して尊重すべきだが、遠慮や忖度は不要 失敗しないために必要なこと
30 体制はシステムの⾁体-④ 意思決定者=システムの頭脳 ▼意思決定者との関わり⽅ - Admin - システムをビジネスに合わせすぎてはいけない - ビジネスロジックを理解し対等な⽴場で会話すること
- 全ての要求を呑む必要はない - オペレーター - 報連相の頻度と質、業務上の距離感が意思決定に作⽤すると⼼得る - 開発者 - 意思決定者の⽴場を理解して尊重すべきだが、遠慮や忖度は不要 失敗しないために必要なこと
31 体制はシステムの⾁体-⑤ オペレーター=システムの感覚器官 ▼特徴 - 顧客に接する営業、経理、会計担当、営業事務 など様々 - プロセス上で最も重要かつ価値が発揮されるが、業務を属⼈化させやすい側⾯もある -
システム運⽤において最も苦労する⼈達 - UI/UXが多少悪くても運⽤で吸収してくれるありがたい存在 - 問題発⽣の最前線にいるとも⾔える いつもありがとうございます 失敗しないために必要なこと
32 体制はシステムの⾁体-⑥ オペレーター=システムの感覚器官 ▼オペレーターとの関わり⽅ - 意思決定者 - オペレーターの信頼を勝ち取るべし - 個別の案件確認より全体の漏れ防⽌に注⼒する
- Admin - 毎⽇オペレーターへ感謝の正拳突きを1万回すべし - ⼊⼒を増やす施策は慎重に実⾏する - オペレーターの負担はかけ算で増えていく - 1つ増やすなら2つ減らせ - 開発者 - オペレーターの違和感を⾒逃すな、しかし惑わされてもいけない 失敗しないために必要なこと
33 体制はシステムの⾁体-⑦ Admin=システムの⾻ ▼特徴 - 求められるスキルの幅が広い - ビジネス、テクノロジー両輪の知識 - 全社設計レベルでの視野の広さ
- ユーザーの要求から背景を理解する能⼒ - システム要件に転換した際のリスクや問題点を適切に捉えて伝える⾔語化能⼒ - 教育や採⽤が難しい - いないことがままあるため、他の役割と兼務されることも - 嫌われることも多々ある - システムへのヘイトを⼀⽅的に向けられる - 融通が利かない等⾔われて嫌われることもある - Adminのキャパシティを超えたカスタマイズはシステムの負債化に直結 - Adminの⼈数×スキルの総量 = システムが許容できるカスタマイズ量 - やること多過ぎ問題 - マジで多いけどAdminがボトルネックになるのは(ʻωʼ乂)ダメー 失敗しないために必要なこと
34 体制はシステムの⾁体-⑧ Admin=システムの⾻ ▼Adminとの関わり⽅ - 意思決定者 - 要求の丸投げをしてはいけない - 要求事項を適切に⾔語化し、⽬的と背景、解決したい事項の説明をするべし
- 衝突が多くAdminを嫌いがちだが尊重を忘れないこと - オペレーター - Adminは⽂句を⾔いやすい相⼿だが、相⼿も⼈間なので... - こう...⼿⼼というか... - 改善要望やクレーム以外に、改善結果や感謝の声もフィードバックするべし - とても喜ぶ - 開発者 - システムの課題解決において協⼒するシーンが多い - 飲みに⾏こう - 役割分担や変更に係る規則類を明確にしておくと摩擦が減る 失敗しないために必要なこと
35 体制はシステムの⾁体-⑨ 開発者=システムの筋⾁ ▼特徴 - 問題解決の主担当 - 命題と前提が誤っていればアウトプットも的を外してしまう点に注意 - Howを重視する傾向があるが、それも役割の⼀つ
- ⼿法を間違えれば新たな弊害と負債を⽣む - 規模が⼤きくなると専任or外注が必要 - 簡易的な⽬安:従業員数500⼈以上、売上50億/年、レコード総数1億件以上 - 中⼩企業ではだいたいAdminが兼務 失敗しないために必要なこと
36 体制はシステムの⾁体-⑩ 開発者=システムの筋⾁ ▼開発者との関わり⽅ - 意思決定者 - ⾔語プロトコルの違いにより意思疎通が互いに難しいが、⼀定のシステム理解があると捗る - オペレーター
- 開発者を兼務できると問題解決のスピードが格段に早まる - Admin - トモダチ。データフローの管理、設計においては役割分担をすべし 失敗しないために必要なこと
37 ぼくがかんがえた理想の体制図 失敗しないために必要なこと
38 ぼくがかんがえた理想の体制図 ChapterX. XXXXXXX
39 おわりに まとめ的な結びの挨拶的な
40 SFA/CRMで悩むあなたへ 今⽇はこれだけ覚えて帰って!! 1 管理者がやることは多い。だが、管理者だけではどうにもできない • ユーザー側との協⼒がないとマジで使われない 2 システムは集合⽣命体であり、モノでも仕組みでもない •
構成する関係者が相互協⼒しないとデータが循環しない • データが循環しなければシステムは簡単に死ぬ おわりに 3 ⾃社のシステムを殺さないために、協⼒者を探そう • 周囲を巻き込むこと • 時には⾃分から巻き込まれにいくこと
41
42 営業フローの問題点を Salesforceで改善した話 barusuが実際に戦ってきた課題たち 12個全部解説したら時間足りなくなりそうなのでAppendixに入れました
43 現場の悲鳴① データ更新されてねぇ ChapterX. XXXXXXX レコードコピーとかコピペがめんどくさすぎて派遣がすぐ辞める そもそもその業務要らなくね?何の為にやってんすかね 既存レコードの情報コピペすると二重管理になるから引用するようにした ステータス変更したらレコードが自動作成されるようにした 追加で更新が必要な項目だけ強調表示するようにした
うっかり忘れちゃうんだよね この作業マジ不毛
44 現場の悲鳴② 商談状況の⼊⼒が⾯倒すぎる ChapterX. XXXXXXX コピペ職人に俺はなる メール取り込みするようにしたから 商談とメールの紐付けだけやれば良いよ memoは好きに残してくれ 議事録の内容をSalesforceにコピペしてる
お客さんとのメールやり取り内容を Salesforceの活動状況に入力するのが面倒 議事録は会社名と商談名揃えてくれれば自動化できる
45 現場の悲鳴③ ⾒積書のフォーマットがない ChapterX. XXXXXXX 帳票システムと承認フロー作ったからこれ使ってヤミ見積なくしてこ おいおいやべーじゃん だいぶファンキーじゃん Excelで勝手に見積作るアホがいる
46 現場の悲鳴④ 売上集計が⼿動で⽉末処理が憂鬱 ChapterX. XXXXXXX 繁忙期に残業してこの作業してると涙が出てくる 前世で相当の罪を背負ったようだ 帳票システムとステータス管理項目作ったから、探しやすくなったはずよ 君はもう赦されて良い 受注できたのか否かは入力が必要なのでステータス更新はよろしく
見積作ったけどどれが受注したのかわからないし、 メール添付のPDFファイルを探すのくっそだるい 毎月末にレコード250件くらいコピーして入力しなきゃいけなくて 月末が近づくと体調悪くなる ステータス更新してくれれば、集計用のレコードは自動で作成されるよ
47 現場の悲鳴⑤ 過去PJ情報が散乱してて何もわからない ChapterX. XXXXXXX 俺たちは雰囲気で営業をやっている PJ管理ルール作ったから納品物まとめといて Salesforceと紐付けたから、命名規則を守ればフォルダURLも生成されるよ 顧客情報に紐付けてるから他案件の情報も参照しやすくなってるよ
48 現場の悲鳴⑥ 名刺データがシステムに⼊ってこない ChapterX. XXXXXXX 名刺がトレーディングカード化している ちなみに俺の名刺、レア度どれくらい? 交換した名刺は俺のデスクに置いといてくれれば 全部システムに入れとくよ
49 現場の悲鳴⑦ 問い合わせがリードに⼊ってこない ChapterX. XXXXXXX 手動で登録する人が必要 パイプライン管理したいのにそもそもデータが入ってない 問い合わせ受信からシステムに入るようにしといた 商談開始前フローも一緒に整備した カンバンのビューとダッシュボード作った
レコード更新ちゃんとやってくれれば視認性爆上がりするよ
50 現場の悲鳴⑧ 基幹システムとデータ連携されてない ChapterX. XXXXXXX フルスクラッチのオンプレシステム辛すぎ🥺 帰社しないとアクセスできないし、いちいち帰社してると帰りが遅くなる 出先で安全にシステム開きたい CSV吐き出せるみたいなので日次バッチ処理作った 参照だけならSalesforceで確認できるよ
※更新は無理だった
51 現場の悲鳴⑨ ⼊⼒規則で怒られるので更新を諦める ChapterX. XXXXXXX 何度修正しても規則厳しすぎて保存できないの辛すぎ すまんな、入力規則の条件緩和するわ 代わりにレコード保全の仕組み作った 定期的に管理者が確認して修正しとくわ
52 現場の悲鳴⑩ 営業メンバーが流動的で商談が⾃然消滅しがち ChapterX. XXXXXXX 自分が稼働する案件決まったから商談いけないわー ゴメン!誰か代わって! 最終更新日でソートしたレポート作成した 動きがない商談はアラート出すようにした 代わりの営業アサインの人選は部長よろしく
53 現場の悲鳴⑪ クロスセルが全然提案できない ChapterX. XXXXXXX A社でやったhoge案件、他顧客にも簡単に横展開できるはずなのに 対象企業がみつからないし探せない 顧客の属性情報を新たに付与したのと、 案件情報が紐付いてレポート出るようにしたから上手く使ってくれ
54 現場の悲鳴⑫ 営業メンバーが定着しない ChapterX. XXXXXXX 営業メンバーの入れ替わりが激しくて教育コストが無視できない 商談フェーズごとに使うメール文面のテンプレ、それぞれ作っといた 入力項目とNextActionの例を示すようにした Salesforceの画面にマニュアルへのリンク置いといた 困ったらこれ読んでくれ
商談時の想定問答とか作った
55 株式会社クラウドネイティブ Cloud Native Inc. 設立:2017年5月 所在地:〒106-0032 東京都港区六本木1-4-5 アークヒルズサウスタワー 16F
代表電話番号:050-1791-0450 Eメールアドレス:
[email protected]
ITの世界だからこそ、⼈と⼈とのコミュニケーションを最重要視し、 全員が前を向いて楽しく仕事を進められる世界を作るのが最⼤のミッションです。 https://cloudnative.co.jp