この記事は chillSAP 夏の自由研究2021 の記事として執筆しています。
はじめに
コロナ禍でDXの需要が高まっており、RPAを利用している企業が増えてきました。
RPA(Robotic Process Automation)というのは一言でいうと「パソコンの業務を人間のようにこなしてくれる自動化ツール」のことです。以下の図で示しているようなことができます。
具体例でいうと、「エクセルにある社員情報データを一行ずつ人事システムに登録」、「ウェブサイトにあるニュース情報を取得して、メールで関係者に送信」といった元々人間がPC上で行う操作をRPAで代替えできます。
SAPプロジェクトの中でもRPAを使う機会が増えてきましたが、「どこで使えるか分からない」といった原因でRPAはまだまだSAPプロジェクトに浸透されていないようです。今回は、私が参画したSAPプロジェクトから得た経験をもとに、UiPathを使ったSAPでの活用方法をシェアします。
本文
SAPの連携方式とUiPathのSAP自動化ソリューション
SAPとデータ連携には様々な方式がありますが、API連携として良く利用されているのが、SAPが標準提供しているBAPI(Business Application Programming Interfaceの略)でしょう。また、RPAの台頭によりSAPの画面操作からのデータ連携(以降GUI連携と言う)も可能になり、画面連携を利用しているところも増えてきています。
SAPプロジェクトで、RPAツールを検討する際にBAPI連携とGUI連携両方対応できるRPAを選択するのがおすすめします。その際に、いくつか考慮しなければならない点があります。
〇 利用しているSAPのGUIクライアントに対応できているか
SAPのGUIクライアントはいくつかあります。ECC時代からお馴染みのWinGUIと、WinGUIをウェブブラウザからアクセスできWebGUI、S/4HANAから利用可能になったFioriがあります。SAPのクライアント画面は、内部的にかなり複雑な構成になっており、うまく画面項目を認識できないRPA製品もあります。
例えば、Fiori画面は内部的にSAP UI5を利用しており、独自のHTMLプロパティを持っています。こういった独自のプロパティを取得できないと、画面項目をうまく認識できません。
そのためRPAプラットフォームを検討する際に、自社のGUIクライアントで自動化利用できるかは重要なポイントになるでしょう。
〇 BAPIコネクターの使いやすさ
自分でプログラムを書いてBAPIを呼び出して使うのは大変な作業になります。また、BAPI自体もREST APIのように簡単に扱えるのではなく、仕組みを理解しないと意外にできなかったりします。そのため、簡易に利用できるコBAPIネクターがあると便利です。
RFCを呼び出すケースもありますので、RFCも対応できる点も重要です。
UiPathは画面とBAPIの両方から自動化可能になっています。SAPのすべてのGUIクライアントにも対応しているようです。BAPIもコールしやすいように設計されています。さらにSAP向けに様々な専用ソリューションも出しているようで、SAPとの親和性がかなり良いです。
以下は、現時点で私が把握しているSAP専用ソリューションです。UiPathのMarketPlaceからも確認できます。
SAP GUI アクティビティ ⇒ ログオンからログオフまでの自動化をカバーしているアクティビティ群(※ UiPathの中で、クリック、入力、ログインといった操作をアクティビティと呼んでいます。アクティビティを並べていくことで画面の自動化を実現しています)
リンク: https://docs.uipath.com/activities/docs/sap
UiPath SRC(SAP Reusable Components)部品 ⇒ そのまま利用可能な部品100本以上があって、SAPの会計、生産、購買、販売のコア業務をカバーしているようです。データ移行にも使えるツールもそろっています。現在名称をUiPath Accelerators for SAPに変更したようです
リンク: https://marketplace.uipath.com/ja/bundles/sap
なお、UiPath社のSAPソリューションの全体像紹介は以下のページから確認できます。
https://www.uipath.com/ja/solutions/technology/sap-automation
UiPathの活用領域
UiPathとSAPの親和性が非常に高いことが分かったところで、SAPプロジェクトの中でUiPathをどのように活用するかを紹介していきます。
業務自動化
前述の通り、RPAは、データ収集、データ加工・入力、入力チェック、レポート出力、システム連携といったことを得意としています。SAPではUiPath RPAを利用して、伝票入力やマスタデータ登録、レポート出力などの業務をよく自動化されています。また、UiPathとAI/OCRの相性も良く、AI/OCRで請求書データを読み込み、UiPathを使いSAPに転記するような利用ケースも多いです。
UiPath RPAは、プログラミングのように自由に扱うことができますので、自動化できない業務はすくないですが、開発コストなどがかかるため、どの業務を自動化するかを費用対効果で見極める必要があります。費用対効果の高い業務から自動化していくのが無難でしょう。
システム連携
システム連携はどこの企業にとっても悩ましい問題です。SAPとその周辺システム(会計、経費生産、CRM など)の連携も例外ではありません。
~UiPathを介さずシステム間直接連携~
SAPと連携するため、連携する双方システムのいずれかを改修する必要があります。最新のクラウドシステムでは、標準APIが用意されているのが多いですが、レガシーシステムですと、APIすら用意されていないのも少なくありません。
例えば、下図のように、SAPを会計システムと連携させるため、どちらか一方の標準APIに合わせる必要があります。会計システムに合わせるのであれば、SAP側でアドオンプログラムを開発する必要があります。アドオン開発になると、開発費用が高く、システム最適化の観点からも望ましくない状況です。一方で、SAPのBAPIをコールする場合、会計システムにてBAPIをコールできる実装を追加しなくてはなりません。いずれも簡易な作業ではありません。
また、システムがバージョンアップするたびに、標準APIが変わっている可能性もあるため、その都度システム改修が発生するかもしれません。特に、最近のクラウドシステムが、市場競争に製品機能の優位性を持たせるため、年間のバージョンアップ回数が多く、機能や仕様が知らずに変更されたことも少なくありません。
~UiPathを利用したシステム連携~
一方で、UiPathを利用した場合、UiPathだけで連携双方システムにアクセス可能です。また、APIが用意されていないレガシーシステムてあってもUiPathを利用し画面操作もしくはデータベース操作でシステム連携できます。改修もUiPathだけで済むため、既存システムに影響を与えないというメリットがあります。
例えば、Salesforceから受注データを取得し、SAPのデータ形式に合わせてデータを加工しSAPに受注データを投入するようなことができます。さらに、SAP側で生成された伝票番号をSalesforceに転記するようなこともできます。UiPath社はこういったシステム連携のために、RESTとSOAP APIを呼び出せるアクティビティだけではなく、様々なシステム向けの専用コネクターも提供しています。私が関わっているプロジェクトでも、SAPとSalesforceの連携でこういったコネクターを大いに活用しています。
また、試したことがないですが、Oracle、PostgresといったSQLデータベースにも接続できるアクティビティも用意されているようです。こんなに連携手法を持っており、UiPathで連携できないシステムはないじゃないかなと思いました。
S/4HANAへの移行
「2027年の崖」を乗り越えるため、この2年ぐらいに、S/4HANAへの移行プロジェクトが非常に増えてきています。S/4HANAへの移行プロジェクトでのRPA活用方法もすこし紹介していきます。
データ移行
S/4HANAへの移行プロジェクトにて旧システムからS/4HANAへのデータ移行が悩まされるところです。単純にECCから移行であれば、SAP社も専用ツールを提供しています、そちらを利用するのが無難でしょう。しかし、新旧システム並行稼働中に起きた差分データと一部のマスタデータ、SAP以外のシステムのデータに関しては、別な方法で移行させなければならないです。そこでUiPathをフル活用した経験があります。
例えば、既存の購買システムから購買データをSAPに移行する際に、UiPathが提供しているSRC部品を利用しました。また、UiPathのBAPIコネクターを利用し、RFC_READ_TABLEをコールし、データをECCから抽出した後に、S/4HANAに登録したこともあります。
アドオン削減
S/4HANAへの移行に伴い、コストの削減とシステムの最適化という観点から過去に作成したアドオンを削減したいといったニーズが少なくはありません。
そうした際に、導入手法をFit to Standardにする企業が増えてきています。むしろ最近ほとんどがFit to Standardになっています。
Fit to Standardは、SAPシステムの機能に合わせて、自社の業務を変更して適用しようとする手法です。その手法を採用する結果、アドオンは自然に減りましたが、アドオンが減ったことによって現場の業務がかえって増えたというようなことも起きています。業務効率の衰退によって現場のユーザ満足度も下がり、S/4HANAの導入効果が現場から疑問視されるのも仕方がありません。
S/4HANAの導入では、こういった現場のニーズを無視し、単なるアドオン削減の活動を避けなければなりません。そこで、UiPathを活用することで、アドオンの単純代替えはともかく、こういった業務変更によってできた穴を埋めることもできます。現場ユーザにしてみれば、元々アドオンで行っていた業務をUiPathで自動化すれば、自分の業務が自動化されたため、S/4HANAの導入で高い満足度を得られるはずです。
言うまでもなく、すべてのアドオンをUiPathで代替えするのが現実的ではないです。ABAPプログラムで開発しやすいかつ効果的なケースも少なくありません。どのアドオンをUiPathで代替えするかは、開発コストと、業務効率、ユーザ満足度、システム構成の最適化といった観点から検討する必要があるでしょう。
テスト
SAP移行プロジェクトの中で、テスト業務多く抱えています。特にS/4HANAになってからアップデートの回数が増えてきて、リグレッションテストのような業務が現場の人を苦しませています。私が参画したプロジェクトの中で、UiPathを利用し、標準トランザクションテスト、権限テスト、リグレッションテストなどしています。特にテストの回数の多いところはUiPathで行うのがかなり効果的です。
UiPathのテスト専用なソリューションとして、Test Suiteというテスト専用の製品群があります。既存のRPAの上で、テストエビデンス自動収集、テストケース管理、モバイルテストといった機能を加えた模様です。自分はこの辺のキャッチアップを進めているところで、興味のある方は以下のリンクをご参照ください。
なんでUiPathがTest Suiteを出したかを考えたら、RPA元々画面操作のツールで、テストツールとして発展していくのも自然な流れだなと思いました。
まとめ
今回は、SAPの業務自動化とシステム連携、S/4HANAへの移行3つの観点から、SAPでのRPA活用方法を紹介しました。SAPプロジェクトに関わっている皆さんにお役に立てれば、幸いです。