中期的なRPAへの取り組みとRPAやAIを組み込んだ業務改革
第二回 RPAの定着と規模拡大に向けて
第一回目ではRPAやAIの活用による業務構造改革の行く末について紹介した。
第二回目は、RPA導入後における大きな課題のひとつであるRPAの定着と規模を拡大していくためのポイントについて説明する。
RPAの定着と規模拡大に向けて
RPAによりある程度の業務の自動化がなされると、次はRPA上の品質向上や効率化に目的が移行していく。最初のうちは業務を自動で処理できれば、その処理時間やリトライ回数などはさほど気にならないのだが、複数の業務やよりクリティカルな業務をRPAに任せるようになると、ロボットによるシナリオ処理をエラー処理も含めて無駄なく効率的に働かせることが必要になってくる。ここで場合によっては別のRPAソリューションを探すということになる場合もあるかと思うが、複数のRPAソリューションが社内で乱立することは好ましい状況ではないと感じる。なぜなら複数のRPAソリューションを扱うということは①異なるスキルを身につける必要がある、②RPAソリューションのインフラおよび管理コストがかさむ、③RPAソリューション間でシナリオの流用ができない、といったデメリットがついてまわるからだ。仮に複数のRPAを採用されていたとしても、将来的には1~2つのRPAソリューションに集約させることを意識しておくべきだろう。
また、1点認識しておいていただきたいことは、RPAは万能ではないということだ。例えばExcel上の自動化のみであれば、マクロを利用した方が良いケースが往々にして発生する。Excelは人が業務を行うに当たっては大変便利なアプリケーションであるが、人がExcelのみを利用して行っている業務(多くの場合、Excel上でのデータ加工)をそのままRPAに置き換えることはRPAを働かせる環境としてはあまり適しているとはいえない。RPAは様々なシステムやアプリケーション、社外のWebサイトやWebアプリケーションとの間を取り持つことが得意なのであって、特定のシステムやアプリケーションについてはそれぞれのシステム内やアプリケーション内での処理はRPAよりもそれぞれのシステムやアプリケーションの方がやはり得意であることが多い。さらに人の手で行う業務の効率化とRPAによる業務の効率化ではインプットとアウトプットは同じであっても、途中のプロセスは異なることが多い。RPAの働きやすい環境やRPAがより速く、より正確に業務をこなせる方法は業務担当者が思いつかない方法であったりすることもある。こういう場合は大抵IT部門の方と連携することになる。業務部門の担当者はどのような業務を何のために、どのように処理するか、必要なインプット・アウトプットが何なのかはよく理解しているが、利用しているシステムやアプリケーションについてはそれほど深く理解していないことが多い。一方でIT部門の担当者はどの部門でどのようなシステムやアプリケーションが利用されているか、それぞれがどのような機能を持っているかはよく理解している、もしくはメーカなどへの問い合わせが可能だが、それらが各部門でどのように利用されているのかはあまり知ることはない。また、ある業務では複数部門にまたがって処理することが必要なものもあるだろう。このようにRPAの効果を最大化させるためには、業務部門とIT部門、その他関連する部門間を横串で連携するような機関が必要となってくる。この機関をCenter of Excellence(CoE)と呼んでいる。
CoEは何をする組織なのか?
先に述べたとおり、RPAを社内で展開していくにあたっては1業務部門だけで完結できることはありえない。必ず組織間の連携が必要となってくる。また、社内で利用しているシステムやアプリケーションは有限であるから、部門ごとに別々にシナリオを開発するよりも、ある程度集約したり、共有した方が効率的である。そして、過去10年程度を振り返っていただきたいのだが、10年の間に社内組織はどれだけ変わっただろうか?10年前と同じメンバーで仕事をしている人はどれだけいるだろうか?利用しているシステムやアプリケーションはどれだけ変わっただろうか?RPAは人より速く、正確に業務を行うことができる。ただし、教えられていない業務を行うことはできない。世の中の変化に合わせて、社内組織も業務も商材もシステムも変わっていく。特にシステムはクラウド化が進むことによって、自社の手の届かないところでバージョンアップされていく。社内も社外も含めて、RPAがどこでどのように稼動しているかを把握し、変更があれば迅速に対処していく。そのためにCoEのような期間が必要となる
CoEにはいくつかの役割があり、RPAの展開フェーズごとに必要な役割やその重みは異なる。RPAへの取り組み初期段階では、業務部門とIT部門の橋渡しや、社内承認の取り付けなどのRPAを社内で推進する役割が主なものとなる。RPAの定着や社内展開をするにあたっては、RPAガバナンスの検討やRPAの取り組みの発表やRPAの社内トレーニングなどのRPAの社内認知度向上活動などの役割も担う。このようにCoEの役割はRPAの展開フェーズごとに多少異なるが、大きくは社内でのRPA活用の効果を最大化することと社内で稼動するRPAを適正に管理することの2点である。さらに、これからは業務部門の近くで活躍するAIへの取り組みもCoEの中で管理されていくようになっていくだろう。
CoEの構成要素と設置モデル
CoEを構成する際に、NICEでは以下の役割を推奨している。
名称 | 役割 |
---|---|
CoEマネージャ | RPA全体の取りまとめ及びステークフォルダー間の橋渡しを行う |
RPAビジネスアナリスト | 業務課題と自動化対象の選定を行う。業務部門と自動化対象の優先順位付け、シナリオの設計を行い、RPA開発者に引き継ぐ |
RPA技術責任者 | シナリオ開発責任者。シナリオ開発の標準化や品質管理、技術支援を行う |
RPA開発者 | RPA開発ツールを利用してシナリオを作成する |
コネクティビティエンジニア | 連携アプリケーションやシステムとの接続性の管理、メンテナンスを行う |
RPA管理者 | 自動化シナリオの配布先や開発者権限の管理、利用中のシナリオのメンテナンス管理を行う |
RPA展開及び変更管理責任者 | 業務部門への展開及び教育を行う。また、変更管理全般を監督し、変更に伴う業務影響を最小化させるよう注力する |
RPAデータアナリスト | 各自動化シナリオの価値を定義、評価する |
RPAテスター | 例外処理やデータの整合性も含め、開発したシナリオ全体の評価を行う |
NICEのRPAとして、特徴的なのはRPA開発者とコネクティビティエンジニアを別の役割としていることだ。NICEのRPAではシナリオを作成する際に部品化して組み合わせるアプローチを採用している。その部品はワークフローなどのビジネスロジック層、データやファンクションを定義/処理するデータ層、アプリケーションとの接続を制御する物理層などのレイヤーに分割して作成管理する。現在の人手による業務をなぞるようなレコーディングベースのRPAツールも多いため、レイヤーアプローチのRPAツールをご存じない方もおられるかもしれないが、社内で広く展開していくにあたってはレイヤーアプローチの方が既存の部品の共有や流用が可能なため、RPAの活用範囲が大きくなっても、維持管理コストがそれほど増やさずに済む。
少し話が逸れてしまったが、NICEではCoEを9つの構成要素で構成することを推奨している。これはCoEの要素ごとに1名を割り当てる必要があるわけではなく、自社のRPAの展開状況に合わせて構成メンバーを拡大していけばよい。CoE立ち上げ時の構成人数としては3名以上が望ましい。3名で構成する場合は、社内調整をするリーダー(CoEマネージャ、展開および変更管理責任者)と対象業務選定と自動化シナリオの評価を行うアナリスト(ビジネスアナリスト、データアナリスト)、そして自動化シナリオの開発者(技術責任者、管理者、開発者、コネクティビティエンジニア、テスター)のような分担になることが一般的だ。
CoEについては基本的に社内で一元的に管理できるように1部門として集約することが、ガバナンスやコンプライアンスの観点では望ましい。
一方でRPAに期待されるものとしてアジリティやフレキシビリティなどがある。しかし、管理・統制をしっかりしようとすれば機動力や自由度は低下する。そのまた逆も然りである。品質と効率は相反するものであるため、これらのバランスを考える必要がある。部門間の風通しがよい場合は集約型のCoEがうまく機能するが、そうではない場合や業務部門側の変化のスピードが著しい場合にはCoEを分散化したほうが機能をする。CoEを分散化する場合の体制としてはCoE部門を集約設置し、構成要素のリーダーはCoE部門内に持つ。そして、分散する構成要素を業務部門側に設置して連携を図る体制をとることをおすすめする。なお、分散する構成要素としてはビジネスアナリスト、データアナリスト、開発者が効果を発揮するだろう。
自社によるDYIとアウトソース
なお、CoEは自社内のみで構成する必要はなく、アナリスト機能はコンサルタントへ、RPA開発はRPAベンダーへというようにアウトソースすることも可能だ。RPAを自社で全て賄うDYIのアプローチもあるが、DYIで進めようとする場合、外部にコストは発生しない反面、自動化シナリオの作成にはスキル習得も含めて時間がかかるし、RPAの特色を踏まえた効率的なシナリオの作成や適切なエラー処理などの実装には限界がある。RPAをCoEも含めて迅速かつ確実に立ち上げる、また、効果的なシナリオを作成するためにはアウトソースを活用して、社外のスキルやナレッジを吸収しながらRPAに取り組むのが良い。
特にRPAを業務システムと同じように業務のベースに組み入れていく際には、現在の業務の棚卸しから業務構造や組織改変までを見据えた取り組みが必要となってくる。現在の業務を遂行しながらこのような取り組みを推進していくにあたっては、自社内のみでは推進力や継続性を維持していくことが難しい場合がある。このような場合には外部コンサルタントを活用することで、着実にRPAの活用と定着を推進できるようになるだろう。
技術的な側面ではRPAソリューションも日々進化しており、シナリオを作成しやすくなってきている一方で、多機能化も進んできており、シナリオの作成には継続的なスキル習得が必要となっている。また、AIなどと連携させていく際にはある程度の専門性も必要となり、自社内で全てを賄うことは、むしろコスト効率が悪いということにもなりかねない。企業の業態にも依存するが、RPAを利用することのみを目的とするのであれば、日々の変更管理程度までは自社内で対応できるようにしておき、シナリオ作成や高度な連携はアウトソースする方がよい。RPA管理の社内コストは抑えて、RPA活用により創り出した時間を自社ビジネスの発展、拡大に活用するという本来のRPA利用のメリットを存分に享受していただきたいと思う。
次回のコラムでは、NICEのRPAをベースにどのようにRPAを運用していくのかを説明する。また、これからの一年でRPAにどの程度の進化を見込んでいるのかを紹介する。