ما بنيناه ولماذا
نظام جامعي متكامل يغطي القبول والتسجيل والشؤون الأكاديمية وبوابات المحاضرين والطلاب والمالية الجامعية، مطبَّق في ثلاث جامعات بثلاث دول بثلاث بيئات تنظيمية مختلفة.
التحدي
الوضع التشغيلي كما وجدناه قبل أن نكتب سطراً واحداً.
ثلاث جامعات في ثلاث دول، تدير أعمالها بخليط من ملفات Excel وأنظمة جزئية وورق. القبول يستقبل مستندات تُراجَع يدوياً، والتسجيل يتعارض مع الجداول ومتطلبات المقررات، والدرجات تُجمَّع من المحاضرين بالبريد، والرسوم تُتابَع في نظام لا يعرف من سجّل ومن لم يسدّد.
التحدي الأصعب لم يكن بناء النظام، بل أن يخدم ثلاث بيئات تنظيمية مختلفة — لكل دولة لوائحها الأكاديمية ومتطلبات جهاتها الإشرافية وسلّم درجاتها — دون أن يتحوّل إلى ثلاثة أنظمة منفصلة تُصان ثلاث مرات.
قبل
- خليط من ملفات Excel وأنظمة جزئية وورق في ثلاث جامعات
- درجات تُجمَّع بالبريد ورسوم في نظام لا يعرف من سجّل ومن سدّد
- ثلاث بيئات تنظيمية تعني ثلاثة أنظمة تُصان ثلاث مرات
بعد
- ثلاث جامعات تُدار بالكامل على نظام واحد بلا أدوات مساعدة
- ربط الحالة المالية بأهلية التسجيل تلقائياً كل فصل
- إضافة جامعة جديدة دون تفريع النظام أو مضاعفة كلفة الصيانة
كيف عملنا على هذا النظام
المسار نفسه في كل مشروع نبنيه — يتغيّر محتواه لا ترتيبه.
تحليل العمل
نجلس مع من يستخدم النظام يومياً، ونرسم المسار الفعلي بكل استثناءاته — وهي غالباً سبب تعثّر المشاريع لاحقاً.
تصميم المعمارية
نموذج البيانات ومصفوفة الصلاحيات ونقاط التكامل وسلوك النظام تحت الحِمل — تُحسم قبل أي واجهة.
التطوير
بناء على مراحل قابلة للاستخدام. كل مرحلة تدخل الخدمة عاملةً، فيُصحَّح المسار مبكراً وبكلفة أقل.
التكامل
ربط النظام بما حوله — محاسبة ودفع وجهات خارجية — بطبقة لا تنكسر عند أول تعطّل في الطرف الآخر.
التحسين والتشغيل
قياس الأداء تحت حِمل حقيقي، ثم تشغيل ومراقبة وصيانة تمتدّ بعد التسليم لا تنتهي به.
الحل بوحداته
ما بنيناه فعلاً، مفصّلاً بالوحدة لا موصوفاً بعبارة عامة.
القبول
— تقديم إلكتروني، رفع المستندات وتدقيقها، معادلة الشهادات، مسار موافقات لجنة القبول، وإصدار القرارات وإشعاراتها.
التسجيل والشؤون الأكاديمية
— الخطط الدراسية، المقررات ومتطلباتها السابقة، الشُعب والجداول، التسجيل والحذف والإضافة مع كشف التعارضات وحدود الساعات.
بوابة المحاضر
— قوائم الطلاب، رصد الحضور، إدخال الدرجات بأوزانها المعتمدة، رفع المواد، والتواصل مع الشُعبة.
بوابة الطالب
— الجدول، الدرجات، السجل الأكاديمي، المعدل التراكمي، الرسوم والمدفوعات، والطلبات الإدارية.
المالية الجامعية
— الرسوم وخطط التقسيط، المنح والخصومات، السداد، وربط الحالة المالية بأهلية التسجيل.
الإدارة والتقارير
— إحصاءات القبول والتسجيل ومعدلات النجاح، والتقارير المطلوبة للجهات الإشرافية في كل دولة.
المعمارية التقنية
الطبقات كما بُنيت فعلاً في هذا النظام — من قناة المستخدم إلى البنية التي تشغّله.
واجهات برمجية أولاً
كل طبقة تتحدّث إلى ما فوقها عبر واجهة موثّقة، فإضافة قناة جديدة لاحقاً لا تعني إعادة بناء ما تحتها.
الأمان بين الطبقات
الصلاحيات تُفحص في طبقة الأعمال لا في الواجهة، وسجلّ التدقيق يوثّق كل عملية تغيّر بيانات.
أداء تحت الحِمل
العمليات الثقيلة تُدفع إلى طوابير خلفية، والقراءات الأكثر تكراراً تُخزَّن مؤقتاً، فتبقى مسارات المستخدم سريعة في الذروة.
التقنيات ولماذا اخترناها
نختار الأداة بحسب ما يجب أن تتصل به وما يجب أن تصمد أمامه — لا بحسب ما هو رائج هذا العام.
هندسة الخلفية Backend
طبقة الأعمال والواجهات البرمجية. اخترناه لنُضج منظومته في الصلاحيات والطوابير وترحيلات قواعد البيانات — وهي تحديداً ما تحتاجه الأنظمة المؤسسية طويلة العمر.
لغة الخلفية. توفّر بيئات تشغيل واستضافة وكوادر صيانة في كل سوق نعمل فيه، فلا يرتهن النظام بمورّد واحد.
الواجهات Frontend
للوحات التشغيلية الكثيفة التي يقضي فيها المستخدم يومه — حيث تُحدَّث أجزاء الشاشة باستمرار دون إعادة تحميل.
البيانات والأداء Data
قاعدة البيانات المعاملاتية. اخترناها لثبات سلوكها تحت الحِمل ووضوح خطط تنفيذ استعلاماتها، وهو ما يجعل ضبط الأداء عملاً هندسياً لا تخميناً.
تخزين مؤقت للبيانات الأكثر قراءة وإدارة الجلسات. يمتصّ الحِمل عن قاعدة البيانات في الذروة، وهي اللحظة الوحيدة التي يُقاس عليها النظام.
البنية والتشغيل Infrastructure
حاويات تجعل بيئة التطوير والاختبار والإنتاج متطابقة، فيختفي صنف كامل من الأعطال التي تظهر عند النشر فقط.
نظام تشغيل الخوادم. نضبطه ونراقبه ونطبّق تحديثاته الأمنية بأنفسنا، فلا تبقى البنية صندوقاً أسود.
الأنظمة المرتبطة Connected Systems
تحديات هندسية حللناها
القرارات التي اتُّخذت في هذا النظام تحديداً، وسبب كل منها.
نواة واحدة وطبقة لوائح لكل جامعة
— القواعد الأكاديمية (سلّم الدرجات، حدود الساعات، شروط الإنذار والفصل، صيغ التقارير الرسمية) تُعرَّف كبيانات قابلة للتهيئة لا كمنطق مكتوب في الكود. هذا ما جعل جامعة ثالثة تُضاف دون إعادة كتابة النظام.
التسجيل عملية ذرّية
— التحقق من المتطلبات والتعارضات والحالة المالية والسعة يجري في معاملة واحدة، لأن التسجيل الجزئي في نظام أكاديمي كارثة لا يكتشفها أحد إلا بعد أسابيع.
الصلاحيات على مستوى الكلية والقسم
— لا على مستوى الشاشة، فرئيس القسم يرى قسمه فقط، والقبول لا يرى الدرجات.
الأثر بعد التشغيل
ما تغيّر فعلاً في عمل العميل — لا ما وعدنا به قبل البدء.
- ثلاث جامعات تُدار بالكامل على نظام واحد، دون الحاجة إلى أدوات أو أنظمة خارجية مساعدة
- إضافة جامعة جديدة ببيئة تنظيمية مختلفة دون تفريع النظام أو مضاعفة كلفة الصيانة
- انتقال دورة القبول والتسجيل من الورق والبريد إلى مسار موثّق قابل للتدقيق
- ربط الحالة المالية بأهلية التسجيل تلقائياً بدل المطابقة اليدوية كل فصل
الأرقام أعلاه تخصّ حجم نظام العميل الذي بنيناه ونشغّل بنيته، لا حجم أعمالنا نحن. ونلتزم باتفاقيات السرية، فنعرض العمق التقني دون أسماء العملاء.