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

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

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

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

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

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

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

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

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

Выберите первый процесс

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

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

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

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

Хороший первый процесс обычно имеет четыре признака:

• Один понятный владелец
• Ежедневный или еженедельный ритм
• Уже ощутимое трение
• Результат, который можно быстро проверить

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

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

Сделайте боль видимой

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

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

Как выглядит видимая боль

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

Помогает короткая проверка:

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

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

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

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

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

Выберите одну метрику успеха

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

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

Запишите базовый уровень до начала разработки. Сделайте это конкретно. «Отдел продаж тратит 75 минут в день на перенос данных о лидах в CRM» — полезно. «Процесс кажется медленным» — нет. Базовый уровень дает реальную точку сравнения и не позволяет командам объявлять успех по памяти.

Для небольших проектов по автоматизации рабочих процессов хорошо подходят такие показатели:

• Время выполнения одной задачи
• Количество ручных передач задач
• Частота ошибок или переделок
• Длина очереди
• Количество дней от запроса до завершения

Задайте короткое окно проверки. Для первого теста часто хватает двух недель, если процесс происходит часто. Короткий срок помогает сохранять честность и ограничивает отговорки. Если за две недели цифра не сдвинулась, доработайте инструмент, сузьте объем или остановитесь.

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

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

Начните с малого в пять шагов

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

1. Опишите текущий процесс на одной странице. Запишите шаги простыми словами. Укажите, кто что делает, где люди ждут и где они дважды копируют одни и те же данные. Если описание не помещается на одной странице, масштаб все еще слишком большой.
2. Сократите объем, пока он не станет почти слишком маленьким. Не нужно перестраивать весь процесс. Выберите минимальное изменение, которое экономит время или убирает одну повторяющуюся ошибку.
3. Делайте только болезненную часть. Если люди тратят время на вопросы о статусе, исправьте статус. Если они перепечатывают одни и те же поля в два инструмента, исправьте это. Остальные идеи оставьте на потом.
4. Сначала протестируйте это с человеком, который владеет процессом. Посидите рядом, пока он использует решение на реальной работе, а не на демонстрации. Посмотрите, где он останавливается, где путается и где возвращается к старому способу.
5. Изучите реальное использование, прежде чем добавлять что-то еще. Через неделю или две проверьте, действительно ли изменение сократило задержки, ручную работу или количество сообщений с уточнениями. Если люди игнорируют инструмент, остановитесь и выясните почему.

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

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

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

Простой пример

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

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

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

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

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

У вас также появляется понятная метрика успеха. Измерьте время согласования до изменений и после них. Если раньше возвраты занимали в среднем 9 часов, а очередь сократила это до 2 часов, результат легко объяснить.

Небольшая команда может протестировать это за неделю. Измерьте среднее время согласования по последним 20–30 запросам, направьте все новые заявки на возврат в одну общую очередь, попросите руководителя поддержки использовать только эту очередь в коротком тесте, а затем снова измерьте то же время согласования через одну или две недели.

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

Ошибки, которые убивают внедрение

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

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

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

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

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

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

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

Следите за несколькими тревожными сигналами:

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

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

Быстрые проверки перед разработкой

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

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

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

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

Прежде чем кто-то начнет писать код, проверьте пять пунктов:

• Есть конкретный человек, который протестирует это в реальной работе, а не только на демонстрации
• Проблема возникает достаточно часто, чтобы решать ее уже сейчас
• Одна простая метрика покажет, помог ли процесс
• У команды есть путь вернуться к старому способу, если инструмент сломается
• Дата проверки уже стоит в календаре

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

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

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

Что делать дальше

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

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

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

Простой план выглядит так:

• Опишите процесс одним предложением
• Назовите человека, который им владеет
• Выберите одну метрику, которая уже важна
• Сделайте только ту часть, которая меняет эту метрику
• Наблюдайте за реальным использованием в течение недели

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

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

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

Если вам нужен второй взгляд перед тем, как команда начнет строить не то, что нужно, Oleg Sotnikov предлагает услуги Fractional CTO и консультации для стартапов через oleg.is. Короткий разбор процесса, владельца и метрики часто помогает удержать масштаб в рамках и избежать недель напрасной работы.