변경관리(ECO/ECN), 판단까지 기록해야 하는 이유

ECO와 ECN, 변경관리 절차의 기본

설계변경 관리는 보통 세 단계로 흐릅니다. 변경 요청(ECR, Engineering Change Request)이 변경의 필요성을 제기하면, ECO(Engineering Change Order)가 그 변경을 공식 승인하고 어떻게 구현할지를 정의합니다. 마지막으로 ECN(Engineering Change Notice)이 승인된 변경을 관련 부서와 후공정에 통지합니다. ECO는 EC, ERN 등과 거의 같은 의미로 쓰이기도 합니다.

위키백과는 ECO를 '설계 주관 부서가 승인하여, 제품과 승인된 형상 문서에 대한 엔지니어링 변경의 구현을 기술하고 권한을 부여하는 문서'로 정의합니다. Arena의 가이드는 ECO를 '형상·적합·기능(form, fit, function)에 영향을 주는, 확립된 베이스라인에 대한 변경을 공식적으로 검토하는 프로세스'라고 설명합니다.

• ECR: 변경의 필요성 제기(초기 요청)
• ECO: 변경 승인 및 구현 방법 정의(공식 권한부여)
• ECN: 승인된 변경을 이해관계자와 후공정에 통지

표준 변경관리 절차는 무엇을 남기는가

잘 운영되는 변경관리는 대체로 다섯 단계를 따릅니다. 변경 요청 개시, 영향 검토와 평가(비용·품질·규정 영향), 변경관리위원회(CCB, Change Control Board) 승인, 설계와 문서의 구현, 그리고 검증과 종료입니다. 이 절차가 남기는 것은 명확합니다. 무엇이 어떤 버전에서 어떤 버전으로 바뀌었고, 누가 언제 승인했는지가 추적됩니다.

PLM의 감사추적(audit trail)도 같은 성격입니다. 누가, 언제, 무엇을 바꿨는지를 정확히 기록합니다. 추적성과 버전 관리 측면에서는 흠잡을 데가 없습니다. 문제는 그 다음입니다.

비어 있는 칸은 언제나 '왜'다

변경 트리거는 기록됩니다. 부품 단종, 불량률 급증, 비용 초과, 규정 위반 같은 사유는 ECO 양식에 적힙니다. 그러나 그 트리거 앞에서 검토했던 여러 대안 중 왜 하필 이 해결책을 택했는지, 무엇을 포기했고 어떤 리스크를 감수하기로 했는지 — 설계 의도와 판단의 근거는 변경 record 안에 체계적으로 담기지 않습니다.

그래서 같은 부품, 같은 공정에서 비슷한 변경 요청이 또 올라오면 조직은 처음부터 다시 검토합니다. 과거에 이미 같은 트레이드오프를 따져 결정한 사람이 있어도, 그 판단의 이유가 남아 있지 않으면 신뢰하고 재사용할 수가 없습니다. 변경 이력은 쌓이는데, 변경 판단은 매번 휘발됩니다.

• 남는 것: 변경 전후 형상, 버전, 승인자, 적용 시점
• 사라지는 것: 검토한 대안, 선택의 근거, 포기한 것, 감수한 리스크

변경의 판단을 다시 쓸 수 있는 형식으로

해법은 ECO 양식에 자유서술 칸을 하나 더 만드는 것이 아닙니다. 자유서술은 검색되지 않고, 검색되지 않는 기록은 다시 쓰이지 않습니다. 변경의 판단을 구조화된 형식으로 — 어떤 상황에서, 어떤 선택지를 두고, 무엇을 결정했으며, 그 근거가 무엇인지를 — 남겨야 같은 변경이 다시 올라왔을 때 과거 판단을 끌어와 재사용할 수 있습니다.