Yazılım Satın Alma Bütçesinde Lisans, Kullanıcı ve Veri Taşıma Maliyetleri Nasıl Hesaplanır?

Yazılım satın alma toplam maliyeti neden önemlidir?

Yazılım satın alma toplam maliyeti, çözümün yalnızca satın alındığı gün ödenen bedeli değil, işletmede kullanılabilir durumda tutulması için gereken yaşam döngüsü giderlerini gösterir. İlk teklif düşük görünse bile kullanıcı artışı, yeni modüller, entegrasyonlar veya yenileme koşulları sonraki dönemlerde bütçe üzerinde önemli bir etki oluşturabilir. Bu nedenle değerlendirme, başlangıç fiyatından çok toplam sahip olma maliyetine odaklanmalıdır.

İlk fiyat ile gerçek bütçe arasındaki fark

Satın alma ekibi öncelikle hangi zaman aralığını karşılaştıracağını belirlemelidir. Aynı dönem kullanılmadan yıllık abonelik modeli ile tek seferlik lisans modelini doğrudan karşılaştırmak yanıltıcı olabilir. Benzer biçimde kurumsal yazılım maliyetini belirleyen unsurlar incelenirken geliştirme veya lisans bedelinin yanında işletme, bakım ve değişiklik ihtiyaçları da dikkate alınmalıdır.

• İlk lisans veya abonelik bedeli
• Kurulum ve uygulama çalışmaları
• Kullanıcı ve yetkilendirme giderleri
• Veri taşıma ve veri hazırlığı
• Entegrasyon ve ek modüller
• Eğitim, bakım ve destek
• Barındırma ve altyapı
• Yenileme ve kapasite artışları

Fiyat ödediğiniz şeydir; değer ise elde ettiğiniz şeydir. - Benjamin Graham

Lisans modeli ve kullanıcı sayısı maliyeti nasıl değiştirir?

Lisans modeli ve kullanıcı sayısı, yazılım bütçesini çözümün fiyatlandırma yöntemine göre farklı biçimlerde etkiler. Bazı sistemler kullanıcı başına, bazıları kullanıcı paketi, aktif kullanıcı, eş zamanlı kullanıcı, işlem hacmi veya kurumsal lisans üzerinden fiyatlandırılabilir. Bu nedenle yalnızca bugünkü çalışan sayısını değil, yazılımı gerçekten kullanacak rolleri ve beklenen büyümeyi tanımlamak gerekir.

Kullanıcı rolleri teklif öncesinde nasıl sınıflandırılmalı?

Her çalışanın aynı lisans seviyesine ihtiyacı olmayabilir. Yönetici, operasyon kullanıcısı, saha personeli, raporlama kullanıcısı ve yalnızca görüntüleme yetkisine sahip hesaplar farklı lisans koşullarına tabi olabilir. Kullanıcı başına yazılım ücreti değerlendiriliyorsa sağlayıcıdan hangi rolün hangi lisans tipine karşılık geldiği ve kullanıcı sayısı arttığında birim fiyatlandırmanın nasıl değişeceği açıkça istenmelidir.

• Aktif kullanıcı sayısını belirleyin
• Kullanıcıları yetki rollerine ayırın
• Salt görüntüleme hesaplarını ayrıca tanımlayın
• Dış kullanıcı ve müşteri hesaplarını belirtin
• Beklenen kullanıcı artışını paylaşın
• Minimum lisans paketini sorun
• Pasif kullanıcıların ücretlendirilmesini netleştirin

Veri taşıma ve temizleme maliyeti nasıl hesaplanmalıdır?

Yazılım veri taşıma maliyeti yalnızca eski sistemdeki kayıtların yeni sisteme kopyalanmasından ibaret değildir. Veri kaynaklarının sayısı, formatları, kayıt kalitesi, eşleştirme kuralları, tekrar eden veriler, eksik alanlar ve doğrulama gereksinimleri çalışmanın kapsamını belirler. Veri hazırlığı belirsiz bırakıldığında hem proje bütçesi hem de geçiş takvimi öngörülenden farklılaşabilir.

Taşıma hizmeti teklife dahil edilmeli mi?

Veri taşıma gerekiyorsa kapsam ve sorumlulukların teklifte ayrı bir kalem olarak tanımlanması yararlıdır. Özellikle eski sistemden veri taşımanın ne zaman planlanacağı proje başlangıcında netleştirildiğinde kaynak sistemlerin hazırlanması, test aktarımı ve kabul süreci daha yönetilebilir hale gelir. Sağlayıcı ile müşteri ekibinin veri temizliğindeki sorumlulukları da ayrılmalıdır.

• Kaynak sistemlerin ve dosyaların sayısı
• Taşınacak kayıtların kapsamı
• Veri temizliği sorumluluğu
• Alan eşleştirme kuralları
• Test aktarımı gereksinimi
• Doğrulama ve kabul yöntemi
• Arşiv verisinin kapsamı
• Geçiş sonrası eski sisteme erişim

Tek seferlik ve yinelenen yazılım giderleri nelerdir?

Tek seferlik giderler çoğunlukla kurulum, yapılandırma, ilk veri taşıma, geliştirme ve başlangıç eğitimleri gibi proje başlangıcına bağlı çalışmalardır; yinelenen giderler ise abonelik, lisans yenileme, barındırma, bakım, destek veya kullanım hacmine bağlı servisleri kapsayabilir. Teklifte bu iki grubun açıkça ayrılması, sonraki dönem bütçelerinin daha doğru hazırlanmasını sağlar.

Yazılım uygulama bütçesi hangi dönem için hazırlanmalı?

Karşılaştırma yapılırken tüm sağlayıcılar için aynı değerlendirme dönemi kullanılmalıdır. Böylece ilk yıl yüksek kurulum bedeli fakat farklı yenileme modeli bulunan bir çözüm ile başlangıç bedeli düşük ancak yinelenen maliyetleri farklı olan başka bir çözüm aynı çerçevede değerlendirilebilir. Teklifin ödeme takvimi ile maliyetin niteliği aynı şey değildir; taksitli ödenen bir kurulum hizmeti yine tek seferlik gider olabilir.

• Kurulum ve başlangıç yapılandırması
• Özel geliştirme çalışmaları
• İlk veri taşıma hizmetleri
• Periyodik lisans veya abonelik
• Barındırma ve altyapı hizmetleri
• Bakım ve teknik destek
• Üçüncü taraf servis ücretleri
• Sözleşme yenileme giderleri

Entegrasyon ve ek modüller bütçeye nasıl eklenmelidir?

Entegrasyon ve ek modüller, ana yazılım lisansından bağımsız fiyatlandırılabildiği için toplam bütçede ayrı değerlendirilmelidir. ERP, CRM, muhasebe, e-ticaret, ödeme, kimlik doğrulama veya üçüncü taraf servislerle veri alışverişi gerekiyorsa yalnızca bağlantının geliştirilmesi değil, API erişimi, test, bakım ve gelecekteki değişiklik sorumlulukları da kapsamlandırılmalıdır.

Entegrasyon maliyetinde hangi kapsam soruları sorulmalı?

ERP ve CRM entegrasyonlarının planlanmasında veri akışının yönü, senkronizasyon sıklığı, hata yönetimi ve sistemlerin sahipliği teknik kapsamı doğrudan etkiler. Hazır bir konektör bulunması da entegrasyonun tüm yaşam döngüsü boyunca ek maliyet oluşturmayacağı anlamına gelmez. Sağlayıcıdan başlangıç entegrasyonu ile sonraki bakım sorumluluğunu ayrı göstermesi istenmelidir.

• Bağlanacak sistemlerin sayısı
• API veya konektör lisansları
• Tek veya çift yönlü veri akışı
• Senkronizasyon sıklığı
• Test ve hata yönetimi
• Ek modül lisansları
• Üçüncü taraf servis giderleri
• Entegrasyon bakım sorumluluğu

Eğitim, bakım ve destek bedeli nasıl değerlendirilmelidir?

Yazılım eğitim ve destek bedeli, sistemin işletme içinde sürdürülebilir biçimde kullanılabilmesi için toplam maliyet hesabına dahil edilmelidir. İlk eğitim paketi yeterli görünse bile yeni çalışanların sisteme katılması, yönetici eğitimleri, dokümantasyon, destek talepleri ve sürüm değişiklikleri ilerleyen dönemlerde ek hizmet ihtiyacı doğurabilir. Bu nedenle destek kapsamı yalnızca ücret olarak değil, hizmet sınırlarıyla birlikte incelenmelidir.

Destek paketinde hangi koşullar açık olmalı?

Teklifte hangi destek kanallarının bulunduğu, hangi hizmetlerin standart pakete dahil olduğu ve hangi çalışmaların ayrıca ücretlendirileceği belirtilmelidir. Bakım ile destek de aynı kavram olarak değerlendirilmemelidir. Bakım yazılımın teknik sürekliliğine odaklanırken destek kullanıcıların operasyonel sorunlarını kapsayabilir. Güncelleme, hata düzeltme ve yeni özellik taleplerinin hangi kategoriye girdiği sözleşmede açıklanmalıdır.

• Başlangıç kullanıcı eğitimi
• Yönetici ve sistem sorumlusu eğitimi
• Dokümantasyon ve eğitim materyalleri
• Destek kanalları ve kapsamı
• Bakım hizmetinin sınırları
• Güncelleme politikasının kapsamı
• Yeni çalışan eğitimleri
• Ek geliştirme taleplerinin yöntemi

Kullanıcı ve modül artışı nasıl fiyatlandırılmalıdır?

Kullanıcı veya modül artışının fiyatlandırması satın alma aşamasında tanımlanmalıdır; çünkü işletmenin bugünkü ihtiyacına göre hazırlanan teklif gelecekteki kullanım seviyesini temsil etmeyebilir. Kullanıcı sayısının, işlem hacminin veya departman kapsamının artması durumunda hangi fiyatlama kuralının uygulanacağı bilinirse yazılım yenileme maliyeti daha öngörülebilir biçimde bütçelenebilir.

Büyüme senaryosu neden satın alma teklifine eklenmeli?

Satın alma ekibi sağlayıcıdan yalnızca mevcut kullanım için fiyat istemek yerine birkaç operasyonel senaryo tanımlayabilir. Yeni departmanların sisteme eklenmesi, ek modül açılması veya işlem hacminin yükselmesi halinde uygulanacak ticari koşullar böylece önceden görülebilir. Proje sırasında kapsam değişiklikleri bekleniyorsa değişiklik taleplerinin bütçeye nasıl yansıtılacağı da teklif ve sözleşme aşamasında netleştirilmelidir.

• Ek kullanıcı birim fiyatı
• Kullanıcı paketlerinin sınırları
• Yeni modül aktivasyon koşulları
• İşlem veya depolama kotaları
• Yeni şirket veya şube kullanımı
• Yükseltme ve paket değişikliği
• Kapsam değişikliği yöntemi
• Yenileme dönemindeki fiyatlama kuralı

Karşılaştırılabilir toplam maliyet teklifi nasıl istenir?

Karşılaştırılabilir bir yazılım satın alma teklifi almak için tüm sağlayıcılara aynı kullanıcı, veri, entegrasyon, modül, destek ve büyüme varsayımları verilmelidir. Farklı kapsamlarla hazırlanan teklifler yalnızca toplam rakam üzerinden karşılaştırıldığında hangi çözümün hangi hizmetleri içerdiği anlaşılamaz. Bu nedenle teklif talebinin amacı tek bir fiyat almak değil, maliyet kalemlerini ve sorumlulukları ortak bir yapıda görünür hale getirmektir.

Sağlayıcıya hangi bilgiler gönderilmelidir?

Mevcut sistemlerin, veri kaynaklarının, kullanıcı rollerinin, entegrasyonların ve beklenen büyümenin kısa bir envanteri hazırlanabilir. Sağlayıcı seçiminde yalnızca maliyet değil, teknik kapsam ve teslim sorumlulukları da değerlendirilmelidir; bu nedenle kurumsal yazılım firması seçerken değerlendirilecek kriterler teklif karşılaştırmasının tamamlayıcı parçasıdır. Ayrıca sözleşme sonunda veri dışa aktarma biçimi, veri teslimi ve olası çıkış maliyetleri önceden sorulmalıdır.

• Mevcut ve beklenen kullanıcı sayısını paylaşın
• Kullanıcı rollerini ve yetkileri tanımlayın
• Taşınacak veri kaynaklarını listeleyin
• Gerekli entegrasyonları belirtin
• Tek seferlik giderleri ayrı isteyin
• Yinelenen giderleri dönemleriyle isteyin
• Yenileme ve büyüme koşullarını sorun
• Veri dışa aktarma koşullarını netleştirin