Üç yıl önce imzalanan sözleşmeyi ilk kez, tedarikçiyi değiştirme kararının verildiği hafta baştan sona okudum. Satın alma klasörden çıkardı: dokuz sayfaydı, altı sayfası ödeme koşulları ve gizlilikti. Aradığım tek satır yoktu. Sistemdeki verinin hangi formatta, hangi sürede ve hangi bedelle bize teslim edileceğine dair hiçbir hüküm yazılmamıştı. Oysa o veritabanının içinde sekiz yıllık DÖF kaydı, doküman revizyon geçmişi, kalibrasyon takvimi ve iki denetimin bulgu kapatma kanıtları duruyordu. Bir QMS sözleşmesini imzalarken asıl belirlediğiniz şey, o sistemden çıkmak istediğiniz gün elinizde ne kalacağıdır. Bu yüzden aşağıdaki on iki maddeyi çıkış gününden geriye doğru sıralıyorum.
Önce çıkışı yazın, sonra girişi
Bir QMS sözleşmesi görüşmesinin tamamı giriş üzerine konuşulur: kurulum ne zaman biter, eğitim kaç gün sürer, kaç kullanıcı tanımlanır. Çıkış senaryosunu masaya getiren kişi genelde huzursuzluk yaratır, çünkü daha yeni başlarken ayrılmaktan söz ediyorsunuzdur. Ama sözleşme dilinde en güçlü olduğunuz an tam olarak o andır. İmzadan sonra, sistem canlıya alındıktan ve veriniz karşı tarafın sunucusunda biriktikten sonra aynı maddeleri pazarlık edemezsiniz.
Madde 1 — Veri mülkiyeti. Sisteme girilen her kayıt, yüklenen her ek dosya ve üretilen her rapor kuruluşa aittir. Tedarikçi bu veriyi yalnızca hizmeti sunmak için işler; anonimleştirilmiş olsa dahi başka bir amaçla kullanamaz. Bu cümleyi tek başına yazmak yetmez, ikinci madde onu tamamlar.
Madde 2 — Veri iade formatı ve süresi. "Veriler talep hâlinde teslim edilir" cümlesi hiçbir şey ifade etmez. Somut yazın: tüm tablolar CSV veya XLSX olarak, ekler orijinal dosya adlarıyla ve klasör yapısıyla, ilişkileri gösteren bir alan sözlüğüyle birlikte, talepten itibaren en geç 15 gün içinde. Bedelsiz olduğunu da ekleyin.
Madde 3 — Geçiş dönemi erişimi. Fesihten sonra sistemin en az 30 gün salt okunur çalışmaya devam etmesi, yeni sisteme geçerken denetim kanıtlarına erişmenizi sağlar. Bu süre olmadan yapılan geçişlerde, göç sırasında kaçan bir kaydı doğrulama şansınız kalmaz. Kayıtların ne kadar süre saklanacağını belirleyen kural sözleşme değil, standart ve müşteri özel şartlarıdır; sözleşme yalnızca buna uymak zorundadır.
Destek ve SLA: sayılar değil, tanımlar önemli
QMS sözleşmesindeki SLA tartışmalarının çoğu sürelerin uzunluğunda değil, sürenin ne zaman başladığında düğümlenir. Bildirim e-postayla mı yapılır, portala kayıt açılınca mı sayaç başlar, mesai dışı bildirimler ertesi sabah 08:00'de mi işleme alınır? Bunları yazmazsanız, hattın durduğu bir cuma akşamı hangi sürenin geçerli olduğunu tartışırsınız.
Madde 4 — Arıza seviyeleri. Her seviyenin tanımı örnekle desteklenmeli. Aşağıdaki tablo, otomotiv tedarikçilerinde işleyen bir yapıdır ve olduğu gibi sözleşme ekine konabilir.
| Seviye | Örnek durum | İlk yanıt | Çözüm hedefi |
|---|---|---|---|
| Kritik | Sisteme hiç giriş yapılamıyor, denetim bugün | 2 saat | Aynı gün geçici çözüm |
| Yüksek | DÖF modülü açılmıyor, diğer modüller çalışıyor | 4 saat | 2 iş günü |
| Orta | Rapor çıktısında sütun kayması | 1 iş günü | 10 iş günü |
| Düşük | Kullanım sorusu, yeni ekran talebi | 1 iş günü | Sürüm planına alınır |
Madde 5 — Destek kanalı ve dil. Desteğin telefon, uzak bağlantı ve yazılı kayıt üzerinden Türkçe verileceği yazılmalı. Yurt dışı merkezli ürünlerde ikinci seviye desteğin yabancı dilde ve farklı saat diliminde olması, kritik arızada verilen 2 saatlik sözü fiilen anlamsız kılar. Destek talebini kimin açabileceğini de sınırlayın; herkesin talep açabildiği kurgularda öncelik sırası bozulur.
Madde 6 — Ölçüm ve yaptırım. SLA'nın ölçüldüğü kayıt hangi sistemde tutulur ve dönemsel olarak kime raporlanır? Aşılan sürelerin karşılığı, yıllık bakım bedelinden yüzde kaç indirimdir? Yaptırımı olmayan bir SLA, sözleşme değil iyi niyet beyanıdır. Bu ölçümü tedarikçi performans değerlendirmenize de taşıyın; tedarikçi yönetimi mantığı yazılım tedarikçiniz için de geçerlidir.
Bir de eskalasyon yolunu yazın. Verilen süre aşıldığında kime, hangi kanaldan çıkılacağı belli olmalı: ikinci saatte destek sorumlusu, dördüncü saatte teknik yönetici, sekizinci saatte firma yetkilisi gibi. İsim değil unvan yazın; kişiler değişir, unvanlar kalır. Bu üç satırı sözleşmeye koyan kuruluşların anlattığı şey hep aynıdır: arıza anında en çok zaman, doğru kişiyi bulmaya çalışırken kaybedilir. Bir de yıl sonunda okunacak tek sayfalık hizmet raporunu şart koşun; kaç talep açıldı, kaçı süresinde kapandı, hangileri aşıldı. Bu rapor olmadan SLA'nın işleyip işlemediğini kimse bilemez, tartışma da hep hafızaya kalır.
SLA metni çoğu sözleşmede satın almanın genel yazılım şablonundan kopyalanır ve kalite birimi o sayfaya hiç bakmaz. Şablonların klasik cümlesi şudur: "5 iş günü içinde müdahale edilir." Gözetim denetiminin sabahında sisteme girilemediğini düşünün. Beş iş günü, denetim bittikten günler sonrasına denk gelir. Kalite takviminizdeki denetim, müşteri ziyareti ve PPAP teslim tarihlerini SLA sürelerinin yanına koyup okuyun; sürelerin makul olup olmadığı ancak o karşılaştırmayla anlaşılır.
Yedekleme, kurtarma ve süreklilik
Madde 7 — Yedekleme sıklığı ve saklama süresi. Günlük yedek mi alınıyor, kaç gün geriye dönük yedek saklanıyor, yedekler nerede tutuluyor? Şirket içi kurulumda bu sorumluluk kuruluşta olur; o zaman da sözleşme kimin ne yapacağını ayırmalıdır. Kalite kayıtlarının saklama süreleri standart ve müşteri özel şartlarıyla belirlenir; yedekleme politikası bu sürelerden kısa olamaz.
Madde 8 — Geri yükleme tatbikatı. Yedek almak yetmez, yedekten dönüldüğünün kanıtlanması gerekir. Yılda bir kez, tercihen yönetim gözden geçirmesinden önce, test ortamına geri yükleme yapılacağını ve tutanak tutulacağını sözleşmeye yazın. Denetimde "yedekleriniz var mı" sorusunun devamı her zaman "geri döndüğünü denediniz mi" olur. Bu konuyu doküman yönetimi tarafındaki kayıt koruma gereksinimleriyle birlikte değerlendirin.
Sürüm güncelleme ve standart uyumu
Madde 9 — Sürüm politikası. Yeni sürümler bakım bedeline dahil mi, yılda kaç kez yayınlanıyor, güncelleme sırasında sistem ne kadar süre kapalı kalıyor? Güncellemenin önce test ortamında denenip kuruluş onayıyla canlıya alınacağı yazılmalı. Bir sabah gelip formların yerini değiştirmiş bir sürümle karşılaşmak, o gün yeniden eğitim vermeniz gereken kırk operatör demektir.
Madde 10 — Standart değişikliklerine uyum. Otomotivde standartlar ve müşteri özel şartları değişir. Bir standart revizyonu yayınlandığında yazılımın formlarını ve raporlarını güncellemek bakım kapsamında mıdır, yoksa ayrı fiyatlandırılan bir geliştirme midir? Bu tek cümlenin eksikliği, sonraki üç yılın en sık tartışma konusu olur. Sistemin hangi standartları karşıladığını standartlar sayfasındaki gibi net bir listeyle sözleşme ekine iliştirin.
Bedel, kullanıcı tanımı ve fesih
Madde 11 — Kullanıcı tanımı ve fiyat artışı. "Kullanıcı" kim sayılıyor: sisteme giriş yapan herkes mi, yoksa aynı anda bağlı olanlar mı? Yılda birkaç kez rapor bakan bir üretim müdürü tam kullanıcı olarak faturalanıyorsa, üç yıl sonraki maliyetiniz bugünkünün epey üstüne çıkar. Yıllık artışın hangi ölçüte bağlandığını ve tavanını da yazın. Lisans modelinin nasıl kurgulandığını fiyatlandırma sayfamızda karşılaştırabilirsiniz.
Madde 12 — Fesih ve devir. Kuruluşun hangi bildirim süresiyle sözleşmeyi sonlandırabileceği, tedarikçinin el değiştirmesi hâlinde hakların nasıl devredileceği ve kaynak kodun emanet (escrow) düzenlemesine konu olup olmayacağı bu maddenin içindedir. Şirket içi kurulumda çalışan sistemlerde bu risk daha düşüktür, çünkü veri ve uygulama sizin sunucunuzdadır. Bulut aboneliklerinde ise fesih maddesi doğrudan verinize erişiminizi belirler; PaKalite'yi kendi sunucusuna kuran firmaların bu maddeyi daha rahat müzakere etmesinin sebebi budur.
Denetçi sözleşmenizi okumaz ama sonuçlarını görür. Kalite kayıtlarınızı dış kaynaklı bir sistemde tutuyorsanız, bu tedarikçinin nasıl seçildiğine, performansının nasıl izlendiğine ve kayıtlarınızın korunmasının nasıl güvence altına alındığına dair kanıt ister. QMS tedarikçinizi yıllık tedarikçi değerlendirmenize dahil edin ve SLA aşımlarını performans puanına yansıtın. Bu, hem sözleşmeyi canlı tutar hem de denetimde hazır bir cevap sağlar.
Kurulum yeri sözleşmenin yarısını belirler
QMS sözleşmesinin aynı on iki maddesi, sistemin nerede çalıştığına göre bambaşka ağırlık kazanır. Yazılım kendi sunucunuzda çalışıyorsa veri mülkiyeti tartışması büyük ölçüde biter; veritabanı zaten sizin makinenizdedir, yedeği siz alırsınız, fesih gününde kimseden dosya beklemezsiniz. Buna karşılık yedekleme, sürüm yükseltme ve sunucu bakımı sorumluluğu da size geçer; sözleşmede bunların hangisinin tedarikçi desteğine dahil olduğunu ayırmanız gerekir. Bulut aboneliğinde denge tersine döner: işletim yükü sizden çıkar, buna karşılık veri erişimi ve çıkış maddeleri sözleşmenin en dikkatli okunması gereken satırlarına dönüşür.
Bu ayrımı sözleşmeye bir sorumluluk tablosu olarak eklemek en temiz yöntemdir. Sol sütuna işi yazın, sağ sütuna sorumluyu: veritabanı yedeği, yedek doğrulama, sürüm kurulumu, kullanıcı yetkilendirme, sunucu güncellemesi, ağ erişimi. Altı satırlık bu tablo, canlıya alma sırasında en çok zaman kaybettiren "bu kimin işiydi" tartışmasını baştan kapatır. Nasıl kurgulanacağını QMS devreye alma planı yazısındaki haftalık görev dağılımıyla birlikte okumanızı öneririm.
Sözleşme eki olarak kabul kriterleri
Sözleşmenin gövdesi ticari hükümlerden oluşur; sistemin gerçekten ne yapacağı ise ekte durur. Şartnamedeki her fonksiyonel şartın karşısına ölçülebilir bir kabul kriteri yazılmış olmalı ve bu ek imzalı olarak sözleşmeye bağlanmalıdır. Aksi hâlde canlıya alma sonrası çıkan "biz bunu böyle anlamamıştık" tartışmasında elinizde yalnızca toplantı notları kalır. Kabul kriteri, üzerinde tartışılmayacak kadar somut olmalıdır: örneğin "onaylanmış bir dokümanın revizyonu alındığında önceki revizyon otomatik olarak yürürlükten kalkar ve geçmiş listede görünür" gibi.
Kabul testinin nasıl yapılacağını da yazın. Kimin hangi senaryoyu, hangi veriyle çalıştıracağı ve kaç iş günü içinde sonuç bildireceği belli olmalı. Kabul edilmeyen bir maddede ne olacağı da öyle: düzeltme süresi, ikinci deneme hakkı, hâlâ karşılanmıyorsa ödeme takviminin nasıl etkileneceği. Bu üç cümle, projeyi süresiz bir düzeltme döngüsüne girmekten kurtarır.
İmzadan önceki son yarım saat
QMS sözleşmesini kalite, satın alma ve bilgi işlem birlikte okumadan imzaya göndermeyin. Kalite tarafı SLA sürelerini denetim takvimiyle, bilgi işlem yedekleme ve güncelleme maddelerini altyapıyla, satın alma bedel ve fesih hükümleriyle karşılaştırsın. Yarım saatlik bu okuma, üç yıl sonra yaşanacak veri teslim pazarlığının tamamını ortadan kaldırır. Sözleşmeye giden yolda teknik gereksinimlerin nasıl yazıldığını QMS şartnamesi hazırlama yazısında madde madde ele aldık; şartnamedeki kabul kriterleri sözleşmenin eki olarak imzalanmalıdır.
Bir de şu var: sözleşmede yazmayan hiçbir söz, satış görüşmesinde ne kadar net verilmiş olursa olsun, üç yıl sonra elinizde kalmaz. "Veriyi zaten istediğiniz zaman dışarı alırsınız" cümlesini duyduğunuzda cevabınız tek olsun: o hâlde bunu şu maddeye yazalım. Karşı taraf yazmakta zorlanıyorsa sorun cümlede değil, cümlenin arkasındaki gerçekliktedir. Bu on iki maddeyi bir kontrol listesine çevirip her yazılım görüşmesinde önünüze koyun; üçüncü görüşmede hangi tedarikçinin neyi taahhüt edebildiğini kendiliğinden görürsünüz.