Всего за 400 руб. Купить полную версию
Для облегчения создания и работы над такими документами, как детальная архитектура ИТ сервиса, документ может быть разбит на две части:
Архитектура сервиса описывает назначение, сервиса компоненты, требования, стоимость и т п;
Руководство по внедрению и сопровождению описывает последовательность развертывания, стандартные операции по сопровождению и т п;
Для небольших организаций, организаций с вялотекущими ИТ процессами, или не значительным влиянием ИТ на бизнес, допускается совмещение политик, процедур и стандартов различных процессов в едином документе.
Рекомендации по разработке ИТ документации
Какие документы нужны для вашей организации сейчас?
Насколько детально нужно их прорабатывать?
Стоимость времени, потраченного на создание документа по отношению к ценности документа?
Генерирование кучу ненужных документов дорого, долго и глупо. Это выгодно, если проект оценивают по толщине отчетных документов. Но толстые документы никто не читает. Их ставят на самую дальнюю полку и забывают навсегда. Поэтому нужно выбрать только те документы, которые нужны, и прорабатывать их настолько детально, насколько это нужно для достижения целей. Логично. Но как определить эту грань? Так как разработка документации и административные работы требуют дополнительных ресурсов, порядок разработки и глубина проработки ИТ документации может быть различной как для различных организаций, так и отдельных процессов в одной организации. Различают ИТ документы по следующим типам:
По степени важности (Устав, планы, бюджет, политики, стандарты, процедуры, прочие документы).
По уровню взаимодействия:
Взаимодействие ИТ с внешними организациями;
Взаимодействие ИТ с подразделениями внутри организации;
Взаимодействие внутри ИТ департамента;
Методы и техники
«Классический метод» разрабатывается документация и процессы собственными силами или с привлечением консультантов и экспертной группы. Внедрение поэтапное основных и второстепенных процессов. В качестве достоинств: наиболее правильный с точки зрения организации. Качественная проработанная цепочка «снизу вверх» и «сверху-вниз». К недостаткам можно отнести: достаточно затратный как по времени, так и по финансам. Не эффективен в условиях ограниченных ресурсов.
«Разработка по требованию» процессы формируются в ходе внедрения и сопровождения ИТ сервисов. Далее происходит их обкатка, и лишь затем
формальное документирование, и принятие. Приоритеты также формируются по необходимости. Как пример, в первую очередь прорабатываются процессы взаимодействия ИТ и внешних организаций: поставщиками продуктов, компанией разработчиков. Следующий шаг: организуются процессы взаимодействия ИТ департамента с другими подразделениями компании. И в последнюю очередь формализуется организация работ внутри самого ИТ департамента. Достоинства метода: эффективен с точки зрения использования ресурсов, простота и понятность в организации простых процессов, целевой, направлен на управление наиболее важными «живыми» процессами в организации, а не формально «важными» с точки зрения управления ИТ сервисами. Недостатки: часто является реактивным методом, т.е. работает по факту происходящих действий, требует дополнительного времени и ресурсов по интеграции процессов между собой.
«Техника постепенного улучшения» представляет из себя следующую последовательность действий:
Выбираете минимальный набор документов;
Заполняете документ на основе здравого смысла;
Если что-то кажется лишним, отбрасывайте;
Оцениваете, сможете ли достичь нужных результатов;
Если нет, то включите недостающие разделы;
Заполните их и снова проведите оценку;
И так далее до достижения результатов.
Выбор метода зависит от индивидуальных особенностей организации и ее культуры. На мой взгляд использование метода «по требованию» с применением техники «постепенного улучшения» является наиболее удачным. Процесс утверждения руководящих ИТ документов в общем случае может выглядеть так:
Для процессов, владельцем которых является ИТ, или которые являются внутренними процессами ИТ, утверждение возможно по решению ИТ директора с последующим формальным утверждением на ИТ комитете.
Разрешение конфликта интересов происходит согласно процедуре в два этапа: инициатор и ИТ директор привлекают департамент внутреннего аудита. Если конфликт не разрешен, то запрос эскалируется на ИТ комитет.
Для процессов, владельцем которых не является ИТ, утверждение возможно только по решению ИТ комитета.
Ряд документов требует разработку их в других департаментах. При этом может соблюдаться следующий алгоритм действий:
ИТ ссылается на документ, разработанный в соответственном функциональном департаменте (документы по кадрам, закупкам и т п).
Если документ отсутствует в функциональном департаменте, то ИТ разрабатывает его самостоятельно по вопросам, связанным с ИТ деятельностью и с учетом вербальных требований функционального департамента.
При разрешении конфликтов в различных документах можно руководствоваться принципами наследования «Сверху вниз» и приоритета «Устав политика процедура инструкция».