Çalışan sertifikalarını takip eden, yenileme hatırlatmaları gönderen, denetimlere hazır kayıtlar üreten ve kurumsal eğitimleri yöneten bir web uygulamasını nasıl planlayıp tasarlayacağınızı ve inşa edeceğinizi öğrenin.
Ekran taslağı çizmeye veya teknoloji yığını seçmeye başlamadan önce, kurumsal eğitim yönetimi web uygulamasını neden inşa ettiğinizi netleştirin. Farklı hedefler çok farklı ürün kararlarına yol açar—ve en net hedef ifadesi kapsam kaymasına karşı en iyi savunmalardan biridir.
Çoğu ekip şu (veya birkaç) sorunu çözmeye çalışır:
Birincil hedefinizi tek cümleyle yazın (ör. “Gecikmiş uyumluluk eğitimlerini %30 azalt ve denetim hazırlık süresini yarıya indir”). Her özellik isteğini bunu kullanarak değerlendirin.
Temel kullanıcı gruplarınızı ve her birinin sürtünme olmadan yapması gereken tek işi tanımlayın:
Dış denetçilere sahip değilseniz, dahili incelemeler için bir “denetim görünümü”na ihtiyaç duyabilirsiniz.
Aylık olarak gerçekten gözden geçireceğiniz kısa bir liste seçin:
Çalışan sertifika takibi için pratik bir v1 genelde şunları içerir: kullanıcı hesapları, eğitim atamaları, tamamlamanın yakalanması, temel hatırlatmalar ve basit raporlama.
İleri seviye öğeleri (derin analizler, karmaşık öğrenme yolları, çok kiracılı platform özellikleri) “sonra”ya bırakın—ancak bunlar lansman için zorunluysa dahil edin.
Özellikleri veya ekranları seçmeden önce, eğitim ve sertifika takibinin şirketinizde bugün nasıl işlediğini netleştirin. Amaç, gerçek adımları, gerçek istisnaları ve gerçek sahipliği yakalamaktır—böylece uygulama günlük operasyonlarla uyumlu olur, idealize edilmiş bir süreçle değil.
İK, uyumluluk ve farklı departmanlardan birkaç takım lideri ile kısa görüşmeler (30–45 dakika) ile başlayın. Onlardan yakın zamanda gerçekleşmiş bir eğitim döngüsünü baştan sona anlatmalarını isteyin:
Sıkıntıları birebir not alın—bu alıntılar daha sonra önceliklendirme için faydalı olur.
Bulgularınızı basit bir iş akışı haritasına (bu aşamada bir beyaz tahta fotoğrafı bile yeterlidir) dönüştürün. En azından şu kullanım durumlarını kapsayın:
Her adımda kimin ne yaptığını tanımlayın: çalışan, yönetici, İK/yönetici veya eğitmen.
Eğitim sistemlerinin denetimlerde başarısız olduğu yerler kenar durumlardır. Yükleniciler, çoklu lokasyon kuralları (site başına farklı standartlar), muafiyetler (önceki haklar) ve izin durumu (tarihsel geçmişi kaybetmeden son tarihlerde duraklatma) gibi senaryoları açıkça belgeleyin.
İş akışını kabul kriterleriyle birlikte kullanıcı hikayelerine çevirin. Örnek: “Bir İK yöneticisi olarak, Konum A'daki tüm depo personeline 'Forklift Güvenliği' atayabilmeli, onaylı muafiyetleri hariç tutabilmeli ve kimlerin geciktiğini görebilmeliyim.” Bu hikayeler yapım planınız ve ortak kabül tanımınız olur.
Kurumsal bir eğitim yönetimi web uygulaması veri modeline bağlıdır. Varlıklarınız ve geçmişiniz açık ise, çalışan sertifika takibi çok daha kolay olur: atamalar izlenebilir, yenilemeler öngörülebilir ve uyumluluk raporlaması savunulabilir.
İlk olarak bariz yapı taşlarını modelleyin:
Kural: bir şey "atanabiliyorsa", "tamamlanabiliyorsa" veya "muaf tutulabiliyorsa" genelde kendi tablosunu/nesnesini hak eder.
Her atama ve sertifika örneği için atanmış, devam ediyor, tamamlandı, süresi doldu, muaf gibi açık durum değerleri saklayın. Durumu yalnızca tarihlerden çıkarmayın—zamanla ekipler "geç tamamlandı", "yönetici tarafından muaf" veya "yenileme ilerliyor ama süresi doldu" gibi kenar durumlar isteyecektir.
Denetime hazır sertifika kayıtları üretmek için kanıtı gerçekleştiği anda yakalayın:
Kanıtı kim sundu ve kim onayladıysa onu da saklayın.
Üzerine yazmak yerine ekleyin. Atamalara, son tarihlerine, tamamlama sonuçlarına ve manuel düzenlemelere yapılan değişikliklerin bir denetim izini tutun. En azından şunu kaydedin: kim neyi ne zaman değiştirdi ve önce/sonraki değerler.
Bu değişiklik geçmişi soruşturmaları destekler ("neden bu muaf edildi?"), sonraki sertifika yenileme hatırlatmalarını basitleştirir ve entegrasyonları (SSO ve HRIS entegrasyonu güncellemeleri gibi) daha güvenli hale getirir—çünkü neyin değiştiğini görüp gerektiğinde güvenle geri alabilirsiniz.
Erişim kontrolü, eğitim uygulamalarının ya sorunsuz ya da destek kabusu gibi hissettirdiği yerdir. Net bir rol modeli günlük görevleri basitleştirir (çalışanlar öğrenir, yöneticiler onaylar) ve hassas verileri korur (İK kayıtları, kanıt dosyaları, dışa aktarımlar).
Çoğu ekip ihtiyaçların %95'ini beş rol ile karşılayabilir:
Zamanla nüans gerekirse yeni roller icat etmek yerine izinlerle (aşağıda) nüans ekleyin.
İzinleri fiiller şeklinde yazın ve bunları ekranlara/API uç noktalarına eşleyin:
Bu, "Yöneticiler dışa aktarabilir mi?" veya "Yazarlar çalışan kanıtlarını görebilir mi?" gibi soruları tartışmadan yanıtlamayı kolaylaştırır.
Hedef kitlenize uyan giriş seçeneklerini belirleyin:
Çok kiracılı eğitim platformu inşa ediyorsanız kiracı sınırlarını her yerde uygulayın: veritabanı sorguları kiracı kimliğiyle sınırlandırılmış, dosya depolama kiracı bazında bölünmüş ve günlükler müşteriler arasında karışmayacak şekilde olmalı. Bunu bir güvenlik özelliği olarak test edin, kolaylık olarak değil.
Bir eğitim uygulaması netlikle başarılı olur veya başarısız olur. Çoğu kullanıcı "keşfetmiyor"—atanmış eğitimi hızlıca bitirmeye, tamamlamayı kanıtlamaya veya neyin geciktiğini görmeye çalışıyor. Üç temel deneyimi tasarlayarak başlayın: Çalışan, Yönetici (İK/L&D) ve Yönetici.
Çalışanın ana ekranı tek bir soruya cevap vermeli: "Sırada ne yapmam lazım?"
Atanmış eğitim listesi gösterin; son tarih, durum ve net bir birincil eylem (Başlat / Devam Et / Gözden Geçir / Sertifikayı İndir) olsun. İlerlemenin görünür olmasını sağlayın (örn. “5 modülden 3'ü”) ve Kısa filtreler ekleyin: Yakında süresi dolan, Süresi geçmiş, Tamamlandı.
Sertifikalar kolay bulunmalı ve paylaşılabilir olmalı. İndirilebilir bağlantılar ve son kullanma tarihlerini gösteren özel bir "Sertifikalar" sekmesi destek taleplerini azaltır.
Yöneticiler hız ve güven ister. Temel ekranlar genelde şunları içerir:
Toplu işler için tasarlayın: toplu atama, toplu hatırlatmalar ve basit şablonlar (örn. “Yıllık Güvenlik Eğitimi”). Ayarlar alanı varsa sade ve görev odaklı tutun.
Yöneticilerin temiz bir ekip durumu sayfasına ihtiyacı var; gecikme uyarıları ve bireysel kayıtlara inme. Öncelik verin:
Düğmelerde açık fiiller kullanın, basit arama ve az sayıda yüksek değerli filtre ekleyin; karmaşık sorgu oluşturucu yerine. Yardımcı boş durumlar ekleyin (“Gecikmiş eğitim yok”) ve hataları eyleme dönüştürülebilir yapın (“Yükleme başarısız—10MB altı PDF deneyin”).
Gelecekte ileri özellikler ekleseniz bile ilk deneyimi hafif ve öngörülebilir tutun.
Uygulamanızın güvenilirliği iki şeye bağlı: açık eğitim içeriği ve her çalışanın tamamladığını kesin gösterecek net kanıt. Burada "kurs atadık"ı "kim neyi ne zaman, hangi sürümle tamamladı"ya çevirirsiniz.
Gerçek dünya programlarının çoğunu kapsayan küçük bir kurs formatı setiyle başlayın:
Gerekirse SCORM/xAPI opsiyonel bir yetenek olarak ekleyin; zorunlu kılmayın. Birçok şirket SCORM olmadan da idare eder, ancak düzenlenen veya büyük organizasyonlar standart izleme için buna ihtiyaç duyabilir.
İçeriği Kurs → Modül → Ders olarak modelleyin ki yapı taşlarını yeniden kullanabilin ve bir kısmı güncellenince tüm kursu yeniden yazmak zorunda kalmayın.
Ders seviyesinde tamamlamayı şu açık kurallarla tanımlayın:
Zamana dayalı kurallarda dikkatli olun: sayfa başında geçirilen süre yanıltıcı olabilir. Gerekirse kaydırma/okuma onayı veya kısa bir onaylama ile birleştirin.
Değerlendirmeler kurs başına yapılandırılabilir olmalı:
Çalışanın deneme geçmişini (puan, izin verildiyse cevaplar, zaman damgaları) saklayın ki sonuçları sonra açıklayabilesiniz.
Politikalar değişir. Uygulamanız tarihsel kanıtı korumalıdır.
Ekler (slaytlar, SOP'ler, onay formları) yüklemeye izin verin ve kurs güncellemelerini yeni sürüm olarak ele alın. V1'i tamamlayan çalışanlar v1 için tamamlanmış görünmeye devam etmelidir; v2 yayımlansa bile. İçerik güncellemeleri yeniden eğitim gerektiriyorsa, eski kaydı üzerine yazmak yerine yeni sürüme bağlı yeni bir atama oluşturun.
Sertifika takibi, eğitimi kanıta dönüştüren kısımdır: kim hangi yeterliliğe sahip, ne kadar süre için. Amaç, sürenin öngörülebilir olması, yenilemelerin otomatik olması ve istisnaların kontrollü olmasıdır—e-tablolarsız.
Sertifikayı kurstan bağımsız bir kayıt türü olarak ele alın. Her sertifika şunları desteklemeli:
Hem veriliş tarihi hem de raporlama için türetilmiş olsa da saklanan son kullanma tarihi tutun. Tüm yenilemelerin geçmişini saklayın ki denetimlerde sürekliliği gösterebilesiniz.
Yenileme otomasyonu çoğunlukla zamanlama ve mantıktır. Yaygın desenler:
Yenileme kuralları tekrarlanır çalışsın; aynı eğitimi iki defa atamamalıdır.
Gerçek organizasyonlar alternatifleri kabul eder: satıcı sertifikaları, önceki eğitimler veya düzenleyici lisanslar. Destekleyin:
Her zaman kimi tarafından ve ne zaman verildiğini kaydedin; muafiyetlerin uyumluluk raporlarında görünmesini sağlayın.
Çalışan bir sertifika yüklediğinde bunu İK'ya (veya doğrulayıcı role) gönderin ve basit bir durum makinesi kullanın: Gönderildi → Onaylandı/Reddedildi → Verildi.
Onaylandığında iç sertifikayı doğru geçerlilik süresiyle oluşturun ve denetime hazır kayıtlar için belge referansını saklayın (bkz. /blog/audit-ready-training-records).
Bildirimler, eğitim sistemlerinin ya faydalı ya da göz ardı edilen sistemler olmasını belirler. Amaç basit: doğru mesajı doğru kişiye doğru zamanda gönderin—e-posta çöp haline gelmeden.
Başlangıç için yüksek değere sahip birkaç olayı tutarlı şekilde bildirin:
Yükseltmeler için kurallar belirleyin: "7 gün gecikme olursa yöneticiye bildir; 14 gün olursa İK'ya bildir." Dil bilgisi olabildiğince olgusal ve aksiyon odaklı olsun.
Bildirimleri kullanıcı düzeyinde ayarlanabilir yapın (kategori bazında isteğe bağlı/gerekirse opt-out) ve her kullanıcının saat dilimine göre gönderin. 3:00'te gelen bir son tarih hatırlatıcısı fark edilirlik kazandırmaz.
Spam önlemek için ekleyin:
Yöneticiler ve İK tek tek bildirimler yerine özetleri tercih eder. Haftalık bir özet gönderin; içeriğinde:
Bir bildirim geçmişi saklayın (alıcı, kanal, şablon, zaman damgası, durum ve ilgili atama/sertifika). Bu, “aldılar mı?” sorusunun cevaplanmasında yardımcı olur ve sorun gidermeyi kolaylaştırır. Bu günlükten kullanıcıya veya atama kaydına bağlantı verin.
Raporlama, bir eğitim ve sertifika uygulamasının değerini kanıtladığı yerdir: tamamlanma verisini yöneticiler, İK ve denetçiler için net cevaplara dönüştürür.
İki pano ile başlayın:
Sayıların tutarlı olması için basit kurallar tanımlayın (örn. “tamamlandı” tüm gereken modüller geçildi ve gerekiyorsa kanıt eklendi anlamına gelir).
Her grafik tıklanabilir olmalı. Bir departmanda %82 uyumluluk göründüğünde kullanıcı şunlara inebilmelidir:
Böylece panolar sadece özet değil, operasyonel araç haline gelir.
Denetçiler genelde aynı hikayeyi ister; ama kanıtla birlikte. Bir "denetim görünümü" oluşturun ki şunları cevaplasın:
Tam izi manuel ekran görüntüleri olmadan dışa aktarmayı kolaylaştırın.
Analiz için CSV ve paylaşım için PDF desteği ekleyin. Aylık uyumluluk paketi gibi zamanlanmış teslimatlar sunun; e-postaya veya güvenli indirme alanına, ekranda kullanılan aynı filtrelerle eşleşecek şekilde.
Entegrasyonlar bir eğitim uygulamasını “güncellemeniz gereken başka bir yer” olmaktan çıkarıp güvenilen bir sisteme dönüştürür. Öncelikle hangi sistemlerin çalışanlar, programlar ve iletişim için gerçeği tuttuğunu belirleyin—sonra uygulamanızın neyi çekmesi, neyi göndermesi ve neyin senkron kalması gerektiğine karar verin.
Çoğu organizasyon için HRIS, çalışan listesi, departmanlar, iş unvanları, yöneticiler ve konum bilgilerini tutar. Yeni işe alınanlar otomatik eklenmesi, ayrılanların devre dışı bırakılması ve raporlamanın güncel kalması için gece senkronları (veya yakın gerçek zamanlı) planlayın.
Çok kiracılı destek varsa HRIS kimliklerinin kiracılara nasıl eşleneceğini ve veri karışmasını nasıl önleyeceğinizi tanımlayın.
Tek oturum açma şifre sorunlarını azaltır ve benimsemeyi artırır. Yaygın SSO seçeneklerini (SAML veya OIDC) destekleyin. Gerektiğinde SCIM ile kullanıcı, grup ve rol atamalarının otomatik oluşturulmasını ekleyin.
SSO olsa bile acil durumlar için "break glass" yönetici erişimi tutun.
Eğitmenli oturumlar için bir takvim sağlayıcısıyla entegrasyon planlayın: davet oluşturma, yeniden planlama ve katılım sinyallerini izleme.
Hatırlatmalar ve yükseltme akışları için e-posta ve Slack/Teams bağlantıları ekleyin; çalışanların gerçekten gördüğü yerde bildirim gönderin—spam yapmadan. Mesaj şablonlarını düzenlenebilir tutun.
Dağınık geçmiş veriye hazırlıklı olun. Geçmiş tamamlamalar ve sertifikalar için doğrulama ve önizleme adımı olan rehberli içe aktarımlar sağlayın. Uygulamalar için gerçek zamanlı entegrasyonlar gerekirken, tamamlanma kaydedildiğinde, sertifika verildiğinde, yenileme geldiğinde veya kullanıcı devre dışı bırakıldığında tetiklenen webhooks veya API'ler sunun.
Bir eğitim yönetimi uygulaması kişisel veriler (isim, e-posta, iş rolleri), performans verileri (puanlar) ve uyumluluk kanıtı (sertifikalar, imzalı belgeler) içerir. Bunu bir kayıt sistemi gibi ele alın: güvenlik ve gizliliği baştan tasarlayın.
Önce rol tabanlı erişimle başlayın ve yeni özelliği "erişimsiz" olarak varsayarak açıkça izin verin. Örneğin, bir yönetici yalnızca kendi ekibinin durumunu görmeli, başka departmanın quiz cevaplarını görememeli.
Trafiği HTTPS/TLS ile şifreleyin ve hassas verileri dinlenme halinde de şifreleyin (veritabanı ve yüklemeler için şifreli nesne depolama). Çok kiracılı platform destekliyorsanız kiracı ayrımını veri katmanında yapın ve çapraz erişimi test edin.
Denetime hazır kayıtlar için yönetsel eylemleri ve kritik değişiklikleri (atamalar, son tarihler, puan düzenlemeleri, sertifika yüklemeleri, durum değişiklikleri) kaydedin. "Kim/ne zaman/neyi/önce/sonra" bilgisini tutun.
Tamamlamaları, puanları ve yüklenen belgeleri ne kadar süre saklayacağınızı belirleyin (örn. “işten ayrılıştan sonra 7 yıl” veya “yasal gerekliliğe göre”). Otomatik saklama politikaları uygulayın ve bunları yönetici yardım sayfalarında belgeleyin (bkz. /help/data-retention).
İlk girişte açık onay/bildirim metni ekleyin; erişim talepleri ve veri silme isteklerini ele alacak basit araçlar sağlayın. Hukuki dayanağınız "meşru menfaat" olsa bile kullanıcıların ne toplandığını ve nedenini anlamalarını sağlayın. Bunu SSO ve HRIS entegrasyonu ile eşleştirin ki işten ayrıldıklarında erişim otomatik olarak kaldırılabilsin.
Ekranlar çalıştığında uygulama "bitmiş" sayılmaz. Zor olan, kuralların doğru davrandığını (atamalar, yenilemeler, sona erme), denetim kayıtlarının doğru kaldığını ve sistemin gerçek kurumsal karmaşıklık altında dayanabildiğini kanıtlamaktır.
Eğer hızlı ilerliyorsanız, Koder.ai gibi bir vibe-coding platformu iş akışlarını prototiplemenize (atamalar, hatırlatmalar, denetim görünümleri) ve rol tabanlı erişim ile raporlama üzerinde tek bir sohbet odaklı döngüde yinelemeye yardımcı olabilir—ayrıca gözden geçirip genişletebileceğiniz gerçek, dışa aktarılabilir kaynak kodu üretebilir.
Uyumluluk riski yaratan bölümlere odaklanın:
Ayrıca “mutlu olmayan yol”ları test edin: eksik değerlendirmeler, erişimin iptali, kaçırılmış son tarihler ve çakışan rol izinleri.
Sentetik veriler gerçek kullanıma benzemeli: büyük organizasyonlar, birden çok departman, dolaylı raporlara sahip yöneticiler, sınırlı erişime sahip yükleniciler ve birbirine giren programlarda binlerce atama. Kenar durumları ekleyin:
Bunlar performans sorunlarını ve raporlama hatalarını erken görünür kılar.
Stagingi prodüksiyonun yakın bir kopyası olarak çalıştırın: aynı konfigürasyonlar, aynı entegrasyonlar (veya güvenli taklitleri) ve aynı zamanlanmış işler.
Prodüksiyon hazırlığı için şunları kurun:
Lansmandan sonra sürtünmeyi azaltan ve güveni artıran iyileştirmeleri önceliklendirin:
Eğer paketleme veya self-serve onboarding planlıyorsanız ilgili kaynakları /pricing adresinde erişilebilir tutun ve pratik kılavuzları /blog içinde genişletin (örn. içe aktarma, yenilemeler, denetim hazırlığı).
Öncelikle tek cümlelik bir birincil hedef yazın (ör. “Aykırı uyumluluk eğitimlerini %30 azalt ve denetim hazırlık süresini yarıya indir”). Ardından aylık olarak inceleyeceğiniz 2–4 metriği seçin; örnekler: departman bazında tamamlama oranı, gecikme trendi, ortalama tamamlama süresi ve denetim raporu üretme süresi.
Bu hedefi, v1'e neyin gireceğine ve sonraya bırakılacağına karar vermek için kullanın; böylece ilk günden her kenar durumu için tasarım yapmazsınız.
Çoğu ürün için en az dört kullanıcı grubu gerekir:
Dış denetçileriniz yoksa bile, raporlar ve kanıtların kolayca incelenmesi için dahili bir “denetim görünümü” düşünün.
İK, uyumluluk ve farklı departmanlardan bazı yöneticilerle kısa görüşmeler (30–45 dakika) yaparak başlayın. Onlardan yakın zamanda gerçekleşen bir eğitim döngüsünü baştan sona anlatmalarını isteyin:
Cevapları basit bir iş akışı haritasına ve desteklemeniz gereken istisnalara dönüştürün.
İlk etapta birkaç temel varlıkla başlayın:
Durumu tarihlerden çıkarsamak yerine açık durum alanları kullanın. Örneğin:
Denetim geçmişini ekleme-yalnız olarak ele alın. En azından şunları kaydedin:
Bunu atamalar, süre sonları, tamamlamalar, puan düzenlemeleri, kanıt yüklemeleri ve sertifika durum değişiklikleri için uygulayın. Ayrıca kanıt öğelerini (zaman damgaları, sertifika kimlikleri/dosyaları, onaylar) gerçekleştiği anda saklayın ki denetim paketlerini sonradan üretebilesiniz (bkz. /blog/audit-ready-training-records).
Rolleri küçük ve sabit tutun (ör. Çalışan, Yönetici, İK Yönetici, İçerik Yazarı, Denetçi). Sonra izinleri eylemler olarak tanımlayın ve bunları ekranlara/API'lere eşleyin:
Bu, rol patlamasını önler ve “Yöneticiler dışa aktarabilir mi?” ya da “Yazarlar çalışan kanıtlarını görebilir mi?” gibi soruların net şekilde cevaplanmasını sağlar.
Organizasyonunuzun büyüklüğüne göre başlayın:
SSO olsa bile acil durumlar için sıkı kontrol edilen bir “break glass” yönetici erişimi tutun.
Birkaç ortak türü destekleyin ama gereksiz yere abartmayın:
Tamamlanma kurallarını ders/lesson seviyesinde açıkça tanımlayın (quiz geçişi, zaman damgası ile onaylama veya uygun güvenliklerle zaman tabanlı). Güncellemeler için kurs sürümleri oluşturun ve eski tamamlamaları asla üzerine yazmayın; yeniden eğitim gerekiyorsa yeni sürüme bağlı yeni bir atama oluşturun.
Sertifikaları kendi kayıt türü olarak modelleyin; her biri aşağıyı desteklemeli:
Yenilemeleri idempotent işler halinde otomatikleştirin (aynı eğitimi iki kez atamamalı). Muafiyetleri ve denkliği (harici sertifikaların iç gereksinimi karşıladığı durumlar) yönetmek için onaylayıcı ve gerekçe kaydedin. Yüklenen kanıtların doğrulama iş akışı basit olmalı: .
Kural: eğer bir şey “atanabiliyorsa”, “tamamlanabiliyorsa” veya “muaf tutulabiliyorsa”, genellikle kendi tablosuna/nesnesine ihtiyaç duyar. Bu, raporlama ve denetim izleri için ileride işleri çok daha kolay hale getirir.
Bu, “geç tamamlandı”, “yönetici tarafından muaf tutuldu” veya “yenileme ilerliyor ama süresi doldu” gibi durumlara ihtiyaç duyulduğunda belirsizliği ortadan kaldırır.
