他人任せDXのツケ

　RPAを活用したDXが暗礁に乗り上げた。

　会社の方針では業務部門が自らRPAを活用してDXを推進することになっていた。

　しかし、RPAで業務を効率化すべき対象の業務部門は忙しすぎた。

　忙しい故に、RPAによる自動化に夢を見た。

　同時に、RPAを学習して自らの業務を変革する余裕すらなかった。

　そこで、IT部門が親切心からロボット開発の代行を申し出た。

　RPAの技術習得も兼ねて。

　業務部門は「渡りに船」とその申し出に飛び乗った。

　かくして、従来の業務システム開発と同じように要件定義から始めてロボットの開発を進めた。

　業務部門は業務効率化の夢をIT部門に託して要件を伝えた。

　IT部門は業務部門の期待に応えようと完璧なロボット開発に挑んだ。

　しかし、相変わらず業務部門は忙しく、夢は語れど、

　詳細な業務分析やデータ分析には十分な時間が割けなかった。

　IT部門は業務分析に不安を感じながらなんとかロボットの開発を進めた。

　RPAはノーコード開発ツールとはいえ不慣れなIT部門は10ケ月格闘した。
　そして、ようやく何とか動くものができたと思った時に事態は急変した。

　ロボットが必要とするデータが連携システムに無いことが発覚した。
　

　業務部門からはデータは存在すると聞いており信じていた。

　そのデータが連携システムに無ければ、どこから取得するのか？

　毎回、業務担当者がデータを準備する必要があるのか？

　もし、そのデータが否定形であり、人の判断を要するものなら、

　そもそも、RPA化には不向きな業務だとすれば、10カ月が水泡に帰す！

　IT部門の好意、本業故にRPAに10カ月を投じたことも罪作りな結果になった。

　業務部門の話を鵜呑みにして、データの実在を確認しなかった。

　それもお粗末な話だが、、、

　業務部門が他人任せにせず、RPAによるDXを自ら進めていればもっと早く気が付いたであろう。

　IT部門のようにRPA開発にドップリと浸ることもなかったはずだ。
　本業の合間にやれる範囲でやれることを考えたに違いない。

　他人任せのDXで、業務効率化し楽を手に入れようとしたツケは決して小さくはない。

　最初の一歩は高い勉強代となった。
　

　*********************************************
　孫子の兵法　九変篇　将に五危あり

　将軍のしてはいけない危険な５つのことがある。
　１．必死の覚悟は、盲目的となり殺される。
　２．是が非でも生きようとすると、捕虜になる。
　３．興奮しやすいのは、侮られる。
　４．潔癖症は、辱められることになる。
　５．民を愛しすぎれば、煩まされる。
　
　*********************************************