アゲ出しLife

RPA、ときどき雑記

【RPA】未だに「RPA始めるならまずBPRから」とか言ってる人がいて驚く

f:id:getsun:20190404225220p:plain

つい先日、ある企業と話していたら「RPAを始める前にBPRをしっかりすることでロボットの効果を最大限にできるって提案をもらってるんです」という言葉を聞いて椅子から落ちそうになりました。

まだそんな提案するやついんのか、、、と。

 

※BPR=ビジネス・プロセス・リエンジニアリングで、業務や組織構成の抜本的な見直しです(以下参考リンク)

www.kaonavi.jp

 

 

RPAとBPRの関係性というのは、色々な場面で語られており、解釈もいくつかあるんですが、根本としてはRPAはBPRの直接的あるいは間接的な手段であると思います。

 

順序を間違えるとRPAのメリットを損なう

RPAの大きな利点は、以下の2ポイントがあります。

  • 現行業務を変えずにロボットに置き換えることで自動化できる
  • 一般的なのSIやBPRより短期間・低コストで実現できる

 

いわば「安い・早い・美味い」ですね。

 

で、今回言われている「先にBPR」なんてやっちゃうってことは、せっかく安くて早くてそのまま使える手段があるのに、敢えて高くて遅い手法をその前に持ってくるってことです。

 

BPRが終わるまでロボットは動き出せない、というか開発にも着手できないわけですから、RPAが効果を発揮し始めるのはその分遅くなってしまいます。

 

しっかりとしたBPRが必要なくらい現行業務が入り組んでいるのであれば、それこそRPAを優先して取り組むべきです。

早くて安いRPAで、BPRに腰を据えて取り組む時間を創出するという考えの方が、トータルで見た削減時間は大きくなるはずです。

(そもそもそんなに入り組んだ現行業務を走らせながら、BPRなんてやってられないですよ)

 

その上で、BPRによってRPAの効力を最大化できるような業務を構築していくのが、あるべき論ですが、理想型です。

 

そもそもRPAは作成後の修正・改善・拡張も用意ですから、アジャイル的にスピード感を持って進めるのに適していますから、ウォーターフォール的なBPRの後に配置するのは勿体ないと思うんですよね。

※細切れに、かつ頻繁に人間の判断や承認が入るような業務は、自動化による削減効果を得にくいため、例外となります 

 

 

少し話が逸れてしまいますが、「腰を据えて検討する時間をRPAによって創出する」という考えは、アンチRPAの方にこそご理解いただきたいものです。

 

いつも引用させていただいているorangeitems様の記事になりますが、

www.orangeitems.com

>効率の悪いシステムや業務フローの延命策でしかないという声も耳にします。

RPAを毛嫌いするSIの人には本当に言われていることです。

 

ただ、これだって次期をよりよいものにするための延命だとしたら、何か悪いんですかね?

自分の仕事が欲しくて「そろそろシステム更改の時期ですね!」なんてやってるよりよほど誠実ではあると思います。

 

 

それで大きいSI案件が減るのは困るというのは私だってIT企業の人間なのでそうなんですが、為す術がないからってタラタラ文句だけ言っているのは、単に時代についていけていないだけだとも思う訳です。

遅かれ早かれAIに奪われる領域だったものを、想定より早いタイミングでRPAが登場してかき乱されているのが不満なんでしょう、と。。。

 

 

まとめ

RPAとBPR、どちらが先か、と言われたら、基本的にはRPAを優先すべきです。(例外あり)

その上で、RPAでBPRのための時間を創出するという発想をもつことで、RPAとBPRは互恵関係にまで発展し得ます。

 

RPAというまだ新しい単語に反発したい気持ちから、後に回したがる人もいらっしゃると思いますが、ぜひ一度、手を触れてみてください。