Автоматизация для малого бизнеса: что делать с бюджетом до 500 тысяч

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

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

Дальше — про то, как распорядиться бюджетом от 150 до 500 тысяч так, чтобы первый проект не оказался последним. Какой процесс брать первым, что помещается в эти деньги, где сервис за пять тысяч в месяц отменяет разработку и на чём экономить нельзя.

Правило первого проекта: один процесс, шесть месяцев, две системы

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

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

1. 1Процесс повторяется не меньше 300 раз в месяц. Меньше — эффект утонет в погрешности: система требует внимания и денег на эксплуатацию независимо от того, обрабатывает она 50 документов или 5 000.
2. 2Он описывается правилами, а не чутьём. Если на вопрос «как ты это решаешь» сотрудник отвечает «по ситуации», сначала нужен письменный регламент, а уже потом система. Автоматизировать неописанное — самый быстрый способ потратить бюджет на переделки.
3. 3У него уже есть счётчик. Число писем в общем ящике, число проведённых накладных в 1С, число звонков в детализации оператора — эти цифры уже существуют, и по ним можно замерить эффект. Процесс без счётчика придётся сначала мерить две недели вручную.
4. 4Его тормоз формулируется числом. Не «неудобно» и не «люди устают», а «менеджер тратит два часа в день» или «каждая пятая заявка получает ответ на следующий день». Если в формулировке боли нет числа, считать окупаемость будет не от чего.
5. 5У него есть союзник внутри. Первый проект держится на одном заинтересованном сотруднике, который отвечает на вопросы подрядчика и потом объясняет коллегам, зачем всё это. Если по самому болезненному процессу такого человека нет, берите второй по списку — технически скучнее, но с союзником.

Что реально помещается в 150–500 тысяч

Цена разработки — это человеко-недели команды плюс запас на риск. Типовой состав проекта автоматизации: аналитик, разработчик и тестировщик, частично занятые; неделя такой команды стоит на рынке 120–200 тысяч рублей. Отсюда арифметика: 300 000 ₽ — это примерно две полные недели работы команды, которые растягиваются на пять-шесть недель календаря за счёт согласований и ожидания ваших ответов. Всё, что не помещается в эти человеко-недели, в бюджет не поместится.

• 150–250 тысяч, 3–5 недель. Один узкий участок и одна система на конце. Разбор входящей почты по темам с автосозданием карточек в CRM. Ответы на пять-семь типовых вопросов клиентов. Отчёт, который сейчас собирают руками в Excel по понедельникам, — по расписанию и без человека.
• 250–400 тысяч, 5–8 недель. Процесс целиком, с двумя системами и правилами для исключений. Распознавание входящих счетов и накладных с занесением в 1С. Квалификация заявок с распределением по менеджерам и приоритетами. Бот поддержки на вашей базе знаний с эскалацией на человека по стоп-темам.
• 400–500 тысяч, 6–10 недель. Участок с голосом, нетривиальной логикой или третьей системой. Голосовой робот на входящей линии с записью в живое расписание. Управленческая отчётность, собранная из 1С, CRM и банковской выписки в один дашборд с ежедневным обновлением.

В расчёте намеренно нет двух вещей, которые обычно вписывают в презентацию: заявок, которые сейчас теряются и вернутся, и ускорения первого ответа клиенту. Эффект от них есть, но защищать его перед самим собой через полгода трудно — пусть остаётся запасом прочности. И честная граница сверху: своя CRM, ERP, складская система, мобильное приложение, замена 1С или компьютерное зрение на производственной линии в пятьсот тысяч не помещаются даже близко. Это проекты от полутора миллионов, и компании на тридцать человек они, как правило, не нужны — нужен один участок, который болит сейчас.

Готовый сервис или разработка: как понять до того, как платить

Вопрос, который в этом бюджете экономит больше всего денег: а разработка точно нужна. Проверка занимает вечер. Опишите задачу одной фразой, не упоминая свою компанию: онлайн-запись клиентов, учёт сделок, рассылка по базе, электронный документооборот. Если фраза похожа на название категории программ, рынок эту задачу уже закрыл — есть 5–10 сервисов по 3–8 тысяч рублей в месяц, в которых ваш сценарий типовой. Разработка здесь проигрывает по всем параметрам сразу, включая срок запуска.

Разработка начинается там, где в описании задачи появляются слова у нас и по-своему: наши формы документов, наши правила скидок, наша связка 1С с самописным складом. Между двумя полюсами лежит основная масса проектов малого бизнеса — разработка на готовых компонентах, когда языковая модель, движок ботов, распознавание и BI берутся коробочными, а платите вы за сборку под ваш процесс. Именно в этой середине легче всего переплатить: если в смете отдельной строкой стоит разработка того, что можно взять готовым, вы покупаете велосипед с гравировкой, а потом ещё платите за его обслуживание. Обратное правило тоже работает — готовый сервис перестаёт быть дешёвым в трёх случаях: абонентская плата считается за пользователя, а вас уже пятьдесят; половина времени уходит на ручной перенос данных между сервисом и учётом; важный для выручки процесс упёрся в чужую дорожную карту, и вам отвечают, что такой функции не планируется.

Сэкономить на диагностике — самый дорогой способ сэкономить

Диагностика в проекте на 300 000 ₽ стоит 40–80 тысяч и занимает одну-две недели. Соблазн понятный: это 15–25% бюджета за документ, а не за работающую систему, и техзадание вроде бы уже есть в голове у владельца. Дальше случается одно из трёх. Подрядчик пишет техзадание по вашему рассказу — а на приёмке выясняется, что реальный процесс давно отличается от рассказанного, потому что менеджеры два года назад придумали обходной путь. Или объём операций оказывается втрое меньше, чем казалось на глаз, и проект не окупается никогда — но выясняется это уже после оплаты. Или всплывает интеграция, которую никто не учитывал, и смета вырастает на 40% в середине работ.

Считать надо не стоимость диагностики, а стоимость ошибки без неё. Переделка после неверного техзадания — это 30–50% бюджета проекта и месяц срока. Система, которой в итоге не пользуются, — это 100% бюджета плюс сгоревшее доверие команды к следующему проекту. При таких ставках 60 000 ₽ за две недели замеров, карту процесса и внятное техзадание — самая дешёвая страховка в проекте. Отдельное правило: диагностика должна быть платной. Бесплатное обследование окупается подрядчику только продажей, поэтому его вывод известен заранее — автоматизировать надо, и желательно побольше.

Поддержка: как не платить за неё больше, чем за сам проект

Рыночный ориентир поддержки — 10–20% от стоимости внедрения ежемесячно. Для проекта на 300 000 ₽ это 30–60 тысяч в месяц, то есть 360–720 тысяч в год: больше, чем сам проект. Для корпорации с круглосуточной линией и десятком смежных систем такая цифра оправдана. Малому бизнесу столько не нужно, а главная причина переплаты — единая нерасшифрованная строка в договоре, под которой каждая сторона понимает своё.

• Разделите счёт на две части. Эксплуатация — мониторинг, обновления, реакция на сбой, продление сертификатов — фиксированная сумма. Развитие — новые сценарии и доработки — по часам по факту. Единая цифра всегда считается подрядчиком по худшему сценарию, то есть в вашу сторону дороже.
• Возьмите SLA по своему реальному режиму. Реакция за час в рабочие часы стоит вдвое дешевле круглосуточной. Если склад работает с 9 до 18, а заказы ночью не приходят, платить за ночное дежурство инженера не за что.
• Внешние расходы — по счётчику, а не внутри абонента. Токены языковой модели, распознавание страниц, телефония, SMS: попросите передавать их по факту с приложением отчёта. Упакованные в общую сумму, они обычно идут с наценкой 30–50%, и проверить это невозможно.
• Абонентский минимум с переносом неиспользованных часов. Восемь часов в месяц, остаток переходит на следующий — честнее, чем оплачивать постоянную готовность, которая понадобится дважды в год.
• Заберите право уйти. Исходный код, доступы, документация и инструкция по развёртыванию должны оказаться у вас до окончательного расчёта за внедрение. Тогда поддержка у автора системы — ваш выбор, а не безвыходность, и цена держится в рынке сама собой.

Разумный ориентир для проекта на 300 000 ₽ — 15 000–25 000 ₽ в месяц за эксплуатацию плюс часы развития по факту. Отдельной строкой заложите внешние расходы: языковая модель на объёмах малого бизнеса обходится в 3–8 тысяч рублей в месяц, распознавание документов — 1–3 рубля за страницу, телефония — по тарифу оператора. И держите в уме, что первые два-три месяца после запуска поддержки нужно заметно больше, чем потом: сценарии дорабатываются по живым случаям, база знаний дописывается по реальным вопросам. Планировать этот период по стабильной ставке — значит спорить с подрядчиком в самый неподходящий момент.

Первый проект финансирует второй

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

1. 1Месяц 0. Вкладываете 320 000 ₽ из собственных денег. Один процесс, две системы, шесть недель. Метрики замерены до старта — иначе через полгода спорить об эффекте будет нечем, и спор этот вы проиграете.
2. 2Месяцы 1–3. Выход на расчётные показатели. В первый месяц экономии нет вообще, во второй — примерно половина, к третьему — расчётная. Люди привыкают, сценарии дорабатываются, всплывают исключения. Считать эффект с первого дня — типовая ошибка планирования.
3. 3Месяцы 4–7. Эффект 70 000 ₽ в месяц превращается в живые деньги только при одном из трёх условий: вы не наняли пятого менеджера, отменили переработки или пропустили выросший объём через прежний состав. Если не произошло ничего из трёх, второго проекта быть не должно — это честный сигнал остановиться и разобраться. К седьмому месяцу накопленный эффект перекрывает вложение.
4. 4Месяц 12. Накопленный эффект — порядка 735 000 ₽, свободными после возврата вложения остаётся около 400 000 ₽. Этого хватает на второй проект того же размера, и он уже не трогает оборотку.
5. 5Второй проект берут того же масштаба, а не втрое больше. Соблазн после первого успеха замахнуться на полтора миллиона — главная причина, по которой второй проект проваливается чаще первого: растёт число участков, число систем и число людей, которых надо переучивать, а команда и опыт остаются прежними.

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

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