وكيل الذكاء الاصطناعي الشخصي مثل Claude Duet وChatGPT dots يعمل لشخص واحد: يقرأ بريده وتقويمه وتطبيقاته، وينجز مهامه الشخصية. أما ProjectVIEW AI فيمنح كل مستخدم في الشركة وكيل ذكاء اصطناعي شخصياً، لأنه يرث ملف كل مستخدم ودوره من ProjectVIEW ERP. وبذلك يحصل مدير المشروع ومراقب التكاليف والمدير المالي كلٌّ على مساعده الخاص، الذي يعمل على بيانات الشركة ضمن دوره وصلاحيات الاعتماد الخاصة به وفي بيئة خاصة.

ما هما Claude Duet وChatGPT dots؟

كلاهما وكيل ذكاء اصطناعي يعمل باستمرار، وقد أُطلقا في خريف 2026. يعملان في الخلفية على حاسوب سحابي خاص بهما، ويتصرفان نيابةً عن مستخدم واحد.

• Claude Duet (من Anthropic، نسخة معاينة بحثية منذ أكتوبر 2026) يرسل ملخصاً قصيراً كل صباح، ويراجع التطبيقات المتصلة كل بضع ساعات، وينفذ المهام. وبالإضافة إلى ذلك، يطلب الإذن قبل أن يرسل أو يدفع أو يوقّع أو يحذف أي شيء.
• ChatGPT dots (من OpenAI، أُطلق في سبتمبر 2026) يمنح كل مستخدم وكيلاً شخصياً يُسمى «dot». ويعمل عبر تطبيقات مثل Gmail وGoogle Calendar وSlack وTeams.

باختصار، هما مساعدان شخصيان يتمتعان بحسن التقدير. ويجيبان جيداً عن سؤال بسيط: «ما الذي يجب أن أنجزه أنا اليوم، وما الذي يمكنك أن تنجزه عني؟».

لماذا لا يستطيع الوكيل الشخصي إدارة عمليات الشركة؟

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

لذلك، يواجه الوكيل الشخصي ثلاثة قيود في الشركات القائمة على المشاريع:

1. لا يعرف نموذج التشغيل لديكم. يرى رسائل عن المشروع، لكنه لا يرى هيكل التكاليف الذي خلفه.
2. يعمل بصلاحيات شخص واحد. تحتاج قرارات الأعمال إلى بيانات الشركة كلها، مصفاةً حسب الدور، لا إلى بريد مستخدم واحد.
3. يعمل خارج إطار الحوكمة. الاعتمادات وفصل المهام وسجلات التدقيق جزء من نظام الشركة، لا من مساعد شخصي.

يلخص الجدول التالي الفرق.

كيف يصبح ProjectVIEW AI وكيل ذكاء اصطناعي شخصياً لكل دور؟

لا ينشئ ProjectVIEW AI قائمة مستخدمين ثانية. بل يرث ملف كل مستخدم من ProjectVIEW ERP. وبذلك يعرف الذكاء الاصطناعي منذ اليوم الأول من يسأل، وما الذي يُسمح له برؤيته وفعله.

يرث الذكاء الاصطناعي خمسة عناصر من ملف ERP:

1. حساب المستخدم: من يطرح السؤال.
2. الدور: مثل مدير المشروع أو مراقب التكاليف أو مدير المشتريات أو المدير المالي.
3. التكليفات: الشركات والمشاريع المشتركة والمشاريع التي يعمل عليها.
4. الصلاحيات: الوصول على مستوى الوحدة والوظيفة والحقل والسجل.
5. موقعه في سير العمل: أي المستندات والقرارات يُعدّها أو يراجعها أو يعتمدها.

لذلك يحصل السؤال نفسه على إجابة مختلفة وصحيحة لكل دور. فعند سؤال «ما الذي يحتاج إلى انتباهي هذا الأسبوع؟» مثلاً:

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

هذا المساعد القائم على الأدوار متاح اليوم في ProjectVIEW ERP، ويمكن مشاهدته في عرض توضيحي عند الطلب.

باختصار، يخصّص Claude Duet وChatGPT dots الذكاء الاصطناعي حول تطبيقات الشخص الخاصة. أما ProjectVIEW AI فيخصّصه حول دوره في الشركة. وبما أن الملف يأتي من ERP، فلا حاجة إلى إدارة مجموعة صلاحيات منفصلة، ولا يرى أحد عبر الذكاء الاصطناعي أكثر مما يراه في ERP.

لماذا يجب أن يفهم ذكاء الأعمال كل شركة على حدة؟

نادراً ما يعمل مقاولان في السوق نفسها بالطريقة نفسها. أحدهما ينفذ الأعمال المدنية بنفسه، والآخر يسند كل شيء تقريباً إلى مقاولين من الباطن. أحدهما يقسم المشروع إلى 300 رمز تكلفة، والآخر يستخدم 3,000. كما تختلف سلاسل الاعتماد ومنطق التسعير وهياكل المشاريع المشتركة.

مثلاً، تطرح الشركتان السؤال نفسه: «هل يتجاوز مشروع البرج ميزانيته؟».

• المقاول أ ينفذ الهيكل بنفسه. التجاوز لديه في رموز تكاليف العمالة، لأن الإنتاجية في الموقع أقل من المعدل المفترض في الميزانية.
• المقاول ب يسند الهيكل إلى مقاول من الباطن. التجاوز لديه سببه تغييرات اعتمدها الموقع ولم يصدّقها أحد، فلم تُفوتَر للعميل.

يعطي الذكاء الاصطناعي العام الشركتين الإجابة المتوسطة نفسها. وفي أعمال ذات هوامش ضيقة، تكون الإجابة المتوسطة غالباً إجابة خاطئة. في المقابل، يعطي ProjectVIEW AI كل شركة إجابة مختلفة، لأنه يتتبع السبب في سجلاتها الخاصة.

كيف يمنح ProjectVIEW ERP الذكاء الاصطناعي نموذجاً دقيقاً لأعمالكم؟

جودة الذكاء الاصطناعي من جودة الهيكل الذي يقرؤه. لذلك يعمل ProjectVIEW AI فوق ProjectVIEW ERP، نظام ERP المتكامل المبني على إطار BoQ WBS Cost Codes.

• BoQ (جدول الكميات): ما تبيعونه وتحصلون على مقابله.
• WBS (هيكل تجزئة العمل): كيف تخططون له وتنفذونه.
• رموز التكاليف: كم يكلف، بنداً ببند.

يربط ProjectVIEW ERP هذه الهياكل الثلاثة في سجل واحد. وبالإضافة إلى ذلك، يكيّف مُكوّن النظام ومحرك سير العمل العمليات والاعتمادات مع طريقة عمل كل شركة. لذلك لا يخمّن الذكاء الاصطناعي نموذج التشغيل لديكم، بل يقرؤه.

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

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

ماذا يحدث لبياناتكم عند سؤال ProjectVIEW AI؟

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

1. تطرحون سؤالاً في مساعد ProjectVIEW AI.
2. يطبّق ProjectVIEW AI ملف المستخدم والدور من ERP. لا تصلون إلا إلى الوحدات والحقول والسجلات التي يسمح بها دوركم.
3. يسترجع الذكاء الاصطناعي سجلات ERP ذات الصلة في تلك اللحظة.
4. يعمل النموذج في بيئة خاصة على Microsoft Azure أو على خوادمكم. ولا تُرسل البيانات إلى خدمات ذكاء اصطناعي عامة موجهة للمستهلكين.
5. تحصلون على إجابة، وعند الحاجة على إجراء مقترح. ويعتمد شخصٌ كل إجراء مهم.
6. يُسجَّل القرار في سجل التدقيق.

على Microsoft Azure، لا تُستخدم الأسئلة لتدريب النماذج. كما تتوفر خيارات لموقع تخزين البيانات، والتشفير أثناء التخزين، ومفاتيح يديرها العميل. وتحمل DANAOS Projects شهادات ISO 27001 وISO 9001 وISO 14001 وISO 20000-1. للتفاصيل، راجعوا أمن البيانات وحوكمتها في ProjectVIEW AI.

كيف يعمل الوكلاء الشخصيون وProjectVIEW AI معاً؟

يكمّل المستويان أحدهما الآخر. يمكن لمديرة مشروع أن تستخدم الاثنين في صباح واحد:

1. يُعدّ وكيلها الشخصي ملخص الصباح، ويصوغ الردود، ويحجز اجتماعاً مع العميل.
2. ينبّه ProjectVIEW AI إلى أن حزمتين من أعمال الباطن تتجهان لتجاوز الميزانية ويبيّن السبب.
3. تعتمد الإجراء التصحيحي في ProjectVIEW ERP، ويُسجَّل القرار.

وبالإضافة إلى ذلك، يتضمن ProjectVIEW ERP v12 موصل MCP لـClaude وChatGPT. وMCP (Model Context Protocol) معيار مفتوح يربط مساعدات الذكاء الاصطناعي بأنظمة الأعمال بطريقة منضبطة. وينبغي لمن يستخدمه الاتصال عبر مساحات عمل مؤسسية ومراجعة شروط البيانات في كل خطة، لأن البيانات تخرج من البيئة الخاصة عندما يقرؤها مساعد خارجي.

ما الأخطاء التي يجب أن تتجنبها الشركات؟

• لصق البيانات التشغيلية في أدوات ذكاء اصطناعي شخصية. يبدو ذلك سريعاً، لكن أسعار العطاءات والهوامش تخرج عن سيطرة الشركة.
• تشغيل الذكاء الاصطناعي على ملفات مصدّرة بدل السجلات الحية. تفقد الملفات المصدّرة حداثتها خلال أيام، وكذلك الإجابات.
• البدء بالذكاء الاصطناعي قبل تنظيم هيكل التكاليف. إذا لم تترابط BoQ وWBS ورموز التكاليف، فلن يستطيع أي ذكاء اصطناعي تفسير الهامش.
• تجاوز الاعتمادات. يجب أن يُعدّ الذكاء الاصطناعي القرارات، ويتخذها البشر.

كيف يقرر التنفيذيون أي ذكاء اصطناعي يستخدمون لكل مهمة؟

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

يستغرق التطبيق الكامل لـProjectVIEW ERP من 5 إلى 7 أشهر. كما يمكن أن يعمل ProjectVIEW AI فوق أنظمة قائمة مثل SAP وOracle وPrimavera P6، لذا يمكنكم البدء بالمجال الأكثر إلحاحاً. ويعتمد السعر على الوحدات وعدد المستخدمين وخيار النشر.

الأسئلة الشائعة

هل يغني Claude Duet أو ChatGPT dots عن مساعد ذكاء اصطناعي لنظام ERP؟

لا. هما وكيلان شخصيان يعملان لمستخدم واحد في تطبيقاته. أما عمليات الشركة فتحتاج إلى ذكاء اصطناعي يقرأ نظام السجلات ضمن الأدوار والاعتمادات والتدقيق.

هل ProjectVIEW AI وكيل ذكاء اصطناعي شخصي لكل مستخدم؟

نعم. يرث ProjectVIEW AI ملف كل مستخدم ودوره وتكليفاته وصلاحياته من ProjectVIEW ERP. لذلك يحصل كل مستخدم على إجابات وإجراءات مقترحة تناسب دوره، ولا يرى أبداً أكثر مما يسمح به ERP.

هل يعمل ProjectVIEW AI مع Claude أو ChatGPT؟

نعم. يتضمن ProjectVIEW ERP v12 موصل MCP لـClaude وChatGPT. استخدموا مساحات عمل مؤسسية وراجعوا شروط البيانات في كل خطة.

هل تُستخدم بياناتنا لتدريب نماذج الذكاء الاصطناعي؟

على Microsoft Azure، لا تُستخدم الأسئلة لتدريب النماذج. ويسترجع ProjectVIEW AI سياق ERP عند السؤال، فلا حاجة لإعادة التدريب على بيانات العميل.

هل يتخذ ProjectVIEW AI القرارات بنفسه؟

لا. يُعدّ التحليلات والإجراءات المقترحة فقط. ويعتمد شخصٌ كل إجراء مهم، ويُسجَّل القرار.

Read more: وكيل ذكاء اصطناعي شخصي لكل دور في الشركة: ProjectVIEW AI

أنظمة ERP للبناء في الفلبين التي تستحق التقييم لعام 2027 ستة: ProjectVIEW ERP وSAP S/4HANA وOracle Fusion Cloud ERP وMicrosoft Dynamics 365 وIFS Cloud وAcumatica Construction Edition. لذلك ينبغي للمقاولين الكبار وشركات EPC ومطوري البنية التحتية إعطاء الأولوية للتحكم في تكاليف المشاريع القائم على جدول الكميات (BoQ) وللتكامل على مستوى المؤسسة. في المقابل، تحتاج شركات المقاولات الصغيرة والمتوسطة عادةً أولاً إلى محاسبة المقاولات وتكاليف الأعمال.

باختصار، هذا دليل عملي لأبرز حلول ERP للبناء المخصّصة للمقاولين وشركات EPC ومطوري البنية التحتية والشركات الهندسية في الفلبين.

لماذا يحتاج المقاولون إلى أنظمة ERP للبناء في الفلبين؟

يمثّل اختيار برنامج تخطيط موارد المؤسسات (ERP) المناسب للبناء قراراً مهماً لشركات المقاولات الفلبينية. والسبب أنها تدير مشاريع معقدة، وتكاليف مواد متزايدة، ومقاولين من الباطن، ومعدات، وعمليات موزعة على مواقع وجزر عديدة.

في عام 2027، يحتاج المقاولون إلى ما هو أكثر من برامج المحاسبة. بعبارة أخرى، هم بحاجة إلى منصات متكاملة تربط تقدير التكاليف والموازنات والمشتريات والجدولة وإدارة الموارد والأداء المالي للمشروع.

كما أن ثلاثة عوامل محلية تجعل التكامل مهماً بشكل خاص للمقاولين في الفلبين. أولاً، كثيراً ما تتوزع المشاريع على عدة جزر، ما يصعّب رفع التقارير من الموقع إلى المكتب الرئيسي. ثانياً، تتطلب عقود البنية التحتية العامة والشراكة بين القطاعين العام والخاص (PPP) سجلات مفصلة للتقدم والتغييرات والمطالبات. ثالثاً، يجب تطبيق قواعد الضرائب والتقارير الصادرة عن مكتب الإيرادات الداخلية (BIR) بشكل صحيح في الوحدة المالية. نتيجة لذلك، فإن نظام ERP الذي يربط بيانات الموقع والعقود والمحاسبة في نظام واحد يقلّل التسويات اليدوية في هذه المجالات الثلاثة.

بناءً على ذلك، نعرض فيما يلي ستة أنظمة ERP للبناء تستحق التقييم، يخدم كلٌّ منها متطلبات أعمال مختلفة.

ما أفضل أنظمة ERP للبناء في الفلبين لعام 2027؟

1. ProjectVIEW ERP من DANAOS Projects

الأنسب لـ: كبار مقاولي البناء، وشركات EPC، ومطوري البنية التحتية، والشركات الهندسية كثيفة رأس المال.

ProjectVIEW ERP منصة ERP مؤسسية مخصّصة لقطاع البناء، وقد صمّمتها DANAOS Projects لدمج تنفيذ المشاريع مع الإدارة المالية والتشغيلية.

القدرات الرئيسية:

• تكامل جدول الكميات (BoQ) وهيكل تجزئة العمل (WBS) ورموز التكلفة
• موازنة المشاريع والتنبؤ بها والتحكم في التكاليف
• إدارة المشتريات والمقاولين من الباطن والمعدات
• تقدير التكاليف والمناقصات وإدارة العقود
• إضافة إلى التكامل مع Primavera P6 وBIM وأنظمة المؤسسات الخارجية

اعتبار رئيسي: مناسب بشكل خاص للمقاولين الكبار، لأنهم يحتاجون إلى تحكم مفصّل في التكاليف على مستوى المشروع. ولدى DANAOS أيضاً مكتب فرعي في بونيفاسيو غلوبال سيتي (BGC) في تاغيغ لخدمة العملاء في الفلبين.

2. SAP S/4HANA

الأنسب لـ: مجموعات البناء الكبيرة التي تحتاج إلى إدارة مالية على مستوى المؤسسة وعمليات أعمال موحّدة.

SAP S/4HANA منصة ERP مؤسسية شاملة تستخدمها قطاعات متعددة، على سبيل المثال الهندسة والبناء.

القدرات الرئيسية:

• الإدارة المالية والتوحيد على مستوى المؤسسة
• المشتريات وإدارة سلسلة الإمداد
• إدارة الأصول
• محاسبة المشاريع والتقارير
• كما يدعم عمليات متعددة الشركات ومتعددة الجنسيات

اعتبار رئيسي: خيار قوي للمجموعات الكبيرة المتنوعة. ومع ذلك، قد تتطلب سير العمل الخاصة بالبناء مكونات SAP إضافية أو تكاملات أو إعدادات.

3. Oracle Fusion Cloud ERP

الأنسب لـ: المؤسسات الكبيرة التي تعطي الأولوية للحوكمة المالية والمشتريات والعمليات السحابية.

كذلك يوفّر Oracle Fusion Cloud ERP مجموعة متكاملة من التطبيقات المالية والتشغيلية.

القدرات الرئيسية:

• المحاسبة المالية والتقارير
• المشتريات وإدارة الموردين
• الإدارة المالية للمشاريع
• الموازنة والتخطيط على مستوى المؤسسة
• إضافة إلى التحليلات وسير العمل المالي المؤتمت

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

4. Microsoft Dynamics 365

الأنسب لـ: المقاولين المتوسطين والكبار الباحثين عن إدارة مؤسسية مرنة وتكامل مع منظومة Microsoft.

من جهته، يقدّم Microsoft Dynamics 365 تطبيقات أعمال تغطي المالية وسلسلة الإمداد والعمليات والإجراءات المتعلقة بالمشاريع.

القدرات الرئيسية:

• الإدارة المالية والتقارير
• المشتريات وإدارة المخزون
• عمليات المشاريع
• تحليلات Power BI
• إضافة إلى التكامل مع Microsoft 365 وPower Platform

اعتبار رئيسي: يوفّر مرونة كبيرة، إلا أن الوظائف الخاصة بالبناء قد تعتمد على تطبيقات الشركاء والتخصيص.

5. IFS Cloud

الأنسب لـ: شركات الهندسة والبناء والشركات كثيفة الأصول التي تدير مشاريع ومعدات معقدة.

أما IFS Cloud فيجمع بين قدرات تخطيط موارد المؤسسات وإدارة الأصول وإدارة الخدمات.

القدرات الرئيسية:

• إدارة دورة حياة المشروع
• تكاليف المشاريع والإدارة المالية
• المشتريات وعمليات سلسلة الإمداد
• إدارة المعدات والأصول
• كذلك تخطيط الموارد والتحليلات التشغيلية

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

6. Acumatica Construction Edition

الأنسب لـ: شركات البناء الصغيرة والمتوسطة التي تبحث عن محاسبة مقاولات وإدارة مشاريع متكاملة.

أخيراً، Acumatica Construction Edition حل ERP سحابي بقدرات مالية وإدارية للمشاريع موجّهة لقطاع البناء.

القدرات الرئيسية:

• محاسبة المقاولات وتكاليف الأعمال
• موازنة المشاريع وتتبع التكاليف
• أوامر الشراء وإدارة عقود الباطن
• إدارة أوامر التغيير
• إضافة إلى تقارير المشاريع ولوحات المعلومات

اعتبار رئيسي: مناسب بشكل خاص للمقاولين النامين الباحثين عن إدارة مالية وإنشائية متكاملة. ومع ذلك، يجب التأكد من التوطين للفلبين وتغطية الشركاء ودعم التنفيذ.

كيف نقارن أنظمة ERP للبناء في الفلبين؟

باختصار، يلخّص الجدول التالي نقطة القوة الرئيسية والشركات المستهدفة لكل منصة من المنصات الست في هذا الدليل.

كيف تختار بين أنظمة ERP للبناء في الفلبين؟

قبل وضع قائمة مختصرة من أنظمة ERP للبناء في الفلبين، ينبغي للشركات أولاً تقييم خمسة متطلبات:

1. وظائف مخصّصة للبناء: هل تدعم المنصة الموازنة القائمة على جدول الكميات، وإدارة المقاولين من الباطن، والتغييرات، وتتبع تكاليف المشاريع؟
2. وضوح تكاليف المشاريع: بعبارة أخرى، هل تستطيع الإدارة مقارنة الموازنات والالتزامات والتكاليف الفعلية وتقدّم المشروع؟
3. قدرات التكامل: هل يستطيع النظام تبادل المعلومات مع Primavera P6 وأدوات BIM ومنصات المحاسبة الحالية والأنظمة الأخرى؟
4. قابلية التوسع: كذلك، هل يدعم النظام شركات متعددة ومشاريع كبيرة وعمليات موزعة جغرافياً؟
5. التنفيذ والدعم: أخيراً، هل تتوفر موارد تنفيذ مؤهلة؟ وهل يغطي المورّد المتطلبات التنظيمية في الفلبين وترتيبات الدعم طويلة الأمد بشكل كافٍ؟

على سبيل المثال، من الاختبارات المفيدة معرفة ما إذا كان المورّد قد بنى المنصة حول هياكل المشاريع أم كيّفها من برامج أعمال عامة. كما تشرح مقارنتنا بين ProjectVIEW وأنظمة ERP العامة الفرق بمزيد من التفصيل.

أيّ أنظمة ERP للبناء في الفلبين يناسب شركتك؟

في الواقع، لا يوجد نظام ERP واحد للبناء هو الأفضل لكل المقاولين في الفلبين.

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

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

الأسئلة الشائعة

ما هو نظام ERP للبناء؟

باختصار، نظام ERP للبناء برنامج مؤسسي يربط تقدير التكاليف والموازنات والمشتريات والمقاولين من الباطن والمعدات والعمالة والمحاسبة حول المشروع. وعلى خلاف برامج المحاسبة العامة، يتتبع التكاليف وفق هيكل المشروع، مثل جدول الكميات وهيكل تجزئة العمل.

ما الفرق بين نظام ERP للبناء وبرنامج المحاسبة؟

يسجّل برنامج المحاسبة ما أنفقته الشركة بالفعل. في المقابل، يتتبع نظام ERP للبناء أيضاً الموازنات والالتزامات والتقدّم والتوقعات لكل مشروع. وبالتالي ترى الإدارة تجاوزات التكاليف قبل وصولها إلى الدفاتر.

كم يستغرق تنفيذ نظام ERP للبناء؟

يعتمد ذلك على النطاق وعدد الوحدات والتكاملات المطلوبة. على سبيل المثال، يستغرق تنفيذ ProjectVIEW ERP عادةً من 5 إلى 7 أشهر.

كم تكلفة أنظمة ERP للبناء في الفلبين؟

تختلف التكلفة باختلاف المورّد ونموذج الترخيص ونطاق التنفيذ، لذا ننصح بطلب عروض أسعار بالمتطلبات نفسها من كل مورّد في القائمة المختصرة. أما ProjectVIEW ERP فيعتمد سعره على الوحدات وعدد المستخدمين وخيار النشر. اطّلع على أسعار ProjectVIEW ERP أو اطلب عرضاً من فريقنا.

هل لدى DANAOS وجود في الفلبين؟

نعم. إذ لدى DANAOS مكتب فرعي في بونيفاسيو غلوبال سيتي (BGC) في تاغيغ بمترو مانيلا، يخدم العملاء في الفلبين وجنوب شرق آسيا.

شاهد كيف يدير ProjectVIEW ERP التحكم في التكاليف القائم على جدول الكميات في مشاريعك.

احجز عرضاً توضيحياً

Read more: أفضل 6 أنظمة ERP للبناء في الفلبين لعام 2027

أُطلق ProjectVIEW ERP v12 رسميًا، وهو متاح الآن لجميع عملاء DANAOS Projects. أولاً، يدمج الإصدار 12 أداة ProjectVIEW AI في طريقة إدارة المستخدمين لعملياتهم وتنفيذها وتحسينها. كما يضيف وحدة إنتاج جديدة تغطي التصنيع القائم على المشاريع من البداية إلى النهاية. بالإضافة إلى ذلك، يقدّم موصل MCP يتيح لمساعدي الذكاء الاصطناعي مثل Claude وChatGPT العمل مباشرةً مع ProjectVIEW.

ما الجديد في ProjectVIEW v12؟

كيف يعمل ProjectVIEW AI في الإصدار 12؟

في الإصدار 12، أصبح ProjectVIEW AI مدمجًا في عمليات الإدارة لدى المستخدمين وفي تنفيذها وتحسينها. كذلك يعمل على بيانات متجانسة وموحّدة: البيانات التشغيلية المجمّعة من جميع المشاريع، إلى جانب البيانات الداخلية للشركة. وبذلك تستند كل إجابة وكل اقتراح إلى المصدر الموحّد نفسه الذي يستخدمه نظام ERP.

ماذا تغطي وحدة الإنتاج الجديدة؟

ثانياً، يضيف ProjectVIEW v12 وحدة إنتاج جديدة تغطي التصنيع القائم على المشاريع من البداية إلى النهاية. نتيجة لذلك، أصبح بإمكان المصنّعين الذين ينتجون حسب المشروع أو الطلب أو العقد إدارة الإنتاج في النظام نفسه الذي يستخدمونه للتقدير والموازنة والمشتريات وضبط التكاليف. اطّلع على المزيد حول إدارة المواد والإنتاج في ProjectVIEW ERP.

ماذا يمكن للمستخدمين فعله باستخدام موصل MCP؟

بروتوكول MCP (Model Context Protocol) معيار مفتوح لربط مساعدي الذكاء الاصطناعي بأنظمة الأعمال. لذلك، وباستخدام موصل ProjectVIEW MCP الجديد، يمكن للمستخدمين ربط Claude أو ChatGPT بـ ProjectVIEW من أجل:

1. تنفيذ العمليات بدون واجهة (Headless) دون فتح شاشات نظام ERP؛
2. طرح الأسئلة على بياناتهم بلغة طبيعية؛
3. إنشاء لوحات المعلومات ومؤشرات الأداء التي يحتاجونها؛
4. وأخيراً، بناء وكلاء ومساعدين ذكيين خاصّين بهم لمزيد من الأتمتة.

موقع إلكتروني جديد احتفالًا بالإصدار 12

في الوقت نفسه، واحتفالًا بإطلاق ProjectVIEW v12، يظهر موقع danaos-projects.com بحلّة جديدة. فهو يضم صفحة رئيسية جديدة، وقوائم أعدنا تصميمها، ومحدِّد لغة أبسط، بالإنجليزية والإسبانية واليابانية والإندونيسية والعربية.

الأسئلة الشائعة

من يمكنه استخدام ProjectVIEW v12؟

باختصار، ProjectVIEW v12 متاح الآن لجميع عملاء ProjectVIEW ERP.

ما مساعدو الذكاء الاصطناعي الذين يعملون مع موصل ProjectVIEW MCP؟

الموصل متاح لـ Claude وChatGPT.

ما الجديد للمصنّعين في الإصدار 12؟

وحدة إنتاج جديدة تغطي التصنيع القائم على المشاريع من البداية إلى النهاية.

كيف يمكنني مشاهدة ProjectVIEW v12؟

احجز عرضًا توضيحيًا مع فريقنا وسنعرض لك الإصدار 12 على حالة الاستخدام الخاصة بك.

احجز عرضًا توضيحيًا

Read more: إصدار ProjectVIEW ERP v12 متاح الآن لجميع العملاء

من المحادثات الميدانية المتفرقة إلى ذكاء مؤسسي منظّم: لماذا يمكن للذكاء الاصطناعي المعتمد على الصوت أن يُحدث تحولًا جذريًا في تسجيل الواقع التشغيلي والتحكم فيه بمواقع الإنشاءات وأحواض بناء السفن والمناجم والعمليات البحرية

مستقبل أنظمة تخطيط موارد المؤسسات (ERP) ليس شاشة أخرى، بل نظام تشغيل يستمع

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

على سبيل المثال: التنقل بين القوائم. واستكمال النماذج. واختيار الأكواد. وإدخال الكميات. وإرسال المعاملات. وتحديث التقارير.

لكن مواقع الإنشاءات وأحواض بناء السفن والمناجم والمنصات البحرية لا تعمل بالطريقة نفسها التي تعمل بها المكاتب الإدارية.

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

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

لهذا السبب، يقدم الذكاء الاصطناعي المعتمد على الصوت ونهج التشغيل دون واجهة مستخدم تقليدية (Headless ERP) أسلوبًا مختلفًا للتعامل مع هذه المشكلة.

من خلال DANAOS ProjectVIEW AI، يمكن للعاملين في المواقع استخدام اللغة الطبيعية لتوثيق الأنشطة والأحداث التشغيلية عبر تسجيلات صوتية قصيرة. وبالتالي لا يحتاجون إلى مقاطعة سير عملهم المعتاد للتنقل بين واجهات ERP المعقدة.

بعد ذلك، يحوّل الذكاء الاصطناعي هذه الملاحظات المتفرقة إلى معلومات منظّمة ويحدد سياقها التشغيلي. ثم يوجّه البيانات ذات الصلة إلى الحقول ومسارات العمل المناسبة داخل ProjectVIEW ERP.

بعبارة أخرى، الهدف ليس مجرد تحويل الكلام إلى نص، بل تحويل الملاحظات المنطوقة إلى بيانات مؤسسية موثّقة وقابلة للتنفيذ.

1. ما المقصود بنظام ERP دون واجهة مستخدم تقليدية، ولماذا يغيّر الصوت المعادلة بالكامل؟

باختصار، يفصل نهج التشغيل دون واجهة مستخدم تقليدية (Headless Operating Approach) منطق الأعمال ومعالجة البيانات داخل المؤسسة عن واجهة المستخدم التي يتفاعل الأشخاص من خلالها مع النظام.

في أنظمة ERP التقليدية، يتعين على المستخدمين التنقل بين الشاشات والنماذج لإنشاء المعاملات وتسجيلها.

أما في نموذج التشغيل المعتمد على الصوت، فيستطيع المستخدم بدء هذه التفاعلات باللغة الطبيعية. في الوقت نفسه، يواصل نظام ERP الأساسي تطبيق هياكل البيانات والصلاحيات والحسابات وقواعد العمل المعتمدة.

والفرق بين النهجين جوهري:

• نظام ERP التقليدي: يحوّل الأشخاص الواقع التشغيلي إلى حقول داخل البرنامج.
• نظام ERP المعتمد على الصوت: يصف الأشخاص الواقع كما يحدث. ثم يحوّل الذكاء الاصطناعي ملاحظاتهم إلى معلومات جاهزة للمعالجة داخل النظام.

كيف يدعم ProjectVIEW ERP هذا النهج؟

يوفّر ProjectVIEW ERP بالفعل البنية التشغيلية اللازمة لهذا النهج. ويشمل ذلك بيئة متكاملة لبيانات المشروعات، ومسارات عمل قائمة على الأدوار والصلاحيات، وإطارًا لواجهات برمجة التطبيقات قائمًا على المعايير (Standards-Based API Framework).

بالإضافة إلى ذلك، يضيف ProjectVIEW AI طبقة الذكاء التي تفسّر اللغة الطبيعية وتربط الملاحظات البشرية ببيئة البيانات المنظّمة.

ومع ذلك، لا يعني ذلك إلغاء واجهة نظام ERP، بل جعل استخدامها اختياريًا في العديد من مهام إعداد التقارير الروتينية. كما تحتفظ المؤسسة بالواجهات التقليدية لأغراض الإشراف والتحقق ومعالجة الاستثناءات والاعتمادات.

التشغيل دون واجهة تقليدية لا يعني غياب الرقابة، بل إزالة التعقيدات غير الضرورية في التفاعل مع النظام.

2. من التسجيلات الصوتية المتفرقة إلى سجل تشغيلي يومي موحّد

لنتأمل حالة مهندس موقع يشرف على عدة أنشطة ضمن مشروع بنية تحتية ضخم.

ثم، على مدار يوم العمل، يستخدم المهندس ProjectVIEW AI لتسجيل ملاحظات موجزة كلما وقع حدث تشغيلي.

08:10 — توزيع العمالة

«بدأ 12 نجارًا و6 حدادين العمل في هياكل الأساسات بالمنطقة B».

10:45 — توقف المعدات

«توقفت الحفارة EX-204 بسبب مشكلة هيدروليكية، وتم إخطار فريق الصيانة».

13:20 — المواد ونسب الإنجاز

«تم صب 35 مترًا مكعبًا من الخرسانة في قطاع الأساسات F3، بينما كانت الكمية المخططة لليوم 50 مترًا مكعبًا».

15:40 — المعوقات التشغيلية

«لم يتمكن مقاول الباطن من استكمال أعمال التسليح المتبقية بسبب تأخر توريد المواد».

يمثل كل تسجيل ملاحظة مستقلة.

وقد يسجّله المهندس بعد دقائق أو ساعات من التسجيل السابق، كما قد يتعلق بنشاط أو مورد أو مقاول باطن مختلف.

لذلك لا توجد حاجة إلى إعداد تقرير يومي كامل أثناء الوقوف في موقع العمل.

وبدلًا من ذلك، يجمع ProjectVIEW AI صورة تشغيلية منظّمة من مجموعة من التسجيلات المتفرقة.

كيف يعالج ProjectVIEW AI التسجيلات الصوتية؟

في الممارسة، يتبع سير عمل معالجة الذكاء الاصطناعي ست مراحل أساسية:

1. التسجيل الصوتي: ينشئ الموظفون المصرّح لهم تسجيلات قصيرة ومؤرخة عبر تطبيق العمل الميداني.
2. تحويل الكلام إلى نص: تحوّل تقنيات التعرف على الكلام التسجيلات إلى نصوص قابلة للبحث، مع الحفاظ على السياق الأصلي والبيانات الوصفية المتاحة.
3. التفسير الدلالي: يحدد الذكاء الاصطناعي الأنشطة والمواقع والكميات والتواريخ وموارد العمالة والمعدات والمواد ونسب الإنجاز والمعوقات المبلّغ عنها.
4. الربط بالسياق التشغيلي: يطابق النظام المعلومات المستخرجة مع المشروع المعني، وجدول الكميات (BoQ)، وهيكل تقسيم العمل (WBS)، وأكواد التكاليف (Cost Codes)، وسجلات الموارد.
5. إدخال البيانات المنظّمة في نظام ERP: يملأ النظام بالبيانات المفسَّرة السجلات وحقول المعاملات المناسبة داخل ProjectVIEW ERP. ويعمل في ذلك وفقًا لمتطلبات التحقق والصلاحيات المعتمدة.
6. المطابقة التشغيلية: أخيراً، يقارن ProjectVIEW التنفيذ الفعلي واستهلاك الموارد بعد التحقق منهما بالميزانية المعتمدة والجدول الزمني وخط الأساس التشغيلي للمشروع.

من الناحية التقنية، تدعم تقنيات تحويل الكلام إلى نص الحديثة المعالجة الدفعية للتسجيلات وتحديد اللغة. كذلك تدعم إضافة الطوابع الزمنية والتمييز بين المتحدثين، كما توضح وثائق Microsoft Azure Speech.

لكن العامل الحاسم لا يتمثل في تقنية تحويل الكلام إلى نص وحدها.

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

3. لماذا يُعد تكامل جدول الكميات (BoQ) وهيكل تقسيم العمل (WBS) وأكواد التكاليف (Cost Codes) في ProjectVIEW عنصرًا حاسمًا؟

صحيح أنه يمكن لتطبيق عام يعتمد على الذكاء الاصطناعي أن يقدم ملخصًا ممتازًا لملاحظات مهندس الإنشاءات.

لكن الملخص لا يمثّل معاملة مضبوطة داخل نظام ERP.

على سبيل المثال، لنفترض أن المهندس قال:

«تم صب 35 مترًا مكعبًا من الخرسانة في الأساس F3».

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

وهنا تبرز أهمية البنية الأساسية لنظام ProjectVIEW ERP:

جدول الكميات (BoQ) هيكل تقسيم العمل (WBS) أكواد التكاليف (Cost Codes)

جدول الكميات (BoQ) — ما الذي يجري تنفيذه؟

يحدد بند الأعمال التعاقدي أو التجاري، ووحدة القياس، والكميات المرتبطة به، والموارد المدرجة في الميزانية.

هيكل تقسيم العمل (WBS) — متى وأين ينفّذ الفريق الأعمال؟

يربط التنفيذ بالأنشطة المخططة، والاعتماديات، والمدد الزمنية، ونسب الإنجاز المجدولة. ويشمل ذلك أيضاً الجداول التي يديرها المقاول باستخدام Oracle Primavera P6.

أكواد التكاليف (Cost Codes) — كيف يراقب المقاول الموارد والمصروفات؟

تربط استهلاك الموارد والمصروفات بهيكل التكاليف الداخلي للمقاول.

بعد ذلك، يربط ProjectVIEW ERP هذه الأبعاد على مستوى المؤسسة.

وعندما يربط الفريق الملاحظات الميدانية بالعناصر الصحيحة ويتحقق منها، يستطيع النظام مطابقة كميات الأعمال المُبلّغ عنها وتوزيع العمالة. كما يطابق استخدام المعدات واستهلاك المواد مع معدلات الإنتاجية المخططة والتكاليف المدرجة في الميزانية.

نتيجة لذلك، يتيح النظام ما هو أكثر قيمة بكثير من إعداد التقارير تلقائيًا:

المقارنة المستمرة بين الخطة، والموارد المستهلكة، والأعمال المنفّذة فعليًا، والأعمال المتبقية.

ويمثل ذلك أساس منهجية ProjectVIEW في مراقبة التكاليف الفعلية مقارنة بالتكاليف المدرجة في الميزانية (Actual vs. Budgeted Cost Control).

باختصار، يجعل الذكاء الاصطناعي تسجيل الملاحظات التشغيلية أسهل، بينما يحوّلها ProjectVIEW إلى معلومات ذات قيمة اقتصادية وتشغيلية.

4. تطبيقات ERP المعتمدة على الصوت في الإنشاءات وأحواض بناء السفن والتعدين والعمليات البحرية

تزداد أهمية التقارير الميدانية المعتمدة على الصوت في البيئات التي تتوزع فيها الأنشطة على مساحات واسعة. كما تزداد أهميتها حيث يصعب على العاملين استخدام لوحات المفاتيح أو استكمال النماذج الرقمية المطوّلة.

الإنشاءات والبنية التحتية

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

وبالتالي تدعم هذه الملاحظات سجلات الأعمال اليومية بالمواقع، وقياس نسب الإنجاز، ومراقبة تكاليف المشروعات.

بناء السفن وإصلاحها

يمكن للمشرفين تسجيل تقدم أعمال التصنيع وأنشطة اللحام وتركيب المعدات. كذلك يسجّلون ملاحظات الإصلاح ونتائج الفحص وتوقفات العمل في مختلف السفن والورش والأحواض الجافة.

نتيجة لذلك، تساعد السجلات المنظّمة على ربط التنفيذ في أحواض بناء السفن بحزم العمل والموارد والميزانيات وأنشطة الصيانة أو الإنتاج.

التعدين والمحاجر

يمكن للمشرفين الميدانيين توثيق أنشطة الحفر والإنتاج، وعمليات النقل، وتوقف المعدات، وأحداث الصيانة، وتوزيع العمالة، والمعوقات التشغيلية.

كما يمكن لهذه الملاحظات أن تكمل بيانات القياس عن بُعد الصادرة عن الآلات وقياسات الإنتاج. وبذلك توفر سياقًا إضافيًا لتحليل استخدام المعدات والتكاليف التشغيلية.

الإنشاءات البحرية والعمليات البحرية خارج الشاطئ

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

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

في المحصلة، يظل المبدأ واحدًا في جميع هذه القطاعات:

كلما اقترب تسجيل المعلومات من لحظة التنفيذ الفعلي، قلّ اعتماد المؤسسة على إعادة بناء صورة ما حدث في الماضي.

5. من تحويل الصوت إلى نص إلى مراقبة التكاليف المدعومة بالذكاء الاصطناعي

تظهر القيمة الحقيقية عندما تصبح السجلات الناتجة عن الصوت جزءًا من بيئة بيانات تشغيلية مترابطة.

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

عندئذٍ، بعد التحقق من هذه الملاحظة وربطها بنشاط المشروع الصحيح، تصبح مدخلًا لتحليل أوسع نطاقًا.

ثم يستطيع نظام ProjectVIEW ERP مقارنة الإنجاز المُبلّغ عنه والمعتمد بمعاملات الموارد ومعدلات الإنتاجية المدرجة في الميزانية. كما يقارنه بمتطلبات الجدول الزمني والتكاليف الفعلية.

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

وبالتالي تدعم هذه المعلومات اكتشاف المخاطر التي قد تؤثر في أداء المشروع في وقت مبكر.

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

لذلك فهذا تمييز مهم.

لا ينبغي للذكاء الاصطناعي أن يستنتج يقينًا تشغيليًا من ملاحظة لم يتحقق منها أحد.

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

بعبارة أخرى، الهدف ليس أتمتة غير مقيّدة.

بل تسريع تسجيل البيانات، وتصنيفها بذكاء، وتنفيذ العمليات ضمن ضوابط واضحة.

ويتوافق هذا النهج مع مبادئ الذكاء الاصطناعي الجدير بالثقة الواردة في إطار إدارة مخاطر الذكاء الاصطناعي الصادر عن NIST.

6. لماذا يمكن لأنظمة ERP المعتمدة على الصوت أن تُحدث تحولًا في إنتاجية المؤسسات؟

في السابق، ركز التحول الرقمي التقليدي بدرجة كبيرة على استبدال المستندات الورقية بالنماذج الإلكترونية.

لكن النماذج الرقمية قد تفرض بدورها أعباء إدارية كبيرة على الأشخاص المسؤولين عن تحقيق النتائج الفعلية على أرض الواقع.

في المقابل، تغيّر التفاعلات المعتمدة على الصوت هذه العلاقة.

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

ولا تقتصر الفوائد المحتملة على سهولة الاستخدام.

فالتقارير الأسرع قد تحسّن اكتمال السجلات اليومية وتسرّع اكتشاف الانحرافات. كما قد ترفع جودة البيانات المستخدمة في التنبؤ بالتكاليف وإدارة أداء المشروعات.

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

عادةً يعرف هذه التفاصيل الأشخاص الأقرب إلى التنفيذ، لكنها لا تتحول إلى جزء من المعرفة المؤسسية المنظّمة.

لهذا السبب، يوفر ProjectVIEW AI مسارًا لتسجيل هذه الملاحظات وربطها بالسجلات التشغيلية ذات الصلة.

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

7. التطور من إدخال البيانات في ERP إلى بيئة تشغيل ذكية

يتجاوز التحول طويل الأجل مجرد التعرف على الصوت.

بعبارة أخرى، الصوت يمثل أحد أشكال التفاعل ضمن بيئة تشغيل أوسع مدعومة بالذكاء الاصطناعي.

على سبيل المثال، يمكن للمؤسسة أن تدمج تدريجيًا بين التسجيلات الصوتية الميدانية والصور ومقاطع الفيديو والمستندات. كما يمكنها دمج بيانات القياس عن بُعد للمعدات، وقراءات المستشعرات، وملاحظات الطائرات المسيّرة، ومعاملات ERP القائمة.

ويسهم كل مصدر في تقديم بُعد مختلف من الأدلة التشغيلية.

ومن خلال منظومة ProjectVIEW، يفسّر النظام هذه المعلومات بالاستناد إلى هياكل المشروعات وقواعد الأعمال نفسها، بدلًا من بقائها معزولة داخل تطبيقات غير مترابطة.

وهذا هو التوجه المعماري الذي يقوم عليه ProjectVIEW OS:

ProjectVIEW ERP — طبقة العمليات والبيانات (The Process and Data Layer)

نظام السجلات المعتمد الذي يدير البيانات المنظّمة والمعاملات والموارد والميزانيات والصلاحيات والاعتمادات.

ProjectVIEW AI — طبقة الذكاء والأتمتة (The Intelligence and Automation Layer)

بيئة الذكاء الاصطناعي التي تفسّر المعلومات غير المنظّمة، وتوفر الاستدلال المرتبط بالسياق، وتدعم الأتمتة المصممة لأغراض محددة.

ويؤسس النظامان معًا لبيئة تشغيل أكثر ذكاءً تتمحور حول المشروعات.

اقرأ المزيد: ProjectVIEW OS — نظام التشغيل لعالم الإنشاءات والتشييد.

8. السؤال الأهم: هل يستطيع نظام ERP لديك فهم الواقع أثناء حدوثه؟

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

لا ينبغي لبرمجيات المؤسسات أن تجبر الموظفين على مقاطعة الأعمال الإنتاجية لمجرد تسجيل ما يحدث.

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

هذه هي الفرصة التي يقدمها التشغيل المعتمد على الصوت ونهج ERP دون واجهة مستخدم تقليدية.

يتحدث الأشخاص. يفسّر الذكاء الاصطناعي. ويعمل ProjectVIEW ERP على تنظيم البيانات والتحقق منها وضبطها.

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

تسجيل الواقع التشغيلي بينما لا يزال هناك وقت لاتخاذ إجراء بناءً عليه.

أخيراً، لن يتحدد مستقبل أنظمة ERP للإنشاءات بعدد الشاشات التي يستطيع المستخدمون الوصول إليها.

بل بمدى قدرة نظام التشغيل على فهم الأعمال الجاري تنفيذها، ومدى موثوقية ربط هذا الواقع بقرارات الأعمال.

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

Read more: قوة الصوت: كيف يُحدث الذكاء الاصطناعي في ProjectVIEW تحولاً في أنظمة تخطيط موارد المؤسسات (ERP) الخاصة بالبناء من خلال العمليات اللامركزية

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

تستثمر شركات الإنشاءات، ومشغلو المناجم، وأحواض بناء السفن في الذكاء الاصطناعي (AI)، وإنترنت الأشياء الصناعي (IIoT)، والتوائم الرقمية، والتحليلات التنبؤية، ووكلاء الذكاء الاصطناعي المستقلين.

ومع ذلك، لا يزال هناك سؤال جوهري لم تتم الإجابة عنه بالقدر الكافي:

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

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

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

ولا يكمن الحل في مجرد إضافة المزيد من الذكاء الاصطناعي.

بل في إنشاء منظومة تشغيل مؤسسية متخصصة حسب القطاع، ومتكاملة على مستوى المؤسسة، تربط الواقع التشغيلي بالهندسة والوقت والتكلفة والموارد والعقود والأداء المالي.

وهذا هو المبدأ المعماري الذي تقوم عليه حلول DANAOS ProjectVIEW ERP، والتطور نحو ProjectVIEW AI.

1. ثلاثة قطاعات، وثلاثة أنماط تشغيلية مختلفة، وتحدٍ جوهري واحد

تشترك إدارة الإنشاءات وإدارة التعدين وإدارة أحواض بناء السفن في مجموعة من الخصائص المهمة.

تتطلب القطاعات الثلاثة استثمارات رأسمالية كبيرة، وتنسيقًا معقدًا للموارد، وخبرات هندسية، وإدارة لاستخدام المعدات، ومشتريات، وإدارة للقوى العاملة، ومراقبة للتكاليف، والالتزام بالمتطلبات التنظيمية.

لكن بيئات التشغيل الخاصة بها تختلف اختلافًا جوهريًا.

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

الإنشاءات: إدارة التقدم والإنتاجية والمخاطر التعاقدية

يعمل قطاع الإنشاءات في الغالب من خلال مشروعات ذات نطاقات محددة، ومراحل تعاقدية، وميزانيات، وتواريخ إنجاز واضحة.

وسواء كان المشروع يتضمن تنفيذ مبنى مرتفع، أو بنية تحتية للنقل، أو منشأة صناعية، أو منشأة بحرية، يتعين على المقاولين تنسيق ما يلي:

• التصميمات الهندسية والرسومات ونماذج BIM وإصداراتها وتعديلاتها.
• جداول الكميات (BoQ)، وتقديرات التكلفة، وميزانيات المشروعات.
• هياكل تقسيم العمل (WBS) والجداول الزمنية للإنشاءات.
• مشتريات المواد والخدمات اللوجستية والمخزون.
• إنتاجية العمالة، واستخدام المعدات، وأداء المقاولين من الباطن.
• قياس التقدم، والتغييرات، والمطالبات، والمستخلصات والاعتمادات.
• التدفقات النقدية، والقيمة المكتسبة، وربحية المشروع.

ولا يتمثل التحدي الإداري الأساسي في معرفة حجم الأموال التي تم إنفاقها فحسب.

بل يتمثل في فهم حجم الأعمال المادية التي تم تنفيذها فعليًا، والموارد التي استُهلكت، وما إذا كانت الإنتاجية المحققة تبرر الإنفاق، وكيف تؤثر الانحرافات في الميزانية والجدول الزمني للأعمال المتبقية.

ولا يستطيع نظام ذكاء اصطناعي يقرأ المعاملات المالية وحدها الإجابة عن هذه الأسئلة بصورة موثوقة.

إذ يحتاج إلى وجود روابط بين الكميات الهندسية والأنشطة المخططة والموارد والتنفيذ الفعلي في الموقع.

التعدين: إدارة الإنتاج المستمر وتوافر المعدات واقتصاديات الموارد

يختلف قطاع التعدين اختلافًا كبيرًا عن الإنشاءات التقليدية.

فعلى الرغم من أن تطوير المناجم وتوسعتها يُعدان من المشروعات الرأسمالية، فإن عمليات التعدين النشطة تعتمد عمومًا على إنتاج مستمر وكثيف الاستخدام للأصول والمعدات.

وتعتمد إدارة التعدين على التنسيق بين:

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

يرتبط الأداء الاقتصادي للمنجم ارتباطًا وثيقًا بإنتاجية معداته، وخصائص المواد المستخرجة، وكفاءة سلسلة الإنتاج بأكملها.

ولذلك، يجب أن يفهم وكيل الذكاء الاصطناعي في التعدين أكثر بكثير من أوامر الشراء والسجلات المحاسبية.

فعلى سبيل المثال، قد تنتج زيادة تكلفة الطن عن تراجع توافر المعدات، أو زيادة مسافات النقل، أو ارتفاع استهلاك الوقود، أو انخفاض درجات الخام، أو تراجع كفاءة المعالجة.

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

أحواض بناء السفن: إدارة التعقيد الهندسي والطاقة الإنتاجية ومدة بقاء السفن

يقدم قطاع بناء السفن وإصلاحها نموذجًا تشغيليًا مختلفًا آخر.

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

وقد يدير حوض بناء السفن في الوقت نفسه سفنًا جديدة قيد الإنشاء، وسفنًا قيد الإصلاح، وعمليات صيانة في الأحواض الجافة، ومنشآت بحرية، ومشروعات لتصنيع المنشآت المعدنية.

وتشمل متطلبات الإدارة ما يلي:

• مواصفات السفن والحزم الهندسية ورسومات الإنتاج.
• حزم العمل ومراحل الإنتاج وتسلسل التصنيع.
• تقطيع الفولاذ واللحام والتجميع والتجهيز والتشغيل.
• إشغال الأحواض الجافة وتوافر الأرصفة واستخدام الرافعات.
• تتبع المواد وإدارة المستودعات.
• توزيع العمالة المتخصصة والتنسيق مع المقاولين من الباطن.
• متطلبات هيئات التصنيف والفحوصات وسجلات الجودة.
• أوامر التغيير والأعمال الإضافية واعتمادات العملاء.
• مراحل تسليم السفن ومدة دورة الإصلاح وربحية المشروع.

وعلى خلاف موقع الإنشاءات التقليدي، غالبًا ما يدير حوض بناء السفن عدة مشروعات تتنافس على مرافق الإنتاج نفسها، والعمالة الماهرة، والأحواض، والمعدات الثقيلة.

وفي إصلاح السفن، قد تؤدي الظروف غير المتوقعة التي يتم اكتشافها بعد الفحص إلى تغيير نطاق الأعمال الأصلي بصورة كبيرة.

ولذلك، يجب أن تربط منظومة التشغيل الذكية لحوض بناء السفن بين الحالة الفنية للسفينة، ونطاق الأعمال المعتمد، والطاقة الإنتاجية، وتوافر المواد، والجدول الزمني، والآثار التجارية.

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

2. لماذا لا تستطيع نماذج الذكاء الاصطناعي العامة فهم العمليات الهندسية بمفردها؟

تتمتع نماذج اللغة الكبيرة (LLMs) بقدرات استثنائية على تفسير اللغة، وتلخيص المستندات، واسترجاع المعلومات، ودعم مسارات العمل التحليلية.

لكن الذكاء اللغوي لا يعادل الذكاء الهندسي أو التشغيلي.

تأمل الأسئلة الثلاثة التالية:

• الإنشاءات: لماذا تجاوزت حزمة أعمال الخرسانة المسلحة ميزانيتها رغم الإبلاغ عن اكتمالها بنسبة 80%؟
• التعدين: لماذا ارتفعت تكلفة الطن رغم الحفاظ على حجم الإنتاج المخطط؟
• أحواض بناء السفن: هل يمكن للسفينة A مغادرة الحوض الجاف قبل موعدها بثلاثة أيام من دون التأثير في المسار الحرج للسفينة B؟

لا يمكن الإجابة عن هذه الأسئلة بصورة موثوقة من خلال البحث في المستندات وحده.

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

قد يقدم نموذج ذكاء اصطناعي عام تفسيرًا يبدو منطقيًا، لكن معقولية التفسير لا تعني أنه مثبت بالأدلة.

وفي العمليات الهندسية المؤسسية، يجب أن يميز الذكاء الاصطناعي بين:

• التقدم المخطط والتقدم الفعلي.
• التكاليف الملتزم بها والتكاليف المتكبدة فعليًا.
• الموارد المتاحة والموارد المخصصة.
• التغييرات الهندسية المعتمدة والتغييرات المقترحة.
• كميات الإنتاج المسجلة والكميات التي تم التحقق منها.
• الاتجاهات التاريخية والظروف التشغيلية الحالية.

كما يجب أن يكون قادرًا على تحديد مصدر المعلومات المستخدمة وتوقيتها وحالة اعتمادها.

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

3. شبكة البيانات (Data Mesh): تحويل المعلومات التشغيلية المنفصلة إلى ذكاء أعمال مترابط

يشير مصطلح Data Mesh إلى نهج معماري يتم فيه تنظيم البيانات وفقًا لمجالات الأعمال، مع تحديد واضح للمسؤولية عن ملكيتها وجودتها، ووضع منتجات بيانات قابلة للتشغيل البيني.

وبالنسبة إلى المؤسسات كثيفة الاعتماد على الهندسة، يتمثل الهدف العملي في إنشاء نسيج بيانات موثوق ومترابط يمتد عبر المؤسسة بأكملها.

وهنا يظهر الفرق المهم.

فقد تستوعب بحيرة البيانات كميات هائلة من المعلومات من دون أن توضح بالضرورة العلاقات بينها.

وقد يجمع مستودع البيانات المعلومات التاريخية، لكنه لا يوفر دائمًا السياق التشغيلي المطلوب لتنفيذ قرارات الأعمال.

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

ومع ذلك، فإن إنشاء شبكة بيانات لا يضمن تلقائيًا وجود حقيقة تشغيلية موحدة.

ولتحقيق ذلك، تحتاج المؤسسة إلى نموذج أعمال متسق يربط مجالات البيانات المختلفة ببعضها.

مجالات البيانات التشغيلية الأساسية

يجب على المؤسسة الهندسية كثيفة رأس المال والجاهزة لاستخدام الذكاء الاصطناعي ربط المعلومات الواردة من المجالات التالية:

1. الهندسة والتخطيط: جداول الكميات (BoQ)، وهياكل تقسيم العمل (WBS)، ونماذج BIM، وتصميمات CAD، والنماذج الجيولوجية، وخطط الإنتاج، ومراجعات التصميم والمواصفات الفنية.
2. التنفيذ والإنتاج: تقارير التقدم اليومية، والكميات المركبة، والمكونات المصنعة، والكميات المستخرجة، والفحوصات، وسجلات الإنتاج، وسجلات الإنجاز.
3. الموارد والأصول: العمالة، والمعدات، والسفن، والأصول، والوقود، والصيانة، والتوافر، ومعدلات الاستخدام.
4. العمليات التجارية: التقدير، والمناقصات، والمشتريات، والتعاقد من الباطن، والعقود، والتغييرات، والمستخلصات، والمطالبات.
5. الإدارة المالية: الميزانيات، ورموز التكلفة، والالتزامات، والتكاليف الفعلية، والمحاسبة، والتدفقات النقدية، والربحية.
6. الذكاء التشغيلي الخارجي: أنظمة تتبع المعدات، ومستشعرات إنترنت الأشياء، والطائرات المسيّرة، ونظم المعلومات الجغرافية (GIS)، والمراقبة البيئية، وتطبيقات الجهات الخارجية، وبيانات السوق ذات الصلة.

ويجب ألا تظل هذه المجالات معزولة عن بعضها.

إذ تظهر القيمة الحقيقية عندما يمكن تفسير حدث إنتاج مسجل في أحد المجالات ضمن سياق جميع المجالات الأخرى.

على سبيل المثال، يجب ألا يقتصر تسجيل تعطل إحدى المعدات على تذكرة صيانة فقط.

بل يجب أن يكون من الممكن أيضًا تحديد الأنشطة المتأثرة، والطاقة الإنتاجية المفقودة، ومدى توافر معدات بديلة، والآثار المالية، والإجراءات التصحيحية التي تحتاج إلى اعتماد.

وهذا هو الفرق بين جمع البيانات وتحويلها إلى قيمة تشغيلية.

4. ProjectVIEW ERP: منطق الأعمال الذي يربط الوقت والتكلفة والواقع التشغيلي

تم تصميم DANAOS ProjectVIEW ERP خصيصًا للمؤسسات الهندسية التي تتمحور أعمالها حول المشروعات والاستثمارات كثيفة رأس المال.

ولا تتمثل ميزته الأساسية في مجرد تكامل وحدات ERP، بل في منطق الأعمال الذي يربط نطاق الأعمال الهندسي بالجداول الزمنية للتنفيذ وهياكل التكاليف المؤسسية والاستهلاك الفعلي للموارد.

وتتمثل العلاقة الأساسية في:

BoQ WBS Company Cost Control Accounts

يجيب كل بُعد من هذه الأبعاد عن سؤال مختلف في إدارة الأعمال.

BoQ — ما المطلوب تنفيذه أو تسليمه، وما التكلفة التقديرية له؟

يوفر جدول الكميات نطاق الأعمال التعاقدي أو الإنتاجي، والكميات القابلة للقياس، ومتطلبات الموارد، وخط الأساس الخاص بتقدير التكلفة.

WBS — متى يجب تنفيذ الأعمال، وبأي تسلسل؟

يربط هيكل تقسيم العمل نطاق المشروع بالأنشطة المجدولة، والمراحل الرئيسية، والاعتماديات، والتقدم المخطط.

حسابات مراقبة التكاليف المؤسسية — أين يتم تخصيص الموارد والتكاليف ومراقبتها وتجميعها؟

يوفر هيكل التكاليف المؤسسي تصنيفات مالية وتشغيلية متسقة عبر المشروعات والإدارات والشركات التابعة ووحدات الأعمال.

ومن خلال الربط بين هذه الأبعاد، ينشئ ProjectVIEW ERP نموذجًا تشغيليًا سياقيًا بدلًا من الاكتفاء بمجموعة من السجلات المالية المنفصلة.

لماذا يُعد ذلك مهمًا للذكاء الاصطناعي؟

لنفترض وجود نشاط إنشائي يتطلب 1,000 متر مكعب من الخرسانة.

• يحدد BoQ الكمية المخططة والموارد المرتبطة بها.
• يحدد WBS فترة التنفيذ والاعتماديات.
• تحدد حسابات مراقبة التكاليف كيفية تصنيف النفقات ومراقبتها.

وتسجل المعاملات اليومية في الموقع الكميات المركبة فعليًا، وساعات العمالة، واستخدام المعدات، والمواد المستهلكة، ومساهمات المقاولين من الباطن.

يستطيع ProjectVIEW ربط هذه السجلات لحساب الانحرافات بين الأداء المخطط والأداء الفعلي وتحليلها.

ويمكن بعد ذلك تصميم وكيل ذكاء اصطناعي مصرح له بالوصول إلى هذه المعلومات المترابطة، ليطرح أسئلة مثل:

• هل الإنتاجية أقل من المستوى المرجعي المدرج في الميزانية؟
• هل يتناسب استهلاك المواد مع الكميات المنفذة؟
• هل ترتفع تكلفة العمالة بسبب العمل الإضافي أو انخفاض الإنتاج؟
• هل سيؤثر الأداء الحالي في التكلفة المتوقعة عند اكتمال المشروع؟
• ما الإجراءات التصحيحية المعتمدة والمتاحة؟

والفرق هنا جوهري.

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

وهذا هو الأساس لإجراء توقعات أكثر موثوقية للتكاليف، واكتشاف الحالات غير الطبيعية، ودعم القرارات التشغيلية.

5. من مواقع الإنشاءات والمناجم وأحواض بناء السفن إلى نسيج بيانات مؤسسي مترابط

يمكن أن يعمل ProjectVIEW ERP بوصفه طبقة مركزية للتنسيق التشغيلي، مع استمرار التطبيقات المتخصصة في أداء الوظائف التي صُممت من أجلها.

فالهدف ليس استبدال كل تطبيق هندسي أو صناعي، بل ربط مخرجاته ذات الصلة بنموذج أعمال مؤسسي متسق.

التكامل الهندسي وتكامل الجدولة

يوفر ProjectVIEW ERP تكاملًا أصليًا مع Oracle Primavera P6، بما يدعم الربط بين الجداول الزمنية للمشروعات ومراقبة التكاليف التشغيلية.

كما يتيح دعمه لمعيار Industry Foundation Classes (IFC) دمج المعلومات الواردة من تطبيقات BIM المتوافقة.

وتساعد هذه التكاملات على ربط المعلومات الهندسية والتخطيطية بالسجلات التشغيلية والتجارية.

تسجيل البيانات في الموقع وساحات التصنيع

توفر المعاملات اليومية الأدلة التشغيلية اللازمة لمقارنة الأنشطة المخططة بالتنفيذ الفعلي.

ويشمل ذلك تقدم الأعمال، واستخدام القوى العاملة، ومعاملات المعدات، وحركة المواد، وأداء المقاولين من الباطن.

وكلما اقترب تسجيل البيانات من موقع التنفيذ الفعلي، زادت فائدتها في اتخاذ القرارات التشغيلية.

تكامل المشتريات والمخزون والأنظمة المالية

يدمج ProjectVIEW عمليات المشتريات، وإدارة المستودعات، والتعاقد من الباطن، وإعداد الميزانيات، ومراقبة التكاليف.

كما تدعم إمكانات واجهات برمجة التطبيقات (API) تكامله مع أنظمة مؤسسية خارجية، بما في ذلك SAP وOracle، وفقًا لنطاق التنفيذ.

ويتيح ذلك للمؤسسات الحفاظ على استثماراتها الحالية في الأنظمة، مع إنشاء مستوى أقوى من الرقابة التشغيلية الخاصة بالمشروعات.

المعدات والسفن والبيانات الصناعية

يمكن لأنظمة تتبع المعدات وإنترنت الأشياء وإدارة الأساطيل والمراقبة الصناعية توفير معلومات تشغيلية قيّمة.

وفي البيئات البحرية والبحرية الخارجية، يمكن للتكامل مع التطبيقات البحرية المتخصصة توسيع منظومة البيانات لتشمل عمليات السفن والإدارة الفنية وأداء الأساطيل.

ومن خلال المنظومة التقنية الأوسع لـDANAOS، يمكن تقديم ProjectVIEW إلى جانب الخبرات المتخصصة في البرمجيات البحرية من DANAOS Management Consultants.

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

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

6. ProjectVIEW AI: من ذكاء الأعمال إلى التنسيق الذكي للأعمال

توضح أدوات ذكاء الأعمال التقليدية ما حدث، بينما تقدر التحليلات التنبؤية ما قد يحدث.

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

هذا هو الاتجاه الذي يتبناه ProjectVIEW AI.

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

ويمكن لهؤلاء الوكلاء العمل عبر عدة مستويات من الذكاء.

الذكاء الوصفي: ما الذي يحدث؟

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

الذكاء التشخيصي: لماذا يحدث ذلك؟

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

الذكاء التنبؤي: ما الذي يُرجح حدوثه؟

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

الذكاء التوجيهي: ما الذي ينبغي علينا فعله؟

يمكن للوكلاء تقييم البدائل، وقياس آثارها المحتملة، والتوصية بإجراءات تصحيحية.

التنفيذ الوكيلي الخاضع للضوابط: هل يمكن للنظام بدء الإجراء؟

مع توافر الصلاحيات المناسبة وآليات التحقق والموافقة، يمكن لوكلاء الذكاء الاصطناعي إعداد طلبات الشراء، وتصعيد الاستثناءات، والتوصية بإعادة توزيع الموارد، أو بدء مسارات عمل مؤسسية محددة.

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

لا يتعلق الأمر باستقلالية غير مقيدة، بل بتنسيق تشغيلي خاضع للحوكمة.

7. ثلاثة سيناريوهات لوكلاء ذكاء اصطناعي متخصصين حسب القطاع

السيناريو الأول: وكيل مراقبة تكاليف الإنشاءات

ينفذ أحد مقاولي الإنشاءات عدة مشروعات للبنية التحتية.

وتشير السجلات اليومية إلى انخفاض إنتاجية أعمال الحفر عن المستوى المرجعي المحدد في الميزانية.

يمكن إعداد وكيل لمراقبة التكاليف بحيث يتحقق من:

• كميات الحفر المنفذة.
• ساعات العمالة المخططة والفعلية.
• معدلات استخدام الحفارات والشاحنات.
• استهلاك الوقود.
• مسافات النقل ومدى توافر المعدات.
• تقدم WBS والكميات المتبقية.
• الالتزامات الحالية المتعلقة بالتكاليف وتوقعات الميزانية.

يحدد الوكيل علاقة محتملة بين تراجع الإنتاجية وتوقف المعدات وزيادة متطلبات النقل.

ثم يُعد تقريرًا بالاستثناءات مدعومًا بالأدلة، ويقدر الأثر المحتمل في التكلفة عند اكتمال المشروع، ويوصي بإجراءات تصحيحية لاعتمادها من مدير المشروع.

النتيجة التجارية: اكتشاف الانحرافات مبكرًا، وتحسين توزيع الموارد، وتعزيز حماية هوامش ربح المشروعات.

السيناريو الثاني: وكيل ذكاء الإنتاج وأسطول المعدات في التعدين

يسجل أحد مواقع التعدين استقرارًا في الإنتاج اليومي، بالتزامن مع ارتفاع تكاليف الإنتاج.

يمكن لوكيل ذكاء اصطناعي متصل ببيانات الإنتاج المعتمدة، والأسطول، والصيانة، والتكاليف أن يتحقق مما إذا كانت الزيادة مرتبطة بأحد العوامل التالية:

• انخفاض توافر الشاحنات.
• ارتفاع استهلاك الوقود لكل طن.
• زيادة مسافات النقل.
• تغير خصائص المواد.
• خسائر الإنتاج المرتبطة بالصيانة.
• عدم كفاءة توزيع المعدات.

وبدلًا من الإبلاغ عن ارتفاع التكلفة فقط، يستطيع الوكيل التحقيق في العوامل التشغيلية التي أدت إليه.

ويمكنه بعد ذلك التوصية ببدائل لتوزيع أسطول المعدات أو تحديد فترات الصيانة، تمهيدًا لمراجعتها هندسيًا.

النتيجة التجارية: فهم أفضل لتكلفة الطن، وتحسين استخدام المعدات، ودعم تخطيط الإنتاج بقرارات أكثر دقة.

السيناريو الثالث: وكيل تحسين الإنتاج والأحواض الجافة في بناء السفن

يدير أحد أحواض بناء السفن عدة سفن تخضع لأعمال الصيانة والإصلاح المجدولة.

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

يمكن تصميم وكيل للذكاء الاصطناعي في حوض بناء السفن لربط المعلومات التالية:

• نطاق الإصلاح المعتمد والنطاق المعدل.
• المواد المطلوبة ومدى توافرها.
• الطاقة الاستيعابية للحام والتصنيع.
• توافر العمالة والمقاولين من الباطن.
• إشغال الأحواض والجداول الزمنية للإنتاج.
• متطلبات الفحص والاعتماد.
• إجراءات التغييرات التعاقدية.
• الأثر المحتمل في السفن الأخرى.

ويمكن للوكيل تحديد تعارضات الجدولة، وتقدير احتياجات الموارد الإضافية، وإعداد خطة مقترحة لاستعادة المسار الزمني.

ومع ذلك، تظل التغييرات التجارية بحاجة إلى الاعتمادات اللازمة.

النتيجة التجارية: تحسين استخدام الأحواض، وتسريع تقييم الأعمال المستجدة، وتعزيز الرقابة التجارية، وتقليل مخاطر تأخر تسليم السفن.

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

8. البيانات الموثوقة أهم من زيادة حجم البيانات

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

• قد يتعطل أحد المستشعرات.
• قد يكون تقرير التقدم اليومي غير مكتمل.
• قد يبلغ المقاول من الباطن عن كميات لم يتم اعتمادها.
• قد تمثل معاملة المشتريات التزامًا ماليًا، وليس تكلفة متكبدة فعليًا.
• قد يكون الرسم الهندسي قد استُبدل بإصدار أحدث.
• قد يكون السجل المالي صحيحًا من الناحية المحاسبية، لكنه غير كافٍ لتفسير الإنتاجية المادية.

ولكي يصبح الذكاء الاصطناعي جديرًا بالثقة، يجب أن تتوافر في المعلومات مجموعة من الخصائص الأساسية:

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

وتكتسب هذه المتطلبات أهمية خاصة في الإنشاءات والتعدين وأحواض بناء السفن، لأن القرارات قد تترتب عليها آثار مالية وتعاقدية وبيئية وآثار متعلقة بالسلامة.

والمبدأ الأساسي واضح:

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

9. نظام ERP هو الأساس التشغيلي، وليس منظومة الذكاء الاصطناعي بأكملها

سيكون من المضلل القول إن نظام ERP وحده يستطيع استبدال النماذج الجيولوجية، أو أنظمة التحكم الصناعي، أو أدوات إنشاء نماذج BIM، أو محركات الجدولة، أو التطبيقات البحرية المتخصصة.

• يفهم تطبيق تخطيط المناجم القيود الجيولوجية وقيود الاستخراج.
• يمثل تطبيق BIM الهندسة والمعلومات المتعلقة بالأصول.
• يدير Primavera P6 الجدولة التفصيلية للمشروعات.
• يحتفظ نظام إدارة السفن بالسجلات التشغيلية البحرية المتخصصة.
• تقيس أنظمة القياس الصناعي سلوك المعدات الفعلي.

أما دور نظام ERP المتخصص حسب القطاع فهو مختلف.

إذ يوفر سياق الأعمال المؤسسي الذي يربط هذه الأنظمة المتخصصة بالموارد والعقود والتكاليف ومسارات العمل والنتائج المالية.

وهذا التمييز بالغ الأهمية.

فمن دون الأنظمة المتخصصة، تفقد المؤسسة العمق الفني اللازم.

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

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

لذلك، تحتاج المؤسسة الذكية إلى ثلاثة أسس متكاملة:

1. أنظمة تشغيلية متخصصة لالتقاط المعلومات الهندسية والصناعية ومعالجتها.
2. منصة تشغيل مؤسسية متكاملة تربط العمليات والموارد والوقت والتكلفة والمسؤولية التجارية.
3. منظومة ذكاء اصطناعي خاضعة للحوكمة تستطيع تحليل هذه المعلومات ودعم القرارات أو تنفيذ إجراءات محددة تحت الرقابة.

يتموضع ProjectVIEW ERP بوصفه الأساس الثاني، وطبقة السياق التشغيلي التي تدعم الأساس الثالث.

10. خارطة الطريق: من الرقمنة المجزأة إلى العمليات المنسقة بالذكاء الاصطناعي

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

المرحلة الأولى — إنشاء بيانات رئيسية مؤسسية موثوقة

توحيد هياكل المشروعات، وحسابات التكاليف، والموارد، وسجلات المعدات، ووحدات القياس، والمسؤوليات التنظيمية.

المرحلة الثانية — تكامل مسارات العمل التشغيلية الأساسية

ربط التقدير والتخطيط والمشتريات والإنتاج والقوى العاملة والمعدات والعقود والرقابة المالية.

المرحلة الثالثة — ربط الأنظمة الهندسية والصناعية المتخصصة

دمج المعلومات ذات الصلة بالجدولة ونماذج BIM وتخطيط المناجم وإدارة السفن ونظم المعلومات الجغرافية وإنترنت الأشياء وأنظمة تتبع المعدات.

المرحلة الرابعة — التحقق من الأداء التشغيلي

إنشاء مطابقة منهجية بين الكميات المخططة والفعلية، والتقدم، والتكاليف، واستخدام الموارد، والتغييرات المعتمدة.

المرحلة الخامسة — تقديم مساعدي ذكاء اصطناعي متخصصين

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

المرحلة السادسة — تطبيق الذكاء التنبؤي والتوجيهي

التوسع إلى التنبؤ، واكتشاف الحالات غير الطبيعية، وتحسين الصيانة، وتحليل الإنتاج، وتقييم السيناريوهات.

المرحلة السابعة — تمكين التنسيق بالذكاء الاصطناعي الخاضع للحوكمة

السماح لوكلاء الذكاء الاصطناعي المصرح لهم ببدء مسارات عمل محددة، بدعم من آليات التحقق والصلاحيات والموافقات وسجلات التدقيق والإشراف البشري.

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

11. الميزة التنافسية ستكون للمؤسسات التي تتحكم في بياناتها

يتسارع تبني الذكاء الاصطناعي في القطاعات كثيفة رأس المال.

ومع ذلك، فإن المؤسسات الأكثر استفادة لن تكون بالضرورة تلك التي تستخدم أكبر عدد من تطبيقات الذكاء الاصطناعي.

بل ستكون المؤسسات القادرة على الإجابة عن أسئلة الأعمال الأساسية بدقة واتساق:

• ما الأعمال التي تم إنجازها فعليًا؟
• ما الموارد التي تم استهلاكها لتحقيقها؟
• كيف يقارن الأداء بخط الأساس المعتمد؟
• ما أسباب الانحراف؟
• ماذا سيحدث إذا استمر الاتجاه الحالي؟
• ما الإجراءات التصحيحية الممكنة فنيًا والمبررة تجاريًا؟
• من يملك صلاحية اعتماد هذه الإجراءات وتنفيذها؟

تتطلب الإجابة عن هذه الأسئلة أكثر من لوحات المعلومات أو مستودعات البيانات المنفصلة أو واجهات المحادثة المدعومة بالذكاء الاصطناعي.

إنها تتطلب نموذجًا تشغيليًا متكاملًا للمؤسسة.

وهنا يتضح الفرق بين الرقمنة العامة والتحول التشغيلي الحقيقي.

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

في DANAOS Projects، تتمثل رؤيتنا في أن يصبح ProjectVIEW ERP مركز القيادة التشغيلي لقطاعات الإنشاءات والتعدين والهندسة البحرية والعمليات البحرية الخارجية وبناء السفن وإصلاحها.

منصة مؤسسية متكاملة تربط نسيج البيانات التشغيلية، وتصل الأنظمة الهندسية والصناعية المتخصصة، وتوفر سياق الأعمال الذي يحتاج إليه ProjectVIEW AI وغيره من وكلاء الذكاء الاصطناعي المصرح لهم.

ولا يقتصر هدفنا على مساعدة المؤسسات في تبني الذكاء الاصطناعي.

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

لأن المقياس النهائي للذكاء في المشروعات الهندسية كثيفة رأس المال ليس مقدار البيانات التي يستطيع النظام معالجتها.

بل مدى قدرته على حماية هوامش الربح، وتحسين الإنتاجية، والسيطرة على المخاطر، ودعم التنفيذ المربح للمشروعات.

Read more: الذكاء الاصطناعي في قطاعات البناء والتعدين وأحواض بناء السفن: لماذا يُعد نظام تخطيط موارد المؤسسات (ERP) المخصص للقطاع حجر الأساس للعمليات الذكية؟

أصبحت الطائرات المسيّرة في قطاع البناء أدوات قوية لجمع البيانات. لكن بيانات الطائرات المسيّرة وحدها لا تتحكم في المشروع.

تبدأ القيمة الحقيقية عندما يربط فريق المشروع الصور والسحب النقطية والكميات ونتائج الفحص والبيانات الجغرافية المكانية بـجدول الكميات (Bill of Quantities – BoQ) وهيكل تجزئة العمل (Work Breakdown Structure – WBS) والجدول الزمني ورموز التكاليف والموارد والمعدات والسفن والعقود والإنفاق الفعلي للمشروع.

هذا هو الفرق بين رصد الواقع (Reality Capture) والتحكم في المشروع استنادًا إلى الواقع.

على سبيل المثال، يحدد تحليل حديث لسوق الطائرات المسيّرة للبناء في اليابان عدة اتجاهات تسرّع اعتماد هذه الطائرات. ومن هذه الاتجاهات المسح الخرائطي الآلي للمواقع، والمساحة، وفحص البنية التحتية، ومعالجة الصور بالذكاء الاصطناعي، وتتبع التقدم في الوقت الفعلي، والتوافق التشغيلي مع BIM، والصيانة التنبؤية.

تحظى اليابان بأهمية خاصة في هذا السياق. فقد روّج برنامج i-Construction التابع لوزارة الأراضي والبنية التحتية والنقل والسياحة لاستخدام المسح بالطائرات المسيّرة (UAV) والبيانات ثلاثية الأبعاد. ويشمل ذلك جميع مراحل سير عمل المساحة والتشييد والفحص. كما تعترف الإرشادات اليابانية تحديدًا بالمسح التصويري بالطائرات المسيّرة لإجراء مسوحات ثلاثية الأبعاد عالية الكثافة، وباستخدام البيانات ثلاثية الأبعاد لحساب كميات الأعمال ودعم البناء المعتمد على تقنيات المعلومات والاتصالات.

ومع ذلك، فإن الخطوة التالية أكبر:

ربط ما تراه الطائرة المسيّرة بما تعرفه المؤسسة.

ما الحلقة المفقودة بين الطائرات المسيّرة في البناء وأنظمة ERP؟

يمكن للطائرة المسيّرة أن تخبرك بما هو موجود في موقع معيّن وفي لحظة زمنية محددة.

أما نظام ERP فينبغي أن يخبرك بما تعنيه تلك الملاحظة بالنسبة إلى المشروع.

على سبيل المثال، تستطيع سير عمل الطائرات المسيّرة الحديثة توليد صور عالية الدقة وصور جوية مُصحّحة (Orthomosaics) وسحب نقطية. كما تولّد نماذج للتضاريس، وقياسات حجمية، وصور حرارية، وبصورة متزايدة ملاحظات مصنّفة بالذكاء الاصطناعي.

وقد أثبتت الأبحاث الأكاديمية بالفعل قيمة الجمع بين المسح التصويري بالطائرات المسيّرة وBIM. إذ وجدت مراجعة منهجية لتقنيات الطائرات المسيّرة في البناء أن متابعة التقدم من أبرز التطبيقات. وتعتمد هذه المتابعة عادةً على صور الطائرات المسيّرة لإنشاء نموذج ثلاثي الأبعاد للوضع المنفَّذ فعليًا (As-built) ومقارنته بالنموذج المخطط.

وتذهب الأبحاث الأحدث إلى أبعد من ذلك. فقد جمعت دراسة أجراها باحثون عام 2026 بين المسح التصويري بالطائرات المسيّرة وBIM والمقارنة الآلية للسحب النقطية. ونتيجة لذلك، أظهرت إمكانية التقييم الكمي للأعمال المنجزة والجارية والمعلّقة، مع تحديد الانحرافات عن الجدول الزمني.

لكن يظل هناك سؤال جوهري على مستوى المؤسسة:

التقدم مقارنةً بماذا؟

• يمكن للنموذج ثلاثي الأبعاد أن يحدد أن عنصرًا ما موجود.
• في المقابل، يمكن للجدول الزمني أن يشير إلى أن نشاطًا ما ينبغي أن يكون قد اكتمل.

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

لهذا السبب، يغيّر ProjectVIEW ERP المعادلة.

ينبغي أن تتحول بيانات الطائرات المسيّرة في النهاية إلى معاملة ضمن المشروع

صمّمت DANAOS Projects نظام ProjectVIEW ERP حول العلاقة التالية:

BoQ WBS رموز التكاليف

يمثّل BoQ النطاق التعاقدي القابل للقياس.

ويمثّل WBS الأنشطة وتسلسلها والوقت.

وتمثّل رموز التكاليف الطريقة التي تصنّف بها المؤسسة إنفاقها وتتحكم فيه.

لذلك، لا ينبغي أن يكون الهدف من دمج البيانات المستمدة من الطائرات المسيّرة إنشاء لوحة معلومات أخرى.

بل ينبغي أن يكون تحويل الواقع المرصود إلى أدلة منظَّمة تدعم معاملات نظام ERP.

في الممارسة، يمكن أن تبدو سلسلة البيانات العملية على النحو التالي:

1. رصد الواقع: أولاً، تجمع الطائرات المسيّرة (UAV) والكاميرات الثابتة والأجهزة المحمولة الأدلة الميدانية. كذلك تجمعها أنظمة LiDAR وGNSS والتتبع عن بُعد للمعدات وأجهزة استشعار IoT، وعند الاقتضاء أنظمة ROV/AUV.
2. تفسير الواقع: ثم يحدد المسح التصويري والرؤية الحاسوبية والذكاء الاصطناعي الكميات والأصول والحالات والعناصر والعيوب والتقدم أو الحالات الشاذة.
3. وضع الواقع في سياقه: بعد ذلك، تحدد BIM وGIS وترميز المشروع موقع الملاحظة. ويكون ذلك بالنسبة إلى الأصل أو المنطقة أو بند BoQ أو نشاط WBS ذي الصلة.
4. مطابقة الواقع: يقارن ProjectVIEW ERP التقدم المرصود بالتقدم المجدول والموارد المدرجة في الموازنة. كما يقارنه بالعمالة الفعلية والمعدات والمواد والمقاولين من الباطن والتكلفة.
5. التصرف بناءً على الواقع: أخيراً، تُطلق سير عمل ProjectVIEW عمليات المراجعة أو الفحص أو الاعتماد. وقد تُطلق كذلك الإجراءات التصحيحية أو الصيانة أو الاعتماد المالي للأعمال أو التنبؤ أو تنبيهات الإدارة.

تصبح الطائرة المسيّرة مراقبًا ميدانيًا إضافيًا. ويصبح ProjectVIEW نظام السجل التشغيلي المرجعي. ويصبح الذكاء الاصطناعي طبقة التفسير والاستدلال.

هل يمكن لبيانات الطائرات المسيّرة أن تُكمل السجل اليومي للبناء؟

يمكنها أن تعززه بدرجة كبيرة، لكن ينبغي أن تكون مكمِّلة للتقارير الميدانية المضبوطة، لا بديلًا عنها دون تمحيص.

تقليديًا، يعتمد السجل اليومي للبناء على المعلومات التي يدخلها المشرفون والمهندسون ومسؤولو تسجيل الوقت ومديرو المعدات والمقاولون من الباطن وغيرهم من العاملين في الموقع.

في الوقت الحالي، ينظّم ProjectVIEW معلومات الموقع وحوض بناء السفن حول التقدم وإنتاجية العمالة واستهلاك المواد. كما ينظّمها حول استخدام المعدات وعمليات الفحص وأوامر العمل وغيرها من السجلات التشغيلية. وتصف DANAOS تحديدًا رقمنة السجلات اليومية للمقاولين بوصفها وسيلة لتحسين رؤية المشروع والتنسيق فيه في الوقت الفعلي.

والآن تخيّل استكمال هذا السجل البشري بأدلة تولّدها الآلات.

• يمكن التحقق من قيد تقدم يفيد بأن أعمال الحفر بلغت كمية معينة بمقارنته بنموذج للتضاريس مستمد من الطائرة المسيّرة.
• كذلك يمكن مقارنة كمية مخزون الركام بسجلات المستودع والمواد.
• ويمكن مقارنة تقدم أعمال الخرسانة أو الحديد أو الأنابيب أو الهياكل بالصور وعناصر BIM وبنود BoQ المقابلة.
• بل قد يتضمن طلب الفحص صورًا مرجعية جغرافيًا التقطها الفريق قبل تقديمه بوقت قصير.

بعد ذلك، يستطيع الذكاء الاصطناعي تحديد الاختلافات بين صور الأمس واليوم وإبراز المناطق التي تتطلب تحققًا بشريًا. كما يستطيع إعداد مسودة منظَّمة لتقرير البناء اليومي.

بعبارة أخرى، النتيجة ليست “ذكاءً اصطناعيًا يحل محل مهندس الموقع”.

بل سلسلة أدلة أفضل.

لماذا يُعد استخدام المعدات الثقيلة أمرًا حاسمًا في البناء والتعدين؟

في البناء والتعدين، لا ينفصل الإنتاج عن المعدات.

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

على سبيل المثال، تُظهر الأبحاث الحديثة حول مراقبة أساطيل معدات أعمال الحفر والردم أن GNSS وأنظمة التتبع عن بُعد (Telematics) قادرة على التمييز بين حالتي التشغيل والتوقف. كما أنها قادرة على تحليل دورات عمل المعدات، ودعم تقييم الإنتاجية في الوقت الفعلي.

وبالمثل، تستخدم Caterpillar معلومات التتبع عن بُعد، مثل معدل الاستخدام واستهلاك الوقود ووقت التشغيل مقارنةً بوقت التوقف. ثم تجمعها مع سجلات الفحص والصيانة لفهم أداء المعدات وحالتها.

كذلك يُبرز نظام Smart Construction من Komatsu التوجه العام ذاته. إذ يمكن الجمع بين معلومات التصميم وبيانات الوضع المنفَّذ التي تولّدها الآلات والمسح الجوي بالطائرات المسيّرة لعرض التقدم والكميات بصريًا.

ينقل ProjectVIEW ERP هذه المعلومات التشغيلية إلى بيئة إدارة المشاريع والتحكم في التكاليف. وتشمل قدرات إدارة المعدات فيه تكلفة الساعة في حالتي التشغيل والتوقف، وجدولة المعدات وتخصيصها. كما تشمل الخدمات اللوجستية والتعبئة، والصيانة الوقائية والتصحيحية، والاستخدام اليومي للمعدات المرتبط بهياكل BoQ، وأنظمة التتبع عن بُعد للمعدات.

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

معرفة مكان وجود الحفارة أمر مفيد.

ومع ذلك، فمعرفة ما إذا كانت منتجة أفضل.

أما معرفة الكمية التي أنتجتها، ولأي نشاط، وبأي تكلفة، ومقارنةً بأي موازنة فهي التحكم على مستوى المؤسسة.

من إدارة أسطول المعدات إلى إدارة أسطول السفن

كذلك يمتد المبدأ نفسه إلى العمليات البحرية.

فالبناء البحري وطاقة المناطق البحرية وعمليات أحواض بناء السفن تضيف فئة أخرى من الموارد كثيفة رأس المال: السفن.

إذ تشارك القاطرات البحرية والصنادل وسفن التجريف وسفن الرافعات مشاركةً مباشرة في تنفيذ المشروع. كما تشارك قوارب نقل الطواقم وسفن الإمداد والمنصات ذاتية الرفع (Jack-up) وسفن التركيب وغيرها من الأصول العائمة.

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

لذلك يتناول DANAOS ProjectVIEW ERP العمليات البحرية والبحرية البعيدة عن الشاطئ عبر أحواض بناء السفن والمواقع والسفن. ويشمل ذلك جدولة تعبئة السفن، وإدارة الأسطول والمعدات، وسجلات الصيانة، والتكامل مع الخدمات اللوجستية للمشروع ومراكز التكلفة.

ويكتسب هذا أهمية لأن نشاط الأسطول لا ينبغي أن يكون خارج السجل التشغيلي اليومي للمشروع.

على سبيل المثال، تستهلك السفينة التي تدعم نشاطًا من أنشطة WBS في البحر الوقت والمال. وهي تستهلكهما تمامًا كما تستهلكهما الحفارة التي تدعم نشاطًا من أعمال الحفر والردم على اليابسة.

وينبغي أن يُسهم كلاهما في النهاية في الحقيقة التشغيلية ذاتها.

هل يمكن استخدام الطائرات المسيّرة في الفحص البحري والبحري البعيد عن الشاطئ؟

نعم، ولكن مع تمييز تقني مهم.

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

كما تجمع أبحاث DNV بين الطائرات المسيّرة وLiDAR والذكاء الاصطناعي لفحص هياكل السفن عن بُعد. ويشمل ذلك تحديد التشققات والتآكل المحتملة لإخضاعها لتقييم بشري أدق.

ويمكن أن يقلل ذلك الحاجة إلى السقالات ومنصات العمل والوصول البشري الخطر. كما أثبتت DNV إمكانية الفحص بالطائرات المسيّرة على الأصول البحرية العائمة، بما في ذلك خزان في وحدة FPSO. وقد عالجت خوارزمية متخصصة الفيديو الملتقط لاكتشاف تشققات إنشائية محتملة.

لكن الطائرات المسيّرة الجوية لا تحل محل الفحص تحت سطح البحر.

في المقابل، تحت خط الماء تصبح المركبات المشغَّلة عن بُعد (ROV) والمركبات ذاتية التشغيل تحت الماء (AUV) وأجهزة السونار وأنظمة الفحص تحت الماء جزءًا من البنية الأشمل ذاتها لرصد الواقع. وتعترف Lloyd’s Register صراحةً بالطائرات المسيّرة (UAV) والدرون وROV والأنظمة الروبوتية وغيرها من تقنيات الفحص عن بُعد لتطبيقات المسح المناسبة.

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

لماذا يغيّر ProjectVIEW ERP + الذكاء الاصطناعي قيمة رصد الواقع؟

يصبح الذكاء الاصطناعي ذا قيمة حقيقية عندما يتوفر له السياق.

على سبيل المثال، قد يتعرف نموذج ذكاء اصطناعي يحلل صورة من طائرة مسيّرة على آلة أو عنصر خرساني أو مخزون ركام أو أنبوب أو منطقة تآكل أو هيكل غير مكتمل.

ويوفر ProjectVIEW سياق الأعمال المفقود:

أي مشروع؟ أي BoQ؟ أي نشاط في WBS؟ أي موقع؟ أي مقاول من الباطن؟ أي آلة أو سفينة؟ أي فحص؟ أي موازنة؟ أي حساب تكلفة؟ أي تاريخ إنجاز مخطط؟

يتيح هذا السياق لـProjectVIEW AI تجاوز تصنيف الصور نحو الاستدلال التشغيلي.

تعرّف DANAOS نظام ProjectVIEW OS بأنه ProjectVIEW ERP، أي طبقة العمليات والبيانات، مقترنًا بـProjectVIEW AI، أي طبقة الذكاء والاستقلالية. وفي هذا النظام، يوفر الربط بين BoQ وWBS ورموز التكاليف أساسًا منظَّمًا للمشروع يستند إليه تحليل الذكاء الاصطناعي.

نتيجة لذلك، تتيح هذه البنية اكتشاف الانحرافات بمساعدة الذكاء الاصطناعي وتحديد أولويات الفحص وتحليل الإنتاجية. كما تتيح تنبيهات الصيانة، والتحقق من التقدم، والتنبؤ، وإعداد التقارير آليًا استنادًا إلى واقع المشروع المنظَّم بدلًا من الصور المعزولة أو الأوامر النصية العامة.

المستقبل ليس إدارة الطائرات المسيّرة، بل الإدارة المتكاملة للواقع.

تُراكم تقنيات البناء أجهزة الاستشعار في كل مكان.

• ترى الطائرات المسيّرة المشروع من الأعلى.
• ويُبلغ العاملون في الموقع عمّا حدث على الأرض.
• وتسجل أنظمة التتبع عن بُعد للمعدات كيفية تشغيلها.
• ويصف BIM ما ينبغي أن يكون موجودًا.
• ويحدد Primavera متى ينبغي تنفيذ الأنشطة.
• ويمكن لمركبات ROV وروبوتات الفحص توثيق البيئات الصعبة أو المغمورة بالمياه.
• وتولّد السفن سجلات التشغيل والصيانة والتعبئة.

ومع ذلك، يكمن الخطأ في السماح لكل تقنية بإنشاء صومعة بيانات معزولة أخرى.

يبدأ البناء الرقمي الحقيقي عندما تتلاقى تدفقات البيانات هذه حول هيكل المشروع ذاته.

وبالنسبة إلى DANAOS Projects، فإن هذا الهيكل هو ProjectVIEW ERP.

والهدف على المدى الطويل واضح:

الموقع + حوض بناء السفن + المعدات + السفن + الطائرات المسيّرة + BIM + الجدول الزمني + الذكاء الاصطناعي ← حقيقة تشغيلية واحدة.

باختصار، جمع مزيد من البيانات لا يحقق التحكم تلقائيًا.

بل يتحقق التحكم بربط الواقع بـالنطاق والوقت والموارد والتكلفة.

الأسئلة الشائعة

كيف يمكن دمج بيانات الطائرات المسيّرة في البناء مع نظام ERP؟

أولاً، يمكن معالجة الصور والسحب النقطية والقياسات وبيانات الفحص المستمدة من الطائرات المسيّرة عبر منصات المسح التصويري أو BIM أو GIS أو الذكاء الاصطناعي. ثم يمكن تبادلها مع نظام ERP عبر واجهات API أو ملفات منظَّمة أو خدمات التكامل. وفي ProjectVIEW ERP، يتمثل هدف الأعمال في ربط المعلومات المعتمدة بالمشروع أو BoQ أو WBS. كذلك يربطها برمز التكلفة أو المورد أو الأصل أو الفحص أو المعاملة التشغيلية ذات الصلة.

هل تستطيع الطائرات المسيّرة قياس تقدم أعمال البناء تلقائيًا؟

يمكن للمسح التصويري بالطائرات المسيّرة والذكاء الاصطناعي أتمتة أجزاء كبيرة من قياس التقدم. ويصح ذلك خاصةً حين يمكن رصد الكميات أو الأشكال الهندسية الفعلية بصورة موثوقة. وتُثبت الأبحاث إمكانية مقارنة نماذج الوضع المنفَّذ المولّدة بالطائرات المسيّرة بنماذج BIM المخططة. ويظل التحقق البشري مهمًا، خاصةً في الاعتماد التعاقدي والأعمال المخفية والأنشطة التي لا يمكن رصدها عن بُعد بصورة موثوقة.

لماذا ينبغي ربط بيانات الطائرات المسيّرة ببيانات المعدات والعمالة؟

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

كيف يمكن للذكاء الاصطناعي تحسين مراقبة البناء القائمة على الطائرات المسيّرة؟

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

كيف ينطبق ذلك على البناء البحري والبحري البعيد عن الشاطئ؟

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

المراجع وقراءات إضافية

تحليل سوق الطائرات المسيّرة للبناء في اليابان: Optiusd Group، Japan Construction Drone Market Regional Size, Trends and Forecast to 2033. اقرأ مقال السوق على LinkedIn

برنامج i-Construction الياباني والمسح بالطائرات المسيّرة: وزارة الأراضي والبنية التحتية والنقل والسياحة / هيئة المعلومات الجغرافية المكانية في اليابان. إرشادات i-Construction الصادرة عن MLIT إرشادات GSI للخرائط ثلاثية الأبعاد والطائرات المسيّرة

الأبحاث الأكاديمية: Unmanned Aerial Vehicles Integration with Digital Technologies toward Construction 4.0، Sustainability. اقرأ المراجعة المنهجية للأدبيات

متابعة التقدم بالطائرات المسيّرة + BIM: Integrated Information System for Periodic Construction Progress Monitoring: Utilizing UAV, Photogrammetry, and BIM، Civil Engineering Sciences، 2026. اقرأ المقال البحثي

استخدام المعدات الثقيلة: Caterpillar Fleet Management وKomatsu Smart Construction. استخدام المعدات لدى Caterpillar لوحة معلومات Komatsu Smart Construction

الفحص البحري بالطائرات المسيّرة: مسوحات السفن عن بُعد وبمساعدة الطائرات المسيّرة من DNV. مسوحات DNV بالطائرات المسيّرة

DANAOS ProjectVIEW ERP: ProjectVIEW ERP ونظام التشغيل ProjectVIEW AI

العمليات البحرية والبحرية البعيدة عن الشاطئ: ProjectVIEW ERP للبناء البحري وعمليات المنبع

موارد ذات صلة

برنامج إدارة أحواض بناء السفن ونظام ERP لبناء السفن · نظام ERP للبناء البحري والعمليات البحرية · ProjectVIEW ERP وNVIDIA Omniverse

Read more: من بيانات الطائرات المسيّرة إلى التحكم في المشاريع: كيف يربط ProjectVIEW ERP والذكاء الاصطناعي واقع الموقع وحوض بناء السفن والعمليات البحرية

لماذا يحتاج كبار المقاولين إلى التمييز بين البرمجيات على مستوى المهام، والمنصات على مستوى المشاريع، وأنظمة ERP للبناء على مستوى المؤسسة بأكملها قبل الحديث عن «التكامل»

تحيط البرمجيات اليوم بشركات البناء من كل جانب.

برمجيات الجدولة. برمجيات تقدير التكاليف. تطبيقات حصر الكميات. منصات BIM. بيئات البيانات المشتركة. أنظمة إدارة الوثائق. أدوات المشتريات. التطبيقات الميدانية. الأنظمة المحاسبية. أنظمة إدارة الموارد البشرية. أنظمة إدارة المستودعات. منصات ضبط المشاريع. منصات إدارة البناء. أنظمة تخطيط موارد المؤسسات (ERP).

في الواقع، يدّعي كل مورّد تقريبًا اليوم أنه يقدّم «منصة متكاملة» أو «مصدرًا واحدًا للحقيقة» أو «حلًا شاملًا من البداية إلى النهاية».

وهذا يخلق مشكلة جوهرية.

بعبارة أخرى، نحن نستخدم الكلمات نفسها لوصف أنظمة صُمّمت لمعالجة مستويات مختلفة تمامًا من أعمال البناء.

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

لذلك، لفهم تقنيات البناء فهمًا صحيحًا، أعتقد أننا بحاجة إلى تقسيم السوق إلى ثلاث طبقات رئيسية:

1. التطبيقات المخصصة لأغراض محددة

2. منصات البناء الموجّهة نحو المشاريع (طبقات البناء)

3. أنظمة ERP للبناء على مستوى المؤسسة بأكملها

لا شك في وجود تداخل بينها.

ومع ذلك، تزداد الحدود بينها ضبابية مع توسيع المورّدين لوظائف أنظمتهم، واستحواذهم على تطبيقات أخرى، وبنائهم منظومات للتكامل.

لكن هذا التمييز يظل أساسيًا.

لأن السؤال الحقيقي ليس:

«كم عدد الميزات التي يتضمنها هذا البرنامج؟»

السؤال الحقيقي هو:

ما مستوى المؤسسة الذي يحكمه البرنامج؟

هذا السؤال يغيّر كل شيء.

1. تطبيقات البناء المخصصة لأغراض محددة: حل مشكلة واحدة بإتقان بالغ

أولاً، تشمل الفئة الأولى التطبيقات المصممة حول مهمة أو تخصص أو تحدٍّ تشغيلي محدد.

ومن الأمثلة على ذلك:

• الجدولة والتخطيط؛
• حصر الكميات؛
• تقدير التكاليف؛
• إعداد نماذج BIM؛
• التعليق على الوثائق؛
• رصد الواقع (Reality Capture)؛
• إدارة السلامة؛
• أنظمة التتبع عن بُعد للمعدات؛
• الرواتب؛
• المحاسبة؛
• المشتريات؛
• صيانة الأصول؛
• التقارير الميدانية؛
• إدارة الجودة.

وتكمن قيمة هذه التطبيقات تحديدًا في تخصصها.

لنأخذ Oracle Primavera P6 مثالًا.

على سبيل المثال، تصف Oracle نظام Primavera P6 Enterprise Project Portfolio Management بأنه حل لتحديد أولويات المشاريع والبرامج والمحافظ وتخطيطها وإدارتها وتقييمها. كما تشمل نقاط قوته الجدولة والموارد ومتابعة التقدم وإدارة محافظ المشاريع. كما تنص Oracle صراحةً على أن P6 يمكنه مشاركة البيانات مع الأنظمة المالية وأنظمة رأس المال البشري وأنظمة ERP.

في الواقع، هذا بالضبط ما ينبغي أن نتوقعه.

إذ لا يحتاج Primavera إلى أن يصبح نظام الرواتب والمشتريات والمستودعات ودفتر الأستاذ العام لدى المقاول كي يكون منصة جدولة متميزة.

فمسؤوليته الأساسية مختلفة.

وبالمثل، قد تعالج الأنظمة المتخصصة لحصر الكميات (QTO)، وأنظمة التقدير، وتطبيقات BIM، ومنصات التتبع عن بُعد للمعدات، وتقنيات رصد الواقع، مشكلاتها الخاصة على نحو أفضل مما يمكن لأي تطبيق مؤسسي كبير أن يفعله.

باختصار، إن قوة البرمجيات المخصصة لأغراض محددة تكمن في العمق.

وقيدها الطبيعي هو النطاق المؤسسي.

لذلك ينتج التطبيق المتخصص عادةً ما يمكن أن نسميه:

الحقيقة على مستوى المهمة

على سبيل المثال، يثق المخطط في Primavera فيما يخص الجدول الزمني.

ويثق المقدِّر في نظام التقدير فيما يخص التقديرات.

ويثق فريق BIM في نموذجه.

كذلك يثق مهندس الكميات في تطبيق QTO.

وأخيراً، يثق مدير المعدات في منصة التتبع عن بُعد.

في الواقع، قد يكون كلٌّ منهم محقًا ضمن نطاقه.

تبدأ المشكلة عندما تحتاج المؤسسة إلى فهم كيفية تأثير كل هذه الحقائق بعضها في بعض.

2. منصات البناء الموجّهة نحو المشاريع: صنع الحقيقة على مستوى المشروع

نشأت الفئة الثانية لأن قطاع البناء يتسم بخاصية فريدة أخرى:

نادرًا ما تنفّذ شركة واحدة المشروع بمفردها.

قد يشمل المشروع الكبير:

• المالك؛
• المهندس أو الاستشاري؛
• المقاول الرئيسي؛
• شركاء المشروع المشترك؛
• المقاولين من الباطن؛
• الموردين؛
• المصممين؛
• مديري المشاريع؛
• مهندسي الكميات؛
• الجهات الحكومية؛
• المفتشين المستقلين.

لذلك تحتاج هذه الجهات إلى تبادل كميات هائلة من المعلومات دون أن تنتمي بالضرورة إلى المؤسسة نفسها.

فهي تتبادل:

المخططات، وطلبات الاستيضاح (RFI)، والمستندات المقدَّمة للاعتماد، والمراسلات، وطلبات التغيير، وسجلات الفحص، والعقود، والنماذج، والجداول الزمنية، والصور، والوثائق، والمعلومات التجارية.

نتيجة لذلك، نشأت الحاجة إلى منصات البناء الموجّهة نحو المشاريع.

بعبارة أخرى، محور التنظيم الطبيعي فيها هو المشروع.

Procore

على سبيل المثال، يمثّل Procore مثالًا قويًا على ذلك.

فهو يوفّر بيئة واسعة لإدارة البناء تتمحور حول تنفيذ المشاريع والإدارة الميدانية والإدارة التجارية وسير العمل المالي للمشروع.

لكن بنية Procore نفسها تُبرز أيضًا تمييزًا مهمًا.

إذ تربط أدوات تكامل ERP لديه Procore بأنظمة مثل Viewpoint Vista وSpectrum وSage وNetSuite وCMiC وQuickBooks وAcumatica وWorkday وغيرها. كما يصف Procore هذه التكاملات بأنها آليات لربط معلومات مشاريع البناء ببيئة ERP أو البيئة المحاسبية للشركة.

ومع ذلك، لا يُضعف هذا القيمة التي يقدمها Procore.

بل يساعد على تحديدها.

فيمكن أن يكون Procore طبقة إدارة بناء قوية للغاية، بينما تظل منصة أخرى مسؤولة عن المحاسبة المؤسسية ووظائف ERP.

Autodesk Construction Cloud

كذلك يتبع Autodesk Construction Cloud مبدأً معماريًا مشابهًا.

إذ توفّر Autodesk قدرات واسعة لإدارة البناء ومنظومة تكامل تربط Autodesk Construction Cloud بتطبيقات ERP والتطبيقات المالية الخارجية.

كما تنشر Autodesk صراحةً إرشادات حول ربط بيئة البناء لديها بأنظمة ERP والأنظمة المالية للتخلص من الإدخال المزدوج للبيانات ومزامنة المعلومات المالية بين الموقع والمكاتب الإدارية.

ومرة أخرى، يوضح هذا الفرق بين تقنيات تنفيذ المشاريع والعمود الفقري للمؤسسة.

Oracle Aconex

في المقابل، ربما يقدّم Oracle Aconex أحد أوضح الأمثلة على ما أسميه الحقيقة على مستوى المشروع.

تصف Oracle نظام Aconex بأنه بيئة بيانات مشتركة (Common Data Environment – CDE)، أي بيئة مركزية تربط المؤسسات والعمليات ومعلومات المشروع.

ويتميز Aconex بقوة خاصة لأن كل جهة مشاركة في المشروع تحتفظ بالتحكم في معلوماتها أثناء التعاون ضمن بيئة مشروع مشتركة. وتصفه Oracle صراحةً بأنه نظام ينشئ مصدرًا واحدًا للحقيقة للمشروع.

وهذه الصياغة مهمة:

للمشروع.

بعبارة أخرى، يمكن لـAconex أن يوفّر سجلًا مرجعيًا معتمدًا للمشروع يضم الوثائق والمراسلات والنماذج والموافقات والقرارات.

وهذا ذو قيمة كبيرة جدًا.

لكن حقيقة المشروع وحقيقة المؤسسة ليستا بالضرورة الشيء نفسه.

Trimble ProjectSight

كذلك يقدّم Trimble ProjectSight مثالًا مفيدًا آخر.

تتيح وثائق Trimble الحالية ربط الشركات والمشاريع داخل ProjectSight مباشرةً ببيئة ERP. ويمكن بعد ذلك مزامنة العقود وأوامر الشراء مع نظام ERP هذا.

ومرة أخرى، تخبرنا البنية نفسها بشيء ما.

باختصار، منصة المشروع تدير سير عمل البناء.

ويبقى نظام ERP نظامًا مؤسسيًا.

3. أنظمة ERP للبناء على مستوى المؤسسة: حوكمة المقاول لا المشروع فحسب

نصل الآن إلى الفئة الثالثة.

ومع ذلك، المقاول ليس مجرد مجموعة من المشاريع.

إنه شركة.

في الواقع، كثيرًا ما يكون كبار المقاولين أكثر تعقيدًا من ذلك بكثير.

فقد تتألف من:

• كيانات قانونية متعددة؛
• شركات تابعة؛
• مشاريع مشتركة؛
• وحدات أعمال؛
• عمليات إقليمية؛
• مئات المشاريع المتزامنة؛
• آلاف الموظفين؛
• أساطيل معدات؛
• ساحات إنتاج أو تصنيع؛
• مستودعات؛
• مقاولين من الباطن؛
• موردين؛
• عملات متعددة؛
• ولايات ضريبية متعددة؛
• أنظمة رواتب مختلفة؛
• تسلسلات هرمية مؤسسية للاعتماد؛
• أدلة حسابات مختلفة.

كما أن المشاريع تستهلك موارد تملكها هذه المؤسسة.

وهذا هو السبب في وجود تخطيط موارد المؤسسات (ERP) أصلًا.

لذلك يتعين على نظام ERP للبناء على مستوى المؤسسة أن يدير ليس المشروع فحسب، بل العلاقة بين المشروع والمؤسسة أيضًا.

ومن أمثلة هذه الفئة أنظمة مثل Trimble Viewpoint Vista وCMiC وSage X3 Construction وDANAOS ProjectVIEW ERP، رغم أن بنيتها وعمقها الوظيفي وأسواقها المستهدفة تختلف اختلافًا كبيرًا.

Viewpoint Vista

على سبيل المثال، تصف Trimble نظام Vista بأنه حل ERP للبناء متكامل بالكامل يغطي مجالات منها:

• تكاليف الأعمال؛
• الإدارة المالية؛
• الرواتب؛
• الموارد البشرية؛
• المعدات؛
• إدارة الخدمات؛
• عمليات موقع العمل؛
• التحليلات.

كما توضح وثائق Vista بدقة ما يعنيه التكامل المؤسسي. إذ يمكن لمعاملات الرواتب أن تحدّث تكاليف الأعمال ودفتر الأستاذ العام وإدارة المعدات والحسابات الدائنة وغيرها من الهياكل المالية.

وهذا أكثر من مجرد مشاركة مستند أو مزامنة حقل بيانات.

إنه تكامل على مستوى المعاملات.

CMiC

كذلك تصف CMiC بنيتها صراحةً بأنها نظام ERP للبناء مبني على منصة قاعدة بيانات واحدة.

ويجمع حلها بين الشؤون المالية للبناء وإدارة المشاريع، بينما يعمل سير العمل والتحليلات عبر كليهما.

وتشمل بيئتها المالية المحاسبة والرواتب وإدارة رأس المال البشري والمعدات والمخزون، بينما تمتد بيئة إدارة المشاريع لديها إلى ضبط المشاريع والمشتريات والجودة والسلامة والمخططات والتوثيق.

ومرة أخرى، فإن الفارق المهم هو النطاق.

بعبارة أخرى، التطبيق لا يقتصر على إدارة ما يحدث داخل المشروع.

بل يربط نشاط المشروع مباشرةً بالعمليات المالية والتشغيلية للمؤسسة.

Sage X3 Construction

كذلك يقدّم Sage X3 Construction مثالًا آخر.

إذ تضع Sage هذا الحل في مجالات التقدير وإدارة المشاريع وتكاليف المشاريع والمشتريات والمخزون وإدارة العقود والإدارة المالية والموارد البشرية والرواتب والتحليلات.

والأهم من ذلك أنه يدعم أيضًا مشاريع وعملات وكيانات أعمال متعددة.

لذلك فهذه سمة من سمات أنظمة ERP.

فيجب أن يفهم النظام كلًا من:

هيكل المشروع

و

الهيكل المؤسسي.

الفئات ليست مطلقة، وهذا أمر مهم

أسواق البرمجيات ليست ثابتة.

• يواصل مورّدو إدارة المشاريع إضافة وظائف مالية.
• ويواصل مورّدو ERP إضافة قدرات ميدانية وقدرات لإدارة المشاريع.
• على سبيل المثال، يتوسع مورّدو الجدولة نحو ضبط المشاريع.

كذلك تدعم منصات CDE بشكل متزايد سير العمل والعمليات التجارية والتحليلات.

كما يمثّل Microsoft Dynamics 365 Project Operations مثالًا ممتازًا على هذا التداخل.

إذ تقدّم Microsoft نظام Project Operations بتكوينات نشر مختلفة، منها بيئة أساسية موجّهة نحو المشاريع وبيئة متكاملة مع Dynamics 365 Finance. ومع ذلك، تميّز Microsoft صراحةً بين وظائف Project Operations وعمليات النشر المتكاملة مع ERP.

وفي البنية المتكاملة مع ERP، تزامن Microsoft البيانات بين Dataverse وDynamics 365 Finance باستخدام تقنية الكتابة المزدوجة (dual-write)، بينما يوفّر Finance إطار محاسبة المشاريع والإطار المالي.

لذا لا يحاول هذا المقال إنشاء تصنيفات برمجية مصطنعة.

فالفئات تصف المسؤولية المعمارية.

بعبارة أخرى، قد تشارك منصة واحدة في عدة طبقات.

لكن في نهاية المطاف، لا يزال على كل بنية مؤسسية أن تجيب عن السؤال التالي:

أي نظام يحكم أي حقيقة؟

حقيقة المهمة وحقيقة المشروع وحقيقة المؤسسة

باختصار، يمكن اختزال هذا التمييز في ثلاثة مستويات.

التطبيق المخصص لغرض محدد

يُنتج حقيقة المهمة

المنصة الموجّهة نحو المشاريع

تُنتج حقيقة المشروع

نظام ERP على مستوى المؤسسة

يُنتج حقيقة المؤسسة

هذه الحقائق متكاملة.

لكنها ليست قابلة للتبادل.

بيئة البيانات المشتركة ليست بالضرورة نظام ERP

يستحق هذا التمييز اهتمامًا خاصًا لأن مصطلحَي CDE و«المصدر الواحد للحقيقة» أصبحا يُستخدمان بإفراط.

على سبيل المثال، تعرّف Oracle بيئة البيانات المشتركة بأنها بيئة سحابية تُخزَّن فيها معلومات مشاريع البناء ويصل إليها المشاركون المصرّح لهم.

وهذا تعريف مناسب.

يمكن أن تصبح بيئة CDE البيئة المرجعية المعتمدة لما يلي:

• الوثائق؛
• المخططات؛
• النماذج؛
• المراسلات؛
• المراجعات؛
• الموافقات؛
• سجلات المشروع.

لكن على نظام ERP أن يجيب عن مجموعة مختلفة من الأسئلة:

• من يملك المادة؟
• في أي مستودع توجد؟
• لأي مورّد جرى الدفع؟
• أي كيان قانوني تعاقد مع المورّد؟
• أي مشروع استهلك المادة؟
• أي رمز تكلفة تأثّر؟
• أي قيد محاسبي نُشئ؟
• ما المعالجة الضريبية التي طُبّقت؟
• كيف أثّرت المعاملة في التدفق النقدي؟
• كيف أثّرت في ربحية المشروع؟

هذه معاملات مؤسسية، وليست مجرد معلومات عن المشروع.

لذلك يمكن لبيئة CDE الخاصة بالمشروع ونظام ERP المؤسسي أن يتعايشا، بل ينبغي ذلك في كثير من الأحيان.

لكن تسمية كليهما «مصدرًا واحدًا للحقيقة» دون تحديد النطاق يثير الالتباس.

الاتصال ليس تكاملًا

قد تكون هذه أهم نقطة في النقاش بأكمله.

اليوم، يمتلك كل تطبيق مؤسسي تقريبًا واجهة برمجة تطبيقات (API).

لكن ذلك لا يعني أن كل تطبيق مؤسسي متكامل.

يمكن لواجهة API أن ترسل:

• رقم مورّد،
• أمر شراء،
• فاتورة،
• رمز مشروع،
• قيمة تكلفة،
• كمية،
• مستندًا،
• أو حالة.

صحيح أن هذا يثبت أن الأنظمة قادرة على التواصل.

لكنه لا يثبت أنها تتشارك منطق الأعمال نفسه.

ذلك لأن التكامل المؤسسي الحقيقي يتطلب ما هو أكثر بكثير.

إنه يتطلب:

• بيانات رئيسية مشتركة؛
• معرّفات مشتركة؛
• هياكل تنظيمية مشتركة؛
• منطق سير عمل مشترك؛
• استمرارية المعاملات؛
• المطابقة المالية؛
• حوكمة الوصول؛
• تتبّع مسار البيانات؛
• المساءلة.

لنأخذ مثالًا بسيطًا من البناء.

على سبيل المثال، يحتاج موقع ما إلى 2,000 متر من الكابلات.

ومع ذلك، لا ينبغي أن يتحول هذا الاحتياج ببساطة إلى أمر شراء.

فقد يلزم ربطه بما يلي:

المشروع ← BoQ ← نشاط WBS ← رمز التكلفة ← رمز المادة ← المورّد ← حزمة المشتريات ← المستودع ← مذكرة الاستلام (GRN) ← الصرف للموقع ← الاستهلاك الفعلي ← التكلفة ← المحاسبة

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

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

بل تملك قواعد بيانات متعددة تحاول دوريًا أن تتوافق فيما بينها.

وهذا أمر مختلف تمامًا.

لم تعد المشكلة الرقمية في قطاع البناء نقصًا في البرمجيات

يمتلك القطاع بالفعل كميات هائلة من البرمجيات.

والمشكلة الأكبر هي التجزئة.

على سبيل المثال، وصفت McKinsey تقنيات البناء بأنها سوق شديدة التجزئة تقودها الحلول المتخصصة، ولاحظت أن عدم الرضا عن دمج العديد من الحلول المتخصصة أسهم في اتجاه القطاع نحو المنصات المتكاملة.

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

لقد انتقل التحدي من:

«كيف نرقمن هذه العملية؟»

إلى:

«كيف نجعل جميع العمليات المرقمنة تمثّل واقع الأعمال نفسه؟»

لماذا يحتاج كبار المقاولين إلى نظام ERP كعمود فقري؟

بالنسبة إلى المقاول على مستوى المؤسسات، هناك عدة عناصر تحتاج في النهاية إلى مالك مؤسسي واحد.

1. البيانات الرئيسية

لهذا السبب، يجب أن تتولى جهة ما حوكمة:

• المواد،
• تخصصات العمالة،
• الموظفين،
• الموردين،
• المقاولين من الباطن،
• المعدات،
• رموز التكاليف،
• الشركات،
• العملات،
• وحدات القياس،
• المشاريع،
• المستودعات،
• الحسابات المصرفية.

إذا احتوى كل تطبيق مشروع على نسخة مختلفة، يتحول التكامل إلى مطابقة دائمة.

2. العاقبة المالية

لكل نشاط إنشائي تقريبًا عاقبة مالية في نهاية المطاف.

• العمالة تكلّف مالًا.
• المواد تكلّف مالًا.
• المعدات تكلّف مالًا.
• المقاولون من الباطن يكلّفون مالًا.
• التأخيرات تكلّف مالًا.
• التغييرات تكلّف مالًا.

وحتى التقدم له أهمية تجارية، لأنه يتحول في النهاية إلى:

اعتماد الأعمال المنجزة ← الإيرادات ← الفاتورة ← الحسابات المدينة ← النقد.

لذلك لا يمكن أن تظل إدارة البناء والإدارة المالية منفصلتين بشكل دائم.

3. موارد المؤسسة

لا تملك المشاريع بشكل مستقل القوى العاملة للشركة أو معداتها أو علاقاتها مع الموردين أو نقدها أو معرفتها المؤسسية.

بل إن المؤسسة هي التي تملك هذه الموارد وتوزّعها بين المشاريع.

وهذا يعني أن تنفيذ المشاريع يجب أن يرتبط في النهاية مجددًا بإدارة موارد المؤسسة.

4. إدارة المحافظ

يدير مدير المشروع مشروعًا.

أما الرئيس التنفيذي فلا.

بعبارة أخرى، الرئيس التنفيذي يدير شركة تضم محفظة من المشاريع.

لذلك تحتاج الإدارة العليا إلى الاتساق عبر:

• المشاريع،
• وحدات الأعمال،
• الدول،
• الشركات التابعة،
• المشاريع المشتركة،
• العملات،
• وفترات إعداد التقارير.

لذلك يتطلب هذا المستوى من الحوكمة نموذجًا مؤسسيًا.

البنية الصحيحة ليست «تطبيقًا واحدًا يفعل كل شيء»

وهذا تمييز مهم آخر.

ومع ذلك، فإن الدعوة إلى نظام ERP كعمود فقري لا تعني معارضة البرمجيات المتخصصة.

فذلك سيكون سذاجة تقنية.

على سبيل المثال، يمكن للمقاول أن يستخدم بشكل مشروع تمامًا:

• Primavera P6 للجدولة.
• Revit أو Tekla للتصميم وBIM.
• Aconex كبيئة CDE تعاقدية.

نظامًا متخصصًا لرصد الواقع لتصوير الموقع.

أنظمة متخصصة للتتبع عن بُعد للمعدات.

تطبيقات هندسية متخصصة.

وربما منصات يفرضها العميل ولا يمكن استبدالها.

والمبدأ المعماري الصحيح هو:

التطبيقات المتخصصة على الأطراف. ونظام ERP في القلب.

تؤدي التطبيقات المتخصصة المهام التي صُمّمت من أجلها.

في المقابل، يتولى نظام ERP تنسيق العواقب التجارية والتشغيلية والمالية على مستوى المؤسسة بأكملها.

باختصار، المشكلة ليست في امتلاك تطبيقات كثيرة.

المشكلة في وجود مراكز ثقل كثيرة.

أين يقع DANAOS ProjectVIEW ERP؟

ينتمي DANAOS ProjectVIEW ERP أساسًا إلى الفئة الثالثة:

نظام ERP للبناء على مستوى المؤسسة

فقد صمّمت DANAOS Projects نظام ProjectVIEW كحل مؤسسي لمؤسسات البناء متعددة التخصصات والجنسيات والوظائف ذات العمليات الموزعة. كما تصف الوثائق الفنية لـDANAOS وحداته بأنها تطبيقات مخصصة لأغراض محددة تتوافق مع أقسام شركة البناء، لكنها تتشارك الملفات الرئيسية وموارد النظام نفسها داخل منصة مركزية واحدة.

ويمتد نطاقه ليشمل:

• التقدير والمناقصات؛
• الموازنة وضبط التكاليف؛
• التوريد والمشتريات؛
• إدارة المستودعات والمواد؛
• إدارة المقاولين من الباطن؛
• الإنتاج والتصنيع؛
• المعدات والصيانة؛
• نظام HRMS وإدارة العمالة؛
• عقود العملاء؛
• المحاسبة والمالية؛
• الوثائق؛
• التحليلات؛
• سير العمل؛
• التطبيقات الميدانية؛
• البوابات الخارجية.

والمبدأ الأساسي هنا مهم.

ومع ذلك، فهذه الوحدات ليست مصممة لتعمل كجزر منفصلة للأقسام.

بل تعمل فوق هيكل مشترك للمشروع والمؤسسة.

كذلك تصف بنية SaaS الحالية لدى DANAOS نظام ProjectVIEW ERP بأنه نظام ERP بمستوى يلائم قطاع البناء، يتألف من 10+1 وحدات مؤسسية تغطي العمليات التجارية والتشغيلية والإنتاجية والمالية.

المنطق الأساسي للبناء في ProjectVIEW: BoQ WBS رموز التكاليف

يطرح قطاع البناء تحديًا خاصًا أمام أنظمة ERP لأن أبعاده الأساسية تأتي من مصادر مختلفة.

فـجدول الكميات (Bill of Quantities – BoQ) يخبرنا بما يتوقع العميل تسليمه وبأي كمية.

وهيكل تجزئة العمل (Work Breakdown Structure – WBS) يخبرنا بكيفية تسلسل العمل عبر الزمن.

وهيكل رموز التكاليف يخبرنا بكيفية تصنيف المقاول للإنفاق والموارد داخليًا.

هذه الهياكل مترابطة.

لكنها ليست متطابقة.

لذلك يربط منطق الأعمال في ProjectVIEW بين:

BoQ WBS رموز التكاليف

لذلك تصف DANAOS ذلك بأنه نواة المشروع التي تربط النطاق والوقت والتكلفة.

وداخليًا، تصف وثائق ProjectVIEW هذه العلاقة بأنها التكامل الثلاثي بين جدول كميات العميل (BoQ) وهيكل تجزئة العمل (WBS) الخاص بالجدولة ورموز التكاليف الداخلية، بهدف ربط التكلفة والوقت والموارد.

في الواقع، هذا أهم مما يبدو للوهلة الأولى.

لأن أداء البناء لا يمكن قياسه من خلال تقدم الجدول الزمني وحده.

على سبيل المثال، تخيّل أن الموقع أبلغ بما يلي:

«النشاط مكتمل بنسبة 50%».

ينبغي أن يكون السؤال البديهي:

50% وفقًا لماذا؟

يمكن قياس التقدم الفعلي من خلال الكمية أو النسبة المنجزة مقارنةً بجدول الكميات (BoQ) أو هيكل تجزئة العمل (WBS) المعني.

لكن ضبط التكاليف يتطلب سؤالًا ثانيًا:

ما الموارد التي استُهلكت لتحقيق هذه النسبة البالغة 50%؟

العمالة.

المواد.

المعدات.

المقاولون من الباطن.

الموارد غير المباشرة.

إذا لم تتوافق الكمية المنجزة ومعدل الإنتاج والوقت والتكلفة المستهلكة مع خط الأساس، فهذا يعني أن شيئًا ما قد تغيّر.

نتيجة لذلك، تتحول عند هذه النقطة إدارة البناء إلى تحكم اقتصادي، لا مجرد إعداد تقارير عن التقدم.

لماذا يظل ProjectVIEW متكاملًا مع Primavera وBIM وSAP وOracle؟

إذا كان ProjectVIEW نظام ERP، فلماذا يتكامل مع أنظمة أخرى؟

لأن العمود الفقري للمؤسسة لا ينبغي أن يصبح ذريعة للعزلة التقنية.

كذلك صمّمت DANAOS Projects نظام ProjectVIEW للاتصال بتقنيات البناء المتخصصة، بما في ذلك Oracle Primavera P6 وMicrosoft Project وبيئات BIM.

ويمكنه أيضًا الاتصال بمنصات مؤسسية من أطراف ثالثة مثل SAP أو Oracle عبر واجهات API عند الحاجة. وتنص الوثائق الفنية لـDANAOS صراحةً على هذه البنى الهجينة.

لذلك يكتسب هذا أهمية خاصة للمجموعات متعددة الجنسيات الكبيرة جدًا.

على سبيل المثال، قد تكون الشركة القابضة قد اعتمدت SAP أو Oracle معيارًا عالميًا لشؤونها المالية.

وقد لا يكون استبدال هذه المنصة واقعيًا من الناحية التجارية ولا ضروريًا من الناحية التقنية.

وفي هذا السيناريو:

قد يظل SAP/Oracle نظام ERP المالي للمؤسسة، بينما

في هذه الحالة، يصبح ProjectVIEW طبقة التشغيل الخاصة بالبناء التي تدير العمليات الأعمق الخاصة بقطاع البناء.

وهذه بنية مشروعة.

وبذلك يمكن للبرنامج نفسه أن يؤدي أدوارًا مختلفة بحسب طريقة النشر.

إذن، ما الذي ينبغي أن يعنيه «المصدر الواحد للحقيقة» فعلًا؟

لا ينبغي أن يعني أن كل بايت من البيانات يجب أن يوجد فعليًا في قاعدة بيانات واحدة.

ذلك لأن هذا التعريف قد عفا عليه الزمن.

يمكن للمؤسسة الحديثة أن تشغّل بشكل مشروع عدة أنظمة سجلات مرجعية.

بدلاً من ذلك، المطلوب هو أن تكون ملكية البيانات واضحة لا لبس فيها.

على سبيل المثال:

• على سبيل المثال، قد يملك Primavera الجدول الزمني المعتمد.
• وقد تملك بيئة BIM النموذج الحالي.
• وقد يملك Aconex سجل الوثائق التعاقدية.

وأخيراً، قد يملك نظام ERP معاملات الموردين والموظفين والمحاسبة والمشتريات والتكاليف.

المهم أن تعرف جميع الأنظمة المشاركة:

أي نظام يملك أي حقيقة،

وأي معرّفات تربط بينها،

و

كيف تنتقل المعاملة بينها دون أن تفقد معناها.

هذه هي البنية المؤسسية.

كيف ينبغي للمقاولين اختبار ما إذا كانت المنصة متكاملة فعلًا؟

بدلًا من أن تسأل المورّد:

اطرح الأسئلة التالية:

أين تُنشأ البيانات الرئيسية؟

من يملك بيانات الموردين والمواد والموظفين والمعدات ورموز التكاليف والجهات والمشاريع؟

هل تحافظ المعاملات على هويتها؟

هل يمكن لاحتياج ما أن ينتقل من طلب الموقع إلى المشتريات وأمر الشراء والاستلام والاستهلاك والتكلفة والمالية دون إعادة إنشائه؟

هل يمكن مطابقة التقدم الفعلي مع استهلاك الموارد؟

هل تستطيع الإدارة أن تفهم ما إذا كانت التكلفة المتكبدة مبرَّرة بكمية العمل المنجز؟

هل يستطيع النظام إدارة الهيكل المؤسسي؟

• شركات متعددة؟
• شركات تابعة؟
• مشاريع مشتركة؟
• دول؟
• عملات؟
• مشاريع؟

هل يصل النشاط التشغيلي إلى الإدارة المالية؟

هل تُنشئ معاملة البناء في النهاية عاقبة مالية قابلة للتدقيق؟

هل يستطيع التنفيذيون مقارنة المشاريع بشكل متسق؟

أم يتعين على ذكاء الأعمال أولًا توحيد عشرة هياكل بيانات مختلفة؟

هل يمكن تتبع مؤشر أداء رئيسي (KPI) وصولًا إلى المعاملة الأصلية؟

إذا رصدت الإدارة انحرافًا في التكاليف، فهل يستطيع المستخدمون التعمق لتحديد معاملة العمالة أو المواد أو المعدات أو المقاول من الباطن أو المشتريات المسؤولة عنه؟

باختصار، تكشف هذه الأسئلة أكثر بكثير مما تكشفه مقارنة الميزات.

أين يأتي دور الذكاء الاصطناعي في كل هذا؟

إضافةً إلى ذلك، هناك سبب آخر يجعل هذا النقاش ملحًّا.

الذكاء الاصطناعي.

تتسابق الشركات الآن لإدخال وكلاء الذكاء الاصطناعي والمساعدين الذكيين (Copilots) والأنظمة التنبؤية إلى قطاع البناء.

لكن الذكاء الاصطناعي يضاعف جودة البيانات والعمليات التي يقوم عليها.

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

بل سيسرّع استهلاك عدم الاتساق.

ولهذا تكتسب بيانات ERP المنظمة أهمية استراتيجية.

كما تضع البنية الحالية لـProjectVIEW نظام ERP بوصفه طبقة العمليات والبيانات المنظمة تحت بيئة الذكاء الاصطناعي الخاصة به، مستخدمةً BoQ وWBS ورموز التكاليف أبعادًا للمشروع يمكن للآلة فهمها.

وقبل أن تسعى المؤسسات إلى ذكاء اصطناعي مستقل للبناء، فإنها تحتاج إلى شيء أقل بريقًا بكثير، لكنه أهم بكثير:

بيانات مؤسسية متسقة.

الأسئلة الشائعة

ما الفرق بين برمجيات إدارة البناء وأنظمة ERP للبناء؟

تساعد برمجيات إدارة البناء أساسًا على تنسيق تنفيذ المشاريع وضبطه.

أما نظام ERP للبناء فيربط تنفيذ المشاريع بوظائف المؤسسة مثل المشتريات والمخزون والرواتب والمعدات والمحاسبة والمالية وموارد المؤسسة وإدارة المحافظ.

هل Procore نظام ERP؟

يوفّر Procore وظائف واسعة لإدارة البناء والشؤون المالية للمشاريع، لكن Procore نفسه يوفّر تكاملات مخصصة مع العديد من أنظمة ERP والأنظمة المحاسبية. وهذا يوضح قدرته على التعايش مع نظام ERP يشكّل العمود الفقري للمؤسسة، بدلًا من أن يُطلب من Procore نفسه أداء كل وظائف ERP.

هل Autodesk Construction Cloud نظام ERP؟

Autodesk Construction Cloud هو في الأساس بيئة للبناء وتنفيذ المشاريع. وتدعم Autodesk بفاعلية التكامل مع تطبيقات ERP والمحاسبة والتطبيقات المالية الخارجية.

هل بيئة CDE هي نفسها نظام ERP؟

لا.

تدير بيئة CDE معلومات المشروع المشتركة والتعاون.

أما نظام ERP فيدير موارد المؤسسة ومعاملاتها وعواقبها المالية.

ويمكنهما، بل ينبغي في كثير من الأحيان، أن يعملا معًا.

هل يُلغي نظام ERP الحاجة إلى التطبيقات المتخصصة؟

لا.

ينبغي أن تحتفظ البنية المؤسسية الناضجة بالتطبيقات المتخصصة حين توفّر هذه التطبيقات وظائف متفوقة في مجالها.

وينبغي لنظام ERP أن ينسّق عملها.

هل يمكن لنظام ERP عام مثل SAP أو Oracle أو Dynamics أن يعمل كعمود فقري للمؤسسة؟

بالتأكيد.

يمكن لمنصات ERP المؤسسية الكبيرة أن توفّر العمود الفقري للمؤسسة.

والسؤال بالنسبة إلى المقاولين هو ما إذا كان النظام يتضمن بشكل أصيل ما يكفي من منطق الأعمال الخاص بالبناء، أم أن هناك حاجة إلى طبقة تشغيل إضافية خاصة بالبناء.

هل ProjectVIEW ERP مجرد منصة لإدارة المشاريع؟

لا.

تمتد بنية ProjectVIEW ERP عبر العمليات التجارية والتشغيلية والمالية، مع قدرات تدعم تعدد الشركات وتعدد المشاريع، ووحدات خاصة بالبناء تتشارك بيانات مؤسسية مشتركة.

هل يمكن لـProjectVIEW أن يتعايش مع SAP أو Oracle؟

نعم.

تدعم DANAOS التكامل مع بيئات ERP الخارجية عندما ترغب مجموعة مؤسسية أكبر في الاحتفاظ بمنصتها المالية المؤسسية القائمة.

السؤال الحقيقي للتحول الرقمي

ركّز قطاع البناء خلال العقد الماضي تركيزًا كبيرًا على رقمنة العمليات الفردية.

وكان ذلك ضروريًا.

لكننا ندخل الآن المرحلة التالية.

فلم يعد التحدي ببساطة:

«هل يمكننا رقمنة هذه المهمة؟»

بل التحدي هو:

«هل يمكننا أن نجعل كل عملية رقمية تصف واقع الأعمال نفسه؟»

وهذا يتطلب بنية مؤسسية.

ويتطلب حوكمة.

ويتطلب بيانات رئيسية.

ويتطلب استمرارية المعاملات.

ويتطلب ربط الموقع بالمكتب، والمشروع بالشركة، وفي النهاية التقدم الفعلي للبناء بعاقبته المالية.

مع ذلك، ستظل التطبيقات المخصصة لأغراض محددة أساسية.

كذلك ستظل منصات التعاون في المشاريع أساسية.

وستظل بيئات CDE أساسية.

وستظل تطبيقات الجدولة أساسية.

وسيظل BIM أساسيًا.

لكن كبار المقاولين لا يزالون بحاجة إلى شيء في المركز.

شيء يجب أن يفهم الشركة.

شيء يجب أن يفهم مواردها.

شيء يجب أن يفهم كل مشروع.

شيء يجب أن يحوّل نشاط البناء إلى تكلفة وإيرادات وتدفق نقدي وربحية.

شيء يجب أن يطابق في النهاية بين:

ما وعدنا ببنائه

ومتى خططنا لبنائه. وما الموارد التي استهلكناها. وكم كلّف فعليًا. وما القيمة التي حققناها.

هذا هو دور نظام ERP للبناء.

التطبيقات المخصصة لأغراض محددة تُحسّن المهام.

والمنصات الموجّهة نحو المشاريع تنسّق المشاريع.

ونظام ERP للبناء يحكم المؤسسة.

وهذا بالتحديد هو المجال الذي صُمّم DANAOS ProjectVIEW ERP للعمل فيه:

لا بوصفه تطبيقًا آخر يحيط بمشروع البناء، بل بوصفه العمود الفقري المؤسسي المتخصص في البناء الذي ينسّق عمل الشركة التي تقف خلفه.

المصادر وقراءات إضافية

LinkedIn — إرشادات الظهور في البحث بالذكاء الاصطناعي توصي LinkedIn بالمقالات الطويلة بوصفها أصولًا لبناء المرجعية، وتؤكد على وضوح المصطلحات والعناوين بصيغة الأسئلة وأقسام الإجابة المستقلة واتساق لغة الفئات لتسهيل استرجاع المحتوى بواسطة الذكاء الاصطناعي. LinkedIn: How to Maximize AI Visibility for Your LinkedIn Posts

McKinsey — تجزئة تقنيات البناء وتكامل المنصات McKinsey: Rise of the Platform Era — The Next Chapter in Construction Technology

Oracle Primavera P6 Enterprise Project Portfolio Management Oracle Primavera P6 EPPM

Oracle Aconex — التعاون في المشاريع وبيئة البيانات المشتركة Oracle Aconex لإدارة مشاريع البناء

تكاملات ERP في Procore وثائق تكاملات ERP في Procore

Autodesk Construction Cloud — تكامل ERP والأنظمة المالية Autodesk: تكاملات ERP والأنظمة المالية للبناء

Trimble ProjectSight — تكامل ERP تكامل ERP في Trimble ProjectSight

Trimble Viewpoint Vista — نظام ERP للبناء Trimble Vista: نظام ERP للبناء

CMiC — نظام ERP للبناء منصة CMiC لأنظمة ERP للبناء

Sage X3 Construction Sage X3 Construction ERP

Microsoft Dynamics 365 Project Operations وثائق Microsoft Dynamics 365 Project Operations

DANAOS — ProjectVIEW OS وبنية BoQ WBS رموز التكاليف ProjectVIEW OS: نظام التشغيل لقطاع البناء

DANAOS — لماذا يأتي ERP قبل الذكاء الاصطناعي امشِ قبل أن تركض: لماذا يأتي ERP قبل الذكاء الاصطناعي

DANAOS — بنية SaaS والنطاق الوظيفي لـProjectVIEW ERP إطار SaaS الرئيسي لـDANAOS ProjectVIEW ERP

Read more: برمجيات البناء ليست سوقًا واحدة: شرح الحلول المتخصصة ومنصات المشاريع وأنظمة ERP للبناء

تصنيع الدفاع والفضاء ليس مجرد تصنيع. إنه تنفيذ مشاريع يكون فيه التصنيع مندمجاً داخل نطاق تعاقدي وهندسي وتسليمي أوسع.

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

إنها موجودة لأن مشروعاً محدداً يتطلبها.

لذلك يغيّر هذا الفارق منطق نظام ERP تغييراً كاملاً.

في التصنيع التقليدي، تكون قائمة المواد (Bill of Materials – BoM) عادةً هي البنية المهيمنة: ما المكونات اللازمة لتصنيع منتج ما؟

وللتبسيط، تستخدم هذه المقالة BoQ بوصفه تلك الركيزة التجارية/الخاصة بالمشروع.

ولذلك فإن المتطلب الجوهري ليس مجرد إدارة قائمة BoM.

بل هو إنشاء سلسلة رقمية قادرة على ترجمة:

متطلب المشروع ← BoQ ← WBS ← المنتج المصنَّع ← BoM ← عمليات الإنتاج ← الجودة ← التجميع/التركيب ← التكلفة ← التقدم

هذا هو الفرق بين برمجيات التصنيع ونظام ERP حقيقي للتصنيع القائم على المشاريع.

يقوم DANAOS ProjectVIEW ERP بالفعل بنمذجة هذه العلاقة من خلال بنية ERP للتصنيع القائم على المشاريع، حيث يمكن تحويل BoQ الخاص بالمشروع إلى قوائم BoM ومسارات تصنيع جاهزة للإنتاج مع بقائها مرتبطة بأنشطة WBS ورموز التكلفة. danaos-projects.com

ما هو التصنيع القائم على المشاريع في قطاعي الدفاع والفضاء؟

التصنيع القائم على المشاريع هو إنتاج عناصر هندسية مطلوبة تحديداً للوفاء بنطاق مشروع أو عقد أو مهمة، بدلاً من تجديد مخزون قياسي من المنتجات المتكررة.

كما يتداخل ذلك عادةً مع التصنيع وفق التصميم حسب الطلب (engineer-to-order) والتصنيع منخفض الحجم عالي التعقيد.

في الواقع، الفارق المهم اقتصادي بقدر ما هو تقني.

بعبارة أخرى، العنصر المصنَّع لا يوجد بوصفه منتجاً معزولاً.

بل يوجد داخل اقتصاديات المشروع الذي يتطلبه وجدوله الزمني.

يعكس دليل هندسة النظم (Systems Engineering Handbook) الصادر عن NASA الواقع الأوسع لهندسة النظم في قطاع الفضاء: فالتطوير وتحقيق المنتج عمليتان تكراريتان متعددتا التخصصات تمتدان عبر دورة حياة المشروع. وتُبرز NASA تحديداً هندسة النظم القائمة على النماذج (MBSE) بوصفها آلية لتحسين تطوير المنتجات وتسليمها. NASA

وبالمثل، تعمل برامج الفضاء الأوروبية ضمن إطار التعاون الأوروبي لتوحيد معايير الفضاء (ECSS)، الذي يدمج صراحةً إدارة المشاريع والهندسة والتصنيع الصناعي والإنتاج والصيانة وضمان المنتج. ويشترط معيار إدارة التهيئة فيه الحفاظ على العلاقة بين خصائص المنتج والمتطلبات المعتمدة والتهيئة الفعلية كما نفّذها الفريق (as-built) المتطورة طوال دورة الحياة. ECSS

ولهذا السبب تحديداً يصبح الفصل التقليدي بين الإدارات مشكلة.

لا يمكن للهندسة أن تُنهي عملها ثم “تلقي بقائمة BoM من فوق الجدار” إلى الإنتاج ببساطة.

ولا يمكن للإنتاج أن يصنّع دون فهم المعالم الرئيسية للمشروع.

كذلك لا يمكن للمشتريات أن تشتري بناءً على طلب المخزون وحده.

وبالمثل، لا يمكن للجودة أن تعمل بمعزل عن التهيئة.

وأخيراً، لا يمكن للإدارة المالية أن تفهم الأداء الحقيقي للمشروع إذا كانت تكاليف التصنيع منفصلة عن مُخرَج المشروع الذي تسبّب فيها.

الترجمة المفقودة: BoQ ← BoM

هذه هي المشكلة المعمارية التي تستحق مزيداً من الاهتمام.

على سبيل المثال، تخيّل أن BoQ لمشروع ما يتضمن متطلباً لمجموعة هندسية مُجمَّعة.

من منظور المشروع، قد تظهر تلك المجموعة على أنها مادة أو منتج واحد مطلوب لإنجاز نطاق تصميمي واحد في BoQ.

لكن داخلياً، لا تكون تلك “المادة” بالضرورة شيئاً تشتريه الشركة من كتالوج.

فقد تكون هي نفسها منتجاً مصنَّعاً وفق نهج قائم على المشاريع.

نتيجة لذلك، يتفرّع ذلك المنتج إلى قائمة BoM خاصة به تتكون من مواد خام متعددة ومكونات مشتراة ومواد استهلاكية وعناصر نصف مصنَّعة.

• ويتطلب أيضاً عمالة.
• ويستهلك الآلات والأدوات والطاقة الإنتاجية.
• ويمر بعمليات التصنيع.
• ويجتاز الفحوصات وبوابات الجودة.

من جهة، قد ينفّذ المصنّع بعض العمليات داخلياً.

من جهة أخرى، قد يسند بعضها الآخر إلى موردين أو مقاولين من الباطن متخصصين.

وعند الانتهاء، يعود ناتج التصنيع ليتجمّع في منتج واحد قابل للتعريف. ثم يستهلكه نطاق المشروع الأم أثناء التجميع أو الإنشاء أو التكامل أو التركيب.

هذا هو التصنيع المتداخل داخل المشروع.

يدعم ProjectVIEW بالفعل المنطق الأساسي لذلك من خلال تصنيع BoQ-to-BoM ومراحل الإنتاج وتخصيص الموارد، ومن خلال وحدة إدارة المواد والإنتاج المخصصة. ويمكن أن تكون مراحل الإنتاج متتابعة أو متوازية، وأن تميّز بين المدخلات والمنتجات نصف المصنَّعة والمخرجات. كما يمكنها أن تخصّص العمالة والآلات، وأن تشمل المقاولين من الباطن، وأن تحسب التكلفة النهائية لوحدة الإنتاج، وأن تقارن الموارد والتكاليف المخططة بالفعلية. Danaos Projects

ويُنشئ ذلك علاقة أغنى بكثير من:

المنتج ← BoM

فتصبح:

نطاق BoQ ← نشاط WBS ← المنتج المصنَّع ← BoM + مسار التصنيع + الموارد + الجودة ← المنتج النهائي ← BoQ الأم

وبالتالي تظل كل طبقة منسوبة اقتصادياً إلى المشروع نفسه.

المنتج المصنَّع هو أيضاً مورد من موارد المشروع

هذا المفهوم بالغ الأهمية.

يمكن للمجموعة المصنَّعة أن تكون في الوقت نفسه:

على سبيل المثال، لنأخذ وحدة دعم هندسية مصنَّعة لبرنامج دفاعي.

على مستوى المشروع، قد تكون مادة/مورداً مطلوباً لحزمة عمل محددة في BoQ.

أما داخلياً، فيمكن لـ ProjectVIEW تفكيك ذلك المنتج إلى قائمة BoM للتصنيع.

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

وبمجرد اكتمالها وقبولها، يعيد الفريق المجموعة النهائية إلى المشروع الأم بوصفها مورداً خاضعاً للرقابة وقابلاً للتعريف وجاهزاً للتركيب.

والأهم من ذلك أن تكلفتها لم تختفِ في حساب عام للتكاليف غير المباشرة للمصنع.

فساعات العمل ووقت الآلات والمواد والعمليات المتعاقد عليها من الباطن وتقدم الإنتاج تظل جميعها منسوبة إلى متطلب المشروع الذي أوجدها.

هذا هو التحكم في تكاليف المشروع الذي يصل إلى داخل عملية التصنيع.

مثال من قطاع الدفاع: متطلب واحد في BoQ، ومشروع إنتاج كامل تحته

على سبيل المثال، لنفترض مقاولاً دفاعياً ينفّذ منشأة متكاملة لدعم المهام.

قد يتطلب بند واحد من النطاق التعاقدي حاوية معدات هندسية أو وحدة إنشائية.

لذلك، من منظور المشروع الأم، تريد الإدارة أن تعرف:

• هل هي جاهزة؟
• متى سيتم تركيبها؟
• كم كانت تكلفتها؟
• هل اجتازت الفحص؟
• هل تستخدم التهيئة المعتمدة؟

ومع ذلك، تحت ذلك البند الذي يبدو بسيطاً يكمن مشروع مصغّر.

• تُصدر الهندسة الرسومات والمواصفات.
• يُنشئ النظام قائمة BoM ومسار التصنيع المعنيين أو يربطهما.
• تؤمّن المشتريات المكونات المطلوبة.
• يخصّص الإنتاج طاقة الورشة والعمالة والآلات.
• كما يمكن للمصنّع إسناد عمليات متخصصة مختارة إلى جهات خارجية.
• تسجّل الجودة الفحوصات وحالات عدم المطابقة والموافقات.
• تخضع تغييرات التهيئة للتحكم في الإصدارات.

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

بل تصبح بدلاً من ذلك زوايا نظر مختلفة إلى واقع المشروع الواحد.

تطبّق DANAOS اليوم منطق تصنيع مماثلاً في بيئات المشاريع المعقدة مثل بناء السفن وعمليات أحواض بناء السفن، حيث تتشابك بالفعل أعمال التصنيع والمواد والعمالة والمقاولون من الباطن ومعلومات التصميم والإنتاج والتكلفة. Danaos Projects

مثال من قطاع الفضاء: لا يمكن فصل التصنيع عن التهيئة والجودة

لنتأمل الآن هيكل دعم أرضي متخصصاً أو إطار تكامل ينتجه المصنّع لبرنامج فضائي.

قد تحتوي قائمة BoM الخاصة به على عناصر قياسية ومكونات مصنَّعة خصيصاً وقطع دقيقة يوفرها موردون متخصصون.

• أولاً، يجري جزء من الإنتاج في ورشة المصنّع.
• ثم قد يسند المصنّع عملية أخرى إلى جهة خارجية.
• بعد ذلك، قد يجري التجميع النهائي في منشأة مختلفة.
• وقد يتطلب القبول سجلات فحص وشهادات ورسومات معتمدة وتهيئة فعلية (as-built) دقيقة.

ولهذا السبب لا يمكن أن تكون الجودة مجرد وحدة أخرى في نظام ERP تقف إلى جانب التصنيع.

بعبارة أخرى، الجودة جزء من حالة الإنتاج.

وتجعل معايير الفضاء الأوروبية هذه العلاقة صريحة: إذ تحتفظ ECSS بمتطلبات مخصصة لـ ضمان منتجات الفضاء وضمان الجودة لمشاريع الفضاء وإدارة التهيئة/المعلومات. ECSS

لا يمكن الإبلاغ بصدق عن أن عنصراً مصنَّعاً “مكتمل” لمجرد أن عمليات التصنيع بلغت 100%.

• فقد يكون مصنَّعاً مادياً لكنه لم يُفحص.
• أو مفحوصاً لكنه خاضع لحالة عدم مطابقة.
• أو مقبولاً لكنه لم يُفرج عنه.
• أو مُفرجاً عنه لكنه لم يُنقل.
• أو مُسلَّماً لكنه لم يُدمج.
• أو مدمجاً لكنه بانتظار التحقق النهائي.

في المقابل، لكل حالة معنى مختلف بالنسبة إلى الإنتاج والجودة والتخطيط والإدارة التجارية والعميل.

لذلك يجب على أي نظام ERP جادّ أن يفهم هذه الفروق.

في قطاعي الدفاع والفضاء، لا تكفي المعلومات الآنية. يجب أن تكون معلومات عالية الموثوقية.

في الواقع، ربما يكون هذا هو الفارق الأهم.

على سبيل المثال، كثيراً ما يطلب التنفيذيون “لوحات معلومات آنية”.

لكن السرعة من دون موثوقية أمر خطير.

إذا أبلغ فريق الإنتاج مدير برنامج بأن مجموعة ما مكتملة بنسبة 82%، فماذا تعني نسبة 82% بالضبط؟

• الساعات المستهلكة؟
• العمليات المنجزة؟
• الكميات المادية المنتَجة؟
• بنود BoM المكتملة؟
• المخرجات المعتمدة من الجودة؟
• القيمة المكتسبة؟
• الإبلاغ الذاتي من أرضية المصنع؟

لذا ينبغي أن يكون الهدف هو تقدماً آنياً عالي الموثوقية.

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

تدعو استراتيجية الهندسة الرقمية (Digital Engineering Strategy) الأمريكية إلى مصادر موثوقة لبيانات النظام ونماذجه تشمل التخصصات ودورة الحياة. وهي تربط صراحةً بين هذا المصدر الموثوق للحقيقة وإدارة التكلفة والجدول الزمني والأداء والمخاطر، مع التأكيد على أن أصحاب المصلحة يحتاجون إلى المعلومات الصحيحة في الوقت المناسب. Assistant Secretary of War

كذلك ينطبق هذا المبدأ مباشرةً على نظام ERP القائم على المشاريع.

لا ينبغي الاكتفاء بالإبلاغ عن التقدم. بل ينبغي إثباته.

أين يُحدث الذكاء الاصطناعي تغييراً في تصنيع مشاريع الدفاع والفضاء؟

يوفّر ProjectVIEW ERP طبقة العمليات والبيانات المنظَّمة. وتصف DANAOS كلاً من ProjectVIEW OS وProjectVIEW AI بأنهما طبقة ذكاء تعمل فوق معلومات BoQ وWBS والتكلفة والعمليات المنظَّمة، مع مجالات معلنة تشمل التنبؤ بانحرافات التكلفة، وتوقّع التأخير والإنتاجية، وتقييم المخاطر، وذكاء المشتريات، واكتشاف الحالات الشاذة، وسير العمل المدعوم بالذكاء الاصطناعي. Danaos Projects

ما حالات استخدام الذكاء الاصطناعي في تصنيع الدفاع والفضاء؟

وبالنسبة إلى التصنيع في قطاعي الدفاع والفضاء، يفتح ذلك عدة حالات استخدام بالغة القيمة:

1. تقدّم يتحقق منه الذكاء الاصطناعي. على سبيل المثال، يمكن لوكيل ذكاء اصطناعي مقارنة تقدم الإنتاج المُعلن بمدى اكتمال BoM والمواد المستهلكة ومعاملات العمالة. كما يمكنه مقارنته بنشاط الآلات وحالة المقاولين من الباطن وبوابات الجودة المجتازة. وبدلاً من مجرد تكرار عبارة “مكتمل بنسبة 75%”، يمكنه التنبيه إلى أن 61% فقط من الأدلة تدعم الحالة المُبلَّغ عنها وتحديد ما هو ناقص.
2. التنبؤ بمخاطر الجدول الزمني والإنتاج بالذكاء الاصطناعي. إذا تأخر مكوّن متخصص، وتعذّر توفر إحدى الآلات، وتغيّر موعد فحص إلزامي، يمكن للذكاء الاصطناعي تقييم أثرها المجتمع على مسار الإنتاج ونشاط WBS والمعلم النهائي للمشروع، بدلاً من تحليل كل مشكلة على حدة.
3. ذكاء الجودة والتهيئة بالذكاء الاصطناعي. يمكن لذكاء المستندات تحديد سجلات الفحص المفقودة، ومراجعات الرسومات غير المتسقة، والشهادات غير المكتملة، والأنماط المتكررة لعدم المطابقة، أو المعاملات المنفَّذة استناداً إلى معلومات ملغاة. والهدف ليس استبدال الحكم الهندسي، بل إظهار التناقضات قبل أن تنتشر إلى المراحل اللاحقة.
4. ذكاء المشتريات وقرارات التصنيع أو الشراء بالذكاء الاصطناعي. نظراً لإمكانية إنتاج المنتج المصنَّع داخلياً أو إسناده إلى جهة خارجية، يمكن للذكاء الاصطناعي مقارنة الطاقة الداخلية وتوافر الآلات والإنتاجية التاريخية. كذلك يمكنه مقارنة مُهل التوريد لدى الموردين، والتزامات المشتريات، والتكلفة المتوقعة، قبل أن تقرر الإدارة ما إذا كانت ستصنّع أو تتعاقد من الباطن أو تشتري.
5. إحاطات تنفيذية وإحاطات لأصحاب المصلحة بالذكاء الاصطناعي. يمكن لصاحب مصلحة مخوَّل أن يسأل: ما الحالة المعتمدة الحالية للحزمة X، وما الذي يعيق إكمالها، وما أحدث تكلفة متوقعة لها، وما الأدلة التي تدعم هذا التقييم؟ ويمكن توليد إجابة الذكاء الاصطناعي من معاملات ERP المنظَّمة والأدلة المرتبطة بها، بدلاً من رسائل البريد الإلكتروني وجداول البيانات المجمَّعة يدوياً.

باختصار، الكلمة المحورية في كل ذلك هي الأدلة.

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

السرية تغيّر الطريقة التي يجب أن يعمل بها التعاون

تفرض برامج الدفاع والفضاء متطلباً آخر: ليس على كل صاحب مصلحة أن يرى كل شيء.

• الرؤية الآنية لا تعني رؤية غير مقيدة.
• قد تحتاج قيادة البرنامج إلى الاطلاع على وضع التكلفة والجدول الزمني.
• تحتاج إدارة الإنتاج إلى حالة تصنيع تفصيلية.
• تحتاج فرق الجودة إلى معلومات الفحص وحالات عدم المطابقة.
• قد يحتاج المقاولون المتخصصون إلى حزمة العمل المسندة إليهم فقط.
• قد يحتاج العملاء إلى حالة المعالم المعتمدة دون الوصول إلى المعلومات التجارية الداخلية أو معلومات الموردين.

ولذلك فإن البنية الصحيحة هي:

مصدر واحد للحقيقة، وعروض متعددة مخوَّلة.

في البيئات الأمريكية التي تتعامل مع المعلومات غير المصنفة الخاضعة للرقابة (CUI)، يوفّر معيار NIST SP 800-171 Rev.3 مرجعاً مهماً: فهو يتناول حماية CUI في الأنظمة غير الفيدرالية، ويشمل التحكم في الوصول، ومبدأ الحد الأدنى من الصلاحيات، وقابلية التدقيق، وسلامة النظام، وحماية المعلومات أثناء النقل وأثناء التخزين. ويشترط تحديداً قصر وصول المستخدمين والعمليات على ما يلزم لمهامهم المسندة والاحتفاظ بسجلات تدقيق مفصلة. NIST Publications

هذا لا يعني أن استخدام نظام ERP يحقق تلقائياً الامتثال لمعايير NIST أو ECSS أو قواعد مراقبة الصادرات أو عقد دفاعي بعينه. إذ يجب دائماً التحقق من الامتثال وفقاً للبرنامج المحدد والولاية القضائية وتصنيف البيانات والالتزامات التعاقدية.

ومع ذلك، فإنه يحدد الاتجاه المعماري الصحيح.

بعبارة أخرى، ينبغي توزيع معلومات المشروع وفقاً لـ الهوية والدور والمسؤولية ومبدأ الحاجة إلى المعرفة.

لذلك من الأفضل أن تقتصر الإشعارات الموجهة إلى أصحاب المصلحة الحساسين على الإعلان عن وقوع حدث مهم وإتاحة وصول موثَّق إلى السجل المرجعي. في المقابل، لا ينبغي أن توزّع دون داعٍ معلومات تقنية أو تجارية سرية عبر قنوات غير خاضعة للرقابة.

تدعم بيئة CDE المتكاملة في ProjectVIEW بالفعل إدارة إصدارات المستندات والموافقات والسجل التاريخي ومسارات التدقيق، بينما تربط بيئة التصنيع فيه نشاط الإنتاج ببنية المشروع الأصلية. قدرات التحكم في المستندات وCDE في ProjectVIEW Danaos Projects

من الخيط الرقمي إلى الخيط الاقتصادي

يدرك قطاعا الدفاع والفضاء بالفعل مفهوم الخيط الرقمي (digital thread).

ويصفه مزوّدو التكنولوجيا في القطاع بأنه الربط المستمر بين معلومات الهندسة والتصنيع والإنتاج ودورة الحياة. فعلى سبيل المثال، تضع Siemens الخيط الرقمي في قطاع الطيران والفضاء والدفاع في إطار إدارة البرامج والهندسة وسلسلة التوريد والإنتاج ودعم المنتج. Siemens Resources

لكن هناك خيطاً آخر لا يقل أهمية:

الخيط الاقتصادي.

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

ويعيد منطق ProjectVIEW القائم على المشاريع ربط هذا الواقع المادي والهندسي بـ BoQ وWBS وCost Codes.

وبالتالي فإن الخيط الرقمي لا ينتهي عند الهندسة أو أرضية المصنع.

بل يمتد إلى الميزانية والالتزامات والتكلفة الفعلية والقيمة المكتسبة وتقدم المشروع والأداء المالي.

لماذا لا يكفي نظام ERP التقليدي للتصنيع؟

قد يكون نظام ERP التقليدي للتصنيع جيداً جداً في الإجابة عن السؤال:

ما الذي يتطلبه تصنيع المنتج A؟

أما تصنيع مشاريع الدفاع والفضاء فيتطلب سؤالاً أوسع:

لماذا نصنّع المنتج A، ولأي متطلب تعاقدي، ومقابل أي معلم في الجدول الزمني، وباستخدام أي موارد، وبأي تهيئة، وبأي تكلفة، وبأي حالة جودة، وكيف يؤثر إنجازه على البرنامج الأم؟

في الواقع، يتجاوز هذا السؤال حدود الهندسة وضوابط المشاريع والمشتريات والإنتاج والجودة والتعاقد من الباطن والخدمات اللوجستية والمالية.

لذلك لا يمكن الإجابة عنه بموثوقية عندما تعمل هذه الوظائف في أنظمة غير مترابطة.

ولا يمكن للذكاء الاصطناعي الإجابة عنه إذا لم تكن لديه هو نفسه حقيقة تشغيلية منظَّمة يستند إليها.

وهنا تكمن أهمية نموذج ProjectVIEW لتصنيع المشاريع BoQ-to-BoM.

تشرح BoM كيف يبني المصنّع المنتج. وتشرح WBS متى يجب أن يبنيه. ويشرح BoQ لماذا يحتاجه المشروع وأين تكمن قيمته الاقتصادية. وتشرح رموز التكلفة (Cost Codes) ما يكلّفه تنفيذه للمؤسسة. وتثبت سجلات الجودة والتهيئة ما إذا كان الناتج مقبولاً فعلاً.

باختصار، يربط التصنيع القائم على المشاريع بين هذه العناصر الخمسة جميعها.

وعندئذٍ يستطيع الذكاء الاصطناعي تفسير النسيج الرقمي الناتج.

ينبغي أن يصبح نظام ERP لتصنيع الدفاع والفضاء نظام قيادة، لا قاعدة بيانات

بالنسبة إلى برامج الدفاع والفضاء المعقدة، ليس الهدف نظام سجلات آخر.

بل هو بيئة قيادة خاضعة للرقابة لتصنيع المشاريع.

أي بيئة قادرة على تتبّع المتطلب من النطاق التعاقدي إلى التعريف الهندسي، ومن BoQ إلى BoM، ومن المشتريات إلى التصنيع. كما تتتبّعه من الورشة الداخلية إلى المقاول المتخصص الخارجي؛ ومن الإنتاج إلى الفحص؛ ومن المكوّن النهائي إلى التجميع والإنشاء؛ ومن التنفيذ المادي عودةً إلى الوقت والتكلفة والجودة وأداء البرنامج.

في هذه البيئات، قد يكون العنصر المصنَّع منتجاً اليوم، ومورداً للمشروع غداً، وجزءاً من نظام أكبر بكثير بعد التركيب.

لذلك يجب على نظام المعلومات أن يفهم الحالات الثلاث جميعها.

هذا هو التصنيع القائم على المشاريع.

وهذا بالضبط نوع التعقيد الذي صمّمت DANAOS Projects من أجله نظام ERP متكامل يتمحور حول المشاريع مثل DANAOS ProjectVIEW ERP.

الأسئلة الشائعة: التصنيع القائم على المشاريع في قطاعي الدفاع والفضاء

ما الفرق بين BoQ وBoM؟

يمثّل BoQ نطاق المشروع أو العقد وكمياته، بينما تصف BoM المكونات المطلوبة لتصنيع منتج ما. وفي التصنيع القائم على المشاريع، تتمثل القدرة المهمة في الحفاظ على العلاقة بينهما بحيث تظل المنتجات المصنَّعة مرتبطة بمتطلب المشروع ونشاط WBS والميزانية وهيكل التكلفة التي أوجدت الطلب.

ماذا يعني BoQ-to-BoM؟

يعني BoQ-to-BoM أخذ أحد مُخرَجات المشروع أو عنصر مصنَّع معرَّف ضمن البنية التجارية/بنية المشروع وتفريعه إلى المواد والمكونات والعمليات والموارد اللازمة لتصنيعه. وبعد الانتهاء، يعود المنتج المصنَّع إلى المشروع الأم بوصفه مورداً خاضعاً للرقابة لأغراض التجميع أو الإنشاء أو التركيب.

لماذا يُعد التصنيع القائم على المشاريع مهماً لقطاعي الدفاع والفضاء؟

لأن كثيراً من مُخرَجات الدفاع والفضاء تُصمَّم هندسياً لبرنامج أو تهيئة أو مهمة محددة، بدلاً من إنتاجها حصراً كمخزون متكرر. ولذلك فهي تتطلب تحكماً متزامناً في الهندسة والتصنيع والجدول الزمني للمشروع والجودة والمشتريات والتعاقد من الباطن والتكلفة.

كيف يمكن للذكاء الاصطناعي تحسين نظام ERP لتصنيع الدفاع والفضاء؟

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

لماذا تُعد الرؤية الآمنة لأصحاب المصلحة مهمة؟

لأن البرامج الحساسة تتطلب في آنٍ واحد تدفقاً سريعاً للمعلومات وتحكماً صارماً فيها. والهدف ليس كشف جميع معلومات المشروع للجميع، بل تزويد كل صاحب مصلحة مخوَّل بـ المعلومات الصحيحة الموثَّقة، في الوقت المناسب، وللغرض المناسب.

Read more: نظام ERP لتصنيع الدفاع والفضاء: لماذا يبدأ التصنيع القائم على المشاريع من BoQ-to-BoM

«المشروع مكتمل بنسبة 50%.»

تبدو العبارة دقيقة.

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

في الواقع، لا توجد في التشييد نسبة عالمية موحدة تسمى ببساطة «نسبة الإنجاز».

50% وفقًا لمن؟

• مخطِّط الجداول الزمنية؟
• مهندس الموقع؟
• مسّاح الكميات؟
• مقاول الباطن؟
• مراقب التكاليف؟
• الاستشاري؟
• الإدارة المالية؟
• العميل؟

لأن المشروع الواحد قد يكون في الوقت نفسه:

في الواقع، قد تكون جميع هذه الأرقام صحيحة.

إنها ببساطة تقيس حقائق مختلفة.

ولهذا تحديدًا لا يجوز الخلط بين إعداد تقارير التقدم وإدارة التشييد.

فالسؤال الحقيقي ليس فقط:

بل هو:

عند هذه النقطة تحديدًا يتحول قياس التقدم إلى التحكم في التكاليف.

وفي الوقت نفسه، تكتسب القيمة المكتسبة (Earned Value) معناها الحقيقي.

ماذا تعني عبارة «مكتمل بنسبة 50%» فعلًا؟

حتى Oracle Primavera P6 يميّز بين مقاييس إنجاز مختلفة، منها Duration Percent Complete وUnits Percent Complete وPhysical Percent Complete وPerformance Percent Complete. ويُستخدم Performance Percent Complete بعد ذلك في حسابات القيمة المكتسبة. تعريفات الأنشطة ونسب الإنجاز في Oracle Primavera P6

هذا التمييز جوهري.

على سبيل المثال، قد يُظهر برنامج الجدولة بشكل مشروع أن نشاطًا ما مكتمل بنسبة 50% وفق منهجية التقدم المختارة.

لكن ذلك لا يثبت تلقائيًا:

• أن 50% من الكمية المتعاقد عليها قد نُفِّذت؛
• أن 50% من الموارد المطلوبة قد استُهلكت؛
• أن 50% من الميزانية قد اكتُسبت؛
• أن العمل يُنتج بالمعدل المخطط؛
• أو أن المشروع سليم اقتصاديًا.

الوقت ليس كمية.

الكمية ليست تكلفة.

التكلفة ليست تقدمًا.

تبدأ إدارة التشييد عندما تُربط هذه الأبعاد ببعضها.

يجب تسجيل التقدم حيث يحدث فعلًا: في الموقع

أولًا، ينشأ التقدم الفعلي في التشييد من التنفيذ.

بعبارة أخرى، إنه يحدث في موقع البناء، أو ساحة التصنيع، أو حوض بناء السفن، أو الورشة، أو المنجم، أو المنشأة البحرية، أو أينما يُنفَّذ العمل المادي.

لذلك ينبغي تسجيل التقدم مقابل النطاق الفعلي للعمل.

لذلك، وبحسب طبيعة النشاط، يمكن تسجيله على النحو التالي:

• كمية فعلية منجزة مقابل بند في BoQ؛
• نسبة إنجاز مقابل نشاط في WBS؛
• إنتاج قابل للقياس مقابل كلٍّ من BoQ وWBS المرتبط به؛
• أو منهجية إنجاز مرجّحة محددة مسبقًا حيث لا تكفي الكميات وحدها.

الأمثلة واضحة:

• تركيب 500 م من خط أنابيب طوله 1,000 م = تقدم كمّي مادي بنسبة 50%
• صب 600 م³ من أصل 1,000 م³ من الخرسانة = 60%
• تركيب 250 طنًا من أصل 500 طن من الهياكل الفولاذية = 50%
• تركيب واستلام 25 وحدة من أصل 50 وحدة معدات = 50%

أما الأعمال التي لا يمكن قياسها منطقيًا ككمية متصلة، فيمكن لمراحل تقدم محددة مسبقًا أو قواعد الاستحقاق (Rules of Credit) أن تحدد كيفية احتساب الإنجاز.

على سبيل المثال، تصف InEight قواعد الاستحقاق بأنها طريقة لنسب التقدم إلى مراحل قابلة للقياس، بحيث تعكس تقارير التقدم إنجازًا مُتحققًا منه لا تقديرًا شخصيًا. InEight — قواعد الاستحقاق أساس لميزانيات تشييد موثوقة

وهذا يرسي المبدأ الأول:

لكن حتى التقدم المادي الدقيق ليس سوى نصف المعادلة.

السؤال الغائب: ما الذي تطلّبه تحقيق هذا التقدم؟

على سبيل المثال، لنفترض أن نشاط خط أنابيب يتضمن:

كمية BoQ: 1,000 متر الكمية المركّبة فعليًا: 500 متر

يُبلغ الموقع بشكل صحيح:

مكتمل بنسبة 50%.

لكن الإدارة تحتاج الآن إلى معرفة أمر أهم بكثير.

ومع ذلك، ما الذي استهلكناه لإنتاج هذه الأمتار الـ500؟

كم من:

• ساعات العمالة؛
• ساعات تشغيل المعدات؛
• المواد؛
• موارد مقاولي الباطن؛
• المواد الاستهلاكية؛
• الموارد غير المباشرة؛

كانت مطلوبة؟

ثم كيف يقارن ذلك بما أدرجناه في الميزانية أصلًا؟

مثال بسيط يكشف المشكلة

تخيّل أن فريق التخطيط بنى ميزانية 1,000 متر من خط الأنابيب على:

800 ساعة عمل

80 ساعة تشغيل معدات

1,000 متر من الأنابيب

إضافة إلى تكاليف مقاولي الباطن والتكاليف غير المباشرة المرتبطة بها.

لذلك، عند إنجاز مادي بنسبة 50% تمامًا، تشير افتراضات التخطيط التناسبية إلى أنه كان ينبغي استهلاك ما يقارب:

400 ساعة عمل

40 ساعة تشغيل معدات

500 متر من المواد

وذلك بالطبع مع مراعاة التوزيع الفعلي للموارد وملف الإنتاج بطبيعة الحال.

لكن معاملات الموقع تكشف أن:

560 ساعة عمل

55 ساعة تشغيل معدات

540 مترًا من المواد

قد استُهلكت فعليًا.

• المشروع بالفعل مكتمل ماديًا بنسبة 50%.
• لكن أداء موارده ليس 50%.
• فقد استهلكت العمالة بالفعل 70% من ساعات العمل المخططة.
• واستهلكت المعدات قرابة 69% من ساعات التشغيل المخططة.
• ويبلغ استهلاك المواد 54%.

لكن الموارد اللازمة لتحقيق هذا التقدم تنحرف عن افتراضات الميزانية.

نتيجة لذلك، عند هذا الانحراف تبدأ مشكلة الإدارة الحقيقية.

الكمية + الوقت + التكلفة: اختبار الواقع في التشييد

لذلك فإن العلاقة الأساسية في التشييد ليست مجرد:

التقدم المخطط مقابل التقدم الفعلي

بل هي:

بعبارة أخرى، كل بُعد منها يختبر الأبعاد الأخرى.

الكمية تجيب عن:

ما الذي بنيناه فعلًا؟

الوقت يجيب عن:

بأي سرعة ننتجه (الإنتاج المدفوع بالجهد)؟

الموارد تجيب عن:

ما الذي استهلكناه لإنتاجه؟

التكلفة تجيب عن:

كم كلّفنا استهلاك هذه الموارد؟

لذلك يتطلب العمل السليم أن تظل هذه الأبعاد متوافقة إلى حد معقول مع الافتراضات الواردة في ميزانية المشروع وجدوله الزمني.

هذا هو اختبار الواقع.

معدل الإنتاج لا يقل أهمية عن التقدم

لنفترض أن ميزانيتنا الأصلية افترضت:

• 1,000 متر من العمل باستخدام 800 ساعة عمل.

وبالتالي فإن الإنتاجية المدرجة في الميزانية هي:

• 1.25 متر لكل ساعة عمل.

لكن بعد إنجاز 500 متر، استُهلكت 560 ساعة عمل.

الإنتاجية الفعلية الآن هي:

• 0.89 متر لكل ساعة عمل.
• لا يزال التقدم المادي مُبلَّغًا عنه بدقة عند 50%.

لكن إنتاجية العمالة تراجعت بشكل كبير مقارنة بافتراض الميزانية.

لوحة متابعة تقدم تُظهر ببساطة:

لا يمكنها كشف ذلك.

النسبة صحيحة.

لكن الاستنتاج الإداري خاطئ لأن النسبة موجودة دون سياق تشغيلي.

ولهذا يجب احتساب إنتاجية العمالة الفعلية بربط استهلاك الموارد بالعمل المنتَج فعليًا.

هذا ما تحاول القيمة المكتسبة أن تُخبر به الإدارة

أما على مستوى ضبط المشروع، فيُضفي تحليل القيمة المكتسبة طابعًا منهجيًا على هذه العلاقة من خلال مقارنة ثلاثة أبعاد أساسية:

• القيمة المخططة (PV): ما مقدار القيمة التي كان يجب إنجازها حتى الآن؟
• القيمة المكتسبة (EV): ما القيمة المدرجة في الميزانية للعمل المنجز فعليًا؟
• التكلفة الفعلية (AC): كم كلّف العمل المنجز فعليًا؟

على سبيل المثال، لنفترض أن حزمة عمل خط الأنابيب لدينا تبلغ ميزانيتها عند الإنجاز $100,000.

في تاريخ التقرير:

التقدم المخطط = 60%

وبالتالي:

PV = $60,000

لكن التقدم المادي المُتحقق منه لا يتجاوز:

50%

وبالتالي:

EV = $50,000

وقد ولّدت الموارد المستهلكة فعليًا:

AC = $65,000

لذلك فإن المشروع متأخر عن الخطة وينفق بشكل غير متناسب مقارنة بالقيمة التي اكتسبها.

مؤشر أداء الجدول الزمني (SPI) هو:

SPI = EV / PV = 0.83

مؤشر أداء التكلفة (CPI) هو:

CPI = EV / AC = 0.77

كذلك تصف تعريفات واجهة برمجة التطبيقات الحالية في Oracle Primavera القيمة المكتسبة بأنها الميزانية الأساسية مضروبة في Performance Percent Complete، ومؤشر SPI بأنه القيمة المكتسبة مقسومة على القيمة المخططة. تعريفات القيمة المكتسبة وأداء الجدول الزمني في Oracle Primavera P6

لهذا السبب تتمتع القيمة المكتسبة بهذه القوة.

فهي لا تسأل ببساطة:

بل تسأل:

بعبارة أخرى، هذا في جوهره سؤال من صميم إدارة التشييد.

يجب أن تبقى القيمة المكتسبة مستندة إلى واقع التشييد الفعلي

لا تكون القيمة المكتسبة موثوقة إلا بقدر موثوقية قياس التقدم الذي يغذيها.

إذا كتب أحدهم ببساطة:

مكتمل بنسبة 50%

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

هذا تمييز مهم.

لذلك يجب أن يعرف النظام ما الذي يُشكّل التقدم المكتسب.

وقد يأتي ذلك من:

• الكميات المركّبة؛
• كميات BoQ المنجزة؛
• تقدم WBS المُتحقق منه؛
• الخطوات المرجّحة؛
• قواعد الاستحقاق؛
• مخرجات الإنتاج المقبولة؛
• الأعمال المفحوصة؛
• أو أي طريقة قياس أخرى محددة بموضوعية.

والهدف دائمًا واحد:

لا التفاؤل.

لا الإنفاق.

ولا مجرد الوقت المنقضي.

لماذا لا يكفي التقدم المعتمد على WBS وحده؟

لا غنى عن WBS.

فهو ينظّم:

• الأنشطة؛
• التسلسل؛
• الاعتماديات؛
• المراحل الرئيسية؛
• المدة؛
• زمن المشروع.

لكن WBS لا يستطيع بمفرده تمثيل الواقع الاقتصادي الكامل للتشييد.

خذ هذا النشاط مثالًا:

تركيب أنابيب المياه المبرّدة — المستوى 3

قد يعرف الجدول الزمني:

• تاريخ البدء؛
• تاريخ الانتهاء؛
• المدة؛
• المنطق؛
• تخصيص الموارد؛
• نسبة الإنجاز.

لكن الضبط التجاري والتشغيلي يحتاج إلى ما هو أكثر بكثير.

• ما كمية الأنابيب الموجودة ضمن هذا النشاط؟
• أي بنود BoQ؟
• أي أقطار؟
• ما المواد؟
• أي تخصصات عمالية؟
• ما المعدات؟
• أي مقاول باطن؟
• ما الميزانية؟
• ما التكلفة؟
• ما الذي تم شراؤه؟
• ما الذي وصل؟
• ما الذي استُهلك؟
• ما الذي تم فحصه؟
• ما الذي تم اعتماده؟
• ما الذي تم دفعه؟

يمثّل نشاط WBS الهيكل الزمني للتنفيذ.

ومع ذلك، لا يمثّل تلقائيًا الهيكل التجاري والمالي الكامل للمشروع.

لهذا السبب يعتمد ProjectVIEW ERP على العلاقة:

• يحدد BoQ النطاق القابل للقياس والنطاق التجاري.
• ويحدد WBS التنفيذ والزمن.
• كما تحدد رموز التكلفة (Cost Codes) التصنيف الاقتصادي لاستهلاك الموارد في المؤسسة.

ثم يربط ProjectVIEW معاملات المشروع الفعلية بهذه الهياكل.

تحديث تقدم WBS هو تقرير، وليس بعدُ تحكمًا في التكاليف.

لذلك يجب أن يكون هذا التمييز صريحًا.

عندما يحدّث أحدهم نشاطًا من:

40% → 50%

تكون المؤسسة قد سجّلت تقدمًا.

هل هو مفيد؟ بالتأكيد.

هل هو ضروري؟ نعم.

هل هو إدارة تشييد؟ ليس بعد.

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

إذا تطلّب تقدم إضافي بنسبة 10%:

• 10% من العمالة المتوقعة،
• 10% من المعدات المتوقعة،
• 10% من المواد المتوقعة،

وقرابة الوقت المتوقع،

فقد يكون العمل يسير على نحو جيد إذن.

لكن إذا تطلّب التقدم الإضافي نفسه بنسبة 10%:

• 22% عمالة إضافية،
• 18% تكلفة معدات إضافية،
• 15% استهلاكًا زائدًا للمواد،

وضعف المدة المتوقعة،

فإن الإدارة تكون قد اكتشفت عندئذٍ مشكلة أداء خطيرة.

• الجدول الزمني وحده لا يفسرها.
• ونسبة التقدم وحدها لا تفسرها.
• كما أن دفتر الأستاذ المحاسبي وحده لا يفسرها.

وحدها العلاقة بين العمل المنجز والموارد المستهلكة تفسرها.

هذا هو الفرق بين إعداد التقارير وإدارة التشييد

يمكن لنظام الجدولة أن يُخبر الإدارة:

أما نظام إدارة التشييد والتحكم في التكاليف فيجب أن يجيب:

باختصار، هذا مستوى مختلف جذريًا من الضبط.

النسبة المئوية المنفردة هي إعداد تقارير.

أما كمية العمل المنجز المطابَقة مع الوقت والموارد والتكلفة فهي إدارة التشييد.

ساعات العمل لا تساوي التقدم

لنأخذ مشروعين.

كلاهما يُبلغ عن:

• تقدم مادي بنسبة 50%.

استهلك المشروع A:

• 48% من ساعات العمل المدرجة في ميزانيته.

واستهلك المشروع B:

• 72%.

هل ينبغي للإدارة أن تعتبرهما متساويين في السلامة لأن كليهما مكتمل بنسبة 50%؟

بالطبع لا.

في المقابل، المشروع A يسير عمومًا وفق إنتاجية العمالة المخططة.

أما المشروع B فيحوّل قدرًا أكبر بكثير من العمالة إلى المخرَج المادي نفسه.

وقد ينشأ الفرق عن:

• ظروف موقع سيئة؛
• منحنى التعلم؛
• الازدحام؛
• إعادة العمل؛
• ضعف الإشراف؛
• عدم كفاية توافر المواد؛
• تغييرات التصميم؛
• قيود الوصول؛
• العمل الإضافي؛
• تشكيل غير مناسب لفرق العمل؛
• أو افتراضات تقدير غير صحيحة.

أيًّا كان السبب، لا تظهر المشكلة إلا عندما يتشارك استهلاك العمالة والإنجاز المادي المرجع نفسه في المشروع.

لهذا السبب يتعامل ProjectVIEW مع إنتاجية العمالة كجزء من ضبط المشروع، لا مجرد إدارة للموارد البشرية.

ساعات المعدات لا تساوي التقدم أيضًا

ينطبق المنطق نفسه على المعدات.

على سبيل المثال، الرافعة المحجوزة لعشر ساعات لم تُنتج بالضرورة عشر ساعات من القيمة.

كذلك قد تكون الحفّارة الموجودة في الموقع:

• عاملة،
• منتظرة،
• متوقفة،
• تحت الصيانة،
• قيد التعبئة،
• أو معطّلة بسبب نشاط آخر.

السؤال ليس مجرد:

بل هو:

يتضمن نموذج إدارة المعدات في ProjectVIEW تكلفة التشغيل والتوقف، والجدولة والتوافر، والخدمات اللوجستية، والصيانة، والاستخدام اليومي للمعدات المرتبط بـ BoQ.

وبالتالي يمكن التعامل مع المعدات كمورد اقتصادي مرتبط بالإنتاج الفعلي للمشروع، لا مجرد أصل في سجل الأسطول.

وصول المواد إلى الموقع ليس تقدمًا

تُدخل المواد تشويهًا شائعًا آخر.

لنفترض أن:

70% من المواد قد تم شراؤها.

هل العمل مكتمل بنسبة 70%؟

بالطبع لا.

وماذا لو كان:

• 70% قد طُلب،
• 60% قد سُلّم،
• 55% قد استُلم في المخزون،
• 45% قد صُرف من المستودع،
• 40% قد رُكّب،
• و35% فقط قد فُحص وقُبل؟

أي نسبة تمثل التقدم؟

في الواقع، كل معاملة تُخبر الإدارة بشيء مفيد.

ومع ذلك، لا ينبغي الخلط بين أيٍّ منها والأخرى.

لذلك تميّز عمليات المواد والإنتاج في ProjectVIEW بين:

• المشتريات؛
• مذكرات استلام البضائع؛
• المخزون؛
• حركات المستودع؛
• الصرف؛
• مراحل الإنتاج؛
• استهلاك الموارد؛
• وتكلفة الإنتاج الفعلية.

هذا التمييز بالغ الأهمية في:

• التشييد،
• تصنيع أنظمة MEP،
• الهياكل الفولاذية،
• البناء المعياري،
• بناء السفن،
• إصلاح السفن،
• التصنيع البحري،
• التصنيع الصناعي،

وغيرها من بيئات الإنتاج القائمة على المشاريع.

• ما طُلب ليس ما استُلم.
• ما استُلم ليس ما استُهلك.
• ما استُهلك ليس ما رُكّب.
• وما رُكّب ليس بالضرورة ما قُبل.

لذلك لا ينبغي لأي من هذه النسب أن تتحول تلقائيًا إلى «تقدم المشروع».

تقدم ساحة التصنيع ليس تلقائيًا تقدمًا في الموقع

يزداد هذا أهمية عندما تجمع المشاريع بين التصنيع والتشييد.

لنفترض أن وحدة معيارية:

• مصنّعة بنسبة 80% في الساحة.

ثم هل أعمال المشروع المرتبطة بها مكتملة بنسبة 80%؟

• ربما لا.

فقد تظل الوحدة بحاجة إلى:

• الاختبار؛
• الفحص؛
• الطلاء؛
• الإفراج؛
• النقل؛
• الرفع؛
• التركيب؛
• التوصيل؛
• التشغيل التجريبي؛
• وقبول العميل.

لذلك يحتاج التصنيع القائم على المشاريع إلى ضبط التقدم عبر بيئات مادية متعددة:

يجب أن يبقى الخيط الاقتصادي متصلًا بينما ينتقل المنتج المادي.

وإلا فسيُبلغ كل قسم عن نسخته الخاصة من «الإنجاز».

التقدم الذي يطالب به مقاول الباطن نسخة أخرى من الواقع

قد يقدّم مقاول الباطن:

مكتمل بنسبة 55%.

ومع ذلك، ليست هذه بالضرورة النسبة التي ينبغي للمقاول الرئيسي الاعتراف بها.

لذلك قد يلزم التحقق من التقدم الفعلي مقابل:

• الكميات المقاسة؛
• سجلات الفحص؛
• أسعار العقد؛
• الاعتمادات السابقة؛
• التغييرات المعتمدة؛
• المحتجزات؛
• الخصومات؛
• حالات عدم المطابقة؛
• والمستندات الداعمة.

وبالتالي:

التقدم المُطالَب به ≠ التقدم المُتحقق منه

و:

التقدم المُتحقق منه ≠ التقدم المعتمد

صُممت عمليات مقاولي الباطن في ProjectVIEW لربط عقود مقاولي الباطن وتقدم الموقع والاعتمادات والخصومات والآثار المالية ضمن هيكل ضبط المشروع. وتصف DANAOS البيئة المتكاملة لـ ProjectVIEW بأنها تشمل تقدم مقاولي الباطن واعتماداتهم والتزاماتهم إلى جانب التحكم في تكاليف المشروع.

التقدم المعتمد ليس مماثلًا للتقدم المادي

قد يكون المقاول قد أنجز فعلًا:

50% من العمل المادي.

لكن ربما:

• 47% قد فُحص،
• 43% قد اعتُمد رسميًا،
• 38% قد فُوتر،
• و30% فقط قد دُفع فعليًا.

ومرة أخرى، لا تُعد أي من هذه النسب خاطئة بالضرورة.

بعبارة أخرى، إنها تنتمي إلى مراحل مختلفة في تحويل العمل إلى قيمة تجارية.

وهذا يعطينا تسلسلًا مهمًا:

لذلك ينبغي لنظام ERP للتشييد أن يحافظ على هذه الفروق مع الإبقاء على العلاقات بينها.

لأن التنفيذ التشغيلي يجب في النهاية أن يتحول إلى واقع مالي.

هنا يجب أن تلتقي محاسبة المشاريع بالمحاسبة المالية

على سبيل المثال، يمكن للمحاسبة المالية أن تُبلغ بدقة عن:

• الفواتير؛
• الذمم الدائنة؛
• الذمم المدينة؛
• قيود اليومية؛
• المدفوعات؛
• الإيرادات؛
• المصروفات.

لكن المحاسبة ترى عادةً الأثر المالي بعد أن يُعترف بالمعاملة ماليًا.

أما إدارة التشييد فيجب أن تفهم أيضًا ما يحدث تشغيليًا قبل وصول جميع المستندات المالية.

• قد يكون المورّد قد سلّم مواد لم تُرحَّل فاتورتها بعد.
• وقد يكون مقاول الباطن قد أنجز أعمالًا لم تُعتمد بعد.
• وقد تكون العمالة قد استُهلكت قبل إقفال كشوف الرواتب.
• وقد تكون المعدات قد عملت قبل إتمام التوزيع الشهري للتكاليف.
• لذلك يوجد التقدم المادي قبل أن تصل أجزاء من تكلفته إلى دفتر الأستاذ العام.

ومرة أخرى:

BoQ WBS Cost Codes

بعبارة أخرى، هنا تتلاقى المحاسبة المالية ومحاسبة المشاريع.

يتحقق التحكم في التكاليف عندما يبرر استهلاك الموارد التقدم

وبالتالي يمكننا الآن تعريف التحكم في التكاليف بدقة أكبر.

بعبارة أخرى، التحكم في التكاليف ليس مجرد معرفة:

• التكلفة الفعلية مقابل الميزانية.

بل هو فهم سبب وجود التكلفة الفعلية قياسًا بالعمل المنجز.

على سبيل المثال، لنفترض أن حزمتي عمل أنفقت كل منهما:

• $500,000.

اكتسبت الحزمة A:

• $550,000 من القيمة المدرجة في الميزانية.

واكتسبت الحزمة B:

• $350,000.

في الواقع، قد تكون المعاملة المحاسبية دقيقة بالقدر نفسه في الحالتين.

لكن الأداء التشغيلي مختلف تمامًا.

لهذا السبب يجب ربط تكلفة الموارد بهيكل المشروع نفسه الذي نقيس التقدم على أساسه.

وإلا فستتمكن الإدارة من رؤية المال.

وستتمكن من رؤية التقدم.

ومع ذلك، لن تستطيع أن تفسر بشكل موثوق العلاقة بينهما.

هذا ليس تحكمًا في التكاليف.

هذان تقريران منفصلان.

عندما تتوافق الكمية ومعدل الإنتاج والتكلفة

تتحقق أقوى الحالات عندما تتمكن الإدارة من المقارنة المستمرة بين:

الكمية

ما مقدار العمل الذي أُنجز فعلًا؟

معدل الإنتاج

ما مدى كفاءة إنتاج هذه الكمية عبر الزمن؟

التكلفة

ما مقدار الإنفاق على الموارد الذي تطلّبه تحقيقها؟

عندما تبقى هذه الثلاثة متوافقة مع خط الأساس، يعمل المشروع قريبًا من نموذجه الاقتصادي المخطط.

وعندما يبدأ أحدها في الانحراف، تتلقى الإدارة إنذارًا مبكرًا.

على سبيل المثال:

• الكمية متأخرة + التكلفة وفق المستهدف

في هذه الحالة، قد يشير ذلك إلى مشكلات في الجدول الزمني أو الإنتاجية.

• الكمية وفق المستهدف + التكلفة مرتفعة

في المقابل، قد يشير ذلك إلى عدم كفاءة في استخدام الموارد.

• الكمية متقدمة + التكلفة متقدمة بالنسبة نفسها

قد يعكس ببساطة تسريع التنفيذ.

• الكمية متقدمة + التكلفة أقل من المخطط

قد يشير إلى تحسّن الإنتاجية.

• مرور الوقت + كمية مكتسبة قليلة

يشير إلى تدهور الجدول الزمني.

لهذا السبب لا يمكن تفسير التقدم بمعزل عن غيره.

بل يجب تفسيره من خلال الإنتاج والتكلفة.

من تقارير التقدم إلى اختبار مستمر للواقع

على سبيل المثال، تميل التقارير التقليدية إلى العمل بشكل دوري:

• جمع التقدم.
• تحديث P6.
• جمع التكاليف الفعلية.
• انتظار الفواتير.
• إقفال الحسابات المالية.
• مطابقة جداول البيانات.
• إعداد تقرير شهري.
• تفسير الانحراف.

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

في المقابل، يغيّر نظام ERP المتمحور حول المشاريع هذا التسلسل.

يسجّل مستخدمو الموقع باستمرار:

• التقدم المادي؛
• معاملات العمالة؛
• استخدام المعدات؛
• حركات المواد؛
• الإنتاج؛
• تقدم مقاولي الباطن؛
• عمليات الفحص؛
• الاعتمادات؛
• وغيرها من الأحداث التشغيلية.

كما تشير هذه المعاملات إلى هياكل المشروع نفسها.

وبالتالي يستطيع النظام أن يسأل باستمرار:

هذا اختبار واقع حقيقي للمشروع.

وهذا أيضًا أساس الذكاء الاصطناعي الموثوق

بالإضافة إلى ذلك، يجعل الذكاء الاصطناعي هذه البنية أكثر أهمية.

على سبيل المثال، تخيّل أن تسأل وكيل ذكاء اصطناعي مؤسسيًا:

إذا كان التقدم موجودًا في P6،

والمواد في جداول البيانات،

والعمالة في نظام الرواتب،

والمعدات في نظام آخر،

وتقدم مقاولي الباطن في ملفات PDF،

والمشتريات في نظام ERP،

والبيانات المالية الفعلية في دفتر الأستاذ العام،

فيجب على الذكاء الاصطناعي عندئذٍ أولًا محاولة استنتاج العلاقات بين مجموعات البيانات هذه.

هذه مسألة احتمالية حتى قبل معالجة سؤال العمل الفعلي.

أما إذا كانت:

BoQ وWBS وCost Codes والموارد والتقدم والمعاملات المالية مرتبطة ارتباطًا حتميًا مسبقًا،

فإن الذكاء الاصطناعي يعمل انطلاقًا من سياق أعمال منظَّم.

وبالتالي يمكنه استجواب المشروع بدلًا من إعادة بنائه.

باختصار، هذا هو الغرض من بنية ProjectVIEW ERP + ProjectVIEW AI:

لذلك لا ينبغي أن نطلب من الذكاء الاصطناعي اختراع العلاقات التي أخفقت المؤسسة نفسها في إرسائها.

إذن، ما مدى اكتمال مشروع «مكتمل بنسبة 50%»؟

الإجابة الصحيحة هي:

• يعتمد ذلك على ما تقيسه نسبة الـ50%.

لكن إدارة التشييد يجب أن تذهب أبعد من ذلك.

إذا كانت الـ50% تمثل إنجازًا ماديًا مُتحققًا منه، فعلى الإدارة أن تسأل:

• ما الذي خططنا لتحقيقه حتى الآن؟
• ما الكمية التي حققناها فعلًا؟
• كم استغرق ذلك من الوقت؟
• ما العمالة التي استهلكناها؟
• ما المعدات التي استهلكناها؟
• ما المواد التي استهلكناها؟
• ما قيمة أعمال مقاولي الباطن التي استهلكناها؟
• ما التكلفة الفعلية؟
• ما القيمة التي اكتسبناها؟
• ما الذي تم اعتماده؟
• ما الذي تمت فوترته؟
• ما الذي تم تحصيله؟

عندها فقط تصبح عبارة «مكتمل بنسبة 50%» معلومة إدارية لا مجرد رقم على لوحة متابعة.

الأسئلة الشائعة

ما هو التقدم الفعلي في التشييد؟

باختصار، التقدم الفعلي هو الكمية القابلة للقياس أو النسبة المُتحقق منها بموضوعية من أعمال المشروع المنجزة فعلًا في تاريخ التقرير. كما ينبغي عادةً تسجيله مقابل نطاق المشروع الممثَّل في بنود BoQ أو أنشطة WBS أو علاقة مضبوطة بينهما.

كيف يجب قياس التقدم في التشييد؟

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

هل تكفي نسبة الإنجاز في WBS لضبط مشروع تشييد؟

لا.

نسبة الإنجاز في WBS قيّمة لإدارة الجدول الزمني، لكن ضبط المشروع يتطلب أيضًا المقارنة بالكميات المادية واستهلاك الموارد والتكلفة.

في المقابل، إن نسبة تقدم في WBS منفصلة عن العمالة والمواد والمعدات ومقاولي الباطن والمعاملات المالية توفّر تقارير تقدم، لا إدارة تشييد شاملة.

ما العلاقة بين التقدم والتحكم في التكاليف؟

باختصار، يحدد التقدم العمل الذي أنجزه الفريق.

ويحدد التحكم في التكاليف ما إذا كانت الموارد والتكلفة المستهلكة لإنجاز هذا العمل متوافقة مع ميزانية المشروع.

لذلك ينبغي ربط التكلفة الفعلية للعمالة والمعدات والمواد ومقاولي الباطن والموارد الأخرى بـ BoQ و/أو WBS نفسه الذي يُقاس التقدم على أساسه.

ما هي القيمة المكتسبة في التشييد؟

بعبارة أخرى، القيمة المكتسبة هي القيمة المدرجة في الميزانية للعمل المنجز فعليًا.

لذلك تتيح للإدارة مقارنة ما خططت له، وما تحقق، وما كلّفه العمل المنجز فعليًا.

يستخدم Oracle Primavera مقياس Performance Percent Complete لحساب القيمة المكتسبة. تعريفات القيمة المكتسبة في Oracle Primavera P6

ما الفرق بين التقدم المادي والقيمة المكتسبة؟

أولًا، يصف التقدم المادي مقدار العمل المنجز.

في المقابل، تُسند القيمة المكتسبة القيمة الاقتصادية المدرجة في الميزانية لهذا العمل المنجز.

لذلك يثبت التقدم المادي الإنجاز، بينما تساعد القيمة المكتسبة الإدارة على مقارنة الإنجاز بميزانية المشروع وتكلفته الفعلية.

لماذا قد يكون المشروع مكتملًا بنسبة 50% لكنه تجاوز الميزانية بالفعل؟

لأن التقدم المادي واستهلاك الموارد قد يكونان في حالة تباعد.

فقد يحقق المشروع 50% من أعماله بعد استهلاك 70% من ميزانية العمالة و65% من ميزانية المعدات و60% من تكلفته الإجمالية.

قد تكون نسبة الإنجاز صحيحة بينما يتدهور الأداء الاقتصادي للمشروع.

كيف ترتبط إنتاجية العمالة بالتقدم في التشييد؟

باختصار، تقيس إنتاجية العمالة العلاقة بين العمالة المستهلكة والعمل المنتَج.

على سبيل المثال:

الأمتار المركّبة / ساعة عمل

أو:

الأطنان المصنّعة / ساعة عمل

لذلك فإن تتبع ساعات العمل دون ربطها بمخرجات قابلة للقياس يُظهر الاستهلاك لا الإنتاجية.

هل يُعد توريد المواد تقدمًا في التشييد؟

ليس بالضرورة.

على سبيل المثال، قد يطلب الفريق المواد ثم يتسلّمها ويخزّنها ويصرفها ويصنّعها ويركّبها ويقبلها في أوقات مختلفة.

وصول المواد مهم للخدمات اللوجستية والالتزامات، لكن لا ينبغي تفسيره تلقائيًا على أنه تقدم مادي في التشييد.

هل التقدم الذي يطالب به مقاول الباطن هو نفسه تقدم المشروع؟

لا.

يجب التحقق من مطالبات مقاولي الباطن مقابل العمل القابل للقياس وسجلات الفحص وشروط العقد والتغييرات والاعتمادات السابقة والخصومات والمحتجزات قبل أن تصبح تقدمًا معتمدًا.

لماذا نربط BoQ وWBS وCost Codes؟

والسبب أنها تمثل ثلاثة أبعاد مختلفة لكنها مترابطة للمشروع نفسه:

BoQ — النطاق القابل للقياس/التجاري

WBS — التنفيذ والزمن

Cost Codes — التصنيف الاقتصادي

نتيجة لذلك، يتيح ربطها تحليل التقدم المادي واستغلال الموارد والتكلفة المالية مقابل واقع المشروع نفسه.

لمزيد من المعلومات عن هذه البنية، راجع ما كتبته DANAOS حول WBS والتحكم في تكاليف المشاريع. لماذا لا يكفي WBS وحده للتحكم في تكاليف المشروع

الخلاصة

إن كون المشروع «مكتملًا بنسبة 50%» ليس معلومة كافية لإدارته.

نحن بحاجة إلى معرفة:

50% من ماذا؟

ثم:

بأي تكلفة؟

باستخدام أي موارد؟

خلال أي مدة؟

مقابل أي كمية وإنتاجية مخططة؟

محقِّقًا أي قيمة مكتسبة؟

لأن:

وعندما تُقارن قيمة العمل المنجز باستمرار بما خُطط له وبما كلّفه فعلًا، ننتقل من مجرد إعداد تقارير عن المشروع إلى التحكم فيه.

هذا هو الفرق بين معرفة أن العمل يجري ومعرفة ما إذا كان المشروع يحقق الأداء المطلوب.

Read more: مكتمل بنسبة 50% وفقًا لمن؟ التقدم الفعلي في التشييد والتحكم في التكاليف والقيمة المكتسبة