تكامل البانر — 11 شهر من التعقيد: لماذا هو الحاجز الأصعب في النقل الجامعي

ملخص تنفيذي

في كل مرة يسأل فيها رائد أعمال: 'كم يأخذ تكامل البانر؟' تكون الإجابة التقليدية: '3-6 أشهر'. الحقيقة المرة: 11 شهراً. هذا ليس رقماً خيالياً — إنه متوسط الوقت الذي استغرقه فريق رَكب المكون من 8 مهندسين لبناء طبقة تكامل كاملة وآمنة ومستقرة مع أنظمة الجامعات السعودية.

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

١. ما هو البانر — ولماذا لا يمكن تجاهله؟

١.١ التعريف

Banner by Ellucian هو نظام ERP (تخطيط موارد المؤسسة) المتخصص في إدارة الجامعات. في السعودية، يستخدم من قِبَل 22+ جامعة حكومية وأهلية. النظام يدير: جداول المحاضرات، تسجيل الطلاب، الشعب الدراسية، المواقع والكليات، بيانات الطلاب الأكاديمية والشخصية، والتقويم الأكاديمي.

ببساطة: البانر هو 'عقل الجامعة الرقمي'. أي نظام تريد أن يخدم طلاب الجامعة يجب أن يتحدث مع البانر.

١.٢ لماذا لا يمكنك تجاهله

في النقل الجامعي، أنت تحتاج من البانر:

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

١.٣ المفاجأة: ليس هناك 'بانر واحد'

أكبر صدمة يتعرض لها المطور الجديد: 'البانر' ليس نظاماً واحداً موحداً. كل جامعة لديها:

- نسخة مختلفة من البانر (بعضها Banner 8، بعضها Banner 9، بعضها Banner XE)

- تخصيصات (Customizations) محلية تراكمت عبر 10-15 سنة

- إعدادات أمان مختلفة وسياسات وصول مختلفة

- تكوين مختلف للبوابة الوسيطة (ESB/Middleware)

- فريق تقنية مختلف — بشخصيات مختلفة وأولويات مختلفة

النتيجة: التكامل مع جامعة الملك سعود ليس هو نفسه التكامل مع جامعة الملك عبدالعزيز. كل جامعة = مشروع تكامل شبه مستقل.

٢. طبقات التكامل السبع — تشريح تقني

تكامل البانر الكامل ليس 'API واحد'. إنه 7 طبقات منفصلة، كل طبقة لها تحدياتها الخاصة:

الطبقة ١: المصادقة والصلاحيات (2-4 أسابيع)

أول عقبة: لا يمكنك حتى طلب بيانات من البانر إلا بعد المرور بنظام المصادقة. الجامعات السعودية تستخدم عادة: SAML 2.0، Shibboleth، أو SSO مخصص. بعض الجامعات تضيف طبقة مصادقة ثنائية (2FA) إلزامية.

التحدي الخفي: تحتاج موافقة فريق أمن المعلومات في الجامعة. هذا الفريق مشغول — جداً مشغول. قد تنتظر 3-4 أسابيع لمجرد الحصول على 'معرف عميل' (Client ID) و 'كلمة سر' (Client Secret).

الطبقة ٢: اكتشاف الخدمات ومعرفات البيانات (3-5 أسابيع)

بعد المصادقة، تحتاج أن تعرف: أين بيانات الجداول؟ أين بيانات الطلاب؟ أين الكليات؟ البانر ليس لديه 'نقطة نهاية موحدة' تعطيك كل شيء. البيانات موزعة عبر:

- Banner Student API (للطلاب والتسجيل)

- Banner Finance API (للدفع والفواتير)

- Banner HR API (للموظفين — أحياناً بيانات السائقين الموظفين)

- جداول القاعات (Room Scheduling) — نظام منفصل غالباً

- كل نظام له Endpoint مختلف، نسخة مختلفة، وتنسيق استجابة مختلف

المشكلة: وثائق API المتاحة للعامة تغطي فقط ~30% من الـ endpoints الفعلية. الـ 70% الباقية تحتاج أن 'تكتشفها' بالتعاون مع فريق تقنية الجامعة — وهذا يتطلب علاقة شخصية.

الطبقة ٣: تحويل البيانات وتطبيعها (4-6 أسابيع)

البيانات الخام من البانر غير قابلة للاستخدام المباشر. تحتاج طبقة تحويل (ETL/Transformation):

- **تنسيقات تاريخ غير قياسية:** جامعة تستخدم Hijri، أخرى Gregorian، ثالثة الاثنين. بعضها بصيغة `YYYYMMDD`، بعضها Unix timestamp.

- **رموز المباني:** 'مبنى 5' في جامعة الملك سعود ليس له نفس التنسيق في جامعة الملك عبدالعزيز.

- **أكواد المقررات:** `CS101` vs `101-COMP-3` vs `علوم-حاسب-١٠١`. كل جامعة لها نظام ترميز مختلف تماماً.

- **تقسيم الطلاب:** بعض الجامعات تقسم حسب 'الكلية'، بعضها حسب 'البرنامج'، بعضها حسب 'الدفعة'. لا يوجد تصنيف موحد.

- **أعيرة التقدير:** يحتاج نظامك أن يفهم GPA 4.0 vs 5.0 vs نسبة مئوية — لأنك قد تحتاج هذه البيانات للتقارير.

الطبقة ٤: المزامنة والتحديثات الدورية (3-4 أسابيع)

البيانات في البانر ليست ثابتة. الجداول تتغير أسبوعياً (تعديل شعب، إلغاء محاضرات، تغيير قاعات). تحتاج:

- Webhook listeners: ليست كل الجامعات تدعمها. بعضها يعتمد على polling كل ساعة.

- استراتيجية Delta Sync: لا تسحب كل شيء كل مرة — اسحب التغييرات فقط.

- معالجة التعارضات: ماذا لو تغير الجدول بعد أن حجز الطالب؟

- آلية Fallback: ماذا لو تعطل البانر (وهذا يحدث أسبوعياً أثناء فترة التسجيل)؟

الطبقة ٥: أمان البيانات والامتثال (4-6 أسابيع)

أنت الآن تتعامل مع بيانات شخصية وأكاديمية لآلاف الطلاب. هيئة الأمن السيبراني السعودية (NCA) تفرض:

- تشفير البيانات في حالة السكون (AES-256) وأثناء النقل (TLS 1.3)

- RLS (Row Level Security) صارم — طالب يرى بياناته فقط

- سجل تدقيق كامل (Audit Log) لكل وصول للبيانات

- نسخ احتياطي مشفر واختبار استعادة كل 3 أشهر

- تقييم أمني (Security Assessment) من طرف ثالث قبل الإطلاق

- توثيق كامل لتدفق البيانات (Data Flow Diagram) تقدمه للجامعة

هذه المتطلبات ليست 'اختيارية'. بدونها، الجامعة لن توقع عقداً معك. نقطة.

الطبقة ٦: اختبار التكامل وضمان الجودة (3-5 أسابيع)

بعد بناء كل الطبقات السابقة، يأتي الاختبار. التحدي: لا يوجد 'بيئة اختبار' حقيقية للبانر. بيئة الاختبار (Test/Staging) غالباً: لا تحتوي بيانات حقيقية، ليست محدثة بنفس وتيرة الإنتاج، وقد تكون معطلة لأسابيع.

سيناريوهات الاختبار الحرجة: ماذا لو سجّل 2000 طالب في نفس الدقيقة (فترة التسجيل)؟ ماذا لو غيرت الجامعة جدولاً لـ 500 طالب دفعة واحدة؟ ماذا لو تعطل البانر تماماً — هل نظام النقل يستمر في العمل؟

الطبقة ٧: النشر والمراقبة المستمرة (2-3 أسابيع)

النشر في بيئة الإنتاج ليس 'upload وخلاص'. يتطلب:

- نافذة صيانة (Maintenance Window) — غالباً منتصف الليل

- فريق تقنية الجامعة حاضر — وهذا يتطلب تنسيقاً مسبقاً

- خطة تراجع (Rollback Plan) كاملة في حال فشل النشر

- مراقبة مباشرة (Real-time Monitoring) للـ 72 ساعة الأولى

- توثيق كامل لعملية النشر يرفع للجامعة

٣. الجدول الزمني الحقيقي — 11 شهراً

هذا هو الجدول الزمني الفعلي الذي مر به فريق رَكب — وليس تقديراً نظرياً:

لماذا يأخذ 11 شهراً وليس 3؟

الفرق بين 'التكامل النظري' و 'التكامل الحقيقي':

- **النظري:** 'نقرأ الـ API، نكتب الكود، نختبر، ننشر. 3 أشهر.'

- **الحقيقي:** 'ننتظر 3 أسابيع لمقابلة فريق التقنية. نوثق 40 endpoint غير موثق. نتعامل مع 3 تنسيقات تاريخ مختلفة. نفاوض على صلاحيات RLS. ننتظر موافقة الأمن السيبراني 6 أسابيع. نصحح 40 خطأ في الاختبار. 11 شهراً.'

٤. العلاقات الشخصية — 'الطبقة الثامنة' غير التقنية

هذا هو السر الذي لا يخبرك به أحد: 40% من نجاح تكامل البانر يعتمد على العلاقات الشخصية، وليس على المهارة التقنية.

ماذا تعني 'العلاقات' عملياً؟

- **معرفة من تتصل به:** في جامعة كبيرة، لا تعرف من هو 'المسؤول عن API البانر'. هل هو مدير تقنية المعلومات؟ ولا مختص التكامل؟ ولا مسؤول قاعدة البيانات؟ الإجابة تختلف من جامعة لأخرى.

- **بناء الثقة قبل طلب الشيء:** فريق تقنية الجامعة حذِر — جداً حذِر. قبل أن يعطوك صلاحية API، يجب أن يثقوا بك. هذه الثقة تبنى عبر اجتماعات، عروض، وقنوات غير رسمية.

- **المرونة البيروقراطية:** بعض الإجراءات في الجامعة 'إلزامية' على الورق. في الواقع، يمكن تجاوزها أو تسريعها — إذا كنت تعرف الشخص المناسب.

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

كيف تبني هذه العلاقات إذا كنت جديداً؟

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

٥. تحليل مالي — كم تكلف طبقة التكامل وحدها؟

هذه تكلفة طبقة التكامل فقط — لا تشمل المنصة الأساسية ولا التسويق ولا أي شيء آخر. أضفها إلى تكلفة بناء المنصة (1.2M) لتحصل على 1.9M ريال قبل أي مصروف آخر.

٦. مقارنة: التكامل السطحي Vs التكامل الحقيقي

معظم الداخلين الجدد يبنون 'تكاملاً سطحياً' ويظنون أنهم انتهوا. الفرق بين الاثنين هو الفرق بين نظام يبيع ونظام يموت:

الفارق شاسع. التكامل السطحي يصلح للعرض التجريبي (Demo). التكامل الحقيقي يصلح للإنتاج الحي مع آلاف الطلاب.

٧. توصيات — قبل أن تبدأ رحلة التكامل

للمنصات القائمة (إذا كنت تبني الآن):

للمستثمرين:

- أي منصة تدعي أنها 'تكاملت مع البانر' في أقل من 6 أشهر: اطلب إثباتاً.

- اسأل تحديداً: 'كم جامعة متكاملين معها فعلاً في الإنتاج الحي — وليس في البيئة التجريبية؟'

- المنصة التي تكاملت مع جامعة واحدة فقط = لم تثبت قابلية التوسع بعد.

٨. خلاصة

تكامل البانر ليس 'عقبة تقنية' يمكن حلها بذكاء برمجي. إنه مشروع متعدد التخصصات: تقني (7 طبقات)، بشري (علاقات)، قانوني (أمن سيبراني)، وتنظيمي (سياسات الجامعة). يحتاج 11 شهراً في المتوسط، ويكلف 700,000 ريال على الأقل.

هذا هو السبب الحقيقي وراء فشل 4 من أصل 6 منصات في تقريرنا السابق. ليس لأنهم 'لم يكونوا أذكياء كفاية'. بل لأنهم قللوا من تقدير هذا الحاجز تحديداً.

لا تدخل هذا السوق حتى تقرأ هذا التقرير ثلاث مرات. وإذا كنت ما زلت مصمماً — فأنت على الأقل تعرف الآن ما ينتظرك.