Finans Ekiplerinin Açıkça Açıklayabileceği Gider Onay Kuralları

Finans ekiplerinin açık onay kurallarına neden ihtiyacı var

«Her gideri yönetici onaylar» gibi basit bir kural, harcamalar ekipler, bütçeler veya tutar limitleri arasında dağıldığında yetersiz kalır. Bir satış yöneticisi, bir çalışanın müşteri yemeğine neden ihtiyaç duyduğunu anlayabilir. Ancak maliyet merkezinde bütçe kalıp kalmadığını veya bu harcamanın finans tarafından incelenmesi gerekip gerekmediğini bilmeyebilir.

Açık gider onay kuralları, her kişiye tanımlı bir karar sorumluluğu verir. Talep sahibi gerekli bilgileri sağlar. Bütçe sahibi, harcamanın kendi maliyet merkezine ait olduğunu doğrular. Finans ekibi politikayı, vergiyi, makbuzları ve yüksek harcama limitlerini kontrol eder. Böylece talepler «lütfen onaylayın» gibi belirsiz isteklerle dolu e-posta zincirlerinde dolaşmak yerine bilinen bir yol üzerinden ilerler.

Harcama limitleri ile bütçe sahipliği farklı sorulara yanıt verir. Limit, ne zaman başka bir onay düzeyinin gerektiğini belirler. Bütçe sahipliği ise giderin hangi bütçeden karşılanacağını gösterir. Bir departman yöneticisi, departmanındaki her bütçenin otomatik sahibi olmamalıdır. Bir kişi ekibi yönetirken başka biri satın almayı finanse eden projenin veya maliyet merkezinin bütçesini kontrol edebilir.

Örneğin bir çalışan, müşteri projesi için 180 dolarlık bir yazılım aboneliği gönderir. Yöneticisi iş ihtiyacını onaylayabilir, proje bütçesinin sahibi ise harcamanın bu projeye kaydedilmesini onaylayabilir. Abonelik standart politikanın dışındaysa finans ekibi de inceleme yapabilir. Tutar 3.500 dolara ulaştığında talebin finans direktöründen veya satın alma incelemecisinden onay alması da gerekebilir.

Talep ekranlarını oluşturmadan önce bu kararlar üzerinde anlaşın. Aksi halde form, iş akışının aslında maliyet merkezi ve proje kodu gerektirdiği yerde yalnızca bir yönetici adı toplayabilir. Ekipler daha sonra istisnalar ekler ve bu durum yeniden çalışmaya ve karışıklığa yol açar.

Kuralları sade bir dille yazın. Her kural şunları açıklamalıdır:

• Tutar, gider türü veya maliyet merkezi gibi hangi durumun onayı tetiklediği
• Talebi kimin onayladığı ve neyi kontrol ettiği
• Ne zaman ikinci bir onayın gerektiği
• Normal onaylayıcı bulunmadığında ne olduğu
• Bir istisnayı kimin onaylayabileceği

Finans, yöneticiler ve çalışanlar kuralı aynı şekilde yorumlamalıdır. Politika üzerinde anlaşmaya varıldıktan sonra AppMaster gibi bir no-code platform, politika kararlarını ekran tasarımının içine gizlemeden kural haritasını formlara, onay süreçlerine ve bildirimlere dönüştürebilir.

Her talebin ihtiyaç duyduğu bilgilerle başlayın

Bir onaylayıcı, yorumlarda ayrıntı istemeden karar verebilmek için yeterli bağlama ihtiyaç duyar. Finans ekibi, formları oluşturmadan veya gider onay iş akışını yapılandırmadan önce hangi bilgilerin gerekli olduğunu belirlemelidir.

Çoğu onaylayıcının çalışanın ne harcamayı planladığını, işletmenin buna neden ihtiyaç duyduğunu, hangi bütçenin ödeme yapacağını ve talebin politikaya uyup uymadığını bilmesi gerekir. Yönetici iş gerekçesine odaklanabilir. Maliyet merkezi sahibi bütçeyi kontrol eder. Finans ekibi kategori limitlerini, vergi kanıtlarını ve destekleyici belgeleri inceler.

Her talep temel bilgileri tutarlı bir biçimde kaydetmelidir:

• Verginin dahil olup olmadığıyla birlikte toplam tutar ve para birimi
• Seyahat, yazılım, müşteri yemekleri veya ofis ekipmanı gibi gider kategorisi
• Maliyet merkezi ve gerektiğinde proje veya müşteri kodu
• Talep sahibi, departman ve kararın gerektiği tarih
• İş amacı, tedarikçi ve teklif veya makbuz gibi belgeler

Zorunlu alanları gerçek bir karara bağlayın. Aylık 25 dolarlık bir yazılım aboneliği için tedarikçi, tutar, maliyet merkezi ve iş amacı yeterli olabilir. 4.000 dolarlık bir dizüstü bilgisayar alımı için cihazın kullanılacağı kişi, değiştirme nedeni ve varlık talep numarası da gerekebilir. Her talep için tek ve uzun bir form kullanmak kötü veri üretir ve çalışanları zorlar.

Bazı alanlar yalnızca kategori veya tutar bunu gerektirdiğinde görünmelidir. Seyahat taleplerinde varış yeri ve seyahat tarihleri gerekebilir. Müşteri ağırlama giderlerinde katılımcıların adları istenebilir. Belirli bir tutarın üzerindeki bir talep, rakip teklifleri veya tedarikçi seçiminin nedenini gerektirebilir. Koşullu sorular süreci takip etmeyi kolaylaştırır, çünkü çalışanlar formun neden ek bilgi istediğini anlar.

Her bilgi parçasını kimin sağlayacağına karar verin. Talep sahipleri amaç ve tedarikçi gibi bildikleri bilgileri girmelidir. Form, çalışan profilinden departman ve yönetici bilgilerini doldurabilir. Finans ekibi gönderimden sonra politika durumunu veya muhasebe kodlarını ekleyebilir. Böylece çalışanlar doğrulayamayacakları alanlar hakkında tahminde bulunmaz.

Formu oluşturmadan önce listeyi son dönemdeki üç gider talebiyle test edin. Bir onaylayıcı e-postayı açmadan veya ek soru sormadan karar verebiliyorsa talep yeterli bilgiyi içerir. Aksi halde süreç henüz kağıt üzerindeyken eksik alanı ekleyin veya ifadesini netleştirin.

Onay eşiklerini karışıklık yaratmadan haritalayın

Tutar aralıkları şirketin para harcama biçimine uymalıdır. Yıllık yazılım planları satın alan bir ekibin, çalışanların çoğunlukla kilometre, yemek ve küçük malzeme gideri bildirdiği bir işletmeden farklı limitlere ihtiyacı vardır. Başka bir şirketin eşiklerini kopyalamak genellikle iyi sonuç vermez.

İnsanların hatırlayabileceği kısa bir aralık listesi kullanın. Bir departman yöneticisi 500 dolara kadar olan talepleri, finans yöneticisi 501 ile 2.500 dolar arasındaki talepleri, departman başkanı ise daha yüksek tutarları onaylayabilir. Daha az aralık genellikle daha az yönlendirme hatası yaratır.

Her aralığın yanına hesaplama yöntemini yazın. Finans ekipleri çoğu zaman bir kişinin vergi öncesi tutarı, diğerinin ise nihai bedeli kullanması nedeniyle anlaşamaz. Toplamlara satış vergisinin, bahşişlerin, döviz işlem ücretlerinin ve yinelenen ödemelerin dahil olup olmadığını belirtin. 12 aylık bir abonelikte onayın ilk aylık ödeme üzerinden mi yoksa yıllık taahhüdün tamamı üzerinden mi verileceğine karar verin.

Harcama türü de önemlidir. 1.000 dolarlık bir müşteri yemeği ile 1.000 dolarlık bir dizüstü bilgisayar aynı incelemeyi gerektirmeyebilir. Ekipman için BT veya satın alma onayı gerekebilirken normal limit içindeki bir seyahat yalnızca çalışanın yöneticisinin onayını gerektirebilir.

Politika üzerinde anlaşırken basit bir tablo kullanın:

İki kişinin onay vermesi gerektiğinde açık olun. Onayların sırayla mı yoksa aynı anda mı verileceğini ve ödeme öncesinde iki kararın da gerekip gerekmediğini tanımlayın. 1.800 dolarlık bir yazılım talebi önce maliyet merkezi yöneticisine, ardından finans ekibine gidebilir. Kısıtlı bir proje bütçesine kaydedilen 3.000 dolarlık bir talep, çalışanın yöneticisi onay vermiş olsa bile bütçe sahibinin ve finansın onayını gerektirebilir.

Eşik değişikliklerini finans ekibi kontrol etmelidir. İnsanlar form içindeki limitleri değiştirebilir veya sözlü istisnalar yapabilirse iş akışını açıklamak ve denetlemek zorlaşır. Güncel aralıkları tek bir politika belgesinde tutun ve formları buna göre oluşturun.

Sorumluluğu maliyet merkezine göre atayın

Her aktif maliyet merkezinin adı belirlenmiş bir bütçe sahibi olmalıdır. Bu kişi her satın almayı bizzat onaylamak zorunda değildir, ancak çalışanlar ve finans ekibi bu bütçeye yapılan harcamalardan kimin sorumlu olduğunu bilmelidir. «Departman başkanına gönder» gibi bir kural, departmanda birden fazla ekip veya bütçe olduğunda gecikmelere yol açar.

İlk onaylayanı seçmek için talepteki maliyet merkezini kullanın. Bir satış koordinatörü Kuzey Amerika satış maliyet merkezine 450 dolarlık bir etkinlik gideri gönderirse talep önce bu maliyet merkezinin sahibine gider, ardından tutara dayalı kuralları izler. Koordinatörün bütçeden sorumlu satış liderini tahmin etmesi gerekmez.

Sahipliği basit tutun:

• Her aktif maliyet merkezine birincil bir sahip atayın.
• Birden fazla eşit sahip listelemek yerine yedek kapsamı için vekalet kurallarını kullanın.
• Ortak veya şirket genelindeki giderler için ayrı yollar belirleyin.
• Eksik veya etkin olmayan kodlara sahip talepleri finans incelemesine gönderin.

Ortak giderler için belirlenmiş bir yol gerekir. Birden fazla departmanın kullandığı yazılımlar, ortak ofis malzemeleri ve şirket etkinlikleri, talep varsayılan olarak tek bir departmana yönlendirildiğinde anlaşmazlık yaratabilir. Finans ekibi bu giderleri ortak hizmetler sahibine atayabilir, talep sahibinden gideri bölmesini isteyebilir veya bütçe seçilmeden önce talebi inceleyebilir. Yaygın ortak harcama türlerinin her biri için tek bir yaklaşım seçin.

Form artık bulunmayan kodları kabul etmemelidir. Çalışan kapatılmış bir projeyi veya kullanımdan kaldırılmış bir ekip kodunu seçerse talep durmalı ve güncel bir maliyet merkezi istemelidir. Çalışan bir maliyet merkezi seçemiyorsa finans ekibi «maliyet merkezi eksik» gibi bir gerekçeyle talebi almalıdır. Politika izin veriyorsa finans ekibi talebi düzeltme için geri gönderebilir veya geçici bir kod atayabilir.

Maliyet merkezi adı, kodu, birincil sahibi ve durumunun bulunduğu kısa bir sahip listesi tutun. Bütçeler taşındığında, ekipler yeniden düzenlendiğinde veya bir sahip ayrıldığında listeyi güncelleyin. Bir AppMaster uygulamasında yöneticiler bu listeyi veri tablosunda tutabilir ve gönderimleri otomatik olarak yönlendirmek için kullanabilir. Değişikliklerin kontrolü finansta kalır ve talepler artık bütçeyi yönetmeyen birinin gelen kutusunda beklemez.

Vekiller ve izinler için kurallar belirleyin

Bir yönetici izinde, seyahatte veya başka bir role geçiş sürecindeyken onaylar durmamalıdır. Vekalet taleplerin ilerlemesini sağlar, ancak finans ekibinin her kararı kimin ve neden verdiğini görebilmesi için bu kuralın sınırları olmalıdır.

Vekalete yalnızca adı geçen onaylayıcı izin verdiğinde veya yetkili bir finans ya da İK yöneticisi tarafından tanımlandığında izin verin. Vekilin adını, başlangıç tarihini ve bitiş tarihini kaydedin. Süresiz vekalet, eski erişimlerin açık kalması nedeniyle sorun yaratır.

Uygulanabilir bir kural, departman yöneticisinin planlı izin sırasında en fazla 30 gün için tek bir vekil atamasına izin verebilir. Devamsızlık daha uzun sürerse finans atamayı inceler ve yeniler. Böylece vekilin hâlâ doğru yetkiye sahip olup olmadığını teyit etmek için net bir kontrol noktası oluşur.

Onay izini açık tutun

İş akışı, asıl onaylayanı vekil olarak hareket eden kişiyle birlikte göstermelidir. Vekalet dönemini ve onay zamanını kaydedin. Finans veya denetçi bir talebi daha sonra incelediğinde yöneticinin kişisel olarak onay vermediğini ve vekilin işlem yapma iznine sahip olduğunu görebilmelidir.

Asıl onaylayanın adını vekilin adıyla değiştirmeyin. Bu kısayol, özellikle normal harcama düzeninin dışındaki giderlerde anlaşmazlıkların çözümünü zorlaştırır.

Vekilin kendi ekibinden gelen talepler için net bir kural belirleyin. Bazı finans ekipleri vekillerin o ekibin rutin taleplerini onaylamasına izin verir, ancak vekilin kendi giderlerinin başka bir yönetici tarafından onaylanmasını ister. Diğerleri, vekil yöneticinin bağlılık hattındaki tüm talepleri başka bir düzeye taşır. Bir politika seçin ve açıkça yazın.

Vekalet politikası, vekillerin yalnızca belirtilen tarihler arasında adı geçen onaylayıcı adına hareket ettiğini, kendi giderlerini onaylayamayacağını ve normal tutar ve maliyet merkezi kurallarına uyması gerektiğini doğrulamalıdır. Bir yönetici ayrıldığında veya rol değiştirdiğinde finans bir yedek onaylayıcı atamalıdır.

Rol değişiklikleri kısa süreli izinlerden farklı ele alınmalıdır. Bir kişi ayrıldığında onay erişimini hızla iptal edin ve maliyet merkezlerini yeni bir sahibe atayın. Kalıcı bir sahip yoksa finans, bitiş tarihi olan geçici bir yedek belirleyebilir. Talepler, ayrılan bir çalışanın vekiline süresiz olarak yönlendirilmemelidir.

Gecikmeye yol açmadan önce istisna yollarını planlayın

Her gider onay iş akışında normal kurallara uymayan talepler için bir yol bulunmalıdır. Ekranları oluşturmadan önce bu durumları tanımlayın. Aksi halde çalışanlar e-posta gönderir, yöneticiler gayriresmî kararlar verir ve hiç kimse bir talebin neden ilerlediğini açıklayamaz.

Yaygın istisnalar arasında acil seyahat, eksik makbuz, standart limitin üzerindeki talep veya yanlış maliyet merkezine kaydedilmiş bir gider bulunur. Her birini belirsiz bir «özel durum» yerine adlandırılmış bir istisna türü olarak ele alın. Talep sahibi nedeni seçmeli ve gerekli ayrıntıları eklemelidir.

Örneğin bir çalışan, toplantı tarihi değiştiği için yarın bir müşteri ziyaretine rezervasyon yapmak zorunda kalabilir. Talep seyahat planını, aciliyetin kısa açıklamasını ve beklenen toplam maliyeti gerektirebilir. Finans ekibi daha sonra talebi normal zincire göndermek yerine çalışanın yöneticisine ve bir finans incelemecisine yönlendirebilir.

Her istisnaya bir sahip atayın

Her istisnayı kimin onaylayacağına ve hangi kanıtlara ihtiyaç duyacağına karar verin. Eksik makbuz, imzalı bir beyan ve kart işlem kaydı gerektirebilir. Acil satın alma, ekibin normal satın alma yolunu neden kullanamadığını açıklayan bir yönetici notu isteyebilir.

Her geçersiz kılma için nihai kararı, incelemeci adını, tarihi ve nedeni kaydedin. Bu, finans ekibine kullanılabilir bir denetim kaydı sağlar ve tekrarlanan politika sorunlarını belirlemeye yardımcı olur.

Yanıt süresi ve eskalasyon ekleyin

Bir incelemeci uzakta olduğunda veya bildirimi kaçırdığında talepler çoğu zaman bekler. Her istisna için bir yanıt süresi belirleyin. Bu sürenin sonunda iş akışı bir vekile bildirim göndermeli veya adı belirlenmiş bir yedek incelemeciye eskalasyon yapmalıdır.

Acil seyahat için ilk incelemecinin yanıt vermesi adına bir iş günü tanınabilir. İşlem yapmazsa talep vekiline gider. Vekil de dört çalışma saati içinde yanıt vermezse finans ekibi karar vermek üzere talebi alır. Gecikmenin nerede başladığını belirleyebilmesi için asıl incelemeciyi görünür tutun.

Uygulama istisna türünü, kanıtları, geçersiz kılma nedenini ve eskalasyon durumunu saklamalıdır. AppMaster ekiplerin bu alanları modellemesine ve talepleri görsel iş süreçleri üzerinden yönlendirmesine olanak tanır. Böylece çalışanlar meşru istisnalar için açık bir yol izlerken finans ekibi tutarlı kayıtlar tutabilir.

Gerçekçi bir talebi baştan sona inceleyin

Bir pazarlama koordinatörü, yıllık 1.200 dolarlık bir yazılım aboneliği için talep gönderir. Form tedarikçiyi, tutarı, iş amacını, yenileme tarihini ve pazarlama maliyet merkezini sorar. Koordinatör bir tedarikçi teklifi ekler ve aracın kampanya raporlamasını desteklediğini açıklar.

İş akışı bildirimleri göndermeden önce tutarı ve maliyet merkezini okur. Üzerinde anlaşmaya varılan kurallara göre 1.000 ile 2.500 dolar arasındaki satın almalar için maliyet merkezi sahibi ile finans incelemecisinin onayı gerekir. Talep önce pazarlama bütçesi sahibine gider.

Sahip, talebi, maliyet merkezinde kalan bütçeyi ve satın alma nedenini görür. Onaylayabilir, reddedebilir veya bir soruyla geri gönderebilir. Onaylarsa aynı kayıt finans ekibine ulaşır. Finans, aboneliğin politikaya uyup uymadığını, vergi bilgilerinin mevcut olup olmadığını ve tedarikçinin kayıtlarda zaten bulunup bulunmadığını kontrol eder.

İki taraf da onay verirse sistem kararı, onaylayanların adlarını ve zaman damgalarını kaydeder. Koordinatör bir durum güncellemesi alır ve satın alma işlemine devam edebilir. Finans talebi reddederse kayıtta «Mevcut sözleşme sona erene kadar mevcut raporlama aracını kullanın» gibi ret nedeni korunur.

Maliyet merkezi sahibi uzaktayken

Pazarlama sahibi izinliyse vekil yalnızca sahibi önceden vekalet oluşturmuşsa ve vekalet izin tarihleri boyunca aktifse işlem yapar. Vekile pazarlama sahibi adına hareket ettiği bildirilir.

Vekil aynı kararı verebilir, ancak kayıtta hem yetkisi geçerli olan sahibin hem de işlemi yapan kişinin adı görünmelidir. Vekil onay verdikten sonra finans ekibi talebi yine inceler. Vekil kendi giderini onaylayamaz veya daha yüksek bir onay limitini aşamaz.

Talep istisna gerektirdiğinde

Tedarikçi normal inceleme tamamlanmadan ödeme istiyorsa veya satın alma bir politika limitinin dışındaysa koordinatör istisna talep edebilir. Form kısa bir istisna notu ve tedarikçi teklifindeki son tarih gibi kanıtları zorunlu kılmalıdır.

İş akışı daha sonra talebi bu istisnayı onaylamaya yetkili kişiye, çoğu zaman bir finans yöneticisine gönderir. Bu karar normal onayların yerini almaz, onların yanında tutulur. Örneğin: «İstisna onaylandı: etkinlik kaydı cuma günü kapandığı için standart şartlardan önce ödeme yapılmasına izin verildi.»

Bu örnek, sık sık karışıklığa yol açan alanları test eder: tutar limitleri, sahiplik, geçici kapsam ve istisnalar. Her yolun bir sahibi ve kaydedilmiş bir sonucu olmadan talep ekranını oluşturmayın.

Yaygın onay kuralı hatalarından kaçının

Birçok onay iş akışı, bütçe sahipliğini yansıtmak yerine organizasyon şemasını kopyaladığı için başarısız olur. Bir iş unvanı nadiren tüm resmi gösterir. Bir yönetici iki maliyet merkezini yönetebilir, geçici olarak bir bütçenin sahibi olabilir veya yalnızca belirli bir harcama kategorisini onaylayabilir. Onay haklarını «departman başkanı» gibi bir unvana değil, kişiye, maliyet merkezine, kategoriye ve limite bağlayın.

Her talebi finans direktörüne yönlendirmekten kaçının. Bu, rutin satın almalar için kuyruk oluşturur ve finansı darboğaza dönüştürür. Finans ekibi politikayı belirlemeli, olağan dışı riskleri incelemeli ve seçili istisnaları ele almalıdır. Maliyet merkezi sahipleri, üzerinde anlaşılmış limitler dahilindeki olağan harcamaları onaylayabilir. Daha yüksek tutarlar ve kısıtlı kategoriler bir sonraki düzeye ilerler.

İstisna kurallarını e-posta zincirlerinde değil, iş akışında tutun. Bir çalışanın uçuş iptal edildiği için aynı gün otel ayırtması gerekiyorsa talebin görünür bir yolu olmalıdır: nedeni kaydedin, kanıt ekleyin, doğru onaylayana gönderin ve kararı günlüğe yazın.

Birkaç kontrol, karışıklıkların çoğunu önler:

• Onay haklarını yalnızca iş unvanına değil, bütçe sorumluluğuna göre atayın.
• Standart talepler için eşikler, istisnalar için ayrı bir yol belirleyin.
• İzin kapsamını ve her vekaletin süresini tanımlayın.
• Finans direktörü onayını yalnızca gereken tutarlar, kategoriler ve istisnalar için kullanın.
• Talep sahiplerinin kendi nihai onaylayıcılarını seçmesine izin vermeyin.

Son nokta çıkar çatışmalarına karşı koruma sağlar. Talep sahibi giderin hangi maliyet merkezine yazılacağını seçebilir, ancak iş akışı onaylayanı onaylanmış kurallara göre seçmelidir. Satış maliyet merkezine 900 dolarlık müşteri yemeği gönderen bir satış yöneticisi, kendisine yakın yöneticilerden oluşan bir menüye değil, o bütçenin sahibine yönlendirilmelidir.

Kuralları insanların test edip açıklayabileceği bir dille yazın. Örneğin: «5.000 doların üzerindeki talepler için maliyet merkezi sahibi ve finans onayı gerekir. Acil durum nedeniyle sonradan rezerve edilen seyahatler ön onayı atlayabilir, ancak çalışan iki iş günü içinde makbuzları ve yazılı nedeni göndermelidir.»

Formları oluşturmadan önce hızlı bir kontrol yapın

Bir form, belirsiz kuralları düzeltemez. Önerilen onay haritasını finansın, bütçe sahiplerinin ve operasyon çalışanlarının kolayca okuyabileceği kısa bir belgeye dönüştürün.

Sahiplikle başlayın. Her aktif maliyet merkezi için adı belirlenmiş bir onaylayıcı ve izin durumunda kullanılacak bir yedek yol gerekir. Şirket bu rol listesini güncel tutmuyorsa «departman lideri» gibi etiketlerden kaçının. Pazarlama maliyet merkezinin sahibi yoksa taleplerin duracağına, finansa gideceğine veya geçici bir vekile yönlendirileceğine karar verin.

Her eşiği yakın dönemdeki taleplerle karşılaştırın. Son ay veya çeyrekteki küçük bir örneği tutara, maliyet merkezine ve gider türüne göre sıralayarak inceleyin. Bu çalışma, kulağa mantıklı gelen ancak gereksiz onaylar yaratan kuralları ortaya çıkarır. Yazılım yenilemelerinin çoğu 500 dolarlık eşiğin hemen üzerinde kalıyorsa finans, olağan dışı harcamaları incelemek yerine rutin ödemeleri onaylamak için fazla zaman harcayabilir.

Yazılı kuralları zor durumlarla test edin:

• Aktif bir maliyet merkezine kaydedilen ve normal sahibi görevde olan 1.200 dolarlık otel talebi
• Maliyet merkezi sahibinin izninde olduğu sırada gönderilen bir talep
• Daha hızlı bir istisna yolu gerektiren, normal eşik üzerindeki acil bir onarım
• Maliyet merkezi olmayan geçerli bir gider veya güncel sahibi bulunmayan bir maliyet merkezi

Her durum için beklenen sonucu yazın: talebi kimin alacağı, kimin onaylayabileceği, hangi kanıta ihtiyaç duyulacağı ve kimse yanıt vermezse ne olacağı. İki kişi aynı durumu farklı yorumluyorsa kuralın daha fazla çalışılması gerekir.

Ekip formu tasarlamadan önce finans ve bütçe sahiplerinden belgeyi onaylamalarını isteyin. Onayları yalnızca metni değil, tutarları, yönlendirme sırasını, vekil limitlerini ve istisna yetkisini de kapsamalıdır. Daha sonraki değişiklikler için açık bir referans olması amacıyla onaylanmış sürümü iş akışı geliştirmesinin yanında tutun.

İş akışını üzerinde anlaşılmış kurallardan oluşturun

Finans yönlendirme haritasını onayladıktan sonra her kuralı uygulamanın saklayabileceği ve işleyebileceği verilere dönüştürün. Bir talep; tutar, para birimi, maliyet merkezi, gider türü, talep sahibi, iş gerekçesi, makbuz ve tarih gibi alanlara ihtiyaç duyar. Çalışanların ayrıca net durumları görmesi gerekir: Taslak, Gönderildi, Yönetici bekleniyor, Finans bekleniyor, Onaylandı, Reddedildi ve Düzeltme gerekiyor.

Politikayı ekran düzeninden ayrı tutun. 500 dolarlık eşiği 750 dolara değiştirmek veya yeni bir maliyet merkezi sahibi atamak, her formu yeniden oluşturmak yerine bir kuralı değiştirmek anlamına gelmelidir.

Gönderim ekranından önce yönlendirmeyi oluşturun

Önce yönlendirme koşullarını oluşturun. 250 doların altındaki bir talep maliyet merkezi yöneticisine gidebilir. 250 ile 2.000 dolar arasındaki talep bu yöneticiyle birlikte finansın onayını gerektirebilir. 2.000 doların üzerindeki bir talep ayrıca departman başkanına gidebilir. Müşteri ağırlama giderleri her tutarda makbuz ve finans incelemesi gerektirebilir.

Finans çalışanları bir kuralı açtığında uygulamanın neden belirli bir onaylayanı seçtiğini anlayabilmelidir. AppMaster'da ekipler; talebi kaydeden, zorunlu alanları kontrol eden, maliyet merkezi sahibini bulan, tutarı değerlendiren ve uygun onay görevlerini oluşturan görsel iş süreçleri kurabilir. Rol tabanlı erişim, her onaylayanın yalnızca görmesi gereken taleplere erişmesini sağlar.

Gönderim ekranını mantık sabitlendikten sonra oluşturun. Yönlendirme kurallarının ve finans incelemelerinin ihtiyaç duyduğu bilgileri ve ilgili belgeleri toplayın. Gereksiz sorular çalışanları yavaşlatır ve çoğu zaman tutarsız yanıtlara yol açar.

İnsanların gerçekten gönderdiği talepleri test edin

Yayınlamadan önce finans ekibi uygulamada gerçekçi durumları test etmelidir:

• Normal bir işletme maliyet merkezine kaydedilen 90 dolarlık yazılım aboneliği
• Yönetici ve finans incelemesi gerektiren 600 dolarlık otel gideri
• Ek bir onay gerektiren 3.500 dolarlık ekipman talebi
• Normal onaylayıcı görevde yokken gönderilen bir talep
• Finansın düzeltme için geri gönderdiği, makbuzu eksik bir talep

Her testte atanan onaylayanı, talep sahibinin durumunu, hatırlatma zamanını ve denetim kaydını kontrol edin. Finans ekibi yönlendirmeyi bir veya iki cümleyle açıklayamıyorsa çalışanlar bu kurala bağlı hale gelmeden önce kuralı basitleştirin.

Testten sonra iş akışını yayınlayın ve talep sahiplerine görecekleri durumlar hakkında kısa bir rehber sunun. Açık gider onay kuralları, birinin gelen kutusundaki gizli kararlar olmaktan çıkar ve öngörülebilir adımlara dönüşür.