Satın Almadan Ödemeye - Talep Veri Şablonunuz
Satın Almadan Ödemeye - Talep Veri Şablonunuz
- Kapsamlı analiz için önerilen özellikler
- Takip Edilecek Temel Süreç Aktiviteleri
- Pratik veri çıkarma rehberliği
Satın Alma-Ödeme - Talep Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Faaliyet Adı
ActivityName
|
Talep için belirli bir zamanda gerçekleşen özel iş faaliyetinin veya event'in adı. | ||
|
Açıklama
Bu öznitelik, satın alma talebi yaşam döngüsündeki farklı adımları kaydeder. Örnekler arasında 'Talep Oluşturuldu', 'Onay Adımı Onaylandı' ve 'Talep Kaynaklandı' bulunur. Her faaliyet, talep üzerinde atılan belirli bir kilometre taşını veya eylemi temsil eder. Bu faaliyetlerin sırasını ve sıklığını analiz etmek, süreç haritalarının görselleştirilmesini, yaygın yolların belirlenmesini ve standart prosedürden sapmaların tespit edilmesini sağladığı için process mining için temeldir.
Neden önemli
Süreç haritasındaki adımları tanımlayarak, talep akışının görselleştirilmesini ve analiz edilmesini sağlar.
Nereden alınır
Bu, genellikle Coupa sistemi içindeki event log'larından, durum değişikliği kayıtlarından veya denetim izlerinden türetilir. Durum alanlarından veya eylem kodlarından eşleştirmeyi gerektirebilir.
Örnekler
Talep OluşturulduTalep GönderildiOnay Adımı OnaylandıTalep ReddedildiSatın Alma Siparişi Oluşturuldu
|
|||
|
Olay Zamanı
EventTime
|
Aktivitenin meydana geldiği kesin tarih ve saat. | ||
|
Açıklama
Olay Zamanı veya zaman damgası, bir satın alma talebi için bir faaliyetin kaydedildiği tam anı yakalar. Bu veri, süreç akışını oluşturmak için olayların kronolojik sıralaması açısından kritik öneme sahiptir. Döngü sürelerini hesaplama, faaliyetler arasındaki süreyi ölçerek darboğazları belirleme ve farklı zaman dilimlerindeki süreç performansını anlama dahil olmak üzere tüm zaman tabanlı analizlerin temelidir. Doğru ve ayrıntılı zaman damgaları, anlamlı süreç analizi için hayati öneme sahiptir.
Neden önemli
Bu timestamp, event'leri doğru bir şekilde sıralamak ve döngü süreleri ve bottleneck'ler gibi tüm süreye dayalı metrikleri hesaplamak için çok önemlidir.
Nereden alınır
Bu bilgi, Coupa'daki her talep için denetim izinde veya geçmiş kayıtlarında, genellikle her eylem için 'created_at' veya 'updated_at' alanı olarak yakalanır.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
|
|||
|
Satın Alma İsteği Kimliği
PurchaseRequisitionId
|
Her satın alma talebi için benzersiz tanımlayıcı, süreç için birincil durum tanımlayıcısı olarak hizmet eder. | ||
|
Açıklama
Satın Alma Talep ID'si, tek bir mal veya hizmet talebiyle ilgili tüm faaliyetleri birbirine bağlayan merkezi anahtardır. Her talebe oluşturulduğunda benzersiz bir ID atanır ve bu, yaşam döngüsü boyunca sabit kalır. Bu, talebin ilk oluşturulmasından ve gönderilmesinden, tüm onay veya reddetme adımlarından, nihai kaynak bulma ve kapanışına kadar uçtan uca izlenmesini sağlar. Process mining'de, her event log girdisi bu ID'ye bağlanır ve her bir durum için tam yolculuğun yeniden yapılandırılmasını sağlar.
Neden önemli
Bu, tüm süreç adımlarını birbirine bağlayan, talebin yaşam döngüsünün baştan sona tam bir analizini sağlayan temel Durum ID'sidir.
Nereden alınır
Bu, Coupa'nın Talepler modülünde ve ilgili data dışa aktarımlarında bulunan birincil anahtar alanıdır.
Örnekler
PR-102934PR-102935PR-102936
|
|||
|
Kaynak Sistem
SourceSystem
|
`veri`nin çıkarıldığı kaynak sistemi tanımlar. | ||
|
Açıklama
Bu öznitelik, süreç data'sının kaynaklandığı kayıt sistemini belirtir. Bu analiz için değer sürekli olarak 'Coupa' olacaktır. Bu alanı dahil etmek, özellikle data'nın birden çok sistemden birleştirilebileceği ortamlarda en iyi uygulamadır. Data geçmişi hakkında temel bağlam sağlar ve data yönetimi ile kalite kurallarını yönetmeye yardımcı olur.
Neden önemli
Data yönetimi ve birden çok kurumsal sistemden data birleştirilirken kritik olan net data geçmişi sağlar.
Nereden alınır
Bu genellikle, veri kümesinin kökenini etiketlemek için veri çıkarma ve dönüştürme süreci sırasında eklenen statik bir değerdir.
Örnekler
Coupa
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden son yenilendiği zamanı gösteren `timestamp`. | ||
|
Açıklama
Bu öznitelik, Coupa'dan en son data çıkarma tarihini ve saatini kaydeder. Analiz edilen data'nın güncelliği konusunda şeffaflık sağlar. Data'nın ne kadar yeni olduğunu bilmek, kullanıcıların içgörülerin mevcut operasyonel durumu mu yoksa daha önceki bir zaman noktasını mı yansıttığını anlamaları için kritiktir. Bu, devam eden operasyonları izleyen dashboard'lar için özellikle önemlidir.
Neden önemli
Kullanıcılara verinin güncelliği hakkında bilgi verir, böylece analizin zaman çerçevesini anlamalarını ve güncel bilgilere dayanarak karar vermelerini sağlar.
Nereden alınır
Bu timestamp, başarılı bir data çıkarma çalıştırmasının sonunda data boru hattı veya ETL aracı tarafından oluşturulur ve eklenir.
Örnekler
2024-05-21T02:00:00Z
|
|||
|
Bölüm
Department
|
Talebin yüklendiği iş departmanı veya maliyet merkezi. | ||
|
Açıklama
Departman özniteliği, her talebi belirli bir organizasyonel birime veya maliyet merkezine bağlar. Bu, karşılaştırmalı analiz için kritik bir boyuttur. Dashboard'ların ve KPI'ların departmana göre filtrelenmesine ve bölümlere ayrılmasına olanak tanıyarak yöneticilerin onay döngü sürelerini, reddetme oranlarını ve kuruluşun farklı bölümlerindeki uyumluluğu karşılaştırmasını sağlar. Bu, departmana özgü sorunları veya en iyi uygulamaları belirlemeye yardımcı olur.
Neden önemli
Farklı iş birimleri arasında süreç döngü süresi ve ret oranları gibi KPI'ların karşılaştırılmasını sağlayarak iyileştirme alanlarını vurgular.
Nereden alınır
Bu, Coupa'daki Talep nesnesi üzerinde, genellikle talep sahibinin kullanıcı profiliyle ilişkili veya talep kalemlerinde belirtilen standart bir alandır.
Örnekler
PazarlamaBT OperasyonlarıTesislerAraştırma ve Geliştirme
|
|||
|
Onaylayan
Approver
|
Bir onay faaliyetinden sorumlu kullanıcı veya grup. | ||
|
Açıklama
Bu öznitelik, bir onay adımına atanan belirli bireyi veya onay grubunu tanımlar. 'Onay Adımı Başlatıldı', 'Onay Adımı Onaylandı' ve 'Onay Adımı Reddedildi' gibi faaliyetler için doldurulur. Data'yı onaylayana göre analiz etmek, 'Onaylayıcı Performansı ve Yükü' dashboard'ını oluşturmak için anahtardır. Bireysel onay sürelerini ölçmeye, belirli onaylayıcıların neden olduğu bottleneck'leri belirlemeye ve iş yükü dağılımını değerlendirmeye yardımcı olur.
Neden önemli
Onaylayan performansını, iş yükü dengelemesini ve belirli kişilere veya onay gruplarına ilişkin darboğazları analiz etmek için kritik öneme sahiptir.
Nereden alınır
Bu bilgi, Coupa'daki her taleple ilişkili onay zinciri detaylarında bulunur. Kullanıcı data'sıyla birleştirmeyi gerektirebilir.
Örnekler
David MillerFinans Onaycıları L2Susan Chen
|
|||
|
Talep Durumu
RequisitionStatus
|
Satın alma talebinin mevcut veya nihai durumu. | ||
|
Açıklama
Bu öznitelik, data çıkarımı anındaki talebin genel durumunu veya nihai sonucunu gösterir. Yaygın durumlar arasında 'Onay Bekliyor', 'Onaylandı', 'Reddedildi', 'Geri Çekildi' ve 'Kapatıldı' bulunur. Bu, filtreleme ve analiz için önemli bir boyuttur. Onay ve ret oranlarını hesaplamak, açık taleplerin mevcut iş yükünü izlemek ve taleplerin nihai durumunu anlamak için kullanılır.
Neden önemli
Talep sonuçlarını anlamak, onay ve ret oranlarını hesaplamak ve devam eden taleplerin mevcut durumunu izlemek için çok önemlidir.
Nereden alınır
Bu, Coupa'daki Satın Alma Talep nesnesi üzerinde bulunan, genellikle 'status' veya 'state' olarak adlandırılan standart bir alandır.
Örnekler
Onay BekliyorOnaylandıReddedildiGeri ÇekildiKapalı
|
|||
|
Talep Eden
Requester
|
Satın alma talebini oluşturan ve gönderen çalışan. | ||
|
Açıklama
Bu öznitelik, talebi başlatan kişiyi tanımlar. Data'yı talep sahibine göre analiz etmek, yüksek değişiklik oranları veya sık reddetmeler gibi belirli kullanıcılarla ilgili kalıpları belirlemeye yardımcı olur; bu da ek eğitim ihtiyacını gösterebilir. Ayrıca, farklı kullanıcılar veya kullanıcı grupları için talep hacimlerini ve süreç davranışını analiz etmek için de kullanılır.
Neden önemli
Süreç davranışının kullanıcıya göre analiz edilmesini sağlar, eğitim ihtiyaçlarını belirlemeye ve farklı bireylerin süreçle nasıl etkileşimde bulunduğunu anlamaya yardımcı olur.
Nereden alınır
Coupa'daki Talep nesnesinde standart bir alan olarak mevcuttur, genellikle Kullanıcı nesnesine bağlanır ve 'talep eden' veya 'oluşturan' olarak adlandırılır.
Örnekler
Alice Johnson`Bob Smith``Charlie Brown`
|
|||
|
Toplam Tutar
TotalAmount
|
Satın alma talebinin toplam parasal değeri. | ||
|
Açıklama
Bu öznitelik, talepte istenen tüm mal ve hizmetlerin toplam maliyetini temsil eder. Miktar, onay workflow'unun karmaşıklığını sıkça etkilediği için süreç analizinde kritik bir faktördür; daha yüksek değerli talepler genellikle daha fazla onay adımı gerektirir. Süreç metriklerini değer aralıklarına göre (örn., <1000 Dolar, 1000 Dolar-10000 Dolar) analiz etmek, sürecin farklı finansal öneme sahip talepleri nasıl ele aldığını ortaya çıkarabilir.
Neden önemli
Farklı değerdeki talepler için sürecin nasıl değiştiğini analiz etmeye yardımcı olur, çünkü daha yüksek tutarlar genellikle daha karmaşık onay iş akışlarını tetikler.
Nereden alınır
Bu, Coupa'daki Talep nesnesinin başlığında bulunan, tipik olarak 'total' veya 'total_amount' olarak adlandırılan standart bir alandır.
Örnekler
500.0012550.7599.99
|
|||
|
```Malzeme Türü```
Commodity
|
Talep edilen mal veya hizmetlerin üst düzey kategorisi. | ||
|
Açıklama
Ürün/Hizmet Kodu özniteliği, 'Ofis Malzemeleri', 'Bilgisayar Donanımı' veya 'Pazarlama Hizmetleri' gibi talepteki kalemler için standart bir sınıflandırma sağlar. Bu, satın alma kalıplarının ve süreç varyasyonlarının neyin satın alındığına göre analiz edilmesini sağlar. Belirli ürün/hizmet kodları özel onay gereksinimlerine veya kaynak bulma stratejilerine sahip olabilir ve süreci ürün/hizmet koduna göre analiz etmek, farklı harcama kategorileri için satın almayı optimize etmeye yardımcı olabilir.
Neden önemli
Harcama kategorilerini analiz etmeye ve onay süreleri gibi süreç davranışlarının satın alınan mal veya hizmet türüne göre değişip değişmediğini anlamaya yardımcı olur.
Nereden alınır
Bu, Coupa'da tipik olarak talep kalemi düzeyinde bulunan standart bir alandır. Başlık düzeyine toplanması gerekebilir.
Örnekler
Ofis MalzemeleriBilgisayar DonanımıPazarlama HizmetleriSeyahat
|
|||
|
Aciliyet Seviyesi
UrgencyLevel
|
Talebin aciliyetini belirten, 'Yüksek', 'Orta' veya 'Düşük' gibi bir sınıflandırma. | ||
|
Açıklama
Aciliyet Seviyesi, genellikle bir öncelik alanıyla eşleştirilir ve talep sahiplerinin hızlandırılmış işlem gerektiren talepleri işaretlemesine olanak tanır. Bu öznitelik, 'Acil Talep İşlem Süresi' dashboard'ı için temeldir. Yüksek aciliyetli taleplerin döngü sürelerini standart olanlarla karşılaştırarak, kuruluşlar önceliklendirme mekanizmalarının etkin olup olmadığını ve acil iş ihtiyaçlarının zamanında karşılanıp karşılanmadığını değerlendirebilir.
Neden önemli
Acil taleplerin standart olanlardan daha hızlı işlenip işlenmediğinin analiz edilmesini sağlayarak önceliklendirme politikalarının etkinliğini doğrular.
Nereden alınır
Bu, Coupa'daki Talep nesnesi üzerinde standart veya özel bir alan olabilir. Coupa belgelerine veya sistem yapılandırmasına başvurun.
Örnekler
YüksekOrtaDüşük
|
|||
|
Değişiklik Yapıldı
IsAmended
|
İlk gönderiminden sonra talebin bir veya daha fazla kez değiştirildiğini gösteren bir boole bayrağıdır. | ||
|
Açıklama
Bu hesaplanan öznitelik, belirli bir durum için 'Talep Değiştirildi' faaliyetinin gerçekleşip gerçekleşmediğini gösteren basit bir bayraktır (Doğru/Yanlış). Kullanıcıların değişiklik gerektiren talepleri kolayca izole etmesine olanak tanıyarak analizi ve filtrelemeyi basitleştirir. Bu, Talep Değişiklik Oranı KPI'sını hesaplamak ve 'Talep Değişiklik Hacmi' dashboard'ını desteklemek için kullanılır; bu da yeniden işleme nedenlerini belirlemeye ve ilk seferde kaliteyi iyileştirmeye yardımcı olur.
Neden önemli
Değişiklik oranı KPI'sının hesaplanmasını basitleştirir ve yeniden işleme gerektiren vakalar ile gerektirmeyenlerin kolayca bölümlere ayrılmasını sağlar.
Nereden alınır
Bu, process mining aracında, her durum için event log içinde bir 'Talep Değiştirildi' faaliyetinin varlığı kontrol edilerek hesaplanır.
Örnekler
truefalse
|
|||
|
Onay Adım Sayısı
ApprovalStepCount
|
Bir talebin geçtiği toplam onay adımı sayısı. | ||
|
Açıklama
Bu hesaplanan öznitelik, her talep için farklı 'Onay Adımı Onaylandı' faaliyetlerinin sayısını sayar. Her durum için onay workflow'unun karmaşıklığını ölçmeye yardımcı olur. Bu, 'Ortalama Onay Adımı Sayısı' KPI'sının temelidir ve olağandışı uzun veya karmaşık onay yollarını izleyen talepleri belirlemek için faydalıdır; bu da workflow basitleştirmesi ihtiyacını gösterebilir.
Neden önemli
Her talep için onay workflow'unun karmaşıklığını ölçerek, aşırı karmaşık ve düzene sokulması gereken yolları belirlemeye yardımcı olur.
Nereden alınır
Bu metrik, process mining aracında her Durum ID'si için 'Onay Adımı Onaylandı' olaylarının sayısını sayarak hesaplanır.
Örnekler
253
|
|||
|
Onay Adımı Süresi
ApprovalStepDuration
|
Bir talebin tek bir onay adımında beklediği süre. | ||
|
Açıklama
Bu hesaplanan metrik, 'Onay Adımı Başlatıldı' faaliyeti ile buna karşılık gelen 'Onay Adımı Onaylandı' veya 'Onay Adımı Reddedildi' faaliyeti arasındaki süreyi ölçer. Onay zincirinin her farklı aşamasındaki bekleme süresini izole eder. Bu, 'Kritik Onay Adımı Bottleneck'leri' dashboard'ı için çok önemlidir, çünkü genel süreçteki en önemli gecikmelere hangi onaylayıcıların veya onay aşamalarının neden olduğunu tam olarak belirler.
Neden önemli
Onay workflow'u içindeki belirli bottleneck'leri, sadece toplam döngü süresini değil, her bir adımda bekleme süresini ölçerek belirler.
Nereden alınır
Süreç madenciliği aracında, 'Onay Adımı Başlatıldı' ile sonraki terminal onay olayı (Onaylandı/Reddedildi) arasındaki zaman farkı bulunarak hesaplanır.
Örnekler
1.2 gün4 saat3.8 gün
|
|||
|
Onay İş Akışı Yolu
ApprovalWorkflowPath
|
Talebe uygulanan belirli onay zinciri veya iş akışı şablonu için bir tanımlayıcı. | ||
|
Açıklama
Bu öznitelik, bir talebin takip etmesi gereken önceden tanımlanmış onaylayanlar dizisini tanımlar. Genellikle miktar, departman ve talep türü gibi faktörlere dayalı iş kuralları tarafından belirlenir. Bu özniteliği analiz etmek, 'Talep Politikası Uyumluluğu' dashboard'ının merkezindedir. Gerçek onaylayanlar dizisini atanan workflow yoluyla karşılaştırarak sapmaları tespit etmek, uyumluluk oranlarını ölçmek ve yönetilmeyen istisnaları belirlemek mümkün hale gelir.
Neden önemli
Beklenen ve gerçekleşen onay adımları arasında karşılaştırma yaparak süreç sapmalarını vurgulayarak uyumluluk analizi yapılmasını sağlar.
Nereden alınır
Coupa dokümantasyonuna başvurun. Bu, talep için tetiklenen onay zincirinin veya iş akışı kuralının adından türetilebilir.
Örnekler
Standart Onay <5 bin DolarBT Donanım Onayı >10 bin DolarSermaye Gideri CFO İncelemesi
|
|||
|
Para Birimi
Currency
|
Talebin toplam tutarı için para birimi kodu. | ||
|
Açıklama
Bu öznitelik, talebin Toplam Tutarının hangi para biriminde (örn., USD, EUR, GBP) olduğunu belirtir. Özellikle birden çok para birimiyle çalışan çok uluslu kuruluşlar için herhangi bir finansal analiz için temel bir bağlamdır. Parasal değerlerin doğru yorumlanmasını sağlar ve finansal raporlama ile dashboard'larda doğru dönüşüm ve toplama yapılmasına olanak tanır.
Neden önemli
Toplam Tutar özniteliği için gerekli bağlamı sağlar, çoklu para birimi ortamlarında doğru finansal analiz sağlar.
Nereden alınır
Bu, Coupa'daki Talep nesnesi üzerinde, genellikle 'currency_code' veya benzeri olarak adlandırılan standart bir alandır.
Örnekler
USDEURGBP
|
|||
|
Ret Nedeni
RejectionReason
|
Bir talep veya onay adımı reddedildiğinde, onaylayan tarafından sağlanan neden. | ||
|
Açıklama
Bir onaylayan bir talebi reddettiğinde, genellikle kararı için bir neden sunar. Bu öznitelik, bu metinsel açıklamayı yakalar. Reddetme nedenlerini analiz etmek, taleplerin neden başarısız olduğuna dair doğrudan, niteliksel geri bildirim sağlar. Bu içgörü, kök neden analizi için paha biçilmezdir; yanlış kodlama, bütçe eksikliği veya yetersiz gerekçe gibi yaygın sorunları belirlemeye yardımcı olur; bunlar daha sonra eğitim veya süreç iyileştirmeleri yoluyla ele alınabilir.
Neden önemli
Süreç başarısızlıklarının temel nedenlerine doğrudan içgörü sağlar, kullanıcı eğitimi veya süreç açıklığa kavuşturma alanlarını belirlemeye yardımcı olur.
Nereden alınır
Bu bilgi, genellikle talebin onay geçmişinde 'Reddedildi' durum değişikliği ile ilişkili yorumlar veya notlar alanında yakalanır.
Örnekler
Yanlış maliyet merkeziBu çeyrek için bütçeyi aşıyorYinelenen talepYetersiz gerekçe sunuldu
|
|||
|
Satın Alma Siparişi Kimliği
PurchaseOrderId
|
Onaylanan talepten oluşturulan satın alma siparişinin tanımlayıcısı. | ||
|
Açıklama
Bir talep tamamen onaylandıktan ve kaynak sağlandıktan sonra, genellikle bir satın alma siparişi oluşturulur. Bu öznitelik, ortaya çıkan bu PO'nun ID'sini saklar. Yukarı akış Talep süreci ile aşağı akış Satın Alma Siparişi süreci arasında önemli bir bağlantı görevi görür. 'Talep Onayından PO Oluşturmaya Kadar Geçen Süre' KPI'ının hesaplanmasını sağlar ve tüm Satın Alma-Ödeme (Purchase-to-Pay) döngüsünün daha geniş, uçtan uca analizine olanak tanır.
Neden önemli
Talebi sonraki satın alma siparişiyle bağlar, devir süresinin analiz edilmesini sağlar ve uçtan uca daha geniş bir P2P görünümü kolaylaştırır.
Nereden alınır
Bu, Coupa'daki Talep nesnesi üzerinde, PO oluşturulduktan sonra doldurulan standart bir alandır.
Örnekler
PO-45000123PO-45000124PO-45000125
|
|||
|
Talep Onay Döngü Süresi
RequisitionApprovalCycleTime
|
Bir talebin ilk gönderildiği andan nihai onayı aldığı ana kadar geçen toplam süre. | ||
|
Açıklama
Bu, temel onay sürecinin süresini ölçen hesaplanmış bir metriktir. Her durum için 'Talep Gönderildi' faaliyeti ile 'Talep Onaylandı' faaliyeti arasındaki zaman farkı bulunarak hesaplanır. Bu süreç için en önemli KPI'lardan biridir, çünkü onay workflow'unun verimliliğini doğrudan niceliksel olarak belirler. Performansı izlemek, bottleneck'leri belirlemek ve süreç iyileştirme girişimlerinin etkisini ölçmek için birden çok dashboard'da kullanılır.
Neden önemli
Bu, süreç verimliliğini ölçmek için birincil bir KPI'dır. Onaylar için geçen süreyi niceliksel olarak belirler ve bottleneck'leri belirlemek için esastır.
Nereden alınır
Bu metrik, process mining aracında 'Talep Gönderildi' timestamp'ini 'Talep Onaylandı' timestamp'inden çıkararak hesaplanır.
Örnekler
2.5 gün8 saat15.2 gün
|
|||
|
Talep Türü
RequisitionType
|
Talebin kategorisi veya türü, örneğin 'Sermaye Harcaması', 'Operasyonel Gider' veya 'Yazılım'. | ||
|
Açıklama
Talep Tipi, talepleri iş amacına veya satın alma niteliğine göre kategorize etmeye yardımcı olan bir sınıflandırmadır. Bu öznitelik, uyumluluk analizi ve farklı türdeki taleplerin süreç boyunca nasıl aktığını anlamak için değerlidir. Örneğin, sermaye harcaması talepleri, standart operasyonel taleplere göre daha sıkı ve uzun bir onay yolunu izleyebilir. Süreci Talep Tipine göre analiz etmek, süreç optimizasyonu için değerli içgörüler ortaya çıkarabilir.
Neden önemli
Talebin iş amacına göre analizin segmentlere ayrılmasını sağlar, çünkü farklı türlerin farklı süreç akışları ve politikaları olabilir.
Nereden alınır
Bu, Coupa'daki Talep nesnesi üzerinde muhtemelen özel veya standart bir sınıflandırma alanıdır.
Örnekler
Sermaye GideriOperasyonel GiderBT DonanımıProfesyonel Hizmetler
|
|||
|
Tedarikçi Adı
SupplierName
|
Talep için seçilen tedarikçinin veya satıcının adı. | ||
|
Açıklama
Bu öznitelik, talep edilen mal veya hizmetler için hedeflenen tedarikçiyi tanımlar. Tedarikçi, talep sahibi tarafından belirtilebilir veya kaynak bulma sürecinde daha sonra eklenebilir. Süreç metriklerini tedarikçiye göre analiz etmek, tedarikçi performansını değerlendirmeye ve belirli tedarikçilerle etkileşimlerin daha uzun döngü sürelerine veya diğer süreç verimsizliklerine yol açıp açmadığını belirlemeye yardımcı olabilir. Satın alma stratejisi ve tedarikçi ilişkileri yönetimi için önemli bağlam sağlar.
Neden önemli
Seçilen tedarikçiye göre süreç performansının analiz edilmesini sağlar, bu da tedarik stratejileri ve tedarikçi yönetimi hakkında bilgi verebilir.
Nereden alınır
Bu bilgi, Coupa'daki Talep Kalemi nesnesinde, genellikle 'tedarikçi' veya 'satıcı' alanı olarak mevcuttur.
Örnekler
StaplesDell TechnologiesAccentureCDW
|
|||
Satın Alma-Ödeme - Talep Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Satın Alma Siparişi Oluşturuldu
|
Onaylanmış talep bilgilerine dayanarak başarılı bir şekilde bir satın alma siparişi (PO) oluşturulur. Bu olay, kaynak talep kimliğini referans alan bir PO kaydının oluşturulduğunda çıkarılır. | ||
|
Neden önemli
Bu, talep sürecinin birincil başarılı sonucudur ve Satın Alma-Ödeme'nin bir sonraki aşamasına devri işaretler. 'Talep Onaylandı'dan bu event'e kadar geçen süreyi analiz etmek, yürütmedeki gecikmeleri vurgular.
Nereden alınır
Oluşturan 'requisition_headers' veya 'requisition_lines' kimliğine geri referans içeren 'purchase_orders' tablosunda bir kaydın oluşturulmasından çıkarılır.
Yakala
Talep ID'sine bağlı PO kaydının 'created-at' timestamp'ini kullanın.
Event tipi
inferred
|
|||
|
Talep Gönderildi
|
Talep sahibi, tamamlanmış talebi resmi olarak onay workflow'una gönderir. Bu event, talebin durumunun sistemin denetim günlüklerinde veya geçmiş tablolarında 'taslak'tan 'onay bekliyor'a değişmesi gözlemlenerek çıkarılır. | ||
|
Neden önemli
Gönderim, onay sürecini tetikler ve bu da 'Ortalama Talep Onay Döngü Süresi' KPI'ını ölçmek için kritik bir kilometre taşıdır. Bu noktadan önceki gecikmeler kullanıcıyla ilgiliyken, sonrakiler süreçle ilgilidir.
Nereden alınır
'requisition_headers' tablosundaki bir durum değişikliğinden, özellikle 'status' alanı 'pending_approval' olarak değiştiğinde çıkarılır. Bu değişikliğin zaman damgası ilgili denetim izinde bulunur.
Yakala
Talebin durumunun ilk kez 'onay bekliyor' olarak değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Kapatıldı
|
Talep resmi olarak kapatılır; bu da üzerinde başka bir işlem yapılmayacağı anlamına gelir. Bu, bir PO oluşturulup karşılandıktan sonra veya talep onaylandıktan ancak sipariş verilmeden önce iptal edilirse gerçekleşebilir. | ||
|
Neden önemli
Bu faaliyet, talebin yaşam döngüsü için kesin bir bitiş noktası görevi görür. Durumların net bir sonuca ulaşmasını sağlayarak, süreç analizinde süresiz olarak 'aktif' görünmelerini engeller.
Nereden alınır
'requisition_headers' tablosundaki 'status' alanı 'closed' olarak güncellendiğinde bir durum değişikliğinden çıkarılır. Zaman damgası ilgili denetim izine kaydedilir.
Yakala
Talebin genel durumunun 'kapatıldı' olarak değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Oluşturuldu
|
Yeni bir satın alma talebi bir kullanıcı tarafından başlatılır ve taslak olarak kaydedilir. Bu, her talep vakasının başlangıç noktasıdır ve genellikle talep kaydının oluşturulma zaman damgasından çıkarılır. | ||
|
Neden önemli
Bu faaliyet, talep yaşam döngüsünün başlangıcını işaretler. Oluşturmadan gönderime kadar geçen süreyi analiz etmek, kullanıcı belirsizliğinden veya sistem karmaşıklığından kaynaklanan gecikmeleri ortaya çıkarabilir.
Nereden alınır
Bu event, belirli bir Satın Alma Talep ID'si için 'requisition_headers' tablosundaki 'created-at' timestamp'inden yakalanır.
Yakala
Talep başlığı kaydının oluşturulma timestamp'ini kullanın.
Event tipi
inferred
|
|||
|
Talep Onaylandı
|
Talep, onay workflow'undaki tüm gerekli adımları başarıyla geçmiştir. Bu, talep başlığının genel durumunun 'onaylandı' olarak değişmesinden çıkarılır. | ||
|
Neden önemli
Bu, onay döngüsünün sonunu işaretleyen kritik bir başarı kilometre taşıdır. Bu faaliyete ulaşma süresi birincil bir KPI'dır ve aşağı akış satın alma eylemleri için tetikleyici görevi görür.
Nereden alınır
'requisition_headers' tablosundaki 'status' alanı 'approved' olarak güncellendiğinde bir durum değişikliğinden çıkarılır. Zaman damgası ilgili denetim izine kaydedilir.
Yakala
Talebin genel durumunun 'onaylandı' olarak değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Reddedildi
|
Talep, onay sürecinde kesin olarak reddedilmiştir ve bir satın alma siparişine dönüştürülmeyecektir. Bu, talep başlığının genel durumunun 'reddedildi' olarak değişmesinden çıkarılır. | ||
|
Neden önemli
Bu faaliyet, süreçteki nihai bir hatayı temsil eder. Bu event'leri analiz etmek, 'Talep Reddetme Oranı'nı iyileştirmek ve politika ihlalleri veya bütçe sorunları gibi temel nedenleri belirlemek için anahtardır.
Nereden alınır
'requisition_headers' tablosundaki 'status' alanı 'rejected' olarak güncellendiğinde bir durum değişikliğinden çıkarılır. Zaman damgası ilgili denetim izine kaydedilir.
Yakala
Talebin genel durumunun 'reddedildi' olarak değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Onay Adımı Başlatıldı
|
Bir onay görevi belirli bir onaylayana veya onay grubuna atanır ve talep şimdi onların eylemini beklemektedir. Bu durum, taleple ilişkili bir onay kaydının 'beklemede' durumuyla oluşturulduğunda çıkarılır. | ||
|
Neden önemli
Bu, belirli bir onay için bekleme süresinin başlangıcını işaretler. Bunun ile ilgili 'Onay Adımı Onaylandı/Reddedildi' arasındaki süreyi ölçmek, onay zincirindeki belirli bottleneck'leri belirlemeye yardımcı olur.
Nereden alınır
Onaylayanın eylem durumunun 'beklemede' veya eşdeğeri olduğu, taleple bağlantılı 'approvals' tablosunda bir kaydın oluşturulma zaman damgasından çıkarılır.
Yakala
Onay zincirinde bir kişinin onay bekleyen kaydının oluşturulma timestamp'ini kullanın.
Event tipi
inferred
|
|||
|
Onay Adımı Onaylandı
|
İş akışındaki bireysel bir onaylayan, talep için onayını verir. Bu, sistem tarafından belirli bir zaman damgası ve kullanıcı bilgisiyle kaydedilen açık bir eylemdir. | ||
|
Neden önemli
Bu faaliyet, onay süreç akışına ayrıntılı içgörü sağlar. Bu adımları birleştirmek, 'Onay Adımı Başına Ortalama Bekleme Süresi'ni hesaplamaya ve onaylayıcı performansını analiz etmeye yardımcı olur.
Nereden alınır
Belirli talep ve onaylayana bağlı olarak, 'approvals' tablosunda veya denetim izinde kaydedilen açık bir 'onayla' eyleminden yakalanır.
Yakala
Talebin onay geçmişindeki 'onaylama' olaylarını filtreleyin.
Event tipi
explicit
|
|||
|
Onay Adımı Reddedildi
|
Bireysel bir onaylayan, iş akışındaki kendi aşamasında talebi reddeder ve genellikle düzeltme için talep edene geri gönderir. Bu, Coupa tarafından kaydedilen açık bir eylemdir. | ||
|
Neden önemli
Herhangi bir adımdaki reddetmeler, yeniden işleme neden olur ve döngü sürelerini uzatır. Reddetmelerin nerede ve neden meydana geldiğini analiz etmek, süreç iyileştirme ve kullanıcı eğitimi için çok önemlidir.
Nereden alınır
Belirli talep ve onaylayana bağlı olarak, 'approvals' tablosunda veya denetim izinde kaydedilen açık bir 'reddet' eyleminden yakalanır.
Yakala
Talebin onay geçmişindeki 'reddetme' olaylarını filtreleyin.
Event tipi
explicit
|
|||
|
Talep Değiştirildi
|
Talep, gönderildikten sonra talep sahibi veya başka bir yetkili kullanıcı tarafından düzenlenir. Coupa bunu açıkça yeni bir sürüm veya denetim girişi olarak kaydeder, genellikle onay workflow'unun bir kısmını veya tamamını sıfırlar. | ||
|
Neden önemli
Değişiklikleri takip etmek, süreçteki yeniden işleme ve verimsizliği anlamanın anahtarıdır. Yüksek hacimli değişiklikler, belirsiz başlangıç gereksinimlerini veya karmaşık satın alma politikalarını gösterebilir; bu da 'Talep Değişiklik Oranı' KPI'sını etkiler.
Nereden alınır
Bu, 'requisition_headers' tablosuyla ilişkili denetim izi tablolarından yakalanır; bu tablolar sürüm değişikliklerini veya belirli 'düzenleme' eylemlerini kaydeder.
Yakala
Talep gönderildikten sonra geçmiş kaydında açıkça 'düzenleme' veya 'güncelleme' olaylarını arayın.
Event tipi
explicit
|
|||
|
Talep Geri Çekildi
|
Orijinal talep sahibi, talep nihai onayı almadan önce iptal eder. Bu, o talep için süreci sonlandıran, kullanıcı odaklı, açık bir eylemdir. | ||
|
Neden önemli
Geri çekmeler, değişen iş ihtiyaçlarını, yinelenen talepleri veya kullanıcıların süreci atladığını gösterebilir. Bunu takip etmek, talep sinyali oynaklığını ve potansiyel süreç uyum sorunlarını anlamaya yardımcı olur.
Nereden alınır
Denetim izinde kaydedilen açık bir kullanıcı eylemine dayanarak, 'requisition_headers' tablosundaki bir durum değişikliğinden 'geri çekildi' veya benzer bir duruma çıkarılır.
Yakala
Talebin durumunun 'geri çekildi' olarak değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Kaynaklandı
|
Onaylanan talep, hemen bir satın alma siparişine dönüştürülmek yerine, bir RFQ veya açık artırma gibi bir kaynak bulma event'ine gönderilir. Bu event, talep bir kaynak bulma event nesnesine bağlandığında çıkarılır. | ||
|
Neden önemli
Bu faaliyet, satın alma sürecinde önemli bir alternatif yolu ortaya çıkarır. Basit satın almaları daha karmaşık, stratejik kaynak bulma faaliyetlerinden ayırarak daha incelikli döngü süresi analizine olanak tanır.
Nereden alınır
Durumun 'tedarik' olarak değiştiğini veya 'requisition_lines' tablosu ile bir tedarik etkinliği tablosu arasında bir bağlantı oluşturulduğunu tespit ederek çıkarılır.
Yakala
Durumun 'tedarik' olarak değişip değişmediğini veya bir tedarik etkinliği kimliğine bağlantı oluşturulup oluşturulmadığını kontrol edin.
Event tipi
inferred
|
|||