SAP Go-Live 안정화 — Hyper Care 3가지 원칙

8편에서 Cutover의 5일이 끝나는 지점이 D+1이라는 시작점이라고 짚었다. 그 시작점부터 약 30일이 Hyper Care다. 이 30일은 시스템이 안정화되는 기간이라기보다는 조직이 새 시스템에 적응하는 기간이다. 한 그룹사 PCE 전환 사례에서, 운영 개시 직후 한 달이 어떻게 세 가지 원칙으로 굴러갔는지 본다.

변경 최소화 — 지루함이 안전이다

오픈 직후의 안전은 새로운 일을 하지 않는 것에서 온다.

Hyper Care 기간의 가장 흔한 실수는 작은 개선 요청에 즉시 반응하는 것이다. 사용자가 "이 화면에 항목 하나만 추가하면 좋겠다"고 보내면, 운영팀은 별로 큰 일이 아니라고 생각해서 빠르게 반영한다. 그러나 PCE 같은 통합 시스템에서 작은 변경 한 건은 잠재적으로 미식별 의존성을 건드린다. 7편에서 본 Role-Catalog-Tile-매뉴얼의 4단 매핑이 그 예다 — Tile 하나를 바꾸면 그 Tile을 보는 Role이, 그 Role을 가진 사용자가, 그 사용자에게 배포된 매뉴얼이 조용히 어긋난다.

원칙은 단순하다 — 비상 변경(Critical/Hotfix)만 허용. 신규 기능 배포는 일단 멈추고, 사용자 요청은 목록에만 쌓아둔다. 작은 수정 한 건이 미식별 의존을 깨뜨려 다른 기능을 멈추게 할 수 있다는 가능성을 늘 의식해야 한다. 이 원칙이 지루하게 느껴진다면 그것이 정확히 원하는 상태다 — Hyper Care 기간의 지루함은 안정 운영이 작동하고 있다는 신호다. 시스템 자체에 변화가 적을수록, 사용자가 새 시스템에 적응할 시간을 얻는다.

모니터링 최대화 — 보는 것을 늘리기

변경을 줄이는 만큼 보는 것을 늘린다.

Hyper Care의 모니터링은 네 갈래로 작동한다. 첫째, SXI_MONITOR — 인터페이스 송수신 로그. 6편 일탈 사례에서 LIMS 인터페이스 차단의 검증에 쓰인 도구다. 둘째, MB51 — 재고 이동 이력. 품질재고 → 가용재고 같은 상태 전환이 정상 범위인지 일별로 본다. 셋째, 프로세스체인 실행 결과(BW) — 5편의 데이터소스 동기화가 일별로 정상 작동하는지. 넷째, Fiori Tile 사용 패턴 — 7편의 Role 설계대로 사용자가 실제로 시스템을 쓰고 있는지의 행동 데이터.

이 네 갈래는 수동 점검만으로는 다 보지 못한다. 모니터링은 자동 알림일별 리뷰의 조합이어야 한다. 임계값이 넘으면 자동 알림이 운영팀에 도달하고, 매일 정해진 시간에 전일 발생 이슈와 처리 결과를 리뷰하는 회의가 30일 동안 반복된다. 6편의 일탈이 수 시간 내에 식별된 것은 이 모니터링 체계가 작동했기 때문이다 — 일탈 자체를 막지는 못해도, 늦지 않게 잡힌다는 보장이 Hyper Care의 핵심 자산이다.

이슈 대응 — 5단계 표준 절차

일탈은 발생하지 않게 만드는 게 아니라 빠르게 잡히게 만드는 것이다.

PCE 같은 복잡한 시스템에서 0건 일탈은 비현실적이다. 진짜 KPI는 식별 후 종결까지의 시간이다. 본 프로젝트의 일탈 대응에는 5단계 표준 절차가 적용됐다 — 즉시 차단 → 영향 범위 식별 → 원복 → 로직/데이터 보완 → 재현 검증 → 운영 반영. 6편의 품질재고 일괄 합격 일탈이 이 절차로 수 시간 내에 종결된 사례다.

이 절차가 명문화되어 있어야 D+5에 사고가 나도 D+6에 종결 가능하다. 표준 대응 절차가 명문화돼 있지 않으면, 같은 종류의 이슈가 매번 처음 겪는 사고가 된다. 절차가 적용된 이후 사후 단계에는 CAPA(Corrective and Preventive Action)가 따라온다 — 단일 이슈를 종결한 뒤, 유사 위험을 가진 모든 CBO를 전수 검토하는 결정. 이 결정이 1·3·4편의 CBO 분류가 시작 단계에 끝나지 않았을 때의 보충 비용이다. Hyper Care 30일은 종결의 시간이 아니라 학습의 시간이기도 하다.

원칙구체 도구핵심 KPI
변경 최소화변경관리 동결, 비상 변경만 허용일별 변경 건수 (낮을수록 좋음)
모니터링 최대화SXI_MONITOR, MB51, 프로세스체인, Fiori 사용발생 → 인지 시간
이슈 대응5단계 절차, CAPA 트리거인지 → 종결 시간

한 줄로

Hyper Care의 본질은 시스템 안정이 아니라 조직 안정이다. 변경 최소화·모니터링 최대화·이슈 대응 — 이 셋은 시스템 운영의 룰이지만, 결과적으로는 사용자 신뢰를 쌓는 일이다. 30일을 지루할 정도로 조용하게 마치면, 사용자는 새 시스템도 결국 일을 할 수 있는 도구라고 인식하게 된다. 그 인식이 PCE 구축의 진짜 결과물이다. 다음 10편에서 시즌 1을 회고하고, 왜 BTP가 다음 단계인가로 다리를 놓는다.

댓글

이 블로그의 인기 게시물

S/4HANA Cloud CBO 개발 3단계 — 어디까지 위에서 끝내는가

S/4HANA Cloud PCE 전환 시작 단계, 가장 먼저 바뀌는 3가지

SAP QM 검사로트 일괄합격 일탈 — CSV가 놓친 한 가지