REHBER · 02 · SÜREÇ REHBERİ
Üniversite etkinlik yönetim sistemi
Kampüs etkinliği bir formla başlayıp bir raporla biter. Arada yedi aşama, en az beş farklı paydaş ve her aşamada kaybolabilecek bir veri parçası vardır. Bu rehber döngünün tamamını, aşama başına sistemden beklenenleri ve kimin neye erişmesi gerektiğini anlatıyor.
Etkinliğin yaşam döngüsü nasıl işler?
Döngü yedi aşamadan oluşur ve her aşama bir sonrakine veri devreder. Sistemin asıl işi bu devri kesintisiz tutmaktır; aşamalardan biri sistemin dışına çıktığında, o noktadan sonraki bütün raporlar tahmine dayanır.
| Aşama | Sahibi | Sistemden beklenen | Kırılma noktası |
|---|---|---|---|
| 01 Talep | Kulüp yönetimi | Tek formda tarih, saat, mekân, tahmini katılım, bütçe ve ihtiyaç listesi. Taslak kaydedilebilmeli, aynı etkinlik gelecek dönem kopyalanabilmeli. | Form e-posta ekinde dolaşırsa hangi sürümün geçerli olduğu kaybolur. |
| 02 Onay | Danışman, kulüp ofisi, dekanlık | Kademeli onay, her kademede gerekçeli ret ve düzeltip yeniden gönderme. Bekleyen talebin kimde olduğu ve kaç gündür beklediği görünmeli. | Onay zincirinin bir halkası sistemin dışındaysa süre ölçülemez ve gecikme kimseye ait olmaz. |
| 03 Duyuru | Kulüp yönetimi | Onay anında etkinlik takvime düşsün, ilgili öğrencilere bildirim gitsin. Duyuru metni ve görseli talep kaydından türesin, ikinci kez yazılmasın. | Duyuru yalnız kulübün kendi kanalında kalırsa etkinliği yalnız mevcut üyeler duyar. |
| 04 Kayıt ve kontenjan | Kulüp yönetimi | Kontenjan dolduğunda otomatik kapanma, yedek listesi, iptal edildiğinde yedekten otomatik yükseltme. Kayıt kimliği doğrulanmış öğrenciye bağlı olsun. | Açık form üzerinden alınan kayıtlarda aynı kişi birden çok yer kapatır, kontenjan gerçeği yansıtmaz. |
| 05 Yoklama | Kulüp yönetimi, görevli | Kapıda saniyeler süren giriş, zaman damgalı kayıt, kayıt olan ile katılanın ayrı görünmesi. İnternet zayıfken de çalışan bir yol bulunmalı. | Kâğıt liste dönem sonunda dijitalleşmez; katılım sayısı tahmine döner. |
| 06 Geri bildirim | Katılımcı | Etkinlik bitiminde kısa anket, yalnız katılımı doğrulanmış kişiye açık. Sonuç etkinlik kaydına iliştirilsin. | Herkese açık anket, katılmayanın da doldurabildiği ve karşılaştırılamayan veri üretir. |
| 07 Raporlama | Kulüp ofisi, dekanlık | Kulüp, fakülte, dönem ve etkinlik türü kırılımlarında hazır rapor. Kayıt-katılım farkı, onay süresi ve bütçe gerçekleşmesi görünsün. | Rapor elle derleniyorsa dönem sonunda haftalar gider ve sayılar tartışmalı kalır. |
Talep aşamasında ne sorulmalı?
Talep formu, sonraki bütün adımların girdisidir. Buradaki eksik alan onayı geciktirir, fazladan alan ise kulübün formu doldurmaktan kaçınmasına yol açar. Denge, onay verecek kişinin karar için gerçekten ihtiyaç duyduğu alanlarda kurulur.
Asgari set şudur: etkinlik adı ve türü, tarih ve saat aralığı, mekân talebi, tahmini katılımcı sayısı, dış konuk olup olmadığı, bütçe ihtiyacı ve teknik ihtiyaç listesi. Bunların üzerine eklenen her alan için "onay veren bunu okuyup karar değiştirir mi" sorusunu sorun.
Taslak kaydı ve geçmiş etkinliği kopyalama, kullanımı en çok artıran iki küçük özelliktir. Kulüpler her dönem benzer etkinlikleri tekrarlar; sıfırdan form doldurmak gereksiz bir sürtünmedir.
Onay zinciri nasıl kurgulanmalı?
Zincir, kurumun gerçek karar mekanizmasını yansıtmalı ve tamamı sistem içinde olmalıdır. Bir kademe e-postada yürüyorsa, o kademedeki bekleme süresi hiçbir raporda görünmez ve gecikme kimseye ait olmaz.
Üç kural işe yarıyor. Her kademede ret gerekçeli olmalı ve talep düzeltilip yeniden gönderilebilmeli; bekleyen talep kimdeyse orada ve kaç gündür beklediği yazılı olmalı; onay verecek kişi izinliyse vekâlet tanımlanabilmeli. Üçüncüsü olmadığında akış her tatilde kilitlenir.
Kayıt, kontenjan ve yoklama nasıl bağlanır?
Üçü tek bir kimlik üzerinde birleşmelidir. Kayıt kurum kimliğiyle yapılıyorsa kontenjan gerçeği yansıtır, yoklama da aynı kişiye bağlanır ve kayıt-katılım farkı anlamlı bir gösterge hâline gelir.
Kontenjan tarafında yedek listesi ve iptalde otomatik yükseltme, dolu görünen ama yarısı gelmeyen etkinlikleri düzeltir. Yoklama tarafında ise tek ölçüt kapıdaki hızdır: iki yüz kişilik bir girişte akış kuyruğa dönüyorsa, görevli listeyi bırakıp herkesi içeri alır ve veri kaybolur. Yöntemlerin ayrıntılı karşılaştırması için yoklama sistemleri rehberine bakın.
Geri bildirim ne zaman ve kime açılmalı?
Anket etkinlik biter bitmez ve yalnız katılımı doğrulanmış kişilere açılmalıdır. Herkese açık bir form, katılmayanların da doldurabildiği ve etkinlikler arasında karşılaştırılamayan veri üretir.
Soru sayısını üçle beş arasında tutun. Uzun anket doldurulmaz, doldurulmayan anket ise düşük katılım yüzünden yanıltıcı sonuç verir. Aynı soruların bütün etkinliklerde sabit kalması, dönem sonunda karşılaştırma yapabilmenin tek koşuludur.
Kimin hangi yetkiye ihtiyacı var?
Yetkilendirmede kural basittir: her rol işini yapmak için gereken en dar veriyi görür. Aşağıdaki tablo, kampüslerde tekrar eden rol kümesini ve sınırlarını gösteriyor.
| Rol | Süreçteki işi | Görmesi gereken | Görmemesi gereken |
|---|---|---|---|
| Öğrenci | Görür, kayıt olur | Etkinlik listesi, kendi kayıtları, geri bildirim | Başkasının kayıt ve katılım verisi |
| Kulüp üyesi | Yukarıdakiler + kulüp içi görünürlük | Kulüp sayfası, üye duyuruları | Üye kişisel verisi, bütçe |
| Kulüp yönetimi | Oluşturur, yönetir | Talep açma, duyuru, kontenjan, yoklama, kendi kulübünün raporu | Başka kulübün verisi |
| Kulüp danışmanı | İlk onay | Danışmanı olduğu kulübün talepleri ve raporları | Diğer kulüplerin süreçleri |
| Kulüp ofisi / SKS | Koordinasyon onayı | Tüm talepler, mekân çakışması, kampüs takvimi | Ders ve not verisi |
| Dekanlık / rektörlük | Son onay, izleme | Fakülte ve kampüs geneli raporlar, onay kuyruğu | Bireysel geri bildirim metinleri |
| Mekân ve teknik birim | Kaynak tahsisi | Onaylı etkinliklerin mekân ve ekipman ihtiyacı | Katılımcı kişisel verisi |
| Güvenlik | Giriş kontrolü | Gün bazlı etkinlik listesi, beklenen katılım | Katılımcı listesi detayı |
Tabloda en çok tartışılan satır dekanlık satırıdır. İzleme yetkisi, bireysel geri bildirim metinlerini okumayı kapsamamalıdır; aksi hâlde öğrenci dürüst cevap vermez ve anket verisi değersizleşir. Toplu sonuç görünür, tekil metin görünmez.
Kampüs içi paydaşlar kimler?
Etkinlik süreci yalnız kulüp ile dekanlık arasında geçmez. Sistemi kurarken masaya çağrılmayan her paydaş, sonradan sürecin dışında kalır ve kendi tablosunu tutmaya devam eder.
- Sağlık, kültür ve spor birimi: kulüp kayıtları, bütçe ve kampüs takvimi.
- Mekân ve destek hizmetleri: salon tahsisi, kurulum, temizlik planı.
- Bilgi işlem: kurum girişi, ağ, ekran ve ses sistemleri.
- Kurumsal iletişim: duyuru dili, görsel kimlik, dış basına açılan etkinlikler.
- Güvenlik: gün bazlı etkinlik listesi ve beklenen katılımcı sayısı.
- Mali işler: bütçe onayı ve gerçekleşme.
- Hukuk ve veri sorumlusu: aydınlatma metni, dış konuk sözleşmeleri, görsel kayıt izni.
En sık atlanan iki paydaş güvenlik ve mali işlerdir. Güvenliğe listeyi zamanında vermeyen etkinlik kapıda tıkanır; mali işleri sürece almayan kulüp, harcamayı etkinlikten sonra belgelemeye çalışır.
Sistemin başarısı nasıl ölçülür?
Dört gösterge yeterlidir: talepten onaya geçen ortalama gün, yoklaması sistemden alınan etkinliklerin oranı, kayıt-katılım oranı ve dönem raporunun hazırlanma süresi. Dördü de kurulumdan önce ölçülüp sonra tekrar bakılırsa, sistemin işe yarayıp yaramadığı tartışma konusu olmaktan çıkar.
CardeaCore bu döngüyü nasıl yürütüyor
CardeaCore'da bir etkinlik tek kayıt olarak açılır ve yedi aşamanın tamamı o kayıt üzerinde ilerler. Talep formu kurumun tanımladığı etkinlik türlerinden beslenir, onay zinciri kurumun kademelerine göre kurulur, onay anında etkinlik takvime düşer ve ilgili öğrencilere bildirim gider. Kayıt kurum kimliğine bağlıdır, kontenjan dolunca yedek listesi devreye girer, kapıda QR ile alınan yoklama aynı kayda yazılır.
Dekanlık tarafında fakülte ve dönem kırılımlı raporlar hazır durur; kayıt-katılım farkı ve onay süresi ayrı gösterge olarak görünür. Rol tablosundaki sınırlar yetkilendirmede karşılığını bulur: bireysel geri bildirim metinleri toplu sonuçların arkasında kalır.
Demoyu inceleyin Diğer rehberler
Sık sorulan sorular
Etkinlik yönetim sistemi ne yapar?
Bir kampüs etkinliğini talep aşamasından dönem sonu raporuna kadar tek kayıt üzerinde yürütür. Onay zincirini, duyuruyu, kontenjanlı kaydı, yoklamayı ve geri bildirimi aynı etkinliğe bağlar. Değeri, bu adımların birbirine veri taşımasından gelir.
Onay akışı kaç kademeli olmalı?
Kurumun gerçek karar mekanizması kaç kademeliyse o kadar. Yaygın kurgu danışman, kulüp ofisi ve dekanlık şeklinde üç kademedir. Kademe sayısını sistemde artırmak kolaydır ama her kademe onay süresine gün ekler, bu yüzden gereksiz halkaları çıkarın.
Kayıt olan ile katılan arasındaki farkı neden ayrı tutmalı?
İkisi arasındaki oran, duyurunun mu yoksa zamanlamanın mı sorunlu olduğunu ayırt eder. Kayıt yüksek katılım düşükse duyuru işini yapmış, saat ya da mekân uygun değildir. Tek bir sayı tutan sistemde bu ayrım kaybolur.
Mekân çakışmasını sistem çözebilir mi?
Mekân takvimi sisteme bağlıysa çözer, değilse yalnız uyarır. Pratikte çoğu kurumda mekân ayrı bir birimde yönetilir; bu durumda etkinlik sistemi onay adımına mekân teyidini bir alan olarak koymalı ve teyit gelmeden onayı tamamlamamalıdır.
Akreditasyon raporları için hangi veri gerekir?
Etkinlik sayısı ve türü, katılımcı sayısı ve öğrenci profili kırılımı, kazanım ya da tema eşleşmesi ile geri bildirim sonuçları. Bu veriler ancak kayıt, yoklama ve anket aynı etkinliğe bağlıysa geriye dönük çıkarılabilir. Dönem bitince toplanmaya çalışılırsa çıkmaz.
Küçük bir kampüste bu sistem gerekli mi?
Dönemde otuz etkinliğin altında kalan ve onay zinciri iki kişiden ibaret olan bir kampüste paylaşılan bir takvim ve bir tablo çoğu işi görür. Sistem ihtiyacı, onay zinciri uzayınca ve kurumsal rapor istenmeye başlayınca ortaya çıkar.