المقدمة

في مجال مشاريع تكنولوجيا المعلومات في القطاع العام، قلما توجد قصص متباينة مثل تلك الخاصة ببرنامج التكنولوجيا الوطنية للمعلومات (NPfIT) في هيئة الخدمات الصحية الوطنية (NHS) وتطوير موقع GOV.UK بواسطة خدمة الحكومة الرقمية (GDS). بينما أصبح NPfIT مرادفًا للفشل، يتم الثناء على مشروع GOV.UK باعتباره نموذجًا ناجحًا للتحول الرقمي. في صميم هذه النتائج المتناقضة توجد اختلافات جوهرية: الأساليب التي استخدمت في تنفيذها. اعتمد برنامج NPfIT بشكل كبير على نموذج الشلال (Waterfall) مما ساهم في فشله، في حين أن النهج الرشيق (Agile) الذي تبناه فريق GDS أدى إلى نجاح GOV.UK. تستعرض هذه المقالة التحديات والفشل النهائي لـ NPfIT والنجاح المتناقض لـ GOV.UK من خلال منظور الأساليب التي استخدمتها كل منهما.

رحلة NPfIT: طموح عرقله أسلوب الشلال

رؤية كبيرة أعيقتها التعقيدات

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

نموذج الشلال: التخطيط قبل التنفيذ

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

في الممارسة العملية، أدى اعتماد نموذج الشلال إلى العديد من المشاكل:

• تأخير في تسليم القيمة: مع نموذج الشلال، يتم تسليم معظم القيمة في نهاية المشروع. بالنسبة لـ NPfIT، هذا يعني أن سنوات مرت قبل أن تصبح الأنظمة القابلة للاستخدام متاحة، مما أدى إلى إحباط أصحاب المصلحة.
• عدم المرونة تجاه التغيير: تغيرت احتياجات NHS بمرور الوقت، ولكن الهيكل الجامد لنموذج الشلال جعل من الصعب التكيف مع المتطلبات الجديدة دون إعادة هيكلة وتأخيرات كبيرة.
• تراكم المخاطر: بتأخير الاختبارات والتحقق حتى المراحل اللاحقة، تراكمت المشاكل دون أن تُلاحظ حتى فوات الأوان في كثير من الأحيان لحلها دون تكاليف وجهد كبير.

المركزية مقابل الاحتياجات المحلية

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

الاعتماد على الموردين والعوائق التقنية

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

تجاوزات مالية وتشغيلية

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

رحلة GOV.UK: النجاح من خلال المنهجية الرشيقة

نهج يركز على المستخدم ومتكرر

على النقيض التام من برنامج NPfIT، يُظهر تطوير موقع GOV.UK بواسطة خدمة الحكومة الرقمية (GDS) الفوائد الجلية للمنهجيات الرشيقة. تم إطلاق GOV.UK كإصدار تجريبي (بيتا) في عام 2011 وأصبح متاحًا بشكل كامل بحلول عام 2012، وهدف إلى تبسيط الخدمات الحكومية وتوحيدها عبر الإنترنت، مما يجعلها أكثر سهولة للمواطنين.

المنهجية الرشيقة: المرونة والتسليم المستمر

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

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

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

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

تمكين الفرق الصغيرة متعددة التخصصات

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

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

التركيز على احتياجات المستخدمين

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

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

فعالية التكلفة والسرعة

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

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

الخاتمة

تُبرز القصص المتباينة لـ NPfIT و GOV.UK الدور الحيوي للأساليب المتبعة في إدارة المشاريع في تحديد نجاح مشاريع تكنولوجيا المعلومات على نطاق واسع. أدت الاعتماد على نموذج الشلال في NPfIT إلى تأخيرات في تسليم القيمة، وعدم مرونة، وفشل نهائي، رغم الاستثمارات الكبيرة. في المقابل، سمح النهج الرشيق لـ GOV.UK بالتطوير السريع، المركز على المستخدم، والتحسين المستمر، والتسليم الفعال من حيث التكلفة.

بينما تستمر المنظمات العامة في السعي نحو التحول الرقمي، تُظهر الدروس المستفادة من NPfIT و GOV.UK أهمية تبني أساليب تركز على المرونة، والتطوير التكراري، وتسليم القيمة المبكر والمستمر. يبرهن نجاح GOV.UK على أن الأساليب الرشيقة ليست مجرد بديل عصري، بل هي إطار مجرب لتحقيق تحول رقمي مستدام وذو تأثير كبير.