Искусственный интеллект, ITSM и в общем-то причём тут LEAN?

Вместо предисловия или откуда щупальца LEAN


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



Введение


Однажды давным-давно, в далёкой-далёкой галактике… И да, пребудет с тобой Lean Thinking!

В общем, разбираясь в потерях работы ITSM-процессов, команда пришла к заключению, что они зачем-то тратят время людей на задачу с сильным таким monkey-job. А точнее, на координацию входящих запросов в стек команды со всех источников. И вроде бы всё тут понятно и можно сделать. Но в чём подвох? Создай классификаторы и маршрутизацию настрой на их основе, и будет тебе счастье… Вот тут-то мы и столкнулись с проблемой: страдает «точность» и человека-координатора мы полностью убрать не можем, прям «бяда».

На пути к правильному решению или подготовка


Ну, точность и точность…. Идём по принципу Кано и решаем, что можем с максимально разумным эффектом: матрицы классификаций – решение о выставление класса через поиск опорных слов в описании и т.д. И аллилуйя!

70% скопа заявок перекрыто роботом! — Все довольны: «Мы круты, мы боги...». Мы реально это внедрили и нормально так жили уже несколько лет. Но время идёт, а потеря то, вот она. Мы теперь хотим, чтобы и классификация, и даёшь нам точность человека.
Начинаем решать задачу перекрытия оставшегося скопа заявок. Помним, что это примерно 30%.

Итак, их основные проблемы:

  1. Запросы прямых пользователей без структуры описания.
  2. Новые типы запросов требуют времени на описание.
  3. Запросы, похожие на другие, в классификаторе едут не в ту команду…

Уже становится понятно, куда клонится наш рассказ? Итак, время идёт, а LEAN не терпит издержек…

Итак, суть проблемы


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

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

 «Бесконечно можно смотреть на то, как течёт вода, горит огонь, и другие работают…» - неизвестный мне автор. 

Начинаем штурмовать новые высоты с использование шторма. Brainstorm очень полезный инструмент, метод 5W усиливает шторм до бури! И что же мы нарешали:

Наши исходные проблемы:

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

Какие предложения по решению:

  1. Надо, чтобы машина могла принять решение по качеству предложенного варианта.
  2. Решение должно самообучаться с минимальными затратами.
  3. Поддержка решения в остальном не отличается по стоимости от предыдущего решения.

Начинаем перебирать варианты.

Из технологий можно подумать о статистической аналитике с элементами BI. Дорого, да и зачем тут монстра с элементами ERP? Проблемы то похожи на задачи, решаемые «искусственным интеллектом» и механизмами «машинного обучения». Ну что же, наш отдел оптимизации, не сомневаясь в успехе, на следующую встречу позвал ребят из отдела диджитал-решений.

Решаем проблему


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







Ещё через месяц мы состыковали нашу ITSM и «Искусственный интеллект» и закончили тестирование.

В итоге: нам совсем не нужны координаторы запросов, так как робот сейчас обрабатывает 99% всех инцидентов и для оставшихся 10-15 инцидентов в день не создают негативное ощущение рутины. Команда довольна, не отвлекаясь от основных задач, сотрудники получили устранение рутины, просто заявив, что этот «архаичный инструмент» уже устарел и мешает работать.

Вывод


Совместное с командой постоянное наблюдение за своими процессами несёт неоценимую пользу. Не только позволяя находить издержки и устранять их, а также формировать понимание и потребность в использовании новых технологий. Решая задачи устранения даже минимальных по значимости, но полностью рутинных проблем, мы действительно создаём ценность. И ценность не только для заказчика, но и для сотрудников и компании.
ICL Services
Цифровые технологии для бизнеса

Комментарии 1

    +2
    Так как вы говорите от 70% к 99% процентам перешли?
    Что-то сделали непонятное? Или изначально просто плохо решили задачу? Метки классов не соответствовали реальному делению задач по отделам, поменяли метки?
    Что за три таблички без подписей?
    Вон у вас ошибки, где Monitoring и Backup путаются. Что вы с ними сделали?
    При чём здесь статистическая аналитика, BI и диджитал? Тема, как влияет то, кого позвать на помощь, не раскрыта.
    Да и не верю я, что эту задачу можно решить на 10k заявок с такой точностью. У меня точность выше 0.91 не поднималась на топ-метках при решении аналогичной задачи с заранее заданными метками и произвольными текстами.
    Что-то темните вы, мне кажется, или просто вместо валидационной выборки померили точность системы на трейнсете под предлогом того, что система теперь у вас «самообучаемая».

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

    Самое читаемое