승인 대상과 종료 상태를 먼저 고정합니다
승인 흐름은 “요청이 들어오면 검토한다”로 시작하면 너무 넓어집니다. 예산 집행, 휴가, 콘텐츠 게시처럼 무엇을 승인하는지와 요청이 언제 종료되는지를 한 문장으로 적으세요. 예를 들어 “비용 요청이 접수된 시점부터 승인 결과가 요청자에게 안내되고 기록될 때까지”처럼 정하면, 중간 단계가 불필요하게 늘어나는 일을 막을 수 있습니다.
| 단계 | 좋지 않은 문구 | 확인 가능한 문구 |
|---|---|---|
| 시작 | 승인 요청 | 필수 항목을 포함한 요청 접수 |
| 검토 | 내용 확인 | 금액·근거 자료·담당 부서 확인 |
| 조건 | 승인 가능? | 결재 권한과 예산 범위 안인가? |
| 결과 | 처리 완료 | 승인 결과와 다음 조치 안내 발송 |
한 노드에는 행동 하나, 책임 주체 하나를 둡니다
요청자가 자료를 제출하고 검토자가 내용을 확인하고 승인권자가 결정을 내리는 과정을 하나의 노드에 넣으면, 지연이 발생했을 때 어디를 확인해야 하는지 알 수 없습니다. 행동이 바뀌거나 담당자가 바뀌는 지점에서 노드를 나누세요. 노드 문구에는 동사를 쓰고, 담당자는 메모 노드 또는 문구의 괄호 안에 적으면 읽는 사람이 책임 경계를 즉시 파악할 수 있습니다.
- 요청자가 제출해야 할 필수 정보를 적습니다.
- 형식과 근거 자료를 확인하는 사전 검토를 둡니다.
- 권한 또는 금액 기준을 판단하는 조건 노드를 만듭니다.
- 승인·반려 결과를 요청자에게 알리는 단계를 분리합니다.
- 기록·후속 실행처럼 승인 뒤에 남는 작업을 연결합니다.
조건 노드는 질문 하나와 증빙 하나로 씁니다
“자료가 충분하고 예산도 남아 있는가?”처럼 두 질문을 한 조건에 합치면, 어떤 이유로 보완되었는지 추적하기 어렵습니다. 자료 완전성, 예산 범위, 결재 권한을 각각의 조건으로 나누세요. 각 조건에는 확인할 수 있는 증빙을 함께 정합니다. 금액은 견적서, 권한은 결재 규정, 기간은 요청 접수 시각처럼 판단 근거가 정해져 있어야 같은 요청을 다른 사람이 검토해도 결과가 일관됩니다.
보완·반려·보류를 서로 다른 결과로 취급합니다
승인되지 않았다는 이유만으로 모든 요청을 반려로 끝내면 재제출 가능한 요청까지 사라집니다. 자료가 빠졌다면 보완 요청 후 같은 검토 단계로 돌아가게 하고, 외부 확인을 기다린다면 보류 상태와 다시 확인할 시점을 남기세요. 규정상 허용되지 않는 요청만 반려 결과로 닫는 방식이 가장 읽기 쉽습니다.
- 보완: 누락 항목과 재제출 위치를 요청자에게 알립니다.
- 보류: 기다리는 정보·담당자·다음 확인 날짜를 메모로 남깁니다.
- 반려: 적용한 기준과 이의 제기 또는 재요청 가능 여부를 안내합니다.
- 승인: 승인 자체와 실제 집행·게시·발주 같은 후속 행동을 구분합니다.
실제 요청 하나로 끝까지 따라가며 검토합니다
공유 전에는 최근에 처리한 요청 한 건을 가정해 시작 노드부터 따라가 보세요. 요청자가 어느 자료를 준비해야 하는지, 검토자가 기준을 어디에서 확인하는지, 보완이 발생하면 정확히 어느 단계로 돌아가는지 말로 설명할 수 있어야 합니다. 모든 길이 승인, 반려, 보류처럼 이름 붙은 결과에 도착하는지도 확인합니다.
- 누락 자료가 있는 요청은 보완 경로로 가는가?
- 금액 또는 권한 기준을 넘으면 상위 승인으로 이어지는가?
- 결과 통보가 승인권자의 내부 결정과 분리되어 있는가?
- 보류된 요청을 다시 확인할 책임자와 시점이 있는가?
- 각 경로가 끝나거나 다음 행동으로 명확히 이어지는가?
작성 후에는 플로우캔버스의 흐름 점검으로 연결되지 않은 노드가 없는지 확인하고, 실제 규정이 바뀌면 조건 문구와 검토일을 함께 고치세요. 도구는 구조를 확인하는 데 도움을 주지만, 승인 기준의 적법성과 조직 규정의 최신성은 담당자가 직접 검토해야 합니다.