На столе лежали три правдоподобных варианта, и два из них занимали месяцы. Всё решил выбор: какой записи верить, когда данные расходятся.


Михаил Савченко4 мин
Содержание7 разделов
  1. Что показали замеры
  2. Три варианта
  3. Почему быстрый читатель не спасал
  4. Что изменило выбранное решение
  5. Цена, которой нет ни в одном предложении
  6. Что это дало
  7. Что можно перенести на свой проект

Что показали замеры

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

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

Вариантов было три, и два из них занимали месяцы.

Три варианта

ВариантСрокПочему отвергнут или выбран
Заменить учётную системуМесяцыЧинит одно поле миграцией всего, посреди сезона
Подключить модель к таблицамНеделиБыстрее отвечает по неверным данным, и ответ не отследить
Одна главная запись, реальные состояния3 неделиЧинит именно то, что было сломано

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

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

Почему быстрый читатель не спасал

За этим выбором - общее правило, которое полезно отделить от частностей.

Проверка хороша ровно настолько, насколько верна запись, по которой она идёт. Если запись говорит, что машина недоступна, а та стоит на площадке, любой читатель этой записи, сколь угодно быстрый, повторит ошибку. А клиент, который спросит, почему ему отказали, получит ответ, за которым нет ничего правдивого.

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

Что изменило выбранное решение

Две вещи, и вторая весила больше.

Доступность перестала быть одним полем «да или нет» и стала семью явными состояниями, поэтому машина, вернувшаяся и ждущая осмотра, машина в пути и машина, забронированная без подтверждения, перестали показываться свободными.

Затем одна запись стала главной по тому, что забронировано, а проверка в реальном времени стала срабатывать и в момент подтверждения, а не только в момент заявки. Эта вторая правка и прекратила двойные брони, потому что конфликты возникали между «посмотрел в общую таблицу» и «пообещал машину».

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

Цена, которой нет ни в одном предложении

Если одна запись становится главной, кому-то придётся перестать вести свою копию.

В любом таком операционном отделе есть один-два человека с личной таблицей, и они не вредничают. Они завели её потому, что когда-то официальная система ошиблась, а их таблица оказалась права, и с тех пор бизнес тихо на неё опирался.

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

Что это дало

Путь от брони до отгрузки сократился с 4 часов до 3 минут, двойные брони исчезли. В пиковый сезон та же команда справляется с объёмом в 2,5 раза больше, а внедрение уложилось в 3 недели. Все цифры - на странице кейса.

Три недели - следствие решения, а не скорости работы. Отвергнутые варианты были не медленными версиями того же проекта, а другими проектами, и один из них закончился бы примерно к концу сезона.

Что можно перенести на свой проект

Прежде чем на что-то соглашаться, найдите факт, в котором расходятся две ваши системы, и решите, какой из них верить.

Такое решение ничего не стоит, занимает полдня и определяет размер каждого следующего проекта. Замер, который его вскрывает, описан в посте неделя до, и по той же причине противоречивые данные - единственный вид беспорядка, в обход которого не стоит автоматизировать, пока у вопроса нет ответа.

Часто задаваемые вопросы

  • Почему не поменять учётную систему, раз проблема была в модели данных?

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

  • Чем плох вариант с языковой моделью на существующих таблицах?

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

  • Что конкретно изменило выбранное решение?

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

  • Чего это решение стоило?

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

Case StudyOperationsEquipment RentalMethodology