Sabit fiyat mı, adam/gün mü? ERP proje sözleşmesinde fiyatlama modeli

ERP projesinin teklif aşamasında en çok konuşulan rakam toplam bedeldir, oysa projenin nasıl biteceğini büyük ölçüde bedelin nasıl hesaplandığı belirler. Aynı kapsam için bir satıcı sabit fiyat verir, bir diğeri adam/gün birim fiyatıyla tahmini bir aralık sunar. İki teklif yan yana konduğunda ilki "daha güvenli", ikincisi "daha esnek" görünür. İkisi de yarım doğrudur.

Bu yazıda iki modeli, yani sabit fiyatlı ve zaman-malzeme (adam/gün) bazlı sözleşmeyi tarafsız biçimde karşılaştırıyoruz. Amaç bir modeli övmek değil, hangisinin sizin projenize ne zaman uyduğunu görmenizi sağlamak.

İki modelin gerçekte neyi paylaştırdığı

Fiyatlama modeli aslında bir risk dağıtımıdır. Soru şudur: kapsam büyürse, tahmin yanlış çıkarsa ya da iş beklenenden uzun sürerse fazladan maliyeti kim taşıyacak?

• Sabit fiyat: Kapsam yazılı ve kapalıdır. Belirlenen işi belirlenen bedelle teslim etmek satıcının sorumluluğundadır. Süre uzarsa maliyet genellikle satıcıya, kapsam değişirse maliyet size yazılır.
• Adam/gün bazlı: Harcanan efor kadar ödersiniz. Süre ve kapsam belirsizliği büyük ölçüde sizin tarafınızdadır; karşılığında kapsamı proje sırasında yeniden şekillendirme özgürlüğünüz olur.

Hiçbir model riski ortadan kaldırmaz, yalnızca yerini değiştirir. Sabit fiyatta risk kapsam tanımı sırasında, adam/gün modelinde proje yönetimi sırasında birikir.

Sabit fiyat ne zaman mantıklı

Sabit fiyat, kapsamın gerçekten yazılabildiği işlerde işe yarar. Standart bir finans ve stok kurulumu, tanımlı sayıda kullanıcı, sınırlı sayıda rapor ve belli bir veri aktarımı hacmi böyle bir kapsamdır. Daha önce benzer kurulum yapmış bir uygulama ortağı bu iş için sağlıklı bir tahmin üretebilir.

Avantajları açıktır: bütçe önceden bellidir, yönetim kurulu onayı kolaylaşır, satıcı verimli çalışmak için teşvik görür. Dezavantajı ise daha az görünür. Satıcı fiyatı tutturmak zorunda olduğu için kapsam dışı kalan her şeyi değişiklik talebi olarak yazar. Proje ilerledikçe her küçük istek tartışma konusuna dönüşebilir. Bazı satıcılar belirsizliğe karşı fiyata tampon da ekler; bunu teklifte göremezsiniz.

Sabit fiyatlı teklifte kapsam belgesine şu soruların cevabı yazılı olmalıdır:

1. Hangi süreçler ve hangi modüller kapsamda?
2. Veri aktarımında kaç kalem, hangi kalite seviyesinde temizlenmiş veri varsayılıyor?
3. Eğitim kaç oturum, kimlere?
4. Rapor ve çıktı formları kaç adet?
5. Kabul kriterleri nedir, kim ne zaman onaylar?

Kapsam belgesi gereksinim analizinden çıkmalıdır. Hazır bir listeniz yoksa önce ihtiyaç analizi ve gereksinim listesi rehberine bakın; kapsamı yazılı hale getirmeden sabit fiyat istemek, bulanık bir işe kesin rakam istemek anlamına gelir.

Adam/gün bazlı model ne zaman mantıklı

Kapsamın başta net olmadığı, süreçlerin proje içinde keşfedildiği işlerde adam/gün modeli daha dürüst bir başlangıçtır. Üretimde sipariş bazlı ağaç yapıları, birden fazla şirketin konsolidasyonu, eski sistemden karmaşık veri taşıma ya da yoğun entegrasyon bu tür işlerdir. Üretim sektöründeki ERP ihtiyaçları çoğu zaman bu gruba girer.

Bu modelin güçlü yanı esnekliktir: önceliği değişirse ekibi yeniden yönlendirebilirsiniz ve her değişiklik için pazarlık yapmazsınız. Zayıf yanı denetimdir. Birim fiyat düşük görünse de toplam efor kontrolsüz büyüyebilir. Satıcının hızlı bitirmek için güçlü bir teşviki yoktur.

Bu riski yönetmek için şu önlemler işe yarar:

• Aylık ya da aşama bazlı bir tavan bütçe belirleyin; tavana yaklaşıldığında yazılı onay istensin.
• Zaman çizelgelerini haftalık olarak, kim ne üzerinde kaç saat çalıştı şeklinde paylaşmalarını isteyin.
• Birim fiyatın hangi rol için geçerli olduğunu yazın; kıdemli danışman ve genç danışman aynı fiyatla faturalanmasın.
• Seyahat, konaklama ve ek eğitim giderlerinin ayrı mı dahil mi olduğunu açıklığa kavuşturun.

Karma model: sabit çerçeve, değişken kalem

Pratikte en sık kullanılan çözüm ikisini birleştirmektir. Projeyi aşamalara ayırırsınız: keşif ve analiz adam/gün ile yapılır, çıkan kapsam üzerine kuruluma ait kalemler sabit fiyatlanır, kapsam dışı talepler ise önceden kararlaştırılmış birim fiyatla eklenir.

Bu yapının mantığı basittir. Belirsizliğin en yüksek olduğu ilk aşamada eforu açıkça ödersiniz, kapsam netleşince risk transferi anlamlı hale gelir. Keşif aşaması sonunda taraflardan birinin projeden çıkabilmesi de iyi bir güvencedir. Bu çıkış hakkı sözleşmede yoksa ekleyin. Sözleşme maddelerini toplu görmek için ERP sözleşmesi imzalamadan önce kontrol listesine göz atabilirsiniz.

Varsayımsal bir örnek: aynı iş, iki teklif

Rakamlar tamamen örnekleme amaçlıdır, gerçek bir fiyat değildir. Orta ölçekli bir ticaret firması için iki teklif geldiğini düşünün. A ortağı kapsamı kapalı tutup sabit bedel veriyor. B ortağı 100 adam/gün tahmin edip günlük birim fiyat üzerinden fatura kesmeyi öneriyor.

Proje sırasında firma iki yeni ihtiyaç keşfediyor: bir bayi iskonto yapısı ve bir depo transfer onay akışı. A ortağında bu iki talep değişiklik formuna dönüşür, her biri ayrıca fiyatlanır ve onay beklerken takvim durur. B ortağında talepler aynı gün planlanır ama toplam efor tahmini aşar; tavan bütçe tanımlanmadıysa fatura tahminin üzerine çıkar.

Hangi tarafın "kazandığı" kapsamın ne kadar doğru yazıldığına bağlıdır. Kapsam başta iyi tanımlanmışsa A ortağı daha ucuza ve daha az sürtüşmeyle bitirir. Kapsam sonradan çok değişiyorsa B ortağının esnekliği değerli hale gelir. Bu yüzden önce kapsamın ne kadar oturmuş olduğunu dürüstçe değerlendirin, fiyat modelini ondan sonra seçin.

Sözleşmede fiyat modeline bağlı olarak aranacak maddeler

Hangi modeli seçerseniz seçin, şu başlıklar yazılı olmalı:

• Değişiklik yönetimi: Kapsam değişikliği nasıl talep edilir, kim onaylar, fiyatlandırma nasıl yapılır, yanıt süresi nedir?
• Ödeme planı: Ödemeler takvime mi, teslim edilen aşamaya mı bağlı? Aşama kabulü ödeme koşulu olarak yazılmış mı?
• Kabul kriterleri: Bir aşamanın bittiği hangi testle ve kimin imzasıyla kabul edilir?
• Gecikme sorumluluğu: Süre aşımı kimin kaynaklı ise bunun maliyeti kime yazılır?
• Ekip değişikliği: Teklifte adı geçen kıdemli danışmanın proje boyunca yer alması taahhüt ediliyor mu?
• Canlıya geçiş sonrası destek: Hata düzeltme ve ilk haftalardaki destek fiyata dahil mi, ayrıca mı?

Karar tablosu

Teklifleri karşılaştırırken sık yapılan hatalar

Yalnızca toplam bedele bakmak. Sabit fiyatlı bir teklifin içinde ne olmadığına bakmadan düşük bedeli kazanmak, değişiklik taleplerinde farkın geri ödenmesine yol açabilir. TCO ve gizli kalemler rehberi bu açıdan okunmaya değer.

Birim fiyatı düşük diye adam/gün teklifini ucuz saymak. Düşük birim fiyat, daha az deneyimli ekip ya da daha uzun süre anlamına gelebilir. Karşılaştırmayı toplam tahmini efor ve ekip yapısı üzerinden yapın.

Uyarlama kalemini ihmal etmek. Standart ürünün dışına çıkan her geliştirme kapsam riskini artırır. Hangi uyarlamaların sabit fiyata dahil olduğunu netleştirmek için standart mı uyarlama mı yazımıza bakın.

Proje liderliğini düşünmemek. Hangi model seçilirse seçilsin, kapsamı ve değişiklikleri izleyecek bir sorumlu gerekir. Bunu iç ekibin mi, dış danışmanın mı üstleneceği ayrı bir karardır; bu karar çerçevesini ayrıca ele aldık.

Ürüne ve ortağa göre değişen pratik

Fiyatlama modeli yalnızca ürüne değil, uygulama ortağına da bağlıdır. SAP Business One, Microsoft Dynamics 365 Business Central, Odoo ya da Logo Tiger gibi ürünler iş ortakları kanalıyla uygulanır ve teklif yapısı ortaktan ortağa farklılaşır. Aynı ürünü iki ortak, biri sabit biri adam/gün olarak teklif edebilir. Bu nedenle teklifleri ürün bazında değil, ortak ve model bazında kıyaslayın. Yerli ve yabancı ürünlerin genel farkları için yerli ve global ERP karşılaştırması sayfası da yardımcı olur. Güncel fiyat ve çalışma şekli için ilgili iş ortağından yazılı teklif alın.

Hangi modelin projenize uyduğundan emin değilseniz, önce Uygun ERP bul aracıyla aday listenizi daraltabilir, ardından keşif formu üzerinden bağımsız bir değerlendirme isteyebilirsiniz.