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