إنتروبيا الفواتير: لماذا تصادمات المراجعة تقتل العائد

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

المشغلون لا يفشلون في التجميع؛ النظام هو الذي يفشل في التزامن.

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

عادةً ما يعمل الهندسة بشكل جيد. الاحتكاك يأتي من معاملة الهندسة كتدفق مستمر بينما يحدث التصنيع في لقطات منفصلة. عندما تعامل قائمة المواد (BOM) كمستودع برمجيات، فإنك تدعو إلى الفوضى. التراجع في git لا يكلف شيئًا. التراجع عن أداة قالب حقن البلاستيك أو إتلاف 5000 لوحة دوائر مطبوعة لأن حرف المراجعة لم يتطابق مع القالب هو خطأ بتكلفة ستة أرقام. تصادم عدة أوامر تغيير هندسي أثناء بناء مجدول هو السبب الأكثر شيوعًا لفقدان العائد "الناعم". أنت لم تبنِ الوحدة بشكل خاطئ؛ لقد بنيت الوحدة الخاطئة لأن الجداول الزمنية تصادمت.

فخ "أحدث مراجعة"

هناك افتراض خطير في تطوير الأجهزة الحديثة بأن النسخة "الأحدث" من ملف هي التي يجب بناؤها. في نظام إدارة دورة حياة المنتج (PLM)، يمكن أن يكون الملف "معتمدًا" قبل أن يتم "تنفيذه" بفترة طويلة. تلك الفجوة هي المكان الذي يختفي فيه المال.

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

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

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

البرمجيات الثابتة هي مكون، وليست مجرد شعور

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

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

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

مصفوفة التوزيع

الحقل الأكثر أهمية في أي ECO ليس وصف التغيير، بل "التصرف" في المواد القديمة. هنا يتم حساب الواقع المالي للتغيير. عند تقديم مراجعة جديدة، يجب أن تأخذ في الاعتبار المواد في أربع حالات: في المخزون (في المستودع)، في الطلب (واردة من الموردين)، العمل الجاري (في العملية على الخط)، والسلع النهائية (موجودة على الرصيف).

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

يجب عليك إجراء الحسابات. غالبًا ما يكون من الأرخص التخلص من $5,000 من لوحات الدوائر المطبوعة الخام بدلاً من دفع ثمن ثلاثة أيام من توقف الخط بينما يحاول المشغلون إعادة العمل الدقيقة. إعادة العمل هي في الغالب خيال؛ التخلص هو ثمن الوضوح.

بروتوكول الانفصال النظيف

لوقف النزيف، يجب عليك فرض "الانفصال النظيف". التغيير التدريجي — حيث يتم خلط المراجعات الجديدة مع المراجعات القديمة في الحاوية — مقبول فقط للأجزاء التي هي 100% قابلة للتبادل من حيث الشكل والحجم والوظيفة، مثل برغي من مورد مختلف. لكل شيء آخر، تحتاج إلى قطع حاد.

هذا يعني تحديد نقطة القطع ليس بتاريخ تقويمي، لأنه متغير، بل برمز دفعة محدد أو رقم تسلسلي. "تبدأ المراجعة B عند الرقم التسلسلي: 100500." تسمح هذه التعليمات للمصنع بفصل الخط. يمكنهم إنهاء تشغيل المراجعة A، تنظيف الخط، تطهير المخزون القديم، وبدء المراجعة B بإعداد جديد.

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