Путь службы поддержки: от древности к современности
Есть хорошая фраза: «Невозможно управлять тем, что нельзя измерить». Ее авторство приписывают многим — от Питера Друкера до Билла Хьюлетта. На схожем принципе основан и цикл Деминга (Plan-Do-Check-Act) — запланировали, реализовали, проверили, что получилось, скорректировали направление и все по-новому. Примерно по такой же схеме работает служба поддержки в «ЛАНИТ-Интеграции». Благодаря подаренному мне опыту и родилась идея этой статьи.
Предлагаю вместе разобраться, является ли техподдержка порождением новомодных библиотек и фреймворков, или это просто современная версия того, что было сотни лет назад, и как бизнес пришел к тому, что эффективность процессов поддержки оказывает значительное влияние на работу сервисов, требуя отдельного внимания.
Жизненный цикл информационной системы в классической водопадной модели выглядит достаточно просто и состоит из семи этапов: анализ требований, проектирование, реализация, тестирование, внедрение, эксплуатация и вывод из эксплуатации (рис. 1). Однако идеальный мир ― это утопия. Дело в том, что на любом этапе могут возникнуть ошибки. Например, неправильно сформированные требования, неточности в проектировании или разработке ИС, невнимательность при тестировании, внедрении. В итоге на последнем этапе проявляются все ошибки, и без поддержки (и учета сбоев) система может быть неработоспособна.
Рис. 1. Жизненный цикл информационной системы по классической водопадной модели
Такая ситуация может произойти в любом секторе. К примеру, в промышленности выход из строя оборудования на одном из этапов производства приведет к сбою всех остальных бизнес-процессов. А это, как мы знаем, чревато серьезными последствиями.
Создание чего-то нового оценить довольно легко. Например, мы невооруженным глазом видим появление нового этажа в строящемся здании, а при внедрении новой ИС отслеживаем закрытие этапов в JIRA. Но оценить работу службы поддержки сложнее, так как не видно картину целиком. Максимум ― это массовые сбои и то, как их лихорадочно устраняют.
При эксплуатации ИС важно знать, какое количество сбоев возникает у системы, как быстро они могут быть устранены, как одни ошибки влияют на другие, сколько времени нужно на реализацию новых функций, какое влияние это все оказывает на бизнес-процессы.
Заря промышленной эры: минимальная отчетность — низкий уровень управляемости
Предлагаю посмотреть на эволюцию службы поддержки и инструменты её взаимодействия с высоты птичьего полета.
А вы знали, что такие службы существуют с древности (махните в комментариях)? Как только люди стали специализироваться (одни охотятся, другие делают стрелы, третьи готовят пищу), то появились и те, кто занимался ремонтом. Например, в древнем поселении есть гончар, который может не только сделать новый кувшин, но и отремонтировать прохудившийся.
Если посмотреть на это современным взглядом, то есть набор умений (оказываемых услуг), канал для подачи обращений (личное обращение потребителя услуги или доверенного лица), соглашение об уровне услуг (стоимость, качество). Их либо запоминали, либо записывали на берестяные грамоты, глиняные таблички или другие древние носители информации. И так продолжалось примерно до начала промышленной революции.
XVIII—XIX века. Появляются фабрики и специальные работники, которые ремонтируют и настраивают станки. Изменений с точки зрения организации работы не так много. Все то же взаимодействие через личные обращения. Но появляются журналы учета аварий и работ ― предшественники современных систем Service Desk.
Они используются не просто для отчетности и расчета налогов, но и для аналитики: сколько раз из строя выходил ткацкий станок, из-за чего, сколько был в простое. Их также использовали и для записи сбоев в первых электронных вычислительных машинах.
Hidden text
А вы знаете, что одна из первых известных записей в истории, сделанная в таком журнале, ― восстановление компьютера Harvard Mark II.
9 сентября 1947 года операторы компьютера, который тестировался в Гарварде, зафиксировали его отключение. В процессе разбора проблемы был обнаружен мотылек, закоротивший реле. Таким образом, был зафиксирован не только первый баг компьютера, но и популяризирована идея дебаггинга (отладки). В настоящее время журнал с приклеенным мотыльком находится в Национальном музее американской истории.
Кстати, человеком, который нашел моль, была Грэйс Хоппер («Бабушка Кобол»), которая развила концепцию машинно-независимых языков программирования и сделала первый компилятор — программу для перевода программы в машинные коды.
Как в те времена «пользователи» могли обратиться в «службу поддержки»?
Вариантов было немного: сходить пешком, отправить посыльного, возможно, использовать какой-нибудь местный семафор или телеграф. Других вариантов до массовой компьютеризации и телефонизации практически не было. Все записи велись в книгах вроде больших амбарных. Но позже компьютеры стали развиваться, а журналы аварий перекочевали в электронный вид, хотя оставались всего лишь инструментом для отчетности и статистики.
В середине прошлого века, в период, когда компании начали активно расширяться, усложнялись поддерживаемые системы, развивалась телефония, стали формироваться и первые колл-центры, которые работали с поступающими обращениями. В то же время начало приходить осознание, что эффективность процессов поддержки оказывает значительное влияние на бизнес и требует отдельного внимания. Одна из первых попыток систематизации и оптимизации лучших (на то время) практик ― библиотека ITIL (Information Technology Infrastructure Library), первая версия которой появилась в конце 1980-х.
Чуть позже процессы поддержки стали автоматизировать ― для регистрации сбоя нужно было заполнить несколько полей в электронной таблице, а также определенные строки в зависимости от ситуации. Кстати, при смене статуса стали автоматически отправляться электронные письма и другие схожие операции, например, назначение ответственного исполнителя, формирование цепочки заданий для стандартных работ.
Но самое главное ― взаимодействие оставалось реактивным: пожаловались ― устранили проблему. Но если никто не жалуется, то можно ничего не делать. Неплохой иллюстрацией такого подхода стали анекдоты того периода про пользователей или известная серия рассказов «BOFH» (Bastard Operator From Hell, Simon Travaglia):
Я молча кладу трубку на принтер, включаю его и запускаю тест. Поворот ключа в замке — и мне уже никто не помешает проходить особо трудную миссию Comanch’а. Стук в дверь заглушается принтером, принтера я не слышу — в наушниках мобилизующе звучит Tribal Dance, и из состояния полного кайфа меня выводит только чувство голода.
Обед — это святое. Turbo Debugger — на экране, трубка — на телефоне, дверь — настежь. За дверью — очередь юзеров. Горящие взгляды провожают меня, пока я вывешиваю табличку «Обед. Без причин не беспокоить» и закрываю дверь.
Каналы взаимодействия и начало автоматизации
Ключевое изменение, которое принесло развитие компьютеризации и оптимизация процессов поддержки, — переход от реактивной парадигмы к интерактивности. Нужно было не просто зафиксировать проблему, а как можно точнее диагностировать ее с самого начала, оценить влияние на бизнес и срочность. Изменения начались с самого первого шага, а именно со способов коммуникации с пользователями.
Ниже собрал для вас разные каналы обращений, их плюсы и минусы.
1. Телефон
В начале 1980-х обработку телефонных обращений стали активно оптимизировать через голосовое меню (Interactive Voice Response, IVR). Первыми подобную систему внедрили банки и телеком-операторы ― те организации, в которых можно автоматизировать обработку типовых запросов. Например, такие популярные команды, как «Нажмите 1 для запроса баланса / 2 для смены пин-кода» и т.д. В корпоративной среде IVR широкого распространения не получил, поскольку звонки все равно переадресовываются на единственного диспетчера (если речь идет о компании среднего размера) или в контакт-центр к универсальным операторам (в крупной компании). В первую очередь это связано с очень разнообразным набором запросов.
Главный плюс телефонной связи — оперативность. Пользователь может сразу задать уточняющие вопросы по возникшей проблеме или получить объяснения по ее решению. Однако это будет распространяться на несложные задачи, которые возможно быстро решить. Из этой ремарки вытекает основной минус — низкая эффективность для непростых проблем. Словами не всегда можно лаконично описать, что происходит на экране, и приходится ждать, когда оператор или пользователь предпримет какие-нибудь действия.
Но все-таки телефон остается одним из самых популярных средств коммуникации. Конечно же, развитие технологий не обошло этот инструмент стороной. Например, бизнес стал внедрять функцию распознавания речи, а также дал возможность пользователю решить свою проблему вместе с чат-ботом. Но технологии развиваются, и, возможно, через несколько лет мы уже не будем так сильно ненавидеть голосовых помощников.
2. Электронная почта
Давайте начнем с того, что первое электронное письмо было отправлено в 1965 году учеными Массачусетского технологического института. В 1971 году американский программист Томлинсон разработал метод, который позволял отправлять электронные письма по сети Arpanet (дальний родственник интернета), а также предложил ввести в использование символ @. Буквально через пару лет появились первые стандарты. А веб-интерфейсом и массовыми хакерскими атаками электронная почта обзавелась в девяностые.
Главный плюс почты — это возможность оперативно передавать большой объем информации — технических вложений, например, логи или скриншоты. Однако у этого инструмента ограничены возможности автоматизации. Можно использовать шаблоны писем, mailto-ссылки, XLS и PDF-формы. Но далеко не всегда можно обеспечить корректность заполнения этих форм, а следовательно, и автоматизировать их обработку.
Сейчас явно виден тренд, который связан со снижением популярности электронной почты и переходом в мессенджеры. Теперь простые и оперативные вопросы проще решать там. Посмотрим, что будет дальше.
3. Веб-порталы
Более широкие возможности автоматизации для подачи обращений дали веб-порталы. На них могут быть размещены интерактивные формы регистрации заявок и базы знаний, например, инструкции или способы решения типовых ошибок.
Стало возможным подать заявку, которая ранжируется по уровню доступа. Например, по бухгалтерской системе могут оставить обращение только сотрудники бухгалтерии, а заявку на установку Photoshop — дизайнеры. Однако заведение запроса — это не просто форма с текстовым полем, а набор выпадающих списков, которые помогают диагностировать запрос пользователя. Например, если проблема с доступом в интернет, то будут заданы примерно следующие вопросы, открывается ли корпоративный портал или с каким сайтом проблемы, какое сообщение об ошибке. Пример подобного портала смотрите ниже.
Пример формы подачи заявки
Кроме диагностики, такая детальная информация о проблеме позволяет сделать не только автоматическое назначение на ответственных специалистов, но и решить некоторые заявки, предоставив, например, права с помощью запуска скрипта. Главный плюс — это возможность контролировать правильность ввода данных, предостерегать пользователя от ошибок и не оформлять некорректные обращения. Однако создание заявки у пользователя отнимает больше времени, чем другие альтернативные способы, а также требует дополнительной информации для описания проблемы. К тому же требуются дополнительные ресурсы на поддержание форм заявок и логики их обработки в актуальном состоянии. В крупной компании с тысячами форм заявок для этого могут потребоваться целые отделы, а это уже минус.
4. Чаты и чат-боты
Если вы вдруг хотите изучить суперкраткую историю создания и развития чат-ботов, то картинка ниже идеально для этого подходит.
Ну что, признавайтесь, кто злится, когда нужно быстро решить важный вопрос, а ты вынужден прослушивать голосовое меню бота по имени Иван? Думаю, многие. Но давайте рассмотрим этот инструмент с двух сторон: пользователя и технической службы.
Например, для технического специалиста намного удобнее получать заполненные заявки и приступать к устранению проблемы сразу (почти сразу), а не тратить время на обработку обращений через телефон или электронную почту. А вот если посмотреть со стороны пользователя, то зачастую такие виртуальные помощники, мягко говоря, злят. Думаю, каждый из нас попадал в такую ситуацию, когда нужно решить проблему быстро, а вместо этого мы топаем ногой и слушаем голосовое меню до нужного нам пункта. А вот с нестандартными запросами сложности возникают чаще. Например, фразу «открыть счет» или «показать реквизиты» — робот поймет, а вопрос «Обязательно ли вводить номер корреспондентского счета при переводе?» может поставить его в тупик. К тому же все эти средства оптимизации лишены души и человечности, которые нужны при устранении проблем. Если надо оформить заявку на выдачу техники, то процесс может быть формальным. Но если речь идет о срочном отчете для руководителя, который уезжает на важную встречу, такой подход уже не подойдет.
Что будет завтра?
Один из вариантов заглянуть в будущее — это провести анализ существующих и разрабатываемых технологий (этапы их развития, внедряемые функции), а также изучить тренды этой области.
Конечно, полноценному анализу нужно посвятить отдельную статью, но я сделаю небольшой срез на примере ITIL. На первом этапе стоит рассмотреть, сколько новых версий выходило и какие основные изменения вносились. Приступим.
Стартовая версия библиотеки — это обобщение передового опыта в области управления ИТ-системами. Ядром второй стала концепция управления ИТ-сервисами ITSM, которая основана на использовании базовых правил оказания услуг ИТ-отделами как сотрудникам компании, так и ее клиентам. Следующая версия была ориентирована на систематизацию и повышение уровня удобства ее использования. В четвертой происходит смещение фокуса с жизненного цикла услуги на формирование бизнес-ценностей.
Исходя из новостной ленты, количества исследований и разработок, можно говорить о том, что новая концепция будет включать, например, правила использования искусственного интеллекта, продвинутых алгоритмов анализа и обработки. А может быть, следующая версия ITIL будет написана при помощи ChatGPT с картинками от MidJourney. Какие ставки?
Вывод
Каждый инструмент предназначен для решения определенного круга задач. То, что хорошо работает для клиентов банка или телеком-оператора, не будет эффективным для сотрудников внутри организации. Все дело в количестве типов заявок, специалистов и направлений на стороне поддержки. Сейчас уже не найти крупного телеком-оператора с прямым доступом к контакт-центру без голосового меню. Однако в сегменте премиальных банковских услуг прямой контакт с персональным менеджером — не редкость.
Возможно, в ближайшем будущем в «ЛАНИТ-Интеграции» появятся голосовые роботы, которые будут распознавать эмоции и с первого раза правильно интерпретировать даже сложные вопросы. Но это уже совсем другая история.
