لماذا لا يحلّ نقل نظام ERP إلى السحابة مشكلة عملياتك

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

إذا كان طلب الشراء اليوم يمرّ بثلاث موافقات عبر البريد، وورقة Excel موازية، ومكالمة هاتفية، فسيظل يمرّ بالمسار نفسه بعد النقل. الفرق أنه الآن يعمل على خوادم في فرانكفورت بدل آلة في القبو.

السحابة مكان، لا قرار يخصّ العمليات

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

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

لا شيء من هذا يتحسّن بتغيير الخادم. نظام ERP، محليًا كان أم سحابيًا، مرآة لعملياتك. إن كانت العملية مشوّشة، تردّ المرآة التشوّش نفسه، لكن بزمن تشغيل أفضل.

خطأ توثيق الوضع الحالي بكسل

يبدأ النقل المعتاد بتوثيق العمليات الحالية. الهدف المعلن هو "تكرار ما لدينا الآن". هنا يموت المشروع قبل أن يبدأ.

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

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

قبل ذلك بعشرين عامًا، سلكت Hershey الطريق المعاكس وفشلت بسبب التسرّع. أطلقت نظام ERP وإدارة العلاقات وإدارة سلسلة التوريد في الإنتاج معًا، قُبيل عيد الهالووين، دون وقت لتثبيت العمليات. عجزت عن شحن طلبات كانت موجودة في مستودعها. كان النقل مكتملًا تقنيًا، لكن التشغيل توقّف رغم ذلك.

ما يجب فعله قبل لمس السحابة

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

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

المقاومة الداخلية هي المشروع الحقيقي

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

الدراسات الكلاسيكية في إدارة التغيير متّسقة هنا. معظم برامج التحوّل لا تفشل بسبب التقنية. تفشل بسبب التنفيذ والمواءمة والتزام الناس. تلخّص HBR هذا جيدًا في عمل سيركين وكينان وجاكسون عن الجوانب الصعبة للتغيير.

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

إذن، هل تستحق السحابة العناء؟

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

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

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