실무적으로 자동차 업계의 ASPICE 기반 문제해결관리 절차(PRM/SUP.9)에서 "긴급 해결(Emergency Resolution)" 조건은 보통 다음 수준으로 정의합니다.
중요한 것은:
"급하다"가 아니라
"정상적인 문제해결 절차를 수행하면 사업적/기술적 손실이 발생하는 경우"
를 긴급 해결로 정의하는 것입니다.
1. 가장 일반적인 긴급 해결 조건
① 고객(OEM) 양산 일정 영향
예)
- 고객 릴리즈 D-3
- SOP 직전
- PPAP 제출 직전
- 고객 마일스톤 직전
문제가 발생
예:
고객 제출 바이너리 오류
정상 절차
문제 등록
영향분석
CCB
수정
전체 회귀시험
수행하면
고객 일정 Miss
발생
→ 긴급 해결 가능
② 양산 차량 영향
예)
양산 차량 ECU Reset
양산 차량 CAN 통신 불가
안전 기능 비활성화
이 경우는 거의 대부분 긴급 해결 대상
③ Safety 영향 가능성
예)
ASIL 기능 동작 오류
Fail Safe 미동작
DTC 누락
ISO 26262 관련 문제
→ 대부분 긴급 처리
④ 고객 시험 중 Blocker Issue
예)
고객 검증 시험
SYS.5 수행 불가
기능 동작 불가
고객 시험 전체 중단 가능
→ 긴급 해결
⑤ 생산(Manufacturing) 영향
예)
공장 생산 중단
Programming 실패
EOL 시험 실패
양산 조직에서는 매우 중요
⑥ 서비스/필드 문제
예)
고객 클레임 다수 발생
Warranty 증가
리콜 가능성
이 경우도 긴급 처리
실무적으로 추가하면 좋은 것
긴급 해결 남용 방지
예)
긴급 해결 적용 여부는
프로젝트 관리자 및 품질보증 담당자의 승인을 받아야 한다.
또는
긴급 해결 적용 사유는 문제관리 시스템에 기록되어야 한다.
""단순히 문제의 심각도가 높다고 긴급해결하는 것도 말이 안되는 거지?""
네. 오히려 실무적으로는:
"심각도(Severity)가 높다"와 "긴급성(Urgency)이 높다"는 다른 개념입니다.
이 둘을 구분하지 않으면 긴급해결 프로세스가 망가집니다.
1. 가장 흔한 오해
많은 사람들이:
중요한 문제 = 긴급 문제
라고 생각하는데,
실제로는:
Severity (심각도)
≠
Urgency (긴급성)
입니다.
2. 예를 들어보자
사례 1 : 심각도 높음 + 긴급성 낮음
예)
ASIL-D 안전기능에서
특정 진단 커버리지 계산 오류 발견
심각도:
매우 높음
하지만
양산 전 6개월
남았음.
고객 제출도 없음.
차량에도 안 들어감.
이 경우:
Major 또는 Critical 문제
일 수는 있지만,
Emergency
는 아닐 가능성이 큼.
정상 문제해결 절차로 가도 됨.
3. 반대로
사례 2 : 심각도 중간 + 긴급성 높음
예)
고객 제출 D-1
릴리즈 패키지 생성 오류
Release Note PDF 깨짐
Safety 영향 없음.
기능 영향 없음.
하지만
내일 고객 제출
해야 함.
이 경우:
심각도는 중간
일 수 있지만,
긴급성은 매우 높음
입니다.
실제로는 긴급해결 절차 태울 수도 있음.
ASPICE 관점에서도
SUP.9에서 Emergency Process를 쓰는 이유는
문제가 크기 때문
이 아니라
정상 절차를 수행할 시간이 없기 때문
입니다.
즉
Critical
과
Emergency
는 다른 축.
실제 절차서에 잘 쓰는 방식
좋은 문제해결관리 절차는
긴급해결 조건을:
❌
심각도가 높을 경우
라고 안 씁니다.
대신
⭕ 이렇게 씁니다.
- 고객 제출 일정 영향
- 양산 일정 영향
- 고객 시험 중단 위험
- Safety 영향으로 즉각 대응 필요
- 생산 중단 위험
즉
시간 제약
을 기준으로 정의.
'ASPICE 기본 이론' 카테고리의 다른 글
| 문제해결관리 프로세스에 CCB를?? (0) | 2026.05.29 |
|---|---|
| 문제해결 관리의 긴급 해결 프로세스 생략 가능 프로세스, 불가 프로세스 (0) | 2026.05.29 |
| 변경요청관리 프로세스의 흔한 패턴 (feat 형상관리) (0) | 2026.05.29 |
| SYS.4와 SWE.6의 차이 (0) | 2026.05.29 |
| 고객 요구사양서, 승인도 파헤치기1 (0) | 2026.05.20 |