10と2の法則とはいつも自分でRPAを開発する際に心がけていることだ
詳細を説明する前に以下、背景となることを述べたいと思う
1.RPAの対象業務はこれまでのシステム化対象業務と違う
2.対象業務の実施者は極端に忙しい、もしくは複雑な業務を行っている
3.世の中、RPAを実際の業務で行っているところを見たことが無い人が大勢
要はこれまでのような業務ヒアリングの仕方は通じないし、ヒアリングを受けている人も期待はするもののあまりピンと来ていない。まともな業務マニュアルの類を提出してもらえることもあまり期待できないだろう
他の言葉で言い変えると、忙しい、もしくは、人への説明が難しいような業務を行っているので、まともに聞いてもシステム化にのるような答えを得るのは難しい。さらに言えばRPAといってもどうしても半信半疑なので、あまり答えるモチベーションもない
逆に、聞く方も聞いてもあまり相手の言うことが良く分からない。何より、使われている言葉が良く分からいだろう。業務の現場で行われていることそのものだからだ。図に落とそうにも何一つかけなかったりする。なので共通言語が何一つ生まれない
そんな時にどうしたらいいか?
とにかく聞いた範囲でRPAを作ってデモしてみることが重要だと思う
目的は2つ
1つは自分の為だ
RPAに業務を載せる為にはある程度の業務の整理が必要だ。
RPAに投入するデータを作成するところから、無理やり業務を系統立てて整理していかねばならない
そして、あれこれ想像しながらRPAシナリオを描いていくと不思議と相手の言っていたことが理解できてきたり、その次に聞くべきことが見えてくる
2つ目は相手との共通言語を作る為だ
RPAの動きを見た業務ユーザーは、RPAと自分の動きを照らし合わせながら次に説明が必要な部分が良く見えてくる。そして、何より重要なのはRPAへの漠然とした期待が確信に変わってきて前のめりになってもらえることだ
だから2つの目的を達成する為に10を理解しようとするより2つでも分かっていることがあったらRPAを無理やり作ってデモすることが重要だ
とは言っても無理なものは無理なところもあるので工夫が必要なわけだが、一番のお勧めは動画を撮らせてもらうことだ
動画を見てからディスカッションするのも有効だろう
いずれにしろとにかく動くことだ。動くことで次に動くべきことが見えてくる
コメントを残す