مشکل داده را نمی توان فقط به تیم داده سپرد

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

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

داده خوب یعنی داده مناسب برای یک تصمیم مشخص

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

به جای پرسش کلی «کیفیت داده های ما خوب است؟» بپرسید برای کدام تصمیم چه داده ای لازم داریم و خطای داده چه اثری بر آن تصمیم می گذارد. پاسخ این پرسش نشان می دهد کجا باید هزینه کنیم.

مالک داده را با نگهدارنده فایل اشتباه نگیریم

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

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

به جای پاکسازی بی پایان، از مسیر تصمیم برگردید

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

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

قرارداد داده به زبان ساده

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

یک عدد، چند تعریف

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

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

کیفیت داده را با نیاز تصمیم تعریف کنید

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

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

مالکیت داده یعنی اختیار و پاسخگویی

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

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

داده سالم فقط حاصل پاکسازی نیست

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

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

آمادگی داده را صادقانه گزارش کنید

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

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

درباره اختلاف داده، مرجع تصمیم لازم است

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

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

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