プロジェクト管理

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

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

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

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

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

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

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

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