ハイパーオートメーション

今回はAlmaLinuxにSAP NetWeaver AS ABAPをインストールする手順の紹介が主です。
SAP自動化については次回から詳しく述べていきます。

SAPとその自動化ツール

自動化を考える上で、その対象としてERPを操作することが多いです。
ERPは「Enterprise Resource Planning」の略で、組織が多様化したビジネスプロセスを統合できるように「統合プラットフォーム」を提供するアプリケーションです。
そのERPのシェアで一番高いのはドイツSAP SE社のERPである「SAP ECC | SAPS/4 HANA」です。
SAPは「Systems, Applications, and Products」の略で、グローバル市場で最も主要なERPビジネスアプリケーションとして知られており、各RPAベンダーもSAP向けに個別の機能を提供しています。

https://www.uipath.com/ja/solution/sap-gui
https://www.blueprism.com/japan/products/blue-prism-accelerators-for-use-with-sap-erp/

実はSAP社自体もRPAのような自動化ツール「SAP Process Automation」を持っており、自動化のツール選択で悩むところです。
https://www.sap.com/japan/products/process-automation.html

ではハイパーオートメーションの観点ではどのツールを使うのがよいかなどを述べていきたいと思いますが、まずはSAP検証環境を準備したいと思います。

SAP NetWeaver AS ABAP Developer Edition 7.52 SP04 on AlmaLinux 8

SAP NetWeaver Application Serverをインストールします。
SAP NetWeaver Application Serverは主な目的としてはSAPで使われている「ABAP」という言語の開発環境のサーバー側として使われることが多いです。

また、今回はOSは「AlmaLinux 8」への導入となります。
CentOS 8は、2021年12月31日でサポートが終了しており、RHEL 9のリビルドとしてのCentOS 9をリリースしないことがアナウンスされているため、RHELのダウンストリーム(Downstream)であるAlmaLinuxが今後増えていくと考えているためです。
あくまで検証目的なので、ちょっと実験的に環境構築してみたいと思います。

サーバーインストール準備

AWSのEC2でインスタンスを起動する

今回はAWS環境にて構築したいと思います。まずはAlmaLinux OS 8のイメージを使ってインスタンスを作成します。

必要なハードウェア要件は以下のとおりです。

• x86_64 Processor based hardware
• At least 4 GB RAM plus about 8 GB swap space
• About 100 GB free disk space for server installation (インストール完了段階で約50GBの使用量になります）

ホスト名を変更する

$ sudo hostnamectl set-hostname primesap
$ sudo vi /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
172.31.33.73 primesap

SELinuxを非強制にする

$ sudo vi /etc/selinux/config
#SELINUX=enforcing
SELINUX=permissive
$ sudo /sbin/reboot

必要なパッケージを導入する

$ sudo dnf -y install wget csh libnsl libaio
$ wget https://forensics.cert.org/centos/cert/8/x86_64/unrar-5.4.0-1.el8.x86_64.rpm
$ sudo rpm -ivh unrar-5.4.0-1.el8.x86_64.rpm 

インストール資材を転送する

SCP/SFTPなどで圧縮・分割されているインストール資材をサーバーに転送します。

$ ls -al
total 14248664
drwxrwxr-x. 3 ec2-user ec2-user       4096 May 31 01:50 .
drwx------. 4 ec2-user ec2-user        152 May 30 14:32 ..
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 30 14:59 TD752SP04part01.rar
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 30 15:12 TD752SP04part02.rar
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 30 16:04 TD752SP04part03.rar
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 30 15:26 TD752SP04part04.rar
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 30 15:39 TD752SP04part05.rar
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 30 15:52 TD752SP04part06.rar
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 31 01:11 TD752SP04part07.rar
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 31 01:24 TD752SP04part08.rar
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 31 01:38 TD752SP04part09.rar
-rw-rw-r--. 1 ec2-user ec2-user 1450000000 May 31 01:50 TD752SP04part10.rar
-rw-rw-r--. 1 ec2-user ec2-user   90622541 May 31 01:51 TD752SP04part11.rar

転送が完了したらunrarコマンドで展開します。

$ unrar x '*.rar'

UNRAR 5.40 freeware      Copyright (c) 1993-2016 Alexander Roshal


Extracting from TD752SP04part01.rar

Extracting  readme.html                                               OK 
Creating    server                                                    OK
Creating    server/TAR                                                OK
Creating    server/TAR/x86_64                                         OK
(略)
Extracting  client/JavaGUI/PlatinManual750_5-80002496.ZIP             OK 
Extracting  client/JavaGUI/PlatinGUI750_5-80002496.JAR                OK 
All OK

インストーラーのシェルのパーミッションを変更します。

$ chmod 755 install.sh 

SYBASEライセンスファイルを更新する

実は初期インストール資材に入っているSYBASEライセンスファイルは有効期限が切れているため、新しいライセンスファイルが追加でアップされています。

これをダウンロードして展開し、所定のフォルダ（server/TAR/x86_64）に配置することで、インストール時に自動的にライセンスファイルが置き換えられます。

$ ls
client  install.sh   SAP_COMMUNITY_DEVELOPER_License  TD752SP04part01.rar  TD752SP04part03.rar  TD752SP04part05.rar  TD752SP04part07.rar  TD752SP04part09.rar  TD752SP04part11.rar
img     readme.html  server                           TD752SP04part02.rar  TD752SP04part04.rar  TD752SP04part06.rar  TD752SP04part08.rar  TD752SP04part10.rar

$ unrar x License.rar 

UNRAR 5.40 freeware      Copyright (c) 1993-2016 Alexander Roshal


Extracting from License.rar

Creating    License                                                   OK
Extracting  License/info.txt                                          OK 
Creating    License/SYBASE_ASE_TestDrive                              OK
Extracting  License/SYBASE_ASE_TestDrive/SYBASE_ASE_TestDrive.lic     OK 
All OK

$ cp License/SYBASE_ASE_TestDrive/SYBASE_ASE_TestDrive.lic /home/ec2-user/sapimage/server/TAR/x86_64

サーバーインストール実行

インストールを実行する

最初に「almalinuxはテストされていません」と出ますが、今回はそのままyesでインストールを進めます。

$ sudo ./install.sh 
Hostname primesap assumed to be SAP compliant
Your distribution 'almalinux' was not tested. Do you want to continue? y
You have chosen to continue with install in non tested distribution
and we encourage you to share your experience with the SAP community
Error: /sbin/uuidd: not executable file
Do you want to continue regardless of the missing dependencies? yes/no: y
 
#============================================ 
# 
# Installing SAP Developer Edition  
# 
#============================================ 
 
 
You are about to install the SAP Developer Edition
Please make sure you have carefully read and understood the documentation
 
 
To install this TestDrive you have to accept 

the SAP COMMUNITY DEVELOPER License (DEV).

SAP DEVELOPER CENTER
MASTER SOFTWARE DEVELOPER LICENSE AGREEMENT

Please scroll down and read the following SAP Developer Center Software Developer License Agre
ement (?Developer Agreement?) carefully. By clicking ?I Accept? or by attempting to access or 
use the SAP Software, You agree that this Developer Agreement forms a legally binding agreemen
t between You (?You? or ?Your?) and SAP AG, for and on behalf of itself and its subsidiaries a
nd affiliates (as defined in Section 15 of the German Stock Corporation Act) (?SAP?) and You a
gree to be bound by all of the terms and conditions stated in this Developer Agreement. If You
 are trying to access or download the SAP Software on behalf of Your employer or as a consulta
nt or agent of a third party (either "Your Company"), You represent and warrant that You have 
the authority to act on behalf of and bind Your Company to the terms of this Developer Agreeme
nt and everywhere in this Developer Agreement that refers to ?You? or ?Your? shall also includ
e Your Company. If You do not agree to these terms, do not click "I Accept", and do not access
 or use the SAP Software.
 
Do you agree to the above license terms? yes/no:y
 
 
Now we need the passwords for the OS users.
Please enter a password which will be used
for all operating system users.
 
Please enter a password:(任意のパスワード)
Please re-enter password for verification:(任意のパスワード)
 
 
Now we begin with the installation.
Be patient, this will take a while ... 
 

extracting data archives...
extracting /home/ec2-user/sapimage/server/TAR/x86_64/dbdata.tgz-*
sybase/NPL/sapdata_1/
(略)
Removed directory /root/.sapinst/primesap/1408.

Configure profiles for 4GB physical memory
Profile /sapmnt/NPL/profile/NPL_D00_primesap: changing PHYS_MEMSIZE from 1536 to 2048
Profile /sapmnt/NPL/profile/NPL_D00_primesap: changing abap/shared_objects_size_MB from 200 to 386
Configuring strong TLS according to SAP Note 510007
Profile /sapmnt/NPL/profile/DEFAULT.PFL: adding ssl/ciphersuites = 135:PFS:HIGH::EC_P256:EC_HIGH
Profile /sapmnt/NPL/profile/DEFAULT.PFL: adding ssl/client_ciphersuites = 150:PFS:HIGH::EC_P256:EC_HIGH
Checking syb Database
Database is running
-------------------------------------------
Starting Startup Agent sapstartsrv
OK
Instance Service on host primesap started
-------------------------------------------
starting SAP Instance ASCS01
Startup-Log is written to /home/npladm/startsap_ASCS01.log
-------------------------------------------
/usr/sap/NPL/ASCS01/exe/sapcontrol -prot NI_HTTP -nr 01 -function Start
Instance on host primesap started
Starting Startup Agent sapstartsrv
OK
Instance Service on host primesap started
-------------------------------------------
starting SAP Instance D00
Startup-Log is written to /home/npladm/startsap_D00.log
-------------------------------------------
/usr/sap/NPL/D00/exe/sapcontrol -prot NI_HTTP -nr 00 -function Start
Instance on host primesap started
Installation of NPL successful

おおよそ20分程度でインストールが完了します。

停止確認を行う

正常停止できるか確認する。SAPサービスの起動停止はインストール時に作成されるnpladmユーザーを利用して実施します。

$ sudo su - npladm
Last login: Tue May 31 15:11:40 UTC 2022 on pts/0
primesap:npladm 2> stopsap all
Checking syb Database
Database is running
-------------------------------------------
stopping the SAP instance D00
Shutdown-Log is written to /home/npladm/stopsap_D00.log
-------------------------------------------
/usr/sap/NPL/D00/exe/sapcontrol -prot NI_HTTP -nr 00 -function Stop
Instance on host primesap stopped
Waiting for cleanup of resources
..........
stopping the SAP instance ASCS01
Shutdown-Log is written to /home/npladm/stopsap_ASCS01.log
-------------------------------------------
/usr/sap/NPL/ASCS01/exe/sapcontrol -prot NI_HTTP -nr 01 -function Stop
Instance on host primesap stopped
Waiting for cleanup of resources
..
stopping database NPL ...
stop database completed successfully
Checking syb Database
Database is not available via R3trans
-------------------------------------------
primesap:npladm 3> exit
logout

起動確認をする

一度サーバーを再起動させます。

$ sudo /sbin/reboot

npladmユーザーになり、「startsap all」でSAPが正常起動するか確認します。

$ sudo su - npladm
Last login: Tue May 31 15:17:05 UTC 2022 on pts/0
primesap:npladm 4> startsap all
Checking syb Database
Database is not available via R3trans
-------------------------------------------
starting database NPL ...
Log file: /sybase/NPL/startdb.log
parse level 0: identified message 'Database 'master' is now online.'
parse level 1: identified message 'Database 'tempdb' is now online.'
parse level 2: identified message 'Database 'sybsystemprocs' is now online.'
parse level 3: identified message 'Recovery complete.'
Recovery Complete
startdb completed successfully
Starting Startup Agent sapstartsrv
OK
Instance Service on host primesap started
-------------------------------------------
starting SAP Instance ASCS01
Startup-Log is written to /home/npladm/startsap_ASCS01.log
-------------------------------------------
/usr/sap/NPL/ASCS01/exe/sapcontrol -prot NI_HTTP -nr 01 -function Start
Instance on host primesap started
Starting Startup Agent sapstartsrv
OK
Instance Service on host primesap started
-------------------------------------------
starting SAP Instance D00
Startup-Log is written to /home/npladm/startsap_D00.log
-------------------------------------------
/usr/sap/NPL/D00/exe/sapcontrol -prot NI_HTTP -nr 00 -function Start
Instance on host primesap started

自動生成されるユーザー一覧

インストール時に以下のSAPユーザーが作成されます（OSユーザーではありません）。

クライアントインストール

インストール資材の「50144807_6\BD_NW_7.0_Presentation_7.50_Comp.2\PRES1\GUI\WINDOWS\Win32」にあるSAPGUIインストーラー「SetupAll.exe」を実行します。

起動するとインストールオプションの選択画面になるので、今回は「SAP GUI for Windows 7.50 (Compilation 2)」を選択します。

インストール先フォルダを選択します（デフォルトで問題ありません）。

インストールが完了するまで待ちます。（約２分程度かかります）

SAPサーバーについて名前解決ができるようにhostsファイルに追記します。

スタートメニューから「SAP Logon」を選択します。

初期は何も接続情報がないため「新規アイテム」を選択します。

そのまま「次画面」を選択します。

「アプリケーションサーバ」「インスタンス番号」「システムID」を入力し「次画面」を選択します。

作成したアイテムを選択します。

インストール時に自動作成されたSAPユーザーを利用してログインを実行します。

正常にMenu画面が表示されたら、接続完了です。

次回に向けて

無事、AlmaLinux8環境にSAP NetWeaver AS ABAPをインストールすることができました。では、次回はこの環境を利用して、SAPの自動化を実際にやってみたいと思います。

RPAベンダーの言うハイパーオートメーションとは

RPAベンダーのハイパーオートメーションは基本的に以下フローに集約されます。

これはあくまで現行フロー・システムをそのままRPA化することに主眼が置かれています。
一部、ユーザーとのコラボレーションツール（UiPathならAction Center、Blue PrismならInteract）が提供されていますが、基本となるフローはそのままです。

DXを目指してのRPA・ハイパーオートメーションの導入であれば、まずは業務上ボトルネックになっているシステムに着眼し、クラウド化などの手法で更新していく必要があります。
まあ、確かにボトルネックになっているシステムを直接操作しなくてよくなるのはRPAのメリットではありますが、それはただ作業を楽にするだけであり、企業価値を高めて、継続性のある会社にするという観点から言えば、効果は低いと思われます。

RPAベンダーは、「DXしましょう、ハイパーオートメーションしましょう」とは言いますが、「システムを更新しましょう」とは言わないです。
これはシステムを更新すると、その新システムの中の機能で自動化が進んだり、APIが利用できることなどによりiPaaS（複数のクラウド環境上に分散している業務システムを統合するためのクラウドサービス）などで自動化ができたりするので、RPAを導入する必要がなくなったりします。
ライセンス販売が主たる収益源になっているRPAベンダーからすれば、新規導入やアップセルこそ顧客に求めているアクションであり、システムの更新ではないためです。

誤解しないでいただきたいのは、RPAを否定している訳ではありません。RPAは自動化の観点では大きな効果を生み出します。ただ、もっと高い視点で効率化しましょうということです。

Gartnerがトップトレンドとしているように、ハイパーオートメーションの時代ではありますが、RPAベンダーの言うハイパーオートメーション製品群を使う必要はなく、各会社の状況にあったハイパーオートメーションの取り組みをしていくのが重要と考えます。

ハイパーオートメーションの前準備

では、ハイパーオートメーションに必要な前準備について整理していきたいと思います。

マスタの整理

データをうまく活用するためには、そのデータ各項目の意味が統一されている必要があります。
同じ商品でも複数の商品コードがあったり（よく同一商品でも取引先によってコードを変えている企業がありますが）、あるコードを軸に売上推移などを見える化しても正しく表現できない場合があります。

このように、マスタを整理することは非常に大事ですが、非常に面倒・大変です。バラバラなものを整理していくのは非常に根気のいる作業で、またすぐに成果に結びつかないので誰もやりたがりません。

ニュースでデジタル庁がデータ整備を中断したとのことですが、まさにその大変さを表しているニュースかと思います。

デジタル庁の「事業所」データ整備事業が中断、目玉政策が実現困難と判明した経緯
https://xtech.nikkei.com/atcl/nxt/column/18/01157/042800060/

よくERP更新プロジェクトが立ち上がると、マスタ整備チームも併せて立ち上げられるパターンが多いですが、マスタ整備は常に整理しつづけることが重要だと考えています。
さらにいえば、取引先や業界の中でのマスタができあがるとさらに効果が高くなるため、各業界でも日々取り組んでいただきたい内容です。

クラウド化

クラウド化の流れはもう止められない流れと言えます。
ハイパーオートメーションの観点からもサーバー・サービスをつなぎやすい位置にあることは非常に大事です。
これまでは企業システムといえば、契約したデータセンター内に物理サーバーを設置してOSやミドルウェアをインストールして、業務アプリケーションをセットアップするという流れで、外部との接続を増やす場合もかなりのネットワーク設定が必要でした。
AWSやAzureなどのクラウドサービスを利用すると、簡単に他のシステムとの接続設定ができたり、また追加で必要となるサーバーも簡易に増設することが可能です。
ハイパーオートメーションを推進していくと、データの流れが随時増えていくので、臨機応変に構成を変えられるクラウドサービスを利用することが求められます。

SaaS利用とポストモダンERP化

「ポストモダンERP」という考え方があります。
上記「クラウド化」はコンピューティングリソースの観点でしたが、こちらではクラウド上で展開されている各SaaSを組み合わせて利用していくというものです。
日々ニュースを見ていると、SaaSで各サービスがどんどん機能追加をしたりなどより良いものになっていくのが分かるかと思います。
それらを利用しない手はありません。

今までは１つのERPの中で業務を完結させようとするあまり、巨大なERPができてしまい、機能追加やメンテナンスがしにくいERPの反省として提唱されてきました。
また、システムが分断されていることは悪いことのように言われていましたが、それは繋がらないシステムは悪いですが、分散してもAPIなどで繋がり成長するシステムは良いものです。

AI活用の流れ

ハイパーオートメーションのコア技術の１つがAI活用です。
AIにより人が判断していたことを代行できたり、さらに人でも判断できないことが判断できるようになったり（どこの特徴量を見ているのかわかりませんが）、自動化の流れを大きくしたのがこのＡＩという技術です。
総務省が公表している「令和元年版情報通信白書」によると、日本のAI導入率はわずか「39％」です。これに対し、海外の導入率は中国85％、アメリカ51％、ドイツ49％、フランス49％、スイス46％、オーストリア42％です。（直近PwCの調査では、だいぶん巻き返していると聞いています。）

AIやAIができること自体の認識はだいぶん広まってきましたが、じゃあそれを自社業務でどのように利用できるかと考える企業はまだまだ少ないのが現状です。
無理に導入する必要はありませんが、しっかり自社業務×ＡＩを考え、新しい展開を検討していく流れや意識改革が必要となります。

紙業務の廃止とデジタル化

グローバルな数字ではありますが、請求書の量は現在約5,500億枚であり、2035年までに4倍になると予想されています。
新型コロナウィルス対策での蔓延防止のため、在宅勤務が推奨され、紙業務についても大きくデジタル化が進みましたが、まだまだ紙業務は残ったままです。
紙業務のやっかいなところは、定型フォーマットでないため、データ構造（合計金額の印刷場所など）がそれぞれ異なり、再利用しにくいという点です。
AI-OCRによりある程度自動化できますが、業務フローの中に物理的紙があることで、ハイパーオートメーションの目指す自動化のボトルネックになってしまいます。

まずはEDIなどでデータでやりとりをする仕組みをつくることが大事です。
このあたりはPeppolという仕組みや、大日本印刷のEDI事例を含めて別途紹介します。

AS400などレガシーシステムのWeb化

ブラウザベースのアプリケーションであれば、RPAやブラウザ自動化の仕組みで自動化できます。
またWindowsアプリケーションもRPAで自動化できます。（認識できる項目に限り）
しかし、1970年ごろから構築されてきたIBM i(AS/400)などのシステムはCUI（Charactor User Interface）であり、項目の入力やデータ抽出がしにくいという問題があります。
各RPA製品にも補助機能はありますが、あくまで補助機能であり、自動化しやすいかといえばそうではありません。

まあ、本来であれば廃止しましょうということですが、IBM i(AS/400)で作られているシステムは基幹系システムである場合が多く、簡単に移行できないという状況もあります。
そのため、最近でCUI画面をGUI化（ブラウザ操作可）とするようなソリューションも多くありますので、まずは自動化しやすいInterfaceにしていくことが必要です。

https://www.officequattro.com/jpn/software/contents/autoweb/index.html

ハイパーオートメーションを進めていくという考え

結局は、ツールは何を使って、どのようにハイパーオートメーションを進めていくのが良いかという話では、「できることから１つずつ積み立てて、新しいことにもチャレンジしていく」と言う他ありません。
ただ、これまで述べてきたように「方向性」は見えていると思うので、そこに向けて１歩１歩手を打っていきましょう。継続的に、持続的に。

でなければ、前回の最後に「2000年以降、フォーチュン500社の52％が倒産、買収、もしくは消滅しました。」とお伝えしたように、時代に合わせて新しいことを取り組んでいかないと企業の存続が脅かされてしまいます。
ハイパーオートメーションは企業存続に高く寄与すると考えられており、危機意識をもって、取り組んでいく必要があります。

次回は紙業務に注目して、AI-OCRやハイパーオートメーションでの取り組みについて述べていきたいと思います。

弊社ではハイパーオートメーション導入サービスを展開しております。

そのパイパーオートメーションや周辺技術についてコラム形式で紹介していきたいと思います。

ハイパーオートメーションの市場規模は600億ドル

2021年11月17日にGartnerの「2022年の戦略的テクノロジのトップ・トレンド」が発表になりました。
https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20211117
その中で今回のテーマである「ハイパーオートメーション」があります。

Increased focuses on growth, digitalization and operational excellence have highlighted a need for better, more widespread automation.Hyperautomation is a business-driven approach to identify, vet and automate as many business and IT processes as possible. It requires the orchestrated use of multiple technologies tools and platforms, including RPA, low-code platforms and process mining tools.

企業の成長、デジタル化、競争上優位性（オペレーショナル・エクセレンス）への注目が高まる中、より優れた、より広範な自動化の必要性が浮き彫りになっています。
ハイパーオートメーションは、ビジネス主導のアプローチで、可能な限り多くのビジネスおよびITプロセスを特定し、検証し、自動化するものです。
ハイパーオートメーションには、RPA、ローコードプラットフォーム、プロセスマイニングツールなど、複数のテクノロジーやプラットフォームを組織的に使用することが必要です。

By 2024, diffuse hyperautomation spending will drive up the total cost of ownership 40-fold, making adaptive governance a differentiating factor in corporate performance

2024年までに、ハイパーオートメーションの普及により、総所有コストが40倍になり、アダプティブガバナンスが企業業績の差別化要因になる

A global oil and gas company has 14 concurrent hyperautomation initiatives.These initiatives include targeted task automation, industrializing over 90 different areas including intelligent document processing, and automation of geoscience and offshore oil drilling operations. Decisions on what to automate are made strategically and are premised on targeted business outcomes for either quality, time to market, business agility or innovation for new business models.

あるグローバルな石油・ガス会社では、14のハイパーオートメーションの取り組みが同時に進行しています。これらの取り組みには、対象タスクの自動化、インテリジェントな文書処理など90以上の異なるエリアの産業化、地質学と海上石油掘削作業の自動化などです。
何を自動化するかは戦略的に決定され、品質、市場投入までの時間、ビジネスの俊敏性、新しいビジネスモデルの革新など、目標とするビジネス成果を前提に決定されます。

また、ガートナーは2021年4月28のレポートで、ハイパーオートメーションの市場規模は600億ドルになると予想しています。

Gartner, Press Release, April 28, 2021, “ Gartner Forecasts Worldwide Hyperautomation-Enabling Software Market to Reach Nearly $600 Billion by 2022”

https://www.gartner.com/en/newsroom/press-releases/2021-04-28-gartner-forecasts-worldwide-hyperautomation-enabling-software-market-to-reach-nearly-600-billion-by-2022

産業革命により、人間の作業を機械に置き換えて自動化（オートメーション）させる時代になり、また情報革命により、デジタルでのやりとり自体も自動化させる時代となりました。しかもデジタルでの自動化は非常に短い時間軸で大きく変化し、時代を大きく変えていっています。AIの発展もあり、人間の作業の【置き換え】ではなく、人間以上のことができる【高度化】も実現され、新しい時代に私たちは生きています。

逆の言い方をすると、私たちは自動化しなければ時代に取り残されていくという時代でもあります。RPAなどの複数のテクノロジーやプラットフォームを積極的に使っていく必要があります。

各RPAツールベンダーも、この流れを受けてハイパーオートメーション関連の製品をリリースしてきました。

RPAベンダーのハイパーオートメーションの取り組み

UiPath

ハイパーオートメーションとは？ RPAから広がる自動化の未来
https://www.uipath.com/ja/blog/corporate/are-you-ready-for-hyperautomation

UiPath社は、コア製品である「Studio」「Orchestrator」「Robot」を中心にしていますが、手広く製品を増やしていって、UiPath製品群で自動化に関わる製品がそろう形にしています。とくにSaaSで提供されている「Automation Cloud」を中心に製品連携の仕組みはよく出来ていると思います。

Automation Anywhere

複数のテクノロジーを活用したエンドツーエンドの自動化それが、ハイパーオートメーション
https://www.automationanywhere.com/jp/rpa/hyperautomation

Automation Anywhere社は文章などの非構造化データの抽出を行う「IQ Bot」とRPA「RPA Workspace」に非常に力を入れており、Everest Groupが出しているIntelligent Document Processing (IDP)とう文章処理のカテゴリで常にリーダー的位置づけに居ます。

Blue Prism

追加コストなしでここまでできる！2022年Blue Prism製品ポートフォリオ紹介
https://www.blueprism.com/japan/resources/white-papers/20220126-webinar/

Blue Prism社も上記２社に負けず劣らずの各製品群を提供していっています。

このようにグローバルな各RPAベンダーがハイパーオートメーションに非常に注力していることが分かります。
Gartnerの発表もこの流れ・ハイパーオートメーションの成長を受けての発表であり、実際グローバルに成長していくものと思われます。

しかし、Gartnerがトップ・トレンドとして注目しているハイパーオートメーションですが、日本国内ではあまり活発ではありません。

日本国内で注目されないハイパーオートメーション

Googleのニュース検索で「ハイパーオートメーション 事例」を検索しても、実際の事例はまだ非常に少ないのが分かります。その理由としては、以下があると私は考えています。

部分最適化のアプローチ（全体最適化への抵抗）

現在の業務プロセスを踏襲して、部分的にITツール（RPAなど）を導入するアプローチであり、業務フロー全体を効率化・自動化するという方針になっていないためです。
たとえば、顧客とのやりとりを今までFAXでやりとりをしていたのを、RPA＋OCRで自動化するのも良いですが、そもそもFAXでなく電子データでやりとりしたいと思ったことは多いかと思います。
フロー全体の効率化が有効だと判断しても、顧客および部課外との調整が正直めんどくさく、また失敗できないため、尻込みしてしまいます。
実際、顧客に聞いてみるとFAX送信のかかる費用や、顧客側もFAX送信が顧客側の自動化のネックになっていたりするなど、顧客側もFAXを廃止したいという思いの場合があります。

RPA疲れ・失敗

RPAはGartnerのパイプサイクルで幻滅期を超えて、普及期に入ったといわれています。
しかし、一度RPA導入がうまくいかなかった企業がハイパーオートメーションに取り組むかといえば取り組まないと思います。

RPAの失敗はいろいろと考えられます。

• 業務プロセスが複雑
• 安定しない（一部ツール自体の問題もあります）
• 環境の変化に追随して修正する必要がある
• 長期的な計画が無く、管理が明確になっていない

これらから、実際何がダメで失敗したのか反省し、次のチャレンジに向かう必要がありますが、そのままフェードアウトして改善へのアプローチをしなくなる傾向があります。

プロセスマイニングツール（タスクマイニングツール）が使えない環境

プロセスマイニングはINPUT情報として、業務システムの操作ログを利用します。
https://www.sbbit.jp/article/cont1/39189
そもそも、操作ログが取得できないシステムであったり、また取得するためのシステム設定値の変更が必要だったり、ログを取り出すこと自体でさえ難しい状況があります。
特に日本の場合は、業務システムがデスクトップ型アプリケーションが多く、操作ログが取れないシステムがまだまだ多いという事情もあります。
また、改善チームと情報システム部門の関係性が遠い場合、操作ログの取得を依頼すること自体が難しい場合があります。

プロセスマイニングツールの価格

プロセスマイニングのツールはライセンス料込みのPoCで大よそ300万円～500万円が目安のようです。
https://it.impress.co.jp/articles/-/18937
もちろん本格導入しようとした場合はそれ以上の金額がかかってきます。

真の自動化に向けてできること

企業価値を高めて、継続性のある会社にするためには、デジタル技術の導入に前向きである必要があります。

実際、2000年以降、フォーチュン500社の52％が倒産、買収、もしくは消滅しました。20年も経たないうちに、2000年にフォーチュン500リストに載っていたブランドの半分以上が存在しなくなりました。
また、50年前、フォーチュン500ブランドの平均余命は75年でした。現在は15未満です。今後60年間で、推定9,000社がフォーチュン500リストに出入りする可能性があると予測されています。
グローバルで企業が生き残りをかけて、デジタル化やDXを推進している中で、日本企業だけ変革しないという選択はありえません。

次回以降はどのようにハイパーオートメーションを導入していけばいいか考えを提示していきたいと思います。

ハイパーオートメーションを阻害する要因の１つ「紙業務」を、さらに「請求書」にフォーカスを当てて述べていきたいと思います。
今回はその前半部分で、世界および日本の状況を確認していきたいと思います。

各社のレポートから現状を知る

ここでは、請求書にかかわる３つのレポートからキーポイントを取り上げてみたいと思います。

Billentisレポート(2019年5月)

まず、新型コロナウイルスによるパンデミック前の2019年5月に出されたこのレポートでは、企業とそのパートナー企業は、年間5,500億を超える請求書を交換しており、その数は2035年までに4倍になると予測しています。また、2019年現在、ペーパーレスでやり取りされている請求書は約550億枚（約10％）に過ぎないようです。

また、国別での電子請求書の普及度・市場の成熟度は以下のようになっており、日本は「発展途上」と位置づけられています。
日本は紙の請求書でかつ押印することが一般的であるためですが、インボイス制度が導入されることで改善すると考えています。

成熟度は各国の事情がありますが、面白いのはラテンアメリカが成熟度が高いことが分かります。
たとえば、アルゼンチン税務当局（AFIP）は、2019年春に電子請求書発行の義務化体制を経済の全分野に拡大しました。
ブラジルでは、ごく一部の例外を除き、すべての企業に電子請求が義務付けられています。
https://edicomgroup.com/electronic-invoicing/brazil

イメージ的には「発展途上国は電子化が遅れている」という感覚がありますが、比較してみると日本のほうが発展途上のカテゴリになっており、政府のやる気がデジタル化に大きく寄与する良い例だと思います。

Ardent Partnersレポート(2021年2月)

Ardent Partners AP Metrics that Matter in 2021
http://ardentpartners.com/2021/02/announcing-the-ap-metrics-that-matter-in-2021-ebook/

債務担当者が請求書データの入力、間違いの修正、請求書と支払いのステータスに関する電話や電子メールへの応答など、自動化できるタスクに4分の1近くを費やしています。そのため、業務時間が平均１日あたり２時間追加になっているようです。

逆に、高度に自動化された経理部門はフルタイム従業員１人あたり８倍の請求書が処理できるようになります。さらに自動化により、スタッフの作業負荷だけでなく、エラーや不正のリスクも軽減されることがわかりました。

債務部門が受け取る請求書の大半が電子化されるようになりました。2021年、平均的な債務組織は現在、請求書の51%を電子的に受け取っています。

請求書1枚を処理するための平均コスト（人件費、間接費、技術費などを含む）は、過去1年間に8％微増して$10.89となりました。この増加は残念なことですが、ほとんどの組織にはまだ改善の余地があることは明らかです。

過去12ヶ月間の全請求書の約4分の1(24.6%)に、承認されるために債務担当者が何らかの措置や追加作業を行う必要がある例外のフラグが立っていた。例外の割合が高いことは重大な問題であり、多くの債務部門が企業においてより戦略的な地位を獲得することを阻んでいます。

Beanworksレポート

State of Accounts Payable Today
https://www.beanworks.com/resources/research/state-of-accounts-payable-today/

債務機能を自動化すると、企業の収益を平均して年間35,000ドルも改善できます。

会計プロセスを自動化した債務専門家のうち、74％が支払い遅延が少ないと述べ、67％が自動化以降支払い遅延がないと報告しました。
10人に8人が承認期間の短縮を報告し、79％が自動化されたプラットフォームが不正を効果的に捕らえて防止したと述べています。
回答者の約81％が、自動化によって監査が容易になったと述べ、71％が支払エラーが少ないと報告しました。
自動化により人件費が89％削減され、10人に7人が、債務の自動化以降、財務部門と他の部門がより生産的に協力したと述べています。
さらに、77％が、自動化によってベンダーとの関係が改善されたと報告しています。

日本の商慣習が自動化を妨げる

話題を日本に向けてみましょう。実は日本独自の商慣習が自動化の大きな妨げになっています。その理由は以下の３つです。

入金と債権が１対１でない

日本では「月末締め翌月（翌々月）末払い」という月末に複数請求書を合算して翌月（翌々月）に支払う金額を確定させる商習慣があり、実は国際的には一般的ではありません。国際的には都度請求が一般的で、支払期日も月末とかではなく、請求書の日付＋〇〇日以内とかになります（画像では15日以内）。
日本の商習慣で合算されて入金された場合、どの請求書の合算なのかの入金対債権で1対多のマッチング（消込）が必要となります。
さらに言えば、入金が複数回であれば、多対多の消込となり、どの項目をキーに明細を括り、どんなルールに基づいて対象とぶつけるか、設定が複雑になりがちです。
国際的には１対１であり、また請求書(INVOICE)に発注書No(具体的にはPO(purchase order)No)が記載されているので、どの発注に対する請求なのか分かりやすくなっています。

振込手数料・消費税差額

日本の民法上は金融機関での振込手数料は本来振込人側で負担するとなっていますが、実際は振込人側が負担したくないため、入金額から振込手数料を差し引いた金額を入金するケースもあります。また。その振込手数料も固定ではなく、相手先の銀行や金額によって変わるため、金額だけでマッチングができず、問題をさらに複雑にします。さらに、消費税の計算方法で数円の差が出てしまうことも複雑にしている原因です。

親会社・子会社が一体になって入金してくる

ある取引において、子会社への請求に対してその親会社が入金してくる場合があり、また子会社がそのまま入金してくる場合もあり、問題をさらに複雑にしています。

これらの問題があり、日本における債権処理の難しさ、高度な文書処理 (Intelligent Document Processing /IDP)およびハイパーオートメーションの実現の難しさがあります。

参考URL
https://www.blackline.jp/blog/trend/matching.html

世界的な請求書相互交換プラットフォームの流れ

請求書を紙でやりとりするのではなく電子的にやりとりする仕組みを作ろうという流れが世界的に進んでいます。
今回はその中で大きな４つのグループを紹介したいと思います。

ConnectONCE(Open Network for Commerce Exchange)

https://connect-once.com/

ONCEは、グローバルトレードを推進するための共同フォーラムであるB2B eコマースに専念するマーケットプレイスオペレーター、そのサプライヤーと顧客、サービスプロバイダーなどを提供する唯一の組織です。

ONCEは、2000年の誕生以来、メンバーが共通の問題を特定し、オンライントレードの加速と成長を可能にする標準ソリューションを作成することに重点を置いており、市場の相互運用性、セキュリティ、ビジネスサービス、コンテンツ管理、ベストプラクティス、およびサプライヤの有効化を目指しています。

ONCEのビジョンは、電子取引ネットワーク、顧客、サプライヤー、サービス、テクノロジー企業の世界最大の同盟であり、取引パートナー間の電子商取引の採用を促進および加速するためのグローバルフォーラムを提供することです。ONCEの主な目標は、メンバーの製品とサービスに対する理解と採用を促進することです。

ONCEメンバーは、グローバルなB2B eコマースの成長に参加するだけでなく、毎日数十万の電子取引やビジネスサービスを促進することでそれを可能にします。

EESPA(European EInvoicing Service Providers Association)

https://eespa.eu/

EESPAは、ネットワーク、ビジネスアウトソーシング、金融、テクノロジー、およびEDIサービスを提供する組織から集められた、E-Invoicingサービスプロバイダーの大規模でダイナミックなコミュニティのヨーロッパレベルでの業界団体です。2011年に結成されたEESPAには、80人を超える正会員と準会員がいます。
EESPAは、そのメンバーシップのために多くのサービスを提供および開発しています。

・業界を代表し、公共政策の議論に参加する
・適切なヨーロッパのフォーラム内でのベストプラクティスの推奨
・相互運用性の促進と相互運用可能なエコシステムの構築
・電子請求書の幅広い採用とそのメリットの提唱とサポート

GS1

https://www.gs1.org/

GS1 は、複数の地域にまたがるサプライチェーンの効率と透明性を高めるため、国際規格を設計・策定する国際組織です。
GS1 の規格体系はサプライチェーン用規格として世界で最も広く採用されています。
具体的には「GS1 XML Standards」という各商取引における規格を定めており、その中にINVOICEの規格もあります。
日本にも「一般財団法人流通システム開発センター」が日本支部として活動しています。
https://www.gs1jp.org/

個人的には棚卸iOSアプリを作っていた時に、バーコード規格の１つとしてGS1を知り、今でも仕事でGS1の活動を追っていることが感慨深くもあります。
https://www.barcode.ne.jp/barcode/1215.html

OpenPEPPOL

https://peppol.org/

Peppolは、欧州委員会とコンソーシアムのメンバーによって資金提供された大規模なパイロットとして2008年に始まりました。
このプロジェクトの目標は、公的機関と民間部門の間の摩擦のない貿易を可能にすることであり、最終的には、健全な競争を促進しながら効率を高めることでした。
これらの目標を達成するために、Peppol Business Interoperability Specification（Peppol BIS）が開発され、eOrdersやeInvoicesなどの一般的な調達ドキュメントの交換が標準化されました。すべてがオープンで安全なネットワーク上で交換されます。

このPeppolというプラットフォームが実は最注目ポイントです。
2021年9月に設立されたデジタル庁は、発足されたその月（2021年9月）に「OpenPeppol」の正式メンバーとなり、わが国の管理局（Peppol Authority）としての活動を開始しており、「電子インボイス」とそのネットワークの実現は、デジタル庁の最重要施策となっております。
https://www.digital.go.jp/policies/electronic_invoice/

民間でも「EIPA｜電子インボイス推進協議会」という枠組みの中でPEPPOLの推進が行われています。
https://www.eipa.jp/

別の機会でより深堀しますが、日本全体のハイパーオートメーションのためにPeppolにすごい期待しております。

なお、今回は割愛しましたが、上記のほかにもOASIS, UN/CEFACT, CENなどの団体もあり、請求書ネットワーク化に対して多くの組織が取り組んでいます。

後半に向けて

今回は状況を確認ということで、世界的な潮流や日本の状況についてトピックレベルではありますが触れてみました。
ここからどうドキュメントのハイパーオートメーションを進めていくかは次回から述べていきたいと思います。
AI-OCRのトレンド、PEPPOLなどの具体的な接続の仕方、自動化の具体的なテクニックなど紹介していければと思います。

今回は紙の請求書をどのようにデジタル化・構造抽出するかについて確認していきたいと思います。
紙のデジタル化といえば、「OCR」ですので、今回はOCRと請求書について掘り下げていきます。

OCRとは

まずOCRとは何の略かというと
　Optical Character Recognition（日本語では「光学文字認識」）
の略です。活字、手書きテキストの画像を文字コード（デジタルデータ）に変換するソフトウェアや技術を指します。

OCRの歴史は意外にも古く1920年代に研究・開発され、1929年にはアメリカで数字とアルファベットを読み取るOCRがそれぞれ開発され特許が出願されています。
日本においては1960年代に郵便物の仕分けのために大量の人員が動員されており、これを解決すべく郵便番号制度の検討とOCRの研究がスタートしました。日本では住所で使われる「漢字」の読み取りが難しいため、郵便番号制度とOCR機器の開発を同時に進める必要がありました。そして1968年7月に郵便番号制度が導入され、同月に東芝が国産OCRを初めて製品化し、本格的にOCRの利用が始まりました。

世界初の郵便物自動処理装置(TR-3/4)
https://toshiba-mirai-kagakukan.jp/learn/history/ichigoki/1967postmatter/index_j.htm
TR-3/4の基本仕様

• 赤枠内に記入された自由手書き数字を認識
• 読取可能桁数3桁
• 処理速度20,000通/時

自由手書きでは、使用する筆記用具、字の大きさと位置、線の太さと濃度など千差万別で、30万字にも及ぶサンプルを全国から集め、解析シミュレーションをもとに改良を重ね、実用機TR-3型とTR-4型を製造した。

これら日本のOCRの歴史は「OCR-コンピュータ博物館」でまとまっていますので、ご参照ください。
https://museum.ipsj.or.jp/computer/ocr/index.html

このように、OCRはビジネスの領域でも利用されるようになり、現在ではパソコンだけでなくスマートフォンアプリなどでも気軽に利用できるようになっています。

個人的におすすめなのは「Microsoft Lens」です。認識精度も高く、画像処理も優秀なので何かLensと連携するサービスを作れないか考えているところです。

OCRの基本的技術

ここでOCRの基本的技術を確認しておきたいと思います。
この後にAIの導入でこのあたりの基本的技術がどう進化していったかを理解していただくためにも、まずは基本を確認したいと思います。

Step1.文字列領域切取（ユーザー指定）

まずはどこに文字列があるかユーザーが指定します。
サンプルでは(180,196)-(788,324)の座標に宛名が、(638,426)-(794,486)の座標に件名があると指定します。

実際には数字を指定する訳ではなく、OCRソフトの画面で指定しやすくなっています。また、この座標に正しく文字列が入っているように、画像の傾き補正などをする必要があります。

Step2.文字切取

文字列から文字を切り出します。
活字であれば文字と文字は重ならないので、長方形で切り出すことが可能です。

Step3.文字認識

文字がどの文字かOCRソフト内に持っている文字データベースと付け合わせして、一番類似度が高いものを選択します。

英数字だけであれば大文字小文字区別した場合でも62文字で文字数が少ないので比較しやすいです。

日本語はひらがな・カタカナだけでなく漢字も含まれ、たとえばカタカナは同じ形でも大文字小文字・全角半角があるので間違って認識してしまうパターンが多いですし、漢字はさらに常用漢字と人名用漢字の合わせて約3,000字程度あるので、どの文字が正確に判断するのかは非常に難しいです。

さらに、書体（フォント）でも文字の形が違うので、多くの書体で多くの文字をOCRソフト内に文字データベースとして持つ必要があります。

Step4.辞書マッチング

文字認識の段階で複数のパターンが考えられる場合は、OCRソフト内の辞書とマッチングさせます。
「ハイパー」（イが大文字）⇒辞書にあるので正しそう
「ハィパー」（イが小文字）⇒辞書にないので間違っていそう

これらを見ると、OCRの文字認識に何が大切か分かります。

1. 傾き補正など適切な前処理（画像処理）ができること
2. 多くのフォント・文字の文字データベースを持っていること
3. 多くの辞書を持っていること

例えば、PanasonicのAI-OCR対応ソフト「AI帳票OCR Ver.9（WisOCR）」の仕様を見てみると、対応している文字数などが分かります。
https://www.panasonic.com/jp/business/its/ocr_form/spec_1.html

AI-OCRとは

一般にAI-OCRと言われますが、技術的には３つの体系があります

Text Recognition AI（文字認識）

AI-OCRでよく言われる「手書き」文字に対応したものとなります。

手書き文字はOCRソフト内に持っている文字データベースではヒットしないため、文字判定が非常に難しいです。
綺麗な手書き文字であれば良いのですが、崩れていたり・傾いていたりなど人間であっても読みにくい文字もあります。
さらに、文字と文字が重なることがあり、きれいに文字単位で長方形で切れない場合もあります。

これらをAIの深層学習（ディープラーニング）を用いた画像認識システムにより文字データベースに無い文字でも文字認識することが可能となりました。

Context Recognition AI（文脈認識）

文章の意味が正しくなるように、AIが自動的に補正する技術です。
特に、「間違えやすいもの」を文脈から自動修復するところで機能します。

機能的には辞書マッチングで補正できる部分もありますが、それをもっと文脈を意識して修正してくれます。

Text Detection AI（文字領域検出）

基本技術「文字列領域切取」では画像内の座標を指定しなければいけないという話をしました。
しかしText Detection AIでは画像内の文字列と文字列の関係性から、取得したい文字列を取得することが可能です。

たとえば「請求日」を画像内から取得したい場合は、「請求日」という文字列のある右側の文字列を取得します。一般的に項目名の右側に値があるので、このルールで取得できます。

また、宛名は「御中」や「様」という左側（前側）にあるので、左側にある文字列を取得します。
さらに、その左側にある文字列に「株式会社」や「有限会社」という文字が含まれている場合は宛名の可能性がさらに高いです。

このようにすることで、座標を指定しなくても、取得したい項目名を指定すれば必要な文字列（値）を取得できるようになります。特に請求書であれば読み取りたい項目は限られているので、このルールを細かく設定すれば、請求書から取得したい内容は取得できます。
※実際に別途紹介するABBYY FlexiCaptureという製品では、このルールを非常に細かく設定できます。

ただ、ここまでの話でしたらAIでなくても実現できます。
世の中にはルールで表現できないパターンの請求書も多くあるため、各OCRサービスベンダーはAIによる機械学習にてこの認識精度を高めています。実は結構、枚数の多い公共系（電気・水道・ガス）の請求書がルール定義では難しいため（余計な文字が多すぎる！！）、AIが活躍しているところです。

例）NTT東日本
https://web116.jp/ryoukin/payment/form01.html

日々進化するOCR

AI-OCRは日々進化しており、たとえば最近のニュースでは凸版印刷が古文書などで利用されている「くずし文字」のOCRをサービス化しました。

「AI OCR」でくずし字を解読、開発に6年を費やした凸版印刷の狙い
https://xtech.nikkei.com/atcl/nxt/column/18/00001/05251/

特開2021-149737　くずし字認識システム、くずし字認識方法、データセットの作成方法、及びプログラム
https://www.j-platpat.inpit.go.jp/c1800/PU/JP-2021-149737/939D2F21E59AF35D4ADCECBEE290962909349DCD5E48156C842312E0ED50FA01/11/ja

前回のコラムでもふれたように「年間5,500億を超える請求書を交換しており、その数は2035年までに4倍になると予測されている」ので、当面まだ私たちは紙請求書と付き合う必要があります。
そのデジタル化のためにも、AI-OCRの進化にはこれからも期待したいと思います。

次回は、実際どのようなAI-OCRサービスがあって、各社のメリットや、そもそもハイパーオートメーションの観点からどのようにしていくべきか述べていきたいと思います。