Часто получаю вопрос: "Наши программисты сами сделали бота и на тестовых вопросах работает отлично, но при ответах на реальные вопросы пользователей начинается треш. Как сделать супер промпт чтобы бот не глючил?".
Ответ простой: "Серебряной пули нет, задачу нужно разбивать на части и использовать разные инструменты для решения разных проблем".
Привет, Хабр. Я Антон Лазарев, руководитель группы автоматизации ИТ-процессов. Хочу поделиться с вами небольшой, но поучительной историей о процессе разработки и внедрения одного из самых любимых инструментов наших пользователей для общения с поддержкой. Поделюсь результатами и пройдусь по граблям, на которые мы успели наступить в прошлом, пока разрабатывали наш чат-бот Айтишу.
Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в “Петрович-Тех”.
Представьте: пользователи не могут начать работу в системе. Не испытывают сложности через день или неделю, а прямо на старте не имеют возможности начать пользоваться продуктами компании.
В таких случаях требуется быстрая помощь, а у нас соответствующий специалист занят другой задачей. Пошёл разбирать один запрос, тот оказался трудозатратным, копится очередь недовольных пользователей с проблемами помельче. Нужно как-то повысить скорость обработки входящих запросов, но как именно?
В этой статье расскажу, как мы создавали первую линию технической поддержки – какие шаги мы предприняли и что сработало, а что оказалось пустой тратой ресурсов. Надеюсь, наш опыт будет интересен не только тем, кто непосредственно занимается организацией поддержки, но всем, кого интересуют подходы к обработке входящего потока запросов, на уровне команды, отдела, продукта и компании.
На проде что‑то сломалось — такова суровая реальность, случается с лучшими из нас, увы. Что часто происходит в подобных случаях: ловим алерты, бежим смотреть графики и логи, вызваниваем из отпуска разработчика, который занимался этой функциональностью, выкатываем фикс, проводим пост‑мортем. Это реакция на уровне здравого смысла, классика.
Но когда речь заходит о недозаработанных из‑за инцидента деньгах, расстроенных пользователях — любое улучшение, даже небольшое, на доли процента — может принести ощутимый результат.
Давайте поговорим, как подойти к вопросу мониторинга методологически — задействовать инструментарий инцидент‑менеджмента. Обсудим, как оценивать критичность сервисов и какие системы могут быть полезны для отслеживания проблем.
Статья ориентирована в первую очередь на тех, кто прямо сейчас занимается мониторингом на уровне общей инженерной грамотности, но пока не использует в явном виде инцидент‑менеджмент как подход.
Asana скоропостижно ушла из России, не оставив своим пользователям достаточно времени на поиск альтернативных решений. Имеем что имеем. Но по протоптанным тропам идти проще, чем прокладывать их самому. Поэтому мы решили поделиться историей компании, которая перешла из Asana в Kaiten заблаговременно. Возможно их опыт поможет вам сделать выбор.
Это кейс бэк-офиса онлайн-школы «Академия Йоги». HR-специалисты, юристы, IT-поддержка, бухгалтерия обрабатывают ежемесячно более 240 заявок, и с помощью Kaiten смогли автоматизировать рутинные процессы и увеличить скорость обработки задач.
Работая на первой линии тех.поддержки, я часто сталкивался с рутиной, особенно очень хотелось минимизировать подключение к рабочему столу пользователей для сбора информации и как-то автоматизировать этот процесс, что привело меня к осваиванию языка PowerShell и написанию скриптов, которые в последствии оформились в самостоятельные программы. Некоторые из них я решил выложить на GitHub, возможно для кого-то они будут полезны.
ScanPC
Утилита сканирующая удалённый ПК и показывающяя версию ОС, информацию о дисках, железе, открытых портах из списка (22,445,80,8080,3389,5900,1112,2575,10050), установленных принтерах, пользователях вошедших в систему, список профилей пользователей в папке C:\Users, размер системных папок и фалов, папки с документами в профилях пользователей размером больше 100МБ.
Как правило управлять ИТ-активами предлагается с помощью методологии ITAM — IT Asset Management. Этот метод связывает ИТ-активы с договорной и финансовой информацией, чтобы компания могла учитывать общие затраты.
Однако на практике ITAM может быть слишком трудозатратен для малого и среднего бизнеса, одна из главных задач которого — оказывать хороший сервис. Гибкая service desk система вполне способна закрыть задачи по управлению ИТ-активами без приобретения дополнительной системы ITAM. Я расскажу почему это так и поделюсь конкретными кейсами внедрения учёта ИТ-активов с помощью ITSM.
Привет, Хабр! В продолжении темы, связанной с внедрением Каталога ИТ-услуг в компании, хочу разобрать достаточно популярный вопрос (не знаю, как у других, но у нас так точно) – зачем нужно возиться с услугами, если все пользователи работают с системами? Логичнее же «идти от систем», чем каких-то «никому не понятных услуг». Давайте разбираться и взвешивать все «за» и «против». Пусть каждый сам для себя решит, как эффективно выстроить процесс управления ИТ в общем и, взаимодействие с бизнесом, в частности.
Всем привет! В этой статье я поделюсь четвёртым выпуском рубрики Открытый микрофон, в котором Иван Хахарев, ведущий аналитик Департамента системного анализа в Спортмастере, выступил с докладом про то, как создать службу поддержки, которая ляжет на большинство систем. Такая разработка может помочь проанализировать продукт, улучшить UX или даже провести реинжиниринг.
Мы подобрали экспертов, которые делятся своей экспертизой и мнением, их комментарии - ниже по тексту.
Приходите в комментарии, задавайте вопросы или делитесь своей экспертизой!
Система service desk в развивающейся компании должна быть не просто стабильной. Она должна быть масштабируемой, омниканальной, гибкой и легко настраиваемой. В статье рассказали о том, как правильно подобранная service desk система улучшила работу в ИТ-службе.
Привет, Хабр! Меня зовут Андрей Прокофьев-Нужный и я решил поделиться опытом, который приобрела наша IT-компания М.Тех в процессе внедрения Каталога ИТ-услуг.
Сегодня ПО для автоматизации сервисной поддержки — привычное явление даже в молодых микрокомпаниях на аутсорсе. При этом аутсорсеры на старте часто стараются следовать модному тренду и разрабатывают собственное кастомизируемое решение. Такое, которое можно гибко настроить под собственные нужды и запросы заказчиков.
Но всегда ли разработка собственного решения для обработки заявок целесообразна для начинающей компании? Существуют ли «коробки», способные закрыть все требования аутсорсера на старте? И в какой момент ей можно переходить от типового инструмента к кастомизируемой конфигурации? Давайте поразмышляем.
Всем привет. На связи снова Александр Грачев. Как и обещал, возвращаюсь с новыми рассказами о внутренней кухне технической поддержке песочницы PT Sandbox и том, как мы делаем мир безопаснее и лучше благодаря нашему продукту.
Все мы знаем о таких распространенных вирусах, как шифровальщики. И да, когда-то о них было слышно «из каждого утюга», а потом шумиха улеглась и вроде как все прошло. Но наши исследования показывают, что они никуда не делись.
Предположу, что от слова «шифровальщик» у любого IT-специалиста начинает дергаться глаз. И я понимаю эти эмоции. В мир ИБ я, как многие в этой сфере, попал из ИТ (и это несмотря на то, что многие айтишники не любят безопасников и наоборот).
Так вот, злосчастные шифровальщики — это страшный сон IT-специалиста, о котором мечтаешь забыть. Да, сейчас стало легче и проще, способов защиты стало больше, а вот раньше… В любой момент мог раздаться звонок со словами: «У меня тут на рабочем столе появился текстовый файл „Открой меня“, а внутри просят деньги. Что делать?» И начинается череда приключений.
Привет! Я Лиза, специалист службы поддержки Канбан-сервиса Kaiten. Ежедневно я и мой коллега получаем около 40 запросов от наших пользователей: помогаем разобраться в продукте, найти неизвестные для них функции, устранить проблемы. Рассказываю, как мы организовали свою работу внутри нашего же сервиса с помощью модуля Service desk.
Продолжить цикл статей о подходах к структурированию сервисов поддержки и развития приложений мы с Михаилом Ковешниковым решили размышлением о ресурсной модели, а точнее о балансе между внутренней командой и аутсорсингом.
Довольно редко встречается ресурсно-сервисная модель, в которой все работы выполняются только штатными сотрудниками либо наоборот только субподрядчиками. Обычно выбор конкретного решения о балансировке ресурсов зависит от сложности бизнес-приложения, ситуации на рынке труда и особенностей клиента.
Мы хотим описать ключевые факторы, влияющие на выбор модели сорсинга, преимущества и недостатки использования внешних ресурсов.
Привет! Меня зовут Василий Жуковский, и я отвечаю за работу технической поддержки PT Network Attack Discovery (PT NAD) — системы поведенческого анализа трафика от Positive Technologies. Недавно коллеги из техпода PT Sandbox рассказали, какая работа проводится, пока вы ждете ответ на свое обращение. Вышло здорово, и я решил поддержать этот тренд. Сегодня расскажу, как мы работаем с обращениями и что «дарим» в дополнение к решению проблемы пользователя. За последние три года мы обработали более 3500 запросов, не считая вопросов в нашем телеграм-чате. Давайте рассмотрим пример одного такого обращения.
Не так давно я работал сетевым инженером в региональном Интернет провайдере с услугами, в основном, для домашних абонентов. А потом ушёл в корпоративный сегмент, в компанию с большой филиальной сетью по России. И помимо того что это другой опыт и другой взгляд на профессию - это другой взгляд на провайдера и его взаимодействие с клиентами, теперь уже со стороны клиента. Нельзя сказать, что для меня получилось сделать какие-то невероятные открытия в этом взаимодействии, нет, но какие-то моменты получилось сформулировать более точно, про них и будет в этой статье. Рассмотрим реальные, я думаю типичные, ситуации из практики работы сетевого инженера в бизнес компании с провайдерами Интернет через призму отношения к этому со стороны провайдера в том числе.
Приветствую всех, кому интересна тема перехода с Jira на альтернативные решения.
Совсем недавно мы, GlowByte Soft, рассказывали о том, какие бизнес-процессы компании могут автоматизировать на базе ITSM-платформы ZenTao. По откликам мы поняли, что нужно подробнее остановиться на самой базовой и самой главной функциональности ITSM-платформ – управлении сервисом и работе с заявками.
