Size teklif edilen sistemin doğru sistem olup olmadığını bilmeniz mi gerekiyor?

Para bağlanmadan önce mimarinin, maliyetin ve tedarikçi tekliflerinin incelenmesi. Bağımsız, somut ve yazılı.

Problem

Kendinden emin bir mimari diyagramı, bir fiyat ve bir takvimle bir teklif gelir; onaylaması gerekenler doğru olup olmadığını anlayamaz. Tedarikçi yalan söylemiyordur ama yanıtlamayı bildiği soruyu yanıtlıyordur. Yaygın sonuçlar problemden üç kat büyük bir sistem, tam iş büyüdüğünde pahalılaşan bir lisans modeli ya da zor kısmın sonra halledileceğini sessizce varsayan bir tasarımdır.

Nasıl yaklaşıyoruz

Teklifi soyut en iyi uygulamalara karşı değil, çözmesi beklenen probleme karşı okuruz. Rakamları kontrol ederiz: kullanıcılar, veri, iş hacmi, beş yıllık maliyet. Yazılmamış varsayımları kontrol ederiz. Bir şey yanlışsa neyin neden yanlış olduğunu ve yerine ne istenmesi gerektiğini söyleriz. Teklif iyiyse onu da söyleriz. Değer, kusur bulmakta değil net bir yanıttadır.

İşlenmiş örnek

Bir teklif incelendi, kapsam yarıya indi

Bir lojistik şirketinin elinde beş yıl boyunca 40 tesis için fiyatlandırılmış bir depo yönetim sistemi teklifi vardı. Altı tesisleri vardı ve gerisi için somut bir plan yoktu. Mimariyi ve lisans koşullarını inceledik; maliyetin üçte ikisinin sözleşme bitmeden kullanmayacakları kapasiteyi satın aldığını ve asıl önemli kısım olan muhasebe sistemiyle entegrasyonun fiyatı verilmemiş sonraki bir aşama olarak listelendiğini gördük. Yeniden düzenlenen kapsam altı tesisi kapsadı, önce entegrasyonu fiyatlandırdı ve genişleme için bir seçenek bıraktı. Tedarikçi aynı kaldı. Sözleşme yaklaşık yarı boyutundaydı.

Ne alırsınız

  • Teklifin gerçek probleminize ve sayılarınıza göre yazılı incelemesi
  • Somut risklerin, boşlukların ve fiyatlandırılmamış varsayımların listesi
  • Tedarikçiye götürülecek somut sorular ve değişiklikler
  • Üzerine hareket edebileceğiniz bir öneri, teklif edildiği gibi ilerlemek olsa bile
Probleminizi anlatın