وقتی مشتری قطعه‌ای را برمی‌گرداند، اولین سؤال معمولاً این است: «چه مشکلی دارد و چگونه جایگزینش کنیم؟» اما برای مسئول کیفیت و خریدار صنعتی، پاسخ به همین سؤال کافی نیست. باید روشن شود کدام الزام رعایت نشده، چه موجودی دیگری ممکن است درگیر باشد و چه اقدامی جلوی تکرار مشکل را می‌گیرد. روش 8D چارچوبی برای بررسی منظم مسئله و رسیدن به اقدام اصلاحی مبتنی بر علت است. راهنمای هشت گام حل مسئله ASQ این مسیر را از تشکیل تیم تا پیشگیری از تکرار و جمع‌بندی تلاش تیم توضیح می‌دهد. (asq.org)
در این مقاله، نحوه تنظیم گزارش 8D قطعات خودرو را برای رسیدگی به قطعه برگشتی مرور می‌کنیم. مثال اصلی، مسئله‌ای است که پس از تغییر در تولید یک قطعه قبلاً تأییدشده مشاهده شده است؛ نه معرفی مدارک تأیید اولیه قطعه، آموزش ردیابی مواد یا شرح کامل مدیریت تغییر. مثال‌ها فرضی و آموزشی‌اند و هیچ‌کدام بیانگر پرونده مشتری یا توانمندی اثبات‌شده هاناپارت نیستند. چک‌لیست‌ها و نمونه جمله‌های اجرایی نیز پیشنهادهای نگارشی این مقاله‌اند و باید با شواهد واقعی و الزامات همان مشتری تطبیق داده شوند.
گزارش 8D قرار است چه چیزی را روشن کند؟
8D فقط یک فرم برای پاسخ به شکایت نیست. برای نمونه، ZF در معرفی سامانه رسیدگی الکترونیکی به شکایت تأمین‌کنندگان، استفاده از این روش را برای تحلیل مشترک مسئله و یافتن راه‌حل جلوگیری از تکرار توضیح می‌دهد. این نمونه، کاربرد گزارش در ارتباط رسمی مشتری و تأمین‌کننده را نشان می‌دهد؛ اما مسیر ارسال و دسترسی به سامانه، مخصوص همان رابطه تأمین است. (zf.com)
برای تنظیم یک گزارش خوانا، پیشنهاد می‌کنیم در هر بازنگری به این پرسش‌ها پاسخ دهید: چه چیزی را با مدرک می‌دانیم؟ چه چیزی هنوز نامعلوم است؟ تا پایان بررسی چه اقدامی برای کنترل وضعیت انجام داده‌ایم؟ علت اعلام‌شده بر چه شواهدی تکیه دارد؟ و گام بعدی بر عهده کدام نقش سازمانی است؟ خواننده نباید برای یافتن پاسخ، میان چند ایمیل و فایل پراکنده جست‌وجو کند.
در ابتدای پرونده، شناسه شکایت، شناسه قطعه، ویرایش مرجع، تاریخ دریافت و وضعیت گزارش را بیاورید. برای پیوست‌ها نیز عنوان و تاریخ مشخص بگذارید. به‌جای «طبق فایل ارسالی»، بنویسید کدام فایل و کدام نتیجه، پشتوانه تصمیم بوده است. در نسخه قابل‌اشتراک، اطلاعات محرمانه یا داده‌های شخصی غیرضروری را وارد نکنید؛ برای مشخص‌کردن مسئولیت‌ها می‌توان از نقش سازمانی و شناسه اقدام استفاده کرد.
پیش از شروع، خواسته مشتری را مشخص کنید
پیشنهاد اجرایی ما این است که پیش از تکمیل گزارش، یک فهرست کوتاه از خواسته‌های همان مشتری تهیه کنید. قالب پاسخ، مهلت هر مرحله، مسیر ارسال، اختیار آزادسازی موجودی و شیوه تأیید نهایی را از قرارداد، درخواست شکایت یا دستور معتبر استخراج کنید. اگر پاسخ یک مورد روشن نیست، آن را به‌عنوان پرسش باز نگه دارید؛ نه اینکه با حدس، یک الزام تازه بسازید.
- پاسخ اولیه باید شامل چه اطلاعاتی باشد؟
- گزارش در کدام سامانه یا مسیر ارتباطی ارسال شود؟
- برای تعیین تکلیف قطعات مشکوک، چه تأییدی لازم است؟
- اگر آزمون زمان‌بر باشد، تمدید مهلت چگونه درخواست شود؟
- چه مدرکی برای پذیرش اقدام اصلاحی و بستن پرونده خواسته شده است؟
اگر اقدام اصلاحی به تغییر محصول یا فرایند منجر می‌شود، وضعیت مجوز تغییر را جدا بررسی کنید. برای نمونه، راهنمای درخواست تغییر تأمین‌کننده بوش، نسخه V4 در دامنه اعلام‌شده خود، اطلاع‌رسانی و دریافت تأیید کتبی پیش از اجرای تغییر را مقرر می‌کند. بنابراین در چنین رابطه‌ای، تکمیل گزارش 8D جای مجوز تغییر را نمی‌گیرد. این شرط را نباید بدون بررسی قرارداد به همه مشتریان تعمیم داد. (assets.bosch.com)
D1 و D2؛ تیم را مشخص کنید و مسئله را دقیق بنویسید
D1: چه کسانی باید در بررسی حضور داشته باشند؟
در ساختار معرفی‌شده توسط ASQ، D1 تشکیل تیم دارای شناخت محصول و فرایند و D2 تعریف مشخص و قابل‌اندازه‌گیری مسئله است. انتخاب اعضا و نوشتن شرح مسئله، دو کار متفاوت اما مرتبط‌اند. (asq.org)
برای تقسیم کار، می‌توانید کیفیت را مسئول یکپارچگی گزارش، تولید را مسئول ارائه سوابق اجرای عملیات، مهندسی را مسئول بررسی مرجع فنی و خرید را مسئول هماهنگی با تأمین‌کننده قرار دهید. انبار و لجستیک نیز در موضوع موجودی و ارسال مشارکت کنند. این ترکیب، نسخه ثابت برای همه پرونده‌ها نیست؛ نقش‌ها را با توجه به موضوع انتخاب کنید.
در فهرست اقدامات، عبارت‌هایی مانند «پیگیری توسط تولید» را به نقش مسئول، موعد و خروجی مورد انتظار تبدیل کنید. مثلاً بنویسید: «مسئول اجرای عملیات، سوابق استفاده از فیکسچر را تا موعد توافق‌شده ارائه کند.» اگر برای انجام کار، مدرک یا اجازه‌ای لازم است، همان‌جا ثبت کنید. هدف این الگوی پیشنهادی آن است که جلسه بعدی صرف مرور خروجی‌ها شود، نه تکرار بحث درباره اینکه چه کسی باید کار را انجام می‌داد.
D2: آنچه دیده‌اید را از آنچه حدس می‌زنید جدا کنید
در شرح اولیه، دو بخش داشته باشید: «مشاهده و داده موجود» و «فرضیه‌های نیازمند بررسی». اگر مشتری دشواری مونتاژ را گزارش کرده، همان را با انتساب روشن به گزارش مشتری ثبت کنید. پیش از بررسی، آن را به اشتباه ماشین‌کاری یا نصب نادرست تبدیل نکنید. برای جمع‌آوری اطلاعات، فهرست زیر را به‌عنوان الگوی نگارش به کار ببرید:
- نام و شناسه قطعه و ویژگی مورد شکایت.
- الزام قابل‌اعمال، همراه با شماره ویرایش مرجع.
- محل کشف مشکل؛ مانند بازرسی ورودی یا مونتاژ مشتری.
- تعداد واقعی قطعات بررسی‌شده و موارد مشاهده‌شده.
- زمان نخستین مشاهده و سوابق مشاهده‌های بعدی.
- وضعیت نمونه برگشتی و مدارک همراه آن.
- اطلاعاتی که هنوز برای تکمیل شرح مسئله لازم است.
مثال آموزشی: فرض کنید قطعه‌ای قبلاً تأیید شده و پس از تغییر تأییدشده فیکسچر، مشتری از دشواری مونتاژ شکایت کرده است. برای پاسخ اولیه می‌توان نوشت: «دشواری مونتاژ از سوی مشتری گزارش شده است. نمونه برگشتی و ویژگی مرتبط در حال بررسی‌اند و ارتباط مشکل با تغییر فیکسچر هنوز تأیید نشده است.» اگر بعداً مغایرت ابعادی با مدرک مشخص شد، شرح مسئله را با همان نتیجه و مرجع پذیرش به‌روزرسانی کنید.
برای تحویل‌گیری نمونه نیز پیشنهاد می‌کنیم وضعیت دریافت، تصاویر مرتبط و ترتیب بررسی‌ها ثبت شود. پیش از هر فعالیتی که وضعیت نمونه را تغییر می‌دهد، هدف آن را در پرونده مشخص کنید. در نگارش نتایج، توضیح دهید بررسی مربوط به نمونه در وضعیت دریافت بوده یا پس از یک اقدام مشخص انجام شده است. به این ترتیب، خواننده می‌تواند ترتیب رویدادهای ثبت‌شده را دنبال کند.
D3؛ ابتدا دامنه مشکل را کنترل کنید
مهار، اقدام موقت برای محافظت از مشتری در برابر محصول نامنطبق است؛ نه حذف علت ریشه‌ای. راهنمای حل مسئله بوش، دفترچه شماره ۱۶ در این مرحله، موجودی در مسیر حمل، انبارهای میانی و محل مشتری را نیز در دامنه بررسی مطرح می‌کند. (assets.bosch.com)
برای اداره این مرحله، یک فهرست وضعیت موجودی بسازید. محل نگهداری، مقدار واقعی، وضعیت بررسی، نقش مسئول و مرجع تصمیم را در آن بیاورید. وضعیت‌ها را روشن بنویسید: مشکوک، در حال بررسی، پذیرفته‌شده طبق معیار مشخص، ردشده یا منتظر تعیین تکلیف. در این الگوی پیشنهادی، کنار هر وضعیت باید معلوم باشد تصمیم بر چه مبنایی گرفته شده است.
در مثال فیکسچر، موجودی پیش و پس از تغییر را در پرونده جدا کنید؛ اما گروه «پیش از تغییر» را بدون مدرک، سالم اعلام نکنید. توضیح دهید مرز بررسی بر چه اطلاعاتی استوار است. اگر زمان ثبت تغییر با زمان اجرای واقعی آن تفاوت دارد، این اختلاف را به‌عنوان موضوع باز نگه دارید و برای روشن‌کردن آن اقدام تعیین کنید. عنوان یک گروه موجودی، جای نتیجه بررسی آن گروه را نمی‌گیرد.
برای هر اقدام مهار، چهار پاسخ کوتاه بنویسید: چه موجودی‌ای تحت کنترل قرار گرفته؟ با چه روشی بررسی می‌شود؟ نتیجه واقعی چیست؟ و چه تأییدی برای تعیین تکلیف لازم است؟ اگر بازرسی اضافی انتخاب شده، معیار آن را به نقشه یا دستور معتبر همان پرونده ارجاع دهید. این مقاله مقدار عمومی برای نمونه‌گیری یا حد پذیرش پیشنهاد نمی‌کند.
برای مطالعه جداگانه درباره داده‌های اندازه‌گیری، مقاله نقش MSA و GR&R در کنترل کیفیت قطعات خودرو در دسترس است. در الگوی پیشنهادی گزارش شکایت، نام روش بررسی، مرجع پذیرش و شناسه مدرک نتیجه را کنار هم قرار دهید تا خواننده برای یافتن مبنای تصمیم، ناچار به حدس‌زدن نباشد.
D4؛ چرا عیب ایجاد شد و چرا دیده نشد؟
تحلیل علت در 8D باید هم علت ایجاد مسئله و هم دلیل کشف‌نشدن آن را بررسی کند. طبق راهنمای ASQ، علت‌ها باید تأیید یا اثبات شوند؛ طرح یک احتمال در جلسه یا ترسیم نمودار علت‌ومعلول به‌تنهایی اثبات علت نیست. (asq.org)
برای جلوگیری از اعلام زودهنگام نتیجه، پیشنهاد می‌کنیم برای هر فرضیه یک ردیف جدا تهیه کنید. در آن، فرضیه، شاهد پشتیبان، شاهد مخالف، روش بررسی و نتیجه نهایی را بنویسید. وضعیت هر ردیف می‌تواند باز، ردشده یا تأییدشده در دامنه بررسی باشد. اگر مدرک لازم در دسترس نیست، محدودیت را صریح ثبت کنید و نقش مسئول تهیه آن را مشخص کنید.
ادامه مثال فیکسچر
در مثال آموزشی، تیم می‌تواند اجرای تغییر، تنظیم عملیات، روش بازرسی و وضعیت نمونه برگشتی را جدا بررسی کند. برای هر فرضیه بپرسید: «اگر این توضیح درست باشد، انتظار داریم در کدام مدرک یا نتیجه چه تفاوتی ببینیم؟» سپس نتیجه واقعی را کنار همان انتظار بنویسید. تا زمانی که شواهد کافی ندارید، جمله «علت، فیکسچر جدید بود» را نتیجه نهایی گزارش قرار ندهید.
فرض کنیم در ادامه همین سناریوی فرضی، شواهد نشان داده‌اند نسخه فیکسچر استفاده‌شده با نسخه تأییدشده تفاوت داشته و ارتباط آن با مغایرت نیز در بررسی مناسب تأیید شده است. در این صورت، موضوع بعدی بررسی مسیر استفاده از نسخه نادرست است. تیم می‌تواند نحوه ابلاغ نسخه، دسترسی به مدارک و تأیید اجرای تغییر را بررسی کند. این موارد تا پیش از دریافت شواهد، فقط مسیر تحقیق‌اند؛ نه علت‌های قطعی.
برای بخش کشف‌نشدن مشکل نیز یک پرسش مستقل بنویسید: «کنترل پیش‌بینی‌شده برای همین ویژگی چه بوده و چه مدرکی از اجرای آن داریم؟» سپس تفاوت میان نبودن مدرک، اجرا‌نشدن کنترل و نتیجه نامناسب کنترل را در متن حفظ کنید. این تفکیک، پیشنهاد نگارشی ماست؛ نتیجه فنی هر مورد فقط پس از بررسی شواهد همان پرونده نوشته شود.
مثال دوم: تغییر تأمین‌کننده یک عملیات
فرض کنید پس از تغییر تأییدشده تأمین‌کننده یک عملیات، مشتری مغایرت یک ویژگی را گزارش کرده است. در الگوی پیشنهادی این مقاله، جدیدبودن تأمین‌کننده را نتیجه تحلیل قرار ندهید. ابتدا سفارش ابلاغ‌شده، نسخه الزام، مدارک تحویل و نتایج بررسی نمونه را کنار هم بگذارید. اگر اختلافی وجود دارد، مشخص کنید به تعریف خواسته، اجرای عملیات، روش آزمون یا تصمیم پذیرش مربوط است.
برای نگارش نتیجه، می‌توانید از این ساختار استفاده کنید: «فرضیه مطرح‌شده با بررسی مدرک مشخص ارزیابی شد؛ نتیجه به‌دست‌آمده آن را در دامنه بررسی تأیید یا رد می‌کند.» نام مدرک و نتیجه را جای عبارت‌های کلی بگذارید. اگر فقط بخشی از فرضیه بررسی شده، همان بخش را نتیجه‌گیری کنید و موارد باقی‌مانده را باز نگه دارید.
D5 و D6؛ اقدام را انتخاب کنید و نتیجه را بسنجید
انتخاب و بررسی اقدام اصلاحی با اجرای آن و ارزیابی نتیجه در عمل، دو مرحله متمایزند. راهنمای 8D تأمین‌کنندگان Vestas در بخش انتخاب اقدام، بررسی ارتباط آن با علت و نقطه عبور عیب و توجه به پیامد منفی جدید را مطرح می‌کند. این سند، راهنمای همان شرکت است و الزام عمومی صنعت خودرو محسوب نمی‌شود. (vestas.com)
D5: اقدام مبهم ننویسید
برای نوشتن اقدام، این پرسش‌ها را پاسخ دهید: چه چیزی تغییر می‌کند؟ در کدام نقطه؟ نقش مسئول اجرا چیست؟ خروجی مورد انتظار چیست؟ و نتیجه چگونه بررسی خواهد شد؟ عبارت «دقت بیشتر شود» را با یک فعالیت قابل پیگیری جایگزین کنید. مثلاً در سناریوی نسخه نادرست، می‌توان بازبینی مسیر دسترسی به نسخه مصوب و ثبت تطابق نسخه مورد استفاده را برای ارزیابی پیشنهاد کرد.
در مثال تغییر تأمین‌کننده نیز، اگر اختلاف ابلاغ الزام واقعاً تأیید شده باشد، بازبینی سازوکار انتقال و پذیرش نسخه الزام می‌تواند یک گزینه باشد. در گزارش توضیح دهید چرا این گزینه انتخاب شده و چگونه همان علت را هدف می‌گیرد. این مثال‌ها دستور آماده برای همه کارخانه‌ها نیستند؛ اقدام نهایی را بر اساس شواهد پرونده و مجوزهای لازم انتخاب کنید.
پیش از اجرا، معیار موفقیت را در طرح بررسی مشخص کنید. چه نتیجه‌ای قابل قبول است؟ بررسی در چه شرایطی انجام می‌شود؟ چه داده‌ای نگهداری خواهد شد؟ و چه مشاهده‌ای موجب بازشدن دوباره تحلیل می‌شود؟ تعداد نمونه، مدت پایش و حد پذیرش را از طرح معتبر و توافق‌شده همان پرونده بگیرید؛ نه با انتقال یک عدد عمومی از پرونده‌ای دیگر.
D6: اجرای اقدام را با تأیید اثربخشی یکی ندانید
در نسخه پیشنهادی گزارش، سه وضعیت جدا داشته باشید: انتخاب‌شده، اجراشده و اثربخشی بررسی‌شده. برای اجرا، مدرک انجام کار را معرفی کنید. برای اثربخشی، نتیجه بررسی پس از اجرا را بیاورید. اگر هنوز داده کافی ندارید، بنویسید: «اقدام اجرا شده؛ ارزیابی اثربخشی همچنان باز است.» این جمله، ادعای گزارش را به وضعیت ثبت‌شده پرونده محدود می‌کند.
برای ارائه نتیجه، پیشنهاد می‌کنیم هر مدرک به یک پرسش مشخص پاسخ دهد. صورت‌جلسه تغییر را برای مستندسازی اجرای تصمیم و گزارش بررسی پس از اجرا را برای ارائه نتیجه معرفی کنید. اگر آزمایش در شرایط محدود انجام شده، همان محدودیت را کنار نتیجه بنویسید. از خواننده نخواهید خودش حدس بزند یک پیوست چه ارتباطی با ادعای گزارش دارد.
برای مطالعه مستقل درباره ارزیابی فرایند، می‌توانید به مقاله شاخص‌های Cp و Cpk در تولید قطعات خودرو مراجعه کنید. در این مقاله، هدف بازآموزی محاسبات قابلیت نیست؛ پیشنهاد نگارشی این است که هر نتیجه مورد استفاده، به سؤال مشخص همین شکایت و دامنه بررسی آن متصل شود.
D7 و D8؛ از پرونده فعلی به جلوگیری از تکرار برسید
در راهنمای بوش، D7 شامل بازبینی مدارک مرتبط و انتقال آموخته‌ها به محصولات و فرایندهای مشابه است. D8 نیز مرور نهایی مسیر حل مسئله و جمع‌بندی را پوشش می‌دهد. این تقسیم‌بندی را می‌توانید در بخش پایانی گزارش از طریق همان توضیح مراحل پایانی 8D در راهنمای بوش دنبال کنید. (assets.bosch.com)
D7: مشخص کنید کجاهای دیگر را بررسی کرده‌اید
به‌جای جمله «به سایر خطوط تعمیم داده شد»، فهرست موارد بررسی‌شده را بیاورید. آیا قطعه دیگری از همان مسیر ابلاغ نسخه استفاده می‌کند؟ آیا دستور مشابه در محل دیگری اجرا می‌شود؟ آیا تأمین‌کننده دیگری با همان سازوکار دریافت الزام کار می‌کند؟ برای هر مورد، نتیجه بررسی، اقدام لازم یا دلیل بی‌نیازی به اقدام را ثبت کنید.
اگر بازبینی مدارک لازم شد، عنوان سند، شماره ویرایش و محل تغییر را به گزارش اضافه کنید. برای مطالعه زمینه مرتبط، مقاله ارتباط PFMEA و برنامه کنترل در تولید قطعات خودرو را بخوانید. در این پرونده، پیشنهاد ما ارائه نشانی دقیق تغییر در مدرک است، نه نوشتن جمله کلی «مدارک کیفیت اصلاح شد».
D8: پیش از بستن پرونده، موارد باز را مرور کنید
برای جمع‌بندی، وضعیت موجودی، اقدامات باز، مدارک نتیجه، مجوزهای مرتبط و پاسخ مشتری را یک‌بار کنار هم قرار دهید. اگر بخشی هنوز تکمیل نشده، آن را حذف نکنید تا گزارش ظاهراً کامل به نظر برسد. می‌توانید در خلاصه نهایی بنویسید چه مواردی پایان یافته و چه مواردی همچنان به تأیید یا مدرک نیاز دارند.
همچنین پیشنهاد می‌کنیم یک یادداشت کوتاه از آموخته‌های پرونده نگه دارید: کدام اطلاعات دیر به دست رسید؟ کدام ارجاع مبهم بود؟ چه کاری در رسیدگی بعدی باید زودتر انجام شود؟ این یادداشت را از نتیجه فنی جدا کنید تا هم تجربه اجرایی حفظ شود و هم علت تأییدشده در میان توضیحات جانبی گم نشود.
خلاصه‌ای که کیفیت و خرید بتوانند با آن تصمیم بگیرند
برای هماهنگی مسئول کیفیت و خرید، پیشنهاد می‌کنیم در هر بازنگری گزارش، یک خلاصه ثابت تهیه شود. جزئیات بررسی در پیوست‌ها بماند، اما وضعیت تصمیم‌ها در متن اصلی روشن باشد. در این الگو، خواننده می‌بیند کدام موضوع اکنون تعیین تکلیف شده و کدام موضوع هنوز به نتیجه بررسی وابسته است.
- وضعیت مسئله: مشاهده تأییدشده، دامنه فعلی و اطلاعات نامعلوم.
- وضعیت موجودی و ارسال: مقادیر نگه‌داشته‌شده، محموله‌های در مسیر و تصمیم‌های باقی‌مانده.
- وضعیت تحلیل: فرضیه‌های باز و علت‌های تأییدشده با ارجاع به مدرک.
- وضعیت اقدام: اقدام انتخاب‌شده، اجرای انجام‌شده و نتیجه بررسی پس از اجرا.
- گام بعدی: نقش مسئول، موعد، مجوز موردنیاز و خروجی قابل ارائه.
این خلاصه را جایگزین متن فنی نکنید. اگر پیشنهاد تغییر تأمین‌کننده مطرح است، آن را به‌عنوان تصمیمی مستقل با بررسی‌ها و مجوزهای لازم ثبت کنید؛ نه نتیجه خودکار برگشت یک قطعه. در نسخه پیشنهادی گزارش، دلیل تصمیم خرید و نتیجه تحلیل فنی در بخش‌های مشخص نوشته شوند تا خواننده ارتباط و تفاوت آن‌ها را ببیند.
اشتباه‌هایی که در بازخوانی گزارش باید پیدا کنید
در بازبینی داخلی، متن را از نگاه کسی بخوانید که در جلسات حضور نداشته است. آیا می‌تواند مشاهده، فرضیه، تصمیم و نتیجه را از هم تشخیص دهد؟ برای این بازخوانی، فهرست زیر را پیشنهاد می‌کنیم:
- علت زودهنگام: آیا یک احتمال بدون مدرک در بخش نتیجه نهایی قرار گرفته است؟
- مهار با عنوان اصلاح: آیا جداسازی موجودی، به‌اشتباه حذف علت معرفی شده است؟
- عبارت «خطای اپراتور» بدون توضیح: آیا شرایط اجرا و مدارک مرتبط بررسی و ثبت شده‌اند؟
- اقدام بدون خروجی: آیا عبارتی مانند «دقت بیشتر» هنوز در فهرست اقدامات مانده است؟
- نتیجه بدون دامنه: آیا معلوم است نتیجه مربوط به کدام نمونه‌ها و شرایط است؟
- پیوست بی‌ارتباط: آیا نقش هر فایل در پشتیبانی از تصمیم مشخص شده است؟
- بستن زودهنگام: آیا موضوعی پایان‌یافته ثبت شده، درحالی‌که مدرک نتیجه هنوز باز است؟
اگر نمونه، داده یا معیار پذیرش در دسترس نیست، در الگوی پیشنهادی ما سه چیز نوشته می‌شود: محدودیت چیست، کدام نتیجه را فعلاً نمی‌توان اعلام کرد و برنامه تکمیل اطلاعات چگونه است. اگر مشکل در بررسی انجام‌شده دیده نشد، همان را گزارش کنید؛ از تبدیل نتیجه محدود به ادعای کلی «مشکلی وجود ندارد» پرهیز کنید.
برای کنترل ویرایش گزارش نیز پیشنهاد می‌کنیم تغییرهای مهم هر نسخه را کوتاه بنویسید. مثلاً روشن کنید شرح مسئله با دریافت نمونه تکمیل شده، یک فرضیه پس از بررسی رد شده یا وضعیت یک اقدام از اجراشده به اثربخشی بررسی‌شده تغییر کرده است. متن نسخه تازه را با اطلاعات همان نسخه هماهنگ کنید و جمله‌های قدیمی متناقض را بدون توضیح باقی نگذارید.
پرسش‌های متداول درباره گزارش 8D قطعات خودرو
اگر علت هنوز مشخص نیست، در پاسخ اولیه چه بنویسیم؟
در قالب پیشنهادی این مقاله، شرح مشاهده، دامنه فعلی، اقدامات مهار، اطلاعات موردنیاز و برنامه مرحله بعد را بنویسید. وضعیت علت را «در حال بررسی» نگه دارید و برای پیگیری، نقش مسئول و موعد مشخص کنید. قالب نهایی پاسخ را با درخواست همان مشتری تطبیق دهید. پاسخ اولیه را با نتیجه نهایی یکی نگیرید و برای کامل نشان‌دادن فرم، علت احتمالی را قطعی ننویسید.
آیا آموزش مجدد را به‌عنوان اقدام اصلاحی بنویسیم؟
پیشنهاد می‌کنیم آن را صرفاً برای پرکردن بخش اقدام انتخاب نکنید. ابتدا در گزارش توضیح دهید آموزش چه ارتباطی با علت تأییدشده دارد، چه خروجی‌ای از آن انتظار می‌رود و نتیجه چگونه بررسی می‌شود. اگر هنوز این ارتباط روشن نیست، انتخاب اقدام را باز نگه دارید. در مثال‌های این مقاله، هیچ اقدام آماده‌ای بدون بررسی علت به همه پرونده‌ها تعمیم داده نمی‌شود.
چه زمانی می‌توان مهار را برداشت؟
در راهنمای بوش، رفع مهار با اجرای اقدام اصلاحی و تأیید نتیجه آن مرتبط شده و در صورت نیاز، توافق مشتری نیز مطرح است. برای پرونده خود، تصمیم رفع مهار و مرجع تأیید آن را جدا مستند کنید؛ تکمیل بخش اجرای اقدام را به‌تنهایی مجوز آزادسازی موجودی ندانید. (assets.bosch.com)
آیا گزارش 8D مجوز اجرای تغییر است؟
اگر در رابطه تأمین، مجوز تغییر جداگانه لازم باشد، این دو مسیر را یکی نگیرید. راهنمای SICR بوش نمونه‌ای از الزام دریافت تأیید پیش از اجرا در دامنه مشخص خود است. در الگوی پیشنهادی گزارش، شناسه درخواست تغییر و وضعیت مجوز را کنار اقدام مرتبط بیاورید تا وضعیت رسیدگی به شکایت با وضعیت اجازه اجرای تغییر اشتباه نشود. (assets.bosch.com)
جمع‌بندی؛ گزارش را ساده بنویسید، اما شواهد را حذف نکنید
برای تنظیم یک گزارش روشن، پیشنهاد نهایی ما این است که سه مرز را در تمام بخش‌ها حفظ کنید: مشاهده با فرضیه یکی نیست، اجرای اقدام با اثربخشی یکی نیست و تکمیل فرم با پایان رسیدگی یکی نیست. در مسئله‌های پس از تغییر نیز، سوابق پیش و پس از تغییر، نسخه‌های اجرایی و وضعیت مجوزها را به همان بخش مرتبط ارجاع دهید؛ بدون آنکه گزارش شکایت را به آموزش کامل مدیریت تغییر تبدیل کنید.
گزارش را با جمله‌های کوتاه و مشخص بنویسید؛ هر ادعا را به مدرک آن وصل کنید و هر موضوع باز را با نقش مسئول و گام بعدی نشان دهید. اگر برای هماهنگی موضوع مرتبط با قطعات هاناپارت نیاز به ارتباط دارید، از صفحه تماس با هاناپارت استفاده کنید و در طرح موضوع، شناسه قطعه، شرح مشاهده و مدارک قابل‌اشتراک را مشخص کنید. این مسیر ارتباطی، جای بررسی فنی و توافق درباره نحوه رسیدگی به پرونده را نمی‌گیرد.