Harcama Yönetimi Veri Şablonunuz
Harcama Yönetimi Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Ramp için çıkarma rehberliği
Gider Yönetimi Öznitelikleri
| 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
|
|||
Gider Yönetimi Aktiviteleri
| 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
|
|||