نرم افزار کاهش توقفات تولید یک ابزار صرفا گزارش‌گیری نیست؛ هدف آن این است که زمان‌های از دست‌رفته در کارخانه را از لحظه وقوع شناسایی، دسته‌بندی، اندازه‌گیری و به اقدام اصلاحی متصل کند.
نمودار سلسله مراتبی عوامل توقف خط تولید:
نمای کلی از منوهای اصلی نرم افزار:
در بسیاری از کارخانه‌ها مدیر تولید در پایان شیفت می‌داند که یک خط چند ساعت متوقف بوده است، اما پاسخ دقیقی برای این چهار سوال ندارند:
- توقف دقیقا چه زمانی رخ داده؟
- علت واقعی چه بوده؟
- چه مقدار تولید از دست رفته؟
- و برای جلوگیری از تکرار آن چه اقدامی انجام شده است؟
این فاصله میان «داده» و «تصمیم» یکی از دلایل اصلی استمرار توقفات است. ثبت دستی توقف توسط اپراتور، علاوه بر خطای انسانی، معمولا جزئیاتی مانند اختلاف سرعت، توقف‌های کوتاه، توقف مکانیکی، توقف برقی یا زمان تعویض قالب را با دقت کافی ثبت نمی‌کند.
در یک معماری داده‌محور، اطلاعات مستقیما از تجهیزات و لایه کنترل دریافت میشود و در کنار اطلاعات ثبت‌شده توسط پرسنل قرار می‌گیرد. در سامانه مورد بررسی، اتصال به PLC و دریافت داده از پروتکل‌هایی مانند Modbus برای حذف وابستگی کامل به گزارش‌های دستی پیش‌بینی شده است.
بنابراین کاهش توقف خط تولید به معنی وجود یک داشبورد نیست؛ این مرحله با ایجاد یک منبع داده قابل اعتماد شروع میشود.
نرم‌افزار باید بتواند مشخص کند چه مقدار از زمان خط، صرف تولید، عدم تولید، توقف فنی، تغییر قالب یا سایر وضعیت‌ها شده است. این تفکیک، مبنای تحلیل ریشه‌ای و تصمیم‌گیری برای نگهداری و تعمیرات، برنامه‌ریزی تولید و مدیریت عملکرد خواهد بود.
نرم افزار مدیریت تولید
نرم افزار چگونه به کاهش توقف خط تولید کمک می‌کند؟
موثرترین رویکرد، تبدیل توقف از یک «رویداد ثبت‌شده» به یک رویداد قابل‌اندازه‌گیری و قابل‌اقدام است. برای این کار، نرم‌افزار باید حداقل چهار لایه را پوشش دهد: دریافت داده، تشخیص وضعیت خط، تحلیل علت توقف و پیگیری اقدام اصلاحی.
در لایه اول، اطلاعات عملکرد تجهیزات به‌صورت لحظه‌ای دریافت میشود. سپس وضعیت هر خط در داشبورد مانیتورینگ نمایش داده میشود(گاهی توسط کاربر ثبت میشود) تا مشخص باشد کدام خط در حال تولید، متوقف یا در وضعیت دیگری است.
چنین معماری این امکان را می‌دهد مدیریت به جای انتظار برای گزارش پایان شیفت، وضعیت واقعی کف کارخانه را در همان لحظه مشاهده کند.
مرحله بعد، تفکیک توقف‌هاست. برای مثال، توقف مکانیکی و توقف برقی نباید در یک دسته قرار گیرند؛ زیرا راهکار اصلاحی آن‌ها متفاوت است. همچنین توقف ناشی از تعویض قالب با خرابی تجهیز یکسان نیست و ترکیب این موارد می‌تواند تصویر اشتباهی از عملکرد خط ایجاد کند. سامانه موردنظر امکان مشاهده توقفات از گزارش دستی پرسنل و تشخیص خودکار دستگاه‌ها را فراهم می‌کند.
نکته مهم بعدی، اندازه‌گیری توقف‌های کوتاه و پنهان است. در یک خط تولید، ممکن است چند توقف چند دقیقه‌ای در طول شیفت به چشم نیاید، اما مجموع آن‌ها در پایان ماه به ساعت‌ها ظرفیت ازدست‌رفته تبدیل شود. به همین دلیل، سیستم باید به جای تمرکز بر توقفات بزرگ، تمام زمان‌های عدم تولید را ثبت و تجمیع کند.
از طرف دیگر، صرفا دانستن اینکه «خط متوقف شده» برای تصمیم مدیریتی کافی نیست. بهتر است مدت توقف به وزن یا تعداد محصول از دست‌رفته تبدیل شود. در معماری مورد بررسی نیز تبدیل هر دقیقه توقف فنی به وزن تولید ازدست رفته به‌عنوان یکی از شاخص‌های مدیریتی مطرح شده است. این تبدیل، زبان فنی تعمیرات را به زبان مالی و تولیدی مدیریت نزدیک می‌کند.
ارتباط کاهش توقف تولید با OEE، نت و نگهداری پیشگیرانه
کاهش توقف تولید زمانی پایدار میشود که اطلاعات توقف به فرآیند نگهداری و تعمیرات متصل باشد. اگر نرم‌افزار فقط توقف را نشان دهد اما پس از آن هیچ درخواست کار، مسئول، زمان انجام و نتیجه‌ای ثبت نشود، سازمان صرفا صاحب یک گزارش دقیق‌تر شده است؛ نه یک سیستم بهتر.
ارتباط میان مانیتورینگ تولید و نگهداری و تعمیرات (نت) در این نقطه اهمیت پیدا می‌کند. برای هر خرابی می‌توان درخواست انجام کار ایجاد کرد، مسئول مشخص کرد، زمان شروع و پایان تعمیر را ثبت نمود و قطعات مصرفی و توضیحات عملیات را نگهداری کرد. در سیستم مرجع، ماژول درخواست انجام کار، گزارش انجام کار، کالاهای مصرفی و گزارش نت در کنار یکدیگر قرار گرفته‌اند.
این داده‌ها امکان تحلیل شاخص‌هایی مانند MTBF و MTTR را نیز فراهم می‌کنند. MTBF به فاصله زمانی میان خرابی‌ها و MTTR به مدت زمان موردنیاز برای تعمیر اشاره دارد.
اگر یک تجهیز مرتبا خراب شود، صرفا کاهش زمان تعمیر کافی نیست؛ باید علت تکرار خرابی نیز بررسی شود. از سوی دیگر، اگر تعداد خرابی‌ها پایین باشد اما هر خرابی ساعت‌ها توقف ایجاد کند، کاهش MTTR می‌تواند اثر مستقیم بر ظرفیت واقعی تولید داشته باشد.
ارتباط با OEE نیز از همین مسیر شکل می‌گیرد. OEE فقط یک عدد نیست؛ ترکیبی از مولفه‌هایی است که عملکرد واقعی تجهیز را در برابر شرایط ایده‌آل نشان می‌دهد. بنابراین داده‌های توقف، سرعت واقعی و مقدار تولید باید با دقت کافی جمع‌آوری شوند. در سیستم مرجع، محاسبه OEE بر مبنای سرعت استاندارد تولید مطرح شده و هدف آن اندازه‌گیری بازده واقعی خطوط است.
برای مثال، فرض کنید یک خط در ظاهر ۹۰ درصد زمان شیفت فعال بوده است، اما در همین زمان با سرعتی پایین‌تر از سرعت استاندارد کار کرده است. اگر تنها زمان توقف اندازه‌گیری شود، بخش مهمی از ظرفیت ازدست‌رفته دیده نمی‌شود. نرم افزار کاهش توقفات تولید باید بتواند هم توقف و هم افت سرعت را در تحلیل لحاظ کند.
در نتیجه، مسیر بهبود را می‌توان چنین ترسیم کرد:
داده لحظه‌ای ← تشخیص توقف ← طبقه‌بندی علت ← درخواست تعمیر ← ثبت اقدام ← تحلیل MTBF/MTTR ← اصلاح فرآیند ← بهبود OEE.
چند نمونه عملی اثر داده‌محوری بر توقفات کارخانه
نمونه اول؛ کارخانه تولیدی فولادی:
در نمونه عملیاتی درج‌شده در مستندات این راهکار، پس از استقرار سیستم در یک کارخانه تولیدی فولادی، افزایش ظرفیت واقعی تولید بیش از 20% در سال و افزایش بازدهی اعلام شده است؛ این افزایش بدون افزودن تجهیز جدید یا افزایش ساعت کاری گزارش شده است. همچنین کاهش چشمگیر هزینه‌های ناشی از توقفات و استقرار واحد نگهداری و تعمیرات پیش‌بینی‌شده از نتایجِ ذکرشده است.
اهمیت این مثال در این است که افزایش ظرفیت لزوما به معنای خرید ماشین‌آلات بیشتر نیست. اگر کارخانه بخشی از ظرفیت اسمی خود را به دلیل توقف، افت سرعت، تنظیمات یا ضعف در تعمیرات از دست بدهد، بازیابی ظرفیت موجود می‌تواند از نظر اقتصادی با توسعه فیزیکی کارخانه تفاوت زیادی داشته باشد. البته مقدار صرفه‌جویی یا بازگشت سرمایه هر پروژه به نوع صنعت، ارزش محصول، تعداد خطوط، الگوی خرابی و هزینه توقف وابسته است.
نمونه دوم؛ توقف فنی و نگهداری:
یک خط در طول یک ماه چندین بار به دلیل یک تجهیز مشخص متوقف میشد. در روش سنتی ممکن است هر بار تعمیر انجام شود و موضوع بسته شود. اما وقتی تاریخچه توقف، مدت تعمیر، قطعات مصرفی و دفعات خرابی در یک سیستم یکپارچه ثبت شود، الگوی تکرارشونده قابل مشاهده خواهد بود. در این حالت مدیر نت می‌تواند بررسی کند که آیا ادامه تعمیرات موردی منطقی است یا باید PM، اصلاح قطعه، تغییر روش نگهداری یا اقدام مهندسی دیگری انجام شود.
این همان جایی است که نرم افزار کاهش توقفات تولید از یک ابزار ثبت اطلاعات به ابزار تصمیم‌گیری تبدیل میشود. حتی اطلاعات تعویض قالب نیز می‌تواند جداگانه تحلیل شود؛ در مستندات سیستم، تولید و توقف ناشی از تعویض قالب در نمودارهای مجزا قابل مشاهده است.
از نظر اقتصادی نیز هزینه توقف فقط هزینه تعمیر نیست. هنگام توقف، علاوه بر هزینه نیروی انسانی و قطعات، ظرفیت تولید، برنامه تحویل، انرژی مصرف‌شده و گاهی مواد اولیه نیز تحت تأثیر قرار می‌گیرند. بنابراین برای اولویت‌بندی اقدامات اصلاحی بهتر است زمان توقف به اثر تولید و مالی آن مرتبط شود.
چگونه نرم افزار مناسب برای کاهش توقف خط تولید انتخاب کنیم؟
برای انتخاب نرم افزار کاهش توقفات تولید نباید فقط تعداد نمودارها یا ظاهر داشبورد را مقایسه کرد.
سوال اصلی این است که نرم‌افزار تا چه اندازه می‌تواند فاصله بین کف کارخانه و تصمیم مدیریتی را کم کند.
اولین معیار، اتصال به تجهیزات و PLC است. اگر داده تولید همچنان به‌صورت دستی وارد شود، بخشی از خطا و تأخیر سیستم سنتی باقی خواهد ماند.
بنابراین باید مشخص شود نرم‌افزار با PLCها و پروتکل‌های موجود کارخانه چگونه ارتباط برقرار می‌کند و در صورت قدیمی بودن تجهیزات، چه راهکاری برای تکمیل داده دارد. در مستندات این سامانه، سازگاری با پروتکل‌های استاندارد مانند Modbus و امکان استفاده از سنسورهای مستقل در صورت نیاز ذکر شده است.
دومین معیار، پایش لحظه‌ای و تاریخچه قابل تحلیل است. داشبورد تولید برای واکنش سریع ضروری است، اما برای کاهش پایدار توقف باید بتوان داده چند هفته یا چند ماه را نیز تحلیل کرد. امکان فیلتر بازه زمانی، مقایسه خطوط و بررسی تاریخچه توقف‌ها به مدیر اجازه می‌دهد روند خرابی و افت عملکرد را ببیند.
سوم، یکپارچگی با نت، برنامه‌ریزی تولید، انبار و OEE است. توقف تولید یک مسئله منفرد نیست؛ خرابی تجهیزات می‌تواند برنامه تولید را تغییر دهد، برنامه تولید با موجودی انبار ارتباط دارد و تعمیرات نیز به قطعات و نیروی انسانی وابسته است. معماری یکپارچه می‌تواند این اطلاعات را در یک جریان داده قرار دهد. در سیستم اصلی نیز ماژول‌های مانیتورینگ، انبار، برنامه‌ریزی تولید، نت، فروش و منابع انسانی در یک ساختار واحد معرفی میشوند.
چهارمین معیار، قابلیت اقدام پس از شناسایی مشکل است. نرم‌افزار باید بتواند پس از شناسایی توقف، آن را به درخواست کار، مسئول، زمان انجام و گزارش نتیجه متصل کند. در غیر این صورت، سازمان ممکن است هر ماه همان گزارش توقف را ببیند بدون اینکه چرخه اصلاح کامل شود.
نرم افزار کاهش ضایعات
در نهایت، معیار موفقیت، تعداد گزارش‌ها نیست؛ کاهش زمان از دست رفته و افزایش ظرفیت واقعی تولید است. یک سیستم مناسب باید بتواند به این سوال پاسخ دهد: «این توقف دقیقا چه اثری بر تولید داشته و چه اقدامی برای جلوگیری از تکرار آن انجام شده است؟»
به همین دلیل، نرم افزار کاهش توقفات تولید زمانی ارزش واقعی ایجاد می‌کند که داده ماشین، عملکرد خط، توقف، نگهداری و تعمیرات و شاخص‌های بهره‌وری را در یک زنجیره قابل‌پیگیری قرار دهد. هدف نهایی، صرفا مشاهده توقف نیست؛ هدف، تبدیل هر توقف به یک مسئله قابل‌اندازه‌گیری، قابل‌تحلیل و قابل‌اصلاح است.
کلمات کلیدی: نرم افزار کاهش توقفات تولید، کاهش توقف خط تولید، کاهش توقف تولید