التحول الرقمي عملياً: خدمة طلب كشف الدرجات

في المقال الثالث من السلسلة مررنا على الأدوات المفتوحة لكل خطوة من دورة التحول الرقمي Digital Transformation، وفي هذا المقال سوف نطبقها على خدمة واحدة من البداية إلى النهاية: طلب كشف درجات رسمي Official Transcript في جامعة، وهي الخدمة التي بدأنا بها السلسلة في المقال الأول، لأنها تجمع صفات الخدمة المناسبة للبداية: طلبات كثيرة، وانتظار يعرفه الجميع، وأقسام متعددة يمر عليها الطلب. والجامعة في المثال افتراضية، فلا نملك سجلات جامعة حقيقية، ولذلك سوف نولد سجل أحداث محاكى Simulated Event Log بسكربت نكتب افتراضاته كلها، ونحلله بالأدوات الحقيقية نفسها التي ستستخدمها على سجلاتك، فالأرقام في هذا المقال نتيجة الافتراضات، والطريقة هي ما يهمك.

المواضيع في السلسلة:

1. ما هو التحول الرقمي Digital Transformation فعلاً؟
2. منهجية التحول الرقمي: من التقييم إلى خارطة الطريق.
3. أدوات التحول الرقمي المفتوحة: من BPMN إلى البيانات.
4. التحول الرقمي عملياً: خدمة طلب كشف الدرجات. (الموضوع الحالي)

وسوف نناقش في هذا المقال ما يلي:

• رسم الوضع الحالي As-Is بلغة BPMN من ملف نصي، وتحويله إلى صورة بمكتبة bpmn-js.
• سجل الأحداث Event Log: من أين يأتي، وكيف ولدناه للمثال.
• قياس المدة والانتظار والتكرار بمكتبة pm4py، ومقارنة السجل بمخطط الإجراء.
• نقاط الألم Pain Points مرتبة بما تكلفه من وقت.
• الوضع المستهدف To-Be، وتقدير أثره بالطريقة نفسها.
• خارطة الطريق على مراحل، والمؤشرات KPIs، وبطاقة الإجراء كما تطلبها المعايير الأساسية.

والصورة التالية تبين الخطوات الست والملف الذي تنتجه كل خطوة:

الخدمة وحدودها

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

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

رسم الوضع الحالي As-Is

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

وقد يتساءل البعض: لماذا نكتب الرسم بسكربت بدلاً من رسمه في Camunda Modeler؟ والإجابة أن الرسم في البرنامج هو الطريقة الطبيعية لفريق العمل، ولكننا هنا نريد أن يعيد القارئ إنتاج الملف نفسه، فكتبنا سكربت Python صغيراً gen_bpmn.py يأخذ الحارات والمهام والأسهم ويكتب ملف BPMN 2.0 كاملاً بمواقع العناصر، والملف الناتج يفتح في Camunda Modeler وbpmn.io كأي ملف رسم بهما. والجزء الذي يصف الوضع الحالي من السكربت كما يلي:

# Current state (As-Is): paper form by email, manual checks by email, wet signature, pickup in person
model("asis",
      [("S", "الطالب"), ("R", "القبول والتسجيل"), ("F", "الإدارة المالية"), ("D", "مكتب العميد")],
      [("start", "start", "S", 0, "يحتاج كشف درجات"),
       ("submit", "task", "S", 1, "تعبئة النموذج وإرساله بالبريد"),
       ("log", "task", "R", 2, "استلام الطلب وتسجيله يدوياً"),
       ("complete", "xor", "R", 3, "النموذج مكتمل؟"),
       ("fix", "task", "S", 3, "استكمال البيانات الناقصة"),
       ("askfin", "task", "R", 4, "مراسلة المالية عن الرسوم"),
       ("fee", "task", "F", 5, "التحقق من سداد الرسوم"),
       ("print", "task", "R", 6, "طباعة الكشف"),
       ("sign", "task", "D", 7, "توقيع العميد"),
       ("stamp", "task", "R", 8, "الختم والاتصال بالطالب"),
       ("collect", "task", "S", 9, "الحضور والاستلام"),
       ("end", "end", "S", 10, "استلم الكشف")],
      [("start", "submit", ""), ("submit", "log", ""), ("log", "complete", ""),
       ("complete", "fix", "لا"), ("fix", "log", ""), ("complete", "askfin", "نعم"),
       ("askfin", "fee", ""), ("fee", "print", ""), ("print", "sign", ""), ("sign", "stamp", ""),
       ("stamp", "collect", ""), ("collect", "end", "")])

ولكل عقدة في الوصف أعلاه المعرف ثم النوع ثم الحارة ثم رقم العمود ثم الاسم كما يظهر في الرسم. ونشغل السكربت داخل Container من Python دون أي مكتبة إضافية:

docker run --rm --name lab-dt-py -v "$PWD:/lab" -w /lab python:3.13.16-slim python gen_bpmn.py

والمخرج سوف يكون كما يلي:

asis.bpmn: 4 lanes, 12 nodes, 12 flows
tobe.bpmn: 3 lanes, 9 nodes, 9 flows
asis_happy.bpmn: 4 lanes, 10 nodes, 9 flows

ثم نحول الملف إلى صورة بسكربت render.mjs الذي شرحناه في المقال الثالث، وكانت نتيجة الاستيراد warnings=0، والصورة التالية هي الرسم كما أخرجته bpmn-js:

وفي الرسم أعلاه لاحظ التالي:

• كل سهم يعبر من حارة إلى أخرى هو تسليم Hand-off، والطلب الذي يسلك المسار البسيط يعبر ست مرات، ومع كل تسليم صندوق بريد ينتظر فيه.
• الحلقة بين «النموذج مكتمل؟» و«استكمال البيانات الناقصة» لا تظهر في أغلب أدلة الإجراءات، ولكنها جزء من الواقع، وسوف نقيس حجمها بعد قليل.
• لا توجد مهمة واحدة آلية، فكل المهام بأيقونة الشخص.

سجل الأحداث Event Log

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

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

ولأن الجامعة في مثالنا افتراضية فقد كتبنا سكربت simulate_log.py يولد 300 طلب ببذرة عشوائية ثابتة Fixed Seed، فيخرج السجل نفسه في كل تشغيل، والافتراضات التي فيه كما يلي:

ونشغل السكربت بالطريقة نفسها:

docker run --rm --name lab-dt-py -v "$PWD:/lab" -w /lab python:3.13.16-slim \
  sh -c "python simulate_log.py && head -14 asis_log.csv"

والمخرج سوف يكون كما يلي:

asis_log.csv: 300 cases, 2604 events
tobe_log.csv: 300 cases, 1518 events
case_id,activity,resource,start,complete
T-0001,Submit form by email,Student,2026-01-04T09:13,2026-01-04T09:28
T-0001,Log request,Registrar,2026-01-05T08:00,2026-01-05T08:10
T-0001,Ask finance,Registrar,2026-01-05T10:31,2026-01-05T10:36
T-0001,Confirm fee,Finance,2026-01-07T13:11,2026-01-07T13:21
T-0001,Print transcript,Registrar,2026-01-08T08:00,2026-01-08T08:05
T-0001,Dean signs,Dean office,2026-01-11T10:00,2026-01-11T10:03
T-0001,Stamp and call,Registrar,2026-01-12T10:17,2026-01-12T10:22
T-0001,Collect in person,Student,2026-01-14T08:00,2026-01-14T08:10
T-0002,Submit form by email,Student,2026-01-04T18:21,2026-01-04T18:36
T-0002,Log request,Registrar,2026-01-05T09:43,2026-01-05T09:53
T-0002,Ask finance,Registrar,2026-01-05T14:57,2026-01-05T15:02
T-0002,Confirm fee,Finance,2026-01-06T11:41,2026-01-06T11:51
T-0002,Print transcript,Registrar,2026-01-07T08:00,2026-01-07T08:05

وفي المخرج أعلاه لاحظ أن الطلب الثاني أرسل الساعة 18:21 بعد انتهاء الدوام، فبدأ تسجيله صباح اليوم التالي، وأن طباعة الطلب الأول كانت يوم 8 يناير بينما توقيعه يوم 11 يناير، لأن العميد يوقع يومي الأحد والأربعاء فقط.

القياس بمكتبة pm4py

نشغل pm4py في Container واحد نثبت فيه المكتبة وبرنامج Graphviz الذي ترسم به المكتبة مخططاتها، ونبقيه يعمل حتى نعيد التحليل أكثر من مرة:

docker run -d --name lab-dt-pm4py -v "$PWD:/art" -w /art/lab python:3.13.16-slim sleep infinity
docker exec lab-dt-pm4py sh -c "apt-get update -qq >/dev/null 2>&1; apt-get install -y -qq --no-install-recommends graphviz >/dev/null 2>&1; dot -V; pip install -q --root-user-action=ignore pm4py==2.7.23.10 2>&1 | tail -2; pip list 2>/dev/null | grep -iE '^(pm4py|pandas|numpy|graphviz) '"

والمخرج سوف يكون كما يلي:

dot - graphviz version 2.42.4 (0)
graphviz        0.21
numpy           2.5.4
pandas          3.0.6
pm4py           2.7.23.10

والسكربت mine.py يقرأ السجل بالدالة pm4py.format_dataframe مع عمود وقت البداية، ثم يحسب المدة ووقت العمل والتسليمات والتكرار والمسارات Variants، ثم الانتظار قبل كل خطوة، ثم أبطأ الانتقالات بالدالة pm4py.discover_performance_dfg، ثم التطابق مع الرسم. ونشغله كما يلي:

docker exec lab-dt-pm4py sh -c "cd /art/lab && python mine.py" > mine-output.txt 2>&1

والمخرج للوضع الحالي سوف يكون كما يلي، وقد حذفنا منه رسالة الترخيص التي تطبعها المكتبة في أوله، وعرضناها في المقال الثالث:

===== AS-IS (simulated)
cases: 300   events: 2604
cycle time (days): median 12.7  p90 19.9  max 28.1
work time per case (minutes): median 63
share of the cycle time spent working: 0.36%
hand-offs between teams per case: median 6  max 12
manual touches per case (rows not done by a system): median 8
cases with rework (asked to fix data): 85 (28.3%)
variants: 4
   215 cases  Submit form by email > Log request > Ask finance > Confirm fee > Print transcript > Dean signs > Stamp and call > Collect in person
    71 cases  Submit form by email > Log request > Fix missing data > Log request > Ask finance > Confirm fee > Print transcript > Dean signs > Stamp and call > Collect in person
    11 cases  Submit form by email > Log request > Fix missing data > Log request > Fix missing data > Log request > Ask finance > Confirm fee > Print transcript > Dean signs > Stamp and call > Collect in person

waiting before each activity (hours), sorted by total waiting:
                   count  median  share_of_all_waiting_%
concept:name                                            
Dean signs           300    68.6                    23.6
Collect in person    300    71.9                    22.8
Confirm fee          300    66.7                    20.1
Log request          402    30.9                    15.1
Stamp and call       300    22.0                     6.0
Print transcript     300    17.8                     5.3
Fix missing data     102    27.6                     3.7
Ask finance          300     4.3                     3.4

slowest transitions (performance DFG, median hours from one activity to the next):
  Stamp and call -> Collect in person: 71.9
  Print transcript -> Dean signs: 68.6
  Ask finance -> Confirm fee: 66.7
  Submit form by email -> Log request: 32.2
  Fix missing data -> Log request: 27.9

وفي المخرج أعلاه لاحظ التالي:

• المدة الوسيطة للطلب 12.7 يوماً، و10% من الطلبات تتجاوز 19.9 يوماً، بينما وقت العمل الفعلي على الطلب ساعة واحدة تقريباً (63 دقيقة)، أي أن الطلب يقضي 0.36% فقط من عمره وأحد يعمل عليه، والباقي انتظار.
• الوسيط ست تسليمات بين الأطراف لكل طلب، وثماني لمسات من الموظفين أو الطالب.
• 28.3% من الطلبات أعيدت لاستكمال البيانات مرة على الأقل، وطباعة المسارات تعرض أكثر ثلاثة مسارات تكراراً من أربعة.
• جدول الانتظار مرتب بمجموع الانتظار، وثلاث خطوات فقط تأخذ ثلثي الانتظار كله: توقيع العميد 23.6%، والاستلام 22.8%، والتحقق من الرسوم 20.1%.

والصورة التالية هي مخطط الأداء الذي أخرجته pm4py بالدالة save_vis_performance_dfg بالوسيط، وكل سهم عليه الوقت الوسيط بين الخطوتين:

هل يطابق السجل الرسم؟ وماذا يحدث إذا رسمنا المسار البسيط فقط؟

أغلب أدلة الإجراءات ترسم المسار البسيط Happy Path فقط، أي الطلب المكتمل من أول مرة، ولذلك أضفنا إلى السكربت نسخة ثالثة من الرسم asis_happy.bpmn بلا حلقة الاستكمال، وقارنا السجل بالمخططين بطريقة إعادة التشغيل بالرموز Token-Based Replay في الدالة pm4py.fitness_token_based_replay، بعد تحويل أسماء الخطوات في السجل إلى الأسماء العربية في الرسم. والجزء الخاص بذلك من المخرج كما يلي:

fitness of the log against asis.bpmn: fitting cases 100.0%  log fitness 1.0

fitness of the log against asis_happy.bpmn: fitting cases 71.7%  log fitness 0.964

والنتيجة أن الرسم الذي فيه الحلقة يطابق كل الطلبات، بينما رسم المسار البسيط يطابق 71.7% منها فقط، أي أن الدليل المكتوب يصف ما يحدث لأقل من ثلاثة أرباع الطلبات، والربع الباقي هو الطلبات التي تأخذ أطول وقت. ولاحظ أن مقياس Log Fitness بقي مرتفعاً (0.964) لأن الطلبات المخالفة تتبع الرسم في أغلب خطواتها، فلا تحكم على الرسم بهذا الرقم وحده، وانظر إلى نسبة الطلبات المطابقة كاملة.

وأخيراً طلبنا من pm4py أن تكتشف رسماً من السجل وحده بخوارزمية Inductive Miner، وحفظناه بصيغة BPMN وحولناه إلى صورة بالطريقة نفسها:

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

نقاط الألم مرتبة بما تكلفه

من الأرقام أعلاه نكتب نقاط الألم، وكل نقطة لها رقم من السجل وسبب ومعالجة، والجدول التالي مرتب بنصيب كل نقطة من مجموع الانتظار:

وفي الجدول أعلاه لاحظ أن أي تحسين في سرعة الموظفين أنفسهم لن يغير المدة تقريباً، لأن العمل الفعلي 0.36% من عمر الطلب، فلو أصبح كل موظف أسرع بالضعف لنقصت المدة دقائق من أصل أيام، والمكسب الحقيقي في حذف الانتظار بين الأقسام.

الوضع المستهدف To-Be

صممنا الوضع المستهدف على خمسة مبادئ، وكل مبدأ يعالج نقطة ألم من الجدول السابق:

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

والصورة التالية هي الرسم المستهدف كما أخرجته bpmn-js من الملف tobe.bpmn:

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

===== TO-BE (projection from assumptions)
cases: 300   events: 1518
cycle time (hours): median 0.5  p90 1.0  max 75.3
work time per case (minutes): median 10
share of the cycle time spent working: 7.61%
hand-offs between teams per case: median 1  max 3
manual touches per case (rows not done by a system): median 2
variants: 2
   282 cases  Submit in portal > Pay online > Generate from SIS > Seal and verify code > Deliver and notify
    18 cases  Submit in portal > Pay online > Generate from SIS > Review exception > Seal and verify code > Deliver and notify

median cycle time: 12.7 days -> 32 minutes
p90 cycle time: 19.9 days -> 1.0 hours
pm4py 2.7.23.10  pandas 3.0.6

وفي المخرج أعلاه لاحظ التالي:

• المدة الوسيطة المقدرة 32 دقيقة، ولكن أطول طلب 75.3 ساعة، وهو طلب استثناء وصل قبل نهاية الأسبوع، فمسار الاستثناء هو الذي سيحدد تجربة الطلاب الأسوأ، ويحتاج مؤشراً خاصاً به.
• اللمسات اليدوية الوسيطة اثنتان، وهما خطوتا الطالب نفسه في التقديم والدفع، أما الموظف فيلمس طلبات الاستثناء فقط.
• 18 طلباً من 300 مرت على الاستثناء في هذا التشغيل، أي 6% بينما الافتراض 8%، وهذا طبيعي في عينة صغيرة.

خارطة الطريق على مراحل

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

وفي خارطة الطريق أعلاه لاحظ التالي:

• المرحلة الأولى لا تحتاج تكاملاً معقداً، ولكنها تحذف حلقة الاستكمال التي أصابت 28.3% من الطلبات، وتبني ثقة الإدارة برقم يتحسن خلال أسابيع.
• المرحلة الثانية تحذف انتظار المالية والاستلام، وهما معاً 42.9% من الانتظار في السجل.
• المرحلة الثالثة هي الأصعب، لأن أكبر نقطة ألم، وهي التوقيع، تحتاج قراراً تنظيمياً قبل الكود، وهذه هي خطوة «إزالة العوائق» في نموذج Kotter التي شرحناها في المقال الثاني.
• المدد تقدير للتخطيط، وتراجع بعد قياس كل مرحلة.

المؤشرات KPIs وسجل المنافع

كل مؤشر في الجدول التالي يحسب بالسكربت نفسه من سجل الأحداث، فلا يحتاج موظفاً يجمعه، وخط الأساس من سجل الوضع الحالي المحاكى، والهدف من التقدير مع هامش:

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

بطاقة الإجراء كما في المعايير الأساسية

في المقال الثاني ذكرنا أن المعيار 5.7.2 في المعايير الأساسية للتحول الرقمي يطلب بطاقة لكل إجراء بعناصر محددة، والجدول التالي يملؤها لخدمتنا من ملفات هذا المقال:

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

ملفات المثال

كل ملفات المثال في مجلد lab مع المقال، وهي كما يلي:

وبعد الانتهاء نحذف ما أنشأناه بالاسم فقط:

docker rm -f lab-dt-pm4py

أخطاء شائعة

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

تدريب عملي

• غير في simulate_log.py توقيع العميد ليصبح يومياً بدلاً من مرتين في الأسبوع، وأعد التحليل، ثم قارن المدة الوسيطة الجديدة بخط الأساس، وستعرف كم من المدة يعود إلى الدفعات وحدها.
• صدر من نظام التذاكر أو البريد في مؤسستك سجلاً لخدمة واحدة بأعمدة case_id وactivity وresource وstart وcomplete، وشغل عليه mine.py كما هو.

الخلاصة

• بدأنا من حدود الخدمة كما يراها الطالب، ورسمنا الوضع الحالي بملف BPMN يولده سكربت، وحولناه إلى صورة بمكتبة bpmn-js دون تحذيرات.
• في السجل المحاكى كانت المدة الوسيطة 12.7 يوماً ووقت العمل 0.36% منها، وثلاث خطوات انتظار بين الأقسام أخذت ثلثي الانتظار كله.
• رسم المسار البسيط يطابق 71.7% من الطلبات فقط، والرسم المكتشف من السجل أظهر حلقة الاستكمال نفسها.
• الوضع المستهدف يأخذ البيانات من SIS والدفع إلكترونياً ويصدر الكشف بختم إلكتروني، والموظف للاستثناءات، وتقدير المدة الوسيطة له 32 دقيقة من افتراضات معلنة.
• خارطة الطريق أربع مراحل لكل منها مؤشر من السجل نفسه، وأصعبها يحتاج قراراً تنظيمياً قبل الكود.

وبهذا تكتمل السلسلة، وللتعمق في الأجزاء التي بني عليها المثال ارجع إلى المقالات التالية:

دليلالأنظمة التي تحتاجها الجامعة: من القبول إلى التخرجأنظمة الجامعة على مسار الطالب من الاستقطاب إلى الخريجين، ولماذا يكون نظام معلومات الطلاب في مركزها.دليلCapability Map: كيف تقرر مصير كل نظام في مؤسستككيف تبني خريطة لقدرات مؤسستك وتربط بها أنظمتك، لتكتشف التكرار والفجوات وتقرر ما تبقيه وما توقفه.دليلهندسة المتطلبات Requirements Engineering من الطلب إلى ما يبنىما هو المتطلب Requirement، وكيف تجمعه وتكتبه وتراجعه وتدير تغييره، ولماذا تفشل مشاريع كبيرة عندما تهمل هذه الخطوة.دليلحساب العائد ROI والقيمة الحالية NPV لمشروعك التقنيكيف تحسب العائد وفترة الاسترداد والقيمة الحالية لمشروع تقني، وتختبر افتراضاته، وتعرضه على قسم المالية في صفحة واحدة.

سجل التحديثات

• أكتوبر 2026: كتابة المقال مع تشغيل السكربتات بلغة Python 3.13.16 في Container من python:3.13.16-slim، وتحليل السجل بمكتبة pm4py 2.7.23.10 مع pandas 3.0.6 وGraphviz 2.42.4، وتحويل الرسوم بمكتبة bpmn-js 18.31.0 المثبتة بأداة npm داخل node:24-alpine، والسجل محاكى بالكامل ولا يمثل جامعة حقيقية.