どうもmizukiです。トップダウンでRPAを入れた結果、逆に生産性が落ちている最中です。
RPAの導入の成功率を上げられる、とても分かりやすい記事を見つけました。記事の作者のような方が居てくれれば今の状況も変わっていたと思います。導入検討中の方は間違いなく参考になると思います。
RPAの導入・展開がうまくいっている企業に共通するポイント
明らかに導入失敗している側が記事を読んで思った事
この記事の失敗するポイントをすべて網羅しています。「上から押し付け（トップダウン）によるノルマを課したスタート」から始まり、「RPAを業務とは認めずに、表彰はおろか評価もしない」と誰がそんな状況でRPAをやりたいと思うんだ、と言う環境になっています。
進捗報告を見ても明らかに出来ない理由を羅列している部署が多いです。
RPAを覚えろと言われてもエンジニアであれば余裕で使える
僕も社内SEなので、「当然できるよね」とか言われてやらされました。適当に自動化できそうな作業を（一部は実際にはやる必要はないけど）自動化しています。
どの種類のRPAであれ、プログラムを書ける人なら余裕で動かせます。『UWSC』なんかで自動化を経験した人であれば間違いなく使いこなせます。
作っていく最中で、エンジニアであれば保守の観点での使い勝手の悪さに気づくと思います。コーディングルール制定してRPA導入している会社があれば凄い！
RPAが上手く行けば社内でも学習の意欲が高まる
僕の現在所属している会社は、ほぼ全員が新しい技術を学ぶ意思が無いので、そういった意識がRPAが上手く導入されていれば変わってきたと思います。
新しい事を学び出来る事を増やせば、会社から評価される！と言う好循環になっていたかもしれません。
まとめ
上手くRPAを導入するのであれば。
「上から押し付けて始めるのでは無く、手を挙げた部署からスタートする。」
「成果を出した人は評価をする」
「RPAを業務として認め、時間を確保する」
この3点は絶対に必要だと感じています。もしやり直せるならスタートからやり直したいレベルに酷い状況なので、今後導入する方々が同じ事にならないよう祈っております。
今後RPAを作った人が退職をした後に「エンジニアだから解析お願いね」とか言われたら即座に退職届を出します。私の戦場はここじゃない。
参考
失敗する理由の詳細です。よければどうぞ。やっぱり保守性が微妙なのでVBAと同じ過ちを繰り返しそう。人は過ちを繰り返す。
コメント