先に結論各工程の実施・承認・相談先を一枚で確認し、担当者不在でも止まらない形にします。
社内が決める業務ルールを明確にする
計算、締め、承認、保存期間、顧客統合などは業務責任者が確認します。開発会社へ現行Excelだけ渡して推測させません。
現場スタッフは例外と操作負担、管理者は集計と権限、経営側は目的と優先順位を確認します。代表者一人の意見だけで完成としません。
開発会社の成果物と責任範囲を決める
要件、画面、ソース、試験結果、移行手順、運用資料のどこまで含むかを契約前に確認します。口頭説明だけを成果物にしません。
外部サービス、サーバー、ドメイン、メール等の障害で誰が一次対応するかを分けます。営業時間と緊急連絡の条件も明記します。
試験と受入を共同で行う
開発側は自動・異常系・複数端末を確認し、社内側は実際の業務シナリオと数字を確認します。架空データで安全に例外も試します。
受入基準は『動いた』だけでなく、件数、重要合計、権限、入力時間、出力、通信失敗を含めます。未解決項目を記録して公開判断します。
運用後の変更窓口を残す
問い合わせ、要望、不具合、権限申請を分類し、社内窓口と開発窓口を決めます。すべてを担当者個人のチャットへ送りません。
担当交代時は仕様、アカウント、バックアップ、変更履歴を引き継ぎます。内製化する部分も権限とレビューを用意します。
相談前にそろえるもの
- 業務判断者
- 成果物・責任範囲
- 共同受入基準
- 障害・問い合わせ窓口
- 担当交代・内製レビュー
全部そろっていなくても構いません。分かる範囲を確認し、業務ルールや金額に関わる部分は担当者と一緒に決めます。