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