RPAを「業務システムやプロセス」の改善や見直しのきっかけにしては？

このnoteの目的

RPAを「業務システムやプロセス」の改善や見直しのきっかけにしては？
そのために、RPAを「情報の橋渡し役」と捉えてみてはどうか、
という提案です。
以下では、
「情報」を「川を渡る乗客」、人力の反復業務を「渡し船」、RPAを「自動運転の渡し船」、根本対策を「橋」に例えていますが、RPAを揶揄するという意図ではありません。

RPAの捉え方

RPAが導入される「人」の業務として、例えばこのようなものがあると思います。

①　「紙」の記述内容を、Excelのワークシートへ入力
②　あるシステムの画面出力を「見て」、別のシステムの画面へ入力

これらは「情報を橋渡しをする業務」と捉えられると思います。つまり、

①　紙の記述内容の「情報」をOCRで読み込み、Excelのワークシートの該当するセルに「情報」として入力していく
②　あるシステムの画面上に表示されている「情報」を目視で読み取って、別のシステムの画面上の入力欄に「情報」として入力していく

と捉えることができます。
そして、このような業務をRPAは自動化してくれます。

「情報」を「運搬される対象」と捉えると

いろいろな見方があると思いますが、私は

①「情報」を「水」に例えると、これを人力でやるのが「バケツリレー」
②「情報」を「川を渡る人」に例えると、これを人力でやるのが「渡し船」

に例えることができると思います。

RPAは、この「人力」の部分をそのままロボット化するので、

①「バケツリレー」→「ロボットによるバケツリレー」
②「渡し船」→「自動運転の渡し船」

と考えられると思います。

もちろん「根本的な解決策」は

①「水道管」を引く
②「橋」を架ける

だと思います。

そう簡単に「水道管」や「橋」が建設できるのかどうか

先ほど「水道管」「橋」と例えましたが、実際には、

建設のための予算確保、工期、技術的な可能性、技術者人員確保、保守費用、費用対効果、…

と考えなければならないことが多々あります。
これはITについても変わりません。

※ソフトウェアは劣化はしませんが、入力、出力、運搬する情報などの「仕様変更」などに追従する必要があります。

そこまで考慮した上での「投資」という判断が必要になってきます。

RPAの活用方法

もちろん根本解決が容易ならばそれに越したことはありませんが、もしそれが困難であれば、とりあえずの解決策として

最初はRPAで「情報」の流れを繋いでみる

が「あり」だと思います（RPAは比較的構築が容易ですので ※注釈）。
そして、

RPAの導入の効果が高ければ、「根本解決」策の効果も高い

と見なして「根本解決」策に対する投資を考えればよいと思います。
（RPAの効果が高い例としては「定型化していて例外がない」「運ぶ情報の量が多い」などが挙げられます）

ITで考えられる「根本解決」としては、

紙のデジタル化、入力側と出力側のインタフェース作成と結合

などの「手段」のデジタル化、システム最適化の他に、

業務そのものを見直して、「そこに情報を流す必要を無くする」

もあると思います。

まとめ

RPAを「情報の橋渡し役」と見ることから、
RPAを「作業効率化」だけでなく「業務・システムの見直し」のきっかけにすることができると思います。
RPAの導入を、そのような観点で捉えてみてはいかがでしょうか。

※注釈

RPAの開発が「プログラミング知識不要」か

RPAやローコード開発では、作業をコンピュータ（ロボット）に指示する際に、言語（プログラミング言語）ではなく「図示」を使っています（指示を図形や矢印で示す）。
その昔の「流れ図」「フローチャート」みたいな形です。

指示が「言語」ではないことから「文法」を覚える必要はなくなりました。
また、ある程度まとまった作業は単純化されました（「Excelを開く」とか）。
このことより、「文法ミス」のようなことも減りましたし、作業の流れの見通しもよくなりました。

しかしながら、個々の作業の「流れ」を指示するときの「指示の話し方」は相変わらずです（分岐、繰り返し、変数、などなど）。

RPAやローコードの宣伝に「プログラミングの知識は不要」と書かれることが多いですが、
確かに、プログラミング言語の「文法の知識」は確かに不要ですが、そもそも（コンピュータへの）「話し方」を知っていないと、何も指示できなくなります。

プログラミングの教育ツールとして「Scratch」という「図示型」のプログラミングツールがあります。
こういうプログラミングツールの事前学習は、RPAやローコード開発に役立つのではないか、と考えています。