運営会社
UiPath担当のChewbaccaです。
誰がやっても同じ結果になる単純な定型業務はRPAに置き換えるべきですが、具体的にはどんな業務が当てはまるのか、改めて考えてみました。
RPAに向かない業務
まずは、逆にRPAには向かない業務を考えてみました。
RPAは定型のシナリオに沿った作業しかできませんので、プロセスが定型化されていない業務や判断を含む業務には向きません。
判断を含む業務に導入するには、判断を必要とする作業で処理を一時停止し、人間が判断した後に、処理を再開するなどの人間の作業補助的な使い方となります。
作業内容の変更やイレギュラーが頻繁に発生する業務にも不向きと考えられます。
例えば、ファイルの名前や保存場所、アプリケーションのデザインやインターフェースが頻繁に修正される場合には、その都度、変更箇所の特定とシナリオの修正といった対応が必要となる為、場合によっては、運用の変更やアプリケーションの更新を見送る判断が必要になる場合もあると考えられます。
イレギュラーについても同様で、導入時に想定されうる例外であればともかく、頻繁に例外が生じる様な場合、その都度シナリオの修正が必要となり、例外処理を多く組み込む事になればシナリオが煩雑となり、可読性の低下や保守管理コストの増加につながります。
また、実行頻度の低い業務についても導入と保守コストに見合うかどうか、慎重に検討する必要があると考えられます。
従って、こういった業務はRPAには向かない、もしくは導入を検討する際には現時点だけでなく近い将来も踏まえて検討する必要があると言えそうです。
RPAに向いている業務
結論として、以下の要件を満たす様な業務がRPAに向いていると言えそうです。
・長期間大きな仕様変更がない見込みの業務
・何度も繰り返す必要がある大量の定型業務
・イレギュラーがない業務（イレギュラーの種類が例外処理でカバーできる程度の業務）
例えば自社システムであれば、将来的な仕様変更の有無の確認も容易でしょうし、RPA導入後も、RPAへの影響を踏まえた仕様変更の是非を検討できる為、導入に向いているといえそうです。
また、自社のレガシーシステムを含めた、様々な用途の相互連携しないシステムが乱立する中での「つなぎ」の役割を果たすのに向いていると考えられます。
例えば、システムAの画面を見ながら、システムAの内容をシステムBに入力する作業などがあるかと思いますが、そういった業務を自動化する為に大きな時間と費用をかけてシステム連携の仕組みを構築したり、システムの一元化を図るのではなく、RPAで人間の代わりに業務をさせるといった選択肢はコストと時間の面からも十分あり得ると考えられます。
また、OCRなどと連携すれば、紙に書かれた内容の読み取りも可能ですので、人間が手作業していたデータ入力作業などを自動化でき、人間がストレスに感じる単純な繰り返し作業もRPAならその心配はないので、要件を満たす業務であれば積極的にRPAの導入を検討するべきと思われます。
RPAの導入に成功した暁には、人的エラーや業務のやり忘れを抑止し、なにより単純作業に割いていた時間を削減し、その創出した時間でAIにもできない付加価値の高い創造的な仕事に充てることができる様になるでしょう。
皆様の業務の中で、これらに当てはまりそうな業務がありますでしょうか。
ぜひとも一度ご相談いただけましたらと思います。
