Автоматизация без замены 1С и CRM: как это работает технически

Разговор об автоматизации в компании на 20–500 человек почти всегда упирается в одну фразу: у нас старая 1С и самописная CRM, сначала надо всё это заменить. Иногда фразу приносит подрядчик, иногда — новый руководитель, который на прошлом месте работал в другой системе. Дальше проект превращается в миграцию на полтора года, а исходная задача (сократить ручной ввод, увидеть реальную маржу по заказам, перестать терять заявки) откладывается до её окончания.

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

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

Учётная система и слой автоматизации — разные машины

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

Почему замена 1С — самый дорогой способ автоматизироваться

Замена учётной системы — это не покупка лицензий. Это перенос остатков, взаиморасчётов и истории документов, переобучение всех, кто вводит данные, и параллельный учёт до первого чистого закрытия периода. Считаем на модельной компании: 120 человек, 60 рабочих мест в 1С, торговля с собственным складом.

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

Автоматизация не требует единой системы. Она требует доступа к данным и права записать результат обратно.

Четыре способа подключиться к тому, что уже работает

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

1. 1Официальный API. В 1С это HTTP-сервис, вынесенный в расширение конфигурации, или стандартный интерфейс OData; в amoCRM и Битрикс24 — REST и вебхуки. Мы получаем именованный доступ с ограниченной ролью, работаем в правилах системы и не зависим от того, как физически устроены таблицы. Единственный минус: если нужного метода нет, его дописывает ваш 1С-специалист — это 1–3 дня работы, а не проект.
2. 2Штатный обмен. Регламентное задание раз в 5–15 минут выгружает срез данных в XML или CSV — в каталог, на FTP или в объектное хранилище; надстройка забирает файлы и разбирает. Система о нас не знает вообще ничего, риск сломать учёт нулевой. Минусы: данные приходят с задержкой в один цикл выгрузки, и обратная запись идёт таким же файлом, который система должна уметь принять.
3. 3Чтение базы. Для клиент-серверной 1С на PostgreSQL или MS SQL снимается реплика либо заводится пользователь с правом только на SELECT. Читать можно всё и быстро, но имена таблиц машинные (вида _Document137_IDRRef), поэтому первым делом строится карта соответствия по метаданным конфигурации. Минус: карта живёт до следующего серьёзного обновления, за ней надо следить. Для файловой базы способ не годится.
4. 4Промежуточный контур. Между вашими системами и автоматизацией ставится отдельная база-зеркало: она собирает данные любым из трёх способов выше, приводит их к одной модели и хранит историю. Все расчёты, дашборды и ИИ-сценарии обращаются к ней, а не к боевому учёту, поэтому дополнительная нагрузка на 1С равна нулю сверх ночной выгрузки. Стандартный выбор, когда систем больше одной или в отчёт нужно свести 1С, CRM и телефонию.

На практике почти всегда получается связка: читаем через API или выгрузку, а пишем обратно только через API. Писать напрямую в таблицы 1С нельзя ни при каких обстоятельствах — запись мимо механизма проведения ломает регистры накопления, и это не лечится откатом: расходятся остатки и взаиморасчёты, а обнаруживается через месяц при закрытии. Читать базу напрямую — нормальная инженерная практика. Писать в неё напрямую — нет. Если подрядчик предлагает второе, дальше можно не слушать.

Сроки подключения и что делать с самописными системами

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

• Где лежат данные. PostgreSQL, MS SQL, MySQL — работаем штатно. DBF, файлы Access, набор Excel на сетевой шапке — сначала придётся навести порядок, и это отдельная работа на несколько недель.
• Есть ли отметка времени изменения. Без поля с датой правки таблицу приходится вычитывать целиком при каждой синхронизации: на 200 тысячах строк терпимо, на 20 миллионах — нет, и добавление одного поля экономит месяцы эксплуатации.
• Есть ли устойчивые ключи. Если заказ опознаётся только связкой номер плюс дата, а номера повторяются между филиалами, до всякой автоматизации строится правило склейки записей.
• Жив ли автор системы. Полдня разговора с человеком, который её писал, экономит две недели раскопок. Если автора нет, вместо документации будет реверс по данным — это делается, но закладывайте плюс 30–50% к сроку.
• Есть ли бэкапы и тестовый контур. У самописных систем их часто нет вовсе. Это первое, что нужно сделать, и стоит это дешевле любой автоматизации.

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

Как не сломать существующий учёт — сейчас и после обновления

1. 1Отдельный пользователь интеграции. Не учётная запись главбуха и не полные права. Своя роль, свой пароль, свои ограничения — тогда всё, что делает надстройка, видно в журнале регистрации под её именем и отделимо от действий людей.
2. 2Первые 4–8 недель — только чтение. Надстройка считает, показывает и шлёт уведомления, но не пишет в учёт ни строчки. За это время видно, сходятся ли её цифры с отчётами бухгалтерии. Если не сходятся, виновата интеграция, а не учёт, и чинится она без последствий для данных.
3. 3Тестовый контур на копии. Запись включается сначала на копии рабочей базы, развёрнутой из вчерашнего бэкапа. Прогоняем 30–50 реальных документов и сверяем результат построчно с тем, что сделал бы человек.
4. 4Пилот на одном участке. В бою запись стартует на одном складе, одной группе документов или одном менеджере. Объём маленький, цена ошибки — копейки, откат делается руками за полчаса.
5. 5Расширение по цифрам, а не по календарю. Следующий участок подключается после недели без расхождений на предыдущем. Если расхождения есть, разбираем их, а не двигаемся дальше.

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

Отдельный страх — обновления вендора. Ломает интеграцию не сам факт обновления, а изменение структуры данных под ней. Если работаем через HTTP-сервис в расширении, типовое обновление конфигурации нашего кода не касается: расширение живёт отдельным файлом и переживает релиз. Если читаем таблицы напрямую, обновление может переименовать или разбить таблицу, ночная выгрузка встанет, а заметите вы это утром по пустому отчёту. По нашей практике на типовой 1С за год случается одно-два обновления, требующих вмешательства, и каждое стоит 2–4 часа работы, а не переделки проекта. Именно это и есть содержание строки поддержка в договоре.

• Контракт данных: письменно зафиксированный список полей и их смысла. Любое расхождение с ним — событие с понятной процедурой, а не сюрприз.
• Мониторинг выгрузок: если ночная синхронизация вернула ноль строк или на 40% меньше обычного, алерт приходит инженеру раньше, чем вы откроете отчёт.
• Тестовый прогон на копии перед плановым обновлением 1С — 2–3 часа, при условии что о дате обновления сказали заранее.
• Окно сопровождения после обновления: сутки повышенного внимания и правка карты полей в тот же день.
• Код в расширениях, а не в типовой конфигурации, чтобы ваша 1С оставалась на поддержке вендора и обновлялась штатно.

Когда систему всё-таки придётся менять

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

• Единой базы нет вообще: учёт живёт в файлах на компьютерах сотрудников. Подключаться не к чему — сначала нужна система записи, любая.
• 1С версии 7.7 или конфигурация с пятнадцатилетними доработками без исходной документации, где любое изменение стоит как отдельный проект. Здесь дешевле переехать на типовую, чем каждый год платить за археологию.
• Система физически не хранит нужный факт: нет привязки заказа к менеджеру, нет себестоимости по партиям, нет даты обещанной отгрузки. Добавить поле в чужую самописную систему бывает дороже, чем перейти на типовую конфигурацию.
• Файловая база и 40 одновременных пользователей: она тормозит сама по себе, и любая дополнительная нагрузка ухудшит то, что и так болит. Тут первый шаг — перевод в клиент-серверный режим, а не автоматизация.
• Вендор ушёл с рынка, обновлений безопасности нет, поддержка невозможна. Это уже вопрос рисков, а не удобства.

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