Bulut Dava Takibi ile Yerel Kurulum Farkları

Bulut dava takibinde yazılım ve veriler sağlayıcının altyapısında durur; tarayıcı veya mobil uygulamayla büronun içinden, duruşma koridorundan ya da evden aynı dosyaya ulaşırsınız. Yerel kurulumda ise program ve veritabanı büronun kendi bilgisayarında ya da sunucusunda çalışır; erişim, yedekleme ve güncelleme sorumluluğu büroya aittir. Asıl farklar erişim, ekip çalışması, yedekleme, bakım yükü ve mevzuat değişikliklerinin yazılıma yansıma hızında ortaya çıkar. E-tebligat ve süre takibi gibi sürekli akan işlerde her yerden erişilen ve güncel kalan model çoğu büro için daha az risk taşır; ancak büronun büyüklüğü, bilgi işlem kapasitesi ve çalışma biçimi kararı belirler.

Kısa Cevap: Hangi Model Hangi Büroya Uygun?

Dava takip yazılımı seçerken doğru soru "hangisi daha iyi" değil, "hangi işi, kim, nereden yapacak" sorusudur. Bulut modeli ile yerel kurulum arasındaki tercih, aslında bir sorumluluk dağılımı tercihidir. Bulutta altyapıyı, güncellemeyi ve yedeklemeyi sağlayıcı üstlenir; büro yalnızca yazılımı kullanır. Yerel kurulumda bu yükün tamamı büroya geçer, karşılığında verinin fiziksel olarak büronun elinde durduğu duygusu ve internet bağlantısından görece bağımsız çalışma imkânı kazanılır.

Bu iki yaklaşımın hangisinin "güvenli" olduğu da çoğu zaman yanlış sorulur. Düzenli yedeği alınmayan, güncellemesi aylarca yapılmayan ve yalnızca tek bir bilgisayarda duran bir yerel kurulum, iyi yönetilen bir bulut hizmetinden daha kırılgan olabilir. Aynı şekilde, erişim parolaları zayıf bırakılmış ve ikinci doğrulama kullanılmayan bir bulut hesabı da büro için risk üretir. Yani belirleyici olan model adı değil, o modelin büro içinde nasıl işletildiğidir.

Küçük ve orta ölçekli bürolarda, özellikle birden fazla avukatın, sekreterin ve stajyerin aynı dosyalar üzerinde çalıştığı yapılarda bulut model genellikle pratik bir başlangıç noktasıdır. Yerel kurulum ise bilgi işlem kapasitesi olan, ağ ve yedekleme süreçlerini düzenli yürütebilen ve belirli bir sebeple verinin büro içinde kalmasını isteyen yapılarda anlam kazanır. Aşağıdaki tablo, ayrıntılara girmeden önce temel farkları özetliyor.

Takip eden bölümlerde bu satırların her birini büro pratiğinden örneklerle açacağız. Önce iki modelin teknik olarak nasıl işlediğine bakmak, sonraki karşılaştırmaları daha anlaşılır kılacak.

Bulut ve Yerel Kurulum Teknik Olarak Nasıl Çalışır?

Bulut modelde yazılım, sağlayıcının yönettiği sunucularda çalışır. Siz bir tarayıcı penceresi veya mobil uygulama üzerinden oturum açarsınız; dosyalarınız, müvekkil kayıtlarınız, duruşma tarihleriniz ve görevleriniz bu merkezî ortamda tutulur. Yazılımın yeni sürümü yayımlandığında herkes aynı anda aynı sürümü kullanmaya başlar. Büro tarafında kurulacak bir şey yoktur; gereken, güvenilir bir internet bağlantısı ve güçlü bir hesap güvenliğidir.

Yerel kurulumda ise yazılım büronun kendi donanımına yüklenir. Tek kişilik bir büroda bu, çoğu zaman tek bir bilgisayar demektir; birkaç kişilik bir ekipte ise ortak bir dosya sunucusu veya yerel ağdaki bir veritabanı sunucusu devreye girer. Veri bu donanımın diskinde durur. Programın yeni bir sürümü çıktığında bunu kimin, ne zaman ve hangi sırayla kuracağına büro karar verir; bu da güncellemelerin gecikmesi riskini beraberinde getirir.

Aradaki hibrit çözümler

Piyasada iki modelin arasında kalan çözümler de vardır. Örneğin yazılım yerelde kurulu olup yalnızca yedeklerini bulut depolamaya atan ya da büro sunucusuna dışarıdan sanal özel ağ ile bağlanılan düzenler görülür. Bu yapılar iki dünyanın avantajını vaat etse de her iki dünyanın yönetim yükünü de büroya bırakabilir. Hibrit bir düzen kuruyorsanız, hangi parçanın kimin sorumluluğunda olduğunu yazılı bir listeyle netleştirmek gerekir.

Tarayıcı eklentisi ve yerel oturum ilişkisi

Bulut model kullanırken bile bazı işlemler yerelde kalabilir. Örneğin kamu sistemlerine erişim gerektiren işlemlerde, avukatın kendi bilgisayarında kendi oturumuyla çalışan bir tarayıcı eklentisi, sunucunun kamu sistemine hiç bağlanmasını gerektirmeden veriyi büronun hesabına taşıyabilir. Bu ayrıntı, "bulut" kelimesinin her şeyin uzaktaki bir sunucuda yapıldığı anlamına gelmediğini hatırlatır; mimariyi yazılımın kendi açıklamalarından okumakta fayda vardır.

Bu ayrımı netleştirdikten sonra, bürolar için en somut fark olan erişim ve ekip çalışması konusuna geçebiliriz.

Erişim ve Ekip Çalışması Açısından Farklar

Örneğin Ankara'da icra ağırlıklı çalışan bir avukat düşünelim. Sabah icra dairesinde dosya inceliyor, öğleden sonra adliyede bir duruşmaya giriyor, akşam ise evinden tebligatlara göz atıyor. Yerel kurulum kullanıyorsa, büro dışındayken dosya bilgisine ulaşmak için ya büro bilgisayarına uzaktan bağlanması ya da bilgileri yanında taşıması gerekir. Bulut modelde ise aynı kayda telefonundan veya dizüstü bilgisayarından, aynı güncel haliyle ulaşır. Bu fark, günlük iş akışında en çok hissedilen farktır.

Ekip çalışmasında da benzer bir tablo vardır. Büroda sekreter yeni bir duruşma tarihi girdiğinde, bulut modelde bu bilgi o anda ilgili avukatın ekranında ve takviminde görünür. Yerel kurulumda aynı sonuç, tüm kullanıcıların aynı veritabanına bağlı olmasına bağlıdır. Her kullanıcı kendi bilgisayarında ayrı bir kopya tutuyorsa, güncel bilgi dağılır ve hangi kaydın doğru olduğu tartışılır hale gelir. Süre takibi gibi hata toleransı düşük bir işte bu dağınıklık ciddi risktir.

Yetki yönetimi de bir başka başlıktır. Büroda ortak avukat, çalışan avukat, sekreter ve stajyerin görebileceği bilgiler aynı değildir. Rol bazlı yetkiyi iyi çözmüş bir bulut hizmetinde bu ayarlar tek yerden yapılır. Yerel kurulumlarda ise çoğu zaman dosya klasörü izinleri ve işletim sistemi hesaplarıyla bu ayrım sağlanmaya çalışılır; bu yöntem hem kurulması hem de denetlenmesi daha zahmetli bir düzendir. Ayrılan bir stajyerin erişiminin kapatılması gibi basit bir işlem bile, yerel düzende birden fazla noktada yapılması gereken bir iş olabilir.

Erişimin yanında verinin korunması ve yedeklenmesi de bürolar için en az bu kadar önemli bir başlıktır; sıradaki bölümde bunu ele alıyoruz.

Veri Güvenliği, KVKK ve Yedekleme

Avukatlık mesleğinde müvekkil bilgisi, meslek sırrı kapsamında korunması gereken bir değerdir; üstelik dosyalardaki kimlik, adres ve sağlık gibi bilgiler kişisel veri niteliği taşır. Bu nedenle hangi modeli seçerseniz seçin, verinin kimin elinde durduğunu, kimlerin eriştiğini ve nerede saklandığını bilmeniz gerekir. KVKK açısından bakıldığında bulutta veri işleyen sağlayıcı ile büro arasındaki ilişkinin, yani verinin hangi ülkede barındırıldığının ve hangi güvenlik önlemlerinin alındığının açıkça anlaşılması önem taşır.

Yerel kurulumun sık anlatılan avantajı, verinin fiziksel olarak büroda durmasıdır. Bu doğrudur; ancak fiziksel kontrol, otomatik olarak güvenlik anlamına gelmez. Büro bilgisayarının çalınması, disk arızası, fidye yazılımı, yangın veya su baskını gibi olaylar yerel veriyi bir anda erişilemez hale getirebilir. Yedek dosyası aynı odadaki ikinci bir diskte duruyorsa, aynı olay yedeği de etkiler. Yerel düzende düzenli, ayrı yerde saklanan ve geri yükleme denemesi yapılmış yedek, tartışmasız bir zorunluluktur.

Bulut modelde yedekleme ve altyapı güvenliği sağlayıcının sürecinin parçasıdır; büronun işi hesap güvenliğini sağlamaktır. Güçlü ve tekrar kullanılmayan parolalar, mümkünse ikinci doğrulama, paylaşılan hesap kullanmama ve ayrılan çalışanın erişimini hemen kapatma bu işin temelidir. Sağlayıcı seçerken verilerin Türkiye'de barındırılıp barındırılmadığını, rol bazlı yetki sunup sunmadığını ve yedekleme yaklaşımını açıkça sormalısınız.

Kontrol için aşağıdaki listeyi sağlayıcı veya bilgi işlem desteğiyle birlikte gözden geçirebilirsiniz.

• ✓ Verinin hangi ülkede barındırıldığı yazılı olarak öğrenildi mi?
• ✓ Kullanıcılar için rol bazlı yetki tanımlanabiliyor mu?
• ✓ Yedekler ayrı bir konumda tutuluyor ve geri yükleme denendi mi?
• ✓ Ayrılan çalışanın erişimi tek adımda kapatılabiliyor mu?
• ✓ Hesaplarda güçlü parola ve mümkünse ikinci doğrulama kullanılıyor mu?

Maliyet ve Bakım Yükü: Görünen ve Görünmeyen Kalemler

Maliyet karşılaştırması yapılırken en sık düşülen hata, yalnızca lisans veya abonelik bedeline bakmaktır. Bulut modelde maliyet genellikle düzenli bir abonelik veya kullanıma dayalı ödeme biçiminde görünür; yerel kurulumda ise başlangıçta lisans ya da kurulum bedeli, sonrasında donanım, elektrik, yedekleme ortamı, bilgi işlem desteği ve zaman maliyeti ortaya çıkar. Bu kalemlerin bir kısmı faturada görünmez, ama büronun cebinden ya da mesaisinden çıkar.

Yerel kurulumun gizli maliyetlerinden biri bakım zamanıdır. Sunucunun güncellenmesi, işletim sistemi yamaları, disk doluluğunun izlenmesi, yedek ortamının yenilenmesi ve bir arıza anında müdahale edecek kişinin bulunması gerekir. Büroda bu işi yapacak bir uzman yoksa, bakım ya dış destek alınarak ya da avukatın veya sekreterin kendi mesaisinden harcanarak çözülür. Avukatın saati ise büronun en değerli kaynağıdır.

Bulut modelde ise bu bakım yükü büro dışına çıkar; karşılığında sağlayıcıya bağımlılık doğar. Hizmetin kesintisiz sürmesi, fiyat politikası ve verinin gerektiğinde dışarı aktarılabilmesi gibi konuları baştan sormak gerekir. Bir sözleşme veya kullanım koşulu imzalamadan önce "çıkış planı" olarak adlandırabileceğimiz soruların cevabını alın: Hizmetten ayrılırsam verilerimi hangi biçimde, ne kadar sürede alabilirim?

Fiyatlandırma yapısını karşılaştırırken sabit abonelik ile kullanıma bağlı ödeme arasındaki farkı da hesaba katın. Kullanıma dayalı modellerde, işlem hacmi düşük olan küçük bürolar için maliyet öngörülebilir kalabilir; hacim yüksek bürolarda ise aylık toplamı izlemek gerekir. MÜHLET'in güncel fiyatlandırma yapısı için fiyatlar sayfasına bakabilirsiniz; kendi büronuzun hacmine göre hesap yapmak, en sağlıklı karşılaştırmadır. Karşılaştırmayı en az bir yıllık bir dönem için yapın; çünkü yerel kurulumda donanım yenileme ve destek kalemleri genellikle ilk yıldan sonra görünür hale gelir.

Süre ve Tebligat Takibinde İki Modelin Farkı

Dava takibinin kalbi süredir; kaçırılan bir süre, hangi altyapıyı kullandığınızdan bağımsız olarak hak kaybı demektir. Burada iki modelin farkı, hesaplamanın matematiğinde değil, hesaplamanın dayandığı kuralların güncel tutulmasında ve tebligatın büroya ulaşma hızında ortaya çıkar. Elektronik tebligat, muhatabın elektronik adresine ulaştığı tarihi izleyen beşinci günün sonunda tebliğ edilmiş sayılır (Tebligat Kanunu m.7/a). Muhatap tebligatı okumasa da bu sonuç değişmez; erken açmak süreyi öne çekmez, geç açmak ertelemez.

Bu kural, takibin "bir gün sonra bakarım" mantığıyla yürütülemeyeceğini gösterir. Tebligatın düştüğü an ile fark edildiği an arasındaki her gün, aslında süreden gitmiş bir gündür. Bulut modelde bildirimler kullanıcıya hangi cihazda olursa olsun ulaşabilir; yerel kurulumda ise bildirimin gelmesi, programın açık olduğu ve büro bilgisayarının çalıştığı bir zamana bağlı kalabilir. Tatilde veya duruşmadaki avukat için bu önemli bir farktır.

Süre hesabında ise temel kurallar şöyledir: Gün olarak belirlenen sürelerde tebliğ günü sayılmaz; hafta, ay ve yıl sürelerinde süre başladığı güne karşılık gelen günde biter (HMK m.92). Resmî tatiller süreye dahildir; yalnızca son gün hafta sonuna veya resmî tatile denk gelirse süre izleyen ilk iş günü mesai sonunda biter (HMK m.93). Yazılı yargılamada cevap dilekçesi süresi iki hafta, istinaf süresi de iki haftadır. Adli tatil ise her yıl 20 Temmuz ile 31 Ağustos arasındadır ve hukukta süreler tatilde durmaz; son günü tatile rastlayan süre, tatilin bittiği günden itibaren bir hafta uzar (HMK m.104). İdari yargıda bu uzama 7 gündür, tutuksuz ceza işlerinde 3 gündür; icra takip işlemlerinde ve tutuklu işlerde uzama yoktur.

Kural değişikliği ve takvim güncellemesi

Resmî tatil günleri, dini bayram tarihleri ve olası yeni düzenlemeler her yıl takvime yansıtılmak zorundadır. Bulut modelde bu güncelleme merkezî yapılır ve tüm kullanıcılara aynı anda ulaşır. Yerel kurulumda ise takvim ve kural verisinin her bilgisayarda güncellenmesi gerekir; güncelleme atlanırsa, yazılım eski takvimle hesaplamaya devam edebilir. Bu yüzden hangi modeli seçerseniz seçin, süre hesabını yapan bileşenin ne sıklıkla ve nasıl güncellendiğini sormalısınız. Hesabı kendiniz de kontrol etmek isterseniz ücretsiz hukuki süre hesaplama aracını kullanabilirsiniz.

Doğru Modeli Seçmek İçin Adım Adım Yol Haritası

Karar anında sezgiye değil, büronun kendi ihtiyaçlarına dayanan bir değerlendirmeye ihtiyaç vardır. Aşağıdaki adımlar, hangi modele yöneleceğinizi netleştirmek için sırayla uygulanabilir. Her adımı büroda çalışan herkesin görüşünü alarak, özellikle de günlük işi yürüten sekreter ve stajyerleri dinleyerek tamamlamak gerekir; çünkü yazılımı en çok onlar kullanır.

1. Çalışma biçimini yazın. Kaç kişi çalışıyor, kaçı büro dışında, kaçı aynı anda aynı dosyaya bakıyor; bunları açıkça listeleyin.
2. Kritik işleri belirleyin. Süre takibi, tebligat izleme, duruşma takvimi ve görev dağılımı gibi hata kaldırmayan işleri öne alın.
3. Bilgi işlem kapasitesini ölçün. Yedekleme ve güncellemeyi düzenli yürütecek bir kişi veya destek var mı, dürüstçe cevaplayın.
4. Veri ve KVKK gereksinimlerini sorun. Verinin nerede barındırıldığını, kimlerin eriştiğini ve rol bazlı yetkinin nasıl işlediğini yazılı öğrenin.
5. Deneme yapın. Gerçek bir dosya akışıyla kısa bir deneme yürütün; ekibin kullanım kolaylığını ve hızını gözlemleyin.
6. Çıkış planını netleştirin. Gerekirse verileri hangi biçimde ve ne kadar sürede geri alabileceğinizi öğrenin.

Bu yol haritası sonunda çoğu büro, kendi önceliklerinin hangi tarafta olduğunu net biçimde görür. Süre takibi ve tebligat izleme öncelikli ise, ekip dağınıksa ve bilgi işlem desteği sınırlıysa liste bulut modele işaret eder. Veri yerelliği, internetten bağımsız çalışma ve donanım üzerinde tam kontrol öncelikliyse yerel kurulum daha cazip görünür. Kararı verdikten sonra da bir geçiş takvimi çıkarmak, hangi kayıtların önce taşınacağını ve eski düzenin ne zamana kadar paralel izleneceğini belirlemek gerekir.

Karar notu (büro içi kullanım için): Yazılım seçiminde sorulacaklar — 1) Veri nerede barındırılıyor? 2) Yedek ne sıklıkla alınıyor, geri yükleme denendi mi? 3) Resmî tatil ve süre kuralları nasıl güncelleniyor? 4) Rol bazlı yetki var mı? 5) Ayrılırsam verimi nasıl alırım?

MÜHLET Bulut Modelinde Dava ve Süre Takibini Nasıl Çözer?

Bulut modelin getirdiği "her yerden erişim ve güncel kalma" avantajını süre takibine uygulayan bir örnek olarak MÜHLET, avukatlar için geliştirilmiş UETS entegrasyonlu, yapay zekâ destekli bir süre takip ve tebligat yönetim platformudur. Her özelliği, bu yazıda ele aldığımız bir derde karşılık gelir.

Tebligatların büroya geç ulaşması sorunu için MÜHLET, UETS'e düşen e-tebligatları tarayıcı eklentisiyle, avukatın kendi bilgisayarında kendi oturumuyla otomatik alır; şifre MÜHLET'e verilmez ve sunucular UETS'e bağlanmaz. Detaylar UETS entegrasyonu sayfasında yer alır. Tebligat içeriğini okuma yükü için yapay zekâ tebligatı analiz eder; mahkeme, esas numarası, taraflar ve tebligat türünü çıkarır, her çıktı bağımsız bir usul kuralı motoruyla doğrulanır ve düşük güvende avukat onayı ister. Bunun için yapay zekâ tebligat analizi sayfasına bakabilirsiniz.

Süre hesabındaki hata riski için MÜHLET, süreleri Türk adli takvimine göre, yani adli tatil, resmî tatil ve hafta sonu düzeltmeleriyle hesaplar; ayrıntılar süre takibi sayfasında anlatılır. Unutma riskine karşı son güne kadar kademeli olarak e-posta, SMS ve uygulama veya tarayıcı bildirimiyle hatırlatır; kanallar bildirim sistemi sayfasında açıklanır.

Ekip düzeni için ortak, avukat, sekreter ve stajyer rollerine göre yetki tanımlanabilir; dava, müvekkil, duruşma ve görev yönetimi, takvim senkronizasyonu ve iOS ile Android mobil uygulama da sunulur. Veriler Türkiye'de barındırılır ve KVKK uyumlu çalışılır. Hizmet tebligat kredisiyle işler; ilk kullanımda ücretsiz deneme kredisi verilir, böylece gerçek akışınızla kendi değerlendirmenizi yapabilirsiniz. Böylece bulut modelin sunduğu erişim kolaylığını, tebligat akışınız üzerinde somut olarak görebilir ve ekibinizle birlikte karar verebilirsiniz.

Karar Verirken Sık Yapılan Hatalar

Yazılım seçiminde en sık görülen hata, kararı yalnızca fiyat üzerinden vermektir. Ucuz görünen bir yerel kurulum, yedekleme ve bakım maliyeti eklendiğinde pahalı hale gelebilir; ucuz görünen bir bulut aboneliği ise verinin dışarı alınamaması gibi bir kapanı gizliyor olabilir. Kararı toplam sahip olma maliyeti ve riskle birlikte, yani yazılımın hata durumunda büroya ne kaybettireceğiyle birlikte düşünmek gerekir.

İkinci hata, yerel kurulumun "daha güvenli" olduğuna otomatik olarak inanmaktır. Verinin büroda durması, güvenlik önlemlerini kendiliğinden getirmez; güncellenmeyen işletim sistemi, tek kopya halinde duran veri ve herkesin bildiği ortak parola, bu düzenin en yaygın zayıf noktalarıdır. Bulut için de aynısı geçerlidir: hesap güvenliğinin ihmal edilmesi, sağlayıcının güvenlik katmanlarını boşa çıkarır. Her iki modelde de insan faktörü, yani parola alışkanlığı ve yetki yönetimi belirleyicidir.

Üçüncü hata, süre hesabının kaynağını sorgulamamaktır. "Program hesapladı" cümlesi tek başına bir güvence değildir; programın hangi kurallara, hangi takvime dayandığı ve bunun nasıl güncellendiği önemlidir. Aynı şekilde, tebligatın okunma tarihini süre başlangıcı sanmak, e-tebligatta sık görülen bir yanılgıdır. Sürenin ulaşma tarihini izleyen beşinci günün sonuna göre işlediğini unutmayın.

Son olarak, geçişi tek hamlede ve yedeksiz yapmak da sık yapılan bir hatadır. Eski kayıtları yeni sisteme aktarırken bir süre iki sistemi paralel izlemek, kritik duruşma ve süre kayıtlarının doğru taşındığını kontrol etmek, geçişin güvenliğini artırır. Ekibe kısa bir kullanım eğitimi vermeyi de ihmal etmeyin; yeni sistemin ilk haftalarında yapılan küçük giriş hataları, doğrudan süre ve duruşma kayıtlarına yansıyabilir.

Sık Sorulan Sorular

Bu yazı genel bilgilendirme amaçlıdır; somut olayınız için hukuki değerlendirme gerekir.