Masraf yönetimi Veri Şablonunuz
Masraf yönetimi Veri Şablonunuz
- Analiz için önerilen öznitelikler
- Süreciniz boyunca izlenecek temel etkinlikler
- Veri çıkarma yönergeleri
Masraf yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik adı
ActivityName
|
Masraf raporunun yaşam döngüsünde gerçekleşen belirli bir olayın veya görevin adı. | ||
|
Açıklama
Etkinlik adı, Masraf raporu gönderildi, Yönetici onayladı veya Geri ödeme yapıldı gibi süreç adımlarını belirtir. Bu olaylar, süreç akışını oluşturan işlem sırasını gösterir. Bu etkinlikleri analiz ederek süreç haritasını görselleştirebilir, adımlar arasındaki darboğazları belirleyebilir ve onay ya da ret gibi farklı sonuçların sıklığını hesaplayabilirsiniz. Masraf yönetimi sürecinde neler yaşandığını anlamanın temelini oluşturur.
Neden önemli?
Bu öznitelik, süreç haritasını oluşturmak ve her masraf raporunun geçtiği olay sırasını anlamak için önemlidir.
Nereden alınır?
Bu bilgi, Brex sistemindeki olay günlüklerinden veya işlem durumlarından elde edilir. Durum kodlarının ya da olay türlerinin kullanıcıların anlayacağı adlarla eşleştirilmesi gerekebilir.
Örnekler
Masraf raporu oluşturulduYönetici onayladıFinans reddettiGeri ödeme yapıldı
|
|||
|
Masraf raporu kimliği
ExpenseReportId
|
Masraf raporunun yaşam döngüsünü izlemek için kullanılan benzersiz tanımlayıcı ve temel vaka kimliğidir. | ||
|
Açıklama
Masraf raporu kimliği, masraf yönetimi sürecinin temelini oluşturur. Oluşturma ve gönderimden onay ve geri ödemeye kadar ilgili tüm etkinlikleri tek bir vakada bir araya getirir. Process Mining sırasında bu kimlik, her masraf raporunun baştan sona analiz edilmesini sağlar. Raporun izlediği yolu yeniden oluşturmak, toplam çevrim sürelerini ölçmek, düzeltme için geri gönderilen raporlardaki yeniden çalışma döngülerini belirlemek ve yaygın ya da istisnai akışları anlamak için süreç varyantlarını analiz etmek amacıyla kullanılır.
Neden önemli?
Bu kimlik, masraf raporunun tüm yaşam döngüsünü izlemek ve çevrim sürelerini, darboğazları ve süreç sapmalarını analiz etmek için gereklidir.
Nereden alınır?
Brex masraf yönetimi modülündeki temel tanımlayıcılardan biridir. Genellikle masraf raporlarıyla ilgili tüm veri dışa aktarımlarında ve API uç noktalarında bulunur.
Örnekler
ER-2023-08-1012ER-2023-09-2345ER-2023-10-5567
|
|||
|
Olay zamanı
EventTime
|
Belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
|
Açıklama
Olay zamanı, süreçteki her etkinliğin kesin tarih ve saatini gösterir. Olayların kronolojik sırasını belirlediği için Process Mining açısından temel bir veridir. Bu zaman damgası, etkinlikler arasındaki çevrim sürelerini hesaplamak, bekleme sürelerini ve gecikmeleri belirlemek, süreç performansını farklı dönemlerde analiz etmek için kullanılır. Ortalama yönetici inceleme süresi ve Geri ödeme işleminin tamamlanma gecikmesi gibi temel metriklerin hesaplanmasını sağlar; darboğaz analizini ve performans takibini destekler.
Neden önemli?
Zaman damgası, gecikmeleri belirlemek için gereken çevrim süreleri ve bekleme süreleri gibi zamana dayalı tüm metrikleri hesaplamak açısından önemlidir.
Nereden alınır?
Brex’teki her olay veya işlem kaydında ilişkili bir zaman damgası bulunmalıdır. Bu bilgi, masraf raporlarına ait API yanıtlarında veya veri dışa aktarımlarında yer alabilir.
Örnekler
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
Çalışanın departmanı
EmployeeDepartment
|
Masraf raporunu gönderen çalışanın departmanı. | ||
|
Açıklama
Bu öznitelik, raporu gönderen çalışanın bağlı olduğu Satış, Mühendislik veya Pazarlama gibi iş birimini belirtir. Analiz için önemli bir kurumsal boyuttur. Verileri departmana göre analiz etmek, kuruluşun belirli bölümlerine özgü süreç farklılıklarını, darboğazları veya uyumluluk sorunlarını belirlemeye yardımcı olur. Örneğin, bir departmanda ret oranının diğerlerine göre çok daha yüksek ya da onay sürelerinin daha uzun olup olmadığını ortaya çıkarabilir. Bu da hedefli eğitim veya süreç düzenlemeleri gerektiğine işaret eder. Departman bütçelerini izlemek ve maliyetleri dağıtmak için de önemlidir.
Neden önemli?
Farklı iş birimlerindeki süreç performansını filtreleyip karşılaştırmaya ve departmana özgü sorunları ya da eğilimleri belirlemeye yardımcı olur.
Nereden alınır?
Bu bilgi genellikle Brex’teki çalışan profilinden alınır. Profil, çoğu zaman bir insan kaynakları bilgi sistemiyle eşitlenir.
Örnekler
SatışMühendislikPazarlamaFinans
|
|||
|
Olayı gerçekleştiren kullanıcı
EventUser
|
Raporu onaylayan yönetici gibi etkinliği gerçekleştiren kullanıcı. | ||
|
Açıklama
Olayı gerçekleştiren kullanıcı özniteliği, bir etkinlikten sorumlu kişiyi belirtir. Bu kişi raporu gönderen çalışan, raporu inceleyen yönetici veya geri ödemeyi işleme alan finans ekibi üyesi olabilir. Onaylayan performansı ve iş yükü Dashboardunda olduğu gibi bu öznitelik, iş yükünü ve performansı analiz etmek için gereklidir. Hangi onaylayanların en çok raporu işlediğini, kimin en hızlı onay verdiğini ve süreçte darboğaz oluşturan kişiler olup olmadığını belirlemeye yardımcı olur. Böylece iş yükü daha dengeli dağıtılabilir ve ihtiyaç duyulan kişilere hedefli destek sağlanabilir.
Neden önemli?
Bir işlemden sorumlu kişiyi belirler; böylece iş yükünü ve performansı analiz edebilir, kişilerin oluşturduğu darboğazları tespit edebilirsiniz.
Nereden alınır?
Bu veri genellikle Brex’teki masraf raporunun denetim kaydında veya olay geçmişinde tutulur.
Örnekler
john.smith@example.comjane.doe@example.comfinance-bot
|
|||
|
Politika ihlali işareti
PolicyViolationFlag
|
Masraf raporunun politika ihlali nedeniyle işaretlenip işaretlenmediğini belirten boole işareti. | ||
|
Açıklama
Brex’in otomatik politika motoru, kategori sınırını aşan bir masraf veya eksik makbuz gibi olası bir ihlal tespit ettiğinde bu öznitelik true ya da false olarak ayarlanır. Bu işaret, uyumluluk analizinin temelini oluşturur ve Politika ihlali oranı KPI’ının hesaplanmasında kullanılır. Uyumluluk sorunları içeren raporları hızla filtreleyerek bunların işlem sürelerine ve ret oranlarına etkisini anlamaya yardımcı olur. İşaretlenen raporları analiz ederek şirket politikalarını iyileştirebilir ve çalışanların daha fazla yönlendirmeye ihtiyaç duyduğu alanları belirleyebilirsiniz.
Neden önemli?
Uyumluluk takibini doğrudan destekler; politika ihlallerinin süreç verimliliği ve yeniden çalışma üzerindeki etkisini ölçmeye yardımcı olur.
Nereden alınır?
Bu, Brex’teki masraf raporu verilerinde bulunan ve genellikle politika motoru tarafından yönetilen bir boole alanı veya durum göstergesi olabilir.
Örnekler
truefalse
|
|||
|
Rapor durumu
ReportStatus
|
Masraf raporunun yaşam döngüsündeki mevcut durumu. | ||
|
Açıklama
Rapor durumu, masraf raporunun süreçteki mevcut konumunu gösterir. Örneğin, Yönetici onayı bekliyor, Onaylandı, Ödendi veya Reddedildi durumlarından biri olabilir. Bu öznitelik, özellikle Açık masraf raporları durum izleme Dashboardu için operasyonları takip etmek açısından önemlidir. Yöneticilerin ve finans ekiplerinin mevcut iş yükünü görmesine, belirli bir durumda bekleyen raporları tespit etmesine ve yapılacak işleri önceliklendirmesine yardımcı olur. Her durumda geçen süreyi analiz ederek süreç gecikmelerini ve verimsizlikleri belirleyebilirsiniz.
Neden önemli?
Masraf raporunun iş akışındaki mevcut konumunu gösterir; operasyon Dashboardları ve durum takibi için önemlidir.
Nereden alınır?
Brex’teki masraf raporu nesnesinin temel durum alanlarından biridir.
Örnekler
ONAY_BEKLİYORONAYLANDIREDDEDİLDİÖDENDİ
|
|||
|
Toplam tutar
TotalAmount
|
Masraf raporunun toplam parasal değeri. | ||
|
Açıklama
Bu öznitelik, masraf raporunda talep edilen toplam tutarı gösterir. Harcama örüntülerini ve masraf sürecinin mali etkisini anlamak için önemli bir mali metriktir. Analiz sırasında masraf raporları, yüksek ve düşük tutarlı raporlar gibi farklı değer aralıklarına göre gruplandırılabilir. Bu raporların onay süreçleri veya inceleme düzeyleri farklı olabilir. Öznitelik ayrıca mali raporlama, bütçe analizi ve departman ya da kategori bazındaki harcama eğilimlerini belirlemek için gereklidir.
Neden önemli?
Bu öznitelik, daha ayrıntılı inceleme gerektirebilecek veya onay süresi daha uzun olabilecek yüksek tutarlı masraf raporlarını belirlemek gibi mali analizlere imkân verir.
Nereden alınır?
Brex’teki her masraf raporuyla ilişkili standart bir alandır. API yanıtlarında veya dışa aktarımlarda ana masraf raporu nesnesinde bulunabilir.
Örnekler
150.752500.0079.99
|
|||
|
Bitiş zamanı
EndTime
|
Bir etkinliğin ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
StartTime (EventTime) bir etkinliğin başlangıcını, EndTime ise bitişini gösterir. “Yönetici incelemesi başladı” ve “Yönetici onayladı” gibi süre gerektiren etkinliklerde özellikle kullanışlıdır. Bir etkinlik için hem başlangıç hem de bitiş zamanının bulunması, işlem süresini etkinlik öncesindeki bekleme süresinden ayrı olarak hesaplamanızı sağlar. Böylece işin kendisinin ne kadar sürdüğünü doğru ölçebilirsiniz. Bu, darboğaz analizinin önemli bir parçasıdır.
Neden önemli?
Etkinliklerin işlem sürelerini bekleme sürelerinden ayrı ve hassas biçimde hesaplamanızı sağlayarak darboğaz analizinin doğruluğunu artırır.
Nereden alınır?
EndTime çoğu zaman sıradaki etkinliğin StartTime değeridir. Süresi belirli etkinlikler için kaynak verilerde ayrı bir alan olarak da bulunabilir.
Örnekler
2023-10-26T10:05:12Z2023-10-26T14:40:00Z2023-10-27T09:15:25Z
|
|||
|
Çalışanın adı
EmployeeName
|
Masraf raporunu oluşturan ve gönderen çalışanın adı. | ||
|
Açıklama
Bu öznitelik, masraf raporunun kimin adına gönderildiğini belirtir. Olayı gerçekleştiren kullanıcı, işlemi kimin yaptığını gösterirken çalışanın adı, masraf raporunun hangi çalışana ait olduğunu belirtir. Analiz sırasında masrafları çalışan bazında izlemeye imkân verir. Politika ihlali içeren raporları sık sık gönderen veya raporları sürekli reddedilen çalışanları belirleyerek ek eğitim ihtiyacını ortaya çıkarabilir. Ayrıca kuruluştaki farklı çalışanların veya rollerin harcama örüntülerini anlamaya yardımcı olur.
Neden önemli?
Masraf raporunun sahibini belirler ve çalışan bazında gönderim kalitesini ve uyumluluğu analiz etmenizi sağlar.
Nereden alınır?
Her masraf raporunda bulunan temel bir bilgidir ve Brex’te raporu oluşturan kişinin kullanıcı profiline bağlıdır.
Örnekler
Alice JohnsonRobert WilliamsMaria Garcia
|
|||
|
Fişler zamanında eklendi
ReceiptsAttachedOnTime
|
Fişlerin rapor gönderilmeden önce eklenip eklenmediğini gösteren işaret. | ||
|
Açıklama
Bu hesaplanmış boole özniteliği, yaygın bir süreç uygulamasına uyumu ölçer: masraf raporunu incelemeye göndermeden önce gerekli tüm fişleri eklemek. Belirli bir vakada “Fişler eklendi” etkinliği “Masraf raporu gönderildi” etkinliğinden önce gerçekleşirse “true” değerini alır. Bu işaret, “Fiş uyumu ve etkisi” Dashboardunu ve “Fiş ekleme uyumu” KPI’ını doğrudan destekler. Bu özniteliği analiz ederek fişlerin ne sıklıkla geç eklendiğini veya eksik olduğunu ölçebilir, bu davranışla gecikme, ret ve yeniden çalışma gibi süreç sonuçları arasındaki ilişkiyi inceleyebilirsiniz.
Neden önemli?
Fiş gönderme politikalarına uyumu ölçerek süreç gecikmelerinin ve retlerin yaygın nedenlerinden birini belirlemeye yardımcı olur.
Nereden alınır?
Bu değer, her vakadaki “Fişler eklendi” ve “Masraf raporu gönderildi” etkinliklerinin zaman damgaları karşılaştırılarak Process Mining aracında hesaplanır.
Örnekler
truefalse
|
|||
|
Harcama kategorisi
ExpenseCategory
|
Seyahat, yemek veya yazılım gibi harcamaya atanan kategori. | ||
|
Açıklama
Harcama kategorisi, çalışanın harcamanın türünü belirtmek için seçtiği sınıflandırmadır. Muhasebe, bütçeleme ve politika kurallarının uygulanması için kullanılır. Process Mining kapsamında harcamaları kategorilere ayırmak, süreci daha ayrıntılı incelemenizi sağlar. Örneğin, uluslararası seyahat gibi belirli harcama kategorilerinin onay süresinin daha uzun veya ret oranının daha yüksek olup olmadığını belirlemeye yardımcı olabilir. Bu analiz, belirli harcama türlerine yönelik politika ve süreçleri iyileştirmeyi destekler.
Neden önemli?
Harcama türüne göre süreç analizi yapmanızı sağlar; farklı harcama türlerinde görülen davranışları ve darboğazları ortaya çıkarabilir.
Nereden alınır?
Bu, harcama kalemlerinde standart olarak bulunan bir alandır. Bir raporda birden fazla kategori varsa rapor düzeyinde bir araya getirilmesi gerekir.
Örnekler
Uçak biletiYemek ve ağırlamaYazılım abonelikleriOfis malzemeleri
|
|||
|
İlk seferde onay
FirstPassApproval
|
Bir raporun ret veya düzeltme olmadan onaylanıp onaylanmadığını gösteren işaret. | ||
|
Açıklama
Bu hesaplanmış boole özniteliği, en verimli süreç örneklerini belirler. Bir masraf raporu gönderimden nihai onaya kadar tüm süreç boyunca hiç reddedilmeden veya düzeltme için geri gönderilmeden ilerlerse “true” değerini alır. Bu öznitelik, süreç kalitesi ve verimliliğinin önemli bir ölçütü olan “İlk seferde onay oranı” KPI’ının temelini oluşturur. Oranın yüksek olması, çalışanların kurallara uygun ve eksiksiz raporlar gönderdiğini, onay sürecinin de anlaşılır olduğunu gösterir. İlk seferde onaylanmayan raporların özelliklerini analiz etmek, süreçteki aksaklık ve hata kaynaklarını belirlemeye yardımcı olur.
Neden önemli?
Herhangi bir aksaklık yaşamadan ilerleyen raporları belirleyerek ilk gönderimlerin kalitesini ve temel iş akışının verimliliğini ölçer.
Nereden alınır?
Bu öznitelik, her vakanın etkinlik sıralaması Process Mining platformunda analiz edilerek ve ret ya da düzeltme etkinliklerinin bulunmadığı doğrulanarak hesaplanır.
Örnekler
truefalse
|
|||
|
Kaynak sistem
SourceSystem
|
Verilerin çıkarıldığı sistem. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynağını belirtir. Bu örnekte kaynak Brex’tir. Özellikle birden fazla sistemden gelen verilerin süreçleri bütünsel olarak incelemek üzere birleştirildiği ortamlarda veri yönetişimi ve izlenebilirlik açısından önem taşır. Analiz sırasında birden fazla kaynak sistem kullanılıyorsa verileri filtrelemeye ve gruplara ayırmaya yardımcı olur. Böylece metrikler ve süreç haritaları kaynağa göre doğru yorumlanır. Tek sistemli bir görünümde ise verinin kaynağını doğrulamak için kullanılır.
Neden önemli?
Verinin kaynağı hakkında gerekli bağlamı sağlar, izlenebilirliği güvence altına alır ve birden fazla sistemin kullanıldığı ortamlarda verilerin doğru filtrelenmesine yardımcı olur.
Nereden alınır?
Bu, veri çıkarma ve dönüştürme aşamasında genellikle eklenen sabit bir Brex değeridir.
Örnekler
BrexBrex-API-v2.1
|
|||
|
Ödeme yöntemi
PaymentMethod
|
Harcamayı nasıl ödediğinizi belirtir. Örneğin, şirket kartı veya kişisel para. | ||
|
Açıklama
Bu öznitelik, Brex tarafından verilen şirket kartından yapılan harcamalarla çalışanın cebinden ödediği ve geri ödeme gerektiren harcamaları birbirinden ayırır. Ödeme yöntemine göre süreç önemli ölçüde değişebileceğinden bu ayrım önemlidir. Şirket kartı işlemleri doğrulama ve mutabakat sürecinden geçebilirken geri ödemeler talep ve ödeme sürecini izler. Ödeme yöntemine göre analiz yapmak, her akışa özgü sorunları belirleyip ayrı ayrı iyileştirmenize yardımcı olur.
Neden önemli?
Şirket kartıyla yapılan harcamalar ile çalışanın cebinden ödediği ve geri ödeme gerektiren harcamalarda süreç akışı ve gerekli adımlar çoğu zaman farklıdır. Bu nedenle bu öznitelik, varyant analizi için önemlidir.
Nereden alınır?
Bu bilgi Brex’teki işlem verilerinde yer alır.
Örnekler
Brex şirket kartıGeri ödemeFatura ödemesi
|
|||
|
Otomatik mi
IsAutomated
|
Etkinliğin bir sistem kullanıcısı veya bot tarafından gerçekleştirilip gerçekleştirilmediğini belirten boole işareti. | ||
|
Açıklama
Bu öznitelik, etkinliğin otomatik politika kontrolü gibi sistem tarafından mı, yoksa manuel onay gibi bir kullanıcı tarafından mı gerçekleştirildiğini gösterir. Otomatik ve manuel etkinlikleri ayırt etmek, süreçteki otomasyon düzeyini anlamak açısından önemlidir. Kurallara dayalı sistemlerin ne kadar etkili olduğunu değerlendirmenize ve otomasyon fırsatlarını belirlemenize yardımcı olur. Örneğin, kaç raporun otomatik olarak onaylandığını ve kaçının manuel müdahale gerektirdiğini göstererek işlemlerin müdahalesiz tamamlanma oranını artırma çalışmalarına yön verebilir.
Neden önemli?
Süreçteki otomasyon düzeyini ölçmeye ve hangi adımların insanlar, hangilerinin sistem tarafından gerçekleştirildiğini belirlemeye yardımcı olur.
Nereden alınır?
Bu değer genellikle olayla ilişkili kullanıcı kontrol edilerek belirlenir. Sistem tarafından oluşturulan olaylar çoğu zaman genel bir “system” veya “bot” kullanıcısıyla ilişkilendirilir.
Örnekler
truefalse
|
|||
|
Para birimi
Currency
|
Masraf raporunun toplam tutarına ait para birimi kodu. | ||
|
Açıklama
Para birimi özniteliği, toplam tutarın USD, EUR veya GBP gibi hangi para biriminde olduğunu belirtir. Birden fazla para birimiyle işlem yapan çok uluslu kuruluşlarda doğru mali analiz için önemlidir. Bu öznitelik, mali verilerin doğru yorumlanmasını sağlar. Masraf tutarlarının doğru biçimde toplanmasına ve karşılaştırılmasına imkân verir; bunun için çoğu zaman tutarların ortak bir raporlama para birimine çevrilmesi gerekir. Farklı para birimlerindeki tutarların yanlışlıkla toplanmasını önler.
Neden önemli?
Birden fazla para biriminin kullanıldığı ortamlarda mali doğruluğu sağlar ve masraf tutarlarının doğru biçimde toplanıp raporlanmasına imkân verir.
Nereden alınır?
Bu alan genellikle Brex masraf raporu verilerinde tutar alanının yanında bulunur.
Örnekler
USDEURGBP
|
|||
|
Politika ihlali ayrıntıları
PolicyViolationDetails
|
İhlal edilen belirli politikayı açıklayan metin. | ||
|
Açıklama
Politika ihlali işareti bir ihlal yaşandığını gösterirken bu öznitelik ihlalin nedenini açıklar. İhlal edilen kurala ilişkin ayrıntıları içerir. Örneğin, “Yemek harcaması 50 $ sınırını aştı” veya “25 $ üzerindeki harcamalar için fiş gerekli”. Bu ayrıntı düzeyi, “Politika ihlali ve yeniden çalışma analizi” Dashboardu için çok değerlidir. En sık karşılaşılan ihlal türlerini belirleyerek temel nedenleri analiz etmenizi sağlar. Bu içgörü, belirli bir politikayı daha açık hâle getirmek, çalışanlara hatırlatma göndermek veya otomatik sistem kurallarını düzenlemek gibi hedefli adımlar atmanıza yardımcı olabilir.
Neden önemli?
Politika ihlallerinin temel nedenini ortaya koyarak politikalarda, kullanıcı eğitiminde ve sistem yapılandırmalarında hedefli iyileştirmeler yapmanızı sağlar.
Nereden alınır?
Bu bilgi, Brex’te işaretlenen bir harcamayla ilişkili uyumluluk veya inceleme notları bölümünde bulunabilir.
Örnekler
Harcama, kategori sınırını aşıyor.Fiş eksik.Yinelenen harcama tespit edildi.
|
|||
|
Ret nedeni
RejectionReason
|
Bir yöneticinin veya finans kullanıcısının masraf raporunu reddederken belirttiği neden. | ||
|
Açıklama
Bu öznitelik, masraf raporu reddedildiğinde belirtilen serbest metinli veya önceden tanımlanmış nedeni kaydeder. Otomatik politika işaretinden farklıdır ve onaylayanın verdiği manuel kararı yansıtır. Ret nedenlerini analiz etmek, süreçteki aksaklıkların ve yeniden çalışmanın nedenlerini anlamak açısından önemlidir. Sık yapılan gönderim hatalarını, net olmayan politikaları veya çalışanların ya da yöneticilerin yanlış anlamalarını belirlemeye yardımcı olur. Bu bilgiler, eğitim materyallerini ve sık sorulan soruları iyileştirmek, böylece ret ve yeniden çalışma oranlarını düşürmek için kullanılabilir.
Neden önemli?
Manuel retlerin nedenlerini açıklar ve kullanıcı eğitimini iyileştirip gelecekteki hataları azaltmak için doğrudan geri bildirim sağlar.
Nereden alınır?
Bu genellikle onaylayanların Brex arayüzünde “Reddet” işlemini seçtiklerinde doldurabildiği bir yorum alanıdır.
Örnekler
Yanlış harcama kategorisi seçildi.Lütfen iş gerekçesini daha ayrıntılı açıklayın.Bu satın alma önceden onaylanmamıştı.
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden en son yenilendiği zaman damgası. | ||
|
Açıklama
Bu öznitelik, analiz edilen verilerin güncelliğini gösterir. Brex’ten en son başarılı veri çıkarma işleminin tarih ve saatini kaydeder. Son veri güncellemesinin ne zaman yapıldığını bilmek, içgörülerin ne kadar güncel olduğunu anlamak açısından önemlidir. Dashboardların operasyonların en güncel durumunu mu yoksa daha eski verileri mi yansıttığını görmenize ve analizin gerçek zamanlı doğruluğuna ilişkin beklentilerinizi belirlemenize yardımcı olur.
Neden önemli?
Kullanıcılara verilerin güncelliği hakkında bilgi verir. Bu bilgi, operasyonlarla ilgili doğru ve güncel kararlar almak için önemlidir.
Nereden alınır?
Bu zaman damgası, Brex’ten başarılı bir veri aktarımının sonunda veri çıkarma aracı veya süreci tarafından oluşturulur.
Örnekler
2023-11-20T02:00:00Z2023-11-21T02:00:00Z
|
|||
|
Ülke
Country
|
Çalışanın veya harcama işleminin ilişkili olduğu ülke. | ||
|
Açıklama
Bu öznitelik, çalışanın ana ofisinin veya maliyet merkezinin bulunduğu ülkeyi gösterir. Küresel şirketlerde karşılaştırmalı analiz için önemli bir boyuttur. Süreci ülkeye göre analiz etmek; süreç performansındaki, uyumluluk oranlarındaki veya harcama davranışlarındaki bölgesel farklılıkları ortaya çıkarabilir. Örneğin, yerel düzenlemeler veya farklı yönetim yapıları nedeniyle bir ülkedeki onay süreleri daha uzun olabilir. Bu içgörü, yerel ihtiyaçları gözetirken süreçleri küresel ölçekte standartlaştırmaya yardımcı olur.
Neden önemli?
Farklı coğrafi bölgelerde süreç performansını ve uyumluluğu analiz etmenizi sağlar. Bu, çok uluslu kuruluşlar için özellikle önemlidir.
Nereden alınır?
Brex’teki çalışan profili bilgilerinden alınır ve çoğu zaman merkezi bir İK sistemiyle eşitlenir.
Örnekler
USACANGBRDEU
|
|||
|
Yeniden çalışma var mı
IsRework
|
Rapor en az bir kez düzeltme için geri gönderildiyse doğru olan hesaplanmış bir işaret. | ||
|
Açıklama
Bu boole özniteliği süreç akışından hesaplanır. Geçmişinde “Rapor düzeltme için gönderildi” etkinliği bulunan her masraf raporu için “true” değerini alır. Böylece yeniden çalışma gerektiren vakaları kolayca etiketleyip analiz edebilirsiniz. Bu işaret, “Masraf raporlarında yeniden çalışma oranı” KPI’ını hesaplamak ve “Politika ihlali ve yeniden çalışma analizi” Dashboardunu oluşturmak için kullanılır. Süreçte sorunsuz ilerleyen vakaları geri gönderilenlerle kolayca karşılaştırmanızı ve yeniden çalışmanın zaman ve maliyetini ölçmenizi sağlar.
Neden önemli?
Ek çalışma ve düzeltme gerektiren masraf raporlarını belirleyerek yeniden çalışmanın nedenlerini ve maliyetini analiz etmenizi sağlar.
Nereden alınır?
Bu öznitelik kaynak sistemde bulunmaz. Bir vakanın etkinlik sıralamasında “Rapor düzeltme için gönderildi” veya benzer yeniden çalışma etkinliklerinin olup olmadığı kontrol edilerek hesaplanır.
Örnekler
truefalse
|
|||
Masraf yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Finans onayladı
|
Finans ekibi incelemeyi tamamlamış ve masraf raporuna son onayı vermiştir. Bu, geri ödeme yapılmadan önceki son onay aşamasıdır. | ||
|
Neden önemli?
Bu önemli aşama ödemeye izin verir. Toplam onay çevrim süresini ölçmenin bitiş noktası, Geri ödeme işleminin tamamlanma gecikmesi KPI’ını ölçmenin ise başlangıç noktasıdır.
Nereden alınır?
Bu olay, son onaylayanın kimliği ve zaman damgasıyla birlikte onay geçmişine veya denetim kaydına açıkça yazılmalıdır.
Kaydedin
Olay günlüğünden veya durumun Finans onayladı ya da Ödeme için onaylandı olarak değişmesinden alınır.
Olay türü
explicit
|
|||
|
Geri ödeme yapıldı
|
Bu etkinlik, ödemenin çalışana gerçekten yapıldığı anı gösterir. Çalışan açısından sürecin son adımı ve başarılı tamamlanma noktasıdır. | ||
|
Neden önemli?
Bu, sürecin temel başarı bitiş noktasıdır. Çalışan memnuniyetini doğrudan etkileyen Ortalama uçtan uca çevrim süresi ve Geri ödeme işleminin tamamlanma gecikmesi KPI’larını hesaplamak için gereklidir.
Nereden alınır?
Bu olay, ödeme işlem günlüklerinden veya bankadan ya da ödeme sağlayıcısından gelen API onayından alınmalıdır. Gerçek ödeme tarihine karşılık gelir.
Kaydedin
İşlemin gerçekleştiği zaman damgasını içeren ödeme işlem günlüğünden alınır.
Olay türü
explicit
|
|||
|
Masraf raporu gönderildi
|
Çalışan, tamamladığı masraf raporunu onay için resmen gönderdiğinde bu etkinlik gerçekleşir. Kullanıcının gerçekleştirdiği bu önemli işlem, raporun durumunu Taslak veya Açık durumundan Onay bekliyor durumuna geçirir. | ||
|
Neden önemli?
Bu önemli aşama, onay iş akışını resmen başlatır. Gönderim ile son onay arasında geçen süre, toplam çevrim süresinin önemli bir bölümünü oluşturur.
Nereden alınır?
Bu olay genellikle denetim günlüğüne açıkça kaydedilir. Alternatif olarak, ilgili zaman damgasıyla birlikte durumun Gönderildi veya Yönetici onayı bekliyor olarak değişmesinden çıkarılabilir.
Kaydedin
Olay günlüğünden veya masraf raporu kaydındaki submission_timestamp alanından alınır.
Olay türü
explicit
|
|||
|
Masraf raporu oluşturuldu
|
Bu etkinlik, çalışanın masraf raporu oluşturmasıyla sürecin başladığını gösterir. Sistem, yeni bir masraf raporu kaydı oluşturulduğunda bu olayı kaydeder. Rapor taslak olarak açılabilir veya ilk masraf kalemleri eklenmiş olabilir. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç olayıdır. Bu noktadan gönderime kadar geçen süreyi analiz etmek, çalışanların davranışlarını ve masrafları raporlarken yaşanabilecek gecikmeleri anlamaya yardımcı olur.
Nereden alınır?
Bu olay, Brex veritabanındaki masraf raporu nesnesinin veya kaydının oluşturulma zaman damgasından alınabilir. Masraf raporu kimliğiyle ilişkili en erken zaman damgasına karşılık gelmelidir.
Kaydedin
Masraf raporunun üst bilgi kaydındaki oluşturulma tarihinden belirlenir.
Olay türü
explicit
|
|||
|
Muhasebe kaydı oluşturuldu
|
Masraf verilerinin şirketin büyük defterine veya ERP sistemine başarıyla kaydedildiği son adımı ifade eder. Böylece masraf raporunun mali mutabakatı tamamlanır. | ||
|
Neden önemli?
Bu etkinlik, sürecin mali muhasebe açısından tamamlandığını doğrular. Geri ödeme ile muhasebe kaydı arasındaki gecikmeler, sistem entegrasyonu veya muhasebe iş akışlarıyla ilgili sorunlara işaret edebilir.
Nereden alınır?
Muhasebe sistemiyle başarılı eşitlemenin ardından gelen API onayı veya durum güncellemesiyle kaydedilebilir. Olayın zaman damgası, muhasebe kaydının oluşturulduğu zamanı gösterir.
Kaydedin
Entegre ERP veya muhasebe yazılımından başarılı API geri bildirimi ya da durum güncellemesi geldiğinde kaydedilir.
Olay türü
explicit
|
|||
|
Rapor düzeltme için geri gönderildi
|
Yönetici veya finans ekibinden bir onaylayan, raporu düzeltilmesi için çalışana geri gönderir. Bu işlem kesin ret kararından farklıdır ve yeniden çalışma döngüsünü başlatır. | ||
|
Neden önemli?
Bu etkinlik, yeniden çalışmanın başlıca göstergesidir. Sıklığını izlemek, Masraf raporunda yeniden çalışma oranı KPI’ı ile Politika ihlali ve yeniden çalışma analizi Dashboardu için önemlidir.
Nereden alınır?
Durumun Düzeltme gerekiyor veya Geri gönderildi olarak değişmesinden çıkarılabilir. Sistem, bu durum güncellemesinin zaman damgasını kaydetmelidir.
Kaydedin
Genellikle yorumların da eklendiği Düzeltme gerekiyor gibi bir durum değişikliğinden çıkarılır.
Olay türü
inferred
|
|||
|
Yönetici onayladı
|
İlk düzey yönetici masraf raporunu inceleyip sonraki işlemler için onaylamıştır. Bu önemli karar noktası, raporu genellikle finans incelemesi veya otomatik onay olan bir sonraki aşamaya taşır. | ||
|
Neden önemli?
Bu aşama, ilk onay adımını tamamlar. Onay çevrim sürelerini, yöneticilerin iş yükünü ve İlk seferde onay oranını izlemek için gereklidir.
Nereden alınır?
Bu olay, onaylayanın kimliğini ve zaman damgasını içeren bir onay geçmişi tablosuna veya denetim kaydına açıkça yazılmış olabilir.
Kaydedin
Olay günlüğünden veya ilişkili zaman damgasıyla birlikte durumun Yönetici onayladı olarak değişmesinden alınır.
Olay türü
explicit
|
|||
|
Finans incelemesi başladı
|
Masraf raporunun son inceleme için finans veya muhasebe ekibinin kuyruğuna girdiği anı gösterir. Genellikle yönetici onayından sonra durumun değişmesinden çıkarılır. | ||
|
Neden önemli?
Bu, son ve çoğu zaman en önemli onay aşamasının başladığını gösterir. Süreyi analiz etmek, finans ekibindeki darboğazları belirlemeye yardımcı olur.
Nereden alınır?
Yönetici onayından sonra raporun durumu Finans onayı bekliyor veya benzer bir duruma geçtiğinde kaydedilen zaman damgasından çıkarılır.
Kaydedin
Durumun Finans incelemesi bekliyor olarak değiştiği zaman damgasından çıkarılır.
Olay türü
inferred
|
|||
|
Finans reddetti
|
Finans ekibi masraf raporunu genellikle politika, uyumluluk veya dokümantasyon sorunları nedeniyle reddetmiştir. Bu son ret kararı süreci durdurur. | ||
|
Neden önemli?
Bu önemli bir istisna olayıdır. Sıklığını ve nedenlerini analiz etmek, uyumluluk sorunlarını anlamak ve genel masraf raporu ret oranını hesaplamak için gereklidir.
Nereden alınır?
Diğer onay kararlarında olduğu gibi bu işlem de onaylayanın kimliği, zaman damgası ve ret nedeni ile birlikte denetim kaydına açıkça yazılmalıdır.
Kaydedin
Olay günlüğünden veya durumun Finans reddetti olarak değişmesinden alınır.
Olay türü
explicit
|
|||
|
Geri ödeme planlandı
|
Son onayın ardından masraf raporu, yaklaşan bir geri ödeme grubu kapsamında ödeme kuyruğuna alınır. Bu etkinlik, onay aşamasından ödeme sistemine devir teslimi gösterir. | ||
|
Neden önemli?
Bu adım, son onay ile ödemenin işleme alınması arasındaki gecikmeleri ortaya çıkarabilir. Onay aşamasındaki darboğazları ödeme sistemindeki verimsizliklerden ayırmaya yardımcı olur.
Nereden alınır?
Ödeme için hazır veya Planlandı durumuna geçişten çıkarılabilir. Sistem ayrı bir ödeme ya da ERP sistemiyle bağlantılıysa açık bir olay olarak da kaydedilebilir.
Kaydedin
Ödeme bekliyor durumuna geçişten veya bir ödeme grubu kaydının oluşturulmasından çıkarılır.
Olay türü
inferred
|
|||
|
Makbuzlar eklendi
|
Bir kullanıcının masraf kalemine makbuz görseli veya belgesi yüklemesini ya da eklemesini ifade eder. Genellikle her ek için zaman damgası içeren açık bir olay olarak kaydedilir. | ||
|
Neden önemli?
Bu etkinliği izlemek, Makbuz uyumu ve etkisi Dashboardu için önemlidir. Gecikmelerin veya retlerin makbuzların eksik ya da geç gönderilmesiyle ilişkili olup olmadığını belirlemeye yardımcı olur.
Nereden alınır?
Bu bilgi, ekleri masraf kalemleriyle ilişkilendiren bağlantılı bir tabloda tutulabilir. Her ek kaydının kendi oluşturulma zaman damgası olmalıdır.
Kaydedin
Kullanıcı bir masraf kalemiyle ilişkili dosyayı başarıyla yüklediğinde kaydedilir.
Olay türü
explicit
|
|||
|
Politika ihlali işaretlendi
|
Rapordaki bir veya daha fazla masraf kaleminin şirket politikasını ihlal ettiğini belirten otomatik veya manuel bir olaydır. Sistem kuralı tetiklendiğinde ya da inceleyen kişi sorunu işaretlediğinde kaydedilebilir. | ||
|
Neden önemli?
Bu etkinlik, Politika ihlali ve yeniden çalışma analizi Dashboardu ile Politika ihlali oranı KPI’ı için önemlidir. Yaygın uyumluluk sorunlarını ve politikaların açıklığa kavuşturulması gereken alanları belirlemeye yardımcı olur.
Nereden alınır?
Politika ihlali işareti özniteliğinin true olarak ayarlanmasından çıkarılır. Zaman damgası, işaretin durumunun son güncellendiği zamandır.
Kaydedin
Politika ihlalini belirten bir boole işaretindeki veya durum alanındaki değişiklikten çıkarılır.
Olay türü
inferred
|
|||
|
Yönetici incelemesi başladı
|
Bu etkinlik, masraf raporunun yöneticinin onay kuyruğuna girdiği anı gösterir. Genellikle gönderimden hemen sonra rapor durumunun Yönetici onayı bekliyor olarak değişmesinden çıkarılır. | ||
|
Neden önemli?
Bu, ilk onay aşamasının başladığını gösterir. Bu noktadan Yönetici onayladı veya Yönetici reddetti durumuna kadar geçen süreyi ölçmek, Ortalama yönetici inceleme süresi KPI’ı için önemlidir.
Nereden alınır?
Masraf raporunun durumu Yönetici onayı bekliyor veya benzer bir duruma geçtiğinde kaydedilen zaman damgasından çıkarılır. Bu olay genellikle Masraf raporu gönderildi olayıyla aynı zamana denk gelir.
Kaydedin
Durumun Yönetici onayı bekliyor olarak değiştiği zaman damgasından çıkarılır.
Olay türü
inferred
|
|||
|
Yönetici reddetti
|
İlk düzey yönetici masraf raporunu inceleyip reddetmiştir. Bu işlem genellikle süreci durdurur veya raporu düzeltilmesi için çalışana geri gönderir. | ||
|
Neden önemli?
Bu etkinlik olumsuz bir sonucu ve süreç istisnasını gösterir. Masraf raporu ret oranını hesaplamak ve ilk onay düzeyindeki başarısızlık nedenlerini belirlemek için önemlidir.
Nereden alınır?
Onay kararlarında olduğu gibi bu işlem de zaman damgası ve neden koduyla birlikte onay geçmişi tablosuna veya denetim kaydına açıkça yazılmalıdır.
Kaydedin
Olay günlüğünden veya ilişkili zaman damgasıyla birlikte durumun Yönetici reddetti olarak değişmesinden alınır.
Olay türü
explicit
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Veri toplama sürecinizi kolaylaştırmak ve masraf yönetiminizi iyileştirme yolunda hızla ilerlemek için bu şablondan yararlanın. İçgörüleri ortaya çıkarmaya ve verimliliği artırmaya bugün başlayın.
Brex masraf yönetiminizi bugün iyileştirin
Onay çevrim süresini %30 azaltın, çalışan memnuniyetini artırın.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.