業務効率化、働き方改革の代表的手段となったRPAですが、使用方法を誤るとむしろ効率を下げる場合もあります。RPA化に適した作業とそうでない作業を2回に分けてお話させていただきます。
①パソコン上の業務であること
RPA化が可能なのは、あくまでパソコンの画面上での業務だけです。RPAで協同ロボットを動かしパソコン外の業務を自動化することも模索されていますが、なかなか実用範囲に達しているものはないのが実情です。
②定型業務であること
現時点でRPA化が可能なのは、定型業務のみです。
定型業務・・・マニュアル化しやすく、誰が行っても同じアウトプットが出るべき業務。
非定形業務・・・マニュアル化しにくく、行った人によって異なるアウトプットが出る業務。
③実行回数が多い業務であること
RPAも所詮はプログラミングです。人間が手で行って数分で終わる作業でも、RPA化にはその数十倍から数百倍、時としてそれ以上の時間を要します。
毎日行い業務の場合、数か月で元が取れる場合もありますが、週に一回だけの業務、年に一回だけの業務を自動化しても望むような効果を得られない場合があります。
④条件の分岐が少ない、もしくは分岐条件をルール化できる業務であること
RPAも人間の感覚的な判断はできません。また、複雑に処理条件が分岐するRPAは開発負荷が高くなります。処理条件の分岐が少ない、少なくとも分岐の条件を数式、もしくは表で表現できることがRPA化の条件となります。
⑤人間の作業負荷が高く、引継ぎが困難な業務であること
①から④と矛盾する場合もありますが、残業等労働時間への悪影響が大きき業務、業務内容が複雑で特定の個人しかできない、属人化してしまった業務に関しては、多少RPA化の開発負荷が高くても自動化した方が良い場合があります。
早朝や深夜の定期的業を自動化すると、労働時間の改善効果が大きいです。
この時の注意点として「属人化した業務をRPA化したら、今度はRPAエンジニアしか行えない業務として属人化した」というパターンです。VBAやPythonなどメンテナンス負荷が少なくエンジニアの総数が多いツールを用いてRPA化すること、ドキュメント類を整備し引継ぎを行いやすくすることも必要です。
⑥MS Office、およびブラウザ内で完結する業務であること
MS Office内で完結する業務はVBAを用いれば自動化できる可能性が高いです。またVBAは20年ほど仕様変更刺されていないため、一度RPA化すると長期間、メンテナンスなしで使用できる場合が多いです。
これには異議を唱える方も多いと思います。「VBAってマクロでしょ?RPAじゃないよね?」。
私はVBAのマクロもRPAの一種だと考えています。PythonでもJAVAでもC言語でも、業務を自動化するためのプログラムは全てRPAだと私は考えています。実際、市販のRPAでもそういった言語で作られていたり、そういった言語を部品としてRPA内で利用することもあります。
プログラミング言語で作っても、市販のツールで作っても、RPAはRPAだと私は考えます。
ブラウザ内で完結する業務もRPA化に適しています。VBAによるIE制御は長期的にメンテナンスなしで使えることがありますし、Seleniumも存在します。ただしWeb上のシステムはバージョンアップにより画面が変わることがあり、その場合RPAが動かなくなるリスクがあります。
いかがだったでしょうか?次回では逆にRPA化に適さない業務に関してお話させていただきます。
Comments