In English

Сопровождение на аутсорсинге

01.10.2011, Стародумов Артем
Издание: CIO
Для крупных компаний широко применяемой практикой организации процесса эксплуатации корпоративной сети является привлечение внешних ресурсов на принципах аутсорсинга. Однако отношения с эксплуатирующей компанией в этом случае имеют свою специфику.

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

Баланс интересов


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

«Но в таком случае, – продолжает Максим, – неизбежно встает критический вопрос о защите информации, надежности доступа к информационным ресурсам. Поэтому процесс эксплуатации сети прочно связан с двумя ключевыми принципами – обеспечением функциональности и гарантиями информационной безопасности».

Давая рекомендации тем, кто стоит перед выбором, эксплуатировать сеть своими силами либо привлекать сторонние организации, Сергей Малышев, директор по развитию сетевого сервиса компании «Инфосистемы Джет», говорит:

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

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

«Подготовка собственных специалистов – не такая большая проблема, – говорит Сергей. – На обучении персонала экономить не стоит, хотя и неоправданные затраты не нужны. Компромисс в этом вопросе зависит от структуры и бизнеса заказчика».

Эксплуатация конвергенции


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

В конвергентных сетях, обращает внимание Сергей Малышев, для достижения задач совместимости иногда приходится предлагать специализированные технические решения, которые обеспечивают требуемое сопряжение разного типа сервисов. В частности, таковы решения класса Session Border Controllers – SBC (контроллеры пограничной сессии), которые устанавливаются на границах сред и позволяют решать задачи совместимости и прозрачности предоставления сервисов и их организации.

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

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

В автоматическом режиме


Эксперты рынка единодушны в вопросе о том, что плохо организованный процесс приема заявок на обслуживание корпоративной сети вызывает недовольство клиентов и даже может спровоцировать их опок. «Служба ServiceDesk дает полную картину качества работы сети, фиксирует сроки, ресурсы и является важной частью в политике экономии компании, позволяя четко планировать деятельность службы поддержки и эксплуатации, – поясняет Максим Темнов.- Даже офису из 20-30 человек с одним инженером необходима хотя бы элементарная система класса ServiceDesk для обеспечения качества эксплуатации корпоративной сети и экономии средств на обработку заявок. Ведь даже если заявка отправлена по электронной почте, ее нужно найти, выяснить суть проблемы и выделить ресурсы для ее решения. Все это занимает силы и время бизнес-подразделения. Особенно важную роль играет служба ServiceDesk для обеспечения работы внешних ИТ-служб».

Роман Котрачев, директор департамента сервисных решений «АМТ-ГРУП», напоминает о том, что ServiceDesk – служба, которая обеспечивает единую точку входа для пользователей, осуществляет взаимодействие с поставщиками услуг, координирует устранение инцидентов/проблем и выполнение запросов на сервис, контролирует соблюдение SLA со стороны поставщиков услуг. «При этом поставщиками услуг могут быть как внутренние подразделения предприятия, так и внешние компании, работающие по договорам подряда, – говорит он. – ServiceDesk необходим в случае, когда у компании есть более одного поставщика IТ-услуг».

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

Александр Левашов, руководитель отдела «Мультисервисные сети» компании «АйТи», убежден, что в крупной организации без ServiceDesk не обойтись, потому что какие-то несложные вопросы, связанные с управлением конфигурацией сети или обслуживанием запросов на изменения от пользователей, могут решаться и на стороне заказчика: служба автоматизации может реализовывать «первую линию» технической поддержки и снимать простые вопросы буквально на телефоне. «У одного из наших заказчиков, в компании «Башнефть», примерно год назад было внедрено решение класса ServiceDesk, хотя там и не шел вопрос об обслуживании сети, – рассказывает Левашов. – Эта система понадобилась для организации первой линии технической поддержки пользователей корпоративных информационных систем, в том числе системы электронного документооборота, во внедрении которой принимала участие наша компания. На второй линии технической поддержки (у компании-аутсорсера) также использовалась система класса ServiceDesk, интегрированная с системой «Башнефти». Это позволило передавать инциденты на вторую линию поддержки (аутсорсеру) в автоматизированном режиме и с минимальными задержками. Созданная при этом на первой линии поддержки база знаний позволила «снимать» до 80% запросов пользователей в ходе консультации по телефону горячей линии».

Левашов считает, что сегодня при желании практически любая компания может у себя развернуть подобную службу. «Если раньше системы класса ServiceDesk были только коммерческими, и не каждый заказчик мог себе позволить приобрести систему с широким функционалом, то сегодня существует свободное ПО, реализующее функции ServiceDesk», -поясняет он.

Работа над ошибками


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

Александр Зубков, директор сервисного центра «АМТ-ГРУП», обращает внимание на довольно типичную ошибку в процессе эксплуатации – выполнение функций поддержки эксплуатации в том же подразделении и теми же сотрудниками, которые осуществляют ее первоначальное строительство и развитие (установку нового оборудования, внедрение новых сервисов):

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

По мнению Андрея Синяченко, технического директора департамента инфраструктурных решений компании «АйТи», ошибки на стадии эксплуатации сети в основном носят организационный характер. Они часто связаны с тем, что заказчик не уделяет должного внимания вопросам взаимодействия в рамках сервисных контрактов с интеграторами, которое должно быть четко регламентировано. Заказчику необходимо составлять отчеты и по результатам года анализировать, какие затраты понесены на собственный персонал, а какие – на сервис аутсорсеров.

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

По мнению Малышева, требования, предъявляемые к механическим элементам, должны учитываться регламентами по обслуживанию: «Например, не секрет, что при увеличении скорости передачи по оптическому волокну недостаточная оптическая чистота поверхности разъемов является причиной 90% отказов. Вот почему с развитием технологий регламенты должны актуализироваться в соответствии с текущим состоянием и уровнем развития техники».

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

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

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

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

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

С точки зрения эксплуатации одна из главных проблем, по мнению Сергея Малышева, заключается в том, что инженеры не разговаривают на языке бизнеса. «Они изъясняются на своем техническом языке в терминах протоколов, интерфейсов, – поясняет он. – А бизнес интересуется не скоростью на порту: ему нужно решение конкретной бизнес-задачи, где одним из факторов является наличие или отсутствие сервиса. Задача людей, которые эксплуатируют сеть, – максимально доступным языком разговаривать с бизнесом, потому что сама по себе сеть никому не нужна. Это всего лишь инструмент для достижения цели».

Центральный федеральный округ