ServiceNow وبدائله مفتوحة المصدر: ماذا تأخذ من كل منها؟

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

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

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

وكل معلومة عن ServiceNow في هذا المقال من توثيقها الرسمي كما قرأناه في 15 أكتوبر 2026، مع تاريخ كل صفحة، لأن هذا التوثيق يتغير مع كل إصدار. والمقالات التي يبني عليها هذا المقال هي:

دليلأي نظام تذاكر Helpdesk يناسب قسم تقنية المعلومات؟مقارنة أنظمة التذاكر المفتوحة بتراخيصها وأجزائها المدفوعة ودعمها للعربية، مع تجربة البريد وال SLA على ثلاثة منها.دليلدورة حياة أجهزة المؤسسة IT Asset Managementكيف تتابع كل جهاز في مؤسستك من الطلب والشراء إلى التسليم والجرد والإرجاع، ثم المسح والإتلاف بسجل كامل.دليلسير عمل حقيقي في n8n: من التذكرة إلى تسليم الجهازكيف تبني في n8n سير عمل يفتح تذكرة في GLPI وينتظر موافقة المدير ثم يسلم الجهاز في Snipe-IT، ويتعامل مع الفشل والتكرار.

ما هي ServiceNow؟

منصة ServiceNow خدمة سحابية تقدم إدارة الخدمات للمؤسسات باشتراك، وتوثيقها الحالي يسمي المنصة نفسها «ServiceNow AI Platform»، كما في صفحة Workflow Studio لإصدار Brazil المحدثة في 10 سبتمبر 2026. وفوق هذه المنصة مجموعة تطبيقات تشترك في قاعدة البيانات نفسها، وأهمها كما تظهر أسماؤها في ملخص الميزات الجديدة لإصدار Brazil المحدث في 8 أكتوبر 2026:

• إدارة خدمات تقنية المعلومات ITSM: وفيها Incident Management وChange Management وService Catalog، أي الحوادث والتغيير وكتالوج الطلبات التي شرحناها في مقال ITSM.
• إدارة العمليات ITOM: وفيها Discovery الذي يكتشف الأجهزة والخدمات ويملأ قاعدة بيانات الإعدادات CMDB، وService Mapping الذي يربط الأجهزة بالخدمات التي تعتمد عليها.
• إدارة الأصول: وفيها Hardware Asset Management للأجهزة وSoftware Asset Management للتراخيص.
• خدمات الموظفين HR Service Delivery: وتصفها صفحتها بأنها منصة واحدة لكل خدمات الموارد البشرية، فيها إدارة الحالات والمعرفة، وبوابة الموظف Employee Center، وأتمتة أحداث مثل التعيين التي تمر بعدة أقسام.
• خدمة العملاء CSM: إدارة حالات العملاء الخارجيين.
• الأمن والامتثال: وفيها Security Incident Response للاستجابة للحوادث الأمنية، وميزات الحوكمة والمخاطر والامتثال GRC.
• بناء التطبيقات: App Engine لبناء تطبيقات داخلية، وWorkflow Studio الذي تقول صفحته إنه واجهة واحدة لسير العمل والتدفقات الفرعية والإجراءات وجداول القرار، وأنه مفعل افتراضياً في المنصة.

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

الإصدارات: مدن بالترتيب الأبجدي، وتحديث لا يتوقف

تقول صفحة ServiceNow upgrades لإصدار Brazil، المحدثة في 10 سبتمبر 2026، إن الإصدارات منظمة في عائلات Families، وإن العائلة مجموعة إصدارات تحمل اسم مدينة كبيرة، وتضم التصحيحات Patches والإصلاحات العاجلة Hotfixes. والأسماء تمشي بالترتيب الأبجدي، فالعائلات التي يذكرها التوثيق اليوم هي Xanadu ثم Yokohama ثم Zurich، ثم عاد الترتيب إلى أول الحروف مع Australia ثم Brazil. وتفرق الصفحة نفسها بين أمرين:

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

وفي صفحة الإصدارات المتاحة المحدثة في 8 أكتوبر 2026 أن Brazil متاح منذ 24 سبتمبر 2026 لعملاء الإتاحة المبكرة Early Availability، وأن أهداف التصحيح في الربع الرابع من 2026 تشمل ثلاث عائلات هي Australia وZurich وYokohama. والنتيجة العملية أن العميل يعيش في دورة ترقية مستمرة: كل عائلة جديدة تعني قراءة ملاحظات الإصدار، واختبار التخصيصات التي بنيتها على المنصة، ثم الترقية قبل أن تخرج عائلتك من قائمة التصحيحات. وكلما زادت التخصيصات زادت تكلفة كل ترقية، وهذا هو الشكل الحقيقي للارتباط بالمورد Vendor Lock-in هنا: ليس أنك لا تستطيع الخروج، وإنما أن كل ما بنيته مكتوب بلغة المنصة وأدواتها، كما شرحنا في الارتباط بمورد واحد.

نموذج الاشتراكات، ولماذا لا تجد سعراً

الترخيص في ServiceNow اشتراك يقاس بطرق مختلفة حسب المنتج، وتصف صفحة أنواع الاشتراكات في Subscription Management لإصدار Brazil، المحدثة في 10 سبتمبر 2026، خمسة أنواع:

والمعنى العملي للنوع الأول أن ما تدفعه يتبع عدد من يعملون على الطلبات، أي الفنيين وفرق الدعم ومن في حكمهم، وليس عدد الموظفين الذين يرسلون الطلبات. وبعض الميزات اشتراك منفصل فوق المنتج نفسه، فمثلاً تقول صفحة إعداد Workflow Studio إن إجراءات تدفق البيانات Data Stream Actions تحتاج اشتراكاً منفصلاً في Integration Hub.

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

لماذا تختارها الجهات الكبيرة؟

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

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

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

خريطة البدائل جزءاً جزءاً

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

وفيما يلي كل جزء مع ما نشرناه عنه، وتراخيص الأدوات كما في مستودعاتها في 15 أكتوبر 2026.

التذاكر والطلبات ITSM

هذا أقرب جزء إلى التغطية الكاملة، وقد قارنا أنظمته بالتجربة في مقارنة أنظمة التذاكر، وخلاصتها:

• نظام GLPI للتذاكر والأصول معاً، بترخيص GPL-3.0.
• نظام iTop لمن يريد عمليات ITIL كاملة مع CMDB، بترخيص AGPL-3.0.
• نظاما Znuny وOTOBO، وقد شرحنا قصتهما في قصة OTRS وZnuny وOTOBO.
• نظام Zammad، وهو أقرب لمكتب الدعم Helpdesk منه لإدارة الخدمات الكاملة.

قاعدة بيانات الإعدادات والاكتشاف

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

• نظام iTop: أقوى CMDB مفتوحة بنموذج بيانات قابل للتعديل كما ذكرنا في المقارنة، ولكنه يحتاج من يملؤه.
• وكيل GLPI Agent: وكيل جرد يرسل بيانات الأجهزة إلى GLPI، وترخيصه GPL-2.0 كما في مستودعه.
• نظام OCS Inventory: نظام جرد بوكيل وسيرفر، وترخيص سيرفره GPL-2.0 كما في مستودعه.
• نظام NetBox: مصدر الحقيقة للشبكة ومراكز البيانات، أي العناوين والكوابل والخزائن، وترخيصه Apache-2.0 كما في مستودعه، وهو لا يكتشف الشبكة وحده وإنما يوثق ما يجب أن تكون عليه.

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

الأجهزة والتراخيص

يغطي Snipe-IT سجل الأجهزة والتراخيص والملحقات وإقرارات الاستلام، وقد شرحنا الإجراءات في دورة حياة أجهزة المؤسسة والتثبيت في دليل Snipe-IT، وفي إصداره v8.8.0 محولات مزامنة تجريبية مع أنظمة إدارة الأجهزة. أما إدارة تراخيص البرامج بالعمق الذي تعنيه Software Asset Management، أي مطابقة ما هو مثبت فعلاً على الأجهزة مع ما اشتريته، فلا يوجد لها مقابل مفتوح كامل، وأقرب ما يكون جرد البرامج في GLPI مع سجل التراخيص.

المراقبة والأحداث

جزء ITOM في ServiceNow يجمع تنبيهات أدوات المراقبة ويربطها بالأجهزة والخدمات والتذاكر، والمراقبة نفسها تقوم بها في العالم المفتوح أدوات مثل Zabbix بترخيص AGPL-3.0 وPrometheus بترخيص Apache-2.0، ولكن الربط بين التنبيه والتذكرة والجهاز في CMDB عمل تبنيه أنت، سواء بإضافات الأدوات أو بسير عمل. ولم ننشر بعد دليلاً لـ Zabbix أو Prometheus، وقد شرحنا جزءاً من المراقبة في مسار السجل Log Pipeline وفي التتبع الموزع.

خدمات الموظفين

لا يوجد منتج مفتوح واحد يقابل HR Service Delivery، والسبب أنها ليست نظام موارد بشرية، وإنما بوابة طلبات للموظف مع سير عمل يمر بعدة أقسام. ويبنى مقابلها من ثلاث قطع:

• نظام الموارد البشرية نفسه، مثل Frappe HR بترخيص GPL-3.0، أو OrangeHRM بترخيص GPL-3.0.
• بوابة طلبات، وقد تكون نظام التذاكر نفسه بفئة خاصة بالموارد البشرية، كما في إدارة خدمات المؤسسة ESM.
• سير عمل يربط التعيين بالحسابات والأجهزة، كما شرحنا في دورة حياة حساب الموظف JML.

خدمة العملاء

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

الأمن والامتثال

في هذا الجزء أداتان مفتوحتان تستحقان الذكر، وكلتاهما تغطي جزءاً محدداً:

• أداة DefectDojo: لإدارة الثغرات من نتائج أدوات الفحص، وترخيصه BSD-3-Clause كما في مستودعه.
• أداة CISO Assistant: لإدارة الضوابط والمخاطر والامتثال، والكود خارج مجلد enterprise بترخيص AGPL-3.0، أما ما داخله فترخيص تجاري، كما في ملف الترخيص في مستودعه.

وقد قارنا فئات الأمن التجارية ببدائلها في حلول الأمن التجارية وبدائلها، وشرحنا المصطلحات في مصطلحات GRC والضوابط في ضوابط NCA ECC.

بناء التطبيقات الداخلية

جزء App Engine تقابله أدوات بناء التطبيقات الداخلية Low-Code، وتراخيصها تحتاج انتباهاً لأن أغلبها نواة مفتوحة مع أجزاء مدفوعة:

• أداة Appsmith: بترخيص Apache-2.0 كما في مستودعه.
• أداة ToolJet: بترخيص AGPL-3.0.
• أداة Budibase: يقول ملف الترخيص في مستودعه إنه يعد GPL-3.0 بشكل عام، وإن الميزات المدفوعة في حزم منفصلة بترخيص BSL.
• أداة NocoBase: له اتفاقية ترخيص خاصة به في مستودعه، فاقرأها قبل الاعتماد عليه.
• أداة NocoDB: قاعدة بيانات بواجهة جداول، وقد شرحنا تثبيته في دليل NocoDB.

سير العمل والموافقات

هنا التغطية جيدة، فأداة n8n تغطي الربط بين الأنظمة، وFlowable يغطي العمليات الطويلة بمعيار BPMN، وقد قارنا الأدوات وتراخيصها، ومنها تغير ترخيص Camunda، في أدوات أتمتة سير العمل. والفرق عن Workflow Studio أن سير العمل هناك يعمل داخل المنصة على بياناتها مباشرة، أما هنا فيعمل من الخارج عبر واجهات API، وهذا هو موضوع الفقرة التالية.

قاعدة المعرفة

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

دليلBookStack: توثيق فريقك في كتب وفصول على سيرفرككيف تشغل BookStack على سيرفرك وتنظم توثيق فريقك في أرفف وكتب وفصول، مع صلاحيات ودخول موحد وبحث بالعربية.دليلOutline: قاعدة معرفة فريقك على سيرفرككيف تشغل Outline على سيرفرك ليكتب فيه فريقك إجراءاته وقراراته، ويدخل إليه الموظفون بحساباتهم في authentik.

تكلفة الصمغ: ماذا تعلمنا من ربط ثلاثة أنظمة

لم نبن في هذا المقال تجربة جديدة، لأن التجربة التي تقيس تكلفة الربط موجودة: في سير عمل حقيقي في n8n بنينا العملية التي تبيعها ServiceNow كتطبيق جاهز، أي موظف يطلب جهازاً، فتفتح تذكرة في GLPI، وتنتظر موافقة المدير، ثم يسلم الجهاز في Snipe-IT وتغلق التذكرة. والعملية عملت، ولكن تلك التجربة أظهرت ما يتطلبه الربط من عمل:

1. حساب خدمة لكل نظام وصلاحياته: أول تشغيل فشل لأن GLPI أعطى حساب الخدمة صلاحية الخدمة الذاتية كصلاحية افتراضية، فكان سير العمل يعمل كموظف عادي، كما في بيانات الاعتماد.
2. جلسات تنتهي أثناء الانتظار: الموافقة قد تأخذ أياماً، فاحتجنا جلسة GLPI جديدة بعد الانتظار.
3. منع التكرار: الطلب نفسه وصل مرتين ففتحت تذكرتان، حتى أضفنا معرفاً ثابتاً وعقدة تمنع التكرار، كما في الطلب نفسه يصل مرتين.
4. الفشل في المنتصف: عندما توقف Snipe-IT بقيت التذكرة موافقاً عليها دون جهاز، ولولا سير عمل الأخطاء لبقيت كذلك حتى يسأل الموظف، كما في الفشل في منتصف الطريق.
5. التشغيل: حفظ سير العمل في Git، واختباره، ومراقبة تشغيلاته، وكلها عمل مستمر وليس مرة واحدة.

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

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

ما لن تحصل عليه من الأدوات المفتوحة

إذا اخترت الأدوات المفتوحة فاعرف من البداية ما الذي لن يأتي معها، وأهمه:

• منصة واحدة: لا يوجد مشروع مفتوح يجمع ITSM وITOM وHR وCSM والأمن وبناء التطبيقات على نموذج بيانات واحد.
• تقارير عابرة للأنظمة: سؤال مثل «كم حادثة سببتها أجهزة انتهى ضمانها في قسم المالية؟» يحتاج نقل البيانات إلى مستودع تقارير، كما في Metabase.
• اكتشاف عميق: ربط الخدمات بما تعتمد عليه آلياً، وليس جرد الأجهزة فقط.
• مسؤول واحد: عندما يتعطل الربط بين نظامين لا يوجد مورد واحد تتصل به، والمسؤول هو فريقك، كما شرحنا في من يتحمل المسؤولية عندما يتعطل الإنتاج.
• واجهة واحدة باللغة نفسها: كل أداة لها مستوى مختلف من الترجمة العربية، كما رأينا في العربية في أنظمة التذاكر.
• ترقيات منسقة: عشر أدوات تعني عشرة جداول إصدارات وعشر قوائم تنبيهات أمنية، كما رأينا في تنبيهات Snipe-IT وحده في دليل التثبيت.

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

متى تكون ServiceNow هي الإجابة الصحيحة؟

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

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

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

جدول القرار

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

أخطاء شائعة

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

الخلاصة

• تبيع ServiceNow منصة واحدة بقاعدة بيانات واحدة فوقها تطبيقات ITSM وITOM والأصول والموارد البشرية وخدمة العملاء والأمن وبناء التطبيقات.
• إصداراتها عائلات بأسماء مدن بالترتيب الأبجدي، وآخرها Brazil في الإتاحة المبكرة منذ 24 سبتمبر 2026، والترقية المستمرة جزء من تكلفتها.
• الاشتراك يقاس بأنواع منها حسب المستخدم المنفذ وحسب السعة، ولا توجد أسعار منشورة في التوثيق.
• أغلب الأجزاء لها مقابل مفتوح، أوضحها التذاكر والأصول وسير العمل وقاعدة المعرفة، وأضعفها الاكتشاف وخدمات الموظفين.
• الذي لا يوجد له مقابل مفتوح هو المنصة نفسها، وتجربة الربط بين GLPI وSnipe-IT عبر n8n أظهرت أن الصمغ عمل مستمر له تكلفة حقيقية.

وفي مقالات قادمة بإذن الله سوف نكمل أدوات مرحلة إدارة تقنية المعلومات، مثل GLPI وNetBox وأدوات الجرد الآلي.

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

• أكتوبر 2026: كتابة المقال من توثيق ServiceNow الرسمي كما هو في 15 أكتوبر 2026 (صفحات إصدار Brazil المحدثة في 10 سبتمبر و8 أكتوبر 2026)، وتراخيص الأدوات من مستودعاتها في التاريخ نفسه، وتجربة الربط المنشورة في مقال n8n على GLPI 12.0.0 وSnipe-IT v8.8.0 وn8n 2.43.5. لم نبن تجربة جديدة لهذا المقال.