「そのRPA、DXの足を引っ張ってない？」――企業が考えるべき現実的な組み合わせとは：Mostly Harmless（2/3 ページ）

[大越章司，ITmedia]

それは本当にRPAの成功事例なのか？

　下記の記事は、RPAで業務の効率化が達成できたというものです。

• 4人で対応していたデータ転記をRPAで代替しこだわりの結婚式を具現化する顧客対応に注力（IT Leaders）

　しかし、タイトルの「データ転記」からして、嫌な予感がします。内容は下記の通りです。

結婚情報メディアが運営するWebサイトの仕組みはおおむね共通しており、顧客が専用フォームから会場見学予約や問い合わせのアクションを起こすと、ブライダル業者の所定のアドレスにアラートメールが送信されるようになっている。

　ここまではよいです。しかし、下記の箇所から一気に雲行きが怪しくなります。

データの一括ダウンロード機能を用意しているWebサイトは限られ、多くの場合はカスタマーセンターの担当者がコピー＆ペーストを繰り返して自社の基幹システムに再入力することとなる。

　読み進めます。

予約や問い合わせがいつ入ってくるか読めないのでピークに合わせた人繰り計画が立てにくい一方で、1日でかなりの件数に対応しなければならないため現場の作業負荷はことのほか大きい。やむなくカスタマーセンターでは、4人体制で毎日シフトを組んで対処していた。

　やはりそうなりますよね。この後は、「RPAの導入によって劇的に効率が上がった」と続きます。

　これはこれでよい結果だと思います。しかし、私が抱いた違和感とは、「そもそも、『データ転記』自体がビジネスプロセスとして問題であり、理想的には『最初からデータ転記しなくても済むようにシステムを作る方がよいのではないか？』」ということです。

　このシステムを分解してみると下記になります。

1. 「結婚情報メディアが運営するWebサイト」に問い合わせが入る
2. ブライダル業者の所定のアドレスにアラートメールが送信される
3. ブライダル業者はWebサイトにログインして内容を確認
4. 内容を画面上でWebサイトから基幹システムにコピー＆ペースト

　つまり、3から4へのデータ転記に手間がかかっているわけです。そこをRPAで自動化すると、もちろん効率は上がるでしょう。

　しかし、本来あるべき“DX的な”理想の形は、「最初からWebサイト上で、内容確認から顧客管理、スケジューリングまでできるように設計する」または「APIを用意し、Webサイトから業者の基幹システムへ自動でデータが流れるようにする」だと思います。

　もちろん私はこのケースの詳細を知っているわけではありません。こういったシステムの場合、分かっていても構築時に、スケジュールや予算の問題で、そこまでできないという状況は起こりがちです。「後で時間ができたらやろう」と思っていたのが、結局延び延びになることもありえます。

　ただこの課題を“システムの外側”でRPAのみで解決してしまおうとすると、このシステムが今後“あるべき姿”に修正される可能性は低くなるでしょう。それは、DXへの道が遠のく（＝チャンスを失う）ということになります。