MONOLITH LAW OFFICE+81-3-6262-3248Hafta içi 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Eski Sistemden Yeni Sisteme Geçişin Sistem Geliştirmedeki Hukuki Sorunları

IT

Eski Sistemden Yeni Sisteme Geçişin Sistem Geliştirmedeki Hukuki Sorunları

Yeni bir IT sistemi oluşturmak, IT mühendislerinin tipik iş alanlarından biridir. Ancak, “yeni bir sistem oluşturma” durumunda, çoğu zaman “daha önce kullanılan sistemin kaldırılması” süreci de aynı anda dahil olabilir. Bu makalede, yeni bir sistem geliştirme projesini, “eski sistemin kaldırılması” yönünden yeniden ele alacağız ve bu konuyla ilgili çeşitli hukuki sorunları açıklıyor olacağız.

Yeni Bir Sisteme Geçiş Ne Anlama Geliyor?

IT Sistemlerinin Ömrü Sonsuz Değildir

Bir şirketin kullandığı IT sistemlerinin, bir kez oluşturulduktan sonra sürekli olarak kullanılabileceği düşünülse de, bu kesinlikle doğru değildir. Ayrıca, eski bir şeyi sürekli olarak kullanmaya devam etmenin her zaman iyi olduğu anlamına da gelmez. Şirketten şirkete ve sistemin kullanım amacına göre değişiklik gösterse de, genel bir kural olarak, bir sistem en fazla yaklaşık 10 yıl kullanıldıktan sonra, yeni bir şeye yenilenmesi daha iyi olacağına dair bir yönetim kararı verilme eğilimindedir.

10 yıl geçtiğinde, piyasada dolaşan bilgisayarların performansı da büyük ölçüde değişir. Bu durumda, örneğin, 10 yıl önce (insanlar tarafından basit ve mükemmel bir tasarım olarak görülen) bilgisayarın işlem hızı gibi kısıtlamalar nedeniyle uygulanması gerçekçi olmayan bir programın, şimdi uygulanabilir hale gelmiş olabileceği durumu da olabilir. Ayrıca, bir kez oluşturulduktan sonra 10 yıl boyunca kullanılmaya devam edilmişse, bu süre zarfında şirketin iş akışı veya iç kuralları da büyük ölçüde değişmiş olabilir. Bu tür şirket içi ve dışı işletme çevresi değişikliklerine yanıt olarak sonradan uygulanan kodlar, ekran tarafından algılanamayacak kadar karmaşık ve iç içe geçmiş bir yapıya dönüşmüş olabilir. Bu durumda, kullanıcılar için eklenmesini istedikleri özellikler olsa bile, geliştiriciler tarafından artık ek uygulamanın imkansız hale geldiği bir durum olabilir.

Eski bir sistem, zamanla IT mühendislerine çok sayıda “elle yapılan işlem” (örneğin, verileri tek tek çıkarmak için sorgular oluşturmak gibi işletme işlemleri) oluşturabilir. Sistem kendisi de, eski olduğunda ironik bir şekilde işleri “kişiye özel” hale getirir. Çok eski hale gelmiş ve kişiye özel işlemlerin arttığı bir sistemle ilgili işlere daha fazla “sistemleştirme” önlemleri uygulamaya çalışıldığında, bu durumda “eski sistemden geçiş için yeni bir sistemin geliştirilmesi” projesi başlatılır.

Yeni Sistem Geliştirmesi, Eski Sistemin Kaldırılmasıyla Birlikte İlerler

Daha önce belirtildiği gibi, (tüm sistem geliştirme projeleri için geçerli olmasa da) bir sistem geliştirme projesinin, eski sistemden geçiş yönünü de aynı anda içermesi genellikle söz konusudur. Sistemler genellikle belirli bir gün itibariyle kesintisiz bir şekilde değişir.

Ancak, günlük iş süreçlerinin kendisi, geçmişten bugüne, bugünden geleceğe doğru sürekli bir şekilde devam etmelidir. Geçmiş verileri gerektiği kadar saklarken, mevcut iş süreçlerinin ilerlemesini engellememek ve daha da önemlisi, geleceğe yönelik üstün bir “sistemleştirme” konsepti sunmak gibi, yeni bir sisteme geçiş genellikle çeşitli zorlukları beraberinde getirir. Bu durumlar karmaşık bir şekilde birleştiğinde, yeni bir sistem geliştirmenin ve mevcut sistemin işletilmesi ve bakımı gibi işler karmaşık bir şekilde ilişkilendirilir ve ayrılmaz bir ilişki oluşturabilir.

Yeni Sisteme Geçiş Adımları Nedir?

Eski sistemden yeni sisteme geçişte önemli adımlar nelerdir?

Eski bir sistemden yeni bir sisteme geçerken, özellikle önemli olan, verilerin uygun şekilde taşınmasıdır. Veri taşıma adımları genellikle aşağıdaki prosedüre göre ilerler.

  1. Eski sistemde saklanan veriler arasından, yeni sisteme taşınması gerekenlerin hangileri olduğunu belirlemek → Yeni sistemin ekranından kolayca aranabilir olması gereken verilerin hangileri olduğunu, ayrıca, ekran araması gerekli olmayabilir ancak (denetimler vb. durumlarda) gerektiğinde çıkarılabilir olması gereken verilerin hangileri olduğunu belirlemek de gereklidir.
  2. 1’de belirlenen veriler arasından, yeni sisteme yüklenmesi gereken verileri, CSV dosyası gibi bir formatla çıktı almak.
  3. 2’de çıkarılan verileri yeni sisteme yüklemek.
  4. 3’te yüklenen verilerin, yeni sistemde yansıtılıp yansıtılmadığını doğrulamak ve doğru bir şekilde taşınıp taşınmadığını kontrol etmek. → Taşımanın doğru yapıldığını doğrulama sonuçları genellikle, ekran görüntüleri veya yazdırılan raporlarla, kanıt materyali olarak saklanır (sözde test süreci).

Yeni Sisteme Geçiş, Kullanıcı ve Satıcı Rollerinin Düzenlenmesi Zorluğu

Önceden belirtilen veri taşıma adımlarında, sıklıkla karşılaşılan bir sorun, kullanıcı tarafının bunu ne kadar kendi iç sorunu olarak görüp yönetim altında tutması gerektiği sorunudur. Ayrıca, veri taşıma konusuyla sınırlı olmamakla birlikte, sistem geliştirme projeleri genelinde “kullanıcı işbirliği yükümlülüğü” hakkındaki genel açıklamalar için aşağıdaki makaleye bakınız.

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

Genel olarak, sistem geliştirme projelerinde, satıcıların genellikle sistem geliştirme için gerekli uzman bilgi ve beceri konusunda kullanıcılardan üstün olduğu (veya daha çok, bu nedenle işe alındıkları) doğrudur. Ancak, diğer yandan, kendi sistemlerinin “olması gereken durumu” hakkında tartışma genellikle sadece kullanıcı tarafından yapılabilir.

Bu noktaları göz önünde bulundurarak, daha önce belirtilen adımlar 1 ve 4’ün kullanıcı tarafından gerçekleştirilmesi gibi bir rol düzenlemesi düşünülebilir. Başka bir deyişle, tüm veri taşıma sürecinde, taşınacak verinin “gereksinim tanımı” ve verinin gereksinimlere uygun olarak taşınıp taşınmadığının “kabulü” her ikisi de kullanıcı işbirliği yükümlülüğü olarak düzenlenebilir. Veya başka bir düzenleme şekli olarak, kullanıcı tarafında eski sistemi hakkında geniş bilgiye sahip bir kişi varsa, adım 2’yi de kullanıcı tarafının sorumluluğu olarak düşünebiliriz.

Eğer dış kaynak kullanmaya gerek duymadan, eski sistemi şirket içinde halledebilirsek, yeni sistemi dış kaynak olarak satıcıya vermek isteyebiliriz. Bu şekilde, veri taşıma işlemlerinde, kullanıcı ve satıcı rollerinin düzenlemesi bazen belirsiz hale gelebilir. Ayrıca, kullanıcının satıcıya sistem geliştirme ile ilgili işleri dış kaynak olarak vermesi durumunda, genellikle satıcıdan hangi rollerin beklendiği ve hangi yasal yükümlülüklerin doğacağı hakkında genel bir açıklama için aşağıdaki makaleye de bakınız.

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

Yeni Sisteme Geçişle İlgili Geçmiş Mahkeme Kararları

Sistem geçiş projelerinde dava durumları da oluşabilir.

Yeni bir sisteme geçişi hedefleyen sistem geliştirme projelerinde, gerçekten sorunlar ortaya çıkmış ve dava konusu olmuş durumlar mevcuttur. Aşağıda alıntıladığımız karar metni, veri geçişi sırasında geçiş işleminin başarısız olması, yeni sistemde birden çok veri uyumsuzluğu ve hata oluşması gibi sorunların ortaya çıktığı ve teslim tarihinde gecikmeler yaşandığı bir durumu anlatmaktadır. Bu tür çeşitli sorunlara karşı, tedarikçi ve kullanıcı tarafının her birinin projeye hangi yükümlülükleri taşıdığı tartışma konusu olmuştur. Sonuç olarak, tedarikçi tarafının taşıması gereken dikkat yükümlülüğü aşağıdaki gibi belirlenmiş ve tedarikçi tarafının dikkat yükümlülüğünü ihlal ettiği kabul edilmiştir.

Davalı, bu dava konusu sözleşmeye dayalı veri geçiş işlemlerinde, bu dava konusu eski sistemdeki verileri sadece bu dava konusu yeni sisteme taşımakla kalmayıp, taşınan verilerle bu dava konusu yeni sistemi çalıştırma borcu, özellikle, veri geçiş işlemlerine başlamadan önce, bu dava konusu eski sistemdeki geçişin hedefi olan verileri araştırıp analiz etmek, verilerin özelliklerini ve durumunu anlamak, bu verilerin bu dava konusu yeni sisteme taşındıktan sonra çalışmayı engelleyip engellemeyeceğini değerlendirmek, engel oluşturacaksa, ne zaman ve hangi yöntemle bu verileri düzelteceğine karar vermek ve son olarak, bu dava konusu eski sistemden taşınan verilerle bu dava konusu yeni sistemi çalıştırma borcunu üstlenmek

gerektiği kabul edilir ve bu dava konusu durumda, veri geçişi sırasında, veri uyumsuzluğunu düzeltme ve çözme yükümlülüğü taşıması gerektiği kabul edilir.

Tokyo District Court, November 30, Heisei 28 (2016)

Bu durum, adım 1 ve adım 4’ün kullanıcı tarafından, adım 2 ve adım 3’ün tedarikçi tarafından üstlenildiği bir rol dağılımı örneğidir. Yani, eski sistemden veri çekme (adım 2) işlemi tedarikçi tarafından bir kez üstlenilmişti. Bu nedenle mahkeme de, veri çekme işlemi dahil olmak üzere, (sistem geliştirme uzmanı olarak) tedarikçinin üstlendiği işlemlerin gerçekten sorunsuz bir şekilde gerçekleştirilebileceği konusunda önceden değerlendirme yapması gerektiğine karar vermiştir.

Ancak, eğer adım 2’yi (yani veri çekme işlemi) kullanıcı tarafının görevi olarak önceden belirlemiş olsaydık ve bu çekme işlemi başarısız olmuş olsaydı ne olurdu? Bu durumda, kullanıcının veri çekme işleminin sorunsuz bir şekilde gerçekleştirilebileceği konusunda önceden bir araştırma yapmaması nedeniyle teslim tarihinde gecikme yaşandığı ve bu sefer kullanıcı tarafının işbirliği yükümlülüğünü ihlal ettiği gerekçesiyle suçlanabileceği bir durum olabilir.

Ayrıca, bu tür kararlar, sadece sözleşme metinlerine dayanmamakta, sistem geliştirme sürecine uygun toplantı tutanakları gibi belgeler de kanıt olarak kullanılmaktadır. Toplantı tutanaklarının önemi hakkında aşağıdaki makalede detaylı bir şekilde açıklama yapılmıştır.

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

Özet

Sistem geliştirme projesi, hem kullanıcı tarafının hem de satıcı tarafının birçok yükümlülüğü karşılıklı olarak üstlenmesi ve iletişimi dikkatlice sürdürmesi gereken bir süreçtir. Bu nedenle, daha önce bahsedilen mahkeme örneğinde olduğu gibi, sadece bazı ön koşullarda küçük değişiklikler yapmak, sorumluluğun kullanıcı ve satıcı tarafı arasında kolayca değişebileceği anlamına gelir.

Ekran görünümünden tahmin edilemeyecek kadar büyük veri ve karmaşık mekanizmalara sahip bir sistem olma olasılığı, küçük bir ön koşul farklılığından dolayı son yargısal kararın büyük ölçüde değişebileceği olasılığı gibi faktörler göz önüne alındığında, yeni bir sistem geliştirme projesinin risk yönetiminin, eski sistemin kaldırılmasıyla birlikte kapsamlı bir şekilde ele alınması önemlidir.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Başa dön