درخت تجهیزات، نمایش رابطه میان یک مجموعه و اجزای آن است. اما پیش از رسم شاخهها باید روشن کنیم این درخت چه چیزی را نشان میدهد: اجزایی که برای ساخت یک مدل تعریف شدهاند، یا نمونههایی که اکنون واقعاً در یک تجهیز مشخص قرار دارند؟ این دو تصویر ممکن است شبیه هم باشند، ولی به پرسشهای متفاوتی پاسخ میدهند.
فهرست قطعات و مواد یا BOM میتواند بگوید یک مجموعه پمپ به یک الکتروموتور از آیتم مشخص نیاز دارد. برای دانستن اینکه کدام موتور با کدام سریال در یک پمپ معین نصب شده، باید ارتباط نمونههای واقعی را نیز ثبت کنیم. نرمافزار باید بتواند تعریف مجموعه، هویت اجزا و سابقه ارتباط آنها را از هم قابل تشخیص نگه دارد.
درخت تجهیزات باید پاسخ کدام پرسش را بدهد؟
اگر پرسش شما «برای ساخت این مدل چه اقلامی لازم است؟» باشد، به ساختار مرجع، مقدار و واحد اجزا نیاز دارید. اگر بپرسید «در این مجموعه مشخص، اکنون چه نمونههایی قرار دارند؟»، شناسه نمونهها و وضعیت ارتباطشان اهمیت پیدا میکند. برای پاسخ به «ماه قبل چه موتوری روی این مجموعه بود؟» نیز تاریخچه لازم است.
بنابراین عنوان «درخت تجهیزات» بهتنهایی کافی نیست. در کنار درخت، نوع نمایش، مجموعه مورد بررسی و زمان مرجع را روشن کنید. یک ساختار بدون این اطلاعات ممکن است تعریف طراحی را بهجای وضعیت واقعی نشان دهد یا آخرین وضعیت را با سابقه گذشته اشتباه بگیرد.
در این مقاله، تمرکز بر ساختار فیزیکی مجموعه و اجزای آن است. درخت طبقهبندی کالا، ساختار واحدهای سازمانی و فهرست انبارها کاربردهای دیگری دارند؛ شباهت شکل نمایش آنها دلیل یکسانبودن معنایشان نیست.
تفاوت BOM با ساختار واقعی تجهیز چیست؟
در مستندات Microsoft Dynamics 365، BOM اجزای لازم برای تولید محصول را تعریف میکند و خطوط آن، اقلام و مصرف برنامهریزیشده را توصیف میکنند. این مستندات همچنین انواع مختلف BOM و نسخههایی با محدوده اعتبار، مانند زمان، مقدار یا سایت را توضیح میدهند. پس حتی برای ساختار مرجع هم باید بدانیم کدام نسخه و کدام کاربرد مدنظر است. منبع: فهرست مواد و نسخههای BOM در Microsoft Learn
جدول زیر دو نیاز اطلاعاتی را مقایسه میکند. در ستون BOM، منظور فهرست مرجع طراحی یا ساخت است؛ این جدول محدودیت همه نرمافزارها یا همه انواع BOM را بیان نمیکند.
| موضوع | فهرست مرجع قطعات | ساختار نمونه واقعی |
|---|---|---|
| پرسش اصلی | چه اجزایی برای این مدل تعریف شدهاند؟ | کدام اجزا در این مجموعه مشخص قرار دارند؟ |
| هویت جزء | آیتم، مشخصات یا گزینه مجاز | نمونه مشخص، در صورت نیاز با سریال |
| مقدار | تعداد یا مصرف تعریفشده و واحد | اجزای واقعاً ثبتشده در مجموعه |
| زمان | اعتبار نسخه مرجع | شروع و پایان ارتباط هر جزء |
اگر سامانهای با نام BOM، نمونههای سریالی را هم دنبال میکند، همان دادهها را بررسی کنید: آیا شناسه مجموعه، شناسه جزء و سابقه ارتباط آنها معلوم است؟ معیار، پرسشی است که داده پاسخ میدهد؛ نام صفحه بهتنهایی این توانایی را ثابت نمیکند.
جایگاه نصب با هویت قطعه یکی نیست
«جایگاه موتور محرک» نقشی در یک مجموعه را مشخص میکند. موتور فیزیکی که آن نقش را پر میکند، موجودیت دیگری است. با تعویض موتور، جایگاه میتواند باقی بماند و نمونه قرارگرفته در آن تغییر کند.
اگر شماره جایگاه را همان شناسه موتور بدانیم، پس از جابهجایی معلوم نیست سابقه به محل تعلق دارد یا به قطعهای که از آن خارج شده است. برای طراحی داده، هویت نمونه را مستقل نگه دارید و حضور آن در جایگاه را یک ارتباط قابل ثبت در نظر بگیرید.
در توضیح GS1 درباره سریالگذاری نیز شماره سریال به نمونه منفرد مربوط است؛ برای مثال، یک نمونه تجاری با ترکیب GTIN و سریال شناسایی میشود. این تفکیک به روشنکردن تفاوت تعریف محصول و نمونه آن کمک میکند. روش ثبت جایگاه و بازه نصب در این مقاله، پیشنهاد مدلسازی است و بهعنوان الزام GS1 معرفی نمیشود. منبع: تفاوت سریالگذاری و شناسایی یکتا در GS1
برای مرور هویت خانواده، قلم و نمونه، راهنمای مدل هویت سهلایه کالا را بخوانید. یک کلاس کالا میتواند الگوی ویژگیهای موتور باشد، در حالی که یک موتور سریالی، نمونه واقعی از آیتم تعریفشده است.
مثال پمپ: یک مدل موتور، دو نمونه و دو مجموعه
دو مجموعه فیزیکی پمپ با شناسههای داخلی PUMP-A و PUMP-B را فرض کنید. هر مجموعه یک جایگاه برای موتور محرک دارد. دو موتور هممدل با سریالهای M-031 و M-052 نیز داریم که هر دو به آیتم MTR-0042 تعلق دارند. این کدها کاملاً فرضیاند و شناسه استاندارد GS1 محسوب نمیشوند.
در قواعد این مثال، تعویض موتور با نمونهای از همان آیتم، هویت مجموعه پمپ را تغییر نمیدهد. ابتدا موتور M-031 روی مجموعه اول قرار دارد. سپس آن موتور جدا و به انبار منتقل میشود و موتور M-052 جای آن را میگیرد. در مرحله بعد، موتور اول به مجموعه دوم تخصیص داده و نصب میشود.
| مرحله | ارتباطی که ثبت میشود | چیزی که ثابت میماند |
|---|---|---|
| ابتدا | موتور M-031 در جایگاه محرک مجموعه اول |
هویت هر موتور و مجموعه |
| تعویض | پایان ارتباط موتور اول و آغاز ارتباط M-052 با همان جایگاه |
آیتم موتور و هویت مجموعه اول |
| جابهجایی بعدی | آغاز ارتباط M-031 با جایگاه محرک مجموعه دوم |
سریال موتور جابهجاشده |
اگر فقط آیتم MTR-0042 را در شاخه موتور بنویسیم، تفاوت دو نمونه دیده نمیشود. اگر فقط آخرین سریال را ذخیره کنیم، وضعیت فعلی مشخص است اما پاسخ مربوط به گذشته از بین میرود. با نگهداری ارتباط و زمان اعتبار آن، میتوان هر دو پرسش را پاسخ داد.
این مثال فقط درباره ثبت هویت و ارتباط است و مجوز فنی جایگزینی قطعات را تعیین نمیکند. شرایط پذیرش یک جزء در یک مجموعه باید طبق مشخصات و قواعد فنی سازمان جداگانه بررسی شود.
رابطه «جزء مجموعه» را از «قرارگرفته در محل» جدا کنید
موتور داخل انبار ممکن است در یک جایگاه نگهداری شود، اما این حضور آن را به جزء نصبشده یک پمپ تبدیل نمیکند. همچنین تعلق یک کالا به کلاس «الکتروموتور» رابطه طبقهبندی است؛ با حضور همان موتور در یک مجموعه فیزیکی تفاوت دارد.
در طراحی، برای هر رابطه نام و معنای روشنی داشته باشید. «جزء این مجموعه است»، «در این محل قرار دارد» و «به این خانواده تعلق دارد» سه گزاره متفاوتاند. استفاده از یک ستون عمومی «والد» برای همه این معناها، گزارشها را مبهم میکند.
برای یک جزء فیزیکی منفرد در ساختار نصب، قواعد را طوری تعریف کنید که ارتباطهای ناسازگار همزمان پذیرفته نشوند. در مثال پمپ، همان موتور نمیتواند در یک زمان، موتور نصبشده هر دو مجموعه مستقل باشد. این قاعده را نباید به روابط مرجع تعمیم داد؛ یک آیتم موتور میتواند در فهرست مرجع چند مدل پمپ استفاده شود.
رویداد خروج از انبار و ثبت نصب نیز باید با هم سازگار باشند، اما یک چیز نیستند. تحویل یک موتور ممکن است پیش از نصب آن انجام شود. برای تفکیک مقدار، محل و وضعیت، راهنمای مدیریت موجودی انبار را ببینید.
برای ارتباط اجزا چه اطلاعاتی نگه داریم؟
یک پیشنهاد ساده برای ثبت ارتباط، شامل شناسه مجموعه، جایگاه، شناسه جزء، نوع رابطه، زمان شروع، زمان پایان و مرجع ثبت است. مرجع میتواند سند مونتاژ یا جابهجایی مرتبط با فرایند سازمان باشد. ثبتکننده و دلیل اصلاح نیز به پیگیری تغییرات کمک میکنند.
«اکنون چه چیزی ثبت شده؟» با «در زمان مشخص چه چیزی برقرار بوده؟» تفاوت دارد. اگر اطلاعات نصب با تأخیر وارد میشود، زمان واقعی رویداد را از زمان ورود اطلاعات جدا کنید. برای اصلاح اشتباه نیز روشن باشد چه دادهای تصحیح شده و دلیل آن چه بوده است.
نسخه ساختار مرجع و وضعیت واقعی را جدا نمایش دهید. ممکن است تعریف مجاز مجموعه تغییر کند، اما این تغییر بهخودیخود ثابت نمیکند که اجزای همه نمونههای موجود هم عوض شدهاند. تطبیق هر مجموعه با نسخه مرجع، به داده واقعی همان مجموعه نیاز دارد.
همچنین مانع رابطههای دوری شوید: مجموعه نباید مستقیم یا از طریق چند شاخه، جزء خودش شود. این کنترل از تولید درختی جلوگیری میکند که ظاهراً قابل نمایش است اما معنای فیزیکی درستی ندارد.
نرمافزار باید تا چه سطحی از جزئیات پاسخگو باشد؟
همه قطعات به شناسنامه سریالی مستقل نیاز ندارند. سطح ثبت را از نیاز واقعی انتخاب کنید. برای بعضی اجزا، آیتم و تعداد کافی است؛ بعضی به بچ نیاز دارند و برخی باید در سطح نمونه پیگیری شوند. شمار زیاد شاخهها بهتنهایی نشانه کیفیت بیشتر داده نیست.
برای ارزیابی نرمافزار، همان سناریوی دو پمپ را اجرا کنید: دو موتور از یک آیتم بسازید، ارتباط اولیه را ثبت کنید، جایگزینی و جابهجایی را انجام دهید و سپس ساختار فعلی و گذشته را بخواهید. بررسی کنید آیا نتیجه با اسناد و هویت نمونهها تطبیق دارد.
- آیا نوع درخت و زمان مرجع آن برای کاربر روشن است؟
- آیا آیتم و سریال هر جزء بدون اشتباهگرفتن با جایگاه قابل شناساییاند؟
- آیا آغاز و پایان ارتباط، تاریخچه قبلی را حفظ میکند؟
- آیا یک جزء منفرد بهاشتباه در دو جایگاه ناسازگار همزمان ثبت نمیشود؟
- آیا تغییر نسخه مرجع از تغییر وضعیت واقعی قابل تشخیص است؟
برچسب نیز باید به رکورد مناسب اشاره کند: برچسب نمونه به هویت جزء و برچسب جایگاه به همان جایگاه. درباره این تمایز، مقاله بارکد، QR و شماره سریال را بخوانید.
این پرسشها معیار نیازسنجیاند و وجود همه آنها در یک محصول از پیش فرض نشده است. در بررسی ایدنتو، سناریوی واقعی سازمان را کنار تعریف کلاس، آیتم و سریال قرار دهید تا روشن شود نرمافزار باید کدام روابط و کدام سطح از تاریخچه را پاسخ دهد.
پرسشهای متداول درباره درخت تجهیزات و BOM
آیا BOM و درخت تجهیزات همیشه دو چیز جدا هستند؟
نامگذاری سامانهها متفاوت است. مهم این است که مشخص شود داده درباره تعریف یک مدل است یا اجزای یک نمونه واقعی، و آیا زمان و سوابق ارتباطها را نگه میدارد.
آیا تعویض یک جزء باید شناسه کل مجموعه را عوض کند؟
به قواعد هویت سازمان و ماهیت تغییر بستگی دارد. در مثال این مقاله، هویت مجموعه ثابت بود و ارتباط موتور تغییر کرد. این تصمیم باید پیش از ثبت عملیات تعریف شود.
آیا هر پیچ و واشر باید یک سریال مستقل داشته باشد؟
لزوماً خیر. سطح رهگیری را متناسب با نیاز اطلاعاتی و الزامات مربوط انتخاب کنید. برای بعضی اقلام، ثبت آیتم و مقدار پاسخگو است.
آیا نگهداری آخرین وضعیت ساختار کافی است؟
اگر فقط وضعیت فعلی لازم باشد، ممکن است کافی باشد. برای پاسخ به اینکه در گذشته کدام نمونه در یک مجموعه قرار داشته، باید سوابق ارتباط و زمان اعتبار آنها نیز نگهداری شود.