SAP

保留を解除しているのは人ではなく、マスタに書かれた担当者だ。SAPは解除権限を与信セグメント単位で分け、限度額の引上げ承認を二重統制として設計している。営業任せにしない運用の組み方を示す。

捨てる判断のほとんどは、会議でなく既定スコープの計算で片がつく。人が判断するのは、実績はあるが業務ごとやめるものと、本番実績のない新規開発の二つだけだ。アドオン削減を議論から計算に移すための記事。

Central Financeは全面移行の縮小版ではなく、原本を動かさずに写しを一つ作る仕組みだ。継続複製の対象外に何が並ぶか、マッピングを誰が恒久的に保守するか。採用前に確かめるべき点を整理する。

支払提案から漏れる明細は、毎月同じ顔ぶれになりやすい。発生源は支払条件と支払方法の未設定、請求書検証の差異ブロック、確率ブロック、緊急の四つで、手を打つ部署がそれぞれ違う。その分け方を示す。

在庫側は品目マスタの評価クラスが、売上側は得意先と品目の勘定設定グループが効く。効く場所が違うため、勘定の正しさは二つの部署に分かれて存在する。誰も説明できない自動仕訳を減らすための整理。

配賦、償却、為替評価は、失敗したときの戻し方がそれぞれ違う。ジョブ運用を情報システム部門任せにしていると、決算の朝に判断が止まる。経理が知っておくべき依存関係と再実行の考え方をまとめた。

稟議は案件への承認、SAPは文書への承認で、二つは一対一で対応しない。分割発注や期またぎで一件の稟議が複数の購買文書に分かれると、案件側の承認は文書からたどれなくなる。承認の置き場所を整理する。

稼働から数年で帳票が重くなるのは処理能力の不足でなく、走査する明細の本数が増えたからだ。アーカイブで起きやすい失敗は、退避したデータが見えなくなること。明細照会に出し続ける設計を考える。

更新の頻度は導入形態で違う。Public Editionは年2回の定時更新で日程を選べず、Private Editionとオンプレミスは2年ごとの主要リリースと半年ごとの機能追加がある。形態に合わせて回帰テストを使い回す仕組みを示す。

テスト環境のデータを仮名加工情報として整理すれば楽になる、という発想はかえって高くつく。削除情報の管理や第三者提供の禁止など、別の義務が加わるからだ。検証環境のデータの扱い方を整理する。