改善が失敗する理由　その弐

　昨日の記事【改善が失敗する理由　その壱】では、改善手法をつまみ食いして始めると、その改善は失敗することをお伝えしました。

　今日はその第２弾になります。

　改善を始める時、どのようなスタートを切られるでしょうか。

　意外に感じられるかもしれませんが、そこに大きな落とし穴があるのです。

『全社的に取り組みを開始する』は失敗する

　全社的に取り組みを開始する。

　どの企業でもよくあることでしょう。

　でもこれが大きな落とし穴なのです。

　ちょっと考えれば分かることですが、どの部署も同じ忙しさでしょうか？

　どの部署も同じリソースを有しているでしょうか？

　どの部署も同じパフォーマンスを有しているでしょうか？

　改善活動を全社的に展開した場合、そのリソースが割ける部署と割けない部署が出てくるのです。

　そうなると、改善結果に大きな差が出てきます。

　改善結果が出ているところは良いですが、そうでないところは改善活動がどんどん苦痛になってきます。

　日々の忙しさに追われ、その上改善活動も追加され、必死になってやってもリソース不足で結果が出せない。

　しかも、改善結果によって評価されるとなれば、リソースの少ない部署はどんどんやる気を失っていくでしょう。

　そしてそうしたところは1カ所では済みません。

　大凡ですが、成果を出せるところが2割で、残りの8割は十分な成果が出せないか、活動ができていない状態に陥ります。

　そうなれば『全社的取り組み』は失敗したも同然です。

　各部門、各部署が持っているリソースやパフォーマンスを無視して、全社的な取り組みを開始すると、このような落とし穴にはまってしまうのです。

あえて一番忙しい部署でテストする

　新しい改善手法を導入する時は、組織や企業の中で一番忙しい部署（組織としての最小単位で、メンバーは10人未満）でテストをします。

　信じられないかも知れませんが、一番忙しい部署というのは、一番リソースが足りてない部署になります。

　そこで新しい改善手法を試して、上手く行ったのなら、その改善手法をその部門に広げ、部門で上手く行ったのなら、全社的取り組みを開始する。

　このように段階を経て、全社的取り組みを行っていくのが正解です。

段階を踏むことで得られるメリット

　例えば今流行のDX（デジタルトランスフォーメーション）が良い例になります。

　DXを導入するといっても、簡単なことではありません。

　多額の投資が必要になりますし、導入にかかる手間も相当なものになります。

　だからこそ、いきなり全社展開するのではなく、一部の部署や部門でテストを行うのです。

　そして、良かった点と足りなかった点を出して検証し、修正すべき点は修正して、テストを続けます。

　何度かこうしたテストを繰り返すことで、新しい改善手法の検証ができます。

　もし、十分な結果が出ない（出せない）と判断したのなら、この時点でやめれば良いのです。

　こうすることで、改善手法の検証が手早くできるだけでなく、投資額もかかるコストも少なくてすみますし、何より元に戻す手間も少なく済みます。

もう一つのポイント

　この新しい改善手法を導入する時、忙しい部署のメンバーに改善をやらせるのではなく、他の部署からメンバーを集めて、その部署の改善を補助してもらうのです。

　忙しい部署のメンバーに改善を担当させればどうなるかは先ほど説明した通りです。

　だからこそ、他の部署からメンバーを集め、その忙しい部署を助けるために改善活動をやってもらうのです。

　すると、改善結果が出れば出るほど、忙しい部署はどんどん楽になっていきます。

　実際、組織や企業で一番忙しい部署というのは、その組織や企業の【ボトルネック】である場合がほとんどです。

　そこのパフォーマンスが改善されれば、ほぼ間違いなく組織や企業の収益が改善されます。

　それに、改善手法を実践しているのは、他部署のメンバーですから、次にテストの範囲を広げる時に、すでに実戦経験のあるメンバーがいる部署を選ぶことができます。

　そうなれば、そのメンバーはどうすれば成功するかが分かっているので、次のテストも成功する確率がグンッと上がるのです。

　いくつかの部署や部門での成功例が重なってきたら、そこで全社的な展開に切り替えれば良いのです。

　先にお伝えしたDXを導入する場合でも、このやり方は非常に有効です。

　逆に、DXの営業マンが進めてくるような全社的な取り組みは、このような段階を踏まない分、机上の空論で終わる可能性が圧倒的に高いのです。

最後に

　新しい改善手法を導入する時は、以下のやり方が良いでしょう。

 ○ 全社的ではなく一部の部署（最小単位の組織）でテストする。

 ○ 社内や組織内で一番忙しい部署でテストをする。

 ○ 改善を担当するメンバーは他部署から集める。

　そして今回のやり方で得られるメリットは以下の通りです。

 ※ 一部の部署で始めることで自社に合っているかの検証と確認ができる

 ※ 投資額や導入にかかるコストを抑えられる

 ※ 上手く行かないと判断したらすぐにやめられる

 ※ 忙しい部署でやるので、改善成果が出た時の効果・成果が大きい

 ※ 経験済みのメンバーが揃うので、部門・全社的に広げやすい

 ※ 社内に助け合いの気風が生まれてくる

　全社的な取り組みを優先させると、各部署のリソースのばらつきによって、結果にばらつきが出てしまう。

　その結果、全社的取り組みが失敗に終わる危険性が非常に高いのです。