10 признаков, что бизнес перерос Excel, Telegram и переписку по почте

Ничего.

Excel и Google Таблицы — отличные инструменты. Более того, я бы не советовал бизнесу отказываться от них просто потому, что появилась возможность заказать какую-нибудь «корпоративную систему».

Если у компании:

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

то отдельная разработка может быть просто лишней тратой денег.

Проблема появляется не тогда, когда используется Excel.

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

Например:

• «Это точно последняя версия файла?»
• «Ты поменял количество?»
• «А клиент подтвердил замену?»
• «Где новый адрес доставки?»
• «Кто сейчас занимается этим заказом?»
• «Мы уже отправили поставщику или ещё нет?»

Вот это уже интересные симптомы.

Да. Классическая ситуация.

Сначала появляется файл Заказы.xlsx. Потом Заказы_новый.xlsx. Затем Заказы_финал.xlsx. Следом Заказы_финал2.xlsx. А через неделю выясняется, что один сотрудник продолжал работать вообще в Заказы_Ирина.xlsx.

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

Например:

• один менеджер считает, что клиент заказал 12 единиц товара;
• другой видит 10;
• в одном файле позицию уже заменили;
• в другом осталась старая;
• адрес доставки обновили только в одной версии;
• склад продолжает работать по старому документу.

В этот момент таблица перестаёт быть источником информации.

Она становится одной из версий происходящего. А бизнесу нужен один актуальный источник данных.

См. интервью: Excel, Telegram и CRM — граница CMS и бизнес-системы

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

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

В ней появляются:

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

Новый сотрудник открывает документ на 40 колонок и спрашивает: «А что означает жёлтая строка?» Ему отвечают: «Жёлтая — ждём клиента. Только если дата красная, тогда это уже срочно. А если в колонке K стоит плюс, сначала спроси Александра».

Система у компании уже есть. Просто она нигде нормально не описана.

Это очень показательный симптом.

Если в рабочем чате регулярно появляются вопросы:

• «Какой статус заказа №318?»
• «Клиент согласовал замену?»
• «Оплата пришла?»
• «Кто отвечает за этот объект?»
• «Когда нужна доставка?»
• «Поставщик подтвердил наличие?»

значит нужная информация либо отсутствует, либо её слишком сложно найти.

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

Типичная ситуация выглядит так:

1. Один сотрудник задаёт вопрос.
2. Второй открывает почту.
3. Ищет нужную переписку.
4. Проверяет таблицу.
5. Пишет третьему сотруднику.
6. Ждёт ответа.
7. И только после этого отвечает: «Да, вроде согласовали».

Хорошая система должна давать ответ на такой вопрос за несколько секунд.

Не обязательно. Общаться — нормально.

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

Например:

• «Клиент согласовал второй вариант».
• «Поставщик разрешил заменить модель 125 на 127».
• «Доставку перенесли на четверг».
• «В заказ нужно добавить ещё три позиции».

Если эти решения существуют только в переписке, рано или поздно что-то потеряется.

Представим обычный заказ. Процесс выглядит так:

1. Менеджер отправил клиенту предложение.
2. Клиент ответил в Telegram.
3. Менеджер переслал сообщение снабженцу.
4. Снабженец написал поставщику по электронной почте.
5. Поставщик предложил замену.
6. Менеджер переслал фотографию клиенту.
7. Клиент ответил: «Ок».

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

В нормальной системе решение должно относиться к конкретному заказу, позиции или задаче. Например:

Позиция: смеситель X120 · Исходный товар: отсутствует · Предложена замена: X125 · Согласовано клиентом: 14 сентября, 12:42 · Согласовал: Иван Петров

Тогда история не зависит от памяти конкретного менеджера.

Пример: закупочный портал сантехники для объекта

Я иногда задаю простой вопрос: «Если сейчас позвонит клиент и спросит, где его заказ, сколько времени потребуется сотруднику, чтобы дать точный ответ?»

Если для этого нужно:

• открыть три программы;
• проверить таблицу;
• найти переписку;
• написать двум коллегам;
• дождаться ответа,

это уже сигнал.

В идеале статус заказа должен быть виден сразу. Например:

Новый заказ → Проверка → Согласование → Оплата → Комплектация → Готов к отправке → В доставке → Выполнен

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

Кейс: дилерский портал с очередью исключений

Да. И если задачу можно нормально закрыть существующей CRM — я бы сначала рассматривал именно этот вариант.

Кастомная разработка нужна не потому, что она «круче». Она становится интересна, когда бизнес-процесс компании заметно отличается от стандартного сценария лид → сделка → продажа.

Например, если внутри одного заказа есть:

• десятки товарных позиций;
• версии спецификаций;
• согласование замен;
• разные роли пользователей;
• проверка совместимости;
• резервирование, производство, комплектация, этапы доставки.

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

Почему компании в этот момент отказываются не от CRM как класса, а от идеи «всё хранить в CRM»: исследование про отказ от готовой CRM.

Это очень распространённая проблема.

Например:

1. Клиент прислал заказ.
2. Менеджер занёс его в таблицу.
3. Затем перенёс часть данных в CRM.
4. Сотрудник склада вручную ввёл информацию в учётную систему.
5. Для доставки данные снова скопировали в отдельный документ.
6. Бухгалтер получил ещё один файл.

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

И чем больше заказов, тем сильнее эта проблема масштабируется.

Пример: B2B-кабинет с обменом заказов и 1С

Например:

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

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

Система полезна не только потому, что хранит информацию. Она может проверять сам процесс. Например:

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

Кейс: зоомагазин: согласование замены при самовывозе

Не всегда. Иногда гораздо важнее сделать ошибку технически невозможной.

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

Автоматизация особенно хорошо работает там, где можно сформулировать правило: «Если произошло X, нужно обязательно проверить Y».

Это очень важный признак. Можно провести простой эксперимент.

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

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

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

Это довольно рискованная архитектура.

Пример: система заказов кухонь на заказ

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

Ещё интереснее вопрос: «Почему эти заказы задерживаются?» Иногда оказывается, что компания знает количество продаж, но практически ничего не знает о самом процессе.

Например:

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

Без таких данных очень сложно улучшать процесс.

Кейс: операционный контур сети парковок

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

Я сторонник другого подхода. Сначала нужно определить несколько вопросов, на которые руководителю действительно приходится отвечать регулярно:

• Что сейчас требует моего вмешательства?
• Где процесс остановился?
• Какие заказы рискуют сорвать срок?
• Почему они остановились?

Если интерфейс быстро отвечает на эти вопросы — он уже полезен.

Это довольно неприятный признак, потому что его сложно заметить. Растёт количество заказов. Сотрудники перестают справляться. Компания нанимает ещё одного менеджера. Потом ещё одного.

Кажется логичным: больше клиентов → больше сотрудников. Но иногда выясняется, что значительная часть рабочего дня уходит не на работу с клиентами, а на:

• копирование данных;
• поиск информации;
• сверку таблиц;
• уточнение статусов;
• перенос данных между системами;
• формирование одинаковых документов;
• контроль того, кто кому ответил;
• поиск последней версии файла.

Тогда масштабируется не бизнес. Масштабируется ручная работа.

Обзор: обзор AI-автоматизации для руководителей

Можно несколько дней записывать повторяющиеся действия сотрудников. Не так: «Работал с заказом два часа». А конкретно:

• 15 минут — переносил заказ из письма в таблицу;
• 10 минут — уточнял наличие;
• 12 минут — искал последнее согласование;
• 8 минут — переносил данные в другую систему;
• 15 минут — формировал документ;
• 10 минут — писал коллегам для уточнения статуса.

После такого наблюдения часто становится понятно, где находится реальная проблема.

На мой взгляд, это самый сильный сигнал. Посмотрите на внутренние инструкции компании. Если там есть правила вроде:

• «Если ячейка зелёная — заказ подтверждён».
• «После согласования перенесите строку на второй лист».
• «Название файла обязательно должно содержать дату».
• «После отправки поставщику поставьте плюс в колонке M».
• «После ответа клиента напишите в общий чат».
• «Если товара нет, создайте копию строки и укажите аналог».

Вы уже спроектировали информационную систему. Только вместо программного кода её исполняют сотрудники.

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

Подробнее: интеграция Laravel с 1С

Нет. Это было бы слишком удобно для разработчика. Сначала нужно понять стоимость проблемы.

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

Поэтому я бы смотрел сразу на несколько параметров:

• частота операции;
• количество сотрудников;
• стоимость ошибки;
• количество участников процесса;
• сложность контроля;
• объём ручной работы;
• влияние проблемы на клиента.

Чем чаще повторяется операция и чем дороже ошибка, тем интереснее её автоматизировать.

См. также когда Laravel пока не нужен

Редкий, нестабильный и постоянно меняющийся.

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

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

Иначе получится дорогая автоматизация хаоса.

Размер компании сам по себе не самый важный показатель.

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

А есть компания из пятидесяти человек, где процессы достаточно простые и стандартная CRM полностью закрывает потребности.

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

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

Автоматизация не должна начинаться с фразы «Давайте разработаем систему». Она должна начинаться с вопроса:

«Где именно мы сейчас теряем время или деньги?»

Иногда ответ будет: нигде. И это хороший ответ.

Не с технического задания на 80 страниц. Я бы сначала взял один реальный процесс. Например: от получения заказа до его передачи в доставку.

И разложил его буквально по шагам:

1. Кто получает информацию?
2. Куда её записывает?
3. Кто использует её дальше?
4. Где данные приходится вводить повторно?
5. Где появляется ожидание?
6. Где сотрудник вынужден что-то уточнять?
7. Где чаще всего возникают ошибки?
8. Где требуется подтверждение другого человека?

Очень часто уже на этой схеме становятся видны места, которые стоит автоматизировать.

Как правило, наоборот — не нужно. Хорошая автоматизация редко начинается с идеи «Выбросим всё и напишем собственную ERP».

Гораздо разумнее взять один болезненный участок:

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

Сделать его нормально. Посмотреть на результат. И только потом двигаться дальше.

Я бы задал себе один вопрос:

«Сколько работы в моей компании существует только потому, что информация находится не там, где она нужна?»

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

Не обязательно немедленно заказывать разработку. Но точно стоит посчитать стоимость этого ручного труда.

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

Просто роль сервера в ней выполняют сотрудники.

Если вы узнаёте свою компанию сразу в нескольких пунктах, имеет смысл разобрать процессы подробнее.

1. Существует несколько версий одного файла.
2. Сотрудники постоянно спрашивают друг друга о статусах.
3. Важные договорённости находятся в Telegram или почте.
4. Нельзя быстро определить состояние заказа.
5. Одни и те же данные приходится вводить несколько раз.
6. Ошибки обнаруживаются на поздних этапах.
7. Процесс слишком зависит от знаний конкретного сотрудника.
8. Руководитель получает картину бизнеса только после ручного отчёта.
9. Новые сотрудники нужны в том числе для копирования, сверки и поиска информации.
10. В компании уже существует сложная система правил вокруг таблиц, файлов и сообщений.

Сам по себе ни один из этих признаков не означает, что бизнесу обязательно нужна индивидуальная разработка. Но если таких признаков становится много, вопрос уже стоит ставить не так: «Зачем нам какая-то система?», а так:

«Сколько нам сейчас обходится её отсутствие?»

Excel, Telegram и электронная почта — не враги бизнеса. Они отлично работают на ранних этапах и во многих простых процессах.

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

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

Дальше: Laravel или WordPress — нейтральное сравнение