Как организовать техподдержку в ИТ-компании в формате 24/7

Как организовать техподдержку в ИТ-компании в формате 24/7

Так какие kpi выбирать и с чего лучше начинать?

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

Тут важно отметить, что при измерении фактического показателя следует заранее условиться о периоде измерения значений. Доступность в размерах 99,9 % на практике означает, что простой может продолжаться:
— не больше 8,76 ч/год;
— не более 43,2 мин/месяц;
—10,1 мин/неделю.

И если за основу взято измерение «раз в неделю», то 15-минутный простой за этот промежуток времени станет несоблюдением показателей SLA.

Есть ещё одна область, где значение «ки-пи-ай» переоценить сложно. Бывает, что руководитель недоволен каким-нибудь процессом и, желая его улучшить, начинает «размахивать шашкой», забрасывая всех категоричными распоряжениями по изменению ситуации. Но что значит «недоволен»?

Каковы конкретно измеримые показатели неудачи или успеха? И вот как раз здесь KPI-система помогает исключить необъективность и не допустить схожие ситуации. В результате отладка рутинных процессов проходит в определённой последовательности:
— измерение, Measure;
— управление, Manage;
— улучшение, Improve.

Именно поэтому для многих параметров задают не только критические значения, ниже которых опускаться нельзя, но и целевые значения, которых стремится достичь фирма.
В самом начале внедрения системы разумнее проповедовать принцип «не сломалось — не чини».

15 марта 2021

02:00

. Система мониторинга зафиксировала потерю связности OST – NORD. Дежурный администратор зарегистрировал инцидент и назначил его на сетевую группу. Так как обрыв связи затронул наши и клиентские трассы, инцидент был сразу эскалирован на ведущего инженера ВОЛС и руководителя сетевой группы.

02:15. Дежурный инженер сетевой группы связался с подрядчиком, обслуживающим ВОЛС.

04:00. Ведущий инженер сетевого отдела определил предполагаемое место обрыва со стороны дата-центра OST. Дежурный обслуживающей компании выехал на место для осмотра.Также инженеры установили, что в результате аварии пострадали клиенты, арендующие темную оптику.

04:35. Сетевые инженеры совместно с дежурным инженером подрядчика установили, что обрыв произошел на участке Красносельского коллектора, и связались с ГУП “Москоллектор”. Диспетчер сообщил о возгорании на ПК-42 Красносельского коллектора и принял заявку на допуск ремонтной бригады, но предупредил, что доступ на коллектор закрыт до выяснения обстоятельств.

08:00. Отправлена телефонограмма в ГУП “Москоллектор” с повторной заявкой на аварийный допуск ремонтной бригады подрядчика на территорию коллектора.

08:15. ГУП «Москоллектор» сообщил об отключении силовых кабелей и локализации пожара. Но доступ в коллектор для операторов связи был по-прежнему закрыт до 16.03.2021 г., до восстановления общегородских коммуникаций, инженерных сетей и выявления причин аварии от СК РФ и сотрудников ГУП “Москоллектор”.

09:00. Инженеры начали переключать пострадавших клиентов на резервные маршруты. У некоторых клиентов были свои резервные оптические трассы, и их удалось переключить быстро. Клиентов, не имеющих резерва, переключали на свои собственные резервные трассы.

15:00. Все пострадавшие клиенты переведены на резервные маршруты.

Агрегированные снимки инцидентов

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

Для этого, как только оценка какой-либо метрики падает до значения «требует внимания», система мониторинга автоматически формирует Агрегированный Снимок Инцидента и регистрирует в Service Desk – системе новый инцидент. К Агрегированному Снимку Инцидента прикладываются и все относящиеся к нему жалобы (Сообщения HelpMe). Получив Агрегированный Снимок Инцидента, служба поддержки работает с ним, как с обычным инцидентом.

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

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

Выявление контекста и ограничений

Разумеется заказчик находится в какой-то ситуации и он ограничен принятыми ранее  решениями (decision).

“Разгрузить грузовик” – это сложно? Неясно, так как неясен контекст.

К примеру, “Разгрузи грузовик в минус 40, на дне озера” и “Разгрузи грузовик в плюс 25, на асфальте” выглядят как совершенно разные задачи.

Для проектирования модели нужно разобраться в контексте того, как полученное решение (solution) будет использоваться, в каком процессе и для чего. Какая ситуация у заказчика. 

Выявление контекста – сфокусировано на области, где проявляют себя потребности. Нет смысла начинать решение задачи с “описания текущих процессов”, если не сформулировано цели (потребности, боли) изменений. Процессов и деталей этих процессов слишком много, их изучение само по себе без цели не имеет смысла и окончания.

Перед проектированием будущего изменения часто нужно выявить желаемые сроки внедрения. Возможны разные варианты:

  1. Сделать к “черной пятнице”, 

  2. Сделать, потому что каждый день мы что то теряем, 

  3. Сделать, иначе с какого-то момента мы будем каждый день что-то терять.

Таким образом выявляются ожидания/ограничения по срокам.

Не всегда все нужно делать монументально, часто бизнес не уверен в будущих выгодах. В этом случае стоит сделать более быстрое/менее качественное решение, чтобы проверить гипотезу. Также иногда лучше сделать менее качественно, но более быстро, даже если это “заплатка” или “костыль”. Нужно выявить ожидания/ограничения по качеству.

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

В итоге, складывается понимание ограничений на проектный треугольник (стоимость/сроки/качество).

Кроме того, область решений (solution) ограничена еще:

  1. Ограничениями по ресурсам

  2. Требованиями удобства пользователей

  3. Решениями по существующему ИТ-ландшафту и уровню ИТ сервиса

  4. Выбором подрядчиков и правилами привлечения новых

  5. Правилами работы с подрядчиками

  6. Требованиями безопасности и распространения информации

  7. Требованиями регуляторов

  8. И т.д.

Не зная ограничения, нельзя спроектировать решение с их учетом.

В случае слишком жестких ограничений решения может и не найтись. Тогда ограничения заменяются функциями штрафа и аналитик ищет наименее болезненное решение.

Выявление потребностей и целеполагание

Пациент приходит к доктору и требует “Выпишите мне аспирин, срочно!!!”.

Требование = “Выписать аспирин”. Что делает доктор в данном случае? Плохой доктор даст аспирин. Хороший доктор будет выявлять причины проблемы и лечить их.

Требование (requirement) – это некоторый образ или свойство результата, который кто-то у кого-то требует. “Выпишите аспирин”, “Программа должна делать это” – это требование. Термин не самый удачный в русском языке, он плохо стыкуется с бытовым толкованием, что запутывает заказчика и аналитика.

Требование лежит в области решения (solution). “Поесть в ресторане”, “Приготовь еду” – это требования.

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

Поэтому аналитик выявляет потребности и проектирует решение (требования к решению). 

В разное время разные бизнесы стремятся к оптимизации разных атрибутов качества своих систем и процессов.

  1. Обеспечить функциональность

  2. Качественную работу

  3. Скорость/Производительность

  4. Безопасность

  5. Низкие издержки

  6. И т.п.

Разрыв ожиданий и реальности атрибутов качества создает проблему, которую нужно решить, и для этого нужны какие-то изменения. Устранение разрыва будет целью (goal) будущего изменения.

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

Жалоба и удовлетворённость пользователей

Каждая жалоба – это сигнал о неудовлетворённости пользователя, а содержание Сообщения HelpMe позволяет определить, к какому сервису неудовлетворённость относится, где географически расположен пользователь, из какого он подразделения, какую должность занимает и т.п.

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

Теперь эти группы жалоб – метрики, которые отслеживает система мониторинга. Если придёт жалоба пользователя, входящего в группу «Продавцы – Питер», на работу SAP, она будет учтена Метрикой 4, жалоба сочинского пользователя на 1С – Метрикой 6. При помощи метрик удовлетворённости пользователей система мониторинга отслеживает качество ИТ-сервиса.

Сейчас ищут техподдержку:  Горячая линия Huawei, служба поддержки Huawei, бесплатная горячая линия 8-800

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

«Требует внимания» – Пороговое значение Оценки Качества для отправки Агрегированного Снимка Инцидента в Service Desk.

Динамику метрик, а значит удовлетворённости пользователей, можно видеть в режиме реального времени. Зелёные квадратики – «хорошо», мигающие зелёные – «допустимо», появился жёлтый – «требует внимания».

Какую роль играет kpi в управлении it–персоналом?

Говоря о долговременном развитии компании, отметим, что её стратегия, миссия и цели (долго-, средне- и краткосрочные) должны быть сформулированы и доведены до руководства и простых сотрудников. А по каждому сотруднику должны быть согласованы его персональные цели на год и, если это реально, оговорены целевые значения, по которым в перспективе можно будет определить, удалось ли достичь заявленных целей.

Задача непосредственного руководителя — систематический контроль выполнения персональных планов сотрудников на протяжении года (один раз в квартал, один раз в полгода). А по итогу года можно провести и оценку результата, которая будет завязана на денежные бонусы и изменение зп сотрудника.

Здесь нередки ошибки «чёрно-белого» подхода: когда KPI-показатели не достигнуты, премия попросту не выплачивается. Очень часто мы видим итог такой ошибки: сотрудник видит заявленные параметры и понимает, что выполнение «ки-пи-ай» ему в реальности «не светит». В итоге он заранее опускает руки и работает не так эффективно, как мог бы.

Можно и нужно применять не только персональные «ки-пи-ай», но и показатели, которые завязаны на работу целого отдела, а также всего предприятия. И если руководитель способен повлиять на результаты работы «всего цеха», то это учитывается при расчёте его бонуса. А вот на бонус рядовых работников в большей степени влияет степень выполнения персональных целей.

Можно с уверенностью сказать, что, несмотря на всю критику, «ки-пи-ай» при грамотном использовании до сих пор является мощным инструментом объективной оценки и мотивации сотрудников. Но система имеет и минусы:
— измерение и контроль показателей требует ресурсов, ведь бесплатно ничего не происходит.

А значит, нужно стараться по максимуму автоматизировать измерения. Но всегда помните, что чем точнее измеряются параметры, тем дороже это обходится;
— всегда остаётся риск, что сотрудники станут работать исключительно на выполнение KPI, ведь на его базе рассчитываются бонусы.

Всё вышеперечисленное накладывает повышенные требования к качеству самой системы и требует её регулярной проверки на соответствие главным целям и миссии предприятия.

Классификация поддержки


Прежде чем говорить о доходах, необходимо расставить все точки в вопросе терминологии.

Поддержку можно условно разделить на:

Совершенно независимо от этого можно выделить внутреннюю и внешнюю поддержку, хотя для нашей страны выделять во “внутренней поддержке” что-то кроме “технической” пока затруднительно.


Подробнее о классификации поддержки и системах автоматизации, предназначенных для каждого из этих классов мы писали

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

Работы мы обнаружили лишь 48 компаний, чьи вакансии соответствуют запросам “поддержка клиентов” / “клиентская поддержка”. Причем, часть вакансий (в 7 компаниях) на самом деле подразумевала исполнение обязанностей технической поддержки, еще 9 компаний использовали эту формулировку для поиска руководителя call-центра или того же отдела технической поддержки.

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

Концепция

image

Сегодня дело обстоит так, что контактами с пользователями (прежде всего, приёмом и обработкой обращений по поводу инцидентов и сервисных запросов) занимается служба поддержки, а проактивным мониторингом – системный администратор (системные администраторы).

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

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

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

Примечание. Цель мониторинга качества ИТ-сервиса с точки зрения поставщика сервиса – не мониторинг абстрактного качества сервиса как такового, а обеспечение удовлетворённости пользователей качеством сервиса.

Наиболее важный kpi

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

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

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

Каким должен быть этот параметр? Хорошо, если 4,5, хотя для некоторых компаний и 4,0 может быть труднодостижимой целью. Тут главное, чтобы значение (или динамика его улучшения) устраивало топ-менеджмент.

Чем больше сотрудников пройдёт опрос, тем полнее и достовернее будут результаты. И тут мы подошли к ещё одной проблеме: как нам их мотивировать, чтобы они потратили время на заполнение опроса? Здесь работают следующие техники:
— мини-призы первой десятке прошедших анкетирование;
— чётко составленные вопросы и профессиональный дизайн самой анкеты (это банально, но, увы, исполняется далеко не всегда);
— уверенность в том, что ответ любого человека важен для компании, а к результатам опроса руководство отнесётся весьма серьёзно;
— обеспечение обратной связи по результатам (благодарственное письмо директора и отчёт с информацией о том, что удалось выяснить и что будет предприниматься по итогу анкетирования, какие благоприятные изменения ждут компанию, — если работник знает, что его ответы действительно кто-то читает, он заполняет опросы охотнее).

Область применения и ограничения

image

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

  1. Проведение аудита качества ИТ-сервисов (ежегодное техобслуживание). А не появились ли проблемы, о которых мы не знаем; «Просим вас оценить качество получаемого сервиса» и т.п.
  2. По окончании внедрения новых сервисов. Систематизация жалоб позволит локализовать недоработки бизнес-приложений и/или проблемы в ИТ-Инфраструктуре. «Внедряется новое бизнес-приложение, просим вас нам помочь оценить качество работы подрядчиков».
  3. При смене CIO или ИТ–команды. Чтобы оценить масштабы бедствия в цифрах.


Основные цели:

  1. Локализация проблем, что позволяет более эффективно использовать более точные средства диагностики, например, анализатор сетевых протоколов.
  2. Диагностика скрытых дефектов и узких мест (о которых ИТ-Служба не знает). Чтобы их устранить и пользователи больше не жаловались.
  3. Определение пороговых значений технических метрик (утилизация, число ошибок, задержки), соответствующих комфортной работе пользователей. Чтобы контролировать производительность и доступность ИТ-Сервисов с использованием имеющиеся системы мониторинга ИТ-Инфраструктуры и без привлечения для этого пользователей. Это очень важная тема, которую мы постараемся раскрыть в отдельной статье.

Отправка жалобы

Пользователь не любит общаться с ИТ-службой. Минимизируем сложность отправки жалобы: пусть она отправляется полностью автоматически по нажатию кнопки или сочетания клавиш.

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

Сейчас ищут техподдержку:  По какому номеру позвонить оператору МТС: vnc rfr gjpdjybnm jgthfnjhe

Пользователь не прочь бы выразить своё возмущение и улучшить работу сервиса, но не знает, как это сделать. Он громко ругается на весь отдел: «Опять завис, собака!» или переживает эту драму в себе. Дадим ему Красную Кнопку. Теперь, когда сервис опять затупит, он сначала нажмёт на кнопку, а потом будет ругаться на весь отдел.

Красная Кнопка – это программный агент EPM-Agent Plus. Он устанавливается на компьютеры пользователей или терминальный сервер. К программному агенту прилагается девайс – аппаратная кнопка-нажималка, подключаемая по USB. Именно на неё и нажимает пользователь, когда возникают проблемы с сервисом. Если для кого-то кнопка выглядит старомодно, можно обойтись нажатием комбинации клавиш – это будет равносильно нажатию аппаратной кнопки.
image

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

EPM-Agent Plus умеет следующее. По нажатию кнопки (аппаратной или комбинации клавиш) он определяет используемое бизнес-приложение и бизнес-операцию, делает скриншот экрана, добавляет значения переменных среды и учётные данные пользователя и отправляет всё это в виде сообщения HelpMe в Агрегатор информации (не в Service Desk!).

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

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

Первая линия поддержки. функции и обязанности

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

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

С другой — в состоянии перегруза простыми задачами они вряд ли корректно отвечают на запросы, что не самым лучшим образом влияет на восприятие клиентом уровня сервиса. Иными словами, времени и денег на зарплату сотрудников потрачено много, а результат — так себе.

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

Первая линия принимает заявку клиента и классифицирует её.

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

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

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

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

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

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

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

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

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

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

Проектирование решения

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

Например, модель системы из предыдущего примера это электрическая фритюрница.

Моделей системы может быть несколько (и довольно много), но типовые это

  1. Функциональная модель, отвечающая на вопрос “как это работает, функционирует, обеспечивает функцию”. 

  2. Конструктивная модель, отвечающая на вопрос “как это сконструировано, из каких частей состоит”. 

  3. Географическая модель, отвечающая на вопрос “где это работает” или “где расположены части” делается совместно на основе предыдущих двух.

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

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

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

Аналитик решает задачу по проектированию такого решения, которое закрывает потребности по правилу Парето, 20% усилий должны принести 80% бизнес-результата, где усилия берутся из треугольника (цена-качество-сроки) в рамках выявленных ограничений, а результат – это оценка улучшения атрибутов качества бизнес-процесса.

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

ИТ аналитику в поиске помогают

  • Знание того, как ИТ решают задачи по улучшению процессов, 

  • Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

  • Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

  • Знание предметной области,

  • Знание процессного управления и процессов управления изменениями,

  • Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

  • Ну и разумеется, эксперты, партнеры по интеграции, смежники, вендоры ИТ решений и разработчики.

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

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

“Дайте мне аспирин” 
“А это вылечит вашу боль?”
(неизвестно, если причина боли не диагностирована)

Путь обращения в техподдержке


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

Сейчас ищут техподдержку:  В контакте сайт техническая поддержка

Регистрация обращения. При регистрации обращения в тикетной системе оператор делает следующее:

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

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

Как организовать техподдержку в ИТ-компании в формате 24/7
Схема назначения исполнителя в зависимости от того, когда поступило обращение.

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

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

Закрытие обращения. После выполнения запроса или устранения инцидента исполнитель готовит отчет и передает обращение аккаунт-менеджеру. Он получает подтверждение со стороны клиента о разрешении заявки, обращение закрывается и переводится в статус “Решено”.

Как организовать техподдержку в ИТ-компании в формате 24/7
Процесс управления инцидентами выглядит так.

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

Резюме

Работа аналитика это превращение проблем в задачи, при котором характерны этапы:

  1. Выявление потребностей и целеполагание,

  2. Выявление контекста и ограничений,

  3. Проектирование требований,

  4. Проектирование решения,

  5. Внедрение решения.

Опыт проектирования и внедрения решения необходим для грамотного выявления потребностей, контекста и ограничений. Без опыта неясно что из потребностей в каких ограничениях возможно закрыть автоматизацией. Без опыта выявления потребностей и ограничений можно спроектировать неверное решение.

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

Основная ценность работы аналитика-проектировщика для бизнеса состоит в поиске и создании непротиворечивых проверяемых моделей решения, закрывающего потребности по правилу Парето 80 на 20, имея как фокус проявленную выгоду от внедрения с учетом выявленных ограничений.

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

P.S. Спасибо участникам КиФБ за отзывы и корректировки к статье, а так же отдельное спасибо Денису Бескову и Анатолию Левенчуку за то, что помогли взглянуть на проблему системно

Типовые и нетиповые задачи, которые мы решаем

Для себя мы выделили топ-3 типовых задач, которые мы решаем по нашим программным продуктам. Так, в Arenadata Hadoop это падение сервисов, снижение производительности, конфигурация центра управления. С Arenadata DB (ADB) чаще всего связаны задачи, возникающие из-за нарушения работы или медленного выполнения запроса, падения одного или нескольких сегментов и снижения производительности.

Конечно, регулярно техподдержка сталкивается и с нетиповыми задачами. Рассмотрим на примерах.

  1. Проблемы вокруг Hive (продукт AD Hadoop)

    При установке новой версии прикладного ПО установщик падает с ошибкой Hive: не может выполнить drop table.

    Для решения задачи мы протестировали работу на разных версиях внешней базы данных. Диагностика показала, что проблема в конкретной версии внешней базы данных, которая являлась metastore Hive. Чтобы решить её, потребовалось установить более старшую версию внешней базы данных.

  2. Обновление кластера

    При проведении миграции на AD Hadoop выполнялись плановые работы по обновлению кластера с ADH 1.5 на ADH 1.6. Вернуться на старую версию уже невозможно. Потребовалось протестировать совместимость с внешней BI-системой, работу скриптов и стороннего ПО с новыми версиями компонентов ADH.

  3. Плавающие проблемы

    Во время работы с Arenadata DB у клиента возникли сложности при увеличении объёма данных и нагрузки. Длительность запросов к каталогу DB превышала десятки минут.

    Порекомендовав клиенту проверить сеть, мы выявили потерю более 30% пакетов. Инцидент был исчерпан после того, как заказчик устранил проблему в сетевой инфраструктуре.

Универсальные kpi для it-руководителей

Когда надо оценить работу IT-руководителей, используют ряд универсальных «ки-пи-ай». Это и степень удовлетворённости внутренних пользователей, и параметры соблюдения SLA. Можно применять и «ки-пи-ай» из сферы управления проектами, тот же процент успешно выполненных проектов в контексте соблюдения бюджета, сроков, функционала и качества.

А вот измерить «инновационность» сложнее. Поначалу можно лишь посоветовать учитывать число новых ИТ-сервисов и степень их востребованности, а если говорить финансовыми терминами — следует учитывать соотношение инвестиционной и операционной частей IT-бюджета.

Отдельно необходимо упомянуть контроль соблюдения бюджета. Целевое значение — отклонение от утверждённого бюджета не превышает 5 %. Во многих компаниях перерасход бюджета не допускается в принципе, однако и чересчур высокая экономия тоже плохо — она говорит, скорее, о непрофессиональном планировании и о том, что финансы компании заморозились на неинициированных IT-проектах, хотя их можно было инвестировать в более важные и перспективные направления.

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

Финансовые «ки-пи-ай»:
— ROI (Return On Investment) — возврат на инвестиции в проект. Этот показатель относителен и показывает отношение дохода от инвестиции к размеру инвестиции;
— Payback Period — период окупаемости проекта.

Отдельно приведём пример показателей, которые характеризуют умение руководителя работать с персоналом:
— процент «текучки» работников подразделения. Хорошо, если в год по своему желанию уходит меньше 10 % сотрудников;
— процент сертифицированных специалистов (прекрасно, если это 40 % и выше);
— среднее количество сотрудников компании, поддерживаемых одним специалистом из ИТ-департамента.

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

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

Вместо заключения или важные цифры

Всего компаний с вакансиями в поддержке в России за июль-август 2021 года: 1025.

С указанием зарплаты: 436 (42,5%).


Компаний с вакансиями в поддержке в отрасли ИТ: 930 (91% от общего числа компаний с вакансиями в поддержке).

Из них с указанием зарплаты: 394 (42% от общего числа компаний с вакансиями в поддержке в сегменте ИТ).

Далее речь только о вакансиях из ИТ:

  • Без опыта: 187 (20% от общего числа компаний с вакансиями в поддержке в сегменте ИТ), из которых 85 (45%) — с зарплатой; должности — специалист, инженер, оператор.
  • Опыт 1 — 2 года: 532 (57%), с зарплатой — 230 (43%); должности — специалист, инженер, оператор.
  • Опыт 3 — 5 лет: 101 (11%), с зарплатой — 33 (32%); должности — руководитель, инженер, специалист.
  • 6 и более лет опыта — всего 3 вакансии (с зарплатой — только 1); должности — инженер и руководитель.

Компаний с вакансиями в клиентской поддержке / поддержке клиентов — 48

. Из них 9 — руководящие должности в колл-центрах и техподдержке; 3 явно связаны с продажами, а 7 — на самом деле в технической поддержке (как становится понятно уже из беглого изучения текста объявления).

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

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (Пока оценок нет)
Загрузка...

Оставьте комментарий

Adblock
detector