Вот здесь начался разговор о каталогах. Начался он с того, что я посетовал - как много людей ищут примеры, вместо того, чтобы сесть и сделать. Были отзывы и обсуждения, понятно, что тема сейчас востребована. Мы с коллегами как-то считали внедренные процессы во всех проектах, и выходило, что два наиболее популярных - управление инцидентами (куда же без него) и каталог услуг как наиболее часто создаваемый артефакт (процесс актуализации к нему, чтобы там кто не говорил - обычно простейший).
Я, кстати, давно уже использую слово артефакт (приехало из родственных моделей) для обозначения совокупности баз управления, документов и объектов: план доступности, база конфигураций, модель ценообразования, методика управления рисками и т.д и т.п. Общо и просто.
Так вот, каталог услуг ИТ сейчас важнейший артефакт. Почему? Объясняю - технического уровня организации сервиса почти все наелись, внедрением самостоятельным или даже консультантским процессов управления заявками, запросами, инцидентами и прочим совершенно не удивишь - это уже становится настоящем коробкой. Такие уже сейчас клепают десятками, а через год-два-три каждый интегратор будет уметь делать это накопленным опытом и силами вчерашних студентов. Коробки с автоматизацией, правда, разные очень, но это не беда. А вот с тактическим уровнем организации сервиса (да той же поддержки) до сих пор беда: SLM в полноценном виде делают и, главное, хотят делать до сих пор не десятки, а единицы: результат интереснее, но и ответственность выше. Каталог же определенно хорош для старта, для создания базы, на которой можно легко достроить SLM, да и самим процессам поддержки каталог ИТ далеко лишним не будет.
Конкретизирует деятельность? Да. Отвечает на вопрос что мы делаем? Да. Позволяет привнести порядка в процесс заказа услуг ИТ? Да. Формулирует подходы к организации деятельности? Тоже возможно. В общем, благолепие и красота со всех сторон.
А вот что некрасиво - нередко консультанты продвигают заказчику в голову идеи о избранности, возвышенности и "серебряннопулейности" каталога услуг. Мол, если сделать (подмигивают: а дело это непростое, без внешней помощи не обойтись), тогда быстро наступит благорастворение воздусей и счастье всемирного единения заказчика (Бизнес) и подрядчика (ИТ). Да не наступит. И вообще, хватит сакральных таинственных знаний о неведомо чем - в большинстве случаев, говоря о каталоге услуг ИТ, мы банально ведем речь о классификаторе.
Давайте определимся для начала, бывает ли это не так.
Первый каталог услуг, который я увидел в своей жизни - принадлежал аутсорсинговой западной компании, материнские заказчики которой умеют строить в том числе и поезда.
Крупной компании - крупный каталог, страниц на пятьсот, с описаниями архитектуры услуг, схемами поддержки, с выдержками об условиях оказания, ценами на услуги, перечнем услуг, детально описанным уровнями сервиса и прочее, и прочее. Ого, подумал я тогда, в ITIL как-то все проще выглядело. Второй каталог, который я увидел, был тоненькой симпатичной книжицей страниц на десять, в которой был дан перечень услуг, ну и краткие описания. И все. ОГО, подумал я тогда, в ITIL как-то посложнее все выглядело. А третий каталог услуг мы уже сделали сами. И как вы догадались - это было нечто среднее между вариантами один и два.
Какие бывают каталоги?
1. Классификатор внешних услуг (вариант "меню блюд в ресторане"). Перечень услуг, которые продаются Заказчику с кратким описанием, может быть ссылками на соглашения.
Об этом варианте речь идет наиболее часто.
2. Классификатор внутренних и внешних услуг (вариант "рецептура блюд", но и меню тоже присутствует - либо в самом начале, либо в одном из приложений). Перечень внешних услуг, перечень внутренних услуг, архитектура, ответственные, схемы поддержки - тут уже наполненность выше, да и внутренних услуг обычно больше.
Примерно плюс-минус пятьдесят страниц об этом пишет ITILv3 - бизнес-каталог ("меню") дополнен технологическим каталогом ("составляющие блюд"), а там уже и до настоящей "рецептуры" недалеко.
3. Различные начинки к первым двух блюдам - в основном технологические (как построить? как сделать, чтобы не развалилось?), финансовые (как узнать стоимость? как продать?) ну и другие возможны.
И, в общем-то, на этом все. По сути дела - речь всегда идет о классификаторе той или иной степени дополненности околостоящим материалом. ВСЕ. Никаких сакральных знаний тут нет, и артефакт каталог услуг свое качество показывает банально на практике, все ли деятельности учли в каталоге? Построен ли он и автоматизирован настолько гибко, чтобы при изменении структуры услуг, его можно легко менять? Легко ли использовать для расчёта модели стоимости? И т.д. и т.п.
Я уже писал в комментариях к предыдущей заметке, что мне не очень интересно думать на тему - как сделать каталог услуг в конкретной ситуации для конкретных условий. Садись и делай - в любом случае получится более или менее удачно, следующий всяко уже удачнее будет, чем предыдущий. Более интересно понять, кто вообще может быть заинтересован в каталоге?
Давайте попробуем собрать все роли и варианты использования в список:
1. Кто: заказчик. Как: заказывает существующие услуги по классификатору с выбором параметров услуги: объем, качество, место.
2. Кто: заказчик. Как: формирует бюджет, в разрезе внутренних потребителей и классификатора.
3. Кто: подрядчик. Как: определяет, что заказано, а что нет конкретному пользователю вот этого заказчика в ходе поддержки услуг.
4. Кто: подрядчик. Как: классифицирует свою деятельность ИТ в ходе поддержки.
5. Кто: подрядчик. Как: определяет себестоимость услуг в разрезе классификатора.
6. Кто: пользователь. Как: никак, пользователю каталог услуг только мешает 8)
Какие из ключевых ролей и действий забыл?
Начало разговоров о каталогах.
Полезные ссылки:
Практический пример создания каталога услуг ИТ "своими руками" от itil-ist
Анатолий Левенчук о каталогизации вообще (кому интересно - ищите дальнейшие ссылки по ключевым словам в его ЖЖ)
