ثمانية مواقع نشطة. مئتا عامل. مجموعة WhatsApp لكل مشروع، ومالك لا يعرف بالمشكلات إلا بعد أن تكلفه المال.
لم تشتر ImarHub كمنتج جاهز، بل صممت حول طريقة عمل العميل الفعلية: تدفق عملياته، وسلاسل الاعتماد، وهيكل المواقع، وتركيبة القوى العاملة. لا العكس.
تواجه معظم شركات الإنشاءات المتوسطة العقبة نفسها مع برمجيات المؤسسات: يبدو المنتج متقنا، لكن التنفيذ يجبر الشركة على إعادة تشكيل عملها حول النظام. وفي النهاية يشغل الموظفون البرنامج بالتوازي مع مجموعات WhatsApp وجداول البيانات التي كان يفترض أن يحل محلها.
بنيت ImarHub لإلغاء هذا النمط من الفشل بالكامل. حددنا كل وحدة ومسار عمل وخطوة اعتماد بما يطابق عمليات العميل قبل كتابة سطر واحد من الشيفرة. تكيف النظام مع العمل، فأصبح اعتماده مسألة أيام لا أشهر.
هذا بناء لمرة واحدة من دون ترخيص متكرر، أو رسوم لكل مستخدم، أو اعتماد على مورد. يعمل على بنية تحتية يتحكم فيها العميل، ويمكنه التوسع إلى مواقع ومستخدمين ووحدات جديدة من دون سقف تجاري.
العميل مقاول باطن سعودي للأعمال المدنية والميكانيكية والكهربائية والصحية (MEP)، يعمل في أنحاء المملكة منذ أكثر من 15 عاما. نمت الشركة من مقاول تشطيبات لموقع واحد إلى شركة مقاولات باطن تدير عدة مشاريع وتشمل أعمالها الإنشاءات المدنية وتركيبات MEP وحزم البنية التحتية لكبار المطورين العقاريين والمقاولين الرئيسيين المرتبطين بجهات حكومية.
عندما تعاقد العميل مع AppWorx، كان يدير من 8 إلى 12 موقعا نشطا في الوقت نفسه، ويوظف أكثر من 230 عاملا من جنسيات باكستانية وهندية ومصرية وفلبينية، بقيمة عقود سنوية تبلغ نحو 22 مليون دولار.
كانت لدى الشركة العقود، لكنها لم تملك الأنظمة التي تواكب الحجم الذي وصلت إليه.
لم يكن الألم التشغيلي مشكلة واحدة. كان يمكن التعامل مع كل مشكلة منفردة، لكنها مجتمعة صنعت سقفا تشغيليا يعطل النمو.
كان المالك يقضي وقته في ملاحقة معلومات يفترض أن يظهرها النظام تلقائيا. لم يتعطل النمو بسبب نقص العقود، بل بسبب إدارة عملية تتجاوز قيمتها 20 مليون دولار على بنية صممت لعملية بقيمة مليوني دولار.
كان الإبلاغ عن التقدم يتم بصورة غير رسمية عبر الرسائل الصوتية وصور WhatsApp وجداول بيانات متضاربة. عندما احتاج المالك إلى نسبة الإنجاز الفعلية في مبنى أو منطقة محددة، تطلبت الإجابة سلسلة من المكالمات.
عبر ثمانية مواقع، جعل هذا التأخير كل قرار مبنيا على معلومات قديمة؛ فتوزيع العمالة ونشر الموارد وتحديثات العميل كلها اعتمدت على معلومات تصل بعد فوات الأوان.
كانت المستخلصات المالية تنشأ في Word أو Excel، ثم تطبع وتوقع وتمسح ضوئيا وترسل بالبريد الإلكتروني. وتحولت المراجعات إلى نسخ ملفات بلا سجل موثوق.
تكررت النزاعات حول الكميات المعتمدة لغياب مسار تدقيق، فلم يوجد سوى روايات متعارضة وإصدارات مختلفة من جداول البيانات. كلف كل نزاع أياما من وقت الشؤون التجارية.
كان مهندس الموقع يحدد احتياجا للمواد ويرسل رسالة إلى المشتريات، وقد ينفذ الطلب أو لا ينفذ. لم يوجد سجل يوضح من طلب ماذا، ومتى اعتمد، وهل تم الشراء، أو هل وصلت المواد.
اجتمع فائض المخزون ونقصه داخل محفظة المشاريع نفسها. بقيت مواد راكدة في موقع، بينما توقف العمل في موقع آخر بانتظار مواد كان يفترض أن تكون موجودة.
لم يكن مراقبو العمال يملؤون التقارير اليومية للمواقع بانتظام. وتوزعت الصور بين ألبومات الهواتف الشخصية ودفعات WhatsApp بلا هيكل واضح.
التقرير اليومي للموقع وثيقة قانونية بموجب معظم عقود الإنشاءات الخليجية. لكن السجل الفعلي كان مجموعة رسائل، لا تقريرا منظما ومؤرخا زمنيا.
عندما تغير نطاق العمل في الموقع، كانت التعليمات تصل شفهيا أو عبر رسائل WhatsApp غير رسمية. ينفذ العمل، ثم تقدم مطالبات الدفع لاحقا، من دون سجل رسمي لأوامر التغيير يثبت الإشعار في وقته.
بموجب العقود الخليجية القائمة على FIDIC، قد ترفض مطالبة أمر تغيير لا تحمل سجل تقديم مؤرخا وقت صدور التعليمات، حتى إذا نفذ العمل. كانت هذه أخطر فجوة مالية في العملية.
مع أكثر من 200 عامل عبر ثمانية مواقع، تسببت سجلات الحضور الورقية في أخطاء الرواتب وفروق أعداد العمال اليومية ونقاط عمياء في الإنتاجية.
لم توجد طريقة موثوقة لمعرفة عدد العمال من كل حرفة في كل موقع خلال أي يوم، إلا بالاتصال بمراقب العمال والأمل في أن يكون العدد دقيقا.
بنيت ImarHub في سبع طبقات تشغيلية، لكل منها نطاق محدد وواجهات واضحة مع الطبقات التي تعمل بجانبها.
يحصل المالك على عرض موحد للمحفظة كاملة: كل مشروع نشط، ونسبة الإنجاز الحالية، والميزانية المستهلكة مقارنة بقيمة العقد، وقيمة أوامر التغيير القائمة، والاعتمادات المتأخرة، وتوقيت آخر تقرير يومي للموقع.
بني لمراقبي العمال ومهندسي المواقع الذين يعملون وسط اتصال متقطع وشمس مباشرة وشاشات مغبرة وبيئة ميدانية متعددة الجنسيات.
الوحدة الأكثر حساسية ماليا: محرك لدورة الاعتماد كاملة، من تقديم مطالبة مستخلص الدفعة المرحلية (IPC)، مرورا بالتعديل والاعتماد وإنشاء المستند والإقرار والنزاع، ووصولا إلى متابعة الإفراج عن المبالغ المحتجزة.
سجل لأوامر التغيير يوثق تغيرات النطاق عند صدور التعليمات، ويرفق الأدلة، ويرسل الإشعارات الرسمية، وينشئ سجلات زمنية موقعة وثابتة تحمي مقاول الباطن تعاقديا.
نموذج هرمي لجدول الكميات ببنية شجرية متكررة، وحسابات آنية للقيمة المكتسبة، وطلبات مواد مرتبطة ببنود جدول الكميات، واعتمادات مشتريات، وتأكيد للتسليم، وتنبيهات مخزون تراعي الجدول الزمني.
سجل للرسومات حسب الرقم والعنوان والمراجعة والحالة. يتلقى مستخدمو تطبيق الموقع أحدث مراجعة دائما، وتؤرشف الرسومات الملغاة، وتتابع طلبات المعلومات (RFI)، وتسجل المراسلات الرسمية، وتمنع تنبيهات انتهاء المستندات فجوات الامتثال.
بوابة خفيفة عبر رابط آمن، تتيح لمقاولي الباطن عرض المستخلصات المالية، وتقديم مطالبات IPC، والإقرار بالقيم المعتمدة، وتسجيل النزاعات، وتنزيل سجلات PDF الرسمية من دون حساب كامل على المنصة.
أرباح وخسائر حية للمشروع، وإيرادات معتمدة، وتكاليف ملتزم بها، وهامش نهائي متوقع، وتوقعات التدفق النقدي، وملخص للمبالغ المحتجزة، ومعالجة ضريبة القيمة المضافة، وتصدير محاسبي متوافق مع Xero وQuickBooks وSage.
معمارية نظيفة على .NET 10، وقاعدة PostgreSQL، وتطبيق React Native، وواجهات عربية باتجاه RTL في المقام الأول، وسجلات تدقيق ثابتة، وإشعارات عبر WhatsApp Business API.
معمارية نظيفة بطبقات المجال والتطبيق والبنية التحتية وAPI. صندوق أحداث صادر مدعوم بـSQL للإشعارات وإنشاء المستندات وأحداث إعادة الحسابات المالية.
مخطط جدول كميات محسن باستخدام CTE متكرر، مع نماذج قراءة منفصلة لتجميع بيانات لوحة المحفظة، حتى لا تستعلم التقارير من جداول معاملات جانب الكتابة.
تطبيق جوال يعطي الأولوية للعمل دون اتصال، مع مخزن SQLite محلي واكتشاف تعارض قائم على الساعة المتجهة لعمليات الإرسال الميدانية المتزامنة عبر مواقع متعددة.
محرك قوالب يدعم العربية واتجاه RTL، وتنسيق الأرقام العربية، وتخطيط الجداول ثنائي الاتجاه، والتخزين الثابت لملفات PDF المولدة للمستخلصات.
تكتب الإجراءات الحساسة في سجل تدقيق يقتصر على الإضافة ضمن معاملة قاعدة البيانات نفسها. ولا يمكن اعتماد مستخلص من دون إدخال السجل.
يحدد وصول المالك ومدير المشروع ومهندس الموقع ومدير الشؤون التجارية والمدير حسب المشروع، وتدمج الصلاحيات عبر أدوار قابلة للتركيب.
العربية واتجاه RTL هما الأساس، مع قلب التخطيط بالكامل عند تبديل اللغة، ووضع عرض قائم على الأيقونات للعمال الميدانيين الذين يعملون بلغة ثالثة.
ترسل التنبيهات التشغيلية إلى صاحب الدور المعني عبر WhatsApp Business API، ولا تقتصر على مركز الإشعارات داخل التطبيق.
أصبح ما كان يتطلب مكالمات هاتفية ظاهرا من دون سؤال. تظهر التقارير اليومية المتأخرة تلقائيا. وتتحرك المستخلصات المالية عبر دورة اعتماد موثقة. وتسجل أوامر التغيير عند صدور التعليمات، لا عند تقديم المطالبة.
ظهر الأثر التجاري على علاقات مقاولي الباطن فورا. انخفضت جولات النزاع على الاعتماد لأن الطرفين يعملان من الكميات المقاسة نفسها داخل النظام نفسه، مع تعديلات ظاهرة وموثقة.
تواصل AppWorx تطوير ImarHub بموجب عقد تطوير مستمر. المرحلتان الأولى والثانية قيد التشغيل، والمرحلتان الثالثة والرابعة قيد التطوير النشط.
الخلفية التي يمتلكها محمود في الإنشاءات المدنية ليست عبارة تسويقية. إنها الفارق بين وكالة تتعلم معنى المستخلص المالي، وشريك يفهم بالفعل دورة مستخلصات FIDIC، وحماية توقيت أوامر التغيير، وهيكل جدول الكميات، وقيود المزامنة الميدانية.
اختصرت هذه الخبرة مرحلة الاستكشاف. لم تحتج المخاطر إلى شرح، وحدد نطاق القرارات التقنية ومسار التدقيق الثابت ومخطط جدول الكميات المتكرر وحل التعارض بالساعة المتجهة ونموذج التوقيت التعاقدي بصورة صحيحة منذ البداية.
الاعتراض الشائع لدى مقاولي الباطن الخليجيين على Procore هو ارتفاع تكلفته وطابعه الغربي وامتلاؤه بخصائص لا يحتاجون إليها. بنيت ImarHub لنموذج التشغيل الفعلي: منطق المستخلصات، وتركيبة القوى العاملة، ومتطلبات المستندات، والبنية اللغوية، وواقع المواقع.
«هكذا يبدو النظام عندما يبنيه أشخاص يفهمون العملية من داخلها.»
ثمانية مواقع. قبل ImarHub، لم أكن أعرف ما يحدث في الموقع إلا عندما أتصل بمراقب العمال. الآن أفتح شاشة واحدة فأجد كل شيء: نسب الإنجاز، والتقارير اليومية للمواقع (DSR)، وسجل أوامر التغيير، وحالة المستخلصات المالية. حماية توقيت أمر التغيير وحدها حمتنا بالفعل في مطالبة كان سيرفضها الإجراء القديم.
أخبرنا بما تديره وكيف تديره. سنخبرك بصراحة ما إذا كان الحل نظاما مخصصا، وإن كان كذلك، فما الذي يتطلبه بناؤه فعليا.