چرا بیشتر پروژه‌های ERP شکست می‌خورند؟ آنچه تحقیقات دانشگاهی و یک فاجعه‌ی هفت‌میلیارد‌دلاری به ما می‌گویند

یک آمار نگران‌کننده

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

پژوهشی که در سال ۲۰۰۱ در مجله‌ی Information & Management منتشر شد و به بررسی نظرات مدیران فناوری اطلاعات درباره‌ی پروژه‌های ERP سازمان‌شان پرداخت، نشان داد در حالی که دوسوم پاسخ‌دهندگان، سیستم ERP را استراتژیک‌ترین بستر فناوری سازمان خود می‌دانستند، سه‌چهارم آن‌ها پروژه‌ی خودشان را ناموفق ارزیابی کرده بودند. این پژوهش با تکیه بر همین شکاف بزرگ، دیدگاه «تناسب سازمانی» (organizational fit) را مطرح کرد: ریشه‌ی نرخ بالای شکست، تضاد منافع میان سازمان‌هایی است که راه‌حلی اختصاصی و متناسب با خودشان می‌خواهند و فروشندگان ERP که به‌طور طبیعی به‌دنبال یک راه‌حل عمومی و قابل‌فروش به بازار گسترده هستند.

پژوهش جدیدتری که در سال ۲۰۲۳ منتشر شد، با مرور نظام‌مند ۵۵ مقاله‌ی معتبر منتشرشده بین سال‌های ۲۰۰۰ تا ۲۰۲۲، به شناسایی ۳۵ عامل شکست در پیاده‌سازی ERP رسید و آن‌ها را در قالب هشت دسته‌ی اصلی طبقه‌بندی کرد. نکته‌ی جالب این‌جاست که این عوامل، در کشورها و صنایع مختلف، الگوی مشابهی دارند: حمایت ضعیف مدیریت ارشد، مشارکت ناکافی کاربران نهایی، کیفیت پایین داده، مدیریت پروژه‌ی ضعیف، و عدم همسویی فرایندهای کسب‌وکار با منطق نرم‌افزار.

به بیان ساده: شکست ERP معمولاً یک اتفاق تصادفی یا یک باگ فنی نیست؛ الگویی تکرارشونده و قابل‌پیش‌بینی است. برای نشان دادن این‌که این الگو در عمل چه شکلی دارد، بهتر است سراغ یکی از مستندترین و پرهزینه‌ترین شکست‌های دهه‌ی گذشته برویم: فروپاشی تارگت کانادا.

کیس مطالعاتی: تارگت کانادا (۲۰۱۳-۲۰۱۵)

در سال ۲۰۱۱، غول خرده‌فروشی آمریکایی تارگت، حق اجاره‌ی ۲۲۰ فروشگاه زنجیره‌ی زیرز (Zellers) در کانادا را با ۱.۸ میلیارد دلار کانادا خریداری کرد تا با سرعتی بی‌سابقه وارد بازار کانادا شود. برنامه این بود که تا پایان ۲۰۱۳، بیش از ۱۲۴ فروشگاه باز شود و کسب‌وکار از همان سال اول سودآور باشد؛ هدفی که برای گسترشی در این مقیاس، به‌شدت جاه‌طلبانه بود.

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

نتیجه، دقیقاً همان الگویی بود که تحقیقات دانشگاهی پیش‌بینی می‌کنند:

۱. کیفیت داده و حاکمیت داده (Data Governance) هزاران کد کالا، رکورد تأمین‌کننده و جدول قیمت‌گذاری باید به‌صورت دستی وارد سیستم SAP می‌شد؛ کاری که با عجله و بدون فرایند کنترل کیفیت مناسب انجام شد. ادبیات دانشگاهی حوزه‌ی مدیریت داده‌ی مرجع (Master Data Management) دقیقاً همین ریسک را برجسته می‌کند: داده‌ی نامنظم، تکراری یا ناقص، مستقیماً به تصمیم‌گیری نادرست منجر می‌شود، چون داده‌ی مرجع، مبنای تمام تراکنش‌ها و گزارش‌های سازمان است. طبق برآورد گارتنر که در ادبیات این حوزه بازتاب یافته، کیفیت پایین داده به‌طور میانگین سالانه ۱۵ میلیون دلار به سازمان‌ها خسارت وارد می‌کند؛ رقمی که در مقیاس یک پروژه‌ی ملی مثل تارگت کانادا، به‌سرعت میلیاردی می‌شود. نتیجه‌ی عملی این خطاها، پارادوکسی آشنا برای هر متخصص زنجیره‌ی تأمین بود: انبارها پر از کالا بودند، اما قفسه‌های فروشگاه خالی می‌ماندند؛ چون سیستم بر مبنای داده‌ی غلط، تصمیم‌های تخصیص موجودی می‌گرفت.

۲. مدیریت پروژه و زمان‌بندی غیرواقعی یکی از عوامل شکستی که در اغلب مطالعات موردی تکرار می‌شود، فشرده‌سازی جدول زمانی برای رعایت ددلاین‌های تجاری به‌جای واقعیت فنی پروژه است. تارگت هم‌زمان با پیاده‌سازی ERP، مشغول ساخت سه مرکز توزیع جدید در کمتر از دو سال بود؛ کاری که معمولاً چند سال به‌طول می‌انجامد. این هم‌پوشانی چند پروژه‌ی بزرگ، ظرفیت مدیریتی سازمان را از بین برد.

۳. سکوت سازمانی و ضعف در فرهنگ بازخورد یک ماه پیش از افتتاح بزرگ، مدیران ارشد تارگت کانادا از مشکلات جدی در انتقال کالا، سیستم پرداخت، و درک ناقص کارکنان از فناوری جدید آگاه بودند. برخی از مدیران میانی نسبت به جدول زمانی تردید داشتند، اما هیچ‌کس رسماً درخواست تأخیر نکرد. این الگو دقیقاً همان چیزی است که پژوهش‌های حوزه‌ی «حمایت مدیریت ارشد» (top management support) و «مشارکت کاربر» (user involvement) به‌عنوان عامل حیاتی موفقیت معرفی می‌کنند: صرفِ حضور مدیران ارشد کافی نیست؛ باید کانالی واقعی برای شنیده‌شدن هشدارهای عملیاتی وجود داشته باشد.

نتیجه‌ی نهایی

در ۱۵ ژانویه‌ی ۲۰۱۵، تارگت کانادا رسماً درخواست حمایت ورشکستگی داد. تا آن زمان بیش از هفت میلیارد دلار صرف این گسترش شده بود و شرکت پیش‌بینی نمی‌کرد پیش از سال ۲۰۲۱ به سودآوری برسد. تا آوریل همان سال، تمام ۱۳۳ فروشگاه بسته شدند و حدود ۱۷,۶۰۰ نفر شغل خود را از دست دادند.

نکته‌ی مهم این‌جاست: خودِ SAP «علت» شکست نبود. تحلیل‌های پس از رویداد به‌روشنی نشان می‌دهند که مشکل اصلی، فناوری نبود، بلکه اجرای عجولانه، داده‌ی نامعتبر، و نبود مسیر بازخورد صادقانه بود — همان سه‌گانه‌ای که تحقیقات دانشگاهی سال‌هاست درباره‌شان هشدار می‌دهند.

چه چیزی از این کیس یاد می‌گیریم؟

اگر بخواهیم یافته‌های پراکنده‌ی این حوزه را در چند اصل عملی خلاصه کنیم:

1. داده، قبل از نرم‌افزار. هیچ ERP‌ای نمی‌تواند تصمیم درست بگیرد اگر داده‌ی ورودی‌اش نادرست باشد. حاکمیت داده و پاک‌سازی داده باید ماه‌ها پیش از راه‌اندازی شروع شود، نه هم‌زمان با آن.
2. زمان‌بندی را با واقعیت فنی تطبیق دهید، نه با تقویم بازاریابی. فشار برای «باز شدن به‌موقع فروشگاه‌ها» نباید مبنای تصمیم درباره‌ی طول پروژه‌ی ERP باشد.
3. کانال بازخورد صادقانه بسازید. اگر کارشناسان میانی نگرانی دارند اما جرأت گفتنش را ندارند، سازمان کورکورانه به سمت فاجعه حرکت می‌کند.
4. تناسب سازمانی را جدی بگیرید. همان‌طور که در مطالعات حوزه‌ی «organizational fit» آمده، هرچه فاصله‌ی بین نیازهای واقعی کسب‌وکار و راه‌حل عمومی فروشنده بیشتر باشد، ریسک شکست بالاتر می‌رود؛ این فاصله باید در فاز طراحی، نه در فاز اجرا، شناسایی و مدیریت شود.

جمع‌بندی

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

این تجربه را چرا با شما در میان گذاشتیم؟

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

ما ERP خودمان را دقیقاً برای جلوگیری از این الگو، برای کارخانه‌های کوچک و متوسط طراحی کرده‌ایم:

• هزینه‌ی پیاده‌سازی و نگهداری پایین‌تر نسبت به راهکارهای بین‌المللی
• یکپارچگی بیشتر بین واحدهای تولید، انبار، فروش و مالی از همان روز اول
• زمان استقرار کوتاه‌تر، چون می‌دانیم طولانی‌شدن پروژه، خودش یکی از عوامل اصلی شکست است

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

منابع

• Markus, M.L. & Tanis, C. (بر مبنای بررسی نظرات مدیران IT درباره‌ی موفقیت/شکست پروژه‌های ERP)
• Swan, J. et al. (2001). The critical success factors for ERP implementation: an organizational fit perspective. Information & Management.
• مرور نظام‌مند عوامل شکست پیاده‌سازی ERP (۲۰۰۰–۲۰۲۲)، ۵۵ مقاله‌ی بررسی‌شده، شناسایی ۳۵ عامل شکست.
• مطالعات حوزه‌ی مدیریت داده‌ی مرجع (Master Data Management) و حاکمیت داده در پروژه‌های ERP.
• گزارش‌های تحلیلی و آموزشی درباره‌ی فروپاشی تارگت کانادا (۲۰۱۳–۲۰۱۵)، شامل تحلیل‌های حاکمیتی و مالی این پرونده.