Üniversite kulüp etkinlik onay süreci nasıl kurulur: durum makinesi ve onay zinciri tasarımı

Etkinlik tarihine iki gün kala hâlâ onay bekleyen bir kulüp, aslında onay almıyor değil, sürecin nerede durduğunu bilmiyor. Talep WhatsApp’tan danışmana gitti, danışman öğrenci işlerine e-posta attı, öğrenci işleri salon için başka bir birime sordu, kimse cevabı takip etmedi. Süreç bozuk değil, süreç yok.

Aşağıda, kulüp etkinlik onayının hangi alanlarla başlaması, hangi basamaklardan geçmesi ve hangi durumlarda ne yapması gerektiğini tasarım düzeyinde anlatıyorum. Bu, bir yazılım özelliği anlatısı değil, süreç tasarımı.

Mevcut süreç neden tıkanıyor?

Tipik akış tıkanıyor çünkü talebin durumu hiçbir yerde kayıtlı değil. Bilgi, kişilerin gelen kutularında ve sohbet geçmişlerinde dağınık duruyor. Kimse “şu anda kimde” sorusuna bakarak cevap veremiyor, herkes tahmin ediyor.

Somut belirtiler şunlar:

• Kulüp, talebi gönderdikten sonra ne kadar bekleyeceğini bilmiyor, üç gün sonra aynı kişiye tekrar yazıyor.
• Onaycı, karar için gereken bilgiyi formda bulamıyor, cevap yerine soru gönderiyor. Bir tur daha kaybediliyor.
• Danışman onayladı ama öğrenci işleri haberdar değil, çünkü ileti zincirinde yer almıyor.
• Salon iki kulübe ayrı ayrı sözlü olarak verilmiş, çakışma etkinlik sabahı ortaya çıkıyor.
• Etkinlik sonrası bütçe sorulduğunda “onay verilmişti” deniyor, kim verdi belirsiz.

Bunların hepsi tek bir eksiğin sonucu: talebin tek bir kaydı ve o kaydın tanımlı bir durumu yok.

Talep formunda hangi alanlar sorulmalı?

Formun tek işlevi, onaycının karar vermesi için gereken bilgiyi eksiksiz toplamaktır. Bir alan formda değilse, o alan e-posta yazışmasına dönüşür. Kural şu: karar verirken sorulan her soru, bir sonraki dönem forma girmeli.

Alan	Neden gerekli	Zorunluluk
Başlık ve amaç	Etkinliğin niteliği, akademik uygunluk değerlendirmesi	Zorunlu
Başlangıç ve bitiş zamanı	Çakışma kontrolü, personel planlaması	Zorunlu
Mekan tercihi ve alternatifi	Tahsis kararı, kapasite eşleşmesi	Zorunlu
Beklenen katılımcı sayısı	Salon kapasitesi, güvenlik, ikram	Zorunlu
Etkinlik türü	Yönlendirilecek onay basamağının belirlenmesi	Zorunlu
Dış konuşmacı bilgisi	Kurum dışı kişi için ek izin ve protokol	Koşullu
Bütçe talebi ve kalemleri	Mali onay, harcama takibi	Koşullu
Sponsor durumu	Kurumsal iş birliği kuralları, logo kullanımı	Koşullu
Teknik ve lojistik destek	Ses, projeksiyon, masa, güvenlik talebi	Koşullu
Katılım ücreti	Mali mevzuat ve muhasebe akışı	Koşullu
Ortak düzenleyen kulüpler	Sorumluluk paylaşımı, yetkilendirme	Opsiyonel

Koşullu alanları formda dinamik yapın. “Dış konuşmacı var mı” sorusuna evet denmedikçe konuşmacı alanlarını göstermeyin. Herkese her alanı sormak, formu doldurulmaz hale getirir ve kulüpler formu atlayıp doğrudan mesaj atmaya döner.

Bir de zaman kuralı koyun: etkinlik tarihine kaç gün kala talep açılabilir? Kurumların çoğunda 10 ile 15 gün arası bir alt sınır makul. Sınırı forma gömün, sonradan tartışma çıkmasın.

Onay basamakları nasıl sıralanmalı?

Basamakların sırası, en ucuz redden en pahalı redde doğru olmalıdır. Yani etkinliğin hiç yapılmayacağını en hızlı anlayacak kişi ilk sırada olmalı. Salon tahsisi gibi kaynak bağlayan adımlar en sona kalmalı, çünkü iptal edilen tahsisler başka kulüplerin planını bozar.

Pratikte işleyen sıra:

1. Kulüp danışmanı. Etkinliğin kulübün amacına uygunluğunu ve kulübün bunu yürütecek kapasitede olduğunu değerlendirir. En hızlı ret burada verilir.
2. Öğrenci işleri veya sağlık kültür spor birimi. Kurumsal uygunluk, mali kurallar, dış konuşmacı ve sponsor kuralları burada denetlenir.
3. Mekan ve kaynak sahibi. Salon, teknik ekipman ve personel tahsisi burada yapılır ve rezervasyon kilitlenir.

Dekanlık onayı, tüm etkinlikler için değil yalnızca belirli türler için devreye girmeli: kurum dışı katılımcıya açık büyük etkinlikler, bütçe talebi eşiği aşan etkinlikler, kampüs dışında yapılan etkinlikler. Her etkinliği dekanlığa göndermek, dekanlık kuyruğunu kritik olmayan taleplerle doldurur ve gerçekten önemli olanı geciktirir.

Basamak sayısını artırmadan önce şunu sorun: bu basamak hangi kararı veriyor ve bu kararı bir üst basamak zaten veremiyor mu? Cevap “kayıt tutsun diye” ise, o basamak onay değil bildirim olmalı.

Durum makinesi nasıl tanımlanır?

Talebin her an tek bir durumu olmalı ve durumlar arası geçişler önceden tanımlanmalı. Tanımsız geçişe izin veren bir sistem, birkaç hafta içinde tutarsız kayıtlar üretir.

Aşağıdaki durum kümesi kampüs koşullarında yeterli:

Durum	Anlamı	Kimde	Sonraki olası durumlar
taslak	Kulüp hazırlıyor, henüz gönderilmedi	Kulüp	beklemede, iptal
beklemede	Danışman incelemesinde	Danışman	ön onaylı, revizyon, reddedildi
ön onaylı	Danışman uygun buldu, kurumsal inceleme sırada	Öğrenci işleri	mekan bekliyor, revizyon, reddedildi
mekan bekliyor	Kurumsal onay verildi, tahsis bekleniyor	Mekan sahibi	onaylandı, revizyon, reddedildi
revizyon	Düzeltme istendi	Kulüp	beklemede, iptal
onaylandı	Tüm basamaklar tamam, mekan kilitlendi	Kulüp	yayımlandı, iptal
yayımlandı	Öğrencilere duyuruldu, kayıt açık	Herkes	tamamlandı, iptal
tamamlandı	Etkinlik gerçekleşti, yoklama kapandı	Kulüp	arşivlendi
reddedildi	Talep kapatıldı, gerekçe zorunlu	Kulüp	taslak (yeni talep)
iptal	Onaylı etkinlik geri çekildi, kaynak serbest	Kulüp, birim	arşivlendi

Geçiş kurallarını metin olarak yazmak, diyagram çizmekten daha kullanışlı, çünkü koda birebir dönüşür:

taslak        --gönder-->        beklemede
beklemede     --ön onay-->       ön onaylı
beklemede     --revizyon iste--> revizyon
beklemede     --reddet-->        reddedildi        (gerekçe zorunlu)
ön onaylı     --kurumsal onay--> mekan bekliyor
mekan bekliyor--tahsis et-->     onaylandı         (çakışma kontrolü çalışır)
revizyon      --tekrar gönder--> beklemede
onaylandı     --yayımla-->       yayımlandı        (takvime yazılır)
yayımlandı    --etkinlik bitti-->tamamlandı        (otomatik, zamanlanmış iş)
*             --iptal et-->      iptal             (gerekçe zorunlu, tahsis serbest)

Son satırdaki yıldız, iptalin hemen her durumdan mümkün olması gerektiğini gösteriyor. Ama iptal, onaylı bir etkinlikten geliyorsa mekan rezervasyonunun serbest bırakılmasını tetiklemeli. Bu bağı kurmayan sistemlerde salonlar “hayalet dolu” kalır.

Revizyon döngüsü nasıl kurulur?

Revizyon, reddin yumuşak hali değil, ayrı bir mekanizmadır. Onaycı neyin düzeltilmesi gerektiğini alan düzeyinde belirtebilmeli, kulüp yalnızca o alanı güncelleyip yeniden gönderebilmelidir.

İyi bir revizyon akışının şartları:

1. Gerekçe zorunlu. Boş bırakılabilen bir revizyon notu, kulübün ne yapacağını bilmemesi demektir.
2. Geçmiş korunur. Revizyon sonrası eski değerler silinmez, sürüm olarak saklanır. “Bütçe rakamı sonradan değişti mi” sorusu ancak böyle cevaplanır.
3. Basamağa geri döner, başa değil. Danışmandan gelen revizyon, düzeltildikten sonra tekrar danışmana gitmeli. Kurumsal onaydan gelen revizyon, danışmanı yeniden meşgul etmemeli. Aksi halde her düzeltme tüm zinciri tekrar eder.
4. Sayaç tutulur. Aynı talebin üçüncü kez revizyona düşmesi, formun eksik olduğunun işaretidir. Formu düzeltin, kulübü değil.

Ret tarafında tek kural var: gerekçe zorunlu ve kulübe görünür olmalı. Gerekçesiz ret, aynı talebin bir hafta sonra aynı haliyle tekrar gelmesine yol açar.

SLA ve otomatik hatırlatma nasıl çalışmalı?

Basamak başına hedef süre koyun ve süre aşımını hem onaycıya hem kulübe gösterin. Süre tek başına bir şey değiştirmez, görünürlük değiştirir.

Basamak	Hedef süre	İlk hatırlatma	Yükseltme
Danışman incelemesi	2 iş günü	2. günün sonu	4. gün, birim yöneticisine bilgi
Kurumsal inceleme	3 iş günü	3. günün sonu	5. gün, birim yöneticisine bilgi
Mekan tahsisi	2 iş günü	2. günün sonu	4. gün, kulübe alternatif mekan önerisi

Hatırlatmayı kişiye değil role gönderin. Danışman izindeyse talep, yerine bakan kişiye görünür olmalı. Kişiye bağlı akışlar, tatil dönemlerinde tamamen durur.

Kulüp tarafına da bir gösterge koyun: talebin şu anda hangi basamakta olduğu ve o basamakta kaç gündür beklediği. Bu tek ekran, “onay ne oldu” mesajlarının büyük kısmını ortadan kaldırır.

Mekan çakışması kontrolü nasıl yapılır?

Çakışma kontrolü, onayın verildiği anda çalışan bir sorgudur. Talep oluşturulurken yapılan kontrol yeterli değildir, çünkü talep ile onay arasında geçen sürede başka bir etkinlik aynı salonu almış olabilir.

Kontrol edilecek koşul, aralık kesişimidir:

SELECT 1
FROM event_venues ev
JOIN events e ON e.id = ev.event_id
WHERE ev.venue_id = :venue_id
  AND e.status IN ('onaylandi', 'yayimlandi')
  AND e.starts_at < :new_ends_at
  AND e.ends_at   > :new_starts_at
LIMIT 1;

Üç ayrıntıya dikkat edin. Birincisi, yalnızca kaynak bağlayan durumları sayın; taslak veya reddedilmiş etkinlikler salonu işgal etmez. İkincisi, kurulum ve toplanma süresini hesaba katın: etkinlik 19:00’da bitiyorsa salon 19:00’da boş değildir, tampon süreyi aralığa ekleyin. Üçüncüsü, bir etkinlik birden çok salon kullanabilir, bu yüzden mekan ilişkisini ayrı bir bağlantı tablosunda tutun, etkinlik satırındaki tek alanla yetinmeyin.

Kontrolü yalnızca uygulama katmanında yapmak, eşzamanlı iki onayda yetersiz kalır. Tahsisi, rezervasyon satırına benzersizlik kısıtı koyarak veya işlem içinde satır kilidi alarak garanti altına alın.

Onay geçmişi denetlenebilir biçimde nasıl tutulur?

Onay kaydı, etkinlik satırındaki tek bir “onaylayan” alanından ibaret olamaz. Her geçiş için ayrı bir kayıt tutun ve bu kayıtları değiştirilemez sayın.

Bir geçiş kaydında bulunması gerekenler:

• Talebin kimliği ve geçişin sıra numarası
• Önceki durum ve yeni durum
• İşlemi yapan kullanıcı ve o anki rolü
• Zaman damgası, saat dilimi bilgisiyle birlikte
• Gerekçe metni, ret ve revizyonda zorunlu
• Değişen alanların önceki ve sonraki değerleri

Rol bilgisini işlem anında kaydedin. Kişi bir dönem sonra başka role geçtiğinde, geçmiş kararın hangi sıfatla verildiği kaybolmasın.

Bu kayıtlara dokunulmasın: düzeltme gerekiyorsa yeni bir kayıt ekleyin, eskisini güncellemeyin. Denetlenebilirliğin tek şartı budur.

Ne işe yaradı

Bu tasarımın somut kazancı, sürecin nerede beklediğinin tartışma konusu olmaktan çıkmasıdır. Kulüp “kimdeyiz” sorusuna tek ekrandan cevap veriyor, onaycı karar için gereken bilgiyi formda buluyor, mekan çakışması etkinlik sabahı değil onay anında yakalanıyor.

Ölçülmemiş bir iyileşme iddia etmeyelim: onay süresinin ne kadar kısaldığını söyleyebilmek için, eski dönemde talebin ne zaman açıldığına dair kayıt gerekir ve WhatsApp üzerinden yürüyen bir süreçte o kayıt yoktur. Elde edilen kesin kazanım, sürecin ölçülebilir hale gelmesidir. Basamak başına bekleme süresini ilk kez bu yapıyla görebilirsiniz, iyileştirme ondan sonra gelir.

CardeaCore bu işi nasıl yapıyor

CardeaCore’un etkinlik modülü, yukarıdaki durum makinesini doğrudan uyguluyor: taslak, beklemede, ön onaylı, mekan bekliyor, revizyon, onaylandı, yayımlandı, tamamlandı, reddedildi ve iptal durumları tanımlı ve geçişler role bağlı. Talep formu etkinlik türü, kontenjan, dış konuşmacı, sponsor, bütçe ve teknik destek alanlarını koşullu olarak topluyor, bir etkinlik birden çok mekana bağlanabiliyor ve onay geçmişi kim tarafından ne zaman işlendiği bilgisiyle kaydediliyor. Ayrıntı için Cardea Campus sayfasına bakabilirsiniz.