本帖最后由 dqs123 于 2024-12-12 11:05 编辑
VDA条款详细解读分享:
P3.2* 根据产品和过程要求,是否对可行性进行了全面的评价?
P3.1要求我们在产品和过程策划之前首先需要收集足够多的要求,包括但不限于客户要求,法律法规要求,其他相关方要求等等。在收到这些要求之后,下一步的动作就是评审可行性,也可以理解为能不能按照要求做到。通常会从 质量、 成本、交付、物流、 安全等方面进行综合考量。
例如: 客户关于项目时间进度节点的要求能否满足(客户为了抢占市场,尽快推出新品、竞品,将原本需要两年时间的开发周期压缩到6个月,这个时候组织就要评估能够按照既定的节点和时间范围实现客户要求)? 现有的技术积累能否实现客户预期的功能? 相应的法律法规要求能不能满足?按照国家退出的国六排放 标准,组织的最新研制的发动机能否达到?等等;
产品的可追溯要求能否达到要求?
产品一旦出了问题的责任划分能否接受?
等等等等。
采用跨科学程序评估可行性(包括潜在生产场所)
所谓的跨学科程序,指的是多方论证的方法。 什么是多方论证呢?多部门、多学科涉及到的不同职能的人员参与到评审过程中,可能包含设计、生产、工艺、质量、维修、物流、采购、精益等等不同部门的人员,从不同的方向和维度提出各自的意见和建议,目的是充分考虑各个层面可能存在的 风险,为后续的风险 预防提供输入。
所有明确的产品和过程特殊特性(技术、功能、质量、物流、软件等)应对可行性进行检查
可行性检查应该设计到技术、功能、质量、物流、软件等方面的产品与过程相关的特殊特性,项目前期团队会初步识别产品和过程的特殊特性并形成清单,同时对这些特性进行可行性检查。
技术上的可行性,例如材料的强度能够满足策划的要求,设计的 机械结构能否抵挡住策划的冲击,要求的制造精度能否实现等;
功能上的可行性评估,例如可靠性,耐久,稳定性等,响应速度等目标能否实现; 质量方面的可行性检查,例如 PPM目标、返工返修方案、失效分析要求等能否达到要求; 物流方面的可行性检查,例如包装要求、物流时间、及时率、附加运费等要求能否实现; 软件方面的可行性检查例如:软件复杂程度、功能、可安装性、授权、更新方案、诊断等方面(技术、设备是否具备)的要求能够实现。
在可行性研究中,应考虑物质和人力资源
产品和过程的开发策划还要考虑到物质资源和人力资源。
物质资源可能包括:基础设施(厂房、车间等),设备、工装、治具、水、电、气等等;
人力资源可能包括:有资质的员工,有经验的员工,有技能的员工(CAD、GD&T、热处理、焊接,软件开发、ASPICE等),以及足量数量的员工保证不会因为超负荷影响项目的进度、生产质量和节拍。
可行性研究的结果应在提交报价前完成
可行性研究是报价的重要输入,因为可行性研究阶段考虑到客户要求能否实现以及可能涉及到的各个方面的成本,例如人力、设备、材料、软件授权等。所有这些成本加上组织期望的利润,结合市场 环境(例如竞争对手的价格)综合考量才能提交合理的报价。否则很可能给出的价格在客户面前毫无吸引力,行业上也毫无竞争力,从而丧失发包定点的机会。
应确保外购件的可行性
很少有组织会实现整个产业链的自给自足,不可避免的就要涉及到外购,哪怕可能是一颗不起眼的螺母,都要确保其可行性,例如供方的技术经验、供方完整完成项目的经验、螺母的规格型号、尺寸、强度、防锈、包装方案是否能够满足组织的要求。
如果顾客要求无法被满足,应告知顾客,顾客可以在合同授予前批准该偏差
汽车行业特别是一些 OEM会向供方下发 CSR(customer special requirements),不同客户对CSR的称呼不同,但都会在CSR中定义一些要求,例如变更要求、问题处理的要求、过程能力要求等等。所有这些要求组织都需要在合同签订之前仔细逐条研究,避免一些不合理或者无法实现的条款给组织带来严重影响,并及时与客户协商。 有些时候客户甚至会提出无条件索赔的要求,或者远比行业平均水平高出很多的结算周期等等。
还比如,有些客户产线上的员工只要出现变化,如转岗,新入职等情况都要提出变更申请,这显然是很难实现的要求,这个时候组织就要与客户沟通这方面要求的适用性。
出于技术 保密,有的组织并不愿意提交 FMEA内容,通常会与客户协商提交FMEA的封面,等等这些都是在顾客要求的基础之上协商的结果,所以与顾客保持沟通很重要。
应具备生产线以及使用过程更新的程序刷写方案(如有要求)
程序刷写有些组织也叫烧录,是将软件程序传输到ECU(electrical control unit, 电控单元,如ABS防抱死、ECS、EPB车身稳定控制等)的CPU中。具体的烧录方案可能包括:什么时候,什么地方,用什么设备,什么人员进行以及烧录后的 测试和功能验证等。通常软件会随着车辆应用场景的不断丰富而不断更新升级,所以成熟稳定的烧录方案是需要的。
|