كنا نُؤتمت الفوضى: كيف أنقذتنا ‘نمذجة إجراءات العمل’ (BPMN) من جحيم العمليات العشوائية؟

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

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

إحنا كمبرمجين، شو عملنا؟ بكل بساطة، بلشنا نبرمج هاي الفوضى. إجا مدير قسم المبيعات حكالنا: “بدي زر لما أكبسه يبعت إيميل لمدير المالية”. حاضر. إجت مسؤولة المستودعات حكت: “بدي تنبيه لما المخزون يقل عن 10 قطع”. من عيوني. كنا بنبني “جُزُر” برمجية صغيرة في محيط من الفوضى، وبنحاول نربطها بخيوط عنكبوت رفيعة. النتيجة؟ نظام أسرع في تنفيذ الفوضى! بدل ما الخطأ اليدوي ياخذ يوم، صار نظامنا يعمله في ثانية. الوضع كان رايح للجحيم بكل معنى الكلمة، والمشروع على وشك الفشل.

في واحد من اجتماعات “العصف الذهني” اليائسة، واحد من الشباب الجداد، محلل أعمال لسا متخرج، حكى بخجل: “ليش ما نرسم العملية كلها على الورق قبل ما نبرمجها؟ باستخدام إشي اسمه BPMN”. وقتها أنا، بخبرتي اللي كنت شايفها كبيرة، نظرتله نظرة استخفاف. قلت في بالي: “شو هالفلسفة الزايدة؟ إحنا ناس عمليين، بدنا نكتب كود، مش نرسم مربعات ودوائر”.

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

ما هي نمذجة إجراءات العمل (BPMN) ببساطة؟

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

الـ BPMN هي “النوتة الموسيقية” اللي بتوزعها على كل العازفين. هي لغة عالمية موحدة، مرسومة، بتخلي رجل الأعمال، والمحلل، والمبرمج، ومدير القسم، كلهم يطلعوا على نفس الرسمة ويفهموا نفس الإشي بالضبط. مين بيبدأ العملية، شو الخطوات، مين المسؤول عن كل خطوة، ولو صار “كذا” شو بنعمل، ولو صار “هيك” شو البديل.

هي مش مجرد رسمة، هي اتفاقية، عقد مرئي بين كل الأطراف المعنية، بتوصف “إجراء العمل” (Business Process) من الألف إلى الياء.

لماذا وقعنا في “جحيم العمليات العشوائية”؟

مشكلتنا، واللي هي مشكلة أغلب الشركات، ما كانت في التكنولوجيا، بل في غياب “الفهم المشترك”. أعراض المرض كانت واضحة:

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

“أتمتة الفوضى لا تنتج إلا فوضى سريعة ومنظمة.” – مقولة من كيس أبو عمر بعد التجربة هاي.

كيف كانت BPMN طوق النجاة؟

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

الخطوة الأولى: جلسة “الفضفضة” ورسم الخريطة الأولى

جمعنا ممثل عن كل قسم في غرفة اجتماعات كبيرة، ومعنا لوح أبيض (Whiteboard) وأقلام ملونة. طلبنا من مندوب المبيعات يشرح شو بصير من لحظة ما العميل يحكي “بدي أشتري”.

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

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

المكونات الأساسية لـ BPMN التي استخدمناها

بعد ما فضفضنا وشفنا الكركبة، بدأنا ننظمها باستخدام الرموز القياسية للـ BPMN. وهون حلاوة الموضوع، الرموز قليلة ومنطقية:

• الأحداث (Events): عبارة عن دوائر. دائرة رفيعة للبداية، دائرة سميكة للنهاية. بسيطة.
• المهام (Tasks): مستطيل بزوايا دائرية. هاي هي الشغلات اللي بدها تنعمل. ممكن تكون “مهمة مستخدم” (User Task) يعني شخص لازم يعملها، أو “مهمة خدمة” (Service Task) يعني النظام بيعملها تلقائيًا.
• البوابات (Gateways): شكل المعيّن (الدايموند). هاي هي مفترقات الطرق ونقاط اتخاذ القرار. أشهر نوع هو البوابة الحصرية (Exclusive Gateway) اللي بتعني “يا بتروح من هالطريق، يا من هالطريق. مستحيل الاثنين مع بعض”.
• الممرات (Swimlanes): هاي كانت السحر الحقيقي! قسمنا الرسمة لممرات أفقية أو عمودية، كل ممر باسم قسم (مثلاً: ممر المبيعات، ممر المالية، ممر المستودع). أي مهمة بتنحط في ممر معين، بصير واضح للكل مين المسؤول عنها. هيك انتهى زمن “رمي الكرة”.

من الرسم إلى الواقع: مثال عملي (عملية معالجة طلب شراء)

عشان تكون الصورة أوضح، خلينا نطبق هالحكي على مثال “معالجة طلب الشراء” اللي جنّنا.

النموذج “قبل” BPMN (وصف للفوضى)

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

النموذج “بعد” BPMN (الأوركسترا المنظمة)

رسمنا مخطط واضح باستخدام أداة مثل Camunda Modeler أو bpmn.io. المخطط صار كالتالي:

1. (Start Event) “تم استلام طلب جديد” في ممر “النظام”.
2. (Service Task) “التحقق من صحة بيانات الطلب” في ممر “النظام”.
3. (User Task) “مراجعة الطلب والموافقة المبدئية” في ممر “قسم المبيعات”.
4. (Exclusive Gateway) “هل تمت الموافقة؟”
   • نعم: يكمل التدفق.
   • لا: يذهب إلى (User Task) “إبلاغ العميل بالرفض” ثم (End Event).
5. (Service Task) “التحقق من المخزون آليًا” في ممر “النظام” (عبر API لنظام المستودعات).
6. (Exclusive Gateway) “هل المنتج متوفر؟”
   • نعم: يذهب إلى (User Task) “تجهيز وشحن الطلب” في ممر “قسم المستودعات”.
   • لا: يذهب إلى (User Task) “إبلاغ العميل بتأخر الطلب” في ممر “قسم المبيعات”.
7. (Service Task) “إصدار فاتورة آلية” في ممر “النظام”.
8. (End Event) “اكتملت معالجة الطلب”.

فجأة، العملية صارت واضحة، المسؤوليات محددة، والمهام المؤتمتة مميزة عن المهام اليدوية.

من الرسم إلى الكود: ما تحت الغطاء

أجمل ما في الموضوع، أن هذه الرسومات ليست مجرد صور. الأدوات الحديثة تسمح لك بتصدير هذا المخطط كملف XML قياسي. هذا الملف هو ما تفهمه “محركات إجراءات العمل” (Process Engines) مثل Camunda أو Flowable.

هذا يعني أن الرسمة التي اتفق عليها رجل الأعمال، هي نفسها التي سيتم تنفيذها في البرنامج. لا مجال لسوء الفهم.

هذا مثال بسيط على جزء من كود الـ XML الذي يتم توليده لمهمة مستخدم:

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" ...>
  <bpmn:process id="Process_Order" isExecutable="true">
    <bpmn:startEvent id="StartEvent_1" name="تم استلام طلب جديد" />
    ...
    <bpmn:userTask id="Task_ReviewOrder" name="مراجعة الطلب">
      <bpmn:documentation>يقوم موظف المبيعات بمراجعة تفاصيل الطلب والموافقة عليه.</bpmn:documentation>
      <bpmn:incoming>SequenceFlow_...</bpmn:incoming>
      <bpmn:outgoing>SequenceFlow_...</bpmn:outgoing>
    </bpmn:userTask>
    ...
  </bpmn:process>
</bpmn:definitions>

لاحظ كيف أن اسم المهمة (name) وحتى التوثيق (documentation) موجودان في الكود. الرسم هو الكود، والكود هو الرسم.

نصائح “أبو عمر” الذهبية لاستخدام BPMN

من خلال تجربتي وتجارب فريقي، جمعت لكم هذه النصائح العملية:

• ابدأ بالبساطة ثم تعقّد: لا تخفِ الناس من أول جلسة بكل رموز BPMN. ابدأ بالأساسيات، وعندما تنشأ الحاجة لرمز أكثر تعقيدًا (مثل الأحداث الوسيطة أو البوابات المتوازية)، اشرحه في سياقه.
• الـ BPMN لغة تواصل، وليست مجرد أداة تقنية: تذكر دائمًا أن الهدف الأول هو تحقيق فهم مشترك. إذا كان فريق العمل غير التقني لا يفهم الرسمة، فالمشكلة في الرسمة وليست فيهم. بسّطها.
• استخدم الممرات (Swimlanes) دائمًا وأبدًا: أكرر هذه النصيحة لأهميتها. هي أفضل وسيلة لتحديد المسؤوليات ومنع تداخل الصلاحيات.
• لا تؤتمت الفوضى، بل حسّنها أولاً: قبل أن تحول أي مهمة إلى (Service Task)، اسأل نفسك وفريقك: “هل هذه المهمة ضرورية أصلًا؟ هل يمكن تبسيطها؟ هل يمكن دمجها مع مهمة أخرى؟”. المخطط هو فرصتك لتحسين العملية قبل كتابة سطر كود واحد.
• وثّق قراراتك على البوابات (Gateways): لا تكتفِ برسم معين وسهمين. أضف تعليقًا (Annotation) يشرح الشرط بوضوح. بدلاً من “نعم/لا”، اكتب “المخزون > 0” و “المخزون = 0”.

الخلاصة: من الفوضى إلى الأوركسترا 🎶

تجربة “أتمتة الفوضى” كانت قاسية، لكنها علمتنا درسًا ثمينًا: التكنولوجيا وحدها لا تكفي. بدون فهم عميق وواضح ومشترك للعمليات، أفضل الأنظمة ستفشل. الـ BPMN لم تكن مجرد أداة رسم، بل كانت “العصا السحرية” التي حولت الضجيج إلى سيمفونية متناغمة.

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

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

يلا، جربوها واحكولي شو بصير معكم. بالتوفيق! 😉