10 Mar 2026·6 dk
Ülkeler arası dahili uygulama dağıtımı: önce ne planlanmalı?
Bir dahili uygulamayı birden fazla ülkede dağıtmayı mı planlıyorsunuz? Lansman öncesi barındırma bölgesi, diller, roller ve iş akışlarını nasıl seçeceğinizi öğrenin.
Bir dahili uygulamayı birden fazla ülkede dağıtmayı mı planlıyorsunuz? Lansman öncesi barındırma bölgesi, diller, roller ve iş akışlarını nasıl seçeceğinizi öğrenin.
Basit bir dahili uygulama, birkaç ülke işin içine girince dağıtımı zorlaşabilir. Uygulamanın kendisi basit olabilir — izin talep aracı, onay panosu veya dahili CRM — ama her ülke uygulamanın baştan yerel kurallara, alışkanlıklara ve dile uygun olmasını bekler.
Bir ülke verinin nerede barındırıldığına odaklanabilir. Başka bir ülke farklı onay kayıtları, gizlilik ayarları veya belge tutma kuralları isteyebilir. Ekranlar neredeyse aynı görünürken, arka plandaki kurulum değişmelidir.
Süreç farkları başka bir sürtünme katmanı yaratır. Bir ofiste tek bir yönetici onayıyla çözülen bir satın alma talebi, başka yerde finans, hukuk ve departman onayı gerektirebilir. Uygulama çok erken tek bir yol dayatırsa takımlar genellikle e-posta ve tablolarla yolunu bulur. Bu olduğunda güven hızla düşer.
Dil de genellikle küçümsenir. Sadece çeviri problemi çözmez. İnsanlar tanıdık ifadelere, tarih formatlarına, para birimlerine, iş unvanlarına ve politika terimlerine tepki verir. Bir ülkede net gelen bir buton başka bir yerde belirsiz veya riskli görünebilir.
Çoğu gecikme büyük teknik hatalardan değil, küçük kurulum eksiklerinden kaynaklanır. Yerel yöneticiler için rollerin eksik olması, yanlış saat diliminde gelen bildirimler, yerel onay adımlarını atlayan formlar veya politika ile çelişen ifadeler lansmanı engelleyebilir.
Koder.ai gibi platformlarla çalışan bir uygulamayı hızlıca oluşturabilirsiniz, yine de rollout konusunda zorlanabilirsiniz. Zor olan sadece uygulamayı inşa etmek değil; aynı uygulamanın farklı yerlerde doğru, güvenli ve faydalı hissettirilmesidir.
Dil, barındırma veya yerel onay kurallarına girmeden önce neyin değişmemesi gerektiğine karar verin. Her ülkenin aynı sürecin kendi versiyonuna sahip olması durumunda raporlama karışır ve eğitim gerektiğinden daha zorlaşır.
Çekirdek akışla başlayın. Basit bir soru sorun: her takım nerede olursa olsun baştan sona neyi mutlaka yapmalı? Eğer uygulama satın alma taleplerini yönetiyorsa, paylaşılan akış talep, inceleme, onay ve kaydetme olabilir. Bu temel yapı olur.
Sonra her ülkenin yakalaması gereken verileri tanımlayın. Bu listeyi kısa tutun. Sahip olunması gerçekten gereken bilgilere odaklanın: talep sahibi, tarih, tutar, departman ve onay sonucu gibi. Bir ülke ek vergi veya hukuk alanları istiyorsa bunları global asgari parçası yerine yerel ek olarak ele alın.
Paylaşılan adlandırma birçok takımın beklediğinden daha önemlidir. Bir ofis "İnceleniyor" derken başka bir ofis "Beklemede" ve üçüncü bir ofis "Açık" diyorsa, üçü aynı anlama gelse bile raporlar okunması zorlaşır. Tüm şirket için bir alan ve durum isimleri seti seçin, sonra ifadeyi anlamı değiştirmeden çevirin.
Kullanışlı bir kural basittir:
Ayrıca burada neyin değişebileceğine ve neyin değişmemesi gerektiğine karar verirsiniz. Yerel takımlar farklı onay seviyelerine, tatil takvimlerine veya belge formatlarına ihtiyaç duyabilir. Ancak ana tanımlar, temel kayıtlar ve nihai sonuçlar genellikle sabit kalmalıdır.
Bu disiplin sonradan karşılığını verir. Paylaşılan yapı net olduğunda uygulamayı açıklamak, takımları eğitmek ve her ülke için aynı ekranları yeniden inşa etmeden değişiklik yapmak çok daha kolay olur.
İyi bir test basittir: bir ülkedeki yönetici, başka bir ülkeden gelen bir raporu açıp hemen anlayabiliyor mu? Eğer evet ise temeliniz muhtemelen yeterince güçlü demektir.
Uygulamanızın nerede çalıştığı hızdan daha fazlasını etkiler. Çok ülkelilik rollout'unda barındırma yasal riski, destek kapsamını ve yerel takımların sistemi kullanırken kendilerini ne kadar rahat hissettiklerini şekillendirir.
Kullanıcılarınızın basit bir haritasıyla başlayın. Günlük kullanıcıların çoğu Almanya, Brezilya ve Singapur'daysa, sadece merkez ofisin ABD'de diye bir barındırma bölgesi seçmeyin. Uzak bir bölge uygulamayı yavaş hissettirebilir, özellikle panolar, arama ve günlük kullanılan onay akışları için.
Sonra veri kurallarını lansmandan önce gözden geçirin, sonra değil. Bazı ülkeler veya sektörler çalışan verilerinin, müşteri kayıtlarının veya finansal detayların belirli bir bölgede kalmasını bekleyebilir. Yerel barındırma kesin olarak gerekmediğinde bile hukuk veya güvenlik ekipleri gizlilik ve denetim sebepleriyle bunu tercih edebilir.
Pratik bir karar genellikle dört şeye dayanır: kullanıcıların çoğu nerede, uygulama hangi verileri saklıyor, uyumluluk için bölgesel barındırma gerekli mi ve bir şeyler ters giderse kim destek verecek. Hız önemlidir ama tek hedef değildir. Biraz daha yavaş bir bölge, daha net uyumluluk ve daha kolay destek sunuyorsa genellikle daha güvenli bir seçenektir.
Yedekler ve kurtarma aynı tartışmanın parçası olmalıdır. Yedeklerin nerede saklandığını, ne sıklıkla çalıştığını ve kötü bir dağıtım veya veri hatasından sonra ne kadar hızlı hizmetin geri getirilebileceğini bilmeniz gerekir. Bir ülke ekibinin uygulamaya her gün bağımlı olması durumunda zayıf kurtarma planlaması biraz ekstra gecikmeden daha büyük zarar verebilir.
Koder.ai üzerinde inşa ediyorsanız, uygulamaları küresel ve belirli ülkelerde çalıştırma yeteneği, ekipler farklı veri transfer kurallarıyla karşılaştığında yardımcı olabilir. Bu, her ofisi tek bir varsayılan bölgeye zorlamak yerine dağıtımı yerel ihtiyaçlara uyacak şekilde eşleştirmeyi kolaylaştırır.
Hâlâ emin değilseniz, en hassas verilerinize ve en büyük kullanıcı grubunuza en iyi uyan bölgeyi seçin, ardından pilot sonrası performans ve uyumluluğu gözden geçirin.
Dil sorunları genellikle tam çeviriyle başlamaz. Küçük ayrıntılarla başlar; bir ülkede uygulamanın doğal, başka bir yerde garip hissetmesine neden olan detaylarla.
İnsanların en çok kullandığı bölümlerle başlayın: gezinme, butonlar, form alanları, durum adları, hata mesajları ve onay adımları. Raporlar, yardım metinleri ve yönetici ayarları zaman kısıtlıysa bekleyebilir. İlk gün hedefi her kelimeyi çevirmek değil; günlük işi etkileyen kısımları çevirmektir.
Doğrudan çeviri yerelleştirmenin sadece bir parçasıdır. Bilginin nasıl gösterildiğini de ayarlamanız gerekir. Tarih formatı, saat formatı, para birimi gösterimi, ondalık ayırıcılar, adres alanları, telefon numarası kalıpları ve takım etiketleri kullanımı kolaylaştıracak şekilde değişebilir.
Bu ayrıntılar önemlidir çünkü bir ekran alışılmadık görünürse insanlar hata yapar. Almanya'daki bir finans yöneticisi, ABD'deki bir satış lideri ve Japonya'daki bir operasyon ekibi aynı sayıları ve etiketleri farklı okuyabilir eğer biçim garip geliyorsa.
Dahili jargon özel dikkat ister. Merkez ofiste normal gelen bir ifade başka yerde belirsiz veya çok samimi gelebilir. Jargonu kelime kelime çevirmek yerine etiketin günlük işte ne anlama gelmesi gerektiğine karar verin ve en açık yerel ifadeyi seçin.
Gerçek kullanıcı testi burada mükemmel çeviri dosyalarından daha değerlidir. Uygulamayı gerçekten kullanan birkaç hızlı geri bildirim, tek bir paydaş tarafından yapılan son dil incelemesinden genellikle daha faydalıdır. Onlara hangi etiketlerin doğal gelmediğini, neyin belirsiz olduğunu ve hangi terimleri beklediklerini sorun.
Bu tür geri bildirim formlardaki, durum etiketlerindeki ve onay ekranlarındaki sorunları erken yakalar. Ayrıca yerel ifade işini sondan bir rötuş görevi gibi görmek yerine erken tutmanızı sağlar.
Erişim sorunları rollout'un ilk haftasında işi rayından çıkarabilir. İnsanlar ihtiyacı olanı göremezse veya çok fazla kişi kritik verileri değiştirebiliyorsa uygulama hem sinir bozucu hem de riskli olur.
Önce en önemli eylemleri tanımlayın: kim görüntüleyebilir, kim düzenleyebilir, kim onaylayabilir ve kim dışa aktarabilir. Bu dört eylem genellikle günlük kullanıcılar, takım liderleri, finans, İK ve ülke yöneticileri arasındaki gerçek farkı ortaya çıkarır.
Basit bir kural iyi işler: her role yalnızca işini yapmak için gereken erişimi verin. Yerel operasyon lideri bir ülke için talepleri onaylayabilir ama global ayarları düzenlememelidir. Bir finans inceleyicisi raporlama için dışa aktarma erişimine ihtiyaç duyabilir ama kayıtları değiştirme yetkisi olmayabilir.
Yerel kontrolü global kontrolden ayırmak da yardımcı olur. Yerel yöneticiler kendi ülke takımları için kullanıcıları, ayarları veya iş akışlarını yönetmeli. Global yöneticiler şirket çapı kurallardan, paylaşılan şablonlardan, güvenlik ayarlarından ve her bölgeyi etkileyen her şeyden sorumlu olmalıdır.
Bu ayrım sık görülen bir problemi önler: bir ülkenin yaptığı ayar değişikliği başka yerde süreci bozmaz. Ayrıca denetimleri kolaylaştırır çünkü kimin yerel yetkisi ve kimin tam sistem kontrolü olduğu görülebilir.
Lansman öncesi geçici ve paylaşılan hesapları dikkatle gözden geçirmek de yardımcı olur. Kurulum girişleri, geçiş hesapları ve demo kullanıcılar genellikle planlanandan daha uzun süre aktif kalır. Paylaşılan hesaplar daha kötüdür çünkü kim değişiklik yaptı net olarak takip edilemez.
Go-live öncesi birkaç temel işi yaptığınızdan emin olun:
Lansmandan sonra erişimi düzeltmek her zaman daha zordur. Roller erken tanımlamak ve bunları uygulama geniş kitleye ulaşmadan önce gerçek senaryolarla test etmek daha iyidir.
Rollout'lar genellikle günlük işlerin aslında aynı olmadığı yerde başarısız olur. İki ülke takımı aynı uygulamayı masraf talepleri, işe alım veya tedarikçi onayı için kullanıyor olabilir, ama o işin arkasındaki adımlar çok farklı olabilir.
Uygulamanın nasıl görünmesi gerektiğiyle başlamayın. Her yerin işi zaten nasıl yaptığını gözlemleyerek başlayın.
Her ülke için mevcut süreci yazın. Somut tutun. Talebi kim başlatıyor? Kim inceliyor? Hangi belgeler gerekli? Görevin tamamlanması ne zaman sayılır? Kısa bir yan yana karşılaştırma genellikle gerçek sorunları hızlıca ortaya çıkarır.
Şu sorulara bakın: kim talep gönderebilir, hangi yönetici veya takım onaylar, finans, İK veya hukuk incelemesi gerekiyor mu, hangi yerel alanlar veya belgeler gerekli ve süreç ne zaman düzeltme için geri döner.
Küçük farklılıklar daha sonra büyük sorunlar yaratır. Bir takım bir tedarikçiyi eklemeden önce vergi kimlik numarası alanına ihtiyaç duyabilir. Başka bir yerde belirli bir tutarın üstünde hukuki inceleme gerekebilir. Başka bir yerde düşük değerli satın almalarda daha hızlı bir yol olabilir.
Her fark ayrı bir iş akışı gerektirmez. Bazı farklar yerel ifadeyle, bir ekstra alanla veya basit bir kural değişikliğiyle halledilebilir. Sıra gerçekten değişiyorsa ayrı bir akış kullanın. İnsanların farklı adımlara, farklı zamanlamaya veya farklı kararlara ihtiyaç duyduğu durumlar gerçekten farklı bir süreçtir.
Pratik bir kural: aynı ekran ve aynı sıra hâlâ mantıklıysa ayarları kullanın. Değilse ayrı bir yol oluşturun.
Her yerel istisnanın tek bir paylaşılan kaydını tutun. Neyin farklı olduğunu, neden farklı olduğunu, kimin bu seçeneği onayladığını ve ne zaman tekrar gözden geçirileceğini yazsın. O kayıt olmadan takımlar tahmin etmeye başlar ve uygulama yavaşça yamalı bir hal alır.
Güçlü bir rollout küçük başlar. Herkese aynı anda açarsanız küçük sorunlar hızla destek problemlerine dönüşür.
En güvenli yaklaşım bir ülke, bir takım ve gerçek günlük iş ile pilot yapmaktır. Ortak görevleri yapan ve yararlı geri bildirim verecek bir takım seçin. Pilotu yönetilebilir ama normal kullanımda ne kırılacağını gösterecek kadar gerçek tutun.
Basit bir rollout sırası iyi işler:
Pilot, insanların canlı veri, gerçek onaylar ve gerçek teslim tarihlerinde kullandığında en çok önemlidir. Test verileri daha sonra sürtünme yaratan küçük şeyleri gizleme eğilimindedir: belirsiz alan adları, eksik izinler veya yerel alışkanlıklara uymayan iş akışı adımları gibi.
Pilot sonrası durun ve olanları gözden geçirin. Kullanıcıların nerede takıldığını, hangi rollerin eksik veya fazla geniş olduğunu, hangi ifadelerin kafa karıştırdığını ve hangi iş akışı adımlarının ülkeye göre değişmesi gerektiğini inceleyin. Sonra genişletmeden önce bu sorunları düzeltin.
Bu ara, takımların zaman kazanmasını sağlar. Dalga arasında kısa bir boşluk, geniş bir lansmandan sonra dağınık bir yeniden lansmandan çok daha ucuzdur.
Akışları, izinleri ve dağıtımları hızlıca ayarlamaya izin veren araçlar bu aşamada çok yardımcı olabilir. Örneğin Koder.ai snapshot ve rollback destekler; bu, değişiklikleri test ederken güvenli geri dönüşler yapmanız ve her rollout dalgasını kontrol altında tutmanız için faydalıdır.
Fransa, Brezilya ve Japonya takımları tarafından kullanılan bir İK istek uygulamasını düşünün. Amaç üç ayrı araç değil. Amaç tek bir paylaşılan yapı tutmak ama her ülkenin kendi ihtiyacı doğrultusunda çalışmasına izin vermektir.
Talep formu hemen hemen her yerde aynı kalabilir: çalışan adı, istek türü, tarihler, sebep ve gerekirse destekleyici belgeler. Bu raporlamayı temiz tutar ve uygulamayı sürdürmeyi kolaylaştırır.
Değişen şey onay yolu olur. Fransa'da bir izin isteği önce takım liderine sonra İK'ya gidebilir. Brezilya'da bordroyla ilgili isteklere finans da bakmak zorunda olabilir. Japonya'da süreç daha resmi bir zincir gerektirip İK onayından önce ek bir yönetici incelemesi isteyebilir.
Birçok takımın keşfettiği desen budur: uygulama yüzeyde aynı görünürken arkasındaki kurallar konuma göre değişir.
Arayüzün de uyum sağlaması gerekir. Fransa'daki bir kişi Fransızca etiketler ve gün-ay-yıl tarih düzeni görmelidir. Brezilya'daki biri Portekizce ve yerel biçimlendirme görmelidir. Japonya'dakiler bekledikleri dil ve yapıyı görmelidir. Tarih sırası, durum adları ve isim alanları gibi küçük detaylar hata ve destek taleplerini azaltır.
Erişim ilk günden net olmalıdır. Çalışanlar kendi isteklerini oluşturup takip edebilmeli. Yerel yöneticiler kendi ülkelerindeki istekleri inceleyip onaylamalı. Yerel İK takımları politika kontrolleri ve istisnalarla ilgilenmeli. Global yöneticiler tüm ülkeler için özet panolar görmeli; global adminler paylaşılan ayarlar, raporlar ve rol kurallarını yönetmelidir.
Bu denge genellikle hedeftir: tek bir uygulama, tek bir paylaşılan veri modeli ve gerçekten gerektiğinde yerel yollar.
Çoğu rollout problemi uygulamanın kendisinden değil, ilk başta zararsız görünen acele kararların yarattığı yükten kaynaklanır. Bu kararlar sonrasında her yerel takım için ekstra iş oluşturabilir.
İlk hata herkese tek bir iş akışı dayatmaktır. Almanya'da mantıklı gelen bir süreç Brezilya'daki bir takımı yavaşlatabilir. Çekirdek süreci tutarlı bırakın ama gerçekten önemli olduğunda yerel adımlar için alan bırakın.
Bir diğer yaygın hata çeviriyi son rötuş olarak görmek. Yerel ifadeler son haftada göründüğünde, takımlar genellikle belirsiz butonlar, garip alan adları ve günlük işlemlerle uyuşmayan terimlerle kalır. Bu hatalar hatalara, destek taleplerine ve insanların tekrar tablolarla çalışmaya dönmesine yol açar.
Erişim de takımların kestirme yaptığı bir alandır. Geniş admin hakları lansmanı kolaylaştırmış gibi görünse de sonrasında genellikle daha büyük bir karmaşa yaratır. Hassas veriler, ayarlar ve onaylar yalnızca gerçekten ihtiyaç duyanların görebileceği şekilde olmalıdır.
Zamana bağlı detaylar da kolayca kaçırılır. Farklı çalışma haftaları, yerel tatiller ve birden fazla saat dilimi son teslimleri, bildirimleri ve destek kapsamını etkiler. Bu detaylar kurulum sırasında küçük gözükür; günlük karışıklık başladığında önemi ortaya çıkar.
Bir yedek plan lansman planı kadar önemlidir. Bir onay kuralı başarısız olursa veya bir form kullanıcıları karıştırırsa insanların güvenli bir yedek sürece ihtiyacı olur. Bu geçici manuel bir süreç, bir rollback noktası veya tam açık sürümden önce küçük bir pilot grup olabilir.
Kullanışlı bir son test basittir: her ülke takımından bir kişiye baştan sona gerçek bir görev tamamlatın. Küçük sorunlar genellikle çok hızlı ortaya çıkar.
Uygulama ülkeler çapında canlıya alınmadan önce genellikle sorun yaratan ayrıntıları son bir kez gözden geçirin. Kurulumdaki küçük boşluklar birkaç takım aynı anda sistemi kullanmaya başlayınca günlük destek sorunlarına dönüşebilir.
Gerçek dünya testiyle başlayın, varsayımlarla değil. Bir barındırma seçimi kağıt üzerinde uygun görünebilir ama yine de her pazarın güvenlik, hukuk veya veri kurallarından sorumlu kişilerin onayını alması gerekir.
Son kontrolünüz birkaç temel konuyu kapsamalıdır. Her barındırma bölgesinin ilgili iç sahipler tarafından onaylandığını teyit edin. Ön saflardan yöneticilere ve adminlere kadar her rol için gerçek test hesaplarıyla giriş yapın. Dil, tarih formatları, para birimi gösterimi ve bildirim metinlerini gözden geçirin. Her ülkede bir tam görevi ilk girdiden son onay veya rapora kadar çalıştırın. Sonra yayından sonra yapılacak değişiklikleri büyük bir istek listesi yerine küçük, net güncellemeler olarak not edin.
Bu uçtan uca test birçok takımın beklediğinden daha önemlidir. Bir form mükemmel çalışıyor olabilir ama bir yöneticinin devralması eksik bir alan, yerel onay adımının olmaması veya bir bildirimin kafa karıştırıcı metni yüzünden hâlâ başarısız olabilir.
Lansmandan sonra her şeyi aynı anda değiştirme dürtüsüne direnin. En büyük engelleri önce düzeltin, sonra uygulamayı küçük adımlarla iyileştirin. Bu takımların her hafta sürecin değiştiğini hissetmeden adapte olmasına yardımcı olur.
Düzenli kalmak için geri bildirimleri üç gruba ayırmak işe yarar: acil düzeltmeler, yerel istekler ve herkes için yeni standart olması gereken fikirler. Bu ülkeye özgü ihtiyaçları görünür tutar ama paylaşılan uygulama kontrolünü kaybetmezsiniz.
Yeni ülkeler çevrimiçi oldukça sürümleri hızla ayarlamanız gerekiyorsa, Koder.ai ülke-spesifik kurulumları daha geniş bir yayın öncesinde test etmek için pratik bir seçenek olabilir. Bu özellikle genel iş akışı benzer kaldığında ama son detaylar bölgeye göre değiştiğinde faydalıdır.
Önce her yerde aynı kalması gereken parçaları tanımlayın: çekirdek iş akışı, zorunlu veriler ve alanlar ile durumların ve alan adlarının anlamı. Bu temel sabitlenince, yalnızca yasal veya operasyonel ihtiyaçlar gerektiriyorsa yerel değişiklikler ekleyin.
Genellikle ayrı uygulamaya gerek yok. Tek bir paylaşılan uygulama raporlama, eğitim ve bakım açısından daha kolaydır. Varsayılan yaklaşım, süreç gerçekten değiştiğinde yerel ayarlar, ek alanlar veya ayrı onay yolları kullanmaktır.
En büyük kullanıcı grubunuz, en hassas verileriniz, yerel uyumluluk gereksinimleri ve uygulamayı kimlerin destekleyeceği temel kriterler olmalıdır. Hız önemlidir ama gizlilik ve denetim gereksinimlerini karşılayan bir bölge çoğu zaman daha güvenli bir tercih olur.
Çeviri yalnızca bir parçadır. Ayrıca yerel tarih ve saat biçimleri, para birimi gösterimi, alan etiketleri, durum adları ve ülkedeki kişiler için işe yarar terimler de gerekir.
Önce gerçek eylemler etrafında roller tanımlayın: kim görüntüleyebilir, kim düzenleyebilir, kim onaylayabilir ve kim dışa aktarabilir. Ardından yerel yönetici haklarını global yöneticilerden ayırın, böylece ülke ekipleri kendi işlerlerini yönetirken şirket çapındaki ayarları değiştiremezler.
Her ülkenin gerçek sürecini yazın ve adımları yan yana karşılaştırın. Aynı ekran sırası işe yarıyorsa ayarlar veya ek alanlarla ilerleyin. Adımlar, zamanlama veya kararlar farklıysa ayrı bir iş akışı yolu oluşturun.
Gerçek iş akışıyla, canlı verilerle ve gerçek onaylarla küçük bir ülke ve ekip üzerinde pilot yapın. Ana sorunları düzeltin, kullanıcıların nerede zorlandığını inceleyin ve sonra dalgalar halinde genişletin; aynı anda herkese açmak yerine.
Aşırı geniş yönetici erişimi, geç yapılan çeviri çalışmaları, eksik yerel onay adımları, yanlış saat dilimi ayarları ve bir yedek planın olmaması sık karşılaşılan sorunlardır. Kurulum sırasında küçük görünen bu hatalar, lansmandan sonra benimsemeyi yavaşlatır.
Her ülkede gerçek rollere sahip hesaplarla uçtan uca test çalıştırın. Barındırma onayı, izinler, dil, biçimlendirme, bildirimler, onaylar ve raporlama gibi konuları go-live öncesi kontrol edin.
Evet. Hızla inşa ederken, belirli ülkelerde dağıtım yapma ve rollout sırasında akışları ayarlama ihtiyaçlarınız için yardımcı olabilir. Koder.ai ayrıca snapshot ve rollback desteği sunar; bu, ülke spesifik değişiklikleri test ederken ve bir sorun çıkarsa güvenli geri dönüş yaparken kullanışlıdır.