İki Olay Özelliği Arasındaki Süre

Genel Bakış

İki Olay Özelliği Arasındaki Süre zenginleştirmesi, aynı olay kaydı içindeki iki zaman damgası veya zaman aralığı alanı arasındaki zaman farkını hesaplar. Bu güçlü zenginleştirme, planlanmış bir randevu ile gerçekte varış arasındaki süre veya tek bir işlem kaydı içindeki istek gönderimi ile onay arasındaki süre gibi, bireysel olaylarda bulunan ilgili zamansal veri noktaları arasındaki geçen zamanı ölçmenizi sağlar.

Bir vaka içindeki farklı olaylar arasındaki süreyi ölçen zenginleştirmelerin aksine, bu operatör yalnızca olay seviyesinde çalışır ve her olayda zaten mevcut olan iki datetime veya timespan özelliğini karşılaştırır. Bu, kaynak sisteminizde hem başlangıç hem de bitiş zaman damgalarının ayrı alanlar olarak yakalandığı gecikmeler, ön süreler ve işlem süreleri gibi performans metriklerini analiz etmek için özellikle değerlidir. Zenginleştirme hem DateTime hem de TimeSpan özellik türlerini destekleyerek çeşitli zamanlama senaryoları için maksimum esneklik sağlar.

Zenginleştirme, hesaplanan süreyi içeren yeni bir olay seviyesi zaman aralığı özelliği oluşturur. Bu özellik daha sonra filtrelerde, görselleştirmelerde ve performans analizlerinde darboğazları tespit etmek, hizmet seviyesi uyumunu ölçmek ve süreç örneklerinizde zamanlama farklılıklarını anlamak için kullanılabilir. Hesaplama (Özellik Son - Özellik İlk) olarak yapılır ve böylece hem pozitif süreler (olaylar geç kaldığında) hem de negatif süreler (olaylar erken tamamlandığında veya planlanandan önce gerçekleştiğinde) mümkün olur.

Yaygın Kullanımlar

  • Sağlık süreçlerinde planlanan randevu zamanı ile gerçek hasta varış zamanı arasındaki süreyi ölçerek randevu gecikmesini hesaplamak
  • Aynı işlem kaydındaki istek gönderim zaman damgası ile onay zaman damgasını karşılaştırarak onay dönüş süresini ölçmek
  • Taahhüt edilen teslim tarihi ile gerçek teslim tarihi arasındaki farkı hesaplayarak gönderim gecikmelerini takip etmek
  • Müşteri sorgusu zaman damgası ile ilk yanıt zaman damgası arasındaki süreyi ölçerek yanıt süresini analiz etmek
  • Bakım faaliyetleri için planlanan başlangıç zamanı ile gerçek başlangıç zamanını karşılaştırarak program uyumunu değerlendirmek
  • Belge alım zaman damgası ile işleme tamamlama zaman damgası arasındaki süreyi hesaplayarak işlem verimliliğini ölçmek
  • Destek bilet kayıtlarında bilet oluşturma ile ilk yanıt arasındaki süreyi ölçerek SLA uyumunu izlemek
  • Planlanan ve gerçek üretim başlangıç zamanlarını karşılaştırarak üretim programı sapmasını takip etmek

Ayarlar

Yeni Özellik Adı: Hesaplanan zaman farkını tutacak yeni olay özelliğinin adı. Bu özellik TimeSpan veri türü olarak oluşturulacak ve olay tablonuzdaki diğer olay özellikleriyle birlikte görünecektir. Ölçülen sürenin ne olduğunu açıkça belirten açıklayıcı bir isim seçin, örneğin "Onay Gecikmesi", "Teslimat Sapması" veya "İşlem Süresi". Özellik adı organizasyonunuzun adlandırma kurallarına uygun olmalı ve filtrelerde ve görselleştirmelerde kullanıldığında anlamlı olmalıdır. Bu alan, geçerli herhangi bir özellik adını kabul eder ve sonraki analiz adımlarında hesaplanan süreye erişmek için tanımlayıcı olur.

İlk Özellik Adı: Süre hesaplamasında daha erken olan zaman damgasını içeren olay özelliği. Bu, olay tablonuzda mevcut bir DateTime veya TimeSpan özelliği olmalıdır. Zenginleştirme, süre ölçümünde başlangıç noktası olarak bunu kullanacaktır. Örneğin, randevu gecikmelerini ölçerken bu “Planlanan Randevu Zamanı” alanı olur. Açılır menü, hesaplanmış ve gizli özellikler hariç tutulmak suretiyle yalnızca olay tablonuzdaki geçerli DateTime ve TimeSpan özelliklerini gösterir. Böylece sadece uygun zamansal verilere seçim yapılabilir.

Son Özellik Adı: Süre hesaplamasında daha geç olan zaman damgasını içeren olay özelliği. Bu, olay tablonuzda mevcut bir DateTime veya TimeSpan özelliği olmalıdır. Zenginleştirme, süre ölçümünde bitiş noktası olarak bunu kullanacaktır. Örneğin, randevu gecikmelerini ölçerken bu “Gerçek Varış Zamanı” olur. Hesaplama (Özellik Son - Özellik İlk) olarak yapılır, bu yüzden burada kronolojik olarak daha geç zaman damgasını seçtiğinizden emin olun. Pozitif sonuçlar ikinci zaman damgasının birinciden sonra gerçekleştiğini (gecikme veya süre) gösterirken, negatif sonuçlar ikinci zaman damgasının birinciden önce olduğunu (erken tamamlanma) gösterir.

Örnekler

Örnek 1: Sağlık Randevu Gecikmesi Analizi

Senaryo: Bir tıp kliniği, planlanan randevu zamanları ile gerçek geliş zamanlarını karşılaştırarak hasta randevu gecikmelerini ölçmek istiyor. Her iki zaman damgası da randevu sistemlerinde her randevu olayında ayrı alanlar olarak kaydedilmektedir. Bu gecikmelerin anlaşılması, zamanlamayı optimize etmeye ve hasta memnuniyetini artırmaya yardımcı olur.

Ayarlar:

  • Yeni Özellik Adı: Randevu Gecikmesi
  • İlk Özellik Adı: Planlanan Zaman
  • Son Özellik Adı: Gerçek Varış Zamanı

Çıktı: Zenginleştirme “Randevu Gecikmesi” adlı yeni bir olay özelliği yaratır ve TimeSpan değerleri kullanarak planlanan ile gerçek zaman arasındaki farkı gösterir:

  • Erken gelen hastalar için negatif süreler olacak (örneğin, 15 dakika erken için -00:15:00)
  • Zamanında gelenler için sıfıra yakın süreler olur (örneğin, 2 dakika gecikme için 00:02:00)
  • Geç kalanlar için pozitif süreler oluşur (örneğin, 45 dakika geç için 00:45:00)

Örnek veri: | Hasta ID | Planlanan Zaman | Gerçek Varış Zamanı | Randevu Gecikmesi | |----------|-----------------|---------------------|-------------------| | P-1001 | 2024-01-15 09:00 | 2024-01-15 09:12 | 00:12:00 | | P-1002 | 2024-01-15 10:30 | 2024-01-15 10:25 | -00:05:00 | | P-1003 | 2024-01-15 14:00 | 2024-01-15 14:38 | 00:38:00 |

İçgörüler: Klinik, hastaların %35’inin öğleden sonra randevularına 15 dakikadan fazla geç gelerek programdaki gecikmelere neden olduğunu tespit etti. Öğleden sonraki randevu aralıkları arasına tampon süre eklemek için zamanlama algoritmalarını değiştirdiler ve toplam bekleme sürelerini %22 azalttılar.

Örnek 2: Satın Alma Siparişi Onay Dönüş Süresi

Senaryo: Satın alma departmanı, bir satın alma siparişinin gönderildiği zamandan onaylandığı zamana kadar geçen süreyi ölçmek istiyor. Her iki zaman damgası da ERP sisteminde her sipariş kaydında ayrı alanlar olarak bulunuyor. Bu dönüş süresini takip etmek, onay darboğazlarını tespit etmeye ve zamanında satın alma kararları alınmasına yardımcı olur.

Ayarlar:

  • Yeni Özellik Adı: Onay Dönüş Süresi
  • İlk Özellik Adı: Gönderim Tarihi/Zamanı
  • Son Özellik Adı: Onay Tarihi/Zamanı

Çıktı: Her satın alma siparişinin onay süresini gösteren yeni bir olay özelliği oluşturulur:

  • Hızlı onaylar: 00:15:30 (15 dakika 30 saniye)
  • Standart onaylar: 1.08:20:00 (1 gün, 8 saat, 20 dakika)
  • Gecikmeli onaylar: 5.14:30:00 (5 gün, 14 saat, 30 dakika)

Örnek veri: | Sipariş No | Tutar | Gönderim Tarihi/Zamanı | Onay Tarihi/Zamanı | Onay Dönüş Süresi | |------------|-------|------------------------|--------------------|-------------------| | PO-8821 | $450 | 2024-02-10 08:30 | 2024-02-10 09:15 | 00:45:00 | | PO-8822 | $15,200 | 2024-02-10 10:00 | 2024-02-12 14:30 | 2.04:30:00 | | PO-8823 | $89,500 | 2024-02-10 11:20 | 2024-02-16 09:45 | 5.22:25:00 |

İçgörüler: Analiz, 50.000 \(üzerindeki siparişlerin ortalama 4,5 gün onay aldığını, 1.000\) altındakilerin ise 2 saatten kısa sürede onaylandığını gösterdi. Kuruluş, düşük değerli satın alımlar için otomatik onay iş akışları uygulayarak toplam onay süresini %40 azalttı.

Örnek 3: Üretim Programı Uyumu

Senaryo: Bir üretim tesisi, üretim yürütmelerinin planlanan başlangıç zamanları ile gerçek başlangıç zamanlarını takip ediyor. Her üretim emrinde hem planlanan hem de gerçek başlangıç zamanları MES sistemlerinde kaydediliyor. Bu sapmayı ölçmek, program doğruluğu ve kapasite planlama etkinliğini belirlemeye yardımcı olur.

Ayarlar:

  • Yeni Özellik Adı: Başlangıç Zamanı Sapması
  • İlk Özellik Adı: Planlanan Başlangıç Zamanı
  • Son Özellik Adı: Gerçek Başlangıç Zamanı

Çıktı: “Başlangıç Zamanı Sapması” özelliği, üretim yürütmelerinin erken başladığını (negatif), zamanında başladığını (sıfıra yakın) veya geç başladığını (pozitif) gösterir:

  • Erken başlangıçlar, mevcut kapasite veya program esnekliği anlamına gelir
  • Geç başlangıçlar, planlama çatışmaları veya yukarı akış gecikmelerini ortaya çıkarır
  • Tutarlı desenler üretim planlamasını optimize etmeye yardımcı olur

Örnek veri: | İş Emri | Ürün Hattı | Planlanan Başlangıç | Gerçek Başlangıç | Başlangıç Zamanı Sapması | |---------|------------|---------------------|------------------|--------------------------| | WO-5501 | Hat A | 2024-03-05 06:00 | 2024-03-05 06:00 | 00:00:00 | | WO-5502 | Hat B | 2024-03-05 08:00 | 2024-03-05 09:45 | 01:45:00 | | WO-5503 | Hat C | 2024-03-05 12:00 | 2024-03-05 11:50 | -00:10:00 |

İçgörüler: Fabrika, Hat B’nin önceki vardiyadan kaynaklanan uzun değişim süreleri sebebiyle sürekli 1-2 saat geç başladığını belirledi. Paralel değişim faaliyetleri uygulayarak ortalama başlangıç sapmasını 90 dakikadan 15 dakikaya indirdi ve günlük üretim kapasitesini %8 artırdı.

Örnek 4: Müşteri Destek Yanıt Süresi

Senaryo: Bir müşteri destek organizasyonu, temsilcilerin yeni destek biletlerine ilk yanıtını ne kadar hızlı verdiklerini ölçmek istiyor. Bilet yaratma ve ilk yanıt zaman damgaları bilet sistemlerinde ayrı alanlar olarak kaydediliyor. Bu yanıt süresinin izlenmesi, SLA uyumu ve müşteri memnuniyeti için kritik önemdedir.

Ayarlar:

  • Yeni Özellik Adı: İlk Yanıt Süresi
  • İlk Özellik Adı: Bilet Oluşturma Tarihi/Zamanı
  • Son Özellik Adı: İlk Yanıt Tarihi/Zamanı

Çıktı: Zenginleştirme, her bilet için ilk yanıt süresini gösteren “İlk Yanıt Süresi” adlı bir özellik üretir:

  • Mükemmel yanıt: 00:08:30 (8 dakika 30 saniye)
  • SLA’ya uyum: 00:55:20 (55 dakika 20 saniye)
  • SLA ihlali: 02:15:45 (2 saat 15 dakika 45 saniye)

Örnek veri: | Bilet ID | Öncelik | Oluşturma Tarihi/Zamanı | İlk Yanıt Tarihi/Zamanı | İlk Yanıt Süresi | |----------|---------|-------------------------|-------------------------|------------------| | TKT-9001 | Yüksek | 2024-04-12 10:22 | 2024-04-12 10:30 | 00:08:00 | | TKT-9002 | Orta | 2024-04-12 11:15 | 2024-04-12 12:05 | 00:50:00 | | TKT-9003 | Düşük | 2024-04-12 14:30 | 2024-04-12 16:55 | 02:25:00 |

İçgörüler: Destek ekibi, yüksek öncelikli biletlerin ortalama 12 dakikada ilk yanıt aldığını, bu sürenin 30 dakikalık SLA hedefinin içinde olduğunu ancak orta öncelikli biletlerin ortalama 75 dakika ile 60 dakikalık hedefi aştığını keşfetti. Triaj sürecini ve personel seviyelerini düzenleyerek orta öncelikli biletleri önceliklendirdiler ve SLA uyumunu %78’den %94’e çıkardılar.

Örnek 5: Lojistik Teslimat Performansı

Senaryo: Bir lojistik şirketi, taahhüt edilen teslim tarihleri ile gerçek teslim tarihlerini karşılaştırarak teslimat performansını analiz etmek istiyor. Her iki tarih sevkiyat takip sistemlerinde sipariş oluşturma ve teslimat onayı sırasında kaydedilir. Teslimat sapmasının anlaşılması, taşıyıcı performans sorunlarını tespit etmeye ve müşteri beklentilerini iyileştirmeye yardımcı olur.

Ayarlar:

  • Yeni Özellik Adı: Teslimat Sapması
  • İlk Özellik Adı: Taahhüt Edilen Teslimat Tarihi
  • Son Özellik Adı: Gerçek Teslimat Tarihi

Çıktı: “Teslimat Sapması” özelliği, teslimatların erken (negatif), zamanında (sıfır veya küçük pozitif) veya geç (pozitif) olduğunu gösterir:

  • Erken teslimatlar: -1.00:00:00 (1 gün erken)
  • Zamanında teslimatlar: 00:00:00 ile 04:00:00 arasında (zamanında veya 4 saat gecikmeli)
  • Geç teslimatlar: 2.08:30:00 (2 gün 8 saat 30 dakika geç)

Örnek veri: | Sevkiyat ID | Taşıyıcı | Taahhüt Edilen Teslimat | Gerçek Teslimat | Teslimat Sapması | |-------------|----------|-------------------------|-----------------|------------------| | SHP-7701 | FastShip | 2024-05-20 17:00 | 2024-05-20 15:30 | -01:30:00 | | SHP-7702 | QuickCargo | 2024-05-21 12:00 | 2024-05-21 11:45 | -00:15:00 | | SHP-7703 | StandardPost | 2024-05-22 10:00 | 2024-05-24 14:20 | 2.04:20:00 |

İçgörüler: Analiz, teslimatların %18’inin 1 günden fazla geç olduğunu ve bu gecikmelerin %65’inin StandardPost’tan kaynaklandığını gösterdi. Şirket, taşıyıcılarla hizmet seviyelerini yeniden müzakere etti ve geçmiş performansa dayalı dinamik taşıyıcı seçimi algoritması uyguladı; böylece geç teslimatları %18’den %7’ye indirerek müşteri memnuniyet puanlarını 15 puan artırdı.

Çıktı

İki Olay Özelliği Arasındaki Süre zenginleştirmesi, aşağıdaki özelliklere sahip tek bir yeni olay seviyesi özelliği oluşturur:

Veri Türü: TimeSpan - Yeni özellik, seçilen iki özellik arasındaki zaman farkını temsil eden TimeSpan formatında süre değerleri tutar. TimeSpan değerleri pozitif (ikinci zaman damgası daha sonra ise), negatif (ikinci zaman damgası daha önce ise) veya sıfır (her iki zaman damgası aynı ise) olabilir.

Özellik Konumu: Yeni özellik olay tablosuna eklenir ve veri kümenizde diğer olay özellikleriyle birlikte görünür. Türetilmiş bir özellik olarak işaretlenir ve olay filtrelerinde, olay özelliği listelerinde görünür ve istatistiksel zenginleştirmelerle vaka seviyesine toplulaştırılabilir.

Hesaplama Yöntemi: Her olay için hesaplama şu şekildedir: (Son Özellik Adı - İlk Özellik Adı). Kaynak özelliklerden herhangi biri belli bir olay için null veya eksikse, yeni özellik o olay için null kalır; bu, yanlış sıfır değerlerin oluşmasını önleyerek veri bütünlüğünü sağlar.

Görüntüleme Formatı: TimeSpan değerleri standart süre formatında (gün.saat:dakika:saniye) gösterilir. Örneğin:

  • 00:15:30 15 dakika 30 saniye anlamındadır
  • 1.08:20:00 1 gün, 8 saat, 20 dakika anlamındadır
  • -00:05:00 negatif 5 dakika (erken varış) anlamındadır

Diğer Özelliklerle Entegrasyon: Hesaplanan süre özelliği çeşitli şekillerde kullanılabilir:

  • Olay Filtreleri: Süre eşikleri bazında olayları filtreleme (örneğin, yanıt süresi 1 saati aşanları göster)
  • Vaka Toplamaları: Olay seviyesi süreleri vaka seviyesine toplamak için Toplam, Ortalama, Min veya Max zenginleştirmeleri kullanma
  • Performans Analizi: Grafiklerde süre dağılımlarını görselleştirme ve aykırı değerleri belirleme
  • Hesaplayıcılar: Karmaşık iş mantığı için özel hesaplayıcı ifadelerinde süreye başvurma
  • Uyumluluk Kontrolü: Kabul edilebilir süre aralıklarına göre uyumluluk kuralları tanımlama

Bağımlılıklar: Zenginleştirme, yapılandırmada belirtilen iki kaynak özelliğe bağlıdır. Kaynak özelliklerden biri yeniden adlandırılırsa, gizlenirse veya veri kümesinden kaldırılırsa, hesaplanan süre özelliğinin yeniden yapılandırılması gerekebilir veya geçersiz hale gelebilir. Zenginleştirme bu bağımlılıkları izler ve kaynak özelliklerde değişiklik olursa kullanıcıları uyarır.

Performans Dikkatleri: Bu zenginleştirme her olay için basit bir çıkarma işlemi yapar ve milyonlarca olay içeren büyük veri kümelerinde dahi minimal performans etkisi yaratır. Hesaplama zenginleştirme çalıştırıldığında bir kez yapılır ve sonuçlar saklanır; böylece sonraki analiz işlemleri önceden hesaplanmış değerlere referans verir, yeniden hesaplama yükü olmaz.

Ayrıca Bakınız

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