Satın alma talepleri e-postada bekliyor, masraf formları eksik belge nedeniyle geri dönüyor, teklif onayları ise yöneticilerin yoğunluğu yüzünden günlerce açılmıyor. Pek çok şirkette sorun, araç eksikliği değil; kuralların dağınık olması, akışların görünmemesi ve sorumlulukların kişilere bağlı ilerlemesi. Onay süreci otomasyonu, bu dağınık yapıyı kayıt altına alır, kuralları sisteme taşır ve bekleme sürelerini ölçülebilir hale getirir.

İyi kurgulanmış bir yapı, yalnızca “formu dijitale taşımak” anlamına gelmez. Talebin türüne göre rota belirler, bütçe ve tutar eşiklerini devreye sokar, eksik alanları daha ilk adımda tespit eder, SLA sürelerini izler ve ERP, muhasebe ya da CRM ile veri alışverişi yapar. Buradaki amaç nettir: gereksiz beklemeyi azaltmak ve onay sürecini kontrol edilebilir hale getirmek.

Bu yazıda, satın alma, masraf ve teklif süreçlerinde otomasyonun nasıl kurulacağını; hangi kuralların sisteme tanımlanması gerektiğini; 24 saat, 48 saat gibi servis seviyelerinin nasıl belirleneceğini ve hangi entegrasyonların gerçek fark yarattığını ele alıyoruz.

Onay süreci otomasyonu nedir, hangi problemi çözer?

En basit haliyle onay süreci otomasyonu, bir talebin oluşturulmasından nihai onaya kadar geçen adımların yazılım tarafından yönetilmesidir. Sistem; kim onaylayacak, hangi koşulda bir üst seviyeye çıkılacak, hangi belgeler zorunlu olacak, ne kadar sürede yanıt gelmezse eskalasyon tetiklenecek gibi kuralları uygular.

Manuel düzende en sık karşılaşılan üç gecikme tipi şunlardır: yanlış kişiye giden talepler, eksik bilgi nedeniyle geri dönen kayıtlar ve tatil ya da yoğunluk nedeniyle sahipsiz kalan işler. Örneğin 25.000 TL üzeri satın alma taleplerinin departman yöneticisine değil, finans onayına düşmesi gerekiyorsa bu kural e-postada hatırlatmayla değil, sistem kuralıyla işlemelidir.

Buradaki kazanım yalnızca hız değildir. Her adım zaman damgasıyla kaydedildiği için darboğazlar görünür hale gelir. “Teklifler neden geç çıkıyor?” sorusu tahminle değil, örneğin ortalama 31 saat bekleme süresi yaratan belirli bir onay adımı üzerinden yanıtlanır.

Önce mevcut akışı çıkarın: 1 haftalık haritalama çoğu projede yeterlidir

Başarılı bir dijitalleştirme projesi ekran tasarımıyla değil, süreç haritalamayla başlar. Uygulamada 3 ila 5 iş günü içinde mevcut durum net şekilde ortaya çıkarılabilir. Her akış için şu veri seti toplanmalıdır:

  • Talebi kim başlatıyor?
  • Hangi alanlar zorunlu?
  • Kaç onay seviyesi var?
  • Tutar, departman, lokasyon ya da tedarikçi tipine göre rota değişiyor mu?
  • En sık geri dönüş nedeni ne?
  • Ortalama bekleme süresi kaç saat ya da kaç gün?

Örnek bir satın alma akışında haritalama çıktısı şöyle olabilir: Talep sahibi formu doldurur, 10.000 TL altı talepler bölüm yöneticisine gider, 10.000 TL ile 50.000 TL arası için finans kontrolü eklenir, 50.000 TL üzeri satın alma komitesine düşer. Tedarikçi kartı yoksa ERP’de yeni kayıt açılmadan siparişe geçilmez. Bu netlik sağlanmadan yapılan otomasyon, dağınıklığı yalnızca daha hızlı taşır.

İlk ölçümler neden kritik?

Başlangıç verisi yoksa iyileşme de kanıtlanamaz. En azından son 30 güne bakın. Kaç talep açıldı, yüzde kaçı geri döndü, kaç tanesi SLA dışına çıktı? Bu metrikler hem teknik tasarımı hem de önceliklendirmeyi belirler.

Satın alma akışında otomasyon: tutar eşiği, bütçe kontrolü, tedarikçi doğrulama

Satın alma sürecindeki gecikmelerin büyük bölümü üç noktada oluşur: eksik talep bilgisi, bütçe kontrolünün geç yapılması ve tedarikçi verisinin dağınık olması. Otomasyon kurgusunda bu alanlar daha ilk günden ele alınmalıdır.

İyi bir satın alma formu serbest metin ağırlıklı olmamalıdır. Talep türü, maliyet merkezi, beklenen teslim tarihi, para birimi, teklif dokümanı ve varsa sözleşme eki zorunlu alan olarak tanımlanır. Form gönderildiği anda sistem iki temel kontrol yapabilir: bütçe kalemi uygun mu, tedarikçi sistemde aktif mi?

Somut bir senaryo düşünelim. İstanbul ve Ankara ofisleri için iki ayrı maliyet merkezi kullanan bir şirkette 18.500 TL tutarında dizüstü ekipman talebi açılıyor. Otomasyon motoru şu sırayı izler:

  1. Maliyet merkezi doğrulaması
  2. ERP’den güncel bütçe bakiyesi kontrolü
  3. 18.500 TL eşiğine göre finans onayının devreye alınması
  4. Tedarikçi vergi numarası ve IBAN format kontrolü
  5. 24 saat içinde işlem yapılmazsa yedek onaylayıcıya atama

Bu yapı, satın alma ekibinin “eksik evrak” ve “yanlış rota” kaynaklı geri dönüşlerini ciddi ölçüde azaltır. Ayrıca denetim açısından da güçlüdür; kim, ne zaman, hangi belgeyle onay verdiği kayıt altındadır.

Masraf onaylarında mobil deneyim belirleyicidir

Masraf süreçlerinde gecikme çoğu zaman ofis dışında başlar. Çalışan fişi saklar ama sisteme geç girer. Yöneticinin önüne toplu kayıt gelir. Muhasebe ise KDV oranı ya da belgenin okunurluğu nedeniyle iadeye düşer. Bu akış masaüstü mantığıyla kurulduğunda doğal olarak yavaşlar.

Masraf otomasyonunda mobil giriş temel bir gereksinimdir. Kullanıcı fişi ya da faturayı telefondan yükleyebilmeli, OCR ile tarih-tutar-belge no ayrıştırılmalı, belge tipi seçildiğinde ilgili vergi alanları otomatik gelmelidir. OCR her zaman kusursuz çalışmayabilir; bu yüzden kritik alanlarda kullanıcı doğrulaması bırakmak daha güvenlidir.

Örneğin günlük konaklama limiti 4.000 TL olan bir seyahat politikasında sistem, limit aşımı olduğunda açıklama zorunlu alanını açabilir. Hafta sonu oluşan taksi masrafında proje kodu yoksa kayıt beklemeye alınabilir. 7 gün içinde belge yüklenmeyen taslaklar için hatırlatma gönderilebilir. Buradaki fark basittir: kural sonradan kontrol edilmez, veri girişinde işletilir.

Masraf akışında kontrol noktaları

  • Belge yüklemeden gönderime izin vermeme
  • Şirket politikasına göre günlük veya kategori bazlı limit kontrolü
  • Aynı tutar, tarih ve belge numarası ile mükerrer kayıt tespiti
  • Muhasebe sistemine fişleştirme için standart veri aktarımı

Teklif onaylarında hız için paralel onay modeli kullanın

Teklif süreçlerinde kayıp çoğu kez sıra bağımlı onaylardan kaynaklanır. Satış ekibi fiyat çalışmasını bitirir, önce bölge müdürü bakar, ardından finans marjı kontrol eder, sonra hukuk sözleşme maddelerine döner. Her adım bir öncekinin tamamlanmasını beklerse 2 saatlik iş 2 güne yayılabilir.

Bu noktada çözüm, uygun adımlarda paralel onay modelini kullanmaktır. Örneğin 1 yıllık SaaS teklifinde indirim oranı yüzde 12’yi aşıyorsa finans ve satış direktörü aynı anda devreye girebilir. Standart sözleşme şablonu kullanılıyorsa hukuk adımı otomatik olarak pas geçilebilir; özel madde eklenirse yeniden zorunlu hale gelebilir.

Teknik kural seti örneği:

if discount_rate > 12 then require(finance_approval)
if contract_template == "standard" then skip(legal_review)
if annual_value >= 250000 then require(gm_approval)
set_sla("finance_approval", "8h")

Bu tür kurallar düşük kodlu araçlarda da, özel geliştirilen workflow motorlarında da uygulanabilir. Asıl mesele araç değil, karar mantığının açık ve sürdürülebilir olmasıdır.

Entegrasyon olmadan otomasyon yarım kalır

Onay ekranı tek başına yeterli değildir. Süreçler pek çok şirkette ERP, muhasebe, insan kaynakları, e-posta, kimlik yönetimi ve doküman arşivi ile temas eder. Manuel veri taşıma sürüyorsa gecikme başka bir noktadan geri döner.

Pratikte en yaygın entegrasyonlar şunlardır:

  • ERP entegrasyonu: maliyet merkezi, bütçe, tedarikçi kartı, sipariş numarası
  • Muhasebe entegrasyonu: masraf fişleri, hesap planı, KDV kodları
  • CRM entegrasyonu: teklif tutarı, müşteri segmenti, satış fırsatı bilgisi
  • SSO/LDAP: rol bazlı yetki ve organizasyon ağacı
  • E-posta ve Teams/Slack bildirimleri: anlık onay çağrısı ve eskalasyon

Örneğin yöneticinin izinli olduğu 5 günlük dönemde sistem, İK verisinden vekalet bilgisini okuyup onayı otomatik biçimde yedek kişiye atayabilir. Bu, küçük görünen ama beklemeyi doğrudan azaltan bir entegrasyondur.

SLA, eskalasyon ve loglama: gecikmeyi gerçekten bunlar azaltır

Birçok projede form ve onay butonları tamamlanır; ancak SLA ve eskalasyon kuralları sona bırakılır. Oysa gecikmeyi azaltan asıl mekanizma buradadır. Her adım için hedef süre tanımlanmalıdır: bölüm yöneticisi 8 saat, finans 24 saat, hukuk 2 iş günü gibi.

Süre dolduğunda ne olacağı da açık biçimde belirlenmelidir. Hatırlatma mı gidecek, üst yöneticiye bildirim mi düşecek, yoksa yedek onaylayıcı mı devreye girecek? Kural yoksa sistem sadece dijital bir bekleme odasına dönüşür.

Loglama da aynı derecede önemlidir. En az şu olaylar kayıt altına alınmalıdır: oluşturma zamanı, alan değişiklikleri, yorumlar, ret nedeni, yeniden gönderim, onay zamanı, IP ya da cihaz bilgisi. Bu kayıtlar hem iç denetim hem de kök neden analizi açısından değerlidir.

Uygulama planı: 6 ila 10 haftada çalışan ilk sürüm mümkün

Kapsam kontrollü tutulursa ilk canlı sürüm çoğu kurumda 6 ila 10 hafta içinde alınabilir. Özellikle tek süreçle başlamak riski azaltır. Önerilen sıra genelde satın alma ya da masraf akışıdır; çünkü hacim yüksektir ve geri dönüş etkisi kısa sürede görünür.

Örnek proje planı

  • 1. hafta: süreç keşfi, mevcut akış haritası, rol matrisi
  • 2.-3. hafta: ekranlar, kural seti, entegrasyon tasarımı
  • 4.-6. hafta: geliştirme, test verisi, kullanıcı kabul testleri
  • 7. hafta: pilot canlı kullanım, 20-30 kullanıcıyla ölçüm
  • 8.-10. hafta: iyileştirme, ek senaryolar, raporlama panelleri

Pilot aşamada tüm kurumu devreye almak yerine belirli bir departmanla başlamak daha sağlıklıdır. Örneğin yalnızca iç satın alma talepleri ya da yalnızca yurtiçi masraflar ilk dalga olabilir. İkinci aşamada teklif ve sözleşme akışları eklenir.

Başarıyı hangi metriklerle ölçmelisiniz?

Onay süreci otomasyonunun başarısı, “kullanıma alındı” ifadesiyle değil, operasyonel verilerle anlaşılır. En az 4 temel metriği haftalık olarak izleyin:

  • Talep başına ortalama tamamlanma süresi
  • İlk seferde doğru tamamlama oranı
  • SLA ihlali sayısı
  • Ret ve yeniden gönderim nedenleri

Örneğin satın alma akışında ortalama çevrim süresi 72 saatten 29 saate inmişse sistemin gerçek etkisi görünür hale gelir. Masraf sürecinde mükerrer kayıt tespiti artmışsa bu da ayrı bir kazanımdır; çünkü yalnızca hız değil, kontrol kalitesi de yükselmiştir.

Kapanışta kritik nokta şu: onay süreçlerini dijitalleştirmek bir form projesi değildir. Kural motoru, entegrasyon, mobil kullanım, SLA yönetimi ve denetlenebilir kayıt yapısı birlikte ele alındığında gecikmeler belirgin biçimde düşer. Şirketinize uygun kuralları sade bir şekilde modelleyip küçük bir kapsamla başlamak, büyük ve dağınık bir dönüşüm girişiminden çoğu zaman daha iyi sonuç verir.