İş uygulaması veritabanlarında sahipsiz kayıtları önleyin

Sahipsiz kayıtlar günlük sorunlara nasıl yol açar?

Sahipsiz kayıt hâlâ vardır, ancak artık ondan sorumlu belirli bir kişi veya ekip yoktur. Bu durum bir çalışan işten ayrıldığında, müşteri hesabı el değiştirdiğinde veya ekipler birleştiğinde sık görülür. Veri veritabanında kalır, ancak bu kayıtla ilgili iş durur.

Maya'ya atanmış bir destek talebini düşünün. Bir yönetici, Maya'nın kullanıcı hesabını açık taleplerini başka birine aktarmadan silerse bu talepler tüm temsilcilerin iş kuyruğundan kaybolabilir. Müşteri yanıt beklerken destek ekibi dosyanın başka birinin sorumluluğunda olduğunu sanır.

Satış kayıtlarında da aynı sorun yaşanır. İşten ayrılan bir temsilcinin onlarca hesabı, takip görevi ve teklifi olabilir. Yeni bir sahip atanmazsa yenileme tarihleri geçer ve yeni talepler bekler. Artık şirkette çalışmayan bir yöneticiye bağlı onay istekleri de sonuçsuz kalabilir.

Etkileri doğrudan görülür:

• Atanmamış işleri gösteren bir kuyruk olmadığı için çalışanlar son tarihleri kaçırır.
• Müşteriler geç veya birbiriyle çelişen yanıtlar alır.
• Yöneticiler bir kayıtla kimin ilgilenmesi gerektiğini göremez.
• Raporlar eksik iş yükleri ve yanıltıcı sonuçlar gösterir.
• Hassas veriler artık erişmemesi gereken kişilere görünmeye devam edebilir.

Veritabanlarında sahipsiz kayıtları önlemek için sahipliği tüm uygulamayı etkileyen bir kural olarak ele alın. Bir talep bir temsilciye ve bir destek ekibine ait olabilir. Bir hesap satış temsilcisine aitken ilgili faturalar finans ekibine ait olabilir. Bu ilişkileri insanlar uygulamayı kullanmaya başlamadan önce tanımlayın.

Silinmiş kullanıcı, pasif kullanıcı ve arşivlenmiş kayıt farklı durumlardır. Kullanıcıyı silmek hesabı kaldırır ve sahip olduğu kayıtlarla bağlantıları bozabilir. Kullanıcıyı pasif olarak işaretlemek geçmişi korur, ancak uygulamanın bu kullanıcıya yeni iş atamasını engellemelidir. Bir kaydı arşivlemek onu günlük görünümlerden kaldırır, ancak denetim, raporlama veya kurtarma için erişilebilir tutar.

Örneğin tamamlanmış bir destek talebi belirli bir sürenin ardından arşive taşınabilir. Pasif bir temsilciye ait açık talep ise bunun yerine ekip kuyruğuna veya belirlenmiş yeni bir sahibe gönderilmelidir. Bu ayrım, birinin işlem yapması gerektiğinde kayıtların görünmez olmasını önler.

Her kayıt için sahipliğin ne anlama geldiğine karar verin

Formları veya otomasyonları oluşturmadan önce sahipliği tanımlayın. Her kayıt için bir sonraki işlemden belirli bir çalışanın mı, ekibin mi yoksa bir sistem sürecinin mi sorumlu olacağına karar verin. Bir müşteri destek talebi bir temsilciye ait olabilir. Bir satış hesabı bölge ekibine ait olabilir. Zamanlanmış bir içe aktarma işlemi bir sistem hesabına ait olabilir.

Sahibin iş akışını etkilediği kayıtları listeleyin. Yaygın örnekler arasında müşteriler, adaylar, fırsatlar, görevler, destek dosyaları, onaylar, siparişler ve dahili talepler bulunur. İşlem gerektirmeyen kayıtların bireysel bir sahibe ihtiyacı olmayabilir, ancak raporlama ve hata yönetimi için yine de bir ekip veya sistem sahibi gerekebilir.

Kaydı oluşturan kişinin mevcut sahibi olduğunu varsaymayın. Bu iki rol genellikle farklıdır. Bir koordinatör bir etkinlikten sonra aday kaydı girebilir, ancak takibi bir satış temsilcisi yapabilir. Geçmiş önemliyse iki alanı da saklayın: «Oluşturan», kaydı kimin girdiğini; «Mevcut sahip» ise şimdi kimin işlem yapması gerektiğini gösterir.

Her sahiplik alanı için tek bir doğru kaynağı kullanın. Satış ekranı bir hesap yöneticisi, destek ekranı ise ayrı bir iletişim sahibi saklarsa çalışanlar zamanla çelişen isimler görür. Sahiplik alanını ana kayıtta tutun ve kayıt nerede görünürse görünsün aynı alanı gösterin. Bu yaklaşım, çalışanlar ayrıldığında veya ekipler değiştiğinde veritabanlarında sahipsiz kayıtları önlemeye yardımcı olur.

Paylaşılan sahipliğin sınırlarını belirleyin. «Satış ve destek» gibi bir etiket esnek görünür, ancak iki grubun da diğerinin yanıt vermesini beklemesine yol açabilir. Birden fazla kişi kaydı görüntüleyebiliyor, düzenleyebiliyor veya katkıda bulunabiliyor olsa bile bir sonraki işlemden sorumlu tek bir kişi ya da ekip atayın.

Tanımı alanın yanında sade bir dille yazın. Örneğin: «Mevcut sahip, bir sonraki müşteri iletişiminden sorumlu kişidir.» Bu cümle geliştiricilere açık bir kural, çalışanlara da işleri tutarlı biçimde atayabilecekleri bir ölçüt verir.

Bir iş uygulaması veritabanı tasarımında sahiplik, kontrol edilmesi gereken bir ilişkidir. Uygulama pasif bir çalışanın sahip olarak seçilmesini engellemeli ve ekipte aktif üye yoksa bir yedek sahip göstermelidir. AppMaster, bu ilişkileri Data Designer içinde modellemenize ve kullanıcılar bir iş süreci üzerinden kayıt oluşturduğunda veya güncellediğinde aynı sahiplik kuralını uygulamanıza yardımcı olur.

Ekranları oluşturmadan önce ilişkileri haritalayın

Sayfalarla değil, kayıtlarla başlayın. Bir ekran düzenli görünebilir, ancak arkasındaki verilerin bağlantıları belirsiz olabilir. Uygulamanızın ihtiyaç duyduğu kayıtların basit bir haritasını çıkarın, ardından her alt kaydı ona sahip olan veya onu açıklayan kayda bağlayın.

Bir müşteri destek uygulamasında bir müşterinin birçok talebi olabilir. Her talepte notlar, görevler, ekler ve mesajlar bulunabilir. Talep bu iş kayıtlarının üst kaydıdır, müşteri ise daha geniş bağlamı sağlar. Bu harita, formlar veya panolar oluşturulmadan önce sahipsiz kayıtların oluşmasını önlemeye yardımcı olur.

İş verilerini referans verilerinden ayırın

Referans kayıtlarını aktif işi anlatan kayıtlardan ayrı tutun. Ürünler, hizmet kategorileri, bölgeler ve durum etiketleri ortak referans verileridir. Bir talep, satış fırsatı, fatura veya dahili istek belirli bir olayı ya da işi anlatır.

Bir talep bir ürün kategorisine bağlanabilir, ancak kategori talebin sahibi değildir. Yönetici bir kategoriyi kaldırırsa uygulama, etkilenen talepler için yeni bir kategori seçilmesini istemelidir. Talepleri kategoriyle birlikte silmemelidir.

Her ilişkiyi sade bir dille yazın. Küçük bir tablo veya taslak yeterlidir:

• Bir müşterinin birçok talebi olabilir ve her talep tek bir müşteriye ait olmalıdır.
• Bir talebin birçok notu olabilir ve her not tek bir talebe ve tek bir yazara ait olmalıdır.
• Bir görev bir taleple ilişkili olabilir, ancak geçici olarak atanmamış kuyruğunda bekleyebilir.
• Bir dosya, çalışanların amacını anlayabilmesi için bir talebe, nota veya müşteri kaydına ait olmalıdır.
• Bir ürün kategorisinin birçok talebi olabilir, ancak bu alan isteğe bağlıysa bir talepte kategori bulunmayabilir.

Boş değerlerin nerede kullanılabileceğine karar verin

Bazı bağlantılar her zaman mevcut olmalıdır. Talebi olmayan bir destek notu anlamını yitirir, bu nedenle bu bağlantıyı zorunlu kılın. Diğer bağlantılar kısa süreliğine boş kalabilir. Yeni bir görev, yönetici bir sahip seçene kadar atanmamış kuyruğunda bekleyebilir.

Bu ayrımı iş uygulaması veritabanı tasarımınızda açıkça belirtin. Her ilişki için çalışanların alanı boş bırakıp bırakamayacağına, uygulamanın alanı otomatik doldurup doldurmayacağına ve ilgili kayıt değiştiğinde ne olacağına karar verin. Açık veritabanı kayıt sahipliği, yeniden atama, arşivleme ve raporlamada hata olasılığını azaltır.

Harita doğru çalıştıktan sonra ekranları oluşturun. Böylece formlar doğru alanları zorunlu kılabilir, ilgisiz seçenekleri gizleyebilir ve çalışanların daha sonra kimsenin izleyemeyeceği kayıtlar oluşturmasını engelleyebilir.

Yeni kayıtlar için kurallar belirleyin

Her yeni kaydın uygulamaya girdiği anda bir sahibi olmalıdır. Buna çalışan formu, müşteri portalı, elektronik tablo içe aktarması veya otomatik iş akışıyla oluşturulan kayıtlar da dahildir. Uygulama sahipliği kısa bir süreliğine bile boş bırakırsa takip işleri gözden kaçabilir.

Her kayıt türü için varsayılan bir sahip belirleyin. Bir destek talebi destek kuyruğuna, yeni satış adayı ise satış operasyonları ekibine gönderilebilir. Varsayılan sahip her zaman tek bir kişi olmak zorunda değildir. Uygulama net bir atama kuralı uygulayana kadar ortak bir kuyruk daha güvenli olabilir.

İnsanların zaten çalışma biçimine uyan kurallar kullanın:

• Hesapları müşterinin bölgesine veya posta koduna göre atayın.
• Talepleri seçilen üründen sorumlu ekibe gönderin.
• Yeni talepleri çalışma saatlerinde bir kuyruğa yönlendirin.
• Bir sonraki adayı, açık iş yükü en düşük ekip üyesine verin.
• İçe aktarılan kayıtları, biri inceleyene kadar içe aktarmayı yapan çalışanda tutun.

Atamanın nedenini kaydedin. Bir aday kaydında «Müşteri Ontario'yu seçtiği için Kuzey satış ekibine atandı» ifadesi bulunabilir. Bu bilgi yöneticinin kuralın işe yarayıp yaramadığını kontrol etmesini ve çalışanların düzeltme gerektiğinde nereden başlayacağını görmesini sağlar. Atama nedenini gayriresmî yorumlardan ayrı tutun, böylece daha sonra raporlayabilirsiniz.

Bazı kayıtlar hiçbir kurala uymayabilir. Formda konum bulunmayabilir, içe aktarmada bilinmeyen bir ürün kodu olabilir veya kuyruktaki herkes müsait olmayabilir. Bu kayıtları sahipsiz bırakmayın. «Atama gerekiyor» gibi bir durumla izlenen bir istisna kuyruğuna gönderin ve bu kuyruğu her iş günü kontrol etmekten sorumlu belirli bir ekip atayın.

Sahiplik kuralları kaydı oluşturan işlemin parçası olarak çalışmalıdır. AppMaster'da görsel bir iş süreci kaydı oluşturabilir, sahip veya kuyruk seçebilir, atama nedenini saklayabilir ve sorumlu ekibe bildirim gönderebilir. Süreç, yalnızca geçerli bir sahip atadıktan veya kaydı istisna kuyruğuna yerleştirdikten sonra tamamlanmalıdır.

Bu yaklaşım, eksik görevlerin ve yanıtsız müşteri taleplerinin bir temizlik işine dönüşmesini önler.

Personel değişiklikleri için yeniden atama kuralları yazın

Personel değişiklikleri, açık işleri birkaç saat içinde sahipsiz bırakabilir. Bir satış temsilcisi istifa edebilir, bir destek temsilcisi başka bir ekibe geçebilir veya bir yönetici ebeveyn iznine çıkabilir. Her olay için kimin devralacağını, nelerin taşınacağını ve ne kadar sürede işlem yapılması gerektiğini belirten yazılı bir kural gerekir.

Daha önce oluşturulmuş her kaydı değil, aktif kayıtları aktarın. Aktif bir satış fırsatı, çözülmemiş destek talebi, onay isteği veya bu ay vadesi gelen görev yeni bir sahibe ihtiyaç duyar. Uygulama geçmişi koruyorsa kapatılmış anlaşmalar ve tamamlanmış talepler eski çalışana bağlı kalabilir.

Biri izne çıkmadan önce her ekip için yedek bir sahip belirleyin. Bu kişi belirli bir iş arkadaşı veya ekip lideri olabilir. Alternatif olarak yöneticinin düzenlemekten sorumlu olduğu ortak bir kuyruk kullanılabilir. Her şeyi genel bir hesaba atamaktan kaçının. İnsanlar çoğu zaman oradaki işi başkasının üstleneceğini düşünür.

Bir yeniden atama kuralı şunları belirtmelidir:

• İstifa, rol değişikliği veya izin gibi hangi olayların aktarımı başlattığı.
• Hangi kayıt durumlarının aktif sayıldığı.
• Varsayılan olarak işi kimin aldığı ve bu seçimi kimin değiştirebildiği.
• Önceki sahibin, aktarım tarihinin ve nedeninin uygulamada nasıl kaydedildiği.
• Yöneticinin yeniden atamayı ne zaman incelemesi gerektiği.

Eski sahibin adını kayıt geçmişinde tutun. Mevcut sahibin müşteriyle en son kimin konuştuğunu bilmesi gerekebilir ve yöneticiler denetim izi isteyebilir. Eski değerin üzerine yazıp başka yerde saklamadan kaybetmeyin. «Sahip, ekip değişikliği nedeniyle 12 Haziran'da Maya Patel'den Jordan Lee'ye aktarıldı» gibi bir geçmiş kaydı, mevcut sorumluluğu karıştırmadan bağlam sağlar.

Son tarihleri aciliyete göre belirleyin. Bir yönetici yüksek öncelikli talepleri ve fırsatları bir iş günü içinde, düşük öncelikli kayıtları ise üç iş günü içinde inceleyebilir. Son tarih geçerse yöneticiyi bilgilendirin veya kaydı bir yükseltme kuyruğuna yönlendirin.

AppMaster ekipleri mevcut sahibi, önceki sahibi, aktarım nedeni, öncelik ve inceleme son tarihini Data Designer içinde modelleyebilir. Bir Business Process, personel durumu değiştiğinde uygun kayıtları taşıyabilir ve yönetici için inceleme görevi oluşturabilir. Böylece kural yalnızca devir elektronik tablosunda değil, uygulamanın içinde görünür kalır.

Sessizce silmek yerine arşivleme işlemleri seçin

Silmek düzenli bir çözüm gibi görünür, ancak ekibin daha sonra ihtiyaç duyacağı bağlamı ortadan kaldırabilir. Kapatılmış bir müşteri talebi bir faturalandırma kararını açıklayabilir. Eski bir tedarikçi kaydı geçmişteki bir satın almayı destekleyebilir. Yayına almadan önce hangi kayıtların kapatılabileceğine, arşivlenebileceğine veya silinebileceğine karar verin ve her işleme açık bir anlam verin.

İş bitmiş, ancak kayıt normal geçmişte tutulacaksa kapatma durumunu kullanın. Örneğin bir destek temsilcisi çözülen talebi kapatır. Çalışanlar talebi ve mesajlarını okuyabilir, ancak talep yeniden açılmadıkça yanıt ekleyemez.

Artık günlük işin parçası olmayan, ancak raporlama, denetim veya ileride yaşanabilecek bir anlaşmazlık için gerekebilecek kayıtları arşivleyin. Arşivlenmiş bir hesap varsayılan listelerden ve arama sonuçlarından çıkmalı, yetkili çalışanlar arşiv filtresiyle hesabı bulabilmelidir. Sahibi, oluşturulma tarihini, durum geçmişini, ilgili dosyaları ve arşivleme nedenini koruyun. Bu ayrıntılar aylar sonra sık sorulan şu soruyu yanıtlar: Bu kararı kim, neden aldı?

Yasal, operasyonel veya raporlama açısından hiçbir değeri kalmamış kayıtları silin. Geçici taslaklar, yinelenen test kayıtları ve yanlışlıkla oluşturulmuş boş kayıtlar buna örnek olabilir. Bir kayıtta ödeme, tamamlanmış iş, imzalı belge veya başka bir bağlantılı geçmiş varsa silme işlemini engelleyin.

Pasif kayıtları gerçekten pasif hâle getirin

Arşiv durumu, arkasında kurallar olmadan anlam taşımaz. Çalışanlar göreve eklemeye, tutarları değiştirmeye veya kaydı başka birine atamaya devam edebiliyorsa arşiv etiketi yeterli değildir. Normal düzenlemeleri kilitleyin ve arşivlenmiş öğeler için otomatik hatırlatmaları veya takip görevlerini durdurun.

Sınırlı ve kontrollü işlemlere izin verin:

• Kaydı ve geçmişini görüntüleme.
• Kaydı, nedeni kaydederek geri yükleme.
• İzin verildiğinde dışa aktarma.
• Politika gerektiriyorsa dahili uyum notu ekleme.

Kayıtları kimin geri yükleyebileceğine genellikle yönetici veya sistem yöneticisi karar vermelidir.

Saklama süresi belirleyin

Her arşivin ne kadar süre erişilebilir kalacağını yazılı hâle getirin. Süre kayıt türüne göre değişebilir. Tamamlanmış bir dahili talep, işlem geçmişi bulunan bir müşteri hesabından daha kısa süre saklanabilir. Süre dolduğunda belirlenen yönetici, şirket politikasına göre kaydın kalıcı olarak silinmesini inceleyebilir.

AppMaster'da ekipler Data Designer içinde Active, Closed ve Archived gibi durumları modelleyebilir. Business Process kuralları düzenlemeleri engelleyebilir ve arşivlenmiş verileri günlük ekranlardan gizleyebilir. Böylece yazılı politika tutarlı uygulama davranışına dönüşür.

İstisnalar için bir yükseltme yolu oluşturun

Sahiplik kuralları yine de beklenmedik durumlarla karşılaşır. Bir müşteri artık var olmayan bir ekibe ait olabilir, bir çalışan devir işlemi tamamlanmadan ayrılabilir veya bir içe aktarma işlemi sahipsiz kayıtlar oluşturabilir. Bu kayıtların görünür bir hedefe ve onları düzenlemekten sorumlu birine ihtiyacı vardır.

«Atanmamış müşteri kayıtları» veya «Sahiplik incelemesi» gibi adlandırılmış bir istisna kuyruğu oluşturun. Geçerli sahibi olmayan her kaydı otomatik olarak buraya gönderin. Herkesin gördüğü, ancak kimsenin sorumluluk hissetmediği genel bir gelen kutusundan kaçının.

Kuyruğu incelemek için bir yönetici veya küçük bir operasyon grubu atayın. Uygulama her öğenin kuyruğa neden girdiğini, ne zaman geldiğini ve en son kimin incelediğini kaydetmelidir. Bu geçmiş, aynı kaydın bir karar alınmadan kişiler arasında dolaşmasını önler.

Son tarihleri riske göre belirleyin

Farklı kayıtlar için farklı inceleme süreleri belirleyin. Sahibi olmayan yeni bir destek talebi bir saat içinde ele alınmalı, pasif bir tedarikçi iletişim kaydı ise birkaç iş günü bekleyebilir. Son tarihi tek bir genel kurala göre değil, gecikmenin maliyetine göre belirleyin.

Örneğin:

• Sahipsiz acil destek dosyalarını hemen kuyruğa gönderin ve 30 dakika sonra nöbetçi yöneticiyi uyarın.
• Atanmamış aktif satış fırsatlarını bir sonraki iş gününde inceleyin.
• Eksik içe aktarılan kayıtları beş iş günü içinde inceleyin.
• Ayrılan bir hesap yöneticisine ait hesapları, planlanan bir sonraki müşteri iletişiminden önce yeniden atama için işaretleyin.

Son tarih geçtiğinde belirli bir yöneticiyi bilgilendirin. Yönetici işlem yapmazsa tanımlanmış bir sürenin ardından öğeyi ikinci bir kişiye veya ekibe gönderin. Zinciri kısa tutun. Uzun onay merdivenleri müşterileri bekletir.

Yanlış atamaları bildirmeyi kolaylaştırın

Hataları çoğu zaman ilk fark eden çalışanlardır. Her kayda basit bir «Atama sorununu bildir» işlemi ekleyin. «Yanlış bölge» veya «Müşteri sağlayıcı değiştirdi» gibi kısa bir neden isteyin, ardından geçmişi silmeden kaydı istisna kuyruğuna taşıyın.

AppMaster'da kuyruğu Data Designer içindeki bir durum ve sahiplik alanıyla modelleyebilirsiniz. Bir Business Process son tarihleri belirleyebilir ve e-posta, SMS veya Telegram bildirimleri gönderebilir. Çalışan sorunu uygulama arayüzünden bildirir, süreç de kaydı doğru inceleyene gönderir.

Açık bir yükseltme yolu, belirsizlik çözülürken kayıtların aktif kalmasını sağlar. Ayrıca yöneticilere, gizli bir sahipsiz iş yığını yerine ölçülebilir bir inceleme listesi sunar.

Örnek: İşten ayrılan satış temsilcisi

Bir satış temsilcisi cuma günü işten ayrılacağını bildirir. Temsilcinin 38 müşteri hesabı, 11 açık teklifi ve birkaç taslak teklifi vardır. Ekip yalnızca kullanıcı hesabını pasif hâle getirirse bu kayıtlar günlük iş kuyruklarından kaybolabilir veya açık bir sahipliğini yitirebilir. Küçük boşluklar kısa sürede kaçırılmış yenilemelere ve yanıtsız müşteri taleplerine dönüşür.

Satış yöneticisi hâlâ ilgi gerektiren hesaplardan başlamalıdır. Uygulama her aktif hesabı bölge ekip liderine atayabilir. Ekip lideri, her hesabı yeni bir temsilciye verene kadar sorumluluğu taşır. Böylece işe alım zaman alsa bile personel değişikliği sırasında veritabanı kayıt sahipliği açık kalır.

Açık teklifler, işten ayrılan temsilciyi değil hesabı izlemelidir. Hesap Kuzey bölge liderine taşınırsa açık teklifleri de oraya taşınmalıdır. Yeni sahip, eski temsilcinin kayıtları arasında arama yapmadan anlaşma geçmişini, iletişim bilgilerini ve bir sonraki işlemi görebilmelidir.

Taslak teklifler için farklı bir kural gerekir. Müşteri iletişimi, planlanmış takip işlemi veya yakın zamanda güncelleme bulunmayan bir taslak daha fazla çalışma gerektirmeyebilir. Yönetici bu taslağı silmek yerine arşivleyebilir. Arşivlenmiş taslaklar referans için erişilebilir kalır, ancak aktif satış listelerini doldurmaz veya hatırlatıcı başlatmaz.

Bazı hesaplarda bölge bilgisi bulunmayabilir. Bu kayıtları manuel inceleme kuyruğuna gönderin ve satış operasyonları yöneticisini bilgilendirin. Bu kişi, sahip atamadan önce müşterinin konumunu, hesap notlarını ve mevcut sözleşmesini kontrol eder. Uygulama incelemeden kimin sorumlu olduğunu ve incelemenin ne zaman tamamlanması gerektiğini göstermelidir.

AppMaster'da bir Business Process, yönetici bir temsilciyi ayrılacak olarak işaretlediğinde hesap durumunu ve bölgeyi kontrol edebilir. Süreç kayıtları yeniden atayabilir, uygun taslakları arşivleyebilir ve istisnalar için inceleme görevi oluşturabilir. Her işlem, sahipsiz kayıtlar oluşturmak yerine açık bir iz bırakır.

Yayına almadan önce sahiplik kurallarını test edin

Sahiplik kuralları bir diyagramda iyi görünüp ilk yoğun haftada başarısız olabilir. Kısa bir test turu, gerçek müşteri talepleri, faturalar veya destek dosyaları pasif bir çalışana takılmadan önce eksikleri ortaya çıkarır.

Mümkünse gerçekçi verilerin bir kopyasını kullanın. Farklı rollere sahip kullanıcılar oluşturun ve onlara ilişkili öğeler içeren kayıtlar verin: iletişim kişileri ve fırsatları olan bir hesap veya görevleri ve ekleri olan bir proje. Hem normal işlemleri hem de zorlayıcı durumları test edin.

Kayıtların uygulamaya girdiği her yolu test edin

Kayıtlar yalnızca ana oluşturma formundan gelmez. Çalışanlar bir elektronik tablo içe aktarabilir, bir entegrasyon aday ekleyebilir veya otomatik bir süreç gece boyunca destek talebi oluşturabilir. Her yolun bir sahip atadığını veya kaydı ortak bir kuyruğa gönderdiğini kontrol edin.

Şu kontrolleri yapın:

• Her ilgili rolle manuel kayıtlar oluşturun ve beklenen sahibin göründüğünü doğrulayın.
• Sahip bilgileri eksik bir dosyayı içe aktarın ve uygulamanın yedek kuralı izlediğini doğrulayın.
• Her entegrasyon veya otomatik süreç üzerinden bir test kaydı gönderin.
• Alt kayıtların, politikanızda belirtildiği gibi üst kaydın sahipliğini devraldığını, sahiplik istediğini veya sahipliği yok saydığını doğrulayın.

Atanmış satış temsilcisi olmayan içe aktarılmış bir aday, boş sahip alanıyla beklemek yerine satış kuyruğuna gitmelidir. Boş sahiplik, hata mesajından daha zor fark edilir.

Personel değişikliklerini ve engellenen işlemleri simüle edin

Aktif işleri bulunan bir test kullanıcısını pasif hâle getirin. Uygulamanın bu kullanıcının kayıtlarını listelediğini, kayıtları seçilen yeni sahibe veya kuyruğa aktardığını ve ekip bu bağlama ihtiyaç duyduğunda önceki sahibi kayıt geçmişinde koruduğunu doğrulayın. Ardından yeni sahip olarak oturum açın ve aktarılan işleri açıp güncelleyebildiğinizden emin olun.

Hâlâ aktif alt kayıtları bulunan bir üst kaydı arşivlemeyi de deneyin. Açık talepleri olan müşteri hesabı, kurallarınızın gerektirdiği işlemi başlatmalıdır: arşivlemeyi engellemek, ilgili kayıtları arşivlemek veya yöneticiden karar istemek. Uygulama, alt kayıtları kullanılabilir bir üst kayıt olmadan sessizce bırakmamalıdır.

İzin incelemesiyle bitirin. Normal bir çalışan kendi ekibi içinde sahip değiştirebilirken yalnızca bir yönetici ekipler arasında iş taşıyabilmeli veya ayrılan bir çalışanın kayıtlarını yeniden atayabilmelidir. Bu sınırları yalnızca yönetici hesabıyla değil, gerçek rol hesaplarıyla test edin.

AppMaster ekiplerin bu kontrolleri bir iş uygulamasına yerleştirmesine yardımcı olabilir. Bir iş sürecini kullanarak sahip zorunluluğu getirin, atanmamış işleri kuyruğa yönlendirin ve ilişkili kayıtlar hâlâ ilgi gerektiriyorsa arşiv işlemlerini engelleyin. Aynı süreçleri uygulamayı yayımlamadan önce test edin, ardından çalışanların kuralı hatırlamasına güvenmek yerine kuralı düzeltin.

Yayına almadan önce hızlı kontroller

Bir iş uygulaması gerçek iş başlamadan önce son bir sahiplik incelemesine ihtiyaç duyar. Bu incelemeyi satış, destek, operasyon ve kullanıcı hesaplarını yöneten kişilerle birlikte yapın. Personel rolleri değiştiğinde her önemli kaydın hâlâ sorumlu bir kişisi veya ekibi olmalıdır.

Mümkünse gerçekçi kayıtların test kopyasını kullanın. Bir müşteri, anlaşma, destek isteği, fatura ve dahili görev oluşturun. Ardından bir sahibin durumunu değiştirdikten sonra her ekranın ne gösterdiğini kontrol edin.

• Her önemli kayıt türü için mevcut bir sahip, ortak kuyruk veya belirli bir yedek ekip belirleyin.
• Her pasif kullanıcı için süreci kimin başlattığını ve kimin onayladığını içeren belgelenmiş bir devir işlemi bulunduğunu doğrulayın.
• Örnek bir kaydı arşivleyin ve izin verilen çalışanların kaydı arama, filtreler veya ilgili müşteri geçmişi üzerinden hâlâ bulabildiğini doğrulayın.
• İstisna kuyruklarını sabit bir programa göre, örneğin her pazartesi sabahı, incelemek üzere bir kişi görevlendirin.
• Sahibi ayrılmadan önce yeni sahip seçilmemiş bir anlaşma gibi eksik veya çelişkili veriler içeren kayıtları test edin.

Çalışanlardan bu kontrolleri uygulamayı oluşturan kişinin yardımı olmadan yapmalarını isteyin. Bir yönetici 30 açık müşteri talebini birkaç dakika içinde aktaramıyorsa kural yalnızca kâğıt üzerinde var olabilir. Uygulamanın açık bir işlemi, onay mesajı ve değişikliği kimin yaptığını gösteren bir kaydı olmalıdır.

İzinleri de test edin. Bir destek temsilcisinin arşivlenmiş bir dosyayı görmesi gerekebilir, ancak dosyayı yeniden açamamalıdır. Bir departman lideri kendi ekibi içinde iş atayabilmeli, ancak hassas bir kaydı ilgisiz bir gruba taşıyamamalıdır.

AppMaster'da bu kontrolleri uygulamanın iş süreçlerine yerleştirin ve dağıtımdan önce test edin. Geçerli sahibi olmayan kayıtlar için bir istisna kuyruğu ekleyin ve durumunu temizlemekle görevli kişiye görünür kılın. Kimsenin incelemediği bir kuyruk sorunu çözmez, yalnızca müşteri veya iş arkadaşı fark edene kadar gizler.

Kuralları iş uygulamanıza yerleştirin

İş akışını oluşturmadan önce sahiplik kurallarını yazın. Bir yönetici, destek temsilcisi ve geliştiricinin aynı kararı verebileceği kadar açık bir dil kullanın. Örneğin: «Her müşteri hesabının bir aktif hesap sahibi vardır. Bu kişi ayrıldığında satış yöneticisi bir iş günü içinde yeni bir sahip atar. Eski sahip salt okunur geçmişte kalır.»

Her kuralı uygulamadaki alanlara, durumlara ve işlemlere dönüştürün. Bir hesap kaydında sahip, ekip, atama tarihi ve arşiv durumu bulunabilir. Yeniden atama işlemi yeni sahibi zorunlu kılmalı ve değişikliği kimin yaptığını zaman damgasıyla kaydetmelidir. Bu, çalışanlara elektronik tablo çözümü yerine açık bir süreç sunar.

AppMaster, ekiplerin uygulamayı elle yazmadan bu tür dahili uygulamalar oluşturmasına yardımcı olur. Hesapları, iletişim kişilerini, görevleri ve aralarındaki ilişkileri modellemek için Data Designer'ı kullanın. Ardından yeniden atama isteklerini yönlendirmek, yeni bir sahibin bulunup bulunmadığını kontrol etmek ve bir istek çok uzun süre beklediğinde yöneticiyi uyarmak için Business Process Editor'dan yararlanın.

İlk pratik sürümde sahipsiz kayıtlar listesi, neden gerektiren bir yeniden atama formu, geçmişi koruyan bir arşiv işlemi, istisnalar için yönetici kuyruğu ve gecikmiş atamaları gösteren bir rapor bulunabilir.

İlk birkaç hafta boyunca bu raporu sık sık inceleyin. Kayıtlar yönetici kuyruğunda birikiyorsa nedeni bulun. Bir ekip çok fazla aktarım alıyor, bir yöneticinin iş atama izni bulunmuyor veya uygulama açık görevleri kontrol etmeden arşivlemeye izin veriyor olabilir.

Yönlendirme kurallarını ayarlayın, ardından değişen yolu gerçekçi personel değişiklikleriyle test edin. Bir hesap oluşturun, görevleri ve iletişim kişilerini atayın, sahibini kaldırın, hesabı yeniden atayın ve ilgili her kaydın çalışanların beklediği yerde görünmeye devam ettiğini doğrulayın.

Amaç her istisnayı önceden tahmin etmek değildir. Müşteri geçmişi, iş öğeleri veya sorumluluk ortadan kaybolmadan önce insanların istisnaları ele alabileceği görünür bir yer oluşturun. Günlük sahiplik değişikliklerinin rutin kalması için iş akışını çalışanlara sunmadan önce AppMaster'da oluşturup test edin.