من الواتساب والإكسل إلى نظام واحد

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

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

يوم معتاد في شركة تعمل من المجموعات والجداول

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

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

هذا وصف لموقف معتاد، وليس لشركة بعينها. ومن عاش يوما مثله يعرف المشكلات:

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

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

ما الذي ينتقل إلى النظام أولا

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

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

بهذه المكونات الأربعة يتغير سؤال «أين وصل الطلب؟». بدلا من أن يطرح في المجموعة، يفتح المدير شاشة ويرى الجواب. والطلبات المتأخرة تظهر وحدها في Dashboard، بدون أن يبحث عنها أحد.

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

ما الذي يبقى كما هو

النظام الجديد لا يعني أن يتخلى الفريق عن أدواته المألوفة. بعضها يبقى، لكن بدور أوضح:

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

القاعدة التي أقترحها بسيطة:

النقاش يبقى في المحادثة، والقرار يسجل في النظام.

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

نقل البيانات الحالية

البيانات الموجودة في ملفات Excel ثروة، حتى لو كانت غير مرتبة. والسؤال العملي هو ما الذي ينقل، وما الذي يبقى أرشيفا.

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

ابدأوا بقسم واحد

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

لهذا الأسلوب فوائد واضحة:

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

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

ما الذي تقيسونه بعد الإطلاق

حتى تعرفوا هل حقق النظام ما تريدونه، اختاروا مقاييس بسيطة من الآن:

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

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

قائمة مراجعة

أجيبوا بنعم أو لا:

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

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

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

مرتبط بهذا المقالأنظمة داخلية لإدارة العمليات