أفكار مشاريع تخرج في نظم المعلومات Information Systems

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

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

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

ما الذي يجعل المشروع مشروع نظم معلومات Information Systems؟

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

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

• جهة ومستخدم: قسم في الجامعة، أو منشأة صغيرة، أو خدمة حكومية لها بيانات منشورة، أو عيادة. والمهم أن تستطيع وصف من يستخدم النظام ومقابلته أو تمثيله ببيانات حقيقية.
• عملية مرسومة: العملية الحالية As-Is والعملية المقترحة To-Be، بلغة نمذجة العمليات BPMN 2.0 التي تصدرها مجموعة OMG، لأن هذا ما يميز عملك عن مشروع برمجي.
• نظام يعمل: تطبيق تبنيه، أو نظام جاهز مفتوح المصدر تهيئه وتربطه، أو لوحة مؤشرات Dashboard فوق مستودع بيانات. وتهيئة نظام ERP بشكل صحيح عمل نظم معلومات حقيقي، وقد يكون أصعب من كتابة نظام صغير من الصفر.
• قياس: رقم قبل ورقم بعد، أو اختبار قابلية الاستخدام Usability مع مستخدمين حقيقيين، أو مقارنة دقة تقرير بمصدر معروف.

وقد يتساءل البعض: هل يقبل المشرف مشروعاً لم أكتب فيه نظاماً من الصفر؟ والإجابة أن هذا يعتمد على قسمك، فبعض الأقسام تشترط نسبة من البرمجة، لذلك اسأل المشرف في أول لقاء، ولكن في أغلب الأفكار التالية جزء برمجي واضح: ربط API، أو تطبيق صغير فوق النظام الجاهز، أو خط بيانات Data Pipeline، أو برنامج تحليل، وهو جزء يكفي ليظهر مهارتك دون أن يتحول المشروع إلى مشروع هندسة برمجيات.

البكالوريوس Bachelor أم الماجستير Master: ماذا يطلب منك كل مستوى؟

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

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

أما في الماجستير فأنت باحث واحد في الغالب، والسؤال مختلف: ما المعرفة الجديدة التي أضفتها؟ وفي نظم المعلومات تحديداً هناك طريقتان معروفتان للإجابة. الأولى البحث السلوكي Behavioral Research الذي يختبر نظرية، مثل نظرية قبول التقنية واستخدامها UTAUT2 التي نشرها Venkatesh وزملاؤه في مجلة MIS Quarterly سنة 2012، على عينة في سياق جديد. والثانية بحث علم التصميم Design Science Research الذي وصفه Hevner وزملاؤه في المجلة نفسها سنة 2004، وفيه تبني أداة أو نموذجاً أو طريقة Artifact وتقيمها تقييماً صارماً، وتوضح ما الذي أضافته فوق الحلول الموجودة. وفي الحالتين لا يكفي أن «يعمل» ما بنيته، وإنما يجب أن يكون التقييم قابلاً للتكرار: مقياس معروف، وبيانات أو عينة محددة، ومقارنة مع خط أساس Baseline أو اختبار إحصائي.

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

كيف تقرأ بطاقة الفكرة Idea Card؟

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

• المشكلة Problem: جملتان تصفان ألماً حقيقياً عند جهة أو مستخدم، وليس «لا يوجد تطبيق لـ...».
• من يستخدمه Users: الأدوار التي ستقابلها أو تمثلها في التقييم.
• النطاق Scope: ما الذي يدخل في فصلين لفريق من ثلاثة إلى خمسة، وما الذي يخرج صراحة.
• التقنيات المقترحة Stack: أدوات مفتوحة المصدر في الغالب، لأنك تحتاج تشغيلها على جهازك دون ترخيص.
• البيانات Data: مصدر حقيقي فتحناه، أو طريقة معروفة لتوليد بيانات صناعية Synthetic Data عندما تكون البيانات الحقيقية حساسة.
• التقييم Evaluation: المقياس الذي سيتغير، وكيف ستقيسه.
• الصعوبة: متوسطة أو مرتفعة، بحسب ما يحتاجه من مهارات لم تدرسها.
• الخطر الذي يوقفه Risk: السبب الأكثر احتمالاً لفشل هذه الفكرة تحديداً، وكيف تتجنبه من الأسبوع الأول.
• كيف تجعله مميزاً: الإضافة الصغيرة التي تنقل المشروع من «مقبول» إلى مشروع تذكره اللجنة.

والصورة التالية تجمع الأفكار الأربع عشرة على خريطة مجالات نظم المعلومات، والرمز B للبكالوريوس وM للماجستير:

أفكار البكالوريوس Bachelor: بناء نظام وقياس أثره

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

B1: التنقيب في عمليات خدمة حكومية Government Service Process Mining

Project title: Process Mining of a Government Service

• المشكلة: كل جهة تقدم خدمة لها نظام يسجل كل خطوة في الطلب: متى استلم، ومن راجعه، ومتى اعتمد. ولكن مدير الخدمة يرى الأرقام النهائية فقط، ولا يعرف أين ينتظر الطلب، ولا كم مساراً مختلفاً يسلكه الطلب فعلاً مقارنة بالمسار المكتوب في الإجراءات.
• من يستخدمه: مالك الخدمة Process Owner، وفريق التحسين المستمر، ومدير الجودة الذي يتابع مؤشرات مستوى الخدمة SLA.
• النطاق: لفريق من ثلاثة: سجل أحداث Event Log واحد، وتحليل المسارات Variants وأماكن الانتظار ومقارنة قنوات التقديم، ولوحة تعرض النتائج. ولفريق من خمسة: أضف فحص المطابقة Conformance Checking بين العملية المكتوبة بلغة BPMN والسجل، وعملية مقترحة To-Be مع محاكاة لأثرها.
• التقنيات المقترحة: Python مع مكتبة pm4py مفتوحة المصدر للتنقيب في العمليات، وصيغة السجلات المعيارية XES، ولوحة في Metabase أو Superset.
• البيانات: السجلات الحقيقية المنشورة في مسابقات BPI Challenge التي تنظمها مجموعة IEEE للتنقيب في العمليات منذ 2011، ومنها سجلات من بلديات وبنوك ومستشفيات، وسجل خدمة الرخص الذي سنجربه في هذا المقال. وإذا وافقت جهة أو قسم في جامعتك على تصدير سجل خدمة مع إخفاء الهوية فهذا أفضل من أي سجل منشور.
• التقييم: عدد المسارات ونسبة الطلبات على المسار الرئيسي، وزمن الإنجاز Throughput Time بالوسيط والمئين 90، ونسبة الطلبات بعد المهلة، ثم مقابلة مع شخص يعمل في خدمة مشابهة ليقيم هل التوصيات قابلة للتنفيذ.
• الصعوبة: متوسطة.
• الخطر الذي يوقفه: انتظار سجل من جهة حقيقية حتى منتصف الفصل الثاني. لذلك ابدأ بالسجل المنشور، واجعل سجل الجهة إضافة إذا وصل.
• كيف تجعله مميزاً: اربط النتائج بمؤشر قياس التحول الرقمي الحكومي قياس Qiyas الذي تنشره هيئة الحكومة الرقمية، واكتب التوصيات بلغة مالك الخدمة وليس بلغة الخوارزميات.

B2: نظام تخطيط موارد لمنشأة صغيرة مع الفوترة الإلكترونية SME ERP with E-Invoicing

Project title: SME ERP System with ZATCA E-Invoicing

• المشكلة: منشأة صغيرة تعمل بجداول Excel وفواتير من برنامج محاسبة قديم، وعليها الالتزام بالفوترة الإلكترونية من هيئة الزكاة والضريبة والجمارك ZATCA، ولا تعرف هل تشتري نظاماً أم تهيئ نظاماً مفتوح المصدر.
• من يستخدمه: صاحب المنشأة، والمحاسب، وموظف المخزون، وموظف نقطة البيع.
• النطاق: ثلاث وحدات فقط: المبيعات والمخزون والمحاسبة الأساسية، ونقل بيانات المنشأة الحقيقية من الجداول، والربط ببيئة الاختبار Sandbox التي توفرها الهيئة في بوابة مطوري الفوترة الإلكترونية. والموارد البشرية والرواتب خارج النطاق، والسبب أنها وحدها مشروع كامل.
• التقنيات المقترحة: ERPNext مع تطبيق الامتثال السعودي ksa_compliance، أو Odoo Community مع وحدة l10n_sa_edi للربط مع الهيئة، وDocker للتشغيل.
• البيانات: بيانات المنشأة نفسها بعد موافقة صاحبها، وإذا لم تجد منشأة فاستخدم مجموعة Online Retail II في مستودع UCI، وهي فواتير حقيقية لمتجر على مدى سنتين، كبيانات تحويل Migration تجريبية.
• التقييم: زمن إصدار الفاتورة قبل وبعد، ودقة المخزون Inventory Accuracy بمقارنة الجرد الفعلي بالنظام، ونسبة الفواتير التي قبلتها بيئة الاختبار من أول محاولة، واستبيان قابلية الاستخدام SUS مع موظفي المنشأة.
• الصعوبة: متوسطة.
• الخطر الذي يوقفه: أن يتحول المشروع إلى «تثبيت ERPNext» فقط. لذلك اكتب من البداية جزءاً تبنيه أنت: سكربت نقل البيانات مع التحقق منها، أو تقرير مخصص، أو ربط مع متجر المنشأة.
• كيف تجعله مميزاً: وثق قرار الاختيار بين ERPNext وOdoo وشراء نظام سحابي بمعايير مكتوبة وتكلفة ملكية Total Cost of Ownership لثلاث سنوات، فهذا ما تفعله الشركات فعلاً قبل أي تطبيق.

وإذا كنت لم تتعامل مع ERP من قبل، فابدأ بمقال ما هو ERP وCRM؟ ثم تثبيت Odoo Community على سيرفرك، وتفاصيل الربط مع الهيئة في الفوترة الإلكترونية فاتورة: كيف تربط نظامك.

B3: لوحة ذكاء أعمال على بيانات الإحصاء GASTAT Business Intelligence Dashboard

Project title: Business Intelligence Dashboard on GASTAT Statistics

• المشكلة: الهيئة العامة للإحصاء GASTAT تنشر جداول كثيرة عن سوق العمل والأسعار والسكان، ولكن صاحب القرار في جهة صغيرة أو غرفة تجارية لا يستطيع أن يجيب عن سؤال بسيط مثل «كيف تغير التوظيف في قطاعي خلال ثلاث سنوات؟» دون أن يفتح عشرات الملفات.
• من يستخدمه: محلل في جهة أو غرفة تجارية، أو باحث، أو صاحب منشأة يخطط للتوسع.
• النطاق: موضوع واحد فقط، مثل سوق العمل أو الأسعار، ومستودع بيانات Data Warehouse بنموذج النجمة Star Schema، وخط بيانات ETL يحدث البيانات عند صدور نشرة جديدة، ولوحة بخمسة أسئلة قرار محددة.
• التقنيات المقترحة: PostgreSQL، وdbt أو Python لخط البيانات، وMetabase أو Superset للوحات.
• البيانات: صفحة الإحصاءات في موقع الهيئة، وقاعدة البيانات الإحصائية التي تسمح ببناء جداول وتصديرها، ومنصة البيانات المفتوحة الوطنية.
• التقييم: اختبار مهام Task-based Test مع خمسة إلى ثمانية مستخدمين: كم ثانية يحتاج المستخدم للإجابة عن كل سؤال من الأسئلة الخمسة، بالجداول الأصلية ثم باللوحة، ونسبة الإجابات الصحيحة. ومطابقة كل رقم في اللوحة مع الجدول المنشور.
• الصعوبة: متوسطة.
• الخطر الذي يوقفه: تغير شكل الجداول بين نشرة وأخرى، فيتوقف خط البيانات. لذلك خصص أسبوعين لفهم الجداول وكتابة اختبارات تتحقق من شكلها قبل التحميل.
• كيف تجعله مميزاً: اكتب قاموس بيانات Data Dictionary عربياً لكل مؤشر، مع رابط مصدره وتاريخ تحديثه، فهذا ما ينقص أغلب اللوحات.

وللمقارنة بين أدوات اللوحات راجع Metabase أم Superset أم Power BI؟، ولتصميم المستودع راجع OLAP ومستودع البيانات.

B4: نظام إحالة مرضى بمعيار FHIR FHIR Patient Referral System

Project title: FHIR-Based Patient Referral System

• المشكلة: إحالة المريض من مركز رعاية أولية إلى مستشفى ما زالت في كثير من الأماكن خطاباً أو نموذجاً يعاد إدخاله، فتضيع معلومات مثل الأدوية والحساسية، ويطول زمن الإحالة.
• من يستخدمه: طبيب المركز، ومنسق الإحالات في المستشفى، والمريض الذي يتابع حالة طلبه.
• النطاق: عملية واحدة هي الإحالة: إنشاء طلب الإحالة، وقبوله أو رفضه، وتحديد الموعد، وإرجاع ملخص للمركز. وكل مورد بيانات بمعيار HL7 FHIR مثل Patient وServiceRequest وAppointment. والسجل الطبي الكامل خارج النطاق.
• التقنيات المقترحة: سيرفر HAPI FHIR مفتوح المصدر، وواجهة ويب بسيطة، ومحرك سير عمل إذا أردت عرض العملية.
• البيانات: مرضى صناعيون من Synthea، وهو مولد مفتوح المصدر ينتج سجلات مرضى بصيغة FHIR مباشرة، فلا تحتاج بيانات مرضى حقيقيين ولا موافقة لجنة أخلاقيات.
• التقييم: نسبة طلبات الإحالة المكتملة الحقول الإلزامية قبل وبعد، وعدد الخطوات وزمن الإحالة في سيناريو مقارن، واجتياز الموارد للتحقق Validation من المعيار.
• الصعوبة: مرتفعة، لأن فهم FHIR يحتاج وقتاً.
• الخطر الذي يوقفه: محاولة بناء نظام مستشفى كامل. التزم بعملية الإحالة وحدها.
• كيف تجعله مميزاً: قارن تصميمك بما تطلبه منصة نفيس NPHIES لتبادل بيانات التأمين الصحي، واشرح ما الذي يلزم لربط الإحالة بالموافقة المسبقة من شركة التأمين.

وشرح المعيار نفسه في مقال تبادل البيانات الصحية بين الأنظمة: HL7 وFHIR.

B5: فهرس بيانات لجهة بحسب حوكمة البيانات Data Catalog for Data Governance

Project title: Data Catalog for Organizational Data Governance

• المشكلة: في أي جهة متوسطة عشرات الجداول والتقارير، ولا أحد يعرف من يملك كل جدول، ولا تصنيف بياناته، ولا هل فيه بيانات شخصية. وفي المملكة يطلب مكتب إدارة البيانات الوطنية NDMO في الهيئة السعودية للبيانات والذكاء الاصطناعي SDAIA من الجهات الحكومية تصنيف بياناتها وتحديد مالك لكل مجموعة بيانات، ويطلب نظام حماية البيانات الشخصية معرفة أين توجد البيانات الشخصية.
• من يستخدمه: مسؤول البيانات Data Steward، ومسؤول حماية البيانات الشخصية، ومحلل يبحث عن بيانات موثوقة.
• النطاق: قاعدة بيانات واحدة لنظام حقيقي أو تجريبي، وفهرس يصف كل جدول وحقل، وتصنيف كل حقل بمستويات التصنيف، وكشف آلي للحقول التي يحتمل أن تحمل بيانات شخصية مثل رقم الهوية والجوال، وسياسة وصول مكتوبة.
• التقنيات المقترحة: OpenMetadata مفتوح المصدر، أو CKAN إذا كان الهدف نشر بيانات مفتوحة، وPython لقواعد الكشف.
• البيانات: قاعدة بيانات نظام ERPNext من الفكرة B2، أو قاعدة بيانات تجريبية معروفة، مع إضافة حقول شخصية صناعية تعرف مكانها مسبقاً لتقيس بها الكشف.
• التقييم: دقة الكشف Precision والاستدعاء Recall للحقول الشخصية مقابل القائمة التي تعرفها، ونسبة الجداول التي لها مالك وتصنيف ووصف، ومراجعة من شخص يعمل في حوكمة البيانات.
• الصعوبة: متوسطة.
• الخطر الذي يوقفه: أن يتحول المشروع إلى وثيقة سياسات بلا نظام. اجعل الكشف الآلي والفهرس الذي يعمل هما الناتج الأساسي.
• كيف تجعله مميزاً: اجعل قواعد الكشف تفهم الصيغ السعودية، مثل رقم الهوية الوطنية ورقم الإقامة وأرقام الجوال المحلية، واكتب لها اختبارات، فهذه إضافة لا تجدها في الأدوات العالمية.

وللسياق القانوني راجع سياسة البيانات المفتوحة المنشورة في موقع SDAIA، ومقال حماية البيانات الشخصية PDPL للخدمات المستضافة.

B6: مدير مالية شخصية فوق المصرفية المفتوحة Open Banking Personal Finance Manager

Project title: Personal Finance Manager on Open Banking

• المشكلة: من لديه أكثر من حساب بنكي لا يرى مصروفه في مكان واحد، والمصرفية المفتوحة التي ينظمها البنك المركزي السعودي SAMA تسمح لشركات التقنية المالية المرخصة بقراءة معلومات الحساب بموافقة العميل.
• من يستخدمه: فرد يريد ميزانية شهرية، أو صاحب منشأة صغيرة جداً يخلط حسابه الشخصي بحساب عمله.
• النطاق: واجهات بنكية تجريبية Mock APIs تبنيها أنت على شكل واجهات معلومات الحساب، ثم تطبيق يعرض الحسابات ويصنف العمليات ويقترح ميزانية، مع مسار موافقة Consent Flow واضحة يستطيع المستخدم إلغاؤها. والدفع وتحويل الأموال خارج النطاق.
• التقنيات المقترحة: FastAPI أو Node لخادم الواجهات التجريبية، وOAuth 2.0 للموافقة، وتطبيق ويب للمستخدم.
• البيانات: عمليات بنكية صناعية تولدها بقواعد واضحة وتنشرها مع المشروع. لا تستخدم كشوف حسابات حقيقية لزملائك، والسبب أنها بيانات مالية شخصية لا يجوز جمعها لمشروع دراسي دون إجراءات حماية لا يملكها فريق طلابي.
• التقييم: دقة تصنيف العمليات على مجموعة مصنفة يدوياً، واختبار قابلية الاستخدام لمسار الموافقة والإلغاء، وقائمة تحقق أمنية للتوكنات ومدة صلاحيتها.
• الصعوبة: متوسطة إلى مرتفعة.
• الخطر الذي يوقفه: افتراض أنك ستتصل ببنك حقيقي. المشاركة في البيئة التجريبية التشريعية Regulatory Sandbox للبنك المركزي للشركات وليست للطلاب، لذلك قل ذلك صراحة في المقترح وابن الواجهات التجريبية من اليوم الأول.
• كيف تجعله مميزاً: اكتب تحليلاً لمسار الموافقة من منظور حماية البيانات الشخصية: ما الذي يراه المستخدم، وكم مرة يجدد الموافقة، وكيف يلغيها.

والإطار نفسه مشروح في مقال المصرفية المفتوحة Open Banking: إطار البنك المركزي والواجهات.

B7: دعم قرار سعة الخدمات في الحج والعمرة Hajj and Umrah Capacity Decision Support

Project title: Decision Support for Hajj and Umrah Service Capacity

• المشكلة: بحسب تقرير إحصاءات الحج لعام 1447هـ من الهيئة العامة للإحصاء، أدى الحج 1,707,301 حاج، منهم 1,546,655 من خارج المملكة و160,646 من داخلها، ووصل 1,485,729 من القادمين من الخارج جواً و54,429 براً و6,497 بحراً. وكل جهة تخدم الحجاج والمعتمرين، من شركة نقل إلى مقدم خدمة إعاشة، تحتاج أن تقرر قبل الموسم: كم حافلة أو وجبة أو موظفاً تحتاج في كل يوم، وما أثر تغير أعداد القادمين.
• من يستخدمه: مخطط العمليات في شركة خدمات للحجاج أو المعتمرين.
• النطاق: خدمة واحدة، مثل نقل القادمين من المطار إلى السكن، ونموذج محاكاة Simulation يأخذ أعداد القادمين بحسب منفذ الوصول وتوزيعها على الأيام، ويحسب الموارد المطلوبة وزمن الانتظار، ولوحة سيناريوهات «ماذا لو» لمتخذ القرار.
• التقنيات المقترحة: Python مع SimPy للمحاكاة بالأحداث المنفصلة Discrete-Event Simulation، وStreamlit أو Superset لعرض السيناريوهات.
• البيانات: الأرقام الإجمالية من تقارير الهيئة العامة للإحصاء لعدة مواسم، مع افتراضات مكتوبة صراحة لما لا تنشره، مثل التوزيع على الساعات.
• التقييم: التحقق من النموذج Validation بأن يعيد إنتاج الأرقام الإجمالية المنشورة، وتحليل الحساسية Sensitivity Analysis لكل افتراض، ثم مقابلة مع شخص يعمل في التخطيط لخدمة مشابهة.
• الصعوبة: مرتفعة.
• الخطر الذي يوقفه: البيانات المنشورة إجمالية، ولا توجد بيانات تفصيلية بالساعة أو بالمنفذ والفندق، فإذا بنيت المشروع على أمل الحصول عليها فقد تتوقف. ابن النموذج على الإجمالي والافتراضات، واجعل البيانات التفصيلية إن وصلت تحسيناً.
• كيف تجعله مميزاً: اجعل كل افتراض قابلاً للتعديل في الواجهة، واعرض مع كل نتيجة مدى عدم اليقين، فمتخذ القرار يثق بنموذج يقول «بين 40 و55 حافلة» أكثر من نموذج يقول «47».

B8: مساهمة مفتوحة المصدر للسوق السعودي Saudi Localization Open Source Contribution

Project title: Open Source Localization Contribution for the Saudi Market

• المشكلة: أنظمة ERP مفتوحة المصدر تحتاج تهيئة محلية: الفوترة الإلكترونية، والتقارير الضريبية، والترجمة العربية، واتجاه الكتابة من اليمين لليسار في الفواتير المطبوعة. وتطبيق ksa_compliance لنظام ERPNext مثلاً كان فيه 37 بلاغاً Issue وطلب دمج Pull Request مفتوحاً عند مراجعتنا له في نوفمبر 2026.
• من يستخدمه: المنشآت التي تستخدم المشروع، ومجتمع المطورين حوله.
• النطاق: بدلاً من نظام جديد، يكون الناتج مجموعة مساهمات مقبولة Merged Pull Requests في مشروع حقيقي: إصلاح بلاغات، وتحسين ترجمة، واختبارات، وتوثيق عربي. ويكتب الفريق تحليلاً للعملية التي يغطيها الجزء الذي ساهم فيه.
• التقنيات المقترحة: Frappe وPython لنظام ERPNext، أو Python وOWL لنظام Odoo، وGit وGitHub.
• البيانات: بلاغات المشروع نفسه وسجل مساهماته.
• التقييم: عدد المساهمات المقبولة، وزمن مراجعتها، وتغطية الاختبارات للأجزاء التي عدلتها، وتعليقات مشرفي المشروع.
• الصعوبة: متوسطة إلى مرتفعة، لأن فهم كود مشروع كبير يأخذ وقتاً.
• الخطر الذي يوقفه: أن تبقى المساهمات بلا مراجعة لأسابيع. تواصل مع المشرفين على المشروع قبل اعتماد الفكرة، واختر بلاغات عليها نشاط حديث، واتفق مع مشرفك أن المساهمة المفتوحة تحتسب حتى لو لم تدمج كلها.
• كيف تجعله مميزاً: هذا من أقوى المشاريع في السيرة الذاتية، لأن أي صاحب عمل يستطيع أن يفتح الرابط ويرى الكود والنقاش.

أفكار الماجستير Master: سؤال بحث وإضافة يمكن قياسها

في الماجستير تتغير الحقول قليلاً: بدلاً من «النطاق» نكتب سؤال البحث Research Question، وبدلاً من «كيف تجعله مميزاً» نكتب الإضافة المتوقعة Contribution. والأفكار التالية تتطلب قراءة الدراسات السابقة Related Work قبل اعتمادها، لأن الفجوة التي نصفها قد تكون أغلقت في بحث صدر حديثاً، وهذا أول ما يجب أن تتحقق منه مع مشرفك.

M1: لماذا يتبنى الناس الخدمة الحكومية الرقمية أو يتركونها؟ Digital Government Service Adoption

Project title: Adoption and Abandonment of Digital Government Services

• سؤال البحث: ما العوامل التي تفسر استمرار استخدام خدمة حكومية رقمية بعد أول استخدام، وهل يختلف أثرها بين الفئات العمرية؟
• الدراسات السابقة: نظرية UTAUT2 ونماذج الاستمرار في الاستخدام Continuance، وكثير من الدراسات طبقتها على الحكومة الإلكترونية في الخليج، لذلك تحتاج زاوية جديدة، مثل الخدمات التي تعمل بالهوية الرقمية الموحدة، أو كبار السن.
• الطريقة: استبيان بمقاييس منشورة ومترجمة ومختبرة، وعينة بحجم يحدده تحليل القوة الإحصائية Power Analysis، وتحليل بنمذجة المعادلات الهيكلية بالمربعات الصغرى الجزئية PLS-SEM عبر حزمة seminr في R.
• البيانات: بياناتك أنت، تجمعها بأداة مثل LimeSurvey على خادمك، بعد موافقة لجنة أخلاقيات البحث في جامعتك.
• التقييم: صلاحية المقاييس وثباتها، ومعنوية المسارات، والقدرة التفسيرية للنموذج، ومقارنة المجموعات Multi-Group Analysis.
• الإضافة المتوقعة: اختبار النظرية في سياق لم تختبر فيه، مع توصيات محددة لمصممي الخدمات.
• الخطر: عينة صغيرة أو منحازة من زملائك في الجامعة فقط. خطط للتوزيع خارج الجامعة من البداية.

وإجراءات الموافقة الأخلاقية مشروحة في مقال أخلاقيات البحث على البشر.

M2: التنبؤ بتأخر الطلب أثناء تنفيذه Predictive Process Monitoring

Project title: Predictive Process Monitoring for Request Delays

• سؤال البحث: هل يمكن التنبؤ مبكراً، بعد خطوتين أو ثلاث من الطلب، بأنه سيتجاوز مهلته، وما الخصائص التي تقود التنبؤ؟
• الدراسات السابقة: مجال المراقبة التنبؤية للعمليات نشط، وفيه مقارنات معيارية Benchmarks منشورة بين نماذج الشجر المعزز Gradient Boosting والشبكات التسلسلية مثل LSTM والمحولات Transformers على سجلات BPI Challenge.
• الطريقة: تحويل كل طلب جزئي Prefix إلى خصائص، وتدريب نماذج، ومقارنتها على تقسيم زمني Temporal Split وليس عشوائياً، والسبب أن التقسيم العشوائي يسرب معلومات من المستقبل.
• البيانات: سجلات BPI Challenge، ومنها سجل طلبات القروض لسنة 2012 وسجل الرخص الذي نجربه في هذا المقال، وفيه حقل المهلة case:deadline جاهزاً.
• التقييم: AUC وF1 عند كل طول للطلب الجزئي، ومدى التنبؤ المبكر Earliness، والمقارنة مع خط أساس منشور.
• الإضافة المتوقعة: قابلية التفسير Explainability لمالك الخدمة، أي ليس فقط «سيتأخر» وإنما «لماذا»، مع تقييم ذلك مع مستخدمين.
• الخطر: أن تنتهي بمقارنة نماذج لا تضيف شيئاً لما نشر. حدد الإضافة قبل التجارب.

M3: قياس جودة البيانات الحكومية المفتوحة Open Government Data Quality

Project title: Quality Assessment of Open Government Data

• سؤال البحث: ما مستوى جودة البيانات الوصفية Metadata والبيانات نفسها في مجموعات منصة البيانات المفتوحة الوطنية، وما العوامل المرتبطة بها، مثل الجهة الناشرة والقطاع وتاريخ النشر؟
• الدراسات السابقة: أطر قياس جودة بوابات البيانات المفتوحة وتقييم اكتمال البيانات الوصفية وصحة الروابط وقابلية القراءة الآلية، وقليل منها طبق على بوابات عربية.
• الطريقة: عينة عشوائية مكتوبة الطريقة من مجموعات البيانات، ومقاييس آلية مثل اكتمال الحقول وصلاحية الروابط وصيغة الملف، ومقاييس يدوية بمقيمين اثنين ومعامل اتفاق بينهما Inter-rater Agreement.
• البيانات: منصة البيانات المفتوحة الوطنية، مع سياسة البيانات المفتوحة كمرجع لما يفترض أن تحققه الجهات.
• التقييم: مؤشر جودة لكل مجموعة، وتحليل انحدار Regression للعوامل المرتبطة، وتوصيات قابلة للتطبيق.
• الإضافة المتوقعة: أداة قياس قابلة لإعادة التشغيل، ونتائج أول قياس منهجي من نوعه للمنصة إن لم يسبقك أحد.
• الخطر: المنصة تحمي نفسها من الطلبات الآلية، وقد ترفض الطلبات المتكررة من سكربت، لذلك راسل الجهة المشغلة لطلب الوصول المناسب، وصمم العينة لتكون صغيرة بما يكفي للجمع اليدوي إذا لزم.

M4: عوامل نجاح تطبيق ERP في المنشآت الصغيرة ERP Critical Success Factors in SMEs

Project title: Critical Success Factors for ERP Implementation in SMEs

• سؤال البحث: بعد إلزام المنشآت بالفوترة الإلكترونية، هل تغيرت العوامل التي تفسر نجاح تطبيق ERP في المنشآت الصغيرة والمتوسطة، مقارنة بما تقوله الدراسات قبلها؟
• الدراسات السابقة: أدبيات عوامل النجاح الحرجة لتطبيق ERP واسعة، وأغلبها عن الشركات الكبيرة أو من سياقات أخرى، والإلزام التنظيمي كمحرك للتطبيق زاوية أقل دراسة.
• الطريقة: طرق مختلطة Mixed Methods: مقابلات شبه منظمة مع أصحاب منشآت ومزودي حلول، وتحليل موضوعي Thematic Analysis، ثم استبيان يختبر ما ظهر في المقابلات.
• البيانات: مقابلاتك واستبيانك، ويمكنك الوصول إلى مزودي الحلول المعتمدين من دليل مزودي حلول الفوترة الإلكترونية في موقع الهيئة.
• التقييم: تشبع المقابلات Saturation، وثبات الترميز بين مرمزين اثنين، ثم نتائج الاستبيان.
• الإضافة المتوقعة: نموذج عوامل نجاح محدث لسياق إلزامي، وإرشادات للمنشآت.
• الخطر: صعوبة الوصول للمنشآت. ابدأ بمزودي الحلول، فكل مزود يعرف عشرات العملاء.

M5: تصميم لوحات المؤشرات العربية ودقة القرار Arabic Dashboard Design

Project title: Arabic Dashboard Design and Decision Accuracy

• سؤال البحث: هل يؤثر اتجاه اللوحة، من اليمين لليسار أو العكس، وترتيب الرسوم فيها، على سرعة المستخدم العربي ودقته في الإجابة عن أسئلة قرار؟
• الدراسات السابقة: دراسات تصميم اللوحات وأنماط تتبع العين Eye-tracking أغلبها على قراء اللغات من اليسار لليمين، والدراسات على اللوحات العربية قليلة.
• الطريقة: تجربة مضبوطة Controlled Experiment بتصميم داخل المشاركين Within-subjects، ولوحتين بنفس البيانات بتصميمين مختلفين، وترتيب متوازن Counterbalancing لمنع أثر التعلم.
• البيانات: بيانات حقيقية من الهيئة العامة للإحصاء للوحات، ونتائج المشاركين.
• التقييم: زمن الإجابة ونسبة الصحة لكل سؤال، واختبار إحصائي مناسب، واستبيان عبء المهمة NASA-TLX.
• الإضافة المتوقعة: إرشادات تصميم مبنية على دليل تجريبي للوحات العربية.
• الخطر: عدد مشاركين قليل لا يكشف فرقاً. احسب العدد المطلوب قبل التجربة.

M6: إخفاء الهوية في سجلات الأحداث Event Log Anonymization

Project title: Event Log Anonymization for Process Mining

• سؤال البحث: ما مقدار ما تفقده نتائج التنقيب في العمليات عندما نطبق طرق إخفاء الهوية على سجل أحداث فيه بيانات شخصية، وأي طريقة تحافظ على أكبر قدر من الفائدة عند نفس مستوى الحماية؟
• الدراسات السابقة: طرق مثل k-anonymity والخصوصية التفاضلية Differential Privacy طبقت على سجلات الأحداث، ولكن قياسها على متطلبات نظام حماية البيانات الشخصية في المملكة وإرشادات إخفاء الهوية المنشورة من SDAIA زاوية أقل دراسة.
• الطريقة: تطبيق عدة طرق على سجلات BPI، وقياس خطر إعادة التعرف Re-identification Risk، ثم قياس الفائدة بمقارنة المسارات وأزمنة الإنجاز وجودة النموذج المكتشف قبل الإخفاء وبعده.
• البيانات: سجلات BPI Challenge نفسها.
• التقييم: منحنى الحماية مقابل الفائدة لكل طريقة.
• الإضافة المتوقعة: دليل عملي للجهات التي تريد مشاركة سجلاتها مع باحث أو مستشار.
• الخطر: الجانب الرياضي للخصوصية التفاضلية، فاقرأ فيه قبل اعتماد الفكرة.

تجربة عملية Lab: نثبت جدوى فكرة التنقيب في العمليات Process Mining قبل اعتمادها

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

البيانات: سجل أحداث Event Log حقيقي لخدمة رخص في بلدية

اخترنا سجل «مرحلة استلام طلبات الرخص البيئية WABO» من مشروع CoSeLoG، وهو سجل حقيقي من بلدية هولندية نشر في مستودع 4TU.ResearchData للبيانات البحثية برقم DOI 10.4121/12709127، وتستخدمه مكتبة pm4py في اختباراتها، فنأخذ نسخته بصيغة CSV من مجلد بيانات الاختبار في مستودع pm4py. واخترناه لثلاثة أسباب: أنه خدمة حكومية تشبه ما ستجده في أي جهة، وأن فيه حقل المهلة case:deadline لكل طلب فنستطيع قياس الالتزام بها، وأن فيه قناة التقديم case:channel، أي هل قدم الطلب عبر الإنترنت أو في المكتب أو بالبريد. وحجمه 2.3 ميجابايت، لذلك لا نحفظه في مجلد التجربة وإنما نحمله بسكربت:

cd content/articles/grad-projects-is/lab
sh fetch_receipt.sh            # receipt.csv, 2,336,012 bytes
head -2 receipt.csv

وكل سطر في الملف حدث Event واحد، وأهم أعمدته: رقم الطلب case:concept:name، واسم الخطوة concept:name، ومن نفذها org:resource، ووقتها time:timestamp، ثم خصائص الطلب نفسه مثل القناة والمهلة وتاريخ الإغلاق case:enddate. وهذا هو الشكل الذي تحتاجه من أي جهة: رقم حالة ونشاط ووقت، وكل ما سواه إضافة.

البرنامج permit_spike.py

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

# Feasibility spike for the idea "process mining for a government service": can a team of IS students take a real
# event log of a permit service and answer the questions a service owner asks (how many paths, where is the waiting,
# how many requests break the deadline, does the channel matter)? Standard library only (Python 3.13).
#   sh fetch_receipt.sh && python permit_spike.py receipt.csv [--complete-only]
import csv, sys, statistics as st
from collections import Counter, defaultdict
from datetime import datetime

path = sys.argv[1]
complete_only = '--complete-only' in sys.argv
ts = lambda s: datetime.fromisoformat(s) if s else None      # the log mixes +01:00 and +02:00 (summer time)
days = lambda d: d.total_seconds() / 86400

cases = defaultdict(list)          # case id -> [(time, activity, resource)]
meta = {}
rows = 0
for r in csv.DictReader(open(path, encoding='utf-8')):
    rows += 1
    c = r['case:concept:name']
    cases[c].append((ts(r['time:timestamp']), r['concept:name'], r['org:resource']))
    meta[c] = {'channel': r['case:channel'], 'deadline': ts(r['case:deadline']), 'end': ts(r['case:enddate'])}
for c in cases: cases[c].sort()

log_end = max(e[-1][0] for e in cases.values())
if complete_only:                  # drop the cases the municipality had not closed when the log was cut
    cases = {c: e for c, e in cases.items() if meta[c]['end']}

acts = Counter(a for e in cases.values() for _, a, _ in e)
first = min(e[0][0] for e in cases.values())
print(f'== 1. The log{" (closed cases only)" if complete_only else ""}')
print(f'rows {rows}  cases {len(cases)}  events {sum(acts.values())}  activities {len(acts)}  resources {len({r for e in cases.values() for *_, r in e})}')
print(f'from {first:%Y-%m-%d} to {log_end:%Y-%m-%d}   cases without an end date: {sum(1 for c in cases if not meta[c]["end"])}')

print('\n== 2. Variants (the distinct paths a request takes)')
var = Counter(tuple(a for _, a, _ in e) for e in cases.values())
cum = 0
for i, (v, n) in enumerate(var.most_common(5), 1):
    cum += n
    print(f'V{i}  {n:5d} cases  {100*n/len(cases):5.1f}%  cumulative {100*cum/len(cases):5.1f}%  steps {len(v)}')
print(f'variants {len(var)}   seen only once: {sum(1 for n in var.values() if n == 1)}')
print('V1 =', ' > '.join(a.split(' ')[0] for a in var.most_common(1)[0][0]))

print('\n== 3. Where is the waiting? directly-follows pairs, median and p90 days between the two steps')
wait = defaultdict(list)
for e in cases.values():
    for (t1, a1, _), (t2, a2, _) in zip(e, e[1:]):
        wait[(a1.split(' ')[0], a2.split(' ')[0])].append(days(t2 - t1))
pairs = [(k, v) for k, v in wait.items() if len(v) >= 30]
for k, v in sorted(pairs, key=lambda kv: -sum(kv[1]))[:6]:
    q = st.quantiles(v, n=10)
    print(f'{k[0]:>8} > {k[1]:<8} n={len(v):5d}  median {st.median(v):6.2f}  p90 {q[8]:6.2f}  total {sum(v):8.0f} days')

print('\n== 4. Throughput time (first to last event), by channel')
tp = {c: days(e[-1][0] - e[0][0]) for c, e in cases.items()}
by = defaultdict(list)
for c, d in tp.items(): by[meta[c]['channel']].append(d)
for ch, v in sorted(by.items(), key=lambda kv: -len(kv[1])):
    print(f'{ch:<9} n={len(v):5d}  median {st.median(v):6.2f}  mean {st.mean(v):6.2f}  max {max(v):6.1f}')

print('\n== 5. Deadline (case:deadline) against the last event')
late = [c for c, e in cases.items() if meta[c]['deadline'] and e[-1][0] > meta[c]['deadline']]
print(f'cases with a deadline {sum(1 for c in cases if meta[c]["deadline"])}   late {len(late)} ({100*len(late)/len(cases):.1f}%)')
lv = Counter(len(cases[c]) for c in late)
print('late cases by number of steps:', dict(sorted(lv.items())))
print('late cases on the main path V1:', sum(1 for c in late if tuple(a for _, a, _ in cases[c]) == var.most_common(1)[0][0]))

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

• نجمع الأحداث لكل طلب ثم نرتبها بالوقت، لأن ترتيب الأسطر في الملف لا يضمن ترتيب الخطوات، وهذا أول خطأ يقع فيه من يحلل سجلاً لأول مرة.
• نقرأ الوقت بـ datetime.fromisoformat مع المنطقة الزمنية، لأن السجل يخلط +01:00 و+02:00 بسبب التوقيت الصيفي، ولو حذفنا المنطقة الزمنية لأخطأنا بساعة في كل طلب يعبر تغيير التوقيت.
• المسار Variant هو تسلسل أسماء الخطوات في الطلب، ونعد الطلبات لكل مسار.
• زوج «يليه مباشرة» Directly-Follows هو كل خطوتين متتاليتين في طلب واحد، والزمن بينهما هو الانتظار، وهذا أساس خرائط العمليات التي ترسمها أدوات التنقيب.
• الخيار --complete-only يحذف الطلبات التي لم تغلق عند قطع السجل، وسوف نستخدمه في تجربة «ماذا يحدث إذا».

التشغيل والمخرج Output

python permit_spike.py receipt.csv

والمخرج سوف يكون كما يلي، بعد تشغيله على Python 3.13.3:

== 1. The log
rows 8577  cases 1434  events 8577  activities 27  resources 48
from 2010-10-02 to 2012-01-23   cases without an end date: 105

== 2. Variants (the distinct paths a request takes)
V1    713 cases   49.7%  cumulative  49.7%  steps 6
V2    123 cases    8.6%  cumulative  58.3%  steps 6
V3    116 cases    8.1%  cumulative  66.4%  steps 1
V4    115 cases    8.0%  cumulative  74.4%  steps 6
V5     75 cases    5.2%  cumulative  79.6%  steps 6
variants 116   seen only once: 86
V1 = Confirmation > T02 > T04 > T05 > T06 > T10

== 3. Where is the waiting? directly-follows pairs, median and p90 days between the two steps
     T05 > T06      n=  791  median   0.00  p90   8.05  total     2422 days
Confirmation > T02      n= 1079  median   0.00  p90   0.11  total      901 days
     T04 > T05      n= 1177  median   0.00  p90   2.03  total      758 days
     T10 > T02      n=  155  median   0.15  p90   7.08  total      475 days
     T06 > T10      n= 1165  median   0.00  p90   0.01  total      440 days
     T02 > T04      n= 1119  median   0.00  p90   0.08  total      339 days

== 4. Throughput time (first to last event), by channel
Internet  n= 1250  median   0.02  mean   5.19  max  275.8
Desk      n=  109  median   0.78  mean   5.88  max  147.1
Post      n=   53  median   4.06  mean   7.53  max   45.0
e-mail    n=   21  median   0.02  mean  10.76  max  155.0
Intern    n=    1  median   0.97  mean   0.97  max    1.0

== 5. Deadline (case:deadline) against the last event
cases with a deadline 1434   late 92 (6.4%)
late cases by number of steps: {1: 21, 3: 2, 5: 4, 6: 50, 8: 3, 9: 1, 10: 6, 12: 3, 13: 1, 18: 1}
late cases on the main path V1: 36

كيف نقرأ المخرج؟ المسارات Variants أولاً

الجزء الأول يصف السجل: 8577 حدثاً في 1434 طلباً، و27 نشاطاً مختلفاً نفذها 48 موظفاً، من أكتوبر 2010 إلى يناير 2012، و105 طلبات بلا تاريخ إغلاق، أي أنها كانت مفتوحة عندما قطع السجل. وهذه الأرقام وحدها تجيب عن أول سؤال سيطرحه المشرف: هل البيانات كافية لمشروع؟ والإجابة نعم، فسجل بألف وأربعمئة طلب وسنة وثلاثة أشهر من التشغيل أكبر مما يكفي.

والجزء الثاني هو أول نتيجة لها معنى عند مالك الخدمة، والصورة التالية تبينها:

نصف الطلبات تقريباً، أي 713 طلباً، يسلك المسار الرئيسي V1 بست خطوات من تأكيد الاستلام إلى T10، وخمسة مسارات تغطي 79.6% من الطلبات، ولكن هناك 116 مساراً مختلفاً، منها 86 مساراً ظهر مرة واحدة فقط. وهذا نمط ستجده في أغلب السجلات الحقيقية، ويسميه المختصون «السباغيتي» لأن رسم كل المسارات معاً يعطيك خطوطاً متشابكة لا يفهمها أحد. والدرس العملي لمشروعك: لا تعرض على مالك الخدمة كل المسارات، وإنما اعرض المسارات التي تغطي 80% ثم اسأل عن الحالات الفردية: لماذا حدثت؟

ولاحظ المسار V3: 116 طلباً بخطوة واحدة فقط هي تأكيد الاستلام. وعند أول قراءة افترضنا أنها طلبات مفتوحة لم تكتمل، وهذا الافتراض كان خطأ كما سنرى بعد قليل.

أين ينتظر الطلب؟ زوج الخطوات Directly-Follows والمئين p90

الجزء الثالث يرتب أزواج الخطوات بمجموع زمن الانتظار في كل الطلبات، والصورة التالية ترسمه على المسار الرئيسي:

أكبر انتظار في السجل كله بين طباعة التأكيد وإرساله T05 وتقرير الحاجة لإيقاف الطلب T06: 791 مرة، ومجموعها 2422 يوماً، وعند المئين 90 تنتظر الطلبات 8.05 أيام. أي أن عشر الطلبات تقريباً ينتظر أكثر من أسبوع في هذه النقطة وحدها. ويأتي بعده زوج يرجع فيه الطلب من T10 إلى المراجعة T02 في 155 حالة، أي إعادة عمل Rework، وعند المئين 90 يستغرق 7.08 أيام. وهذان هما السؤالان اللذان تحملهما إلى مالك الخدمة في مشروعك: ماذا يحدث بعد إرسال التأكيد؟ ولماذا يعود الطلب إلى المراجعة؟

المشكلة التي ظهرت: الوسيط Median صفر في كل مكان

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

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

قناة التقديم Channel والمهلة Deadline

الجزءان الرابع والخامس يجيبان عن سؤالين يحبهما أي مالك خدمة رقمية، والصورة التالية تجمعهما:

طلبات الإنترنت، وهي 1250 من 1434، وسيطها 0.02 يوم، أي نحو نصف ساعة، أما طلبات البريد فوسيطها 4.06 أيام. وهذا رقم يدعم التحول الرقمي للخدمة، ولكن اقرأ معه المتوسط: 5.19 يوم لطلبات الإنترنت، أي أن الفرق بين الوسيط والمتوسط ضخم، والسبب أن قلة من الطلبات تبقى أسابيع، وأطولها 275.8 يوماً، فتسحب المتوسط. ولو عرضت المتوسط وحده على مالك الخدمة لظن أن كل طلب يأخذ خمسة أيام، ولو عرضت الوسيط وحده لظن أنه لا توجد مشكلة. لذلك اعرض الاثنين، واعرض الطلبات الطويلة كقائمة يمكن فتحها.

وفي المهلة: 92 طلباً، أي 6.4%، انتهت بعد مهلتها المسجلة. والمفاجأة أن 50 منها سلكت ست خطوات، و36 منها على المسار الرئيسي نفسه، أي أن التأخر ليس مشكلة الطلبات المعقدة وحدها، وإنما يحدث في المسار العادي، وهذا يعيدنا إلى الانتظار بعد T05. ولاحظ أيضاً أن 21 طلباً متأخراً فيه خطوة واحدة فقط، وهذا ما قادنا إلى المشكلة الثانية.

ماذا يحدث إذا حذفنا الطلبات المفتوحة Open Cases؟

افترضنا أن الطلبات ذات الخطوة الواحدة هي طلبات لم تغلق عند قطع السجل، فأضفنا الخيار --complete-only لحذف كل طلب بلا تاريخ إغلاق، وتوقعنا أن يختفي المسار V3:

python permit_spike.py receipt.csv --complete-only

== 1. The log (closed cases only)
rows 8577  cases 1329  events 7960  activities 26  resources 45
from 2010-10-02 to 2012-01-23   cases without an end date: 0

== 2. Variants (the distinct paths a request takes)
V1    652 cases   49.1%  cumulative  49.1%  steps 6
V2    119 cases    9.0%  cumulative  58.0%  steps 6
V3    114 cases    8.6%  cumulative  66.6%  steps 6
V4    112 cases    8.4%  cumulative  75.0%  steps 1
V5     66 cases    5.0%  cumulative  80.0%  steps 6
variants 106   seen only once: 80
V1 = Confirmation > T02 > T04 > T05 > T06 > T10

== 3. Where is the waiting? directly-follows pairs, median and p90 days between the two steps
     T05 > T06      n=  725  median   0.00  p90   9.98  total     2345 days
Confirmation > T02      n=  989  median   0.00  p90   0.10  total      821 days
     T04 > T05      n= 1093  median   0.00  p90   2.15  total      751 days
     T10 > T02      n=  151  median   0.17  p90   7.16  total      475 days
     T06 > T10      n= 1083  median   0.00  p90   0.01  total      403 days
     T02 > T04      n= 1026  median   0.00  p90   0.09  total      319 days

== 4. Throughput time (first to last event), by channel
Internet  n= 1148  median   0.02  mean   5.32  max  275.8
Desk      n=  107  median   0.76  mean   5.89  max  147.1
Post      n=   52  median   4.14  mean   7.68  max   45.0
e-mail    n=   21  median   0.02  mean  10.76  max  155.0
Intern    n=    1  median   0.97  mean   0.97  max    1.0

== 5. Deadline (case:deadline) against the last event
cases with a deadline 1329   late 88 (6.6%)
late cases by number of steps: {1: 21, 3: 2, 5: 4, 6: 47, 8: 3, 9: 1, 10: 6, 12: 2, 13: 1, 18: 1}
late cases on the main path V1: 33

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

• حذف الخيار 105 طلبات فقط، وبقي 1329 طلباً، ونسبة المسار الرئيسي لم تتغير تقريباً: 49.1% بدلاً من 49.7%.
• المسار ذو الخطوة الواحدة لم يختف، وإنما نزل من V3 إلى V4 ببقاء 112 طلباً من 116، أي أن هذه الطلبات مغلقة فعلاً بعد خطوة واحدة. وافتراضنا الأول كان خطأ: هذه طلبات أغلقت بعد تأكيد الاستلام مباشرة، وربما سحبها أصحابها أو رفضت، والسجل لا يقول السبب.
• نسبة المتأخر ارتفعت قليلاً إلى 6.6%، لأن المقام صغر، وبقي 21 طلباً متأخراً بخطوة واحدة.

وهذا بالضبط ما تريده من تجربة الجدوى: اكتشفت في ساعة أن هناك فئة من الطلبات تغلق بعد خطوة واحدة دون سبب مسجل، وأن بعضها يغلق بعد المهلة. وهذا سؤال حقيقي تحمله إلى الجهة، وقد يكون محور مشروعك كله: لماذا تغلق 8% من الطلبات بعد الاستلام مباشرة، وكم منها كان يمكن منعه بتحقق أفضل في نموذج التقديم؟

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

الأفكار المستهلكة Overused Ideas: كيف تحول واحدة منها إلى مشروع حقيقي؟

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

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

1. اجمع طلبات الطلاب الحقيقية لفصل كامل من البريد أو نظام التذاكر في القسم، بعد موافقة القسم وحذف الأسماء.
2. صنفها: كم منها سؤال معلومة، وكم طلب إجراء مثل تأجيل اختبار أو معادلة مقرر، وكم شكوى.
3. ارسم عملية كل طلب إجراء شائع بلغة BPMN، وستجد أن أغلب الوقت يضيع في الذهاب والعودة لنقص المعلومات.
4. ابن كتالوج خدمات Service Catalog فيه لكل خدمة نموذج بالحقول المطلوبة، ثم أضف المساعد اللغوي إن أردت، ولكن كواجهة للكتالوج وليس كبديل عنه.
5. قس نسبة الطلبات التي انتهت دون تدخل موظف Deflection Rate، وعدد مرات الذهاب والعودة لكل طلب، قبل الكتالوج وبعده.

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

جدول مقارنة الأفكار Comparison Table

الجدول التالي يجمع الأفكار الأربع عشرة، والعمود الأخير هو أهم ما ستتعلمه من كل فكرة، أي ما ستكتبه في سيرتك الذاتية:

في الجدول أعلاه لاحظ التالي:

• الأفكار التي بياناتها «عالية» هي الأقل خطراً، لأن البيانات أول سبب لتوقف المشاريع، لذلك إذا كان فريقك يعمل لأول مرة على مشروع بهذا الحجم فابدأ منها.
• الأفكار التي تجمع بياناتها بنفسك، مثل M1 وM4، تحتاج موافقة لجنة الأخلاقيات قبل أي جمع، وهذه الموافقة قد تأخذ أسابيع، فاحسبها في الخطة.
• B7 وB6 ببيانات إجمالية أو صناعية، وهذا مقبول ما دمت تكتب الافتراضات وتختبر حساسية النتائج لها.

أخطاء شائعة عند اختيار مشروع نظم المعلومات Common Mistakes

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

قائمة تحقق Checklist قبل أن تقدم أفكارك الثلاث

1. لكل فكرة جهة أو مستخدم تستطيع وصفه، وعملية تستطيع رسمها.
2. لكل فكرة مصدر بيانات فتحته بنفسك وحملت منه ملفاً، أو طريقة معروفة لتوليد بيانات صناعية.
3. جربت أبسط حساب على البيانات في ساعة أو ساعتين، مثل التجربة في هذا المقال، وخرجت منه بنتيجة لها معنى.
4. كتبت المقياس الذي سيتغير، وكيف ستقيسه قبل وبعد.
5. كتبت ما يدخل في النطاق وما يخرج منه صراحة، وتأكدت أنه يتسع في نحو 20 أسبوع عمل فعلي لفريقك.
6. كتبت الخطر الأكبر لكل فكرة وكيف ستتجنبه في الأسبوع الأول.
7. عرفت هل تحتاج موافقة لجنة أخلاقيات، وأضفت مدتها إلى الخطة.
8. سألت المشرف عن نسبة البرمجة التي يشترطها القسم.
9. لطالب الماجستير: قرأت عشرة أبحاث حديثة على الأقل في الموضوع، وكتبت الفجوة في جملة واحدة.
10. لكل فكرة سطر واحد يصلح أن يكتب في السيرة الذاتية بعد التخرج.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• مشروع نظم المعلومات يبدأ من عملية أو قرار في جهة حقيقية وينتهي برقم يتغير، والنظام الذي تبنيه أو تهيئه وسيلة لذلك.
• البكالوريوس يسأل: هل يستطيع فريقك بناء نظام يخدم عملية وقياس أثره؟ والماجستير يسأل: ما المعرفة الجديدة التي أضفتها، وهل يستطيع غيرك تكرار تقييمك؟
• أكثر الأفكار أماناً هي التي بياناتها منشورة: سجلات BPI للتنقيب في العمليات، وبيانات الهيئة العامة للإحصاء للوحات، وSynthea للأنظمة الصحية.
• في التجربة أثبتنا جدوى فكرة التنقيب في العمليات في ساعة: 116 مساراً في 1434 طلباً، وأكبر انتظار بعد إرسال التأكيد بـ 8.05 أيام عند المئين 90، و6.4% من الطلبات بعد المهلة، واكتشفنا أن الوسيط مضلل في سجل يسجل فيه الموظفون الخطوات دفعة واحدة.
• الفكرة المستهلكة لا ترفض بسبب موضوعها، وإنما لغياب العملية والمستخدم والقياس، وأي واحدة منها تتحول إلى مشروع حقيقي بهذه الأسئلة الثلاثة.

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

دليلتخصص نظم المعلومات Information Systems بين التقنية والإدارةماذا يقول نموذج الكفاءات IS2020 عن تخصصك، وكيف تدرسه خمس خطط سعودية، ولماذا تجد فيها البرمجة والمحاسبة معاً، وما الذي ينقصها في إدارة المشاريع، ومن أين تكمله.دليلأي تخصص تقني تختار؟ ما تدرسه فعلاً وأين تعمل بعدهماذا تدرس فعلاً في كل تخصص تقني بحسب الخطط الدراسية السعودية، وأين يعمل خريجوه، ومتى يهم اسم التخصص ومتى تهم المهارة.دليلما هو ERP وCRM؟ ومتى تحتاج شركتك إليهماما الذي تفعله أنظمة ERP وCRM، ومتى تحتاجها شركتك فعلاً، ولماذا يتعثر تطبيقها، وما علاقتها بالفاتورة الإلكترونية في المملكة.دليلOdoo Community: نظام ERP لشركتك على سيرفرككيف تثبت Odoo Community على سيرفرك، وتمر بدورة بيع كاملة حتى الدفع، وترسل فاتورة إلى بيئة الاختبار في منصة فاتورة.دليلالفوترة الإلكترونية فاتورة ZATCA: كيف تربط نظامكبنينا فاتورة مبسطة بصيغة XML ورمز QR بلغة Python، وتحققنا منهما بأداة الهيئة، وحسبنا الهاش بأنفسنا وجربنا الأخطاء الشائعة.دليلMetabase أم Superset أم Power BI؟ أداة التقارير لفريقككيف تختار أداة التقارير لفريقك بحسب الرخصة والتكلفة ومكان بياناتك ودعم العربية وتقييد الصفوف.دليلOLAP ومستودع البيانات: تقارير لا تبطئ تطبيقككيف تنقل تقاريرك من قاعدة التطبيق إلى مستودع بيانات بمخطط النجمة، فتسرع التقارير وتبقى أرقام السنوات الماضية ثابتة.دليلتبادل البيانات الصحية بين الأنظمة: HL7 وFHIRكيف تنتقل نتائج المختبر وبيانات المريض بين أنظمة المستشفى برسائل HL7 وواجهات FHIR، وكيف تبني ذلك وتختبره بنفسك.دليلالمصرفية المفتوحة Open Banking: إطار البنك المركزي والواجهاتما تتيحه المصرفية المفتوحة في المملكة وما تفرضه لائحتها، والموافقة من الطلب إلى الحذف، مع مختبر لتطبيق يقرأ بموافقة العميل فقط.دليلمتطلبات الحكومة الرقمية في المملكة ومؤشر قياس Qiyasخريطة وثائق هيئة الحكومة الرقمية الملزمة والاسترشادية بأرقامها وتواريخها، وكيف يقيس مؤشر قياس التزام الجهات.دليلتثبيت LimeSurvey للاستبيانات على خادمككيف تشغل LimeSurvey على سيرفرك وتنشئ استبيانات بالعربية، فتبقى إجابات المشاركين عندك لا عند خدمة خارجية.دليلأخلاقيات البحث على البشر: من لجنة IRB إلى حماية البياناتما الذي يطلبه النظام السعودي قبل أن تجمع بيانات من البشر، وكيف تحصل على موافقة اللجنة المحلية وتحمي البيانات الشخصية.

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

• نوفمبر 2026: كتابة المقال، والتحقق من مصادر البيانات لكل فكرة، وتشغيل permit_spike.py على Python 3.13.3 مع سجل WABO receipt phase، وقراءة تقرير إحصاءات الحج 1447هـ من الهيئة العامة للإحصاء.