فخ التحول: لماذا تفشل المشاريع التقنية وكيف تُقلّل مخاطرها

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

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

لماذا تفشل هذه المشاريع فعلًا

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

• عُرِّف التحوّل بوصفه برمجيات، لا نتائج. «أطلِقوا نظام ERP» مُخرَجٌ، أما «اختصار دورة الطلب حتى التحصيل من 40 يومًا إلى 15» فهدف. والمشاريع المبنيّة حول الأداة كثيرًا ما تُسلّم الأداة وتُخطئ الغاية.
• غياب مالكٍ واحد مسؤول. حين تتقاسم ملكيةَ البرنامج إدارةُ التقنية والعمليات ولجنةٌ توجيهية، فلا أحد يملكه حقًّا، وتتعثّر القرارات في الفجوات بين الإدارات.
• التسليم على دفعة واحدة كبيرة. يختفي الفريق عامًا كاملًا ليبني كل شيء، ثم يعود فيجد أن السوق قد تحرّك. وكلما اتّسعت الفجوة بين الإنفاق والتغذية الراجعة، عمُقت الحفرة.
• مرحلة أخيرة بلا ميزانية. تُعامَل إدارة التغيير والتدريب وتنظيف البيانات وإعادة تصميم العمليات كأنها تفاصيل ثانوية، وهي في الحقيقة الميدان الذي يُكسب فيه التبنّي أو يُخسر.

أيُّ تحوّلٍ لا تستطيع وصفه بأنه تغييرٌ قابلٌ للقياس في طريقة عمل الناس صباح الثلاثاء ليس تحوّلًا، بل عملية شراء.

أسطورة الانفجار الكبير

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

لذلك أدفع عملائي نحو شرائح رأسية رفيعة: اختَر فريقًا واحدًا ومسارًا واحدًا ومؤشرًا واحدًا قابلًا للقياس، ثم أطلِق شيئًا يستخدمونه فعليًا في الإنتاج خلال أسابيع — لا عرضًا توضيحيًا ولا بيئة تجريبية، بل عملًا حقيقيًا. فالشريحة التي تخترق كل طبقة (البيانات والمنطق والواجهة والعملية البشرية من حولها) تكشف وجع التكامل والاحتكاك السياسي مبكرًا، حين يكون علاجهما ما زال رخيصًا. وعشرة إصدارات صغيرة يُحرّك كلٌّ منها رقمًا خيرٌ من إصدار بطولي واحد لا يُحرّك سوى تاريخ الإطلاق.

تقليل المخاطر: ما ينجح فعلًا

المخاطر لا تُزال بوثائق تخطيطٍ أفضل، بل بتقصير حلقات التغذية الراجعة وجعل الفشل ممكن النجاة منه. وهذه خطواتٌ رأيتُها تؤتي ثمارها باستمرار:

اربط كل مرحلة بمؤشر عمل

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

عيّن مالكًا واحدًا بصلاحية حقيقية

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

قِس قبل أن تُرحّل

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

خصّص ميزانية المرحلة الأخيرة مسبقًا

افترض أن جهد التبنّي يعادل ثلث العمل، لا هامشًا صغيرًا للتقريب. درّب من سيستخدم النظام فعلًا، ونظّف البيانات قبل أن تُسمّم النظام الجديد، وأعِد تصميم العملية بدل رصف المسار القديم المعوجّ بإسفلتٍ جديدٍ باهظ.

مُسرِّع الذكاء الاصطناعي

لم يُخفّف الذكاء الاصطناعي هذا الفخّ، بل زاده سوءًا. فالضغط في اتجاه «افعلوا شيئًا بالذكاء الاصطناعي» يُنتج تجارب بلا مالك، وبلا خطّ أساس، وبلا طريقٍ إلى الإنتاج — نمط الفشل نفسه، لكن بعنوانٍ أكثر بريقًا. والنموذج الذي يبهر في عرضٍ توضيحي دون أن يمسّ مسار عملٍ حقيقيًّا ليس تحوّلًا، بل استعراض. فطبّق الانضباط نفسه: مسارٌ واحد، ومؤشّرٌ واحد، ومالكٌ واحد، وقياسٌ سريعٌ صادقٌ لِما إذا كان قد حرّك الرقم فعلًا.

من أين تبدأ يوم الاثنين

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

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