07 مارس 2025·3 دقيقة
كيفية إنشاء تطبيق ويب لتدفقات الموافقات الداخلية (بدون كود)
تعلّم كيفية بناء تطبيق موافقات داخلية بدون كود: خرّط الخطوات، صمّم النماذج، عيّن الأدوار، أتمت التوجيه، أضف سجل تدقيق، وأطلق التطبيق بأمان.
تعلّم كيفية بناء تطبيق موافقات داخلية بدون كود: خرّط الخطوات، صمّم النماذج، عيّن الأدوار، أتمت التوجيه، أضف سجل تدقيق، وأطلق التطبيق بأمان.
تطبيق الموافقات الداخلية هو نظام لنقل طلب من "شخص يحتاج شيئًا" إلى "تم اتخاذ قرار—ونستطيع إثباته لاحقًا". الأفضل منها يقوم ببعض الوظائف الأساسية باستمرار، حتى عندما يختلف المسار الدقيق بين الفرق.
تتضمن معظم تدفقات الموافقة الداخلية:
سترى نفس النمط في العديد من العمليات:
أدوات الـno-code غالبًا ما تكون مناسبة لأنها تتيح للفرق الإطلاق بسرعة، التكرار الأسبوعي، والحفاظ على الملكية من قبل الأشخاص الذين يديرون العملية. يمكنك بناء النماذج، قواعد التوجيه، الإشعارات، ولوحات المعلومات دون انتظار قائمة تطوير تقليدية.
استعن بالمهندسين إذا كان لديك حالات حافة مثل التوجيهات الشرطية المعقدة (فروع عديدة)، احتياجات إقامة بيانات صارمة، قيود SSO مخصصة، أو تكاملات معقّدة تتطلب طبقة وسيطة ومعالجة أخطاء موثوقة. في كثير من المؤسسات، يمكن للأدوات بدون كود التعامل مع واجهة المستخدم بينما يكمل الهندسة الفجوات.
إذا رغبت بشيء أقرب إلى “مخصص” دون الالتزام ببناء كامل، فإن منصة توليد الكود مثل Koder.ai يمكن أن تكون وسيطًا: تصف سير العمل في دردشة، وتولّد التطبيق (غالبًا React على الواجهة الأمامية، Go + PostgreSQL على الخلفية) مع خيارات لتصدير الشفرة المصدرية، النشر/الاستضافة، لقطات، والتراجع — مفيد عندما يبدأ مسار الموافقة بسيطًا لكنه يحتاج إلى التصلب مع الوقت.
قبل فتح أداة البناء، اختر عملية واحدة للموافقة الداخلية لتتعامل معها أولاً. الهدف هو إثبات القيمة بسرعة، ثم إعادة استخدام نفس النمط لتدفقات الموافقات الأخرى.
المرشح الجيد عادةً يكون:
أمثلة: طلبات الشراء تحت عتبة، موافقات الإجازات، مراجعة المحتوى/القانون لقالب محدد، أو إدخال مورد بسيط.
كن محددًا بشأن ما يعنيه "الإرسال" في نموذجك لسير النموذج إلى الموافقة:
إذا كان الموافقون يطلبون نفس التفاصيل المفقودة بشكل متكرر، اجعلها مطلوبة في الإصدار الأول.
اكتب كل شخص (أو دور) مشارك وأين تُتخذ القرارات: المراجعون، الموافقون، المالية، القانونية، وأي مفوّضين للإجازات. سجل أيضًا القرارات "الطرفية" مثل "إرساله للتعديل" أو "طلب معلومات إضافية"، لأن تلك تحرك معظم المتابعات.
اختر 2–3 نتائج قابلة للقياس:
مع بداية ونهاية ومقاييس نجاح محددة، تصبح بقية خيارات أتمتة سير العمل أسهل بكثير.
قبل لمس أداة البناء، خرّط مسار الموافقة على صفحة واحدة. هذا يمنع تدفقات "تعمل تقريبًا"—حيث تتعطل الطلبات، تُوجّه إلى الشخص الخطأ، أو تتنقّل بدون نهاية واضحة.
ابدأ بهيكل أساسي يمكنك قراءته بصوت عالٍ:
إرسال → مراجعة → موافقة/رفض → إغلاق
لكل خطوة، سمّ من يقوم بها (دور أو فريق)، ما الذي يحتاجون رؤيته، وما الذي يمكنهم تقريره. إذا لم تستطع وصف خطوة في جملة واحدة، فغالبًا ما تخفي عدة أعمال يجب فصلها.
وضّح ما إذا كانت المراجعات تتم:
التدفقات المتوازية تحتاج قاعدة لـ"تم": الجميع يجب أن يوافقوا، أي واحد يكفي، أو الأغلبية. اختر واحدًا الآن—التغيير لاحقًا غالبًا ما يفرض إعادة بناء.
الرفض يمكن أن يعني:
اختر ما يناسب الامتثال والتقارير. "تعديل وإعادة تقديم" شائع، لكن ينبغي تسجيل القرار الأصلي أيضًا.
خرّط المسارات غير السعيدة مقدمًا:
إذا وثّقت هذه على الورق أولًا، يصبح البناء تكوينًا بدل التخمين.
يعمل تطبيق الموافقات بدون كود أفضل عندما يكون نموذج البيانات بسيطًا، متسقًا، وسهل التقرير لاحقًا. قبل بناء الشاشات، قرر السجلات التي ستخزنها وكيف ترتبط.
لأغلب حالات الموافقة الداخلية، يمكنك تغطية 90% من الاحتياجات ببضع جداول (أو مجموعات):
اجعل الطلب المصدر الوحيد للحقيقة. يجب أن تشير كل شيء آخر إليه.
حدد الحقول الأساسية اللازمة للتوجيه واتخاذ القرار. الحقول المطلوبة النموذجية:
كل الباقي يمكن أن يبدأ اختياريًا. يمكنك إضافة حقول لاحقًا بعدما ترى ما يطلبه المراجعون فعلاً.
قرّر مقدمًا المستندات التي يجب تخزينها (عروض الأسعار، العقود، لقطات الشاشة) ولمَدة كم.
استخدم مجموعة صغيرة وواضحة من الحالات حتى يفسر الجميع التقدّم بنفس الطريقة:
مسودة → مُرسَل → قيد المراجعة → مُوافق / مرفوض → مكتمل
تجنّب اختراع الكثير من الحالات المخصصة مبكرًا. حقل حالة متسق يجعل الفلترة، التذكيرات، والتقارير أسهل بكثير.
نجاح تطبيق الموافقات أو فشله يعتمد على سهولة الاستخدام. إذا كان الناس يترددون في تقديم طلب أو لا يعرفون ما الذي سيحدث بعد ذلك، سيعودون للبريد الإلكتروني.
تغطي معظم تدفقات الموافقة الداخلية مجموعة صغيرة من الصفحات:
اجعل التنقّل بسيطًا: "طلب جديد"، "طلباتي"، "يحتاج موافقتي"، و"الإعدادات" (للمسؤولين).
ابدأ بالحد الأدنى من الحقول المطلوبة، ثم استخدم الحقول الشرطية للحفاظ على قِصر النموذج. على سبيل المثال: اعرض "تفاصيل المورد" فقط إذا "نوع الشراء = مورد جديد"، أو اعرض "سبب الاستثناء" فقط إذا تم إلغاء خانة سياسة.
هنا تتألق أدوات الـno-code: يمكنك إظهار/إخفاء أقسام بناءً على قوائم منسدلة، مبالغ، أو القسم—دون بناء نماذج منفصلة.
على كل سجل طلب، اعرض:
مؤشر تقدم بسيط زائد سطر "بانتظار: <الاسم/الدور>" يُقلل معظم رسائل "أي تحديث؟".
ابدأ بواحد من سير العمل الذي يكون ذو ألم عالي، وتعقيد منخفض:
أمثلة: طلبات الشراء تحت حد محدد، طلبات الإجازة، أو تدفق طلب وصول أساسي. اثبت القيمة، ثم أعد استخدام نفس النموذج لعمليات موافقة أخرى.
اجمع الحد الأدنى من البيانات اللازمة للتحويل وللاتخاذ قرار. الحقول المطلوبة الشائعة:
إذا استمر المطلعون في طلب تفصيل معين (مثل اسم المورد أو عرض الأسعار)، اجعله حقلًا مطلوبًا في النسخة الأولى.
تحتاج معظم التطبيقات إلى عدد قليل من الشاشات الأساسية:
اجعل التنقّل بسيطاً حتى يتمكن المستخدمون من العثور بسهولة على "طلب جديد"، "طلباتي"، و"تحتاج موافقتي".
استخدم مجموعة حالات صغيرة وموحدة لتسهيل الفلاتر والتذكيرات والتقارير:
إن احتجت لتفصيل أكثر، اعرض الخطوة الحالية (مثلاً "مراجعة المدير") كحقل منفصل بدلاً من اختراع حالات عديدة.
اختر بناءً على ما إذا كانت الأسبقية مهمّة أم أن السرعة مطلوبة:
بالنسبة للمراجعات المتوازية، حدّد قاعدة الإكمال مبكراً: الجميع يجب أن يوافقوا، أي واحد يكفي، أو الأغلبية — تغيير هذا لاحقاً غالباً ما يسبب إعادة عمل.
قرّر ماذا يعني "مرفوض" في عمليتك:
حتى مع خيار التعديل/إعادة التقديم، احتفظ بسجل للتوثيق يوضح القرار الأصلي وسبب الرفض.
عرّف الأدوار والصلاحيات لكل مرحلة:
قاعدة عملية: بعد الإرسال، قفل الحقول الأساسية (المبلغ/المورد/التواريخ) والسماح بالتغييرات فقط عبر إجراء "إرسال مرة أخرى" أو "إعادة".
استخدم قواعد مبنية على المنظمة بدلاً من إدخال أسماء ثابتة:
بهذا تبقى قواعد التوجيه دقيقة عند تغيّر الأشخاص أو فرقهم.
أضف قواعد لمنع التعطّل منذ البداية:
اجعل سلوك التصعيد مرئيًا ومتسقًا حتى يشعر المستخدمون بأن النظام متوقع وليس اعتباطياً.
سجل تفاصيل كافية لتجيب على "من فعل ماذا ومتى ولماذا":
حدد توقعات الاحتفاظ مبكراً (مثلاً 12–24 شهرًا للطلبات التشغيلية، أطول للمالية/القانون) وطبّق مبدأ أدنى الامتيازات بحيث يرى المستخدمون فقط ما يحتاجون إليه.