Yazılımda Onay Akışı Nasıl Kurulur? Limit ve Vekâlet

Onay akışı, bir kaydın oluşturulduğu anda değil, yetkili kişi onayladıktan sonra geçerli hâle gelmesini sağlayan kural kümesidir. Yazılımda kurmak için üç soruyu yazılı cevaplamak yeterlidir: hangi belge onaya girer, kaç kademe onay ister, onaylayacak kişi masasında değilken yetki kime geçer.

Onay akışı ile rol ve yetki yönetimi aynı şey değildir. Yetki kim hangi ekranı açar, hangi kaydı değiştirir sorusunu; onay akışı değiştirilen kayıt ne zaman gerçek olur sorusunu cevaplar. İkisi tek tabloya sıkıştırıldığında iki sonuçtan biri çıkar: onayı olmayan bir iskonto faturaya yansır ya da en küçük kayıt bile yönetici onayı bekleyip iş durur.

Hangi belge onaya girer, hangisi girmez

Her kaydı onaya sokan sistem kısa sürede şuna dönüşür: onay kuyruğu şişer, kuyruk okunmadan toplu onaylanır ve onay kaydı yalnızca görüntüde kalır. Onay, gerçekten geri alınması pahalı olan kayıtlar için ayrılır.

Belgeyi onaya alıp almama kararında şu ölçütler işe yarar:

• Geri alınabilirlik: Kayıt yanlışsa düzeltmek bir tuş mu, yoksa müşteriyi arayıp özür dilemek mi gerekiyor?
• Dışarıya çıkan kayıt: Teklif, fatura, iade, kargo talimatı gibi şirket dışına giden belgeler onaya en yakın gruptur.
• Para etkisi: Fiyat, iskonto, vade, masraf gibi alanlar değişiyorsa onay anlamlıdır.
• Fiziksel etki: Sayım farkı, hurda çıkışı, depo transferi gibi kayıtların sonucu rafta görülür.
• Sıklık: Günde yüzlerce kez oluşan bir kayıt için onay değil, sonradan örnekleme ve sapma raporu daha gerçekçidir.

Bu listeden geçmeyen kayıtlar onaysız ilerler; kontrol ihtiyacı varsa onay yerine iz kaydı ve rapor kullanılır.

Kademe, limit ve onay matrisi

Kademe sayısı belge türüne ve limite göre değişir. Limit değerlerini yazılım değil şirket belirler; yazılımın işi limiti bir ekrandan düzenlenebilir hâle getirmek, koda gömmemektir. Koda gömülü limitte her değişiklik geliştirme talebine, her geliştirme talebi de beklemeye dönüşür.

Matris kurulurken iki hata sık görülür. Birincisi, talebi oluşturan kişinin kendi talebini onaylayabilmesi: bu, akışın tamamını anlamsız kılar ve yazılımda tek bir kuralla engellenir. İkincisi, zincirin tek isme bağlanması: o kişi izne çıktığında bütün şirket bekler.

Vekâlet: onaylayacak kişi masasında değilken

Onay akışının en çok tıkandığı yer izin, seyahat ve rapor günleridir. Çözüm, onayı başkasına şifreyle devretmek değil, yazılımda tanımlı vekâlettir. Vekâlet üç alanla kurulur: kimden, kime, hangi tarih aralığında. Dördüncü alan kapsamdır: bütün belgeler mi, yalnızca limit altı belgeler mi?

Vekâletle atılan onayda iz kaydı iki ismi birlikte tutar: onayı fiilen veren vekil ve yerine onay verdiği kişi. Tek isim tutulursa sonradan bakıldığında kararı kimin verdiği tartışma konusu olur. Vekâletin bitiş tarihi zorunlu alandır; süresiz vekâlet, kalıcı yetki devrinin adı konmamış hâlidir.

Onaylandıktan sonra kayıt değişirse

Onaylanmış bir kaydın alanları serbestçe değiştirilebiliyorsa onayın bilgi değeri yoktur. Uygulanabilir kural şudur: kritik alanlardan biri değişince onay otomatik düşer ve belge yeniden kuyruğa girer. Kritik alan listesi her belge türü için ayrı yazılır; satın alma talebinde miktar, birim fiyat, tedarikçi ve teslim tarihi kritiktir, açıklama alanındaki yazım düzeltmesi değildir.

Bunun yanında ikinci bir kural gerekir: onay anındaki kayıt sürümü saklanır. Onaylanan hâl görülmeden, sonradan yapılan değişikliğin ne olduğu anlaşılmaz. Sürüm saklamak, onay akışını denetlenebilir yapan asıl ayrıntıdır.

Bekleyen işler, hatırlatma ve tıkanma

Onay akışı kurulan her sistemde iki ekran şarttır. Birincisi onaylayacak kişinin bekleyen onaylar listesi; ikincisi yöneticinin en uzun bekleyen belgeler raporu. İkinci ekran olmadan tıkanma ancak müşteri şikâyetiyle fark edilir.

Bildirim yardımcı olur ama akışı kurtarmaz; e-posta okunmazsa belge yine bekler. Bu yüzden zaman aşımı kuralı tanımlanır: belirli süre bekleyen talep bir üst kademeye yükselir ya da talep sahibine geri döner. Hangisi olacağı şirketin kararıdır; yazılımın şart koştuğu tek şey belgenin sahipsiz kalmamasıdır.

Reddetme de akışın parçasıdır. Ret gerekçesi zorunlu alan olmalı ve talep sahibine görünmelidir; gerekçesiz ret, aynı talebin birkaç gün sonra aynı şekilde geri gelmesine yol açar.

Kısa kontrol listesi

1. Onaya giren belge türleri yazılı mı, yoksa kişiye göre mi değişiyor?
2. Limitler ekrandan düzenlenebiliyor mu, kodda mı duruyor?
3. Talebi oluşturan kişi kendi talebini onaylayabiliyor mu?
4. Her kademenin tanımlı bir vekili ve vekâletin bitiş tarihi var mı?
5. Kritik alan değişince onay düşüyor mu, onay anındaki sürüm saklanıyor mu?
6. Bekleyen ve tıkanan belgeler tek ekrandan görülüyor mu?
7. Ret gerekçesi zorunlu mu?

KAV Yazılım, özel yazılım ve entegrasyon projelerinde onay akışını bu başlıklar üzerinden kurar; belge türü ve limit tanımları şirketin kendi ekranından yönetilir.