我が社のRPA事情

　僕の勤める会社は、B2Bな製造業。客先からの注文をEDIで受け、製造し、EDIで納品指示を受けて出荷する。

　今のところ、受注業務について、RPAを導入済だ。経営層は、製造業務もRPAで省人化したいとか言ってたけど、なーんか勘違いしている気がするなぁ。

　正直なところ、RPA云々よりも、言いたいことが実はある。同じA社であっても、第1工場と第2工場とで、データフォーマットやEDIシステムが違うことは、全然珍しいことではない…これは非効率だろ！と、客先に向かっては言えないが、すごく言いたい。

　納品先の数（我が社の場合は50～100くらいかな）だけプログラムを用意しなければならないって、ムダだよなぁ。EDIFCTやANSIX12のように、統一してくれないかなぁ。競争原理の働かない競合ほど、無意味なものはない。そこは協調して欲しいものだ。

　中小企業共通EDI標準なんてのも登場したけど、「中小企業」なんて銘打っちゃうあたりが、残念だわぁ。

　話が逸れてしまった。

　正直、客先システムという不確定要素の塊に対してRPAを適用するというのは、あまり得策ではない。

　図のような異常事態も考えられる。

　何故、異常事態が起こりうるのにRPA化したかというと、誤作動を起こしていないか人が監視することにしたからだ。

　元々、省人化ではなく、過密な出荷スケジュールを遅延なく執行することが、RPA導入の目的だったのだ。3名ほどのスタッフが、EDIで当日や近日中の納品指示を受信していた。突発的な欠勤などで手が足らなくなると、出荷予定時刻やデータ配信時刻に間に合わなくなってしまう可能性があった。

　そこで、RPAで予定時刻通りにデータ処理を行うようにし、スタッフ3名は他の業務をしつつ、交代でRPAを監視するという体制にしたのだ。

　まぁ、そんなわけで、我が社の場合、RPAで激的効果を得られたとは、微塵も思っていない。

　が、RPAこそ最先端テクノロジーだと勘違いしている人が大勢いる。その人達の本心は「オレが働かなくても給料もらえるように、お前がRPAで自働化しろ」といったところか。まぁ、流石にそこまでではないかもしれないが、「RPAかシステム屋が、オレが何もしなくても、上手いことやってくれる」ぐらいには思っていそうだ。

　そんな人達には、図のようなフローを見せて、まずは己が働くことを促している。

　ただ、結局のところ、RPAで対応できるのは、個人の細々とした作業ぐらいなもんだ。大規模になればなるほど、「あれ？これって、市販のパッケージソフト導入すれば良かったんじゃない？」ということになりかねない。

　そもそも、RPAもプログラミングの一種なので、どうせプログラミングするなら、きちっと組織として全体最適を図り、それなりのシステムを構築すべきだろう。今は、ローコード開発だとか超高速開発ツールというものがあるので、一昔前よりもシステム構築がしやすくなっている。

　RPAなんてものが流行っているのは日本だけで、海外ではローコード開発が流行っているんじゃないかな？

IT・通信業ランキング