Satın Almadan Ödemeye - Talep Veri Şablonunuz
Satın Almadan Ödemeye - Talep Veri Şablonunuz
Bu, Satın Alma-Ödeme (Purchase to Pay) - Talep süreci için genel Process Mining veri şablonumuzdur. Daha özel rehberlik için sisteme özel şablonlarımızı kullanın.
Belirli bir sistem seçin- Çeşitli sistemler arasında tutarlı analiz için standartlaştırılmış `data` alanları.
- Tam süreç görünürlüğü için izlenecek temel faaliyetlerin kapsamlı bir listesi.
- Benzersiz Satın Alma-Ödeme (Purchase to Pay), Talep iş akışınıza uyarlanabilen esnek bir temel.
Satın Alma-Ödeme (Purchase to Pay) - Talep Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet Adı ActivityName | Talep için belirli bir zamanda gerçekleşen özel iş etkinliğinin veya olayının adı. | ||
| Açıklama Etkinlik Adı, satın alma talebi yaşam döngüsündeki tek bir adımı veya durum değişikliğini tanımlar. 'Talep Gönderildi', 'Onay Adımı Başlatıldı' veya 'Talep Reddedildi' gibi olaylar için insan tarafından okunabilir etiketler sağlayarak süreç haritasının temel yapı taşlarını oluşturur. Bu öznitelik, süreç keşfi ve analizi için temeldir. Bu etkinlikleri sıralayarak, Process Mining araçları gerçek süreç akışını görselleştirebilir, standart prosedürden sapmaları belirleyebilir ve bottleneck'leri veya yeniden işleme döngülerini tespit edebilir. Tutarlı ve anlamlı etkinlik adları, anlaşılır ve eyleme geçirilebilir bir süreç modeli oluşturmanın anahtarıdır. Neden önemli Süreç haritasını görselleştirmek ve süreç akışını analiz etmek için temel olan sürecin bireysel adımlarını tanımlar. Nereden alınır
Örnekler Talep OluşturulduOnay Adımı OnaylandıSatın Alma Siparişi Oluşturuldu | |||
| Olay Zamanı EventTime | Etkinliğin gerçekleştiği kesin tarih ve saat. Bu, olay sıralaması için birincil timestamp olarak hizmet eder. | ||
| Açıklama Olay Zamanı, genellikle
Neden önemli Bu timestamp, event'leri sıralamak, çevrim sürelerini hesaplamak ve süreç performansını ve bottleneck'leri analiz etmek için hayati öneme sahiptir. Nereden alınır Genellikle sistem denetim izlerinde, event log'larda veya işlem kayıtlarında oluşturma veya değişiklik tarihi olarak kaydedilir. Örnekler 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z | |||
| Satın Alma İsteği Kimliği PurchaseRequisitionId | Her satın alma talebi için benzersiz tanımlayıcı. Bu, süreç için birincil case tanımlayıcısı olarak hizmet eder. | ||
| Açıklama Satın Alma Talebi ID'si, her talep belgesine oluşturulduğunda atanan benzersiz bir anahtardır. Başlangıçtan tamamlanmaya kadar tek bir taleple ilişkili tüm etkinlikler, değişiklikler ve onaylar için merkezi referans noktası görevi görür. Process Mining'de bu ID, case korelasyonu için çok önemlidir. Sistemin her talebin uçtan uca yolculuğunu yeniden yapılandırmasına olanak tanır, 'Talep Oluşturuldu', 'Onay Adımı Onaylandı' ve 'Satın Alma Siparişi Oluşturuldu' gibi farklı event'leri tutarlı bir süreç akışına bağlar. Tutarlı ve benzersiz bir case tanımlayıcısı olmadan süreç varyantlarını, çevrim sürelerini ve sonuçları analiz etmek imkansızdır. Neden önemli Bu, bir talebin tüm yaşam döngüsünü izlemek için temel anahtardır ve tüm ilgili event'lerin tek bir süreç örneğine bağlanmasını sağlar. Nereden alınır Genellikle satın alma talebi işleminin veya belge tablosunun üst verilerinde bulunur. Örnekler PR-100567REQ00043218000123987 | |||
| Kaynak Sistem SourceSystem | Verinin çıkarıldığı ERP veya tedarik platformu gibi bilgi sistemini tanımlar. | ||
| Açıklama Kaynak Sistem özniteliği, süreç verisinin kökenini belirtir. Merkezi bir ERP ve özel bir e-tedarik aracı gibi birden fazla sisteme sahip kuruluşlarda, bu alan farklı kaynaklardan gelen verileri ayırt etmeye yardımcı olur. Bu bilgi, veri doğrulama, sorun giderme ve sisteme bağımlı olabilecek süreç varyasyonlarını anlamak için değerlidir. Örneğin, bir sistemden gelen talepler farklı bir onay yolunu izleyebilir veya diğerinden daha hızlı bir çevrim süresine sahip olabilir. Kaynak sisteme göre veri analizi, entegrasyon sorunlarını veya sistem konsolidasyonu fırsatlarını ortaya çıkarabilir. Neden önemli Veri kökeni hakkında bağlam sağlar, bu da veri doğrulama ve birden fazla sistemdeki süreç farklılıklarını analiz etmek için çok önemlidir. Nereden alınır Bu, genellikle veri çekme süreci sırasında eklenen statik bir değerdir veya teknik meta veri alanlarında bulunabilir. Örnekler SAP S/4HANAOracle FusionCoupa | |||
| Son Veri Güncellemesi LastDataUpdate | Bu kayıt için verinin kaynak sistemden en son ne zaman yenilendiğini veya çekildiğini gösteren timestamp bilgisidir. | ||
| Açıklama Son Veri Güncelleme timestamp'i, analiz edilen verinin güncelliğini gösterir. Kaydın kaynak sistemden en son ne zaman çekildiğini ve Process Mining ortamına yüklendiğini gösterir. Bu öznitelik, operasyonel izleme ve analizlerin güncel bilgilere dayanmasını sağlamak için çok önemlidir. Kullanıcıların gerçek dünya olayları ile süreç modelindeki temsilleri arasındaki potansiyel gecikmeyi anlamalarına yardımcı olur. Dashboard'lar ve KPI'lar, devam eden operasyonları takip eden bu bilgiye güvenerek zamanında ve ilgili içgörüler sağlar. Neden önemli Kullanıcılara verinin güncelliği hakkında bilgi verir, bu da analizlerin ilgili ve güncel olmasını sağlamak için kritiktir. Nereden alınır Genellikle veri entegrasyonu veya ETL (Çıkar, Dönüştür, Yükle) aracı tarafından veri yükleme süreci sırasında eklenir. Örnekler 2024-05-20T02:00:00Z2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Bölüm Department | Talebin yüklendiği iş departmanı, maliyet merkezi veya organizasyonel birim. | ||
| Açıklama Departman özniteliği, 'Pazarlama', 'BT' veya 'Finans' gibi satın almadan sorumlu organizasyonel birimi temsil eder. Bütçeleme ve maliyet tahsisi için kullanılan önemli bir finansal ve organizasyonel veridir. Process Mining'de, departmanlara göre veri analizi yaygın ve güçlü bir tekniktir. Farklı iş birimleri arasındaki performans karşılaştırmasına olanak tanıyarak hangi departmanların daha verimli olduğunu ve hangilerinin desteğe ihtiyaç duyabileceğini belirlemeye yardımcı olur. Bu analiz, bir departmanın satın alma alışkanlıklarına veya iç süreçlerine özgü çevrim süresi, onay oranları veya uyumluluktaki farklılıkları ortaya çıkarabilir. Neden önemli Farklı iş birimleri arasında performans kıyaslaması ve maliyet analizi yapılmasını sağlayarak departmana özgü süreç davranışlarını ortaya çıkarır. Nereden alınır Genellikle satın alma talebinin üst veya kalem verilerinde bulunur, şirketin organizasyon yapısına bağlıdır. Örnekler PazarlamaBilgi TeknolojileriFinansOperasyonlar | |||
| Para Birimi Currency | Talebin toplam tutarı için USD veya EUR gibi para birimi kodu. | ||
| Açıklama Para Birimi özniteliği, Talep Tutarı için para birimini belirtir. Çok uluslu kuruluşlar için talepler, talep edenin veya tedarikçinin konumuna bağlı olarak farklı para birimlerinde oluşturulabilir. Bu alan, doğru finansal raporlama ve analiz için hayati öneme sahiptir. Parasal değerlerin doğru yorumlanmasını sağlar ve farklı bölgelerdeki verileri toplarken doğru dönüştürmeye olanak tanır. Talep değerini içeren herhangi bir analiz, farklı para birimlerini doğrudan karşılaştırmamak için para birimini dikkate almalıdır. Neden önemli Finansal veriler için gerekli bağlamı sağlar, talep değerlerinin bölgeler arasında doğru yorumlanmasını ve toplanmasını garanti eder. Nereden alınır Genellikle satın alma talebi işleminin üst verilerinde, tutar alanlarının yanında bulunur. Örnekler USDEURGBP | |||
| Satın Alma Siparişi Kimliği PurchaseOrderId | Onaylanmış talepten oluşturulan satın alma siparişinin tanımlayıcısı. | ||
| Açıklama Satın Alma Siparişi ID'si, onaylanmış bir satın alma talebinden oluşturulan satın alma siparişi (PO) belgesinin benzersiz numarasıdır. Bu alan, talep sürecini sonraki tedarik ve ödeme süreçlerine bağlar. Bu öznitelik, Talep-PO dönüşüm verimliliğini analiz etmek için kritik öneme sahiptir. Bir talebin başarılı bir şekilde bir satın alma siparişiyle sonuçlandığını doğrular ve bu dönüşüm için geçen sürenin ölçülmesini sağlar. Hangi taleplerin ilgili bir PO'ya sahip olduğunu analiz ederek, işletmeler ön-tedarik aşamasının etkinliğini değerlendirebilir ve onaylanmış ancak asla yerine getirilmeyen talepleri belirleyebilir. Neden önemli Talebi sonraki tedarik sürecine bağlar, talep-Satın Alma Siparişi (PO) dönüşüm oranlarının ve sürelerinin analizini sağlar. Nereden alınır Satın Alma Siparişi (PO) oluşturulduktan sonra talep belgesi verilerinde bulunur, bazen ilgili belgeler veya belge akışı tablosunda yer alır. Örnekler PO-4500012345ORD7890016000054321 | |||
| Talep Durumu RequisitionStatus | Satın alma talebinin yaşam döngüsündeki mevcut veya nihai durumu. | ||
| Açıklama Talep Durumu, talebin belirli bir zamandaki durumunu veya nihai sonucunu gösterir. Yaygın durumlar arasında 'Devam Ediyor', 'Onay Bekliyor', 'Onaylandı', 'Reddedildi' ve 'Kapalı' bulunur. Bu nitelik, sonuç analizi ve operasyonel izleme için gereklidir. Analistlerin, ret oranları veya Satın Alma Siparişi (PO) dönüşüm oranları gibi metrikleri hesaplamak için talepleri nihai durumlarına göre filtrelemesine olanak tanır. Operasyonel bağlamda, ekiplerin onay bekleyen talep sayısı gibi mevcut iş yükünü anlamalarına yardımcı olur, bu da işleri önceliklendirmelerini ve kaynakları etkili bir şekilde yönetmelerini sağlar. Neden önemli Talep sonuçlarına dair net bir görünüm sunar, ret oranları gibi temel metriklerin hesaplanmasını sağlar ve operasyonel iş yükü yönetimini destekler. Nereden alınır Genellikle satın alma talebi belgesinin başlık durumu alanında bulunur. Örnekler OnaylandıReddedildiOnay BekliyorGeri Çekildi | |||
| Talep Edenin Adı RequesterName | Satın alma talebini oluşturan ve gönderen çalışanın veya kullanıcının adı. | ||
| Açıklama Talep Eden Adı, satın alma talebini başlatan kişiyi tanımlar. Bu kişi genellikle mal veya hizmete ihtiyaç duyan iş kullanıcısıdır. Süreci talep edene göre analiz etmek, belirli bireyler veya gruplarla ilgili kalıpları belirlemeye yardımcı olabilir. Örneğin, bazı talep edenlerin sıklıkla yeniden işleme gerektiren eksik veya uyumsuz talepler gönderip göndermediğini ortaya çıkarabilir. Bu bilgi, hedefe yönelik eğitim sağlamak veya yaygın kullanıcı grupları için talep sürecini basitleştirmek için kullanılabilir, nihayetinde verimliliği ve uyumluluğu iyileştirir. Neden önemli Kullanıcıya özgü davranışları belirlemeye yardımcı olur, bireyler veya ekipler için hedefe yönelik eğitim ve süreç iyileştirmeleri sağlar. Nereden alınır Satın alma talebinin başlık verilerinde bulunur, genellikle çalışan ana verilerine bağlıdır. Örnekler Can DemirAyşe YılmazMaria Garcia | |||
| Talep Türü RequisitionType | Talebin türü veya kategorisi; örneğin mal, hizmet veya sermaye harcamaları için olabilir. | ||
| Açıklama Talep Türü, satın alma talebini doğasına veya amacına göre sınıflandırır. Örnekler arasında standart malzemeler, hizmetler, sermaye harcamaları veya belirli bir katalogdan talepler bulunur. Bu sınıflandırma genellikle onay Süreci talep türüne göre analiz etmek, farklı talep türlerinin farklı yolları takip edip etmediğini veya farklı verimlilik seviyeleri deneyimleyip deneyimlemediğini anlamaya yardımcı olur. Örneğin, sermaye harcaması talepleri ek onay katmanları nedeniyle daha uzun döngü sürelerine sahip olabilirken, standart katalog öğeleri için talepler yüksek oranda otomatikleştirilmiş olabilir. Bu analiz, türe özgü süreç varyantlarını tasarlamaya ve optimize etmeye yardımcı olur. Neden önemli Talebin türü genellikle gerekli onay Nereden alınır Bu bilgi, genellikle talep üst verisinde bir belge türü veya kategori kodu olarak saklanır. Örnekler Sermaye HarcamasıOperasyonel GiderHizmet TalebiMalzeme Talebi | |||
| Talep Tutarı RequisitionAmount | Satın alma talebinin toplam parasal değeri. | ||
| Açıklama Talep Tutarı, satın alma talebinde istenen tüm öğe ve hizmetlerin toplam finansal değerini temsil eder. Bu, tedarik süreci boyunca kullanılan önemli bir finansal metriktir. Süreç analizinde, bu nitelik değer tabanlı filtreleme ve analiz için hayati öneme sahiptir. Taleplerin, genellikle farklı onay Neden önemli Değer tabanlı analize olanak tanır, yüksek değerli talepleri önceliklendirmeye ve finansal değerin süreç davranışını nasıl etkilediğini anlamaya yardımcı olur. Nereden alınır Genellikle satın alma talebi işleminin veya belge tablosunun üst verilerinde bulunur. Örnekler 500.0012500.7599.95 | |||
| `Teslim Edilmesi Gereken Tarih` RequiredByDate | Talep edenin mal veya hizmetlerin teslim edilmesini istediği tarih. | ||
| Açıklama Gerekli Teslim Tarihi, talep eden tarafından yerine getirme için son tarihi belirtmek üzere belirlenir. Bu tarih, talep onayından nihai teslimata kadar tüm tedarik süreci için bir hedef görevi görür. Bu öznitelik, süreç zamanlamasını ve iş ihtiyaçlarıyla uyumunu analiz etmek için önemlidir. Gerekli Teslim Tarihini gerçek Satın Alma Siparişi oluşturma tarihi veya teslimat tarihi ile karşılaştırarak, kuruluşlar dahili hizmet düzeyi anlaşmalarını karşılama yeteneklerini ölçebilirler. Tedarik sürecinin iş teslim tarihlerini karşılayacak kadar hızlı olup olmadığı gibi kritik soruları yanıtlamaya yardımcı olur. Neden önemli Süreç performansını iş son teslim tarihlerine karşı ölçmek ve zamanında yerine getirme yeteneklerini değerlendirmek için bir kıyaslama sağlar. Nereden alınır Genellikle kullanıcı tarafından talep oluşturma sırasında girilir ve talep başlığında veya kalem detaylarında saklanır. Örnekler 2024-06-302024-07-152024-08-01 | |||
| Aciliyet Seviyesi UrgencyLevel | Talebin öncelik veya aciliyetini belirten bir sınıflandırma; örneğin 'Yüksek', 'Orta' veya 'Düşük'. | ||
| Açıklama Aciliyet Seviyesi, bazen Öncelik olarak da adlandırılır, talep edenler tarafından istenen mal veya hizmetlerin ne kadar hızlı gerektiği belirtmek için kullanılan bir alandır. Bu sınıflandırma, talebin tedarik ekibi ve onaylayanlar tarafından nasıl yönlendirildiğini ve önceliklendirildiğini etkileyebilir. Aciliyet seviyesine göre süreç performansını analiz etmek, sürecin iş ihtiyaçlarına duyarlı olup olmadığını belirlemeye yardımcı olur. Örneğin, 'Yüksek' aciliyetli taleplerin 'Düşük' aciliyetli olanlardan gerçekten daha hızlı işlenip işlenmediği doğrulanabilir. Eğer değilse, bu bir bottleneck'i veya ele alınması gereken önceliklendirme mekanizmasında bir hatayı gösterebilir. Neden önemli Sürecin acil talepleri etkili bir şekilde önceliklendirip önceliklendirmediğini ve belirtilen aciliyetin gerçek işleme hızıyla uyumlu olup olmadığını değerlendirmeye yardımcı olur. Nereden alınır Genellikle talep oluşturma formunda isteğe bağlı veya zorunlu bir alan olup, talep başlığında saklanır. Örnekler YüksekOrtaDüşükAcil | |||
| Kullanıcı Adı UserName | Oluşturma, düzenleme veya onaylama gibi belirli bir etkinliği gerçekleştiren kullanıcının adı. | ||
| Açıklama Kullanıcı Adı, süreç log'undaki herhangi bir etkinlikten sorumlu kişiyi tanımlar. Bu, talep edeni, bir düzenleyiciyi, bir onaylayanı veya taleple etkileşimde bulunan başka herhangi birini yakalayabilen genel bir özniteliktir. Bu öznitelik, kaynak ve otomasyon analizi için temeldir. 'Dört göz prensibini' (farklı kullanıcılar arasındaki devirler) anlamaya yardımcı olur ve sistem veya batch kullanıcıları tarafından gerçekleştirilen etkinlikleri belirleyerek otomasyon oranlarını hesaplamak için kullanılabilir. Etkinlikleri kullanıcıya göre analiz etmek, farklı rollerin süreçle nasıl etkileşime girdiğini anlamaya yardımcı olur. Neden önemli Bu öznitelik, kullanıcı devirlerini anlamak, otomasyonu analiz etmek ve belirli süreç adımlarını doğru aktöre atfetmek için çok önemlidir. Nereden alınır Her işlem için denetim izinde veya Örnekler asmithjdoeBATCH_USER | |||
| Onaylayanın Adı ApproverName | Bir onay veya ret etkinliğinden sorumlu kullanıcının veya grubun adı. | ||
| Açıklama Onaylayan Adı, iş akışındaki bir onay veya ret adımını gerçekleştiren kişiyi, rolü veya grubu tanımlar. Bu, talep eden veya diğer faaliyetleri gerçekleştirebilecek genel kullanıcıdan farklıdır. Bu nitelik, onay sürecinin kendisini analiz etmek için anahtardır. Bir onaylayıcının karar verme süresi gibi onaylayıcı performansını ölçmeye yardımcı olur. Ayrıca, belirli onaylayıcıların süreçte darboğaz olup olmadığını gösteren iş yükü dağılımını da belirleyebilir. Bu analiz, onay zinciri içindeki daha iyi kaynak tahsisini ve performans yönetimini destekler. Neden önemli Onay Nereden alınır Onayla ilgili faaliyetler için Örnekler Alice JohnsonBob WilliamsFinans Onay Grubu | |||
| Ret Nedeni RejectionReason | Bir talebin veya onay adımının reddedilmesi durumunda onaylayan tarafından belirtilen neden. | ||
| Açıklama Ret Nedeni, bir talebin neden reddedildiğini açıklayan bir metin alanı veya koddur. Onaylayanlar, talebi değiştirmesi ve yeniden göndermesi gerekebilecek talep edene geri bildirim sağlamak için bu bilgiyi sunar. Bu öznitelik, süreç hatalarının temel neden analizleri için paha biçilmezdir. Ret nedenlerini kategorize ederek ve analiz ederek kuruluşlar, 'Yanlış GL Kodu', 'Bütçe Aşıldı' veya 'Uyumsuz Tedarikçi' gibi yaygın sorunları belirleyebilir. Bu içgörüler, talep edenler için daha iyi eğitim, daha net politika iletişimi veya yaygın hataları önlemek için sistem geliştirmeleri gibi hedeflenmiş iyileştirmeleri tetikleyebilir. Neden önemli Taleplerin neden başarısız olduğuna dair doğrudan içgörü sunar, yeniden işleme sürecini azaltmak ve ilk seferde onay oranlarını iyileştirmek için kök neden analizine olanak tanır. Nereden alınır Genellikle 'Reddedildi' etkinliği veya durum değişikliği ile ilişkili bir yorumlar veya notlar alanında yakalanır. Örnekler Bütçe AşıldıYanlış Maliyet MerkeziTekrar Eden TalepPolitika İhlali | |||
Satın Alma-Ödeme (Purchase to Pay) - Talep Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Satın Alma Siparişi Oluşturuldu | Onaylanmış bir veya daha fazla talep satırındaki bilgilere dayanarak resmi bir satın alma siparişi belgesi oluşturulur. Bu olay, dahili talep sürecinden harici tedarik sürecine geçişi işaret eder. | ||
| Neden önemli Bu, talep sürecinin birincil başarılı sonucudur. Nihai onaydan PO oluşturulmasına kadar geçen süre, satın alma departmanının verimliliğini ölçer. Nereden alınır Bu event, talep ID'sini referans alan karşılık gelen bir satın alma siparişi belgesi bulunarak talep için çıkarılır. Yakala Talep kimliğini referans alan satın alma siparişinin oluşturulma Event tipi inferred | |||
| Talep Değiştirildi | Bir kullanıcı, talep gönderildikten sonra onu değiştirir, genellikle bilgileri düzeltmek veya bir reddetmeye yanıt vermek için. Bu eylem genellikle miktar, fiyat veya satır öğeleri gibi detayları düzenlemeyi içerir ve onay sürecinin yeniden başlamasını gerektirebilir. | ||
| Neden önemli Değişiklikleri takip etmek, yeniden işleme döngülerini, süreç verimsizliklerini ve belirsiz başlangıç gereksinimlerini belirlemek için çok önemlidir. Yüksek değişiklik oranları, çevrim sürelerini önemli ölçüde uzatabilir. Nereden alınır Sistem denetim izlerinden, değişiklik Yakala İlk gönderimden sonra temel talep alanlarındaki düzenlemelere karşılık gelen olayları değişiklik veya denetim Event tipi explicit | |||
| Talep Gönderildi | Talep eden, tamamlanmış talebi resmi olarak onay workflow'una gönderir. Bu eylem, talebi taslak durumundan, inceleme ve onay bekleyen aktif bir duruma geçirir. | ||
| Neden önemli Bu event, resmi onay sürecini tetikler. Gönderim ile nihai onay arasındaki süre, genel çevrim süresinin kritik bir bileşenidir. Nereden alınır Genellikle bir durum değişikliği event'inden, bir kullanıcı eylem log'undan veya bir onay sürecinin başlangıcını gösteren bir workflow engine log'undan yakalanır. Yakala Talep durumunun taslak halinden onay beklediğini gösteren bir duruma geçtiği zaman damgasını kaydedin. Event tipi explicit | |||
| Talep Kapatıldı | Talep idari olarak kapatılmıştır, bu da üzerinde başka bir işlem yapılmayacağını gösterir. Bu genellikle, tüm kalemleri satın alma siparişlerine tamamen dönüştürüldükten veya iptal edildikten sonra meydana gelir. | ||
| Neden önemli Bu, talebin yaşam döngüsünün tamamlandığını onaylayan sürecin nihai son event'idir. Eski taleplerin süresiz olarak açık kalmamasını sağlar. Nereden alınır Talep başlığındaki nihai durum güncellemesinden veya tüm ilgili kalemlerin tamamen sipariş edildi veya kapatıldı olarak işaretlenmesinden çıkarılır. Yakala Talebin son durumunun 'Kapalı' veya 'Tamamlandı' olarak ayarlandığı zaman damgasını kaydedin. Event tipi inferred | |||
| Talep Oluşturuldu | Bir kullanıcı, yeni bir satın alma talep belgesi oluşturarak mal veya hizmet talebini başlatır. Bu olay, talebin yaşam döngüsünün başlangıcını işaret eder ve genellikle resmi gönderimden önce taslak veya eksik bir durumla başlar. | ||
| Neden önemli Bu, sürecin birincil başlangıç event'idir. Oluşturmadan gönderime kadar geçen süreyi analiz etmek, talep hazırlığındaki gecikmeleri veya kullanıcı belirsizliğini ortaya çıkarabilir. Nereden alınır Bu, genellikle ana satın alma talebi başlık kaydındaki veya tablosundaki oluşturma timestamp'inden yakalanır. Yakala Satın alma talebi başlığının ilk kayıt oluşturma Event tipi explicit | |||
| Talep Onaylandı | Talep, onay workflow'undaki tüm gerekli adımları başarıyla geçmiştir. Bu kilometre taşı, talebi tedarik edilmeye veya satın alma siparişine dönüştürülmeye uygun hale getirir. | ||
| Neden önemli Bu, önemli bir başarı kilometre taşıdır. Bu duruma ulaşmak için geçen süre, talep süreci verimliliğinin birincil ölçüsüdür. Nereden alınır Talep başlığının genel durumunun 'Onaylandı' veya Yakala Genel talep durumunun ilk kez 'Onaylandı' veya eşdeğerine değiştiği zaman damgasını kaydedin. Event tipi inferred | |||
| Talep Reddedildi | Talep, onay süreci sırasında kesin olarak reddedilir ve bir satın alma siparişine dönüştürülmez. Bu, talep için nihai, başarısız bir sonucu temsil eder. | ||
| Neden önemli Bu, önemli bir başarısızlık kilometre taşıdır. Nihai ret nedenlerini analiz etmek, ön uç süreçleri ve talep eden eğitimini iyileştirmeye yardımcı olabilir. Nereden alınır Talep başlığının genel durumunun 'Reddedildi', 'Onaylanmadı' veya benzer bir terminal ret durumuna değişmesinden çıkarılır. Yakala Genel talep durumunun ilk kez 'Reddedildi', 'Onaylanmadı' veya eşdeğerine değiştiği zaman damgasını kaydedin. Event tipi inferred | |||
| Onay Adımı Başlatıldı | Talep, çok adımlı bir workflow'un parçası olarak belirli bir onaylayana veya onay grubuna atanır. Bu etkinlik, belirli bir onay eylemi için bekleme süresinin başlangıcını işaretler. | ||
| Neden önemli Bu event, onay zinciri içindeki bottleneck'lerin ayrıntılı analizine olanak tanır, gecikmelere neden olan belirli onaylayanları veya aşamaları belirler. Nereden alınır Yeni bir onay görevi oluşturulduğunda ve bir kullanıcıya veya role atandığında Yakala Bir onay görevinin oluşturulduğu veya talep durumunun belirli bir onaylayıcıyı beklediğini gösterdiği zaman damgasını kaydedin. Event tipi inferred | |||
| Onay Adımı Onaylandı | Bireysel bir onaylayan, talebe iş akışındaki belirlenmiş aşamasında onay verir. Bu eylem, talebi bir sonraki adıma veya nihai onaya daha yakına taşır. | ||
| Neden önemli Bir onay adımının başlangıcı ile bitişi arasındaki sürenin analizi, bireysel onaylayıcı performansını ve iş yükü dağılımını ortaya çıkarır. Nereden alınır Onay geçmişi log'larında veya iş akışı işlem verilerinde kaydedilen açık bir kullanıcı eyleminden yakalanır. Yakala Onay geçmişi veya iş akışı Event tipi explicit | |||
| Onay Adımı Reddedildi | Bireysel bir onaylayan, talebi belirlenmiş aşamasında reddeder ve genellikle düzeltilmesi için talep edene geri gönderir. Bu eylem, onay iş akışının ilerlemesini durdurur. | ||
| Neden önemli Bu etkinlik, yeniden işleme için birincil bir tetikleyicidir. Bu retleri takip etmek, başarısızlığın yaygın nedenlerini, eğitim ihtiyaçlarını ve sorunlu onay aşamalarını belirlemeye yardımcı olur. Nereden alınır Onay geçmişi log'larında veya iş akışı işlem verilerinde kaydedilen açık bir kullanıcı eyleminden yakalanır. Yakala Onay geçmişi veya iş akışı Event tipi explicit | |||
| Onay Sıfırlandı | Talebin tüm onay workflow'u sıfırlanır ve sürecin baştan başlamasına neden olur. Bu genellikle, zaten devam etmekte olan bir talepte önemli bir değişiklik yapıldıktan sonra meydana gelir. | ||
| Neden önemli Onay sıfırlamaları, uzayan döngü sürelerinin önemli bir nedenidir. Bunların sıklığını ve tetikleyicilerini belirlemek, politika sorunlarına veya düzeltme sürecindeki problemlere işaret edebilir. Nereden alınır Onay durumunun daha önce sonraki bir onaylayıcıya atanmış olmasına rağmen başlangıç adımına temizlenmesi veya sıfırlanması gözlemlenerek çıkarılır. Yakala Onay Event tipi inferred | |||
| Talep Geri Çekildi | Talep eden veya yetkili bir kullanıcı, talep nihai onay almadan veya siparişe dönüştürülmeden önce talebi iptal eder. Bu eylem, bu özel talep için süreci sonlandırır. | ||
| Neden önemli Bu, süreci net bir başarı veya başarısızlık sonucu olmadan sonlandıran terminal bir event'tir. Yüksek çekilme oranları, değişen iş ihtiyaçlarını veya erken talepleri gösterebilir. Nereden alınır Genellikle 'Geri Çekildi' veya 'İptal Edildi' durum değişikliği ile sonuçlanan açık bir kullanıcı eylemi olarak veya bir silme bayrağı ayarlayarak kaydedilir. Yakala Talep durumunun 'Geri Çekildi', 'İptal Edildi' olarak güncellendiği veya bir silme işaretinin ayarlandığı zaman damgasını kaydedin. Event tipi explicit | |||
| Tedarik Kaynağı Atandı | Bir satın alma uzmanı veya tedarik sorumlusu, onaylanmış bir talep satırına belirli bir tedarikçi, sözleşme veya fiyatlandırma anlaşması atar. Bu, satın alma siparişini oluşturmadan önceki hazırlık adımıdır. | ||
| Neden önemli Bu etkinlik, taktik tedarik ekibinin verimliliğini ölçer. Buradaki gecikmeler, talep onayı ile sipariş yerleştirme arasında bir bottleneck oluşturabilir. Nereden alınır Onaylandıktan sonra talep satır öğesindeki tedarikçi veya kaynak bilgi alanlarındaki güncellemelerin gözlemlenmesiyle yakalanır. Yakala Onaylanmış bir talep satırında bir tedarikçi veya sözleşme kimliğinin ilk kez doldurulduğu zaman damgasını belirleyin. Event tipi explicit | |||
Veri Çekim Kılavuzları
Veri çıkarma yöntemleri sisteme göre değişir. Detaylı talimatlar için,