約款が終われば次は「オーダー」から考えるフェーズ

さて、約款も少なくともドラフトとなるものは完成し、ここからは業務・システムを司るバックエンド部門の出番・・・というのは間違いではありませんが、サービス企画を行うフロント部門にもまだまだやるべきことがあります。

なぜなら約款というのは「お客さまから見える側」のサービス仕様であって、その裏側には泥臭くサービスをサービスたるものに支えている「オーダー」があるからです。このオーダーを本来提供したいサービス仕様と突き合わせることによって、業務・システムのアラであったり、サービス仕様として諦めざるを得ない部分などが見えてくるのです。

そのため、サービスをより良いものにしていくためには、バックエンド部門とフロント部門が文字通り力を合わせて進めて行く必要があります。実はここからが本番なのです。



オーダー一つ一つに不整合が無いかをチェックする

「オーダー」とはまさに業務が動き始めるキッカケとなる「注文」のこと。これはお客さまからの場合もあれば、事業者側からの場合もあります。

例えば、「申込」。これはお客さまからのアクション=実際の申込行為によってスタートが切られます。スタートしてからはというと、決められた業務ステップを一つずつこなしながらコマを進めていくわけですが、ここで条件によっては分岐を迎えることがあります。

例えば「申込のキャンセル」の場合。申込をされたけども、利用開始を準備している間にキャンセルとなり、結局課金が開始しないまま去っていかれたお客さまになります。この場合、そもそも「申込のキャンセル」は受け付けるのか?というオーダー種類を選別する必要もありますし、またオーダーの分岐条件として、どこまで進んでいたら受け付けないのか?キャンセルしたときの課金停止処理はいつまでが期限なのか?申込キャンセルした場合には何か別の通知を出すのか?等々の検討が必要になってきます。

「申込」という業務カテゴリを一つ取っただけでもこれだけのバリエーション(分岐)とその分岐ごとの条件があるのですから、一つのサービスを考えるうえでのオーダーはそれこそ無数になります。ですが、このオーダーをすべて洗い出し、一つひとつのオーダーのスタートからエンドまでを辿り、不整合は無いか、途中で途切れてしまうオーダーはないか、そして元々の「サービス企画の思想」に沿ったオーダー処理になっているかを、フロント部門とバックエンド部門で膝を突き合わせて確認しなければ、より完成度の高いサービスはできないと言っても過言では無いでしょう。


web-3706562_1280




ここではバックエンド部門が主導権を握るべき

ただしこのフェーズでは、主導権はバックエンド部門が握るべきです。なぜならばオーダーをすべて洗い出し、またそのオーダーを流れとして構築して分岐まで想定する、という作業をフロント部門はスキルとして持ち合わせていないからです。もちろん万能にできれば越したことは無いのですが、フロント部門はもともと企画屋であり、業務を想像して作り上げることには長けていないことが多いため、ここで一工夫が必要です。

その工夫が、主導権をバックエンド部門が握るということです。バックエンド部門の方は上手くリードしてあげてください。

このオーダー一つ一つを見える化するというフロント部門が慣れていない作業を押し付けて、サービスの立上げそのものが立ち行かなくなるよりは、オーダーを分解して組み上げていくことに慣れているバックエンド部門がたたき台を作り、その内容を両者でレビューしサービス仕様・業務の両面を微調整していく、というスタイルが一つの理想形になるでしょう。

ただし、バックエンド部門からすると、検討していく中で「決まっていないこと」が多いのにはイライラしますので要注意。オーダーベースで精緻に見ていけばいくほどアナが見えてきます。もちろんそのアナに気づくことが目的ですから良いことではあるのですが、すぐにはフロント部門もアナを埋める策を決められるわけではありません。サービス企画は様々なステークホルダーが絡んでくるから尚更です。そのため、バックエンド部門としてはまどろっこしいかもしれませんが少し猶予を与えた上での決定を促す、そんな大人な対応がより良いサービスの構築には必要でしょう。



疲弊していくオペレーション現場とならないために

サービス仕様に対して熱く語ってきたわけですが最後に、コンサルティングをおこなう立場から少しだけ苦言を呈して終えたいと思います。

日本のエネルギーマーケットは全面自由化されてから3年程度とまだまだこれからの市場ですので仕方ないかもしれませんが、往々にしてサービス仕様への意識が低いです。。それはフロント部門ももちろんですが、バックエンド部門も「サービス仕様が根幹となって業務・システムが作り上げられる」ということをまだ確信を持てていないことも原因だと思います。

何でもかんでもフロント部門のムリやお願いを聞くわけではなく、サービス仕様の甘さにより業務・システムが決められない時にはフロント部門にサービス仕様を練り直すように突き返す、ぐらいのことをしなければ、結局サービスが開始されてからしわ寄せが来るのは業務・システ厶です。しわ寄せが来た状態でサービスインしようものなら、オペレーション現場が疲弊していき、次の新サービス追加どころではなくなる・・・という悪循環が始まってしまいます。

「サービスを立ち上げたいのは分かるけど、そう入ってもこれを決めてもらわないと業務・システムが固まりません!」と言うか言わないかで、後々そのサービスやオペレーションに関わる何十人、何百人という人たちに影響がある、と心を鬼にして厳しいことを言う必要があります。

ですが、パワーバランス的にバックエンド部門がこういうことを言いにくいのも事実でして、言うに言えない状況も多々あると思います。

それならば尚更、サービス企画の段階からサービス仕様を意識させ、せめて約款項目が決まってから業務・システム構築を始めるなどバックエンド部門も防衛策を取るべきだと考えます。

まだ生まれて間もない日本のエネルギー業界に「サービス仕様」というコンセプトとメソッドが広がっていくことを切に願います。










にほんブログ村 企業ブログ 電気・ガス・水道・熱供給へ
にほんブログ村