RPA内製化の本当の課題とは・・。

RPA内製化してます・・。と言っても多くの企業では、情報システム部の要員が、外部業者のメンバーを業務委託で雇って、開発・運用させているのが実態で、完全に自由に業務側のメンバーが行っているのは少ないです。

その理由は、業務側が扱えるほど運用が楽ではないからです。エクセルVBAのように一度作ったら、ほぼ100％動作するというのとは違い、急に動作しなくなったり、仕様変更したくなったりすることが多く、元々の手作業を対象にしていることが多いので、動かなくなったときのリカバリーが大変になり、そのときの開発者への白い目がキツイからです。

そんな経験をすると誰でも自分がリスクを冒しても開発したいと思えなくなります。また、ただ単純に作るだけでなく、引き継ぎを考えて、ドキュメントやマニュアル作らされるなど、面倒なことが増えるし、休日や夜間に動作させるとなると、対応も迫られたり、本当に疲弊するだけな感じになるでしょうし、明確な運用設計を指導してくれる人がいないですし、情シス側も運用だけ放り投げられても面倒なので、あまり自由に開発させたくないというのもあり、業務側と情シス側もWin-Winの関係にならないことが多いです。

（会社としては人が削減できたり、無駄な作業が減ったと大騒ぎしますが、へまったときのインパクトのことを誰もが考えていないので・・)

これらの課題を真に解決しないまま内製化を押し進めるのは危険以外の何ものでもありませんし、一番最大のミスは、システム開発会社にRPAの運用設計は考えられないという事実です。システム開発会社は、瑕疵担保責任など開発リスクを考えるのが得意なので、RPAのように動作しなくなることがあり得るものについては、判断できないのと、作業をしたことがないので、リカバリーを現場と調整できない人が多いのです。つまり動かなくなることを想定することが難しい人達なのです。そんな人達にはRPAの運用設計は難しいだけです。

そんなRPA内製化の運用設計で一番重要なのは、開発者と運用者の線引きをどこに置くのか。その上で、どういう運用設計をするのがベストなのか。現場の人へのIT責任の理解を進める度量と、運用時のリカバリー設計、それらを統制できる方法論が必要なのです。

これはシステム開発会社のノウハウにもなく、ITのコンサル会社でもわかっているけど、一番もめる人間関係も含めての調整になるので、あまり手を出したくない世界ですので、発展していかないのです。

RPA内製化を進めるのは、そうQC活動のような活動の中での、１手段としての活用を推進できるようにするのがベストな進め方だと考えます。

最低でもそういう心意気を持つ人たちでないと・・・。成功は遠い道のり。

誰でも始めることはできるけど・・

一度始めると被害も大きくなるし、失敗での痛手は会社間のコミュニケーションにも多大な影響を与えかねませんので、良いアドバイスをくれる人に力をもらうのがベストです。