3. Kriterler tek tek: neden önemli, ne sorulur, hangi kanıt kabul edilir
1. Mevzuat parametrelerinin güncelliği ve bunun kanıtı
Önerilen ağırlık: 5 / 5
Neden önemli: Asgari ücret, SGK prime esas kazanç alt-üst sınırı, gelir vergisi tarifesi ve kıdem tazminatı tavanı yılda en az bir, çoğu zaman iki kez değişir. Parametre bayat kalırsa hata tek bir bordroda kalmaz: tüm kadroya, aynı anda ve geriye dönük düzeltme gerektirecek biçimde yayılır.
Sorulacak soru: “Şu anda hangi parametre setini kullanıyorsunuz ve son mevzuat değişikliğini sisteme hangi tarihte uyguladınız?”
Kabul edilebilir kanıt: Yayımlanmış bir parametre listesi ya da güncelleme günlüğü: her satırda değerin kendisi, yasal dayanağı, yürürlük tarihi ve değişikliğin sistemde uygulandığı tarih. Üçüncü tarih olmadan "güncel" kelimesi ölçülemez.
Sık yapılan hata: "Mevzuata tam uyumluyuz" cümlesini kanıt saymak. Bu cümle her satıcının sitesinde yazar; ölçülebilir olan cümle değil, tarihtir.
2. Hesabın kalem kalem doğrulanabilmesi
Önerilen ağırlık: 5 / 5
Neden önemli: Bordro bir sonuç değil, bir gerekçedir. Çalışan "bu ay neden az yattı" diye sorduğunda kalem kalem gösterilemeyen hesap savunulamaz; iş mahkemesinde de savunulamaz.
Sorulacak soru: “Tek bir çalışanın bordrosunda SGK matrahı, kümülatif gelir vergisi matrahı, uygulanan vergi dilimi, asgari ücret istisnası ve damga vergisi ayrı satırlar olarak görünüyor mu?”
Kabul edilebilir kanıt: Örnek bir bordro çıktısı (PDF). Dilim ve istisna satırları görünmüyorsa hesap kapalı kutudur.
Sık yapılan hata: Yalnızca net tutarı gösteren özet ekranla yetinmek; itiraz geldiğinde dökümün olmadığını fark etmek.
3. Türkiye'ye özgü hesap kalemlerinin motorda olması
Önerilen ağırlık: 5 / 5
Neden önemli: Asgari ücret gelir ve damga vergisi istisnası, yıl boyunca kümülatif ilerleyen vergi matrahı, 5510 sayılı Kanun md. 81 işveren teşvikleri, engellilik indirimi, icra ve nafaka kesintisi ile kıdem tazminatı tavanı Türkiye'ye özgüdür. Bunlar raporlama katmanında düzeltilebilecek ayrıntılar değil, hesabın kendisidir.
Sorulacak soru: “Asgari ücret istisnası, kümülatif matrah, işveren teşviki, engellilik indirimi ve icra kesintisi bordroda otomatik uygulanıyor mu; hangi yılın oranlarıyla?”
Kabul edilebilir kanıt: Bu kalemlerin göründüğü örnek bir hesap ve kullanılan oranın hangi yıla ait olduğunun yazılı olması.
Sık yapılan hata: Yurt dışı menşeli bir üründe bu kalemlerin "özelleştirme" veya bir Excel eklentisiyle çözüleceğini varsaymak. Kümülatif matrah, ay ay ilerleyen bir durumdur; yıl ortasında elle düzeltilemez.
4. Kapsam sınırlarının açıkça yazılı olması
Önerilen ağırlık: 4 / 5
Neden önemli: Türkiye'de bir İK yazılımının yapmadığı işler (e-Bildirge gönderimi, muhtasar ve prim hizmet beyannamesi, e-fatura, İŞKUR bildirimleri) genelde satın alma sonrası öğrenilir. Bu işler ortadan kalkmaz; sadece kimin yapacağı belirsiz kalır.
Sorulacak soru: “Hangi resmi bildirimleri siz göndermiyorsunuz? Bu işleri kim yapacak?”
Kabul edilebilir kanıt: Satıcının kendi sitesinde yayımlanmış bir kapsam dışı listesi. Sözlü "hepsi var" cevabı kanıt değildir.
Sık yapılan hata: Demoda sorulmayan soruyu sözleşmeye de yazdırmamak; sonra mali müşavirle yazılım arasında kalmak.
5. PDKS'nin sahada, gerçek koşullarda çalışması
Önerilen ağırlık: 4 / 5
Neden önemli: Giriş-çıkış kaydı ofiste her üründe çalışır. Fark, şantiyede, mağazada, vardiyalı üretimde ve internetin kesildiği anda ortaya çıkar. Puantaj yanlışsa bordro da yanlıştır — hata zincirin en başında oluşur.
Sorulacak soru: “İnternet kesildiğinde giriş-çıkış nasıl kaydediliyor? QR veya konum doğrulaması kötüye kullanıma karşı nasıl korunuyor? Çoklu şube ve vardiya devri nasıl yönetiliyor?”
Kabul edilebilir kanıt: Canlı demo ve ayarların gösterilmesi: QR kodunun geçerlilik süresi, konum toleransı, vardiya devri kuralları.
Sık yapılan hata: Ürünü ofis senaryosunda test edip sahada kullanmak; tek şube üzerinden karar verip çok şubede kurmak.
6. Çalışan self-servisi ve mobil erişim
Önerilen ağırlık: 4 / 5
Neden önemli: İK ekibinin zamanının büyük kısmını hesaplama değil, tekrarlayan sorular alır: "izin bakiyem ne kadar", "bordromu alabilir miyim", "avans talebim ne oldu". Bu yükü ancak çalışanın kendi ekranı azaltır.
Sorulacak soru: “Çalışan izin talebini, bordrosunu, avansını, masrafını ve puantajını İK'ya sormadan kendi telefonundan görebiliyor ve yürütebiliyor mu?”
Kabul edilebilir kanıt: Uygulama mağazasındaki güncel sürüm tarihi ve bir demo hesabı. Sürüm tarihi eski bir mobil uygulama, terk edilmiş bir mobil uygulamadır.
Sık yapılan hata: Yalnızca yönetici panelini beğenip çalışan tarafını hiç denememek. Yazılımın gerçek tasarrufu çalışan tarafında oluşur.
7. Veri taşınabilirliği ve çıkış planı
Önerilen ağırlık: 5 / 5
Neden önemli: Bugün sorulmayan tek soru, üç yıl sonra en pahalı soru olur: buradan nasıl çıkarım? Özlük dosyaları, kıdem tarihleri ve izin bakiyeleri taşınamıyorsa yazılım değiştirmek fiilen imkânsız hâle gelir.
Sorulacak soru: “Sözleşme sona ererse verimi hangi formatta, ne kadar sürede ve hangi ücretle alırım? Özlük belgeleri ve yüklenen dosyalar da dahil mi?”
Kabul edilebilir kanıt: Sözleşmede yazılı bir veri iade maddesi, örnek bir dışa aktarım dosyası ve varsa kamuya açık API dokümanı.
Sık yapılan hata: Girişi kolay, çıkışı imkânsız bir sistemi "kurulumu çok kolay" diye seçmek.
8. KVKK uyumu ve veri işleme sözleşmesi
Önerilen ağırlık: 5 / 5
Neden önemli: İK verisi, KVKK'nın en hassas veri kümelerinden birini içerir: kimlik, sağlık raporu, ücret, banka bilgisi, aile durumu. Yazılım sağlayıcısı bu veride veri işleyendir; aranızdaki ilişkinin yazılı olması gerekir.
Sorulacak soru: “Veri işleyen sıfatıyla imzaladığınız sözleşme metnini önceden görebilir miyim? Alt işleyenler kimler ve veriler fiziksel olarak nerede saklanıyor?”
Kabul edilebilir kanıt: Kamuya açık bir veri işleme sözleşmesi metni, alt işleyen listesi ve veri saklama yeri bilgisi.
Sık yapılan hata: "KVKK uyumluyuz" ifadesini yeterli saymak; sözleşme imzalanmadan gerçek personel verisini sisteme yüklemek.
9. Kimin neyi göreceğinin ayarlanabilmesi
Önerilen ağırlık: 4 / 5
Neden önemli: İzin onaylayan bir departman yöneticisinin tüm kadronun maaşını görmesi bir yazılım tercihi değil, bir veri sızıntısıdır. Yetki modülden modüle ayrışabilmelidir.
Sorulacak soru: “Bordroyu hiç görmeden izin onaylayabilen bir rol tanımlayabilir miyim? Yetki, modül bazında "görüntüleme" ve "yönetme" olarak ayrılıyor mu?”
Kabul edilebilir kanıt: Yetki matrisi ekranının demoda gösterilmesi ve bir kullanıcıya sınırlı yetki verilerek denenmesi.
Sık yapılan hata: Tek bir "yönetici" rolüyle başlayıp, tüm ücret verisini yönetici olan herkese açmak.
10. Muhasebe aktarımı ve API
Önerilen ağırlık: 3 / 5
Neden önemli: Bordro çıktısının muhasebeye elle girilmesi, otomasyonun kazandırdığı zamanı geri alır. Ayrıca ileride kuracağınız her entegrasyonun ön koşulu, dokümante edilmiş bir arayüzün varlığıdır.
Sorulacak soru: “Muhasebe programına aktarım hangi formatta yapılıyor? Genel amaçlı bir API var mı ve dokümantasyonu kamuya açık mı?”
Kabul edilebilir kanıt: Kamuya açık API dokümanı: kimlik doğrulama yöntemi, uç listesi, hata kodları. Doküman yoksa entegrasyon bir proje, bir özellik değildir.
Sık yapılan hata: "Entegrasyon yapılabilir" cümlesini var olan bir entegrasyon saymak.
11. Fiyatın öngörülebilir olması
Önerilen ağırlık: 4 / 5
Neden önemli: Aylık lisans, toplam maliyetin yalnızca bir parçasıdır. Kurulum, veri aktarımı, eğitim, ek modül ve destek ayrı ayrı ücretlendirilebilir; çalışan sayısı arttığında fiyatın nasıl davranacağı çoğu zaman hiç sorulmaz.
Sorulacak soru: “Fiyat kullanıcı başına mı, modül başına mı? Kurulum, eğitim, veri aktarımı ve destek ayrı ücretli mi? Yıl içinde çalışan sayım artarsa ne olur, azalırsa düşer mi?”
Kabul edilebilir kanıt: Kamuya açık bir fiyat sayfası ya da tüm kalemleri içeren yazılı teklif. Sözlü fiyat, teklif değildir.
Sık yapılan hata: Yalnızca aylık lisans rakamlarını karşılaştırmak; toplam sahip olma maliyetini (aşağıdaki kalem listesi) hiç hesaplamamak.
12. Destek: kim, hangi kanal, ne kadar sürede
Önerilen ağırlık: 3 / 5
Neden önemli: Bordro kapanışı tarihli bir iştir. O gün bir hata çıkarsa "yarın döneriz" cevabı, ücret ödemesinin gecikmesi demektir.
Sorulacak soru: “Bordro kapanış gününde bir sorun olursa kime, hangi kanaldan ulaşırım ve yanıt süresi taahhüdünüz nedir?”
Kabul edilebilir kanıt: Yazılı destek saatleri veya hizmet seviyesi taahhüdü; ölçülebilir bir süre. Taahhüt yayımlanmamışsa bunu bilerek karar vermek de bir seçimdir.
Sık yapılan hata: Satış görüşmesindeki yanıt hızını destek hızı sanmak.
13. Mevcut veriyle başlama (geçiş maliyeti)
Önerilen ağırlık: 4 / 5
Neden önemli: Yazılım değiştirmenin gerçek maliyeti lisans değil, geçiştir. Kıdem tarihleri, izin devir bakiyeleri ve yıl içinde birikmiş kümülatif vergi matrahı taşınmazsa yeni sistem ilk günden yanlış hesaplar.
Sorulacak soru: “Mevcut personel listesi, işe giriş tarihleri, izin devir bakiyeleri ve yıl içi kümülatif vergi matrahı nasıl aktarılır? Devir bakiyesi elle girilebiliyor mu?”
Kabul edilebilir kanıt: Aktarım şablonu veya içe aktarma ekranı; izin devir bakiyesi ve kümülatif matrah alanlarının gösterilmesi.
Sık yapılan hata: Yılın ortasında geçip kümülatif gelir vergisi matrahını taşımamak. Bu hata yıl sonunda toplu vergi farkı olarak geri döner.
14. Ürünün gerçekten yaşadığının kanıtı
Önerilen ağırlık: 3 / 5
Neden önemli: Bir İK yazılımı, mevzuat değiştiği için sürekli bakım isteyen bir üründür. Geliştirilmeyen ürün, bir sonraki asgari ücret zammında sizi yalnız bırakır.
Sorulacak soru: “Son altı ayda hangi özellikler yayınlandı? Değişiklik günlüğü tutuyor musunuz?”
Kabul edilebilir kanıt: Tarihli sürüm veya değişiklik notları; mobil uygulamanın mağazadaki son güncelleme tarihi; mevzuat değişikliklerinin ne zaman uygulandığının kaydı.
Sık yapılan hata: Ekran görüntüsü galerisine ve tanıtım videosuna bakıp ürünün canlı olduğunu varsaymak.