탄탄한 프로세스 개선 문서화는 일회성 성과를 누적되는 이점으로 바꿉니다. Trupeer를 사용하면 무료 프로세스 개선 문서 템플릿으로 시작해 브랜드 가이드라인에 맞게 커스터마이즈하고, 개선 산출물을 팀이 바로 이해할 수 있는 비디오 워크스루로 전환하여 도입을 촉진함으로써 개선 문서화에 드는 시간을 몇 시간이나 절약할 수 있습니다.

프로세스 개선 문서화란 무엇인가요?

프로세스 개선 문서화는 업무를 수행하는 방식에 대한 변경 사항을 기록한 문서입니다. 즉, 어떤 문제가 있었는지, 무엇을 발견했는지, 무엇을 어떻게 바꿨는지, 그리고 그 결과 무엇이 일어났는지를 담습니다.

이는 하나의 문서가 아니라 문서의 한 계열을 포괄합니다. 작업 중에 작성하는 A3 또는 문제 해결 시트. 새로운 방법을 표준으로 설명하는 표준 작업 문서. 마지막에 작성하는 개선 보고서. 린(Lean) 리드로 진행한 경우 밸류 스트림 맵(Value Stream Map). 그리고 업데이트된 절차 방식으로 만들어진 그 어떤 결과든 포함됩니다.

이는 현재 프로세스가 어떻게 돌아가는지를 설명하는 프로세스 문서화와는 구분됩니다. 프로세스 문서화는 현재(as-is) 상태를 다룹니다. 개선 문서화는 한 가지 as-is에서 다른 as-is로 이동한 기록이며, 두 문서는 끊임없이 혼동됩니다. 오늘의 프로세스가 어떻게 작동하는지에 대한 설명이 필요하다면, 프로세스 문서화 템플릿이 이를 다루며 아마도 찾고 있는 것이 바로 그것일 것입니다.

이 페이지는 개선이 남기는 문서상의 흔적(페이퍼 트레일)을 다루며, 특히 그 대부분이 6개월 뒤에는 가치가 없는 이유를 설명합니다.

개선 보고서가 잘못된 독자를 위해 작성되는 이유

개선 문서화는 프로젝트가 끝날 때, 프로젝트를 직접 운영한 사람이 작성합니다. 그리고 스티어링 그룹, 스폰서, 감사(audit), 또는 성과/이익 검토(benefits review)를 위한 문서로 제출됩니다.

그 독자가 알고 싶은 것은 한 가지입니다. “효과가 있었는가, 그리고 무엇을 얼마나 절감했는가.” 그래서 보고서는 그 질문에 답하도록 구성됩니다. 배경, 현재 상태, 근본 원인, 해결책, 실행, 실현된 이익, 승인(sign-off). 유통되는 모든 개선 보고서는 대체로 이런 섹션을 갖고 있으며, 그 질문에 충분히 능숙하게 답합니다.

문제는 그 독자가 한 번 읽고 다시는 읽지 않는다는 점입니다.

실제로 필요하게 될 사람은 18개월 또는 3년 뒤의 누군가입니다. 비슷한 문제에 직면했거나, 어떤 지표가 다시 흔들린 이유를 조사하고 있거나, 이전에 어떤 아이디어가 이미 시도된 적이 있는지 궁금해하는 사람입니다. 그 독자가 원하는 것은 완전히 다릅니다. “무엇을 가정했는데 틀렸던가”, “무엇을 해봤지만 실패했는가”, 그리고 “이 개선이 계속 작동하려면 무엇에 의존하는가”가 핵심입니다.

이런 내용들은 표준 개선 보고서에 전혀 나오지 않습니다. 첫 번째 독자가 요청한 것이 아니기 때문입니다. 그중 두 가지는 승인 시점에서 오히려 약점처럼 보이기 때문에, 그래서 편집되어 빠져버립니다.

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

1단계: 템플릿 섹션 열기

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

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

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

3단계: 템플릿 보기 확장

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

4단계: 템플릿 편집

선택한 템플릿을 수정하기 시작하려면 Edit을 클릭하세요.

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

• 새 섹션 추가

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

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

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

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

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

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

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

프로세스 개선 문서화 템플릿으로 다음을 할 수 있습니다:

• 문서화 시간 절약: 린(Lean) 및 식스 시그마(Six Sigma) 실무자가 사용하는 구조로 빈 페이지를 건너뛰세요.

• 모든 산출물 포착: 맵, 분석, 계획, 보고서를 위한 템플릿.

• 브랜드 유지: Trupeer의 브랜드 키트를 사용해 로고, 글꼴, 색상을 적용하세요.

• 도입 촉진: 밀도 높은 보고서를 팀이 바로 흡수할 수 있는 비디오 워크스루로 전환하세요.

• 개선 표준화: 모든 이니셔티브에 동일한 템플릿을 사용하세요.

• 글로벌 팀 대응: 한 번의 클릭으로 개선 문서를 65+개 언어로 번역하세요.

개선 보고서에 빠져 있는 세 가지 섹션

세 가지 추가만으로, 오래 걸리지 않으며, 나중에 누구나 필요로 하는 유일한 부분들입니다.

우리가 가정했고 틀렸던 것. 모든 개선은 원인에 대한 가설로 시작됩니다. 무엇이었는지, 그리고 어떻게 바뀌었는지를 기록하세요. 이는 보통 문서에서 가장 가치 있는 단락인데, 틀린 가정은 대개 가장 명백한 것이고 다음 사람도 그 지점에서 출발하기 때문입니다.

우리가 시도했지만 버린 것. 고려했으나 거절한 옵션과 그 이유. 이유가 기록되지 않은 거절 옵션은 2년 안에 다시 제안되고, 누군가는 한 달을 들여 왜 작동하지 않는지 다시 찾아내게 됩니다.

이 개선이 의존하는 것. 결과가 성립하는 조건입니다. 이 섹션은 가장 많은 일을 하며, 아래에서 그 자체로도 다룹니다.

이 세 가지를 추가하면, 마무리 문서가 시작 문서로 바뀝니다. 또한 누가 작성해야 하는지도 달라지는데, 실패한 가설과 버려진 옵션이 포함된 보고서는 성공을 보여주기 위해 작성된 보고서와는 다른 종류의 문서이며, 이를 받아들일 스폰서가 필요하기 때문입니다.

의존성(Dependencies): 당신의 개선이 조용히 의존하고 있는 것들

거의 모든 프로세스 개선은 조건부입니다. 특정한 것들이 사실이기 때문에 작동하며, 그 사실이 더 이상 사실이 아니게 되면 보통 아무도 두 사건을 연결하지 못한 채로 작동이 멈춥니다.

일반적인 의존성은, 보통 하나로 기록되지 않습니다.

프로젝트 중에 새로 만들어졌거나 재배정된 역할. 변경된 규칙 또는 임계값. 새로 도입된 미팅 또는 리뷰 주기. 시스템 구성 또는 자동화. 특정 인물의 참여. 공급업체 또는 상위(업스트림) 팀이 특정 방식으로 행동하는 것. 새 방법이 실행 가능해지게 만든 물량 또는 믹스 가정.

개선 보고서는 구현(implementation) 섹션에서 이 모든 것을 “실제로 수행한 것”처럼 언급하곤 합니다. 하지만 이것은 결과가 의존하는 조건으로 기록하는 것과는 다르며, 18개월 뒤 구조조정, 시스템 변경, 정책 번복으로 그중 하나가 사라질 때 그 차이가 엄청나게 중요해집니다.

각 의존성을 한 줄짜리 행(row)으로 작성하세요. 무엇인지, 현재 누가 소유하는지, 그리고 변경되면 무엇이 일어나야 하는지를요. 그런 다음 그 행들이 변경 시 참고될 수 있는 곳에 배치하세요. 즉, 닫힌 프로젝트 폴더 안이 아니라 프로세스 문서화와 함께 두는 것입니다. 개선 보고서에만 기록된 의존성은, 아무도 다시는 보지 않을 의존성입니다.

무료 프로세스 개선 문서화 템플릿: 복사해서 쓰는 보고서

여기서 복사하세요. 별표(*)가 표시된 세 섹션이 추가 항목입니다.

헤더. 개선 참조 및 제목. 영향을 받는 프로세스. 담당자(Owner). 스폰서. 시작 및 종료 날짜. 상태(Status).

문제. 숫자가 포함된 관찰(observation) 형태로 명시하세요. 무엇이 일어나고 있었는지, 얼마나 자주 발생했는지, 그리고 어떻게 알게 되었는지.

기준선(Baseline). 측정값, 변경 전 값, 측정 방법, 적용 기간, 그리고 측정 시점. 이것이 없으면 이후의 어떤 내용도 평가할 수 없으며, 이는 PDCA 방법 템플릿의 Check 단계에서 말하는 것과 같은 지점입니다.

우리가 가정했고 틀렸던 것. 초기 가설, 실제 조사에서 무엇이 발견되었는지, 그리고 두 내용이 언제 갈라졌는지.

근본 원인(Root cause). 증거와 함께, 그것이 무엇으로 밝혀졌는지.

우리가 시도했지만 버린 것. 고려한 옵션, 각 옵션이 거절된 이유, 그리고 다시 검토할 가치가 있으려면 무엇이 바뀌어야 하는지.

우리가 바꾼 것. 실제 개입(intervention)을 재현할 수 있을 만큼 정확하게 설명하세요.

결과(Result). 동일한 측정값, 동일한 방법, 사후 값, 차이, 그리고 인접한 작업에 대한 부수 효과(side effects).

이 개선이 의존하는 것. 의존성마다 한 행(row). 현재 소유자와 변경 시 수행할 작업을 포함하세요.

변경된 문서. 어떤 절차, 작업 지침 또는 작업 보조 자료가 업데이트되었는지(참조로). 문서가 하나도 바뀌지 않았다면, 그 개선은 표준화되지 않은 것입니다.

승인(Sign-off). 누가, 언제, 어떤 증거를 기준으로 승인했는지.

여기까지 복사하세요. 전체를 3~4페이지로 유지하세요. 개선 보고서에서의 본능은 길이를 통해 엄격함을 보여주려는 것이지만, 22페이지 보고서는 4페이지 보고서보다 읽는 사람이 훨씬 적습니다.

프로세스 개선 문서화의 유형과 각각을 언제 사용해야 하는지

가장 자주 건너뛰는 두 가지는 표준 작업과 레지스터입니다. 표준 작업을 건너뛰면 개선이 몇 주 안에 되돌아갑니다. 레지스터를 건너뛰면 조직은 어떤 것이 이전에 시도되었는지 답할 수 없는데, 이 질문은 가장 자주 나오고 가장 드물게 답변됩니다.

되돌아갔지만 아무도 알아차리지 못한 개선

Nettlebed Financial Services는 약 700명의 직원으로 생명보험 및 연금 상품을 관리합니다. 2023년에 신규 비즈니스 애플리케이션 처리에 대한 개선 프로젝트를 진행했는데, 중앙값 처리 리드타임(turnaround)은 5일 서비스 기준 대비 11.4일이었습니다.

4개월의 작업으로 중앙값을 4.2일로 낮췄습니다. 연간 환산 이익 약 34만 파운드로 성공으로 보고되어 이사회에 제출한 뒤 종료했습니다. 개선 보고서는 22페이지였고, 모든 일반적인 섹션이 포함되어 있었습니다.

그로부터 2년 뒤 처리 리드타임은 9.8일이 되었습니다.

개선이 종료 처리되었고, 보고가 합리화(rationalised)되면서 측정값이 다른 대시보드로 이동했기 때문에, 아무도 그 drift(흔들림)를 알아차리지 못했습니다.

조사 결과 세 가지 원인이 있었는데, 모두 이전에 그런 의존성으로 기록된 적이 없는 것들이었습니다.

프로젝트 중에 전담 트리아지(triage) 역할이 만들어졌다가, 2024년 구조조정(restructure) 때 일반 풀(pool)로 흡수되었습니다. 그 구조조정에 참여한 누구도 그 역할에 의존하는 것이 있다는 사실을 알지 못했습니다.

또한 애플리케이션에서 2개 필드를 초과해 누락된 경우, 추적하지 않고 같은 날 반송하도록 했던 규칙이 불만 제기 이후 조용히 되돌려졌습니다.

그리고 노후 큐(aged queue)에 대한 주간 15분 리뷰도, 그 리뷰를 운영하던 팀 리더가 다른 부서로 이동하면서 중단되었습니다.

이 세 가지 모두 원래 보고서에 나타났습니다. 세 가지 모두 구현 섹션에서 “수행한 것”으로 설명되었지만, 결과가 의존하는 조건으로는 하나도 나열되지 않았습니다.

두 번째 발견도 있었습니다. 보고서의 근본 원인 섹션에는 원인이 신규 비즈니스 팀의 자원이 충분하지 않다고 적혀 있었습니다. 하지만 실제 원인은 프로젝트 6주차에 확인된 것으로, 한 유통 채널에서 들어오는 애플리케이션의 38%가 미완성 상태로 도착한다는 것이었습니다. 이 발견은 프로젝트 작업 노트에만 남아 있었고 최종 보고서에는 반영되지 않았는데, 보고서가 배운 내용을 기록하기 위한 것이 아니라 해결책을 정당화하기 위해 작성되었기 때문입니다.

그들이 2026년에 프로젝트를 다시 돌렸을 때는 4개월이 아니라 3개월이 걸렸고, 2주차에 같은 결론에 도달했습니다. 다만 누군가가 개인 드라이브에 기존 작업 노트를 보관해 두었기 때문에 가능했습니다.

보고서 템플릿은 위의 세 섹션을 기준으로 다시 작성되었습니다. 의존성은 프로젝트 폴더가 아니라 프로세스 문서화와 함께 등록되었고, 각 의존성마다 소유자와 트리거가 함께 기록되었습니다.

그 이후 18개월 동안, 14개의 개선이 새 형식으로 문서화되었습니다. 역할 변경 1건, 시스템 변경 2건, 정책 번복 1건 등 총 4건의 의존성 알림이 발생했습니다. 그중 3건은 개선을 보존하기 위한 조치로 이어졌습니다.

개선 보고서를 단계별로 작성하는 방법

프로젝트 시작 시점에 기준선(baseline) 섹션을 작성하세요. 끝에서 작성하지 마세요. 소급해서 만든 기준선은 항상 약간 더 그럴듯하게 보이며, 모두가 그걸 알고 있습니다.

가정은 바뀌는 즉시 작업 노트에 기록하세요. 누군가가 “우리는 X라고 생각했는데 사실은 Y였어”라고 말하는 그 순간이 기록할 타이밍입니다. 프로젝트 끝까지 살아남지 못할 가능성이 크기 때문입니다.

버린 옵션은 버리는 시점에서, 이유와 함께 각각 한 줄로 기록하세요.

결과 섹션은 기준선과 동일한 측정값과 방법으로 작성하세요. 프로젝트 중 측정이 바뀌었다면, 비교가 어떻게 성립하는지 설명하고 그렇게 했음을 명시하세요.

의존성 섹션은 마지막에 작성하세요. 바꾼 모든 것을 뒤로 거슬러 올라가며, 각 항목에 대해 “이게 사라지면 어떻게 되는가?”를 질문해보세요. 이 질문은 구현 목록에는 없는 의존성을 드러냅니다.

그다음 변경된 문서의 이름을 적으세요. 문서가 하나도 바뀌지 않았다면, 숫자가 무엇이든 개선은 끝난 것이 아닙니다.

개선 레지스터와, 개별 보고서가 파일로 정리되는 이유

개별 개선 보고서는 한 번 읽고 파일로 정리됩니다. 이건 규율(discipline) 문제가 아니라 “찾을 수 있음(findability)”의 문제입니다. 관련 보고서가 존재하는지 아무도 모르니, 아무도 찾지 않습니다.

레지스터는 대부분을 해결하며, 세팅에 1시간 정도만 듭니다. 영향을 받는 프로세스, 한 줄로 적은 문제, 결과, 날짜, 소유자, 그리고 보고서 링크까지 포함해 개선당 한 행(row)으로 구성하세요.

두 개의 열(column)이 행정용 문서가 아니라 실제로 유용하게 만듭니다. 프로젝트 이름이 아니라, 사람들이 검색할 때 사용할 언어로 문제를 설명하는 짧은 키워드 목록. 그리고 의존성 개수로, 구조조정이나 시스템 변경을 검토하는 누구나 영향을 받을 수 있는 개선을 필터링할 수 있게 합니다.

달력(calendar)이 아니라 구조적으로 무언가가 바뀔 때 레지스터를 검토하세요. 레지스터는 딱 두 순간에 제 역할을 합니다. 누군가 개선을 제안할 때, 그리고 어떤 것이 하나를 되돌릴 수 있을 만큼 바뀔 때입니다.

프로세스 개선 문서화 모범 사례

작업 중에 문서화하고, 작업 후에 하지 마세요. 거의 모든 가치 있는 일은 작업의 중간에서 일어나며, 작업이 끝나면 사라집니다.

실패한 가설을 적어두세요. 이것은 보고서에서 가장 유용한 단락이며, 스폰서를 위한 편집을 거치면 가장 먼저 희생되는 부분입니다.

보고서를 표준과 분리하세요. 보고서는 한 번 일어난 일을 기록합니다. 표준 작업 문서(Standard work document)는 SOP 또는 작업 지침으로, 지금 작업이 어떻게 수행되는지를 기록하며, 이 문서가 개선을 살아 있게 유지합니다.

짧게 유지하세요. 4페이지가 22페이지를 이깁니다.

변경이 일어나는 곳에 의존성을 등록하세요. 프로젝트 폴더가 아니라 프로세스 문서화에서요.

측정을 제대로 종료하세요. 프로젝트가 끝난 뒤 그 지표를 누가 소유할지, 그리고 어디에 보고될지를 합의하세요. 소유자가 없는 지표는 흔들리고, 아무도 그것을 보지 못합니다.

개선 문서화인가요, 프로세스 문서화인가요: 무엇인가요?

직설적으로 말할 가치가 있습니다. 이 둘은 서로 바꿔 검색되며, 서로 다른 문서이기 때문입니다.

프로세스 문서화는 현재 프로세스가 어떻게 돌아가는지를 설명합니다. 이는 지속적으로 관리되며 작업을 수행하는 사람들이 읽고, 성공의 기준은 누군가가 그것을 바탕으로 프로세스를 수행할 수 있는지 여부입니다. 우리의 프로세스 문서화 템플릿이 이를 다룹니다.

프로세스 개선 문서화는 변경을 기록합니다. 무엇이 잘못이었는지, 무엇을 발견했는지, 무엇을 했는지, 그리고 무엇에 의존하는지를요. 이는 한 번 작성하고 유지 관리하지 않으며, 작업을 수행하는 사람이 아니라 변경을 검토하는 사람들이 읽습니다.

관계는 이렇습니다. 성공적인 개선은 프로세스 문서화의 업데이트를 만들어냅니다. 개선 보고서가 존재하는데도 프로세스 문서화가 여전히 예전 방법을 설명하고 있다면, 개선은 되돌아가며 보고서는 그것이 실제로 일어났다는 유일한 증거가 됩니다.

프로세스가 어떻게 작동하는지 기록하는 템플릿을 원하셨다면, 그것은 프로세스 문서화이며 다른 페이지에 있습니다. 그것의 플로우차트를 원하셨다면, 언제 그릴 가치가 있는지에 대한 우리의 프로세스 플로우 템플릿이 다룹니다.

Word 또는 Excel에서 프로세스 개선 템플릿을 받을 수 있나요?

개선 보고서용 Word 또는 Google Docs. 이는 구조가 있는 산문(prose)이며, 공유되어 코멘트가 달리고, 정렬되는 것이 아니라 읽히는 문서입니다.

Excel은 두 가지 용도에 적합합니다. 개선 레지스터는 목록 형태이며 필터링과 검색이 필요합니다. 그리고 의존성 로그는 의존성마다 소유자와 검토 트리거가 있는 한 행(row)이 필요하며, 프로세스별로 필터링 가능해야 구조조정이나 시스템 변경을 그 기준으로 점검할 수 있습니다.

서명 완료된 닫힌 보고서용 PDF. 다만 의존성 행은 편집 가능하고 다른 곳에서도 “살아 있어야” 합니다. 소유권이 바뀌면 의존성도 바뀌어야 하기 때문이며, PDF에서 고정된 의존성은 유지 관리되지 않을 의존성입니다.

PowerPoint는 스폰서를 위한 마무리 발표 자료에 적합합니다. 이는 보고서와는 다른 산출물이므로, 보고서 대신이 아니라 보고서로부터 만들어야 합니다. 덱(deck)만 남는다면, 가정과 버려진 옵션이 가장 먼저 사라집니다.

현장에서 실제로 무엇이 바뀌었는지 기록하는 방법

변경이 살아남는지 결정하는 개선 문서화의 섹션은 표준 작업(Standard work)입니다. 즉, 지금 작업이 어떻게 수행되는지를 설명하는 업데이트된 절차입니다. 또한 이 섹션은 가장 자주 건너뛰기도 하는데, 이를 작성한다는 것은 누군가가 방금 몇 달 동안 설계하느라 지친 방법에 대해 화면을 다시 촬영하고 단계를 다시 써야 한다는 뜻이기 때문입니다.

Trupeer AI는 그 비용의 대부분을 제거합니다. 새로운 방법을 수행하는 사람이 한 번만 기록하면, 출력물은 이미 캡처된 단계와 이미지가 포함된 “작성된 절차”가 되어, 만들기보다 확인할 준비가 됩니다. 개선은 프로젝트가 종료된 다음 분기가 아니라, 입증되는 바로 그 주에 표준화됩니다.

기록하세요. 브랜드화하세요. 번역하세요. Trupeer하세요.

두 번째 활용법도 알아두면 좋습니다. 변경하기 전에 기존 방법을 기록해두면, 결과 섹션을 솔직하게 작성하는 일이 훨씬 쉬워지는 “비교 가능한 이전 산출물(before artefact)”이 생깁니다. SOP creator는 변경되어야 하는 절차를 다루고, 우리의 5S 프로세스 개선 템플릿은 작업장 조직 측면을 다룹니다. 그리고 출력물은 일관된 브랜딩과 함께 지식 베이스에 저장됩니다. 설정 지침은 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

Word에서 프로세스 문서 템플릿이 있나요?

필요한 것이 프로세스가 현재 어떻게 작동하는지에 대한 설명이라면, 그것은 개선 문서화가 아니라 프로세스 문서화이며, 우리의 프로세스 문서화 템플릿이 예외가 단계보다 왜 더 중요한지까지 포함한 구조를 다룹니다. 이 페이지의 개선 보고서는 다른 순간에 작성되는 다른 문서입니다.

Word에서 다운로드할 수 있는 단계별 프로세스 템플릿이 있나요?

단계별 형식은 개선 보고서가 아니라 프로세스 문서화 또는 SOP에 해당합니다. 번호가 매겨진 액션, 줄마다 하나씩, 각각 예상 결과가 포함됩니다. 두 페이지 모두에서 잠금 해제 다운로드가 제공되지 않으며, 폼도 없습니다.

PDF에서 프로세스 문서화 샘플이 있나요?

게시된 샘플은 섹션 순서 측면에서 찾기 쉽고 읽을 가치가 있습니다. 특히 개선 보고서의 경우, 위의 섹션들이 유용한 부분이며, 세 가지 추가 항목은 게시된 어떤 샘플에도 들어 있지 않을 내용입니다. 거의 모든 게시 예시는 후임자를 위한 것이 아니라 스폰서를 위해 작성되었기 때문입니다.

비즈니스 프로세스 문서 템플릿이 있나요?

네, 그리고 그것은 개선 기록이 아니라 현재(as-is) 상태에 대한 설명입니다. 비즈니스 프로세스 문서, 프로세스 문서화, 프로세스 설명은 동일한 산출물에 대해 서로 바꿔 사용됩니다. 우리의 프로세스 문서화 템플릿이 이를 다룹니다.

개선 보고서와 A3의 차이는 무엇인가요?

A3는 문제 해결 중에 사용하는 작업 문서로, 한 장에 현재 상태부터 분석을 거쳐 대책까지 이어지도록 구성되며, 작업이 진행되는 동안 논의하고 주장하는 것을 전제로 합니다. 개선 보고서는 끝에 작성하고 이후에 읽습니다. A3를 잘 사용하는 팀은 A3가 의존성과 버려진 옵션을 기록하고 있다면, 별도의 보고서가 필요 없는 경우가 많습니다.

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

개선을 수행한 사람이 작성해야 합니다. 작업 노트는 프로젝트 내내 유지하고, 나중에 재구성하지 않는 것이 더 중요합니다. 더 어려운 요구사항은, 틀린 가정과 실패한 것들의 목록이 포함된 보고서를 받아들일 스폰서가 있다는 점입니다. 대안은 읽기에는 그럴듯하지만 아무에게도 도움이 되지 않는 문서이기 때문입니다.

개선 보고서는 얼마나 길어야 하나요?

3~4페이지입니다. 길이는 여기서 엄격함(rigour)을 대신하는 좋지 않은 지표이며, 긴 보고서는 혜택을 받을 바로 그 사람들에게조차 읽히지 않은 채로 파일에 들어갑니다. 분석에 정말 더 많은 공간이 필요하다면 부록에 넣고, 보고서 자체는 짧게 유지하세요.

개선 문서화는 얼마나 오래 보관해야 하나요?

레지스터는 무기한으로 보관하세요. 비용이 저렴하고 시간이 지날수록 더 유용해집니다. 보고서는 프로세스가 존재하는 한, 그리고 품질 시스템이나 인증이 요구하는 기간만큼 보관하세요. 의존성 행은 보고서에만 두면 안 됩니다. 누군가가 예전 프로젝트를 찾으러 갈 때가 아니라, 무언가가 바뀔 때 의존성을 찾을 수 있어야 하기 때문입니다.