لماذا تفشل 70% من مشاريع التحوّل الرقمي؟

لماذا يخفق التحوّل؟

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

وقد وجدت أبحاث Pulse of the Profession الصادرة عن PMI أن المتخصّصين في إدارة المشاريع ممّن يتمتّعون بحسّ تجاري عالٍ يُبلغون عن معدّل إخفاق في المشاريع قدره 8%، مقابل 11% لدى نظرائهم. وقد شمل استطلاع PMI في تلك الدراسة 2841 متخصّصاً في إدارة المشاريع. فالمتخصّصون الذين يفهمون الواقع التشغيلي يوازنون بصورة أفضل بين الخيارات التقنية في البنية والنطاق والأولويات. وحين تربط الفرق القرارات التقنية بالواقع التجاري مباشرةً، يتراجع انحراف المشاريع عن مسارها تراجعاً كبيراً.

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

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

ما تحدّيات التحوّل الرقمي؟

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

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

وكثيراً ما تدرك القيادات التنفيذية إلحاح تحديث البنية التحتية القديمة. وتستشهد IBM ببحث أجراه IBM Institute for Business Value، قال فيه 83% من كبار التنفيذيين إن تحديث التطبيقات والبيانات محوري في استراتيجية أعمالهم. ويتطلّب تحديث الأنظمة القديمة اختيار المسار المناسب من بين تجديد البنية، والاستبدال الكامل، والخدمات المصغّرة (microservices) الموجّهة، حمايةً للعمليات القائمة.

وتعدّد IBM 6 أساليب لتحديث التطبيقات. كما تتطلّب البنية الحديثة حدود تكامل واضحة بين أنظمة الأعمال المتنوّعة. وقد خلص تقرير State of the API الصادر عن Postman إلى أن 82% من المؤسّسات تبنّت نهج API-first بدرجة ما. وحين يُهمَل التخطيط للتكامل، تعجز الأدوات المتفرّقة عن تبادل البيانات الحيوية، فيبقى السياق التشغيلي القيّم حبيس قواعد بيانات معزولة داخل المؤسّسة.

لماذا يخفق التحوّل الرقمي؟

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

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

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

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

كيف نمنع الإخفاق في التسليم قبل كتابة الشيفرة؟

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

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

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

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

ما منهجية التسليم التي تُبقي مشاريع البرمجيات ضمن جدولها الزمني؟

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

ونتّفق معكم على طريقة عمل البرمجيات وشكلها باستخدام نماذج أوّلية قبل تخصيص أي وقت هندسي. وتطوير نماذج أوّلية قابلة للنقر يكفل أن يفهم مسؤولو العمليات طريقة تفاعل النظام قبل تطوير خدمات الواجهة الخلفية. ومراجعة مسارات الواجهة التفاعلية مبكراً تكشف صعوبات الاستخدام التي كثيراً ما تعجز المخطّطات الثابتة للواجهات (wireframes) عن إظهارها.

ونطوّر على مراحل متتالية مع آلية إصدار مؤتمتة، لتوجّهوا العمل أثناء التطوير. والإيقاع المنتظم للتسليم يتيح لرعاة المشروع من جهة الأعمال تعديل النطاق كلّما ظهرت احتياجات فعلية. أما الاختبار المستمرّ المؤتمت فيمنع عيوب التراجع (regression)، فلا تُخلّ الميزات الجديدة بالوحدات الوظيفية القائمة.

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

كيف تؤثّر حوكمة البيانات والتنفيذ المحلّي في المشاريع؟

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

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

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

كم يستغرق تطوير نظام للتشغيل الفعلي من انطلاق المشروع حتى الإطلاق؟

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

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

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

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

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

أبرز النقاط

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

المصادر

1. إدارة المتطلبات وإخفاق المشاريع: تقرير Pulse of the Profession (pmi.org)
2. نتائج المشاريع والحسّ التجاري: تقرير Pulse of the Profession لعام 2025 (pmi.org)
3. تعريف تحديث التطبيقات وأساليبه الستّة (ibm.com)
4. تبنّي نهج API-first والإيرادات من API: تقرير State of the API لعام 2025 (postman.com)