4장. RFQ·FMEA·WS까지 쌍방향 연동 시스템 구축
이 장에서 얻어 가는 것
RFQ를 DFMEA에 복사하고, PFMEA의 관리방법을 WS에 복사하는 것만으로는 연동 시스템이 아니다. 진짜 연동은 요구사항이 현장 행동으로 변환되고, 그 행동의 결과가 다시 위험분석과 고객 요구사항의 충족 증거로 돌아오는 구조다.
이 장에서는 다음의 기술적 판단을 사용자가 직접 확인할 수 있도록 설명한다.
- RFQ의 문장을 요구사항 ID·조건·목표·검증방법으로 분해하는 방법
- DFMEA와 PFMEA를 구분하고 BOM·PFD를 연결의 기준으로 삼는 방법
- PFMEA의 관리특성을 CP와 작업표준(WS)의 행동·반응계획으로 변환하는 방법
- WS 실행결과·EP·자동검사·SPC·PM 데이터를 FMEA로 되돌리는 방법
- 추천은 시스템이 만들고, 적용·수정·폐기는 엔지니어가 확정하는 통제 원칙
단방향 문서가 고객 심사에서 실패하는 이유
설계팀은 RFQ와 도면을 보고 DFMEA를 작성하고, 제조팀은 PFD와 PFMEA를 만든다. 품질팀은 Control Plan을 정리하고 생산팀은 WS를 배포한다. 이 순서만 보면 시스템이 연결된 것처럼 보이지만, 실제로는 각 문서가 다음 문서의 근거가 되지 못하고 복사된 문장만 남는 경우가 많다.
| 현장에서 받는 질문 | 단방향 방식의 취약점 | 쌍방향 연동이 보여줘야 할 증거 |
|---|---|---|
| 이 WS의 작업기준은 어느 RFQ에서 출발했는가? | WS에 원천 요구사항 ID가 없다. | RFQ ID → 기능 → 특성 → 공정 → WS 단계의 추적 경로 |
| 작업자가 관리하는 특성은 왜 중요한가? | CP와 WS에 숫자만 있고 위험의 이유가 없다. | PFMEA 고장원인·영향·관리방법과 WS 행동의 연결 |
| 현장 결과가 기준을 바꿀 필요가 있는가? | 검사결과가 파일에 저장되어도 FMEA에 반영되지 않는다. | 결과 ID → 이상유형 → 영향평가 → FMEA·RFQ 재검토 이력 |
| PCN 후 무엇을 재검증했는가? | 개정 파일 목록만 있고 영향 논리가 없다. | 변경대상·영향 관계·재검증·승인·WS 개정의 완결 기록 |
문서를 많이 만드는 것이 품질 시스템을 성숙시키지 않는다. 질문에 대해 원천 요구사항, 기술 판단, 현장 실행, 객관적 증거를 한 번에 보여줄 수 있어야 한다.
쌍방향 연동의 데이터 모델
Smart FMEA의 연결은 파일 간 링크가 아니라 대상과 관계의 관리다. 사용자가 화면에서 선택하는 항목은 네 가지 층으로 분리된다. 이 구분이 있어야 시스템 추천과 엔지니어 확정을 혼동하지 않는다.
| 층 | 질문 | 자전거 제동 사례 | 왕복 방향 |
|---|---|---|---|
| 요구사항 | 무엇을 만족해야 하는가? | RFQ-BRK-017, 건식 제동력 50N 이상 | RFQ → FS·DFMEA |
| 판단 | 어떤 기능과 위험으로 해석하는가? | 패드 정렬, 유격, 체결토크, 감속 부족 | DFMEA·PFMEA ↔ RFQ |
| 실행 | 누가 언제 무엇을 어떻게 관리하는가? | WS-ASM-014의 방향확인·토크·기능검사 | FMEA·CP → WS |
| 증거 | 실제로 요구사항이 충족되었는가? | 자동검사 결과, SPC 추세, PM 이력, 부적합 조치 | WS·현장 → FMEA·RFQ |
각 관계에는 출처, 버전, 적용범위, 승인상태, 변경일, 담당자를 남긴다. “연결됨”이라는 표시만으로는 심사 대응이 되지 않는다. 어떤 근거로 연결되었는지와 현재 유효한지가 함께 보여야 한다.
RFQ를 FMEA의 출발점으로 바꾸는 요구사항 분해
RFQ 원문을 FMEA의 고장형태 칸에 붙여 넣으면 분석이 시작되기 전에 의미가 사라진다. 먼저 고객 요구를 검증 가능한 단위로 구조화하고, 그 다음 기능과 특성으로 변환해야 한다.
요구사항 분해의 다섯 필드
| 필드 | 기술적 질문 | 자전거 제동 예시 |
|---|---|---|
| Requirement ID | 변경되어도 추적 가능한 고유 식별자는 무엇인가? | RFQ-BRK-017 Rev.2 |
| 조건 | 어떤 사용·환경·하중에서 적용되는가? | 건식, 75kg 하중, 신규 패드, 20km/h |
| 목표 | 충족해야 하는 수치·범위·행동은 무엇인가? | 제동력 50N 이상, 유격 3~5mm |
| 검증 | 어떤 DV·SC&D·검사로 충족 여부를 판정하는가? | 제동력 시험, 유격 게이지, 반복 내구시험 |
| 승인 | 누가 해석과 예외를 확정하는가? | 설계·품질·고객 승인 기록 |
RFQ에서 DFMEA와 PFMEA를 나누는 기준
고객 요구가 제품의 의도와 성능을 말하면 DFMEA의 입력이 된다. 그 요구를 생산에서 실현하는 순서·조건·작업방법이 공정 위험으로 변환되면 PFMEA의 입력이 된다. 같은 요구사항을 두 문서에 복사하지 말고, 서로 다른 질문으로 전개한다.
| 구분 | DFMEA 질문 | PFMEA 질문 |
|---|---|---|
| 설계 | 제품이 제동력을 만들 수 있는 구조·재료·공차인가? | 그 구조와 특성을 공정에서 반복적으로 만들 수 있는가? |
| 고장 | 제품 기능이 어떤 조건에서 실패하는가? | 공정의 어떤 4M 원인이 제품 특성을 실패시키는가? |
| 검증 | DV·SC&D로 설계 의도를 검증했는가? | 공정검사·EP·자동검사·SPC로 생산 변동을 관리하는가? |
| 출력 | 도면·사양·BOM·설계대책 | PFD·CP·WS·PM·반응계획 |
FMEA 판단을 작업표준(WS)의 행동으로 변환하기
PFMEA와 Control Plan은 작업자에게 그대로 전달되는 문서가 아니다. WS는 위험을 줄이는 작업 행동과 이상 발생 시 반응을 현장에서 실행할 수 있는 언어로 바꿔야 한다. 따라서 WS는 CP의 특성명 복사본이 아니라, 관리방법을 실행 가능한 지시로 변환한 결과다.
WS 한 항목이 반드시 답해야 하는 질문
| WS 필드 | 사용자에게 보여야 할 내용 | 연결 원천 |
|---|---|---|
| 작업 목적 | 왜 이 확인 또는 조정을 하는가? | DFMEA 기능·PFMEA 고장영향 |
| 작업 대상 | 어느 부품·공정·특성을 다루는가? | BOM·PFD·공정번호 |
| 작업 방법 | 도구·방향·순서·조건·주의점은 무엇인가? | PFMEA 예방관리·CP 검사방법 |
| 합격 기준 | 수치·범위·외관·기능의 판정기준은 무엇인가? | RFQ·도면·FS·CP 규격 |
| 이상 반응 | 정지·격리·재작업·보고·재검증의 순서는 무엇인가? | PFMEA 검출관리·반응계획 |
| 기록 | 어떤 결과를 어디에 저장하고 누구에게 알리는가? | 검사 ID·SPC·추적성·승인 이력 |
좋은 WS는 작업자에게 “무엇을 측정하라”에서 멈추지 않고 “이 결과가 왜 중요하며 기준을 벗어나면 무엇을 멈추고 무엇을 격리할지”까지 알려준다.
자전거 제동 조립 WS의 연결 예
| WS 지시 | FMEA 위험 | 반응과 증거 |
|---|---|---|
| 패드 방향 화살표를 진행방향과 일치시킨다. | 패드 방향 반전으로 접촉 불량 | 작업 확인, 비전 결과, 이상품 격리 |
| 지정 토크로 체결하고 결과를 저장한다. | 체결토크 부족으로 유격 발생 | 토크 파형, 재체결, 영향 LOT 추적 |
| 레버 유격을 게이지로 확인한다. | 유격 과다로 입력 전달 불안정 | 측정값, 조정 횟수, 공정 재발 여부 |
| 기능시험 결과가 기준 미달이면 출하하지 않는다. | 제동력 미달로 정지거리 증가 | 자동검사 ID, 격리, 원인분석, 재검증 |
WS 실행 결과를 다시 FMEA와 RFQ로 올리는 방법
쌍방향 시스템에서 가장 차별화되는 부분은 역방향이다. 작업표준을 배포한 뒤 현장 데이터가 쌓여도 FMEA가 변하지 않는다면 시스템은 전자문서 보관함에 머문다. 단, 현장 결과가 들어왔다고 FMEA를 자동으로 덮어써서는 안 된다. 시스템은 신호를 수집하고 영향 후보를 제시하며, 엔지니어가 창의적 문제해결과 근거 검토를 거쳐 확정한다.
| 현장 신호 | 시스템의 후보 판단 | 엔지니어 확정 후의 조치 |
|---|---|---|
| 합격률 저하 | 특정 WS 단계·작업자군·설비군과 관계 탐색 | PFMEA 발생도·예방관리·교육을 재검토 |
| 조정 횟수 증가 | 공차·부품 편차·공정조건의 연결 후보 제시 | DFMEA 설계원인과 PFMEA 공정원인을 분리 분석 |
| SPC 추세 이탈 | 특성·공정·공구 수명·PM 이력의 영향 분석 | CP 기준·WS 교체조건·PM 주기 변경을 승인 |
| RMA·ABN 발생 | 고객 조건과 과거 LLD·CIP·유사 FMEA 검색 | RFQ 해석·검증계획·FMEA 위험을 재평가 |
| PCN 후 이상 증가 | 변경 전후 관계와 영향 LOT 추적 | 재검증·고객 통지·WS 개정·출하 판단 확정 |
역방향 반영의 통제 규칙
- 현장 결과는 원본 증거로 보존하고, 해석 결과와 분리한다.
- 추천된 위험·원인·대책에는 추천 출처와 유사도보다 적용 조건을 먼저 보여준다.
- 엔지니어가 적용·수정·보류·거부를 선택하고 사유를 기록한다.
- 확정된 변경은 영향받는 RFQ·DFMEA·PFMEA·CP·WS의 개정 대상으로 만든다.
- 개정 후 DV·공정검증·MSA·SPC·PM 결과를 다시 연결해 닫힘을 확인한다.
DFMEA와 PFMEA를 구분해야 연동이 정확해진다
DFMEA와 PFMEA를 하나의 FMEA 표로 섞으면 설계 문제와 제조 문제의 책임·검증·대책이 흐려진다. 양쪽은 BOM과 PFD를 경계로 연결하되, 분석의 질문은 분리해야 한다.
| 구분 | DFMEA | PFMEA | 연결 키 |
|---|---|---|---|
| 분석 대상 | 제품 기능·인터페이스·부품 설계 | 공정 기능·작업·설비·검사 | BOM 부품번호·PFD 공정번호 |
| 고장 원인 | 구조·재료·공차·환경·인터페이스 | 사람·설비·자재·방법·측정의 4M | 제품특성·공정특성 관계 |
| 주요 대책 | 설계 변경·공차 조정·재료 선정·DV | 포카요케·조건 잠금·검사·반응·PM | 특별특성·관리특성 |
| 현장 문서 | 도면·FS·시험계획·BOM | PFD·CP·WS·검사기준·PM | 문서 ID·개정·적용범위 |
| 최종 질문 | 제품이 의도한 기능을 설계상 수행하는가? | 그 기능을 매번 같은 품질로 생산하는가? | RFQ 충족 증거가 닫혔는가? |
BOM과 PFD는 문서 중간에 놓인 단순 참조표가 아니다. DFMEA의 설계 판단을 PFMEA의 공정 판단으로 넘기고, PFMEA의 관리결과를 CP·WS로 내리는 구조적 연결 기준이다.
Master·Family·Part를 쌍방향 지식으로 운영하기
모든 프로젝트를 빈 화면에서 시작하면 누락이 늘고, 반대로 과거 FMEA를 그대로 복사하면 적용조건이 다른 위험을 정답처럼 가져오게 된다. Master·Family·Part 계층은 재사용과 엔지니어 확정의 경계를 분명히 하는 장치다.
| 계층 | 쌍방향으로 내려보내는 것 | 현장에서 다시 올려야 하는 것 | 확정 경계 |
|---|---|---|---|
| Master | 공통 기능·대표 고장사슬·표준 관리 후보 | 새로운 반례·폐기 조건·업종 지식 | 적용 가능성과 최신성 |
| Family | 제품군 구조·사용환경·공통 특성 | 제품군별 변동·옵션·고객 조건 | Family 차이와 공통 범위 |
| Part | 프로젝트 문서·RFQ·부품·공정 기준 | 최종 S/O/D·실행결과·승인 이력 | 고객 제출본과 현장 기준 |
상위 지식을 업데이트해도 Part FMEA를 자동으로 덮어쓰지 않는다. 영향 후보를 알리고, 엔지니어가 적용·수정·거부를 확정한 뒤 변경 이력을 남긴다.
PCN을 문서 개정이 아니라 양방향 영향관리로 사용하기
공정변경(PCN)은 설비·공구·작업순서가 바뀌었다는 통지에 그치지 않는다. 변경된 조건이 RFQ 충족능력과 FMEA 위험을 바꾸는지, WS가 작업자에게 전달하는 행동을 바꿔야 하는지를 판단해야 한다.
| PCN 변경 | 하류 영향 | 역방향 확인 | 승인 증거 |
|---|---|---|---|
| 토크 공구 교체 | PFMEA 체결원인·CP 측정·WS 설정값 | 토크 분포와 MSA 비교 | 공정검증·SPC·고객 승인 |
| 패드 공급처 변경 | DFMEA 재료원인·DV·입고검사 | 제동력·마찰·내구 결과 | 재료승인·시험성적서 |
| 자동검사 알고리즘 변경 | 검출관리·WS 판정·출하차단 | 오검출·미검출·MSA 확인 | 검사 유효성·릴리스 기록 |
| 작업순서 변경 | PFD·PFMEA·CP·WS 개정 | 불량모드와 조정시간 추세 | 라인 검증·교육 이력 |
PCN 영향범위는 상류·하류·횡단 세 방향으로 확인한다. 상류는 RFQ·FS·DFMEA·DV, 하류는 BOM·PFD·PFMEA·CP·WS·PM, 횡단은 Family·Part·LLD·RMA·ABN·CIP다.
사용자가 전문가 수준의 판단을 확인하는 Smart FMEA 화면
사용자에게 필요한 것은 복잡한 데이터베이스 화면이 아니라 현재 선택한 요구사항이 어디에서 왔고, 어떤 위험을 거쳐, 어떤 작업으로 실행되며, 어떤 증거로 닫혔는지를 한 화면에서 읽는 것이다.
| 화면 영역 | 사용자가 확인하는 질문 | 전문가가 판단하는 내용 |
|---|---|---|
| 요구사항 트리 | 이 항목은 어떤 RFQ·FS·도면에서 왔는가? | 원문·조건·개정·고객 승인 범위 |
| FMEA 관계 패널 | 어떤 기능·고장·원인·대책으로 해석되었는가? | DFMEA/PFMEA 구분과 영향 논리 |
| 실행 문서 패널 | 작업자에게 어떤 행동과 반응으로 전달되었는가? | WS·CP·PM의 일관성과 실행 가능성 |
| 증거 패널 | 실제로 기준을 만족했다는 자료가 있는가? | 검사·SPC·MSA·DV·불량·RMA 결과 |
| 변경 비교 | 개정 전후 무엇이 달라졌는가? | 영향범위·재검증·고객 통지·승인 필요성 |
연결 상태의 의미
| 상태 | 의미 | 사용자 조치 |
|---|---|---|
| 연결됨 | 출처·대상·버전·범위·근거가 확인됨 | 실행 결과와 최신성을 확인한다. |
| 추천됨 | 유사 요구·산업 지식·과거 사례가 후보로 제시됨 | 적용·수정·거부를 결정한다. |
| 미연결 | 다음 단계의 관계나 증거가 없음 | 담당자·기한·보완 항목을 지정한다. |
| 충돌 | 규격·단위·버전·조건이 서로 다름 | 승인 근거로 조정하고 이력을 남긴다. |
| 폐기 | 개정·제품변경으로 유효하지 않음 | 하위 추천과 사용중지 관계를 정리한다. |
시스템이 추천하는 것은 후보이지 정답이 아니다. 사람이 확정해야 하는 항목은 엔지니어의 창의적 문제해결 영역으로 남겨두고, 확정된 결과만 다음 추천 지식으로 편입한다.
자전거 제동 FMEA로 보는 쌍방향 연동 실습
교육 사례의 기준은 “건식 조건에서 안정된 제동력을 확보한다”는 고객 RFQ다. 이 문장을 고장형태부터 분석하지 않고, 요구사항·기능·설계·공정·작업·증거의 순서로 전개한다.
| 단계 | 전개 내용 | 다음 단계로 넘기는 연결 |
|---|---|---|
| 1. RFQ | RFQ-BRK-017: 건식·지정하중·지정속도에서 제동력 50N 이상 | 조건·목표·검증 ID |
| 2. DFMEA | 레버 입력 전달, 패드 접촉, 캘리퍼 정렬, 구조·재료·공차 분석 | 제품특성·특별특성·DV/SC&D |
| 3. BOM/PFD | 패드·캘리퍼·케이블과 입고·조립·방향확인·조정·시험 연결 | 부품번호·공정번호·적용범위 |
| 4. PFMEA/CP | 방향 반전·토크 부족·유격 조정 누락·시험기 변동 분석 | 관리특성·검사·반응계획·PM |
| 5. WS | 방향 확인, 토크 체결, 유격 게이지, 기능시험을 작업 행동으로 표준화 | WS 개정·교육·작업결과 ID |
| 6. 역방향 | 조정 증가·SPC 추세·자동검사 NG·RMA를 영향 후보로 수집 | FMEA 재평가·RFQ 검증상태·LLD |
예를 들어 조정 횟수가 증가했다고 해서 바로 설계 공차를 바꾸지 않는다. 현장 데이터의 조건, 부품 LOT, 공구 상태, 작업순서, 측정시스템을 분리하고, 그 결과를 DFMEA 원인인지 PFMEA 원인인지 구분한 뒤 엔지니어가 대책을 확정한다.
RFQ·FMEA·WS 쌍방향 연동 체크리스트
- RFQ에 고유 ID·개정·조건·목표·검증방법이 있는가?
- RFQ 요구가 기능·제품특성·DFMEA로 변환되었는가?
- DFMEA와 PFMEA의 분석 질문과 책임이 분리되어 있는가?
- BOM과 PFD가 부품·공정·특성의 연결 기준으로 사용되는가?
- PFMEA·CP의 관리방법이 WS의 작업·판정·반응으로 변환되었는가?
- WS 실행 결과가 검사·SPC·PM·불량·RMA 증거로 저장되는가?
- 현장 결과가 FMEA와 RFQ 검증상태의 재검토 후보로 올라오는가?
- 추천·연결·충돌·미연결·폐기 상태가 구분되는가?
- 엔지니어가 적용·수정·보류·거부를 확정하고 사유를 남기는가?
- PCN 발생 시 상류·하류·횡단 영향과 재검증을 모두 확인하는가?
- 쌍방향 연동 — RFQ에서 WS로 요구를 내려보내고 현장 증거를 FMEA·RFQ로 회수하는 추적 구조
- WS — 작업표준. CP와 FMEA의 관리방법을 작업 행동·판정·이상 반응으로 변환한 문서
- 데이터 계보 — 요구사항과 판단이 출처에서 현장 결과까지 이어지는 관계 기록
- PCN — 공정변경의 영향범위와 승인·재검증·문서 개정을 관리하는 활동
- 엔지니어 확정 — 시스템 추천을 적용조건·근거·창의적 문제해결로 검토해 공식 판단으로 승인하는 행위
사례 사용 안내
자전거 특성과 수치는 Smart FMEA 공개용 교육 사례다. 실제 프로젝트에서는 고객 RFQ·FS·도면·법규·시험규격과 승인된 변경관리 기준을 사용한다.
다음 장에서 계속됩니다
S/O/D를 감이 아니라 고장영향·예방관리·검출관리의 근거로 정하고, 시스템 추천과 엔지니어 확정을 분리하는 방법을 다룬다.
