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