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