Kurumsal Çok Aşamalı Onaylar İçin Web Uygulaması Oluşturma

Çok Aşamalı Onay Zincirleri Nedir (ve Neden Önemlidir)\n\nÇok aşamalı onay zinciri, bir isteğin ilerleyebilmesi için geçmesi gereken yapılandırılmış karar dizisidir. Rasgele e-postalara ve “tamam gibi görünüyor” mesajlarına dayanmak yerine, bir onay zinciri kararları tekrar edilebilir bir iş akışına dönüştürür; sahipliği, zaman damgalarını ve sonucu netleştirir.\n\nTemel seviyede, uygulamanız her istek için üç soruyu yanıtlıyor: \n\n- Kim onaylamalı?\n- Hangi sırada (veya hangi aşamada)?\n- Her karardan sonra ne olur?\n\n### Ardışık vs. paralel adımlar\n\nOnay zincirleri genellikle iki deseni birleştirir:\n\n- Ardışık onaylar: Adım B, Adım A onaylanana kadar başlayamaz. Örnek: bir purchasing (закупки) isteği önce takım liderini, sonra Finansı, sonra Satın Alma'yı gerektirebilir.\n- Paralel onaylar: Birden fazla onaylayıcı aynı anda inceleyebilir. Örnek: bir politika değişikliği Hukuk ve Güvenlik'in paralel onayını gerektirebilir ve ancak onaylandıklarında ilerleyebilir.\n\nİyi sistemler her ikisini de destekler; ayrıca “bunlardan herhangi biri onaylayabilir” ile “hepsinin onaylaması gerekir” gibi varyasyonlar da bulunur.\n\n### Tipik kurumsal kullanım örnekleri (genel örnekler)\n\nÇok aşamalı onaylar, izlenebilirliği olan kontrollü değişiklik gereken her yerde karşınıza çıkar:\n\n- Purchasing (закупки): tedarikçi seçimi, bütçe kontrolleri, satın alma onayı\n- Masraflar: yönetici onayı, finans doğrulaması, yüksek tutarlar için istisnalar\n- Erişim talepleri: yönetici onayı, sistem sahibi onayı, güvenlik incelemesi\n- Politika değişiklikleri: taslak, paydaş onayı, uyumluluk incelemesi, yayımlama\n\nİstek türü farklı olsa bile ihtiyaç aynıdır: kimin çevrimiçi olduğuna bağlı olmayan, tutarlı karar alma.\n\n### Kurumsalların onay zincirlerinden bekledikleri\n\nİyi tasarlanmış bir onay iş akışı sadece “daha fazla kontrol” değildir. Dört pratik hedefi dengelemelidir:\n\n- Hız: gereksiz gidip gelmeleri azaltmak ve beklemeleri ortadan kaldırmak\n- Kontrol: doğru kişilerin doğru şeyleri onayladığından emin olmak\n- Görünürlük: herkes durumu, sonraki adımı ve engelleri görebilmeli\n- Denetime hazır kayıtlar: kim, ne, ne zaman, karar ve gerekçe içeren eksiksiz bir denetim izi\n\n### Kaçınılması gereken yaygın tuzaklar\n\nOnay zincirleri daha çok süreç belirsizliğinden başarısız olur. Tekrarlayan problemlere dikkat edin:\n\n- Belirsiz sahiplik: kimse onaylayıcıyı bilmiyor, istekler takılır\n- Eksik denetim geçmişi: kararlar sohbet veya e-postada oluyor ve sonra kanıtlanamıyor\n- Çok fazla manuel adım: “bilgi amaçlı” incelemeler zorunlu onaylara dönüşür ve her şeyi yavaşlatır\n\nBu rehberin geri kalan kısmı, onayların iş için esnek, sistem açısından öngörülebilir ve gerektiğinde denetlenebilir kalmasını sağlayacak bir uygulama inşa etmeye odaklanır.\n\n## Kurumsal Onaylar için Gereksinimler Kontrol Listesi\n\nEkranları tasarlamadan veya bir iş akışı motoru seçmeden önce, gereksinimler üzerinde açıkça anlaşın. Kurumsal onay zincirleri birçok takımı etkiler ve küçük eksiklikler (ör. delege eksikliği) hızla operasyonel çözümlere dönüşür.\n\n### Erken dahil edilmesi gereken paydaşlar\n\nSistemi kullanacak veya inceleyecek kişileri isimlendirmekle başlayın:\n\n- İstek sahipleri (çalışanlar, yükleniciler, tedarikçiler)\n- Onaylayıcılar (yöneticiler, finans, hukuk, IT, güvenlik)\n- Yöneticiler (admin) (şablonları, yönlendirme kurallarını ve erişimi yöneten ops/destek)\n- Denetçiler/uyumluluk (iç denetim, dış düzenleyiciler)\n\nPratik bir ipucu: her gruptan en az bir kişiyle 45 dakikalık bir yürütme yapın; bir “tipik istek” ve bir “en kötü durum isteği” (escalation, yeniden atama, politika istisnası) üzerinden geçin.\n\n### Olmazsa olmaz iş akışı kabiliyetleri\n\nBu maddeleri test edilebilir ifadeler halinde yazın (her birinin çalıştığını ispatlayabilmelisiniz):\n\n- Eklentiler ve yapılandırılmış alanlarla istek gönderebilme\n- Onay/red, yorum ve her adım için karar kaydetme\n- Geçici delege (tatil) ve kalıcı yeniden atama (örgütsel değişiklikler)\n- Paralel onayları (ör. Finans ve Hukuk) ve ardışık adımları destekleme\n- Kim neyi görebilir sorusunu uygulama (istek sahibi görünürlüğü vs onaylayıcıya özel notlar)\n\n“İyi”nin neye benzediğine dair ilham arıyorsanız daha sonra bu gereksinimleri UX gereksinimlerine haritalayabilir ve /blog/approver-inbox-patterns benzeri referanslara bakabilirsiniz.\n\n### İşlevsel olmayan gereksinimler (kurumsal için ne gerekli)\n\nHedefleri tanımlayın, dilekleri değil:\n\n- Uptime ve RTO/RPO (ne kadar süre kapalı kalabilir, ne kadar veri kaybı kabul edilebilir)\n- Performans (ör. 10k bekleyen öğe için gelen kutusu 2 saniyenin altında yüklenmeli)\n- Veri saklama (istekler, yorumlar ve ekler ne kadar süre saklanacak)\n- Destek modeli (kim on-call, mesai saatleri, olaylar için SLA'lar)\n\n### Kısıtlar ve başarı metrikleri\n\nÖnceden kısıtları yakalayın: düzenlemeye tabi veri türleri, bölgesel depolama kuralları ve uzaktan çalışan bir ekip (mobil onaylar, saat dilimleri).\n\nSon olarak başarı metriklerinde uzlaşın: onay süresi (time-to-approve), % gecikmeli ve yeniden iş oranı (eksik bilgi nedeniyle kaç kez geri döndüğü). Bu metrikler önceliklendirmeyi yönlendirir ve yayılımı haklı çıkarmaya yardımcı olur.\n\n## Veri Modeli: İstekler, Adımlar, Kararlar ve Şablonlar\n\nNet bir veri modeli “gizemli onayları” önler—kimin neyi, ne zaman ve hangi kurallar altında onayladığını açıklayabilirsiniz. İş nesnesi olan Request ile süreç tanımı olan Template öğesini ayırarak başlayın.\n\n### Temel varlıklar\n\nRequest: isteği oluşturan kayıt. İstek sahibi kimliği, iş alanları (tutar, departman, tedarikçi, tarihler) ve destekleyici materyallere bağlantılar içerir.\n\nStep: zincirdeki bir aşamayı temsil eder. Adımlar genellikle gönderim zamanında bir Template'den oluşturulur, böylece her Request'in kendi değiştirilemez (immutable) sırası olur.\n\nApprover: genellikle bir adıma bağlı kullanıcı referansı (veya grup referansı). Dinamik yönlendirme destekleniyorsa, çözülen onaylayıcı(lar)ı ve onları üreten kuralı izlenebilirlik için saklayın.\n\nDecision: olay günlüğü: onay/red/iade, aktör, zaman damgası ve isteğe bağlı meta veriler (ör. delegated-by). Değişiklikleri denetleyebilmek için append-only (eklemeli) olarak modelleyin.\n\nAttachment: dosyaları (nesne depolamada) ve meta verileri saklar: dosya adı, boyut, içerik türü, checksum ve yükleyen.\n\n### Raporlamayı kolaylaştıran durumlar\n\nRaporlama için küçük, tutarlı bir Request durum seti kullanın:\n\n- Draft: düzenlenebilir, yönlendirilmemiş\n- Submitted: yönlendirme kurallarına kilitlenmiş, adımlar oluşturulmuş\n- In Review: en az bir bekleyen adım var\n- Approved: gerekli tüm adımlar tamamlandı\n- Rejected: reddedilme ile istek sona erdi\n- Canceled: istek sahibi/admin tarafından geri çekildi\n\n### Erken ihtiyaç duyacağınız adım tipleri\n\nYaygın adım semantiklerini destekleyin:\n\n- Tek onaylayıcı: bir kişi karar vermeli\n- Grup: grup üyelerinden herhangi biri karar verebilir\n- Kota (Quorum): N-of-M onayı gerekli\n- Koşullu: yalnızca bir koşul doğruysa dahil edilir (ör. tutar \u003e $10k)\n\n### Şablon versiyonlaması (sürpriz olmadan)\n\nWorkflow Template'i versionlu tutun. Bir şablon değiştiğinde, yeni Request'ler en son versiyonu kullanır, ancak akışta olan Request'ler oluşturuldukları versiyonu korur.\n\nHer Request'te template_id ve template_version saklayın ve gönderim anında kritik yönlendirme girdilerini (departman veya maliyet merkezi gibi) snapshot olarak alın.\n\n### Yorumlar ve dosyalar\n\nYorumları Request'e bağlı ayrı bir tablo olarak modelleyin (isteğe/isteğe adım/karara bağlı olarak da) böylece görünürlüğü kontrol edebilirsiniz (sadece istek sahibi, onaylayıcılar, adminler).\n\nDosyalar için: boyut limitleri uygulayın (ör. 25–100 MB), yüklemeleri zararlı yazılım için tarayın (asenkron karantina + serbest bırakma) ve veritabanınızda yalnızca referansları saklayın. Bu, çekirdek iş akışı verilerinin hızlı kalmasını ve depolamanın ölçeklenebilir olmasını sağlar.\n\n## Esnek Onay Yönlendirme Kurallarını Tasarlamak\n\nOnay yönlendirme kuralları kimin neyi onaylaması gerektiğini ve hangi sırada belirler. Kurumsal onay iş akışında püf noktası, katı politika ile gerçek dünya istisnaları arasında denge kurmaktır—her isteği özel bir iş akışına çevirmeden.\n\n### Net “sinyaller” ile başlayın\n\nÇoğu yönlendirme, isteğin birkaç alanından türetilebilir. Yaygın örnekler:\n\n- Tutar eşikleri (ör. $10k üzeri Finans ekler)\n- Departman veya maliyet merkezi (maliyet merkezi sahibine yönlendirir)\n- Lokasyon (yerel tüzel kişi veya bölgesel uyumluluk)\n- Risk seviyesi (yüksek riskli tedarikçiler için InfoSec/Hukuk eklenir)\n\nBunları hard-code etmek yerine yapılandırılabilir kurallar olarak değerlendirin, böylece adminler dağıtım olmadan politikaları güncelleyebilir.\n\n### Dinamik onaylayıcıları destekleyin\n\nStatik listeler çabuk bozulur. Bunun yerine dizin ve örgüt verilerine dayalı olarak çalışma zamanında onaylayıcıları çözün:\n\n- Yönetici zinciri (doğrudan yönetici, eşik üzerinde ise bir üstü)