SAP・システム

元帳を増やすべきなのは、その評価で独立した財務諸表を外に出す場合だけだ。日本の税務償却は損金経理を入力とし、申告は確定した決算に基づくため、税務簿価は会計に従属する。だから税務は元帳でなく減価償却領域と申告調整で持つ。決め手は器の数でなく、取得時にどの属性を取っているかにある。

カットオーバーで先に決めるのは稼働日ではなく、移行基準日と凍結する伝票の範囲。期首残高は勘定残高・未決済明細・期中累計・固定資産の四つに分かれ、残高だけを移すと消込と償却が止まる。旧システムの停止日も計画の一部になる。

帳票要件の絞り込みは利用頻度でなく、どの意思決定に誰がいつ使うかで切る。標準で出す・作る・廃止するの3分類のうち、プロジェクトの成否を決めるのは廃止できた本数。作ると決めたものも三段階で削ってからアドオンに落とす。

UATを画面操作の確認にすると、詰まるのは稼働後になる。テストケースは伝票からでなく試算表・開示・税務・経営資料という出口から逆算し、頻度と後戻りコストの2軸で粒度を決める。合否は不具合ゼロでなく、残った不具合の運用回避が決まっているかで判定する。

案件採算の設計とは、原価の器を作ることではなく、見積の一行と実績の一行を同じキーで並べる作業である。工数は活動タイプ単価で原価に化けるため、単価の分母をどこに置くかが案件の赤黒を左右する。決算後にしか粗利が出ないのは、S/4HANAでは設計の選択の結果でしかない。

稼働後の形骸化は研修不足でなく、例外が起きたときに処理を決める人がいないことで起きる。判断手順を分岐表にし、窓口を業務部門のキーユーザーに置き、定着は受講率でなく後付け振替仕訳や調整Excelの本数で測る。

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

サブシステムとSAPの数字が合わないのは連携の技術不良でなく、日付定義とマスタ粒度のずれで起きる。連携ごとに突合キーを持たせ、締めの基準日を片側に固定し、差異を日次で機械的に検知して一次責任者を個人名で置く。販売・購買・経費・給与で崩れる場所は違う。

移行できれいにしたマスタは、稼働後の登録運用で必ず崩れる。取引先・品目・勘定のオーナーを業務部門に置き、登録申請・重複チェック・棚卸しを工程として固定する。誰でも登録できる状態を放置しないための、権限とオーナーシップの決め方。

締めた後に修正伝票が入り報告値と確定値が食い違うのは、SAPの会計期間を開けっ放しにしているからだ。期間オープン管理（OB52）を締めの申請・承認・記録を伴う運用に設計し、閉めた期を勝手に開かせない統制に変える。