「RPA」=「ロボット作成」に固執しすぎではないか?
ディップ株式会社でRPAの推進責任者をしています。
また、RPA界では知らない人はいないであろう、RPAしくじり先生の弟子をしています。
社内でRPAを推進していて、他社でも活かせる考え方や導入事例をここでは書いていこうと考えています。
ロボット選びを優先すると失敗しやすい
RPAが盛り上げり、様々なイベントや事例記事が出回るようになりましたね。成功事例が多く、失敗事例はまだあまり出てきていないのですが、以下のような事を直接聞くことが増えました。
・ロボットを作ったがその後の社内展開がうまくいかない
・ロボットの修正や開発に工数がかかる
・ディレクターやロボット作成人員が育たたない
いずれもロボットに関わる問題であり、RPAの効果を最大化するためには必要な事だと思います。僕らも同様の問題は抱えており解決方法は思考錯誤しています。
RPAを導入する=ロボットを作るで間違いはないのですが、ロボットを扱う前にどんな業務がどのように行われているのか、どのくらい作業に困っているのか深掘りすることでこういった問題は小さくできると考えています。
そのため、ロボットを前提にするのではなく、その業務が本当に必要なのか?工数を削減することで、どのくらいユーザが幸せになるのかを考えてからロボットを選ぶようにしています。
・優先すべきは業務に携わるユーザ行動と心理
ロボット選択を優先することで手戻りの出来ない状態になってしまう事が多いので、特に気をつけているのは業務の把握です。
システム開発の要件整理にも近いですが、さらに上流から考えることで、仮にロボット導入に至った際、ロボットが容易に導入できるように準備しています。
例えば、以下のようなことを整理します。
・業務に当たっているユーザはどのようなペルソナなのか?
・ユーザは1日のうち、どのくらい業務に縛られているのか?
・業務における課題、何が一番面倒くさいか?
・他に解決する手段はないのか?
・無駄な工程は存在しないのか?
・業務が楽になると、どのくらい幸せになれるのか?
・そもそも業務自体が本当に必須なのか?
このようなことに整理して、ロボットを作らずに実現出来ないかを考えてRPAを進めています。
私が他プロジェクトでUXディレクターを担っている事もあり、RPAにおいても同様に考えることでRPAが失敗するリスクを減らせればと思います。
また、この項目を順番に考えていけば整理ができるフレームワークも準備しているので、次回ご紹介します。