昨年から導入企業が続々と増えているRPA(ロボティック・プロセス・オートメーション)。働き方改革に向けた労働生産性向上や、人件費削減といった効果が期待され、新しい業務改善の一手として注目されています。
しかしその反面、初めてRPAを導入する企業の中では、ユーザー側での活用や自力での展開にこだわるあまり、外部から適切な支援を受けることをせずにうまくいかないケースもあるようです。そこで今回は、RPA導入時に必要な外部からの支援についてご紹介します。
RPA運用はユーザー部門主体を目指すべき
RPAについて少しおさらいすると、開発者が定義したプログラムに従ってパソコン上の操作を自動化するロボットソフトウェアです。これまでのマクロなどと異なり、複数のアプリケーションにまたがった自動化が可能なので、マニュアルとして作業手順を明確にできる定型業務のほとんどはRPAで自動化することができます。RPAはソフトウェアなのでアプリケーションの一種ととらえて、開発者となるのは情報システム担当者と考えることが多いかもしれませんが、実際にはユーザー部門を主体にRPAを運用する方が、その効果を最大限に引き出すことができます。
RPAが自動化できる定型業務はバックオフィスの業務が中心です。人事、経理、総務などでは定型的な事務処理が多く、作業量も膨大なのでそこに多くのリソースを費やしてしまいます。これをRPAで自動化できれば、ユーザーはより付加価値の高い仕事に集中でき、会社の労働生産性は飛躍的に高まるでしょう。ちなみに営業や企画開発などの業務においても、書類の作成などの定型作業は意外と多いためRPAによる自動化効果が期待できます。
ではなぜ、RPAはユーザー部門が主体となって運用するのがいいのでしょうか？その理由はRPAが継続的かつ短いサイクルで改良を加えて、あくまで現場の業務に即して活用しないといけないからです。
たとえば企業に入社した新入社員は、最初は「何が分からないのかすら分からない」状態です。そのため基本的なビジネスマナーや会社の事業内容、製品やサービスの特徴、業務内容などを徐々に教育していきます。その際には人事部が集合的に研修を行うかもしれません。
しかし、そのあと事業部門に配属すると、そこで仕事を教えるのは人事部ではなく、現場の先輩でしょう。RPAもそんな新入社員と同じです。基本的なシステムとしての動作確認は情報システム部門が行うとしても、実際の業務を知っているのは情報システム部門ではありません。そのため、実際に業務プロセスをRPAに定義する開発業務を行うのは、現場のユーザーでないとうまくいかないのです。また、現場の業務はしばしば変更されます。そのたびに些細な変更でも情報システム部門に依頼していては、なかなか迅速な対応は難しく、結果として業務が滞ってしまうでしょう。
このように、RPAでは導入時に自動化プログラムを開発した後も、業務フローを見直してより効率良い手順で自動化を実行したり、業務内容の変化に応じて自動化プログラムに改良を加える必要があります。企業によってはこうしたサイクルが高頻度で回転するため、ユーザー部門でRPAを運用する方がそういた変化に対しスピーディに対応できるというわけです。
これらのことを考慮すると、RPAのツールの選定時には、開発ツールが一般のユーザーでも容易に理解できるレベルで提供されるものが好ましいでしょう。
ユーザー部門主体で運用するための支援とは
以上のような理由で、最終的な運用はユーザーが主体になるとしても、導入時には情報システムからのPoC支援は絶対条件の一つです。PoCとは「Proof Of Concept」の略であり日本語では「概念実証」と訳されます。一通り全体を作り上げる試作(プロトタイプ)の前段階で、要となる新しいアイデアなどの実現可能性のみを示すために行われる、不完全あるいは部分的なデモンストレーションなどを意味します。
引用：IT用語辞典「POC 【 Proof Of Concept 】 概念実証 / コンセプト実証 / プルーフオブコンセプト」
PoCは本格稼働に入る前の動作検証であり、まず既存の社内システム環境でRPAが認証やネットワーク、OS環境などで基本的な動作ができるのかを確認します。新入社員に対する人事部からの研修のような段階です。RPAは複数のシステムやアプリケーションにまたがって自動化を実行する製品なので、場合によっては特定の環境で動作しない可能性があります。予めRPAの動作要件に準拠していればほとんど問題はないでしょうが、社内には特殊なアプリケーションや環境がある可能性があります。
従って、本格稼働に入ってから不都合が発覚するとそれこそ大問題です。PoCを実行して動作検証を行うことでそうした問題をいち早く検知して、問題があれば本格稼働に入る前に対処します。
このPoCはユーザー部門だけで行える作業ではありません。システム的な観点からの検証、アプリケーションの動作状況、システムをまたいだ自動化実行の際の動作、認証環境の検証、動作環境のアセスメント(評価)など多数の視点からPoCを実行する必要があります。
また、実際にはRPAのベンダーによるサポートも必要でしょう。単純に社内の環境だけでなく、ツール自体の仕様等に依存する部分もあるからです。いくつかのケースを試しながらうまく動作する環境を見つけ出すうえで、ベンダーのサポートがあるほうがスムーズです。製品選定の際には、このようなサポート体制があるかどうかも確認しましょう。
RPA運用のためにユーザー部門でできること
RPAの展開に際しては、ユーザー部門での準備も必要です。最終的にはRPAの運用主体はユーザー部門で行われることが望まれますので、まずは部門ごとにRPA活用のリーダーとなる人材を選出して、情報システムや導入パートナーと連携を取り教育を施していく必要があります。部門ユーザー全員がRPAを開発できるよう環境を整えるという考え方もありますが、チーム内のメンターのように、RPAを育てる先輩社員を選定して、ノウハウが蓄積するようにしてゆくのが効率的です。
結果的には部門ごとに数人のRPAリーダーを選出して、ノウハウの蓄積と情報交換を行いながら運用してゆきましょう。
もう一つの側面は、運用を可能にする人材を育てると同時に、ユーザー部門にファンを育成して組織全体にRPAの存在を浸透させてゆくことも重要です。RPAの推進リーダーを組織的に権威付けするとともに、ロボット開発を気兼ねなく依頼できる機運を作り、組織全体で活用できる土壌を作りましょう。
このように、RPAの成功にはその性格上ユーザーの体制づくりが非常に重要です。社内のリソースで手探りで行うのもよいですが、経験豊富なベンダーにアドバイスをもらうのも有効です。RPAのベンダーにおいて顧客の支援の経験はもちろんですが、そのベンダー自身がユーザーであることも、その知見において非常に大きなポイントになるでしょう。
そのため、自社での導入経験があるなど、ユーザー側の苦労を知っているベンダーを選定するのも重要です。
必要なサポートとベンダー選定のポイント
以上のように、RPAの導入から定着化にかけては情報システム部門とユーザー部門の協力が不可欠であり、最終的にはユーザー部門の体制作りまでがその成否を大きく左右します。その第一歩ともいえるRPAツールの選定においては、システム的なサポート体制と、自らユーザーとしての苦労やノウハウを持っているという2つの視点が重要です。
ツールの活用は、その機能だけではなく、運用の体制が重要であり、いかにスムーズにそのフェーズまでたどり着けるかが大きなカギです。そのためには、すべてを自社で解決するのではなく、外部からの支援も適宜受けることが近道です。RPAのツールを提供していながら、自社でも活用しているなどして、ユーザーとしての経験やノウハウがあるベンダーの支援はより効果があるものになるでしょう。ぜひそのようなスキルのあるベンダーの支援を受けながら、RPAのメリットを最大限に享受してみてください。
