以下は、
本件の場合です。
たとえば、J-BMの場合は、マネタイズシナリオを出発点としてUCチャレンジだと思います。だから、実際の手順は、ケースによってさまざまだとは思います。
が、
以下の段取りは、
かなりおもしろそうです。
そうそう！昨冬のシンポジウム以降、欲しかったのはコレなんです！機能連携レベルのプロセスの作り方＼(^o^)／
シビれるなー
ぜひ、やってみたいです！！
あ、そういえば
さきほどまでの投稿は、
事業構想 八の字における左回りの話でしたが、本投稿は右回りですね！ということで、この投稿の書庫ラベルは、「事業開発（外部適応編）」ではなく、「事業開発（内部適応編」にしました。
↓
①検討対象の品定め
まず、各人のトライ＆エラーを通じて、
「良いケース」と「悪いケース」をそれぞれ選ぶ
②ー１ 良いケースからの学び
良いケースに至ったポイントは何だったのか？
良いケースの再現性を高めるには、業務遂行プロセスにおいて何が重要か？
②ー２ 悪いケースからの学び
悪いケースを繰り返さないためのポイントは何か？
ここでいう悪いケースは、どのような点を加味していれば、良いケースになった可能性があるといえるか？
③機能連携レベルのプロセスの肝の明確化
前項②ー１と②ー２をふまえると、
カスタマ・サクセスを叶える一連のプロセスにおいて、Keyとなる組織行動は何か？
＊おそらく、本項は、J-BMにおけるUCチャレンジシートの最右列「対応行動」に相当すると思う
④QA体系図の登場人物列挙
前項のKey行動をフックにして、一連のプロセスを描いてみたい。そこで、一連のプロセスに登場するであろう主要プレーヤー（人物、部門、組織など）をリストアップする
⑤登場人物別Key行動の定義
前項③の観点をにらみながら
登場人物別のKey行動を定義する
⑥QA体系図アウトライン化
各登場人物のKey行動を繋ぐことを試みる。
そのバトンリレーの様子を、一連の機能連携プロセスのアウトラインとして描画する。なお、この段階はまだ「アウトライン」の状態であり、完成図面は到底ない。
⑦手立ての検討
当ステップは、QA体系図でいうところの「帳票類」に相当する。前項のQA体系アウトラインを、うまいこと実行することに役立つ「手立て」を考える。たとえば、QA体系図に登場する人物の能力個体差によらず、誰でもうまく遂行できるようになるためには、どのような「手立て」が支援策として存在していればよいか？
この手立てが、実際に実装されたものが「業務支援システムやツール、DB」になる。