ERP و تحول سازمان؛ چگونه یک سامانه به تغییر شیوهٔ ادارهٔ کسب‌وکار کمک می‌کند؟
ناشر: شرکت توسعه آتراویژن فردا
ERP زمانی به تحول سازمانی منجر می‌شود که فرایند، داده، اختیار و شاخص‌های مدیریتی را بازطراحی کند؛ نصب نرم‌افزار فقط زیرساخت این تغییر است.
تحول از نرم‌افزار شروع نمی‌شود
سازمان ممکن است سامانه‌ای جدید نصب کند اما همان ثبت‌های تکراری، گزارش‌های دستی و تصمیم‌های جزیره‌ای را ادامه دهد. در این وضعیت ابزار تغییر کرده، ولی روش ادارهٔ سازمان تقریباً ثابت مانده است. تحول زمانی آغاز می‌شود که مسئلهٔ کسب‌وکار، فرایند مطلوب و مسئول نتیجه روشن شوند.
ERP یک بستر مشترک برای پیوند واحدها فراهم می‌کند. سفارش فروش می‌تواند نیاز تأمین و تولید را ایجاد کند، تحویل بر موجودی و درآمد اثر بگذارد و عملکرد واقعی در شاخص مدیریتی دیده شود. ارزش این پیوند به کیفیت تصمیم‌ها و انضباط اجرایی وابسته است.
چهار محور تغییر سازمانی
تحول ERP را می‌توان در چهار محور دید: فرایندهای انتها‌به‌انتها، دادهٔ مشترک، نقش و اختیار و نظام سنجش. اگر یکی از این محورها نادیده گرفته شود، بخش دیگری آسیب می‌بیند؛ برای مثال گردش‌کار دقیق بدون مالک داده، اطلاعات نامعتبر را منظم‌تر جابه‌جا می‌کند.
مدیران باید تعارض میان بهینه‌سازی یک واحد و نتیجهٔ کل سازمان را حل کنند. هدف واحد خرید ممکن است کمینه‌کردن قیمت باشد، اما نتیجهٔ سازمان به کیفیت، زمان تحویل، موجودی و توقف تولید نیز وابسته است. ERP این روابط را قابل مشاهده می‌کند؛ تصمیم نهایی همچنان مسئول مدیریتی می‌خواهد.
| محور | پرسش تحول | خروجی مورد انتظار |
|---|---|---|
| فرایند | کار از ابتدا تا نتیجه چگونه جریان دارد؟ | حذف وقفه و ثبت تکراری |
| داده | تعریف معتبر و مالک اطلاعات کیست؟ | مرجع مشترک و مغایرت کمتر |
| نقش و اختیار | چه کسی تصمیم می‌گیرد و پاسخ‌گوست؟ | کنترل روشن و ارجاع سریع |
| سنجش | نتیجه با چه شاخصی دیده می‌شود؟ | تصمیم مبتنی بر خط مبنا و هدف |
بازطراحی پیش از پیکربندی
شناخت وضع موجود برای کشف علت‌هاست، نه انتقال همهٔ عادت‌های موجود به سامانهٔ جدید. تیم مشترک باید فعالیت‌های بدون ارزش، کنترل‌های تکراری، مسیرهای مبهم تأیید و فایل‌های شخصی را شناسایی کند. سپس وضع مطلوب با توجه به کنترل داخلی و قابلیت اجرا طراحی می‌شود.
هر تفاوت با الگوی محصول الزاماً نیازمند توسعه نیست. ابتدا پیکربندی، اصلاح فرایند یا استفاده از قابلیت آماده بررسی می‌شود. توسعهٔ اختصاصی زمانی توجیه دارد که نیاز مشخص، ارزش قابل توضیح، معیار پذیرش و مسئول نگهداری داشته باشد.
مدیریت تغییر و مشارکت کاربران
مقاومت ممکن است از ابهام نقش، افزایش موقت حجم کار، نگرانی دربارهٔ شفافیت یا تجربهٔ ناموفق گذشته ناشی شود. پیام عمومی دربارهٔ مزایای ERP جای گفت‌وگوی مشخص با هر نقش را نمی‌گیرد. کاربر باید بداند چه چیزی تغییر می‌کند، چرا و در صورت بروز مسئله از چه مسیری کمک می‌گیرد.
کاربران کلیدی باید در تحلیل، طراحی، آزمون و آموزش مشارکت کنند. این مشارکت فقط برای پذیرش نیست؛ دانش استثناهای واقعی را وارد طراحی می‌کند. حامی اجرایی نیز باید تصمیم‌های بین‌واحدی را به‌موقع بگیرد و زمان مشارکت تیم را به رسمیت بشناسد.
تحول بعد از Go-Live ادامه دارد
راه‌اندازی نقطهٔ شروع بهره‌برداری است. در هفته‌ها و ماه‌های بعد، کیفیت داده، مسیرهای دورزدن سیستم، زمان انجام کار و درخواست‌های تغییر باید بررسی شوند. تفکیک خطا، نیاز آموزشی و درخواست جدید به اولویت‌بندی درست کمک می‌کند.
کمیتهٔ راهبری محصول باید تغییرها را بر اساس ارزش سازمانی و اثر بین‌ماژولی بررسی کند. اگر هر واحد به‌تنهایی راه‌حل جانبی بسازد، یکپارچگی به‌تدریج از بین می‌رود. نقشهٔ بهبود مستمر، تحول را از پروژه‌ای موقت به توانمندی سازمان تبدیل می‌کند.
چگونه نتیجهٔ تحول را بسنجیم؟
شاخص باید به مسئلهٔ اولیه متصل باشد: زمان چرخهٔ خرید، مدت بستن حساب‌ها، تعداد مغایرت‌های باز، دقت موجودی، تحقق برنامه یا زمان پاسخ‌گویی نمونه‌هایی از معیارهای قابل بررسی‌اند. برای هر شاخص، تعریف، منبع، خط مبنا، هدف، دورهٔ سنجش و مالک لازم است.
تعداد کاربران یا تراکنش‌ها به‌تنهایی موفقیت را نشان نمی‌دهد. ممکن است استفاده زیاد باشد ولی فرایند همچنان ناکارآمد بماند. ترکیب شاخص نتیجه، کیفیت داده و پذیرش نقش‌ها تصویر واقع‌بینانه‌تری از تحول سازمانی ایجاد می‌کند.
منابع و مبنای مقاله
مبنای داخلی: متدولوژی استقرار آتراویژن، طراحی وضع مطلوب، مدیریت تغییر، آموزش و تثبیت پس از راه‌اندازی. برای آشنایی عمومی با نقش ERP در تحول، راهنمای ERP شرکت SAP را ببینید.
شاخص‌ها و الگوهای مقاله پیشنهادی‌اند و باید با خط مبنا و اولویت‌های هر سازمان تطبیق داده شوند.