ИТ-архитектура от А до Я: Шаблоны документов. Первое издание

Раздел I: Управление ИТ Сервисами;

•Глава 1: Стратегические ИТ документы;

•Глава 2: Политики и Положения ИТ;

•Глава 3: ИТ Стандарты;

•Глава 4: ИТ Процедуры;

•Глава 5: Должностные Инструкции;

•Глава 6: Сервисные Соглашения;

•Глава 7: Прочие документы ИТ;

Раздел II: Информационная Безопасность;

•Глава 1: Стратегические документы ИБ;

•Глава 2: Политики и Положения ИБ;

•Глава 3: Стандарты ИБ;

•Глава 4: Процедуры ИБ;

•Глава 5: Должностные Инструкции;

•Глава 6: Прочие документы ИБ;

Раздел III: Управление Проектами;

УПРАВЛЕНИЕ ИТ СЕРВИСАМИ

ОБЩАЯ ИНФОРМАЦИЯ

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

•Политики и положения – высокоуровневые документы, определяющие общие положения, методы достижения целей, задачи и т п. Определяют высокоуровневые значения (например, … длинна пароля должна быть регламентирована …) Как правило содержит общее описание процедур и принципов.

•План – это заранее намеченная система мероприятий, предусматривающая порядок, последовательность и сроки выполнения работ. Как правило хорошо проработанный документ с высоким уровнем детализации.

•Стандарт – документы промежуточного уровня, определяющие метрики для методов, определённых в политиках (например, … длина пароля восемь символов…). Наиболее часто изменяемый документ ввиду непрерывности и изменчевости бизнес требований и возможностей организации.

•Процедуры – документы промежуточного уровня, определяющие пошаговый регламент работ для применения политик с использованием метрик стандартов, инструменты, исполнителей, инструкций и т п. как правило глубоко детализированный документ с блок схемами, примерами выполнения действий с конкретной информационной системой. Например, «Процедура Управления Инцидентами» построенная на базе решения Microsoft System Center 2016 Service Manager.

•Стандартные Операционные Процедуры (СОП) – документы промежуточного уровня, определяющие пошаговые действия для рутинных работ, указанных в регламенте работ по сервису. К таким работам можно отнести установку сервиса, создание резервной копии, восстановление и т п.

•Инструкции, акты и формы – низкоуровневые документы, определяющие действия сотрудников внутри ИТ департамента, конечных пользователей, факты выполнения действий и т п.

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

Кроме этого, в зависимости от структуры организации некоторые документы могут быть сгруппированы по ролевому принципу. Так для примера, если в организации имеется выделенная роль «Оператора Резервного Копирования», чья задача состоит в создании резервных копий всех ИТ сервисов, то есть смысл сгруппировать процедуры резервного копирования всех ИТ сервисов в одном документе. Это позволит сотруднику поддерживать актуальность информации, и избавит от необходимости просматривания документы «Детальной Архитектуры сервиса» всех сервисов.

Для облегчения создания и работы над такими документами, как детальная архитектура ИТ сервиса, документ может быть разбит на две части:

•Архитектура сервиса – описывает назначение, сервиса компоненты, требования, стоимость и т п;

•Руководство по внедрению и сопровождению – описывает последовательность развертывания, стандартные операции по сопровождению и т п;

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

Рекомендации по разработке ИТ документации

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

•Какие документы нужны для вашей организации сейчас?

•Насколько детально нужно их прорабатывать?

•Стоимость времени, потраченного на создание документа по отношению к ценности документа?

Генерирование кучу ненужных документов дорого, долго и глупо. Это выгодно, если проект оценивают по толщине отчетных документов. Но толстые документы никто не читает. Их ставят на самую дальнюю полку и забывают навсегда. Поэтому нужно выбрать только те документы, которые нужны, и прорабатывать их настолько детально, насколько это нужно для достижения целей. Логично. Но как определить эту грань? Так как разработка документации и административные работы требуют дополнительных ресурсов, порядок разработки и глубина проработки ИТ документации может быть различной как для различных организаций, так и отдельных процессов в одной организации. Различают ИТ документы по следующим типам:

По степени важности (Устав, планы, бюджет, политики, стандарты, процедуры, прочие документы).

По уровню взаимодействия:

•Взаимодействие ИТ с внешними организациями;

•Взаимодействие ИТ с подразделениями внутри организации;

•Взаимодействие внутри ИТ департамента;

Методы и техники

Можно руководствоваться различными методами внедрения:

•«Классический метод» – разрабатывается документация и процессы собственными силами или с привлечением консультантов и экспертной группы. Внедрение поэтапное основных и второстепенных процессов. В качестве достоинств: наиболее правильный с точки зрения организации. Качественная проработанная цепочка «снизу – вверх» и «сверху-вниз». К недостаткам можно отнести: достаточно затратный как по времени, так и по финансам. Не эффективен в условиях ограниченных ресурсов.

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

•«Техника постепенного улучшения» представляет из себя следующую последовательность действий:

•Выбираете минимальный набор документов;

•Заполняете документ на основе здравого смысла;

•Если что-то кажется лишним, отбрасывайте;