در کارخانه‌ها یک پرسش تکراری پیش می‌آید: وقتی مشخصات یک قطعه تغییر می‌کند، آیا همان کد کالا باید حفظ شود یا باید آیتم جدید ساخت؟ پاسخ «هر تغییری یعنی کد جدید» هزینه و داده تکراری می‌سازد؛ پاسخ «همیشه همان کد» هم ممکن است دو قطعه ناسازگار را زیر یک شناسه پنهان کند.
نرم‌افزار کدینگ باید این تصمیم را به قاعده‌ای روشن و قابل ردیابی تبدیل کند. هدف، ساختن یک کلید برای هر واقعیت قابل سفارش و مصرف است، درحالی‌که تاریخچه نسخه‌ها و تغییرات مهندسی هم حفظ شود.
مثال: تغییر جنس واشر در پمپ
فرض کنید واشر پمپ GSK-42 از لاستیک NBR به EPDM تغییر می‌کند تا در دمای بالاتر دوام بیاورد. از دید تعمیرکار، هر دو «واشر ۴۲» هستند؛ اما از دید انبار و مهندسی، ممکن است شرایط کاری، سازگاری شیمیایی و تأییدیه متفاوت باشد.
اگر هر دو زیر یک آیتم بمانند و فقط توضیحات ویرایش شود، مشخص نخواهد بود اسناد سال گذشته به کدام جنس اشاره دارند. اگر برای هر تغییر جزئی کد تازه بسازیم، جست‌وجو و خرید با فهرستی از رکوردهای تقریباً تکراری روبه‌رو می‌شود. تصمیم باید بر اساس اثر تغییر بر شناسایی، سفارش، نگهداری و مصرف گرفته شود.
چهار نوع تغییر را از هم جدا کنید
تصحیح اطلاعات، مانند اصلاح غلط تایپی در عنوان، معمولاً هویت فنی را عوض نمی‌کند. تغییر توضیح یا نام محلی هم ممکن است بدون آیتم جدید انجام شود، به شرط آنکه ویژگی‌های فنی و کاربرد همان باشند.
تغییر فنی مؤثر، مانند جنس، ظرفیت، ابعاد اتصال یا فشار کاری، می‌تواند کالای قابل جایگزینی متفاوتی بسازد. اگر خریدار یا تکنسین باید میان نسخه قدیم و جدید تصمیم بگیرد، آیتم جدید یا دست‌کم نسخه مهندسی مجزا لازم است.
تغییر فرایند یا تأمین‌کننده همیشه به معنی آیتم جدید نیست. اگر قطعه همچنان همان مشخصات و قابلیت تعویض‌پذیری را دارد، ممکن است تفاوت را در منبع تأمین یا سوابق خرید ثبت کرد. اما این تصمیم باید با تأیید مهندسی و قواعد سازمان سازگار باشد.
تغییر بسته‌بندی یا واحد سفارش نیز لزوماً هویت قطعه مصرفی را تغییر نمی‌دهد. کارتن ده‌تایی می‌تواند شکل سفارش متفاوتی باشد، درحالی‌که واحد پایه همان قطعه است. نرم‌افزار باید رابطه بسته‌بندی و تبدیل واحد را جدا از هویت خود قطعه نگه دارد.
پرسش‌هایی که باید پیش از تخصیص کد پاسخ داده شوند
برای تصمیم‌گیری، فرایند حاکمیت داده باید دست‌کم بپرسد:
- آیا دو نسخه را می‌توان بدون بررسی و محدودیت، به جای هم نصب یا مصرف کرد؟
- آیا تفاوت بر ایمنی، کیفیت، عملکرد یا انطباق اثر می‌گذارد؟
- آیا سفارش‌دهنده باید نسخه قدیم و جدید را جداگانه انتخاب کند؟
- آیا نسخه قبلی هنوز در موجودی، تجهیز نصب‌شده یا سفارش باز وجود دارد؟
- تاریخ اجرا و دامنه مجاز استفاده از نسخه جدید چیست؟
پاسخ‌ها باید همراه با تصمیم، مسئول تأیید و تاریخ اثر ثبت شوند. کدگذاری بدون ثبت دلیل، در پروژه بعدی همان اختلاف را دوباره ایجاد می‌کند.
هویت پایدار، نسخه و وضعیت
در مدل سه‌لایه، کلاس خانواده قطعه را تعریف می‌کند، آیتم کالای قابل سفارش و مدیریت موجودی است و سریال نمونه یکتای تجهیز را مشخص می‌کند. نسخه مهندسی می‌تواند در کنار آیتم یا به‌عنوان آیتم مستقل مدیریت شود؛ انتخاب به این بستگی دارد که نسخه‌ها در انبار و سفارش واقعاً از هم تفکیک شوند یا خیر.
نرم‌افزار باید سه چیز را با هم اشتباه نگیرد: کد پایدار آیتم، نسخه مشخصات و وضعیت چرخه عمر. یک آیتم ممکن است فعال باشد ولی نسخه قدیمی‌اش برای خرید جدید بسته شده باشد؛ سریال‌های نصب‌شده همچنان باید به مشخصات زمان نصب ارجاع دهند. برای این پیوند، مقاله چرخه عمر کد کالا را ببینید.
نمونه گردش تغییر کنترل‌شده
در مثال واشر، مهندسی ابتدا مشخص می‌کند تفاوت NBR و EPDM بر قابلیت جایگزینی اثر دارد یا نه. اگر پاسخ مثبت باشد، آیتم جدید تعریف می‌شود و به آیتم پیشین با رابطه «جایگزین از تاریخ مشخص» پیوند می‌خورد. موجودی قدیمی حذف نمی‌شود؛ می‌توان آن را مصرف کرد، برای تجهیزات خاص نگه داشت یا طبق تصمیم سازمان قرنطینه کرد.
اگر تفاوت صرفاً تصحیح متن باشد، همان شناسه حفظ می‌شود و سابقه تغییر توضیح ثبت می‌گردد. در هر دو حالت، اسناد گذشته نباید با ویرایش جدید معنای دیگری پیدا کنند.
نرم‌افزار باید چه چیزی را پاسخ دهد؟
سامانه مدیریت کد کالا باید درخواست تغییر را به مشخصات پیش و پس از تغییر، دلیل، دامنه اثر، تصمیم درباره کد، تأییدکننده و زمان اجرا پیوند دهد. همچنین باید نشان دهد کدام سریال‌ها، انبارها، سفارش‌ها و ساختارهای تجهیز تحت تأثیر قرار می‌گیرند.
استاندارد مدیریت GTIN در GS1 هم بر ارزیابی اثر تغییر بر تمایز محصول، الزامات قانونی و زنجیره تأمین تأکید می‌کند. این قاعده مشخصاً برای شناسه تجاری GTIN است و نباید بدون بررسی به همه کدهای داخلی صنعتی تعمیم داده شود؛ اما اصل تصمیم‌گیری بر مبنای اثر واقعی تغییر، برای طراحی فرایند کدینگ مفید است.
جمع‌بندی
کد جدید زمانی لازم است که نسخه جدید باید در سفارش، نگهداری، ایمنی یا ردیابی از نسخه قبلی جدا شناخته شود. تغییرات توصیفی و فرایندی که هویت قابل استفاده کالا را عوض نمی‌کنند، معمولاً باید در سابقه همان آیتم مدیریت شوند. نرم‌افزار خوب مرز این دو را با قواعد روشن، تأیید مسئول و تاریخچه قابل پیگیری نگه می‌دارد.
برای شناخت رابطه کلاس، آیتم و سریال، به مدل هویت سه‌لایه کالا مراجعه کنید.
منبع: استاندارد مدیریت GTIN در GS1 و راهنمای GS1 درباره تغییر محصول.