Please enable JavaScript.
Coggle requires JavaScript to display documents.
deployto-be (step2-2:施策遷移条件 (プログラムマネジメントの領域使える (プロフィールマネジメント,…
deployto-be
step2-2:施策遷移条件
なんのために設計する？
研究施策を評価し、適切なフェーズに移行させるため（本来のアセスメントの形）
足切りではなく、うまく施策を引っ張りあげるため？
くすぶっている施策とはなにか？
step3のプロセス設計の問題では？
将来性のある施策？
何のためにパターン分けする？
施策毎の目的に合わせて基準を変えるため
メリットは？
スタンスに応じて評価指標が変わるため、今まで通らなかったような案件が通るようになる？（所員のモチベーションが向上、ビジネス寄りはスピーディに対応可能等）
なぜフェーズ移行評価に時間が掛かる？（委員会承認までに半年かかる）
品質を求めすぎているから
なぜ？
事業展開するから？（企業に迷惑掛けたくない？）
会議の回数を増やすことでのリスクヘッジ
なぜ？
失敗すると責任追及される（研究費の無駄遣い）
では、研究費の掛からないものは簡易でよいのでは？
カテゴリ分けをどうするか？
内部環境（vario）、外部環境、独自性、実現可能性、影響度
ニュースコア法の観点
ブーストゲート法使える
評価指標ではなく、ブースターの役割がメインなのでstep3で活用
プログラムマネジメントの領域使える
プロフィールマネジメント
プログラム戦略マネジメント
アーキテクトマネジメント
プラットフォームマネジメント
判断指標
実行者+評価者が判断（ニュースコア法を参考にする）
明確な基準を作る