الأنظمة التي تحتاجها الجامعة: من القبول إلى التخرج

في المقال الأول من السلسلة رتبنا أنظمة الشركة حول سجلين رئيسيين، هما الموظف والعميل، ثم رتبناها في المقال الثاني على مراحل نمو الشركة. ولكن الجامعة لا تشبه الشركة في هذا، فعدد الموظفين فيها لا يتغير كثيراً من سنة إلى أخرى، بينما يدخلها آلاف الطلاب كل عام ويخرج منها آلاف، ولكل طالب مسار طويل يبدأ قبل القبول وينتهي بعد التخرج بسنوات، وكل مرحلة في هذا المسار يملكها قسم مختلف ونظام مختلف. ولذلك فالسؤال في الجامعة ليس «متى نضيف النظام؟» وإنما «أي نظام يملك الطالب في كل مرحلة، وكيف ينتقل سجله من نظام إلى آخر دون أن يعيد أحد كتابته؟».

المواضيع في السلسلة:

1. ما الأنظمة التي يحتاجها كل قسم في مؤسستك كحد أدنى؟
2. من 5 موظفين إلى 500: متى تضيف كل نظام؟
3. الأنظمة التي تحتاجها الجامعة: من القبول إلى التخرج. (الموضوع الحالي)

وهذا المقال محايد تجاه طريقة التشغيل مثل المقالين السابقين، فإذا قررت جامعتك أن تعتمد على المصادر المفتوحة فخطة الأدوات بالترتيب وحوكمتها في المصادر المفتوحة للجامعات، وأما التقييم والتعليم في زمن الذكاء الاصطناعي فله سلسلة مستقلة تبدأ من الواجبات والاختبارات الجامعية في زمن الذكاء الاصطناعي.

وسوف نناقش في هذا المقال ما يلي:

• مسار الطالب من الاستقطاب إلى الخريجين، والأنظمة في كل مرحلة.
• نظام معلومات الطلاب SIS، ولماذا هو مركز أنظمة الجامعة وليس نظام إدارة التعلم LMS.
• الأقسام الأكاديمية والإدارية، وما يملكه كل قسم.
• التكاملات: الحسابات والدخول الموحد، ونقل الشعب والدرجات بين ال SIS وال LMS، والأدوات الخارجية عبر LTI.
• السياق السعودي كما في الصفحات الرسمية.
• تجربة عملية: السكربت نفسه من المقال الثاني على مصفوفة أنظمة الجامعة.

مسار الطالب والأنظمة في كل مرحلة

أوضح طريقة لرؤية أنظمة الجامعة أن ترسم مسار الطالب، ثم تضع تحت كل مرحلة الأنظمة التي يحتاجها، وتحت المسار كله الأساس الذي تعتمد عليه كل المراحل. والصورة التالية تبين ذلك:

والمراحل السبع كما يلي:

• الاستقطاب Recruit: صفحات البرامج على الموقع، ومتابعة المهتمين وأسئلتهم قبل التقديم في نظام علاقات، وهو من نوع إدارة علاقات العملاء CRM ولكن العميل هنا هو الطالب المحتمل.
• القبول Admit: بوابة تقديم إلكترونية تجمع البيانات والمستندات وتحسب المفاضلة، وعند القبول ينشأ للطالب رقم جامعي وحساب.
• التسجيل Enrol: يصبح الطالب سجلاً في نظام معلومات الطلاب SIS، ويسجل المقررات والشعب، وتصدر عليه الرسوم إن وجدت، ويوضع في جدول بقاعات وأوقات.
• التعلم والبحث Learn: المقررات في نظام إدارة التعلم LMS، والمحاضرات الافتراضية، والمكتبة، والمستودع العلمي للرسائل والأبحاث، ومنح البحث ومشاريعه لأعضاء هيئة التدريس وطلاب الدراسات العليا، وخدمات الطلاب.
• التقييم Assess: الاختبارات وبيئتها الآمنة، ونقل الدرجات النهائية من ال LMS إلى ال SIS، واستبيانات تقييم المقررات التي تحتاجها جهات الاعتماد.
• التخرج Graduate: التدقيق الأكاديمي Degree Audit الذي يتحقق من أن الطالب أكمل خطته، وإخلاء الطرف من المكتبة والمالية والسكن، ثم كشف الدرجات والشهادة.
• الخريجون Alumni: متابعة الخريجين وتوظيفهم، وهي بيانات تطلبها جهات الاعتماد أيضاً.

وأما الأساس تحت المسار فهو العمود الفقري نفسه الذي شرحناه في المقال الأول، مع فرق مهم، وهو أن الجامعة تملك مصدرين للهوية وليس مصدراً واحداً، فالموظفون وأعضاء هيئة التدريس مصدرهم نظام الموارد البشرية في ال ERP، والطلاب مصدرهم ال SIS، وسوف نعود إلى هذا في قسم التكاملات.

نظام معلومات الطلاب SIS: مركز الجامعة

كثير من الجامعات تبدأ مشروع التحول الرقمي من نظام إدارة التعلم LMS لأنه الأكثر ظهوراً للطلاب والمعلمين، ولكن ال LMS لا يملك الطالب، وإنما يقرأه. فنظام معلومات الطلاب Student Information System، واختصاراً SIS، هو مصدر سجل الطالب الرسمي، وهو الذي يحفظ ما يلي:

• السجل الشخصي والأكاديمي: بيانات الطالب، وبرنامجه، وخطته الدراسية، وحالته، مثل منتظم أو مؤجل أو منسحب.
• التسجيل: المقررات والشعب التي سجلها في كل فصل، وهي التي يجب أن تصل إلى ال LMS.
• الدرجات الرسمية: الدرجة النهائية المعتمدة في كل مقرر، والمعدل، وهي تختلف عن درجات الواجبات اليومية في ال LMS.
• كشف الدرجات والتخرج: الوثيقة الرسمية التي تخرج من الجامعة، والتدقيق الأكاديمي الذي يسبقها.

وقد يتساءل البعض: لماذا لا نجعل ال LMS هو المصدر ونضيف إليه ما ينقصه؟ والإجابة أن ال LMS مصمم ليكون مرناً، فالمعلم يستطيع أن ينشئ مقرراً ويضيف طالباً ويغير درجة، وهذه المرونة هي ما يحتاجه التعليم اليومي، ولكنها عكس ما يحتاجه السجل الرسمي، الذي يجب أن يكون كل تغيير فيه بصلاحية محددة وسجل تدقيق. ولذلك فالترتيب الصحيح أن يقرأ ال LMS الطلاب والشعب من ال SIS، ويعيد إليه الدرجة النهائية فقط، وقد شرحنا حدود ال LMS نفسه في ما الذي لا يقوم به ال LMS؟.

الأنظمة في كل مرحلة

الجدول التالي يجمع أنظمة كل مرحلة، ومعها القسم الذي يملكها، والأمثلة، وأغلبها أنواع أنظمة وليست أسماء منتجات، لأن أنظمة الجامعات الكبيرة تختلف كثيراً بين الدول وكثير منها يبنى محلياً:

لاحظ في الجدول أن مرحلتي الاستقطاب والخريجين تستخدمان النوع نفسه من الأنظمة، أي نظام علاقات، وكثير من الجامعات تستخدم المنصة نفسها لهما، والسبب أن الخريج قد يعود طالب دراسات عليا، فيبقى تاريخه في مكان واحد.

الأقسام الأكاديمية والإدارية

الجامعة فيها نوعان من الأقسام، والنوعان يحتاجان أنظمة مختلفة، كما يلي:

والجملة الأخيرة في صف تقنية المعلومات هي أهم ما في الجدول، فقسم تقنية المعلومات في الجامعة لا يجب أن يكون مالك سجل الطالب أو محتوى المقررات، وإنما مالك الطرق التي تنقلها، والسبب أن من يملك الطريق يعرف متى يتعطل، أما من يملك المحتوى فيعرف هل هو صحيح.

التكاملات: كيف تتكلم الأنظمة مع بعضها؟

إذا كان لكل مرحلة نظام، فالمشكلة الحقيقية هي ما بين الأنظمة، والصورة التالية تبين أهم التكاملات حول ال SIS:

والتكاملات في الصورة كما يلي:

• الحسابات Provisioning: عند قبول الطالب ينشئ ال SIS حسابه في مزود الهوية، وعند تخرجه أو انسحابه تتغير حالته، فتتغير صلاحياته، والطريقة هي نفسها التي شرحناها للموظفين في دورة حياة حساب الموظف JML وSCIM، ولكن بمصدرين، فالموظفون من الموارد البشرية والطلاب من ال SIS، والمعيد الذي يدرس وهو طالب دراسات عليا له سجل في الاثنين، فقرر من البداية أي المصدرين يملك حسابه.
• الدخول الموحد SSO: كل نظام في الصورة يدخل إليه الطالب والموظف بالحساب نفسه عبر SAML أو OpenID Connect، كما في authentik وإدارة الأدوار عبر التطبيقات.
• الشعب والدرجات بين ال SIS وال LMS: المعيار المفتوح لهذا الربط هو OneRoster من منظمة 1EdTech، التي تصفه بأنه يحل حاجة المؤسسة التعليمية إلى تبادل بيانات قوائم الطلاب والمقررات والدرجات بين الأنظمة بأمان، ويدعم التبادل بملفات CSV أو عبر REST، وآخر إصدار بحسب الصفحة هو OneRoster 1.2 في 14 أكتوبر 2026. فإذا كان ال SIS وال LMS يدعمانه فاستخدمه بدل ربط خاص، وإلا فالحد الأدنى تصدير CSV مجدول من ال SIS واستيراده في ال LMS.
• الأدوات الخارجية داخل المقرر: عبر معيار LTI 1.3 وحزمة LTI Advantage، وقد شرحنا كيف يعمل وما يقدمه في الربط مع الأدوات الخارجية عبر LTI، فلا نعيده هنا.
• المكتبة والمالية: المكتبة تحتاج حالة الطالب لتسمح له بالإعارة وتوقفها عند تخرجه، والمالية تحتاج تسجيله لتحسب رسومه، وكلاهما يقرأ من ال SIS، وكلاهما يعيد إليه حالة إخلاء الطرف عند التخرج.

ولكل سهم في الصورة مالك ومهمة مجدولة وتنبيه عند الفشل، والسبب أن التكامل الذي يتعطل بصمت يكتشف في أسوأ وقت، وهو الأسبوع الأول من الفصل عندما لا يجد مئات الطلاب مقرراتهم في ال LMS.

السياق السعودي

إذا كانت جامعتك في المملكة، فهناك جهات ومنصات رسمية ترتبط بأنظمتها، والجدول التالي يجمع ما تحققنا منه في صفحاتها الرسمية في 14 أكتوبر 2026:

لاحظ أننا لم نضع في الجدول منصات لم نجد لها صفحة رسمية واضحة تشرح علاقتها بأنظمة الجامعة، فإذا كانت جامعتك مرتبطة بمنصة وطنية أخرى للقبول أو الابتعاث أو الاعتماد، فاجعل الربط معها صفاً في جدول التكاملات له مالك، مثل أي تكامل آخر.

تجربة عملية: مصفوفة أنظمة الجامعة

في المقال الثاني كتبنا سكربتاً يحول مصفوفة الأقسام والمراحل إلى جداول وقائمة تحقق، ويرفض الملف إذا جاء نظام قبل ما يعتمد عليه. والسكربت نفسه يعمل على الجامعة دون تعديل، فالمراحل هنا هي مراحل مسار الطالب، والحقل needs يعني أن النظام يقرأ بيانات نظام آخر، والحقل signal يعني ما الذي يحدث بدون هذا النظام. والصفوف التالية ثلاثة صفوف اخترناها من الملف university-systems.json، كل صف كما هو:

{ "id": "sis", "dept": "Registrar", "system": "Student information system (SIS)", "col": "P3", "needs": ["apply"], "signal": "no single student record" },
{ "id": "lms", "dept": "Academic", "system": "LMS (courses)", "col": "P4", "needs": ["sis", "idp"], "signal": "course lists typed by hand" },
{ "id": "grades", "dept": "Registrar", "system": "Grade sync LMS -> SIS", "col": "P5", "needs": ["lms", "sis"], "signal": "grades retyped into the SIS" },

ونشغله في Container كما في المقال الثاني:

cd lab
docker run --rm --name lab-org-univ -v "$PWD:/lab:ro" -w /lab \
  python:3.13.16-slim python matrix.py university-systems.json

والمخرج سوف يكون كما يلي، وهذا القسمان الأول والثاني منه:

26 systems, 8 stages, 0 dependency problems
== 1. Systems added at each stage
-- P0 Foundation (before any student): +5 (total 5)
   Finance/HR       ERP: finance, HR, payroll
   IT               Identity provider + SSO
   IT               Email + calendar
   IT               Backup + restore test
   IT               IT service desk (ITSM)
-- P1 Recruit: +2 (total 7)
   Admissions       Prospect CRM
   Marketing        Website / CMS
-- P2 Admit: +2 (total 9)
   Admissions       Online application + documents
   IT               Student account creation
-- P3 Enrol: +3 (total 12)
   Finance          Fees + student billing
   Registrar        Student information system (SIS)
   Registrar        Timetabling + rooms
-- P4 Learn + research: +6 (total 18)
   Academic         LMS (courses)
   Academic         Virtual classroom
   Library          Library system (ILS)
   Library          Research repository
   Research         Research grants + projects
   Student affairs  Student services desk
-- P5 Assess: +3 (total 21)
   Academic         Exams + lockdown browser
   Quality          Course evaluation surveys
   Registrar        Grade sync LMS -> SIS
-- P6 Graduate: +3 (total 24)
   Registrar        Degree audit
   Registrar        Graduation clearance
   Registrar        Transcripts + verifiable certificates
-- P7 Alumni: +2 (total 26)
   Alumni           Alumni CRM
   Careers          Careers + job board

== 2. Department x stage (number of systems added)
department         P0   P1   P2   P3   P4   P5   P6   P7  total
IT                  4    .    1    .    .    .    .    .      5
Finance/HR          1    .    .    .    .    .    .    .      1
Marketing           .    1    .    .    .    .    .    .      1
Admissions          .    1    1    .    .    .    .    .      2
Registrar           .    .    .    2    .    1    3    .      6
Finance             .    .    .    1    .    .    .    .      1
Academic            .    .    .    .    2    1    .    .      3
Library             .    .    .    .    2    .    .    .      2
Research            .    .    .    .    1    .    .    .      1
Student affairs     .    .    .    .    1    .    .    .      1
Quality             .    .    .    .    .    1    .    .      1
Alumni              .    .    .    .    .    .    .    1      1
Careers             .    .    .    .    .    .    .    1      1
all                 5    2    2    3    6    3    3    2     26

في المخرج أعلاه لاحظ التالي:

• خمسة أنظمة من ستة وعشرين يجب أن تكون جاهزة قبل أول طالب، أربعة منها لتقنية المعلومات، وهي الأساس الذي يعتمد عليه كل ما بعده.
• عمادة القبول والتسجيل Registrar تملك ستة أنظمة، وهي أكثر جهة في الجامعة، وأغلبها في مرحلتي التقييم والتخرج، وهذا يفسر لماذا يكون ضغط نهاية الفصل عليها هي.
• مرحلة التعلم والبحث فيها ستة أنظمة لأربع جهات مختلفة، وأغلبها يقرأ من ال SIS أو من الهوية، أي أن ال LMS والمكتبة والمستودع وخدمات الطلاب لا تعمل جيداً قبل ال SIS مهما كانت جيدة وحدها.

وأما القسم الثالث من المخرج فهو قائمة التحقق، وكل بند فيها هو النظام وبجانبه ما يحدث بدونه:

== 3. Checklist (you need it when...)
-- Foundation (before any student)
[ ] Identity provider + SSO: one password per system, no clean leavers
[ ] Email + calendar: staff use personal mailboxes
[ ] Backup + restore test: a lost semester of grades
[ ] IT service desk (ITSM): requests lost in email at semester start
[ ] ERP: finance, HR, payroll: staff and budgets in spreadsheets
-- Recruit
[ ] Website / CMS: programme pages out of date
[ ] Prospect CRM: enquiries answered late or twice
-- Admit
[ ] Online application + documents: paper files and emailed scans
[ ] Student account creation: students wait a week for a login
-- Enrol
[ ] Student information system (SIS): no single student record
[ ] Fees + student billing: fees reconciled by hand
[ ] Timetabling + rooms: room clashes in week one
-- Learn + research
[ ] LMS (courses): course lists typed by hand
[ ] Virtual classroom: meeting links pasted per lecture
[ ] Library system (ILS): loans and fines outside the student record
[ ] Research repository: theses and papers scattered
[ ] Research grants + projects: grant spend tracked in sheets
[ ] Student services desk: students queue at offices
-- Assess
[ ] Exams + lockdown browser: exam day overloads the LMS
[ ] Grade sync LMS -> SIS: grades retyped into the SIS
[ ] Course evaluation surveys: no evidence for accreditation
-- Graduate
[ ] Degree audit: graduation checks by hand
[ ] Graduation clearance: students chase signatures
[ ] Transcripts + verifiable certificates: employers phone to verify degrees
-- Alumni
[ ] Alumni CRM: graduates lost after the ceremony
[ ] Careers + job board: no employment data for accreditation

اكسرها: ال LMS قبل ال SIS

هذا هو الخطأ الذي ذكرناه في قسم ال SIS، أي أن تبدأ الجامعة بال LMS في مرحلة القبول قبل أن يوجد نظام معلومات الطلاب، فلنجربه على نسخة من الملف داخل ال Container:

docker run --rm --name lab-org-univ-break -v "$PWD:/lab:ro" -w /lab python:3.13.16-slim sh -c 'python - <<EOF
import json
d = json.load(open("university-systems.json", encoding="utf-8"))
for r in d["rows"]:
    if r["id"] == "lms": r["col"] = "P2"
json.dump(d, open("/tmp/broken.json", "w"))
EOF
python matrix.py /tmp/broken.json; echo "exit code $?"'

والمخرج سوف يكون كما يلي:

26 systems, 8 stages, 1 dependency problems
  ERROR lms (P2) needs sis, which only comes in P3
exit code 1

والخطأ هنا هو ما يحدث في الجامعة فعلاً عندما يسبق ال LMS ال SIS، فالمقررات تنشأ في ال LMS يدوياً، ويضاف الطلاب إليها بملفات يجهزها كل قسم بطريقته، ثم يأتي ال SIS بعد ذلك فلا تتطابق أسماء الشعب ولا أرقام الطلاب، ويصبح الربط بينهما مشروع تنظيف بيانات قبل أن يكون مشروع تكامل.

أخطاء شائعة

• البدء بال LMS قبل ال SIS، أو جعل ال LMS مصدراً للطلاب والشعب.
• نقل الدرجات النهائية يدوياً في نهاية الفصل.
• مصدر واحد للهوية يفترض أن كل شخص موظف أو طالب فقط، فيتعطل حساب المعيد وطالب الدراسات العليا الذي يعمل في الجامعة.
• حسابات الخريجين تبقى بكل صلاحياتها، أو تغلق فجأة دون أن يعرف الخريج كيف يصل إلى كشف درجاته.
• كل كلية تختار أداة اختبارات أو منصة اجتماعات مختلفة، فيحتاج الطالب في الفصل الواحد إلى خمسة حسابات.
• تكاملات بلا مالك ولا تنبيه، تكتشف في الأسبوع الأول من الفصل.
• شراء ما توفره المنصات الوطنية للجامعة، مثل مصادر المكتبة الرقمية، دون مراجعة.

تدريب عملي

• ارسم مسار الطالب في جامعتك بالأنظمة الفعلية، وضع تحت كل نظام القسم المالك، ثم ابحث عن كل مكان يكتب فيه موظف بيانات الطالب بيده.
• عدل university-systems.json بأنظمة جامعتك، وأضف لكل صف حقلاً بطريقة التكامل، مثل OneRoster أو CSV أو يدوي، ثم شغل السكربت.

الخلاصة

• أنظمة الجامعة تترتب على مسار الطالب من الاستقطاب إلى الخريجين، وتحتها أساس من الهوية والبريد ومكتب الخدمة والنسخ الاحتياطي وال ERP.
• نظام معلومات الطلاب SIS هو مصدر سجل الطالب الرسمي، وال LMS يقرأ منه الطلاب والشعب ويعيد إليه الدرجة النهائية فقط.
• للهوية في الجامعة مصدران: الموارد البشرية للموظفين وال SIS للطلاب، وقرر من البداية من يملك حساب من له دوران.
• التكاملات المفتوحة هي OneRoster للشعب والدرجات، وLTI للأدوات داخل المقرر، وSAML أو OpenID Connect للدخول، ولكل تكامل مالك وتنبيه.
• في التجربة احتاجت الجامعة خمسة أنظمة قبل أول طالب، وملكت عمادة القبول والتسجيل ستة أنظمة، ورفض السكربت الملف عندما سبق ال LMS ال SIS.

وبهذا تكتمل السلسلة، وللتفاصيل في كل نظام ارجع إلى أدلته المنفصلة على الموقع:

دليلالمصادر المفتوحة للجامعات: خطة وأدوات بالترتيبدليل لقيادة الجامعة يشرح ما تكسبه فعلاً من المصادر المفتوحة وما تكلفه، وبأي ترتيب تنقل خدماتها إليها.دليلأنظمة إدارة التعلم LMS: ماذا تحتاج منها مؤسستك التعليمية؟ما الذي يفعله نظام إدارة التعلم LMS، وما الذي تحتاجه منه مدرستك أو جامعتك فعلاً قبل أن تختار بين الأنظمة المفتوحة.دليلMoodle: منصة تعلم بالعربية على سيرفرككيف تثبت Moodle على سيرفرك وتجهزه بالعربية، ثم تنشئ مقرراً واختباراً وتسجل الطلاب وتأخذ له نسخة احتياطية كاملة.دليلالواجبات والاختبارات الجامعية في زمن الذكاء الاصطناعيكيف تقيم طلابك عندما يكتب الذكاء الاصطناعي الواجب، ولماذا لا تنفع أدوات الكشف، وما الذي يجب أن تدرسه الآن.

سجل التحديثات

• أكتوبر 2026: كتابة المقال مع تشغيل سكربت المقال الثاني بلغة Python 3.13.16 في Container من python:3.13.16-slim على Docker Engine 29.8.0، ومراجعة صفحات 1EdTech ووزارة التعليم والمكتبة الرقمية السعودية والمركز الوطني للتعليم الإلكتروني ومنصة حوكمة البيانات الوطنية كما هي في 14 أكتوبر 2026.