Одна из ключевых задач в рамках модели аутсорсинга — поиск единого понимания содержания услуг заказчиком и поставщиком. Достигнуть взаимопонимания и постоянно его удерживать помогает SLA (Service Agreement Level, соглашение об уровне сервиса).
В рамках модели аутсорсинга очень важно установить общие правила деятельности, обеспечивающие единую нормативную и методическую основу для эффективного взаимодействия специалистов функциональных подразделений заказчика и внешнего сервис-провайдера в процессе создания, внедрения, эксплуатации и сопровождения ИТ — как по организационным, так и техническим вопросам. Следование этим требованиям позволит создавать модели аутсорсинга, отличающиеся высоким качеством информационной поддержки бизнес-процессов организации заказчика, а также низкими эксплуатационными затратами.
В первую очередь на старте взаимоотношений нужно четко и однозначно определить задачи клиента, перечень, объем и характеристики предоставляемых услуг, а также все подразделения, ответственных сотрудников и их действия в различных ситуациях в процессе выполнения соглашения. Если еще «на берегу», до начала проекта получить его максимально ясную картину, то можно избежать множества трудностей. Резонно ожидать, что специалисты провайдера и заказчика должны грамотно формировать требования к услугам. Однако зачастую заказчик не может четко выразить, какие именно работы он ожидает получить от аутсорсера и с какими параметрами. Потому аутсорсер должен обладать достаточной компетенцией, чтобы суметь провести декомпозицию общей задачи на все необходимые составляющие, из которых и будет состоять услуга, и которыми будет определяться ее стоимость. При этом в SLA нужно представить и описание бизнес-результата услуги (чтобы избежать классического диалога «К пуговицам претензии есть?»), и полную спецификацию всех видов деятельности, которые будут выполняться аутсорсером в интересах заказчика. Такая детализация позволит в дальнейшем варьировать спецификацию услуги в зависимости от оценки бизнес-результата заказчиком.
Помимо этого, необходимо определить периодическую процедуру оценки качества услуги и пересмотра SLA. «Всегда нужно искать поставщика, способного «человеческим языком» описать свои услуги, уровни надежности и доступности, зависимость стоимости услуг от их качественных характеристик, — советует Сергей Аулов, заместитель руководителя департамента информационных сервисов компании IT ENERGY — Ведь не секрет, что поставщик по сути — технарь, а заказчик — бизнесмен, чаще всего не владеющий технологической составляющей ИТ. Конечно, идеальный вариант, когда в компании заказчика есть отдельный человек, разбирающийся и в ИТ, и в собственном бизнесе, так называемый представитель заказчика, но это не всегда возможно, особенно в небольших компаниях. В любом случае поставщик услуг не должен быть пассивен: его задача — помочь заказчику разобраться с потребностями его бизнеса в определенных ИТ-услугах, ранжировать эти услуги, помочь выработать к ним требования по надежности, доступности, уровню предоставления. Постоянное взаимопонимание возможно только в том случае, если каждая из сторон попытается хоть немного понять оппонента и не будет пытаться «перетянуть одеяло» на себя. Это подразумевает, что поставщик услуг не будет просить заоблачные деньги, а бизнес не будет пытаться получить даром все и сразу!»
При выборе поставщика услуг желательно узнать, какие организации являются или являлись его клиентами. Это даст возможность понять, с компаниями какого уровня работал аутсорсер, а также его отраслевую специализацию, если таковая присутствует.
Еще одна важнейшая причина внимательно относиться к составлению SLA — опасения заказчиков относительно утечки конфиденциальной информации. Особенно актуально это при работе с критически важными бизнес-процессами, связанными с информацией о клиентах компании-заказчика. «Аутсорсер должен уделять особое внимание ответственности за неразглашение конфиденциальной информации, — подчеркивает Михаил Лагутин, руководитель отдела аутсорсинга транзакционных бизнес-процессов компании «Xerox Россия». — Это условие также диктуется законодательными и регулирующими документами стран, в которых мы оказываем услуги клиентам». Однако в стремлении к информационной безопасности бизнес подчас переходит границы разумного, практикуя максимальную закрытость ведения дел. Такой подход не будет способствовать взаимопониманию поставщика услуг и заказчика. Поэтому желательно, чтобы заказчик максимально открыто обрисовал поставщику услуг свои бизнес-цели, описал внутренние технологические процессы, расставив их по приоритету и важности для бизнеса. «В идеале заключению SLA должна предшествовать работа по построению процессной модели ведения бизнеса в соответствии с подходами, изложенными в ISO 9000/9001», — подчеркивает Сергей Аулов.
— В случае же, если заказчик, борясь с рисками, хочет самостоятельно участвовать в определении спецификации услуги, помочь ему организовать эту работу может описание моделей сервисных активов, агентского взаимодействия и сервисных архетипов, вместе с методологией определения спецификации услуг приведенные в книге «Service Strategy» третьей версии ITIL, — говорит Александр Грошев, аналитик-консультант компании Digital Design.
Что включать в SLA С точки зрения законодательства обязательными в соглашении являются описание предмета услуги, сроков ее оказания и цены. Но, конечно, для целей взаимопонимания, снижения рисков и заказчика, и аутсорсера и повышения качества услуги важно указать целый ряд дополнительных параметров: > бизнес-результат для заказчика; > форму и место предоставления услуги, ее функциональные характеристики и способ доступа к ней; > количество и расположение пользователей; > время доступности и поддержки пользователей; > максимальное время восстановления услуги в случае инцидента; > период предоставления; > единицу измерения услуги и ее цену; > порядок и периодичность пересмотра SLA, граничные условия для запуска пересмотра вне расписания (превышение количества пользователей, объема трафика, отказ от услуги и пр.).
Список ИТ-услуг должен содержать детальное описание их состава, перечень технических средств, список пользователей — потребителей услуги. Далее необходимо согласовать конкретные параметры предоставления услуги — качественные и количественные. Параметры напрямую соотносятся с бизнес-требованиями: сколько часов в сутки необходим тот или иной уровень предоставления услуги, только ли в рабочее время или круглосуточно — например, если компания имеет территориально распределенную структуру; каково среднее и максимальное время отклика в том или ином приложении; каково допустимое суммарное время простоя или среднее за определенный период и т. д. Одновременно оговаривается порядок предоставления отчетности и процесс устранения неполадок. «При разработке SLA следует максимально ориентироваться на требования компании-заказчика и услуги, необходимые для функционирования ИТ- и других систем, — подчеркивает Леонид Гуштуров, генеральный директор ОАО «КОМКОР» (торговая марка «АКАДО Телеком»). — Самое главное — чтобы заказчик четко понимал, что он хочет и какие деньги готов за это заплатить».
В контракт рекомендуется заложить степень гибкости с точки зрения объемов. — Например, в нашей практике есть контракт, по которому мы обслуживаем 20 тысяч пользователей, однако если их число вырастет на 5%, то стоимость работ для заказчика не изменится, а SLA сохранится, — поясняет Вадим Стеценко, руководитель дирекции ИТ-аутсорсинга компании «Астерос». — С другой стороны, на определенную гибкость должен идти и заказчик. Работая с одним клиентом, мы сразу знали, что раз в месяц могут происходить сбои, и в эти моменты образуется пик нагрузки на службу поддержки. В этом случае у заказчика есть два пути. Первый — допускать на время пика снижение SLA. Второй — покупать у поставщика более дорогой сервис, который в «мирное время» избыточен, зато покрывает пиковые нагрузки.
Особенно внимательно надо отнестись к порядку восстановления после аварии или сбоя. Здесь необходимо описать и рассчитать время реакции на инцидент, время прибытия технического специалиста и полное время восстановления предоставляемой ИТ-услуги. «В SLA всегда должен присутствовать порядок проведения регламентных работ, — напоминает Сергей Аулов. — Грамотный поставщик услуг никогда не забудет об установке обновлений, сервисных пакетов или просто о профилактике и обновлении своего оборудования. Для всего этого необходимо время — и очень часто с прерыванием предоставления услуги. Под эти работы необходимо отвести периоды наименьшей загруженности — выходные дни или ночное время суток».
Не стоит забывать и про формулу расчета времени простоя, хотя иногда можно обойтись и без сложных расчетов, если грамотно описать уровни предоставления сервиса. Естественно, она необходима, если речь пойдет о штрафных санкциях поставщику услуг за нарушение требований, изложенных в SLA.
Финансовая-юридическая составляющая данного документа не менее важна, чем все остальное. Сюда входит описание и порядок платежей за предоставление сервиса, ответственность сторон, порядок возмещения убытков, адекватный причиненному ущербу.
Еще один обязательный этап в аутосорсинговых проектах — работа с рисками. Понятно, что невозможно предусмотреть все форс-мажо-ры, но смоделировать ситуацию возникновения рисков, определить их значимость, коэффициенты вероятности и методы управления необходимо. Опыт аутсорсера помогает еще до старта проекта предусматривать возможные проблемные зоны в SLA.
Эдуард Гатиятуллин, директор департамента развития сервиса и аутсорсинга Сервисного центра компании «Ай-Теко», обращает внимание, что в SLA обязательно должны присутствовать механизмы фиксирования, обсуждения и разрешения конфликтных ситуаций. Для этого необходимо обратить особое внимание на разграничение ответственности за контроль качества услуг, включая наличие критериев измерения качества, согласованных обеими сторонами, формы и периодичность отчетности, описание ролей и обязанностей рабочих групп, обладающих соответствующими уровнем полномочий и управляющих процессами со стороны сервис-провайдера и со стороны заказчика.
Наконец, в SLA закрепляются финансовые обязательства сторон в случае нарушения соглашения и порядок юридических действий по его урегулированию. Эту часть SLA не все аутсорсеры трактуют одина- ково. Так, например, эксперты Digital Design не считают, что введение штрафных санкций за нарушение SLA — это верный путь регулирования отношений. Во-первых, часто трудно рассчитать и обосновать размер штрафа на основе негативного эффекта от нарушения SLA. А во-вторых, штрафы — фактор ограничения, а не стимулирования или мотивации, и в долгосрочной перспективе они не способствует развитию партнерских отношений. Рыночная конкуренция и прописанные в SLA возможности для его пересмотра или прекращения действия предоставляют заказчику достаточно возможностей для выбора лучшего предложения.
— Первая версия SLA, как правило, неточна и в дальнейшем подвергается серьезной доработке, — делится опытом Вадим Стеценко. — Чтобы более качественно определить потребности в сервисе и сделать безболезненным перевод процессов на аутсорсинг, мы рекомендуем запустить пилот на одну-две услуги. Обычно такой тест-драйв позволяет снять многие вопросы и уточнить параметры SLA и стоимость предоставления сервисов. В дальнейшем желательно, чтобы SLA было сформировано с некоторым запасом.
Говорить на одном языке Одним из препятствий к росту рынка ИТ-услуг в РФ, затрудняющим диалог потребителя и провайдера, уже в течение нескольких лет называют отсутствие одинаково понимаемой терминологии.
В SLA должны быть включены максимально точные, но в то же время понятные для бизнеса определения, касающиеся качества предоставления сервиса: например, что такое доступность, как и в чем она считается. Далее необходимо описать элементы мониторинга сервиса — что, как, в каких единицах измеряется.
Обязательно должны присутствовать определения таких понятий, как инцидент, сбой, неисправность, — возможно, с градацией по уровням.
Эдуард Гатиятуллин обращает внимание: поскольку договором на аутсорсинг управляют представители сервис-провайдера и заказчика, терминология SLA определяется в едином информационно-понятийном поле, которое должно включать такие понятия, как: > результативность, оценивающая удовлетворение потребностей клиентов; > эффективность, определяющая действенность внутренних процессов; > конфиденциальность, обеспечивающая соблюдение положений информационной безопасности; > адекватность, учитывающая соответствие состава и качества оказываемых услуг реальным потребностям; > доступность, описывающая наличие возможности использовать предоставляемые услуги; > надежность, формирующая устойчивость предоставления услуг. Если в организации заказчика нет сложившейся терминологии в данной области, то имеет смысл воспользоваться готовым глоссарием из библиотеки ITIL v3. Благодаря усилиям российского некоммерческого партнерства «Форум по ИТ Сервис-менеджменту» (itSMF Russia) он переведен на русский язык.
— Если заказчик оперирует устоявшейся в его внутренней деятельности терминологией, не совпадающей с ITIL, то в глоссарии имеет смысл привести именно ее, а для повышения взаимопонимания и переносимости услуг сделать ссылки на соответствующие определения из глоссария ITIL, — советует Александр Грошев. — Если же терминология клиента в области качества сервиса не находит аналогов среди общеизвестных источников, то стоит привести формулы и примеры для однозначности трактовок этих терминов.
Мониторинг исполнения SLA Обычно со стороны потребителя услуг создается служба заказчика, в функции которой входит управление удовлетворенностью функционального заказчика от бизнеса, отношениями с аутсорсерами, ИТ-бюджетом и затратами, инновациями в ИТ. В процессе реализации проекта по аутсорсингу именно административный офис управления должен будет обеспечивать администрирование исполнения договора на аутсорсинг, включая распространение информации о нем и оказание помощи в его понимании, проведение аудита, обсуждение изменений и контроль издержек на предмет соблюдения бюджета, обеспечение процесса исполнения договора и обновление документации, сбор и распространение отчетов о производительности и отказах, ввод и обслуживание процедуры составления счетов, оплаты.
Со стороны исполнителя обычно существует коммерческое подразделение, обеспечивающее управление отношениями с заказчиком. «Система управления ИТ-услугами аутсорсера, автоматизирующая деятельность производственных подразделений, должна автоматически обнаруживать нарушения SLA и обеспечивать хранение исторических данных для последующего совместного с заказчиком периодического анализа качества услуг, — отмечает Александр Грошев. — При критическом характере обнаруженного нарушения SLA система должна автоматически обеспечить надлежащую эскалацию как внутри производственного блока, так и в коммерческую службу и на уровень службы заказчика, если под угрозой оказались его критичные бизнес-процессы».
Отметим, что процесс предоставления услуг и его ролевая модель должны быть построены так, чтобы предусмотреть классификацию исключительных ситуаций и стандартные действия при их наступлении, дабы эскалации не превращались в постоянный информационный шум.
Полезные советы Самые ценные советы — те, что основаны на собственном опыте. Поэтому слово специалистам, принимавших участие во многих аутсор-синговых проектах.
Александр Грошев рекомендует: если перенос части услуг ИТ-департамента на сторону рассматривается впервые, то стоит составить бизнес-кейс и провести его анализ с высокой степенью детализации, чтобы оценить риски и предусмотреть различные варианты развития отношений. Первое SLA целесообразно заключить на короткий период и для ограниченного количества пользователей, не отказываясь в это время от услуг собственного ИТ-департамента, чтобы оценить правильность составленного бизнес-кейса.
Конечно, вариант с пилотным SLA не может относиться к стратегическому аутсорсингу, экономически оправданному только при многолетнем сотрудничестве в силу необходимости значительных инвестиций. Здесь, чтобы снизить риски заказчика и аутсорсера, в SLA может быть заложена возможность при определенных условиях провести обратный перенос ИТ-инфраструктуры и приложений к заказчику или другому провайдеру — с соответствующими компенсациями и штрафами.
«Самое главное — требуйте от провайдера услуг только то, что нужно именно вам, — советует Леонид Гуштуров. — Основное внимание уделяйте защите наиболее критичных для бизнеса систем и компонентов. Договоритесь с оператором о единых терминах и схеме осуществления мониторинга и контроля соблюдения SLA».
Эдуард Гатиятуллин обращает внимание: сервис-провайдер должен быть в состоянии наглядно демонстрировать управление проектом аутсорсинга, обеспечивая выполнение процессов согласно соответствующим требованиям ISO 20 000. Как и процесс управления качеством, процесс пересмотра SLA должен давать ответы на следующие вопросы: «Куда и как будет перенесена деятельность в области ИТ на следующий день после завершения договора?», «Есть ли возможность остаться с сервис-провайдером и сколько это будет стоить?», «Если услуги будут переданы другому сервис-провайдеру, какие работы по переходу следует выполнить и сколько продлится переход?», «Если услуги будут возвращены в организацию обратно, какие ресурсы необходимы и как долго продлится перемещение?».
— Чтобы понять необходимый уровень качества услуг, можно оттолкнуться от существующего и критично оценить, насколько он устраивает или нет, — говорит Вадим Стеценко. — В частности, если картина по сервису совсем туманна, то можно найти нужный уровень качества эмпирическим путем. Для этого у провайдера необходимо запросить матрицу, отражающую качество услуг и стоимость. И в рамках пилота, двигаясь от самого простого и дешевого предложения, найти целевой уровень сервиса. Стоит подчеркнуть, что нужно именно полное меню, так как оно поможет оценить предложение провайдера комплексно и даст уверенность, что в случае замены качества сервиса клиент не переплатит.
«Не стоит стремиться к большому количеству «девяток» — достижению 99,999% доступности, — уверен Сергей Аулов. — Такие показатели даются очень дорогой ценой, а для бизнеса это и не обязательно самое главное. Всегда нужно стремиться найти золотую середину — баланс между затратами и уровнем предоставления ИТ-услуг, при котором бизнес в компании может осуществляться комфортно и эффективно».
