비즈니스를위한 정책 및 절차를 작성하는 방법

직장을위한 정책과 절차를 작성하는 방법에 대한 가이드입니다.

데이비드 리버모어

정책 및 절차는 무엇입니까?

그렇다면 정책과 절차는 무엇입니까? 간단히 말해, 조직에서 작업을 수행하는 방법에 대한 단계별 지침입니다. 모든 직원에게 기대되는 것과 같은 일반적인 것이거나 특정 작업을 완료하는 방법 일 수 있습니다. 어느 쪽이든 정책과 절차를 통해 모든 사람이보고 따를 수 있도록 이러한 생각을 종이에 적을 수 있습니다.

이 기사에서는 다음 내용을 다룹니다.

• 정책 및 절차에 포함 할 사항
• 정책 및 절차를 형식화하는 방법.
• 하나의 예
• 팁
• 정책 및 절차 사용의 장단점.

정책 및 절차에 포함 할 내용

다음은 모든 정책 및 절차에 필요한 사항입니다.

• 헤더 -여기에는 조직, 부서 등의 이름이 포함되어야합니다. 이는 절차의 대상을 식별합니다.
• 제목 -절차의 제목입니다. 이것을 너무 길게하지 마십시오. 기억하고 참조하기 쉽게 만드십시오.
• 절차 번호 -쉽게 참조 할 수 있습니다. 이를 통해 절차는 책, 바인더, 온라인 데이터베이스 등에서 특정 순서로 진행될 수 있습니다. 번호 순서 일뿐만 아니라 절차 번호 사이에 동일한 간격 (예: 100, 105, 110 등)이 있어야합니다.
• 유효 날짜 -절차가 처음으로 발효 된 날짜입니다. 특정 작업에 대한 일정을 설정하는 데 중요 할 수 있습니다.
• 개정 날짜 -한 시점에서 절차가 변경된 경우이 날짜는 절차가 수정 된 날짜로 변경되어야합니다. 이렇게하면 모든 사람이 현재 변경 사항에 대한 최신 정보를 얻을 수 있습니다.
• 검토 날짜 -변경해야 할 사항이 있는지 확인하기 위해 절차를 검토 한 경우이 날짜를 변경해야합니다. 변경 사항이 없는지 여부는 중요하지 않습니다.이 날짜는 마지막 검토 날짜를 표시하도록 변경해야합니다.
• 승인 정책 및 절차의 방출을 승인 한 사람의 이름 -. 이것은 부서장 또는 감독자가 될 것입니다.
• 정책 -이것은 누가, 무엇을, 언제, 어디서, 왜, 어떻게에 포함되어야합니다. 그러나이 부분은 간단해야합니다. 기껏해야 정책이 시행되는 이유에 대한 개요 여야합니다.
• 지시 사항 -무언가를 수행해야하거나 그 사람이 따라야하는 전반적인 지시 사항이있는 경우 지시문에 있어야합니다. 즉시 알아 차려야하는 중요한 사항이있는 경우를 제외하고는이를 포함하지 마십시오.
• 절차 -이것이 귀하의 정책 및 절차의 대부분입니다. 정책이 지시하는 것을 수행하는 방법에 대한 항목 별 단계를 제공합니다.
• 페이지 번호 -각 페이지에 페이지 번호가 있어야합니다.
• 페이지 헤더 -페이지 헤더에는 정책 및 절차의 제목과 절차 번호가 포함되어야합니다.
• 이니셜 -정책 및 절차를 마지막으로 검토 한 사람의 이니셜이어야합니다. 또한 마지막 검토 날짜도 포함해야합니다.
• 예 -헤더, 페이지 번호 등이없는 별도의 페이지에 있습니다. 다음은 절차의 중요한 단계에서 설명되는 내용의 예입니다.

정책 및 절차를 포맷하는 방법

정책 및 절차를 작성할 때 몇 가지 기본 규칙이 있습니다.

• 글꼴 -일반적으로 사용되고 인식되는 글꼴이어야하지만 전문가가 아닌 것으로 간주되지는 않습니다. 예를 들어, Comic Sans는 비전문적 인 글꼴입니다.
• 글꼴 크기 -기껏해야 절차 전체에서 큰 글꼴 크기를 사용해서는 안됩니다. 절차마다 항상 일관성이 있어야합니다.
• 색상 -색상은 실제로 필요하지 않습니다. 절차는 검정색 글꼴이있는 흰색 배경에 있어야합니다. 그러나 예에서는 색상을 사용할 수 있습니다.
• 간격 -절차 부분은 쉽게 읽을 수 있도록 적절한 간격을 유지해야합니다. 단계 사이에 공백이 없으면 누군가 정책을 읽을 때 텍스트가 함께 실행됩니다.
• 여백 -다른 문서에 대한 조직의 표준이 무엇이든간에 만들어야합니다. 이것은 사용자가 절차를 읽고 사용하는 경향이 있습니다.

아래는 위에 나열된 각 범주에 대한 권장 스타일 요구 사항입니다.

• 머리글 -머리글은 항상 중앙, 굵게, 모두 대문자로 정책 맨 위에 있어야합니다. 또한 나머지 정책 및 절차에 비해 가장 큰 글꼴 크기를 가져야합니다.
• 제목 및 절차 번호 -둘 다 정책 및 절차에서 참조 용으로 사용되므로 둘 다 같은 줄에 있어야합니다. 크기가 같거나 헤더보다 약간 작을 수 있지만 모두 대문자로 굵게 표시해야합니다. 제목은 맨 왼쪽에 있고 절차 번호는 맨 오른쪽에 있어야합니다.
• 유효, 수정 및 검토 날짜 -이러한 작업이 다양한 방식으로 수행되는 것을 보았습니다. 때때로 그들은 그들 자신의 열에 있고, 어떤 때는 그들 자신의 행에서 그들을 본 적이 있습니다. 개인 취향이지만 항상 제목 아래에 있어야하며 글꼴 크기가 작아야합니다. 이전 카테고리와 마찬가지로 굵게 대문자로 표시해야합니다.
• Authorized By- 정책 및 절차 상단의 마지막 줄이 될 수 있습니다. 문서의 맨 왼쪽에 굵게 대문자로 표시해야합니다.
• 정책 -이 시점에서 정책이 시작됨을 나타내는 무언가가 있어야합니다. 일반적으로 "정책"이라는 단어는 모두 대문자와 굵게 표시 할 수 있지만 정책 자체는 굵은 문자 나 대문자로 설명하지 않습니다. 문서의 텍스트도 양쪽 맞춤을 원할 것입니다.
• 지시문 -이것은 일반적으로 눈에 띄고 싶은 것이므로 굵게 표시되고 모두 대문자로 표시됩니다. 정책과 절차에서 잘 보이도록 단락을 정당화하십시오.
• 절차 -이 부분은 매우 자세하기 때문에 설명하기 가장 어려운 부분입니다. 기본적으로 가능한 한 단계를 분리하는 것이 좋습니다. 정보의 단락을 원하지 않고 간단하게 텍스트를 따르기를 원합니다. 따라서 다른 들여 쓰기에서 다른 종류의 목록을 사용하여 가능한 한 많이 분리하십시오. 예를 들어, A.1.ia는 각각 이전과 다른 들여 쓰기에 있습니다. 그러나 "B"로 이동할 때는 앞의 "A"와 동일한 들여 쓰기가 있어야합니다. 아래 예는 이에 대한 실제 예를 보여줍니다.
• 페이지 번호 -문서 바닥 글 중앙에 위치해야합니다. 각 페이지의 번호를 만들거나 현재 페이지와 총 페이지 수 (예: 1/2 페이지)를 표시합니다. 첫 페이지에는 페이지 번호가있을 필요가 없습니다.
• 페이지 머리글 -첫 페이지 이후의 각 후속 페이지의 페이지 머리글은 제목과 동일해야하며 절차 번호는 첫 페이지에 있습니다.
• 이니셜 -각 절차의 마지막에 절차를 검토 / 수정하는 사람은 이니셜과 마지막으로 검토 / 수정 한 날짜를 포함해야합니다.
• 예 -이는 작성중인 절차와는 별개입니다. 여기에는 프로그램의 스크린 샷, 검토 할 테이블 등이 포함될 수 있습니다. 절차의 관련 지점에서 예제를 참조해야합니다 (예: 예제 A). 그런 다음 각 예제의 오른쪽 상단 모서리에 어떤 예제인지에 대한 참조가 있어야합니다.

정책 및 절차에 가장 적합한 글꼴

내가 추천하는 네 가지 글꼴이 있습니다.

1. Arial- 이 글꼴은 대부분의 문서에서 업계 표준으로 간주됩니다. 많은 컴퓨터에서 기본적으로이 글꼴을 사용하며 읽기 쉽습니다. 이 글꼴로 잘못 갈 수는 없습니다.
2. Times New Roman- 또 다른 산업 표준. 일부 컴퓨터 프로그램의 기본 글꼴로도 사용됩니다. 어떤 사람들은 이것을 컴퓨터 사용자의 1 세대가 인식하는 오래된 스타일이라고 생각합니다.
3. Calibri- 더 부드러운 접근 방식을 위해이 글꼴을 사용할 수 있습니다. 눈에 편하고 문서 모양을 매끄럽게 만듭니다. 정책과 절차는 읽고 쓰는 데 지루할 수 있으므로 사용하기에 더 좋은 글꼴 중 하나가 될 수 있습니다.
4. Georgia- 드물게 사용되는 글꼴이지만 눈에 띄는 글꼴입니다. 나는 Arial과 Times New Roman 사이의 십자가라고 생각합니다.

읽기가 너무 어렵거나 전문가답지 않은 앞면은 사용하지 않습니다. 비전문적 인 글꼴을 사용하면 아무도 정책과 절차를 심각하게 받아들이지 않을 것입니다.

아래 그림은 작동중인 네 가지 글꼴을 모두 보여줍니다.

위에 언급 된 글꼴의 예.

데이비드 리버모어

정책 및 절차의 예.

데이비드 리버모어

위의 정책 및 절차 예에서 사용 된 형식

이 표는 위의 예에서 사용한 형식을 다룹니다. 사용 된 글꼴은 Arial이며 달리 지정하지 않는 한 텍스트는 기본적으로 왼쪽에 있습니다.

범주	체재
머리글	14pt., 굵게, 가운데
표제	14pt., 굵게
절차 번호	14pt., 굵게
날짜	12pt., 굵게, 가운데
권한을 부여받은	12pt., 굵게, 가운데
수단	12pt., "정책"은 굵게, 양쪽 맞춤
지령	12pt., 굵게, 양쪽 맞춤
순서	12pt., 양쪽 맞춤
페이지 번호	10 점, 중앙
페이지 헤더	12pt., 굵게
머리 글자	12pt.

정책 및 절차에 관한 팁

다음은 정책 및 절차와 관련하여 따라야 할 몇 가지 일반적인 팁입니다.

• 절차를 자주 검토하십시오. 프로 시저를 작성했다고해서 완료된 것은 아닙니다. 주기적으로 돌아가서 절차의 변경 사항을 검토해야합니다. 일부는 몇 년에 한 번씩 검토 할 것을 권장하지만 가능하면 매년 검토하고 싶습니다. 또한 절차에 영향을 미치는 조직의 변화가 발생하면 즉시 정책과 절차를 변경해야합니다.
• 절차가 제공되기 전에 검토를받습니다. 몇 사람이 절차를 검토하여 이해가되는지 확인하십시오. 이 과정에는 신입 사원과 경험 많은 직원을 포함 시키십시오. 그들은 당신이 생각하지 못했던 정보를 제공 할 수 있습니다. 절차를 검토하는 정규위원회가 있다면 훨씬 좋습니다.
• 절차가 출시되면 모든 사람이 절차를 검토했는지 확인하도록합니다. 절차 작성이나 수정을 마치면 모든 직원에게 보냅니다. 그들은 그것을 검토 할 때 서명하고 날짜를 기입합니다. 또한 정책 및 절차에 대한 변경 사항을 알리기 위해 직원에게 이메일을 보냅니다. 이렇게하면 모든 사람에게 알린 문서가 있습니다. 대규모 조직에서는 팀 또는 섹션 수준의 감독자가 처리해야합니다.
• 목차를 개발하십시오. 많은 정책과 절차를 개발하게되면 특정 정책을 쉽게 찾을 수 있도록 목차를 개발하십시오.
• 절차에서 약간의 흔들림 공간을 허용하십시오. 직원은 서신에 대한 정책과 절차를 따르지 않아야합니다. 작업을 완료하기위한 가이드 역할을해야합니다. 오류가 발생하지 않고 법률을 위반하지 않는 한 절차를 따를 때 약간의 여유가있을 수 있습니다.
• 절차를 가능한 한 짧게 유지하십시오. 발생할 수있는 모든 시나리오 또는 상황을 포함하지 마십시오. 일 년에 한 번 일이 발생하면 왜 그에 대한 절차를 개발합니까? 메모 나 이메일로 제공하는 것이 가장 좋습니다.
• 절차에서 규칙이나 법률을 위반하지 않는지 확인하십시오. 대규모 조직에서는 절차를 개발할 때 고용 주나 직원이 해를 끼치 지 않는지 확인해야 할 수 있습니다. 필요한 경우 절차의 정책 부분에 정책 및 절차가 개발 된 이유를 법적 근거에 포함합니다.
• Google it. 정책 작성을 시작하기 전에 온라인으로 검색하여 다른 조직이 유사한 정책을 작성했는지 확인하십시오. 절차를 표절하지 마십시오. 대신, 그것을 읽고 당신이 찾은 아이디어를 기반으로 당신의 것을 만드십시오.

정책 및 절차 사용의 장점

다음은 정책 및 절차를 개발하는 전문가입니다.

• 일을하는 균일 한 방법을 허용합니다. 정책과 절차를 마련하지 않으면 사람들이 원하는 방식으로 일을 할 수 있습니다. 실수를하거나 과정에서 오류를 일으킬 수 있습니다. 정책과 절차는 그 문제를 해결합니다.
• 직원의 끊임없는 질문을 제거합니다. 감독자로서 저는 직원들로부터 끊임없이 질문을받습니다. 이제 정책과 절차가 완전히 업데이트되었으므로 질문에 답할 절차를 안내해 드릴 수 있습니다. 그러나 때때로 절차에 대한 설명이 필요합니다.
• 정책과 절차에 따라 직원은 책임을집니다. 올바르게 수행되면 정책 및 절차를 사용하면 직원이 특정 표준을 유지할 수 있습니다. 누군가는 자신이 무언가를 인식하지 못했거나 참조 할 것이 없다고 말할 수 없습니다. 정책과 절차를 통해 직원이 자신에게 기대되는 바를 알 수 있습니다.
• 신입 사원 교육에 적합합니다. 신입 사원을 영입하면 1 ~ 2 일은 그들과 긴밀하게 일하면서 보낸다. 나는 그들에게 일의 대부분을 보여 주지만 나는 떠난다. 제가 그들에게 남기는 한 가지는 정책과 절차입니다. 질문이 있으면 해당 절차로 안내합니다. 직업과 질문이있는 경우 어디로 가야하는지 배웁니다. 게다가 이것은 내 일을 할 수있는 자유를줍니다.
• 목표를 설정할 수 있습니다. 서면으로 직무를 수행하는 것의 좋은 점은 직원의 목표를 설정할 수 있다는 것입니다. 절차는 무엇을해야하고 언제 잠자리에 들어야하는지에 대해 설명 할 수 있습니다. 직원은이를 홍보, 인상 등의 노력에서 목표로 다룰 수 있습니다.

정책 및 절차 사용의 단점

다음은 정책 및 절차 개발의 단점입니다.

• 그것은 창의성을 억압합니다. 직원은 의사 결정에 자유가없는 것처럼 느낍니다. 그들은 항상 정해진 절차를 따라야한다고 느낀다면 틀 밖에서 생각하거나 문제에 대한 새롭고 창의적인 해결책을 찾지 못할 것입니다. 저는 항상 직원들에게 절차는 엄격하고 빠른 규칙이 아니라 지침을 의미한다고 말합니다. 성공적으로 목표에 도달하는 한, 방법은 중요하지 않습니다.
• 시간이 많이 소요될 수있는 지속적인 업데이트가 필요합니다. 무언가가 변경 될 때마다 누군가는 그것을 수정하기 위해 정책으로 돌아 가야합니다. 새로운 직무가 생기면 누군가가 그것을하는 방법에 대한 절차를 작성해야합니다. 시간이 많이 걸리는 과정입니다. 매주 저는 정책 및 절차를 업데이트하는 방법을 업데이트, 검토 또는 계획하고 있습니다.
• 조직의 성장을 방해 할 수 있습니다. 많은 직원이 "항상 이런 식으로 수행되었는데 왜 변경해야합니까?"라는 문구로 되돌아갑니다. 이것은 누군가의 창의성을 막는 것과는 다릅니다. 대신 어떤 사람이 항상 특정 방식으로 수행되었다는 문서를 보유하고 있다면 정책과 절차가 조직의 변화를 막을 수 있습니다.
• 직원은 절차의 단계를 여러 방법으로 해석 할 수 있습니다. 절차의 작성자가 완전히 다른 것을 의미 할 수있을 때 누군가는 한 단계를 한 방향으로 읽을 수 있고 다른 사람은 다른 방법으로 단계를 읽을 수 있습니다. 종이에있는 단어는 해석의 여지가 있습니다. 따라서 절차가 개발 될 때, 특히 긴 절차가 개발되면 이에 대한 구두 의사 소통이 있어야합니다.
• 그들은 쓰기가 지루합니다. 나는 때때로 절차를 작성하고 수정하는 데 여러 날을 보냈습니다. 매우 길고 복잡한 과정이 될 수 있으므로 제 직업에서 가장 흥미로운 것은 아닙니다. 지루한 문제는 실수하기 쉽다는 것이므로 수정 후 여러 사람이 정책을 확인하는 것이 중요합니다.

© 2014 데이비드 리버모어