IT ManagerИТ в бизнесеУправление

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

Юрий Шойдин | 13.03.2012

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

политика ИБ.

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

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

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

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

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

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

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

Таблица 1

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

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

img

img

Схема 1

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

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

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

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

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

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

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

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

Общие положения

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

Цель документа

Здесь указывается цель создания документа. По данному разделу в основном ориентируются пользователи, чтобы не читать весь документ. Например, регламент составлен с целью упорядочения подключения к сети Интернет и КИС внешних пользователей, не работающих в компании.

Основная часть

Думаю, тут комментарий излишен. Здесь формулируются правила и требования, описывается процедура.

Обязанности и ответственности

Данный раздел предназначен для того, чтобы все пользователи и сотрудники понимали меру как своей, так и чужой ответственности. Например, ответственность за подачу заявки несет руководитель подразделения, которому нужен Интернет; ответственность за подключение рабочего места – сотрудник хелпдеска (службы техподдержки).

Приложения

В данном разделе находятся формы заявок и графическое представление процесса, если это возможно.

Таблица 2

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

img

img

Схема 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    [ Подписка на журнал ]

Об авторах

Юрий Шойдин

Юрий Шойдин

Член правления Российского Союза ИТ-директоров, возглавляет Комитет по информационной безопасности. Связан с ИТ отраслью с 1992 года. Имеет 3 высших профильных образования, в том, числе МВА и несколько специальных. Основная специализация - проектирование сложных изменений в организации и системах управления. Более 35 проектов внедрения информационных систем (учетных и систем безопасности) на предприятиях по всей России в качестве РП. Является постоянным автором журнала и входит в экспертный совет. Является одним из организаторов ежегодной Санкт-Петербургской Конференции по информационной безопасности «Secure World»

Мероприятия

22.11.2018
Передача Audio, Video и KVM по IP: решения, опыт, истории успеха

Казань, пр. Фатыха Амирхана, 1A, комплекс «Казанская Ривьера».

30.11.2018
«Спутниковые данные программы «Коперникус»: новые возможности для инноваций»

Санкт-Петербург, КВЦ «Экспофорум» (Санкт-Петербург, Петербургское шоссе, 64/1, зал B3-B5)

07.12.2018
ИТ в Ритейле

Конгресс-центр «ЛЕНПОЛИГРАФМАШ»