Bakıda məktəb idarəetmə sisteminin hazırlanması məktəb üçün sadəcə yeni veb-sayt yaratmaq deyil. Bu, qəbuldan məzuniyyətə qədər əsas əməliyyatları eyni məlumat mənbəyi ətrafında quran rəqəmsal iş qatıdır. Düzgün layihələndirilmiş platforma qəbul müraciətlərini, şagird kartlarını, sinif bölgüsünü, davamiyyəti, ödəniş cədvəllərini, sənədləri və valideynlərə göndərilən bildirişləri əlaqələndirir. Nəticədə əməkdaşlar eyni məlumatı müxtəlif Excel fayllarına və mesajlaşma qruplarına təkrar daxil etmirlər.
Hazır məhsulun dəyişdirilməsi həmişə məqsəd olmamalıdır. Məktəbin işlək qəbul qaydaları, kampus strukturu, maliyyə siyasəti və kommunikasiya tərzi varsa, fərdi platforma mövcud proseslərə uyğun inteqrasiya qatı kimi hazırlanmalıdır. POLADO-nun veb platformaların hazırlanması xidməti bu tip daxili əməliyyat sistemləri, kabinetlər və idarəetmə iş axınları üçün uyğun yanaşmadır.
Məktəb idarəetmə platforması hansı problemi həll edir?
Əməliyyat problemi adətən “məlumat yoxdur” deyil, məlumatın parçalanmasıdır. Qəbul komissiyası namizəd siyahısını ayrıca saxlayır, müəllimlər davamiyyəti cədvəldə qeyd edir, mühasibat ödənişləri başqa proqramda izləyir, valideynlər isə sualları telefon və ya mesajlaşma kanalları ilə verir. Bu vəziyyətdə bir şagirdin aktual statusunu anlamaq üçün bir neçə əməkdaşdan məlumat toplamaq lazım gəlir.
Fərdi təhsil idarəetmə proqramı üçün əsas prinsip budur: şagird, valideyn, qeydiyyat, sinif, müqavilə, hesablanmış ödəniş, faktiki ödəniş, davamiyyət və sənəd ayrıca, lakin bir-biri ilə əlaqəli obyektlər olmalıdır. Məsələn, qəbuldan “qeydiyyat təsdiqləndi” mərhələsinə keçid şagird kartını yarada, tələb olunan sənədlər siyahısını aça və ilkin ödəniş planının hazırlanması üçün maliyyə əməkdaşına tapşırıq verə bilər. Beləliklə, məlumatı yenidən yazmaq əvəzinə vəziyyət dəyişikliyi idarə olunur.
Prioritet modullar: minimum faydalı əməliyyat nüvəsi
1. Qəbul və qeydiyyat iş axını
Qəbul modulu açıq forma ilə bitməməlidir. Namizədin mənbəyi, müraciət etdiyi sinif və tədris ili, müsahibə vaxtı, sənəd yoxlama statusu, qərar, gözləmə siyahısı səbəbi və növbəti addım görünməlidir. Sistem təkrarlanan müraciətləri müəyyən etməli, natamam faylları işarələməli və yalnız səlahiyyətli əməkdaşlara həssas qeydləri açmalıdır.
2. Şagird məlumat sistemi və akademik struktur
Şagird profilində şəxsiyyət məlumatları ilə yanaşı valideyn və qəyyum əlaqələri, tədris ili üzrə qeydiyyatlar, sinif və bölmə tarixçəsi, tibbi və ya dəstək qeydlərinə çıxış qaydaları, sənəd statusları və təcili əlaqə məlumatları saxlanır. Sinif, fənn, müəllim və dərs cədvəli ayrıca idarə edilərsə, davamiyyət və bildirişlər düzgün kontekstə bağlanır. Tarixçəni silmək əvəzinə tarixli dəyişikliklər saxlamaq illərarası hesabat və mübahisələrin araşdırılması üçün vacibdir.
3. Məktəblər üçün davamiyyət idarəetmə sistemi
Davamiyyət funksiyası “gəldi/gəlmədi” düyməsindən ibarət olmamalıdır. Məktəb gecikmə, üzrlü və üzrsüz yoxluq, erkən çıxış, dərs üzrə yoxluq və düzəliş sorğuları kimi öz qaydalarını modeldə əks etdirməlidir. Müəllim mobil brauzerdən sürətli qeyd aparmalı, rəhbər isə sinif, tarix, şagird və səbəb üzrə hesabat ala bilməlidir. Valideyn bildirişi yalnız məktəbin seçdiyi qaydadan sonra göndərilməli, göndəriş vaxtı və nəticəsi jurnal kimi saxlanmalıdır.
4. Məktəb ödənişlərinin idarə edilməsi
Məktəb ödəniş proqramı maliyyə uçot sistemini kor-koranə əvəz etməyə çalışmamalıdır. Onun rolu şagird müqaviləsi, təhsil haqqı planı, endirim, hissəli ödəniş tarixi, borc statusu, qəbz istəyi və maliyyə komandası üçün istisna siyahısı arasında etibarlı əməliyyat görünüşü yaratmaqdır. Məsələn, iki uşağı olan ailə üçün ailə hesabı ilə şagird səviyyəli borcları qarışdırmadan idarə etmək, təqaüd və endirimlərin kim tərəfindən nə vaxt təsdiqləndiyini izləmək lazımdır.
Onlayn ödəniş və ya mühasibat sistemi inteqrasiyası planlaşdırılırsa, uğurlu ödəniş bildirişi dərhal “ödənildi” demək olmamalıdır. Təkrar bildirişlər, uğursuz sorğular, qismən ödəniş, geri qaytarma və əl ilə düzəlişlər üçün idempotent emal, uzlaşdırma növbəsi və audit qeydləri nəzərdə tutulmalıdır.
5. Valideyn portalı və kontrollu kommunikasiya
Məktəb valideyn portalının hazırlanması valideynə yalnız onun uşaqları ilə bağlı məlumatı göstərməlidir: davamiyyət xülasəsi, elanlar, seçilmiş sənədlər, ödəniş vəziyyəti, sorğu və görüş istəyi. Portal hər daxili idarəetmə ekranının valideyn versiyası olmamalıdır. Bildirişlər elan, sinif, fərdi şagird və ya borc xatırlatması kimi hədəflənməli; vacib mesajlar üçün oxunma və çatdırılma jurnalı yaradılmalıdır.
Rol əsaslı giriş və məlumat təhlükəsizliyi
Məktəb sistemi uşaqlara və ailələrə dair həssas məlumat emal edir. Buna görə “admin” rolundan başqa dəqiq icazə modeli lazımdır: qəbul əməkdaşı müraciətləri görə bilər, müəllim yalnız öz siniflərinin davamiyyətini redaktə edə bilər, maliyyə əməkdaşı ödənişləri idarə edə bilər, valideyn isə yalnız öz övladı ilə əlaqəli məlumatı aça bilər. Giriş icazəsi yalnız ekran səviyyəsində deyil, API və məlumat səviyyəsində də yoxlanmalıdır.
Təhlükəsizlik çərçivəsinə güclü sessiya idarəetməsi, uyğun hallarda çoxfaktorlu identifikasiya, parolların təhlükəsiz saxlanması, şifrəli ötürmə, ehtiyat nüsxələr, bərpa sınaqları, giriş və kritik dəyişiklik audit jurnalları daxildir. NIST rəqəmsal identifikasiya qaydaları autentifikasiya və identifikatorların həyat dövrü üçün faydalı texniki istinad nöqtəsidir. İnterfeys isə klaviatura ilə istifadə, aydın fokus vəziyyətləri, kontrast və formaların başa düşülməsi baxımından WCAG 2.2 prinsiplərinə uyğun planlaşdırılmalıdır.
İnteqrasiya arxitekturası: sistem rekord mənbəyini müəyyən edin
Platforma layihəsinə başlamazdan əvvəl hər məlumat sahəsi üçün “rekord mənbəyi” müəyyən olunmalıdır. Məsələn, şagirdin kontakt məlumatının əsas mənbəyi məktəb platforması, bank əməliyyatının əsas mənbəyi isə ödəniş provayderi və ya mühasibat sistemi ola bilər. Bu qərar verilməzsə, iki sistem eyni sahəni dəyişdirərək uyğunsuzluq yaradır.
- Ödəniş provayderləri üçün təhlükəsiz geri bildiriş emalı və uzlaşdırma;
- Mühasibat sistemi ilə ixrac və ya idarə olunan API inteqrasiyası;
- SMS, e-poçt və ya push bildiriş provayderləri ilə göndəriş statuslarının qeyd olunması;
- Şəxsiyyət təminatçısı ilə əməkdaş girişinin mərkəzləşdirilməsi;
- İdxal faylları üçün yoxlama, səhv hesabatı və təkrar işə salına bilən proseslər.
İnteqrasiya ehtiyacı genişdirsə, əvvəlcə məlumat xəritəsi, hadisə axını və xəta ssenariləri hazırlanmalıdır. POLADO-nun UI/UX və məhsul dizaynı xidməti müxtəlif istifadəçi qrupları üçün ekranlardan əvvəl rol, iş axını və məlumat arxitekturasını dəqiqləşdirməyə kömək edir.
İlk versiya üçün real yol xəritəsi
- Proses kəşfi: qəbul, akademik şöbə, maliyyə və rəhbərliklə mövcud iş axınlarını, istisnaları və hesabatları xəritələyin.
- Məlumat modeli: şagird, valideyn, tədris ili, qeydiyyat, sinif, davamiyyət, hesablanma, ödəniş və sənəd arasındakı əlaqələri yazılı təsdiqləyin.
- MVP sərhədi: ilk buraxılışda qəbul, şagird kartı, siniflər, davamiyyət, ödəniş statusu və əsas valideyn portalını prioritet edin.
- Pilot və məlumat köçürülməsi: bir sinif və ya kampusda yoxlayın; Excel fayllarından köçürmədən əvvəl dublikatları və natamam sahələri təmizləyin.
- İşlək dəstək: ehtiyat nüsxə, monitorinq, hadisə cavabı, dəyişikliklərin buraxılışı və istifadəçi təlimini planın bir hissəsi edin.
Yaxşı məktəb platforması bütün prosesləri bir gündə rəqəmsallaşdırmır. Əvvəlcə məlumatın təkrar daxil edildiyi, gecikmənin yarandığı və cavabdehliyin qeyri-müəyyən olduğu keçidləri aradan qaldırır.
Fərdi platforma nə vaxt daha məntiqlidir?
Bir neçə kampusu olan, öz qəbul mərhələlərini tətbiq edən, fərqli ödəniş qaydaları olan və ya valideyn təcrübəsini brendinə uyğun qurmaq istəyən məktəblər üçün fərdi inkişaf xüsusilə dəyərlidir. Eyni yanaşma mövcud mühasibat, LMS və ya giriş nəzarəti alətlərini saxlayaraq onların arasındakı əməliyyat boşluqlarını bağlamaq istəyən təşkilatlar üçün də uyğundur.
Layihədən sonra təhlükəsizlik yeniləmələri, performans izlənməsi və mərhələli funksional inkişaf tələb olunur. Bu ehtiyaclar üçün texniki dəstək və konsaltinq xidməti məhsulun istifadəyə verildikdən sonra da idarəolunan qalmasına kömək edir. Məktəbinizin qəbul, davamiyyət, ödəniş və valideyn kommunikasiya prosesləri hazırda ayrı alətlərdədirsə, POLADO ilə əlaqə saxlayın və proses xəritəsi, MVP həcmi, inteqrasiya riskləri və tətbiq mərhələlərini müzakirə edin.