Kullanıcı Sebepleriyle Sistem Geliştirme İşlemlerinin Kesintiye Uğraması Durumunda Nasıl Hareket Edilmeli?

Sistem geliştirme işlemi, genellikle uzun süreli projeler şeklinde gerçekleşir. Ancak, bir kez başlanmış olan bir sistem geliştirme projesine, kullanıcı tarafından tek taraflı olarak “Bu sisteme artık ihtiyaç yok, geliştirmenize gerek yok” gibi bir ifade kullanıldığında, işi üstlenen tedarikçi tarafından ne yapılabilir?

Bu makalede, sistem geliştirme sözleşmesinin özelliklerini düzenlerken, bu durumda ne gibi önlemler alınabileceğini açıklıyoruz.

Kullanıcı Tarafından Yapılan Kesintiler Üzerine Düşünmenin Önemi

Sistem geliştirme sözleşmeleri, sözleşme olarak bakıldığında bazı özelliklere sahiptir. Bunlardan biri, bu tür projelerin genellikle uzun süreli olması ve tedarikçinin büyük bir takdir yetkisi ile birlikte önemli yükümlülükler taşımasıdır. Tedarikçinin proje yönetimi yükümlülüklerinin genel içeriği hakkında ayrıntılı bir açıklama aşağıdaki makalede bulunabilir.

https://monolith.law/corporate/project-management-duties[ja]

Diğer bir özellik ise, kullanıcıların, müşteri olsalar bile, tedarikçinin işlerine geniş çapta yardımcı olma yükümlülüğü taşımasıdır. Kendi iç sistemlerini kullanıyor olmaları nedeniyle, tedarikçiye “tamamen bırakma” seçeneği genellikle geçerli değildir. Şirket içinden de, tedarikçinin uzmanlığını kullanarak işlerini yerine getirebilmesi için gerektiği gibi yardımcı olma yükümlülüğü vardır. Bu konuda ayrıntılı bir açıklama aşağıdaki makalede bulunabilir.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Yukarıdaki bilgileri kısaca özetlersek, tedarikçi ve kullanıcı arasında, bir “dış hizmet sağlayıcı” olarak sistem geliştiren ve karşılığında ödeme yapan bir “müşteri” ilişkisi bulunurken, aynı zamanda, projenin başarısına yönelik ortak bir hedefe doğru işbirliği yapması gereken “takım arkadaşı” gibi bir yönü de vardır. Bu karmaşık ilişki, genellikle özel sipariş takım elbise diken bir terzi gibi işlerde bulunmayan bir şeydir ve sistem geliştirme sözleşmelerinin önemli bir özelliğidir. Sistem geliştirme ile ilgili anlaşmazlıklar, bu karmaşık ilişkiden kaynaklanır ve bir kez karıştığında, tarafların ilişkisini hukuki olarak nasıl düzenlemesi gerektiği konusu genellikle karmaşık ve çözülmesi zor bir durum haline gelir.

Kullanıcı tarafı, “Sonuçta bu sisteme ihtiyacımız kalmadı, bu yüzden projeyi daha fazla ilerletmeye gerek yok” gibi bir değişiklik yaparsa, tarafların hak ve yükümlülüklerini nasıl anlaması gerektiği konusunda düşünmek, karmaşık bir sözleşme ilişkisi karşısında hukuki düşünceyi harekete geçirme konusunda bir örnek sunar. Aşağıda, bu tür bir durumu düşünerek, sonrasında göz önünde bulundurulması gereken konuları düzenliyoruz.

Öncelikle İptal Talebinin Nedenini Düzenleyin

“Kullanıcının tek taraflı olarak projeyi durdurmak istediğini” ifade eden bir durum hakkında, tedarikçi tarafından bakıldığında, bu algının kullanıcı ile her zaman paylaşılmış olması gerekmez. Bir örnek vermek gerekirse, yurtdışı ofislerde çalışan expatların personel işlerini yönetmek için bir sistem geliştiren bir proje başlatılmıştı. Ancak, daha sonra yurtdışı genişleme planı tamamen geri çekildi ve bu tür bir sistemin geliştirilmesi artık gereksiz hale geldi. Evet, bu açıklamaya bakarsanız, kullanıcının tek taraflı bir değişikliği olarak algılanabilir.

Ancak, eğer bu karara varma sürecinde, tedarikçi tarafında da, proje yönetimi yükümlülüklerinin ihlali olan her aşamanın gecikmesi gibi durumlar varsa ve geliştirme ilerlemekte zorlanıyorsa, bu da şirket politikasının değişmesine neden olmuş olabilir. Peki bu durumda ne olur?

Daha önce belirtildiği gibi, sistem geliştirme hem tedarikçi hem de kullanıcı tarafından büyük yükümlülükler alır ve birlikte sıkı bir işbirliği içinde ilerler. Bu durumda, durdurma talebinin kullanıcıdan geldiği ve tedarikçinin bunu kullanıcının kendi iptali olarak düşündüğü durumda bile, tedarikçinin kusuruna işaret edilerek, borç ihlali temelli fesih veya karşılıklı iptal olduğu iddia edilerek geri dönebilir.

Kendi iptali mi, borç ihlali temelli fesih mi, karşılıklı iptal mi olduğu gibi ayrımlar, proje ilerlemesi ve önceki müzakerelerin durumuna bağlı olarak, durumdan duruma özel olarak değerlendirilme eğilimindedir. Bu nedenle, eğer tedarikçi, kullanıcının kendi iptali olduğu algısıyla sonrası işlemleri ilerletiyorsa, toplantı tutanakları gibi belgelerde, bu konuda açıkça kayıt bırakmalı ve bu konuda daha sonra bir anlaşmazlık olmaması için önlem almalıdır.

Ödeme Talebi ve Tazminatın Temel Maddesini Kontrol Etme

Yukarıdaki noktaları göz önünde bulundurarak, kullanıcının kendi kararıyla iptal durumunda, bir sonraki adım olarak, tedarikçinin kullanıcıya, tamamlanma oranına göre ödeme talebinde bulunup bulunamayacağı veya tazminat talep edip edemeyeceğini değerlendirmek olacaktır.

Bu durumda başvurulması gereken maddeler, sözleşme tipine bağlı olarak değişir. Sistem geliştirme sözleşmeleri genel olarak, taahhüt sözleşmeleri ve yarı vekalet sözleşmeleri olmak üzere iki kategoriye ayrılabilir.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Ve yarı vekalet sözleşmeleri ve taahhüt sözleşmeleri durumunda, Japon Medeni Kanunu (Japanese Civil Code) aşağıdaki hükümleri belirler:

a.) Yarı vekalet sözleşmesi durumunda
Ödeme talebi: Japon Medeni Kanunu (Japanese Civil Code) Madde 648, Fıkra 3
Vekaletin, vekilin kusurundan kaynaklanmayan bir sebep nedeniyle yarıda kesildiği durumlarda, vekil, zaten tamamlanan işin oranına göre ödeme talep edebilir.
Tazminat talebi: Japon Medeni Kanunu (Japanese Civil Code) Madde 651
1. Her iki taraf da istediği zaman vekaleti iptal edebilir.
2. Bir taraf, diğer tarafa zarar veren bir zamanda vekaleti iptal ederse, bu taraf, diğer tarafın zararını tazmin etmelidir. Ancak, kaçınılmaz bir sebep varsa, bu durum geçerli olmayabilir.

b.) Taahhüt sözleşmesi durumunda
Tazminat talebi: Japon Medeni Kanunu (Japanese Civil Code) Madde 641
İş tamamlanana kadar, müşteri, her zaman zararı tazmin ederek sözleşmeyi iptal edebilir.

Not: Japon Medeni Kanunu (Japanese Civil Code) Madde 641’e dayalı tazminatın kapsamı, sadece zaten harcanan maliyetleri değil, “sözleşme iptal edilmeseydi elde edilecek olan karı” da geniş bir şekilde içerir. Bu, işin tamamlanmasının gereksiz olduğu durumlarda, yasanın işin tamamlanmasını zorlamasının anlamsız olduğu düşüncesiyle, aynı miktarda ödeme yaparak tedarikçinin karını garanti etmenin daha mantıklı olduğunu yansıtır.

Yine de, Japon Medeni Kanunu (Japanese Civil Code) Madde 641’e dayalı tazminatla ilgili olarak, tedarikçi ve kullanıcı arasındaki bireysel sözleşmelerde, tazminatın kapsam dışı bırakıldığı durumlar nadir değildir. Bu tür durumlarda, bireysel olarak yapılan anlaşmalar (yani sözleşmeler) üstün gelir ve bu tür medeni kanun hükümleri geçerli olmaz, bu nedenle dikkatli olunmalıdır.

Daha Fazla İşlem Hacmi ve Zarar Kanıtlama

Kullanıcı tarafından kendi isteğiyle yapılan iptallerde, genellikle sözleşmelerde görülen, işlem hacmi (yani tamamlanan kısım) için komisyon talebi ve tazminat talebi yapılabilir. Bu nedenle genellikle, satıcı tarafından, tazminat talebinde bulunmak için işlem hacmi ve zarar hakkında kanıtlar sunulması gerekmektedir.

Yine de, bu tür işlem hacmi yani tamamlanma oranının kanıtlanması, gerçekte uygulandığında oldukça zorlu bir iş olabilir. Çünkü hangi iş maddesinin ne kadar tamamlandığı gibi konular, özellikle birden fazla alt yüklenici varsa, ilerlemeyi kontrol etmek için görüşmeler yapmak, gerçekte uygulandığında oldukça fazla olabilir. Ayrıca, bu görüşme sonuçlarını destekleyen belgelerin oluşturulması ve görüşme içeriğinin belgelenmesi gibi işlemler de dahil olmak üzere tüm bu işlemler yapıldığında, iş yükü büyük olacaktır. Tüm bunlara rağmen, kanıtların yetersiz olduğu söylenirse, kanıtların hazırlanması için harcanan çaba boşa gitmiş olabilir, bu da birçok zorluğu beraberinde getirir.

Bu tür durumları göz önünde bulundurarak, önlem olarak, sözleşme aşamasında baştan, iptal durumunda iptal tarihine kadar olan günler için günlük hesaplama yapılacağını belirtmek, hesaplamaları basitleştirmek gibi çözümler düşünülebilir. Ayrıca, işlem hacmi taleplerinin, kanıtlamanın zor olduğu düşünüldüğünde, işlem hacmi talebinden vazgeçip, “zaten tamamlanan kısmın geliştirilmesi için harcanan maliyet” için talepte bulunmayı düşünmek de bir seçenek olabilir. Şirket içi geliştirme maliyetleri söz konusu olduğunda, “iş saatleri x birim fiyat” gibi basit bir hesaplama ile kolayca hesaplanabilir. Düşük kar marjı olan projelerde özellikle, işlem hacmi yerine maliyet bazlı talepleri önceliklendirmek, alacakların tahsil edilmesini kolaylaştırırken zararların telafi edilmesini sağlar, bu da daha gerçekçi bir çözüm olabilir.

Kullanıcı tarafından göz önünde bulundurulması gerekenler nelerdir?

Öte yandan, kendi isteğiyle sözleşmeyi feshetmek isteyen kullanıcıların da önceden düşünmeleri gereken noktalar vardır. Bu, tedarikçi ile arasında ödenecek tazminat miktarının kabaca ne kadar olacağını kontrol etmektir. Burada “kabaca” dememizin nedeni, genel bir fikir edinmek ve sonraki müzakerelerin akışını belirlemektir (sözleşmeyi feshetme niyetinin gecikmesi, işlerin tersine dönmesine neden olacağından, tam bir miktar olmasa bile yeterli olacaktır).

Kontrol edilen tahmini miktarın aşırı yüksek olduğuna karar verilirse, bir açıklama talep etmelisiniz. Ancak, ödeme miktarını düşürmek için aşırı pazarlık yapmaya çalışırsanız, anlamsız dava gibi durumlar ortaya çıkabilir ve durum daha da karmaşık hale gelebilir. İki taraf arasındaki müzakereler zorlaşıyorsa, bir avukata danışmayı düşünmek de bir seçenek olabilir.

Not: Bu makalede, sistem geliştirme konusunda bir sözleşmenin var olduğunu varsayarak açıklamalar yapılmıştır. Ancak, gerçek sistem geliştirme durumlarında, “sözleşmenin baştan beri geçerli olup olmadığı” konusu da tartışma konusu olabilir. Bu konuda aşağıdaki makalede daha ayrıntılı bir açıklama yapılmıştır.

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

Özet

Bu makalede, kullanıcıların kendi durumları nedeniyle projenin durdurulması gibi bir duruma karşı nasıl bir yol izlenmesi gerektiğini açıkladık. Ancak, bu makalenin en önemli noktası, “gerçekten kullanıcının kendi durumu olarak adlandırılabilir mi?”, “satıcı tarafında gerçekten bir kusur yok muydu?” gibi soruların incelenmesi gerektiğidir.

Sistem geliştirme gibi projelerde, hem satıcı hem de kullanıcı büyük sorumluluklar üstlenir. Bu durumda, karşı tarafın tek taraflı olarak sorumlu tutulup tutulamayacağını önceden iyi bir şekilde incelemek gereklidir. Aksi takdirde, durumu daha da kötüleştirebilecek bir durumla karşılaşabiliriz. Bu konuda bilinçli olmalıyız.