پاسخ کوتاه

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

نکته‌های کلیدی

شروع از مسئله‌ای قابل اندازه‌گیری

انتخاب آزمایش متناسب با ریسک

پیگیری نتیجه در کار روزانه

سه کار متفاوت را به هم وصل کنید

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

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

بهبود مستمر در یک شیفت عادی چه شکلی دارد؟

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

اصول کار روشن‌اند: ارزش را از نگاه مشتری تعریف کنید، کار را ببینید، انجام‌دهندگان را درگیر کنید، تغییر محدودی را بیازمایید و پیگیری کنید که نتیجه باقی می‌ماند یا نه. ایمنی، کیفیت و تیم بعدی را هم در نظر بگیرید. کایزن روزانه این تمرین مداوم را فراهم می‌کند؛ رویداد کایزن توجه گروه را روی مسئله‌ای محدود متمرکز می‌کند. با راهنمای PDCA بررسی نتیجه را برنامه‌ریزی کنید و وقتی تغییر به همکاری چند تیم نیاز دارد، از راهنمای رویداد کایزن کمک بگیرید.

وضعیت فعلی را در محل کار ببینید

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

شمارش، زمان، نتیجه بازرسی و سابقه نگهداری را نگه دارید. اندازه‌گیری و برآورد را جدا بنویسید؛ نبود داده را صفر نگذارید.

پیش‌بینی را پیش از آزمایش بنویسید

بگویید چه چیزی را تغییر می‌دهید، چرا انتظار اثر دارید و چه نتیجه‌ای توضیح شما را رد می‌کند. از تغییری محدود و قابل بازگشت شروع کنید. ایمنی، کیفیت و الزام قانونی، حدود آزمایش را تعیین می‌کنند.

شرایط قابل مقایسه را انتخاب و تغییرهای هم‌زمان را ثبت کنید. هم اندازه اثر و هم عدم‌قطعیت و پیامد جانبی آن را گزارش کنید.

  1. مسئله

    فاصله نتیجه واقعی با انتظار و مسئول بررسی را مشخص کنید.

  2. شواهد

    مشاهده و سوابق را روی یک خط زمانی قرار دهید.

  3. آزمون

    یک تغییر مجاز و معیار رد یا تأیید پیش‌بینی را تعیین کنید.

  4. نتیجه

    اثر محلی و اثر بر خروجی کل را جدا بررسی کنید.

بیش از ظرفیت تیم کار باز نکنید

پیشنهادها را از نظر اثر بر مشتری، شواهد، تلاش، ریسک و افراد مورد نیاز مقایسه کنید. مهار فوری، تغییر کوچک روزانه و پروژه مهندسی بزرگ، برنامه‌های یکسانی ندارند.

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

نتیجه را وارد روش عادی کار کنید

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

استاندارد، بهترین روش شناخته‌شده فعلی است. با تغییر شرایط، دوباره پیش‌بینی و آزمایش کنید؛ لازم نیست روش قبلی را فقط چون تأیید شده حفظ کنید.

از 3C برای یک مسئلهٔ کوچک استفاده کنید، نه کل سیستم بهبود

در حل مسئلهٔ روزانه، 3C می‌تواند مخفف Concern، Cause و Countermeasure، یعنی مسئله، علت و اقدام اصلاحی باشد. مشکل مشاهده‌شده، شواهد علت و اقدامی را که باید بیازمایید ثبت کنید. مسئول و بررسی نتیجه را هم بنویسید. اگر علت هنوز حدس است، اقدام بعدی بررسی بیشتر است، نه بستن مسئله.

نام‌ها به مدل بستگی دارند. تویوتا بهبود مستمر و احترام به افراد را دو ستون «راه تویوتا» معرفی می‌کند. این‌ها دو مرحلهٔ بررسی علت نیستند. یک سابقهٔ کوتاه 3C می‌تواند به این رویکرد کمک کند، اما جای پرورش افراد، تعیین اولویت‌ها و بررسی نتایج را نمی‌گیرد.

منظور کدام فرایند هفت‌مرحله‌ای بهبود است؟

ITIL برای خدمات، مدل مشخصی از بهبود مستمر دارد. PeopleCert هفت پرسش را توضیح می‌دهد: چشم‌انداز چیست، اکنون کجا هستیم، به کجا می‌خواهیم برسیم، چگونه می‌رسیم، چه اقدامی انجام می‌دهیم، آیا به هدف رسیده‌ایم و چگونه بهبود را ادامه می‌دهیم. این مدل برای مدیریت خدمات مفید است؛ استاندارد اجباریِ هفت‌مرحله‌ای برای تولید نیست.

منابع قدیمی‌تر ITIL، توالی اندازه‌گیری خود را هم «فرایند هفت‌مرحله‌ای بهبود» می‌نامند: راهبرد بهبود را مشخص کنید، اندازه‌گیری‌ها را تعریف کنید، داده را گردآوری و پردازش کنید، آن را تحلیل کنید، یافته‌ها را ارائه دهید و به کار ببرید، سپس بهبودها را اجرا کنید. این توالی را با هفت پرسش بالا یکی نگیرید. برای یک آزمایش در محل تولید، شاید PDCA کافی باشد؛ مسئلهٔ عیبی که علتش روشن نیست ممکن است به DMAIC نیاز داشته باشد.

مثالی مرتبط از ابوالفضل

ابوالفضل دربارهٔ حفظ ارتباط نتیجه با تصمیم اولیهٔ بهبود می‌نویسد.

مطالعهٔ یادداشت تکمیلی

به انگلیسی در وبلاگ شخصی ابوالفضل، بنیان‌گذار Vrolen. مطالعهٔ مرتبط است، نه منبع فنی مستقل.

چک‌لیست عملی

  • مسئله و نتیجه مورد انتظار را بنویسید.
  • کار واقعی را همراه انجام‌دهندگان ببینید.
  • خط مبنا و داده نامعلوم را ثبت کنید.
  • مسئول و وقت بررسی تعیین کنید.
  • پیش از تغییر، پیش‌بینی بنویسید.
  • حدود ایمنی و کیفیت را رعایت کنید.
  • اثر بر کل جریان و پیامد جانبی را بسنجید.
  • استاندارد و زمان پیگیری را به‌روز کنید.

پرسش‌های متداول

پرسش‌های متداول

منابع و مطالعهٔ بیشتر

منابع معتبر استفاده‌شده برای پژوهش و بررسی این راهنما.