Как устроена техническая поддержка в Яндекс.Клауде?
Докладов про поддержку мало.
Толковых - ещё меньше.
А между тем, в крупном облачном провайдере поддержка - не просто «дежурный у телефона».
Это система, в которой всё продумано: от найма до культуры, от автоматизации до KPI, от первого тикета до инцидента уровня P0.
В докладе - разбор изнутри.
Не про теорию.
Про то, как это работает на практике.
Что узнаете:
▪️ Как организована поддержка в крупном облачном провайдере?
- Три линии
- L1 решает большую часть запросов, L2 и L3 - погружаются в сложные кейсы, работают с продуктами, участвуют в инцидентах.
- Поддержка - не «конвейер», а сеть экспертизы.
▪️ Сколько инженеров на каждой линии?
- Не просто цифры.
- Как они распределены по продуктам
▪️ Как и откуда они набирают людей?
- Не только по стеку и резюме.
▪️ Как устроен онбординг и развитие?
- Первые 90 дней - не «знакомство с системой», а глубокое погружение.
▪️ Что автоматизировали?
- Чтобы инженер мог решать проблему, а не искать её.
▪️ Чем занимаются L2/L3?
▪️ Какие KPI у инженеров и руководителей?
▪️ Как работают с инцидентами?
▪️ Что должна иметь любая ответственная компания?
▪️ Нужен ли Tone of Voice?
- Спойлер: Да.
▪️ Support - центр расходов или доходов?
▪️ Какая культура в команде?
Рекомендую.
Польза будет.
Однозначно.
#TechSupport
Докладов про поддержку мало.
Толковых - ещё меньше.
А между тем, в крупном облачном провайдере поддержка - не просто «дежурный у телефона».
Это система, в которой всё продумано: от найма до культуры, от автоматизации до KPI, от первого тикета до инцидента уровня P0.
В докладе - разбор изнутри.
Не про теорию.
Про то, как это работает на практике.
Что узнаете:
▪️ Как организована поддержка в крупном облачном провайдере?
- Три линии
- L1 решает большую часть запросов, L2 и L3 - погружаются в сложные кейсы, работают с продуктами, участвуют в инцидентах.
- Поддержка - не «конвейер», а сеть экспертизы.
▪️ Сколько инженеров на каждой линии?
- Не просто цифры.
- Как они распределены по продуктам
▪️ Как и откуда они набирают людей?
- Не только по стеку и резюме.
▪️ Как устроен онбординг и развитие?
- Первые 90 дней - не «знакомство с системой», а глубокое погружение.
▪️ Что автоматизировали?
- Чтобы инженер мог решать проблему, а не искать её.
▪️ Чем занимаются L2/L3?
▪️ Какие KPI у инженеров и руководителей?
▪️ Как работают с инцидентами?
▪️ Что должна иметь любая ответственная компания?
▪️ Нужен ли Tone of Voice?
- Спойлер: Да.
▪️ Support - центр расходов или доходов?
▪️ Какая культура в команде?
Рекомендую.
Польза будет.
Однозначно.
#TechSupport
RUTUBE
Как мы делаем Yandex Cloud — Support
В новом выпуске «Как мы делаем Yandex Cloud» познакомились с руководителем третьей линии поддержки Александром Житным. Обсудили, как устроена поддержка Yandex Cloud, чем занимаются команда автоматизации и AI-роботы, какие у команды KPI и принципы работы.…
🔥8👍7✍3👎1
Change Management
Что? Зачем? И почему?
Incident Management - восстанавливает сервис.
Problem Management - убирает причину поломки.
Change Management - предотвращает сбои и улучшает сервис.
Если инцидент - пожар, проблема - неисправная проводка,
то Change - это разрешение на ремонт, проверенный план и подписанный акт.
Без него «быстрый фикс» становится бомбой.
Примеры:
▪️ Обновление операционной системы на критически важном сервере.
▪️ Развертывание новой версии корпоративного приложения.
▪️ Изменение конфигурации сетевого оборудования, чтобы увеличить пропускную способность.
▪️ Удаление устаревшего, неиспользуемого компонента инфраструктуры.
Что такое Change Management?
Это процесс контроля изменений в инфраструктуре, продуктах и процессах.
Не запрет на перемены.
А структура для безопасных изменений.
Основные цели Change Management
Цель - не замедлить.
Цель - предотвратить ущерб от "хорошей пятничной идеи в 20:37".
Почему это важно? Потому что:
▪️70% инцидентов начинаются с изменения.
▪️90% из них - с изменения, которое "никто не заметил".
▪️100% из них - с изменения, которое не прошло проверку.
1️⃣ Контроль рисков
Каждое изменение оценивается: что может пойти не так?
Кто пострадает?
Как откатим?
2️⃣ Минимизация сбоев
Не "сделаем и посмотрим".
А: протестируем → согласуем → внедрим → проверим.
3️⃣ Прозрачность и аудит
Где, что, кем и когда было изменено?
Теперь вы можете ответить на этот вопрос.
5️⃣ Координация между командами
Разработка, SRE, поддержка, безопасность - все в одном поле.
Никаких сюрпризов в релизе.
5️⃣ Сохранение стабильности сервиса
Не ради "процедуры".
А ради того, чтобы клиенты продолжали пользоваться сервисом.
Когда запускается Change Management?
Всегда.
Если изменение касается:
▪️кода,
▪️конфигурации,
▪️сети,
▪️доступов,
Все идёт через Change Request (CRQ).
Даже если:
▪️"это мелочь",
▪️"раньше так делали без согласования",
▪️"сроки горят".
Горящие сроки - не повод для горящего сервиса.
Как работает процесс?
1️⃣ Инициация изменения
Кто-то хочет что-то изменить.
Пишет CRQ:
▪️Что?
▪️Зачем?
▪️Как?
▪️Риски?
▪️План отката?
2️⃣ Оценка и согласование
Change Advisory Board (CAB) - или упрощённый аналог - смотрит:
▪️Нет ли конфликтов с другими изменениями?
▪️Есть ли ресурсы?
▪️Достаточно ли тестов?
▪️Кто утвердит?
3️⃣ Реализация
Изменение внедряется в согласованное окно.
С контролем, мониторингом, поддержкой на связи.
5️⃣ Проверка и закрытие
Работает ли?
Клиенты не страдают?
Метрики в норме?
→ Закрываем CRQ.
→ Фиксируем в базе знаний.
Кто участвует?
▪️Change Manager - не бюрократ, а координатор.
Он держит процесс в чистоте и вовремя.
▪️Заявитель - разработчик, инженер, SRE, менеджер продукта - кто инициирует изменение.
▪️CAB (Change Advisory Board) - представители поддержки, безопасности, SRE, продуктовой команды.
▪️Incident Manager / ТехПод - на связи, если что-то пойдёт не так.
Типичные ошибки
▪️«Это быстро, давайте без CRQ»
→ Быстро - не значит безопасно.
→ Без CRQ - без отката.
→ А значит, и без контроля.
▪️Change Management = бюрократия
Нет.
Это инструмент доверия.
Ты уверен, что никто не полезет в прод в пятницу вечером без плана.
▪️Не фиксируют результат
Решение есть.
CRQ закрыт.
А в базе знаний - пусто.
→ Через месяц - тот же инцидент.
Потому что "все забыли".
Зачем это измерять?
Потому что:
▪️Количество изменений, прошедших через процесс
Если 30% - значит, у вас полумрак.
Если 100% - значит, порядок.
▪️Процент изменений, вызвавших инциденты
Должен стремиться к нулю.
Если не стремится - где-то прорыв.
▪️Среднее время согласования
Не должно быть "ожидание 5 дней".
Но и не "подписали за 2 минуты".
▪️Доля экстренных изменений
Если больше 10% - значит, процесс не работает.
Люди обходят его.
Итог
Change Management - это тормоз.
Но не для прогресса.
Для хаоса.
Он не запрещает ехать.
Он не даёт врезаться.
#ChangeManagement #ITIL #TechSupport
Что? Зачем? И почему?
Incident Management - восстанавливает сервис.
Problem Management - убирает причину поломки.
Change Management - предотвращает сбои и улучшает сервис.
Если инцидент - пожар, проблема - неисправная проводка,
то Change - это разрешение на ремонт, проверенный план и подписанный акт.
Без него «быстрый фикс» становится бомбой.
Примеры:
▪️ Обновление операционной системы на критически важном сервере.
▪️ Развертывание новой версии корпоративного приложения.
▪️ Изменение конфигурации сетевого оборудования, чтобы увеличить пропускную способность.
▪️ Удаление устаревшего, неиспользуемого компонента инфраструктуры.
Что такое Change Management?
Это процесс контроля изменений в инфраструктуре, продуктах и процессах.
Не запрет на перемены.
А структура для безопасных изменений.
Основные цели Change Management
Цель - не замедлить.
Цель - предотвратить ущерб от "хорошей пятничной идеи в 20:37".
Почему это важно? Потому что:
▪️70% инцидентов начинаются с изменения.
▪️90% из них - с изменения, которое "никто не заметил".
▪️100% из них - с изменения, которое не прошло проверку.
Каждое изменение оценивается: что может пойти не так?
Кто пострадает?
Как откатим?
Не "сделаем и посмотрим".
А: протестируем → согласуем → внедрим → проверим.
Где, что, кем и когда было изменено?
Теперь вы можете ответить на этот вопрос.
Разработка, SRE, поддержка, безопасность - все в одном поле.
Никаких сюрпризов в релизе.
Не ради "процедуры".
А ради того, чтобы клиенты продолжали пользоваться сервисом.
Когда запускается Change Management?
Всегда.
Если изменение касается:
▪️кода,
▪️конфигурации,
▪️сети,
▪️доступов,
Все идёт через Change Request (CRQ).
Даже если:
▪️"это мелочь",
▪️"раньше так делали без согласования",
▪️"сроки горят".
Горящие сроки - не повод для горящего сервиса.
Как работает процесс?
Кто-то хочет что-то изменить.
Пишет CRQ:
▪️Что?
▪️Зачем?
▪️Как?
▪️Риски?
▪️План отката?
Change Advisory Board (CAB) - или упрощённый аналог - смотрит:
▪️Нет ли конфликтов с другими изменениями?
▪️Есть ли ресурсы?
▪️Достаточно ли тестов?
▪️Кто утвердит?
Изменение внедряется в согласованное окно.
С контролем, мониторингом, поддержкой на связи.
Работает ли?
Клиенты не страдают?
Метрики в норме?
→ Закрываем CRQ.
→ Фиксируем в базе знаний.
Кто участвует?
▪️Change Manager - не бюрократ, а координатор.
Он держит процесс в чистоте и вовремя.
▪️Заявитель - разработчик, инженер, SRE, менеджер продукта - кто инициирует изменение.
▪️CAB (Change Advisory Board) - представители поддержки, безопасности, SRE, продуктовой команды.
▪️Incident Manager / ТехПод - на связи, если что-то пойдёт не так.
Типичные ошибки
▪️«Это быстро, давайте без CRQ»
→ Быстро - не значит безопасно.
→ Без CRQ - без отката.
→ А значит, и без контроля.
▪️Change Management = бюрократия
Нет.
Это инструмент доверия.
Ты уверен, что никто не полезет в прод в пятницу вечером без плана.
▪️Не фиксируют результат
Решение есть.
CRQ закрыт.
А в базе знаний - пусто.
→ Через месяц - тот же инцидент.
Потому что "все забыли".
Зачем это измерять?
Потому что:
▪️Количество изменений, прошедших через процесс
Если 30% - значит, у вас полумрак.
Если 100% - значит, порядок.
▪️Процент изменений, вызвавших инциденты
Должен стремиться к нулю.
Если не стремится - где-то прорыв.
▪️Среднее время согласования
Не должно быть "ожидание 5 дней".
Но и не "подписали за 2 минуты".
▪️Доля экстренных изменений
Если больше 10% - значит, процесс не работает.
Люди обходят его.
Итог
Change Management - это тормоз.
Но не для прогресса.
Для хаоса.
Он не запрещает ехать.
Он не даёт врезаться.
#ChangeManagement #ITIL #TechSupport
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍3✍2🤝1
FS_Benchmark_2024.pdf
24.5 MB
7 KPIs of world-class ITSM. Что показал Freshservice Service Management Benchmark Report 2024?
KPI - это не просто цифры. Это ваш GPS в мире ITSM.
На основе данных 9 400+ организаций, 100 стран и 167 миллионов(❗️ ) тикетов отчёт FBR 2024 выделил 7 ключевых метрик, которые определяют эффективность сервис-деска. Не теория. Реальные цифры. Реальный рынок.
Это не просто отчёт. Это бенчмарк для тех, кто хочет быть выше рынка.
7 KPI, по которым измеряют зрелость поддержки:
1️⃣ CSAT - 97,4%
Почти полное удовлетворение клиентов. Теперь это не достижение - это ожидание.
2️⃣ ART - 24,15 часа
Среднее время решения запроса. Ваш результат ближе к этому числу?
3️⃣ AFRT - 10,82 часа
Первый ответ. Чем быстрее, тем лучше. Каждый час ожидания — снижение доверия.
4️⃣ FCR - 73,9%
Доля тикетов, закрытых с первого контакта. Ниже? Значит, процесс хромает.
5️⃣ Resolution SLA - 95,7%
Соблюдение сроков решения. Большинство тикетов закрывается вовремя. Но не у всех.
6️⃣ First Response SLA - 95,5%
Сроки первого ответа соблюдаются почти всегда. Исключения - риск для репутации.
7️⃣ AFAT - 17,47 часов
Время до назначения тикета специалисту. Каждый час в очереди - потеря лояльности.
Эти цифры - медиана по рынку.
Если вы ниже - догоняйте.
Если выше - вы впереди.
Если намного выше - вы задаёте тренд.
Где взять прорыв по метрикам?
Отчёт чётко показывает: технологии работают. Но только если они правильные.
1️⃣ Reply Suggester → -38,68% к первому ответу
Предлагает готовые, контекстно-ориентированные ответы прямо в интерфейсе специалиста.
Основано на базе знаний, истории обращения и типе запроса.
Специалист не ищет, не формулирует - он отправляет.
Результат: первый ответ за 6,56 часов вместо 10,82.
2️⃣ Ticket Summary Generator → -32,16% к времени решения
Автоматически создаёт краткое резюме длинного тикета.
Выделяет суть проблемы, действия специалистов, комментарии клиента.
Специалист не читает 50 сообщений - он видит суть за 10 секунд.
Итог: на треть быстрее закрываются сложные тикеты.
3️⃣ Help Article Generator → +15,48% к эффективности базы знаний
Автоматически создаёт статьи на основе реальных тикетов, переписок и внешних источников.
Решения из опыта специалистов сразу становятся доступны всей команде.
База знаний живёт и растёт без ручного труда.
Self-service становится мощнее. Повторяющиеся тикеты исчезают.
Итог
FBR 2024 - это не про «что делают другие».
Это про то, какие действия дают прирост.
Не гадайте.
Сравнивайте.
Улучшайте.
#Исследования #Тренды #TechSupport #Метрики
KPI - это не просто цифры. Это ваш GPS в мире ITSM.
На основе данных 9 400+ организаций, 100 стран и 167 миллионов(
Это не просто отчёт. Это бенчмарк для тех, кто хочет быть выше рынка.
7 KPI, по которым измеряют зрелость поддержки:
Почти полное удовлетворение клиентов. Теперь это не достижение - это ожидание.
Среднее время решения запроса. Ваш результат ближе к этому числу?
Первый ответ. Чем быстрее, тем лучше. Каждый час ожидания — снижение доверия.
Доля тикетов, закрытых с первого контакта. Ниже? Значит, процесс хромает.
Соблюдение сроков решения. Большинство тикетов закрывается вовремя. Но не у всех.
Сроки первого ответа соблюдаются почти всегда. Исключения - риск для репутации.
Время до назначения тикета специалисту. Каждый час в очереди - потеря лояльности.
Эти цифры - медиана по рынку.
Если вы ниже - догоняйте.
Если выше - вы впереди.
Если намного выше - вы задаёте тренд.
Где взять прорыв по метрикам?
Отчёт чётко показывает: технологии работают. Но только если они правильные.
Предлагает готовые, контекстно-ориентированные ответы прямо в интерфейсе специалиста.
Основано на базе знаний, истории обращения и типе запроса.
Специалист не ищет, не формулирует - он отправляет.
Результат: первый ответ за 6,56 часов вместо 10,82.
Автоматически создаёт краткое резюме длинного тикета.
Выделяет суть проблемы, действия специалистов, комментарии клиента.
Специалист не читает 50 сообщений - он видит суть за 10 секунд.
Итог: на треть быстрее закрываются сложные тикеты.
Автоматически создаёт статьи на основе реальных тикетов, переписок и внешних источников.
Решения из опыта специалистов сразу становятся доступны всей команде.
База знаний живёт и растёт без ручного труда.
Self-service становится мощнее. Повторяющиеся тикеты исчезают.
Итог
FBR 2024 - это не про «что делают другие».
Это про то, какие действия дают прирост.
Не гадайте.
Сравнивайте.
Улучшайте.
#Исследования #Тренды #TechSupport #Метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥5❤2🤝1
КтоЕстьКто в ТехПоде
За последнее годы, я провел больше 400 собеседований на tech и руководящие позиции, и этот опыт позволил мне сформулировать два ключевых наблюдения:
1️⃣ Успех приходит тогда, когда тебе не нужно «заставлять» себя работать, потому что процесс приносит радость. Когда твоя job становится хобби, ты не «ищешь время» на развитие, а просто не можешь без него жить. Следить за трендами, смотреть доклады с конференций, быть на острие - это не обязанность, а естественное состояние.
2️⃣ Существует разрыв в ожиданиях. Часто талантливые люди просто не понимают, каких конкретно знаний и навыков от них ждут на той или иной позиции. Они теряются в догадках, куда двигаться дальше.
Чтобы закрыть этот разрыв, я запускаю серию постов #КтоЕстьКто в #ТехПод с фокусом на роли в индустрии облачных провайдеров.
В первом выпуске разберем инженера технической поддержки 1-й линии (L1). Это тот самый старт, с которого начинаются многие великие карьеры в IT.
Вместе разберем:
▪️Что это за роль на самом деле
▪️Какие требования действительно важны
▪️Куда растут лучшие инженеры L1
А в конце серии постов вас ждет небольшой бонус -откровенный разговор о том, сколько можно зарабатывать на каждой из разобранных позиций.
#КтоЕстьКто #ТехПод #TechSupport
За последнее годы, я провел больше 400 собеседований на tech и руководящие позиции, и этот опыт позволил мне сформулировать два ключевых наблюдения:
Чтобы закрыть этот разрыв, я запускаю серию постов #КтоЕстьКто в #ТехПод с фокусом на роли в индустрии облачных провайдеров.
В первом выпуске разберем инженера технической поддержки 1-й линии (L1). Это тот самый старт, с которого начинаются многие великие карьеры в IT.
Вместе разберем:
▪️Что это за роль на самом деле
▪️Какие требования действительно важны
▪️Куда растут лучшие инженеры L1
А в конце серии постов вас ждет небольшой бонус -
#КтоЕстьКто #ТехПод #TechSupport
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥5
КтоЕстьКто: Инженер технической поддержки 1-й линии (L1 Support Engineer)
Обзор роли
Инженер L1 в облачном провайдере - это первая и ключевая точка контакта между клиентом и компанией. Основная задача - приём обращений, первичная диагностика и решение базовых инцидентов, связанных с облачной инфраструктурой и сервисами клиента. Роль требует понимания облачных технологий и направлена на максимально быстрое восстановление работоспособности услуг или грамотную эскалацию для минимизации времени простоя.
Цель позиции
Обеспечить оперативное и квалифицированное реагирование на входящие запросы клиентов, эффективно используя инструменты мониторинга и базу знаний. Минимизировать время на первичную обработку и эскалацию инцидентов, соблюдая SLA и обеспечивая высокий уровень клиентского сервиса.
Кому подходит роль
▪️ Выпускникам технических вузов, интересующимся облачными технологиями
▪️ Кандидатам, которые хотят построить карьеру в одной из самых востребованных областей IT
▪️ Тем, кто готов учиться, обладает развитыми коммуникативными навыками и хочет работать в динамичной среде
Роль и обязанности
▪️ Приём и обработка запросов клиентов
▪️ Приём инцидентов от клиентов через выделенные каналы связи: тикет-система, телефон, портал
▪️ Профессиональное и вежливое общение, направленное на уточнение и понимание сути проблемы
▪️ Проверка прав клиента на получение технической поддержки по договору
Первичная диагностика и решение
▪️ Оперативный сбор информации: идентификаторы облачных ресурсов (ID инстанса, ID проекта), ошибки с консоли управления, логи, скриншоты
▪️ Проведение базовой диагностики с использованием внутренних инструментов мониторинга и панелей управления: дашборды состояния сервисов, метрики виртуальных машин, статус сетевых интерфейсов
▪️ Решение распространённых проблем:
• Консультации по настройке и использованию панели управления (Cloud Console)
• Проблемы с доступом к виртуальным машинам (ВМ) через SSH/RDP
• Сброс паролей или ключей доступа к ВМ
• Консультации по работе с базовыми сервисами (объектное хранилище, CDN, базы данных)
• Проверка доступности сервисов в зоне клиента и идентификация массовых инцидентов
Эскалация инцидентов
▪️ Чёткое определение категории проблемы: сбой платформы, сетевые проблемы, проблемы с производительностью, консультационный запрос
▪️ Назначение тикетов соответствующим экспертным командам: L2/L3, сетевым инженерам, инженерам по хранению данных, специалистам по виртуализации - с полным комплектом собранной информации
▪️ Мониторинг статуса эскалированных тикетов и поддержание коммуникации с клиентом о прогрессе
Документирование и управление знаниями
▪️ Ведение детальной и точной записи по каждому инциденту в системе Service Desk
▪️ Создание и обновление статей в базе знаний на основе повторяющихся запросов: How-To, частые ошибки, рекомендации
▪️ Ведение внутренней документации по процедурам эскалации
Требования к навыкам
Обязательные Hard Skills
▪️ Базовое понимание облачных концепций: IaaS, PaaS, виртуальные машины, виртуальные сети, блочное и объектное хранилище
▪️ Базовые знания сетевых технологий: понимание TCP/IP, DNS, HTTP(S); умение использовать ping, traceroute, nslookup, curl для первичной диагностики
▪️ Основы безопасности: понимание разницы между логином/паролем и ключевой парой SSH, принципов работы файрволов
▪️ Работа с API: базовое понимание REST, методов запросов, кодов ответов
▪️ Опыт работы с CLI (командной строкой) на базовом уровне в Linux: работа с файловой системой, основные команды - ls, cd, cat, grep, ps, chmod, chown
▪️ Английский язык на уровне чтения технической документации (как минимум)
Продолжение в комментариях
#КтоЕстьКто #TechSupport
Обзор роли
Инженер L1 в облачном провайдере - это первая и ключевая точка контакта между клиентом и компанией. Основная задача - приём обращений, первичная диагностика и решение базовых инцидентов, связанных с облачной инфраструктурой и сервисами клиента. Роль требует понимания облачных технологий и направлена на максимально быстрое восстановление работоспособности услуг или грамотную эскалацию для минимизации времени простоя.
Цель позиции
Обеспечить оперативное и квалифицированное реагирование на входящие запросы клиентов, эффективно используя инструменты мониторинга и базу знаний. Минимизировать время на первичную обработку и эскалацию инцидентов, соблюдая SLA и обеспечивая высокий уровень клиентского сервиса.
Кому подходит роль
▪️ Выпускникам технических вузов, интересующимся облачными технологиями
▪️ Кандидатам, которые хотят построить карьеру в одной из самых востребованных областей IT
▪️ Тем, кто готов учиться, обладает развитыми коммуникативными навыками и хочет работать в динамичной среде
Роль и обязанности
▪️ Приём и обработка запросов клиентов
▪️ Приём инцидентов от клиентов через выделенные каналы связи: тикет-система, телефон, портал
▪️ Профессиональное и вежливое общение, направленное на уточнение и понимание сути проблемы
▪️ Проверка прав клиента на получение технической поддержки по договору
Первичная диагностика и решение
▪️ Оперативный сбор информации: идентификаторы облачных ресурсов (ID инстанса, ID проекта), ошибки с консоли управления, логи, скриншоты
▪️ Проведение базовой диагностики с использованием внутренних инструментов мониторинга и панелей управления: дашборды состояния сервисов, метрики виртуальных машин, статус сетевых интерфейсов
▪️ Решение распространённых проблем:
• Консультации по настройке и использованию панели управления (Cloud Console)
• Проблемы с доступом к виртуальным машинам (ВМ) через SSH/RDP
• Сброс паролей или ключей доступа к ВМ
• Консультации по работе с базовыми сервисами (объектное хранилище, CDN, базы данных)
• Проверка доступности сервисов в зоне клиента и идентификация массовых инцидентов
Эскалация инцидентов
▪️ Чёткое определение категории проблемы: сбой платформы, сетевые проблемы, проблемы с производительностью, консультационный запрос
▪️ Назначение тикетов соответствующим экспертным командам: L2/L3, сетевым инженерам, инженерам по хранению данных, специалистам по виртуализации - с полным комплектом собранной информации
▪️ Мониторинг статуса эскалированных тикетов и поддержание коммуникации с клиентом о прогрессе
Документирование и управление знаниями
▪️ Ведение детальной и точной записи по каждому инциденту в системе Service Desk
▪️ Создание и обновление статей в базе знаний на основе повторяющихся запросов: How-To, частые ошибки, рекомендации
▪️ Ведение внутренней документации по процедурам эскалации
Требования к навыкам
Обязательные Hard Skills
▪️ Базовое понимание облачных концепций: IaaS, PaaS, виртуальные машины, виртуальные сети, блочное и объектное хранилище
▪️ Базовые знания сетевых технологий: понимание TCP/IP, DNS, HTTP(S); умение использовать ping, traceroute, nslookup, curl для первичной диагностики
▪️ Основы безопасности: понимание разницы между логином/паролем и ключевой парой SSH, принципов работы файрволов
▪️ Работа с API: базовое понимание REST, методов запросов, кодов ответов
▪️ Опыт работы с CLI (командной строкой) на базовом уровне в Linux: работа с файловой системой, основные команды - ls, cd, cat, grep, ps, chmod, chown
▪️ Английский язык на уровне чтения технической документации (как минимум)
Продолжение в комментариях
#КтоЕстьКто #TechSupport
👍13🔥4❤2
SysAid-SOSM-2025.pdf
12.3 MB
The Rise of Agentic AI in ITSM (2025 Mega-Trends) SysAid
Развитие агентного ЫЫ в ITSM (Мега-тренды 2025 года) от SysAid
2025 год меняет ITSM: на смену автоматизации приходит агентный ИИ, который не просто выполняет задачи, а действует автономно - анализирует контекст, принимает решения и решает проблемы без участия человека.
Основные тренды, формирующие будущее ITSM:
▪️ Автономность вместо помощи: 52% руководителей ИТ хотят, чтобы ИИ автоматически устранял повторяющиеся инциденты. Агенты уже способны решать до 23% запросов уровня 1 без участия человека, автоматически классифицировать тикеты и выполнять рутинные операции - от сброса паролей до онбординга.
▪️ Чат-боты становятся обязательным стандартом: От «приятной опции» они превращаются в ядро сервис-деска, значительно снижая нагрузку на персонал. AI-усиленные порталы самообслуживания сокращают объем тикетов в 3 раза чаще, чем традиционные SSP, причем 43% организаций фиксируют снижение более чем на 30%.
▪️ Умное управление активами: 30% компаний до сих пор используют ручной учет активов, а 12% - вообще не имеют системы. Автоматизированное, основанное на ИИ отслеживание активов в реальном времени становится критически важным для снижения рисков, соблюдения норм и экономии средств.
▪️ Приоритеты внедрения: ИТ-команды в первую очередь ценят простоту использования (63%), безопасность (56%) и стоимость решения (52%). Успех зависит не только от технологий, но и от проектирования интерфейсов вокруг потребностей человека - подход, основанный на human-centered design.
▪️ Профилактика и прогнозирование: Агенты ИИ не ждут проблем - они их предотвращают. С помощью анализа данных в реальном времени, прогнозирования сбоев и автоматической инициации корректирующих действий они повышают надежность систем и снижают простои.
▪️ Реальная трансформация роли ИТ-персонала: Рутинные задачи передаются ИИ, освобождая специалистов для работы над сложными, креативными и стратегическими задачами. Это меняет саму природу ИТ-поддержки - от реактивной к проактивной и интеллектуальной.
▪️ Барьеры остаются: Несмотря на энтузиазм, ключевые препятствия - это опасения по поводу безопасности, конфиденциальности данных и нехватки ресурсов для внедрения.
▪️ Гибридная работа усиливает спрос: 38% лидеров планируют использовать ИИ для упрощения поддержки в условиях распределенных команд - особенно важно, чтобы решения были интуитивно понятны, как личный офисный helpdesk.
Вывод:
Успех зависит не от технологии самой по себе, а от её интеграции в процессы с фокусом на простоту, безопасность и удобство людей. Итог: пользователи получают мгновенную помощь, IT-специалисты - время на сложные задачи, а бизнес - надежную и экономичную IT-инфраструктуру.
#Исследования #Тренды
Развитие агентного ЫЫ в ITSM (Мега-тренды 2025 года) от SysAid
2025 год меняет ITSM: на смену автоматизации приходит агентный ИИ, который не просто выполняет задачи, а действует автономно - анализирует контекст, принимает решения и решает проблемы без участия человека.
Основные тренды, формирующие будущее ITSM:
▪️ Автономность вместо помощи: 52% руководителей ИТ хотят, чтобы ИИ автоматически устранял повторяющиеся инциденты. Агенты уже способны решать до 23% запросов уровня 1 без участия человека, автоматически классифицировать тикеты и выполнять рутинные операции - от сброса паролей до онбординга.
▪️ Чат-боты становятся обязательным стандартом: От «приятной опции» они превращаются в ядро сервис-деска, значительно снижая нагрузку на персонал. AI-усиленные порталы самообслуживания сокращают объем тикетов в 3 раза чаще, чем традиционные SSP, причем 43% организаций фиксируют снижение более чем на 30%.
▪️ Умное управление активами: 30% компаний до сих пор используют ручной учет активов, а 12% - вообще не имеют системы. Автоматизированное, основанное на ИИ отслеживание активов в реальном времени становится критически важным для снижения рисков, соблюдения норм и экономии средств.
▪️ Приоритеты внедрения: ИТ-команды в первую очередь ценят простоту использования (63%), безопасность (56%) и стоимость решения (52%). Успех зависит не только от технологий, но и от проектирования интерфейсов вокруг потребностей человека - подход, основанный на human-centered design.
▪️ Профилактика и прогнозирование: Агенты ИИ не ждут проблем - они их предотвращают. С помощью анализа данных в реальном времени, прогнозирования сбоев и автоматической инициации корректирующих действий они повышают надежность систем и снижают простои.
▪️ Реальная трансформация роли ИТ-персонала: Рутинные задачи передаются ИИ, освобождая специалистов для работы над сложными, креативными и стратегическими задачами. Это меняет саму природу ИТ-поддержки - от реактивной к проактивной и интеллектуальной.
▪️ Барьеры остаются: Несмотря на энтузиазм, ключевые препятствия - это опасения по поводу безопасности, конфиденциальности данных и нехватки ресурсов для внедрения.
▪️ Гибридная работа усиливает спрос: 38% лидеров планируют использовать ИИ для упрощения поддержки в условиях распределенных команд - особенно важно, чтобы решения были интуитивно понятны, как личный офисный helpdesk.
Вывод:
Успех зависит не от технологии самой по себе, а от её интеграции в процессы с фокусом на простоту, безопасность и удобство людей. Итог: пользователи получают мгновенную помощь, IT-специалисты - время на сложные задачи, а бизнес - надежную и экономичную IT-инфраструктуру.
#Исследования #Тренды
🔥11👍5❤1
Проиграл на первом шаге.
Или как НЕ нужно искать работу в технической поддержке.
Ко мне откликнулся кандидат на позицию инженера.
Резюме - безупречное.
Опыт - в компании, которая наш прямой конкурент.
Знания - всё, что нужно.
Я даже подумал: «Вот он - тот самый человек. Минимум адаптации. Максимум пользы. Может, даже чему-то нас научит».
И тут начинается самое интересное.
13 лет в индустрии - и я не пишу рекрутеру. Я пишу напрямую.
Тому, кто руководит техподом у конкурента.
Сообщение: «Привет. Такой-то у тебя работал? Ушёл пару месяцев назад. Что скажешь?»
Ответ - через 3 минуты.
Две строки.
«Такого человека у меня никогда не было. Более того - он вообще никогда не работал в нашей компании».
Что это значит?
Это не ошибка.
Это не опечатка.
Это сознательная ложь.
И она ломает всё - с самого первого шага.
Потому что в техподдержке, как нигде, всё строится на доверии.
Если его нет на нулевом этапе - дальше ничего хорошего не будет.
Никаких «но», «вдруг», «может быть».
Нет доверия - нет сотрудничества.
Но история на этом не заканчивается.
Она только начинается.
Потому что такие случаи - не редкость.
Их становится больше.
Но - и это важно - российский big tech начал реагировать.
Активно.
Системно.
И это дает надежду.
Я видел одного. Потом второго. Потом понял - это не исключения.
Скоро расскажу про новый мейнстрим: как люди без опыта, но подготовленные «менторами» и с «правильным» резюме, прорываются в топовые IT-компании.
Метод - обман.
Цель - зарплата.
Результат - пожар. Ваш.
#Собеседование #TechSupport
Или как НЕ нужно искать работу в технической поддержке.
Ко мне откликнулся кандидат на позицию инженера.
Резюме - безупречное.
Опыт - в компании, которая наш прямой конкурент.
Знания - всё, что нужно.
Я даже подумал: «Вот он - тот самый человек. Минимум адаптации. Максимум пользы. Может, даже чему-то нас научит».
И тут начинается самое интересное.
13 лет в индустрии - и я не пишу рекрутеру. Я пишу напрямую.
Тому, кто руководит техподом у конкурента.
Сообщение: «Привет. Такой-то у тебя работал? Ушёл пару месяцев назад. Что скажешь?»
Ответ - через 3 минуты.
Две строки.
«Такого человека у меня никогда не было. Более того - он вообще никогда не работал в нашей компании».
Что это значит?
Это не ошибка.
Это не опечатка.
Это сознательная ложь.
И она ломает всё - с самого первого шага.
Потому что в техподдержке, как нигде, всё строится на доверии.
Если его нет на нулевом этапе - дальше ничего хорошего не будет.
Никаких «но», «вдруг», «может быть».
Нет доверия - нет сотрудничества.
Но история на этом не заканчивается.
Она только начинается.
Потому что такие случаи - не редкость.
Их становится больше.
Но - и это важно - российский big tech начал реагировать.
Активно.
Системно.
И это дает надежду.
Я видел одного. Потом второго. Потом понял - это не исключения.
Скоро расскажу про новый мейнстрим: как люди без опыта, но подготовленные «менторами» и с «правильным» резюме, прорываются в топовые IT-компании.
Метод - обман.
Цель - зарплата.
Результат - пожар. Ваш.
#Собеседование #TechSupport
👍9🔥5🤔3🤝2😁1
Волчий билет: почему тактика обмана на собеседовании ведет к карьерному краху
В индустрии растёт не тренд - а паразит.
Сами себя называют «ИТ-волки». В этом сообществе ~80 тысяч подписчиков.
Феномен? Да.
Полезный? Нет.
Это сообщество не учит работать.
Оно учит - как не работать, но получать.
Как выдать чужой опыт за свой.
Как пройти техническое собеседование, ничего не зная.
Как цитировать Трудовой Кодекс, чтобы не уволили - даже если вы ничего не делаете.
И как «накрутить» карьеру, которой не было.
Это не «недобросовестный кандидат».
Это - системный риск.
Вот что это даёт на практике:
▪️ Утечки данных от внутреннего инсайдера.
▪️ Сбои из-за некомпетентности - не злого умысла, а просто незнания.
▪️ Потеря времени на поиск/найм/собеседование
▪️ Неверные кадровые решения, которые тянут за собой простой систем, коллапс согласований, недовольство клиентов.
▪️ А в худшем случае - банкротство.
Вы получаете историю в духе Knight Capital Group.
2012 год.
Американская брокерская компания.
Один сотрудник - без должного контроля - запустил обновление ПО.
Старый код не удалили. Новый - активировали неправильно.
Система начала слать миллионы ложных ордеров.
150 акций в секунду.
За 45 минут - убытки в $440 миллионов.
Больше, чем весь капитал компании.
Результат? Банкротство.
Причина? Некомпетентность. Недоработок в процессах тестирования и контроля версий ПО. Отсутствие контроля. Доверие там, где нужно было проверять.
Но индустрия уже реагирует.
Начинает сопротивляться. Службы безопасности крупных игроков уже ведут тихий мониторинг этих сообществ. Участники получают «красные метки», даже не догадываясь, почему их резюме летит в корзину после «успешного» коучинга. МинЦифры работает над цифровым профилем - чтобы работодатель видел всю карьерную историю, а не только то, что в резюме.
На Инфоцыган когда-то тоже закрывали глаза, пока их не прикрыли за месяц.
Моя позиция проста: волкам - волчий билет.
Тактически обман может принести быстрый результат. Стратегически же ложь всегда вскрывается. И падение с высоты мнимого успеха будет болезненным.
Вывод старый как мир: чтобы чего-то добиться, нужно учиться. Затем работать. И повторять этот цикл снова. Коротких путей в профессионализме нет.
#Собеседование #TechSupport
В индустрии растёт не тренд - а паразит.
Сами себя называют «ИТ-волки». В этом сообществе ~80 тысяч подписчиков.
Феномен? Да.
Полезный? Нет.
Это сообщество не учит работать.
Оно учит - как не работать, но получать.
Как выдать чужой опыт за свой.
Как пройти техническое собеседование, ничего не зная.
Как цитировать Трудовой Кодекс, чтобы не уволили - даже если вы ничего не делаете.
И как «накрутить» карьеру, которой не было.
Это не «недобросовестный кандидат».
Это - системный риск.
Вот что это даёт на практике:
▪️ Утечки данных от внутреннего инсайдера.
▪️ Сбои из-за некомпетентности - не злого умысла, а просто незнания.
▪️ Потеря времени на поиск/найм/собеседование
▪️ Неверные кадровые решения, которые тянут за собой простой систем, коллапс согласований, недовольство клиентов.
▪️ А в худшем случае - банкротство.
Вы получаете историю в духе Knight Capital Group.
2012 год.
Американская брокерская компания.
Один сотрудник - без должного контроля - запустил обновление ПО.
Старый код не удалили. Новый - активировали неправильно.
Система начала слать миллионы ложных ордеров.
150 акций в секунду.
За 45 минут - убытки в $440 миллионов.
Больше, чем весь капитал компании.
Результат? Банкротство.
Причина? Некомпетентность. Недоработок в процессах тестирования и контроля версий ПО. Отсутствие контроля. Доверие там, где нужно было проверять.
Но индустрия уже реагирует.
Начинает сопротивляться. Службы безопасности крупных игроков уже ведут тихий мониторинг этих сообществ. Участники получают «красные метки», даже не догадываясь, почему их резюме летит в корзину после «успешного» коучинга. МинЦифры работает над цифровым профилем - чтобы работодатель видел всю карьерную историю, а не только то, что в резюме.
На Инфоцыган когда-то тоже закрывали глаза, пока их не прикрыли за месяц.
Моя позиция проста: волкам - волчий билет.
Тактически обман может принести быстрый результат. Стратегически же ложь всегда вскрывается. И падение с высоты мнимого успеха будет болезненным.
Вывод старый как мир: чтобы чего-то добиться, нужно учиться. Затем работать. И повторять этот цикл снова. Коротких путей в профессионализме нет.
#Собеседование #TechSupport
👍14🔥9
30% штата - поддержка. Что ещё делает Точку не похожей на банк
Вы когда-нибудь слышали, чтобы банк снимал про себя кино?
Не рекламный ролик с «счастливой майонезной семьёй», а честный, живой рассказ о том, как устроена компания, для которой клиент - не метрика, а человек.
«Точка» - сделала именно это.
Они нанимают не по дипломам, а по эмпатии. Часто - из сферы HoReCa, где слушать клиента -это мышечная память. Они отменили деление на «випов» и «простых смертных». Нет никаких KPI вроде среднего времени на звонок. Сотрудник может самостоятельно, без согласований, подарить клиенту подарок.
Но как это работает изнутри? Как не скатиться в хаос?
Ключ - в халократии. Это когда у тебя есть свобода, но и ответственность за нее - тоже твоя. 50% времени ты тратишь на основную работу, а остальное - на то, что считаешь полезным.
Представьте диалог сотрудника с руководителем:
- Что мне делать?
- Вот цели, стратегия и ценности. Приноси пользу. Решай сам, как.
Спойлер: идеи «Точки» - это не изобретение велосипеда, а гениальное заимствование и адаптация лучших мировых практик.
▪️Отказ от AHT и принцип «провести с клиентом хоть целый день» - это прямая отсылка к культуре Zappos и книге Тони Шея «Доставляя счастье».
▪️Право сотрудника дарить подарки и идея, что мимо проблемы клиента не пройдет никто - это устав отелей The Ritz-Carlton, который описал в своих правилах основатель Хорст Шульце.
▪️Собеседования, основанные на ценностях компании - это отголосок принципов лидерства Amazon и их знаменитого процесса найма с «Bar Raiser».
▪️Реальные полномочия у рядовых сотрудников - об этом подробно написано в книге Джона Шоула «Реальные полномочия: Самостоятельность сотрудников как ключ к успеху».
▪️Легенда про кирпичи. Даже гендир в фильме не вспомнил истоки, но эта история очень напоминает практику одного девелопера: когда компания зарабатывала 100 млн рублей, они приносили в кабинет кирпич и складывали его в стену. Символично и осязаемо.
▪️А их фокус на малом и среднем бизнесе очень напоминает стратегию американского банка Capital One, который также начал с этого.
Вывод? Этот фильм смотрится на одном дыхании, даже на скорости 2x. Это редкий и честный взгляд на компанию, которая не на словах, а на деле поставила клиента в центр. Рекомендую к просмотру всем, кто хочет понять, каким должен быть сервис. Точка.
#TechSupport
Вы когда-нибудь слышали, чтобы банк снимал про себя кино?
Не рекламный ролик с «счастливой майонезной семьёй», а честный, живой рассказ о том, как устроена компания, для которой клиент - не метрика, а человек.
«Точка» - сделала именно это.
Они нанимают не по дипломам, а по эмпатии. Часто - из сферы HoReCa, где слушать клиента -это мышечная память. Они отменили деление на «випов» и «простых смертных». Нет никаких KPI вроде среднего времени на звонок. Сотрудник может самостоятельно, без согласований, подарить клиенту подарок.
Но как это работает изнутри? Как не скатиться в хаос?
Ключ - в халократии. Это когда у тебя есть свобода, но и ответственность за нее - тоже твоя. 50% времени ты тратишь на основную работу, а остальное - на то, что считаешь полезным.
Представьте диалог сотрудника с руководителем:
- Что мне делать?
- Вот цели, стратегия и ценности. Приноси пользу. Решай сам, как.
Спойлер: идеи «Точки» - это не изобретение велосипеда, а гениальное заимствование и адаптация лучших мировых практик.
▪️Право сотрудника дарить подарки и идея, что мимо проблемы клиента не пройдет никто - это устав отелей The Ritz-Carlton, который описал в своих правилах основатель Хорст Шульце.
▪️Собеседования, основанные на ценностях компании - это отголосок принципов лидерства Amazon и их знаменитого процесса найма с «Bar Raiser».
▪️Реальные полномочия у рядовых сотрудников - об этом подробно написано в книге Джона Шоула «Реальные полномочия: Самостоятельность сотрудников как ключ к успеху».
▪️Легенда про кирпичи. Даже гендир в фильме не вспомнил истоки, но эта история очень напоминает практику одного девелопера: когда компания зарабатывала 100 млн рублей, они приносили в кабинет кирпич и складывали его в стену. Символично и осязаемо.
▪️А их фокус на малом и среднем бизнесе очень напоминает стратегию американского банка Capital One, который также начал с этого.
Вывод? Этот фильм смотрится на одном дыхании, даже на скорости 2x. Это редкий и честный взгляд на компанию, которая не на словах, а на деле поставила клиента в центр. Рекомендую к просмотру всем, кто хочет понять, каким должен быть сервис. Точка.
#TechSupport
YouTube
Компания с Урала, перевернувшая игру — 20 млрд прибыли без регламентов | В чем феномен Точка Банк?
Подписывайтесь на мой тг, чтобы поднимать свою бизнес-насмотренность – там я регулярно делюсь интересными историями предпринимателей: https://news.1rj.ru/str/+P1FC7e-57wViM2Fi
#михаилгребенюк #гребенюк #точкабанк #банк #бизнес #деньги #предпринимательство #бизнесидеи…
#михаилгребенюк #гребенюк #точкабанк #банк #бизнес #деньги #предпринимательство #бизнесидеи…
🔥8👍4❤3👏3🤣2
Меняют индустрию, как Tesla
ServiceNow - компания, которая стала де-факто стандартом в ITSM: её платформу используют 85% компаний из Fortune 500.
Недавно они представили AI Experience - новую надстройку для управления ИИ и автоматизацией в корпоративной среде.
Суть решения - единый интерфейс, объединяющий разные типы AI-агентов: текстовые, голосовые, визуальные и веб-агенты.
Цель - упростить взаимодействие пользователя с системой, чтобы задачи решались быстрее и без необходимости повторно описывать проблему.
В демонстрационном видео показано, как менеджер в Adobe голосом даёт команду: одобрить заявку. Одновременно с этим запускается диагностика проблем с VPN. Система автоматически создаёт заявку, анализирует телеметрию, проверяет интеграции и предлагает решение. Хотя ее никто не просил :)
Также AI Experience умеет работать со скриншотами ошибок - распознаёт визуальный контекст и подбирает релевантные действия.
Платформа собирает данные о работе процессов и даёт аналитические рекомендации по их улучшению.
Клиенты вроде Adobe, Pure Storage и Bell Canada сообщают о сокращении времени на решение инцидентов и росте эффективности.
Важный акцент сделан на управлении и безопасности ИИ: все агенты и данные работают в рамках единой контролируемой экосистемы, а не как набор разрозненных инструментов.
Такие решения требуют не только точности ИИ, но и чётких процессов, fallback-механизмов и человеческого контроля - особенно в production-среде.
В целом, AI Experience - не просто «ещё один ИИ-чат», а попытка системно интегрировать искусственный интеллект в рабочие процессы поддержки.
Работает ли это на практике - покажет время.
Но направление, безусловно, заслуживает внимания.
#TechSupport #AI
ServiceNow - компания, которая стала де-факто стандартом в ITSM: её платформу используют 85% компаний из Fortune 500.
Недавно они представили AI Experience - новую надстройку для управления ИИ и автоматизацией в корпоративной среде.
Суть решения - единый интерфейс, объединяющий разные типы AI-агентов: текстовые, голосовые, визуальные и веб-агенты.
Цель - упростить взаимодействие пользователя с системой, чтобы задачи решались быстрее и без необходимости повторно описывать проблему.
В демонстрационном видео показано, как менеджер в Adobe голосом даёт команду: одобрить заявку. Одновременно с этим запускается диагностика проблем с VPN. Система автоматически создаёт заявку, анализирует телеметрию, проверяет интеграции и предлагает решение. Хотя ее никто не просил :)
Также AI Experience умеет работать со скриншотами ошибок - распознаёт визуальный контекст и подбирает релевантные действия.
Платформа собирает данные о работе процессов и даёт аналитические рекомендации по их улучшению.
Клиенты вроде Adobe, Pure Storage и Bell Canada сообщают о сокращении времени на решение инцидентов и росте эффективности.
Важный акцент сделан на управлении и безопасности ИИ: все агенты и данные работают в рамках единой контролируемой экосистемы, а не как набор разрозненных инструментов.
Такие решения требуют не только точности ИИ, но и чётких процессов, fallback-механизмов и человеческого контроля - особенно в production-среде.
В целом, AI Experience - не просто «ещё один ИИ-чат», а попытка системно интегрировать искусственный интеллект в рабочие процессы поддержки.
Работает ли это на практике - покажет время.
Но направление, безусловно, заслуживает внимания.
#TechSupport #AI
YouTube
Introducing AI Experience by ServiceNow
Join us to meet the UI that puts AI to work, with voice, text, image, and web agents in one AI interface. See it in action during a visionary demo showcasing how Adobe is using ServiceNow to create AI-first experiences that drive real business outcomes. Come…
🔥6👍5
Service Request Management (SRM)
Что? Зачем? И почему это не «просто тикеты»?
Service Request Management (SRM) - обеспечивает выполнение рутинных запросов пользователей, чтобы они могли работать без лишних задержек.
Что такое сервисный запрос (или ЗНО - запрос на обслуживание)?
Это запрос пользователя на доступ к стандартизированным и предварительно одобренным услугам, информации, консультациям или рутинным изменениям. Отличительные черты:
▪️Предсказуемость: это не внезапный сбой, а ожидаемая потребность.
▪️Стандартизация: есть чёткий процесс выполнения.
▪️Низкий риск: обычно не приводит к критическим сбоям.
Примеры сервисных запросов
▪️сброс пароля, установка ПО, запрос нового оборудования, доступ к VPN.
▪️предоставление доступа новым сотрудникам, запрос оборудования, отзыв доступа при увольнении.
▪️настройка инструментов для отчётов.
▪️настройка мобильных устройств, доступ к Wi-Fi, выделение облачных ресурсов.
Что такое Service Request Management (SRM)?
Это процесс управления и выполнения запросов пользователей на IT-услуги. SRM - сердце ITSM, которое помогает оперативно и качественно обрабатывать запросы, от сброса пароля до выдачи нового оборудования.
Цель SRM: не просто закрыть запрос, а сделать это так, чтобы пользователь остался доволен, а поддержка не тратила лишнее время. Это про скорость, прозрачность и user-friendly подход.
Основные цели SRM:
1️⃣ Ускорить выполнение запросов.
Автоматизировать рутину, чтобы запросы решались в реальном времени.
2️⃣ Повысить удовлетворённость пользователей.
Прозрачные процессы и чёткая коммуникация создают позитивный опыт взаимодействия с IT.
3️⃣ Оптимизировать ресурсы IT-команды.
Категоризация и приоритизация помогают распределять задачи там, где они действительно нужны.
5️⃣ Обеспечить видимость и контроль.
Руководители видят статус запросов, тренды и узкие места, чтобы принимать взвешенные решения.
5️⃣ Двигать непрерывное улучшение.
Анализ данных запросов помогает находить проблемы и улучшать процессы.
Как работает процесс SRM?
Процесс SRM - это структурированный путь от подачи запроса до его выполнения. Всё ради удовлетворённости клиентов.
1️⃣ Запрос - через самообслуживания портал, почту, чат.
2️⃣ Логирование - уникальный ID, статус, трекинг.
3️⃣ Классификация - тип, команда, SLA.
4️⃣ Автоматизация - если можно - система делает сама.
5️⃣ Исполнение - человек вмешивается только там, где нужно.
6️⃣ Обратная связь - пользователь знает: «Всё готово».
7️⃣ Анализ - что можно автоматизировать/улучшить завтра?
Кто участвует?
▪️Пользователь/Клиент - подаёт запрос.
▪️IT-инженеры (L1/L2/L3) /Финансы/ИБ-специалисты - исполняет (или одобряет).
▪️ Менеджер процесса - настраивает процессы, каталог услуг, SLA
Приоритизация запросов: не всё сразу
Это основа управления очередями запросов. Она учитывает:
▪️Влияние: Насколько запрос важен для бизнеса?
▪️Срочность: Как быстро это нужно сделать?
Пример категорий:
▪️Критичный (P1): Запросы, влияющие на всю компания, от руководства (VIP-клиентов)
▪️Высокий (P2): Запросы, влияющие на целый отдел, важные проекты
▪️Средний (P3): Установка стандартного ПО
▪️Низкий (P4): Запрос информации, консультация
Что важно измерять?
▪️% автоматизированных запросов - чем выше, тем меньше рутины.
▪️Среднее время выполнения - если растёт, значит, что-то ломается.
▪️Удовлетворённость (CSAT/CDSAT) - пользователь доволен или злится?
▪️SLA - сколько заявок закрыты в срок.
Типичные ошибки
▪️Смешивают с инцидентами
Разные процессы. Разные цели.
▪️Нет self-service портала
Инженеры тонут в рутине.
▪️Нет каталога услуг
Каждый запрос - как первый.
▪️Не автоматизируют очевидное
Пароль сбросили 500 раз - и всё ещё вручную?
▪️Плохая коммуникация: пользователь не знает, на каком этапе его запрос, и теряет доверие.
▪️Игнорирование приоритизации: срочные запросы тонут среди незначительных.
▪️Отсутствие анализа: без обратной связи и метрик процесс не улучшается.
Итог:
Хороший SRM - когда никто не замечает поддержку
Потому что всё просто работает.
#SRM #ITSM #ITIL #TechSupport
Что? Зачем? И почему это не «просто тикеты»?
Service Request Management (SRM) - обеспечивает выполнение рутинных запросов пользователей, чтобы они могли работать без лишних задержек.
Что такое сервисный запрос (или ЗНО - запрос на обслуживание)?
Это запрос пользователя на доступ к стандартизированным и предварительно одобренным услугам, информации, консультациям или рутинным изменениям. Отличительные черты:
▪️Предсказуемость: это не внезапный сбой, а ожидаемая потребность.
▪️Стандартизация: есть чёткий процесс выполнения.
▪️Низкий риск: обычно не приводит к критическим сбоям.
Примеры сервисных запросов
▪️сброс пароля, установка ПО, запрос нового оборудования, доступ к VPN.
▪️предоставление доступа новым сотрудникам, запрос оборудования, отзыв доступа при увольнении.
▪️настройка инструментов для отчётов.
▪️настройка мобильных устройств, доступ к Wi-Fi, выделение облачных ресурсов.
Что такое Service Request Management (SRM)?
Это процесс управления и выполнения запросов пользователей на IT-услуги. SRM - сердце ITSM, которое помогает оперативно и качественно обрабатывать запросы, от сброса пароля до выдачи нового оборудования.
Цель SRM: не просто закрыть запрос, а сделать это так, чтобы пользователь остался доволен, а поддержка не тратила лишнее время. Это про скорость, прозрачность и user-friendly подход.
Основные цели SRM:
Автоматизировать рутину, чтобы запросы решались в реальном времени.
Прозрачные процессы и чёткая коммуникация создают позитивный опыт взаимодействия с IT.
Категоризация и приоритизация помогают распределять задачи там, где они действительно нужны.
Руководители видят статус запросов, тренды и узкие места, чтобы принимать взвешенные решения.
Анализ данных запросов помогает находить проблемы и улучшать процессы.
Как работает процесс SRM?
Процесс SRM - это структурированный путь от подачи запроса до его выполнения. Всё ради удовлетворённости клиентов.
Кто участвует?
▪️Пользователь/Клиент - подаёт запрос.
▪️IT-инженеры (L1/L2/L3) /Финансы/ИБ-специалисты - исполняет (или одобряет).
▪️ Менеджер процесса - настраивает процессы, каталог услуг, SLA
Приоритизация запросов: не всё сразу
Это основа управления очередями запросов. Она учитывает:
▪️Влияние: Насколько запрос важен для бизнеса?
▪️Срочность: Как быстро это нужно сделать?
Пример категорий:
▪️Критичный (P1): Запросы, влияющие на всю компания, от руководства (VIP-клиентов)
▪️Высокий (P2): Запросы, влияющие на целый отдел, важные проекты
▪️Средний (P3): Установка стандартного ПО
▪️Низкий (P4): Запрос информации, консультация
Что важно измерять?
▪️% автоматизированных запросов - чем выше, тем меньше рутины.
▪️Среднее время выполнения - если растёт, значит, что-то ломается.
▪️Удовлетворённость (CSAT/CDSAT) - пользователь доволен или злится?
▪️SLA - сколько заявок закрыты в срок.
Типичные ошибки
▪️Смешивают с инцидентами
Разные процессы. Разные цели.
▪️Нет self-service портала
Инженеры тонут в рутине.
▪️Нет каталога услуг
Каждый запрос - как первый.
▪️Не автоматизируют очевидное
Пароль сбросили 500 раз - и всё ещё вручную?
▪️Плохая коммуникация: пользователь не знает, на каком этапе его запрос, и теряет доверие.
▪️Игнорирование приоритизации: срочные запросы тонут среди незначительных.
▪️Отсутствие анализа: без обратной связи и метрик процесс не улучшается.
Итог:
Хороший SRM - когда никто не замечает поддержку
Потому что всё просто работает.
#SRM #ITSM #ITIL #TechSupport
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍3🤝1
TechSupportConf'25. Как это было?
Публичных конференций, где говорят на нашем языке, в России не было. До этой недели.
Давайте разберемся, почему это событие стало настоящим открытием.
Во-первых, это действительно первая конференция для специалистов техподдержки в России. Глоток свежего воздуха на фоне стандартных IT-ивентов. За рубежом такие события есть, слежу за ними онлайн, но увидеть что-то подобное у нас, да еще и оффлайн - это другое. Во-вторых, я имел честь выступить там. А в-третьих… это же Петербург! Кто не любит этот город?
Конференция длилась два дня, и каждый из них был насыщен по максимуму. Первый день - это посещение дата-центров и техподов компаний «Миран» и «Selectel». Второй - доклады и обмен опытом. Но давайте начнем с самого начала - с первого дня, который удивил даже меня, видавшего виды.
День первый. Утро. Миран.
Экскурсия в дата-центр. Я думал, меня уже ничем не удивить. Человека, который на заре карьеры два года проработал в обслуживании дата-центров крупной IT-компании, создающей лучшие антивирусы. Стойки, серверы, коммутаторы, системы охлаждения, питание, ДГУ - все это видел сотни раз и для меня это родной язык.
Но это до тех пор, пока экскурсию не проводит человек, который строил этот ДЦ с нуля.
Виталий. Его подача, глубина знаний и экспертиза - выше всяких похвал. Не просто «вот система охлаждения», а «вот почему мы выбрали эти компрессоры, какие были подводные камни и почему это решение оказалось надежнее». Это был не тур по музею, а мастер-класс по принятию решений.
Затем - техпод Мирана. 80 человек в компании, 21 из них - в поддержке. Вопрос: чем можно выделиться на рынке colocation, где все делают одно и тоже?
Ответ: только сервисом. И они это поняли раньше конкурентов.
Что еще? Их фишка - прозрачность. Они сделали визуализацию, где каждый инженер видит свой вклад в общее дело. Штука простая, но рабочая.
День. Selectel. Собираю камни, как Танос💎
После «Мирана» нас погрузили в автобус и отвезли в Selectel. 40 минут экскурсионной поездки - и мы на месте. Сначала рассказали про команду Customer Success. Кто это такие и зачем они нужны?
Это голос крупных клиентов внутри компании. Их задача - сделать так, чтобы проблемы решались быстрее, а клиенту не приходилось доказывать, что он не верблюд.
После был обед. Но больше всего хотелось общения про техподдержку, особенно в облаке. Как Танос собирал камни бесконечности, так я собираю информацию с рынка облачных провайдеров. Какая структура поддержки? Сколько линий? Какие KPI? Идиллия с разработкой или классические битвы? Ответы я получил. На многие вопросы. И это оказалось ценно. А экскурсия по дата-центру стала приятным бонусом.
Итог дня:
К 78 причинам любить Петербург добавилась ещё одна - место, где рождаются крутые отраслевые инициативы.
Продолжение - во второй серии нашего сериала «TechSupportConf: Как это было?». Расскажу, что я такого наговорил со сцены, что заставило народ просыпаться, какие доклады прозвучали у коллег и что полезного можно вынести из таких мероприятий.
#TechSupport #TechSupportConf
Публичных конференций, где говорят на нашем языке, в России не было. До этой недели.
Давайте разберемся, почему это событие стало настоящим открытием.
Во-первых, это действительно первая конференция для специалистов техподдержки в России. Глоток свежего воздуха на фоне стандартных IT-ивентов. За рубежом такие события есть, слежу за ними онлайн, но увидеть что-то подобное у нас, да еще и оффлайн - это другое. Во-вторых, я имел честь выступить там. А в-третьих… это же Петербург! Кто не любит этот город?
Конференция длилась два дня, и каждый из них был насыщен по максимуму. Первый день - это посещение дата-центров и техподов компаний «Миран» и «Selectel». Второй - доклады и обмен опытом. Но давайте начнем с самого начала - с первого дня, который удивил даже меня, видавшего виды.
День первый. Утро. Миран.
Экскурсия в дата-центр. Я думал, меня уже ничем не удивить. Человека, который на заре карьеры два года проработал в обслуживании дата-центров крупной IT-компании, создающей лучшие антивирусы. Стойки, серверы, коммутаторы, системы охлаждения, питание, ДГУ - все это видел сотни раз и для меня это родной язык.
Но это до тех пор, пока экскурсию не проводит человек, который строил этот ДЦ с нуля.
Виталий. Его подача, глубина знаний и экспертиза - выше всяких похвал. Не просто «вот система охлаждения», а «вот почему мы выбрали эти компрессоры, какие были подводные камни и почему это решение оказалось надежнее». Это был не тур по музею, а мастер-класс по принятию решений.
Затем - техпод Мирана. 80 человек в компании, 21 из них - в поддержке. Вопрос: чем можно выделиться на рынке colocation, где все делают одно и тоже?
Ответ: только сервисом. И они это поняли раньше конкурентов.
Что еще? Их фишка - прозрачность. Они сделали визуализацию, где каждый инженер видит свой вклад в общее дело. Штука простая, но рабочая.
День. Selectel. Собираю камни, как Танос
После «Мирана» нас погрузили в автобус и отвезли в Selectel. 40 минут экскурсионной поездки - и мы на месте. Сначала рассказали про команду Customer Success. Кто это такие и зачем они нужны?
Это голос крупных клиентов внутри компании. Их задача - сделать так, чтобы проблемы решались быстрее, а клиенту не приходилось доказывать, что он не верблюд.
После был обед. Но больше всего хотелось общения про техподдержку, особенно в облаке. Как Танос собирал камни бесконечности, так я собираю информацию с рынка облачных провайдеров. Какая структура поддержки? Сколько линий? Какие KPI? Идиллия с разработкой или классические битвы? Ответы я получил. На многие вопросы. И это оказалось ценно. А экскурсия по дата-центру стала приятным бонусом.
Итог дня:
К 78 причинам любить Петербург добавилась ещё одна - место, где рождаются крутые отраслевые инициативы.
Продолжение - во второй серии нашего сериала «TechSupportConf: Как это было?». Расскажу, что я такого наговорил со сцены, что заставило народ просыпаться, какие доклады прозвучали у коллег и что полезного можно вынести из таких мероприятий.
#TechSupport #TechSupportConf
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥9❤1👏1
Коллеги, вчера Amazon упал. Не просто «подтормаживал» — упал.
142 сервиса. Более 20 тысяч жалоб. Snapchat, Perplexity, Zoom, Slack, Microsoft Teams и многие другие - все в одной лодке. И все смотрят на одну страницу: https://health.aws.amazon.com/health/status. Самый масштабный сбой с 2011 года.
К вопросу о прозрачности в управлении инцидентами.
Когда рушится всё, каждая секунда на счету. Клиенты не просто ждут исправления - они ждут информации. И здесь AWS демонстрирует мастер-класс.
Два ключевых принципа, которые нельзя разделять: быстро решить проблему и постоянно быть на связи. Но что именно делает их подход образцовым?
Взгляните на страницу статуса AWS. Обновления каждые 30-40 минут. Не формальность, а содержательный диалог: что произошло, как обойти проблему, какие шаги предпринимаются дальше.
Это управление ожиданиями в реальном времени. Прозрачность, которая превращает хаос в контролируемый процесс.
Кому интересно, что сломалось и как решали, можно почитать тут
#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка
142 сервиса. Более 20 тысяч жалоб. Snapchat, Perplexity, Zoom, Slack, Microsoft Teams и многие другие - все в одной лодке. И все смотрят на одну страницу: https://health.aws.amazon.com/health/status. Самый масштабный сбой с 2011 года.
К вопросу о прозрачности в управлении инцидентами.
Когда рушится всё, каждая секунда на счету. Клиенты не просто ждут исправления - они ждут информации. И здесь AWS демонстрирует мастер-класс.
Два ключевых принципа, которые нельзя разделять: быстро решить проблему и постоянно быть на связи. Но что именно делает их подход образцовым?
Взгляните на страницу статуса AWS. Обновления каждые 30-40 минут. Не формальность, а содержательный диалог: что произошло, как обойти проблему, какие шаги предпринимаются дальше.
Это управление ожиданиями в реальном времени. Прозрачность, которая превращает хаос в контролируемый процесс.
Кому интересно, что сломалось и как решали, можно почитать тут
#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка
👍9🔥6🤝3
«Как стать крутым в ТехПоде?»
1️⃣
Мы соберем 100 коротких и мощных советов от руководителей и директоров, которые прошли этот путь. Без воды. Только конкретика.
Первый в рубрике - Сергей Харитонов, директор центра ИТ-поддержки, Президентская академия РАНХИГС:
#TechSupport #Сто_Советов_ТехПод
Мы соберем 100 коротких и мощных советов от руководителей и директоров, которые прошли этот путь. Без воды. Только конкретика.
Первый в рубрике - Сергей Харитонов, директор центра ИТ-поддержки, Президентская академия РАНХИГС:
Как стать крутым в Технической Поддержке?
Короткий совет: определиться с областью, работать больше положенного, интересоваться за гранью своих должностных обязанностей, проявлять инициативу и показывать результаты.
Если сильнее развернуть ответ, то у сотрудника поддержки есть 4 основых области знаний:
1. Знание предметной области и процессов, которые поддерживаешь.
2. Знание продукта и технологии, которую поддерживаешь
3. Знание основ поддержки (например, практики ITIL)
4. Умение в софтскиллы - эмпатия, ответственность, умение видеть картину целиком, умение читать между строк.
Как правило поддержка является первым шагом в карьере ИТ-специалиста и именно тут ты определяешься с тем вектором, куда развиваться. В зависимости от области знаний, которая ближе к сердцу, ты становишься - разработчиком, тестировщиком, бизнес-аналитиком, техписом, ITSM-специалистом, менеджером или другим специалистом из миллиона вариантов.
Определяешься, выбираешь сферу и начинаешь углубляться - улучшать процессы, находить неочевидные решения, проявлять инициативу, залезать вглубь продукта - в зависимости от области знаний. А дальше всё зависит только от твоего желания.
#TechSupport #Сто_Советов_ТехПод
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12✍3🔥2
ТехПод от А до Я
TechSupportConf'25. Как это было? Публичных конференций, где говорят на нашем языке, в России не было. До этой недели. Давайте разберемся, почему это событие стало настоящим открытием. Во-первых, это действительно первая конференция для специалистов техподдержки…
TechSupportConf. Вторая серия. На сцену залез вдруг.
В зале - 600 рук, а я вдруг оказываюсь на сцене. Что я там делаю? Делюсь опытом, конечно: как найти своих инженеров и проводить поведенческое интервью - с чего начать, какие вопросы задавать, а какие лучше обходить стороной. Здесь и сейчас: бери и применяй завтра же. А если этого мало - в конце есть список литературы, которая расширит твой арсенал как руководителя.
Мой критерий успеха прост: если хотя бы один человек вынес пользу - значит, время потрачено не зря. Если больше десяти - отлично. Судя по отзывам, получилось именно так. (Кстати, в каждом посте тоже должно быть что-то полезное.)
Что понравилось в докладах?
▪️Miran рассказал о стандартном, но важном Incident Management. Особенно интересен их подход к накоплению и повторному использованию знаний.
▪️Ecom.Tech (Самокат) удивил стендап-стилем подачи и юмором. Спикер поделилась практическим чек-листом для подготовки статей в Confluence с учётом работы любых LLM - польза, которая точно пригодится.
▪️Selectel привёл ценные цифры: средний срок работы в поддержке - 2,7 года, состав команды, направления карьерного роста сотрудников. Захотелось сравнить с нашими данными за последние пять лет.
▪️UseDesk продемонстрировал мастерство живого реагирования: когда презентация внезапно перелистнулась на последний слайд, спикер легко справился с ситуацией.
▪️Swarmica движется в том ж направлении, что и мы: сочетает KCS, ИИ и автогенерацию статей.
▪️TimeWeb и Support.Science - органичный тандем с отличным темпом и подачей.
- Один момент особенно поразил: во время инцидента в поддержку может прилететь тысяча заявок. Хорошо, что есть инструменты, которые помогают сократить поток обращений - например, status page, как у AWS.
Аудитория?
На мой взгляд, 70–90 % - это руководители техподдержки. Когда спросили, кто знает и использует ITIL, руки подняли лишь около 5 %. Это вызвало интерес: как на практике решают инциденты, проводят корневой анализ и планируют работы?
Ещё одна важная деталь: функционал L2 в разных компаниях может сильно отличаться - даже если они работают в схожих сферах: облака, хостинг и т.п.
Зачем нужны такие конференции?
1️⃣ Познакомиться с интересными людьми: организаторами, спикерами, коллегами из других компаний.
2️⃣ Получить опыт выступления.
3️⃣ Собрать команду на тимбилдинг.
5️⃣ Мотивировать сотрудников, беря с собой лучших инженеров.
Будет ли следующая конференция?
Конечно! Следите за новостями.
Ps. Спасибо организаторам!
#TechSupport #TechSupportConf
В зале - 600 рук, а я вдруг оказываюсь на сцене. Что я там делаю? Делюсь опытом, конечно: как найти своих инженеров и проводить поведенческое интервью - с чего начать, какие вопросы задавать, а какие лучше обходить стороной. Здесь и сейчас: бери и применяй завтра же. А если этого мало - в конце есть список литературы, которая расширит твой арсенал как руководителя.
Мой критерий успеха прост: если хотя бы один человек вынес пользу - значит, время потрачено не зря. Если больше десяти - отлично. Судя по отзывам, получилось именно так. (Кстати, в каждом посте тоже должно быть что-то полезное.)
Что понравилось в докладах?
▪️Miran рассказал о стандартном, но важном Incident Management. Особенно интересен их подход к накоплению и повторному использованию знаний.
▪️Ecom.Tech (Самокат) удивил стендап-стилем подачи и юмором. Спикер поделилась практическим чек-листом для подготовки статей в Confluence с учётом работы любых LLM - польза, которая точно пригодится.
▪️Selectel привёл ценные цифры: средний срок работы в поддержке - 2,7 года, состав команды, направления карьерного роста сотрудников. Захотелось сравнить с нашими данными за последние пять лет.
▪️UseDesk продемонстрировал мастерство живого реагирования: когда презентация внезапно перелистнулась на последний слайд, спикер легко справился с ситуацией.
▪️Swarmica движется в том ж направлении, что и мы: сочетает KCS, ИИ и автогенерацию статей.
▪️TimeWeb и Support.Science - органичный тандем с отличным темпом и подачей.
- Один момент особенно поразил: во время инцидента в поддержку может прилететь тысяча заявок. Хорошо, что есть инструменты, которые помогают сократить поток обращений - например, status page, как у AWS.
Аудитория?
На мой взгляд, 70–90 % - это руководители техподдержки. Когда спросили, кто знает и использует ITIL, руки подняли лишь около 5 %. Это вызвало интерес: как на практике решают инциденты, проводят корневой анализ и планируют работы?
Ещё одна важная деталь: функционал L2 в разных компаниях может сильно отличаться - даже если они работают в схожих сферах: облака, хостинг и т.п.
Зачем нужны такие конференции?
Будет ли следующая конференция?
Конечно! Следите за новостями.
Ps. Спасибо организаторам!
#TechSupport #TechSupportConf
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥8❤2
Как стать крутым в ТехПоде?
Собираем 100 коротких советов от руководителей и директоров в ТехПоде! У микрофона - Полина, CXO(Chief Experience Officer) в Giftery,:
Измеряй, упреждай и действуй на результат
#TechSupport #Сто_Советов_ТехПод
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍4🤝2
Дифференцируйтесь или теряйте кадры. Онбординг в мире технической поддержки.
Вы наверняка слышали это на собеседованиях.
Я слышу всё чаще: «Меня просто бросили в огонь с первого дня».
Или: «Дали доступ в вики - и сказали: иди, читай».
Никто не объяснил, кто за что отвечает. Ни один вопрос не получил ответа.
Что остаётся у новичка?
Вопросы - в воздухе.
Команда - как чужая.
Стресс - как единственный спутник.
Это не просто плохо.
Это симптом.
Симптом того, что компания не умеет - или не хочет - вводить людей в курс дела.
А в крупной организации, где процессы измеряются терабайтами, а инструкции - сотнями страниц, мозги кипят даже у опытных инженеров.
Раньше я слышал от инженеров на испытательном сроке :
«Боялся, что меня уволят - потому что чувствовал себя тупым».
Не потому, что они не могли.
А потому, что им не дали ни карты, ни компаса.
Сейчас мы действуем на опережение.
Сразу говорим новичку: «Да, информации много. Голова будет пухнуть. Это нормально. Все через это прошли».
Но мы не оставляем его в этом состоянии.
Мы даём ему путь.
Не бросаем в огонь - проводим через него по надёжному маршруту.
Обещаем: через три месяца ты освоишься.
Через шесть - уже будешь приносить реальную пользу.
И не просто выполнять задачи - а улучшать то, что раньше работало хуже, чем должно.
А как построить онбординг, который не ломает, а заряжает?
Вот как мы это делаем.
▪️Шаг первый: личная встреча с руководителем.
Не формальность. Не ритуал.
Разговор один на один - где объясняют не только, какие системы использовать, но и: что здесь ценят, а что - нет.
Где закладывается фундамент.
Потому что человек, который чувствует, что его видят - не как ресурс, а как человека - уже на полшага ближе к тому, чтобы остаться.
▪️Шаг второй: знакомство с командой.
Не просто добавить в десяток чатов.
А представить так, чтобы новичок почувствовал: его ждали.
▪️Шаг третий: наставник.
Не просто старший инженер.
Тот, кто знает, как объяснить сложное просто.
Кто не отвечает «прочитай вики» - а говорит: «Давай сядем. Я покажу».
Шаг четвёртый: Ключевой. Структурированное погружение.
Трёхмесячный курс - как путешествие.
Первый день - что делать.
Первая неделя - что изучить.
Первый месяц - что понять.
Всё: от Service Request до Incident Management, от Linux до сетевых диаграмм.
Каждый модуль - тест.
Не для оценки.
Для обратной связи.
Результаты автоматически приходят руководителю и наставнику.
Ни один пробел не остаётся незамеченным.
Ни один вопрос - без ответа.
Шаг пятый: фидбек после завершения.
После успешного прохождения - не просто «молодец».
Сообщение на команду. Поздравляем.
Спрашиваем: что помогло? Что мешало? Что нужно изменить?
Потому что онбординг - не разовая акция.
Это живой процесс. И если он не улучшается - он умирает.
Можно ли пойти дальше? Всегда. Мы, например, организовали встречу с поставщиком платформы, на которой построили наш онбоардинг. Поделились опытом и нашими «хотелками». Это выводит процесс на новый уровень.
Большинство компаний бросают новых сотрудников в огонь - и называют это «пробуждением самостоятельности».
Дифференцируйтесь.
Делайте противоположное тому, что делают остальные за столом.
Погружайте плавно. Без стресса.
Нарабатывайте лояльность не с момента первой победы - а с первого рабочего дня.
Эта стратегия окупается.
С головой.
P.S.
Читал статью на Indeed: средняя стоимость обучения одного сотрудника - около $1252 при 33 часах обучения.
Рекомендации: удержание через комфортную среду, найм квалифицированных кадров, цифровизация документооборота, целенаправленное обучение на основе оценки.
#TechSupport #Onboarding
Вы наверняка слышали это на собеседованиях.
Я слышу всё чаще: «Меня просто бросили в огонь с первого дня».
Или: «Дали доступ в вики - и сказали: иди, читай».
Никто не объяснил, кто за что отвечает. Ни один вопрос не получил ответа.
Что остаётся у новичка?
Вопросы - в воздухе.
Команда - как чужая.
Стресс - как единственный спутник.
Это не просто плохо.
Это симптом.
Симптом того, что компания не умеет - или не хочет - вводить людей в курс дела.
А в крупной организации, где процессы измеряются терабайтами, а инструкции - сотнями страниц, мозги кипят даже у опытных инженеров.
Раньше я слышал от инженеров на испытательном сроке :
«Боялся, что меня уволят - потому что чувствовал себя тупым».
Не потому, что они не могли.
А потому, что им не дали ни карты, ни компаса.
Сейчас мы действуем на опережение.
Сразу говорим новичку: «Да, информации много. Голова будет пухнуть. Это нормально. Все через это прошли».
Но мы не оставляем его в этом состоянии.
Мы даём ему путь.
Не бросаем в огонь - проводим через него по надёжному маршруту.
Обещаем: через три месяца ты освоишься.
Через шесть - уже будешь приносить реальную пользу.
И не просто выполнять задачи - а улучшать то, что раньше работало хуже, чем должно.
А как построить онбординг, который не ломает, а заряжает?
Вот как мы это делаем.
▪️Шаг первый: личная встреча с руководителем.
Не формальность. Не ритуал.
Разговор один на один - где объясняют не только, какие системы использовать, но и: что здесь ценят, а что - нет.
Где закладывается фундамент.
Потому что человек, который чувствует, что его видят - не как ресурс, а как человека - уже на полшага ближе к тому, чтобы остаться.
▪️Шаг второй: знакомство с командой.
Не просто добавить в десяток чатов.
А представить так, чтобы новичок почувствовал: его ждали.
▪️Шаг третий: наставник.
Не просто старший инженер.
Тот, кто знает, как объяснить сложное просто.
Кто не отвечает «прочитай вики» - а говорит: «Давай сядем. Я покажу».
Шаг четвёртый: Ключевой. Структурированное погружение.
Трёхмесячный курс - как путешествие.
Первый день - что делать.
Первая неделя - что изучить.
Первый месяц - что понять.
Всё: от Service Request до Incident Management, от Linux до сетевых диаграмм.
Каждый модуль - тест.
Не для оценки.
Для обратной связи.
Результаты автоматически приходят руководителю и наставнику.
Ни один пробел не остаётся незамеченным.
Ни один вопрос - без ответа.
Шаг пятый: фидбек после завершения.
После успешного прохождения - не просто «молодец».
Сообщение на команду. Поздравляем.
Спрашиваем: что помогло? Что мешало? Что нужно изменить?
Потому что онбординг - не разовая акция.
Это живой процесс. И если он не улучшается - он умирает.
Можно ли пойти дальше? Всегда. Мы, например, организовали встречу с поставщиком платформы, на которой построили наш онбоардинг. Поделились опытом и нашими «хотелками». Это выводит процесс на новый уровень.
Большинство компаний бросают новых сотрудников в огонь - и называют это «пробуждением самостоятельности».
Дифференцируйтесь.
Делайте противоположное тому, что делают остальные за столом.
Погружайте плавно. Без стресса.
Нарабатывайте лояльность не с момента первой победы - а с первого рабочего дня.
Эта стратегия окупается.
С головой.
P.S.
Читал статью на Indeed: средняя стоимость обучения одного сотрудника - около $1252 при 33 часах обучения.
Рекомендации: удержание через комфортную среду, найм квалифицированных кадров, цифровизация документооборота, целенаправленное обучение на основе оценки.
#TechSupport #Onboarding
👍15🔥3❤1
Как стать крутым в ТехПоде?
Добавляем в коллекцию новый совет от руководителей в ТехПоде. Делится Ольга Елисеева, руководитель технической дирекции, Инфосистемы Джет:
Важно понимать, за что клиент платит деньги: чаще всего это за работоспособность оборудования и процессов целиком, иногда он платит компании за ваши компетенции и ожидает, что вы станете полноценным членом его команды. Когда ты это понимаешь, тебе легче «встать в тапки» клиента, понять мотивы его действий, начать думать «как клиент» и где-то играть на опережение — чтобы он мог спать спокойно. А это тебе самому обеспечит не только профессиональный рост, но и финансовый.#TechSupport #Сто_Советов_ТехПод
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍4🤝3❤1
Forwarded from Вот это сервис! от Supprt.Science
Сегодня мы с коллегой Ринатом Саитовым знакомим вас с материалами о работе с инцидентами.
Речь о ITIL, способах строить процессы так, чтобы 31 декабря в 17.59 никто не катил срочные обновления, а поддержку не заваливало тикетами, чтобы жалобы клиентов влияли на решения продукта, а бизнес не терял связи с клиентом.
Ринат — шеф поддержки и автор канала «ТехПод от А до Я». Он умеет раскладывать сложные процессы по полочкам.
🧷 В карточках — тезисы из его статей, а полные версии тут:
⚪️ Incident Management часть 1 и 2
⚪️ Problem Management
⚪️ Change Management
#ITIL #техпод #incidentmanagement #ТочкаТрения
Речь о ITIL, способах строить процессы так, чтобы 31 декабря в 17.59 никто не катил срочные обновления, а поддержку не заваливало тикетами, чтобы жалобы клиентов влияли на решения продукта, а бизнес не терял связи с клиентом.
Ринат — шеф поддержки и автор канала «ТехПод от А до Я». Он умеет раскладывать сложные процессы по полочкам.
#ITIL #техпод #incidentmanagement #ТочкаТрения
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14✍4🤩3🤝3👍2