ERP Projesi Kısmen Kuruldu Ama Çalışmıyor: Bedel İadesi ve Zarar Nasıl Değerlendirilir?

ERP yazılımının bazı modüllerinin kurulmuş olması, projenin sözleşmeye uygun biçimde tamamlandığını veya şirket tarafından kabul edildiğini tek başına göstermez. Bedel iadesi, eksik işlerin tamamlanması, ayıbın giderilmesi, bedel indirimi ya da tazminat taleplerinden hangisinin gündeme geleceği; sözleşmenin niteliğine, teslim ve kabul koşullarına, arızanın ağırlığına ve başarısızlığın nedenine bağlıdır.

Önce ne vaat edildiği, neyin gerçekten teslim edildiği ve hangi işlemlerin başarısız olduğu belgelenmelidir. ERP uyuşmazlığında teknik inceleme ile hukukî talebin aynı olguya dayanması gerekir. Yalnızca ödenen faturalara veya ekrandaki hata mesajına bakılarak tüm proje bedelinin iade edileceği sonucuna varılamaz.

Kısmi Kurulum, Teslim ve Kabul Aynı Şey midir?

Hayır. Kurulum, sistem bileşenlerinin ortama yerleştirilmesini; teslim, kararlaştırılan edimin iş sahibinin kullanımına sunulmasını; kabul ise teslim edilen sonucun sözleşmeye uygunluğuna ilişkin ayrı bir değerlendirmeyi ifade edebilir. Tarafların kullandığı terimler ve sözleşmedeki kabul mekanizması belirleyicidir.

Örneğin sunucuya yazılım yüklenmesi, kullanıcı hesaplarının açılması veya stok modülünün çalışması, üretim planlama ve muhasebe entegrasyonunun da tamamlandığı anlamına gelmez. Buna karşılık sözleşmede birbirinden bağımsız modüllerin ayrı ayrı teslimi ve kabulü kararlaştırılmışsa her aşamanın durumu ayrıca değerlendirilir.

Somut ERP sözleşmesi tek bir hukukî tipe zorlanmamalıdır. Belirli bir yazılımın geliştirilmesi, uyarlanması ve işler hâlde teslimine ilişkin edimler 6098 sayılı Türk Borçlar Kanunu’nun (TBK) 470 ve devamındaki eser sözleşmesi hükümleri kapsamında değerlendirilebilir. Standart lisans, sürekli bulut hizmeti, bakım, eğitim veya danışmanlık edimleri ise farklı hükümler gerektirebilir. Karma sözleşmede uyuşmazlığa konu yükümlülüğün niteliği ayrı ayrı belirlenir.

ERP Projesinde Kabul Gerçekleşmiş Sayılır mı?

Yazılım sağlayıcısının “sistemi kurduk” demesi veya bir faturanın ödenmesi, her durumda kesin kabul anlamına gelmez. Ancak yazılı kabul tutanağı, başarıyla tamamlanan kullanıcı kabul testleri, ihtirazî kayıt bulunmayan teslim belgeleri ve sistemin uzun süre kullanılması, şartlarına göre sağlayıcı lehine değerlendirmeye konu olabilir.

Eser sözleşmesi hükümlerinin uygulandığı hâllerde TBK m.474, teslim sonrasında eserin işlerin olağan akışına göre imkân bulunur bulunmaz incelenmesini ve belirlenen ayıpların uygun sürede bildirilmesini öngörür. TBK m.477 ise açık veya örtülü kabulün sonuçlarını, inceleme ve bildirim ihmalini, sonradan ortaya çıkan ayıpları ve yüklenicinin kasten gizlediği ayıplara ilişkin istisnayı düzenler.

Bu nedenle özellikle şu kayıtlar birlikte okunmalıdır:

• Geçici kabul, kesin kabul ve canlı kullanıma geçiş için sözleşmede ayrı aşamalar öngörülüp öngörülmediği.
• Kullanıcı kabul testlerinin (UAT) hangi senaryolarla ve kimin onayıyla tamamlandığı.
• İmzalanan tutanakta eksik işler, çekinceler veya giderilmesi beklenen hatalar bulunup bulunmadığı.
• Canlı kullanımın nihai kabul mü, yoksa sınırlı bir deneme veya zorunlu geçiş mi olduğu.
• Hataların ne zaman öğrenildiği ve sağlayıcıya hangi içerikle bildirildiği.

Önemli ayrım: Hiç teslim edilmemiş bir modül ile teslim edildiği hâlde ayıplı çalışan bir modül aynı hukukî rejime kendiliğinden tabi değildir. Ayıp bildirimine ilişkin bir süreyi, henüz teslim edilmemiş bütün işlere otomatik uygulamak da hatalı olabilir.

ERP Çalışmıyorsa Ödenen Bedel Geri Alınabilir mi?

Bedelin tamamının veya bir kısmının iadesi mümkündür; ancak talebin dayanağı belirlenmelidir. “ERP başarısız oldu” tespiti tek başına sözleşmeden dönme hakkını ve tam iadeyi kanıtlamaz.

1. Proje tamamlanmadıysa: Eksik ifa ve temerrüt

Kararlaştırılan modüller, veri aktarımı veya entegrasyonlar hiç teslim edilmemişse öncelikle ifa yükümlülüğü ve gecikmenin sebebi incelenir. Eser sözleşmesine uygulandığı ölçüde TBK m.473, yüklenicinin işe başlamaması veya işi geciktirmesi nedeniyle sözleşmenin zamanında tamamlanamayacağının açık olduğu belirli hâllerde, iş sahibine teslim gününü beklemeden sözleşmeden dönme olanağı tanır. Yapım sırasında ayıplı veya sözleşmeye aykırı sonuç doğacağı açıkça görülürse maddede ayrıca ihtar ve uygun süre mekanizması yer alır.

Genel borçlu temerrüdü hükümlerinde TBK m.117 ve m.123-125 önemlidir. Somut durumda ihtar ve ek süre gerekip gerekmediği belirlenerek ifa ve gecikme zararı, ifadan vazgeçip ifa edilmemeden doğan zarar veya sözleşmeden dönme gibi yolların koşulları değerlendirilir. İhtar göndermeden doğrudan bütün bedeli talep etmek her dosyada uygun yol olmayabilir.

2. Teslim edilen sistem ayıplıysa: Onarım, indirim veya dönme

Eser sözleşmesi niteliğindeki teslim bakımından TBK m.475, yüklenicinin ayıptan sorumlu olduğu hâllerde iş sahibine üç temel seçimlik hak tanır:

• Ayıp, sistemi kullanılamayacak veya hakkaniyet gereği kabulü beklenemeyecek ölçüde etkiliyorsa sözleşmeden dönme.
• Sistem elde tutuluyorsa ayıp oranında bedel indirimi.
• Aşırı masraf gerektirmiyorsa gideri yükleniciye ait olmak üzere ücretsiz onarım.

Kanun, genel hükümlere göre tazminat isteme hakkını ayrıca saklı tutar. Bununla birlikte seçimlik hakların koşulları birbiri yerine geçirilemez; örneğin küçük ve giderilebilir bir raporlama hatası ile temel finans kayıtlarını bozarak sistemin esaslı kullanımını engelleyen sorun aynı ağırlıkta değildir.

3. Lisans veya bakım hizmeti süreklilik taşıyorsa

Bulut tabanlı ERP hizmetinde aylık kullanım bedeli, ayrı bakım paketi ve tek seferlik uyarlama bedeli bulunabilir. Sürekli edimli ilişkiye uygulanabilecek TBK m.126 bakımından fesih, kural olarak dönmeden farklı sonuçlar doğurur. Bu nedenle geçmişte sağlanmış ve kullanılmış hizmetlerin bedeli ile hiç karşılanmamış uyarlama veya hizmet edimleri ayrılmadan bütün ödemelerin iadesi istenmemelidir.

Kısmen Çalışan ERP Sisteminde Tam İade mi, Kısmi İade mi?

Belirleyici soru yalnız “kaç modül kuruldu?” değildir; çalışan kısmın şirket açısından bağımsız ve sözleşmede amaçlanan bir kullanım değeri bulunup bulunmadığıdır. Bir modül teknik olarak açılıyor olsa bile temel süreçle bütünleşmeden işlevsiz kalabilir. Tersine, tarafların ayrı bedel ve kabul mekanizması öngördüğü kullanılabilir bir modülün varlığı, toplam iade hesabını etkileyebilir.

Varsayımsal örnek: Stok ekranları açılan fakat üretim hareketlerini muhasebeye doğru aktaramayan bir ERP’de, entegrasyonun projenin asli amacı olup olmadığı araştırılır. Tek bir modülün kurulmuş olması “işin büyük bölümü tamamlandı” sonucunu; entegrasyondaki her hata da “sözleşme tamamen ortadan kalkar” sonucunu kendiliğinden doğurmaz.

Bu değerlendirmede sözleşmedeki etapların bölünebilirliği, hangi bedelin hangi edime karşılık geldiği, lisansın kullanılmaya devam edilip edilmeyeceği, iade edilebilir teslim çıktıları ve sağlayıcının fiilen yarattığı değer birlikte incelenmelidir. Eser sözleşmesine uygulanıyorsa TBK m.479’daki teslim ve parça parça teslim edilen eser bakımından bedelin muacceliyetine ilişkin kurallar da önemlidir.

ERP Projesinin Başarısızlığından Doğan Zararlar İstenebilir mi?

TBK m.112, borcun hiç veya gereği gibi ifa edilmemesi hâlinde, borçlunun kendisine hiçbir kusur yüklenemeyeceğini ispat edemediği ölçüde zararın giderilmesi sorumluluğunu düzenler. Bununla birlikte şirketin her gideri otomatik olarak karşı tarafa yüklenemez. İhlal, zarar, uygun illiyet bağı, tazminat rejimi ve sözleşmedeki geçerli sorumluluk düzenlemeleri birlikte incelenir.

Dosyanın koşullarına göre ayrı ayrı araştırılabilecek kalemler şunlardır:

• Çalışmayan veya hiç teslim edilmeyen işler için ödenmiş bedellerin, seçilen hukukî yola göre iadesi.
• Hatanın giderilmesi, verinin yeniden düzenlenmesi veya üçüncü kişiden zorunlu teknik destek alınması için yapılan makul ve belgeli giderler.
• Eski sisteme geçici dönüş veya alternatif yazılım kullanımının kanıtlanabilir ek maliyeti.
• Somut kayıtlarla gösterilebilen faaliyet aksaması ve şartları oluşmuşsa yoksun kalınan kazanç.

Bedel iadesi ile tazminat aynı kalem değildir. Ayrıca sözleşmeden dönme nedeniyle istenebilecek zarar ile ifa edilmemesi sebebiyle talep edilen zarar farklı hukukî esaslara dayanabilir. Birbirini dışlayan seçimlik haklar bir arada gerçekleşmiş gibi ileri sürülmemeli; aynı ödeme veya kayıp iki kez hesaba katılmamalıdır. Zarar hesabı, mali kayıtlar ile teknik neden analizi üzerinde kurulmalıdır.

ERP Uyuşmazlığında Hangi Belgeler Karşılaştırılmalı?

Uyuşmazlık dosyasının temelini tek başına sözleşme değil, kapsam–uygulama–test–kabul–ödeme zinciri oluşturur. İncelemede şu belge grupları eşleştirilmelidir:

• Taahhüt: Ana sözleşme, teklif, iş kapsamı (SOW), teknik şartname, modül listesi, proje takvimi, performans ve entegrasyon kriterleri.
• Değişiklikler: Ek protokoller, change request kayıtları, ilave iş onayları, kapsamdan çıkarılan işler ve bunların fiyat etkisi.
• Fiilî ifa: Kurulum ve sürüm kayıtları, veri aktarım raporları, API/entegrasyon logları, eğitim ve yetki tanımları, sağlayıcının işlem kayıtları.
• Test ve kabul: UAT senaryoları, başarılı/başarısız sonuçlar, hata bildirimleri, tekrar test kayıtları, geçici ve kesin kabul tutanakları, canlıya geçiş yazışmaları.
• Parasal sonuç: Faturalar, ödeme dekontları, lisans ve bakım giderlerinin ayrımı, alternatif tedarikçi teklifleri, yeniden işleme masrafları ve varsa faaliyet kaybı kayıtları.

Özellikle teklif aşamasındaki vaat ile sonradan kabul edilmiş kapsam değişiklikleri farklıdır. İlk teklifte yer alan bir fonksiyonun geçerli bir değişiklikle çıkarılıp çıkarılmadığı açıklığa kavuşturulmadan “eksik teslim” sonucu kurulamaz.

Teknik İnceleme ve Kabul Testi Nasıl Yapılandırılmalı?

Teknik raporun yalnızca “sistem çalışmıyor” demesi yeterince açıklayıcı değildir. Sözleşmede ölçülebilen her yükümlülüğün fiilî sonuçla eşleştirilmesi ve hata nedeninin belirlenmesi gerekir. Bilgi işlem birimi ile hukukî inceleme aynı test matrisini esas alabilir.

• Fonksiyon: Sözleşmede hangi işlemin yapılması vaat edildi, hangi ekran veya süreç bunu gerçekleştirmiyor?
• Tekrar edilebilirlik: Hata hangi sürümde, hangi yetkiyle, hangi veri setinde ve hangi adımlar izlendiğinde ortaya çıkıyor?
• Entegrasyon: Veri başka sisteme hiç mi aktarılmıyor, yanlış mı eşleşiyor, yoksa gecikmeli mi işleniyor?
• Neden: Sorun yazılım, kurulum, müşteri verisi, altyapı, üçüncü taraf sistem veya onaylanmış kapsam değişikliğinden mi kaynaklanıyor?
• Giderilebilirlik: Sorunun düzeltilmesi teknik olarak mümkün mü; olası düzeltmenin proje takvimi ve kullanım amacına etkisi nedir?
• Kabul ilişkisi: Başarısız testlerin hangisi kabulün ön koşulu ve hangi eksikler çekinceyle kabul edilmiş?

Teknik ortamın sürümü, tarih bilgisi ve kayıt bütünlüğü korunmalıdır. Kişisel veriler ve ticari sırlar gereksiz yere dış hizmet sağlayıcılarına aktarılmamalı; inceleme yetki ve sözleşmesel erişim sınırları içinde yapılmalıdır.

Dava Açılmadan Önce ERP Sistemi İçin Delil Tespiti Yapılabilir mi?

Evet, şartları varsa. 6100 sayılı Hukuk Muhakemeleri Kanunu’nun (HMK) 400. maddesi, ileride açılacak davada ileri sürülecek vakıaların keşif veya bilirkişi incelemesi gibi yollarla tespitine imkân tanır. Bunun için hukukî yarar gerekir; örneğin sistem güncellendiğinde mevcut hataların veya logların kaybolması yahut tespitinin önemli ölçüde zorlaşması tehlikesi somutlaştırılabilir.

Delil tespiti talebinin kapsamı ve içeriği HMK m.402’ye, görev ve yetki HMK m.401’e göre belirlenir. Hakların korunması bakımından zorunluluk varsa HMK m.403 uyarınca karşı tarafa önceden tebligat yapılmaksızın tespit imkânı da değerlendirilebilir; bu, bütün ERP uyuşmazlıklarında otomatik uygulanacak bir usul değildir.

HMK m.199 elektronik verileri belge kapsamında ele alır. HMK m.293 kapsamında tarafın uzman görüşü alması da mümkündür. Ancak özel teknik rapor, mahkeme eliyle delil tespitiyle veya mahkemenin görevlendirdiği bilirkişinin incelemesiyle aynı usulî işlem değildir. Hangi aracın gerekli olduğu delilin korunması ve ispat ihtiyacına göre belirlenir.

Yazılım Sağlayıcısının Savunmaları Sonucu Değiştirebilir mi?

Evet. Sağlayıcı; hatanın müşterinin eksik veri vermesinden, altyapı veya erişim sağlamamasından, üçüncü taraf sistemlerinden, ilave kapsam taleplerinden ya da test ve kabuldeki gecikmeden kaynaklandığını ileri sürebilir. Bu iddialar da belgelerle sınanmalıdır.

Eser sözleşmesi rejiminde TBK m.476, ayıbın yüklenicinin açık ihtarına rağmen iş sahibinin talimatından doğduğu veya başka nedenle iş sahibine yüklenebildiği hâller için önem taşır. Bu nedenle yalnız sağlayıcının kusurunu değil, şirketin üstlendiği veri hazırlama, altyapı sağlama ve kabul testlerine katılma yükümlülüklerini de incelemek gerekir.

İş takvimindeki gecikmenin kime ait olduğu, proje yönetimi toplantıları, onay zinciri, bağımlılık listesi ve karşılıklı yazışmalar üzerinden tarihlendirilmelidir. Her yeni geliştirme talebi “müşteri kusuru”; her teknik hata da “sağlayıcı kusuru” olarak sınıflandırılamaz.

İhtar, Arabuluculuk ve Dava Süreci Nasıl Planlanır?

1. Sözleşme ve talep türü belirlenir. Tahkim şartı, sözleşmesel bildirim ve kabul usulü, sorumluluk sınırları ve ödeme takvimi kontrol edilir.
2. Teknik durum korunur. Mevcut sürüm, erişilebilen loglar, test verileri, kayıt tarihleri ve sözleşme kapsamıyla bağlantılı hatalar belgelenir; gerekli ise delil tespiti değerlendirilir.
3. Uygun bildirim yapılır. Eksik ve ayıplı edimler somutlaştırılır. Temerrüt, dönme veya feshe yönelik ihbarlarda tacirler arasındaki işlemler için 6102 sayılı Türk Ticaret Kanunu (TTK) m.18/3 kapsamındaki bildirim yöntemleri dikkate alınır. Sıradan destek talebi ile sözleşmeyi sona erdirmeye yönelik ihtar aynı şey değildir.
4. Uyuşmazlık yolu seçilir. Her iki tarafın ticari işletmesiyle ilgili uyuşmazlıklar bakımından TTK m.4-5 kapsamında ticari dava ve görev incelemesi yapılır. Konusu bir miktar para olan ticari alacak ve tazminat davalarında TTK m.5/A uyarınca dava öncesi arabuluculuk şartı gündeme gelir. Dava taleplerinin birleşimi veya geçerli tahkim anlaşması varsa usul ayrıca değerlendirilir.

Uyuşmazlığın yalnızca sözleşmeden dönmenin tespitine mi, belirli bir paranın iadesine mi, tazminata mı yoksa birlikte ileri sürülen taleplere mi ilişkin olduğu; görevli merci, dava şartı ve talep sonucunu etkileyebilir. Bu yüzden “her ERP davası doğrudan asliye ticaret mahkemesinde açılır” biçiminde bir genelleme doğru değildir.

ERP Projesinde Zamanaşımı Ne Zaman Başlar?

Tek bir süre bütün talepler için geçerli değildir. Eser sözleşmesinin ayıplı ifasına ilişkin TBK m.478, taşınmaz yapı dışındaki eserlerde teslim tarihinden itibaren iki yıllık; yüklenicinin ağır kusuru hâlinde ise eserin niteliğine bakılmaksızın yirmi yıllık zamanaşımını düzenler. Eser sözleşmesinden doğan diğer alacaklarda TBK m.147/6 ve talebin niteliğine göre farklı hükümler gündeme gelebilir.

Henüz teslim edilmemiş bir modül, teslim edilmiş fakat ayıplı çalışan bir modül ve sürekli sunulan hizmet bakımından başlangıç tarihi ile uygulanacak süre aynı varsayılmamalıdır. Ayrıca zamanaşımı hesabı, ayıbın uygun sürede bildirilmesi yükümlülüğünün yerine geçmez. Kesin süre incelemesi için sözleşme, teslim ve bildirim tarihleri birlikte gereklidir.

ERP Uyuşmazlıklarında Sık Yapılan Hatalar

• Kurulum, kullanıcı eğitimi, geçici kabul ve kesin kabulü tek işlem saymak.
• Sistem ekran görüntüsü alıp hata senaryosunu, sürümü ve veri setini kaydetmemek.
• Projedeki bütün gecikmeleri sağlayıcıya yüklerken müşterinin onay ve veri hazırlama yükümlülüklerini incelememek.
• Ayıp bildirimi, temerrüt ihtarı ve sözleşmeden dönme açıklamasını birbirine karıştırmak.
• Delil korunmadan sistemi sıfırlamak, yeniden kurdurmak veya kayıtları silmek.
• Ayıplı ifa ile hiç ifa edilmemeyi, bedel iadesiyle tazminatı ve geçmiş hizmetle gelecekteki hizmeti aynı hesapta toplamak.

Sonuç: Bedel İadesi İçin Önce Teknik ve Hukukî Durum Ayrıştırılmalı

ERP projesinin kısmen kurulmuş olmasına rağmen çalışmaması, şirkete çeşitli hukukî talepler ileri sürme imkânı verebilir. Bununla birlikte uygun talep, sözleşmede vaat edilen sonuç ile teslim edilen fiilî durum arasındaki farkın, kabul ve bildirim kayıtlarının ve kusurun nedeninin belirlenmesine bağlıdır. Kullanılabilir bir kısmın varlığı, ayıbın ağırlığı, giderim olanağı ve sözleşmedeki lisans-bakım ayrımı özellikle önemlidir.

Somut uyuşmazlıkta sözleşme belgeleri, test sonuçları, kabul kayıtları, ödeme dökümü ve teknik inceleme birlikte değerlendirilmelidir.

Bu makale genel bilgilendirme amacıyla hazırlanmış olup hukuki danışmanlık niteliği taşımaz. Somut hukuki sorunlarınız için bir avukata danışmanız gerekir.