مسئله
در شرکت EPC با چندین پروژه همزمان، مدیریت سازمان به پیگیریهای دستی و حافظه افراد وابسته بود؛ اطلاعات وجود داشت اما پراکنده بود و پاسخ به سؤالات سادهای مثل وضعیت هر فرد، هزینه و پیشرفت پروژهها نیازمند تماس با چند نفر بود.
راهکار
بهجای دیجیتالکردن صرف فرآیندها، ERP بهعنوان بستر «حافظه سازمانی» پیادهسازی شد: شکستن پروژه به تسکهای قابل ردیابی، ثبت خودکار زمان (Time Sheet)، حسابداری چندبعدی پروژه-تسک، شفافسازی خرید، ماژول PLM برای طراحی، و سیستم مدیریت عملکرد مبتنی بر داده.
نتیجه
سازمان از تصمیمگیری بر مبنای حدس به تصمیمگیری مبتنی بر داده رسید؛ وابستگی به افراد کلیدی کاهش یافت و سوابق پروژهها، زمانها، هزینهها و طراحیها به بانک تجربهای تبدیل شد که پروژههای بعدی را سریعتر، دقیقتر و کمخطاتر میکند.
وقتی چند پروژه همزمان در حرکتاند، دیگر نمیتوان سازمان را با حافظه افراد مدیریت کرد
در یکی از پروژههای استقرار ERP، با شرکتی در حوزه EPC و طراحی و تولید تجهیزات و خطوط تولید صنعتی مواجه شدیم؛ سازمانی که همزمان چندین پروژه را پیش میبرد و هر پروژه از بخشهای مختلف طراحی، مهندسی، تولید، خرید، تأمین، انبار و اجرا تشکیل میشد.
در ظاهر، مسئله فقط «نبود یک نرمافزار یکپارچه» بود؛ اما با ورود به سازمان مشخص شد مسئله عمیقتر است. چندین پروژه بهصورت همزمان در جریان بود، افراد در پروژههای مختلف فعالیت میکردند و هر بخش اطلاعات خود را به شیوهای متفاوت مدیریت میکرد. در نتیجه، مدیریت برای پاسخ به سؤالهای ساده اما حیاتی، اغلب مجبور بود از افراد مختلف پیگیری کند:
- هر فرد الان روی چه کاری است و چقدر زمان صرف کرده؟
- هر پروژه چقدر هزینه داشته و چقدر با بودجه فاصله دارد؟
- یک طراحی در چه مرحلهای است و منتظر چه کسی مانده؟
- مسئول هر فعالیت چه کسی است؟
- اگر یکی از افراد کلیدی سازمان نباشد، آیا فرآیند همچنان ادامه پیدا میکند؟
اطلاعات وجود داشت، اما به دانش قابل استفاده برای تصمیمگیری تبدیل نشده بود. بخش قابلتوجهی از تجربه، پیگیریها و حتی علت تصمیمها در ذهن افراد قرار داشت، نه در یک ساختار مشخص سازمانی.
بنابراین، رویکرد ما فقط پیادهسازی فرآیندهای موجود در ERP نبود. سؤال اصلی این بود:
چطور میتوانیم سازمانی را که بخش قابلتوجهی از مدیریت آن به افراد، پیگیریهای دستی و اطلاعات پراکنده وابسته است، به سازمانی تبدیل کنیم که بتواند با داده، فرآیند و اطلاعات یکپارچه تصمیم بگیرد؟
وقتی یک نفر همزمان در چند پروژه کار میکند، «الان مشغول چه کاری است؟» یک سؤال ساده نیست
یکی از اولین چالشها، مدیریت پروژه و منابع انسانی درگیر در پروژهها بود. افراد میتوانستند همزمان روی چند پروژه و تسک فعالیت کنند؛ بنابراین، صرفاً داشتن برنامه پروژه کافی نبود و باید مشخص میشد هر فرد روی چه کاری است، هر تسک چه زمانی باید انجام شود و چه مقدار زمان برای آن صرف شده است.
ساختار پروژهها در سیستم به شکل پروژه، زیرپروژه و تسک طراحی شد و ارتباط میان آنها مشخص گردید. در نتیجه، پروژه دیگر یک عنوان کلی نبود، بلکه به مجموعهای از فعالیتهای قابلاندازهگیری تبدیل شد. درصد پیشرفت نیز بر اساس وضعیت واقعی فعالیتهای زیرمجموعه تعریف شد تا پیشرفت پروژه صرفاً یک عدد اعلامشده توسط افراد نباشد.
در کنار آن، مدیریت نیاز داشت پیشرفت پروژه را در لحظه ببیند؛ نه اینکه در پایان یک بازه زمانی، گزارشی دریافت کند که اطلاعات آن مربوط به روزها یا هفتههای قبل است.
هر تسک یک ردپا شد؛ از «چه کسی انجام داد؟» تا «چقدر زمان صرف شد؟»
گام بعدی، ایجاد ساختار مشخص برای ثبت زمان فعالیتها بود. با طراحی فرآیند Time Sheet، زمان صرفشده برای تسکها ثبت شد و حدود ۷۰ درصد فرآیند اعتبارسنجی تایمشیتها بهصورت خودکار انجام گرفت و تنها تأیید مدیر بالاسری باقی ماند.
این دادهها فقط برای ثبت زمان نبودند و امکان پاسخ به سؤالهای مختلف مدیریتی را فراهم کردند:
- چه کسی روی پروژه کار کرده است؟
- چه کاری انجام داده و چقدر زمان صرف کرده است؟
- پروژه چه میزان منابع انسانی مصرف کرده است؟
- کدام فعالیتها بیشتر از زمان مورد انتظار طول کشیدهاند؟
همزمان، مدیریت تسک به شکل کانبان نیز پیادهسازی شد تا وضعیت فعالیتها و جریان کار برای تیمها قابل مشاهدهتر باشد. به این ترتیب، تسک از یک دستور کاری ساده به یک واحد قابل ردیابی از فعالیت، زمان، منابع و پیشرفت پروژه تبدیل شد.
یک تصمیم مدیریتی؛ محدود کنیم یا شفافتر کنیم؟
در ادامه پروژه، مدیریت میخواست دقیقاً بداند هر فرد روی چه تسکی کار میکند و چرا. راهکار اولیه این بود که امکان ایجاد پروژه و تسک محدود شود و صرفاً مدیر پروژه این دسترسی را داشته باشد.
اما بررسی فرآیند نشان داد این محدودیت میتواند خودش به یک گلوگاه تبدیل شود. اگر هر تسک برای ایجاد شدن نیازمند عبور از یک نفر باشد، سازمان بهجای کاهش وابستگی به افراد، ممکن است به مدیر پروژه وابستگی جدیدی پیدا کند.
بنابراین، پیشنهاد ما این بود که بهصورت آزمایشی، سرپرستان واحدها نیز امکان ایجاد تسک برای افراد مختلف را داشته باشند و کنترل، بهجای محدود کردن فرآیند، از مسیر داشبورد و رهگیری خطاها انجام شود.
کنترل سازمان نباید الزاماً به معنی محدود کردن افراد باشد؛ گاهی شفافیت، کنترل مؤثرتری از محدودیت ایجاد میکند.
این رویکرد کمک کرد سیستم چابک باقی بماند و مدیر پروژه نیز بهجای درگیر شدن با ایجاد و پیگیری تکتک تسکها، روی تصمیمها و فعالیتهای مهمتر تمرکز کند.
هزینههایی که دیر دیده شوند، میتوانند پروژه را زمین بزنند
یکی از جدیترین مشکلات سازمان، مدیریت هزینه پروژهها بود. تعدد پروژهها و تنوع مصارف باعث شده بود مدیریت نتواند در لحظه تصویر دقیقی از هزینه واقعی هر پروژه داشته باشد. این هزینهها عمدتاً در سه گروه قرار میگرفتند:
مواد اولیه، نیروی انسانی و خدمات برونسپاریشده.
وقتی هزینهها با تأخیر دیده شوند، ممکن است زمانی متوجه انحراف شوید که اصلاح آن بسیار سخت شده باشد. این مسئله برای سازمان آنقدر جدی شده بود که ادامه این وضعیت، شرکت را تا مرز ورشکستگی پیش برده بود.
بنابراین، مدیریت به چیزی فراتر از یک گزارش مالی نیاز داشت؛ باید میتوانست در حین اجرای پروژه ببیند منابع کجا مصرف شدهاند و پروژه تا چه اندازه در مسیر بودجه حرکت میکند.
وقتی حسابداری از «ثبت هزینه» به «کنترل پروژه» تبدیل شد
برای حل این مسئله، حسابداری چندبعدی در ERP پیادهسازی شد. هزینهها دیگر فقط در سطح کلی حسابداری ثبت نمیشدند و امکان تحلیل آنها در ابعاد مختلف، از جمله پروژه و حتی تسک، فراهم شد.
در نتیجه، رابطه میان فعالیت و هزینه شفافتر شد:
پروژه ← تسک ← مصرف منابع ← هزینه
مدیریت میتوانست بهصورت لحظهای بررسی کند که هر پروژه تا کجا پیش رفته، چه میزان منابع مصرف کرده و چه مقدار هزینه ایجاد کرده است. همچنین امکان مقایسه هزینه واقعی با بودجه فراهم شد تا انحرافها پیش از خارج شدن پروژه از کنترل دیده شوند.
به این ترتیب، حسابداری چندبعدی از یک ابزار صرفاً مالی فراتر رفت و به یکی از ابزارهای اصلی مدیریت و کنترل اقتصادی پروژهها تبدیل شد.
خرید دیگر نباید با «پیگیری افراد» جلو میرفت
در فرآیند خرید و تأمین کالا نیز مشکل مشابهی وجود داشت. برای فهمیدن وضعیت یک درخواست، در بسیاری از مواقع لازم بود از افراد مختلف سؤال شود.
با استقرار ERP، نقش هر فرد در فرآیند مشخص شد و در هر مرحله میتوانستیم ببینیم:
چه کسی مسئول است؟ چه کاری انجام داده؟ چه کاری باید انجام دهد؟ فرآیند اکنون در چه مرحلهای است؟
این تغییر باعث شد فرآیند تأمین کالا سریعتر و قابل پیگیریتر شود؛ اما ارزش مهمتر، چیزی بود که بهمرور شکل گرفت: بانک اطلاعاتی سازمان.
هر خرید، درخواست، اقدام و مرحلهای که در سیستم ثبت میشد، بخشی از حافظه سازمان را تشکیل میداد. اطلاعاتی که قبلاً ممکن بود در ایمیل، فایل، تماس تلفنی یا ذهن افراد باقی بماند، حالا به دادههای ساختاریافته سازمان تبدیل میشد.
وقتی طراحی یک خط تولید با تماس تلفنی مدیریت میشود
پیچیدهترین بخش پروژه، طراحی و مدیریت چرخه عمر محصول بود. محصولات شرکت، تجهیزات و خطوط تولید صنعتی پیچیدهای بودند که متخصصان حوزههای مختلف بهصورت همزمان روی آنها کار میکردند. در روش قبلی، هماهنگی میان این افراد تا حد زیادی از طریق تماس تلفنی و ارتباطات کلامی انجام میشد.
در چنین محیطی، مشخص نبود طراحی دقیقاً در چه مرحلهای است، تأیید آن منتظر چه کسی است، مالک آن چه کسی است، تغییر یک بخش چه اثری بر بخشهای دیگر دارد و کدام نسخه از یک مستند معتبر است.
وقتی محصول پیچیده باشد، نمیتوان هماهنگی پیچیدگی آن را به حافظه افراد سپرد.
محصول به یک درخت تبدیل شد؛ و هر شاخه داستان خودش را داشت
برای حل این مسئله، یک ماژول اختصاصی PLM توسعه داده و در سازمان پیادهسازی کردیم. ساختار طراحی محصول به شکل یک درخت طراحی شکل گرفت و هر Branch میتوانست بهصورت مستقل مدیریت شود؛ در عین حال، وابستگی میان Branchها نیز در سیستم تعریف شد.
این موضوع اهمیت زیادی داشت، زیرا تغییر در یک بخش از محصول ممکن بود روی بخش دیگری اثر بگذارد. بنابراین، فقط ثبت طراحی کافی نبود و باید وابستگیها و اثر تغییرات نیز قابل مشاهده و مدیریت میشد.
فرآیند تأییدات طراحی، وضعیت هر طراحی، فردی که فرآیند منتظر او بود و همچنین تاریخچه مستندات و نسخهبندی آنها در سیستم ثبت شد. در نتیجه، بخشی از دانش مهندسی سازمان از ذهن متخصصان و مکالمات روزمره خارج و به ساختاری قابل ردیابی و قابل استفاده تبدیل شد؛ ساختاری که بعدها میتوانست در تولید و حتی پشتیبانی نیز مورد استفاده قرار گیرد.
هر کاری که انجام میدهیم، فقط یک کار نیست؛ یک داده برای تصمیم بعدی است
یکی از مهمترین تغییرات، ایجاد ارتباط میان بخشهای مختلف سازمان بود. دادهای که در یک بخش تولید میشد، میتوانست در بخش دیگری ارزش ایجاد کند.
زمان ثبتشده برای یک تسک، علاوه بر مدیریت فعالیت، برای مدیریت منابع انسانی و محاسبه هزینه پروژه قابل استفاده بود. هزینه پروژه برای کنترل بودجه ارزش داشت. طراحی ثبتشده در PLM میتوانست بعدها در تولید و پشتیبانی استفاده شود و سوابق خرید نیز بهمرور به بخشی از بانک اطلاعاتی تأمینکنندگان و تجربه سازمان تبدیل میشد.
ERP در این پروژه فقط چند ماژول کنار هم نبود؛ یک زنجیره اطلاعاتی میان فرآیندهای سازمان ایجاد کرد.
اپراتور، کارشناس و مدیر؛ همه بخشی از یک سیستم شفاف شدند
در بخش منابع انسانی نیز همین رویکرد ادامه پیدا کرد. با پیادهسازی سیستم یکپارچه مدیریت عملکرد، ارزیابی عملکرد از یک فرآیند دستی و پراکنده به فرآیندی ساختاریافته و تا حد زیادی خودکار تبدیل شد.
یکی از راهکارهای اجراشده، گیمیفیکیشن ارزیابی عملکرد بود. قوانین امتیازدهی در سیستم تعریف میشدند و بخشی از امتیازها بهصورت خودکار محاسبه میشد؛ برای مثال، انجام یک تسک میتوانست بهصورت خودکار ۵ امتیاز برای فرد ایجاد کند و سرپرست نیز بر اساس کیفیت انجام آن تسک، ۲ امتیاز دیگر اختصاص دهد. در کنار آن، ارزیابی عملکرد ۳۶۰ درجه نیز پیادهسازی شد.
نکته مهم این بود که این سیستم از دادههایی استفاده میکرد که در بخشهای دیگر سازمان تولید شده بودند. وقتی مشخص باشد هر فرد چه تسکهایی انجام داده، چه میزان زمان صرف کرده و چه فعالیتهایی بر عهده داشته است، مدیریت عملکرد دیگر کاملاً وابسته به برداشت شخصی مدیر نخواهد بود.
عملکرد، از یک مفهوم مبهم به موضوعی قابل مشاهده و قابل اندازهگیری نزدیکتر شد.
وابستگی به افراد؛ مشکلی که ERP فقط آن را پنهان نکرد، آشکارش کرد
شاید مهمترین دستاورد این پروژه، فراتر از تمام ماژولها و فرآیندهایی بود که پیادهسازی شدند.
قبل از استقرار، وقتی داده ساختاریافتهای وجود نداشت، گاهی حتی مشخص نبود مشکل دقیقاً چیست و علت آن کجاست. وقتی پروژهای عقب میافتاد، هزینهای افزایش پیدا میکرد، خریدی دیر انجام میشد یا طراحیای متوقف میماند، پیدا کردن علت واقعی همیشه ساده نبود؛ زیرا بخشی از پاسخها در ذهن افراد قرار داشت.
ERP این وابستگی را یکشبه حذف نکرد، اما یک تغییر اساسی ایجاد کرد:
سازمان شروع کرد به دیدن خودش.
فرآیندها ثبت شدند، مسئولیتها مشخص شدند، زمانها و هزینهها قابل ردیابی شدند، طراحیها نسخهبندی شدند، تأییدات قابل پیگیری شدند و فعالیت افراد در ارتباط با پروژهها قابل مشاهده شد.
وقتی این دادهها کنار هم قرار گرفتند، تصمیمگیری نیز میتوانست از «فکر میکنم مشکل اینجاست» به سمت «دادهها نشان میدهند مشکل اینجاست» حرکت کند.
پروژه تمام شد؛ اما چیزی که باقی ماند، مهمتر از خود پروژه بود
یکی از ارزشمندترین خروجیهای این استقرار، اطلاعاتی بود که برای آینده سازمان باقی ماند. پروژههای بعدی دیگر الزاماً از نقطه صفر شروع نمیشدند؛ سوابق پروژهها، زمانهای صرفشده، هزینهها، طراحیها، مستندات، فرآیندهای خرید و عملکرد افراد، بهمرور یک بانک اطلاعاتی از تجربه سازمان ایجاد میکردند.
این اطلاعات میتوانست در پروژههای مشابه آینده کمک کند تا سازمان:
- سریعتر برنامهریزی کند؛
- دقیقتر منابع را تخمین بزند؛
- هزینهها را بهتر پیشبینی کند؛
- خطاهای گذشته را تکرار نکند؛
- وابستگی به افراد کلیدی را کاهش دهد؛
- و تصمیمهای خود را بر اساس تجربه ثبتشده سازمان اتخاذ کند.
در واقع، یکی از مهمترین اتفاقات این پروژه این بود که تجربه افراد کمکم به دانش سازمان تبدیل شد.
از اجرای ERP تا ساختن یک حافظه سازمانی
در پایان این استقرار، مسئله فقط این نبود که شرکت صاحب یک ERP شده است. سازمان توانست برای بخش قابلتوجهی از فعالیتهای خود یک ساختار مشترک ایجاد کند؛ ساختاری که در آن پروژه، تسک، زمان، هزینه، خرید، طراحی، منابع انسانی و اطلاعات محصول میتوانستند در ارتباط با یکدیگر قرار بگیرند.
ما صرفاً فرآیندهای موجود را دیجیتال نکردیم. در بسیاری از نقاط، از فرصت استقرار استفاده کردیم تا درباره خود فرآیندها نیز تصمیم بگیریم:
آیا باید روش قبلی را همانطور که هست وارد نرمافزار کنیم، یا باید از فرصت استقرار برای بهتر کردن خود فرآیند استفاده کنیم؟
ERP برای سازمان به بستری برای شفافیت، کنترل، تصمیمگیری مبتنی بر داده و کاهش وابستگی به افراد تبدیل شد.
و شاید بتوان تمام این تجربه را در یک جمله خلاصه کرد:
ما فقط یک نرمافزار در سازمان مستقر نکردیم؛ تلاش کردیم حافظه سازمان را از ذهن افراد به یک ساختار قابل مشاهده، قابل اندازهگیری و قابل استفاده برای تصمیمهای آینده منتقل کنیم.
جانِ کلام
استقرار موفق ERP زمانی اتفاق میافتد که نرمافزار فقط جایگزین فایلها و روشهای قبلی نشود؛ سازمان باید فرآیندها، مسئولیتها، هزینهها و دانش خود را شفاف ببیند و از دادههای امروز برای تصمیمهای بهتر فردا استفاده کند.