今でこそ説明の余地もないほど認知されているRPA(Robotic Process Automation)ですが、世にセミナや成功事例講演が出回り始めた時期に、一度“試しにやってみた”ことがあります。詳しい時期感や目的はおいておくとして、とにかく「導入を前提にして、まずは触ってみて、知ってみよう」という事でトライアルをしてみたのです(失敗することも織り込み済みの稀有な例かもしれません)。その時の経験はいわゆる“導入の失敗事例”そのものでした。
どんな課題に直面したのかを発信することで、これから検討を考えている方のご参考としていただければと思います。
いきなり自らのトライアルPJを否定する結果となりました(笑)。この取り組みでは「RPAを導入前提にトライアルすることでRPAのなんたるかを知る」ことを目的としていたのですが、「RPAを導入できそうな業務はどこだ～」「費用対効果は出なさそうだがどうやって“捻出”すればいいのか～」と、RPAの導入そのものを目的にしてしまったがために、本来改善に不要な工数を割くこととなりました。当たり前のことですが、普通は“明確な問題があるから改善策を検討する”はずなのに、改善策の検討を先にしてしまっていることが原因といえます。しかし、案外笑い話でもない話で、「RPAに取り組むことが決まって～」というスタートで検討を始めるケースも多いのではないでしょうか。
現状の把握や分析を行うこともなく、「まずは事例でよく聞くあの業務から始めよう」「おそらく手作業が多いはずだ！社内の業務だからそんなことわかっている！」という軽い(？)ノリで、ある経理系業務をサンプルの対象として選定しました。想定通り手作業が多く取り組みとして成功しそうな雰囲気はあったのですが、業務についてヒアリングをかけてみると、実はOCR(手書き文字をテキストデータ化する機能)が必須であったり、手作業で面倒な業務ではあるものの作業回数自体は実はそんなに多くなくツール化するほどでもない作業量であったりと、結果として不要な検討とヒアリングの工数をかけてしまいました。そのITを導入する根拠は何か、という部分が欠落していたことが原因です。
失敗その２とほぼ同じことなのですが、現状の把握や分析を行っていない状態で取り組みを始めるということは、乱暴に言ってしまえば「結果が出るかどうかはわからん、でもとりあえず検証してみたいからヒアリングさせてくれ」という状況で他部署の方の時間をもらう事になります。幸い当時のPJでは協力部署の方が私たちの取り組みを理解しており、険悪な雰囲気にはならなかったのですが、これが本当のPJだったらと考えると「まず快く協力はしてもらえないだろうな」と感じました。他部署の方からすると、要は「協力するメリット」がないのです。さらに言ってしまえば、「自分の業務を否定されている感覚」「仕事を奪われる想像」のほうが印象に残ると思います。「きっと仕事が楽になるよ」だけではその道のプロの方に訴求することはできません、定量的な根拠が必要になるということです。
多少脚色した部分はありますが、この記事で書いていることは現実に起き得る事です。また、書き尽くせない小さな後悔や反省点もまだまだあります。総じて言えることは、RPAに限らずITの導入を考える際は正しい手順で考えること、準備をした上で取り組むこと、これに尽きると思います。「何を当たり前のことを」と思う方が大半だと思いますが、この記事を読むことで、改めて「こんな失敗はしないようにしよう」と思っていただければと思います。
さて、このままですと「やってみて失敗しただけ」のかわいそうなPJになってしまいますので、次回は失敗から学んだ対策について、しっかりとお伝えしたいと思います。
次回の記事はこちら：
RPAを“やってみた”-事前に知っておきたい２つのポイント-
Rankingランキング
New arrival新着
Keywordキーワード
