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