Как отбиться от «ходоков» ИТ-Каталогом27.12.2023 13:00

Привет, Хабр! Меня зовут Андрей Прокофьев-Нужный и я решил поделиться опытом, который приобрела наша IT-компания М.Тех в процессе внедрения Каталога ИТ-услуг. Про Каталог услуг на просторах Интернета написано много статей и разных рекомендаций, включая практики ITIL и стандарт ISO, есть курсы и книги, но теория теорией, а на деле получается «как всегда»: не так красиво и даже местами совсем не понятно.

Здесь речь не пойдёт про тот «каталог услуг», который обычно размещается на порталах самообслуживания большинства компаний или встроен в популярные ИТСМ-системы. Несомненно, это тоже называется каталогом услуг, но в нашем случае он является лишь его витриной для пользователя, который непосредственно наш Каталог не видит, но косвенно им пользуется.

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

Что же такое для нас Каталог услуг и как он был воспринят коллегами?

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

Итак, обо всем по порядку.

С чего начался наш дозор

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

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

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

Ещё одним аргументом стала потребность в получении прозрачной статистики и отчётности по деятельности ИТ на любом уровне. Об этом я тоже расскажу чуть позже.

Кратко резюмируя причины для внедрения каталога в компании:

1.       Структурированный учёт услуг и систем

2.       Прозрачная статистика и отчётность по деятельности ИТ

3.       Данные для смежных ИТСМ-процессов

Основы проектирования

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

Для тех, кто начинает Каталог с нуля, обязательно возникнут вопросы: что конкретно включить в Каталог, чтобы удовлетворить потребности всех заинтересованных лиц; как начать формировать Каталог, когда не знаешь всех заинтересованных лиц в лицо и никто в компании не обладает такой информацией? Начните с основного:

1.       Определите количество уровней вложенности для услуг и систем

2.       Подключите к обсуждению и наполнению каталога архитектора услуг и/или систем, если таковые есть в компании или в ИТ

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

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

А насколько сложной должна быть структура?

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

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

Уровень II — Вид услуги или доменная функция. На этом уровне агрегируются названия крупных направлений компании, например, для торговых процессов таковыми могут быть Online Sales (продажи через интернет-магазин), Retail Sales (продажи через розничные магазины), Back Office (функции бек-офиса, поддерживающие розничные процессы) и User (пользовательские сервисы). Для продуктовой истории на этом уровне могут находится названия доменных функций или продуктовых кластеров.

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

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

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

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

Рисунок 1. Пример структуры каталога ИТ-услуг

В дальнейшем Каталог можно детализировать и до этого уровня, если есть такая потребность. Но всегда исходите из «масштабов» компании и потребностей окружающих. Если ваш каталог будет содержать несколько сотен услуг или тысяч бизнес-операций, возможно, в дальнейшем возникнет проблема с актуализацией этих данных и управлением каталогом в целом. К тому же, следует учитывать, что Каталог тесно связан с процессом управления уровнем услуг (Service Level Management) и поэтому одним из обязательных атрибутов услуги будет Соглашение об уровне услуг (Service Level Agreement). А какой SLA вы определите для бизнес-операций: один на всех или каждой отдельный — вопрос, однако.

Рисунок 2. Пример структуры продуктового каталога

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

Рисунок 3. Пример структуры каталога систем

В итоге, у вас получится три таблицы: одна — с перечнем услуг, вторая — с перечнем систем и третья таблица — связи услуг с системами. На начальном этапе, когда ещё нет готового автоматизированного решения для вашего Каталога, вы можете вести каталог в Excel, т.к. он вполне подходит для этой задачи. Услуги и системы можно разместить на отдельных листах книги, как и таблицу со связями. Лучше, если таблица со связями будет содержать ссылки на первые два листа, тогда вам достаточно будет вносить изменения в атрибуты услуг и систем на первых двух листах, а в третьей таблице дынные будут обновляться самостоятельно.

Атрибуты услуг и систем

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

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

Таблица 1. Атрибуты услуги в каталоге

Таблица 2. Атрибуты системы в каталоге

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

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

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

Таблица 3. Каталог услуг. Связи услуг с системами

Кто всё это будет делать?

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

Без актуализации данных Каталог быстро потеряет смысл. Наш Каталог на данный момент вмещает около трёх сотен услуг и трёх сотен модулей систем. С актуализацией данных и ведением такого Каталога справляется 0.25 FTE, при этом сотрудник совмещает ещё несколько ролей в процессе.

В процесс были включены следующие основные роли:

Таблица 4. Роли в процессе управления Каталогом услуг

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

Как показала практика, самым популярным вопросом среди всех участников процесса стал вопрос — А ЗА ЧТО ОТВЕЧАЕТ ВЛАДЕЛЕЦ УСЛУГИ/СИСТЕМЫ? Важно в Каталоге и регламенте процесса дать чёткое определение этой роли, т.к. это практически ключевые роли в процессе.

Таблица 5. Пример определения роли владельца услуги и системы

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

На практике: просто и красиво

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

Рисунок 4. Каталог и другие процессы ИТСМ

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

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

Рисунок 5. Классификаторы заявки

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

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

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

Каталог услуг vs коробочные решения

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

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

Кто-то должен нести дозор

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

Таблица 6. Пример реестра изменений Каталога

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

Помимо excel-формата дополнительно можно реализовать электронный Каталог, обновляемый непосредственно из CMDB. Тут полет вашей фантазии может быть ограничен только техническими возможностями и/или денежными средствами. Главное, установите чёткую последовательность внесения изменений в Каталог, чтобы не было расхождений между источниками, например:

1.       Каталог в excel-формате

2.       Каталог в CMDB

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

Главной причиной устаревания данных в Каталоге является незаинтересованность или не вовлеченность в процесс людей.

Вместо выводов: на страже хаоса

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

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

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

Спасибо всем, кто прочитал до конца. А как обстоят дела у вас в компаниях? Буду рад любым комментариям.

© Habrahabr.ru