프로세스 문서화는 부족한 지식을 조직의 지식으로 바꾸는 작업입니다. Trupeer를 사용하면 무료 프로세스 문서화 템플릿으로 시작해 브랜드 가이드라인에 맞게 커스터마이징하고, 팀이 실제로 사용하는 명확한 비디오 워크스루로 문서화된 프로세스를 전환하여 작업 방식 기록에 드는 시간을 몇 시간이나 절약할 수 있습니다.

프로세스 문서화 템플릿이란?

프로세스 문서화는 실제 업무가 어떻게 진행되는지에 대한 서면 기록입니다. 즉, 단계, 누가 수행하는지, 어떤 순서로 진행되는지, 어떤 입력값이 필요한지, 그리고 완성된 결과가 어떤 모습인지까지 포함합니다.

프로세스 문서화 템플릿은 이를 기록하기 위한 재사용 가능한 구조입니다. 헤더 필드, 단계 형식, 그리고 문서를 처음 접하는 사람도 바로 활용할 수 있게 해주는 주변 정보까지 포함합니다.

모든 템플릿은 대체로 같은 것을 제공합니다. 목적, 범위, 담당자가 포함된 번호 매긴 단계 목록, 그리고 어딘가에 플로우차트를 넣을 수 있는 공간입니다. 이 구조는 괜찮습니다. 다만 그 구조가 만들어내는 문서는 모든 것이 계획대로 진행되는 프로세스 버전을 설명하는 문서이며, 정작 도움이 필요한 사람에게는 그 버전이 아닙니다.

왜 ‘정상 경로’는 아무도 필요로 하지 않았을까

누군가에게 프로세스를 문서화해 달라고 하면, 그 사람은 어떻게 작동하는지 설명할 것입니다. 이것이 질문에 대한 자연스러운 답이긴 하지만, 내용으로는 틀렸습니다.

문서를 읽는 사람은 보통 일주일 안에 표준 케이스를 처리할 수 있습니다. 누군가가 그것을 두 번 보여주면, 금방 익혀서 문제없이 진행합니다. 하지만 그들이 할 수 없는 것은 구매 주문 번호가 누락된 상태에서의 순서 처리, 계약 가격과 일치하지 않는 고객 가격, 중단된 부품, 방금 신용 한도를 초과한 계정 같은 상황을 처리하는 일입니다.

이런 상황은 흔치 않지 않습니다. 대부분의 운영 프로세스에서 시간 기준으로는 이런 예외가 작업의 대부분을 차지합니다. 물량 기준으로는 소수일 수 있어도, 각 예외는 깔끔한 케이스보다 몇 배 더 오래 걸리기 때문입니다.

또한 이런 예외 콘텐츠는 쓰기가 가장 어렵습니다. 그 이유는 이해할 가치가 있습니다. 프로세스를 문서화하는 사람은 예외를 수백 번 처리해 왔고, 오래전부터 예외를 ‘결정’으로 느끼지 않게 되었습니다. 프로세스가 어떻게 작동하는지 묻는 질문을 받으면, 그들은 솔직하고 정확하게 정상 경로를 설명합니다. 왜냐하면 질문이 그렇게 답하도록 유도하기 때문입니다.

그래서 문서는 문서화가 필요 없었던 부분만 다루고, 이번 작업의 전부였던 이유인 예외 부분은 빠지게 됩니다.

Trupeer에서 이 템플릿을 커스터마이징하는 방법

1단계: 템플릿 섹션 열기

메인 내비게이션에서 템플릿 섹션으로 이동하세요.

2단계: 템플릿 선택 후 열기

작업하려는 템플릿을 클릭해 열어보세요.

3단계: 템플릿 보기 확장

필요한 경우 템플릿 보기를 확장해 전체 레이아웃과 세부 정보를 더 명확하게 확인하세요.

4단계: 템플릿 편집

편집을 클릭해 선택한 템플릿을 수정하기 시작하세요.

편집기에서 다음을 할 수 있습니다.

• 새 섹션 추가

• 서식 규칙 정의 또는 업데이트

• 로고를 추가하고 위치 및 관련 설정을 조정

5단계: 커스터마이징한 템플릿 저장

필요한 모든 변경을 마친 후 저장을 클릭해 업데이트된 템플릿을 본인 템플릿으로 저장하세요.

6단계: 미리보기 및 템플릿 미세 조정

커스터마이징한 템플릿이 어떻게 보이는지 확인하려면 미리보기를 여세요.

미리보기 화면에서 필요하다면 템플릿이 원하는 대로 정확히 표시되도록 직접 계속 조정할 수 있습니다.

프로세스 문서화 템플릿으로 할 수 있는 일:

• 문서화에 드는 시간을 절약: 어떤 비즈니스 프로세스든 적용할 수 있도록 설계된 구조로 빈 페이지를 건너뛰세요.

• 부족한 지식(트라이벌 지식) 포착: 사람들이 떠나도 지식이 남도록 실제로 업무가 어떻게 진행되는지 문서화하세요.

• 브랜드에 맞게 유지: Trupeer의 브랜드 키트를 사용해 로고, 글꼴, 색상을 적용하세요. 기능 부서 간 프로세스 문서에 완벽합니다.

• 프로세스 문서로 SOP 만들기: AI SOP creator를 사용해 각 단계를 상세 작업 지침으로 전환하세요.

• 개선점 파악: 프로세스를 문서화하는 것은 개선의 첫 단계입니다. 템플릿이 비효율을 눈에 보이게 해줍니다.

• 글로벌 팀과 공유: 한 번의 클릭으로 프로세스 문서화를 65개+ 언어로 번역하세요.

작성하기 전에 예외율을 계산하는 방법

무엇이든 쓰기 전에, 실제 업무 중 표준 경로를 그대로 따르는 비율이 어느 정도인지 확인하세요. 이 작업은 오후면 충분하며, 무엇을 어떻게 쓸지에 대한 방향이 바뀝니다.

프로세스의 최근 사례를 표본으로 가져오세요. 30개면 대략적인 판단이 가능하고, 데이터를 쉽게 구할 수 있다면 200개가 더 좋습니다. 선택된 표본이 현실보다 항상 더 깔끔하기 때문에, 연속 표본을 권장합니다.

각 사례마다 단 하나의 질문을 하세요. 이 일이 그대로 진행되었나요, 아니면 무언가를 결정해야 했거나 추적, 수정 또는 에스컬레이션이 필요했나요?

그다음, 그대로 진행되지 않은 사례를 그룹으로 나누고 개수를 세세요.

두 가지 숫자가 나옵니다. 첫째, 깔끔하게 진행된 비율입니다. 이는 정상 경로 문서가 커버할 수 있는 작업의 양을 알려줍니다. 둘째, 예외 유형의 순위 목록입니다. 이것이 바로 작성 순서입니다.

대부분의 팀은 둘 다에 놀랍니다. 모두가 간단하다고 설명하는 프로세스도 실제로는 전체 사례의 3분의 1 또는 절반에서 깔끔하게만 진행되는 것으로 드러나는 경우가 많고, 상위 3가지 예외 유형이 나머지 대부분을 차지하는 경우가 흔합니다. 이 세 가지는 표준 단계 14개 전체를 합친 것보다 더 많은 문서화 주의가 필요합니다.

모든 단계에 필요한 ‘그리고 만약 그렇지 않다면’

이 규율의 가장 가벼운 버전은 거의 비용이 들지 않으며, 이미 가지고 있는 문서에도 적용할 수 있습니다.

각 단계를 가져오세요. 각 단계는 어떤 조건이 충족되어야 한다는 것을 전제로 합니다. 예를 들어 필드가 채워져 있는지, 가격이 일치하는지, 재고가 존재하는지, 승인 절차가 갖춰져 있는지 같은 것들입니다. 각 단계 아래에 ‘그리고 만약 그렇지 않다면(and if not)’으로 시작하는 한 줄을 작성하세요.

예: 구매 주문 번호가 존재하고 고객 형식에 맞는지 확인합니다. 그리고 만약 그렇지 않다면: 템플릿을 사용해 이메일로 요청자에게 요청하고, 주문은 보류 대기열에 유지한 뒤 배정으로 진행하지 않습니다.

이 한 줄은 세 가지 일을 합니다. 첫째, 예외를 드러냅니다. 예외는 종종 누군가가 처음으로 적어보는 순간에야 보이기 때문입니다. 둘째, 어떤 일이 일어나야 하는지에 대한 결정을 강제합니다. 이 결정은 자주 합의되지 않은 것으로 드러납니다. 셋째, 독자가 무언가를 즉흥으로 만들어내거나 누군가를 중단시키지 않도록, 대신 무엇을 해야 하는지 알려줍니다.

‘그리고 만약 그렇지 않다면’의 답이 대략 두 줄을 넘어서 길어지면, 해당 내용은 고유한 결정 규칙을 가진 별도의 예외 섹션에 들어가야 하며, 단계는 그곳을 가리키는 역할만 하면 됩니다. 답이 정말로 ‘감독자에게 문의’라면 역할을 명시해 분명히 말하세요. 에스컬레이션이 숨겨져 있으면, 없애려던 중단이 발생하기 때문입니다.

무료 프로세스 문서화 템플릿: 그대로 복사할 구조

여기서 복사하세요.

헤더. 부서가 아니라 결과(outcome)로 표현한 프로세스 이름. 담당자(owner)는 역할로 작성. 마지막으로 이 문서로 프로세스를 실행해 확인한 날짜(Last verified date). 버전. 예상 빈도와 물량.

이 프로세스가 만들어내는 것. 완성된 결과를 독자가 ‘이게 맞다’고 판단할 수 있도록 설명합니다.

트리거와 경계. 무엇이 시작하고 무엇이 끝내는지, 그리고 이 문서에서 다루지 않는 내용이 바로 양쪽에 무엇이 있는지 설명합니다. 경계는 중복되거나 서로 모순되는 문서가 어디서 생기는지 보여주는 지점입니다.

누가 참여하는가. 이름이 아니라 역할로 작성하고, 각 역할이 무엇에 대해 책임지는지 명시합니다.

입력값과 시스템. 시작하기 전에 반드시 존재해야 하는 것과 필요한 시스템 및 접근 권한을 적습니다.

단계. 번호를 매긴 형태로, 한 줄에 한 가지 행동을 작성합니다. 예상 결과와 함께 각 단계 아래에 그리고 만약 그렇지 않다면(and if not) 한 줄을 추가합니다.

예외. 표본에서 뽑은 예외 유형을 순위로 나열합니다. 각 예외마다 조건, 결정 규칙, 누가 승인할 수 있는지, 그리고 다음에 무슨 일이 일어나는지를 포함하세요. 이 섹션은 보통 단계보다 더 길어지는데, 이는 맞는 방향입니다.

이 프로세스가 다루지 않는 것. 해당 케이스가 어디로 가는지에 대한 포인터와 함께 명시적으로 이름을 붙여 적습니다.

측정 항목. 보통 걸리는 시간, 물량, 그리고 깔끔하게 진행되는 비율을 적습니다. 마지막 수치는 추적할 가치가 있습니다. 프로세스가 바뀌면 이 값도 움직이기 때문입니다.

여기까지 복사하세요. 일반적인 템플릿에 추가해야 할 두 가지는 ‘그리고 만약 그렇지 않다면’ 줄과 예외 섹션입니다. 그 외의 모든 것은 어떤 괜찮은 구조에서든 찾을 수 있습니다.

프로세스 문서화 템플릿에 포함할 것

위의 헤더, 경계, 역할, 단계, 예외를 그대로 사용하세요. 문서를 줄이려는 사람에게서 지켜낼 만한 가치가 있는 항목은 세 가지입니다.

마지막으로 확인됨(Last verified), 마지막으로 업데이트됨이 아님. 문구를 편집하는 것은 프로세스가 여전히 같은 방식으로 실행된다는 것을 확인하는 것과 다릅니다. 실제로 누군가가 ‘일어나는 것을 본’ 날짜는, 누군가가 오타를 고쳤다는 의미의 날짜보다 훨씬 더 가치가 있습니다.

경계. 대부분의 중복 문서는 두 팀이 같은 프로세스의 겹치는 구간을 문서화하면서, 각 팀이 어디까지 멈추는지 합의하지 않아 생깁니다.

깔끔한 실행 비율. 문서가 실제 업무를 설명하는지, 아니면 이상화된 버전을 설명하는지 판단하게 해주는 유일한 지표입니다.

세 가지는 빼도 됩니다. 단어보다 문서를 더 빨리 구식으로 만드는 인터페이스 변경 스크린샷. 프로세스가 존재하는 이유에 대한 설명(이는 정책에 들어가야 합니다). 그리고 IT documentation에 있는 시스템 상세 정보로, 다시 설명하기보다는 참조해야 합니다.

문서가 주문의 31%를 커버했던 유통사

B2B 유통사인 Pellowe Trading은 두 명의 숙련된 코디네이터가 서로 한 달 안에 사직했을 때, 주문 처리(order processing)를 문서화했습니다.

문서는 어떤 정상적인 기준으로 봐도 철저했습니다. 14단계, 플로우차트, 스크린샷, 22페이지, 그리고 두 코디네이터가 모두 떠나기 전에 승인까지 받았습니다.

대체 인력이 두 명 투입되었습니다. 6주 안에 주문 적체(backlog)는 약 40건에서 약 310건으로 늘었고, 결산(finance close)은 9일 지연되었습니다.

조사에서는 연속된 200건의 주문을 추적해, 문서화된 14단계를 이탈 없이 그대로 따른 사례가 몇 개인지 확인했습니다.

63건이었습니다. 나머지 137건은 최소 한 가지 예외에 해당했습니다.

순위로 정리하면 예외는 다음과 같았습니다. 고객 구매 주문 번호가 누락되었거나 형식이 잘못된 경우가 41번. 주문의 가격이 계약 가격표와 일치하지 않는 경우가 29번. 대체품이 필요한 중단된 부품이 22번. 신용 한도 초과가 18번. 계정에 보관되어 있지 않은 배송 주소가 14번. 분할 배송 요청이 13번.

이 6가지 중 어느 것도 22페이지 어디에도 등장하지 않았습니다.

떠나게 된 두 코디네이터는 이 예외들을 수년 동안 주 1회가 아니라 매주 여러 번 처리해 왔습니다. 인수인계 과정에서 둘 다 그중 어떤 것도 제기하지 않았고, 아무것도 숨기지 않았습니다. 주문 프로세스가 어떻게 작동하는지 물었을 때, 그들은 그 질문에 정확하게 답했습니다.

적체는 11주와 임시 인력으로 해소했습니다. 두 고객이 계정을 이동했습니다. 재무팀은 지연 청구(invoicing)로 인한 보유 비용(carrying cost)과 손실 마진을 합쳐 대략 64,000파운드로 계산했습니다.

재작성에는 4일이 걸렸습니다. 동일한 14단계에 각 단계마다 ‘그리고 만약 그렇지 않다면(and if not)’ 한 줄을 추가했고, 6가지 지정 케이스를 커버하는 별도의 예외 섹션도 추가했습니다. 실제 결정 규칙도 함께 포함했습니다. 가격 재정의(price override)는 누가 승인할 수 있는지, 그리고 어느 정도까지 가능한지, 대체 규칙과 이를 승인하는 사람, 신용 한도 에스컬레이션 경로까지 말이죠.

이 문서는 새 코디네이터 2명과 재무 담당자 1명이 작성했으며, 누군가의 기억이 아니라 200건 주문 표본을 기반으로 작업했습니다. 이 디테일이 중요했던 이유는, 기억만으로 작성할 수 있었을 사람들은 이미 떠났고, 표본이 그들이 기억으로 작성했을 것보다 더 나은 자료였다는 점 때문입니다.

6개월 후, 주문당 예외 처리의 중앙값(median exception handling time)은 22분에서 7분으로 줄었습니다. 적체는 50건 미만에서 안정적이었고, 200건의 새 표본에서는 84%가 누구에게도 에스컬레이션하지 않고 문서만으로 해결 가능하다는 결과가 나왔습니다.

프로세스 문서화를 만드는 방법: 단계별

먼저 표본을 뽑고 예외를 세세요. 그 외의 모든 것은, 실제로 무엇을 문서화하는지 알게 되면 훨씬 쉬워집니다.

가능하다면 서로 다른 사람 두 명이 프로세스를 수행하는 모습을 두 번 관찰하세요. 같은 문서화된 프로세스를 수행하더라도 두 사람이 다르게 처리한다면, 그것 자체가 발견 사항입니다.

단계보다 먼저 경계와 결과(outcome)를 작성하세요. 그래야 문서가 불필요하게 길어지는 것을 막을 수 있습니다.

프로세스가 ‘원래 그래야 한다’고 생각하는 것에서가 아니라, 관찰한 내용에서 단계들을 작성하세요. 둘이 다르다면, 매끈하게 맞추기보다 차이를 기록하세요. 그 차이는 보통 채택할 만한 개선이거나, 고쳐야 할 문제이기 때문입니다.

각 단계에 ‘그리고 만약 그렇지 않다면(and if not)’ 한 줄을 추가하세요. 이 작업은 단계 작성보다 더 오래 걸릴 것으로 예상하세요.

예외 섹션은 순위 목록에서 위에서 아래로 작성하고, 전체 물량의 대부분을 차지하는 예외들을 커버했으면 멈추세요. 완벽한 커버리지는 목표가 아니며, 달성할 수도 없습니다.

그다음, 작업을 해본 적 없는 누군가가 당신이 지켜보는 동안 문서로 실제 사례를 한 번 실행해 보고, 아무 말도 하지 않게 하세요. 그들이 묻는 모든 질문은 결함이며, 질문은 예외 섹션에 모여 나타날 것입니다.

형편없는 프로세스 문서화가 만드는 영향

눈에 보이는 비용은 온보딩 시간이며, 그중 가장 작은 비용입니다.

더 큰 비용은 조용히 발생합니다. 프로세스를 아는 사람들이 한 주를 ‘질문을 받는 일’로 보내게 되는 중단이 생기는데, 이는 티켓으로 나타나지 않기 때문에 보이지 않습니다. 또한 같은 입력값에서 두 사람이 서로 다른 결과를 만들어도 아무도 알아차리지 못하는 불일치가 생깁니다. 고객이 비교해 보기 전까지는요. 핵심 인물 리스크도 있습니다. 한 사람이 자리를 비우면 프로세스가 돌아가지 않는데, 그 사실은 그 사람이 없을 때까지 숨겨져 있습니다.

그리고 결정이 흐트러지는 현상도 있습니다. 문서가 무엇을 해야 하는지 말해주지 않으면 사람들은 나름대로 합리적으로 결정하고, 시간이 지나면서 결정이 갈라져 결국 문서화할 단일 프로세스 자체가 남지 않게 됩니다.

네 가지 모두에서 공통 패턴은 이렇습니다. 형편없는 문서는 실패를 만들어내지 않습니다. 대신 작업량, 인력, 시스템 문제로 돌려지는 느린 악화를 만들어냅니다. 그래서 실제로 겪는 사람들이 거의 고치지 못하는 경우가 많습니다.

좋은 프로세스 문서화 템플릿을 만드는 요소는?

세 가지이며, 그중 어떤 것도 레이아웃이 아닙니다.

예외를 요구합니다. 단계 표와 그 외 아무것도 없는 템플릿은 매번 정상 경로 문서를 만들게 됩니다. 왜냐하면 그렇게 만들도록 유도하기 때문입니다.

마지막 업데이트가 아니라 ‘마지막으로 확인됨’ 필드가 있습니다. 이 차이가 유지보수의 의미를 바꿉니다.

그리고 경계에 대한 진술을 강제합니다. 그래야 같은 프로세스가 서로 다른 경계를 가진 세 팀에 의해 세 번 문서화되는 일이 생기지 않습니다.

그 외에는, 대부분의 템플릿 비교에서 말하는 것처럼 형식이 훨씬 덜 중요합니다. 예외를 커버하는 단순한 문서가, 예외를 커버하지 못하는 우아한 문서보다 낫습니다.

프로세스 문서 형식: 텍스트, 플로우차트 또는 체크리스트

세 가지 형식이며, 선택은 선호가 아니라 업무의 형태를 따라야 합니다.

번호 매긴 단계는 시작과 종료가 명확하고 분기(branch)가 적은 선형 프로세스에 적합합니다. 대부분의 행정 및 운영 프로세스가 여기에 해당하며, 위 템플릿도 이를 전제로 합니다.

플로우차트 또는 스윔레인은 실제로 분기되는 프로세스, 또는 여러 역할을 가로지르며 그 사이에 인계(handoff)가 있는 프로세스에 적합합니다. ‘이 부분은 누구의 일인가’라는 질문이 계속 나올 때 스윔레인이 특히 제 역할을 합니다. 다만 스윔레인은 디테일을 담기엔 좋지 않으므로, 텍스트 버전과 함께 사용하고 대체하지 마세요.

체크리스트는 순서보다 완전성이 더 중요한 프로세스에 적합하며, 메인 문서라기보다 보조 자료로 함께 두면 잘 작동합니다.

유용한 규칙 하나: 프로세스에 진짜 결정 포인트가 약 3개를 넘는다면, 쓰는 것만큼이나 그려서 표현하세요. 그보다 적다면 플로우차트는 장식이고, 번호 목록이 문서입니다.

프로세스 문서, SOP 또는 작업 지침: 무엇인가요?

세 가지 용어는 서로 바꿔 쓰이지만, 그 아래에는 실제로 구분되는 차이가 있습니다.

프로세스 문서화는 업무가 어떻게 흐르는지(종종 여러 역할을 거쳐) 설명하는 것으로, 서술형입니다. 여기서는 이 일이 어떻게 진행되는지에 대한 답을 합니다.

SOP는 권위가 있고 처방적입니다. 작업을 수행하는 승인된 방법을 명시하며, 통제됩니다. SOP에서 벗어나는 것은 곧 SOP에서 벗어나는 것이며, 우리의 SOP 템플릿이 그 구조를 다룹니다.

작업 지침(work instruction)은 가장 세분화된 형태로, 한 역할이 한 작업 스테이션에서 수행하는 한 가지 작업을 다룹니다. 규제 또는 제조 환경에서는 통제된 문서이며, 우리의 제조 작업 지침 템플릿이 이를 다룹니다.

실용적인 테스트는 ‘결과(Consequences)’입니다. 문서에서 벗어나는 것이 단지 다른 방식으로 일하는 것이라면, 그것은 프로세스 문서화입니다. 문서에서 벗어나는 것이 비준수(nonconformance)라면 SOP 또는 작업 지침이며, 프로세스 문서화에는 없는 버전 관리, 승인, 그리고 검토 주기가 필요합니다.

프로세스가 한 사람의 머릿속에만 있었고 그 사람이 떠나는 상황이라면, 문서화 작업은 사실상 인수인계(handover)입니다. 그리고 우리의 지식 전달 SOP는 그 작업을 제대로 수행하는 방법을 다룹니다. 여기에는 왜 누군가에게 자신의 업무가 어떻게 돌아가는지 물어보면 정상 경로가 나오게 되는지도 포함됩니다.

Word나 Excel에서 프로세스 문서화 템플릿을 받을 수 있나요?

문서는 Word 또는 Google Docs용입니다. ‘그리고 만약 그렇지 않다면’ 줄과 예외 섹션이 포함된 단계는 구조를 가진 글(prose)이며, 셀보다 문서에서 더 잘 읽힙니다.

Excel은 두 가지 보조 자료용입니다. 예외 로그(exception log)는 샘플에서 인스턴스당 한 행씩 예외 유형을 기록한 것으로, 순위 목록을 만들어내며 나중에 다시 실행해 무엇이 바뀌었는지 확인할 수 있습니다. 그리고 프로세스 레지스터(process register)는 모든 문서화된 프로세스를 담당자, 마지막으로 확인된 날짜, 깔끔한 실행 비율과 함께 나열한 것으로, 이런 자료 라이브러리를 관리하는 방식입니다.

PowerPoint는 프로세스를 발표할 때 플로우차트 또는 스윔레인 보기에 적합하며, 문서 자체에는 적합하지 않습니다.

PDF는 검증이 끝난 뒤 한 번 발급되는 버전으로, 라이브 복사본에서 내보낸 것입니다.

문서를 쓰지 않고 프로세스를 문서화하는 방법

예외 콘텐츠는 절대 ‘쓰지 않는’ 부분이며, 그 이유는 망설임이 아니라 시간입니다. 누군가는 그 일을 아는 사람과 함께 앉아 그 사람이 하는 일을 기록한 다음, 저녁 한때를 메모를 읽을 수 있는 형태로 바꾸는 데 써야 합니다.

녹화는 그 대부분을 없애줍니다. Trupeer AI는 화면 녹화를 단계와 화면이 이미 캡처된 서면 절차로 바꿔서, 프로세스를 아는 사람이 한 번만 수행하면 되게 합니다. 설명할 필요가 줄어듭니다.

유용한 요령은 표준 케이스가 아니라 예외를 녹화하는 것입니다. 다음에 가격 불일치나 구매 주문 누락이 들어오면, 처리하는 사람이 직접 처리하는 모습을 녹화하게 하세요. 2주 동안 6번의 녹화만으로도, 1년 동안 글로 쓰려 했을 때 커버되지 않았을 대부분을 담을 수 있습니다.

녹화하세요. 브랜딩하세요. 번역하세요. Trupeer하세요.

결과물은 지식 베이스의 가이드와 문서가 되어 일관된 브랜딩으로 제공되고, SOP creator는 통제가 필요한 절차를 다루며, 우리의 작업 보조 템플릿은 사람들이 자주 틀리는 ‘한 단계’에 대한 짧은 참고 자료를 다룹니다. 설정 지침은 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

Word에서 무료 프로세스 문서화 템플릿을 사용할 수 있나요?

위의 구조는 ‘그리고 만약 그렇지 않다면’ 줄과 표준 템플릿이 생략하는 예외 섹션을 포함해 Word 또는 Google Docs에 그대로 붙여넣을 수 있습니다. 잠금 해제 다운로드도 없고, 양식도 없습니다. 단계를 먼저 쓰기 전에 예외 섹션을 추가하세요. 단계를 먼저 쓰면 보통 사용 가능한 노력이 먼저 소진되기 때문입니다.

Excel에서 무료 프로세스 문서화 템플릿을 사용할 수 있나요?

Excel은 문서 자체보다 예외 로그와 프로세스 레지스터에 적합합니다. 로그는 샘플된 인스턴스당 한 행씩 예외 유형을 기록하며, 이것이 순위 목록을 만들어냅니다. 레지스터는 모든 프로세스를 담당자, 마지막으로 확인된 날짜, 깔끔한 실행 비율과 함께 나열하므로, 어떤 문서가 오래되어 구식이 되었는지 확인할 수 있습니다.

PDF에서 무료 프로세스 문서화 템플릿을 사용할 수 있나요?

문서를 누군가가 그 문서로 프로세스를 실행해 검증한 뒤 한 번 내보내고, 작업 버전은 편집 가능 상태로 유지하세요. 예외는 새로운 예외가 나타날 때마다 계속 추가되므로, 고정된 프로세스 문서는 대부분보다 더 빨리 구식이 됩니다.

PowerPoint에서 프로세스 문서화 템플릿을 사용할 수 있나요?

프로세스를 수행하는 것이 아니라, 프로세스를 이해해야 하는 사람들에게 설명할 때는 플로우차트 또는 스윔레인 보기를 슬라이드로 사용하세요. 디테일을 담기엔 적절하지 않으므로, 슬라이드로 ‘대신’ 만들기보다 문서에서 구성해 가져오세요.

Word에서 단계별 프로세스 템플릿을 사용할 수 있나요?

그것은 위 구조의 ‘단계 섹션’입니다. 번호 매긴 작업을 한 줄에 하나씩 작성하고, 각 줄마다 예상 결과와 ‘그리고 만약 그렇지 않다면’ 한 줄을 포함하세요. 두 개의 프로세스인지 고민하기 전까지는 약 12단계 정도로 유지하고, 두 줄을 넘는 내용은 예외 섹션에 넣으세요.

프로세스 문서는 얼마나 길어야 하나요?

예외가 필요로 하는 만큼이면 됩니다. 보통은 단계가 한 페이지 또는 두 페이지 정도로 이어지고, 예외 섹션이 더 길어지게 된다는 뜻입니다. 단계만 있고 예외가 없는 문서는 짧고 사용되지 않는 경우가 많습니다. 길이는 페이지 수가 아니라, 누군가가 새로 문서만으로 실제 사례를 완료할 수 있는지로 판단하세요.

누가 프로세스 문서화를 작성해야 하나요?

프로세스를 수행하는 사람이 작성해야 합니다. 기억이 아니라 실제 인스턴스의 표본을 기반으로 작업하세요. 위의 실제 예시는 그 논거입니다. 수년의 경험이 있는 두 사람이 자신의 프로세스를 철저히 문서화하면서 모든 예외를 빼버렸는데, 부주의해서가 아니라 질문이 유도한 것이 정상 경로였기 때문입니다.

프로세스 문서화는 얼마나 자주 검토해야 하나요?

일정표가 아니라 트리거에 따라 검토하세요. 시스템이 바뀔 때, 예외 유형이 새로 두 번 나타날 때, 프로세스를 소유한 사람이 떠날 때, 그리고 깔끔한 실행 비율이 변할 때입니다. 1년에 한 번 20개 인스턴스를 다시 샘플링하는 데는 한 시간이 걸리며, 예정된 일괄 읽기보다 더 많은 정보를 알려줍니다.