Sistemdeki Arızaların Kabul Sonrası Ortaya Çıktığı Durumlarda Ne Yapılmalı?

Sistem geliştirme genel olarak, gereksinim tanımlama aşamasında belirlenen içeriğe göre programın uygulanmasını ilerletir ve sonunda kullanıcı ve satıcı tarafından belirlenen özelliklere uygun olup olmadığını kontrol eder ve kabul testinin başarısıyla sona erer.

Ancak, gerçek dünyada, test süreci ve kabul testi sırasında tespit edilemeyen hatalar ve sorunlar, sonraki operasyon aşamalarında ortaya çıkabilir. Bir kez teslim alındığında, hukuki olarak ne talep edebileceğinizi merak ediyor olabilirsiniz.

Kabul Testinden veya Test Sürecinden Sonra Bile Hataların Kalması Şaşırtıcı Değil

Teknik bir bakış açısıyla söylersek, çeşitli test süreçlerinin tamamlanmasının veya kullanıcı tarafından kabul edilmesinin ardından çeşitli hataların ve sorunların ortaya çıkması hiç de nadir bir durum değildir. Kullanıcıların kabul sürecinde genellikle yaptıkları şey, ekran üzerinden kontrol edilebilen giriş-çıkışların kontrolünün merkezde olmasıdır. Ancak, bir IT sistemi, kullanıcı tarafından kontrol edilebilen ekran görünümünden daha fazlasıdır, genellikle arkasındaki veritabanı ve çeşitli hesaplamaları ve kontrolleri yöneten program bölümünde karmaşık ve ayrıntılı bir yapıya sahip olabilir. Bu nedenle, kullanıcı perspektifinden ekran üzerindeki giriş-çıkış kontrolünden elde edilebilecek bilgilerin baştan sınırlı olduğunu anlamak önemlidir. Dolayısıyla, kontrol sürecinde daha sonraki operasyonel aşamada ortaya çıkabilecek tüm sorunların olasılığını kapsamlı bir şekilde doğrulamak gerçekçi olmayabilir.

Yukarıda belirtilen durumlar, geliştirme işlerini üstlenen tedarikçi tarafından bakıldığında da aynıdır. Örneğin, uygulanan programın içeriği hakkında, hataların veya sorunların olup olmadığını kontrol etmek ‘test süreci’dir. Ancak, test sürecinde gerçekten her türlü hatanın veya sorunun olasılığını doğrulayabilir miyiz? Cevap her zaman evet değildir. Geliştirilen sistem tam anlamıyla işlerde kullanılmaya başlandıktan sonra bile, tedarikçinin beklemediği işlemler yapılır, veya büyük miktarda veri gerçekten kaydedilmeye başlar, veya birden fazla kullanıcı aynı anda erişmeye başlar. Buna rağmen, sorunsuz bir şekilde çalışmaya devam eden bir sistem oluşturmak aslında üstün teknik beceri gerektirir.

Kabul veya test gibi aşamalarda, her türlü hatayı veya sorunu bulmak gerçekçi olmayabilir ve gerçekten kullanmaya başladıktan sonra çeşitli sorunların ortaya çıktığı durumlar olabilir. Bu, bir IT sisteminin doğasıdır ve ilk olarak bu noktayı anlamak önemlidir.

Borçların yerine getirilmiş olduğu kabul edilmesi genellikle normaldir

Peki, bu tür sorunlar gerçekten ortaya çıktığında, nasıl bir yol izlemeliyiz? Hukuki sıralamaya göre düzenleyeceğiz.

Öncelikle, sonradan olsa bile, çeşitli hatalar ve sorunlar ortaya çıktıysa, kullanıcı tarafından, bugüne kadar iş talep ettiği tedarikçiye karşı bir tür sorumluluk talep etmek istenecektir. Ancak, genellikle, teslimat zaten tamamlanmış ve kabul edilmişse, borcun yerine getirilmemesine dayalı sorumluluk talebi genellikle zordur.

Aslında, sistem geliştirme sözleşmeleri, özel bir anlaşma sağlanmadıkça, program uygulamasına ilişkin hükümler Japon Medeni Kanunu’ndaki (Japanese Civil Code) taahhüt sözleşmesi hükümlerini içerir. Taahhüt sözleşmesinin ne olduğu aşağıdaki makalede ayrıntılı olarak açıklanmıştır.

https://monolith.law/corporate/system-development-contact-agreement[ja]

Ve taahhüt sözleşmesinde, “işin tamamlanması”, borcun yerine getirilmesi gerekliliğidir. Burada bahsedilen “işin tamamlanması”nın ne anlama geldiği aşağıdaki makalede ayrıntılı olarak açıklanmıştır.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Burada, geçmiş mahkeme kararlarında, taahhüt sözleşmesindeki “işin tamamlanması”nın, sistem geliştirme bağlamında, geliştirme sürecinin tamamının sona ermesi anlamına geldiğini açıklıyoruz. Ve geliştirme sürecinin tamamı tamamlandıktan sonra ortaya çıkan hata ve sorunların, taahhüt sözleşmesindeki kusur garantisi sorumluluğu sorunu olduğunu açıklıyoruz.

Özetlemek gerekirse, bir kez teslimat kabul edilmiş ve kabul tamamlanmışsa, borcun zaten yerine getirilmiş olduğu varsayılarak, sonraki kalite garantisi sorunu, yani kusur garantisi sorumluluğunun takibi mümkün olup olmadığı genellikle sorun olacaktır.

Kusurlu Garanti Sorumluluğuna Dayalı Sorumluluk Takibi Yolu

Peki, kusurlu garanti sorumluluğuna dayanarak satıcıdan bir yanıt talep ettiğimizde, hangi konuları hangi sırayla ele almalıyız? Aşağıda bunları kontrol edelim.

Öncelikle Hata veya Arızanın Önem Derecesini ve Ciddiyetini Kontrol Edin

Hata veya arıza sonradan ortaya çıktığında ve bu durum hukuki bir “kusur” olarak kabul edilip bir tür garanti talep edildiğinde, hatanın veya arızanın ciddiyeti sorun olmaktadır. Hukuki kusur meselesi genellikle;

1. Hata veya arıza olarak adlandırılan şeylerin hafif olduğu ve hukuki bir “kusur” olarak kabul edilemeyeceği durumlar
2. Hukuki bir “kusur” olarak kabul edilebilecek durumlar, ancak sözleşmenin amacının gerçekleştirilmesi mümkün olduğu durumlar
3. Hukuki bir “kusur” olarak kabul edilebilecek durumlar ve ayrıca sözleşmenin amacının gerçekleştirilmesi mümkün olmayan durumlar

olarak üç kategoriye ayrılır. Kusurlu garanti sorumluluğuna dayalı sorumluluk takibinin mümkün olup olmadığını belirleyen şey, 1 ve 2 arasındaki çizgidir ve sözleşmenin kusurlu garanti sorumluluğuna dayanarak feshedilip feshedilemeyeceğini belirleyen şey 2 ve 3 arasındaki çizgidir.

Madde 634

1. İşin konusu olan malda bir kusur olduğunda, sipariş veren, yükleniciye, makul bir süre belirleyerek, bu kusurun düzeltilmesini talep edebilir. Ancak, kusur önemsiz olduğunda ve düzeltme aşırı maliyet gerektirdiğinde, bu durum geçerli değildir.

2. Sipariş veren, kusurun düzeltilmesi yerine veya onunla birlikte, zararın tazminini talep edebilir. Bu durumda, Madde 533 hükümleri uygulanır.

Madde 635

İşin konusu olan malda bir kusur var ve bu nedenle sözleşmeyi yaptığı amaç gerçekleştirilemiyorsa, sipariş veren, sözleşmeyi feshedebilir. Ancak, binalar ve diğer arazi yapıları için bu durum geçerli değildir.

Ayrıca, bu “kusur”ların aşamalı ayrımı hakkında, aşağıdaki makalede detaylı bir açıklama yapılmıştır.

https://monolith.law/corporate/defect-warranty-liability[ja]

Sonraki Adım Olarak Satıcıdan Talep Edilecek Konuları Belirlemek

Ayrıca, karşı taraftan ne talep etmeniz gerektiğini belirlemek de önemlidir. Eğer sözleşmeyi feshetmek istiyorsanız, bunun bir kusur olduğunu kanıtlamanın yeterli olmayacağını, bunun “sözleşmenin amacını gerçekleştiremeyecek” kadar ciddi bir durum olduğunu belirtmeniz gerekmektedir. Burada bahsedilen “amaç”ın belirlenmesinde, sistem geliştirme projesinin başlangıcında yapılan toplantıların tutanakları ve spesifikasyon belgelerindeki bilgiler önemli ipuçları olacaktır. Kabul sonrası bile hatalar veya arızalar sonradan ortaya çıkabilir, bu yüzden geliştirme projesi sona erdikten sonra bile belgelerin saklanması önemlidir.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Ayrıca, feshin dışında, kusurlu garanti sorumluluğunun içeriği olarak talep edilebilecek şeyler arasında, tazminat talepleri ve kusur düzeltme talepleri bulunmaktadır.

Diğer Dikkat Edilmesi Gerekenler

Sözleşmenin feshi gibi hukuki işlemler yapılırken, nasıl yapılacağına dikkat edilmeli

Eğer kusur garantisi sorumluluğu kapsamında, sözleşmenin feshini gerçekleştirecek olursanız, fesh işlemi için gerekli hukuki işlem prosedürlerinin nasıl yapılacağına dair bilgiyi de öğrenmelisiniz. Sözleşmenin feshinin etkileri, geçerli bir irade beyanının nasıl yapılacağı, sonradan sorun olmayacak şekilde bildirimlerin nasıl yapılacağı gibi konular hakkında ayrıntılı açıklamaları aşağıdaki makalede bulabilirsiniz.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Çatışma yerine, müzakere şeklinde çözüm tercih edilmelidir

Ayrıca, bu tür hukuki tartışmalar, sadece dava durumunda anlam ifade etmez. Mahkeme yoluyla çözüm, her iki taraf için de büyük bir yük olabilir. Aslında, dava öncesi müzakere aşamasında da bu bilgiler büyük ölçüde kullanılmalıdır. Hukuki bilgilerin, dava dışı müzakerelerde ne kadar anlamlı olduğu hakkında aşağıdaki makalede açıklama yapılmaktadır.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Hatalar ve sorunlar ile eksik özellikler ayrı ayrı düşünülmelidir

Uygulanan özelliklerde veya spesifikasyonlarda hatalar veya sorunlar olduğunda ve baştan beri gerekli özelliklerin olmadığı durumlarda, tartışmalar farklı olacaktır. Eğer gerekli özellikler tamamen eksikse, taahhüt sözleşmesindeki “işin tamamlanması” kabul edilmeyebilir ve borcun yerine getirilmesi kabul edilmeyebilir.

Ayrıca, gerekli özellikler veya spesifikasyonlar sağlanmamış olsa bile, kullanıcı tarafının gereksinim tanımlama aşamasında uygun bilgi sağlamadığı sonucu ortaya çıkmışsa, sözleşme içeriğinin bir parçası olarak kabul edilmesi bile uygunsuz olabilir.

Özet

Proje sürecinde ortaya çıkan sorunlar, projenin devam ederken ortaya çıkabileceği gibi, işletme aşamasında ve sonrasında da ortaya çıkabilir. Tüm süreçleri sorunsuz bir şekilde tamamlamış olsak bile, her zaman rahat hissetmememiz gerektiği, sistem geliştirme projelerinin özelliği, “Kusur Garanti Sorumluluğu” (Japanese ~ 瑕疵担保責任) adlı düzenleme ile sembolize edilmiş gibi görünüyor. Sistem geliştirme projesinin sonrasını da göz önünde bulundurarak belge yönetimini tamamen uygulamak ve bu tür bir süreci anlamak önemli olduğu düşünülmektedir.