Известная ошибка в ITIL — это проблема, которая уже была проанализирована, но ещё не была решена
Как работают известные ошибки и зачем они нужны? Покажу между делом.
Пусть у нас есть абстрактная служба ИТ, в которой разработка в одном подразделении, а эксплуатация в другом. К примеру такая:
Привет, Хабр! Меня зовут Сергей. В X5 Tech я отвечаю за поддержку системных сервисов магазинов, обновлений и аналитику на уровне второй линии поддержки. Примерно с начала 2024 года у нас стартовала масштабная инициатива по реинкарнации Problem Management. Хотя уже сейчас понятно, что это даже не реинкарнация в прямом понимании этого слова, а фактически запуск.
Я давно (с 2011 года) работаю в X5. За это время успел побывать в множестве разных ролей от системного администратора до бизнес‑архитектора. И могу сказать, что большую часть этого времени Problem Management у нас был в том или ином виде. Мне удалось посмотреть и поучаствовать в этом процессе в разных амплуа — от человека, который со стороны поддержки ИТ проблемы регистрирует, до человека, который их решает. В текущей активности я принимаю непосредственное участие в создании и развитии процесса Problem Management, формировании стратегии, а также отвечаю за работу и развитие роли Problem аналитиков. Что это за ребята и чем они занимаются — я расскажу в статье.
Хочу поделиться своим опытом с позиции человека, который сейчас принимает непосредственное участие в создании, становлении и развитии сложного и очень важного процесса управления проблемами в X5 Tech. Надеюсь, наш кейс будет полезен всем, кто развивает направление ProblemManagement у себя, а также тем, кто только планирует создание такой функции или размышляют над целесообразностью его внедрения.
Представьте ситуацию: ваша команда только что выпустила новую версию продукта, а через неделю техподдержка завалена тикетами от недовольных пользователей. Знакомо, не правда ли? Сегодня недостаточно просто разрабатывать качественное ПО — нужно уметь эффективно поддерживать его и оперативно реагировать на изменения потребностей пользователей.
В этой статье рассмотрим, как интеграция подходов IT Service Management (ITSM) и Software Development Life Cycle (SDLC) может помочь создать цикл непрерывного совершенствования продукта. Разберемся, почему объединение этих практик — не просто модный тренд, а необходимость для компаний, стремящихся быть на шаг впереди конкурентов.
Итак, у вас есть благая цель: вы хотите построить на производстве столовую, чтобы сотрудники могли пообедать на работе и не ездили в ближайшую пиццерию. Так вы сократите время простоя, а ещё никто не будет греть рыбу в общей микроволновке. Это хорошо.
Правда, пока вы делаете ремонт по всем правилам СанПин, закупаете оборудование, нанимаете поваров и проходите проверки, деньги уходят в большем объёме, а необходимость обедать в другом месте остаётся. И это плохо.
Но что, если поменять план?
1. Сначала поставим кофемашину и аппарат со снеками в зоне отдыха. Тогда коллеги сократят число подходов «до магазина».
2. Потом отремонтируем помещение, закупим мебель и будем продавать недорогие готовые комплексные обеды. Часть коллектива уже перестанет уезжать на перерыв.
3. Затем построим свою кухню: часть блюд продолжим закупать, а часть начнём производить сами. Большинство сотрудников это оценит, и люди станут чаще ходить в столовую.
4. Наконец, откроем ещё один цех и перейдём на полный цикл работы.
Таким образом, двигаясь поэтапно, мы сократим время, когда затраченные ресурсы не приносят никакой пользы.
То же самое можно сделать с автоматизацией бизнес-процессов. Вы пишете ТЗ, выбираете софт, готовите документы — но пока в системе не начали работать люди, это лишь списанные деньги. В этой статье мы разберём, как ускорить отдачу на вложенное при внедрении нового ПО.
Два года назад Kokoc Group вышел на международный рынок, а в этом году запустил новый продукт — многофункциональную платформу, предоставляющую широчайший спектр услуг диджитал маркетинга для развития бизнеса международных клиентов.
Перед запуском платформы передо мной как руководителем группы разработки и моей коллегой, руководителем отдела поддержки оставалась одна мелочь — организовать поддержку на разных языках (потому что далеко не все партнеры и коллеги за пределами РФ и СНГ знают английский и тем более русский). В процессе мы поняли, что эта самая «мелочь», на самом деле — огромный проект.
Меня зовут Михаил Кобзарев, руководитель группы разработки PHP в Kokoc Group, занимаюсь разработкой внутренних проектов и продуктов для группы компаний. И сейчас я расскажу, как найти саппорт-систему за три месяца, если при себе нет 10 миллионов.
Привет, Хабр! Я — Артем, ведущий специалист в дирекции эксплуатации и развития автоматизированных рабочих мест в Страховом Доме ВСК. Сегодня я вам расскажу о том, как мы подружили Jira и Telegram в нашем проекте «Telegram Bot «Поддержка ВСК».
План повествования:
Устал от стандартного подхода к саппорту своего продукта через Jira? Надоели миллион уведомлений на почту о изменениях в таске? Раздражает скорость ответа на тикет? Тогда мы идем к тебе...
Всем привет! Я Артем Ибрагимов, руководитель направления в управлении разработки цифровых продуктов в Первой грузовой компании. Одна из составляющих работы любого продукта – это техподдержка. В ПГК есть несколько флагманских цифровых сервисов, где наши IT-специалисты на постоянной основе решают различные вопросы и проблемы пользователей. Ранее я подробно рассказал о работе техподдержки одного из наших продуктов – личного кабинета клиента (ЛКК) и оперативном решении возникающих задач. Сегодня поговорим о техподдержке не только ЛКК, но и других наших флагманских продуктов, а также об обратной связи по клиентской помощи.
ИИ может не только ускорить, но и значительно повысить качество обработки обращений в техподдержку. Я занимаюсь в НЛМК генеративным искусственным интеллектом и расскажу, как нам совместно с ИТ‑вендором Аксеникс удалось преобразовать подход к обслуживанию ИT‑запросов поддержки пользователей через проект интеллектуальной классификации и маршрутизации.
Привет, Хабр! Меня зовут Павел Родичев, и я тимлид технической поддержки в СберМаркете. Эта статья — о том, как мы интегрировали в Jira систему, которая для этого не предназначена, и сократили время на нотификацию пользователей.
Привет, Хабр! В блоге ЛАНИТ хочу поделиться историей внедрения Service Desk, которая продолжается до сих пор, точно, как в анекдоте, что ремонт нельзя закончить, его можно только прекратить. Я не буду подробно описывать все этапы внедрения. Расскажу только, с какими проблемами мы сталкивались на этом пути и как мы их решали. Возможно, наш практический опыт внедрения окажется для вас полезным.
Привет, Хабр! На связи Наталия Сляднева, руководитель направления сервиса вычислительной инфраструктуры КРОК. Сегодня я расскажу о системе взаимодействия с клиентами и работе с обратной связью. Вы узнаете, что мы предпринимаем для улучшения сервиса, как новые подходы влияют на реакции клиентов и повышают их лояльность, а также как мы справляемся со сложностями и оцениваем результаты.
Вопрос качественной сервисной поддержки ИТ-инфраструктуры на нашем рынке стоит остро — большинство заказчиков привыкли получать прямую, быструю и высококачественную сервисную поддержку от вендоров. Сейчас эти задачи легли на наши плечи и мы стараемся не просто держать марку, а работать даже лучше.
В этой статье я приоткрою внутреннюю кухню и поделюсь 5 практиками, которые помогают нам анализировать, дорабатывать и ускорять внутренние процессы, чтобы быть еще полезнее клиентам. Возможно, они помогут и вам.
При работе с SIP-телефонией достаточно часто можно встретить проблему отсутствия слышимости. Ошибка может возникнуть как на сети, так и на стороне SIP-устройства или приложения.
Хотелось бы поделиться сбоем, вероятность воспроизведения которого крайне мала - настолько, что техподдержке проще будет сослаться на ошибку из-за космических лучей: в ТП одного крупного оператора SIP-телефонии за 3 года зафиксировано 6 обращений, в которых такая проблема зафиксирована (из ~300.000 всего - 0.002%).
Как мы помогли ГУП «Водоканал Санкт-Петербурга» улучшить работу с обращениями жителей самого северного мегаполиса мира.
Водоканал управляет почти 18 000 км водопровода и канализации. Каждый день предприятие делает более комфортной жизнь 5 миллионов человек, десятков тысяч предприятий и организаций Петербурга. Чтобы ускорять работу с обращениями внешних потребителей и заявками сотрудников для оказания качественного сервиса, нужна налаженная работа с обращениями. Для этого предприятию требовалось современное и удобное решение. Им стала автоматизированная система управления обращениями на базе Naumen, которую внедрила СИГМА.
Меня зовут Женя, я руководитель проектов. Хочу поделиться с Хабром кейсом моей команды: мы автоматизировали работу с обращениями клиентов в холдинге «Русклимат».
Проблема была в том, что сотрудники компании работали с большими объёмами данных в нескольких программах (служба поддержки в Naumen, претензионный отдел в 1С, сервисные центры на старом портале), из-за чего обработать и передать обращение другому подразделению было сложно.
В статье я покажу схему взаимодействия отделов, опишу задачи, процесс работы, проведённую автоматизацию и результаты.
Всем привет! Мы (Олег Герцев и Лиля Кондратьева) работаем в сервисном центре Positive Technologies и отвечаем за поддержку MaxPatrol SIEM и MaxPatrol VM соответственно.
Мы не только обрабатываем более десяти тысяч заявок в год, но и активно развиваем экспертизу клиентов и партнеров: среди наших сотрудников есть активные участники комьюнити-чата в Телеграме, в прошлом году мы выступали с лекциями на ДОД, а также готовили материалы для разработки курса по траблшутингу.
Ранее коллеги, работающие с PT Sandbox и PT NAD, рассказывали, с решением каких вопросов сталкиваются инженеры. Мы решили не останавливаться и в этой статье хотим приоткрыть завесу тайны над буднями специалистов поддержки уже других продуктов, приведя несколько историй на основе реальных событий. Кстати, пока мы готовили этот текст, так вдохновились, что придумали несколько тематических ребусов, к которым перейдем в самом конце. Пока же ныряем в будни техподдержки!
Может быть, вы видели в магазинах объявление, что в случае просрочки или других проблем можно звонить вот на эту горячую линию. У некоторых работодателей такая линия есть для сотрудников.
Там можно пожаловаться на задержку зп, коррупцию или ещё что-нибудь. Жалоба попадает на специальную платформу, где её изучают, проверяют и либо отклоняют, либо передают дальше, чтобы ответственные разобрались. Это комплаенс-менеджмент.
Если компания большая и у неё много юрлиц и филиалов, с менеджментом помогают подрядчики. Например, консалтинговая компания ДРТ, для которой моя команда автоматизировала данный процесс. В этом кейсе я покажу, какое решение для управления комплаенсом мы создали.
Часто получаю вопрос: "Наши программисты сами сделали бота и на тестовых вопросах работает отлично, но при ответах на реальные вопросы пользователей начинается треш. Как сделать супер промпт чтобы бот не глючил?".
Ответ простой: "Серебряной пули нет, задачу нужно разбивать на части и использовать разные инструменты для решения разных проблем".
Привет, Хабр. Я Антон Лазарев, руководитель группы автоматизации ИТ-процессов. Хочу поделиться с вами небольшой, но поучительной историей о процессе разработки и внедрения одного из самых любимых инструментов наших пользователей для общения с поддержкой. Поделюсь результатами и пройдусь по граблям, на которые мы успели наступить в прошлом, пока разрабатывали наш чат-бот Айтишу.
Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в “Петрович-Тех”.
Представьте: пользователи не могут начать работу в системе. Не испытывают сложности через день или неделю, а прямо на старте не имеют возможности начать пользоваться продуктами компании.
В таких случаях требуется быстрая помощь, а у нас соответствующий специалист занят другой задачей. Пошёл разбирать один запрос, тот оказался трудозатратным, копится очередь недовольных пользователей с проблемами помельче. Нужно как-то повысить скорость обработки входящих запросов, но как именно?
В этой статье расскажу, как мы создавали первую линию технической поддержки – какие шаги мы предприняли и что сработало, а что оказалось пустой тратой ресурсов. Надеюсь, наш опыт будет интересен не только тем, кто непосредственно занимается организацией поддержки, но всем, кого интересуют подходы к обработке входящего потока запросов, на уровне команды, отдела, продукта и компании.
