«آخر وقت واردش میکنم.» «این قسمت را بلد نیستم.» «باز هم باید همان گزارش اکسل را بفرستم.» این سه جمله فرضی ممکن است برای مدیر یک معنا داشته باشند: کارکنان از CRM استفاده نمیکنند. اما پاسخ مناسب به هرکدام متفاوت است. آموزش بیشتر شاید مشکل مطرحشده در جمله دوم را حل کند، ولی اگر مدیر هنوز گزارش موازی بخواهد، آموزش بهتنهایی دلیل دوبارهکاری را از بین نمیبرد.
برای بررسی استفاده کارکنان از CRM، بهتر است موقتاً برچسب «مقاومت در برابر تغییر» را کنار بگذاریم و ببینیم کار دقیقاً کجا متوقف میشود. در این مقاله، گلایهها را به مسئلههای قابل مشاهده تبدیل میکنیم. مبنا، راهنماهای اجرایی Microsoft و Salesforce، از جمله نوشته مارس ۲۰۲۶ Salesforce درباره اعتماد کارکنان است. این منابع توصیههای حرفهایاند، نه آزمایشهایی که درصد معینی از افزایش بهرهوری را برای هر کسبوکار ثابت کرده باشند. مثال شرکت و پیشنهادهای اجرایی زیر نیز تألیفی و فرضیاند.
بهجای دفاع از نرمافزار، یک نوبت کار را تماشا کنیم
شرکتی فرضی را در نظر بگیرید که تجهیزات نورپردازی مراسم اجاره میدهد. کارشناس باید نیاز مشتری را ثبت کند، موجودی تجهیزات را از انبار بپرسد و نتیجه را برای تأیید قیمت تحویل مدیر بدهد. CRM راه افتاده، اما برخی پروندهها خالی ماندهاند. مدیر میتواند از همین نشانه نتیجه بگیرد که کارکنان همکاری نمیکنند؛ یا از یک کارشناس بخواهد مسیر آخرین درخواست را از آغاز تا پایان نشان دهد.
با تماشای مسیر کار ممکن است معلوم شود کارشناس ثبت اولیه را میداند، ولی هنگام تغییر تاریخ مراسم، راه اصلاح درخواست را پیدا نمیکند. شاید هم فرم، شماره قرارداد را پیش از تأیید قیمت اجباری کرده باشد؛ اطلاعاتی که هنوز وجود ندارد. این دو مانع در گزارش تعداد پروندههای ناقص شبیه هم دیده میشوند، اما یکی به یادگیری مربوط است و دیگری به ترتیب طراحی کار.
کیت لسارد در مقاله رسمی Salesforce در ۲ مارس ۲۰۲۶ درباره اعتماد ذینفعان، مشاهده کار کاربران و شنیدن دشواریهای آنها را پیش از پیشنهاد تنظیمات تازه توصیه میکند. همچنین پیشنهاد میکند پس از تغییر، برای افراد توضیح داده شود چه چیزی عوض شده، چرا اهمیت دارد و چگونه باید از آن استفاده کنند. برای شرکت فرضی ما، کاربرد این توصیه روشن است: ابتدا توقف را ببینیم، سپس راهحل را انتخاب کنیم و بعد نتیجه اصلاح را به همان فرد برگردانیم.
هر گلایه را به صاحب مسئله برسانیم
برای جلسه بررسی، میتوان از سه یادداشت زیر استفاده کرد. این یادداشتها پیشنهادهای همین مقالهاند و امتیاز استاندارد سنجش کارکنان نیستند. در هر مورد، مسئول پیگیری مشخص شده است؛ زیرا همه مانعها در اختیار کاربر نهایی نیستند.
- «نمیدانم از کجا اصلاح کنم»: باید دید کاربر در کدام مرحله راه را گم میکند. مسئول آموزش با همراهی همان کاربر، محل توقف را بررسی کند.
- «فرم اجازه ادامه نمیدهد»: کدام داده یا مجوز در زمان انجام کار موجود نیست؟ مسئول فرایند و مدیر سامانه باید این مانع را با هم بررسی کنند.
- «باید در دو جا بنویسم»: چه کسی خروجی دوم را میخواهد و چرا؟ مدیر واحد درخواستکننده گزارش باید ضرورت و شکل این درخواست را روشن کند.
در مثال اجاره تجهیزات، برداشتن اجبار شماره قرارداد میتواند کار را جلو ببرد، اما حذف بیبررسی همه فیلدهای اجباری هم راهحل نیست. لازم است معلوم شود شماره قرارداد در چه مرحلهای واقعاً ضروری میشود. شاید ثبت آن هنگام تأیید نهایی لازم باشد، نه هنگام دریافت درخواست. مسئول فرایند باید این تصمیم را بگیرد و مسئول سامانه بررسی کند که محصول موجود چگونه میتواند آن را پشتیبانی کند.

اگر مشکل دوبارهنویسی است، از کارشناس نخواهیم بین دستورهای ناسازگار انتخاب کند. فرض کنیم مدیر هر عصر فایل جداگانهای از سفارشهای در انتظار قیمت میخواهد. پیش از حذف فایل، باید بررسی شود آیا گزارش سامانه همان اطلاعات ضروری را در اختیار او میگذارد یا نه. اگر هنوز نمیگذارد، دوره انتقال، مسئول تهیه خروجی و شرط پایان کار موازی روشن شود. وعده مبهم «فعلاً هر دو را پر کنید» نقطه پایان قابل بررسی ندارد.
این بررسی ممکن است نشان دهد بخشی از روش کار باید اصلاح شود، نه اینکه حتماً محصول دیگری بخریم. تفکیک مسئله فرایند از محدودیت ابزار، پیشنیاز تصمیم درباره ادامه یا تغییر سامانه است.
کلاس آموزش وقتی تمام میشود که کار انجام شود
حضور در جلسه، بهتنهایی نشان نمیدهد همکار میتواند درخواست تغییر تاریخ را درست ثبت کند. راهنمای راهبرد آموزش Microsoft Dynamics 365، هدف آموزش را توانایی انجام کار در سامانه جدید میداند و بر هدفهای مشخص و قابل سنجش و ادامه آموزش پس از راهاندازی تأکید میکند. این راهنما در اکتبر ۲۰۲۳ بهروزرسانی شده و در اینجا بهعنوان مرجع پایه استفاده شده است؛ قدمت آن را با تاریخ منابع جدیدتر اشتباه نمیگیریم.
برای کارشناس شرکت فرضی، تمرین مناسب میتواند همین درخواست تغییر تاریخ باشد: پرونده درست را پیدا کند، تغییر را ثبت کند و وضعیت تازه را به فرد مسئول بررسی موجودی برساند. آموزشدهنده نباید از ابتدا به جای او کلیک کند؛ ابتدا فرصت انجام مستقل بدهد، سپس فقط محل توقف را توضیح دهد. در پایان، کارشناس یک مورد مشابه را خودش انجام دهد. نتیجه این تمرین، شاهدی محدود درباره همان کار است و به معنی تسلط بر تمام نرمافزار نیست.
برای مسئول انبار، تمرین متفاوت است؛ او باید درخواستهای مرتبط با موجودی را پیدا کند و پاسخ قابل استفاده بدهد. مجبورکردن همه نقشها به یادگیری همه صفحهها، هدف این تمرین پیشنهادی نیست. بهتر است هر نقش بداند ورودی کارش چیست، تصمیم خودش کدام است و نفر بعدی چه خروجیای انتظار دارد. راهنمای کوتاه همان مسیر نیز باید همراه تغییر فرم یا مسئولیت بهروز شود.
ورود بیشتر به سامانه، پایان بررسی نیست
درس رسمی Salesforce درباره سنجش استفاده کاربران، ورود، ساخت و بهروزرسانی رکورد را نشانههای اولیه معرفی میکند و در کنار آنها کیفیت داده و بازخورد کاربران را بررسی میکند. بنابراین شمار ورود را میتوان سرنخ دانست، اما برای فهمیدن اینکه کار روزانه جا افتاده، باید رفتار مورد انتظار را هم دید. این منبع تاریخ بهروزرسانی آشکاری ندارد و آمار مقایسهای شرکتها ارائه نمیکند.
در شرکت اجاره تجهیزات، پیشنهاد میکنیم پس از اصلاح مانع، چند درخواست عادی و یک درخواست تغییر تاریخ بررسی شوند. آیا اطلاعات لازم در زمان درست ثبت شده؟ آیا مسئول انبار بدون پرسوجوی جداگانه میتواند کار خودش را ادامه دهد؟ آیا مدیر هنوز همان فایل موازی را میخواهد؟ این پرسشها ارزیابی همین مسیر کاریاند؛ نتیجه آنها نباید به افزایش قطعی فروش یا موفقیت همه بخشها تعمیم داده شود.
حتی اگر تعداد ورود بالا رفته باشد، ممکن است کارشناس برای پیدا کردن یک بخش چند بار تلاش کرده باشد. در مقابل، کاربری که وظیفه محدود و مشخصی دارد شاید کمتر وارد شود و همان وظیفه را درست انجام دهد. مقایسه افراد با نقشهای متفاوت بر اساس یک شمارش مشترک، علت توقف را روشن نمیکند. مشاهده پرونده، توضیح کاربر و انتظار واقعی از نقش او باید کنار هم قرار بگیرند.
جلسه بعدی مدیر میتواند با همان سه گلایه آغاز شود، اما این بار پاسخها مشخص باشند: مسیر اصلاح به کارشناس آموزش داده شد؛ زمان دریافت شماره قرارداد تغییر کرد؛ و گزارش موازی تا آمادهشدن خروجی تأییدشده، مسئول و مهلت معلوم دارد. اگر یکی از این موارد هنوز حل نشده، همان را باز نگه داریم. جا افتادن CRM زمانی قابل مشاهده است که ادامه کار برای کارکنان ممکن و روشن شده باشد، نه فقط وقتی فهرست کاربران فعال طولانیتر میشود.
هر دو تصویر، تصویرسازی مفهومی تولیدشده با هوش مصنوعیاند و محیط واقعی یک شرکت یا رابط کاربری محصول مشخصی را نشان نمیدهند.
نظر شما چیست؟