يبدأ تحديث الأنظمة القديمة بقرار عملي: ما الأجزاء التي ينبغي الاحتفاظ بها، وما الذي يحتاج إلى تحسين أو استبدال؟ قد يحتاج برنامج قديم يعمل بصورة موثوقة إلى صيانة محددة فقط. وفي المقابل، قد يتطلب برنامج أحدث تغييرًا كبيرًا إذا كان يعطل تطوير العمل أو يعتمد على مكونات انتهى دعمها.
هذا الدليل موجه للشركات التي تريد تقييم نظامها الحالي أو مقارنة عروض تحديثه. يساعد على تحديد انتقال يمكن اختباره وتمويله وتشغيله، دون افتراض أن إعادة البرمجة بالكامل أو الانتقال إلى السحابة أو شراء نظام ERP هو الحل المناسب تلقائيًا.
حدّد سبب التحديث بأدلة من العمل
اجمع أمثلة على ما يعجز النظام الحالي عن دعمه: تكامل مطلوب، مشكلة متكررة في مطابقة البيانات، إصدار يصعب اختباره، أو مكون لم يعد يتلقى إصلاحات أمنية. سجّل العملية المتأثرة وتكرار المشكلة والمسؤول عنها والحل اليدوي المستخدم حاليًا. افصل المشكلة المثبتة عن التحسين المرغوب.
اربط كل أولوية بنتيجة قابلة للقياس. مثلًا، احسب أوامر البيع التي يعيد الموظفون إدخالها في نظام آخر خلال فترة متفق عليها، ثم حدد هدفًا لمعالجة هذا التكرار. عبارة «استخدام تقنية حديثة» لا تحدد شرطًا لقبول المشروع.
قارن البدائل باستخدام العملية نفسها
تميّز Microsoft بين الاحتفاظ بالتطبيق، وإيقافه، وتغيير استضافته، ونقل منصته، وإعادة تنظيم شفرته، وإعادة بنائه. تختلف هذه التدخلات في نطاقها؛ فنقل الاستضافة لا يعادل إعادة تصميم سير العمل. راجع استراتيجيات تحديث التطبيقات.
استخدم المقارنة التالية كنقطة بداية، ثم اختبر ملاءمتها للنظام الفعلي.
| البديل | الدليل المطلوب قبل الموافقة | التكلفة أو القيد الذي يجب فحصه |
|---|---|---|
| الاحتفاظ بالنظام وتحسين استقراره | مكونات مدعومة وإصدارات قابلة للتكرار واستعادة مجرّبة | الصيانة المستمرة والقيود المتبقية |
| تحسين مكونات محددة | حدود واضحة للمشكلة واختبارات للسلوك الحالي | الارتباط بالأجزاء التي ستبقى |
| الاستبدال بنظام ERP أو منتج جاهز | عرض العمليات العادية والاستثنائية بالإعداد المقترح | التراخيص والإضافات والترقيات وتغييرات التشغيل |
| استبدال الوظائف تدريجيًا | انتقال قابل للتنفيذ بين المكونات القديمة والجديدة | التكاملات المؤقتة وتشغيل نظامين |
| استبدال التطبيق بالكامل | نطاق واضح وتجربة ترحيل وخطة توقف مقبولة | القواعد غير الموثقة ومخاطر الانتقال والتدريب |
قد يناسب تطبيق ERP العمليات القياسية، بينما تعالج البرمجة الخاصة متطلبات لا تدعمها المنتجات المتاحة بصورة مناسبة. قارن البديلين بالسيناريوهات نفسها، ولا تعِد بناء وظيفة معتادة لمجرد وجودها في التطبيق القديم.
جهّز قائمة يمكن للمورد التحقق منها
ارسم خريطة للتطبيقات وقواعد البيانات والملفات والمهام المجدولة والتصدير والخدمات المتصلة. أدرج أعمال الجداول الإلكترونية والتصحيحات اليدوية. تحقق من إتاحة مستودع الشفرة وإعدادات النشر والوثائق، ومن حقوق شركتك التعاقدية في تعديل كل مكون أو استبداله.
لكل تكامل، سجّل المسؤول عنه ومعرّفات السجلات والعمليات المسموح بها وطريقة معالجة الفشل. اطلب من المستخدمين الحالات التي قد تغيب عن العرض المعتاد: إلغاء أمر، تكرار استيراد، تعديل بعد الاعتماد، أو تغيير صلاحيات موظف. صنّف كل قاعدة إلى مطلوبة، أو لم تعد لازمة، أو تحتاج إلى قرار من مسؤول العمل.
استخدم أمثلة منزوعة البيانات الشخصية في المناقشات الأولى مع الموردين. لا تحتاج مناقشة النطاق الأولية إلى كلمات مرور الإنتاج أو قواعد بيانات العملاء.
اختبر إمكانية الاستبدال التدريجي
ينقل نمط Strangler Fig وظائف محددة إلى بديل جديد مع استمرار النظام القديم في بقية العمل. يحتاج إلى نقطة يمكن عندها توجيه الطلبات أو فصل العمل. وتوضح Microsoft أنه قد لا يناسب نظامًا بلا نقطة تكامل قابلة للتعديل، أو حالة تستلزم إيقاف النظام القديم سريعًا. راجع النمط وحدوده.
اطلب تحديد الحد الفعلي بين الجزء القديم والجديد. عبارة «سننقل وحدة بعد أخرى» غير كافية إذا كانت الوحدات كلها تكتب مباشرة في الجداول نفسها. ينبغي أن يوضح العرض المكونات التي يمكن تغييرها بصورة مستقلة، وأجزاء الربط المؤقتة، وشروط إزالتها لاحقًا.
مثال توضيحي: اعتماد أوامر البيع
لنفترض أن شركة تريد واجهة جديدة للاعتماد مع الاحتفاظ بنظام الفوترة الحالي. هذا مثال للتخطيط، وليس نتيجة مشروع نفذته تراود لعميل.
حدد مجموعة مستخدمين للتجربة وحالات الاعتماد والنظام الذي ينشئ المعرّف الأساسي للأمر. عيّن المسؤول عن تعديل كل حقل. عندما يكون ذلك عمليًا، اجعل لكل حقل أو معاملة جهة كتابة أساسية واحدة؛ وإذا كان النظامان سيكتبان، فاطلب تصميمًا واضحًا لحل التعارضات ومطابقة النتائج.
اختبر أمرًا معتمدًا وآخر مرفوضًا، وتعديلًا أثناء الاعتماد، وطلبًا مكررًا، وتعذر الوصول إلى خدمة الفوترة. يحتاج المستخدم إلى حالة معلّقة أو فاشلة واضحة وإجراء للاسترداد. نجاح الإرسال من الشاشة لا يثبت وحده تسجيل الأمر في النظام المستقبِل.
قبل التوسع، طابق السجلات المتفق عليها واختبر الصلاحيات مع مسؤول العملية. احتفظ بأدلة الاستثناءات والتصحيحات، وليس بإجماليات الحالات الناجحة فقط.
وضّح المقصود بالرجوع إلى النسخة السابقة
قد لا يؤدي إرجاع شفرة التطبيق إلى عكس تحويلات البيانات أو الإجراءات التي أُرسلت إلى نظام آخر. كما أن استعادة نسخة الأمس قد تفقد عملًا صحيحًا أُنجز اليوم. اطلب إجراءات منفصلة للتراجع عن إصدار التطبيق، وتصحيح البيانات، ومعالجة المعاملات الخارجية.
يجب أن تحدد خطة الانتقال موعد إيقاف التعديل، ونقل آخر التغييرات، وفحوص السماح بالإطلاق، وصاحب صلاحية التأجيل. جرّب الاستعادة والمطابقة ببيانات ممثلة للعمل. وضّح كيف يواصل الموظفون العمليات الأساسية أثناء التوقف وكيف تُدخل هذه العمليات بعده.
اطلب سجل قرار وتقديرًا كاملًا للتكلفة
اطلب من كل مورد توضيح البديل الموصى به، والبدائل المستبعدة، والأدلة الناقصة، وأول مخرج يساعد على حسم المجهول. افصل في التقدير بين التقييم والتنفيذ وتجهيز البيانات والتكاملات والبنية المؤقتة والتراخيص والتدريب والدعم. يجب إظهار جودة البيانات غير المعروفة والتكاملات غير الموثقة كافتراضات تحتاج إلى فحص.
اتفق على أدلة إيقاف النظام القديم: بيانات متطابقة، وتقارير تشغيلية، وقبول المستخدمين، وملكية الوصول، وترتيبات الدعم، وأرشيف قابل للاستخدام عند الحاجة. تحديد موعد للإطلاق لا يثبت تحقق هذه الشروط.
لمناقشة تقييم مع تراود، أرسل اسم نظامك الحالي وأهم قيد فيه والعملية التي تريد تحسينها عبر نموذج التواصل. ولتجهيز المشروع على نطاق أوسع، اقرأ دليل تخطيط التحول الرقمي.



