「同業のA社がこうやって成功したらしい」。この情報から企画が始まることは、よくあります。
他社事例を集めること自体は正しい行動です。ただ、そのまま持ち込もうとすると、たいてい途中で止まります。理由は単純で、同じシステムを使い、同じプロセスで、同じ人が働いている会社は存在しないからです。
なぜそのままは使えないのか
同じ業界であっても、実際に見ていくと前提が揃いません。
▶ 使っているシステムが違う
基幹システムも、日々使うツールも違います。「この作業を自動化した」という事例も、そもそも作業の切れ目が違えば同じようには切れません。
▶ 業務プロセスの区切りが違う
同じ「受注処理」でも、どこからどこまでを一人が担当しているかは会社ごとに違います。分担が違えば、変えるべき場所も変わります。
▶ 意思決定の仕方が違う
現場に裁量がある会社と、稟議で決める会社では、同じ施策でも進む速さがまったく違います。
▶ 人の構成が違う
平均年齢、中途と新卒の比率、離職率。どれも、変化の受け止められ方に影響します。
事例に書かれているのは結果と、うまくいった打ち手です。その打ち手が成立した前提条件までは、たいてい書かれていません。
それでも他社事例を見る意味はある
使えないから見なくてよい、という話ではありません。読み方を変えれば役に立ちます。
▶ 打ち手ではなく、課題設定を読む
「何をやったか」ではなく「何を問題だと考えたか」を見ます。ここは業界内で共通していることが多く、自社の課題を言葉にする助けになります。
▶ つまずいた箇所を探す
成功事例でも、途中で何に苦労したかが書かれていれば、そちらのほうが参考になります。うまくいった部分より、詰まった部分のほうが再現しやすいためです。
▶ 社内を動かす材料として使う
「他社もやっている」は、良くも悪くも社内では効きます。ただし、これは着手の理由にはなっても、設計の根拠にはなりません。
最初の設計が、その後のすべてを決める
他社事例を参考にした後で必要になるのが、自社としての設計です。ここを飛ばして「進めながら考える」を選ぶ組織は少なくありません。
進めながら調整すること自体は、悪いことではありません。ただ、それで到達できるのは改善であって、改革ではありません。
▶ 改善でたどり着けるところ
いまのやり方を前提に、無駄を削り、速くする。積み重ねれば確実に効果は出ます。
▶ 改善では届かないところ
そもそもその作業が必要なのか。その分担のままでよいのか。この問いは、進めながらでは出てきません。日々回っているものを止めて考える時間を、意図的に作らないと出せない問いだからです。
変革を掲げているのに改善しかしていない状態は、掲げた目標と実際にやっていることがずれています。
最初に決めておくこと
自社の設計として、着手前に決めておきたいことがあります。
▶ どこを変えないかを決める
すべてを変えることはできません。変えない部分を先に決めると、変える部分に集中できます。
▶ 誰の仕事が、どう変わるかを具体的に書く
「業務効率化」ではなく、「この人のこの作業がなくなり、代わりにこれをする」まで書きます。ここまで書けないなら、まだ設計ができていません。
▶ 何をもって進んだと言うかを決める
導入したかどうかではなく、何が変わったら成功なのか。これを先に決めておかないと、報告の段階で困ります。
▶ 止めるときの条件も決める
うまくいかなかった場合にどうするか。撤退の基準を先に決めておくと、思い切って始められます。
まとめ——参考にはするが、答えは自社にしかない
他社事例は地図ではなく、他人の旅行記です。同じ道を歩いても同じ景色にはなりません。
読むべきは、その人がどこで迷い、何を判断の材料にしたか。そこから自社の地図を自分で書く。この最初の作業を省略した取り組みは、たいてい途中で「思っていたのと違う」に行き着きます。
▶ 今週の一歩
いま参考にしている他社事例を一つ選び、「自社と前提が違う点」を3つ書き出してみてください。3つ出てきた時点で、そのまま真似できないことが分かります。