منهجية تنفيذ ERP في الشركات الكبرى والمجموعات القابضة

منهجية تنفيذ ERP في الشركات الكبرى والمجموعات القابضة

للشركات الكبرى والمجموعات القابضة.

صُممت هذه المنهجية للانتقال من SAP وOracle إلى 1C. كما تصلح للانتقال من أنظمة 1C القديمة إلى أنظمة أحدث (مثلًا من 1C:UPP إلى 1C:ERP).

*لا تناسب القطاع الحكومي ولا الأعمال الصغيرة.

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

يجب أن يلتزم كل مشروع بمواعيده وميزانيته ويحقق أهدافه.

هدف كل عميل هو

1) الانتقال إلى النظام الجديد في الموعد المحدد وضمن الميزانية،

2) الحفاظ على العمليات الرئيسية الحيوية للأعمال دون خسارة في الكفاءة،

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

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

المهام الرئيسية للمشروع:

المرحلة 1: التصميم.

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

- نمذجة هذه العمليات في النظام الجديد، أي أخذ مستندات وعمليات حقيقية ومحاولة إعادة إنتاجها في النظام الجديد. نعرض النموذج على العميل، وبناءً على النتائج نسجّل «الاختناقات» (الفجوات الوظيفية) التي تمنع النظام من العمل بشكل صحيح.

وعندما يلزم ترحيل البيانات من النظام القديم إلى الجديد، يجب الاتفاق على نطاق البيانات المراد ترحيلها وتطوير أدوات الترحيل.

المرحلة 2: التطوير.

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

المرحلة 3: التشغيل التجريبي.

مشكلة شائعة: انتهى التطوير وحُمّلت البيانات، لكن النظام لا يعمل بسبب أخطاء. ولهذا يلزم اختبار شامل.

نجري 3 أنواع من الاختبار:

الاختبار الداخلي: تشغيل كامل للنظام من البداية إلى النهاية داخل الشركة، بقيادة المعماريين التقني والوظيفي.

الاختبار الخارجي: التشغيل نفسه، لكن هذه المرة بالاشتراك مع العميل. وفي هذه المرحلة يستطيع العميل طلب إجراء تعديلات.

اختبار القبول: نعدّ حالات اختبار خطوة بخطوة، ويمرّ العميل بنفسه على العملية بأكملها للتحقق من عمل النظام.

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

المرحلة 4: التشغيل الفعلي.

ندعم المشروع دائمًا لمدة 3–6 أشهر بعد الإطلاق الفعلي، إلى أن يعتاد الموظفون على النظام.

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

لا يمكن ترك التنفيذ لفريق الجهة المنفّذة وحده. فعندما نبيّن نطاق العمل المشترك، فإننا في الواقع نضع القواعد التي يتوقف عليها نجاح المشروع. وفيما يلي جدول يوضح كيفية مشاركة موظفي العميل.

راعي المشروع يعتمد القرارات النهائية، ويخصص الميزانية، ويستلم المشروع ككل.

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

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

الخبير بالنظام الذي ننتقل منه. وهو أخصائي تقني يُعدّ البيانات في النظام الحالي لنقلها إلى النظام الجديد.

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

أثناء التنفيذ يجب أن نلتزم دائمًا بالجدول الزمني والميزانية. غير أن الناس يرغبون عادةً في أخذ نظامهم القديم، الذي جرى تخصيصه على مدى سنوات طويلة، ونقله بالكامل إلى النظام الجديد مع إضافة متطلبات جديدة في الوقت نفسه؛ أي أخذ 1C وتحويله إلى SAP. لكن لنكن واقعيين: لا يمكن في ستة أشهر أو سنة تحقيق ما استغرق بناؤه سنوات طويلة وميزانيات ضخمة. وفي مثل هذه الحالات تتجاوز تكاليف التخصيص الميزانية بمقدار 3–4 أضعاف.

فكيف نقرّر ما يجب فعله للبقاء ضمن الميزانية؟

إليكم كيف نحل هذا التعارض.

نقترح ترتيب جميع عمليات الأعمال بحسب مدى حرجيتها.

• عالية: عمليات من دونها «ينهار» عمل الشركة وتعجز عن مواصلة نشاطها.
• متوسطة: عمليات يؤدي غيابها إلى إبطاء العمل.
• منخفضة: قائمة الأمنيات وميزات الراحة والتحسينات المرغوبة.

تغطي الميزانية عادةً العمليات ذات الأولوية العالية وجزءًا من العمليات ذات الأولوية المتوسطة. أما البنود منخفضة الحرجية فتؤجَّل إلى مراحل لاحقة من تطوير النظام.

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

إذا حاولتم إنجاز كل شيء دفعة واحدة، فسيتعثر المشروع، ولن نلتزم بالجدول الزمني ولا بالميزانية.

ولهذا فإننا:

1. ننفّذ البنود ذات الأولوية العالية أولًا؛
2. ننجز البنود ذات الأولوية المتوسطة أثناء التشغيل الفعلي؛
3. ثم نواصل تحسين النظام لسنوات، بحسب الحاجة.

يمنح هذا النهج المرحلي أفضل فرصة لتحقيق النتيجة المرجوة.

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

دراسات حالة ERP