見出し画像

「UWSCとRPAの違いどんな人におすすめなのかをメリット・デメリットから解説」という記事を読みましたが、気になるのはココ!という話

「UWSCとRPAの違いどんな人におすすめなのかをメリット・デメリットから解説」という記事を読みました。2020年頃の記事です。

UWSCとRPA双方のメリット・デメリットについて丁寧に書かれていますね。

気になるのはココ!
「UWSCはプログラミング知識がある人におすすめ」、「RPAは非エンジニアにおすすめ」という部分ですね。ここ何で基準が違うのかなと。では私なりに「誰におすすめ」を記事にしてみたいと思います。

誰におすすめ
システムに対する自動化だけを実現したいのでれば、プログラミングを「しない」 方向を選ぶ選択肢もあり、業務プロセス全体の生産の向上を図りたいのであれば、プログラミングを「する」方向を選ぶしかないのではないかと思います。あるいは、プログラミングをできる人も必要になってしまうというということですね。

選択次第で決定的な違いが生まれる
ここでの選択で決定的に違うのはプログラミングを「する」方向を選ぶか「しない」方向を選ぶかですよね。
プログラミングを「する」方向を選んだ場合、知識と身につくのは「プログラミング知識」ですよね。UWSC の「プログラミング知識」がついてくるとVBA の「プログラミング知識」も同じようなものなので、生産の向上に向けて有効な知識となっていきますよね。一方のプログラミングを「しない」 方向を選んだ場合、「RPA 製品の使い方という知識」がついてくるわけですよね。これまで使う機会がなかったので使ったことないんですが、システムに対する自動化を実現できるようになったりすんでしょうけど、VBA の領域に対しても自動化できるわけではないと思いますし、「プログラミング知識」も身につかないので、システムに対する自動化以外の領域をどのように生産の向上をしていけるのか不思議に思っているんですよね。

単にシステムに対する自動化だけを目的にするならプログラミングを「しない」という選択肢もあり、業務プロセス全体を通して生産の向上を図ろうとするとプログラミングを「する」方向しか選択肢がないように思われるんですよね。あるいは、プログラミングをできる人を調達する必要があるということですね。

プログラミングを「する」方向を選んだとしても、継続力の違いや適性の違いなどの差があって「プログラミング知識」に差がでてきてしまうものだと思います。誰でも得意・不得意はあると思うので、自然なことだと思います。組織の中にそうした「プログラミング知識」を伸ばしやすい人が出てくれば、そうした人を中心にして UWSC も活用していけるようになっていくのではないでしょうか。

プログラミングできる人いる環境では、方針としてメンバーに「プログラミング知識」を学ばせるか、「RPA 製品の使い方という知識」を学ばせるかという選択肢があり、費用や効果、リスクやメリットを考慮して判断する。併用してくなど自由な選択肢があると思います。

誰におすすめなのかを考えていくと、目的や環境によって判断も変わりますねという結論になりました。

まずは、目的と組織のおかれた環境を整理してみるとよいかもしれませんね。

誰もが無料でWindows自動化を始め、生産性を向上し続けられるようにする



この記事が気に入ったらサポートをしてみませんか?