إفهم القواعد دي قبل ما تدخل الأتمتة في شغلك

في الفترة الأخيرة، كلمة Automation بقت موجودة في كل مكان.

أي شركة عندها شغل يدوي بتفكر في الأتمتة، وأي صاحب مشروع بيسمع عن الذكاء الاصطناعي بيبدأ يسأل:
هل ممكن الـ AI يعمل ده بدل الموظف؟
هل نستخدم Make؟
ولا Zapier؟
ولا نبني نظام خاص بينا؟

أنا شايف إن معظم الناس بتوصل للأسئلة دي بدري جدًا.

لأن قبل ما تختار أداة أو تفكر في AI، في سؤال أهم:

إحنا بنحاول نحل إيه بالضبط؟

وده فرق كبير.

المشكلة مش دايمًا في إن الشغل يدوي

خليني أوضح قصدي بمثال بسيط.

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

أول حاجة ممكن تيجي في بالك:

إحنا محتاجين نعمل Automation.

ممكن.

لكن قبل ما تعمل أي حاجة، لازم تسأل نفسك:

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

أحيانًا تكتشف إن المشكلة مش إن مفيش Automation.

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

وهنا لو بدأت تبني Automation، أنت ممكن تكون بتأتمت عملية غير منظمة أصلًا.

شفت ده أكتر من مرة

في شغل الأنظمة والتشغيل، ساعات المشكلة بتبان في الأول إنها مشكلة تقنية.

حد يقولك:

النظام محتاج يتربط بالنظام التاني.

أو:

محتاجين نعمل API.

أو:

خلينا نستخدم AI عشان نوفر وقت الفريق.

لكن لما تبدأ تفهم طريقة الشغل نفسها، تكتشف إن التقنية مش هي أصل المشكلة.

ممكن مثلًا يكون عندك 3 موظفين بيعملوا نفس المراجعة.

أو بيانات العميل موجودة في 4 أماكن مختلفة.

أو مفيش حد عارف مين المفروض يتصرف لما يحصل خطأ.

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

هل إحنا لسه محتاجين الخطوة دي؟

وده في رأيي أهم جزء قبل أي تطوير.

ارسم اللي بيحصل فعلًا، مش اللي المفروض يحصل

في شركات كثيرة، لما تسألهم:

الطلب بيمشي إزاي عندكم؟

كل شخص في الفريق ممكن يديك إجابة مختلفة.

وده معناه إن العملية نفسها مش واضحة.

أنا أفضل في البداية أرسم الموضوع بشكل بسيط جدًا.

مثلًا:

وصول الطلب
↓
استقبال البيانات
↓
مراجعة
↓
تنفيذ
↓
تحديث الحالة
↓
إشعار العميل

بعد كده تبدأ تدخل في التفاصيل.

مين بيعمل المراجعة؟

هل كل الطلبات بتتراجع؟

لو المراجعة فشلت، الطلب بيروح فين؟

هل التنفيذ بيتم تلقائيًا ولا يدويًا؟

هل العميل بياخد تحديث من النظام فعلًا ولا موظف بيبعتله رسالة؟

هنا تبدأ الصورة الحقيقية تظهر.

وغالبًا هتلاقي فرص الأتمتة بنفسك.

مش كل شيء محتاج يتأتمت

دي نقطة مهمة جدًا.

في ناس بتتعامل مع الأتمتة كأن الهدف النهائي هو إن ميبقاش في أي تدخل بشري.

وأنا مش متفق مع ده.

في عمليات الأفضل إن الإنسان يفضل جزء منها.

خصوصًا لو القرار معقد، أو تكلفة الخطأ عالية، أو في حاجة محتاجة فهم للسياق.

ممكن مثلًا تعمل Automation مسؤول عن:

استقبال البيانات.
التحقق من معلومات معينة.
تجهيز كل حاجة للموظف.
إرسال إشعار للفريق.
تسجيل العملية.

وبعدين الموظف ياخد القرار النهائي.

وده في حالات كثيرة أفضل بكتير من إنك تحاول تعمل نظام ذكي ومعقد عشان يأتمت 100% من العملية.

مش لازم الأتمتة تكون كاملة عشان تكون مفيدة.

لو قدرت توفر 30% أو 40% من وقت الفريق في عملية مهمة، دي نتيجة حقيقية.

طيب إيه اللي يستحق الأتمتة فعلًا؟

أنا عادة ببص على 3 حاجات.

أولًا: هل الحاجة دي بتتكرر كثير؟

لو موظف بيعمل نفس المهمة مرة واحدة في الشهر، ممكن متكونش أولوية.

لكن لو بيعملها عشرات أو مئات المرات يوميًا، هنا الوضع مختلف.

ثانيًا: هل الخطوات واضحة؟

الأتمتة بتحب القواعد الواضحة.

لما يحصل كذا، اعمل كذا.

لو البيانات ناقصة، حول العملية للمراجعة.

لو الدفع تم، نفذ الخطوة التالية.

كل ما كانت القواعد واضحة، كانت الأتمتة أسهل وأكثر استقرارًا.

ثالثًا: هل العمل اليدوي بيعمل مشاكل فعلًا؟

مش كل وقت الموظفين لازم توفره.

لكن لو العمل اليدوي بيسبب:

أخطاء.
تأخير.
فقدان بيانات.
نسيان خطوات.
مشاكل مع العملاء.

فهنا الأولوية أعلى.

ابدأ بأصغر مشكلة ممكنة

أكبر غلطة ممكن تحصل إنك تقرر تعمل مشروع ضخم من البداية.

"هنأتمت الشركة كلها."

الجملة دي شكلها جميل، لكن تنفيذها صعب جدًا.

لأنك هتدخل في عشرات العمليات، وعدة أنظمة، وأشخاص مختلفين، واستثناءات ملهاش نهاية.

الأفضل إنك تختار مشكلة واحدة.

مشكلة واضحة وموجودة فعلًا.

مثلًا:

فريق الدعم بيقضي وقت طويل في البحث عن بيانات العميل في أكثر من نظام.

تمام.

خلينا نحل المشكلة دي فقط.

نفهم البيانات جاية منين، ونشوف هل نقدر نجمعها في مكان واحد، أو نعمل عملية تلقائية تجيب المعلومات المطلوبة.

بعد ما تنجح، انتقل للحاجة اللي بعدها.

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

والـ AI مش لازم يدخل في كل حاجة

حاليًا أي مشروع فيه AI بيبقى شكله جذاب.

لكن بصراحة، في عمليات كثيرة لا تحتاج AI إطلاقًا.

لو عندك قاعدة واضحة:

لما الطلب يتغير إلى Paid، نفذ كذا.

أنت مش محتاج نموذج ذكاء اصطناعي.

محتاج Automation طبيعي ومنظم.

الـ AI بيكون مفيد أكثر لما تكون بتتعامل مع شيء محتاج فهم.

مثلًا:

قراءة رسائل العملاء وتصنيفها.
تلخيص معلومات.
استخراج بيانات من نصوص.
اقتراح ردود.
تحليل محتوى.
المساعدة في اتخاذ قرار بناءً على سياق معين.

لكن استخدام AI في مكان مش محتاجه ممكن يزود التكلفة والتعقيد بدون فائدة حقيقية.

التقنية مش هدف.

المفروض تكون وسيلة لحل مشكلة.

قبل ما تبدأ، اعمل التمرين ده

اختار عملية واحدة داخل مشروعك أو شركتك.

واكتبها من أول لحظة لحد ما تنتهي.

مش محتاج برنامج متخصص ولا مخطط معقد.

اكتب فقط:

إيه اللي بيبدأ العملية؟

وبعدها:

إيه اللي بيحصل؟

وبعدين:

مين بيتدخل؟

وفي النهاية:

إيه النتيجة المطلوبة؟

بعدها بص على كل خطوة واسأل:

هل الخطوة دي لازم إنسان يعملها؟

لو الإجابة لا، يبقى عندك فرصة جيدة للأتمتة.

ولو الإجابة نعم، اسأل سؤال تاني:

هل ممكن النظام يجهز للإنسان المعلومات اللي يحتاجها بدل ما يضيع وقت في جمعها؟

حتى هنا أنت حققت قيمة.

في النهاية

أنا مقتنع إن أفضل مشاريع الأتمتة مش هي اللي فيها أكبر عدد من الأدوات أو أكبر كمية AI.

أفضل مشروع هو اللي بعد ما يتنفذ تقدر تقول:

قبل كده كنا بنعمل ده في ساعتين، دلوقتي بياخد 10 دقائق.

أو:

قبل كده كان بيحصل الخطأ ده كل يوم، دلوقتي النظام بيمنعه.

أو حتى:

الفريق بقى مركز على شغل أهم بدل ما يكرر نفس الخطوات طول اليوم.

عشان كده، قبل ما تبدأ تفكر في Make أو Zapier أو AI Agents أو APIs، ارجع خطوة للخلف.

افهم الشغل الأول.

ارسم العملية كما هي فعلًا.

شوف فين الوقت بيضيع.

شوف فين الأخطاء بتحصل.

وبعدين اختار التقنية المناسبة.

لأن أتمتة عملية غير واضحة مش هتخليها أفضل.

في الغالب، هتخلي المشكلة تحصل بشكل أسرع فقط.

هل عندك عملية داخل مشروعك أو شركتك بتستهلك وقت الفريق بشكل متكرر؟

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

مش لازم تبدأ بحل ضخم. أحيانًا البداية الصح هي فهم المشكلة بشكل أفضل.