نظام الخطوات الخمس: كيف تبني وتدير مشروعك بناءً على الواقع الميداني

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

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

الخلاصة

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

لماذا توقفت عن البدء بالبرنامج

عندما يقول لي أحدهم إن شركته تحتاج نظاماً جديداً، لا يكون سؤالي الأول «أي نظام؟». سؤالي الأول هو: «ماذا يحدث فعلاً هنا؟».

نادراً ما يطابق الجواب الطلب. الشركة التي تطلب نظام CRM لديها في الغالب مشكلة في متابعة الزبائن، لا مشكلة في البرمجيات. والفريق الذي يطلب نظام ERP لديه في الغالب ثلاثة أشخاص يحتفظ كل واحد منهم بنسخة مختلفة من رقم المخزون نفسه. وصاحب المشروع الذي يطلب الأتمتة لديه في الغالب طريقة عمل لم يكتبها أحد قط، فلا يوجد بعد شيء ثابت يمكن أتمتته.

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

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

ماذا يعني التفكير المنظومي للمشاريع

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

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

عملياً، يطرح التفكير المنظومي للمشاريع خمسة أنواع من الأسئلة:

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

لا يتحدث أي من هذه الأسئلة عن البرمجيات، وهذا مقصود. البرنامج جواب محتمل، لكنه ليس السؤال الأول أبداً.

الخطوات الخمس في لمحة

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

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

الخطوة الأولى: أفهم

الخطوة الأولى هي التي يريد الجميع القفز فوقها لأنها تبدو بطيئة. لكنها في التفكير المنظومي للمشاريع الخطوة التي توفر أكبر قدر من الوقت.

لكي أفهم مشروعاً، أذهب إلى حيث يُنجز العمل. أجلس مع من يقومون بالعمل قبل أن أفتح الحاسوب. أتتبع طلبية واحدة أو عملية تسليم واحدة أو فاتورة واحدة من بدايتها إلى نهايتها. وأطلب رؤية الوثائق الحقيقية: دفتر الحارس عند المدخل، وملف إكسيل على حاسوب المحاسب، ومجموعة واتساب التي يؤكد فيها السائقون عمليات التسليم.

بعض العادات تجعل هذه الخطوة مثمرة:

• تتبع حالة واحدة من البداية إلى النهاية. طلبية حقيقية واحدة، تتبعها من يد إلى يد، تعلمك أكثر من عشر مقابلات عن طريقة العمل بشكل عام.
• العدّ. كم طلبية في اليوم، وكم تصحيحاً في الأسبوع، وكم دقيقة لكل مهمة. الرقم التقريبي أفضل من الصفة الواثقة.
• السؤال عما يحدث حين يسوء الأمر. كل طريقة عمل تبدو نظيفة حين تشتغل. المهم هو الاستثناء: المرتجع، والوثيقة الناقصة، والزميل الغائب.
• الانتباه إلى الحلول الالتفافية. حين يقول أحدهم «عادة نفعل هكذا، لكن»، فإن طريقة العمل الحقيقية تبدأ بعد كلمة «لكن».

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

الخطوة الثانية: أنظّم

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

أرسم أربعة أشياء:

1. المسارات. من يفعل ماذا، وبأي ترتيب، وما الحدث الذي يطلق كل خطوة.
2. البيانات. المعلومات التي تحتاجها كل خطوة، والمعلومات التي تنتجها، والمكان الذي توجد فيه.
3. الترابطات. الخطوات التي لا يمكن أن تبدأ قبل انتهاء خطوة أخرى، والأشخاص أو الأدوات التي يعتمد عليها كل شيء.
4. نقاط الخلل. أين يتعطل التدفق، وكم مرة، وكم يكلف ذلك.

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

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

الخطوة الثالثة: أبني

الآن فقط أقرر ما الذي يجب أن يوجد. أحياناً يكون برنامجاً. وفي أحيان كثيرة يكون شيئاً أبسط: دوراً واضحاً، أو قائمة مشتركة واحدة، أو قاعدة تحدد من يؤكد التسليم، أو استمارة تعوض ثلاث مكالمات هاتفية.

مبدآن يقودان هذه الخطوة.

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

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

في هذه الخطوة أيضاً يحمي التفكير المنظومي للمشاريع الميزانية. فبما أن الخطوتين الأوليين حددتا المشكلة الحقيقية، يصبح للبناء حد واضح. والطلبات التي لا تخدم التدفق المحدد يمكن تأجيلها دون شعور بالذنب.

الخطوة الرابعة: أشغّل

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

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

بعض القواعد لهذه الخطوة:

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

الخطوة الخامسة: أطوّر

الخطوة الأخيرة تغلق الحلقة. أغيّر ما تشير إليه النتائج، ولا شيء غير ذلك.

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

تصف دورة ديمنغ (خطط، نفّذ، تحقق، صحّح) الانضباط نفسه. المهم هو الترتيب: تتحقق قبل أن تتصرف، وتتصرف بناءً على ما تحققت منه.

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

كيف تدور الخطوات الخمس في الواقع

على الورق، تأتي الخطوات واحدة بعد الأخرى. في الواقع، تتداخل وتتكرر بمستويات مختلفة.

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

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

مثال توضيحي: الشركة التي طلبت نظام CRM

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

شركة توزيع لديها حوالي اثني عشر مندوب مبيعات تطلب نظام CRM لأن «الزبائن لا تتم متابعتهم». الطلب واضح والحل يبدو بديهياً.

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

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

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

أشغّل. طيلة أربعة أسابيع، يستعمل الفريق القائمة في كل زيارة حقيقية. يلاحظ المسؤول أن مندوبين اثنين يملآن دفتريهما أولاً ثم القائمة لاحقاً، فتتأخر القائمة دائماً بيوم.

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

المشروع الذي بدأ بعبارة «نحتاج نظام CRM» أصبح «المبيعات والمحاسبة يجب أن تريا الزبون نفسه». واختيار البرنامج صار تفصيلاً. هذا بالضبط ما يصلح له التفكير المنظومي للمشاريع.

المخاطر التي يقلصها التفكير المنظومي للمشاريع

أقدم هذه المنهجية كوسيلة لتقليص المخاطر، لأن كل خطوة تزيل خطراً محدداً.

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

لا يختفي أي من هذه المخاطر تماماً. لكن كل خطر يصبح مرئياً مبكراً، حين تكون كلفة معالجته ما تزال صغيرة.

كيف تبدأ هذا الأسبوع

لا تحتاج إلى مستشار ولا إلى برنامج لكي تجرب هذه المنهجية. يكفيك أسبوع واحد ودفتر.

1. اختر تدفقاً واحداً يزعجك. الطلبيات، أو التحصيل، أو التسليم. واحد فقط.
2. تتبع حالة حقيقية واحدة. من أول اتصال إلى آخر وثيقة، ودوّن كل يد تمر بها وكل معلومة تحتاجها.
3. اكتب قائمة الترابطات. من ينتظر من؟ وما الملف أو الشخص الذي يتوقف كل شيء إذا غاب؟
4. حدد نقطة خلل واحدة. اختر المكان الذي يتعطل فيه التدفق أكثر من غيره، واحسب كم مرة حدث ذلك هذا الشهر.
5. جرّب تغييراً صغيراً واحداً. قاعدة جديدة، أو قائمة مشتركة، أو دور واضح، ثم راقب النتيجة أسبوعين قبل أن تضيف أي شيء آخر.

إذا وجدت بعد هذا الأسبوع أن المشكلة ليست حيث كنت تظن، فقد بدأ التفكير المنظومي للمشاريع يؤدي عمله. وإذا تبين أن الحل يحتاج فعلاً إلى برنامج، فستعرف الآن بدقة ما الذي يجب أن يفعله ذلك البرنامج، وما الذي لا يحتاج إليه.

الأخطاء الأكثر شيوعاً

هذه هي الأنماط التي أراها أكثر من غيرها حين يغيب التفكير المنظومي للمشاريع عن مشروع ما.

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

كيف أطبق هذه المنهجية في عملي

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

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

أسئلة حول التفكير المنظومي للمشاريع

للمزيد

هذه أول مذكرة في سلسلة عن طريقتي في البناء. يمكنك الاطلاع على مساري، أو على المشاريع التي أرتبط بها، أو مراسلتي إذا كنت تبني شيئاً وتريد أن نتبادل الأفكار.