انتقل إلى المحتوى

إدارة أصحاب المصلحة في SAP: امنع الصراعات قبل أن تبدأ

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

شخصان من قطاع الأعمال يتصافحان بينما يصفق زملاؤهما خلفهما
المحتويات
  1. من المشاركون وما الذي يهمهم
  2. حدّد التوقعات قبل أن تظهر المشكلات
  3. صلاحيات القرار
  4. إيقاع التواصل
  5. خط أساس النطاق
  6. المشاركة حسب مرحلة SAP Activate
  7. كيف يغيّر RISE وGROW نموذج الحوكمة
  8. أين يفيد الذكاء الاصطناعي وأين لا يفيد
  9. التعامل مع المقاومة
  10. «نحتاج إلى هذا التخصيص»
  11. «لسنا جاهزين للتشغيل الفعلي»
  12. «لم يخبرنا أحد بهذا التغيير»
  13. حل الصراعات وسجلات القرارات
  14. علامات نجاح خطة المشاركة
  15. الأسئلة الشائعة

تحدد إدارة أصحاب المصلحة في SAP ما إذا كان البرنامج سينتهي في موعده أم سيقضي ربعه الأخير في الجدال. وهي تقوم على أربع عادات. ارسم خريطة لمن يهمّ أمرهم وما يهتم به كل طرف. اكتب من يملك صلاحية البتّ في ماذا. شغّل إيقاع تواصل يتوافق مع مرحلة SAP Activate. وسجّل كل قرار مهم مع بدائله. هذا الدليل موجّه إلى المديرين التنفيذيين للبرامج ومكاتب إدارة المشاريع (PMO) والرعاة التنفيذيين في برامج S/4HANA. استخدم جدول الأدوار وإيقاع التواصل لكل مرحلة أدناه لبناء خطة المشاركة قبل ورشة العمل الأولى.

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

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

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

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

الدورما يهمهكيف تُشركه
الراعي التنفيذي (الرئيس التنفيذي، رئيس العمليات، المدير المالي للمجموعة)العائد، ومخاطر الأعمال، ومصداقية البرنامجتواصل مباشر ومنتظم وموجز
اللجنة التوجيهية (مدير تقنية المعلومات، المدير المالي، رؤساء وحدات الأعمال)الجدول الزمني والميزانية والنطاقمراجعات توجيهية منظمة تنتج قرارات
قيادة المالية (المدير المالي، المراقبون الماليون)الاعتراف بالإيرادات، وسلامة التقارير، والضوابطإشراك مبكر في التصميم، وتوقيع نطاق FI/CO
قادة العمليات والأعمالاستمرارية العمليات، والتدريب، وسهولة الاستخدامورش التصميم، وملكية اختبار قبول المستخدم (UAT)
قيادة تقنية المعلومات (مدير تقنية المعلومات، رئيس الهندسة المعمارية)الهندسة المعمارية، والأمن، والتكامل، والدعمتوقيع التصميم التقني
مالكو عمليات الأعمالدقة العملية، والاستثناءات، والحالات الحدّيةقيادة ورش التصميم، وتوقيع التهيئة
المستخدمون النهائيونمنحنى التعلم، والعمل اليومي، وتغيّر الوظائفالتدريب وإدارة التغيير
شركة تكامل الأنظمة (SI)نطاق التسليم، وطلبات التغيير، وتوفير المواردحوكمة رسمية ووثائق النطاق
الموارد البشرية وإدارة التغييرأثر ذلك على الأفراد، وتغيّر الأدوار، والتواصلمسار عمل موازٍ للتسليم

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

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

أكثر أشكال المشاركة فاعلية تحدث قبل أن يشتكي أحد. ثبّت ثلاثة أمور عند الانطلاق.

صلاحيات القرار

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

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

إيقاع التواصل

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

خط أساس النطاق

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

تتغير احتياجات المشاركة مع انتقال البرنامج عبر مراحل SAP Activate. وما ينجح في Explore لا ينجح في Deploy. استخدم هذا كعمود فقري لخطة المشاركة:

المرحلةمحور المشاركةالإيقاعمن يقود
Discover وPrepareخريطة الأدوار، وهيكل الحوكمة، وإحاطات الراعي، وأولى جلسات المواءمة مع المالية والعمليات وتقنية المعلوماتإحاطة للراعي في البداية، وتشكيل اللجنة التوجيهيةالمدير التنفيذي للبرنامج
Exploreورش Fit-to-Standard مع قادة الأعمال ومالكي العمليات، ومراجعة قرارات الفجوات (Fit-Gap) قبل التوقيعجلسات عمل أسبوعية، واللجنة التوجيهية عند إغلاق المرحلةمهندس الحل ومالكو العمليات
Realizeالتحضير لـ UAT، وحماية وقت قادة الأعمال للاختبار، وحالة العيوب وترحيل البياناتاللجنة التوجيهية كل أسبوعين، وقادة مسارات العمل أسبوعياًمدير البرنامج
Deployالجاهزية للانتقال (Cutover)، والاتفاق على معايير المضي أو التوقف (go/no-go) قبل بدء الانتقالاجتماعات وقوف يومية للانتقال، وإحاطة تنفيذية لقرار المضي أو التوقفقائد عمليات الأعمال بدعم من تقنية المعلومات وشركة التكامل
Runالتواصل في فترة الدعم المكثف (Hypercare)، وقنوات المشكلات، ومراجعات الاستقراريومياً لأسبوعين ثم أسبوعياً، ومراجعات عند 30 و60 و90 يوماًقائد الدعم ومالكو العمليات

مرحلتان تسببان معظم المتاعب. في Explore، وجود الأشخاص الخطأ في الغرفة يعني أن القرارات تُفتح من جديد في Realize، بعد أن بدأت التهيئة. وفي Realize، من الأنماط الشائعة أن يكون مالكو UAT غير متاحين أو غير مستعدين. عالج ذلك في الخطة أثناء Explore، لا قبل أسبوعين من بدء الاختبار.

كان النموذج التقليدي يضم ثلاثة أطراف: العميل وشركة التكامل (SI) والرعاة. وفي RISE with SAP تنضم SAP بصفتها مشاركاً في التنفيذ. فهي تشغّل البنية التحتية والعمليات التقنية، ويتتبع فريق نجاح العملاء لديها التبني والقيمة. وينتج عن ذلك ثلاثة تغييرات في الحوكمة.

  1. منتدى لمراجعة الامتدادات. كل فجوة تحتاج إلى قرار: تهيئتها، أو توسيعها عبر واجهات برمجية مُصدَرة (على النظام نفسه (on-stack) باستخدام ABAP Cloud، أو جانبياً (side-by-side) على SAP BTP)، أو رفضها. في S/4HANA Cloud Public Edition لا يمكن تعديل النواة. وفي Private Edition يمكن ذلك، لكن كل تعديل يضيف عمل ترقية. ومنتدى صغير تحت اللجنة التوجيهية، فيه مهندس معماري واحد مخوّل بالقرار، يمنع وصول كل نقاش عن التخصيص إلى اللجنة التوجيهية. وإن تخطيته فسيظهر الدين التقني عند أول ترقية كبرى.
  2. إيقاع نجاح العملاء مع SAP. يتعامل فريق SAP مع التبني واستخدام BTP وخارطة الطريق. ويعمل بالتوازي مع حوكمة التنفيذ ويستمر بعد التشغيل الفعلي. ادمجه في حوكمتك بدلاً من تشغيله منفصلاً.
  3. مسار تصعيد إلى SAP. حين يفشل شيء على مستوى المنصة، يحتاج مدير تقنية المعلومات إلى أن يعرف بمن يتصل في SAP، لا في الشريك فقط. تأكد من جهات الاتصال ومستويات الخدمة قبل أن توقّع.

تحتاج برامج GROW with SAP على Public Edition إلى الثلاثة نفسها بوزن أخف: قرارات امتداد أقل لأن مجال التوسيع أضيق، وإيقاع نجاح أكثر توحيداً، وتصعيد يمر عادةً عبر الشريك أولاً. أما البرامج المحلية (on-premise) فتبقى على النموذج التقليدي، حيث تكون SAP مورّداً لا مشاركاً.

تساعد أدوات الذكاء الاصطناعي في الأعمال الورقية للمشاركة، لا في العلاقات.

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

سجلات القرارات في المرتبة الثانية. تستطيع ميزات الذكاء الاصطناعي في Confluence، وهي الآن تحت علامة Rovo من Atlassian، تحويل ملاحظات الاجتماعات إلى مدخلات منظمة في سجل القرارات متى بنيت قالباً.

صياغة المتطلبات تفيد في Explore. تستطيع SAP Cloud ALM صياغة المتطلبات من نصوص ورش Fit-to-Standard. ومع ذلك يحتاج كل سطر إلى شخص يتحقق منه.

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

الصراعات في برامج SAP لا تظهر من فراغ. إنها تنشأ من توقعات لم تُدَر. حدّد التوقعات مبكراً، وتواصل باستمرار، ووثّق كل قرار. والبديل أشهر من الجدال بأثر رجعي.

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

«نحتاج إلى هذا التخصيص»

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

«لسنا جاهزين للتشغيل الفعلي»

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

أشيع صوره: كشف UAT مشكلات لم تُعالج. المضي قدماً ينقل المشكلة من UAT إلى الإنتاج. وتأخير أسبوعين يكلف عادةً أقل بكثير من فترة دعم مكثف تُنفق على مشكلات كانت معروفة قبل التشغيل الفعلي.

«لم يخبرنا أحد بهذا التغيير»

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

حين يتجاوز الصراع مستوى العمل، يهم ثلاثة أمور.

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

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

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

إذا امتلأ بريد مدير البرنامج بحالات تصعيد عاجلة، فالخطة لا تعمل. البرامج السليمة تسير بقرارات منظمة لا بإطفاء حرائق يومي.

علامات صحية: اجتماعات اللجنة التوجيهية تنتج قرارات لا تأجيلات؛ وقادة الأعمال يحضرون الورش وUAT دون مطاردة؛ وتصل تغييرات النطاق عبر عملية التغيير؛ وتأتي مشكلات ما بعد التشغيل الفعلي عبر قنوات محددة؛ وسجل القرارات محدّث ويُرجَع إليه في اللجنة التوجيهية.

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

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

ما إدارة أصحاب المصلحة في تنفيذ SAP؟

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

تمس SAP المالية والموارد البشرية والمشتريات والعمليات وتقنية المعلومات في آن واحد، ولكل منها أولويات ونفوذ مختلفان. وإدارتهم كجمهور واحد تنتج تحديثات عامة وتفوّت الشواغل التي تدفع إلى المقاومة. وتدمج SAP Activate هذا في كل مرحلة: ورش Explore وملكية UAT في Realize ومراجعات الجاهزية في Deploy تعتمد كلها على مشاركين من الأعمال تم إعدادهم.

كيف تبني خريطة أدوار لمشروع SAP؟

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

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

ما الذي ينبغي أن تتضمنه خطة مشاركة SAP؟

سجل أدوار (الاسم والوظيفة والنفوذ والاهتمام والشواغل الرئيسية)، وخطة تواصل (القناة والتكرار والمحتوى لكل مجموعة)، وصلاحيات القرار لتغييرات النطاق وقرارات التصميم والجاهزية للتشغيل الفعلي، وأنشطة لكل مرحلة من Activate، ومسار تصعيد للقرارات المتنازع عليها، وطريقة لرفع الشواغل رسمياً.

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

كيف تدير مقاومة قادة الأعمال لـ SAP؟

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

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

كيف تعالج الصراعات بين المالية وتقنية المعلومات في برنامج SAP؟

تعود معظمها إلى واحد من ثلاثة توترات: الوصول مقابل الفصل بين المهام، ومرونة التقارير مقابل حوكمة البيانات، ووتيرة التكامل مقابل المراجعة الأمنية.

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

كيف يغيّر RISE with SAP إدارة أصحاب المصلحة؟

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

Noel D'Costa

بقلم

Noel D'Costa

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

الخطوة التالية

هل تدير برنامج ERP الآن؟

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