عندما يتوقف دعم أحد البرامج؛ تجربة في عملية ترحيل استغرقت عامين

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

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

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

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

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

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

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

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

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

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

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

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

الدرس الذي تعلمته من هذه التجربة

لم تكن هذه التجربة بالنسبة لي مجرد تجربة فنية. ومن أهم الدروس التي تعلمتها منها أن الشركة لا ينبغي أن تجعل نفسها رهينة لبرنامج واحد أو لجهة واحدة لتقديم الدعم.

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

البرنامج الذي يحتفظ لسنوات بالمعلومات الحيوية لشركة ما ليس مجرد أداة؛ بل هو جزء من البنية التحتية لذلك النشاط التجاري.

ولهذا السبب، أرى أنه عند اختيار برنامج أو تصميمه، يجب أن نطرح على أنفسنا سؤالًا مهمًا أيضًا:

إذا توقف دعم هذا البرنامج يومًا ما، فهل سنظل قادرين على الوصول إلى معلوماتنا ومواصلة أعمالنا؟

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