RPAは基本的に業務ユーザ自身が使うツールです。一旦RPAで自動化しても業務は変化するもので、顧客都合で例外処理が発生したりもします。やはり自社でRPAシナリオを開発し運用するノウハウを獲得していく必要があります。
RPAをソフトウエアツールとして使いこなす本質的な組織能力を身に着けて頂くための方向性をご説明しています。
RPAはユーザが習得すべきツール
RPA は基本的に Excel や Word 、パワーポイントなどのオフィス製品と同様に業務ユーザーの方々が自身で使いこなせるようになるべきツールだと思います。
プログラミング不要
RPAの中には、サーバー開発型のように大規模プロジェクトを実施し、システム開発・導入が必要なタイプもあります。しかし、先ずは毎日残業してこなしているPC雑務を効率化するPC導入型を使ってみることをお勧めしています。RPAの場合、基本的にExcelマクロのようなプログラムすら開発する必要がありません。
なぜなら、現代のビジネス環境では【時間が命】であり、時間を金額に換算する必要があります。（通常は割引計算と言います）
大規模に数ヶ月のプロジェクトで業務を整理していたのでは、完成した頃には業務が変わってしまっている可能性もあり、早期に効果を刈り取る意識が重要
迷うより今日から始める
今日から始めましょう。多くの企業にとって既に迷うような金額では無いと思います。正社員の方の残業代や、仮に派遣社員、パートさんにお願いした場合と比べて遥かに安価です。１年間の契約が必要な点はありますが、迷うような金額では無いように思います。
RPAは短期でクイックに導入
RPAの本質的な理解が重要
単にRPAをツールとして使うスキルを身につけるトレーニングではなく、RPAにはコーチング型の導入とその後のサポートが必要と考えています。なぜなら、会社の業務は常に変化し、顧客都合などで常に例外が発生するものだからです。
よって、社員の方がRPAの本質を理解し、この様な例外や変化への対応を自分で考えて実施していく必要があるのです。幸い、RPAは過去のExcelマクロやノーツDBの様に特定のプログラミングスキルが必要無いものです。
業務をよく理解していれば、RPAの本質的な理解をする事で容易に使いこなせるのがRPA
ステップ
１．集合トレーニング
RPAをツールとして使うための基本的な共通操作を集合トレーニングで覚えて頂きます。感の良い方であれば、これだけで充分使えるようになるかと思われます。
２．個別教育
その方の普段の業務をお聞きしながら、RPAでの業務効率化が可能な対象業務を洗い出して頂き、相談役としてコンサルタントが一緒にRPA化の業務フローを考えていきます。
RPAの操作自体は基本的に社員の方にやって頂いています。これにより、集合トレーニングでは身に付けられなかった実際操作と自信が身に付けられます。
３．オンサイトサポート
自社に戻って社内展開する場を設けたり、実際の運用の中での質問などが発生する場合もありますので、コンサルタントが週に１回、月に１回など周期を決めてお伺いします。
４．問合せ窓口サポート
コンサルタントがお伺いするまでもないような場合や、ある程度運用が落ち着いてきた場合はメール、もしくは電話での技術相談窓口を設置して対応しています。
５．リモート監視
RPAの動作状態や例外が発生するような場合など、その動作をリモートで監視し、メール等でお知らせしたり、修正・再実行させて頂く事が可能です。（事前に例外処理内容を協議させて頂く必要があります）
そこには課題も
これまで多くの企業様でのRPA導入プロジェクトを見てきましたが、RPAは基本的にユーザーが使い方を習得し、業務運用として使いこなしていくべきツールだとは言っても、やはり共通の課題があります。
多くの業務ユーザは時間をとれない
殆ど全ての場合にあてはまるのが、この問題です。RPAが然程難しいツールではなく基本的にプログラムを書く必要がないとは言っても、やはりある程度まとまった時間を確保してツールの使い方を習得する必要があります。
この時間を殆どの業務ユーザーが確保できないのが現実のようです。
プログラムを書ける必要がある
RPAの実装には必ずしもプログラムを書く必要はありませんが、プログラムを書ける必要があります。ここに業務ユーザーにとって高いハードルがあるようです。RPAに業務の一連の動作を教えるにはフロー図を書くことで指示をしますが、このフロー図を書いていくステップがプログラミングそのものなのです。
処理の流れを分岐させるための条件を論理式として入れたり、変数を定義して処理の途中で使う値を保持し、代入したり、ループ回数をカウントアップしていく等、プログラミングに慣れた人にとっては馴染みがあるフロー定義も、そうでない業務ユーザにとっては難しく感じてしまうようです。
やはり、RPAを使いこなしていくには「プログラムを書く必要はない」が、「プログラムを書ける」必要がありそうです。
環境・情報がない
多くの業務ユーザの方が自分でRPAの使い方を習得し、自信の業務を効率化していけるのではないか、とチャレンジしようとしても簡単に試せる環境やRPAツールに関する技術情報などが不足している状況です。
