Каталог ИТ-услуг: как приручить дракона

Размещено в: Технологии и подходы/ Technologies and Frameworks по материалам It4business.ru

Лариса Будкова, ведущий тренер-консультант, Роман Журавлёв, директор по обучению, Cleverics

Зачем нужен каталог услуг?

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

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

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

Каким должен быть каталог услуг?

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

Минимум определен. Но достаточен ли он? Попробуем разобраться.

Традиционно каталог услуг соотносят с теми процессами, которые раньше (в ITIL второй версии) назывались «процессами предоставления услуг», а теперь (в ITIL третьей версии) – «процессами проектирования услуг». Эти процессы, а в первую очередь – процесс управления уровнем услуг (Service Level Management), работают в трех основных областях: проектирование новых/изменяемых услуг; управление качеством услуг, находящихся в эксплуатации; управление взаимоотношениями.

• Проектирование услуг – это деятельность по трансляции требований заказчиков к услугам (Service Level Requirements, SLR) в детальные спецификации услуг, включающие в себя их основные характеристики, модели услуг, требования и критерии для успешного развертывания услуг и их последующей эксплуатации. ITIL v3 называет результат этой деятельности Service Design Package, SDP.
  Требования к информации: для того, чтобы проектировать услуги, надо понимать как организована работа по их предоставлению, развертыванию, эксплуатации и поддержке, какие при этом необходимы и/или используются ресурсы, какие задействованы внешние и внутренние услуги.
• Управление качеством услуг, находящихся в эксплуатации, предполагает анализ данных о предоставлении услуг, оценку качества услуг и инициацию корректирующих мер, направленных либо на обеспечение соответствия этого качества ранее согласованным критериям, либо на его повышение с учетом ожидаемого будущего изменения этих критериев.
  Требования к информации: для того, чтобы выполнить эту работу, необходимо организовать сбор данных о функционировании компонентов инфраструктуры и исполнении работ внешними и внутренними командами, влияющих на итоговое качество услуги, а также об удовлетворенности заказчиков и конечных пользователей услуг.
• Управление взаимоотношениями можно разделить на две подгруппы – управление отношениями с поставщиками и управление отношениями с заказчиками (такое разделение используется в стандарте ISO/IEC 20000, и отчасти – в ITIL v3).
  Требования к информации: для того, чтобы управлять взаимоотношениями с поставщиками, надо знать какие услуги и на каких условиях они нам предоставляют, как эти услуги влияют на услуги, которые мы предоставляем заказчикам.
  Для того же, чтобы управлять отношениями с заказчиками, важно владеть информацией о том, какие услуги мы каждому из них предоставляем, каково влияние этих услуг на бизнес-деятельность, каковы особенности наших услуг при предоставлении разным заказчикам, как распределяются общие ресурсы (задействованные в предоставлении услуг для разных заказчиков).

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

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

Простой каталог

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

Цели / потребности:

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

Структура каталога: таблица с перечнем услуг.

Основные поля: идентификатор услуги, название¹, краткое описание (функциональное назначение услуги); тип услуги (см. ниже «Пример классификации услуг»); основной заказчик услуги; бизнес-приоритет (уровень критичности); место предоставления; часы предоставления поддержки; ответственный в ИТ²; группа, ответственная за поддержку; статус³;

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

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

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

Непростой каталог

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

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

Цели / потребности:

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

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

Возможные компоненты: справочник услуг, предусматривающий различные представления для целей управления поставщиками, качеством отдельных услуг, отношениями с заказчиками и т.д.; модели услуг, позволяющие наглядно отобразить связи и зависимости как для «исходящих» услуг (от чего зависит услуга N?), так и для «входящих» (какие услуги зависят от услуги Z?); параметры (показатели объема и качества) услуг, а также их целевые и пороговые значения, согласованные с заказчиком, и информация о том, как по этим параметрам собираются данные и представляются отчеты; внутренние («технические») описания услуг, включающие в себя перечни основных систем и/или ресурсов, от которых зависит предоставление каждой услуги⁴.

Преимущества: Как альтернатива построению CMDB, организации системы функционально-стоимостного учета и заключению множества SLA, «непростой» каталог услуг позволяет при сравнительно(!) невысоком уровне затрат на построение и сопровождение помочь в решении важных управленческих задач. Одновременно он не отменяет возможности развития полнофункциональных процессов управления финансами, конфигурациями, уровнем услуг и других. Напротив, сформированный таким образом каталог создает благоприятные условия для их дальнейшего развития. При этом «непростой» каталог сохраняет все плюсы «простого», кроме, разумеется, простоты.

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

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

Многоуровневый каталог

Известный критик «лучших практик», Роб Ингланд (Rob England), он же IT Skeptic, в своей книге «Owning ITIL» пишет о каталоге услуг⁵: «Каталог направляет ваших сотрудников. Это ключевой механизм изменений в культуре ИТ, основа отношений с заказчиками и важнейший инструмент организационных преобразований. Каталог услуг дает информацию всем процессам. Как только услуга определена в каталоге, процессы знают, что от них требуется, и знают, как приоритизировать эти требования.»

В модели Скептика есть четыре уровня каталога услуг:

• Актуальный каталог / Current Catalogue: срез текущего состояния, перечисление всех фактически предоставляемых услуг, включая те устаревшие услуги, которые мы больше не предлагаем новым пользователям. Это основной и необходимый элемент всей сервисной деятельности нашей ИТ-службы. Целевая аудитория – ИТ.
• Красивый каталог / Brochure Catalogue: высокоуровневый документ, написанный бизнес-языком, определяющий, что ИТ предлагает заказчикам. Используется как основа для управления отношениями с заказчиками. Также используется пользователями как справочник при взаимодействии с ИТ. Определяет целевое состояние. Целевая аудитория – заказчики, пользователи.
• Технический каталог / Technical Catalogue: объединение актуального и красивого каталогов, дополненное подробной технической информацией. Используется в работе ИТ. SLA (если есть) являются частью технического каталога; кроме того, в него входят: перечень критических компонентов, связанные услуги, правила эскалации… Целевая аудитория – ИТ.
• Автоматизированный каталог / Automated Catalogue: интерактивный инструмент, позволяющий пользователям просматривать и заказывать услуги. Важно понимать, что технологическая оболочка – самая простая часть такого каталога. Она должна быть основана на трех перечисленных выше документах. Эти уровни дополняют друг друга, а не заменяют. Целевая аудитория: пользователи.

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

Лучший каталог – полезный каталог

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

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

Сноски:

¹ Верное определение услуг в каталоге – непростая и очень важная задача, достойная отдельной статьи.
² Во многих проектах использовалась роль «куратор услуги», в ITIL® v3 это «владелец услуги» (service owner).
³ Возможные статусы: планируется; в разработке; пилот; в эксплуатации; приостановлена; архив.
⁴ Известны случаи, когда в состав «непростого» каталога включаются также ресурсно-сервисные модели услуг и правила распределения затрат, связанных с услугами, на поддерживающие услуги и ресурсы. (См., например: К.Скрипкин, С.Растопшина, И. Баринов, «Основание. Каталог услуг в управлении ИТ-службой» Альманах «itSMF Россия 2010. Избранные статьи».
⁵ R.England, «Owning ITIL. A skeptical guide for decision makers» © Copyright Two Hills Ltd 2009, стр. 90-92
⁶ Если вы чувствуете, что для управления каталогом вам нужен специально организованный процесс Service Catalogue Management, то, скорее всего, вы нарушили два следующих правила в списке.

проектирование программного обеспечения

7-я Международная конференция специалистов в области обеспечения качества ПО SQA Days-2010. Харьков, 14-15 мая

Размещено в: Тестирование ПО/ Software Testing по материалам It4business.ru

7-я Международная конференция специалистов в области обеспечения качества ПО SQA Days-2010 пройдёт в одном из крупнейших городов Украины, Харькове, 14-15 мая 2010г. в презентационно-выставочном центре «РАДМИР ЭКСПОХОЛЛ». Золотой партнёр конференции – лидер украинского IT-рынка компания GlobalLogic.

Сегодня SQA Days – это конференция № 1 в СНГ по тематике тестирования и обеспечения качества программного обеспечения. В общей сложности, за все время существования, мероприятие посетили более 1500 участников из компаний, представляющих различные сектора экономики. Конференция традиционно объединяет ведущих специалистов международного класса. Мероприятие примечательно ещё и тем, что пройдет впервые в Украине, стране, в которой традиционно сильная школа обеспечения качества ПО. В рамках SQA Days 2010 существует возможность получения международного сертификата ISTQB.

Что такое SQA Days?

Для многих специалистов и руководителей «Software Quality Assurance Days» это реальная возможность заявить о себе, повысить профессиональный уровень сотрудников, которые отвечают за качество ПО и, тем самым, укрепить конкурентные позиции и создать преимущество. SQA Days – это замечательная платформа общения и обмена опытом для людей, вовлеченных в сферу тестирования ПО. Ведущие профессионалы смогут рассказать о своих достижениях, показать, как эффективно использовать инструменты, методики и методологии. Для начинающих – это отличный шанс приобрести новые полезные знакомства в профессиональной среде.

Конференция посвящена вопросам, связанным с тестированием и обеспечением качества программного обеспечения:

• функциональному тестированию,
• тестированию производительности,
• автоматизации тестирования и инструментальным средствам,
• конфигурационному тестированию,
• тестированию удобства использования (usability) и защищенности,
• статическим методам обеспечения качества и другим сферам интересов QA-специалистов.

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

В программе конференции доклады ведущих специалистов в области обеспечения качества ПО. Предварительная программа конференции доступна на сайте конференции:
http://it-conf.ru/sqa7/docs/Agenda.xls

Кроме того, «Software Quality Assurance Days» 2010 – это уникальная возможность получить сертификат международного образца прямо во время! Только на SQA Days можно пройти экзамен международной ассоциации ISTQB (International Software Testing Qualifications Board, www.istqb.org). Узнать подробнее

Участие в конференции является платным

Стоимость участия 1день / 2 дня : 6 240 / 7 800 российских рублей,

Информация о скидках.

Где будет проходить конференция?

Украина, г. Харьков, ул. Академика Павлова 271, Презентационно-выставочный центр «РАДМИР ЭКСПОХОЛЛ». Подробней

Расписание:

Регистрация участников: с 8-30 по 9-30
Начало конференции: 9-30
Окончание конференции: 18-30 – 19-00

Контактная информация:
Владислав Орликов
Телефон: +375 (29) 770-48-58
Полаженко Сергей
Телефон: +375 (29) 751-98-04, +375 (29) 121-42-14
Email: org@it-conf.ru

Вы заинтересованы в карьерном росте и получении новых знаний? Следите за профессиональным уровнем своих сотрудников? Хотите всегда быть в курсе инноваций в сфере программного обеспечения? Спешите – количество мест ограничено.
Заявки на участие в конференции принимаются до 11-го мая.
Зарегистрироваться можно на сайте конференции.

Rонтроль качества программного обеспечения

Три набора софта, на которые стоит обратить внимание.

Размещено в: Решения/ Solutions по материалам Macradar.ru

 

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

Humble Indie Bundle предлагает сразу семь игр. В списке представлены World of Goo, Aquaria, Gish, LugaruHD, Penumbra, EFF и Child’s Play. Все игры созданы независимыми разработчиками, но хуже от этого они не стали ;-) Думаю, каждый найдет в этом наборе игру, которая увлечет на несколько часов. Интересная деталь — вы можете устанавливаете стоимость набора. Есть даже возможность выбрать, куда пойдут деньги: разработчикам или на благотворительность (можно разделить сумму между авторами и благотворителями).

Другой бандл, Bundleecious, предлагает за скромные 10 долларов 6 программ. Речь идет о таких приложениях, как DaisyDisk, Sofa Control, Img2IcnsPro (создание пиктограмм из картинок), Overflow (быстрый запуск приложений и открытие документов) и Headline (RSS-агрегатор).

Третий бандл Macbuzzer должен стартовать вот-вот. Детали неизвестны, но обещают сделать какое-то совершенно невероятное предложение.

разработка прорамм и программных продуктов