Документация службы ИТ (часть 1)

Презентация к лекции

Введение в документацию ИТ-службы

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

Мы выясним:
• Виды и состав обязательной документации.
• Устройство ключевого документа — Положения о службе ИТ (СИТ).
• Бизнес-модель деятельности службы и регламентирующие её процедуры (взаимодействие с руководством, бизнес-средой и подразделениями).
• Критерии и процедуры оценки эффективности службы и её персонала.

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

Виды и состав документации

Итак, какие документы нужны службе:
• Положение о службе. Документ конституционного значения, определяющий её права, обязанности, функции и задачи.
• Процедуры. Мы подробно рассмотрим наиболее критичные из них.
• Организационно-распорядительные документы. На практике здесь часто наблюдается большой разрыв между тем, что должно быть, и тем, что есть.
• Проектная документация. Без неё служба не может существовать. Она составляет от 80% до 90% всего объёма документов, независимо от того, кто разрабатывал систему: внешний подрядчик или собственные сотрудники.
• Методические материалы.

Ключевые процедуры

Процедуры — центральный вопрос. Я перечислю наиболее критичные:
• Предоставление ИТ-услуг конечным пользователям. Важно понимать разницу между содержанием процессов, описанных в библиотеке ITIL, и тем, как мы будем говорить о регламентах их предоставления.
• Формирование плана. Если у службы есть годовой план работы, то нужна и процедура его создания.
• Формирование бюджета. Из плана неизбежно вытекает бюджет на развитие и на сопровождение существующих систем.
• Оценка деятельности. Как итог — процедура оценки выполнения плана и бюджета.
• Проведение тендеров. Эти процедуры, несмотря на внешнюю схожесть, всегда отличаются из-за особенностей корпоративной культуры и правил конкретной компании.
• Управление корпоративными информационными ресурсами. Это касается любого корпоративного контента: интернет-ресурсов, баз знаний, интеллектуального капитала. Часто именно здесь царит неразбериха, что снижает ценность этих ресурсов.

Организационно-распорядительные документы

Здесь можно выделить три группы: приказы о внедрении и приёмке систем, акты приёмки и план-графики работ.

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

Другая крайность — отсутствие акта приёмки системы в эксплуатацию. Этот документ не формальность, он фиксирует, кто теперь отвечает за её нормальное функционирование. И конечно, не может быть нормальной работы без план-графиков. Это иллюстрирует негативный пример внедрения сложного комплекса систем в одном министерстве, где при профессиональном подрядчике отсутствовало плановое взаимодействие, что привело к плачевному итогу.

Проектная документация

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

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

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

Методические материалы

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

Чего почти нигде нет — это методики оценки совокупной стоимости владения (Total Cost of Ownership, TCO). Внутри ИТ-служб существует сопротивление этому по двум причинам. Во-первых, это непростая регулярная деятельность, требующая выделенного специалиста. Во-вторых, аккуратный подсчёт TCO часто показывает реальные затраты на ИТ, которые существенно превышают данные бухгалтерского учёта, что вызывает недовольство руководства. Тем не менее, 100% компаний из списка Fortune 500 уже используют методики TCO, особенно при отданном на аутсорсинг ИТ-обслуживании.

И последнее — проблемы с нормативно-справочной информацией (НСИ). Раньше в стране существовали единые классификаторы, утверждённые Госстандартом. Сейчас же даже внутри одной организации (например, в поликлинике и стационаре одной больницы) могут использоваться разные классификаторы. В авиастроении, где над проектом работают сотни КБ и заводов, несогласованность НСИ приводит к путанице и удлинению сроков. Конструктор заказывает одну деталь, а поставщик, имея другой классификатор, поставляет другую.

Хорошая новость в том, что передовые ИТ-компании создали решения для устранения этих противоречий — своего рода «автоматизированные переводчики» между разными системами классификации, не изменяющие внутренние классификаторы организаций. Но с точки зрения методического обеспечения, в компании должны быть утверждены собственные согласованные классификаторы.

Бизнес-модель: Положение о службе по «максимуму»

Переходим к «конституции» — Положению о службе информационных технологий (СИТ). Я покажу его структуру на примере реального, максимально полного документа для крупной службы. Этот документ имеет юридический характер, визируется юристами и служит инструментом для разрешения споров.

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

Общие положения и полномочия
Интересна ситуация, когда служба является обособленным подразделением первого уровня управления, а ИТ-директор подчиняется напрямую генеральному директору и действует на основании выданной им генеральной доверенности. Это означает, что директор по ИТ имеет право подписывать финансовые и юридические документы (договоры, акты). Это встречается крайне редко.

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

Функции: от техники к управлению
Функции службы охватывают широчайший спектр:
• Техническая политика: Выработка политики компании в части выбора программно-технических средств и поставщиков.
• Информационная безопасность: Участие в обеспечении безопасности и правового режима документированной информации как объекта собственности.
• Консалтинг: Оказание консультационных услуг не только внутри компании, но и вовне — другим организациям. Служба настолько сильна, что выступает игроком на рынке, проводя платные семинары и конференции.
• Разработка ПО: Разработка и внедрение оригинального прикладного ПО силами собственного мощного подразделения.
• Управление документами: Создание и совершенствование общей организационной системы управления документами и данными, интеграция всех информационных потоков и бизнес-процессов.
• Организационное развитие: Инжиниринг и реинжиниринг бизнес-процессов, совершенствование организационной структуры компании.
• Информационно-аналитическое обеспечение: Обеспечение руководства аналитикой.
• Контроль: Установление фактов невыполнения распорядительных документов.

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

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

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

Ответственность — за всё отвечает ИТ-директор.

Именно Положение о службе является последней инстанцией при разрешении споров. Если какая-то задача не значится в перечне функций, ИТ-директор вправе отказаться от её выполнения. Если же новая задача действительно нужна бизнесу, то сначала в «конституцию» вносится поправка. Это и есть нормальная логика работы документа.

Краткие итоги

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

Анализ состава документации демонстрирует системную проблему: наибольший объем занимает проектная документация (80-90%), в то время как управленческие документы (процедуры, положение о службе, методики) либо отсутствуют, либо создаются формально. Это создает критический перекос, при котором служба умеет внедрять системы, но не способна ими управлять, оценивать их реальную стоимость и обеспечивать их соответствие бизнес-целям. Отсутствие программ и методик испытаний, а также технологий эксплуатации приводит к тому, что организация принимает «черный ящик», за работоспособность и развитие которого потом невозможно отвечать системно.

Центральным стабилизирующим элементом в этой модели выступает Положение о службе. На примере документа, близкого к идеальному, показано, как юридически закрепленные полномочия и ответственность могут легитимизировать экспансию ИТ-службы в смежные области, такие как организационное развитие и управление бизнес-процессами. Это делает ИТ-директора не просто «главным по технике», а проактивным менеджером, отвечающим за эффективность компании в целом. Однако такой максимум возможен исключительно при совпадении двух внетекстовых факторов: критичности ИТ для бизнеса и высокого кредита доверия от первого лица.

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