데이터 마이그레이션 일정

왜 이행은 항상 마지막 달에 시작되나

새 화면이 있어야 매핑을 한다는 착각이다. 매핑은 AS-IS 코드와 예외에서 시작한다.

개발이 끝나야 이행한다는 순서는 편하다. 새 컬럼이 확정돼야 옮긴다는 말도 맞다.

다만 예외의 80%는 새 화면이 아니라 옛 코드와 수기 보정에 있다. 그 목록은 첫 달에 받을 수 있다.

운영자가 월말에 엑셀로 고치는 항목, 배치가 실패하면 수동으로 넣는 건, 코드 값이 문서와 다른 테이블. 이 세 목록이 이행 WBS의 첫 칸이다.

첫 칸을 비우고 개발만 달리면, 마지막 달에 목록이 쏟아진다. PM이 착수 주에 이 목록의 담당을 발주 쪽으로 안 찍으면, 수행사는 추정 매핑으로 리허설을 한다.

추정 매핑의 리허설은 리허설이 아니다.

갑을 접점이 이행인 이유

수행사는 TO-BE를 만들고, 발주는 AS-IS를 안다. 두 지식이 한 표에서 만나야 이행이다.

인터페이스와 회계, 고객 식별키가 대표 접점이다. 수행사 혼자 옛 고객번호를 새 키로 바꾸면, 중복과 휴면과 합병이 한꺼번에 터진다.

발주 현업이 식별 규칙을 한 장으로 안 주면 수행사는 추측한다. 추측이 오픈 주말에 드러난다.

역할 표에 이행 매핑 확인을 발주, 변환 프로그램과 검증 리포트를 수행, 리허설 데이터 제공을 운영으로 나눈다. 한 칸이라도 공란이면 그 칸이 오픈 주 이슈다.

Risk(위험) 대장에 이행을 중반 이후 한 줄로 적는 습관이 이 공란을 숨긴다. 착수 주에 올려야 하는 위험이다.

리허설을 몇 번 해야 하나

한 번이면 도구 확인이다. 두 번째부터 예외가 보인다. 오픈과 같은 시간대 리허설이 한 번은 있어야 한다.

리허설 한 번은 프로그램이 도는지 보는 수준이다. 두 번째에서 코드 값 예외가 나오고, 세 번째에서 수행 시간이 종료 창을 넘기는지 보인다.

횟수를 계약에 안 박으면 한 번으로 끝난다. 한 번의 성공은 오픈 성공이 아니다.

오픈과 같은 시작 시각, 같은 인력, 같은 체크리스트로 한 번을 더 한다. 그 한 번이 새벽에 안 되면, 오픈 새벽에 안 된다.

시간은 프로그램 문제가 아니라 배치 창과 연계 기관 점검 창의 문제인 경우가 많다.

검증을 건수로만 하면 놓치는 것

이관 건수가 맞아도 금액과 권한이 틀릴 수 있다. 건수, 금액, 샘플 시나리오를 같이 본다.

원장 100만 건이 100만 건으로 넘어오면 보고는 합격이다. 그중 정산 금액 합이 어긋나고, 휴면 고객의 권한이 살아 있으면 업무는 불합격이다.

검증 리포트는 세 층이다. 건수, 핵심 금액 합, 시나리오 샘플 20건.

샘플은 현업이 고른다. 수행사가 고른 샘플은 쉬운 건만 남는다.

샘플 20건의 선정 기준을 리허설 전에 받아 두지 않으면, 오픈 다음 날 현업이 들고 오는 21번째 건이 사고를 만든다.

이행 실패를 [[stabilization]]에 넘기지 마라

안정화는 새 결함을 닫는 기간이다. 이관이 안 끝난 상태를 안정화로 부르면 기간만 녹는다.

오픈을 강행하고 남은 이관을 안정화에 넣는 결정이 있다. 안정화 인력이 이관을 다시 하면, 신규 결함은 손도 못 댄다.

사용자는 새 화면과 옛 데이터가 섞인 상태를 본다. 그 상태는 안정화가 아니라 미이행이다.

미이행이면 오픈 범위를 줄이거나 일정을 옮긴다. 줄일 범위는 미리 정한 이관 목록의 뒤쪽이다.

목록이 없으면 현장에서 감정으로 줄인다. 감정으로 줄인 범위는 다음날 다시 범위가 된다.