S/4HANAへの移行が、2年後の5月の連休に決まった。移行の影響調査の報告書は、自社開発のプログラム約1,400本について、改修の要否を1本ずつ判定していた。 経理部長はその報告書を読み終えてから、経理部で業務改善を担当する社員に聞く。うちで動いているロボットは、この中に入っているのか。担当者は少し考えて、入っていないと思います、と答える。 経理部では5年前からRPAを使い、仕入先の登録、入金消込の前処理、経費明細の転記、月末の残高照会の出力を自動化してきた。稼働している本数は、担当者にもすぐには分からない。 分かっているのは、それぞれのロボットがSAPの画面を開き、決まった位置の項目に値を入れ、決まったボタンを押していることだけである。移行で画面が変われば、ロボットは止まる。
画面を操作する自動化は、画面が変わるたびに費用が戻ってくる
RPAが経理で広がった理由ははっきりしている。システムに手を入れずに、担当者の画面操作をそのまま置き換えられるからである。 改修の予算も、情報システム部の順番待ちも要らない。数週間で作れて、効果はすぐに出る。
その速さの代わりに、ロボットは画面の形に依存している。 項目の位置、ボタンの名前、画面が開く順番。どれかが変われば、ロボットは値を入れる場所を見失う。そして、ERPの画面は、思っているより頻繁に変わる。
一つ目は移行である。 S/4HANAへの移行では、先に挙げたように、マスタの登録の画面そのものが別のものに置き換わる。二つ目は版の更新である。 S/4HANAは、版の更新やサポートパッケージの適用のたびに、画面の項目や既定の値が変わりうる。クラウドの契約では、更新の時期を会社の都合だけでは決められない。三つ目は画面の切替えである。 承認や照会の画面をFioriに寄せれば、同じ業務でもブラウザの上の別の画面になる。承認の画面を受信箱のアプリに集めれば、承認の操作を代行していたロボットは、操作する画面そのものを失う。
画面が変わるたびに、ロボットは直すか作り直すことになる。 RPAの費用は作ったときに一度だけかかるのではなく、画面の変わる回数だけ戻ってくる。しかも、その費用が発生する時期は、ロボットの側では決められない。ERPの更新計画が決める。
経理の自動化を、三つの置き場所で選び直す
ロボットの本数が増えた会社で起きているのは、自動化の置き場所を選ばずに、最も手早い手段で埋めてきたことである。選び直すときの順番は、標準機能、APIやファイルでの連携、RPAである。
第一の置き場所は、ERPの標準機能である。 入金消込の前処理をロボットで行っている会社は、たいてい銀行の入金明細を画面で見て、得意先と請求書を探している。S/4HANAには、銀行の明細を取り込み、規則に沿って消込の候補を当てる機能がある。標準機能に置けば、画面が変わっても、SAPが版の更新の中で対応する。 消込の規則を整えないまま機能だけ入れても効果は出ないので、規則の見直しと一緒に行う（SAPと銀行の連携は、消込ルールを直さないまま自動化すると作業が増える）。
第二の置き場所は、APIやファイルでの連携である。 経費明細の転記のように、外部システムのデータをSAPに入れるロボットは、画面を通る必要がそもそもない。SAPは、取引先の登録（API_BUSINESS_PARTNER）や仕訳の登録などのAPIを、SAP Business Accelerator Hub（2023年にSAP API Business Hubから改称）で公開している。APIは画面ではなくデータの形で約束されているので、画面の変更では壊れにくい。 作るのに時間はかかるが、データの流れを設計する機会にもなる（SAPとサブシステムの数字が合わない原因、販売・購買・経費・給与の連携設計）。
第三の置き場所が、RPAである。 標準機能がなく、APIもなく、連携を作るほどの件数もない作業。あるいは、標準機能や連携が稼働するまでのつなぎ。RPAを使ってよいのは、この二つの場合に限る。
ロボットの台帳に、撤去の期限を書く
RPAを最後の置き場所にすると決めたら、既存のロボットをどう扱うか。すべてを一度に作り替える必要はない。 必要なのは、一本ずつ、いつまで使って、何に置き換えるかを決めることである。
台帳に載せる項目は多くない。ロボットの名前、動かしている業務と決算の工程、触っているSAPのトランザクション、ロボットが使うユーザーID、入力と出力、止まったときに人が代わりにやる場合の工数、置き換え先（標準機能、API連携、廃止のいずれか）、撤去の期限。 最後の二つが空欄のロボットは、暫定の手段ではなく、恒久の仕組みとして扱われていることになる。
撤去の期限は、ERPの更新計画から逆算して置く。 次の移行や版の更新で触っている画面が変わるなら、その日が期限である。期限までに置き換え先が用意できないなら、移行のテストの計画に、そのロボットの作り直しと検証を最初から入れておく。
台帳を持つことには、もう一つの意味がある。 ロボットが作ったデータが仕訳や決算の数字に入るなら、そのロボットは財務報告に関わる処理の一部である。作った担当者が異動した後に誰が直すのか、変更を誰が承認するのかを、台帳の上で決めておく（現場が作った経理の自動化ツールは誰が保守するか、シャドーITへの依存を防ぐ）。
移行の計画の前に、ロボットのユーザーIDから触っている画面を洗い出す
冒頭の会社のように、ロボットの本数すら分からない状態から始めるなら、手がかりはSAPの側にある。ロボットは、SAPにログオンするためのユーザーIDを持っている。 担当者の個人のIDで動かしている場合でも、実行の日時は決まっている。
SAPの利用状況の統計（トランザクションST03N）からは、ユーザーごとにどのトランザクションを何回使ったかが取れる。 ロボットのユーザーIDを並べ、触っているトランザクションの一覧を作る。その一覧を、S/4HANAの簡素化リストと突き合わせれば、移行で画面が変わるロボットが先に分かる。 移行前の点検が自社開発のプログラムに対して行うことを、ロボットに対しても手で行うのである。
突き合わせの結果は、三つに分かれる。移行で画面が変わり、止まるロボット。画面は変わらないが、版の更新やFiori化で止まりうるロボット。当面は影響のないロボット。 一つ目は、移行のプロジェクトの課題として登録し、置き換え先と作り直しの工数を見積りに入れる。移行のときに捨てる自社開発のプログラムを使用実績で選ぶのと同じ考え方で、使われていないロボットは移行を機に止める（移行時にSAPアドオンを何本捨てられるか、使用実績から削除対象を選ぶ手順）。
ロボットのユーザーIDは、ライセンスの棚卸しでも確かめておく。 人ではなくロボットがSAPを使う場合の利用の数え方は、契約の条件によって扱いが変わりうる。移行の契約を結ぶ前に、ロボットのIDが何本あり、どの区分で数えられているかを確かめる（SAPのライセンスとデジタルアクセスを棚卸しする手順、未使用権限と外部連携）。
売上高700億円の化学品メーカー（3月決算、国内の連結子会社4社）。S/4HANAへの移行が2年後に決まり、影響調査の報告書は自社開発のプログラムを対象にしていた。 経理部長の指示で、業務改善の担当はまず、RPAのツールに登録されたロボットを数えた。稼働中が46本、止まったまま登録だけ残っているものが12本あった。 次に、ロボットが使う7つのユーザーIDについて、SAPの利用状況の統計から直近3か月に使ったトランザクションを取り出し、簡素化リストと突き合わせた。46本のうち11本が、仕入先と得意先のマスタの登録や銀行口座の変更など、移行で画面が置き換わるトランザクションを操作していた。 さらに19本は、Fiori化を予定している承認と照会の画面を操作していた。会社は、46本を一本ずつ台帳に載せ、置き換え先と撤去の期限を書いた。 仕入先の登録の3本は、購買システムからAPIで取引先を登録する連携に置き換え、移行のプロジェクトの範囲に入れた。入金消込の前処理の4本は、銀行明細の取込みと消込の規則を標準機能で組み直すことにした。経費明細の転記の5本は、経費精算システムからのファイル連携に置き換えた。 使用実績が年に数回しかない9本は、手作業に戻して廃止した。残る25本は、撤去の期限を付けた暫定のロボットとして残し、移行のテストの計画に、作り直しと検証の工数を最初から入れた。 移行の見積りには、ロボットの対応として約1,800万円が加わった。数えずに移行していれば、同じ作り直しは稼働後の障害対応として、最初の月次締めの最中に発生していた。移行の週末の翌営業日、止まったロボットは1本だった。 テストで漏れた月末の残高照会の出力で、担当者が手作業で代わりを務め、3日後に直した。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
決めるのは三つ
第一に、画面を操作するRPAの費用は、作ったときではなく画面が変わるたびに戻ってくると考える。 S/4HANAへの移行では、得意先と仕入先のマスタの登録がビジネスパートナーのトランザクションに置き換わり（SAP Note 2265093）、銀行口座のマスタのFI12は照会だけになる（SAP Note 2270400）。版の更新やFiori化でも画面は変わる。その時期はロボットの側ではなく、ERPの更新計画が決める。
第二に、経理の自動化の置き場所を、標準機能、APIやファイルでの連携、RPAの順に選び直す。 標準機能に置けば、SAPが版の更新の中で対応する。APIは画面ではなくデータの形で約束されている。RPAは、標準機能もAPIもなく連携を作るほどの件数もない作業か、つなぎの期間に限り、台帳に置き換え先と撤去の期限を書く。 期限は、次に触っている画面が変わる日から逆算する。
第三に、移行の計画を立てる前に、ロボットを自分で数える。 移行前の点検はSAPの中の自社開発のプログラムを調べるが、SAPの外にあるロボットの手順は対象にならない。ロボットのユーザーIDから利用状況の統計で触っているトランザクションを洗い出し、簡素化リストと突き合わせて、止まるロボットの作り直しを移行の見積りとテストの計画に最初から入れる。 GUIのスクリプト機能を許すサーバの設定と、ロボットのIDのライセンスの区分も、あわせて確かめる。
