ERP sözleşmesinde imzadan önce kontrol edilmesi gereken maddeler

Bir ERP projesinde en çok zaman demo ve teklif karşılaştırmasına ayrılır; sözleşme metni genelde son haftaya, bazen hukuk departmanının "standart, sorun yok" onayına sıkışır. Oysa demo aşamasında görülmeyen riskler — yıllık bakım bedelinin nasıl artacağı, destek ekibinin arızaya kaç saatte döneceği, sözleşme bittiğinde verinin hangi formatta teslim edileceği — hep bu metinde yazar. Ürün seçimi kadar, seçilen ürünün hangi koşullarla bağlandığı da işletmenin sonraki üç-beş yılını belirler.

Bu yazı belirli bir vendor'ı ya da hukuk bürosunu önermiyor; sözleşme imzalanmadan önce sorulması gereken sekiz soruyu, hangi maddenin nereye baktığını göstererek sıralıyor.

Lisans kapsamı: kimin, neyi, nasıl kullanacağı net mi

Lisans maddesinin ilk işi, "kullanıcı" tanımını netleştirmek. Named user (isim bazlı) lisansta her kullanıcı ayrı hesapla tanımlanır ve devredilemez; concurrent user (eşzamanlı) modelde ise aynı anda sisteme bağlı kişi sayısı sınırlanır, hesap kimin adına açıldığı önemli değildir. İki model de doğru olabilir ama sözleşmede hangisinin geçerli olduğu, vardiyalı çalışan bir üretim tesisinde ya da mevsimsel personel artışı yaşayan bir işletmede maliyeti doğrudan etkiler.

İkinci soru, modül bazlı lisanslamada hangi modüllerin pakete dahil olduğu. "Temel paket" ile satılan bir ERP'de üretim planlama, çoklu depo ya da gelişmiş raporlama gibi modüller çoğu zaman ayrı kalemdir; bu ayrım demo sırasında değil, sözleşme ekindeki modül listesinde görülür. Kullanıcı sayısı ya da işlem hacmi sözleşmede belirtilen sınırı aştığında (overage) ne olacağı — otomatik ek fatura mı, yoksa önceden bildirimli yeniden görüşme mi — ayrı bir madde olarak yer almalı.

Yıllık bakım bedeli ve fiyat artışı: hangi endekse bağlı

Kalıcı lisans modelinde yıllık bakım/güncelleme bedeli, sektörde yaygın olarak lisans bedelinin belirli bir yüzdesi (uygulamada sık görülen bant %15-22 aralığı) olarak sabitlenir; bu oran vendor'a ve ürüne göre değişir, sözleşmede açık rakam olarak yazılı olmalı. Asıl gözden kaçan nokta, bu bedelin yıllar içinde nasıl artacağı: TÜFE'ye mi bağlı, döviz kuruna mı endeksli, yoksa vendor'ın tek taraflı belirleme yetkisi mi var? "Güncelleme opsiyoneldir" gibi esnek görünen ifadeler cazip gelse de, yıllarca yapılmamış güncellemenin birikmiş bedeli sonradan toplu talep edilebiliyor — bu riski sözleşme metninde ayrı bir madde olarak sorgulamak gerekir.

SaaS/bulut abonelik modelinde ise yıllık bakım kalemi yoktur ama abonelik bedelinin yenileme döneminde ne kadar artabileceği (cap oranı var mı, yok mu) genelde sözleşmenin en çok atlanan maddesidir.

SLA ve destek: arıza tanımı, yanıt süresi, tazminat

SLA (hizmet seviyesi taahhüdü) maddesinin işe yaraması için önce "arıza" kelimesinin tanımlanması gerekir: sistem tamamen çöktüğünde mi, tek bir modül yavaşladığında mı, yoksa raporlama hatası da bu kapsama girer mi? İyi kurgulanmış bir SLA, öncelik seviyelerini (kritik, yüksek, orta, düşük) ayrı ayrı tanımlar ve her seviye için yanıt süresi ile çözüm süresini ayırır — "yanıt" arandığında geri dönülmesi, "çözüm" sorunun giderilmesidir, ikisi karıştırılmamalı.

Tazminat (penalty) maddesi de kritik: SLA ihlal edildiğinde sözleşme bedeli üzerinden kredi mi uygulanıyor, yoksa bu madde yalnızca kağıt üzerinde mi kalıyor? Destek zincirinin kaç katmandan geçtiği (yerel iş ortağı → ülke organizasyonu → global destek merkezi) katman sayısı arttıkça pratikte yanıt süresinin uzayabildiği bir gerçek; bu yüzden asıl güvence markadan çok, seçilen iş ortağının kendi SLA taahhüdü ve yerel ekip büyüklüğüdür.

Veri sahipliği ve çıkış senaryosu: vendor lock-in riski

Sözleşme sona erdiğinde ya da vendor değiştirilmek istendiğinde veri hangi formatta (düz CSV, SQL dump, API export), ne sürede ve ücretsiz mi teslim edilecek — bu madde genelde hiç yazılmaz ya da "makul sürede" gibi belirsiz bir ifadeyle geçiştirilir. Belirsizlik burada işletmenin aleyhine işler: veri formatı özel/kapalıysa yeni sisteme taşıma projesi aylarca uzayabilir, vendor bu süreçte ek ücret talep edebilir.

Sağlıklı bir sözleşme, fesih/geçiş halinde veri teslim süresini (ör. bildirimden itibaren belirli bir gün sayısı), teslim formatını ve bu işlemin ücretli olup olmadığını açıkça yazar. Bu madde özellikle uzun ve karmaşık uygulama projelerinin yürütüldüğü inşaat-taahhüt gibi sektörlerde önem kazanır; proje bazlı çalışan işletmelerde veri geçmişi, tamamlanmış işlerin garanti ve hakediş takibi için yıllarca referans olarak kalır.

KVKK ve yurt dışı veri aktarımı: bildirim yükümlülüğü unutulmasın

ERP bulutta çalışıyorsa ve sunucular yurt dışındaysa, kişisel veri aktarımı KVKK'nın (6698 sayılı Kanun) yurt dışına aktarım hükümlerine tabi olur. Kurum'un yayımladığı standart sözleşme mekanizması kullanıldığında, imzalanan sözleşmenin imza tarihinden itibaren 5 iş günü içinde Kişisel Verileri Koruma Kurumu'na bildirilmesi zorunludur — bu, Kurul'un 4 Haziran 2024 tarihli ve 2024/959 sayılı kararıyla netleşen ve Kanun'un 9. maddesine dayanan bir yükümlülük. Şirketler çoğu zaman standart sözleşmeyi imzalayıp dosyalar, bildirim adımını atlar; bildirimsiz sözleşme hukuken güvence sağlamaz.

Vendor'la görüşülürken sorulması gereken somut sorular: veri fiilen hangi ülkede/veri merkezinde tutuluyor, standart sözleşme mekanizması vendor tarafından zaten sunuluyor mu, bildirim süreci kimin sorumluluğunda ilerleyecek? Bu maddeler, özellikle çok şubeli ya da holding yapısındaki işletmelerde birden fazla KVKK veri sorumlusu tarafını ilgilendirebilir.

Süreklilik güvencesi: kaynak kod escrow ne zaman gerekir

Yazılım emanet (escrow) sözleşmesi, vendor'ın kaynak kodunu doğrudan paylaşmadan, bağımsız bir üçüncü tarafa (escrow ajanı) teslim etmesi ve önceden belirlenmiş koşullar (vendor'ın iflası, hizmeti sürdürememesi gibi) gerçekleştiğinde bu kodun müşteriye devredilmesini sağlayan bir mekanizmadır. Türk Standardları Enstitüsü'nün (TSE) ayrı bir "Escrow Sayısal Kaynak Kod" hizmeti bulunuyor; kritik iş süreçlerini tek bir vendor'a bağımlı hale getiren büyük ölçekli veya özel geliştirmeli ERP projelerinde bu tür bir güvence talep edilmesi makul bir uygulamadır.

Her ERP alımında escrow şart değil — küçük ölçekli, köklü ve çok müşterili bir üründe risk düşüktür. Ama özel geliştirme ağırlıklı, tek bir yerel iş ortağına bağımlı ya da kritik operasyonu (üretim hattı, lojistik akışı) doğrudan yöneten sistemlerde bu maddenin en azından görüşülmesi gerekir.

Özelleştirme mülkiyeti ve fesih koşulları

Standart ERP nadiren kutudan çıktığı gibi kullanılır; özel rapor, entegrasyon ya da iş akışı geliştirmesi neredeyse her projede olur. Sözleşmenin bu geliştirmelerin mülkiyetini (work product/iş ürünü) kime ait olduğunu net biçimde yazması gerekir — geliştirmeyi yapan iş ortağı mı, yoksa bedeli ödeyen müşteri mi hak sahibi? Bu belirsizlik, özellikle özel modül geliştirmenin yoğun olduğu üretim sektöründe, iş ortağı değiştirildiğinde ciddi bir tıkanıklığa dönüşebilir.

Fesih koşulları da aynı titizlikle okunmalı: hangi taraf hangi gerekçeyle ve kaç aylık bildirimle feshedebilir, erken fesihte cayma bedeli var mı, minimum taahhüt süresi (genelde SaaS sözleşmelerinde 12-36 ay aralığında görülür) ne kadar?

Kalıcı lisans mı, SaaS aboneliği mi: sözleşme maddesi farkları

İki model, aynı sorulara farklı cevap verir. Aradaki farkı bulut/SaaS ERP karşılaştırma sayfamızda daha geniş ele aldık; sözleşme maddeleri özelinde tablo şöyle özetlenebilir:

Hangi modelin daha uygun olduğu nakit akışı tercihine bağlı; bu ayrımı SAP Business One ile Business Central karşılaştırmamızda somut bir örnek üzerinden de gösterdik. Lisans dışındaki gizli maliyet kalemlerini ise ERP TCO rehberimizde ayrıca topladık.

İmza öncesi kontrol listesi

Sözleşme metni önünüze geldiğinde, aşağıdaki sekiz soruya net cevap alınmadan imza atılmaması önerilir:

• Kullanıcı tanımı (named/concurrent) ve modül kapsamı ekte açıkça listelenmiş mi?
• Yıllık bakım/abonelik artış oranı hangi endekse bağlı, tavan (cap) var mı?
• SLA'da öncelik seviyeleri, yanıt/çözüm süreleri ve ihlal halinde tazminat maddesi ayrı ayrı tanımlanmış mı?
• Destek zincirinin kaç katmandan geçtiği ve iş ortağının kendi SLA taahhüdü net mi?
• Fesih/geçiş halinde veri teslim formatı, süresi ve ücreti yazılı mı?
• Bulut sağlayıcı yurt dışındaysa KVKK standart sözleşme mekanizması ve 5 iş günlük bildirim süreci kimin sorumluluğunda?
• Özel geliştirmelerin (rapor, entegrasyon, iş akışı) mülkiyeti kime ait, kaynak kod escrow ihtiyacı değerlendirildi mi?
• Erken fesih/cayma bedeli ve minimum taahhüt süresi net mi?

Bu sorulardan birine bile net cevap alınamıyorsa, imza öncesi hukuk danışmanlığı almak — özellikle uzun taahhütlü ve kritik operasyonu kapsayan sözleşmelerde — makul bir ek maliyettir, gecikmiş bir maliyet değildir.

Kendi kriterlerinize göre kısa liste çıkarmak için uygun ERP bul aracı kullanılabilir; sözleşme maddelerini kendi senaryonuzla birlikte değerlendirmek isteyen işletmeler için bağımsız bir keşif görüşmesi de talep edilebilir.

Kaynaklar

• Kişisel Verilerin Yurt Dışına Aktarılması Rehberi, KVKK Kurumu
• KVKK Kurulu'nun 4 Haziran 2024 tarihli ve 2024/959 sayılı kararı (6698 sayılı Kanun madde 9 kapsamında standart sözleşme bildirim yükümlülüğü)
• TSE Escrow Sayısal Kaynak Kod hizmeti
• Bulut/SaaS ERP karşılaştırma sayfamız
• ERP TCO gizli kalemler rehberimiz