Портфельный аудит скрытой ручной работы в командах стартапов

Почему ручная работа прячется на виду

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

Команды делают так по простой причине: костыль работает. Таблица закрывает дыру. Сообщение в чате дает ответ быстрее, чем переделка workflow. Память дополняет то, что ни одна система не записывает.

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

На неделю или две это решение кажется разумным. Потом оно превращается в привычку.

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

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

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

Простой пример делает проблему очевидной. Стартап получает нового клиента. Кто-то переносит форму в CRM, отправляет приветственное письмо, обновляет трекер онбординга, пишет в чат продуктовой команде и вручную проверяет биллинг. При десяти клиентах в месяц это кажется посильным. При пятидесяти тот же процесс съедает часы каждую неделю.

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

На что акселератору смотреть в первую очередь

Начните с работы, которая двигает данные, а не решения. Первый вопрос простой: где кто-то копирует одну и ту же информацию из одного инструмента в другой?

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

В первую очередь стоит смотреть на скучные, но частые процессы, которые влияют на выручку, деньги или отчетность:

• онбординг клиентов
• обновления в sales pipeline
• выставление счетов и напоминания об оплате
• внутренние отчеты для основателей и инвесторов

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

Ищите человеческий костыль внутри системы. Во многих стартапах есть один человек, который всегда вручную чистит записи, склеивает дубликаты, исправляет детали счетов или обновляет отчет до того, как его увидит руководство. На первый взгляд он выглядит эффективным, но часто он просто закрывает собой сломанный workflow.

Помогает простой вопрос: «Если бы этот человек ушел в отпуск на неделю, что бы перестало двигаться?» Ответ обычно прямо указывает на самую дорогую ручную работу.

Важно и время. Некоторые задачи кажутся терпимыми в обычную неделю, а потом взрываются в конце месяца или прямо перед отчетом для инвесторов. Этот пик — полезное доказательство. Он показывает, что команда имеет дело не со случайным бардаком, а с повторяющимся процессом, который не выдерживает нагрузки.

Представьте стартап, который ведет сделки в sales tool, отправляет детали онбординга по почте и создает счета в бухгалтерской системе. Каждую пятницу операционный менеджер тратит часы, сверяя названия компаний, условия контрактов и даты выставления счетов между всеми тремя системами. Никто не называет это проблемой процесса, потому что работа все равно делается. Но это именно проблема процесса.

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

Как провести аудит

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

Выберите процесс, который затрагивает деньги, клиентов или delivery. Хорошие примеры — обработка лидов, онбординг клиентов, подготовка счетов, эскалации в поддержке или еженедельная отчетность. Если основатель говорит: «Мы делаем это постоянно», — это обычно и есть правильное место для проверки.

Потом проследите работу от первого входа до финального результата. Если приходит новый лид, куда он попадает первым? Кто его читает? Кто копирует? Кто утверждает следующий шаг? Где хранится финальная запись? Продолжайте идти по цепочке, пока работа не будет завершена полностью, а не только до момента, когда ее передали другой команде.

Для каждого процесса зафиксируйте пять вещей:

• что запускает работу
• кто к ней прикасается
• что он делает вручную
• сколько времени это занимает
• как часто это повторяется в обычную неделю

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

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

Потом отметьте шаги, которые повторяются между клиентами, сделками или обращениями в поддержку. Основатель может тратить всего шесть минут на перенос данных из email в CRM, потом в Slack и в шаблон предложения. Это звучит мелко, пока не происходит 40 раз в неделю. Один час превращается в четыре. Четыре — в подработку на полставки.

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

Как распознать паттерны копирования и вставки

Работа по копированию и вставке редко попадает в roadmap. Она проявляется в мелких задержках: основатель смотрит один дашборд, вручную обновляет CRM, потом еще раз отправляет те же цифры в чат или по почте. Такие повторы важны, потому что они съедают время каждую неделю и делают простую работу хрупкой.

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

Некоторые признаки легко не заметить, пока не попросишь людей показать задачу вживую:

• Сотрудник заново вводит те же данные о клиенте или сделке в другое приложение.
• Перед загрузкой люди меняют формат дат, названия столбцов или валюты.
• Обновления приходят в виде скриншотов, а не полей, которые можно сортировать или искать.
• Отчет существует только после того, как кто-то сведет несколько выгрузок в таблице.
• Работа останавливается, когда один человек отсутствует, потому что только он знает все шаги.

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

Ручное изменение формата — еще одна типичная утечка. Если сотрудникам постоянно приходится исправлять CSV-файлы перед импортом, проблема не в таблице. Инструменты не согласованы по структуре, и команда становится тем самым адаптером.

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

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

Как оценить ущерб

Начните с простой математики. Если задача занимает 12 минут, а кто-то делает ее 80 раз в неделю, это 960 минут, или 16 часов. Большинство команд занижают оценку, поэтому лучше попросить их засечь реальный проход, а не называть приблизительное число.

Потом привяжите к этому времени стоимость. Смотрите не только на длительность, но и на то, кто делает работу. Десять часов времени основателя, инженера или sales lead стоят дороже, чем десять часов административной роли, потому что они еще и отнимают время у работы, которая двигает выручку или продукт.

Простой scorecard для каждой повторяющейся задачи должен включать:

• минут на один проход
• проходов в неделю
• кто это делает
• почасовую стоимость этого человека
• что ломается, если задача идет не так

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

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

Самая быстрая проверка — нагрузка объемом. Задайте один вопрос: что будет, если в следующем квартале этот стартап удвоит объем? Если ответ: «Мы наймем еще одного человека, чтобы успевать», — у задачи уже есть проблема масштаба. Если ответ: «Ничего не изменится, потому что шаг занимает минуту и почти не ломается», — проблема небольшая.

Допустим, у одной компании из портфеля customer success manager вручную копирует данные заказа в три системы. На один заказ уходит 18 минут, и это происходит 50 раз в неделю. Это 15 часов. При ставке $45 в час прямые затраты составляют $675 в неделю еще до исправления ошибок. Удвоение объема заказов превращает это в 30 часов потерь в неделю на работу, за которую клиенты не платят дополнительно.

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

Простой пример из портфеля

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

Представьте небольшую sales-команду. Лид заполняет форму на сайте. Кто-то из продаж открывает ответ и копирует имя, компанию, email и детали сделки в CRM. После звонка тот же менеджер пишет заметки в CRM, а потом копирует сводку в общий лист, потому что основатели смотрят его на еженедельных встречах. Когда сделка закрывается, финансы открывают лист и снова вбивают данные клиента в систему выставления счетов.

Поток достаточно простой:

• лид приходит через форму
• продажи заносят те же данные в CRM
• продажи копируют заметки по сделке в общий лист
• финансы заново вводят закрытую сделку в биллинг

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

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

Вот почему акселераторам стоит смотреть на передачи задач, а не только на инструменты. У стартапа могут быть CRM, общий лист и биллинг, но он все равно будет жить на ручном перемещении данных, которое бьет по марже. Проблема не в количестве приложений. Проблема в том, что каждая продажа зависит от людей, которые вручную переносят одни и те же данные, прежде чем деньги попадут в банк.

Ошибки, которые скрывают настоящую проблему

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

Аудит должен следовать за задачей, а не за приложением. Если sales assistant вытаскивает имена из письма, вставляет их в CRM, а потом обновляет таблицу для финансов, проблема не в том, что команда использует три инструмента. Проблема в паттерне передачи.

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

Основатель может сказать: «Данные по лидам автоматически попадают в CRM». Координатор покажет другую картину: одно поле импортируется неверно, поэтому каждое утро она исправляет 40 записей, прежде чем кто-то сможет звонить этим лидам. Эта ежедневная рутина важнее, чем красивая схема процесса.

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

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

Быстрая проверка помогает держать аудит честным:

• Кто делает эту задачу каждый день?
• Что копируется из одного места в другое?
• Как часто кто-то ждет ответа или файла?
• Что ломается, если этого человека нет?
• Сколько минут команда тратит на это каждую неделю?

Еще одна ловушка: команды сначала исправляют отчеты, потому что руководители видят именно отчеты. Отчеты кажутся срочными, но они редко съедают маржу так быстро, как обработка заказов, сортировка обращений в поддержку, проверки счетов или маршрутизация лидов. Если ежедневные операции все еще теряют время, более красивый отчет мало что изменит.

Полезный аудит держится близко к реальной работе. Он смотрит на настоящие задачи, считает повторения и ранжирует исправления по стоимости.

Быстрые проверки для каждого стартапа

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

Несколько проверок обычно снова и снова вскрывают одни и те же слабые места:

• Если одно действие клиента создает работу в двух или трех инструментах, спросите, зачем вообще существует такое разделение.
• Смотрите на перепечатку. Если имя клиента, тариф, адрес или номер счета уже существует, никто не должен вводить это вручную снова.
• Посмотрите на работу в конце месяца. Если один человек закрывает биллинг, payroll или отчеты для партнеров, потому что «только он знает как», процесс хрупкий.
• Спросите, когда всплывают ошибки. Если команда замечает проблемы только после отправки счетов или отчетов, у нее нет раннего предупреждения.
• Проверьте, как они объясняют workflow. Если им нужно открыть пять вкладок, чтобы просто описать простой путь, работа размазана по слишком многим местам.

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

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

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

Что делать после аудита

Аудит окупается только тогда, когда команда быстро меняет один процесс. Начните с workflow, который происходит каждый день, отнимает больше всего времени у сотрудников и больше всего раздражает людей. Хорошие первые цели — передача лидов, проверки счетов, сортировка обращений в поддержку, еженедельная отчетность и ручной перенос данных клиентов между инструментами.

Не покупайте новое приложение в первый же день. Многие команды добавляют софт до того, как уберут грязную передачу задач, и это просто закрепляет потери на месте. Если sales копирует заметки в таблицу, а ops копирует те же заметки в CRM, сначала исправьте этот путь. Одна убранная передача задач может сэкономить больше времени, чем новая подписка.

Первый тест держите маленьким и понятным:

• выберите процесс с ясным объемом, например 50 тикетов в поддержку или 200 обновлений заказов в неделю
• измените только один шаг, например автозаполнение поля или прямую отправку данных в следующий инструмент
• запустите тест на две недели
• отслеживайте сэкономленные часы, процент ошибок и cycle time
• спросите людей, которые работают руками, стало ли им проще

Простых цифр достаточно. Если стартап экономит 6 часов в неделю на одной административной задаче, это больше 300 часов в год благодаря одному исправлению. Это тот самый эффект, который улучшает маржу без большого перестроения компании.

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

Некоторым стартапам нужен взгляд со стороны, потому что основатели слишком близко к рутине, или команда считает плохой обходной путь нормой. В таких случаях Олег Сотников на oleg.is может подключиться как Fractional CTO, посмотреть на workflow и помочь спланировать практичную автоматизацию без превращения этого в большой софт-проект.

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