RPA（ロボティック・プロセス・オートメーション）
### 少し調べてみたので、めもっておきます。 ###
最近RPA（ロボティック・プロセス・オートメーション）という技術が噂になっています。
これは人が手動で行っている業務を、自動でやらせちゃいましょうということのようですが、実際はまだまだハードルが高そうです。
個人的には、毎日同じ事を繰り返していたり、繰り返し作業が多い場合は良いかもしれないです。
自分は、EXCELのマクロを駆使して、業務改善を経験するのが好きなので理解しやすいですが、マクロを知らない人は「なんだろ」って感じですね。
ある程度の規模がないと、環境の整備や管理で余計なコストがかかってしまうかもしれないです。
実際に導入している企業は、月で1000時間単位での削減事案が出ていました。
サーバー導入タイプだと1000万以上かかるようですし、社内ネットワークの整備も必要ですので、システム部抜きではすすめられませんね。
クライアントタイプだと、1台あたり、60万強から
ただ各クライアントに入れるのは容量等の問題も有りラップトップを一人一台の会社は厳しいですかね。
今後はAI技術の活用でもっと活性化していきそうです。どうなっていくのか注目です。
以下、引用です。
■RPAの管理者が想定すべき「5つのリスク」
RPAによる業務の自動化を始めるにあたって管理者が想定しなければならないリスクとしては、大まかに①連携する既存システムとの不整合 ②誤処理の見過ごし ③不具合時の業務停止 ④不正使用による情報漏えい ⑤管理者交代による「ブラックボックス化」、の5つが挙げられます。【①連携する既存システムとの不整合】
既存の業務プロセスの代替として導入されるRPAは多くの場合、導入企業の基幹システムやWebサービスなどと連携することとなります。従って、これらの連携先に変更が生じた場合にRPAの対応が遅れると、処理が滞ったり、誤作動を引き起こしたりといったトラブルを招くことになります。【②誤処理の見過ごし】
基本的にRPAは定型業務の処理を担うため、例外的な処理は人手によって補完する必要があります。ところがRPAの設計で例外処理の対策に漏れがあった場合は、例外処理の担当人員を配置していたとしても、その担当者が気づかないところでRPAが誤った処理をし続ける可能性があります。また誤処理に気づけた場合でも、本来あるべき業務プロセスを把握していなければ、適切な処理をやり直すことができない事態も起こりえます。【③不具合時の業務停止】
ある業務処理を全面的に、あるいは大部分でRPAに置き換える場合、自然災害やシステム障害によってRPAが停止したときのバックアップ体制が課題となります。この点の不備は業務停止に直結しかねないため、特に大きなリスクといえるでしょう。【④不正使用による情報漏えい】
機密情報や個人情報を扱う業務にRPAを導入する場合は、万一RPAに対する不正なアクセスを許すと、情報漏えいや意図的な誤処理といった被害の発生につながります。【⑤管理者交代による「ブラックボックス化」】
人手による業務からRPAへの移行作業や、その後の運用を担当した人が異動・退職した場合、後任の担当者がRPAの業務フローを理解できない「ブラックボックス化」が生じ、将来的な業務プロセスの改善が困難となるおそれがあります。■リスクに備える管理体制
企業がRPAを導入するにあたっては、上で挙げた各リスクに備える体制を社内に構築する必要があります。ここでポイントとなるのは「導入部門と情報システム部門の連携」、そして「業務プロセスの文書化」です。前者に関連する事情としては、RPAの導入プロジェクトにおける導入先の部門と情報システム部門がいずれも当事者であることに加え、トップダウンで進めるケースを除くと両部門のいずれかがプロジェクトの主導役になることが挙げられます。こうした点からすると、両部門の連携は基本中の基本ともいえますが、実際にそれが緊密であるほど、不正アクセスへの対策はより強固なものとなり（上記④のリスクに対応）、かつRPAの連携先に関する情報を常時更新して整合性を保つことも容易になります（同①のリスクに対応）。
後者についてみると、業務プロセスの文書化は、RPAを導入する初期段階に対象業務を切り出す目的でも行われています。しかし、一見非常に単純な業務においてさえ、従来それを担っていた本人も自覚しないまま複雑多岐にわたる例外処理をしていることが珍しくありません。業務プロセスの全貌を常に把握し、細部にいたるまで正確な内容を記録しておくことは、思いがけない誤処理が生じた際の修正や人手による応急処置を迅速に行う上で、きわめて重要といえます（上記②③のリスクに対応）。さらに、そうした正確な現状把握をベースにすることで、より実態に即した形にRPAをアップデートすることも可能となります（上記⑤のリスクに対応）。
こうした管理体制の構築は多くの場合、RPAの導入に併せたタイミングで集中的に実施されています。しかしRPAは、変化が激しい業務環境にも対応しうるカスタマイズ性を本来的な強みとしており、導入した後も当初の構成にとどまらず、細かなチューニングや周辺業務への適用拡大を行うことを想定したツールです。従って、そうしたRPAの変化を反映するための管理体制のアップデートは、導入した後も常に欠かせないという認識が欠かせません。さらに運用開始から一定の期間が経過した後は、各所で最適化を図ったカスタマイズが相互に干渉や重複を起こしていないか確認し、全体最適に向けた統合調整を進めることも忘れてはなりません。
■自動化そのものより「業務改革」の姿勢が重要
冒頭でも触れたとおり、従来人手で行っていた定型作業へのRPAの導入は、爆発的ともいえる業務改善の可能性を秘めています。プログラミングの知識は不要でPC上での操作も容易なことから導入自体のハードルは低く、日本国内においても普及のスピードは加速の一途にあります。RPA自体の技術的な難易度がさほど高くないだけに、その導入と運用は、同時に行う「業務改革」の方法いかんで成否が決まると言ってよいでしょう。自動化に伴う変化で生じるリスクを慎重に見極め、関係部署が緊密に連携しながら、運用フェーズごとのルールを絶えず見直していく姿勢が重要です。
##################################################
追記（2018/6/11）
Robo-Pat記事
・1ライセンス、12万/月
・5240時間削減…3人ぐらいの削減ですかね。
個人的にはちょっと高いかな？
疑問？
・変更や対象作業のアプリが変更になったときの対応（誰が直すの？）
・検証、障害の概念（システム以外の人はあまり持っていないです）
・バックアップ、セキュリティ（PCインストールの懸念）