Esmose

コラムを読む

Step3.サービスの歯車、しくみを作る

しくみの「改善」と「更新」


しくみにはハードや基本サービスにはない、改善され更新されるという特徴がある。

ハードは一度できあがってしまうと大幅に変更するのは難しい。
基本サービスは「これを提供する」と決めたら必ずそれを提供するのだから、基本的に改善や更新はしない。

けれども、しくみは基本サービスを提供するために何でも行う役割なので、ダメなものを捨て、より良くしていくことに力を入れていかなくてはならない。
サービスは正確に提供されているのに、オペレーションに不備があってサービス提供が遅れているのなら、オペレーションの不備を改善して早く提供できるようにする。
ルールが定まっていることで、逆にサービス提供の足かせになっていることがあれば、ルールは改善され、更新され続ける

このように改善と更新が必要なオペレーションとルールは、マニュアルによって定められる。
ということはつまり、マニュアルは唯一無二で絶対のバイブルではなく、更新され続けるデータベースであると考えた方がわかりやすいし、的確だといえる。

どのような場合に、どのような手順で、改善と更新が組み込まれるかと決めることもしくみ作りには必要で、このこともマニュアルに書き残してルール化される。

しくみされていなければこうなる

しくみが決まっていなければ、真面目に、正確にサービスを提供しようとする提供者ほど、売上げを圧迫することでしか解決できないことがある。

たとえば、私はお気に入りのスエードの黒い靴を持っている。
銀座のある店舗の銘柄なのだが、形も履きやすさも私好みで、だからその靴はよく履く。
それだけにかかとの裏が磨り減るのが早く、年に一度は修理に出していた。
かかとの修理と新しい商品の取り付けは、このお店のルールとして3000円で行うというしくみ(サービス提供後のしくみ)があった。
私はそれを利用していた。

ところが3年目に入ったある日、スエードの一部分が破れてしまった。
靴下が見えるような構造にはなっていないものの、見てくれは悪いし、雨の日は濡れてしまう。
そこでいつもかかとを取り替えてもらっている銀座店に靴を持っていき、修理できるのかどうかということを聞いた。
しかし残念なことに、修理は不可能だということだった。

そこでこのお店では、サービスの信用を守るために私に新品の同じ靴を用意してくれた。
これはサービスを必ず提供すると約束している提供者の立場としては間違った行いではない。
むしろ非常に正しい。

しかし私は新品の靴を改めて用意すると決まるまでの過程や、店員の説明のぎこちなさなどを併せて考えてみて、このようなケースへの対処はしくみ化されていないのだと感じた。

たとえば、「2年間は無料で保証しますが、それを超えた場合に、全く同じ靴をお買い求めいただく場合は定価の二割引でご購入いただく」というしくみはあっていいだろう。
なぜなら、かかと部分の交換など、想定される問題は有料で対応しているのだから、それを超える不具合が有料でもおかしくない。

しかしもっと大切なのことは、程度が軽ければ有料で具合がひどければ新品というのは、お客から見てもサービスが公平ではないということである。
もちろん新品を手に入れると気分はいいし、「これからもこの店で買おう」と思うかもしれない。
しかし考えられた完全なサービスとはいえない。

サービスを提供するという約束はきっちりと守られているものの、これでは何か問題が起こるたびに、提供者は利益を圧迫されてしまう。
利益が圧迫されると靴の新商品開発に影響があるかもしれないし、人件費を削減しなくてはならなくなるかもしれない。
そうすると、結局は正確にサービスが提供されなくなってしまう。

しくみによってサービスを形作るのは、お客のためであることはもちろん、サービス提供者のためでもあり、その結果としてサービスの継続提供するという約束を守るためでもある。

加える改善、削除する改善と更新

改善とマニュアルの更新というと難しく聞こえるかもしれないけれども、わかりやすい考え方として「支払方法」がある。
たとえば、インターネットで商品を販売するのであれば、銀行振り込みだけを受け付けていた支払いの方法から、代引きを加えることでサービスを利用しやすくなるお客もいるだろう。
飲食店であれば現金払いに加えて、クレジットカードで支払うことができるようにする。

そうすると、クレジットカードの支払いに関する書類の事務処理、財務処理などを新しく業務に反映しなくてはならなくなる。
その手順や方法もルールー化してマニュアルを更新する。

この方法は既にサービス利用者となったお客の声に耳を傾けることと同じように、サービスを利用するには今一歩踏み出せない、利用者ではないお客の声にも耳を傾ける必要がある。
それぞれのお客が求めるポイントは違っていて、両方を改善の対象に入れなくてはならない。

ではたとえば両方の声が複数上がった場合に、そのどちらがより大切かというと、それを判断するためにコンセプトを基準にして優先順位をつけるようにする。
売上げを目的にすると利用者ではないお客の声に応えることになり、顧客満足を目的にすると利用者であるお客の声に応えることになってしまう。
基準がどうしても一方的になってしまうので、このような場合は原点に返って、なぜこのサービスを提供しているのかという意味を見出してくれるコンセプトを基準にした方がいい。

加える改善があれば、削除する改善もある。
削除する改善は、お客は「それは別に必要ないかな」となんとなく感じてはいるが、特に迷惑ではないのではっきりと気がつかないという特徴がある。
したがって、お客の声に耳を傾けても削除する改善はなかなか見つからない。

削除する改善は、仕事に注目することからはじめる。
仕事のプロセスを分解してあまり強い意味を持たない作業を止める。
手順は増える一方で収集がつかなくなることが多いので、定期的に作業を削除するためのミーティングを開いた方がいい。

削除には別の見方もある。
同じ質のクレームが発生するのは共通の原因がある可能性がある。
たとえば、7アクトでは月会費を事業運営の維持費として支払ってもらっている。
これを最初、サービス利用料という名目にしたらクレームが出た。
具体的に何のサービスを提供されているのかという意味がお客に見えにくかった。
そしてそれを「維持費としていただいています」と説明するように改善すると、「確かにこの価格でどうやって維持されているのかと思っていました」という声に変わった。

配送業で配送ミスがあったり、レストランでオーダーミスがあったり、何かミスがあるときは構造的にそのミスが起こるようにできている可能性がある。
ミスが起こる、イコール改善とマニュアルの更新を行う、という「しくみ」を作っておくことで、しくみの管理はうまく行うことができる。
そして一度改善したら、万が一同じ配送ミスやオーダーミスがあったときにどのように迅速に対応するのかも併せてしくみ化しておく。

この両方をしくみ化することで、大本の原因を解決し、万が一の場合にも備えることができるようになる。
さらにできれば、改善と更新はいつ、どのように行なわれるかというルールも決める。

でなくては、状況と問題対応が変わるたびにマニュアルが更新され、混乱してしまうだけになる。
そうなると現場では結局ケース・バイ・ケースになってしまうので、改善の方法と時期を決めることで長期的にサービス提供をスムーズにする。

しくみ作りは、サービス提供前・提供中・提供後の3つの流れに関わるトータルサービスと、改善・更新のルールを決めることが基本作業となる。

トップに戻るボタン