SAP S/4HANA導入の道のり　～会計編2～

真下：実際の工夫点などをお聞きします。まず、現在プロトタイプでどこまで進んでいるんでしょうか？また、アドオンの検討はされていますか？

石倉：現在、固定資産や海外送金などの面倒くさそうなところが残っています（笑）。
アドオンは、プロトタイプ検証を進める中で、標準的な業務フローやテンプレートとはっきり異なる要件が出てきたときに検討されます。
実装ベンダーから見れば、プロトタイプ検証とはアドオンにせざるを得ない候補を抽出する作業でもあるのだと思います。
アドオン候補は「この流れを実現するにはこういったアドオンが必要になります」とまとめてくれます。それをアシスト側で現場を含めて検討し、疑問点などをまとめたものを実装ベンダーと共有して、それらを取りまとめて関係者でアドオン検討会を行う流れです。
アシスト側は、会計のアドオンの場合、財務会計チームだけではなく、担当役員の林さん、プロジェクトマネージャーの岡田さん、システムチームやアプリチームなどの各チームからスクラムマスター（以下SM）などが参加して最終の判定を行います。

岡田：その結果、2023年末から稼働させている会計範囲においては、テンプレートに元々あったアドオンを改修してもらうだけで、ABAPで開発するような新たなアドオン開発は無し、となりました。

真下：今の話は、IPS社が提供するテンプレートにアドオンがあるので、それを改修するという意味と捉えましたがいかがでしょうか。

石倉 ：そうですね。
テンプレートを簡単にいうと、ベースは業界標準のプロセスに沿ってSAPのパラメーターなど各種の設定をした設定集のようなものです。
ただ、そのプロセスを実行するにあたり、「こうなっていたら使いやすいだろうな」というものもでてきます。例えば、「大量のデータをチェックして処理したい」という時に、対象データを1件ずつ呼び出してチェックして処理するより、条件検索で一覧展開した上で処理したい場合ってありますよね。
そういったことを実現するアドオンもセットで提供されているものです。
おおまかに言うと、テンプレートとは「SAPパラメーター設定済環境に使い勝手を良くするためのアドオンを加えたもの」なのです。

真下：今回修正対象となったテンプレートのアドオンはどのようなものなのでしょうか。

石倉：テンプレートのアドオンによる消費税計算のタイミングを変更してもらいました。
このアドオンは、楽楽精算（経費精算システム）からのアップロードデータをSAP側で受け取る部分にあたります。
SAPの通常処理だとデータを受け取ったときに消費税計算を行うのですが、アシストの場合、このアップロードするデータは楽楽精算で既に消費税計算済みなので、そのままだと二重計算になってしまうためスキップさせました。
また、SAPには処理途中にその処理が正しいことを確認するシミュレーション機能というものがあるのですが、テンプレートのアップロードデータの受け取り処理部分にはその機能がありませんでした。今回、機能を追加してもらってエラー等を事前にチェックできるようにしています。
ちなみに、このアプリはABAPで作成された、いわゆるアドオンですが、SAPのコア部分に触れているものではないので、SAPバージョンアップ時の影響はほとんどないと思います。

真下：これからもアドオンは発生していくのでしょうか。

岡田：原則として、可能な限り新規アドオンは作らない方針です。
そのために、アドオン開発の判定はこれからも慎重に行っていきます。

真下：アドオン以外にも機能拡張方法はあると思いますが、そのあたりはいかがでしょうか。

岡田：今回のアドオン判定会議で候補となっていたものの中にも、データ参照クエリを新たに作成することで対応できたようなものもあります。
できるだけ簡易に実現できる手段や、良い外部サービスがあれば積極的に利用していきたいと思っています。

真下：例えば、どのようなサービスでしょうか？

石倉：既に採用を決定し、Stage0.5でも使っていこうと考えているものにBlackLine※があります。
BlackLineで現行システムのAMISで行っている入金消込の処理を代替したいと考えています。

また、現場の各担当の工夫で処理されているタスクの見える化や監査法人との処理のオンライン化なども計画しています。
Stage0.5では候補となる処理を洗い出し、その中から今後BlackLineを使っていけるかどうかを判断し、BlackLine化を試みる予定です。

※）BlackLine：経理業務のサービス

岡田：DataSpiderは利用します。
SAPというシステムは企業システムの基幹のため、周辺システムとのデータ連携が多く発生します。
アシストでは扇子（Salesforce）※との連携もありますし、楽楽精算や銀行データの取り込みなども発生します。
現在人手に頼っている部分もあるので、できるだけDataSpiderで自動化を図っていきたいと考えています。

例えば、扇子から抽出したデータをDataSpiderでBlackLineに連携して、仕分けや加工処理などを行い、そのデータをDataSpiderでSAPに連携するようなことを考えています。

※）扇子：Salesforceで構築したSFAの社内システム名称（詳細は『SAP S/4 HANA導入プロジェクトの軌跡。まずは概要です。』参照）

石倉：前編でプロトタイプ検証作業でStrapを使っている話をしましたが、他にもプロトタイプ検証作業にSAP Enable Now（以下、SEN）※も使っています。

※）SEN（https://www.sap.com/japan/products/hcm/enable-now.html）

SENでプロトタイプの対象となっている処理の画面遷移を取得し、注釈を加えておくことで、検証担当の現場の方がいつでも動画として内容確認できるようにしています。

真下：なるほど、ちなみにSENの利用はいつ頃決められたのでしょうか。

石倉：プランニング、概要設計段階です。
お話ししたように、今回の基幹システム刷新ではアジャイル開発の方式を選択しています。
プロジェクトをアジャイルで進めていくにあたって、レビュープロセスやテストに現場メンバーの積極的な参加がキーとなっていました。
現業を持っている現場の方に、何度もレビューに参加してもらうのはなかなか難しく、アジャイルで進めていく上で障壁になりそうでした。
そのため、どうしたら忙しい現場メンバーの力を活かせるのか、特にプロトタイプ検証はどうやったらスムーズに進めていけるのか、を検討した結果です。

真下：今後は扇子からSAPへの連携もありますが具体的にどのようなものになりそうですか。また、現時点で課題となっていることは何ですか。

石倉：扇子で見積もりを作り、発注が確定したら発注伝票としてSAPに連携させる、そういったことをイメージして、業務フローや他の課題に取り組んでいます。

駒形：前回のインタビューで既存の仕組みでは受注伝票がないという話がありましたが、そのあたりと関係しそうですね。

石倉：はい。AMISと異なり、SAPにおける処理は伝票の遷移で表現されます。プロセスによっても異なりますが、受注伝票から始まり、購買伝票、入庫伝票、出庫伝票、請求伝票と処理されていくイメージです。

駒形：最初に受注伝票が必ずできるのですね。今後はどのようなタイミングで受注伝票ができますか。

石倉：扇子で見積もりが確定すると受注伝票データを組み立て、それをSAPへプッシュする予定です。
SAPではそれを受け取って受注伝票として処理します。
このあたりの処理の流れは、今後、受発注処理を実装していく中でお話しします。
今の一番の課題は、受注伝票を作るためにも、品目マスター（SAPにおける商品マスター）をどうするかです。

現在、優先的に品目マスターに関する検討をしています。
「何を品目マスターで持つのか」と「メインの品目マスターをどこで持つのか」と「メンテナンスフロー」が大きなテーマです。

SAPでは、品目マスターに登録の無い品目の発注はできないことが前提です。
このあたりは、AMISで色々工夫をしてきたことが通じない世界ですので、十分検討する必要があるわけです。

真下：確かに私も営業として、既存のAMISでは、品目マスターにないものは「その他」として処理していました。
そういった営業事務処理上の工夫で乗り切っていたことができなくなるのですね。
それにより、営業からするとどのような点が変わりますか？

岡田：1回だけしか販売しないような製品であっても、基本的に品目マスターが必要になります。

真下：1回きりしか販売しない製品でもマスターの登録が必要になるということですか？
それは営業としてはかなり面倒ですね。

岡田：はい。
そのあたりをどう乗り切っていくのか議論をしています。
数字の正確性を担保するというSAPの導入目的の一つは、財務諸表にある売上が、その発生単位である伝票までさかのぼることができることが保証されている、といったような仕組みに支えられています。
その仕組みの基礎が、品目マスターなので、ここは手を抜けないところです。
いずれにせよ、AMISに存在する大量の商品情報をどう整理して品目マスター化するのか、品目マスターの運用問題とともに基幹システム刷新面での大問題の一つだと考えています。

真下：伝票までさかのぼれることが保証されている、というのはどのようなイメージでしょうか？

石倉：例えば、毎年の財務諸表が出た時に、売上の項目をクリックしてドリルダウンしていくと、最終的にその売上の元になった伝票までたどり着けるということです。その数字がどこから来た数字なのかを明らかにすることが、SAPを導入する理由の一つです。
そのため、今までのように品目マスターにないものを「その他」として処理したり、摘要にコメントを残すというように曖昧な処理をしてしまうことができなくなるということでもあります。

真下：なるほど、既存のAMISの自由度が高い点は営業からすると融通が効いてありがたかったのですが、SAPで再構築するにはそれがネックになっているのですね。
品目マスターに対しては、アドオンテーブル（テーブル拡張）で対応するという話も聞いたことがありますがその点はいかがでしょうか。

石倉：バージョンアップ時に思わぬ問題を引き起こす可能性がある、避けられるなら避けるべきだ、という話もよく聞きますので、原則としてテーブルの拡張は行わない方針で考えています。

真下：大変そうですが、それを乗り越えることでバージョンアップに耐えられるSAPが構築できるわけですね。
次は画面についてお聞きします。今回はFioriを使っているのですか。

岡田：はい、原則Fioriです。SAP GUIは利用しない、という方針を決めていました。
画面によっては、Web画面（SAP Gui for HTML）でFioriでないものもありますが、いずれにせよ、操作的にはWebベースです。

真下：SAP GUIを使わないという方針を決めたのはなぜですか？

岡田：実は、SAP導入アセスメントの際に、SAP社からSAP GUIを利用する際、（AWSの場合は）AWS Direct Connectの専用線サービスを使うように推奨されました。
アシストもAWS Direct Connectは利用しているので、この環境でSAP GUIを使うことはできるのですが、その場合、アシストのネットワークを必ず経由することになってしまうため、ネットワーク的な柔軟性を損ないかねないと考えました。
そのようなわけで将来的にAWS Direct Connectの利用をやめられるようにしておくことも視野におき、最初からWebベースでの利用を前提にしたということです。

SAPの実装ベンダーから「AWS Direct Connectは利用されていますか？」と聞かれると思います。SAPを利用するには必須とかパフォーマンスを理由にSAP GUIを勧めてくるベンダーもいますが、自分たちがSaaSをどう使いたいかを元に判断すべきだと思います。

真下：なるほど、サービスを拡張する際に会社のネットワークがボトルネックにならないようにするためでもあるのですね。
クラウドサービスの話が出ましたが、今回アシストはSAP S/4HANA Cloud, private editionを採用したと聞いています。private edition採用の理由を説明いただけますか。

石倉：アシストの場合、もしかすると、SAP S/4HANA Cloud, public editionでも十分だったかもしれませんが、先ほども話題になったIPS社のテンプレートを利用したかったからです。
このような3rdベンダーテンプレートを利用する場合のクラウド版となると、private edition 一択だったということです。

駒形：実際、テンプレートを使ってみていかがでしたか。

石倉：このテンプレートがあって、とても助かっています。
それぞれの業務フローごとにテンプレートがあることで、そのテンプレートのフローを確認しながらアシストのプロセスを検討していくことができています。テンプレートが一種の教科書のような役割を果たしている感じですね。

駒形：SAP社もベストプラクティスを提供していますが、それとの違いは何なんでしょうか？

岡田：SAP社のベストプラクティスは業務フロー全体ではなく、特定の処理を切り取ったもので、それらをつなぎ合わせて全体の業務フローを作るようになっていました。
そのためなかなかピンとこないことも多かったのですが、IPS社のテンプレートは処理を一連の業務フローとして表現してくれているので、理解しやすいと感じています。

駒形：テンプレートは教科書と言っていましたが、どの程度適合するものでしょうか？

石倉：結論からいうと現在、テンプレートをそのまま使っている部分はかなり少ないと思います。
先ほど話したとおり、テンプレートを教科書として、その内容をSignavioに落として、プロトタイピングを通じてアシストとしてのプロセスを決めています。
そういう意味では、IPS社のテンプレートをお手本とはしていますが、アシストとしてのTO-BEモデルを作っているといえると思います。

駒形：そうなると、アシストとしてのTO-BEモデルとSAPとしてのベストプラクティスに乖離が出ないかが気になります。

岡田：SAPの標準では非常に丁寧な処理で組み立てられているところを、アシストとして、ここは省略できるとか、ここは外からデータが来るので不要とかありますが、今のところ、全体としては標準に近い形になる予定です。

真下：それでは、最後に今後の予定について教えてください。

岡田：はい、まず会計パッケージのSMILEをSAPの財務会計（FI）へ置き換えます（Stage0.5）。
これは、2023年の年末から年始にかけてデータ移行を行いました。2023年の決算は現行のSMILEで行います。（詳細は『SAP S/4 HANA導入プロジェクトの軌跡。まずは概要です。 』参照）
その後、2024年の8月から9月頃に、AMIS（既存のロジ系システム）をSAPのロジ系（SD、MM） に置き換え、SAPの管理会計（CO）も実装していく計画です。
そうなるとSAPの財務会計にSAPのロジ系からデータが直接流れる（Stage1.0）ようになります。

真下：2024年8月までは、AMISのデータをSAPで処理するということですか。

石倉：はい、そのとおりです。
Stage0.5では、既存のAMISデータをSAPの会計に連携します。
また、AMISには極力改修を入れたくありませんので、現在のAMISの仕様や生成するデータの形がStage0.5におけるSAP側の前提であり制約となります。

駒形：具体的にはどのようなところでしょうか。

石倉： 例えば、SMILEと連携するために、AMISではプロダクトコード、プロダクトグループというものを使って処理をしていますが、SAPとしては不要です。
しかし、AMISのデータを連携させる以上、Stage0.5の間は今のデータの形として残し、業務フローもそれらを前提として組み立てないといけないことになります。
このあたりがStage0.5では制約になっています。

駒形：なるほど、まずはSMILEの置き換えが目標である、ということですね。

石倉： そうです。会計的には、先ほど話があったように2023年度決算はSMILEですが、翌年2024年度の決算は変則的ですがSAPで行い、翌々年2025年の決算から完全な形で行われるようになると考えています。

真下：Stage0.5からStage1.0に進むと、基幹システムがAMISからSAPに切り替わり、扇子で見積もりを作成し、受注確定したらSAPに伝票が渡り、そこから管理会計までの一連のプロセスがSAP内で処理されるようになるわけですね。ちょっと楽しみです。

真下、駒形：本日は長時間ありがとうございました。