RPA入れたけど、効果出るかな……
RPA（ロボティック・プロセス・オートメーション）の失敗として語られるのは、ロボットが止まる形です。
- 連携先の画面が変わって動かなくなる
- 作った人が異動して直せなくなる
- 使われないまま残る
私は、その手前にもう一つの形があると考えています。
ロボットは動いているけど、効いたかどうかを言えない状態です。
私は複数拠点で展開する汎用ロボットを開発した経験があります。
立場的に削減できた時間を記録していませんが、事前と事後の評価は重要です。
この記事では、以下の3点についてお伝えします。
- 「効いた」と言うために要る3つの条件
- 導入前にしか取れない数字
- ロボットが止まったあとに残る仕事
RPAの失敗は、止まることだけではない
ロボットが止まること自体は、避けようがありません。私にも、壊れない形は作れません。
RPAは、人がやっている画面操作をそのまま代わりにやる仕組みです。連携先の画面や仕様が変われば、動かなくなります。
私が作ったロボットでも、仕様変更への対応は発生しました。
そのうえで、もう一つの形があります。
ロボットは動いている。人の手も離れた。それでも、何がどれだけ効いたのかを言えない。
- ロボットは動いているが、削減できた時間を言えない
- 数字は改善したが、何が効いたのかを分けられない
- 次に何を自動化すべきかが決まらない
これは失敗ではありません。数字が目標を超えて改善していることもあります。
残らなかったのは成果ではなく、方法のほうです。
方法が残らないと、2本目のロボットで同じ判断ができません。1本目がなぜうまくいったのかを、社内の誰も説明できないためです。
「効いた」と言うには、3つの条件が必要
効いたかどうかを言うには、3つの条件が揃っている必要があります。
3つのうち2つは、導入したあとでは取り戻せません。
この3つは、RPAではなく別の改善から私は学びました。大手BPO企業で担当していた架電業務の改善です。
1時間あたりの架電数を、21.3件から24.2件まで動かしました。
1. 判定する周期は、見る周期とは別に決まる
架電数は日次でも週次でも集計していました。上司への報告にいるためです。
それでも、判定には使えません。
日次の数字は、施策以外の理由で揺れが発生します。その日の架電先や入っていたメンバーでも変わるためです。
架電先が電話に出ないと、通話が短く終わります。すると件数だけが伸びます。
数字が上がったのに、中身は悪い日があるのはそういうことです。
だから週次は目安程度に、判定は月次で行いました。同じ数字に、2つの周期が要ります。
| 周期 | 何で決まるか | この案件での実際 |
|---|---|---|
| 見るための周期 | 判断が必要になる頻度 | 日次・週次 |
| 判定するための周期 | 数字が揺れなくなる幅 | 月次 |
2. 変える前の数字は、変える前にしか取れない
架電数の21.3件/時という数字は、kintoneに手を加える前の月次の実測値です。
あとからさかのぼって作っていません。
変える前の数字を持っていたから、24.2件/時と比べられました。それだけを見せられても、良いのか悪いのかは判断できません。
RPAでも同じです。導入前に人が何分かけていたかを測っていなければ、削減した時間という数字は出てきません。
3. 同じ時期に、他に何を変えたかを書き留める
架電数が21.3件から24.2件へ動いた期間、走っていた施策は3つありました。
kintoneの改修、トークスクリプトの見直し、オーダー件数を増やす施策です。
数字は目標を超えて改善しました。それでも、どれがどれだけ効いたのかは言えません。
施策を1つに絞れ、とは書きません。稼働している業務では、効果が読めない施策を1つだけ試して待つ選択が取れないからです。私も絞りませんでした。
代わりに、同じ期間に何を変えたかを、書き留めておく。
何が効いたか分からないという結論は、何も分からない状態より情報量が多いです。次に1つずつ試す順序を決められます。
- 判定する周期が、数字の揺れる幅に合っている
- 変える前の数字を、変える前に持っている
- 同じ期間に他に何を変えたかを、書き留めてある
上の2つは、着手した時点で決まります。導入したあとに気づいても、変える前の数字はもう取れません。
RPAが失敗する理由は導入前に決まる、というのはこの意味です。
導入前に測っていない時間は、後から出てこない
削減効果の計算式は、どこで見ても同じ形をしています。導入前の1件あたりの作業時間に、年間の件数と時給を掛ける。
この式は、導入前の作業時間が分かっていることを前提にしています。
私が作ったRPAのロボットは、6つの拠点で使うものでした。各拠点の担当者が手作業でやっていた条件の絞り込み、ダウンロード、転記を自動で動く形にしています。
手元に残っているのは、作業時間が多くかかり日常業務を圧迫していた、という状態の記述だけです。これは数字ではありません。だから私は、あの案件で何時間減らせたのかを言えません。
作る側は、測らないままでも作れてしまいます。私自身がそうでした。
測るのは頼む側の仕事だと考えています。頼んだ側が測っていなければ、記録はどこにも残りません。
その点は発注段階で記録を残しておきましょう。
- その作業に、1件あたり何分かかっているか
- その作業が、月に何回発生しているか
- その作業を、今は誰がやっているか
3つとも、ストップウォッチと数え上げで足ります。専用の道具は要りません。
どこにどれだけ時間がかかっているかを数字で出しておくこと。これを業務の見える化と呼びます。
何を自動化すべきかは、見えていない状態では決められません。順番として、こちらが先に来ます。
詳しくは業務の見える化とは、結局何をすることなのかで書いています。
止まったときに直せる人は、作る前に決める
止まること自体は、失敗ではありません。止まったときに直せる人がいないことが、失敗にあたります。
私が作ったロボットは、渡す先が作る時点で決まっていました。社内の情報システム担当の方に、操作のレクチャーと研修を実施しています。
ですが、渡す先の部署を決めることと、直せる人の数を決めることは別です。
渡す先さえ決めれば足りる、という話ではありません。
社内の特定の1人に依存している状態を、属人化と呼びます。社外に依存する丸投げとは、向きが逆になります。
日々の作業から人を外した先に、1人だけが直せる場所を作る。作業の属人化を減らして、仕組みの属人化を足す形です。
止まらないようにするためにも以下の3点をあらかじめ決めておくのが良いでしょう。
- 仕様が変わったとき、誰が直すか
- その人以外に、直せる人を何人にするか
- 直せるようになるための時間を、誰の工数から出すか
導入を決める前に、3つの問いに答えておく
ここまでの話を、導入前に答えられる形にします。
その場で即答できなくてもかまいません。社内に聞けば分かる状態であれば、答えられるうちに入ります。
- 自動化したい作業に、1件あたり何分かかっているかを言えるか
- その作業が減ったとき、どの数字が動くかを言えるか
- ロボットが止まったとき、直せる人を何人にするかを決めているか
3つともNoでも、導入をやめたほうがいいという話ではありません。
ただしその状態で入れたロボットは、効いたかどうかを後から言えなくなります。
1つ目と2つ目は、導入したあとでは取り戻せません。
先に測っておくと、あとで戻らずに済みます。
3つ目は、数えるだけで答えが出ます。動いている仕組みを直せる人が、社内に何人いるか。
私が関わった案件では、その答えは1人でした。
まとめ：ロボットを選ぶ前に、今かかっている時間を測る
読み終えたあとにやることを、1つだけ挙げます。
自動化しようとしている作業について、今かかっている時間を測ってください。
- 1件あたり何分かかるかを、3回分計る
- 先月その作業が何回あったかを、数える
- 2つを掛けた数字を、メモに残す
これだけで、導入後に比べられる形になります。ロボットを選ぶのは、そのあとで間に合います。
そもそも自社がどこで詰まっているのかが分からない。
そういう段階であれば、3分で終わる診断を用意しています。見える化・自動化・内製化のどこが弱いかが出ます。