프로세스 설명서를 위한 최고의 가이드

프로세스 설명서에서는 사용자에게 조직 작업의 일부인 프로세스를 수행하는 방법을 설명합니다. 간략하게 살펴보는 개요를 말하는 것이 아닙니다. 프로세스 설명서는 상세하며 단계별로 제공됩니다. 또한 체크리스트 또는 흐름도와 같은 다양한 형태로 정보를 표시할 수 있습니다.

프로세스 설명서는 진행형입니다. 즉 항상 진행 중인 작업입니다. 프로세스를 캡처하고 설명하는 방법을 업데이트하고 개선하려면 조직에서 정기적으로 설명서를 다시 검토해야 합니다.

지식 공유의 결핍으로 인해 대기업에서 연간 4천 7백만 달러의 비용이 듭니다. 기업 중 4%만이 프로세스를 일관성 있게 문서화한다고 보고했습니다. 즉, 많은 조직이 설명서의 이점을 모두 활용하지 못하고 있습니다. 이 이점을 종합하면 생산성 및 수익 향상에 큰 도움이 될 수 있습니다. 여기에는 다음이 포함됩니다.

• 뛰어난 효율성. 프로세스 설명서는 품질을 향상시키는 동시에 비용 및 시간 절약으로 이어질 수 있습니다. ICU 체크리스트에서 Gawande는 프로세스 설명서가 연간 약 2백만 달러를 절약한다고 합니다.
• 원활한 공동 작업. 프로세스 설명서를 사용하면 팀원은 합의된 표준을 공유하기 때문에 오해와 혼란을 줄일 수 있습니다. 어떤 프로세스 접근 방식이 더 나은지에 대해 논쟁이 없습니다.
• 더 심층적인 참여. 프로세스 문서화는 직원 참여를 높일 수 있는 지식 공유 문화의 일부입니다. 7,000명 이상의 직원을 대상으로 한 설문 조사에서 응답자의 80%가 현재 역할 및 그들이 원하는 미래의 역할에 필요한 기술이 부족하다고 답했습니다. 다각도에서 살펴볼 문제라는 것은 분명하지만 프로세스 설명서도 직원이 원하는 학습을 제공하는 방법입니다.
• 프로세스 개선. 설명서를 통해 더 많은 직원이 프로세스를 수행할 수 있을 뿐만 아니라 프로세스 자체를 개선할 수도 있습니다. 문서화하려면 한 걸음 물러서서 프로세스를 면밀히 검토해야 하는데, 이 과정에서 이전에는 아무도 알아차리지 못했지만 더 효율적으로 작업할 기회를 발견할 수 있습니다. 프로세스가 작동하지 않는다는 것을 이미 알고 있는 경우에도 프로세스를 문서화하기 전에는 문제의 원인이 무엇인지 명확하게 알지 못할 수 있습니다.
• 더 빠른 교육. 프로세스를 문서화하면 더 효율적으로 신규 직원을 온보딩하고 계약자에게 작업 내용을 교육할 수 있습니다. 팀원은 프로세스를 다른 직원에게 반복해서 가르치는 것 외에도 다른 일에 집중할 수 있습니다. 동시에 교육을 받는 직원은 다른 직원에게 도움을 요청하는 대신 설명서를 참조할 때 자신감과 권한 부여를 더 많이 느낍니다.
• 지식 격차 감소. 팀에 항상 핵심 프로세스를 처리하는 팀원이 한 명뿐이라면 해당 팀원이 갑자기 자리를 비우게 된 경우 어떻게 하겠습니까? 이제 그 팀원이 지식을 공유하지 않고 조직을 떠난다면 상황이 얼마나 더 심각해질지 생각해보세요. 이런 일이 생기면 그 지식은 영원히 사라질 수 있습니다. 막대한 피해가 생길 것입니다. 프로세스 설명서로 지식을 공유하고 저장하세요.
• 더 높은 품질. 모든 직원이 따라야 할 프로세스 완료 모범 사례를 기록하면 팀원은 오류를 줄이면서 계속해서 더 나은 결과를 얻을 수 있습니다. Atul Gawande 박사의 베스트셀러 "체크! 체크리스트"에는 가장 간단한 프로세스 설명서의 힘에 대한 특히 놀라운 예시가 나옵니다. Johns Hopkins 병원의 한 의사가 중환자실에서 중심정맥관 감염을 방지하는 방법에 관한 체크리스트를 만들면서 단 1년 만에 43건의 감염을 예방하고 8명의 생명을 구할 수 있었습니다.

그러나 이 모든 이점을 얻으려면 먼저 프로세스를 문서화하기 위한 몇 가지 공통적인 장애물을 극복해야 합니다.

• 지식 독점. 정보를 자신만 알고 있어야 우위를 점할 수 있다고 믿기 때문에 정보를 공유하는 것을 좋아하지 않는 직원도 있습니다. 지식 독점의 문제가 있다면 투명성의 이점과 투명성이 직장 문화의 가치라는 점을 강조하세요.
• 자기 의식. 반면에 직원들은 자신이 "올바르게" 수행하고 있다고 생각하지 않아 프로세스 수행 방법에 대한 세부 사항을 생략하거나 변경할 수 있습니다. 그들은 자신이 실제로 하는 일 대신에 해야한다는 생각하는 할 일을 말해줍니다. 이런 문제가 발생하면 프로세스를 수행하는 가장 좋은 방법이 끊임없이 진화하고 있다는 생각을 강조하세요. 설명서는 누군가의 실수를 잡으려는 것이 아니며 학습과 개선에 관한 것입니다.
• 완벽주의. 프로세스 설명서는 매우 섬세한 작업입니다. 그러나 세부 사항 하나하나에 너무 몰두하기 시작하면 설명서를 완성하지 못할 수도 있습니다. 작고 간단하게 시작해도 괜찮습니다. 특히 프로세스를 처음으로 문서화하는 경우라면 더욱 그렇습니다. 앞으로 설명서를 지속해서 수정하고 개선해야 한다는 점을 기억하세요.
• 시간 제약. 모두가 바쁩니다. 프로세스 설명서를 다루는 데 전혀 신경 쓰지 않는 것 같으면 주간 일정을 확인하여 시간을 확보하고 팀의 캘린더에서 해당 시간을 차단하세요. 월 또는 분기를 선택하여 프로세스 설명서를 함께 업데이트하는 데 전념해도 됩니다.
• 설명서에 대한 신뢰 부족. 프로세스를 완료하려고 할 때 어렵게 작성된 설명을 읽어내려고 애쓴 적이 있다면 설명서는 가치가 없거나 득보다 실이 더 많은 것이라고 생각할 수 있습니다. 설명서가 성과를 거둘 것이라는 확신을 가지려면 템플릿과 철저한 설명서 표준으로 작업을 시작하세요.

이제 설명서를 시작할 준비가 되었습니다. 하지만 무엇부터 시작해야 할까요? 프로세스의 단계를 입력하기 전에 많은 계획이 필요합니다.

1. 범위 정의. 어떤 프로세스를 문서화합니까? 시작 지점과 끝 지점은 무엇입니까? 설명서를 사용하는 직원이 프로세스가 완료되는 시점을 어떻게 알 수 있습니까?
2. 대상 그룹 이해. 효과적인 프로세스 설명서를 만들려면 설명서를 사용할 대상을 명확하게 이해해야 합니다. 설명서 사용자의 특징은 무엇이며 이들에게 필요한 것은 무엇입니까? 예를 들어 작성자는 프로세스 경험이 많지만 설명서 사용자 대부분이 프로세스에 완전히 익숙하지 않은 경우 동료와 커뮤니케이션하는 것과는 다른 방식으로 작성해야 합니다.
3. 관련자를 식별. 두 명 이상의 직원이 프로세스에 관여하는 경우 각 직원이 수행하는 작업을 설명합니다.
4. 정보 수집. 프로세스에 참여할 수 있는 팀원 및 기타 이해 관계자와 대화합니다. 브레인스토밍 세션을 열고 싶을 수도 있습니다. 프로세스를 직접 수행하는 경우 진행하면서 문서화를 시작하세요. 다른 직원이 프로세스를 수행하는 경우 프로세스를 진행하면서 메모하도록 요청하세요.
5. 체계화. 모든 정보를 수집했다면 이제 사용자가 프로세스를 완료하도록 모든 정보를 최상의 순서로 배치할 차례입니다. 이 작업이 어렵게 느껴진다면 순서를 다시 정렬할 수 있는 색인 카드 또는 스티커 메모(원하는 경우 온라인 메모 기능)를 사용하여 단계를 정리해 보세요.
6. 작성. 개요를 더 명확한 설명으로 작성합니다. 시작하기 전에 사용자 경험(UX) 작성의 핵심 원칙 몇 가지를 검토하면 좋습니다. 독자가 읽는 데 방해가 될 수 있는 관련 없는 정보는 제거합니다. 능동적인 어조와 명확하고 분명한 표현을 사용하세요. 사용자 친화적 디자인에 적합한 방식으로 작성합니다. 예를 들어 짧은 단락 및 글머리 기호 목록을 사용하세요.
7. 시각 자료 추가. 사용자의 약 3분의 2가 시각적 학습자라는 사실을 아십니까? 흐름도 또는 다이어그램과 같은 시각적 도구를 사용하여 프로세스를 설명하면 사용자가 설명서를 훨씬 더 쉽게 이해할 수 있습니다. 문서화하는 프로세스를 시각 자료로 설명하는 것이 가능합니까?
8. 피드백 받기. 작성자가 첫 번째 초안을 이해할 수 있다고 해서 사용자도 내용을 이해할 수 있는 것은 아닙니다. 따라서 설명서를 널리 공유하기 전에 초기 검토자를 몇 명 선발해서 의견 및 제안을 요청하세요. 어떤 부분이 잘 진행되는지, 명확하지 않거나 추가 설명이 필요한 부분은 무엇인지 물어봅니다. 초기 검토자에는 프로세스에 익숙하지 않은 팀원도 포함해서 설명서를 사용해 프로세스를 완료할 수 있는지 확인합니다. 잘 완료했다면 스스로 칭찬하세요. 설명서를 잘 만들었습니다! 그렇지 않다면...
9. 수정. 검토자의 피드백을 수집하여 설명서를 개선하는 데 참고하세요.
10. 다시 공유. 검토자에게 수정된 설명서를 시도하도록 요청하세요. 검토자가 이제 프로세스를 완료할 수 있습니까?
11. 배포. 프로세스 설명서가 필요할 수 있는 모든 사용자가 프로세스 설명서를 사용할 수 있도록 합니다. 이 작업을 수행하려면 Confluence와 같은 중앙 집중식 지식 리포지토리를 사용하는 것이 가장 좋습니다. 이렇게 하면 모든 팀원이 동일한 버전의 설명서를 사용하고 어디에 있든 설명서에 액세스할 수 있습니다.
12. 업데이트 계획. 현재는 작업이 완료되었지만 프로세스 설명서가 언제까지나 변하지 않는다는 의미는 아닙니다. 지금 몇 가지 미리 알림을 예약하여 설명서가 잘 작동하는지 정기적으로 평가하고 추가 업데이트 및 개선 사항을 고려하세요.

문서화하는 프로세스의 규모 및 복잡성에 따라 이 단계를 조정할 수 있습니다.

프로세스 설명서의 모든 단계에서 조금 벅찬 느낌이 듭니까? 여기에 스트레스를 받지 마세요. 여러분은 혼자가 아닙니다. 설명서 프로젝트의 모든 단계에서 도구 및 템플릿을 사용하여 더 효율적으로 작업할 수 있습니다.

앞서 언급했듯이 프로세스를 문서화하려면 먼저 프로세스 작동 방식에 대한 정보를 수집해야 합니다. 때로는 여러 팀원과의 브레인스토밍 세션이 관련되기도 합니다. 모든 팀원의 시간을 최대한 활용하고 논의한 내용을 모두 기록하려면 Mural의 브레인스토밍 템플릿을 사용하는 것이 좋습니다. Mural의 템플릿은 생산적인 브레인스토밍 세션을 계획하고 회의를 구조화하고 결과를 캡처하는 과정을 안내합니다.

프로세스를 문서화하는 데 필요한 모든 정보를 수집하는 것만 해도 큰 산을 넘은 것입니다. 그러나 정보를 분류하고 논리적이고 이해하기 쉬운 형식으로 배치하는 것은 훨씬 더 어려운 단계로 느껴질 수 있습니다.

Confluence의 방법 안내 문서 템플릿을 통해 이 모든 것을 이해할 수 있습니다. 템플릿을 사용하면 다른 모든 프로세스 설명서 간에 일관성을 유지할 수 있다는 이점이 있습니다. 사용자가 무엇을 기대해야 하는지 알고 있으면 설명을 따르기가 더 쉽습니다.

Confluence의 방법 안내 문서 템플릿

흐름도 또는 다이어그램과 같은 시각적 요소는 정보를 더 빠르고 명확하게 전달할 수 있습니다. 프로세스 설명서에 시각 자료를 추가하기 위해 그래픽 아티스트가 될 필요는 없습니다. Gliffy 및 Draw.io는 Confluence의 애드온으로 사용할 수 있는 인기 있는 다이어그램 작성 도구입니다. Atlassian Marketplace에서 해당 도구 및 기타 시각적 도구에 대해 자세히 알아볼 수 있습니다.

Draw.io에서 제공한 프로세스 다이어그램 샘플

gliffy에서 제공한 전자 상거래 트랜잭션 프로세스 다이어그램 샘플

앞서 배포가 프로세스 설명서의 중요한 일부인 이유를 언급했습니다. 설명서가 아무리 명확하고 잘 정리되어 있더라도 필요한 직원이 사용할 수 없으면 큰 의미가 없습니다. 팀에는 프로세스 수행 방법에 관한 중앙 집중식 단일 정보 출처가 필요합니다. 따라서 마스터 프로젝트 설명서 템플릿 또는 기타 프로젝트 관리 템플릿을 통해 Confluence에 프로세스 설명서를 저장하는 것이 좋습니다. 또한 이 기능을 통해 설명서를 쉽게 찾고 업데이트할 수 있습니다.

프로세스 설명서는 물론 매우 중요하지만 단순히 작업을 빠르고 적절한 방식으로 완료하기 위한 것이 아닙니다. 팀의 집단지성을 발휘하는 것입니다. 개개인의 지식을 팀의 지식으로 전환하면 함께 더 많은 것을 성취할 기회가 열립니다.