> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # التحول الرقمي عملياً: خدمة طلب كشف الدرجات - URL: https://arabroot.io/articles/التحول-الرقمي-عمليا-خدمة-طلب-كشف-الدرجات/ - Published: 2026-10-13T14:45:00.000Z - Updated: 2026-10-14T12:16:04.000Z - Description: نرسم خدمة جامعية بلغة BPMN ونقيس أين ينتظر الطلب من سجل أحداث، ثم نصمم الخدمة المستهدفة وخارطة طريق بمؤشرات. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الفرق والمنتج, الاستضافة الذاتية في [المقال الثالث من السلسلة](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%84-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9/) مررنا على الأدوات المفتوحة لكل خطوة من دورة التحول الرقمي Digital Transformation، وفي هذا المقال سوف نطبقها على خدمة واحدة من البداية إلى النهاية: طلب كشف درجات رسمي Official Transcript في جامعة، وهي الخدمة التي بدأنا بها السلسلة في [المقال الأول](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%84-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%85%D8%A7-%D9%87%D9%88-%D9%81%D8%B9%D9%84%D8%A7-%D9%88%D9%85%D8%A7-%D9%84%D9%8A%D8%B3-%D9%83%D8%B0%D9%84%D9%83/)، لأنها تجمع صفات الخدمة المناسبة للبداية: طلبات كثيرة، وانتظار يعرفه الجميع، وأقسام متعددة يمر عليها الطلب. والجامعة في المثال افتراضية، فلا نملك سجلات جامعة حقيقية، ولذلك سوف نولد سجل أحداث محاكى Simulated Event Log بسكربت نكتب افتراضاته كلها، ونحلله بالأدوات الحقيقية نفسها التي ستستخدمها على سجلاتك، فالأرقام في هذا المقال نتيجة الافتراضات، والطريقة هي ما يهمك. المواضيع في السلسلة: 1. ما هو التحول الرقمي Digital Transformation فعلاً؟ 2. منهجية التحول الرقمي: من التقييم إلى خارطة الطريق. 3. أدوات التحول الرقمي المفتوحة: من BPMN إلى البيانات. 4. التحول الرقمي عملياً: خدمة طلب كشف الدرجات. (الموضوع الحالي) وسوف نناقش في هذا المقال ما يلي: - رسم الوضع الحالي As-Is بلغة BPMN من ملف نصي، وتحويله إلى صورة بمكتبة bpmn-js. - سجل الأحداث Event Log: من أين يأتي، وكيف ولدناه للمثال. - قياس المدة والانتظار والتكرار بمكتبة pm4py، ومقارنة السجل بمخطط الإجراء. - نقاط الألم Pain Points مرتبة بما تكلفه من وقت. - الوضع المستهدف To-Be، وتقدير أثره بالطريقة نفسها. - خارطة الطريق على مراحل، والمؤشرات KPIs، وبطاقة الإجراء كما تطلبها المعايير الأساسية. والصورة التالية تبين الخطوات الست والملف الذي تنتجه كل خطوة: ![ست بطاقات مرقمة من اليمين إلى اليسار بينها أسهم: 1 رسم الوضع الحالي وملفه asis.bpmn، 2 سجل الأحداث وملفه asis_log.csv، 3 القياس ونقاط الألم بسكربت mine.py، 4 الوضع المستهدف وملفه tobe.bpmn، 5 خارطة الطريق، 6 المؤشرات من mine-output.txt، وتحتها ملاحظة أن كل خطوة تنتج ملفاً حقيقياً وأن السجل محاكى بافتراضات معلنة](https://arabroot.io/content/images/2026/10/dt-practice-01-steps.webp) كل خطوة تنتج ملفاً يمكن مراجعته وإعادة تشغيله، وليس شريحة في عرض تقديمي ## الخدمة وحدودها أول قرار هو حدود الخدمة، أي متى تبدأ ومتى تنتهي من وجهة نظر المستفيد، وليس من وجهة نظر قسم واحد. والسبب أن كل قسم يقيس الجزء الذي يملكه، فالمالية تقول إنها ترد خلال يومين، والقبول يقول إنه يطبع الكشف في يوم، ولا أحد يقيس المدة كاملة التي ينتظرها الطالب. والحدود في مثالنا كما يلي: - **البداية:** عندما يرسل الطالب الطلب. - **النهاية:** عندما يكون الكشف في يد الطالب، أو في بريده في الوضع المستهدف. - **الأطراف:** الطالب، وعمادة القبول والتسجيل، والإدارة المالية، ومكتب العميد. - **خارج النطاق:** معادلة المقررات وكشوف الطلاب المنقولين من جامعات أخرى، فلها إجراءات مختلفة. ## رسم الوضع الحالي As-Is الوضع الحالي يرسم كما يعمل فعلاً وليس كما في دليل الإجراءات، ولذلك يرسم مع الموظفين الذين ينفذونه. وفي مثالنا يرسل الطالب نموذجاً بالبريد، ويسجله موظف القبول يدوياً، وإذا كان ناقصاً يعيده إلى الطالب، ثم يراسل المالية للتأكد من الرسوم، ثم يطبع الكشف، ثم يوقعه العميد، ثم يختم ويتصل بالطالب ليحضر ويستلمه. وقد يتساءل البعض: لماذا نكتب الرسم بسكربت بدلاً من رسمه في Camunda Modeler؟ والإجابة أن الرسم في البرنامج هو الطريقة الطبيعية لفريق العمل، ولكننا هنا نريد أن يعيد القارئ إنتاج الملف نفسه، فكتبنا سكربت Python صغيراً `gen_bpmn.py` يأخذ الحارات والمهام والأسهم ويكتب ملف BPMN 2.0 كاملاً بمواقع العناصر، والملف الناتج يفتح في Camunda Modeler وbpmn.io كأي ملف رسم بهما. والجزء الذي يصف الوضع الحالي من السكربت كما يلي: ```python # 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 دون أي مكتبة إضافية: ```bash docker run --rm --name lab-dt-py -v "$PWD:/lab" -w /lab python:3.13.16-slim python gen_bpmn.py ``` والمخرج سوف يكون كما يلي: ```text 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` الذي شرحناه في [المقال الثالث](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%84-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9/#bpmn-render)، وكانت نتيجة الاستيراد `warnings=0`، والصورة التالية هي الرسم كما أخرجته bpmn-js: ![رسم BPMN بأربع حارات: الطالب، والقبول والتسجيل، والإدارة المالية، ومكتب العميد، فيه بداية يحتاج كشف درجات، ثم تعبئة النموذج وإرساله بالبريد، ثم استلام الطلب وتسجيله يدوياً، ثم بوابة النموذج مكتمل؟ إذا لا يعود إلى استكمال البيانات الناقصة عند الطالب ثم إلى التسجيل، وإذا نعم مراسلة المالية عن الرسوم، ثم التحقق من سداد الرسوم في المالية، ثم طباعة الكشف، ثم توقيع العميد، ثم الختم والاتصال بالطالب، ثم الحضور والاستلام، ثم نهاية استلم الكشف](https://arabroot.io/content/images/2026/10/dt-practice-02-asis.webp) الوضع الحالي كما رسمته bpmn-js 18.31.0: الطلب يعبر بين الحارات ست مرات على الأقل وفي الرسم أعلاه لاحظ التالي: - كل سهم يعبر من حارة إلى أخرى هو تسليم Hand-off، والطلب الذي يسلك المسار البسيط يعبر ست مرات، ومع كل تسليم صندوق بريد ينتظر فيه. - الحلقة بين «النموذج مكتمل؟» و«استكمال البيانات الناقصة» لا تظهر في أغلب أدلة الإجراءات، ولكنها جزء من الواقع، وسوف نقيس حجمها بعد قليل. - لا توجد مهمة واحدة آلية، فكل المهام بأيقونة الشخص. ## سجل الأحداث Event Log الرسم يقول ما هي الخطوات، ولكنه لا يقول كم تستغرق ولا أين ينتظر الطلب، ولذلك نحتاج سجل أحداث فيه لكل طلب كل خطوة مع وقت بدايتها ووقت انتهائها ومن نفذها. وفي جامعة حقيقية تجمع هذا السجل من المصادر التالية: - **البريد المشترك:** وقت وصول كل رسالة ووقت الرد عليها، مع رقم الطالب في العنوان. - **نظام التذاكر أو مكتب الخدمة:** إذا كانت الطلبات تسجل فيه، فكل تغيير في حالة التذكرة حدث. - **سجل التدقيق Audit Log في نظام الطلاب SIS:** وقت طباعة الكشف ومن طبعه. - **دفتر التوقيع أو التسليم:** إذا كان ورقياً فأول مبادرة في خارطة الطريق هي أن يصبح جدولاً. ولأن الجامعة في مثالنا افتراضية فقد كتبنا سكربت `simulate_log.py` يولد 300 طلب ببذرة عشوائية ثابتة Fixed Seed، فيخرج السجل نفسه في كل تشغيل، والافتراضات التي فيه كما يلي: | الافتراض | القيمة في السكربت | | -------------------- | ------------------------------------------------------------------------------------------------------------ | | وصول الطلبات | طلبان ونصف في اليوم في المتوسط، من 4 يناير 2026 | | ساعات العمل | من الأحد إلى الخميس، من 8:00 إلى 15:00، وكل عمل للموظفين يبدأ داخلها | | الانتظار قبل كل خطوة | توزيع ملتو إلى اليمين Lognormal بوسيط مختلف لكل خطوة، مثل 20 ساعة في البريد المشترك و40 ساعة في بريد المالية | | النموذج الناقص | 28% من الطلبات تعاد مرة، و12% مما يعاد يعاد مرة أخرى، وثلاث مرات على الأكثر | | توقيع العميد | دفعتان في الأسبوع، الأحد والأربعاء الساعة 10:00، و15% من المرات يكون العميد مسافراً فيتأخر أسبوعاً | | الاستلام | يحضر الطالب بعد الاتصال بوسيط 40 ساعة، في ساعات العمل | | وقت العمل الفعلي | من 3 إلى 15 دقيقة لكل خطوة | ونشغل السكربت بالطريقة نفسها: ```bash 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" ``` والمخرج سوف يكون كما يلي: ```text 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 الذي ترسم به المكتبة مخططاتها، ونبقيه يعمل حتى نعيد التحليل أكثر من مرة: ```bash 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) '" ``` والمخرج سوف يكون كما يلي: ```text 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`، ثم التطابق مع الرسم. ونشغله كما يلي: ```bash docker exec lab-dt-pm4py sh -c "cd /art/lab && python mine.py" > mine-output.txt 2>&1 ``` والمخرج للوضع الحالي سوف يكون كما يلي، وقد حذفنا منه رسالة الترخيص التي تطبعها المكتبة في أوله، وعرضناها في المقال الثالث: ```text ===== 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` بالوسيط، وكل سهم عليه الوقت الوسيط بين الخطوتين: ![مخطط أفقي من pm4py فيه الخطوات بالإنجليزية من Submit form by email إلى Collect in person، وعلى كل سهم الوقت الوسيط: 1D إلى Log request، و4h إلى Ask finance، و2D باللون الأحمر إلى Confirm fee، و17h إلى Print transcript، و2D بالأحمر إلى Dean signs، و21h إلى Stamp and call، و2D بالأحمر إلى Collect in person، وحلقة 1D بين Log request وFix missing data](https://arabroot.io/content/images/2026/10/dt-practice-03-perf-dfg.webp) الأسهم الحمراء الثلاثة هي نقاط الألم الكبرى، وكل واحد منها انتظار بين قسمين ## هل يطابق السجل الرسم؟ وماذا يحدث إذا رسمنا المسار البسيط فقط؟ أغلب أدلة الإجراءات ترسم المسار البسيط Happy Path فقط، أي الطلب المكتمل من أول مرة، ولذلك أضفنا إلى السكربت نسخة ثالثة من الرسم `asis_happy.bpmn` بلا حلقة الاستكمال، وقارنا السجل بالمخططين بطريقة إعادة التشغيل بالرموز Token-Based Replay في الدالة `pm4py.fitness_token_based_replay`، بعد تحويل أسماء الخطوات في السجل إلى الأسماء العربية في الرسم. والجزء الخاص بذلك من المخرج كما يلي: ```text 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 وحولناه إلى صورة بالطريقة نفسها: ![رسم BPMN أفقي اكتشفته pm4py من السجل دون حارات: start ثم Submit form by email ثم بوابة ثم Log request ثم بوابة تذهب إلى Ask finance أو إلى Fix missing data التي تعود إلى البوابة الأولى، ثم Confirm fee ثم Print transcript ثم Dean signs ثم Stamp and call ثم Collect in person ثم end](https://arabroot.io/content/images/2026/10/dt-practice-04-discovered.webp) الرسم المكتشف من السجل فيه حلقة الاستكمال نفسها، ولكنه لا يعرف الحارات لأن السجل لا يقول من يملك كل قسم وهذا الرسم مفيد عندما لا يوجد رسم أصلاً، أو عندما يختلف الموظفون في وصف الإجراء، فتبدأ النقاش من الرسم المكتشف بدلاً من ذاكرة كل شخص. ## نقاط الألم مرتبة بما تكلفه من الأرقام أعلاه نكتب نقاط الألم، وكل نقطة لها رقم من السجل وسبب ومعالجة، والجدول التالي مرتب بنصيب كل نقطة من مجموع الانتظار: | نقطة الألم | القياس من السجل | السبب | المعالجة في الوضع المستهدف | | -------------------------- | --------------------------------------------- | ------------------------------------- | ------------------------------------------ | | انتظار توقيع العميد | وسيط 68.6 ساعة، و23.6% من الانتظار | توقيع يدوي على دفعات مرتين في الأسبوع | ختم إلكتروني ورمز تحقق | | الحضور للاستلام | وسيط 71.9 ساعة، و22.8% من الانتظار | الكشف ورقي ويجب أن يأتي الطالب إليه | إرسال الكشف إلكترونياً | | التحقق من الرسوم | وسيط 66.7 ساعة، و20.1% من الانتظار | مراسلة بالبريد بين قسمين | دفع إلكتروني يغني عن السؤال | | البريد المشترك قبل التسجيل | وسيط 30.9 ساعة، و15.1% من الانتظار | الطلب يصل بالبريد وينتظر من يفتحه | الطلب في البوابة مباشرة | | الاستكمال وإعادة الإرسال | 28.3% من الطلبات، وثلاث جولات في أسوأ الحالات | نموذج حر بلا تحقق من الحقول | بيانات الطالب تأتي من SIS، والحقول إلزامية | وفي الجدول أعلاه لاحظ أن أي تحسين في سرعة الموظفين أنفسهم لن يغير المدة تقريباً، لأن العمل الفعلي 0.36% من عمر الطلب، فلو أصبح كل موظف أسرع بالضعف لنقصت المدة دقائق من أصل أيام، والمكسب الحقيقي في حذف الانتظار بين الأقسام. ## الوضع المستهدف To-Be صممنا الوضع المستهدف على خمسة مبادئ، وكل مبدأ يعالج نقطة ألم من الجدول السابق: - **البيانات من مصدرها:** بيانات الطالب تأتي من SIS، فلا يكتبها ولا تنقص. - **الدفع جزء من الطلب:** لا يوجد سؤال للمالية، فالدفع إما تم وإما لم يتم. - **الإصدار آلي:** الكشف يصدر من SIS مباشرة، ويختم إلكترونياً مع رمز تحقق يستطيع أي طرف أن يتحقق به من صحته. - **الإنسان للاستثناءات:** موظف القبول يرى فقط الطلبات التي على سجلها ملاحظة، مثل إيقاف أو رسوم معلقة. - **التسليم إلكتروني:** الكشف يصل إلى بريد الطالب أو حسابه، ويبقى الكشف الورقي لمن يطلبه. والصورة التالية هي الرسم المستهدف كما أخرجته bpmn-js من الملف `tobe.bpmn`: ![رسم BPMN بثلاث حارات: الطالب يقدم الطلب في البوابة ثم الدفع الإلكتروني، ثم في حارة البوابة ونظام الطلاب SIS إصدار الكشف من SIS ثم بوابة توجد ملاحظة على السجل؟ إذا نعم مراجعة الحالة الاستثنائية في حارة القبول والتسجيل، وإذا لا مباشرة إلى ختم إلكتروني ورمز تحقق، ثم إرسال الكشف وإشعار الطالب، ثم نهاية استلم الكشف](https://arabroot.io/content/images/2026/10/dt-tools-03-bpmn-js.webp) ثلاث مهام آلية بأيقونة الترس، والموظف يظهر في مسار الاستثناء فقط ثم ولدنا سجلاً للوضع المستهدف بالسكربت نفسه وبافتراضات جديدة، أهمها أن 8% من الطلبات عليها ملاحظة تحتاج مراجعة موظف بوسيط انتظار 10 ساعات في ساعات العمل، وأن الخطوات الآلية تأخذ دقيقة، ثم حللناه بالتحليل نفسه. وهذا ليس قياساً وإنما تقدير Projection من افتراضات، والغرض منه أن ترى أثر التصميم قبل البناء، وأن تكتب الهدف في سجل المنافع بطريقة القياس نفسها. والجزء الخاص به من المخرج كما يلي: ```text ===== 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%، وهذا طبيعي في عينة صغيرة. ## خارطة الطريق على مراحل الوضع المستهدف لا يبنى دفعة واحدة، فبعض أجزائه يحتاج تعديل لائحة واعتماد الختم الإلكتروني، وبعضها يمكن أن يبدأ الشهر القادم، ولذلك رتبناه على أربع مراحل كما في الصورة التالية: ![أربع بطاقات من اليمين إلى اليسار تحت شريط ملون: المرحلة 0 خط الأساس لمدة أسبوعين فيها سجل أحداث ورسم الوضع الحالي وسجل المنافع ومؤشرها المدة الوسيطة 12.7 يوماً، المرحلة 1 الآن مكاسب سريعة لمدة 6 أسابيع فيها نموذج في البوابة ببيانات من SIS ورقم متابعة ومؤشرها الصحيح من أول مرة من 71.7% إلى 95%، المرحلة 2 التالي ربط الأنظمة لمدة 3 أشهر فيها دفع إلكتروني وإرسال الكشف إلكترونياً ومؤشرها حذف 42.9% من الانتظار، المرحلة 3 لاحقاً الخدمة المستهدفة لمدة 3 إلى 6 أشهر فيها الإصدار من SIS بختم إلكتروني وتعديل اللائحة ومؤشرها المدة الوسيطة أقل من يوم](https://arabroot.io/content/images/2026/10/dt-practice-06-roadmap.webp) كل مرحلة لها مؤشر من السجل نفسه، وتقاس قبل أن تبدأ المرحلة التالية وفي خارطة الطريق أعلاه لاحظ التالي: - المرحلة الأولى لا تحتاج تكاملاً معقداً، ولكنها تحذف حلقة الاستكمال التي أصابت 28.3% من الطلبات، وتبني ثقة الإدارة برقم يتحسن خلال أسابيع. - المرحلة الثانية تحذف انتظار المالية والاستلام، وهما معاً 42.9% من الانتظار في السجل. - المرحلة الثالثة هي الأصعب، لأن أكبر نقطة ألم، وهي التوقيع، تحتاج قراراً تنظيمياً قبل الكود، وهذه هي خطوة «إزالة العوائق» في نموذج Kotter التي شرحناها في [المقال الثاني](https://arabroot.io/articles/%D9%85%D9%86%D9%87%D8%AC%D9%8A%D8%A9-%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%84-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D9%84%D9%89-%D8%AE%D8%A7%D8%B1%D8%B7%D8%A9-%D8%A7%D9%84%D8%B7%D8%B1%D9%8A%D9%82/#change). - المدد تقدير للتخطيط، وتراجع بعد قياس كل مرحلة. ## المؤشرات KPIs وسجل المنافع كل مؤشر في الجدول التالي يحسب بالسكربت نفسه من سجل الأحداث، فلا يحتاج موظفاً يجمعه، وخط الأساس من سجل الوضع الحالي المحاكى، والهدف من التقدير مع هامش: | المؤشر | التعريف | خط الأساس | الهدف | المالك | | ------------------ | --------------------------------------------- | --------------- | --------------------------- | -------------------- | | المدة الوسيطة | من إرسال الطلب إلى استلام الكشف، لنصف الطلبات | 12.7 يوماً | أقل من يوم بعد المرحلة 3 | عميد القبول والتسجيل | | مدة 90% من الطلبات | المدة التي تنتهي قبلها 90% من الطلبات | 19.9 يوماً | أقل من 3 أيام بعد المرحلة 3 | عميد القبول والتسجيل | | الصحيح من أول مرة | نسبة الطلبات التي لم تحتج استكمالاً | 71.7% | 95% بعد المرحلة 1 | رئيس قسم الوثائق | | التسليمات لكل طلب | عدد مرات انتقال الطلب بين الأطراف، بالوسيط | 6 | 1 بعد المرحلة 3 | مالك الخدمة | | اللمسات اليدوية | عدد خطوات الأشخاص لكل طلب، بالوسيط | 8 | 2، وكلاهما للطالب | مالك الخدمة | | مدة الاستثناءات | المدة لطلبات الاستثناء فقط، لـ 90% منها | غير موجود اليوم | يومان | رئيس قسم الوثائق | والمؤشر الأخير غير موجود في الوضع الحالي لأن كل الطلبات تمر على الموظف، ولكنه أهم مؤشر بعد التحول، لأن الطلبات الآلية ستكون سريعة دائماً، والطالب الذي ينتظر هو صاحب الاستثناء. ## بطاقة الإجراء كما في المعايير الأساسية في [المقال الثاني](https://arabroot.io/articles/%D9%85%D9%86%D9%87%D8%AC%D9%8A%D8%A9-%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%84-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D9%84%D9%89-%D8%AE%D8%A7%D8%B1%D8%B7%D8%A9-%D8%A7%D9%84%D8%B7%D8%B1%D9%8A%D9%82/#maturity) ذكرنا أن المعيار 5.7.2 في المعايير الأساسية للتحول الرقمي يطلب بطاقة لكل إجراء بعناصر محددة، والجدول التالي يملؤها لخدمتنا من ملفات هذا المقال: | عنصر البطاقة كما في المعيار | القيمة في خدمة الكشف | | --------------------------- | --------------------------------------------- | | اسم العملية أو الإجراء | طلب كشف درجات رسمي | | رمز موحد وفريد | رمز من سجل الإجراءات، مثل ADM-REG-007 | | وصف موجز | إصدار كشف درجات رسمي للطالب أو الخريج وتسليمه | | المسؤول عن الإجراء | عمادة القبول والتسجيل | | تصنيف الإجراء | رئيسي | | مستوى الأهمية | عال، لكثرة الطلبات وأثرها على الطالب | | مخطط تدفق الإجراء BPMN | الملفان asis.bpmn وtobe.bpmn والصورتان منهما | | مؤشرات الأداء | جدول المؤشرات أعلاه، محسوبة من سجل الأحداث | والرمز في الجدول مثال من عندنا، فاستخدم نظام الترقيم الذي يعتمده سجل الإجراءات في جهتك. ولاحظ أن المعيار يطلب أيضاً آلية لترقيم الإصدارات، وحفظ ملفات BPMN في مستودع Git يعطيك ذلك دون جهد إضافي، فكل تعديل على الإجراء له تاريخ ومؤلف وسبب. ## ملفات المثال كل ملفات المثال في مجلد `lab` مع المقال، وهي كما يلي: | الملف | ما فيه | | ---------------- | ---------------------------------------------------------- | | gen\_bpmn.py | يكتب asis.bpmn وasis\_happy.bpmn وtobe.bpmn بمواقع العناصر | | simulate\_log.py | يولد asis\_log.csv وtobe\_log.csv بالافتراضات المكتوبة فيه | | mine.py | التحليل بمكتبة pm4py، ويكتب discovered.bpmn ومخطط الأداء | | render.mjs | يحول ملفات BPMN إلى SVG وصور بمكتبة bpmn-js | | \*-output.txt | المخرجات كما خرجت من كل تشغيل | وبعد الانتهاء نحذف ما أنشأناه بالاسم فقط: ```bash 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 دقيقة من افتراضات معلنة. - خارطة الطريق أربع مراحل لكل منها مؤشر من السجل نفسه، وأصعبها يحتاج قراراً تنظيمياً قبل الكود. وبهذا تكتمل السلسلة، وللتعمق في الأجزاء التي بني عليها المثال ارجع إلى المقالات التالية: [![](https://arabroot.io/content/images/2026/10/university-systems-cover-cover.webp)دليلالأنظمة التي تحتاجها الجامعة: من القبول إلى التخرجأنظمة الجامعة على مسار الطالب من الاستقطاب إلى الخريجين، ولماذا يكون نظام معلومات الطلاب في مركزها.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D8%AA%D9%8A-%D8%AA%D8%AD%D8%AA%D8%A7%D8%AC%D9%87%D8%A7-%D8%A7%D9%84%D8%AC%D8%A7%D9%85%D8%B9%D8%A9-%D9%85%D9%86-%D8%A7%D9%84%D9%82%D8%A8%D9%88%D9%84-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%AA%D8%AE%D8%B1%D8%AC/)[![](https://arabroot.io/content/images/2026/10/capability-map-cover-cover.webp)دليلCapability Map: كيف تقرر مصير كل نظام في مؤسستككيف تبني خريطة لقدرات مؤسستك وتربط بها أنظمتك، لتكتشف التكرار والفجوات وتقرر ما تبقيه وما توقفه.](https://arabroot.io/articles/%D8%AE%D8%B1%D9%8A%D8%B7%D8%A9-%D9%82%D8%AF%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D8%B9%D9%85%D8%A7%D9%84-%D9%88%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D9%85%D8%AD%D9%81%D8%B8%D8%A9-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/requirements-engineering-cover-cover.webp)دليلهندسة المتطلبات Requirements Engineering من الطلب إلى ما يبنىما هو المتطلب Requirement، وكيف تجمعه وتكتبه وتراجعه وتدير تغييره، ولماذا تفشل مشاريع كبيرة عندما تهمل هذه الخطوة.](https://arabroot.io/articles/%D9%87%D9%86%D8%AF%D8%B3%D8%A9-%D8%A7%D9%84%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-requirements-engineering/)[![](https://arabroot.io/content/images/2026/10/business-case-cover-cover.webp)دليلحساب العائد ROI والقيمة الحالية NPV لمشروعك التقنيكيف تحسب العائد وفترة الاسترداد والقيمة الحالية لمشروع تقني، وتختبر افتراضاته، وتعرضه على قسم المالية في صفحة واحدة.](https://arabroot.io/articles/%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D8%AF%D8%B1%D8%A7%D8%B3%D8%A9-%D8%A7%D9%84%D8%AC%D8%AF%D9%88%D9%89-roi-%D9%88-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، والسجل محاكى بالكامل ولا يمثل جامعة حقيقية.