Опубликован: 17.05.2012 | Уровень: для всех | Доступ: платный
Лекция 4:

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

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >

4.3. Дальнейшие действия в рамках Проектирования услуг

Прежде чем передать спроектированное решение на этап Внедрения, необходимо выполнить ряд дополнительных действий:

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

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

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

4.4. Модели для проектирования и предоставления услуг

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

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

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

Существует много моделей для предоставления услуг, каждая из которых имеет свои преимущества и недостатки. В табл. 4.1 представлены основные модели предоставления услуг. На практике предоставление услуг происходит по одной из представленных моделей или ее вариации.

Таблица 4.1. - Модели предоставления услуг
Инсорсинг (Insourcing) Использование внутреннего поставщика услуг для управления ИТ-услугами[1]. Организация использует внутренние ресурсы для проектирования, разработки, внедрения, управления, эксплуатации и(или) поддержки новых, измененных или пересмотренных услуг.
Аутсорсинг(Outsourcing) Использование Внешнего поставщика услуг для управления ИТ-услугами[1]. Организация использует ресурсы внешней организации(или организаций) для осуществления части деятельности, связанной с проектированием, разработкой, управлением, эксплуатацией или поддержкой услуг.
Ко-сорсинг (Co-sourcing) Комбинирование инсорсинга и аутсосинга. Используется ряд внешних организаций для обеспечения каких-то отдельных элементов в рамках жизненного цикла услуг. Сотрудники организации-заказчика и сторонней организации работают вместе для проектирования, разработки, внедрения, управления, эксплуатации и(или) поддержки новых, измененных или пересмотренных услуг. Например, на аутсорсинг может быть отдана часть разработки программного обеспечения, в то время как основным кодом будет владеть сам заказчик.
Партнерство или мультисорсинг (Partnership or multisourcing) Подход предусматривает формальное соглашение двух и более организаций на проведение совместных работ по проектированию, разработке, внедрению, управлению, эксплуатации и(или) поддержке услуг.
Аутсорсинг бизнес-процессов (Business Process Outsourcing) Подход предусматривает передачу целого бизнес-процесса организации-заказчика на аутсорсинг другой организации через заключение соглашения. Например, передача бухгалтерского учета.
Предоставление услуг прикладного уровня (Application Service Provision) Подход предусматривает заключение соглашений с Поставщиками услуг прикладного ПО. Поставщик услуг прикладного ПО (Application Service Provider или ASP) - внешний поставщик услуг, который предоставляет услуги с использованием приложений, развернутых на мощностях провайдера. Пользователи получают доступ к приложениям посредством сетевого подключения к провайдеру[1].
Аутсорсинг управления знаниями (Knowledge Process Outsourcing или KPO) KPO является новейшей формой аутсорсинга. По сути, является стадией, предшествующей аутсорсингу целых бизнес-процессов. В данном случае организация-заказчик передает внешней организации процессы, которые требуют специфических опыта, квалификации и навыков. Например, тренинг сотрудников. KPO предполагает управление процессами, которые требуют глубокого изучения или серьёзной аналитической обработки данных, формирования и управления базами знаний, которые в последующем могут использоваться, в том числе и для поддержки принятия решений.

Аутсорсинг позволяет компании-заказчику сократить издержки и значительно снизить трудоёмкость и затраты на эксплуатацию информационных систем и приложений, сконцентрироваться на основных бизнес-процессах компании, не отвлекаясь на вспомогательные[11].

К основным выгодам аутсорсинга можно отнести:

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

ITIL выделяет два подхода к разработке программного обеспечения и услуг:

  1. традиционное проектирование - так называемая, каскадная модель (от англ. waterfall). Модель проектирования, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки[12].
  2. RAD (от англ. rapid application development - быстрая разработка приложений) - концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Практическое определение: RAD - это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию[5].

В каскадной модели стадии идут в следующем порядке:

  • Определение требований
  • Проектирование
  • Конструирование (также "реализация" либо "кодирование")
  • Интеграция
  • Тестирование и отладка (также "верификация")
  • Инсталляция
  • Поддержка

При этом разработчик не может перейти к следующей стадии, не закончив предыдущую. Сначала полностью завершается этап "определение требований", в результате чего получается список требований к программному обеспечению. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка - внесение новой функциональности и устранение ошибок[12 ]. Плюсом каскадной модели является возможность заранее посчитать стоимость реализации решения, основным недостатком же - отсутствие гибкости и возможности быстро реагировать на изменяющиеся потребности бизнеса.

На рис. 4.9 представлено сравнение RAD и каскадного метода.

Сравнение RAD и Каскадного метода

Рис. 4.9. Сравнение RAD и Каскадного метода

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

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

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

В целом RAD имеет следующие преимущества перед традиционным подходом:

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

Еще одним подходом является покупка готовых решений, так называемых "off-the-shelf" или COST. При покупке такого программного обеспечения организация должна:

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

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

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >
Александр Колотов
Александр Колотов

Прошу вас уточнить по курсу ITIL. IT Service Management по стандартам V.3.1 вопрос о количестве версий ITIL.
Судя по названию и по материалу лекции версий 3. По факту версий 4. Т.е. как ответчать как правильно (4) или как по курсу который чуть устарел? Система оценки скорее всего будет согласно материала лекции.

Грета Березовская
Грета Березовская
Николай Растегаев
Николай Растегаев
Россия, Ижевск
Артем Кравченко
Артем Кравченко
Россия, МИИТ, 2010