정책과 절차는 잘 운영되는 모든 조직의 운영 체계입니다. 무엇이 기대되는지, 그리고 일이 어떻게 처리되는지를 정의하죠. Trupeer를 사용하면 무료 정책 및 절차 템플릿으로 시작해 브랜드 가이드라인에 맞게 커스터마이즈하고, 밀도 높은 정책 문서를 직원들이 실제로 끝까지 보는 비디오 워크스루로 바꾸면서 정책/절차 작성에 드는 시간을 몇 시간씩 절약할 수 있습니다.

정책과 절차의 차이는 무엇인가요?

정책은 규칙과 입장을 명시합니다. 무엇이 반드시 일어나야 하는지, 무엇이 허용되지 않는지, 그리고 누가 결정하는지를 말하죠. 의무의 언어로 작성되며 변경은 드물고, 그 위험을 감수하는 주체가 승인합니다.

절차는 어떤 일을 단계별로 어떻게 수행하는지 설명합니다. 실제로 그 일을 하는 주체가 작성하며, 시스템이나 프로세스가 바뀔 때마다 변경됩니다. 거버넌스가 아니라 작업을 수행하는 팀이 소유합니다.

또한 대부분의 가이드에서 둘과 함께 등장하는 프로세스는, 절차가 자리하는 더 넓은 흐름을 의미하며 보통 여러 역할과 여러 절차에 걸쳐 이어집니다.

실무적인 테스트는 동사입니다. must, may not, is required to 같은 표현을 쓰고 있다면 정책을 쓰는 것입니다. click, check, send, confirm 같은 표현을 쓰고 있다면 절차를 쓰는 거예요. 둘 다 많은 문서는 보통 두 문서를 함께 묶은 경우이며, SOP 템플릿은 절차 파트를 제대로 다룹니다.

대부분의 정책 라이브러리에는 아무도 필요로 하지 않는 문서가 들어 있는 이유

정책 템플릿을 검색하면 열다섯 개, 서른 개, 혹은 백 개가 넘는 옵션이 제시됩니다. 모든 목록은 시작점으로 보이지만, 대부분의 조직은 이를 쇼핑 리스트처럼 취급합니다.

결과는 예측 가능합니다. 템플릿과 컨설턴트 체크리스트로 조립되어 10년 동안 쌓인 라이브러리에는, 아무도 의뢰한 기억이 없는 정책이 들어 있고, 문제를 겪은 적이 없는 주제를 다루며, 더 이상 존재하지 않는 직무 직함을 인용하고 있습니다.

특정한 이유 때문에 정책이 더 적은 것보다 이 상황이 더 나쁩니다. 사람들이 신뢰할 수 없는 라이브러리는 아예 더 이상 참고되지 않게 됩니다. 직원들은 무언가를 찾아보는 일이 동료에게 묻는 것보다 느리고 덜 신뢰할 수 있다는 것을 배우고, 그 습관이 자리 잡으면 정말 중요한 정책은 그렇지 않은 정책과 함께 읽히지 않게 됩니다.

따라서 질문은 우리가 어떤 정책을 가져야 하느냐가 아닙니다. 우리가 정당화할 수 있는 정책이 무엇인지가 핵심이며, 그 정당화는 이름 붙일 수 있어야 합니다.

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

1단계: 템플릿 섹션 열기

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

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

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

3단계: 템플릿 보기 확장

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

4단계: 템플릿 편집

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

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

• 새 섹션 추가

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

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

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

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

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

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

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

정책 및 절차 템플릿으로 다음을 할 수 있습니다:

• 작성 시간 절약: 어떤 정책이든 검증된 구조로 빈 페이지를 건너뛰세요.

• 컴플라이언스 유지: 규제기관과 감사자가 기대하는 요소를 내장 섹션으로 제공합니다.

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

• 도입률 개선: 긴 PDF를 직원들이 실제로 끝까지 완주하는 비디오 워크스루로 전환하세요.

• 글로벌 표준화: 지역별 로컬 적용을 포함해 동일한 템플릿을 전 지역에서 사용하세요.

• 모든 직원에게 도달: 한 번의 클릭으로 정책을 65+개 언어로 번역하세요.

모든 정책에는 이름 붙일 수 있는 출처가 필요합니다

모든 정책 상단에 하나의 필드를 추가하세요. 왜 존재하는지입니다. 일관성을 보장하기 위한 목적처럼, 목적이 아니라 ‘출처’죠.

정당한 출처는 세 가지가 있습니다.

법적 또는 규제상의 의무. 이름을 붙이세요. 개인정보 보호 법률, 보건 및 안전 의무, 업종 규제, 고용 관련 법. 특정 법령이나 규제기관이 이 정책을 요구한다면, 그 정책에는 출처가 있습니다.

법에 준하는 외부 요구. 인증 기준, 보험사의 조건, 고객의 계약상 요구, 자금 제공자의 조건. 이는 실제로 존재하며, 어떤 조항인지까지 포함해 구체적으로 명시해야 합니다.

사고 또는 알려진 위험. 무언가가 발생했거나, 거의 발생할 뻔했고, 조직이 재발을 막기로 결정한 경우입니다. 무엇이었는지, 그리고 언제였는지를 기록하세요.

세 가지 중 어느 것도 없는 정책이 존재하는 이유는, 템플릿 팩에 포함되어 있기 때문입니다. 이것이 자동으로 무가치하다는 뜻은 아니지만, 그렇다고 해서 아무도 검토하지 않고 아무도 집행하지 않게 되며, 결국 라이브러리 안에서 주변의 모든 것을 희석시키는 채로 남게 됩니다.

기존 라이브러리 전체에 대해 이 필드를 사후적으로 채우는 작업은 불편하며, 거버넌스 기능이 할 수 있는 가장 유용한 일 하나입니다.

검증 테스트: 누가, 어떻게, 얼마나 자주 확인하나요

두 번째 필드는 정책을 ‘진술’에서 ‘통제’로 바꾸는 역할을 합니다.

모든 정책에 대해 세 가지를 답하세요. 첫째, 누가 준수 여부를 확인하는지. 둘째, 어떤 방법으로 확인하는지(감사, 샘플, 시스템 리포트, 관리자 승인 등). 셋째, 확인 주기가 무엇인지입니다.

세 가지를 모두 답할 수 없다면, 그건 정책이 아닙니다. 단지 선호를 적어둔 것이며, 조직은 그것이 실제로 준수되고 있는지 알 방법이 없습니다.

이것이 항상 삭제해야 한다는 뜻은 아닙니다. 때로는 특히 정책에 실제 위험이 수반되는 경우, 검증을 구축해야 하는 이유가 되기도 합니다. 하지만 검증 불가능한 정책은 특정 유형의 노출입니다. 규제기관, 보험사 또는 고객에게 ‘우리는 이렇게 한다’고 말해놓고, 이를 입증할 수 없기 때문이죠. 따라서 암묵적으로 두기보다는 ‘발견 사항’으로 기록해야 합니다.

문서가 실제로 유용하지만 검증이 불가능하다면, 라벨을 바꾸세요. ‘가이드’라고 부르고, 거버넌스 승인 경로가 아니라 팀 오너를 지정한 뒤 정책 라이브러리에서 빼세요. 가이드는 정당하고 유용한 범주이며, 가이드를 정책인 것처럼 가장하는 것이 라이브러리를 신뢰할 수 없게 만드는 이유입니다.

무료 정책 및 절차 템플릿: 그대로 복사할 구조

여기서 복사하세요. 별표(*)로 표시된 두 필드는 표준 템플릿이 생략하는 부분입니다.

헤더. 정책 제목. 참조 번호. 버전. 승인자 및 승인일. 시행일. 검토일. 소유자(사람이 아니라 역할로).

출처. 이 정책을 요구하는 의무, 요구사항 또는 사고(구체적으로 명시).

목적. 한 문단. 이 정책이 무엇을 위한 것인지, 쉬운 말로 설명합니다.

적용 범위. 명시적으로 제외된 모든 그룹을 포함해, 누구에게 적용되는지와 어디에 적용되는지.

정의. 의미가 정책의 효과를 바꾸는 용어만. 용어집이 아닙니다.

정책 진술. 번호 매기기. 각 항목은 단 하나의 의무만 포함하며, must, may 또는 must not으로 작성합니다. 거의 모든 약한 정책에 등장하는 should는 피하세요. should는 강제할 수 없기 때문입니다.

역할과 책임. 이 정책 아래에서 역할별로 누가 무엇을 하는지.

검증. 준수 여부를 누가 어떤 방법으로, 어떤 주기로 확인하는지, 그리고 증거는 어디에 보관하는지.

위반. 정책을 따르지 않았을 때 어떻게 되는지, 그리고 누가 처리하는지.

관련 문서. 이 정책을 구현하는 절차를 이름과 위치로 나열하세요. 여기서 다시 설명하지 않습니다.

개정 이력. 날짜, 버전, 무엇이 변경되었는지, 누가 승인했는지.

여기까지 복사하세요. 목록에 없는 것에 주목하세요: 단계. 정책에 시스템 사용을 위한 번호 매긴 지침이 포함되어 있다면, 그것은 이 문서가 참조하는 별도의 절차에 들어가야 합니다.

우리 조직에는 실제로 어떤 정책이 필요할까요?

템플릿 목록에서 시작하지 말고, 의무에서 시작하세요.

먼저 조직 유형, 규모, 업종에 대해 법이 요구하는 것을 파악하세요. 대부분의 관할에서는 보건 및 안전, 개인정보 보호, 고용 관련 사항, 그리고 업종별로 필요한 모든 것을 포함하는 짧고 구체적인 목록입니다. 법률 자문가는 한 시간 안에 이를 만들어낼 수 있고, 그 한 시간은 가치가 있습니다.

인증, 보험, 자금 제공자, 그리고 더 큰 고객이 요구하는 사항을 추가하세요. 이들은 조항 참조와 함께 오므로, 출처 필드는 저절로 채워집니다.

또한 조직의 자체 이력이 요구하는 것들을 추가하세요. 최근 3년간의 사고 로그, 불만, 거의 발생할 뻔한 사건, 보험 청구를 살펴보세요. 두 번 일어난 일은 정책 또는 절차로 다뤄야 합니다.

그다음 멈추세요. 서른 개 템플릿 목록이 ‘있어야 할 것’처럼 보인다고 해서 정책을 추가하지 마세요. 소규모 조직에 적절한 수는 종종 15개 미만이고, 중간 규모는 대개 60개를 넘지 않습니다. 200개짜리 라이브러리는 거의 항상 ‘고려된 세트’가 아니라 템플릿 팩의 누적 잔여물입니다.

187개 정책과 104개의 고아 문서를 가진 주택 협회

Ferndale Housing은 약 9,000채의 주택을 450명의 직원으로 운영합니다. 정책 라이브러리에는 180개 7개 문서가 있었고, 대략 15년 동안 템플릿 팩, 컨설턴트, 그리고 연속적인 컴플라이언스 프로젝트를 통해 쌓였습니다.

거버넌스 리드는 문서별로 추적 작업을 진행했습니다. 각 문서가 필요한 의무 또는 사건을 이름 붙이게 한 거죠.

41개는 법적 또는 규제 요구사항으로 추적되었습니다. 23개는 인증, 보험사 또는 자금 제공자의 조건으로 추적됐고, 19개는 특정 과거 사고로 추적되었습니다. 104개는 아예 추적 가능한 출처가 없었습니다.

그 104개 중 68개는 생성된 날 이후 한 번도 검토되지 않았습니다. 31개는 더 이상 존재하지 않는 직무 직함을 참조했습니다. 12개는 같은 라이브러리 안의 다른 정책과 모순되었습니다.

한 번의 모순은 이미 비용을 치르게 했습니다. 두 개의 정책이 같은 범주의 결함에 대해 수리가 ‘긴급’이 되는 기준을 다르게 정하고 있었는데, 하나는 24시간, 다른 하나는 4시간이라고 했습니다. 콜센터 직원들은 자신이 교육받은 쪽을 적용했습니다. 옴부즈맨으로 에스컬레이션된 민원은 부분적으로 어떤 정책이 적용되는지에 달렸고, 해결에는 법무 및 임원 시간 3주와 보상금 지급이 필요했습니다.

더 깊은 비용은 직원 설문에서 드러났습니다. 최전선 직원의 71%는 규칙이 무엇인지 알아야 할 때, 찾아보기보다 동료에게 묻겠다고 답했습니다.

정리 작업은 1/4이 걸렸습니다. 104개의 고아 문서 중 22개는 아무도 기록하지 않았지만 실제로는 출처가 있는 것으로 밝혀졌고, 그 출처를 반영해 다시 작성했습니다. 19개는 가이드로 재분류되었고, 명시적으로 라벨을 붙였으며, 팀 오너를 지정하고 승인 경로는 두지 않았습니다. 63개는 철회했습니다.

라이브러리는 187개 문서에서 105개로 줄었습니다.

그 후 살아남은 모든 정책에 출처와 검증 필드를 추가했습니다. 14개는 검증 필드에 대해 전혀 답할 수 없었고, 이는 문서화 공백이 아니라 거버넌스 발견 사항으로 기록되었습니다. 조직이 어떤 규칙이 준수되고 있는지 알 방법이 없다는 뜻이었기 때문입니다. 1년 안에 그 14개 중 9개는 검증 경로가 생겼고, 5개는 가이드로 하향 조정되었습니다.

정리 작업 후 12개월이 지나자, 동료에게 묻기보다 정책을 찾아보겠다고 답한 최전선 직원 비율은 29%에서 58%로 상승했습니다.

사람들이 따라할 수 있는 정책을 작성하는 방법

정책 진술을 먼저 쓰고, 그 밖의 모든 것은 그 다음에 작성하세요. 목적, 적용 범위, 정의는 실제로 무엇을 요구하는지 알고 나면 훨씬 쉽게 쓸 수 있고, 먼저 작성하면 얇은 규칙 주변에 긴 서문이 생기는 경향도 줄어듭니다.

must와 must not을 사용하세요. should는 작성자가 확실히 약속하기가 불편할 때 등장하는 단어이며, should가 가득한 정책은 위반할 수 없게 만들 수 없습니다. 즉 강제할 수 없다는 뜻이죠.

각 진술에 번호를 매기세요. 번호당 하나의 의무만. ‘and’로 연결된 두 가지 의무가 포함된 진술은 중간쯤에서만 준수되기 쉽습니다.

읽을 수도 있는 규제기관이 아니라, 실제로 준수해야 하는 사람을 위해 작성하세요. 두 대상 모두 현실적인 청중이며, 컴플라이언스 청중이 실제로 무언가가 일어나는지 여부를 결정합니다. 규제 언어를 피할 수 없다면 부록에 넣으세요.

사람이 아니라 역할을 명시하고, 명시된 모든 역할이 여전히 존재하는지 확인하세요.

그다음 테스트하세요. 따라야 하는 사람에게 맡겨서, 이제 그 사람이 무엇을 다르게 할지 물어보세요. 답이 ‘아무것도 없다’면 두 가지 중 하나입니다. 정책이 이미 일어나고 있는 일을 설명하고 있는 경우(문제는 없지만 인정해야 함)거나, 너무 추상적이라 실행할 수 없는 경우입니다.

정책을 실제로 쓸 수 있게 만드는 언어와 톤

짧은 문장과 능동태. “£500 초과 비용은 관리자 승인 대상입니다”가 아니라 “관리자는 £500을 초과하는 비용을 승인해야 합니다”처럼요.

정책이 개인에게 적용되는 경우에는 2인칭을, 조직에 적용되는 경우에는 3인칭을 사용하세요. 한 문서에 섞는 것은 흔하지만 혼란을 부릅니다.

법률 용어가 아니라 쉬운 표현을 쓰세요. 다만 법률 용어가 쉬운 표현이 담지 못하는 의미를 갖는 경우는 예외입니다. 정의된 용어를 반드시 써야 한다면 한 번 정의하고 일관되게 사용하며, 우아함을 위해 표현을 바꿔가고 싶은 유혹은 참으세요.

판단이 아니라 구체적인 기준을 제시하세요. “영업일 기준 2일 이내”는 강제할 수 있습니다. “신속히”는 그렇지 않습니다.

행위자를 숨기는 수동 표현도 피하세요. “~할 것으로 예상됩니다”는 누구에게 무엇을 하라고 말하지 않습니다. 누가 반드시 행동해야 하는지 이름 붙일 수 없다면, 그 진술은 아직 준비되지 않은 것입니다.

정책과 그 절차는 하나의 문서여야 하나요?

보통은 아닙니다. 이유는 깔끔함이 아니라 유지보수 때문입니다.

두 문서는 서로 다른 승인 경로를 가집니다. 정책은 보통 이사회, 임원 또는 위원회의 승인이 필요합니다. 절차는 운영 오너가 필요하죠. 둘을 묶으면, 시스템 업데이트로 인해 발생한 변경을 포함해 모든 절차 변경이 정책 수준에서 다시 승인되어야 합니다. 실제로는 업데이트가 일어나지 않기 때문에, 결합된 문서는 절차 파트에서 조용히 틀어지면서도 형식적으로는 승인된 상태로 남게 됩니다.

또한 변경 속도도 매우 다릅니다. 개인정보 보호 정책은 2~3년에 한 번 바뀔 수 있지만, 주체 접근 요청을 처리하는 절차는 케이스 관리 시스템이 바뀔 때마다 달라집니다.

따로 유지하고 연결하세요. 정책은 이를 구현하는 절차의 이름을 명시합니다. 절차는 어떤 정책을 지원하는지 밝힙니다. 절차가 운영 중인 시스템에서 발생하는 단일 고위험 변경이라면 method of procedure가 적절한 형태이고, 반복되는 운영 작업이라면 SOP 또는 job aid가 맞습니다.

회사 정책 템플릿과 각 템플릿이 속하는 위치

일반적인 회사 정책 세트는 서로 다른 오너를 가진 그룹으로 나뉘며, 다운로드하기 전에 이를 아는 것이 가치가 있습니다.

고용 및 행동. 징계, 고충, 결근, 성평등 및 다양성, 유연근무, 내부고발. HR이 소유하고 법무 입력을 받아 승인하며, 관할의 영향을 크게 받습니다. 여기서는 일반 템플릿을 그대로 쓰는 것이 가장 위험합니다.

보건, 안전 및 환경. 보건 및 안전 정책, 위험 평가, 사고 보고, 그리고 업종별로 요구되는 모든 의무. 특정 인원 규모 이상에서 법령으로 자주 요구되며, 지정된 양식이 있습니다.

정보 및 기술. 허용 사용, 정보 보안, 개인정보 보호, 원격 근무, 그리고 조달. 당사의 IT 조달 정책 템플릿은 승인 경로와 기준을 포함해, 이 중 하나를 제대로 작성한 예시입니다.

재무 및 상업. 비용, 위임 권한, 뇌물 방지, 이해상충, 조달 기준.

운영 및 업종별. 어떤 규제기관이든, 인증이든, 서비스 모델이든 요구하는 내용.

세 번째와 네 번째 그룹의 템플릿은 바로 가져와 적용하고 다음으로 넘어가세요. 첫 번째 두 그룹의 템플릿은 훨씬 더 신중하게 다루세요. 내용이 관할별로 특화되어 있고, 잘못 가져왔을 때의 비용은 문서화 문제가 아니기 때문입니다.

헬스케어 정책 및 절차 템플릿: 무엇이 다른가요

헬스케어 정책은 검색 유입이 많고, 실제로도 완전히 다른 분야의 지식입니다. 그래서 이에 대해 직접적으로 말하는 것이 좋습니다.

세 가지가 달라집니다. 임상 정책은 임상 거버넌스 승인과 임상 저자(임상 작성자)가 필요하며, 일반 템플릿으로는 둘 다 제공할 수 없습니다. 콘텐츠는 특정 규제기관과 인증 기관에 연결되어 있고, 그 요구사항은 처방적이며 국가와 진료 환경에 따라 달라집니다. 그리고 보관, 버전 관리, 직원 인지(acknowledgement)의 증거는 보통 ‘좋은 관행’이 아니라 ‘의무’로 요구되므로, 문서 주변의 프로세스가 문서만큼이나 중요합니다.

이 페이지의 구조는 헬스케어 조직이 필요로 하는 행정 및 운영 정책에 적용할 수 있습니다. 즉 조달, 정보 거버넌스, HR, 시설 관련 정책이죠. 임상 정책을 초안 작성하는 데는 사용하면 안 됩니다.

임상 콘텐츠의 경우에는 규제기관의 요구사항과 전문 단체의 가이드에 따라 작업하고, 임상 거버넌스를 통해 정책을 작성하고 승인받으세요. 템플릿에서 시작하는 것이 ‘진짜로 잘못된 접근’이 되는 몇 안 되는 사례 중 하나입니다.

더 일반적으로 말해, 이 페이지의 어떤 내용도 법률 또는 컴플라이언스 조언이 아닙니다. 고용, 안전, 개인정보 보호, 업종 규제는 모두 관할에 따라 달라지며, 해당 영역의 어떤 정책이든 효력이 발생하기 전에 자격을 갖춘 조언자에게 검토받아야 합니다.

Word 또는 PDF로 정책 및 절차 템플릿을 받을 수 있나요?

초안 작성과 작업용 복사본에는 Word 또는 Google Docs를 사용하세요. 정책은 여러 라운드의 코멘트와 승인 과정을 거치며, 개정 이력이 중요하기 때문입니다.

출판 버전에는 PDF가 필요합니다. 시행 중인 정책은 고정되어야 하고 버전 스탬프와 날짜가 찍혀야 합니다. 그래야 모두가 같은 문서를 읽고, 특정 날짜에 어떤 버전이 적용됐는지 입증할 수 있습니다. 마지막 포인트는 무언가가 분쟁될 때, 들리는 것보다 더 중요해집니다.

정책 레지스터(목록)에는 Excel을 사용하세요. 정책 자체가 아니라 레지스터입니다. 문서당 한 행으로 제목, 참조, 소유자, 승인일, 검토일, 출처, 검증 방법, 마지막 검증일을 넣으세요. 이 레지스터가 있어야 라이브러리를 관리할 수 있고, 대부분의 조직에는 이 레지스터가 없습니다. 검토일과 출처로 정렬하면, 어떤 개별 정책을 읽는 것보다 10분 만에 거버넌스에 대해 더 많은 것을 알 수 있습니다.

정책이 천천히 바뀔 때 절차를 최신 상태로 유지하는 방법

정책을 절차에서 분리하면 승인 문제를 해결하면서 유지보수 문제를 만들어냅니다. 이제 문서가 더 많아지고, 절차 파트는 계속해서 바뀌게 되죠.

그 절차 파트에 노력이 들어가는 이유는, 절차를 업데이트한다는 것은 이미 사용 방법을 알고 있는 시스템에 대해 누군가가 스크린샷을 다시 찍고 단계를 다시 써야 하기 때문입니다. 그리고 그 작업은 항상 더 긴급한 무언가에 밀려납니다.

Trupeer AI는 그 대부분을 제거합니다. 누가 작업을 수행하든 한 번만 기록하면 되고, 결과물은 이미 캡처된 단계와 화면이 포함된 ‘작성된 절차’로 제공되어, 조립(compose)하는 대신 바로 확인할 수 있습니다. 정책은 안정적으로 유지되고 승인된 상태로 남으며, 시스템이 바뀌면 그 아래의 절차는 오후 안에 새로 고칠 수 있습니다.

기록하세요. 브랜드를 입히세요. 번역하세요. Trupeer하세요.

SOP creator는 절차 자체를 다루고, documentation은 정책과 연결된 절차를 함께 유지하며, 정책 세트가 전체 기능이 어떻게 운영되는지 설명하는 경우에는 운영 매뉴얼 템플릿이 콘텐츠를 중복하지 않고 그 관점을 조립하는 방법을 다룹니다. 설정 지침은 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

Word용 무료 정책 및 절차 템플릿이 있나요?

위 구조는 출처와 검증 필드를 포함해, 표준 템플릿이 생략하는 부분까지 그대로 Word 또는 Google Docs에 붙여넣을 수 있습니다. 잠금 해제 다운로드도 없고, 양식도 없습니다. 집 템플릿으로 저장할 때 헤더 블록을 잠그세요. 검토일과 소유자 필드는 가장 자주 비워두기 때문입니다.

PDF용 정책 및 절차 템플릿이 있나요?

PDF로 게시하고 문서 편집기에서 초안을 작성하세요. 게시 버전은 고정되어야 하며 버전 스탬프가 찍혀야 합니다. 그래야 특정 날짜에 시행 중이던 버전이 무엇인지 입증할 수 있는데, 이것이 정책 라이브러리가 도움이 되는지(또는 그렇지 않은지) 결정하는 지점입니다.

소규모 조직을 위한 간단한 정책 템플릿이 있나요?

네, 그리고 더 단순한 것이 보통 더 좋습니다. 헤더, 출처, 목적, 적용 범위, 번호 매긴 진술, 책임, 검증, 위반, 검토일. 이것은 한 페이지이며 완전한 정책입니다. 소규모 조직은 너무 짧은 정책을 작성해서가 아니라, 큰 템플릿 팩을 채택해서 어려움을 겪는 경우가 많습니다.

다운로드할 수 있는 회사 정책 템플릿은 어디에서 찾을 수 있나요?

여러 라이브러리에서 제공하지만, 주의할 점은 어떤 그룹에서 가져오는지입니다. 재무, 상업, 운영 템플릿은 잘 적용됩니다. 고용, 보건 및 안전, 개인정보 보호 템플릿은 관할별로 달라서 사용 전에 조언자에게 검토받아야 합니다. 그곳에서 상속된 오류의 비용은 문서화 비용이 아니기 때문입니다.

정책은 누가 승인해야 하나요?

그 정책이 다루는 위험을 감수하는 주체가 승인해야 합니다. 대부분의 조직 정책에서는 임원 또는 이사회 위원회가 해당되고, 운영 정책에서는 해당 기능의 책임자가 해당합니다. 승인자가 그 정책이 부적절한 것으로 드러났을 때 책임을 질 수 있는지가 테스트 기준입니다. 아무도 책임질 수 없다면, 승인 절차는 행정적일 뿐이며 정책은 집행되지 않을 것입니다.

정책은 얼마나 자주 검토해야 하나요?

법적 또는 규제상의 출처가 있는 모든 것은 매년, 그 외는 2~3년마다 검토하세요. 또한 법이 바뀌거나 해당 영역에서 사고가 발생하거나 책임 역할이 변경될 때마다 트리거 검토를 추가합니다. 캘린더 검토만으로는 변경 없이 다시 발행되는 문서가 많이 생기므로, 사이클보다 트리거가 더 중요합니다.

정책은 얼마나 길어야 하나요?

대부분은 1~3페이지면 충분합니다. 더 길어지는 경우는 보통 절차가 섞여 들어왔거나, 규제 문구를 참조가 아니라 그대로 복제했기 때문입니다. 적용 대상인 사람들이 5분 안에 읽을 수 없는 정책이라면, 감사자 외에는 아무도 읽지 않을 것입니다.

정책, 절차, 프로세스의 차이는 무엇인가요?

정책은 규칙이며 누가 결정하는지에 관한 것입니다. 절차는 한 가지 작업을 한 역할이 수행하는 단계입니다. 프로세스는 그 절차들이 자리하는 더 넓은 흐름으로, 보통 여러 역할을 거쳐 결과로 끝납니다. 정책은 프로세스를 관리하고, 절차는 이를 구현합니다.