「価値創造契約」は対価の設定が問題では無いだろうか
以前、「納品のない受託開発」って厳しいのではみたいな記事*1を書いた都合上、上記スライドについてもコメントしておきたいな、と思います。
永和さんは新しい契約を掲げたものの、顧客獲得につながらなかったとあります。その敗因についてです。
最大のミス ユーザ企業の望む「所有から利用」の意味の取り違い
最近のシステム業界、日本も欧米でも、ITOやBPOといったシステムアウトソーシングが活況だったりして所有から利用がトレンドなのは正しいです。
ただし、ユーザが求めているのって別にシステムを所有しないことではないんですよね。
よく言われることとして、
- 費用明細の明確化
- 無駄払いの無い必要に応じた従量課金 → 固定費の削減
と言った感じで、要はコストが明確となり、無駄なコストを払ってないことがクリアになることが重要なんですよね。
AWSなどをユーザが選択する理由だって、クラウドで開発するため所有してないことではなく、需要に合わせた従量課金となることだったりするわけで。
「案件ごとの一時払い削減よりも継続的な固定費削減」の方がニーズが強いんですよね。
「受託開発」って、お客からしたら「システム開発が必要な場合に都度開発リソースが使える」と考えられている面もあり、開発リソースの「所有から利用」という観点で見られたりする場合もあるんですよね。
なので、今回の永和さんの取り組みは上記取り組みに逆行した「一時払いを減らし、固定費不明瞭化（保守と一次費用である開発の混在）」となるわけで、お客さんからしたら受け入れられづらいのは当然じゃあないかな、と思います。
開発リソースの固定費化ではなく、利用従量制へ
ほんとうの意味で、「所有から利用」を徹底するのであれば、「月額固定費」ではなく、例えば「取引量課金」や「利用アカウント課金」、「画面アクセス課金」等の課金体系であれば上手く言った可能性はあるんじゃないかな、と思います。
つまり、お客さんがビジネスでシステムをどれほど利用したのか、と言った観点で課金するわけです。
こういった契約は、SIerが提供するSaaS/ASPでは古くから見かける課金形態で、業務システムでも適応事例があります。
※とはいえ、ASPでは柔軟なカスタマイズに対応している事例も結構あったりしますが、個社システムで適応事例はさほど見たこと無いんですけどね。。。
ぶっちゃけ、前述のとおり、今の契約ってお客さんから見れば「システムの価値はそのシステムがどれだけ長く使われたかではかれる」という仮説を満たすものではなく、「開発リソースの固定費化。開発リソースの利用から所有へ」と受け止められているだろうと思うわけで、それをひっくり返せば良いと。
このような形態で契約するためには、「顧客の価値」が何なのかをきちんと理解しなければ料金設定できません。
価値創造契約をうたうのであれば、顧客の価値をきちんと掌握することは必須じゃないのかな、と思います。
※とはいえ、epsode6で業務知識がなかったと吐露されているので、ちょっと厳しいのかなと思いますが。。。
まとめ
今回のスライドで挙げられたepisodeって、ほとんどが契約後上手くいかなかった話であり、顧客を獲得できなかった理由じゃ無いんですよね。
とは言え、episodeで挙げられた事由をきちんと解消しなければ、信頼獲得の継続と契約の継続、ひいては顧客獲得の継続につながらないワケで解消することは必要なのは変わらないです。
ただ、現在のepisodeを解消しても、新規顧客獲得につなげるのは厳しいでしょう。
というわけで、色々書きましたが今回顧客が獲得できなかった最大の敗因は契約設定、課金体系設定ではないか、というのがオッサンの意見です。
お客を納得させる「システムの価値」に対する契約、料金体系を設定しないと厳しいんじゃないかなと思います。
以上
