Проектирование услуг как этап жизненного цикла услуг

4.1. Проектирование услуг как этап жизненного цикла

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

1. проектирование услуг, которые способны помочь бизнесу в достижении запланированных результатов;
2. проектирование процессов, поддерживающих жизненный цикл услуг;
3. идентификация рисков и управление ими;
4. проектирование безопасности и отказоустойчивости IT-инфраструктур, оборудования, приложений, информационных ресурсов;
5. проектирование методов и метрик для измерений;
6. создание планов, процессов, политик, стандартов, архитектур и документов, которые будут способствовать проектированию качественных IT-решений, и управление ими;
7. развитие различных способностей и навыков в IT-области;
8. содействие улучшению качества услуг[10].

Требования для новых услуг формируются, как правило, на основе данных из Портфеля услуг и потребностей бизнеса. Проектирование услуг начинается с построения набора требований бизнеса и заканчивается разработкой решения, которое сможет удовлетворить эти требования и помочь бизнесу достичь запланированных результатов. Найденное решение вместе с проектной документацией переходит на этап Внедрения для запуска, тестирования или развития новой/измененной услуги. Проектная документация услуги (Service Design Package или SDP) - документы, определяющие все аспекты услуги и требования к ней на каждой стадии жизненного цикла [1]. Перед реализацией требования в проектной документации, оно должно быть проанализировано, формализовано и одобрено руководством.

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

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

Интересно, что в ITIL выделено Четыре "П" для этапа Проектирования услуг, так же как и для этапа Построения стратегии:

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

Проектирование услуг в глобальном смысле является частью общего процесса изменения бизнеса. Процесс Изменения бизнеса и роль IT в нем изображен на рис. 4.1.

увеличить изображение
Рис. 4.1. Процесс Изменения бизнеса

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

1. новое решение должно быть добавлено в Портфель услуг уже на стадии формирования концепции. Портфель услуг необходимо регулярно обновлять, дабы он отражал актуальный статус любых, даже самых незначительных, изменений в рамках инкрементального и итеративного развития.
2. В рамках начального анализа услуги/системы необходимо понять Требования к уровню услуг. Требование к уровню услуг (Service Level Requirements или SLR) - требование заказчика к IT-услуге. SLR(ы) базируются на бизнес-целях и используются для переговоров и согласования Целевых показателей уровня услуги[1].
3. Используя SLR, команда Управления мощностями может смоделировать новую услугу с использованием имеющихся инфраструктур и понять, сможет ли она поддерживать эту услугу в дальнейшем. Если время позволяет, результаты моделирования отразятся в Плане обеспечения мощностей. План обеспечения мощностей (Capacity Plan) используется для управления Ресурсами, необходимыми для предоставления IT-услуг. Этот план содержит сценарии для прогнозирования спроса со стороны бизнеса, и оценку затрат, необходимых для обеспечения согласованных Целевых показателей уровня услуги[1].
4. Если для обеспечения новой услуги или расширения поддержки имеющейся услуги требуются новые инфраструктуры, необходимо участие процесса Управления финансами.
5. Анализ влияния на бизнес и оценка рисков в отношении услуги должны быть проведены задолго до этапов Планирования мощностей, Проектирования доступности и формирования Стратегии обеспечения непрерывности.
6. Сервис-деск должен заранее готовиться к внедрению новых услуг, в частности, обучать свой персонал.
7. Этап Внедрения может начинать планирование реализации и построение расписания изменений.
8. Если новой услуге требуется дополнительное снабжение, необходимо вовлечение процесса Управления поставщиками. Управление поставщиками (Supplier Management) - процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства[1].

Услуга и ее компоненты представлены на рис. 4.2.

увеличить изображение
Рис. 4.2. Услуга и ее компоненты

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

1. бизнес-процесс - определение функциональных потребностей, для которых предоставляется услуга (например, телепродажи или выставление счета-фактуры);
2. услуга - собственно, сама услуга, которая предоставляется бизнесу и потребителям. Например, электронная почта или хранение информации;
3. SLA/SLR: документы, согласованные с заказчиком, которые определяют уровень, охват и качество услуги;
4. инфраструктура - все оборудование, которое необходимо для предоставления услуги пользователям, включая сервера, маршрутизаторы, концентраторы, телефоны, компьютеры и т.п.;
5. окружающая среда - окружающая среда, необходимая для безопасной эксплуатации инфраструктуры: кондиционирование воздуха, электричество и т.п.
6. данные - данные, необходимые для поддержки услуги, а также для обеспечения бизнес-процессов необходимой информацией (например, список клиентов, бухгалтерский регистр);
7. приложения - все программные приложения, необходимые для управления данными и обеспечивающие функциональные требования бизнес-процессов
8. поддерживающие услуги: любые дополнительные услуги, необходимые для предоставления услуги;
9. соглашения операционного уровня и контракты - любые соглашения, которые необходимы для предоставления услуги с качеством, согласованным на SLA;
10. службы поддержки - любые внутренние команды, обеспечивающие первую и вторую линию поддержки компонентов, необходимых для предоставления услуги, например, Unix или сети.
11. поставщики - любые внешние участники процесса, которые обеспечивают третью и четвертую линию поддержки компонентов, необходимых для предоставления услуги - сеть, аппаратное и программное обеспечение[10].

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

• Функциональность: услуга, ее функциональные возможности, способности и качество.
• Ресурсы: доступные люди, технологии и деньги.
• Расписание: временные границы.

Рис. 4.3. Три составляющих Проектирования

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

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

1. наличие хорошей взаимосвязи между различными действиями в рамках проектирования и другими частями, в том числе планами и стратегиями IT и бизнеса;
2. доступность последних версий планов и стратегий бизнеса для тех, кто участвует в проектировании;
3. соответствие проектной документации планам и стратегиям бизнеса и IT;
4. архитектуры и дизайны:
   • гибки, а, следовательно, способны быстро реагировать на новые потребности бизнеса;
   • интегрированы со всеми стратегиями и политиками бизнеса и IT;
   • поддерживают потребности других стадий жизненного цикла услуги;
   • содействуют продвижению новых или измененных услуг, соответствующих потребностям бизнеса.

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

1. Информация о требованиях к существующим услугам - какие изменения требуются в существующих услугах с учетом:
   • новых функциональных возможностей и требований;
   • изменений в бизнес-процессах, зависимостях, приоритетах, влиянии и критичности;
   • изменений в объеме транзакций услуги. Транзакция (Transaction) - дискретная функция, выполняемая ИТ-услугой. Например, перевод денег с одного банковского счета на другой. Одна Транзакция может содержать многочисленные добавления, удаления и изменения данных, при этом все они должны быть завершены успешно, в противном случае ни одна из них не должна быть выполнена (т.е. вся транзакция будет отменена);
   • повышения уровня услуги и целевых показателей уровня услуги в связи с новым драйвером у бизнеса, или понижение для старых услуг, которые будут в скором времени замещены;
   • потребностей в дополнительной информации процессов Управления услугами.
2. Информация о требованиях к новым услугам:
   • требуемая функциональность;
   • информация и другие потребности менеджмента;
   • поддерживаемый бизнес-процесс, зависимости, приоритеты, влияние и критичность;
   • требования уровня услуг и целевые показатели уровня услуг;
   • уровни транзакций бизнеса, уровни транзакций услуг, количество пользователей и его предполагаемый рост, типы пользователей;
   • финансовое и стратегическое обоснование для бизнеса;
   • предположение о будущих изменениях, то есть об известных будущих требованиях бизнеса или увеличение темпа роста.
   • уровень мощности для бизнеса, который должен быть представлен[10].

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

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

1. назначение менеджера проекта, создание проектной команды и утверждение руководства с применением формальной и структурированной методологии;
2. идентификация всех заинтересованных лиц, составление соответствующих документов с их требованиями и выгодами, которые они получат в результате реализации проекта;
3. анализ, документирование, расстановка приоритетов и согласование требований.
4. вычисление и утверждение бюджета\выгод бизнеса;
5. разрешение потенциальных конфликтов между бизнес-единицами и соглашением о корпоративных требованиях;
6. определение процессов для утверждения требований и изменения утвержденных требований;
7. развитие плана взаимодействия с заказчиком, подчеркивание основных отношений между IT и бизнесом, и то, как эти отношения и необходимая связь с заинтересованными сторонами будет управляться[10].

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

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