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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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