در یک پروژه خودرویی، داشتن فهرستی طولانی از استانداردها الزاماً به معنی شناخت الزامات محصول نیست. ممکن است استانداردی درباره موضوعی مرتبط با خودرو وجود داشته باشد، اما برای گروه خودرویی موردنظر قابل اعمال نباشد؛ ممکن است الزامی فقط در صورت وجود یک تجهیز مشخص مطرح شود؛ ممکن است استاندارد جدیدی منتشر شده باشد اما وضعیت اجرای آن در بازار هدف نیازمند بررسی باشد؛ و ممکن است یک قطعه علاوه بر الزامات قانونی، تعهدات فنی دیگری در برابر خودروساز یا مشتری داشته باشد. به همین دلیل، یکی از نخستین فعالیتهای مهم در توسعه، آزمون یا فرآیند تأیید محصول، شناسایی الزامات قابل اعمال (Applicable Requirements) است.
این فرآیند نباید با جستوجوی چند عبارت و جمعآوری شماره استانداردها پایان یابد. برای هر الزام باید بتوان مشخص کرد منشأ آن چیست، دامنه کاربرد آن چه محصولاتی را پوشش میدهد، آیا پیکربندی موردنظر مشمول آن میشود، وضعیت اجرای الزام چگونه است، کدام نسخه یا اصلاحیه ملاک قرار میگیرد و برای اثبات انطباق چه شواهدی لازم است. نتیجه چنین بررسیای را میتوان در قالب ماتریس الزامات (Requirement Matrix) یا ماتریس الزامات مقرراتی (Regulatory Matrix) مدیریت کرد و سپس بهعنوان ورودی برنامه آزمون، برنامه تصدیق طراحی، فرآیند تأیید نوع و سایر فعالیتهای ارزیابی محصول به کار گرفت.
چرا شناسایی استانداردهای قابل اعمال از خود آزمون مهمتر است؟
آزمون زمانی ارزش دارد که برای پاسخ به الزام مشخصی انجام شود. اگر الزام اشتباه انتخاب شده باشد، حتی اجرای کاملاً صحیح آزمون نیز ممکن است اطلاعاتی تولید کند که برای پروژه موردنیاز نبوده است. در مقابل، اگر یک الزام قابل اعمال اصلاً شناسایی نشده باشد، ممکن است محصول به مراحل پایانی توسعه برسد و تازه مشخص شود که تغییر طراحی، تهیه مدارک یا آزمون دیگری لازم است.
به همین دلیل، ترتیب منطقی پروژه این نیست که ابتدا از آزمایشگاه بپرسیم «چه آزمونهایی دارید؟» و سپس از میان آنها موارد مناسب را انتخاب کنیم. ابتدا باید محصول، بازار هدف، پیکربندی و الزامات مشخص شوند؛ سپس روشهای ارزیابی و آزمونهای موردنیاز تعیین شوند.
این تفاوت بهخصوص در صنعت خودرو اهمیت دارد، زیرا یک وسیله نقلیه میتواند همزمان مشمول الزامات مرتبط با ترمز، فرمان، میدان دید، روشنایی، حفاظت از سرنشینان، تجهیزات الکتریکی، آلایندگی، امنیت سایبری و بسیاری حوزههای دیگر باشد. اما اینکه دقیقاً کدام الزام برای یک خودرو قابل اعمال است، باید از دامنه کاربرد و شرایط تعیینشده در مرجع مربوط استخراج شود.
الزام قابل اعمال (Applicable Requirement) چیست؟
الزام قابل اعمال، الزامی است که با توجه به دامنه کاربرد و شرایط تعریفشده در مرجع مربوط، برای محصول و پیکربندی موردنظر موضوعیت دارد. این مفهوم را نباید با «هر استاندارد مرتبط با خودرو» یکسان دانست.
برای مثال، یک مقرره ممکن است فقط گروههای مشخصی از وسایل نقلیه را پوشش دهد یا الزام خاصی در آن تنها برای خودروهای مجهز به یک سیستم معین مطرح باشد. بنابراین گروه خودرویی، جرم، نوع قوای محرکه، تجهیزات نصبشده، ویژگیهای ساختاری و سایر مشخصات محصول میتوانند بسته به مقرره در تعیین قابلیت اعمال الزامات نقش داشته باشند.
نکته مهم این است که این عوامل را نمیتوان از یک مقرره به مقرره دیگر تعمیم داد. دامنه کاربرد هر سند باید بهصورت مستقل بررسی شود. اینکه گروه خودرویی در یک استاندارد عامل تعیینکننده است، به معنی آن نیست که تمام استانداردها دقیقاً از همان شرایط استفاده میکنند.
قابل اعمال بودن، اجباری بودن و زمان اجرا یک معنی ندارند
این سه مفهوم باید از یکدیگر تفکیک شوند. قابلیت اعمال (Applicability) مشخص میکند یک الزام از نظر دامنه و شرایط فنی به محصول موردنظر مربوط میشود یا خیر. الزامآور بودن (Mandatory) به جایگاه قانونی یا قراردادی آن مربوط است و زمان اجرا (Effective Date) مشخص میکند الزام از چه تاریخی و تحت چه شرایطی باید رعایت شود.
بنابراین ممکن است استانداردی از نظر موضوع و دامنه کاربرد به محصول مرتبط باشد، اما وضعیت الزامآور بودن آن نیازمند بررسی جداگانه باشد. همچنین ممکن است برای اجرای یک الزام برنامه زمانی مشخصی تعیین شده باشد و وضعیت آن در تاریخهای مختلف، برای گروههای متفاوت محصول یا مراحل گوناگون تأیید، یکسان نباشد.
این تفکیک از تصمیمهای اشتباه جلوگیری میکند. عبارتهایی مانند «این استاندارد مربوط به خودروست، پس اجباری است» یا «در فهرست جدید آمده، پس همین امروز برای تمام خودروها اجرا میشود» بدون بررسی منابع رسمی مبنای کافی برای تصمیمگیری نیستند.
برای توضیح بیشتر درباره جایگاه قانونی استانداردها میتوانید مقاله «استاندارد اجباری و استاندارد تشویقی چه تفاوتی دارند؟» را مطالعه کنید.
مرحله اول؛ محصول را دقیق تعریف کنید
پیش از جستوجوی استاندارد باید بدانیم دقیقاً چه محصولی قرار است ارزیابی شود. عبارتهایی مانند «خودرو سواری»، «صندلی»، «چراغ» یا «واحد کنترل الکترونیکی» برای یک بررسی دقیق مقرراتی همیشه اطلاعات کافی ارائه نمیکنند.
در سطح خودرو، گروه خودرویی و ویژگیهای فنی مرتبط باید مشخص باشند. در سطح قطعه نیز باید معلوم باشد قطعه چه عملکردی دارد، روی چه خودروهایی استفاده میشود و آیا بهصورت مستقل مشمول تأییدیه یا الزام مشخصی است یا بخشی از یک سیستم بزرگتر محسوب میشود.
پیکربندی محصول نیز اهمیت دارد. ممکن است دو گونه از یک خودرو نام تجاری یکسانی داشته باشند، اما وجود یا عدم وجود یک سیستم خاص باعث تفاوت در الزامات قابل اعمال آنها شود. بنابراین تحلیل مقرراتی باید بر اساس مشخصات واقعی و تعریفشده محصول انجام شود، نه صرفاً نام تجاری آن.
مرحله دوم؛ بازار و هدف پروژه را مشخص کنید
استانداردهای الزامآور را نمیتوان بدون شناخت بازار هدف (Target Market) تعیین کرد. الزامات خودرو در بازارهای مختلف ممکن است ساختار متفاوتی داشته باشند و وجود یک مقرره UN به معنی اجرای یکسان آن در تمام کشورهای جهان نیست.
همچنین هدف پروژه باید مشخص باشد. آیا محصول برای بازار داخلی توسعه پیدا میکند؟ آیا هدف دریافت تأیید نوع در بازار دیگری است؟ آیا قطعه برای خودروساز مشخصی ساخته میشود؟ یا پروژه صرفاً به ارزیابی و صحهگذاری داخلی محصول مربوط است؟
این تفاوت اهمیت زیادی دارد، زیرا مقررات قانونی تنها منبع الزامات پروژه نیستند. یک خودروساز ممکن است الزامات فنی یا مشخصات اختصاصی دیگری تعیین کرده باشد که حتی اگر الزام قانونی عمومی نباشند، برای تأمینکننده در چارچوب قرارداد همان پروژه لازمالاجرا باشند.
بنابراین پیش از تهیه ماتریس الزامات، بهتر است الزامات مقرراتی و الزامات مشتری یا پروژه از یکدیگر قابل تشخیص باشند.
مرحله سوم؛ گروه خودرویی یا طبقهبندی محصول را تعیین کنید
در مقررات خودرو، طبقهبندی محصول میتواند نقش اساسی در تعیین قابلیت اعمال الزامات داشته باشد. در چارچوب مقررات UN، گروههایی مانند M، N، O و L برای دستههای مختلف وسایل نقلیه به کار میروند و بسیاری از مقررات در بخش دامنه کاربرد خود مشخص میکنند کدام گروهها را پوشش میدهند.
اما صرف دانستن اینکه خودرو در یک گروه مشخص قرار دارد، برای تعیین تمام الزامات قابل اعمال کافی نیست. ممکن است مقرره علاوه بر گروه خودرویی، شرایط دیگری نیز داشته باشد. بنابراین گروه خودرو باید یکی از ورودیهای تحلیل دامنه کاربرد باشد، نه پاسخ نهایی آن.
برای قطعات نیز ممکن است طبقهبندیها یا تعاریف اختصاصی مقرره اهمیت داشته باشند. هنگام مطالعه یک مقرره، بررسی بخشهای دامنه کاربرد و تعاریف کمک میکند مشخص شود محصول موردنظر در چارچوب همان سند چگونه شناخته و طبقهبندی میشود.
مرحله چهارم؛ منابع مقرراتی معتبر را پیدا کنید
ماتریس الزامات باید بر اساس منابع معتبر و قابل ردیابی تهیه شود. فایلهای قدیمی پروژه، صفحات گسترده مربوط به محصولات قبلی یا فهرستهای غیررسمی اینترنتی میتوانند برای شروع جستوجو مفید باشند، اما نباید بدون بررسی منبع اصلی مبنای تصمیم مقرراتی قرار گیرند.
برای مقررات UN، متن رسمی مقررات و اصلاحیههای منتشرشده در چارچوب UNECE WP.29 اهمیت دارند. در مورد الزامات ملی نیز باید به اسناد و مراجع رسمی مربوط مراجعه شود و وضعیت اجرای استانداردها بر اساس اطلاعات معتبر بررسی شود.
در صنعت خودرو ایران، جدول استانداردهای ۱۲۲گانه خودرو در وبسایت تات برای دسترسی ساختاریافته به عنوان استانداردها، شماره استانداردهای مرتبط و اطلاعات وضعیت اجرای آنها ارائه شده است. این جدول میتواند نقطه شروع مناسبی برای شناسایی الزامات باشد، اما در تصمیمهای فنی و مقرراتی حساس، آخرین اسناد و ابلاغیههای رسمی مربوط باید مبنای نهایی بررسی قرار گیرند.
مرحله پنجم؛ دامنه کاربرد استاندارد را بخوانید
یکی از مهمترین مراحل شناسایی الزامات، بررسی دامنه کاربرد یا Scope است. عنوان یک استاندارد یا مقرره همیشه اطلاعات کافی درباره محدوده واقعی کاربرد آن ارائه نمیکند.
ممکن است عنوان یک مقرره درباره سیستم مشخصی باشد، اما دامنه آن فقط برخی گروههای خودرویی یا پیکربندیها را پوشش دهد. همچنین ممکن است بعضی الزامات سند فقط در شرایط خاصی قابل اعمال باشند.
بنابراین پیش از مطالعه جزئیات روش آزمون، ابتدا باید مشخص شود آیا مقرره اصولاً محصول موردنظر را پوشش میدهد یا خیر. بررسی کامل روش آزمون سندی که خارج از دامنه محصول قرار دارد، میتواند زمان و منابع پروژه را بدون ایجاد ارزش فنی مصرف کند.
یک بررسی مقرراتی مناسب معمولاً از دامنه کاربرد، تعاریف، الزامات، مقررات انتقالی و روشهای آزمون عبور میکند، هرچند ترتیب و ساختار دقیق بخشها ممکن است میان اسناد متفاوت باشد.
مرحله ششم؛ تعاریف استاندارد را جدی بگیرید
اصطلاحهایی که در مکالمه روزمره ساده به نظر میرسند، ممکن است در یک مقرره تعریف فنی مشخصی داشته باشند. مفاهیمی مانند نوع خودرو، نوع صندلی، سیستم، قطعه و گونه محصول میتوانند در تعیین قابلیت اعمال الزامات اهمیت داشته باشند.
اگر تعاریف سند نادیده گرفته شوند، ممکن است تیم پروژه محصول را بر اساس برداشت عمومی خود طبقهبندی کند و در نتیجه الزامات اشتباهی را انتخاب کند.
این موضوع بهخصوص در مقررات UN اهمیت دارد، زیرا تأیید نوع معمولاً به نوع مشخصی از محصول (Type) مربوط است و مقرره تعیین میکند برای هدف همان تأییدیه، چه ویژگیهایی در تعریف نوع اهمیت دارند.
مرحله هفتم؛ شرایط قابل اعمال بودن الزامات را استخراج کنید
پس از بررسی دامنه کاربرد و تعاریف، باید شرایطی که تعیین میکنند هر الزام برای محصول قابل اعمال است یا خیر استخراج شوند. این شرایط ممکن است به گروه خودرویی، پیکربندی، تجهیزات نصبشده یا سایر ویژگیهای تعریفشده در مقرره وابسته باشند.
بهتر است این تحلیل فقط در ذهن مهندس باقی نماند. برای هر الزام میتوان در ماتریس ستونی با عنوان «وضعیت قابلیت اعمال و مبنای تصمیم» در نظر گرفت و دلیل قابل اعمال بودن یا نبودن آن را ثبت کرد.
برای مثال، بهجای ثبت صرف عبارت N/A یا «غیرقابل اعمال»، بهتر است در پروژههای حساس، بند مرجع و دلیل تصمیم نیز مشخص شوند. این کار هنگام تغییر طراحی یا ممیزی اهمیت زیادی دارد؛ اگر پیکربندی محصول تغییر کند، میتوان تشخیص داد کدام تصمیمهای قبلی باید دوباره بررسی شوند.
مرحله هشتم؛ نسخه و اصلاحیه قابل اعمال را مشخص کنید
دانستن شماره مقرره کافی نیست. مقررات UN در طول زمان اصلاح میشوند و ممکن است سری اصلاحیهها (Series of Amendments)، اصلاحات تکمیلی (Supplements) و نسخههای تجمیعشده (Revisions) مختلفی داشته باشند. الزامات فنی و مقررات انتقالی نیز ممکن است در طول زمان تغییر کنند.
بنابراین عبارتهایی مانند «محصول مطابق R17 است» بدون مشخص کردن مبنای دقیق ارزیابی، در یک پروژه فنی میتواند اطلاعات ناکافی ارائه کند. باید معلوم باشد کدام نسخه، سری اصلاحیه یا مجموعه مقررات برای فرآیند تأیید یا ارزیابی موردنظر ملاک قرار میگیرد.
در پروژههای چندساله این موضوع اهمیت بیشتری دارد. ممکن است الزامات در زمان شروع طراحی اولیه یک وضعیت داشته باشند و تا زمان تأیید نوع یا آغاز تولید انبوه تغییر کنند. بنابراین پایش تحولات مقرراتی باید در طول پروژه ادامه داشته باشد.
اگر با ساختار مقررات UN آشنا نیستید، مقاله «استاندارد UNECE چیست؟ ارتباط مقررات UN با استانداردهای خودرو در ایران» در دانشنامه تات ساختار کلی این مقررات را توضیح میدهد.
مرحله نهم؛ مقررات انتقالی را بررسی کنید
در مقررات UN، مقررات انتقالی (Transitional Provisions) میتوانند برای تعیین نحوه ورود سریهای جدید اصلاحیهها به فرآیند تأیید نوع اهمیت زیادی داشته باشند. این بخش ممکن است تاریخها و شرایطی را تعیین کند که بر صدور تأییدیههای جدید، پذیرش تأییدیههای قبلی یا ادامه اعتبار و شناسایی آنها در چارچوب مربوط اثر میگذارند.
به همین دلیل نمیتوان صرفاً با مشاهده تاریخ انتشار یک اصلاحیه نتیجه گرفت که از همان روز تمام محصولات باید بر اساس آن ارزیابی شوند. زمان و شرایط اجرای الزامات باید بر اساس متن مقرره و مقررات انتقالی مربوط بررسی شوند.
این یکی از دلایلی است که برنامهریزی مقرراتی باید از ابتدای پروژه انجام شود. اگر محصول قرار است چند سال بعد وارد بازار شود، شناخت الزامات فعلی بهتنهایی کافی نیست؛ تغییرات شناختهشدهای که در زمان تأیید یا عرضه محصول اثر خواهند داشت نیز باید بررسی شوند.
مرحله دهم؛ وضعیت اجرای ملی را جداگانه بررسی کنید
وجود یک مقرره UN و قرار گرفتن محصول در دامنه فنی آن به معنی اجرای خودکار آن در هر کشور نیست. بازار هدف تعیین میکند کدام الزامات و فرآیندهای مقرراتی را پذیرفته یا لازمالاجرا کرده است.
در ایران نیز وضعیت استانداردها و برنامه اجرای الزامات باید بر اساس منابع مربوط بررسی شود. برای مشاهده ساختاریافته اطلاعات میتوانید از جدول استانداردهای ۱۲۲گانه خودرو استفاده کنید و در تصمیمهای پروژهای، آخرین اسناد رسمی مرتبط را مبنا قرار دهید.
این تفکیک اهمیت اساسی دارد: قرار گرفتن محصول در دامنه فنی یک مقرره و الزامآور بودن آن در بازار هدف، دو موضوع مرتبط اما مجزا هستند.
استاندارد ملی و مقررات UN چگونه به هم مرتبط میشوند؟
در بعضی حوزهها ممکن است استاندارد ملی ایران بر پایه یا مرتبط با یک مقرره UN تدوین شده باشد. در چنین شرایطی شناخت مقرره بینالمللی میتواند برای درک منشأ الزامات فنی مفید باشد، اما نباید شماره استاندارد ملی و مقرره UN را بدون بررسی دقیق، دو سند کاملاً یکسان در نظر گرفت.
نسخه مورد استناد، اصلاحات، دامنه کاربرد و وضعیت اجرای سند ملی باید جداگانه بررسی شوند. اگر استاندارد ملی به نسخه مشخصی از یک مقرره ارجاع داده باشد، تغییرات بعدی مقرره بینالمللی الزاماً بهصورت خودکار محتوای استاندارد ملی را تغییر نمیدهند، مگر اینکه سازوکار قانونی یا ارجاع مربوط چنین اثری را پیشبینی کرده باشد.
بنابراین در ماتریس الزامات بهتر است مشخصات دقیق سندی که واقعاً مبنای الزام پروژه است ثبت شود.
ماتریس الزامات (Requirement Matrix) چیست؟
ماتریس الزامات ساختاری برای جمعآوری و مدیریت الزامات محصول است. در پروژههای مقرراتی، ممکن است از اصطلاح ماتریس الزامات مقرراتی (Regulatory Matrix) یا ماتریس انطباق (Compliance Matrix) نیز استفاده شود. هدف این است که الزامات از حالت فهرستی پراکنده خارج شوند و اطلاعات لازم برای بررسی، تصمیمگیری و پیگیری انطباق به آنها متصل شود.
یک ساختار ساده میتواند شامل اطلاعات زیر باشد:
| مرجع | موضوع الزام | قابلیت اعمال | مبنای تصمیم | وضعیت اجرا | روش ارزیابی | شواهد |
|---|---|---|---|---|---|---|
| مقرره یا استاندارد | الزام موردنظر | قابل اعمال / غیرقابل اعمال | دامنه کاربرد و شرایط | وضعیت مرتبط با پروژه | آزمون / تحلیل / بازرسی | گزارش / تأییدیه |
این جدول فقط یک نمونه مفهومی است و ساختار واقعی باید بر اساس فرآیند سازمان طراحی شود. در پروژههای پیچیده میتوان نسخه سند، مسئول پیگیری، گونه خودرو، وضعیت تأییدیه، سابقه تغییرات و اطلاعات دیگری را نیز به آن اضافه کرد.
مهمترین ویژگی ماتریس این است که تصمیمها قابل ردیابی باشند. اگر الزامی قابل اعمال تشخیص داده شده، مبنای آن مشخص باشد و اگر غیرقابل اعمال تشخیص داده شده، دلیل تصمیم نیز قابل بازیابی باشد.
آیا هر الزام قابل اعمال نیازمند آزمون است؟
خیر. قابل اعمال بودن یک الزام و روش اثبات انطباق با آن، دو سؤال متفاوت هستند. پس از اینکه مشخص شد الزام برای محصول قابل اعمال است، باید بررسی شود مرجع مربوط چه روش یا شواهدی را برای اثبات انطباق تعیین کرده است.
بعضی الزامات از طریق آزمون بررسی میشوند، برخی ممکن است به بازرسی، اندازهگیری، بررسی مدارک یا سایر روشهای تعریفشده نیاز داشته باشند. در پروژههای توسعه محصول نیز تحلیل مهندسی ممکن است برای برخی الزامات طراحی روش مناسبی برای تصدیق باشد.
بنابراین ماتریس الزامات نباید بهصورت خودکار به فهرست آزمونها تبدیل شود. ابتدا الزام و شرایط آن مشخص میشود، سپس روش مناسب ارزیابی تعیین خواهد شد.
برای بررسی آزمونها و استانداردهای قابل انجام در تات میتوانید از جدول آزمونهای قابل انجام استفاده کنید.
ماتریس الزامات مقرراتی با Test Plan چه تفاوتی دارد؟
ماتریس الزامات مقرراتی مشخص میکند چه الزاماتی برای محصول مطرح هستند، چرا قابل اعمالاند و وضعیت بررسی یا انطباق آنها چگونه است. در مقابل، برنامه آزمون یا Test Plan بر فعالیتهای آزمونی تمرکز دارد و مشخص میکند آزمون چگونه، روی چه نمونهای، با چه معیارهای پذیرشی و در چه زمانی انجام خواهد شد.
این دو باید به یکدیگر متصل باشند. اگر برنامه آزمون شامل فعالیتی باشد که هیچ الزام یا هدف مهندسی مشخصی در ماتریس ندارد، باید دلیل آن بررسی شود. همچنین اگر الزامی نیازمند آزمون باشد اما هیچ فعالیتی در برنامه برای آن تعریف نشده باشد، ممکن است بخشی از شواهد لازم برای تصدیق یا ارزیابی انطباق محصول تأمین نشده باشد.
این ارتباط کمک میکند آزمون از یک فعالیت جداگانه آزمایشگاهی به بخشی از فرآیند مدیریت انطباق و توسعه محصول تبدیل شود.
ماتریس الزامات مقرراتی چه ارتباطی با DVP&R دارد؟
سند DVP&R یا Design Verification Plan and Report نیز از قابلیت ردیابی الزامات استفاده میکند، اما تمرکز آن بر برنامهریزی و ثبت نتایج تصدیق طراحی است. ماتریس الزامات مقرراتی میتواند یکی از منابع ورودی الزامات برای DVP&R باشد.
برای مثال، یک الزام مقرراتی قابل اعمال وارد مجموعه الزامات محصول میشود و سپس در برنامه تصدیق طراحی مشخص میشود که انطباق با آن چگونه بررسی خواهد شد. در کنار این الزامات، نیازهای مشتری و الزامات داخلی مهندسی نیز میتوانند در همان فرآیند مدیریت شوند.
این ساختار باعث میشود انطباق مقرراتی از توسعه محصول جدا نباشد. الزامات قانونی باید از مراحل اولیه طراحی وارد فرآیند مهندسی شوند، نه اینکه در انتهای پروژه به محصول اضافه شوند.
Type Approval چه زمانی وارد این فرآیند میشود؟
اگر هدف پروژه دریافت تأیید نوع (Type Approval) باشد، شناسایی مقررات قابل اعمال یکی از پایههای برنامه Homologation محسوب میشود. باید مشخص شود برای نوع خودرو، سیستم یا قطعه موردنظر چه تأییدیههایی لازم هستند و چه شواهدی باید برای مرجع مربوط فراهم شوند.
تأیید نوع فقط انجام مجموعهای از آزمونها نیست. پیکربندی محصول، مدارک فنی، مرجع تأیید نوع، خدمات فنی تعیینشده و الزامات انطباق تولید نیز بسته به چارچوب مقرراتی مربوط اهمیت دارند.
در مقاله «Type Approval و Homologation چه تفاوتی دارند؟» این فرآیند و تفاوت میان انجام آزمون و صدور تأییدیه را جداگانه توضیح دادهایم.
آیا استانداردهای مشتری هم باید وارد ماتریس شوند؟
اگر الزامات مشتری برای پروژه لازمالاجرا هستند، بله؛ اما بهتر است منشأ آنها از الزامات مقرراتی قابل تشخیص باشد. یک خودروساز ممکن است الزاماتی فراتر از حداقل الزامات قانونی داشته باشد و تأمینکننده بر اساس قرارداد یا مشخصات فنی موظف به رعایت آنها باشد.
مخلوط کردن این دو منبع میتواند بعداً مشکل ایجاد کند. اگر یک الزام قانونی تغییر کند، باید بدانیم کدام موارد تحت تأثیر قرار گرفتهاند و اگر نسخه جدیدی از مشخصات فنی مشتری منتشر شود نیز باید اثر آن بهصورت جداگانه بررسی شود.
بنابراین استفاده از ستون «منشأ الزام» در ماتریس میتواند بسیار مفید باشد.
تغییر پیکربندی چه اثری بر استانداردهای قابل اعمال دارد؟
قابلیت اعمال الزامات یکبار برای همیشه تعیین نمیشود. اگر پیکربندی محصول تغییر کند، بعضی تصمیمهای قبلی ممکن است نیازمند بازنگری باشند.
اضافه شدن یک عملکرد جدید، تغییر گروه خودرویی، تغییر معماری قوای محرکه یا نصب تجهیزات جدید میتواند بسته به مقرره روی الزامات قابل اعمال اثر بگذارد. بنابراین فرآیند مدیریت تغییرات باید اثر احتمالی تغییر بر الزامات مقرراتی را نیز بررسی کند.
این موضوع دلیل دیگری برای ثبت مبنای تصمیم درباره قابلیت اعمال است. اگر بدانیم چرا الزامی قابل اعمال یا غیرقابل اعمال تشخیص داده شده، پس از تغییر محصول سریعتر میتوان مشخص کرد آیا مبنای تصمیم قبلی همچنان معتبر است یا خیر.
اشتباهات رایج در شناسایی استانداردهای قابل اعمال چیست؟
یکی از خطاهای رایج، کپی کردن فهرست الزامات محصول قبلی بدون بررسی تفاوت پیکربندی است. محصول جدید ممکن است از نظر ظاهری مشابه باشد، اما یک عملکرد جدید الزام دیگری را فعال کند یا ویژگیای تغییر کرده باشد که قابلیت اعمال الزامات را تحت تأثیر قرار دهد.
خطای دیگر، اتکا به عنوان استاندارد بدون مطالعه دامنه کاربرد است. عنوان میتواند موضوع کلی سند را نشان دهد، اما تمام شرایط کاربرد آن را مشخص نمیکند. استفاده از نسخه قدیمی استاندارد، نادیده گرفتن مقررات انتقالی و مخلوط کردن الزامات مشتری با الزامات قانونی نیز میتوانند باعث اشتباه شوند.
همچنین نباید فرض کرد «اگر آزمایشگاه آزمونی را انجام میدهد، پس آن آزمون برای محصول من لازم است». آزمایشگاه تواناییها و خدمات آزمونی خود را ارائه میکند؛ نیاز پروژه باید از الزامات واقعی محصول استخراج شود.
چه زمانی باید استانداردهای قابل اعمال را بررسی کنیم؟
هرچه زودتر، بهتر. الزامات مقرراتی میتوانند روی معماری محصول، جانمایی اجزا، انتخاب قطعات، نرمافزار و حتی راهبرد انتخاب تأمینکنندگان اثر بگذارند. شناسایی یک الزام جدید پس از تثبیت طراحی ممکن است تغییرات پرهزینهای ایجاد کند.
بررسی اولیه بهتر است در مراحل طراحی مفهومی و تعریف الزامات آغاز شود و با افزایش بلوغ محصول دقیقتر شود. در طول پروژه نیز پایش تغییرات مقرراتی اهمیت دارد تا اصلاح استانداردها، مقررات و زمانبندی اجرای آنها شناسایی شوند.
پیش از مراحل DV/PV، تأیید نوع و آغاز تولید انبوه نیز بازبینیهای مشخصی میتوانند کمک کنند تا ماتریس الزامات بهروز باشد و پیکربندی واقعی محصول را منعکس کند.
چه کسی باید الزامات قابل اعمال را تعیین کند؟
این فعالیت معمولاً نیازمند همکاری چند حوزه است. تیم مقررات و تأیید نوع، الزامات بازار را دنبال میکند؛ تیم مهندسی پیکربندی و عملکرد محصول را میشناسد؛ مهندسان آزمون درباره روشهای ارزیابی اطلاعات دارند و تأمینکنندگان نیز ممکن است مسئول بررسی الزامات مربوط به قطعات خود باشند.
در پروژههای کوچکتر ممکن است این نقشها در افراد کمتری جمع شوند، اما اصل موضوع تغییر نمیکند: تصمیم درباره قابلیت اعمال الزامات باید هم بر شناخت مقرره و هم بر شناخت محصول استوار باشد. مطالعه مقرره بدون شناخت پیکربندی کافی نیست و شناخت خودرو بدون بررسی دامنه کاربرد سند نیز نتیجه قابل اتکایی ایجاد نمیکند.
در پروژههایی که استانداردهای قابل اعمال یا برنامه آزمون نیازمند بررسی هستند، خدمات مهندسی و مشاوره تات میتواند برای بررسی الزامات فنی و برنامهریزی فعالیتهای آزمون مورد استفاده قرار گیرد.
یک چکلیست ساده برای شروع بررسی مقرراتی
پیش از نهایی کردن ماتریس، حداقل باید بتوان به این سؤالها پاسخ داد: محصول دقیقاً چیست و چه پیکربندیای دارد؟ بازار هدف کجاست؟ گروه خودرویی یا طبقهبندی قطعه چیست؟ منابع مقرراتی معتبر کداماند؟ دامنه کاربرد و تعاریف هر سند چه میگویند؟ چه شرایطی باعث قابل اعمال یا غیرقابل اعمال شدن الزامات میشوند؟ نسخه قابل اعمال چیست؟ وضعیت اجرای الزام چگونه است؟ و برای اثبات انطباق چه شواهد یا روش ارزیابیای موردنیاز خواهد بود؟
اگر پاسخ یکی از این سؤالها مشخص نیست، بهتر است وضعیت الزام هنوز قطعی اعلام نشود. ثبت وضعیت «در انتظار تعیین تکلیف (TBD)» در مرحله بررسی، بسیار بهتر از ثبت تصمیمی است که مبنای فنی یا مقرراتی مشخصی ندارد.
ماتریس الزامات مناسب قرار نیست عدم قطعیتهای پروژه را پنهان کند؛ باید آنها را قابل مشاهده، قابل پیگیری و قابل مدیریت کند.
فهرست استانداردها پایان کار نیست؛ نقطه شروع است
شناسایی استانداردهای قابل اعمال به معنی جمعآوری بیشترین تعداد استاندارد ممکن نیست. هدف این است که برای محصول مشخص، پیکربندی مشخص، بازار مشخص و زمان مشخص بدانیم چه الزاماتی واقعاً باید مدیریت شوند.
برای رسیدن به این پاسخ باید از شناخت محصول شروع کرد، طبقهبندی آن را تعیین کرد، منابع رسمی را شناخت، دامنه کاربرد و تعاریف را بررسی کرد، شرایط قابل اعمال بودن الزامات را استخراج کرد، نسخه و مقررات انتقالی را شناخت و سپس وضعیت اجرای الزامات در بازار هدف را به تحلیل اضافه کرد. پس از این مراحل است که هر الزام میتواند وارد برنامه تصدیق، برنامه آزمون یا فرآیند تأیید محصول شود.
بنابراین وقتی با فهرستی طولانی از استانداردها روبهرو میشویم، سؤال مناسب این نیست که «کدامها را آزمون کنیم؟» ابتدا باید پرسید: «کدامیک واقعاً برای پیکربندی محصول من قابل اعمال هستند، چرا قابل اعمال هستند و بر اساس کدام مرجع و نسخه باید انطباق با آنها را نشان دهم؟» پاسخ مستند به همین سؤال، پایه یک ماتریس الزامات مقرراتی قابل اتکا و یک برنامه آزمون هدفمند است.