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

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

Существует много моделей для предоставления услуг, каждая из которых имеет свои преимущества и недостатки. В табл. 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 и каскадного метода.

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

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

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

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

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

1.продукт быстрее поступает на рынок;

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

3.большая адаптивность к изменяющимся требованиям бизнеса;

4.простота развития и изменения функциональности решения.

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

1.понимать достоинства и недостатки этого подхода;

2.формализовать процесс выбора наиболее эффективного готового решения;

3.определить процесс для эффективной интеграции и настройки готового решения;

4.определить функциональные требования на приемлемом уровне;

5.сформировать перечень управленческих и операционных требований;

6.определить требования к продукту и поставщику;

7.определить требования к интеграции услуги.

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