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

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

Процедуры и процессы службы информационных технологий

Содержание процедур службы

Основными элементами содержания процедур оказания услуг являются:
• Порядок подачи запросов на предоставление услуг.
• Порядок удовлетворения запросов.
• Порядок учета затрат и тарифы.

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

Процедура формирования планов

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

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

Процедура формирования ИТ-бюджета

Содержание процедуры включает:
• Формат бюджета службы.
• Порядок составления, согласования и использования бюджета.
• Бюджетную отчетность.
• График формирования бюджета.

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

Управление информационными ресурсами

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

Оценка деятельности службы

Самое трудное — определить состав критериев эффективности. Далее нужен порядок рассмотрения отчетов и форма подведения итогов. Это подразумевает:
• Определение формата отчета.
• Понимание, кто и где его рассматривает (например, на совете директоров).
• Какие выводы и в какой форме последуют: от бонусов до устранения замечаний или радикальной смены организации работы.

Примеры критериев оценки эффективности
Построить систему сбалансированных показателей сложно, но есть очевидные измеримые вещи:
• Выполнение плана и бюджета: Бинарная оценка — пункт плана выполнен или нет; бюджет выполнен, сэкономлен или перерасходован.
• Динамика выполненных услуг (по запросам): Показатель измерим, но его рост неоднозначен. Это может означать как хорошую работу службы, так и наличие хронических проблем, вызывающих поток запросов.
• Динамика совокупной стоимости владения (TCO — Total Cost of Ownership): Объективный, но требующий анализа показатель. Рост TCO может быть следствием инвестиций в развитие или, наоборот, неэффективного управления расходами и активами. Снижение TCO может происходить за счет потери качества.
• Динамика сбоев и рекламаций: Однозначные показатели. Рост — плохо, снижение — хорошо. Рекламация — это ситуация, когда что-то мешает пользователю выполнять функции, и он не получает реакции в оговоренный срок.

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

Основные бизнес-процессы службы

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

Процесс планирования

Процесс начинается со сбора исходных данных: предыдущий план, отчет за период и стратегический план. Далее происходит:
1. Анализ ресурсов: Оценка всего необходимого для выполнения позиций будущего плана.
2. Расстановка приоритетов: Ранжирование пунктов плана (обязательно, рекомендуется, можно отложить), так как ресурсы всегда ограничены.
3. Разработка альтернативных планов и бюджетов.
4. Согласование с подразделениями: Каждое подразделение будет отстаивать свои пункты. Если согласование не достигнуто, происходит возврат к формированию новых вариантов плана.
5. Согласование с финансово-экономическим блоком (ФЭБ): Утверждается бюджет плана. При отказе из-за нехватки средств цикл возвращается к анализу ресурсов.
6. Утверждение плана и бюджета: После визы финансового директора план защищается перед советом директоров или утверждается генеральным директором.

Процесс предоставления услуг

Процесс начинается с инициации услуги:
Вариант 1: Регламентная услуга. Назначается исполнитель и срок, услуга выполняется, факт исполнения обязательно фиксируется в журнале учета.
Вариант 2: Запросная услуга (помощь). Аналогично назначается исполнитель, услуга выполняется и фиксируется.
Вариант 3: Запрос на новую работу. Самая сложная ситуация. Необходим анализ возможности ее выполнения:
• Оценка целесообразности: Не противоречит ли запрос ИТ-стратегии или корпоративной технической политике? Отказ в выполнении должен быть мотивирован.
• Оценка ресурсов: Если работа целесообразна, оцениваются трудоемкость и сроки.
• Согласование условий: С инициатором согласуются сроки, трудоемкость и стоимость на основе внутренних тарифов. Если согласовать условия не удалось, заявитель может снять запрос, поняв его реальную сложность и стоимость. При успехе назначается исполнитель, услуга выполняется и фиксируется.

Процесс управления ИТ-активами

В основе лежит репозитарий ИТ-активов (инфраструктура, лицензии, системы, персонал). Этапы процесса:
1. Мониторинг и анализ состояния активов: Необходим для оценки совокупной стоимости владения (TCO).
2. Оценка влияния активов на стоимость бизнеса: ИТ-активы серьезно влияют на акционерную стоимость компании.
3. Корректировка репозитария: Принятие решений о замене, приобретении или избавлении от активов на основе их влияния на бизнес.
На практике решения об обновлении часто принимаются исходя из планов и стратегии, но сам процесс важен для обоснования.

Примечание об окупаемости инвестиций в ИТ (ROI — Return on Investment)
Единой методологии оценки ROI в ИТ не существует. Однако в конкретных случаях оценку можно сделать. Например, внедрение систем управления цепочками поставок (SCM) дает 20–25% сокращения затрат, а системы управления основными фондами окупаются за девять месяцев за счет исключения дублирующих ремонтов. Важно понимать: формально в ROI не входят аспекты качества обучения пользователей, но они критически влияют на реальный эффект. Внедрение системы может сохранить компанию на рынке, что является невычислимой, но стратегической выгодой.

Процесс взаимодействия с внешними исполнителями

Процесс аналогичен предоставлению услуг, но с привлечением внешних компаний:
1. Инициация проекта: Из портфеля проектов или на основе инициативной заявки.
2. Определение условий и утверждение проекта.
3. Выбор исполнителя: По тендеру или другим критериям.
4. Заключение контракта: Если условия не устраивают, можно пересмотреть их или даже отменить проект.
5. Организация работ: Создание плана взаимодействия, совместных рабочих групп.
6. Выполнение, контроль и приемка результатов.

Процесс отчетности

Процесс зеркален планированию:
1. Сбор исходных данных: План за отчетный период и вся статистика (услуги, рекламации, экономические показатели).
2. Сбор подтверждающих документов: Собираются акты (или другие документы), подтверждающие выполнение каждого пункта плана.
3. Анализ результатов и подготовка отчета.
4. Согласование отчета по бюджету с финансово-экономическим блоком: Обязательный этап для устранения возможных расхождений в учете.
5. Корректировка итоговых документов (при необходимости).
6. Защита и утверждение отчета.

Требования к содержанию процедур

Процедура, в отличие от процесса, четко определяет кто, когда и что должен сделать. Она включает в себя процесс, но наполняет его конкретикой. ITIL (IT Infrastructure Library) прекрасно описывает процессы, но не содержит процедур, так как они уникальны для каждой организации.

Любая процедура должна начинаться с указания адресатов — категорий сотрудников, вовлеченных в ее выполнение.

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

Процедура должна стать настольным руководством, прочитав которое новый сотрудник поймет свои задачи, источники входных данных, сроки и кому передавать результат. Это устраняет системные конфликты.

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

Перед нами стоит задача перехода от теоретической модели управления к практическому инструменту наведения порядка. Ключевая идея, пронизывающая все повествование, — разделение и жесткая увязка двух понятий: «процесс» и «процедура». Процесс — это скелет, абстрактная последовательность действий, которая отвечает на вопрос «что делать?». Процедура — это плоть и кровь на этом скелете, прямое руководство к действию, отвечающее на вопросы «кто?», «когда?» и «в каком виде?». Без процедуры любой, даже самый совершенный, бизнес-процесс остается лишь красивой, но бесполезной схемой.

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

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

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