Большинство технологических бюджетов строится вокруг того, что видят клиенты: сайт, процесс бронирования, приложение. А вот что почти никогда не получает отдельную строку — это софт, на котором держится бизнес изнутри: таблица, отслеживающая склад, общий документ, выполняющий роль трекера задач, чат в мессенджере, заменяющий процесс согласования. Эти внутренние инструменты невидимы для клиентов, и именно поэтому годами остаются без финансирования, даже когда тихо обходятся бизнесу дороже любого внешнего проекта.
Почему внутренние инструменты проигрывают спор за бюджет
У новой страницы бронирования отдача очевидна: больше записей. У инструмента, который экономит операционному отделу четыре часа в неделю, отдача тоже есть, но её труднее показать цифрой, поэтому он плохо конкурирует с проектами с понятной историей выручки. В итоге бизнес охотно тратит на привлечение клиентов, пока три человека каждую неделю вручную сверяют одни и те же цифры в трёх разных таблицах — просто потому что никто никогда не подсчитал, во что обходится эта привычка.
Какой ручной процесс стоит заменить первым
Не каждая повторяющаяся задача заслуживает отдельного софта — некоторые вполне нормальны в текущем виде. Те, что стоит исправлять, обычно объединяют три черты: они происходят часто (ежедневно или еженедельно, а не раз в квартал), в них участвует больше одного человека, передающего информацию, а ошибки в них дорого стоят или неловки, а не тривиальны в исправлении. Редкий, одиночный процесс с низкими ставками не стоит автоматизировать, даже если он слегка раздражает. Процесс, к которому ежедневно прикасается вся команда, где ошибка означает неверный заказ или пропущенную встречу, — сильный кандидат.
Полезное упражнение: перечислите все места, где информация сейчас перемещается между таблицей, чатом и памятью человека. Каждая такая передача — это место, где что-то теряется, забывается или делается иначе в зависимости от того, кто в тот день на смене. Передача, вызывающая больше всего заметного трения — та, на которую чаще всего жалуются, — обычно и есть верная точка старта, а не та, что выглядит технически интереснее всего.
Небольшой охват, реальная отдача
Внутренние инструменты с лучшей отдачей редко бывают амбициозными. Простая форма, заменяющая цепочку сообщений, небольшая панель, вытягивающая цифры, которые сейчас живут в чьей-то голове, базовая система, назначающая и отслеживающая задачу вместо того, чтобы полагаться на чью-то память о необходимости проследить, — это скромные разработки по сравнению с полноценной платформой, и они обычно быстро окупаются, потому что ручная версия, которую они заменяют, каждый день отнимала реальное время.
Ошибка, которой стоит избегать, — относиться к внутреннему инструменту как к мини-версии клиентского продукта, с тем же уровнем полировки и разрастанием требований. Ему достаточно надёжно работать для небольшого числа людей, которые будут им пользоваться, и быть достаточно простым, чтобы команда действительно продолжала им пользоваться, а не соскользнула обратно к таблице через месяц.
Как обосновать бюджет
Внутренние инструменты конкурируют за финансирование с проектами, у которых история понятнее, поэтому обоснование нужно строить в тех же терминах: часы, сэкономленные в неделю, умноженные на число людей, выполняющих задачу, сопоставленные со стоимостью скромной разработки. В такой рамке у небольшой внутренней системы часто оказывается более короткий срок окупаемости, чем у клиентского проекта, стоящего рядом с ней в списке приоритетов, — она просто менее заметна, поэтому никто не считает цифры, пока кто-то не попросит.
После того как обоснование готово, сама разработка не обязана быть масштабной. Именно такие проекты наша команда разработки намеренно ограничивает небольшим объёмом, потому что внутренний инструмент оправдывает свой бюджет тем, что растворяется в повседневном использовании, а не производит впечатление. Если вы взвешиваете, настроить ли для этого существующую платформу или построить что-то узкое и заказное, это решение следует той же логике, что описана в нашем руководстве о выборе способа получить софт — правильный ответ обычно зависит от того, насколько процесс на самом деле стандартен.
