いつも拝見させて頂いております。
Uipathの構築ですが、実際に運用する環境で作ることが前提でしょうか?
xamlファイルを提供することで、仕組みを提供したこと(動作を保障)するということにはならないという認識ですが、いかがでしょうか?
ロボットが動くというのは、あくまでも同じ環境下でという認識でよろしいでしょうか。
ロボット作りは人任せにせず、管理できる人が作る、ということをUiPathは推奨しているんでしょうか。
よろしくお願いいたします。
いつも拝見させて頂いております。
Uipathの構築ですが、実際に運用する環境で作ることが前提でしょうか?
xamlファイルを提供することで、仕組みを提供したこと(動作を保障)するということにはならないという認識ですが、いかがでしょうか?
ロボットが動くというのは、あくまでも同じ環境下でという認識でよろしいでしょうか。
ロボット作りは人任せにせず、管理できる人が作る、ということをUiPathは推奨しているんでしょうか。
よろしくお願いいたします。
>ロボットが動くというのは、あくまでも同じ環境下でという認識でよろしいでしょうか。
YESです。
>ロボット作りは人任せにせず、管理できる人が作る、ということをUiPathは推奨しているんでしょうか。
UiPathの推奨運用方法は【無い】認識です。
導入した企業毎に「ベストな運用方法」が異なりますので、”誰がシナリオを作る”とか
”誰がメンテする”とか”誰が責任を持つ”とか、多種多様だと思います。
※難しいところですよね。
ありがとうございます。
やはり、総合的な技術と知識で対応するEUCという感覚であってるみたいですね。
いろいろ情報をあさっていると、「業務をわかっていればOK」的な形でRPAが紹介されているので気になりました。
業務管理のタスクに「ロボット管理」って項目が増え、その中にドキュメントや動作環境というのが必要になりそうですね。
担当者が変わるたびに0ベースから構築ってなるのもどうかなと気になったので。
すみません。認識の確認のような質問になりました。
「どういった組織体系にすべきか」は企業によっても異なるので、一般論になりますが。
UiPathの推奨するプラクティスとしては、横断的なRPA研究・開発部門を社内に作ることが掲げられています。
現場担当者に開発をしてもらうよりは、現場担当者と協力してRPA開発者が業務を自動化・改善していく、という感じではないかと思います。
以下、余談というか、個人的な経験になりますが。
「業務を理解してる人がRPAを作れば良い」というのは一見低コストに見えますが、現実的にはかなり難しいです。というのも、どのようなRPAツールであれ、相応に「覚えないといけない」要素はあるからです。
そして余程、人材とコストに余裕がある企業でなければ、現場担当者は日常業務のタスクを抱えているので、そこにRPAの習得・導入・実装が追加されても、現実的には追いつかないことが多々あります。
「今頑張れば将来楽になる」というのは1つの殺し文句ですが、現実的にはそこまでの余裕がない場所にこそ、業務効率化ができるRPAの需要が大きいという矛盾になってしまうわけです。
つまるところ、基本的に現場担当者に任せっきりにするタイプのRPA導入は、
・属人化(辛うじて覚えた担当者がいないと運用できなくなる)
・硬直化(メンテナンスをする暇がなくなり、業務をRPAに無理にあわせるという本末転倒が生じる)
・そもそも導入できずに失敗する(言うまでもないですね)
といったリスクを抱え込む可能性が高くなるのです。
「業務をわかっていればOK」というのは一見魅力的ですが、現実にはそういったリスクがあることを念頭において、RPAを導入するかどうか、導入するならどのようにやるかを検討していくのが良いのではないか、と思います。
ありがとうございます。
私の考えていたことと近くて一安心です。
RPAのメリットを最大限享受するには、
・社内にロボット製造、管理部門を用意すること
・ロボット専用の環境(業務用PCなど)を用意すること
・ロボットを導入するにあたって、業務分析をしっかり行うこと
・ロボットを改修する体制を整えておくこと
が大切ですね。
こういった体制を整える予算と、人員管理などを踏まえて、どれぐらい全体的に効率化が見込めるかを算出しないと「思ったよりも効果がなかった・管理や開発を考えるとコストが余計にかかった」といった状況に陥ってしまいますね。
全体最適を考慮しながらのEUC提供という、非常に難しいミッションになりますね。
しかも、使うツールとしては、総合技術的な知識も求められるわけで・・・
魔法の杖、というわけにはいかないですね。