کیفیت داده کالا یعنی اطلاعات ثبتشده برای تصمیم موردنظر قابل اتکا باشد. پرشدن همه خانههای فرم، فقط یکی از نشانههایی است که میتوان بررسی کرد؛ ممکن است توان، ابعاد و سازنده یک کالا همگی نوشته شده باشند، اما اطلاعات از کاتالوگ مدل دیگری آمده باشد. چنین شناسنامهای کامل به نظر میرسد و همچنان میتواند خرید، جستوجو یا تحویل کالا را به اشتباه بیندازد.
برای مدیریت اطلاعات مرجع کالا، باید میان «داده موجود است»، «قالب داده درست است» و «مقدار با کالای واقعی تطبیق دارد» تفاوت بگذاریم. نرمافزار باید این تفاوتها را نشان دهد و برای تکمیل یا اصلاح اطلاعات، مسیر مشخصی فراهم کند.
کاملبودن اطلاعات با درستبودن آن فرق دارد
فرض کنید در شناسنامه یک الکتروموتور، توان با مقدار عددی و واحد کیلووات ثبت شده است. از نظر وجود مقدار و قالب، مشکلی دیده نمیشود. اما اگر این مقدار متعلق به مدل مشابه باشد، کنترل قالب نمیتواند اشتباه را تشخیص دهد؛ به مقایسه با منبع مربوط به همان کالا نیاز داریم.
در چارچوب کیفیت داده دولت بریتانیا نیز کاملبودن و دقت داده دو بُعد جدا هستند؛ یک مجموعه اطلاعات میتواند بدون خانه خالی باشد و همچنان مقدارهای اشتباه داشته باشد. این تمایز در بررسی شناسنامه کالا هم مفید است. منبع: معرفی ابعاد کیفیت داده در GOV.UK
برای شروع، سه پرسش را جدا بپرسید: آیا اطلاعات لازم وجود دارد؟ آیا با قواعد تعریفشده سازگار است؟ آیا برای همین قلم و همین کاربرد تأیید شده است؟ پاسخ مثبت به پرسش اول، جای پاسخ دو پرسش بعدی را نمیگیرد.
«نامشخص»، «صفر» و «کاربرد ندارد» را جدا نگه دارید
وقتی کاربر مقدار یک ویژگی را نمیداند، نوشتن صفر فقط برای عبور از الزام فرم، داده نادرست میسازد. صفر یک مقدار واقعی است و تنها در ویژگیهایی باید ثبت شود که چنین مقداری در آنها معنی دارد. به همین شکل، عبارت «کاربرد ندارد» نباید راهی برای پنهانکردن اطلاعات پیدانشده باشد.
| وضعیت | معنای پیشنهادی | نمونه برخورد |
|---|---|---|
| نامشخص | ویژگی مرتبط است، اما مقدار آن هنوز معلوم نیست | تعیین مسئول و مرجع لازم برای تکمیل |
| صفر | مقدار معتبر ویژگی واقعاً صفر است | پذیرش فقط در صورت سازگاری با تعریف ویژگی |
| کاربرد ندارد | ویژگی طبق قاعده برای این کالا مطرح نیست | ثبت دلیل یا قاعده عدم کاربرد |
| در انتظار تأیید | مقدار پیشنهادی وجود دارد، اما بررسی نشده است | حفظ مقدار همراه وضعیت بررسی |
برای نمونه، «تعداد دندانه» در کلاس چرخدنده معنی دارد، اما الزام همان ویژگی برای یک کابل منطقی نیست. در مقابل، اگر قطر یک قطعه برای تشخیص آن لازم است و هنوز اندازهگیری یا مستند نشده، وضعیت آن نامشخص است؛ نمیتوان آن را صرفاً نامرتبط اعلام کرد.
این وضعیتها یک پیشنهاد برای طراحی دادهاند. نام دقیق آنها میتواند با فرایند سازمان فرق کند، اما مقدار ویژگی باید از وضعیت شناخت و تأیید آن قابل تشخیص بماند.
اطلاعات اجباری را برای کلاس و کاربرد تعریف کنید
اجباریکردن همه ویژگیها برای همه کالاها معمولاً مسئله را حل نمیکند. ابتدا مشخص کنید در هر کلاس، کدام ویژگیها برای تشخیص قلم، مقایسه فنی یا عملیات موردنظر لازماند. سپس تعیین کنید این اطلاعات در چه مرحلهای باید کامل و تأیید شده باشند.
ممکن است ایجاد یک رکورد اولیه با اطلاعات محدود مجاز باشد، ولی استفاده از همان رکورد در درخواست خرید به تکمیل چند مشخصه نیاز داشته باشد. در این حالت، «ذخیره پیشنویس» و «آماده استفاده در فرایند» دو وضعیت متفاوتاند. شرط عبور میان آنها باید روشن و قابل بررسی باشد.
در مدل هویت سهلایه کالا، کلاس الگوی توصیف خانواده است و آیتم قلم مشخص را نشان میدهد. بنابراین قواعد ویژگیها را به کلاس مربوط کنید و ویژگی نمونهای را نیز در جای درست نگه دارید. برای مثال، نباید شماره سریال یک موتور فیزیکی بهاشتباه مشخصه مشترک همه نمونههای آن آیتم شود.
هر ویژگی باید تعریف، نوع مقدار و واحد روشن داشته باشد
نام یک ستون بهتنهایی کافی نیست. «توان» ممکن است بدون تعریف دقیق، برای افراد مختلف برداشت متفاوتی ایجاد کند. در تعریف ویژگی روشن کنید چه کمیتی ثبت میشود، واحد مجاز چیست و مقدار از کدام بخش سند یا کدام روش به دست میآید.
در مدل مفهومی ECLASS، ویژگیها نوع داده و دامنه مقدار دارند و ویژگیهای کمّی با واحد اندازهگیری توصیف میشوند. این ساختار کمک میکند عدد، متن و مقدار انتخابی با هم اشتباه نشوند. منبع: مدل مفهومی ECLASS، بخشهای ویژگی و واحد سنجش
در طراحی شناسنامه، مقدار و واحد را جدا و مرتبط ثبت کنید. عبارتهای «۷٫۵ کیلووات» و «۷٬۵۰۰ وات» ممکن است یک کمیت را بیان کنند، اما مقایسه متن خام آنها این برابری را نشان نمیدهد. تبدیل معتبر باید پیش از مقایسه انجام شود. جزئیات این موضوع در راهنمای واحد سنجش کالا و تبدیل مقدار آمده است.
برای ویژگیهایی با گزینههای مشخص، فهرست مقدارهای کنترلشده میتواند از شکلهای نوشتاری پراکنده جلوگیری کند. با این حال، مقدار نامعلوم را خودکار به نزدیکترین گزینه تبدیل نکنید؛ انتخاب اشتباه از یک فهرست مرتب هم داده اشتباه است.
مثال الکتروموتور: سه رکورد با سه نوع مسئله
سه رکورد فرضی از خانواده الکتروموتور را در نظر بگیرید. اعداد جدول فقط برای توضیح روش بررسیاند و مشخصات محصول واقعی نیستند. در این مثال، مشخصه مورد بررسی «توان خروجی نامی» است و سند معتبر همان مدل باید مرجع قرار گیرد.
| رکورد | وضعیت اطلاعات | نتیجه بررسی |
|---|---|---|
| موتور الف | توان ثبت نشده؛ مدل دقیق معلوم است | داده ناقص است؛ میتوان منبع همان مدل را پیگیری کرد |
| موتور ب | توان ۷٫۵ کیلووات ثبت شده؛ منبع مربوط به مدل دیگر است | مقدار از نظر قالب معتبر است، اما برای این رکورد تأیید نشده |
| موتور پ | توان ۷٫۵ کیلووات با سند همان مدل تطبیق داده شده | این ویژگی طبق روش تعیینشده تأیید شده است |
برای موتور ب، کپیکردن دوباره مقدار از همان کاتالوگ یا پرکردن سایر خانهها، مسئله منبع را حل نمیکند. باید مدل، نسخه سند و محدوده کاربرد داده بررسی شوند. اگر مدرک کافی نیست، وضعیت بررسی باز بماند تا مقدار پیشنهادی بهعنوان واقعیت قطعی مصرف نشود.
همچنین تأیید توان موتور پ به معنی تأیید همه مشخصات آن نیست. ممکن است ابعاد نصب یا نوع اتصال هنوز نیازمند بررسی باشد. وضعیت تأیید در سطح ویژگی، زمانی مفید است که بخشهای مختلف شناسنامه در زمانهای متفاوت تکمیل میشوند.
منبع و سابقه اصلاح را همراه داده نگه دارید
برای مشخصههای مهم، فقط مقدار نهایی را ذخیره نکنید. مرجع، نسخه یا تاریخ سند، زمان بررسی و مسئول تأیید کمک میکنند بعداً معلوم شود چرا آن مقدار پذیرفته شده است. مرجع میتواند سند سازنده، پلاک نمونه مشخص یا اندازهگیری با روش تعریفشده باشد؛ کاربرد هر منبع باید روشن باشد.
تفاوت داده آیتم و نمونه در اینجا اهمیت دارد. نتیجه اندازهگیری یک موتور منفرد را بدون بررسی به مشخصه اسمی همه موتورهای آن مدل تبدیل نکنید. همچنین اگر دو منبع با هم ناسازگارند، جدیدتر بودن فایل بهتنهایی دلیل کافی برای انتخاب آن نیست؛ باید معلوم شود هر سند به کدام مدل، نسخه یا نمونه مربوط است.
هنگام اصلاح نیز مقدار قبلی، مقدار جدید، دلیل و مرجع تغییر را قابل پیگیری نگه دارید. بعضی اصلاحها فقط املاییاند؛ بعضی ممکن است نشان دهند کالا در کلاس اشتباه قرار گرفته یا دو قلم متفاوت با هم ترکیب شدهاند. مورد دوم به بازبینی هویت نیاز دارد و با ویرایش نام پایان نمییابد. برای این بخش، راهنمای جلوگیری از کد تکراری کالا را بخوانید.
کیفیت داده را با یک درصد کلی خلاصه نکنید
اگر گزارش فقط درصد خانههای پرشده را نشان دهد، واردکردن مقدارهای حدسی میتواند ظاهر امتیاز را بهتر کند. در گزارش، دستکم نقص اطلاعات موردنیاز، خطاهای قالب یا واحد و موارد در انتظار تطبیق با منبع را جدا نشان دهید.
مبنای محاسبه نیز باید مشخص باشد: کدام کلاسها، کدام ویژگیهای موردنیاز و کدام کاربرد بررسی شدهاند؟ ویژگیهایی که با قاعده روشن کاربرد ندارند، نباید بیتوضیح مانند یک نقص شمارش شوند. نتیجه بررسی بخشی از رکوردها را هم به همه اطلاعات تعمیم ندهید.
برای هر مسئله، مسیر اقدام لازم است: مسئول پیگیری، مدرک موردنیاز و شرط بستهشدن بررسی. ثبت این موارد کمک میکند گزارش کیفیت به فهرستی از کارهای قابل انجام تبدیل شود؛ صرفاً قرمزکردن خانههای خالی، اطلاعات را تکمیل نمیکند.
نرمافزار باید چه کنترلهایی را پاسخ دهد؟
سناریوی ارزیابی را با یک مقدار نامشخص، یک مقدار با واحد ناسازگار و یک مقدار برگرفته از مدل اشتباه شروع کنید. بررسی کنید سامانه کدام مورد را خودکار تشخیص میدهد و کدام را برای بررسی منبع ارجاع میدهد. انتظار تشخیص همه خطاهای معنایی از روی قالب فرم واقعبینانه نیست.
- آیا قواعد ویژگیها بر اساس کلاس و کاربرد مشخصاند؟
- آیا مقدار، واحد و وضعیت تأیید جدا و قابل مشاهدهاند؟
- آیا نامشخص و کاربرد ندارد از صفر قابل تشخیصاند؟
- آیا منبع مقدار و سابقه اصلاح آن قابل مراجعه است؟
- آیا تأیید یک ویژگی بهاشتباه تأیید کل شناسنامه تلقی نمیشود؟
- آیا برای رفع نقص، مسئول و شرط تکمیل تعریف میشود؟
این پرسشها را هنگام بررسی ایدنتو کنار سناریوی واقعی سازمان قرار دهید. هدف، شناسنامهای است که برای جستوجو، مقایسه و عملیات قابل اتکا باشد؛ پشتیبانی نرمافزار از هر کنترل باید با همان سناریو بررسی شود.
پرسشهای متداول درباره کیفیت داده کالا
آیا پرکردن همه فیلدها یعنی اطلاعات کالا درست است؟
خیر. مقدار ممکن است از نظر قالب صحیح باشد، اما به مدل دیگری تعلق داشته باشد. کاملبودن، کنترل قواعد و تطبیق با منبع را جدا بررسی کنید.
برای ویژگی نامعلوم صفر بنویسیم؟
خیر. صفر را فقط وقتی ثبت کنید که مقدار واقعی و مجاز آن ویژگی باشد. نبود اطلاعات باید با وضعیت روشن و مسیر تکمیل ثبت شود.
آیا همه ویژگیها باید هنگام ساخت آیتم اجباری باشند؟
به کلاس و مرحله استفاده بستگی دارد. میتوان رکورد اولیه را با اطلاعات محدود ساخت و آمادهشدن برای یک فرایند مشخص را به تکمیل ویژگیهای لازم وابسته کرد.
آیا کنترل خودکار میتواند همه خطاهای مشخصات را پیدا کند؟
کنترل نوع داده، واحد و گزینههای مجاز بخشی از خطاها را پیدا میکند. برای تشخیص مقدار متعلق به مدل اشتباه یا اختلاف منابع، معمولاً به مدرک مرتبط و بررسی معنایی نیز نیاز است.