وقتی سازمانی میخواهد کدینگ کالا را از نو تعریف کند، معمولاً اولین پیشنهادی که روی میز میآید کد «گویا» است: کدی که با نگاهکردن به آن بفهمیم کالا از کدام گروه است، جنسش چیست، در کدام واحد استفاده میشود و شاید حتی چه اندازهای دارد. در مقابل، روش دیگری هست که کد را فقط یک شناسه یکتا و بیمعنا میداند و تمام معنا را به فیلدهای ساختاریافته میسپارد.
این انتخاب یک سلیقه ظاهری نیست. تعیین میکند وقتی واقعیت کالا تغییر کرد چه اتفاقی برای کد میافتد، آیا سابقه اسناد قابل اتکا میماند و نرمافزار چقدر میتواند جستوجو و گزارش دقیق بدهد. این مقاله دو رویکرد را با نیازهایی که نرمافزار باید پاسخ دهد مقایسه میکند.
کد معنادار چیست و چرا جذاب به نظر میرسد
در کد معنادار، بخشهایی از خود رشته کد حامل اطلاعاتاند. مثلاً دو نویسه اول گروه کالا، دو نویسه بعد زیرگروه، یک نویسه جنس و چند رقم پایانی شماره ترتیبی. نتیجه، کدی است که کاربر باتجربه میتواند بدون باز کردن رکورد آن را «بخواند».
جذابیت این روش واقعی است. در سازمانی که هنوز فهرست اقلام ساختاریافته ندارد، کد گویا جای جستوجوی ضعیف را میگیرد و کاربران با حفظکردن الگو سریعتر کار میکنند. در گزارشهای اکسل هم مرتبسازی بر اساس کد، شبیه گروهبندی عمل میکند.
اما این جذابیت به یک شرط وابسته است: اینکه معنای نهفته در کد هرگز تغییر نکند. مشکل دقیقاً همینجاست، چون داده کالا در طول عمرش تغییر میکند.
هزینه پنهان: واقعیت تغییر میکند، کد نباید تغییر کند
یک کد کالا پس از اولین استفاده، در سند خرید، رسید انبار، حواله، سند حسابداری، سفارش کار و مدارک فنی تکثیر میشود. از آن لحظه، کد دیگر فقط یک برچسب نیست؛ کلید ارجاع تاریخچه است. تغییر کد یعنی شکستن پیوند میان گذشته و حال.
حالا فرض کنید معنایی که داخل کد جاسازی شده تغییر کند: گروهبندی سازمان بازنگری میشود، کالا از انبار فنی به انبار مصرفی منتقل میشود، یا جنس قطعه در نسخه جدید عوض میشود. سازمان بین دو گزینه بد گیر میکند؛ یا کد را عوض کند و سابقه را بشکند، یا کد را نگه دارد و بپذیرد که کد دروغ میگوید.
در عمل معمولاً گزینه دوم انتخاب میشود و نتیجهاش بدترین حالت است: کدی که بخشی از سازمان آن را معتبر میداند و بخش دیگر میداند قدیمی است. مقاله کیفیت داده کالا توضیح میدهد چرا دادهای که ظاهر درست ولی معنای منسوخ دارد، از داده خالی خطرناکتر است.
مشکل دوم، فشار روی طول و ظرفیت کد است. هر بخش معنادار تعدادی نویسه میگیرد و وقتی یک گروه پر شود، طراح یا باید طول کد را عوض کند یا قواعد را نقض کند. هر دو راه، یکنواختی الگویی را که کل ارزش کد گویا به آن وابسته بود از بین میبرد.
تجربه استانداردهای جهانی: شناسه بیمعنا، داده معنادار
استانداردهای بزرگ شناسایی کالا این مسیر را قبلاً رفتهاند و به نتیجه یکسانی رسیدهاند: شناسه را بیمعنا نگه دار و معنا را در پایگاه داده بگذار.
در استاندارد GS1، کد GTIN که روی بارکد کالاهای مصرفی میبینید عمداً فاقد معنای نهفته است. توصیف رسمی این است که این کدها «non-significant» هستند و اطلاعاتی در خود جاسازی نکردهاند؛ در عوض بهعنوان کلید جستوجو در پایگاه دادهای عمل میکنند که همه اطلاعات مربوط به کالا را نگه میدارد. حتی این تصور رایج که ارقام ابتدایی نشاندهنده کشور سازنده است نادرست است؛ آن بخش فقط سازمان صادرکننده کد را مشخص میکند. منبع: توضیح GS1 درباره ماهیت غیرمعنادار GTIN-13
نمونه دوم از دنیای تجهیزات و قطعات یدکی است. در سامانه کدگذاری ناتو، شماره سیزدهرقمی NSN از دو بخش ساخته میشود: چهار رقم اول کد طبقهبندی است که قلم را به گروه و کلاس اقلام مشابه مرتبط میکند، دو رقم بعد دفتر کدگذاری ملی صادرکننده را نشان میدهد و هفت رقم پایانی بهصورت ترتیبی تخصیص مییابد و هیچ معنای ذاتی ندارد؛ با این حال همین بخش بیمعنا فقط و فقط به یک قلم اشاره میکند. منبع: ساختار NSN در مستندات IFS
نکته مهم این مثال دوم آن است که بخش طبقهبندی و بخش شناسه از هم جدا نگه داشته شدهاند. طبقهبندی میتواند بازنگری شود، اما شناسه یکتای قلم دستنخورده باقی میماند و مرجع اتصال سوابق است.
مرز درست: شناسه، طبقهبندی و ویژگی سه چیز جدا هستند
درسی که از هر دو نمونه بالا گرفته میشود این است که سه نیاز متفاوت را نباید در یک رشته کد فشرده کرد.
| نیاز | باید کجا بنشیند | ویژگی لازم |
|---|---|---|
| اشاره یکتا به یک قلم | کد شناسه کالا | پایدار، تکرارنشدنی، مستقل از تغییر واقعیت |
| گروهبندی و دستهبندی | فیلد طبقهبندی و درخت گروه | قابل بازنگری بدون تغییر کد |
| مشخصات فنی و اندازه | ویژگیهای ساختاریافته با مقدار و واحد | قابل جستوجو، مقایسه و اعتبارسنجی |
وقتی این سه از هم جدا باشند، بازنگری ساختار گروهها یک عملیات دادهای ساده است و به اسناد گذشته دست نمیزند. وقتی در هم ادغام شوند، هر بازنگری به پروژه پرخطر تبدیل میشود.
جداسازی ویژگیها از کد، پیشنیاز جستوجوی درست هم هست. اگر «قطر ۵۰» فقط داخل رشته کد یا داخل نام کالا باشد، امکان فیلتر عددی، مقایسه و کنترل واحد وجود ندارد. مقاله شناسنامه فنی کالا این تفکیک را با جزئیات بیشتر توضیح میدهد.
مثال فرضی: یک شیر صنعتی با دو مدل کدینگ
مثال زیر فرضی است. یک شیر پروانهای با قطر مشخص در انبار فنی ثبت میشود. دو طراحی ممکن را مقایسه کنیم:
| رویکرد | نمونه کد | وقتی گروهبندی سازمان عوض شود | وقتی سازنده مدل را با جنس جدید بازطراحی کند |
|---|---|---|---|
| کد کاملاً معنادار | VLV-BF-CI-050-0007 |
کد نادرست میشود یا باید عوض شود | بخش جنس در کد دروغ میگوید |
| شناسه بیمعنا + فیلد ساختاریافته | IT-0000482731 |
فقط مقدار فیلد گروه بهروز میشود | یا ویژگی بهروز میشود یا قلم جدیدی ساخته میشود |
در ستون آخر یک تصمیم مهم پنهان است: تغییر جنس ممکن است آنقدر اساسی باشد که در عمل قلم دیگری ساخته باشد. این تصمیم باید بر اساس قواعد شناسایی سازمان گرفته شود، نه بر اساس اینکه کد فعلی چه شکلی دارد. وقتی کد بیمعناست، سازمان آزاد است تصمیم درست را بگیرد.
توجه کنید که مدل بیمعنا به معنای حذف خوانایی نیست. کاربر همچنان نام، گروه و مشخصات را میبیند؛ فقط این اطلاعات از فیلدهای خودشان خوانده میشود، نه از رمزگشایی رشته کد.
حالت میانه و شرط استفاده از آن
در عمل بسیاری از سازمانها کد نیمهمعنادار انتخاب میکنند: یک پیشوند کوتاه که پایدارترین بُعد را نشان میدهد و بقیه کد ترتیبی است. این انتخاب وقتی قابل دفاع است که پیشوند از بخشی گرفته شود که تقریباً هرگز تغییر نمیکند، مثل تفکیک «قلم انبارشدنی» از «خدمت».
شرط دوم این است که سازمان از قبل بپذیرد پیشوند مرجع طبقهبندی نیست. یعنی گزارشها و فیلترها باید از فیلد گروه بخوانند، نه از بریدن چند نویسه اول کد. اگر گزارشها به الگوی کد وابسته شوند، عملاً همان قفل کد معنادار بازتولید شده است.
شرط سوم، قاعده روشن برای مواردی است که ماهیت قلم بعداً تغییر میکند. سیاست باید از پیش معلوم باشد: کد ثابت میماند و فقط داده اصلاح میشود، یا قلم جدید ساخته و قلم قبلی منسوخ میشود. تصمیم موردی، همان بینظمی را برمیگرداند.
چه چیزی کد گویا را واقعاً غیرضروری میکند
بخشی از دلبستگی به کد گویا، واکنش به نرمافزاری است که جستوجوی خوبی ندارد. اگر پیدا کردن یک قلم نیازمند حفظکردن کد باشد، کاربر طبیعتاً کد را حامل معنا میخواهد. بنابراین پیش از بحث درباره الگوی کد، باید پرسید نرمافزار چه امکاناتی میدهد.
- جستوجو روی نام، مترادف، کد سازنده و کد قدیمی سازمان
- فیلتر بر اساس گروه و بر اساس ویژگی با مقدار و واحد
- نمایش نتایج مشابه هنگام ثبت قلم جدید برای پیشگیری از کد تکراری
- نگهداشتن نگاشت کدهای قدیمی پس از یکپارچهسازی، بهجای حذف آنها
- تفکیک روشن قلم از نمونه فیزیکی بر اساس مدل هویت سهلایه کالا
وقتی اینها موجود باشد، تنها کاری که از کد انتظار میرود یکتایی و پایداری است؛ و آن دقیقاً کاری است که کد بیمعنا بهتر از همه انجام میدهد.
نرمافزار را با این سناریوها بسنجید
برای ارزیابی مدل کدینگ در هر نرمافزاری، این مسیرها را آزمایش کنید:
- گروه یک قلم را عوض کنید؛ کد و ارجاع اسناد گذشته نباید تغییر کند.
- درخت طبقهبندی را بازنگری کنید؛ نباید نیاز به کدگذاری مجدد اقلام باشد.
- دو قلم با ویژگیهای نزدیک ثبت کنید؛ سیستم باید موارد مشابه را پیش از ثبت نشان دهد.
- یک کد قدیمی سازمان را جستوجو کنید؛ باید به شناسنامه فعلی برسید.
- بر اساس ویژگی عددی با واحد مشخص فیلتر بگیرید، نه با جستوجوی متنی در نام.
- قلمی را منسوخ کنید؛ کد نباید برای قلم دیگری بازاستفاده شود.
این موارد معیارهای پیشنهادی برای سنجش مدل دادهاند و ادعای قابلیت فعلی ایدنتو نیستند. بخش قابلیتهای ایدنتو نگاه کلی محصول را معرفی میکند و قواعد کدینگ هر سازمان باید با مسئولان داده همان سازمان نهایی شود.
پرسشهای متداول درباره کد معنادار و کد ترتیبی
آیا کد معنادار همیشه اشتباه است؟
خیر، اما محدودیتهایش باید پذیرفته شود. هر معنایی که داخل کد جاسازی شود، در آینده یا باید همیشه درست بماند یا منبع اختلاف میشود. هرچه معنای بیشتری داخل کد برود، انعطاف کمتری باقی میماند.
اگر کد بیمعنا باشد، کاربر چطور کالا را تشخیص دهد؟
از طریق نام، گروه، ویژگیهای ساختاریافته و جستوجو. کد وظیفه توصیف ندارد؛ وظیفهاش اشاره یکتا و پایدار به یک شناسنامه است.
کد سازنده یا کد تأمینکننده جای کد داخلی را نمیگیرد؟
معمولاً نه. کد سازنده متعلق به سازمان دیگری است، ممکن است تغییر کند یا برای یک قلم چند مقدار داشته باشد. این کدها باید بهعنوان شناسههای کمکی ذخیره و جستوجوپذیر شوند، در کنار شناسه داخلی پایدار.
کد یک قلم منسوخشده را میتوان دوباره استفاده کرد؟
بازاستفاده کد توصیه نمیشود. اسناد و مدارک قدیمی همچنان به آن کد ارجاع میدهند و تخصیص دوبارهاش به قلم دیگر، تفسیر تاریخچه را مخدوش میکند.
برای اصلاح کدینگ فعلی باید همه کدها را عوض کرد؟
نه لزوماً. در بسیاری از موارد میتوان کدهای موجود را بهعنوان شناسه پایدار پذیرفت، معنای نهفته در آنها را نادیده گرفت و در عوض فیلدهای گروه و ویژگی را درست پر کرد. تغییر گسترده کد هزینه و ریسک سابقه دارد و باید آخرین گزینه باشد.