سیستم تولید تویوتا (TPS)؛ از حذف اتلاف تا معماری رقابت پذیری عملیاتی( قسمت اول )

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

مقدمه

در ادبیات مدیریت تولید، کمتر سیستمی را می توان یافت که به اندازه سیستم تولید تویوتا (Toyota Production System: TPS) بر نحوه فهم سازمان ها از بهره وری، کیفیت، موجودی، جریان کار و نقش کارکنان اثر گذاشته باشد. TPS صرفا مجموعه ای از تکنیک ها برای کاهش موجودی یا افزایش سرعت خط تولید نیست؛ بلکه یک نظام مدیریتی و عملیاتی است که تلاش می کند میان جریان ارزش، کیفیت، زمان، هزینه، ظرفیت، حل مسئله و توسعه انسان ارتباطی منسجم ایجاد کند. خود شرکت Toyota هدف TPS را حذف اتلاف و کوتاه کردن زمان تحویل می داند تا محصول با کیفیت بالا، هزینه پایین و در زمان مناسب به مشتری برسد.

اهمیت TPS از اینجا ناشی می شود که مسئله اصلی آن «چگونه بیشتر تولید کنیم؟» نیست، بلکه پرسش بنیادی تری را مطرح می کند: چگونه می توان محصول موردنیاز مشتری را، با کیفیت مورد انتظار، در زمان موردنیاز و با حداقل صرف منابع تولید کرد، در حالی که مشکلات نیز به جای پنهان شدن، سریعا آشکار و حل شوند؟

این تغییر زاویه دید، تفاوت میان یک برنامه معمول کاهش هزینه و یک سیستم تولید واقعی را نشان می دهد. در یک سازمان سنتی، موجودی ممکن است برای پوشاندن مشکلات کیفیت، تاخیر تامین، خرابی تجهیزات یا ناهماهنگی برنامه ریزی استفاده شود. TPS تلاش می کند این «پوشش» را کنار بزند. کاهش موجودی در این نگاه، هدف نهایی نیست؛ بلکه وسیله ای برای آشکارشدن مشکلات سیستم است.

به همین دلیل، فهم TPS بدون توجه به ارتباط میان Just-in-Time، Jidoka، استانداردسازی، Kaizen، Heijunka، Pull، حل مسئله و توسعه افراد ناقص خواهد بود. دو ستون اصلی TPS یعنی JIT و Jidoka، در واقع زمانی عملکرد مطلوب پیدا می کنند که بر بستری از ثبات فرایند، استاندارد کار، یادگیری سازمانی و مشارکت کارکنان قرار گرفته باشند.

۱. چرا TPS شکل گرفت؟

۱-۱. مسئله تویوتا، مسئله تولید انبوه آمریکایی نبود

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

مدل تولید انبوه فورد بر تولید حجم بالای محصولات استانداردشده و استفاده گسترده از تجهیزات و موجودی های مرتبط با تولید انبوه متکی بود. مسئله تویوتا این بود که نمی توانست همان الگو را بدون تغییر در محیط ژاپن تکرار کند.

از اینجا یک مسئله مدیریتی شکل گرفت: اگر امکان تولید انبوه با سرمایه گذاری بسیار بالا وجود ندارد، چگونه می توان تنوع بیشتر، حجم های پایین تر، کیفیت بالاتر و هزینه کمتر را همزمان دنبال کرد؟

پاسخ تویوتا، به تدریج، به طراحی یک سیستم متفاوت انجامید؛ سیستمی که به جای اتکا به موجودی و ظرفیت مازاد، بر جریان، کشش، کیفیت در مبدا و حل سریع مسئله تاکید می کرد.

Lean Enterprise Institute نیز شکل گیری TPS را حاصل توسعه تدریجی مجموعه ای از ایده ها در تویوتا می داند و تاکید می کند که JIT و Jidoka ریشه هایی حتی پیش از جنگ جهانی دوم دارند.

۲. ریشه های TPS: از ساکیچی تویودا تا تایچی اونو

تاریخ TPS را نمی توان صرفا با نام تایچی اونو آغاز کرد. سه چهره در شکل گیری این سیستم نقش برجسته ای داشتند: ساکیچی تویودا، کیچیرو تویودا و تایچی اونو؛ و در توسعه و تثبیت آن، ایجی تویودا نیز نقشی اساسی ایفا کرد.

ساکیچی تویودا و جیدوکا

ساکیچی تویودا، بنیانگذار گروه تویوتا، در توسعه ماشین های بافندگی خودکار نقش داشت. یکی از ایده های مهم او این بود که ماشین بتواند در هنگام وقوع نقص، مانند پارگی نخ، متوقف شود.

این مفهوم بعدها به یکی از ریشه های Jidoka تبدیل شد: کیفیت نباید صرفا در انتهای فرایند بازرسی شود؛ بلکه فرایند باید بتواند وقوع ناهنجاری را تشخیص دهد و از تولید یا انتقال محصول معیوب جلوگیری کند. Toyota نیز منشا مفهوم Jidoka را به ماشین های بافندگی خودکار ساکیچی تویودا مرتبط می کند.

کیچیرو تویودا و Just-in-Time

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

از این منظر، JIT یک شعار درباره «موجودی صفر» نیست؛ بلکه مسئله اصلی آن هماهنگ سازی جریان تولید با تقاضای واقعی است.

Toyota نیز JIT را تولید «آنچه مورد نیاز است، در زمان مورد نیاز و به مقدار مورد نیاز» تعریف می کند.

تایچی اونو و تبدیل ایده ها به سیستم

تایچی اونو نقش محوری در توسعه عملی TPS پس از جنگ جهانی دوم داشت. او تلاش کرد اصولی مانند جریان، تولید کششی، کاهش موجودی، استانداردسازی و حل مسئله را به یک سیستم عملیاتی تبدیل کند.

Lean Enterprise Institute توسعه TPS را به اونو نسبت می دهد و توضیح می دهد که توسعه آن از عملیات ماشین کاری آغاز شد و در دهه های ۱۹۵۰ و ۱۹۶۰ گسترش یافت و بعدها به شبکه تامین کنندگان نیز سرایت کرد.

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

۳. TPS دقیقا چیست؟

TPS را می توان یک سیستم اجتماعی فنی تولید و مدیریت عملیات دانست.

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

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

به بیان ساده:

TPS تلاش نمی کند سازمان را از مسئله خالی کند؛ بلکه سیستم را طوری طراحی می کند که مسئله سریع تر دیده شود و سریع تر حل شود.

این تفاوت بسیار مهم است.

۴. خانه TPS؛ معماری یک سیستم، نه مجموعه ای از ابزارها

TPS معمولا با استعاره «خانه» نمایش داده می شود. این استعاره از نظر مدیریتی نیز مفید است، زیرا نشان می دهد که اجزای سیستم به یکدیگر وابسته اند.

دو ستون اصلی خانه عبارت اند از:

1. Jidoka
2. Just-in-Time

اما این دو ستون بر پایه هایی مانند استانداردسازی، ثبات، کایزن و توسعه افراد قرار دارند و هدف نهایی آنها ایجاد ارزش برای مشتری با کیفیت بالا، هزینه مناسب و زمان تحویل کوتاه است. Lean Enterprise Institute نیز TPS را سیستمی متشکل از دو ستون JIT و Jidoka معرفی می کند که با استانداردسازی کار و Kaizen و چرخه PDCA حفظ و بهبود می یابد.

۵. ستون اول TPS: Just-in-Time۵-۱. JIT چیست؟

Just-in-Time را نباید صرفا «کاهش موجودی» ترجمه کرد.

مفهوم بنیادی JIT عبارت است از:

تولید و جابه جایی فقط آن چیزی که مشتری یا فرایند بعدی نیاز دارد، در زمان مورد نیاز و به مقدار مورد نیاز.

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

بنابراین اگر یک کارخانه موجودی خود را کاهش دهد اما همچنان تولید مازاد، زمان انتظار، دوباره کاری و اختلال جریان داشته باشد، نمی توان گفت TPS را اجرا کرده است.

JIT باید با مفاهیمی مانند:

• Pull System
• Kanban
• Flow
• Heijunka
• Takt Time
• Standardized Work

همراه شود.

۶. کانبان؛ ابزار اجرای منطق Pull

کانبان یکی از شناخته شده ترین ابزارهای TPS است، اما در بسیاری از سازمان ها معنای آن بیش از حد ساده شده است.

کانبان در اصل یک سیستم سیگنال دهی برای هماهنگ سازی تولید و جابه جایی مواد است. در سیستم Push، تولیدکننده ممکن است براساس برنامه داخلی خود تولید کند و محصول را به مرحله بعدی تحویل دهد. در سیستم Pull، مرحله بعدی نیاز خود را به مرحله قبلی منتقل می کند.

در این حالت، جریان اطلاعات برخلاف جریان مواد عمل می کند.

به صورت ساده:

نیاز مشتری ← فرایند بعدی ← فرایند قبلی ← تامین کننده

این منطق باعث می شود تولید از تقاضای واقعی جدا نشود.

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

و این دقیقا یکی از ویژگی های TPS است: سیستم باید مشکلات پنهان را آشکار کند، نه اینکه آنها را با موجودی بیشتر بپوشاند.

۷. ستون دوم TPS: Jidoka۷-۱. کیفیت باید در فرایند ساخته شود

Jidoka معمولا به «خودکارسازی با لمس انسانی» ترجمه می شود. Toyota آن را توانایی توقف فرایند هنگام شناسایی ناهنجاری می داند؛ این توقف می تواند توسط تجهیزات یا خود اپراتور انجام شود. هدف، جلوگیری از ادامه یافتن تولید معیوب و ایجاد امکان حل مسئله در همان نقطه است.

در سیستم سنتی، ممکن است محصول معیوب در پایان خط شناسایی شود.

در Jidoka، پرسش متفاوت است:

چرا اجازه دادیم این نقص چندین مرحله جلوتر برود؟

این تفاوت میان «بازرسی کیفیت» و «ساخت کیفیت در فرایند» است.

۸. Andon؛ دیداری کردن مشکل

یکی از ابزارهای مرتبط با Jidoka، Andon است.

Andon به کارکنان امکان می دهد وضعیت یا مشکل را به صورت دیداری اعلام کنند. در کارخانه های تویوتا، در صورت بروز مشکل، اپراتور می تواند درخواست کمک کند و وضعیت مشکل برای تیم مربوطه آشکار شود.

اهمیت Andon در خود چراغ یا تابلو نیست.

اهمیت واقعی آن در این است که سازمان به کارکنان می گوید:

دیدن مشکل بهتر از پنهان کردن مشکل است.

اگر سازمانی Andon نصب کند اما کارکنان از ترس تنبیه مشکلات را گزارش نکنند، ابزار وجود دارد اما فلسفه Jidoka وجود ندارد.

۹. Muda، Mura و Muri؛ سه منشا مهم ناکارایی

در ادبیات Lean سه مفهوم ژاپنی نقش مهمی دارند:

Muda — اتلاف

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

نمونه های کلاسیک شامل:

• تولید بیش از نیاز
• انتظار
• حمل ونقل غیرضروری
• پردازش اضافی
• موجودی اضافی
• حرکت اضافی
• نقص و دوباره کاری

است.

Mura — ناهمگونی

Mura به نوسان، بی ثباتی و ناهمگونی در بار کاری و جریان عملیات مربوط است.

برای مثال، اگر یک واحد در روز اول تقریبا بیکار باشد و روز بعد با حجم بسیار زیادی از درخواست ها مواجه شود، مشکل فقط «اتلاف» نیست؛ سیستم با نوسان مواجه است.

Muri — اضافه بار

Muri زمانی رخ می دهد که افراد یا تجهیزات بیش از ظرفیت منطقی خود تحت فشار قرار گیرند.

اضافه بار می تواند موجب:

• خطای انسانی
• خرابی تجهیزات
• کاهش کیفیت
• خستگی کارکنان
• افزایش زمان انجام کار

شود.

Toyota در توضیح رسمی TPS نیز بر حذف همزمان Muri، Mura و Muda تاکید می کند.

۱۰. رابطه Muda، Mura و Muri

یکی از خطاهای رایج در اجرای Lean این است که سازمان فقط به Muda توجه می کند.

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

ممکن است در کوتاه مدت خروجی افزایش پیدا کند، اما اگر بار کاری از ظرفیت واقعی فرد یا ماشین عبور کند، Muri ایجاد می شود. در ادامه خطا و خرابی افزایش می یابد و Mura شکل می گیرد. سپس دوباره کاری و انتظار ایجاد می شود و در نهایت Muda افزایش می یابد.

بنابراین این سه مفهوم جدا از یکدیگر نیستند.

می توان رابطه آنها را چنین دید:

ناهمگونی ←اضافه بار ← خطا/اختلال ← اتلاف

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

۱۱. هفت اتلاف کلاسیک در TPS

یکی از مشهورترین دستاوردهای تفکر اونو، طبقه بندی اتلاف هاست.

۱. تولید بیش از نیاز

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

۲. انتظار

انتظار کارکنان، مواد، تجهیزات یا اطلاعات برای ادامه فرایند.

۳. حمل ونقل غیرضروری

انتقال فیزیکی محصول یا مواد بدون ایجاد ارزش برای مشتری.

۴. پردازش اضافی

انجام کاری بیش از آنچه برای تحقق مشخصات محصول یا نیاز مشتری لازم است.

۵. موجودی اضافی

مواد اولیه، کالای نیمه ساخته یا محصول نهایی بیش از مقدار لازم.

۶. حرکت اضافی

حرکات غیرضروری کارکنان هنگام انجام کار.

۷. نقص و دوباره کاری

تولید محصول معیوب یا انجام مجدد فعالیت به دلیل خطا.

در برخی چارچوب های متاخر، «استفاده نشدن از استعداد و دانش کارکنان» نیز به عنوان نوع دیگری از اتلاف مطرح شده است. با این حال، بهتر است در یک متن علمی آن را به عنوان توسعه متاخر چارچوب معرفی کنیم، نه اینکه آن را بدون توضیح به فهرست تاریخی هفت اتلاف نسبت دهیم.

۱۲. Kaizen؛ موتور یادگیری مستمر

کایزن یکی از مفاهیم کلیدی TPS است، اما گاهی به اشتباه با «برگزاری جلسات بهبود» یکی گرفته می شود.

Kaizen در TPS به معنای ایجاد تغییرات مستمر و نظام مند برای بهبود فرایند است.

منطق آن ساده است:

استاندارد فعلی ← شناسایی انحراف ← تحلیل علت ← اصلاح ← استاندارد جدید

بنابراین کایزن بدون استاندارد معنا ندارد.

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

۱۳. استانداردسازی؛ دشمن بهبود نیست

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

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

وقتی روش کار استاندارد شد، هر انحرافی قابل مشاهده می شود. سپس کارکنان می توانند سوال کنند:

چرا روش جدید بهتر است؟

اگر روش جدید بهتر باشد، استاندارد تغییر می کند.

بنابراین رابطه واقعی چنین است:

استانداردسازی م←شاهده انحراف ←آزمایش ← یادگیری ← استاندارد جدید

این چرخه، همان چیزی است که TPS را از یک دستورالعمل ثابت به یک سیستم یادگیرنده تبدیل می کند.

۱۴. ارتباط TPS با روش علمی

Spear و Bowen در مطالعه مشهور خود استدلال می کنند که یکی از ویژگی های متمایز TPS، تبدیل فعالیت های عملیاتی به مجموعه ای از آزمایش های کنترل شده است. در این نگاه، استاندارد کاری صرفا دستورالعمل نیست؛ بلکه نوعی فرضیه درباره بهترین روش انجام کار است.

مثلا اگر فرض شود:

«اگر زمان تنظیم ماشین از ۴۰ دقیقه به ۲۰ دقیقه کاهش یابد، اندازه بچ تولید می تواند کوچک تر شود.»

سازمان می تواند این فرضیه را آزمایش کند.

اگر نتیجه تایید شد، روش جدید استاندارد می شود.

این نگاه علمی، یکی از دلایل مهمی است که TPS را از مجموعه ای از ابزارهای سطحی Lean متمایز می کند.

۱۵. Heijunka؛ هموارسازی تولید

حتی اگر Pull System به درستی طراحی شده باشد، نوسان شدید تقاضا می تواند سیستم را بی ثبات کند.

Heijunka به معنای هموارسازی تولید است.

فرض کنید مشتریان در یک هفته ۱۰۰ واحد از محصول A و در هفته بعد ۵۰۰ واحد درخواست کنند.

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

Heijunka تلاش می کند این نوسان را تا حد امکان هموار کند.

هدف آن حذف تقاضای واقعی نیست؛ بلکه مدیریت نحوه انتقال تقاضا به سیستم تولید است.

۱۶. Takt Time؛ تولید با ریتم تقاضا

Takt Time از ابزارهای مهم برای هماهنگ کردن ظرفیت با تقاضا است.

به صورت ساده:

Takt Time = زمان در دسترس تولید / تقاضای مشتری

اگر مثلا ۴۲۰ دقیقه زمان تولید موثر در روز وجود داشته باشد و مشتری ۲۱۰ واحد در روز نیاز داشته باشد:

Takt Time = 420 / 210 = 2 دقیقه

یعنی سیستم باید به طور متوسط هر دو دقیقه یک واحد را تکمیل کند تا با تقاضای مشتری هماهنگ باشد.

Takt Time با Cycle Time یکی نیست.

• Takt Time از تقاضا می آید.
• Cycle Time از عملکرد واقعی فرایند می آید.

اگر Cycle Time بسیار بیشتر از Takt Time باشد، ظرفیت کافی نیست.

اگر Cycle Time بسیار کمتر باشد، ممکن است ظرفیت مازاد یا تولید بیش از نیاز ایجاد شود.

۱۷. Flow؛ جریان در برابر انباشت

در سیستم های سنتی، تولید اغلب به صورت دسته ای انجام می شود.

مثلا:

۱۰۰ قطعه تولید → انتقال → ۱۰۰ قطعه بازرسی → انتقال → ۱۰۰ قطعه مونتاژ

این ساختار می تواند باعث افزایش WIP و زمان انتظار شود.

در جریان نزدیک به One-Piece Flow، تلاش می شود قطعات تا حد امکان در مقادیر کوچک و پیوسته از مراحل عبور کنند.

هدف فقط کوچک کردن Batch نیست.

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

۱۸. چرا کاهش موجودی در TPS اهمیت دارد؟

موجودی در بسیاری از سازمان ها یک دارایی تلقی می شود، اما از دید TPS موجودی زیاد می تواند نشانه یک مشکل پنهان باشد.

تصور کنید بین دو فرایند ۱۰۰۰ واحد موجودی وجود دارد. اگر فرایند اول کند شود، فرایند دوم ممکن است برای مدتی بدون توقف کار کند.

اما مشکل همچنان وجود دارد.

اگر موجودی به ۱۰۰ واحد کاهش یابد، اختلال فرایند اول بسیار سریع تر آشکار می شود.

به همین دلیل می توان موجودی را در TPS شبیه آب یک رودخانه در نظر گرفت:

موجودی بالا → سنگ های کف رودخانه پنهان می شوند.

موجودی پایین تر → مشکلات سیستم آشکار می شوند.

بنابراین کاهش موجودی زمانی مفید است که سازمان همزمان توانایی حل مشکلات را داشته باشد.

۱۹. Poka-Yoke؛ خطاناپذیرسازی

Poka-Yoke به طراحی روش هایی اشاره دارد که احتمال خطای انسانی را کاهش دهند یا خطا را پیش از تبدیل شدن به نقص شناسایی کنند.

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

این رویکرد از یک فرض مهم استفاده می کند:

اگر یک خطا بارها رخ می دهد، نباید همیشه انتظار داشت انسان صرفا با «دقت بیشتر» آن را حل کند.

گاهی مسئله، ضعف طراحی فرایند است.

۲۰. SMED و کاهش زمان Setup

یکی از موانع تولید در حجم های کوچک، زمان تنظیم ماشین آلات است.

اگر تغییر محصول دو ساعت طول بکشد، تولیدکننده تمایل پیدا می کند محصولات را در بچ های بزرگ تولید کند تا تعداد دفعات Setup کاهش یابد.

اما Batch بزرگ:

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

SMED با هدف کاهش زمان Setup توسعه یافته است.

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

این موضوع نشان می دهد که ابزارهای Lean به یکدیگر وابسته اند:

Setup کمتر → Batch کوچک تر → موجودی کمتر → Flow بهتر → انعطاف پذیری بیشتر

۲۱. 5S؛ نقطه شروع یا هدف نهایی؟

5S یکی از شناخته شده ترین ابزارهای Lean است:

1. تفکیک
2. نظم
3. پاکیزگی
4. استانداردسازی
5. انضباط

اما 5S نباید به یک پروژه زیباسازی محیط کار تبدیل شود.

اگر سازمان فقط خطوط کف کارخانه را رنگ کند، قفسه ها را مرتب کند و عکس «قبل و بعد» بگیرد، هنوز Lean ایجاد نشده است.

5S زمانی ارزش واقعی دارد که باعث شود:

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

بنابراین 5S بخشی از مدیریت دیداری و کنترل فرایند است، نه یک برنامه نظافت.

۲۲. Value Stream Mapping؛ دیدن کل سیستم

یکی از محدودیت های مدیریت سنتی این است که هر واحد عملکرد خود را جداگانه بهینه می کند.

خرید می خواهد قیمت خرید را کاهش دهد.

تولید می خواهد ظرفیت ماشین ها بالا باشد.

انبار می خواهد موجودی کافی داشته باشد.

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

اما ممکن است مجموع این تصمیم ها باعث افزایش Lead Time شود.

Value Stream Mapping یا VSM با ترسیم جریان مواد و اطلاعات، نگاه را از یک واحد به کل جریان ارزش منتقل می کند.

سوال اصلی VSM این نیست:

کدام واحد خوب کار نمی کند؟

بلکه این است:

محصول از سفارش مشتری تا تحویل، کجا منتظر می ماند و چرا؟

۲۳. زمان ارزش افزا در برابر زمان عبور

فرض کنید یک محصول برای تکمیل به ۲۰ ساعت فعالیت واقعی نیاز دارد، اما از سفارش تا تحویل ۲۰ روز طول می کشد.

در این حالت:

• زمان ارزش افزا = ۲۰ ساعت
• Lead Time = ۲۰ روز

تفاوت میان این دو، فضای اصلی تحلیل Lean است.

در بسیاری از سازمان ها، مسئله اصلی کمبود سرعت کارکنان نیست؛ بلکه زمان انتظار بین فعالیت ها است.

این نکته برای شرکت های پروژه محور نیز اهمیت ویژه دارد؛ زیرا ممکن است بخش زیادی از زمان پروژه نه صرف تولید یا مهندسی، بلکه صرف انتظار برای تایید، خرید، اطلاعات، تصمیم مدیریتی یا پیمانکار شود.

۲۴. TPS و نقش مدیر

مدیر در TPS فقط تعیین کننده هدف تولید نیست.

مدیر باید درک کند:

• کار واقعا چگونه انجام می شود؟
• مشکل کجا رخ می دهد؟
• چرا مشکل ایجاد شده؟
• چه داده ای برای تحلیل لازم است؟
• چه چیزی در استاندارد کار تغییر کرده است؟
• آیا اصلاح انجام شده پایدار شده است؟

به همین دلیل، یکی از مفاهیم نزدیک به Toyota Way، Genchi Genbutsu یا رفتن به محل واقعی برای مشاهده واقعیت است.

این اصل با مدیریت صرفا مبتنی بر گزارش فاصله دارد.

گزارش می تواند بگوید:

«تولید ۸ درصد کاهش یافته است.»

اما مشاهده مستقیم ممکن است نشان دهد:

«اپراتور هر بار برای دریافت ابزار ۴ دقیقه از ایستگاه خارج می شود.»

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

۲۵. TPS و احترام به انسان

یکی از مهم ترین ابعاد TPS که در برداشت های سطحی از Lean نادیده گرفته می شود، نقش انسان است.

اگر هدف Lean فقط «کار بیشتر با نیروی کمتر» باشد، اجرای آن می تواند با فلسفه TPS فاصله پیدا کند.

Liker در تحلیل Toyota Way، TPS را صرفا مجموعه ای از ابزارهای فنی نمی داند، بلکه آن را یک سیستم فنی اجتماعی معرفی می کند که توسعه و مشارکت افراد در آن اهمیت اساسی دارد.

کارکنان در TPS فقط مجری دستور نیستند.

آنها:

• مشکلات را مشاهده می کنند،
• انحراف را گزارش می کنند،
• در حل مسئله مشارکت می کنند،
• استاندارد را اجرا می کنند،
• و در بهبود آن نقش دارند.

در چنین سیستمی، دانش عملیاتی کارکنان به یک منبع سازمانی تبدیل می شود.

۲۶. TPS، Lean Production و Lean Thinking چه تفاوتی دارند؟

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

TPS

سیستم عملیاتی توسعه یافته در Toyota است.

Lean Production

اصطلاحی است که در ادبیات غربی برای توصیف و تعمیم ویژگی های سیستم هایی مانند TPS رواج پیدا کرد.

اصطلاح «Lean» در پژوهش MIT درباره صنعت خودرو در اواخر دهه ۱۹۸۰ مطرح شد و کتاب The Machine That Changed the World در سال ۱۹۹۰ آن را در سطح وسیعی شناخته کرد.

Lean Thinking

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

بنابراین:

TPS → سیستم بومی تویوتا

Lean Production → تعمیم سیستم های تولید ناب

Lean Thinking → گسترش منطق ناب به کل نظام خلق ارزش

۲۷. پنج اصل مشهور Lean

Womack و Jones در کتاب Lean Thinking اصولی را برای توضیح تفکر ناب مطرح کردند:

1. تعریف ارزش از دید مشتری
2. شناسایی جریان ارزش
3. ایجاد Flow
4. ایجاد Pull
5. حرکت به سمت Perfection

این چارچوب، Lean را از سطح کارخانه به کل فرایند خلق ارزش گسترش داد.

Lean Enterprise Institute نیز این پنج اصل را در توضیح تاریخچه و تکامل Lean مطرح می کند.

۲۸. چهارده اصل Toyota Way

Jeffrey Liker در کتاب The Toyota Way چهارده اصل مدیریتی را در چهار حوزه کلی دسته بندی کرد. این اصول نشان می دهند که TPS را نمی توان به کانبان، 5S یا JIT تقلیل داد.

چهار حوزه اصلی عبارت اند از:

فلسفه بلندمدت

سازمان باید تصمیم های خود را صرفا بر مبنای سود کوتاه مدت اتخاذ نکند.

فرایند صحیح

جریان، Pull، Heijunka، Jidoka، استانداردسازی و کنترل دیداری باید به ایجاد عملکرد مطلوب کمک کنند.

توسعه افراد و شرکا

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

حل ریشه ای مسئله و یادگیری سازمانی

سازمان باید به جای درمان علائم، به سراغ علت ریشه ای برود و از مشکلات یاد بگیرد.

اثر Liker در ادبیات مدیریت این بود که نشان داد Toyota Way را نمی توان به چند ابزار تولیدی تقلیل داد.

۲۹. حل مسئله؛ چرا 5 Why اهمیت دارد؟

در بسیاری از سازمان ها، حل مسئله با شناسایی اولین علت متوقف می شود.

مثلا:

مشکل: محصول دیر تحویل شد.

علت اولیه:

خرید دیر انجام شد.

اما سوال بعدی:

چرا خرید دیر انجام شد؟

چون درخواست خرید دیر ارسال شد.

چرا؟

چون طراحی محصول دیر تمام شد.

چرا؟

چون اطلاعات مشتری دیر دریافت شد.

چرا؟

چون مسئول مشخصی برای تایید اطلاعات وجود نداشت.

در این مثال، «تاخیر خرید» علت نهایی نیست.

حل مسئله واقعی باید از زنجیره علل عبور کند تا به نقطه ای برسد که با تغییر سیستم بتوان احتمال تکرار مشکل را کاهش داد.

۳۰. PDCA؛ ساختار یادگیری

چرخه PDCA شامل:

Plan → Do → Check → Act

است.

اما ارزش PDCA در نام چهار مرحله نیست؛ در منطق آزمایش و یادگیری آن است.

Plan

مشکل و فرضیه را مشخص کن.

Do

راه حل را در مقیاس مناسب آزمایش کن.

Check

داده واقعی را با وضعیت قبل مقایسه کن.

Act

اگر نتیجه مناسب بود، روش را استاندارد کن؛ اگر نبود، فرضیه را اصلاح کن.

این چرخه باعث می شود «بهبود» از یک ایده ذهنی به یک فرایند مبتنی بر شواهد تبدیل شود.

۳۱. چرا اجرای ابزارهای Lean بدون سیستم مدیریت شکست می خورد؟

فرض کنیم یک شرکت:

• 5S اجرا کند،
• کانبان نصب کند،
• تابلو Andon ایجاد کند،
• VSM ترسیم کند،
• و جلسات Kaizen برگزار کند.

اما:

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

در چنین شرایطی، سازمان مجموعه ای از ابزارهای Lean دارد، اما سیستم Lean ندارد.

این مسئله یکی از مهم ترین تفاوت های میان Lean واقعی و Lean نمادین است.

۳۲. یکی از اشتباهات مهم: کاهش موجودی به عنوان هدف

فرض کنید شرکتی تصمیم می گیرد موجودی را ۳۰ درصد کاهش دهد.

اگر این کاهش بدون بهبود فرایند انجام شود، ممکن است نتیجه چنین باشد:

• کمبود مواد
• توقف تولید
• افزایش سفارش های اضطراری
• افزایش حمل ونقل سریع
• افزایش فشار بر خرید
• افزایش اضافه کاری
• کاهش رضایت مشتری

در این حالت، سازمان فقط «موجودی» را کم کرده است، نه اتلاف را.

در TPS، کاهش موجودی باید همراه با افزایش قابلیت اطمینان فرایند باشد.

۳۳. محدودیت مهم JIT؛ ریسک زنجیره تامین

JIT به دلیل کاهش موجودی بافر می تواند سازمان را نسبت به اختلالات زنجیره تامین حساس تر کند.

این مسئله در شرایطی مانند:

• بلایای طبیعی،
• بحران های ژئوپلیتیکی،
• اختلال حمل ونقل،
• کمبود مواد اولیه،
• ورشکستگی تامین کننده،
• یا نوسان شدید تقاضا

اهمیت بیشتری پیدا می کند.

بنابراین نباید نتیجه گرفت که:

موجودی کمتر همیشه بهتر است.

سوال حرفه ای تر این است:

سطح بهینه موجودی برای این ریسک و این فرایند چیست؟

این تفاوت مهمی میان «Lean» و «افراط در کاهش موجودی» است.

۳۴. آیا TPS همیشه عملکرد مالی را بهبود می دهد؟

پاسخ علمی این پرسش «به صورت مطلق» مثبت نیست.

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

این نکته از نظر مدیریتی بسیار مهم است.

ممکن است یک پروژه Lean:

• زمان Setup را کاهش دهد،
• WIP را کم کند،
• Lead Time را کاهش دهد،

اما اثر مالی آن تا زمانی که این بهبودها به فروش، ظرفیت قابل استفاده، کاهش هزینه یا کاهش سرمایه در گردش منتقل نشوند، محدود باشد.

بنابراین:

Operational Improvement ≠ Automatically Financial Improvement

بین این دو باید یک زنجیره علی وجود داشته باشد.

۳۵. موانع اجرای Lean

پیاده سازی Lean یک پروژه صرفا فنی نیست.

یک مرور نظام مند درباره ریسک های اجرای Lean، ۶۱ عامل ریسک را شناسایی کرده و آنها را در شش دسته کلی قرار داده است:

1. ریسک های مدیریت ارشد
2. ریسک های منابع انسانی
3. ریسک های دانش Lean
4. ریسک های فنی
5. ریسک های زنجیره تامین
6. ریسک های فرهنگی

این یافته نشان می دهد که شکست Lean اغلب فقط ناشی از انتخاب ابزار اشتباه نیست؛ بلکه ممکن است به ساختار مدیریت، فرهنگ سازمان، مهارت کارکنان و قابلیت زنجیره تامین مربوط باشد.

۳۶. Lean در سیستم های پیچیده

یکی از نقدهای مهم به اجرای ساده انگارانه Lean این است که همه فرایندها را نمی توان مانند خط مونتاژ خودرو مدیریت کرد.

در سیستم های پیچیده، مانند:

• بیمارستان ها،
• پروژه های مهندسی،
• توسعه محصول،
• خدمات تخصصی،
• تعمیرات پیچیده،
• و زنجیره های تامین چندلایه،

روابط علت و معلولی همیشه ساده نیستند.

یک مرور نظام مند درباره Lean در سیستم های اجتماعی فنی پیچیده نشان داده است که پیچیدگی در بسیاری از پیاده سازی های Lean به اندازه کافی مورد توجه قرار نگرفته و خود پیچیدگی می تواند هم فرصت و هم مانع برای Lean باشد.

بنابراین انتقال TPS باید بر مبنای اصول انجام شود، نه کپی برداری مکانیکی از ابزارها.

۳۷. TPS در عصر Industry 4.0

یک پرسش مهم امروزی این است:

آیا Lean و Industry 4.0 رقیب یکدیگرند؟

پاسخ غالب ادبیات جدید این است که این دو می توانند مکمل یکدیگر باشند.

Industry 4.0 ابزارهایی مانند:

• IoT
• حسگرها
• Cyber-Physical Systems
• تحلیل داده
• هوش مصنوعی
• اتوماسیون
• Digital Twin

را در اختیار سازمان قرار می دهد.

اما فناوری به تنهایی مشکل فرایند را حل نمی کند.

اگر یک فرایند بد را دیجیتال کنیم، ممکن است فقط یک فرایند بد دیجیتال ایجاد کرده باشیم.

به همین دلیل، منطق Lean می تواند پیش از دیجیتالی سازی به سازمان کمک کند:

1. فرایند را ساده کند،
2. اتلاف را شناسایی کند،
3. جریان اطلاعات را اصلاح کند،
4. استانداردها را تعریف کند،
5. سپس فناوری مناسب را به کار گیرد.

مطالعات جدید درباره Lean 4.0 نیز بر تعامل میان اصول Lean و فناوری های Industry 4.0 تمرکز کرده اند و این حوزه را به عنوان یکی از مسیرهای فعال پژوهش معرفی می کنند.

۳۸. از TPS تا Lean 4.0؛ یک تحول مهم

در نسخه سنتی TPS، مشاهده مستقیم و مدیریت دیداری اهمیت زیادی داشت.

در محیط دیجیتال می توان این قابلیت را گسترش داد:

Visual Management → Digital Visual Management

مثلا به جای اینکه فقط چراغ Andon روی خط روشن شود، داده های توقف می توانند در داشبورد ثبت شوند.

اما نکته مهم این است که فناوری نباید جای حل مسئله را بگیرد.

داشبورد می تواند نشان دهد:

ماشین شماره ۳ امروز ۱۲۰ دقیقه توقف داشته است.

اما پرسش مدیریتی همچنان باقی می ماند:

چرا؟

و سپس:

چه اقدامی احتمال تکرار آن را کاهش می دهد؟

این همان جایی است که TPS و تحلیل داده می توانند به یکدیگر متصل شوند.

۳۹. شاخص های مناسب برای سنجش TPS

ارزیابی TPS نباید فقط با یک شاخص مانند «هزینه تولید» انجام شود.

یک سیستم ارزیابی مناسب می تواند شامل چند گروه باشد:

شاخص های جریان

• Lead Time
• Cycle Time
• WIP
• Throughput
• Flow Efficiency

شاخص های کیفیت

• Defect Rate
• First Pass Yield
• Rework Rate
• Customer Complaints

شاخص های تحویل

• On-Time Delivery
• Schedule Adherence
• Order Fulfillment Time

شاخص های بهره وری

• Labor Productivity
• OEE
• Setup Time
• Downtime

شاخص های انسانی

• تعداد پیشنهادهای بهبود
• مشارکت کارکنان
• آموزش
• ایمنی
• نرخ حوادث

شاخص های مالی

• هزینه تبدیل
• سرمایه در گردش
• هزینه کیفیت
• هزینه موجودی
• سودآوری

نکته مهم این است که شاخص ها باید به زنجیره علت و معلولی متصل باشند.

۴۰. یک مدل ساده برای فهم منطق TPS