Ekranlardan Önce Onay Matrisi Tasarımı: Kuralları Haritalayın

Ekranlar açık bir matris olmadan neden başarısız olur

Düzgün görünen bir ekran bile dağınık bir süreci saklayabilir. Onay mantığı önce tanımlanmazsa, insanlar Onayla ve Reddet düğmelerini görseler bile kimin ne zaman işlem yapacağını ya da sonrasında ne olacağını bilmeyebilirler.

Bu kafa karışıklığı gerçek işte hızlıca ortaya çıkar. Birisi bir talep gönderir, uygulamada görünür ve ilk soru şudur: "Bu talep yöneticinin mi, finansın mı yoksa her ikisinin mi dikkatine gitmeli?" Ekran bitmiş gibi görünür, ama karar yolu eksiktir.

Bunun nedeni, ekranların kuralları olduğundan daha basit göstermesidir. Bir form durum, yorumlar ve işlem düğmeleri gösterebilir ama arkasındaki gerçek onay matrisini tahmin edemez. İşin tutarı, bölüm kuralları veya geçici vekiller varsa, bu durumlar ortaya çıktığında arayüz bozulmaya başlar.

Çoğu zaman tek bir istisna, işin uygulamanın dışına taşmasına yetiyor. Onaylar genellikle bir bölüm yöneticisine gider, ama talep acilse, belirli bir tutarın üzerindeyse ya da onaycı izinliyse farklı davranılabilir. Eğer bu durum haritalanmamışsa insanlar e-postaya, sohbete veya tablolarına geri döner.

Daha büyük bir sorun doğar: her ekip kendi kural versiyonunu uygulamaya başlar. Operasyonlar talebi bir şekilde gönderir, finans farklı bir yol izler ve destek HR'den farklı istisnaları yönetir. Uygulama, paylaşılan bir süreç yerine tutarsız kararlar için ortak bir ekran olur.

Uyarı işaretleri genellikle kolayca fark edilir:

• kullanıcılar sonraki adımın kime ait olduğunu sorar
• benzer talepler ekipler arasında farklı sonuçlar alır
• istisnalar sohbet veya e-postayla çözülür
• politika değişiklikleri kural değişikliği yerine ekran değişikliği gerektirir

Politika güncellemeleri bu zayıflığı hızla açığa çıkarır. Mantık ekranın içinde yaşadığında her eşik veya rol değişikliği UI yeniden çalışması demektir. Bu da ekipleri yavaşlatır, yeni hatalar yaratır ve kullanıcı güvenini azaltır.

Ekran karar yolunu yansıtmalı, onu tanımlamamalı. Matris önce net olduğunda UI daha basit, daha kararlı ve kullanımı daha kolay olur.

Herhangi bir tel çerçeveden önce neyi haritalamalısınız

Ekrandan ziyade karar mantığıyla başlayın. Sağlam bir onay matrisi, kimin neyi onaylayabildiğini, hangi koşullar altında olduğunu ve biri kullanılamazsa ne olacağını gösteren sade bir tabloyla başlar. Bu mantık belirsizse, cilalı bir arayüz bile insanları şaşırtır.

Her talep türü için onay seviyelerini sırayla haritalayın. Her adımı kimin üstlendiğini ve o adımın neye izin verdiğini yazın: onayla, reddet, incele veya geri gönder. İnsan isimleri yerine roller kullanmak daha iyidir; çünkü insanlar yer değiştirir, ekipler değişir ve süreç buna rağmen ayakta kalmalıdır.

Sonra rotayı değiştiren kuralları tanımlayın. Tutar açık bir tetikleyici olsa da genellikle tek koşul değildir. Onay iş akışı kuralları bölge, departman, tedarikçi türü, talep kategorisi veya risk düzeyine bağlı olabilir. Aynı tutar bir ekip için rutinken başka bir ekip için hassas olabilir.

Yokluklar için de kurallar gerekir. Ana onaycı müsait değilse hemen kim devralır? Yedeğin geçici olduğu durumlarda hangi tarih aralığı geçerlidir? Bunlar yoksa talepler tıkanır çünkü bu hafta kimin sorumluluğunda olduğu bilinmez.

Zaman sınırları da en az bunlar kadar önemlidir. Bir talep yanıtsız kaldığında ne olacağına karar verin. Bir gün sonra hatırlatma, iki gün sonra eskalasyon ve üç gün sonra operasyonlara bildirim gönderebilirsiniz. Bu seçimler durum etiketlerini, bildirimleri ve kuyruk görünümlerini etkiler; bu yüzden ekran tasarımına başlamadan önce karara bağlanmalıdır.

Pratik bir matris genellikle beş temel soruyu yanıtlar:

• Hangi koşul bu kuralı başlatır?
• Bu aşamada hangi rol onay verir?
• Yedek kimdir?
• Onaycının işlem yapması için ne kadar süresi var?
• Süre kaçırılırsa ne olur?

Bu yanıtları erken haritalarsanız, geri kalan inşa çok daha kolay olur.

Matrisi adım adım nasıl kurarsınız

Bir tablo, beyaz tahta veya hesap tablosu kullanın. Bir yönetici, ekip lideri ve süreç sahibi hepsinin bir bakışta anlayabileceği kadar basit tutun.

Önce onay gerektiren her talep türünü listeleyin. İş zaten talepleri farklı şekilde ele alıyorsa her şeyi tek bir genel akışa zorlamayın. Bir satın alma talebi, iade, indirim onayı ve erişim isteği genellikle farklı onaycılar, limitler ve süreler gerektirir.

Sonra ilk onaycıyı ve ardından her karar noktasını yazın. Her talep türü için önce kim inceliyor ve onay veya red sonrası ne oluyor not edin. Sonuca ulaşana kadar yolu takip edin: onaylandı, reddedildi, düzenleme için geri gönderildi veya iptal edildi gibi.

Bundan sonra rotayı değiştiren eşikleri ekleyin. Birçok ekip burada sonra takılır. 500$ altındaki bir talep ekip liderine giderken 500$ üstü bölüm başkanına gidiyorsa bunu şimdi yazın. Acil talepler bir adımı atlıyorsa veya daha hızlı bir yoldan gidiyorsa bunu da yakalayın.

Sonra istisnaları, süreleri ve son durumları kaydedin. Eksik belgeler, yinelenen talepler, politika ihlalleri ve gecikmiş onaylar gibi vakaları dahil edin. Kural, işler yanlış gittiğinde nasıl davrandığını bilmeden bitmiş sayılmaz.

Son olarak, taslağı bugün onay veren kişilerle gözden geçirin. İşin genelde nerede takıldığını, kimlerin adımları atladığını ve normal onaycı müsait olmadığında ne olduğunu sorun. Gerçek uygulamalar genellikle hiç dokümante edilmemiş kuralları ortaya çıkarır.

Küçük bir örnek bunu netleştirir. Ofis malzemeleri için bir satın alma talebi düşünün: 200$ altı ofis malzemeleri ekip liderine gider, 200$–2.000$ arası yazılım bölüm yöneticisine gider ve üzeri finansın incelemesini gerektirir. Form tutarı ve kategoriyi erken yakalamazsa UI doğru yola gönderemez.

İnsanların gerçekten uygulayabileceği eşikler belirleyin

Eşikler insanlar tarafından hızlı okunabildiğinde ve aynı şekilde yorumlandığında işe yarar. "Küçük alımlar" veya "yüksek riskli tedarikçiler" gibi ifadeler farklı kişilere farklı anlamlar verecektir. Bunun yerine sabit rakamlar, tarihler ve adlandırılmış koşullar kullanın.

Daha net bir kural şöyle olur: "1.000$'a kadar ekip liderine gider. 1.001$–5.000$ arası bölüm yöneticisine gider. 5.000$'ın üzeri finans ve direktörü gerektirir." Böylece kimsenin talebin nereye ait olduğuna dair tahmin yürütmesine gerek kalmaz.

Tutar yaygın bir tetikleyicidir ama süreç diğer faktörlere bağlıysa tek kriter olmamalıdır. Yeni bir tedarikçiden düşük maliyetli bir yazılım, onaylanmış bir tedarikçiden gelen daha büyük bir siparişten daha fazla inceleme gerektirebilir.

Çoğu ekip yalnızca küçük bir yönlendirme kural setine ihtiyaç duyar. Yaygın örnekler arasında tutar aralığı, tedarikçi durumu, satın alma kategorisi, departman ve aciliyet yer alır. Önemli olan kural sayısı değil, herkesin bunları aynı şekilde uygulayıp uygulamadığıdır.

Kuralların sırası da önemlidir. Hangi koşulun üstün olduğunu bilmezlerse aynı talep farklı şekillerde yönlendirilir. Bir sıra seçin ve tutarlı olun. Öncelikle tedarikçi durumunu, sonra kategoriyi, sonra tutarı kontrol edebilirsiniz. Veya önce tutarı kontrol edip istisnaları sonra ele alabilirsiniz. Her iki yaklaşım da herkes aynı sıra izlediğinde işe yarar.

Ayrıca kimin eşiği ne zaman geçersiz kılabileceğini tanımlamak yardımcı olur. Bunu yapmazsanız personel ya çok uzun bekler ya da süreci e-posta ve sohbette atlar. "Finans direktörü aylık kapanış sırasında limit üzeri onaylayabilir" faydalıdır. "Üst yönetim istisna yapabilir" ise çok belirsizdir.

Basit bir test işe yarar: aynı örnek talebi üç kişiye verin ve nereye gitmesi gerektiğini sorun. Eğer üç farklı cevap alıyorsanız eşikler hâlâ çok belirsiz demektir.

Yedek onaycıları, vekilleri ve eskalasyonları planlayın

Güçlü bir matris ana onaycıyla bitmez. Gerçek işler biri izinde, hastaysa veya yanıt vermezse akmaya devam etmelidir. Bunu erken planlamazsanız ekran düzenli görünse bile süreç sessizce tıkanır.

Her önemli adım için yedek onaycıyı belirleyerek başlayın. Bu, sadece "sonraki yönetici" gibi genel bir ifade değil, doğru bağlama sahip bir kişi veya rol olmalıdır. Örneğin belli bir tutarın üzerindeki giderleri onaylayan bir finans lideri varsa, o kişi müsait olmadığında kim devreye girer kararlaştırın.

Geçici vekillerin sınırları olmalı. Bir vekile onay yetkisi sadece tanımlı bir süre için verilmelidir; örneğin tatil tarihleri veya planlı izin dönemleri. Bu, sorumluluğu net tutar ve birinin uzun süre sonra bile onay erişimini korumasını önler.

Basit bir düzen dört şeyi yanıtlamalı: ana onaycı kim, yedek kim, vekil ne kadar süreyle hareket edebilir ve istek ne zaman zincirde yukarı çıkar.

Eskalasyonlar açık tetikleyicilere dayanmalıdır, tahmine değil. Yaygın tetikleyiciler zaman, tutar, risk veya eksik bilgi içerir. Örneğin 10.000$ üzerindeki bir satın alma isteği 24 saat boyunca yanıtsız kalırsa bölüm başkanına eskale edilebilir.

Eskalasyon yolunu kısa tutun. Birinin bir sonraki alıcıyı anlaması için karmaşık bir diyagrama ihtiyaç varsa kural muhtemelen çok karışıktır. Genellikle bir veya iki net atlama yeterlidir.

Her kararı da kaydedin. Kimin onayladığını, kimin vekalet ettiğini, devrin ne zaman gerçekleştiğini ve talebin neden eskale edildiğini saklayın. Bu geçmiş, daha sonra birisi bir gecikmenin veya vekil onayının nedenini sorduğunda önemlidir.

Göründüğünden daha önemli bir kural: döngülerden kaçının. Bir talep, daha önce onaylayan birine veya aynı kişi için vekalet eden birine asla geri dönmemelidir. Uygulamaya başlamadan önce matrisi dairesel yollar için kontrol edin.

Basit bir örnek: satın alma talebi onayı

Küçük bir şirketin günlük ihtiyaçları için alışveriş yaptığını hayal edin. Bir çalışan gerekli öğe, tutar, gerekçe ve gereken tarih ile tek bir satın alma talebi gönderir. Yönlendirme kurallarla, kim çevrimiçi olduğuna bağlı değil.

Talep 420$ ise doğrudan ekip liderine gider. Bu küçük alımların akmasını sağlar. 3.200$ tutarındaki bir talep ekip liderini atlayıp bölüm yöneticisine gider çünkü bütçe etkisi daha büyüktür.

Şimdi 7.800$ tutarında yeni ekipman talebini alın. Bölüm yöneticisi hala inceleme yapar ama tek başına yeterli değildir. Çünkü tutar 5.000$'ın üzerinde olduğundan finans da incelemelidir. İşte net bir matrisin faydası: daha yüksek tutarlar kontrol ekler ama kararsızlık katmaz.

Yokluklar burada da önemlidir. Bölüm yöneticisi izindeyse talep beklemede kalmamalıdır. İsimlendirilmiş bir vekil otomatik olarak alır ve tanımlı süre boyunca hareket edebilir.

Zaman sınırları aynı netlikte olmalıdır. Kimse iki gün içinde harekete geçmezse talep operasyonlara eskale olur. Operasyonlar takip edebilir, yeniden atayabilir veya işin engellenmemesini sağlayabilir.

Bu örnekte matris birkaç basit ama önemli soruyu yanıtlar: ne kadar talep ediliyor, her tutarda hangi rol onaylıyor, ne zaman finans ekleniyor, yoklukları kim karşılıyor ve süre kaçırıldığında ne oluyor.

Bu yanıtlar belirlendiğinde ekran tasarımı basitleşir. Form sadece doğru veriyi istemeli ve talep sayfası yalnızca mevcut onaycıyı, varsa vekili ve eskalasyon sayacının çalışıp çalışmadığını göstermelidir.

Yeniden çalışmaya neden olan yaygın hatalar

Çoğu yeniden çalışma tek bir ekran çizilmeden önce başlar. Ekipler onay yolunu tahmin eder, sonra UI'ı aslında hiç üzerinde anlaşılmamış kurallara uydurmaya çalışır.

Yaygın hatalardan biri organizasyon şemasını kopyalayıp bunu bir iş akışı olarak adlandırmaktır. Bu düzenli görünebilir ama gerçek talepler genellikle tutar, risk, konum veya talep türüne göre hareket eder. Matris bunu görmezse ekranlar daha sonra ekstra alanlar, ekstra durumlar ve garip istisnalar gerektirecektir.

Diğer bir sorun özel durumları unutmak. Acil talepler, düzenlemeye tabi satın almalar veya ekipler arası talepler genellikle farklı bir yol izler. Bu istisnalar erken haritalanmazsa insanlar manuel geçici çözümler ister ve arayüz tek seferlik seçeneklerle dolar, bu da herkesi şaşırtır.

Ekipler ayrıca iki kişiye aynı işi verdiğinde bağ çözücü kuralı olmadığında sorun yaratır. Her ikisi de onaylayabiliyorsa önce kim işlem yapar? Farklılık olursa kimin kararı geçerli olur? Bu cevap yoksa talepler dolaşıp durur ve kullanıcı güveni düşer.

Vekil kuralları başka bir zayıf noktadır. Vekil yokluğu kapatmak için olmalı, sessizce kalıcı ikinci sahip olmaktan kaçınmalıdır. Geçici kapsama ile kalıcı sahiplik karıştığında raporlar karışır ve sorumluluk kaybolur.

Yönlendirme netleşmeden form tasarlamak da yeniden çalışmaya yol açar. Bir form tamamlanmış gibi görünse de onay kuralları kesinleştiğinde genellikle tutar bandı, departman, aciliyet veya politika bayrağı gibi eksik alanlar ortaya çıkar. Ardından düzen, doğrulama ve bildirimler değişmek zorunda kalır.

Bunu erken yakalamaya yardımcı olacak hızlı bir gerçek kontrol:

• İki onaycı aynı anda aynı talebi alabilir mi?
• Geçici yedek ile kalıcı sahiplik arasında net bir fark var mı?
• Acil veya düzenlemeye tabi vakalar farklı bir rota izliyor mu?
• Her yönlendirme kararı mevcut bir alana mı bağlı?
• Bir onaycı şirketten ayrılırsa süreç hâlâ mantıklı kalır mı?

Herhangi bir cevap belirsizse orada durun. Ekranları cilalamadan önce matrisi düzeltin.

Ekranları tasarlamadan önce hızlı kontroller

Bir form veya durum rozeti tasarlamadan önce mantığı düz bir dille test edin. İyi bir onay matrisi bir diyagram açmadan kolayca açıklanabilmelidir. Bir yönetici, finans lideri veya operasyon çalışanı rotayı yaklaşık bir dakikada tarif edemezse süreç hâlâ UI çalışması için çok belirsizdir.

Gerçek örneklerle hızlı bir gözden geçirme yapın. Bir kişiye talebin gönderiminden son karara kadar tam rotayı açıklamasını isteyin. Muhtemel her sonucun adımları için isimlendirilmiş bir sonraki onaycı olduğundan emin olun, sadece mutlu yol değil. Belirsiz eşikleri "$1.000 ve altı" veya "%10'dan fazla indirim" gibi kesin kurallara çevirin. Yedek ve eskalasyon kurallarının "24 saat sonra" veya "2 iş günü sonra" gibi net zaman sınırları kullandığından emin olun.

Sonra izlenebilirliği test edin. Daha sonra biri talebin neden geciktiğini, istisnayı kimin onayladığını veya vekilin ne zaman devreye girdiğini soracaktır. Süreciniz bu soruları önceden yanıtlamalıdır. Zaman damgaları, karar geçmişi ve net durum değişiklikleri ekstra değil, kural setinin parçasıdır.

Basit bir senaryo genellikle zayıf noktaları açığa çıkarır. Cuma öğleden sonra gelen 4.800$'lık bir satın alma talebini ve normal onaycının izinde olduğunu düşünün. Sıradaki kim? Sistem ne kadar bekler? Yedek de hareketsizse ne olur? Bu sorular yazılı değilse UI karışıklığı gizler, çözmez.

Bu kontroller geçilince ekran tasarımı çok daha kolaylaşır. Artık arayüzün ne göstermesi gerektiğini tahmin etmiyor, açık kurallara net bir biçim veriyorsunuz.

Sonraki adımlar: matrisi çalışan bir uygulamaya dönüştürün

Kurallar netleşince, ekranları cilalamadan önce süreci inşa edin. Mantık, veri alanları ve onay durumlarıyla başlayın. Yönlendirme çalışırsa, arayüz tasarımı çok daha kolay olur. Yönlendirme hâlâ değişiyorsa, çekici ekranlar yalnızca sorunları gizler.

Pratik bir ilk sürüm genellikle temel alanları içerir: talep türü, tutar, departman, mevcut onaycı ve her kararın açık geçmişi. Ardından bir talebi ilerleten, yedek onaycıya gönderen veya biri zamanında yanıt vermezse eskalasyon tetikleyen kuralları ekleyin.

İlk ekranları basit tutun. Bir talep sahibi gönderebilmeli, durum kontrol edebilmeli ve takip sorularına yanıt verebilmeli. Bir onaycı inceleyebilmeli, onaylayabilmeli, reddedebilmeli veya yeniden atayabilmeli. Bu, iş akışının günlük kullanımda mantıklı olup olmadığını test etmek için yeterlidir.

Mantıklı bir inşa sırası basittir:

• temel veri alanlarını ve durum değerlerini tanımlayın
• eşikler, yedek onaycılar, vekiller ve eskalasyonlar için yönlendirme kurallarını ekleyin
• talep sahipleri ve onaycılar için temel ekranları oluşturun
• her kanalın aynı gerçek kaynağı kullandığından emin olun
• geniş dağıtımdan önce bir gerçek talebi baştan sona test edin

Bu ortak gerçek kaynağı birçok ekibin beklediğinden daha önemlidir. Mobil bir yerde bir durum, web panelde başka bir durum ve backend başka eşikler kullanıyorsa güven hızla yok olur.

Bunu AppMaster'da inşa ediyorsanız, net bir matris kurulumunu çok daha kolaylaştırır. Veriyi, iş mantığını ve onay akışını önce modelleyebilir, sonra aynı süreci backend, web ve mobil arasında kuralları farklı araçlarda yeniden yazmadan taşıyabilirsiniz.

İlk test için tek bir gerçek vaka kullanın. Bir eşikli, vekil onaycılı ve gecikmiş bir eskalasyonu olan gerçek bir satın alma talebi çalıştırın. İnsanların nerede tereddüt ettiğini, hangi veriyi kaçırdıklarını ve hangi durum etiketlerinin kafa karıştırdığını izleyin.

Sonra metinleri ve düzeni iyileştirin. Süreç gerçek bir taleple çalıştığında, ekranları tasarlamak daha kolay olur ve bir hafta sonra yeniden inşa edilme olasılığı çok düşer.