لماذا تموت مشاريع ERP في ترحيل البيانات — وكيف تكون واحدًا من الناجين؟

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

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

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

الكذبة التي يبدأ بها كل مشروع

كل مشروع ERP يبدأ بالجملة نفسها: «سننظف البيانات أثناء الترحيل». تقال بثقة كافية ليوافق عليها كل من في الغرفة. وبعد ستة أشهر يجلس الناس أنفسهم في الغرفة نفسها بوجوه مختلفة: خوف، وتبادل لوم، وإدراك متأخر أن كل حركة تزيد الغرق.

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

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

ثلاثة أنواع من البيانات تسقط المشروع

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

العلاج سؤال واحد قبل ترحيل أي شيء: لو اختفت هذه البيانات غدًا، هل ينتبه أحد؟ إن كان الجواب لا، فلا ترحلها. أرشفها.

بيانات الحاضر. سجلات عملاء مكررة: «Al-Rashid Trading» و«AlRashid Trading» و«Al Rashid Trading LLC». النظام القديم يعاملها ثلاثة عملاء، والمستخدمون يعرفون أنها عميل واحد، ولم يصلحها أحد لأن النظام «يعمل». ومخزون يظهر 100 قطعة في النظام و73 قطعة على الرف، والجميع يعرف أن الرقم غلط ولكل واحد طريقته في الالتفاف عليه.

المنطق هنا «سنصلحها في النظام الجديد». لن يحدث. النظام الجديد لن يعرف من تلقاء نفسه أن السجلات الثلاثة عميل واحد، ولن يجرد مخزونك بدلًا منك. تنظيف البيانات يسبق الترحيل. لا يرافقه ولا يتبعه.

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

العلاج ترتيب معكوس: احصر متطلبات النظام الجديد أولًا — كل حقل إلزامي وكل تصنيف مطلوب — ثم اسأل هل هذه البيانات موجودة اليوم أم يجب إنشاؤها.

سبعة أخطاء، كل واحد منها أسقط مشروعًا

هذه أخطاء متكررة لا نادرة، وكل واحد منها أنهى مشروعًا واحدًا على الأقل، وبعضها أنهى مشاريع كثيرة.

1. البدء متأخرًا. ترحيل البيانات ليس مرحلة، بل مسار متواز يبدأ في اليوم الأول وينتهي بعد التشغيل. الشركات التي تفشل تؤجله إلى «لاحقًا»، فيضيق الجدول وتؤخذ الاختصارات. تقييم البيانات يبدأ في الأسبوع الأول، لا بعد اعتماد المتطلبات.
2. تسليمه لقسم تقنية المعلومات وحده. التقنية تكتب البرامج وتنقل الملفات، لكنها لا تعرف هل «WIDGET-A» و«WIDGET-A-NEW» صنف واحد أم صنفان. هذا جواب من يعيش مع البيانات يوميًا. كل نطاق بيانات يحتاج مالكًا من العمل: الأصناف للعمليات، والعملاء للمبيعات، والموردون للمشتريات، ويملك هذا المالك التنظيف والربط والتحقق.
3. الترحيل دفعة واحدة. استخراج واحد وتحويل واحد وتحميل واحد، فإذا فشل لم يعرف أحد أين فشل. الصحيح موجات: البيانات الأساسية أولًا — الأصناف والعملاء والموردون ودليل الحسابات — ثم الأرصدة، أي المخزون والذمم المدينة والدائنة المفتوحة، ثم الحركات التاريخية عند الحاجة. كل موجة تعتمد قبل بدء التي بعدها.
4. تخطي المطابقة. شركات ترحل بياناتها ولا تتحقق من وصولها، وتفترض أن البرنامج ما دام قد عمل فالبيانات صحيحة. وبعد ثلاثة أشهر من التشغيل يكتشف أحدهم آلاف العملاء المفقودين، أو فرقًا في قيمة المخزون لا يفسره أحد، أو عشر سنوات من الحركات اختفت بلا أثر. طابق كل شيء: عدد السجلات، ومجموع القيم، حتى تثبت حسابيًا أن ما خرج من النظام القديم وصل إلى الجديد.
5. الترحيل بلا تجارب. أول تشغيل للترحيل يجب ألا يكون ليلة الانتقال. شركات اختبرت برامجها على عينة ولم تختبرها على كامل البيانات، فاكتشفت في الثانية صباحًا أن الترحيل يستغرق 47 ساعة لا 8 ساعات كما خططت. الحد الأدنى ثلاث تجارب كاملة ببيانات كاملة وتحقق كامل.
6. تجاهل الترابط. العملاء مرتبطون بالفواتير، والأصناف بقوائم المواد، وقوائم المواد بأوامر التشغيل. ترحيل الأصناف قبل جدول وحدات القياس يعطي أصنافًا بلا وحدة، وترحيل الفواتير قبل العملاء يعطي فواتير بلا عميل. جدول وحدات القياس يبدو أقل عناصر الترحيل أهمية، حتى يكون المصنع يسعر بالمتر ويشتري بالكيلوغرام، فيصير التحويل الذي يعتمد عليه كل سعر وكل رصيد وكل هامش في النظام الجديد. ارسم الترابط وحدد التسلسل قبل كتابة أول سطر ترحيل.
7. بلا خطة تراجع. سؤال «ماذا لو فشل الترحيل؟» جوابه المعتاد صمت، أو ما هو أسوأ: «لن يفشل». قد يفشل. الأنظمة تتعطل، والبرامج فيها أخطاء، والبيانات فيها مفاجآت. حدد خطة التراجع قبل خطة الترحيل، واعرف كيف تعيد تشغيل النظام القديم إن لم يعمل الجديد، ثم اختبر الخطة نفسها.

الإطار الذي ينجح

سبع مراحل بتواريخ، تبدأ في الأسبوع الأول من المشروع وتنتهي بعد التشغيل بشهر.

مخرج المرحلة الأولى هو الأهم، وقيمته في صدقه. تقرير تقييم البيانات الذي يجامل أحدًا لا يفيد، لأن كل قرار بعده — ما ينتقل وما يؤرشف وكم يستغرق التنظيف — مبني عليه.

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

الأرقام التي تدل على صحة الترحيل

الترحيل السليم يعرف بأرقام لا بانطباع فريق المشروع. هنا أحد عشر مؤشرًا تتابع أسبوعيًا، ولكل مؤشر حد يقول إنه سليم وحد آخر يستدعي التدخل قبل الوصول إلى يوم الانتقال.

السؤال الذي يسبق اجتماع اللجنة القادم

قبل تقرير الحالة القادم، اطرح على فريقك سؤالًا واحدًا: لو شغلنا النظام غدًا بالبيانات التي عندنا اليوم، ما الذي سينكسر؟

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

باختصار

سبب الوفاة المتكرر في مشاريع ERP ليس البرنامج ولا الميزانية. البيانات المتسخة تنتقل كما هي، فالتنظيف يسبق الترحيل ولا يرافقه.

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

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

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

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

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