ليش بناءك كله واقف على عمود واحد؟ ايش بيصير بعد ما يروح سالم - العدد #10

Abdullah Alqarni

١٣ فبراير ٢٠٢٦

في كل شركة، فيه ذاك الموظف الـ "Superstar" أو ذاك النظام الـ "أساسي" اللي لو عطل دقيقة واحدة... البزنس كله يوقف.

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

سالم مو المشكلة، المشكلة هي إن البزنس بالكامل معتمد عليه، هذا بالضبط اللي نسميه "نقطة الانهيار" (Single Point of Failure - SPOF)، "نقطة الانهيار" هي أي جزء في نظامك (سواء كان موظف، نظام، عملية، أو حتى مورد) إذا فشل أو توقف، كل شي بعده ينهار. هذا هو التعريف الحرفي لـ "الهشاشة" (Fragility) في البزنس.

المشكلة مو في "البطل"، المشكلة في "التصميم"

الشركات كثير تقع في فخ "الاعتمادية" هذي لأنها أسهل على المدى القصير:

- نعتمد على مورد واحد لأنه أرخص.

- نخلي المعلومات كلها عند موظف واحد لأنه "الأسرع" و"الأشطر".

- نحط كل بياناتنا على سيرفر واحد عشان "نوفر" تكاليف.

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

الحل؟ "هندسة الفشل" (Failure Engineering)

هنا يجي دور التفكير العكسي. بدل ما نصمم عملياتنا على أمل إن "ما فيه شي بيخرب"، لازم ننتقل لـ "هندسة الفشل".

هندسة الفشل هي ببساطة: التصميم مع توقع الفشل.

هي العقلية اللي خلت شركات عملاقة زي نتفليكس وأمازون تبني أنظمة مستحيل (أو شبه مستحيل) تطيح. كيف؟ عن طريق تطبيق مبادئ بسيطة لكنها جذرية:

1. الازدواجية والتكرار (Redundancy): لا تحط بيضك كله في سلة واحدة

- بشرياً: لا تخلي المعرفة "حكر" على موظف واحد. لازم يكون فيه "Cross-Training" (تدريب متبادل). ولازم يكون فيه توثيق مستمر في "قاعدة معرفة" (Knowledge Base). إذا غاب الخبير، القاعدة موجودة.

- تقنياً: لا تعتمد على سيرفر واحد. استخدم "موازنة التحميل" (Load Balancing) اللي توزع الضغط على أكثر من سيرفر. إذا طاح واحد، الثاني يشيل الشغل عن السيرفر الى ان يضبط السيرفر الي طاح.

2. اللامركزية (Decentralization): فكك العقدة

- إذا كانت كل الموافقات لازم تمر على مدير واحد، هو صار "نقطة انهيار" (وبنفس الوقت "عنق زجاجة" يسبب بطء).

- الحل هو "تمكين الخطوط الأمامية" (Frontline Empowerment). عط صلاحيات، وزع المسؤوليات. لا تخلي العملية كلها مربوطة بشخص واحد أو قسم واحد.

3. المرونة (Resilience): خلك زي المطاط، لا تنكسر

- النظام المرن هو اللي إذا فشل جزء منه، ما ينهار كله. يقدر يكمل شغله حتى لو بكفاءة أقل.

- مثال: لو نظام الدفع الإلكتروني في متجرك تعطل، هل عندك خيار "الدفع عند الاستلام" كبديل مؤقت؟ أو هل المتجر كله يوقف؟ هذا هو الفرق بين تصميم "مرن" وتصميم "هش".