Kurumsal LMS satın alma kararı, bir ürün demosunda en çok özelliği görmekten ibaret değildir. Komisyonun asıl görevi; kurumun iş hedeflerini, bilgi güvenliği yükümlülüklerini, entegrasyon ihtiyaçlarını ve uzun vadeli çıkış seçeneklerini karşılaştırılabilir kanıtlara dönüştürmektir. İyi yazılmış bir teknik şartname, satıcıların aynı sorulara aynı formatta yanıt vermesini ve tekliflerin yalnızca pazarlama diliyle değil, kabul testleriyle değerlendirilmesini sağlar.
Bu rehber, RFP veya ihale dokümanına uyarlanabilecek beş maddeyi ve 100 puanlık örnek bir puanlayıcıyı sunar. Metin, herhangi bir sağlayıcıyı peşinen seçmez. Qulak da ancak kurumunuzun onaylı gereksinimleriyle eşleştiği, sunduğu kanıtlar kabul testlerinde doğrulandığı ve toplam maliyeti alternatiflerle şeffaf biçimde karşılaştırıldığı durumda değerlendirilmelidir.
Erken karar desteği: Taslak şartnamenizdeki kritik maddeleri, entegrasyon sınırlarını ve kabul testlerini birlikte gözden geçirmek isterseniz Qulak ekibiyle iletişime geçin . Bu görüşme, adayların aynı ölçütlerle karşılaştırılmasının yerini tutmaz; gereksinimleri netleştirmeye yardımcı olur.
Satın alma kararını ürün demosu değil, kanıt seti belirlemeli
Komisyon, her kriter için üç soruyu önceden yazmalıdır: Ne isteniyor? İsteklinin hangi belgesi, ekranı veya test çıktısı bunu kanıtlayacak? Nasıl kabul edilecek? Kabul testi başarısız olursa düzeltme süresi, sorumluluk ve yeniden test yöntemi ne olacak? Bu yaklaşım, “kullanıcı dostu”, “güvenli” veya “yapay zekâ destekli” gibi tek başına ölçülemeyen ifadeleri somutlaştırır.
İhtiyaç listesini hazırlarken mevcut kullanıcı sayısı kadar gelecekteki büyümeyi, çalışan dışı kullanıcıları, içerik sahiplerini, rapor tüketicilerini, veri saklama sürelerini ve tedarikçi değişikliği senaryosunu da yazın. LMS, LXP ve Skills OS ayrımını netleştirmek de kapsamın gereksiz yere genişlemesini önler.
İhale dokümanına eklenebilecek 5 kopyalanabilir şartname maddesi
Aşağıdaki örnekler doğrudan kopyalanabilir; ancak kurumunuzun mevzuatına, veri sınıflandırmasına ve mevcut mimarisine göre hukuk, bilgi güvenliği ve satın alma ekiplerince son hâline getirilmelidir.
1. Standartlar, içerik uyumluluğu ve veri taşınabilirliği
İçerik ve öğrenme kaydı standartlarını sürüm bazında istemek, tedarikçi değişikliğinde kilitlenme riskini azaltır.
İstekli, teklif ettiği çözümün desteklediği öğrenme içeriği ve kayıt standartlarını (varsa SCORM 1.2, SCORM 2004, xAPI veya eşdeğeri) sürüm bazında beyan edecektir. Kullanıcı, içerik, tamamlanma, puan, sertifika ve denetim kayıtlarının makine tarafından işlenebilir formatta dışa aktarılmasına ilişkin veri sözlüğünü, örnek dışa aktarım dosyasını ve geri yükleme/çıkış prosedürünü sunacaktır. İdare, örnek içerik ve örnek kayıt setiyle kabul testi yapacaktır.
2. Bilgi güvenliği, KVKK ve veri yaşam döngüsü
“Güvenli” ifadesi yerine kontrolleri, sorumlulukları ve veri yaşam döngüsünü görünür kılın.
İstekli; veri işleyen ve alt işleyen listesini, veri işleme amaçlarını, veri lokasyonlarını, saklama ve silme sürelerini, aktarımda ve saklamada kullanılan şifreleme kontrollerini, erişim yetkisi modelini, güvenlik olayı bildirim sürecini ve bağımsız denetim/sertifika kanıtlarını sunacaktır. İdareye ait veriler, sözleşme sona erdiğinde belirlenen formatta iade edilecek veya doğrulanabilir silme kaydıyla imha edilecektir. Kişisel verilerin işlenmesi, kurumun KVKK rol ve talimatlarıyla sınırlandırılacaktır.
3. Kimlik, API ve kurumsal entegrasyonlar
Entegrasyon maddesi, yalnızca “API var” demek yerine protokolleri, kapsamı ve hata yönetimini tarif etmelidir.
İstekli, çözümün desteklediği kimlik doğrulama ve kullanıcı yaşam döngüsü yöntemlerini (ör. SAML 2.0, OIDC, SCIM), REST API uç noktalarını, API kimlik doğrulamasını, hız limitlerini, sürümleme politikasını, hata kodlarını ve loglama yaklaşımını dokümante edecektir. İdare; kurumsal kimlik sağlayıcı, insan kaynakları sistemi ve gerekli diğer sistemlerle pilot entegrasyon yaparak kullanıcı açma, rol değişikliği, pasifleştirme ve rapor aktarımı senaryolarını test edecektir.
4. Erişilebilirlik, kullanılabilirlik ve çoklu cihaz desteği
Erişilebilirliği tasarım niyetiyle değil, test edilebilir kriterlerle satın alın.
İstekli, web arayüzünün hedeflediği erişilebilirlik seviyesini ve istisnalarını açıkça beyan edecektir. İdare; klavye ile kullanım, odak görünürlüğü, renk kontrastı, form etiketleri, ekran okuyucu uyumu, altyazı/transkript ve duyarlı tasarım senaryolarını örnek kullanıcı akışlarıyla test edecektir. WCAG 2.2 AA ile ilişkilendirilen uygunluk iddiaları, kapsam ve kanıtla birlikte sunulacak; eksikler teslimat planında açıkça listelenecektir.
5. Raporlama, denetim izi ve yapay zekâ yönetişimi
Raporların kim tarafından, hangi veriyle ve hangi dönem için üretildiği izlenebilir olmalıdır. AI özellikleri varsa, ayrı bir risk ve kontrol beyanı isteyin.
İstekli; yönetici, eğitmen ve denetçi rolleri için örnek raporları, filtreleri, dışa aktarım formatlarını, zaman damgası ve değişiklik geçmişi içeren denetim izi kapsamını sunacaktır. Yapay zekâ kullanılan her işlev için işlenen veri alanları, veri minimizasyonu yaklaşımı, saklama süresi, model/alt işleyen kullanımı, çıktıların doğruluk sınırları, insan onayı, itiraz/düzeltme yolu ve kapatma seçeneği açıklanacaktır. AI çıktıları, kurumun insan denetimi ve onaylı yönetişim süreci olmadan yüksek etkili personel kararlarının tek dayanağı yapılamaz.
RFP puanlayıcı: 100 puanlık tarafsız örnek
Aşağıdaki dağılım, her kurumun önceliğine göre revize edilebilir. Önemli olan ağırlıkların ihale öncesinde sabitlenmesi ve sonradan bir satıcı lehine değiştirilmemesidir. Her alt kriteri 0-5 arasında puanlayıp ağırlıklı puanı = (verilen puan / 5) × ağırlık formülüyle hesaplayabilirsiniz.
| Değerlendirme alanı | Ağırlık | Kanıt ve kabul testi |
|---|
| İşlevsel uygunluk | 25 | Senaryo bazlı demo, rol/kurs/sınav akışları, örnek kullanıcı kabul testi. |
| Güvenlik ve KVKK | 20 | Veri akış şeması, alt işleyenler, erişim modeli, olay süreci ve sözleşme eki. |
| Entegrasyon ve taşınabilirlik | 15 | SSO/API pilotu, örnek dışa aktarım, veri sözlüğü ve çıkış senaryosu. |
| Raporlama ve denetim izi | 10 | Örnek raporlar, filtreler, zaman damgası, rol bazlı görünürlük ve kayıt geçmişi. |
| Erişilebilirlik ve deneyim | 10 | Klavye, ekran okuyucu, altyazı ve mobil akışlar; bulgular için düzeltme planı. |
| Uygulama ve destek modeli | 10 | Proje planı, sorumluluk matrisi, destek kanalları, eğitim ve bilgi aktarımı. |
| Toplam sahip olma maliyeti | 10 | Lisans, kurulum, entegrasyon, içerik taşıma, destek, artış varsayımları ve çıkış maliyeti. |
| Toplam | 100 | Teklif, kanıt ve kabul testi sonuçları birlikte değerlendirilir. |
Teklif dosyasında mutlaka kanıt isteyin
- Her “desteklenir” ifadesi için sürüm, kapsam, lisans bağımlılığı ve istisnalar.
- Güvenlik mimarisi, veri akışları, sorumluluk matrisi ve alt işleyen bildirim süreci.
- Bir örnek içerik, bir örnek kullanıcı ve bir örnek rapor üzerinden canlı kabul testi.
- Veri ihracı, sözleşme sonu iade/silme ve tedarikçi değişikliği için yazılı çıkış planı.
- Tek seferlik kurulum ile tekrar eden ücretlerin ayrıştırıldığı toplam maliyet tablosu.
- Referans verilecekse kurum adı, kapsam ve paylaşım izninin doğrulanabilir olması; aksi hâlde anonim örnek kullanılması.
LMS veri taşıma ve geçiş rehberindeki kontrol noktaları, özellikle mevcut bir sistemden çıkış planlayan komisyonlar için şartnameye kabul testi eklemeye yardımcı olur. Sağlayıcının sunmadığı bir özelliği varsaymak yerine, “teklif kapsamında var mı, hangi lisansla, hangi kanıtla?” sorusunu yazılı olarak sorun.
AI kullanılan LMS senaryolarında sınırlar nasıl yazılmalı?
Yapay zekâ, içerik taslağı, arama, öneri, sınıflandırma veya rapor özetleme gibi süreçlerde yardımcı olabilir; ancak “AI var” ifadesi tek başına kalite veya uygunluk kanıtı değildir. İhale dokümanı, öncelikle veri minimizasyonunu istemelidir: Gereksiz kişisel veri, özel nitelikli veri, serbest metin veya çalışan değerlendirme notu modele aktarılmamalıdır. İşlenen alanlar, amaç, saklama süresi ve silme yöntemi teklif ekinde gösterilmelidir.
İkinci sınır insan denetimidir. AI tarafından üretilen bir içerik, beceri eşlemesi, risk işareti veya öneri yayımlanmadan ve çalışanı etkileyen bir sürece girmeden önce yetkili bir kişi tarafından incelenebilmelidir. Sistem; önerinin kaynağını, tarihini, kullanılan girdileri ve yapılan düzeltmeleri uygun ölçüde kaydetmelidir. Kurum, bir çıktıya itiraz edebilmeli, yanlış sonucu düzeltebilmeli ve gerektiğinde AI işlevini kapatabilmelidir.
Üçüncü sınır kurumsal yönetişimdir. AI işlevleri için sahip, risk sınıfı, onay mercii, periyodik gözden geçirme, olay bildirim yolu ve tedarikçinin model değişikliği bildirim süreci tanımlanmalıdır. Bu rehber hukuki görüş yerine geçmez; KVKK, iş hukuku, kurum politikaları ve uygulanabilir sektörel yükümlülükler uzman ekiplerce ayrıca değerlendirilmelidir.
Qulak hangi koşullarda değerlendirmeye alınabilir?
Qulak’ı değerlendirmek isteyen komisyon, önce yukarıdaki maddeleri kendi kurumuna uyarlayıp tüm adaylara aynı soruları yöneltmelidir. Ardından Qulak’ın teklifindeki kapsamı; içerik standartları, kimlik ve API entegrasyonları, güvenlik belgeleri, raporlama, erişilebilirlik, AI yönetişimi, uygulama yaklaşımı ve toplam maliyet başlıklarında kanıtlamasını istemelidir. Bir özelliğin web sitesinde anılması, tek başına kabul edilmiş gereksinim anlamına gelmez.
Uygunluk; yazılı yanıt, kontrollü demo, örnek veriyle pilot ve sözleşme ekleri birlikte incelenerek belirlenmelidir. Qulak’ın koşullarınıza uygunluğu teyit edilirse, komisyon satın alma kararını ölçülebilir kriterler ve kayıt altına alınmış puanlarla verebilir. Uygunluk kanıtlanmıyorsa başka bir sağlayıcıya yönelmek, şartnamenin tarafsızlık ilkesinin doğal sonucudur.
Şartnamenizi kanıt odaklı hâle getirin
İhtiyaç listenizi, puanlama matrisinizi veya kabul testi taslağınızı paylaşın. Qulak’ın da diğer adaylarla aynı ölçütlerde değerlendirilmesini sağlayacak soruları birlikte netleştirelim.
LMS satın alma görüşmesi başlat
Sıkça Sorulan Sorular
LMS ihalesinde yalnızca özellik listesi yeterli midir?
Hayır. Özelliklerin yanında kanıt türü, kabul testi, veri taşınabilirliği, güvenlik belgeleri, toplam sahip olma maliyeti ve sözleşme sonu çıkış planı da puanlanmalıdır.
Bir LMS sağlayıcısının AI özellikleri nasıl değerlendirilmelidir?
Veri minimizasyonu, insan onayı, kayıt ve denetim, modelin sınırları, veri saklama süresi ve kurumun risk değerlendirmesi birlikte incelenmelidir. AI çıktıları, insan denetimi olmadan yüksek etkili personel kararlarının tek dayanağı yapılmamalıdır.
Qulak satın alma sürecinde ne zaman değerlendirilmelidir?
Qulak; kurumun onaylanmış gereksinimleriyle eşleştiği, güvenlik ve entegrasyon kanıtları kabul testlerinde doğrulandığı ve ticari koşullar alternatiflerle karşılaştırıldığı durumda adaylardan biri olarak değerlendirilmelidir.
RFP puanları ihale sonrasında değiştirilebilir mi?
Şeffaflık için ağırlıklar, puan ölçeği ve kanıt kuralları tekliflerden önce onaylanmalıdır. Zorunlu bir değişiklik olursa gerekçesi, kapsamı ve tüm isteklilere eşit uygulanacağı kayıt altına alınmalıdır.
İçerik yaklaşımı: kanıt, tarafsızlık ve yönetişim
Bu rehber, satın alma ekiplerinin karşılaştırılabilir şartname ve kabul testi yazmasına yardımcı olmak için hazırlanmıştır. Ürün uygunluğu, her kurumun doğrulama sürecine ve sözleşme koşullarına bağlıdır.
Kaynaklar
Teknik şartnameyi kurumunuzun hukuk, bilgi güvenliği, erişilebilirlik ve satın alma ekipleriyle birlikte gözden geçirin. Aşağıdaki kaynaklar çerçeve oluşturmak içindir:
İlgili rehberler
