تصور کنید یک شرکت برای حل بینظمیهای داخلی، یک نرمافزار جدید خریداری میکند. مدیر از امکانات سیستم راضی است، داشبوردها مرتباند و گزارشهای زیادی تولید میشود؛ اما چند ماه بعد هنوز کارمندان اطلاعات را در فایلهای قبلی ثبت میکنند، بعضی مراحل را دستی انجام میدهند و برای کارهای مهم به پیامرسانها برمیگردند.
در چنین شرایطی معمولاً گفته میشود «کاربران همکاری نمیکنند». اما این توضیح بیش از حد ساده است. مقاومت کاربر اغلب نشانه یک مشکل عمیقتر در طراحی، آموزش، فرایند یا حتی انتخاب خود نرمافزار است.
نرمافزار برای مدیر خریداری نمیشود؛ برای کاربر استفاده میشود
مدیر ممکن است به گزارشهای دقیق، کنترل بیشتر و دیدن شاخصها اهمیت بدهد. کارمند اما با سؤال دیگری روبهروست: «آیا این سیستم کار روزانه من را سادهتر میکند یا فقط یک مرحله دیگر به کارم اضافه میکند؟» اگر پاسخ سؤال دوم باشد، مقاومت کاملاً قابل پیشبینی است.
یک سیستم موفق باید در لحظهای که کاربر به آن نیاز دارد، سریع و قابل فهم باشد. اگر ثبت یک درخواست در سیستم جدید پنج دقیقه طول بکشد ولی همان کار قبلاً در سی ثانیه با یک روش ساده انجام میشده، صرفاً اضافه کردن قابلیتهای بیشتر مشکل را حل نمیکند.
پنج دلیل رایج شکست Adoption
- فرایند واقعی بررسی نشده است: نرمافزار بر اساس تصور مدیر طراحی شده، نه کاری که کاربر واقعاً انجام میدهد.
- رابط کاربری پیچیده است: کاربر برای انجام یک کار ساده مجبور است از چند صفحه و فرم عبور کند.
- آموزش فقط یک جلسه است: آموزش اولیه بدون مستندات، تمرین و پشتیبانی معمولاً کافی نیست.
- مزیت سیستم برای کاربر مشخص نیست: کاربر فقط وظیفه بیشتری میبیند، نه منفعتی برای خودش.
- سیستم با فرایند سازمان هماهنگ نیست: نرمافزار از سازمان میخواهد خودش را با محصول تطبیق دهد، در حالی که بعضی بخشهای فرایند باید ابتدا بازطراحی شوند.
قبل از تغییر نرمافزار، رفتار کاربران را ببینید
یکی از بهترین روشها این است که به جای پرسیدن «چه قابلیتی میخواهید؟»، از کاربر بخواهید یک کار واقعی را انجام دهد و فقط مشاهده کنید. کجا مکث میکند؟ چه چیزی را دوباره وارد میکند؟ کدام اطلاعات را از جای دیگری کپی میکند؟ چه چیزی را روی کاغذ یا در پیامرسان نگه میدارد؟ همین جزئیات معمولاً بیشتر از یک جلسه طولانی نیازمندیها اطلاعات میدهند.
اگر کاربر برای انجام کارش مجبور باشد با نرمافزار بجنگد، مشکل از کاربر نیست؛ بخشی از مشکل در طراحی سیستم است.
Adoption را چگونه اندازه بگیریم؟
استفاده از سیستم را نباید فقط با تعداد حسابهای ساختهشده سنجید. باید دید چند درصد کاربران فعالاند، چند فرایند واقعاً داخل سیستم انجام میشود، کدام قابلیتها نادیده گرفته میشوند و کاربران برای انجام چه کارهایی هنوز به روشهای قبلی برمیگردند.
گاهی یک سیستم با ده قابلیت پرکاربرد، موفقتر از سیستمی است که صد قابلیت دارد اما کاربران برای انجام کارهای اصلی آن را باز نمیکنند.
راه درست چیست؟
پیش از خرید یا توسعه، کاربران واقعی را وارد فرایند کنید. یک جریان کاری مشخص را انتخاب کنید، نسخه اولیه را با گروه کوچکی آزمایش کنید، بازخورد بگیرید و نقاط اصطکاک را اصلاح کنید. آموزش، مستندسازی و پشتیبانی را نیز بخشی از پروژه بدانید، نه کاری که بعداً باید somehow انجام شود.
هدف نهایی این نیست که کارکنان مجبور شوند از نرمافزار استفاده کنند. هدف این است که نرمافزار آنقدر با کار واقعی هماهنگ باشد که استفاده از آن، انتخاب منطقیتر از روش قبلی باشد.