Satın Almadan Ödemeye - Talep Veri Templateiniz
Satın Almadan Ödemeye - Talep Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Oracle Fusion Financials için veri çıkarma yönlendirmesi
Satın Almadan Ödemeye - Satın alma talebi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik
ActivityName
|
Talep sürecinin belirli bir noktasında gerçekleşen iş olayının adıdır. | ||
|
Açıklama
Etkinlik, satın alma talebinin yaşam döngüsündeki belirli bir adımı veya kilometre taşını ifade eder. 'Talep oluşturuldu', 'Onay adımı onaylandı' ve 'Satın alma siparişi oluşturuldu' buna örnektir. Bu etkinlikler, kaynak sistemin denetim günlüklerinde veya işlem tablolarında kaydedilen durum değişikliklerinden, kullanıcı işlemlerinden ya da sistem olaylarından türetilir. Bu öznitelik, talep akışını görsel olarak gösteren süreç haritasını oluşturmak için gereklidir. Etkinliklerin sırasını ve sıklığını analiz etmek; yaygın süreç yollarını, darboğazları, yeniden çalışma döngülerini ve standart prosedürden sapmaları belirlemeye yardımcı olur.
Neden önemli?
Süreç haritasının temelini oluşturur ve talep iş akışını görselleştirip analiz etmenizi sağlar.
Nereden alınır?
POR_REQUISITION_HEADERS_ALL gibi tablolardaki durum değişikliği kayıtlarından, işlem geçmişinden veya FA_FUSION_SOAINFRA.WFTASK gibi Workflow denetim izlerinden türetilir.
Örnekler
Talep oluşturulduOnay adımı onaylandıTalep reddedildiSatın alma siparişi oluşturuldu
|
|||
|
Olay zamanı
EventTime
|
Etkinliğin gerçekleştiği anı gösteren zaman damgasıdır. | ||
|
Açıklama
Olay zamanı, belirli bir etkinliğin gerçekleştiği kesin tarih ve saati kaydeder. Bu zaman damgası, bir vaka içindeki olayları kronolojik olarak sıralamak için temeldir ve sistemdeki oluşturma tarihleri, son güncelleme tarihleri veya belirli işlem zaman damgalarından alınır. Analizde Olay zamanı; etkinlikler arasındaki çevrim süreleri, bekleme süreleri ve toplam vaka süresi gibi süreye dayalı tüm metrikleri hesaplamak için kullanılır. Darboğazları belirlemek, SLA'lara göre performansı ölçmek ve talep sürecinin zamansal dinamiklerini anlamak açısından önemlidir.
Neden önemli?
Tüm zamanla ilgili KPI'ları hesaplamak, olayları doğru sıraya koymak ve süreç performansını ve darboğazları analiz etmek için gereklidir.
Nereden alınır?
Genellikle işlem veya durum değişikliğiyle ilişkili 'LAST_UPDATE_DATE' ya da 'CREATION_DATE' sütunundan alınır. Bu sütunlar çoğu zaman POR_REQUISITION_HEADERS_ALL veya Workflow geçmişi tablolarında bulunur.
Örnekler
2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
|
|||
|
Satın alma talebi kimliği
PurchaseRequisitionId
|
Satın alma talebinin benzersiz tanımlayıcısıdır ve süreçteki vaka kimliği olarak kullanılır. | ||
|
Açıklama
Satın alma talebi kimliği, belirli bir mal veya hizmet talebiyle ilgili tüm etkinlikleri birbirine bağlayan merkezi tanımlayıcıdır. Her talebe oluşturulduğunda benzersiz bir kimlik atanır ve bu kimlik yaşam döngüsü boyunca değişmez. Process Mining kapsamında bu öznitelik; oluşturma, gönderim, onay adımları ve nihai kapatma gibi ilgili tüm olayları tek bir vaka altında gruplamak için kullanılır. Böylece talebin uçtan uca yolculuğu analiz edilebilir, süreç haritaları görselleştirilebilir, çevrim süreleri hesaplanabilir ve her talep için varyantlar incelenebilir.
Neden önemli?
Talebin başlangıçtan sona yaşam döngüsünü izlemek için temel özniteliktir. Vaka düzeyindeki tüm analizleri ve KPI hesaplamalarını mümkün kılar.
Nereden alınır?
Bu değer genellikle talep başlığı tablosundaki birincil anahtardır. Oracle Fusion Financials içinde buna POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID örnek verilebilir.
Örnekler
100234810023491002350
|
|||
|
Kaynak sistem
SourceSystem
|
Bu verilerin çıkarıldığı bilgi sistemidir. | ||
|
Açıklama
Süreç verilerinin kaynağını tanımlar. Bu veri modeli için değer sürekli olarak 'Oracle Fusion Financials' olur. Birden fazla ERP veya entegre sistemin bulunduğu ortamlarda bu alan, veri soyunu izlemek, sorun gidermek ve veri kalitesini güvence altına almak için önemlidir. Analiz edilen süreç olayları için doğru kaynağın hangisi olduğunu anlamaya yardımcı olur.
Neden önemli?
Verilerin kaynağı hakkında gerekli bağlamı sağlar. Bu bilgi, veri yönetişimi ve birden fazla sistemden veri entegrasyonu sırasında önemlidir.
Nereden alınır?
Veri setinin kaynağını etiketlemek için veri çıkarma ve dönüştürme sürecinde eklenen statik bir değerdir.
Örnekler
Oracle Fusion Financials
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Kaynak sistemdeki en son veri yenilemesinin zaman damgasıdır. | ||
|
Açıklama
Verilerin Oracle Fusion Financials sisteminden en son çıkarıldığı tarih ve saati gösterir. Tek tek olaylar yerine veri setinin tamamı için geçerlidir. Analistler bu bilgiyi verilerin güncelliğini anlamak ve en son işlemlerin ne zaman dahil edildiğini doğrulamak için kullanır. Dashboard raporlaması ve analizlerin güncel bilgilere dayanmasını sağlamak için önemli bir üst veridir.
Neden önemli?
Verilerin ne kadar güncel olduğunu gösterir. Böylece analizlerin geçerli ve mevcut en son bilgilere dayalı olması sağlanır.
Nereden alınır?
Bu zaman damgası, veri çıkarma işlemi sırasında, genellikle ETL aracı veya veri hattı tarafından oluşturulur ve saklanır.
Örnekler
2023-10-27T02:00:00Z
|
|||
|
Departman
DepartmentName
|
Talep sahibinin bağlı olduğu iş departmanıdır. | ||
|
Açıklama
Bu öznitelik, talebi oluşturan kişinin Finance, IT veya Marketing gibi kurumsal birimini belirtir. Genellikle İK sistemindeki talep sahibinin kullanıcı profilinden alınır. Departmana göre analiz, süreç verilerini bölümlere ayırmanın yaygın ve etkili bir yoludur. Daha yüksek ret oranları veya daha uzun çevrim süreleri gibi departmana özgü davranışları belirlemenize yardımcı olur. Böylece hedefli süreç iyileştirme çalışmalarına yön verebilirsiniz. Bu, Requester Performance Metrics Dashboardı için önemli bir boyuttur.
Neden önemli?
Süreç analizinin iş birimine göre bölümlendirilmesini sağlar; departmana özgü örüntüleri, performansı ve uyumluluk sorunlarını ortaya çıkarır.
Nereden alınır?
Genellikle talep sahibinin profilinden türetilir. Bunun için talep tablosunun departman bilgilerini içeren bir İK veya kullanıcı dizini tablosuyla birleştirilmesi gerekebilir.
Örnekler
Bilgi TeknolojileriFinansOperasyonlarPazarlama
|
|||
|
Gereken tarih
RequiredByDate
|
Talep sahibinin mal veya hizmetlere ihtiyaç duyduğu tarihtir. | ||
|
Açıklama
Bu tarih, talep sahibi tarafından istenen ürünlerin teslim alınması gereken son tarihi belirtmek için girilir. Satın alma süreci için kurum içi hizmet seviyesi anlaşması (SLA) hedefi olarak kullanılır. Bu öznitelik, Required By Date Performance Dashboardının ve Required-By Date Adherence Rate temel performans göstergesinin temelini oluşturur. Bu tarihi gerçek Purchase Order oluşturma veya mal kabul tarihiyle karşılaştırarak satın alma sürecinin iç müşteri taleplerini ne ölçüde karşıladığını görebilir ve sistematik gecikmeleri belirleyebilirsiniz.
Neden önemli?
Süreç performansını kurum içi son tarihlere göre ölçmek ve satın alma sürecinin iş ihtiyaçlarını zamanında karşılayıp karşılamadığını anlamak için önemlidir.
Nereden alınır?
Genellikle talep satırı düzeyinde, POR_REQUISITION_LINES_ALL gibi tablolarda 'NEED_BY_DATE' benzeri bir alanda saklanır.
Örnekler
2023-11-012023-12-152024-01-31
|
|||
|
İş birimi
BusinessUnit
|
Talebin bağlı olduğu kuruluş içindeki belirli iş birimidir. | ||
|
Açıklama
İş birimi, talebin oluşturulduğu şirket içindeki ayrı bir tüzel veya işlevsel birimi temsil eder. Departmandan daha üst düzey bir organizasyonel gruplamadır. Verileri İş birimine göre analiz etmek, kuruluşun farklı bölümleri arasında üst düzey performans karşılaştırmaları yapılmasını sağlar. Bu sayede üst yönetim, süreç verimsizliklerinin belirli bir yerde mi yoksa genel olarak mı görüldüğünü ve iyileştirme çalışmalarının nereye odaklanması gerektiğini anlayabilir. Neredeyse tüm Dashboard ve KPI'larda filtreleme için kullanılan önemli bir boyuttur.
Neden önemli?
Üst düzey organizasyonel bağlam sağlar; kuruluşun farklı bölümleri arasında performans karşılaştırması ve stratejik analiz yapılmasına imkan verir.
Nereden alınır?
Oracle Fusion'da temel bir organizasyon alanıdır ve genellikle POR_REQUISITION_HEADERS_ALL gibi tablolarda talep başlığında bulunur.
Örnekler
Kuzey Amerika İş BirimiAvrupa İş BirimiGenel merkez
|
|||
|
Ret nedeni
RejectionReason
|
Bir talep veya onay adımı reddedildiğinde onaylayan tarafından belirtilen nedendir. | ||
|
Açıklama
Bir talep reddedildiğinde onaylayan kişi genellikle önceden tanımlanmış bir listeden seçim yaparak veya serbest metin girerek bir neden belirtir. Bu öznitelik, söz konusu gerekçeyi kaydeder. Bu öznitelik, süreç başarısızlıklarının kök neden analizinde büyük önem taşır. Retlerin ardındaki nedeni göstererek Amendment and Rejection Trends Dashboardını doğrudan destekler. Ret nedenlerini analiz etmek; hatalı kodlama, bütçe aşımı veya politika ihlalleri gibi yaygın sorunları belirlemenize yardımcı olur. Bu sorunları eğitim veya sistem kontrolleriyle ele alabilirsiniz.
Neden önemli?
Taleplerin neden reddedildiğine ilişkin doğrudan içgörü sağlar; yeniden çalışmayı azaltmak ve doğrudan işleme oranını artırmak için hedefli iyileştirmeler yapılmasına yardımcı olur.
Nereden alınır?
Workflow yorumlarından veya Workflow denetim izindeki belirli ret nedeni kodu alanlarından alınır. Bu alanlar FA_FUSION_SOAINFRA.WFTASK ile ilgili tablolarda veya ilişkili yorum depolarında bulunabilir.
Örnekler
Hatalı büyük defter hesabıMasraf merkezi bütçesi aşıldıTercih edilmeyen tedarikçi seçildiYinelenen talep
|
|||
|
Talep durumu
RequisitionStatus
|
Satın alma talebinin mevcut veya nihai durumudur. | ||
|
Açıklama
Bu öznitelik, talebin belirli bir zamandaki genel durumunu veya Approved, Rejected, In Process ya da Closed gibi nihai sonucunu belirtir. Event Logdaki birçok etkinlik çoğu zaman bu kaynaktan türetilir. Bu öznitelik, mevcut iş yükü ve bekleyen işler hakkında anlık görünüm sağlayan Requisition Status Overview Dashboardı için temel niteliktedir. Ayrıca belirli bir durumla sona eren vakaları filtreleyerek Requisition Rejection Rate gibi sonuç odaklı temel performans göstergelerini hesaplamak için kullanılır.
Neden önemli?
Taleplerin mevcut durumunu gösterir ve KPI hesaplamalarında nihai sonuçları belirlemek için kullanılır.
Nereden alınır?
Talep başlığı tablosunda, genellikle POR_REQUISITION_HEADERS_ALL içindeki 'DOCUMENT_STATUS' veya 'APPROVAL_STATUS' gibi bir alanda bulunur.
Örnekler
ONAYLANDISÜREÇTEREDDEDİLDİGERİ ÇEKİLDİ
|
|||
|
Talep sahibi adı
RequesterName
|
Satın alma talebini oluşturan ve gönderen çalışanın adıdır. | ||
|
Açıklama
Bu öznitelik, mal veya hizmet talebini başlatan kişiyi belirler. Bilgi genellikle sürecin başında, talep ilk oluşturulduğunda kaydedilir. Süreç performansını talep sahibine göre analiz etmek, “Talep sahibi performans metrikleri” Dashboardu için önemlidir. Taleplerle ilişkili yüksek değişiklik, reddedilme veya uzun çevrim süresi oranlarını göstererek hangi kullanıcıların veya grupların ek eğitime ihtiyaç duyabileceğini belirlemeye yardımcı olur. Sürecin insan odaklı bir görünümünü sunar.
Neden önemli?
Performansın talep sahibine göre analiz edilmesini sağlar; eğitim ihtiyaçlarının belirlenmesine ve verimli kullanıcıların veya departmanların öne çıkarılmasına yardımcı olur.
Nereden alınır?
Talep başlığı verilerinden alınır. Genellikle talep sahibinin kimliği, çalışan veya kullanıcı ana verileri tablosuyla birleştirilir. POR_REQUISITION_HEADERS_ALL içindeki 'PREPARER_ID' ile ilgili alanları bulun ve PER_ALL_PEOPLE_F ile birleştirin.
Örnekler
John SmithJane DoeEmily Jones
|
|||
|
Talep toplam tutarı
RequisitionTotalAmount
|
Satın alma talebinin toplam parasal değeridir. | ||
|
Açıklama
Bu öznitelik, tek bir satın alma talebindeki tüm kalemlerin değerlerinin toplamını gösterir. Her talebin finansal önemini anlamak için önemli bir veri noktasıdır. Process Mining analizinde toplam tutar çok çeşitli amaçlarla kullanılır. Genellikle farklı onay yollarına veya daha sıkı incelemelere tabi olan yüksek değerli talepleri filtrelemek için kullanılabilir. Dashboardlar bu öznitelikten yararlanarak çevrim süresi veya ret oranı gibi süreç metriklerinin talep değeriyle nasıl ilişkili olduğunu analiz edebilir.
Neden önemli?
Finansal bağlam sağlar. Değere dayalı analizle süreç iyileştirmelerine öncelik vermeye ve talep tutarının süreç davranışını nasıl etkilediğini anlamaya yardımcı olur.
Nereden alınır?
Talep başlığında, genellikle POR_REQUISITION_HEADERS_ALL içindeki REQUISITION_TOTAL gibi bir alanda bulunur. Ayrıca POR_REQUISITION_LINES_ALL içindeki satır kalemi tutarları toplanarak da hesaplanabilir.
Örnekler
550.0012500.7599.99
|
|||
|
Değiştirildi mi
IsAmendedFlag
|
Talebin en az bir kez değiştirilip değiştirilmediğini gösteren boolean bayrağıdır. | ||
|
Açıklama
Bu hesaplanan öznitelik, bir talebin ilk gönderiminden sonra herhangi bir değişikliğe uğrayıp uğramadığını gösterir. Talebin geçmişinde "Requisition Amended" etkinliğinin bulunup bulunmadığı kontrol edilerek türetilir. Bu işaret, analiz ve KPI hesaplamalarını kolaylaştırır. Doğrudan "Requisition Amendment Rate" KPI'ını hesaplamak ve düz akışta ilerlemeyen vakaları belirlemek için kullanılır. Değiştirilen ve değiştirilmeyen talepler arasındaki süreç metriklerini kolayca filtrelemenizi ve karşılaştırmanızı sağlar.
Neden önemli?
Değişiklik oranının hesaplanmasını kolaylaştırır ve değiştirilen taleplerle değiştirilmeyen talepleri kolayca karşılaştırmanızı sağlar.
Nereden alınır?
Bu öznitelik kaynak sistemde bulunmaz; olay günlüğünde değişiklikle ilgili etkinliklerin bulunup bulunmadığına göre veri dönüşümü sırasında hesaplanır.
Örnekler
truefalse
|
|||
|
Düz akışta mı
IsStraightThrough
|
Talebin herhangi bir değişiklik veya ret olmadan onaylanıp onaylanmadığını gösteren işaret. | ||
|
Açıklama
Bu hesaplanan işaret, gönderimden onaya kadar olan süreçte değişiklik veya ret gibi yeniden işlem döngülerine girmeden ilerleyen talepleri belirler. Tek bir vaka için sürecin eksiksiz yürütüldüğünü gösterir. Bu öznitelik, "Straight-Through Requisition Rate" KPI'ının temelini oluşturur. Düz akışta ilerleyen taleplerin özelliklerini, örneğin yaygın departmanları, talep sahiplerini veya türleri analiz ederek iyi uygulamaları ve otomasyon fırsatlarını ortaya çıkarabilirsiniz. Düz akışta ilerlemeyen talepleri analiz etmek ise verimsizliğin başlıca nedenlerini belirlemenize yardımcı olur.
Neden önemli?
Süreç verimliliğini doğrudan ölçer ve Straight-Through Requisition Rate KPI'ının temelini oluşturur. Böylece yeniden işlemenin nedenlerini belirlemenize yardımcı olur.
Nereden alınır?
Bu öznitelik veri dönüşümü sırasında hesaplanır. Bir vakada "Requisition Amended" veya "Approval Step Rejected" etkinliklerinden hiçbiri bulunmuyorsa vaka true olarak işaretlenir.
Örnekler
truefalse
|
|||
|
Kullanıcı adı
UserName
|
Onaylayan veya düzenleyen gibi belirli bir etkinliği gerçekleştiren kullanıcının adıdır. | ||
|
Açıklama
Requester Name başlatanı tanımlarken User Name, süreçte onaylama veya reddetme gibi belirli bir olayı gerçekleştiren kişiyi belirtir. Bu ayrım, farklı kişilerin görev aldığı çok adımlı onay iş akışlarında özellikle önemlidir. Bu öznitelik, onay darboğazlarını analiz etmek ve belirli onaylayanların veya ekiplerin performansını ölçmek için gereklidir. Onay zincirinde yer alan her kullanıcının işlem sürelerini analiz etmenizi sağlayarak Approval Workflow Bottlenecks Dashboardını doğrudan destekler.
Neden önemli?
Her olayın sorumlusunu tanımlar. Devir sürelerini, onaylayan performansını ve kaynak dağılımını analiz etmek için önemlidir.
Nereden alınır?
Her görevin tamamlanmasıyla ilişkili kullanıcıyı kaydeden FA_FUSION_SOAINFRA.WFTASK gibi Workflow geçmişi veya denetim izi tablolarından alınır.
Örnekler
David LeeSusan ChenMichael Brown
|
|||
|
Onay Workflow yolu
ApprovalWorkflowPath
|
Talep için gerekli olan önceden tanımlanmış onaylayanlar veya onay grupları dizisidir. | ||
|
Açıklama
Bu öznitelik, talep tutarı, türü ve departmanı gibi unsurları dikkate alarak şirket politikalarına göre beklenen standart onay sürecini tanımlar. Tasarlanması gereken süreci temsil eder. Approval Workflow Path, uyumluluk ve uygunluk analizi için temel bir özniteliktir. Gerçekleştirilen onay adımlarını belirlenmiş yolla doğrudan karşılaştırmanızı sağlayarak Compliance and Deviation Analysis Dashboardını ve Requisition Conformance Index temel performans göstergesini destekler. Sapmalar, politika ihlallerine veya süreç verimsizliklerine işaret edebilir.
Neden önemli?
Gerçek süreç akışını gerekli onay hiyerarşisiyle karşılaştırarak uygunluk kontrolü yapılmasını ve uyumlu olmayan taleplerin belirlenmesini sağlar.
Nereden alınır?
Bu bilgi Oracle Fusion BPM Worklist veya Approval Management Engine (AMX) içinde yapılandırılır. Her talep için tanımlanan yolu çıkarmak karmaşık olabilir ve yapılandırma tablolarının sorgulanmasını gerektirebilir.
Örnekler
Yönetici > Direktör > Finans Başkan YardımcısıMasraf merkezi sahibi > BT GüvenliğiYönetici > Departman yöneticisi
|
|||
|
Otomatik mi
IsAutomated
|
Bir etkinliğin sistem tarafından otomatik olarak gerçekleştirilip gerçekleştirilmediğini gösteren işaret. | ||
|
Açıklama
Bu öznitelik, süreçte insan yerine bir sistem kullanıcısı veya otomatik bir aracı tarafından yürütülen olayları belirler. Sistem tarafından başlatılan durum değişiklikleri veya düşük tutarlı kalemler için otomatik onay adımları buna örnek olabilir. Bu özniteliği analiz ederek süreçteki otomasyon düzeyini ölçebilirsiniz. Otomatik adımların hızını ve verimliliğini manuel adımlarla karşılaştırmak, ayrıca daha fazla otomasyon fırsatlarını belirlemek için kullanılabilir.
Neden önemli?
Süreçteki otomasyon düzeyini ölçmenize ve manuel görevleri otomatikleştirme fırsatlarını belirlemenize yardımcı olur.
Nereden alınır?
Bir etkinlikle ilişkilendirilen kullanıcının sistem veya servis hesabı olup olmadığı kontrol edilerek türetilir. Bunun için bilinen sistem kullanıcı kimliklerinin bir listesi gerekir.
Örnekler
truefalse
|
|||
|
Para birimi
CurrencyCode
|
Talep tutarının para birimi kodudur, örneğin USD veya EUR. | ||
|
Açıklama
Bu öznitelik, Talep toplam tutarının hangi para birimiyle ifade edildiğini belirtir. Küresel kuruluşlarda talepler farklı para birimleriyle oluşturulabilir. Finansal verileri doğru yorumlamak ve toplamak için gereklidir. Parasal değer içeren tüm analizlerde tutarların doğru karşılaştırılması için para birimi kodu kullanılmalıdır. Bunun için tek bir para birimine göre filtreleme yapılabilir veya tüm tutarlar ortak bir para birimine dönüştürülebilir.
Neden önemli?
Özellikle birden fazla para birimiyle çalışan çok uluslu kuruluşlarda doğru finansal analiz ve raporlamayı sağlar.
Nereden alınır?
Genellikle tutar alanlarının yanında, talep başlığı tablosunda, örneğin POR_REQUISITION_HEADERS_ALL içinde bulunur.
Örnekler
USDEURGBPJPY
|
|||
|
Satın alma siparişi numarası
PurchaseOrderNumber
|
Onaylanmış talepten oluşturulan satın alma siparişinin tanımlayıcısıdır. | ||
|
Açıklama
Bu öznitelik, satın alma talebini ortaya çıkan satın alma siparişine bağlar. Talep tamamen onaylandıktan sonra genellikle tedarikçiye gönderilmek üzere bir veya daha fazla satın alma siparişine dönüştürülür. Analizde bu kimlik, talep sonrasındaki süreci izlemek için gereklidir. Requisition-to-PO Lead Time temel performans göstergesinin hesaplanmasını ve Requisition to PO Cycle Time Dashboardının oluşturulmasını destekler. Ayrıca talep süreci verilerini sonraki PO ve faturalama süreçleriyle birleştirerek uçtan uca Satın Almadan Ödemeye analizi yapmanızı sağlar.
Neden önemli?
Talebi sonraki satın alma siparişine bağlar; talep-satın alma siparişi çevrim süresinin ölçülmesini ve uçtan uca süreç analizini sağlar.
Nereden alınır?
Bu bilgi, PO oluşturulduktan sonra saklanır. Genellikle talep satırına geri bağlanan PO_DISTRIBUTIONS_ALL gibi PO dağıtım tablolarındaki ilgili talep referansları incelenerek bulunur.
Örnekler
PO-2023-5832PO-2023-5833PO-2023-5834
|
|||
|
Talep türü
RequisitionType
|
Mal veya hizmet talebi gibi talebin kategorisidir. | ||
|
Açıklama
Bu öznitelik, talep edilen unsura göre talebi sınıflandırır. Yaygın türler arasında mal, hizmet ve sermaye harcamaları bulunur. Tür, gerekli onay iş akışını ve satın alma stratejisini etkileyebilir. Analizde Requisition Type, filtreleme ve karşılaştırma için etkili bir boyut olarak kullanılır. Örneğin hizmet taleplerinin onay çevrim süresinin mal taleplerine göre daha uzun olup olmadığını analiz edebilirsiniz. Farklı talep türlerinin farklı süreç davranışları veya darboğazlar sergileyip sergilemediğini anlamanıza yardımcı olur.
Neden önemli?
Mal ve hizmet gibi farklı satın alma türlerinde sürecin nasıl değiştiğini anlamak için analizin bölümlendirilmesini sağlar.
Nereden alınır?
Genellikle talep oluşturma sırasında seçilen satır kalemi türü veya kategorisine göre belirlenir. Talep satırı tablosunda, POR_REQUISITION_LINES_ALL içinde saklanabilir.
Örnekler
MallarHizmetlerYatırım harcaması
|
|||
|
Tedarikçi adı
SupplierName
|
Mal veya hizmetler için önerilen ya da önceden seçilen tedarikçinin adıdır. | ||
|
Açıklama
Bu öznitelik, mal veya hizmetlerin satın alınmasının planlandığı tedarikçiyi tanımlar. Tedarikçi, talep sahibi tarafından önerilebilir veya kataloglara ya da önceki anlaşmalara göre sistem tarafından belirlenebilir. Tedarikçiye göre analiz, önemli satın alma örüntülerini ortaya çıkarabilir. Örneğin belirli tedarikçilere ait taleplerin onaylanmasının daha uzun sürüp sürmediği veya daha yüksek ret oranlarına sahip olup olmadığı belirlenebilir. Bu bilgi, tedarikçi ilişkileri yönetimi ve satın alma stratejisi için değerli olabilir.
Neden önemli?
Süreç performansının tedarikçiye göre analiz edilmesini sağlar; kaynak bulma stratejisine ve tedarikçi ilişkileri yönetimine yardımcı olur.
Nereden alınır?
Talep satırı kalemi tablosu POR_REQUISITION_LINES_ALL içinde bulunur ve genellikle VENDOR_ID üzerinden POZ_SUPPLIERS gibi bir tedarikçi ana verileri tablosuna bağlanır.
Örnekler
Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
|
|||
|
Ürün açıklaması
ItemDescription
|
Talep satırında istenen ürün veya hizmetin açıklamasıdır. | ||
|
Açıklama
Bu öznitelik, satın alınan ürünün metinsel açıklamasını içerir. İstenen mal veya hizmetler hakkında ayrıntı sağlar. Genellikle yapılandırılmamış olsa da Ürün açıklaması analiz için değerli bir bağlam sunar. Talep türüyle yakalanmayan belirli satın alma türlerine ait talepleri ayırmak için filtrelerde kullanılabilir. Örneğin bir analist, belirli süreç akışlarını ve çevrim sürelerini anlamak için 'Software License' ifadesini içeren tüm talepleri arayabilir.
Neden önemli?
Satın alınan ürün veya hizmet hakkında ayrıntılı bağlam sunar; belirli mal veya hizmetlerde daha ayrıntılı filtreleme ve analiz yapılmasını sağlar.
Nereden alınır?
Talep satırı kalemi tablosu POR_REQUISITION_LINES_ALL içinde, ITEM_DESCRIPTION gibi bir alanda bulunur.
Örnekler
15 inç dizüstü bilgisayar, 16 GB RAMDanışmanlık hizmetleri - 4. çeyrek projesiYıllık yazılım bakım yenilemesi
|
|||
Satın Almadan Ödemeye - Satın alma talebi faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Satın alma siparişi oluşturuldu
|
Onaylanmış bir talep satırının satın alma siparişi oluşturmak için kullanılmasıyla gerçekleşir. Talep sürecini sonraki satın alma sürecine bağlar. | ||
|
Neden önemli?
Talep-Satın Alma Siparişi Çevrim Süresini ölçmek için önemli bir kilometre taşıdır. Buradaki gecikmeler, onaydan satın almaya geçişteki darboğazlara işaret eder.
Nereden alınır?
Bu açıkça kaydedilen bir olaydır. Talep ile satın alma siparişi arasındaki bağlantı, kaynak talep satırı kimliğine referans içeren PO_LINE_LOCATIONS_ALL gibi tablolarda saklanır.
Yakalayın
Verilen Talep Kimliğine referans veren Satın Alma Siparişinin oluşturulma tarihini bulun.
Olay türü
explicit
|
|||
|
Talep gönderildi
|
Tamamlanan talebin onay iş akışına gönderilmesiyle gerçekleşen kullanıcı işlemini ifade eder. Talep durumu “Eksik” veya “Taslak” durumundan onay beklediğini gösteren bir duruma geçtiğinde kaydedilir. | ||
|
Neden önemli?
Bu etkinlik, onay döngüsünü başlatır. Talep Onay Döngüsü Süresi ve genel çevrim sürelerini ölçmek için önemli bir kilometre taşıdır.
Nereden alınır?
POR_REQUISITION_HEADERS_ALL tablosundaki durum değişikliğinden çıkarılır, örneğin durumun 'PENDING APPROVAL' değerine geçmesi. Gönderim tarihi de çoğu zaman açıkça saklanır.
Yakalayın
Belge durum alanının ilk kez 'Pending Approval' değerine değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep kapatıldı
|
Talebin yaşam döngüsünün nihai olarak kapandığını gösterir. Bu, tüm satırların karşılandığı, örneğin satın alma siparişlerine dönüştürüldüğü veya iptal edildiği anlamına gelir. Bu durum, nihai bir durum güncellemesinden çıkarılır. | ||
|
Neden önemli?
Süreçteki başlıca başarılı son olaydır. Talebin tamamen işlendiğini ve başka bir işlem gerekmediğini doğrular.
Nereden alınır?
POR_REQUISITION_HEADERS_ALL tablosundaki talep başlığı durumunun 'CLOSED' değerine değişmesinden çıkarılır.
Yakalayın
Talebin belge durumunun 'Closed' olarak değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep oluşturuldu
|
Bir kullanıcının yeni bir satın alma talebini ilk kez kaydetmesiyle satın alma sürecinin başladığını gösterir. Bu olay genellikle sistemde ilgili bir zaman damgasıyla birlikte açık bir kayıt oluşturma işlemi olarak yakalanır. | ||
|
Neden önemli?
Bu, talep sürecinin temel başlangıç olayıdır. Oluşturma ile gönderim arasındaki süreyi analiz etmek, talebin resmileştirilmesindeki gecikmeleri ortaya çıkarabilir.
Nereden alınır?
Bu olay, POR_REQUISITION_HEADERS_ALL tablosunda, yeni bir Requisition ID oluşturulduğunda creation_date sütunundan alınarak kaydedilir.
Yakalayın
Talep başlık kaydı için oluşturma zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Talep onaylandı
|
Satın alma talebinin Workflow içindeki tüm adımları başarıyla tamamlamasından sonraki nihai onayı gösterir. Bu durum, talebin genel durumunun 'Approved' değerine değişmesinden çıkarılır. | ||
|
Neden önemli?
Talebin satın alma işlemi için hazır olduğunu gösteren önemli bir kilometre taşıdır. Toplam talep onay döngüsü süresinin ölçüm noktasıdır.
Nereden alınır?
POR_REQUISITION_HEADERS_ALL tablosundaki belge durum alanının 'APPROVED' değerine değişmesinden çıkarılır. Bu durum değişikliğinin tarihi, olay zamanı olarak kullanılır.
Yakalayın
Belge durumunun ilk kez 'Approved' olarak ayarlandığı zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep reddedildi
|
Talebin nihai olarak reddedildiğini ve bu talebe ilişkin sürecin sonlandığını gösterir. Talebin genel durumu 'Rejected' olarak güncellendiğinde çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, başarısız talepler için son noktadır. Bu vakaları analiz etmek, Talep Reddetme Oranı KPI'ını ve başarısızlık nedenlerini anlamak için önemlidir.
Nereden alınır?
POR_REQUISITION_HEADERS_ALL tablosundaki belge durumunun 'REJECTED' değerine değişmesinden çıkarılır.
Yakalayın
Belge durumunun ilk kez 'Rejected' olarak ayarlandığı zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Onay adımı başlatıldı
|
Bir talebin Workflow içinde belirli bir onaylayana veya onay grubuna atandığı anı gösterir. Bu bilgi, Workflow motorunun işlem günlüğünden alınır. | ||
|
Neden önemli?
Bu etkinlik, her onay adımındaki bekleme süresini hesaplamak için gereklidir. Belirli onaylayanlardan veya onay seviyelerinden kaynaklanan darboğazları belirlemeye yardımcı olur.
Nereden alınır?
Kullanıcılara atanan görevleri kaydeden Oracle Fusion Workflow tablolarından alınır. Onay görevinin atama zaman damgası kullanılır.
Yakalayın
Belirli talep için Workflow geçmişindeki görevin oluşturulma zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Onay adımı geri gönderildi
|
Bir onaylayan, talebi resmi olarak reddetmeden ek bilgi veya küçük düzeltmeler için hazırlayana geri gönderir. Bu genellikle Workflow sisteminde açıkça gerçekleştirilen bir işlemdir. | ||
|
Neden önemli?
Bu durum açıklama gerektiğini gösterir ve çevrim süresini uzatan bir yeniden çalışma döngüsü oluşturur. Geri göndermeleri reddetmelerden ayırmak, süreçteki sürtünme noktalarını daha iyi anlamayı sağlar.
Nereden alınır?
Talebin onay işlem geçmişinden alınır. Workflow sistemi, zaman damgasıyla birlikte bir 'RETURN' veya benzer bir işlem kaydeder.
Yakalayın
Workflow geçmişindeki 'RETURN' veya 'Request for Information' işleminin zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Onay adımı onaylandı
|
Bir onaylayanın, Workflow içindeki kendisine atanmış adımda talebi onaylama işlemini gösterir. Olay, onay geçmişine açıkça kaydedilir. | ||
|
Neden önemli?
Tek tek onay adımlarını izlemek, gerçek onay yolunu haritalamaya ve hiyerarşinin her aşamasındaki işlem süresini ölçmeye yardımcı olur.
Nereden alınır?
Talebin onay işlem geçmişinden alınır. Bu geçmiş genellikle onay hiyerarşilerini yöneten Workflow (WF) veya İnsan Kaynakları Yönetimi (HCM) tablolarında saklanır.
Yakalayın
Workflow işlem geçmişi günlüğündeki 'APPROVE' işleminin zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Onay adımı reddedildi
|
Bir onaylayan talebi reddeder. Bu işlem genellikle talebi düzeltmesi için hazırlayana geri gönderir veya talebi sonlandırır. İşlem, Workflow geçmişine açıkça kaydedilir. | ||
|
Neden önemli?
Bu etkinlik, yeniden çalışma ve gecikmelerin başlıca nedenlerinden biridir. Reddetmeleri analiz etmek, uyumluluk sorunlarını, bütçe problemlerini veya yetersiz gerekçeleri belirlemeye yardımcı olur.
Nereden alınır?
Talebin onay işlem geçmişinden alınır. Workflow sistemi, zaman damgasıyla birlikte bir 'REJECT' işlemi kaydeder.
Yakalayın
Workflow işlem geçmişi günlüğündeki 'REJECT' işleminin zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Talep değiştirildi
|
Bu olay, bir kullanıcının ilk gönderimden sonra talebi değiştirdiğini ve çoğu zaman onay sürecinin yeniden başlatılması gerektiğini gösterir. Bu durum, temel veri alanlarındaki değişiklikler veya talebin yeni bir sürümünün oluşturulması tespit edilerek çıkarılır. | ||
|
Neden önemli?
Sık yapılan değişiklikler, veri kalitesi sorunlarına veya değişen gereksinimlere işaret eder. Bu durum yeniden çalışmaya ve süreç gecikmelerine yol açar. Ayrıca 'Talep Değişiklik Oranı' KPI'ını doğrudan destekler.
Nereden alınır?
Talebin sürüm numaraları izlenerek veya gönderimden sonra durumun yeniden 'Incomplete' değerine döndüğü belirlenerek çıkarılır. Değişiklik günlükleri ya da denetim izi tabloları da bu değişiklikleri kaydedebilir.
Yakalayın
Talep gönderildikten sonra aynı Talep Kimliği için oluşturulan yeni sürümlerin zaman damgalarını belirleyin.
Olay türü
inferred
|
|||
|
Talep geri çekildi
|
Talep sahibinin, gönderilmiş bir talebi tamamen onaylanmadan önce iptal etmesi veya geri çekmesiyle gerçekleşir. Bu genellikle durum değişikliğiyle sonuçlanan açık bir kullanıcı işlemidir. | ||
|
Neden önemli?
Geri çekmeleri izlemek, değişen iş ihtiyaçları veya kullanıcıların gönderimden sonra hataları düzeltmesi gibi erken sonlandırma nedenlerini belirlemeye yardımcı olur.
Nereden alınır?
POR_REQUISITION_HEADERS_ALL tablosunda durumun 'WITHDRAWN' değerine değişmesinden çıkarılır. İşlem, talebin işlem geçmişine kaydedilir.
Yakalayın
Talep durumunun 'Withdrawn' olarak güncellendiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Satın Almadan Ödemeye - Talep sürecinizi optimize etmeye ve yeni verimlilik fırsatlarından yararlanmaya başlamak için bu Templatei kullanın. Satın alma operasyonlarınızı dönüştürmeye hazır olun.
Satın Almadan Ödemeye, talep sürecini %30 hızlandırın
Oracle P2P talep sürecinizi daha akıcı hale getirin ve çevrim süresini %30 azaltın.
Kredi kartı gerekmez, dakikalar içinde kurulumu tamamlayın.