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

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

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

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

كيفية تطبيق LEAN على تسليم المنصات

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

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

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

ماذا كانت مشكلة تطبيق المورد بالفعل

سوق Empower Global بُنيت لدعم 120 علامة تجارية مملوكة للسود تبيع عبر منصة واحدة. هذا يعني عملية تعيين موردين عملية مراجعة موردين عملية موافقة موردين وآلية لتحديد الباعة الذين سيضيعون وقت الفريق أو يضرون نزاهة المنصة.

قبل أن تؤتمتة TechSparq سير العمل في Salesforce Service Cloud كانت المراجعة يدوية وبطيئة. التطبيقات تأتي شخص يقرأها شخص يحكم هل يقابل المورد معايير السوق شخص يتابع أحياناً شخص يتتبع الحالة عبر جدول دائماً متأخر بقليل. الممثلون السيئون لا يُرصدون مبكراً. الموردون المؤهلون ينتظرون أسابيع للإجابات التي يجب أن يتلقوها في أيام. الفريق يقضي معظم الوقت على عمل كان يمكن لنظام مصمم جيداً أن يفعله تلقائياً.

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

كيف صممنا الأتمتة (والتصميم جاء قبل البناء)

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

معظم معايير عدم التأهيل كانت قواعس. تطبيقات غير مكتملة. توثيق ناقص. فئات منتجات خارج نطاق السوق. مواقع خارج الجغرافيا المدعومة. نقاط سعر غير متسقة مع موضع السوق. لا واحد من تلك متطلب مراجعة إنسانية. متطلبة قائمة اختيار يمكن لـ Salesforce Service Cloud تشغيلها تلقائياً بثوان عند الإرسال.

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

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

ماذا ينتج تصميم العملية LEAN فعلاً في بناء المنصة

عمل الأتمتة على Empower Global لم يكن ملفتاً لأن التكنولوجيا. Salesforce Service Cloud منصة نضجة مع أدوات سير عمل موثقة جيداً. أي فريق Salesforce مختص يمكنه بناء توجيه مؤتمت وتسجيل.

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

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

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

كيفية تطبيق هذا على مشروع منصتك التالي

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

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

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

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

الفرق ليست المنصة. إنها انضباط العملية التي سبقت البناء.