コラム
ITの習性を知る② なぜ、ベンダーロックインは起きてしまうのか？
2017.04.27
ジャパンシステム株式会社 コンサルティングアドバイザー
データキュレーション株式会社 代表取締役 寺澤慎祐
記念すべき第１回のコラムはベンダーロックインについて書きました。
第２回は「なぜ、ベンダーロックインは起きてしまうのか？」についてです。
第１回のコラムの最後に「それより何もシステムを統治することができないことが一番の問題です」と書きましたが、ベンダーロックインは起きてしまう理由はまさしくシステムを統治しないからです。しかし、実際は、ベンダーロックインが起きるのでシステムを統治できないのではなく、システムを統治できないのでベンダーロックインが起きてしまうのです。
システムを統治できるということは、自社の業務及びその業務をシステム化したこと自体を管理監督把握できていることです。その逆は、業務システムを管理監督把握できてい無いことです。つまりベンダーに丸投げしてしまうことです。丸投げするということは、技術や製品、システムについて学ぶこともなく、ITについてよくわからないのでシステムインテグレーションベンダーやテクノロジーベンダーにお任せすることであるが、お任せされたベンダーはそれなりに企業論理が働き、そのユーザーにとって最高のシステムを提案したいものの、自社の能力や製品・サービスのことを勘案すると自社にとって都合の良いシステムになってしまうのは致し方ないことでもあります。
私は別にユーザー企業のIT部門がシステムインテグレーションベンダーやテクノロジーベンダーと議論ができるほどにIT知識を得る必要があるとは言っていません。むしろその逆で、ITについてことさらに細かく知る必要はなく、自社の業務内容やその業務をシステム化することで得られる便益についてを細かく知る必要があります。
意外とIT部門が知らないのは自社の業務だったりするわりに、自社システムがORACLEのデータベースで、OSはレッドハット社で、開発言語はJavaで・・・なんてことを知っているのです。そんなことよりこのシステムでどのくらいの業務効率がよくなったのかを定量的に把握していることのほうが重要です。
実は、ベンダーロックインは一つのユーザー企業に一つのベンダーであることは稀で、意外と複数のベンダーによってロックインされています。その理由は、ユーザーがベンダーロックインになるのを嫌がり顧客管理システムはA社、受発注システムはB社、物流システムはC社というように業務毎に違うベンダーになるように調整した結果、システム毎業務毎に特定ベンダーと付き合うことになり、システム毎業務毎にベンダーロックインされるという状況なのです。そのためユーザー企業が一番困るのは複数システムにまたがるサービスを開発したい時です。
上記の例で言えば、受発注システムと物流システムを連携させて顧客サービスを充実扠せようとなると、殆どの場合はB社かC社がそのシステムを担当するか、はたまた全く別のベンダーが担当することになりますが、B社C社がそのような連携システムに前向きで協力的かというとそうでもなくなってしまいます。
ユーザー企業のIT部門がシステムを統治できていれば、IT部門がリードして全体最適や連携を考えれば良いのですが、統治できていなければどちらかのベンダーか全く新しいベンダーに頼ることになります。個々のシステムにおける個別最適と、会社全体のシステムを効率的に動かすための全体最適は相反するようにも見えますが、実は統治する方法は昔からあります。
次回は、システムの個別最適と全体最適についてお話しします。