چرا کارکنان از نرم‌افزار جدید استفاده نمی‌کنند

تیم آرادتیم مهندسی

سامانه تحویل شده، تست‌ها را گذرانده، آموزش هم برگزار شده. سه ماه بعد نصف کاربران هنوز اکسل خودشان را دارند و بخشی از داده اصلاً وارد سامانه نمی‌شود.

از نظر فنی هیچ اشکالی نیست. از نظر سازمانی، پروژه شکست خورده.

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

مقاومت معمولاً منطقی است

اولین اشتباه مدیران، تفسیر مقاومت به‌عنوان تنبلی یا ترس از تکنولوژی است.

تقریباً همیشه دلیل واقعی‌تری هست:

سامانهٔ جدید کار او را سخت‌تر کرده. کاری که قبلاً با یک عدد در اکسل انجام می‌شد، حالا هفت کلیک و سه فیلد اجباری دارد. از نظر سازمان بهتر است؛ از نظر او بدتر. و او درست می‌گوید.

نفعش را نمی‌بیند. داده‌ای که او وارد می‌کند به درد گزارش مدیریت می‌خورد، نه به درد خودش. یعنی هزینه‌اش را او می‌دهد و سودش را کس دیگری می‌برد.

می‌ترسد. سامانه‌ای که کارش را قابل اندازه‌گیری می‌کند، ممکن است نشان دهد کند است، یا اشتباه می‌کند، یا اصلاً لازم نیست. این ترس واقعی است و نادیده‌گرفتنش کمکی نمی‌کند.

قبلاً سوخته. سازمانی که سه سامانهٔ رهاشده در کارنامه دارد، کارمندی دارد که یاد گرفته صبر کند تا این هم برود.

راه دور زدنش باز است. اگر می‌شود همان کار را با اکسل هم انجام داد و کسی جلویش را نمی‌گیرد، بخشی از تیم همان کار را می‌کند.

کاری که پیش از راه‌اندازی باید انجام شود

بیشتر تلاش‌های «مدیریت تغییر» بعد از تحویل شروع می‌شوند و همان‌جا دیر است.

کاربر را در انتخاب و طراحی شریک کنید

نه به‌عنوان تشریفات. یعنی کسی که هر روز کار می‌کند، پیش از قطعی‌شدن، سامانه را ببیند و نظرش اثر بگذارد.

این هم اطلاعات می‌دهد — کاربر واقعی استثناهای فرایند را می‌داند که هیچ سندی ندارد — و هم مالکیت می‌سازد. آدمی که در ساختن چیزی نقش داشته، از آن دفاع می‌کند.

فرایند را ساده کنید، نه اینکه فقط دیجیتالش کنید

اگر فرایند فعلی هفت مرحله دارد و شما همان هفت مرحله را در سامانه می‌گذارید، هیچ‌کس ذوق نمی‌کند.

بهترین لحظه برای حذف مراحل زائد، همان لحظهٔ ساخت سامانه است. بعد از آن، هر تغییری هزینهٔ فنی دارد.

برای کاربر هم چیزی در آن بگذارید

این تنها مؤثرترین اقدام در کل این حوزه است، و ساده‌ترین.

اگر سامانه فقط داده می‌گیرد، کاربر آن را باری می‌بیند. اگر چیزی هم پس بدهد، هم‌پیمان می‌شود:

  • گزارش عملکرد خودش، پیش از آنکه مدیر ببیند.
  • حذف کاری که قبلاً دستی می‌کرد — پر شدن خودکار فیلدها، محاسبهٔ خودکار.
  • دسترسی سریع به اطلاعاتی که قبلاً باید می‌پرسید.
  • پایان دوباره‌کاری: داده‌ای که یک بار وارد می‌شود و دیگر جای دیگری تایپ نمی‌شود.

آن مورد آخر معمولاً بزرگ‌ترین برگ برنده است و مستقیماً از یکپارچه‌سازی می‌آید.

مسیر قدیمی را ببندید — با تاریخ اعلام‌شده

تا وقتی هر دو راه باز است، بخشی از تیم راه قدیمی را می‌رود. این نه لجبازی است نه بدخواهی؛ راه آشناتر همیشه کم‌هزینه‌تر به نظر می‌رسد.

پس تاریخ پایان مسیر قدیمی را از قبل اعلام کنید و در آن تاریخ ببندیدش. اما فقط وقتی سامانهٔ جدید واقعاً کار می‌کند — بستن مسیر قدیمی روی سامانه‌ای که آماده نیست، اعتماد را برای همیشه از بین می‌برد.

آموزش، آن‌طور که جواب می‌دهد

جلسهٔ آموزش دوساعتهٔ عمومی برای همه، تقریباً بی‌فایده است. آنچه در پروژه‌ها جواب داده:

کوتاه و بر اساس نقش. انباردار لازم نیست ماژول مالی را یاد بگیرد. بیست دقیقه دربارهٔ همان کاری که خودش می‌کند، از دو ساعت دربارهٔ همه‌چیز بهتر است.

در زمان استفاده، نه یک ماه قبل. آموزشی که سه هفته پیش از راه‌اندازی برگزار شود، فراموش می‌شود.

ویدیوی کوتاه به‌جای جزوه. کاربر سازمانی متن نمی‌خواند؛ می‌خواهد ببیند چه کلیک می‌شود. سه دقیقه به ازای هر کار متداول.

راهنمای درون‌سامانه‌ای. بهترین آموزش آن است که در لحظهٔ نیاز و در خود صفحه باشد.

و مهم‌تر از همه: چند کاربر کلیدی را زودتر آموزش دهید. آدم‌هایی که همکارانشان از آنها می‌پرسند. یک نفر باتجربه در هر واحد، از هر پشتیبانی مرکزی مؤثرتر است — چون در دسترس است و پرسیدن از او هزینهٔ اجتماعی ندارد.

هفتهٔ اول، تعیین‌کننده‌ترین هفته

اعتماد به سامانه در همان هفتهٔ اول ساخته یا خراب می‌شود.

پشتیبانی متراکم بگذارید. کسی که در دسترس باشد و سریع جواب بدهد. باگی که در روز دوم دو ساعته رفع شود، اعتماد می‌سازد؛ همان باگ اگر یک هفته بماند، داستانی می‌شود که یک سال تعریف می‌شود.

بازخورد را جدی و قابل مشاهده پاسخ دهید. وقتی کاربری پیشنهادی می‌دهد و هفتهٔ بعد می‌بیند اعمال شده، رفتار کل واحد عوض می‌شود.

اولین موفقیت را اعلام کنید. «گزارش ماهانه که دو روز طول می‌کشید، این ماه ده دقیقه‌ای آماده شد.» عدد، از هر بخشنامه‌ای مؤثرتر است.

نقش مدیر، که قابل واگذاری نیست

دو چیز که فقط مدیر می‌تواند انجام دهد:

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

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

چطور بفهمیم کار می‌کند

نه با نظرسنجی رضایت. با این‌ها:

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

اگر سه ماه بعد از راه‌اندازی، سی درصد کاربران فعال نیستند، مشکل آموزش نیست. برگردید به بخش دوم این مقاله: یا سامانه کارشان را سخت‌تر کرده، یا نفعی در آن نمی‌بینند.

هر دو قابل رفع‌اند — ولی نه با بخشنامه.

پروژه یا ایده‌ای دارید؟

متخصصین ما آماده برگزاری یک جلسه مشاوره رایگان هستند.

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

همکاران ما پیام شما را می‌بینند و با شما تماس می‌گیرند.