Собери сам, или Как живут ИТ-системы на «1С»
Казалось бы, если в компании все на 1С — бухгалтерия, склад, зарплата, производство, то и жизнь должна быть простой: единая платформа, единые данные, минимум проблем. Но на практике все устроено иначе. Модули 1С не всегда работают как единый организм. Что-то требует доработок, где-то всплывают сложности при обновлениях, а где-то интеграции между «своими же» системами превращаются в отдельные проекты с отдельным бюджетом.
Именно поэтому после первого круглого стола, посвященного 1С, ИТ-директора сами предложили продолжить разговор — но уже не про платформу в целом, а про архитектуру. Про то, как устроены реальные проекты, где заканчиваются возможности типовых решений и начинается настоящая инженерия. Почему даже внутри одной экосистемы все не так очевидно. И когда стоит выбирать готовые модули, а когда — идти в сторону от 1С, несмотря на всю кажущуюся «удобную среду».
Эту встречу журнал IT Manager и клуб ИТ Диалог посвятили именно архитектурным развилкам…
Стандарта нет и быть не может
Открыл круглый стол модератор Иван Козлов, ИТ директор группы Латео и директор по развитию клуба ИТ-Диалог с вопроса из обсуждений в группе сообщества, который разделил его на две равные половины: Что делать с бухгалтерией в архитектуре 1С? Держать внутри ERP, чтобы все было «в одном флаконе»? Или выносить за пределы системы, бережно оградив от проблем с обновлениями?
Денис Окулов: «Типовая "1С" как 10 нужных книг. Но чтобы их выбрать, надо прочитать 10 тысяч»
Одни настаивают, что бухгалтерия должна быть внутри ERP — мол, иначе теряется целостность данных. Другие уверены: проще и безопаснее вынести ее наружу и оставить нетронутой. По словам
Александра Нараева
, руководителя направления 1С ERP «АНТ — Цифровые Сервисы», даже при переходе на 1С:ERP, логика «бухгалтерия отдельно» сохраняет смысл, особенно когда речь идет о стабильности, обновлениях и взаимодействии с нервными, но крайне важными бухгалтерами. Поэтому бухгалтерию лучше не трогать. Бухгалтерия должна жить своей жизнью и обновляться спокойно. Все, что нужно для бизнеса, лучше выносить в отдельные решения и аккуратно интегрировать. По сути, он предложил компромисс: бухгалтерия — как монолит, ERP — как гибкий инструмент вокруг нее.
Суть спора, по мнению директора департамента ИТ Олега Смирнова (ИТ-холдинг Fplus), не в «местоположении» бухгалтерии, а в модели учета. Типовая бухгалтерия — это одно. Но если выстраивать систему на управленческом учете, где проводки формируются автоматически по правилам, то и бухгалтерия становится всего лишь отражением бизнес-операций. А не отдельным модулем, с которым нужно синхронизироваться.
Такой подход особенно актуален для сложных компаний с несколькими системами и высокими требованиями к целостности данных. В этом случае разнесенная архитектура может оказаться невыгодной: слишком велика цена поддержки и риски рассинхронизации.
Что делает 1С одновременно гибкой и противоречивой платформой? В отличие от западных систем, вроде SAP, здесь не существует догмы: «все должно быть так и никак иначе». Каждый проект — это выбор. И каждый выбор — это ответственность.
Главная же беда 1С — в том же, в чем и ее главное преимущество. Платформа настолько гибкая, что соблазн сделать «по-своему» возникает у каждого второго ИТ-директора. И кастомизация растет вширь, вглубь и по диагонали. В результате системы становятся уникальными и... трудно обслуживаемыми.
Именно 1С избаловала рынок возможностью переделывать все что угодно под любые требования. Это дает свободу, но накладывает и обязательства: регулярные обновления, тестирование, синхронизация — все это влечет за собой накладные расходы.
Если бухгалтерия вынесена наружу, организация становится зависимой от обмена и его сопровождения. Значит, нужны стабильные интеграторы, готовые поддерживать актуальность и быстро реагировать на сбои. А если все собрано в одной конфигурации — придется быть готовым к аккуратным и своевременным обновлениям.
ERP как дом с пристройкой или монстр с крыльями
Если бы можно было просто один раз внедрить 1С:ERP и больше к ней не прикасаться — архитектурные споры были бы в разы проще. Но увы, обновления — неизбежность. И чем больше у системы связей, тем громче может быть взрыв.
Сергей Анциферов
, ИТ-директор сразу трех заводов в Энгельсе, знает это на практике. Его предприятия работают с ERP, в которую включен регламентированный учет. Все вроде бы работает. Но стоит начать обновление, как сразу всплывают зависимости. ERP у него интегрирована с PDM, LIMS и системами документооборота. Где-то интеграция бесшовная, где-то — не очень, но в любом случае каждое обновление требует танцев с бубном. Иногда — с огнетушителем. Даже при использовании расширений и сохранении конфигурации на поддержке, изменения в одной системе могут поломать ролевую модель в другой. Как отмечает Сергей, «обновлении LIMS повлияло на ролевую модель в ERP, пришлось ее дорабатывать. Могут сбиваться расчеты себестоимости, иногда — закрытие периода», и на решение подобных багов приходится тратить время и ресурсы, проводить дополнительное тестирование.
Поэтому внешняя бухгалтерия могла бы частично изолировать регламентированный контур от этих коллизий: обновляешь ERP — и не трогаешь учет. Но есть и обратная сторона — интеграции. А значит, все равно остаются риски и потребность в ее дополнительной поддержке.
Когда речь идет о больших компаниях, вопрос о месте бухгалтерии, кажется, перестает быть вопросом. «Бухгалтерия должна быть внутри ERP», — считает Роман Викторов, заместитель генерального директора по ИТ компании «Карелия Палп». По его опыту, любое другое решение дороже( и с точки зрения интеграции, и с точки зрения поддержки, и тем более при обмене данными). Поэтому регулярное обновление ERP — это вполне решаемый процесс. При наличии отлаженных процедур и использования расширений, обновления укладываются в два дня: один на реализацию, один на тестирование. Исключение — масштабные переходы между версиями, но даже они проходимы.
Однако идеальную картину резко разбивает
Владимир Шершун
, директор по развитию и цифровизации компании «Северная Столица». Он приводит пример производственного предприятия, где доработки поручили напрямую фирме 1С. Пока писали под версию 2.1, вышла 2.2. Пока адаптировали под 2.2 — появилась 2.4. Сейчас система так и осталась на промежуточной версии, с «монстром» из пяти доработанных подсистем. Про оперативные обновления и «расширения» в таком сценарии можно забыть: каждое движение — дорого и долго.
В другом кейсе той же группы компаний решили начать с бухгалтерии. Все шло по плану, пока не дошли до производственного документооборота — и число документов выросло с 12 до 47. Это вызвало настолько жесткое сопротивление со стороны бухгалтерской команды, что ее пришлось полностью выводить в отдельный контур. По сути, бизнес-процессы задавили стандартную логику ERP.
Вывод звучит однозначно: если кастомизация в проекте глубокая, особенно в части производства, бухгалтерию лучше выносить за пределы ERP. Только так можно сохранить управляемость и не попасть в ловушку вечных доработок и откатов.
Где заканчивается ИТ и начинается бизнес
Вопрос о месте бухгалтерии — вовсе не про архитектуру. Это про власть. Про то, кто в компании реально принимает решения и кто готов нести за них ответственность.
Максим Каранкевич
, директор по данным и цифровой трансформации компании «Ультрамар» прямо говорит: бухгалтерия должна находиться там, где это выгодно бизнесу. Не ИТ-директору, не интегратору, не методологу. Только бизнес может расставить приоритеты — удобство, контроль, скорость, прозрачность. У кого-то это две базы УПП: одна бухгалтерская, другая производственная. У кого-то — бухгалтерия живет в 1С, а ERP — вообще на других решениях.
Поэтому выбор архитектуры — это результат договоренности между главным бухгалтером, финансовым директором и владельцем. Все остальное — уже вопрос техники. Но если в компании нет сильного главбуха, то ИТ берет инициативу на себя. И наоборот, если бухгалтер требует «как в Аксапте», это уже повод выставлять коммерческое предложение.
Особая история — когда главбух и финдир совмещены в одном лице. Тогда контроль за оперативным учетом становится частью бухгалтерской зоны ответственности и требования к системе меняются: бухгалтерия в ERP — уже не компромисс, а способ контролировать производство в реальном времени.
Особую сложность вносит и государственный учет. Если у компании есть обязательства по господходам, это накладывает ограничения на структуру данных, на правила формирования проводок, на детализацию отчетности. В такой ситуации разделение учета может быть не просто желательным, а обязательным — чтобы не смешивать несовместимое.
Редко удается работать с «чистого листа». Как правило, на предприятии уже есть сложившаяся ИТ-среда — старые системы, внешние модули, BI, зарплатные продукты, иногда даже парковочные терминалы и системы доступа. Все это — наследие, с которым нужно считаться. А значит, подход к архитектуре определяется не только логикой, но и историей.
Формально почти все участники соглашались: архитектуру нужно подстраивать под бизнес. Но за этой дипломатичной формулой — вполне осязаемое напряжение. Особенно там, где техническое мнение ИТ вступает в противоречие с решением бухгалтерии или финансового блока.
Один из типичных сценариев: главбух настаивает на интеграции, видя в ней простое и понятное решение. ИТ-директор, напротив, видит подводные камни, которые всплывут через полгода — в сопровождении, обновлениях, ошибках на стыке. Но возражать бесполезно: ответственность размазана, а бюджет «не его». В таких случаях ИТ не должен играть в героев или спасателей. Выбор всегда остается за владельцем, финдиром и главбухом, но ИТ должно дать им инструменты для осознанного решения.
Существует еще еще одна ловушка — иллюзия просчитываемости. Архитектурные решения обычно сравнивают в моменте: сколько стоит интеграция, сколько — поддержка. Но бизнес редко делится с ИТ своими стратегическими планами. А значит, оценка «правильности» архитектуры делается в информационном вакууме. На выходе получается типичная ситуация: ИТ может все — бухгалтерию поддержать и внутри, и снаружи, но потом же все это и разгребает. Поэтому вопрос даже не в архитектуре. А в том, кто готов брать ответственность, а кто — только выписывает требования.
Наследие против будущего: УПП, LTS и 8.5
Официальные релизы развиваются, но живут они не в вакууме, а рядом с десятками устаревших, но все еще работающих конфигураций. На УПП до сих пор сидит немало предприятий — не из упрямства, а по вполне рациональным причинам. Особенно это касается специфических отраслей вроде алкогольной, где обмен с ЕГАИС давно налажен, а новые требования, такие как маркировка, пока лишь в перспективе.
Тем временем мир вокруг двигается дальше. С выходом ERP 2.5 и появлением LTS-версий 1С попыталась успокоить рынок: долгоживущие релизы должны были снять тревогу вокруг вечных доработок и внезапных обновлений. И в этом есть реальный смысл: если верить обещаниям, LTS-модель избавит внедренцев от шока, когда при обновлении система неожиданно удаляет полсотни документов и добавляет столько же новых.
Однако иллюзий никто не питает. LTS хоть и помогает с управленческими блоками, бухгалтерии это не касается: ее все равно придется обновлять. К тому же и срок жизни таких версий — отнюдь не «лонгтерм», а скорее «пара лет». И значит, все равно придется следить за изменениями и адаптироваться к ним.
На горизонте — новая платформа 8.5. Участники уже начали ее изучать, и пока основной вопрос — даже не функциональность, а интерфейс. Большая часть текущих решений перегружена кастомизированными формами, и «воздушный» дизайн 8.5 пока вызывает не радость, а опасения. Один из главных страхов — что пользователи снова испугаются нового интерфейса, как уже бывало. Только теперь информации в формах стало еще больше и комфорт от легкости может обернуться потерей управляемости.
Однако с запуском платформы 8.5 у разработчиков 1С впервые за долгое время появился повод для сдержанного оптимизма. Новая оболочка «1С:Воздух» обещает решить ту самую старую проблему, из-за которой компании уходили на React и JavaScript для построения АРМов, панелей, мобильных интерфейсов. Если раньше написать полноценный интерфейс для производственного сотрудника в 1С было невозможно, то теперь многое меняется.
Обновленный интерфейс предлагает карточный дизайн, векторные иконки, масштабируемость, адаптивную структуру. Да, визуально он может отпугнуть консервативных пользователей. Но на фоне того, что многие конфигурации перегружены сложными формами и закладками, «воздух» дает возможность все упростить — и наконец сделать красиво внутри экосистемы, а не сбоку от нее.
Но 8.5 — это не только оболочка. В платформу встроен «1С-напарник» — первый шаг к появлению полноценного ассистента, который сможет помогать в построении аналитики и настройке конфигураций. Пока бизнес не готов формулировать такие запросы напрямую.
Выход платформы 8.5 участники обсуждали уже без скепсиса — как нечто неминуемое. Возможности нового интерфейса, переход в сторону веба, мобильные сценарии, гибридный режим — все это, по мнению большинства, выглядит разумной и давно назревшей эволюцией.
Существует также риск, который часто уходит из поля зрения: сама платформа развивается быстрее, чем прикладные решения успевают адаптироваться. ERP 2.5, на которую сейчас переходят многие, — не финальная точка. Вероятно, появится ERP 3.1 или что-нибудь похожее, уже под 8.5. А значит, крупные компании, завершив миграцию, почти сразу столкнутся с новой волной изменений. Рано или поздно 8.3 перекратит обновляться, и это станет моментом истины для всех, кто еще сомневается.
Монолит или шина?
Архитектурная карта мира все чаще рисуется с шиной данных в центре. На слайдах она выглядит безупречно: аккуратный квадрат посередине и венок из разнопрофильных систем по краям. На конференциях кивают, соглашаются, говорят, что это «будущее» и «путь вперед».
Но стоит задать прямой вопрос: а что не так с монолитом? — и идиллия трещит. 1С ERP вопреки моде до сих пор остается в логике цельной системы. И даже вендор внятно рекомендует: все, включая бухгалтерию, по возможности держать внутри. «1С по-прежнему идет в сторону монолита», — отметил Иван Козлов, поставив под сомнение универсальность шинной модели.
Шина данных — не дань тренду, а практический ответ на задачи, с которыми 1С справляется не всегда. Управление оборудованием, сбор показаний с контроллеров, интеграция с MES и СУТП — все это выходит за пределы типовой ERP. Поэтому, если на предприятии работает множество специализированных решений, шина становится не идеологией, а необходимостью. Архитектура зависит не от моды, а от зрелости ИТ-ландшафта. Там, где автоматизация глубоко заходит в цеха и оборудование становится частью управленческого контура, именно шина позволяет соединить данные и принять решения.
Есть и компромиссные подходы. Например, использование бесплатного коннектора от СофтБаланс к RabbitMQ, который позволяет без серьезной переделки заменить транспорт в уже работающей интеграции. Архитектура не меняется, просто появляется возможность мониторить обмен.
Шина действительно оправдана, когда в ландшафте десяток разнородных систем — 1С, Oracle, SQL, веб-приложения. Но если все строится вокруг 1С, интеграция через стандартные интерфейсы выглядит куда логичнее. Разве что речь идет о MES — тогда да, без шины и правда не обойтись, хотя бы чтобы не перегружать базу.
Вопрос о необходимости шины данных оказался куда менее теоретическим, чем могло показаться на старте обсуждения. Проблема упирается в масштаб и архитектуру: если у вас всего пара систем, «точка-точка» действительно дешевле. Но как только систем становится больше — уравнение меняется.
«До тех пор, пока тебе не надо сделать пять точек, тебе и шина не нужна. Но когда начинается «многие ко многим» — все, шина неизбежна», — поясняет
. Но думать о шине нужно заранее, если есть перспектива роста.
Мониторинг тоже стал аргументом. В «коробочной» 1С мониторинг интеграций невозможен в принципе. Шина закрывает этот пробел. «Хоть кто-то должен смотреть в одно окно — или хотя бы получать алерты, а не узнавать через два дня, что у тебя не прогрузились документы», — добавляет Евгений Титов, директор по ИТ «Завод Продмаш».
Конечно шина — не панацея. Для тех, кто живет исключительно внутри 1С-ландшафта, можно обойтись и типовыми обменами. Но как только в схеме появляется сторонняя WMS или PDM, ситуация резко меняется: писать кастомные интеграции долго, дорого и небезопасно.
DATAREON, 1С-шина или open source
Судя по обсуждению, сегодня на рынке сформировались четыре условных лагеря — сторонники DATAREON, приверженцы 1С-шины, энтузиасты open source (вроде RabbitMQ и Kafka) и те, кто до сих пор сидит на старых COM-коннекторах. Спойлер: у всех свои боли, и ни у кого нет магического решения.
В портфеле Владимира Шершун проекты и на где роли шины исполняли такие продукты как RabbitMQ, и Apachе Kafka + Kafka REST Proxy, так и на интеграционном решении 1С-ШИНА и DATAREON. «RabbitMQ — это игрушка, разворачивается за вечер. Продукты Kafka сложнее, DATAREON — серьезный промышленный продукт, 1С-ШИНА пока сыра», — уверен он.
Главный плюс DATAREON — зрелость. Он существует с 2014 года, оброс десятками коннекторов и умеет работать с самыми разными источниками. «Мы в него интегрировали вообще все предприятие, даже МСК — и все работало стабильно», — отмечает Владимир. Дополнительный бонус — встроенный MDM и удобные средства для разрешения конфликтов в интеграции: по логам можно точно понять, где потерялись данные и кто виноват — ваша команда или подрядчик.
На этом фоне 1С-шина выглядит как младшая сестра. Она действительно дешевле и «родная» в экосистеме, но, по мнению участников, пока вызывает вопросы и требует доработки. На форумах разработчики регулярно жалуются на тупиковые ситуации, когда стандартными средствами решить задачу не удается. Впрочем, потенциал у нее есть.
Для легких кейсов вполне жизнеспособен и open source: тот же RabbitMQ совместно с коннектором от СофтБаланс, который можно внедрить за пару дней Но с такими решениями всегда возникает вопрос безопасности. Если она критична — лучше идти в коммерцию. Если нет — можно ставить.
Однако встает вопрос: кто будет всем этим управлять? Один из ключевых аргументов против — дополнительная нагрузка на ИТ-подразделения. «Знакомый внедрил шину данных – теперь у него все красиво интегрировано, но с тех пор в штате плюс пять человек, только чтобы шину поддерживать», — делится Иван Козлов. Вопрос надежности тоже оказывается критичным. Главный минус 1С-шины — отсутствие кластеризации, что делает ее потенциальной точкой отказа. В отличие от Kafka или RabbitMQ, которые можно развернуть в отказоустойчивом режиме.
Кроме того, зрелость продукта. В корпоративных сценариях предпочтение часто отдают решениям вроде DATAREON, поскольку они обеспечивают не только транспорт, но и обвязку: от мониторинга до MDM. Впрочем, и этот выбор не универсален — все зависит от масштаба и требований конкретного предприятия.
Экосистема 1С. Миф или стратегия выживания?
Вопрос о том, можно ли всерьез считать 1С экосистемой, вызывает немало эмоций. На первый взгляд все похоже: продукты на одной платформе, общий интерфейс, единый стек. Но как только начинается разговор о реальных сценариях, картина усложняется.
Пока речь идет о едином ERP-решении — да, можно говорить о целостной среде. Но как только появляются отдельные продукты (ЗУП, ДО, бухгалтерия и т. п.), их интеграция требует усилий и не происходит «из коробки». Более того, ориентация исключительно на 1С может отрезать доступ к специализированным отраслевым решениям, которые в ряде случаев объективно сильнее.
Академическое определение экосистемы — это не только продукты, но и сообщества, стандарты, совместимость, поддержка. При должной настройке, уверены многие участники, все это действительно можно собрать и заставить работать — вопрос зрелости и ресурсов.
Именно поэтому при выборе новых систем аргумент «у нас уже есть своя команда по 1С» зачастую перевешивает функциональные достоинства конкурентов. Тем не менее участники едины в одном: если у предприятия сложный ландшафт с множеством внешних систем (особенно в производстве), замыкаться только на 1С нельзя. Экосистема — это не только удобство и унификация, но и риск упустить более сильные решения, если смотреть только внутрь.
Выбирать между 1С и сторонними решениями — не просто вопрос вкуса, а расчет на перспективу. Базовые блоки вроде зарплаты или ERP — безусловно, зона 1С, и с этим никто особенно не спорит. Но стоит взглянуть в сторону более сложных систем — например, MES — как уверенность резко снижается.
Системы, управляющие оборудованием и собирающие данные с датчиков, редко чувствуют себя комфортно в архитектуре 1С. Даже при наличии сильной внутренней команды риски ограничений становятся очевидны. Пример с WMS — еще один маркер. Если склад простой, 1С справляется.
Если задачи сложнее — например, присутствует управление холодильниками или требуется высокая производительность — уже приходится смотреть на специализированные продукты вроде Solvo или Logistics. Они не из дешевых, но иногда просто нет другого выбора, считает Максим Каранкевич.
Тем не менее даже самые технологически продвинутые решения упираются в вопрос поддержки. Если в штате нет нужных специалистов, а рынок предлагает их по высокой цене и в дефиците — выбор становится очевидным. Стоимость владения снова выходит на первый план.
1С: гибкость, но по какой цене?
Возможность быстро изменить и адаптировать под себя — одновременно главное достоинство и головная боль платформы 1С. Именно эта «переписываемость» и становится критерием выбора: если понятно, что бизнесу придется подстраиваться под логику системы, а не наоборот — возможно, стоит посмотреть на другие решения.
Сложные задачи — например, связанные с большим количеством пользователей, личными кабинетами, аналитикой — заставляют пересматривать привычные рамки. По мнению
, свежие продукты 1С, такие как «Элемент» и новые инструменты аналитики, могут стать не только технологическим решением, но и стимулом к росту для самих разработчиков: «Хочешь не хочешь, кругозор придется расширять».
Хотя 1С и не позиционируется как система для высоконагруженной аналитики «из коробки», при работе с большими объемами данных ее возможности можно существенно расширить — за счет настройки и подключения специализированных решений. Прогресс в новых релизах очевиден: в платформе 8.5 появляются бессерверные вычисления и прямая интеграция с оборудованием, что открывает новые архитектурные сценарии.
Впрочем, вопрос не только в технологиях, но и в людях. Если команда уже знакома с 1С, переход на нее даже с западных систем может оказаться проще, с учетом всех «напильников». Этот фактор часто становится решающим в выборе платформы.
Даже при том, как быстро развивается платформа, все по-прежнему упирается в одно — в готовность компании вкладываться. В доработки, в архитектуру, в людей. Возможности у 1С есть — и немалые. Но и цена вопроса растет: вместе с масштабом растут бюджеты, вместе с гибкостью — требования к качеству решений, а вместе с релизами — зарплаты хороших специалистов.
Так и завершился круглый стол: без универсального рецепта, но с пониманием того, что 1С остается мощным, но требовательным конструктором. На ней можно собрать и простую витрину, и сложный цифровой завод. Только прежде чем начинать сборку, стоит ответить на вопрос: кто это будет делать — и хватит ли ресурсов довести до конца.