Вместо предисловия или откуда щупальца LEAN
Пару лет назад мой коллега рассказывал, как работает LEAN в нашем подразделении Сервис Деска. Но как-то умолчал, что LEAN работает у нас во всех сервисных проектах, а не только в Сервис Деске. В целом LEAN очень полезный инструмент поиска зон улучшений в процессах работы, и что важно – это хороший командообразующий инструмент.
Введение
Однажды давным-давно, в далёкой-далёкой галактике… И да, пребудет с тобой Lean Thinking!
В общем, разбираясь в потерях работы ITSM-процессов, команда пришла к заключению, что они зачем-то тратят время людей на задачу с сильным таким monkey-job. А точнее, на координацию входящих запросов в стек команды со всех источников. И вроде бы всё тут понятно и можно сделать. Но в чём подвох? Создай классификаторы и маршрутизацию настрой на их основе, и будет тебе счастье… Вот тут-то мы и столкнулись с проблемой: страдает «точность» и человека-координатора мы полностью убрать не можем, прям «бяда».
На пути к правильному решению или подготовка
Ну, точность и точность…. Идём по принципу Кано и решаем, что можем с максимально разумным эффектом: матрицы классификаций – решение о выставление класса через поиск опорных слов в описании и т.д. И аллилуйя!
70% скопа заявок перекрыто роботом! — Все довольны: «Мы круты, мы боги...». Мы реально это внедрили и нормально так жили уже несколько лет. Но время идёт, а потеря то, вот она. Мы теперь хотим, чтобы и классификация, и даёшь нам точность человека.
Начинаем решать задачу перекрытия оставшегося скопа заявок. Помним, что это примерно 30%.
Итак, их основные проблемы:
- Запросы прямых пользователей без структуры описания.
- Новые типы запросов требуют времени на описание.
- Запросы, похожие на другие, в классификаторе едут не в ту команду…
Уже становится понятно, куда клонится наш рассказ? Итак, время идёт, а LEAN не терпит издержек…
Итак, суть проблемы
Что такое запрос — это текст, который надо обрабатывать, и на результатах нужно выносить решение о его классе. К примеру, использование уже немного описанного классификатора по определённым фразам и словам требует достаточно долгой подготовки матрицы классификации и её постоянную актуализацию.
Начали думать, как быть. Команда поняла, что у неё не хватает возможности решить эту задачу. Тогда обратились к коллегам из отдела оптимизации. Есть у нас такая команда, как на заводах Тойота, они помогают всей компании в оптимизации процессов: ищут, копают и т.д.
«Бесконечно можно смотреть на то, как течёт вода, горит огонь, и другие работают…» - неизвестный мне автор. Начинаем штурмовать новые высоты с использование шторма. Brainstorm очень полезный инструмент, метод 5W усиливает шторм до бури! И что же мы нарешали:
Наши исходные проблемы:
- Проблема точности, а точнее технологическая слабость имеющегося решения и нет возможности его улучшать.
- Проблема стоимости поддержки – надо постоянно актуализировать матрицу классификации, следить за отклонениями.
Какие предложения по решению:
- Надо, чтобы машина могла принять решение по качеству предложенного варианта.
- Решение должно самообучаться с минимальными затратами.
- Поддержка решения в остальном не отличается по стоимости от предыдущего решения.
Начинаем перебирать варианты.
Из технологий можно подумать о статистической аналитике с элементами BI. Дорого, да и зачем тут монстра с элементами ERP? Проблемы то похожи на задачи, решаемые «искусственным интеллектом» и механизмами «машинного обучения». Ну что же, наш отдел оптимизации, не сомневаясь в успехе, на следующую встречу позвал ребят из отдела диджитал-решений.
Решаем проблему
Дата-архитекторы и дата-инженеры за пару недель перебрав немалое количество фреймворков, выкатили решение – первую оценку и модель:
Ещё через месяц мы состыковали нашу ITSM и «Искусственный интеллект» и закончили тестирование.
В итоге: нам совсем не нужны координаторы запросов, так как робот сейчас обрабатывает 99% всех инцидентов и для оставшихся 10-15 инцидентов в день не создают негативное ощущение рутины. Команда довольна, не отвлекаясь от основных задач, сотрудники получили устранение рутины, просто заявив, что этот «архаичный инструмент» уже устарел и мешает работать.
Вывод
Совместное с командой постоянное наблюдение за своими процессами несёт неоценимую пользу. Не только позволяя находить издержки и устранять их, а также формировать понимание и потребность в использовании новых технологий. Решая задачи устранения даже минимальных по значимости, но полностью рутинных проблем, мы действительно создаём ценность. И ценность не только для заказчика, но и для сотрудников и компании.