サービス業にサービス(システム）を提供する話

システムを提供する会社だと、受託でシステム開発を請け負って、開発完了して「検収」もらったら終了っていう感覚が一般的。

「納品しました！完了です！」ってやつです。

まあ基幹システム系とか、勘定系とか、その系は、一回「正しく」動けばほぼ触らないからその理論が成り立つのかな。
なので、納品までの道のりも長いしC/Oにて完全稼働になる。

自分の所が抱えているシステムは、そのシステムの特性上、サービス業の方にご提案する事が多い。
そこで、システム（機能）だと思うと「サービス業なめんなっ」ってなるぞって話をしようと思う。

サービス業のシステムを提案すると

　①システム　→　②本部　→③店頭担当者　→　④お客様

という流れで登場人物がでてくる。

一番の利用者が【③店頭担当者】
一番困るのが【④お客様】
という実態を頭では理解していながら忘れてしまうことがままある。社内で「お客様」といえば【②本部】だったり、一次請けだったりする。

でもそれは大きな間違いだと認識した方がいい。

　店頭で、エンドカスタマーが困らないシステムを提供する

のが必須要件である。

実際に【④お客様】直に代金をお預かりして商品をお渡ししている【③店頭担当者】が社の代表であり、それを支える【①システム(サービス）】でなければならない以上、顔が見えないサービスを作ってしまいがちだが。
見る顔は【③店頭担当者】であり【④お客様】でなければならない。

それを理解せずに事を進めると、C/O後いつまでたっても本部が納得しない状況を生み、本部が下からの突き上げを半ば逆切れのようにこちらに向けるというのが発生する。
そこに「検収したのはそっちでしょ」理論は、法的に通用しても心情的には通用しない。

サービス業の店頭を意識するという事は

　・店頭オペレーションを理解し
　・店頭オペレーションを想定して
　・お客様の動きも想定して
　・顧客満足度を落とさないオペレーション水準を担保し
　・お客様に価値を与えられるサービス(システム）を作る

ということになるのではないかと。

どれだけ【④お客様】のオペレーションを正しく理解し、それ以上の気遣いができる要件定義を行うことができるか。
それができていて漸く、【①システム(サービス）】の順調なC/Oと、及第点がもらえるのだ、という前提をチーム全体が持って進めなければならない。

即ち、サービス業にサービス（システム）を売る。というハードルの高さを理解して、それに対応できるPMとエンジニアのアサインが必要。
そして、それをバックアップできる体制や仕組みがなければ、炎上する。

たぶんね。

「システム」を納品していながらも「サービスとしてあるべき姿」に向かって対応（運用）し続ける未来を想像して動く。
サービス業向きサービス(システム）は、運用フェーズに乗った時に真価が問われる。

　いかに店舗運用ができるのか。サービスとして運用できるのか。

サービス業へのシステム展開は本当に難易度が高いなぁ。

最後にひとつ。先輩よりいただいた金言を。

1店舗で1年1回だけ大トラブルが発生するとして、
360店舗あると、サポートする側は、ほぼ毎日大トラブルの対応をすることになるという覚悟。

この覚悟を以って挑め。

ああ心臓が痛い…