كل العملية البشرية لشركة واحدة، في نظام واحد.
شركة B.M Enterprises كانت محتاجة مكان واحد لكل حاجة خاصة بالموظف — البيانات الشخصية، حالة الجواز والفيزا، العقود، بيانات العيلة، المستندات، وأصول الشركة — وفوق ده كله الطبقة التشغيلية اليومية: الحضور والانصراف، طلبات الإجازات، ومين المسموح له يشوف أو يعتمد إيه.
بناه فريق من 6 أفراد كموقع ويب وتطبيق موبايل، وبيستخدمه يوميًا أكتر من 50 موظف و50 مستخدم نظام في الشركة.
نبني المنطق التشغيلي، مش مجرد شاشات بيانات.
سهل جدًا إن نظام موارد بشرية يتبنى بشكل ناقص، كمجموعة فورمز فوق قاعدة بيانات. الأجزاء اللي فعلًا كانت مهمة هنا هي اللي وراها قواعد حقيقية.
بروفايل، مش صفحة
البيانات الشخصية، الجواز/الفيزا، العقود، العيلة، المستندات، والأصول — كل واحدة منها سجل مستقل مرتبط بموظف واحد، مش فورم طويل واحد.
الحضور كمنطق، مش مجرد سجل
الدخول والخروج بيحسبوا ساعات الشغل، التأخير، والانصراف المبكر أوتوماتيك — حالة فعلية، مش بس توقيت مكتوب.
الطلبات كتدفق متابع
طلبات الإجازة والانصراف المبكر بتعدي بمراحل إنشاء، مراجعة، وحالة واضحة — مش إيميل بيضيع في الإنبوكس.
باك إند واحد على Supabase، تطبيقين حقيقيين.
الويب والموبايل مكانوش موقع متجاوب وتطبيق إضافي بالعرض — كانوا تطبيقين منفصلين فعليًا، React للويب وReact Native (Expo) للموبايل، شاركوا نفس سكيما الـPostgres، نفس نظام تسجيل الدخول، ونفس منطق العمل عبر Supabase. نفس قواعد الحضور ونفس فحوصات الصلاحيات بتنطبق على أي كلايِنت المستخدم شغّال عليه.
ويب
React · TypeScript
موبايل
React Native · Expo · React Native Paper
باك إند
Supabase — Postgres، تسجيل الدخول، التخزين
البيانات والفورمز
Refine · React Hook Form · Zod
الحالة
Zustand
الصلاحيات
CASL
التواريخ واللغة المحلية
date-fns · date-fns-tz · expo-localization
سير العمل
Git · GitHub
شغلانة مختلفة لكل منصة، نفس القواعد تحتها.
موقع الويب بُني للموارد البشرية والإدارة — بروفايل الموظف الكامل، التقارير، والاعتمادات، حيث شاشة أكبر وكيبورد بيعملوا شغل حقيقي. تطبيق الموبايل بُني للموظفين نفسهم — تسجيل حضور وانصراف من أي مكان هما فيه فعلًا، وتقديم أو تتبع طلب إجازة من غير ما يفتحوا لابتوب.
الاتنين بيقروا ويكتبوا على نفس جداول Supabase ونفس قواعد صلاحيات CASL، فأي تغيير في الدور أو حقل جديد في بروفايل الموظف محتاج يتعرّف مرة واحدة بس عشان يكون صحيح على المنصتين.
الحضور والطلبات كحالة فعلية، مش نص حالة.
أوقات تسجيل الدخول والخروج بتتغذى مباشرة في حسابات ساعات الشغل، التأخير، والانصراف المبكر، محسوبة من قواعد الشِفت الخاصة بالشركة مش متدخلة بإيد. طلب الإجازة أو الانصراف المبكر بيعدي بمراحله الخاصة — مُقدَّم، تحت المراجعة، معتمد أو مرفوض — مع حالة واضحة للموظف اللي قدّم الطلب ولمين محتاج يتصرف فيه، سواء على الويب أو الموبايل.
قرارات جت من تعقيد موارد بشرية حقيقي، مش من قالب.
وأنا براجع الموضوع دلوقتي، تلات قرارات بيعملوا شغل أكبر من شكلهم:
بروفايل هو فعلًا مركز بيانات
الجواز، الفيزا، العقود، العيلة، المستندات، والأصول سجلات مستقلة تحت موظف واحد، مش حقول متكدسة في فورم واحد.
صلاحيات متفعّلة مرة، ومُحترمة مرتين
صلاحيات الأدوار على CASL متعرّفة من مكان واحد ومحترمة من موقع الويب وتطبيق الموبايل — مش معاد تنفيذها في كل شاشة أو كل منصة.
منتجين حقيقيين، مصدر حقيقة واحد
الويب والموبايل تطبيقان منفصلان فعليًا بشغلانة مختلفة، مش كود بيس واحد ممدود عشان يناسب شاشتين — ومع ذلك محدش منهم ممكن يخرج عن مزامنة بيانات التاني.
مبني عشان دور أو نوع طلب جديد ما يعنيش إعادة بناء.
لأن الصلاحيات كانت بتعدي من خلال CASL مش if-checks متفرقة، والطلبات كانت متصممة كمسار حالة عام مش منطق مخصوص لكل نوع طلب، إضافة دور جديد أو نوع طلب جديد كان المفروض يكون تغيير إعدادات — قواعد جديدة ومجموعة حالات جديدة — مش شاشات جديدة من الصفر.
نظام حقيقي، في استخدام يومي، لمدة قد سنتين.
SFYR كان في الخدمة لمدة قد سنتين، بيستخدمه يوميًا أكتر من 50 موظف و50 مستخدم نظام في B.M Enterprises للحضور، الإجازات، وسجلات الموظفين على الويب والموبايل — قبل ما التطوير يتوقف والمشروع ما يكملش.