S/4HANAへの移行から1年半がたった。画面はほぼ全部、移行前と同じSAP GUIのままである。 保守ベンダーの定例会で、次の改善の柱としてFioriへの全面切替えが提案された。操作が直感的になる、スマートフォンから使える、SAPの新しい機能はFioriで出てくる。経理部長はうなずきかけて、手を止める。 経理の担当者は毎日、伝票入力の画面をキーボードだけで打っている。月末の3営業日は1人で数百件の仕訳を入れる。その画面を変えて、締めが1日でも延びたら誰が責任を持つのか。 一方で、情報システム部の問い合わせ記録を見ると、件数の多い項目は経理の入力ではなかった。発注の承認をしようとした部長が、ログオンの手順と承認の画面を思い出せない、という問い合わせである。
全面切替えが経理の締めを遅くする理由
Fioriへの全面切替えを提案されたとき、経理の側がまず心配するのは入力の速度である。この心配は正しい。
経理の担当者がGUIで使っている画面は、少数のトランザクションに集中している。総勘定元帳への仕訳の入力(FB50)、仕入先の請求書の入力(FB60、購買発注に紐づくものはMIRO)、明細の照会(FBL3N、FBL1N、FBL5N)、自動支払(F110)。 毎日これらを繰り返す担当者は、画面の項目の順番とショートカットを手が覚えている。マウスに触らずに1件の仕訳を打ち終える人もいる。Fioriのアプリは、ブラウザの上で動き、項目の配置もボタンの位置も違う。 覚え直すまでの数週間は、入力が遅くなる。
そして、その数週間が月末に重なれば、締めが延びる。 全面切替えを年度の途中で行えば、少なくとも一度の月次締めは、慣れない画面で通すことになる。大量の仕訳は、もともと画面から1件ずつ打つのではなく、Excelからのアップロードで入れている会社も多い。画面を変えても、その部分の効率は何も変わらない(SAPの手入力仕訳は件数でなく、アップロードと直接起票の経路を絞って統制する)。
全面切替えのもう一つの費用は、稼働の後に来る。 Fioriのアプリは、使えるようにするたびに、アプリを動かすサービスの有効化と、利用者に見せるカタログや画面構成の設計と、それを利用者に割り当てる権限ロールの設計が要る。アプリの数だけ、権限の設計と、アップグレードのたびの回帰テストの対象が増える(S/4HANAのアップグレード対応を毎回ゼロから始めない、経理の回帰テストの資産化)。使う人の少ない画面まで移せば、この費用は効果を上回る。
画面を三層に分け、触る人数と頻度で順番を決める
全面か据え置きかで議論が止まるのは、画面をひとまとまりで見ているからである。経理から見たSAPの画面は、使う人と使い方で三つの層に分かれる。
一つ目は承認の層である。 購買依頼や発注の承認、仕入先の請求書の承認、経費の承認、支払の承認。触るのは部長や課長で、人数は経理の十倍を超えることが多い。一人あたりの頻度は月に数回で、承認のためだけにSAPにログオンする。この層の利用者は、GUIの操作を覚えても、次に使うまでに忘れる。 問い合わせが多いのはここである。
二つ目は照会の層である。 部門の予算と実績、取引先ごとの債権残高、原価センタの費用の明細。触るのは事業部の管理担当や経営企画、経理の管理職で、頻度は週に数回から月に数回。GUIでは明細を画面に出してExcelに落とし、手元で集計し直している人が多い(SAPから出したExcelが正本になっていないか、加工した集計表をどこまで許すか)。
三つ目は入力の層である。 仕訳、請求書、支払、固定資産の登録。触るのは経理と購買、営業事務の担当者で、人数は少なく、頻度は毎日である。
三つの層を並べると、画面の移行が効く順番は自然に決まる。画面を変えるときの教育の総量は、触る人の人数と、その人が操作を忘れる速さで決まる。 月に数回しか触らない人が何百人もいる層では、覚えやすい画面に変える効果が大きい。毎日触る人が数十人しかいない層では、今の画面に慣れていること自体が資産である。
承認の層は、Fioriの画面より先に承認の置き場所を決める
承認の層をFioriに寄せる中心は、承認を待っている案件を一か所に集める受信箱のアプリ(My Inbox)である。承認者は、発注でも請求書でも、同じ受信箱を開いて、内容を見て、承認か差戻しを押す。 S/4HANAでは、購買依頼や発注、仕入先の請求書の承認に、条件と承認者を画面から設定できる柔軟なワークフロー(flexible workflow)が用意されている。
ここで先に決めておくべきことがある。 承認をSAPの中に置くのか、外の稟議やワークフローのシステムに置くのかである。多くの会社では、稟議は外のワークフローで処理し、SAPの中では発注の承認をもう一度行っている。この二重の承認をそのままFioriに移すと、承認者が押すボタンの場所が一つ増えるだけで終わる(支払と稟議の承認をSAPに置くか外部ワークフローに置くか、二重承認が生まれる境目)。
画面を寄せる前に、承認の経路を棚卸しし、SAPの中に残す承認と外に出す承認を分ける。SAPに残す承認だけを受信箱に集め、承認者が月に一度ログオンすれば済む形にする。 承認者の権限は、承認に要るアプリだけに絞って割り当てる。承認者に照会や入力の権限まで付けると、職務分掌の点検の対象が一気に広がる(SAPの権限設計と職務分掌(SoD)、内部統制を仕組みで担保する実務と判断基準)。
承認の層を寄せた効果は、数字で測れる。 承認に関する問い合わせの件数、承認待ちの滞留日数、月末に承認が間に合わずに翌月に回った請求書の件数。この三つを移行の前後で比べる。
照会の層は、数字の出どころを揃えてから寄せる
照会の層をFioriに寄せる意味は、見栄えではない。明細をExcelに落として集計し直す手作業を減らすことである。 Fioriの照会のアプリは、勘定や原価センタの残高から伝票の明細までを、同じ画面の中でたどれる。S/4HANAでは会計と管理会計の明細が一つの表(ユニバーサルジャーナル)に載っているので、財務会計の数字と管理会計の数字を別々に取り出して突き合わせる必要が減っている(S/4HANAのユニバーサルジャーナルで消える作業と、FIとCOの照合後に残る責任)。
ただし、照会の層を寄せると、一つ問題が起きる。 事業部の管理担当がFioriで見る数字と、経営会議の資料に載っている数字が合わない、という問い合わせである。会議の資料は経理がGUIから落とした明細を手元で組み替えて作っており、組替えの規則が画面の側にはない。照会の画面を寄せる前に、経営会議の資料の数字を、どの照会の画面のどの条件から出すかを決めておく。 決められないなら、その資料は画面の移行とは別に、帳票の要件として整理し直すべきものである(SAPの帳票・レポート要件を絞る手順、標準で出す・作る・廃止するの3分類)。
照会の層は、全員に一斉に配らない。 まず、Excelでの組替えに最も時間を使っている部門から始め、組替えの作業が実際に減ったかを確かめてから広げる。
入力の層はGUIに残し、例外だけを個別に移す
入力の層は、GUIに残すのが原則である。残すと決めたうえで、例外を個別に拾う。
第一の例外は、Fioriでしか登録や変更ができない機能である。 冒頭で触れた銀行口座のマスタがその例で、財務の担当者は銀行口座の開設や変更のたびに、Fioriのアプリを使うことになる。この種の機能は、S/4HANAの版を上げるたびに増えうる。 アップグレードの計画のたびに、簡素化リストでGUIの画面が照会専用になる項目がないかを確かめ、該当する担当者だけに、そのアプリの使い方を教える(SAPと銀行の連携は、消込ルールを直さないまま自動化すると作業が増える)。
第二の例外は、入力の頻度が低い担当者である。 本社の経理ではなく、拠点で月に数件だけ経費の請求書を入れる事務の担当者は、入力の層にいても、性質は承認の層に近い。この人たちには、入力の項目を絞ったFioriのアプリを渡したほうが、誤入力と問い合わせが減る。
そして、画面を分けても、入口は一つにできる。 Fioriの起動画面(Fiori launchpad)には、GUIのトランザクションをブラウザの上で動かすSAP GUI for HTMLの画面も、タイルとして並べられる。承認者はFioriのアプリを、経理の担当者はGUIの画面を、同じ入口から開く。入口を揃えるだけで、ログオンの手順についての問い合わせは減る。 ただし、ブラウザの上のGUIは、Windowsに入れるGUIと操作の感触が同じではない。毎日大量に打つ担当者には、Windows版のGUIを使い続けてもらう。
売上高1,400億円の産業機器メーカー(3月決算、国内の連結子会社6社)。2年前にS/4HANAへ移行し、画面はGUIのままだった。 保守ベンダーはFioriへの全面切替えを提案し、見積りでは、対象のアプリ約90本の有効化、権限ロールの再設計、全利用者向けの研修で、9か月の工程を示した。経理部長はまず、利用者の数と頻度を画面ごとに数えた。利用者1,120人のうち、経理と購買・営業事務で毎日入力する担当者は210人。照会だけの利用者は約160人。残る約750人は、発注と請求書と経費の承認のためにだけログオンしており、一人あたりのログオンは月に平均3回だった。 情報システム部の問い合わせ記録では、承認に関する問い合わせが全体の約4割を占め、そのほとんどがログオンの手順と承認画面の操作だった。会社は、全面切替えをやめ、三層に分けて順番を組み直した。 第1段は承認の層で、外のワークフローと重なっていた発注の二重承認を整理し、SAPに残す承認を受信箱に集めた。承認者の権限は承認のアプリだけにした。第2段は照会の層で、経営会議の資料の数字を出す照会の画面と条件を経理が先に定め、Excelでの組替えに最も時間を使っていた事業部から順に配った。 入力の層はGUIに残し、銀行口座のマスタの登録と、拠点の経費の請求書の入力だけをFioriのアプリに移した。移行したアプリは約30本、工程は5か月になった。 承認に関する問い合わせは、第1段の後の3か月で月平均約240件から約60件に減り、月末に承認が間に合わず翌月に回る仕入先の請求書は、月に約70件から十数件になった。経理の月次締めの営業日は、移行の前後で変わっていない。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
Fiori化で決めておく三つのこと
第一に、Fiori化を全面か据え置きかの二択にしない。 GUIは今も保守されており、SAP GUI for Windows 8.00は2023年1月27日に出荷され、7.70の保守は2024年4月9日に終わり、2026年7月16日には8.10の一般提供も始まった。一方で、銀行口座のマスタのように、S/4HANAではFioriでしか登録や変更ができない機能も出てきた。画面を入力・照会・承認の三層に分け、層ごとに移すかどうかを決める。
第二に、順番は、触る人の人数と、その人が月に何回触るかで決める。 月に数回しか触らない人が数百人いる承認の層から寄せ、承認の経路を棚卸しして二重の承認を整理してから受信箱に集める。照会の層は、経営会議の資料の数字をどの画面から出すかを決めてから、組替えに時間を使っている部門から配る。毎日大量に打つ入力の層はGUIに残す。
第三に、入力の層の例外を、版を上げるたびに拾う。 Fioriでしか登録できない機能と、入力の頻度が低い拠点の担当者の画面だけを、個別に移す。入口はFioriの起動画面に揃え、GUIの画面もタイルとして並べる。効果は、承認の問い合わせ件数、承認待ちの滞留、翌月に回った請求書の件数で、移行の前後を比べて確かめる。
関連記事
- 支払と稟議の承認をSAPに置くか外部ワークフローに置くか、二重承認が生まれる境目
- SAP稼働後の定着を左右するのは操作研修ではなく、例外時の判断手順である
- SAPの権限設計と職務分掌(SoD)、内部統制を仕組みで担保する実務と判断基準
- S/4HANAのアップグレード対応を毎回ゼロから始めない、経理の回帰テストの資産化
- SAPから出したExcelが正本になっていないか、加工した集計表をどこまで許すか
- SAPの帳票・レポート要件を絞る手順、標準で出す・作る・廃止するの3分類
- S/4HANAのユニバーサルジャーナルで消える作業と、FIとCOの照合後に残る責任
- SAPの手入力仕訳は件数でなく、アップロードと直接起票の経路を絞って統制する



