RPAには業務責任が付きもの

以下のようなポストをして、結構な反響を得たので、これについてまとめておきます。

RPA導入が進まない原因は、RPAを開発した人が運用も行い、業務責任が実質的に移動するから、です。 この問題に触れない限りは、自パソコンの自動化以上のRPA活用は難しい。実質、誰かが我慢しているだけ。 僕は業務責任が移動するから、そういう部署を作ればいいと主張しています。

という内容です。

これは主に「完全自動化」した場合を想定して発信していますが
RPAを開発して運用している人のところには必然的に業務責任が移動してきがちです。

この「移動してきがち」というところがポイントで、
完全に業務責任が移動してきたわけではないのです。

営業部が作っていた日報を情報システム部の1人がRPAを使って自動化したケースを想定してみましょう。

お気づきの通り、ほとんどの業務を情シス担当者がやることになってしまっています。
「正しいデータを定時に送付する」という業務責任は営業部にあるはずですが、実際はそうなっていません。
そもそも、責任の所在については話し合ったこともなかったはずです。

ただ、「毎日の作業が大変だから、情報システム部に自動化してもらっただけ」というのが、営業部の立場です。

営業日報の小さな数字が間違っていたことで、「責任問題！」というところまで発展することはないでしょう。だからこそ、どこの責任だったのかあいまいなまま日常が進んでいきます。

このように、「RPAには業務責任の移動が含まれるかもしれない」ということを誰も認識していないし、議論しない点は問題ですね。

責任の所在がどこにあるのかをはっきりさせないままRPAの運用を続けると、RPAを作った人の負担が大きくなって疲れてしまいます。
新しい自動化を行うのが嫌になってしまうかもしれません。
こうしてRPAの進捗が悪くなっていってしまうのです。

というわけで、僕はいっそのこと「業務責任込みでRPA開発を引き受ける」という覚悟を持って開発する、そしてそのための部署を作るくらいでちょうどいい、と考えています。

受託開発会社が案件を受注するレベルで要件定義を行い、業務を勉強し、業務責任を受け取るつもりで開発する、ということです。

要件定義をする人、RPA開発を行う人、運用する人を分けて、1人に負担がかかりすぎないようにすることも、疲弊してしまうことを防ぐには大事です。そのための「部署」です。本当の部署でなくても、「グループ」「チーム」でもいいでしょう。

そういう意味で「DAFチームとその役割【業務の完全自動化を支えるDAF理論】」という記事も書いているので、併せてお読みください。

もちろん会社の状況によっては、この考えがなじまないこともあるでしょう。

その時は、「業務責任を取らないといけないような案件は請けない」とか、「業務責任を取れる範囲で自動化する」という対策も考えられます。

営業日報の例で言うなら、「営業日報を自動作成し、営業担当者に送る」までを自動化とし、営業担当者には自分で数字を確認してもらい、自分の責任でメールしてもらう、とするわけです。
そうすれば、数字の質問やクレームは営業担当者に行くことになります。

とはいえ、「毎日数字を検算することなど不可能」だし、「自動でメールできる帳票を営業担当者が手動で送るのはムダ」だし、、机上の空論ではありますが…。

というわけで、RPAは技術的な問題だけじゃないんだぞ、ということですね。