《ステップ・バイ・ステップガイド》
システムに問題があれば「交渉」も必要
アドバイザー佐野：あ、そういえば、今週はいよいよ在庫・受注システムとファイルサーバのサービスインじゃないですか！
PM：そういえば、じゃなくて一番肝心なところですよ。幾多の難関を乗り越えて、今日が最終受け入れ検査です。運用テスト中に操作性について、いくつか小さな仕様変更をしました。今日はこれからその立会い検査があります。
アドバイザー佐野：要件定義で決定した機能が、正しく実現されているかの、最終的な受入れテストですね。
PM：はい。問題なければ、この変更点などを含む最終版の成果物ドキュメントを受け取り、受領印を押すだけです。
アドバイザー佐野：このように、「成果物すべての内容（機能）・数量を確認し、点検して受け入れる」作業のことを、検収といいます。検収を受けると、システムインテグレータは契約内容に従って請求書を発行します。そしてこの請求書を元にA社は支払いを行ないます。
PM：もし、ぜんぜん気に入らないシステムであっても、検収してしまえば請求書どおり払わなければいけないということですか？
アドバイザー佐野：ええ、そうです。反対に、重箱の隅をつつくような些細な問題のために検収の引き伸ばしをすれば、サービスインに影響を与えるだけではなく、システムインテグレータとの関係も悪くなりかねません。
PM：では、もしも受入れのタイミングで問題が発生した場合はどうしたらいいのでしょうか？ 気に入らないものにお金は払えないし、かといってサービスインを遅らせるのは業務への影響が大きいし……どちらも大事です。
アドバイザー佐野：受け入れがたい重大な問題であれば、もちろん検収する必要はありません。しかし、その問題が、システムの運用そのものに与える影響が小さいものならば、「その問題が解決するまで、その機能については支払いを保留する」「稼動後、今回のプロジェクトの支払い範囲内で修正する」といった、「交渉」をぜひしてください。程度にもよりますが、あくまでも問題のない部分については支払う、という条件付きであれば、システムインテグレータ側も検討する余地があるはずです。
PM：ふぅむ。検収は実際にお金を動かす引き金、いつどんなときに引くか、タイミングを見誤らないように気をつけなければいけないということですね。
さて、次週はいよいよ最終回です。安定稼動のために購入検討すべき各種オプションサービス、また、今回のプロジェクトを振り返り、次回のシステムへどう生かしていくべきかを考えてみましょう。 |
|---|
 |
||||
 |
 |
 |
|
 |
 |
||||
佐野 央の「社内システム導入を成功させる方法」トップへ
【アスキービジネス 新刊ムック】
【ASCII.jp SaaS・ASP】