Tekrarlanan Aktiviteleri Kaldır

Genel Bakış

Tekrarlanan Aktiviteleri Kaldır zenginleştirmesi, ardışık tekrar eden aynı aktiviteleri tek bir olayda birleştirerek sürecinizi basitleştirir ve her aktivitenin kaç kez tekrarlandığına dair önemli bilgileri korur. Bu güçlü veri temizleme aracı, aynı aktivitenin sistem davranışı, kullanıcı eylemleri veya süreç tasarımı nedeniyle arka arkaya birden fazla kez gerçekleştirilmiş olabileceği süreçlerin analizinde vazgeçilmezdir.

Bir vakada aktiviteler ardışık olarak tekrarlandığında, gerçek süreç akışı bulanıklaşabilir ve anlamlı desenleri belirlemek zorlaşır. Bu zenginleştirme, tekrarlanan aktiviteleri birleştirerek gürültüyü azaltır ve bu aktivitelerin kaç kez gerçekleştiğini takip eden bir sayım niteliği oluşturur. Ayrıca, tekrarlanan aktivitelerden olay seviyesi nitelik değerlerini birleştirerek koruyabilir, böylece önemli bilgilerin birleştirme sırasında kaybolmamasını sağlayabilirsiniz.

Zenginleştirme iki çalışma modu sunar: sıkı ardışık tekrar (aktiviteler birbirini doğrudan takip etmeli) veya esnek tekrar (ara aktiviteler olsa bile tüm aktiviteler birleştirilir). Bu esneklik, zenginleştirmenin süreç analiz ihtiyaçlarınıza göre uyarlanmasını sağlar.

Yaygın Kullanımlar

Otomatik tekrar deneme mantığından kaynaklanan kekeleme desenlerini kaldırarak süreç akışlarını sadeleştirmek
Kullanıcıların düğmelere tekrar tekrar tıkladığı veya sayfayı yenilediği olay kayıtlarını temizlemek
Ardışık gerçekleşen anket veya durum kontrol aktivitelerini birleştirmek
Yüksek frekanslı izleme aktivitelerini analiz ederken süreç karmaşıklığını azaltmak
Tekrarlayıcı gürültüyü ortadan kaldırarak süreç keşfi için veri hazırlamak
Aktivitelerin sonraki adıma geçmeden önce kaç kez tekrarlandığını takip etmek
Denetim izleri için tekrarlanan aktivitelerin nitelik değerlerini birleştirerek korumak

Ayarlar

Activity Name: Tekrarlandığında birleştirmek istediğiniz aktiviteyi seçin. Zenginleştirme, bu aktivitenin birden fazla kez gerçekleştiği yerleri belirleyerek bunları tek bir olaya indirger. Sürecinizde tekrar ettiği bilinen aktiviteleri seçin; örneğin deneme girişimleri, durum kontrolleri veya kullanıcı etkileşimleri gibi.

Count Column Name: Aktivitenin kaç kez tekrarlandığını saklayacak yeni niteliğin adını belirtin. Bu nitelik, birleştirilen ardışık gerçekleşme sayısı ile otomatik doldurulur. Varsayılan adlandırma kalıbı "[Activity Name]_Count" şeklindedir ancak kuruluşunuzun adlandırma kurallarına göre özelleştirebilirsiniz. Örneğin, "Payment Retry" tekrarlamalarını kaldırıyorsanız, "Payment_Retry_Attempts" olarak adlandırabilirsiniz.

Concatenate Attributes (Optional): Tekrarlanan aktivitelerden korumak istediğiniz bir veya daha fazla olay seviyesi string niteliği seçin. Birden fazla örnek birleştirildiğinde, bu niteliklerin değerleri virgülle ayrılarak birleştirilir. Bu, her tekrar farklı bağlamsal bilgi içeriyorsa (hata mesajları, zaman damgaları veya kullanıcı kimlikleri gibi) özellikle faydalıdır. Yalnızca hesaplanmamış ve gizli olmayan string türündeki olay nitelikleri birleştirme için kullanılabilir.

Must Follow Directly: Zenginleştirmenin tekrarlanan aktiviteleri nasıl belirleyeceğini kontrol edin:

Etkin (varsayılan): Araya başka aktivite girmeden ardışık olarak gerçekleşen aktiviteleri kaldırır. Örneğin, "A, B, B, B, C" dizisinde üç ardışık B aktivitesini tek bir B olarak birleştirir. Bu en yaygın ve temkinli yaklaşımdır.
Devre Dışı: Araya başka aktiviteler girmiş olsa bile seçilen aktivitenin tüm örneklerini kaldırır ve sadece ilk örneği tutar. Örneğin, "A, B, C, B, D, B" dizisinde sadece ilk B kalır. Bu modu kullanırken dikkatli olun çünkü süreç akışını temelden değiştirir.

Örnekler

Örnek 1: Ödeme İşleme Tekrar Deneme Mantığı

Senaryo: Bir e-ticaret platformunda ödeme işlemi için otomatik tekrar deneme mantığı vardır. Ödeme ağ sorunları veya geçici kart yetkilendirme problemleri nedeniyle başarısız olursa, sistem vazgeçmeden önce 5 kez otomatik olarak tekrar dener. Bu tekrar denemeler süreç haritasını kalabalıklaştırır ve gerçek müşteri yolculuğunu görmek zorlaşır.

Ayarlar:

Activity Name: "Process Payment"
Count Column Name: "Payment_Retry_Count"
Concatenate Attributes: "Error_Message", "Gateway_Response"
Must Follow Directly: Etkin

Çıktı: Zenginleştirme ardışık ödeme işleme denemelerini tek bir "Process Payment" aktivitesinde birleştirir ve ek bağlam sağlar:

Yeni nitelik: "Payment_Retry_Count" (örneğin 1 (tekrar yok), 2 (bir tekrar), 5 (dört tekrar) gibi değerler içerir)
Olay niteliği "Error_Message" tüm hata mesajlarını virgülle ayrılmış şekilde içerir: "Network timeout, Network timeout, Card declined"
Olay niteliği "Gateway_Response" tüm cevapları içerir: "503, 503, 402"

Örnek vaka dönüşümü:

Önce: Process Payment (başarısız) -> Process Payment (başarısız) -> Process Payment (başarısız) -> Process Payment (başarılı)
Sonra: Process Payment (başarılı), Payment_Retry_Count = 4

Kavramsal Çıkarım: İşletme artık ödeme başarı oranlarını kaç tekrar denemesinin gerektiğini görerek daha doğru analiz edebilir. Yüksek tekrar sayılı vakalar, belirli ödeme ağ geçitleriyle entegrasyon sorunlarına veya yoğun trafik dönemlerindeki problemlere işaret edebilir.

Örnek 2: Müşteri Hizmetleri Durum Kontrolleri

Senaryo: Bir müşteri hizmetleri bilet sistemi, müşteri yanıtını beklerken her 5 dakikada bir bilet durumunu otomatik olarak kontrol eder. Bu kontrol aktiviteleri uzun süren vakalarda yüzlerce olay oluşturur ve süreç analizini neredeyse imkansız hale getirir.

Ayarlar:

Activity Name: "Check Ticket Status"
Count Column Name: "Status_Check_Count"
Concatenate Attributes: (seçilmedi)
Must Follow Directly: Etkin

Çıktı: Ardışık durum kontrol aktiviteleri tek olayda birleştirilir. Örneğin, "Send Email to Customer" ile "Customer Response Received" arasında 50 durum kontrolü olan bir vaka tek "Check Ticket Status" aktivitesi ve Status_Check_Count = 50 olarak gösterilir.

Kavramsal Çıkarım: Analistler otomatik anket gürültüsünden arınmış gerçek müşteri etkileşim akışını görebilir. Durum kontrol sayısı, biletlerin genellikle müşteri yanıtını ne kadar beklediğini gösterir; bu süre bilet çözüm süresi ve müşteri memnuniyeti ile ilişkilendirilebilir.

Örnek 3: İmalat Kalite Kontrol Yeniden Testleri

Senaryo: İlaç üretim sürecinde kalite kontrol başarısızlıkları, parti reddedilmeden önce 3 kez yeniden test edilir. Firma, yeniden testlerin sayısını takip ederken analiz için temiz süreç akışları korumak istemektedir.

Ayarlar:

Activity Name: "Quality Inspection"
Count Column Name: "Inspection_Attempts"
Concatenate Attributes: "Inspector_ID", "Test_Results", "Failure_Reason"
Must Follow Directly: Etkin

Çıktı: Birden çok ardışık kalite kontrol aktivitesi tam denetim bilgisiyle birleştirilir:

Inspection_Attempts: Parti kaç kez denetlendiğini gösterir (1-4)
Inspector_ID birleşik: "INSP_001, INSP_001, INSP_002" (farklı denetçi varsa gösterir)
Test_Results birleşik: "FAIL, FAIL, PASS" (ilerlemeyi gösterir)
Failure_Reason birleşik: "pH out of range, pH out of range, " (sorunu belirtir)

Kavramsal Çıkarım: Firma, ilk geçiş oranlarını (Inspection_Attempts = 1) ve yeniden işleme oranlarını (Inspection_Attempts > 1) analiz edebilir, aynı zamanda kimin denetlediği ve neden testlerin başarısız olduğu hakkında tam izlenebilirlik sağlar.

Örnek 4: BT Destek Bileti Yeniden Atama

Senaryo: Bir BT yardım masasında, biletler çözüm öncesi destek ajanları arasında birkaç kez yeniden atanıyor. Her yeniden atama "Reassign Ticket" aktivitesini oluşturur ve gerçek çözüm adımlarını analiz etmeyi zorlaştırır.

Ayarlar:

Activity Name: "Reassign Ticket"
Count Column Name: "Reassignment_Count"
Concatenate Attributes: "Assigned_To", "Reassignment_Reason"
Must Follow Directly: Etkin

Çıktı: Birden çok ardışık yeniden atama birleştirilir:

Reassignment_Count: Yeniden atama toplam sayısı (biletin ileri geri gitmesini gösterir)
Assigned_To birleşik: "Agent_A, Agent_B, Agent_C, Agent_D" (yükselme yolunu gösterir)
Reassignment_Reason birleşik: "Wrong department, Requires senior agent, Requires system admin" (nedenini gösterir)

Kavramsal Çıkarım: Yüksek yeniden atama sayıları, zayıf ilk bilet yönlendirmesi veya belirsiz sorumluluk atamalarını gösterir. Birleşik ajan isimleri ortak yükselme desenlerini ortaya koyar ve bilet dağıtım kurallarının iyileştirilmesine yardımcı olur.

Örnek 5: Doküman Onay İş Akışı Revizyonları

Senaryo: Bir doküman yönetim sistemi, gözden geçirenlerin dokümanları revizyon için defalarca geri göndermesine izin verir. Kuruluş, revizyon döngülerini takip ederken süreç haritasını onay iş akışına odaklı tutmak ister.

Ayarlar:

Activity Name: "Request Revisions"
Count Column Name: "Revision_Cycles"
Concatenate Attributes: "Reviewer_Comments"
Must Follow Directly: Etkin

Çıktı: Ardışık revizyon istekleri birleştirilir:

Revision_Cycles: Dokümanın kaç kez geri gönderildiğini gösterir (kalite göstergesi)
Reviewer_Comments birleşik: "Fix formatting, Update references, Correct calculations" (tam geri bildirim geçmişi)

Kavramsal Çıkarım: Çok sayıda revizyon döngüsü gereken dokümanlar, belirsiz gereksinimleri veya yetersiz ilk kalite kontrollerini işaret edebilir. Birleşik yorumlar, gözden geçirme sürecinin tam denetim izini sunar ve süreç haritasını temiz ve analiz edilebilir tutar.

Çıktı

Tekrarlanan Aktiviteleri Kaldır zenginleştirmesi olay günlüğünüzü iki temel şekilde değiştirir:

Olay Azaltma: Seçilen aktivitenin ardışık gerçekleşmeleri tek bir olaya birleştirilir. Zenginleştirme ilk gerçekleşmeyi tutar ve sonraki tekrarları gizler, böylece verisetinizdeki toplam olay sayısını azaltır. Bu birleştirme vaka düzeyinde gerçekleşir, dolayısıyla farklı vakalarda tekrar desenlerine bağlı olarak farklı sayıda olay kaldırılabilir.

Yeni Sayım Niteliği: "Count Column Name"da belirttiğiniz adla yeni bir tam sayı olay seviyesi niteliği oluşturulur. Bu nitelik, birleştirilen olayda toplam birleştirilen tekrar sayısı ile doldurulur. Tekrar yoksa değeri 1 olur. Birleştirilmiş olaylarda, değer aktivitenin ardışık kaç kez gerçekleştiğini gösterir (örneğin, 4 değeri aktivitenin üst üste 4 kez gerçekleştiği anlamına gelir).

Birleştirilmiş Nitelik Değerleri: Birleştirmek için nitelik seçtiyseniz, tüm tekrar eden olayların değerleri virgülle ayrılarak tek bir dizge olarak birleştirilir ve birleştirilmiş olaya kaydedilir. Bu, hata mesajları, kullanıcı kimlikleri veya zaman damgaları gibi tekrarlar arasında değişebilecek önemli bağlamsal bilgileri korur. Birleştirme kronolojik sırada gerçekleşir; böylece tekrarlar boyunca değerlerin ilerleyişini görebilirsiniz.

Süreç Görünümü Etkisi: Bu zenginleştirme uygulandıktan sonra süreç haritalarınız ve varyantlarınız, ardışık aynı aktivitelerin neden olduğu tekrar döngüleri olmadan sadeleşmiş akışlar gösterir. Önceden "A -> B -> B -> B -> C" gibi döngüler gösteren vakalar şimdi "A -> B -> C" olarak sunulur ve temel süreç yapısı daha kolay belirlenir. Ancak, tekrar desenlerini filtrelerde ve hesaplayıcılarda sayım niteliği ile analiz etme yeteneğiniz korunur.

Sayım Niteliği Kullanım Alanları: Yeni sayım niteliği şu amaçlarla kullanılabilir:

Filtreler: "Payment_Retry_Count > 3 olan vakaları göster" gibi sorunlu ödeme işlemlerini bulmak için
Hesaplayıcılar: Vakalar arasında sayımın ortalamasını veya toplamını hesaplayarak genel tekrar oranlarını ölçmek
Performans analizi: Yüksek sayımları daha uzun işlem süreleriyle ilişkilendirmek
Kalite metrikleri: Sayımı 1 olan olayları sayarak birinci geçiş başarı oranlarını takip etmek
Görselleştirmeler: Tekrar deneme dağılımını gösteren histogramlar oluşturmak

Veri Bütünlüğü: Zenginleştirme, zaman damgası bilgilerini (ilk gerçekleşmenin zaman damgasını kullanır) koruyarak ve önemli nitelik değerlerinin birleşimine izin vererek tam veri bütünlüğünü sağlar. Hiçbir veri kalıcı olarak silinmez; bunun yerine tekrar eden olaylar gizli olarak işaretlenir ve gerekirse zenginleştirme kaldırılarak yeniden görünür hale getirilebilir.

Bu dokümantasyon mindzieStudio süreç madenciliği platformunun bir parçasıdır.