今回は、ＤＸレポート(経済産業省HP)を元に、ＤＸの取組における障害を乗り越える方法を考えてきたいと思います。

１．日本企業がＤＸに踏み出せないのはなぜか？

米国企業と比較した場合、日本では受託開発によるシステム構築やパッケージを自社業務に合わせてカスタマイズするケースがほとんどです。

一方、米国ではパッケージに合わせて業務を見直し、かつ複数のパッケージを組み合わせて利用することが一般的になっています。

受託開発では、自社の[現時点の]業務手順にあわせてシステムは設計されます。[現時点の]という点がくせ者で、システム開発に1年かかるとすると、業務手順も1年前の状態で止まります。世の中の変化スピードについていくことが難しく、また、新しいIT技術が出てきてもシステムと容易につなぐことはできません。

一方で、パッケージに業務を合わせた場合、パッケージ自体のバージョンアップによってシステムは新しくなります。業務のやり方を変える必要が出てくるので、導入時には現場担当者がシステムの仕様を理解することが重要となります。できる範囲は限られるものの、パラメータを設定することで、自社の業務に近いシステム設定とすることも可能です。

２．DXに強い社内システムを構築するには？

DXレポート内では、自前主義を排除して経営トップのリーダーシップの下で業務プロセスの標準化を進めるべきとあります。

つまり自社独自システムの開発は控えるべきと提言しています。また、同業他社で共通プラットフォームを構築することも提案されています。たとえば商圏が異なる同業者が協力してシステム投資を行うことで、負担を抑えかつ他社の良いところを自社に取り入れることができます。すでにそういったプラットフォームが存在する、あるいは業界に特化したシステムが存在するかもしれません。

まずは自社がどういったシステムを求めているか、要件を整理したうえで、情報収集してください。情報収取より先に要件整理←ここも重量なポイントですので２回書きます。時には、ITコーディネータのような社外の力を借りることも必要になるかと思います。よろず支援拠点でも相談対応いたしております。

システム導入にあたっては、システムの動きに業務を合わせることを、経営層の指導のもとで力強く進めてください。必ず現場からの反発がありますので、現場の声に耳を傾けながらも、システムに業務を合わせるという姿勢を貫いてください。ここは経営層にしかできない仕事です。ＩＴ事業者からカスタマイズの提案を受けたとしても、既に他社で動いているシステムですので、極力手を入れるべきではありません。

また、全ての業務を１つのシステムに任せるのではなく、いくつかのシステムを組み合わせる発想も必要になってきます。似たような機能を、導入した複数のシステムが提供している場合もあるので、どの業務をどのシステムで行うかを、全員が共有できる一覧などで整理しておくことをお勧めします。

３．DXの全体像

DXの取り組みにおいて、システムの持つ役割は大きくSoRとSoEの２に分けられます。

SoRとSoE

SoR・・・System of Recordの略。

社内の業務プロセスを管理するためのシステム。業務の効率化と、業務上で発生するデータの記録が主な目的。蓄積したデータは、データベースを使って整然と保管される。現代の業務システムとよばれるものの大半はSoRに分類される。長く使われれている古い業務システムをレポート内ではレガシーシステムと呼び、レガシーシステムの業務プロセスに合わせて、現在も業務を行っている実情を、レガシー企業文化と痛烈に批判している。

SoE・・・System of Engagementの略。

顧客との関係を強化するためのシステム。ユーザーとのつながりの強化が主な目的。オンラインショッピングや、チャットシステムなどの新た顧客体験創造などの提供を行う。蓄積したデータは、ファイルなどで緩やかな形で保管される。メールやチャットツールなどの情報やり取りの為のツールもここに含まれる。

４．SoRのレガシーからの脱却を進めるためには？

SoRとSoEはDXの両輪とも言えるもので、この２つが連携して初めてDX化は進み始めます。SoRとSoEをつなげる際には、まずはSoRの内情を把握することが重要です。

しかし、独自開発したシステムの仕様がマニュアル化されていない、システム導入に携わったメンバーが辞めてしまった、システムを分析できるエンジニアがいないなどの様々な理由で、内情の把握することも簡単ではありません。

SoRの脱却はクラウドサービスの導入や共通プラットフォームへの参画を前提に進めてください。自社独自のシステム構築は、後々再びレガシー化するため、あまりお勧めできません。

５．SoRとSoEの両輪をつなぐには？

SoRとSoEそれぞれで独立して業務が完結することは無く、普段は意識していないかもしれませんが、人間がそのつなぎ役にとして業務を行っています。現代において事務作業の多くが、SoRとSoEをつなぐための入力作業です。例えば、得意先からメールを受け取って、内容を整理して受注システムに入力するといった業務を当然のように行っているかと思います。それは本来の作業なのでしょうか？本来は得意先から注文をいただくための交渉業務にもっと時間を充てるべきだと思いませんか？

このSoEとSoRの連携こそが、現代においての生産性の最大の阻害要因だと筆者は考えています。連携のルールが決められるなら、そこはシステムに任せられるはずです。例えばAPI連携(※1)やOCR連携(※2)、RPAツール(※3)による連携など、対応したツールは多く提供されています。

※1　API・・・Application Programming Interface の略

※2　OCR・・・Optical Charactor Recognitionの略

※3　RPA・・・Robotic Process Automationの略

６．SoEを自社主導で推進するには？

SoEの領域は時代変化とともに次々と新しいサービスが生まれています。時間をかけて検討していると、システムが完成したときには既に時代遅れになってしまい、他社に先行されているかもしれません。SoEの領域では信頼できるＩＴ企業とのパートナーシップの構築が重要であるとレポートには記されています。

米国では社内にＩＴエンジニアが在籍して、自社サービスの開発を行うことが多いのですが、日本ではＩＴ業者に委託することが大半です。いきなり社内に開発チームを作ることは現実的ではないので、協業できるＩＴ企業を探して、自社のスキルアップを図りながら、緩やかに米国のようなスタイルにシフトしていくことを、ＤＸレポートでは提案しています。現実には、そういったスタイルに対応できるIT企業はまだまだ多くないかと思います。これまでのIT業界の主な仕事は企業ごとの独自システムの開発だったためです。

７．最後に

最後に、私の最も尊敬するダーウィンの言葉を借りて、ブログを閉じたいと思います。

“生き残る種とは、最も強いものではない。最も知的なものでもない。それは、変化に最もよく適応したものである。”

最後までお読みいただきありがとうございました！