دانشنامه نت

تبریک سال 1394 از طرف سایت دانشنامه نگهداری و تعمیرات

1394-01

 

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

سند استراتژیک و نقشه راه سایت دانشنامه طرح‌ریزی و در حال آماده‌سازی است. این نقشه راه قابل انتشار در اینجا نیست، اما دو نکته مهم و قابل توجه در نقشه راه جهت پیاده‌سازی در سال 94 را جهت اطلاع دوستان می‌آوریم.

1- نزدیک شدن به مفهوم سازمان مجازی (Virtual Organization) برای فعالیت‌های کاری تیم سایت دانشنامه نت

2- تمرکز بر انتشار اسناد علمی و دانشی (از نوع کتاب، مقاله، گزارش، مجله، پوستر و بولتن)

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

آرزوی ما این است که در پایان سال 94 در سراسر ایران تمام فعالان صنایع ما هر یک بتوانند به «رهبران قابلیت اطمینان» (Reliability Leaders) در صنعت و کار خود تبدیل گردند.

پیشاپیش سال 1394 را تبریک و سالی پر از برکت برای شما و صنعت شما و همچنین سالی عاری از خرابی و حادثه برای تجهیزات شما آرزومندیم.

هرم تعالی نت

استراتژی، نقشه راه و مدل‌های تعالی نگهداری و تعمیرات

Raod map - mpedia.ir

در ادامه این پست در ارتباط با استراتژی نت چندین تماس مختلف داشتیم با مضمون مشترک:

«چطور تشخیص دهیم کجا هستیم و به کجا می خواهیم برسیم؟»

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

سوال دیگری که اغلب پرسیده می شود این است که در میان این همه مدل استراتژیک سازمانی (دیوید، پورتر، ماتریس های مختلف و متنوع معروف) آیا در زمینه نگهداری و تعمیرات مدلی ارائه شده است؟

بله، منتها باز هم جواب این است که شما بسته به شرکت خود باید مدل استراتژیک و نقشه راه منحصر به فرد خود را در زمینه نت طرح ریزی کنید. شاید با یک هفته وقت گذاشتن و استفاده از ظرفیت‌های فکری سازمان خودتان بتوان به یک نقشه راه اولیه رسید. در دنیا چند مدل معروف وجود دارد که برخی را در این پست می آوریم.

مدل جان کمپل که تحت عنوان «آپتایم: استراتژی برای تعالی در مدیریت نگهداری و تعمیرات» معروف است (شکل زیر)

Uptime Pyramid Rev'd-mpedia.ir

 

یا مدل وایرمن که بگونه‌ای هرمی شکل به سمت تعالی نگهداری و تعمیرات حرکت می کند. (شکل زیر)

Maintenance-Strategy-Series-mpedia.ir

المنت های آپتایم نیز توسط تیم ترنس او هنلن تهیه شده است. اگر چه نقشه راه نیست ولی شما را با اجزای اصلی نت، مدیریت دارایی‌ها و قابلیت اطمینان آشنا می‌کند. (شکل زیر)

UptimeElements-Mpedia.ir

اخیرا نیز اداره کل راهبری نظام نگهداری و تعمیرات صنعت نفت کارگروه داخلی تشکیل داده و با همکاری تیم دکتر زواشکیانی مدلی بومی برای این وزارت خانه تهیه کرده اند که چون در سایت اداره کل منتشر شده است ما نیز آن را در اینجا برای خوانندگان عزیز سایت دانشنامه نت می‌آوریم. (شکل زیر)

Iran Oil and Gaz-mpedia.ir

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

ISO 55000 مدیریت دارایی ها

نقاط قوت و ضعف استاندارد ISO 55000 در زمینه مدیریت دارایی‌ها (Asset management)

banner-ISO-55000--2014 mpedia.ir

از زمان انتشار استاندارد ISO 55000 در اوایل 2014 موجی از بحث ها و اظهارنظرها در ایران و سایر نقاط دنیا براه افتاده است. در سایت دانشنامه نت درباره این استاندارد خواهیم نوشت. در این پست می خواهیم درباره نقاط ضعف و قوت این استاندارد صحبت کنیم.

نقاط قوت کلی این استاندارد عبارتند از:

 

 1- در آن برنامه استراتژیک مدیریت دارایی‌ها به خوبی دیده شده است و سازمان را وادار می کند تا نقشه راه و افق زمانی دستیابی در زمینه مدیریت داریی‌ها داشته باشد.
2- اتصال سند استراتژیک سازمان با بخش مدیریت دارایی ها را با تاکید بر ارزش دارایی ها برقرار می سازد، چیزی که در خیلی از سازمان‌های ایرانی دیده نمی شود.
3- کنترل و پیگیری انطباق مدیریت دارایی ها با این استاندارد انجام می‌گیرد.
4- برنامه اجرایی برای نگهداری و تعمیرات و مدیریت دارایی‌ها با این ISO انجام خواهد گرفت.
5- زیر ساخت IT برای تصمیم گیری در ارتباط با مدیریت دارایی‌ها ضروری به نظر می‌رسد.
6- ارزیابی عمر دارایی ها در این استاندارد دیده شده است.

نقط ضعف کلی آن نیز به شرح زیر می باشد:

1- همانند (PAS 55) وارد جزئیات و نحوه اجرا نشده است و کاربردی نمی‌باشد.
2- مشخص نشده است که ارزیابی انطباق چگونه باید انجام گیرد.
3- بیشتر به استاندارد های دیگر ارجاع شده است مانند استاندارد ریسک ISO 31000 و خود استاندارد جامع و فراگیر نمی باشد.

این مطلب ادامه دارد.

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

تدوین استراتژی در بخش نگهداری و تعمیرات

تدوین استراتژی در بخش نگهداری و تعمیرات

business-management1

اخیراً خیلی از شرکت‌ها خواسته یا ناخواسته به سمت تدوین سند استراتژی حرکت کرده اند، خواسته از این جهت که مدیران آگاه و مشاوران خبره‌ای در سازمانشان دارند و ناخواسته از این جهت که چون از قافله شرکت های دارای استراتژی عقب نمانند، به دنبال برنامه‌ریزی استراتژیک هستند. تاکید این پست روی تدوین سند استراتژی است چرا که در مرحله اجرای استراتژی و ارزیابی و پایش آن شرکت های موفق خیلی کم هستند و کار مشکلی است. واحدهای نگهداری و تعمیرات به لحاظ جایگاه مهمی که در سازمانها و شرکت‌ها دارند در فرایند تدوین سند استراتژی درگیر خواهند بود. نکات زیر را در این مورد مد نظر داشته باشید:

1-     خیلی از شرکت‌های مشاور تدوین سند استراتژی متاسفانه کفایت لازم را نداشته و هنوز تنها از استراتژی، مدل دیوید را فهممیده اند که آن را نیز ناقص و عجولانه در سازمان پیاده می‌کنند. اگر نفوذی در سازمانتان دارید در فرایند انتخاب مشاور دخیل شده و مشاور زبده و البته با تجربه ای را انتخاب کنید.

2-     آنچه که واضح و مبرهن است، این است که مدیران ارشد باید در جلسات تدوین حضور فعال داشته باشند. در بخش نت، مدیر نگهداری و تعمیرات و روسای بخش‌ها باید حضور داشته باشند. اگر مدیر و روسای نت در جلسه به هر دلیل موجه و غیر موجهی حضور نداشتند، حتماً جلسه را لغو کنید.

3-     داشتن استراتژی و اجرای آن، واحدهای نگهداری و تعمیرات را دستخوش تلاتم و تکاپو خواهد کرد. روح مدیریت استراتژی همین است، همیشه باید چالش ایجاد کند، اهداف را مشخص و مجموعه را متناسب با شاخص هایی بسنجد. مجموعه‌های نت نیز باید تمام تلاش و فعالیت‌ها را در راستای همین اهداف استراتژیک و سیاست‌های خروجی سند استرتژیک تنظیم کنند. قاعدتاً این مساله تغییر و تحول بزرگی را در زیر مجموعه های نت ایجاد می‌کند چراکه قرار است پایش شوند و این به مذاق آنها خوش نیست.

4-     در تعیین اهداف و شاخص‌ها، تفکیکی بین شاخص‌های تجهیزی و سیستمی و استراتژیک قایل شوید. دقت کنید MTBF شاخص تجهیز است و برای تیم تحلیل خرابی می تواند مفید باشد، برای سنجش استراتژی‌ها و اهداف نت نیست.

5-     در این کار خیلی از روسا مثال‌هایی از اجرای ناموفق برنامه‌ریزی استراتژیک در جاهای دیگر می‌زنند و کل داستان را زیر سوال می‌برند و برخی نیز مصرانه می گویند ما نیاز به سند نداریم!! آنچه مسلم است این است که داشتن بیانیه ماموریت، جشم انداز و برنامه استراتژیک از الزامات سازمان شماست. شما باید بدانید درچه وضعیتی هستید، به کجا می‌خواهید برسید و حرکت خود را نیز باید کنترل کنید. منتها در اجرای استراتژی عارضه‌هایی وجود دارد که باید از آنها اجتناب کنید. مهمترین عارضه، درگیر نکردن مدیران و روسا در بخش تدوین سند است.

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

برونسپاری و پیمانکاری نت

کاربردهای برونسپاری و پیمانکاری در نگهداری و تعمیرات

images

 

با گذاشتن پست تفاوت برونسپاری و پیمانکاری برخی از دوستان تماس گرفته و خواستار مثال و توضیح بیشتر در این باره شدند.

جدا از تعریف این دو واژه در نهایت در هر کدام چه برونسپاری و چه پیمانکاری، طرف دومی وجود دارد و طی یک قرارداد کار را برای شما انجام می دهد، در هر سه مرحله برنامه ریزی، اجرا و کنترل برونسپاری مهم عارضه یابی این مراحل و درست گام برداشتن است که در این زمینه بیشتر مطلب خواهیم گذاشت.

در شکل زیر سعی شده است برخی کاربرد‌های برونسپاری و پیمانکاری در نگهداری و تعمیرات آورده شود، موارد 1 و 2 بیشتر به پیمانکاری نزدیک تر است و موارد 3، 4 و مخصوصاً 5 به برونسپاری نزدیک تر است.

mpedia.ir

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

برونسپاری نت

تفاوت پیمانکاری نت و برونسپاری نت؟

images

در ترمینولوژی واگذاری فعالیت‌های سازمان به بیرون دو واژه پرکاربرد وجود دارد، یکی برونسپاری و دیگری پیمانکاری.

مرسوم است که ایندو را معادل یکدیگر در نظر میگیرند در حالیکه با یکدیگر تفاوت دارند. در برونسپاری تجدید ساختار یک سری فعالیت های ویژه با استفاده از منابع بیرون از سازمان که توانمندی های ویژه ای را دارا می‌باشند صورت می پذیرد. در حالیکه در پیمانکاری قسمتی از فعالیت های سازمان با کمک پیمانکار انجام می‌شود و تجدید ساختار صورت نمیگیرد.

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

به صورت کلی برای درک تفاوت به کلیدواژه تجدید ساختار دقت کنید، تفاوت در همین کلیدواژه نهفته است.

پست های بیشتری را درباره این موضوع در آینده خواهیم گذاشت.

پست کاربردهای برونسپاری و پیمانکاری در نت بیشتر در درک این دو واژه کمک خواهد کرد.

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

نرم افزار نگهداری و تعمیرات

تاکتیک‌های فروش نرم افزار نگهداری و تعمیرات CMMS /EAM (بخش 1)

images

 

در مدتی که با شرکت های دارنده نرم افزار CMMS،EAM و ERP در ایران به نوعی ارتباط و همکاری داشته ایم و در برخی موارد برای انتخاب و ممیزی یک نرم افزار یک روز کامل درگیر بوده ایم، نقاط ضعف و قوتی در استراتژی‌های بازاریابی آنها مشاهده می‌شد.

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

صاحبان و ذینفعان نرم افزار مخاطب اصلی من هستند، لطفاً به این نکات توجه دقیقی داشته باشید:

1-      اطلاعات نتی خود را بالا ببرید. حرف از شاخص‌های نت زده شد سریع نگوئید بله می دانم MTBF !!. از سیستم های متعالی نت اطلاعات کافی داشته باشید.

2-      با زبان علمی وحتی آکادمیک صحبت کنید نه زبان کوچه بازاری. از واژه هایی که سرشار از احترام هستند استفاده کنید. در سال گذشته در جلسه ای با یکی از کارشناسان نت پس از نیم ساعت صحبت کردن ایشان، تقریباً همه حاضرین در جلسه از لحن و کلماتی که ایشان استفاده می‌کردند، واپس زده شده بودند. جالب اینکه ایشان برای ارائه نرم افزار نت بسیار خوبی تشریف آورده بودند.

3-      سعی کنید شناخت نسبی از صنعتی که وارد آن می شوید، داشته باشید. متناسب با نیاز آن صنعت روی بخشی از نرم افزار تمرکز بیشتری داشته باشید و از سوابق فروش نرم افزار در آن صنعت هم بگوئید. با جستجوی کوتاهی در سایت های اینترنتی از پیاده‌سازی نرم افزار در همان صنعت در کشور های خارجی اطلاعات کسب کنید و آن را در اختیار مدیران و کارشناسان قرار دهید.

4-      در جلسات مذاکره و ممیزی نرم افزار افراد ایرادهای صریحی خواهند گرفت، شما به هیچ عنوان، به هیچ عنوان نباید برافروخته و عصبانی شده و با لحن تند جواب آنها را بدهید. مشاهده شده در جلسه ای یکی از مدیران به خاطر ضعف اطلاعاتی ایراداتی را به نرم‌افزار وارد می کند، شما باید با لحن آرام و البته علمی جواب آنها را بدهید. در واقع موثر سخن بگوئید، نه عصبانی، نه حتی زیبا بلکه موثر!.

ادامه این موارد (حداقل 8 مورد دیگر) را در پستی جداگانه خواهیم گذاشت.

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

برونسپاری در نگهداری و تعمیرات

اولین قدم در برونسپاری نگهداری و تعمیرات (Maintenance Outsourcing)

مشاور نرم افزار نگهداری و تعمیرات CMMS

آیا در زمینه نصب و استقرار نرم افزار CMMS نیاز به مشاور است؟

CMMS_Consultants_1

 

گرداوری: احسان سلیمی

ویرایش: سید مجتبی حسنیان

برگرفته از مقاله ای مشترک و ارائه شده در کنفرانس فناوری اطلاعات و مدیریت دانش

سوال: آیا در زمینه نصب و استقرار نرم افزار CMMS نیاز به مشاور است؟

جواب: تعداد زیادی از فروشندگان نرم افزار و مشاورین وجود دارند که در زمینه نصب و استقرار نرم افزار CMMS یا EAM فعالیت دارند. دو نوع مشاوره در زمینه استقرار نرم افزار وجود دارد، گروه اول مشاورینی هستند که به جنبه کاری سیستم متمرکز می شوند (بهبود سیستم موجود، نظارت جامع در استقرار نرم افزار، جمع آوری داده ها، ورود داده ها، ممیزی استقرار)، در حالی که گروه دوم بر جنبه های تکنولوژی و IT تمرکز دارند و سازمان می تواند با توجه به بلوغ سازمانی خود مشاور خود را انتخاب نماید.

برای تصمیم گیری در خصوص اینکه آیا یک شرکت به خدمات مشاوره ای برای استقرار نرم افزار نیاز دارد یا خیر سوال های زیر باید در کارگروه استقرار بررسی شود:

1-     آیا کارکنان سازمان قادر هستند به تنهایی رویه جاری خود را تغییر دهند، به گونه ای که فرایندهای قدیمی را بهبود داده و کارامدی سیستم را افزایش دهند؟

2-     آیا در میان پرسنل سازمان، کارمندانی که تجربه استقرار یک نرم افزار مدیریت دارایی ها داشته باشند، وجود دارد؟

3-     آیا کارکنان نت و IT سازمان، زمان برای افزودن این پروژه به برنامه کاری خود را دارند؟

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

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

جایگاه RCA در تحلیل سوانح در مدیریت ایمنی

fukushima-daiichi-nuclear-plant-explosion

 

استفاده از متد های تحلیل علل ریشه ای خرابی ها ابتدا در واحدهای ایمنی مورد استفاده قرار گرفته و پس از محرز شدن اثربخشی این روش ها، جای خود را در مدیریت نگهداری و تعمیرات باز کرده است. آنچه که اکنون در ایران باب شده است استفاده از RCFA می باشد، در حالیکه می توان از این روش ها در خواستگاه اصلی آنها، یعنی مدیریت ایمنی نیز استفاده کرد.

وضعیت کنونی بررسی سانحه در ایران بدین صورت است که پس از وقوع سانحه، کمیسیون سانحه تشکیل شده و با برگزاری تعداد محدودی جلسه که بیشتر شبیه دادگاه می‌باشد، به دنبال مقصر اصلی سانحه میگردند. یافتن مقصر اصلی عمدتاً با مصاحبه هایی با افراد درگیر در سانحه و شاهدین ماجرا طبق صورت جلساتی انجام میگیرد. افرادی که در نوک پیکان سانحه بوده اند به نسبت خاصی مقصر شناخته میشوند و جریمه ای متناسب با درصد قصور افراد تعیین میگردد. در پروسه مذکور دو مشکل اساسی وجود دارد:

1)  یافتن علت اصلی سانحه طبق متد مشخص و استانداردی صورت نمیگیرد. در حالیکه هنگام استفاده از متدهای RCA به صورت سیستماتیک سانحه مورد کنکاش قرار میگیرد و با تمرکز بر بخشهای مختلف سانحه تمام جوانب سانحه مورد آنالیز قرار گرفته و از تاثیر گذاشتن سلایق شخصی افراد، عواطف و احساسات در ریشه یابی علل سانحه جلوگیری میکند.

2)  هنگامی که از متد خاصی برای آنالیز علت ریشه ای سانحه استفاده نمیشود، ظاهری ترین دلایل و خارجی ترین عوامل به عنوان عامل اصلی سانحه شناخته میشود. عمدتا کاربران و پرسنل درگیر در سانحه مورد بازخواست قرار گرفته و آنها را به عنوان مقصر شناسایی میکنند، و هیچوقت به لایه های پنهان که عمدتا دلایل ریشه ای سانحه نیز در همین لایه های پنهان میباشد وارد نمیگردند.

تکنیک ها و متدهای آنالیز دلیل ریشه ای خرابی و استفاده از این متدها در آنالیز دلیل ریشه ای باعث میشود به دو مشکل عمده فوق برخورد نکرده و دلیل ریشه ای سوانح شناسایی و با تعریف اقدام اصلاحی سعی بر برطرف کردن آن شود.

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

 

تقابل واحد نت و عملیات

تقابل واحد عملیات (تولید یا بهره برداری) با واحد نت (نگهداری و تعمیرات)

mpedia operaion and maintenance

 

سوال: اگر عملیات (واحد تولید یا بهره برداری) ساعات کار خود را از 5 یا 6 روز در هفته به 7 روز کامل در هفته بخواهد تغییر دهد(بنا به مقتضیات شرایط) تکلیف واحد نت و انجام PMها چیست؟

جواب: باز هم سعی می شود جواب تیتر وار داده شود تا انسجام داشته باشد.

1-      سرگروه تیم عملیات (یامدیر عملیات) را نسبت به عواقب عدم انجام PMها در زمان مقرر مطلع کنید.

مدیر بالاتر نیز باید آگاهی داشته باشد که آماده به کاری (Availability) تجهیزات را اگر بخواهید افزایش دهیدباید در تولید توقفاتی داشته باشید. 7 روز فشرده کار کردن نهایتاً باعث افزایش توقفات و کاهش تولید می شود.

2-      سعی کنید برنامه PM را بهینه سازی نمائید (با استفاده از روشهای PM Optimization). بررسی کنید کجاها کارهای PM اضافی انجام می دهید، بازه های تناوب برخی فعالیت های PM را می توانید بزرگتر کنید. زمانهای اضافی و اتلاف های زمانی را در برنامه شناسایی کرده و آنها را حذف کنید. (استفاده از نت ناب)

3-      سیاست نت  را در بخش هایی از تجهیزات به سمت نت پیشگویانه (PdM) ، نت مبتنی بر پایش وضعیت (CBM) تغییر دهید.

4-      جلسات مشترک با عملیات بگیرید تا مشخص کنید چه زمانهایی باید توقفات برنامه ای داشته باشید. توجه کنید در توقفات برنامه ای صرفا ًکار PM انجام نمی شود، واحد عملیات به این توقفات نیاز دارد تا با تمرکز به تمیزکاری محیط کار بپردازد، خطوط تولید کثیف تقریباً 30% توقفات تولید را افزایش می دهد. آنها حداقل باید در برنامه 24/7 (7روز کاری 24 ساعته) زمانهای توقف برنامه ای را اعلام کنند تا تیم نت فعالیت خود را انجام دهد.

5-      برنامه ریزی نت را دوباره بررسی کنید و بین فعالیت های Critical و حیاتی و بقیه فعالیت ها تمایز قائل شوید. می توانید در گروه‌بندی، فعالیت های A، B و C داشته باشید و در شرایط اضطرار گروه C را به تعویق بیاندازید.

6-      تیم های نت را با جلسات توجیهی آماده کنید. به آنها توضیح دهید بنا به شرایط باید بهره وری خود را افزایش دهند تا برنامه ریزی نیز بتواند اثربخش کار کند.

7-      برنامه ریزی MRO مدیریت قطعات یدکی باید تغییر یابد، چه به لحاظ مکانی، فرایندی، میزان موجودی و زمانبندی.

8-      در زمانی که توقف برنامه ای در تولید کاهش پیدا می کند، بهترین تجویز اجرای درست TPM می باشد. اپراتورهای دستگاه می‌توانند فعالیت های ساده نت را و در برخی مواقع فعالیت های PdM را انجام دهند.

9-      حضور برخی از تکنسین های نت می تواند در خط تولید و در خط بهره برداری در زمان تولید کمک کند. آنها می توانند PMهایی که نیاز به توقف ندارند را انجام داده، پایش وضعیت را کنترل کرده و حالت های خرابی را به خوبی شناسایی کنند در زمانی که اپراتورها توانایی انجام این فعالیت را ندارند.

امیدوارم این موارد به شما در برنامه ریزی کارها کمک کند. از خوانندگان سایت تقاضا دارم این لیست را کامل کرده و توصیه های خود را در بخش کامنت ها و نظرات بنویسند.

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

چرا خیلی از شرکت ها نمی توانند بیش از 30 درصد ظرفیت CMMS استفاده کنند؟ (بخش دوم)

CMMS

 

در بخش اول برخی از دلایل را ذکر کردیم، ادامه مطلب را مطالعه فرمائید.

8-    خیلی از سازمانهایی که در پیاده‌سازی نرم افزار نگهداری و تعمیرات (CMMS) ناتوان هستند، سیستم نگهداری و تعمیرات کاغذی نیز یا نداشته و یا خیلی ضعیف است.

به عنوان مثال وقتی گزارشات و شاخص های KPI در سازمان به خوبی طرح ریزی نشده باشد، چه انتظاری از CMMS در ارائه این شاخص ها و گزارشات دارید. وقتی فرآیند صدور دستورکار به غلط در سازمان طرح ریزی گشته است باعث عدم پیاده سازی درست گردش دستورکار در CMMS خواهیم بود. در برخی از سازمان ها حتی فرم ها و چک لیست های به شدت ضعیفی در حال اجرا می باشد و بسیار عجله برای خرید نرم افزار نیز دارند!!

9-    ضعف در برنامه ریزی پیاده سازی و استفاده از نرم افزار یکی دیگر از دلایل عدم استفاده کامل از ظرفیت های CMMS است. باید بدانید با نرم افزار به کجا می خواهید برسید و نرم افزار برای رسیدن به این اهداف چگونه می تواند به شما کمک کند. حتی در نقشه راه نرم افزار شما جایگاه RCA و RCM را هم باید مشخص کنید و حداقل تا 5 سال آینده برنامه داشته باشید.

10-    متولی پیاده سازی CMMS در سازمان شما نباید بخش IT و یا مدیریت مالی سازمان شما باشد. متولی واحد نگهداری و تعمیرات و یا دقیق تر واحد برنامه ریزی و مهندسی نگهداری و تعمیرات است.

11-    سیاست سازمان باید قبل از خرید نرم افزار شفاف و روشن باشد. اینکه آیا بخش های خرید، مدیریت انبار و مدیریت مالی نیز در این نرم افزار می خواهد انجام گیرد و یا اینکه نرم افزار های مجزای خود را دارد و یا اینکه در پکیج ERP این ماژول ها دیده شده است، باید مشخص گردد.

مسیر پیاده سازی صفر تا صد نرم افزار باید شفاف و روشن باشد. در استاندارد ISO 55000 هم تاکید بسیار زیادی روی موضوع شفاف بودن استراتژی نت، اهداف عینی و اجرایی و سیاست های نت و مدریت دارایی‌ها شده است.

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

انگیزه در کارکنان نگهداری و تعمیرات

مدیریت کارکنان و نحوه ارتباط با آنها از A تا Z

Work-Motivation-in-Running-Business

 

 

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

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

نرم افزار نگهداری و تعمیرات CMMS

چرا خیلی از شرکت ها نمی توانند بیش از 30 درصد ظرفیت CMMS استفاده کنند؟ (بخش اول)

images

 

چرا خیلی از شرکت ها نمی توانند بیش از 30 درصد ظرفیت نرم افزار های نگهداری و تعمیرات (CMMS) استفاده کنند؟

پاسخ:

پاسخ این سوال را سعی میکنم تیتر وار بیان کنم تا پاسخ شفاف و روشنی داشته باشیم.

1-    قبل از هر چیز این نکته را نباید فراموش کرد که همیشه لازم نیست سازمان شما از 100 درصد قابلیت های نرم افزار CMMS یا EAM استفاده کند، به نسبت بلوغی که در سازمان وجود دارد، بخش های مختلف نرم افزار با زمانبندی مناسب باید پیاده سازی گردد.

2-    مهمترین دلیل در استقاده حداقلی از ظرفیت CMMS، ضعف در پیاده سازی آن در سازمان است. تیمی قوی و آموزش دیده نرم افزار را پیاده نکرده و کاستی های زیادی را به همراه داشته است.

3-    آموزش ضعیف است. کاربران نمی دانند بخش های مختلف نرم افزار چه استفاده ای دارد و نمی دانند چگونه باید از آن استفاده کنند.

4-    در برخی سازمان ها زمان شیفت و تعداد افراد حاضر در شیفت جوابگوی پرکردن و کار کردن با تمامی بخش های CMMS نیست، البته این هم ناشی از سوء مدیریت و عدم نیازسنجی درست است.

5-    خیلی از نرم افزارهای موجود به قدری پیچیده هستند که عملاً کارکردن با آن مشکل و دردسر ساز هستند. پنجره های زیاد و کلیک های بسیار.

به اصطلاح یوزر فرندلی نیستند. اگر کاربران با نرم افزار به خوبی ارتباط برقرار کنند، فرم ها به درستی و با اطلاعات دقیق پر خواهند کرد.

 

6-    دلیل دیگری که خیلی مشاهده می گردد عدم ارتباط درست بین کسانی که تیم پشتیبانی و برنامه ریز CMMS هستند و آنهایی که تیم اجرایی و کاربران نهایی هستند. تیم پیاده سازی و پشتیبانی با کابران کف کارگاه باید ارتباط نزدیک و صمیمی داشته باشند.

7-    مسئول پیاده سازی فردی ضعیف است. در تیم سازی های نت شخصی به عنوان Champion می شناسند. او مسئوول تغییر فرهنگ سازمانی و انتقال دانش به کاربران است. هر چقدر شخص قدرتمند و آموزش دیده باشد، پیاده سازی CMMS موفق تر خواهد بود.

ادامه این مطلب را در این پست مشاهده فرمائید.

شما می توانید با ذکر نام منبع (سایت دانشنامه نت) و لینک سایت (www.mpedia.ir) این مطلب را باز نشر دهید.

ایجاد انگیزه در کارکنان بخش نگهداری و تعمیرات (بخش دوم):

ایجاد انگیزه در کارکنان بخش نگهداری و تعمیرات (بخش اول):

یک سوال در ارتباط با تفاوت CMMS و EAM

نت دقیق

از نت دقیق یا Precision Maintenance تا مرگ و میر نوزادان

نرم افزار نگهداری و تعمیرات CMMS

سیستم مکانیزه مدیریت نگهداری و تعمیرات (CMMS)

دوره های نت

دوره های تخصصی نگهداری و تعمیرات