Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

定型業務をこなすRPA導入で「臭いものにフタをする」状態になる?「現行通り」の業務自動化は危険!

2018/11/20 06:00

 前回(第2回)ではRPA(Robotics Process Automation)の導入には段階があることを述べ、きれいごとでは済まないRPA導入の難所を取り上げました。第3回は、目の前の業務をそのままRPA化することが正しいことなのか、一段視点を高めて分析することの必要性に触れていきます。

RPA開発は一般的なシステム開発よりもランニングコスト比率が高い

 一般的なシステム開発では、システムをリリースするまでに要したコスト(≒工数)を100%とするなら、リリース後には毎年それの20%近く発生すると言われています。たとえば、あるシステムを構築したとしましょう。サーバー、データベース、監視ツール/ジョブスケジューラーなどの各種ミドルウェアをセットアップし、システム要件を変更しない限り、同じ設定を使い続けます。システムリリース後の作業は、定常的なヘルスチェックやデータの整理整頓が中心で、プログラムバグ/リソース不足によるインシデント対応、セキュリティパッチ適用などが不定期に発生する程度です。

 一方、RPA開発では、リリースまでに要した工数を100%とするなら、リリース後に発生する毎年の工数は50%にも達することがあります。

 たとえば、人手で行っているある業務をRPAツールに置き換えたとしましょう。メールや特定のフォルダに置かれたファイルをイベントトリガーとして、インプットに応じたデスクトップ上の操作が自動実行されます。作業対象ウインドウのフォームやデータ項目は、テキストコード/画像/座標によって読取り/入力処理を行います。デスクトップ上のアイコンが変わった、バージョンアップで見た目(GUI)が変わったというだけで、RPAツールのスクリプト処理は止まります。メールの読み込みや特定アプリケーションの動作が遅延しただけででも思い通りに動かなくなるスクリプトもあるでしょう。この結果、その都度、保守担当者によるスクリプト/パラメーターの修正が発生します。

出典:アクセンチュア作成[画像クリックで拡大表示]

 個々のRPA開発の案件というのは、実はそれほど規模が大きくありません。数FTE(Full Time Equivalents:フルタイム当量)で少しずつリリースするようなものばかりです。一方で一般的なシステム開発はその数倍の規模になるケースが多数あります。ある営業支援システムは導入に60FTE、保守運用は12FTE/年を掛けていました。一方、そのシステムを使用する営業社員の入力支援をRPAツールで置き換えたとき、RPA導入時は6FTEで済みましたが、その後の年間の運用保守にはその半分に当たる3FTEを掛けています。

 このことから言えるのは、マニュアル業務をむやみにRPAツールの処理に置き換えてしまうと、逃れることのできないツール保守運用のボリュームが肥大化し、戦略的な投資への配分がどんどん目減りしてしまうという事実です。業務の生産を高めて戦略的な投資余力を捻出するはずのRPAが、その余力を削り取ってしまうのですから、皮肉というより外にありません。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 中 寛之(ナカ ヒロユキ)

    アクセンチュア株式会社 オペレーションズ本部 シニア・マネージャー。業界を限定せず、先進的システム導入やグローバル展開プロジェクトなどの基盤運用設計領域をリードすることが多く、ITIL上位資格者(ITIL Manager)として、運用改善プロジェクトリードも多数務める。マルチベンダー管理を含む、運用...

バックナンバー

連載:RPA徹底入門
All contents copyright © 2007-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5