ТЕХНОЛОГИИ И ПОДХОДЫ/ TECHNOLOGIES AND FRAMEWORKS

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

Размещено в: Технологии и подходы/ 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, то, скорее всего, вы нарушили два следующих правила в списке.

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

Исследование «IBM Global CIO Study»: отчет «Новая роль ИТ-директоров»

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

Услуги IT аутсорсинга

IBM проследит за качеством данных

Размещено в: Технологии и подходы/ Technologies and Frameworks, Управление документооборотом/ Document Management по материалам osp.ru - Software

Компания пополняет серию продуктов для управления данными

В марте IBM выпустит бета-версию продукта, предназначенного для отслеживания потоков информации между различными системами. InfoSphere Business Information Monitor, новый компонент в линейке продуктов для управления данными IBM InfoSphere, будет контролировать перемещение данных из баз данных в системы бизнес-аналитики и другие корпоративные решения и посылать предупреждения по электронной почте или с помощью RSS, если выявлены нарушения с исходными данными. Продукт подразумевает установку агентов на серверы баз данных или другие источники для мониторинга этих платформ на предмет изменений в самих данных или в их структуре. Если, например, что-то не так с таблицей базы данных, Business Information Monitor сообщит об этом пользователям базы. Метрики для определения качества данных и выдачи предупреждений задаются администратором.

Решение базируется на средствах мониторинга баз данных в реальном времени компании Guardium, купленной IBM в ноябре, а также разработках IBM Research. Продукт может работать с реляционными СУБД IBM DB2, Oracle, SQL Server, Sybase, хранилищами данных Teradata, ERP-системами SAP и Oracle, BI-платформами IBM Cognos, SAP Business Objects, Oracle Hyperion и др.

Внедрение СЭД

Agile побеждает

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

Forrester признает широкое распространение скорых методов разработки

Процессы скорой (agile) разработки, предполагающие создание программного обеспечения с помощью небольших итераций вместо долгосрочного полномасштабого планирования проекта, постепенно занимают доминирующее положение, считают аналитики Forrester Research. 35% из 1300 ИТ-специалистов, принявших участие в опросе, отметили, что их процессы разработки можно охарактеризовать как скорые. Это число увеличивается до 46%, если к agile-подходам отнести RUP или «спиральный» метод.

Аналитики считают, что наиболее верным признаком широкого признания скорых методов является отказ разработчиков от ортодоксальности – они готовы комбинировать в проектах различные подходы и методики в стремлении обеспечить оптимальное решение стоящих перед ними задач. По данным Forrester, наиболее популярным скорым процессом является Scrum – ему следуют 11% респондентов.

Разработка программных приложений

Новое в IBM Rational

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

Обновление линейки IBM Rational затронуло инструменты, расширяющие экспертизу заказчиков в разработке собственных продуктов. IBM Rational Systems Architect 11.3.1 предлагает интеграцию с средством управления проектами и портфелями Rational Focal Point, подключение к инструментам измерения производительности IBM Rational Insight, поддержку Open Group Architecture Framework 9, расширенные возможности подготовки отчетов, анализа и принятия решений. В системе управления требованиями IBM Rational DOORS Web Access 1.3 реализован ввод и редактирование требований посредством веб-интерфейса. В инструментарии проектирования и разработки на основе моделей IBM Rational Rhapsody 7.5.1 расширено взаимодействие между командой разработчиков и группой контроля качества, документация проектирования систем, возможности AUTOSAR (Automotive Open Systems Architecture).

В решение SOA-разработки IBM Rational Software Architect for WebSphere Software 7.5.4 добавлен модуль предоставления коммуникационных услуг. IBM Enterprise Verification Management Solution предлагает среду тестирования и моделирования разработки микросхем, в том числе однокристальных систем.

Разработка корпоративных порталов на основе IBM WebSphere Portal

« Предыдущая страница