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