Yazilim
Yapay Zekâ Sohbeti ile Doğrulanmış Çözümlerini Bulun ve Hizmet Alın

SAAS Yazilim nedir?

Yazilim kategorisi; iş süreçlerini dijitalleştiren, çoğu zaman internet üzerinden kullanılan ve genellikle abonelikle sunulan bulut tabanlı uygulamalar (SaaS) ile yazılım sağlayıcılarını kapsar. Bu araçlar; ekiplerin aynı veriye erişmesini, iş akışlarını otomatikleştirmesini ve ölçülebilir şekilde çalışmasını hedefler.

Bu kategoride seçim yapmak çoğu zaman “özellik listesi”nden çok; toplam maliyet, entegrasyon, veri taşınabilirliği, güvenlik ve destek gibi karar kriterlerine bağlıdır. Karşılaştırma, doğru aracı hızlı elemek için önemlidir.

• CRM ve satış otomasyonu
• Pazarlama otomasyonu ve e-posta pazarlama
• Müşteri destek / helpdesk ve canlı sohbet
• Proje ve iş yönetimi (task, roadmap)
• Ürün analitiği ve event tracking
• BI, raporlama ve veri görselleştirme
• Finans, faturalama ve abonelik yönetimi
• İK, işe alım (ATS) ve performans yönetimi
• Dokümantasyon, bilgi tabanı ve wiki
• E-imza, sözleşme ve doküman yönetimi
• Kimlik ve erişim yönetimi (SSO, kullanıcı yönetimi)
• Entegrasyon/iPaaS ve otomasyon (workflow)

Bu kategoriyi genellikle kurucular, ürün ekipleri ve pazarlama ekipleri satın alır. Amaç; dağınık araçları azaltmak, ekipler arası görünürlüğü artırmak, manuel işleri otomatikleştirmek ve ölçümleme/raporlama ile karar kalitesini yükseltmektir.

Common use cases for Yazilim

• Lead’leri tek yerde toplayıp satış hunisini aşama aşama yönetmek.
• Web ve uygulama event’lerini izleyip ürün aktivasyonunu ölçmek.
• E-posta kampanyalarını segmentlere göre tetiklemek ve sonuçları raporlamak.
• Destek taleplerini etiketleyip SLA takibi yapmak ve bilgi tabanı ile azaltmak.
• Ürün roadmap’ini, sprint’leri ve görev bağımlılıklarını ekipçe yönetmek.
• Faturalama, abonelik yenileme ve ödeme hatalarını otomatikleştirmek.
• Onboarding akışlarını (checklist, e-posta, görev) standardize etmek.
• Dokümanları tek yerde sürümleyip erişim izinleriyle paylaşmak.
• Raporları farklı kaynaklardan çekip tek panelde birleştirmek.
• SSO ile kullanıcı girişlerini merkezileştirip erişim yönetimini kolaylaştırmak.
• Entegrasyonlarla (CRM–support–billing) veri tekrarını azaltmak.
• Uyumluluk gereği log, saklama ve silme süreçlerini izlenebilir hale getirmek.

How to choose Yazilim

• Temel ihtiyaç uyumu: Hangi 3–5 kritik iş akışını karşılıyor, hangilerini dışarıda bırakıyor kontrol edin. Neden önemli: “%80 uyum” çoğu zaman toplam maliyeti düşürür. Quick test: “İlk 30 günde hangi 3 çıktıyı alırsak ‘başarılı’ sayılır ve bunu ürün içinde nasıl ölçeriz?”
• Toplam maliyet (TCO): Lisans + eklentiler + kullanım aşımı + entegrasyon + kurulum maliyetini sorun. Neden önemli: Ucuz görünen plan büyüdükçe pahalılaşabilir. Quick test: “12 ayda X kullanıcı ve Y kullanımda toplam fatura kalemleri neler olur?”
• Entegrasyon yüzeyi: Hazır entegrasyonlar, API kapsamı, webhooks, veri senkron sıklığına bakın. Neden önemli: Veri adaları oluşmasını engeller. Quick test: “Şu 2 sistemi (ör. CRM + destek) çift yönlü senkronlayabilir miyiz, hangi alanlar destekleniyor?”
• Veri dışa aktarma ve taşınabilirlik: Export formatları (CSV/JSON), tam veri dökümü, ek dosyalar ve ilişkilendirmeler dahil mi kontrol edin. Neden önemli: Kilitlenme riskini azaltır. Quick test: “Hesabı kapatsak tüm veriyi ne kadar sürede ve hangi formatta alırız?”
• Güvenlik temel kontrolleri: RBAC, SSO/SAML, MFA, audit log, IP kısıtı gibi kontrolleri doğrulayın. Neden önemli: Erişim hataları veri sızıntısı riskidir. Quick test: “Rol bazlı izinlerde ‘okuma/yazma/silme’ ayrımı ve admin logları var mı?”
• Uyumluluk ve veri işleme (EU): DPA, alt işleyenler (sub-processors), veri konumu ve aktarım mekanizmalarını sorun. Neden önemli: GDPR yükümlülükleri ve tedarikçi riski. Quick test: “Veri işleyen olarak hangi amaçlarla veri işliyorsunuz ve alt işleyen listeniz nerede yayınlı?”
• Limitler ve plan kısıtları: Kullanıcı, event, depolama, API rate limit, proje sayısı gibi limitleri inceleyin. Neden önemli: Beklenmedik tıkanmalar olur. Quick test: “Bu planın ‘adil kullanım’ veya gizli limitleri var mı, aşım olursa ne olur?”
• Raporlama ve denetlenebilirlik: Raporların doğruluğu, filtreler, dışa aktarma, audit trail var mı bakın. Neden önemli: Karar kalitesi ve iç denetim. Quick test: “Bir kayıt kim tarafından ne zaman değiştirildiğini tek ekranda görebilir miyiz?”
• Destek ve operasyonel süreçler: Destek kanalları, yanıt süreleri, acil durum prosedürü ve statü sayfasını kontrol edin. Neden önemli: Üretimde kesinti maliyetlidir. Quick test: “P1 bir kesintide hedef yanıt süreniz nedir ve nasıl eskale edilir?”
• Uygulama/kurulum süresi: Kurulum adımları, gerekli kaynaklar, eğitim ihtiyacı ve başarı kriterlerini netleştirin. Neden önemli: Zaman kaybı fırsat maliyetidir. Quick test: “Bizden hangi roller kaç saat ayırmalı ve ilk değeri ne zaman görürüz?”
• Ürün yol haritası ve değişiklik yönetimi: Sürüm notları, geriye dönük uyumluluk ve deprecations politikasını sorun. Neden önemli: Entegrasyonlar kırılabilir. Quick test: “API/özellik kaldırımlarını kaç gün önceden duyuruyorsunuz?”
• Satın alma ve sözleşme esnekliği: Aylık/ yıllık, iptal, yenileme ve fiyat artışı maddelerini okuyun. Neden önemli: Kilitlenme ve bütçe riski. Quick test: “Yenilemede fiyat artışı nasıl belirlenir ve iptal için bildirim süresi nedir?”

Red flags and deal-breakers

• Fiyat sayfası net değil ve toplam maliyet sadece satış görüşmesinde ortaya çıkıyor.
• Veri dışa aktarma kısıtlı; tam export için ek ücret veya destek talebi gerekiyor.
• Audit log yok ya da sadece “enterprise” planda, temel izlenebilirlik sağlanmıyor.
• SSO/SAML sadece en üst pakette; ekip büyüdükçe güvenlik maliyeti artıyor.
• Veri saklama ve silme politikası belirsiz; “ne zaman silinir” net değil.
• Alt işleyenler listesi yayınlanmıyor veya değişiklik bildirim süreci yok.
• Uptime/incident geçmişi için statü sayfası veya olay raporu paylaşılmıyor.
• API çok sınırlı; temel nesnelere erişim yok veya rate limit aşırı düşük.
• Entegrasyonlar tek yönlü; veri tutarlılığı için manuel iş gerekiyor.
• Rol ve izin sistemi kaba; hassas aksiyonlar için ayrı yetki yok.
• Destek yalnızca e-posta ve belirsiz sürelerde; acil eskalasyon yok.
• Sözleşmede otomatik yenileme ve kısa iptal penceresi var; açıkça belirtilmiyor.
• Veri taşımada yardımcı olmuyor; migration araçları/dokümantasyon zayıf.
• Ürün içinde “kullanım limiti” uyarıları yok; aşım faturası sürpriz oluyor.

Best-fit guidance by buyer type

• Startup
  • Priorities: Hızlı kurulum, makul başlangıç maliyeti, temel entegrasyonlar, esnek aylık plan.
  • Avoid: Uzun yıllık taahhüt, karmaşık kurulum, kritik özelliklerin eklenti olarak satılması.
  • Onboarding expectations: 1–2 haftada canlıya çıkış; şablonlar ve self-serve dokümantasyon.
• SMB
  • Priorities: İzin yönetimi, raporlama, ekipler arası iş akışı, destek erişilebilirliği.
  • Avoid: Limitlerin belirsiz olduğu planlar, entegrasyonların kırılgan olması.
  • Onboarding expectations: 2–6 haftada kurulum; veri aktarımı ve temel eğitim oturumları.
• Enterprise
  • Priorities: SSO/SAML, audit log, RBAC, DPA ve güvenlik dokümanları, SLA, ölçeklenebilir API.
  • Avoid: Güvenlik kontrollerinin eksikliği, belirsiz veri işleme şartları, zayıf değişiklik yönetimi.
  • Onboarding expectations: 1–3 ay; güvenlik değerlendirmesi, pilot, kademeli rollout, yönetişim.

• Self-serve / PLG satın alma
  • Priorities: Ücretsiz deneme, net fiyatlandırma, ürün içi rehberlik, hızlı entegrasyon.
  • Avoid: Demo zorunluluğu, fiyatın gizli olması, denemede kritik özelliklerin kapalı olması.
  • Onboarding expectations: Aynı gün kurulum; 1–2 sprint içinde ölçülebilir sonuç.
• Sales-led procurement
  • Priorities: Güvenlik paketi, sözleşme esnekliği, POC planı, referans süreçleri ve SLA.
  • Avoid: Sözleşmede tek taraflı fiyat artışı, belirsiz yenileme koşulları.
  • Onboarding expectations: POC + değerlendirme; paydaş onaylarıyla aşamalı geçiş.

• Regulated ortamlar
  • Priorities: Denetlenebilirlik, veri saklama/silme, erişim kontrolleri, olay yönetimi, DPA.
  • Avoid: Log yokluğu, veri konumu belirsizliği, alt işleyen şeffaflığının olmaması.
  • Onboarding expectations: Güvenlik incelemesi, dokümantasyon, kontrollü pilot ve onaylı süreçler.
• Non-regulated ortamlar
  • Priorities: Hız, kullanım kolaylığı, entegrasyon, maliyet kontrolü.
  • Avoid: Gereksiz kurumsal karmaşıklık, düşük benimsenme riski.
  • Onboarding expectations: Self-serve kurulum; hafif süreçlerle hızlı iterasyon.

Pricing and contract literacy

Yazılım ürünlerinde fiyatlandırma çoğunlukla birkaç modele dayanır. Koltuk başı (per seat) modelinde aktif kullanıcı sayısı maliyeti belirler; rol bazlı fiyat farkları olabilir. Kullanım bazlı (usage-based) modelde event, API çağrısı, mesaj, depolama veya işlem adedi gibi metrikler faturalandırılır. Kademeli planlar (tiered) ise özellik ve limitleri paketlere böler; çoğu zaman entegrasyon, güvenlik ve raporlama üst paketlere taşınır.

Sözleşmelerde add-on (ek modül), minimum taahhüt, aşım (overage) ücretleri ve “adil kullanım” maddeleri kritik olur. Aylık plan esneklik sağlar; yıllık plan genellikle birim fiyatı düşürür ama iptal ve bütçe riskini artırabilir. Yenileme koşullarında otomatik yenileme, iptal bildirim süresi ve fiyat artışı maddeleri net olmalıdır.

• Bu planın fiyatı hangi metriklerle artar (kullanıcı, kullanım, depolama)?
• Eklenti olarak satılan zorunlu özellikler var mı (SSO, audit log, API erişimi)?
• Limit aşımında ne olur: durdurma mı, otomatik yükseltme mi, aşım ücreti mi?
• Yıllık sözleşmede iptal ve iade koşulları nedir?
• Otomatik yenileme var mı, iptal için kaç gün önce bildirim gerekir?
• Fiyat artışı maddesi nasıl çalışır (yenilemede, kullanım artınca, enflasyon vb.)?
• Veri ihracı ve hesap kapatma sürecinde ücret var mı?
• Destek seviyesi hangi planda, SLA ayrı mı?

Checklist before annual commitment

• Deneme/POC için yazılı başarı kriterleri belirledik (ör. 3 ölçülebilir çıktı).
• Kritik iş akışlarımızı uçtan uca test ettik (gerçek veriyle, gerçek kullanıcıyla).
• Toplam maliyeti (lisans + eklenti + aşım + entegrasyon) 12 ay için çıkardık.
• Veri sahipliği ve tam dışa aktarma seçenekleri net (format, kapsam, süre).
• Hesap kapatma sonrası veri saklama ve silme süresi yazılı olarak açık.
• Gerekli entegrasyonlar çalışıyor (en az 2 kritik sistem) ve senkron mantığı net.
• API limitleri, webhook’lar ve hata senaryoları test edildi.
• Admin kontrolleri yeterli (RBAC, kullanıcı yaşam döngüsü, erişim devri).
• SSO/MFA ihtiyacımız varsa plan dahilinde ve uygulanabilir.
• Audit log ve raporlama ihtiyaçlarımız karşılanıyor; dışa aktarma mümkün.
• Güvenlik dokümanları paylaşıldı (genel güvenlik özeti, olay yönetimi yaklaşımı).
• DPA ve alt işleyenler listesi incelendi; değişiklik bildirim süreci net.
• Destek kanalları, yanıt süreleri ve eskalasyon yolu netleştirildi.
• SLA gerekiyorsa kapsamı ve istisnaları okundu.
• Geçiş/migrasyon eforu tahmin edildi (veri temizliği, alan eşleştirme, eğitim).
• İç paydaşlar (ürün, pazarlama, IT/güvenlik) onay verdi.

Security and compliance essentials

• Şifreleme: Aktarım sırasında (in transit) ve depoda (at rest) şifreleme yaklaşımını doğrulayın.
• RBAC: Rol bazlı erişim; en az ayrı admin rolleri ve hassas aksiyon izinleri arayın.
• Audit logs: Girişler, izin değişiklikleri, veri silme/dışa aktarma gibi olaylar loglanmalı.
• SSO/SAML: Kurumsal giriş ve merkezi kullanıcı yönetimi için destek olup olmadığını kontrol edin.
• MFA: Zorunlu MFA ve/veya adminler için ek kontroller mevcut olmalı.
• Yedekleme ve geri yükleme: Yedekleme sıklığı ve geri yükleme yaklaşımı sorulmalı.
• Olay müdahalesi: Güvenlik olayı bildirim süreci ve iletişim kanalı net olmalı.
• Veri saklama: Varsayılan saklama süreleri ve müşterinin yönetebileceği ayarlar olmalı.
• Silme: Silme talebi sonrası sistemlerden gerçekten silinme ve zaman çizelgesi açıklanmalı.
• Erişim kontrolleri: IP kısıtı, cihaz politikaları veya oturum süreleri gibi ek kontroller (varsa) değerlendirilmelidir.

EU bağlamında, GDPR kapsamında tarafların rolünü netleştirmek önemlidir: siz genellikle data controller, SaaS sağlayıcısı ise çoğunlukla data processor olur. Genel (hukuki olmayan) yaklaşım: DPA/security addendum içinde işleme amaçları, alt işleyenler, veri aktarımı, saklama/silme, olay bildirimi ve denetim/şeffaflık maddelerinin açık yazıldığını doğrulayın.

Trusted / Verified provider policy (what “Verified” means)

“Verified” rozeti; bir sağlayıcının temel kimlik ve şeffaflık kontrollerinden geçtiğini gösteren bir işarettir. Bu rozet, ürünün ihtiyaçlarınıza kesin uyacağını veya sıfır risk olduğunu garanti etmez.

• Kimlik ve şirket varlığı: Sağlayıcının yasal şirket bilgileri ve iletişim kanalları doğrulanabilir olmalı.
• Kamusal ayak izi: Resmi web sitesi, dokümantasyon, fiyatlandırma veya plan bilgileri gibi kamusal kaynaklar incelenir.
• Politika şeffaflığı: Gizlilik politikası, güvenlik sayfası ve veri işleme yaklaşımı erişilebilir olmalı.
• Destek erişilebilirliği: Destek kanalları ve temel destek süreci (en azından nasıl iletişime geçileceği) net olmalı.
• Ürün netliği: Ürünün ne yaptığı, temel kullanım senaryoları ve limitler anlaşılır şekilde açıklanmalı.
• Yanıt verebilirlik: Sağlayıcı, doğrulama sorularına makul sürede yanıt vermeli.
• Yeniden kontrol: Bilgiler periyodik olarak ve önemli değişiklik sinyallerinde (alan adı, politika güncellemesi, iletişim değişikliği) tekrar kontrol edilir.
• Rozetin garanti etmedikleri: Performans, uptime, güvenlik olayı yaşanmayacağı, uyumluluk onayı veya her ekip için “en iyi” seçim olduğu garanti edilmez.

Use-case entry points

• CRM seçimi

  Pipeline yönetimi, lead kaynakları ve satış raporlaması için doğru veri modelini arıyorsanız.

• Pazarlama otomasyonu

  Segment bazlı kampanya, tetikleyici akışlar ve ölçümleme kurmak istiyorsanız.

• Ürün analitiği

  Activation, retention ve feature adoption metriklerini event düzeyinde izlemek istiyorsanız.

• Müşteri destek sistemi

  Ticket triage, SLA takibi ve self-serve bilgi tabanı ile yükü azaltmak istiyorsanız.

• Proje ve sprint yönetimi

  Backlog, sprint planlama ve bağımlılıkları tek yerde yönetmek istiyorsanız.

• Faturalama ve abonelik

  Yenileme, proration ve ödeme hatalarını daha az manuel işlemle yönetmek istiyorsanız.

• Dokümantasyon ve wiki

  Ürün, süreç ve teknik bilgiyi sürümleyip erişim kontrollü paylaşmak istiyorsanız.

• E-imza ve sözleşme akışı

  Sözleşme hazırlama, onay ve imza süreçlerini izlenebilir hale getirmek istiyorsanız.

• SSO ve erişim yönetimi

  Kullanıcı yaşam döngüsünü merkezileştirip güvenliği standardize etmek istiyorsanız.

• Entegrasyon ve otomasyon

  Uygulamalar arası veri akışını kod yazmadan veya minimum kodla kurmak istiyorsanız.

How Bilarna shortlists providers (transparency)

Bilarna gibi bir karşılaştırma/keşif sayfasında kısa liste oluşturmanın amacı; yüzlerce seçeneği “en çok uyan birkaç adaya” indirmektir. Bu süreçte önce gereksinimler netleştirilir, sonra araçlar aynı çerçevede karşılaştırılır.

Kısa liste genellikle şu girdilerle şekillenir: kullanım senaryosu, ekip büyüklüğü, bütçe aralığı, EU veri/uyumluluk beklentisi, gerekli entegrasyonlar, canlıya çıkış zaman çizelgesi ve kilit kısıtlar (SSO zorunluluğu, audit log ihtiyacı, veri ihracı gibi).

• Kullanılan girdiler: İhtiyaç listesi, mevcut sistemler, entegrasyon öncelikleri, güvenlik gereksinimleri, satın alma modeli (aylık/yıllık), zaman planı.
• Hariç tutulanlar: İhtiyaçla ilgisiz ürün kategorileri, temel güvenlik/şeffaflık bilgisi bulunmayan sağlayıcılar, kritik entegrasyonları karşılamayan seçenekler.
• Takip soruları: “Hangi veriler işlenecek?”, “Kimler admin olacak?”, “Hangi raporlar şart?”, “Çıkış planı nedir?” gibi sorular kısa listeyi daraltır.
• Karşılaştırma yaklaşımı: Özellikten önce iş akışı uyumu, TCO, entegrasyon, veri taşınabilirliği, güvenlik ve destek kriterleriyle eleme yapılır.

Implementation and migration considerations

• Veri temizliği: Eski sistemdeki mükerrer kayıtlar ve alan karmaşası migrasyonun en büyük gecikme nedenidir.
• Alan eşleştirme: “Kaynak alan → hedef alan” haritasını yazılı hale getirin; özel alanlar kritik olabilir.
• Rollout planı: Tüm ekibe bir anda açmak yerine pilot ekip ve kademeli geçiş planlayın.
• Eğitim ve sahiplik: Admin sahipleri, süreç sahipleri ve destek sorumluları net olmalı.
• Geri dönüş planı: Canlıya geçişte sorun olursa hangi tarihe kadar geri dönebileceğinizi belirleyin.
• Ölçümleme: Başarı kriterlerini ürün içinde veya raporda ölçebileceğiniz şekilde kurun.

Key integrations to plan for

• Kimlik: SSO sağlayıcısı (SAML/OIDC) ve kullanıcı provizyonlama (SCIM varsa).
• İletişim: E-posta, takvim ve takım mesajlaşma araçları (bildirim ve otomasyon için).
• Veri: Veri ambarı/BI veya en azından düzenli export akışı.
• CRM / Support / Billing: Müşteri yaşam döngüsü verisinin tutarlı kalması için temel üçlü entegrasyon.
• Web ve ürün izleme: Event şeması, UTM standardı ve kimlik eşleştirme (anonymous → user).
• Otomasyon: Webhook/iPaaS ile hata toleransı, yeniden deneme ve loglama.

Glossary of common terms

• SaaS: İnternet üzerinden kullanılan, genellikle abonelikle sunulan yazılım.
• TCO: Toplam sahip olma maliyeti; lisansın ötesindeki tüm maliyetler dahil.
• RBAC: Rol bazlı erişim kontrolü; kullanıcıların yetkilerini role göre sınırlar.
• SSO: Tek oturum açma; merkezi kimlikle birden çok uygulamaya giriş.
• SAML: Kurumsal SSO’da sık kullanılan kimlik doğrulama standardı.
• MFA: Çok faktörlü kimlik doğrulama; giriş güvenliğini artırır.
• Audit log: Kim, neyi, ne zaman yaptı kaydı; denetim ve güvenlik için kritik.
• DPA: Veri işleme sözleşmesi; GDPR kapsamında controller-processor şartlarını düzenler.
• Sub-processor: Sağlayıcının hizmet sunarken kullandığı alt hizmet sağlayıcılar.
• Overage: Plan limitini aşınca oluşan ek ücret.
• Lock-in: Veriyi/iş akışını taşımayı zorlaştıran bağımlılık ve çıkış maliyeti.