KPIهای تعمیرات؛ تعریف و پایش درست MTBF، MTTR و OEE در عمل

خیلی از تیم‌های نت و تعمیرات KPI دارند، اما KPI برایشان «عدد گزارش ماهانه» است نه «ابزار تصمیم». نتیجه هم قابل پیش‌بینی است: MTBF ظاهراً عالی می‌شود چون خرابی‌ها ثبت نشده‌اند، MTTR پایین می‌آید چون زمان انتظار قطعه را حذف کرده‌ایم، و OEE بالا می‌رود چون توقف‌ها را به دسته‌های دیگر منتقل کرده‌ایم. اینجا KPI به جای اینکه شفاف کند، پنهان می‌کند.

KPIهای تعمیرات وقتی ارزش دارند که سه چیز را هم‌زمان درست کنیم: ۱) تعریف عملی و یکسان در کل سازمان، ۲) مرزبندی دقیق زمان‌ها (چه چیزی «توقف» است و چه چیزی نیست)، ۳) سازوکار گزارش‌دهی که قابلیت پیگیری علت و اقدام اصلاحی داشته باشد. در این مقاله دقیقاً روی همین سه موضوع، با مثال‌های نزدیک به گزارش‌های واقعی تعمیرات، جلو می‌رویم تا MTBF، MTTR و OEE را طوری پایش کنید که در نهایت به کاهش توقف، افزایش عمر تجهیز و مدیریت هزینه برسد.

قبل از KPI: سه سوءبرداشت رایج که نت را گمراه می‌کند

قبل از اینکه سراغ فرمول‌ها برویم، باید چند سوءبرداشت رایج را خنثی کنیم. چون اگر این‌ها حل نشود، بهترین اکسل‌ها هم خروجی غلط می‌دهند.

• • سوءبرداشت ۱: «هرچه عدد بهتر، یعنی عملکرد بهتر»؛ نه همیشه. MTTR پایین می‌تواند یعنی تعمیر سطحی و برگشت خرابی در چند روز بعد. MTBF بالا می‌تواند یعنی ثبت نکردن توقف‌های کوتاه (Micro-stop).

  • سوءبرداشت ۲: «MTBF و MTTR فقط به تیم تعمیرات مربوط است»؛ در عمل، کیفیت اپراتوری، تامین قطعه، برنامه‌ریزی تولید و حتی کیفیت روانکاری روی این شاخص‌ها اثر مستقیم دارد.

  • سوءبرداشت ۳: «OEE عدد واحد بهره‌وری است»؛ OEE اگر به اجزایش شکسته نشود (Availability/Performance/Quality)، به‌جای راهنمایی، دعوا تولید می‌کند.

برای شروع، یک تصمیم ساده بگیرید: «KPI فقط وقتی پذیرفته است که بتوانیم با آن یک اقدام مشخص تعریف کنیم.» اگر KPI صرفاً برای ارائه به مدیریت است، احتمالاً در مسیر غلط هستید.

یک صفحه «تعاریف KPI» بسازید و همان را مبنای آموزش اپراتور، برنامه‌ریز و نت قرار دهید. هرجا تعریف مبهم است، همان‌جا منبع اختلاف آینده است.

MTBF در عمل: فاصله واقعی بین خرابی‌ها، نه فاصله بین «ثبت‌ها»

MTBF (Mean Time Between Failures) یعنی «میانگین زمان کارکرد بین دو خرابی» برای تجهیزات قابل تعمیر. نکته کلیدی این است که MTBF فقط وقتی معنا دارد که خرابی (Failure) را درست تعریف کرده باشید: خرابی یعنی تجهیز نتواند وظیفه‌اش را طبق استاندارد انجام دهد (ایمنی، کیفیت، ظرفیت یا پایداری).

فرمول ساده و قابل اجرا

در گزارش‌های عملی، دو مدل رایج دارید:

• • • MTBF مبتنی بر زمان کارکرد: MTBF = مجموع زمان کارکرد واقعی تجهیز / تعداد خرابی‌های ثبت‌شده

    • MTBF مبتنی بر تولید/کیلومتر: برای ناوگان یا خطوط خاص، به‌جای ساعت از کیلومتر یا تعداد سیکل استفاده می‌شود.

مثال نزدیک به گزارش تعمیرات

فرض کنید یک کمپرسور اسکرو در ماه ۶۰۰ ساعت در سرویس بوده. ۳ خرابی ثبت شده: (۱) تریپ دمای بالا، (۲) افت فشار خروجی، (۳) نشتی روغن و توقف اضطراری. MTBF ماهانه می‌شود ۶۰۰/۳ = ۲۰۰ ساعت.

اما اگر توقف‌های کوتاه ۵ دقیقه‌ای به‌عنوان «ایست لحظه‌ای» ثبت نشده باشند (مثلاً ۱۲ بار تریپ و ریست سریع)، MTBF شما به‌صورت مصنوعی بالا می‌رود و علت ریشه‌ای (مثلاً مشکل خنک‌کاری یا کیفیت روغن) دیر دیده می‌شود. اینجاست که اتصال نت به داده‌های فرآیندی و ثبت درست توقف‌ها اهمیت پیدا می‌کند؛ در تجهیزات دوار، پایش وضعیت و حتی نتایج روغن صنعتی مصرفی می‌تواند قرائن مهمی درباره اکسیداسیون، آلودگی و ریسک تریپ بدهد.

برای هر تجهیز «آستانه خرابی» تعریف کنید. مثلاً اگر افت فشار بیش از X بار یا افزایش دما بیش از Y درجه رخ داد و نیاز به مداخله نت داشت، همان را Failure حساب کنید؛ حتی اگر توقف کامل تولید رخ ندهد.

MTTR در عمل: زمان واقعی بازگشت به سرویس، با تفکیک اجزای زمان

MTTR (Mean Time To Repair) را معمولاً «میانگین زمان تعمیر» ترجمه می‌کنند، اما در اجرا دو برداشت متفاوت داریم: یکی فقط زمان کار آچار (Wrench time) و دیگری زمان بازگشت تجهیز به سرویس (Time to restore). اگر تعریف شما روشن نباشد، مقایسه واحدها و ماه‌ها بی‌معنا می‌شود.

دو تعریف رایج (یکی را انتخاب و ثابت کنید)

• • • MTTR (آچار): زمان شروع تا پایان عملیات تعمیر توسط تیم نت، بدون زمان انتظار.

    • MTTR (بازگشت به سرویس): از لحظه اعلام خرابی تا لحظه تحویل تجهیز به تولید. این تعریف برای مدیریت توقف واقعی کاربردی‌تر است.

مثال: چرا MTTR «ظاهراً عالی» می‌شود ولی توقف کم نمی‌شود؟

یک پمپ سیرکولاسیون در شیفت شب از کار می‌افتد. اعلام خرابی ساعت ۲۲:۱۰. تکنسین ۲۲:۳۰ می‌رسد. قطعه مکانیکال‌سیل در انبار نیست. سفارش اضطراری و تامین از بازار، صبح می‌رسد. نصب و تست انجام می‌شود و پمپ ساعت ۰۹:۲۰ تحویل می‌شود.

• • • اگر فقط زمان آچار را حساب کنید (مثلاً ۱ ساعت)، MTTR خیلی خوب به نظر می‌رسد.

    • اما توقف واقعی ۱۱ ساعت و ۱۰ دقیقه بوده و Availability را می‌زند.

به همین دلیل در گزارش‌های تصمیم‌محور، MTTR را به اجزای زیر تفکیک می‌کنند:

• • • زمان تشخیص (Diagnosis)

    • زمان انتظار نیروی انسانی/مجوز کار

    • زمان انتظار قطعه/تدارکات

    • زمان تعمیر و مونتاژ

    • زمان تست و راه‌اندازی

اگر در یک ماه ببینید سهم «انتظار قطعه» ۵۰٪ کل MTTR است، راه‌حل شما آموزش تکنسین نیست؛ بلکه سیاست سطح موجودی و تامین پایدار است. اینجا حتی انتخاب درست روانکار هم اثر غیرمستقیم دارد: روغن مناسب و پایش درست، تعداد خرابی‌های مرتبط با سایش/دما را کم می‌کند و فشار روی انبار قطعات را پایین می‌آورد.

MTTR را همیشه همراه با «پای چارت» اجزای زمان گزارش کنید. یک MTTR تک‌عددی بدون اجزا، برای اقدام اصلاحی کافی نیست.

OEE: اگر Availability را غلط ببندید، کل عدد بی‌اعتبار می‌شود

OEE (Overall Equipment Effectiveness) ترکیبی است از سه جزء:

• • • Availability (دسترس‌پذیری): چند درصد از زمان برنامه‌ریزی‌شده، تجهیز واقعاً در دسترس تولید بوده.

    • Performance (عملکرد): در زمان کار، با چه سرعتی نسبت به استاندارد تولید کرده.

    • Quality (کیفیت): چند درصد تولید، قابل قبول بوده.

فرمول رایج: OEE = Availability × Performance × Quality

مثال عددی ساده (اما واقعی)

یک دستگاه پرس در یک شیفت ۸ ساعته، ۷ ساعت «زمان برنامه‌ریزی‌شده تولید» دارد (۱ ساعت استراحت/جلسه خارج از برنامه تولید). در این ۷ ساعت، ۳۰ دقیقه توقف خرابی و ۲۰ دقیقه توقف تنظیمات داشته است. زمان کار واقعی می‌شود ۶ ساعت و ۱۰ دقیقه.

• • • Availability = ۶:۱۰ / ۷:۰۰ ≈ ۸۸٪

    • اگر سرعت استاندارد ۱۰۰ قطعه/ساعت باشد و شما در ۶:۱۰، ۵۴۰ قطعه زده‌اید: Performance ≈ ۵۴۰ / ۶۱۶ ≈ ۸۸٪

    • اگر ۲۰ قطعه مرجوعی دارید: Quality = (۵۴۰-۲۰)/۵۴۰ ≈ ۹۶٪

    • OEE ≈ ۰.۸۸ × ۰.۸۸ × ۰.۹۶ ≈ ۷۴٪

چالش رایج اینجاست: بعضی مجموعه‌ها «توقف تنظیمات» را از Availability خارج می‌کنند تا عدد بهتر شود. اما اگر تنظیمات ماهیتاً به تجهیز و قابلیت نگهداشت مربوط است، حذفش یعنی از دست‌دادن فرصت بهبود. OEE باید واقعیت بهره‌وری را نشان دهد، نه اینکه برای ارائه زیباتر شود.

قبل از محاسبه OEE، یک جدول کُد توقف استاندارد بسازید و مشخص کنید هر توقف داخل کدام جزء می‌رود. اگر کُد توقف استاندارد ندارید، OEE شما قابل دفاع نیست.

چطور KPIها را «قابل گزارش و قابل اقدام» کنید؟ قالب گزارش ماهانه پیشنهادی

گزارش KPI وقتی مفید است که هم روند بدهد، هم علت. پیشنهاد عملی برای قالب گزارش ماهانه (برای هر تجهیز کلیدی یا هر خط):

• • 1. سه عدد اصلی: MTBF، MTTR، OEE

    2. Top 3 علت خرابی (بر اساس توقف یا تکرار)

    3. تفکیک MTTR به اجزای زمان (به درصد)

    4. اقدام اصلاحی مشخص + مالک اقدام + تاریخ موعد

برای اینکه گزارش‌ها مقایسه‌پذیر باشند، این حداقل‌ها را ثابت نگه دارید: بازه زمانی، تعریف خرابی، منبع داده (CMMS/دفتر شیفت/SCADA) و روش برخورد با توقف‌های زیر ۵ دقیقه.

در تجهیزات خودرویی یا ناوگانی هم منطق مشابه است، فقط واحد کارکرد تغییر می‌کند. مثلاً به‌جای «ساعت»، «کیلومتر» یا «ساعت موتور» معیار می‌شود و داده‌ها از سرویس‌های دوره‌ای می‌آید؛ برای ناوگان‌هایی که در چند شهر سرویس می‌شوند، یکپارچه‌سازی تامین و مشخصات مصرفی روغن موتور می‌تواند اختلاف‌های ناشی از تنوع روغن و سرویس را کمتر کند و تحلیل KPI را تمیزتر کند.

گزارش را با «۳ اقدام اصلاحی ماه بعد» تمام کنید. اگر خروجی جلسه KPI اقدام ندارد، جلسه KPI در عمل بی‌اثر است.

چالش‌ها و راه‌حل‌ها: وقتی KPIها با واقعیت کف کارخانه نمی‌خوانند

در فضای واقعی ایران، چند چالش پرتکرار داریم که KPI را منحرف می‌کند. این‌ها را بهتر است صریح ببینیم:

چالش ۱: داده ناقص و ثبت سلیقه‌ای

اگر اپراتور یک توقف را «کم‌اهمیت» بداند و ثبت نکند، MTBF زیبا می‌شود ولی مشکل باقی می‌ماند.

• • • راه‌حل: یک فرم ثبت توقف ساده با ۵ فیلد اجباری (زمان شروع/پایان، کد توقف، علت ظاهری، اقدام انجام‌شده، وضعیت تحویل) و آموزش کوتاه شیفتی.

چالش ۲: فشار برای عددسازی

وقتی KPI ابزار تنبیه شود، افراد طبیعی است که دسته‌بندی را دستکاری کنند.

• • • راه‌حل: KPI را «ابزار یادگیری» کنید: به‌جای مقصر، روی علت ریشه‌ای و اقدام تمرکز کنید.

چالش ۳: خرابی‌های مرتبط با روانکاری که زیر رادار می‌مانند

بخشی از خرابی‌های یاتاقان، دمای بالا، گیرپاژ یا کف‌کردن سیستم، از «تغییر شرایط روغن» شروع می‌شود ولی در گزارش به‌عنوان «خرابی مکانیکی» می‌آید و چرخه تکرار می‌شود.

• • • راه‌حل: برای تجهیزات حساس، یک ردیف «وضعیت روانکاری» در گزارش خرابی اضافه کنید: سطح روغن، نشتی، آلودگی ظاهری، زمان آخرین تعویض/فیلتراسیون. در صورت نیاز، سیاست‌های تامین منطقه‌ای مثل تامین روغن صنعتی در شهر اصفهان کمک می‌کند تامین پایدارتر شود و ریسک توقف ناشی از کمبود یا جایگزینی نامناسب کاهش یابد.

هر خرابی تکرارشونده (بیش از ۲ بار در ماه یا ۳ بار در فصل) را از چرخه KPI ماهانه خارج کنید و وارد یک «جلسه RCA کوتاه» کنید؛ KPI باید شما را به RCA برساند.

پرسش‌های متداول درباره MTBF، MTTR و OEE

۱) MTBF را برای تجهیزی که چند نوع توقف دارد چطور حساب کنیم؟

اول باید تعریف کنید «خرابی» کدام توقف‌هاست. توقف‌های برنامه‌ریزی‌شده (مثل PM یا اورهال) را معمولاً از MTBF حذف می‌کنند، اما توقف‌های عملکردی (افت فشار، تریپ، نشتی) را داخل می‌آورند. مهم این است که در کل سازمان یکسان باشد. سپس مجموع زمان کارکرد واقعی را بر تعداد خرابی‌های تعریف‌شده تقسیم کنید.

۲) MTTR بهتر است شامل زمان انتظار قطعه باشد یا نه؟

برای تصمیم‌گیری مدیریتی و کاهش توقف، بهتر است MTTR را «از اعلام خرابی تا تحویل به تولید» تعریف کنید، چون واقعیت توقف را نشان می‌دهد. اما برای ارزیابی کارایی تیم فنی، می‌توانید در کنار آن «زمان آچار» را هم جداگانه گزارش کنید. ترکیب این دو، هم انصاف دارد هم قابلیت اقدام.

۳) آیا OEE برای همه صنایع و تجهیزات مناسب است؟

برای تجهیزات گلوگاهی و خطوط تولید تکرارشونده بسیار مفید است. برای تجهیزاتی که استفاده‌شان متناوب یا پروژه‌ای است (مثلاً بعضی ماشین‌آلات کارگاهی)، OEE ممکن است گمراه‌کننده شود مگر اینکه زمان برنامه‌ریزی‌شده را دقیق تعریف کنید. در این موارد گاهی Availability و شاخص‌های خرابی (MTBF/MTTR) تصویر شفاف‌تری می‌دهند.

۴) توقف‌های کمتر از ۵ دقیقه را ثبت کنیم یا حذف؟

اگر ثبت نشوند، معمولاً MTBF و OEE بهتر از واقعیت دیده می‌شوند، در حالی که همین توقف‌های ریز می‌توانند نشانه مشکل جدی باشند (مثل حساسیت سنسور، روانکاری ناکافی، دمای بالای موضعی). پیشنهاد عملی این است: توقف‌های زیر ۵ دقیقه را به‌صورت «تعداد و مجموع زمان» جداگانه گزارش کنید تا هم بار ثبت سنگین نشود و هم سیگنال از بین نرود.

۵) KPIها را با چه تناوبی پایش کنیم که هم دقیق باشد هم زمان‌گیر نشود؟

برای تجهیزات بحرانی، پایش هفتگی (روند کوتاه) و گزارش ماهانه (تصمیم مدیریتی) ترکیب خوبی است. برای تجهیزات غیر بحرانی، گزارش ماهانه کافی است. نکته کلیدی این است که جلسه KPI کوتاه و اقدام‌محور باشد: ۳۰ تا ۴۵ دقیقه با سه خروجی مشخص بهتر از یک جلسه دو ساعته بدون اقدام است.

جمع‌بندی: KPI تعمیرات وقتی ارزش دارد که به تصمیم تبدیل شود

MTBF، MTTR و OEE قرار نیست «عددهای تزئینی» باشند. MTBF باید به شما بگوید کدام خرابی‌ها تکرار می‌شوند و کجا باید پیشگیری یا پایش وضعیت را جدی‌تر کنید. MTTR باید نشان دهد گلوگاه بازگشت به سرویس کجاست: تشخیص، تامین قطعه، مجوز کار یا مهارت فنی. OEE هم اگر درست کُدگذاری شود، به‌جای اختلاف، یک زبان مشترک بین تولید و نت می‌سازد. در عمل، بهترین KPI آن است که انتهای گزارشش یک اقدام واضح داشته باشد: چه کاری، توسط چه کسی، تا چه تاریخی. اگر این حلقه بسته شود، KPI از «گزارش» به «مدیریت» تبدیل می‌شود و اثرش را در کاهش توقف و هزینه، خیلی سریع خواهید دید.