ERPでもSaaS型クラウドサービスが定着してきていますが、クラウドサービスは定期的な再テストが必要になります。周辺業務を含めてRPAで自動化、業務効率化することでERPへのアドオン開発を減らし、周辺システムを含めた業務フローの効率化が可能となります。
ここでは、その辺りを含めた従来はERPへの追加開発で対応していた開発をRPAで代替出来ることをご説明しています。
殆どのERP導入プロジェクトが予算オーバーになる
ERPは画面からの手入力が基本
ERPとしてはドイツのIBM技術者がスピンアウトして作ったSAPが有名あり、その基本は画面からの手入力です。そこには日本企業が得意な作業の無駄を省くような考え方は殆どありません。
むしろ、現場は指示された通りに何も考えず画面に向かって入力する事を求められ、その手入力の正確性が彼らの評価ですし、むしろそこに仕事を残しているのではないかとさえ思えます。
そして、画面自体にマスターのチェックロジック等が入っているためデータベースに直接データ投入したりするのは非常に危険で通常はやりません。SAPの導入プロジェクトでもバッチインプットと言われる画面マクロでデータを投入します。
ERPアドオン開発の実態
日本企業にERPを導入しようとすると、手作業が既に簡略化されていたり、自動化されているため今更画面への手入力に戻すことも出来ずに大量のアドオン開発が発生するのです。典型的なアドオンは下記のようなものです。
- 周辺システムとERPの連携
- 帳票・レポート類
- トランザクション間の自動化
- 自社の特殊業務ロジック追加
しかし、言うまでもなくERP導入プロジェクト成功のカギは如何にアドオン開発を減らせるかに掛かっています。
ERPには極力アドオン開発しない
◆ 周辺システムとERPの連携
先にも書きましたが、ERPは画面からの手入力を基本にしていますので、この辺りが日本企業の現場が強く、極力自動入力する考え方に合わないため、プロジェクトの中で周辺システムとの連携インターフェースを開発することになっていくことが多くなってきます。
このようなシステム間を繋ぐことこそRPAが得意とする作業ですので、このシステム間インターフェース開発をRPAで減らす事が可能となります。
◆ 帳票・レポート類
これも、画面からの手入力を主な職務とするブルーワーカーがいない日本企業では、どうしても様々な業種・業態に汎用的に対応するためのERPの多くの画面項目が不要で、邪魔に感じます。
そして、多くの自社には不要な項目があるために画面遷移が増え、使いづらいと感じてしまう原因にもなってしまうのです。
この点も人が手入力するのではなく、RPAが自動で行うのであれば、多少見づらくても関係ありませんので、RPA化することでERPへのアドオン開発を減らす事が出来ます。
◆ トランザクション間の自動化
これも欧米特有の考え方から来てるのですが、全ての業務プロセスを個別に全てマニュアル処理するようにERPはできてています。例えば販売処理であれば、
- 引き合い登録
- 受注登録
- 在庫確認・引当
- 在庫ピッキング
- 出荷処理
- 出庫処理
- 請求
大まかには上記の様に全て個別のトランザクションとして実行しますが、日本企業であればこれらの内、自社に重要ではない業務処理は恐らく連続して処理が流れるようにアドオン開発すると思います。
また、自社のグループ会社との会社間購買・販売では更に購買側と販売側は裏返しの処理になりますので、殆どに日本企業がこの販売処理と購買処理を同時に自動入力するようにアドオン開発しようとすると思われます。
そしてこれらのアドオン開発も、殆どの場合RPAで自動実行することが可能になるものと思われます。
ERPはコア部分を変更できない
ERPとは在庫などの物の動き（ロジスティクス）が発生した時点で同時に自動仕訳と言われる機能で会計仕訳を自動転記するシステムです。
この部分の機能ははあまりに複雑であり、ほぼ変更が出来ないと言えます。また、余程の事が無い限りその必要性も発生しないものと思われます。殆どのERPへのアドオン追加開発は上記の３タイプ、もしくは自社の特殊業務ロジックの追加なのです。
よって、ERPへの追加アドオン開発の内、RPAで自動化できないのは最後の「自社の特殊業務ロジック追加」のみになり、逆に言うと、それ以外のERPへのアドオン開発はRPAで不要となるのです。
RPAでERPアドオン開発を代替する
ERPアドオン開発をRPAロボで大幅削減できる
ERPの導入は大手コンサルティング会社やIT会社に委託して開発する事が多いかと思いますが、RPAであれば自社もしくは安い単価の要員でシナリオ構築可能となり、アドオン開発もその費用も大きく削減できることになります。
ERPの導入プロジェクト自体をコンサルティング会社に依頼するのは正しいと思います。なぜなら、その導入過程で業務整理したり、業務フローの見直し、切り出しなどの主に間接業務の効率化をするのが通常だからです。
ERP周辺業務を含めて業務を効率化する
ERPの導入プロジェクトをやっているとこれを機に業務を見直そう、と言う話が出てきます。むしろ業務効率化を目的にERPを導入する会社も多いかと思います。そして実際に業務している現場の方を入れて話を進めているとあれもこれも、とアドオン開発が膨れ上がっていきます。
当然です。実際にその業務をしている方にとっては毎日繰り返し行っている作業であり、「同じ作業の繰り返し ≒ 無駄さ作業」に感じてくるのです。しかし、たいがいの場合ERPに閉じた業務は少なく、周辺システムを含めた一連の業務プロセスになっています。
そして、その間にExcelでの手集計作業が必要だったり、得意先からの紙の注文書やFax、紙の伝票などが入っています。そこにRPAロボットで間を繋ぐ意味があるのです。
業務フローを柔軟化し変革を加速する
ERPの内部に（SAPであればABAPで）開発してしまうと、業務が硬直化してしまいます。なぜなら、高額をかけてアドオン開発すると、簡単には変更できなくなってしまうからです。
しかし、益々ビジネス環境変化が加速している現状において、仮に一旦業務を最適化してERP導入したとしても直ぐに外部環境が変わってしまう事が想定されます。
殆ど変わる可能性が無いコア業務部分にERP標準業務フローで導入し、周辺業務をRPA化することで柔軟性を保ち業務を変革する
のが正しいのだと思います。少なくとも現時点では。
RPAでテスト自動化すると再現テストが容易になる
ERP導入プロジェクトでは、実際に使いだす前に業務シナリオに沿った一連のテストを実施します。これこそ正に上記でも触れているERP周辺業務を含めた業務フローであり、今は殆どのテストを手作業で実施しています。
無駄ですし、問題があると毎回誰かが手作業で再テストする必要があります。この場合でも人が変われば全く同じテストを実施したと言えるでしょうか。周辺業務も含めてシナリオ化しておけば、毎回そのテストシナリオを実行することで再現性に問題ありません。
そして、シナリオテストが完了するとデータ移行になりますが、ERPの場合、会計伝票まで紐付いて入っているため個別のデータとして投入することが基本的に出来ません。ここでも上記テストと同様に画面から投入するため同じシナリオが使えるのです。
高額なコンサルティング会社に単なるシナリオテストを依頼するよりも遥かに効率的で再現性があり、その後の業務にもそのRPAシナリオが活用できるのですから一石二鳥以上
SaaS（クラウドサービス）への対応
ERPも最近はクラウド環境に導入してSaaS型サービスとしての使い方が浸透してきています。スピードを重視する意味では非常に理にかなっていると思いますが、いくつか難点かあるのはご存知でしょうか。
- アドオン開発に多少制約（全く出来ないわけではありません）
- 開発元のパッケージベンダーがパッチやPGM修正を（彼らのタイミングで）適用するため、毎回テストする必要がある
１．に関しては正にERP内部にアドオン開発するのではなく、周辺連携を含めRPAする事をお勧めしている立場なので、むしろ同じ方向性かと思います。そして、２．に関してもパッケージ開発元が言ってきたテスト猶予期間にRPAシナリオを実行して再現テストをすれば良いだけとなります。
正に、現代にマッチしたERPの導入方法だと思います。
