Счёт на $3 000 перекладывали друг другу, как горячую картошку. Он мог до двух недель лежать неотправленным, а из этих денег собирались платить перевозчику, который требует оплату сразу. Из-за таких счетов могла зависнуть треть недельной выручки, и деньги на долг приходилось срочно искать.
При этом сам счёт делался за несколько минут. Если смотреть только на время операции, не видно ни проблемы, ни пользы от её решения. С внедрениями так же. Перед стартом владелец задаёт один вопрос: сколько я на этом заработаю? Если ответ сразу не виден, внедрение откладывают или не начинают вовсе.
Для одних внедрений это правильный вопрос, для других нет. У многих полезных внедрений выгода не видна, если мерить их не тем или смотреть на них по отдельности. А иногда решение, которое делает почти всё, проигрывает старой ручной схеме, хотя каждая сделанная часть работает.
Я Дмитрий, операционный архитектор: проектирую, как в бизнесе ходят заявки, деньги и люди. Около двух лет работал с кросс-бордер сервисом, который возит грузы между странами. Ниже примеры из бизнесов клиентов и простой способ понять, что можно оценивать отдельно, а что только вместе.
Отдельно можно оценивать только один тип внедрений
Я делю внедрения на три типа: точечное улучшение, инфраструктура и звено цепочки. Тип понятен по двум вопросам. Задавайте их про само изменение и по порядку. Первый: что сломается, если убрать это изменение и вернуть как было? Если многое, это инфраструктура. Если нет, второй: от чего оно зависит? Если только от того, что уже есть, это точечное улучшение. Если от того, что ещё надо достроить, это звено цепочки.
Точечное улучшение. Работает на том, что уже есть. Убрал, и пропало только оно.
Инфраструктура. От неё зависят другие. Убрал, и ломается многое. Сама денег не приносит.
Звено цепочки. Даёт результат, ради которого его делали, только когда достроены другие части.
Термин «инфраструктура» взят из классификации IT-вложений Питера Уэйлла (MIT).
На вопрос «сколько я на этом заработаю?» честно отвечает только точечное улучшение, если мерить правильно. Инфраструктура и звенья цепочки работают в связке с другими частями, и их польза видна только у целого.
Инвойс, который по минутам ничего не экономил
В кросс-бордер сервисе, с которым я работал, инвойсы были исключением из основного процесса. Их выставляли только компаниям, остальные клиенты просто платили переводом. По инвойсу проходили крупные суммы, $1 000–3 000. Улучшать его не брались: в основной процесс он не входил. Первую версию собрали на скорую руку: шаблон в Google-таблице, оформленный как бланк. Инструмент работал, но был неудобным: выбивал из рабочего ритма, а заполнять его умел только узкий круг сотрудников, причём не всегда те, кто вёл эти грузы. Поэтому счёт откладывали и передавали друг другу. Он мог висеть от 3 до 14 дней, пока клиент сам не напомнит.
В логистике задержка счёта бьёт дважды. Счёт можно выставить, только когда груз пришёл и его замерили. Пока счёта нет, клиент не платит, а груз ждёт отправки, она раз в неделю. А другому перевозчику платить нужно сразу, и рассчитывали как раз на эти деньги. Средний счёт около $2 000, в неделю их от 2 до 4, а выручка компании около $20 000 в неделю. Если задерживались 3–4 счёта, зависала примерно треть недельной выручки. Бывало это не каждую неделю, но тогда приходилось срочно трясти клиентов или занимать.
Я переделал инвойс дважды. Сначала добавил к шаблону формулы и меню. Потом вынес инвойс на отдельный сайт: шаблон настраивается, а данные клиента подтягиваются из amoCRM или из списка на сайте. Заполнять стало удобно, ошибиться сложнее, и перекладывать счёт друг на друга перестали. Теперь его может выставить даже новичок. Делается он по-прежнему за 3–5 минут, но уходит в тот же день. Срочно искать деньги для перевозчика ещё приходится, но реже.
Так выглядит точечное улучшение, и для исключений вроде этого оно подходит лучше всего. Пройдём по тесту. Убери новую форму, и ничего не сломается: вернётся старая, и процесс просто снова станет медленным. Зависит она только от того, что уже было, достраивать ничего не пришлось. Польза видна во времени людей вокруг счёта: его больше не перекладывают, а деньги для перевозчика ищут реже. Отсюда и деньги, и сроки доставки. По минутам операции её не разглядеть.
Запись в CRM, которая сама ничего не продаёт
Инфраструктурой может быть и совсем небольшая вещь. Пример из того же кросс-бордер сервиса. Я внедрил в amoCRM простую вещь: когда сделка впервые попадает на новый этап воронки продаж, в ней фиксируются дата и время. Встроенная история этапов была слишком жёсткой для отчётов по управлению и финансам.
Сама по себе эта запись ничего не продаёт. Но она стала основой для учёта. По датам находят просроченные оплаты и проблемные сделки на этапе производства. Появилась статистика конверсии, то есть сколько сделок доходит до следующего этапа. До этого ориентировались примерно и только в моменте. Убери эту запись, и вместе с ней исчезнут контроль просрочек, отчёты и статистика по воронке.
Деньги инфраструктуры лежат в том, что на ней строится дальше: в учёте, аналитике и решениях. По её собственной прибыли её не оценить.
Одна кнопка перевесила всё остальное
Ивент-проект клиента в Тбилиси: около 100 билетов на каждый ивент, средний билет 60 лари (около $23). Моя команда сделала для организатора ИИ-консьержа: он отвечал покупателям в стиле мероприятия, продавал и присылал билеты с дизайном.
Не было одного: эквайринга с API, чтобы оплата сама подтверждала билет. Один банк отказал, а другие, куда мы обращались, давали эквайринг только без API. Поэтому на время сделали ручное подтверждение: покупатель платил, чек приходил организатору в Telegram-бот, и он жал «Подтвердить», чтобы человек получил билет. За три ивента это около 300 подтверждений, и каждое нужно было сделать сразу, как пришла оплата. Через одну кнопку прошло около 18 000 лари (примерно $6 900) продаж.
После третьего ивента организатор сказал прямо: раз всё равно нужно следить за оплатами, смысл теряется. И вернулся к продаже в личке. Его логика понятна: если всё равно надо куда-то заходить, проще работать в привычном интерфейсе.
Звено цепочки здесь консьерж. Пройдём по тесту. Убрали его, и ничего не сломалось: организатор просто вернулся в личку. А результат консьержа зависел от того, чего ещё не было, от эквайринга. Без него цепочка от вопроса до билета не замыкалась, и работа с организатора так и не снималась. Цену ручного шага мы понимали и запустились осознанно, потому что параллельно проверяли остальные части. Они сработали, и незакрытой осталась только оплата. Этого хватило, чтобы решение не прижилось, и масштабировать его мы не стали.
На нажатие кнопки уходит пять секунд. Но пять секунд всё равно не ноль. Пока человек должен хоть пять секунд в день смотреть в процесс, он в нём: помнит, проверяет и не может уйти.
Ещё в 1983 году психолог Лизанна Бейнбридж в работе «Ирония автоматизации» заметила: когда процесс автоматизируют, человеку остаются задачи, которые не получилось автоматизировать. Среди них изматывающее наблюдение за системой.
В инвойсе человек тоже остался. Но там сотрудник делает счёт в рабочее время, это часть его работы. Здесь человек должен дежурить: оплата может прийти в любой момент, а покупатель ждёт билет.
Организатор оценивал целое, и здесь это было правильно. Незамкнутая цепочка оказалась хуже ручной продажи в личке: она обещала забрать процесс, а человек всё равно оставался внутри.
Целое ведёт себя иначе, чем части
Запись в CRM и консьерж показывают одно свойство систем. Его называют эмерджентностью: у целого появляются свойства, которых нет ни у одной из его частей.
Системный мыслитель Расселл Акофф объяснял это на машинах. Возьмите лучший двигатель, лучшие тормоза и другие лучшие детали от разных моделей, и рабочая машина из них не соберётся. Улучшать связанные части по отдельности бесполезно. Точечное улучшение, как с инвойсом, можно сделать и отдельно.
Экономист Пол Дэвид разобрал, как фабрики переходили на электричество. Сначала паровую машину просто заменили одним большим электромотором, а силу к станкам по-прежнему несли валы и ремни. Выигрыш был минимальным. Производительность выросла, когда на каждый станок поставили свой мотор и перестроили весь цех. Новый мотор стал полезным только вместе с новой системой вокруг него.
Недостроенная цепочка тихо съедает маржу
Незамкнутая цепочка может и не развалиться, как у организатора. Тогда она тихо съедает деньги. В службе доставки в Тбилиси приём заказов автоматизировали через мини-приложение и панель управления, а передачу заказов дальше оставили ручной. Каждое решение по отдельности выглядело разумным. Но в итоге на заказ уходило около $4,4 ручной работы при марже до $4,6.
Главная мерка: время людей
Под всеми тремя типами лежит одна мерка: время людей. Человек нужен там, где процесс не стандартизирован: его не автоматизировали или автоматизировать нельзя. Такое место всегда хрупкое. Чем меньше в процессе таких мест, тем он эффективнее.
Отсюда простое правило:
Основной процесс доводите до конца. Недостроенная цепочка оставляет человека внутри и проигрывает старой схеме.
Исключения закрывайте точечно, как инвойс. Такое улучшение даёт пользу сразу, достраивать ничего не надо.
Инфраструктуру оценивайте по тому, что на ней построят.
Как проверить у себя
Выпишите, что вы внедрили за последний год и что собираетесь внедрять. Каждому задайте два вопроса: что сломается, если его убрать, и от чего оно зависит.
Считайте время людей вокруг операции: напоминания, поиски денег, дежурства. Минуты самой операции могут не показать ничего, как с инвойсами.
В каждой цепочке найдите человека, который должен «просто нажать кнопку» в любой момент. Пока он там стоит, цепочка не замкнута.
Если цепочку можно замкнуть, достраивайте. Если пока нельзя, честнее остановиться, как сделал организатор. Если не замкнули и не бросили, посчитайте, сколько стоит ручной шаг: в службе доставки он съедал $4,4 из $4,6 маржи.
