他社のベストプラクティスを真似しても、他社にはなれない

SaaSの導入を検討していると、ベンダーからこう説明されることがあります。

「この運用がベストプラクティスです」
「他社ではこの形で運用されています」

多くの会社を見てきたベンダーの話ですから、実際にノウハウは蓄積されています。参考にしない手はありません。すでに成功している会社のやり方だと聞けば、自社でも同じようにすればうまくいく気がして、安心もします。

ところが、お客様の業務改革をご一緒していると、そのやり方がそのまま当てはまらない場面によく出会います。

他社の成功事例を真似しても、他社にはなれません。その会社がうまくいった理由は、外から見える業務プロセスやシステムだけにあるわけではないからです。だから私たちは、「ベストプラクティス」という言葉が出てきたときほど、その背景にある前提条件を確認するようにしています。

成功事例は、その会社の条件の上に成り立っている

たとえば、ある会社が営業活動の効率化に成功したとします。訪問中心の営業をオンライン商談中心に切り替え、営業管理をCRMに集約し、見積作成を自動化した。担当者の入力項目も大幅に減らした。その結果、営業生産性が大きく上がった。

これだけ聞くと、同じ仕組みを入れれば自社でも同じ結果が出そうに思えます。

しかし、その会社は扱う商品の種類が少なく、価格体系も単純で、取引条件もある程度そろっていたのかもしれません。ブランド力があり、顧客のほうから問い合わせが来るので、一から細かく説明しなくても商談が進む会社だった可能性もあります。

自社はどうでしょうか。顧客ごとに提案内容が変わり、現場を見なければ見積もれない。価格は案件ごとに調整していて、担当者と顧客の長年の関係が受注を左右する。そういう会社に同じ営業プロセスを入れても、同じ結果が出るとは限りません。

観点	成功事例の会社（想定）	自社
商品	扱う商品の種類が少ない	顧客ごとに提案内容が変わる
価格	価格体系が単純	案件ごとに調整している
取引条件・見積	取引条件がある程度そろっている	現場を見なければ見積もれない
商談の進み方	顧客から問い合わせが来て、細かい説明なしで進む	担当者と顧客の長年の関係が受注を左右する

成功した方法には、成功した理由があります。その理由を見ずに取り入れても、真似できるのは外から見えている部分だけです。

成功企業がやっていることが、成功の理由とは限らない

急成長している企業が、毎朝15分のミーティングをしていたとします。それを見て「うちもやろう」と考える。

けれども、その会社が伸びた本当の理由は、商品の強さだったのかもしれません。市場そのものが伸びていた、採用した人材がよかった、経営判断が当たった、という可能性もあります。毎朝のミーティングは、成長していた会社でたまたま行われていただけ、ということも十分にあり得るのです。

システム選びでも同じです。「有名企業がこのERPを使っている」「業界トップの会社がこの業務フローを採用している」。参考にはなりますが、それだけでは自社も同じものを選ぶ理由になりません。

「標準だから」で業務を変えると、必要な確認まで消える

「一般的によく使われている方法です」と言われるより、「これがベストプラクティスです」と言われたほうが、正解に近く聞こえます。SaaSで「標準ではこの運用です」と言われれば、システムに合わせて自社の業務を変えるべきなのでは、と考えてしまう。

実際、システムに合わせたほうがよい業務もあります。昔から続いているだけの手順や、理由のない二重入力なら、標準的な運用に寄せたほうが楽になります。

困るのは、意味のある業務まで「標準だから」という理由で変えてしまう場合です。

営業担当者の入力負担を減らそうと項目を削ったら、顧客対応に必要な情報まで残らなくなった。承認フローを簡素化したら、自社では必要だった確認が抜けた。在庫を極力持たない運用に変えたら、それまで受けられていた短納期の注文に応えられなくなった。問い合わせ対応を標準化したら、顧客に評価されていた柔軟な対応ができなくなった。

「標準だから」と変えたこと	その結果、失われたもの
営業担当者の入力項目を削った	顧客対応に必要な情報が残らなくなった
承認フローを簡素化した	自社では必要だった確認が抜けた
在庫を極力持たない運用にした	短納期の注文に応えられなくなった
問い合わせ対応を標準化した	顧客に評価されていた柔軟な対応ができなくなった

こうなると、現場から「このやり方では、うちは回りません」という声が上がります。それに対して「新しいやり方に慣れていないだけです」「現場が変化を嫌がっているんです」と説明されることがあります。

たしかに、慣れの問題である場合もあるでしょう。しかし、採用した方法そのものが自社に合っていない可能性もある。現場が抵抗しているからといって、現場が間違っているとは限りません。現場にしか見えていない条件が残っていることもあります。

ベストプラクティスは、答えではなく試すための仮説

誤解のないように書いておくと、私たちはベストプラクティスを否定しているわけではありません。多くの会社で同じサービスがどう使われているかを知っているのは、SaaSベンダーの強みです。その蓄積があるのに、毎回ゼロから考える必要はありません。

ただ、最初から正解としては扱いません。「この会社では、この条件のもとで、この方法がうまくいった」という事例として受け取り、自社でも使えるかを確かめるための仮説として見ます。

確かめるときに見るのは、似ているところより違うところです。顧客の性質が違えば、営業のやり方は変わります。標準品を売るのか、受注生産なのかでも変わる。企業規模が違えば、承認の仕組みも変わってきます。取引量や利益の出し方、社員のスキル、意思決定の速さが違えば、同じシステムでも使われ方が変わります。

そのうえで、まず一部から試します。私たちは、最小構成で動くものを先に作ってお客様に使っていただき、問題があれば直し、うまくいけば広げる、という進め方をとっています。提案する人、作る人、運用する人が同じチームにいるので、試して合わなかった部分も、チームの中でそのまま作り直せます。

他社のベストプラクティスが自社のベストプラクティスになるのは、こうして確かめ、自社に合う形へ変えたあとです。

他社を知っている人だけでは、自社に合う形は決まらない

コンサルタントやシステム会社、SaaSベンダーを使う意味の一つは、彼らが選択肢を知っていることにあります。「他社ではこうしている」「こういう方法もある」「ここは標準機能で対応できる」といった知識です。

一方で、なぜこの手順があるのか。なぜこの顧客だけ処理が違うのか。なぜ営業担当者にこの権限を持たせているのか。なぜこのタイミングで在庫を確保するのか。こうした問いに一番よく答えられるのは、実際にその業務をしている人たちです。外部の人間が短期間ですべてを理解することはできません。

外部が持つ一般的な知見と、お客様が持つ自社固有の知見。どちらか片方だけでは、自社に合う形にはたどり着けません。

ベストプラクティスを知ることと、従うことは違う

間違った選択はしたくない。だからシステム刷新や業務改善では、つい正解を外に求めたくなります。業界のベストプラクティス、大手の成功事例、ベンダーが推奨する標準運用。どれも知っておく価値はあります。

ですが、事業も顧客も人も、会社ごとに違います。他社ではどうしているかを知ったうえで、自社に合うかを考える。合えば取り入れ、合わなければ変え、一部だけ使えるならそこだけ使う。目的は他社の成功事例を再現することではなく、自社の事業を良くすることのはずです。

レザボア・コンサルティングは、一般的な成功事例や方法論をそのまま当てはめることはしません。お客様の業務と事業の前提を確認したうえで、取り入れるもの、変えるもの、残すものを一緒に決め、決めたものを同じチームで作り、動かします。

「SaaSの標準運用に合わせるよう勧められているが、業務を変えてよいのか判断がつかない」「他社事例を紹介されたが、自社との違いを整理したい」。そうした段階からご相談いただけます。