GTM基盤構築支援 ── 設計
課題の超え方を、
要件定義まで落とす。
診断で見つけた課題を、実装できる形にする。
どの業務を、誰が・何が、どのように動かすか——そこまで決めて、はじめて作れます。
Why
ツールが回らないのは、
システムの要件定義しか、しなかったから。
SFA も MA も入っている。それなのに、入力されない。使われない。数字も出ない。
原因は、ツールの選定ではありません。業務の動かし方を決めないまま、システムだけを決めたことにあります。
一般的な要件定義
システムから始める
- 必要な画面と項目を決める
- 機能一覧をつくる
- ツールの設定値を決める
- 誰がどう使うかは、導入後に現場で考える
入っているが、使われていない。
当社の要件定義
業務から始める
- どの業務を、どの順番で動かすかを決める
- 人がやること・AIがやることを分ける
- その業務が必要とするデータを定義する
- そこから、必要なシステム構成を決める
業務が回り、数字が動く。
Scope
4つを、まとめて決める。
業務・データ・システム・移行は、切り離して決められません。
バラバラに決めるから、あとで繋がらない。この4つを1つの要件定義書にまとめます。
01 Operation
業務設計
どの業務を、誰が・何が、どの順番で動かすか。人とAIの分担を決め、例外処理と判断ポイントまで含めて設計する。ここが決まらないと、データもシステムも決まらない。
02 Data
データ設計
その業務を回すために、どのデータが・どの粒度で・どこにあれば足りるか。部門ごとにバラバラな定義を、共通のデータ契約として揃える。
03 Architecture
AI／システム構成
既存のSFA・MA・データ基盤を前提に、何を活かし、何を繋ぎ、どこにAIを置くか。置き換えありきでは設計しない。Growth Gear をどこまで組み込むかも、ここで決める。
04 Roadmap
移行ロードマップ
いまの業務を止めずに、どの順番で移行するか。何人月かかるか。どこから先行して効果が出るか。実装の見積りが立つ粒度まで落とす。
Boundary
進むほど、数字が確かになる。
診断で出すのは、解けたときの改善余地の幅と、何を解けば効きそうかという解決仮説です。
設計で出すのは、実装可能な解法と、それに基づいて精緻化した数字です。
設計は、単体ではお請けしません。実装まで通してはじめて、要件定義書は価値になるからです。
なお診断費は、設計・実装に進まれる場合に一部を充当します。
その他
事業戦略・プロダクト戦略・GTM戦略そのものの策定も、個別にお請けしています。
まずは、どこが問題かを見つけるところから。
設計の前に、診断があります。どこに、いくらかけていて、解けたらどれくらい伸びる余地があるか——数字で示します。