Byte/RE ИТ-издание

Кому доверить свою ИТ-систему?

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

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

Кто есть кто на рынке сервисных услуг

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

У сервисной организации есть и другие плюсы, например, возможность поддерживать мультивендорные решения и настроенные для заказчика разработки. Как правило, наиболее квалифицированные ресурсы производителей — англоговорящие, и находятся они за границей. Сервисная же компания имеет высококвалифицированных инженеров «под боком», что особенно важно при «продвинутых» (высокоуровневых) сервисных контрактах.

Поэтому неспроста многие производители строят свою сервисную политику по двухуровневой системе (рис. 1) — при этом они выигрывают за счет итогового повышения качества обслуживания заказчиков. Но при приобретении сервисных услуг перед заказчиками встает опять все тот же серьезный вопрос выбора конкретной компании. А какими они бывают?

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

Услуги техподдержки должны быть как можно ближе к потребностям заказчиков и соответственно требуют от заказчиков более внимательного отношения к их выбору.

«Временные связи» или «постоянные отношения»?

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

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

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

Как правило, модель с низким во влечением предполагает более простые сервисные услуги. Но такая модель имеет ряд других преимуществ:

  • экономия на накладных расходах на поддержание отношений с сервисным подрядчиком (заказчику не требуется проводить установочные совещания, «подтачивать» свои процедуры, чтобы лучше состыковать их с процедурами подрядчика и т. п.);
  • меньшая зависимость от поставщика (заказчик в любой момент сможет переключиться на другого);
  • легче «выбивать» хорошие финансовые условия (проще получить несколько альтернативных предложений от других поставщиков).

У отношений с высоким вовлечением также есть свои плюсы:

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

Как видно, у каждой модели есть свои плюсы и минусы. Часто сотрудничество с поставщиком сервисных услуг начинается с базовых сервисов для какой-то части системы заказчика. Тем не менее сегодня мы наблюдаем следующую тенденцию: все больше компаний движутся в сторону потребления более высокоуровневых сервисных услуг и устанавливают долгосрочные отношения с высоким вовлечением с сервисными организациями (рис. 2). Объясняется это тем, что критичность внутренних ИТ-сервисов компаний неминуемо возрастает, из-за чего надежность поставщика сервисных услуг выходит на первый план. Зачастую сервисная поддержка некоторых дорогостоящих и уникальных сетей или систем невозможна без серьезного согласования процедур поставщика и заказчика.

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

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

Есть еще одна причина, по которой комп ании стараются минимизировать количество поставщиков сервисных услуг, — это риск «нарваться» на недобросовестного провайдера услуг, который в самый критичный момент нарушит SLA. Да и само по себе переключение на другого поставщика при использовании базовых услуг также влечет за собой дополнительные расходы и риски. Даже на этапе сравнения предложений подрядчиков могут возникнуть проблемы; например, термин 24Ч7Ч4 у разных поставщиков может иметь совершенно разное значение: у одних это замена оборудования за 4 ч круглосуточно, у других — выезд инженера в течение 4 ч, а у третьих — только начало обработки запроса заказчика через 4 ч.

Таким образом, «правильный» поставщик должен быть готов предложить как базовые сервисные услуги (ремонт, оперативная замена оборудования, модернизация ПО), так и более продвинутые, подстраиваемые под заказчика.

В чем секрет «правильного» сервисного центра

Хороший сервисный центр (СЦ) должен одновременно уметь «печь пирожки», как «Макдональдс», и «сервировать эксклюзивную пекинскую утку», как специализированный ресторан. С одной стороны, он должен иметь возможность в минимальные сроки устранить аварию путем оперативной замены неисправного оборудования или исправления настроек, а с другой — быть способным решать «плавающие», «непонятные» проблемы.

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

Как успешно совместить два типа структуры при организации СЦ? Наиболее эффективный способ — это создать внутри СЦ две подструктуры, одну — отвечающую за оперативный выезд инженера и замену вышедшего из строя оборудования, другую — нацеленную на анализ комплексных проблем и решение сложных задач (рис. 3). В первой структуре должна существовать четкая функциональная иерархия, а также жесткая регламентация всего рабочего процесса. Во второй нужна как можно более плоская организация, с регламентированием только контрольных точек и необходимых результатов без жестких требований к самому процессу организации работы.

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

Сертификат по результатам сданного экзамена гораздо показательней, чем сертификат об окончании курсов. Многие возразят, что среди инженеров гуляет много шпаргалок с правильными ответами, и ценность сертификатов сейчас утрачена, но это не совсем так. Хороший пример — сдача экзамена на водительское удостоверение: вопросы всем заранее известны, но требуется не один день, чтобы подготовиться и все запомнить. Особенно важно наличие у сотрудников СЦ сертификатов высших ступеней, так как это действительно довольно объективный показатель квалификации. Например, подготовка инженера к лабораторной работе CCIE (Cisco Certified Internetworking Expert) в среднем требует не менее года упорных тренировок, причем многие инженеры знают от коллег и знакомых примерное содержание заданий, но, как ни странно, с первого раза лабораторную сдают гораздо меньше половины. Как правило, сертификат высшей ступени существенно повышает вероятность того, что инженер не только знает, где что написано в документации, но хотя бы раз на практике сталкивался с чем-то похожим, пусть даже при подготовке к лабораторной, а при обработке высокоприоритетного сервисного запроса в стрессовой ситуации это очень критично.

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

Каким бы продвинутым ни был СЦ, каких бы великих гуру он ни имел в своем штате, рано или поздно возникнет запрос, который он не сможет отработать самостоятельно, — например, проблема с оборудованием, вызванная ошибками встроенного ПО. Поэтому для заказчика очень важно, чтобы СЦ имел развитые отношения с различными производителями. Они не обязательно должны быть на уровне «авторизованного сервисного центра», поскольку разные производители имеют разную политику выстраивания партнерских отношений. Часто само понятие «авторизованный сервисный центр» означает компанию, которая осуществляет гарантийный ремонт оборудования производителя, что несколько отличается от задач сервисной поддержки ИТ-систем. По многому оборудованию провайдеры сервисных услуг сами не производят ремонтов, а используют, в свою очередь, других партнеров, но они должны уметь эскалировать проблему, связанную с какой-либо системной ошибкой, на уровень производителя. Поэтому для сервисной компании бывает достаточно (а иногда даже лучше) иметь статус не «авторизованного сервисного центра», а «бизнес-партнера» производителя.

SLA, ITIL и прочие характеристики качества

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

Существует довольно много методологий контроля и обеспечения качества, начиная от стандартизации ISO 9001 и заканчивая методологиями TQM (Total Quality Management), 6-Sigma и т. п. Но все их объединяет несколько общих принципов (при действительно правильном внедрении), основные из которых: постоянное совершенствование, сфокусированность на клиентах, сбор и анализ объективных показателей работы, а также обязательная вовлеченность в систему контроля качества как рядовых сотрудников, так и руководителей среднего и высшего звена.

Чтобы оценить, действительно ли поставщик сервисных услуг привержен основным принципам обеспечения качества, вовсе не требуется проводить доскональный аудит. Достаточно попросить продемонстрировать, какие данные для контроля своей работы он собирает и что с ними делает. Предоставленная информация должна свидетельствовать о том, что методика контроля качества внедрялась не ради нее самой, а ради процесса непрерывного совершенствования.

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

Если с собираемыми параметрами все в порядке, на следующем шаге нужно определить, насколько серьезно и регулярно выполняется их анализ и какие мероприятия при этом проводятся. Ключевые моменты, на которые здесь необходимо обратить внимание, — это опять-таки регулярность, а также вовлеченность сотрудников на всех уровнях. Стоит попросить кого-либо из руководства сервисной службы подрядчика рассказать о нескольких последних улучшениях (пусть даже мелких), которые были сделаны по результатам контроля.

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

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

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

Основные правила оценки будущего поставщика сервисных услуг

  1. Сервисная организация должна быть готова предложить как базовые сервисы, так и кастомизированный для заказчика пакет услуг.
  2. Внутренняя организация СЦ должна по-разному обеспечивать как минимум две четко разделенные подструктуры — группу или отдел оперативной замены оборудования и устранения аварий, вызванных аппаратными неисправностями, и группу решения комплексных и «скользких» проблем.
  3. Достаточное количество сертифицированных специалистов (именно сертифицированных, а не только обученных). Большое количество профессионалов особенно важно при приобретении «продвинутых» сервисов.
  4. Наличие партнерских отношений с производителями. Иногда важен статус не авторизованного сервис-центра, а бизнес-партнера.
  5. Развитость инструментов контроля качества. СЦ обязательно должен регулярно собирать объективную информацию как об удовлетворенности заказчиков, так и о показателях своей работы (с точки зрения соблюдения SLA), а также вести регулярный ее анализ. Можно попросить показать, к примеру, статистические данные, которые анализируются регулярно, раз в неделю или в месяц.
  6. Стоит поинтересоваться, какие улучшения в своей работе (пусть даже мелкие) подрядчик сделал по результатам контроля в последние несколько месяцев. Важно, чтобы такая работа велась постоянно.
  7. Проанализируйте, какие отчеты подрядчик готов предоставлять на регулярной основе.
  8. Выясните, какие мероприятия СЦ проводит для повышения актуальности информации в информационной системе. Важно наличие процесса выборочного контроля информации вручную, так как отследить актуальность информации автоматически невозможно.
  9. Уточните, отслеживается ли в информационной системе поставщика сервисных услуг стадия исполнения сервисного запроса и то, «на чьей стороне мячик».
  10. Выясните состояние объемов ЗИП-складов оборудования и лабораторий в сервисной организации.
  11. Уточните наличие группы сервис-менеджеров (или руководителей сервисных проектов).

Информационная система провайдера сервисных услуг

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

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

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

Ресурсы сервисной компании

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

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

При запуске серьезных сервисных проектов сервис-провайдер должен быть уверен, что у него достаточно ресурсов и что все необходимые мероприятия по запуску проекта будут выполнены в срок: например, закуплен необходимый ЗИП, усилен инженерный состав, заключены соглашения с подрядчиками и т. д. Кроме того, при выполнении «тяжелых» сервисных проектов существует масса работ, которые надо заранее планировать и отслеживать. К их числу относятся плановые диагностики оборудования, технологические аудиты. Качественно выполнить все эти работы невозможно без наличия специализированного координирующего органа внутри СЦ — службы руководителей сервисных проектов или сервис-менеджеров. Как и в случае проектов внедрения или построения каких-либо систем, руководители сервисных проектов должны закрепляться за заказчиками и нести ответственность за оказание им услуг поддержки. Поэтому при выборе подрядчика следует обратить внимание на наличие отдельной группы таких менеджеров.

Вам также могут понравиться