Переход на модель аутсорсинга. Часть третья.

Posted on Monday 14 March 2011 by Rustam Sydykov

Привет, народ!

Продолжение придыдущих постов об аутсорсинге: часть первая и часть вторая. Предположим, решение об аутсорсинге принято. Хочется надеятся, что призрачные перспективы сэкономить кучу денег не были основной причиной. Как я уже говорил, финансовый отдел просто обожает аутсорсинг. Я могу сильно ошибаться, но кто-то мне говорил, что при переходе на модель аутсорсинга классификация расходов на IT  меняется с CAPEX на OPEX (с капитальных фондов на текущие траты) и это каким-то образом положительно сказывается на финансовых показателях. Поэтому еще раз подчеркну: не давайте права финансовому отделу влиять на решение об аутсорсинге, так как кратковременная финансовая выгода можешь напрочь “отшибить мозги” финансистам. Но даже если решение об аутсорсинге принято, компания еще должна решить, какой тип аутсорсинга ей выбрать:

  • Полный – аутсорсеру отдаются все компоненты IT:
    • Инфраструктура: центры обработки данных (сервера, кабельное хозяйство и другое вспомогательное оборудование);
    • IT сервисы: почта, доступ в интернет, десктопы и лептопы (не как физические устройства, а как IT сервисы: операционная система, антивирусы, средства установки приложений, средства управления рабочей средой и т.д), телефонная связь и т.п.;
    • Поддержка и управление пользователями (точнее, их учетными записями).
  • Частичная:
    • Частичный аутсорсинг инфраструктуры, серсисов или поддержки.

Дальше все проще и сложнее одновременно. Компания должна произвести “безкровную” передачу выбранных/всех IT сервисов аутсорсеру таким образом, чтобы бизнес не заметил перемен. Наверное, это самое главное в переходный период, так как это наиболее видимая для бизнес-пользователей часть. Но она и самая легкая. Гораздо сложнее добиться успешного завершения задач, которые являются предпосылками для этого перехода: контракты, список обязанностей и т.д. и т.п. Данная часть для меня не представляет особого интереса, так как это больше поле деятельности менеджеров, юридического и финансового отделов.
Единственное, что могу сказать, основываясь на своем скромном опыте: всем лучше будет, если договор об аутсорсинге будет составлен таким образом, чтобы исключить любое двоякое толкование обязанностей и ответственности сторон. Аутсорсер будет “белый и пушистый” ровно до того момента, пока компания не подпишет договор. Особенно если это “полный” аутсорсинг. После этого любые пункты, которые могут трактоваться двояко, будут пониматься обеими сторонами так, чтобы это было выгодно им, а не другому. Я уже писал про термины и недорозумения, которые могут возникнуть из-за того, что разные организации/люди могут вкладывать разный смысл. Например, в одном случае, аутсорсер и компания договорились перепроектировать структуру сервиса каталогов (учетные записи, членство в группах, политики и т.д.). Где-то в середине проекта выснилось, что компания под “сервисом каталогов” так же понимала доступ к файл-серверам и упорядочивание доступа к папками и файлам! С точки зрения аутсорсера (да и с моей тоже :)), файловые сервера имеют только косвенное отношение к сервису каталогов, но компания традиционно включала в“сервис каталогов” практически все: аутентификацию/авторизацию к приложениям, файлам и папакам на файл-серверах, дизайн десктопов и лептопов. В общем, все, что каким-либо образом использует сервис каталогов! С точки зрения аутсорсера данные сервисы лежат вне области проекта и если компания хочет включить их в проект, это означает увеличение стоимости проекта (“дэнги-дэнги давай!”), а так же смешение сроков окончания проекта на пару месяцев. Высший менеджмент компании и аутсорсера два месяца обсуждал этот вопрос, что вылилось и в задержку проекта, и в увеличение стоимости проекта даже без расширения границ работы, так как два месяца люди, вовлеченные в проект, просто занимались текущей поддержкой.
Надеюсь, я смог донести до вас важность ясного описания целей и задач аутсорсинга. Если кратко, то контракт аутсорсинга (да и любой другой контракт или соглашение о выполняемых работах) должен быть:

  1. Составлен таким образом, чтобы исключить двоякое толкование. Содержать процедуру разрешения неоднозначных ситуаций и, в идеале, давать компании больше “веса” в принятии решений о том, как должнен трактоваться тот или иной пункт. По идее, это задача аутсорсера до подписания контракта выяснить вплоть до мельчайших подробностей, что ему предстоит делать в рамках контракта;
  2. Содержать критерии, которые можно применять для оценки работы аутсорсера. Эти критерии должны позволять оценивать сервис, предоставляемый аутсорсером:
    • Качественно – “что и как” должен делать аутсорсер. Например: “Обеспечить SLA (соглашение об уровне сервиса) для корпоративной почты (<здесь по идее должна быть ссылка на документ, описывающий “корпоративную почту” как сервис, содержащий другие компоненты, обеспечивающие бесперебойную работу почты: “почтовые” антивирусы, сервера “спам-фильтры”, а так же сервисы, от которых косвенно зависит работа корпоративной почты: корпоративная локальная сеть, подключение к Интернет)”;
    • Количественно. Например: “обеспечить SLA для корпоративной почты 99.9% во время рабочих часов, “окно” для сервисного обслуживания – <время>, КПД “спам-фильтров” – 89%, время восстановления работоспособности основной (RTO) части почты как сервиса – 1 час, допустимая часть потери данных (RPO) – 1 час и т.д. Кстати, определение “рабочих часов”> – не такой уж простой вопрос, как кажется. Если компания принадлежит к одному часовому поясу – то это легко. А что если ее офисы разбросаны по всему земному шару!? :) Тогда требование “99.9% во время рабочих часов” легко может превратиться практически в 24x7 и в результате система, удовлетворяющая таким требованиям будет горааааздо дороже.

После подисания контракта на аутсорсинг наступает следующая фаза: переход с внутренней IT службы на поддержку аутсорсером. Об этом чуть попозже.

Надеюсь, я не утомил вас своим слогом :) и засим раскланиваюсь,
Рустам.

0 Responses to "Переход на модель аутсорсинга. Часть третья."

Leave a Reply