حاکمیت داده در سازمان
جلسهای که در هر سازمان متوسط به بالا تکرار میشود: مدیر فروش میگوید این ماه ۱۲۰۰ سفارش داشتیم، مدیر مالی میگوید ۱۱۴۰.
هر دو گزارششان را از سامانه گرفتهاند. هر دو راست میگویند. و نیم ساعت بعدی جلسه صرف بحث دربارهٔ عدد میشود، نه دربارهٔ تصمیم.
حاکمیت داده یعنی این جلسه دیگر برگزار نشود.
چرا اعداد فرق میکنند
تقریباً همیشه یکی از اینهاست، و هیچکدام باگ نیست:
تعریف متفاوت. فروش سفارش لغوشده را میشمارد، مالی نه. سفارشی که پرداختش تأیید نشده چه؟ سفارش مرجوعی چه؟ این شایعترین علت است و فنی نیست.
زمان متفاوت. یکی بر اساس تاریخ ثبت، دیگری بر اساس تاریخ فاکتور.
منبع متفاوت. دو سامانه که همگامسازیشان تأخیر دارد.
فیلتر متفاوت. یکی شعبهٔ تعطیلشده را حذف کرده، دیگری نه.
نکتهٔ مهم: این مسئله با ابزار حل نمیشود. خرید یک ابزار هوش تجاری روی دادهای که تعریف مشترک ندارد، فقط گزارشهای متناقض قشنگتری میسازد.
سه چیزی که حاکمیت داده واقعاً هست
بگذارید از تعریفهای آکادمیک فاصله بگیریم. در عمل، سه چیز است:
۱. برای هر داده، یک مرجع
کدام سامانه صاحب حقیقت دربارهٔ هر موجودیت است؟
- مشتری: CRM یا سامانهٔ فروش؟
- قیمت: سامانهٔ فروش یا حسابداری؟
- موجودی: انبار یا فروشگاه؟
- پرسنل: منابع انسانی، بیشک.
بقیهٔ سامانهها کپی دارند، نه نسخهٔ مستقل. تغییر در مرجع اتفاق میافتد و به بقیه منتشر میشود.
بدون این تصمیم، هر سامانهای که اجازهٔ ویرایش داشته باشد، بهمرور واقعیت خودش را میسازد. الگوهای انتشار در یکپارچهسازی سامانهها آمده.
۲. برای هر داده، یک مالک
نه مالک فنی — مالک کسبوکاری. کسی که تصمیم میگیرد تعریف چیست، چه کسی دسترسی دارد، و کیفیتش با اوست.
مالک «مشتری» معمولاً مدیر فروش است، نه واحد فناوری. واحد فناوری نگهبان است، نه مالک — و این تفکیک، تفاوت بین حاکمیت دادهٔ کارآمد و پروژهای است که در واحد IT دفن میشود.
اگر برای دادهای نمیتوانید نام یک نفر را بنویسید، آن داده بیصاحب است و کیفیتش هم به همان اندازه.
۳. برای هر اصطلاح، یک تعریف نوشتهشده
واژهنامهای که میگوید «مشتری فعال» یعنی چه. «سفارش» از چه لحظهای سفارش است. «فروش ماهانه» چه چیزی را شامل میشود و چه چیزی را نه.
ساده به نظر میرسد و بیشترین اثر را دارد. سازمانهایی را دیدهایم که فقط با نوشتن سی تعریف، نیمی از تناقضهای گزارشیشان حل شده — بدون یک خط کد.
کیفیت داده: شش سنجه
کیفیت داده مبهم است تا وقتی به شش بعد شکسته شود. هرکدام قابل اندازهگیریاند:
| بعد | سؤال | مثال خرابی |
|---|---|---|
| کامل بودن | چند درصد فیلدهای لازم پرند؟ | ۴۰٪ مشتریان کد پستی ندارند |
| درستی | آیا با واقعیت میخواند؟ | آدرسهای قدیمی |
| یکتایی | تکراری داریم؟ | یک مشتری با سه پرونده |
| سازگاری | در دو سامانه یکی است؟ | نام متفاوت در فروش و مالی |
| بهروز بودن | چقدر تازه است؟ | موجودی با تأخیر ۶ ساعت |
| اعتبار | قالبش درست است؟ | شمارهٔ تلفن ۹ رقمی |
اندازهگیری این شش، نقطهٔ شروع درست هر پروژهٔ حاکمیت داده است. بدون آن، بحث دربارهٔ کیفیت داده بحث دربارهٔ احساسات است.
دادههای تکراری، مسئلهٔ همیشگی
در هر سازمانی که مشتری دارد، پروندهٔ تکراری هم دارد. «شرکت الف»، «شركت الف»، «الف (تهران)».
در فارسی این مسئله شکل خاص خودش را دارد و باید از ابتدا دیده شود:
- ی و ک عربی در برابر فارسی — شایعترین علت عدم تطبیق در متن فارسی.
- نیمفاصله: «میشود» در برابر «می شود» در برابر «میشود».
- اعداد فارسی، عربی و لاتین در یک فیلد.
- فاصلهٔ اضافه، «شرکت» و «شركت»، پیشوندهای «آقای/خانم».
راه عملی: نرمالسازی در لحظهٔ ثبت، نه در گزارش. یک تابع نرمالسازی که همهٔ ورودیهای متنی از آن عبور کنند — تبدیل کاراکترهای عربی به فارسی، یکسانسازی اعداد، حذف فاصلهٔ اضافه.
هزینهاش یک روز کار است اگر از ابتدا باشد، و یک پروژه اگر بعداً.
و برای موارد باقیمانده: تطبیق احتمالی که موارد مشکوک را برای بررسی انسانی علامت بزند، نه اینکه خودکار ادغام کند. ادغام خودکار اشتباه، از دادههای تکراری بدتر است چون برگشتپذیر نیست.
دسترسی و طبقهبندی
بخشی از حاکمیت داده که به امنیت وصل میشود: هر دادهای یک سطح حساسیت دارد.
سه سطح برای اکثر سازمانها کافی است: عمومی، داخلی، محرمانه. و برای هر سطح قاعدهای: کجا میتواند ذخیره شود، چه کسی میبیند، آیا میشود خروجی گرفت، چقدر نگه داشته میشود.
بدون طبقهبندی، همهچیز یا زیادی باز است یا زیادی بسته — و هر دو مشکلسازند. سازوکار فنیاش در سطوح دسترسی آمده.
و سیاست نگهداری و حذف. دادهای که برای همیشه نگه داشته میشود، هم هزینهٔ ذخیرهسازی دارد و هم ریسک. برای هر دسته بنویسید چقدر میماند و بعد چه میشود.
چطور شروع کنیم بدون پروژهٔ چندساله
«حاکمیت داده» عنوانی است که بهسادگی به برنامهای دوساله با کمیته و سند تبدیل میشود که هیچوقت به نتیجه نمیرسد. مسیر عملیتر:
۱. سه گزارشی را انتخاب کنید که بیشترین بحث را میسازند. نه همهٔ دادهها — سه گزارش.
۲. برای همانها تعریف بنویسید، با حضور همهٔ کسانی که استفاده میکنند. این جلسه معمولاً پرتنش و بسیار مفید است.
۳. مرجع هر عدد را مشخص کنید، و بقیه از همانجا بخوانند.
۴. کیفیت همان دادهها را بسنجید با شش سنجهٔ بالا.
۵. بدترین بعد را اصلاح کنید.
۶. سه گزارش بعدی.
بعد از یک سال، سازمانی دارید که دربارهٔ اعدادش بحث نمیکند — بدون آنکه پروژهٔ حاکمیت دادهای اعلام کرده باشد.
و پیشنیاز هر پروژهٔ هوش مصنوعی
اگر برنامهای برای تحلیل پیشرفته یا هوش مصنوعی دارید، این مقاله پیشنیاز آن است.
مدلی که روی دادهٔ تکراری، ناقص و بیتعریف آموزش ببیند، خروجیاش همان کیفیت را دارد — با این تفاوت که حالا اشتباه با اطمینان بیشتری بیان میشود. همان ترتیب لایهها که در تحول دیجیتال گفتیم: پرش از داده به هوش مصنوعی، شایعترین اشتباه پرهزینهٔ این حوزه است.