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