المدونة — 2026-08-07
بقلم عماد يحيى — مطور مواقع ومهندس أنظمة تقنية في دبي
جداول الإكسل تفشل في تتبع العهد لسبب واحد جوهري: الجدول يخزّن حالة، والعهدة في حقيقتها تاريخ. الخلية تُكتب فوقها فتختفي الحقيقة السابقة، بينما السؤال الذي تحتاج إجابته يوم يختفي جهاز ليس «أين هو الآن؟» بل «من استلمه، ومتى، وبأي مستند، وإلى من انتقل بعده، وماذا جرى له؟». النظام الصحيح لإدارة الأصول لا يسجّل صفوفًا بل أحداثًا: تسليم، ونقل، وإرجاع، وصيانة، مربوطة كلها بالموظف المسؤول وبإقرار عهدة موقّع.
أنا عماد يحيى، مهندس أنظمة في دبي وأدير البنية التقنية لشركة عقارية هنا. وهذا الموضوع تحديدًا لم يكن مشروع عميل بالنسبة لي: الأجهزة التي كانت على ذلك الجدول كانت مسؤوليتي، وحين ضاع أصل كنت أنا الشخص الذي لا يستطيع الإجابة عن سؤال «من كان يحمله آخر مرة؟». لذلك بنيت نظام إدارة الأصول التقنية بنفسي — يتتبع أكثر من 150 جهازًا عبر أقسام الشركة، وبعد تشغيله لم يعد هناك أصل غير متتبع. ما يلي هو ما تعلمته من ذلك البناء.
الجدول أداة ممتازة للحساب، وسيئة جدًا لحفظ التاريخ. عندما ينتقل جهاز من موظف إلى آخر، ما يحدث عمليًا هو أن أحدهم يفتح الملف ويستبدل الاسم القديم بالجديد. في تلك اللحظة تختفي المعلومة الأهم: أن الجهاز كان بحوزة شخص آخر قبل أسبوعين. لا يبقى سؤال «من كان مسؤولًا عنه حين تعطّل؟» بلا إجابة فحسب، بل يصبح غير قابل للإجابة أصلًا.
والمشكلة الثانية أن الجدول لا يفرض أي انضباط. لا شيء فيه يمنعك من تسليم جهاز دون تسجيل، ولا من كتابة اسم موظف بصيغتين مختلفتين، ولا من حذف صف بالخطأ. ثلاث فجوات كانت موجودة عندنا قبل النظام، وأراها تتكرر في شركات كثيرة تدير أصولها على الجداول: لا سجل تسليم، ولا إقرار مسؤولية موقّع، ولا أثر تدقيق. والنتيجة المتوقعة لهذه الفجوات هي بالضبط ما حدث: أصول تختفي دون أن يكون أحد مخطئًا رسميًا.
والمشكلة الثالثة تنظيمية: الجدول يجعل المعرفة شخصية لا مؤسسية. الشخص الذي يحتفظ بالملف يعرف السياق كله — أي جهاز في المخزن، وأيها عند الصيانة، ومن وعد بإرجاع اللابتوب الأسبوع القادم — لكن هذه المعرفة تغادر معه يوم يغادر.
الجرد يجيب عن سؤال المحاسبة: كم جهازًا نملك وما قيمتها؟ أما تتبع العهدة فيجيب عن سؤال المسؤولية: من يتحمل مسؤولية هذا الجهاز الآن، وبأي مستند، ومنذ متى؟ والشركات تخلط بينهما فتشتري نظام جرد ثم تكتشف أنه لا يخدمها في اللحظة التي تحتاجه فيها فعلًا.
وتلك اللحظة تأتي دائمًا: موظف يقدم استقالته. المخالصة تحتاج قائمة دقيقة بما بحوزته الآن — لا ما بحوزته حسب آخر تحديث للملف — وتحتاج إقرارات موقّعة تُثبت ما استلمه وبأي حالة. إن لم يكن ذلك جاهزًا بضغطة زر، ستحصل على أحد أمرين: تأخير في إنهاء الخدمة، أو تنازل صامت عن أصول لن يسأل عنها أحد.
والفرق يظهر أيضًا في التدقيق. الجرد رقم يُكتب في نهاية السنة ويسهل تجميله؛ أما سجل العهدة فسلسلة أحداث مؤرخة، كل حدث فيها له طرف وتوقيت، وهذا ما يجعله قابلًا للاحتكام إليه.
بعض ما في هذه القائمة هو ما بُني عليه نظامي فعليًا — دورة حياة الأصل والتسليم والنقل والإرجاع، وإقرارات العهدة وسجلات الصيانة المرتبطة بسجل الجهاز، وسجل التدقيق التلقائي، ولوحات حالة توزيع الأجهزة على الأقسام — وبقيّتها ما أنصح أي شركة بإضافته عند البناء. وهي نقطة البداية التي أقترحها لمن يريد الخروج من الجداول دون أن يبني شيئًا مبالغًا فيه:
المكوّنات غير مبهرة عمدًا: قاعدة بيانات SQL خلف لوحة تحكم داخلية. بيانات الأصول علائقية بطبيعتها — أجهزة، وموظفون، وعمليات تسليم، وأحداث صيانة — والبنية العلائقية تجعل الإجابة عن الأسئلة المهمة سريعة وسهلة بدل أن تكون جلسة فلترة وتمرير داخل ملف مشترك.
الأسئلة الثلاثة التي يجب أن يجيب عنها النظام فورًا: كل ما بحوزة هذا الموظف الآن، وكل ما مرّ على هذا الجهاز منذ شرائه، وكل ما هو منشور في هذا القسم. إن كان نظامك يحتاج أكثر من بضع ثوانٍ لأي منها، فهو جدول إكسل بواجهة أجمل.
وعمليًا يتحول هذا إلى ثلاث شاشات: صفحة الموظف وفيها عهدته الحالية وسجله السابق، وصفحة الجهاز وفيها تاريخه كاملًا مع إقراراته وسجل صيانته، ولوحة إدارية تُظهر حالة توزيع الأجهزة على الأقسام. وأنصح إضافة إلى ذلك بترقيم كل جهاز برقم أصل ثابت وملصق عليه، لأن الجرد الميداني يعتمد على أن يقرأ الفنّي رقمًا لا أن يجتهد في تمييز طراز من آخر.
النتيجة التي تستحق الدراسة ليست الرقم، بل ما يتطلبه الحفاظ عليه. نظام تتبع كهذا لا ينجح إلا إذا كان المسار الوحيد الذي يمكن أن يتحرك الجهاز عبره: كل تسليم ونقل وإرجاع يمر داخل النظام. عملية تسليم واحدة تتم خارجه — «خذ هذا اللابتوب الآن وسنسجّله لاحقًا» — تعيد مشكلة الجدول بهدوء ودون أن يلاحظ أحد.
لذلك الخلاصة الصادقة لأي شركة تفكر ببناء مشابه: البرمجيات هي النصف الأسهل. النصف الآخر التزام إداري بأن الجهاز لا يتحرك بدون حركة مقابلة في النظام، وأن قسم تقنية المعلومات لا يقبل استثناءً في هذه النقطة مهما كان الطلب مستعجلًا.
والوسيلة العملية لجعل هذا الالتزام ممكنًا هي أن يكون التسجيل أسهل من تجاوزه. إن كان تسليم جهاز داخل النظام أسرع من تسجيله على ورقة، سيلتزم الجميع؛ وإن كان أبطأ وأكثر نماذج، سيلتف الجميع حوله بعد أسابيع قليلة. تصميم النظام هنا ليس ترفًا، بل هو ما يقرر إن كانت السياسة ستُطبّق أم لا.
سأقولها بوضوح رغم أن هذا عملي: إن كانت أجهزتك قليلة، ودوران الموظفين بطيء، والتسليم يحدث مرة كل بضعة أشهر، فجدول منضبط ونموذج تسليم موقّع ومؤرشف جيدًا قد يكفيان. لا داعي لبناء نظام لمشكلة لم تصل إليك بعد.
تتغير الحسبة حين تتراكم هذه العلامات: عدد الأجهزة يتجاوز ما يستطيع شخص واحد تذكّره، ودوران الموظفين يجعل التسليم والاسترجاع حدثًا شهريًا، والمواقع تتعدد، وتظهر أصول عالية القيمة تستحق إثباتًا واضحًا للمسؤولية، أو يطلب منك تدقيق داخلي أو خارجي سجلًا لا تملكه. عند هذه النقطة تكون تكلفة الفوضى قد صارت حقيقية — تُدفع كأجهزة مفقودة ووقت ضائع في البحث بدل أن تُدفع كنظام.
والبداية الصحيحة ليست البرمجة بل جرد افتتاحي صادق: جولة ميدانية واحدة تُثبّت الحقيقة كما هي اليوم — كل جهاز، ومن بحوزته، وبأي حالة — دون محاولة تجميل الأرقام. بعدها يصبح كل شيء حركات داخل النظام. نظام كامل من هذا النوع يُبنى عادةً خلال 4 إلى 8 أسابيع حسب الميزات، وبيانات جداولك الحالية تُنقل ويُتحقق منها قبل التشغيل، والنظام ملكك بالكامل: الكود وقاعدة البيانات والاستضافة والحسابات باسمك. صف لي حجم أصولك وطريقة عملك الحالية، وتحصل على عرض سعر ثابت مكتوب خلال 24 ساعة.
لأن الجدول يخزّن الحالة الحالية فقط: عند تحديث الخلية يختفي من كان يحمل الجهاز قبل ذلك. والعهدة تحتاج تاريخًا كاملًا — تسليم ونقل وإرجاع وصيانة — مربوطًا بإقرارات موقّعة وسجل تدقيق. أضف أن الجدول لا يفرض انضباطًا: لا شيء فيه يمنع تسليم جهاز دون تسجيل، ولا يمنع حذف صف بالخطأ.
لست مستشارًا قانونيًا والصياغة النهائية يراجعها مستشارك، لكن من الناحية التشغيلية يجب أن يربط الإقرار بوضوح: هوية الموظف، ووصف الجهاز مع رقم الأصل والرقم التسلسلي، وتاريخ التسليم، وحالة الجهاز عند الاستلام، وتوقيع الموظف. والأهم أن يُخزَّن مرفقًا بسجل الجهاز داخل النظام لا في مجلد منفصل، حتى يظهر تلقائيًا عند أي استعلام عن ذلك الأصل أو ذلك الموظف.
هذا هو التصميم الطبيعي: سجل الموظف يجب أن يكون مصدرًا واحدًا تقرأ منه بقية الأنظمة بدل أن يُكتب الاسم يدويًا في كل نظام على حدة. بنيت النظامين — منصة الموارد البشرية ونظام إدارة الأصول — داخل الشركة نفسها، وإن كان كل منهما نظامًا قائمًا بذاته، والقاعدة التي أطبّقها أن أي بيان يُدخل مرتين سينحرف مرتين. وحين يُبنى الربط، فهو يعني عمليًا أن مغادرة موظف تُظهر فورًا ما بحوزته قبل إنهاء الخدمة.
نعم، النموذج نفسه ينطبق على أي أصل تُسلَّم مسؤوليته لشخص: المركبات، والأثاث، والأدوات، والهواتف، وبطاقات الدخول. ما يتغير هو الحقول الوصفية وأنواع الصيانة، أما البنية — دورة حياة وأحداث وإقرارات وسجل تدقيق — فواحدة. بنيت النظام أصلًا لأجهزة تقنية المعلومات لأنها كانت مسؤوليتي، لكن المنطق ليس خاصًا بها.
نظام كامل يشمل دورة حياة الأصل والتسليم والإرجاع وإقرارات العهدة وسجلات الصيانة ولوحات الحالة يُبنى عادةً خلال 4 إلى 8 أسابيع حسب الميزات، وبياناتك الحالية تُنقل ويُتحقق منها قبل التشغيل. هذه مدة تسليم حقيقية من أنظمة تعمل الآن في الإنتاج في دبي.
التكلفة تتبع النطاق: عدد الأصول وأنواعها، وعدد المواقع، وهل تحتاج ربطًا بأنظمة أخرى مثل الموارد البشرية، وهل تحتاج جردًا ميدانيًا افتتاحيًا. لهذا لا أنشر أرقامًا عامة — صف لي وضعك الحالي وتحصل على عرض سعر ثابت مكتوب خلال 24 ساعة، بلا رسوم شهرية عن كل مستخدم بعد التسليم.
تطوير برمجيات مخصصة في دبي — صفحة الخدمة · تطوير أنظمة الموارد البشرية في دبي · تطوير أنظمة نقاط البيع في دبي