Kulüp yönetim yazılımı nasıl seçilir

Kulüp yönetim yazılımına gerçekten ihtiyacınız var mı?

İhtiyaç, kulüp sayısıyla değil, tekrar eden işin hacmiyle ölçülür. Dönemde otuz etkinliğin altında kalan, onay zinciri iki kişiden ibaret olan ve kurumsal rapor istenmeyen bir kampüste iyi kurulmuş bir tablo ile paylaşılan bir takvim çoğu işi görür.

Karar vermeden önce üç rakamı yazın: aktif kulüp sayısı, geçen dönemki toplam etkinlik sayısı, bir etkinlik talebinin onaydan geçmesi için dokunan kişi sayısı. Sonra bir de şunu ekleyin: dönem sonu raporu kaç kişinin kaç saatini aldı. Bu dört sayı, hem alıp almama kararını hem de bütçenin üst sınırını belirler.

Yazılımın çözmediği bir şey var: kimsenin sahiplenmediği süreç. Onay adımı belirsizse, sistemde de belirsiz kalır. Süreç önce kâğıt üzerinde netleşmeli.

Hangi yaklaşım hangi kampüse uyar?

Piyasada dört yaklaşım var ve hiçbiri diğerinden mutlak olarak iyi değil. Doğru seçim, kampüsün ölçeğine ve kurumsal raporlama baskısına göre değişir.

Bir kampüs aynı anda birden çok yaklaşımda olabilir. Yaygın bir durum şudur: kurumun sisteminde kayıtlı bir kulüp modülü vardır, kulüpler onu kullanmaz ve gerçek iş genel amaçlı araçlarda yürür. Bu, en pahalı hâldir; lisans ödenir, fayda alınmaz.

Değerlendirme kriterleri hangileri olmalı?

Değerlendirmeyi özellik listesi üzerinden yapmayın, soru listesi üzerinden yapın. Aşağıdaki tablo, demo sırasında ekranda görülmesi gereken maddeleri içeriyor. Ağırlık sütunu bizim gördüğümüz sıklığa göre; kurumunuza göre değiştirin.

Tabloda en çok atlanan iki satır var. Birincisi dönem devri: kulüp yönetimleri her yıl değişir, yetki aktarımı zahmetliyse ikinci yıl kullanım çöker. İkincisi yoklamanın kapıdaki hızı; teoride çalışan bir akış, iki yüz kişilik bir girişte kuyruğa dönüşüyorsa öğrenci onu kullanmaz.

Satın alma sürecinde hangi soruları sormalı?

Aşağıdaki sorular, sunumda güzel görünen ürünlerle canlıda çalışan ürünleri birbirinden ayırır. Cevapları yazılı isteyin.

1. Şu anda kaç kurumda canlı kullanılıyor ve bunların kaçı bizim ölçeğimizde?
2. Referans kurumdaki kulüp yöneticileriyle doğrudan konuşabilir miyiz?
3. Verimiz nerede tutuluyor, veri işleyen sözleşmesi ve aydınlatma metni hazır mı?
4. Sözleşme sonunda veriyi hangi formatta ve ne kadar sürede alıyoruz?
5. Kurum girişimizle (SSO) entegrasyon standart mı, ek geliştirme mi?
6. Onay akışını biz mi tanımlıyoruz, yoksa her değişiklik geliştirme talebi mi?
7. Yıllık fiyat neye göre artıyor, üç yıllık tavan verebilir misiniz?
8. Kurulum, veri aktarımı, eğitim ve destek fiyata dahil mi?
9. Destek hangi saatlerde ve hangi kanaldan, yanıt süresi taahhüdü nedir?
10. Son bir yılda hangi özellikler eklendi, yol haritası nasıl belirleniyor?
11. Kesinti oldu mu, ne kadar sürdü, nasıl bildirildi?
12. Öğrenci verisi başka amaçla işleniyor mu, model eğitiminde kullanılıyor mu?

Dördüncü ve on ikinci sorulara verilen cevaplar en çok bilgi taşır. Veri çıkışını kolaylaştıran bir sağlayıcı, sizi tutmak için sözleşmeye değil ürüne güveniyor demektir.

Pilot nasıl kurgulanır?

Pilotun amacı ürünü denemek değil, tam bir döngüyü sonuna kadar götürmektir. Talepten rapora uzanan bir turu tamamlamayan pilot, karar için veri üretmez.

1. Kapsamı daraltın. Üç ila beş kulüp seçin ve bunlardan biri mutlaka en dağınık çalışan olsun. En düzenli kulüple yapılan pilot yanıltır.
2. Başarı ölçütünü önceden yazın. Örnek: talep-onay süresi ortalama üç günün altına insin, etkinliklerin yüzde sekseninde yoklama sistemden alınsın, dönem raporu iki saatten kısa sürede çıksın.
3. Gerçek etkinlikle çalışın. Test verisiyle yapılan pilot, kapıdaki kuyruğu ve internetin zayıf olduğu salonu göstermez.
4. Onay zincirini eksiksiz kurun. Danışman, kulüp ofisi, dekanlık: zincirdeki herkes pilotta yer almalı, yoksa asıl darboğaz görünmez.
5. Dört ila altı hafta sonra kapatın. Ölçütlere bakıp evet ya da hayır deyin. Uzatılan pilot, karar verilmediğinin başka bir adıdır.

Hangi hatalar tekrar ediyor?

Aşağıdakiler, sürecin sonunda pişmanlık üreten ve önceden görülebilen hatalar.

• Özellik listesiyle karar vermek. Uzun liste, kullanılmayan özelliklerin listesidir. Beş kritik işin ekranda ne kadar sürede yapıldığına bakın.
• Kulüp yöneticilerini karara katmamak. Ürünü günlük kullanan onlardır. Katılmadıkları karar, benimsenmeyen ürün olur.
• Öğrenci tarafını sonraya bırakmak. Yönetim ekranı mükemmel, öğrenci ekranı zayıf olan bir üründe veri hiç oluşmaz, çünkü öğrenci sisteme girmez.
• Veri göçünü küçümsemek. Eski üye listeleri ve geçmiş etkinlikler aktarılmazsa sistem boş başlar ve boş sistem güven vermez.
• Eğitim yerine kılavuz vermek. Yirmi sayfalık kılavuz okunmaz. Kırk beş dakikalık uygulamalı oturum, dönem boyunca gelen destek talebini azaltır.
• KVKK'yı en sona bırakmak. Aydınlatma metni, açık rıza gereken alanlar ve saklama süreleri sözleşmeden önce netleşmezse pilot canlıya çıkamaz.

Ne zaman yazılım almamalı?

Üç durumda cevap açıkça hayırdır. Kulüp sayısı azsa ve etkinlikler seyrekse; süreç henüz kâğıt üzerinde bile tanımlı değilse; ürünü sahiplenecek bir kişi kurumda belirlenmemişse. Üçüncüsü en belirleyicisidir. Sahibi olmayan sistem, kurulduktan üç ay sonra kullanılmayan sistemdir.

CardeaCore bu tabloda nerede duruyor

CardeaCore, tablodaki dördüncü kategoride: adanmış kampüs platformu. Kulüp üyeliği, etkinlik talebi ve onay zinciri, duyuru, kontenjanlı kayıt, kapıda QR ile yoklama ve dekanlık tarafındaki raporlama tek yerde duruyor. Onay akışı kurumun kendi kademelerine göre tanımlanıyor, dönem devri yetki aktarımıyla yapılıyor.

Kampüsünüz yukarıdaki eşiklerin altındaysa, dürüst tavsiyemiz beklemeniz. Kulüp sayısı ve etkinlik hacmi arttığında, elinizde yukarıdaki dört rakam hazır olarak konuşalım.

Demoyu inceleyin Diğer rehberler

Sık sorulan sorular