#012 — Stakeholders | أصحاب المصلحة
عندما تبدأ تحليل أي نظام، لا يكفي أن تسأل:
ما الذي يجب أن يفعله النظام؟
السؤال الأهم أولًا هو:
من الأشخاص والجهات التي يجب أن أستمع إليها؟
هنا يأتي مفهوم Stakeholders — أصحاب المصلحة.
الـStakeholder هو أي شخص أو جهة لها علاقة بالنظام؛ قد تستخدمه، تديره، تعتمد على مخرجاته، توفر له بيانات، تؤثر في قراراته، أو تتأثر بنتائجه.
ولهذا فليس كل Stakeholder مستخدمًا للنظام، وليس كل مستخدم صاحب القرار.
في متجر إلكتروني مثلًا قد نجد:
العميل يريد تجربة سهلة وسريعة.
الموظف يريد تقليل الخطوات اليدوية والأخطاء.
المدير يريد تقارير تساعده على اتخاذ القرار.
صاحب العمل يهتم بالقيمة والتكلفة والعائد.
فريق التقنية يهتم بالأمان والصيانة والتوسع.
والأنظمة الخارجية تحتاج تكاملًا واضحًا ودقيقًا.
نفس النظام، لكن كل Stakeholder يراه من زاوية مختلفة.
وهنا تظهر إحدى أهم مهارات محلل النظم:
لا تسأل الجميع نفس الأسئلة.
مع العميل تسأل عن احتياجاته والمشاكل التي يواجهها.
مع الموظف تفهم سير العمل اليومي.
مع الإدارة تبحث عن المعلومات ومؤشرات الأداء.
مع صاحب العمل تفهم الهدف التجاري.
مع فريق التقنية تحدد القيود التقنية والأمنية والتكاملات.
ثم تأتي خطوة أخرى مهمة: Stakeholder Analysis.
ليس جميع أصحاب المصلحة بنفس مستوى التأثير والاهتمام، ولذلك يمكن استخدام Power–Interest Matrix لتحديد طريقة التعامل معهم:
High Power + High Interest → إدارة ومشاركة وثيقة.
High Power + Low Interest → الحفاظ على رضاهم.
Low Power + High Interest → إبقاؤهم على اطلاع.
Low Power + Low Interest → المتابعة بالقدر المناسب.
وقد تبدأ المشكلة عندما تتعارض احتياجاتهم.
العميل يريد أقل عدد من خطوات تسجيل الدخول.
فريق الأمن يريد تحققًا أقوى.
الإدارة تريد تكلفة أقل.
الفريق التقني يريد نظامًا قابلًا للصيانة والتوسع.
دور المحلل هنا ليس قبول كل طلب كما هو، بل:
Understand → Compare → Prioritize → Negotiate → Balance
أي: يفهم، يقارن، يرتب الأولويات، يتفاوض، ثم يصل إلى توازن منطقي يخدم المشروع.
وأحد أخطر أخطاء التحليل هو بناء النظام بناءً على رأي شخص واحد، بينما بقية أصحاب المصلحة لم يتم الاستماع إليهم.
لذلك يمكن اختصار الفكرة بهذه المعادلة:
Right Stakeholders → Better Requirements → Better System
كلما فهمت أصحاب المصلحة بشكل أفضل، أصبحت متطلباتك أكثر واقعية، وقرارات التصميم أدق، وفرصة نجاح النظام أكبر.
سؤال للنقاش:
لو كنت ستحلل تطبيق توصيل طعام، من أهم 5 Stakeholders ستبدأ معهم قبل كتابة المتطلبات؟
المنشور القادم:
#013 — Process Modeling
كيف نفهم ونمثل خطوات العمل داخل النظام؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #Stakeholders #StakeholderAnalysis #RequirementsEngineering #SystemAnalysis #BusinessAnalysis #PowerInterestMatrix #Requirements #SystemDesign #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #ProcessModeling #هندسة_البرمجيات #تحليل_النظم #أصحاب_المصلحة #تطوير_البرمجيات
عندما تبدأ تحليل أي نظام، لا يكفي أن تسأل:
ما الذي يجب أن يفعله النظام؟
السؤال الأهم أولًا هو:
من الأشخاص والجهات التي يجب أن أستمع إليها؟
هنا يأتي مفهوم Stakeholders — أصحاب المصلحة.
الـStakeholder هو أي شخص أو جهة لها علاقة بالنظام؛ قد تستخدمه، تديره، تعتمد على مخرجاته، توفر له بيانات، تؤثر في قراراته، أو تتأثر بنتائجه.
ولهذا فليس كل Stakeholder مستخدمًا للنظام، وليس كل مستخدم صاحب القرار.
في متجر إلكتروني مثلًا قد نجد:
العميل يريد تجربة سهلة وسريعة.
الموظف يريد تقليل الخطوات اليدوية والأخطاء.
المدير يريد تقارير تساعده على اتخاذ القرار.
صاحب العمل يهتم بالقيمة والتكلفة والعائد.
فريق التقنية يهتم بالأمان والصيانة والتوسع.
والأنظمة الخارجية تحتاج تكاملًا واضحًا ودقيقًا.
نفس النظام، لكن كل Stakeholder يراه من زاوية مختلفة.
وهنا تظهر إحدى أهم مهارات محلل النظم:
لا تسأل الجميع نفس الأسئلة.
مع العميل تسأل عن احتياجاته والمشاكل التي يواجهها.
مع الموظف تفهم سير العمل اليومي.
مع الإدارة تبحث عن المعلومات ومؤشرات الأداء.
مع صاحب العمل تفهم الهدف التجاري.
مع فريق التقنية تحدد القيود التقنية والأمنية والتكاملات.
ثم تأتي خطوة أخرى مهمة: Stakeholder Analysis.
ليس جميع أصحاب المصلحة بنفس مستوى التأثير والاهتمام، ولذلك يمكن استخدام Power–Interest Matrix لتحديد طريقة التعامل معهم:
High Power + High Interest → إدارة ومشاركة وثيقة.
High Power + Low Interest → الحفاظ على رضاهم.
Low Power + High Interest → إبقاؤهم على اطلاع.
Low Power + Low Interest → المتابعة بالقدر المناسب.
وقد تبدأ المشكلة عندما تتعارض احتياجاتهم.
العميل يريد أقل عدد من خطوات تسجيل الدخول.
فريق الأمن يريد تحققًا أقوى.
الإدارة تريد تكلفة أقل.
الفريق التقني يريد نظامًا قابلًا للصيانة والتوسع.
دور المحلل هنا ليس قبول كل طلب كما هو، بل:
Understand → Compare → Prioritize → Negotiate → Balance
أي: يفهم، يقارن، يرتب الأولويات، يتفاوض، ثم يصل إلى توازن منطقي يخدم المشروع.
وأحد أخطر أخطاء التحليل هو بناء النظام بناءً على رأي شخص واحد، بينما بقية أصحاب المصلحة لم يتم الاستماع إليهم.
لذلك يمكن اختصار الفكرة بهذه المعادلة:
Right Stakeholders → Better Requirements → Better System
كلما فهمت أصحاب المصلحة بشكل أفضل، أصبحت متطلباتك أكثر واقعية، وقرارات التصميم أدق، وفرصة نجاح النظام أكبر.
سؤال للنقاش:
لو كنت ستحلل تطبيق توصيل طعام، من أهم 5 Stakeholders ستبدأ معهم قبل كتابة المتطلبات؟
المنشور القادم:
#013 — Process Modeling
كيف نفهم ونمثل خطوات العمل داخل النظام؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #Stakeholders #StakeholderAnalysis #RequirementsEngineering #SystemAnalysis #BusinessAnalysis #PowerInterestMatrix #Requirements #SystemDesign #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #ProcessModeling #هندسة_البرمجيات #تحليل_النظم #أصحاب_المصلحة #تطوير_البرمجيات
#013 — Process Modeling | نمذجة العمليات
قبل أن تفكر في أتمتة أي عملية داخل النظام، اسأل أولًا:
هل أفهم كيف تتم هذه العملية فعليًا؟
هنا تأتي أهمية Process Modeling.
نمذجة العمليات هي تحويل خطوات العمل الحقيقية إلى نموذج بصري واضح يوضح:
من يبدأ العملية؟
من ينفذ كل خطوة؟
ما القرارات الموجودة؟
ما البيانات المستخدمة؟
أين تحدث الأخطاء؟
ومتى تنتهي العملية؟
بمعنى أبسط:
Input → Process → Decision → Output
لكن الهدف ليس رسم Flowchart جميل فقط.
الهدف الحقيقي هو أن نرى العملية بوضوح حتى نستطيع تحليلها وتحسينها.
ولهذا نبدأ عادةً بـ:
AS-IS Process
أي: كيف تتم العملية الآن في الواقع؟
وليس كيف نتمنى أن تكون.
لأنك عندما ترسم الواقع قد تكتشف:
تأخيرًا غير ضروري.
إدخال بيانات متكررًا.
اعتمادًا زائدًا على التواصل اليدوي.
خطوات لا تضيف قيمة.
نقاط فشل لم تكن واضحة.
وصعوبة في معرفة المسؤول عن كل خطوة.
بعد ذلك نبدأ التحليل:
أين يحدث التأخير؟
ما الذي يمكن الاستغناء عنه؟
ما الذي يمكن أتمتته؟
أين تتكرر البيانات؟
ما القرارات التي تحتاج إلى توضيح؟
ثم ننتقل إلى:
TO-BE Process
أي: كيف يجب أن تصبح العملية بعد التحسين؟
وهنا توجد قاعدة مهمة جدًا:
لا تؤتمت عملية سيئة كما هي.
إذا كانت العملية مليئة بالفوضى، فإن تحويلها إلى Software قد يعني فقط:
فوضى أسرع.
الأفضل هو:
AS-IS → Analyze → Improve → TO-BE → Automate
ومن العناصر المهمة التي نبحث عنها داخل أي Process:
Trigger — ما الذي يبدأ العملية؟
Actors — من يشارك فيها؟
Activities — ما الخطوات التي تتم؟
Decisions — أين تتفرع المسارات؟
Data — ما البيانات المطلوبة؟
Outputs — ما الناتج؟
Exceptions — ماذا يحدث عند الفشل؟
End State — متى تعتبر العملية مكتملة؟
ولدينا أكثر من طريقة لتمثيل العمليات، مثل:
Flowchart للتدفقات البسيطة.
Activity Diagram للأنشطة والتفرعات.
BPMN لنمذجة عمليات الأعمال بتفصيل أكبر.
Swimlanes لإظهار مسؤولية كل Actor أو قسم.
لكن لا تبحث دائمًا عن الأداة الأكثر تعقيدًا.
ابحث عن الأداة التي تجعل العملية أوضح للفريق وأصحاب المصلحة.
يمكن اختصار الفكرة في هذه المعادلة:
Clear Process + Clear Requirements = Better System
المهندس الجيد لا يبدأ بالأتمتة مباشرة، بل يفهم العملية، يبسطها، يحسنها، ثم يحولها إلى نظام.
سؤال للنقاش:
لديك متجر يستقبل الطلبات من WhatsApp والهاتف والموقع، وكل طلب يُسجل يدويًا.
ما أول مشكلة ستبحث عنها في الـ AS-IS Process؟
المنشور القادم:
#014 — Risk Analysis
كيف تكتشف المخاطر قبل أن تتحول إلى مشاكل حقيقية؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #ProcessModeling #BusinessProcess #SystemAnalysis #RequirementsEngineering #Flowchart #ActivityDiagram #BPMN #Swimlanes #BusinessAnalysis #SystemDesign #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #نمذجة_العمليات #تطوير_البرمجيات
قبل أن تفكر في أتمتة أي عملية داخل النظام، اسأل أولًا:
هل أفهم كيف تتم هذه العملية فعليًا؟
هنا تأتي أهمية Process Modeling.
نمذجة العمليات هي تحويل خطوات العمل الحقيقية إلى نموذج بصري واضح يوضح:
من يبدأ العملية؟
من ينفذ كل خطوة؟
ما القرارات الموجودة؟
ما البيانات المستخدمة؟
أين تحدث الأخطاء؟
ومتى تنتهي العملية؟
بمعنى أبسط:
Input → Process → Decision → Output
لكن الهدف ليس رسم Flowchart جميل فقط.
الهدف الحقيقي هو أن نرى العملية بوضوح حتى نستطيع تحليلها وتحسينها.
ولهذا نبدأ عادةً بـ:
AS-IS Process
أي: كيف تتم العملية الآن في الواقع؟
وليس كيف نتمنى أن تكون.
لأنك عندما ترسم الواقع قد تكتشف:
تأخيرًا غير ضروري.
إدخال بيانات متكررًا.
اعتمادًا زائدًا على التواصل اليدوي.
خطوات لا تضيف قيمة.
نقاط فشل لم تكن واضحة.
وصعوبة في معرفة المسؤول عن كل خطوة.
بعد ذلك نبدأ التحليل:
أين يحدث التأخير؟
ما الذي يمكن الاستغناء عنه؟
ما الذي يمكن أتمتته؟
أين تتكرر البيانات؟
ما القرارات التي تحتاج إلى توضيح؟
ثم ننتقل إلى:
TO-BE Process
أي: كيف يجب أن تصبح العملية بعد التحسين؟
وهنا توجد قاعدة مهمة جدًا:
لا تؤتمت عملية سيئة كما هي.
إذا كانت العملية مليئة بالفوضى، فإن تحويلها إلى Software قد يعني فقط:
فوضى أسرع.
الأفضل هو:
AS-IS → Analyze → Improve → TO-BE → Automate
ومن العناصر المهمة التي نبحث عنها داخل أي Process:
Trigger — ما الذي يبدأ العملية؟
Actors — من يشارك فيها؟
Activities — ما الخطوات التي تتم؟
Decisions — أين تتفرع المسارات؟
Data — ما البيانات المطلوبة؟
Outputs — ما الناتج؟
Exceptions — ماذا يحدث عند الفشل؟
End State — متى تعتبر العملية مكتملة؟
ولدينا أكثر من طريقة لتمثيل العمليات، مثل:
Flowchart للتدفقات البسيطة.
Activity Diagram للأنشطة والتفرعات.
BPMN لنمذجة عمليات الأعمال بتفصيل أكبر.
Swimlanes لإظهار مسؤولية كل Actor أو قسم.
لكن لا تبحث دائمًا عن الأداة الأكثر تعقيدًا.
ابحث عن الأداة التي تجعل العملية أوضح للفريق وأصحاب المصلحة.
يمكن اختصار الفكرة في هذه المعادلة:
Clear Process + Clear Requirements = Better System
المهندس الجيد لا يبدأ بالأتمتة مباشرة، بل يفهم العملية، يبسطها، يحسنها، ثم يحولها إلى نظام.
سؤال للنقاش:
لديك متجر يستقبل الطلبات من WhatsApp والهاتف والموقع، وكل طلب يُسجل يدويًا.
ما أول مشكلة ستبحث عنها في الـ AS-IS Process؟
المنشور القادم:
#014 — Risk Analysis
كيف تكتشف المخاطر قبل أن تتحول إلى مشاكل حقيقية؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #ProcessModeling #BusinessProcess #SystemAnalysis #RequirementsEngineering #Flowchart #ActivityDiagram #BPMN #Swimlanes #BusinessAnalysis #SystemDesign #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #نمذجة_العمليات #تطوير_البرمجيات