Arabic:التطوير بدون برمجة وببرمجة منخفضة

مقدمة

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

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

الفكرة المركزية: لا تعني عبارة «بدون برمجة» أن الحل لا يحتاج إلى تحليل أو تصميم أو اختبار أو حوكمة. كما لا تعني «برمجة منخفضة» أن الشيفرة عديمة الأهمية؛ بل تعني أن الجزء الأكبر من الحل يبنى مرئيًا، وتستخدم الصيغ أو التعبيرات أو الواجهات البرمجية أو المكوّنات المخصصة عندما تضيف قيمة حقيقية.

مثال على عائلة أدوات منخفضة البرمجة لبناء تطبيقات وأتمتة وتحليلات

مثال على منصة بدون برمجة لبناء تطبيقات قائمة على البيانات

أهداف التعلم

بعد إكمال الدورة ستكون قادرًا على:

1. تحليل عملية عمل وتحويل المشكلة إلى متطلبات واضحة وحد أدنى قابل للتجربة.
2. تصميم نموذج إلكتروني يجمع بيانات صحيحة وقابلة للاستخدام.
3. تنظيم البيانات في جداول وحقول ومعرّفات وعلاقات مناسبة.
4. بناء سير عمل يحتوي على محفز وشروط وإجراءات وموافقات وإشعارات.
5. إنشاء لوحة معلومات تربط مؤشرات الأداء بالقرارات العملية.
6. تركيب تطبيق أعمال بسيط يجمع الواجهة والبيانات والأتمتة والتقارير.
7. تقييم الفرق بين بدون برمجة والبرمجة المنخفضة والتطوير التقليدي واختيار النهج الأنسب.
8. تطبيق مبادئ الأمن والصلاحيات والحوكمة والاختبار والإدارة خلال دورة حياة الحل.

المحتوى التعليمي

من المشكلة إلى الحل الرقمي

ابدأ دائمًا بالعملية لا بالأداة. اسأل: من يقوم بالعمل؟ ما الحدث الذي يبدأ العملية؟ ما البيانات التي تدخل؟ ما القرار الذي يجب اتخاذه؟ ما النتيجة المطلوبة؟ وأين يحدث التأخير أو التكرار أو الخطأ؟ هذه الأسئلة تمنعك من بناء تطبيق جميل لا يحل المشكلة الأصلية.

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

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

مثال بصري على ربط الأشخاص والمستودعات وخطوات سير العمل؛ ركز على تدفق العملية أكثر من النصوص الإنجليزية داخل الرسم

قبل البناء، ارسم نسخة مبسطة من العملية الحالية ثم نسخة محسنة. لا تؤتمت خطوة غير ضرورية لمجرد أنها موجودة في الإجراء القديم. تحسين العملية يسبق أتمتتها.

بدون برمجة أم برمجة منخفضة أم تطوير تقليدي؟

الحدود بين هذه الأساليب ليست حادة، لكن المقارنة التالية تساعدك على الاختيار:

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

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

قاعدة مهنية: اختر أبسط نهج يحقق المتطلبات مع مستوى مقبول من الأمن والصيانة والمرونة، ولا تجعل الحماس للأداة سببًا لتجاهل المخاطر.

بناء النماذج وجمع البيانات

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

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

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

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

تنظيم البيانات وقواعد البيانات

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

رمز بصري لمصدر البيانات الذي تعتمد عليه النماذج والتطبيقات وسير العمل

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

لماذا العلاقات مهمة؟ لأنها تمنع التكرار وتقلل التناقض. إذا تغيّر اسم قسم ما، فمن الأفضل تحديثه في سجل القسم لا في آلاف الطلبات القديمة. كما تساعد العلاقات على عرض «كل طلبات هذا القسم» أو «كل الموافقات المتعلقة بهذا الطلب» بسهولة.

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

تصميم سير العمل والأتمتة

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

مثال على أداة لأتمتة التدفقات بين التطبيقات والخدمات

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

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

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

تحميل الفيديو

يوتيوب

قد يقوم يوتيوب بجمع البيانات الشخصية. سياسة الخصوصية

استمرار تجاهل

إنشاء لوحات المعلومات ومؤشرات الأداء

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

مثال بصري على جمع مؤشرات ورسوم متعددة في شاشة واحدة لدعم المتابعة والقرار

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

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

تحميل الفيديو

يوتيوب

قد يقوم يوتيوب بجمع البيانات الشخصية. سياسة الخصوصية

استمرار تجاهل

تركيب تطبيق أعمال بسيط

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

مثال على أداة لبناء تطبيقات أعمال بواجهات مرئية واتصال بمصادر بيانات

مثال على عرض العناصر في أعمدة تمثل مراحل مختلفة من العمل

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

قد تبدأ بمنصة بدون برمجة مثل Google AppSheet عندما تكون البيانات والعملية مباشرتين، أو بمنصة منخفضة البرمجة مثل Microsoft Power Apps عندما تحتاج إلى تخصيص أكبر أو تكامل مع منظومة مؤسسية. الاختيار يعتمد على البيئة والبيانات والصلاحيات والتكلفة والمهارات ومتطلبات التكامل، وليس على شهرة الاسم.

تحميل الفيديو

يوتيوب

قد يقوم يوتيوب بجمع البيانات الشخصية. سياسة الخصوصية

استمرار تجاهل

البرمجة المنخفضة: أين تدخل الشيفرة أو الصيغ؟

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

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

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

الأمن والحوكمة ودورة حياة الحل

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

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

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

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

متى لا تكون المنصات المرئية هي الاختيار الأفضل؟

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

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

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

مشروع تطبيقي متكامل: من نموذج إلى تطبيق

تخيل أنك مسؤول عن تحسين عملية «طلب حضور دورة تدريبية». ابدأ بنموذج يحتوي على الموظف، الدورة، التكلفة، سبب الحاجة، والموعد. خزّن الطلب في جدول منظم مرتبط بالموظف والقسم. أنشئ سير عمل يرسل الطلب إلى المدير ثم إلى مسؤول التطوير عند تجاوز التكلفة حدًا داخليًا. بعد القرار حدّث الحالة وأرسل إشعارًا. أنشئ لوحة تعرض عدد الطلبات المفتوحة، متوسط زمن القرار، التوزيع حسب القسم، ونسبة القبول.

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

بهذا المشروع تكون قد ربطت المكونات الأساسية كلها: نموذج + بيانات + سير عمل + صلاحيات + لوحة معلومات + تطبيق + اختبار + حوكمة.

مهام تفاعلية

اختبار: اختبر معرفتك

ما الوصف الأدق للفرق بين التطوير بدون برمجة والتطوير ببرمجة منخفضة؟ (التطوير ببرمجة منخفضة يسمح عادة بتوسعات وصيغ أو شيفرة محدودة عند الحاجة) (!التطوير بدون برمجة يتطلب دائمًا كتابة شيفرة أكثر) (!النهجان لا يستخدمان واجهات مرئية) (!التطوير ببرمجة منخفضة لا يمكنه الاتصال بالبيانات)

ما الخطوة الأفضل قبل اختيار منصة لبناء حل أعمال؟ (فهم العملية والمستخدمين والبيانات والنتيجة المطلوبة) (!اختيار أكثر منصة تحتوي على قوالب) (!تصميم الألوان والشعار أولًا) (!إنشاء لوحة معلومات قبل جمع البيانات)

لماذا يفيد وجود معرّف فريد لكل سجل؟ (لتمييز السجل وربطه بالسجلات الأخرى دون التباس) (!لزيادة عدد الحقول في النموذج) (!لمنع المستخدم من رؤية البيانات) (!لإلغاء الحاجة إلى اختبار التطبيق)

ما العنصر الذي يبدأ سير العمل الآلي عادة؟ (المحفز) (!التنسيق البصري) (!لون الزر) (!عنوان لوحة المعلومات)

ما أفضل نقطة بداية لتصميم لوحة معلومات إدارية؟ (تحديد السؤال أو القرار الذي يجب أن تدعمه اللوحة) (!إضافة أكبر عدد ممكن من الرسوم) (!اختيار الألوان قبل المؤشرات) (!نسخ كل أعمدة قاعدة البيانات إلى الشاشة)

ما المقصود بمصدر الحقيقة في إدارة البيانات؟ (المكان المرجعي المعتمد الذي تمثل بياناته النسخة الأساسية للمعلومة) (!نسخة إضافية ينشئها كل مستخدم) (!ملف مؤقت يستخدم أثناء العرض) (!رسم بياني يعرض البيانات)

متى يكون التوسع منخفض البرمجة مناسبًا؟ (عندما تحتاج إلى منطق أو تكامل لا توفره المكونات القياسية بشكل كاف) (!عندما تريد تعقيد الحل دون حاجة) (!عندما لا يوجد أي متطلب وظيفي) (!عندما تريد تجنب التوثيق والاختبار)

أي ممارسة تدعم الحوكمة الجيدة؟ (معرفة مالك كل تطبيق ومصادر بياناته وصلاحياته وخطة صيانته) (!منح جميع المستخدمين صلاحية كاملة) (!إنشاء التطبيقات بحسابات شخصية مجهولة) (!تجنب تسجيل التغييرات)

ما الفائدة الأساسية من تجربة حل أولي مع مجموعة صغيرة قبل التوسع؟ (كشف مشكلات الاستخدام والبيانات والمنطق قبل تعميم الحل) (!إلغاء الحاجة إلى الأمن) (!ضمان أن كل المتطلبات لن تتغير) (!إلغاء الحاجة إلى التدريب)

متى قد يكون التطوير التقليدي أنسب من منصة مرئية؟ (عندما تتطلب الحالة أداء أو تخصيصًا أو خوارزميات تتجاوز حدود المنصة) (!عندما نحتاج إلى نموذج إدخال بسيط) (!عندما نريد إشعارًا بعد إرسال طلب) (!عندما نريد قائمة مهام داخلية صغيرة)

لعبة الذاكرة

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

السحب والإفلات

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

كلمات متقاطعة

نموذج	واجهة تستخدم لإدخال بيانات منظمة
بيانات	معلومات تحفظ في سجلات وحقول
أتمتة	تنفيذ خطوات عمل تلقائيًا وفق قواعد
صلاحيات	قواعد تحدد من يمكنه الوصول أو التعديل
اختبار	تحقق من سلوك الحل قبل الإطلاق وبعد التغييرات
واجهة	الجزء المرئي الذي يتعامل معه المستخدم داخل التطبيق

مهام مفتوحة

سهل

1. خريطة عملية بسيطة: اختر إجراءً متكررًا في عملك وارسم مساره الحالي من البداية إلى النهاية مع تحديد الشخص والبيانات في كل خطوة.
2. نموذج طلب عملي: صمم نموذجًا ورقيًا أو رقميًا لطلب داخلي من ستة إلى ثمانية حقول، ثم اختبر وضوحه مع زميل.
3. قاموس بيانات مصغر: أنشئ قائمة بعشرة حقول لحالة عمل حقيقية، وحدد نوع كل حقل ومثالًا صحيحًا لقيمته.
4. مؤشر قرار: اختر قرارًا إداريًا واحدًا وحدد مؤشرًا يمكن أن يساعد في اتخاذه، مع تعريف واضح لكيفية حسابه.

متوسط

1. نموذج وسير موافقة: أنشئ نموذجًا لطلب إجازة أو شراء أو تدريب واربطه بسير موافقة يحتوي على شرط واحد على الأقل وإشعار للنتيجة.
2. قاعدة بيانات مترابطة: صمم جدولين أو ثلاثة جداول مترابطة لمتابعة العملاء أو الأصول أو الطلبات، واستخدم معرّفات فريدة بدل نسخ المعلومات المتكررة.
3. لوحة معلومات تشغيلية: أنشئ لوحة تعرض ثلاثة إلى خمسة مؤشرات من بيانات تجريبية، ثم اشرح ما القرار الذي يدعمه كل مؤشر.
4. اختبار مستخدم: اطلب من شخص تنفيذ سيناريو كامل في نموذج أو تطبيق أولي، وسجل نقاط التردد والأخطاء ثم عدّل التصميم بناء عليها.

متقدم

1. تطبيق أعمال متكامل: ابن حلًا يجمع نموذجًا وقاعدة بيانات وسير عمل ولوحة متابعة لعملية مهنية حقيقية باستخدام بيانات تجريبية غير حساسة.
2. مراجعة حوكمة: أنشئ قائمة تحقق تغطي المالك والصلاحيات ومصادر البيانات والبيئات والتوثيق والتراخيص وخطة الاستمرارية ثم طبقها على حل موجود.
3. مقارنة منصات: قارن منصتين على أساس التكامل والحوكمة وقابلية التوسع والتكلفة وتجربة المستخدم وإمكانية التخصيص، وقدّم قرارًا مبررًا لحالة استخدام واحدة.
4. دراسة تحسين عملية: قابل صاحب عملية مهنية بعد موافقته، وثق الوضع الحالي، واقترح تصميمًا مستقبليًا، ونفذ نموذجًا أوليًا، ثم اعرض أثره المتوقع ومخاطره وحدوده في فيديو أو عرض قصير.

مجالات تعلم مرتبطة

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

مسرد

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