Özel Yazılım Teklifi Karşılaştırma: Neler Değerlendirilmeli?

Özel yazılım teklifi karşılaştırma sürecinde teklifleri aynı kapsam ve varsayımlar üzerinden değerlendirin; toplam bedelin yanında teslimatları, entegrasyonları, testleri ve destek koşullarını da inceleyin. Böylece ilk bakışta uygun görünen ancak ihtiyaç duyulan işleri kapsam dışında bırakan teklifleri ayırt edebilirsiniz.

Özellikle satış, satın alma, bayi ve tedarikçi süreçleri birden fazla sistemi veya kullanıcı grubunu etkiliyorsa, teklifin iş akışlarını nasıl ele aldığını anlamak önemlidir. Aşağıdaki başlıklar, seçenekleri somut ve karar vermeyi kolaylaştıran ölçütlerle yan yana koymanıza yardımcı olur.

Özel yazılım teklifi karşılaştırma: Önce kapsamı nasıl eşitlersiniz?

Farklı tedarikçilerden gelen teklifler, aynı ihtiyaca yanıt veriyor gibi görünse de birbirinden farklı varsayımlar içerebilir. Bir teklif analiz, tasarım ve geliştirmeyi kapsarken diğeri yalnızca belirli ekranların hazırlanmasını ele alabilir. Bu nedenle ilk adım, teklifleri okumadan önce kurumun çözmesini beklediği problemleri ve iş kapsamını yazılı hâle getirmektir.

İş kapsamını kullanıcı grupları, süreçler ve beklenen sonuçlar üzerinden tanımlayın. Örneğin bir ticaret sistemi değerlendiriyorsanız satış, satın alma, bayi işlemleri ve tedarikçi etkileşimlerini ayrı ayrı belirtin. Her sürecin başlangıç koşulunu, temel adımlarını, istisnalarını ve tamamlanma ölçütünü tarif etmek; tekliflerde hangi işlerin yer aldığını görmeyi kolaylaştırır.

Her tedarikçiden dahil olan işleri, hariç tutulan işleri ve teklifin dayandığı varsayımları ayrı başlıklarla açıklamasını isteyin. “Gerektiğinde yapılır” veya “sonradan netleşir” gibi ifadeler belirsizliği ortadan kaldırmaz. Bu tür maddeleri soru listesine alın ve yanıtları karar dosyanıza ekleyin.

• Kullanıcı ve rol grupları: Sistemi kimlerin, hangi yetkilerle kullanacağı.
• Süreç kapsamı: Hangi iş akışlarının teslimata dahil olduğu ve nelerin kapsam dışında kaldığı.
• Kabul ölçütleri: Bir işlevin tamamlanmış sayılması için hangi sonucun gösterilmesi gerektiği.
• Varsayımlar ve bağımlılıklar: Kurumdan, başka bir tedarikçiden veya mevcut sistemlerden beklenen girdiler.

Teklifte hangi teslimatlar ve aşamalar açıkça yazılmalı?

Yalnızca “yazılım geliştirilecektir” ifadesi, projenin nasıl ilerleyeceğini veya kurumun hangi çıktıları teslim alacağını anlatmaya yetmez. Teklifte analiz, tasarım, geliştirme, test, canlıya geçiş ve sonrasındaki destek gibi aşamalar ayrı ayrı açıklanmalıdır. Her aşamanın çıktısı, kurumun katılımı ve onay noktası anlaşılır olmalıdır.

Teslimat listesinde işlevsel tanımların yanı sıra teknik dokümantasyon, kullanıcı veya yönetici eğitimleri ve devreye alma hazırlıkları gibi ihtiyaçları da kontrol edin. Bu unsurların her projede aynı biçimde gerekli olması beklenmez; önemli olan, kurumunuz için gerekenlerin teklif içinde açıkça karşılanıp karşılanmadığını görmektir.

Takvim değerlendirmesinde yalnız başlangıç ve bitiş tarihine değil, ara teslimatlara ve karar bağımlılıklarına bakın. Kurumun veri sağlaması, süreç sahiplerinin geri bildirim vermesi veya başka bir sistemin erişim sunması gecikmeleri etkileyebilir. Teklif, bu sorumlulukları ve gecikme durumunda izlenecek iletişim yolunu tarif etmelidir.

• Aşama — hangi çıktının üretileceği — kurumdan beklenen onay veya katkı.
• Test ve kabul — kimlerin hangi senaryoları deneyeceği — hata ve eksiklerin nasıl kayıt altına alınacağı.
• Canlıya geçiş — hazırlık adımları ve sorumlular — geçiş sonrası izleme ve destek yaklaşımı.

Teknik yaklaşım, entegrasyon ve veri yönetimi nasıl kıyaslanır?

Teknik teklifleri yalnız kullanılan araçların isimlerine göre sıralamayın. Daha yararlı soru, önerilen yaklaşımın kurumun mevcut sistemleriyle, veri akışlarıyla ve gelecekteki değişiklik ihtiyaçlarıyla nasıl uyum kurduğudur. Tedarikçiden mimari tercihlerini iş gereksinimleriyle ilişkilendirmesini ve kararların hangi varsayımlara dayandığını açıklamasını isteyin.

Entegrasyon başlığında sistem adlarını listelemekle yetinmeyin. Hangi verinin hangi yönde aktarılacağı, aktarımın hangi koşulda gerçekleşeceği, başarısız işlemlerin nasıl fark edileceği ve hataların kim tarafından ele alınacağı net olmalıdır. Mevcut sistemlerin teknik dokümantasyonu veya erişimi henüz sağlanmadıysa, bunun teklif ve takvim üzerindeki etkisini ayrıca sorun.

Veri taşıma gündemdeyse kaynak verinin kalitesi, eşleştirme kuralları, deneme aktarımı ve doğrulama sorumluluğunu değerlendirin. Teklifte bu konuların bulunmaması, veri taşımanın otomatik olarak dahil olduğu anlamına gelmez. Güvenlik ve erişim yönetiminde de roller, yetkilendirme yaklaşımı, kayıtların tutulması ve sorumluluk sınırları açıkça konuşulmalıdır.

• Entegrasyon — veri yönü, sıklık veya tetikleyici, hata halinde izlenecek yol.
• Veri taşıma — hangi kayıtların aktarılacağı, temizleme ihtiyacı ve doğrulama sorumluluğu.
• Güvenlik — kullanıcı yetkileri, erişim süreçleri ve kurumla tedarikçi arasındaki görev paylaşımı.
• Teknik sürdürülebilirlik — değişikliklerin nasıl ele alınacağı ve kararların nasıl belgeleneceği.

Teklifleri karşılaştırmak için hangi adımları izlemelisiniz?

Kararı yalnız toplantı izlenimine veya teklif dosyasının uzunluğuna bırakmamak için ortak bir değerlendirme süreci kullanın. Her tedarikçiye aynı gereksinimleri ve açıklama sorularını yöneltmek, cevapları daha adil biçimde karşılaştırmanızı sağlar. Değerlendirmeyi ilgili iş birimlerinin, teknik ekibin ve satın alma sorumlularının katkısıyla yürütmek de farklı risklerin erken görülmesine yardımcı olur.

• 1. Gereksinimleri sabitleyin: Öncelikli iş akışlarını, kullanıcıları, entegrasyonları ve kabul koşullarını tek bir dokümanda toplayın.
• 2. Teklifleri aynı şablona aktarın: Her gereksinim için dahil, hariç, belirsiz veya ek bilgi gerekli durumunu işaretleyin.
• 3. Açıklama alın: Belirsiz kapsamları, varsayımları, kurum sorumluluklarını ve olası ek işleri yazılı olarak sorun.
• 4. Teknik ve operasyonel riski değerlendirin: Entegrasyon, veri, güvenlik, bakım ve değişiklik yönetimini ayrı ayrı inceleyin.
• 5. Toplam yükü karşılaştırın: Başlangıç çalışmasının yanında lisans, barındırma, destek, kurum içi emek ve olası değişiklik kalemlerinin nasıl ele alındığını netleştirin.
• 6. Kararı kaydedin: Seçim gerekçesini, kabul edilen riskleri ve sonraki adımları paydaşlarla birlikte belgeleyin.

Bakım, değişiklik ve toplam sahip olma yükü nasıl değerlendirilir?

Bir yazılım çözümünün değerlendirmesi teslimat gününde bitmez. Kullanıcıların destek alacağı kanal, hata bildiriminin nasıl ele alınacağı, bakımın hangi işleri kapsadığı ve yeni taleplerin nasıl önceliklendirileceği teklif içinde veya sözleşme eklerinde açıklanmalıdır. “Bakım dahildir” gibi genel ifadeler yerine kapsamı ve sınırları sorun.

Yeni bir ihtiyaç ortaya çıktığında bunun hata düzeltmesi mi, mevcut kapsamın tamamlanması mı yoksa yeni geliştirme mi sayılacağını önceden konuşun. Talebin nasıl kaydedileceği, etkisinin ve tahmini iş yükünün nasıl değerlendirileceği, onay vermeye kimin yetkili olduğu belirgin olmalıdır. Böylece proje sırasında beklentiler ile sözleşmedeki işler arasındaki fark daha erken görünür.

Toplam sahip olma yükünü değerlendirirken yalnız tedarikçiye ödenecek bedeli düşünmeyin. Kurumun süreç sahiplerinden, bilgi işlem ekibinden ve kullanıcılardan beklenen zamanı; veri hazırlama ve test sorumluluklarını; devam eden hizmetlerin koşullarını da hesaba katın. Teklifler arasında karşılaştırmayı sağlıklı kılmak için her kalemin hangi varsayıma dayandığını yazılı olarak teyit edin.

Özel ticaret sistemi hangi durumda uygun, hangi durumda değil?

Özel geliştirme, satış, satın alma, bayi veya tedarikçi süreçleri standart bir paketin sunduğu işleyişe sığmadığında ya da süreçler arasında kuruma özgü bağlantılar gerektiğinde değerlendirmeye değer olabilir. Burada belirleyici olan, farklılaşan iş akışlarının gerçekten iş ihtiyacı olması ve teklifin bu ihtiyacı anlaşılır bir kapsamla karşılamasıdır. Özel yazılım seçimi, her kurum için otomatik olarak en doğru seçenek değildir.

Süreçler yaygın ve görece standartsa, hazır bir ürünün mevcut işleyişe uyarlanması daha basit bir seçenek olabilir. İhtiyaç henüz netleşmemişse veya kurum süreçlerini değiştirmeye açıksa, önce süreçleri sadeleştirmek ve hazır çözümleri değerlendirmek daha uygun olabilir. Özel geliştirmede kapsamı, bakım sorumluluğunu ve değişikliklerin nasıl yönetileceğini üstlenmeye kurumun hazır olup olmadığını da hesaba katın.

KMK'nın doğrulanmış ürün bilgisine göre Kuruma Özel Ticaret Sistemleri, standart paketlere sığmayan satış, satın alma, bayi ve tedarikçi süreçleri için KMK Core üzerinde geliştirilen bir ticaret sistemidir. Bu yaklaşımın kurumunuzun gereksinimleriyle nasıl eşleştiğini incelerken kuruma özel ticaret sistemlerinin kapsamına bakabilir; değerlendirmeyi kendi süreç ve kabul ölçütleriniz üzerinden yapabilirsiniz.

• Özel geliştirmeyi değerlendirin — süreçler kurumun işleyişine özgü ve standart pakete uyarlama ihtiyacı belirginse.
• Hazır çözümü değerlendirin — ihtiyaçlar standart işlevlerle karşılanabiliyor ve uyarlama sınırlı kalıyorsa.
• Önce süreçleri netleştirin — gereksinimler, roller veya karar sahipleri henüz belirlenmemişse.

Karar öncesi hangi soruların yanıtını almalısınız?

Son değerlendirme toplantısında teklifleri aynı sorularla sınamak, eksik bilgi nedeniyle oluşabilecek yanlış kıyaslamaları azaltır. Yanıtların sözlü kalmaması için önemli açıklamaları revize edilmiş teklif, kapsam dokümanı veya sözleşme eki içinde görmeyi isteyin. Özellikle kapsam dışı işler ile kurumun yükümlülükleri, proje başladıktan sonra anlaşmazlığa dönüşebilecek alanlardır.

• Teklifte belirtilen her önemli işlev için hangi teslimat ve kabul ölçütü tanımlanıyor?
• Hangi entegrasyon, veri aktarımı, test veya eğitim işleri dahil değil?
• Kurumdan hangi ekiplerin ne zaman katkı vermesi bekleniyor?
• Yeni taleplerin kapsam, takvim ve bedel etkisi nasıl hesaplanıp onaylanacak?
• Canlı kullanım sonrasında destek, bakım ve hata bildirimi için süreç nasıl işleyecek?
• Teknik kararlar ve kurumun verileri üzerindeki sorumluluklar nasıl belgelenecek?

Sağlıklı bir özel yazılım teklifi karşılaştırması; ortak gereksinimlere dayanan, kapsamı ve varsayımları görünür kılan bir değerlendirmedir. Teknik yaklaşımın yanı sıra teslimatları, kurumun sorumluluklarını, devam eden bakım yükünü ve değişiklik sürecini birlikte inceleyin.

Ticaret sistemleriyle ilgili daha fazla içerik için kurumsal ticaret sistemleri yazılarını inceleyebilir, kendi teklif değerlendirmenizde aynı ölçütleri kullanabilirsiniz.

Sık Sorulan Sorular