★ISO/TS 22163认证知识★---★ISO/TS 22163认证标准规则★
8 运行
8.1运行的策划和控制
为满足产品和服务提供的要求，并实施第6章所确定的措施，组织应通过以下措施对所需的过程（见4.4）进行策划、实施和控制： a)确定产品和服务要求；
b)建立下列内容的准则：1）过程；
2）产品和服务的接收。
c)确定所需的资源以使产品和服务符合要求；
d)按照准则实施过程控制；
e)在必要的范围和程度上，确定并保持、保留成文信息，以：1）确信过程已经按策划进行；
2）证实产品和服务符合要求。
策划的输出应适于组织的运行。
组织应控制策划的变更，评审非预期变更的后果，必要时，采取措施减轻不利影响。
组织应确保外包过程受控（见8.4）。
8.1.1 过程转移或外包的策划
组织必须建立、实施和保持一个文件化的过程，用以影响组织产品和服务质量的外包过程的策划。
该过程必须包括： a)可行性研究；
b)风险评估；
c)策划外包所需的措施；
d)与顾客沟通，必要时；
e)FAI（见8.9），如当生产过程的外包；
f)保留外包活动的成文信息。
当多现场的组织将一个过程从一个现场转移到另一个现场时必须执行这个过程。
注1：过程外包的策划可为在执行8.4要求之前的制造或购买决定作准备。
注2：引发外包可能是资源缺乏或一个战略决定。
注3：为过程外包或转移的策划，可能执行变更管理过程（见8.1.5）。
8.1.2投标管理
组织必须建立、实施和保持一个文件化过程以管理投标。
该过程必须包括： a)需求管理（见8.2）；
b)控制的类型和程度（见6.1.3.3）；
c)风险和机会管理（见6.1），包括财政评估；
d)输入组织知识（如经验总结）（见7.1.6）；
e)交付物的策划包括成本（如时间、定价）；
注：在投标测算中可使用项目标准成本结构。
f)为合同执行策划资源；
g)批准报价。
组织必须保留其投标管理活动的有关成文信息。
组织必须规定处理投标、相应需求管理人员必要的能力和对应级别。
8.1.3 项目管理
8.1.3.1组织必须建立、实施和保持一个文件化过程以管理项目。
注1：项目管理过程的范围取决于一个组织的业务模式。大多数轨道行业公司是从投标阶段直至质保期结束。然而个别情况可以仅限于设计和开发（如一个新产品系列或平台的开发）。
该过程必须包括：
a)需求管理（见8.2）；
b)控制的类型和程度（见6.1.3.3）；
注2：组织可以依据风险和机会所规定的控制类型和程度，将项目进行分类。
c)项目阶段和活动（如策划、执行、监视、控制和结束）；
d)里程碑和每个阶段的交付物，通过门方法来管理；
注3：每个阶段交付物可以规定在门检查表中。
e)在阶段评审中（见8.1.3.4）通过门准则来做出决定接收、有条件接收或拒收，以授权进入下一阶段；
注4：有条件接收可以是有行动计划的接收。
f)归零要求；
g)记录和控制开口项，并落实适当资源来关闭它们。
8.1.3.2该过程应包括：
a)如阶段评审决定拒收时一个升级过程，以促进问题解决；
b)与顾客、关键外部提供方评审有关SWOT；
c)至少在项目结束期间识别最佳实践和经验教训（见7.1.6）；
8.1.3.3项目必须管理其成文信息，包括：
a)项目信息的评审、存储（如：标准化文件包结构）、控制和维护；
b)保留成文信息（如计划、排程、评审输出、报告等），按7.5要求；
8.1.3.4阶段评审必须：
a)执行；
1）在工作结构分解所规定的层级展开；
2）在项目层级考虑交付物的评审；
b)不能通过除非在阶段评审之前开口项被关闭。否则，由最高管理者批准搁置。
组织必须规定阶段评审的强制和非强制参加人员。
8.1.3.5 项目整合管理
8.1.3.5.1项目必须建立和实施一个项目管理计划，该计划必须包括或引用：
a)一个项目组织架构图；
b)项目目标、框架条件、分配的资源、排除内容；
c)指定项目组成员的职责和权限；
d)指定项目执行中遵照的规则；
e)来自有关职能、现场和合作方的合作计划，使项目管理计划协调一致；
注1：典型职能是销售、设计、制造、质量、生产、采购、现场支持和其他相关人员，适当时包括外部提供方和顾客。
f)各阶段交付物（如为顾客的合同交付物或为产品认可的预期设计输出的成文信息）包括：
1）识别由顾客（如顾客产品认可点）或授权机构来批准的交付物，在必要之处；
2）外部提供方交付物（如文件、材料、服务）；
g)变更的控制（如范围、时间、成本）见8.1.5。
注2：项目管理计划可以包括所有其他在8.1.3要求的辅助计划（如沟通、人力资源、质量）。
8.1.3.5.2当一个项目涉及多现场或合作方时，项目管理计划必须附加包括或引用：
a)工作分工和运作接口；
b)指定职责和权限；
c)沟通渠道（项目内部和与顾客或相关方）；
d)适用过程和其他有关过程的成文信息。
8.1.3.6 项目范围管理
针对范围管理，项目管理过程必须包括：
a)识别项目要求（如时间、商务、技术）见8.2；
b)明确工作范围；
c)细化工作包（如工作分解结构WBS）；
d)分配工作包到工作包所有者；
e)验证工作包。
针对范围管理，项目管理过程应包括一个标准化工作分解结构WBS。
注：设计和开发中的范围管理描述在8.3.2。
8.1.3.7 项目时间管理
8.1.3.7.1关于时间管理，项目管理过程必须包括：
a)确定并排序活动；
b)估算活动的资源和持续时间；
c)进度考虑：1）过去的经验；
2）长周期内容，和外部提供方联合管理。
8.1.3.7.2项目进度必须：
a)包括持续时间、开始、结束和工作包（包括外部提供方的）相互依赖关系；
b)包括关键路径；
c)给主生产计划提供输入（见8.5.7）
项目应使用应用软件对活动进行排定和跟踪。
项目不能改变排定的交付顾客日期，除非被顾客授权。
8.1.3.8 项目成本管理
关于成本管理，项目管理过程必须包括：
a)基于投标测算确定预算；
b)在成本科目架构内，分配预算到各自工作包；
c)成本的定期控制，包括完成时实际和估算成本。
项目应使用标准化应用软件来跟踪成本。
项目必须不增加项目预算，除非由组织授权规定时。
8.1.3.9 项目质量管理
关于质量管理，项目管理过程必须包括质量保证和控制活动的策划和实施。
项目必须建立和实施一个项目质量管理计划。
注：见ISO10005和10006指南。
8.1.3.10 项目人力资源管理
8.1.3.10.1关于人力资源管理，项目管理过程必须包括：
a)确定和描述项目岗位（如项目经理、项目采购员、项目质量经理）、相对业务线职能
的职责、报告关系和赋予权力（如财务批准权、利润和损失责任、等等）；
b)形成项目团队；
c)依据在7.1.2、7.2和7.3规定要求来管理项目团队；
8.1.3.10.2项目必须建立、实施和保持一个人力资源计划。该计划必须包括： a)指派核心团队成员；
b)人员分配（如组织架构图）。
8.1.3.10.3组织必须对项目经理和核心团队成员确定必要的能力和相关的级别，关于：
a)项目管理；
b)在使用的项目管理应用软件；
c)团队工作和沟通；
d)项目质量管理；
e)风险和机会管理；
f)所交付产品和服务。
8.1.3.10.4组织应对项目经理确定必要能力和相应级别，关于：
a)领导力；
b)项目财务。
8.1.3.11 项目沟通管理
8.1.3.11.1 关于沟通管理，项目必须：
a)应用在7.4和8.2.1中规定的要求；
b)建立、实施和保持一个项目沟通管理计划；
c)执行定期项目评审以监视项目进程，核心团队成员出席（见8.1.3.10.2）。
如果有偏离项目目标，项目必须识别并实施适当的沟通以避免任何对顾客或组织的影响。
8.1.3.11.2项目评审必须包括：
a)项目绩效（实际状况对比策划状况）基于9.1.1规定的KPIs（如要求、时间、成本）；
b)预测（如完成时的时间、预计成本）；
c)实际风险和机会，包括有关措施的状况；
d)跟踪以往评审的开口项和措施。
项目评审的输出应报告给项目经理以上管理层，包括问题的决定或升级。
8.1.3.12 项目风险和机会管理
8.1.3.12.1 针对风险和机会管理，项目必须：
a)应用6.1规定的要求；
b)建立、实施和保持一份登记包括风险和机会的财务分析；
c)保留风险和机会管理的成文信息。
8.1.3.12.2针对风险和机会管理，项目应：
a)职能线经理参加风险评审；
b)考虑与顾客所商定产品的功能和集成成熟度，作为风险管理的输入；
c)管理成本节省（以平衡损失）或成本增加（以增加保证金）的机会，尤其为了恢复项目预算恶化。
8.1.3.13 项目采购管理
针对项目采购管理，必须应用8.4规定的要求。
8.1.4 配置管理
8.1.4.1 组织必须建立、实施和保持一个文件化的适于其产品的配置管理过程。
注：配置管理过程适于硬件和软件。
该过程必须考虑，至少在：a)技术状态管理策划；
b)产品分解结构直至最低可更换单元；
c)确定技术状态项，至少有关安全件；
d)建立技术状态基线，最低为“设计”、“建造”和“维护”；
e)对技术状态的变更控制依据8.1.5；
f)技术状态纪实；
g)可追溯性标识的准则（如序列、批次号）；
组织必须保留有关成文信息。
8.1.4.2该过程应：
a)考虑定期内部技术状态审核；
b)整合外部提供方的技术状态管理体系（如数据转移接口）；
c)作为技术状态项，考虑在设计、开发、生产和维护中所用工具和软件；
d)由一个应用软件支持。
8.1.4.3 注：见ISO10007 指南。
8.1.5 变更管理
8.1.5.1 组织必须建立、实施和保持文件化过程以管理变更。这些过程必须包括：a)在这个标准中规定的要求，如：1)在8.2.4用于产品和服务要求；
2)在8.3.6用于设计和开发变更；
3)在8.5.6用于生产和服务提供；
b)变更申请；
c)原因分析，当变更源于失效；
d)变更影响分析，考虑风险和机会；
e)对所建议的变更予以验证，以避免不利影响；
f)通知并与顾客、外部提供方和授权机构达成协议，基于准则至少包括变更影响到他们的要求；
注1：变更影响到顾客要求可引发一个偏差许可；
注2：当顾客批准该变更时，来自一个偏差许可的所规定变更申请可以关闭。
g)为变更批准指派职责和权限（如变更控制委员会）；
h)实施前变更的批准；
i)实施变更；
j)实施和跟踪的验证。
这些过程必须由一个应用软件支持。
8.1.5.2这些过程应包括： a)策划措施以将变更影响降到最低；
b)由一个应用软件支持变更的可追溯性；
8.1.5.3对产品和服务技术变更，这些过程必须还包括：a)一个变更影响分析，在
1)已经交付的组件和产品；
2)顾客规范和技术状态；
3)有关成文信息（如质量保证计划、FMEA报告）
b)重新评价功能，非功能和集成要求；
c)再确认活动基于影响分析的结果；
d)要求保留关于被变更产品和服务的序列号和/或日期的成文信息。
注：变更可能引起可靠性的缺乏、老化（产品或外部提供方）、标准/规程/法律/运行需求的进化、成本优化、或特定事件：事故、差错、天气或顾客工程变更通知单。
8.1.5.4 对产品和服务技术变更，这些过程应还包括重新评估运行和集成成熟度。
8.1.5.5 变更管理要求必须应用到：a)项目管理（见8.1.3）；
b)产品和服务的要求（见8.2.4）；
c)产品和服务的设计开发（见8.3.6）；
d)外部提供过程、产品和服务的控制（见8.4）；
e)生产和服务提供（见8.5.6），包含生产过程、生产设备、生产程序（软件）和生产地点。
注1：变更发动可能是外部提供方或组织为了改进或纠正设计，或顾客工程变更通知单。
注2：启动变更过程的触发点是被批准的成文信息的预期变更。
8.2 产品和服务的要求
8.2.1 顾客沟通
与顾客沟通的内容应包括：a)提供有关产品和服务的信息；
b)处理问询、合同或订单，包括更改；
c)获取有关产品和服务的顾客反馈，包括顾客投诉；
d)处置或控制顾客财产；
e)关系重大时，制定应急措施的特定要求。
8.2.1.1 顾客沟通–补充
当预计延误且不能避免（如延误来自外部提供方），组织必须向顾客沟通。
8.2.2 产品和服务要求的确定
a) 在确定向顾客提供的产品和服务的要求时，组织应确保：产品和服务的要求得到规定，包括：
1）适用的法律法规要求；
2）组织认为的必要要求。
b)提供的产品和服务能够满足所声明的要求。
8.2.2.1 产品和服务要求的确定–补充
8.2.2.1.1当确定要求时，组织必须考虑：a)功能、非功能和集成要求；
b)RAMS/LCC要求。
8.2.2.1.2当确定要求时，组织应考虑：a)来自类似产品/投标/项目的经验；
b)产生于市场分析的要求；
c)老化要求（如来自市场、外部提供方、法规的信息）；
d)关键产品特性；
e)有关产品寿命结束的要求（如处置、再循环）。
注：与外部提供方一起的老化管理可依据ISOTS22163老化指南。
8.2.3 产品和服务要求的评审
8.2.3.1组织应确保有能力向顾客提供满足要求的产品和服务。在承诺向顾客提供产品和服务
之前，组织应对如下各项要求进行评审： a)顾客规定的要求，包括对交付及交付后活动的要求；
b)顾客虽然没有明示，但规定的用途或已知的预期用途所必需的要求；
c)组织规定的要求；
d)适用于产品和服务的法律法规要求；
e)与以前表述不一致的合同或订单要求。
组织应确保与以前规定不一致的合同或订单的要求已得到解决。
若顾客没有提供成文的要求，组织在接受顾客要求前应对顾客要求进行确认。
注：在某些情况下，如网上销售，对每一个订单进行正式的评审可能是不实际的，作为替代方法，可评审有关的产品信息，如产品目录。
8.2.3.2适用时，组织应保留与下列有关的成文信息：a)评审结果；
b)产品和服务的新要求。
8.2.4 产品和服务要求的更改
若产品和服务要求发生更改，组织应确保相关的成文信息得到修改，并确保相关人员知道已
更改的要求。
8.2.5 –补充
组织必须建立、实施和保持一个文件化过程以管理产品和服务要求。
该过程必须：a)考虑8.2规定的要求；
b)应用于：
1)在投标之前满足市场预期的新产品和服务的设计开发（如平台、产品系列）；
2)投标管理（提交标书、接受合同或订单）；
3)项目执行（如接受合同或订单变更）；
4)变更控制（见8.1.5）。
注：该过程可以包括在项目管理过程中。
c)通过多方论证方法执行，适用时包括内部和外部干系人；
d)至少包括这些步骤：
1)确定（见8.2.2）；
2)评审（见8.2.3）；
3)验证；
4)确认；
e)确保要求是：1)分别逐项检查；
2)评估和考虑；
3)评价有关风险和机会；
4)由相关人员适当的转换、理解、共识、逐层分解和承诺；
5)完整、明确、可验证和可行的；
6)技术要求被文件化在需求说明书中；
注：需求说明书可以由顾客提供或组织编制。
更新如发生变更。
8.3 产品和服务的设计和开发
8.3.1总则
组织应建立、实施和保持适当的设计和开发过程，以确保后续的产品和服务的提供。
8.3.1.1 总则–补充
8.3.1.1.1在8.3规定的要求应用于新技术的设计开发或引进（如复合材料制品、激光焊
接）。
组织为新技术的落实必须执行过程FMEA。
设计和开发过程必须：
a)考虑8.3.2, 8.3.3, 8.3.4, 8.3.5, 8.3.6描述有关策划、输入、控制、输出和变更的要求；
b)文件化；
c)结合IEC62278（EN50126）或等同标准的与安全有关的产品，依据IEC62425（EN50129）或等同标准规定安全案例；
8.3.1.1.2组织必须确定设计开发人员的必要能力和相应级别，有关：
a)需求管理；
b)技术状态管理；
c)质量保证方法。
8.3.2 设计和开发策划
在确定设计和开发的各个阶段和控制时，组织应考虑：
a)设计和开发活动的性质、持续时间和复杂程度；
b)所需的过程阶段，包括适用的设计和开发评审；
c)所需的设计和开发验证、确认活动；
d)设计和开发过程涉及的职责和权限；
e)产品和服务的设计和开发所需的内部、外部资源；
f)设计和开发过程参与人员之间接口的控制需求；
g)顾客及使用者参与设计和开发过程的需求；
h)对后续产品和服务提供的要求；
i)顾客和其他有关相关方期望的对设计和开发过程的控制水平；
j)证实已经满足设计和开发要求所需的成文信息。
8.3.2.1 设计和开发策划–补充
8.3.2.1.1 在确定设计和开发的阶段和控制时，组织必须考虑：
a)每个过程阶段的目标；
b)产品构造（如产品分解结构）；
c)技术状态控制，见8.1.4；
d)在产品架构的规定层级上进行设计评审、验证和确认（如首先从部件设计评审、接着
子系统设计评审、然后上升为系统设计评审）；
e)针对特殊过程的设计评审、验证和确认；
设计和开发的阶段和控制必须文件化（如在一个质量保证计划中）。
注：设计可以是方案设计、初步设计、最终设计。
8.3.2.1.2在确定设计和开发的阶段和控制时，组织应考虑：
a)每个设计和开发阶段满足目标的质量保证方法（如规定在一个质量保证计划）；
b)控制非功能、功能、性能和集成要求的方法；
c)控制集成和运行成熟度的方法。
注1：如果特殊过程要求作为设计输入，依据ISOTS22163特殊过程指南，这些特殊过程的风险评估是设计和开发过程的一部分。
注2：和外部行业协作可以考虑作为外部提供服务（见8.4）。
8.3.3 设计和开发输入
组织应针对所设计和开发的具体类型的产品和服务，确定必需的要求。组织应考虑：
a)功能和性能要求；
b)来源于以前类似设计和开发活动的信息；
c)法律法规要求；
d)组织承诺实施的标准或行业规范；
e)由产品和服务性质所导致的潜在失效后果。
针对设计和开发的目的，输入应是充分和适宜的，且应完整、清楚。
相互矛盾的设计和开发输入应得到解决。
组织应保留有关设计和开发输入的成文信息。
8.3.3 设计和开发输入–补充
关于设计和开发输入，组织必须考虑8.2.2规定的要求。
组织必须保留有关成文信息。
加上，组织应考虑：
a)生产和例行试验要求，包括特殊过程，所以在这个阶段生产设备是已知的；
b)设计原则的应用（如可制造性设计、可测试性设计、可维修性设计）。
注：可维修性设计可依据ISOTS22163维修指南来管理。
8.3.4设计和开发控制
组织应对设计和开发过程进行控制，以确保：
a)规定拟获得的结果；
b)实施评审活动，以评价设计和开发的结果满足要求的能力；
c)实施验证活动，以确保设计和开发输出满足输入的要求；
d)实施确认活动，以确保形成的产品和服务能够满足规定的使用要求或预期用途；
e)针对评审、验证和确认过程中确定的问题采取必要措施；
f)保留这些活动的成文信息。
注：设计和开发的评审、验证和确认具有不同目的。根据组织的产品和服务的具体情况，可单独或以任意组合的方式进行。
8.3.4.1 设计和开发控制–补充
组织应对设计和开发过程进行控制，考虑：
a)功能分解；
b)集成和运行成熟度；
c)质量保证方法的实施。
8.3.4.2 设计评审
关于设计评审，组织必须确定：a)授权进入下一阶段的准则（如检查表、验收规则）；
b)强制和可选择的参与者；
参加设计评审的职能代表必须具有规定的能力级别和各自决策的授权。
组织必须保留有关设计评审的成文信息。
组织应使用多方论证方法来执行设计评审。
注1：参与者可以是职能领导（如RAMS、服务），内部和外部顾客，生产方面的专家。
注2：设计评审可以是项目阶段评审的一部分或一个输入（见8.1.3.3）。
8.3.4.3 设计验证
组织必须确保性能要求被验证。
组织必须保留有关设计验证的成文信息。
注：设计验证活动可以是有限元分析、计算、仿制、设计伴随测试。
8.3.4.4 设计确认
8.3.4.4.1 关于设计确认，组织必须：
a)确保功能、非功能和集成要求被确认；
b)在交付或调试结束之前完成确认，或和顾客协议控制计划并监视它们直至完成。
注：设计确认活动如鉴定测试、型式试验、产品批准测试等等。
8.3.4.4.2 针对设计确认，当测试是必要时，组织必须策划、控制和评审这些测试。组织必须
确保：a)规定测试计划、规范或程序：
1)测试目标；
2)测试条件和可重复环境；
3)被测试产品；
4)所需资源；
5)接受准则；
6)被记录参数；
7)操作方法；
8)测试的绩效；
b)提交正确技术状态的产品并作为技术状态基线被记录；
c)满足接受准则。
组织必须保留测试结果的成文信息。
8.3.5设计和开发输出
组织应确保设计和开发输出：
a)满足输入要求；
b)满足后续产品和服务提供过程的需要；
c)包括或引用监视和测量要求，适当时，包括接收准则；
d)规定产品和服务特性，这些特性对于预期目的、安全和正常提供是必需的；
组织应保留有关设计和开发输出的成文信息。
8.3.5.1设计和开发输出–补充
8.3.5.1.1组织必须确保设计和开发输出：
a)放行前被验证和批准；
b)依据生产过程输入要求的方式验证；
c)包括文件（如操作、维修手册）和有关实际应用的培训；
8.3.5.1.2 组织应：
a)确保输出相对输入要求的可追溯性；
b)确定设计批准的授权和接受准则；
c)确定当发生批准的接受准则没有满足时升级规则；
d)确保生产和服务提供信息包括产品存储要求。
8.3.5.1.3
注：设计和开发输出可以包括如规范和图纸（也有来自外部提供方的）、材料信息、生产过程流程图和或布局图、检验和测试计划、生产作业指导书、过程和产品批准接受准则、防错活动的结果（如FMEA）适当时、快速检测方法、产品和/或生产过程不合格的反馈。
8.3.6 设计和开发更改
组织应对产品和服务在设计和开发期间以及后续所做的更改进行适当的识别、评审和控制，
以确保这些更改对满足要求不会产生不利影响。
组织应保留下列方面的成文信息：
a)设计和开发更改；
b)评审的结果；
c)更改的授权；
d)为防止不利影响而采取的措施。
8.4 外部提供的过程、产品和服务的控制
8.4.1 总则
组织应确保外部提供的过程、产品和服务符合要求。
在下列情况下，组织应确定对外部提供的过程、产品和服务实施的控制：
a)外部供方的产品和服务将构成组织自身的产品和服务的一部分；
b)外部供方代表组织直接将产品和服务提供给顾客；
c)组织决定由外部供方提供过程或部分过程。
组织应基于外部供方按照要求提供过程、产品或服务的能力，确定并实施对外部供方的评价、选择、绩效监视以及再评价的准则。对于这些活动和由评价引发的任何必要的措施，组织应保留成文信息。
★重庆ITSS认证★重庆CS认证★重庆CCRC认证★重庆CMMI认证★重庆ISO27001认证★重庆军标认证★重庆保密认证★重庆CCCF认证★重庆特种设备许可证★重庆LA认证★重庆CNAS认证★重庆CMA认证★ 重庆两化融合认证★
|
