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