itSMF Russia :: Ассоциации организаций и специалистов в сфере управления информационными технологиями «ИТ сервис-менеджмент форум» баннер
НОВОСТИ УЧАСТИЕ В АССОЦИАЦИИ ОБ АССОЦИАЦИИ БИБЛИОТЕКА СОБЫТИЯ ДЛЯ УЧАСТНИКОВ ТРЕБУЮТСЯ СПЕЦИАЛИСТЫ БЛОГИ НАБЛЮДАТЕЛЬНЫЙ СОВЕТ

 

баннер

 

баннер

 

поделиться

Присоединиться к ITSM сообществу


Состав itSMF Russia


 

 


книжный магазин itSMF



Подпишитесь на новости ITSM-сообщества

* обязательные поля
Архив рассылок >>>



facebook linkedin баннер twitter



Реестр аккредитованных учебных центров, работающих в Российской Федерации и имеющих право проводить обучение по утвержденному списку курсов ITIL®


Manager’s Certificate in IT Service Management Список ITIL Expert'ов и сервис-менеджеров России и стран СНГ



Список российских профессионалов сервис-менеджмента, обладателей сертификатов priSM




Работа для Вас: актуальные вакансии


Чтобы дуэт состоялся.
Дискуссия об одной из ключевых составляющих модели аутсорсинга — взаимоотношениях заказчика и провайдера услуг
Untitled Document
Автор: Елена Некрасова
Опубликовано в журнале "CIO" №9 от 06 декабря 2009 года

(Продолжение. Начало в «CIO» № 7-8)

В предыдущем номере журнала («CIO», №7–8, 2009) мы начали дискуссию об одной из ключевых составляющих модели аутсорсинга — взаимоотношениях заказчика и провайдера услуг. Сегодня разговор продолжают:

- Иван Андрианов, директор департамента продаж сервиса и аутсорсинга компании «Открытые Технологии»

- Юрий Литвинов, руководитель практики Application Management в России компании Accenture Russia

- Георгий Ованесян, руководитель направления технической поддержки и ИТ-аутсорсинга компании КРОК

- Анна Плетенева, менеджер по развитию новых продуктов и сервисов сервисного центра компании «Ай-Теко»

- Румяна Свистунова, директор по развитию технологий компании «Verysell Проекты»

- Рафаэль Сухов, заместитель генерального директора Stack Group

- Владимир Шаталов, директор департамента сервисных технологий ЗАО «Стинс Коман».

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

Г. Ованесян: Совершенно верно, эта задача — одна из основных при выстраивании отношений. Здесь немаловажную роль играют SLA — соглашения об уровне услуг, которые призваны четко и детально описывать весь объем и содержание каждой услуги. Безусловно, только формальным документом всю задачу взаимоотношений «заказчик — поставщик» не решить. Необходимо адекватно и гибко выстраивать отношения, и немаловажную роль здесь играет готовность обеих сторон идти на компромиссы, понимать интересы и специфику друг друга.

А. Плетенева: Ситуация осложнена тем, что на данный момент рынок услуг ИТ-аутсорсинга находится в стадии становления, а это значит, что процессы оказания некоторых услуг пока не стандартизированы. С учетом того, что и бизнес-процессы компаний зачастую не формализованы, складывается сложная ситуация: заказчик не понимает, что именно ему нужно от аутсорсера, а поставщик услуг, в свою очередь, может ориентироваться только на техническое задание со стороны клиента — и в соответствии с этим в индивидуальном порядке разрабатывать схему обслуживания и содержание каждого сервиса. По моему мнению, от аутсорсера как профессионала в области ИТ-услуг требуется участие в аудите бизнес-процессов заказчика и помощь в составлении технического задания на аутсорсинг. По желанию заказчика к этому процессу может быть привлечена другая ИТ-компания как независимый эксперт. К процессу выработки технического задания следует отнестись с особым вниманием, потому что именно от него в дальнейшем во многом будет зависеть полнота предоставляемой услуги.

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

В. Шаталов: Для достижения взаимопонимания между заказчиком и поставщиком услуг необходимо, чтобы поставщик не только четко понимал все потребности заказчика, но и умел предвосхитить такие потребности хотя бы на один шаг вперед. К сожалению, это далеко не всегда возможно, ибо зависит от «зрелости» обеих сторон. Важным элементом в установлении взаимопонимания является степень доверия к поставщику услуг. В идеале он как бы становится внутренним структурным подразделением заказ чика. Удержание взаимопонимания происходит на базе постоянного обмена информацией: от заказчика — о новых задачах и планах развития своего бизнеса, от поставщика — о новых возможностях ИТ-услуг, которые в текущей и планируемой среде заказчика окажутся наиболее эффективными.

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

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

В. Шаталов: Удачное, работоспособное SLA — это соглашение, над которым плодотворно потрудились и поставщик, и заказчик. Если процесс разработки был активным с обеих сторон, это послужит залогом хорошего понимания и сочетания и интересов заказчика и возможностей поставщика, и можно ожидать, что такой контракт будет успешным. Основные советы при разработке SLA:

> требуйте только того, что нужно именно вам;

> уделяйте внимание защите важных компонентов ИТ-инфраструктуры;

> четко определите понятия и термины;

> учитывайте наилучшие и наихудшие сценарии развития событий;

> четко оговорите штрафные санкции;

> не останавливайтесь на единожды достигнутом: требуется обязательная периодическая модернизация SLA.

Р. Сухов: Решение организационных и правовых вопросов между аутсорсером и его клиентом существенно облегчается, во-первых, если у клиента формализованы бизнес-процессы, и во-вторых, если в процессе выработки критериев оценки качества (и стоимости) услуги аутсорсера принимает участие специалист или команда специалистов, хорошо знакомых и со спецификой бизнеса клиента и тенденциями рынка современных ИКТ. Решение этой задачи можно осуществить как благодаря использованию кадровых ресурсов заинтересованных сторон, так и за счет привлечения независимых консультантов, компетентных в вопросах бизнеса, ИКТ, права. При таком подходе удастся, с одной стороны, не упустить из виду чего-то важного, а с другой — избежать конфликтов из-за необоснованного завышения/занижения стоимости услуги. А значит, и степень ответственности каждой из сторон будет наиболее адекватной. Эту работу необходимо выполнять не только на начальном этапе сотрудничества, но и по прошествии какого-то времени (периодичность определяется сторонами). Это связано с возможным изменением рыночной обстановки, а также с процессами, влияющими на бизнес-ситуацию клиента или аутсорсера. По опыту работы с потребителями услуг SDN могу сказать, что от такой модели взаимоотношений выигрывают обе стороны.

Ю. Литвинов: Ключевой момент определения реалистичных целевых уровней качества — это выяснение текущих значений показателей. Конечно, от поставщика услуг ожидают улучшения ситуации, а не сохранения статус-кво. Однако, прежде чем договариваться о стремительном взлете качества услуг, необходимо понимать, в какой степени нынешние проблемы лежат в области, передаваемой поставщику, и какова возможная скорость устранения этих проблем. Если в течение многих лет в приложения вносились изменения без анализа их влияния на надежность и целостность системы, то такую ситуацию невозможно исправить за один день.

Р. Свистунова: Чтобы избежать недопонимания, заказчик и аутсорсер прежде всего должны договориться о понятиях, которыми будут оперировать. Например, прийти к единому мнению, что каждый из партнеров будет понимать под задержкой в предоставлении сервиса, неисправностью оборудования и т. п. При этом необходимо учитывать как можно большее число факторов, которые могут повлиять не невозможность исполнения договорных обязанностей. Тогда в SLA можно будет внести понятные для обеих сторон параметры, поддающиеся измерению, а затем каким-то образом технически зафиксировать. По сути своей, SLA и будет перечнем этих понимаемых однозначно, измеряемых и фиксируемых параметров.

Ю. Литвинов: Стоит отметить характерную ошибку: при состав лении системы SLA возникает желание определить целевые уровни для всех показателей, которые только можно подсчитать. В результате поставщик услуг уделяет больше внимания цифрам, чем реальным нуждам заказчика, а заказчик не имеет ресурсов эти цифры анализировать. Набор KPI должен быть ограниченным, в него нужно вносить только действительно ключевые показатели.

Г. Ованесян: Хорошим средством от завышенных требований и цен является правильное деление всех задач по ИТ-услугам. Это позволяет корректно сравнивать предложения разных поставщиков, а также опираться на опыт других компаний по приобретению подобных услуг. Как раз сейчас в рамках комитета по стандартам и методологиям некоммерческого партнерства «Астра» мы разрабатываем единый классификатор услуг по ИТ-аутсорсингу.

И. Андрианов: Составляя SLA, следует дифференцировать уровень требуемого качества обслуживания среди элементов и сервисов своей системы: акцент должен в первую очередь делаться на гарантии функционирования критически важных узлов, сбои которых не позволяют функционировать системе целиком. Покупатель услуги вправе требовать только того, что нужно непосредственно ему, в соответствии с его реальными запросами. Так, за рубежом избалованный предложениями типовых SLA местный покупатель лишь недавно (и только благодаря кризисным явлениям) смекнул, что в значительной части того, за что он платит согласно подписанному SLA, он не нуждается. В определении цены важнейший фактор не сама услуга, а качество ее предоставления. Размер оплаты рассчитывается, лишь исходя из таких критериев, как доступность, время, необходимое на устранение сбоев, и др. Чем серьезнее проект, тем детальнее должно прорабатываться соглашение. Однако все же следует помнить, что SLA — документ, ориентированный на бизнес, поэтому он не должен содержать избыточного количества технических деталей. Все узкотехнические аспекты могут определяться, к примеру, в SLS (Service Level Specifications — спецификации сервиса) или в SLO (Service Level Objectives — задачи сервиса).

Кто и как (со стороны заказчика и исполнителя) должен следить за исполнением SLA и его адаптацией к изменению потребностей бизнеса заказчика?

А. Плетенева: По мере развития рынка ИТ-аутсорсинга сформировалась единая для всех модель взаимодействия поставщика услуг и заказчика. Для реализации аутсорсингового проекта с обеих сторон формируются рабочие группы, в состав которых входят специалисты со всеми необходимыми компетенциями — от постановки задач до выполнения и контроля работ. Хорошо, если в практике компании-провайдера выделена специальная служба сервис-менеджмента, аккумулирующая всю информацию о проектах и отвечающая за качество услуг на каждом этапе их реализации. Параметры отчетности, которую поставщик услуг обязан предоставлять клиенту, детально фиксируются в SLA. В каждом случае вид, метрики, периодичность и прочие характеристики отчетов определяются индивидуально, исходя из потребностей заказчика. Неизменной остается только цель отчетности — дать представление о полноте предоставляемой услуги.

Р. Свистунова: Если в компании-заказчике остается своя собственная ИТ-служба, то она и выступает в роли связующего звена между тем, что делает аутсорсер, и бизнес-процессами, идущими у заказчика. Задача собственной ИТ-службы тогда состоит в том, чтобы своевременно трансформировать потребности бизнеса в тех или иных ИТ-сервисах в задачи, поставленные перед аутсорсером. Ставя же такие задачи, собственная служба контролирует и качество их исполнения. Таким образом, в компании-заказчике должен быть хотя бы один человек, отвечающий за ИТ-функционал. Как правило, это ИТ-директор: на нем и лежит ответственность за то, чтобы круг работ, переданный аутсорсеру, соответствовал текущим потребностям заказчика.

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

И. Андрианов: Методологом, систематизирующим ИТ-процессы и ИТ-службу в целом, выступает CIO. Его миссия состоит в примирении бизнеса, который несет затраты на ИТ (порой очень существенные), с получаемыми от этих затрат результатами и выгодами. Именно CIO должен строить модель экономического обоснования аутсорсинга ИТ-сервисов и защищать ее перед финансовым и топ-менеджментом. В его задачи также входит выбор аутсорсинговых функций, их стандартизация, нормирование и формирование критериев оценки качества аутсорсинговых услуг. Со стороны аутсорсера ключевая фигура — сервис-менеджер, фактически сотрудник заказчика в исполнителе. Он ежедневно отвечает за качество услуг, формирует и согласовывает требования к услугам на этапе проектирования и ТКП, выступает руководителем работ на этапе внедрения и постоянно отчитывается перед заказчиком в соответствии с договорными отношениями и SLA.

В. Шаталов: Точнее, ключевыми фигурами со стороны поставщика являются, как правило, два специалиста: Account Manager и Service Manager по данному заказчику. Первый больше занимается «политическими», а второй — техническими вопросами по развитию и управлением ИТ-средой заказчика.

Р. Сухов: Основной объем ответственности за соблюдение требований, оговоренных в SLA, всегда смещен в сторону аутсорсера. Это абсолютно логично, потому что изначально аутсорсер позиционирует себя как партнера, имеющего в своем распоряжении технические, кадровые и административные ресурсы, превосходящие по своему уровню то, чем располагает клиент. А вот о том, кто возьмет на себя мониторинг текущей ситуации, стороны могут договориться по своему усмотрению. Отметим значимый момент. Когда речь идет о взаимоотношениях владельца коммерческого дата-центра и его клиента, важно понимать, какое место занимают бизнес-процессы, происходящие на стороне ИТ-аутсорсера, в цепочке факторов, влияющих на качество конечного продукта/услуги. В идеале кто-то должен взять на себя ответственность за согласование «промежуточных» параметров, характеризующих качество бизнес-процессов на «стыках». По сути, такая работа является особой — организационной — формой аутсорсинга, а SLA, которое составляется в этом случае, можно назвать «сквозным». Так, обсуждая условия предоставления услуг крупным корпоративным клиентам, мы сегодня заявляем о своей готовности выступить в роли организационно-интегрирующего звена. И эта инициатива все чаще вызывает заинтересованность.

Р. Свистунова: На мой взгляд, определение уровня качества предоставляемых услуг лучше возложить на специальную рабочую группу, формируемую из представителей заказчика и аутсорсера. Такая группа должна проводить проверки соблюдения договорных обязательств и SLA, и если необходимо, предлагать изменения в контрактные документы.

Как заказчику правильно распределить полномочия между собственными и внешними ИТ-специалистами? Каковы средства контроля и мотивации собственного ИТ-подразделения в модели аутсорсинга?

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

Ю. Литвинов: В идеале собственный персонал заказчика должен заниматься управлением спросом (Demand Management) и управлением взаимоотношениями с исполнителем. Пограничной областью является бизнес-анализ и управление проектными работами. Заказчики иногда хотят сохранить эту функцию у себя, чтобы избежать утечки экспертизы и зависимости от поставщика. Работа по конкретным запросам, конфигурационное управление, управление проблемами и прочие технические дисциплины остаются внешним специалистам. На практике в распределение обязанностей, особенно в пограничной области, вмешивается человеческий фактор — наличие людей с соответствующей квалификацией у поставщика или исполнителя.

Р. Свистунова: На разделение полномочий часто влияют и такие субъективные факторы, как взаимное доверие заказчика и аутсорсера, степень компетентности аутсорсера и степень готовности заказчика переложить на плечи сторонней организации оказание как можно большего числа ИТ-услуг. Может быть и так, что на откуп сторонней организации будет отдано все обеспечение заказчика ИТ-функционалом, за исключением контроля качества выполняемых работ.

И. Андрианов: Часто решение в пользу аутсорсинга бывает трудно принять из-за сомнений в надежности партнера. Развеять их могут лишь умело составленный договор, регламентирующий права и обязанности сторон, положительный опыт сотрудничества с заказчиками (success story), а также собственный сотрудник, отвечающий за координацию взаимодействия с компанией-аутсорсером. Последний фактор иногда бывает одним из самых главных. Вот почему на этой позиции в организации хотелось бы видеть профессионала, владеющего всем спектром вопросов и, естественно, хорошо мотивированного. Кстати, и мотивация собственных сотрудников перестает быть проблемой при сокращении затрат на непрофильные виды деятельности. А это ведет к повышению лояльности персонала и заинтересованности в конечном результате, а также к снижению рисков в работе организации.

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

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

> аутсорсер не должен дублировать функционал собственной ИТ-службы;

> необходимо распределить все работы по поддержанию работоспособности корпоративной ИТ-системы, а задач, за выполнение которых никто не отвечает, остаться не должно.

В ведении заказчика, тем не менее, всегда остаются функции управления, контроля качества работ, а также планирование и бюджетирование.

Насколько остры на сегодняшний день юридические аспекты аутсорсинговой деятельности? Как грамотно организовать защиту интересов заказчика и поставщика?

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

И. Андрианов: Опасения российских заказчиков перед аутсорсингом пока отчасти оправданны. Если посмотреть типичные договоры наших европейских коллег, то мы увидим внушительные тома, состоящие из сотен страниц, на 90% которых описывается не то, как предоставляется сервис, не пункты SLA, а условия и гражданская ответственность страховки. На Западе все риски, как правило, застрахованы. А в российском Гражданском кодексе пока вообще не предусмотрена ответственность за некоторые риски. И никакая страховая компания не оформит страховки на то, что сейчас по факту требуется заказчику.

В. Шаталов: Интересно, что понятий «аутсорсинг» и «договор аутсорсинга» нет в российском законодательстве. В силу этого к таким соглашениям применяют положения Гражданского кодекса РФ о договоре возмездного оказания услуг.

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

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

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

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

В. Шаталов: Мол, «они профессионалы, сами знают, что надо делать».

Ю. Литвинов: Совершенно верно! В результате исполнитель сталкивается с требованиями, которые ему кажутся чрезмерными и необоснованными.

В. Шаталов: Поставщик может «биться как рыба об лед», выполняя то одну, то другую прихоть заказчика, но в целом так и не достичь ожидаемого от него уровня сервиса: «не смог угадать».

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

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

Г. Ованесян: Можно сказать, что в проектах аутсорсинга возможны практически все риски, которые в принципе возможны в проектах, связанных с ИТ. Все и всегда предусмотреть, конечно, нельзя. Мы рекомендуем отстраивать такие взаимоотношения между заказчиком и поставщиком, в рамках которых необходимый перечень рисков предусмотрен в SLA, а постоянное взаимодействие сторон позволяет вовремя идентифицировать и находить противодействие возникающим рискам. Однако даже в SLA невозможно прописать риски на все случаи жизни; потребуется гибкость и партнерские взаимоотношения сторон.

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

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

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

> быть партнерами, а не просто клиентами. Отношения должны строиться как долгосрочные и взаимовыгодные;

> принять сложность рынка и научиться извлекать из нее выгоду. Обилие подрядчиков, разнообразие их предложений должно не пугать и запутывать клиента, а восприниматься им как широкий выбор возможностей, которым нужно умело воспользоваться для подбора оптимального партнера;

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

Статья опубликована на
cio-world
Все права сохранены


Помогите своим коллегам быть в курсе интересных новостей! Поделитесь!
Документ без названия


 

Приглашаем принять участие
в воркшопе ITSM Labs
баннер


баннер


баннер


Партнеры itSMF России



 Директор информационной службы
 

Information Management

Открытые системы



Московское отделение ISACA

ABPMP Russian Chapter

GlobalCIO

СоДИТ

SPb CIO Club — партнер itSMF России

Высшая школа бизнес-информатики Государственного университета – Высшей школы экономики (ВШБИ)

МИИТ

ГУУ

Московский государственный университет экономики, статистики и информатики (МЭСИ)

Факультет ВМК МГУ имени М.В. Ломоносова

Московский институт электроники и математики (МИЭМ)

Институт информационных бизнес систем



Блоги: