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

Материал подготовлен по рабочему разговору с Рафаэлем, инициатором перезапуска БухСорса. Редакция сгруппировала вопросы и передала ответы в косвенной речи. Это изложение замысла продукта, а не дословная стенограмма и не сообщение о готовности новой версии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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