لماذا نبدأ دائماً بتدقيق العمليات قبل كتابة أي كود

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

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

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

لهذا نبدأ دائماً بتدقيق العمليات.

ما هو تدقيق العمليات فعلاً

يوحي الاسم بمشاركة استشارية طويلة ومكلفة. ليس الأمر كذلك.

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

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

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

ما الذي نبحث عنه

لكل شركة نسختها الخاصة من المشاكل ذاتها. نبحث عن:

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

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

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

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

هذه ليست مشاكل غير عادية. تظهر في كل شركة تقريباً نعمل معها. السؤال ليس ما إذا كانت موجودة - بل أيها تكلّف أكثر وأيها يمكن للبرمجيات أن تحله فعلاً.

ما الذي يغيّره التدقيق

نادراً ما يؤكد ناتج تدقيق العمليات الجيد الخطة الأصلية. في الغالب يغير ثلاثة أشياء.

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

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

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

لماذا تتخطى معظم الشركات هذه الخطوة

الجواب بسيط: إنها تؤخر بدء العمل البرمجي القابل للفوترة.

شركة تكسب المال من البناء لديها حافز هيكلي للبدء في البناء في أسرع وقت ممكن. مرحلة الاستكشاف - فهم المشكلة قبل اقتراح الحل - مركز تكلفة يؤخر الإيرادات.

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

ما الذي تخسره إذا تخطيت هذه الخطوة

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

ثم تأتي محادثة إعادة البناء. مزيد من المال، مزيد من الوقت، وفريق متشكك لأنه مرّ بهذا من قبل.

لقد ورثنا ما يكفي من هذه الحالات لنعرف كيف تحدث. كان يمكن تجنب كل منها تقريباً بتدقيق جاد للعمليات في البداية. ليس تمريناً شكلياً - بل نظرة حقيقية وصادقة في كيفية عمل الشركة قبل تحديد ما يجب بناؤه.

كيف نعمل

كل مشروع نتولاه يبدأ بتدقيق للعمليات. ليس اختيارياً وليس زخرفياً. إنه الأساس الذي يُبنى عليه كل شيء آخر.

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

الناتج هو ملخص واضح: ما هي المشكلة الحقيقية، ما نوصي ببنائه، وبأي ترتيب، ولماذا. يقود هذا الملخص بعد ذلك كل شيء - النطاق، الجدول الزمني، الهيكل التقني.

إنها ليست المرحلة الأكثر إثارة في المشروع. لكنها المرحلة التي تحدد ما إذا كان المشروع سينجح.

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