변경관리 안 한 작은 개선들
– 공사도 변경관리입니다. 실무에서 자주 놓치는 CSV 항목들
이런 건, 누가 봐도 변경 같지 않죠.
센서 하나 이설했다? 기계 고정대만 살짝 옮겼다?
알람 설정을 살짝 바꿨는데 그게 뭐?
근데요, 실사관 눈엔 다 보입니다.
그리고 이런 “작은 변경” 하나가 감사보고서에 그대로 적힙니다.
“No change control applied for system modification.”
센서 이설 / 위치 변경
→ 위치만 옮긴 거라 괜찮다고요? 하지만 설치 위치는 Validation에 포함된 항목입니다.
BMS/EMS에선 측정값의 기준 자체가 바뀌는 일이에요.
알람 임계값 수정
→ 생산팀 요청으로 임계값 3°C에서 5°C로?
OQ에서 3°C로 검증한 시스템을, 아무 기록 없이 바꾼 셈입니다.
스케줄러 / 백업 주기 변경
→ 백업 주기 10분 → 5분?
이거 CSV 재검토 대상입니다. 백업 부하, 저장 위치, 파일 충돌 등 전부 검토해야죠.
디스플레이 변경 / HMI 수정
→ 룸 넘버 하나 고친 것도 Logics 수정이면 설계 문서, 테스트 계획 다시 봐야 합니다.
많은 실무자가 이런 변경들을 “그냥 수리”, “그냥 조정”으로 여깁니다.
특히 현장 기술팀 주도 변경은, QA에 보고 없이 끝나는 경우가 허다하죠.
하지만 GAMP5, EU GMP Annex 11, PIC/S PE009 전부 명시합니다.
“모든 시스템 구성요소 변경은 문서화된 변경관리 절차에 따라야 한다.”
특히 GAMP5에서는 Impact Assessment를 생략할 수 없다고 말하고 있죠.
즉, 이 시스템은 ‘관리되지 않는 시스템’입니다.
CSV를 했다고 보기 어렵고, 재밸리데이션 또는 경고장 대상이 되는 거죠.
실무에서 흔히 말합니다.
“그냥 설치 위치만 바꾼 거예요.”
“태그네임만 수정했는데요.”
“임계값만 조금 조정했어요."
하지만 감사관은 이렇게 묻습니다:
“그 변경이 시스템 성능에 영향을 준다는 근거는 누가 평가했습니까?”
“테스트는 다시 수행했나요?”
“변경 전후의 설정값과 검토 내용은 문서화되어 있습니까?”
모든 변경은 기록하라 → 전기, 통신, HMI, 설정값 등 작은 변경도 CSV Impact 평가 대상입니다.
임계값, 센서 위치 변경은 반드시 QA 통보 → Validation 관련 설정이면 무조건 변경관리 필요.
변경 전후 설정값, 작업자, 승인자 기록 남겨라 → 작업일보? NO. 변경기록서(Change Record)나 검토보고서가 필요합니다.
정기적으로 CSV 관련 변경이 있었는지 리뷰하라 → 생산팀, 기술팀 작업을 QA에서 분기별 리뷰하는 절차 만들면 감점 방지.
변경관리 안 한 작은 개선 = 감점 직행 티켓
실무자는 “공사”라는 단어 대신 “변경”이라는 단어를 써야 합니다
센서 하나, 설정값 하나도 CSV에 영향 줄 수 있는 핵심 포인트
변경관리 누락은 ‘문서의 미흡’이 아니라, 시스템 신뢰성 전체를 무너뜨리는 치명타
다음 편 예고
[12편] 설계가 없으면, 검증도 없다