# Okul yönetim sistemi seçerken SIS, LMS ve ERP farkları

*2026-09-29 · 15 dk*

SIS, LMS ve ERP'nin okul yaşam döngüsündeki rollerini; entegrasyon, veri sahipliği, KVKK, demo senaryosu ve seçim puan kartıyla karşılaştıran kapsamlı rehber.


Okul yönetim sistemi arayan kurumlar çoğu zaman aynı teklif dosyasında SIS, LMS, ERP, CRM, veli uygulaması ve muhasebe ifadeleriyle karşılaşır. Ürünlerin ekranları birbirine benzediği için “hepsi öğrenci bilgisi tutuyor” sonucu çıkar. Oysa aynı kişinin adı üç sistemde bulunabilir ama her sistem bu kişiye farklı iş bağlamında bakar. Kayıt, ders deneyimi ve finansal işlem birbirinden ayrılmadığında veri kopyaları, yetki ihlalleri ve tutarsız raporlar oluşur.

Bu rehber; K–12 okulları, kolej zincirleri, kurslar ve yükseköğretim kurumları için kavramsal bir seçim çerçevesi sunar. Mevzuat ve resmî entegrasyon gereksinimleri kurum türüne göre farklıdır; ürün seçimi öncesinde ilgili MEB, YÖK, KVKK, mali ve kurumsal yükümlülükler ayrıca doğrulanmalıdır.

## SIS nedir ve hangi kaydın sahibi olmalıdır?

SIS, Student Information System yani öğrenci bilgi sistemidir. Öğrencinin adaylıktan kayda, sınıf ve programa yerleşimden ölçme–değerlendirmeye, devamsızlıktan transkripte ve mezuniyete uzanan akademik/idari ana kaydını yönetir. Öğrenci numarası, statü, program, sınıf, ders kaydı, not, devamsızlık, disiplin, mezuniyet koşulu ve resmî raporlar SIS'in doğal kapsamındadır.

SIS'i yalnız “öğrenci kartı” olarak görmek büyük hatadır. Sistem zaman içinde değişen akademik gerçekliği korumalıdır. Bir öğrencinin programı, sınıfı, danışmanı veya ders seçimi değiştiğinde eski dönem kaydı bozulmamalıdır. Akademik takvim, dönem, müfredat ve değerlendirme kuralları sürümlenmelidir. Dondurma, nakil, muafiyet, bütünleme, tekrar ve mezuniyet gibi istisnalar gerçek süreçtir; ürün demosunda sınanmalıdır.

MEB'in e‑Okul tanımı da öğrencinin kayıttan mezuniyete bilgilerini sistematik olarak tutan yönetim ve veli bilgilendirme yapısını vurgular. Kurum SIS'i ile resmî sistem aynı şey kabul edilmemeli; hangi verinin hangi kanaldan, hangi yetkiyle bildirileceği belirlenmelidir. [Education Suite Pro](/urunler/education-suite-pro) SIS katmanını diğer eğitim süreçleriyle ortak öğrenci yaşam döngüsünde ele alır.

## LMS nedir ve SIS'ten neden farklıdır?

LMS, Learning Management System yani öğrenme yönetim sistemidir. Ders alanı, içerik, video, etkinlik, ödev, quiz, tartışma, rubrik, geri bildirim ve öğrenme ilerlemesini yönetir. SIS “öğrenci hangi derse kayıtlı ve resmi notu ne?” sorusuna; LMS “öğrenci ders içinde ne yaptı, hangi içeriğe erişti ve hangi geri bildirimi aldı?” sorusuna cevap verir.

LMS öğretim tasarımını desteklemelidir. Öğretmen içerik sıralaması, ön koşul, teslim tarihi, grup çalışması, erişilebilirlik ve ölçme etkinliklerini tasarlar. Öğrenci tek ders bağlamında öğrenir; bildirim, takvim ve geri bildirim alır. İçerik standardı, video sağlayıcı, sanal sınıf ve kütüphane entegrasyonu LMS'in alanıdır.

Resmî ders kaydı SIS'ten LMS'e akar; LMS'de oluşan sonuçlar belirlenmiş değerlendirme kuralıyla SIS'e döner. Her tıklamayı SIS'e göndermek gereksizdir. Nihai veya onaylanmış not, tamamlanma ve belirli risk sinyalleri paylaşılabilir. Ham etkinlik verisinin amacı, saklama süresi ve erişimi ayrıca yönetilmelidir.

## ERP okulda hangi süreçleri yönetir?

ERP; muhasebe, bütçe, tahsilat, satın alma, stok, sabit kıymet, insan kaynakları, bordro ve nakit süreçlerinin ana sistemidir. Özel okulda ücret planı, indirim, burs, sözleşme, taksit, tahsilat ve iade; üniversitede bütçe, proje, satın alma ve personel mali süreçleri ERP'de yürüyebilir. Öğrenci veya veli ERP'de cari hesap referansı olarak bulunur, ancak ayrıntılı akademik kaydın burada çoğaltılması gerekmez.

ERP ile SIS arasındaki sınır ücretlendirme noktasında hassastır. Öğrencinin programı ve kayıt statüsü SIS'te; ücret tarifesi, fatura ve ödeme ERP'de sahiplenilebilir. Bursun akademik koşulu SIS'ten, finansal uygulaması ERP'den gelir. İade veya kayıt iptali tek taraflı yapılırsa sistemler ayrışır. Bu nedenle durum geçişleri ve mutabakat raporu gerekir.

Personel tarafında öğretmenin kimlik, bordro ve özlük ana kaydı HR/ERP'de; ders görevlendirmesi ve akademik iş yükü SIS'te olabilir. Zaman çizelgesi ve ek ders hesabı iki sistem arasında tanımlı kuralla akmalıdır.

## SIS, LMS ve ERP karşılaştırma tablosu

| Boyut | SIS | LMS | ERP |
|---|---|---|---|
| Ana amaç | Akademik/idari öğrenci yaşam döngüsü | Öğrenme deneyimi ve içerik | Kurumsal kaynak ve finans |
| Ana kullanıcı | Öğrenci işleri, yönetim, öğretmen | Öğretmen, öğrenci, eğitim tasarımcısı | Finans, İK, satın alma, yönetim |
| Temel nesne | Öğrenci–program–ders kaydı | Ders alanı–etkinlik–içerik | Hesap–cari–işlem–maliyet merkezi |
| Zaman yapısı | Akademik yıl/dönem | Ders haftası ve etkinlik | Mali dönem |
| Kritik çıktı | Not, devamsızlık, transkript, mezuniyet | Öğrenme ilerlemesi ve geri bildirim | Fatura, tahsilat, bütçe ve mali tablo |
| Veri ayrıntısı | Resmî akademik kayıt | İnce taneli etkileşim | Finansal işlem |
| Ana risk | Tarihsel kaydın bozulması | İzleme ve mahremiyet aşırılığı | Akademik bağlamın kaybı |

Bu tablo ürünlerin hiç örtüşmediği anlamına gelmez. Modern platformlar modülleri bir arada sunabilir. Mimari kararı ürün menüsüne göre değil, hangi modülün hangi ana kaydı yönettiğine göre verilir.

## CRM ve veli portalı bu resimde nereye oturur?

CRM aday öğrenci, kampanya, görüşme, başvuru ve kayıt dönüşümünü yönetebilir. Aday kesin kayıt olduğunda kimlik ve iletişim bilgisi SIS'e kontrollü şekilde devredilir. Aynı kişiyi yeni kayıt açarak çoğaltmak yerine aday–öğrenci kimlik eşlemesi yapılır. Başvuru belgelerinin hepsinin CRM'de süresiz tutulması veri minimizasyonuna aykırılık riski doğurabilir.

Veli portalı ayrı bir kayıt sistemi değil, farklı sistemlerden yetkili ve bağlama uygun hizmet sunan deneyim katmanıdır. Veli SIS'ten devamsızlık ve notu, LMS'den ödev/geri bildirimi, ERP'den borç ve ödeme bilgisini görebilir. Ancak velinin erişimi öğrencinin yaşı, velayet/yetki durumu, kurum politikası ve mevzuata göre sınırlandırılmalıdır.

Portal tek şifre ve bütünlüklü deneyim sağlar; arka planda veri sahipliği korunur. Ekran için bütün veriyi yeni veri tabanına kopyalamak yerine API veya güvenli servislerle güncel kaynak okunmalıdır. Bildirim tercihleri, dil, erişilebilirlik ve iletişim kanalı yönetimi ortak hizmet tasarımının parçasıdır.

## Veri sahipliği matrisi nasıl hazırlanır?

Her ana nesne için tek sahip sistem belirleyin. Öğrenci kimliği ve akademik statü SIS; ders içeriği ve ham etkinlik LMS; fatura ve ödeme ERP; aday fırsatı CRM; kullanıcı kimlik doğrulaması merkezi kimlik sistemi tarafından sahiplenilebilir. Diğer sistemler gereken en az alanı değişmez anahtarla tüketir.

Matris sütunları şunlar olmalıdır: nesne/alan, iş amacı, ana sistem, oluşturma yetkisi, onay, tüketen sistem, aktarım sıklığı, saklama süresi, hata sahibi ve silme/anonymizasyon kuralı. “Adres” gibi basit görünen alan bile önemlidir: Öğrenci işleri mi günceller, veli portalı talep mi açar, ERP fatura adresini ayrı mı tutar?

Çift yönlü senkronizasyon varsayılan olmamalıdır. Bir alan iki sistemde değişirse hangisi kazanacak? Daha güvenli yaklaşım, değişiklik talebinin ana sisteme gönderilmesi ve onaylı değerin geri dağıtılmasıdır. Kimlik eşlemede ad/soyad yerine değişmez kurum kimliği kullanılır; T.C. kimlik numarası her entegrasyonda anahtar olarak taşınmamalıdır.

## Kayıttan ilk karneye uçtan uca akış

Gerçek seçim senaryosu sistemi parçalardan değil yaşam döngüsünden sınar. [Kayıttan ilk karneye akış](/urunler/education-suite-pro/is-akislari/kayittan-ilk-karneye-uctan-uca) şu adımları kapsayabilir: aday başvurur, belge ve izinler toplanır, kabul kararı verilir, öğrenci numarası oluşur, ücret planı ERP'ye gider, ders/sınıf ataması yapılır, LMS alanları açılır, devamsızlık ve ölçme verisi oluşur, dönem notu onaylanır, karne ve veli bildirimi üretilir.

Bu zincirde kimlik bir kez oluşmalı, statü değişiklikleri olay olarak aktarılmalıdır. Kayıt iptalinde LMS erişimi kapanırken finansal iade kuralı tetiklenmeli; geçmiş işlem silinmemelidir. Sınıf değişikliğinde eski ders alanı kayıtları akademik denetim için korunmalı, yeni erişim doğru tarihte açılmalıdır.

Demo sırasında mutlu yolun yanında istisnaları çalıştırın: geç kayıt, burs değişikliği, ders muafiyeti, veli yetki değişimi, not itirazı ve kayıt dondurma. Sistem kullanıcıyı manuel e-posta ve Excel'e itiyor mu ölçün.

## Akademik yapı ve kural motoru neden önemlidir?

Okulun program, sınıf, şube, ders, kazanım, kredi ve değerlendirme modeli zaman içinde değişir. Sistem akademik yapıyı sabit alanlara gömmemeli; yürürlük tarihli ve sürümlü yönetmelidir. Aynı ders kodunun farklı yıllarda içerik veya kredi değişikliği eski transkripti bozmamalıdır.

Not hesaplama; sınav, proje, performans, rubrik, telafi ve yuvarlama kurallarını içerebilir. Kural değişikliği onaylı notu sessizce değiştirmemelidir. Hesap ara değerleri, kullanılan sürüm ve onaylayan kişi saklanmalıdır. Öğretmen esnekliği ile kurum standardı dengelenmelidir.

Ders programı oluşturma da yalnız takvim değildir. Öğretmen, derslik, kapasite, ekipman, ardışıklık ve pedagojik kısıtlar bulunur. [Ders programı çizelgeleme optimizasyonu](/urunler/education-suite-pro/yetenekler/ders-programi-cizelgeleme-optimizasyon) katı ve esnek kısıtları ayırmalı; önerinin nedenini açıklamalı, insanın değişikliğini kaydetmelidir.

## Ölçme, kazanım ve öğrenme analitiği

SIS nihai notun, LMS etkinlik verisinin kaynağıdır. Ölçme sistemi soru, sınav, rubrik ve kazanım eşlemesini daha derin yönetebilir. Hedef tek puan üretmek değil, hangi kazanımda hangi kanıta dayanarak destek gerektiğini anlamaktır. [Ölçme, değerlendirme ve kazanım analitiği](/urunler/education-suite-pro/yetenekler/olcme-degerlendirme-ve-kazanim-analitigi) bu nedenle not defterinden daha geniştir.

Analitik ekranlar veri bağlamını göstermelidir. Düşük başarı; içerik zorluğu, eksik katılım, erişim sorunu, ölçme hatası veya bireysel destek ihtiyacından kaynaklanabilir. Korelasyon nedensellik değildir. Öğretmene “riskli öğrenci” etiketi vermek yerine gözlenebilir sinyal, veri tarihi ve önerilen doğrulama adımı sunulmalıdır.

Veri kalitesi ölçülmelidir: eksik etkinlik, geç senkronizasyon, yanlış ders kaydı ve farklı not ölçekleri sonuçları bozar. Model veya gösterge yayına alınmadan önce alt gruplarda hata, temsil ve erişim adaleti incelenmelidir.

## Türkiye bağlamında resmî sistemler ve entegrasyon

Kurum türüne göre e‑Okul, MEBBİS, YÖKSİS ve diğer resmî sistemlerle süreçler bulunabilir. Ticari ürünün “e‑Okul entegrasyonu var” ifadesi teknik ve hukuki olarak doğrulanmalıdır: Hangi işlem, hangi yetki, hangi resmî servis veya onaylı yöntemle yapılır? Ekran otomasyonu veya kullanıcı parolası paylaşımı güvenli entegrasyon değildir.

Resmî sistem, kurum içi SIS'in tüm ihtiyacını karşılamak zorunda değildir; kurum da resmî kaydı gölgeleyen paralel “resmî gerçek” üretmemelidir. Veri gönderimi öncesi doğrulama, gönderim sonucu ve hata kodu saklanmalıdır. Kullanıcı hangi kaydın resmî sisteme ulaştığını görebilmelidir.

Mevzuat ve teknik arayüzler değişebilir. Ürün satıcısının güncelleme süreci, bildirim süresi, test ortamı ve müşteri sorumluluğu sözleşmede yer almalıdır. Bu rehber yayımlandığı tarih itibarıyla genel mimari yaklaşım sunar; güncel resmî şartlar ilgili kurumdan doğrulanmalıdır.

## KVKK, çocuk verisi ve amaç sınırlaması

Öğrenci verisi sıradan CRM verisi gibi ele alınamaz. Kimlik, iletişim, akademik performans, davranış, rehberlik, sağlık ve biyometrik olabilecek görüntü/ses verileri farklı risk taşır. KVKK, özel nitelikli veriler için daha sıkı koruma gerektirir. KVKK Kurulu'nun eğitim kurumundaki psikolojik değerlendirme verisine ilişkin kararı, amaç, aydınlatma ve hukuki şartların somut süreçte ele alınması gerektiğini gösterir.

Sistem veri minimizasyonunu teknik olarak desteklemelidir. Her modül tüm öğrenci profilini görmemeli; rehberlik notları öğretmen geneline açılmamalı; finans personeli sağlık veya davranış verisine erişmemelidir. Rol, sınıf, ilişki ve amaç temelli yetki gerekebilir. Veli ile öğrenci erişimi birbirinden ayrılmalı, yetki değişiklikleri zamanında uygulanmalıdır.

Saklama süreleri veri kategorisine göre tanımlanmalı; süre sonunda silme, yok etme veya anonimleştirme kanıtlanmalıdır. Test ortamına canlı veri kopyalanmamalı. Yapay zekâ hizmetine veri gönderilecekse veri akışı, alt işleyenler, yurt dışı aktarım, eğitim kullanımı ve silme açıkça değerlendirilmelidir.

## Entegrasyon ve teknik mimari kriterleri

API varlığı tek başına entegrasyon kabiliyeti değildir. Öğrenci, ders, kayıt ve not için belgelenmiş veri sözlüğü; kimlik doğrulama; oran sınırı; olay bildirimi; tekrar deneme; sürümleme ve hata yönetimi gerekir. Bir kayıt iki kez gönderildiğinde çoğalmamalı, sıralama bozulduğunda statü geriye gitmemelidir.

SSO, çok faktörlü doğrulama ve otomatik kullanıcı yaşam döngüsü önemlidir. Öğrenci kayıt olduğunda doğru rol açılmalı; ayrıldığında erişim kapanmalı; mezun portalı gerekiyorsa sınırlı yeni rol oluşmalıdır. Öğretmenin kurumdan ayrılması içerik ve not sahipliğini kaybettirmemelidir.

LMS içerik aktarımı için yaygın standartlar, sanal sınıf ve kütüphane entegrasyonları değerlendirilebilir. Ancak standart adı görmek yerine gerçek içerik paketi, not geçişi ve kullanıcı eşleme testi yapılmalıdır. Veri dışa aktarımı yalnız PDF olmamalı; ilişki ve ekleriyle açık, makinece okunur format sunulmalıdır.

## Tek paket mi, uzman ürünler mi?

Tek paket yaklaşımı ortak arayüz, daha az sözleşme ve daha basit destek avantajı sunar. Küçük ve orta kurumda operasyon yükünü azaltabilir. Risk, SIS güçlü iken LMS'in yüzeysel veya ERP'nin yerel mali gereksinimlerde zayıf olmasıdır. Ayrıca paket içindeki veri paylaşımı kullanıcıya görünmeden aşırı olabilir.

Uzman ürünler her alanda derinlik ve seçim esnekliği sağlar. Risk, entegrasyon, kimlik, raporlama ve çoklu satıcı koordinasyonudur. Kurumun ürün sahipliği ve teknik işletim kapasitesi yoksa iyi ürünler kötü deneyime dönüşebilir.

Hibrit yaklaşım sık görülür: güçlü SIS çekirdeği, entegre LMS, mevcut ERP ve ortak portal. Karar için “kaç sistem?” yerine “kullanıcı kaç kesinti yaşıyor, ana kayıtlar ne kadar güvenilir ve değişim maliyeti nedir?” soruları sorulmalıdır.

## Demo için uygulanabilir test paketi

Satıcıya hazırlıklı demo yerine kurum senaryosu verin. Örnek paket: 50 öğrenci, iki program, üç ücret planı, burs, kardeş indirimi, geç kayıt, sınıf değişikliği, bir not itirazı, rehberlik erişim kısıtı ve mezuniyet kontrolü.

Test adımları:

1. Adayı mükerrer kişi oluşturmadan öğrenciye dönüştürün.
2. Kayıtla birlikte ücret planı ve LMS erişimi üretin.
3. Bir öğrencinin sınıfını dönem ortasında değiştirin; geçmişi koruyun.
4. Çevrimdışı/bağlantı kesintili not girişi senaryosunu deneyin.
5. Onaylı notu değiştirmeye çalışın ve denetim izini inceleyin.
6. Rehberlik notunu yetkisiz rolden arayın.
7. Kayıt iptalinde finansal iade, LMS kapanışı ve tarihsel kaydı kontrol edin.
8. Öğrenci verisini açık formatta dışa aktarın.
9. Entegrasyonda hatalı ders kodu üretip hata kuyruğunu izleyin.
10. Veli portalında başka çocuğa erişim girişimini sınayın.

Her görev için süre, hata, manuel müdahale ve kullanıcı yorumu kaydedilmelidir.

## Seçim puan kartı

| Boyut | Önerilen ağırlık | Kanıt |
|---|---:|---|
| Öğrenci yaşam döngüsü ve istisnalar | %20 | Kayıttan mezuniyete canlı senaryo |
| Akademik kural ve tarihçe | %15 | Sürüm, dönem kilidi, not itirazı |
| Öğrenme deneyimi | %15 | Öğretmen ve öğrenci görev testi |
| Finans/tahsilat uyumu | %10 | Ücret, burs, iade ve mutabakat |
| KVKK ve güvenlik | %15 | Rol testi, veri akışı, silme kanıtı |
| Entegrasyon ve veri açıklığı | %10 | API, hata ve dışa aktarım |
| Kullanılabilirlik/erişilebilirlik | %10 | Cihaz ve engel gruplarıyla test |
| TCO ve sağlayıcı sürekliliği | %5 | Beş yıllık maliyet ve SLA |

Veto kriterleri; yetkisiz rehberlik/sağlık verisi erişimi, onaylı notun izsiz değişmesi, verinin dışa aktarılamaması ve hesap paylaşımı gibi konular olabilir. Puanlar satış beyanına değil, kurum verisiyle kanıta dayanmalıdır.

## Toplam sahip olma maliyeti ve yatırım değeri

Lisansın yanında kurulum, entegrasyon, veri temizliği, içerik göçü, eğitim, cihaz, destek, kimlik yönetimi, rapor geliştirme ve iç ekip zamanı hesaplanmalıdır. Öğrenci başına fiyatlandırmada mezun, veli, aday ve sezonluk kullanıcıların nasıl sayıldığı sorulmalıdır. API, depolama, video, SMS/e-posta ve yapay zekâ kullanımı ek maliyet yaratabilir.

Değer; kayıt işleme süresi, tahsilat gecikmesi, not kapanış süresi, mükerrer veri, destek çağrısı, öğretmen idari eforu ve rapor hazırlama saatindeki değişimle ölçülebilir. Pedagojik sonucu tek başına yazılıma atfetmek doğru değildir; sistem öğretmene zaman ve güvenilir sinyal sağlayarak katkı verir.

Üç yıllık ihtiyatlı, beklenen ve büyüme senaryosu kurun. Öğrenci sayısı arttığında fiyat kademesi, birleşme veya yeni kampüs ekleme maliyeti, veri çıkış ücreti ve sözleşme sonunda arşiv erişimi dahil edilmelidir.

## Uygulama yol haritası ve 90 günlük kabul

İlk aşama veri ve süreç tasarımıdır: kişi eşleme, akademik yapı, rol, saklama ve entegrasyon sözlüğü hazırlanır. İkinci aşama sınırlı program veya kampüste pilottur. Üçüncü aşama ölçüm ve düzeltme; dördüncü aşama kontrollü yayılımdır. Akademik takvimin en yoğun kayıt veya sınav döneminde büyük geçişten kaçınılmalıdır.

İlk 90 gün için örnek hedefler: mükerrer öğrenci oranının belirli eşik altında olması; kayıt sonrası LMS erişiminin dakikalar içinde açılması; not aktarımında kayıp olmaması; ERP–SIS tahsilat mutabakatının yüzde 99,5 üzeri eşleşmesi; kritik rol ihlali bulunmaması; destek taleplerinin çoğunun tanımlı sürede çözülmesi; kullanıcı görev tamamlama süresinin tabana göre azalması.

Eğitim, role göre ve kısa senaryolarla yapılmalıdır. Öğretmene finans modülü, finans ekibine ders tasarımı anlatmak yerine günlük işi gösterin. Süper kullanıcı ve veri sorumlusu rolleri kalıcı işletim modeline bağlanmalıdır.

## Sık yapılan hatalar

Birinci hata, ürün etiketini yetenek sanmaktır. “SIS + LMS + ERP” yazması derinliği kanıtlamaz. İkinci hata, resmî entegrasyonu ekran robotuyla karıştırmaktır. Üçüncü hata, bütün veriyi bütün sistemlere kopyalamaktır. Dördüncü hata, veli portalını yalnız mobil uygulama görünümü olarak değerlendirip yetki ve veri tazeliğini ihmal etmektir.

Beşinci hata, öğrenci analitiğini etiketleme aracına dönüştürmektir. Sinyal, karar değil inceleme başlangıcıdır. Altıncı hata, eski akademik kayıtları temizleme adına tarihçeyi değiştirmektir. Yedinci hata, içerik göçünün telif, sürüm ve erişilebilirlik boyutunu planlamamaktır. Sekizinci hata, dönem başlamadan kullanıcı kabul testi yapmamaktır.

Son olarak, “tek ekran” hedefiyle ana sistem sınırlarını yok etmek hatadır. Kullanıcı tek deneyim yaşayabilir; arka planda veri sahipliği ve sorumluluk açık kalmalıdır.

## Rol bazlı kabul atölyesi nasıl yürütülür?

Teknik ekip tüm sistemi onaylamamalıdır. Öğrenci işleri, öğretmen, rehberlik, finans, veli/öğrenci deneyimi, veri koruma ve BT için ayrı görev kartları hazırlanır. Her katılımcı kendi rol hesabıyla gerçekçi veride görevi tamamlar; gözlemci tıklama sayısı, süre, hata, yardım ihtiyacı ve yetkisiz görünen alanı kaydeder. Satıcı müdahale ederse müdahale de bir kullanılabilirlik bulgusu sayılır.

Öğrenci işleri geç kayıt, nakil, dondurma ve mezuniyet koşulunu; öğretmen ders alanı, ölçme, not düzeltme ve sınıf değişikliğini; rehberlik sınırlı not erişimini; finans burs, taksit, iptal ve iade akışını; veli iki çocuk ve değişen yetki senaryosunu tamamlamalıdır. BT mükerrer olay, bağlantı kesintisi, SSO rol değişimi ve veri dışa aktarımını test eder. Veri koruma sorumlusu küçük grup raporu, özel nitelikli alan, erişim logu ve saklama sonu silme kanıtını inceler.

Atölye sonunda bulgular kritik, yüksek, orta ve deneyim iyileştirmesi olarak sınıflandırılır. “Eğitimle çözülür” ifadesi otomatik kabul edilmez; günlük ve yüksek frekanslı görevde sürekli eğitim gereksinimi ürün tasarımı sorunudur. Kritik yetki veya tarihçe hatası çözülmeden pilot başlamaz. Orta bulgular için sahibi, teslim tarihi ve tekrar test koşulu yazılır.

## Veri göçünde akademik tarihçe kontrolü

Göç yalnız öğrenci sayısının eşleşmesi değildir. Aktif statü, program/sınıf, ders kaydı, not, devamsızlık, ücret planı, burs, veli ilişkisi ve izin/tercih ayrı mutabakat görmelidir. Rastgele örnek yerine risk tabakalı örneklem kullanın: sınıf değiştiren, kaydı dondurulan, muafiyeti olan, birden çok velisi bulunan, borç/iade işlemi olan ve mezuniyet sınırındaki öğrenciler özellikle seçilir.

Eski sistemde veri hatalıysa yeni sisteme sessizce “temiz” değer yazmak denetim izini yok eder. Düzeltme kararı, kaynağı ve onayı ayrı kayıt olmalıdır. Eski belgeler yasal/kurumsal saklama planıyla aranabilir arşivde tutulur. Göç sonrası kullanıcı eski sisteme yeni işlem girmemeli; kesim saati ve sorumlusu ilan edilmelidir.

## Dönem açılışı için operasyon provası

Canlı kullanımdan önce akademik dönem bir günlük masaüstü ve saha provasıyla uçtan uca işletilmelidir. Öğrenci kaydı, sınıf listesi, öğretmen ataması, ders programı, LMS alanı, ücret planı, veli erişimi ve bildirim aynı örnek üzerinde doğrulanır. İlk ders günü yoğunluğu için eş zamanlı giriş ve performans testi yapılır. Şifre sıfırlama, yanlış sınıf, geç kayıt ve ödeme bekleyen öğrenci için destek karar ağacı hazır olur.

Prova sonunda yalnız yazılım hatası değil, süreç ve sorumluluk boşluğu kaydedilir. “Bu alanı kim düzeltir?”, “Veli hangi kanaldan destek alır?” ve “Resmî sisteme gönderim başarısızsa kim görür?” sorularının sahibi belirlenir. Dönem açılış komuta ekibi iletişim, eskalasyon ve günlük mutabakat ritmini uygular. Böylece ilk hafta kullanıcıların kişisel çözümler üretmesi yerine kurum tek çalışma biçimiyle ilerler. Operasyon provası, ürün kabulünün son adımı ve dönem risk değerlendirmesinin ilk girdisidir.

Prova bulguları yeni dönemin ilk iki haftasında günlük olarak yeniden ölçülür ve kalıcı işletim ekibine devredilir.

## Sonuç ve karar özeti

SIS, LMS ve ERP birbirinin alternatifi değil, okulun üç ayrı gerçekliğinin kayıt sistemidir: akademik/idari öğrenci yaşamı, öğrenme deneyimi ve kurumsal finans/kaynak. Başarılı mimari, bu sınırları görünmez kullanıcı deneyimiyle birleştirir; veriyi gereksiz çoğaltmaz, tarihçeyi korur ve hassas öğrenci bilgisini amaçla sınırlı tutar.

Seçimden önce yaşam döngüsü haritası, veri sahipliği matrisi, rol modeli ve demo paketi hazırlayın. [Education Suite Pro](/urunler/education-suite-pro) ürün kapsamını, [kayda dayalı uçtan uca akışı](/urunler/education-suite-pro/is-akislari/kayittan-ilk-karneye-uctan-uca) ve [çocuk verisi ile yapay zekâ etiği yeteneğini](/urunler/education-suite-pro/yetenekler/cocuk-verisi-kvkk-ve-yapay-zeka-etigi) inceleyebilirsiniz. Kurum tipinize göre mimari değerlendirme için [ön görüşme](/on-gorusme) planlanabilir.

## Resmî ve birincil kaynaklar

- Millî Eğitim Bakanlığı: [e‑Okul Yönetim Bilgi Sistemi](https://e-okul.meb.gov.tr/)
- MEB bütçe raporu: [e‑Okul'un kayıttan mezuniyete kapsamı ve veli bilgilendirme yapısı](https://sgb.meb.gov.tr/meb_iys_dosyalar/2023_08/24152252_2023_Butce_Raporu.pdf)
- KVKK: [Eğitim kurumunda çocukların özel nitelikli verilerine ilişkin 2020/255 sayılı karar özeti](https://www.kvkk.gov.tr/Icerik/6894/2020-255)
- KVKK: [Uzaktan eğitim platformları hakkında kamuoyu duyurusu](https://www.kvkk.gov.tr/Icerik/6723/Uzaktan-Egitim-Platformlari-Hakkinda-Kamuoyu-Duyurusu)

> Bu içerik teknoloji seçimi ve veri yönetişimi rehberidir; belirli bir kurum için hukuki uygunluk görüşü yerine geçmez.