Özellik-Aktivite Matrisi
Genel Bakış
Özellik-Aktivite Matrisi hesaplayıcısı, etkinlik kaydınızdaki özellikler ile aktiviteler arasındaki ilişkiyi gösteren kapsamlı bir çapraz tablolaştırma sunar. Her özellik ve aktivite kombinasyonu için, değere sahip olan vaka sayısını göstererek yöneticilerin veri tamlığı kalıplarını anlamalarına ve veri kalitesi sorunlarını tespit etmelerine yardımcı olur.
ÖNEMLİ: Bu hesaplayıcı yalnızca yöneticiler için tasarlanmıştır ve teknik analiz ile veri kalitesi değerlendirmesi amaçlıdır. Özelliklerin farklı aktiviteler arasında nasıl doldurulduğunu gösteren bir matris oluşturur; bu, veri çıkarma kalıplarını anlamak, eksik verileri belirlemek ve etkinlik kaydı yapısının doğrulanması için esastır.
Bu hesaplayıcı, süreç aktiviteleri boyunca özellik doldurma kalıplarını anlaması gereken sistem yöneticileri ve veri kalitesi uzmanları tarafından, sorun giderme, doğrulama veya veri seti optimizasyonu için kullanılır.
Yaygın Kullanımlar
- Belirli özellikleri hangi aktivitelerin doldurduğunu tespit ederek sürece veri akışını anlamak
- Veri olması gereken aktivitelerde eksik özellik değerlerini tespit etmek
- Kritik özelliklerin beklenen süreç aşamalarında doldurulduğunu doğrulamak
- Özellik doldurma sürecindeki sistematik boşlukları bularak veri çıkarma problemlerini teşhis etmek
- ETL tasarımı için belirli aktivitelere bağlı özellik bağımlılıklarını anlamak
- Teknik spesifikasyonlar için hangi aktivitelerin hangi özelliklere veri sağladığını belgelemek
Ayarlar
Bu hesaplayıcı için herhangi özel yapılandırma gerekmemektedir. Çalıştırıldığında, tüm özellikleri (hem vaka seviyesi hem etkinlik seviyesi) tüm aktivitelerle çaprazlayarak bir matris oluşturur. Hücre değerleri, o özellik için o aktivitede değere sahip vaka sayısını gösterir.
Not: Özellik ve aktivite sayısı fazla olan veri setlerinde bu matris çok büyük olabilir. Hesaplayıcı tamamını gösterir, bu yüzden tüm kombinasyonları incelemek için kaydırma gerekebilir.
Örnekler
Örnek 1: Onay Verilerinin Tamlığını Doğrulama
Senaryo: Yeni bir onay takip sistemi kurdunuz ve satın alma siparişi sürecinizde onayla ilgili özelliklerin her onay aşamasında doğru doldurulduğunu doğrulamanız gerekiyor.
Ayarlar:
- Başlık: "Onay Özelliği Doldurma Analizi"
- Açıklama: "P2P sürecinde onay verisi yakalama doğrulaması"
Çıktı:
Hesaplayıcı, aktivitelerin sütunlarda, özelliklerin satırlarda olduğu bir matris gösterir. Onayla ilgili özellikler için:
| Özellik | Create PO | Submit for Approval | L1 Approval | L2 Approval | Finance Approval | Send to Vendor |
|---|---|---|---|---|---|---|
| ApproverName | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalLevel | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalTimestamp | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalComments | 0 | 0 | 1,523 | 398 | 189 | 0 |
| DelegatedBy | 0 | 0 | 234 | 67 | 23 | 0 |
İçgörüler: Matris, onay özelliklerinin yalnızca onay aktiviteleri (L1, L2 ve Finans Onayı) sırasında doğru şekilde doldurulduğunu, diğer aktivitelerde sıfır olduğunu doğrular. L1 Onay aşamasına ulaşan tüm 1,847 vakada ApproverName, ApprovalLevel ve ApprovalTimestamp doludur; bu, veri yakalamanın tam olduğunu gösterir. Ancak ApprovalComments, L1’de 1,523 vakada mevcut olup 324 vakada eksik, bu yorumların isteğe bağlı olup olmadığını araştırmaya değer. DelegatedBy sadece bazı onaylarda görünüyor, doğru şekilde delege durumlarını yakalıyor.
Örnek 2: Veri Çıkarma Boşluklarını Belirleme
Senaryo: Siparişten tahsilata sürecinde birden fazla kaynak sistemden veri birleştirdiniz ve bazı özelliklerin beklenen tüm aktivitelerde tutarlı şekilde doldurulmadığını şüpheleniyorsunuz.
Ayarlar:
- Başlık: "Çok Kaynaklı Veri Tamlığı Kontrolü"
- Açıklama: "CRM, ERP ve nakliye sistemlerinden özellik doldurma doğrulaması"
Çıktı:
| Özellik | Create Order | Credit Check | Pick Items | Pack Items | Ship | Generate Invoice | Receive Payment |
|---|---|---|---|---|---|---|---|
| CustomerName | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 |
| CreditScore | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 |
| WarehouseLocation | 0 | 0 | 2,456 | 2,456 | 2,456 | 0 | 0 |
| CarrierName | 0 | 0 | 0 | 0 | 2,456 | 0 | 0 |
| TrackingNumber | 0 | 0 | 0 | 0 | 2,234 | 0 | 0 |
| InvoiceAmount | 0 | 0 | 0 | 0 | 0 | 2,456 | 2,456 |
| PaymentMethod | 0 | 0 | 0 | 0 | 0 | 0 | 1,987 |
İçgörüler: Matris birçok veri kalitesi sorununun göstergesidir. CustomerName ve CreditScore vaka-seviyesi özelliklerdir, tüm aktivitelerde tüm vakalar için doludur, beklendiği gibidir. WarehouseLocation depoya özgü aktivitelerde (Pick, Pack, Ship) doğru şekilde görünür. Ancak TrackingNumber aktivitesi Ship için 2,234 vaka dolu, beklenen 2,456 yerine, 222 sevkiyata izleme numarası eksik - kritik bir boşluk. PaymentMethod aktivitesi Receive Payment için 1,987 vaka dolu, 2,456 beklenenin altında, 469 ödeme yöntemi eksik, ödeme sistem entegrasyonunda sorun olabilir.
Örnek 3: Özellik Yaşam Döngüsünü Anlama
Senaryo: Belirli özelliklerin süreç yaşam döngüsünde ne zaman kullanılabilir hale geldiğini belgeleyerek alt analiz ve raporlama tasarımına rehberlik etmek istiyorsunuz.
Ayarlar:
- Başlık: "Özellik Yaşam Döngüsü Belgelendirmesi"
- Açıklama: "Fatura işleme sürecinde her özelliğin ne zaman doldurulduğunu haritalama"
Çıktı:
| Özellik | Receive Invoice | Validate Invoice | Match to PO | Approve Payment | Schedule Payment | Make Payment | Close Case |
|---|---|---|---|---|---|---|---|
| InvoiceNumber | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| VendorID | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| PONumber | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| MatchStatus | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| ApprovedAmount | 0 | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 |
| PaymentDate | 0 | 0 | 0 | 0 | 3,456 | 3,456 | 3,456 |
| ActualPaymentDate | 0 | 0 | 0 | 0 | 0 | 3,456 | 3,456 |
| ClosureReason | 0 | 0 | 0 | 0 | 0 | 0 | 3,456 |
İçgörüler: Bu matris özellik yaşam döngüsünü net gösterir. InvoiceNumber ve VendorID baştan (fatura alındığında tüm vakalar için belirlenen vaka-seviyesi özellikler) doldurulur. PONumber ve MatchStatus yalnızca Match to PO aktivitesinden sonra kullanılabilir, önceki aşamalarda yoktur. ApprovedAmount Approve Payment aşamasında başlar ve sonraki aktivitelerde bulunur. PaymentDate (planlanan ödeme tarihi) Schedule Payment aşamasında görünürken ActualPaymentDate sadece Make Payment aşamasında, planlanan ile gerçekleşen tarih arasındaki farkı ayırt eder. ClosureReason sadece son aşamada doldurulur. Bu yaşam döngüsü anlayışı, belirli özelliklere bağımlı analitik tasarımı için kritik önemdedir.
Örnek 4: Sistematik Veri Kalitesi Sorunlarını Saptama
Senaryo: Kullanıcılar analizlerde tutarsız veri bulunduğunu rapor ediyor. Belirli aktivitelerin beklenen özellikleri sistematik olarak doldurup doldurmadığını tespit etmeniz gerekiyor.
Ayarlar:
- Başlık: "Sistematik Veri Boşluğu Analizi"
- Açıklama: "Eksik özellik doldurulan aktivitelerin belirlenmesi"
Çıktı:
| Özellik | Verify Request | Assign Resource | Start Work | Quality Check | Complete Work | Document Results |
|---|---|---|---|---|---|---|
| RequestID | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| AssignedTo | 0 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| WorkCategory | 0 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| StartTime | 0 | 0 | 5,678 | 5,678 | 5,678 | 5,678 |
| QualityScore | 0 | 0 | 0 | 4,234 | 4,234 | 4,234 |
| CompletionNotes | 0 | 0 | 0 | 0 | 5,678 | 5,678 |
| DocumentationLink | 0 | 0 | 0 | 0 | 0 | 3,456 |
İçgörüler: Matris kritik bir veri kalitesi sorununu ortaya koyar. QualityScore Quality Check aşaması için tüm vakalarda (5,678) dolu olmalıdır, fakat yalnızca 4,234 vakada mevcut, yani 1,444 vaka (yüzde 25) kalite skorundan yoksun. Bu sistematik bir boşluk olup kalite kontrol sistemi veya veri çıkarma problemine işaret edebilir. Ayrıca Document Results aşamasında DocumentationLink 3,456 vakada dolu, 2,222 vaka (yüzde 39) eksik; bu belgelemelerin önemli bölümünün atlandığını gösterir. Bu sistematik boşlukların veri bütünlüğü için acilen giderilmesi gerekir.
Örnek 5: Çoklu Sistem Entegrasyonunu Doğrulama
Senaryo: Süreciniz CRM, ERP ve lojistik olmak üzere üç farklı sistemden veri entegre ediyor ve her sistemden gelen özelliklerin uygun aktivitelerle doğru şekilde ilişkili olup olmadığını doğrulamanız gerekiyor.
Ayarlar:
- Başlık: "Çoklu Sistem Entegrasyon Doğrulaması"
- Açıklama: "CRM, ERP ve lojistik sistemlerinden özellik doldurma doğrulaması"
Çıktı:
| Özellik | Enter Order (CRM) | Reserve Inventory (ERP) | Allocate Stock (ERP) | Dispatch (Logistics) | Deliver (Logistics) | Confirm Receipt (CRM) |
|---|---|---|---|---|---|---|
| CustomerID (CRM) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| SalesRepID (CRM) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| SKU (ERP) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| InventoryLocation (ERP) | 0 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| StockLevel (ERP) | 0 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| CarrierID (Logistics) | 0 | 0 | 0 | 8,945 | 8,945 | 8,945 |
| DeliveryStatus (Logistics) | 0 | 0 | 0 | 8,945 | 8,945 | 8,945 |
| ReceivedBy (CRM) | 0 | 0 | 0 | 0 | 0 | 7,234 |
İçgörüler: Matris çoğu sistem entegrasyonunun doğru çalıştığını doğrular. CRM özellikleri (CustomerID, SalesRepID) süreç genelinde vaka-seviyesi özellikler olarak beklenildiği gibi mevcuttur. ERP özellikleri (InventoryLocation, StockLevel) Reserve Inventory aktivitesinden itibaren görünür. Lojistik özellikleri (CarrierID, DeliveryStatus) Dispatch aşamasından sonra görünür. Ancak ReceivedBy özelliğinde önemli bir sorun var; Confirm Receipt aktivitesinde 8,945 vakadan yalnızca 7,234’ü dolu, 1,711 teslimatta (yüzde 19) alıcı onayı yok. CRM onay iş akışı araştırılmalıdır.
Örnek 6: Özellik Zenginleştirme Stratejisi Planlama
Senaryo: Hangi özelliklerin seyrek doldurulduğunu ve referans verilerle veya geliştirilmiş veri yakalama süreçleriyle zenginleştirilmesinin faydalı olacağını belirlemek istiyorsunuz.
Ayarlar:
- Başlık: "Özellik Zenginleştirme Fırsatı Analizi"
- Açıklama: "Zenginleştirme gerektiren seyrek özelliklerin belirlenmesi"
Çıktı:
| Özellik | Submit Claim | Review Documents | Assess Damage | Approve Amount | Issue Payment | Close Claim |
|---|---|---|---|---|---|---|
| ClaimNumber | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| PolicyNumber | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| AdjusterID | 0 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| AdjusterName | 0 | 0 | 0 | 0 | 0 | 0 |
| DamageCategory | 0 | 0 | 12,456 | 12,456 | 12,456 | 12,456 |
| EstimatedCost | 0 | 0 | 12,456 | 12,456 | 12,456 | 12,456 |
| ApprovalReason | 0 | 0 | 0 | 12,456 | 12,456 | 12,456 |
| PaymentMethodCode | 0 | 0 | 0 | 0 | 12,456 | 12,456 |
| PaymentMethodName | 0 | 0 | 0 | 0 | 0 | 0 |
İçgörüler: Matris mükemmel zenginleştirme fırsatlarını ortaya koyar. AdjusterID tüm vakalar için Review Documents aşamasından itibaren dolu, ama AdjusterName hiç doldurulmamış. AdjusterID’nin çalışan arama tablosu ile isimlerle zenginleştirilmesi analizleri daha kullanıcı dostu yapar. Benzer şekilde PaymentMethodCode tüm ödemelerde mevcut, ancak PaymentMethodName yok. Ödeme yöntemi kodlarının açıklayıcı isimlerle zenginleştirilmesi rapor okunurluğunu önemli ölçüde artırır. Bu zenginleştirmeler, referans ID’ler zaten mevcut olduğundan minimal çabayla büyük değer katacaktır.
Çıktı
Özellik-Aktivite Matrisi hesaplayıcısı aşağıdaki yapıda kapsamlı bir matris tablosu gösterir:
Satırlar: Etkinlik kaydınızdaki her bir özellik, hem tüm vakayı kapsayan vaka seviyesi özellikler hem de aktivite bazında değişebilen etkinlik seviyesi özellikler.
Sütunlar: Sürecinizdeki benzersiz her bir aktivite.
Hücre Değerleri: Her hücre o aktivitede ilgili özelliğe sahip olan vaka sayısını gösterir. 0 değeri o aktivitede hiç vaka için özellik doldurulmadığını belirtir.
Hücre Değerlerini Anlamak
Vaka Seviyesi Özellikler: Örneğin CustomerID, OrderNumber gibi vaka seviyesi özellikler için aynı satırdaki tüm aktivitelerde hücre değeri aynıdır ve özelliğe sahip toplam vaka sayısını gösterir.
Etkinlik Seviyesi Özellikler: Örneğin ApproverName, WarehouseLocation gibi özellikler aktiviteler arasında farklılık gösterir, hangi süreç aşamasında doldurulduklarını gösterir.
Sıfır Değerler: 0 değeri, o aktivitede özelliğin hiç doldurulmadığını gösterir; bu süreç gereği normal olabilir veya veri kalitesi sorununa işaret edebilir.
Etkileşimli Özellikler
Sırala ve Filtrele: Matris başlıklarına tıklayarak aktiviteler bazında sıralama yapabilirsiniz. Tarayıcı araması ile ilgilendiğiniz özelikleri hızlı bulun.
Çıktı Alma: Matris tam halini Excel veya CSV olarak dışa aktarabilir, detaylı çevrimdışı analiz, dokümantasyon ve teknik ekiplerle paylaşım yapabilirsiniz.
Büyük Matrisler: Çok sayıda aktivite ve özellik için matris çok büyük olabilir; tam matris gezinimi için yatay ve dikey kaydırma kullanabilirsiniz.
Doldurma Kalıplarını Yorumlama
Tutarlı Doldurma: Bir özellik tüm aktivitelerde aynı sıfır olmayan değeri gösteriyorsa bu, sürecin erken aşamalarında doldurulan vaka seviyesi özelliktir.
İlerleyici Doldurma: Erken aktivitelerde 0, sonraki aktivitelerde dolu hücreler gösteriyorsa, özellik belirli süreç aşamasında doldurulmaktadır.
Kısmi Doldurma: Bir özellik toplam vaka sayısından daha az değerde varsa, bazı vakalarda eksiktir; bu veri kalitesi sorunu veya isteğe bağlı alan anlamına gelebilir.
Aktiviteye Özgü Doldurma: Bir özellik yalnızca belirli aktivitelerde doluysa, etkinlik seviyesi ve ilgili aktivitelere özgü bir özelliktir.
Performans Dikkatleri
- Büyük Veri Setleri: Yüzlerce özellik ve aktivite içeren veri setlerinde işlem süresi uzayabilir.
- Kaynak Kullanımı: Özellik-aktivite kombinasyonlarının tümünü taramak hesaplama açısından yoğundur.
- İyi Uygulamalar: Çok büyük veri setlerinde bu hesaplayıcıyı yoğun olmayan saatlerde çalıştırmak önerilir.
Yönetici Yetkisi
Bu hesaplayıcı yalnızca Yönetici rolüne sahip kullanıcılar tarafından erişilebilir. Veri seti özelliklerini anlaması gereken normal kullanıcılar, detaylı özellik-aktivite dağılımı olmayan özet metrikler sunan Dataset Information hesaplayıcısını kullanmalıdır.
Bu dokümantasyon mindzie Studio süreç madenciliği platformunun bir parçasıdır.