В таблице всё есть. Просто не у всех и не одинаково.
Утро начинается с вопроса в чате: кто взял заказ Петрова? Один отвечает, что не брал, второй — что вроде бы Саша, третий — что Саша в отпуске. Через десять минут выясняется, что заказ действительно взяли, просто статус в таблице поменять забыли, и клиенту за это время успели позвонить из двух отделов.
Это не история про безответственных сотрудников. Ровно те же люди год назад работали в тех же таблицах, и ничего не ломалось. Изменились не они, а нагрузка на инструмент — и это довольно точно объясняет, что именно посыпется раньше остального.
Дальше — почему таблицы и переписка держат работу до определённого момента, что ломается первым, как понять, на какой вы ступени, и с чего начинается автоматизация учёта, когда до неё действительно дошло.
Дело не в количестве записей, а в количестве одновременных изменений
С ростом бизнеса растут три разные вещи, и их легко сложить в одну — «стало больше работы».
Записей больше. Заказов, клиентов, поставок. Само количество строк проблему ещё не объясняет: таблица нормально работает и с большим объёмом, пока процесс остаётся простым.
Людей больше. Уже интереснее, но пока каждый ведёт свой участок и не пересекается с соседом — тоже терпимо.
Одновременных изменений больше. Вот здесь начинают появляться системные расхождения. Двое трогают одно и то же в один и тот же час: один меняет статус, второй в это время смотрит на строку и принимает по ней решение. Ни один из них не сделал ничего неправильного.
Поэтому «мы просто выросли» — не объяснение. Объяснение конкретнее: выросло число ситуаций, когда правда о заказе существует в двух версиях одновременно.
Таблица и чат ломаются по-разному
Они делают разную работу, и слабые места у них тоже разные.
Сразу оговорюсь: современные табличные сервисы умеют многое — историю версий, права на диапазоны, проверку значений, комментарии, автоматизации. Дело не в том, что таблица технически чего-то не может. Дело в том, что модель бизнес-процесса в ней приходится собирать и поддерживать руками, а держится она на дисциплине команды.
Ответственность моделируется вручную. Отдельной колонкой, правилами заполнения и договорённостями. Колонка «ответственный» существует ровно настолько, насколько её заполняют, — а заполняют её в последнюю очередь.
История есть у файла, а не у записи. Версии документа сервис хранит, но это история правок таблицы, а не история заказа. Восстановить по ней бизнес-смысл — кто перевёл заказ в этот статус и почему — обычно дольше и труднее, чем в системе, где изменение записи и есть событие.
Обязательность полей — это настройка и контроль, а не свойство строки. Проверку значений можно включить, но сама строка не знает, можно ли двигать заказ дальше. Пустая ячейка не мешает работать сегодня — она всплывает в тот день, когда по записи нужно отгрузить, выставить счёт или передать её другому человеку.
Бизнес-роли приходится моделировать поверх прав доступа. Менеджеру, бухгалтеру, администратору и исполнителю нужны разные возможности работы с одними и теми же данными. В таблицах такое разделение приходится отдельно настраивать и поддерживать.
У чата всё то же самое, и к этому добавляется своё.
В переписке нет текущего состояния — только события. Чат хранит, что и когда сказали. Чтобы понять, как обстоят дела с заказом сейчас, приходится прокручивать ленту и собирать состояние из реплик — а часть решений принята голосом, в другом чате или в личке.
И поиск в переписке ищет сообщения, а не состояние. Слово «оплата» он найдёт легко. А списка заказов, которые прямо сейчас ждут оплаты, не соберёт: такого вопроса переписке задать нельзя.
Пять зон, где беспорядок становится заметен
У разных компаний порядок отличается: где-то раньше всего заболит отчётность, где-то доступ, а статусы будут в порядке. Я проверяю эти пять зон именно в такой последовательности — от текущего состояния записи к отчётности, потому что каждая следующая опирается на предыдущие. Рядом с каждой — вопрос, по которому видно, ваша это зона или нет.
Зона 1. Состояние. Первым делом я смотрю, можно ли доверять ответу на вопрос «что с этим сейчас». Надёжным он перестаёт быть не потому, что кто-то ленится, а потому, что обновление статуса — отдельное действие, которое надо не забыть сделать после основного.
Можете ли вы прямо сейчас, не спрашивая никого, назвать текущее состояние любого заказа?
Зона 2. Ответственность. Дальше расползается «кто должен». Обратите внимание — не «кто виноват», а именно «кто должен сделать следующий шаг». Пока людей мало, это очевидно и без записи. Когда участников больше, очевидность заканчивается, а места, где это было бы записано, нет.
Если открыть любую запись, видно ли из неё, кто делает следующий шаг и до какого момента?
Зона 3. История. Потом начинаются споры о прошлом. Что обещали клиенту по срокам, какую скидку согласовали, кто менял сумму. Всё это где-то обсуждалось — в чате, в звонке, в комментарии к строке, которого уже нет.
Можете ли вы восстановить, как запись выглядела две недели назад, и кто её менял?
Зона 4. Доступ. Дальше вопрос перестаёт быть удобством и становится риском. Файл с клиентами лежит в личном облаке сотрудника; данные клиентов открыты всем, кто когда-либо получал ссылку; человек уходит — и часть рабочей информации уходит с ним. Отдельно проверьте таблицы с персональными данными клиентов — именами, телефонами, адресами: у кого сейчас есть к ним доступ и как этот доступ отзывается.
Знаете ли вы точно, у кого сейчас есть доступ к вашим данным о клиентах?
Зона 5. Отчётность. Сводку собирают руками — и чем дальше, тем дольше это занимает, а доверия к результату меньше: собирается она из тех самых строк, о которых шла речь в зонах 1–3.
Сколько человеко-часов уходит на то, чтобы собрать картину за месяц, и совпадают ли две сводки, собранные разными людьми?
Пройдите пять вопросов сверху вниз и остановитесь на первом, где ответ отрицательный. Он показывает, с какой зоны имеет смысл начинать разбор. Что там ниже — вопрос отдельный, но браться за отчётность, пока нельзя доверять состояниям и ответственности, действительно рано: отчёт, собранный из недостоверных статусов, достовернее не станет.
Это не то же самое, что потерянные заявки
Здесь легко перепутать два разных беспорядка, и лечатся они в разном порядке.
Заявки — это то, что приходит снаружи: с сайта, из мессенджера, с Авито, по телефону. Про то, где они теряются по дороге и как устроен их маршрут, у меня есть отдельные разборы — где теряются заявки и автоматизация обработки заявок.
Учёт — это то, что происходит с работой после того, как заявка стала заказом: кто ведёт, в каком состоянии, что обещано, что сделано.
Порядок важен. Если заявки не доезжают до вас вовсе, автоматизация учёта эту дыру не закроет — она аккуратно учтёт то, что дошло. Сначала вход, потом внутренняя работа. Если же на входе всё в порядке, а разваливается именно то, что внутри, — вы читаете про свою ситуацию.
Отдельный случай — когда система учёта уже есть, но живёт своей жизнью, и данные в неё переносят руками. Это третья задача, про неё — как связать сайт, бота и CRM.
Когда таблиц ещё достаточно
Не всякая описанная выше боль означает, что пора заказывать разработку. Есть признаки, по которым видно, что рано.
Записи ведёт один человек. Пока правки не бывают одновременными, главный источник ошибок отсутствует.
Цикл сделки короткий и простой. Если заказ живёт день-два и с ним работает один человек, подробная история изменений менее критична. Но не всегда: возвраты, споры и сверки требуют её при любом цикле.
Процесс типовой. Если ваша работа устроена так же, как у других компаний в нише, сначала стоит проверить готовые сервисы: возможно, задача закрывается без собственной разработки. Разбираться, чем ваш процесс отличается от типового, имеет смысл до того, как заказывать своё.
И три шага, которые стоят дёшево и делаются до всякой разработки:
- Одна таблица вместо трёх. Не потому, что одна лучше, а потому, что чем больше параллельных таблиц описывают один процесс, тем выше риск расхождений и тем чаще их приходится сверять руками.
- У каждой записи — владелец и состояние. Две колонки, которые заполняются всегда, даже если остальные пустые.
- Решение из чата переезжает в запись. Договорились о сроке или скидке в переписке — это должно оказаться в строке заказа в тот же день, иначе через месяц договорённость придётся искать в переписке — если она там вообще найдётся.
Если после этих шагов работа выправилась — задача решена, и денег она не стоила. Если нет — значит, дело не только в дисциплине, и разбирать надо сам процесс: как он устроен, кто в нём за что отвечает и где ему не хватает инструмента. Вот тогда разговор про разработку осмысленный.
С чего начинается автоматизация учёта
Вопреки ожиданию, начинается она не с выбора программы. Начинается с того, что вы описываете одну запись — заказ, клиента, заявку, поставку, смотря чем живёт бизнес: какие у неё бывают состояния, кто её меняет на каждом состоянии и что обязательно должно быть заполнено, чтобы перейти к следующему.
Из этого описания уже видно, какой инструмент нужен. И только после него имеет смысл спорить, где всё это будет жить.
Если готовые сервисы не подходят, дальше возникает выбор между кабинетом на своём сайте и отдельным веб-приложением. Здесь я его намеренно не разбираю: это уже вопрос формы решения, а не диагностики — и он заслуживает отдельного разговора.
Что за этими двумя формами стоит — на страницах корпоративного сайта и разработки веб-приложений.
А начинать всё равно стоит с одного и того же: пройти пять вопросов сверху вниз и найти зону, где ответ впервые становится отрицательным.