SAP

UATを画面操作の確認にすると、問題は稼働後に表面化する。テストケースは伝票からでなく、試算表・開示・税務・経営資料という出口から逆算し、頻度と後戻りコストの2軸で粒度を考える。その進め方を示す。

案件採算の設計は、原価の器を作ることではなく、見積の一行と実績の一行を同じキーで並べる作業だ。工数は活動タイプ単価で原価になるため、単価の分母の置き方が案件の赤黒を左右する。その設計を示す。

稼働後の形骸化は研修不足でなく、例外が起きたときに処理を判断する人がいないことで起きる。判断手順を分岐表にし、窓口を業務部門のキーユーザーに置く。定着の度合いを受講率以外で測る方法も示す。

SAPの組織構造で稼働後に直せないのは、会社コード、管理領域、管理領域通貨の三つだ。事業別損益は利益センタで作れるが、法人の切り出しは後から作れない。設計会議の時間配分を見直すための記事。

サブシステムとSAPの数字が合わないのは、日付定義とマスタ粒度のずれで起きる。連携ごとに突合キーを持たせ、締めの基準日を片側に固定し、差異を日次で検知する。その仕組みの作り方を示す。

移行できれいにしたマスタは、稼働後の登録運用で崩れやすい。誰でも登録できる状態を放置すれば、重複と欠損は一年ほどで戻る。オーナーを業務部門に置き、申請・重複チェック・棚卸しを工程にする手順を示す。

配賦の結果に事業部から異論が出て、毎月説明に追われている人へ。SAPの配賦で揉めるのは技術より基準だ。アセスメントとディストリビューションの使い分け、基準値の選定、配賦後の説明までを整理した。

SAPの利益センタは組織の写しでなく、損益責任の単位で切る。導出の設計、受け皿に落ちた残高の監視、文書分割の判断、CO-PAとの役割分担まで、実務で詰まりやすい点を一つずつ順に整理する。

SACをダッシュボードとして使う限り、投資は回収できない。価値は計画と実績を同じモデルで突き合わせ、着地見込みを毎月書き換える運用にある。Excel予算からSACでの計画運用へ移る順序を具体的に示す。

S/4HANAが縮めるのは集計・転記・突合という機械の待ちだ。見積の確定や子会社データの到着という人の待ちは、業務設計で詰めるしかない。機能と締め作業を対応させて、どこが縮みどこが残るかを示す。