Professional Buy-in Process プロフェッショナル・バイイン・プロセス Date: July 16th, 2015 Facilitator: Ryoma Shiratsuchi, Co-President, Juntos Consulting 本資料の一切の無断転載を禁じます。また、本資料の一部または全部を、著作権法 の定める範囲を超え、無断で複製（コピー）、転載、ファイル化することを禁じます。 本ワークショップの目的 営利組織に対するTOC導入を、よりスムーズに 行うための 技術・経験を紹介する： ▪ より短い期間で ▪ 導入する解決策の内容を妥協することなく ▪ 期待した成果を実現する © 2015 Juntos Consulting All Rights Reserved. 2 導入アプローチに関する課題 セールスと導入に要するサイクルタイムの長さは、経営陣と現場のマネジャー のBuy-in（理解して同意する）を獲得する能力に影響を受ける。 Top-down Approach Decision Top Management Cycle Time for Sales Cycle Time for Implementation Gemba Time • 意思決定は短期間で行われるかもしれない。しかし、現場とのコンセンサス が欠如していると、導入中に多くの困難に直面することになる。 その結果： ☹ 導入フェーズ中に、やり直しが多く発生する ☹ 導入のサイクルタイムが予定よりも長くかかる ☹ 現場はいずれ解決策を使うことを止めるかもしれない © 2015 Juntos Consulting All Rights Reserved. 3 導入アプローチに関する課題 セールスと導入に要するサイクルタイムの長さは、経営陣と現場のマネジャー のBuy-in（理解して同意する）を獲得する能力に影響を受ける。 Decision Top Management Cycle Time for Sales Bottom-up Approach Gemba Cycle Time for Implementation Time • 意思決定が行われるまでに多くの時間を要する。 • 導入の範囲が小さくなり過ぎてしまうかもしれない。 その結果： ☹ ルール/方針や指標の変更が必要な時に、経営陣の関与が得られない ☹ 解決策が本格展開されるまでに非常に長い時間がかかる © 2015 Juntos Consulting All Rights Reserved. 4 サイクルタイムが長くなる – 推測される原因 解決策の優先順位について関係者の認識にギャップがある © 2015 Juntos Consulting All Rights Reserved. 5 導入アプローチに関する課題 – 求められる新しい方向性 Top-down? or Bottom-up? 両者の間のつながりを 作ることに集中する Top Management Top Management Gemba Gemba © 2015 Juntos Consulting All Rights Reserved. 6 「抵抗の6階層」 第1層: 「何が問題であるか」について同意しない 第2層: 解決策の方向性に同意しない 第3層: その解決策では望んでいる効果が得られるとは思わない なるほど。 でも・・・ (Yes, but…) 第4層: ネガティブな（悪い）影響について心配だ 第5層: 解決策の導入方法について心配だ（障害） 第6層: 説明のつかない不安（「イエス」と言いつつ行動は「ノー」） © 2015 Juntos Consulting All Rights Reserved. 7 標準的なBuy-inプロセス UDE UDEクラウド 問 題 コア・クラウド 現状ツリー インジェクション 解決策 導入方法 © 2015 Juntos Consulting All Rights Reserved. 未来ツリー ネガティブ・ブランチ S&Tツリー 8 現実は… UDE UDEクラウド 問 題 コア・クラウド 現状ツリー インジェクション 解決策 導入方法 © 2015 Juntos Consulting All Rights Reserved. 未来ツリー ネガティブ・ブランチ S&Tツリー 9 「抵抗の6階層」の第１層を登った地点はどこにある? “Define a problem precisely and you are halfway to a solution.” もし上記の主張が妥当だとすれば、 「問題に同意する」という中間目標は、どこにありますか? あなたの足もと © 2015 Juntos Consulting All Rights Reserved. or 10 あなたの頭上 「解くべき問題」に同意する – 障害と中間目標 障害 なぜそれが問題なのかピンと こない - “何が悪いの?” 「大した問題ではない」と思う 阻害要因 （障害の原因） 中間目標 「パフォーマンスが低い」という 事実を知らない これは確かに、 “私にとって”悪いものである、 その問題が私とどんな関係が あるか分からない どんなマイナスの結果が将来 起こるのか想像できない と認識している この問題の影響は無視できない or 将来の脅威が現実のものである、 と認識している 「しょうがない」と思う © 2015 Juntos Consulting All Rights Reserved. “自分のやるべきことは もう十分やっている” “私の行動”に誤りがあり、 この問題を引き起こしている、 （この問題は私の責任である） “私のせいではない” と認識している 11 プロフェッショナル・Buy-inプロセス UDE UDEクラウド コア・クラウド 問 題 ニーズB/Cに対する“責任” ネガティブ・ループ図 “時間制約”への集中 インジェクション 解決策 & 導入方法 © 2015 Juntos Consulting All Rights Reserved. パフォーマンス評価指標 ポジティブ・ループ図 ネガティブ・ブランチ 12 UDEクラウドの作成手順 1. なぜこのUDEは望ましくないのか? システムのどんな重要ニーズが危険に晒されているか? UDE 2. 危険に晒されているニーズBを満たすために、 どのような行動をとらなければならないか? 3. 行動Dをいつも行うことができないのは、 他にどんな重要ニーズがあるからか? 4. もう一方のニーズCを満たすために行うのは どのような行動か? 5. BとCの両方で達成される、 共通の目的は何か? 1 B A 2 D 5 3 C D’ 4 このUDEが真っ向からの対立をあなたにもたらしているかチェックして下さい。 行動DがCを危険に晒しているかチェックして下さい。 行動D’がBを危険に晒しているかチェックして下さい。 © 2015 Juntos Consulting All Rights Reserved. 13 © Copyright Oded Cohen, 2015 UDEクラウドをつくる際の間違い UDE リソースが必要な時に利用できない A B D すべての 顧客オーダーの 納期を守る 設備を追加購入する C D’ 自社の経費が 増えるのを防ぐ 設備を追加購入 しない 利益を増やす © 2015 Juntos Consulting All Rights Reserved. 14 © Copyright Jelena Fedurko, 2015 UDEクラウドをつくる際の間違い 間違い： DとD’に「未来の意思決定」に関する個人のジレンマを記述する • 上記の間違いは、いたるところで広がっている症状である。 • UDEクラウドでは、DとD’に「システムの定常的な行動モード」を記述する 必要がある。それにも関わらず「システムの責任者の個人的なジレンマ」 を記述してしまっている。 • この場合、片方のアクションのボックスには、システムが現在従っている 行動が書かれ、もう一方に、取り入れたい行動が書かれる。 © 2015 Juntos Consulting All Rights Reserved. 15 © Copyright Jelena Fedurko, 2015 UDEクラウドをつくる際の間違い UDE リソースが必要な時に利用できない B A すべての 顧客オーダーの 納期を守る 間違い： Dの記述は現状の 定常的な行動ではなく、 未来の意思決定に関する D ジレンマの片側である 設備を追加購入する 利益を増やす D-D’で表現しているのは、 具体的な単発の投資案件 に関するジレンマである © 2015 Juntos Consulting All Rights Reserved. C D’ 自社の経費が 増えるのを防ぐ 設備を追加購入 しない 16 © Copyright Jelena Fedurko, 2015 修正例その1 UDE リソースが必要な時に利用できない A B D すべての 顧客オーダーの 納期を守る オーダーのうち いくつかを 外注に出す C D’ 自社の経費が 増えるのを防ぐ どのオーダーも 外注に出すことは しない 利益を増やす © 2015 Juntos Consulting All Rights Reserved. 17 © Copyright Jelena Fedurko, 2015 修正例その2 UDE リソースが必要な時に利用できない A B D すべての 顧客オーダーの 納期を守る 作業者に 残業させる C D’ 自社の経費が 増えるのを防ぐ 作業者に 残業させない 利益を増やす © 2015 Juntos Consulting All Rights Reserved. 18 © Copyright Jelena Fedurko, 2015 現実は… コア・クラウドを特定することは、その組織に対して集中すべき“てこの点”を 提供する。 しかし現実は、実践者の多くを迷路に導いてしまう。 コア・クラウドの特定プロセスは、高度なスキルと多くの経験が必要で あり、実践者の多くは間違えやすい。 習得するためには、2-3年の実践期間が求められる © 2015 Juntos Consulting All Rights Reserved. 19 製造企業における典型的な問題症状 – UDE 1. 機械/作業者が必要な時に使えない 2. 原材料/部品が必要な時に足りない 3. 製品倉庫で在庫品の欠品が多い 4. 緊急配送が必要となることが多すぎる 5. 仕掛在庫が多すぎる 6. 優先順位がころころ変わる 7. 督促が多すぎる 8. 残業が多すぎる 9. やり直しが多すぎる 10. 陳腐化したり、死蔵品となる品目が多い © 2015 Juntos Consulting All Rights Reserved. 20 これらのUDEはなぜ好ましくないのでしょうか? 1. 機械/作業者が必要な時に使えない 2. 原材料/部品が必要な時に足りない 3. 製品倉庫で在庫品の欠品が多い 4. 緊急配送が必要となることが多すぎる 5. 仕掛在庫が多すぎる 6. 優先順位がころころ変わる 7. 督促が多すぎる 8. 残業が多すぎる 9. やり直しが多すぎる 顧客の需要を 満たす 両方とも自社にとって欠くことの できない大事なニーズである! L 社内のキャパシティを 上手に徹底活用する 10. 陳腐化したり、死蔵品となる品目が多い © 2015 Juntos Consulting All Rights Reserved. L 21 UDEを発生させる要因 – 変動 前述のUDEを発生させるトリガーは、“変動”である。 需要と供給には、それぞれ変動がつきものであり、供給フローに影響を 与える。供給側にとって以下が“需要の変動”とみなされる： ▪ 数量の増減 ▪ 納期の前倒し/後倒し ▪ 納期の偏り ▪ 製品ミックスの偏り 変動を小さくすることは重要であるが、なくすことはできず、そのために マネジャーが必要となる。 © 2015 Juntos Consulting All Rights Reserved. 22 中核問題 – オペレーション管理におけるコア・クラウド B D 顧客の需要を 満たす 需要の変動をそのまま 受け入れる A 上手に管理する D’ C 社内のキャパシティを 上手に徹底活用する © 2015 Juntos Consulting All Rights Reserved. 23 需要の変動をそのまま 受け入れることはしない （均す/調整する/断る） コア・クラウドを得ることの価値 人は必ずしも、損得勘定（メリットとデメリットの大きさを比べる）だけで自分 の行動を決めるわけではない。 コア・クラウドのニーズB/Cが表すのは、マネジャーとしての“責任”である。 但し、人は、自分のやるべきことができていない（=責任を果たしていない） と認識したとしても、自分の行動を変えるには至らないことがある。 プロフェッショナルなマネジャーは、「知り得て害を為さない」 コア・クラウドの行動D/D’を通じて、“自分の行動がシステムに害を及ぼして いる”と明確に認識した時にはじめて、人は自分の行動を変える機会を得る。 © 2015 Juntos Consulting All Rights Reserved. 24 現実は… コア・クラウドの特定を通じて、そのシステムが持つ“制約”が明らかになる。 制約（Constraints）: 「システムの目標達成レベルを決定づける要因/要素」 営利組織における制約は、以下の3種類に分類される： ▪ キャパシティ制約 ▪ 市場制約 ▪ 時間制約 TOCの主張は、「いかなるシステムにも、ごく少数の制約がある」であり、 「制約はひとつ」とは述べていない。 但し、「集中の5ステップ」を用いようとするのであれば、我われはひとつの 制約を選ばなければならない。 しかし現実は、営利組織の多くは、市場制約とキャパシティ制約を両方とも 同時に持っている。 © 2015 Juntos Consulting All Rights Reserved. 25 MTO環境におけるクラウドの例 B D 顧客の需要を 満たす CCRのキャパシティを 浪費する顧客要求を 受け入れる C D’ CCRのキャパシティ を上手に徹底活用 する CCRのキャパシティを 浪費する顧客要求を 受け入れることは しない A 上手に管理する © 2015 Juntos Consulting All Rights Reserved. 26 MTO/MTA混合環境におけるクラウドの例 B D MTA製品の需要を 満たす 上振れした実需に 応じてすぐにMTAの WOを投入する A 上手に管理する C MTOオーダーを 処理するのに必要な キャパシティを確保 する © 2015 Juntos Consulting All Rights Reserved. 27 D’ 実需が上振れしても MTAのWOをすぐに 投入することはしない プロジェクト環境におけるクラウドの例 B D 顧客の需要を 満たす ショートワークに 全てのリソースを 割当てる C D’ プロジェクトに 利用可能なリソース を確保する ショートワークに 全てのリソースを 割当てることはしない A 上手に管理する © 2015 Juntos Consulting All Rights Reserved. 28 “時間制約”に集中する ジレンマが解消されない結果、“妥協した行動”が取られる。 需要の変動に対処するために取られる、現行システムにおける典型的な “妥協した行動”とは： ▪ 製造（MTO/MTA）環境 – 早めの投入 ▪ プロジェクト環境 – マルチタスキング 上記の行動はいずれも、待ち時間を発生させ、製造リードタイム/補充期間/ サイクルタイムを伸ばす – すなわち、“時間制約”を浪費する。 時間制約は、市場制約とキャパシティ制約のどちらにも影響を与える重要 なドライバーである。 浪費されている時間制約に対し、マネジャーの注意を向けるようにするため には、どうすればよいか? © 2015 Juntos Consulting All Rights Reserved. 29 現実は… コア・クラウドを記述できたのであれば、そこからは、クラウドの前提条件を 表面化し、インジェクションを導き出すステップに移る。 しかし現実は、TOCの標準ソリューションを適用しようとする環境であれば、 インジェクションが“パッケージ”として用意されているため、上記のステップ を辿ることなく、解決策が紹介されるだろう。 この場合、提案された解決策を部分的に導入（解決策の構成要素を妥協） しようとする意見が出るかもしれない。 また、このステップの前後で、現状ツリー（CRT – Current Reality Tree）を 作ることもある。CRTは「原因と結果」のロジックを使ってシステムの問題を 構造的に表現することできる。 しかし現実は、CRTは第3者が見て分かり易いものではなく、また、解決策 のイメージを誘発するような図解構造になっているとは言い難い。 © 2015 Juntos Consulting All Rights Reserved. 30 CCPMの3つのルール RULE 1: パイプライニング WIPを制限し、リソースを集中させる RULE 2: フルキット 準備の出来ていないタスクを開始しない RULE 3: バッファマネジメント バッファの優先順位に従ってリソースを配置する © 2015 Juntos Consulting All Rights Reserved. 31 解決策の構成要素を妥協すると… © 2015 Juntos Consulting All Rights Reserved. 32 ネガティブ・ループ図 – プロジェクト環境 できるところから着手すれば 進捗するという思い込み インプット/指示を待つ間 別のタスクを開始する 作業者/マネジャーの マルチタスキング 待ち時間 同時進行中の 作業が多すぎる （High WIP） タスクの期間が 伸びる タスクの開始-終了日 とリソースの割当予定 を固定する © 2015 Juntos Consulting All Rights Reserved. 33 問題解決の方向性 何を変えるのか? 何に変えるのか? High WIP WIPの制限（パイプライニング） 進行中パス/タスク数が多すぎる 進行中パス/タスク数を制限する 薄く伸ばしたリソース割り当て リソースの集中 できるところから進捗を見せなけ ればならない フルキット（万全な準備） 開始日が来ても、準備が出来て いなければタスクを開始しない 予定した開始日がくれば、準備が 不十分でもそのタスクを開始する バッファの優先順位に基づいて リソースを配置する 固定スケジュール 局所的に優先順位を判断する 部門全体で共通の優先順位 リソースに仕事を割当てる 仕事にリソースを割当てる © 2015 Juntos Consulting All Rights Reserved. 34 ネガティブ・ループ図を用いたコミュニケーションの効用 ループ構造によって問題の繰返し性が表現されるため、すべての関係者が 問題の深刻度を理解することができる。 自分たちの行動における現状の間違った部分が特定され、取り入れるべき 解決策の構成要素を“どれも欠かせない、ひとつのセット”として伝えること ができる。 シンプルな図解によって一覧性を確保しているため、どんな相手に対しても 問題と解決策について短時間で説明することができる。 © 2015 Juntos Consulting All Rights Reserved. 35 プロフェッショナル・Buy-inプロセス UDE UDEクラウド コア・クラウド 問 題 ニーズB/Cに対する“責任” ネガティブ・ループ図 “時間制約”への集中 インジェクション 解決策 & 導入方法 © 2015 Juntos Consulting All Rights Reserved. パフォーマンス評価指標 ポジティブ・ループ図 ネガティブ・ブランチ 36
© Copyright 2024 ExpyDoc
