اختيار نظام تخطيط موارد المؤسسات (ERP): لماذا تعد الشراكة الصحيحة أمراً بالغ الأهمية؟

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

 

يمكن لعرض توضيحي لنظام ERP أن يوضح أن النظام ينشئ أوامر الشراء، ويسجل التكاليف، وينشئ لوحات المعلومات.

 

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

 

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

 

ولهذا أرى أن تقييم نظام ERP للمؤسسات يجب أن يجيب عن سؤالين أساسيين:

 

هل تفهم هذه المنصة كيفية عمل أعمالنا؟

 

هل يستطيع هذا المزوّد مساعدتنا في تنفيذ النظام وتشغيله وتطويره باستمرار؟

 

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

 

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

 

1. يجب إثبات الخبرة في القطاع من خلال منطق الأعمال

 

يجب أن يفهم مزود نظام ERP أكثر من مجرد المصطلحات المستخدمة داخل شركة الإنشاءات.

 

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

 

لننظر إلى ثلاثة هياكل مختلفة للمشروعات.

 

• جدول الكميات — BoQ — يحدد بنود الأعمال المقاسة وكمياتها. ويمكن لتحليل الموارد مقابل هذه البنود أن يدعم تقدير التكلفة الداخلي للمقاول. ولا يعني سعر البيع المقدم للعميل تلقائيًا أنه يساوي تكلفة التنفيذ الداخلية.

 

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

 

• رموز التكلفة — Cost Codes — توفر التصنيف الداخلي الذي يمكن من خلاله تجميع وتحليل ومطابقة النفقات وتكاليف الموارد.

 

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

 

وتستكشف DANAOS Insights العلاقة بين هذه الأبعاد في إنشاء خطوط الأساس لأداء المشروع، من خلال الربط بين BoQ وWBS وتصنيف التكاليف وتخطيط الموارد واعتماد الأعمال.

 

والاختبار العملي واضح:

 

هل يستطيع المزوّد شرح كيف يؤثر التغيير في الكمية على احتياجات الموارد، والمشتريات، والتنفيذ، والتكلفة، والتوقعات—وليس فقط كيفية إدخال التغيير في النظام؟

 

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

 

قيّم الإعداد المقترح والعملية الفعلية—وليس صورة نمطية عن المزوّد.

 

2. استبدل العروض التوضيحية المنفصلة باختبار متكامل للمشروع من البداية إلى النهاية

 

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

 

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

 

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

 

بعد ذلك، اطلب من المزوّد توضيح كيفية استخدام المعلومات نفسها لدعم:

 

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

 

ثم أدخل تغييرًا على السيناريو.

 

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

 

والآن افحص ما إذا كان النظام يحافظ على التمييز بين العناصر التي تهم فعليًا:

 

المادة المستلمة ليست بالضرورة مادة مستهلكة.

 

والمادة المستهلكة ليست بالضرورة تقدمًا فعليًا معتمدًا.

 

والتكلفة المتكبدة ليست بالضرورة تغييرًا معتمدًا من العميل.

 

كما يجب ألا يقوم التوقع المعدل بصمت باستبدال خط الأساس الأصلي المعتمد.

 

وفي كل مرحلة، اسأل: من يسجل الحدث؟ ومن يعتمد عليه؟ وما الذي يتغير في العمليات اللاحقة؟ وما الأدلة التي تبقى محفوظة؟

 

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

 

الهدف ليس جعل العرض التوضيحي صعبًا.

 

بل اكتشاف ما إذا كان الحل المقترح سيظل متماسكًا عندما يصبح المشروع نفسه أكثر تعقيدًا.

 

3. القدرة على التنفيذ جزء مما تشتريه بالفعل

 

المنصة القوية لا تقوم بتهيئة نفسها تلقائيًا بما يتناسب مع المؤسسة.

 

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

 

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

 

وبالنسبة للمشترين من المؤسسات، أترجم ذلك إلى ثلاثة متطلبات.

 

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

 

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

 

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

 

إن عبارة “يمكننا دعم ذلك” ليست دقيقة بما يكفي.

 

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

 

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

 

ويجب على الشريك الموثوق أن يجعل هذه الفروق أكثر وضوحًا، لا أن يعمل على إخفائها.

 

4. يجب أن يحافظ التكامل على المعنى، وليس مجرد نقل البيانات

 

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

 

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

 

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

 

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

 

والأهم من ذلك، حدد من يتحمل المسؤولية عندما تعبر العملية الحدود بين نظامين.

 

توصي قائمة Microsoft المرجعية لاستراتيجية التكامل والحوكمة باختبار التكاملات في ظروف واقعية، وفحص آثارها على العمليات السابقة واللاحقة.

 

وتتناول DANAOS Insights العلاقة بين المشروع والوظائف المالية في مقال رموز التكلفة في ProjectVIEW ERP: التكامل مع Oracle Fusion وSAP. ويستخدم النهج المنشور خرائط رموز التكلفة لربط عمليات المشروع بالتقارير المؤسسية.

 

وهذا يخلق خيارًا معماريًا مهمًا.

 

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

 

يجب على الشريك الموثوق أن يوصي بالبنية التي تناسب الأعمال—not تلقائيًا بأكبر برنامج استبدال ممكن.

 

5. تبني المستخدمين هو نتيجة للعملية، وليس مجرد عدد مرات تسجيل الدخول

 

لا يثبت تسجيل الدخول إلى نظام ERP أن المستخدم يستفيد منه بكفاءة.

 

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

 

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

 

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

 

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

 

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

 

وتتضمن قائمة Microsoft المرجعية لإدارة التغيير اختبارات يوم العمل المعتاد، وملاحظات التدريب، ونقل المعرفة، وقياس التبني والاستخدام.

 

وتطور DANAOS في مقال المؤسسة المتعلمة: كيف يسرّع ProjectVIEW ERP التحول الرقمي العلاقة بين العمليات الموحدة، والاحتفاظ بالمعرفة، والتعلم التشغيلي المستمر.

 

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

 

يجب ألا يكون الهدف هو جعل الموظفين معتمدين على المزوّد في كل إجراء روتيني.

 

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

 

6. الشريك القوي لا يمكنه أن يحل محل القيادة الملتزمة

 

لدى المزوّد مسؤوليات، وكذلك العميل.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

7. حدد نتائج الأعمال قبل البدء في عد الوحدات التي تم تشغيلها

 

يوضح إنجاز مرحلة التنفيذ للإدارة ما تم تثبيته وتشغيله.

 

لكنه لا يثبت بمفرده ما الذي تحسن بالفعل.

 

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

 

الرؤية التجارية ورؤية التكلفة: هل يستطيع الفريق تحديد الميزانية الحالية، والتكاليف الفعلية، والالتزامات القائمة، والتوقع المتبقي دون احتساب مزدوج؟ وما مدى سرعة تقييم أثر أي تغيير؟

 

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

 

موثوقية العمليات: كم من الوقت يستغرق اعتماد طلب شراء، أو حل استثناء في البيانات، أو مطابقة سجلات المشروع مع السجلات المؤسسية؟ وما الحلول الالتفافية التي لا تزال مستخدمة؟

 

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

 

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

 

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

 

8. يجب أن يكون الدعم طويل الأجل محددًا من الناحية التشغيلية

 

عبارة “الدعم مشمول” تترك الكثير من الأسئلة دون إجابة.

 

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

 

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

 

وبالنسبة للمقاول، أوصي باختبار نموذج الخدمة من خلال موقف عملي:

 

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

 

يجب أن تحدد الإجابة قناة الإبلاغ، ومسؤول الحادث، ومسار التصعيد، والحل المؤقت للأعمال، وآلية التواصل.

 

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

 

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

 

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

 

9. تتضمن الثقة الشفافية بشأن الاستمرارية والتكلفة وإمكانية الخروج

 

يجب ألا تعتمد العلاقة طويلة الأجل على جعل مغادرة النظام أو المزوّد أمرًا صعبًا بشكل متعمد.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

10. يجعل الذكاء الاصطناعي اختيار ERP المنضبط أكثر أهمية—وليس أقل

 

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

 

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

 

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

 

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

 

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

 

وترى DANAOS Projects أن الذكاء الاصطناعي يجب أن يعمل حول بيانات المشروعات الخاضعة للرقابة والعمليات التجارية المنظمة.

 

والسؤال المهم ليس فقط: “هل يتضمن نظام ERP الذكاء الاصطناعي؟”

 

بل هو: “هل يمكننا فهم ما يفعله الذكاء الاصطناعي، وإدارته، والتحقق من نتائجه؟”

 

كيف يتوافق ProjectVIEW ERP مع هذا التقييم؟

 

تعتمد البنية المنشورة لـ ProjectVIEW ERP على ربط BoQ وWBS وCost Codes عبر العمليات التجارية والتشغيلية والمالية.

 

وتشرح DANAOS Insights هذا النهج في مقال كيف يحقق ProjectVIEW ERP مراقبة حقيقية للتكاليف: نظرة متعمقة على بنية الوحدات المتكاملة. ويوضح المقال كيف تساهم عمليات التقدير، والمشتريات، ومعاملات الموقع، والتعاقد من الباطن، والمعلومات المالية في إنشاء هيكل مشترك لمراقبة المشروع.

 

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

 

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

 

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

 

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

 

فكرة ختامية

 

لا يختار مشترو أنظمة ERP للمؤسسات مجرد برنامج.

 

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

 

فالمنصة المناسبة لا تستطيع تعويض ضعف التنفيذ.

 

والشريك المناسب لا يستطيع تعويض عدم ملاءمة المنتج من الأساس.

 

ولا يستطيع أي منهما تعويض مؤسسة غير مستعدة لتحمل مسؤولية عملياتها وقراراتها.

 

ولذلك يجب أن يجيب اختيار نظام ERP الأقوى عن سؤال صعب ولكنه أكثر فائدة:

 

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

 

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

 

عن المؤلف

 

Christos Emmanouilidis هو مهندس مدني والرئيس التنفيذي لشؤون العملاء والشؤون التجارية في DANAOS Projects Software Solutions LLC. ويركز عمله على أنظمة ERP المتخصصة في القطاعات، وتكنولوجيا الإنشاءات، ونتائج العملاء، والتحول الرقمي للمؤسسات القائمة على المشروعات.