چارچوب DDIT

بیشتر پروژه‌های ناموفق زنجیره تامین از یک اشتباه مشترک شروع می‌شوند: راه‌حل قبل از تشخیص انتخاب می‌شود. یک مدیر در جایی یک ابزار یا یک روش موفق دیده، و می‌خواهد همان را در سازمان خودش پیاده کند — بدون اینکه بداند مسئله واقعی او همان مسئله‌ای است که آن ابزار حل کرده یا نه.

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

به همین دلیل، تشخیص در SCM LAB همیشه دو لایه دارد: تحلیل کمّی روی داده‌های موجود سازمان، و گفت‌وگوی ساختاریافته با ذی‌نفعان کلیدی — از کارشناس برنامه‌ریزی تا مدیرعامل. خروجی این مرحله یک لیست از «کارهای اشتباه» نیست، بلکه نقشه‌ای از علت‌های ریشه‌ای است که معمولاً دو یا سه لایه عمیق‌تر از علامت‌های ظاهری قرار دارند.

طراحی، جایی است که بیشتر مشاوره‌های عمومی می‌لغزند: یک مدل استاندارد (یک متد MRP، یک چرخه S&OP، یک سیاست موجودی) را از یک پروژه قبلی برمی‌دارند و با تغییرات جزئی روی سازمان جدید پیاده می‌کنند. مشکل این است که هر سازمان محدودیت‌های خودش را دارد — سیستم ERP فعلی، سطح بلوغ داده، فرهنگ تصمیم‌گیری، و حتی این‌که چه کسی واقعاً اختیار تغییر فرآیند را دارد.

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

خروجی طراحی همیشه دو بخش دارد: طراحی فرآیند (چه کسی، چه زمانی، با چه ورودی و خروجی، چه تصمیمی می‌گیرد) و طراحی ابزار (چه چیزی این فرآیند را در عمل پشتیبانی می‌کند — از یک قالب اکسل ساده تا یک داشبورد Power BI). هر دو باید هم‌زمان طراحی شوند، چون فرآیند بدون ابزار پشتیبان دوام نمی‌آورد و ابزار بدون فرآیند مشخص، فقط یک فایل بلااستفاده در یک پوشه است.

خیلی از پروژه‌های مشاوره در همین مرحله شکست می‌خورند، نه به این دلیل که طراحی بد بوده، بلکه چون تیم مشاور طراحی را «تحویل داد» و رفت. یک فرآیند جدید یا یک ابزار جدید، در هفته اول همیشه اصطکاک ایجاد می‌کند — افراد عادت قدیم دارند، داده‌ها همیشه تمیز نیستند، و همیشه یک استثنا پیش می‌آید که در طراحی اولیه دیده نشده.

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

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

این مرحله، شاید کم‌دیده‌شده‌ترین بخش کار مشاوره باشد، و دقیقاً به همین دلیل جزو ارکان چارچوب DDIT است. هدف نهایی یک پروژه مشاوره خوب، وابستگی بلندمدت مشتری به مشاور نیست — برعکس، هدف این است که تیم داخلی بتواند فرآیند و ابزار جدید را بدون کمک بیرونی نگه دارد، تنظیم کند و حتی توسعه دهد.

انتقال ظرفیت شامل سه لایه است: مستندسازی (چرا این تصمیم گرفته شد، نه فقط چطور اجرا می‌شود)، آموزش عملی تیم داخلی روی سناریوهای واقعی (نه فقط یک کارگاه تئوریک)، و تعیین یک مالک داخلی مشخص که مسئولیت نگهداری فرآیند را بر عهده می‌گیرد.

در بسیاری از پروژه‌های صنعت غذایی و دارویی که با آن‌ها کار کرده‌ایم، این مرحله شامل یک دوره کوتاه سایه‌به‌سایه (Shadowing) هم هست — کارشناس داخلی، چرخه بعدی را با نظارت غیرمستقیم مشاور خودش اجرا می‌کند. وقتی این چرخه بدون نیاز به دخالت مشاور تکرار شد، پروژه واقعاً تمام شده — نه وقتی گزارش نهایی تحویل داده می‌شود.