نادرًا ما تفشل مشاريع ERP لأن البرنامج عاجز عن التعامل مع المحاسبة أو المخزون، بل تفشل لأنها تحاول استبدال كل شيء في اليوم الأول. فعملية الإطلاق الشاملة دفعة واحدة تطلب من كل الأقسام تغيير طريقة عملها في الأسبوع نفسه، وتكسر تكاملات لم يوثقها أحد، وتولّد مقاومة تدوم أطول من بقاء فريق التنفيذ. ومن واقع خبرتنا، فإن التبني، لا التقنية، هو السبب الأكثر شيوعًا للإخفاق.
يسلك نظام ERP المعياري طريقًا مختلفًا: ابدأ بمجال واحد، كالمالية أو المخزون، وأثبت قيمته مع مستخدمين حقيقيين، ثم توسّع. تتشارك الوحدات الهوية والبيانات الرئيسية والأعراف، لكن كل وحدة تُطلق وفق جدولها الخاص. فيتعلم الناس مجالًا واحدًا في كل مرة، وتدخل التكاملات الخدمة تدريجيًا، ويرى رعاة المشروع النتائج قبل الالتزام بالمرحلة التالية.
خطّط المراحل حول المشكلات الحقيقية
ينبغي أن تحل الوحدة الأولى مشكلة يشعر بها الناس كل يوم. فبالنسبة لشركة تجارية، قد تكون رؤية المخزون عبر المستودعات. وبالنسبة لمصنّع، قد تكون أوامر الإنتاج واستهلاك المواد. وبالنسبة لشبكة عيادات، قد تكون الفوترة والمستلزمات.
نوصي بتخطيط المراحل على هذا النحو:
- الاستكشاف مع من يؤدون العمل فعلًا. ارسم خريطة العملية الحالية، وجداول البيانات التي تُبقيها متماسكة، والتقارير التي يستخدمها المديرون فعلًا.
- إصدار أول محدود النطاق. وحدة واحدة، وموقع أو اثنان، وقائمة قصيرة بمسارات العمل الضرورية. أطلقه، وراقب استخدامه، وأصلح ما يزعج المستخدمين.
- التوسع حسب المجال أو حسب الموقع، لا الاثنين معًا. ولكل خطوة معايير قبول خاصة بها وخطة للتراجع.
- إيقاف الأجزاء القديمة بقرار مدروس، وذلك فقط بعد أن تعمل الوحدة الجديدة بالتوازي مدةً كافية لكسب الثقة.
ولأننا نُطلق تحديثات كل أسبوع، يرى المستخدمون ملاحظاتهم تتحول إلى تغييرات بسرعة. وهذا الإيقاع أهم للتبني من أي حفل إطلاق.
ارسم حدودًا واضحة للمجالات
المعيارية قرار معماري قبل أن تكون خطة تسليم، وهي تتطلب تصميمًا متعمدًا للحدود. فالمالية والمخزون والمشتريات والمبيعات والموارد البشرية والإنتاج سياقات محدودة (Bounded Contexts) منفصلة؛ يملك كلٌّ منها بياناته وقواعده، ويعرض للآخرين واجهات محددة بوضوح.
ويعني ذلك عمليًا:
- لا جداول مشتركة بين الوحدات. لا يكتب المخزون مباشرة في جداول المحاسبة، بل ينشر حدثًا أو يستدعي واجهة برمجية، وتسجّل المالية قيودها اليومية بنفسها.
- بيانات رئيسية مشتركة بمالك واحد. تُعرَّف المنتجات والعملاء والموردون ووحدات القياس مرة واحدة، وتتولى وحدة واحدة مسؤولية كلٍّ منها، ويُشار إليها في كل مكان آخر.
- عقود صريحة. تُرقَّم إصدارات الواجهات البرمجية والأحداث وتُوثَّق، كي لا يكسر تغيير في وحدة ما وحدةً أخرى بصمت.
ويمكن تحقيق ذلك ضمن تطبيق أحادي معياري جيد البنية (Modular Monolith)، دون الحاجة بالضرورة إلى خدمات مصغّرة. فبالنسبة لكثير من المؤسسات، يكون تطبيق واحد قابل للنشر مبني بـ ASP.NET Core أو Laravel، مع حدود داخلية صارمة بين الوحدات، أبسط تشغيلًا، ويظل من السهل تقسيمه لاحقًا عند الحاجة.
هوية واحدة وصلاحيات متسقة
لا شيء يُضعف الإطلاق المعياري أسرع من تسجيل دخول مختلف لكل وحدة. لذلك نصمم هوية مشتركة منذ الإصدار الأول: تسجيل دخول موحّد، ودليل مستخدمين واحد، ونموذج صلاحيات يفهم الهيكل التنظيمي (الشركة والفرع والقسم والمستودع) عبر جميع الوحدات.
ينبغي أن تعكس الأدوار المسؤوليات الحقيقية: أمين المستودع يرى المخزون وينقله داخل مستودعه، والمدير الإقليمي يعتمد التحويلات بين المواقع، والمالية تراجع التقييمات. وتعريف ذلك مرة واحدة يعني أن كل وحدة جديدة ترث نموذج وصول جاهزًا بدل أن تخترع نموذجها الخاص.
خطّط للترحيل بوصفه منتجًا لا مهمة
ترحيل البيانات هو المرحلة التي تخسر فيها مشاريع كثيرة أشهرًا. لذا تعامل معه جزءًا من المنتج:
- افحص البيانات القديمة مبكرًا؛ فالعملاء المكررون والوحدات غير المتسقة والرموز المفقودة أمر طبيعي، وتنظيفها يستغرق وقتًا.
- قرّر ما الذي سيُنقل من التاريخ. تُنقل عادةً الأرصدة المفتوحة والطلبات المفتوحة والمعاملات الحديثة، أما التاريخ الأقدم فمكانه غالبًا أرشيف للقراءة فقط لا النظام الجديد.
- اكتب نصوص ترحيل قابلة للتكرار، وشغّلها مرات عديدة في بيئات الاختبار قبل موعد التحويل.
- شغّل النظامين القديم والجديد بالتوازي لفترة محددة، مع تقارير مطابقة تقارن الأرصدة ومستويات المخزون.
- أبقِ التكاملات مع الأنظمة القديمة ما دامت مطلوبة، عبر محوّلات يمكن إزالتها لاحقًا بسهولة.
لوحات يفتحها الناس فعلًا
يرعى التنفيذيون مشاريع ERP لأنهم يريدون رؤية واضحة. فقدّم لهم عددًا قليلًا من المؤشرات المرتبطة بالقرارات، مثل تغطية المخزون أو الذمم المتأخرة أو تأخيرات الإنتاج، بدل جدران من المقاييس الاستعراضية. ويجب أن يكون كل رقم في اللوحة قابلًا للتتبع حتى المعاملات التي يستند إليها.
التبني مشكلة منتج
نادرًا ما تغيّر جلسات التدريب وحدها العادات. لذلك نستثمر في مسارات تعريف داخل التطبيق، ورسائل تحقق واضحة، وواجهات بالعربية والإنجليزية حيث تحتاج الفرق إلى اللغتين، وشاشات مصممة حول المهمة لا حول قاعدة البيانات. ونحرص أيضًا على أن يتولى شخص من جهة العميل مسؤولية كل وحدة، ويدافع عنها بين زملائه.
الهدف ليس نظام ERP يعمل من الناحية التقنية فحسب، بل نظام تختار الفرق استخدامه كل يوم لأنه يسهّل عملها. والتسليم المعياري والحدود الواضحة والهوية المشتركة والترحيل المدروس هي الطريق إلى ذلك.