표준 운영 절차 예시: 단계별 SOP 3가지

표준 운영 절차 예시는 제목만 나열하는 대신 실제 단계, 시스템, 예외 상황을 보여줄 때 가장 유용합니다. 아래에 작성 예시 세 가지를 소개한 뒤, 유지 관리할 수 있는 절차서의 구성과 실제 업무가 이루어지는 곳에서 문서화하는 방법, 절차서가 여전히 실제 업무를 반영하는지 확인하는 방법을 살펴봅니다.

표준 운영 절차란 무엇인가요?

SOP는 반복 업무를 수행하는 방법을 설명합니다. 누가 어떤 순서로 어느 시스템에서 업무를 처리하는지, 일반적인 경로를 따를 수 없을 때는 어떻게 해야 하는지를 담습니다. 팀이 업무를 수행하고 새 직원을 교육할 때 참고할 수 있는 공통 기준이며, 실제 업무와 대조해 마지막으로 확인한 시점에 따라 품질이 달라집니다.

표준 운영 절차 예시 세 가지

각 예시는 담당 역할, 시스템, 예상 결과, 예외 처리 경로를 담은 단계별 표로 구성됩니다. 이런 정보를 함께 제시하면 절차를 따라가기 쉽고, 시스템에 기록된 실제 업무와 비교하기도 수월합니다.

표준 운영 절차 예시 1: 공유 서비스의 송장 예외 처리

이 절차는 송장과 발주서, 입고 내역 간 3자 대조가 실패하면 시작됩니다. 예외 처리 열에는 단계가 계획대로 진행되지 않을 때 취할 조치가 설명되어 있습니다.

마지막 행은 반복되는 문제를 검토 대상으로 올리는 방법을 안내합니다. 모든 예외에 같은 해결책이 필요하다고 전제하지 않습니다.

표준 운영 절차 예시 2: 입고 및 적치

표준 운영 절차 예시 3: IT 서비스 데스크의 인시던트 분류

SOP에는 어떤 내용을 담아야 할까요?

다음 표준 운영 절차를 작성할 때 아래 구성을 출발점으로 삼으세요.

• 목적과 범위: 절차가 다루는 내용과 다루지 않는 내용을 명시합니다. 범위를 분명히 하면 하나의 SOP가 한 가지 업무에 집중할 수 있습니다.
• 시작 조건: 절차를 시작하는 이벤트를 지정해 독자가 언제 적용되는지 알 수 있도록 합니다.
• 역할: 개인이 아니라 역할별 책임을 명시합니다. 담당자는 바뀔 수 있지만 역할은 비교적 안정적으로 유지됩니다.
• 번호가 매겨진 단계와 시스템: 각 단계의 내용과 수행 역할, 사용하는 시스템을 설명합니다.
• 예외 처리 경로: 일반적인 절차를 따를 수 없을 때의 조치를 설명합니다. 이상적인 경우뿐 아니라 자주 발생하는 변형도 포함합니다.
• 통제와 증빙: 무엇을 어디에 기록하고 얼마 동안 보관할지 명시합니다.
• 책임자와 개정 이력: 책임자를 지정하고 변경할 때마다 날짜와 변경 내용을 기록합니다.
• 검토 기준: 시스템, 규정, 팀의 변경이나 측정된 성과 변화 등 검토를 시작해야 하는 조건을 지정합니다.

개정 이력에는 언제 무엇이 바뀌었는지 기록됩니다. 검토 기준을 정해 두면 절차가 오래되어 쓸 수 없게 되기 전에 다시 살펴볼 수 있습니다.

SOP를 바로 사용할 수 있는지 어떻게 확인할까요?

절차를 게시하거나 개정하기 전에 다음 항목을 확인하세요.

• SOP의 범위에 다루지 않는 내용도 명시되어 있나요?
• 시작 조건이 초반에 분명하게 제시되어 있나요?
• 각 단계에 담당 역할, 시스템, 예상 결과가 명시되어 있나요?
• 애플리케이션에서 수행하는 단계에는 독자가 보게 될 화면이 나와 있나요?
• 일반적인 경로를 따를 수 없을 때의 조치가 설명되어 있나요?
• 책임자와 개정 이력이 지정되어 있나요?
• 특정 이벤트가 검토를 시작하도록 정해져 있나요?
• 절차를 이벤트 데이터와 비교할 수 있나요? 차이가 있다면 프로세스 책임자와 확인했나요?

마지막 질문에 답할 수 없다면 업무가 기록되는 시스템부터 확인하세요. 그러면 절차가 실제 업무를 반영하는지 점검할 수 있습니다. SOP 관리를 단순한 문서 보관이 아니라 정기적인 검토 과정으로 바꿀 수 있습니다.

SOP 관리 방법

SOP를 작성하는 일은 절반에 불과합니다. 절차를 어디에 보관할지, 어떤 버전이 최신인지, 누가 검토할지 관리하는 일이 더 어렵습니다. 전용 표준 운영 절차 관리 소프트웨어를 사용하든 문서 폴더를 사용하든, 팀별로 복사본을 만들어 두면 그중 일부는 오래된 버전이 됩니다. ProcessMind에서는 절차를 설명 대상 프로세스와 함께 관리하므로 문서와 관리 기준을 한곳에서 확인할 수 있습니다.

• 절차를 설명하는 활동에 추가합니다. 모든 프로세스에는 환경 수준에서 한 번 구성하는 섹션으로 이루어진 문서 트리가 있습니다. 따라서 각 절차는 동일한 설명, 범위, 역할, 목표, 관리 항목을 바탕으로 작성할 수 있습니다. 조직에 필요한 사용자 지정 섹션을 추가하고, 작업 지침은 누군가 찾아야 하는 폴더에 두지 말고 해당 단계에 연결하세요.
• 프로세스와 함께 검토합니다. 프로세스는 초안, 검토 중, 승인, 게시, 폐기, 보관 상태로 관리됩니다. 검토자는 ‘내 검토 필요’ 필터에서 검토할 항목을 찾을 수 있습니다. 승인과 동시에 게시 버전을 만들 수 있어 한곳에서 승인한 문서를 다른 곳에서 수정하는 일을 방지합니다.
• 업무가 진행되는 곳에서 의견을 남깁니다. 단계에서 댓글 추가를 선택하면 해당 활동에 관한 논의가 시작됩니다. 필드, 통제 항목, 예외에 관한 질문을 받은편지함에 묻히게 하지 않고 관련 지침 옆에 남길 수 있습니다.
• 버전을 보관합니다. 버전 이력에는 변경 내용과 시점, 변경한 사람이 기록되며, 게시 과정에서 독자에게 공개할 버전을 지정합니다.
• 모델에 지정된 역할을 가져옵니다. 문서의 RACI 매트릭스는 모델에서 각 활동에 지정한 역할을 바탕으로 작성됩니다. 따라서 문서의 책임과 다이어그램의 책임이 일치합니다.
• 화면에서 진행하는 단계는 해당 화면에서 캡처합니다. ProcessMind에서 스크린샷이나 화면 녹화를 하고, 필요한 컨트롤만 남도록 자릅니다. 저장된 이미지에서 개인정보를 가린 뒤 Markdown으로 지침을 추가하세요. 편집기에서 민감할 가능성이 있는 필드를 자동으로 감지할 수도 있습니다. 가림 상자를 수정할 수 있으므로 저장 전에 감지 결과를 바로잡을 수 있습니다. 캡처는 활동에 연결된 아티팩트로 저장됩니다.
• 파일이 필요한 독자를 위해 내보냅니다. 검토 주기와 품질 시스템에는 Word, 버전 관리에는 Markdown, 배포와 보관에는 PDF 및 인쇄 형식을 사용할 수 있습니다. 내보내기 설정에서 문서화되지 않은 모델 요소 목록, 프로세스 차트, 활동별 RACI를 포함할지 지정합니다. 문서화되지 않은 요소를 목록으로 확인하면 절차의 누락 부분을 빠르게 찾을 수 있습니다.

문서는 절반에 불과합니다. 나머지 절반은 검증이며, 같은 곳에서 진행해야 합니다. 문서화된 단계를 시스템에 기록된 활동과 비교한 뒤 교육, 문서, 프로세스 중 무엇을 변경할지 결정하세요. 승인된 변경 사항은 자체 버전 상태와 함께 문서에 반영됩니다.

두 가지 한계도 알아두어야 합니다. ProcessMind는 기록을 관리하고 검토에 필요한 근거를 제공하지만, 규정 준수를 인증하지는 않습니다. 또한 품질 관리 시스템에서 요구하는 승인 절차나 법무팀이 관리하는 정책 자료실을 대체하지 않습니다. Scribe 같은 별도 화면 캡처 도구로도 작업 수행 방법을 기록할 수 있으며, 한 팀이 관리하는 절차가 몇 개뿐이라면 위키로 충분할 수 있습니다. 하지만 위키나 별도의 문서 저장소만으로는 절차가 여전히 실제 업무와 일치하는지 확인할 수 없습니다.

이벤트 데이터로 SOP를 작성하는 방법은 무엇인가요?

이벤트 데이터는 ERP, ITSM, WMS처럼 업무를 기록하는 시스템에서 어떤 단계를 거쳤는지 보여 줍니다. 프로세스 지식과 함께 활용해 절차를 작성하고 검토하세요. process mining을 활용하면 다음과 같은 작업을 할 수 있습니다.

1. 이벤트 로그 불러오기

   프로세스를 기록하는 시스템에서 케이스 ID, 활동, 타임스탬프를 확인합니다. 비교 가능한 분석을 위해 케이스 기준 하나와 기간 하나를 정해 사용하세요.

2. 문서화된 프로세스에 매핑하기

   기록된 순서를 SOP의 단계와 나란히 놓고 비교합니다. 문서화된 단계 중에는 모든 케이스에서 나타나는 단계도 있고, 드물게 나타나거나 전혀 나타나지 않는 단계도 있습니다. 각각의 차이를 확인해야 합니다.

3. 차이 분석하기

   각 경로가 얼마나 자주 실행되는지, 업무가 어디에서 대기하는지, 어떤 단계가 반복되는지 측정합니다. 데이터에 나타난 차이는 조사의 출발점이지, 업무가 잘못되었다는 증거가 아닙니다.

4. 중요한 차이를 SOP에 반영하기

   위의 세 가지 예시처럼 반복되는 예외를 담당 역할, 시스템, 예상 결과를 포함한 행으로 정리합니다. 데이터만으로 알 수 없는 내용은 실제 업무를 수행하는 사람에게 확인하세요.

프로세스 데이터로 절차를 점검할 수 있지만, 데이터만으로 모든 의사결정의 이유를 알거나 프로세스가 어떻게 되어야 하는지 정할 수는 없습니다. 실제 업무를 수행하고 책임지는 사람과 분석 결과를 확인하세요. 이때 책임자와 검토 기준도 정해야 합니다. 책임자가 없는 절차는 실제 업무와 달라지기 쉽습니다.