Harcama Yönetimi Veri Şablonunuz

Ramp
Harcama Yönetimi Veri Şablonunuz

Harcama Yönetimi Veri Şablonunuz

Bu template, harcama yönetimi sürecinizi analiz etmek ve optimize etmek için gerekli verileri toplamak üzere net bir yol haritası sunar. Temel öznitelikleri, izlenecek ana aktiviteleri ve verilerinizi Ramp'ten çekmek için pratik rehberliği özetler. Anlamlı süreç keşfi ve iyileştirme için gereken tüm bilgileri topladığınızdan emin olmak için bu kaynağı kullanın.
  • Toplanması Önerilen Nitelikler
  • Takip Edilmesi Gereken Temel Aktiviteler
  • Ramp için çıkarma rehberliği
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Gider Yönetimi Öznitelikleri

Bunlar, harcama yönetimi sürecinizin kapsamlı bir analizi için event log'unuza dahil etmeniz gereken temel veri alanlarıdır.
3 Gerekli 6 Önerilen 14 İsteğe Bağlı
Ad Açıklama
Faaliyet Adı
ActivityName
Harcama yönetimi süreci içinde belirli bir zamanda meydana gelen belirli event veya görevin adı.
Açıklama

Bu öznitelik, 'Harcama Gönderildi', 'Yönetici Onayladı' veya 'Geri Ödeme Gerçekleştirildi' gibi harcama raporu yaşam döngüsündeki tek bir adımı açıklar. Bu aktiviteler, süreç haritasındaki düğümleri oluşturarak süreç akışının görselleştirilmesine ve analiz edilmesine olanak tanır.

Aktiviteleri analiz etmek, hangi adımların en sık olduğunu, darboğazların nerede meydana geldiğini ve farklı workflow'ların nasıl değiştiğini belirlemeye yardımcı olur. Operasyonların sırasını anlamak ve her aşamada performansı ölçmek için temel bir bileşendir.

Neden önemli

Süreç haritasındaki adımları tanımlar, süreç akışının baştan sona görselleştirilmesini ve analiz edilmesini sağlar.

Nereden alınır

Bu, genellikle Ramp'teki her harcama raporuyla ilişkili event log'larından veya durum değişikliği kayıtlarından türetilir.

Örnekler
Gider GönderildiYönetici OnayladıFinans İncelemesi BekleniyorGeri Ödeme Gerçekleştirildi
Gider Raporu Kimliği
ExpenseReportId
Her harcama raporu için sürecin birincil case identifier'ı olarak hizmet veren benzersiz tanımlayıcı.
Açıklama

Harcama Raporu ID'si, tek bir harcama gönderimine ilişkin tüm event'leri ve aktiviteleri gruplandırır. Bir harcama talebinin ilk girişinden nihai ödemesine kadar eksiksiz, kronolojik takibine olanak tanır.

Process Mining'de bu öznitelik, her harcama raporunun uçtan uca yolculuğunu yeniden yapılandırmak için esastır. Bunu case ID olarak kullanarak analizler, döngü sürelerini doğru bir şekilde hesaplayabilir, darboğazları belirleyebilir ve raporların onay sürecinde izlediği farklı yolları görselleştirebilir.

Neden önemli

Bu, tüm ilgili aktiviteleri tek bir süreç örneğine bağlayan temel özniteliktir ve uçtan uca analizi mümkün kılar.

Nereden alınır

Bu tanımlayıcı, Ramp içindeki ana harcama raporu veya işlem tablosunda bulunmalıdır.

Örnekler
ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
Olay Zaman Damgası
EventTimestamp
Aktivitenin gerçekleştiği kesin tarih ve saat.
Açıklama

Süreçteki her aktivitenin, ne zaman gerçekleştiğini kaydeden bir zaman damgası vardır. Bu zamansal veri, olayları kronolojik olarak sıralamak için kullanılır ve tüm zamanla ilgili analizlerin temelini oluşturur.

Süreç madenciliğinde, zaman damgaları aktiviteler arasındaki döngü sürelerini hesaplamak, bir vakanın toplam süresini ölçmek ve gecikmeleri belirlemek için kullanılır. Bu bilgi, performans izleme ve süreç iyileştirme fırsatlarını belirlemek için kritiktir.

Neden önemli

Bu öznitelik, event'lerin kronolojik sırasını sağlar ve tüm süre hesaplamaları ile performans analizi için esastır.

Nereden alınır

Bu bilgi genellikle Ramp'in event log'larında veya işlem verilerinde aktivite veya durum kayıtlarının yanında bulunur.

Örnekler
2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
Çalışan Departmanı
EmployeeDepartment
Harcama raporunu gönderen çalışanın departmanı.
Açıklama

Bu öznitelik, harcamayı gönderen çalışanın ait olduğu iş birimini veya departmanı gösterir; örneğin 'Satış', 'Mühendislik' veya 'Pazarlama'.

Bu, analiz için kritik bir boyuttur, çünkü kuruluşun farklı bölümlerindeki süreç performansını filtrelemeye ve karşılaştırmaya olanak tanır. Departmanlar arasındaki onay süreleri, revizyon oranları ve politika uyumluluğundaki farklılıkları ortaya çıkararak hedeflenen iyileştirme girişimlerini destekleyebilir.

Neden önemli

Farklı iş birimleri arasında süreç metriklerinin karşılaştırılmasını sağlar, verimlilik, uyumluluk ve harcamalardaki farklılıkları vurgular.

Nereden alınır

Bu bilgi muhtemelen çalışanın Ramp'teki kullanıcı profili veya entegre bir IK sistemi ile ilişkilidir.

Örnekler
SatışPazarlamaMühendislikFinans
Gider Kategorisi
ExpenseCategory
Bir harcamaya atanan kategori, örneğin 'Seyahat', 'Yazılım' veya 'Yemek'.
Açıklama

Bu öznitelik, harcamaları önceden tanımlanmış kategorilere ayırır, bu da şirket harcamalarının takip edilmesine ve kontrol edilmesine yardımcı olur. Tek bir harcama raporu birden fazla kategoriden öğeler içerebilir.

Harcama kategorisine göre analiz yapmak, 'Harcama Kategorisi Analizi' dashboard'u için esastır. Finans ekiplerinin paranın nerede harcandığını anlamasına, bütçe uyumluluğunu izlemesine ve zaman içindeki harcama eğilimlerini veya anormalliklerini belirlemesine yardımcı olur.

Neden önemli

Detaylı harcama analizi yapılmasına olanak tanır, ana maliyet unsurlarını ve bütçe optimizasyonu fırsatlarını belirlemeye yardımcı olur.

Nereden alınır

Bu genellikle Ramp'teki harcama raporunda satır kalemi düzeyinde bir detaydır. Bazı analizler için verilerin rapor düzeyine toplanması gerekebilir.

Örnekler
Uçak BiletiYemek ve EğlenceYazılım AboneliğiOfis Malzemeleri
Kullanıcı Adı
UserName
Harcamayı gönderen çalışan veya onaylayan dahil olmak üzere, aktiviteyi gerçekleştiren kullanıcının adı veya ID'si.
Açıklama

Bu öznitelik, süreçteki belirli bir event'ten (örneğin, bir harcama raporunu gönderme, onaylama veya inceleme) sorumlu kişiyi tanımlar. Bu, bir çalışanın adı veya benzersiz bir kullanıcı ID'si olabilir.

Kullanıcıya göre analiz yapmak, iş yükü dağılımını anlamaya, en iyi performans gösterenleri belirlemeye ve ek eğitim gerektirebilecek kişileri tespit etmeye yardımcı olur. Onay performansı ve kaynak yönetimi ile ilgili dashboard'lar için kilit öneme sahiptir.

Neden önemli

Süreç aktivitelerini belirli kişilere atar, bu da kaynak düzeyinde performans analizi yapılmasına ve eğitim ihtiyaçlarının belirlenmesine olanak tanır.

Nereden alınır

Kullanıcı bilgileri genellikle Ramp'teki her harcama raporunun denetim izinde veya işlem geçmişinde kaydedilir.

Örnekler
Alice Johnson`Bob Smith``Charlie Brown``Sistem Otomasyonu`
Politika İhlali Bayrağı
PolicyViolationFlag
Gider raporunun bir politika ihlali nedeniyle işaretlenip işaretlenmediğini gösteren bir bayrak.
Açıklama

Bu boolean öznitelik, sistemin otomatik kontrolleri bir harcama limitini aşma veya yinelenen bir harcama gönderme gibi şirket harcama politikalarının potansiyel bir ihlalini tespit ederse true olarak ayarlanır.

Bu bayrak, 'Politika İhlali Tespiti' dashboard'u ve ilgili KPI için kritiktir. Politika kontrollerinin etkinliğini ölçmeye ve yaygın uyumsuzluk alanlarını belirlemeye yardımcı olur, bu da politika güncellemelerini veya çalışan eğitimini bilgilendirebilir.

Neden önemli

Politika uyumluluğunu doğrudan ölçer, uyumsuz harcamaları ve ilgili riskleri belirlemeye ve azaltmaya yardımcı olur.

Nereden alınır

Bu, Ramp içinde gönderim veya onay süreci sırasında otomatik politika kontrolleri tarafından tetiklenen sistem tarafından oluşturulmuş bir bayrak olması muhtemeldir.

Örnekler
truefalse
Rapor Toplam Tutarı
ReportTotalAmount
Harcama raporunun toplam parasal değeri.
Açıklama

Bu öznitelik, tek bir rapora dahil edilen tüm harcamaların toplamını temsil eder. Harcama kalıplarını anlamak için önemli bir finansal metriktir.

Süreç analizinde, rapor tutarı case'leri segmentlere ayırmak ve yüksek değerli raporların farklı onay yollarını izleyip izlemediğini veya işlemenin daha uzun sürüp sürmediğini araştırmak için kullanılabilir. Harcama analizi dashboard'ları ve maliyet tasarrufu fırsatlarını belirlemek için temeldir.

Neden önemli

Analiz için önemli bir finansal boyut sağlar, raporların değere göre segmentlere ayrılmasına ve genel harcamaların izlenmesine olanak tanır.

Nereden alınır

Bu, Ramp'teki harcama raporu nesnesi üzerindeki birincil alandır.

Örnekler
150.752500.0089.99
Revizyon Nedeni
RevisionReason
Bir harcama raporu çalışana revizyon için geri gönderildiğinde verilen neden.
Açıklama

Bir onaylayıcı bir harcama raporunu reddettiğinde veya geri gönderdiğinde, genellikle bir neden belirtir. Bu öznitelik, 'Eksik Fiş', 'Yanlış Kategori' veya 'Politika Dışı' gibi bu nedeni yakalar.

Bu bilgi, 'Harcama Revizyon Oranı ve Nedenleri' dashboard'u için paha biçilmezdir. Yeniden işlemenin en yaygın nedenlerini analiz ederek, kuruluşlar gönderim sürecindeki sistemik sorunları belirleyebilir ve hataları azaltmak için hedeflenen eğitim veya sistem iyileştirmeleri uygulayabilir.

Neden önemli

Yeniden işleme temel nedenlerine doğrudan içgörü sağlar, ilk seferdeki gönderim kalitesini artırmak için hedeflenen eylemleri mümkün kılar.

Nereden alınır

Bu veri, Ramp'te 'Harcama Revizyon İçin Geri Gönderildi' aktivitesi gerçekleştiğinde yorumlarda veya ret detaylarında yakalanacaktır.

Örnekler
Ayrıntılı fiş eksikliğiGider politika limitini aşıyorYanlış gider kategorisi seçildiTekrar eden işlem
Denetim Sonucu
AuditOutcome
Harcama raporunun dahili veya harici denetiminin sonucu.
Açıklama

Resmi bir denetimden geçen gider raporları için bu öznitelik, 'Onaylandı', 'Kısmen Reddedildi' veya 'Daha Fazla Bilgi Gerekli' gibi nihai sonucu kaydeder.

Bu veri, 'Gider Denetim Performansı' dashboard'unun merkezindedir. Denetim sürecinin etkinliğini değerlendirmeye, farklı sonuçların sıklığını izlemeye ve denetim bulgularının finansal etkisini anlamaya yardımcı olur.

Neden önemli

Denetim sürecinin etkinliğini ve sonuçlarını ölçer, uyumluluk ve kontrol zayıflıkları hakkında içgörüler sağlar.

Nereden alınır

Bu, Ramp'in denetim modülünde veya ayrıntılı harcama denetimi için kullanılıyorsa entegre bir sistemde kaydedilecektir.

Örnekler
BaşarılıNotlarla GeçtiReddedildiÜst Düzeye Aktarıldı
Finans İnceleme Süresi
FinanceReviewTime
Bir harcama raporunun finansal inceleme aşamasında geçirdiği süre.
Açıklama

Bu metrik, bir raporun finans kuyruğuna ('Finansal İnceleme Bekleniyor') girdiği andan, bir finans onaylayıcısının işlem yaptığı ('Finans Onayladı' veya 'Finans Reddeti') ana kadar geçen süreyi ölçer.

'Ortalama Finansal İnceleme Süresi' KPI'sı ve 'Finansal İnceleme Verimliliği' dashboard'u için birincil ölçüttür. Bu süreyi analiz etmek, finansal inceleme sürecini kolaylaştırma veya otomatikleştirme fırsatlarını belirlemeye, manuel çabayı azaltmaya ve genel döngüyü hızlandırmaya yardımcı olur.

Neden önemli

Finans departmanının inceleme sürecinin verimliliğini ölçer, otomasyon ve düzene sokma fırsatlarını vurgular.

Nereden alınır

Bu değer, finansal inceleme aktivitelerinin başlangıç ve bitiş event zaman damgalarından hesaplanır.

Örnekler
4 saat1 gün 2 saat18 saat
Finans Onaylayıcısı
FinanceApprover
Harcama raporunu onaylayan finans ekibinden kullanıcı.
Açıklama

Bir finans inceleme adımını içeren iş akışları için bu öznitelik, nihai onayı gerçekleştiren finans departmanındaki belirli kişiyi veya ekibi tanımlar.

Bu öznitelik, performansı bireysel veya ekip düzeyinde analiz etmeye olanak tanıyarak 'Finans İnceleme Verimliliği' dashboard'unu destekler. Darboğazları belirlemeye, iş yükü dağılımını değerlendirmeye ve finans inceleme aşamasının etkinliğini ölçmeye yardımcı olur.

Neden önemli

Finans inceleme adımının detaylı performans analizine olanak tanır, süreçteki kritik bir kontrol noktasını optimize etmeye yardımcı olur.

Nereden alınır

Bu, Ramp'teki harcama raporunun onay geçmişinde, finansal inceleme aşamasında yakalanacaktır.

Örnekler
Finans Ekibi ADavid LeeFinans Otomasyon Botu
Geri Ödeme Yöntemi
ReimbursementMethod
ACH veya banka havalesi gibi geri ödeme ödemesini gerçekleştirmek için kullanılan yöntem.
Açıklama

Bu öznitelik, çalışanın hangi ödeme kanalı aracılığıyla geri ödendiğini belirtir. Farklı yöntemlerin farklı işlem süreleri ve maliyetleri olabilir.

Geri ödeme performansını yönteme göre analiz etmek, en verimli ödeme kanallarını belirlemeye yardımcı olur. 'Geri Ödeme Yöntemi Performansı' dashboard'u bu verileri döngü sürelerini ve güvenilirliği karşılaştırmak için kullanarak potansiyel olarak ödeme stratejilerinin optimize edilmesine yol açabilir.

Neden önemli

Farklı ödeme kanalları arasında performans karşılaştırmasına olanak tanır, hız ve güvenilirlik için optimizasyon yapmaya yardımcı olur.

Nereden alınır

Bu bilgi, Ramp içindeki ödeme veya geri ödeme kayıtlarında bulunmalıdır.

Örnekler
ACH TransferiKurumsal Kart KredisiDoğrudan Para Yatırma
Gönderim Yöntemi
SubmissionMethod
Harcama raporunun mobil uygulama veya web portalı gibi hangi kanal aracılığıyla gönderildiği.
Açıklama

Bu öznitelik, çalışanın harcama raporunu nasıl gönderdiğini gösterir. Yaygın yöntemler arasında mobil uygulama, masaüstü web tarayıcısı veya e-posta yönlendirme bulunur.

Gönderim yöntemini analiz etmek, kullanıcı davranışı ve teknoloji adaptasyonu hakkında içgörüler sağlayabilir. Örneğin, belirli bir kanal aracılığıyla gönderilen raporlar için yüksek bir revizyon oranı, o kanalın arayüzünde kullanılabilirlik sorunları olduğunu gösterebilir.

Neden önemli

Kullanıcı davranışına ilişkin bağlam sağlar ve belirli gönderim kanallarının daha yüksek hata oranları veya gecikmelerle ilişkili olup olmadığını belirlemeye yardımcı olabilir.

Nereden alınır

Bu bilgi, Ramp'in sistem log'larındaki gönderim event'inin metadata'sında yakalanabilir.

Örnekler
Mobil UygulamaWeb PortalE-posta
Kaynak Sistem
SourceSystem
Verilerin çıkarıldığı kaynak uygulamayı tanımlar.
Açıklama

Bu öznitelik, süreç verilerinin kayıt sistemini belirtir, ki bu durumda Ramp'tir. Verilerin birden fazla sistemden karıştırılabileceği ortamlarda, net veri soyutlaması sağlayarak faydalıdır.

Analiz için, belirli bir kaynaktan veri filtrelemeye yardımcı olur ve veri doğrulama ve yönetişim amaçları için kullanılabilir.

Neden önemli

Verilerin kökeni hakkında bağlam sağlar, bu da veri yönetimi ve birden fazla sistemden veri entegre edilirken kritiktir.

Nereden alınır

Bu, veri çekme ve dönüşüm süreci sırasında eklenen genellikle statik bir değerdir ('Ramp').

Örnekler
Ramp
Muhasebe Kayıt Süresi
AccountingPostingTime
Bir geri ödemenin gerçekleştirildiği andan, işlemin muhasebe sistemine kaydedildiği ana kadar geçen süre.
Açıklama

Bu hesaplanmış metrik, finansal kayıt tutmadaki gecikmeyi ölçer. 'Geri Ödeme Gerçekleştirildi' event'i ile 'Muhasebe Sistemiyle Senkronize Edildi' event'i arasındaki zaman farkıdır.

Bu öznitelik, 'Ortalama Muhasebe Kayıt Süresi' KPI'sı ve 'Muhasebe Kayıt Gecikmeleri' dashboard'u için kullanılır. Finansal kayıtların zamanında güncellenmesini sağlamaya yardımcı olur, bu da doğru ve zamanında finansal raporlama için önemlidir.

Neden önemli

Finansal kayıt tutmadaki gecikmeleri vurgular, muhasebe kapanış sürecini hızlandırmak için eylemleri mümkün kılar.

Nereden alınır

Bu, veri log'undaki geri ödeme ve muhasebe senkronizasyon event'leri için event zaman damgalarından hesaplanır.

Örnekler
2 saat1 gün5 dakika
Olay Bitiş Zamanı
EventEndTime
Süresi olan bir aktivitenin ne zaman sona erdiğini gösteren zaman damgası.
Açıklama

Birçok aktivite anlık olsa da, 'Politika Kontrolü Yapıldı' gibi bazı aktivitelerin ölçülebilir bir süresi olabilir. Bu öznitelik, bu tür aktivitelerin bitiş zamanını yakalar ve Başlangıç Zamanı'nı tamamlar.

Hem başlangıç hem de bitiş zamanına sahip olmak, aktivite işlem sürelerinin hassas bir şekilde hesaplanmasına olanak tanır. Bu, 'Ortalama Politika Kontrol Süresi' gibi KPI'lar ve genel süreç içinde belirli otomatik veya manuel görevlerin tamamlanmasının tam olarak ne kadar sürdüğünü belirlemek için esastır.

Neden önemli

Bireysel aktivite sürelerinin hassas bir şekilde hesaplanmasını sağlar, bu da verimsiz süreç adımlarını belirlemek için kritiktir.

Nereden alınır

Süresi olan aktiviteler için bu, Ramp'in olay verilerinde günlüğe kaydedilir. Anlık olaylar için ise StartTime ile aynı olabilir.

Örnekler
2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
Onay Adım Sayısı
ApprovalStepCount
Bir harcama raporunun geçtiği toplam resmi onay adımı sayısı.
Açıklama

Bu hesaplanmış metrik, tek bir harcama raporu için gerçekleşen 'Yönetici Onayladı' ve 'Finans Onayladı' gibi farklı onay aktivitelerinin sayısını sayar. Onay workflow'unun karmaşıklığını ölçmeye yardımcı olur.

Bu öznitelik, 'Rapor Başına Ortalama Onay Adımı' KPI'sı ve 'Basit Harcama Onay Yolları' dashboard'u için kullanılır. Bu sayıyı, özellikle raporun değeri veya kategorisiyle ilişkili olarak analiz ederek, kuruluşlar basit, düşük değerli harcamaların aşırı karmaşık onay süreçlerine tabi olup olmadığını belirleyebilir.

Neden önemli

İş akışı karmaşıklığını nicelendirir, basitleştirme fırsatlarını belirlemeye yardımcı olur, özellikle düşük riskli raporlar için.

Nereden alınır

Bu, event log'undaki her case içinde belirli onay ile ilgili aktivitelerin sayılmasıyla hesaplanır.

Örnekler
123
Onaylayan Yönetici
ApprovingManager
Onay adımını gerçekleştiren yöneticinin adı.
Açıklama

Bu öznitelik, bir çalışanın harcama raporunu incelemekten ve onaylamaktan sorumlu yöneticiyi tanımlar. Raporu gönderen kullanıcıdan farklıdır.

Onaylayan yöneticiyi takip etmek, 'Yönetici Onay Döngüsü Süresi' dashboard'u için esastır. Onay iş yüklerini ve performansını analiz etmeye olanak tanır, hızlı onaylayan yöneticileri darboğaz oluşturan yöneticilerden ayırır. Bu, iş yüklerini dengelemeye veya ek destek sağlamaya yardımcı olabilir.

Neden önemli

Bireysel onaylayıcıların performans analizini sağlar, onay iş akışındaki darboğazları belirlemeye ve gidermeye yardımcı olur.

Nereden alınır

Bu bilgi, Ramp'teki onay workflow verilerinin bir parçasıdır ve bir yönetici bir rapor üzerinde işlem yaptığında kaydedilir.

Örnekler
Ayşe YılmazJohn MillerSusan Chen
Son Veri Güncellemesi
LastDataUpdate
Verilerin kaynak sistemden son yenilendiği zamanı gösteren `timestamp`.
Açıklama

Bu öznitelik, en son veri çekiminin tarihini ve saatini kaydeder. Analiz edilen verinin güncelliği hakkında bağlam sağlar.

Herhangi bir analizde, verinin güncelliğini bilmek sonuçları doğru yorumlamak için çok önemlidir. Bu öznitelik, kullanıcıların güncel bilgilere bakıp bakmadıklarını anlamalarına yardımcı olur.

Neden önemli

Kullanıcıları verilerin güncelliği hakkında bilgilendirir, analizlerin güncel ve ilgili bilgilere dayanmasını sağlar.

Nereden alınır

Bu zaman damgası, veri çekme süreci sırasında oluşturulur ve eklenir.

Örnekler
2023-11-01T06:00:00Z
Toplam Geri Ödeme Döngüsü Süresi
TotalReimbursementCycleTime
Bir harcama raporunun gönderildiği andan geri ödemenin gerçekleştirildiği ana kadar geçen toplam süre.
Açıklama

Bu hesaplanmış metrik, geri ödeme sürecinin çalışanın bakış açısından uçtan uca süresini ölçer. Her case için 'Harcama Gönderildi' ve 'Geri Ödeme Gerçekleştirildi' event'leri arasındaki zaman farkı olarak hesaplanır.

Bu öznitelik, 'Ortalama Geri Ödeme Döngüsü Süresi' KPI'sının ve 'Uçtan Uca Geri Ödeme Döngüsü' dashboard'unun temelidir. Süreç verimliliğinin üst düzey bir ölçümünü sağlar ve çalışan memnuniyetinin önemli bir göstergesidir.

Neden önemli

Genel süreç süresini nicelendirir, uçtan uca verimliliği ölçmek için temel bir performans göstergesi sağlar.

Nereden alınır

Bu, veri dönüşümü sırasında ilk gönderim event'inin zaman damgasının nihai geri ödeme event'inden çıkarılmasıyla hesaplanır.

Örnekler
3 gün 4 saat10 gün 1 saat1 gün 8 saat
Yeniden İşleme mi?
IsRework
Bir gider raporunun en az bir kez revizyona geri gönderilip gönderilmediğini gösteren hesaplanmış bir bayrak.
Açıklama

Bu boolean öznitelik, belirli bir case için 'Harcama Revizyon İçin Geri Gönderildi' aktivitesinin gerçekleşip gerçekleşmediği kontrol edilerek türetilir. En az bir revizyon döngüsünden geçmiş herhangi bir rapor için true olarak ayarlanır.

Bu bayrak, 'Harcama Raporu Revizyon Oranı' KPI'sının hesaplanmasını basitleştirir ve ilk geçişte onaylanan raporlar ile yeniden işleme gerektiren raporlar arasında kolay filtreleme ve karşılaştırma yapılmasına olanak tanır. Bu iki grubun analizi, revizyonların zaman ve maliyet etkisini ortaya çıkarabilir.

Neden önemli

Süreci yeniden işleme analizi için kolayca segmentlere ayırır, düzeltme için geri gönderilen raporların sıklığını ve etkisini nicelendirmeye yardımcı olur.

Nereden alınır

Bu, veri dönüşümü sırasında case içinde bir revizyon aktivitesinin varlığı kontrol edilerek türetilen hesaplanmış bir alandır.

Örnekler
truefalse
Yönetici Onay Süresi
ManagerApprovalTime
Bir raporun yönetici incelemesi beklediği andan, yöneticinin onu onayladığı veya reddettiği ana kadar geçen süre.
Açıklama

Bu metrik, yönetici onay aşamasının süresini hesaplar. 'Yönetici İncelemesi Bekleniyor' aktivitesi ile sonraki 'Yönetici Onayladı' veya 'Yönetici Reddeti' aktivitesi arasındaki zaman farkıdır.

Bu süre, 'Ortalama Yönetici Onay Süresi' KPI'sını hesaplamak ve 'Yönetici Onay Döngüsü Süresi' dashboard'unu beslemek için kullanılır. Genellikle önemli bir darboğaz olan ilk onay düzeyindeki gecikmeleri belirlemeye yardımcı olur.

Neden önemli

Kritik bir onay adımının süresini izole eder, yönetici incelemelerinden kaynaklanan darboğazları belirlemeye ve gidermeye yardımcı olur.

Nereden alınır

Bu, event log'undan yönetici incelemesi bekleme ve tamamlama event'leri arasındaki zaman farkı bulunarak hesaplanır.

Örnekler
1 saat 15 dakika2 days 3 hours5 saat 30 dakika
Gerekli Önerilen İsteğe Bağlı

Gider Yönetimi Aktiviteleri

Bunlar, doğru Process Discovery ve performans ölçümü için Event Log'unuza kaydetmeniz gereken temel süreç adımları ve dönüm noktalarıdır.
5 Önerilen 7 İsteğe Bağlı
Aktivite Açıklama
Geri Ödeme Gerçekleştirildi
Geri ödeme ödemesi başarıyla işlendi ve çalışana gönderildi. Bu genellikle çalışan için son adımdır ve ödeme döngüsünün sonunu işaret eder.
Neden önemli

Bu, geri ödeme süreci için birincil bitiş event'idir. Gönderimden bu noktaya kadar olan süre, çalışan memnuniyeti ve süreç verimliliği için kritik bir KPI'dır.

Nereden alınır

Ödeme işleme günlüklerinden veya ödeme sağlayıcısıyla yapılan bir entegrasyondan yakalandı. Ramp'teki gider durumu 'Geri Ödendi' veya 'Ödendi' olarak güncellenir.

Yakala

Ödeme sistemi başarılı ödeme transferini onayladığında bir olay günlüğe kaydedilir.

Event tipi explicit
Gider Gönderildi
Bir çalışan, bir gider için gerekli tüm bilgilerin eksiksiz olduğunu onaylar ve onay süreci için gönderir. Bu, gideri 'taslak' veya 'dikkat gerektiren' durumdan 'onay bekleyen' durumuna taşıyan açık bir kullanıcı eylemidir.
Neden önemli

Bu aktivite, onay ve geri ödeme döngüsünü resmi olarak başlatan kritik bir kilometre taşıdır. Onay ve geri ödeme SLA'larını ölçmek için temel teşkil eder.

Nereden alınır

Gider nesnesinin durum geçmişinden yakalandı. Bu, kullanıcının işlemi inceleme için gönderme eylemine karşılık gelir.

Yakala

Kullanıcı 'Gönder' düğmesine tıkladığında, bir durum değişikliğini tetikleyerek günlüğe kaydedilir.

Event tipi explicit
Gider Oluştu
Bir harcamanın oluşturulmasını işaret eder; genellikle bir kurumsal kart kullanıldığında otomatik olarak veya bir çalışan manuel olarak cep harcaması kaydı oluşturduğunda başlatılır. Bu event genellikle işlem veri akışlarından veya kullanıcı arayüzü eylemlerinden yakalanır.
Neden önemli

Bu, harcama yaşam döngüsü için birincil başlangıç event'idir. Bu event'ten itibaren geçen süreyi analiz etmek, gönderim gecikmelerini ve genel süreç hızını anlamaya yardımcı olur.

Nereden alınır

Ramp kart işlem günlüklerinden veya manuel olarak girilen bir gider nesnesinin oluşturulma zaman damgasından oluşturuldu. Gider veya işlem tablosundaki ilk kayıt oluşturma olayını arayın.

Yakala

Bir kart işlemi işlendiğinde veya bir kullanıcı yeni bir gider girişi oluşturduğunda doğrudan günlüğe kaydedilir.

Event tipi explicit
Muhasebe Sistemiyle Senkronize Edildi
Harcama işlem verileri, NetSuite, QuickBooks veya Xero gibi entegre muhasebe sistemine başarıyla kaydedildi. Bu event, sürecin finansal kayıt tutma bölümünün tamamlandığını işaret eder.
Neden önemli

Bu, uçtan uca sürecin son aktivitesidir. Buradaki gecikmeler, finansal raporlamanın doğruluğunu ve finansal kapanışın hızını etkileyebilir.

Nereden alınır

Bir entegrasyon log'unda veya Ramp'teki harcama nesnesi üzerinde bir durum güncellemesi olarak kaydedilir. 'Senkronize Edildi', 'Kaydedildi' veya 'Dışa Aktarıldı' gibi bir durum arayın.

Yakala

Başarılı veri senkronizasyonunda muhasebe entegrasyon hizmeti tarafından bir günlük girdisi oluşturulur.

Event tipi explicit
Yönetici Onayladı
Yönetici harcamayı inceledi ve onayladı, böylece finansal inceleme veya geri ödeme gibi bir sonraki adıma geçmesine izin verdi. Bu, açık bir kullanıcı eylemi aracılığıyla yakalanır.
Neden önemli

Bu, ilk düzey onayın başarıyla tamamlandığını gösteren önemli bir kilometre taşıdır. Onay workflow'larını analiz etmek ve darboğazları belirlemek için çok önemlidir.

Nereden alınır

Yönetici 'Onayla' düğmesine tıkladığında, harcamanın onay geçmişine bir event olarak kaydedilir. Event log'u onaylayıcının ID'sini ve bir timestamp içermelidir.

Yakala

Yönetici yetkilerine sahip bir kullanıcı tarafından 'Onayla' eylemi üzerine bir olay günlüğe kaydedilir.

Event tipi explicit
Finans İncelemesi Bekleniyor
Onaylanmış bir gider yükseltildi ve şu anda finans veya muhasebe ekibinden inceleme beklemektedir. Bu durum genellikle yüksek değerli giderler veya politika işaretleri olanlar için geçerlidir. Aktivite bir durum değişikliğinden çıkarılır.
Neden önemli

Finansal inceleme döngüsünün başlangıcını işaret eder. Bu aşamanın süresini ölçmek, finans ekibinin iş yükünü ve verimliliğini değerlendirmeye yardımcı olur ve otomasyon fırsatlarını belirler.

Nereden alınır

Yönetici onayından sonra gider nesnesindeki bir durum değişikliğinden 'Finans Onayı Bekleniyor' olarak çıkarıldı. Bu, giderin durum geçmişine erişim gerektirir.

Yakala

Gider durumunun 'Finans İncelemesi Bekleniyor' olarak güncellendiği zamanki zaman damgasından türetilmiştir.

Event tipi inferred
Finans Onayladı
Finans ekibi harcamayı inceledi ve nihai onayı verdi, geri ödeme ve muhasebe senkronizasyonu için uygun hale getirdi. Bu, finans ekibinin bir üyesi tarafından açık bir kullanıcı eylemi olarak kaydedilir.
Neden önemli

Ödeme öncesindeki son onay kapısını temsil eder. Bu aktiviteyi analiz etmek, uçtan uca onay döngüsünü ve finans ekibi verimliliğini anlamaya yardımcı olur.

Nereden alınır

Giderin onay geçmişinde bir olay olarak kaydedildi. Finans departmanından bir kullanıcıyla ilişkili bir onay olayı arayın.

Yakala

Finans yetkilerine sahip bir kullanıcı tarafından 'Onayla' eylemi üzerine bir olay günlüğe kaydedilir.

Event tipi explicit
Fiş Eklendi
Bir fişin bir harcamayla ilişkilendirildiği anı temsil eder; bu, OCR eşleştirmesi yoluyla otomatik olarak veya kullanıcı tarafından manuel olarak yapılabilir. Bu, fiş dosyasının işlem kaydına başarıyla bağlandığı zaman yakalanır.
Neden önemli

Bu aktiviteyi takip etmek, eksik belgelerden kaynaklanan gecikmeleri belirlemeye yardımcı olur. Uyumluluğu ve denetim hazırlığını sağlamak için önemli bir adımdır.

Nereden alınır

Bir fiş yüklendiğinde veya eşleştirildiğinde gider veya işlem geçmişine kaydedildi. Bir ek oluşturma olayını veya 'receipt_attached' gösteren bir bayrağı kontrol edin.

Yakala

Sistem bir fiş görüntüsünü veya dosyasını gider kaydına bağladığında olay oluşturulur.

Event tipi explicit
Geri Ödeme Planlandı
Cepten ödenen giderler için onaylanan tutar ödeme işleme sırasına alınmıştır. Bu olay, giderin tüm onaylardan geçtiğini ve ödenmeye hazır olduğunu gösterir.
Neden önemli

Bu kilometre taşı, onay sürecini ödeme uygulama sürecinden ayırır. Ödeme işlemedeki gecikmelerle onaylardaki gecikmeleri izole etmeye yardımcı olur.

Nereden alınır

Büyük olasılıkla son onaydan sonra gider durumunun 'Geri Ödeme Bekleniyor' veya 'Ödeme İçin Hazır' olarak değişmesinden çıkarıldı. Ödemeler toplu yapılıyorsa açık bir olay da olabilir.

Yakala

'Ödeme için Hazır' durum değişikliğinden veya bir ödeme toplu işlem tablosunda bir kayıt oluşturulmasından türetilmiştir.

Event tipi inferred
Gider Revizyon İçin Geri Gönderildi
Bir onaylayıcı, yönetici veya finans inceleyicisi, gideri reddetmiş ve düzeltme için çalışana geri göndermiştir. Bu, 'Revizyon Gerekli' veya 'Reddedildi' durumuna bir durum değişikliği ile yakalanır.
Neden önemli

Bu aktivite, süreçte yeniden işleme döngüsünü ifade eder ve bu da döngü süresini doğrudan artırır. Bu event'leri izlemek, yaygın gönderim hatalarını belirlemeye ve ilk geçiş verimini artırmaya yardımcı olur.

Nereden alınır

Gider nesnesindeki bir durum değişikliğinden 'Revizyon Gerekli' veya benzer bir duruma çıkarıldı. Olay, eylemi başlatan onaylayıcıya bağlanmalıdır.

Yakala

Gider durumunun 'Revizyon Gerekli' veya 'Reddedildi' olduğu zamanki zaman damgasından türetilmiştir.

Event tipi inferred
Politika Kontrolü Yapıldı
Sistem, harcamayı yapılandırılmış şirket politikalarına göre otomatik olarak denetler ve olası ihlalleri işaretler. Bu genellikle gönderimden kısa bir süre sonra meydana gelen sistem tarafından oluşturulan bir event'tir.
Neden önemli

Otomatik uyumluluk kontrollerinin verimliliğini ve süreç üzerindeki etkisini ölçer. Yaygın politika ihlallerini ve çalışan eğitimi gereken alanları belirlemeye yardımcı olur.

Nereden alınır

Büyük olasılıkla gider işlemiyle ilişkili bir denetim izinde veya günlükte kaydedildi. 'policy_check' veya 'compliance_scan' ile ilgili sistem olaylarını arayın.

Yakala

Otomatik politika motoru işlem üzerinde çalıştıktan sonra bir sistem günlük girdisi oluşturulur.

Event tipi explicit
Yönetici İncelemesi Bekleniyor
Harcama gönderildi ve şimdi çalışanın doğrudan yöneticisinin incelemesini bekliyor. Bu durum, harcama durumu gönderimden sonra 'Yönetici Onayı Bekleniyor' veya benzer bir değere değiştiğinde anlaşılır.
Neden önemli

Yönetici onay aşamasının başlangıcını belirler. Bu durumda geçirilen sürenin analizi, yönetici onay döngü sürelerini ölçmek ve iyileştirmek için anahtardır.

Nereden alınır

Gider nesnesindeki bir durum değişikliğinden 'Onay Bekleniyor' gibi bir duruma ve bir yöneticinin kuyruğuna atanmasından çıkarıldı. Durum geçmişi takibi gerektirir.

Yakala

Gider durumunun 'Yönetici Onayı Bekleniyor' olduğu zamanki zaman damgasından türetilmiştir.

Event tipi inferred
Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

Verilerinizi Ramp'ten Nasıl Alırsınız?