عقد نظام إدارة الزوار: بنود الترخيص والدعم وملكية البيانات التي تراجعها قبل التوقيع

أين تضيع الوعود بين العرض والتوقيع؟

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

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

وهي المرحلة التي تأتي بعد التقييم والترسية في خطوات شراء نظام إدارة الزوار: النطاق صار معروفًا، والمطلوب الآن أن يصبح ملزمًا.

من يراجع كل جزء من العقد؟

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

الترخيص أو الاشتراك: بماذا يُحسب وماذا يحدث عند التجاوز؟

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

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

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

ولا تقبل مبدأ «عدد مستخدمين مفتوح» دون أن يُكتب، ولا تفترض أن الوحدات التي رأيتها في العرض التوضيحي مشمولة. قاعدة بسيطة: ما لا يرد اسمه في ملحق الوحدات غير مشمول.

نطاق التنفيذ ومخرجاته: ما الذي يُسلَّم في كل مرحلة؟

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

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

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

معايير القبول: متى يُعد النظام مستلمًا؟

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

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

التكاملات والتخصيص: النطاق والتراخيص والملكية

التكاملات

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

1. النظام وإصداره: اسم النظام الآخر وإصداره كما ثبتا في التقييم، لأن تغيّر الإصدار قد يغير الواجهة.
2. اتجاه البيانات ونطاقها: ما الذي ينتقل ومن أين إلى أين، مثل «صلاحية مؤقتة للزائر تُنشأ عند تسجيل الوصول وتُلغى عند المغادرة، وأحداث الدخول تعود إلى نظام الزوار».
3. الترخيص ومن يتحمله: رخصة الواجهة من مزود النظام الآخر بند مستقل يُحدد من يشتريه ومن يتابعه، ولا يُترك داخل عبارة «التكامل مشمول».
4. ما يحدث إن تغير النظام الآخر: ترقية نظام البوابات بعد التشغيل قد تكسر الربط؛ حدد هل إعادة التهيئة ضمن الدعم أم طلب تغيير.

التخصيص وملكيته

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

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

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

الدعم والتحديثات: ما يدخل العقد وما يحال إلى اتفاقية الخدمة

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

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

تصنيف الأعطال ومؤشرات الخدمة وطريقة قياسها موضوع مستقل تفصله مقالة اتفاقية الدعم بعد تشغيل نظام الزوار؛ المهم هنا ألا يوقع العقد وملحق الخدمة «سيُتفق عليه لاحقًا».

البيانات: مكانها وسريتها وتسليمها عند الإنهاء

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

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

التوسع وتغيير النطاق: الفروع الجديدة والانتقال بين خيارات النشر

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

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

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

قائمة التحقق الكاملة قبل توقيع عقد نظام إدارة الزوار

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

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

سيناريو: شركة خدمات مالية قبل توقيع عقد سحابي

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

المسودة الأولى للعقد كانت من صفحتين تحيل إلى «العرض الفني المرفق». عند تطبيق القائمة السابقة ظهرت خمس فجوات:

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

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

الأسئلة الشائعة

الخلاصة: العقد يثبت ما رأيته لا ما سمعته

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

وإن كنت تقيّم نظام إدارة زوار المنشآت، اطلب عرضًا تُفصل فيه الوحدات والتكاملات والمراحل والدعم بنودًا مستقلة، فيسهل على المشتريات والقانونية تحويله إلى ملاحق عقد دون إعادة صياغة.