近頃RPAの導入がブームになっているが、現場に良かれと思って導入したのに思ったように効果が出なかったり現場から反発があって結局あまり使われていない、といった事例をよく聞く。そのような事例からのヒアリングも含めて、どのような対策を打てばRPAの導入を成功させられるのか考えてみた。
RPA失敗談あるある
- 業務や取引先ごとにばらばらにロボットがなし崩し的に稼働して運用コストが増えてしまった。
- いろいろな業務でRPAが試されていて、全体を把握できない。
- 現場のスキルやノウハウが不足していてなかなか進まない。使用率があがらない。
- 個別のロボットの稼働状況を見てみたら、意外と稼働していなく最適化されていなかった。
- ITスキルが高いエンジニアがロボットを作ったが、その人の業務をRPA化しているだけで他の人には理解ができない。ますますブラックボックス化してしまった。
- ロボットを作成した担当者が異動してしまい、だれもそのロボットのことがわからなくなった。
- 現場のメンバーのモチベーションがわかない。業務を取られるのではないかという反発が起こってしまった。
- ウォーターフォール型の開発プロジェクトを組んでしまい、スピード感がなくなるうえに成果物が現場のニーズと違ってしまう。
対策
- RPA化を行う前に、まず業務の見直しを行う。BPOを行う際の業務整理のプロセスを事前に入れておくとよい。業務整理をしたうえで再定義されたタスクについて、汎用性が高い業務は市販のパッケージソフトを導入することを考え、その次にはシステム化することを考えるべきである。残りのシステム化できない部分は現場で同ハンドルするかをRPA、手作業の外注 (アウトソース)、従業員による手作業のどれでやるべきかを検討する。
| 業務汎用性 | プレイヤーと提供/作業内容 |
|---|---|
| レベル3 |
パッケージベンダー パッケージソフトウェアとAPIの提供 |
| レベル2 |
SIer システム間連携 (APIの呼び出しプログラム)の構築 |
| レベル1 |
業務の現場メンバー (1) iPaaS, RPA (2) 手作業の外注 (3) 従業員による手作業 |
- 業務整理やRPA化にかかわる知識を社内で集める Center Of Excellence (COE) 部門を立ち上げる。メンバーには、コミュニケーション力とやる気が高い若手や女性をアサインしておくとよい。
- 全体の把握ができるように、最初からサーバ型RPAを使う。PoC自体は最初は現場主導でやらせたり、目安箱を設けてRPA化/見直ししてほしい業務を募ってみてもいいだろう。プロジェクトが進んできたら、IT部門やCOE部門によるガバナンスを効かせていくのが良い。
- 現場で高いスキルを持った人が継続的に活用できるとは考えないほうが良い。その人が異動してしまった場合のことを常に考えてみる。RPAツールは、高度なプログラミングスキルを持っていなくても扱えるものを選んで運用すべきである。
- ロボットの稼働状況は全体が見えるようにレポートを作成する。とはいっても、人間がロボットの稼働状況を調べて報告するようでは本末転倒なので、サーバ型RPAでレポーティングツールがついているものを活用して自動で見える化できるようにしておく。
- ロボットは作成する前に、まず誰にでもわかる形式で仕様書を作成する。
- RPAにかかわるメンバーや対象部門のメンバーには、RPA化/業務効率化することの意義を伝え、仕事を取り上げられるリスクがないことを伝える。うまく効率化できた場合には表彰したり、意識改革 (ジョブ・クラフティング)を行うなど、ソフト面でも部門で仕組みを作ってサポートをする。
- DevOps型の開発手法を取り入れ、現場とロボット作成者が綿密に連携を取りながらCI/CDを行っていく。
まとめ
RPAの目的はあくまでも業務の効率化であり、RPAの導入そのものをプロジェクトのゴールにしないほうが良い。RPAはあくまでも業務効率化の手段の一つであり、他にも手段はある。他の手段の方が優れている場合も多々あるので、RPAの導入を単体で考えるのではなく、他の手段と組み合わせた一緒のプロジェクトとして立ち上げることがお勧めである。また、事前の業務見直し/整理は必須である。既存業務をそのままRPA化することは考えないほうが良いだろう。
加えて、RPA導入は従業員の今後のタスクアサインとも密接に絡んでいるため、半分はコミュニケーションの課題でもある。対象部門内のコミュニケーションを円滑にする、コミュニケーション能力の高い若手や女性をコアなプロジェクトメンバーに入れることで、より円滑に進むだろう。