كيف تختار أول عملية تستحق الأتمتة في مشروعك الصغير ؟

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

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

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

1. حدّد خطوة يمكن وصفها بدل طلب ( أتمتة المشروع )

عبارة ( أريد أتمتة خدمة العملاء ) واسعة ؛ فهي تشمل استقبال الطلبات وفهمها وتوزيعها والرد والتنفيذ والمتابعة . أما ( أريد نقل حقول نموذج طلب الزيارة إلى سجل داخلي للمراجعة ) فتحدد جزءًا تستطيع فهمه وتجربته .

اكتب وصف المهمة في جملة توضح :

• ما الحدث الذي يبدأها ؟ 
• من أين تأتي البيانات ؟
• ما الإجراء المتكرر ؟
• ما الناتج المطلوب، ومن يستخدمه ؟
• ما الحالات التي تتطلب تدخل شخص ؟

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

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

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

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

2. قِس عبء العمل الحالي دون تسميته وفرًا متوقعًا

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

لنفترض أن سجلات منشأتنا الافتراضية تعطي الأرقام التالية لشهر واحد :

• تسجيل طلبات الزيارة : 180 مرة ، بمتوسط أربع دقائق للمرة ؛ أي 720 دقيقة أو 12 ساعة .
• فرز رسائل العملاء : 120 مرة ، بمتوسط ثلاث دقائق ؛ أي 360 دقيقة أو ست ساعات .
• اعتماد طلبات التعويض : 30 مرة ، بمتوسط ثماني دقائق ؛ أي 240 دقيقة أو أربع ساعات .
• إعداد ملخص أسبوعي للطلبات : أربع مرات خلال الشهر ، بمتوسط 25 دقيقة ؛ أي 100 دقيقة ، أو ساعة و40 دقيقة .

المعادلة المستخدمة هي :

عبء العمل اليدوي خلال الفترة = عدد مرات تنفيذ المهمة × متوسط وقت العمل المباشر للمرة .

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

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

3. افحص الجاهزية قبل ترتيب أولوية الأتمتة

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

أ. هل القواعد والمدخلات واضحة ؟

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

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

ب. هل الاستثناءات قابلة للاكتشاف والإحالة ؟

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

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

ج. ما أثر الخطأ ، وهل يمكن تداركه ؟

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

وبناءً على افتراضات المثال ، تكون قراراتنا الأولية كما يلي :

نرشّح تسجيل طلبات الزيارة لتجربة محدودة لأن المدخلات موحدة والناتج مسودة داخلية بشرط التحقق من إمكانية الربط ومنع التكرار .

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

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

4. استخدم الذكاء الاصطناعي لتحدي اختيارك

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

أرسل وصفًا منزوع المعلومات الحساسة ، ثم استخدم أمرًا مثل :

لدي المهام المرفقة ، ولكل مهمة وصف للمدخلات والخطوات والتكرار والوقت والاستثناءات والناتج .

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

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

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

لا تفترض أن الذكاء الاصطناعي ضروري لتنفيذ المهمة، ولا تقترح شراء أداة قبل تحديد المتطلبات.

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

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

5. حوّل المرشح إلى تجربة ذات حدود واضحة

القرار الآن ليس ( سنؤتمت استقبال العملاء بالكامل ) ، بل ( سنختبر إنشاء مسودة سجل من نموذج طلب الزيارة ) . هذه الحدود تجعل النتيجة قابلة للمراجعة قبل توسيع الاستخدام .

اكتب بطاقة التجربة قبل التنفيذ :

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

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

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

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

وافحص إمكانية الرجوع إلى المسار اليدوي ، مع معرفة الطلبات التي عولجت بالفعل حتى لا تُسجل مرتين عند الاستئناف . كذلك ، تحقّق من جهد الإعداد والتكلفة المستمرة قبل تحويل التجربة إلى التزام دائم .

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

6. الخلاصة

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

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

ابدأ بخطوة محدودة يستطيع فريقك فهمها ومراجعتها وإيقافها . ثم اجعل نتيجة التجربة هي التي تحدد الاستمرار أو التعديل أو اختيار مهمة أخرى .