نمذجة العمليات: المخططات الانسيابية ومخططات تدفق البيانات

رسم مخططات التدفق بفاعلية

18 دقيقة الدرس 3 من 10

رسم مخططات التدفق بفاعلية

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

العملية التي سنقوم بنمذجتها

تخيل أنك المحلل الأنظمة لمتجر إلكتروني متوسط الحجم. أعطاك مدير العمليات وصفاً لسير عمل معالجة الطلبات:

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

تتضمن هذه الفقرة قرارات وحلقات واهتمامات متوازية ونتائج متعددة — تحديداً نوع التعقيد الذي يُصمَّم مخطط التدفق لفكّه.

الخطوة 1 — تحديد الحدود

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

  • البداية: يضع العميل طلباً.
  • النهاية 1: إلغاء الطلب واسترداد المبلغ.
  • النهاية 2: إكمال الطلب (شحن الطرد وإرسال التتبع).
  • النهاية 3: وضع الطلب في قائمة الانتظار (في انتظار توفر المخزون).

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

الخطوة 2 — استخراج القرارات

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

  1. هل المنتجات متوفرة؟ — نعم ← استمر؛ لا ← أبلغ العميل.
  2. اختيار العميل؟ — إلغاء ← مسار الاسترداد؛ طلب مؤجل ← مسار الانتظار.
  3. هل تم تفويض الدفع؟ — نعم ← الشحن؛ لا ← تعليق الطلب.
نصيحة — وضع تسميات القرارات: ضع دائماً تسمية على كلا فرعَي المعين (نعم/لا، أو النتيجة المحددة كـإلغاء/طلب مؤجل). الفرع غير المسمى يُفرز تفسيرات متضاربة بين المطورين وأصحاب المصلحة.

الخطوة 3 — ترتيب خطوات العملية

بين القرارات، رتّب خطوات العملية البسيطة بالتسلسل. في التدوين القياسي هذه مستطيلات. من الوصف نستخلص:

  • التحقق من توفر المخزون
  • إبلاغ العميل (مشكلة المخزون)
  • تسجيل الطلب المؤجل
  • استرداد المبلغ
  • تأكيد الطلب
  • الإرسال إلى المستودع / التجهيز والتغليف
  • تفويض الدفع
  • شحن الطرد
  • إرسال بريد إلكتروني بالتتبع
  • تحديد حالة الطلب كمكتمل

الخطوة 4 — رسم المخطط

بعد تحديد الحدود والقرارات والخطوات، نجمع المخطط الآن. استخدم مستطيلات مستديرة الزوايا (منهيات) للبداية/النهاية، مستطيلات للعمليات، ومعينات للقرارات. الأسهم تحمل التدفق والتسميات تُوضّح كل فرع.

Order-Handling Flowchart Start: Order Placed Check Stock Availability Items in Stock? Yes No Notify Customer (Stock Issue) Customer Choice? Cancel Issue Refund End: Order Cancelled Back-order Log Back-Order End: Awaiting Stock Confirm Order Send to Warehouse / Pick and Pack Authorise Payment Payment Authorised? No Hold Order & Contact Customer Retry Yes Ship Parcel Send Tracking Email End: Order Complete
مخطط تدفق معالجة الطلبات: ثلاث حالات نهاية مختلفة (مكتمل، ملغى، في انتظار المخزون) وحلقة إعادة محاولة الدفع.

الخطوة 5 — مراجعة المخطط مقابل القواعد

قبل تقديم المخطط لأصحاب المصلحة، مرّره عبر قائمة التحقق هذه:

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

التحليل إلى المستوى الصحيح

يجب أن يتسع مخطط تدفق واحد بسهولة في صفحة واحدة. عندما تجد نفسك ترسم أكثر من 15–20 شكلاً، فكر في التحليل. يمكن أن يكون مستطيل "التجهيز والتغليف" في مخطط معالجة الطلبات أعلاه هو نقطة البداية لمخطط فرعي يُظهر الخطوات التفصيلية لعامل المستودع. هذا النهج الهرمي — مخطط أصل رفيع المستوى مع مخططات فرعية تفصيلية — يُسمى مخطط التدفق المتداخل أو الطبقي ويعكس بالضبط كيفية عمل مستويات DFD (ستطبق نفس الفكرة في الدرسين التاليين).

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

التواصل مع أصحاب المصلحة

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

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