در کدینگ کالا، ساختن یک شناسه یکتا فقط شروع کار است. کالا ممکن است تازه در مرحله پیشنهاد باشد، وارد خرید و انبار شود، برای مدتی مصرف نشود و در نهایت به‌دلیل تغییر فنی یا توقف تأمین بازنشسته شود. اگر نرم‌افزار این وضعیت‌ها را از خود شناسه جدا نکند، تیم‌ها برای نشان‌دادن «دیگر قابل استفاده نیست» به تغییر کد، حذف رکورد یا ساخت رکورد تکراری پناه می‌برند؛ هر سه کار تاریخچه را مخدوش می‌کند.
مدل مناسب باید اجازه دهد کد پایدار بماند و وضعیت چرخه عمر، دامنه استفاده و ارتباط آن با جایگزین‌ها جداگانه مدیریت شود. در این مقاله، نیازمندی‌های همین مفهوم را با یک مثال صنعتی بررسی می‌کنیم.
چرا بازنشسته‌کردن با حذف‌کردن فرق دارد؟
فرض کنید یک کارخانه برای یاتاقان خط پمپ، کد BRG-6205-2RS دارد. این قطعه دیگر برای خرید جدید تأیید نمی‌شود، اما هنوز در چند دستگاه نصب است و سوابق مصرف آن برای تعمیرات و ردیابی هزینه لازم است. حذف رکورد باعث می‌شود جست‌وجوی اسناد قدیمی بی‌معنا شود؛ تغییر کد هم پیوند میان موجودی، حواله و تجهیز را دشوار می‌کند.
پس «بازنشسته» باید یک وضعیت داده‌ای باشد، نه فرمان حذف. نرم‌افزار باید بتواند در جست‌وجوی خرید، این کالا را پیشنهاد ندهد، اما در سوابق و گزارش‌های موجودی آن را قابل مشاهده نگه دارد.
چرخه عمر چه وضعیت‌هایی را باید از هم جدا کند؟
نام وضعیت‌ها به سیاست سازمان بستگی دارد، اما مفهوم‌ها باید روشن باشند:
- پیشنهادی: هنوز داده کامل یا تأیید فنی ندارد و نباید در اسناد عملیاتی استفاده شود.
- فعال: می‌تواند در خرید، انبار، نگهداری یا ساختار تجهیزات به کار رود.
- محدود: فقط در دامنه مشخصی مانند یک سایت، قرارداد یا موجودی باقی‌مانده مجاز است.
- بازنشسته: برای ایجاد تراکنش جدید پیشنهاد نمی‌شود، ولی سابقه و ارتباطاتش حفظ می‌شود.
این وضعیت با «موجودی صفر» یکی نیست. ممکن است کالای بازنشسته هنوز در انبار یا روی تجهیز وجود داشته باشد و ممکن است کالای فعال فعلاً موجودی نداشته باشد. نرم‌افزار باید این دو مفهوم را در مدل جدا نگه دارد.
وضعیت باید روی کدام لایه بنشیند؟
در مدل هویت سه‌لایه ایدنتو، کلاس خانواده و تعریف فنی را نگه می‌دارد، آیتم رکورد قابل سفارش و انبارش است و سریال یک نمونه فیزیکی مشخص را نشان می‌دهد. چرخه عمر معمولاً در سطح آیتم معنا دارد؛ چون تصمیم خرید یا توقف تأمین درباره یک قلم مشخص گرفته می‌شود. بااین‌حال، سریال نصب‌شده باید بتواند به آیتم بازنشسته ارجاع دهد تا تاریخچه تعمیرات از بین نرود.
اگر فقط روی سریال برچسب «قدیمی» بزنیم، ممکن است برای آیتم‌های دیگر همان کالا دوباره خرید انجام شود. اگر فقط کلاس را بازنشسته کنیم، گونه‌های جدید همان خانواده بی‌دلیل مسدود می‌شوند. نرم‌افزار باید سطح اثرگذاری وضعیت را صریح نشان دهد.
جایگزین، جانشین و تغییر مهندسی
بازنشستگی معمولاً با یک تصمیم بعدی همراه است: آیا آیتم جایگزین دارد؟ برای نمونه، یاتاقان جدید ممکن است از نظر ابعاد قابل نصب باشد، اما نیاز به تأیید مهندسی یا تغییر دستورالعمل روانکاری داشته باشد. بنابراین لینک «جایگزین پیشنهادی» نباید به‌معنای برابری کامل دو کالا تعبیر شود.
سامانه باید برای رابطه جایگزینی حداقل این اطلاعات را نگه دارد: آیتم قدیمی، آیتم جدید، دامنه اعتبار، تاریخ شروع، مرجع تأیید و محدودیت‌های فنی. این رابطه به تیم خرید کمک می‌کند پیشنهاد درست بگیرد و به نگهداری هشدار می‌دهد که نصب قطعه جدید شاید نیازمند بازبینی باشد.
نرم‌افزار باید چه کنترل‌هایی ارائه دهد؟
یک مفهوم چرخه عمر قابل اتکا، به چند کنترل عملی نیاز دارد:
- تغییر وضعیت باید ثبت‌کننده، زمان و دلیل داشته باشد.
- تغییر وضعیت بازنشسته نباید اسناد گذشته را ویرایش کند.
- قواعد استفاده باید قابل تنظیم باشند؛ مثلاً بازنشسته در خرید جدید ممنوع ولی در رسید برگشتی مجاز باشد.
- گزارش باید بین آیتم‌های فعال، محدود و بازنشسته تفکیک کند.
- قبل از بازنشستگی، وجود موجودی، سفارش باز، ساختار تجهیز یا قرارداد فعال بررسی شود.
- جایگزین‌ها باید با رابطه و تاریخ اعتبار خود دیده شوند، نه با کپی‌کردن رکورد.
راهنمای رسمی Microsoft برای Product lifecycle state نیز وضعیت چرخه عمر را از برنامه‌ریزی و استفاده عملیاتی جدا می‌کند و توصیه می‌کند محصولات منسوخ از پیشنهادهای برنامه‌ریزی کنار گذاشته شوند، درحالی‌که داده اصلی باقی می‌ماند. این تفکیک نشان می‌دهد «قابل مشاهده بودن سابقه» با «قابل پیشنهاد بودن برای عملیات جدید» دو نیاز متفاوت‌اند.
نمونه تصمیم برای یک قطعه صنعتی
برای آیتم BRG-6205-2RS، کمیته فنی می‌تواند وضعیت را از فعال به بازنشسته تغییر دهد و BRG-6205-2RS-C3 را به‌عنوان جایگزین تأییدشده معرفی کند. نرم‌افزار باید در همان لحظه سه رفتار متفاوت داشته باشد:
- رسیدها و مصرف‌های قبلی همچنان با کد قدیمی گزارش شوند.
- سفارش جدید کد قدیمی را پیشنهاد ندهد و رابطه جایگزین را نمایش دهد.
- سریال‌های نصب‌شده روی پمپ‌ها همچنان به آیتم قدیمی متصل بمانند تا تاریخچه تجهیز قابل ردیابی باشد.
این رفتار از تولید رکوردهای مشابه جلوگیری می‌کند و به سازمان اجازه می‌دهد واقعیت فنی را اصلاح کند، بدون آنکه شناسه تاریخی را بازنویسی کند.
جمع‌بندی نیازمندی
کد کالا باید کلید پایدار تاریخچه باشد؛ چرخه عمر باید یک ویژگی کنترل‌پذیر کنار آن باشد. نرم‌افزار کدینگ زمانی پاسخ‌گوی این نیاز است که ایجاد، استفاده، محدودسازی و بازنشستگی را در یک مدل پیوسته مدیریت کند، اثر هر وضعیت را بر خرید و انبار جدا نشان دهد و ارتباط آیتم با سریال و جایگزین را حفظ کند.
برای طراحی این مدل، صفحه هویت سه‌لایه کالا رابطه کلاس، آیتم و سریال را توضیح می‌دهد و مقاله کیفیت داده کالا معیارهای کامل‌بودن و قابل اعتماد بودن رکورد را بررسی می‌کند.
منبع مفهومی: Product lifecycle states در Microsoft Learn و Exclude products with specific lifecycle states.