得手分野を持ったベンダー

得手分野を持ったベンダー


あるお客様の話です。
そのお客様は、基幹系システムの全面更改を検討しておりました。

私は、その検討段階からプロジェクトに参画したのですが、提案依頼書(RFP)を取りまとめ終わった段階で、どのベンダーに声を掛けるかを協議。
諸般の事情により、それほど期間を掛けられない

当然ながら、青天井で予算を組むこともできない

そこで当該業種向けの実績があり且つ当該業種向けのパッケージシステムを持っているベンダーに絞って提案をお願いいたしました。

ベンダー確定までの経緯は省略しますが、コスト/期間/品質面でお客様の要望を満たしそうなベンダーを選定し、いざプロジェクトがスタート。

すると、流石に当該業種向けシステムでは定評のあるベンダーだけあって、大した波乱もなく順調な進行。

約半年経過した今、既にテスト稼動まで漕ぎ着けました。

後は、直近に迫った本稼働を待つばかりという、コスト/納期/品質のどれをとっても満足のいく、絵に描いたような成功プロジェクトと思っています。

得意分野を持ったベンダーは、やはり強いですね。

◇◇◇◇◇
しかし、ここに来て少々不安が出始めてます。

プロジェクトの進行やシステムの品質に対する不安ではなく、ベンダー担当者のサポート体制に関する不安です。

他のユーザの仕事が忙しい様で、時折、対応が散漫に感じられるのです。

他のユーザの仕事をすることは何ら問題はないのですが、お客様に不安感を与える対応は如何なものかと言うことです。

それでなくとも、近々基幹系システムが全面更改(本稼働)される段階まで来ているわけですから、お客様としては不安が一杯な状態なのです。

ベンダーとしては、システムを開発・導入することを目標にするのは当たり前でしょうが、教育サポートを充実させ、お客様が安心してシステムを運用できるように指導する事もベンダーの責務と捉えて欲しいものです。

ユーザとしては、システム開発が終了してから始まる『運用』が大切なのですから。

こちらもご覧ください

0 件のコメント:

コメントを投稿

システム設計書

システム設計書 システム開発における設計書。 名前の付け方、内容の記述の仕方、実はこれ、ベンダーによってまちまちなんです。 名前の付け方に関して言えば、外部設計書/内部設計書というベンダーもあれば、基本設計書/詳細設計書というベンダーもあります。 場合によっては...