Источник
Банкоматы периодически ломаются. Иногда — сами, просто из-за износа механических частей, чаще — с помощью клиентов банка. В них могут застрять мятые деньги, скрепки, скотч. Может в который раз упасть винда, на которой они работают. В общем, они ломаются. Но вовремя поднятая вещь не считается упавшей, поэтому мы их быстро-быстро чиним.
Точнее, сначала робот чинит банкомат. На типовые срабатывания датчиков заводится инцидент, и робот начинает программу восстановления. Обычно это перезагрузка или сброс ошибок на конкретном модуле. Если после перезагрузки состояние сохраняется либо если поломка повторяется чаще статистической вероятности, то появляется алерт для инженера или оператора.
Если нужен физический ремонт, то робот после диагностики пишет отчёт и говорит, какие запчасти надо брать.
Меня зовут Павел Слюсарь, и я директор департамента развития сервиса «Мультикарта». Мы помогаем примерно двадцати тысячам банкоматов и научились возвращать их в строй практически молниеносно. Сегодня я расскажу, как мы дошли до «системы быстрого реагирования» и какие инструменты в ней используем.
Что может сломаться в банкомате
Из всех проблем с банкоматами примерно 60 % связано с деньгами, их передвижением, замятием, отсутствием или, наоборот, переизбытком и решается с помощью инкассатора.
Вообще количество наличных в банкомате очень хорошо прогнозируется. Инкассация — операция сложная и дорогостоящая, и банки научились планировать её на те дни, когда наличные уже на исходе. В большинстве случаев у них это отлично получается. Но время от времени задача вовремя поменять кассеты с банкнотами осложняется дополнительными обстоятельствами.
Во-первых, иногда банкомат бывает доступен для клиентов, но недоступен для инкассаторов и инженеров. Например, в выходные дни зачастую закрыты здания и офисы, в контуре безопасности которых находится та часть банкомата, где проходит обслуживание. Стало быть, снять деньги с карточки можно, а снять с сигнализации банкомат и загрузить или разгрузить его — нельзя. И тут уже неважно, насколько грамотно был составлен график обслуживания.
Во-вторых, время от времени поведение клиентов становится непредсказуемым. На фоне каких-нибудь новостей люди могут все в один день массово отправиться снимать (или класть) наличные. И это, конечно, ломает прогнозируемый план инкассаций приблизительно целиком.
Остальные примерно 40 % неисправностей связаны с любыми другими узлами и функциями.
Например, банкомат может потерять связь с центральным компьютером и маршрутизатором.
Часто ломаются ролики и сбоят чиповые станции картридеров, в которые вставляется карта (бесконтактные в этом плане безопаснее).
А ещё могут возникнуть проблемы с:
- Чековым принтером и расходными материалами.
- Чтением карты клиента.
- Сложным оборудованием приёма-выдачи денежных средств.
- Клавиатурой.
- Связью.
- Софтом и т. д.
В идеале банкомат должен оставаться нерабочим не дольше нескольких часов
Кто обслуживает банкоматы
Ключевых ролей — пять:
- Центр, где работают координаторы, инцидент-менеджеры, роботы, а также админы, которые следят за софтом, установленным на каждый из банкоматов. Эдакая линия поддержки, которая помогает инженерам «в полях» и обеспечивает прогрузку и проливку программного обеспечения каждого устройства. Координируют инженеров и выстраивают маршруты инкассаторам тоже здесь.
- Инкассаторы — в основном это бравые ребята на бронированной машине с ограниченным набором действий. Лучше всего они умеют охранять деньги и в случае чего чётко действуют по военному регламенту.
- Сервисные инженеры — узкоспециализированные профессионалы с узкоспециализированным оборудованием, которые хорошо знают, как протестировать банкомат, как его починить на месте и как снять и заменить модуль, чтобы поковыряться с ним в офисе, если на месте разобраться не выходит. Инженер, который выезжает чинить полный банкомат, не всегда сопровождается инкассатором, потому что совместные выезды — это всегда очень дорогой процесс. Чаще всего сначала инкассаторы выгружают из банкомата деньги, а затем приезжает инженер, который может спокойно ремонтировать его несколько часов, пока не починит окончательно.
- Менеджеры устройств. Это работники в регионах (в основном сотрудники банка), которые с помощью специальной программы выбирают конкретное место, где оптимально будет поставить банкомат. А затем приезжают на точку, чтобы посмотреть, как он будет смотреться и насколько хорошо его там заметно, договариваются об установке с арендодателем и взаимодействуют с клиентами, которые ходят к этому банкомату снимать деньги, когда у них возникают претензии.
- Централизованная региональная структура департамента безопасности, которая отвечает за выбор и установку средств, ограничивающих возможность влияния на банкомат. То есть за всякие антискимминговые накладки, сигнализацию, видеонаблюдение и т. д.
Схема, по которой проходит технический мониторинг, выглядит примерно так
Самое важное для инцидент-менеджмента качество банкомата
В отличие от многих других видов оборудования банкоматы можно диагностировать удалённо.
То есть в любой момент времени известно, в каком состоянии находится каждый из узлов: выдача, приём, картридеры и т. д.
Значит, мы можем обновлять программное обеспечение и устранять многие ошибки удалённо.
И максимально точно выстраивать маршруты и инструкции для инженеров, которые отправляются на выезд, чтобы устранить те ошибки, с которыми удалённо справиться не получилось.
Когда мы только начинали заниматься банкоматами в 2008-м, то работали по классической схеме
Банкомат в ней воспринимался как обычный юзер, у которого что-то периодически ломается.
Когда у нас на обслуживании была всего пара сотен устройств, этот принцип работал просто замечательно. Как только происходил инцидент, специально обученный человек видел в списке всю информацию о нём, а если не видел, то любые изменения в состоянии устройств дублировались к нему на почту. Дальше он мог зайти в инцидент и сделать всё необходимое: разрешить, устранить, перезагрузить и т. д.
Но затем у нас резко выросла инсталляционная база, и банкоматов, которые мы сопровождаем, стало двадцать тысяч. Мы раздробили их по регионам и линиям, но время, которое человек тратит на поиски изменений, всё равно стало превышать время на их обработку примерно в три-четыре раза, а это как-то неправильно.
Тогда мы сели и стали думать, как сделать, чтобы весь поиск происходил исключительно с помощью машины, а человек занимался более интеллектуальной работой.
Мы думали-думали и придумали перейти к событийной модели. Это не самое популярное решение, т. к. почти ни в одном сервисдеске его не используют как основное: везде сохраняются центральными история интерфейсов инцидент-менеджмента, тикет менеджмента, список заявок, список инцидентов и т. д. И очень зря, потому что оно нас буквально спасло.
Суть решения такая: для наших сотрудников перестал существовать список инцидентов, зато появилась событийная лента. Больше всего она напоминает мессенджер для общения с системой: в реальном времени человеку приходит сообщение с коротким описанием инцидента, по которому нужно быстро ответить.
В программе эта лента выглядит вот так. Интерфейс «Последние события» — ключевой интерфейс системы КТО. Вся работа специалистов технического мониторинга сосредоточена в нём. Именно качество и скорость обработки событий в этом интерфейсе определяют будущую доступность Сети УС.
А работает это так
Три ключевых понятия системы:
- Инцидент — длительная сущность, которая существует с момента возникновения проблемы до момента её устранения.
- Событие — мгновенный сигнал, который возникает при любых изменениях внутри инцидента и должен привлечь внимание человека. У него нет жизненного цикла — оно возникает, захватывается, обрабатывается и исчезает. В рамках одного инцидента может быть несколько событий.
- Заявка — она тоже существует внутри инцидента и направлена на какого-нибудь исполнителя, который будет разбираться с банкоматом на выезде или удалённо. У каждой заявки в программе есть определённые атрибуты: тип, регламентное время, статус просрочки, текущее время выполнения и т. д.
Как только происходит любое изменение в сервисдеске (инцидент, заявка и т. д.), сообщение об этом в оптимизированной форме приходит всем сотрудникам в ленту, где отражаются события, отсортированные по приоритету, времени появления, сложности, направленности и т. д.
Сотрудник выбирает одно из них, переходит на отдельную страничку, получает полностью подготовленное сообщение по инциденту, отрабатывает то действие, которое нужно сделать прямо сейчас, не глядя на информацию о том, что происходило до него, и закрывает окошко.
Допустим, что в банкомате перестал работать картридер. Система получает сигнал, она знает, что первым делом его нужно перезагрузить, и делает это самостоятельно. Инцидент сформирован, сигнал отправлен, перезагрузка прошла. Допустим, картридер не восстановился.
Дальше система отправляет заявку к инженерам. Допустим, что-то сбойнуло в программе и ответа от инженеров о том, что скоро кто-нибудь приедет его чинить, не пришло. Тогда через нашего сервисного партнёра оператору отправляется событие. Выглядит оно, как строчка в отдельном интерфейсе, которая гласит примерно следующее: «Банкомат 11222, долгое время отсутствует назначение инженера, необходимо позвонить в координацию сервисного партнёра и выяснить, в чём проблема в выполнении назначения данной заявки».
Оператор переходит по ссылке, заходит в карточку, в которой до него уже были сделаны какие-то действия, и видит итоговый комментарий. Этой информации ему достаточно для того, чтобы, не погружаясь в глубокое исследование о выполненных и невыполненных работах, позвонить сервисному партнёру и попросить назначить инженера, который съездил бы и разобрался, что происходит с банкоматом. Партнёр открывает свою программу, видит, что из-за человеческого фактора произошла ошибка, и говорит оператору: «Простите, пожалуйста, у нас косяк. Но мы уже назначили Петрова, он скоро отправится на объект, а вам сейчас придёт информация через инфообмен». Теперь оператор имеет полное право закрыть окошко и забыть про этот инцидент.
Дальше либо инженер Петров починит банкомат, и больше никто никогда не вспомнит об этой истории, либо не сможет починить, и событие с информацией об этом снова попадёт в интерфейс. Оператор откроет его в порядке очереди и также отработает, не вчитываясь в исторические справки.
Мы можем настроить бизнес-процесс, например, так, что человек должен отреагировать только на третий сбой. Заглючил картридер, робот его перезагрузил, не помогло — перезагрузил, опять не помогло — перезагрузил и создал событие. Человек зайдёт в это событие, внимательно прочитает логи, найдёт среди них нестандартные и, возможно, примет какое-нибудь своё решение по инциденту. А ещё он может отправить в службу автоматизации бизнес-процессов комментарий о том, что тут неплохо было бы сделать развилку.
У нас есть инциденты, в которых человек не появляется вообще ни разу: вся система отрабатывается автоматически. Есть такие, где один сотрудник разбирается со всеми вопросами.
А есть и такие, к которым независимо друг от друга на разных жизненных циклах инцидента подключается до пяти-шести операторов.
Самый главный плюс такой системы в том, что сотрудники больше не тратят времени на поиск
И благодаря этому мы сократили трудозатраты операторов примерно на 60 %.
У нас больше нет ситуации, когда человек сидит и смотрит, что поменялось и перекрасилось из зелёного в красный и наоборот на дашборде или в списке тикетов в сервисдеске. Этот этап мы прошли ещё в 2012 году.
Кроме того, нам теперь видна реальная картина трудозатрат человека, которая построена не на входящем потоке сигналов в систему, а на потоке сигналов оператора. Мы знаем, сколько каких событий принесла система, сколько из них захватил каждый сотрудник, а также кто и сколько потратил времени.
И это был первый глобальный шаг нашей оптимизации.
И тут настало время тотальной (ну почти) автоматизации
Когда мы оптимизировали поиск, большая часть событий у нас ещё не была автоматизирована.
Поначалу система только хардкодно стреляла сигналами о том, что где-то что-то произошло и человеку нужно подключиться и разобраться, что именно.
Следующий шаг был такой: мы захардкодили, откуда возникали эти события в момент определённых изменений, определили последовательность и объём событий.
Затем собрали так называемое дерево автоматизации, то есть двоичное дерево переходов, которое может запускать в разные ветки различные источники данных, откуда происходит последовательный анализ возникшего инцидента или заявки. Система идёт по дереву и в определённые моменты генерирует события на обработку.
Как только выстроили дерево и получили ключевые объёмники по событиям, мы начали автоматизировать эти точки от большего к меньшему. Каждая веточка этого дерева, поначалу приводившая к ручным событиям, потихоньку становилась автоматизированным бизнес-процессом.
Там, где возникало очень много ручных событий, мы описывали бизнес-процесс более детально, добавляя его в дерево, чтобы система могла отрабатывать его и вносить комментарии самостоятельно без участия оператора.
Из всех событий, которые поначалу обрабатывались людьми, 84 % теперь обрабатывается автоматически. На долю инженеров осталось только 16 % заявок, и это самые сложные истории, которые выполняются дорогими службами инкассации и самыми профессиональными из всех профессиональных инженерами. Как правило, они связаны со свободным текстом, который нельзя привести к общему знаменателю. Например, если в заявке написано что-то типа: «Что делать, если меня покусал банкомат?» — с этим придётся разбираться человеку. Но что-то подобное увидеть в заявке можно нечасто.
И это правильный подход, потому что многие формализованные моменты содержат в себе свободный текст, и нам дешевле, чтобы человек этот текст прочитал и правильно отреагировал, чем опираться только на роботов.
Кстати, про наших роботов
Они выполняют человеческие функции, мы их очень любим и знаем каждого по имени. Кроме того, у каждого есть своя история.
Нет, мы не сходим с ума, просто так реально удобнее. Довольно сложно произносить: «Какое изменение мы внесли в робота принятия первого решения в части автоматической обработки модуля классической обработки инцидентов?» Гораздо проще сказать: «Как изменился Валл-И?»
Он, кстати, был первым роботом, которого мы запустили. Со стороны бизнес-аналитики этим занимался начальник группы Валентин Сердюков. Поэтому робота зовут, с одной стороны, в честь милого мультяшного персонажа, а с другой — в честь его создателя.
А ещё у нас работают Маруся, Илана, Мила, Тор, Катюша, Инна, Вика, Джулия, Сигма, Вадик и Джарвис.
К чему мы хотим прийти в конце концов
Сейчас мы заняты постепенным внедрением машинного обучения. Мы уже сделали это на входе с точки зрения обращений и жалоб, где свободный текст превращается в некие формализованные теги. И постепенно движемся к тому, чтобы на базе всех имеющихся у нас отчётов обучить систему формализовывать свободные изыскания инженеров. И тогда наше двоичное дерево с упорядоченной информацией сможет обеспечить нам автоматизацию последнего пласта события со свободным текстом.
Автор:
Pavel_Slyusar
