前回の「宅配会社のRPA導入話」の続きです。
そもそもRPAを導入しようと思った理由の１つは、「働き方改革」の一環なんだそうです。
今更ながら、RPAの強みは、自動化です。
それは人がPCの前にいてもいなくても、どちらでも対応可能です。
この先、どの業界も人手不足になるのは見えています。
出来る限り人件費を削り、人にはもっと売上に直接関係するところを担ってもらいたい！というのは、経営者全員が希望するところでしょう。
さて、前回の「RPA導入に気を使ったこと」の続きを。
RPA導入で気を使ったこと
３．基幹業務の操作は自動化しない。
基幹業務 ⇒ すべての企業活動の中心となる販売管理、生産管理、会計、人事、給与などの業務のこと（コトバンクより）
一瞬、「えっ！？」と思いましたが、ERPで対応しており、RPAではないということなんですね。
ERP ⇒ Enterprise Resource Planningの略。総務、会計、人事、生産、在庫、購買、物流、販売などの基幹情報や経営資源を、統合的かつリアルタイムに処理する基幹業務システムを構築し、効率的な経営を図る経営手法のこと。代表的なERPパッケージには、SAPの「SAP R/3」、Oracleの「オラクル アプリケーションズ」などがある。
この会社でのRPAの位置づけは、あくまでも補助的な利用方法となっており、全社的に対応を要求される部分については、システムの見直しにて対応しているようです。
対象となる業務プロセスを平準化してみて、自動化できるか？などを検討し、システム化する方が効率的なのか、RPA化するほうが効果的なのか、十分吟味して決めているとのことでした。
さすが資金力のある大手企業の考え方ですね。
４．RPAに障害が起こった時の業務継続方法を事前に考慮する。
これって、本当に大事だと思います。
機械って、本当に「絶対」が無い世界なのです。
例えば、通信のインフラ関係の会社においては、冗長化（二重化・三重化）は当たり前であり、様々なトラブルに耐えられるように設計されています。
そのため、計算上はシステムダウンしないように作られています。
なのに、実際にはちょこちょこ止まることがあるのです（苦笑）
世界中から天才と呼ばれる人達を集めて作られたシステム、たとえばGoogleやAmazonが運用しているシステムであってもです。
設計に致命的なミスがある場合もあれば、オペレーターがマニュアルに書かれていない手法で対応したことが原因であったり、停電などの外的要因もありえるでしょう。
そういう訳で、テストでちゃんと動いたからもう大丈夫！とは言えません。
むしろ、数年に１度あるかないかというトラブルを想定して、備えておくべきなのです。
RPAの場合は、回線などのインフラと違って、冗長化というのはあまり聞きませんから、余計にトラブルの可能性は高いと言えるでしょう。
なので、その時の対応方法が特定の人の頭の中にしかないというのは、極めて危険です。
これから終身雇用も本格的に崩壊し、それに伴って労働力の流動化も一層進むのは明らかでしょう。
RPAで自動化したものは、書類にするなり、動画にするなり、緊急時には手動で誰でも対応できるようにマニュアル化しておきましょう。
また、RPA導入後には１０分程度で終わっていた作業が、その時は手作業でやることになり、結果半日以上かかるかもしれません。
そういった作業時間のことも考慮しておきましょう。
以上、大手の宅配会社のケースでした。
人材もお金もある大企業の話なので、そのままマネすることはできないかもしれませんが、中小企業にも通じる点は多々あります。
導入の際には、運用まで考えた事前準備が大事ということですね。