本稼働直後の現場には、独特の緊張感がある。
稼働させて終わり、ではない。むしろそこからが本番だ。設計時には想定していなかったデータ量、運用が始まって初めて見える業務の波——そうしたものが、稼働後に次々と押し寄せてくる。
今回は、ある現場で「入金消込が手作業で詰みかけた」話をしたい。私自身は初動の相談を受けた立場で、その後の詳しい対応は別の担当者が引き継いだ。だからこれは「私が解決した武勇伝」ではなく、「現場で何が起きて、SAPの標準機能に何ができるのか」を整理した記録として読んでいただきたい。
ある製造業の、本稼働直後の現場
お客様は、ある製造業の企業だった。業界が特定されると差し障りがあるため、ここでは詳細は伏せておく。
つい最近、長く使ってきたレガシーのホストシステムから、SAP S/4HANAへ移行したばかりだった。特徴的だったのは、アドオン（カスタム開発）をほぼ作らず、SAP標準の機能をメインに据えた「クリーンな」構成だったことだ。S/4HANAのクリーンコアという思想に沿った、今らしい移行だった。
4月に初めての決算を終え、ようやく一息つこうとしていた。ところが、その矢先だった。
稼働してしばらく経った頃から、関係会社と本社の間の入金処理が本格的に始まることになった。そして、その件数が現場の想定を大きく超えていた。
入金消込8万件——手作業では詰む
入金消込の件数が、8万件を超えていた。翌月には10万件を超える見込みだという。
消込（けしこみ）というのは、入ってきた入金と、こちらが持っている売掛金（債権）を突き合わせて、「この入金はこの請求に対するものだ」と確定させる作業だ。会計の根幹をなす処理であり、ここが滞ると決算も資金管理も回らなくなる。
現場は当初、銀行仮勘定からの消込を、画面上で手動で行おうとしていた。だが、ここで壁にぶつかる。
手動消込の画面では、一度に処理できる件数に上限があった。おおむね500件が限界で、それを超えると処理が重くなり、タイムアウトしてしまう。
8万件を500件ずつ。単純に割っても、160回以上。来月の10万件なら200回。これを毎月、手作業で——。考えるだけで、現場の疲弊が目に浮かぶ。これはもう「忙しい」というレベルではない。仕組みとして詰んでいる状態だった。
なぜ手作業で詰むのか——オンライン処理の限界
ここには、SAPの仕組みを理解していると見えてくる、構造的な理由がある。
画面を使った手動の処理は「オンライン処理」と呼ばれる。人が画面を操作して、その場で結果を受け取る方式だ。このオンライン処理には、応答時間の上限が設定されている。一定時間内に終わらない処理は、システムが強制的に打ち切る仕組みになっている。
大量データを画面で一気に処理しようとすれば、この上限に引っかかる。500件という壁は、まさにこれだった。
つまり、大量処理をオンラインで回そうとすること自体が、そもそもの設計ミスだった。発想を変える必要があった。大量処理は、オンラインではなくバックグラウンド（バッチ）に逃がす——これが出発点だ。
標準機能だけで、桁を変える
ここからが、SAP標準機能の底力の話だ。アドオンを作らなくても、標準の機能を正しく使えば、処理の「桁」を変えられる。
① 自動消込をバックグラウンドで回す
SAPには、自動消込（一般にF.13と呼ばれる処理）という標準機能がある。これをバックグラウンドジョブとして実行すれば、件数の上限もタイムアウトもない。会社コードや得意先の範囲で分割して、複数のジョブを並列で走らせることもできる。
500件ずつ手作業で160回、という世界から、夜間にジョブを流して朝には終わっている、という世界へ。同じSAPでも、使い方ひとつでここまで変わる。
② 自動消込が「効く」ための土台を整える
ただし、自動消込はボタンひとつで魔法のように動くわけではない。
「どの入金が、どの債権に対応するのか」をシステムが判断するための基準（突き合わせのキー）が、きちんと整備されていなければならない。割当番号や参照番号といった項目に、消込の手がかりとなる情報が正しく入っているか。ここが自動消込の生命線になる。
逆に言えば、ここが整っていないと、自動消込をかけても大半が残ってしまい、結局手作業に逆戻りになる。
③ 銀行明細の取込時点で、消込率を上げる
さらに根本的な対策として、電子銀行明細（EBS）の取込ルールを強化するという手がある。
銀行からのデータを取り込む時点で、明細の中の情報を解釈し、対応する債権を自動で見つけて消し込む。この取込時の自動消込率を上げられれば、そもそも残作業そのものが減る。後工程で頑張るより、入口で勝負する発想だ。
④ 関係会社ならではの打ち手
今回のように関係会社間の取引が多い場合は、専用の打ち手もある。
債権と債務を相殺する（ネッティング）仕組みや、S/4HANA標準の会社間の照合・突合機能を使う方法だ。そして何より効くのが、上流の運用ルール——「入金には必ず請求番号を乗せる」という約束事を関係会社間で徹底することだ。入口のデータがきれいなら、後工程は驚くほど楽になる。
この現場が教えてくれること
この一件には、本稼働直後の現場が抱える本質が詰まっている。
ひとつは、「動いている」と「回り続けられる」は違うということ。稼働はゴールではなく、運用というマラソンのスタート地点だ。データ量が本格的に増えたときに耐えられるか——それは、稼働して時間が経って初めて試される。
もうひとつは、アドオンを作らなくても、標準機能を正しく使えば道は開けるということ。「標準ではできない」と思い込んで手作業に走るのか、「標準でどこまでできるか」を知った上で設計するのか。その差が、現場の明暗を分ける。クリーンコアの時代だからこそ、標準機能をどれだけ知っているかが、これまで以上に効いてくる。
そして——大量データに手作業で立ち向かおうとしている現場は、きっとこの一社だけではない。同じ壁にぶつかっている方が、どこかにいるはずだ。
同じような現場に立つ方の、何かのヒントになれば嬉しい。記事へのご感想やご意見があれば、お問い合わせフォームからお寄せいただけると励みになる。
（このカテゴリでは、SAP運用保守の現場リアルをお届けしています。）
コメント