Бизнес процессы отдела информационных технологий

IT бизнес процессы в организации

Опубликовано 24.12.2021

Что такое бизнес-процессы компании

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

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

ITSM — современный стандарт управления ИТ-бизнес-процессами

Эффективность бизнес-процессов организаций сегодня в значительной степени зависит от деятельности ИТ-подразделения. Технологии продолжают совершенствоваться, инфраструктура — расширяться. Поэтому, чтобы обеспечить все потребности бизнеса, IT-механизмы должны работать четко и слаженно, качественно поддерживая все рабочие процессы. Для этого был разработан специальный стандарт — ITSM, Information Technology Service Management или Концепция управления качеством информационных услуг.

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

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

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

Составляющие ITSM

Стандарт управления IT базируется на трех принципах:

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

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

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

Типовая модель

Компания Hewlett-Packard разработала Типовую модель, которой должна соответствовать структура IT-процессов в организации. В этой деятельности HP опиралась на лучший международный опыт, собранный в библиотеке ITIL (IT Infrastructure Library). Добавив к нему свои собственные наработки, компания создала структуру IT-процессов и связей между ними. ITIL показывает, «как надо», а Типовая модель — «как этого достичь».

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

Типовая модель HP подразумевает разделение всех процессов на 5 категорий. Рассмотрим их ниже.

Управление изменениями и конфигурацией

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

Первый, change management, отслеживает все преобразования ИТ-среды и контролирует внесение изменений в IT-систему, согласовывая заявки, расставляя приоритеты, оценивая риски и регулируя восстановление после сбоев. А, так как каждое действие вызывает какие-либо перемены в инфраструктуре, то оно в любом случае взаимодействует с процессом управления изменениями.

Назначение второго, configuration management, состоит в регистрации и контроле сведений об IT-среде, точнее, о каждом из элементов конфигурации (CI, configuration item). Процесс обрабатывает данные об атрибутах CI (оборудование, софт, сотрудники), их статусе (в действии, ремонте) и связях между ними. К процессу управления конфигурацией также обращаются все составляющие Типовой модели.

Стратегические бизнес-процессы

Благодаря этим стратегическим разработкам айтишники функционируют как представители бизнеса, а не обслуживающий персонал. Одни процессы позволяют проанализировать рынок IT-услуг и определить требования к ИТ-подразделению (business assessment). Другие (customer management) — управлять пользователями, т. е. предвидеть их запросы, продавать IT-услуги, оценивать уровень удовлетворенности заказчика. Эти два процесса взаимосвязаны. Данные о пользователях используют при изучении рынка и конкурентной обстановки, а все вместе — для разработки IT-стратегии (IT strategy development). В ходе последнего процесса перед ИТ-отделом ставят конкретные цели и задачи (а также пути их достижения и решения), определяют бюджет, выбирают технологии и архитектуру IT-среды и выполняют другие стратегические действия.

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

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

• Планирование услуг (service planning). Это формирование и контролирование перечня стандартных услуг, который при необходимости меняется в соответствии со спецификой бизнес-подразделений, а также анализ возможных убытков.
• Управление уровнем услуг (service level management). Конкретные параметры и оценка стоимости стандартной услуги позволяют определить уровень обслуживания, достаточный для удовлетворения потребностей клиента. На основе результатов, полученных по окончании этих двух процессов, заказчик и исполнитель заключают соглашение SLA.
• Управление безопасностью (security management). В ходе этого процесса определяют защитную политику и доводят ее до каждого сотрудника организации, обеспечивая информационную безопасность.
• Обеспечение готовности услуг (availability management). Это контролирование того, на сколько услуга подготовлена для передачи заказчику в соответствии с выставленными им параметрами. Здесь в зависимости от требований клиента конечный результат может измениться по сравнению с тем, что был определен на стадии планирования.
• Управление ресурсами (capacity management). Контролирует рабочую нагрузку оборудования в соответствии со SLA. Данные, полученные в результате этого процесса, помогают спланировать услуги и управлять их уровнем.
• Снижение расходов (cost management). Процесс вычисляет настоящую стоимость IT-услуги, устанавливает ее бюджет, анализирует использование и служит ориентиром для совершенствования обслуживания. 

Разработка, совершенствование и внедрение услуг

В ходе этих процессов разрабатывают новые и совершенствуют действующие услуги, а также тестируют их и интегрируют в ИТ-систему. После успешных испытаний компонент полностью внедряется в информационную среду. В соответствии с задачами процессы делятся на 2 стадии. Build&test реализует и тестирует услугу, проверяя ее на согласованность с конкретными стандартами. Release to production, в свою очередь, выпускает продуктивную версию на основе результатов первого этапа и вводит ее в действие.

Поддержка инфраструктуры

Эти процессы поддерживают инфраструктуру, решают проблемы, следят за удовлетворенностью заказчиков. Управление операциями (operations management) мониторит состояние ИТ-ресурсов, координирует очередь печати и резервирование, администрирует IT-структуру. Служба технической поддержки (Help Desk) или управление инцидентами (incident management) быстро и качественно обрабатывает заявки и восстанавливает готовность услуги при возникновении сбоев. Управление же проблемами (problem management) выступает в виде профилактических мер, предотвращая инциденты на основе информации, полученной в результате предыдущего процесса.

Реализация ITSM

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

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

Примеры бесконечны, каждая организация может привести свой собственный опыт применения Типовой модели.

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

Заключение

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

Библиографическое описание:

Ташлыкова, Е. В. Оптимизация бизнес-процессов IT-отдела на примере ЗАО «Пермская целлюлозно-бумажная компания» / Е. В. Ташлыкова, Р. Н. Петухов. — Текст : непосредственный // Молодой ученый. — 2015. — № 16 (96). — С. 313-316. — URL: https://moluch.ru/archive/96/21619/ (дата обращения: 24.03.2023).

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

Ключевые слова: оптимизация бизнес-процессов, процессное управление, ключевые показатели эффективности.

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

На большинстве предприятий проводятся мероприятия по оптимизации, повышению эффективности и качества её бизнес-процессов. Эти мероприятия позволяют снизить риск возникновения сбоев в работе предприятия.

Существует множество методов оптимизации бизнес-процессов, каждый метод может быть направлен на повышение определенных параметров процесса: производительность, эффективность, адаптивность, качество процессов [1].

В качестве методов оптимизации бизнес-процессов используются:

1.    Анализ сильных и слабых сторон (SWOT-анализ).

2.    Бенчмаркинг.

3.    Анализ и оптимизация бизнес-процессов на основе показателей KPI.

4.    Метод Lean, «6 Сигма.

5.    Изменение фрагментарности бизнес-процессов.

6.    Анализ бизнес-логики процессов.

7.    Функционально-стоимостной анализ.

8.    Анализ трудоемкости и длительности бизнес-процессов.

9.    Концепция процессного управления.

Процессный подход применяется с целью создания горизонтальных связей в организации, позволяет более оперативно решать возникающие вопросы и воздействовать на результат. Процессный подход подразумевает несколько принципов [2]:

—          принцип взаимосвязи процессов (организация представляет собой сеть процессов);

—          принцип востребованности процесса (каждый процесс должен иметь цель, а его результаты востребованы);

—          принцип контроля процесса (для каждого процесса должны быть определены показатели характеризующие процесс и его результаты);

—          принцип ответственности за процесс (за процесс должен отвечать один человек).

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

Процессный подход позволяет:

—          понимать процессы, повышать их качество и качество используемых ресурсов;

—          улучшать координацию работ между сотрудниками, сократить дублирование действий;

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

—          измерять результаты процессов через KPI и стимулировать их улучшение;

—          создать эффективную систему мотивации сотрудников.

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

Рис. 1. Схема взаимодействия двух процессов

Взаимодействие между процессами происходит следующим образом. Процесс № 2, который является потребителем результата Процесса № 1, формирует требования, которым должен соответствовать результат Процесса № 1. Участник Процесса № 1, выполнив функции, входящие в процесс, проверяет соответствие результата требованиям, в случае если результат не удовлетворяет требованиям, производится его доработка. Точка контроля должна содержать в себе измеряемые показатели производительности, стоимости, времени выполнения и т. д.

Бизнес-процессы IT-отдела ЗАО «ПЦБК» можно условно поделить на четыре группы:

—          бизнес-процессы, направленные на поддержание работоспособности информационных систем предприятия;

—          процессы, обеспечивающие работоспособность электронно-вычислительного оборудования;

—          процессы, направленные на обеспечение работоспособности программного обеспечения;

—          процессы информационной поддержки пользователей предприятия.

Процессы начинаются с четырех событий (рис.2): поступившей заявки или звонка пользователя, распоряжения руководства и необходимости обслуживания ИС. Далее менеджер производит оформление заявок, в случае если это звонок от пользователя, менеджер самостоятельно вводит заявку в систему заявок, таким образом, менеджер становится ответственным лицом за принятие и оформление заявок. После принятия заявки менеджер должен определить исполнителя, в зависимости от работ, указанных в заявке, и компетенций того или иного исполнителя. Вся работа с заявками производится в системе заявок IntraService и в системе электронного документооборота (СЭД).

Рис. 2. Начальные события усовершенствованных процессов

Если заявка включает работы прикладного характера, то он направляется к аналитику, который в свою очередь формирует техническое задание для программиста (рис.3).

Рис. 3. Процесс формирования задания для программиста

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

Измерение и анализ показателей процесса являются важнейшими средствами, позволяющими находить пути улучшения процессов. Процесс могут охарактеризовать три группы показателей [3]:

показатели процесса;

показатели продукта процесса

показатели удовлетворенности клиентов процесса.

На рисунке 4 представлена схема взаимодействия процесса оформления заявки и процесса определения исполнителя. Для того чтобы правильно определить исполнителя, необходимо чтобы заявка соответствовала требованиям оформления заявок, определенным участником процесса «определение исполнителя». Таким образом, исполнитель процесса «оформление заявки» проверяет соответствие заявки данным требованиям.

Для измерения процесса оформления заявки определены Показатели 1:

—          количество оформленных заявок;

—          время оформления заявок;

—          количество неверно оформленных заявок.

Для оценки процесса определения исполнителя сформированы Показатели 3:

—          количество верно определенных исполнителей;

—          количество не принятых исполнителями заявок.

Рис. 4. Схема взаимодействия процессов «оформление заявки», «определение исполнителя» и «принятие заявки»

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

Литература:

1.         Репин В. В. Бизнес-процесс компании: построение, анализ, регламентация. — М.: Стандарты и качество, 2007. — 240 с.

2.         Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М.: Манн, Иванов и Фербер, 2013. — 544 с.

3.         Клочков А. KPI и мотивация персонала. Полный сборник практических инструментов. — М.:Эксмо, 2009. — 160 с.

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

Привет! Меня зовут Валера, у меня много разного бизнеса, но сегодня хочу поделиться картой внутреннего бизнес-процесса для нашего отдела продаж в IT-компании «Студия Т».

Если не хочется читать описание всего flow продаж, то можно просто скачать карту целиком в моём tg-канале и разобраться самостоятельно.

Для остальных — давайте разберёмся подробно.

В «Студии Т» мы занимаемся, в основном, заказной разработкой — сайты, сервисы, мобильные приложения. Есть еще отдел рекламы и ведения соцсетей, но это отдельный юнит внутри компании и они работают по другим регламентам и процессам.

Отдел продаж

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

Поэтому отдел состоит из следующих ребят:
— Руководитель отдела продаж
— Два менеджера продаж, которые обрабатывают все входящие заявки
— Два аккаунт менеджера, которые работают с клиентом уже после подписания договора, смотрят, что можно улучшить/докрутить и, соответственно, делают допродажи и кросспродажи

Сегодня говорим про workflow менеджеров продаж.

Входящий запрос

Лиды к нам приходят по 4 основным каналам:
— Телефон
— Соцсети
— Почта
— Сайт

В течении 15-ти минут менеджер должен создать карточку в CRM (если она почему-то не создалась автоматически) и взять заявку в работу.

Если нам позвонили, то переходим сразу к фазе «Первичный отсев». Если другой канал связи, то первая задача — выяснить телефон, часовой пояс и удобное время для звонка.

Срок: 30 минут от получения

Цель №1: Принять решение, может/хочет ли агентство взять проект в работу и перейти к согласованию встречи.

Цель №2: Добиться прогресса. Если это не встреча, то договорится о общении в tg или ватсапе по всем остальным вопросам. В процессе диалога мы не боимся прямых вопросов, а любим их.

После того, как получили номер, мы проводим первичный брифинг и «Фазу отсева».

Построение диалога: Знакомство — О клиенте и бизнесе — Выявление болей, проблем и задач — Как мы можем помочь, опыт по этим проблемам. Извлекающие вопросы!

Скоринг

Проведя первый созвон и первичный брифинг, менеджер делает скоринг клиента.

Это внутренний процесс, где есть прям «Фаза отсева» с жёсткими критериями непопадания, а после отсева мы оцениваем клиентам по 3 основным блокам, по 5 параметрам в каждом.

3 блока — запрос, соответствие, коммуникация.

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

Каждый параметр оцениваем -1, 0, 1. И выставляем итоговый балл.

Дальнейший путь, исходя из оценки

Исходя из балла — делим на сегменты:

Начальный (С)

Чаще всего это небольшие ребята, которые не прошли по бюджету, срокам и/или технологиям.

Тут всё автоматизировано, довольно шаблонно и такие процессы отрабатывают стажёры/новые менеджеры или просто менее опытные ребята, чтобы «набить руку» и научиться отказывать.

Сегменту С мы отправляем письмо отказа, объясняя почему «нет» и предлагаем работу с партнёрами Студии.

У нас есть своя партнёрская программа, где мы подбираем хорошие, проверенные агентства, работающие в других ценовых сегментах и/или с другими технологиями.

Средний (B)

Эти заказчики «Золотой фонд».

Они должны получать стабильное качество и заботу.

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

Со средним сегментом мы договариваемся о следующей встрече. Онлайн или офлайн, если есть возможность.

Отрабатываем его по всем стандартным процессам компании.

Вип (А)

Самые «жирные» клиенты.

Тут мы чаще всего общаемся не с ЛПР, поэтому основная задача — научить лида продавать нас ЛПРу.

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

Подготовка к интервью

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

Создаём рабочую группу проекта.

Чаще всего это:

— менеджер продаж

— аналитик

— маркетолог

— тимлид для предварительной оценки, если что-то сложное и нестандартное

Рабочая группа собирает аналитику по конкурентам, смотрит метрики, проблемные места бизнеса и текущее состояние всех digital-каналов.

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

Если вы не понимаете, что такое проблемные и извлекающие вопросы, то нужно прочитать книжку «СПИН-продажи. Практическое руководство», автор Нил Рекхэм.

Сюда же собираем релевантный опыт, как мы уже решали похожие кейсы. По проблемам/сфере/отрасли.

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

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

Собираем всё это в презентацию, репетируем. Особенно репетируем возможные возражения.

Глубинное интервью

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

Понимаем, как наш продукт/услуга помогает бизнесу клиента. Если мы не можем чётко сформулировать пользу, которую клиент получит от нашего продукта, то не сможем убедить его, что продукт стоит своих денег. Когда заказчик знает об измеримой пользе — увеличение конверсий, прибыли и других KPI, — он понимает, что готов платить за результат.

Проводим презентацию и договариваемся о дате, когда мы подготовим коммерческое предложение и возможности его презентации.

Подготовка коммерческого предложения

При оценке по скорингу >9 подключаем РОПа к подготовке КП.

Если лид не готов на презентацию КП, то отправляем по почте без презентации и закидываем карточку в «Дожим».

Презентация коммерческого предложения

Цель №1: Рассказать всё лично, презентовать Студию в лучшем свете, лишний раз поболтать с командой.

Цель №2: Сразу ответить на все вопросы, собрать фидбэк.

Цель №3: Договориться о «прогрессе», выявить новые потребности.

Проверяем всё оборудование, созваниваемся по правилу «нас на одного человека меньше, чем с другой стороны».

Договариваемся о дате принятия решения, задаём «неудобные» вопросы про конкурентов, критерии выбора подрядчика и т.д.

Пингуем и если через 3 дня после презентации решение не принято, то переводим лида в «Дожим».

Дожим

Срок: Через 2 рабочих дня от презентации или отправки материалов

Цель: Помочь заказчику совершить сделку, отработать возражения, найти причины в принятии решения, выйти на нового/настоящего ЛПР

На этапе «дожима» мы пытаемся понять чего не хватает для принятия решения. Чаще всего это:
— Просьба выслать учредительные документы, проверка подрядчика
— Шаблон договора
— Есть какие-то вопросы по КП
— Нужна еще встреча (возможно с кем-то другим)
— Хотят тестовое задание

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

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

Разберём их чуть подробнее:

Запуск проекта отложен

Пытаемся выяснить причины и сроки, почему запуск отложили и пробуем понять, можем ли мы как-то помочь, повлиять.

Возможно, стоит предложить выделить MVP или предложить начать с каких-то небольших шагов — техническое задание, архитектура, аналитика, custdev.

Ждут чьего-то решения

Выясняем кто тот человек, чьё решение мы ждём.

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

У заказчика нет времени на изучение

Если презентации не было и просто отправляли КП, то договариваемся о встрече и презентуем.

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

Выбрали других

Здесь нужно провести «дебрифинг» клиента, чтобы выявить слабые стороны нашего КП и агентства, понять реальные причины фэйла.

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

Зачем? Потому что 90% проектов в IT не укладываются в срок и возможно как раз сейчас клиент устал от обещаний и готов сменить подрядчика.

Не могут выбрать, ждут еще другие КП

Нужно выявить слабые стороны нашего КП и агентства, понять реальные причины фэйла и что мы можем сделать.

Задаём неудобные и прямые вопросы в стиле «что сделать, чтобы выбрали нас?»

Итого

Важное, что хотелось бы проговорить еще разок в разрезе продаж, подытожив.

Если материал вам понравился — подпишитесь на канал.

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

Искренне надеюсь это поможет и/или улучшит ваши продажи в компании!

Статья предназначена для практикующих бизнес-аналитиков и консультантов в области проектирования бизнес-процессов.

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

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

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

Схема 1.

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

Схема 2.

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

Итак, опишем подробнее показанные подходы.

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

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

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

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

Используя этот подход, мы видим и описываем процессы сверху. Стоит отметить, что данный подход в полной мере соответствует методологии процессного подхода в управлении.

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

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

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

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

Если Директор ИТ будет иметь у себя оба описания, это будет очень полезно.

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

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

Автор: О.Бурносова

Оценка и измерение ИТ-процессов

Деятельность ИТ служб, при их хорошей организации – это система процессов. Часть процессов, направленных на управление ИТ сервисами, называется ITSM (IT Service Management). Процессы управления ИТ дают возможность эффективно использовать информационные технологии, чтобы удовлетворять потребности заказчиков. Об эффективности и результативности свидетельствует, если:

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

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

Критерии оценки эффективности реализации ИТ-процессов

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

ИТ-процессы в действии

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

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

Также это наличие системы различных иерархических должностных связей, которые позволяют определить обязательства, ответственность сотрудников за реализацию конкретных процессов, поставленных задач. Продуктивность процесса (Productivity) означает, что он может хорошо функционировать лишь с минимальной поддержкой извне.

Методы контроля и оценки ИТ-процессов

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

ИТ-процессы: цели и задачи

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

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

Карта бизнес процессов – аутсорсинг обслуживания ИТ

Такая карта составляется для компании, которая выполняет обслуживание ИТ системы на основании аутсорсинга. Например, карта основных бизнес процессов компании HelpIT.me может быть представлена кратким описанием основных процессов.

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

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

Следующим процессом можно выделить мониторинг ИТ систем клиента – Управление событиями. Этот процесс заключается в том, что будет происходить регулярный мониторинг ИТ систем, с выявлением важных и/или критичных событий. Он может проводиться в полном объеме или только в виде проверок отдельных частей ИТ систем. Мониторингом можно считать даже тот случай, когда специалисты аутсорсинговой компании звонят заказчику и спрашивают, все ли в порядке в его организации. В этом случае это будет мониторинг удовлетворенности пользователей. Хотя эту деятельность стоит больше отнести к процессу Управлением уровнем сервиса.

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

HelpIT.me от большинства компаний отличается тем, что здесь не проводятся активные продажи в прямом смысле этого слова. Новые клиенты обращаются на основании рекомендаций текущих клиентов, партнеров компании. Такая особенность накладывает определенные обязательства на все виды процессов организации, а при хорошо отлаженных процессах и при их постоянном улучшении удовлетворяются основные потребности клиентов, повышая уровень репутации на рынке.

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

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

Управление ресурсами – это еще один процесс, благодаря которому распределяются и контролируются ресурсы компании в соответствии с процессами. Также этот процесс позволяет обеспечить ресурсы внутренних процессов компании.

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

Управление продуктами – еще один процесс, благодаря которому анализируются, разрабатываются, внедряются и реализуются новые продукты компании.

Стратегическое планирование, развитие – процесс, направленный на развитие стратегии компании. Также он отвечает за эффективность работы компании и ее успех.

Процесс управления финансами – этот процесс предназначен для управления финансовыми потоками. 

О двух подходах к описанию бизнес-процессов ИТ-подразделений

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

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

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

Оптимизация бизнес-процессов IT-отдела

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

Результативность ИТ-процессов (effectiveness)

Результативность дает возможность показать, как данный процесс соответствует назначению и поставленным целям. Чтобы разработать метрики и контроли, позволяющие измерить результативность, нужно различать то, что представляет собой назначение и цели. Назначение позволяет определить роль процесса в общей системе управления. Назначение является универсальным, так как в различных компаниях практически не меняется. Формулировки назначений представлены в различных сводах и стандартах, которые предлагают процессные подходы. А цель позволяет определить то, что обеспечивает процесс за определенный период времени. Цели обязательно верифицируются, пересматриваются и меняются.

Верификация целей проходит по специализированной методике. Примером такой методики может быть система SMART.

Степень соответствия ИТ-процессов требованиям (compliance)

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

Автор: Александр Михайлов, MBA по стратегическому управлению,editor@info-strategy.ru,Генеральный директор компании «Консалтинг по управлению ИТ».
Текст написан на базе главы книги «ИТ-стратегия: лучшие международные и российские практики». 

скачать pdf файл статьи

Материал статьи построен на базе лучшего международного опыта разработки ИТ-стратегий и практического опыта автора:

15 лет консалтинга по управлению ИТ (из них 7 лет в IBM); 10 лет работы руководителем ИТ службы в российских и зарубежных компаниях; 11 лет преподавания ИТ-стратегий в ведущих российских бизнес школах; разработка ИТ-стратегий десятков крупных российских предприятий, помощь в разработке более трех сотен ИТ-стратегий.

Оглавление:

1. ИТ-процессы: что надо рассмотреть для планирования на 1 год и более 
2. Методологии проектирования и контроля ИТ-процессов: ITIL, COBIT, PRM IT, MOF
     2.1. История развития методологий по ИТ-процессам
     2.2. ITIL
     2.3. COBIT
     2.4. PRM IT (методология IBM)
     2.5. MOF (методология Microsoft)
     2.6. Сравнение процессных методологий
3. Анализ и проектирование ИТ-процессов на 1 год и более
4. Анализ текущего состояния и планирование улучшений ИТ-процессов в рамках разработки ИТ-стратегии или стратегии цифровой трансформации бизнеса
5. Типовые варианты планирования ИТ-процессов на 1 год и более

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

1. ИТ-процессы: что надо рассмотреть для планирования на 1 год и более

Вот составляющие ИТ-процессов, обычно рассматриваемые при планировании на 1 год и более:

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

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

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

---

2. Методологии проектирования и контроля ИТ-процессов

2.1. История развития методологий по ИТ-процессам

Методологий для анализа и проектирования ИТ-процессов достаточно много, на Рис. 1 представлены только основные из них: Рис. 1. История развития методологий по ИТ-процессам

Первые методологии по ИТ-процессам разработала компания IBM. Не все знают, что IBM не поддерживала ITIL v1 и v2, но в разработке третьей версии ITIL участвовали как специалисты IBM, так и HP, и Microsoft (можно проверить, посмотрев список авторов книг по ITIL v3).

Я изучал все рассмотренные на рисунке методологии, кроме ISMA, эта методология уже лет двадцать как устарела. На мой взгляд, методология PRM IT разработки IBM сейчас лучшая. Как для проектирования ИТ-процессов, так и для разработки ИТ-стратегий. Проблема в том, что эта методология отсутствует в открытом доступе. Кроме того, ITIL v3 стал уже стандартом де-факто в России, да и во многих других странах.

Рассмотрим процессные методологии более подробно.

2.2. Методология ITIL

Третья версия методологии Information Technology Infrastructure Library (ITIL v3) сейчас является стандартом де-факто как в России, так и во многих других странах мира. По ITIL есть как доступная литература, так и обучение, и консалтинг.

Методология создана по инициативе правительства Великобритании в 1989 году (во времена Маргарет Тэтчер). Толчком для ее создания послужила приватизация и оптимизация госслужб. На этой волне была предпринята попытка оптимизации госучреждений и осуществлено их сравнение с компаниями, успешно работающими в рыночных условиях. 20 лет назад это был достаточно революционный подход.

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

Основная идея методологии ITIL: ИТ-служба оказывает пользователям ИТ информационные услуги. Услуги оказываются в соответствии с согласованными требованиями к их количеству и объему. А пользователи оплачивают услуги, которыми они воспользовались.

Для начала 90-х годов эта идея была достаточно нова. Для российского бизнеса идея оказания услуг как внешним заказчикам, так и другим подразделениям подразделениями компании, нова и сейчас. Попробуйте в вашей бухгалтерии и отделе кадров проверить качество и своевременность их услуг. Или про SLA их спросите.

Недавно появилась и новая область использования в методологии ITIL — для бизнеса, например, для оптимизации работ строительных бригад РЖД по ремонту железных дорог. Планирование этих работ было оптимизировано с использованием ITIL.

На Рис. 4 представлен перечень процессов ITIL v3, с разбивкой по фазам жизненного цикла: Рис. 4. Процессы ITIL v3

ITIL: использование в ИТ-стратегии

Применимость ITIL при разработке ИТ-стратегий я оценил бы следующим образом:

• ITIL в России, да и в других странах, используется очень часто, особенно при проектировании ИТ-процессов. Однако полнота покрытия выделенными в ITIL ИТ-процессами реальных работ по ИТ не особенно велика. Процессы поддержки ИТ рассмотрены подробно, но вот с развитием ИТ плоховато. Например, процесс по разработке и поддержке ИТ-стратегии в ITIL просто отсутствует. А группы процессов в ITIL выделены, на мой взгляд, неполно.
• Соответственно, если у вас при автоматизации Help Desk использована методология ITIL (а это встречается очень часто), то вроде бы и в ИТ-стратегии использовать ITIL целесообразно, чтобы спланировать развитие ИТ-процессов на год-два. Однако, если рассмотреть в ИТ-стратегии все процессы ITIL, то времени это займет много, да и в глазах будет рябить. То есть в стратегиях, которые вы сами хотите разработать за месяц другой, все процессы рассматривать вряд ли имеет смысл. А группы процессов в ITIL не покрывают весь спектр работ по ИТ, то есть только группы ИТ-процессов рассматривать тоже смысла нет;
• Есть разные шкалы в ITIL, используемые для оценки уровней зрелости ИТ-процессов, , в т.ч. совсем подробные или не совсем корректные. Например, по некоторым рекомендуемым на сайтах по ITIL опросникам выходит, что если у вас нет видения и миссии конкретного ИТ-процесса, то и уровень зрелости этого процесса будет ниже плинтуса. Собственно, я бы не рекомендовал при разработке ИТ-стратегии использовать рекомендации ITIL для оценок уровней зрелости ИТ-процессов.

2.3. Методология COBIT

Методология Control Objectives for Information and Relates Technology (COBIT) была разработана для контроля ИТ-процессов. Международные финансовые корпорации строили на базе COBIT системы контроля работ по ИТ. Хотя эти финансовые корпорации обанкротились во время кризиса 2007 года из-за того, что неправильно вели бизнес, а также плохо контролировали действия своих брокеров, вряд ли причиной этого была методология COBIT.

Сейчас COBIT развивает Ассоциация Аудита и Контроля Информационных Систем (ISACA). В COBIT (версия 5) выделены процессы как поддержки, так и планирования развития ИТ (см. Рис. 2): Рис. 2. Типовые процессы ИТ в COBIT

В COBIT есть множество показателей по каждому из ИТ-процессов:

• Модель зрелости (Maturity model);
• Критические факторы успеха (KSF);
• Показатели достижения результата (KGI);
• Показатели исполнения (KPI).

COBIT: модель зрелости процессов ИТ

Для оценки текущих и требуемых через 1-2 года уровней зрелости ИТ-процессов я рекомендовал бы использовать модель зрелости на базе COBIT v4 (см. Табл. 1):

Табл. 1. Шкала оценки уровней зрелости ИТ-процессов

Уровень зрелости	Описание
0	Не существует (Non-Existent)	Полное отсутствие каких-либо процессов. Организация не понимает, о чем идет речь.
1	Начальный (Initial)	Организация понимает, о чем идет речь, и что это необходимо. Не существует стандартизованного процесса. Присутствуют определенные подходы, применяемые от случая к случаю. Управление не организовано.
2	Повторяемый (Repeatable)	Процессы разработаны до степени, когда люди, выполняющие одну задачу, используют похожие процедуры. Ответственность не прописана, отсутствует обучение. Высокая степень зависимости от знаний конкретных людей.
3	Определенный (Defined)	Процессы стандартизованы и документированы, проводится обучение. Отклонения маловероятны, хотя их соблюдение оставлено на усмотрение персонала. Процессы являются формализацией существующей практики и не оптимизированы.
4	Управляемый (Managed)	Возможность контролировать и измерять выполнение процессов и применять меры там, где процессы не эффективны. Процессы постоянно улучшаются и могут быть автоматизированы.
5	Оптимизованный (Optimized)	Процессы доведены до соответствия лучшим практикам и основаны на результатах сравнения с другими организациями. Обеспечивается быстрая адаптация к изменяющимся условиям. Процессы автоматизированы и согласованы с другими процессами.

Данная шкала удобна своей простотой и тем, что похожа на оценки в российской школе. Шкала достаточно согласована [при оценке уровня зрелости в шкале COBIT версии 4 не было консалтинговых подколок, типа «если у вас нет миссии ведения процесса», то уровень зрелости уже будет не более троечки. Однако, в версии 5 все поменялось, уровень зрелости ИТ-процессов очень многих российских организаций может быть оценен как чрезвычайно низкий].

В рамках методологии COBIT также говорится, что уровень зрелости ИТ-процессов вашей организации надо бы сравнить с другими уровнями (см. Рис. 3). Рис. 3. Модель зрелости процессов ИТ

Эти рекомендации совершенно правильные, но сейчас в России непросто найти с чем же можно сравнить свои ИТ-процессы.

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

COBIT: использование в ИТ-стратегии

Вот мои оценки применимости COBIT при разработки ИТ-стратегий:

1. В России COBIT используется весьма редко, особенно для проектирования ИТ-процессов. Полнота покрытия выделенными в COBIT процессами, всех работ по ИТ не выше, чем в ITIL. Однако, ITIL более распространен в России, соответственно саму модель процессов COBIT в ИТ-стратегии, полагаю, использовать нет смысла;
2. Шкала оценок уровней зрелости ИТ-процессов в COBIT удобна для использования в ИТ-стратегиях [на мой взгляд, в COBIT v4 шкала понятнее, чем в v5. А также существенно меньше и «разводит» на заказы консалтинга по увеличению уровней зрелости ИТ-процессов в случаях, когда у вас всего-то не написаны «видение» и «миссия» процесса]. Важным достоинством шкалы оценки зрелости ИТ-процессов является ее простота, понятность, а также интуитивное соответствие российской школьной шкале оценок. Соответственно, я бы рекомендовал в ИТ-стратегии, при оценках текущего и требуемых уровней зрелости ИТ-процессов, использовать шкалу COBIT.

2.4. Методология PRM IT

Методология Process Reference Model for IT (PRM IT) является весьма полной и внутренне согласованной методологией компании IBM. Перечень процессов PRM IT приведен на Рис. 5: Рис. 5. Процессы PRM IT

Работая в IBM, я разработал ряд ИТ-стратегий, где была использована методология PRM IT. На мой взгляд, методология PRM IT удобней и лучше как для разработки ИТ-стратегий, так и для проектирования ИТ-процессов — она самая полная. В методологии есть ряд процессов, и она существенно больше покрывает работы по ИТ, чем ITIL и COBIT. Однако это перечеркивается тем, что компания IBM не предоставляет эту методологию в открытом доступе.

PRM IT: использование в ИТ-стратегии

Применимость PRM IT при разработке ИТ-стратегий я бы оценил так:

• Модель PRM IT очень полная: 30 лет на разработку и отсутствие совместимости с предшествующими методологиями все-таки позволили разработать полную и понятную процессную методологию. Но, учитывая, что IBM не распространяет описание процессов PRM IT, на мой взгляд, в ИТ-стратегии стоит планировать только группы процессов PRM IT.
• Шкалы оценок уровней зрелости ИТ-процессов в PRM IT широкой публике скорее не известны, и COBIT скорее проигрывают.

2.5. Методология MOF

В 1999 году корпорация Microsoft начала собственные разработки по адаптации ITIL к особенностям эксплуатации информационных систем на базе собственных технологий. В результате на свет появились рекомендации, изложенные в библиотеке документов Microsoft Operations Framework (MOF).

Если у вас все построено на Microsoft, и вы уже внедрили MOF, то ИТ-процессы можно планировать и на базе методологии MOF.

Модель процессов MOF включает в себя 21 функцию управления услугами, сгруппированную по четырем квадрантам:

• Поддержка (supporting);
• Эксплуатация (operating);
• Изменения (changing);
• Оптимизация (optimizing).

Рис. 6. Методология MOF

На мой взгляд, сейчас в России проектирование процессов на 90% проводится на базе ITIL, а MOF почти не используется.

MOF: использование в ИТ-стратегии

Полнота покрытия ИТ-процессами MOF всех работ по ИТ невелика. Соответственно, и в ИТ-стратегиях MOF имеет смысл использовать, только если ваша организация уже давно и существенно использует MOF, а не ITIL или COBIT.

2.6. Сравнение процессных методологий

• MOF ориентирована на поддержку продуктов Microsoft, вряд ли целесообразно использовать эту методологию для разработки ИТ-стратегии;
• COBIT скорее ориентирован на контроль, а не на планирование развития ИТ-процессов. В России COBIT распространен существенно меньше, чем ITIL. Соответственно, вряд стоит использовать COBIT для разработки ИТ-стратегий;
• ITIL сейчас де-факто является стандартом ИТ-процессов. Соответственно, и в ИТ-стратегиях появляется желание использовать ITIL. Однако, при этом надо каким-то образом выделить рассматриваемые в ИТ-стратегии процессы (или их группы), запланировать развитие всех 20-30 процессов будет сложно;
• PRM IT, на мой взгляд, лучше других подходит для долгосрочного планирования ИТ в рамках ИТ-стратегий. Однако, в отличие от ITIL, PRM IT используется только внутри IBM и для клиентов этой компании.

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

• шкалу для оценки уровней зрелости ИТ-процессов – из COBIT v4;
• группы ИТ-процессов, требования к уровням зрелости которых вы будете согласовывать с бизнес-руководством вашего предприятия – из PRM IT;
• перечень ИТ-процессов, если вы собираетесь все их спланировать, лучше взять из ITIL v3. Однако, если вы и ИТ-стратегию и планирование ИТ-процессов делаете в первый раз, то я не рекомендовал бы пробовать рассматривать сразу все ИТ-процессы, так как на обе работы вас не хватит.

---

3. Анализ и проектирование ИТ-процессов на 1 год и более

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

Весьма распространенная форма оценки имеющегося и требуемого уровней зрелости ИТ-процессов (по ITIL) приведена на Рис. 8: Рис. 8. Оценки текущего и требуемого через 1-2 года уровней зрелости ИТ-процессов (по ITIL)

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

Вот еще пример графика оценки зрелости процессов (это по COBIT), сколь красиво, столь и непонятно, откуда появились все оценки, кроме текущего состояния (см. Рис. 9, кодами обозначены названия процессов COBIT, соответствие между кодами и названиями процессов приведено на Рис. 2):

  Рис. 9. Оценка текущего и требуемых уровней зрелости ИТ-процессов (по COBIT)

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

На мой взгляд, в ИТ-стратегии надо планировать требуемые через 1-2 года уровни зрелости ИТ-процессов, исходя, в первую очередь, из требований бизнеса.

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

• Высокая важность для бизнеса: предполагается, что этот процесс более других важен для бизнеса, например, процессы, связанные с непрерывностью (бесперебойностью) работы ИТ;
• Средняя важность для бизнеса: таких процессов большинство. Предполагается, что они должны быть не хуже, чем у ваших конкурентов и партнеров. К этой группе часто относят процессы, связанные с управлением ИТ (если вы не ИТ-компания);
• Низкая важность для бизнеса: желательно, чтобы примерно треть процессов представители бизнеса отнесли к этой категории. Например, это может быть процесс “Анализ ROI по ИТ-проектам” (если вы этим вообще не занимаетесь).

Вот мои предложения по конкретным работам детализации групп работ по ИТ и входящим в эти группы ИТ-процессам [ИТ-процессы взяты из методологии PRM IT, в методологии ITIL ряда процессов не хватает, особенно относящихся к управлению ИТ-службой и планированию ИТ] (см. Табл. 2):

Табл. 2. Группы основных ИТ-процессов, целесообразных для рассмотрения в ИТ-стратегии

Направления работ по ИТ	Поднаправления работ по ИТ (группы ИТ-процессов)	Основные выполняемые работы
Управление и развитие ИТ	Управление ИТ-службой	Управление финансами Управление активами Управление поставщиками Управление контрактами Управление персоналом Управление знаниями персонала
Планирование и развитие ИТ	ИТ-стратегия Управление архитектурой информационных систем Управление архитектурой инфраструктуры ИТ Управление рисками ИТ Управление портфелем проектов по ИТ Управление проектами по ИТ
Анализ потребностей и удовлетворения  пользователей	Управление требованиями пользователей ИТ Управление Каталогом ИТ-сервисов Управление уровнем услуг (SLA) Оценка удовлетворенности пользователей
Разработка и внедрение	Разработка решений	Разработка требований (ТЗ) Разработка концепции решения Разработка решения Тестирование решения
Внедрение решений	Управление изменениями Управление релизами Управление конфигурациями
Непрерывность ИТ	Управление непрерывностью Управление доступностью Управление мощностями Управление требованиями со стороны государства, акционеров и руководства компании
Поддержка ИТ	Поддержка техни-ческих средств и сетей	Выполнение операций Управление событиями Управление серверами и сетями Управление инженерной инфраструктурой
Поддержка пользователей (Help Desk)	Управление инцидентами Управление проблемами Управление доступом пользователей
Информационная безопасность	Управление безопасностью

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

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

Другой вид стратегической диаграммы по планированию ИТ-процессов приведен на Рис. 11.

У генерального директора вашей компании стоит спросить текущую и ожидаемую через 1-2 года важность каждого из направлений ИТ для бизнеса, а также степень удовлетворенности бизнеса текущим состоянием ИТ для каждой области (см. Рис. 11): Рис. 11. Текущее и требуемое через 1-2 года состояние направлений ИТ

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

Вот типовые рекомендации по улучшению ИТ-процессов:

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

Тенденции по ИТ-процессам

Улучшение ИТ-процессов сейчас является, пожалуй, самым популярным направлением улучшения управления ИТ. Вот ряд современных тенденций по ИТ-процессам:

• Массовое внимание к улучшению ИТ-процессов;
• Широкое использование ITIL;
• Централизация ИТ-процессов.

Улучшение ИТ-процессов является сейчас одной из наиболее интересных и массовых областей оптимизации ИТ.

---

4. Анализ текущего состояния и планирование улучшений ИТ-процессов в рамках разработки ИТ-стратегии или стратегии цифровой трансформации бизнеса

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

Рис.12 . Место ИТ-процессов в ИТ-стратегии

Также по ИТ процессам надо определить и конкретные проекты по их улучшению и поддерживающие их цели ИТ (как минимум, приоритеты, что важнее — обеспечение непрерывной работы того, что уже внедрено, или же быстрое внедрение новых программ).
В рамках разработки стратегии цифровой трансформации бизнеса, целесообразно учесть ИТ-процессы не только как часть управления ИТ, но и как части процессов поддержки инфраструктуры ИТ; информационных систем; бизнес-процессов, которые предполагается цифровизировать:
Рис. 13. Место ИТ-процессов в стратегии цифровой трансформации бизнеса

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

Рис. 14. Аудит цифровой трансформации бизнеса, включая ИТ-процессы

На взгляд автора этой публикации, планировать развитие ИТ-процессов лучше вместе с планированием других элементов ИТ, и постепенно, начав с выработки основных направлений развития ИТ и аудита ИТ:Рис. 15. Этапы разработки стратегии улучшения ИТ-процессов на 1-3 года

Более подробно см. стратегию развития ИТ-процессов.

---

5. Типовые варианты планирования ИТ-процессов на 1 год и более

Рекомендации в зависимости от того, что надо улучшать:

• если текущее состояние ИТ-процессов непонятно, насколько плохо или хорошо, а точнее непонятно исходя из чего далее планировать улучшения ИТ-процессов, то лучше провести аудит ИТ-процессов.
  Аудит должен дать независимую оценку, адекватны ли ИТ-процессы вашей компании. Вряд ли вашей компании надо работать также четко как Google и IBM, но и регулярно терять запросы пользователей вроде бы тоже ни к чему, т.е. для каждой компании, в конкретный момент времени, есть небольшой диапазон оптимальных уровней зрелости ИТ-процессов.
  Осталось лишь определить, каков этот «оптимальный уровень зрелости» по каждому из основных ИТ-процессов. Вот и вся задачка.
• если обязательно нужно улучшить ИТ-процессы, спланировав их развитие на 1-3 года, но при этом остальные элементы ИТ (информационные системы, инфраструктура, управление ИТ) планировать не нужно или не получается, то можно предложить разработать стратегию улучшения ИТ-процессов.
  Хотя существенно лучше запланировать развитие не только ИТ-процессов, но и всех основных элементов ИТ, сделав это в рамках комплексной стратегии развития ИТ (если такой стратегии пока нет, то лучше начать с совместной с консультантами разработки ИТ-стратегии).
• если гендиректор вашей компании обеспокоен (или наоборот, воодушевлен) цифровой трансформацией бизнеса, то запланировать развитие ИТ процессов (да и всех основных элементов ИТ) можно в рамках разработки стратегии цифровой трансформации бизнеса (или его первого шага — стратегии создания единой цифровой платформы бизнеса).

А вот рекомендации в зависимости от размеров компаний:

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

---

Концепция управления качеством информационных услуг (Information Technology Service Management — ITSM) возникла в результате принципиального изменения сегодняшней роли ИТ-подразделений. Бизнес-процессы настолько тесно увязаны с приложениями, техническими ресурсами и деятельностью персонала отделов автоматизации, что эффективность последних оказывается одним из решающих факторов эффективности компании в целом.

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

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

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

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

Итак, ITSM подразумевает коренную реорганизацию службы эксплуатации информационных технологий. Опираясь на мировой опыт, компания Нewlett-Рackard разработала типовую модель управления качеством информационных услуг, так называемую ITSM Reference Model. Модель детально описывает процессы и взаимосвязи между ними, которые должен поддерживать ИТ-отдел, чтобы предоставлять информационные услуги с гарантированным качеством.

Ключевые элементы ITSM — процессы, персонал, технологии

Идеология ITSM держится на трех китах:

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

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

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

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

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

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

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

Особую роль играет менеджер процесса — Process Owner — сотрудник, который будет контролировать выполнение процесса от начала и до конца. Его обязанности и полномочия должны быть определены и подтверждены руководством компании, поскольку менеджеру процесса придется принимать решения, затрагивающие разные подразделения. Ведь ИТ-процесс, как правило, является кросс-функциональным и пересекает организационные границы. Когда в компании развертывается новое приложение или происходит модернизация сервера, директивы менеджера такого процесса обязаны выполнять сотрудники любых отделов, которых коснутся изменения информационной инфраструктуры. Менеджер процесса назначает ответственных за определенные задачи, анализирует влияние процесса на функционирование бизнеса компании, поддерживает взаимоотношения с менеджерами других подразделений. Для ИТ-отделов, которые привыкли распределять ответственность персонала по функциональным группам ресурсов и не имеют общего видения процессов, реорганизация работы, связанная с определением процесса и его менеджера, необходима, но и наиболее сложна.

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

Типовая модель

Два года назад Hewlett-Packard предложила типовую модель информационных технологий HP IT Reference Model, которая позволяет разработать структуру ИТ-процессов в компании и на ее основе реализовать управление качеством информационных услуг. Типовая модель представляет собой методику внедрения лучшего международного опыта в области ИТ, собранного в Библиотеке IT Infrastructure Library. Библиотека ITIL — это сборник из 68 книг по различным областям функционирования ИТ, включая планирование ресурсов, управление проблемами, управление инцидентами, разработку и внедрение новых услуг, снижение расходов, управление пользователями и т.д. Эта информация собиралась и систематизировалась Комитетом по телекоммуникациям при правительстве Великобритании, а сейчас поддерживается, издается и обновляется независимой организацией EXIN.

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

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

Рис. Типовая модель ИТ

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

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

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

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

Процесс управления конфигурациями (configuration management) регистрирует и контролирует данные об ИТ-инфраструктуре. Этот процесс обрабатывает информацию о каждом элементе конфигурации (configuration item — CI): атрибуты CI (системы и сетевые устройства, прикладные программы, персонал, документация и т.д.), статус CI (в наличии, в ремонте, в производственной среде и т.д.) и взаимосвязи между ними (например, «компьютер А находится на рабочем столе пользователя X», «принтеры В, C и D доступны для использования» и т.д.). Процесс управления конфигурацией, который относится только к ресурсам ИТ-инфраструктуры, не следует путать со стандартной процедурой управления ресурсами предприятия. Любые процессы, влияющие на инфраструктуру (а это все процессы модели), будут взаимодействовать с процессом управления конфигурацией.

Привязка ИТ к бизнес-процессам

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

В ходе анализа бизнес-процессов (business assessment) исследуется рынок ИТ-услуг и определяются бизнес-требования к ИТ-отделу. Процесс управления пользователями (customer management) позволяет ИТ-отделу выступить в роли полноправного бизнес-партнера для потребителей информационных услуг. Управление пользователями — это возможность прогнозировать их потребности, продавать ИТ-услуги, измерять степень удовлетворенности заказчика предоставленной ему услугой. Процесс управления пользователями взаимодействует с другими процессами «бизнес-группы». Информация о пользователях, полученная в ходе выполнения этого процесса, может использоваться при анализе рынка и конкурентной ситуации, а результаты анализа бизнес-процессов и данные о пользователях в свою очередь являются основой для разработки ИТ-стратегии.

Ключевое значение для ITSM имеет процесс разработки ИТ-стратегии (IT strategy development). Используя данные процессов бизнес-анализа и управления пользователями, этот процесс трансформирует требования бизнеса в цели и задачи ИТ-отдела и планы их достижения. Разработка ИТ-стратегии включает определение бюджета ИТ-отдела, документальное закрепление общего видения ИТ-процессов и услуг, описание этапов реализации поставленных задач, определение ключевых условий их достижения и возможных проблем, выбор архитектуры информационной среды и необходимых технологий, а также, возможно, принятие решения о структурной реорганизации ИТ-отдела.

Управление услугами

Процессы этой группы преобразуют общее видение информационных услуг, ИТ-стратегию, в определение конкретных услуг с помощью детальных спецификаций. Процессы управления услугами определяют уровни предоставляемых услуг, поддерживают заключение соглашений об уровне обслуживания (service level agreement, SLА), обеспечивают защиту инфраструктуры и данных. Процессы управления услугами позволяют получить информацию о доступности услуг, необходимых ресурсах и возможностях снижения расходов. На этих данных будет базироваться контракт на обслуживание.

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

Понятие требуемого уровня предоставляемой услуги, которое может включать перечень приложений на рабочих местах, время отклика компьютерных систем, время исправления неисправностей и т.д., является важнейшей составляющей управления информационными услугами и поддерживается процессом управления уровнем услуг (service level management). В ходе этого процесса на основе заданных параметров стандартной услуги и оценок ее стоимости определяется, обсуждается с заказчиком, отслеживается и фиксируется в отчетах необходимый заказчику уровень услуг. Подробные спецификации услуг, полученные в результате выполнения процесса планирования услуг, являются отправной точкой для заключения осмысленных соглашений SLA.

Процесс управления безопасностью (security management) — одна из недавних доработок Типовой модели НР. Его появление вызвано критическим значением гарантированной защиты компьютерной инфраструктуры для нормального функционирования электронного бизнеса. Процесс управления безопасностью определяет и контролирует параметры защиты корпоративной информации и ИТ-услуг, реализует и поддерживает инфраструктуру информационной безопасности в компании. Все услуги, предоставляемые отделом автоматизации, должны в обязательном порядке удовлетворять тем стандартам защиты, которые формулирует этот процесс. Функции процесса управления безопасностью включают определение корпоративной политики защиты и доведение ее до каждого сотрудника ИТ-подразделений, анализ проблем с защитой, оценку рисков, связанных с защитой информации, анализ возникающих инцидентов и др.

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

Процесс управления ресурсами (capacity management) осуществляет контроль за тем, чтобы рабочая нагрузка задействованных компьютерных ресурсов отвечала тем требованиям, которые оговорены в соглашении об уровне услуги. Этот процесс также является поставщиком данных для процесса планирования услуг и управления уровнем услуг.

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

Разработка и внедрение услуг

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

Процесс реализации и тестирования (build&test) направлен на разработку и одобрение функциональной версии компонента информационной инфраструктуры, функции или услуги в целом. После того как сформулированы спецификации услуги, процесс реализации и тестирования получает нужные компоненты, реализует определенные функции или полномасштабное решение. Когда реализация компонента, функции или услуги завершена, проводится тщательное тестирование. В том числе проверяется соответствие компонентов и услуги принятым стандартам защиты. Процесс реализации и тестирования находится в тесном взаимодействии с процессами управления изменениями, управления конфигурациями и выпуском версии продуктивной системы.

Выпуск версии продуктивной системы (release to production) — это создание одной или нескольких копий нового или модифицированного компонента, сервисной функции и полномасштабной услуги в соответствии с подробным планом, который разрабатывается на этапе реализации и тестирования. Это процесс ввода услуги или ее компонентов в действие: он обеспечивает доставку, установку и интеграцию в рабочую среду необходимых ресурсов, реализацию механизмов поддержки и контроля за услугой, администрирование программного обеспечения, обучение пользователей и окончательные пользовательские тесты.

Оперативная поддержка

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

Управление операциями (operations management) — это, скорее, совокупность нескольких различных задач и процедур, а не единый процесс. Все они вместе поддерживают повседневные действия по предоставлению ИТ-услуги в соответствии с соглашением об уровне обслуживания. Управление операциями гарантирует нормальную работу информационной среды, что, в свою очередь, обеспечивает нормальное обслуживание заказчика. Задачи управления операциями — это мониторинг состояния ресурсов, управление очередями на печать, управление резервированием, администрирование клиентов, серверов, сетей, пользователей, IP-адресов и баз данных и т.д.

Управление инцидентами (incident management) или служба поддержки (Help Desk) — процесс быстрого восстановления готовности услуги с наименьшими потерями в случае возникновения инцидентов в инфраструктуре. Служба поддержки обрабатывает звонки пользователей, регистрирует информацию о сбое, определяет приоритеты разрешения инцидентов. Управление инцидентами предполагает повседневное взаимодействие потребителя и поставщика услуги, являясь ценным источником информации о том, насколько пользователь удовлетворен ИТ-обслуживанием.

Если управление инцидентами — это оперативное реагирование на сбои, то управление проблемами (problem management) реализует упреждающий подход, позволяя выявить корневые причины сбоев и предотвратить их до того, как они окажут необратимое воздействие на информационную среду. Исходной информацией для анализа служат инциденты, которые разрешены предыдущим процессом. Управление проблемами включает анализ тенденций возникновения проблемных ситуаций, оценку и контроль известных ошибок в инфраструктуре, информирование других процессов о потенциальных проблемах.

Реализация ITSM

Достоинство Типовой модели НР в том, что она не имеет определенных точек начала или конца; внедрение ITSM на ее основе можно начинать с любых процессов. Но есть несколько вариантов, которые наиболее типичны, поскольку помогают организациям быстро справиться со своими проблемами.

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

Если ИТ-отдел хочет стать поставщиком услуг, ему необходимо задуматься о том, каким образом он будет определять потребности своих клиентов и добиваться нужного качества обслуживания. А бизнес-подразделения хотят иметь возможность выбора нужных услуг, приобретения пакетов услуг. Для этого они должны как минимум понимать, что им предлагают. Но для ИТ-персонала проблематичной может оказаться даже попытка сформулировать возможности автоматизации на языке, доступном неспециалисту. Отношения ИТ-отдела с бизнес-подразделениями требуют формализации. Механизмом такой формализации являются соглашения SLA. Процесс управления уровнем услуг помогает выполнить все действия для заключения таких соглашений и, в совокупности с другими процессами, выявить необходимые связи между ИТ и бизнесом и получить общее видение услуг необходимого качества.

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

ITSM — новая для ИТ-отделов концепция. Но ее необходимость диктуется жизнью. Слишком велика сегодня роль информационных технологий для бизнеса, особенно для его «е»-компонента. То, что в Hewlett-Packard активно занялась этой проблемой, конечно, не случайно: технологическая основа для автоматизации работы ИТ-отдела — это платформа управления компьютерными системами и сетями HP OpenView (На пути у управлению ИТ-услугами, «Открытые системы», 2000, №7-8). Входящий в нее компонент IT Service Manager использует концепцию процессов и является обязательным компонентом проектов НР при развертывании ITSM-решений IT Service Manager интегрирован с другими компонентами OpenView, которые обеспечивают управление уровнем услуг, сбоями, проблемами, изменениями, позволяют взглянуть на информационные ресурсы с точки зрения бизнес-процессов и т.д. Внедрение ITSM-решений на основе Типовой модели и платформы OpenView в HP начали с себя, реорганизовав работу собственного ИТ-подразделения в соответствии с концепцией управления качеством информационных услуг.