Service desk

У нас часто ругают отечественное. Во многом справедливо. Дороги, туалеты, отсутствие канализации, газификации, низкие пенсии, отечественный автопром (вёдра с гайками). А ещё ругаем банки. И тоже есть за что их ругать. Обманывают. Не по делу жрут наше время, которое стоит денег. Но здесь я буду их хвалить. Всё познаётся в сравнении. И приятно когда в России справедливо есть чем гордиться. И повод для гордости не то, что сделали очередную Кузькину мать, которая может весь мир в труху, а нас в рай, а то, что Россия опережает Европу.

Интерфейсы, импорт данных и общее сравнение

Подготавливая материалы для данной статьи я анализировал, а что уже было написано до меня и наткнулся на статью 2015 года, которая хвалит европейские банки. Но я имею опыт с европейскими банками с 2012 года, когда поехал учить английский в Европу. Меня тогда ещё поразило, что банки там работают всего несколько часов в день с перерывом на обед. Сделать перевод огромная проблема. Открыть счёт иностранцу нереально было в Англии. А вот в Словении было, по-моему, намного проще.

Мне нужно было перевести из Германии 56к евро в Словению между двумя банками Unicredit. Так мне отказали и пришлось с котлетой кэша лететь из Гонновера в Лондон, а из Лондона в Любляну. Прям мафиози себя почувствовал. В России впрочем у иностранцев тоже проблемы.

Свой первый счёт в иностранном банке я получил в 2012 году в Словении. Банк UniCredit. Ни в какое сравнение с нашим Tinkoff словенский UniCredit не шёл уже тогда. И до настоящего времени там ничего, по-моему, не поменялось. Последний раз сталкивался в 2019 году, пока они не начали закрывать счета всем иностранцам.

В России мы давно интегрировали нашу CRM с банками по технологии DirectBank. В Словении до сих пор нет ни одного банка с API. В Словении порядка 20 банков и во все нужно загружать XML и выгружать данные в XML и в PDF для бухгалтерии. Вообще Европа как-то не дружит с облаками. Все шлют аттачи, вместо того, чтобы послать ссылку на файл в облаке.

Борьба словенских банков с компаниями основанными иностранцами привела нас в Revolut. Ещё пробовал PaySera и совсем чуть-чуть TranswefWise. У PaySera интерфейс ЛК как у нас в первой половине нулевых сайты делали. Но бог бы с дизайном, проблема, что медленный, висел и ужасно запутанный.

Revolut тоже было висел днём несколько часов. Но это пустяки относительные. Интерфейс у Революта хотя бы современный.

Про Revolut много было шума, что он придёт в Россию и подвинет Tinkoff. Дудки! Tinkoff может не опасаться это ведро с гайками.

Сравнение поддержки

Were experiencing a high volume of requests due to overwhelming demand today. Please check our FAQs here: https://www.revolut.com/business/help. Youll be able to find answers to most of your questions there.

Revolut клиентов не уважает. Причём это такое показательное неуважение как российское православие показушное ну или как советские коммунистические идеалы. Тебе наворачивают такой вежливости от которой просто мозг взрывается. Клиенту вежливо объясняют: "отстань, глупый, не до твоих проблем нам, не видишь, что мы заняты".

У российских банков в ЛК и приложении есть онлайн чат. Это уже просто норма. Онлайн чат доступен на каждой странице. И туда сразу можно написать свою проблему. Есть хорошие банки с хорошей поддержкой. Раньше у Тинькова было хорошо, а потом с роботом стало плохо. Недавно писал, робота не было. Может они научились подключать живого оператора, если робот не может дать качественный ответ. Правда сегодня опять писал и робот появился.

У Revolut chat нужно найти. И чат сразу же сообщает, что все операторы заняты, иди мужик отсюда FAQ почитай или в Revolut Community спроси. А в этот Revolut Community не пускают прям из ЛК Революта. Нужно зарегистрироваться. Но зарегистрировавшись всё равно нельзя вопрос задать. Можно только читать.Круг замкнулся и мой мозг в поисках логики тоже. Зачем отправлять клиентов в Community, если они не могут там вопрос задать?!

Ладно разбираемся как всё же написать в чат, нужно нажать не яркую кнопку Got it, а догадаться прокрутить вниз и нажать блеклую кнопку Chat with us.

За несколько рабочих дней переписки в чате, операторы там постоянно меняются, все многоэтажно вежливые, но ни одну проблему не решают. Только говорят, что куда-то передали. А потом автоматическое сообщение, ну типа ты чувак в офлайне, поэтому если что пиши и удачи тебе. И две кнопки: решена проблема или продолжить. А если день не отвечать, то они чат сами закрывают, мол Всё хорошо, прекрасная маркиза .

Чат поддерживает разные ветки, но нельзя открыть новую ветку пока не закроешь старую.

В России поддержка тоже далеко не всегда супер. Но Яндекс по моему обращению переписывал код Метрики, чтобы там не было inline стилей и JS, чтобы Метрика нормально работала с заголовком Content-Security-Policy. Сбербанк реально напрягался и пытался хотя бы помочь решить проблему своего API для платежей по периодическим услугам нашего дата-центра. Поддержки Точки, Модульбанка нормально отвечали по вопросам DirectBank.

Сравнение API, безопасности

Revolut не просто ведро с гайками, а дырявое ведро. В документации описано, что токен можно запросить с правами READ, WRITE. Запрашиваю с правом READ и на стадии аутентификации меня начинают терзать смутные сомнения:

Думаю, ну может это просто интерфейс такой, верстальщики так сверстали. Ну так же не может быть в банке с 10М+ клиентов. Это же какой-то бред.

Как бы не так. Работает на запись отлично!

В российских банках API работает по уму. Через DirectBank можно читать данные и писать отправлять платёжки, зарплатные ведомости и что там ещё API DirectBank позволяет. Но деньги никуда не отправятся пока лицо с правом подписи не зайдёт в ЛК или приложение и не подпишет платёжки. То есть подписание платёжек производится через независимый канал СМС. Есть тут минус, что зависим от сотовой сети, СМСки не всегда доставляются оперативно. Значительно лучше бы использовать ENUM или аппаратный токен.Кстати, в словенском Unicredit был аппараnный токен, но там не было API, а теперь он позакрывал счета многим иностранцам.

А у Revolut получаешь токен и отправляй платежи. Но токен удобно хранить в CRM. И удобно, чтобы платёжку в банк могли отправить бухгалтеры, менеджеры или сама CRM автоматически получив счёт от клиента. Но нужен этап подписания платёжки директором. А тут обломс.

Платёжки в Революте создаются с id контрагента, который был ранее создан. Еще контрагенту нужно добавить его счёт (IBAN). В ЛК можно добавлять и удалять счета, а вот через API нельзя. Поддержка рассказывает сказки, что в будущем они примут к сведению. Можно создать несколько контрагентов с одинаковым именем и разными счетами. Но это каша. У контрагента нет уникального поля вроде ИНН или регистрационного номера, чтобы можно было различить две разных компании Ромашка. Через API можно удалить контрагента и создать его заново с новым списком счетов. Какие индусы ж так API писали?! Но тут проблема. При создании нового контрагента он получит новый id, а ранее проведённые платежи будут привязаны к старому id.

У меня были мысли как реализовать относительно безопасную работу с двумя токенами READ & WRITE. Идея была запрашивать токен со scope WRITE только перед отправкой платёжек и не сохранять его. Тут получалась как бы двухфакторная авторизация с риском, что хакеры паровозом довесят платёжек при отправке. Но теперь когда выяснилось, что токен с правами READ может записывать данные рисковано даже импорт платежей делать.

Ещё одна проблема API Revolut, что нет возможности отозвать токен.

Заключение

После опыта с европейскими банками меня разрывают чувства гордости за Россию. Хочется ехать с российским флагом.

Если бы Tinkoff, ModulBank или Tochka пришли в Европу, то они смело бы могли брать 25-50евро в месяц с корпоративных клиентов. Ну и с частных по 5-25.

Если кому приходилось интегрироваться с американскими или азиатскими банками по API, расскажите как у них.

Привет, Хабр! Несмотря на то, что информационная безопасность и все, что связано с этой сферой, сейчас на хайпе, найти инженера технической поддержки по ИБ задача непростая. Еще больше ее усложняет расхожее мнение, что техподдержка только для джунов, а более опытные специалисты должны переходить в проектную деятельность. Чтобы развенчать этот миф, подробнее расскажем о профессии и возможностях, которые она открывает.

В сервисном департаменте STEP LOGIC на двух линиях технической поддержки работает более 50 специалистов. Сейчас они обслуживают порядка 150 сервисных контрактов это более 10 тыс. инцидентов в год. Первая линия поддержки проводит классификацию обращений заказчиков и если проблему можно решить по скрипту, то закрывает заявку своими силами. Если сделать это в течение первого часа не удается или требуются дополнительные компетенции, то инцидент передается на вторую линию поддержки, инженеры которой обладают более глубокими техническими знаниями и навыками.

Как сервисные партнеры нескольких крупных вендоров, мы имеем право оказывать услуги по технической поддержке оборудования от их имени. Например, при обслуживании оборудования Cisco наши специалисты решают до 80-90% проблем самостоятельно, за помощью к вендору мы обращаемся только при гарантийной замене или обнаружении программных ошибок. Для того, чтобы вендор авторизовал партнера на предоставление совместных услуг, в штате обязательно должны быть сертифицированные инженеры, имеющие CCIE или, как минимум, CCNP. Еще два обязательных условия прохождение ежегодных аудитов на соответствие уровня услуг, требования к которым схожи с лучшими практиками ITIL, и принцип оказания технической поддержки, основанный на практиках Cisco CX Specialization.

Конечно, оптимальное решение для компаний, у которых есть локальная задача поддержки оборудования конкретного вендора, это покупка его стандартных пакетов обслуживания. У того же Cisco, например, есть варианты на разный вкус и кошелек: контракты Cisco SMARTnet или расширенная версия Solution Support, Next Calendar Day, если нужна замена оборудования в выходной или праздничный день, профессиональные услуги вендора Advanced Services (AS) и Business Critical Services (BCS), если заказчику необходим дизайн сети. Но бизнесу, в котором требования постоянно меняются, зачастую удобнее работать с компанией, которая будет жить в конкретной инфраструктуре, понимать, как она построена, в чем ее плюсы и минусы, узкие места и иметь опыт работы с технологиями разных производителей. Востребованы наши услуги и в системах высокой критичности, где нужен высокий SLA с фиксированным временем решения и круглосуточный сервис. Совместное оказание услуг часто удобно и самому производителю, так как он может не держать большой штат поддержки и сосредоточиться на основном бизнесе, не переживая при этом об уровне сервиса.

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

Коротко портрет потенциального кандидата можно описать так: инженер, который более года работал в поддержке безопасности с оборудованием ведущих ИБ-вендоров и хорошо разбирается в сетевых технологиях.

График работы предлагаем стандартный 8 часов 5 дней в неделю. Иногда по отделу назначаются дежурства. Если ночью появилась критичная проблема, то дежурному придется подключиться и разобраться с ней. Но есть и небольшой плюс ехать никуда не нужно, специалисту выдается доступ в систему, с помощью которого он может работать удалено. Собственно, поэтому мы и не зацикливались на Москве или области, а сразу расширили зону поиска на всю Россию.

Почему возникли проблемы

• Небольшое число подходящих специалистов. Забив перечисленные выше параметры на hh.ru, мы видим чуть более 70 человек, находящихся сейчас в поиске работы. Если бы мы искали сотрудника в московский офис, то ситуация была бы еще хуже. Для сравнения, при поиске бухгалтера сайт выдает более 1000 подходящих резюме.

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

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

5 причин обратить внимание на вакансию инженера технической поддержки

1. Быстрый горизонтальный рост компетенций

   Минимальные начальные требования для кандидатов знание сетевых технологий, основ информационной безопасности, шифрования, принципов работы межсетевого экрана и системы предотвращения вторжений. Кроме стандартных файрволов и VPN, инженеры техподдержки работают с такими классами решений как Next Generation Firewall, SIEM, Web Application Firewall, DLP, IPS/IDS, Identity/AccessManagement, IRP/SOAR, Threat Intelligence. Это помогает развиваться не по одному направлению предметной деятельности, а более широко. Наши специалисты детально изучают оборудование ведущих ИБ-вендоров, тестируют в лаборатории его новые версии.

   Идеальный кандидат должен уметь работать в режиме многозадачности, быстро адаптироваться к изменениям и все схватывать буквально на лету. Такой темп работы позволяет быстро продвигаться по карьерной лестнице: в среднем, путь от младшего инженера техподдержки до ведущего эксперта в STEP LOGIC составляет 5 лет.

2. Возможность стать экспертом, так как нужно "копать" глубоко

   Работа инженера внедрения заканчивается после ввода проекта в эксплуатацию. Как сотрудники техподдержки, мы можем с уверенностью заявить, что все самое интересное на этом только начинается. Техническая поддержка это не только консультации клиентов по вопросам функционирования оборудования, удаленная диагностика и настройка, решение проблем, локализация и мониторинг аварий, но и совместная работа с вендором по устранению багов, разработка планов по развитию и миграции инфраструктуры. Недавно мы приняли участие в проекте по миграции, который стал для нас своеобразным челленджем. Немного предыстории: крупный российский банк для защиты периметра продолжительное время использовал межсетевые экраны Cisco ASA. За последний год объем трафика увеличился в несколько раз, и оборудование перестало с ним справляться. Заказчик закупил межсетевые экраны нового поколения Cisco Firepower и перед ним встала задача провести максимально бесшовную замену, так как инфраструктура критическая и должна работать 24х7. Необходимо было перенести с одной ОС на другую большое количество настроек: сотни интерфейсов, тысячи правил межсетевого экранирования, сотню VPN и сделать это в короткое окно работ. Была проведена комплексная работа, включающая в себя изменение настроек маршрутизации, трансляции NAT, редистрибуции и фильтрации тысяч маршрутов, учитывающая переходные процессы с целью минимизации возможных потерь трафика.

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

3. Развить командные навыки работы и soft skills

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

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

4. Научиться работать с технической документацией

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

5. Усовершенствовать технический английский

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

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

• эксперта по классу решений или технологии

• менеджера/сервис-менеджера/product owner по продукту или услуге

• руководителя нового направления/услуги

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

Таким образом, если работа с оборудованием и устранение неполадок приносит радость, среди soft skills присутствует пресловутая коммуникабельность и клиентоориентированность, имеется стойкое желание развить свои технические знания и стать экспертом в конкретной области ИТ, то у вас есть веский повод обратить внимание на вакансию инженера технической поддержки.

Статья рекомендуется к прочтению тем, у кого болит вопрос управления и контроля персонала на выезде, а также тем, кто собирает полезную информацию перед внедрением FSM или Service Desk системы для управления мобильными сотрудниками.

Приветствую всех. С кем не знаком - Андрей Балякин: 7 лет в сервисном бизнесе, 20 лет в ИТ. Предприниматель. Последние несколько лет - CEO проекта HubEx (ИТ платформы автоматизации выездного обслуживания и управления сервисными процессами).

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

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

Для начала давайте определимся, о чем пойдет речь: ИТ сообщество подобные системы часто называет ITSM или Service desk с приложением для мобильных сотрудников. В англоязычном мире под этот класс систем есть отдельный термин: Field Service Management или сокращенно - FSM (не путать с Workforce management). В переводе это звучит как управление полевым сервисом, но более понятным будет - управление выездным обслуживанием или управление мобильными сотрудниками.

Чем я поделюсь:

1. Представлю собранный в течении нескольких лет чек-лист для компаний, которые внедряют FSM решение для управления выездным обслуживанием. Он поможет четко сформулировать свои требования к системе

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

3. Обсудим, для каких компаний какие типы систем предпочтительнее

4. Объясню, на что следует обращать внимание перед внедрением решения для управления мобильным персоналом в своей компании

5. Приведу пример сервисного процесса и его стадий для более глубокого понимания требований к системе, а также удобной настройки процесса по шаблону, если систему вы уже выбрали

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

Чтобы избежать субъективных мнений по основным вопросам и принципиальным отличиям различных систем управления выездным обслуживанием, начну с мнения аналитического агентства Gartner. Он недавно выпустил свежую публикацию на тему Field Service Management-а в дополнении к обновлению магических квадрантов. Вот ссылка на статью для англо-понимающих: https://www.gartner.com/doc/reprints?id=1-2438LY1F&ct=200903&st=sb

Что говорит уважаемый Gartner?

Во первых:

Решения по управлению мобильными сотрудниками делятся на 2 категории, а при выборе следует учитывать следующие моменты:

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

1. мировой лидер в классе (имеется в ввиду следующее: берем SAP, Microsoft, Oracle и т.п. мировых лидеров + стартуем дорогостоящий проект адаптации/доработки/внедрения и пилим, пилим, пилим. Стоимость таких проектов, в среднем, от 200k$ до 900k$ по РФ)

2. выбираем нишевое отраслевое решение от локального вендора.

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

Получается, что первый вариант - дорого, богато, никаких компромиссов. Будет сделано именно то, что нужно вам (тут все часто зависит от зрелости команды внедрения и готовности бизнеса к долгострою и серьезным инвестициям) . Второй - значительно меньшие инвестиции и возможность в разумные сроки закрыть 80% функциональных требований. Но именно 80, не 100%!

Во вторых:

Gartner делит вендоров (разработчиков) систем управления выездным персоналом (FSM-систем) на три категории.

Appointment-Centric: в основе лежит управление заявками и расписаниями сотрудников

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

Equipment-Centric: в основе лежит выездное техническое обслуживание и ремонт оборудования

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

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

Для примера:

1. Приложение мобильного сотрудника должно помогать ему получить необходимую документацию по ремонтируемому оборудованию, технологические карты или коды ошибок

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

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

Outcome-Centric: для компаний, использующих модель Equipment-as-a-Service (Оборудование, как сервис/услуга)

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

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

Для таких компаний часто важнее всего быстрая диагностика оборудования и получение данных о работе (поломках) онлайн.

Что требуется от ИТ-системы в этом случае?

1. Наличие мобильного приложения, чтобы в режиме реального времени получать данные мониторинга оборудования, в том числе на выездах, и оперативно принимать меры

2. Модуль мониторинга оборудования, который, во-первых, сможет измерять показатель, за который платит заказчик, а во-вторых, контролировать работоспособность и фиксировать ошибки в работе оборудования

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

Ticket-centric: сервис деск на базе ITSM service desk/service management систем, расширенный мобильным приложением для выездных сотрудников и модулем управления расписаниями.

Фактически получаются системы вида Appointment-centric (ориентированные на работу с заявками), но, в отличии от последних, обычно имеющие ряд ограничений. Возможности этого класса решений обычно упираются в возможности ITSM систем, сделанных для ИТ и работающих в рамках ITIL практик. Как итог - выездным сервисным сотрудникам оказывается неудобно работать по процессам ИТ, у них своя специфика, отличная от ИТ-сервиса.

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

Appointment-centric: в основе лежит управление заявками и расписаниями сотрудников

Сотрудник и расписание вынесены в начало схемы намеренно, так как именно эти сущности определяют логику работы систем данного класса. Продвинутые Appointment-centric FSM системы позволяют удобно планировать загрузку персонала с учетом расписаний работы объектов. Они учитывают сменный график работы сотрудников, автоматически планируют и оптимизируют расписания, динамически перераспределяют заявки в случае форс-мажора.

Equipment-centric: выездное техническое обслуживание и ремонт оборудования

В начало процесса добавляется оборудование с иерархией до узлов и агрегатов, когда необходимо.

Все заявки привязываются к оборудованию. Выполнение плановых работ также привязывается к оборудованию.

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

Вся аналитика ремонтов, обслуживание и устранение неисправностей собирается вокруг оборудования. Фактически это получается FSM по модели ТОиР.

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

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

Outcome-centric: в основе лежит оборудование как услуга

Тут мы видим обвязку к упрощенной модели Equipment-centric FSM. Создание вложенных заявок на нескольких сотрудников обычно не требуется, однако добавляется обязательное условие получения информации о работе оборудования. Например, интеграция решения, по управлению выездным персоналом с IoT или мониторинговой системой, сообщающей о состоянии и работоспособности оборудования.

Outcome-centric: оплата за результат или достижение согласованных показателей

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

Ticket-centric: в основе лежит работа с заявками. Своего рода сервис деск, расширенный приложением для мобильных сотрудников

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

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

Еще один тип систем, которые пытаются использовать ряд компаний при реализации задачи управления выездными сотрудниками - настройка CRM под задачи FSM.

Какие функции вам точно потребуется или почему не стоит заменять специализированные решения на всемогущие CRM

Почему я добавил CRM? Причины две:

1. Среди ИТ-решений по управлению мобильными специалистами иногда встречается такое понятие как CRM для выездных сотрудников. По факту это то же самое FSM-решение с урезанной функциональностью или Service desk с примитивным мобильным приложением. Осмелюсь предположить, что CRM в названии присутствует по простой причине: FSM у нас в России не раскачена, такие запросы пользователи не ищут, а в поисковиках светиться нужно. И чем проще и понятнее ты назовешься - тем лучше. А CRM, как известно знают все

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

Заявка хоть и похожа на воронку со стадиями, которые можно как-то назвать, но в CRM нет и половины функций, которые требуются компаниям с мобильными сотрудниками. Например:

1. расписания сотрудников и объектов обслуживания в связке с специализаций и географией, позволяющие системе автоматизировано распределять заявки

2. учет оборудования и привязки к нему заявок / выполняемых работ

3. GPS-контроль персонала

4. ТОиР-модуль для работы с плановыми заявками и с возможностью создавать группы заявок по типам объектов, оборудования, видам работ и других сущностей системы

5. история обслуживания

6. расчет плановых сроков закрытия заявок согласно SLA с заказчиком

7. специализированные инструменты для экспресс-подачи заявок заказчиком

8. учет квалификации сотрудников и специальных документов, которые необходимо иметь для выполнения конкретных видов работ и без которых не получится назначить заявку на специалиста

9. справочник работ и услуг

10. иерархия объектов обслуживания, как и самих объектов с гео-привязкой на местности

11. оффлайн режим в мобильных приложениях

12. расчет стоимости выполненных работ и оказанных услуг через приложение

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

Это, конечно, далеко не полный список того, что не получится сделать в CRM тем, кому нужно управление заявками и выездными сотрудниками. Если я что-то забыл - дополняйте, пожалуйста, в комментариях. Интересен ваш опыт.

• CRM - это система преимущественно для отдела продаж. Ее можно использовать для других целей, понимая и принимая ограничения, но тут определенно не стоит рассчитывать на гибкость и высокий уровень автоматизации операционных процессов сервиса.

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

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

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

На этот раздел крайне рекомендую обратить особое внимание всех, кто планирует автоматизировать работу выездных сервисных сотрудников.

Для удобства структуру сделал в виде чек-листа, заполнив который по выбранным решениям можно сделать осознанный вывод: подходит решение или не совсем. Если подходит на 85% и больше - повод примерить.

Чек-лист для компаний, внедряющих FSM решение по управлению выездными обслуживанием: на что обратить внимание?

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

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

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

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

• Найдите у себя в компании лидеров мнений.

• Обсуждайте с ними новые процессы с самого начала.

• Показывайте систему.

• Дайте попробовать поработать и собирайте фидбэк.

• Мотивируйте их на результат (премии по итогам проекта, слава и поощрения, кому что)

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

Итак, чек-лист по выбору FSM решения.

Отметьте те пункты, которые важны для вашей компании, и оцените по ним различные решения на рынке. У кого есть опыт в работе /внедрениях Service desk или FSM решений для управления заявками и работой выездного персонала: возможно я что-то упустил в списке, так что дополняйте в комментариях. Буду обновлять список. В итоге получим удобный чек-лист для тех, кто выбирает систему управления выездным обслуживанием.2

Вот очень простой базовый процесс прохождения заявки на выездное обслуживание:

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

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

Дополнительно настраивается система уведомлений (кто что и когда должен получать при поступлении заявок на конкретные стадии или при просрочках / Опозданиях итп).

Аналитика: the last, but not least, как сказали бы англичане: последний по порядку, но не по значению.

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

Прежде отмечу, что важно иметь возможность видеть данные показатели в динамике, а также во всех разрезах, которые так или иначе присутствуют в системе, например в разрезе:

1. Периодов

2. Клиентов

3. Сотрудников

4. Оборудования

5. Объектов

6. Типам заявок

7. Типам работ

8. и т.д.

Оперативные показатели:

1. Кол-во открытых заявок

2. Кол-во не назначенных заявок

3. Кол-во заявок, не принятых в работу

4. Кол-во просроченных заявок

5. Кол-во заявок, по которым исполнитель опаздывает на объект

6. Кол-во заявок, которые истекают сегодня

7. Среднее время реакции диспетчера

8. Кол-во футбольных заявок, по которым исполнители несколько раз отказались от выполнения

Данные показатели предназначены, преимущественно, для диспетчеров или сотрудников, контролирующих назначение или исполнение заявок в срок.

Метрики для руководителей

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

Условно выделяемые нами показатели можно разделить на следующие категории:

Количественные:

1. Кол-во созданных заявок за период

2. Кол-во закрытых заявок за период

3. Кол-во эскалированных заявок за период

4. Кол-во закрытых в срок / не в срок заявок

5. Кол-во отказов исполнителей по заявкам

6. Динамика создания/закрытия заявок с графиком их сгорания

7. Соотношение заявок по типу заявки

8. Соотношения заявок по срочности

9. Соотношение заявок по типу работ

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

11. Кол-во обслуживаемых объектов / оборудования

12. Кол-во клиентов

SLA показатели:

1. Contract Uptime Rate % бесперебойной работы оборудования

2. First Time Fix Rate - % выполненных заявок с первого посещения

3. Repeat Visit кол-во повторных визитов на объект по одной и той же заявке

4. Нарушения сроков разрешения заявок, указанных в SLA

5. Оценки клиентов по выполненными работам

6. Превышение фактического времени выполнения заявок относительно планового по типам работ

Временные показатели:

1. Average Time to Fix среднее время выполнения работ исполнителями

2. Average Time to Complete среднее время от создания до закрытия заявки

3. Среднее время реакции диспетчера

4. Среднее время принятия исполнителем заявки в работу

5. Среднее время от создания заявки до назначения на исполнителя

6. Среднее время от принятия заявки исполнителем до переведения в статус В пути

7. Среднее время исполнителя на дорогу

Финансовые показатели:

1. Выручка

2. Прибыль

3. Средний чек

4. ТОП клиентов по выручке и прибыли

5. Доля выполненных заявок по контракту и по сдельной схеме

6. Service to Cash Time время от завершения работ исполнителем до поступления оплаты от клиента

7. ABC анализ клиентов

Показатели по исполнителям

1. Utilization Rate % рабочего времени исполнителей, которое было потрачено на работу и оплачено клиентами

2. Tasks Per Person среднее кол-во выполненных заявок на одного исполнителя

3. Отработанные сотрудниками часы

4. Переработки сотрудников

5. Оценки клиентов по выполненным исполнителями работам

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

Итого

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

Шаги внедрения

1. Определите, к какому подклассу должна относиться целевая FSM система для вашей организации: appointment-centric / equipment-centric / outcome-centric или ticket-centric.

2. Найдите поддержку среди лидеров мнений в вашей организации

3. Зафиксируйте цели внедрения системы и показатели, оцифровка которых крайне важна

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

5. Сформулируйте требования к системе, воспользовавшись предложенными выше шаблонами

6. Проанализируйте рынок решений с учетом типа FSM решения из п.1,

Удачи в нелегком, но важном и абсолютно верном начинании.

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

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

Заранее благодарю!

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

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

Начинаем с малого: ты, да я, да мы с тобой

Мы не собирались строить все из ничего, сходу создавая сложную структуру саппорта. Начали с малого в апреле 2020 года. Тогда мы пригласили тимлида и попросили его найти коллегу-инженера. Вместе они занимались решением технических вопросов, которые нужно было решать партнерам и клиентам. Чуть подробнее о том какие вопросы решались - ниже, в подразделе Диверсификация обязанностей. Ни о какой круглосуточной работе изначально не было и речи, это была стандартная пятидневка и график с 9:00 до 18:00.

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

Суббота и воскресенье? Работаем!

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

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

Подсчитали, сколько еще людей нужно добрать, прокалькулировали связанные с расширением операционные расходы, посмотрели статистику звонков. Как оказалось, основной трафик идет по будням с 10:00 до 20:30, так что смысла оплачивать дополнительные 14 часов в день пока не было. Но вот субботу и воскресенье решили добавить.

Решение нашли быстро: недельный дежурный с дополнительной оплатой по выходным.

А теперь - диверсификация обязанностей

Компания росла, расширялся и отдел поддержки. Не очень быстро - к октябрю 2020 года количество сотрудников в нем достигло 6 человек. Это 1 тимлид и 5 инженеров.

Клиенты и партнеры саппортом были вполне довольны. Но задач, конечно, стало больше, увеличилось и их разнообразие. С течением времени мы стали замечать, что отдел сам по себе разделился на две части, как раз по типам решаемых задач. Условно это было разделение на "Help Desk" и на "мониторинг". Работа стала эффективнее, и мы уже официально разделили отдел на два подразделения:

• Help Desk - 2 человека

• Мониторинг - 3 человека

Единственное - тимлида разделить не удалось, поскольку он был один и не хотел, чтобы его делили. Пришлось оставить его как есть, с условием, чтобы он координировал работу всего отдела.

Задачи Help Desk:

• Поддержка платформы и локализация ее проблем (ошибки API; кнопка работает не так, как должна; нет доступа и тд.).

• Поддержка сервисов платформы и локализация проблем с ними (робот не звонит, вместо "привет" распознает "вечер, море, хочу в отпуск", тарабанит фразы как робот и становится не похож на человека).

• Поддержка SIP-телефонии (сетевые проблемы телефонии).

• Поддержка External API.

Задачи мониторинга:

• Мониторинг сетевой инфраструктуры и своевременная реакция на возникающие проблемы (сервера, базы данных, сетевое оборудование).

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

Спустя некоторое время оценили преимущества разделения:

1. Специалисты саппорта прекрасно знали свои обязанности и не мешали друг другу.

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

3. Задачи выстроились в стройную систему.

4. Выходные можно закрывать без дежурного.

Последний пункт стоит немного пояснить. Дело в том, что на этом этапе мы отказались от дежурного в подразделении Help Desk. Вместо этого мы предложили подразделению мониторинга 7-часовой рабочий день по будням с тем, чтобы на выходные у сотрудников оставалось 10 дополнительных часов. Это решение обсуждалось вместе с сотрудниками, которые были не против. Схема простая: сначала один человек работает по 7 часов по будням и в выходные, потом второй, потом третий и так далее. Ну а затем - наша песня хороша, начинай сначала.

Ну привет, круглосуточная поддержка

Выше уже упоминалось, что круглосуточную поддержку мы не вводили, поскольку подавляющее большинство клиентов и партнеров обращались с вопросами в обычное время - с 10:00 до 20:30. Почему так? Все просто - те, с кем мы работали ранее, находились в одном с нами часовом поясе.

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

Сначала получалось так:

1. Help Desk - c 9:00 до 18:00 по будням. Здесь пока что ничего не менялось.

2. Мониторинг - 3 смены: 9:00-18:00 (2 человека), 14:00-21:00 (1 человек), 1:00-9:00 (1 человек, добрали позже из другого часового пояса на ГПХ).

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

Изначально выбирали из трех перспективных вариантов реализации полноценного круглосуточного саппорта:

1. Три смены по 9 часов - утро, вечер, ночь.

2. 2/2 по 12 часов

3. Сутки через трое (Why not? как гипотеза подойдет)

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

1. Желание сохранить команду (многим не нравится сменный график, и в этом нельзя никого винить)

2. Необходимость сделать оплату смен достойной (текучка кадров никому не нужна)

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

4. Поиск сотрудников.

Поразмыслив, мы решили оставить первый вариант - три смены по 9 часов. Почему так? Режим сутки через трое рассматривался просто как экзотичный вариант. Но работать 24 часа, а потом трое суток быть дома - на это соглашаются далеко не все, и это понятно. Суточные смены очень сложные.

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

Что было сразу, до глобального перехода на круглосуточную работу?

1. Help Desk - 4 инженера.

2. Мониторинг - 3 инженера + 1 инженер ночью.

Теперь решаем наши задачи:

Сохраняем команду - оставляем у всех все так, как есть сейчас. Пусть продолжают работу по стандартному графику - 9:00-18:00

Рассчитываем минимальное количество людей на смене - тут все зависит от нагрузки и трафика в вечер и ночь. В нашем случае достаточно по 1 человеку на ночную смену для каждого подразделения:

Итого нужно:

1. Help Desk - 4 утро, 1 вечер, 1 ночь.

2. Мониторинг - 3 утро, 1 вечер, 1 ночь.

После решения этой задачи приступаем уже к реализации. Набрасываем график с 18-20 обязательными сменами (естественно, его можно варьировать), чтобы был запас на больничные/отпуска и ребята могли добрать смен вплоть до 25+.

Где мы искали дополнительных сотрудников для вечерних и ночных смен? Да где и все, собственно - HH, Rabota, LinkedIn и др. Кстати, были даже попытки найти разработчиков на Tinder, но об этом уже в другой раз.

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

Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов.

Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели.

Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете.

Первый шаг для определения качественных ключевых показателей (KPIs) - определить цели процесса Управления проблемами, которые его результаты должны помочь вам достигнуть. Для у правильного процесса Управления проблемами есть два ключевых результата:

• уменьшение количества возникающих инцидентов

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

Мы можем просто измерять количество инцидентов и их общее влияние на бизнес. Это точно будет полезно знать, но я не уверен, что они смогут показывать, как хорошо работает именно процесс Управления проблемами, т.к. слишком много факторов на него влияет. Я немного разбавлю их и предложу несколько критических факторов успешности (CSFs), которые могут поспособствовать получению результатов:

• определение проблем, которые являются причиной множественных инцидентов

• создавать среду, которая снижает влияние от инцидентов

• инициирование изменений, которые уменьшают количество инцидентов

Стоит сказать, почему я не упомянул поиск корневых причин проблем (root cause analysis, RCA). Я видел много людей в управлении проблемами, кто думал только о поиске корневых причинах, но это не давало им особого результата, потому что RCA - это не более чем одна из техник, используемых в Управлении проблемами. Худшие ключевые показатели, которые можно придумать, - это среднее время обнаружения корневой причины, доля проблем, у которых ключевая причина была выявлена не хуже 3 дней и т.п. Использование таких показателей провоцирует участников Управления проблемами на поведение, которое мне бы не хотелось получить. Это равносильно заявлению, что в сложной многофакторной ситуации нужно искать единственную корневую причину. Для меня более правильный способ - это проведение постоянного анализа, даже если в его результате удастся идентифицировать только одну значимую причину.

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

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

CSF1 - определение проблем, которые являются причиной множественных инцидентов

• увеличение доли инцидентов ассоциированных с записями о проблемах или известными ошибками

• отчет о топ 5 проблем создается каждый месяц

CSF2 - создавать среду, которая снижает влияние от инцидентов

• увеличение доли инцидентов, для которых в базе знаний есть статьи с решениями

• увеличение доли инцидентов решенных пользователями с использованием инструментов самостоятельного решения

• уменьшение влияния инцидентов, ассоциированных с топ 5 проблем прошлого месяца

CSF3 - инициирование изменений, которые уменьшают количество инцидентов

• уменьшение количества инцидентов, ассоциированных с топ 5 проблем прошлого месяца

• уменьшение беклога незавершенных проблем

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

На сколько метрики, измеряемые в вашем процессе Управления проблемами, соответствуют потребностям ваших заказчиков?
Когда вы пересматривали в вашем процессе Управления проблемами ключевые показатели (KPIs) и связанные с ними факторы достижения успешности (CSFs) и цели?

PS Если тема интересна, можно познакомиться со статьями Стюарта Рейнса:

Как определять метрики для процесса Управления (перевод, оригинал)

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

У меня есть серия заметок о метриках (metrics) и ключевых показателях результативности (Key Performance Indicators, KPIs), для оценки нескольких областей Управления ИТ-услугами (IT service management). И они были очень популярны, т.к. посвящены теме, в которой многие людей ищут подсказки. Вот эти заметки:

• Как определить метрики для процесса Управления изменениями (перевод, оригинал)

• Как определить метрики для процесса Управления проблемами (перевод, оригинал)

• Как определить метрики для процесса Управления инцидентами (перевод, оригинал)

• Сбалансированная система показателей для ключевых показателей IT (перевод, оригинал)

На одну из них я получил запрос: А как насчет техподдержки?. Ниже мои мысли о том как можно посчитать техподдержку.

Рекомендуемая картина мира при определении метрик и ключевых показателей

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

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

Также нужно прояснять понимание целей и критичных факторов успешности (Critical Success Factors, CSFs), которые необходимо выполнить, чтобы обеспечить достижение целей. Каждый ключевой показатель должен поддерживать одну или более целей или критичных факторов. Отчеты и обсуждения с заказчиками стоит вести о целях и критичных факторах, их поддерживающих, а не о ключевых показателях. I в KPI означает индикатор. Показатели - это не доказательство достижения цели, а всего лишь индикатор, помогающий понимать тренды и проблемы.

Цели и критичные факторы для техподдержки

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

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

• Мы хорошо общаемся с нашими пользователями, поддерживаем их достаточным объемом информации и соответствуем их ожиданиям

• Мы решаем пользовательские инциденты быстро и эффективно

• Мы выполняем запросы на обслуживание быстро и эффективно

• Мы достигаем высокого уровня удовлетворенности заказчика

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

Я использовал термины цели или критичные факторы (objectives or CSFs) для обозначения высокоуровневых понятий. Мы провели бесконечное число обсуждений о разнице между двумя этими понятиями, но это не так уж и важно. Просто будьте уверены в том, что нашли то, о чем стоит заботиться. В идеале стоит остановиться на 3-6 целях или критичных факторах. Если будет больше, то отчеты будут слишком длинными и слишком размытыми.

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

  • все взаимодействия пользователи могут инициировать по телефону или через портал самообслуживания (Да/Нет)

  • процент телефонных звонков принятых в течение 30 секунд

  • процент непринятых телефонных звонков

  • результаты ответа на вопрос: Как проще всего связаться с IT, когда они нужны? в ежегодном опросе удовлетворенности заказчиков

• Мы хорошо общаемся с нашими пользователями, поддерживаем их достаточным объемом информации и соответствуем их ожиданиям

  • процент инцидентов, по которым пользователи запрашивали текущее состояние решения

  • процент инцидентов, возвращенных пользователем в работу после того, как техподдержка их закрыла

• Мы решаем пользовательские инциденты быстро и эффективно

  • процент инцидентов, решенных не хуже утвержденного уровня обслуживания (SLA)

  • процент инцидентов, решенных пользователями самостоятельно используя портал самообслуживания

  • процент инцидентов, решенных в течение первого контакта с пользователем.

• Мы выполняем запросы на обслуживание быстро и эффективно

  • процент запросов на обслуживание, выполненных не хуже утвержденного уровня обслуживания (SLA)

  • процент запросов на обслуживание, выполненных без ручных операций со стороны ИТ сотрудников

• Мы достигаем высокого уровня удовлетворенности заказчика

  • процент пользователей поставивших оценки 4 или 5 в опросе удовлетворенности результатом решения инцидента

  • увеличение удовлетворенности заказчиков работой техподдержки в ежегодном опросе удовлетворенности

Эти примеры ключевых показателей основаны на целях и критичных факторах для техподдержки. Их не стоит путать с более детальными ключевыми показателями, которые могут использоваться для измерения процесса Управления инцидентами (incident management process).Вам может также потребоваться несколько дополнительных внутренних ключевых показателей для измерения на сколько рационально техподдержка использует свои ресурсы, но это вряд ли будет интересно заказчикам (внутренним заказчикам это будет очень даже интересно).

Заключение

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

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

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

Как нас когда-то учили переходить дорогу

Когда я был маленьким ребенком, нас учили переходить дорогу, давая такие инструкции:

• Остановись на краю дороги

• Посмотри направо

• Посмотри налево

• Снова посмотри на право

• Прислушайся

• Если все чисто и тихо, переходи

И мы напевали эти слова всякий раз, когда требовалось перейти дорогу.Конечно, из-за юного возраста мы не понимали реальную опасность, но, как и многие другие, я думал, что повторение этих магических слов мне помогает защититься от этих гадких машин. Сейчас я не уверен осознавал ли тогда, что меня подталкивают быть осторожным и услышать, чтобы заметить автомобили, которые не видны взгляду. А что я должен был сделать, если бы определил? Спрятаться от них? Очень быстро перебежать через дорогу? Все что я знал - это чтобы перейти дорогу я должен повторить правильные слова. Позже анализируя я понял, что слова детского заклятия были руководством пользователя по пересечению проезжей части.В начале 60-х из исследований стало понятно, что зубрежка бордюрной считалочки работает плохо. Сейчас считается, что дети, заучивая через многократное записывание, (привет, заставка от Симпсонов) не всегда понимают смысл, и что, еще хуже, дети младше девяти не различают бордюр от сточной канавы или разницу право и лево - joemoran.net

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

Посещение Комитета по изменениям (change advisory board, CAB)

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

Что нужно делать на встрече CAB, что инициатор изменения не может сам сделать без CAB?

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

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

Дословно change advisory board (CAB) - консультационный совет по изменениям, т.е. название содержит намек на совещательный его фокус, а не решающий.

Решение инцидентов

Я видел практически одно и тоже во многих службах техподдержки. Сотрудники, получив сценарии, четко им следуют, считая, что должны давать ответы из этих сценариев без учёта особенностей конкретной ситуации, а также искренне уверены, что все ими сказанное нужно фиксировать в в истрии решения инцидента нужно. Сотрудники техподдержки особенно четко следуют сценариям решений, если в них написано, что нужно перезагрузить компьютер, даже если очевидно, что это не поможет решить текущую проблему. Хуже всего, что это раздражает и разочаровывает пользователей в оценке возможностей техподдержки, и усложняет общение при следующих обращениях пользователей. Обеспечивать сотрудников техподдержки рекомендациями и чек-листами для общения с пользователями - это важно и нужно, но это не заменяет обучение сотрудников думать, что они говорят, а затем ожидать от них, чтобы они говорили правильные вещи.

Даже хирургам нужны чек-листы

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

Исследование показало, что использование простых хирургических чек-листов в течение важных операций помогает избегать в более, чем 40% смертей, и осложнений в более чем трети случаев - BBC.

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

Так что это все может означать для ITSM?

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

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

Улучшать инструменты, используемые персоналом для работы. Помогать сотрудникам создавать простые чек-листы и процессы, чтобы быть уверенным, что они будут правильно выполнять работу И ЗАТЕМ доверять сотрудникам.

Заключение

Если ваши ITSM процессы объемны и сложны, это мешает вашим сотрудникам эффективно работать, и, возможно, пора их пересматривать и упрощать. Может казаться, что самый простой путь реализации этого придумать более простые чек-листы и процессы, а затем заставить всех ими пользоваться. Но если так сделаете, то можете к своему удивлению обнаружить удручающий результаты, как те взрослые, которые учили меня бордюрной считалочке. Новую культуру не удастся насадить, а вот вовлечение людей в разработку простых процессов, сработает гораздо лучше и может запустить культурные изменения. И все это может вызвать гигантские изменения в удовлетворенности и заказчиков, сотрудников, а также может дать возможность классно делать свою работу. Попробуйте дать сотрудникам возможность воспользоваться их навыками, знаниями, инструментами и верой в то, что они нужны для того, чтобы делать классную работу? И вы можете быть поражены, как успешно они решат задачу.

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

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

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

При запуске процесса управления знаниями, я бы рекомендовал, сконцентрироваться на краткосрочных результатах, чтобы именно в краткосрочной перспективе получить ценность. Не стоит сразу начинать с всеобъемлющих программ, получение ценности от которых займет у Вас годы. То что Вы думаете о масштабном всеобъемлющем результат - это хорошо, но не стоит забывать и возврате вкладываемых в это ресурсов. А этого можно добиться именно разбиением крупного проекта на шаги измеряемым ROI.

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

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

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

• база известных ошибок интегрированная с системой обработки заявок

• репозиторий документов (например, SharePoint)

• очное или онлайн обучение

• вебинары, подкасты, видео на YouTube и другие медиа ресурсы

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

• наставничество и коучинг

• наличие экспертов в предметных областях, которые способны помочь сотрудникам найти требуемые знания

• новостные рассылки, электронная почта и другие каналы массовых коммуникаций

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

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

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

Ссылки на другие статьи Стюарт Рейнса:

• Как определить метрики для процесса Управления изменениями (перевод, оригинал)

• Как определить метрики для процесса Управления проблемами (перевод, оригинал)

• Как определить метрики для процесса Управления инцидентами (перевод, оригинал)

• Сбалансированная система показателей для ключевых показателей IT (перевод, оригинал)

• Как определить метрики для техподдержки (перевод, оригинал)

• Осторожно. Как использовать метрики процессов без вреда для здоровья процессов (перевод, оригинал)

• ITSM ликбез: 7 способов диагностики причин IT инцидентов и проблем (перевод, оригинал)

• ITSM ликбез: Как соответствовать ожиданиям заказчика (перевод, оригинал)

• Прошлое и будущее Управления ИТ Услугами (ITSM) (перевод, оригинал)

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

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

Просто представьте, что у Вас сотня админов, которых Вы ежедневно обеспечиваете работой (это не выдумка, а реальность).

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

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

Можно ли с этим что-то сделать? Конечно! Работающие и очень эффективные меры давно известны это Бережливое производство (Lean Manufacturing) и Теория ограничений (Theory of Constraints, TOC).

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

Небольшой экскурс в Lean и TOC

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

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

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

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

А вот увеличение производительности горлышка на X% приведет к увеличению прибыли всего предприятия на X%. А это миллионы, а может и миллиарды!

Это если кратко.

Единственная, но очень важная метрика теории ограничений

В Теории ограничений есть, по сути, единственная метрика, на основе которой принимаются все решения это Проход (или Проток, Throughput).

T_u=P TVC,

где T_u величина прохода на единицу продукции;
P цена единицы продукции;
TVC полностью переменные затраты

(https://tocpeople.com/2012/08/upravlenie-predpriyatiem-po-finansovym-pokazatelyam-tos/)

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

Как это можно использовать?

Давайте рассмотрим известный пример с двумя продуктами. Пусть человек-бутылочное горлышко принимает участие в производстве продуктов А и Б.

Продукт А стоит 300 руб, а продукт Б 400 руб.

При этом Проход (грубо - Прибыль) продукта А = 100 руб, а у продукта Б = 200 руб

Какие продукты и в каком количестве должен производить человек-бутылочное горлышко, чтобы максимизировать прибыль предприятия (а мы знаем, что именно он определяет всю прибыль предприятия)?

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

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

Время производства продукта А 5 мин, продукта Б 30 мин.

Продукт А: 100 руб / 5 мин = 20 руб / мин

Продукт Б: 200 руб / 30 мин = 6,6 руб / мин

Получается, что при изготовлении продукта А компания получает прибыль в 20 руб/мин, а при изготовлении продукта Б всего 6,6 руб/мин.

Выбор очевиден, не правда ли? Нужно производить как можно больше продукта А, а в оставшееся время продукт Б.

Переложение метрики Прохода для технической поддержки

Самое главное сомнение, которое у Вас скорее всего возникнет в тех поддержке нет прибыли. Совершенно верно.

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

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

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

Из Jira, например, можно извлечь следующие данные:

Приоритетзадачи

Категория задачи

Общее время исполнения(от регистрации до перевода в статус Resolved) с учетом всех дней и выходных. Время исполнения с точки зрения клиента от самого начала до самого конца.

Дополнительно можно вычислить Touch time - время ручной работы админа по каждой задаче. Другими словами время, затраченное администратором на задачу за вычетом выходных, нерабочего времени и нахождения задачи в статусе Need Info (запрос доп информации от клиента).

Если на человеке висело несколько параллельных задач, то Touch time вычисляется по каждой завершенной задаче отдельно, а затем берется 85% персентиль от всего полученного множества.

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

В Jira значение Touch time можно вычислить как время между сменами статусов.

Время работы человека-горлышка (или время, затраченное на производства продукта) = Touch time

Проход = количество выполненных задач конкретной категории и приоритета

К прохода = Прибыль / Время работы горлышка

или

К прохода = количество выполненных горлышком задач / Touch time

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

Вот реальный пример из службы тех поддержки:

Колонка template Категория задач. Строки упорядочены по убыванию коэффициента прохода.

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

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

Почитайте интересную статью про технологию Swarming в которой есть много подобных нестандартных выводов.

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

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

Поиск бутылочного горлышка техподдержки

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

Если просуммировать время создания ценности и соотнести его с общим временем цикла, то можно посчитать эффективность потока:

Эффективность потока = Суммарное время создания ценности / Общее время цикла * 100%

Часто эффективность потока в компаниях не превышает 5-10%.

Каким образом посчитать эффективность потока для задач тех поддержки?

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

Можно использовать метод проще и считать по количеству выполненных задач за период:

Эффективность потока = Кол-во выполненных задач / (Всего задач в работе) * 100%

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

Вот примеры с реальными данными:

Можно отфильтровать данные по наименее эффективным группам и получить эффективность входящих в них админов.

Что обозначает эффективность потока в тех поддержке?

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

Вот пример реальной ситуации по настоящему, не выдуманному админу:

Как видите, ситуация жесткая он делает всего 4-5 задач в день, а вешают на него аж по 10 штук.

Естественно, о какой эффективности тут может идти речь.

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

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

А если посчитать Touch time и коэффициент прохода, то можно еще и расставить приоритеты исполнения обращений, приходящих в бутылочное горлышко.

Т.е. метрики бережливого производства действительно могут помочь с налаживанием дел в технической поддержки.

Что делать со всеми этими метриками?

Улучшать, конечно. С помощью Kaizen непрерывного совершенствования. В низкой эффективность виноваты не люди виновата система. И её надо перестраивать.

Т.е. нужно находить корневую причину проблемы (истинную причину, а не лежащую на поверхности) и устранять её. И так поступать с каждой проблемой.

Вот хороший пример как в Службе Service Desk использовали Lean (бережливый подход) и что из этого получилось.

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

Зуб даю, что первое, что Вы увидите в тех поддержке - это то, что админы (/сотрудники тех поддержки) делают по десятку задач одновременно (см. график выше). Вы наверняка на себе испытали как это работает:

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

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

А почему у админа много задач? Корневой причиной является распространенная ложная установка. Руководство считает, что ресурсы надо утилизировать на 100%, чтобы они не простаивали. Поэтому и загружает админа задачами. Но на самом деле это заблуждение, вызывающее огромные проблемы.

При однозадачности задачи выполняются в разы быстрее, чем при многозадачности:

Решить проблему можно. Теория ограничений для этого случая говорит:

Расширьте бутылочное горлышко

Подчините ему всё производство

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

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

Вариантов решений множество.

Помните, что этот админ-бутылочное горлышко, по сути, является первопричиной того, с какой скоростью и качеством Ваша служба технической поддержки обрабатывает запросы. Думайте в числах прохода. Если найм или выделение помощника этому админу увеличит проход в 5 или 10 раз, разве это не стоит того?

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

А на этом всё.

NB. Все выводы в этой статье сделаны на основе наблюдений за реальным отделом технической поддержки большой компании.

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

Ваши комментарии он с удовольствием прочитает и ответит на них.

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

Конечно, в заголовке я немного слукавила: я не простой клиент, а клиент избалованный автоматизацией и сервисом, а ещё бывший инженер по тестированию, маркетолог и пиарщик. Худший покупатель, в общем. Автоматизацию я полюбила, работая на протяжении 8 лет с RegionSoft CRM, любовь к сервису пришла оттуда же. Интерес к доставкам появился тоже не случайно после того, как компания стала развивать и внедрять сервис для отслеживания удалённых сотрудников на местности RegionSoft GeoMonitor, сразу возникла потребность понять физиологию курьерского дела.

Итак, проанализируем службы доставки на примере нескольких крупных провайдеров и кое-кого ещё. Место действия Нижний Новгород.

• Сбермаркет сервис, который доставляет продукты и товары из Ленты, Метро, Ашана и огромного количества магазинов в Москве, в Нижнем Новгороде только из Ленты, Метро, Ашана, Окей. Вышли на рынок региона довольно тихо, но активно распространялись по сарафанному радио. 5 заказов.

• Впрок (Перекрёсток) собственная доставка сети магазинов Перекрёсток. На удивление лучше, чем сами магазины (субъективно). У меня Перекрёсток в 400 метрах от дома, но после рекламы в Редакции А. Пивоварова (где ведущий вещал со склада) и скидки на первый заказ странно было не попробовать. Результат: уже 13 заказов.

• Яндекс.Лавка (+ Яндекс.Доставка) быстрый сервис доставки базовых продуктов и товаров. Не для запасов, а для покупки того, чего прямо сейчас не хватает дома или в холодильнике. 51 заказ.

• Самокат сервис с даркстором в радиусе 1,5 км. На самом деле, хороший сервис доставки продуктов с нормальным ассортиментом. Удобно, что ассортимент у них и Лавки отличается. С недавнего времени появился Самокат Супермаркет для закупки больших заказов с периодом доставки 1,5 часа. 30 заказов.

• Ozon Озон есть Озон. За последний год 26 заказов.

• Wildberries маркетплейс со множеством товаров и довольно странной маркетинговой политикой. 34 заказа за год, но большинство это маски, респираторы и санитайзеры они там появились раньше всех и стремительно дешевели.

• Курьерские доставки СДЭК, Почта России через них присылают товары различные интернет-магазины, организации и т.д.

• Яндекс.Еда, Delivery Club сервисы доставки еды.

• Локальные магазинчики с доставкой (в основном, не еда, а одежда, аксессуары, посуда и т.д.)

• Аутсайдеры для примера: Ленточка и SPAR Online собственный сервис доставки гипермаркетов Лента (1 отменённый заказ) и доставка SPAR Online (1 заказ).

Фишки доставки

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

• Главная фишка удобство заказа и оплаты: удобные каталоги, любые формы платежей, у курьеров и чековый терминал, и платёжный терминал, и возможность корректировки стоимости заказа (если, например, в заказе есть весовой товар). Не нужно нервничать и искать наличку или переживать, что ошиблась и не выбрала оплату заказа онлайн курьер спокойно принимает платёж (но есть нюанс если сбоит сотовая связь и Wi-Fi, могут быть проблемы и зависания оплаты, это нужно учитывать, оформляя заказ, например, в дачный посёлок с плохим покрытием).

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

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

• У Сбермаркета сборщик на связи с клиентом он звонит не только сообщить, что чего-то нет в наличии и предложить замену, но и сообщает сроки годности и обсуждает состояние фруктов. Кстати, их же сборщики могут по личной просьбе найти на полках и добавить в заказ то, чего не было в каталоге особенно это было актуально для заказа из Метро. При этом он не спешит, уточняет, перезванивает. То ли дело Ленточка единственный раз, когда я с ними связалась, сборщик довольно грубо и прямолинейно сообщил, что у него регламентировано время на работу с каждым клиентом и он не пойдёт заменять товар, а просто не положит его в заказ (к слову, заказ я отменила и больше к ним не вернулась).

Яндекс.Лавка дарксторная доставка, не похожая ни на какую другую. Они унаследовали технологичность Яндекса и подходы Яндекс.Еды (а потом и её курьеров). Лавка пришла в Нижний Новгрод довольно громко: их анонсировал в инстаграме губернатор, о них говорили, да к тому же на старте были скидки 10% на весь ассортимент: например, мороженое было рублей на 15-25 дешевле, чем в Пятёрочке. По субъективным впечатлениям, сервис рос очень быстро.

• Удобное приложение: группы товаров, заказанные ранее товары, интерфейсы оплаты, чат с поддержкой всё в одном окне. Приложение за год значительно изменилось, и очевидно, что этот процесс был не просто игрой в перекладывание ярлычков, а рефакторингом на основе пользовательского опыта. Стало удобнее.

• Идеальная поддержка: за любой косяк с фото сразу возвращали деньги за продукт и давали купоны на скидку (чаще 10%, за крупный промах (просрочку) был 20%), оперативно реагировали и при упоминании в Facebook. Конечно, это стимулировало ещё больший заказ. Был даже случай, когда из-за недостатка курьеров не могли доставить заказ и отклонили его, так бонусом была вся сумма этого заказа (около 1200 рублей).

• Скорость доставки WOW (ну, справедливости ради, я живу в центре города и недалеко от их распределительной точки).

• Вежливые курьеры в СИЗ-ах и гарантированно бесконтактная доставка.

• Удобная система оплаты чаевых.

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

• Ах да, кэшбек. Если вы подключены к Яндекс.Плюс, то с заказов в Лавке часто прилетают бонусы, ими же можно и рассчитываться, получив их в других сервисах. Экосистема, короче (кстати, раз зашла о ней речь, скажу, что оплата бонусами в такси не прошла таксист, сказал, это проблема на стороне сервиса, я жаловаться и выяснять поленилась).

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

Про Яндекс.Еду я не буду ничего говорить, они в городе давно, я ими пользовалась раз 7-8 за без малого три года, нареканий не было, маршрутизация с проблемами и вопросами чёткая (была проблема с тем, что перепутали заказы и мне вместо моего маленького отдали чужой огромный).

А вот про Яндекс.Доставку я скажу и здесь, и в минусах, потому что мне она показалась самой нестабильной частью экосистемы. Казалось бы, то же самое такси, с которым всё давно отлажено и ясно, но нет. Пока о плюсах: конечно, это супер удобная экспресс-доставка по городу. Раньше передать подружке букет и подарок, вывезти свои вещи из офиса, перевезти пару кресел к пожилым родственникам или отправить знакомому лекарства было задачей не из простых либо делаешь всё сама, либо пользуешься пакетными решениями доставок, среди которых много неудачных по сервису и качеству (особенно по части сладостей, цветов и сувениров) или цене (грузоперевозки просто новое Эльдорадо). За время самоизоляции сервис выручал и меня, и знакомых относительно меня. Как правило, все курьеры были быстрыми, бережными и даже не ругались, если их просили довезти пакет с чем-то важным всего лишь через 400 метров (был и такой случай, чисто ради сюрприза). Цены при этом таксишные и выше.

Самокат пришёл в город значительно (для масштабов 2020) позже, чем Лавка, и выходил на рынок довольно лениво. Но опять же, я живу недалеко от их распределительного центра и вижу, что розовых колёсных курьеров ощутимо заметно на улицах. Самокат, как и Лавка, предлагает ассортимент продукции под своей маркой (гораздо дороже, но и заметно интереснее) и довольно разнообразен в позициях. Курьеры чуть менее вежливы, чем яндексовые, но и быстрее обычно минут 10-15, редко 30.

Обе доставки относительно давно изменили график возможности совершить заказ до 22:00 и даже 23:00, и это прекрасно во многих ситуациях. Несколько раз буквально выручало.

От еды перейдём к вещам насущным.

Как же похорошел Озон при коронавирусе! Я серьёзно: он ощутимо расширился, стал доставлять товары из-за рубежа, расширил маркетплейсы для отдельных брендов и продавцов. Я видела, сколько проблем OZON огребал из-за этих изменений (чего стоила возможность жаловаться на неадекватные цены на хлоргексидин (400 р. против аптечных 35-45 р.), маски и санитайзеры и разборки с грубящими на жалобы продавцами), но, кажется, это сделало его сильнее, хотя, конечно, товары с неадекватными ценами по-прежнему встречаются. Я с Озоном с 2009 года и совершила там сотни покупок, поэтому пользуюсь и Премиумом, и Ozon Card, бонусная система и скидки по подписке для меня оказались выгодными. Этот маркетинг лично меня втянул и теперь Ozon приоритетный для меня книжный, дачный, ремонтный и проч. (кроме сложной техники). И это тоже показатель: маркетологи сделали лояльным стреляного рекламщика, маркетолога, пиарщика честь им и хвала (только смайлики в рассылках ну очень раздражают).

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

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

Теперь о локальных магазинчиках с доставкой А о них не будет. О них в недостатках. Увы.

Недостатки доставок

Общие минусы

• В приложениях разных продуктовых доставок царит чехарда с доступностью продуктов и товаров для заказа. В приложении Впрок сразу видно, есть товар на складе или нет корректировки если и случаются, то только с весовым товаром. В Сбермаркете есть расхождение замены и отказы получаются почти при каждом заказе. В Лавке и Самокате также сразу понятно, есть товар или нет, но потом продукты могут исчезнуть из корзины, если кто-то успел заказать последние, пока ты формировал заказ я понимаю принцип, но с точки зрения покупателя это странно.

• Время доставки у всех длинных сервисов очень растяжимое понятие. Интервалы вроде с 10 до 18 это день в привязке к дому. Если бы было отслеживание статуса приближения курьера к дому, было бы идеально: можно было бы сопоставить со своим графиком дел и выхода из дома. Бывает, что не соблюдается даже выбранный интервал (справедливости ради, в основном, из-за пробок, аварий, снегопадов и других форс-мажоров).

• Курьерам и сборщикам в общем и целом наплевать на сохранность товаров и их вида. И если Впрок и Сбермаркет продумали крутые пластиковые контейнеры, а OZON коробки (много и разных, да ещё с набивкой из бумаги и плёнки с пупырышками), то остальным, включая крупных операторов, до фени, что будет с вашей коробкой или пакетом. Я видела и порванные упаковки, и ужасно грязные, пыльные верхние слои защиты, и разбитые яйца, и т.д.

• Кстати, о яйцах, а точнее о товарном соседстве. Жёстко его соблюдают только Впрок и Сбермаркет (у них всё по категориям в пакетах, замороженное в термосумках, которые забирают), а у остальных всё зависит от укладчика: бывает очень классно и добросовестно, а бывает яйца, мороженое, хлеб и курица приходят в одном пакете и, если одно яйцо решит разбиться, весь пакет и все продукты будут в нём.

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

• Недовольство курьеров при отключённом лифте. Я старалась не делать крупные (да и никакие) заказы, когда знала, что лифт не работает. Но за год он ломался и некоторые заказы попадали на такую ситуацию, о которой я не знала. Удивило, что громче всех возмущался представитель курьерской службы, который привёз 3 листочка документов, а самыми позитивными оказались доставщики OZON и Wildberries, хотя одному из них пришлось тащить на 7 этаж 24 кг посылки (чаевые не взял).

• Непонятные функции чаевых: если у сервисов Яндекса всё чётко и чаевые можно оставить всегда, то у остальных ситуации очень странные. Самокат подключил чаевые спустя время через внешний сервис, курьеры OZON и Wildberries ни за что не берут деньги, а доставщик СДЭК, который кроме прочего ещё и помог с занесением тяжестей к месту их нахождения в квартире, заявил, что его вообще за такое оштрафовать могут и некоторые предлагают, а потом жалуются (жуть же!).

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

Частные минусы

• Яндекс.Лавка, на мой взгляд, перегружает курьеров, и я им об этом писала. Изначально, когда Лавка только пришла в город, абсолютно все заказы развозили курьеры на автомобилях. Это было здорово и удобно: с бесплатной доставкой можно было заказать муку, 10 бутылок минералки, гору молочки и т.д. Машина 9 ступенек лифт, а вот и получатель. Когда очередной мой заказ на 20+ кг принёс парень с термосумкой и без транспорта, я, кажется, достала службу поддержки, потому что никакие мои чаевые не компенсируют угрозу здоровью молодого (и, кстати, обычно ещё растущего) организма. Это здорово демотивировало делать объёмные заказы, и я перешла на услуги Впрок, а Лавку оставила для для салата яиц не хватило и прочих срочных мини-заявок. Правда, потом заметила по себе и соседям, что заказы стали справедливо распределять между пешими курьерами, курьерами на мото/вело и на авто, что однозначно логично.

• Яндекс.Лавка изменяет стоимость доставки в зависимости от погоды и загруженности курьеров (как и в Еде, и в Такси). И если в Еде и Такси это очевидно, то в Лавке всегда становится сюрпризом. То есть базовые условия 0 рублей от 200 рублей заказа, а тут дорожает + порог заказа с бесплатной доставкой сильно растёт (в несколько раз). Это максимально справедливо по отношению к труду курьеров, просто первые разы не хватило возможности предусмотреть такую ситуацию со стороны клиента.

• Курьер Яндекс.Доставки не хотел подниматься на этаж и даже подъезжать к дому из-за сугробов, грубил и отказывался закрыть заказ со своей стороны (там и так наценка за погоду была нехилая), в то время как его коллега приехал, встал сбоку от дома, дошёл по сугробам до подъезда, идеально выполнил срочный и важный заказ на доставку пакета и получил чаевые. И таких инцидентов и мелочей за год доставок было много: грубость курьеров, раздражение, отсутствие СИЗ Я знаю, что компании практически не могут на это повлиять, но ведь у Сбера и Перекрёстка получилось, значит, должно получаться. Сервисы доставки должны прежде всего остального понимать, что лица курьеров и их отношение это и есть лицо компании в глазах клиента. Никто не станет разбираться, почему компания А предоставила компании Б таких сотрудников просто скажут: Давеча в Яндексе заказывала, так быстро привезли и курьер такой аккуратный, на сумку заказ положил, отошёл. Видите, не Еда, не Лавка, а Яндекс и этот парень лицо Яндекса, Перекрёстка, Озона, Сбера и его партнёров и т.д. Наверное, это самый сложный пласт работы с человеческим фактором.

• Wildberries приносит заказы по частям, иногда ну очень мелким и в разные дни и ты сильно привязан к дате и времени или вынужден просить курьера приехать позже или в другой день. Я пыталась общаться об этом с компанией, но ответ был так себе: всем удобно, а ты сиди недовольная. В противоположность им OZON даёт возможность изменить дату заказа, выбрать единую дату для частей и т.д. Ну и поддержка Озона (сильно и хорошо роботизированная) работает не в пример лучше несчастной Евы Вайлет в социальных сетях фиолетового конкурента.

• Яндекс.Лавка и Самокат выбирают очень странных поставщиков готовой еды, выпечки, кондитерской продукции: например, я как горожанин доверяю лишь одному изготовителю из предложенных. Но вообще интересно узнать долю заказов готовой еды именно в этих сервисах какой смысл, когда есть Яндекс.Еда и Delivery с гарантированно проверенными местами, и это не считая локальные доставки из городских кафе, ресторанов и сетевых общепитов. Единственный заказ двух наименований готовой еды оказался на 100% неудачным и был отправлен в мусор в полном составе. Но это дело вкуса.

Теперь о локальных магазинчиках с доставкой. Я работаю удалённо из дома, долго была в жёсткой самоизоляции и иногда хотелось купить что-то для души: пару статуэток в коллекцию, кое-что из эксклюзивных чаёв и прочих милых мелочей. Тех мелочей, которые небольшие, но довольно дорогие. Было 4 заказа и из них только один не взял деньги за доставку. Но особенно поразил один из них: 2 мелочи стоили 3000 рублей, я точно знаю, что наценка минимум 30%. Доставляли Яндекс.Доставкой и попросили компенсировать что-то около 200 рублей не вопрос, но как же это смазало впечатление! Но всех победил магазин, который потребовал 500 рублей за доставку + 100 рублей, если до подъезда и ещё какие-то условия, если до квартиры (стоимость заказа около 7000 рублей, вес не больше 7 кг) в общем, отказалась от их услуг из-за этого неуёмного коммерческого бюрократизма.

И так сойдёт?

Сейчас мы вышли на улицы и вернулись в оффлайновые магазины, которые обходят доставки по свежести, качеству фруктов и овощей, ассортименту и скидкам. Доставкам нужно развиваться, чтобы быть конкурентоспособными вне уникальных условий пандемии COVID-19. Кто-то уже вернул платность доставки и стимулирует посещать пункты выдачи, кто-то стал ощутимо хуже доставлять, кто-то поднял цены ощутимо выше магазинных. Стабильно хорошо смотрятся длинные доставки, которые привозят запас продуктов на дом или на дачу, но они и изначально были на голову выше. Остальным нужно развиваться и уже видно, что Яндекс.Лавка и Самокат это делают. Самокат работает в формате гипермаркет, Лавка постоянно расширяет ассортимент, Яндекс.Еда доставляет продукты из магазинов (включая локальные) и больших гипермаркетов.

Так каким должна быть доставка, чтобы доставлять во всех смыслах этого слова?

Идеальная доставка с точки зрения клиента

• Приложение должно быть удобным, отзывчивым, с однозначно воспринимаемым интерфейсом. Акции, бонусы, последние заказы, адреса, способы оплаты и контакты поддержки должны быть очевидны и находиться на ожидаемых пользователем местах. В приложении должно быть удобное отслеживание заказа (по возможности) пользователь должен знать более точное время прибытия курьера (как у Деливери, Яндекс.Еды, Самоката и Лавки). Дополнительной интересной возможностью могут быть оценки и отзывы на товар (лучше всего реализовано у Впрок) это позволяет покупателю быть информированным, а самому маркетплейсу управлять качеством, ассортиментом и поставщиками.

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

• Поддержка пользователей обязана быть простой, доступной и очень быстрой. У большинства участников обзора поддержка сочетает в себе роботизацию и участие живого оператора. А вот позвонить и поговорить голосом гораздо проще с небольшими местными компаниями они отвечают сразу и по делу, крупные маркетплейсы гоняют или по людям, или по IVR (который, к тому же служит в первую очередь коммерции, а не помощи клиенту). В принципе (кроме Wildberries) из всех обращений, что случались, всё заканчивалось хорошо и в пользу клиента. Самые приятные механики взаимодействия у Ozon и у сервисов Яндекса. А вот с Самокатом из приложения пообщаться не получалось приходилось переключаться на мессенджер (а потом ещё запоминать, в каком это из 5 мессенджеров я общалась с Самокатом, чтобы обратиться вновь).

• Курьеры это довольно болезненная часть работы доставок, с ними случается всякое (хотя уверена, что у них тоже сотни историй про особых клиентов). Чаще всего это быстрые, обходительные люди, которые безупречно выполняют работу, но, увы, 2-3 косяка могут испортить отношение к компании. Наверное, где-то в идеальном мире для курьеров проходит качественное обучение, их учат правилам обращения с людьми, лифтами, звонками, ручками дверей, домофонами и т.д. Но вообще это мелочи кроме пары вопиющих случаев на грани правонарушения претензий к этим ребятам нет, они своеобразные герои пандемии. Из реальных пожеланий: возможность отслеживать реальное перемещение курьера и понимать, почему в приложении он будет через 6 или 12 минут, а в реальности уже звонит в дверь.

• Ассортимент самая сложная история. Необходимо, чтобы он изменялся в зависимости от спроса, от отзывов покупателей, чтобы все продукты были с нормативным сроком годности. Обязательно должно быть полное описание продукта, вся информация о нём. Благодаря этому формируется доверие со стороны клиента, он не боится заказывать не только товары длительного хранения, но и молочку, фрукты, рыбу и т.д. Если говорить откровенно, то абсолютно никаких проблем со свежестью и качеством не было только у Впрок и Сбермаркета вероятно, это объясняется возможностями складского хранения и оптимальными условиями транспортировки заказа у гигантов. Таких оговорок быть не должно: если доставка работает с продуктами, фруктами, овощами, цветами и проч., разочарований и претензий у клиента быть не должно.

• Программы лояльности факультативная функциональность. Здесь должно работать простое правило: либо программа есть и она рабочая и понятная (бонусы, кэшбек, скидки, условия бесплатной доставки и т.д.), либо её просто нет и покупатель вас выбирает просто за отличную работу сервиса. Третьего не дано.

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

Перечитала статью и вижу, что прямо благостно написала о сервисах Яндекса, Сбермаркете, Впрок и OZON. Конечно, отчасти это привычка (в случае Яндекса и Озона), отчасти работа в техносфере я доверяю тем, кого хорошо знаю как человек из ИТ. Но в этой вроде бы субъективной оценке есть и объективные причины.

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

• Приложения не глючат, не вылетают, обеспечивают взаимодействие со всеми функциями в одном интерфейсе (кроме Озона, у него есть ещё отдельное небольшое приложение Ozon Card).

• У приложения Впрок даже сторонние библиотеки со ссылками на GitHub указаны. Приложение выглядит действительно продуманно и профессионально.

• У Впрок, Озона, Сбермаркета кроме мобильных приложений отличные web-сайты, где можно собрать заказ в удобном для себя режиме, не тыкая в случайные позиции и вдумчиво перебирая корзину. Поскольку я почти 16 часов в день нахожусь у десктопа, для меня это важная функциональность.

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

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

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

Ну а если вы только создаёте свою службу доставки, то у нас в РегионСофт есть RegionSoft CRM с возможностью управления складом, ассортиментом, дисконтными программами и т.д. и облачный сервис GeoMonitor, который позволяет отслеживать перемещение объектов (курьеров и транспорта) на местности. В этой сфере автоматизация многое определяет.

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

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

1. Персонал: поиск, обучение и работа с персоналом

2. Операционные процессы:

   1. диспетчеризация (приём и обработка клиентских обращений),

   2. выполнение заявок,

   3. закупка расходных материалов или запчастей,

   4. работа с подрядчиками,

   5. управление уровнем клиентского сервиса и сбор обратной связи,

   6. контроль перемещений сотрудников и контроль за расходом ГСМ

   7. в компаниях, обслуживающих оборудование, добавляется плановое обслуживание или выполнение регулярных (контрактных) работ (планирование и выполнение ППР)

Если говорить о первом шаге автоматизации в сервисных компаниях с выездным персоналом, то 25% компаний начинают автоматизацию с внедрения CRM системы, а 75% - автоматизируют работу по заявкам и контроль выездного персонала. И это не случайно, ведь операционка для b2b сервиса - это прежде всего ежедневная кропотливая работа с обращениями клиентов и их заявками.

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

Довольно часто руководители сервисных организаций ставят перед сервисом следующие цели:

1. снижение затрат на диспетчерскую

2. оптимизация затрат на фронт-офис персонал (сервисные специалисты)

3. снижение затрат на подрядчиков

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

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

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

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

1. Цель 1: Снижение затрат на диспетчерскую и процессы диспетчеризации

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

Прием клиентских обращений может быть автоматизированным или ручным:

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

Ручной прием обращенийэто обычно телефон, мессенджеры или почта без средств автоматизации.

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

Так, для организации работы по заявке диспетчеру требуется:

1. пообщаться с заказчиком по телефону или обработать обращение поступившее на почту / в мессенджер,

2. зарегистрировать заявку,

3. вручную классифицировать обращение,

4. рассчитать срок выполнения по SLA,

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

6. договориться с клиентом о времени визита, согласовать его с исполнителем и далее проконтролировать выполнение заявки в срок

7. После выполнения заявки - собрать с исполнителя отчет о выполненных работах и запустить процесс по оплате работ, в случае b2b сервиса и при постоплатной схеме работ

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

Автоматизация процессов диспетчерской может снизить эти расходы до 90%.

Пример: в среднем по сервисной отрасли, один диспетчер обрабатывает до 500 заявок, с учетом неравномерности их поступления. Для отказоустойчивости или приема обращений 24x7, уже требуется 3-5 диспетчеров работающих посменно. А если заявок тысячи? Количество диспетчеров растет пропорционально.

В среднем, на 20-50 мобильных (выездных) сотрудников требуется два диспетчера (даже без круглосуточной поддержки). Зарплата диспетчера сравнима с зарплатой сервисного специалиста, а значит до 10% затрат на ФОТ сервиса уходит на обслуживание процессов диспетчеризации. Это может составлять до 20% недополученной прибыли всего бизнеса.

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

Динамику каких показателей следует контролировать для минимизации затрат на диспетчеризацию клиентских обращений?

1. Доля и количество заявок, полученных по электронным каналам связи, в которых не требуется участие диспетчера при получении, регистрации и распределении заявок

2. Соотношение исполнителей и диспетчеров

3. Скорость назначения заявок на исполнителей

4. Скорость закрытия заявок

5. Среднее время в пути

6. First Time Fix Rate - доля заявок, закрытых исполнителями с первого посещения объекта

7. Доля и кол-во заявок, закрытых с нарушением срока SLA

8. Оценка от клиентов

Цель 2: Оптимизация затрат на персонал сервисной службы

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

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

Контроль каких показателей, может позволить снизить затраты на персонал и оптимизировать сервис?

1. Количество закрытых заявок на сотрудника

2. Коэффициент полезной загрузки исполнителей

3. Отношение количества офисных сотрудников к мобильным

4. Среднее количество выполненных заявок на человека в день

5. Рейтинг эффективности персонала

6. Объем переработок

7. Пробег автотранспорта по сотрудникам

8. Пробег автотранспорта в расчете на заявку

9. Средняя полезная загрузка сотрудника в день в часах

10. Среднее количество открытых заявок по исполнителям

11. Равномерность загрузки исполнителей по дням недели/месяца

12. Суммарное время выполнения работ по исполнителям

13. Доля и количество заявок, выполненных с просрочкой

14. Доля и количество повторных выездов

15. В RCM контрактах - MTBF (среднее время между отказами оборудования), MTTR (среднее время на устранение неисправности), % оборудования, по которому были заявки

16. % выполнения плановых (профилактических) работ

17. Наличие наиболее используемых материалов/запчастей на складе и у исполнителя в начале смены

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

Цель 3: Снижение затрат на подрядчиков

Для системной работы с подрядчиками, необходимо выстроить автоматизированный процесс работы с ними и установить точки контроля их работы. Существует 2 основных способа снижать затраты на подрядчиков: уменьшать стоимость контрактов, снижая объем или стоимость работ, либо увеличивать строгость SLA и штрафовать при его нарушении. В обоих случаях необходимо четко регламентировать процесс работы подрядчиков и контролировать не только уровень сервиса, но и его объем.

Контроль каких показателей, поможет снизить затраты на подрядчиков?

1. уровень сервиса (соблюдения SLA)

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

3. фиксация факта присутствия на объекте при закрытии заявки

4. указание выполненных работ и фиксация объекта ремонта

5. контроль количества повторных ремонтов

6. В RCM контрактах - MTBF (среднее время между отказами обслуживаемого оборудования), MTTR (среднее время на устранение неисправности), % оборудования по которому были заявки

7. общее количество выполненных заявок

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

9. скорость решения проблем

10. простои оборудования

11. рейтинг исполнителей подрядчика

12. рейтинги и сравнительная оценка уровня сервиса различных подрядчиков

13. количество заявок на согласовании у заказчика

14. время поставки запчастей

15. оборачиваемость запчастей и актуальная матрица запчастей

16. среднее время приема заявки подрядчиком в работу

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

Цель 4: Снижение затрат на административные функции и бэкофис.

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

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

Тут правильнее перечислить процессы, оптимизация которых снижает затраты на административные функции:

1. Оптимизация первичного документооборота: переход на электронные первичные сервисные акты вместо бумажных

2. Переход на ЭДО по юридически значимым документам (бухгалтерские акты, СФ, договора и т.д.)

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

4. Внедрения систем систем электронного архива как входящих, так иисходящих документов с QR-кодированием и хранением всех бухгалтерских документов в компании в электронном виде

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

6. Электронные авансовые отчеты сотрудников по купленным в магазинах запчастям и расходным материалам

7. Автоматизированный GPS-контроль перемещения персонала и автотранспорта

8. Автоматизация планирования маршрутов по заявкам

9. Оптимизация матрицы запчастей и управление товарным запасом

10. Электронный склад запчастей в смартфоне мобильного сотрудника с поиском требуемых запчастей

11. Стандартизация стандартных или плановых работ через чек-листы или карты операций

12. Онбординг и обучение персонала через электронные помощники в смартфоне

Как правильно ставить цели в сервисной компании?

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

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

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

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

1. Определить верхнеуровневые стратегические цели (финансовые / клиентские (рынок) / процессные или цели, связанные с персоналом)

2. Декомпозировать цели до уровня отдела или функций в компании

3. Определить показатели, контроль и изменение которых позволит, в среднесрочной перспективе, достигнуть поставленных целей

4. Решить задачи по регулярному расчету и оценки выбранных показателей (показатели следует рассчитывать и оценивать не реже 1 раза в месяц. Нижнеуровневые - понедельно или даже ежедневно).

Тут часто встает вопрос о необходимости внедрения какого-либо ИТ-решения, позволяющего

• оцифровывать текущие сервисные процессы,

• измерять требуемые показатели

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

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

Для оцифровки сервисного бизнеса с выездным персоналом лучше всего подходят решения класса FSM (Field Service Management). В России этот класс систем представлен решением HubEx (мы - разработчики платформы HubEx FSM). Так что если при прочтении остались вопросы - спрашивайте в комментариях. И удачи в цифровизации в своих компаниях!

Одни из самых интересных задач в работе администратора приложений, на мой взгляд, это осуществление миграции данных при переходе на новую систему. Сегодня я хочу поделится собственным опытом переноса данных с не очень известной helpdesk системы VisionFlow в более известную систему ServiceNow.

Что хотел заказчик

• Перенести все данные из VisionFlow в ServiceNow с сохранением даты регистрации / закрытия тикетов

• Перенести всю историю переписки по каждому тикету (достаточно было объединить все комментарии в один тред, но мы пошли чуть дальше)

• Перенести все прикреплённые к тикетам файлы

Что мы имели

• Серверную версию Helpdesk системы VisionFlow развёрнутую на виртуальной линукс машине с БД MySQL для хранения данных.

• ServiceNow инстанс, с подготовленной заранее таблицей для заказчика.

  На данном этапе были обговорены все нюансы, такие как:

• Статусная модель

• Требуемые поля

• Логика автоматического назначения тикетов на исполнителя

• Данные требующие переноса

Перенос данных

ServiceNow позволяет использовать excel файлы в качестве ресурса для импорта данных. Не буду подробно расписывать процесс импорта данных в систему (процесс неплохо описан в документации к продукту), но в общих чертах он выглядит так:

Так как было решено использовать xlsx файл в качестве источника данных, файл требовалось подготовить. Требуемые данные VisionFlow хранит в разных таблицах своей базы данных. Для получения данных был написан запрос к БД:

SELECTprojectissue.projectIssueId,projectissue.ticketId as 'Number',    reporter.email as 'Reporter',    projectissue.name as 'Short Description',    projectissue.Description as 'Description',    projectissue.companycustomfield15 as 'Product',    projectissue.companycustomfield13 as 'Document',    issuestatus.name as 'Status',    assignee.name as 'Assignee',    ADDTIME(projectissue.CreateDate, '-01:00') as 'Created',    ADDTIME(projectissue.completionDate, '-01:00') as 'Closed',    issuehistory.EventText as 'Comment',    author.name as 'commentAuthor'FROMprojectissueINNER JOIN issuestatus    ON projectissue.IssueStatusId = issuestatus.IssueStatusIdINNER JOIN systemuser assigneeON projectissue.ResponsibleSystemUserId = assignee.SystemUserIdINNER JOIN systemuser reporterON projectissue.CreatedBySystemUserId = reporter.SystemUserIdINNER JOIN issuehistory ONissuehistory.ProjectIssueId = projectissue.ProjectIssueIdINNER JOIN systemuser author ON issuehistory.SystemUserId = author.SystemUserIdWHEREprojectissue.ProjectId = 54 AND (issuehistory.IssueEventTypeId = 5 OR issuehistory.IssueEventTypeId = 10 OR issuehistory.IssueEventTypeId = 2)    #projectissue.ProjectId = 54ORDER BY projectissue.TicketId ASC, issuehistory.EventDate ASC

Выполнение запроса позволило нам получить данные по всем тикетам из определённого проекта, включая историю комментариев по каждому отдельному элементу, с сохранением авторства и даты добавления. Вторым шагом данные были выгружены в JSON и залиты в Excel документ. После загрузки документа в ServiceNow в качестве Data Source была проведена обработка записей и создание / обновление тикетов в системе.

Результат: В системе ServiceNow зарегистрированы все записи из VisionFlow, включая дату открытия и закрытия тикетов, комментариев (и их авторов) с соблюдением исходного порядка и всех ключевых полей. Т.к. таблица на момент переноса была пуста, проблем с подменой даты создания тикетов не возникло (ничего такого, чтобы могло повлиять на нумерацию).

Перенос вложений

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

Выполняем запрос к БД для получения всех данных по вложениям переносимого проекта:

SELECT document.documentId,document.name,    document.FullPath,SUBSTRING_INDEX(SUBSTRING_INDEX(document.FullPath, '/', -2), '/', 1) as 'projectIssueId',    projectissue.ticketId as 'Number' FROM visionflow.document INNER JOIN projectissue ON projectissue.ProjectIssueId = SUBSTRING_INDEX(SUBSTRING_INDEX(document.FullPath, '/', -2), '/', 1) WHERE document.FullPath like '%/54/issuedocuments/%'ORDER BY projectissueid

Данный запрос позволил нам получить информацию о том, как и где VisionFlow хранит вложения. К нашему счастью, оказалось, что VF создаёт отдельную папку для каждого проекта, в которой создаёт набор папок для тикетов, в которых вложения присутствуют. Папки имеют в качестве названия issueId, позволяющее однозначно идентифицировать принадлежность к тикету. Собственно, запрос выше позволят нам получить наименование папки, в которой лежит вложение и TicketId (его мы использовали для переноса данных в ServiceNow).

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

Для добавления вложений в ServiceNow было решено использовать API attachments. Для этого на стороне SN был создан endpoint для получения временного токена с доступами к нужной таблице.

ServiceNow предоставляет code samples для их API. По документации мы видим, что нам потребуются следующие параметры для нашего запроса:

file_name (Required) - имя добавляемого файла

table_name (Required) - имя таблицы, в которой запись хранится

table_sys_id (Required) - ID записи, в которую требуется добавить вложение

Content-Type (Header) - mime type передаваемого контента

Как мы видим, вложение имеет связку с sys_id записи, к которой он принадлежит ( как и в VisionFlow). Следовательно, нам достаточно переименовать папки, которые мы загрузили из VisionFlow в sys_id записей, к которым мы будем их крепить. Для этого был выгружен список sys_id + ticketId из ServiceNow + список issueId + ticketId из VisionFlow. С помощью VLOOKUP функции Excel списки были сопоставлены и создан новый список с полями:

• old_folder_name

• ticket_id

• new_folder_name

На Python был написан скрипт для переименования папок и удаления тех, в которых не было найдено файлов (прогрессбар в данном случае был добавлен только для тренировки):

import pandas as pd, os from tqdm import tqdmdef renameFolders():    df = pd.read_csv('/Downloads/folder_rename.csv')    pbar = tqdm(total=len(df))    for _ , row in df.iterrows():        old_name = row['old_folder_name']        new_name = row['new_folder_name']        try:            os.rename(f'/Downloads/home/tomcat/vflowdocs/54/issuedocuments/{old_name}', f'/Downloads/home/tomcat/vflowdocs/54/issuedocuments/{new_name}')            pbar.update(1)        except:            pbar.update(1)def removeEmptyFolders():    folder_list = os.listdir('/Downloads/home/tomcat/vflowdocs/54/issuedocuments/')    for folder in folder_list:        path = f'/Downloads/home/tomcat/vflowdocs/54/issuedocuments/{folder}'        try:            os.rmdir(path)        except:            if len(os.path.basename(path)) < 6 and os.path.basename(path) != 'nan':                print(f'ServiceNow SysId not found for item: {os.path.basename(path)}')renameFolders()removeEmptyFolders()

Не буду расписывать скрипт для заливки вложений, опишу лишь несколько моментов:

• В скрипт добавлена проверка размера вложений, для того, чтобы отсеять всё то, что имеет вес менее 3000 kb (различные иконки, картинки из подписей и другой мусор) def getSize()

• Добавлен метод для удаления дубликатов аттачей. В VisionFlow каждое повторно пересылаемое вложение создавало новый файл документа def removeDuplicates()

• Добавлена обработка файлов с mime типом None. По какой-то причине mimetypes не возвращает типы для формата *msg, *txt, *eml

• Реализован финальный лог по операциями на основе ответов от сервера

• Ну и последнее (но мне, как любителю всё смотреть визуально, не менее важное) - прогрессбар для отслеживания процесса загрузки

import os, glob, filetype, requests, mimetypesfrom tqdm import tqdmimport pandas as pddef number_of_files():    files_number = 0    folder_list = os.listdir('/Downloads/home/tomcat/vflowdocs/54/issuedocuments/')    for folder in folder_list:       files_number += len(os.listdir(f'/Downloads/home/tomcat/vflowdocs/54/issuedocuments/{folder}/'))    return files_number#Progress Barpbar = tqdm(total=1297)log_messages_status = []log_messages_filepath = []log_messages_filename = []log_messages_target = []def uploadAllFiles(folder_name):    #Variables    entire_list = glob.glob(f'/Downloads/home/tomcat/vflowdocs/54/issuedocuments/{folder_name}/*')    my_list_updated = []    #Get Files Size    def getSize(fileobject):        fileobject.seek(0,2)        size = fileobject.tell()        return size    #Upload Files    def uploadFunc(filename, sys_id, path_to_file, content_type):        url = f'https://instance.service-now.com/api/now/attachment/file?file_name={filename}&table_name=table_name&table_sys_id={sys_id}'        payload=open(path_to_file, 'rb').read()        headers = {            'Accept': 'application/json',            'Authorization': 'Bearer ',            'Content-Type': content_type,            }                    response = requests.request("POST", url, headers=headers, data=payload)        if response.status_code == 201:            #print(f'Success: {filename} was uploaded to the incident with sys_id {sys_id}')            pbar.update(1)            log_messages_status.append('Success')            log_messages_filename.append(filename)            log_messages_filepath.append(path_to_file)            log_messages_target.append(sys_id)        else:            pbar.update(1)            #print(f'Error: {filename} was not uploaded to the incident with sys_id {sys_id}')            log_messages_status.append('Error')            log_messages_filename.append(filename)            log_messages_filepath.append(path_to_file)            log_messages_target.append(sys_id)    #Remove Duplicates    def removeDuplicatesByName(list_of_elements):        list_of_elements.sort()        if len(list_of_elements) > 1:            for item in list_of_elements:                item_to_compare = item.split('.')[0]                for element in list_of_elements:                    if item_to_compare in element:                        entire_list.remove(element)                    else:                        pass            return list_of_elements        else:            return list_of_elements    my_list = removeDuplicatesByName(entire_list)    for item in my_list:        file_size = open(item, 'rb')        if getSize(file_size) > 3000:            my_list_updated.append(item)        else:            pass    for attach in my_list_updated:        kind = filetype.guess_mime(attach)        if kind != None:            uploadFunc(os.path.basename(attach), os.path.dirname(attach).split('/')[-1], attach, kind)        elif kind == None and attach.split('.')[-1] == 'txt':            uploadFunc(os.path.basename(attach), os.path.dirname(attach).split('/')[-1], attach, 'text/plain')        else:            uploadFunc(os.path.basename(attach), os.path.dirname(attach).split('/')[-1], attach, 'application/octet-stream')        def getFolders():    folder_list = os.listdir('/Downloads/home/tomcat/vflowdocs/54/issuedocuments/')    for folder in folder_list:        if folder != '.DS_Store':            uploadAllFiles(folder)            getFolders()data_to_write = pd.DataFrame({    'status': log_messages_status,    'file_name' : log_messages_filename,    'file_path' : log_messages_filepath,    'target' : log_messages_target})data_to_write.to_csv('/Downloads/results_log.csv')

Заключение

У нас было 2 пакетика.. У нас было 6000 тысяч записей к переносу (не так много, старая система работала не долго), 2000 вложений и немного времени. Процесс подготовки занял у меня около 14 часов (изучение, попытки и т.д.) неспешной работы, а процесс переноса занимает около 30 минут суммарно.

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

В конечном счёте, основная задача переезда - сделать это максимально незаметно для заказчика, что и было сделано с моей стороны.

Количество самого разного оборудования во всём мире неуклонно растет. Не последнюю роль в этом играет развитие промышленного интернета вещей (Industrial Internet of Things, IIoT) и повсеместное проникновение умных устройств: датчиков, контроллеров и т. д. Согласно прогнозам уже к концу 2020 года количество умных устройств в мире превысит 200 миллиардов. Вся эта "армия" оборудования, несмотря на возможности удаленного управления, требует профилактического и выездного обслуживания (Field Service Management, FSM).

Расскажем об основных правилах повышения эффективности выездного обслуживания. Их 7.

Что такое Field Service Management? Особенности в двух словах

Field service management или "выездное обслуживание" - это подход и практики к управлению работой выездных инженеров или техников.

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

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

Малый и средний бизнес зачастую пытается использовать для решения задач управления выездным обслуживанием CRM или системы для автоматизации внутри внутренних процессов компании (ITIL или ITSM ориентированные). Но подобные решения не покрывают значительную часть вопросов. Без специализированных инструментов здесь обойтись сложно.

Field Service в России и мире. Обзор рынка

На западе вопросу эффективного выездного обслуживания давно уделяют пристальное внимание. В США FSM - это сформировавшаяся отрасль, где основная доля принадлежит крупным компаниям. Крупному бизнесу неизбежно приходится заботиться о решении вопросов с распределением задач между исполнителями и в целом о повышении эффективности своей работы. Поэтому они в первую очередь внедряют инструменты для управления выездным сервисом. Вслед за крупным бизнесом на такие решения переходят и небольшие компании.Так, согласно исследованиям и прогнозам Allied Market Research к 2026 году рынок выездного обслуживания увеличится более чем в 3 раза до 10,81 миллиарда долларов. При этом во всем мире, согласно отчёту Mordor Intelligence, количество выездных техников уже достигло 20 миллионов.

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

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

Возможно ли российским компаниям небольшими усилиями улучшить качество выездного обслуживания? Ниже 7 советов, которые помогут!

Фиксируйте 100% обращений

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

Качество обслуживания неразрывно связано с сохранением клиентской базы. По данным Teleperformance Customer Experience Lab, клиенты на 13% лояльнее к компаниям, с техподдержкой которых у них был позитивный опыт взаимодействия. Если же опыт был негативным, лояльность клиентов может снизится на 27%.

Согласно всероссийскому исследованию интеграторов спутникового мониторинга транспорта и телематики (подробнее в записи презентации результатов), проведенного нами в этом году, почти 60% компаний утверждают, что их клиенты отказываются от продолжения сотрудничества из-за некачественного сервиса. При этом у 69,7% компаний доля выручки от сервисного обслуживания составляет от 10% до 25%.

Таким образом, если вы дорожите своей клиентской базой, позаботьтесь о том, чтобы опыт взаимодействия с вами был позитивным. Если вы еще этого не делаете, начните фиксировать все клиентские обращения. И используйте для этого специализированные Helpdesk системы, а не бумажные журналы, таблицы в Google, мессенджеры. Последние помогают стартовать, но довольно быстро исчерпывают свои преимущества и уже на масштабах 10 заявок в день становятся непригодными.

Планируйте работы и выезды умно и эффективно

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

На начальном этапе планировать выезды можно в том же Google Календаре. Однако этот инструмент ничего не знает ни про соглашение об уровне сервиса (Service Level Agreement, SLA), ни про саму обслуживаемую инфраструктуру. Главное - он не позволяет оценить реальную фактическую загрузку сотрудников. Поэтому начните использовать для распределения заявок и планирования специализированные системы или модули, встроенные в решения для автоматизации выездного обслуживания. Вот, например, как выглядит модуль планирования на месяц/неделю/день внутри Okdesk:

Сократите расходы на бензин и увеличьте продуктивность

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

Чтобы оптимизировать загрузку инженера, распределение задач лучше осуществлять с учетом двух ключевых аспектов:

• местоположение объекта заявки;

• местоположение или маршрут сотрудника.

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

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

Отслеживание местоположения сотрудников позволит компании исключить и левые выезды.

Сделайте инженеров и выездных техников на 100% мобильными

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

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

Оценивайте реальную ситуацию в бизнесе

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

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

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

В контексте FSM пунктуальность - это не просто вежливость, а характеристика оказания услуг. Если распределение заявок происходит на глаз, инженеры перегружены так, что это приводит к регулярным опозданиям, то тут уже повод задуматься об изменении собственных процессов. А если выездные техники опаздывают, даже будучи полностью свободны, это повод обсудить ситуацию персонально. В любом случае выявлять подобные проблемы и намечать пути их решения невозможно в блокноте или опираясь на субъективные ощущения.

Откажитесь от бесплатной работы

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

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

Привет, меня зовут Сергей и я отвечаю за техническую поддержку компании itsoft, так что, в этой статье речь пойдет именно про поддержку.

Поддержка это лицо компании для текущих клиентов. Однако, так ли часто мы сталкиваемся с хорошей поддержкой? Ответ, к сожалению, очевиден.

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

Что всех бесит в поддержке

Начать я решил со списка того, что меня и моих коллег (да и вас, скорее всего) бесит в поддержке:

• долгое ожидание;

• роботы;

• некомпетентность;

• ограниченное количество каналов для связи;

• письма с адреса no-reply@domain.ru;

• нельзя пожаловаться (отсутствие обратной связи).

Долгое ожидание

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

• Сейчас мы не можем ответить на звонок;

• Оператор сейчас ответит, пожалуйста, оставайтесь на линии;

• Сейчас все операторы заняты, вам ответит первый освободившийся оператор;

• Продолжать можно до бесконечности!

Мало того, что нам приходится тратить на это много времени, так еще и далеко не всегда понятно сколько придется ждать, может 5 минут, может 20.

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

Есть уникальное в своем роде решение Ричарда Брэнсона, владельца авиакомпании Virgin Atlantic, который вместо раздражающих и клишированных фраз записал на автоответчик следующее обращение:

Здравствуйте, меня зовут Ричард Брэнсон, я владелец авиакомпании Virgin Atlantic. Сейчас все операторы заняты. Это непорядок. Давайте поступим следующим образом: если через 18 секунд никто не ответит на ваш звонок, вы получите скидку 450 фунтов. Я начинаю обратный отсчет 18, 17, 16, 15

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

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

Роботы

Переходим ко второму нашему пункту, который нас бесит общение с роботами.

В своих попытках бороться с длительным ожиданием многие компании приходят к решению укомплектовать свою поддержку новыми сотрудниками:

• всевозможными чат-ботами, которые сегодня "умеют" практически все, даже пытаются учиться;

• автоматической системой распределения тикетов с ИИ и без него;

• роботом на телефоне и другими искусственными заменителями.

В редких ситуациях это действительно удобно и скорее всего эффективно, однако, чаще всего это очередная возможность серьезно взбесить своего клиента!

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

У нас даже есть забавная статистика, по которой около 5% обращений в наш онлайн-чат приходят с единственным вопросом: Это робот?. Однако, мы роботами не пользуемся и не планируем, так что, на все обращения отвечают живые сотрудники.

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

Некомпетентность

Следующий пункт, который нас бесит в поддержке некомпетентность сотрудников.

Даже длительное ожидание можно выдержать, если быть уверенным в том, что это принесет результат, однако, именно из-за некомпетентности именно его мы и не получаем.

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

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

Такие причины как низкие зарплаты, а как следствие высокая текучка и низкая квалификация кадров, попавших туда по массовому отбору понятны, а вот что непонятно почему это устраивает большинство компаний?

Пример из жизни: когда-то давно, получив в банке свою первую пластиковую карточку я пытался привязать ее к счету в paypal, но была смешная по нынешним меркам проблема на карточке отсутствовал cvc-код. Забегая вперед скажу, что проблема заключалась в том, что карта не являлась дебетовой, это была visa electron, на которых наличие cvc-кода не предусмотрено. Решалась проблема просто нужно было завести другую карту, например, виртуальную. Однако, для выяснения этой информации мне пришлось раз 6 позвонить в поддержку банка и лишь на третий день на другом конце провода попался компетентный сотрудник, который за 2 минуты все объяснил. Само собой, новую карту я завел уже в другом банке.

Невнимательность

Отдельным пунктом, который мы решили выписать изолировать от некомпетентности будет невнимательность сотрудников поддержки, которая бесит не меньше!

Знакома ли вам ситуация, когда в процессе переписки с поддержкой вы задаете три вопроса, но получаете ответ только на один или два? Нам знакома! Стоит отметить, что даже педантично пронумерованные вопросы тоже могут потеряться. Комментарии тут излишни.

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

Ограниченное количество каналов для связи

Еще один пункт в нашем антирейтинге это ограниченное количество каналов для связи. Какой смысл даже в хорошей поддержке, с которой у вас нет возможности связаться?

Тут речь пойдет не о личных предпочтениях каждого, а о ситуациях, когда вам НУЖНО связаться с поддержкой, но из-за ограниченного количества каналов связи такой возможности не представляется.

Вот достаточный список:

• тикет-система, если клиенту так комфортнее и нужно отслеживать статус обращения;

• адрес электронной почты, если нет возможности авторизоваться в тикет-системе;

• номер телефона, на случай отсутствия доступа в интернет;

• возможность связаться через мессенджер или онлайн-чат, если нет возможности позвонить.

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

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

Письма с адреса no-reply@domain.ru

Пожалуй, самый безобидный, но наиболее распространенный пункт, который нас тоже бесит.

В данной ситуации раздражает факт того, что мы не можем ответить на такое письмо. Точнее можем, но его никто не прочитает.

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

Нельзя пожаловаться

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

Часто ли вам предлагают возможность оценить качество полученного ответа? На самом деле, такая возможность появляется все чаще, но всегда ли эта оценка на что-то повлияет и поможет решить вашу проблему?

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

Отсутствие желания у руководства разбираться в каждой негативной ситуации можно понять, но это бесит!

На что влияет качество поддержки

Разобравшись со списком того, что нас бесит в поддержке пришло время подумать, а на что же это влияет?

Тут можно выделить 3 основных момента:

• отток клиентов;

• отсутствие лояльности;

• и как следствие, отсутствие продаж по "сарафанке".

Отток клиентов

Начнем с оттока клиентов, в чем нам поможет исследование ресурса pwc.com. В исследовании проводился анализ причин оттока клиентов, а лидерами рейтинга стали:

• плохое отношение сотрудников компании к клиентам;

• недружелюбное обслуживание клиентов;

• плохая репутация компании;

• некомпетентные сотрудники;

• низкая эффективность;

• недоступность товара (услуги).

Ничего не напоминает?

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

Отсутствие лояльности

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

Лояльность клиента подразумевает:

• адресное и продуктивно общение с отделом продаж;

• объективная, честная и своевременная обратная связь;

• готовность к изменениям, которые вы запланировали;

• помощь, в ряде ситуаций, причем как словом, так и делом;

• и конечно же, рекомендации!

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

Отсутствие продаж по сарафанке

Согласно индексу NPS, стать промоутером вашей компании могут только максимально лояльные клиенты, которые набирают 9-10 баллов, т.е. полностью довольны результатом вашего сотрудничества и качеством услуг. Будет ли доволен клиент, которого бесит ваша поддержка?! Конечно же нет.

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

Методы, которые сработали у нас

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

• запустили поддержку в Telegram;

• наладили систему премирования;

• внедрили систему оценок качества поддержки;

• перестали работать с некомпетентными и невнимательными сотрудниками.

Поддержка дата-центра в Telegram

Начнем с того, что мы первые, кто запустил возможность обращаться в поддержку дата-центра через Telegram. На данный момент около 20% обращений обрабатываются именно там. Процесс коммуникации простой и понятный всем, кто пользуется этим мессенджером.

Можно воспользоваться виджетом в правом нижнем углу на нашем сайте, либо найти чат в самом мессенджере (@itsoft_bot) и задать интересующий его вопрос.

Для интеграции с рабочей средой (у наc это Slack) использовали сервис telebot.im.

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

Система премирования

Еще один метод, который помогает нам удерживать планку это система премирования, которая завязана на ряд параметров KPI каждого сотрудника поддержки.

Многие параметры KPI связаны непосредственно со скоростью реакции сотрудника на поступившее обращение и качеством его работы, например:

• скорость реакции на поступившее обращение;

• время, которое потребовалось на его закрытие;

• количество пропущенных звонков;

• качество коммуникации с клиентом.

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

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

Если говорить о цифрах, то каждый сотрудник поддержки, который выдерживает уровень своих показателей KPI выше 95% на протяжении некоторого времени может поднять уровень своей зарплаты на 40% от базовой ставки, это не считая премии. Самые же эффективные сотрудники поддержки всегда могут рассчитывать на квартальную премию в размере 50% от уровня базовой зарплаты. Без кнута тут тоже не обходится, но об этом немного позже. Не жалейте денег на сотрудников, мотивация делает вещи!

Система оценок качества поддержки

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

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

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

Оценки можно ставить:

• в переписке по электронной почте;

• в тикет-системе;

• в чате Telegram.

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

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

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

Мы не работаем с некомпетентными и невнимательными сотрудниками

Последний метод, о котором я бы хотели рассказать: мы не держим в штате некомпетентных и невнимательных сотрудников.

Звучит проще, чем кажется на самом деле. Но вот как это на самом деле:

• начинается все с длительного отбора и череды собеседований (благодаря премиальной системе и достойному уровню зарплаты мы можем позволить себе опытных специалистов);

• каждый сотрудник поддержки проходит испытательный срок длительностью три месяца;

• на испытательном сроке тратится много сил на закрытие пробелов как по части коммуникаций, так и по техническим моментам (для этого мы разработали подробную систему обучения и массу инструкций, регламентов и регулярно наполняем корпоративную wiki);

• по итогам испытательного срока обязательная аттестация;

• если испытательный срок не пройден - увольняем;

• для тех сотрудников, которые уже прошли испытательный срок действует вышеупомянутая система KPI и правила, которых мы придерживаемся (если показатели KPI продолжительное время ниже 90% - увольняем);

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

Стоит отметить, что даже несмотря на строгость, текучка у нас практически отсутствует, но на это есть свои причины.

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

Риски перемен и как работать с персоналом

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

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

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

Однако, даже такой подход не может застраховать от ряда проблем, вот 3 основных:

• итальянская забастовка;

• увольнения;

• демотивация и нежелание работать.

К ним и перейдем.

Итальянская забастовка

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

Все прекрасно понимают, что такой формат взаимодействия невозможен.

Всегда находятся сотрудники, которые не хотят ничего менять в устоявшейся, родной, привычной схеме работы, им сложно самим принимать решения и ответственность в новых условиях. Они боятся навредить себе и/или компании, приговаривая дайте мне инструкции, и я буду их выполнять. Вот тут начинается самое интересное. Да, правила, инструкции и регламенты нужны и должны быть, но есть 3 момента:

• вы не закроете инструкциями 100% возможных ситуаций;

• ситуации, которые не закрыты инструкцией требуют, чтобы сотрудник думал самостоятельно;

• чем больше инструкций, тем меньше сотрудник думает самостоятельно.

Ситуация, на самом деле патовая, но мы стараемся ее избежать:

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

• в узких местах наша система оценки и мотивации гибкая, но не нарушает базовых принципов, цели и правила компании (например, если принято неверное решение, но оно имеет адекватно обоснование, мы дорабатываем систему, а не скидываем вину на сотрудника);

• мы не стесняемся объяснить сотрудникам цели компании, ее принципы, мотивацию руководителя и суть наших бизнес-процессов;

• учим сотрудников вникать в суть проблемы, ведь так проще принять решение, когда ситуация не подразумевает наличие инструкции;

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

Увольнения

Да, у нас, как и у других случаются увольнения. Значит цели и ценности компании и сотрудника сейчас не совпадают.

Но мы стараемся выяснить чем вызвано такое решение и получить максимально подробную обратную связь:

• устраивает ли заработная плата? (иногда вопрос сводится к сумме, которую мы можем себе позволить, сохранив сотрудника);

• в каком направлении сотрудник решил двигаться? (может быть и нам нужен такой специалист, у нас несколько разных направлений);

• если это результат конфликта, то в чем он заключался? (может быть есть проблемы, о которых мы не знаем);

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

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

Демотивация, нежелание работать

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

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

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

Тут мы придерживаемся следующих принципов:

• система KPI прозрачна и понятна всем, причем, создавалась она не единолично, все участвовали в этом, имея возможность высказать опасения и предложить решение;

• параметры KPI реальны и достижимы, мы не пытались задрать планку на такую высоту, которую никто не возьмет, при этом, не стали опускать ее слишком низко;

• мы поддерживаем тягу сотрудников к развитию своих профессиональных навыков, готовы оплатить им курсы, повысить заработную плату или пригласить на другую должность;

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

Результаты

Как мы знаем, главное это результат, о котором далее и пойдет речь.

Чего мы добились благодаря нашим методам и работе с сотрудниками?

Вот краткий список:

• увеличилась скорость реакции поддержки;

• увеличилась скорость закрытия обращений;

• снизилось количество пропущенных звонков;

• увеличилось количество обращений на сотрудника;

• снизился отток клиентов.

Далее, разберем каждый пункт немного подробнее и приведем цифры.

Увеличилась скорость реакции поддержки

За последние три года мы смогли сократить время ожидания клиентов на 43%. Например, в рамках тикет-системы до середины 2017 года среднее время ответа поддержки составляло 8,6 минуты, на данный момент это 4,9 минуты.

Увеличилась скорость закрытия обращений

Если взять за шаблон такой тип обращения как Подключение IP-KVM, то за три года мы добились сокращения сроков на 76%! Стоит отметить, что и принцип закрытия обращений изменился. Мы не закрываем обращения без обратной связи от клиента (само собой, если это необходимо), а значит, мы добавили промежуточный этап, но все равно стали быстрее.

Снизилось количество пропущенных звонков

Пропущенным звонком мы считаем ситуацию, когда трубку не подняли за 5 гудков, так вот, таких ситуаций стало ниже. Му улучшили показатели с 9% три года назад до 3% на данный момент. 6% не такой уж и выдающийся показательно, но и звонков с тех пор стало больше примерно на 10%.

Увеличилось количество обращений на сотрудника

Многих вышеперечисленных показателей легко достигнуть, растеряв часть клиентской базы или увеличив штат поддержки, но в нашем случае клиентская база росла, а среднее количество обращений на сотрудника за три года увеличилось на 76%, а это значит, что мы стали не просто быстрее, мы стали эффективнее!

Снизился отток клиентов

Эффективность не имеет смысла, если клиенты все равно уходят, но и эту статистику мы смогли выправить.

Вот наши показатели оттока клиентов по годам:

• за 2017-й год средний отток составлял 2,8 %, для нас это много, и мы начали действовать;

• в 2018-м мы получили первые результаты, отток снизился и составил 1,6 %;

• в 2019-м показатель не сильно изменился и оставался на уровне 1,7 %;

• за текущий, 2020-й год средний отток составляет всего 1,1 %.

Мы бы хотели похвастаться показателем меньше 1%, но увы, год выдался трудным и к сожалению, многих клиентов мы потеряли по независящим от нас причинам.

Появился отдел поддержки

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

С полным списком наших клиентов вы можете ознакомиться на нашем сайте.

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

Заключение

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

А вот и продолжение истории из начала статьи, как говорится, это еще не все!

- А вы что, не делали мне бэкапы!? Зачем я тогда вообще размещаюсь по-вашему???

Тем самым клиент намекал, что мы должны не только развернуть его бэкап, но еще и найти его там, куда мы же его должны были положить. Тут уже изумились инженеры и вопрос был передан менеджеру.

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

Кстати, потратив довольно много сил и времени мы смогли клиенту помочь, восстановив часть данных и возобновить его работу. Но, клиент все равно обиделся и вскоре съехал, само собой, ничего не заплатив, так как был уверен, что косяк наш и все проведенные работы - его устранение.

Как пропадают данные?

Потеря данных это действительно ужасная ситуация, все это понимают. Сотни оплаченных человеко-часов / результаты труда сотрудников, которые хранятся на серверах это не только деньги, это и ответственность и репутация. Восстановление же (*или попытки восстановления) данных после утери это тоже процесс очень трудоемкий и затратный. Само собой, наличие бэкапов это крепкий сон любого причастного сотрудника, но случиться может все что угодно:

• молния ударила в дата-центр Google;

• что-то пошло не так при миграции сервера и MySpace потеряла все данные пользователей за 12 лет с 2003 по 2015 годы (включая музыку, фотографии и видео);

• 16000 результатов тестов на коронавирус было утеряно из-за технической ошибки в Excel в Великобритании, подробности не уточняются;

• Яндекс удалил виртуальные машины активных пользователей, применив некорректную фильтрацию и перепутав их с должниками;

• администратор ошибся, а gitlab лишился базы данных объемом 300Гб;

• в результате кибератаки вируса-шифровальщика все данные в базе данных компании ISS World были утеряны.

Это малая часть известных случаев, которые афишировали на просторах интернета. Частностей на порядки больше, так что, лишний раз проверим наличие свежих бэкапов и идем дальше.

Наивность и дебиторка

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

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

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

• оплатить забыли или не успели;

• сейчас нет денег;

• не получили счет и забили;

• бухгалтерия где-то как-то что-то;

• прочая бюрократия.

Как хостеры обращаются с данными

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

Для понимания, обрисую ситуацию, которую мы транслировали при общении:

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

Первый вопрос довольно безобидный.

Как быстро, с момента образования задолженности сервер будет отключен?

Работа встала, но еще не все потеряно.

Однако, что происходит после того, как предоставление услуг приостановлено?

После появления задолженности, в какие сроки сервер будет разукомплектован / удален?

Аренда физического сервера:

Аренда виртуального сервера:

Случилось страшное. Сервер разукомплектован или удален, но может быть еще есть шанс, что данные можно восстановить?

После того, как сервер разукомплектовали / удалили, есть ли возможность восстановить данные?

Аренда физического сервера:

Аренда виртуального сервера:

Раз уж статистика такая, может быть хостеры предлагают бэкапы, которые входят в услугу по умолчанию? (тут речь только про виртуальные сервера, для физических сразу 100% нет, что логично)

Имеется ли резервное копирование, которое входит в стоимость услуги по умолчанию?

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

Что еще можно отнести к наивности?

Значок Договор, покажи ему свой договор! (с)

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

Под меня будут подстраиваться. Уверены?

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

Ситуация, когда наша бухгалтерия платит только по четвергам (с) не единична, но весьма комична.

А мы счет не получали! (с)

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

Вы же профессионалы (с)

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

Уходя, гасите свет (с)

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

Заключение

В заключение хотелось бы написать простой чек-лист, который позволит снизить вероятность потери данных, извините, если некоторые пункты будут очевидными:

• делайте бэкапы и храните их отдельно от сервера в другом дата-центре, а лучше в нескольких местах;

• проверяйте бэкапы (а можно ли из них что-то развернуть?);

• внимательно читайте договор, задавайте вопросы, если важные для вас моменты не прописаны;

• убедитесь, что вы точно получите счет за услуги, резервируйте получателей;

• настройте автоплатеж, если не задействована бухгалтерия;

• если бухгалтерия имеет место быть - объясните ей, что сначала нужно заплатить, а потом решать любые возникающие вопросы, промедление может оказаться фатальной ошибкой;

• спросите у своего хостера про бэкапы и другие, пусть даже самые очевидные ситуации;

• поинтересуйтесь у вашего менеджера как принято работать с дебиторкой, какие сроки у вас есть и как можно их оттянуть;

• не рассчитывайте, что хостер будет вас кредитовать, там тоже бизнес, тоже бюджеты и кормление завтраками никто терпеть не будет;

• не будьте наивными, это дорогого стоит.

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

1. Мы не сможем точно ответить на ряд вопросов, потому что подход индивидуальный (и вот тут придется объясниться);

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

Немного слов про индивидуальный подход при работе с дебиторкой.

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

Да, у нас есть бэкапы по умолчанию для виртуальных серверов, но спросите менеджера когда исчезнут ваши данные и он не ответит. Почему? Потому что подход все еще индивидуальный. Факторов масса, но один, наиболее важный - мы не доверяем автоматизированным оповещениям. Счета рассылаются автоматически по электронной почте, туда же, с завидной периодичностью падают письма с напоминанием и дублем счета. Еще мы используем смс-оповещение, остановились на API greensms.ru, но это все автоматика.

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

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

Исключения наверное есть, но это те, кто:

а) не прислал платежку;

б) пользуется этим лайфхаком с завидной регулярностью.

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

Берегите свои данные, не позволяйте хостерам их уничтожать!