İş Akışı Otomasyonu Nedir? Onay Rehberi

Satın alma onayı, izin talebi, teklif onayı ve form süreçleri hâlâ e-posta zincirlerinde ve kâğıt formlarda kayboluyorsa, iş akışı otomasyonu tam bu yükü azaltmak için kullanılır. Kimde beklediği belirsiz onaylar, geciken imzalar ve kopyalanmış dosyalar hem zaman hem güven kaybı yaratır. Bu rehber; workflow tasarımını, tetikleyici–kural–bildirim mantığını ve hangi süreçlerin önce otomatikleştirileceğini KOBİ, e-ticaret ve kurumsal ekipler için pratik bir çerçevede anlatır.

İş akışı otomasyonu nedir?

İş akışı otomasyonu, bir işin başlama anından tamamlanmasına kadar geçen adımların kurallarla tanımlandığı, onay basamaklarının sırayla ilerlediği ve bildirimlerin otomatik gittiği dijital süreç yönetimidir. Amaç, insanı ortadan kaldırmak değil; tekrarlayan aktarımları, takip e-postalarını ve “dosya kimde?” sorularını azaltmaktır.

Klasik bir satın alma örneğinde form doldurulur, e-posta ile yöneticiye iletilir, yönetici muhasebeye yönlendirir, muhasebe bütçe kontrolü yapar. Her aktarımda format bozulur, ekler kaybolur, süre uzar. Otomatik akışta form kaydı oluşur, tutara göre onaycı belirlenir, redde gerekçe istenir, onay sonrası ilgili birim bilgilendirilir. Tüm geçmiş tek kayıtta kalır.

RPA ve BPM ile farkı netleştirin

Bu üç kavram sık karışır; işletme ihtiyacına göre rolü farklıdır.

• İş akışı otomasyonu: İnsan onayı, form ve departman geçişlerini kurallı hale getirir. Odak “süreç akışı”dır.
• RPA (robotik süreç otomasyonu): Ekran üzerinde tıklama, kopyalama, veri aktarma gibi tekrarlayan görevleri botla yürütür. Odak “işlem tekrarı”dır.
• BPM (iş süreçleri yönetimi): Uçtan uca süreç modelleme, iyileştirme ve yönetişimdir; otomasyon bunun bir parçası olabilir.

Pratik ayrım: Onay zinciri ve durum takibi istiyorsanız iş akışı otomasyonu yeterlidir. Eski bir ekrandan veri çekip başka sisteme yapıştırmak ana dertse RPA devreye girer. Kurumsal süreç mimarisi ve sürekli iyileştirme hedefleniyorsa BPM çerçevesi gerekir. Birçok KOBİ için önce onay ve form akışını netleştirmek en hızlı kazanımı verir.

Hangi kurumsal süreçler otomasyona uygundur?

Her süreci aynı anda dijitale taşımak ekibi yorar. Önce tekrarlayan, kurallı ve net onay basamakları olan işleri seçin.

Öncelikli aday süreçler

• Satın alma ve teklif onayı: Tutar eşikleri, bütçe kodu, satın alma birimi ve finans onayı.
• İzin ve devamsızlık talepleri: Yöneticiden İK’ya aktarım, bakiye kontrolü, onay/red bildirimi.
• Teklif ve sözleşme taslağı onayı: Satışın hazırladığı metnin hukuk veya yönetici kontrolünden geçmesi.
• Müşteri şikâyeti ve iade formları: Kayıt, öncelik, ilgili birime atama, çözüm süresi takibi.
• İşe alım ve çalışan talebi: Pozisyon talebi, bütçe onayı, İK süreci.
• Kampanya / içerik yayın onayı: Pazarlama taslağının marka veya yöneticiden geçmesi.

Önce otomatikleştirmeyin

Kuralları belirsiz, her seferinde istisna üreten veya kararın tamamen yoruma bağlı olduğu süreçleri ilk dalga dışı bırakın. Otomasyon, zayıf süreci hızlandırırsa karmaşayı da hızlandırır. Önce “kim, neye göre, ne zaman karar verir?” sorusunu yazıya dökün.

Tetikleyici, koşul, onay basamağı ve bildirim yapısı

Sağlam bir akış dört yapı taşıyla kurulur. Bunları net tanımlamadan panelde alan açmak, eksik süreç üretmeye yol açar.

1. Tetikleyici (ne zaman başlar?)

• Form gönderildiğinde
• Belirli bir kayıt durumu değiştiğinde (ör. “taslak” → “onay bekliyor”)
• Belirli bir tarihte veya periyotta (hatırlatma, yenileme)
• Harici bir olayda (yeni sipariş, stok eşiği, destek bileti)

2. Koşul ve kurallar (hangi yolu izler?)

Örnek: Satın alma tutarı 10.000 TL altındaysa birim yöneticisi yeterlidir; üstündeyse finans ve genel müdür basamakları devreye girer. Kategori “BT ekipmanı” ise bilişim birimi ek onaycı olur. Koşullar mümkün olduğunca nesnel alanlara bağlansın: tutar, kategori, departman, müşteri tipi, stok durumu.

3. Onay basamakları (kim ne yapar?)

• Sıralı onay: A onaylamadan B’ye gitmez.
• Paralel onay: İki birim aynı anda bakabilir; hepsi tamamlanınca ilerler.
• Tek onaycı veya vekil: Onaycı izindeyse yedek kişi devreye girer.
• Red ve revizyon: Redde zorunlu gerekçe; “düzeltmeye geri gönder” yolu açık olsun.

4. Bildirim ve hatırlatma

Onay bekleyen kişiye anında bildirim, belirli süre geçince hatırlatma, nihai karar sonrası talep sahibine özet mesaj. Bildirim az ve anlamlı olmalı; her küçük durum değişikliğinde herkese mail atmak gürültü yaratır.

İyi kural seti: tetikleyici net, koşul ölçülebilir, onaycı rol bazlı, bildirim seyrek ama zamanında.

Departmanlar arası aktarımı bozmadan tasarım adımları

Akış tasarımının en zor kısmı yazılım değil, el değiştiren sorumlulukların netliğidir. Aşağıdaki sıra, “IT kurdu, operasyon kullanmadı” riskini azaltır.

1. Mevcut işi olduğu gibi yazın. Kim başlatır, hangi belge istenir, kim imzalar, redde ne olur? Gerçek hayattaki kısayolları da not edin.
2. Rolleri unvan değil sorumlulukla tanımlayın. “Ahmet Bey” yerine “Satın Alma Onaycısı”, “Bütçe Kontrolü” gibi roller kullanın; personel değişince akış bozulmasın.
3. Gerekli alanları minimuma indirin. Her alan bir sürtünme noktasıdır. Karar için gerçekten gereken veriyi sorun.
4. SLA ve bekleme sürelerini ekleyin. 48 saat onaylanmayan talepler hatırlatılsın veya üst basamağa çıksın.
5. Pilot bir süreçle başlayın. Tek departman, tek form; iki hafta kullanım sonrası kuralı sadeleştirin.
6. Erişim ve görünürlüğü ayırın. Herkes her alanı görmesin; muhasebe bütçe notunu, İK kişisel veriyi, satış müşteri notunu kendi yetkisinde görsün.

Departman geçişinde “elde tutma” hissi kritiktir: Bir kayıt bir birime atandığında o birim net görev görür; önceki birim de durumun “finans kontrolünde” olduğunu izleyebilir. Şeffaflık, arama-sorma yükünü düşürür.

Hazır yazılım paneliyle akış kurma senaryoları

Özel geliştirme her zaman gerekmez. Form, durum alanı, rol bazlı onay ve bildirim sunan hazır panellerle birçok işletme ilk otomasyonunu kısa sürede kurabilir. HazırSoft tarafında da süreç odaklı hazır yazılımlar ve katalogdaki çözümlerle operasyonel akışları tek panelde toplamak mümkündür; seçim yaparken onay basamağı, rol/yetki ve bildirim esnekliğine bakın.

Senaryo A: Küçük e-ticaret – iade onayı

Müşteri iade formu doldurur. Tutar veya ürün kategorisine göre depo veya müşteri hizmetleri inceler. Onaylanırsa kargo iade etiketi süreci başlar; redde müşteriye gerekçeli mesaj gider. Amaç, WhatsApp ve e-posta karmaşasını tek kayda indirmek.

Senaryo B: KOBİ – satın alma talebi

Personel talep formunu açar, kalem ve tutarı girer. Eşik altı talepler birim yöneticisinde biter; eşik üstü finansa düşer. Onay sonrası satın alma birimi tedarikçi tekliflerini ekler. Tüm geçmiş tek talep kaydında arşivlenir.

Senaryo C: Kurumsal – teklif / sözleşme taslağı

Satış temsilcisi teklif dosyasını yükler. Tutar ve indirim oranına göre satış müdürü ve gerekirse finans onaylar. Onaylanınca teklif “gönderilebilir” statüsüne geçer. Böylece “hangi sürüm gitti?” tartışması azalır.

Panel seçerken demo ortamında şu soruları test edin: Vekil onaycı atanabiliyor mu? Red sonrası revizyon döngüsü var mı? Geçmiş log dışa aktarılabiliyor mu? Mobil bildirim veya e-posta şablonları yönetilebiliyor mu? İhtiyaca uygun çözümü hızla taramak için HazırSoft yazılım kataloğu ve yazılım sihirbazı da başlangıç noktası olabilir.

Ölçüm: süre, hata oranı ve şeffaflık metrikleri

Otomasyonun faydası “kurduk” demekle bitmez. Basit ama düzenli ölçülen göstergeler, bir sonraki iyileştirmeyi gösterir.

• Ortalama tamamlanma süresi: Talep açılışından nihai onaya kadar geçen süre.
• Basamak bekleme süresi: Hangi onaycıda en çok birikim oluşuyor?
• Geri dönüş (revizyon) oranı: Eksik bilgi nedeniyle kaç talep başa döndü?
• Kural dışı müdahale: Kaç kayıt manuel atlandı veya sistem dışı e-posta ile “acil” işlendi?
• Görünürlük: Talep sahibi durumunu sormadan görebildi mi? (Sorgu çağrılarının azalması dolaylı göstergedir.)

İlk ayda hedefi abartmayın. “Satın alma onayını e-postadan panele taşımak ve ortalama bekleme süresini görünür kılmak” yeterli bir başlangıçtır. Metrikleri ekiple paylaşın; cezalandırma aracı değil, darboğaz bulma aracı olsun.

Küçük ekiplerde abartısız başlama planı

Beş-on kişilik ekiplerde dev BPM projesi gerekmez. Aşağıdaki 30 günlük çerçeve gerçekçidir.

1. 1. hafta – Tek süreç seçin. En çok e-posta üreten onay işi hangisi? Genelde izin veya satın alma talebi çıkar.
2. 2. hafta – Kağıt akışı yazın. Tek sayfada: tetikleyici, alanlar, onaycılar, red yolu. Ekiple 30 dakikada doğrulayın.
3. 3. hafta – Panelde kurun ve pilotlayın. Sadece o süreç, sadece gönüllü kullanıcı grubu. Yan kanalları (paralel e-posta) bilinçli kapatın.
4. 4. hafta – Kuralı sadeleştirin. Kullanılmayan alanları silin, gereksiz onaycıları çıkarın, hatırlatma süresini ayarlayın. Sonra ikinci sürece geçin.

Kontrol listesi:

• Süreç sahibi tek kişi mi atandı?
• Rol tanımı kişi adından bağımsız mı?
• Red ve revizyon yolu tanımlı mı?
• Vekil onaycı senaryosu var mı?
• Minimum zorunlu alan seti net mi?
• Durum etiketleri sade mi (Bekliyor / Onaylandı / Reddedildi / Revizyon)?
• Haftalık 15 dakikalık metrik bakışı planlandı mı?

Sık yapılan hatalar ve kaçınma yolları

• Her şeyi otomatikleştirmek: Önce bir akışta ustalaşın.
• Fazla onay basamağı: Riskle orantısız imza zinciri süreci felç eder.
• Bildirim selı: Sadece aksiyon gerektiren olaylarda haber verin.
• Gölge süreç: Panel varken hâlâ WhatsApp onayı almak veri bütünlüğünü bozar.
• Eğitim eksikliği: Beş dakikalık ekran kaydı bile benimseme oranını yükseltir.

İş akışı otomasyonu, doğru kurgulandığında onayları hızlandırır, sorumluluğu netleştirir ve denetlenebilir bir kayıt bırakır. E-ticaret operasyonundan kurumsal satın almaya kadar ortak nokta aynıdır: önce süreci sade yazın, sonra paneli o sade hale uydurun. İhtiyacınıza uygun hazır çözümleri incelerken yazılım kategorisinden form, onay ve bildirim yeteneklerini karşılaştırabilir; kendi öncelik listenize göre pilot süreci bir hafta içinde başlatabilirsiniz.