برنامه‌ریزی تولید / نگاه و تجربهٔ من
برنامهٔ تولید،
باید در کارخانه
جواب بده.
کمک می‌کنم فاصلهٔ بین «چیزی که می‌خوایم تولید کنیم» و «چیزی که واقعاً می‌تونیم بسازیم» روشن بشه؛ از مقدار مواد و موجودی انبار تا ترتیب عملیات و اتفاق‌هایی که حین کار می‌افتن.
مسئله، قبل از نرم‌افزار
سفارش هست.
پس چرا تولید جلو نمی‌ره؟
گاهی مسئله کمبود سفارش نیست؛ مسئله اینه که فروش یک عدد می‌بینه، انبار یک عدد دیگه و واحد تولید با واقعیت سومی روبه‌رو می‌شه.
ممکنه روی کاغذ مواد کافی داشته باشیم، اما بخشی از اون قبلاً به برنامهٔ دیگه‌ای تخصیص پیدا کرده باشه. ممکنه همهٔ قطعات اصلی آماده باشن، ولی یک جزء کوچک یا اقلام بسته‌بندی کار رو متوقف کنن. گاهی هم برنامه ثبت شده، اما معلوم نیست کدوم عملیات انجام شده، چه کسی روش کار کرده یا چرا مقدار نهایی با برنامه فرق داره.
من از همین فاصله‌ها شروع می‌کنم. قبل از اینکه فرم یا داشبوردی بسازم، دنبال اینم که تصمیم تولید الان چطور گرفته می‌شه، اطلاعاتش از کجا میاد و کجا به حدس، تماس تلفنی یا فایل‌های پراکنده وابسته می‌شه. نرم‌افزار وقتی ارزش داره که این ابهام‌ها رو کمتر کنه، نه اینکه فقط ظاهر مرتب‌تری بهشون بده.
عددِ پیشنهادی تولید، هنوز برنامهٔ قابل اجرا نیست؛
باید معلوم باشه به کدوم مواد و محدودیت‌ها تکیه کرده.
از تقاضا تا مقدار قابل ساخت
هر عدد،
باید دلیل داشته باشه.
برای تصمیم دربارهٔ مقدار تولید، فقط موجودی امروز کافی نیست. وضعیت فروش، میانگین تقاضا، نقطهٔ سفارش، موجودی اطمینان و مقدار برنامه‌های در جریان باید کنار هم دیده بشن. محصولی که سریع مصرف می‌شه با محصولی که ماه‌ها در انبار می‌مونه، نباید صرفاً به خاطر موجودی مشابه، پیشنهاد تولید یکسانی بگیره.
در سیستم‌هایی که روشون کار کرده‌ام، این ارتباط بین گزارش‌های موجودی و تصمیم تولید برام مهم بوده: تشخیص موجودی بحرانی، نزدیک‌شدن به نقطهٔ سفارش، موجودی بیش از نیاز و روزهای خواب کالا. حتی وقتی میانگین فروش صفره، نباید با یک تقسیم نامعتبر، گزارش ظاهراً دقیقی بسازیم؛ خودِ این وضعیت نیاز به بررسی داره.
قدم بعدی، فرمول ساخت یا همون BOM هست؛ اینکه هر واحد محصول از چه اجزایی و با چه ضریبی ساخته می‌شه. مقدار قابل ساخت از نظر مواد رو محدودکننده‌ترین جزء تعیین می‌کنه، نه جمع موجودی‌ها. اگر یک قطعه برای چند محصول مشترکه، نمی‌شه موجودی کاملش رو هم‌زمان به همهٔ اون‌ها وعده داد.
به همین خاطر، در طراحی منطق تخصیص، تفاوت بین موجودی، سهم پیشنهادی، مقدار تخصیص‌یافته و مصرف واقعی رو جدی می‌گیرم. این‌ها چهار اسم برای یک عدد نیستن؛ هرکدوم یک معنی عملیاتی دارن و قاطی‌شدنشون می‌تونه برنامه‌ای بسازه که فقط روی صفحه شدنیه.
وقتی مواد مشترکن
یک موجودی،
چند برنامهٔ رقیب.
بخش مهمی از تجربهٔ فنی من، کار روی همین مسئله بوده: وقتی چند محصول به یک ماده یا قطعه وابسته‌ان، چطور مقدار تولید هرکدوم رو پیشنهاد بدیم، بدون اینکه یک موجودی رو چند بار مصرف‌شده فرض کنیم؟ پاسخ همیشه «تقسیم مساوی» یا «اولین درخواست» نیست؛ اولویت تقاضا، برنامه‌های فعال و خطر ایجاد مازاد هم اهمیت دارن.
روی منطق‌هایی کار کرده‌ام که سهم مواد مشترک رو بین محصولات محاسبه می‌کنن و بعد بررسی می‌کنن آیا اون سهم واقعاً به تولید قابل اجرا تبدیل می‌شه یا به خاطر کمبود جزء دیگری، بلااستفاده می‌مونه. سهم محاسباتی یک محصول نباید بی‌دلیل به‌عنوان مصرف واقعی از موجودی کم بشه.
بچ‌های کوچک و ناقص هم مسئلهٔ جداگانه‌ای دارن. گاهی آزادکردن سهم یک برنامهٔ خیلی کوچک می‌تونه گلوگاه یک برنامهٔ مهم‌تر رو باز کنه؛ اما فقط وقتی که واقعاً خروجی قابل ساخت ایجاد کنه، نه اینکه یک برنامهٔ ناقص رو با برنامهٔ ناقص دیگری عوض کنیم. این تصمیم باید با قواعد روشن و قابل بررسی گرفته بشه، نه یک عدد ثابت برای همهٔ کارخانه‌ها.
در ادامه، مازاد مواد هم نباید خودکار به تولید بیشتر تبدیل بشه. منطق تخصیص باید موجودی فعلی محصول، تقاضا و احتمال خواب کالا رو ببینه. هدف این نیست که هر ماده‌ای که داریم به هر قیمتی مصرف بشه؛ هدف اینه که تصمیم تولید با نیاز واقعی کسب‌وکار ارتباط داشته باشه.
دقت، در جزئیاته
یک وزن، یک ضریب،
یک اصلاح کوچک؛
با اثر واقعی روی برنامه.
برای یک محصول، واحد مصرف ممکنه «عدد» باشه و برای دیگری «وزن». ظرفیت بسته، کارتن یا بسته‌بندی تولید هم الزاماً با واحد فروش یکسان نیست. اگر این تفاوت‌ها در محاسبه گم بشن، خروجی سیستم با واقعیت انبار فاصله می‌گیره.
ثبت دقیق اعشار، جمع‌کردن مصرف ردیف‌های تکراری یک جزء، تفکیک قطعهٔ پیدا‌شده از قطعهٔ آسیب‌دیده و محاسبهٔ دوباره بعد از اصلاح مقدار، از جزئیاتی‌ان که در توسعهٔ این سیستم‌ها باهاشون درگیر بوده‌ام. برای من، قابل اعتماد بودن سیستم از همین جا شروع می‌شه.
از محاسبه به کف کارگاه
برنامه، بعد از ثبت
نباید گم بشه.
بعد از مشخص‌شدن مقدار، باید مسیر اجرای کار روشن باشه: محصول چه عملیاتی داره، پیش‌نیاز هر مرحله چیه، مسئول انجامش کیه و چه چیزی برای مرحلهٔ بعد آماده شده؟ در توسعهٔ بخش تولید، روی تعریف عملیات و پیش‌نیازها، ارتباط مواد با عملیات و ثبت نیروهای هر مرحله کار کرده‌ام تا برنامه فقط یک ردیفِ «در حال انجام» نباشه.
زمان شروع و پایان، توضیح اپراتور، ثبت خطا یا دوباره‌کاری و حفظ اطلاعاتِ ثبت‌نشده، بخش‌های کوچکی از تجربهٔ روزمرهٔ کاربرن؛ ولی اگر درست طراحی نشن، اطلاعات اجرا ناقص می‌مونه. سیستم باید به ثبت واقعیت کمک کنه، نه اینکه کاربر برای ردشدن از فرم‌ها اطلاعات غیرواقعی وارد کنه.
در مرحلهٔ شناخت کسب‌وکار، ظرفیت زمانی نیروها و ماشین‌آلات و محدودیت‌های هر خط رو هم بررسی می‌کنیم. این رو از محاسبهٔ موجودی جدا می‌بینم: اینکه موادِ ساخت یک مقدار رو داریم، به معنی امکان تحویل اون مقدار در هر تاریخ دلخواه نیست. سطح زمان‌بندی و ابزار مورد نیاز باید متناسب با مسئلهٔ واقعی شما انتخاب بشه.
برنامه‌ها در عمل عوض می‌شن. کسری مواد، اصلاح فرمول، تغییر اولویت، ضایعات یا مغایرت شمارش باید اثر مشخصی روی مقدار و سهم سایر برنامه‌ها داشته باشن. من دنبال اینم که اصلاح یک تصمیم، حساب‌وکتاب بقیهٔ سیستم رو به‌هم نریزه و بشه فهمید چه چیزی، چرا و توسط چه کسی تغییر کرده.
تولید و انبار، یک گفت‌وگوی مشترک
مواد از کجا کم شد؟
محصول کجا اضافه شد؟
تخصیص مواد، خروج واقعی از انبار و رسید محصول نهایی، سه اتفاق متفاوتن. در بخش‌هایی که توسعه داده‌ام، برای مصرف مواد و ورود محصول، مقدار قبل و بعد، وضعیت ثبت و مسیر برگشت یا اصلاح اهمیت داشته؛ چون دوباره‌ثبت‌شدن یک عملیات یا لغو ناقصش می‌تونه موجودی رو از واقعیت دور کنه.
برای همین، ارتباط تولید با انبار و سامانهٔ مالی رو فقط «ارسال یک عدد» نمی‌بینم. وضعیت انتقال، خطای ثبت، امکان پیگیری و کنترل دوباره باید روشن باشه. اگر ارتباطی ناموفق بود، کاربر باید بدونه چه چیزی انجام شده و چه چیزی هنوز نیاز به رسیدگی داره؛ نه اینکه با تکرار یک دکمه، ناخواسته دو بار اثر موجودی ایجاد کنه.
نحوهٔ همکاری
از یک برنامهٔ واقعی
شروع می‌کنیم.
لازم نیست از روز اول، کل سازمان رو وارد یک پروژهٔ بزرگ کنیم. می‌تونیم یک محصول، یک برنامهٔ تولید و مسیر مواد تا تحویلش رو بررسی کنیم: اطلاعات امروز چطور ثبت می‌شن، کدوم تصمیم‌ها قابل محاسبه‌ان و کجا هنوز به تجربهٔ افراد وابسته‌ایم. همین نمونه، خیلی از ارتباط‌های پنهان رو روشن می‌کنه.
بعد از شناخت مسئله، منطق و ارتباط‌های مورد نیاز رو طراحی می‌کنم و متناسب با شرایط، سیستم موجود رو توسعه می‌دم یا بخش مورد نیاز رو پیاده‌سازی می‌کنم. داده‌های پایه، مسئولیت کاربران، دسترسی‌ها و ارتباط با انبار و مالی هم جزئی از این کارن؛ نه موضوعاتی که قرار باشه بعد از نوشتن نرم‌افزار بهشون فکر کنیم.
انتظار من از خروجی این همکاری، صرفاً یک صفحهٔ جدید نیست. باید بشه یک عدد پیشنهادی رو تا مواد و فرض‌های پشتش دنبال کرد، کسری رو قبل از شروع کار دید، وضعیت اجرا رو فهمید و اثر یک اصلاح رو توضیح داد. اینکه کدوم قابلیت‌ها برای شما اولویت دارن، از بررسی کسب‌وکار خودتون مشخص می‌شه.
من قرار نیست بدون شناخت شرایط شما، وعدهٔ درصد مشخصی از افزایش تولید یا کاهش هزینه بدم. کاری که می‌تونم انجام بدم، تبدیل مسئله‌های واقعی تولید به قواعد روشن، محاسبات قابل بررسی و سیستمیه که تیم شما بتونه در کار روزمره بهش تکیه کنه.
اگر امروز یک برنامهٔ تولید دارید که روی کاغذ شدنیه،
اما در اجرا مدام عوض می‌شه، همون می‌تونه نقطهٔ شروع گفت‌وگوی ما باشه.