Uygulama arşivleme stratejisi: Kayıtları dikkatle saklayın

Eski kayıtların belirli bir yere ihtiyacı vardır

Uygulamalar çoğu ekibin beklediğinden daha hızlı dolar. Kapatılmış destek vakaları, tamamlanmış siparişler, eski kullanıcı profilleri, denetim günlükleri ve taslak kayıtlar, günlük işlerde kimsenin onlara ihtiyacı kalmadıktan sonra bile görünür olmaya devam edebilir. Arama sonuçları kalabalıklaşır, ekranları taramak daha uzun sürer ve çalışanlar yanlışlıkla yanlış kaydı açabilir.

Aktif veriler şu anda devam eden işleri destekler. Arşivlenmiş verilerin amacı farklıdır: ekip onları yasal bir kural, müşteri talebi, finansal kontrol veya geçmişte alınmış bir karar nedeniyle daha sonra gerekebileceği için saklar. Bu grupları ayırmak, ihtiyaç duyulabilecek bilgileri silmeden daha düzenli bir çalışma alanı sağlar.

Her şeyi aynı yerde tutmak da risk yaratır. Dosyalar biriktikçe depolama maliyetleri artar. Raporlar güncelliğini yitirmiş kayıtları içerebilir ve yöneticilere gerçeği yansıtmayan bir tablo sunabilir. Kişisel bilgileri gerekenden uzun süre saklamak, özellikle eski müşteriler veya çalışanlar günlük araçlarda hâlâ görünüyorsa, gizlilik sorunlarına yol açabilir.

İyi bir arşiv politikası her kayıt türü için iki soruyu yanıtlar: Bu kaydı neden saklıyoruz ve ne kadar süreyle ihtiyacımız var? Politika, aktif kullanım sona erdikten sonra kaydın nereye gideceğini de belirtmelidir. Arşiv unutulmuş bir klasör değildir. Çalışanların geçerli nedenlerle eski kayıtları bulabilmesi gerekir; rutin aramalar ise güncel işlere odaklanmalıdır.

Örneğin bir destek ekibi, açık ve yakın zamanda kapatılmış vakaları ana çalışma alanında tutabilir. 18 aydan uzun süre önce kapatılan vakalar, bir şikayet incelemesi sırasında yöneticinin geri alabileceği bir arşive taşınabilir. Böylece temsilciler, yıllar önce çözülmüş sorunları ayıklamak zorunda kalmadan güncel vakaları arayabilir.

AppMaster ile bir iç araç oluşturuyorsanız bu ayrımı kayıt sayısı büyümeden planlayın. Aktif ve arşivlenmiş kayıtlar için ayrı görünümler oluşturabilir, uygun kayıtları taşımak için iş süreçlerini kullanabilir ve arşiv erişimini role göre sınırlayabilirsiniz. Her kaydı açık bir nedenle saklayın, sakladığınız sürece koruyun ve bu neden ortadan kalktığında kaldırın.

Kayıt envanteriyle başlayın

Uygulamanın hangi verileri tuttuğu bilinmiyorsa arşiv politikası aksar. İşe pratik bir envanterle başlayın. Uygulamaya giren, uygulamadan çıkan veya uygulamada kalan her kayıt türünü listeleyin.

Yaygın kayıtlar arasında müşteri talepleri, faturalar, destek vakaları, kullanıcı profilleri, sözleşmeler, ödeme kayıtları, dışa aktarılan raporlar ve denetim günlükleri bulunur. Terk edilmiş form gönderimleri ve taslak siparişler gibi geçici kayıtları da ekleyin. Bunlar, depolama, gizlilik veya arama sorunlarına yol açana kadar çoğu zaman fark edilmez.

Her kayıt türü için şu dört ayrıntıyı yazın:

• Desteğin, finansın, satışın veya operasyonun oluşturduğu ya da kullandığı ekip
• Çalışanların bu kayda günlük iş için mi, yoksa ara sıra başvurmak için mi ihtiyaç duyduğu
• Kaydın bulunduğu uygulama, veritabanı, paylaşılan klasör veya harici hizmet
• Faturanın müşteri hesabına bağlı olması gibi, başka kayıtların bu kayda bağlı olup olmadığı

Günlük kullanılan veriler kolayca aranıp açılabilmelidir. Eski başvuru verileri, çalışanlar bunlara nadiren ihtiyaç duyuyorsa ana çalışma alanından çıkarılabilir. Bu ayrım yalnızca kaydın yaşına bakmaktan daha önemlidir. Kapatılmış bir destek vakası, temsilciler yakın konuşmaları sık sık incelediği için altı ay görünür kalabilir. On yıllık bir vakaya ise yalnızca müşteri geçmişteki bir soruna itiraz ederse ihtiyaç duyulabilir.

Ana uygulamanın dışında saklanan kayıtları da ekleyin. Finans faturaları bir muhasebe hizmetinde tutarken destek ekibi vaka notlarını bir yardım masası aracında saklayabilir. Ekipler raporları çoğu zaman paylaşılan depolama alanına aktarır ve bu kopyaların da kendi saklama kurallarına ihtiyaç duyduğunu fark etmez.

AppMaster ile oluşturulan iç araçlarda veri modellerini, oluşturulan API kayıtlarını, yüklenen dosyaları ve ödeme ya da mesajlaşma gibi bağlı modülleri envantere dahil edin. Dağıtımdan sonra her öğenin nereye gideceğini not edin. Ekibin saymadığı kayıtları koruyamazsınız.

İlk envanter için her kayıt türüne bir satır ayırmak yeterlidir. Envanteri bu kayıtları kullanan kişilerle birlikte gözden geçirin. Onlar, uygulama sahibinin fark etmediği bağımlılıkları ve eski dosyaları çoğu zaman bilir.

Uygulanabilir veri saklama süreleri belirleyin

Saklama süresi, bir kaydı silmeden veya uzun süreli depolamaya taşımadan önce ne kadar tuttuğunuzu belirtir. Süreleri gerçek ihtiyaçlara göre belirleyin: yasal düzenlemeler, müşteri sözleşmeleri, vergi kuralları, anlaşmazlıklar ve günlük operasyonlar. Kimsenin açıklayamadığı veya uygulayamadığı bir kural, kayıtlar biriktiğinde işe yaramaz.

Her dosya ve veritabanı satırı için tek bir kural kullanmaktan kaçının. Farklı kayıtların taşıdığı riskler farklıdır. İmzalı bir müşteri sözleşmesinin yıllarca saklanması gerekebilirken yinelenen bir içe aktarma raporu yalnızca birkaç hafta işe yarayabilir. Uygulama arşivleme stratejiniz her kayıt grubunu adlandırmalı ve açık bir süre belirlemelidir.

Basit bir politika şöyle olabilir:

• Faturaları ve ödeme kayıtlarını vergi ve muhasebe kurallarının gerektirdiği süre boyunca saklayın.
• Müşteri sözleşmelerini sözleşme süresi ve talepleri ele almak için gereken ek süre boyunca saklayın.
• Kapatılmış destek vakalarını belirli sayıda yıl saklayın. Aktif bir anlaşmazlık daha uzun saklama gerektiriyorsa istisna uygulayın.
• Geçici yüklemeleri, başarısız içe aktarmaları ve test kayıtlarını kısa bir süreden sonra silin.

Süreyi başlatan olay, yıl sayısı kadar önemlidir. Bunu açıkça yazın. Bir sözleşme süresi, birinin sözleşmeyi yüklediği tarihte değil, sözleşmenin sona erdiği tarihte başlayabilir. Destek vakası süresi, vakanın kapandığı tarihte başlayabilir. Çalışan kaydı için başlangıç, iş ilişkisinin sona erdiği tarih olabilir.

Kuralları uygulamada kullanılabilir hale getirin

Başlangıç olayını, uygulamanın izleyebileceği bir alanda saklayın. Örneğin «vaka kapanış tarihi» veya «sözleşme bitiş tarihi». Elle yapılan hesaplamalar tutarsız kararlara yol açar. AppMaster'da ekipler bu tarihleri Data Designer'da modelleyebilir ve saklama tarihi geldiğinde kayıtları işaretlemek için görsel bir iş süreci kullanabilir.

İstisnaları görünür tutun. Yasal bekletme, denetim veya açık müşteri şikayeti normal silme işlemini durdurabilir. Bekletmeyi kimin koyduğunu, nedenini ve ekibin ne zaman yeniden incelemesi gerektiğini kaydedin. Bu bilgiyi özel bir nota veya gelen kutusuna saklamayın.

Hukuk, uyum, finans veya gizlilikten sorumlu kişiden kuruluşu etkileyen süreleri incelemesini isteyin. Ekip bir kuralı otomatikleştirmeden önce yerel gereklilikleri ve sözleşme yükümlülüklerini doğrulayabilirler. Yeni bir pazara girdiğinizde, sözleşme şablonunu değiştirdiğinizde veya yeni bir kayıt türü eklediğinizde politikayı gözden geçirin.

Çalışanların tekrarlayabileceği bir talimat olmalıdır: Bu kaydı şu tarihe kadar sakla, ardından politikaya göre arşivle veya kaldır.

Açık arşiv ölçütleri seçin

Bir uygulama arşivleme stratejisi, insanların ve yazılımın tutarlı biçimde uygulayabileceği kurallara ihtiyaç duyar. «Eski» çok belirsizdir. Arşiv kararlarını uygulamada zaten kayıtlı olan olaylara bağlayın. Örneğin vakanın kapanması, sözleşmenin sona ermesi veya hesabın pasif hale gelmesi.

Bir destek vakası, temsilci vakayı kapattığında ve kimse 90 gün boyunca yeniden açmadığında arşivlenmeye uygun olabilir. Bir müşteri sözleşmesi, bitiş tarihinden sonra ve finans ekibi son ödemeyi kaydettiğinde taşınabilir. Bu kurallar her taşıma için açık bir neden sunar ve yanlışlıkla arşivlemeyi azaltır.

Yeni bir manuel kontrol listesi oluşturmadan önce mevcut alanları kullanın. Durum, kapanış tarihi, ödeme durumu, sözleşme bitiş tarihi, son giriş tarihi ve anlaşmazlık işareti çoğu zaman yeterlidir. AppMaster'da ekipler bu alanları Data Designer'da modelleyebilir ve bunları zamanlanmış olarak kontrol etmek için iş süreçlerini kullanabilir.

Bir kayıt, kendi türüne bağlı tüm koşulları karşılamalıdır. Kapatılmış bir destek vakasının ve tamamlanmış bir ödemenin iş ve hukuk ihtiyaçları aynı değildir.

Otomasyon başlamadan önce istisnaları ekleyin

Bazı kayıtlar depolamaya hazır görünür, ancak aktif kalmaları gerekir. Açık bir anlaşmazlık, denetim, iade talebi, yasal bekletme veya bağlı aktif vaka arşivlemeyi engellemelidir. Çalışanların yorumlara veya hafızaya güvenmemesi için bu engeli özel bir alanda saklayın.

Her kuralı sade bir dille yazın. Örneğin:

• Kapatılmış bir destek vakasını, anlaşmazlık veya denetim açık değilse yeniden açılmadan geçen 90 günün ardından arşivleyin.
• Son ödeme durumu tamamlandığında, sözleşmenin bitiş tarihinden 30 gün sonra sözleşmeyi arşivleyin.
• Giriş yapılmadan geçen 12 aydan sonra pasif hesabı arşivleyin. Ancak hesapta aktif abonelikler veya çözülmemiş talepler varsa arşivlemeyin.
• Yasal bekletme altındaki kayıtları, yetkili bir kişi bekletmeyi kaldırana kadar aktif sistemde tutun.

Manuel onayı tanımlayın

Otomasyon her durumu kapsamaz. Kayıt yöneticisi veya ekip lideri gibi manuel arşivlemeyi onaylayabilecek rolü belirleyin. Bu kişinin nedeni, tarihi ve kayıt kimliğini yazmasını zorunlu tutun. Bu izni küçük bir grupla sınırlayın.

Birisi kaydı vaktinden önce arşivlemek istediğinde de aynı kural geçerlidir. Satış yöneticisi talepte bulunabilir, ancak yetkili onaylayan kişi önce bağlı faturaları, açık görevleri ve saklama gerekliliklerini kontrol etmelidir. Bu inceleme, tamamlanmış görünen bir kaydın başka bir ekip hâlâ ihtiyaç duyarken ortadan kaybolmasını önler.

Arşive hangi bilgilerin taşınacağını belirleyin

Arşiv, eski işlere ulaşmayı zorlaştırmadan karmaşayı azaltmalıdır. Çoğu çalışan bunlara ihtiyaç duymuyorsa aktif olmayan kayıtları varsayılan arama sonuçlarından çıkarın. Böylece satış ve destek ekipleri yıllar öncesinden kalmış yüzlerce kapalı öğe yerine önce güncel işleri görür.

Temel geri alma ayrıntılarını korumadan kayıt taşımayın. Sabit kayıt kimliğini, bağlı kişiyi veya hesabı, önemli tarihleri, mevcut durumu ve arşiv tarihini saklayın. Kısa bir kapanış nedeni, birinin kaydın neden var olduğunu anlaması gerektiğinde zaman kazandırır.

İlgili bilgilere ilişkin açık bir kural gerekir. Kapatılmış bir destek vakasında mesajlar, yüklenen ekran görüntüleri, ödeme ayrıntıları ve müşteri profiline bağlantılar bulunabilir. Vakanın tamamının birlikte mi taşınacağına, bazı dosyaların aktif depolamada mı kalacağına veya hassas öğelerin ayrı saklama kurallarına mı tabi olacağına karar verin.

Tipik bir arşiv paketi şunları içerir: ana kayıt ve kimliği, oluşturulma ve arşivlenme tarihleri, durum ve sahibi, kapanış nedeni, ilgili mesajlar ve dosyalar, ayrıca aktif kalan bağlı kayıtlara referanslar.

İş olayını bir neden olmadan birkaç yere bölmekten kaçının. Eski sipariş arşive taşınırken iade notu aktif sistemde kalırsa çalışanlar eksik bir geçmiş görebilir. Eski vakalar günlük görünümlerden ayrılsa bile aktif müşteri profili genellikle erişilebilir kalmalıdır.

Raporların da kendi kuralları olmalıdır. Finans, uyum ve eğilim raporları arşivlenmiş kayıtlara ihtiyaç duyabilir. Günlük iş yükü raporları ise genellikle yalnızca aktif öğeleri kullanmalıdır. Tam ayrıntıların denetim veya inceleme için hazır tutulduğu bir aylık arşiv özeti, rutin raporlama için çoğu zaman yeterlidir.

AppMaster'da ekipler arşiv durumunu ve tarihlerini Data Designer'da modelleyebilir, ardından uygun kayıtları taşımak ve bunları hangi görünümlerin içereceğini kontrol etmek için iş süreçlerini kullanabilir. Kuralları yılların geçmişine uygulamadan önce küçük bir gerçekçi kayıt grubuyla test edin.

İhtiyaç duymadan önce geri yükleme adımlarını yazın

Bir arşiv ancak çalışanlar bir kaydı karışıklık yaşamadan bulabildiğinde işe yarar. Veri geri yükleme sürecini ekip kayıt yapısını, izinleri ve iş kurallarını hâlâ biliyorken yazın.

Geri yükleme talebinde kimin bulunabileceğini belirleyin. Bir destek temsilcisi müşteri takibi için kapatılmış bir vakaya ihtiyaç duyabilir. Finans kaydı için ise yöneticinin veya uyum sorumlusunun onayı gerekebilir. Talepleri basit tutun, ancak ekibin tekrarlanan sorunları veya olağandışı erişimleri belirleyebilmesi için bir neden isteyin.

Tutarlı bir talep yolu işe yarar:

1. Talep sahibi kaydı belirtir ve neden ihtiyaç duyduğunu açıklar.
2. Atanan sorumlu onay gerekip gerekmediğini kontrol eder.
3. Sistem veya yönetici kaydı belirlenmiş bir konuma geri yükler.
4. Ekip talebi, nedeni, onaylayanı ve geri yükleme tarihini kaydeder.
5. Aktif inceleme süresi sona erdiğinde kayıt arşive geri döner.

Kaydın tam olarak nereye döneceğini belirtin. Geri yüklenen bir destek vakası, yeni vakalarla sessizce karışmak yerine «Arşivlenmiş kayıt geri yüklendi» durumuyla sınırlı bir inceleme alanında görünebilir. Ne kadar süre erişilebilir kalacağına, örneğin 14 veya 30 güne, ve hangi olayın onu daha erken geri göndereceğine karar verin.

Talep günlüğü hem hizmet kalitesini hem de hesap verebilirliği destekler. Kayıt kimliğini, talep sahibini, iş nedenini, gerektiğinde onaylayanı, talep tarihini ve arşive dönüş tarihini ekleyin. Sohbet mesajları ve kişisel hafıza bu faaliyetin güvenilir kayıtları değildir.

İşlemi gerçek bir arşiv örneğiyle test edin. İlgili kişiler, notlar, ödeme girişleri veya ekleri bulunan bir kaydı geri yükleyin. Bağlantıların hâlâ çalıştığını ve kullanıcıların yalnızca görmelerine izin verilen alanları gördüğünü kontrol edin. Eksik ekler ve kopmuş ilişkiler çoğu zaman kurulum sırasında değil, testte ortaya çıkar.

Bir AppMaster uygulamasında ekipler arşiv durumunu ve geri yükleme taleplerini veri modelinde oluşturabilir, ardından onayları yönlendirmek ve her işlemi kaydetmek için görsel iş süreçlerini kullanabilir. Aynı iş akışı rutin talepleri ve daha hassas kayıtları yönetebilir; politika gerektirdiğinde ek onay uygulanabilir.

Arşiv erişim kurallarını belirleyin

Arşivlenmiş kayıtlar, aktifken içerdikleri kişisel, finansal veya gizli bilgilerin aynısını taşıyabilir. Bir kaydı günlük görünümden çıkarmak, herkese açık hale getirmek için güvenli olduğu anlamına gelmez. İzinleri geniş ekip üyeliğine göre değil, kişinin yapması gereken işe göre belirleyin.

Destek çalışanlarının takip sırasında eski bir müşteri vakasını okuması gerekebilir. Genellikle arşivlenmiş tüm faturalara, iç notlara veya personel dosyalarına erişmeleri gerekmez. Taleple ilgilenmeye yetecek bir görünüm sağlayın ve çözüm için gerekli olmayan alanları gizleyin.

Hassas arşivleri belirli rollerle sınırlayın. Finans yöneticisi arşivlenmiş ödeme kayıtlarını açabilirken destek temsilcisi yalnızca vaka numarasını, müşteri adını, durumu ve onaylanmış hesap geçmişini görebilir. Küçük bir izin kümesini incelemek daha kolaydır ve yanlışlıkla veri açığa çıkmasını azaltır.

Dışa aktarmayı ve toplu erişimi kontrol edin

Dışa aktarımlar, ekranda tek bir kaydı görüntülemekten daha sıkı biçimde yönetilmelidir. Elektronik tablo kopyalanabilir, e-postayla gönderilebilir veya uygulama dışında saklanabilir. Arşivlenmiş kayıtlar kişisel veya finansal bilgiler içeriyorsa onay isteyin. Dışa aktarmayı kimin istediğini, neden ihtiyaç duyduğunu, tarih aralığını ve kimin onayladığını kaydedin.

AppMaster ile oluşturulan bir iç araçta ekipler bu rolleri uygulamada modelleyebilir ve dışa aktarma taleplerini bir onaylayana yönlendirmek için iş süreçlerini kullanabilir. Kural, yoğun bir iş gününde çalışanların uygulayabileceği kadar basit kalmalıdır.

Kısa bir erişim düzeyi seti yardımcı olabilir:

• Destek çalışanları, müşteri talepleriyle bağlantılı arşivlenmiş vakaları arayabilir ve görüntüleyebilir.
• Yöneticiler, eskalasyonlar veya denetimler için daha geniş vaka geçmişlerini görebilir.
• Finans veya gizlilik rolleri, ödeme ya da hassas kişisel veri içeren kayıtları açabilir.
• Yöneticiler izinleri yönetebilir, ancak otomatik olarak her arşivi dışa aktarma iznine sahip olmamalıdır.

İş değişikliklerinde erişimi gözden geçirin

İnsanlar ekip değiştirir, geçici görevler üstlenir ve işten ayrılır. Arşiv erişimini yıllık temizliği beklemeden bu noktalarda gözden geçirin. Bir kişinin son iş gününde erişimini kaldırın ve rolü artık eski kayıtlara ihtiyaç duymadığında izinlerini değiştirin.

Hassas arşivler için temel bir erişim günlüğü tutun. Günlükte kaydı kimin açtığı, ne zaman açtığı ve herhangi bir dışa aktarma yapıp yapmadığı görülmelidir. Bir müşteri eski vakayı kimin görüntülediğini sorduğunda ekip, gelen kutularını aramak yerine gerçeklere dayalı yanıt verebilir.

Örnek: kapatılmış destek vakalarını arşivleme

Destek ekiplerinin kapatılmış vakaları bir süre yakında tutması gerekir. Temsilciler geçmiş yanıtları kontrol etmek, tekrarlanan sorunları fark etmek ve konuşmayı yeniden başlatan müşterilere yardımcı olmak için yakın zamandaki vakaları inceler. Her vakayı sonsuza dek aktif tutmak günlük aramaları yavaşlatır ve gerekli olandan fazla eski müşteri bilgisini görünür bırakır.

14 Mayıs 2024'te müşteri iade aldıktan sonra kapatılmış bir vakayı düşünün. Politika, kapatılmış vakaları son kapanış tarihinden itibaren iki yıl boyunca aktif tutuyor. Bu dönemde yetkili destek çalışanları vakayı arayabilir, mesajları okuyabilir ve iade kaydını görüntüleyebilir.

Arşiv tetikleyicisi açıktır: vaka iki yıl boyunca kapalı kalmış olmalı ve yasal bekletme, açık anlaşmazlık veya bağlı inceleme bulunmamalıdır. 15 Mayıs 2026'da uygulama vakayı ve eklerini arşive taşır. Normal destek kuyruğu artık vakayı göstermez, ancak arşiv saklama süresinin geri kalanı boyunca onu korur.

Politika, kapatılmış vakaların iki yıl aktif tutulmasını, bekletme veya inceleme yoksa arşivlenmesini, mesaj ve eklerin korunmasını ve aramaların onaylı destek yöneticileri, uyum çalışanları ve şikayet incelemecileriyle sınırlandırılmasını gerektirebilir.

Altı ay sonra müşteri iade kararı hakkında şikayette bulunur. Şikayet incelemecisi vakayı numarasından bulur ve geçici geri yükleme talep eder. İncelemeci şikayet referansını ve erişim nedenini kaydeder. Bir destek yöneticisi, inceleme orijinal konuşmaya ve iade zaman çizelgesine ihtiyaç duyduğu için talebi onaylar.

Uygulama vakanın salt okunur bir kopyasını sınırlı inceleme alanına geri yükler. Çalışanlar vakayı yeniden açmadan, geçmişini değiştirmeden veya normal destek kuyruğuna koymadan inceleyebilir. İnceleme sona erdiğinde kopya arşive döner veya geri yükleme kurallarına göre uygulama tarafından kaldırılır.

Erişim günlüğü vakayı kimin aradığını, geri yüklemeyi kimin istediğini, kimin onayladığını, neden erişildiğini ve inceleme kopyasının ne zaman oluşturulup kaldırıldığını kaydetmelidir. «Yalnızca yöneticiler» yeterli değildir. Rolleri adlandırın, hassas geri yüklemeler için neden isteyin ve geri yüklenen kayıtları günlük işlerden ayrı tutun.

Sonradan sorun çıkaran hatalar

Arşiv politikaları çoğu zaman sıradan kestirmeler yüzünden başarısız olur. Ekipler her kayıt için tek bir tarih seçer, depolamayı boşaltmak için dosyaları siler veya bir kişiden gayriresmi aylık temizlik yapmasını ister. Bu seçimler, birinin vaka geçmişine, ödeme kaydına veya alınmış bir kararın kanıtına ihtiyacı olana kadar kolay görünür.

Tek bir saklama süresi nadiren her kayıt türüne uyar. Kapatılmış destek vakalarının aktif ömrü faturalar, sözleşmeler, onay kayıtları veya denetim günlüklerinden daha kısa olabilir. Her türe kendi süresini, sorumlusunu ve nedenini verin.

İş devam ederken kayıtları arşivlemeyin. Ödenmemiş bir fatura, itiraz edilmiş bir ödeme veya inceleme bekleyen bir vaka hâlâ hızlı erişim gerektirir. Kayıt arşivleme ölçütlerine durum kontrolleri ekleyin. Örneğin bir destek vakasını yalnızca ekip kapattıktan, iade süresi sona erdikten ve inceleme işareti kalmadıktan sonra arşivleyin.

Silme ve arşivleme farklı sorunları çözer. Arşiv, eski bilgileri daha sıkı erişim kurallarıyla kullanılabilir tutar. Silme ise bilgiyi kaldırır. Politika yedi yıl saklama gerektiriyorsa kaydı bir yıl sonra, günlük listede görünmediği için silmek bu politikayı ihlal eder ve işletmeyi kanıtsız bırakabilir.

Elle yapılan işler başka bir zayıf noktadır. Hangi filtrelerin çalıştırılacağını, dışa aktarmaların nereye gideceğini ve kayıtların nasıl geri yükleneceğini yalnızca bir çalışan biliyorsa, bu kişi yokken veya ayrıldığında süreç durur. Adımları açıkça yazın, yedek bir sorumlu belirleyin ve veri geri yükleme sürecini gerçek bir örnekle test edin.

AppMaster'da ekipler bu kontrolleri hafızaya güvenmek yerine bir iş sürecinin parçası haline getirebilir. Süreç, kaydın arşiv durumunu değiştirmeden önce durumu, tarihi, ödeme durumunu ve inceleme işaretlerini kontrol edebilir. Böylece tekrarlanabilir bir kural ve ne olduğuna dair açık bir geçmiş oluşur.

İstisnaları düzenli olarak gözden geçirin. Anlaşmazlık veya inceleme nedeniyle bekletilen bir kayıt sonsuza kadar belirsizlikte kalmamalıdır. Bekletilen kayıtları kontrol edecek birini görevlendirin; bekletme sona erdiğinde kayıtları aktif işe döndürsün, arşivlesin veya belgelenmiş saklama süresi sona erdiğinde silsin.

Yayımlamadan önce politikayı kontrol edin

İnsanlar tahmin yürütmeden uygulayabildiğinde politika işe yarar. Özellikle uygulamaya yeni bir kayıt türü girdiğinde, politikayı yayımlamadan veya değiştirmeden önce gözden geçirin.

Her kayıt türünün belirlenmiş bir sorumlusu ve saklama süresi olmalıdır. «Müşteri destek vakası» çok geniş bir tanımdır; fatura anlaşmazlıkları, rutin sorular ve farklı kurallara tabi hesap silme talepleri ayrı gruplar olarak adlandırılmalıdır.

Arşiv tetikleyicilerinin çalışanların gerçekten görebildiği olaylarla eşleştiğinden emin olun. «Pasif olduğunda arşivle» ifadesi ekipler pasifi farklı tanımladığı için anlaşmazlığa yol açar. «Vaka kapandıktan 90 gün sonra arşivle» daha kolay uygulanır. Yeniden açılan kayıtlar için sürenin yeniden başlayıp başlamayacağına veya ilk kapanış tarihinin geçerli kalacağına karar verin.

Politikayı yayımlamadan önce:

• Her kayıt türü için bir sorumlu, saklama süresi ve silme kararı belirleyin.
• Her arşiv tetikleyicisini kapatılmış vaka, tamamlanmış sipariş veya sona ermiş sözleşme gibi gerçek bir olayla eşleştirin.
• Dosyalar, notlar ve ilgili faaliyetler dahil olmak üzere bir örnek kaydı geri yükleyin.
• Arşivlenmiş kayıtları kimin görüntüleyebileceğini, geri yükleyebileceğini veya dışa aktarabileceğini inceleyin.
• Yazılım, iş süreçleri veya yasal yükümlülüklerdeki değişiklikler için bir gözden geçirme tarihi belirleyin.

Geri yükleme testi önemlidir, çünkü kayıtlar nadiren tek başına bulunur. Ekleri ve bağlantılı kayıtları olan bir örnek seçin. Arşiv kurallarını oluşturmamış birinden, yazılı süreci kullanarak kaydı bulup geri yüklemesini isteyin. Ne kadar sürdüğünü ve hangi bilgilerin geri gelmediğini kaydedin.

Erişim kurallarını da aynı şekilde test edin. Bir destek temsilcisinin eski bir vakayı okuması gerekebilir, ancak yalnızca yönetici vakayı geri yükleyebilmeli veya bir grup vakayı dışa aktarabilmelidir. İndirilen dosyalar uygulamanın normal izin ve saklama kontrollerinin dışında kaldığı için dışa aktarımları dikkatle yönetin.

AppMaster ile oluşturulmuş kodsuz bir uygulama kullanıyorsanız bu kontrolleri kaydı kapatan veya arşivleyen iş süreciyle birlikte belgeleyin. Ekip bir durumu değiştirdiğinde, bir dosya türü eklediğinde veya kullanıcı rolü oluşturduğunda arşiv kuralını da güncelleyin.

Politikayı günlük kullanıma taşıyın

Kapatılmış destek vakaları veya tamamlanmış sipariş talepleri gibi hızlı büyüyen tek bir kayıt türüyle başlayın. İlk kısa sürümde kaydın ne zaman taşınacağı, istisnayı kimin onaylayabileceği ve çalışanların geri yükleme talebini nasıl yapacağı yazsın.

İlk uygulamayı küçük tutun. Arşiv ölçütlerini karşılayan yaklaşık 50 kapalı kayıt seçin. Arşivin vaka numarası, tarihler, müşteri adı, ekler ve denetim notları gibi daha sonra gerekebilecek ayrıntıları koruduğunu kontrol edin. Aktif kayıtların arşive girmediğinden emin olun.

Tüm iş akışını onu kullanacak kişilerle test edin. Bir destek yöneticisi, müşteri geçmişteki bir yanıta itiraz ettiği için geçen yıldan bir vaka isteyebilir. Onaylayan kişi talebi almalı, nedeni kaydetmeli, vakayı doğru yere geri yüklemeli ve talep sahibine bildirmelidir. Çalışmayı süre tutarak uygulayın. Çok fazla adım varsa veya denetim izi oluşmuyorsa çalışanlar sürece güvenmeden önce değişiklik yapın.

Çalışanlara günlük soruları yanıtlayan bir rehber verin:

• Hangi kayıtlar otomatik olarak taşınır, hangileri inceleme gerektirir?
• Arşivlenmiş kayıtlar uygulamada nerede görünür?
• Eski kayıtları kim görüntüleyebilir, değiştirebilir veya geri yükleyebilir?
• Geri yükleme talebi için hangi neden belirtilmelidir?
• Eksik arşivlenmiş kayıtlarla kim ilgilenir?

Roller veya yasal gereklilikler değiştiğinde bu rehberi yenileyin. Birkaç ayda bir yapılacak kısa bir inceleme, kâğıt üzerinde mantıklı görünen ancak gerçek işi yavaşlatan kuralları ortaya çıkarabilir.

AppMaster, ekiplerin kod yazmadan iç uygulamaya bir arşiv iş akışı eklemesine yardımcı olabilir. Active, Closed, Archive review ve Archived gibi durumlar oluşturun. Kayıtları taşımadan önce tarihleri ve durumu kontrol etmek için görsel Business Process Editor'ı kullanın, ardından yalnızca onaylı kullanıcıların eski verileri görüntüleyebilmesi veya geri yükleyebilmesi için role dayalı erişim uygulayın.

Süreci paylaşılan bir elektronik tablo yerine gerçek izinler etrafında oluşturun. Destek temsilcileri geri yükleme talep edebilir, ekip lideri onaylayabilir ve yönetici işlemi tamamlayabilir. Her adım kimin ne zaman işlem yaptığını kaydedebilir.

İlk kayıt türü sorunsuz çalıştığında aynı modeli bir sonrakine uygulayın. Küçük ve test edilmiş değişiklikler, arşiv kurallarını herkesin ertelediği bir temizlik projesi olmaktan çıkarıp rutin iş haline getirir.