SAP 운영 인수인계에 남겨야 할 7가지 기록

SAP 운영 인수인계 문서에는 다음 담당자가 같은 상황을 찾아보고, 이어서 판단할 수 있는 정보가 필요합니다. “배치 확인 부탁드립니다”만 남기면 어느 실행을 봐야 하는지부터 다시 물어야 합니다. 업무의 영향, 확인한 근거, 다음 행동까지 연결하면 담당자가 바뀌어도 이어갈 출발점이 생깁니다.

이 글은 SAP GUI 기반 ABAP 환경을 예로 든 일반적인 기록 가이드입니다. 아래 일곱 항목은 문서를 구성하기 위한 제안이며, 화면과 권한은 제품·버전·회사 설정에 따라 다릅니다. 설명에 쓰는 일별 집계 작업 A, 시각, 건수는 모두 가상 예시입니다. 실제 회사의 장애나 운영 경험을 옮긴 내용이 아닙니다.

일곱 기록을 이해·확인·인계의 세 단계로 묶어두면 빠진 정보를 찾기 쉽습니다. 먼저 업무와 확인 위치를 이해하고, 조회 조건·로그·완료 기준으로 상태를 확인한 뒤, 조치 이력과 다음 행동을 전달하는 흐름입니다.

1. 어떤 업무가 영향을 받는지

프로그램 이름과 함께 업무 목적, 결과를 사용하는 부서, 처리 마감 시각을 적습니다. 실행 주기뿐 아니라 결과가 늦어질 때 어떤 후속 업무가 기다리게 되는지도 남깁니다. 오류 메시지가 같아도 마감까지 남은 시간과 업무 영향에 따라 확인 순서는 달라질 수 있습니다.

가상 예시의 작업 A는 매일 오전 6시에 전날 처리 내역을 집계하고, 오전 8시 30분 검토 업무에 결과를 제공합니다. 문서에는 “일별 집계 작업 A는 전날 처리 내역을 모으는 작업이며, 결과 미확인 시 08:30 검토 시작 여부를 업무 담당자가 판단해야 한다”처럼 적습니다. 프로그램명만 보고 업무 영향을 추측하게 하지 않는 것이 목적입니다.

2. 어디서 확인하는지

대상 시스템과 클라이언트, 조회 화면, 필요한 권한의 신청 경로를 남깁니다. 개발·검증·운영 중 어느 환경에서 관찰했는지도 표시합니다. 문서에 화면 이름만 있으면 접근이 안 되는 사람은 조회 오류와 권한 부족을 구분하기 어렵습니다.

좋은 문장 예시는 “운영환경의 지정 클라이언트에서 배치 조회 화면으로 확인한다. 조회 권한이 없으면 팀의 권한 신청 절차를 따르며, 업무 결과는 별도 검토 화면에서 대조한다”입니다. 실제 내부 문서에서는 ‘지정’이나 ‘별도’ 자리에 정확한 위치를 넣습니다. 비밀번호를 문서에 적는 대신 승인된 접근 절차를 연결합니다.

3. 어떤 조건으로 조회했는지

배치 작업은 잡 이름, 조회 기간, 실행 시각과 상태를 남깁니다. SM37에서 잡을 모니터링할 수 있고, 잡 상세에서는 시작 시각과 처리 시간을 확인할 수 있습니다. 같은 이름으로 반복 실행되는 작업이라면 어느 회차를 확인했는지 구분하는 정보가 필요합니다.

예를 들어 “작업 A 확인”보다 “9월 20일 06:00 시작 회차를 조회했고, 07:30에 Finished 상태를 확인했다”가 다음 담당자의 재조회에 도움이 됩니다. 문서의 시각에는 해당 화면의 기준을 함께 적습니다. 날짜 범위와 상태 필터도 남겨야, 다른 조건으로 조회한 결과를 같은 실행의 변화로 착각하지 않습니다.

4. 어떤 로그를 읽었는지

잡 로그의 메시지와 확인 시각을 기록합니다. 애플리케이션 로그까지 조회했다면 오브젝트·서브오브젝트와 기간을 남깁니다. SLG1에서는 이런 조건으로 애플리케이션 로그를 좁힐 수 있습니다. 두 종류의 로그를 모두 확인했다고 쓰려면 각각 실제로 읽은 범위가 있어야 합니다.

캡처에는 당시 화면이 담기지만 같은 내용을 다시 찾을 조건이 모두 보이지 않을 수 있습니다. “06:00 회차의 잡 로그를 확인했고, 추가 조사 대상 메시지와 발생 시각을 기록했다. 애플리케이션 로그는 아직 미확인”처럼 확인 범위를 적어보세요. 메시지의 핵심 내용과 조회 조건을 텍스트로 남기고, 캡처는 이를 보완하는 자료로 붙이면 됩니다.

5. 무엇을 완료로 판단하는지

잡 상태와 업무 결과의 확인 항목을 각각 적습니다. Finished는 모든 잡 단계가 성공적으로 끝났다는 의미입니다. 인수인계 문서에는 여기에 더해 팀이 합의한 결과 건수, 대상 기간, 후속 작업의 확인 여부 등 업무상 완료 기준을 남깁니다.

가상 예시에서 잡은 Finished지만 조회한 결과가 118건이고, 업무 담당자가 예상한 대상이 120건이라고 가정해보겠습니다. 이때 바로 실패로 단정하지 않고 예상 대상의 조건과 결과의 집계 범위를 대조해야 합니다. “잡 종료 확인 / 건수 차이 2건의 사유 미확인 / 업무 완료 판단 보류”라고 적으면 확인한 기술 상태와 남은 업무 판단이 드러납니다.

6. 어디까지 조치했는지

발견 시각, 관찰한 사실, 수행한 조치, 조치 후 결과를 시간순으로 기록합니다. 특히 확인 사실과 원인 추정을 나눠 쓰는 것이 중요합니다. “118건이 조회됨”은 가상 사례에서 확인한 사실이고, “일부 대상이 선택 조건에서 제외됐을 가능성”은 추가 확인이 필요한 추정입니다.

조치 문장도 “확인 완료”보다 “07:35에 결과 조회 기간을 다시 확인했으며 같은 조건에서 118건이 조회됐다. 재실행은 수행하지 않았다”처럼 행동과 결과를 붙입니다. 재실행을 검토한다면 승인 담당자, 이미 처리된 데이터의 유무, 중복 처리 가능성을 먼저 확인할 항목으로 남깁니다. 추정만으로 다음 담당자에게 실행을 지시하지 않습니다.

7. 다음 행동과 담당자는 누구인지

남은 일마다 담당 역할, 다음 확인 시점, 완료 조건을 붙입니다. “계속 모니터링”만 쓰면 누구도 첫 행동을 고르기 어렵습니다. 가상 예시에서는 “업무 담당자가 08:10까지 예상 대상과 결과의 차이 2건을 대조하고, 운영 담당자는 확인 결과를 인계 문서에 갱신한다”처럼 역할을 나눌 수 있습니다.

기한 안에 해소되지 않을 때의 연락 대상과 판단할 내용도 적습니다. 담당자 이름만 남기기보다 대체 가능한 역할과 팀에서 관리하는 연락 경로를 함께 둡니다. 다음 사람이 업무를 받아들였는지 확인하고, 새로 확인한 사실은 원래 기록을 지우기보다 확인 시각과 함께 덧붙이는 편이 경과를 따라가기 좋습니다.

한 건을 정리하는 미니 템플릿

아래 틀에 같은 사건의 정보만 모아보세요. 여러 작업을 한 문단에 섞으면 조회 조건과 조치 이력이 서로 연결되지 않을 수 있습니다. 빈칸은 추측으로 채우기보다 ‘미확인’과 확인 담당자를 적습니다.

• 업무 영향: 업무 목적 / 결과 사용자 / 마감 / 지연 시 판단할 내용
• 확인 위치: 환경 / 클라이언트 / 조회 화면 / 접근 절차
• 조회 조건: 잡 이름 / 대상 날짜 / 실행 회차 / 적용한 필터
• 확인 근거: 로그 종류 / 메시지·발생 시각 / 확인한 범위와 미확인 범위
• 완료 기준: 잡 상태 / 결과 대조 항목 / 업무 담당자의 확인 여부
• 조치 이력: 확인 사실 / 원인 추정 / 수행한 행동 / 이후 결과
• 다음 행동: 담당 역할 / 확인 기한 / 완료 조건 / 미해결 시 연락 경로

인계 직전에는 다음 담당자가 이 문서만 보고 같은 실행을 찾을 수 있는지, 아직 모르는 부분과 다음 행동이 분명한지 읽어보세요. 이후 확인 결과를 반영할 문서 위치와 마지막 갱신 시각도 남깁니다. 공개 블로그나 외부 공유본에는 실제 시스템명, 계정, 거래처, 전표 등 내부 정보를 포함하지 않습니다.