БухСорс: зачем перезапускать контроль качества учёта

Какую задачу решал прежний БухСорс?

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

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

Почему возможности добавить свои правила оказалось недостаточно?

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

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

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

Что здесь меняют LLM?

Рафаэль прежде всего рассматривает LLM как инструмент самой команды: разбирать старые анкеты, помогать с разработкой, собирать варианты проверок и готовить материалы для специалистов. Это способ ускорить работу над продуктом и методикой.

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

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

Как должен выглядеть первый полезный результат?

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

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

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

Обязательно ли отдавать базу в облако?

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

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

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

Что полезно сохранить из старого продукта?

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

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

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

Что можно сделать сейчас?

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

Для подготовки разговора пригодится чек-лист контроля качества учёта. Он помогает сформулировать ожидания от проверки ещё до выбора инструмента.