چرا مهندسان از خرابی متنفرند (و چگونه آن را برطرف می کنیم)

زمان از کار افتادن بیشتر از یک ماشین متوقف است. این می تواند حمل و نقل را به تاخیر بیاندازد، اضافه کاری ایجاد کند، مواد اولیه را هدر دهد، اعتماد مشتری را تحت تاثیر قرار دهد و بر تیم مهندسی فشار وارد کند. من دیده ام که یک خطای کوچک سنسور به تاخیر طولانی در تولید تبدیل شده است، زیرا اخطار نادیده گرفته شده است، قطعه یدکی در دسترس نبود و هیچ کس برنامه بازیابی روشنی نداشته است. مهندسان از تعمیر و نگهداری بیزارند. آنها از خرابی قابل پیشگیری بیزارند. هدف این نیست که هر ماشینی بدون وقفه کار کند. که واقع بینانه نیست. هدف این است که بفهمیم کجا ممکن است خرابی رخ دهد، خطرات قابل اجتناب را کاهش دهد، و در صورت بروز مشکل به روشی کنترل شده بازیابی شود. ## با علل خرابی شروع کنید بسیاری از شرکت ها زمان خرابی را به عنوان یک عدد دنبال می کنند. این عدد زیاد توضیح نمی دهد. من ترجیح می‌دهم زمان خرابی را به دسته‌های واضح تقسیم کنم: - خرابی مکانیکی - خطای الکتریکی - مشکل نرم‌افزار یا سیستم کنترل - کمبود قطعات یدکی - خطای اپراتور - تأخیر در تعویض - تعمیر و نگهداری برنامه‌ریزی‌شده - علل خارجی، مانند قطع برق یا شبکه کارخانه‌ای که «خط 45 دقیقه متوقف شده» را ثبت می‌کند، اطلاعات محدودی دارد. یک رکورد بهتر می تواند بگوید: - موتور نوار نقاله بیش از حد گرم شد - هشدار دما به مدت 20 دقیقه نادیده گرفته شد - موتور جایگزین در دسترس نبود - تولید پس از تنظیم دستی از سر گرفته شد این نوع رکورد به تیم مهندسی چیزی برای عمل می دهد. ## قبل از ایجاد تغییرات از داده ها استفاده کنید تصمیمات تعمیر و نگهداری باید ناشی از رفتار ماشین باشد، نه حدس زدن. داده های مفید ممکن است شامل موارد زیر باشد: - دمای موتور - لرزش - فشار - جریان جریان - کدهای خطا - زمان چرخه - سرعت تولید - مدت زمان تعمیر - الگوهای هشدار مکرر افزایش ارتعاش ممکن است به سایش یاتاقان اشاره کند. تغییر در کشش فعلی ممکن است نشان دهنده بار اضافی باشد. هشدار مکرر در طول همان مرحله تولید ممکن است یک مشکل کنترل یا تراز را نشان دهد. داده ها نیازی به پیچیده بودن ندارند. حتی یک صفحه گسترده که به خوبی نگهداری شده باشد می تواند الگوهایی را نشان دهد که به راحتی در طول یک شیفت کاری شلوغ از دست می روند. توصیه می کنم زمان خرابی را بر اساس دستگاه، نوع خطا، شیفت، محصول و مدت تعمیر مرور کنید. این اغلب نشان می دهد که تعداد کمی از مسائل تکراری باعث از دست رفتن زمان تولید می شود. ## تعمیر و نگهداری را بر اساس ریسک انجام دهید، هر دارایی به یک برنامه تعمیر و نگهداری نیاز ندارد. چاپگر اداری خراب ممکن است ناراحت کننده باشد. خرابی پمپ خنک کننده، دستگاه ایمنی یا کنترل کننده تولید ممکن است کل عملیات را متوقف کند. برخورد یکسان با هر دو دارایی باعث هدر رفتن زمان و منابع می شود. من از سه سوال برای تعیین اولویت های نگهداری استفاده می کنم: 1. اگر این دارایی از کار بیفتد چه اتفاقی می افتد؟ 2. بهبودی چقدر طول می کشد؟ 3. آیا شکست می تواند یک نگرانی ایمنی، کیفیت یا زیست محیطی ایجاد کند؟ تجهیزات پرخطر ممکن است به نظارت بر وضعیت، بازرسی های برنامه ریزی شده، قطعات یدکی حیاتی و یک روش بازیابی واضح نیاز داشته باشند. دارایی های با ریسک کمتر ممکن است فقط به بررسی های معمول و برنامه ریزی جایگزینی اولیه نیاز داشته باشند. این رویکرد به مهندسان کمک می کند تا زمانی را صرف کنند که بتواند بیشترین ریسک عملیاتی را کاهش دهد. ## پیگیری تعمیرات برنامه ریزی شده را آسان تر کنید یک برنامه تعمیر و نگهداری ممکن است حتی زمانی که کار فنی درست باشد شکست بخورد. ممکن است دستورالعمل‌ها خیلی طولانی باشند، پیدا کردن قطعات به سختی ممکن است، یا ممکن است وقتی کار برنامه‌ریزی شده است، دستگاه در دسترس نباشد. یک دستور کار مفید باید به تکنسین بگوید: - چه چیزی باید بررسی شود - چه ابزارهایی مورد نیاز است - کدام مراحل ایمنی اعمال می شود - چه خوانش های قابل قبولی به نظر می رسد - کدام قطعات ممکن است به تعویض نیاز داشته باشند - معمولاً چقدر طول می کشد - بعد از اتمام چه چیزی باید ضبط شود عکس ها، نمودارها و چک لیست های کوتاه می توانند تفاوت زیادی ایجاد کنند. بهترین سند طولانی ترین سند نیست. این همان چیزی است که یک تکنسین می تواند در کنار دستگاه بدون توقف برای تفسیر زبان نامشخص استفاده کند. همچنین پیشنهاد می کنم سفارشات تکمیل شده را بررسی کنید. اگر تکنسین ها اغلب همان مرحله گم شده را اضافه می کنند، روش را به روز کنید. اسناد نگهداری باید منعکس کننده روشی باشد که واقعاً کار انجام می شود. ## قطعات یدکی حیاتی را تحت کنترل نگه دارید یک ماشین فقط زمانی می تواند به سرعت تعمیر شود که قطعه مناسب در دسترس باشد. بسیاری از تیم ها تجهیزات را با دقت ردیابی می کنند، اما خطر قطعات یدکی را با همان توجه ردیابی نمی کنند. یک سنسور کم هزینه ممکن است زمان تحویل طولانی داشته باشد. یک موتور معمولی ممکن است چندین مدل سازگار داشته باشد، اما تنها یکی ممکن است با تنظیمات فعلی مطابقت داشته باشد. برای قطعات حیاتی، موارد زیر را ثبت کنید: - شماره قطعه - جایگزین های سازگار - تامین کننده - زمان تحویل معمولی - محل ذخیره سازی - حداقل سطح انبار - الزامات ماندگاری - تجهیزاتی که از قطعه استفاده می کنند یک بررسی ساده موجودی می تواند از انتظار طولانی پس از تشخیص کوتاه مدت جلوگیری کند. همچنین احتمال خرید قطعه جایگزین اشتباه در طول تعمیر فوری را کاهش می دهد. ## برای بازیابی آماده شوید، نه تنها پیشگیری، برخی از خرابی ها علیرغم تعمیر و نگهداری خوب اتفاق می افتد. وقتی آنها این کار را انجام می دهند، تیم به یک برنامه ریکاوری نیاز دارد. این طرح باید توضیح دهد که چه کسی خطا را بررسی می کند، چه کسی راه اندازی مجدد را تایید می کند، چه کسی با تولید تماس می گیرد و چه کسی رویداد را ثبت می کند. یک راهنمای بازیابی عملی ممکن است شامل موارد زیر باشد: - مراحل خاموش کردن ایمن - بررسی های اولیه عیب - تماس های تشدید - محدودیت های عملیاتی دستی - تعمیرات موقت تایید شده - بررسی های راه اندازی مجدد - بررسی های کیفیت محصول - مراحل ارتباطی در طول یک رویداد استرس زا، افراد به ندرت وقت دارند در چندین سیستم برای دستورالعمل ها جستجو کنند. یک runbook کوتاه و در دسترس می تواند سردرگمی را کاهش دهد و به تیم کمک کند تا تصمیمات ایمن تری بگیرد. ## از اشتباهات نزدیک یاد بگیرید یک ماشین قبل از اینکه چیزی به ما بیاموزد نیازی به شکست کامل ندارد. آلارم‌های مکرر، نشت‌های جزئی، افزایش دما، تأخیر در شروع کار و تعمیرات موقت همگی می‌توانند به یک مشکل بزرگ‌تر اشاره کنند. اگر این علائم نادیده گرفته شوند، تعمیر نهایی ممکن است به زمان بیشتر و قطعات بیشتری نیاز داشته باشد. من مهندسان را تشویق می‌کنم که اشتباهات نزدیک را به همان روشی که شکست‌ها را ثبت می‌کنند، ثبت کنند. هدف سرزنش شخصی نیست که متوجه موضوع شده یا تعدیل موقت را انجام داده است. هدف این است که مشخص شود چه چیزی باعث شده مشکل حل نشده باقی بماند. یک بررسی مفید می پرسد: - اولین هشدار چه بود؟ - کی متوجه شد؟ - چه اقدامی انجام شد؟ - چرا تعمیر دائمی به تعویق افتاد؟ - چه چیزی پاسخ بعدی را آسان تر می کند؟ این یک فرهنگ تعمیر و نگهداری را بر اساس یادگیری به جای عیب یابی ایجاد می کند. ## نرم‌افزار و شبکه‌ها را به عنوان بخشی از آپتایم در نظر بگیرید تجهیزات مدرن به چیزی بیش از موتورها، پمپ‌ها و قطعات مکانیکی وابسته هستند. کنترل‌کننده‌ها، شبکه‌های صنعتی، ابزارهای دسترسی از راه دور، پایگاه‌های داده و به‌روزرسانی‌های نرم‌افزاری نیز می‌توانند بر تولید تأثیر بگذارند. حمله NotPetya 2017 که مرسک را مختل کرد نشان داد که چگونه یک حادثه دیجیتال می تواند بر عملیات فیزیکی و فعالیت تجاری تأثیر بگذارد. این درس فراتر از حمل و نقل اعمال می شود. برنامه ریزی زمان کار صنعتی باید شامل پشتیبان گیری از سیستم، کنترل دسترسی، آزمایش به روز رسانی و روش های بازیابی باشد. تیم های مهندسی و فناوری اطلاعات به دیدگاه مشترکی از سیستم های حیاتی نیاز دارند. پشتیبان گیری کنترلر تنها زمانی مفید است که تیم بداند کجا ذخیره شده و چگونه آن را بازیابی کند. یک نمودار شبکه تنها زمانی مفید است که با نصب فعلی مطابقت داشته باشد. ## کارهایی را که باعث بهبود زمان کار می‌شود، اندازه‌گیری کنید، ساعات توقف مفید هستند، اما کل داستان را بیان نمی‌کنند. من همچنین به موارد زیر نگاه می‌کنم: - میانگین زمان بین خرابی‌ها - میانگین زمان تعمیر - میزان خرابی تکراری - تکمیل برنامه‌ریزی شده تعمیر و نگهداری - درصد کار اضطراری - زمان انتظار قطعات یدکی - زمان پاسخگویی زنگ هشدار - سن عقب‌افتادگی این اقدامات کمک می‌کند بهبود کوتاه‌مدت را از بهبود پایدار جدا کند. به عنوان مثال، یک خط ممکن است ساعات توقف کمتری را پس از یک دور زدن موقت نشان دهد. این بدان معنا نیست که مشکل اساسی حل شده است. اگر همان خطا برگردد، کسب و کار ممکن است فقط هزینه را به تاریخ بعدی منتقل کند. اندازه‌گیری خوب، کار مهندسی را با نتایج تولید مرتبط می‌کند و در عین حال ایمنی و کیفیت را قابل مشاهده نگه می‌دارد. ## یک مسیر عملی برای کاهش زمان خرابی هنگامی که یک مشکل خرابی را بررسی می‌کنم، از یک دنباله ساده استفاده می‌کنم: 1. جمع‌آوری سوابق چندین ماهه خرابی و تعمیر. 2. رویدادها را بر اساس نوع دارایی و شکست گروه بندی کنید. 3. خطاهای مکرر و زمان بهبود طولانی را شناسایی کنید. 4. بررسی کنید که آیا علت اصلی مکانیکی، الکتریکی، دیجیتالی، رویه ای یا مربوط به تامین است. 5. برای هر موضوع پرخطر یک اقدام نگهداری تنظیم کنید. 6. اطمینان حاصل کنید که ابزار، قطعات و دستورالعمل های مورد نیاز در دسترس هستند. 7. روش بازیابی را با افرادی که از آن استفاده خواهند کرد آزمایش کنید. 8. نتایج را پس از دوره عملیاتی بعدی مرور کنید. این فرآیند به یک پروژه نرم افزاری بزرگ نیاز ندارد. این نیاز به سوابق دقیق، مالکیت واضح و بررسی منظم دارد. مهندسان انتظار ندارند که ماشین‌ها کاملاً رفتار کنند. آنها انتظار دارند که کسب و کار به علائم هشدار دهنده توجه کند، از تعمیر و نگهداری ایمن پشتیبانی کند و از هر شکست درس بگیرد. یک برنامه زمانی قوی ترکیبی از نظارت بر وضعیت، برنامه های تعمیر و نگهداری عملی، کنترل قطعات یدکی، مراحل بازیابی واضح و داده های صادقانه است. این به مهندسان شگفتی های کمتری می دهد و به تیم های تولید فرصت بیشتری برای انجام تعهدات خود می دهد. بهترین نتیجه این نیست که زمان خرابی از بین برود. این سیستمی است که به تیم کمک می‌کند از توقف‌های قابل اجتناب جلوگیری کند، سریع‌تر پاسخ دهد و در صورت خرابی تجهیزات تصمیم‌گیری بهتری بگیرد.

وقتی یک سرویس از کار می افتد، تیم من بیشتر از دسترسی به یک ابزار را از دست می دهد. ما تمرکز خود را از دست می دهیم، انتشار را به تأخیر می اندازیم، به پیام های پشتیبانی پاسخ می دهیم و ساعت ها را صرف جستجو در لاگ ها می کنیم. کاری که یک محصول را به جلو می برد باید منتظر بماند. خرابی کمتر با دید واضحی از نحوه رفتار سیستم ها شروع می شود. این نیازی به یک تیم عملیات بزرگ یا یک فرآیند پیچیده ندارد. تغییرات کوچک می تواند به تیم کمک کند تا با وقفه های کمتری بسازد. با فهرست کردن بخش‌هایی از محصول که کاربران هر روز به آن‌ها اعتماد می‌کنند، شروع می‌کنم: - سرورهای برنامه - پایگاه‌های داده - خدمات پرداخت - ذخیره‌سازی فایل - ابزارهای ورود و حساب - APIهای خارجی - سیستم‌های نظارت و هشدار این فهرست نشان می‌دهد که در کجا ممکن است قطعی بر روی کاربران تأثیر بگذارد. همچنین به من کمک می کند تا یک نظم معقول برای بهبود تنظیم کنم. یک سرویس پرداخت ممکن است به پاسخ سریع تری نسبت به صفحه گزارش داخلی نیاز داشته باشد. یک مشکل ورود به سیستم مشتری ممکن است قبل از یک مشکل طرح بندی جزئی نیاز به توجه داشته باشد. سپس شایع‌ترین علل خرابی را دنبال می‌کنم. بسیاری از حوادث از منابع آشنا ناشی می شوند: - استقرار بیش از حد انتظار تغییر می کند - پایگاه داده به حد مجاز خود می رسد - گواهی منقضی شده دسترسی را مسدود می کند - سرویس شخص ثالث پاسخ نمی دهد - افزایش ترافیک از تمام منابع موجود استفاده می کند - یک کار پس زمینه ناموفق یک صف ایجاد می کند - هشداری پس از اینکه کاربران قبلاً مشکل را گزارش کرده اند می رسد وقتی الگو را می دانم، می توانم به جای درمان هر حادثه روی علت کار به عنوان یک غافلگیرکننده کار کنم. فرآیند آزادسازی ایمن تر نیز وقفه ها را کاهش می دهد. من تغییرات کوچکی را ترجیح می دهم که به راحتی بررسی شوند و به راحتی قابل برگشت باشند. هر نسخه باید شامل موارد زیر باشد: 1. توضیح کوتاهی از تغییر، 2. آزمایشی برای مسیر کاربر اصلی، 3. یک مرحله بازگشت واضح، 4. شخصی که مسئول بررسی نسخه است 5. یک رکورد کوتاه از آنچه اتفاق افتاده است انتشار مرحله‌ای می‌تواند به یک تیم کمک کند تا تغییرات را قبل از رسیدن به هر کاربر مشاهده کند. اگر نرخ خطا افزایش یابد، تیم می‌تواند عرضه را متوقف کند و تغییر را بررسی کند. این به توسعه دهندگان فضایی برای ساخت بدون تبدیل هر نسخه به یک رویداد پرخطر می دهد. نظارت نیاز به همان سطح تمرکز دارد. هشدارهای زیاد باعث ایجاد نویز می شود. هشدارهای بسیار کمی تیم را بدون اطلاعات مفید رها می کند. هشدارهایی را انتخاب می‌کنم که به تأثیر کاربر متصل می‌شوند، مانند: - افزایش شدید درخواست‌های ناموفق - زمان پاسخ آهسته صفحه یا API - خرابی‌های غیرمعمول ورود به سیستم - پایگاه داده کامل یا تقریباً کامل - صف کار رو به رشد - سرویسی که ارسال چک‌های سلامت را متوقف کرده است. پیامی مانند "خطای سرویس" کمک زیادی نمی کند. پیامی مانند «شکست‌های پرداخت پس از آخرین نسخه از محدوده طبیعی بالاتر رفت» نقطه شروع واضح‌تری را به تیم می‌دهد. یک تیم محصول کوچک می تواند از این رویکرد بدون افزودن لیست طولانی ابزار استفاده کند. به عنوان مثال، یک تیم وب پنج نفره ممکن است سوابق آپتایم خود را بررسی کند، متوجه شود که بیشتر وقفه ها از هشدارهای ذخیره سازی پایگاه داده پیروی می کنند و هشدار ذخیره سازی را در سطح قبلی تنظیم می کند. تیم همچنین ممکن است یک چک پشتیبان هفتگی اضافه کند و یک بازیابی را در یک محیط جداگانه آزمایش کند. این مراحل همه خطرات را از بین نمی برند، اما احتمال اینکه یک مشکل شناخته شده به یک قطع طولانی تبدیل شود را کاهش می دهند. پشتیبان گیری نیز نیاز به بررسی منظم دارد. یک نسخه پشتیبان که هرگز بازیابی نشده است تنها یک فرض است. من یک آزمایش بازیابی را برنامه ریزی می کنم، مدت زمان طول می کشد را ضبط می کنم و توجه می کنم که کدام فایل ها یا تنظیمات گم شده اند. این به تیم یک طرح بازیابی عملی به جای سندی می دهد که هیچ کس آن را آزمایش نکرده است. مسائل مالکیت روشن در طول یک حادثه. من تعیین می کنم چه کسی سیستم را بررسی می کند، چه کسی با مشتریان ارتباط برقرار می کند و چه کسی جدول زمانی را ثبت می کند. یک نفر نباید همزمان موضوع را بررسی کند، به‌روزرسانی بنویسد و هر مکالمه‌ای را مدیریت کند. پس از بازگشت سرویس، رویداد را بدون سرزنش شخصی مرور می کنم. می پرسم: - قبل از شروع موضوع چه چیزی تغییر کرد؟ - چگونه مشکل را تشخیص دادیم؟ - کدام مرحله پاسخ را کند کرد؟ - چه چیزی به ما در بازیابی سرویس کمک کرد؟ - چه تغییر کوچکی می تواند از یک اتفاق مشابه جلوگیری کند؟ هدف بهبود سیستم و فرآیند است. یک بررسی کوتاه ممکن است به هشدار بهتر، بررسی استقرار ایمن‌تر یا راهنمای بازیابی واضح‌تر منجر شود. کار قابل اعتماد فضای بیشتری را برای ساخت و ساز ایجاد می کند. توسعه دهندگان زمان کمتری را صرف تکرار چک های دستی می کنند. تیم های پشتیبانی به روز رسانی های واضح تری دریافت می کنند. مشتریان با وقفه های کمتری مواجه می شوند. تیم می‌تواند روی بهبود محصول تمرکز کند و در عین حال درک و نگهداری سیستم‌های پشت خود را آسان‌تر نگه دارد. من خرابی را نشانه شکست یک تیم نمی دانم. من با آن به عنوان یک سیگنال رفتار می کنم. هنگامی که تیم آن سیگنال را مطالعه می کند، خطرات شناخته شده را برطرف می کند و هر تغییر را برای بررسی آسان نگه می دارد، می تواند با وقفه های کمتری در کار پیشرفت ثابتی داشته باشد.

هنگامی که یک سیستم کار نمی کند، ضربه بسیار فراتر از صفحه نمایش می رسد. کارکنان وقت خود را از دست می دهند، مشتریان ممکن است بیشتر منتظر بمانند، و مسائل فنی کوچک می تواند به وقفه های روزانه تبدیل شود. من با کسب‌وکارهایی کار می‌کنم که به جای کاهش سرعت، به سیستم‌هایشان برای حمایت از تیم نیاز دارند. تمرکز من ساده است: درک نحوه کار افراد شما، یافتن نقاط ضعف، و ایجاد پشتیبانی حول ابزارهایی که کسب و کار شما از قبل استفاده می کند. با گردش کار روزانه شروع کنید من با نگاهی به کار پشت فناوری شروع می کنم. کارکنان هر روز از کدام سیستم ها استفاده می کنند؟ تاخیر در کجا اتفاق می افتد؟ کدام وظایف به یک نفر بستگی دارد؟ وقتی یک دستگاه، حساب یا سرور از کار می افتد چه اتفاقی می افتد؟ یک تیم فروش ممکن است به ایمیل، پایگاه داده مشتری و فایل های مشترک وابسته باشد. یک انبار ممکن است به نرم افزار انبار و اسکنر بارکد متکی باشد. یک دفتر کوچک ممکن است به اینترنت پایدار، حساب های کاربری ایمن و دسترسی به پلتفرم های ابری نیاز داشته باشد. هر کسب و کاری الگوی کاری متفاوتی دارد. یک طرح پشتیبانی باید به جای اعمال چک لیست یکسان برای هر شرکت، آن الگو را منعکس کند. سیستم ها را قابل مشاهده نگه دارید وقتی تیم می تواند ببیند چه اتفاقی می افتد، مدیریت مشکلات آسان تر است. من به کسب‌وکارها کمک می‌کنم تا بررسی کنند: - سلامت دستگاه - عملکرد شبکه - دسترسی کاربر - به‌روزرسانی‌های نرم‌افزار - استفاده از فضای ذخیره‌سازی - وضعیت پشتیبان‌گیری - هشدارهای امنیتی - وقفه‌های سرویس این اطلاعات به کسب‌وکار نمای مفیدی از سیستم‌هایش می‌دهد. همچنین به جدا کردن یک مشکل یکباره از مشکلی که هر هفته ظاهر می شود کمک می کند. برای مثال، یک آژانس طراحی ممکن است متوجه شود که فایل‌های بزرگ هر روز بعد از ظهر باز شدن زمان بیشتری طول می‌کشد. یک بررسی می‌تواند نشان دهد که وقتی چندین کارمند فایل‌های پروژه را همزمان آپلود می‌کنند، ترافیک ذخیره‌سازی افزایش می‌یابد. پاسخ ممکن است شامل برنامه ریزی ذخیره سازی، تغییرات شبکه، یا فرآیند به اشتراک گذاری فایل بهتر باشد. عمل درست از درک علت حاصل می شود. کاهش وقفه‌های قابل اجتناب بسیاری از درخواست‌های پشتیبانی از مشکلات مکرر ناشی می‌شوند: - رمزهای عبور فراموش شده - دسترسی به نرم‌افزار منقضی شده - فضای ذخیره‌سازی کامل - مجوزهای کاربر نامشخص - دستگاه‌هایی که به‌روزرسانی‌ها را از دست می‌دهند - فایل‌هایی که در چندین مکان مختلف ذخیره شده‌اند، رفع این مشکلات فقط چند دقیقه طول می‌کشد، اما دوباره و دوباره بازمی‌گردند. یک فرآیند ساده می تواند تعداد درخواست های مکرر را کاهش دهد. من ممکن است مدیریت رمز عبور، به‌روزرسانی‌های خودکار، بررسی‌های دسترسی کاربر، قوانین فایل مشترک یا راهنمای کوتاه کارکنان را توصیه کنم. هدف اضافه کردن ابزارهای بیشتر به خاطر افزودن ابزار نیست. هدف حذف اصطکاک از کار عادی است. برای وقفه های سرویس آماده شوید هیچ سیستمی بدون خطر کار نمی کند. قطع برق، دستگاه خراب، فایل آسیب دیده یا قفل حساب می تواند کل تیم را تحت تاثیر قرار دهد. یک طرح پاسخ عملی باید پاسخ دهد: 1. چه کسی موضوع را گزارش می کند؟ 2. کدام سیستم ها ابتدا نیاز به توجه دارند؟ 3. چه کسی می تواند تغییر را تایید کند؟ 4. نسخه های پشتیبان کجا ذخیره می شوند؟ 5. کارکنان چگونه به کار خود ادامه خواهند داد؟ 6. چه زمانی باید به مشتریان یا تامین کنندگان اطلاع داده شود؟ همچنین بررسی می‌کنم که آیا می‌توان نسخه‌های پشتیبان را بازیابی کرد، نه فقط اینکه آیا یک کار پشتیبان کامل نشان داده می‌شود یا خیر. پشتیبان‌گیری که در صورت نیاز باز نمی‌شود کمک زیادی نمی‌کند. برای مثال، یک شرکت حسابداری کوچک ممکن است سوابق مشتری را در یک پوشه ابری مشترک نگهداری کند. اگر یک پوشه به اشتباه حذف شود، تیم باید بداند که چگونه آن را بازیابی کند، چه کسی مجوز این کار را دارد و چگونه از تکرار همان خطا جلوگیری کند. حمایت از افراد و همچنین سیستم مسائل فناوری اغلب مسائل مردم است. یک کارمند جدید ممکن است نداند کجا درخواست دسترسی کند. یک مدیر ممکن است بدون دانستن مجوزهای مورد نیاز، حساب ها را تأیید کند. یکی از کارکنان ممکن است از یک راه حل ناامن استفاده کند زیرا فرآیند تأیید شده بسیار کند به نظر می رسد. من راهنمایی پشتیبانی ایجاد می کنم که افراد می توانند بدون آموزش فنی دنبال کنند. دستورالعمل‌های کوتاه، مالکیت واضح و مسیر تماس شناخته شده می‌تواند سردرگمی را کاهش دهد. پشتیبانی خوب باید به کارمندان کمک کند تا در طول یک روز شلوغ، انتخاب درستی داشته باشند. اسناد طولانی که هیچ کس نمی خواند چیز زیادی را حل نمی کند. از یک چرخه پشتیبانی ساده استفاده کنید یک فرآیند پشتیبانی کاری می تواند از این الگو پیروی کند: - تنظیم فعلی را مرور کنید - سیستم هایی را که بر کار روزانه تأثیر می گذارند فهرست کنید - خطرات اصلی را علامت گذاری کنید - اولویت های پاسخ را تنظیم کنید - مراحل بازیابی را ایجاد کنید - دسترسی کاربر را بررسی کنید - مسائل تکراری را پیگیری کنید - پیشرفت را در کسب و کار بررسی کنید بررسی باید به اقدامات عملی منجر شود. این ممکن است به معنای جایگزینی یک دستگاه قدیمی، تغییر روال پشتیبان گیری، به روز رسانی مجوزهای دسترسی یا مستندسازی فرآیندی باشد که در حال حاضر فقط در حافظه یک کارمند وجود دارد. من بهبودهای ثابتی را ترجیح می دهم که تیم بتواند آن را درک کند و حفظ کند. یک سیستم برای پشتیبانی از یک کسب و کار رو به رشد نیازی به پیچیده بودن ندارد. هنگامی که سیستم ها تحت مراقبت قرار می گیرند، تیم ها زمان کمتری را صرف انتظار، حدس زدن و تکرار همان اصلاحات می کنند. کارکنان می توانند روی مشتریان، پروژه ها و عملیات روزانه تمرکز کنند در حالی که این فناوری یک مسیر پشتیبانی روشن در پشت خود دارد.

یک ماشین متوقف می تواند بیش از یک خط تولید را تحت تأثیر قرار دهد. وقتی تجهیزات بیکار می‌مانند، اپراتورها منتظر می‌مانند، سفارش‌ها به عقب برمی‌گردند و تیم‌های تعمیر و نگهداری باید تحت فشار کار کنند. تعمیر خود ممکن است ساده باشد، اما هزینه آن با هر ساعت از دست رفتن خروجی افزایش می یابد. من این اتفاق را دیده‌ام که یک کابل سنسور فرسوده باعث توقف خط بسته‌بندی می‌شود. قسمت تعویض آن ارزان بود. تأخیر ناشی از یافتن عیب، بررسی سیم‌کشی و انتظار برای تأیید قبل از شروع تعمیر بود. یک طرح عملی از کار افتادگی می تواند این نوع اختلال را کاهش دهد. ### با رایج ترین عیوب شروع کنید که با بررسی سوابق تعمیر و نگهداری در چند ماه گذشته شروع می کنم. من به دنبال مشکلات تکراری مانند: - اتصالات شل شده - تسمه های فرسوده - موتورهای بیش از حد گرم شده - فیلترهای مسدود شده - سطح پایین مایعات - خطاهای سنسور - روغن کاری ضعیف - مشکلات منبع تغذیه این لیست نشان می دهد که یک بررسی کوچک ممکن است از توقف بزرگتر جلوگیری کند. همچنین به تیم تعمیر و نگهداری کمک می کند تا روی تجهیزاتی تمرکز کند که باعث تاخیرهای مکرر می شود. ### علل ساده را قبل از موارد پیچیده بررسی کنید وقتی ماشینی متوقف می شود، از دستور بازرسی واضح استفاده می کنم: 1. پیام هشدار یا کد خطا را بخوانید. 2. برق، سوئیچ ها و محافظ های ایمنی را بررسی کنید. 3. کابل ها، تسمه ها، شیلنگ ها و کانکتورهای قابل مشاهده را بررسی کنید. 4. به دنبال گرما، سر و صدا، لرزش یا بوهای غیر معمول باشید. 5. قرائت های فعلی را با سطوح عملیاتی معمولی مقایسه کنید. 6. عیب و اقدام انجام شده را ثبت کنید. این فرآیند حدس و گمان را کاهش می دهد. همچنین در صورت بازگشت همان مشکل به تکنسین بعدی اطلاعات مفیدی می دهد. یک چک لیست اولیه می تواند از تغییرات غیرضروری قطعات جلوگیری کند. با تعویض موتور، ترمینال شل حل نمی شود. تعویض سنسور کابل آسیب دیده را تعمیر نمی کند. ### قطعات تعویضی کوچک را آماده نگه دارید تعمیر ممکن است ساعت ها طول بکشد که قطعه ارزان قیمت در دسترس نباشد. من پیشنهاد می کنم لیست کوتاهی از قطعاتی که به طور منظم باعث خرابی می شوند ایجاد کنید. این لیست ممکن است شامل فیوزها، حسگرها، تسمه ها، کانکتورها، فیلترها، رله ها و مهر و موم های معمولی باشد. هر مورد باید دارای: - شماره قطعه مشخص - تجهیزات مناسب - محل ذخیره سازی - حداقل سطح موجودی - شخصی که مسئول بررسی آن باشد این به معنای ذخیره همه اجزای ممکن نیست. این به معنای تطبیق سطوح موجودی با استفاده قبلی و زمان عرضه کننده است. ### از بررسی های برنامه ریزی شده برای تجهیزات پرخطر استفاده کنید همه ماشین ها به برنامه تعمیر و نگهداری یکسانی نیاز ندارند. برای تجهیزاتی که چندین عملیات را تحت تأثیر قرار می دهند، نقاط خرابی شناخته شده آن را بررسی می کنم. یک موتور ممکن است به بررسی دما و ارتعاش نیاز داشته باشد. یک نوار نقاله ممکن است نیاز به تراز تسمه و بررسی کشش داشته باشد. ممکن است ماشین پرکن به تمیز کردن سنسور و بررسی کالیبراسیون نیاز داشته باشد. برنامه باید متناسب با تجهیزات و محیط کار باشد. یک منطقه گرد و غبار ممکن است نیاز به بازرسی های مکرر فیلتر و حسگر نسبت به یک اتاق تولید تمیز داشته باشد. ### یک روش گزارش دهی ساده به اپراتورها بدهید. اپراتورها اغلب قبل از وقوع یک شکست متوجه علائم اولیه می شوند. آنها ممکن است صدای جدیدی را بشنوند، یک چرخه آهسته ببینند، یا متوجه خارج شدن محصول از موقعیت خود شوند. از آنها می خواهم سه جزئیات را گزارش کنند: - چه چیزی تغییر کرده است - چه زمانی شروع به کار کرد - کدام دستگاه یا ایستگاه تحت تأثیر قرار گرفته است یک گزارش کوتاه همراه با یک عکس می تواند به کارکنان تعمیر و نگهداری کمک کند تا قبل از رسیدن به دستگاه آماده شوند. گزارش نیازی به زبان فنی ندارد. مشاهدات واضح کافی است. ### علت را ردیابی کنید، نه تنها تعمیر یک سابقه تعمیر و نگهداری باید بیشتر از اینکه "چه قطعه ای تعویض شده است؟" پاسخ دهد. ثبت می کنم: - اولین نشانه مشکل - علت تایید شده - زمان صرف شده برای تشخیص عیب - تعمیر کامل شده - قطعات استفاده شده - اقدامی که ممکن است از تکرار مشکل جلوگیری کند این یک تاریخچه مفید ایجاد می کند. اگر همان سنسور سه بار در شش ماه از کار بیفتد، پاسخ ممکن است سنسور دیگری نباشد. این مشکل می تواند شامل لرزش، رطوبت، سیم کشی یا محل نصب نادرست باشد. ### یک مثال ساده یک سایت کوچک بسته بندی مواد غذایی توقف های مکرر روی یک دستگاه آب بندی داشت. تیم چندین بار همان سنسور مجاورت را تعویض کرد. هر تعمیر برای مدتی تولید را بازیابی می‌کرد، با این حال خطا برگشت. بررسی دقیق تر نشان داد که کابل سنسور به محافظ متحرک ساییده شده است. عایق کابل فرسوده شده بود و باعث ایجاد یک سیگنال متناوب می شد. تعمیر پایدار شامل تغییر مسیر کابل، افزودن حفاظت و به روز رسانی چک لیست بازرسی بود. سنسور جایگزین راه حل اصلی نبود. پیدا کردن الگو بود. ### یک طرح پاسخ کوتاه مدت کوتاه بسازید یک طرح مفید می تواند در یک صفحه قرار گیرد. باید نشان دهد: - چه کسی ماشین را چک می کند - چه کسی قطعات یا پشتیبانی خارجی را تایید می کند - جایی که دفترچه راهنمای ماشین ذخیره می شود - کدام مراحل ایمنی اعمال می شود - چگونه خطا ثبت می شود - چه کسی به روز رسانی تعمیر را دریافت می کند. استفاده از طرح باید در طول یک شیفت شلوغ آسان باشد. سندی که هیچ کس نتواند آن را پیدا کند وقتی تولید متوقف شود کمکی نمی کند. همیشه از کار افتادگی ناشی از خرابی بزرگ تجهیزات نیست. اتصال شل، بازرسی از دست رفته یا گم شدن قطعه یدکی می تواند همین مشکل عملیاتی را ایجاد کند. من روی تکرار خطاها، بررسی های ساده، سوابق پاک و کنترل عملی سهام تمرکز می کنم. این مراحل به تیم ها کمک می کند تا با سردرگمی کمتری پاسخ دهند و در طول زمان تصمیمات تعمیر و نگهداری بهتری اتخاذ کنند. ما تجربه گسترده ای در زمینه صنعت داریم. برای مشاوره حرفه ای با ما تماس بگیرید: Ni Xiaohai: chenhai1331@163.com/WhatsApp +8613505871331.

منابع سازمان بین المللی استانداردسازی، 2018، ISO 55000 مدیریت دارایی بررسی اجمالی اصول و اصطلاحات سازمان بین المللی استانداردسازی، 2014، الزامات سیستم های مدیریت دارایی ISO 55001 وزارت انرژی ایالات متحده، 2010، راهنمای عملیات و تعمیر و نگهداری بهترین شیوه ها، انتشار 3. مک‌گلین، 2011، تصمیم‌های چرخه عمر تجهیزات بهینه‌سازی تعالی مدیریت دارایی جان موبری، 1997، مؤسسه ملی استانداردها و فناوری تعمیر و نگهداری مبتنی بر قابلیت اطمینان، 2018، چارچوبی برای بهبود امنیت سایبری زیرساخت‌های حیاتی نسخه 1.1