Чек-лист разработки внутреннего нормативного документа

Чек-лист проверяет действия по процессу создания внутреннего нормативного документа от лица владельца процесса. Возьмем за данность, что:

1. владелец процесса является ответственным разработчиком документа и отвечает за его создание перед своим руководителем,

2. все внутренние нормативные документы утверждаются генеральным директором в случае их согласования ответственными должностными лицами,

3. описанный процесс применяется в компании малого или среднего бизнеса.

Популярное по теме

Чек-лист разработки внутреннего нормативного документа

581

0

Посмотреть чек-лист

Подготовка к разработке документа

1. Определить цели создания документа (например, разработать положение об общих принципах работы, ввести регламент для описания конкретных действий исполнителей, стандарт для унификации работы).

Важно! Под цель документа определяется вид документа.

2. Определить вид документа: политика, положение, регламент, стандарт, инструкция.

3. Определить перечень лиц, которые должны принять участие в разработке документа (соразработчики). 

4. Определить площадку, на которой будет осуществляться разработка документа в нескольких итерациях (например, система электронного документооборота / СЭД, Гугл-документы, др.).

5. Определить список лиц, которые должны согласовать документ (в соответствии с внутренними регламентами) без участия в его разработке. 

6. Определить список лиц, которые должны быть ознакомлены с документом.

Разработка и согласование документа

7. Сделать драфт (проект) документа - так, как его видит разработчик. В соответствии с определенным видом документа сделать его структуру, заполнить ее информацией, которой владеет разработчик.

8. Подготовить список вопросов, на которые должны ответить соразработчики документа - в соответствии со своей компетенцией и функционалом.

9. Разослать драфт документа лицам в соответствии с п.3 / информировать о нахождении документа на платформе для обсуждения.

10. Определить срок предоставления дополнений и корректировок (редлайн).

11. К назначенному сроку проверить внесение изменений. Если разработчик не согласен с какими-то изменениями, обсудить эти изменения.

Первый вариант обсуждения изменений: обсуждать письменно, на платформе, в режиме "для всех". 

Второй вариант: обсудить лично и договориться о согласованных правках.

Третий вариант: провести рабочую встречу со всеми соразработчиками, обсудить внесение изменений, о которых не получается договориться лично. Цель встречи - прийти к консенсусу. Решение оформить в виде протокола с подписями всех присутствующих.

12. Провести несколько итераций обсуждений в удобных форматах.

13. Сделать финальный драфт документа.  

14. Отправить финальный драфт всем соразработчикам для финального согласования, зафиксировать дедлайн. 

Утверждение / подписание документа

15. В случае согласования подготовить готовый документ (в бумажном или электронном виде) с листом согласования.

16. Собрать подписи всех соразработчиков документа (физические или электронные).

17. Если в лист согласования документа входят лица, которые не относятся к соразработчикам, но должны согласовать документ в обязательном порядке, собрать подписи (физические или электронные) - в соответствии с п.5. 

18. Передать готовый документ с подписями всех ответственных лиц (принимавших участие в разработке и согласовавших документ) на подпись генеральному директору. 

19. Зарегистрировать готовый документ во внутренней системе учета документов.

Ознакомление с документом

20. Ознакомить с новым внутренним нормативным документом всех сотрудников организации, до сведения которых он должен быть доведен.

21. Собрать подписи об ознакомлении с документом (физические или в электронном виде).

Важно!

• Новый разработанный документ не должен противоречить никакому из уже существующих документов. 
• Несколько документов, связанных единой тематикой или бизнес-процессом, должны образовать взаимосвязанную систему документов, при необходимости отсылать друг к другу или расшифровывать положения друг друга.
• Чтобы нормативные документы были рабочим инструментом, владелец процесса или разработчик документа должен отслеживать применение документа в работе.
• В компании должна существовать система отслеживания применения внутренних нормативных документов вплоть до использования санкций в случае нарушения норм документов.