Счёт на $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.

Главная мерка: время людей

Под всеми тремя типами лежит одна мерка: время людей. Человек нужен там, где процесс не стандартизирован: его не автоматизировали или автоматизировать нельзя. Такое место всегда хрупкое. Чем меньше в процессе таких мест, тем он эффективнее.

Отсюда простое правило:

• Основной процесс доводите до конца. Недостроенная цепочка оставляет человека внутри и проигрывает старой схеме.

• Исключения закрывайте точечно, как инвойс. Такое улучшение даёт пользу сразу, достраивать ничего не надо.

• Инфраструктуру оценивайте по тому, что на ней построят.

Как проверить у себя

1. Выпишите, что вы внедрили за последний год и что собираетесь внедрять. Каждому задайте два вопроса: что сломается, если его убрать, и от чего оно зависит.

2. Считайте время людей вокруг операции: напоминания, поиски денег, дежурства. Минуты самой операции могут не показать ничего, как с инвойсами.

3. В каждой цепочке найдите человека, который должен «просто нажать кнопку» в любой момент. Пока он там стоит, цепочка не замкнута.

4. Если цепочку можно замкнуть, достраивайте. Если пока нельзя, честнее остановиться, как сделал организатор. Если не замкнули и не бросили, посчитайте, сколько стоит ручной шаг: в службе доставки он съедал $4,4 из $4,6 маржи.