| Рубрикатор |  |
 |
Реклама
| Статьи |  |
ИКС № 3 2007 | |
|
Профессиональное сопровождение
Пройдем след в след по пути аутсорсинга вместе с профессионалами этого рынка: предмет и функции аутсорсинга, зоны ответственности заказчика и исполнителя, возможные подвохи при составлении SLA и другие «грабли», которых следует опасаться обеим сторонам. Итак, аутсорсеры ИТ-рынка: ВСС, IDS-Scheer, EPAM Systems, Energy Consulting Integration, Digital Design, Siemens, Naumen, R-Style, WideXs, «БиЭйСи», MERA Networks, «Мастертел», ГК «Талгар», «Квазар-Микро», «Открытые Технологии», «Информзащита», АРС, «ДиалогНаука».
«ИКС»: Какие ИТ-функции лучше брать на аутсорсинг, а какие оставлять в ведении заказчика?В. БЕЛИКОВ («БиЭйСи»): Передавать на аутсорсинг можно все, что не относится к основной сфере деятельности компании. Обслуживание стратегических бизнеспроцессов следует возложить на штатных сотрудников, тогда как выполнение операционных функций и задач можно и нужно передать сторонним специалистам.
Л. ГОДЗИКОВСКИЙ (ГК «Талгар»): Нельзя отдавать на аутсорсинг критически важные для предприятия приложения; направления деятельности и ИС, которые по причинам конфиденциальности, высоких требований к оперативности или другим причинам нежелательно поручать внешним организациям, например ИС оперативного управления, информационную безопасность и т.п. Сказанное не означает, что внешние фирмы не могут быть привлечены в качестве соисполнителей этих работ.
К. ПОПРАВКО (Naumen): Я бы предпочел говорить не об ИТ-функциях, а об ИТ-сервисах. Сам сервисный подход упрощает рассмотрение целесообразности аутсорсинга того или иного сервиса. Если заказчику не удалось сформулировать какие-то функции в сервисной терминологии, значит, ему рано думать об их аутсорсинге. Рассмотрим два критерия «передаваемости» сервисов на аутсорсинг. Первый критерий (условно назовем его рыночным): на сервис, который отдается на аутсорсинг, должен быть (или предполагаться) спрос со стороны разных клиентов и предложение со стороны разных поставщиков. В противном случае при передаче на аутсорсинг «нерыночного» сервиса возникают «монопольные» отношения между поставщиком и потребителем, а это никогда не ведет к повышению экономической эффективности. Второй важный критерий – степень вовлеченности ИТ-сервиса в реализацию стратегии, или отнесение сервиса к ключевым (или, как еще говорят, стратегическим). Например, если компания в качестве конкурентной стратегии выбирает «фокус на взаимоотношения с клиентом», система CRM становится носителем основных ноу-хау компании, она развивается одновременно с развитием услуг компании и обеспечивает реализацию конкурентной стратегии через накопление знаний о клиенте и повышение эффективности взаимоотношений. Сервис системы CRM – ключевой, и он не может передаваться на аутсорсинг – ни один аутсорсер не будет успевать за таким клиентом. Если же компания реализует конкурентную стратегию лидерства в продукте или в издержках, сервисы CRM можно смело отдавать на аутсорсинг. «ИКС»: Как правильно распределить зоны ответственности между аутсорсинговой компанией и внутренней ИТ-службой компании?
Л. ГОДЗИКОВСКИЙ: Это самая сложная задача. Обычно эти зоны ответственности напоминают слоеный пирог, и именно на стыках проявляются сложности управления. Один из наших клиентов, начальник ИТ-службы КБФГ, четко сформулировал различие интересов аутсорсера и ИТ-службы: «Талгар» хочет поскорее получить реальные результаты и задает жесткие темпы работ, а мои специалисты, понимая свою ответственность за дальнейшую поддержку системы, не торопятся и хотят получить как можно более широкую функциональность». Здесь речь идет об организации работ, когда аутсорсер отвечает за реальные результаты, но если у аутсорсера почасовые ставки, может сложиться и диаметрально противоположная ситуация. Общих рецептов управления аутсорсерами не существует. Чем дольше аутсорсер работает на конкретное предприятие, тем лучше он знает и учитывает его специфику, но, с другой стороны, возникает эффект «привыкания и примирения», который может в каких-то случаях снизить эффективность совместных работ. Лучший способ «встряхнуть» ситуацию – провести квалифицированный ИТ-аудит в соответствии со стандартом COBIT.
А. ГАВЕРДОВСКИЙ (ЕРАМ Systems): ИТ-служба должна быть эффективным мостом между аутсорсером и бизнесом. Ее ценность в том, что она понимает бизнес компании, может лучше, чем сторонняя структура, трансформировать потребности бизнеса в ИТ-функции и эффективно построить коммуникации. Если ИТ-служба не понимает бизнеса компании, она становится внутренним врагом, который только мешает развитию. Вторая важная вещь – ИТ-подразделение, выступая заказчиком для аутсорсера, должно осуществлять контроль качества его услуг. 
А. КОПТЕЛОВ («IDS-Scheer/Логика бизнеса»): Лучше говорить не о распределении задач, а о построении процессов, в которых будут участвовать как внутренние специалисты, так и специалисты аутсорсинговых компаний. Распределение ответственности и способы контроля в рамках процессов нужно закрепить в SLA, однако перед этим необходимо формализовать процессы ИТ-подразделения. И. ЗВЕРЕВ («Открытые Технологии»): Варианты распределения обязанностей могут быть разными и зависят от целей, задач и характера оказываемых услуг. Тем не менее следует избегать двух крайностей: когда функционал аутсорсера будет в чем-то дублировать функционал внутренней ИТ-службы и когда в результате раздела функций останутся так называемые бесхозные функции, ответственный за исполнение которых так и не определился. Разграничить ответственность лучше всего на ранних этапах проекта и обговорить подобные вопросы во время составления SLA. Чем грамотнее будет составлено соглашение, тем меньше неопределенностей возникнет в процессе реализации проекта.
Н. КОРОБКОВА (MERA Networks): Ответ на этот вопрос зависит от масштаба решаемых задач, от стадии развития отношений и степени доверия заказчика к аутсорсинговой компании, от уровня компетентности аутсорсинговой компании. На наш взгляд, аутсорсинговая компания должна обладать не меньшей, а желательно большей компетенцией в передаваемом проекте или процессе. Если такой компании на рынке нет, значит, вопрос об аутсорсинге данного процесса ставить преждевременно. Кроме того, в классическом варианте любой процесс, передаваемый в ведение аутсорсинговой компании, должен быть сначала проработан и описан заказчиком с точки зрения требований к результату и его связей с другими процессами. Д. ОРЛИНКОВ (Siemens): В ведении заказчика в любом случае остается управление обслуживающими организациями, а также планирование и бюджетирование. Решение о том, насколько глубоко аутсорсинг входит в собственные процессы компании, принимается в зависимости от ее бизнес-стратегии.
С. БАРЫШЕВ (R-Style): Как правило, дележка функций и является теми самыми «граблями», на которые все наступают. Этого можно избежать лишь путем диалога с заказчиком, умением слушать и договариваться. Порой приходится буквально на пальцах разъяснять некоторые моменты. Если все эти механизмы расписать достаточно подробно (кто, когда, как, при взаимодействии с кем, в какой срок и что именно делает), то впоследствии можно будет избежать многих конфликтных ситуаций. Только после этого следует приступать к подготовке документов, которые закрепят принятые решения.
«ИКС»: Каких подводных камней следует остерегаться при составлении SLA?
А. КОПТЕЛОВ: Сложность не столько в составлении SLA, сколько в неготовности бизнеса им пользоваться. Часто ИТ-подразделение уже готово перейти на формализованные отношения, а бизнес-подразделения не видят в этом необходимости – и тут важно повышать зрелость бизнеса в вопросах ИТ.
И. ЗВЕРЕВ: Библиотека передового опыта ITIL рекомендует составлять SLA с учетом задаваемых контролируемых параметров по каждому процессу предоставления сервиса (управление инцидентами, управление уровнем сервиса, управление доступностью и др.). Затем, в процессе оказания услуг аутсорсинга, необходимо на регулярной основе производить оценку достигнутых параметров и сравнивать их с заданными в SLA. Такое сравнение позволит вовремя выявить позитивные или негативные тенденции, включить механизм системы компенсаций за недостигнутый или, напротив, более высокий по сравнению с SLA уровень сервиса. А. ГОЛОВ (Energy Consulting Integration): Если заказчик все-таки решил воспользоваться услугами аутсорсинга системы ИБ, особое внимание в контрактах по аутсорсингу ему надо обратить на следующие моменты:
- юридические вопросы соответствия законодательству, например в части сохранности персональных данных (особенно актуально для бизнеса e-commerce);
- вопросы ответственности, в том числе и субподрядчиков компании-аутсорсера;
- каким образом компания-аутсорсер предполагает обеспечивать конфиденциальность, целостность и доступность обрабатываемой, хранимой и передаваемой информации, какие логические и физические средства контроля и контрмеры будут задействованы;
- какие сервисы и как будут поддерживаться в случае возникновения чрезвычайных ситуаций;
- возможность проведения независимого аудита третьей стороной (например, в соответствии со стандартом SAS 70).
Т. ВЕКИЛОВ («Квазар-Микро»): Нередко бывает, что SLA соблюдается, а заказчик неудовлетворен. В таком случае подрядчик должен приложить максимум усилий, чтобы разобраться в ситуации. Как правило, неудовлетворенность заказчика при формальном соблюдении SLA связана с неоправдавшимися, но не зафиксированными в SLA ожиданиями от аутсорсингового контракта. При составлении SLA нужно предусмотреть два ключевыхмомента: во-первых, регламенты решения нестандартных ситуаций (например, регламенты внесения изменений в SLA); во-вторых, возможные риски, их значимость и способы управления ими. Нужно учитывать, что все ситуации в SLA отразить невозможно, поэтому клиент и аутсорсинговый партнер изначально должны быть настроены на сотрудничество, а не использовать SLA как способ отгородиться друг от друга.
К. ПОПРАВКО: Подводные камни лежат, как правило, в области формулировок и процедур. Важно четко согласовать, что считать простоем или недоступностью сервиса, как учитывается время простоев, как считаются итоговые показатели доступности. В нашей практике были случаи, когда не работающий у клиента сервис не приводил к ухудшению показателей доступности – настолько неадекватна была методика расчета. Следует обратить внимание и на так называемые «групповые инциденты». Это сбои, затрагивающие нескольких пользователей. Методика расчета коэффициентов доступности обязательно должна включать в себя количество затронутых проблемой клиентов: чем больше затронуто клиентов, тем сильнее снижается целевой показатель качества или доступности.
М. САВЕЛЬЕВ («Информзащита»): Надо стараться избегать неточностей и недосказанностей, возможности по-разному толковать положения SLA. Полностью избежать этого нельзя, но при обнаружении таких пунктов их необходимо как можно быстрее оговаривать и согласовывать. Согласно законам Мерфи, больше всего следует опасаться пунктов, которые на первый взгляд кажутся однозначно понятными. В первой же конфликтной ситуации вы убедитесь, насколько по-разному можно трактовать каждое слово соглашения. 
В. БАРАКИН (ВСС): Зачастую проблема кроется в понятиях «время реакции» и «время выезда». Под временем реакции понимается время, прошедшее после фиксации заявки у поставщика услуг до первых действий инженера. Это время непросто измерить, равно как и время, затраченное на выезд. Не говоря уже о том, что во многих договорах не оговаривается, в каком случае и как быстро инженер должен понять, сможет ли он решить задачу удаленно или необходим выезд на территорию заказчика. Отдельно стоит заострить внимание на очень тонком вопросе: что будет, если непосредственные действия инженера аутсорсинговой компании или его рекомендации приведут к краху ИТ-систем и остановке бизнес-процессов?.. В договорах на техническую поддержку эти моменты описывают по-разному. Как правило, есть система штрафов. А отдельные страховые компании могут застраховать заказчика или поставщика услуг от возникновения нештатных ситуаций. 
А. КОНЯЕВ (АРС): При составлении контракта должно быть оговорено, какую ответственность за финансовые потери в связи с неоказанием или некачественным оказанием ИТ-сервиса заказчику несет аутсорсинговая компания. Ю. ПРОХОРОВ (WideXs): Особенно важно иметь градации нарушения качества со штрафными санкциями, а также предусмотреть правильный выход из договора.
С. БАРЫШЕВ: Основные проблемы начинаются, как правило, при взаимодействии (проработка регламента, времени и способов взаимодействия) и при решении недокументированных проблем, которые нельзя расписать в регламенте. В любом случае все предусмотреть нельзя. И здесь решением может стать введение в проект должности так называемого конфликт-менеджера, который будет обладать полномочиями принимать итоговое решение по конфликтным ситуациям. Второй момент: при составлении SLA важно выяснить точную потребность заказчика. Большинство из них на всякий случай хотят «все и навсегда», что, безусловно, дорого. А ведь зачастую им не требуется самый высокий уровень сервиса или надежности для успешной и плодотворной работы, а вполне достаточно, к примеру, среднего уровня надежности и обслуживания, что обходится гораздо дешевле. Очень важно на этом этапе подобрать оптимальный вариант по соотношению цена/качество. 
А. САМОДУРОВ («Мастертел»): Что касается рисков, то мы, например, стараемся максимально обговорить все пункты в договоре с клиентом. В моей практике уже были прецеденты, когда клиенту требовался больший объем услуг, чем тот, о котором мы первоначально договорились. Риск обращения к ИТ-аутсорсингу, с точки зрения клиента, заключается в том, что он боится получить некачественные услуги. Это во-первых, а во-вторых, ему нужно быть уверенным в том, что будут покрыты его насущные потребности в ИТ. Так что договор – лучший способ подстраховки. «ИКС»: Как посчитать эффективность ИТ-аутсорсинга?
А. КОНЯЕВ: Это извечный вопрос. Можно сравнить стоимость содержания и технической подготовки собственного ИТ-персонала (на срок разработки и внедрения проекта) со стоимостью контракта на аутсорсинг с учетом рисков. Ведь главный мотив аутсорсинга – получить ИТ-услуги требуемого качества, заплатив за них меньше, чем при использовании для этого внутренних ресурсов. И если это достигнуто, то эффективность очевидна.
Д. ОРЛИНКОВ: Эффективность любых изменений в компании может быть оценена только тогда, когда ее бизнес-процессы описаны и измеримы. В этом случае каждый value имеет стоимостное выражение. Тогда эффективность аутсорсинга можно посчитать по параметру «полная стоимость владения». 
В. СЕРДЮК («ДиалогНаука»): Эффективность аутсорсинга задач по информационной безопасности (ИБ) легко рассчитать на основе соответствующих финансовых показателей. Один из основных показателей – сумма денег, которую организация может сэкономить за счет делегирования части задач внешней аутсорсинговой компании. При этом экономия может выражаться в следующем: сокращение штата специалистов, отвечающих за обеспечение ИБ компании; сокращение затрат на обучение по вопросам ИБ; сокращение затрат на закупку дорогостоящих средств защиты информации. 
В. БЕЛИКОВ: Эффективен ИТ-аутсорсинг или нет, по-моему, нужно оценивать на основании того, соответствует ли выполненная работа стратегии компании заказчика. Без понимания заказчиком целей трансформации потребления услуг, поставляемых извне вместо производимых внутри организации, невозможно говорить об эффективности. Если понимание достигнуто, можно применять подходы, базирующиеся, например, на соответствии фактических расходов плановым, согласованных метрик фактическим или посложнее – влиянии ИТуслуг на бизнес-показатели ключевой деятельности заказчика.
А. ТАМПЕЛЬ (Digital Design): Эффективность аутсорсинга можно считать в различных разрезах, в зависимости от того, что для заказчика имеет наибольшую важность. Это могут быть экономия финансовых средств, показатели удовлетворенности персонала, пользующегося услугами, суммарное время простояв работе специализированных систем, количество выполненной работы в единицу времени, качество выполненной работы и т.д. Финансовую эффективность подсчитать сложнее всего, так как при использовании внутренних ресурсов существует масса скрытых расходов. А. ГАВЕРДОВСКИЙ: Есть два подхода к оценке эффективности – сравнивать производительность и сравнивать затраты. Часто в реальности сравнить это просто невозможно, потому что нет практики расчета внутренних затрат на ИТ – компании не знают, сколько стоит час их штатного ИТ-специалиста и сколько денег он приносит компании. Пока этого нет, говорить об эффективности сложно.
Ю. ПРОХОРОВ: Эффективность должна подсчитываться по-разному в разных случаях. Однако принцип должен состоять скорее в оценке упущенной выгоды при отсутствии аутсорсинга, чем просто по оценке затрат. С. БАРЫШЕВ: Оценить эффективность в принципе невозможно. Можно посчитать затраты на оборудование, персонал, можно вычислить (в абстрактных единицах) удовлетворенность уровнем сервиса. Но увязать на одной шкале повышение/понижение качества обслуживания, снижение/увеличение внутренних расходов, повышение капитализации компании, удовлетворенность/неудовлетворенность, экономию рабочего времени или часы простоя – нельзя. Эффективность в данном случае – понятие глубоко субъективное.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Адрес: 105082, Россия, г. Москва, 2-й Ирининский пер, д. 3