Vaka Özelliğinden Aktivite Ekleme

Genel Bakış

Vaka özelliğinde saklanan zaman damgası değerlerine göre olay günlüğünüzde yeni aktiviteler oluşturan Add Activity From Case Attribute zenginleştirmesi, önemli bir dönüşüm zenginleştirmesidir. Bu güçlü dönüşüm, kilometre taşı tarihlerini, son tarih zaman damgalarını veya diğer tarih bazlı vaka özelliklerini görünür aktivitelere dönüştürmenize olanak tanır; böylece bu aktiviteler süreç haritalarınızda, varyantlarda ve zaman çizelgesi görselleştirmelerinde görünür.

Bu zenginleştirme, "Beklenen Teslim Tarihi", "Sözleşme Başlangıç Tarihi" veya "Garanti Sona Erme" gibi önemli süreç kilometre taşlarının vaka düzeyinde özellikler olarak yakalandığı durumlarda, gerçek süreç aktiviteleriyle birlikte analiz etmek istediğinizde kritik önemdedir. Bu zaman damgalarını aktivitelere dönüştürerek planlanan ve gerçek zamanlamalar arasındaki sapmaları ölçebilir, son tarihlere göre gecikmeleri tespit edebilir ve zaman bazlı süreç davranışları hakkında daha derin içgörüler elde edebilirsiniz.

Zenginleştirme, yeni aktiviteyi vaka özelliğinde belirtilen tam zaman damgasında yerleştirir ve mevcut aktivitelerin kronolojik sırasına otomatik olarak entegre eder. Böylece özellik bazlı kilometre taşları ile gerçek aktiviteler arasındaki süreleri hesaplamak, aktivitelerin beklenen tarihlerden önce veya sonra gerçekleştiği vakaları belirlemek ve planlanan ile gerçekleştirilen süreç yürütmeleri arasındaki ilişkileri görselleştirmek mümkün olur.

Yaygın Kullanımlar

  • Beklenen teslim tarihlerini aktivitelere dönüştürerek zamanında teslimat performansını ölçmek
  • Sözleşme başlangıç tarihleri veya SLA son tarihlerini süreç haritalarında görünür kilometre taşlarına dönüştürmek
  • Planlanan bitiş tarihinden aktiviteler oluşturarak planlanan ve gerçek zaman çizelgesini karşılaştırmak
  • Randevu saatlerini veya planlanan tarihleri aktiviteler haline getirerek randevu uyum analizleri yapmak
  • Garanti bitiş tarihlerini süreç akışlarına dahil ederek garanti sonrası servis aktivitelerini tanımlamak
  • Check-in zamanlarını veya kayıt zaman damgalarını süreç aktivitelerine dönüştürerek katılım takibi yapmak
  • Proje aşaması son tarihlerinden kilometre taşı aktiviteleri oluşturarak proje zaman çizelgesi uyumunu takip etmek
  • Taahhüt edilen müşteri teslimat tarihlerini aktiviteler haline getirerek taahhütlerin yerine getirilmesini ölçmek

Ayarlar

Date Attribute Column Name: Aktiviteye dönüştürmek istediğiniz zaman damgasını içeren vaka özelliğini seçin. Bu özellik DateTime türünde olmalıdır. Zenginleştirme, yeni aktivitenin gerçekleştiği zaman olarak bu özellikteki zaman damgası değerini kullanacaktır. Eğer bir vakada bu özellik için değer yoksa (null değer), o vaka için aktivite oluşturulmaz.

New Activity Name: Oluşturulacak yeni aktivitenin adını girin. Bu ad, süreç haritanızda, varyant analizinde ve aktivite listelerinde görünecektir. Aktivitenin neyi temsil ettiğini açıkça belirten açıklayıcı bir ad seçin, örneğin "Beklenen Teslim Tarihi", "SLA Son Tarihi" veya "Sözleşme Başlangıç Tarihi". Aktivite adı, karışıklığı önlemek için mevcut aktivitelerden farklı olmalıdır.

New Activity Display Name: İsterseniz raporlar ve görselleştirmelerde farklı görünmesi için aktiviteye kullanıcı dostu bir görüntüleme adı belirtebilirsiniz. Belirtilmezse, Aktivite Adı görüntüleme adı olarak kullanılır.

Expected Order: Süreç modelinizde bu aktivitenin beklenen sıralama pozisyonunu belirtin. Bu sayısal değer, sistemin bu aktivitenin süreç akışında mantıksal olarak nerede yer aldığını anlamasını sağlar ve uygunluk kontrolü ile varyant karşılaştırmaları için faydalıdır. Örneğin, bu bir son tarihi temsil ediyorsa ve belirli aktivitelerden sonra gelmesi gerekiyorsa, süreç modelinize uygun bir sıra numarası atayın.

Örnekler

Örnek 1: Zamanında Teslimat Analizi

Senaryo: Bir e-ticaret şirketi müşteri siparişleri için taahhüt edilen teslim tarihlerini vaka özelliği olarak takip ediyor. Bu taahhüt edilen tarihleri süreç haritasında aktiviteler olarak görselleştirerek teslimatların taahhüt edilen tarihten önce mi sonra mı gerçekleştiğini belirlemek, teslimat performansını ölçmek ve sorunlu teslimat paterni tespiti yapmak istiyor.

Ayarlar:

  • Date Attribute Column Name: "Promised_Delivery_Date"
  • New Activity Name: "Promised Delivery Deadline"
  • New Activity Display Name: "Expected Delivery"
  • Expected Order: 150

Çıktı: Her sipariş için Promised_Delivery_Date özelliğinde belirtilen zaman damgasında "Promised Delivery Deadline" adlı yeni bir aktivite oluşturulur. Süreç haritasında bu aktivite, "Package Shipped" ve "Delivery Complete" gibi gerçek teslimat aktiviteleriyle birlikte görünür.

Zenginleştirme öncesi örnek vaka verisi:

  • Vaka ID: ORD-5423, Promised_Delivery_Date: 2024-03-15 17:00:00
  • Aktiviteler: Order Placed (10 Mart), Payment Confirmed (10 Mart), Package Shipped (12 Mart), Delivery Complete (16 Mart)

Zenginleştirme sonrası:

  • Aktiviteler: Order Placed (10 Mart), Payment Confirmed (10 Mart), Package Shipped (12 Mart), Promised Delivery Deadline (15 Mart 17:00), Delivery Complete (16 Mart)

İçgörüler: Şirket artık "Promised Delivery Deadline" ile "Delivery Complete" arasındaki zamanı ölçerek gecikmeli teslimatları pozitif süreler olarak tespit edebilir. Süreç haritaları, teslimatların %23’sinin taahhüt edilen tarihten sonra gerçekleştiğini gösteriyor; bu özellikle Batı Kıyısı deposundan sevk edilen siparişlerde yoğunlaşmış. Bu da sorunlu dağıtım merkezlerinde hedefli iyileştirme girişimlerini destekliyor.

Örnek 2: BT Destek SLA Takibi

Senaryo: BT destek departmanının, bilet önceliğine bağlı farklı yanıt süresi taahhütleri (SLA) var. Her bilet için SLA son tarihi hesaplanıp vaka özelliği olarak saklanıyor. Ekip, bu son tarihleri aktiviteler olarak sürece enjekte edip SLA uygunluğunu izleyerek ihlale yaklaşan biletleri tespit etmek istiyor.

Ayarlar:

  • Date Attribute Column Name: "SLA_Deadline"
  • New Activity Name: "SLA Response Deadline"
  • New Activity Display Name: "SLA Deadline"
  • Expected Order: 50

Çıktı: Her destek bileti için SLA_Deadline özelliğinde belirtilen zamanda "SLA Response Deadline" aktivitesi oluşturulur. Bu son tarih aktivitesi, diğer destek aktiviteleri ile kronolojik sırayla görünür.

Örnek vaka verisi:

  • Bilet ID: TKT-8821, Öncelik: Yüksek, SLA_Deadline: 2024-06-20 14:30:00
  • Aktiviteler: Ticket Created (20 Haz 10:00), Auto-Assigned (20 Haz 10:05), SLA Response Deadline (20 Haz 14:30), First Response (20 Haz 15:15), Ticket Resolved (21 Haz 09:00)

İçgörüler: Ekip artık "First Response" aktivitesinin "SLA Response Deadline" aktivitesinden sonra gerçekleştiği vakaları filtreleyerek SLA ihlallerini kolayca tespit edebiliyor. Analiz, yüksek öncelikli biletlerin %18’inin SLA’yı ihlal ettiğini ve bunun çoğunlukla 12-14 arası personel yetersizliği olan yoğun saatlerde gerçekleştiğini gösteriyor. Bu rapor, yoğun dönemler için ek personel talebini destekliyor.

Örnek 3: Sözleşme Kilometre Taşı Takibi

Senaryo: Profesyonel bir hizmet firması, çoklu kilometre taşları olan uzun vadeli müşteri sözleşmelerini vaka özelliklerinde saklıyor (sözleşme başlangıcı, 1. teslimat, 2. teslimat, sözleşme bitiş). Bu kilometre taşlarını aktiviteler olarak görselleştirerek planlanan sözleşme zaman çizelgesini gerçekleştirilen işle karşılaştırmak istiyor.

Ayarlar (zenginleştirmeyi farklı kilometre taşları için 4 kez çalıştırın):

Konfigürasyon 1:

  • Date Attribute Column Name: "Contract_Start_Date"
  • New Activity Name: "Contract Start Milestone"
  • Expected Order: 10

Konfigürasyon 2:

  • Date Attribute Column Name: "Deliverable_1_Due_Date"
  • New Activity Name: "Deliverable 1 Deadline"
  • Expected Order: 50

Konfigürasyon 3:

  • Date Attribute Column Name: "Deliverable_2_Due_Date"
  • New Activity Name: "Deliverable 2 Deadline"
  • Expected Order: 100

Konfigürasyon 4:

  • Date Attribute Column Name: "Contract_End_Date"
  • New Activity Name: "Contract End Milestone"
  • Expected Order: 200

Çıktı: Zenginleştirme, her sözleşme için saklanan son tarihlere dayalı dört yeni kilometre taşı aktivitesi oluşturur. Bu kilometre taşları, süreç zaman çizelgesinde "Requirements Gathering", "Design Review", "Deliverable 1 Submitted" gibi gerçek iş aktiviteleriyle birlikte görünür.

Sözleşme C-445 için örnek vaka verisi:

  • Zenginleştirme öncesi: Requirements Gathering (5 Ocak), Design Review (20 Ocak), Deliverable 1 Submitted (10 Şubat), Testing Complete (25 Şubat), Deliverable 2 Submitted (8 Mart)
  • Zenginleştirme sonrası: Contract Start Milestone (1 Ocak), Requirements Gathering (5 Ocak), Design Review (20 Ocak), Deliverable 1 Deadline (5 Şubat), Deliverable 1 Submitted (10 Şubat), Testing Complete (25 Şubat), Deliverable 2 Deadline (1 Mart), Deliverable 2 Submitted (8 Mart), Contract End Milestone (15 Mart)

İçgörüler: Firma artık gerçek işlerin sözleşme tarihleriyle nasıl uyduğunu görselleştirebilir. Analiz, Deliverable 1’in 5 gün geciktiğini, ancak Deliverable 2’nin 7 gün erken teslim edilerek sözleşmenin genel olarak zamanında tamamlandığını gösteriyor. Bu desen analizi, hangi tür teslimatların düzenli olarak geç kaldığını belirleyerek daha iyi tahmin gereksinimini ortaya koyuyor.

Örnek 4: Sağlıkta Randevu Uyumu

Senaryo: Bir tıbbi klinik, hasta randevularını planlar ve planlanan randevu saatini vaka özelliği olarak saklar. Planlanan saat için bir aktivite oluşturarak hastaların görülmeden önce ne kadar beklediğini ölçmek ve randevu gecikmeleri paternlerini belirlemek ister.

Ayarlar:

  • Date Attribute Column Name: "Scheduled_Appointment_Time"
  • New Activity Name: "Scheduled Appointment"
  • New Activity Display Name: "Appointment Time"
  • Expected Order: 20

Çıktı: "Scheduled Appointment" aktivitesi, hastanın görülmesi planlanan tam zamanda oluşturulur ve bu, gerçek "Patient Called to Exam Room" aktivitesi ile karşılaştırılır.

Örnek vaka verisi:

  • Hasta Ziyareti PV-9923, Scheduled_Appointment_Time: 2024-09-12 10:00:00
  • Aktiviteler: Patient Check-In (9:45), Scheduled Appointment (10:00), Patient Called to Exam Room (10:23), Doctor Enters Room (10:30), Visit Complete (10:52)

İçgörüler: Klinik, "Scheduled Appointment" ile "Patient Called to Exam Room" arasındaki süreyi hesaplayarak randevu gecikmelerini ölçebilir. Analiz, ortalama bekleme süresinin planlanan zamandan 18 dakika fazla olduğunu ve sabah randevularının (8-10 arası) öğleden sonralara göre daha dakik olduğunu gösteriyor. Bu durum, gün ilerledikçe kliniğin programa geride kaldığını ve çizelge tamponlarının ayarlanması gerektiğini destekliyor.

Örnek 5: Üretim Planlama

Senaryo: Bir üretim şirketi üretim planlarını yapar ve her iş için planlanan başlama tarihini vaka özelliği olarak saklar. Bu planlanan başlama tarihini aktivite olarak sürece enjekte edip planlanan ve gerçek üretim zaman çizelgelerini karşılaştırarak geç başlayan işleri belirlemek ister.

Ayarlar:

  • Date Attribute Column Name: "Planned_Production_Start"
  • New Activity Name: "Planned Start Date"
  • New Activity Display Name: "Scheduled Start"
  • Expected Order: 15

Çıktı: Her üretim işi için Planned_Production_Start özelliğinde belirtilen zamanda "Planned Start Date" aktivitesi oluşturulur.

Örnek vaka verisi:

  • İş ID: JOB-3391, Planned_Production_Start: 2024-11-05 06:00:00
  • Aktiviteler: Materials Requisitioned (1 Kas), Materials Received (3 Kas), Planned Start Date (5 Kas 06:00), Production Setup (6 Kas 08:00), Production Started (6 Kas 09:30), Quality Check (7 Kas), Production Complete (7 Kas)

İçgörüler: "Planned Start Date" ile "Production Started" arasındaki süreyi ölçerek işlerin %34’ünün 24 saatin üzerinde geciktiğini tespit eder. Kök neden analizi, gecikmelerin %60’ının malzeme geç tesliminden, %25’inin ekipman erişilebilirliği sorunlarından kaynaklandığını gösterir. Bu veriler, malzeme planlaması ve ekipman bakım programlarını iyileştirmek için kullanılmaktadır.

Çıktı

Add Activity From Case Attribute zenginleştirmesi, olay günlüğünüzde yeni olay satırları oluşturur:

Yeni Aktivite Kayıtları: Belirtilen tarih özelliğinde null olmayan bir değere sahip her vaka için:

  • Aktivite Adı: "New Activity Name" ayarında belirttiğiniz isim
  • Zaman Damgası: Seçilen vaka özelliğinden alınan DateTime değeri
  • Vaka İlişkisi: Kaynak özellikle aynı vakaya bağlı
  • Beklenen Sıra: Uygunluk ve varyant analizi için belirttiğiniz sıra değeri

Veri Türü: Yeni aktiviteler standart olay günlüğü aktiviteleridir ve tüm aktivite tabanlı analizlerde görünür:

  • Süreç haritaları ve varyantlar (yeni aktiviteyi kronolojik sırada gösterir)
  • Aktivite sıklık tabloları ve istatistikler
  • Zaman çizelgesi görselleştirmeleri
  • Süre hesaplamaları (süre zenginleştirmeleri için başlangıç veya bitiş noktası olarak)
  • Uygunluk kontrolü (beklenen sıra değeri kullanılarak)

Null İşleme: Belirtilen tarih özelliği null veya boş olan vakalar için yeni aktivite oluşturulmaz. Bu nedenle, yeni aktivitenin toplam vaka sayısından daha az oluşuşu olabilir.

Kronolojik Entegrasyon: Yeni aktiviteler, zaman damgalarına göre doğru kronolojik sıraya otomatik olarak yerleştirilir; daha sonraki aktivitelerden önce ve daha erken aktivitelerden sonra görünür. Bu, doğru süre hesaplamaları ve süreç akış görselleştirmesi sağlar.

Çoklu Zenginleştirmeler: Bu zenginleştirmeyi farklı kaynak özelliklerle birden çok kez çalıştırarak veri setinizdeki çeşitli tarih özelliklerinden çoklu kilometre taşı aktiviteleri oluşturabilirsiniz. Bunu yukarıdaki Sözleşme Kilometre Taşı Takibi örneğinde görebilirsiniz.

Diğer Zenginleştirmelerle Entegrasyon: Oluşturulan yeni aktiviteler;

  • Kilometre taşı ve gerçek aktiviteler arasındaki süreyi hesaplamak için süre zenginleştirmelerinde,
  • Kilometre taşlarına göre aktivitelerin beklenen sırada olup olmadığını kontrol eden uygunluk zenginleştirmelerinde,
  • Kilometre taşı ilişkili desenlere göre vaka segmentasyonu yapan aktivite filtrelerinde,
  • Planlanan ve gerçek zaman çizelgeleri arasındaki sapmayı ölçen hesaplayıcılarda kullanılabilir.

Ayrıca Bakınız

İlgili Aktivite Zenginleştirmeleri:

İlgili Özellik Zenginleştirmeleri:

İlgili Konular:

  • Süreç Keşfi - Kilometre taşı aktiviteleri eklendikten sonra aktivite akışlarını anlama
  • Zaman Çizelgesi Analizi - Planlanan ve gerçek aktivitelerin kronolojik ilişkilerini görselleştirme

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