Доставка товаров и продуктов на дом облегчает жизнь, особенно, если это жизнь в условиях самоизоляции или удалённой работы из дома. 2020 год обрушил на наши головы и в наши мобильники почти десяток приложений с собственной доставкой и море интернет-магазинов привычных сетей с услугами сторонних доставщиков. А раз так, почему бы не провести небольшое исследование и не проанализировать, какие они, сервисы доставки, и насколько они отвечают ожиданиям простого клиента.
И снова здравствуйте. Сегодня мы бы хотели обсудить не столько вопрос разработки технологий, о которых мы рассказывали в этой и вот этой статьях, сколько вопрос поддержки клиентов, которые эти технологии используют. На самом деле, это вовсе не праздный вопрос, а решение сложной проблемы, не менее трудной, чем обучение многослойной нейросети. Техподдержка - одна из головных болей стартапов и молодых компаний.
Ведь хочется, чтобы поддержка продукта была круглосуточной и круглогодичной, а клиенты были всем довольны. Когда планируешь, как все это будет работать, то нередко рисуешь себе идеальную картину с розовыми пони. К сожалению, в реальной жизни все немного иначе - розовые пони исчезают сразу, как начинается планирование службы поддержки со всеми деталями, включая стоимость оплаты услуг специалистов, планирование смен, ТК РФ. Сегодня хотим поделиться опытом.
Привет, Хабр! Несмотря на то, что информационная безопасность и все, что связано с этой сферой, сейчас на хайпе, найти инженера технической поддержки по ИБ задача непростая. Еще больше ее усложняет расхожее мнение, что техподдержка только для джунов, а более опытные специалисты должны переходить в проектную деятельность. Чтобы развенчать этот миф, подробнее расскажем о профессии и возможностях, которые она открывает.
Одни из самых интересных задач в работе администратора приложений, на мой взгляд, это осуществление миграции данных при переходе на новую систему. Сегодня я хочу поделится собственным опытом переноса данных с не очень известной helpdesk системы VisionFlow в более известную систему ServiceNow.
Как-то произошел в нашем дата-центре интересный случай:
Клиент привез сервер на размещение (colocation) и все было хорошо до тех пор, пока в его системе не объявился модный на тот момент вирус-шифровальщик.
Пострадавший обратился в поддержку дата-центра с просьбой восстановить бэкап. Инженеры отнеслись с пониманием и решили помочь, попросив предоставить бэкап, который необходимо развернуть. Однако, клиент изумился и спросил:
- А вы что, не делали мне бэкапы!? Зачем я тогда вообще размещаюсь по вашему???
….
Всем привет! В этой статье речь пойдет про неочевидные причины, из-за которых вы можете потерять свои данные и как с этим связана дебиторская задолженность в проекции на наиболее популярных на рынке хостеров.
оригинальное название Knowledge Management Is Not Just About Document Repositories
автор Stuart Rance
дата публикации 23.7.14
Достоинства: лаконичность, простота, рациональность взгляда.
Недостатки: слишком кратко.
Уровень - ликбез
Оценка 8/10
Это продолжение публикации переводов заметок Стюарта Рейнса (одного из авторов ITIL) с блога SysАid. Почему именно он? Мне интересен его немного отличный от общепринятого взгляд на привычные процессы. Он всегда за упрощение и сохранение сути. Надеюсь Вы разделите этот интерес.
Как всегда, прошу, если минусуете, то в комментариях пишите, пожалуйста, что именно не понравилось. Без этой информации я не смогу даже сделать попытку устранить причину Вашей негативной оценки.
Приятного и полезного чтения….
Поддержка влияет на отток клиентов, продажи по сарафанке. В данной статье мы расскажем о нашем опыте и поделимся рецептами, которые помогли стать поддержке нашего дата-центра лучше.
Оригинальное название: How to Make Your ITSM Processes Work for You
Автор Stuart Rance, дата публикации 15.01.2019
Достоинства:
- описана вполне разумная и привлекательная идея
- простота текста
- доходчивые примеры
Недостатки:
- идея привлекательная, только не рассказывается, как ее реализовывать в жизни
Сложность - базовая
Оценка 8/10
Оригинальное название Defining Metrics for the Service Desk
Автор Stuart Rance
Дата публикации 3.5.15
Достоинства: подробно рассмотрены
- понятие целей (objectives) и критических факторов их достижения (CSFs) и их отличие от ключевых показателей (KPIs)
- для чего использовать KPIs и почему в отчетности фокусироваться на целях и CSFs
Недостатки - слишком компактно.
Уровень - базовый
Оценка - 8/10.
Количество самого разного оборудования во всём мире неуклонно растет. Не последнюю роль в этом играет развитие промышленного интернета вещей (Industrial Internet of Things, IIoT) и повсеместное проникновение “умных” устройств: датчиков, контроллеров и т. д. Согласно прогнозам уже к концу 2020 года количество “умных” устройств в мире превысит 200 миллиардов. Вся эта "армия" оборудования, несмотря на возможности удаленного управления, требует профилактического и выездного обслуживания (Field Service Management, FSM).
Расскажем об основных правилах повышения эффективности выездного обслуживания. Их 7.
Приветствую всех. С кем не знаком - Андрей Балякин: 7 лет в сервисном бизнесе, 20 лет в ИТ. Предприниматель. Последние несколько лет - CEO проекта HubEx (ИТ платформы автоматизации выездного обслуживания и управления сервисными процессами).
Цель публикации - собрать мнения и всесторонний опыт тех, кто внедрил какие-либо системы для управления выездными сотрудниками в своей компании и готов поделиться опытом с остальными.
Оргинал: Defining Metrics for Problem Management
By Stuart Rance | Originally published on June 24, 2014 in ITIL | Updated on November 28, 2017
Это перевод второй статьи на тему определения показателей для процессов Управления ИТ- услагами. Ценность ее в применении техники формулирования показателей на основе требований к результатам процесса (здесь и далее курсивом выдлелены комментарии переводчика).
Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов.
Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели.
Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете.
Если у Вас был опыт общения с руководителем отдела технической поддержки, то наверняка первое, что Вы от него услышали это многочисленные жалобы на жизнь, сотрудников и жестоких клиентов.
Управлять небольшой службой техподдержки из 5 человек еще как-то можно, но когда людей становится больше, а количество обращений в день переваливает за сотню, то жизнь руководителя превращается в ад: постоянные эскалации, перегруженность персонала и почти полная утеря контроля за происходящим.
Просто представьте, что у Вас сотня админов, которых Вы ежедневно обеспечиваете работой (это не выдумка, а реальность).
В этой ситуации надо что-то предпринимать. Тут каждый выкручивается как может – выдумываются многочисленные отмазки, изобретается «стандартизация», клиентов заставляют заполнять невероятных размеров формы с полями, назначение которых невозможно угадать, а при каждом удобном случае обращения скидываются с исполнителя обратно на клиента. На нарушения SLA (плановых сроков исполнения заявок) вообще никто не смотрит. Перечень мер можно продолжать бесконечно.
Проблема не нова и не уникальна – она присутствует на каждом предприятии, в какой бы области оно ни работало. Перепроизводство, перегруженность персонала, проталкивание срочных заказов. Аналогии напрашиваются.
Можно ли с этим что-то сделать? Конечно! Работающие и очень эффективные меры давно известны – это Бережливое производство (Lean Manufacturing) и Теория ограничений (Theory of Constraints, TOC).
Давайте посмотрим как методы и метрики бережливого производства могли бы послужить на благо службы технической поддержки Вашей компании.
