الدليل المؤسسي لحوكمة وسياسات وإجراءات إدارة تقنية المعلومات

الأهداف الإستراتيجية 2026–2029

• رفع معدل توافر الأنظمة الحرجة (ERP/POS/الشبكة) إلى 99.9% بحلول 2027.
• إتمام برنامج تأهيل الكوادر الداخلية والانتقال التدريجي للهيكل التنظيمي المؤسسي (CTO + 6 أقسام) بحلول 2029، دون توظيف خارجي كخطوة أولى.
• تحقيق النضج الكامل لضوابط الأمن السيبراني (ECC وISO 27001) وإنشاء وحدة أمن سيبراني مستقلة بحلول 2027.
• خفض الاعتماد على العمليات اليدوية بنسبة 40% عبر الأتمتة وتحسين سير العمليات بحلول 2028.
• استكمال الانتقال إلى بنية هجينة مستقرة (خوادم محلية + Contabo السحابية) مع خطة تعافٍ من الكوارث مختبَرة بالكامل بحلول 2027.
• بناء قدرات تحليل البيانات والذكاء الاصطناعي دعمًا لاتخاذ القرار التنفيذي بحلول 2029.

المبادرات والمشاريع الرئيسية

تُموَّل هذه المبادرات من ميزانية تقنية المعلومات السنوية (CAPEX/OPEX) الموضحة في نموذج ميزانية تقنية المعلومات بالملاحق، مع مراجعة سنوية لتوزيع الإنفاق بين المبادرات وفق الأولوية والقيمة المتوقعة.

مؤشرات نجاح الخطة الإستراتيجية

• نسبة إنجاز المبادرات الإستراتيجية ضمن الجدول الزمني المعتمد: ≥ 80% سنويًا.
• معدل توافر الأنظمة الحرجة: ≥ 99.9% بحلول 2027.
• عدد الأدوار المؤسسية المستقبلية المُشغَّلة من كوادر داخلية مؤهَّلة: 100% (صفر توظيف خارجي للتوسع).
• العائد على الاستثمار التقني (ROI) لكل مبادرة كبرى: يُقاس عبر مقارنة القيمة المتحققة (توفير تكلفة، خفض توقف، تحسين إنتاجية) بتكلفة التنفيذ، وتُوثَّق النتيجة في تقرير المراجعة ربع السنوية.

الجدول الزمني العام (Roadmap)

البنية التحتية المحلية (On-Premise)

• خوادم فعلية وافتراضية (Hyper-V) داخل مركز البيانات المحلي للشركة، تستضيف نسخة الإنتاج لنظام ERP (Business Central) وقواعد بيانات SQL Server الرئيسية.
• خادم Active Directory وDNS المحلي لإدارة الهوية والوصول لجميع الأجهزة والمستخدمين.
• أنظمة النسخ الاحتياطي المحلية (Local Backup) للبيانات الحرجة، مع نسخة إضافية سحابية للحماية من الكوارث (Offsite Backup) وفق سياسة النسخ الاحتياطي بالمجلد السابع عشر.
• شبكة محلية (LAN) وأجهزة شبكات (Switches/Firewall/Access Points) تربط جميع الأجهزة والخوادم داخل المقر الرئيسي.

الحوسبة السحابية — Contabo

• خوادم VPS سحابية مستضافة لدى مزود الخدمة Contabo، تُستخدَم لاستضافة تطبيقات ومواقع وخدمات مختارة (مثل المواقع الإلكترونية والتطبيقات الرقمية للمجموعة).
• يخضع اختيار الخدمات المرحَّلة لـContabo لتقييم يوازن بين التكلفة والأداء ومتطلبات إقامة البيانات (Data Residency) وفق سياسة الحوسبة السحابية بالمجلد السادس عشر.
• تُدار بيانات اعتماد الوصول لخوادم Contabo عبر 1Password، وتخضع لنفس ضوابط المصادقة متعددة العوامل والمراجعة الدورية المطبَّقة على أي مورد سحابي خارجي.
• يُحتفَظ بنسخة احتياطية مستقلة عن بيئة Contabo نفسها (لا تعتمد فقط على أدوات النسخ الاحتياطي الخاصة بالمزود) اتساقًا مع سياسة منع الارتهان للموردين في المجلد العشرين.

الفروع والاتصال (Branches & Connectivity)

• تتصل جميع الفروع بالمقر الرئيسي عبر شبكات VPN مؤمَّنة (Site-to-Site) لضمان وصول آمن لأنظمة ERP ونقاط البيع.
• تعتمد كل فرع على خط إنترنت أساسي من مزود معتمد، مع دراسة إمكانية خط احتياطي (Failover) للفروع الحرجة وفق سياسة إدارة الموردين.
• تُدار أجهزة نقاط البيع والموازين والطابعات الحرارية في كل فرع ضمن VLAN مخصص معزول عن بقية حركة الشبكة.

الأنظمة والتراخيص والبرامج والاشتراكات الحالية

• الأنظمة الأساسية: Microsoft Dynamics 365 Business Central (ERP)، LS Central/LS Retail (تجزئة)، أنظمة نقاط البيع (POS)، Data Director للتكامل والتقارير.
• منصات التطوير والتحليلات: Power BI للتقارير، Visual Studio وGit لإدارة الأكواد، React/Vite/TypeScript لتطوير المواقع والتطبيقات.
• الاشتراكات والتراخيص السحابية: Microsoft 365 (بريد إلكتروني وتطبيقات مكتبية)، Adobe، 1Password (إدارة كلمات المرور)، بالإضافة لاشتراكات استضافة Contabo.
• أنظمة الأمن والشبكات: حلول جدار الحماية، أنظمة المراقبة الأمنية (SIEM/EDR حسب المتاح)، وأنظمة كاميرات المراقبة (CCTV) في جميع الفروع.
• شريك تنفيذ ودعم ERP خارجي (كما هو موضح بالتفصيل في المجلد الثالث عشر) يقدم الدعم والتطوير لنظام Business Central وLS Retail.
• يُحتفَظ بسجل مركزي كامل لجميع الأنظمة والتراخيص والاشتراكات (البرنامج، المورّد، تاريخ التجديد، عدد المستخدمين المرخَّصين، التكلفة السنوية) يخضع للمراجعة الدورية ضمن إدارة التراخيص بالمجلد السابع.

1. الرؤية والرسالة والأهداف الإستراتيجية

• الرؤية: أن تكون إدارة تقنية المعلومات الشريك الإستراتيجي الموثوق الذي يمكّن جميع شركات المجموعة من النمو والتميز التشغيلي عبر تقنية آمنة وموثوقة ومبتكرة.
• الرسالة: تقديم خدمات وحلول تقنية مستقرة وآمنة وفعالة من حيث التكلفة، تدعم استمرارية الأعمال وتحقق رضا المستفيدين الداخليين والخارجيين.
• الأهداف الإستراتيجية الخمسية تُشتق سنويًا إلى خطة تشغيلية معتمدة من مدير تقنية المعلومات، وتُراجع أداءً وتقدمًا كل ربع سنة أمام الإدارة التنفيذية.
• تُصاغ الأهداف وفق معايير SMART (محددة، قابلة للقياس، قابلة للتحقيق، ذات صلة، ومحددة زمنيًا) وتُربط بمؤشرات أداء رئيسية (KPIs) واضحة.

2. الهيكل التنظيمي والوظيفي والصلاحيات

• يتبع الهيكل التنظيمي لإدارة تقنية المعلومات نموذج «إدارة واحدة – فريقان متكاملان»: فريق العمليات والخدمات التقنية، وفريق الأنظمة المؤسسية والحلول الرقمية، تحت إشراف مدير تقنية المعلومات (تفاصيل الهيكل والأوصاف الوظيفية في القسم المخصص لاحقًا في هذا الدليل).
• لكل وظيفة وصف وظيفي معتمد يتضمن: الهدف من الوظيفة، خط الإشراف والتبعية، المهام والمسؤوليات الرئيسية، ومجالات التعاون مع باقي الفريق.
• تُدار الصلاحيات وفق مبدأ «أقل صلاحية ممكنة» (Least Privilege) و«الفصل بين المهام» (Segregation of Duties) لمنع تضارب الصلاحيات الحساسة.
• تُراجع الصلاحيات الممنوحة لكل وظيفة كل ستة أشهر على الأقل، وعند أي تغيير وظيفي (ترقية، نقل، إنهاء خدمة).

3. مصفوفة RACI ولجنة تقنية المعلومات

• تُعتمد مصفوفة RACI (مسؤول Responsible، معتمد Accountable، يُستشار Consulted، يُبلَّغ Informed) لكل عملية رئيسية موثقة في هذا الدليل، ونموذجها في الملاحق.
• تُشكَّل لجنة تقنية المعلومات (IT Steering Committee) برئاسة مدير تقنية المعلومات وعضوية ممثلين عن الإدارات الرئيسية، تجتمع شهريًا لمراجعة المشاريع والمخاطر والأداء.
• تختص اللجنة باعتماد المشاريع الكبرى، ومراجعة طلبات التغيير عالية الأثر، والموافقة على الاستثناءات من السياسات المعتمدة.

4. إدارة المخاطر والامتثال والتدقيق الداخلي

• يُطبَّق إطار إدارة مخاطر تقني موحّد (Identify – Assess – Treat – Monitor) وفق منهجية متوافقة مع ISO 27001 وNIST، ويُحدَّث سجل المخاطر (Risk Register) فصليًا.
• تُصنَّف المخاطر حسب الاحتمالية والأثر إلى (منخفضة/متوسطة/عالية/حرجة)، وتُصعَّد المخاطر الحرجة فورًا للجنة تقنية المعلومات.
• يخضع الامتثال لمعايير ISO 27001 وISO 20000 ومتطلبات الجهات التنظيمية ذات العلاقة للمراجعة السنوية، مع خطة معالجة للفجوات (Gap Remediation Plan).
• يُجرى تدقيق داخلي دوري (نصف سنوي على الأقل) على الضوابط التقنية والأمنية من جهة مستقلة عن فريق التشغيل، وتُرفع نتائجه للإدارة التنفيذية.

5. مؤشرات الأداء وإدارة الجودة

• تُعتمد لوحة مؤشرات أداء رئيسية (KPI Dashboard) تغطي: توافر الخدمات، زمن حل الحوادث، رضا المستخدمين، الالتزام بـ SLA، ونسبة إنجاز المشاريع.
• تُراجع مؤشرات الأداء شهريًا من قِبل مديري الفرق، وربع سنويًا من قِبل مدير تقنية المعلومات أمام اللجنة التنفيذية.
• تُطبَّق دورة تحسين مستمر (Plan-Do-Check-Act) على العمليات الرئيسية بناءً على نتائج المؤشرات والدروس المستفادة من الحوادث والمشاريع.

6. إدارة المعرفة والوثائق والسجلات

• تُدار قاعدة معرفة مركزية (Knowledge Base) تضم الأدلة التشغيلية (Runbooks) والحلول المتكررة وأدلة المستخدم، ويكون تحديثها مسؤولية مشتركة لجميع أعضاء الفريق.
• تخضع جميع الوثائق الرسمية لدورة حياة موثقة: إعداد – مراجعة – اعتماد – نشر – مراجعة دورية – أرشفة، مع ترقيم إصدارات واضح (Version Control).
• تُحفظ السجلات التشغيلية (سجلات التذاكر، التغييرات، الحوادث، النسخ الاحتياطي) وفق سياسة احتفاظ لا تقل عن ثلاث سنوات ما لم تتطلب المتطلبات التنظيمية مدة أطول.

7. إدارة الميزانية وخارطة الطريق التقنية والتحول الرقمي

• تُعد ميزانية تقنية المعلومات سنويًا وتُقسَّم إلى بنود تشغيلية (OPEX) ورأسمالية (CAPEX)، وتُراجع فعليًا مقابل المخطط كل شهر.
• تُبنى خارطة الطريق التقنية لثلاث سنوات وتُحدَّث سنويًا، وتربط كل مبادرة بهدف إستراتيجي وميزانية ومالك مشروع ومؤشر نجاح.
• تُدار مبادرات التحول الرقمي (أتمتة العمليات، تحسين تجربة العميل الرقمية، الذكاء الاصطناعي) ضمن محفظة مشاريع موحدة تخضع لحوكمة مكتب إدارة المشاريع (PMO).

8. الامتثال النظامي المحلي (الهيئات التنظيمية السعودية)

• ضوابط الأمن السيبراني الأساسية (ECC-1:2018) الصادرة عن الهيئة الوطنية للأمن السيبراني (NCA): تخضع إدارة تقنية المعلومات لتقييم ذاتي سنوي لمدى التزامها بالضوابط الأربعة (الحوكمة، تعزيز الأمن السيبراني، الصمود، الأطراف الثالثة والحوسبة السحابية)، وتُرفع نتائج التقييم للإدارة التنفيذية مع خطة معالجة للفجوات.
• نظام حماية البيانات الشخصية (PDPL) ولائحته التنفيذية الصادرة عن الهيئة السعودية لتنظيم البيانات (SDAIA): تُصنَّف بيانات العملاء والموظفين الشخصية، ويُطبَّق مبدأ الحد الأدنى من جمع البيانات، ويُعيَّن مسؤول حماية بيانات (Data Protection Focal Point) داخل الإدارة.
• في حال وجود أي تعاملات مالية أو ربط مع أنظمة الدفع البنكية، تُراعى المتطلبات ذات الصلة الصادرة عن البنك المركزي السعودي (ساما) الخاصة بأمن المعلومات والمدفوعات الإلكترونية.
• تُحدَّث مصفوفة الامتثال (Compliance Mapping) التي تربط كل سياسة في هذا الدليل بالمعيار أو الضابط التنظيمي المقابل (ECC / ISO 27001 / PDPL) في الملاحق، وتُراجَع سنويًا لضمان مواكبة أي تحديثات تصدرها الجهات التنظيمية.
• يُعيَّن مسؤول امتثال (Compliance Owner) داخل إدارة تقنية المعلومات مهمته متابعة أي تحديثات تنظيمية صادرة عن NCA أو SDAIA أو الجهات ذات العلاقة، وتقييم أثرها على سياسات الدليل خلال 30 يومًا من صدورها.

9. تقويم الاجتماعات الدوري (Meetings Cadence)

10. بيان شهية المخاطر التقنية (IT Risk Appetite Statement)

• لا تقبل الشركة أي مخاطرة قد تؤدي لتوقف الأنظمة الحرجة (ERP، نقاط البيع) لأكثر من الحدود الزمنية المعتمدة في أهداف RTO/RPO بالمجلد السابع عشر، ولا أي مخاطرة أمنية قد تعرّض بيانات العملاء الشخصية للتسرب.
• تقبل الشركة درجة معتدلة من المخاطرة عند تبني تقنيات وحلول جديدة (كأدوات الذكاء الاصطناعي) شريطة المرور بتقييم مخاطر مسبق موثق واعتماد لجنة تقنية المعلومات.
• يُراجَع بيان شهية المخاطر سنويًا بالتوازي مع مراجعة سجل المخاطر المؤسسي الموضح في المجلد الأول.

11. مصفوفة الفصل بين المهام (Segregation of Duties)

• لا يجوز لنفس الشخص أن يكون مسؤولًا عن تطوير تغيير برمجي واعتماده ونشره في بيئة الإنتاج في آن واحد؛ يجب أن تتم المراجعة والاعتماد من طرف مستقل عن منفّذ التغيير (وفق إجراء مراجعة الكود في المجلد الرابع عشر وإدارة التغيير في المجلد التاسع عشر).
• لا يجوز لنفس الشخص إنشاء حساب مستخدم واعتماد صلاحياته المرتفعة في آن واحد دون مراجعة ثانية (Four-Eyes Principle) للحسابات الإدارية الحساسة.
• لا يجوز لمن ينفذ عملية نسخ احتياطي أن يكون هو نفسه من يعتمد وحده نتائج اختبار الاستعادة دون مراجعة مستقلة من زميل آخر.

12. الاسترشاد بمعايير دولية إضافية (ISO 22301 وISO 9001)

• يُسترشَد بمعيار ISO 22301 (إدارة استمرارية الأعمال) عند بناء وتطوير خطط التعافي من الكوارث واستمرارية الأعمال الموضحة في المجلد السابع عشر.
• يُسترشَد بمبادئ معيار ISO 9001 (إدارة الجودة) في تصميم دورة تحسين الجودة المستمر لعمليات إدارة تقنية المعلومات الموضحة في المجلد الأول.

13. عملية استثناءات السياسات (Policy Exception & Waiver Process)

• في حال تعذّر على أي إدارة أو فريق الالتزام الكامل ببند من بنود هذا الدليل لسبب عملي أو تقني مبرَّر، يُقدَّم طلب استثناء رسمي موثَّق يوضح: البند المطلوب الاستثناء منه، السبب، المخاطر المترتبة، والإجراءات التعويضية المقترحة للحد من هذه المخاطر.
• يخضع طلب الاستثناء لمراجعة واعتماد مدير تقنية المعلومات أو لجنة تقنية المعلومات (للاستثناءات عالية الأثر)، ولا يُعتَدّ بأي استثناء غير موثَّق أو غير معتمد رسميًا.
• تُحدَّد لكل استثناء معتمد مدة صلاحية زمنية محددة (لا تتجاوز سنة واحدة كحد أقصى)، وتُراجَع الاستثناءات القائمة عند انتهاء مدتها لتحديد ما إذا كانت الحاجة إليها ما زالت قائمة أو يجب إنهاؤها.
• يُحتفَظ بسجل مركزي لجميع استثناءات السياسات المعتمدة (Exception Register) يراجَع ضمن اجتماعات لجنة تقنية المعلومات ربع السنوية.

القيمة المضافة لمدير تقنية المعلومات

التوظيف والتطوير المهني

• تُشتق متطلبات التوظيف من الأوصاف الوظيفية المعتمدة، وتخضع جميع التعيينات التقنية لمقابلة فنية يشارك فيها مدير الفريق المعني.
• تُوضع خطة تدريب سنوية فردية لكل موظف تشمل الشهادات المهنية ذات الصلة (مثل CCNA، ITIL، Microsoft Certified، Security+) بحد أدنى 20 ساعة تدريب سنويًا.
• يخضع كل موظف لتقييم أداء رسمي مرتين سنويًا وفق معايير محددة مسبقًا مرتبطة بالوصف الوظيفي ومؤشرات الأداء.
• توضع خطة إحلال وظيفي (Succession Planning) للوظائف الحرجة والإشرافية لضمان استمرارية الأعمال عند الشغور.

قواعد السلوك والعمل

• يلتزم جميع الموظفين بسياسة سرية المعلومات وعدم الإفصاح عن بيانات الشركة أو العملاء لأي جهة غير مخوّلة، ويوقّع كل موظف تعهد سرية عند التعيين.
• تُنظَّم سياسة العمل عن بُعد بحيث تتطلب موافقة المدير المباشر واستخدام اتصال VPN مشفّر وجهاز معتمد من الشركة.
• يُنظَّم العمل خارج الدوام الرسمي والمناوبات (On-call) بجدول شهري معتمد، مع تعويض وفق سياسة الموارد البشرية.
• تُوثَّق جميع الاجتماعات الرسمية بمحضر يتضمن القرارات والمهام والمسؤول والموعد النهائي، ويُرفع خلال 48 ساعة من انعقاد الاجتماع.

استخدام الذكاء الاصطناعي (ChatGPT/Copilot)

• يُسمح باستخدام أدوات الذكاء الاصطناعي التوليدي (مثل ChatGPT وCopilot) للأغراض الإنتاجية (كتابة الكود، التوثيق، التلخيص) وفق النسخ المؤسسية المعتمدة فقط.
• يُحظر إدخال أي بيانات مصنّفة كسرية أو حساسة أو بيانات عملاء أو أكواد مصدرية خاصة بأنظمة الإنتاج في أدوات الذكاء الاصطناعي العامة غير المرخصة مؤسسيًا.
• تخضع جميع المخرجات الناتجة عن أدوات الذكاء الاصطناعي (كود، تقارير، محتوى) لمراجعة بشرية قبل الاعتماد أو النشر أو التطبيق في بيئة الإنتاج.

الحضور والانصراف وساعات العمل

• أيام العمل الرسمية لإدارة تقنية المعلومات من الأحد إلى الخميس، بحضور فعلي في المقر/الفرع المخصص وفق الجدول المعتمد من الإدارة.
• تُحدَّد ساعات الدوام الرسمية لإدارة تقنية المعلومات من الساعة 8:00 صباحًا حتى الساعة 5:00 مساءً، من الأحد إلى الخميس (بواقع 8 ساعات عمل فعلية تشمل فترة راحة)، ما لم يصدر تعميم رسمي من الموارد البشرية بخلاف ذلك.
• يُعدّ التأخر عن موعد الحضور المعتمد دون عذر مقبول أو إشعار مسبق للمدير المباشر مخالفة تخضع لسياسة الانضباط الموضحة لاحقًا في هذا المجلد.
• يُلزَم كل موظف بإشعار مديره المباشر بأي غياب أو تأخر قبل بداية الدوام كلما أمكن ذلك، وتوثيق سبب الغياب وفق سياسة الموارد البشرية.
• يقع المقر الرئيسي وجميع مواقع عمل إدارة تقنية المعلومات الحالية داخل محافظة الإحساء؛ وبناءً عليه فإن جميع بنود هذا الدليل (الدعم الميداني، المناوبة، زمن الاستجابة الميداني) مبنية على افتراض تغطية جغرافية موحدة داخل النطاق الجغرافي للمحافظة. في حال استحداث مواقع أو فروع خارج الإحساء مستقبلًا، تُراجَع بنود زمن الاستجابة الميداني ومصفوفة المناوبة لتعكس المسافات الجغرافية الجديدة.

نظام التناوب الاحتياطي خلال عطلة نهاية الأسبوع

• عطلة نهاية الأسبوع (الجمعة والسبت) غير يوم عمل رسمي، إلا أن إدارة تقنية المعلومات تحافظ على نظام تناوب احتياطي بين أعضاء الفريقين لمعالجة الأعطال والحوادث الحرجة العاجلة فقط التي تهدد استمرارية الأعمال (مثل توقف كامل للأنظمة الحرجة، حادثة أمنية، أو عطل في فرع).
• يُعَدّ جدول تناوب أسبوعي يحدد الموظف المكلَّف بالتغطية الاحتياطية من كل فريق (العمليات، الأنظمة المؤسسية) لكل عطلة نهاية أسبوع، ويُعمَّم على جميع أعضاء الفريق قبل بداية الأسبوع.
• يلتزم الموظف المناوب بأن يكون قابلًا للتواصل (هاتفيًا أو عبر التطبيق المعتمد) طوال فترة المناوبة، وأن يستجيب لأي بلاغ حرج خلال 30 دقيقة كحد أقصى من وقت الاتصال.
• لا يُطلَب من الموظف المناوب الحضور الفعلي للموقع إلا إذا تطلبت طبيعة العطل ذلك، ويُفضَّل حل الأعطال عن بُعد قدر الإمكان.
• يُعوَّض الموظف المناوب عن ساعات الاستجابة الفعلية خلال المناوبة وفق سياسة العمل الإضافي الموضحة أدناه، بينما بدل الجاهزية (Standby Allowance) نفسه يُحدَّد وفق سياسة التعويضات المعتمدة من الموارد البشرية.
• في حال كان الموظف المكلَّف بالتناوب الاحتياطي المحدد في الجدول الأسبوعي في إجازة أو غير متاح لأي سبب، يتولى مدير الفريق المعني (العمليات أو الأنظمة المؤسسية) تعيين الموظف البديل يدويًا قبل بداية فترة التناوب بيوم عمل واحد على الأقل، ويُبلَّغ الفريق بالتحديث فور تعيين البديل.
• إذا تعذّر على مدير الفريق تعيين بديل (لظرف طارئ)، تنتقل مسؤولية التغطية مؤقتًا لمدير تقنية المعلومات حتى تعيين البديل المناسب.
• عند تعيين بديل للتناوب الاحتياطي بسبب حالة طارئة أو إجازة الموظف الأصلي المكلَّف بالتناوب، يجب أن يمتلك البديل المعيَّن حدًا أدنى من المهارات والمعرفة التقنية اللازمة لتغطية مسؤوليات الموظف الأصلي بكفاءة مقبولة، استنادًا إلى مصفوفة الكفاءات (Skills Matrix) المشار إليها في سياسة التدريب المتبادل بهذا المجلد؛ ولا يجوز لمدير الفريق تعيين بديل ليست لديه الإلمام الأساسي بالنظام أو المهمة الحرجة محل التغطية، حتى لو استلزم ذلك تكليف عضوين معًا (أحدهما بمهارة جزئية) لتغطية النطاق الكامل لمسؤوليات الغائب.

سياسة العمل الإضافي (Overtime)

• يستحق الموظف عملًا إضافيًا (أجرًا أو إجازة تعويضية وفق ما تحدده لائحة تنظيم العمل المعتمدة) عن أي ساعات عمل فعلية تتجاوز دوامه النظامي، وذلك وفق نظام العمل السعودي ولوائح وزارة الموارد البشرية والتنمية الاجتماعية؛ وتُحدَّد آلية الاحتساب الدقيقة (النسبة أو الطريقة) في لائحة تنظيم العمل والأجور المعتمدة من الموارد البشرية، ولا يتناولها هذا الدليل كتفصيل تقني.
• لا يُعتَدّ بأي عمل إضافي ولا يُصرف عنه أي مقابل إلا بعد استيفاء إجراء الإذن: يُطلَب إذن مسبق من المدير المباشر قبل البدء بالنسبة للعمل الإضافي المخطط له (كصيانة مجدولة خارج الدوام أو عمل ميداني معروف الموعد)، أو عبر إشعار فوري للمدير المباشر بمجرد الشروع في المعالجة بالنسبة للحالات الطارئة الحقيقية التي يستحيل فيها الحصول على إذن مسبق، على أن يُستكمَل توثيق الطلب رسميًا واعتماده خلال 24 ساعة من بدء العمل.
• ينطبق استحقاق العمل الإضافي على كلا فريقَي إدارة تقنية المعلومات بالتساوي عند العمل الفعلي خارج أوقات الدوام الرسمي — سواء لمعالجة عطل أو حادثة نظام أو لتنفيذ عمل ميداني — شريطة استيفاء إجراء الإذن أو الإشعار الموضح أعلاه.
• العمل الإضافي المنفَّذ دون الحصول على إذن مسبق أو دون إشعار المدير المباشر فورًا في الحالات الطارئة لا يُعتمَد ولا يُصرف عنه أي مقابل؛ ويُعَدّ تجاوز هذا الإجراء مخالفة إجرائية تخضع لسياسة الانضباط والجزاءات وتؤثر على تقييم أداء الموظف، حفاظًا على انضباط احتساب الأجور وحماية لحقوق الموظف والشركة معًا.
• يلتزم المدير المباشر بمراجعة أي طلب عمل إضافي واعتماده أو رفضه خلال 24 ساعة من تقديمه، مع توثيق مبررات القرار.
• يراجع مدير كل فريق سجل العمل الإضافي شهريًا؛ وعند ملاحظة نمط متكرر من الاستدعاء لنفس السبب، يُصنَّف العطل كمشكلة نظامية وفق «سياسة معالجة الأعطال النظامية والتعبئة الجماعية» لمعالجة السبب الجذري، دون أن يمنع ذلك استحقاق الموظفين المعنيين للعمل الإضافي عن الساعات الفعلية التي عملوها.

الورديات ونوافذ الجاهزية الحرجة حسب الدور الوظيفي

توضح هذه الفقرة الفرق بين دوام العمل الرسمي المكتبي وبين الجاهزية للاستجابة للحالات الحرجة، وتحدد الأدوار الوظيفية التي تُعَدّ فيها الاستجابة العاجلة خارج أوقات الدوام جزءًا أصيلًا من طبيعة الوظيفة (Primary Job Function) بحكم أهمية الأنظمة التي يشرف عليها الموظف، تمييزًا عن الحالات التي تندرج تحت سياسة العمل الإضافي الطارئ الموضحة أعلاه.

• المهام الحرجة الواقعة ضمن النطاق الطبيعي للدور الوظيفي (مثل استجابة مهندس الشبكات أو مهندس دعم البنية التحتية لعطل حرج أثناء أسبوع مناوبته المجدولة) تُعَدّ جزءًا من مسؤوليات الوظيفة الأساسية، ولا تُحتسَب كعمل إضافي منفصل، وإنما يشملها بدل الجاهزية (Standby Allowance) المشار إليه في قسم المناوبة.
• تخضع الساعات الفعلية للاستجابة أثناء المناوبة خارج الدوام الرسمي لاستحقاق العمل الإضافي وفق السياسة العامة الموضحة في هذا المجلد (بشرط استيفاء إجراء الإذن أو الإشعار الفوري)، بينما يغطي «بدل الجاهزية» (Standby Allowance) مجرد كون الموظف متاحًا للاستدعاء أثناء أسبوع مناوبته سواء استُدعي فعليًا أم لا. وفي حال تجاوزت وتيرة الاستدعاء الحد المعقول (كالاستدعاء لأكثر من ثلاث مرات خلال مناوبة واحدة)، يُصنَّف العطل إضافةً لذلك كمشكلة نظامية وفق «سياسة معالجة الأعطال النظامية والتعبئة الجماعية»، دون أن يخلّ ذلك باستحقاق الموظف لأجر العمل الإضافي عن الساعات الفعلية التي عملها.
• بالنسبة للأدوار الإدارية والتنسيقية (مثل أخصائي العمليات التشغيلية أو أخصائي الدعم الفني من غير المناوبين أسبوعيًا)، فإن أي عمل خارج الدوام الرسمي يُعامَل دائمًا كعمل إضافي وفق السياسة العامة، ولا يدخل ضمن النطاق الطبيعي للوظيفة.

جدول الورديات ونطاق الجاهزية حسب الدور

أوقات التشغيل الحرجة للأنظمة (مقابل دوام الموظفين)

بحكم طبيعة نشاط المجموعة التجاري/التجزئي، فإن بعض الأنظمة يجب أن تبقى متاحة خلال ساعات تشغيل الفروع، والتي قد تمتد إلى ما بعد الدوام الرسمي لموظفي تقنية المعلومات (8:00ص–5:00م) وتشمل أيام العطلة الأسبوعية؛ وهذا هو المبرر الأساسي لوجود نظام التناوب الاحتياطي رغم أن الدوام المكتبي الرسمي هو الأحد–الخميس فقط.

سياسة معالجة الأعطال النظامية والتعبئة الجماعية (Systemic Issue & Team Mobilization Policy)

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

• يُصنَّف العطل بأنه «نظامي/متكرر» عند تكرار نفس المشكلة أو مشكلة من نفس الجذر (Root Cause) ثلاث مرات فأكثر خلال 30 يومًا، أو بقرار من مدير الفريق المعني إذا رأى أن نمط الأعطال يشير لخلل بنيوي حتى لو لم يبلغ حد التكرار المذكور.
• فور تصنيف العطل كنظامي، يُفتَح سجل مشكلة (Problem Record) إلزاميًا وفق إجراء إدارة المشاكل في المجلد الثالث، ويُحال الملف لمدير الفريق المعني لمتابعته حتى الإغلاق النهائي بحل جذري (وليس فقط باحتواء مؤقت).
• يلتزم جميع أعضاء الفريق ذوي الصلة بالمشاركة في تحليل السبب الجذري ووضع الحل الدائم عند دعوتهم لذلك من مدير الفريق — وليس الموظف المناوب أو من تعامل مع الحادثة الأولى وحده — بحيث تُعامَل معالجة الأعطال النظامية كمسؤولية جماعية للفريق بأكمله.
• يُعطى العمل على الحل الجذري للمشكلة النظامية أولوية قصوى ضمن ساعات الدوام الرسمي التالية للتصنيف، وتُعاد جدولة المهام غير الحرجة الأخرى لإفساح المجال لفريق العمل المخصص لحلها.
• إذا تطلب تنفيذ الحل الجذري عملًا خارج الدوام الرسمي (مثل نشر تحديث كبير أو ترحيل بنية تحتية)، يُدار ذلك كتغيير مخطط له (RFC) ضمن نافذة صيانة معتمدة مسبقًا وفق المجلد التاسع عشر، وليس كعمل إضافي فردي تعويضي متكرر.
• يُوثَّق كل ملف مشكلة نظامية بتقرير تحليل سبب جذري (RCA Report) يوضح: وصف النمط المتكرر، الأثر التراكمي، السبب الجذري المكتشف، الحل الدائم المطبَّق، والتحقق من عدم التكرار لمدة لا تقل عن 30 يومًا بعد الحل قبل إغلاق الملف نهائيًا.
• تُراجَع قائمة المشاكل النظامية المفتوحة أسبوعيًا في اجتماع العمليات (المجلد الرابع)، وتُرفع أي مشكلة نظامية لم تُحل خلال 30 يومًا من فتحها إلى مدير تقنية المعلومات لتصعيد الأولوية أو تخصيص موارد إضافية (مثل الاستعانة بمورد أو شريك ERP).

الهدف من هذه السياسة حماية الفريق من الإرهاق الناتج عن تكرار نفس الأعطال، وتوجيه الجهد نحو الحل الدائم بدلًا من التعويض المتكرر عن أعراض مشكلة لم تُعالَج من جذورها.

التدريب المتبادل وتقليل الاعتماد على فرد واحد (Cross-Training / Bus Factor)

• لكل نظام أو مسؤولية حرجة (الشبكات، قواعد البيانات، ERP، الأمن السيبراني) موظفان مؤهلان على الأقل قادران على الاستجابة الأساسية، تفاديًا لاعتماد استمرارية الخدمة على شخص واحد فقط.
• يُخصَّص للفريق جلسة تبادل معرفي داخلي شهرية (لا تقل عن ساعة) يعرض فيها أحد الأعضاء نظامًا أو حلًا تقنيًا تعامل معه لبقية الفريق، وتُوثَّق ملخصات هذه الجلسات في قاعدة المعرفة.
• عند مغادرة أي موظف رئيسي (استقالة أو نقل) لديه معرفة حصرية بنظام حرج، تُخصَّص فترة تسليم لا تقل عن أسبوعين (حسب فترة الإشعار المتاحة) لنقل المعرفة الكاملة وتوثيقها قبل انتهاء خدمته، بالإضافة لإجراءات Offboarding في الملحق المخصص.
• تُعَدّ مصفوفة الكفاءات (Skills Matrix) للفريق تُحدَّث نصف سنويًا، توضح مستوى إتقان كل عضو لكل نظام رئيسي، وتُستخدَم لتحديد أولويات التدريب المتبادل وسد الفجوات.

سياسة الإجازات والغياب (Leave & Vacation Policy)

• الإجازة السنوية أو أي إجازة مستقبلية مخطط لها: تُقدَّم طلباتها قبل 45 يومًا على الأقل من تاريخ بدايتها، لضمان ترتيب التغطية وجدول المناوبة بشكل مناسب دون التأثير على استمرارية الخدمة.
• الإجازة الطارئة (غير المخطط لها): يمكن تقديم طلبها بإشعار لا يقل عن يومين (48 ساعة) قبل تاريخ بدايتها، مع توضيح موجز للسبب لمديره المباشر.
• أي نوع إجازة آخر خارج ما سبق (كالإجازة المرضية أو الظروف الطارئة العائلية) يتطلب تقديم إثبات رسمي (تقرير طبي أو مستند رسمي داعم) خلال مدة لا تتجاوز 3 أيام عمل من تاريخ العودة للعمل أو من تقديم طلب الإجازة، وفق سياسة الموارد البشرية العامة للشركة.
• تخضع جميع طلبات الإجازة لاعتماد المدير المباشر، مع مراعاة عدم تعارضها مع جدول المناوبة الأسبوعي؛ وفي حال وجود تعارض، يتولى مدير الفريق تعيين بديل للمناوبة وفق الآلية الموضحة في قسم المناوبة بهذا المجلد.
• يُراعى ألا يتزامن أكثر من عضو واحد من أعضاء التخصصات الحرجة (كمهندسي الشبكات أو البنية التحتية) في إجازة بنفس الوقت إلا بموافقة استثنائية من مدير الفريق، لضمان استمرار وجود تغطية فنية كافية.
• يُحتفَظ برصيد الإجازات ومتابعته وفق سياسة الموارد البشرية العامة للشركة ونظام العمل السعودي؛ وهذه السياسة تكمل ولا تُلغي أي حق نظامي للموظف في الإجازات.

التدرج الوظيفي ومسار الترقية (Career Ladder & Promotion Path)

يوضح الجدول التالي مسار التدرج الوظيفي المعتمد لكلا فريقَي إدارة تقنية المعلومات، بما يتيح مسارًا واضحًا للنمو المهني ويحدد معايير الانتقال بين المستويات.

تُراجَع مسارات الترقية سنويًا ضمن اجتماع تقييم الأداء لكل موظف؛ ويُشجَّع التنقل الأفقي (Lateral Move) بين الفريقين كجزء من مبدأ الفريق الواحد الموضح في قسم الهيكل التنظيمي، لتوسيع خبرات الأعضاء وتقليل الاعتماد على فرد واحد (Bus Factor) وفق سياسة التدريب المتبادل.

ضوابط تكليف الموظف بالمهام وتوثيقها (Task Assignment & Documentation Controls)

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

• لا يجوز لأي موظف تنفيذ أي مهمة أو إجراء عمل — مهما كان نوعه أو حجمه — دون تكليف أو إعلام رسمي واضح من مديره المباشر أو مدير القسم (مدير تقنية المعلومات)؛ ولا يُعتَدّ بأي عمل نُفِّذ دون هذا التكليف عند أي مراجعة أو تقييم لاحق.
• أي جهة — داخلية كانت (إدارة أخرى، زميل، مسؤول تنفيذي) أو خارجية (مورد، عميل، شريك) — تحتاج عملاً أو مساعدة من موظف معين في إدارة تقنية المعلومات، يجب أن تمر أولًا بمديره المباشر أو مدير القسم؛ ولا يجوز لها التواصل المباشر مع الموظف لتكليفه بمهمة دون علم واعتماد مديره.
• يُسجَّل ويُوثَّق كل تكليف أو طلب عمل يصل للموظف عبر مديره المباشر (سواء عبر نظام التذاكر، أو تكليف كتابي، أو بريد إلكتروني رسمي)، بحيث يبقى لكل مهمة منفَّذة مرجع موثَّق يوضح من كلَّف بها ومتى.
• في الحالات العاجلة أو الطارئة التي تستدعي تدخلًا فوريًا لا يحتمل التأخير، يجب على الموظف إبلاغ مديره المباشر أو مدير القسم فورًا — إما قبل الشروع في التنفيذ إن أمكن، أو خلال أقصر وقت ممكن بعد البدء إن تعذّر الإبلاغ المسبق — حتى في غياب إذن مسبق صريح.
• يتحمل المدير المباشر أو مدير القسم مسؤولية متابعة وتوثيق كل تكليف يصدر عنه، والتأكد من وصوله للموظف المعني بوضوح، ومن قدرة الموظف على تنفيذه ضمن الوقت والموارد المتاحة.
• الهدف من هذه الضوابط: حماية الموظف من التكليف العشوائي أو المتضارب من مصادر متعددة، وضمان تتبع دقيق وقابل للمراجعة لكل عمل منجز داخل الإدارة، ووضوح تام في تحديد المسؤولية عند أي إشكال لاحق.

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

قناة الإبلاغ الأخلاقي والتصعيد المستقل (Ethics & Whistleblower Channel)

• يحق لأي موظف في إدارة تقنية المعلومات الإبلاغ عن أي شبهة إساءة استخدام للصلاحيات، تلاعب بالأنظمة، تضارب مصالح مع مورد أو شريك، أو أي مخالفة أخلاقية أخرى، دون الحاجة للمرور بمديره المباشر إذا كانت الشبهة تتعلق بذلك المدير نفسه.
• تُدار البلاغات الأخلاقية عبر قناة مستقلة معتمدة من الموارد البشرية أو الإدارة التنفيذية (بريد إلكتروني مخصص أو نظام بلاغات سري)، وتُعامَل بسرية تامة مع حماية المُبلِّغ من أي إجراء انتقامي.
• تخضع كل بلاغ لتحقيق مستقل بالتنسيق بين الموارد البشرية ومدير تقنية المعلومات (أو الإدارة التنفيذية مباشرة إذا كان البلاغ يخص مدير تقنية المعلومات نفسه).

خطة الانضباط والجزاءات (Disciplinary & Penalties Policy)

تهدف هذه السياسة إلى ضمان الالتزام بمعايير الأداء والسلوك المهني داخل إدارة تقنية المعلومات، وتُطبَّق بعدالة وشفافية ووفق مبدأ التدرّج في العقوبة، وبما لا يتعارض مع نظام العمل السعودي ولائحة تنظيم العمل المعتمدة في الشركة (التي تبقى المرجع النظامي الأعلى عند أي تعارض).

المبادئ الحاكمة

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

تصنيف المخالفات ودرجات الجزاء

آلية تطبيق الجزاء

1. رصد المخالفة وتوثيقها من قِبل المدير المباشر أو عبر أدوات المراقبة (سجلات النظام، تقارير الأداء، سجل التذاكر).
2. إشعار الموظف كتابيًا بالمخالفة المرصودة ومنحه فرصة لتقديم إيضاحه خلال مدة لا تقل عن 3 أيام عمل (باستثناء الفئة الرابعة التي تستوجب إجراءً فوريًا).
3. مراجعة إيضاح الموظف من قِبل المدير المباشر بالتنسيق مع مدير تقنية المعلومات والموارد البشرية.
4. اعتماد الجزاء المناسب وفق تصنيف المخالفة أعلاه وتوثيقه رسميًا في النظام وملف الموظف.
5. إبلاغ الموظف بالقرار النهائي كتابيًا، مع توضيح حقه في التظلم وفق سياسة الموارد البشرية.

حق التظلم: يحق للموظف تقديم تظلم كتابي إلى إدارة الموارد البشرية خلال 5 أيام عمل من تاريخ إبلاغه بالجزاء، وتُشكَّل لجنة مراجعة (لا تضم المدير المباشر المُصدِر للجزاء) للبت في التظلم خلال 10 أيام عمل من تاريخ تقديمه.

هذه السياسة إطار توجيهي متكامل مع لائحة تنظيم العمل والجزاءات المعتمدة رسميًا من إدارة الموارد البشرية والمعتمدة من وزارة الموارد البشرية والتنمية الاجتماعية؛ وعند أي تعارض تُطبَّق اللائحة الرسمية المعتمدة للشركة ونظام العمل السعودي.

إدارة التذاكر والأولويات وSLA

• تُصنَّف التذاكر إلى: طلب خدمة (Service Request)، حادثة (Incident)، أو مشكلة (Problem)، ولكل نوع مسار عمل مختلف.
• مستويات الأولوية الأربعة: حرجة (توقف كامل لخدمة أساسية)، عالية، متوسطة، منخفضة — مع زمن استجابة وحل معتمد لكل مستوى موثّق في اتفاقية مستوى الخدمة (SLA).
• زمن الاستجابة المستهدف: 15 دقيقة للحوادث الحرجة، ساعة للأولوية العالية، أربع ساعات للمتوسطة، يوم عمل للمنخفضة (قابلة للتعديل حسب اتفاقية الفرع/الإدارة).
• تُصعَّد التذاكر تلقائيًا عند تجاوز زمن SLA المحدد إلى المستوى الإشرافي التالي، مع إشعار فوري لمدير الفريق المعني.

إدارة الحوادث والمشاكل والمعرفة

• تخضع كل حادثة حرجة لتحليل السبب الجذري (Root Cause Analysis) خلال خمسة أيام عمل من إغلاقها، ويُوثَّق في سجل المشاكل (Problem Log).
• تُحوَّل الحلول المتكررة إلى مقالات في قاعدة المعرفة، وتُتاح لفريق الدعم الفني والمستخدمين ذوي الصلاحية عبر بوابة الخدمة الذاتية.
• يُخصَّص مسار دعم مخصص (Fast-track) للمستخدمين من الفئة VIP (الإدارة التنفيذية) بزمن استجابة لا يتجاوز 10 دقائق.

قياس الرضا والتقارير

• يُرسَل استبيان رضا قصير تلقائيًا عند إغلاق كل تذكرة، وتُحتسب نسبة الرضا شهريًا كمؤشر أداء رئيسي بهدف لا يقل عن 90%.
• تُصدَر تقارير يومية (حجم التذاكر المفتوحة/المغلقة)، وأسبوعية (الاتجاهات ونسب الالتزام بـ SLA)، وشهرية (تحليل شامل للأداء ورضا العملاء) لمدير تقنية المعلومات.

سجل المشكلة وتحليل السبب الجذري (Problem Record & RCA)

• يتضمن سجل المشكلة الحقول التالية كحد أدنى: رقم المشكلة، تاريخ الفتح، وصف النمط المتكرر، عدد مرات التكرار وتواريخها، الأثر التراكمي على الأعمال، الفريق/الأعضاء المكلَّفون بالتحليل، الحالة (قيد التحليل/قيد التنفيذ/مغلقة)، والحل الدائم المطبَّق.
• تُستخدَم منهجية تحليل منظمة للسبب الجذري (مثل «الأسباب الخمسة - 5 Whys» أو مخطط عظم السمكة Fishbone) لضمان الوصول للسبب الحقيقي وليس الأعراض الظاهرة فقط.
• لا يُغلَق سجل المشكلة إلا بعد التحقق من استقرار الحل لمدة لا تقل عن 30 يومًا دون تكرار العطل، وتوثيق الحل النهائي في قاعدة المعرفة (Runbooks) بالمجلد الثامن والعشرين لمنع تكراره مستقبلًا.

مستويات التصعيد الفني (Escalation Tiers)

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

يقتصر تكليف المستوى الثاني (L2) حاليًا على حبيب وأحمد أبو ديه نظرًا لعمق خبرتهما التقنية في أنظمة الأعمال والتكاملات؛ وتُحدَّث هذه القائمة مستقبلًا مع نمو قدرات بقية أعضاء الفريق وفق خريطة تأهيل الكوادر الموضحة في قسم الهيكل التنظيمي.

قوائم التحقق اليومية والمراقبة

• يُنفَّذ Opening Checklist في بداية كل يوم عمل يشمل: التحقق من حالة الخوادم، الشبكات، النسخ الاحتياطي الليلي، البريد الإلكتروني، وأنظمة ERP وPOS.
• يُنفَّذ Closing Checklist في نهاية اليوم للتأكد من عدم وجود تنبيهات معلّقة وتسجيل أي أعمال صيانة مجدولة لليوم التالي.
• تُراقَب الخوادم وقواعد البيانات والشبكة والإنترنت والنسخ الاحتياطية عبر أدوات مراقبة مركزية (Monitoring/SIEM) على مدار الساعة مع تنبيهات آلية.
• تُراجَع جميع التنبيهات (Alerts) خلال 30 دقيقة من صدورها، وتُغلَق أو تُصعَّد مع توثيق الإجراء المتخذ.

التقارير والاجتماعات التشغيلية

• يُعقد اجتماع عمليات يومي قصير (Daily Stand-up) لا يتجاوز 15 دقيقة لمراجعة الحوادث المفتوحة والمخاطر التشغيلية لليوم.
• يُرفع تقرير تشغيلي يومي موجز لمدير الفريق يتضمن: الحوادث، حالة الأنظمة الحرجة، والمهام المعلّقة.

دورة حياة الأصل

• المراحل المعتمدة: طلب الأصل ← الاعتماد ← الشراء ← الاستلام ← التسجيل في CMDB ← الوسم (باركود/RFID) ← الاستخدام والصيانة ← النقل عند الحاجة ← الإتلاف أو إعادة التدوير.
• يُسجَّل كل أصل في قاعدة بيانات إدارة التكوين (CMDB) برقم تسلسلي وباركود فريد فور استلامه، ويُربط بالمستخدم أو الموقع المسؤول عنه.
• يخضع كل أصل لجرد فعلي دوري (سنويًا على الأقل) لمطابقة السجلات مع الواقع، وتُوثَّق أي فروقات ويُحقَّق فيها.
• تخضع عملية إتلاف الأصول التقنية (الحاسبات، الأقراص الصلبة) لإجراء محو آمن للبيانات (Secure Data Wiping) قبل الإتلاف أو إعادة التدوير، مع شهادة إتلاف موثقة.

الصيانة والضمان والنقل

• تُتابَع فترات الضمان لكل أصل في CMDB مع تنبيه تلقائي قبل 30 يومًا من انتهاء الضمان.
• يتطلب أي نقل لأصل بين المستخدمين أو الفروع نموذج تسليم/استلام عهدة موقّعًا من الطرفين ومحدَّثًا في السجل فورًا.

دورة تحديث واستبدال الأجهزة (Technology Refresh Cycle)

• تُحدَّد دورة استبدال إرشادية لكل فئة أصول: أجهزة المستخدمين (الحاسبات المكتبية والمحمولة) كل 4-5 سنوات، أجهزة نقاط البيع والموازين كل 5-7 سنوات، أجهزة الشبكات الأساسية (Switches/Routers) كل 5-6 سنوات، والخوادم كل 5 سنوات أو حسب انتهاء دعم الشركة المصنِّعة.
• تُدرَج تكلفة دورة الاستبدال ضمن الميزانية الرأسمالية (CAPEX) السنوية لتفادي تراكم أعباء استبدال مفاجئة لعدد كبير من الأجهزة في سنة واحدة.
• تخضع الأجهزة التي تجاوزت دورة الاستبدال الموصى بها ولا تزال قيد الاستخدام لتقييم مخاطر (توقف الدعم الفني، ضعف الأداء، مخاطر أمنية) قبل تمديد استخدامها.
• يُراعى عند اختيار الأجهزة البديلة معايير الاستدامة والكفاءة في استهلاك الطاقة (Green IT) حيثما أمكن، والتخلص من الأجهزة القديمة عبر جهات إعادة تدوير معتمدة بيئيًا بعد محو البيانات الآمن.

قاعدة بيانات إدارة التكوين (CMDB) والعلاقات بين عناصر البنية

توضح قاعدة بيانات إدارة التكوين (CMDB) جميع عناصر البنية التقنية (Configuration Items - CIs) والعلاقات فيما بينها، بما يسهِّل تحليل الأثر عند أي تغيير أو عطل. يوضح الجدول التالي نموذجًا مختصرًا للعلاقات الرئيسية:

تُدار قاعدة بيانات إدارة التكوين الكاملة (بكل تفاصيل الأجهزة والإصدارات والمالكين) إلكترونيًا ضمن أداة CMDB أو نظام إدارة الأصول المعتمد، وهذا الجدول عرض مختصر للعلاقات الأكثر أهمية لأغراض تحليل الأثر.

معايير التجهيز والصيانة

• تُعتمد مواصفات قياسية (Standard Hardware Specs) لأجهزة المستخدمين ونقاط البيع لضمان التوافق وتسهيل الدعم والصيانة.
• تخضع أجهزة نقاط البيع والماسحات وأجهزة الباركود وأجهزة البصمة لفحص دوري ربع سنوي والتأكد من سلامة عملها.
• تُختبَر وحدات UPS (مزودات الطاقة اللامنقطعة) شهريًا للتأكد من قدرتها على توفير التغطية اللازمة عند انقطاع الكهرباء.
• تُدار أجهزة العرض وغرف الاجتماعات وأجهزة الفيديو كونفرنس والهواتف والأجهزة اللوحية ضمن نفس دورة حياة الأصول مع جدول صيانة وقائية سنوي.

إدارة التراخيص والامتثال

• يُحتفَظ بسجل مركزي لجميع تراخيص البرمجيات (Windows، Microsoft 365، ERP، LS Retail، SQL Server، Power BI، Adobe، Visual Studio، وغيرها) مع تواريخ الشراء والتجديد وعدد المستخدمين المرخصين.
• يُحظر تركيب أي برنامج غير مرخّص أو غير معتمد من إدارة تقنية المعلومات على أجهزة الشركة.
• تُراجَع حالة الترخيص والامتثال (License Compliance Audit) سنويًا لتفادي المخالفات القانونية أو استخدام تراخيص منتهية.

إدارة التحديثات والنسخ

• تُطبَّق التحديثات الأمنية الحرجة (Critical Security Patches) خلال 72 ساعة من صدورها بعد اختبارها في بيئة غير إنتاجية.
• تُدار بيئات التطوير (Visual Studio، Flutter، Git) وفق معايير إصدارات موحدة، وتُوثَّق كل نسخة برمجية بترقيم دلالي (Semantic Versioning).
• يخضع استخدام أدوات الوصول عن بُعد مثل AnyDesk لسياسة صارمة: تفعيل عند الحاجة فقط، وتسجيل الجلسة، وتوثيق الغرض من الاتصال.

سياسة الحد من تقنية المعلومات غير المعتمدة (Shadow IT)

• يُحظر على أي إدارة أو موظف الاشتراك أو استخدام أي برنامج أو خدمة سحابية (SaaS) أو أداة تقنية لأغراض العمل دون مراجعة واعتماد مسبق من إدارة تقنية المعلومات، بصرف النظر عن كون الاشتراك مجانيًا أو مدفوعًا من ميزانية الإدارة الطالبة.
• تشمل الأمثلة الشائعة الخاضعة لهذا الحظر: أدوات مشاركة الملفات السحابية الشخصية، تطبيقات إدارة المهام أو التواصل غير المعتمدة، وأدوات الذكاء الاصطناعي العامة غير المرخصة مؤسسيًا (مرتبط بسياسة الذكاء الاصطناعي في المجلد الثاني والثالث والعشرين).
• تُجرى مراجعة دورية (نصف سنوية) لحركة الشبكة والمصروفات لاكتشاف أي استخدام غير معتمَد لخدمات سحابية (Cloud Discovery)، ويُعالَج أي استخدام مكتشَف إما باعتماده رسميًا بعد تقييم أمني، أو إيقافه واستبداله بحل معتمد.
• يُشجَّع الموظفون على تقديم طلب رسمي لأي أداة جديدة يرون حاجة العمل لها، عوضًا عن اللجوء لحلول غير معتمدة، وتلتزم إدارة تقنية المعلومات بالرد على مثل هذه الطلبات خلال مدة معقولة لا تتجاوز أسبوعًا.

إدارة الحسابات

• يُنشَأ حساب البريد الإلكتروني فور اعتماد طلب التوظيف الرسمي، وبصيغة موحدة لتسمية الحسابات معتمدة من الإدارة.
• يُوقَف حساب الموظف فورًا (خلال ساعة) عند إشعار الموارد البشرية بإنهاء الخدمة، ويُحذَف نهائيًا بعد 90 يومًا وفق سياسة الاحتفاظ بالبيانات.
• تخضع طلبات إنشاء البريد المشترك (Shared Mailbox) ومجموعات البريد التوزيعية لموافقة مالك القسم المعني.
• يُلزَم جميع الموظفين باستخدام التوقيع الرسمي المعتمد من إدارة التسويق/الاتصال المؤسسي في جميع المراسلات.

الأمان والحماية

• تُفعَّل المصادقة متعددة العوامل (MFA) إلزاميًا على جميع حسابات البريد الإلكتروني دون استثناء.
• تُطبَّق أنظمة مكافحة الرسائل المزعجة (Anti-Spam) ومكافحة التصيد الاحتيالي (Anti-Phishing) مع تحديث مستمر لقواعد الفلترة.
• تُجرى حملات توعية ومحاكاة تصيد إلكتروني (Phishing Simulation) للموظفين مرتين سنويًا على الأقل.
• تُحفَظ رسائل البريد الإلكتروني وفق سياسة أرشفة لا تقل عن ثلاث سنوات بما يتوافق مع متطلبات الامتثال.

حوكمة بيئة Microsoft 365 السحابية (Tenant Governance)

• يُقيَّد عدد حسابات المسؤول العام (Global Administrator) على بيئة Microsoft 365 بالحد الأدنى الضروري (شخصان كحد أقصى)، مع تفعيل المصادقة متعددة العوامل إلزاميًا وتسجيل كل نشاط إداري.
• تُطبَّق سياسات الوصول المشروط (Conditional Access) للتحقق من الجهاز والموقع الجغرافي قبل السماح بالدخول للبريد والتطبيقات السحابية، خصوصًا من خارج الشبكة الداخلية.
• تخضع صناديق البريد التي تتجاوز سعتها المعتادة، أو الحسابات غير النشطة لأكثر من 90 يومًا، لمراجعة دورية من فريق العمليات لتحديد ما إذا كانت ما زالت قيد الاستخدام الفعلي.
• تُدار تراخيص Microsoft 365 (E3/E5 أو ما يعادلها) وفق الحاجة الفعلية لكل دور وظيفي، مع مراجعة سنوية لمطابقة عدد التراخيص المشتراة مع عدد المستخدمين الفعليين لتحسين التكلفة.

دورة حياة المستخدم

• يُنشأ حساب المستخدم في Active Directory/Azure AD بناءً على نموذج طلب معتمد من المدير المباشر والموارد البشرية، مع تحديد المجموعات والصلاحيات وفق الدور الوظيفي.
• تُحذَف أو تُعطَّل حسابات المستخدمين فور انتهاء الخدمة، وتُنقَل ملكية بياناتهم إلى المدير المباشر خلال فترة زمنية محددة قبل الحذف النهائي.
• تُعاد كلمات المرور المنسية عبر قناة موثقة (بوابة إعادة تعيين ذاتية أو تحقق هوية عبر مكتب المساعدة) دون مشاركة كلمة المرور عبر البريد أو الهاتف بشكل مباشر.

الصلاحيات وأمن الوصول

• تُطبَّق سياسة أقل صلاحية (Least Privilege) وتُمنَح الصلاحيات المرتفعة (Admin) بشكل مؤقت ومبرَّر (Just-In-Time Access) مع تسجيل كامل للاستخدام.
• يُفعَّل تسجيل الدخول الموحد (SSO) والمصادقة متعددة العوامل (MFA) لجميع الأنظمة الحساسة والوصول عن بُعد.
• تُراجَع عضويات المجموعات والصلاحيات كل ستة أشهر (User Access Review) من قِبل مالكي الأنظمة، وتُوثَّق نتائج المراجعة.

إدارة كلمات المرور وحسابات الخدمة (1Password)

• تُعتمَد أداة 1Password (بحساب Business/Teams مؤسسي) كأداة رسمية وحيدة لإدارة وتخزين ومشاركة كلمات مرور الحسابات الإدارية وحسابات الخدمة (Service Accounts) وأي بيانات اعتماد حساسة أخرى داخل إدارة تقنية المعلومات.
• يُحظر تمامًا مشاركة أي كلمة مرور أو بيانات اعتماد عبر البريد الإلكتروني أو الرسائل النصية أو تطبيقات المحادثة أو أي وسيلة أخرى خارج 1Password.
• تُنظَّم خزائن (Vaults) منفصلة داخل 1Password حسب الفريق والغرض (مثال: خزنة الشبكات، خزنة قواعد البيانات، خزنة ERP، خزنة حسابات الخدمة العامة)، بحيث لا يصل كل موظف إلا للخزائن المرتبطة بمهامه وفق مبدأ أقل صلاحية.
• تخضع جميع كلمات مرور حسابات الخدمة (Service Accounts) والحسابات الإدارية المشتركة لتغيير دوري لا يتجاوز 90 يومًا، ويُدار هذا التدوير وتوثيقه عبر 1Password.
• عند انتهاء خدمة أي موظف أو تغيير دوره الوظيفي، تُلغى صلاحية وصوله لخزائن 1Password فورًا (ضمن نفس إجراء إلغاء الحسابات في المجلد التاسع)، وتُغيَّر أي كلمات مرور كان يملك صلاحية الاطلاع عليها لحسابات مشتركة أو حساسة.
• يُفعَّل سجل التدقيق (Activity Log) في 1Password ويُراجَع ربع سنويًا من قِبل منسق عمليات تقنية المعلومات للتحقق من عدم وجود وصول غير معتاد.
• تُفعَّل المصادقة متعددة العوامل (MFA) إلزاميًا على حساب 1Password لكل مستخدم، إضافة إلى مفتاح الأمان السري (Secret Key) الذي يُحفَظ بشكل آمن ومنفصل.

دورة حياة حسابات الشركاء والأطراف الخارجية (Third-Party Account Lifecycle)

• تُنشأ حسابات أي طرف خارجي (شريك ERP، مزودو الدعم، الاستشاريون، فنيو الصيانة) بشكل فردي باسم كل شخص فعليًا، ويُحظر إنشاء أو استخدام حسابات عامة مشتركة لأكثر من شخص خارجي.
• تُفعَّل المصادقة متعددة العوامل (MFA) إلزاميًا على أي حساب طرف خارجي فور إنشائه، دون استثناء.
• تخضع جميع حسابات الأطراف الخارجية لمراجعة دورية كل ثلاثة أشهر (أعلى تكرارًا من مراجعة الحسابات الداخلية نصف السنوية في المجلد التاسع)، للتحقق من استمرار الحاجة الفعلية لكل حساب ونطاق صلاحياته.
• تُدار كلمات مرور أي حساب خارجي مشترك حصريًا عبر 1Password مع تدوير دوري، وتُسجَّل جميع جلسات دخول الأطراف الخارجية للأنظمة الحساسة (Session Recording) عبر أداة الوصول عن بُعد المعتمدة.
• يُعطَّل حساب الطرف الخارجي فورًا (خلال ساعة من إشعار انتهاء المهمة أو تعليق التعاقد)، ويُحذَف نهائيًا خلال 7 أيام من انتهاء العقد رسميًا، ما لم توجد حاجة توثيقية لإبقائه معطلًا (لا مفعّلًا) لفترة أطول لأغراض التدقيق.

مصفوفة قرار صلاحيات وصول الأطراف الخارجية

البنية والتقسيم

• تُقسَّم الشبكة إلى شبكات فرعية منطقية (VLANs) حسب الوظيفة (بيانات، صوت، ضيوف، نقاط بيع، كاميرات) لعزل حركة المرور وتحسين الأمان.
• تُدار الشبكة الواسعة (WAN) بين الفروع والمقر الرئيسي عبر روابط مؤمَّنة (MPLS/VPN) مع خط اتصال احتياطي (Failover) للمواقع الحرجة.
• تخضع شبكات الواي فاي للضيوف للعزل الكامل عن الشبكة الداخلية، وتتطلب مصادقة عبر بوابة دخول (Captive Portal).

الحماية والمراقبة

• تُدار جدران الحماية (Firewall) بقواعد مصرَّح بها فقط (Default-Deny)، وتُراجَع القواعد كل ثلاثة أشهر لإزالة القواعد غير المستخدمة.
• تُراقَب أداء الشبكة والإنترنت وسعة الروابط باستمرار عبر أدوات مراقبة مركزية مع تنبيهات عند تجاوز حدود الاستخدام أو انقطاع الخدمة.
• تُدار العلاقة مع مزودي خدمة الإنترنت والاتصالات وفق اتفاقيات مستوى خدمة موثّقة تشمل زمن الاستجابة وحل الأعطال.

سياسة وصول الضيوف والزوار للشبكة (Guest & Visitor Network Access)

• يُتاح للضيوف والزوار الاتصال حصريًا بشبكة الواي فاي المخصصة للضيوف (VLAN معزول تمامًا عن الشبكة الداخلية وفق المجلد العاشر)، ولا يُمنح أي زائر بيانات اتصال بالشبكة الداخلية للشركة تحت أي ظرف.
• تتطلب شبكة الضيوف مصادقة أساسية عبر بوابة دخول (Captive Portal) مع تحديد مدة صلاحية الجلسة (يوم واحد كحد أقصى قابل للتجديد بموافقة الموظف المضيف).
• يُحظَر على أجهزة الضيوف والزوار الوصول لأي طابعة أو مورد داخلي مشترك، ويُقيَّد النطاق الترددي المخصص لشبكة الضيوف لمنع التأثير على أداء الشبكة الداخلية للعمليات الحرجة.

سياسة أنظمة الاتصالات الموحدة والهاتف عبر الإنترنت (VoIP/PBX)

• تُدار جميع أنظمة الاتصالات الهاتفية عبر بروتوكول الإنترنت (PBX IP) مركزيًا، مع نسخ احتياطي دوري لإعدادات النظام والأرقام الداخلية.
• يُحدَّد لكل قسم أو فرع مجموعات هاتفية (Ring Groups) وصفوف انتظار (Queues) واضحة لضمان توجيه المكالمات بكفاءة، مع رد آلي (IVR) للمكالمات الواردة الرئيسية.
• تخضع جودة المكالمات (الداخلية والخارجية عبر مزودي SIP Trunk) لمراقبة دورية، وتُعالَج أي أعطال متكررة في الجودة كمشكلة نظامية وفق سياسة المشاكل النظامية بالمجلد الثاني.
• تُصان الشبكة الصوتية (Voice VLAN) بمعزل عن حركة بيانات الشبكة العادية لضمان جودة المكالمات، وفق تقسيم VLAN الموضح في المجلد العاشر.

التشغيل والصيانة

• تُدار الخوادم (Windows Server / Linux) وفق معايير تسمية وتصنيف موحدة، وتُوثَّق في CMDB مع تفاصيل السعة والغرض والمالك.
• تُدار بيئات المحاكاة الافتراضية (Hyper-V / VMware) بحيث لا تتجاوز نسبة استخدام الموارد (CPU/RAM) 80% في الحالة الطبيعية لضمان هامش أمان تشغيلي.
• تخضع التحديثات (Patching) للخوادم لنافذة صيانة شهرية معتمدة خارج أوقات الذروة، مع اختبار مسبق في بيئة غير إنتاجية.

التخزين وتخطيط السعة

• تُدار أنظمة التخزين (RAID/NAS/SAN) بمستوى حماية يضمن استمرارية العمل عند تعطل قرص واحد على الأقل (RAID 5/6 أو ما يعادله).
• يُجرى تخطيط للسعة (Capacity Planning) كل ثلاثة أشهر بناءً على معدلات النمو الفعلية لتفادي نفاد الموارد المفاجئ.
• تُراقَب مؤشرات أداء الخوادم (المعالج، الذاكرة، التخزين، الشبكة) باستمرار مع تنبيهات عند تجاوز 85% من السعة القصوى.

تخطيط السعة (Capacity Planning) — توقعات ثلاث سنوات

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

تُحدَّث أرقام هذا الجدول ربع سنويًا بناءً على بيانات المراقبة الفعلية من أدوات مراقبة الأداء (المجلد الحادي عشر)، وتُرفع أي مخاطر اقتراب من الحدود الحرجة للجنة تقنية المعلومات فورًا وليس فقط في المراجعة الدورية.

النسخ الاحتياطي والاستعادة والصيانة

• تُؤخذ نسخة احتياطية كاملة يوميًا ونسخ تفاضلية/سجل معاملات كل ساعة على الأقل لقواعد البيانات الحرجة (ERP، LS Retail).
• تُختبَر عملية استعادة قاعدة البيانات فعليًا (Restore Test) شهريًا للتأكد من صلاحية النسخ الاحتياطية.
• تُنفَّذ أعمال صيانة الفهارس (Index Maintenance) وتحديث الإحصائيات دوريًا أسبوعيًا لضمان الأداء الأمثل.

التوافرية العالية والحماية

• تُفعَّل تقنية Always On / Replication لقواعد البيانات الحرجة لضمان استمرارية الخدمة عند فشل الخادم الرئيسي.
• تُشفَّر البيانات الحساسة أثناء التخزين والنقل (Encryption at Rest & in Transit)، وتُقيَّد صلاحيات الوصول المباشر لقواعد البيانات على فريق محدد فقط.

التشغيل والتكامل والتطوير

• تُدار جميع التخصيصات والتطويرات على Business Central وLS Retail عبر بيئة تطوير منفصلة عن بيئة الإنتاج، وفق دورة تطوير موثقة (SDLC).
• تُدار التكاملات بين ERP ونقاط البيع (POS) وData Director والأنظمة الخارجية عبر واجهات API موثقة مع مراقبة مستمرة لحالة الاتصال.
• يخضع أي تقرير جديد أو تعديل على تقرير موجود لعملية اعتماد من مالك العملية المعنية قبل النشر للمستخدمين.

الاختبار والإصدارات والدعم

• تخضع كل نسخة/تحديث جديد لـERP أو LS Retail لدورة اختبار كاملة (Functional Testing ثم UAT) قبل الترحيل للإنتاج، مع خطة تراجع (Rollback Plan) جاهزة.
• يُقدَّم الدعم الوظيفي والفني للمستخدمين وفق نفس إطار خدمة الدعم الفني (SLA) المحدد في المجلد الثالث.

إدارة شريك تنفيذ ودعم ERP (ERP Implementation & Support Partner)

• يُعرَّف «شريك ERP» بأنه الشركة الخارجية المتعاقَد معها لتنفيذ ودعم وتخصيص وصيانة نظام Business Central وLS Retail، سواء كانت الشركة المطوِّرة الأصلية أو أحد شركائها المعتمدين (Solution Partner/Reseller).
• يُعيَّن لدى الشريك نقطة اتصال رئيسية واحدة (Account Manager) ومسؤول فني رئيسي (Technical Lead) معروفَين لدى فريق الأنظمة المؤسسية، بحيث تكون جميع الطلبات والتصعيدات موثقة عبر نظام التذاكر ولا تُدار بشكل غير رسمي عبر قنوات شخصية.
• تُحدَّد مسؤوليات الشريك تعاقديًا لتشمل: معالجة الأعطال والحوادث ضمن SLA المتفق عليه، تنفيذ طلبات التغيير المعتمدة (بعد مرورها بإجراء RFC في المجلد التاسع عشر)، نشر التحديثات والإصدارات الجديدة بالتنسيق مع فريق الأنظمة المؤسسية، وتوثيق أي تخصيص برمجي (Customization) في قاعدة المعرفة الداخلية فور إنجازه.
• لا يجوز لشريك ERP تنفيذ أي تعديل مباشر على بيئة الإنتاج (Production) دون طلب تغيير معتمد (RFC) وموافقة مسبقة من مدير فريق الأنظمة المؤسسية والحلول الرقمية، إلا في حالات الطوارئ الموثقة وفق إجراء التغيير الطارئ.
• تُعقد اجتماعات مراجعة دورية مع شريك ERP (شهريًا كحد أدنى) لمتابعة التذاكر المفتوحة، جودة الحلول، الالتزام بـSLA، وخطة الإصدارات القادمة، وتُقيَّم الشراكة سنويًا ضمن آلية تقييم الموردين العامة في المجلد العشرين.
• يُلزَم الشريك بنقل المعرفة (Knowledge Transfer) لفريق الأنظمة المؤسسية الداخلي بشكل مستمر، بحيث لا تعتمد الشركة اعتمادًا كليًا على الشريك الخارجي لفهم أو صيانة التخصيصات الجوهرية في النظام (اتساقًا مع خطة الخروج من الموردين في المجلد العشرين).

ضوابط دخول شريك ERP للنظام (Partner Access & Roles)

• يُمنَح كل موظف لدى شريك ERP حسابًا فرديًا مسمّى باسمه (وليس حسابًا عامًا مشتركًا)، مرتبطًا ببريده الإلكتروني الرسمي لدى الشريك، لضمان إمكانية تتبع كل نشاط داخل النظام لشخص محدد.
• تُمنَح الحسابات وفق مبدأ أقل صلاحية ممكنة والأدوار الموضحة في الجدول أدناه؛ ولا يُمنَح أي حساب صلاحية مدير النظام الكاملة (Global Admin) إلا في حالات استثنائية موثقة ومحدودة المدة.
• الوصول الافتراضي لموظفي الشريك يكون على بيئة الاختبار (Sandbox/Test Environment) فقط؛ ولا يُمنَح الوصول لبيئة الإنتاج (Production) إلا مؤقتًا (Just-In-Time Access) لتنفيذ مهمة محددة معتمدة، ويُلغى تلقائيًا فور انتهاء المهمة أو خلال 24 ساعة كحد أقصى.
• يتطلب أي دخول لبيئة الإنتاج من قِبل الشريك موافقة مسبقة من أخصائي أنظمة ERP الداخلي أو مدير فريق الأنظمة المؤسسية، وتسجيل الجلسة (Session Recording) عند الاتصال عن بُعد.
• يتم الاتصال عن بُعد لشريك ERP حصريًا عبر قناة آمنة معتمدة (VPN مخصص للموردين + مصادقة متعددة العوامل، أو أداة وصول عن بُعد خاضعة للمراقبة مثل AnyDesk تحت إشراف مباشر من الفريق الداخلي)، ويُحظر منح بيانات اعتماد شبكة داخلية عامة للشريك.
• يوقّع كل موظف لدى الشريك له صلاحية وصول اتفاقية سرية وعدم إفصاح (NDA) قبل منح أي حساب، وتُراجَع قائمة حسابات الشريك النشطة شهريًا (بمعدل أعلى من مراجعة الحسابات الداخلية) لضمان إلغاء أي حساب لموظف لم يعد يعمل على حساب الشركة لدى الشريك.
• تُلغى جميع صلاحيات وصول الشريك فورًا عند انتهاء العقد أو تعليق الخدمة أو وجود نزاع تعاقدي، وتُغيَّر أي بيانات اعتماد مشتركة كانت متاحة له (عبر 1Password) في نفس اليوم.

جدول أدوار وصلاحيات شريك ERP

يُدار طلب دخول شريك ERP رسميًا عبر نموذج «طلب صلاحية مورد خارجي» الموضح في المجلد السابع والعشرين (النماذج الرسمية)، ويُوثَّق كل منح أو إلغاء صلاحية في سجل مستقل يخضع للمراجعة الدورية من قِبل أخصائي أنظمة ERP.

سياسة اختيار شريك ERP

• يخضع اختيار أي شريك جديد لتنفيذ أو دعم Business Central/LS Retail لتقييم فني ومالي مقارن يشمل: الخبرة المثبتة في قطاع التجزئة، عدد المستشارين المعتمدين (Microsoft Certified) لدى الشريك، مرجعية عملاء بحجم وطبيعة عمل مشابهة، والقدرة على تقديم دعم محلي فعّال داخل المملكة العربية السعودية.
• يخضع الشريك الجديد لتقييم الاستقرار المالي والتجاري (سنوات الخبرة، حجم الفريق، الشراكة الرسمية مع Microsoft) قبل التعاقد، ضمن آلية المشتريات التقنية العامة بالمجلد الحادي والعشرين.

حدود المسؤوليات بين شريك ERP وإدارة تقنية المعلومات

R = مسؤول عن التنفيذ | A = معتمد نهائيًا | C = يُستشار | I = يُبلَّغ.

إدارة بيئات التطوير والاختبار والإنتاج (DEV / TEST / UAT / PROD)

• تُدار أربع بيئات منفصلة ومعزولة تمامًا عن بعضها لنظام ERP: بيئة التطوير (DEV) لأي تخصيص أو تطوير جديد، بيئة الاختبار الداخلي (TEST) للفحص الوظيفي والتقني من الفريق الداخلي، بيئة قبول المستخدم (UAT) لاعتماد أصحاب العمليات من الإدارات المستفيدة، وبيئة الإنتاج (PROD) للتشغيل الفعلي فقط.
• لا يجوز نشر أي تعديل أو تخصيص مباشرة من بيئة DEV إلى بيئة PROD؛ ويجب المرور التسلسلي عبر جميع البيئات الوسيطة (TEST ثم UAT) والحصول على اعتماد رسمي في كل مرحلة قبل الانتقال للتالية.
• تُحدَّث بيانات بيئتي TEST وUAT دوريًا (كل ثلاثة أشهر على الأقل) من نسخة مُنظَّفة ومموَّهة (Data Masking) من بيانات الإنتاج، لضمان واقعية بيئة الاختبار دون المساس بخصوصية بيانات العملاء أو الموظفين الحساسة.

إدارة الإصدارات وتقويم التحديثات

• يُصدَر تقويم إصدارات (Release Calendar) نصف سنوي بالتنسيق مع شريك ERP يوضح المواعيد المتوقعة لأي تحديث دوري (Patch) من Microsoft أو ترقية كبرى (Major Upgrade)، بما يسمح بالتخطيط المسبق واختباره بعيدًا عن فترات تجميد التغييرات الموضحة في المجلد التاسع عشر.
• تُطبَّق تحديثات Microsoft الدورية أولًا على بيئة TEST للتحقق من عدم تعارضها مع التخصيصات القائمة قبل جدولتها لبيئة الإنتاج ضمن نافذة صيانة معتمدة.

دورة تطوير وترحيل البيانات

• يمر أي تخصيص جديد بمراحل: تحليل المتطلبات وتوثيقها (FRD) ← التصميم الفني ← التطوير في بيئة DEV ← المراجعة الداخلية للكود ← الاختبار الوظيفي في TEST ← اعتماد المستخدم في UAT ← النشر في PROD وفق إجراء إدارة التغيير في المجلد التاسع عشر.
• يخضع أي ترحيل بيانات (Data Migration) — سواء من نظام قديم أو بين بيئات — لخطة ترحيل موثقة تشمل: تنظيف البيانات (Data Cleansing)، خرائط الترحيل (Field Mapping)، تنفيذ ترحيل تجريبي (Mock Migration) للتحقق من النتائج، والتحقق النهائي من اكتمال ودقة البيانات قبل الاعتماد الرسمي للترحيل الفعلي.

بطاقة تقييم أداء شريك ERP (Partner Scorecard)

تُحتسَب النتيجة الإجمالية ربع سنويًا وتُناقَش مع الشريك في اجتماع المراجعة الدوري، وتؤثر نتيجتها التراكمية السنوية على قرار تجديد العقد وفق آلية تقييم الموردين العامة في المجلد العشرين.

حوكمة واجهات البرمجة والتكاملات (API & Integration Governance)

• تُوثَّق كل واجهة برمجة (API) مستخدمة أو مطوَّرة داخليًا في سجل مركزي يشمل: الغرض منها، النظام المصدر والنظام الهدف، طريقة المصادقة المستخدمة، وتكرار الاستدعاء المتوقع.
• تخضع جميع واجهات API الخارجية (مع البنوك، الشركاء، مزودي الخدمات) لمصادقة آمنة (OAuth2 أو مفتاح API مشفَّر)، ولا تُستخدَم بيانات اعتماد ثابتة دون تدوير دوري منتظم.
• يُراقَب أداء كل تكامل رئيسي (زمن الاستجابة ومعدل الفشل) عبر أدوات المراقبة المركزية، مع تنبيه تلقائي فوري عند تجاوز معدل فشل 5% خلال ساعة واحدة.
• يخضع أي تكامل جديد لمراجعة أمنية إلزامية قبل الإطلاق للتحقق من عدم تسرب أي بيانات حساسة عبر الواجهة، وتوثيق نتيجة المراجعة في ملف المشروع.

حوكمة الكائنات البرمجية والتخصيصات (Objects & Customization Governance)

• يُحتفَظ بسجل مركزي لكل كائن برمجي مخصَّص (Custom Object) في Business Central/LS Retail، يشمل: رقم الكائن، الغرض منه، تاريخ الإنشاء، والمطوِّر المسؤول (داخلي أو من شريك ERP).
• تُخصَّص نطاقات أرقام كائنات (Object ID Ranges) منفصلة لكل مطوِّر أو شريك لمنع التعارض بين التخصيصات المختلفة عند التطوير المتزامن.
• يُحظر تعديل الكائنات القياسية (Standard Objects) الخاصة بـMicrosoft مباشرة؛ وتُستخدَم آلية الامتدادات (Extensions) حصريًا للتخصيص، لضمان استمرارية التوافق مع التحديثات المستقبلية.

إدارة الامتدادات والتكاملات (Extensions & API Governance)

• تُطوَّر جميع التخصيصات كامتدادات (AL Extensions) متوافقة مع نموذج التوسعة الرسمي لـBusiness Central، وليس كتعديلات مباشرة على الكود الأساسي.
• يخضع كل امتداد جديد لمراجعة فنية داخلية (من أخصائي ERP أو مدير فريق الأنظمة المؤسسية) قبل تركيبه على بيئة الإنتاج، للتحقق من الأداء وعدم التعارض مع امتدادات أخرى قائمة.
• تُوثَّق جميع واجهات API المرتبطة بـERP (الصادرة والواردة) في سجل مركزي موحَّد مع النظام العام لحوكمة API الموضح في هذا المجلد.

مصفوفة صلاحيات ERP (Permission Sets)

• تُبنى الصلاحيات داخل Business Central عبر مجموعات صلاحيات (Permission Sets) محددة الأدوار (مثل: مستخدم مبيعات، محاسب، مدير مخزون) بدلًا من منح صلاحيات فردية متفرقة لكل مستخدم.
• لا يُمنح أي مستخدم صلاحية SUPER (صلاحية كاملة على النظام) إلا لعدد محدود جدًا من الحسابات الإدارية الموثقة، مع مراجعة ربع سنوية لهذه القائمة.
• تُراجَع مصفوفة الصلاحيات الكاملة سنويًا بالتنسيق بين أخصائي ERP ومدير فريق الأنظمة المؤسسية، للتأكد من اتساقها مع الهيكل التنظيمي الفعلي والأدوار الوظيفية الحالية.

دورة حياة التطوير الكاملة (Development Lifecycle) ومراجعة الكود

• تلتزم جميع تطويرات ERP (الداخلية وتلك التي ينفذها شريك ERP) بدورة موحدة: تحليل المتطلبات ← التصميم الفني ← التطوير في بيئة DEV ← مراجعة الكود ← الاختبار في TEST ← اعتماد المستخدم (UAT) ← النشر في PROD، دون تجاوز أي مرحلة.
• تخضع كل عملية نشر (Deployment) لبيئة الإنتاج لإجراء تغيير موثق (RFC) يشمل خطة تراجع (Rollback) جاهزة ومختبرة قبل التنفيذ.
• يُحتفَظ بسجل إصدارات (Version Control) كامل لكل تخصيص، يوضح رقم الإصدار، تاريخ النشر، والتغييرات المضمَّنة في كل إصدار.

حوكمة LS Retail وData Director والمزامنة (Replication)

• تُدار عملية المزامنة (Replication) بين قاعدة بيانات المقر الرئيسي وقواعد بيانات نقاط البيع في الفروع عبر Data Director، مع مراقبة يومية للتأكد من اكتمال المزامنة دون أخطاء أو تأخير.
• يخضع أي تعارض بيانات ناتج عن انقطاع الاتصال بين الفرع والمقر الرئيسي لإجراء تسوية موثَّق (Conflict Resolution) يحدد أولوية المصدر الصحيح للبيانات.
• تُراقَب أداء استعلامات LS Retail وBusiness Central دوريًا (Query Performance)، وتُحسَّن الفهارس وخطط الاستعلام عند ملاحظة تدهور في زمن الاستجابة.

معايير الكود وإدارة الإصدارات

• يلتزم جميع المطورين بمعايير برمجة موحدة (Coding Standards) لكل لغة/منصة، تشمل التسمية والتعليقات ومعالجة الأخطاء.
• تُدار الأكواد المصدرية عبر Git وفق إستراتيجية فروع موحدة (Git Flow / Trunk-Based) مع حظر الدفع المباشر (Direct Push) إلى الفرع الرئيسي (main/production).
• يخضع كل طلب دمج (Pull Request) لمراجعة كود (Code Review) من مطور آخر قبل الدمج، للتحقق من الجودة والأمان.

الجودة والنشر

• تخضع كل ميزة جديدة لاختبار الجودة (QA) ثم اختبار قبول المستخدم (UAT) قبل النشر في بيئة الإنتاج.
• تُدار خطوط أنابيب النشر (CI/CD) بشكل آلي قدر الإمكان، مع خطوة اعتماد يدوي إلزامية قبل النشر في بيئة الإنتاج.
• يتطلب كل نشر خطة تراجع (Rollback) موثقة ومسبقة الجاهزية، وتوثيق فني (Documentation) مرفق مع كل إصدار جديد.

إدارة البرمجيات والمكتبات مفتوحة المصدر (Open Source Governance)

• لا يُعتمَد استخدام أي مكتبة أو إطار عمل مفتوح المصدر في مشاريع التطوير الداخلية إلا بعد التحقق من نوع الترخيص (MIT، Apache 2.0، GPL، إلخ) والتأكد من توافقه مع الاستخدام التجاري لأنظمة الشركة.
• يُحظر استخدام مكتبات بتراخيص تتطلب الإفصاح عن الكود المصدري الخاص بالشركة (مثل تراخيص GPL القوية) في الأنظمة التجارية المغلقة دون مراجعة واعتماد من مدير فريق الأنظمة المؤسسية والحلول الرقمية.
• يُحتفَظ بسجل مركزي لجميع المكتبات مفتوحة المصدر المستخدمة في كل مشروع (Software Bill of Materials - SBOM) يشمل الاسم والإصدار والترخيص.
• تخضع جميع المكتبات مفتوحة المصدر لفحص ثغرات أمنية دوري (Dependency/SCA Scanning) قبل النشر وبشكل دوري بعده، ومعالجة أي ثغرة حرجة خلال المهل الزمنية المحددة في سياسة إدارة الثغرات بالمجلد السادس عشر.

الاستضافة والأداء والأمان

• تُدار جميع النطاقات (Domains) وشهادات SSL مركزيًا مع تنبيه تلقائي قبل 30 يومًا من انتهاء صلاحية أي شهادة أو نطاق.
• تُستخدَم شبكة توصيل المحتوى (CDN) لتحسين أداء المواقع وتقليل زمن التحميل، مع مراقبة مستمرة لزمن الاستجابة.
• تخضع المواقع والتطبيقات لفحص أمني دوري (Vulnerability Scan) ربع سنوي على الأقل، ومعالجة الثغرات وفق أولويتها.
• تُؤخذ نسخة احتياطية يومية من المواقع والتطبيقات وقواعد بياناتها مع اختبار استعادة دوري.

دورة حياة التطبيقات الداخلية للمجموعة (مثل تطبيقات السوق/المخابز الداخلية)

• تخضع أي فكرة لتطبيق داخلي جديد لتقييم أولي (جدوى العمل، الجمهور المستهدف، التكامل المطلوب مع ERP/POS) قبل اعتمادها كمشروع رسمي ضمن محفظة المشاريع في المجلد الثامن عشر.
• تمر دورة حياة كل تطبيق داخلي بالمراحل التالية: التخطيط والتصميم (UX/UI) ← التطوير ← الاختبار (QA/UAT) ← الإطلاق (Go-Live) ← الصيانة والدعم المستمر ← التقاعد (Retirement) عند استبداله أو زوال الحاجة إليه.
• يُخصَّص لكل تطبيق داخلي مالك منتج (Product Owner) من الإدارة المستفيدة (كالتشغيل أو التسويق)، يعمل بالتنسيق مع فريق الأنظمة المؤسسية والحلول الرقمية لتحديد الأولويات والمتطلبات وترتيبها.
• تخضع جميع التطبيقات الداخلية لنفس معايير التطوير والاختبار والنشر والتوثيق الموضحة في المجلد الرابع عشر، وتُدرَج في كتالوج الخدمات (Service Catalog) بالملاحق فور إطلاقها رسميًا.
• عند تقاعد أي تطبيق داخلي، تُؤرشَف بياناته وفق سياسة الاحتفاظ بالبيانات في المجلد الثاني والعشرين، ويُشعَر جميع المستخدمين المتأثرين بموعد التوقف قبل 30 يومًا على الأقل.

ضوابط الوصول والحماية الأساسية

• سياسة كلمات المرور: حد أدنى 12 حرفًا، مزيج من الأحرف والأرقام والرموز، تغيير كل 90 يومًا للحسابات الحساسة، وحظر إعادة استخدام آخر 5 كلمات مرور.
• تُفعَّل المصادقة متعددة العوامل (MFA) إلزاميًا لجميع الوصول عن بُعد والأنظمة الحساسة والحسابات الإدارية (Privileged Accounts).
• تُنشَر حلول الحماية من التهديدات المتقدمة (EDR/XDR) على جميع نقاط النهاية (Endpoints) مع مراقبة مركزية على مدار الساعة.

المراقبة والاستجابة للحوادث

• يُدار مركز عمليات أمنية (SOC) داخلي أو عبر مزود خدمة مُدار (MSSP)، مرتبط بنظام إدارة معلومات وأحداث الأمن (SIEM) لمراقبة الأحداث على مدار الساعة.
• تُطبَّق خطة استجابة للحوادث الأمنية (Incident Response Plan) بمراحل واضحة: الاكتشاف، الاحتواء، الاستئصال، الاستعادة، والمراجعة اللاحقة (Post-Incident Review).
• تُبلَّغ الحوادث الأمنية الحرجة إلى الإدارة التنفيذية خلال ساعة من اكتشافها، وإلى الجهات التنظيمية ذات العلاقة وفق المهل النظامية المعمول بها.

إدارة الثغرات واختبار الاختراق ومبدأ الثقة المعدومة

• يُجرى مسح دوري للثغرات الأمنية (Vulnerability Assessment) شهريًا، واختبار اختراق شامل (Penetration Testing) سنويًا على الأقل بواسطة طرف مستقل.
• تُعالَج الثغرات الحرجة خلال 7 أيام، والعالية خلال 30 يومًا، والمتوسطة خلال 90 يومًا من تاريخ اكتشافها.
• يُعتمد مبدأ الثقة المعدومة (Zero Trust) تدريجيًا: التحقق المستمر من الهوية والجهاز قبل منح الوصول لأي مورد، بغض النظر عن موقع الاتصال (داخل الشبكة أو خارجها).
• تُنشَر حلول منع تسرب البيانات (DLP) على البريد الإلكتروني ونقاط النهاية لمنع خروج البيانات الحساسة دون تفويض.

سياسة الأجهزة الشخصية وإدارة الأجهزة المحمولة (BYOD/MDM)

• يُسمح باستخدام الأجهزة الشخصية (BYOD) للوصول للبريد الإلكتروني والتطبيقات المؤسسية المحددة فقط بعد تسجيل الجهاز في نظام إدارة الأجهزة المحمولة (MDM) وتوقيع تعهد الاستخدام المقبول.
• تخضع الأجهزة المسجَّلة في MDM لضوابط إلزامية: قفل الشاشة برمز/بصمة، تشفير التخزين، وإمكانية المحو عن بُعد (Remote Wipe) للبيانات المؤسسية فقط عند فقدان الجهاز أو انتهاء خدمة الموظف.
• يُحظر تخزين بيانات العملاء أو الملفات السرية أو المصادر البرمجية على أجهزة شخصية غير مُدارة، ويُحظر ربط الأجهزة الشخصية بشبكة الشركة الداخلية (يُسمح فقط بشبكة الضيوف المعزولة أو الوصول عبر MDM).
• تُراجَع قائمة الأجهزة المسجَّلة في MDM ربع سنويًا، ويُلغى تسجيل أي جهاز غير نشط لأكثر من 90 يومًا.

الأمن الفيزيائي لغرف الخوادم ومراكز البيانات

• يُقيَّد الدخول الفعلي لغرف الخوادم بنظام تحكم دخول إلكتروني (بطاقة/بصمة) مع سجل دخول وخروج مؤرشف لا يقل عن سنة كاملة.
• تُراجَع قائمة الأشخاص المصرَّح لهم بالدخول لغرف الخوادم كل ثلاثة أشهر، ويُلغى تصريح أي شخص لم يعد بحاجة إليه فورًا.
• تُجهَّز غرف الخوادم بأنظمة إطفاء حريق مناسبة للمعدات الإلكترونية (غاز خامل أو ما يعادله)، وأنظمة تحكم بيئي (تكييف مخصص، أجهزة استشعار حرارة/رطوبة) مع تنبيهات فورية عند تجاوز الحدود الآمنة.
• يتطلب دخول أي طرف ثالث (فني صيانة، مورد) لغرف الخوادم مرافقة من موظف مصرَّح له وتوثيق الزيارة في سجل الزوار.

تصنيف خطورة الحوادث الأمنية (Incident Severity)

خارطة طريق نضج الأمن السيبراني (Maturity Roadmap)

• السنة الأولى: إتمام التقييم الذاتي لضوابط ECC، نشر EDR/XDR على جميع نقاط النهاية، تفعيل MFA الشامل، وإجراء أول اختبار اختراق شامل.
• السنة الثانية: تأسيس مركز عمليات أمنية (SOC) داخلي أو عبر مزود مُدار على مدار الساعة، تطبيق مبدأ Zero Trust تدريجيًا على الأنظمة الحرجة، والحصول على شهادة ISO 27001.
• السنة الثالثة: أتمتة الاستجابة للحوادث (SOAR)، توسيع Zero Trust لتغطية كامل البيئة، وإجراء تمارين محاكاة هجوم متقدم (Red Team) سنويًا.

سياسة الحوسبة السحابية (Cloud Policy)

• لا يُعتمَد أي مزود خدمة سحابية جديد (IaaS/PaaS/SaaS) إلا بعد تقييم أمني يشمل: موقع تخزين البيانات، شهادات الامتثال لدى المزود (ISO 27001 أو ما يعادلها)، وآلية تشفير البيانات.
• يُفضَّل بقاء البيانات الحساسة وبيانات العملاء الشخصية داخل المملكة العربية السعودية ما لم يوجد مبرر عمل واضح ومعتمد من مدير تقنية المعلومات ولجنة تقنية المعلومات لخلاف ذلك، بما يتوافق مع متطلبات PDPL.
• تخضع جميع الحسابات السحابية الإدارية (Admin/Root) للمصادقة متعددة العوامل (MFA) الإلزامية ومراجعة صلاحيات ربع سنوية.

معيار أمن بيانات صناعة بطاقات الدفع (PCI DSS)

• نظرًا لتعامل أنظمة نقاط البيع (POS) في جميع الفروع مع بيانات بطاقات الدفع، تخضع بيئة الدفع لمتطلبات معيار PCI DSS (Payment Card Industry Data Security Standard) الصادر عن مجلس معايير أمن صناعة بطاقات الدفع.
• يُحظر تخزين بيانات حامل البطاقة الحساسة (رقم البطاقة الكامل، رمز التحقق CVV، بيانات المسار المغناطيسي) داخل أي نظام محلي (ERP/POS) بعد إتمام عملية الدفع، ويُعتمَد على مزودي دفع معتمدين (Payment Gateway/Processor) متوافقين مع PCI DSS لمعالجة المعاملات.
• تُعزَل شبكة أجهزة نقاط البيع ومعدات الدفع (VLAN مخصص) عن بقية شبكة الشركة وفق ما هو موضح في المجلد العاشر، للحد من نطاق الامتثال لـPCI DSS.
• يخضع نطاق أنظمة الدفع لفحص ثغرات ربع سنوي من جهة معتمدة (Approved Scanning Vendor) حيثما تطلب ذلك مستوى الامتثال المطبَّق، ولاستبيان امتثال ذاتي سنوي (Self-Assessment Questionnaire - SAQ) بالتنسيق مع مزود خدمة الدفع.

إدارة الوصول المتميز (Privileged Access Management - PAM)

• تُدار جميع الحسابات ذات الصلاحيات المرتفعة (Domain Admin، Database Admin، Global Admin) عبر خزائن كلمات مرور مخصصة (1Password Privileged Vaults) منفصلة عن حسابات المستخدمين العاديين.
• يُمنح الوصول المتميز على أساس مؤقت ومبرَّر (Just-In-Time Privileged Access) للمهمة المحددة فقط، مع تسجيل كامل لبداية ونهاية كل جلسة استخدام صلاحية مرتفعة.
• تُراجَع قائمة الحسابات ذات الصلاحيات المرتفعة شهريًا، وتُلغى أي صلاحية مرتفعة لم تعد هناك حاجة فعلية لها.

استخبارات التهديدات وتمارين المحاكاة (Threat Intelligence & Red/Blue Team)

• يُشترَك في مصدر استخبارات تهديدات (Threat Intelligence Feed) موثوق (مجاني أو تجاري) لمتابعة أحدث أساليب الهجوم والثغرات ذات الصلة بالقطاع التجاري/التجزئة.
• يُجرى تمرين محاكاة هجوم (Red Team Exercise) سنويًا على الأقل من طرف مستقل، بينما يتولى الفريق الداخلي أو الفريق المُدار دور الفريق المدافع (Blue Team) في اكتشاف ومعالجة المحاكاة.
• تُوثَّق نتائج تمارين المحاكاة في تقرير يوضح نقاط الضعف المكتشفة وخطة معالجتها ضمن الجدول الزمني المتفق عليه.

مركز العمليات الأمنية والمراقبة المستمرة (SOC/SIEM تفصيلي)

• يُدار مركز عمليات أمنية (SOC) داخلي أو عبر مزود خدمة أمنية مُدارة (MSSP) لمراقبة الأحداث الأمنية على مدار الساعة عبر نظام SIEM مركزي يجمع سجلات الخوادم والشبكات والأجهزة الطرفية.
• تُصنَّف تنبيهات SIEM آليًا حسب الخطورة، وتُصعَّد التنبيهات الحرجة فورًا وفق تصنيف خطورة الحوادث الأمنية الموضح في هذا المجلد.
• تُراجَع قواعد الكشف (Detection Rules) في SIEM ربع سنويًا لتحديثها بما يتوافق مع أحدث أساليب الهجوم المكتشفة عبر استخبارات التهديدات.

النسخ الاحتياطي

• تُطبَّق قاعدة 3-2-1 للنسخ الاحتياطي: ثلاث نسخ من البيانات، على وسيطين مختلفين على الأقل، مع نسخة واحدة خارج الموقع (Offsite/Cloud Backup).
• تُحدَّد أهداف زمن الاستعادة (RTO) ونقطة الاستعادة (RPO) لكل نظام حسب أهميته: RTO لا يتجاوز 4 ساعات وRPO لا يتجاوز ساعة واحدة للأنظمة الحرجة (ERP، POS، البريد).
• تُختبَر عمليات الاستعادة الفعلية (Recovery Testing) دوريًا كل ثلاثة أشهر على الأقل لكل نظام حرج، وتُوثَّق النتائج.

التعافي من الكوارث واستمرارية الأعمال

• تُوثَّق خطة التعافي من الكوارث (DRP) بسيناريوهات واضحة (فقدان مركز بيانات، هجوم فدية، كارثة طبيعية) مع خطوات تنفيذية مفصلة ومسؤول لكل خطوة.
• تُختبَر خطة التعافي من الكوارث بتمرين شامل (DR Drill) سنويًا على الأقل بمشاركة جميع الفرق المعنية، وتُحدَّث الخطة بناءً على الدروس المستفادة.
• تُوثَّق خطة استمرارية الأعمال (BCP) لضمان استمرار العمليات الحيوية أثناء التعافي، بما يشمل مواقع بديلة وإجراءات يدوية مؤقتة عند الحاجة.

فريق تفعيل استمرارية الأعمال (BCP/DR Activation Team)

• يملك القرار الرسمي بإعلان «حالة كارثة» وتفعيل خطة التعافي من الكوارث (DRP) مدير تقنية المعلومات، أو من ينوب عنه رسميًا في حال غيابه (أحد مديرَي الفريقين حسب طبيعة الحادثة).
• فور تفعيل الخطة، يُشكَّل فريق تفعيل مؤقت يضم: مدير تقنية المعلومات (قيادة القرار)، مدير الفريق المعني تقنيًا (تنفيذ التعافي)، ومسؤول تواصل مؤسسي (لتنسيق التواصل الداخلي مع الإدارة التنفيذية والخارجي مع العملاء/الفروع إن لزم، بالتنسيق مع إدارة التسويق/الاتصال المؤسسي).
• يتولى مسؤول التواصل خلال الأزمة إصدار تحديثات دورية (كل ساعتين كحد أقصى أثناء الحادثة النشطة) للإدارة التنفيذية توضح الحالة الراهنة والوقت التقديري للاستعادة، لمنع تعدد مصادر المعلومات غير الرسمية.
• بعد انتهاء الحادثة واستعادة الخدمة بالكامل، يُعقد اجتماع مراجعة لاحقة (Post-Incident Review) خلال 5 أيام عمل يضم فريق التفعيل لتوثيق الدروس المستفادة وتحديث خطة DRP إذا لزم.

تحليل أثر الأعمال (Business Impact Analysis - BIA)

• يُستكمَل تصنيف الأنظمة الحرجة في هذا الدليل (RTO/RPO بالمجلد السابع عشر) بتحليل أثر الأعمال (Business Impact Analysis - BIA) رسمي يُجرى بالتنسيق مع الإدارات التشغيلية والمالية لتحديد الأثر المالي والتشغيلي التقديري لكل ساعة توقف لكل نظام حرج، ويُستخدَم هذا التحليل لتبرير أولويات الاستثمار في الاستمرارية والتعافي من الكوارث.

سيناريوهات استمرارية الأعمال وإجراءات الاستجابة التفصيلية

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

يقابل كل سيناريو من هذه السيناريوهات دليل تشغيلي تفصيلي (Runbook) بخطوات منفذة كاملة ضمن المجلد الثامن والعشرين، وهذا الجدول ملخص إداري للسيناريوهات الرئيسية فقط.

دورة حياة المشروع

• يمر كل مشروع تقني بمراحل: المبادرة والتخطيط، التنفيذ، المراقبة والتحكم، الإغلاق، مع بوابات اعتماد (Gates) بين كل مرحلة وأخرى.
• يتطلب كل مشروع ميثاق مشروع (Project Charter) معتمَد يحدد النطاق والأهداف والميزانية والجدول الزمني والمخاطر الأولية ومالك المشروع.
• تُدار مخاطر المشروع عبر سجل مخاطر خاص به يُراجَع في كل اجتماع متابعة، مع خطط تخفيف لكل مخاطرة عالية الأثر.

المتابعة والإغلاق

• تُعقد اجتماعات متابعة أسبوعية للمشاريع النشطة، وتُرفع تقارير حالة (Status Reports) شهرية للجنة تقنية المعلومات.
• يتطلب الانتقال للتشغيل الفعلي (Go-Live) اعتمادًا رسميًا من مالك المشروع وفريق العمليات بعد التحقق من جاهزية الدعم والتوثيق.
• يُعقد اجتماع دروس مستفادة (Lessons Learned) عند إغلاق كل مشروع وتُوثَّق النتائج في قاعدة المعرفة لتحسين المشاريع المستقبلية.

الوثائق الإلزامية لكل مشروع تقني (Mandatory Project Documentation)

لا يُعتمَد انتقال أي مشروع تقني بين مراحله الرئيسية، ولا سيما الانتقال للتشغيل الفعلي (Go-Live)، دون اكتمال الوثائق الإلزامية المرتبطة بتلك المرحلة والتحقق منها من قِبل مدير المشروع، وفق الجدول التالي:

طلب التغيير والاعتماد

• يُقدَّم كل تغيير مخطط له عبر نموذج طلب تغيير (RFC) يتضمن: الوصف، السبب، الأثر المتوقع، خطة التنفيذ، وخطة التراجع (Rollback Plan).
• تُصنَّف التغييرات إلى: عادية (تمر عبر مجلس اعتماد التغيير CAB)، طارئة (Emergency Change، تتطلب اعتمادًا سريعًا من مدير تقنية المعلومات مع توثيق لاحق)، وبسيطة (Standard، مسبقة الاعتماد ومتكررة).
• يجتمع مجلس اعتماد التغيير (CAB) أسبوعيًا لمراجعة واعتماد طلبات التغيير متوسطة وعالية الأثر.

التنفيذ والتوثيق

• يخضع كل تغيير لاختبار في بيئة غير إنتاجية قبل التنفيذ في بيئة الإنتاج، باستثناء الحالات الطارئة الموثقة والمبررة.
• يُنفَّذ كل تغيير ضمن نافذة صيانة معتمدة، مع فريق مراقبة جاهز لتفعيل خطة التراجع فور رصد أي مشكلة.
• يُوثَّق كل تغيير بعد التنفيذ في سجل التغييرات (Change Log) مع تحديث الوثائق الفنية المرتبطة (CMDB، خرائط الشبكة، أدلة التشغيل).

فترات تجميد التغييرات في المواسم التجارية الحرجة (Change Freeze)

• تُحدَّد سنويًا فترات تجميد للتغييرات غير الحرجة على أنظمة ERP وLS Retail ونقاط البيع والشبكة، تغطي مواسم الذروة التجارية للمجموعة (مثل شهر رمضان، موسم العودة إلى المدارس، نهاية السنة المالية والجرد السنوي، والأعياد الوطنية والدينية الرئيسية).
• خلال فترة التجميد، لا يُسمح بأي تغيير من الفئة العادية (Normal Change) إلا بعد موافقة استثنائية من مدير تقنية المعلومات شخصيًا، بينما تبقى التغييرات الطارئة (Emergency Change) لمعالجة الأعطال الحرجة مسموحة دائمًا وفق إجرائها المعتمد في هذا المجلد.
• تُعمَّم قائمة فترات التجميد المعتمدة لهذا العام على جميع أعضاء إدارة تقنية المعلومات والموردين المعنيين (بما فيهم شريك ERP) قبل بداية كل فترة بأسبوعين على الأقل.
• يُفضَّل جدولة أي ترقية كبرى للأنظمة أو تحديثات رئيسية (Major Upgrades) خارج نطاق فترات التجميد بفارق زمني كافٍ (شهر على الأقل) لضمان استقرار الأنظمة قبل بداية الموسم.

سياسة نوافذ الصيانة وإشعار المستخدمين (Maintenance Window & User Notification)

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

اختيار وتقييم الموردين

• يخضع اختيار أي مورد جديد لمقارنة فنية ومالية موثقة، مع التحقق من السجل التجاري والمرجعيات (References) قبل التعاقد.
• يُقيَّم أداء كل مورد رئيسي سنويًا وفق معايير: جودة الخدمة، الالتزام بـ SLA، الدعم الفني، والتنافسية السعرية، وتُوثَّق النتيجة في سجل تقييم الموردين.
• تُحدَّد اتفاقيات مستوى خدمة (SLA) واضحة في كل عقد رئيسي تشمل زمن الاستجابة، زمن الحل، والغرامات عند الإخلال.

المتابعة والتصعيد وتجديد العقود

• تُعقد اجتماعات مراجعة دورية (ربع سنوية على الأقل) مع الموردين الاستراتيجيين لمراجعة الأداء والمشاكل المتكررة.
• يُحدَّد مسار تصعيد واضح (Escalation Matrix) لكل مورد رئيسي يشمل نقاط اتصال متعددة المستويات عند تعثر الخدمة.
• تُراجَع العقود قبل 90 يومًا من تاريخ انتهائها لاتخاذ قرار التجديد أو إعادة التفاوض أو استبدال المورد.

خطة الخروج من الموردين ومنع الارتهان التقني (Exit Plan / Anti Vendor Lock-in)

• يتطلب كل عقد مع مورد إستراتيجي (ERP، الاستضافة، الأمن السيبراني المُدار) بندًا تعاقديًا صريحًا يوضح آلية تصدير البيانات وتسليمها للشركة بصيغة قابلة للاستخدام (غير مقيدة بصيغة خاصة بالمورد) عند إنهاء التعاقد.
• يُعَدّ تقييم مخاطر الارتهان التقني (Vendor Lock-in Risk Assessment) عند التعاقد مع أي مورد جديد لأنظمة حرجة، يوضح مدى صعوبة الانتقال لمورد بديل ومدة وتكلفة ذلك التقديرية.
• تُحفَظ نسخة احتياطية دورية من البيانات المستضافة لدى الموردين الخارجيين (السحابة، الأنظمة المُدارة) بصيغة مستقلة عن بيئة المورد، ضمن سياسة النسخ الاحتياطي العامة في المجلد السابع عشر.
• يخضع كل مورد إستراتيجي لخطة خروج موثقة (Exit Plan) تُراجَع عند التعاقد وتُحدَّث كل سنتين، توضح الخطوات العملية للانتقال لمورد بديل أو للتشغيل الداخلي دون توقف كبير للخدمة.

بطاقة تقييم الموردين الدورية (Vendor Scorecard) وسجل الاجتماعات

يُوثَّق كل اجتماع مراجعة مع أي مورد رئيسي في سجل اجتماعات الموردين (Vendor Meeting Log) يتضمن: التاريخ، الحضور، النقاط المطروحة، القرارات المتخذة، والمهام المتابَعة وموعد إنجازها، ويُحتفَظ بهذا السجل لمدة سنتين على الأقل لدعم أي تقييم أو تفاوض مستقبلي مع المورد.

سجل الموردين والشركاء التقنيين الرئيسيين (Vendor Registry)

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

يُصنَّف كل مورد حسب مستوى الأهمية لتحديد أولوية المتابعة والمراجعة؛ الموردون «الحرجون» يخضعون لمراجعة أداء وSLA أكثر تكرارًا من الموردين «العاديين».

المسار الإجرائي للشراء

• يبدأ أي طلب شراء تقني بنموذج طلب شراء معتمد من مدير الفريق المعني، مرفقًا به المبرر التقني ومقارنة فنية عند الحاجة.
• تخضع المشتريات التي تتجاوز حدًا ماليًا معينًا (يُحدَّد وفق سياسة الشركة المالية) لثلاث عروض أسعار مقارنة على الأقل قبل الاعتماد.
• يُصدَر أمر الشراء الرسمي بعد اعتماد الإدارة المالية، وتُتابَع حالته حتى الاستلام الفعلي والتسجيل في CMDB.
• تخضع الأصول المستلمة للفحص الفني قبل التسليم النهائي للمستخدم، للتأكد من مطابقتها للمواصفات المطلوبة وتفعيل الضمان.

حوكمة وتصنيف البيانات

• تُصنَّف البيانات إلى أربع فئات: عامة، داخلية، سرية، سرية للغاية، ويُحدَّد لكل فئة ضوابط وصول ومعالجة وتخزين مختلفة.
• تُحدَّد بيانات مرجعية أساسية (Master Data) لكل نظام (العملاء، الموردين، الأصناف) مع مالك بيانات (Data Owner) مسؤول عن دقتها واكتمالها.
• تُجرى مراجعات دورية لجودة البيانات (Data Quality Checks) للكشف عن التكرار أو النقص أو التعارض، مع خطة تصحيح.

الاحتفاظ والأرشفة والحذف الآمن

• تُحدَّد فترة احتفاظ لكل نوع بيانات وفق المتطلبات النظامية والتشغيلية، وتُؤرشَف البيانات التي تجاوزت فترة الاستخدام النشط.
• يخضع حذف البيانات الحساسة، سواء الرقمية أو المخزنة على وسائط فعلية، لإجراء حذف آمن (Secure Deletion) موثَّق يمنع إمكانية الاسترجاع.

سياسة الطباعة والمستندات الورقية الحساسة

• يُقتصَر طباعة المستندات المصنَّفة (سرية/سرية للغاية وفق تصنيف البيانات في هذا المجلد) على الحد الأدنى الضروري لإتمام العمل، مع تفضيل التداول الرقمي الآمن كلما أمكن.
• تُستلَم المطبوعات الحساسة فور طباعتها من الطابعة مباشرة، ويُحظر تركها دون استلام في صواني الطباعة المشتركة.
• تخضع الطابعات متعددة الوظائف المشتركة لضبط ميزة الطباعة الآمنة (Secure Print/Pull Printing) حيثما توفرت، بحيث لا تُطبع المستندات إلا بعد مصادقة الموظف عند الجهاز.
• تُتلَف المستندات الورقية الحساسة التي لم تعد هناك حاجة لها عبر آلة تمزيق معتمدة (Cross-Cut Shredder) وليس عبر رميها في سلة المهملات العادية.

جدول مدة الاحتفاظ بالبيانات حسب النوع

يوضح الجدول التالي مدة الاحتفاظ الإرشادية لأهم أنواع البيانات والسجلات التي تدير أو تحتفظ بها إدارة تقنية المعلومات، تمييزًا عن السجلات المالية والمحاسبية التي تخضع لمدد الاحتفاظ التي تحددها الأنظمة السعودية ذات العلاقة (نظام الشركات ونظام مزاولة المحاسبة) وتُدار بالتنسيق مع الإدارة المالية.

حوكمة الاستخدام

• يخضع اعتماد أي أداة أو نظام ذكاء اصطناعي جديد لمراجعة أمنية وقانونية قبل النشر، تشمل تقييم مخاطر الخصوصية والانحياز (Bias) والدقة.
• يُحدَّد الاستخدام المسموح (تحليل البيانات، الأتمتة، دعم القرار، خدمة العملاء) والمحظور (اتخاذ قرارات نهائية حساسة دون مراجعة بشرية، معالجة بيانات شخصية حساسة دون ضوابط) في سياسة واضحة يوقّع عليها كل مستخدم.
• تخضع جميع مخرجات أنظمة الذكاء الاصطناعي المستخدمة في قرارات العمل لمراجعة بشرية إلزامية قبل الاعتماد النهائي.

ضوابط الخصوصية

• يُحظر تزويد أي نظام ذكاء اصطناعي خارجي (غير مستضاف داخليًا أو غير معتمد مؤسسيًا) ببيانات شخصية للعملاء أو الموظفين أو بيانات مالية حساسة.
• تُراجَع أنظمة الذكاء الاصطناعي المستخدمة سنويًا للتأكد من استمرار دقتها وعدالتها وتوافقها مع السياسات المحدَّثة.

افتتاح فرع جديد

• يبدأ تجهيز الفرع التقني قبل 30 يومًا من موعد الافتتاح المخطط، وفق قائمة تحقق موحدة (Branch Readiness Checklist) تغطي: الشبكة، نقاط البيع، الكاميرات، الطابعات، والاتصال بالمقر الرئيسي.
• يُشرف مهندس حلول التجزئة الميداني بالتنسيق مع مهندس الشبكات على تركيب واختبار جميع الأنظمة قبل موعد الافتتاح بثلاثة أيام عمل على الأقل.
• يُنفَّذ اختبار تشغيلي كامل (End-to-End Test) لجميع الأنظمة (POS، الشبكة، الاتصال بـ ERP) قبل الاعتماد النهائي لفتح الفرع.
• يخضع تدريب موظفي الفرع الجدد على أنظمة نقاط البيع لجلسة تدريبية إلزامية قبل يوم الافتتاح.

إغلاق فرع

• عند إغلاق أي فرع، تُنفَّذ قائمة تحقق معاكسة تشمل: نسخ احتياطي أخير للبيانات المحلية، إلغاء تسجيل الأصول ونقلها أو إتلافها، وإلغاء اتصالات الشبكة والإنترنت الخاصة بالفرع.

مبدأ التواصل عبر التسلسل الإداري (Chain-of-Command Communication)

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

سياسة تلقي المهام والأوامر عبر التسلسل الإداري حصريًا

• لا يجوز لأي موظف في إدارة تقنية المعلومات تلقي أو تنفيذ أي عمل أو مهمة أو أمر تشغيلي إلا من مديره المباشر أو رئيس القسم (مدير تقنية المعلومات)؛ ويُعَدّ تنفيذ أي عمل بناءً على توجيه من أي جهة أخرى خارج هذا التسلسل الإداري المباشر مخالفة تُعامَل كتقصير في أداء الواجب الوظيفي.
• في حال تلقي الموظف طلب عمل من جهة خارج تسلسله الإداري المباشر (كإدارة أخرى أو زميل من فريق مختلف أو حتى مسؤول تنفيذي لا يُعَدّ مديره المباشر)، فإنه غير مخوَّل بالبدء في تنفيذه إلا بعد الرجوع لمديره المباشر أو رئيس القسم وحصوله على تكليف أو موافقة صريحة بذلك.
• الاستثناء الوحيد على ما سبق هو الحالات الطارئة الحقيقية التي تهدد استمرارية الأعمال أو سلامة الأنظمة (كحادثة نظام حرجة) والتي تستوجب تدخلًا فوريًا لا يحتمل التأخير؛ وحتى في هذه الحالة، يبقى الموظف ملزَمًا بإبلاغ مديره المباشر أو رئيس القسم بالأمر قبل الشروع في المعالجة كلما كان ذلك ممكنًا عمليًا، أو فور الشروع فيها مباشرة إن تعذّر الإبلاغ المسبق، وذلك اتساقًا مع مبدأ التسلسل الإداري الموضح في المجلد الخامس والعشرين وسياسة العمل الإضافي في هذا المجلد.
• يُعَدّ تنفيذ أي عمل دون الرجوع للمدير المباشر أو رئيس القسم (في غير الحالات الطارئة الموضحة أعلاه)، أو دون إبلاغه في الحالات الطارئة، تقصيرًا في أداء الواجب الوظيفي يخضع لسياسة الانضباط والجزاءات الموضحة في هذا المجلد، بصرف النظر عن جودة أو صحة العمل المنفَّذ.
• الهدف من هذه السياسة حماية الموظف من تضارب التوجيهات والتنفيذ غير المصرَّح به، وضمان أن كل عمل منفَّذ داخل إدارة تقنية المعلومات معروف ومُتابَع من جهة إشراف واحدة واضحة، بما يحفظ جودة العمل ويحدد المسؤولية بدقة عند أي مراجعة لاحقة.

قنوات ومستويات التصعيد

• تُعتمد قنوات تواصل رسمية موحدة (نظام التذاكر للطلبات الروتينية، البريد الإلكتروني للمراسلات الرسمية، اتصال هاتفي/تطبيق للحالات الحرجة) مع كل إدارة (المالية، الموارد البشرية، المشتريات، التسويق، التشغيل، المستودعات، الفروع).
• يُحدَّد مصفوفة تصعيد بثلاثة مستويات لكل نوع تواصل: المستوى التشغيلي (فريق الدعم)، المستوى الإشرافي (مدير الفريق)، المستوى التنفيذي (مدير تقنية المعلومات) للحالات الحرجة التي تتجاوز أربع ساعات دون حل.
• تُعقد اجتماعات تنسيق دورية مع الإدارات ذات التعامل المكثف (التشغيل، المالية، الفروع) لمراجعة الاحتياجات والمشاريع المشتركة.

التقارير الدورية ولوحات المعلومات

• تُصدَر تقارير يومية وأسبوعية وشهرية وسنوية تغطي: الأداء التشغيلي، الحوادث، المشاريع، والميزانية، وتُوزَّع على الجهات المعنية حسب مستوى التفصيل المناسب.
• لوحة المعلومات التنفيذية (Executive Dashboard) تعرض ملخصًا شاملًا لصحة الخدمات، حالة المشاريع، والمخاطر الحرجة للإدارة التنفيذية.
• لوحة معلومات تقنية المعلومات (IT Dashboard) تعرض مؤشرات الأداء التشغيلية اليومية (توافر الأنظمة، حالة التذاكر، السعة).
• لوحة الأمن السيبراني (Cybersecurity Dashboard) تعرض التنبيهات الأمنية، حالة الثغرات، ونتائج المراقبة المستمرة.
• لوحتا ERP والمشاريع (ERP Dashboard وProject Dashboard) تعرضان حالة الأنظمة المؤسسية وتقدم المشاريع النشطة مقابل الخطة الزمنية والميزانية.

لوحة معلومات الإدارة التنفيذية (Executive Dashboard) — مواصفة المحتوى

تُصمَّم لوحة معلومات تنفيذية (عبر Power BI أو أداة مماثلة) تُعرَض شهريًا وربع سنويًا للإدارة التنفيذية، وتتضمن البطاقات التالية كحد أدنى:

• حالة المشاريع الإستراتيجية ونسبة الإنجاز مقابل الجدول الزمني المعتمد.
• حالة توافر نظام ERP والأنظمة الحرجة (Uptime%) خلال آخر 30 يومًا.
• حالة الفروع (عدد الفروع المتصلة بشكل طبيعي مقابل الفروع ذات الأعطال النشطة).
• ملخص المخاطر التقنية الحرجة المفتوحة من سجل المخاطر.
• حالة العقود الرئيسية (الموردون وشريك ERP) والعقود المقتربة من التجديد خلال 90 يومًا.
• ملخص الوضع الأمني (عدد الحوادث الأمنية حسب الخطورة، حالة الامتثال).
• ملخص الإنفاق التقني الفعلي مقابل الميزانية المعتمدة (CAPEX/OPEX) والانحراف.
• ملخص مؤشرات الأداء الرئيسية (KPI) العامة لإدارة تقنية المعلومات (راجع لوحة KPI أدناه للتفصيل الكامل).

لوحة مؤشرات الأداء التشغيلية (KPI Dashboard) — مواصفة المحتوى

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

قائمة النماذج المعتمدة

• نماذج الطلبات: طلب خدمة، طلب جهاز، طلب برنامج، طلب صلاحية، طلب بريد إلكتروني، طلب VPN، طلب مشروع، طلب تغيير (RFC)، طلب شراء.
• نماذج العهدة والتسليم: نموذج استلام عهدة، نموذج تسليم عهدة — يوثقان الأصل والمستخدم والتاريخ وحالة الجهاز وتوقيع الطرفين.
• نماذج الحوادث والتقييم: تقرير حادث، تقرير أعطال، محضر اجتماع، تقييم مورد، قبول نظام (Sign-off)، تقييم مخاطر.
• يخضع كل نموذج لدورة اعتماد محددة (مقدّم الطلب ← المدير المباشر ← الجهة التقنية المعنية) ويُحتفَظ بسجل إلكتروني قابل للتدقيق لكل نموذج معبَّأ.

كتالوج النماذج الموسّع (نحو 250+ نموذجًا مُدارًا إلكترونيًا)

بالإضافة إلى النماذج الأساسية الموضحة سابقًا في هذا المجلد، تُدار إدارة تقنية المعلومات كتالوجًا إلكترونيًا موسّعًا من النماذج ضمن نظام التذاكر/Workflow الموحد، مبنيًا على القوالب الأساسية التالية مضروبة عبر الأنظمة والبيئات والأدوار المختلفة (مثلًا: «طلب صلاحية» يتكرر كنموذج مستقل لكل نظام من الأنظمة الاثني عشر الرئيسية: AD، البريد، ERP، LS Retail، قاعدة البيانات، VPN، الواي فاي، 1Password، الخادم، جهاز الشبكة، الكاميرات، وAPI)؛ وبضرب هذا المنطق عبر الفئات العشر التالية يتجاوز إجمالي النماذج المُدارة فعليًا 250 نموذجًا، دون الحاجة لتوثيق كل نسخة ورقيًا بشكل منفصل.

يُدار كتالوج النماذج الكامل والمحدَّث إلكترونيًا ضمن نظام التذاكر/Workflow المعتمد لدى الإدارة، وتُراجَع قائمة النماذج سنويًا لإضافة أي نموذج جديد يستجد أو دمج/إلغاء أي نموذج لم يعد مستخدَمًا.

RB-09-01: إنشاء حساب مستخدم جديد

الغرض: تجهيز حساب مستخدم جديد في Active Directory/Azure AD مع الصلاحيات والبريد الإلكتروني المناسبين لدوره الوظيفي.

المتطلبات المسبقة

• نموذج طلب مستخدم جديد معتمد من المدير المباشر والموارد البشرية.
• تحديد القسم والدور الوظيفي والمجموعات المطلوبة.

خطوات التنفيذ

1. التحقق من اكتمال واعتماد نموذج الطلب في نظام التذاكر.
2. إنشاء الحساب في Active Directory وفق معيار التسمية المعتمد (الاسم الأول.اسم العائلة).
3. إضافة المستخدم إلى مجموعات الأمان (Security Groups) المطابقة لدوره الوظيفي فقط (مبدأ أقل صلاحية).
4. إنشاء صندوق البريد الإلكتروني وتفعيل المصادقة متعددة العوامل (MFA).
5. تجهيز الجهاز وتسجيله في CMDB وربطه بالمستخدم.
6. تسليم بيانات الدخول للمستخدم عبر قناة آمنة وتوثيق تغيير كلمة المرور عند أول دخول.

✅ التحقق: تسجيل دخول تجريبي من المستخدم للتحقق من الوصول للبريد والأنظمة المطلوبة.

↩️ خطة التراجع: في حال وجود خطأ في الصلاحيات، تُعطَّل المجموعة الخاطئة فورًا ويُعاد ضبط الصلاحيات الصحيحة.

جهة التصعيد: منسق عمليات تقنية المعلومات ← مدير فريق العمليات والخدمات التقنية.

RB-12-04: استعادة قاعدة بيانات من نسخة احتياطية

الغرض: استعادة قاعدة بيانات SQL Server من نسخة احتياطية عند فقدان أو تلف البيانات.

المتطلبات المسبقة

• تحديد آخر نسخة احتياطية سليمة وتاريخها.
• موافقة مدير الفريق على تنفيذ الاستعادة (خاصة في بيئة الإنتاج).
• إشعار المستخدمين المتأثرين بتوقف الخدمة المؤقت.

خطوات التنفيذ

1. إيقاف الاتصالات النشطة بقاعدة البيانات المتأثرة بشكل آمن.
2. التحقق من سلامة ملف النسخة الاحتياطية قبل بدء الاستعادة.
3. تنفيذ عملية الاستعادة (Restore) على الخادم المستهدف مع مراقبة السجلات أثناء التنفيذ.
4. استعادة سجلات المعاملات (Transaction Logs) اللاحقة إن وجدت للوصول لأحدث نقطة ممكنة.
5. التحقق من سلامة البيانات المستعادة (Consistency Check) عبر أوامر DBCC.
6. إعادة تفعيل الاتصالات وإشعار المستخدمين والفرق المعنية باكتمال الاستعادة.

✅ التحقق: مطابقة عينة من البيانات المستعادة مع آخر تقرير معروف صحيح قبل الحادثة.

↩️ خطة التراجع: الاحتفاظ بنسخة من قاعدة البيانات التالفة قبل الاستعادة لأي تحليل لاحق للسبب الجذري.

جهة التصعيد: مهندس دعم البنية التحتية ← مدير فريق العمليات والخدمات التقنية ← مدير تقنية المعلومات (إذا تجاوزت مدة التعافي RTO المحدد).

RB-16-07: الاستجابة الأولية لحادثة فدية إلكترونية (Ransomware)

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

المتطلبات المسبقة

• توفر خطة الاستجابة للحوادث المعتمدة.
• قائمة اتصال بفريق الأمن السيبراني والإدارة التنفيذية.

خطوات التنفيذ

1. عزل الجهاز/الخادم المصاب فورًا عن الشبكة (فصل كابل الشبكة أو تعطيل المنفذ) دون إيقاف تشغيله لحفظ الأدلة الجنائية.
2. إشعار فريق الأمن السيبراني ومدير تقنية المعلومات فورًا (خلال 15 دقيقة من الاكتشاف).
3. تحديد نطاق الإصابة عبر أدوات EDR/XDR وتحديد الأنظمة والملفات المتأثرة.
4. تعطيل الحسابات التي قد تكون مخترقة مؤقتًا ريثما يتم التحقق منها.
5. عزل النسخ الاحتياطية غير المتأثرة والتأكد من سلامتها قبل أي استخدام.
6. إبلاغ الإدارة التنفيذية والجهات التنظيمية ذات العلاقة وفق المهل النظامية إذا تأكدت الإصابة.
7. بدء إجراءات الاستعادة من نسخ احتياطية نظيفة فقط بعد التأكد من إزالة التهديد بالكامل.

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

↩️ خطة التراجع: لا يُعاد ربط أي نظام بالشبكة إلا بعد اعتماد فريق الأمن السيبراني رسميًا.

جهة التصعيد: فريق الأمن السيبراني/SOC ← مدير تقنية المعلومات ← الإدارة التنفيذية فورًا لأي حادثة مؤكدة.

RB-24-02: تجهيز البنية التحتية التقنية لفرع جديد

الغرض: ضمان جاهزية جميع الأنظمة التقنية للفرع الجديد قبل موعد الافتتاح الرسمي.

المتطلبات المسبقة

• تحديد موعد الافتتاح المخطط وموقع الفرع.
• توفر تصميم الشبكة والمخطط الكهربائي للموقع.

خطوات التنفيذ

1. زيارة ميدانية لتقييم الموقع وتحديد متطلبات الشبكة والكهرباء والتوصيلات قبل 30 يومًا من الافتتاح.
2. تركيب معدات الشبكة (Router/Switch/Access Points) وربطها بخط الاتصال (WAN/VPN) بالمقر الرئيسي.
3. تركيب وتهيئة أجهزة نقاط البيع (POS) والموازين وربطها بنظام LS Retail/ERP.
4. تركيب أنظمة الكاميرات (CCTV) وأجهزة البصمة والطابعات.
5. تنفيذ اختبار تشغيلي شامل (End-to-End) لجميع الأنظمة قبل ثلاثة أيام من الافتتاح.
6. تدريب موظفي الفرع على أنظمة نقاط البيع والدعم الأساسي.
7. الحصول على اعتماد نهائي (Sign-off) من مدير فريق العمليات قبل تأكيد جاهزية الفرع لفريق التشغيل.

✅ التحقق: قائمة تحقق جاهزية الفرع (Branch Readiness Checklist) موقّعة ومكتملة 100%.

↩️ خطة التراجع: في حال وجود أي بند غير مكتمل حرج (مثل عدم استقرار الاتصال)، يُؤجَّل تأكيد الجاهزية حتى المعالجة الكاملة.

جهة التصعيد: مهندس حلول التجزئة ← مدير فريق العمليات والخدمات التقنية ← مدير تقنية المعلومات.

RB-19-03: تنفيذ تغيير طارئ (Emergency Change)

الغرض: معالجة عطل حرج يتطلب تغييرًا فوريًا في البيئة الإنتاجية خارج دورة اعتماد التغيير الاعتيادية.

المتطلبات المسبقة

• تأكيد أن الحالة تستوفي معايير التغيير الطارئ (توقف خدمة حرجة أو خطر أمني وشيك).
• موافقة شفهية/فورية من مدير تقنية المعلومات.

خطوات التنفيذ

1. توثيق وصف موجز للمشكلة والتغيير المقترح ومبرر الاستعجال في نموذج RFC (يُكمَّل بالتفصيل لاحقًا).
2. الحصول على اعتماد فوري من مدير تقنية المعلومات أو من ينوب عنه.
3. تنفيذ التغيير مع مراقبة مباشرة من فريق ثانٍ (Peer Monitoring) لرصد أي أثر جانبي.
4. التحقق الفوري من استقرار الخدمة بعد التنفيذ.
5. استكمال توثيق نموذج RFC بالكامل خلال 24 ساعة وعرضه على مجلس اعتماد التغيير (CAB) في أقرب اجتماع للتصديق اللاحق.

✅ التحقق: عودة الخدمة المتأثرة إلى حالتها الطبيعية دون ظهور أعطال جديدة خلال 24 ساعة من التنفيذ.

↩️ خطة التراجع: تفعيل خطة التراجع المعدة سلفًا للتغييرات الشائعة، أو الاستعادة من آخر نسخة مستقرة معروفة.

جهة التصعيد: فريق التشغيل المنفذ ← مدير الفريق المعني ← مدير تقنية المعلومات.

1. علي الطرابلسي — مدير تقنية المعلومات

IT Manager · المستوى 5 — رئيس/مدير قسم تقنية المعلومات

الفريق: الإدارة العامة لتقنية المعلومات  |  يتبع إلى: الإدارة التنفيذية / الرئيس التنفيذي

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

المهام الرئيسية

• بناء واعتماد الخطة الإستراتيجية والخطة التشغيلية السنوية لإدارة تقنية المعلومات ومتابعة تنفيذها.
• الإشراف المباشر على مديرَي الفريقين (العمليات والخدمات التقنية، والأنظمة المؤسسية والحلول الرقمية) ومتابعة أدائهما.
• اعتماد السياسات والإجراءات والصلاحيات ومصفوفة RACI الخاصة بالإدارة، وتحديثها دوريًا.
• إدارة ميزانية تقنية المعلومات (CAPEX/OPEX) والتفاوض على العقود الرئيسية مع الموردين والشركاء.
• رفع التقارير التنفيذية الدورية لمجلس الإدارة/اللجنة التنفيذية حول حالة الخدمات والمشاريع والمخاطر.
• قيادة برامج التحول الرقمي وإدارة المخاطر التقنية والامتثال لمعايير ITIL وISO 27001 وISO 20000.
• اعتماد خطط استمرارية الأعمال والتعافي من الكوارث ومراجعتها سنويًا على الأقل.
• تمثيل إدارة تقنية المعلومات أمام الإدارة التنفيذية ومجلس الإدارة بصفته المرجع التقني الأعلى في المجموعة، وتقديم رؤية تقنية واضحة تدعم أهداف النمو والتوسع.
• قيادة تقييم وتبني التقنيات الناشئة (الذكاء الاصطناعي، الأتمتة، الحوسبة السحابية) بما يخدم أولويات العمل ويحافظ على قدرة تنافسية للمجموعة.
• بناء وقيادة خطة تطوير القدرات الداخلية للفريق (مسارات الترقية، التدريب، الشهادات المهنية) تمهيدًا لنمو الهيكل التنظيمي دون الاعتماد المفرط على التوظيف الخارجي.
• إدارة العلاقة الإستراتيجية مع الشركاء التقنيين الرئيسيين (شريك ERP، مزودو الأمن السيبراني، مزودو البنية التحتية السحابية) على مستوى تنفيذي.
• رعاية مبادرات التحول الرقمي كراعٍ تنفيذي (Executive Sponsor)، وضمان مواءمتها مع خارطة الطريق التقنية وميزانية المجموعة.
• المساءلة النهائية أمام الإدارة التنفيذية عن وضع الأمن السيبراني والامتثال والمخاطر التقنية للمجموعة ككل.

🤝 يتقاطع عمله مع جميع الإدارات (المالية، الموارد البشرية، المشتريات، التشغيل، التسويق، الفروع) بصفته الجهة المسؤولة عن جميع الأصول والخدمات والمخاطر التقنية في المجموعة.

2. حسين البحراني — مدير فريق العمليات والخدمات التقنية

Technology Operations & Services Manager · المستوى 4 — مدير فريق

الفريق: فريق العمليات والخدمات التقنية (OPS)  |  يتبع إلى: مدير تقنية المعلومات

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

المهام الرئيسية

• الإشراف اليومي على فريق الشبكات والبنية التحتية والدعم الفني وحلول التجزئة.
• متابعة مؤشرات الأداء التشغيلية (SLA/KPI) لخدمة الدعم الفني وإدارة الحوادث والمشاكل.
• التخطيط لسعة البنية التحتية (Capacity Planning) وجدولة أعمال الصيانة الوقائية.
• الإشراف على تجهيز البنية التحتية للفروع الجديدة والتحقق من جاهزيتها قبل الافتتاح.
• إدارة العلاقة مع موردي الشبكات والاتصالات ومزودي خدمة الإنترنت، ومتابعة سجل الموردين الرئيسيين.
• التنسيق مع مدير تقنية المعلومات في خطط استمرارية الأعمال والتعافي من الكوارث، وقيادة تفعيل السيناريوهات عند الحاجة.
• اعتماد جدول التناوب الاحتياطي الأسبوعي لفريق العمليات، والتأكد من استيفاء البديل المعيَّن للحد الأدنى من المهارات المطلوبة عند التعيين الطارئ.
• الإشراف على إدارة البنية التحتية الهجينة (الخوادم المحلية وخوادم Contabo السحابية) والتأكد من اتساق سياسات النسخ الاحتياطي بينهما.
• مراجعة أداء فريق العمليات وتقييمهم الدوري، وتحديد احتياجات التدريب والتأهيل ضمن خريطة تأهيل الكوادر.
• اعتماد طلبات العمل الإضافي الميداني لفريق العمليات ومراجعة سجلها الشهري.
• متابعة تنفيذ دورة تحديث واستبدال الأجهزة (Technology Refresh) لأصول الفريق، ورفع مقترحات الميزانية الرأسمالية المرتبطة.

🤝 يتعاون مباشرة مع فريق الأنظمة المؤسسية في حالات الحوادث الحرجة وافتتاح الفروع وضمان توافر البنية التحتية لأنظمة ERP وPOS.

3. محمود — مهندس الشبكات والبنية التحتية والاتصالات

Network, Infrastructure & Telecommunications Engineer · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق العمليات والخدمات التقنية (OPS)  |  يتبع إلى: مدير فريق العمليات والخدمات التقنية

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

المهام الرئيسية

• تصميم وتنفيذ وإدارة البنية التحتية للشبكات بجميع الفروع (Routers/Switches/Access Points)، وإنشاء وإدارة شبكات VLAN، وإدارة بروتوكولات Layer 2/3 وRouting/Switching وSTP/RSTP وLACP وEtherChannel لضمان استقرار الشبكة.
• إدارة خدمات DHCP وDNS وNTP وSNMP، ومراقبة أداء الشبكة (استهلاك النطاق الترددي، زمن الاستجابة، فقدان الحزم) وتشخيص الأعطال الفنية ومعالجتها لمنع تكرارها.
• تنفيذ الصيانة الوقائية والدورية لمكونات الشبكة، تحديث Firmware أجهزة الشبكة وفق خطة الصيانة، والاحتفاظ بنسخ احتياطية من إعدادات الأجهزة واستعادتها عند الحاجة.
• تطبيق سياسات أمن الشبكات، إدارة الجدران النارية (Firewalls) وسياسات التحكم بالوصول، وإعداد وإدارة شبكات VPN لربط الفروع وتأمين الوصول عن بُعد، ومتابعة السجلات الأمنية وتحليل الأحداث غير الطبيعية.
• تصميم وتنفيذ وإدارة مشاريع ربط الفروع (P2P وVPN)، ومتابعة أداء واستقرار الربط، ومعالجة أعطال خطوط الاتصال بالتنسيق مع مزودي الخدمة، وإدارة عقود الإنترنت والاتصالات الخاصة بالفروع.
• تصميم وتنفيذ وإدارة أنظمة كاميرات المراقبة (CCTV) بالكامل: تركيب كاميرات IP وأجهزة DVR/NVR وبرمجتها، ضبط إعدادات التسجيل والعرض والتخزين، مراقبة الحالة التشغيلية والسعة التخزينية، والتنسيق مع الموردين للصيانة والاستبدال.
• إدارة وتشغيل وصيانة أنظمة السنترال والاتصالات الهاتفية (PBX IP): إضافة وتعديل المستخدمين والأرقام الداخلية، إعداد الرد الآلي (IVR) والمجموعات الهاتفية وصفوف الانتظار، متابعة جودة المكالمات، والتنسيق مع مزودي خدمات SIP Trunk.
• إعداد وتحليل تقارير الاتصالات (المكالمات اليومية والأسبوعية والشهرية، الواردة/الصادرة/الفائتة) ومؤشرات الأداء، وإعداد لوحات المتابعة للإدارة.
• الإشراف على مشاريع التوسعات التقنية للفروع الجديدة: دراسة الاحتياجات، إعداد المواصفات الفنية وجداول الكميات وطلبات الشراء، الإشراف على التنفيذ مع الموردين والمقاولين، وإجراء الاختبارات الفنية والاستلام النهائي.
• إعداد وتحديث كامل الوثائق الفنية (مخططات الشبكات، سجلات عناوين IP، توزيع الأجهزة)، ومتابعة عقود الصيانة والضمان والالتزام باتفاقيات مستوى الخدمة (SLA).
• وضع إطار حوكمة كامل لأنظمة كاميرات المراقبة: تحديد المسؤوليات والصلاحيات، اعتماد الجهات المخوَّلة بالوصول وفق مبدأ أقل صلاحية، اعتماد سياسات الاحتفاظ بالتسجيلات ومدد حفظها، وإجراء مراجعات دورية للالتزام بالحوكمة.

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

4. محمد أشرف — الدعم الفني لأجهزة وشبكات تقنية المعلومات

IT Hardware and Networking Technical Support · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق العمليات والخدمات التقنية (OPS)  |  يتبع إلى: مدير فريق العمليات والخدمات التقنية  |  الوردية: الدوام الصباحي: 8:00 صباحًا – 5:00 مساءً

تجهيز وتركيب وصيانة أجهزة الحاسب ونقاط البيع والشبكات والأنظمة الطرفية في جميع الفروع والمواقع، بما يضمن استمرارية تشغيل الأنظمة الحرجة للتجزئة (نقاط البيع، الموازين، الشبكات) خلال ساعات عمل الفروع.

المهام الرئيسية

• تجهيز وتركيب وإعداد أجهزة الحاسب واللابتوب والماسحات وهواتف VoIP والطابعات والموازين والملحقات الطرفية، وإجراء الإصلاحات الفعلية واستبدال المكونات (ذاكرة، أقراص، لوحات أم) والترقيات.
• تركيب وتهيئة أنظمة نقاط البيع (POS) الكاملة: شاشات اللمس، أدراج النقد، شاشات عرض العملاء، قارئات الباركود، وطابعات الإيصالات الحرارية (Epson/Zebra)، ومعالجة مشكلات اتصال POS بقواعد البيانات وERP لمنع تعطل الكاشير.
• تثبيت وتحديث أنظمة التشغيل والبرامج المؤسسية، وإدارة حسابات المستخدمين وصلاحياتهم عبر Active Directory، وتأمين الأجهزة الطرفية بمضاد الفيروسات وجدران الحماية.
• تركيب وتوصيل ومعالجة أجهزة الخوادم فعليًا (Rack/Cabling) وتهيئة أدوار الخادم الأساسية (AD، DNS، DHCP، IIS/Apache، خدمات الملفات والطباعة).
• إعداد وإدارة شبكات UniFi (Cloud Gateways ونقاط الوصول)، تصميم تقسيم VLAN لعزل الشبكات (شركة/ضيوف)، ضبط أداء الواي فاي، وإدارة سويتشات UniFi ومنافذ PoE وإعدادات STP.
• تركيب وصيانة الأجهزة المتخصصة للتجزئة: أجهزة تحقق الأسعار (Price Checkers) والموازين الإلكترونية، ومعالجة مشكلات الاتصال بينها وبين نقاط البيع وخوادم ERP/المخزون.
• تقديم الدعم الفني الأولي (الفعلي والمنطقي) لأجهزة الصراف الآلي (ATM) الموجودة في المواقع، بما يشمل استكشاف الأعطال واستبدال المكونات كطابعات الإيصالات.
• تثبيت وإدارة برامج طباعة الملصقات والباركود (BarTender) وتصميم قوالب مرتبطة بقواعد البيانات، وإعداد طابعات الباركود الحرارية الصناعية.
• تنفيذ التوصيلات الفعلية لخطوط مزودي الإنترنت (المودم، UPS، الكابلات) والتأكد من حماية الأجهزة من انقطاع الكهرباء.
• تسليم المستهلكات التشغيلية للفروع (لفافات الطابعات الحرارية والموازين، ملصقات الأسعار) حسب الحاجة.

🤝 يعمل ضمن الدوام الصباحي المعتمد (8:00 صباحًا – 5:00 مساءً)، وقد نفّذ مشاريع تجهيز تقنية كاملة لعدة مواقع تجزئة تابعة للمجموعة (الهايبر ماركت، السوبر ماركت، مخبزا المنار وسيسيكو، سمارفي سبوت، وفروع العامر-5)، وينسق مع مهندس الشبكات وزميله في الوردية المسائية لضمان تغطية كاملة لساعات تشغيل الفروع.

5. محمد بشير — الدعم الفني لأجهزة وشبكات تقنية المعلومات

IT Hardware and Networking Technical Support · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق العمليات والخدمات التقنية (OPS)  |  يتبع إلى: مدير فريق العمليات والخدمات التقنية  |  الوردية: الوردية المسائية: 1:00 ظهرًا – 10:00 مساءً

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

المهام الرئيسية

• تجهيز وتركيب وإعداد أجهزة الحاسب واللابتوب والماسحات وهواتف VoIP والطابعات والموازين والملحقات الطرفية، وإجراء الإصلاحات الفعلية واستبدال المكونات والترقيات.
• تركيب وتهيئة أنظمة نقاط البيع (POS) الكاملة وملحقاتها (أدراج النقد، شاشات العرض، قارئات الباركود، طابعات الإيصالات الحرارية)، ومعالجة مشكلات اتصال POS بقواعد البيانات وERP لمنع تعطل الكاشير خلال الفترة المسائية.
• تثبيت وتحديث أنظمة التشغيل والبرامج المؤسسية، وإدارة حسابات المستخدمين وصلاحياتهم عبر Active Directory، وتأمين الأجهزة الطرفية بمضاد الفيروسات وجدران الحماية.
• تركيب وتوصيل ومعالجة أجهزة الخوادم فعليًا (Rack/Cabling) وتهيئة أدوار الخادم الأساسية (AD، DNS، DHCP، خدمات الملفات والطباعة).
• إعداد وإدارة شبكات UniFi (Cloud Gateways ونقاط الوصول)، تصميم تقسيم VLAN، ضبط أداء الواي فاي، وإدارة سويتشات UniFi ومنافذ PoE وإعدادات STP لمنع الحلقات.
• تركيب وصيانة الأجهزة المتخصصة للتجزئة (أجهزة تحقق الأسعار والموازين الإلكترونية)، ومعالجة مشكلات الاتصال بينها وبين نقاط البيع وخوادم ERP/المخزون.
• تقديم الدعم الفني الأولي لأجهزة الصراف الآلي (ATM) في المواقع، بما يشمل استكشاف الأعطال واستبدال المكونات كطابعات الإيصالات.
• تثبيت وإدارة برامج طباعة الملصقات والباركود (BarTender) وإعداد طابعات الباركود الحرارية الصناعية.
• تنفيذ التوصيلات الفعلية لخطوط مزودي الإنترنت (المودم، UPS، الكابلات) وحماية الأجهزة من انقطاع الكهرباء.
• تسليم المستهلكات التشغيلية للفروع (لفافات الطابعات الحرارية والموازين، ملصقات الأسعار) حسب الحاجة خلال الفترة المسائية.

🤝 يعمل ضمن وردية مسائية مخصصة (1:00 ظهرًا – 10:00 مساءً) لتغطية ساعات تشغيل الفروع الممتدة بعد نهاية الدوام الصباحي، وينسق مع زميله في الفترة الصباحية ومهندس الشبكات لضمان تسليم سلس للمهام المفتوحة بين الورديتين.

6. عبدالله المهيني — أخصائي العمليات التشغيلية لتقنية المعلومات

IT Operations Specialist · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق العمليات والخدمات التقنية (OPS)  |  يتبع إلى: مدير فريق العمليات والخدمات التقنية

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

المهام الرئيسية

• متابعة العمليات التشغيلية اليومية لضمان استمرارية الخدمات، ومتابعة البلاغات الواردة من الموظفين وتحديد أثرها (فردي أو على نظام/خدمة/فرع) واتخاذ الإجراءات اللازمة حتى إغلاقها.
• توزيع المهام على فريق العمل بعد مراجعة الطلبات الواردة، وتحديد الأولويات التشغيلية ومتابعة إنجاز الأعمال ضمن الوقت المحدد.
• تقديم الدعم الفني للمستخدمين عن بُعد أو ميدانيًا لأجهزة الحاسب والطابعات وأجهزة نقاط البيع والشبكة والهواتف المكتبية، والتأكد من اختبار الخدمة قبل إغلاق الطلب.
• مراجعة وتصنيف ومتابعة طلبات الدعم الفني عبر نظام التذاكر (Ticketing System)، ومتابعة قناة بديلة (تطبيق Telegram) في حال تعطل النظام أو الحاجة لتحديث عاجل للبيانات.
• إسناد الطلبات لأعضاء الفريق أو تحويلها لقسم البرمجيات حسب نوعها، والتنسيق مع الموارد البشرية لتحديث بيانات الموظفين في الأنظمة وتنفيذ إجراءات إعارة الأصول التقنية.
• إدارة حسابات المستخدمين وصلاحيات الوصول للأنظمة (إنشاء/تعديل/تعطيل/حذف) عند التعيين أو النقل أو إنهاء الخدمة، وإدارة حسابات وخدمات NAS Synology (المجلدات المشتركة وSynology Drive).
• إدارة التراخيص البرمجية والاشتراكات التقنية (Adobe، Microsoft 365، وغيرها) ومتابعة تواريخ الانتهاء وتجديدها استباقيًا لضمان استمرارية الخدمات.
• إعداد طلبات الشراء للأجهزة والبرمجيات، والتنسيق مع إدارة المشتريات والموردين (عروض الأسعار والمقارنات)، ومتابعة أعمال الصيانة والضمان حتى عودة الأجهزة للخدمة.
• إدارة مخزون المستهلكات التقنية (الأحبار، الكابلات، الملحقات، قطع الغيار) ورفع طلبات الشراء قبل الوصول للحد الأدنى.
• إعداد وتحديث السياسات والإجراءات التشغيلية ومخططات سير العمليات، واقتراح مبادرات الأتمتة والتحسين، وإدارة عهد الأصول التقنية (نماذج التسليم والاستلام ونقل الأصول بين الإدارات والفروع).

🤝 نقطة الاتصال التشغيلية بين فريق العمليات والموردين والمستخدمين وإدارة الموارد البشرية، ويدعم جميع الفرق في التوثيق والمتابعة الإدارية وتحسين العمليات.

7. علي القطان — أخصائي دعم فني وتطوير برمجيات

IT Support & Software Development Specialist · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق العمليات والخدمات التقنية (OPS)  |  يتبع إلى: مدير فريق العمليات والخدمات التقنية

تقديم الدعم الفني وتطوير وتحسين الأنظمة الداخلية، وإدارة المخزون والعهد التقنية والعقود، ودعم الامتثال الأمني وتطبيق أفضل الممارسات التشغيلية.

المهام الرئيسية

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

🤝 يجمع بين الدعم الفني وتطوير الحلول الداخلية وإدارة المخزون والعقود، وينسق مع أخصائي العمليات التشغيلية وأخصائي الدعم الفني في الأعمال اليومية، ومع فريق الأنظمة المؤسسية عند الحاجة لتطوير أنظمة داخلية.

8. حيدر — أخصائي الدعم الفني

Technical Support Specialist · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق العمليات والخدمات التقنية (OPS)  |  يتبع إلى: مدير فريق العمليات والخدمات التقنية

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

المهام الرئيسية

• تقديم الدعم الفني للمستخدمين عن بُعد أو ميدانيًا، وتشخيص الأعطال ومعالجتها والتأكد من استعادة الخدمة واختبارها قبل إغلاق طلب الدعم.
• استقبال ومعالجة طلبات الدعم عبر نظام التذاكر (Ticketing System)، وتحديث حالتها باستمرار والتواصل مع المستخدمين حتى التأكد من حل المشكلة بالكامل قبل الإغلاق.
• معالجة أعطال أجهزة الحاسب والطابعات (بما فيها الحرارية) وقارئات الباركود وأجهزة نقاط البيع (POS) وجميع الأجهزة الطرفية، وتركيب الطابعات وضبط الطباعة عبر الشبكة وخاصية المسح الضوئي لمجلدات الشبكة (Scan to Folder).
• تجهيز وتركيب أجهزة الحاسب الجديدة (تثبيت أنظمة التشغيل والتعريفات والبرامج الأساسية وربطها بالشبكة)، وتنفيذ الصيانة الوقائية والتصحيحية، وأعمال التهيئة (Format) وإعادة تثبيت الأنظمة.
• فحص ومتابعة أجهزة نقاط البيع ومنافذ الخدمة (POS & Counters)، ومعالجة مشكلات الاتصال وحالات عدم الارتباط (Localhost) بما يضمن استمرارية العمليات التشغيلية.
• إدارة حسابات المستخدمين على Active Directory (إنشاء/تعديل/تعطيل) وربط أجهزة الحاسب بنطاق الشركة (Domain)، وإدارة حسابات المستخدمين على NAS Synology وصلاحيات الوصول للمجلدات المشتركة.
• المساعدة في تركيب وتشغيل أنظمة كاميرات المراقبة (IP وAnalog)، وتجهيز مواقع التركيب، والتأكد من سلامة عمل الكاميرات بعد التركيب.
• تنفيذ الفحوصات الدورية للبنية التحتية للشبكة، تجهيز وتمديد كابلات الشبكة (RJ45) وفحصها بأجهزة اختبار الشبكات (Cable Tester)، وتهيئة إعدادات IP وSubnet Mask وGateway وDNS للأجهزة.
• إعداد وتحديث مخططات الشبكة وتوثيق توزيع نقاط الشبكة ومسارات الكابلات ومواقع الأجهزة وترقيم المنافذ (Port Mapping).
• توثيق جميع الأعمال الفنية المنفذة وتحديث سجلات الأجهزة والأصول التقنية، وتسجيل تفاصيل الأعطال والإجراءات المتخذة ونتائج المعالجة لدعم قاعدة معرفية للرجوع إليها مستقبلًا.

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

9. حسن السبتي — مدير فريق الأنظمة المؤسسية والحلول الرقمية

Enterprise Systems & Digital Solutions Manager · المستوى 4 — مدير فريق

الفريق: فريق الأنظمة المؤسسية والحلول الرقمية (ERP)  |  يتبع إلى: مدير تقنية المعلومات

قيادة وتطوير أنظمة تخطيط موارد المؤسسة (ERP) والتطبيقات والمنصات الرقمية والتكاملات بين جميع أنظمة المجموعة، بصفته المدير المباشر لفريق الأنظمة المؤسسية والمطوِّر والمشرف التقني الرئيسي على جميع أعمال التطوير في الشركة، ودعم التحول الرقمي للمجموعة.

المهام الرئيسية

• الإشراف الإداري والفني المباشر على فريق تطوير ودعم ERP (Business Central) وLS Retail والتطبيقات والمواقع، مع المشاركة الفعلية في التطوير والتخصيص البرمجي لأنظمة الشركة عند الحاجة.
• الإشراف التقني الشامل على جميع أعمال التطوير في الشركة (الأنظمة الداخلية، التطبيقات، المواقع، التكاملات)، ومراجعة واعتماد الحلول التقنية المقترحة من الفريق قبل التنفيذ.
• المشاركة المباشرة في تطوير وصيانة وتحسين الأنظمة والتكاملات الحرجة عند الحاجة إلى خبرة تقنية متقدمة أو معالجة مشكلات معقدة يتعذر على الفريق حلها بمفرده.
• اعتماد خطط الإصدارات والتطوير (Release Plans) ومتابعة معايير الجودة والاختبار (QA/UAT) لجميع أنظمة المجموعة.
• الإشراف على التكاملات وواجهات البرمجة (API) بين جميع الأنظمة المختلفة داخل المجموعة، والتأكد من اتساقها وأمانها.
• مراجعة واعتماد معايير البرمجة (Coding Standards) وإجراءات Git Flow وCI/CD، وإجراء مراجعات كود دورية لرفع جودة الأنظمة المطوَّرة داخليًا.
• التنسيق مع الإدارات التشغيلية لتحديد متطلبات الأنظمة وتحويلها إلى مشاريع تطوير مجدولة، وقيادة مشاريع التحول الرقمي للمجموعة.
• بناء وتطوير قدرات فريق الأنظمة المؤسسية تقنيًا، ونقل الخبرة العملية لهم في مشاريع التطوير المشتركة، اتساقًا مع سياسة التدريب المتبادل وتقليل الاعتماد على فرد واحد.

🤝 يجمع بين القيادة الإدارية لفريق الأنظمة المؤسسية والمشاركة التقنية المباشرة في التطوير والإشراف على جميع أعمال التطوير بالشركة؛ يتعاون بشكل وثيق مع مدير فريق العمليات في مشاريع النشر والتكامل، ومع مدير تقنية المعلومات في قرارات التطوير الإستراتيجية.

10. علي الرمضان — أخصائي أنظمة تخطيط الموارد المؤسسية

ERP Specialist · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق الأنظمة المؤسسية والحلول الرقمية (ERP)  |  يتبع إلى: مدير فريق الأنظمة المؤسسية والحلول الرقمية

⏳ قيد الاستلام — لم يُستلَم بعد الوصف الوظيفي الرسمي المعتمد لهذا الموظف من الإدارة المختصة. سيُحدَّث هذا القسم بالكامل (الهدف من الوظيفة والمهام التفصيلية) فور استلامه واعتماده.

11. حبيب — أخصائي أنظمة الأعمال والتطوير الرقمي

Business Systems & Digital Development Specialist · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق الأنظمة المؤسسية والحلول الرقمية (ERP)  |  يتبع إلى: مدير فريق الأنظمة المؤسسية والحلول الرقمية

⏳ قيد الاستلام — لم يُستلَم بعد الوصف الوظيفي الرسمي المعتمد لهذا الموظف من الإدارة المختصة. سيُحدَّث هذا القسم بالكامل (الهدف من الوظيفة والمهام التفصيلية) فور استلامه واعتماده.

🔺 جهة تصعيد فني من المستوى الثاني (L2 Escalation) للحالات التقنية المعقدة، وفق مصفوفة التصعيد في المجلد الثالث.

12. أحمد أبو ديه — مطور متكامل للأنظمة والتكامل

Full-Stack Systems & Integration Developer · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق الأنظمة المؤسسية والحلول الرقمية (ERP)  |  يتبع إلى: مدير فريق الأنظمة المؤسسية والحلول الرقمية

⏳ قيد الاستلام — لم يُستلَم بعد الوصف الوظيفي الرسمي المعتمد لهذا الموظف من الإدارة المختصة. سيُحدَّث هذا القسم بالكامل (الهدف من الوظيفة والمهام التفصيلية) فور استلامه واعتماده.

🔺 جهة تصعيد فني من المستوى الثاني (L2 Escalation) للحالات التقنية المعقدة، وفق مصفوفة التصعيد في المجلد الثالث.

13. علي المتروك — مطور تطبيقات الجوال والويب وإدارة البريد الإلكتروني

Mobile & Web Developer / Email Systems Administrator · المستوى 1 — أخصائي/مهندس مساعد (Associate)

الفريق: فريق الأنظمة المؤسسية والحلول الرقمية (ERP)  |  يتبع إلى: مدير فريق الأنظمة المؤسسية والحلول الرقمية

⏳ قيد الاستلام — لم يُستلَم بعد الوصف الوظيفي الرسمي المعتمد لهذا الموظف من الإدارة المختصة. سيُحدَّث هذا القسم بالكامل (الهدف من الوظيفة والمهام التفصيلية) فور استلامه واعتماده.

محتويات الملاحق

• الهيكل التنظيمي والهيكل التقني — موضّحان بالتفصيل في القسم المخصص لهيكل الإدارة في هذا الدليل.
• خرائط الشبكات ومعمارية الأنظمة ومعمارية الأمن السيبراني — تُحفظ وتُحدَّث في قاعدة المعرفة الفنية المقيّدة الوصول.
• مصفوفة RACI ومصفوفة الصلاحيات ومصفوفة المخاطر — نماذج معتمدة قابلة للتطبيق على كل عملية موثقة في هذا الدليل.
• كتالوج الخدمات (Service Catalog) — يسرد جميع الخدمات التي تقدمها إدارة تقنية المعلومات مع وصف كل خدمة ومالكها.
• اتفاقيات مستوى الخدمة (SLA) ومؤشرات الأداء (KPIs) — تفصيلية لكل خدمة وعملية، مرتبطة بلوحات المعلومات الموضحة في المجلد السادس والعشرين.
• قوائم التحقق (Checklists) — لجميع العمليات المتكررة (فتح/إغلاق يومي، افتتاح/إغلاق فرع، النشر، التعافي من الكوارث).
• قاموس المصطلحات وقائمة الاختصارات — مرجع موحّد لجميع المصطلحات التقنية المستخدمة في الدليل.

قاعدة بيانات إدارة التكوين (CMDB) والعلاقات بين عناصر البنية

توضح قاعدة بيانات إدارة التكوين (CMDB) جميع عناصر البنية التقنية (Configuration Items - CIs) والعلاقات فيما بينها، بما يسهِّل تحليل الأثر عند أي تغيير أو عطل. يوضح الجدول التالي نموذجًا مختصرًا للعلاقات الرئيسية:

تُدار قاعدة بيانات إدارة التكوين الكاملة (بكل تفاصيل الأجهزة والإصدارات والمالكين) إلكترونيًا ضمن أداة CMDB أو نظام إدارة الأصول المعتمد، وهذا الجدول عرض مختصر للعلاقات الأكثر أهمية لأغراض تحليل الأثر.

تخطيط السعة (Capacity Planning) — توقعات ثلاث سنوات

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

تُحدَّث أرقام هذا الجدول ربع سنويًا بناءً على بيانات المراقبة الفعلية من أدوات مراقبة الأداء (المجلد الحادي عشر)، وتُرفع أي مخاطر اقتراب من الحدود الحرجة للجنة تقنية المعلومات فورًا وليس فقط في المراجعة الدورية.

سجل المخاطر التقنية (IT Risk Register)

يوثق هذا السجل أبرز المخاطر التقنية المحدَّدة حاليًا كنموذج تطبيقي لإطار إدارة المخاطر الموضح في المجلد الأول، ويُحدَّث ربع سنويًا على الأقل.

هذا السجل نموذج تطبيقي أولي؛ يُدار السجل الكامل والمحدَّث لجميع المخاطر التقنية إلكترونيًا ويُراجَع في كل اجتماع للجنة تقنية المعلومات.

مصفوفات RACI التفصيلية لأهم العمليات (نماذج مستقلة لكل عملية)

بالإضافة إلى مصفوفة RACI العامة في الملاحق، توضح الجداول التالية توزيع الأدوار بالتفصيل لسبع عمليات جوهرية، لضمان وضوح تام للمسؤوليات عند التنفيذ الفعلي.

عملية: إدارة نظام ERP (Business Central/LS Retail)

عملية: النسخ الاحتياطي (Backup)

عملية: إدارة الشبكات (Network)

عملية: إدارة جدار الحماية (Firewall)

عملية: إدارة المشاريع التقنية (Projects)

عملية: إدارة الحوادث (Incidents)

عملية: المشتريات التقنية (Procurement)

R = مسؤول عن التنفيذ | A = معتمد نهائيًا | C = يُستشار | I = يُبلَّغ

مصفوفة RACI للعمليات الرئيسية عبر مجلدات الدليل

R = مسؤول عن التنفيذ | A = معتمد نهائيًا | C = يُستشار | I = يُبلَّغ

جدول مؤشرات الأداء الرئيسية (KPIs) بالأهداف الرقمية المعتمدة

التقويم السنوي للامتثال والمراجعات الدورية

نموذج ميزانية تقنية المعلومات التفصيلي (CAPEX/OPEX مقابل الفعلي)

يُستخدَم هذا النموذج لمتابعة الميزانية المعتمدة مقابل الإنفاق الفعلي والانحراف (Variance) لكل بند رئيسي، بالإضافة إلى التوقع (Forecast) لبقية السنة المالية.

تُملأ الخانات بالأرقام الفعلية بالريال السعودي عند اعتماد الميزانية السنوية، وتُراجَع شهريًا من مدير تقنية المعلومات وربع سنويًا أمام لجنة تقنية المعلومات والإدارة المالية.

جدول تقديري لميزانية تقنية المعلومات (توزيع نسبي إرشادي — ثلاث سنوات)

هذه النسب إرشادية للتخطيط الأولي، وتُحدَّد القيم الفعلية بالريال السعودي سنويًا بالتنسيق مع الإدارة المالية وفق حجم الإيرادات والمشاريع المعتمدة.

قائمة اتصال الطوارئ (Emergency Contact List)

تُحدَّث هذه القائمة فور أي تغيير في المسؤوليات أو أرقام التواصل، وتُوزَّع نسخة مطبوعة منها في غرفة الخوادم الرئيسية ولدى جميع أعضاء فريق تقنية المعلومات.

لوحة معلومات الإدارة التنفيذية (Executive Dashboard) — مواصفة المحتوى

تُصمَّم لوحة معلومات تنفيذية (عبر Power BI أو أداة مماثلة) تُعرَض شهريًا وربع سنويًا للإدارة التنفيذية، وتتضمن البطاقات التالية كحد أدنى:

• حالة المشاريع الإستراتيجية ونسبة الإنجاز مقابل الجدول الزمني المعتمد.
• حالة توافر نظام ERP والأنظمة الحرجة (Uptime%) خلال آخر 30 يومًا.
• حالة الفروع (عدد الفروع المتصلة بشكل طبيعي مقابل الفروع ذات الأعطال النشطة).
• ملخص المخاطر التقنية الحرجة المفتوحة من سجل المخاطر.
• حالة العقود الرئيسية (الموردون وشريك ERP) والعقود المقتربة من التجديد خلال 90 يومًا.
• ملخص الوضع الأمني (عدد الحوادث الأمنية حسب الخطورة، حالة الامتثال).
• ملخص الإنفاق التقني الفعلي مقابل الميزانية المعتمدة (CAPEX/OPEX) والانحراف.
• ملخص مؤشرات الأداء الرئيسية (KPI) العامة لإدارة تقنية المعلومات (راجع لوحة KPI أدناه للتفصيل الكامل).

لوحة مؤشرات الأداء التشغيلية (KPI Dashboard) — مواصفة المحتوى

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

ملخص بيان قابلية التطبيق (Statement of Applicability) وفق ISO 27001 Annex A — نظرة عامة

هذا الملخص إرشادي على مستوى المجال؛ يُفصَّل بيان قابلية التطبيق الكامل (على مستوى كل ضابط فرعي) في وثيقة مستقلة تُدار من فريق الأمن السيبراني عند بدء برنامج اعتماد ISO 27001 رسميًا.

مواءمة إطار الأمن السيبراني مع وظائف NIST Cybersecurity Framework (CSF)

هذه المواءمة إرشادية لتسهيل مقارنة ضوابط الدليل مع إطار عمل NIST CSF المعترف به دوليًا، ولا تغني عن تقييم رسمي مستقل عند الحاجة لشهادة أو تقرير امتثال نظامي.

كتالوج خدمات تقنية المعلومات (IT Service Catalog)

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

يُدار هذا الكتالوج تفصيليًا (مع أوصاف الخدمة الكاملة واتفاقيات مستوى الخدمة الدقيقة لكل بند) ضمن نظام إدارة الخدمة الإلكتروني، وهذا الجدول ملخص مرجعي عام.

نماذج رسمية توضيحية

نموذج طلب تغيير (RFC) — مثال توضيحي

نموذج تسليم/استلام عهدة — مثال توضيحي

نموذج طلب صلاحية مورد خارجي (شريك ERP) — مثال توضيحي

نموذج طلب وصول لقاعدة بيانات (SQL Access Request) — مثال توضيحي

نموذج اعتماد الانتقال للتشغيل الفعلي (Go-Live Signoff) — مثال توضيحي

نموذج تقرير تحليل السبب الجذري (RCA Report) — مثال توضيحي

معايير التسمية الموحدة (Naming Convention)

تُطبَّق هذه المعايير إلزاميًا على جميع الأصول والحسابات الجديدة، وتُعاد تسمية العناصر القائمة تدريجيًا ضمن خطة توحيد لا تتجاوز سنة واحدة من تاريخ اعتماد هذا الإصدار.

نموذج تقييم النضج الذاتي السنوي (Self-Assessment Checklist)

يُستخدَم هذا النموذج من قِبل مدير تقنية المعلومات ومديرَي الفريقين لتقييم مستوى نضج تطبيق كل مجلد من مجلدات هذا الدليل سنويًا، وفق مقياس من 1 إلى 5 (1 = غير مطبَّق، 3 = مطبَّق جزئيًا، 5 = مطبَّق بالكامل ومُراجَع دوريًا)، بهدف تحديد أولويات التحسين للسنة التالية.

يُجرى هذا التقييم مرة واحدة على الأقل سنويًا (يُفضَّل الربع الأول من كل عام)، وتُرفع نتيجته الإجمالية للجنة تقنية المعلومات ضمن خطة التحسين المستمر المشار إليها في المجلد الأول.

قاموس المصطلحات