![見出し画像](https://assets.st-note.com/production/uploads/images/83183592/rectangle_large_type_2_6105465e3e3d4acad89139c31c71c811.jpg?width=1200)
RPAの運用について
この記事はUiPathブログ発信チャレンジ2022サマーの23日目の記事です。
昨日はKosuke Uenoさんの記事、
明日は水科美菜(自称VTuberな猫又)さんの記事です。
はじめに
私は立場的に開発より全体推進や運用管理など全体のとりまとめの方が多いので、実際に行っているRPAの運用・管理について記載したいと思います。
RPAの日々の運用についてやっていること
※注意
以下の運用は他のシステム運用の経験から構築した内容で、これがRPAでやる上でベストなのか正しいのかもわかりません。
うちの会社ではこうしてますよ。って内容ですのですので、その辺を考慮してご覧ください。
最近なんかで見た例えのお話で分かりやすい説明だと思ったのが、RPAは自転車。
自転車は頑張ればほとんどの人が乗れるようになるが、みんながルール守らないと無法地帯になる。と。
確かに日本の自転車ルール(道交法ですが)はまさに無法地帯。
私はきっちり守るので、信号でちゃんと止まるたびに無灯火・片手にスマホ・逆走チャリに追い抜いていかれてイライラすることが多いです。
話がそれました(汗)
なので、RPAもたくさんの人が(頑張れば。かなり頑張って学習すれば)作れるようになると思いますが、継続して使っていく上で、ガバナンスを効かせてきっちり管理していかないと無法地帯となり事故が起こります。
作るのにもRPAは後で修正や改修が良く入るので最低限のルール(規約)が必要だと思うし、使っていくにも管理しないと、誰も必要としていない業務がいつまでも動いてたり・・・
なので、たくさんRPA化できても、何をしているかわからないものが動いているような野良ロボット(野良業務が正しい)が発生しない様にきっちり管理をお勧めします。
開発規約
RPAを始めたころはプログラマーも参加いただいてたので、プログラム開発を参考に、最低限の開発規約等を作りました。
ただコードを書くプログラムと違い、処理が見ればわかるRPAの利点もあるので、まったく同じにはせず最低限に。
コメントはどういう感じに書くとか、こういう作りにしようとか、変数はこういうルールで名前つけようとか。
どこまでやったらいいかはまだ分からず試行錯誤中です。
(現状のは他社できっちり開発してた社員が、以下のUiPathメソドロジーを参考に作ってもらったもの)
UiPathさんにはたくさんの参考になるUiPathメソドロジーなどの資料があるので、こちらを見て必要なものを使うのがおすすめ。
(昔は何もなかった・・・)
日々の運用について
弊社現状、(記事記載時点)8台のUnAttended Robot(以下UR)をメインに運用しています。
現状人が少ないので、開発しながら順番にリカバリー当番となり、RPAがエラーが起きた場合のリカバリーを実施しています。
一定時間毎にURがOrchestratorのエラージョブの一覧を取得、Teamsにアップして、リカバリーが必要なものはリカバリーを行います。
リカバリー当番はメインとサブ2名で、就業時にはメインとサブの人で漏れがないかチェックし完了としてます。
基本リカバリーは、就業時間中のい対応。土日祝はリカバリーせず、翌営業日での対応としてます。
このリカバリー対応は作りの問題かもしれないけど、毎日結構あります・・・
ジョブ失敗率の管理
リカバリーが必要なジョブが結構あると書きましたが、毎月ジョブが失敗したものについてはエラーログを全て取得。
以下3つにわけて管理してます。
①システムエラー(ワークフローの作り等の問題でのエラー)
②ビジネスエラー(管理ファイルを置いてない等、運用上のミスによるエラー)
③アプリケーションエラー(利用しているシステムが止まってたり、
高負荷で重かったとかで、タイミングを見て再実行すれば問題ないもの)
この中で①のみきっちり原因をみんなで確認。改善の必要があれば修正してワークフローの作り方で発生するようなエラーの件数を減らす努力をしています。
個人的に②のビジネスエラーは運用ミスなので、RPAから利用者にメールやチャットを飛ばして、こちら側(RPA)としては正常終了にしたいのですが、皆責任感が強く、こちらで確認、連絡している状況です。
稼働率集計
これは社内への毎月のRPA稼働実績報告用です。
弊社のOrchestratorはオンプレ版なので、そのDBから抽出した稼働実績から、
ロボット名:処理件数(成功件数・失敗件数):処理時間
を見ています。
結構頑張って動いているな。というロボット(UR)でも、現状2百数十時間/月程度なので、
24時間✖️30日=720時間
に近づけるよう目指して、どうジョブをスケジュールすればいいのか、これも試行錯誤中です。
そもそもこの集計、UiPath Insightsを使えば簡単に数字が見られるようになるはずですが、製品の価格を聞いて・・・まだ8台なので毎月手で集計頑張ります!
となり、毎月頑張って集計してますw
URスケジュール表管理
社内の開発チームに作って貰いました。
(見た目はG●●gleカレンダーなのは内緒)
これもオンプレ版OrchestratorのDBから抽出したデータを自動で表示してます。
これでどこの時間に空きがあるかを見ながら、新しい業務を追加して行っています。
ただURが8台になると大分見難くなり、新しい管理方法をRPAの有識者に相談。
時間枠を設けて、そのジョブがその時間枠で終わっているかだけ管理すれば良いのではと。
その時間枠で終わっていないジョブがあるかないかだけ見て管理するのが良いですよと。
確かに。
しかし、それをどうやって管理・運用するかの方法が思いつかず、できる方法を検討中です(汗)
インシデント管理
障害や問題が発生した場合はインシデントとして管理してます。
これも毎週新たなインシデントが発生してないか確認し、発生した場合は問題が解決するまで継続して対応しています。
UiPathのカスタマーサポートの皆さんには本当お世話になっており、この場を借りてお礼をお伝えしたいと思います。
いつもありがとうございますm(_ _)m
課題管理
みなさんやっていると思うので省略
業務管理(RPA業務一覧)
RPA化した業務はデータベースに登録して管理しており、また社内にも公開して誰でも見れるようにしてます。
ここに削減時間等も入れてるので、全体でどのくらい削減時間があったのかグラフでわかるようにもなってます。
もちろん個別にも見られるので、どの部署がどんな業務を自動化してどのくらい削減時間があるのかわかります。
なのでよく事例でもありますが、部署毎に毎月、自動化した件数と削減時間を集計して、ランキングとして公開。
各部署間で競ってどんどんRPA化してくれたらなと。
(正直どれくらい効果があるか不明・・・)
またこの一覧を元に業務の棚卸しを半期に1度実施。
もう利用していない業務がないか、担当者や担当部署が変更になってないか等確認して、野良ロボ(野良業務だよね?)が発生しないように管理してます。
最後に
せっかく作ったものは正しく運用して使ってもらって、ちゃんとRPAが継続して利用されている状況になってないともったいないですので、きちんと運用・管理しましょう。
仕事をする中で大きく3パターンの人がいると思っており、
①0から1の今までに無いものを作るのが得意な人
②1を100にする業務の拡大が得意な人
③100を100で継続して運用するのが得意な人
と、得意な業務が人それぞれ違うと思ってます。
(今回の話は③がメインですね)
なので自分がどれが得意を考えると、どのエキスパートを目指すべきか方向性が見えてきるのではと思ってます。
RPAを利用するみなさんの参考になれば・・・
(文字ばかりで見難くてすみません。)
![](https://assets.st-note.com/production/uploads/images/83207632/picture_pc_520242817ca7beb2311e5cbf8b724209.jpg?width=1200)
この記事が気に入ったらサポートをしてみませんか?