「100%デジタル」で会社を立て直す(1/2)
くじらキャピタルの特徴の1つとして、「100%デジタル」を通じた事業再生、という考えがあります。
会社の顧客接点と基幹系業務を「丸ごと」デジタル化することで、顧客体験を極限まで高めると共に、社内業務の大幅効率化を実現する、というのがその狙いです。
より分かりやすく言うと、
お客様の「旅」の道沿いに、デジタルによって研ぎ澄まされた「おもてなし」を用意し、「あー、この人たちは、自分のことをよく分かっているな」「痒い所に手が届くな」「でも気色悪いところはなく、むしろ非常に心地いいな」「また利用したいな、知り合いにも勧めたいな」と思っていただくこと。
その心地よさが、旅の最初から最後まで、途切れることなく続くこと。旅の途中で突然、「あなた誰?」と聞かれないこと。
さらにそれを、1人だけではなく多くのお客様に同時にご提供すること。
一方でそれを実現する社内の仕組みも「丸ごと」デジタル化されているため、社内の負荷は軽く、誰かが無理をする必要もなく、作業が属人化されることも、部門によって分断されることもなく、余裕をもって、全社一丸となってお客様のために動けること。
これら全てをデジタルによって実現しよう、というのが「100%デジタル」の思想です。
日本語・英語が混じったやや奇妙な言葉ですが、デジタルの力により「おもてなし at scale(スケールするおもてなし)」を実現したいのです。
これは、言われてみると「そりゃそうだよね」と誰しもが思うでしょう。斬新な思想でもなんでもありません。
ではなぜ、これを実現できている会社が、企業規模を問わず極めて少ないのでしょうか?
実はこれ、言うは易しですが、実現には大きなハードルがいくつも立ちはだかっているからなのです。
例えば、見込み客獲得から既存客のアフターフォローまで一貫して活用できる顧客データ基盤を整備しようとする例を考えてみましょう。このジャーニー通貫型データ基盤がないとお客様の「旅」を最初から最後まで追えないので、導入は必須。これに総論反対する人は、おそらくいないでしょう。
では、たとえばこれを導入しようとする時に何が起きるか。
■必然的に部門横断での取り組みになります。今まで、見込み客獲得はマーケティング部門や営業部門、購買データ管理は情報システム部門、アフターフォローはカスタマーサポート部門、みたいな形で分断されていたからです。
■端的に言うと、これまではお客様の都合ではなく、提供者である自社の都合で顧客接点が分断されていたのです。この例でいうと、既存顧客データの主管部門と、見込み客(リード)データの主管部門が分かれている訳です。
■では、この部門横断プロジェクトは、どの部門が主管となるのか? まず、ここで揉めます。主導したい部門同士、あるいはやりたくない部門同士の対立が生まれます。
■導入に向けた予算規模が大きいので、個別部門の予算では賄えないでしょう。では、どの部門がどこまで負担するのか? 「基幹系のデータ基盤なので情シスの予算でやるべきだ」「いやいや、営業拡大の一環なのだから、マーケが持つべき」といった議論が始まります。あるいは「情シスは、すでに既存CRMの拡張プロジェクトを走らせているので、そちらを優先したい」といった事情が露呈します。
■対立を収めるため、そのうち「では、受益者の按分負担としよう」と、よく分からない折衷案が出てきます。なにをもって「受益」というか、あるいは何を基準に「按分」するのか誰も分からないため、発注先のSIerに聞きます。そうすると、綺麗な資料が出てきます。よく分かりませんが、何らかのロジックに基づいた数字の割り振りが書いてあります。(本当の受益者はお客様であり、全社であることは既に忘れられています。)
■みんな釈然としませんが、そのうち調整の過程で声の大きい部門の負担が減り、力の弱い部門の負担が増え、数字の根拠がさらに分からなくなります。
■もはや部門間調整では収拾がつかないので、社長に判断を仰ぎます。ところが社長はITに疎く、判断に必要な基礎知識がありません。それを認めるのが癪なので「ROIは?」ともっともらしく聞きますが、SIerが出してきた回答が怪しい上(利害当事者なので当然です)、その意味するところもよく分からない。ただ、営業管掌の執行役員がどうしてもやるべき、と主張するので「少しだけコストを下げて、しっかりやれ」とGOサインを出す。
■「少しだけコストを下げて、しっかりやれ」というのは、何か具体的な意味のある指示ではなく、「本当はよく分からないが、馬鹿にされたくないので、賢そうな指示を出して議論をまとめたい」という感情の発露に過ぎません。しかし、これを聞いた管理系メンバーや営業管掌の役員は真に受けます。「社長命令だ。ベンダーに言って、xx%くらい下げさせるように」
■それだけコストを下げるとなると、スコープアウトして主要な機能を削るしかありません。SIerは主要機能を削った見積もりを出し、予算内に収めます。何も知らない営業管掌役員は意気軒昂として「ご指示通り、下げさせました!」と社長に報告し、社長も「よくやった!」とご満悦。
■一方で、情シス部門として、運用上必要な機能が削られてしまったので、並行して進んでいた既存CRM拡張プロジェクトでそれを実現することを決断。名目を変えた追加投資を経営に上程し、無事それが承認されたので、別の顧客データ基盤の拡充に走ります。
■同じく声の小さいカスタマーサポート部門は、大嫌いな営業部門が主管する新たなデータ基盤を使うこと(あるいは償却費や利用料を配賦・徴収されること)が嫌なので、情シス主管の拡張基盤を使うことを決めます。
■こうして2つの顧客データ基盤が社内に併存することになります。すると、それぞれのデータテーブル設計が異なり、接続もできないので、「クレームで怒り狂っている既存客に、同じ商品のターゲティング広告をこれでもかと当てて大炎上」みたいな事態が発生し、社内で大問題になります。
■延焼阻止のため、とりあえず、2つのデータ基盤の間に中間テーブルを設置して、日次のバッチ処理で対応する応急処置を行います。設計思想もインフラも異なるためエラーの連続となり、担当者の地獄が始まります。
■なぜ巨費を投じたのに、当初の目的が果たせないのか。なぜ、お客様の旅に最初から最後まで寄り添えず、顧客体験はむしろ悪化しているのか。経営は怒り、混乱します。そこで「今度こそ、統合顧客データ基盤を作る」と決意し、一番上の■に戻るのです。
#くじらキャピタル #人を幸せにする資本 #世界を素敵な会社で埋め尽くす #事業再生ファンド #100パーセントデジタル #デジタル変革
この記事が気に入ったらサポートをしてみませんか?