وقتی سازمان فهرست قدیمی کالا را به یک سامانه تازه منتقل می‌کند، فقط چند ستون جابه‌جا نمی‌شوند. کدهای موجود در درخواست‌ها، اسناد خرید و سوابق انبار به همین فهرست وابسته‌اند. تغییر ظاهر نام‌ها می‌تواند مفید باشد، اما گم شدن ارتباط کد قدیمی با کالای واقعی، قابلیت پیگیری سوابق را از بین می‌برد.
مسئله اصلی واردسازی این است: چگونه داده را منظم کنیم و در عین حال بتوانیم هر ردیف منبع را تا هویت مقصد دنبال کنیم؟ پاسخ، جدا کردن «کد سازمان»، «شرح منبع» و «هویت فنی آیتم» است.
کد قدیمی چه چیزی را باید حفظ کند؟
کد سازمان یک شناسه در محدوده همان سازمان است. ممکن است دو سازمان از یک کد یکسان برای دو کالای متفاوت استفاده کنند؛ ممکن است یک سازمان نیز در دوره‌های مختلف برای یک کالا چند کد ساخته باشد. بنابراین کد را باید همراه با زمینه سازمان و سابقه آن نگهداری کرد.
در انتقال، کد منبع نباید صرفاً با کد تازه جایگزین شود. نرم‌افزار باید رابطه کد قبلی با آیتم مقصد را حفظ کند تا جست‌وجوی یک سند قدیمی همچنان به نتیجه برسد. این رابطه با تعریف فنی کالا متفاوت است؛ درباره این تفکیک، مدل هویت سه‌لایه کالا چارچوب روشنی ارائه می‌کند.
مثال صنعتی: دو کد برای یک بلبرینگ
فرض کنید در فهرست تعمیرگاه، یک ردیف «بلبرینگ 6205» و در فهرست خرید، ردیفی با همین نام و کدی دیگر وجود دارد. یکسان بودن عنوان برای ادغام کافی نیست. باید مشخص شود ویژگی‌های مؤثر، مانند نوع آب‌بندی یا مشخصات تصریح‌شده سازنده، یکسان‌اند یا هنوز معلوم نیستند.
اگر مدارک نشان دهند دو ردیف واقعاً یک تعریف فنی دارند، می‌توان هر دو کد سازمان را به یک آیتم متصل کرد و منشأ هر ارتباط را نگه داشت. اگر یکی از ردیف‌ها مبهم باشد، وضعیت آن باید «نیازمند بررسی» بماند. واردسازی نباید برای پر کردن خانه‌های خالی، هویت قطعی بسازد.
این موضوع با پاک‌سازی عمومی کدهای تکراری فرق دارد: در مهاجرت، علاوه بر تصمیم هویتی، باید مشخص باشد هر ردیف فایل چه سرنوشتی پیدا کرده است. مقاله ادغام کدهای تکراری کالا تصمیم مربوط به ادغام را جداگانه بررسی می‌کند.
کد کالا عدد محاسباتی نیست
شناسه‌ای مثل 00123 باید با همان ساختار منبع بررسی شود. تبدیل خودکار آن به عدد می‌تواند صفرهای ابتدا را حذف کند. راهنمای رسمی Microsoft توضیح می‌دهد که برای حفظ صفرهای ابتدایی و شناسه‌های طولانی، نگهداری داده به‌صورت متن اهمیت دارد. حفظ صفرهای ابتدایی و اعداد طولانی در Excel
این یک نیاز مفهومی برای نرم‌افزار است: کدها را مانند شناسه بخواند، مقدار اصلی را نگه دارد و تفاوت مقدار ذخیره‌شده با نمایش ظاهری سلول را نادیده نگیرد. اگر اطلاعات قبلاً در فایل از دست رفته باشد، افزودن صفر بر اساس حدس، بازیابی معتبر محسوب نمی‌شود؛ باید به منبع قابل اتکا مراجعه کرد.
نقش هوش مصنوعی در ورود فهرست قدیمی
AI می‌تواند از شرح نامنظم، کلاس احتمالی، نام پیشنهادی و ویژگی‌های قابل بررسی استخراج کند. اما کد سازمان باید از داده منبع بیاید؛ مدل نباید آن را حدس بزند یا بازنویسی کند. همچنین متن اصلی باید کنار نتیجه پردازش باقی بماند تا کارشناس بتواند برداشت مدل را با ورودی مقایسه کند.
پیشنهاد شباهت نیز باید به یک کار بررسی تبدیل شود. «این دو شرح نزدیک‌اند» با «این دو ردیف یک آیتم هستند» برابر نیست. مقاله مرز پیشنهاد AI و تأیید فنی این مسئولیت تصمیم‌گیری را توضیح می‌دهد.
پذیرش انتقال با تطبیق ردیف‌ها
پایان عملیات زمانی قابل دفاع است که هر ردیف معتبر منبع، مقصد یا وضعیت روشن داشته باشد. ردیف ردشده باید دلیل داشته باشد؛ ردیف مبهم باید قابل پیگیری باشد؛ ردیف متصل‌شده باید کد و شرح اصلی خود را حفظ کرده باشد. یک گزارش کلی «ورود موفق» این پرسش‌ها را پاسخ نمی‌دهد.
نرم‌افزار باید امکان مقایسه منبع و مقصد، بازبینی ارتباط‌ها و ادامه رسیدگی به موارد حل‌نشده را فراهم کند. حفظ فایل اولیه و ثبت تصمیم‌های اصلاحی نیز کمک می‌کند تغییرات بعدی قابل توضیح باشند. برای این بخش، منبع اطلاعات کالا و پیگیری داده موضوع مکمل است.
معیار موفقیت، ساخته شدن تعداد بیشتری آیتم نیست؛ حفظ سوابق همراه با کاهش ابهام است. در طراحی شناسایی و ورود اطلاعات با هوش مصنوعی در ایدنتو، فهرست قدیمی باید به نقطه شروع اطلاعات منظم تبدیل شود، در حالی که ارتباط سازمان با گذشته خود همچنان قابل پیگیری بماند.