تحديث نظام قديم دون إيقاف العمل: خطة انتقال عملية

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

ابدأ بتشخيص مكتوب لا بقرار#

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

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

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

ما الذي يجعل نظاماً قديماً خطراً#

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

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

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

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

التحديث على مراحل بدل الاستبدال الكامل#

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

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

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

هذا هو معنى «التسليم على دفعات» عملياً: كل دفعة تعمل في الإنتاج ويستخدمها الفريق ويقيس أثرها، لا نسخة تجريبية تُعرض في اجتماع. الدفعة التي لا يستخدمها أحد ليست تسليماً، وإن قُبلت رسمياً.

البيانات هي الجزء الأصعب#

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

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

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

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

التشغيل المتوازي وخطة التراجع#

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

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

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

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

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

ما تطلبه من المطوّر السابق#

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

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

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

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

أسئلة شائعة#

هل أحتاج إيقاف العمل يوماً كاملاً عند الانتقال؟#

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

ماذا لو كان النظام القديم بلا توثيق ولا تعليقات في الكود؟#

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

هل أنقل كل بياناتي التاريخية إلى النظام الجديد؟#

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

كيف أعرف أن التحديث نجح؟#

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

الخطوة التي تسبق أي عرض سعر#

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

إن أردت رأياً في حالتك تحديداً، لدينا استشارة مجانية لمدة ثلاثين دقيقة دون التزام نراجع فيها نظامك الحالي ونقول لك أين يستحق التحديث وأين لا يستحق.