یک ماه دادهٔ توقف را در ChatGPT کپی کنید و بپرسید «علت اصلی توقف‌های ما چیست؟». در چند ثانیه جوابی مطمئن می‌گیرید. در بیشتر کارخانه‌ها همین جواب اول به مشکل اشتباه اشاره می‌کند؛ نه چون ابزار بد است، بلکه چون سؤال و داده ایراد دارند.
در ۲۴ سال کار در تولید دیده‌ام که یک گزارش توقف، بسته به این‌که چطور بشماریم، سه داستان متفاوت تعریف می‌کند. اگر تعداد توقف‌ها را بشمارید، گیرهای کوچک برنده‌اند. اگر دقیقه‌ها را بشمارید، انتظار مواد. و اگر فقط دقیقه‌هایی را بشمارید که از خروجی کل خط کم کرده‌اند، چیز دیگری به صدر می‌آید. ChatGPT راه سریعی برای گذشتن از این گزارش است، به شرطی که سؤال‌ها را به ترتیب درست بپرسید.
در ادامه همان ترتیب را آورده‌ام: پنج سؤال که از گزارش خام توقف به همان اتلافی می‌رسند که باید اول سراغش رفت. خط، گزارش و همهٔ عددهای این مقاله فرضی‌اند، نه دادهٔ یک کارخانهٔ واقعی.
گزارش نمونهٔ فرضی
یک خط ماشین‌کاری پنج ایستگاه دارد. ایستگاه CNC 3 گلوگاه است و زمان سیکلش ۹۰ ثانیه است. در یک ماه، اپراتورها ۲۴۷ توقف با مجموع ۲٬۸۹۰ دقیقه ثبت کرده‌اند. علت‌ها دستی تایپ شده‌اند، پس یک علت با چند اسم آمده است: «مواد نیست»، «منتظر قطعه»، «مواد دیر رسید». و جلوی ۵۸ توقف فقط نوشته شده «سایر».
سؤال ۱: همان سؤالی که همه اول می‌پرسند
جواب معمول: توقف‌های کوتاه (خطای سنسور و گیر کردن قطعه)، با ۹۶ مورد از ۲۴۷ توقف. درست است، اما کم‌فایده‌ترین جواب در کل گزارش است. وقتی چیز دیگری نخواهید، ابزار تعداد رویدادها را می‌شمارد، و پرتکرارترین توقف‌ها معمولاً کوتاه‌ترین‌ها هستند. این جواب را نگه دارید؛ دوباره سراغش می‌آییم.
سؤال ۲: قبل از هر شمارشی، علت‌ها را مرتب کنید
این همان مرحله‌ای است که بیشتر آدم‌ها از آن می‌گذرند، در حالی که همه‌چیز را عوض می‌کند. سه برچسب مواد یک کد می‌شوند. وقتی یادداشت‌ها خوانده می‌شوند، ۲۲ مورد از ۵۸ توقف «سایر» در واقع انتظار مواد بوده‌اند و ۱۲ مورد ستاپ‌هایی بوده‌اند که از زمان استاندارد طولانی‌تر شده‌اند. فقط ۲۴ مورد واقعاً نامشخص‌اند. ردیف‌های «نامطمئن» را سرپرست چک کند؛ ده دقیقه بازبینی انسانی در این مرحله از هر نموداری در مراحل بعد ارزشمندتر است.
| علت (بعد از مرتب‌سازی، فرضی) | تعداد توقف | دقیقه | دقیقه در CNC 3 (گلوگاه) |
|---|---|---|---|
| توقف کوتاه (سنسور، گیر کردن) | ۹۶ | ۴۱۰ | ۶۰ |
| انتظار مواد | ۶۳ | ۸۲۰ | ۲۶۰ |
| طولانی شدن ستاپ | ۳۰ | ۷۹۰ | ۶۴۰ |
| تعویض ابزار | ۳۰ | ۳۳۰ | ۱۲۰ |
| خرابی اسپیندل | ۴ | ۳۸۰ | ۳۸۰ |
| سایر (هنوز نامشخص) | ۲۴ | ۱۶۰ | ۴۰ |
| جمع | ۲۴۷ | ۲٬۸۹۰ | ۱٬۵۰۰ |
سؤال ۳: بر اساس دقیقه رتبه‌بندی کنید، نه تعداد
حالا انتظار مواد با ۸۲۰ دقیقه اول است و طولانی شدن ستاپ با ۷۹۰ دقیقه درست پشت سرش. توقف‌های کوتاه، «برندهٔ» سؤال ۱، به رتبهٔ سوم می‌افتند، فقط کمی جلوتر از خرابی اسپیندل. تصویر بهتر شده، اما هنوز آن تصویری نیست که برای خروجی خط اهمیت دارد.
سؤال ۴: فقط دقیقه‌های گلوگاه از کل خط کم می‌کنند
جواب واقعی اینجا پیدا می‌شود: طولانی شدن ستاپ، با ۶۴۰ دقیقه در گلوگاه. یعنی ۳۸٬۴۰۰ ثانیه، یا حدود ۴۲۷ قطعه‌ای که خط می‌توانست در این ماه بسازد (۳۸٬۴۰۰ ÷ ۹۰). خرابی اسپیندل با ۳۸۰ دقیقه دوم است. بیشتر انتظار مواد در ایستگاه‌های دیگر اتفاق افتاده، در حالی که بافر جلوی CNC 3 آن را در حال کار نگه داشته است؛ پس خیلی کمتر از آنچه جمع دقیقه‌هایش نشان می‌دهد از تولید کم کرده است. حساب را همیشه خودتان چک کنید و هر بار محاسبه را بخواهید. این همان منطقی است که در پیدا کردن و باز کردن گلوگاه تولید با داده توضیح داده‌ام.
سؤال ۵: الگو را پیدا کنید و آن را به یک آزمایش تبدیل کنید
در گزارش فرضی، حدود دو سوم دقیقه‌های اضافه در شیفت شب و در ستاپ‌های مربوط به یک خانوادهٔ محصول خاص رخ داده است. این نتیجه‌گیری نیست؛ جایی است که باید رفت و دید. شاید فیکسچر آن خانواده از قبل آماده نمی‌شود، شاید شیفت شب متخصص راه‌اندازی ندارد. یک آزمایش با یک مسئول برای دو هفته، مثلاً آماده کردن فیکسچر و ابزار قبل از شروع ستاپ، بیشتر از یک ماه نمودار دیگر به شما می‌گوید.
چرا جواب اول غلط بود؟
ChatGPT دقیقاً همان کاری را کرد که از آن خواسته شد. «علت اصلی» بدون تعریف یعنی «پرتکرارترین»، و برچسب‌های نامرتب اندازهٔ واقعی هر علت را پنهان می‌کنند. راه‌حل، ابزار هوش مصنوعی بهتر نیست. یک فهرست کد کوتاه است، یک بازبینی انسانی روی ردیف‌های نامطمئن، و یک سؤال که هر دقیقهٔ ازدست‌رفته را به گلوگاه وصل کند.
اگر خرابی در صدر فهرست می‌آمد، قدم بعدی فرق می‌کرد؛ آن را در نگهداری پیش‌بینانه برای یک دستگاه حیاتی توضیح داده‌ام. و برای نسخهٔ روزانهٔ این سؤال‌ها، از گزارش شیفت تا جلسهٔ صبح، ۵ پرامپت ChatGPT برای مدیر تولید را بخوانید.
چک‌لیست قبل از اعتماد به تحلیل توقف
- اطلاعات محرمانه حذف شده و قوانین شرکت دربارهٔ ابزارهای هوش مصنوعی رعایت شده است.
- علت‌ها به یک فهرست کد کوتاه نسبت داده شده‌اند و متن اصلی کنارشان مانده است.
- ردیف‌های «سایر» خوانده و دوباره کدگذاری شده‌اند و ردیف‌های نامطمئن را سرپرست چک کرده است.
- علت‌ها بر اساس دقیقه رتبه‌بندی شده‌اند، نه فقط تعداد توقف.
- دقیقه‌های گلوگاه جدا شده و به قطعهٔ ازدست‌رفته تبدیل شده‌اند.
- هر محاسبه نشان داده شده و یک بار با گزارش خام چک شده است.
- یک فرضیه، یک آزمایش، یک مسئول و مهلت دوهفته‌ای.
می‌خواهید این را روی گزارش خودتان امتحان کنید؟
یک ماه دادهٔ توقف بی‌نام برایم بفرستید. می‌توانیم این پنج سؤال را با هم اجرا کنیم، ببینیم علتی که همه درباره‌اش حرف می‌زنند واقعاً همان است که از تولید کم می‌کند یا نه، و یک فهرست کد و چند پرامپت متناسب با خط شما برای تیمتان بگذاریم.
تماس با من بخوانید: پیدا کردن گلوگاه بخوانید: داشبورد زندهٔ عملیات
منابع
- منطق گلوگاه بر پایهٔ ایدهٔ تئوری محدودیت‌هاست که کندترین مرحله سرعت کل سیستم را تعیین می‌کند (الیاهو گلدرات، کتاب «هدف»، ۱۹۸۴). گزارش و همهٔ عددهای این مقاله فرضی‌اند.
- مطالعهٔ مرتبط در همین سایت: پیدا کردن گلوگاه تولید با داده، پرامپت‌های ChatGPT برای مدیر تولید، نگهداری پیش‌بینانه برای یک دستگاه حیاتی، و داشبورد زندهٔ عملیات.