CTO перед покупкой автоматизации: сначала закройте пробелы в процессах

Почему больше софта не чинит грязный процесс

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

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

Когда у задачи нет владельца, лишняя работа появляется очень быстро. Один человек заводит запрос, другой его правит, а третий снова спрашивает те же детали, потому что дальше никто не отвечает. Команды называют это «ручной работой», но большая ее часть на самом деле — «неясная работа». Люди переделывают задачи, потому что процесс так и не объяснил, кто принимает решение, кто проверяет и кто закрывает цикл.

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

Если эти правила размыты, новая платформа только ускоряет путаницу.

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

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

Хороший CTO начинает именно с этого. Где работа переходит из рук в руки? Где правила размыты? Где теряется ответственность? Исправьте это сначала, и выбор инструмента станет проще. Пропустите этот шаг — и даже дорогая автоматизация станет просто более быстрым способом совершать те же ошибки.

Где операционные команды теряют деньги каждую неделю

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

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

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

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

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

Утечка обычно проявляется в нескольких местах:

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

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

Как понять, что проблема в процессе, а не в инструменте

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

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

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

Что проверить за обычную рабочую неделю

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

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

Новая платформа редко чинит это сама по себе. Чаще она просто прячет беспорядок на месяц, а потом те же задержки возвращаются уже в более красивом дашборде.

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

Разберите один процесс от запроса до результата

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

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

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

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

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

Согласования требуют особого внимания. Запишите каждое согласование, кто его дает и по какому правилу. Затем перечислите все исключения. Если заказы до $500 не идут в финансы, так и напишите. Если срочные запросы перепрыгивают очередь, тоже напишите это. Размытые правила создают задержки, потому что люди останавливаются, чтобы спросить, а потом спрашивают еще раз.

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

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

Простой пример: согласование счетов, которое все время стопорится

Поставщик присылает счет на $8,400 в понедельник утром. Accounts payable заносит его в систему тем же днем и отправляет на согласование. Срок оплаты — 14 дней, так что отсчет начинается сразу.

Первая задержка вообще не связана с софтом. Никто не прописал лимиты согласования достаточно ясно. Руководитель отдела думает, что может утверждать до $5,000. Финансы считают, что руководители направлений могут утверждать до $10,000. Счет попадает в ее очередь, она сомневается, и команда теряет день, пока все выясняют, кто принимает решение.

К среде она пересылает счет финансовому директору. Он в поездке. Он видит запрос только поздно вечером, а запасного согласующего нет. Accounts payable отправляет напоминания, а потом снова ждет. К пятнице счет пропускает еженедельный платежный прогон.

Теперь ущерб проявляется в мелких, но дорогих деталях. Поставщик присылает уточнение. Команда тратит 20 минут, проверяя статус в почте и чате. Финансы могут потерять скидку за раннюю оплату или заплатить штраф за просрочку. И все это произошло не потому, что инструмент тормозил. Это случилось потому, что правила были размыты.

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

Несколько небольших исправлений быстро меняют результат:

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

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

Чаще всего дешевле изменить правило, а не покупать еще одну подписку.

Что делает CTO до сравнения платформ

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

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

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

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

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

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

Перед сравнением платформ команде нужна простая таблица оценки:

• стоимость одного процесса или одного запроса
• среднее время от запроса до результата
• процент ошибок, переделок или пропущенных передач

Такая таблица не дает выбору инструмента превратиться в спор мнений. Она также делает маленькие победы очевидными. Именно за такой работой известен Oleg Sotnikov: сначала сокращать потери, затем делать ответственность ясной, а уже потом выбирать инструменты, которые подходят процессу, а не заставляют процесс подстраиваться под инструмент.

Частые ошибки, когда команды выбирают автоматизацию

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

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

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

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

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

Ранние признаки обычно такие:

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

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

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

Быстрые проверки перед тем, как одобрить новую платформу

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

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

Проверьте один процесс, который вызывает больше всего повторяющейся боли:

• Попросите одного человека вслух объяснить каждый шаг. Если ему нужны еще три человека, чтобы заполнить пробелы, процесс до сих пор живет в головах.
• Назначьте у каждого шага одного владельца. Совместная ответственность звучит красиво, но застрявшая работа обычно лежит там, где никто не чувствует полной ответственности.
• Запишите правила исключений. Обычные случаи обычно проходят нормально. Просроченные счета, недостающие поля, срочные запросы и дубли съедают время.
• Выберите один источник истины. Если продажи доверяют таблице, финансы — ERP, а поддержка — почте, платформа только быстрее воспроизведет путаницу.
• Сразу скажите, что платформа не решит. Инструмент не исправит неясные лимиты согласования, слабые привычки работы с данными или споры о политике.

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

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

Что делать дальше, если команда застряла

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

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

Прежде чем назначать звонки с вендорами, разберите процесс простыми словами. Кто запускает работу? Кто отвечает за каждую передачу? Какое правило решает — да, нет или эскалация? Какие исключения снова и снова ломают поток? Команды часто приходят к одному и тому же неприятному выводу: инструмент — не главная проблема. Правила размыты, ответственность поделена, и никто не договорился об edge cases.

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

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

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

Если команда слишком близко к проблеме, помогает внешний разбор. Oleg Sotnikov на oleg.is консультирует стартапы и небольшие компании по проектированию процессов, архитектуре, инфраструктуре и практичному внедрению AI. Иногда ответ — легкая автоматизация. Иногда — изменение политики. Иногда действительно нужна новая система, но к этому решению лучше прийти с гораздо более ясным пониманием настоящей проблемы.