Контакты

Юрий Овчаренко: Людям, "облакам" и серверам нужно одно - чтобы о них заботились

CNews - 4 апреля 2012

Все большее количество задач переходит от внутренних ИТ-подразделений к внешним подрядчикам. Процессы поддержки и сопровождения информационных систем здесь не исключение – скорее, даже стоят в авангарде движения к аутсорсингу. Что хотят получить заказчики, обращаясь к внешним партнерам, и готовы ли те удовлетворить их требования? Зачем нужен центр поддержки и сопровождения? И почему SLA – это хорошо, но недостаточно? Об этом в интервью порталу CNews рассказывает Юрий Овчаренко, коммерческий директор компании EPAM Systems.

- Поддержка и сопровождение информационных систем - с одной стороны, аутсорсинг – с другой стороны. Когда эти процессы «находят» друг друга?

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

- Внешний подрядчик работает не бесплатно. Чем будет обусловлена экономия ресурсов, о которой Вы говорите?

- Во-первых, отсутствием комплекса временных и денежных затрат на подбор и удержание команды специалистов, организацию процессов, внедрение механизмов контроля и оценки эффективности работ. У профессионального поставщика услуг все это уже есть. Для примера: в EPAM практика сопровождения и поддержки ИТ-систем существует с 1995 года. За это время мы выделили значительные ресурсы на выстраивание процессов по лучшим методикам и стандартам качества (ITIL®, COBIT, ISO 9001, CMMI). Если раньше это направление обслуживали несколько десятков специалистов, то сейчас их более 1500. В компании действуют программы развития профессиональных компетенций сотрудников. Это наш ключевой бизнес, мы инвестируем в него и готовы это делать дальше, потому что именно такой подход позволяет гарантировать качество услуг. Для компании любой другой отрасли, если она хочет получить то же качество, придется решать тот же комплекс задач, через который прошли мы, выделять на это время, силы и средства.

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

В-третьих, экономия возможна только там, где есть прозрачность. К сожалению, не многие компании могут точно сказать, сколько времени уходит на решение каждого типа инцидентов, каков процент повторно открытых инцидентов, сколько времени оказываются недоступными для пользователей те или иные компоненты систем и т.д. Как следствие – нельзя понять, сколько ресурсов тратится на поддержку, можно ли обоснованно сократить этот объем и за счет чего это сделать. У нас данные о каждой операции заносятся во внутреннюю ИТ-систему – это помогает получать метрики по выполненным работам в различных разрезах. В итоге есть возможность – на основе точных цифр – определить наиболее проблемные места и исправить их. Это вполне может способствовать снижению затрат.

Но, помимо экономии, отмечу и другой важный момент – снижение рисков. Все то, о чем я говорил чуть раньше: наличие опыта, отлаженных технологий, профессиональной команды, современных инструментов и т.д., - помогает подрядчику заранее предотвратить львиную долю проблем, которые могут возникнуть при поддержке и сопровождении систем. В итоге заказчик получает гарантированное и управляемое качество сервиса, повышение уровня удовлетворенности бизнес-пользователей. Внутренняя команда по объективным причинам не всегда может обеспечить аналогичный результат.

- В России есть примеры, когда крупные корпорации выделяют ИТ-подразделения в самостоятельные компании. Для них, как и для аутсорсеров, ИТ становится ключевым бизнесом. Насколько в этом случае проявятся преимущества, которые Вы обозначили?

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

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

- Все зависит от задач, которые отдаются партнеру. Если нужен 1-ый или 2-ой уровень поддержки, то эффективен подход, который активно практикуется, в частности, в проектах EPAM на Западе и в России, - это создание выделенного центра поддержки и сопровождения. Что он означает? Для заказчика формируется команда специалистов – она полностью концентрируется только на его задачах. Дополнительно создается инфраструктура, необходимая для максимально качественной поддержки и сопровождения систем, определения эффективности работы и накопления знаний о бизнесе и ИТ-решениях заказчика. Четко выстраиваются процессы взаимодействия и коммуникаций между командой центра, ИТ-специалистами заказчика и пользователями. Как правило, располагается такой центр на базе регионального офиса подрядчика – в регионах лучше условия с точки зрения квалификации, зарплатных и карьерных ожиданий ИТ-специалистов. Сформированная команда (своего рода ядро центра поддержки) выполняет задачи на 1-ом и 2-ом уровнях. Кроме того, она обеспечивает накопление нужных компетенций - в результате когда в составе команды появляются новые специалисты, их «включение» в работу происходит очень быстро. На знакомство с ИТ-решениями и бизнесом заказчика тратится гораздо меньше времени.

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

- Есть смысл организовывать выделенный центр в тех случаях, когда речь идет об аутсорсинге только 3-его уровня поддержки? Все-таки сейчас 2-ой уровень и особенно 1-ый компании чаще предпочитают закрывать собственными силами.

- На самом деле ситуация меняется. Все большее количество компаний отдает внешним партнерам и 1-ый, и 2-ой уровни поддержки. Но даже если говорить только о 3-ем уровне, то и здесь создание выделенного центра может быть эффективным решением. К примеру, если у заказчика есть большой спектр информационных систем и непрерывный поток небольших по объему задач на доработку их функциональности. Такая ситуация характерна для компаний, чей бизнес меняется очень динамично и где есть потребность в постоянном улучшении сервиса для конечных потребителей. Это банки и финансовые организации, страховщики, телекоммуникационные компании, в какой-то степени ритейл и компании других отраслей. Тогда постоянное наличие под рукой команды с хорошим знанием специфики деятельности и использующихся технологий, с отлаженными процессами и инструментами для контроля эффективности работы будет очень кстати. У нас есть проекты, когда выделенный центр фокусируется только на сопровождении 2-ого или 3-его уровня и работает в тесном контакте с группами поддержки 1-ого уровня, которые находятся как у самого заказчика, так и у других подрядчиков.

Можно действовать и по такой схеме: сначала передать партнеру поддержку 3-его уровня. Если качество услуг удовлетворяет поставленным требованиям, то отдается поддержка 2-ого уровня. Если и на нем все в порядке, то можно подумать об аутсорсинге 1-ого уровня.

- Но в любом случае речь идет только о поддержке и сопровождении информационных систем? Поддержка ИТ-инфраструктуры не входит в задачи выделенного центра?

- Совсем не обязательно. Спектр задач, которые передаются в выделенный центр, определяет заказчик. Например, мы построили центр поддержки систем для глобального западного банка, в рамках которого работают две команды. Одна из них полностью сконцентрирована на поддержке ИТ-инфраструктуры заказчика. В ее обязанности входит поддержка, мониторинг, управление производительностью и сопровождение более 20 000 серверов и всей сетевой инфраструктуры компании (в режиме 24*7*365), взаимодействие с основными поставщиками аппаратного и сетевого оборудования для заказчика и т.д. Вторая команда фокусируется на технической поддержке и сопровождении приложений практически для всех направлений бизнеса банка. Так что ограничений нет.

- Можно ли отдать на аутсорсинг поддержку «облаков», о которых так много говорят в последнее время?

- Да, вполне. Об «облаках», так же как и о людях, системах или серверах, тоже нужно заботиться. Одному из своих клиентов – крупной компании сферы медиа-бизнеса – мы оказывали услуги по технической поддержке частного «облака» на базе виртуальных машин. В задачи команды поддержки «облачных» технологий EPAM Cloud входило, в частности, управление доступом, предоставление виртуальных машин и их конфигураций, управление сетью (контроль межсетевых экранов, поддержка пользователей), работа с провайдерами дата-центров для устранения проблем с физическим оборудованием, услуги по миграции и перемещению среды и т.д. Так что поддержка облаков - это такой же отчуждаемый процесс, как и поддержка классических приложений и инфраструктуры.

- При создании выделенного центра как происходит процесс передачи знаний от заказчика к аутсорсеру?

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

Конечно, у каждой компании есть свои особенности - их нужно изучить и понять. В частности, чтобы разобраться в технологиях, проводится аудит документации систем, аудит кодов, анализируются частота и критичность возникавших инцидентов и т.д. Внешним специалистам подробно объясняются организационные правила компании. Для погружения в специфику деятельности заказчика для них проводятся интервью с его сотрудниками, семинары и тренинги. На первом этапе специалисты подрядчика могут работать в составе текущей команды – это поможет за счет общения с пользователями и совместного решения задач накопить необходимую экспертизу и затем взять процессы в свои руки.

Обычно на передачу знаний уходит от нескольких недель до нескольких месяцев. Но бывает, нужно действовать в гораздо более сжатые сроки. У нас был проект, связанный с поддержкой глобальной сети web-ресурсов для одной из крупнейших мировых компаний сферы масс-медиа – это более 150 Интернет-сайтов и web-сервисов. Там сложилась ситуация, когда заказчик отказался от услуг индийской аутсорсинговой компании, которая ранее осуществляла поддержку и сопровождение, и поставил перед нами задачу в кратчайшие сроки взять эти функции на себя. На начало работы нам дали всего 4 дня, при этом просто не было никого, кто мог бы передать нам знания о приложениях. Но разобрались и справились. Сейчас для этого клиента мы успешно оказываем услуги на 2-ой линии поддержки в режиме 24*7.

- Аутсорсер в свою очередь готов поделиться своими технологиями с заказчиком?

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

Приведу пример. Одна из проблем многих компаний – плохая связь между командами разработки и технической поддержки. Нередко они находятся в разных офисах компании (и даже в разных странах) и практически не общаются друг с другом. Организация процессов, мотивация, инструментарий – все может различаться кардинально. Есть определенная разница даже в мышлении. Разработчики нередко руководствуются принципом «чем больше изменений требуется для системы, тем лучше». Для специалистов службы поддержки, наоборот, каждое внесенное изменение – это потенциальный источник появления дефектов в работе системы и жалоб от пользователей. Многих ошибок можно было бы избежать, если бы и разработчики, и специалисты поддержки работали как одна команда. Для решения этой задачи мы предлагаем заказчикам использовать подход DevOps (Development + Operations). Это комплекс методик, процессов и инструментов, применение которых помогает двум группам специалистов начать действовать совместно и продуктивно, в рамках единого процесса по удовлетворению требований бизнеса. Для повышения качества поддержки и сопровождения EPAM использует технологии проактивного мониторинга систем, которые позволяют выявлять проблемы в работе компонентов и конфигураций приложений до того, как они окажут влияние на работу пользователей. Эти технологии доступны для наших заказчиков.

- Насколько рискованно с точки зрения заказчика отдавать столь важный процесс, как поддержка и сопровождение систем, внешнему подрядчику?

- Аутсорсинг - это всегда риск, но любым риском можно управлять. Правила здесь просты и понятны. Во-первых, правильно подойти к выбору поставщика услуги. Имеет смысл посмотреть на наличие у него нужной инфраструктуры и специалистов того профиля, который требуется. Важно и тщательно проанализировать его опыт работы в этой сфере, выяснить, есть ли среди его клиентов компании той же сферы деятельности и решались ли для них те задачи, которые вы хотите отдать подрядчику. Во-вторых, четко распределить обязанности, роли и функции между привлеченной и собственной командами, подробно расписать процессы эскалации проблем и принятия решений. В-третьих, нужно обеспечить стабильные коммуникации между внутренними и внешними специалистами, научить их воспринимать друг друга как партнеров и единомышленников, а не соперников. Наконец, важно детально зафиксировать условия и параметры сотрудничества, в том числе это делается с помощью заключения соглашения об уровне услуг (Service Level Agreement – SLA).

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

- Какие возможности для оценки эффективности работы центра поддержки и сопровождения есть у клиента? SLA?

- Не только. SLA позволяет понять, справляется ли центр с требованиями заказчика. К примеру, заказчик установил, что предельное время на ответ пользователю – 6 минут, на решение небольшой проблемы – 3 часа, критичные проблемы устраняются максимум в течение дня, а на большие задачи требуется максимум 5 дней. Укладывается команда центра в эти значения? Да. Отлично, значит, работа выполнена в соответствии с тем уровнем предоставления услуг, который был нужен заказчику.

Но есть и другие вопросы. Можно ли отвечать быстрее? Снижается или возрастает количество инцидентов и по каким приложениям? Сколько в среднем уходит времени на распознавание проблемы? SLA не даст на них ответ.

- Что Вы предлагаете в дополнение к SLA?

- Мы предлагаем использовать более широкий набор показателей эффективности – метрик. Для их расчета в специальных информационных системах (это могут быть как разработки EPAM Systems, так и решения других вендоров) фиксируются все операции, которые были выполнены при поддержке и сопровождении. Затем на регулярной основе с заданной периодичностью готовится и анализируется отчетность по выбранным метрикам. Выделенный центр предполагает не разовую реализацию отдельных проектов, а долгосрочное сотрудничество, поэтому есть возможность (благодаря длительному мониторингу) увидеть более полную картину. В результате можно определить, к примеру, показатели улучшения работы – это снижение среднего времени отклика на запрос пользователя и времени на разрешение одного инцидента, сокращение общего объема инцидентов и т.д. Или, наоборот, убедиться, что эти метрики ухудшились, а значит, пора разобраться в причинах проблем и устранить их.

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

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

ITIL® - зарегистрированная торговая марка AXELOS Limited.

Оригинал публикации