تغییر سازمانی با ارسال یک ایمیل درباره هوش مصنوعی اتفاق نمی افتد

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

ممکن است هر دو گروه بخشی از حقیقت را بگویند. اما پیش از متهم کردن آدم ها، باید ببینیم کار روزانه آنها واقعا تغییر کرده است یا فقط یک ابزار جدید به میز کارشان اضافه شده.

مقاومت همیشه دشمن تغییر نیست

کارمند ممکن است نگران کیفیت پاسخ باشد، از دست دادن اختیار را حس کند یا نداند در صورت اشتباه چه کسی مسئول است. این نگرانی ها الزاما مخالفت با فناوری نیستند. گاهی نشانه آن اند که طراحان پروژه به واقعیت کار نزدیک نشده اند.

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

به جای اعلام تغییر، کار را با کارکنان طراحی کنیم

پیش از اجرا چند نفر از استفاده کنندگان واقعی را وارد طراحی کنید. نه فقط برای نظرسنجی آخر پروژه؛ از زمانی که مسئله را تعریف می کنید. از آنها بخواهید نشان دهند امروز کار را چگونه انجام می دهند، کجا استثنا رخ می دهد و چه چیزهایی در مستندات رسمی نوشته نشده است.

مثلا سامانه ای که به واحد خرید در بررسی قرارداد کمک می کند باید بداند چه زمانی یک بند حقوقی به ارجاع نیاز دارد. این دانش معمولا در ذهن کارشناسان باتجربه است. بدون مشارکت آنها، سیستم ممکن است در آزمون های ساده خوب باشد و در پرونده واقعی باعث دوباره کاری شود.

حمایت مدیر یعنی تغییر دادن رفتار خودش

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

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

اجرای مرحله ای، با معیارهای روشن

یک گروه کوچک اما واقعی را انتخاب کنید؛ نه فقط داوطلبان مشتاق فناوری. پیش از شروع، روش فعلی را اندازه بگیرید. پس از اجرا، زمان، کیفیت، تعداد اصلاح ها و رضایت کاربران را دوباره بسنجید. سپس از کسانی که کمتر استفاده کرده اند دلیل بخواهید. شاید اشکال از آموزش باشد، شاید از داده یا خود ابزار.

اگر نتیجه مناسب بود، شیوه کار را مکتوب کنید و مرحله بعدی را آغاز کنید. اگر نبود، اصلاح کنید یا حتی متوقف شوید. اعلام موفقیت زودهنگام، اعتماد افراد را از بین می برد.

چرا کارکنان به روش قدیمی برمی گردند؟

وقتی ابزاری تازه وارد سازمان می شود، مردم آن را با تجربه واقعی روزانه مقایسه می کنند. اگر سامانه جدید کند باشد، داده لازم را نداشته باشد یا کاربر را مجبور کند همان اطلاعات را دوبار وارد کند، استفاده از آن به تدریج کم می شود. در این حالت برچسب «مقاومت در برابر تغییر» توضیح دقیقی نیست. کارکنان ممکن است به روشی برگردند که با وجود نقص، کارشان را تمام می کند. برای شناخت علت، باید در محل کار ببینیم چه اتفاقی می افتد، نه اینکه فقط نمودار ورود کاربران را نگاه کنیم.

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

تغییر باید برای هر گروه معنی متفاوتی داشته باشد

مدیر ارشد از پروژه انتظار ارزش اقتصادی دارد، مدیر میانی نگران تحویل به موقع کار است و کارمند درباره دشواری وظیفه تازه و امنیت شغلی سوال دارد. یک پیام عمومی نمی تواند به همه این دغدغه ها پاسخ دهد. بهتر است برای هر گروه روشن کنیم چه چیزی تغییر می کند، چه چیزی ثابت می ماند و چه کمکی در دوره انتقال وجود دارد. وعده های مبهم مانند «همه چیز بهتر خواهد شد» معمولا اعتماد نمی سازند.

برای نمونه، اگر قرار است گزارش اولیه خودکار شود، باید مشخص کنیم کارشناس پس از آن مسئول کدام بررسی هاست. اگر زمان ذخیره می شود، آیا حجم کار او تغییر می کند؟ آیا آموزش و فرصت آزمون دارد؟ مدیران ممکن است هنوز پاسخ قطعی برای همه سوال ها نداشته باشند، اما باید درباره آنچه معلوم و نامعلوم است صادق باشند. سکوت سازمانی به سرعت با حدس و شایعه پر می شود.

از کاربران واقعی در طراحی کمک بگیرید

کاربر نهایی تنها کسی نیست که در پایان محصول را تحویل می گیرد؛ او منبع مهم شناخت مسئله است. در بسیاری از فرایندها، استثناهای واقعی در مستندات رسمی نوشته نشده اند. کارشناس باتجربه می داند کدام سند گاهی دیر به روز می شود، مشتری چه پرسشی را مبهم مطرح می کند و چه زمانی باید موضوع را به مدیر ارجاع داد. اگر این تجربه در طراحی وارد نشود، سیستم روی کاغذ خوب کار می کند اما در عمل اصطکاک ایجاد می کند.

مشارکت کاربر به معنای واگذاری تمام تصمیم ها به رای گیری نیست. باید نظر او را بشنویم، سپس محدودیت های فنی و ریسک را توضیح دهیم و درباره دامنه پروژه تصمیم بگیریم. نمونه های اولیه را در محیط واقعی آزمایش کنیم و علت نارضایتی را دسته بندی کنیم. شاید برخی خواسته ها با هدف پروژه سازگار نباشند؛ مهم آن است که دلیل تصمیم روشن باشد و کاربر احساس نکند فناوری از بالا و بدون شناخت کار او تحمیل شده است.

مدیر میانی، حلقه فراموش شده تغییر

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

یک گفت و گوی عملی با مدیر واحد برگزار کنید: چه کاری حذف می شود؟ چه کاری اضافه می شود؟ خطا چگونه گزارش می شود؟ چه زمانی اجازه بازگشت به روش دستی داریم؟ پاسخ ها را در برنامه اجرا وارد کنید. مدیری که در طراحی حضور داشته باشد، هنگام برخورد با مشکل به جای دفاع از تصمیمی نامفهوم، می تواند بخشی از راه حل باشد.

موفقیت تغییر را در رفتار بسنجید

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

پس از اجرای مرحله ای، تجربه واقعی را مرور کنید: زمان پایان کار، تعداد خطا، میزان بازکاری، رضایت کارکنان و مشتری و مواردی که ابزار کنار گذاشته شده است. بازخورد منفی را به عنوان داده ارزشمند ببینید. اگر کارکنان می ترسند مشکل را گزارش کنند، مدیریت فقط تصویر ساختگی موفقیت دریافت خواهد کرد. تغییر خوب با اعتماد و یادگیری پیش می رود، نه فقط با دستور.

قبل از گسترش، داستان واقعی یک کاربر را بشنوید

آمار استفاده مهم است، اما گاهی یک مشاهده دقیق چیز بیشتری نشان می دهد. کنار یک کارشناس بنشینید و از آغاز درخواست تا پایان کار، تمام مراحل را ببینید. چه زمانی از سامانه جدید استفاده می کند؟ کجا مجبور به ورود دوباره اطلاعات است؟ در چه نقطه ای پاسخ را کنار می گذارد و سراغ همکار می رود؟ این مشاهده باید با احترام و برای اصلاح فرایند باشد، نه نظارت تنبیهی بر فرد.

بعد آن تجربه را با داده چند کاربر دیگر مقایسه کنید. شاید مسئله فقط به یک تیم محدود باشد، یا نشانه نقص عمومی طراحی باشد. تصمیم اصلاحی را با خود کاربران آزمایش کنید. وقتی افراد ببینند بازخوردشان به تغییر واقعی منجر می شود، اعتماد بیشتری به مسیر تحول پیدا می کنند. تغییر از جایی پایدار می شود که سازمان شنیدن را هم بخشی از اجرا بداند.

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