SCM LAB
بازگشت به بینش‌هاراهبرد

چرا اکثر پروژه‌های تحول زنجیره تامین شکست می‌خورند

چرا اکثر پروژه‌های تحول زنجیره تامین شکست می‌خورند

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

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

پیش‌نیاز دوم، آمادگی داده است، نه فناوری. اکثر سازمان‌هایی که پروژه تحول دیجیتال را شروع می‌کنند، فرض می‌کنند داده‌های موجودشان به‌اندازه کافی تمیز و ساختاریافته است تا در سیستم جدید بارگذاری شود. واقعیت معمولاً برعکس است: کدهای کالای تکراری، واحدهای اندازه‌گیری ناهماهنگ، BOMهای قدیمی که هرگز به‌روزرسانی نشده‌اند. اگر این مشکلات قبل از پروژه شناسایی و اصلاح نشوند، سیستم جدید فقط همان بی‌نظمی قدیمی را با سرعت بیشتر تکرار می‌کند.

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

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

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

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

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

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