バージョンアップ対応でネックとなる「アドオン開発」

ERPのデファクトスタンダードであるSAPのERPパッケージ（以下、SAP ERP）は、アーキテクチャの堅牢性やレスポンス性能の高さなどから、ユーザー企業からの評価も高く、導入実績も多い。2015年のバージョンアップでリリースされたSAP S/4HANAに関心を持つ企業も増え、システムインテグレータには導入や改修の相談が数多く寄せられている。

評価の高いSAP ERPだが、システムの開発や改修にあたり、情報システム部門には課題が突きつけられることになる。「SAP ERPの標準機能だけでカバーできないエンドユーザーのニーズにどのように応えるか」という課題だ。特に最近は、ニーズの変化が早い。

「近年、業務の変化、それに伴うニーズの変化のスピードは増す一方です。たとえば10年前、店舗でのデータ入力はPCからが一般的でしたが、今は、スマートフォンやタブレットを使用するケースが増えています。ユーザー企業の情報システム部門は常に、こうしたニーズの変化に応えることが求められるのです」（SCSK ビジネスソリューション事業部門 AMO第一事業本部 ソリューション第二部 第一課 澤 良太郎）

SAP ERPではこれまで、標準機能で対応できない場合、アドオンで開発することが多かった。しかし、アドオン開発にはいくつか問題がある。一つはコストと時間の問題だ。アドオンするシステムの開発には、当然、通常のシステム開発と同程度のコストと時間がかかる。そして、さらに大きな問題がSAP ERPのバージョンアップへの対応である。

アドオン開発したシステムは当然、バージョンアップ保証の対象外となる。バージョンアップしたSAP ERPを導入すれば、アドオン部分は多かれ少なかれ開発し直さなくてはならない。つまり、バージョンアップ費用だけでなく、アドオン開発したシステムの改修にも、コストや時間がかかるのだ。

また、アドオン開発したシステムは、ユーザー企業にとって資産だ。バージョンアップ対応のため、安定稼働する枯れたシステムを捨てるという判断は難しい。そのため、SAP ERPをバージョンアップしないことを選択するユーザー企業も少なくない。しかし、アップデートされないシステムには、当然、セキュリティリスクが潜む。

RPAの活用は、バージョンアップ対応やコスト面などでメリット

そこで現在、アドオン開発を最小限にするアプローチとして、RPAに注目が集まっている。RPAが得意とするのは、簡単に言えば、人が行っているルーティン業務の自動化だ。

「別システムにあるデータやエクセルのデータをSAP ERPに読み込ませたり、SAP ERPから抽出したデータを一定の処理をして再び SAP ERPに戻したりする作業は、すべてRPAで自動化できます」（澤）

つまり、システム間の連携処理やデータ入力作業、あるいは異常値などを検知してアラートを出す処理などは、RPAで対応できるのだ。これは、従来アドオン開発で対応してきた業務の多くが、RPAで自動化できることを意味する。

発注システムで登録された発注情報をもとに、①SAP ERPに発注情報を登録。それをもとに②注文書を作成し、③仕入先にメールを自動送信する。

また、RPAの開発では、アドオン開発と違って、ERPパッケージ自体にほとんど手を入れる必要がない。アドオン開発では、システムを連携させるためにSAP ERP側も改修する。一方、RPAは基本的に、ERPパッケージと切り離した形で開発する。そのため、システムに手を加えることで生じる改修リスクが少ない。

さらに大きなメリットが、RPAであれば、バージョンアップに伴う改修が少ないことだ。切り離して開発されたRPAは、SAP ERPのバージョンアップに伴って、アドオン開発のような大規模改修の必要はなく、安定稼働しているシステムを捨てなくていい。当然、改修にかかるコストや時間が少なく、改修リスクも低くなる。

また一部の日本のユーザーからは、ドイツで開発されたSAP ERPのUIが使いづらいという声も聞かれる。この問題を解消するために、これまでカバーアドオンなどの手法が使われてきたが、そこにも変化が見られる。

「先日、SAP ERPの導入を検討しているお客様から、UIには手を入れずに開発を進めてもらって問題ない、という話をいただきました。疑問に思って理由を聞いてみると、そのシステムではデータの入出力業務をRPAで自動化するそうです。その方が使い勝手が良いという判断です」（澤）

データの入出力業務をRPAで自動化すれば、カバーアドオンなどと比較してコストは下がる。しかもデータの入出力処理とERP本来の機能とを切り分けることで、システム改修の負荷が下がることも期待できるだろう。

つまり情報システム部門にとって、SAP ERPの標準機能で対応できない業務について、「これまで通り人が処理する」や「アドオン開発したシステムで処理する」という従来の選択肢に加えて、「RPAで処理する」という有力な選択肢が登場したことになる。実際、「SAP ERP＋RPA」というソリューションに対する相談は増えている。

SAP ERP＋RPAの設計は業務効率化にもつながる

では、「SAP ERP＋RPA」システムの開発はどのように進めればいいのだろう。基本的な考え方は、アドオン開発の場合と変わらない。SAP ERPが担う機能とRPAで自動化する業務を切り分けながら、要件を定義する。ただしその際、RPAと業務の相性やRPA 導入のROIなどを考慮の上、要件を絞り込む必要があるだろう。

RPAと業務には相性があり、当然、RPAに向いていない業務もある。たとえば、判断する、意志決定する、決裁するといった業務などには向いていない。一方、得意なのは「決められたルールとプロセスに基づいて処理する業務」だ。

「RPAが得意とするのは、業務の手順と規則が決まっている単純な仕事です。RPAで代替可能な業務を、我々ITベンダーがお客様とともに洗い出し、ソリューションとして提案します」（澤）

RPA導入のROIも重要だ。さまざまな業務の現状の業務時間、従事している人員数などを実際に測定し、RPA導入で削減できるコストを計算し、削減効果の高い業務の自動化を進める。その際、データ入力のような業務であれば、RPAツールなら24時間処理可能なことも考慮する。

さまざまな観点から自動化する業務を絞り込んだら、次は設計だ。具体的には、エンドユーザーにヒアリングした業務のルールとプロセスをロジックツリーに落とし、実際の業務とズレがないかを確認する。こうした業務の見える化は、業務の効率化にもつながる。

「RPA化する業務のプロセスやルールを確認し、それを図解することで業務理解を深めます。と同時に、図をお客様に見せることで、業務の無駄に気づいていただき、業務見直しにつなげます。こうした業務効率化もまた、RPA導入の大きなメリットなのです」（澤）

SCSK ビジネスソリューション事業部門 AMO第一事業本部 ソリューション第二部 第一課 澤 良太郎

RPA導入にかかる時間は、アドオン開発と比べれば短い。また、簡単な業務の自動化であれば、ITに慣れているユーザーでも対応できるだろう。そのため、「簡単に導入できる」と考えがちだが、「ユーザー部門主導の導入はリスクが大きい」と澤は指摘する。

「たとえば、データ入力の作業であれば、年に１回くらい発生するイレギュラーな数値の入力に対してエラーが出ることもあります。エラーが出れば、当然、システムが止まり、業務の停止、ひいては損害につながりかねません。情報システム部門主導で我々が入って導入する場合、こうしたエラーを未然に防いだり、被害を最小限に抑えたりするようにRPAを設計しますが、ユーザー部門主導だと、そうした視点が抜け落ちがちです」（澤）

RPA導入によって、データ処理業務の大部分を自動化するのはそれほど難しくない。しかしERPシステムでは、残り数％の処理できないデータが大きな問題を引き起こす可能性もある。あらゆる状況においてシステムが問題なく動作するかを確認しなくてはならないのだ。

これは、言うは易く、行うは難しい。そもそも、SAP ERPには多様な企業のシステムがつながっている。つまり、RPAで処理したデータが、SAP ERPのシステムだけでなく、SAP ERPにつながるすべてのシステムにおいて問題なく動作するかを検証しなくてはならないのだ。そこでは、さまざまなシステムを構築し、多くのパッケージを扱ってきた、システムインテグレータの知見や経験が活きることになる。

RPAは、少ない範囲で導入して部署の個別最適を図ることもできれば、事業部あるいは全社単位で導入して全体最適を図ることもできる。あるいは、最初は小さく始めて、徐々に適用範囲を広げることも可能だ。

導入のアプローチはさまざまだが、人手不足が進み、働き方改革が叫ばれる日本において、今後、業務自動化の流れがさらに強まることは間違いないだろう。まずは、自社のSAP ERPにRPA導入の可能性はないかを検討してみてはどうだろう。