چرا پیادهسازی ERP شکست میخورد — و معمولاً تقصیر نرمافزار نیست
وقتی یک پروژهی ERP شکست میخورد، اولین چیزی که متهم میشود نرمافزار است. ولی در تجربهی ما، در بیشتر این پروژهها نرمافزار دقیقاً همان کاری را میکرد که قرار بود بکند. مشکل جای دیگری بود.
۱. کسی مالک پروژه نبود
ERP یک خرید نیست، یک تغییر است. اگر در سازمان یک نفر نباشد که اختیار داشته باشد بگوید «از این به بعد فروش اینطور ثبت میشود»، هر واحد به روش خودش ادامه میدهد و شش ماه بعد سه روایت متفاوت از یک عدد دارید. این نفر لزوماً مدیرعامل نیست، ولی باید پشتش به مدیرعامل گرم باشد.
۲. دادهی قبلی تمیز نشد
انتقال دادهی آشفته به سامانهی تازه، فقط آشفتگی را سریعتر میکند. کدینگ تکراری، کالاهایی با سه نام مختلف، ماندههایی که با دفتر نمیخواند — اینها قبل از انتقال باید حل شوند. یک هفته وقت گذاشتن روی این کار، ماهها بعد برمیگردد.
۳. همهچیز با هم راه افتاد
راهاندازی همزمانِ حسابداری، انبار، تولید، فروش و حقوق در یک روز، یعنی وقتی چیزی خراب شد نمیدانید کجا را نگاه کنید. ترتیبدادن ماژولها — اول مالی و انبار، بعد فروش، بعد تولید — پروژه را کندتر نمیکند؛ فقط شکستهای بزرگ را به اشکالهای کوچکِ قابلحل تبدیل میکند.
۴. آموزش فقط یک بار انجام شد
کلاس روز اول را کسی یادش نمیماند، چون هنوز کاری با سامانه نکرده. آموزش مؤثر دو هفته بعد از شروع کار واقعی است، وقتی کاربر سؤال دارد. برای همین آموزش در فرا داخل خودِ پنل میماند، نه در یک جلسهی یکباره.
۵. سامانهی قبلی خاموش نشد
تا وقتی اکسل قدیمی باز است، بخشی از سازمان در آن کار میکند. تاریخِ خاموشی باید از روز اول مشخص و اعلام شده باشد.
جمعبندی
هیچکدام از این پنج مورد به انتخاب نرمافزار ربط ندارد. اگر اینها حل شده باشند، تقریباً هر ERP جدی جواب میدهد؛ و اگر حل نشده باشند، هیچ ERPای نجاتتان نمیدهد.