情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

DXを現場に丸投げすると自動化だけが進む。そして経営者は勘違いする

2024

1/19

DXを現場に丸投げすると自動化だけが進む。そして経営者は勘違いする

華々しい他社事例

「競合のX社がRPAで○○万時間削減したみたいなので、ウチもDXの柱にしたい」

ある現場の社長に言われました。某雑誌を持ってきて、RPAの特集記事を見せてくれます。

そこにはRPAによる自動化例が紹介されていました。
・手書き帳票を「自動読み取り」
・FAXデータをシステムに「自動入力」
・取引先別の書式で請求書を「自動作成」
・請求書を「自動PDF化&送付」
・Excelから基幹システムへの「自動連携」

世の中は便利になったものです。PCで行う事務作業はほとんど「自動化」できそうです。

そして次のページをめくると、付箋がたくさん貼られてありました。

各社の華々しい効果が列挙されています。
・A社37万時間削減/年
・B社10万時間削減/年
・C社12万時間削減/年
・D社844万時間削減/年
・E社130万時間削減/年

世の中は「人手不足」です。これだけ「省力化」できれば、経営層が目の色を変えるのもわからなくもないです。

ただ、これは本当にDXなのでしょうか?

自動化事例の別解

私は、上記の「自動化」には別解があると考えています。

・手書き帳票を「自動読み取り」⇒手書き廃止
・FAXデータをシステムに「自動入力」⇒FAX廃止
・取引先別の書式で請求書を「自動作成」⇒書式統合・標準化
・請求書を「自動PDF化&送付」⇒Web請求
・Excelから基幹システムへの「自動連携」⇒基幹システム刷新

左側は、現在の業務フローの延長線上にある「デジタル化」です。
右側は、業務の流れや在り方を変える「トランスフォーメーション」です。

「デジタル」で「トランスフォーメーション」するからDXではないでしょうか。

現場に近すぎる

私は、RPAほど扱いが難しいモノはないと考えます。なぜか?

それは「現場に近すぎる」からです。

プログラミング知識がなくても、要領を得れば、現場でお手軽に実装できてしまいます。

このフットワークの軽さが最大のメリットですが、最大のデメリットにもなります。

そもそも、現場には業務構造を大きく変えたり、ビジネスモデルを変革したりする「権限」はありません。せいぜいAs-Isの業務フローのまま、同じ業務プロセスをそのまま「自動化」するのが「裁量の範囲」です。

ここにRPAはピタッとハマります。

そして、これは現場にとっては「成功体験」となります。さらなる自動化を精力的に行い、As-Isのまま、どんどんプロセスがRPAで「固定化」されていきます。

本来はイレギュラーをなくし、標準化を考え、フローをシンプルにし、新しい業務の在り方、つまり「To-Be」を考えるべきですが、RPAを手にすると「とりあえず自動化」が進んでしまいます。

As-Isが正当化していくのです。

そして、現場を把握していない経営層は都合よく「自動化効果」だけを切り取ります。年間○○人分の人件費が浮く、「これこそDXだ!」と壮大な勘違いが進みます。

さらには、味をしめた経営層はこれを「全社展開」していきます。部署間で競わせ、次年度の事業計画の目標数値に設定させます。

全社をあげて部分最適化だけが進み、聖域が増えます。

それは、逆に大きな変革ができなくなっていくということ。

さらには、自動化しまくった担当者が異動すると、その領域はブラックボックス化し、業務継続リスクまで高まります。

問題の根幹

この問題の根幹は何でしょうか?

それは、経営層がDXを現場に「丸投げ」しているからです。

本当の意味での変革、巨大な投資判断、業務構造改革、ビジネスモデルチェンジなどは、「経営判断」です。

まずは大きな戦略や方針を経営層が決めて、その具体化を現場に投げる。この「順番」こそが重要です。

その最初のステップを経営層が思考停止し、責任放棄するから、現場は自分たちの権限の中で「部分最適化」にしか走れないのです。

DXの「D」は手段、「X」が変革です。この「X」に経営層が主体的に関与せずに、DXは成り立つのでしょうか?

大きな変革を成し遂げるためには、まず経営層が「IT戦略」を立て、大枠を現場に示すことが大前提なのです。その先にDXの各プロジェクトが定義されます。

自動化ツールは悪いわけではありません。全体最適化の後の「ラストワンマイル」を埋める手段としては、とても素晴らしいと思います。

繰り返しとなりますが「順番」が大事です。これが先に来てはいけないのです。

時代は繰り返す

「RPAの限界は知っているので、ウチには関係ない」
と思っている人は多いかもしれません。

しかし、この話の恐ろしいところは、名前を変えて次のブームが到来していることです。

それは「ローコード/ノーコード開発」です。

これも現場でお手軽に導入でき、ベンダーやコンサルタントは「DX人材育成」という耳障りの良い言葉で、押し込んできます。

RPAに触手を伸ばした人は、ほぼ全員がローコード/ノーコードに飛びついているようにみえます(そしてRPAとの違いを必死に説明しています)。

現在は「内製化ブーム」にも乗っかり、どの現場でも検討/導入が進んでいるのではないでしょうか。

(ちなみに、一昔前は「Excelマクロ&EUC」でした・笑)

他社事例が列挙され、DXの文脈で煽られると、DXにノーアイデアの経営層は飛びつきます。そして、全社をあげた壮大な「ボタンの掛け違い」が始まります。

この構図は、いつの時代も変わらないのかもしれませんね。

貴社のIT部門・情報システム部門は、「デジタル」で「トランスフォーメーション」できていますでしょうか?

関連コラム

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか

情シスコンサルタント
田村 昇平

情シス(IT部門、情報システム部門)を支援するコンサルタント。

支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。

多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。

また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。

「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。

著書の詳細は、こちらをご覧ください。