٤ حالات يجب ان يتوقف فيها النظام ويسال

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

مثال من ارض العمل

منشاة توزيع مواد بناء تدير طلباتها من الواتساب. يرسل المندوب رسالة: اصرف ثلاثمئة كيس اسمنت لعميل مشروع الشمال على الحساب. النظام يفهم الطلب بلا لبس: الصنف معروف، والكمية واضحة، والعميل مسجل. لو نفذ مباشرة لبدا كل شيء سليما.

لكن رصيد هذا العميل غير المسدد تجاوز الحد الائتماني المتفق عليه في ملفه. هنا يجب ان يتوقف النظام، لا لانه لم يفهم، بل لان القرار ليس قراره. الرد الصحيح ليس رفضا صامتا ولا تنفيذا صامتا، بل رسالة الى صاحب الصلاحية: طلب صرف على الحساب لعميل تجاوز حده الائتماني، هذه الكمية وهذه القيمة، اعتمد او ارفض.

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

اربع حالات يجب ان يتوقف فيها النظام

ليست كل خطوة تحتاج موافقة، وكثرة الموافقات تقتل الفائدة كما يقتلها غيابها. هذه اربع حالات تستحق التوقف دائما:

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

كيف يبدو التوقف الجيد

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

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

الخطوة التلقائية تختصر الوقت، لكنها لا تتحمل المسؤولية. المسؤولية تبقى عند من يملك القرار، فاجعل النظام يوصلها اليه بدل ان ياخذها نيابة عنه.

قائمة تحقق قبل تفعيل اي خطوة تلقائية

• حددت ما الذي ينفذ مباشرة وما الذي يقف للاعتماد، مكتوبا لا مفهوما ضمنا.
• وضعت حدا رقميا واضحا للقيمة او الكمية التي تستدعي الاعتماد.
• عرفت من يعتمد، ومن يعتمد بدلا عنه عند غيابه، وخلال كم من الوقت.
• تاكدت ان رسالة الاعتماد تشرح السبب والاثر لا مجرد كلمة رفض.
• لكل خطوة نفذت اثر مسجل: من طلب، وماذا نفذ، ومتى، وباعتماد من.
• جربت الحالات الحدية عمدا قبل التشغيل، لا بعد ان تقع مع عميل حقيقي.

راجع الحدود بعد فترة تشغيل

الحدود التي تضعها اول يوم تقديرات، وبعد شهرين تصبح عندك بيانات. راجع سجل الاعتمادات: بند يعتمد دائما بلا نقاش يعني ان حده منخفض ويستحق التوسيع، وبند يرفض او يعدل كثيرا يعني ان القاعدة نفسها تحتاج مراجعة لا ان النظام مخطئ. بهذه المراجعة تتقلص الموافقات الشكلية وتبقى الحقيقية، وهذا هو الفرق بين نظام يساعد فريقك ونظام يزعجه. تنطبق نفس الفكرة على حركات المخزون من الواتساب، حيث الفرق بين خطوة مرجوعة واخرى مكلفة واضح تماما.