Satın Almadan Ödemeye - Talep veri Templateiniz
Satın Almadan Ödemeye - Talep veri Templateiniz
- Ayrıntılı analiz için önerilen öznitelikler
- İzlenecek temel süreç etkinlikleri
- Veri çıkarma için uygulamalı yönergeler
Satın Almadan Ödemeye - Talep öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik adı
ActivityName
|
Talep için belirli bir zamanda gerçekleşen iş etkinliğinin veya olayın adı. | ||
|
Açıklama
Bu öznitelik, satın alma talebinin yaşam döngüsündeki farklı adımları kaydeder. Örnekler arasında 'Talep oluşturuldu', 'Onay adımı onaylandı' ve 'Talep kaynak bulma sürecine alındı' yer alır. Her etkinlik, talep üzerinde gerçekleştirilen belirli bir aşamayı veya işlemi temsil eder. Bu etkinliklerin sırasını ve sıklığını analiz etmek Process Mining için temel önemdedir. Süreç haritalarını görselleştirmeyi, yaygın yolları belirlemeyi ve standart prosedürden sapmaları saptamayı sağlar.
Neden önemli?
Süreç haritasındaki adımları tanımlar; böylece taleplerin akışını görselleştirebilir ve analiz edebilirsiniz.
Nereden alınır?
Bu bilgi genellikle Coupa sistemindeki olay günlüklerinden, durum değişikliği kayıtlarından veya denetim izlerinden elde edilir. Durum alanlarının ya da işlem kodlarının eşleştirilmesi gerekebilir.
Örnekler
Talep oluşturulduTalep gönderildiOnay aşaması onaylandıTalep reddedildiSatın alma siparişi oluşturuldu
|
|||
|
Olay zamanı
EventTime
|
Etkinliğin gerçekleştiği kesin tarih ve saat. | ||
|
Açıklama
Olay zamanı, yani zaman damgası, satın alma talebiyle ilgili bir etkinliğin kaydedildiği kesin anı gösterir. Süreç akışını oluşturmak için olayları kronolojik sıraya koymada bu veri kullanılır. Çevrim sürelerini hesaplamak, etkinlikler arasındaki süreleri ölçerek darboğazları belirlemek ve sürecin farklı dönemlerdeki performansını anlamak gibi zamana dayalı tüm analizlerin temelini oluşturur. Anlamlı süreç analizleri için zaman damgalarının doğru ve ayrıntılı olması gerekir.
Neden önemli?
Olayları doğru sıraya koymak ve çevrim süreleri ile darboğazlar gibi süreye dayalı tüm metrikleri hesaplamak için bu zaman damgası gereklidir.
Nereden alınır?
Bu bilgi, Coupa’daki her talebin denetim izinde veya geçmiş kayıtlarında, genellikle her işlem için 'created_at' ya da 'updated_at' alanında tutulur.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
|
|||
|
Satın alma talebi kimliği
PurchaseRequisitionId
|
Her satın alma talebinin benzersiz tanımlayıcısıdır ve süreçteki temel vaka kimliği olarak kullanılır. | ||
|
Açıklama
Satın alma talebi kimliği, tek bir mal veya hizmet talebiyle ilgili tüm etkinlikleri birbirine bağlayan temel anahtardır. Her talep oluşturulduğunda kendisine benzersiz bir kimlik atanır ve bu kimlik yaşam döngüsü boyunca değişmez. Böylece talep oluşturulup gönderildiği andan tüm onay veya ret adımlarına, kaynak bulma sürecine ve kapanışına kadar uçtan uca izlenebilir. Process Mining çalışmalarında her olay günlüğü kaydı bu kimliğe bağlanır; böylece her vakanın tüm yolculuğu yeniden oluşturulabilir.
Neden önemli?
Bu temel Vaka kimliği, tüm süreç adımlarını birbirine bağlayarak talebin başlangıçtan sona kadar tüm yaşam döngüsünün analiz edilmesini sağlar.
Nereden alınır?
Bu birincil anahtar alanı, Coupa’nın Requisitions modülünde ve ilgili veri dışa aktarımlarında bulunur.
Örnekler
PR-102934PR-102935PR-102936
|
|||
|
Kaynak sistem
SourceSystem
|
Verinin hangi kaynak sistemden alındığını belirtir. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin geldiği kayıt sistemini belirtir. Bu analizde değer her zaman 'Coupa' olacaktır. Özellikle verilerin birden fazla sistemden birleştirilebildiği ortamlarda bu alanın eklenmesi iyi bir uygulamadır. Veri kökeni hakkında gerekli bağlamı sağlar ve veri yönetişimi ile kalite kurallarının yönetilmesine yardımcı olur.
Neden önemli?
Veri kökenini açıkça gösterir. Bu, veri yönetişimi ve birden fazla kurumsal sistemden gelen verileri birleştirme açısından önemlidir.
Nereden alınır?
Bu, genellikle Veri Seti kaynağını belirtmek için veri çıkarma ve dönüştürme sırasında eklenen sabit bir değerdir.
Örnekler
Coupa
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verinin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, Coupa’dan en son veri çıkarımının tarih ve saatini kaydeder. Analiz edilen verilerin ne kadar güncel olduğunu gösterir. Kullanıcıların içgörülerin mevcut operasyonel durumu mu yoksa daha önceki bir dönemi mi yansıttığını anlaması için verinin güncelliğini bilmek önemlidir. Bu, devam eden operasyonları izleyen Dashboardlar için özellikle önem taşır.
Neden önemli?
Verinin güncelliğini bildirerek kullanıcıların analiz dönemini anlamasına ve güncel bilgilere dayanarak karar vermesine yardımcı olur.
Nereden alınır?
Bu zaman damgası, başarılı bir veri çıkarma işleminin sonunda veri hattı veya ETL aracı tarafından oluşturulup eklenir.
Örnekler
2024-05-21T02:00:00Z
|
|||
|
Departman
Department
|
Talebin gider olarak kaydedildiği iş departmanı veya maliyet merkezi. | ||
|
Açıklama
Departman özniteliği, her talebi belirli bir kuruluş birimine veya maliyet merkezine bağlar. Karşılaştırmalı analiz için önemli bir boyuttur. Dashboardlar ve KPI’lar departmana göre filtrelenip ayrıştırılabilir; böylece yöneticiler kuruluşun farklı bölümlerindeki onay çevrim sürelerini, ret oranlarını ve uyumluluğu karşılaştırabilir. Bu da departmana özgü sorunları veya iyi uygulamaları belirlemeye yardımcı olur.
Neden önemli?
Çevrim süresi ve ret oranı gibi süreç KPI’larını farklı iş birimleri arasında karşılaştırmayı sağlayarak iyileştirme alanlarını ortaya çıkarır.
Nereden alınır?
Coupa’daki Requisition nesnesinde standart bir alandır; genellikle talep sahibinin kullanıcı profiliyle ilişkilendirilir veya talep kalemlerinde belirtilir.
Örnekler
PazarlamaBT operasyonlarıTesis yönetimiAraştırma ve geliştirme
|
|||
|
Onaylayıcı
Approver
|
Onay etkinliğinden sorumlu kullanıcı veya grup. | ||
|
Açıklama
Bu öznitelik, bir onay adımına atanan kişiyi veya onay grubunu belirtir. 'Onay adımı başlatıldı', 'Onay adımı onaylandı' ve 'Onay adımı reddedildi' gibi etkinliklerde doldurulur. Onaylayıcıya göre analiz, 'Onaylayıcı performansı ve iş yükü' Dashboardunu oluşturmanın temelidir. Bireysel onay sürelerini ölçmeye, belirli onaylayıcıların neden olduğu darboğazları belirlemeye ve iş yükü dağılımını değerlendirmeye yardımcı olur.
Neden önemli?
Onaylayıcı performansını ve iş yükü dağılımını analiz etmek, ayrıca belirli kişilerle veya onay gruplarıyla ilişkili darboğazları belirlemek için önemlidir.
Nereden alınır?
Bu bilgi, Coupa’da her taleple ilişkili onay zinciri ayrıntılarında bulunur. User verileriyle birleştirme gerekebilir.
Örnekler
David MillerFinans onaylayıcıları L2Susan Chen
|
|||
|
Talep durumu
RequisitionStatus
|
Satın alma talebinin mevcut veya nihai durumu. | ||
|
Açıklama
Bu öznitelik, veri çıkarımı sırasındaki genel talep durumunu veya talebin nihai sonucunu gösterir. Yaygın durumlar arasında 'Onay bekleniyor', 'Onaylandı', 'Reddedildi', 'Geri çekildi' ve 'Kapalı' bulunur. Filtreleme ve analiz için temel bir boyuttur. Onay ve ret oranlarını hesaplamak, açık taleplerin mevcut iş yükünü izlemek ve taleplerin nihai sonucunu 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 gereklidir.
Nereden alınır?
Coupa’daki Purchase Requisition nesnesinde bulunan standart bir alandır; genellikle 'status' veya 'state' olarak adlandırılır.
Örnekler
Onay bekleniyorOnaylandıReddedildiGeri çekildiKapalı
|
|||
|
Talep sahibi
Requester
|
Satın alma talebini oluşturan ve gönderen çalışan. | ||
|
Açıklama
Bu öznitelik, talebi başlatan kişiyi belirtir. Talep sahibine göre yapılan analizler, sık değişiklik yapılması veya taleplerin sık reddedilmesi gibi belirli kullanıcılarla ilişkili örüntüleri ortaya çıkarabilir. Bu durum ek eğitim ihtiyacına işaret edebilir. Öznitelik ayrıca farklı kullanıcıların veya kullanıcı gruplarının talep hacimlerini ve süreç davranışlarını analiz etmek için kullanılır.
Neden önemli?
Süreç davranışını kullanıcıya göre analiz etmeyi sağlar; eğitim ihtiyaçlarını belirlemeye ve farklı kişilerin süreçle nasıl etkileşim kurduğunu anlamaya yardımcı olur.
Nereden alınır?
Coupa’daki Requisition nesnesinde standart bir alan olarak bulunur; genellikle User nesnesine bağlıdır ve 'requester' ya da 'created_by' olarak adlandırılır.
Örnekler
Alice JohnsonBob SmithCharlie 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 gösterir. Tutar, onay iş akışının karmaşıklığını etkileyebildiği için süreç analizinde önemli bir etkendir; yüksek tutarlı talepler genellikle daha fazla onay adımı gerektirir. Süreç metriklerini tutar aralıklarına göre (ör. <$1000, $1000-$10000) analiz etmek, farklı mali büyüklükteki taleplerin nasıl ele alındığını gösterebilir.
Neden önemli?
Yüksek tutarlar genellikle daha karmaşık onay iş akışlarını tetiklediğinden, farklı tutarlardaki talepler için sürecin nasıl değiştiğini analiz etmeye yardımcı olur.
Nereden alınır?
Coupa’daki Requisition nesnesinin başlığında bulunan standart bir alandır; genellikle 'total' veya 'total_amount' olarak adlandırılır.
Örnekler
500.0012550.7599.99
|
|||
|
Aciliyet düzeyi
UrgencyLevel
|
Talebin aciliyetini 'Yüksek', 'Orta' veya 'Düşük' olarak sınıflandıran değer. | ||
|
Açıklama
Genellikle bir öncelik alanıyla eşleştirilen aciliyet düzeyi, talep sahiplerinin hızla işleme alınması gereken talepleri belirtmesini sağlar. Bu öznitelik, 'Acil taleplerin işlem süresi' Dashboardu için gereklidir. Kuruluşlar, aciliyeti yüksek taleplerin çevrim sürelerini standart taleplerle karşılaştırarak önceliklendirme yöntemlerinin işe yarayıp yaramadığını ve acil iş ihtiyaçlarının zamanında karşılanıp karşılanmadığını değerlendirebilir.
Neden önemli?
Acil taleplerin standart taleplerden daha hızlı işlenip işlenmediğini analiz ederek önceliklendirme politikalarının ne kadar etkili olduğunu değerlendirmeyi sağlar.
Nereden alınır?
Bu, Coupa’daki Requisition nesnesinde standart veya özel bir alan olabilir. Coupa belgelerine ya da sistem yapılandırmasına başvurun.
Örnekler
YüksekOrtaDüşük
|
|||
|
Değişiklik yapıldı mı
IsAmended
|
İlk gönderimden sonra talepte bir veya daha fazla değişiklik yapıldıysa doğru olan mantıksal değer. | ||
|
Açıklama
Bu hesaplanan öznitelik, belirli bir vakada 'Talepte değişiklik yapıldı' etkinliğinin gerçekleşip gerçekleşmediğini gösteren basit bir işarettir (True/False). Değişiklik gereken talepleri kolayca ayırmayı sağlayarak analiz ve filtreleme işlemlerini kolaylaştırır. Talep değişiklik oranı KPI’ını hesaplamak ve 'Talep değişikliği hacmi' Dashboardunu oluşturmak için kullanılır. Böylece yeniden çalışmanın temel nedenleri belirlenebilir ve ilk seferde doğru sonuç alma oranı iyileştirilebilir.
Neden önemli?
Değişiklik oranı KPI’ının hesaplanmasını kolaylaştırır ve yeniden çalışma gerektiren vakaların diğerlerinden kolayca ayrılmasını sağlar.
Nereden alınır?
Bu değer, her vaka için olay günlüğünde 'Talepte değişiklik yapıldı' etkinliğinin bulunup bulunmadığı kontrol edilerek Process Mining aracında 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 birbirinden farklı 'Onay adımı onaylandı' etkinliklerinin sayısını verir. Her vakanın onay iş akışının ne kadar karmaşık olduğunu ölçmenize yardımcı olur. 'Ortalama onay adımı sayısı' KPI’ının temelini oluşturur. Ayrıca, alışılmadık derecede uzun veya karmaşık onay yollarını izleyen talepleri belirleyerek iş akışını sadeleştirme ihtiyacını ortaya çıkarır.
Neden önemli?
Her talebin onay iş akışındaki karmaşıklığı ölçer ve sadeleştirilmesi gereken gereğinden karmaşık yolları belirlemenize yardımcı olur.
Nereden alınır?
Bu metrik, Process Mining aracında her Vaka kimliği için 'Onay adımı onaylandı' etkinliğinin kaç kez gerçekleştiği sayılarak hesaplanır.
Örnekler
253
|
|||
|
Onay adımının 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ı' etkinliği ile buna karşılık gelen 'Onay adımı onaylandı' veya 'Onay adımı reddedildi' etkinliği arasındaki süreyi ölçer. Onay zincirinin her aşamasındaki bekleme süresini ayrı ayrı gösterir. 'Kritik onay adımı darboğazları' Dashboardu için önemlidir; çünkü genel süreçte en uzun gecikmelere hangi onaylayıcıların veya onay aşamalarının yol açtığını tam olarak belirler.
Neden önemli?
Toplam çevrim süresine bakmak yerine her adımda beklenen süreyi ölçerek onay iş akışındaki darboğazları belirler.
Nereden alınır?
Process Mining aracında, 'Onay adımı başladı' ile bunu izleyen son onay olayı (Onaylandı/Reddedildi) arasındaki süre farkı hesaplanarak bulunur.
Örnekler
1,2 gün4 saat3,8 gün
|
|||
|
Onay iş akışı yolu
ApprovalWorkflowPath
|
Talebe uygulanan belirli onay zincirini veya iş akışı şablonunu tanımlayan değer. | ||
|
Açıklama
Bu öznitelik, talebin izlemesi gereken önceden tanımlanmış onaylayıcı sırasını belirtir. Bu sıra, genellikle tutar, departman ve talep türü gibi etkenlere dayanan iş kurallarıyla belirlenir. Bu öznitelik, 'Talep politikalarına uyumluluk' Dashboardunun temelini oluşturur. Gerçek onaylayıcı sırası atanan iş akışı yoluyla karşılaştırılarak sapmalar saptanabilir, uyum oranları ölçülebilir ve yönetilmeyen istisnalar belirlenebilir.
Neden önemli?
Beklenen ve gerçekleşen onay adımlarını karşılaştırarak uyumluluk analizini sağlar ve süreç sapmalarını ortaya çıkarır.
Nereden alınır?
Coupa belgelerine başvurun. Bu değer, talep için tetiklenen onay zincirinin veya iş akışı kuralının adından elde edilebilir.
Örnekler
Standart onay <$5kBT donanımı onayı >$10kSermaye gideri CFO incelemesi
|
|||
|
Para birimi
Currency
|
Talebin toplam tutarının para birimi kodu. | ||
|
Açıklama
Bu öznitelik, talebin toplam tutarının hangi para birimiyle (ör. USD, EUR, GBP) ifade edildiğini belirtir. Özellikle birden fazla para birimiyle çalışan çok uluslu kuruluşlarda, finansal analiz için gerekli bağlamı sağlar. Parasal değerlerin doğru yorumlanmasına, finansal raporlarda ve Dashboardlarda uygun biçimde dönüştürülüp birleştirilmesine yardımcı olur.
Neden önemli?
'Toplam tutar' özniteliği için gerekli bağlamı sağlayarak birden fazla para biriminin kullanıldığı ortamlarda finansal analizin doğru yapılmasına yardımcı olur.
Nereden alınır?
Coupa’daki Requisition nesnesinde bulunan standart bir alandır; genellikle 'currency_code' veya benzer bir ad taşır.
Örnekler
USDEURGBP
|
|||
|
Ret nedeni
RejectionReason
|
Bir talep veya onay adımı reddedildiğinde onaylayıcının belirttiği neden. | ||
|
Açıklama
Onaylayıcı bir talebi reddettiğinde genellikle kararının nedenini belirtir. Bu öznitelik, söz konusu açıklamayı metin olarak kaydeder. Ret nedenlerini analiz etmek, taleplerin neden başarısız olduğuna ilişkin doğrudan ve niteliksel bilgi sağlar. Bu bilgi, yanlış kodlama, bütçe yetersizliği veya gerekçenin yeterince açıklanmaması gibi yaygın sorunların temel nedenlerini belirlemeye yardımcı olur. Ardından bu sorunlar eğitim veya süreç iyileştirmeleriyle ele alınabilir.
Neden önemli?
Süreçteki başarısızlıkların temel nedenlerini doğrudan göstererek kullanıcı eğitimi veya süreç açıklamalarının iyileştirilmesi gereken alanları belirlemeye yardımcı olur.
Nereden alınır?
Bu bilgi genellikle talebin onay geçmişinde 'Reddedildi' durum değişikliğiyle ilişkili yorum veya not alanında tutulur.
Örnekler
Yanlış maliyet merkeziBu çeyreğin bütçesi aşılıyorYinelenen talepYeterli gerekçe sunulmadı
|
|||
|
Satın alma siparişi kimliği
PurchaseOrderId
|
Onaylanan talepten oluşturulan satın alma siparişinin kimliği. | ||
|
Açıklama
Talep tüm onayları alıp kaynak bulma sürecini tamamladığında genellikle bir satın alma siparişi oluşturulur. Bu öznitelik, oluşan PO’nun kimliğini saklar. Önceki Talep süreci ile sonraki Satın Alma Siparişi süreci arasında önemli bir bağlantı kurar. 'Talep onayından PO oluşturulmasına kadar geçen süre' KPI’ının hesaplanmasını ve Satın Almadan Ödemeye döngüsünün tamamının uçtan uca analiz edilmesini sağlar.
Neden önemli?
Talebi sonraki satın alma siparişine bağlayarak devir teslim süresinin analiz edilmesini ve Satın Almadan Ödemeye sürecinin daha geniş kapsamlı, uçtan uca görünümünü sağlar.
Nereden alınır?
Bu, Coupa’daki Requisition nesnesinde bulunan ve PO oluşturulduktan sonra doldurulan standart bir alandır.
Örnekler
PO-45000123PO-45000124PO-45000125
|
|||
|
Talep türü
RequisitionType
|
Talebin 'Sermaye gideri', 'Operasyonel gider' veya 'Yazılım' gibi kategorisi ya da türü. | ||
|
Açıklama
Talep türü, talepleri iş amaçlarına veya satın alınacak ürünün niteliğine göre sınıflandırır. Bu öznitelik, uyumluluk analizinde ve farklı talep türlerinin süreçte nasıl ilerlediğini anlamada fayda sağlar. Örneğin, sermaye harcaması talepleri standart operasyonel taleplere kıyasla daha sıkı ve uzun bir onay sürecinden geçebilir. Süreci talep türüne göre analiz etmek, süreç iyileştirmeye yönelik değerli içgörüler sağlayabilir.
Neden önemli?
Farklı talep türlerinin süreç akışları ve politikaları değişebileceğinden, analizi talebin iş amacına göre ayrıştırmayı sağlar.
Nereden alınır?
Bu, Coupa’daki Requisition nesnesinde bulunan standart veya özel bir sınıflandırma alanı olabilir.
Örnekler
Sermaye gideriOperasyonel giderBT donanımıProfesyonel hizmetler
|
|||
|
Tedarikçi adı
SupplierName
|
Talep için seçilen tedarikçinin adı. | ||
|
Açıklama
Bu öznitelik, talep edilen mal veya hizmetler için düşünülen tedarikçiyi belirtir. Tedarikçiyi talep sahibi seçebilir veya tedarikçi kaynak bulma sürecinde eklenebilir. Süreç metriklerini tedarikçiye göre analiz etmek, tedarikçi performansını değerlendirmeye ve belirli tedarikçilerle çalışmanın çevrim sürelerini uzatıp uzatmadığını ya da başka verimsizliklere yol açıp açmadığını belirlemeye yardımcı olur. Ayrıca satın alma stratejisi ve tedarikçi ilişkilerinin yönetimi için önemli bir bağlam sağlar.
Neden önemli?
Seçilen tedarikçiye göre süreç performansını analiz etmeyi sağlar; bu analiz kaynak bulma stratejilerine ve tedarikçi yönetimine yön verebilir.
Nereden alınır?
Bu bilgi, Coupa’daki Requisition Line nesnesinde genellikle 'supplier' veya 'vendor' alanında bulunur.
Örnekler
StaplesDell TechnologiesAccentureCDW
|
|||
|
Ürün veya hizmet kategorisi
Commodity
|
Talep edilen mal veya hizmetlerin üst düzey kategorisi. | ||
|
Açıklama
Ürün veya hizmet kategorisi özniteliği, talepteki kalemleri 'Ofis malzemeleri', 'Bilgisayar donanımı' veya 'Pazarlama hizmetleri' gibi standart kategorilere ayırır. Böylece satın alma örüntüleri ve süreç farklılıkları, satın alınan ürünlere göre analiz edilebilir. Bazı kategoriler özel onay gerekliliklerine veya kaynak bulma stratejilerine tabi olabilir. Süreci kategoriye göre analiz etmek, farklı harcama grupları için satın alma süreçlerini iyileştirmeye yardımcı olur.
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 genellikle talep kalemi düzeyinde bulunan standart bir alandır. Başlık düzeyinde birleştirilmesi gerekebilir.
Örnekler
Ofis malzemeleriBilgisayar donanımıPazarlama hizmetleriSeyahat
|
|||
Satın Almadan Ödemeye - Talep etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Satın alma siparişi oluşturuldu
|
Onaylanan talepteki bilgilere dayanarak bir satın alma siparişi (PO) oluşturulur. Kaynak talep kimliğine referans veren bir PO kaydı oluşturulduğunda bu olay çıkarılır. | ||
|
Neden önemli?
Bu, talep sürecinin temel başarı sonucudur ve Satın Almadan Ödemeye sürecinin sonraki aşamasına devir teslimi gösterir. 'Talep onaylandı' etkinliğinden bu olaya kadar geçen süreyi analiz etmek, uygulamadaki gecikmeleri ortaya çıkarır.
Nereden alınır?
'purchase_orders' tablosunda, kaynak 'requisition_headers' veya 'requisition_lines' kimliğine referans veren bir kayıt oluşturulmasından çıkarım yapılır.
Kaydedin
Talep kimliğine bağlı PO kaydının 'created-at' zaman damgasını kullanın.
Olay türü
inferred
|
|||
|
Talep gönderildi
|
Talepte bulunan, tamamladığı talebi onay iş akışına gönderir. Bu olay, sistemin denetim günlüklerinde veya geçmiş tablolarında talep durumunun 'draft' değerinden 'pending_approval' değerine değişmesiyle belirlenir. | ||
|
Neden önemli?
Talebin gönderilmesi onay sürecini başlatır ve 'Ortalama Talep Onay Çevrim Süresi' temel performans göstergesini ölçmek için önemli bir kilometre taşı oluşturur. Bu noktadan önceki gecikmeler kullanıcıyla, sonraki gecikmeler ise süreçle ilgilidir.
Nereden alınır?
'requisition_headers' tablosundaki durum değişikliğinden, özellikle 'status' alanının 'pending_approval' değerine geçmesinden belirlenir. Bu değişikliğin zaman damgası ilgili denetim kaydında bulunur.
Kaydedin
Talep durumunun ilk kez 'pending_approval' değerine geçtiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep kapatıldı
|
Talep resmen kapatılır ve artık üzerinde işlem yapılmayacağı belirtilir. Bu, PO oluşturulup karşılandıktan sonra veya onaylanan talep sipariş verilmeden önce iptal edildiğinde gerçekleşebilir. | ||
|
Neden önemli?
Bu etkinlik, talebin yaşam döngüsü için kesin bir bitiş noktası oluşturur. Vakaların net biçimde sonuçlanmasını sağlayarak süreç analizinde süresiz olarak 'etkin' görünmelerini önler.
Nereden alınır?
'requisition_headers' tablosundaki 'status' alanı 'closed' olarak güncellendiğinde durum değişikliğinden çıkarım yapılır. Zaman damgası, ilgili denetim izine kaydedilir.
Kaydedin
Talebin genel durumunun 'closed' olarak değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep oluşturuldu
|
Bir kullanıcı yeni bir satın alma talebi oluşturur ve taslak olarak kaydeder. Bu, her talep vakasının başlangıç noktasıdır ve genellikle talep kaydının oluşturulma zaman damgasından belirlenir. | ||
|
Neden önemli?
Bu etkinlik, talep sürecinin başlangıcını gösterir. Oluşturma ile gönderim arasındaki süreyi analiz etmek, kullanıcıların kararsızlığından veya sistemin karmaşıklığından kaynaklanan gecikmeleri ortaya çıkarabilir.
Nereden alınır?
Bu olay, belirli bir Satın Alma Talebi kimliği için 'requisition_headers' tablosundaki 'created-at' zaman damgasından alınır.
Kaydedin
Talep başlık kaydının oluşturulma zaman damgasını kullanın.
Olay türü
inferred
|
|||
|
Talep onaylandı
|
Talep, onay iş akışındaki gerekli tüm adımları başarıyla tamamlamıştır. Bu durum, talep başlığının genel durumunun 'approved' olarak değişmesinden çıkarılır. | ||
|
Neden önemli?
Bu, onay döngüsünün tamamlandığını gösteren önemli bir başarı aşamasıdır. Bu etkinliğe ulaşma süresi temel KPI’lardan biridir ve sonraki satın alma işlemlerini başlatır.
Nereden alınır?
'requisition_headers' tablosundaki 'status' alanı 'approved' olarak güncellendiğinde durum değişikliğinden çıkarım yapılır. Zaman damgası, ilgili denetim izine kaydedilir.
Kaydedin
Talebin genel durumunun 'approved' olarak değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep reddedildi
|
Talep, onay sürecinde kesin olarak reddedilir ve satın alma siparişine dönüştürülmez. Bu durum, talep başlığının genel durumunun 'rejected' olarak değişmesinden çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, sürecin başarısızlıkla sona erdiğini gösterir. Bu olayları analiz etmek, 'Talep ret oranını' iyileştirmek ve politika ihlalleri ya da bütçe sorunları gibi temel nedenleri belirlemek için önemlidir.
Nereden alınır?
'requisition_headers' tablosundaki 'status' alanı 'rejected' olarak güncellendiğinde durum değişikliğinden çıkarım yapılır. Zaman damgası, ilgili denetim izine kaydedilir.
Kaydedin
Talebin genel durumunun 'rejected' olarak değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Onay adımı reddedildi
|
Onaylayıcı, iş akışındaki kendi aşamasında talebi reddeder. Talep genellikle değişiklik yapılması için talep sahibine geri gönderilir. Coupa bu açık işlemi kaydeder. | ||
|
Neden önemli?
Herhangi bir adımdaki ret, yeniden çalışmaya yol açar ve çevrim sürelerini uzatır. Retlerin nerede ve neden gerçekleştiğini analiz etmek, süreci iyileştirmek ve kullanıcıları eğitmek açısından önemlidir.
Nereden alınır?
'approvals' tablosunda veya denetim izinde kaydedilen açık bir 'reject' işleminden alınır ve ilgili talep ile onaylayıcıya bağlanır.
Kaydedin
Talebin onay geçmişinde 'reject' olaylarını filtreleyin.
Olay türü
explicit
|
|||
|
Onay aşaması başladı
|
Bir onay görevi belirli bir onay verene veya onay grubuna atanır ve talep artık işlem yapılmasını bekler. Talep ile ilişkili bir onay kaydı 'pending' durumuyla oluşturulduğunda bu etkinlik belirlenir. | ||
|
Neden önemli?
Bu, belirli bir onay için bekleme süresinin başlangıcını gösterir. Bu süreyle ilgili 'Onay aşaması onaylandı/reddedildi' etkinliği arasındaki zamanı ölçmek, onay zincirindeki belirli darboğazları belirlemeye yardımcı olur.
Nereden alınır?
Talebe bağlı 'approvals' tablosundaki bir kaydın oluşturulma zaman damgasından belirlenir. Bu kayıtta onay verenin işlem durumu 'pending' veya eşdeğer bir değerdir.
Kaydedin
Onay zincirindeki bir kişiye ait bekleyen onay kaydının oluşturulma zaman damgasını kullanın.
Olay türü
inferred
|
|||
|
Onay aşaması onaylandı
|
İş akışındaki bir onaylayıcı, talebi kendi aşamasında onaylar. Sistem bu açık işlemi belirli bir zaman damgası ve kullanıcı bilgileriyle kaydeder. | ||
|
Neden önemli?
Bu etkinlik, onay akışının her adımına ilişkin ayrıntılı bilgi sağlar. Bu adımları bir arada değerlendirerek 'Onay adımı başına ortalama bekleme süresi' hesaplanabilir ve onaylayıcıların performansı analiz edilebilir.
Nereden alınır?
'approvals' tablosunda veya denetim izinde kaydedilen açık bir 'approve' işleminden alınır ve ilgili talep ile onaylayıcıya bağlanır.
Kaydedin
Talebin onay geçmişinde 'approve' olaylarını filtreleyin.
Olay türü
explicit
|
|||
|
Talep değiştirildi
|
Talep gönderildikten sonra talepte bulunan veya başka bir yetkili kullanıcı tarafından düzenlenir. Coupa bu işlemi yeni bir sürüm veya denetim kaydı olarak açıkça kaydeder; çoğu zaman onay iş akışının bir kısmı ya da tamamı yeniden başlatılır. | ||
|
Neden önemli?
Değişiklikleri izlemek, süreçteki yeniden çalışmayı ve verimsizlikleri anlamak açısından önemlidir. Çok sayıda değişiklik, ilk gereksinimlerin belirsiz veya satın alma politikalarının karmaşık olduğuna işaret edebilir ve 'Talep Değişiklik Oranı' temel performans göstergesini etkiler.
Nereden alınır?
Bu bilgi, sürüm değişikliklerini veya belirli 'edit' işlemlerini kaydeden 'requisition_headers' tablosuyla ilişkili denetim tablolarından alınır.
Kaydedin
Gönderimden sonra talebin geçmiş günlüğünde açıkça belirtilen 'edit' veya 'update' olaylarını arayın.
Olay türü
explicit
|
|||
|
Talep geri çekildi
|
Talebi oluşturan kişi, nihai onay verilmeden önce talebi iptal eder. Kullanıcının başlattığı bu açık işlem, ilgili talebin sürecini sonlandırır. | ||
|
Neden önemli?
Geri çekme işlemleri, iş ihtiyaçlarının değiştiğine, yinelenen taleplere veya kullanıcıların süreç dışına çıktığına işaret edebilir. Bunları izlemek, talep eğilimlerindeki değişkenliği ve sürece uyumla ilgili olası sorunları anlamaya yardımcı olur.
Nereden alınır?
Denetim izinde kaydedilen açık bir kullanıcı işlemi sonucunda 'requisition_headers' tablosundaki durumun 'withdrawn' veya benzer bir değere değiştiği belirlenerek çıkarım yapılır.
Kaydedin
Talep durumunun 'withdrawn' olarak değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep kaynak bulma sürecine alındı
|
Onaylanan talep, doğrudan satın alma siparişine dönüştürülmek yerine RFQ veya açık artırma gibi bir kaynak bulma etkinliğine gönderilir. Talebin bir kaynak bulma etkinliği nesnesine bağlanmasından bu olay çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, satın alma sürecindeki önemli bir alternatif yolu gösterir. Basit satın alımları daha karmaşık ve stratejik kaynak bulma çalışmalarından ayırarak çevrim sürelerinin daha ayrıntılı analiz edilmesini sağlar.
Nereden alınır?
'sourcing' durumuna geçiş saptanarak veya 'requisition_lines' tablosu ile bir kaynak bulma etkinliği tablosu arasında bağlantı oluşturulduğu belirlenerek çıkarım yapılır.
Kaydedin
Durumun 'sourcing' olarak değişip değişmediğini veya bir kaynak bulma etkinliği kimliğine bağlantı oluşturulup oluşturulmadığını kontrol edin.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Bu Template ile Coupa Satın Almadan Ödemeye talep sürecinizi bugün iyileştirmeye başlayın. Değerli içgörüler elde edin ve satın alma süreçlerinizin verimliliğini artırın.
Coupa P2P taleplerinizi iyileştirin, çevrim süresini bugün kısaltın
Verimsizlikleri belirleyin ve P2P talep çevrim sürenizi %30 azaltın.
Kredi kartı gerekmez. Dakikalar içinde iyileştirmeye başlayın.