石本 貴志

保守料が無駄になるのは、更新を取り込む工程が社内にないからだ。追従を止めるのはアドオンではなく、回帰テストの量である。テストを資産化し、適用時期を年次で固定し、役割を分ける進め方を示す。

ライセンスの棚卸しは価格交渉でなく、権限ロールと利用ログの突合から始まる。ずれは未使用、重すぎる、軽すぎる、人が操作していないの四型で出る。外部連携の分はインタフェース一覧から数える。

テンプレート展開が崩れるのは、1社目で例外を1件認めた瞬間に2社目以降が交渉になるからだ。層の境界と変更手続を先に固め、展開順は規模順でなくテンプレートが壊れやすい順に組む。その進め方を示す。

ERP選定を規模で判断すると外しやすい。見るべきは法人数、拠点、通貨、連結、取引の型、内製人数という複雑さの六変数だ。そのうち後から足せないものがいくつあるかが、SAPを選ぶ理由になる。

銀行連携を1本の要件として扱うと、難易度も効果も違う4本が同じ工程に押し込まれる。入金の照合率はフォーマットでなく手がかりの情報量で決まる。消込ルールの再設計を連携設計の前に置く理由を示す。

決まらないプロジェクトの課題管理表は、判断者列が空か全部PMOになっている。上げ先を三階層に固定し、付議基準を後戻りの範囲で定義し、決裁権を運用する部門に置く。滞留の見方もあわせて示す。

日本固有要件を一覧のまま扱うと、全部が開発になる。法令が求める事項と現行帳票の体裁を分け、4つの受け皿に割り付けた表をFit-to-Standardの成果物にする。税コードの考え方も整理する。

見積書は合計金額でなく、前提条件欄から読む。会社コード数、移行年数、帳票本数、レビュー回数といった数量の前提が空欄なら、そこが追加費用の入口になる。契約で押さえるべき点もあわせて示す。

エースを出さないプロジェクトでは、要件定義が現行業務の写しになり、例外処理が設計から落ちる。供出は工程ごとに稼働率を配分し、要件定義は70〜80%を目安にする。抜けた席の埋め方も整理する。

S/4HANA移行の方式がいくつもあって、自社にどれが合うのか分からない人へ。3つのアプローチのメリットとデメリット、向く会社、経理への影響を並べて比べ、どこから検討すべきかの当たりをつける。