شنبه صبح MRP را اجرا می‌کنید و تا ظهر یکشنبه برنامه‌ریزها بخش زیادی از برنامه را عوض کرده‌اند: تاریخ‌ها جابه‌جا شده، مقدارها بالا رفته و سفارش‌ها از یک ماشین به ماشین دیگر رفته‌اند. بیشتر شرکت‌ها این تغییرات دستی را نویز می‌بینند، یا نشانهٔ این‌که برنامه‌ریز به سیستم اعتماد ندارد. من آن‌ها را صادقانه‌ترین داده‌ای می‌دانم که یک کارخانه دربارهٔ اختلاف برنامه و کف کارگاه دارد.
در ۲۴ سال کار در تولید، کمتر برنامه‌ریزی دیده‌ام که برای سرگرمی برنامهٔ ERP را دستی عوض کند. هر تغییر دلیلی دارد: پرسی که آن ترتیب را نمی‌تواند اجرا کند، ماده‌ای که در سیستم هست ولی در قفسه نیست، درصد ضایعاتی که همه می‌دانند جز BOM. مشکل این است که این دانش در ذهن برنامه‌ریز و در یک فایل اکسل شخصی می‌ماند. وقتی برنامه‌ریز به مرخصی می‌رود، کارخانه آن را از دست می‌دهد و دادهٔ مرجع هیچ‌وقت چیزی یاد نمی‌گیرد.
در ادامه یک روش ساده آورده‌ام برای این‌که تغییرات دستی را چهار هفته ثبت کنید و آن‌ها را مثل فهرستی از اصلاحات بخوانید. کارخانه، سفارش‌ها و همهٔ عددهای این مقاله فرضی‌اند، نه دادهٔ یک شرکت واقعی.
نمونهٔ فرضی
کارخانه‌ای هر هفته MRP اجرا می‌کند و حدود ۴۰۰ سفارش تولید آزاد می‌کند. گلوگاهش خط پرس P2 است. در چهار هفته، این یعنی ۱٬۶۰۰ سفارش برنامه‌ریزی‌شده. برنامه‌ریزها قبول کردند هر سفارشی را که بعد از آزاد شدن برنامه دستی عوض می‌کنند ثبت کنند. در پایان چهار هفته ۲۴۰ تغییر دستی ثبت شده بود؛ یعنی ۱۵٪ برنامه.
قدم ۱: هر تغییر دستی را با دلیلش ثبت کنید
آن را به پنج فیلد محدود کنید تا ثبت هر تغییر حدود ۲۰ ثانیه طول بکشد:
- شمارهٔ سفارش و مرکز کاری.
- چه چیزی عوض شد: تاریخ، مقدار، ترتیب یا ماشین.
- از چه به چه (مثلاً از ۱۲ مهر به ۱۵ مهر، یا از P2 به P3).
- یک دلیل از یک فهرست کد کوتاه (پنج یا شش کد کافی است)، به‌اضافهٔ «سایر» با یک یادداشت.
- چه کسی آن را عوض کرد.
اگر ERP شما همین حالا تاریخچهٔ تغییرات را نگه می‌دارد، از همان استفاده کنید، اما دلیل را به آن اضافه کنید. تاریخچهٔ تغییرات می‌گوید چه چیزی عوض شد؛ فقط برنامه‌ریز می‌تواند بگوید چرا. با ۲۰ ثانیه برای هر مورد، ۲۴۰ تغییر در چهار هفته حدود ۸۰ دقیقه از وقت تیم را می‌گیرد.
قدم ۲: صریح بگویید که این ارزیابی عملکرد نیست
اگر برنامه‌ریزها فکر کنند این ثبت علیه خودشان استفاده می‌شود، دیگر تغییرات را روی کاغذ ثبت نمی‌کنند و همان کار را تلفنی ادامه می‌دهند. برای همین از اول به آن‌ها می‌گویم: هدف، صفر شدن تغییرات دستی نیست. هدف این است که هیچ‌کس مجبور نباشد یک تغییر تکراری را هر هفته دوباره انجام دهد.
قدم ۳: بر اساس دلیل و مرکز کاری گروه‌بندی کنید
| دلیل (فرضی) | تعداد | سهم | معمولاً نشانهٔ چیست |
|---|---|---|---|
| تغییر ترتیب در پرس گلوگاه برای کنار هم گذاشتن ستاپ‌ها | ۸۴ | ۳۵٪ | قواعد ترتیب و زمان ستاپ که ERP آن‌ها را نمی‌شناسد |
| بالا بردن مقدار (اضافه کردن قطعه) | ۴۸ | ۲۰٪ | ضریب ضایعات پایین در BOM |
| عقب انداختن شروع: مواد واقعاً موجود نیست | ۴۲ | ۱۷٫۵٪ | دقت موجودی یا زمان تأمین در دادهٔ مرجع کالا |
| انتقال به ماشین دیگر | ۳۶ | ۱۵٪ | نبودِ مسیر تولید جایگزین در دادهٔ مرجع |
| سفارش فوری از طرف فروش | ۳۰ | ۱۲٫۵٪ | نبودِ دورهٔ منجمد یا قاعدهٔ اولویت (مسئلهٔ تصمیم‌گیری، نه داده) |
| جمع | ۲۴۰ | ۱۰۰٪ |
چند ردیف «سایر» با خواندن یادداشت‌ها دوباره کدگذاری شدند، برای همین جدول پنج گروه دارد. دو نکته به چشم می‌آید. اول، ۱۶۴ مورد از ۲۴۰ تغییر، یعنی حدود دو سوم، به پرس گلوگاه P2 مربوط بوده است. برنامه‌ریزها گلوگاه را دستی محافظت می‌کردند؛ دقیقاً همان کاری که باید بکنند، اما سیستم از آن خبر ندارد. دوم، فقط ۳۰ تغییر، یعنی یک مورد از هر هشت، از اولویت‌های فروش آمده است. ۲۱۰ مورد دیگر به دادهٔ مرجع یا قاعده‌هایی اشاره می‌کنند که ERP اصلاً ندارد.
قدم ۴: هر گروه را مثل یک سؤال بخوانید
تغییر ترتیب در گلوگاه (۸۴). ERP پرس P2 را طوری برنامه‌ریزی می‌کند که انگار همهٔ ستاپ‌ها یک اندازه طول می‌کشند. در واقعیت، رفتن از ورق نازک به ورق ضخیم سریع است و برگشتن کند، پس برنامه‌ریزها سفارش‌ها را دستی کنار هم می‌گذارند. یا یک ماتریس سادهٔ زمان ستاپ را وارد قواعد زمان‌بندی کنید، یا ترتیب‌دهی را کار برنامه‌ریز بدانید و دیگر آن را خطا حساب نکنید. هر دو قابل قبول است؛ نادیده گرفتنش نه.
بالا بردن مقدار (۴۸). ضریب ضایعات در BOM ۲٪ است، اما ضایعات واقعی این قطعه‌ها حدود ۶٪ است. برای سفارش ۵۰۰ قطعهٔ سالم، سیستم ۵۱۰ قطعه شروع می‌کند که فقط حدود ۴۷۹ قطعهٔ سالم می‌دهد (۵۱۰ × ۰٫۹۴). برنامه‌ریزی که این را می‌داند عدد را به ۵۳۲ می‌رساند (۵۰۰ ÷ ۰٫۹۴ ≈ ۵۳۲). جای این اصلاح در دادهٔ مرجع است، نه در حافظهٔ برنامه‌ریز.
مواد واقعاً موجود نیست (۴۲). یا عدد موجودی غلط است، یا زمان تأمین در دادهٔ مرجع کالا خیلی کوتاه ثبت شده است. در این مثال سیستم ۱۰ روز کاری می‌گوید، در حالی که ۲۰ تحویل آخر به‌طور میانگین ۱۶ روز طول کشیده‌اند. هر سفارشی که با ۱۰ روز برنامه‌ریزی شود، دستی جابه‌جا خواهد شد.
انتقال به ماشین دیگر (۳۶). مسیر تولید فقط یک ماشین دارد، پس هر وقت P2 پر است، برنامه‌ریز کار را بیرون از سیستم به P3 می‌برد. اضافه کردن مسیر جایگزین، یک راه‌حل موقت هفتگی را به یک گزینهٔ عادی برنامه‌ریزی تبدیل می‌کند.
سفارش فوری (۳۰). این مشکل داده نیست؛ یک قاعدهٔ گم‌شده است: دوره‌ای منجمد که در آن برنامه بدون تصمیم مشخصِ یک فرد مشخص عوض نمی‌شود. اینجا طرف گفت‌وگو فروش است، نه تیم ERP.
قدم ۵: یک دلیل را اصلاح کنید و تعدادش را زیر نظر بگیرید
گروهی را انتخاب کنید که اصلاحش ارزان‌تر است و به گلوگاه مربوط است. در نمونهٔ فرضی، آن گروه ضریب ضایعات بود: اصلاحش روی ۱۲ قطعه‌ای که بیشتر تغییرات مقدار به آن‌ها مربوط بود، دو روز از وقت مهندسی فرایند را گرفت. در چهار هفتهٔ بعد، تغییرات مقدار از ۴۸ به ۱۵ رسید. بعد سراغ گروه بعدی بروید.
یک عدد که باید نگه دارید: نرخ تغییر دستی
نرخ تغییر دستی = سفارش‌هایی که بعد از آزاد شدن برنامه دستی عوض شده‌اند ÷ کل سفارش‌های برنامه. در این مثال ۲۴۰ ÷ ۱٬۶۰۰ = ۱۵٪. آن را هر هفته و به تفکیک کد دلیل دنبال کنید و برای هر دلیل یک مسئول بگذارید: ضریب ضایعات و مسیرهای تولید با مهندسی فرایند، زمان‌های تأمین با خرید، ترتیب‌دهی با برنامه‌ریزی، و دورهٔ منجمد با برنامه‌ریزی و فروش با هم. تعریفش را یک بار در دیکشنری KPI بنویسید تا بعداً کسی بحث نکند که چه چیزی تغییر دستی حساب می‌شود.
اگر در کارخانهٔ شما مشکل بزرگ‌تر مالکیت دادهٔ مرجع است، در مالکیت دادهٔ مرجع قبل از یکپارچه‌سازی ERP–MES درباره‌اش نوشته‌ام. و اگر هنوز مطمئن نیستید گلوگاهتان کجاست، از پیدا کردن و باز کردن گلوگاه تولید با داده شروع کنید.
چک‌لیست قبل از شروع ثبت تغییرات دستی
- یک فهرست کوتاه از دلیل‌ها که با برنامه‌ریزها توافق شده، به‌اضافهٔ «سایر».
- پنج فیلد برای هر تغییر، حدود ۲۰ ثانیه برای هر مورد.
- به برنامه‌ریزها صریح گفته شده که این ارزیابی عملکرد نیست.
- چهار هفته ثبت، قبل از هر نتیجه‌گیری.
- تغییرات بر اساس دلیل و مرکز کاری گروه‌بندی شده و گلوگاه مشخص شده است.
- هر دلیل به یک سؤال دربارهٔ دادهٔ مرجع یا یک قاعده تبدیل شده و یک مسئول دارد.
- هر بار یک اصلاح، و زیر نظر گرفتن تعداد همان دلیل در چهار هفتهٔ بعد.
می‌خواهید تغییرات دستی خودتان را بررسی کنیم؟
چهار هفته تغییرات برنامه را برایم بفرستید؛ از تاریخچهٔ تغییرات ERP یا حتی فایل اکسل برنامه‌ریزها، با شمارهٔ سفارش‌های بی‌نام. می‌توانیم با هم گروه‌بندی‌شان کنیم، ببینیم چندتایشان به گلوگاه شما مربوط است، و یک فهرست دلیل و سه اصلاح دادهٔ مرجع را که بهتر است اول انجام شوند برایتان بگذاریم.
تماس با من بخوانید: پیدا کردن گلوگاه بخوانید: دیکشنری KPI
منابع
- منطق گلوگاه بر پایهٔ ایدهٔ تئوری محدودیت‌هاست که کندترین مرحله سرعت کل سیستم را تعیین می‌کند و باید از آن محافظت شود (الیاهو گلدرات، کتاب «هدف»، ۱۹۸۴).
- «دورهٔ منجمد» (frozen zone) و «حصار زمانی برنامه‌ریزی» (planning time fence) طبق تعریف واژه‌نامهٔ ASCM (APICS Dictionary). کارخانه، سفارش‌ها و همهٔ عددهای این مقاله فرضی‌اند.
- مطالعهٔ مرتبط در همین سایت: پیدا کردن گلوگاه تولید با داده، مالکیت دادهٔ مرجع قبل از یکپارچه‌سازی ERP–MES، و دیکشنری KPI.