من أول القرارات التي تُتخذ عند تشغيل أي نظام موارد بشرية، وأقلها نقاشاً: كيف نرقّم الموظفين؟ يبدو سؤالاً إدارياً يُحسم في دقيقة، ثم يعيش الجواب سنوات في كشوف البنك وملفات الاستيراد وتقارير التأمينات وأي تكامل مع نظام آخر. وتغييره بعد سنة ليس تعديل حقل بل مشروع.
المشكلة في الكود الذي يحمل معنى
الإغراء الأول هو أن يحمل الكود معلومة: حرف للقسم، ورقم للفرع، وسنة التعيين. يبدو ذكياً ويوفّر النظر في تقرير. لكن المعلومة داخل الكود تتقادم: الموظف يُنقل بين الأقسام فيصبح كوده كاذباً، أو يُغيَّر الكود فتُكسر كل الإحالات القديمة إليه. والقاعدة التي تعلّمتها الأنظمة بعد عقود: المعرّف يعرّف ولا يصف.
والبديل بسيط: كود عديم المعنى يُمنح مرة ولا يتغيّر أبداً، وكل ما تريد معرفته — القسم والفرع وسنة التعيين — حقول مستقلة تتغيّر بحرية. وبهذا تحصل على الاثنين: معرّف ثابت يصلح للربط، ومعلومة حيّة تعكس الواقع.
قواعد قليلة تكفي
- لا يُعاد استخدام كود موظف ترك العمل — تاريخه ما زال مرتبطاً به.
- طول ثابت وصيغة واحدة، فالأصفار البادئة تضيع في ملفات الإكسل.
- بلا حروف تختلط بالأرقام في القراءة أو النسخ.
- لا يتغيّر عند النقل أو الترقية أو تغيّر الفرع.
- يُمنح للعائد بعد ترك الخدمة كوده القديم لا كوداً جديداً حيث أمكن.
قاعدة الأصفار البادئة أكثرها تسبباً في المشاكل عملياً. الكود «00147» يتحول في إكسل إلى «147»، فيفشل الاستيراد أو يُنشئ موظفاً مكرراً. إن كنت ستستعمل أصفاراً بادئة فاختبر دورة استيراد كاملة قبل التشغيل لا بعده.
الكود ليس المعرّف الوحيد
الموظف في الواقع يحمل عدة معرّفات لكل منها عالمه: كود الموظف داخل الشركة، ورقم الهوية لدى الدولة، والرقم التأميني لدى جهة التأمين، ورقم الحساب لدى البنك، واسم المستخدم في أنظمة تقنية المعلومات. والخطأ الشائع هو محاولة توحيدها أو استعمال أحدها مكان الآخر.
وأخطر صور هذا الخطأ استعمال رقم الهوية ككود موظف. يبدو حلاً أنيقاً لأنه فريد بالفعل، لكنه يعني نشر بيان شخصي حساس في كل تقرير وكل ملف إكسل يُتداول وكل قائمة تُطبع. والقاعدة أن يبقى رقم الهوية حيث تحتاجه الجهات الرسمية فقط، وأن يكون التداول الداخلي بكود لا يحمل قيمة خارج النظام.
كيف يعالج نوفا HR الترقيم
في نوفا HR، كود الموظف يُسجَّل في البيانات الرئيسية داخل وحدة بيانات الموظف، وهي البوابة التي يدخل منها كل موظف جديد. وعند الحفظ يُنشأ للموظف تلقائياً حساب دخول وقائمة صلاحيات ورصيد إجازة افتتاحي — أي أن الكود يصبح مرتبطاً بثلاثة أشياء في اللحظة نفسها، وهو سبب إضافي لضبطه قبل الحفظ لا بعده.
والكود هو مفتاح الربط في أدوات الاستيراد كلها. استيراد بيانات الموظفين يعتمد عليه، والتأمين الطبي المجمّع في وحدة الرعاية والتأمين يرفع ملفاً يحمل كود الموظف ورقم البطاقة، واستيراد بيانات التأمين في وحدة التأمينات الاجتماعية يمضي بقالب أعمدة ثابتة. فالكود ليس تسمية داخلية بل عمود يتكرر في كل ملف يدخل النظام أو يخرج منه.
وهناك قاعدة تحمي الترقيم من الفوضى: لا يمكن حذف موظف له حركات — حضور أو إجازات أو مرتبات — والبديل هو الإيقاف عبر وحدة شؤون الموظفين. وهذا يعني أن الكود لا يتحرر ليُعاد استخدامه، وهو بالضبط السلوك المطلوب: تاريخ الموظف في وحدة الحضور والانصراف وفي وحدة المرتبات والأجور يبقى مرتبطاً بكوده، ولو مُنح الكود لشخص آخر لاختلط تاريخان.
| الأسلوب | ما يبدو عليه اليوم | ما يصير إليه |
|---|---|---|
| كود يحمل رمز القسم | مقروء ومريح | كاذب بعد أول نقل |
| رقم الهوية ككود | فريد بلا مجهود | بيان حساس في كل تقرير |
| إعادة استخدام أكواد | توفير في الأرقام | تاريخان لشخص واحد |
| رقم متسلسل ثابت | بلا معنى | يعمل بعد عشر سنوات |
أسئلة شائعة
هل نغيّر الترقيم القديم عند تشغيل نظام جديد؟
احتفظ بالأكواد القائمة إن أمكن، حتى لو لم تعجبك صيغتها. الموظفون يعرفون أكوادهم، والمستندات القديمة تحملها، والأنظمة الأخرى تشير إليها. وتغييرها يضيف مخاطرة كبيرة إلى مشروع فيه ما يكفي من المخاطر. وإن اضطررت للتغيير فاحتفظ بالكود القديم في حقل مستقل ليبقى الجسر بين ما قبل وما بعد.
ماذا عن العمالة المؤقتة والمتعاقدين؟
أعطهم أكواداً من نفس التسلسل مع حقل يميّز نوع العلاقة، لا تسلسلاً منفصلاً. التسلسلان المنفصلان يبدوان أنظف ثم ينتجان مشكلة معروفة: شخص ينتقل من متعاقد إلى موظف فيصبح له كودان وتاريخان. والتمييز بحقل لا بمساحة ترقيم يجعل الانتقال تغييراً في حقل واحد.