لماذا تموت مشاريع ERP في ترحيل البيانات

هناك مقبرة أزورها من حين إلى آخر.

ليست تلك التي فيها شواهد وزهور. بل تلك التي فيها غرف خوادم وندم.

إنها المكان الذي تذهب إليه مشاريع ERP لتموت.

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

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

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

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

ترحيل البيانات.

ليس البرنامج. ولا الميزانية. ولا حتى مقاومة التغيير.

البيانات. القاتل الصامت.

الكذبة التي نقولها لأنفسنا

كل مشروع ERP يبدأ بالكذبة الجميلة نفسها:

«سننظّف البيانات أثناء الترحيل.»

سمعت هذه الجملة مئة مرة. وربما ألفًا. تُقال بثقة ويقين يجعلان كل من في الغرفة يومئ موافقًا.

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

وهذه هي الحقيقة التي لا يريد أحد سماعها:

لا يمكنك تنظيف نهر بأن تصبّه في كوب جديد.

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

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

الأشباح الثلاثة لترحيل البيانات

في سنوات عملي في تطبيق أنظمة ERP قابلت ثلاثة أشباح. تسكن كل مشروع ترحيل. وإلى أن تتعلّم رؤيتها، ستسكن مشروعك أنت أيضًا.

الشبح الأول: شبح البيانات الماضية

يعيش هذا الشبح في نظامك القديم.

هو سجل العميل الذي أُنشئ عام 2007 ولم يلمسه أحد منذ ذلك الحين. وهو كود الصنف الذي كان «مؤقتًا» وصار الآن محفورًا في خمسين تقريرًا. وهو المورّد الذي أفلس قبل خمس سنوات ولا يزال في قائمة مورّديك لأن أحدًا لم يجرؤ على حذفه.

همس شبح البيانات الماضية: «احتفظ بكل شيء. قد تحتاجه يومًا ما.»

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

طريقة طرده: قبل أن ترحّل أي شيء، اسأل سؤالًا واحدًا — «لو اختفت هذه البيانات غدًا، هل سيلاحظ أحد؟» إذا كانت الإجابة لا، فلا ترحّلها. أرشِفها. ودعها ترقد.

الشبح الثاني: شبح البيانات الحاضرة

هذا الشبح أمكر. يختبئ في وضح النهار.

هو سجلات العملاء المكرّرة — واحد مكتوب «الراشد للتجارة»، وآخر «الراشد التجارية»، وثالث «شركة الراشد للتجارة ذ.م.م». نظامك القديم تعامل معها كثلاثة عملاء مختلفين. مستخدموك كانوا يعرفون أنهم عميل واحد. ولم يصلحها أحد لأن النظام «كان يعمل».

وهو المخزون الذي يُظهر 100 قطعة في النظام و73 فقط على الرف. الجميع يعرف أن الرقم خاطئ. ولدى الجميع حلول التفافية. ولا أحد لديه وقت لإصلاحه.

همس شبح البيانات الحاضرة: «سنصلحه في النظام الجديد.»

لا. لن تفعل. لأن النظام الجديد لن يعرف بأعجوبة أن ثلاثة سجلات هي عميل واحد. ولن يجرد مخزونك الفعلي نيابة عنك. ولن يصحّح خطايا سنوات من الإهمال.

طريقة طرده: تنظيف البيانات يحدث قبل الترحيل، لا أثناءه. ولا بعده. قبله. وهذا غير قابل للتفاوض.

الشبح الثالث: شبح البيانات المستقبلية

هذا الشبح هو الأخطر، لأنه لم يوجد بعد.

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

همس شبح البيانات المستقبلية: «سنتدبّر أمره وقت الإطلاق.»

ثم يأتي الإطلاق. ولا يكون أحد قد تدبّر أمره. ويتحوّل النظام الذي وعد بالكفاءة إلى سجن من الحقول الإلزامية التي لا يعرف أحد كيف يملؤها.

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

خطايا الترحيل

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

الخطيئة الأولى: البدء متأخرًا

ترحيل البيانات ليس مرحلة. إنه مسار عمل متوازٍ يبدأ في اليوم الأول وينتهي بعد الإطلاق.

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

الطريق الصحيح: ابدأ تقييم البيانات في الأسبوع الأول. لا الأسبوع العاشر. ولا «بعد أن ننتهي من المتطلبات». الأسبوع الأول.

الخطيئة الثانية: تفويضه إلى تقنية المعلومات وحدها

ترحيل البيانات ليس مشروعًا تقنيًا. إنه مشروع أعمال له مكوّنات تقنية.

تستطيع تقنية المعلومات كتابة السكربتات. وتستطيع نقل الملفات. لكنها لا تستطيع أن تخبرك إن كان «WIDGET-A» و«WIDGET-A-NEW» هما المنتج نفسه. الأعمال وحدها تعرف. الأشخاص الذين يعيشون مع هذه البيانات كل يوم وحدهم يعرفون.

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

الخطيئة الثالثة: أسلوب الانفجار الكبير

بعض الشركات تحاول ترحيل كل شيء دفعة واحدة. استخراج ضخم واحد. وتحويل ضخم واحد. وتحميل ضخم واحد.

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

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

الخطيئة الرابعة: تخطّي المطابقة

رأيت شركات ترحّل بياناتها ولا تتحقق أبدًا من أنها وصلت صحيحة.

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

ثم بعد ثلاثة أشهر من الإطلاق، يكتشف أحدهم أن آلاف العملاء مفقودون. أو أن قيم المخزون تختلف بفارق لا يستطيع أحد تفسيره. أو أن عشر سنوات من تاريخ الحركات قد… تبخّرت ببساطة.

الطريق الصحيح: طابق كل شيء. أعداد السجلات الإجمالية. ومجاميع القيم. ومقارنات البصمة الرقمية. أيًّا كان ما يلزم لتثبت — رياضيًا وبما لا يُدحض — أن ما خرج من النظام القديم قد وصل إلى الجديد.

الخطيئة الخامسة: بلا تجارب مسبقة

أول مرة تشغّل فيها عملية الترحيل يجب ألا تكون عطلة الإطلاق.

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

الطريق الصحيح: ثلاث تجارب كاملة كحد أدنى. ببيانات كاملة. وتحقق كامل. كل تجربة تعلّمك شيئًا. وكل تجربة تجعل الترحيل الحقيقي أنعم.

الخطيئة السادسة: تجاهل ترابط البيانات

للبيانات علاقات. العملاء يرتبطون بالفواتير. والأصناف ترتبط بقوائم المكوّنات. وقوائم المكوّنات ترتبط بأوامر التشغيل.

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

الطريق الصحيح: ارسم الترابطات قبل أن تكتب سطرًا واحدًا من كود الترحيل. ابنِ تسلسلًا. والتزم به التزامًا لا تهاون فيه.

الخطيئة السابعة: بلا خطة تراجع

ماذا يحدث إذا فشل الترحيل؟

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

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

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

إطار عمل ترحيل ينجح فعلًا

كفى حديثًا عمّا يسوء. دعني أريك ما الذي يصحّ.

المرحلة الأولى: الاستكشاف (الأسابيع 1–4)

الهدف: أن تفهم ما لديك.

احصر كل مصادر البيانات (ليس نظام ERP الرئيسي فحسب — بل الجداول الإلكترونية وقواعد بيانات Access والسجلات الورقية والمعرفة غير المكتوبة)
قِس جودة البيانات (الاكتمال والدقة والاتساق والتكرار)
حدّد مالك البيانات لكل نطاق
وثّق مشكلات البيانات المعروفة

المُخرَج: تقرير تقييم البيانات — جرد صريح إلى حد القسوة لواقع بياناتك.

المرحلة الثانية: الاستراتيجية (الأسبوعان 5–6)

الهدف: أن تقرّر ما تُرحّله وكيف.

عرّف نطاق الترحيل (ما ينتقل، وما يُؤرشَف، وما يموت)
اختر أسلوب الترحيل حسب نوع البيانات (آلي، شبه آلي، يدوي)
ضع قواعد التنظيف ومنطق التحويل
ابنِ تسلسل الترحيل بناءً على الترابطات
عرّف إجراءات التحقق والمطابقة

المُخرَج: وثيقة استراتيجية ترحيل البيانات — خطة معركتك.

المرحلة الثالثة: التنظيف (الأسابيع 7–14)

الهدف: أن تصلح البيانات قبل أن تنقلها.

نفّذ أنشطة التنظيف حسب نطاق البيانات
ادمج المكرّرات
املأ الحقول المطلوبة الناقصة
وحّد الصيغ (الأسماء والعناوين والأكواد)
تحقّق من مطابقتها لقواعد العمل
احصل على اعتماد من مالكي البيانات

المُخرَج: بيانات نظيفة جاهزة للترحيل — شهد مالكوها بأنها صحيحة.

المرحلة الرابعة: البناء (الأسابيع 8–16)

الهدف: أن تبني آلة الترحيل.

طوّر روتينات الاستخراج
طوّر منطق التحويل
طوّر إجراءات التحميل
ابنِ تقارير المطابقة
أنشئ آلية معالجة الأخطاء وتسجيلها

المُخرَج: حقيبة أدوات ترحيل — مُختبَرة على عيّنة بيانات، وموثّقة، ومحفوظة تحت إدارة إصدارات.

المرحلة الخامسة: الاختبار (الأسابيع 14–20)

الهدف: أن تثبت أنها تعمل.

التجربة الأولى: استخراج وتحويل وتحميل كامل. توقّع إخفاقات. وتعلّم منها.
التجربة الثانية: ترحيل كامل مع مطابقة. قِس الزمن. وحدّد الاختناقات.
التجربة الثالثة: بروفة نهائية. ترحيل كامل يتبع إجراءات الإطلاق حرفيًا. وتحقّق كامل.

المُخرَج: عملية ترحيل مُثبَتة، بزمن موثّق ومطابقة مُتحقَّق منها ومشكلات مُغلَقة.

المرحلة السادسة: التحوّل (عطلة الإطلاق)

الهدف: أن تنفّذ بلا خطأ.

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

المُخرَج: بيانات مُرحَّلة — كاملة، ودقيقة، ومُطابَقة، ومُعتمَدة.

المرحلة السابعة: الرعاية المكثّفة (الأسابيع 1–4 بعد الإطلاق)

الهدف: أن تلتقط ما فاتك.

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

المُخرَج: بيئة بيانات مستقرة — وحكمة للترحيل القادم.

الأرقام التي تعني شيئًا

تريد أن تعرف إن كان ترحيلك سليمًا؟ تابع هذه المؤشرات:

المؤشر	ما الذي يخبرك به	سليم	يستدعي التحقيق
اكتمال الحقول الإلزامية، لكل كيان	هل يمكن تحميل البيانات أصلًا	98% فأكثر	أقل من 95%
نسبة التكرار في كل ملف رئيسي (عملاء، مورّدون، أصناف)	كم من تاريخك هو السجل نفسه محسوبًا مرتين	أقل من 1%	أكثر من 3%
فروق المطابقة على المجاميع الرقابية (ميزان المراجعة، الذمم المدينة، الذمم الدائنة، قيمة المخزون)	هل الأرقام في النظام الجديد هي الأرقام نفسها	صفر، حتى أصغر وحدة عملة	أي فرق يُفسَّر بأنه «تقريب»
نسبة الرفض في كل تحميل تجريبي	هل التنظيف يعمل فعلًا	تنخفض مع كل تحميل؛ وأقل من 0.5% في البروفة النهائية	ثابتة أو مرتفعة عبر التحميلات
نسبة إعادة العمل — سجلات صُحّحت مجددًا بعد اعتماد التنظيف	هل الاعتماد يعني شيئًا	أقل من 2%	أكثر من 10%، وهو ما يعني أن قواعدك خاطئة لا بياناتك
استهلاك قائمة الاستثناءات مقابل الخطة	هل سينتهي التنظيف قبل التحوّل	في حدود 10% من الخطة	أسبوعان متتاليان خلف الخطة
عدد التحميلات التجريبية بحجم كامل	هل يوم التحوّل بروفة أم تجربة	ثلاثة فأكثر	واحد أو لا شيء
زمن التحميل الإنتاجي مقابل نافذة التحوّل	هل يمكنك أن تنتهي قبل صباح الاثنين	60% من النافذة أو أقل	أكثر من 80% من النافذة
عيوب البيانات المفتوحة عند بوابة الإطلاق	هل البوابة قرار أم شكليات	لا عيب من الدرجة الأولى؛ وكل عيب من الدرجة الثانية له مالك وتاريخ	أي عيب من الدرجة الأولى مفتوح، أو عيوب أُعيد تصنيفها نزولًا في الأسبوع الأخير
الكيانات التي لها اعتماد مسمّى من الأعمال	من يملك البيانات بعد رحيل الاستشاريين	100% من الكيانات داخل النطاق	أي شيء اعتمدته تقنية المعلومات نيابة عن الأعمال
تذاكر البيانات لكل 100 مستخدم أسبوعيًا بعد الإطلاق	هل صمد الترحيل	تنخفض أسبوعًا بعد أسبوع ابتداءً من الأسبوع الثاني	ثابتة أو مرتفعة بعد الأسبوع الرابع

المحادثة التي تحتاج إلى إجرائها

قبل اجتماع لجنة التوجيه القادم، وقبل تقرير الحالة القادم، أجرِ هذه المحادثة مع فريقك:

«لو أطلقنا غدًا بالبيانات التي لدينا اليوم، ما الذي سينكسر؟»

اكتب الإجابات. كلها. لا تُصفِّ. ولا تهوّن.

الآن صار لديك سجل مخاطرك. وصارت لديك أولويات التنظيف. وصارت لديك الحقيقة.

والحقيقة، مهما كانت مؤلمة، هي الأساس الوحيد لترحيل ناجح.

قصة أخيرة

كان هناك رجل ورث مكتبة عن جدّه.

آلاف الكتب. عقود من الجمع. وكان الرجل ينتقل إلى بيت جديد فيه مكتبة جميلة حديثة — رفوف من زجاج وضوء، منظّمة بنظام محكم.

وكان أمامه خياران.

أن ينقل كل كتاب كما هو — مغبرًّا، غير مرتّب، بعضه تالف، وبعضه مكرّر، وبعضه بلغات لا يقرؤها.

أو أن يقضي وقتًا قبل النقل. ينظّف كل كتاب. ويقرّر أيّها يستحق مكانًا في المكتبة الجديدة. ويرمّم ما تلف. ويستبعد ما لا يُرمَّم.

الخيار الأول كان أسرع. والخيار الثاني كان أحكم.

فاختار الأحكم.

وحين وضع كتبه أخيرًا على تلك الرفوف الزجاجية، كان كل كتاب ينتمي إلى مكانه. وكان كل كتاب معروفًا. وكان كل كتاب محبوبًا.

ولم تكن مكتبته الجديدة موقعًا جديدًا فحسب. كانت بداية جديدة.

بياناتك هي مكتبتك.

ونظام ERP الجديد هو بيتك الجديد.

واختيارك لطريقة الترحيل هو اختيارك لنوع المستقبل الذي تبنيه.

فاختر بحكمة.

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

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