متى لا تستحق الأتمتة العناء

أربع حالات تكلّف فيها أتمتة المهمة أكثر من المهمة نفسها، والأسئلة التي ينبغي طرحها قبل أن تنفق المال لتكتشف ذلك بالطريقة الصعبة.

فريق سكايفول إيه آي

شجرة قرار بعنوان «Automate?» (هل نؤتمت؟) تتفرع إلى ثلاثة مسارات: نعم حين تكون القيمة واضحة والمهمة مستقرة، وليس بعد حين يكون الأمر غير مؤكد أو ما زالت هناك مشكلات في مرحلة سابقة، ولا حين تكون المهمة نادرة أو بسيطة أو قليلة الأثر.
شجرة قرار بعنوان «Automate?» (هل نؤتمت؟) تتفرع إلى ثلاثة مسارات: نعم حين تكون القيمة واضحة والمهمة مستقرة، وليس بعد حين يكون الأمر غير مؤكد أو ما زالت هناك مشكلات في مرحلة سابقة، ولا حين تكون المهمة نادرة أو بسيطة أو قليلة الأثر.

تفترض معظم الكتابات عن الأتمتة أن الإجابة نعم. وهذه المقالة لا تفترض ذلك.

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

وهذه هي الحالات الأربع التي نقول فيها عادةً: لا تفعل.

المهمة نادرة

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

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

الإجراء يتغير في كل مرة

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

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

لا أحد يستخدم المُخرَج

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

المشكلة الحقيقية في مرحلة سابقة

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

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

ما تتحقق منه قبل أن تلتزم

أربعة أسئلة، بهذا الترتيب:

  1. كم مرة تتكرر المهمة فعلًا؟ عدّها لأسبوع بدلًا من تقديرها.
  2. كم تكلّف المرة الواحدة؟ بالساعات، أو الأخطاء، أو الأشياء التي تصل متأخرة.
  3. هل الإجراء واحد في كل مرة؟ وإن لم يكن، فما الذي يحدد الاختلاف؟
  4. من يستخدم المُخرَج، وماذا يفعل به؟ سمِّ شخصًا بعينه.

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

لماذا نقول هذا للناس

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

تابع القراءة

لنبدأ

هل ترى هذا في عملياتك؟

أخبرنا عنه. لا حاجة لأن تحدد الحل مسبقًا، فهذا دورنا نحن.