ERPの機能不足を標準機能・他社パッケージ・自社開発で埋める三択の比べ方
アドオンの是非だけで議論していると、外部パッケージという三つ目の選択肢が比較から抜ける。三択を比べる軸は初期費用ではない。バージョンアップのたびに発生する追随コストと、五年後の保守の重さで比べたい。
アドオン
移行時にSAPアドオンを何本捨てられるか、使用実績から削除対象を選ぶ手順
捨てる判断のほとんどは、会議でなく既定スコープの計算で片がつく。人が判断するのは、実績はあるが業務ごとやめるものと、本番実績のない新規開発の二つだけだ。アドオン削減を議論から計算に移すための記事。
SAPの年間保守料に見合う価値が出ない原因、標準機能の更新に追従できない体制
保守料が無駄になるのは、更新を取り込む工程が社内にないからだ。追従を止めるのはアドオンではなく、回帰テストの量である。テストを資産化し、適用時期を年次で固定し、役割を分ける進め方を示す。
SAPの帳票・レポート要件を絞る手順、標準で出す・作る・廃止するの3分類
帳票要件の絞り込みは利用頻度でなく、どの意思決定に誰がいつ使うかで切る。3分類のうち、プロジェクトの成否を左右するのは廃止できた本数だ。作ると決めたものをどう絞るかも含めて整理する。
クリーンコアの進め方、アドオンを減らす判断を経理の要件から考える
アドオンを減らせと言われたが、どれを残してよいのか決められない。そういう経理と情シスの責任者に向けて、クリーンコアの意味、SAPが示す拡張の区分、会計の帳票と仕訳で標準に寄せる範囲の決め方を整理する。
SAPアドオンの要否をFit-to-Standardで判定する手順と3つの判断基準
アドオンの要望が次々に上がり、どこで止めればよいか迷う人へ。業務固有性・標準代替可能性・保守コストの3軸で決定木を作れば、判断を議論でなく手順にできる。移行後の保守負債を防ぐ実務基準を示す。