كيف يتم العمل فعليا؟ ما لا تخبرك به الاجراءات الرسمية

في معظم الشركات تستطيع الادارة ان تشرح لك بسهولة كيف يفترض ان تسير عملية معينة. يدخل الطلب الى ERP، يمر بالموافقة، يتم تحديث المخزون، تصل الحركة الى Finance، ثم تظهر النتيجة في التقارير، وربما يوجد SOP يصف كل خطوة ومن المسؤول عنها.

لكن الجلوس مع الموظفين الذين ينفذون العملية يوميا قد يكشف لك شيئا مختلفا.

قد تجد موظفا يصدر قائمة الى Excel قبل ان يعتمد الطلب، ومديرا يحتفظ بملف مستقل للعملاء لان النظام لا يعرض له المعلومة بالشكل الذي يحتاجه، وموافقة تتم عبر Email او WhatsApp رغم انها غير موجودة في Workflow الرسمي، او محاسبا يعدل رقما في ملف جانبي قبل اجتماع الادارة لان التقرير الرسمي لا يعكس استثناء يعرفه اهل العمل جيدا.

هذه الخطوات قد لا تظهر في اي Process Map، لكنها في الواقع جزء من الطريقة التي ينجز بها العمل.

وهنا تظهر ما يعرف في ادارة العمليات باسم Shadow Processes، وسنسميها هنا بشكل ابسط: مسارات العمل غير الرسمية.

الفرق بين ما يفترض ان يحدث وما يحدث فعليا

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

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

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

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

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

ولهذا يمكن لشركة ان تمتلك اجراءات واضحة وانظمة جيدة، ومع ذلك لا تكون قد فهمت تماما كيف يتم انجاز العمل فعليا.

لماذا تظهر هذه المسارات من الاساس؟

اسهل تفسير هو القول ان المستخدمين لا يريدون الالتزام بالنظام.

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

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

الموظف عادة لا ينشئ Workaround بلا سبب، بل لانه يحاول حل مشكلة لم يجد لها اجابة مناسبة داخل المسار الرسمي.

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

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

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

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

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

لا تزل المسار قبل ان تعرف لماذا ظهر

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

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

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

لهذا نرى احيانا بعد Go-Live ان المستخدمين يعيدون بناء نفس الملفات والطرق القديمة، ربما باسم مختلف وفي مكان مختلف، ثم يتم تفسير ذلك على انه فشل في Adoption.

لكن ما حدث فعليا قد يكون ابسط: المشروع نجح في ازالة الـ Workaround، لكنه لم يفهم لماذا كان موجودا من الاساس.

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

القيمة ليست في المسار نفسه، بل في المعلومة التي يحملها عن العمل.

مقاومة التغيير ليست دائما مقاومة للتغيير

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

تخيل Sales Manager يستمر في استخدام ملفه الخاص رغم وجود Dashboard جديدة. من السهل القول انه لم يتبن الحل الجديد، لكن قبل الوصول الى هذه النتيجة يجب ان نسأل سؤالا ابسط: ما الذي يفعله بهذا الملف ولا يستطيع فعله بالـ Dashboard؟

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

لكن هذه حالات مختلفة تماما ولا يمكن التعامل معها بسياسة واحدة.

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

وهذه النقطة تصبح اكثر حساسية عندما نصل الى BI.

هنا تصبح المسألة مهمة جدا في مشاريع BI

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

لنفرض ان الشركة تريد Dashboard للربحية. يقوم فريق BI بالربط مع ERP، يبني Data Model، يعتمد الحقول المحاسبية، يحسب Margin، ثم ينشر Dashboard مرتبة وواضحة، وبعد ذلك يأتي المدير التجاري ويقول ان الربحية التي يراها ليست هي الربحية التي يعتمدها في عمله.

يراجع الفريق البيانات ويجد ان الحسابات مطابقة تماما لما هو موجود في النظام.

في هذه الحالة قد يكون الطرفان على حق.

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

اذا بدأ مشروع BI من سؤال واحد فقط وهو "اين توجد البيانات؟" فقد لا يصل الى هذه المعرفة ابدا.

السؤال الذي يجب ان يرافقه هو: "كيف تصل الشركة اليوم الى الرقم الذي تثق به؟"

المقصود ليس نقل كل معادلة موجودة في Excel الى Data Warehouse، بل فهم لماذا وجدت، وهل تعبر عن Business Rule حقيقية يجب توحيدها واعتمادها، ام عن ممارسة قديمة يجب التخلص منها.

وهنا يظهر الرابط العميق بين مسارات العمل غير الرسمية وBI، لان هذه المسارات لا تنتج فقط اعمالا غير موثقة، بل يمكن ان تنتج ايضا بيانات وتعريفات غير رسمية.

عندما تصبح للشركة اكثر من حقيقة

قد يحتفظ Sales بتصنيف خاص للعملاء، بينما يستخدم Finance تصنيفا مختلفا، وقد يحسب قسم Revenue بطريقة ويحسبه قسم اخر بطريقة مختلفة، ثم تبدأ الفرق في بناء تقارير او Power BI Workspaces خاصة بها لان البيئة المركزية لا تجيب عن سؤال معين.

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

عندها يبدأ النقاش في الاجتماعات بالتحول من "ماذا تخبرنا الارقام؟" الى "اي رقم هو الصحيح؟"

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

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

قد تكون الـ Dashboard صحيحة لكنها لا تزال ناقصة

من المواقف التي تستحق التوقف عندها ان تبني الشركة Dashboard صحيحة بالكامل من الناحية التقنية، ومع ذلك يستمر احد المديرين في فتح Excel اثناء الاجتماع ليشرح "ما يحدث فعليا".

رد الفعل السهل هو اعتبار ذلك عادة سيئة يجب ايقافها، لكن الرد الاكثر فائدة هو مقارنة النظرتين.

ما الذي يعرفه ذلك الملف ولا تعرفه الـ Dashboard؟

قد نكتشف ممارسة خاطئة يجب الغاؤها، وقد نجد Business Rule صحيحة لم تدخل في Analytical Model، او Context تشغيليا لم يكن النظام الاصلي مصمما لتخزينه من الاساس.

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

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

ومع AI يصبح تجاهلها اكثر خطورة

ما يمكن ان يسبب مشكلة في BI يمكن ان يصبح اخطر عندما تدخل الشركة الى AI.

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

اذا كانت السياسة الرسمية تقول شيئا بينما يتعامل الموظفون ذوو الخبرة مع بعض الحالات بطريقة اخرى، فلن يعرف AI هذه الخبرة لمجرد انها موجودة في رؤوس الناس.

واذا كانت هناك ثلاثة تعريفات مختلفة لنفس KPI، فان اضافة Model ذكي فوقها لن تحل الخلاف تلقائيا.

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

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

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

لا تطارد المسارات غير الرسمية، افهم ما تقوله لك

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

الافضل ان نتعامل معه كاشارة.

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

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

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

وجود ملف Excel بجانب Dashboard لا يعني تلقائيا ان مشروع BI فشل.

لكن تجاهل السؤال عن سبب بقاء ذلك الملف قد يكون بداية الفشل.

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

لان اي خطوة تؤثر في الرقم، او القرار، او الطريقة التي تفهم بها الادارة الاداء، هي جزء من العمل فعليا حتى لو لم تظهر في الاجراء الرسمي.