Skip to content
Smart Ideal Technology
Data Migration

كيف تنقل بيانات ERP دون فقد صف واحد (أو وظيفة واحدة)

دليل نقل بيانات ERP قابل للتكرار — تحليل وتحويل وتحميل وتسوية. مبني من عمليّات نقل حقيقية من Oracle وTally وFoxPro وExcel عبر مصر والسعودية.

نُشر 2026-05-06 · 7 دقيقة قراءة

نقل البيانات هو حيث تموت مشاريع ERP. المخطط والعرض التوضيحي وتدريب المستخدمين — كل هذا يسير بشكل جيد. ثم يشغّل أحدهم نقلًا تجريبيًا مساء الجمعة، ويوم الإثنين يكون تقرير أرصدة العملاء ينقصه 3% من المديونيّات. لديك الآن مشكلة سياسيّة لا تقنيّة فقط.

هكذا نُبقي نقل البيانات مُملًا.

مبدأ 1 — النقل بناء لا سكربت

سكربت SQL واحد يعطيك تحميلًا واحدًا متّسخًا. خط الأنابيب يعطيك تحميلات sandbox وبروفات وإطلاقًا حقيقيًا — بنفس الكود كل مرة. ابنِ خط الأنابيب كمنتج.

مبدأ 2 — التسوية جزء من التسليم

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

إن لم تستطع التسوية، فأنت لم تنقل. نسخت بايتات.

خط الأنابيب من 5 خطوات

خطوة 1 — التحليل

قبل أن تكتب أي تحويل، حلّل كل جدول مصدر:

  • عدد الصفوف لكل جدول، لكل قسم
  • معدلات Null لكل عمود
  • تعدّد القيم في الأعمدة الفئويّة
  • مدى التاريخ لكل عمود تاريخ
  • اكتشاف التكرار (نفس المفتاح، عدّة صفوف)
  • الصفوف "محذوفة منطقيًا" (علم محذوف، رمز حالة، إلخ)

هذه الخطوة مُملّة وقابلة للتجاوز، ولهذا تتجاوزها معظم عمليات النقل الفاشلة. لا تتجاوزها.

خطوة 2 — التحويل

طابق كل حقل مصدر مع حقل هدف. لكل واحد، وثّق:

  • موقع المصدر
  • تحويل النوع (نص → رقم، تغيير صيغة التاريخ، تحويل عملة)
  • قيمة افتراضية عندما يكون المصدر null
  • قاعدة التحقّق (يجب أن يكون من [س، ص، ع]، يطابق regex، يشير لصف أب موجود)

اجعل التحويلات idempotent. تشغيل التحويل مرتين على نفس الإدخال يجب أن يُنتج نفس الإخراج.

خطوة 3 — التحميل

ترتيب التحميل يهمّ بسبب المفاتيح الخارجية. حمّل دليل الحسابات قبل قيود اليوميّة. العملاء قبل الفواتير. الأصناف قبل أرصدة المخزون. نتبنّى افتراضيًّا 6 طبقات:

1. البيانات المرجعيّة (العملات، الدول، وحدات القياس)
2. البيانات الرئيسيّة (دليل الحسابات، العملاء، الموردين، الأصناف)
3. الأرصدة الافتتاحية (GL وAP وAR ومخزون)
4. البيانات المعاملاتية (الفواتير، الدفعات، تحرّكات المخزون)
5. البيانات المشتقّة (التوزيعات، التقييمات)
6. بيانات نافذة التحويل (آخر 24-48 ساعة من نشاط النظام القديم)

الطبقة 6 هي نافذة التحويل. نُجمّد النظام القديم مساء الجمعة، نشغّل الطبقة 6، ونفتح النظام الجديد صباح السبت.

خطوة 4 — التسوية

لكل وحدة محمّلة، شغّل تقرير تسوية:

  • GL. ميزان مراجعة من النظام الجديد مقابل القديم، حسب الحساب، حسب الفترة. التسامح: 0.01 من العملة الأساسية.
  • AR. أرصدة العملاء. إجمالي النظام الجديد لكل عميل = إجمالي القديم لكل عميل. التسامح: 0.
  • AP. نفس AR، للموردين.
  • المخزون. الكميّة المتاحة لكل صنف لكل مخزن. التسامح: 0.
  • حجوم البيع/الشراء. آخر 90 يومًا، شهريًا، لكلا النظامَين.

أي تباين يحصل على مالك مُسمّى وتفسير مكتوب. "لا ندري" ليست حلًّا مقبولًا. أكبر قاتلات المشاريع التي رأيتها بدأت كلها من تباين 0.3% قرّر أحدهم أنه "كافٍ". لا يكون كافيًا أبدًا.

خطوة 5 — التحويل

خطة التحويل ورقة دقيقة بالدقيقة. مثال حقيقي:

الجمعة 18:00 — يُغلق النظام القديم للمستخدمين النهائيّين
الجمعة 18:30 — تصدير الطبقة 6 الأخير من القديم
الجمعة 19:00 — تشغيل نقل الطبقة 6 في الهدف
الجمعة 21:00 — تقرير تسوية كامل
الجمعة 22:00 — اتّخاذ قرار Go / no-go
السبت 06:00 — فحوصات صحيّة
السبت 08:00 — فتح النظام الجديد للمستخدمين

كل تحويل يصل مع سكربت تراجع — أحيانًا "احذف المخطط وأعد استيراد لقطة النظام القديم"، أحيانًا "أعد DNS للخادم القديم". إن لم يتضمّن خطة تحويلك مسار تراجع، فالتحويل غير جاهز.

أخطاء النقل الشائعة

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

خطأ: استبعاد البيانات "القديمة". يمتدّ مدقّقو الضرائب في مصر والسعودية إلى 5+ سنوات للوراء. نقل "آخر 3 سنوات" فقط يخلق مشكلة تدقيق مستقبلية.

خطأ: التعامل مع التسوية كفحص نهائي. سوِّ بعد كل بروفة. اكتشاف خطأ تحويل في البروفة الثالثة رخيص. اكتشافه بعد 4 ساعات من الإطلاق يُغيّر المسار المهني.

خطأ: نقل بفرد واحد. الشخص الذي بنى خط الأنابيب لا يمكن أن يكون الوحيد الذي يعرفه. برمج ثنائيّ كحدٍّ أدنى.

خط الأنابيب المرجعي لدينا

أدواتنا الداخلية للنقل: Python (pandas + sqlalchemy) لمرحلة التحويل، Oracle/Postgres للتجهيز، ومُشغّل تسوية مخصّص يُنتج تقرير PDF متجاور. استخدمناها لنقل من Oracle Forms 6i وFoxPro وTally ودفاتر إكسل ونصف دزينة من قواعد Access مخصصة.

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