В жизненном цикле услуг за этапом Построения стратегии следует Проектирование услуг. Основной целью этого этапа является проектирование новых услуг или внесение изменений в существующие услуги. Основные задачи в рамках Проектирования услуг:
Требования для новых услуг формируются, как правило, на основе данных из Портфеля услуг и потребностей бизнеса. Проектирование услуг начинается с построения набора требований бизнеса и заканчивается разработкой решения, которое сможет удовлетворить эти требования и помочь бизнесу достичь запланированных результатов. Найденное решение вместе с проектной документацией переходит на этап Внедрения для запуска, тестирования или развития новой/измененной услуги. Проектная документация услуги (Service Design Package или SDP) - документы, определяющие все аспекты услуги и требования к ней на каждой стадии жизненного цикла [1]. Перед реализацией требования в проектной документации, оно должно быть проанализировано, формализовано и одобрено руководством.
Не все изменения в жизненном цикле услуг требуют вовлечения деятельностей этапа Проектирования. Проектирование затрагивается, когда необходимы "значимые" изменения. Организация должна определить свой набор "значимых изменений", чтобы каждый сотрудник организации понимал, когда необходимо проектирование. Другими словами, абсолютно все изменения должны быть оценены со стороны "значимости" в контексте Проектирования. Такая оценка является частью процесса Управления изменениями.
Разработанное на этапе Проектирования решение должно соответствовать политикам корпорации и IT. Поэтому при проектировании необходимо учитывать стратегии и ограничения, сформированные на этапе Построения стратегии.
Интересно, что в ITIL выделено Четыре "П" для этапа Проектирования услуг, так же как и для этапа Построения стратегии:
Проектирование услуг в глобальном смысле является частью общего процесса изменения бизнеса. Процесс Изменения бизнеса и роль IT в нем изображен на рис. 4.1.
(рис 4.1) Процесс Изменения бизнеса
Основная роль Проектирования в контексте процесса изменения бизнеса заключается в разработке инновационных услуг (в том числе их архитектуры, процессов, политик и документации), которые смогут удовлетворить настоящие и будущие потребности бизнеса. При этом ключевые процессы
Услуга и ее компоненты представлены на рис. 4.2.
(рис 4.2) Услуга и ее компоненты
Чтобы находить и создавать решения, которые смогут удовлетворить новые и существующие потребности бизнеса, проектирование услуг должно учитывать каждый из перечисленных ниже аспектов:
Проектирование должно рассматривать каждый из перечисленных выше аспектов в комплексе, а не изолированно. Чтобы в итоге получить конкурентоспособное решение, удовлетворяющее требованиям бизнеса, необходимо учитывать взаимосвязи и взаимозависимости указанных компонентов. При проектировании услуг под новые требования бизнеса следует учитывать не только функциональную составляющую этих требований. Предложенное на данном этапе решение должно обеспечивать бизнесу планируемую производительность. Делать всё необходимо с учетом имеющихся ресурсов, в установленных границах затрат и времени. Таким образом, менеджеры работают с тремя составляющими (рис. 4.3):
(рис 4.3) Три составляющих Проектирования
Назначением Проектирования является соблюдение тонкого баланса трех составляющих с целью максимального удовлетворения потребностей бизнеса, которые постоянно изменяются. Изменение одной из трех составляющих влияет как минимум еще на одну, а то и на две оставшиеся. Чтобы разрабатывать эффективные решения, поставщикам услуг крайне важно понимать движущие факторы бизнеса и его потребности. Проектирование часто воспринимается только как стадия, предшествующая Эксплуатации. В ITIL подход несколько другой. Проектирование должно не только предложить эффективные решения, но и обеспечить возможность эффективного управления этими решениями в течение всего жизненного цикла. Если объединить всё вышесказанное, то целостный и правильный подход к проектированию должен предусматривать разработку услуг с механизмами и функциями управления и улучшения на всех этапах жизненного цикла.
Люди, ответственные за управление Проектированием, должны убедиться в том, что обеспечено следующее:
Одним из подэтапов проектирования является определение и последующее документирование требований бизнеса и его драйверов. Под драйверами здесь понимается некие движущие бизнес-факторы: люди, информация и задачи, которые обеспечивают достижение поставленных целей. Для регулирования процессов проектирования информация делится на две категории:
Это минимальный набор информации для начала проектирования. Ее точность и аккуратность первостепенна. Если некорректная и неправильная информация будет использована на этапе Проектирования, то разработанная услуга не будет удовлетворять потребностям бизнеса в конечном итоге.
Требования к услугам должны быть документированы. Время, потраченное на это, будет компенсировано отсутствием в дальнейшем споров, дискуссий и разногласий между поставщиком услуг и заказчиком. Стадия определения требований бизнеса заключается в следующем:
После того, как требования согласованы и утверждены, у них появляется "ценник", то есть можно посчитать стоимость конкретного проекта. Требуется соблюдать баланс между тем, что организация может себе позволить и тем, что она хочет. Реализация некоторых требований может слишком дорого стоить и они должны быть исключены уже на этапе Проектирования. При необходимости все решения об исключении требований к услугам могут быть документированы и согласованы с представителями бизнеса. Обычно сложности возникают при сопоставлении того, что хочет бизнес и бюджета, выделенного под решение, который не принимает в расчет полную стоимость услуги, в том числе расходы на текущее обслуживание.
Применяемые документы при проектировании архитектуры и дизайны должны быть четкими, лаконичными, простыми и обоснованными. К сожалению, они часто слишком сложны и носят теоретический характер, а, следовательно, плохо применимы для практики в реальном мире.
Выделяется пять ключевых аспектов Проектирования услуг:
Конечно, ключевым аспектом проектирования является разработка решений, которые будут удовлетворять потребности бизнеса. Каждый раз при формировании новой услуги, она должна быть проверена по всем перечисленным выше пунктам. Это гарантирует то, что она сможет взаимодействовать и работать слаженно с другими услугами, которые уже находятся в эксплуатации. Рассмотрим подробнее ключевые аспекты Проектирования.
Для проектирования новой услуги или внесения изменений в существующую услугу необходимо совершить много действий. В первую очередь нужен строгий и структурированный подход, который позволит создать решение с оптимальной стоимостью, функциональностью, качеством и в заданном временном интервале. Этот процесс и его составляющие показаны на рис. 4.4. Показан жизненный цикл услуги, от новых или измененных требований бизнеса до проектирования, внедрения и эксплуатации. Важным моментом здесь является связь между людьми, которые эксплуатируют услугу, и теми, кто ее проектирует.
(рис 4.4) Создание услуг в соответствии с требованиями бизнеса
Ниже приведены области, которые должны быть рассмотрены в ходе проектирования решения:
Наиболее эффективным способом управления услугами в течение всего жизненного цикла является использование подходящих систем и инструментов управления. Основной системой управления является Портфель услуг, который описывает услугу, предоставляемую поставщиком, в терминах ценности для бизнеса. Он оперирует потребностями бизнеса и тем, что поставщик предлагает в ответ на них. Портфель услуг содержит детальную информацию о всех услугах и их статусе с отображением текущего этапа жизненного цикла (рис. 4.5).
(рис 4.5) Портфель услуг - центральное хранилище информации
ITIL рекомендует устанавливать услугам статусы, приведенные ниже:
Различные элементы одной услуги могут иметь различные статусы в один момент времени. Каждая организация должна аккуратно проектировать Портфель услуг, его содержание и доступ к нему. Содержание Портфеля услуг должно включать в себя следующую информацию:
Заказчики и пользователи могут получить доступ к услугам только на стадиях между "наполнена" и "эксплуатация". Услуги с этими статусами содержатся в Каталоге услуг. Несмотря на то, что проектирование Портфеля услуг осуществляется на стадии проектирования, владеет и управляет им процесс Управления Портфелем услуг с этапа Построения стратегии. (Процесс Управление портфелем услуг принадлежит стадии жизненного цикла Построение стратегии. Проектирование конкретных услуг осуществляется на этапе Проектирования услуг, но процесс, который определяет основные моменты (Управление портфелем услуг) относится к этапу Построения стратегии. Стратегия Предприятия -> Портфель -> Услуги. В рамках построения Стратегии определяется состав Портфеля услуг, а затем уже осуществляется детальная разработка конкретных услуг. )
Портфель услуг является основным источником информации о требованиях и услугах, следовательно, проектировать его нужно очень аккуратно и последовательно. Аналогичный подход к проектированию требуют и другие системы управления, например, Service
Термин "архитектура" имеет различные трактовки в зависимости от контекста. Здесь архитектура - фундаментальная структура системы, отображающая ее компоненты, их взаимодействие друг с другом и условия эксплуатации системы, а также принципы, лежащие в основе проектирования и развития системы.
Под "системой" здесь понимается не только системы в контексте IT. Система - совокупность компонентов, организованных для предоставления специфической функции или набора функций[10].
В качестве системы в данном контексте может рассматриваться организация в целом, бизнес-функция, информационная система и т.п. Сущность проектирования архитектур заключается в развитии и поддержке политик, стратегий, архитектур, дизайнов, документов, планов и процессов IT с целью развертывания и дальнейшей эксплуатации подходящих для организации услуг и решений. Входными данными для проектирования архитектур являются планы, стратегии и политики бизнеса и этапа Построения стратегии. Задачей проектировщиков является совершенствование и развитие дизайнов, планов, политик и архитектур. Этот процесс рассматривает также распределение ответственностей и ролей, услуги, технологии, архитектуры, процессы и процедуры, партнеров и поставщиков, методы управления. Проектирование архитектур также покрывает все вопросы в отношении технологий, в том числе инфраструктуру, окружение, приложения и данные.
Как уже было отмечено выше, в качестве системы можно рассматривать организацию в целом. Организация является сложной системой с множеством компонентов: персонал, бизнес-функции, процессы, организационная структура, информационные ресурсы, финансовые ресурсы, стратегии, системы управления и т.п. Архитектура корпорации должна показывать, как эти компоненты взаимодействуют друг с другом для достижения общей корпоративной цели. ITIL рассматривает архитектуру корпорации в контексте бизнеса, который она ведет, и используемых информационных систем (рис. 4.6).
(рис 4.6) Архитектура корпорации
Архитектура корпорации должна включать в себя следующие основные архитектуры:
Взаимосвязь описанных архитектур показана на рис. 4.7.
(рис 4.7) Взаимосвязь архитектур
Процесс - структурированный набор действий, спроектированный для достижения специфической цели. Процесс преобразовывает один или несколько входов в определенные выходы. Определение процесса включает в себя все роли, распределение ответственности, инструменты и контроль, требующиеся для надежной доставки оговоренных результатов.
Определенные однажды процессы должны контролироваться и быть управляемыми. Контроль процессов - деятельность, связанная с планированием и регулированием процесса, с целью представления процесса в эффективной, рациональной и стойкой манере. Только после определения уровней контроля, может быть определена система измерения эффективности контроля с соответствующими метриками (рис. 4.8).
(рис 4.8) Элементы процесса
Процесс всегда создается для достижения определенных целей. Выходы процесса должны напрямую зависеть от этих целей. При проектировании важным является разработка системы измерения и метрик для выходов процесса, системы отчетности и улучшения. У каждого процесса есть владелец, ответственный за процесс, его улучшение и то, что процесс обеспечивает достижение своих целей. Цели должны быть измеримы и описываться в терминах выгоды для бизнеса с учетом принятых политик и стратегий. На этапе Проектирования каждому процессу назначается владелец.
Выходы процесса должны соответствовать некому набору операционных норм, источником которых являются цели бизнеса. Если результаты процесса соответствуют нормам, его можно назвать эффективным (потому что он может быть повторен, является измеримым и управляемым). Процесс также может быть назван эффективным, если он использует минимальный набор ресурсов. Результаты измерения и анализа процесса с соответствующими метриками должны отображаться в управленческих отчетах и поступать на вход процесса Непрерывного улучшения.
Процесс является основой ITIL. Определение необходимых входов и выходов для процессов внутри организации дает возможность более эффективного и рационального управления ею. Установление норм для процессов позволяет измерить качество их работы. Нормы определяют конкретные условия, которым должны соответствовать результаты процесса. Определение норм дает основу процессу оценки качества процессов. Перед началом проектирования любого процесса важно представлять, как его выходы будут выглядеть. Каждая организация должна использовать формализованный подход для проектирования и реализации процессов сервис-менеджмента. Не нужно стремиться создавать "идеальные процессы". Важно проектировать практичные и приемлемые для данной организации процессы с встроенными в них механизмами улучшения. Одним из направлений развития процессного подхода является создание инструментов и стандартов, которые позволят осуществить интеграцию процессов, принадлежащих разным организациям. Примером является открытый стандарт
Данная часть этапа Проектирования имеет большое значение, так как именно система измерения предоставляет информацию об эффективности услуги. Эта информация оказывает влияние на поведение людей, работающих с измеряемыми процессами, цели, производительность персонала и команды, а также оплату труда.
Используемая система измерения и соответствующие ей метрики должны отражать качество и эффективность процессов проектирования с точки зрения бизнеса, заказчиков и пользователей. Она должна достоверно показывать способность услуги удовлетворять согласованным требованиям бизнеса.
Есть четыре типа метрик, которые могут быть использованы для измерения производительности и возможностей процессов:
Для незрелого процесса лучше подходят первые две метрики, для зрелого процесса рекомендуется определять эффективность и результативность.
Прежде чем передать спроектированное решение на этап Внедрения, необходимо выполнить ряд дополнительных действий:
Хотя существует возможность, что для разработанного решения не потребуется участие третьих сторон (то есть поставщиков), тем не менее, на практике чаще всего они участвуют, а, следовательно, необходимо выполнить следующее:
Модель для проектирования услуг зависит от модели их предоставления. То есть перед тем, как выбрать модель для проектирования новой услуги, необходимо провести обзор текущих возможностей и резервов для ее предоставления. Такой обзор должен включать в себя следующие вопросы:
Информация, полученная из такого обзора поставщика услуг, поможет понять, как он предоставляет услуги и какие возможности может задействовать в отношении новой спроектированной услуги. Модель предоставления услуг даст основу для выбора
Существует много моделей для предоставления услуг, каждая из которых имеет свои преимущества и недостатки. В табл. 4.1 представлены основные модели предоставления услуг. На практике предоставление услуг происходит по одной из представленных моделей или ее вариации.
| Использование внутреннего поставщика услуг для управления ИТ-услугами[1]. Организация использует внутренние ресурсы для проектирования, разработки, внедрения, управления, эксплуатации и(или) поддержки новых, измененных или пересмотренных услуг. | |
|---|---|
| Аутсорсинг( |
Использование Внешнего поставщика услуг для управления ИТ-услугами[1]. Организация использует ресурсы внешней организации(или организаций) для осуществления части деятельности, связанной с проектированием, разработкой, управлением, эксплуатацией или поддержкой услуг. |
| Ко-сорсинг (Co-sourcing) | Комбинирование |
| Партнерство или мультисорсинг (Partnership or multisourcing) | Подход предусматривает формальное соглашение двух и более организаций на проведение совместных работ по проектированию, разработке, внедрению, управлению, эксплуатации и(или) поддержке услуг. |
| Аутсорсинг бизнес-процессов
(Business Process |
Подход предусматривает передачу целого бизнес-процесса организации-заказчика на аутсорсинг другой организации через заключение соглашения. Например, передача бухгалтерского учета. |
| Предоставление услуг прикладного уровня
(Application |
Подход предусматривает заключение соглашений с Поставщиками услуг прикладного ПО. Поставщик услуг прикладного ПО (Application Service Provider или ASP) - внешний поставщик услуг, который предоставляет услуги с использованием приложений, развернутых на мощностях провайдера. Пользователи получают доступ к приложениям посредством сетевого подключения к провайдеру[1]. |
| Аутсорсинг управления знаниями ( |
KPO является новейшей формой аутсорсинга. По сути, является стадией, предшествующей аутсорсингу целых бизнес-процессов. В данном случае организация-заказчик передает внешней организации процессы, которые требуют специфических опыта, квалификации и навыков. Например, тренинг сотрудников. KPO предполагает управление процессами, которые требуют глубокого изучения или серьёзной аналитической обработки данных, формирования и управления базами знаний, которые в последующем могут использоваться, в том числе и для поддержки принятия решений. |
Аутсорсинг позволяет компании-заказчику сократить издержки и значительно снизить трудоёмкость и затраты на эксплуатацию информационных систем и приложений, сконцентрироваться на основных бизнес-процессах компании, не отвлекаясь на вспомогательные[11].
К основным выгодам аутсорсинга можно отнести:
ITIL выделяет два подхода к разработке программного обеспечения и услуг:
В каскадной модели стадии идут в следующем порядке:
При этом разработчик не может перейти к следующей стадии, не закончив предыдущую. Сначала полностью завершается этап "определение требований", в результате чего получается список требований к программному обеспечению. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка - внесение новой функциональности и устранение ошибок[12 ]. Плюсом каскадной модели является возможность заранее посчитать стоимость реализации решения, основным недостатком же - отсутствие гибкости и возможности быстро реагировать на изменяющиеся потребности бизнеса.
На рис. 4.9 представлено сравнение RAD и каскадного метода.
(рис 4.9) Сравнение RAD и Каскадного метода
RAD является более современным и гибким подходом к проектированию. Основным преимуществом RAD является применение итеративного и инкрементального подхода к разработке решений. Итеративный подход предполагает выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы, то есть своего рода обратную связь. Проект при этом подходе периодически проходит повторяющийся цикл Планирование-Реализация-Проверка-Оценка. Благодаря применению итеративного подхода, RAD может быстро реагировать на изменяющиеся требования бизнеса.
Инкрементальный подход предполагает разработку услуги "от куска к куску", то есть последовательно. При этом каждый "кусок" может поддерживать одну из бизнес-функций, для которых предназначена услуга в целом. Для бизнеса инкрементальный подход дает возможность использования какой-то значимой части услуги до того,как она будет разработана полностью.
При проектировании услуг возможно комбинирование инкрементального и итеративного подходов. Начинают с определения требований для услуги в целом, продолжают путем инкрементальной разработки отдельных ее частей.
В целом RAD имеет следующие преимущества перед традиционным подходом:
Еще одним подходом является покупка готовых решений, так называемых "off-the-shelf" или COST. При покупке такого программного обеспечения организация должна:
Покупка готовых пакетов программного обеспечения более экономична, но менее гибка, чем разработка собственных решений. Тем не менее, в ряде случаев организации легче и экономически выгоднее купить готовое решение.
В жизненном цикле услуг за этапом Построения стратегии следует Проектирование услуг. Основной целью этого этапа является проектирование новых услуг или внесение изменений в существующие услуги. Основные задачи в рамках Проектирования услуг:
Требования для новых услуг формируются, как правило, на основе данных из Портфеля услуг и потребностей бизнеса. Проектирование услуг начинается с построения набора требований бизнеса и заканчивается разработкой решения, которое сможет удовлетворить эти требования и помочь бизнесу достичь запланированных результатов. Найденное решение вместе с проектной документацией переходит на этап Внедрения для запуска, тестирования или развития новой/измененной услуги. Проектная документация услуги (Service Design Package или SDP) - документы, определяющие все аспекты услуги и требования к ней на каждой стадии жизненного цикла [1]. Перед реализацией требования в проектной документации, оно должно быть проанализировано, формализовано и одобрено руководством.
Не все изменения в жизненном цикле услуг требуют вовлечения деятельностей этапа Проектирования. Проектирование затрагивается, когда необходимы "значимые" изменения. Организация должна определить свой набор "значимых изменений", чтобы каждый сотрудник организации понимал, когда необходимо проектирование. Другими словами, абсолютно все изменения должны быть оценены со стороны "значимости" в контексте Проектирования. Такая оценка является частью процесса Управления изменениями.
Разработанное на этапе Проектирования решение должно соответствовать политикам корпорации и IT. Поэтому при проектировании необходимо учитывать стратегии и ограничения, сформированные на этапе Построения стратегии.
Интересно, что в ITIL выделено Четыре "П" для этапа Проектирования услуг, так же как и для этапа Построения стратегии:
Проектирование услуг в глобальном смысле является частью общего процесса изменения бизнеса. Процесс Изменения бизнеса и роль IT в нем изображен на рис. 4.1.
(рис 4.1) Процесс Изменения бизнеса
Основная роль Проектирования в контексте процесса изменения бизнеса заключается в разработке инновационных услуг (в том числе их архитектуры, процессов, политик и документации), которые смогут удовлетворить настоящие и будущие потребности бизнеса. При этом ключевые процессы
Услуга и ее компоненты представлены на рис. 4.2.
(рис 4.2) Услуга и ее компоненты
Чтобы находить и создавать решения, которые смогут удовлетворить новые и существующие потребности бизнеса, проектирование услуг должно учитывать каждый из перечисленных ниже аспектов:
Проектирование должно рассматривать каждый из перечисленных выше аспектов в комплексе, а не изолированно. Чтобы в итоге получить конкурентоспособное решение, удовлетворяющее требованиям бизнеса, необходимо учитывать взаимосвязи и взаимозависимости указанных компонентов. При проектировании услуг под новые требования бизнеса следует учитывать не только функциональную составляющую этих требований. Предложенное на данном этапе решение должно обеспечивать бизнесу планируемую производительность. Делать всё необходимо с учетом имеющихся ресурсов, в установленных границах затрат и времени. Таким образом, менеджеры работают с тремя составляющими (рис. 4.3):
(рис 4.3) Три составляющих Проектирования
Назначением Проектирования является соблюдение тонкого баланса трех составляющих с целью максимального удовлетворения потребностей бизнеса, которые постоянно изменяются. Изменение одной из трех составляющих влияет как минимум еще на одну, а то и на две оставшиеся. Чтобы разрабатывать эффективные решения, поставщикам услуг крайне важно понимать движущие факторы бизнеса и его потребности. Проектирование часто воспринимается только как стадия, предшествующая Эксплуатации. В ITIL подход несколько другой. Проектирование должно не только предложить эффективные решения, но и обеспечить возможность эффективного управления этими решениями в течение всего жизненного цикла. Если объединить всё вышесказанное, то целостный и правильный подход к проектированию должен предусматривать разработку услуг с механизмами и функциями управления и улучшения на всех этапах жизненного цикла.
Люди, ответственные за управление Проектированием, должны убедиться в том, что обеспечено следующее:
Одним из подэтапов проектирования является определение и последующее документирование требований бизнеса и его драйверов. Под драйверами здесь понимается некие движущие бизнес-факторы: люди, информация и задачи, которые обеспечивают достижение поставленных целей. Для регулирования процессов проектирования информация делится на две категории:
Это минимальный набор информации для начала проектирования. Ее точность и аккуратность первостепенна. Если некорректная и неправильная информация будет использована на этапе Проектирования, то разработанная услуга не будет удовлетворять потребностям бизнеса в конечном итоге.
Требования к услугам должны быть документированы. Время, потраченное на это, будет компенсировано отсутствием в дальнейшем споров, дискуссий и разногласий между поставщиком услуг и заказчиком. Стадия определения требований бизнеса заключается в следующем:
После того, как требования согласованы и утверждены, у них появляется "ценник", то есть можно посчитать стоимость конкретного проекта. Требуется соблюдать баланс между тем, что организация может себе позволить и тем, что она хочет. Реализация некоторых требований может слишком дорого стоить и они должны быть исключены уже на этапе Проектирования. При необходимости все решения об исключении требований к услугам могут быть документированы и согласованы с представителями бизнеса. Обычно сложности возникают при сопоставлении того, что хочет бизнес и бюджета, выделенного под решение, который не принимает в расчет полную стоимость услуги, в том числе расходы на текущее обслуживание.
Применяемые документы при проектировании архитектуры и дизайны должны быть четкими, лаконичными, простыми и обоснованными. К сожалению, они часто слишком сложны и носят теоретический характер, а, следовательно, плохо применимы для практики в реальном мире.
Выделяется пять ключевых аспектов Проектирования услуг:
Конечно, ключевым аспектом проектирования является разработка решений, которые будут удовлетворять потребности бизнеса. Каждый раз при формировании новой услуги, она должна быть проверена по всем перечисленным выше пунктам. Это гарантирует то, что она сможет взаимодействовать и работать слаженно с другими услугами, которые уже находятся в эксплуатации. Рассмотрим подробнее ключевые аспекты Проектирования.
Для проектирования новой услуги или внесения изменений в существующую услугу необходимо совершить много действий. В первую очередь нужен строгий и структурированный подход, который позволит создать решение с оптимальной стоимостью, функциональностью, качеством и в заданном временном интервале. Этот процесс и его составляющие показаны на рис. 4.4. Показан жизненный цикл услуги, от новых или измененных требований бизнеса до проектирования, внедрения и эксплуатации. Важным моментом здесь является связь между людьми, которые эксплуатируют услугу, и теми, кто ее проектирует.
(рис 4.4) Создание услуг в соответствии с требованиями бизнеса
Ниже приведены области, которые должны быть рассмотрены в ходе проектирования решения:
Наиболее эффективным способом управления услугами в течение всего жизненного цикла является использование подходящих систем и инструментов управления. Основной системой управления является Портфель услуг, который описывает услугу, предоставляемую поставщиком, в терминах ценности для бизнеса. Он оперирует потребностями бизнеса и тем, что поставщик предлагает в ответ на них. Портфель услуг содержит детальную информацию о всех услугах и их статусе с отображением текущего этапа жизненного цикла (рис. 4.5).
(рис 4.5) Портфель услуг - центральное хранилище информации
ITIL рекомендует устанавливать услугам статусы, приведенные ниже:
Различные элементы одной услуги могут иметь различные статусы в один момент времени. Каждая организация должна аккуратно проектировать Портфель услуг, его содержание и доступ к нему. Содержание Портфеля услуг должно включать в себя следующую информацию:
Заказчики и пользователи могут получить доступ к услугам только на стадиях между "наполнена" и "эксплуатация". Услуги с этими статусами содержатся в Каталоге услуг. Несмотря на то, что проектирование Портфеля услуг осуществляется на стадии проектирования, владеет и управляет им процесс Управления Портфелем услуг с этапа Построения стратегии. (Процесс Управление портфелем услуг принадлежит стадии жизненного цикла Построение стратегии. Проектирование конкретных услуг осуществляется на этапе Проектирования услуг, но процесс, который определяет основные моменты (Управление портфелем услуг) относится к этапу Построения стратегии. Стратегия Предприятия -> Портфель -> Услуги. В рамках построения Стратегии определяется состав Портфеля услуг, а затем уже осуществляется детальная разработка конкретных услуг. )
Портфель услуг является основным источником информации о требованиях и услугах, следовательно, проектировать его нужно очень аккуратно и последовательно. Аналогичный подход к проектированию требуют и другие системы управления, например, Service
Термин "архитектура" имеет различные трактовки в зависимости от контекста. Здесь архитектура - фундаментальная структура системы, отображающая ее компоненты, их взаимодействие друг с другом и условия эксплуатации системы, а также принципы, лежащие в основе проектирования и развития системы.
Под "системой" здесь понимается не только системы в контексте IT. Система - совокупность компонентов, организованных для предоставления специфической функции или набора функций[10].
В качестве системы в данном контексте может рассматриваться организация в целом, бизнес-функция, информационная система и т.п. Сущность проектирования архитектур заключается в развитии и поддержке политик, стратегий, архитектур, дизайнов, документов, планов и процессов IT с целью развертывания и дальнейшей эксплуатации подходящих для организации услуг и решений. Входными данными для проектирования архитектур являются планы, стратегии и политики бизнеса и этапа Построения стратегии. Задачей проектировщиков является совершенствование и развитие дизайнов, планов, политик и архитектур. Этот процесс рассматривает также распределение ответственностей и ролей, услуги, технологии, архитектуры, процессы и процедуры, партнеров и поставщиков, методы управления. Проектирование архитектур также покрывает все вопросы в отношении технологий, в том числе инфраструктуру, окружение, приложения и данные.
Как уже было отмечено выше, в качестве системы можно рассматривать организацию в целом. Организация является сложной системой с множеством компонентов: персонал, бизнес-функции, процессы, организационная структура, информационные ресурсы, финансовые ресурсы, стратегии, системы управления и т.п. Архитектура корпорации должна показывать, как эти компоненты взаимодействуют друг с другом для достижения общей корпоративной цели. ITIL рассматривает архитектуру корпорации в контексте бизнеса, который она ведет, и используемых информационных систем (рис. 4.6).
(рис 4.6) Архитектура корпорации
Архитектура корпорации должна включать в себя следующие основные архитектуры:
Взаимосвязь описанных архитектур показана на рис. 4.7.
(рис 4.7) Взаимосвязь архитектур
Процесс - структурированный набор действий, спроектированный для достижения специфической цели. Процесс преобразовывает один или несколько входов в определенные выходы. Определение процесса включает в себя все роли, распределение ответственности, инструменты и контроль, требующиеся для надежной доставки оговоренных результатов.
Определенные однажды процессы должны контролироваться и быть управляемыми. Контроль процессов - деятельность, связанная с планированием и регулированием процесса, с целью представления процесса в эффективной, рациональной и стойкой манере. Только после определения уровней контроля, может быть определена система измерения эффективности контроля с соответствующими метриками (рис. 4.8).
(рис 4.8) Элементы процесса
Процесс всегда создается для достижения определенных целей. Выходы процесса должны напрямую зависеть от этих целей. При проектировании важным является разработка системы измерения и метрик для выходов процесса, системы отчетности и улучшения. У каждого процесса есть владелец, ответственный за процесс, его улучшение и то, что процесс обеспечивает достижение своих целей. Цели должны быть измеримы и описываться в терминах выгоды для бизнеса с учетом принятых политик и стратегий. На этапе Проектирования каждому процессу назначается владелец.
Выходы процесса должны соответствовать некому набору операционных норм, источником которых являются цели бизнеса. Если результаты процесса соответствуют нормам, его можно назвать эффективным (потому что он может быть повторен, является измеримым и управляемым). Процесс также может быть назван эффективным, если он использует минимальный набор ресурсов. Результаты измерения и анализа процесса с соответствующими метриками должны отображаться в управленческих отчетах и поступать на вход процесса Непрерывного улучшения.
Процесс является основой ITIL. Определение необходимых входов и выходов для процессов внутри организации дает возможность более эффективного и рационального управления ею. Установление норм для процессов позволяет измерить качество их работы. Нормы определяют конкретные условия, которым должны соответствовать результаты процесса. Определение норм дает основу процессу оценки качества процессов. Перед началом проектирования любого процесса важно представлять, как его выходы будут выглядеть. Каждая организация должна использовать формализованный подход для проектирования и реализации процессов сервис-менеджмента. Не нужно стремиться создавать "идеальные процессы". Важно проектировать практичные и приемлемые для данной организации процессы с встроенными в них механизмами улучшения. Одним из направлений развития процессного подхода является создание инструментов и стандартов, которые позволят осуществить интеграцию процессов, принадлежащих разным организациям. Примером является открытый стандарт
Данная часть этапа Проектирования имеет большое значение, так как именно система измерения предоставляет информацию об эффективности услуги. Эта информация оказывает влияние на поведение людей, работающих с измеряемыми процессами, цели, производительность персонала и команды, а также оплату труда.
Используемая система измерения и соответствующие ей метрики должны отражать качество и эффективность процессов проектирования с точки зрения бизнеса, заказчиков и пользователей. Она должна достоверно показывать способность услуги удовлетворять согласованным требованиям бизнеса.
Есть четыре типа метрик, которые могут быть использованы для измерения производительности и возможностей процессов:
Для незрелого процесса лучше подходят первые две метрики, для зрелого процесса рекомендуется определять эффективность и результативность.
Прежде чем передать спроектированное решение на этап Внедрения, необходимо выполнить ряд дополнительных действий:
Хотя существует возможность, что для разработанного решения не потребуется участие третьих сторон (то есть поставщиков), тем не менее, на практике чаще всего они участвуют, а, следовательно, необходимо выполнить следующее:
Модель для проектирования услуг зависит от модели их предоставления. То есть перед тем, как выбрать модель для проектирования новой услуги, необходимо провести обзор текущих возможностей и резервов для ее предоставления. Такой обзор должен включать в себя следующие вопросы:
Информация, полученная из такого обзора поставщика услуг, поможет понять, как он предоставляет услуги и какие возможности может задействовать в отношении новой спроектированной услуги. Модель предоставления услуг даст основу для выбора
Существует много моделей для предоставления услуг, каждая из которых имеет свои преимущества и недостатки. В табл. 4.1 представлены основные модели предоставления услуг. На практике предоставление услуг происходит по одной из представленных моделей или ее вариации.
| Использование внутреннего поставщика услуг для управления ИТ-услугами[1]. Организация использует внутренние ресурсы для проектирования, разработки, внедрения, управления, эксплуатации и(или) поддержки новых, измененных или пересмотренных услуг. | |
|---|---|
| Аутсорсинг( |
Использование Внешнего поставщика услуг для управления ИТ-услугами[1]. Организация использует ресурсы внешней организации(или организаций) для осуществления части деятельности, связанной с проектированием, разработкой, управлением, эксплуатацией или поддержкой услуг. |
| Ко-сорсинг (Co-sourcing) | Комбинирование |
| Партнерство или мультисорсинг (Partnership or multisourcing) | Подход предусматривает формальное соглашение двух и более организаций на проведение совместных работ по проектированию, разработке, внедрению, управлению, эксплуатации и(или) поддержке услуг. |
| Аутсорсинг бизнес-процессов
(Business Process |
Подход предусматривает передачу целого бизнес-процесса организации-заказчика на аутсорсинг другой организации через заключение соглашения. Например, передача бухгалтерского учета. |
| Предоставление услуг прикладного уровня
(Application |
Подход предусматривает заключение соглашений с Поставщиками услуг прикладного ПО. Поставщик услуг прикладного ПО (Application Service Provider или ASP) - внешний поставщик услуг, который предоставляет услуги с использованием приложений, развернутых на мощностях провайдера. Пользователи получают доступ к приложениям посредством сетевого подключения к провайдеру[1]. |
| Аутсорсинг управления знаниями ( |
KPO является новейшей формой аутсорсинга. По сути, является стадией, предшествующей аутсорсингу целых бизнес-процессов. В данном случае организация-заказчик передает внешней организации процессы, которые требуют специфических опыта, квалификации и навыков. Например, тренинг сотрудников. KPO предполагает управление процессами, которые требуют глубокого изучения или серьёзной аналитической обработки данных, формирования и управления базами знаний, которые в последующем могут использоваться, в том числе и для поддержки принятия решений. |
Аутсорсинг позволяет компании-заказчику сократить издержки и значительно снизить трудоёмкость и затраты на эксплуатацию информационных систем и приложений, сконцентрироваться на основных бизнес-процессах компании, не отвлекаясь на вспомогательные[11].
К основным выгодам аутсорсинга можно отнести:
ITIL выделяет два подхода к разработке программного обеспечения и услуг:
В каскадной модели стадии идут в следующем порядке:
При этом разработчик не может перейти к следующей стадии, не закончив предыдущую. Сначала полностью завершается этап "определение требований", в результате чего получается список требований к программному обеспечению. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка - внесение новой функциональности и устранение ошибок[12 ]. Плюсом каскадной модели является возможность заранее посчитать стоимость реализации решения, основным недостатком же - отсутствие гибкости и возможности быстро реагировать на изменяющиеся потребности бизнеса.
На рис. 4.9 представлено сравнение RAD и каскадного метода.
(рис 4.9) Сравнение RAD и Каскадного метода
RAD является более современным и гибким подходом к проектированию. Основным преимуществом RAD является применение итеративного и инкрементального подхода к разработке решений. Итеративный подход предполагает выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы, то есть своего рода обратную связь. Проект при этом подходе периодически проходит повторяющийся цикл Планирование-Реализация-Проверка-Оценка. Благодаря применению итеративного подхода, RAD может быстро реагировать на изменяющиеся требования бизнеса.
Инкрементальный подход предполагает разработку услуги "от куска к куску", то есть последовательно. При этом каждый "кусок" может поддерживать одну из бизнес-функций, для которых предназначена услуга в целом. Для бизнеса инкрементальный подход дает возможность использования какой-то значимой части услуги до того,как она будет разработана полностью.
При проектировании услуг возможно комбинирование инкрементального и итеративного подходов. Начинают с определения требований для услуги в целом, продолжают путем инкрементальной разработки отдельных ее частей.
В целом RAD имеет следующие преимущества перед традиционным подходом:
Еще одним подходом является покупка готовых решений, так называемых "off-the-shelf" или COST. При покупке такого программного обеспечения организация должна:
Покупка готовых пакетов программного обеспечения более экономична, но менее гибка, чем разработка собственных решений. Тем не менее, в ряде случаев организации легче и экономически выгоднее купить готовое решение.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.