Как идут бизнес-процессы в компании на самом деле

Задача

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

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

Инструмент, который это показывает, существует давно и называется процессной аналитикой. Мешало ему одно: подготовка данных. Чтобы посчитать процесс, аналитику надо руками собрать журнал событий – найти сквозной идентификатор заявки, вытащить длительности, посчитать вероятности развилок, свести ресурсы. Это 60–80% трудозатрат проекта и недели работы. Именно поэтому такие расчёты жили в крупной промышленности, а не в отделе, где обрабатывают заявки.

Я убрал этот шаг.

Что я сделал

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

Дальше работает связка из двух непохожих частей. Флот ИИ-агентов изучает структуру базы и выдвигает гипотезы: вот эта колонка похожа на идентификатор заявки, вот эта – на шаг процесса, вот эта – на время, вот эта – на исполнителя. А проверяет каждую гипотезу обычный SQL по полному объёму данных.

Проверял всё это не на клиентских данных, а на открытом отраслевом журнале управления инцидентами – это выгрузка из реальной ИТ-компании, опубликованная в репозитории UCI: 141 712 событий, 24 918 заявок, 36 колонок с пропусками и датами в неудобном формате. Никакой подготовки я не делал сознательно – хотел проверить, справится ли система с чужой базой, которую видит впервые.

Агенты предполагают, SQL проверяет

Это главная механика, и она же ответ на вопрос «а вы не выдумываете ли».

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

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

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

Как это работает по шагам

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

Что нашлось в чужом журнале за два часа

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

Самая дорогая находка – первая. Переход «решена» → «закрыта» занимает в среднем 147 часов, и так на всех 24 916 заявках. Проблема устранена, инженер свободен, клиент доволен – а заявка ещё шесть суток числится открытой. При среднем времени жизни заявки в 315 часов это почти половина её срока, в которую никто не работает.

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

Что будет, если

Дальше начинается то, чего не умеет ни один дашборд. Восстановленная модель уходит в симулятор, и его сначала надо проверить на честность: прогнать «как есть» и сравнить с фактом. Расчётное среднее время жизни заявки вышло 315,4 часа против 315,2 фактических. После такого совпадения сценариям можно верить.

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

Никого не пришлось нанимать. Ничего не пришлось внедрять. И, что важнее, это стало известно до того, как компания потратила квартал на неправильное улучшение.

Где здесь деньги

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

На этом журнале это выглядит так. Заявок за год 24 918, срок нарушен у 36,6% – это 9 120 нарушений. Если по договору обслуживания каждое стоит компании 500 рублей скидки или штрафа, получается 4,6 млн рублей в год, и это только та часть, которую видно в договоре. Ставку подставляет заказчик – я её не выдумываю и в отчёте всегда помечаю как допущение.

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

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

Чего эти данные НЕ позволяют

Отдельный раздел, и он для меня важнее, чем результаты выше.

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

Я мог бы выдать красивое «плюс один сотрудник даст минус 15% ко времени» – проверить это никто бы не смог. Но это была бы выдуманная цифра, а выдуманная цифра в расчёте, под который нанимают людей, дороже, чем отсутствие расчёта.

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

Стек

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

Грабли, на которые уже наступил

Форма данных важнее их размера. К названиям колонок система нечувствительна – хоть number, хоть _Reference114 из 1С, роль определяется по поведению значений, а не по имени. А вот форма решает: журнал событий разбирается сразу, а таблица, где этапы лежат отдельными колонками с датами, требует предварительного разворота.

Сначала проверить, ведут ли систему честно. Если стадии двигают задним числом, а половину сделок закрывают руками в конце месяца – журнал будет мусорным, и любые выводы из него тоже. Проверяется это за час, до всякой аналитики. Кстати, сам такой вывод – «40% ваших сделок не отражены в системе» – обычно стоит дороже, чем то, за чем изначально приходили.

Красивая схема без проверки соответствия – это картинка. Пока не измерено, какая доля заявок реально проходит по нарисованной модели, показывать её нельзя. У меня вышло 91,6%, и это хороший результат для чужих данных без единой ручной правки.

Вопросы и ответы