Документирование деятельности. Кому это надо?

Если нет правил – нет и ответственности, а значит, и наказать вы никого не сможете.

Каждый руководитель, а тем более ИТ-директор сталкивается с документированием деятельности предприятия. Документы бывают разные и служат разным целям. Попробуем разобраться в основных правилах составления документов в близком нам ИТ-подразделении.

Для чего нужны документы? Прежде всего они нужны, чтобы зафиксировать на уровне предприятия или подразделения необходимые правила. В противном случае предприятию или подразделению грозит хаос. Мы часто с ним сталкиваемся, когда маленькая компания с одним системным инженером начинает бурно расти, становится средней компанией, а ИТ-подразделение по-прежнему находится в каменном веке с точки зрения документирования.

Когда нужно документирование? Документирование нужно всегда! Вопрос только в его объеме. Не требует объяснения тот факт, что при росте компании в обязательном порядке должен увеличиваться и объем документирования. При этом надо понимать, что чрезмерная любовь к нему либо приводит к излишней бюрократизации основных процессов вашей деятельности и замедляет их, либо у вас будет большой объем очень дорогой макулатуры, пылящейся на полке и измеряемой потраченным временем.

Не претендуя на уникальность, я постараюсь дать несколько советов по документированию деятельности подразделения, которые помогли мне в свое время.

Совет 1. Документируйте правила

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

Если нет правил – нет и ответственности, а значит, и наказать вы никого не сможете. Это касается как правил внутри подразделения, так и правил, определяющих взаимоотношения с другими подразделениями.

Совет 2. Сформируйте систему документов

Для начала надо создать свою или скопировать с другого блока компании структуру документов. Построение такой структуры, подчиненной единой логике формирования, является существенным преимуществом. Во-первых, вы будете четко понимать, какой документ (какого уровня) вам нужен и что в нем писать, а во-вторых, сможете построить документарную систему.

Судебная практика показывает, что все большую роль играют четкость формулировок в документах, имеющаяся в организации внутренняя нормативная база, а также соблюдение организацией ею же установленных правил работы с документами. Для чего это нужно? При правильно составленной системе документов даже проверка, нагрянувшая к вам, например, для контроля лицензионной чистоты используемого программного обеспечения, вынуждена будет уйти ни с чем.

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

Стратегическая группа

К ней относятся документы, определяющие правила для целых направлений или дочерних компаний. Это достаточно общие документы, описывающие ограничительные рамки

Стратегия развития ИТ,

политика ИБ.

В зависимости от содержания сюда можно отнести и Положение по КИС (корпоративной информационной сети)

Тактическая группа

Сюда входят документы, относящиеся к определенным направлениям деятельности и регламентирующие их

Положение о файловых серверах, положение по инвентаризации, положение по паспортиризации информационных ресурсов, положение о закупках

Операционная группа

Это самая нижняя группа правил. В основном здесь находятся инструкции и конкретные регламенты, устанавливающие правила выполнения конкретных операций

Должностная инструкция, инструкция по архивированию, инструкция о проверке серверного оборудования, инструкция допуска в серверную

Таблица 1

Совет 3. При формировании системы документов сделайте систему связанных документов.

Связанные документы имеют встроенную систему подчинения и перекрестные ссылки друг на друга, чтобы не переписывать общие части документов. Если вспомнить методику стратегического планирования и инструмент построения дерева целей, то условно можно сказать, что при создании системы связанных документов происходит то же самое. Дерево документов приведено на схеме 1.

Документирование деятельности. Кому это надо?. Рис. 1

Схема 1

Кроме этого, есть и еще несколько особенностей в формировании системы документов, которые знать необходимо.

Одной из причин того, почему в компаниях отсутствует документирование, связано с двумя проблемами: во-первых, трудно согласовать документ со всеми заинтересованными сторонами (другими руководителями, а их бывает много). Во-вторых, сложно увидеться с генеральным директором и объяснить ему целесообразность своего документа. И тем сложнее это сделать, чем более низкий уровень у вашего документа – ведь стратегию компании принять проще, чем инструкцию по обслуживанию. Причина, надеюсь, понятна всем. Выход из данной ситуации есть.

Глядя на дерево документов, можно с уверенностью сказать, что каждый подчиненный документ должен действовать в рамках родительского. Значит, один раз утвердив у генерального директора документ верхнего уровня, в остальных можно писать, что документ действует в рамках вышестоящего документа и утверждается только директором по ИТ. Далее, у вас полностью развязаны руки, так как нарушение документа низшего уровня приводит к нарушению документа, подписанного генеральным директором, и может грозить виновнику как минимум выговором.

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

Совет 4. Документы должны быть легитимны

Для того чтобы любой документ компании мог вступить в силу, он должен быть утвержден генеральным директором и введен в действие приказом по организации. Как правило, небольшие компании не утруждают себя формированием приказов и используют только утвердительную надпись. Казалось бы, документ составлен и подписан – замечаний нет, но есть вопрос. Представим себе ситуацию: вы утвердили у генерального директора положение по обслуживанию пользователей, где написано, что заявку на ремонт компьютерной техники вы обязаны выполнить в течение трех дней, а подать ее другое подразделение должно в письменном или электронном виде. Далее в бухгалтерии ломается принтер – вам звонят и требуют, чтобы принтер работал через 2 часа. Вы, в соответствии с положением, действуете не спеша. К вечеру вас вызывает генеральный директор и объявляет выговор за срыв сдачи баланса. Ваши возражения и положение по обслуживанию не принимаются во внимание. Теперь представим ситуацию с наличием приказа. Орущему главбуху мы указываем на прямое нарушение приказа генерального директора, просим уменьшить громкость и написать заявку с пометкой «срочно». Если все же главбух добрался до генерального с претензией и на основании этого вас решили уволить, то у вас есть все шансы не только восстановиться на работе по суду, но и получить 100% оплату за все время с момента увольнения до момента восстановления. Пустячок, но приятно.

Читайте также

Сергей Белан: Кибербезопасность как искусство

Почему безопасность — это командная игра, а будущее ИТ за молодежью и искусственным интеллектом? В интервью журналу IT Manager Сергей Белан, начальник управления защиты информации ОАО «Белорусская универсальная товарная биржа», рассказал, как балансировать между безопасностью и бизнес-целями, почему AI — это шанс обогнать конкурентов и как строить культуру ответственности за ИБ внутри команды.

Совет 5. Соблюдай структуру документа

Все документы должны иметь одну структуру. Это выгодно и вам, и пользователю ваших документов. Для себя я определил следующую структуру документов:

Общие положения	Обычно здесь указывается, в соответствии с какими требованиями или на основании каких документов сформирован регламент. Фактически это правовая основа существования вашего документа. Например, порядок подключения сотрудников к Интернету может проводиться в соответствии с требованиями «Положения по КИС» (корпоративной информационной сети), «Положения по ИБ» (информационной безопасности) и «Положения по КТ» (коммерческой тайне).
Цель документа	Здесь указывается цель создания документа. По данному разделу в основном ориентируются пользователи, чтобы не читать весь документ. Например, регламент составлен с целью упорядочения подключения к сети Интернет и КИС внешних пользователей, не работающих в компании.
Основная часть	Думаю, тут комментарий излишен. Здесь формулируются правила и требования, описывается процедура.
Обязанности и ответственности	Данный раздел предназначен для того, чтобы все пользователи и сотрудники понимали меру как своей, так и чужой ответственности. Например, ответственность за подачу заявки несет руководитель подразделения, которому нужен Интернет; ответственность за подключение рабочего места – сотрудник хелпдеска (службы техподдержки).
Приложения	В данном разделе находятся формы заявок и графическое представление процесса, если это возможно.

Таблица 2

Графическое представление вашего документа поможет вам не только еще раз проверить правильность его логики, но и увидеть и оптимизировать описанные процедуры. Например, вот так упрощенно может выглядеть процесс к регламенту технического обслуживания удаленного объекта компании:

Схема 2

Совет 6. Держи документы в порядке

Со временем количество документов в подразделении растет, появляются новые положения, правила и регламенты. Для того чтобы вы и ваши сотрудники помнили, какие документы необходимо иметь, существует журнал учета документов. Такой журнал можно использовать и для контроля состояния документов и учета их версионности. Журнал прост и нагляден, но главное, он должен поддерживаться в актуальном состоянии. Таблица 3.

Группа	№	Наименование документа	Состояние	Дата введения	Примечания
Стратегическая	1	Политика в области ИТ (Стратегия развития)	Разработан		Не утвержден
	2	Политика в области информационной безопасности	Утверждено	01.10.08
		Положение о конфиденциальной информации	Утверждено	01.10.08
	3	Положение о корпоративной информационной системе	Утверждено	15.10.08
Тактическая	1	Положение о пользовательской структуре файловых серверов	Утверждено	01.02.08
	2	Бюджет	шаблон		Не актуально
	3	Положение о подразделении	Утверждено	01.02.08
	4	Положение по оценке поставщиков (закупка)	На изменении	01.03.08	Ждем структуру по закупкам
	5	Положение по планированию	шаблон		Не актуально
	6	Перечень информационных ресурсов, подлежащих защите	В разработке		Версия 1
Операционная	1	Должностные инструкции сотрудников	Утверждено	01.09.08	Не подписано сотрудниками
	2	Инструкция по приему/увольнению	Передано в ОП	01.10.08
	3	Требования к персоналу (стандарт квалификации)	разработан		Передан в ОП
	4	Регламент подразделения	Разработан
	5	План защиты информационных ресурсов	нет
	6	План восстановления информационных ресурсов	нет
	7	Инструкция пользователя компьютерной системы	нет

Таблица 3

Совет 7. Документируйте только самые важные правила

Правила, как и документы, работают только там, где они реально необходимы и востребованы. Если вы создадите документ с правилами включения компьютера, то, скорее всего, к нему никто обращаться не будет. Шанс, что он кому-то потребуется, крайне мал. Самый простой вариант найти темы необходимых документов – вспомнить, по каким вопросам возникали конфликты. Для начала этого вполне достаточнот.

Вообще, самый удобный вариант формирования последовательности создания необходимых документов – это внимательное изучение основных и критичных процессов предприятия и подразделения. Формируйте документы только для критичных точек этих процессов.

Идеальным вариантом создания системы документов в компании является подготовка к сертификации по стандарту качества ИСО ГОСТ Р 9001. В рамках подготовки документов к такой сертификации вам придется составить два необходимых документа:

· Стандарт предприятия «Управление документацией»

· Стандарт предприятия «Управление документами и записями»

Данные документы и мои нехитрые советы могут стать основой для хорошей и качественной системы документов вашей компании.

Журнал IT Manager

Опубликовано 13.03.2012