داشبورد تولید و توقفات خط - وقتی مخرج کسر را کسی ثبت نکرده
ساختن داشبورد تولید معمولاً از سؤال «چه شاخصهایی میخواهید؟» شروع میشود. سؤال بهتر این است: مخرج کسر را دارید؟ چون بیشتر شاخصهای استاندارد تولید نسبتاند، و در بیشتر کارخانهها همان مخرج - زمان تولید برنامهریزیشده - جایی ثبت نشده.
در این صفحه
مسئله مخرج کسر
شاخصهای استاندارد تولید - در دسترس بودن، عملکرد، کیفیت و حاصلضربشان - همه نسبتاند. صورت کسر معمولاً موجود است: چند عدد تولید شد، چقدر ضایعات داشتیم، چقدر توقف داشتیم.
مخرج معمولاً نیست: زمان تولید برنامهریزیشده. یعنی خط قرار بود چند ساعت کار کند؟ بدون این عدد، هیچ نسبتی محاسبه نمیشود.
و مشکل ظریفتر: در بسیاری از کارخانهها این عدد وجود دارد ولی تعریفش ثابت نیست. آیا زمان تعویض قالب جزو زمان برنامهریزیشده است؟ نظافت پایان شیفت چطور؟ توقف برنامهریزیشده نگهداری؟
طبقهبندی علت توقف
داده توقف بدون علت، تقریباً بیفایده است. دانستن اینکه خط هفته گذشته ۱۴ ساعت متوقف بوده هیچ اقدامی پیشنهاد نمیکند؛ دانستن اینکه ۹ ساعتش تعویض قالب و ۳ ساعتش نبود مواد بوده، دو اقدام متفاوت میسازد.
اما طبقهبندی علت را ماشین نمیتواند انجام دهد - این تشخیص انسانی است. کاری که میشود کرد، آسان کردنش است:
- فهرست کوتاه علتهای از پیش تعریفشده، نه فیلد متن آزاد
- حداکثر ده تا پانزده گزینه در سطح اول - فهرست بلند پر نمیشود
- امکان افزودن توضیح، ولی اختیاری
- ثبت در همان لحظه توقف، روی تبلت شیفت
و یک قاعده تجربی: اگر ثبت علت بیش از چند ثانیه طول بکشد، در شیفت شلوغ انجام نمیشود - و دقیقاً همان شیفت شلوغ است که دادهاش بیشترین ارزش را دارد.
توقف کوتاه، مشکل پنهان
توقفهای بلند همیشه ثبت میشوند چون کسی باید تعمیر کند. توقفهای کوتاه - چند دقیقه، چند بار در شیفت - معمولاً ثبت نمیشوند چون اپراتور خودش رفعشان میکند.
ولی جمعشان میتواند از توقفهای بلند بیشتر باشد، و چون ثبت نمیشوند، در هیچ گزارشی دیده نمیشوند. نتیجه: تیم روی خرابیهای بزرگ تمرکز میکند و مشکل اصلی جای دیگری است.
اگر داده سنسوری در دسترس باشد، این توقفها خودکار تشخیص داده میشوند. اگر نه، ثبتشان باید آنقدر آسان باشد که در شیفت شلوغ هم انجام شود.
زمان تولید برنامهریزیشده را ثبت میکنید؟
در جلسه ارزیابی، دادههای موجود کف کارخانه بررسی میشود و میگوییم کدام شاخص امروز قابل محاسبه است و کدام نه.
اتصال چهار داده که امروز جدا هستند
ارزش واقعی داشبورد تولید وقتی ظاهر میشود که چهار چیز به هم وصل شوند:
- تولید - چه چیزی و چقدر، در چه شیفتی
- توقف - چه زمانی، چقدر، به چه علت
- کیفیت - ضایعات و دوبارهکاری، به تفکیک محصول و شیفت
- مواد - موجودی و مصرف
امروز این چهار معمولاً در چهار جای متفاوتاند - و همین باعث میشود پرسشهای ساده بیپاسخ بمانند: آیا افزایش ضایعات هفته گذشته با تعویض تأمینکننده مواد ارتباط داشت؟
بخش زیادی از این داده از برگههای کاغذی میآید - که موضوع راهنمای کارت تولید و برگه کنترل کیفیت است.
گردشکار
۱. توافق روی تعاریف
زمان برنامهریزیشده، دستهبندی علت توقف و تعریف ضایعات - مکتوب و تأییدشده پیش از هر کد.
۲. جمعآوری داده
از Historian اگر هست، از برگهها اگر نیست، و از ERP برای سفارش و مواد.
۳. انبار داده با تقویم شمسی و ساختار شیفت
شیفتها واحد تحلیلاند، نه روز تقویمی - و شیفت شب معمولاً روی دو روز تقویمی میافتد.
۴. داشبورد در دو سطح
سطح خط برای سرپرست شیفت با بهروزرسانی مکرر، و سطح کارخانه برای مدیریت با نمای دورهای.
۵. هشدار انحراف
نه گزارش، بلکه اعلان وقتی شاخصی از محدوده معمول خارج شد.
سنجش و نقطه شروع
معیار اول: سهم زمان توقفی که علتش ثبت شده. اگر این عدد پایین باشد، هیچ تحلیلی معتبر نیست و اولین کار بالا بردن همین است.
معیار دوم، عملیاتی: تعداد اقدام اصلاحی که از روی داده داشبورد انجام شد. داشبوردی که کسی بر اساسش کاری نکند، گزارش است نه ابزار.
پیشنهاد ما شروع با یک خط تولید است - همانی که بیشترین توقف را دارد. و پیش از شروع، همان دو عدد را بدانید: سهم توقف ثبتشده، و آیا تعریف زمان برنامهریزیشده مکتوب است یا نه.
جزئیات پلتفرم در صفحه هوش تجاری سازمانی است.
بقیه کاربردها در صفحه راهکارهای تولید و کارخانجات است.
پرسشهای متداول
چون شاخصهای استاندارد تولید نسبتاند و مخرجشان زمان تولید برنامهریزیشده است - عددی که در بیشتر کارخانهها ثبت نمیشود یا تعریف ثابتی ندارد. اگر دو نفر دو تعریف داشته باشند، شاخص دو عدد میدهد و هر دو قابل دفاعاند.
خیر، این تشخیص انسانی است. آنچه میشود کرد آسان کردنش است: فهرست کوتاه علتهای از پیش تعریفشده بهجای متن آزاد، حداکثر ده تا پانزده گزینه، و ثبت در همان لحظه روی تبلت شیفت. اگر بیش از چند ثانیه طول بکشد، در شیفت شلوغ انجام نمیشود.
جمعشان میتواند از توقفهای بلند بیشتر باشد، و چون اپراتور خودش رفعشان میکند معمولاً ثبت نمیشوند و در هیچ گزارشی دیده نمیشوند. نتیجه اینکه تیم روی خرابیهای بزرگ تمرکز میکند در حالی که مشکل اصلی جای دیگری است.
داده از برگههای کف کارخانه میآید. کندتر و پرخطاتر است ولی شدنی، و بخش زیادی از پروژههای واقعی همینطور شروع میشوند. خواندن آن برگهها موضوع جداگانهای است که راهنمای خودش را دارد.
شیفت. تحلیل بر پایه روز تقویمی در تولید گمراهکننده است، چون شیفت شب معمولاً روی دو روز میافتد و مقایسه شیفتها با هم اطلاعات بیشتری میدهد تا مقایسه روزها.
دو سطح لازم است: سطح خط برای سرپرست شیفت با بهروزرسانی مکرر، و سطح کارخانه برای مدیریت با نمای دورهای. یک داشبورد واحد برای هر دو، معمولاً برای هیچکدام مناسب نیست.
اول سهم زمان توقفی که علتش ثبت شده - اگر پایین باشد هیچ تحلیلی معتبر نیست. بعد معیار عملیاتی: تعداد اقدام اصلاحی که از روی داده داشبورد انجام شد. داشبوردی که کسی بر اساسش کاری نکند، گزارش است نه ابزار.
