DXとデジタルとアーキテクチャーと経営者と

昨日のブログで、デジタルの真価は、レイヤ構造化と抽象化にあると述べたが、さらに経営という視点で、考えてみよう。

業務プロセスをデジタル化するには、本来、業務を標準化することが必要になる。業務プロセスのムダを洗い出し、効率の良い業務の流れに整流することが前提となる。これについては、ECRS［Eliminate（排除：取り除く）・Combine（結合：つなげる）・Rearrange（交換：組み替える）・Simplify（簡素化：単純にする）の頭文字を並べたもの］として、以前より語られているので、そちらを参考にされるといいだろう。

デジタル化以前に、これをしておく必要がある。それに基づいて、業務の流れをアルゴリズムとして記述し、ソフトウェアに実装しなければならない。その際、どこまでか個別であり、どこまでか共通なのかを、階層化して整理しておく必要がある。具体的には、業務アプリケーション層、共通業務基盤層、共通データ活用・連携基盤層、統合データベース層といったことだ。

ソフトウエアの役割は、シンプルに定義すれば、データを変換する機能を提供することだ。業務プロセスを経る過程で生みだされたデータを、様々なロジックを組み合わせることで別の形態のデータへと変換することで、価値を生みだす役割を担う。

このような構造にしておくことで、データに様々なロジックの組合せを適用し、様々な価値に変換できる柔軟性とスピードが与えられる。それがすなわち、変化への俊敏な対応を可能にする、基本的なメカニズムと言えるだろう。

このような階層化された構造とソフトウエアによるデータ変換の雛形を提供しているのが、ERPパッケージである。つまり、ERPを利用するとは、レイヤ構造化と抽象化を経営に取り入れ変化に俊敏に対応できる経営を実現することにある。個々の業務システムの開発生産性を高めるパーツであるとか、そのためのツールではないことを理解しておく必要があるだろう。

アナログで複雑な個々の業務プロセスをデジタルによってレイア構造化し、次第に抽象化された要素へと分解すれば、それらは特定の業務に依存することはなくなる。例えば、統合データベース上に「顧客データ」が一元的に管理されていれば、それを販売管理業務、経理業務、保守・サポート業務で利用できる。しかし、業務個別にシステムを作り、それぞれのシステム個別に顧客データを管理すれば、それらの整合性を担保することは容易なことではなく、管理負担も増大する。また、新たにオンライン販売をはじめようとした場合に、顧客データを再利用すること、あるいは、オンライン決済やオンラインでのプロモーション機能を組み込むことは、よういなことではない。

レイヤ構造化と抽象化を推し進めておけば、このような新たな業務ニーズに対しても、容易に対処できる。

この構造とプロセスを定めたのがアーキテクチャである。行き着くところ、データから価値を生みだす基本構造を定義したものと説明することができるだろう。

経営者の役割は、このアーキテクチャを定義し、改善を続けながら常に社会や顧客にとって、さらには、自社の収益にとって、最適な状態を維持することにある。DXに取り組むうえでの経営者の役割これに尽きるのではないか。

実装や運用は、それぞれのエキスパートに任せることはできるが、データAをいかなるデータBに置き換えることが、企業価値に結びつくかを定義することは、経営者にしかできない。まさにそれこそが、経営者の役割である。

DXに取り組むとは、このようなデジタルがもたらすレイヤ構造化と抽象化をビジネスに組み入れることだ。そこでの経営者の役割は、どのようにデータを変換すれば経営の価値に結びつくかをあきらかにし、全体のアーキテクチャーを定め、改善することにあると言ってもいいだろう。

CDO(Chef Digital Officer)の役目とは、CEOを補佐して、このアーキテクチャーを作ることにある。決して、データの利活用を高めることに留まるものではない。また、CIOの役割とも被る。事実、米国の進んだ企業であれば、もはやCIOがいない企業もあると聞く。つまり、クラウドの利用と内製化を各業務部門委ね、CDOが示したアーキテクチャーに従って、自律的にシステムを実装、運用しているからだ。

DXの行き着くところは、このような組織運営を実現することなのかも知れない。

＊この内容は「DXの思考法・西山圭太著」を参考に、私なりに再解釈して、整理したものです。