そもそもRPAの基本的な形はどこにあるのかというのも考えたので、メモって行こうと思います。 その前に、業務とは何かを考えましょう、、こういう話って人気ないんだけど、まあいいや。
基幹システムのような業務システムは、皆さんの会社にもあるでしょう。このようなシステムはどういう構成になっていますか？
システムは次の３つのバランスで構成されています。
- 業務
- 機能
- データ
です。 ここらへんは、渡辺幸三先生のご著書をお読みください。「販売管理システムで学ぶモデリング講座」は特におすすめですよ。
もう少し、システムの３要素「業務」「機能」「データ」 について考えましょう。
発注業務で考える
実際の業務手順を想像してもらえばいいですね。
あなたが発注書を受け取って、販売管理システムに登録する業務を担当しているとします。
発注金額等のチェックはすでに課長がチェックしています。あなたは入力する係です。
販売管理システムにログインして、メニューを操作して発注登録画面を開きます。発注入力画面には、商品マスタ検索機能や取引先検索機能が付いています。取引先No、発注日、納品希望日などを入力し、商品ごとに発注数量を入力し終えたら、登録ボタンを押します。
この一連の手順は「業務」ですね。
システムには商品マスタ検索機能や取引先検索機能、発注登録機能が備わっていましたね。これは「機能」です。
登録ボタンを押すとデータベースの「発注書データ」と「発注明細データ」に整合性が取れた状態でデータが書き込まれます。この時、システムのユーザーであるあなたはデータベースの構造を意識する必要はありませんね。これは「発注登録機能」が機能しているからです。
このようにシステムの３要素「業務」「機能」「データ」があるから、日常の業務が可能になります。この3要素はそれぞれ独立しているのですが、お互いに影響しあってシステム設計が行われているわけです。
たとえば、業務手順がイレギュラーなら、それに合わせた画面が必要であり、機能も必要です。データベースもイレギュラーな構成にしておかないと対応できないかもしれません。
とはいえ、データベースを変更するのは大変ですから、リリース後に業務手順がイレギュラーな方法に変わったからといって、データベースをいじることはあまりありません。
リリース前の設計段階なら対応できるかもしれませんがね。
通常、業務手順が変わると、データベースは変えずに画面を変更し、機能を追加したり、機能変更したりすることで対応します。これが「システム改修」と呼ばれるものですね。
という感じで通常の業務と呼ばれるものが3つの要素から成っていることがわかってきたと思います。
RPAとは？
で、RPAですが、基本はこの「業務」部分をロボットにやらせようという発想です。
ようするに「業務手順」をロボットに覚えさせて、自動化しようというわけです。
業務手順は人が行っている作業なので、ロボットにやらせてもできるだろう、ということですので、わかりやすいですね。
ロボットは妥協している？
しかし、ちょっと考えてみましょう。
システムの３要素「業務」「機能」「データ」は互いに影響しあっていますね。
人間が行うことを前提としてる「業務」部分をロボットが行うことは、本来想定されていないことです。
ということは、 ロボットが行うにはムダが多いし、ムリが発生することもあります。
RPAロボットに業務を代行させると、「システムにログインし、メニュー操作し、画面で日付を設定し、商品マスタ検索ボタンを押し…」となります。人が行うのと同じことを代行させるからです。
でも、RPAはコンピュータソフトウェアなので、機能に直接アクセスできる、もしくはデータベースにアクセスできる可能性だってありますよね！？
もし機能やデータベースに直接アクセスできれば、「業務手順」は必要なくなります。
ロボットを使うなら、ロボットに合った業務システムの在り方にしないとムダ・ムリは発生します。3つの要素は互いに影響し合っているのだから。
そこを強引に現状に合わせるから、変になります。
RPAで業務を強引に自動化しているということは、変になるんだけど、「工数・費用・技術力」の面から妥協している、という状態なわけです。
RPAの利用方法を考えよう
結局、RPAを利用していいんです。
いいんですが、自分たちは何をしようとしているのか？を理解したうえで、利用しましょう、という話です。
業務の3要素のどの部分を自動化しようとしているのか、という目線で考えたことはないでしょ？
ただ、「RPAは人の代わりに業務を行うことができる」という話のまま、今日まで来ていると思います。
でも「RPAは業務の代行」という定義は決まったものではなく、ただのセールトーク。売る方も理解していないんです。
わかりやすく、使う人にささる切り口で売った方が儲かるから、そう言っているだけなんです。
僕たちは使う方なんで、どう使うかは、こちらで定義し直していいですよね？
RPAの再定義として、僕が実務に合っているものは今のところ３つ。
- API連携の代わり
- アプリ機能の拡張
- 独自アプリ開発
どれも「業務手順」の代わりではありません。以下の記事に少しまとめています。 合わせてお読みください。
コメント ログインすると書き込めます