Консалтинг по автоматизации: как построить успешную стратегию
Почему «давайте что-нибудь автоматизируем» - это не стратегия
Многие проекты автоматизации начинаются одинаково: кто-то побывал на конференции, увидел демо и вернулся убеждённым, что бизнесу нужен чат-бот, новая интеграция с CRM или любой другой инструмент, который произвёл впечатление на той неделе. Через полгода в компании работают три инструмента, ни один из них не связан с другими, а команда тратит на сверку данных вручную больше времени, чем раньше, а не меньше. Это не провал технологии. Это то, что происходит, когда автоматизацию воспринимают как покупку, а не как решение о том, где бизнес реально теряет время или деньги. Небольшая физиотерапевтическая клиника, которая покупает красивый онлайн-сервис для записи только потому, что он есть у конкурента, не проверив сначала, действительно ли узкое место - это запись, а не бумажная работа после каждого сеанса, обычно получает более симпатичный календарь и ту же кучу неразобранных карточек с записями о лечении, что была и раньше.
Начинать с узкого места, а не с инструмента
Настоящая стратегия начинается с того, чтобы назвать конкретную точку, где скапливается работа или клиенты ждут слишком долго, и только после этого спрашивать, что могло бы это исправить. Для небольшой бухгалтерской фирмы это может быть неделя перед сдачей отчётности, когда с каждого клиента вручную приходится выбивать одни и те же документы. Для агентства недвижимости это может быть разрыв между тем, как лид заполнил форму, и тем, когда ему реально перезвонили - разрыв, который нередко решает, превратится ли лид в клиента вообще. Назвать узкое место первым делом значит, что инструмент подбирают под проблему, а не подгоняют проблему под инструмент, который уже купили. Небольшая юридическая фирма может обнаружить, только после того как реально расписала процесс на бумаге, что настоящее узкое место у неё вовсе не приём заявок, а передача дела между юристом, который ведёт первую встречу, и помощником, который готовит папку, - шаг, который целиком идёт по почте и теряется каждый раз, когда кто-то в отпуске.
Порядок: что автоматизировать первым, вторым, третьим
Даже имея чёткий список узких мест, попытка исправить их все разом обычно означает, что ни одно из них не будет исправлено толком. Рабочий порядок обычно начинается с того, что дешевле всего исправить и заметнее всего клиентам, потому что ранние победы создают доверие внутри команды, необходимое для более крупных изменений позже. После этого идёт процесс, который дороже всего обходится в рабочих часах сотрудников, даже если клиенты его никогда не видят напрямую - например, сверка счетов или обновление записей между системами. Самые сложные и самые «политические» изменения, которые затрагивают несколько отделов или требуют пересмотра того, кто за что отвечает, оставляют напоследок, когда команда уже увидела, что автоматизация работает на более простых вещах, и начинает доверять подходу. Такой порядок важен ещё и потому, что доверие, однажды подорванное амбициозным первым проектом, который забуксовал, восстанавливать дорого, а команда, видевшая, как один переусложнённый запуск провалился, будет намного скептичнее в следующий раз, когда кто-то предложит автоматизировать хоть что-нибудь.
Вопросы про бюджет и ответственность, которые обычно пропускают
Два вопроса губят больше проектов автоматизации, чем любое техническое ограничение: кто будет отвечать за workflow после того, как его построят, и что произойдёт, когда через полгода его понадобится изменить. Workflow без чёткого владельца обычно тихо перестаёт работать в первый же раз, когда поставщик меняет формат данных или увольняется сотрудник, и никто этого не замечает, пока не пожалуется клиент. Разговоры о бюджете обычно фокусируются только на стоимости покупки инструмента и упускают постоянные расходы на то, чтобы кто-то его поддерживал, проверял, что он всё ещё срабатывает правильно, и подстраивал под изменения в бизнесе. Стратегия, которая пропускает эти вопросы на бумаге, отвечает на них плохо на практике - обычно в разгар кризиса. Полезно явно зафиксировать ответ, пусть даже одной строкой в общем документе: этот workflow принадлежит вот этому человеку, и он пересматривается примерно с такой-то периодичностью, потому что незаписанное предположение об ответственности обычно испаряется в тот момент, когда человек, на которого все рассчитывали, уходит в отпуск.
Как измерять результат без выдуманных цифр
Соблазнительно описывать крупный проект автоматизации в терминах сэкономленных часов или роста эффективности, но эти цифры чаще угадывают, чем измеряют, а угаданные цифры теряют доверие в первую же секунду, когда кто-то спрашивает, как их посчитали. Более честный подход - привязать измерение к тому, что бизнес уже и так отслеживает: сколько времени занимал ответ на лид до и после, сколько ручных исправлений требовал процесс в прошлом квартале по сравнению с этим, сколько обращений в поддержку упоминают одну и ту же повторяющуюся жалобу. Эти цифры скромнее и не так эффектны, как громкое «на 40% эффективнее», но они выдерживают проверку, когда кто-то решает их пересчитать, и честно показывают, сработало ли изменение на самом деле. Полезно также решить, какими будут эти цифры, ещё до начала проекта, а не после, потому что метрика, выбранная задним числом, имеет обыкновение оказаться именно той, которая случайно выглядит красиво.
Когда звать подрядчика, а когда делать самим
Не каждому бизнесу нужен консультант, чтобы автоматизировать подтверждение записи, и не каждому бизнесу стоит в одиночку проектировать workflow, затрагивающий несколько систем, без стороннего взгляда. Честная граница обычно проходит по сложности и по тому, сколько поставлено на карту, если что-то сломается: соединить два хорошо задокументированных инструмента с готовой интеграцией часто вполне по силам собственной команде, а вот всё, что затрагивает данные клиентов сразу в нескольких системах, или всё, где ошибка означает проблему с комплаенсом, выигрывает от участия того, кто уже наступал на эти грабли в другом месте и знает, где они спрятаны. В любом случае вопрос стратегии идёт раньше вопроса подрядчика. Решить, что чинить и в каком порядке - это работа, которую бизнес должен проделать сам, независимо от того, кто в итоге будет строить сам workflow. Передать это первое решение подрядчику, вместо того чтобы принять его ещё до разговора с подрядчиком, - один из самых частых способов получить в итоге инструмент, который решает любимую проблему подрядчика, а не собственную проблему бизнеса.
Почему стратегию нужно пересматривать, а не просто написать один раз
Документ со стратегией, который написали один раз, утвердили и больше никогда не открывали, стареет так же, как старая оргструктура - незаметно, и его вспоминают только когда кто-то случайно на него натыкается в поисках чего-то другого. Бизнес, который вырос с трёх сотрудников до двенадцати, открыл вторую точку или начал продавать через новый канал, меняет форму собственных узких мест, и workflow, построенный под прошлогоднюю численность команды, может сам стать источником той самой ручной подстройки, которую он должен был устранить. Пересматривать стратегию не обязательно превращать в формальный квартальный ритуал с презентацией - достаточно одного повторяющегося разговора: что сейчас больше всего съедает время, изменилось ли это с прошлого раза, и не нужно ли поправить что-то из того, что автоматизировали год назад, раз бизнес вокруг этого выглядит уже иначе. Отношение к стратегии как к живому, постоянно уточняемому ответу, а не как к документу, написанному один раз, обычно и отличает бизнес, который продолжает получать пользу от автоматизации, от того, который тихо возвращается к ручным костылям, как только исходный workflow перестаёт подходить.