RPAの使い道とBPMとの関係が見えてきた。またBPMとAIとの関係も（AIとの話は次回）。
BPMフォーラムが２０１７年１１月８日にあり「オリックス・ビジネスセンター沖縄株式会社」の基調講演を聞きながら頭の中が整理できた。
この会社はオリックスグループのシェアードサービスセンターである。
すなわち、オリックスグループの事務業務を切り出し、集中化して処理することでグループ全体の事務コストを軽減する機能である。

RPAを使うための条件の話に入る前に、RPAが何者かを簡単に説明します。
PCの上で人が行った手順を覚えて、動く機能と言ってよいだろう。
「手順を覚えて動く」という言葉だけを聞くと、工場の生産ラインのロボットを同じと言えるのかもしれない。

RPAを使うための条件は

①（お客様の）基幹システムの連携を現場サイドの業務改善のために変更することができない
②例えばExcelからの転記（コピペ）作業などの単純作業が固定化され、かつ大量にあること
③なぜExcelを使っているかは（顧客から与えられた）業務の前提条件で変更できないこと

こういった条件がない場合
①はBPMSを使って基幹システム連携で解決が可能である。
②はExcelで行っている作業がなぜ必要なのかという分析を行いExcelの使用をやめ、その機能をBPMSに取り込む

と思っていた。同様のBPO（ビジネス・プロセス・アウトソーシング）を行っている別の会社に訪問してお話をしてみると
やはり、①～③の条件がある。すなわち「根本問題を解決できない」という条件付きである。
前回のコラムで自分が頭の固いことを言っていることに気が付いた。

BPMSはEUC(エンドユーザーコンピューティング）ではないってことを主張していたが、それでもよいのではないか。
すなわちBPMSもRPAも「現場で維持管理できるITツール」なのだと。
ロータスノーツなどにおけるEUCがサイロ化して維持管理やバージョンアップで苦労しているという話から「EUCは失敗する」
というような烙印が押された感がある。確かにRPAは同じ失敗をする可能性を秘めている(見える管理ができないので）。

ところがRPAを使う前提がBPMである場合は話が変わるのではないか。BPMSはその設計図と言えるBPMNによって
何をしているのか、どのような条件で動かしているか「見える」。そしてそのBPMN上のアクティビティを
階層化し、階層化されたプロセスが作業レベルまでブレイクダウンされたものがRPAで動いていることが見えれば良いのである。