多くの企業でIT部門が主導して、ITベンダーやコンサルティング会社に丸投げ発注する従来型のシステム開発アプローチで進められているのを見掛けますが、その進め方は恐らく失敗します。
強引に進めればRPAの導入自体は出来るかも知れませんが、相当な期間と費用を費やし大きなROI（投資対効果）は期待できないでしょうし、その後の運用も含めて、その様な高額な外部ベンダーに費用を払い続けられる会社は多くないと考えられます。
こちらでは、RPAの導入をどの様に進めれば良いのかに関してご紹介しています。
RPAをシステム導入として扱うのが間違いな理由
先ずはRPAの導入を従来のサーバー型大規模システム開発と同様に進めるのには無理がある理由をご説明していきます。
スコープを決め難い
RPAの導入において、従来型のシステム開発として進め難い最大の問題は次の点です。
RPAの場合、詳細な業務手順、周辺システムの仕様などを調べてみないと何処まで自動化出来るか見え難い
よって従来型のシステム開発アプローチである、「ウォーターフォール」型の開発モデルに向かないのです。ウォーターフォール開発モデルでは、外部のITベンダーと契約する際に基本的に決定しなければならない点があります。たとえば、外部ベンダーとの契約を準委任契約する場合、
- スコープ（契約に含まれる範囲）
- スケジュール
- スタッフィング（体制）
は最低限決定出来ないと契約できません。これは、主にベンダー側の論理なのですが、この点が確定出来ないとリスクが多きくなり過ぎるためです。この中でRPA導入の場合、１．スコープが特に決めにくいのです。
従って、ウォーターフォール開発モデルで言う、最初のシステム開発・導入範囲の要件を決める部分でつまずいてしまいます。
RPA導入はウォーターフォール開発に向かない
やはり、ウォーターフォール型開発の様に当初からシステム開発する全体が見えていて、大規模な体制を組んで計画的に進めるアプローチではなく、作成したRPAシナリオの動作や自動化効果を確認しながら、徐々に周辺業務を取込み自動化範囲を広げていくアプローチのほうが向いているのだと思います。
RPAロボットが自社の業務に慣れるように教え込み、育てていく（アジャイル）アプローチです。
業務部門が主導すべき
RPA導入の場合、外部のITベンダー等に丸投げ発注は出来ません。それが出来ていたのは次の条件が揃っていたためです。
- 基幹システムの会計処理、勤怠管理、経費処理、在庫、購買管理などの様に一般的にどこの会社でもそれ程変わらない業務
- 開発当初から、必要な項目や処理の流れ、ロジックなどの形をカッチリ決める事が可能な業務
- 外部取引などのフォームやEDIデータ形式などが決まっていて、作成すれば良いだけ
しかし、どう考えてもRPAで自動化しようとする業務はこれらの条件に当てはまりそうになく、その間に抜け落ちた業務なのです。RPAの導入は
- 業務ユーザーの日常業務の繰り返しPC雑務を自動化するもの
- 大量に同じ繰り返し処理があるわけではないが、そのバリエーションが多くトータルすると結構な業務時間を費やしている
ようなPC業務であって、これらの業務を実際に行っている本人にしか内容が判りませんので、業務ユーザー自身が自分の仕事を少しでも楽に、効率良く行えるように、新しく採用されたロボットの新人に手取足取り指導、引継ぎするのです。
そして、そのロボット社員が慣れてきたら、少しづつ任せる仕事の範囲を広げ、処理の分岐条件を教えて育てていく姿勢が必要になります。
その様な対応を繰り返していくうちに、RPAロボットのほうも次第に打ち解け、組織の一員として相当な力を発揮するようになるに違いありません。
なにしろ、ロボットですから、24時間、365日文句も言わず、残業代も発生せずにあなたに代って働き続けるのです。
検証を繰り返す
パイロット導入で効果を確認
RPAにもやはり向く業務、向かない業務があり、パイロット導入でその特性を理解し、効果を実感する事が重要です。これが頭で理解出来て初めて、実感としてこの辺りの業務であればRPAに任せても大丈夫そうだと判断できるようになります。
その意味でもパイロット導入は非常に重要で、業務ユーザーに任せっきりにせずにプロジェクトをリードする立場の方々が共通認識・感覚として持つようになるのが理想です。
RPAでは自動化出来ないシステムやどの程度の業務量があれば自動化の効果を期待できるのか等、やはり認識しておく必要があります。
ノウハウを社内に蓄積する
そして、RPAと言うツールを使って自社の業務効率を改善するノウハウを蓄積していきます。決して外部ベンダーに丸投げしてはいけません。RPA導入は一旦シナリオを作成して終わりではなく、現場改善活動として継続的に行って少しづつ効率化していく心構えが必要です。
ノウハウを形式知化する
そうしていく内に、次第にRPAで業務を自動化する為のノウハウが社内に蓄積されていきます。ここで、重要になるのがIT部門の役割で、このRPAを使った自動化ノウハウやシナリオ部品のカタログ化、ドキュメント整備などをIT部門が主導します。
ある程度RPAによる業務自動化のイメージやノウハウが社内で蓄積されてきたこの段階で計画的に上記のようなドキュメント整備やRPAシナリオの標準部品化を考えておく事で、後の全社展開のスピードやかかる労力、RPAシナリオ作成の生産性などに大きく影響してきます。
全社に展開する
ここまで準備が出来て初めて全社展開の計画を策定する事が可能となります。間違ってもこの順番を逆にしてはいけません。それは業務をよく知る自分達がRPAについてあまり理解していない内に全社展開の計画を策定しても、その計画通りに進められる可能性が極めて低いためです。
全社レベルで業務を見直し、俗に言うBPRをしたいのであればこの計画を策定する時点が良いかと思います。この時点であれば、実際に業務しているユーザーにもRPAによる自動化のイメージがついて、良いアイディアが出てくるかも知れません。
また、過去の教訓からかシステム導入と言うとリストラを連想する業務ユーザーが多いのも現実です。そうではなく、
日本は人口減少社会に突入し、明らかに労働力人口が減っていきます。今の業務のやり方を継続する事自体が不可能になる可能性が高いと言う点を十分理解してもらう必要があります。
日本企業はまった無しの状況なのです。
その辺りの業務効率化効果を全社に訴求し、プロジェクトを進めやすくする為にもRPA導入のROIを計測し、全社にアピールするような啓蒙活動が必要にもなってきます。
スケールさせる視点を持つ
社内導入範囲の拡大
RPAは導入アプローチさえ間違わなければ、明らかに高いROIを出せるソリューションです。パイロット導入で業務効率化の効果を実感し、業務ユーザー自身が「いける」と感じられるようになったら、社内への展開を本格的に進めましょう。
SCM上の上下流への拡大
RPAの導入・展開において意外に見落とされがちなのがこの点かも知れません。特に
- グループ会社が多数あり、それぞれに経理・総務・人事などの間接部門を持っている
- 複雑な物流網を持ち、外部倉庫に自社資産在庫を多く持つ
- 輸出入に伴う諸手続き、フォワーダーへの依頼、税関書類などの相手国別の事務処理が多い
- 物流業者を日々多数使い、柔軟に数量や納品日などを調整する必要がある
- SCM上の上下流の企業との受発注、出荷指示やASNデータのやり取りにおいて、ある程度自社のコントロールが効く
などの様な業務の場合、SCM上の上下流へのRPA展開は大きな効果を発揮する可能性があります。なぜなら、今でも会社を跨ぐこれらのやり取りはフォーマットを揃えるような人手で行っている業務が多いためです。
既存アプリケーション資産との連携拡大
RPAで自動化しようとする業務の多くは基幹システムのように、システム開発当初から「カッチリ」と要件を確定できない、「柔らかい」柔軟な対応が求められる業務です。
逆に言うと、下記のような特徴の業務にこそRPAを導入していくべきなのだと思います。
- システム化が難しい
- システム化しても直ぐに業務が変わってしまう
- システム開発する程の業務量ではない
まとめ
この様に、RPA導入を従来型のシステム開発として進めてはいけません。それは業務そのものであり、従来型のシステム開発の範囲になり難かった、
- 柔軟な人手の対応が必要だった業務
- 分類・例外が多く人間の判断が要求されるような業務
などを自動化しようとする取組みであって、完全に要件を確定できて、その効果があるのであれば既に基幹システム等の機能として実装されているでしょうし、そうするべきなのだと思います。
業務を少しでも効率的に進められるように育てていく継続的な改善活動のツールがRPAであり、ロボット社員を採用し育成していくように対応すべき
なのです。
