إنه صباح يوم الاثنين. لقد أمضيت الجزء الأكبر من يوم الجمعة في سحب تحديثات الحالة من خمسة مديري مشاريع مختلفين، وتوفيق تواريخ المراحل الرئيسية عبر ثلاثة جداول بيانات، وإقناع تقرير Power BI بتحويله إلى شيء لا يحرجك أمام اللجنة التنفيذية. تبدو لوحة المعلومات جيدة. وربما حتى جيدة. ومع ذلك - السؤال الأول في الاجتماع هو: "هل يمكننا الوثوق بهذه الأرقام؟
هذا السؤال هو نمط الفشل الهادئ لمعظم إعدادات تقارير محفظة المشاريع. ليس خطأ فنيًا. ليست بيانات مفقودة. بل مجرد تآكل بطيء في الثقة يجعل من تقريرك نقطة انطلاق للنقاش بدلاً من أن يكون أساساً لاتخاذ القرارات.
إذا كان هذا يبدو مألوفًا، فمن شبه المؤكد أن المشكلة ليست في Power BI. إنها كيفية هيكلة تقارير المحفظة - ولماذا تستمر الإصلاحات المعتادة في جعل الأمور أسوأ.
لماذا تتعطل تقارير محفظة المشاريع في Power BI
هناك مجموعة محددة من الشروط التي تحول لوحة معلومات محفظة Power BI إلى شيء يولد أسئلة أكثر مما يجيب عنها. لا شيء منها واضح من الخارج، وهذا جزء من سبب استمرارها.
1. نموذج البيانات مصمم للمشاريع الفردية وليس للمحافظ. تبدأ معظم عمليات تطبيق Power BI في بيئات المشاريع ببيانات مشروع واحد - الجدول الزمني والميزانية والموارد - ثم يتم توسيعها لتغطية المحفظة من خلال تكديس المزيد منها. والنتيجة هي تقرير يمكن أن يُظهر لك حالة المشروع الفردي بشكل معقول، ولكنه ينهار عندما تحاول الإجابة عن أسئلة على مستوى المحفظة: ما البرامج المعرضة لخطر عدم الوفاء بالتزامات الربع الثالث؟ أين يتجمع تجاوز الميزانية عبر المحفظة؟ لم يتم تصميم النموذج الأساسي للإجابة على هذه الأسئلة، ولن يؤدي أي قدر من التدابير الجديدة إلى إصلاح عدم التطابق الهيكلي.
2. بيانات الحالة تأتي بشكل غير متناسق، ولا أحد يملك مشكلة الجودة. يعتمد إعداد تقارير الحافظة على قيام مديري المشاريع بتقديم تحديثات صادقة وفي الوقت المناسب. ومن الناحية العملية، يقوم البعض بتقديمها في وقت مبكر، والبعض يقدمها في وقت متأخر، والبعض يقدم أرقامًا متفائلة لتجنب التصعيد. يقوم نظام Power BI بإعداد التقارير بإخلاص عن كل ما يتلقاه. وينتهي الأمر بمكتب إدارة المشاريع إلى أن يكون مسؤولاً عن تقرير لم يتحكم فيه بشكل كامل - وينتهي الأمر بالقيادة إلى التشكيك في الأرقام التي قد تعكس الواقع أو لا تعكسه. هذه ليست مشكلة أشخاص. إنها مشكلة عملية وحوكمة ترثها طبقة إعداد التقارير.
3. يحاول التقرير أن يخدم الكثير من الجماهير في آن واحد. يحتاج مديرو المشاريع التشغيلية إلى تفاصيل على مستوى المهام. ويحتاج مديرو البرامج إلى تتبع المراحل الرئيسية. وتحتاج اللجنة التوجيهية إلى حالة RAG على مستوى المحفظة والتعرض المالي. عندما يحاول تقرير واحد من تقارير Power BI القيام بكل ذلك - عادةً من خلال مجموعة مترامية الأطراف من الصفحات والمرشحات - ينتهي به الأمر إلى عدم القيام بأي من ذلك بشكل جيد. يتوقف المستخدمون التنفيذيون عن النظر إليه لأن العثور على ما يحتاجون إليه يستغرق وقتاً طويلاً. ويتجاهله مديرو المشاريع لأن التفاصيل غير مناسبة لعملهم. ويترك مكتب إدارة المشاريع يحتفظ بتقرير لا يرضى عنه أحد بشكل كامل.
ما الذي يجربه معظم المدمنين على المداومة على ممارسة الجنس في البداية - ولماذا لا ينجح
عندما لا تنجح لوحة معلومات المحفظة في الهبوط، فإن الغريزة هي إضافة المزيد إليها. المزيد من الفلاتر. المزيد من التنقيب. أعمدة حالة مرمزة بالألوان تتدرج عبر ثلاثة مستويات من التسلسل الهرمي. التنسيق الشرطي الذي يبرز كل شيء باللون الأحمر حتى لا يبرز أي شيء. لقد رأيت تقارير تحتوي على سبع عشرة صفحة يتنقل فيها المديرون التنفيذيون من خلال الطلب من مكتب إدارة المشاريع مشاركة الشاشة والنقر عليها.
الخطوة الشائعة الأخرى هي إعادة بناء خط أنابيب البيانات. بنية SharePoint جديدة. تحويلات Power Query جديدة. أحيانًا مستودع بيانات مناسب. هذا هو القرار الصحيح في بعض الأحيان - لكنه مشروع يستغرق شهورًا طويلة ولا يعالج سبب عدم الثقة في التقرير الحالي. يمكن أن يكون لديك بيانات نظيفة تمامًا تغذي تقريرًا لا يزال يفشل في توجيه القرارات.
هناك أيضًا نمط يستحق التسمية: استبدال أداة Power BI بأداة مخصصة لإدارة المشاريع وحواسيبها، لينتهي الأمر بنفس مشاكل إعداد التقارير في واجهة جديدة. تتغير الأداة. أما الأسئلة الأساسية حول ما تحتاج القيادة إلى رؤيته بالفعل، وكيفية تدفق البيانات من المشاريع إلى المحفظة - فتبقى هذه الأسئلة دون حل.
بصراحة: لا يوجد حل سحري هنا. فمشاكل الإبلاغ عن الحافظة هي دائماً مشكلة بيانات جزئياً، ومشكلة عملية جزئياً، ومشكلة تصميم جزئياً. أي شخص يخبرك بخلاف ذلك فهو يبالغ في التبسيط. لكن طبقة التصميم عادةً ما تكون الأسرع في الإصلاح، ودائمًا ما يتم معالجتها في النهاية.
ما الذي يساعد في الواقع: تصميم القرار وليس البيانات
يتمثل الإطار الأكثر فائدة في البدء من الأسئلة الفعلية للجنة التوجيهية - الأشياء الثلاثة أو الأربعة التي يحتاجون إلى الخروج من الاجتماع بعد اتخاذ قرار بشأنها - والتصميم العكسي من هناك. ليس "ما هي البيانات التي لدينا" ولكن "ما الذي يحتاج مالك المحفظة إلى رؤيته لاتخاذ قرار بشأن برنامج مؤجل؟
في الممارسة العملية، يعني هذا عادةً فصلًا صارمًا بين العرض التنفيذي والعرض التشغيلي. وتحتاج الطبقة التوجيهية إلى تجميع على مستوى المحفظة: سلامة الجدول الزمني الإجمالي، والتعرض للميزانية حسب البرنامج، وإشارة واضحة حول المشاريع المرشحة للتصعيد. يجب أن تكون قابلة للقراءة في أقل من دقيقتين دون النقر على أي شيء. يمكن للطبقة التشغيلية - الطبقة التشغيلية - التي يستخدمها مديرو المشاريع وقادة البرامج بالفعل - أن تحمل التفاصيل. هذان جمهوران مختلفان لهما احتياجات مختلفة، ومحاولة خدمة كليهما في تقرير واحد هو ما يجعل معظم لوحات معلومات محفظة Power BI تخطئ في معظمها.
خيارات التصور مهمة أكثر مما تدركه معظم مكاتب إدارة المشاريع. إن حالة إشارة المرور الضوئية التي لا تُظهر الاتجاه - سواء كان المشروع قد تحول للتو إلى اللون الكهرماني أو ظل كهرمانيًا لمدة ستة أسابيع - أقل فائدة مما يبدو عليه. كما أن النظرة العامة للمراحل الرئيسية على غرار جانت التي تُظهر انحراف الجدول الزمني عبر المحفظة تنقل شيئًا لا يمكن لجدول التواريخ أن ينقله. إن اختيار الصورة المرئية ليس زخرفة؛ إنه الفرق بين التقرير الذي يحث على اتخاذ قرار والتقرير الذي يحث على طرح سؤال.
هذا هو المجال الذي تُحدث فيه مرئيات Power BI المصممة خصيصًا لسياقات إدارة المشاريع فرقًا حقيقيًا. تبني LeapLytics مرئيات مخصصة معتمدة خصيصًا لهذا الغرض - أشياء مثل مرئيات مخطط جانت البياني ومؤشرات إشارات المرور الضوئية المصممة لإعداد تقارير المحفظة، وليس إعادة توظيفها من حالات الاستخدام العامة لذكاء الأعمال. فهي لا تحل مشكلة نموذج البيانات أو مشكلة الحوكمة، ولكن عندما تكون البنية صحيحة، فإنها تجعل المخرجات أكثر وضوحًا إلى حد كبير للأشخاص الأكثر أهمية.
قبل وبعد: ما الذي يتغير عندما تعمل تقارير المحفظة بالفعل
وصل مكتب إدارة مشاريع بنية تحتية متوسط الحجم - حوالي 40 مشروعاً نشطاً في أربعة برامج - إلى مرحلة كانت تستغرق فيها المراجعة الشهرية لمحفظة مشاريعهم ثلاث ساعات بدلاً من تسعين دقيقة، ويرجع ذلك في الغالب إلى أن كل تقرير عن الحالة كان يستدعي مناقشة متابعة حول ما إذا كانت الأرقام حديثة. كان مديرو المشاريع يرسلون التحديثات عبر البريد الإلكتروني. وكان مكتب إدارة المشاريع يقوم بتحديث ملف Excel الرئيسي يدوياً. كان Power BI يقرأ من هذا الملف. كانت السلسلة تقدم أسبوعًا على الأقل من التأخير بين الواقع والتقرير.
اشتملت إعادة التصميم على ثلاثة أجزاء: عملية تقديم حالة موحدة مع تحديد يوم الجمعة كموعد نهائي ثابت يقرأه Power BI مباشرة، وفصل واضح بين مخطط تنفيذي واحد (RAG للمحفظة والمخاطر الخمسة الأولى وتباين الميزانية حسب البرنامج) وعرض تشغيلي على مستوى البرنامج، واستبدال مخطط شريطي عام مكدس بمخطط زمني مناسب للمراحل الرئيسية يُظهر انحراف الجدول الزمني في لمحة سريعة.
انخفض الاجتماع التوجيهي من ثلاث ساعات إلى سبعين دقيقة. والأهم من ذلك، توقف السؤال الافتتاحي عن كونه "هل يمكننا الوثوق بهذا؟" وأصبح "ماذا نفعل بشأن البرنامج ب؟ هذا التحول - من التحقق من صحة البيانات إلى اتخاذ القرارات - هو الهدف الفعلي. كل شيء آخر هو البنية التحتية.
وفقاً ل أبحاث معهد إدارة المشاريع حول فعالية مكتب إدارة المشاريع، فإن المؤسسات التي لديها عمليات ناضجة لإعداد تقارير المحفظة تنجز مشاريع أكثر بكثير في الوقت المحدد وفي حدود الميزانية. وليست التقارير في حد ذاتها هي السبب في ذلك - ولكن التقارير السيئة تخفي بشكل فعال الإشارات التي من شأنها أن تسمح بالتدخل المبكر.
من أين تبدأ
إذا كان تقرير محفظتك يولد نقاشات في الاجتماعات أكثر من القرارات التوجيهية، فإن أسرع تشخيص هو أن تسأل: ما الذي تقرره اللجنة التنفيذية بالفعل بناءً على هذا التقرير؟ إذا كانت الإجابة الصادقة هي "ليس الكثير"، فإن التقرير لا يؤدي وظيفته - بغض النظر عن مدى متانة بناء Power BI الأساسي من الناحية الفنية.
ابدأ من هنا. حدد القرارات الثلاثة التي تحتاج اللجنة التوجيهية إلى اتخاذها شهرياً. قم بالبناء بشكل عكسي. ثم اقلق بشأن المرئيات.
إذا كنت قد تجاوزت ذلك بالفعل وكان عنق الزجاجة هو طبقة Power BI نفسها، فإن مكتبة LeapLytics المرئية يستحق إلقاء نظرة - فهو مصمم خصيصًا لسياقات إعداد تقارير إدارة المشاريع، ومعتمد من Microsoft، ومتاح للتجربة مباشرةً. ابدأ الإصدار التجريبي المجاني هنا واختبارها مقابل بيانات محفظتك الفعلية.
