أخطر يوم في مشروعك ليس اليوم الأول — وكيف تنجو من التسعين يومًا الأولى
في تسلق الجبال النزول هو ما يقتل، لا الصعود. ومشاريع ERP تفشل بالطريقة نفسها: يحتفل الفريق بالتشغيل، ويرخي حذره، فتأخذ التسعون يومًا التالية المشروع.
· 11 دقيقة قراءة · بقلم فريق البحث والتحرير في Faceela
راجعه أحمد حسن الجمال — مستشار أنظمة المؤسسات · حدث في
في نيبال جبل يسميه المتسلقون "صانع الأرامل".
ليس الأعلى. ولا الأشد انحدارًا. ولا حتى الأشد بردًا.
لكنه يقتل من نسبة من يحاولونه أكثر مما تقتل قمم أعلى منه بكثير وأشهر منه بكثير.
والسبب؟ يبلغ المتسلقون القمة فيظنون أنهم انتصروا. يحتفلون. يسترخون. يلتقطون الصور بأيد مرتجفة من الفرح.
ثم يبدأون النزول.
منهكين، والأكسجين شحيح، والحذر مرخى.
وعندها يأخذهم الجبل.
اقرأ ما يكفي من روايات التسلق يصعب أن يفوتك النمط: الطريق نازلًا هو ما يقتل، لا الطريق صاعدًا.
اليوم الأشد فتكًا
ولمشروعك قمة أيضًا.
اسمها يوم التشغيل.
طوال شهور — وأحيانًا سنوات — والجميع يتسلق نحو هذه اللحظة. اعتماد الميزانية. اختيار المورد. جمع المتطلبات. الإعداد. الاختبار. التدريب. ترحيل البيانات.
ثم يجيء اليوم أخيرًا.
يطفأ النظام القديم. يشغل الجديد. يسكب الشمبانيا. ترسل الرسائل. تتصافح الإدارة. تلتقط الصور.
انتصار.
إلا أنه ليس كذلك.
لأن التشغيل ليس القمة.
التشغيل هو المخيم القاعدي للتسلق الحقيقي.
والتسعون يومًا التالية هي التي ستحدد إن كان مشروعك سيعيش أم سينضم إلى مقبرة التطبيقات الفاشلة.
الجزء الذي لا يوضع في دراسة الحالة
دعني أخبرك بما يتركه الموردون خارج الرواية.
يستطيع مشروع أن يشغل في موعده وداخل ميزانيته وعلى التصفيق، ثم لا يسلم شيئًا. رأيت هذا يحدث أكثر من مرة.
ولا يوجد رقم صادق عن نسبة حدوثه، وينبغي أن ترتاب فيمن يعطيك واحدًا. الدراسات التي تحصي فشل مشاريع ERP تحصيه عند التطبيق. ولا يكاد أحد يعود بعد سنتين ليسأل هل وصلت المنافع المكتوبة في دراسة الجدوى — وهو السؤال المهم، والسؤال الذي لا يدفع لأحد ليسأله. فخذ ما يلي بوصفه ملاحظة لا قياسًا.
هذه ليست مشاريع انهارت أثناء التطبيق. هذه مشاريع أطلقت. واحتفل بها. وصدرت عنها بيانات صحفية.
ثم فشلت، بهدوء وببطء وبألم.
كان النظام يعمل، لكن أحدًا لم يستخدمه كما ينبغي. ورحلت البيانات، لكن أحدًا لم يثق بها. وأعدت العمليات، لكن أحدًا لم يتبعها.
كان المشروع "مكتملًا". والتحول لم يحدث قط.
وديان الموت الأربعة
بين التشغيل والنجاح الحقيقي أربعة وديان. كل واحد منها يأخذ مشاريع. ولكل واحد أخطاره.
ولا بد أن تعبرها كلها لتصل إلى الجهة الأخرى.
الوادي الأول: وادي الفوضى (اليوم 1 إلى 14)
ما الذي يحدث:
كل شيء ينكسر. أو يبدو أنه ينكسر.
المستخدمون الذين بدوا متمكنين في التدريب ينسون كل شيء. والعمليات التي عملت تمامًا في الاختبار تفشل في الإنتاج. والبيانات التي "تم التحقق منها" تتبين خاطئة. وعمليات الربط التي اجتازت كل اختبار تنتهي مهلتها فجأة.
مكتب الدعم غارق. وفريق المشروع منهك. والإدارة التي كانت تحتفل الأسبوع الماضي صارت تسأل أسئلة محددة.
وهذا طبيعي.
أريدك أن تفهم هذا: الفوضى في الأسبوعين الأولين ليست فشلًا. هي فيزياء.
أنت أخذت مؤسسة تعرف كيف تعمل بطريقة وأجبرتها على العمل بطريقة أخرى. فبالطبع توجد فوضى. وكان سيكون ثمة خلل لو لم توجد.
ما الذي يقتل المشاريع في هذا الوادي:
- الذعر. القيادة تفقد ثقتها وتبدأ الكلام عن التراجع.
- اللوم. الفرق تنقلب على بعضها بدل حل المشكلات.
- التخلي. موارد المشروع الأساسية تسحب إلى "مهامها الطبيعية".
- الأنظمة الموازية. المستخدمون يعودون بهدوء إلى ملفات إكسل والأدوات القديمة.
كيف تنجو:
أولًا، توقعها. أبلغ القيادة قبل التشغيل: "الأسبوعان الأولان سيكونان صعبين. هذا طبيعي. وهكذا سنتعامل معه."
ثانيًا، أنشئ غرفة عمليات. مادية أو افتراضية. مكان واحد تصله المشكلات فتفرز وتحل. لا مشكلة أصغر من أن ترفع، ولا سؤال أغبى من أن يسأل.
ثالثًا، احم فريقك. من بنوا هذا النظام هم من يجب أن يسندوه. لا تدع أحدًا يسحبهم. "مهامهم الطبيعية" تستطيع الانتظار. هذه لا تستطيع.
رابعًا، تواصل بلا انقطاع. تحديث يومي للقيادة، وتحديث كل ساعة للمستخدمين إن لزم. الصمت يصنع الخوف، والمعلومة تصنع الثقة.
الوادي الثاني: وادي الشك (اليوم 15 إلى 45)
ما الذي يحدث:
تهدأ الفوضى الأولى. تستقر الأنظمة. يتوقف النزف.
لكن يجيء الآن ما هو أخبث: الشك.
يبدأ المستخدمون في المقارنة: "في النظام القديم كنت أفعل هذا بثلاث نقرات. الآن يحتاج سبعًا." ينسون إخفاقات النظام القديم، ويتذكرون راحاته وحدها.
وينظر المديرون إلى التقارير فيرون أرقامًا لا يعرفونها: "الإيراد يبدو أقل من الشهر الماضي. هل النظام غلط؟" لا — هو يحسب بطريقة مختلفة. لكنهم لا يعرفون ذلك. هم يرون مختلفًا فقط. والمختلف يحس خطأً.
انتهى شهر العسل. وحل واقع الحياة اليومية مع النظام الجديد. والواقع أقل بريقًا من العرض.
ما الذي يقتل المشاريع في هذا الوادي:
- انحياز المقارنة. كل جديد يقارن بالقديم في غير صالحه.
- انعدام الثقة في البيانات. المستخدمون يصدقون ملفاتهم لا النظام.
- الالتفافات. الناس يجدون طرقًا حول النظام بدل المرور به.
- نفاد صبر الإدارة. "أنفقنا كل هذا المال ولم يتحسن شيء بعد؟"
كيف تنجو:
أولًا، اصطد المكاسب السريعة. اعثر على شيء — أي شيء — أفضل فعلًا. أسرع. أسهل. أدق. وأعلنه. "انظروا إلى هذا التقرير الذي كان يستغرق ثلاثة أيام. صار فوريًا." المكاسب السريعة تعيد بناء الثقة.
ثانيًا، عالج المقارنة مباشرة: "نعم، بعض الأشياء صارت خطوات أكثر. وهذا هو السبب. وهذا ما نكسبه. وهكذا يسهل حين تتكون الذاكرة العضلية."
ثالثًا، اقتل الأنظمة الموازية بلا رحمة. في اللحظة التي ترى فيها ملفًا يكرر وظيفة موجودة في النظام، تدخل. افهم لماذا. أصلح الفجوة. لكن لا تسمح لنظام مواز بالبقاء. هي سرطان. والارتداد أسرع ما يكون حيث لا يقول النظام الحقيقة إلا إذا سجلت الحركة يوم وقوعها — ومصنع يغذي محلاته، حيث التحويل الذي يدخل متى وجد أحدهم وقتًا يجعل كل رقم مخزون بعده خاطئًا أوضح صورة لذلك.
رابعًا، أدر التوقعات إلى أعلى. ذكر الإدارة: "قلنا إن المنافع ستتحقق على مدى 12 إلى 18 شهرًا. نحن في الشهر الأول. وهذا هو المسار. وهذا ما نتتبعه."
الوادي الثالث: وادي الإنهاك (اليوم 46 إلى 75)
ما الذي يحدث:
فريق المشروع منهك.
ظلوا يعملون بطاقة 150 بالمئة شهورًا. فوتوا الإجازات. وفوتوا عشاء العائلة. وفوتوا النوم. وتماسكوا حتى التشغيل بالأدرينالين وحده.
والآن ذهب الأدرينالين. وهم متعبون.
وفي الوقت نفسه، المؤسسة متعبة أيضًا. متعبة من التغيير. متعبة من طلب المساعدة. متعبة من الإحساس بعدم الكفاءة. متعبة من المشروع الذي كان يفترض أن يحسن الأمور فلم يفعل سوى أن جعلها مختلفة.
الإنهاك هو القاتل الصامت.
لا يعلن عن نفسه. يتراكم فحسب. حتى يأتي يوم يستقيل فيه شخص مهم، أو يقع فيه خطأ حرج، أو يقرر الجميع جماعيًا، دون أن ينطق أحد بذلك، أن يكفوا عن بذل هذا الجهد.
ما الذي يقتل المشاريع في هذا الوادي:
- الاحتراق. أعضاء الفريق الأساسيون يرحلون، جسدًا أو ذهنًا.
- الارتداد. المستخدمون يكفون تدريجيًا عن اتباع العمليات الجديدة.
- إهمال الصيانة. المشكلات تتكدس لأن الجميع أتعب من أن يعالجها.
- فقدان الزخم. يتحول المشروع بهدوء من "تحول" إلى "مجرد إبقائه شغالًا".
كيف تنجو:
أولًا، دور فريقك. لا ينبغي لأحد أن يعمل ثمانين ساعة أسبوعيًا في الشهر الثاني. ضع ورديات. وافرض الإجازات. هذه ليست رأفة، هي استراتيجية. المنهكون يخطئون.
ثانيًا، احتفلوا بالنجاة. عبرتم الجزء الأصعب. اعترفوا بذلك. عشاء. أو مكافأة صغيرة. أو شكر صادق من القيادة. الناس يحتاجون أن يشعروا أن تضحيتهم رئيت.
ثالثًا، أضف الطابع الرسمي على الدعم. تصير غرفة العمليات مركز دعم. وتصير استجابة الأزمة مكتب خدمة. ويصير الأبطال فريقًا بساعات عمل طبيعية.
رابعًا، جدد التدريب. صرت الآن تعرف ما يتعثر فيه الناس فعلًا، لا ما ظننت أنهم سيتعثرون فيه. تدريب موجه على أوجاع حقيقية، لا عرض عام آخر.
الوادي الرابع: وادي النسيان (اليوم 76 إلى 90)
ما الذي يحدث:
النظام مستقر. والمشكلات قابلة للإدارة. والحياة تعود طبيعية.
وببطء لا يدرك، ينسى الناس لماذا فعلوا هذا.
تخفت الرؤية الاستراتيجية التي أطلقت المشروع. ويلهو الراعي التنفيذي بالمبادرة التالية. ويتفكك فريق المشروع. وتصير الاجتماعات الأسبوعية شهرية، والشهرية اختيارية.
النظام يعمل. لكن لا أحد يسأل هل يسلم ما وعد به.
وهذا أخطر الوديان كلها.
لأن الوديان السابقة تقتل المشاريع بصوت عال، وهذا يقتلها بصمت. لا تنتبه إلا بعد سنوات، حين يسأل أحدهم: "ما الذي حصلنا عليه فعلًا من ذلك الاستثمار؟" ولا يملك أحد إجابة جيدة.
ما الذي يقتل المشاريع في هذا الوادي:
- عمى النصر. "شغلنا. انتهينا." لا — أنت بدأت.
- التخلي عن القياس. المؤشرات المعرفة في دراسة الجدوى لا تتتبع أبدًا.
- تآكل القدرة. المعرفة تتركز في أشخاص قليلين يرحلون في النهاية.
- إهمال التحسين. النظام لا يضبط أبدًا. ولا يحسن. بل يصان فحسب.
كيف تنجو:
أولًا، حدد موعد مراجعة دراسة الجدوى. ضعها في التقويم الآن. اليوم 90. اليوم 180. اليوم 365. "لنراجع ما وعدنا به مقابل ما سلمناه." اجعلها لا مهرب منها. والمراجعة أسهل ما تكون حين تعيد تشغيل الحساب نفسه الذي بنيت عليه دراسة الجدوى، والنسخة الصادقة من ذلك الحساب — التي تضع فيها أنت نسبة المشكلة التي يزيلها النظام فعلًا، بدل أن يوردها لك المورد — هي بالضبط الافتراض الذي اختبرته لك التسعون يومًا الأولى.
ثانيًا، أسند الملكية. فريق المشروع يرحل. فمن يملك النظام الآن؟ ومن يسأل عن التحسين المستمر؟ ومن يراقب المؤشرات؟ سم الأسماء. ووزع المسؤوليات.
ثالثًا، ابن مجتمعًا. مستخدمون متقدمون. أنصار. مجتمع ممارسة يلتقي بانتظام لتبادل الحيل ورصد المشكلات وطلب التحسينات. النظام ينبغي أن يكون له مناصرون، لا مسؤولو تشغيل فقط.
رابعًا، خطط للموجة التالية. أفضل طريقة لمنع النسيان أن تظل تتقدم. "المرحلة الأولى استقرت. وهذه صورة المرحلة الثانية." الزخم حياة.
قائمة النجاة في تسعين يومًا
اطبعها. علقها على حائطك. راجعها أسبوعيًا.
ومعظم ما فيها كان ينبغي أن يتفق عليه قبل التوقيع. تغطية الرعاية المكثفة، وتعريف المشكلة الحرجة، ومن يدفع ثمن الشهر الرابع — كلها بنود عقد لا حسن نية، ولهذا موضعها عملية الاختيار والتعاقد لا مفاوضة تجريها والنظام متوقف.
الأسبوع 1 و2: إدارة الفوضى
☐ غرفة عمليات قائمة ومزودة بالناس
☐ عملية فرز المشكلات تعمل
☐ تحديث يومي للإدارة يحدث فعلًا
☐ المشكلات الحرجة تحل خلال 4 ساعات
☐ لا نقاش في التراجع (إلا في كارثة حقيقية)
☐ الأنظمة الموازية مثبطة فعليًا
الأسبوع 3 و4: الاستقرار
☐ حجم المشكلات ينخفض أسبوعًا بعد أسبوع
☐ لا مشكلة حرجة مفتوحة أقدم من 48 ساعة
☐ المستخدمون ينجزون الحركات الأساسية وحدهم
☐ تسوية البيانات مكتملة ومعتمدة
☐ عمليات الربط مستقرة 7 أيام متتالية فأكثر
☐ أول مكسب سريع مرصود ومعلن
الأسبوع 5 و6: التطبيع
☐ غرفة العمليات تتحول إلى نموذج دعم
☐ مكتب الدعم يعالج 80 بالمئة فأكثر من المشكلات دون تصعيد
☐ إجراءات التشغيل القياسية منجزة
☐ إقفال الفترة تم بنجاح
☐ فجوات التدريب مرصودة ومعالجة
☐ الأنظمة الموازية تزال فعليًا
الأسبوع 7 و8: التحسين
☐ اختناقات الأداء مرصودة ومعالجة
☐ ملاحظات المستخدمين مجموعة ومصنفة
☐ قائمة التحسينات مرتبة بالأولوية
☐ فريق الدعم انتقل بالكامل من فريق المشروع
☐ قاعدة المعرفة موثقة
☐ شبكة المستخدمين المتقدمين رسمية
الأسبوع 9 و10: القياس
☐ مؤشرات خط الأساس مسجلة
☐ الانحراف عن دراسة الجدوى موثق
☐ استبيان رضا المستخدمين أجري
☐ الالتزام بالعمليات مقيم
☐ مؤشرات جودة البيانات متتبعة
☐ عرض الإدارة جاهز
الأسبوع 11 و12: التسليم
☐ المشروع مغلق رسميًا
☐ الدروس المستفادة موثقة
☐ الملكية المستمرة مسندة
☐ عملية التحسين المستمر معرفة
☐ نطاق المرحلة الثانية مرسوم
☐ مراجعة دراسة الجدوى مجدولة (اليوم 180)
المؤشرات التي تهم بعد التشغيل
انس مؤشرات الزينة. تتبع هذه:
| المؤشر | كيف يقاس | المستهدف |
|---|---|---|
| حجم التذاكر | تذاكر مرفوعة لكل 100 مستخدم أسبوعيًا | انخفاض 50 بالمئة بنهاية الأسبوع 4، و80 بالمئة بنهاية الأسبوع 12 |
| تقادم التذاكر | نسبة التذاكر المفتوحة الأقدم من خمسة أيام عمل | أقل من 10 بالمئة طوال الرعاية المكثفة |
| الالتفافات الحية | العدد في سجل الالتفافات، لكل واحد مالك وتاريخ إغلاق | يبلغ ذروته في الأسبوع 2، ولا يبقى بلا مالك بعد الأسبوع 6 |
| الارتداد إلى الملفات | عدد الملفات الموازية التي تؤدي عملًا يفترض أن يؤديه النظام | ينخفض كل أسبوعين، وكل واحد يقتل أو يستوعب خلال 30 يومًا |
| المستخدمون النشطون مقابل الرخص | مستخدمون متمايزون سجلوا حركة في آخر سبعة أيام | 90 بالمئة فأكثر بحلول الأسبوع 6 |
| تأخر الحركة في العمل لا في الخادم | ساعات من الحدث إلى التسجيل: من استلام البضاعة إلى قيد الاستلام، ومن التسليم إلى الفاتورة | يعود إلى أرقام ما قبل التشغيل بحلول الأسبوع 8 |
| مدة الإقفال الشهري | أيام العمل من نهاية الفترة إلى إقفال معتمد | أول إقفال لا يزيد عن 1.5 ضعف القديم، والثالث عنده أو أقل |
| نسبة أخطاء البيانات الأساسية | تصحيحات في سجلات العملاء والموردين والأصناف لكل 1,000 حركة | أقل من 5، وفي انخفاض |
| القيود اليدوية | قيود تسجل يدويًا لتصحيح ما أنتجه النظام | تنخفض شهرًا بعد شهر، وأي متكرر منها يعاد تصنيفه عيبًا في الإعداد |
| دقة المخزون | انحراف الجرد الدوري بالقيمة مقابل رقم النظام | ضمن 2 بالمئة بحلول الأسبوع 8 |
| خط الأساس التشغيلي | مقياس التسليم في الموعد أو تلبية الطلب نفسه الذي استخدمته قبل التشغيل، بلا تغيير | يعود إلى خط الأساس بحلول الأسبوع 6 |
| الثقة في التقارير | نسبة تقارير الإدارة المأخوذة من النظام بدل إعادة بنائها خارجه | 100 بالمئة بحلول الشهر 3 |
| الاعتماد على شخص بعينه | نسبة التذاكر التي لا يحلها إلا شخص واحد مسمى | أقل من 20 بالمئة بحلول الأسبوع 8 |
| تحقق المنافع | الرقمان أو الثلاثة في دراسة الجدوى، مقيسة في التواريخ التي وعدت بها | مراجعة رسمية في اليوم 90 واليوم 180 |
قصة مصنعين
دعني أخبرك عن مصنعين. كلاهما في الإمارات. كلاهما طبق النظام نفسه. وكلاهما شغل في الشهر نفسه.
المصنع الأول احتفل بالتشغيل بحفلة. ورقي مدير المشروع. وتفكك الفريق. وعاد الجميع إلى "وظائفهم الحقيقية". وحين ظهرت المشكلات لم يكن ثمة من يحلها. وحين تعثر المستخدمون لم يكن ثمة من يساعدهم. وبحلول الشهر الثالث كان نصف المستودع يعمل على ملفات إكسل من جديد. وبحلول الشهر السادس كان المدير المالي يسأل هل ينبغي أن ينتقلوا إلى نظام آخر.
المصنع الثاني احتفل بالتشغيل باجتماع. وجدول أعماله: "ماذا يحدث الآن؟" خططوا للتسعين يومًا التالية ساعة بساعة. وأبقوا غرفة العمليات مفتوحة ثلاثة أسابيع. وجدولوا اجتماعًا يوميًا قصيرًا لشهر، ثم أسبوعيًا لشهرين. وتتبعوا ثلاثة وعشرين مؤشرًا. واستطلعوا المستخدمين كل أسبوعين. وقتلوا أربعة ملفات موازية في الأسبوع الثالث. ووجدوا خطأً في التكلفة في الأسبوع الرابع وأصلحوه، وكان سيكلفهم الملايين. وبحلول الشهر السادس كانوا قد حققوا 80 بالمئة من المنافع المتوقعة.
البرنامج نفسه. البلد نفسه. القطاع نفسه.
ونتيجتان مختلفتان.
والفارق لم يكن الموهبة، ولا الميزانية، ولا الحظ.
الفارق كان الاحترام.
عامل الأول التشغيل على أنه النهاية. وعامله الثاني على أنه البداية.
السؤال الذي لا يسأله أحد
حين تخطط للتشغيل، يسأل الجميع: "هل نحن جاهزون للتشغيل؟"
ولا أحد يسأل السؤال الأهم:
"هل نحن جاهزون لليوم التالي للتشغيل؟"
هل هياكل الدعم قائمة؟ هل مسارات التصعيد معرفة؟ هل المؤشرات تتتبع؟ هل قادتك مهيأون لوادي الفوضى؟ هل مستخدموك مهيأون لأن تكون الأمور صعبة قبل أن تسهل؟
إن لم تستطع أن تجيب بنعم عن كل هذه، فأنت لست جاهزًا للتشغيل.
لا لأن نظامك غير معد.
بل لأن مؤسستك غير مهيأة لما يأتي بعده.
وعد التسعين يومًا
أطلب من كل عميل أن يقطع وعدًا قبل التشغيل.
لا لي. لنفسه.
"لن نحكم على هذا المشروع قبل اليوم التسعين."
لا اليوم الأول، حين يكون كل شيء فوضى. ولا اليوم الثلاثين، حين يتسلل الشك. ولا اليوم الستين، حين يحل الإنهاك.
اليوم التسعون. حين يهدأ الغبار. وحين تستقر العمليات. وحين يصير المسار الحقيقي مرئيًا.
تسعون يومًا من الصبر. تسعون يومًا من الالتزام. تسعون يومًا من العمل الشاق على التبني الحقيقي.
هذا هو ثمن التحول.
ولا طرق مختصرة إليه.
الدرس الأخير
ثمة قول تعلمته من مدير مشاريع قديم، رجل رأى من عمليات التشغيل أكثر مما سأرى.
قال:
"حفل التشغيل ليس الزفاف. هو الخطوبة. الزواج الحقيقي يحدث في الشهور التالية — حين تتعلمان العيش معًا."
نظامك ليس مشروعك.
نظامك شريكك.
وكأي شراكة، سيحتاج صبرًا في الأيام الأولى، وتفهمًا في اللحظات الصعبة، والتزامًا حين يكون الانصراف أسهل.
المشاريع التي تزدهر ليست صاحبة أفضل البرمجيات.
بل التي ظلت حاضرة. التي واصلت العمل. التي رفضت التخلي عن العلاقة حين صعبت.
وهذا هو الفرق بين نظام يعمل ونظام يحول.
إن كان في تقويمك موعد تشغيل وليس عندك إجابة مكتوبة عن من يملك التسعين يومًا الأولى، فتلك فجوة تستحق الإغلاق الآن لا في الأسبوع الثاني. وهكذا نقسم تطبيق ERP على مراحل: مالكون بالاسم قبل الإعداد، وكل مرحلة صالحة للاستخدام وحدها. أما التسعون يومًا نفسها فليست عمل تنفيذ أصلًا — لا شيء فيها إعداد — ولهذا تسعّر ويوظف لها بوصفها عمل التغيير الذي هي إياه، ويقوم بها من سيبقى موجودًا في الشهر الرابع. وإن كان الموعد نفسه لم يحدد بعد، فالتقدير الذي يستحق البناء عليه يبدأ من كم يستغرق التنفيذ فعلًا وما الذي يطيله.