Денис Окулов: Типовая 1С как 10 нужных книг. Но чтобы их выбрать, надо прочитать 10 тысяч

Денис, мы с сообществом «ИТ-Диалог» провели уже второй круглый стол по «1С», и последний был про архитектуру. Так актуальна эта тема. А какой подход вы считаете наиболее перспективным при внедрении и развитии «1С» в крупных компаниях?

Если говорить про цифровизацию на крупных предприятиях, особенно производственных, уже недостаточно просто внедрить ERP — даже если это современная система на базе «1С». Сейчас запрос идет на комплексную автоматизацию, где ERP — это только часть большого слоеного ландшафта.

Речь идет о связке с другими классами систем: MES, EAM, SCADA, IIoT и др. Все это должно работать в единой архитектуре. И подход, который сейчас чаще всего применяется, — это доменно-ориентированная архитектура, или domain-driven design. Он хорошо себя показал еще во времена “расцвета” SAP: каждый модуль отвечает за свою предметную область, модули взаимодействуют между собой через интеграции. Сейчас, когда многие переходят на «1С», подход остается тем же — и это, на мой взгляд, наиболее жизнеспособная модель.

А что с размещением решений — где оправдано облако, а когда лучше локально?

Вопрос чувствительный. Многое упирается в восприятие и политику безопасности. Пока в большинстве компаний сохраняется недоверие к облачным решениям. Особенно в тех структурах, где ИБ настроена консервативно: все свое, все под контролем.

Поэтому основной вектор — on-premise, особенно если речь идет о критичных данных. Но бывают ситуации, когда без облака никуда. Например, у нас был проект миграции на крупном автомобильном заводе — у них не было собственной инфраструктуры и на первом этапе, пока шла разработка, мы использовали облачные ресурсы. Это удобно: можно быстро масштабироваться, протестировать систему под реальной нагрузкой. А когда стало ясно, какой нужен объем, заказчик закупил «железо» и мы развернули все у них локально.

Такой гибридный подход эффективен. Для разработки, пилотов, некритичных процессов облако вполне подходит. А вот данные вроде зарплат, коммерческой тайны или, скажем, VIN-кодов — лучше держать в своем контуре.

На круглом столе ИТ-директора говорили, что разделение «1С» на микросервисы не всегда целесообразно. А как вы к этому относитесь?

Давайте я немного «подушню». Очень часто само понятие «микросервис» используется неправильно. Микросервис — это, по сути, когда один бизнес-процесс в рамках бизнес-функции обслуживается отдельным техническим решением. Например, в рамках функции “Казначейство” процесс “Управление ликвидностью” — один сервис, “Осуществление платежей” — другой. То есть реально разные программы, каждая со своей зоной ответственности. Однако в рамках одной функции необходима интеграция данных сервисов между собой для обеспечения согласованности и системности в управлении.

Но ERP-системы — и особенно «1С» — с настоящими микросервисами не пересекаются. Это вообще параллельные вселенные. В мире 1С правильнее говорить о модульности, о доменной архитектуре. Когда, скажем, казначейство — это один инстанс, закупки — другой, а бухгалтерия — третий. Это можно противопоставить монолиту, но к классической микросервисной архитектуре это не имеет отношения.

Если дробить систему разумно, по логике бизнеса и ритмичности обновлений от вендора — это да, сейчас становится трендом. Особенно потому, что монолиты на «1С» в новых, сложных проектах не тянут по производительности и гибкости. Как конструктор LEGO — не получается. А подстроиться под сложный ИT-ландшафт нужно. Поэтому идем в сторону деления, но не в сторону микросервисов в прямом смысле.

То есть «1С» в текущих реалиях — это все же ядро архитектуры. Насколько она вообще справляется с этой ролью? Какие ограничения вы видите?

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

У «1С» структура данных и трансакционная модель сложнее — а значит, выше вычислительная нагрузка. Мы сейчас как раз этим и занимаемся — оптимизируем, тестируем, моделируем. Вот один из кейсов: мы построили нагрузочный стенд, чтобы проверить, потянет ли «1С» производство 40 тысяч автомобилей в месяц. Это примерно 450 тысяч машин в год — уровень АвтоВАЗа в лучшие времена.

И что получается: если взять даже несложное производство, где 2,5 тысячи комплектующих в трех “переделах”, то выходит около пяти миллионов операций в сутки. Мы начали моделировать — и уже на первом шаге стало ясно, что система такой объем просто физически не переваривает. Длительность операций растет, система начинает «задумываться». Сейчас мы видим, что потолок — это, дай бог, 12–15 тысяч автомобилей в месяц. И это пока только на транзакционном уровне.

Дальше мы будем отрабатывать еще два ключевых сценария — расчет потребностей (MRP) и расчет себестоимости. Это следующие этапы. Мы строим стенд именно под нагруженные производственные проекты. Хотим понимать, где пределы и как мы, как интегратор, можем их расширить. Для нас это способ реально выделиться на фоне конкурентов.

Вы сейчас, насколько я понимаю, ответили на вопрос про падение производительности «1С» при больших объемах. А что делать тем, у кого она уже падает? Хорошо, вы строите нагрузочный стенд, а что делать заказчикам прямо сейчас?

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

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

Кроме того, мы сокращаем количество ЦФО, уменьшаем число статей расходов. Раньше, если в «1С» было больше 50 бюджетных статей, система могла буквально зависать — она начинала гулять по циклическим ссылкам. Мы осознанно упрощаем бизнес-цепочки и методологию, чтобы система держала нормальную скорость при промышленной нагрузке.

То есть где-то оптимизируем платформу, где-то — бизнес-практики. Все для того, чтобы добиться внятной, предсказуемой производительности.

Вопрос с техническим уклоном, но попробую. Как у вас выстраивается автоматизация сборки, тестирования и развертывания конфигурации «1С»? Насколько вообще реально в этой среде применить полноценный CI/CD?

Скажу честно: идея хорошая, но в реальности работает далеко не везде. Автотестирование в рамках CI/CD в «1С» имеет смысл только там, где система почти не меняется. Если конфигурация стабильна, можно потратить ресурсы на автоматизацию сборок и автотестов — и это будет работать.

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

Например, заказчик сам что-то дорабатывает, мы параллельно делаем свои изменения, все это живет на одних инстансах. И вот надо это все собрать в единый релиз, проверить, протестировать — и развернуть. А это уже история про ответственность, доступы, контроль версий, стыковку изменений.

Так что в реальности мы чаще думаем не о CI/CD, а о том, как не устроить «войну релизов». Автоматизация развертывания «1С» — это больше красивая идея, чем уже работающий стандарт.

А как тогда выстраивается командная работа, когда над системой трудится несколько команд?

Договариваемся на берегу. Где можно — разделяем ответственность. Иногда разбиваем изменения по релизам: в один — доработки одной команды, в другой — другой. Но полностью избежать пересечений не получается.

В любом сложном ERP-решении функциональные блоки взаимосвязаны. Дорабатываешь что-то в одном — можешь зацепить другое. Так устроена сама система. Поэтому приходится предусматривать риски, закладывать больше времени на тестирование: альфа, бета, промежуточные прогоны. Без этого никак. Это цена за сложность и гибкость, которую дает «1С».

Про производительность при работе с большими справочниками тоже хотела спросить. Какие архитектурные решения у вас реально работают? Например версионирование, синхронная обработка... А на практике?

На практике все гораздо прозаичнее. Версионирование, например, мы стараемся не использовать. Оно просто утяжеляет систему. Нам в большинстве случаев хватает обычного логирования. Главное — не усложнять лишний раз внутреннее содержание.

Кстати, раз уж зашла речь, вернусь на секунду к теме с количеством пользователей. В «1С» это не самая большая проблема. Ну, даже если у завода пять тысяч сотрудников, реально работающих с системой будет не более трех тысяч. Обычно все делится по бизнес-юнитам, у каждого — свой инстанс. И это работает.

А вот большие справочники — это уже серьезнее. Особенно если речь про полуфабрикаты (ДСЕ) — детали и сборочные единицы. Вот их может быть очень много, и именно они грузят систему, т.к. являются одновременно и элементами справочников номенклатуры и ресурсных спецификаций.

У нас был кейс: завод, выпускающий газовые плиты. Мы тогда по неопытности просто взяли и перенесли из PDM-системы всю структуру вложенности. Получилось, что у одной плиты — 160 уровней внутренних полуфабрикатов. Скажем, стекло в дверце: само стекло — это одно, обработанное — уже другое, вставленное в рамку — третье, с уплотнителем — четвертое. И таких «переделов» накапливается сотни.

Но «1С» — не PDM. Это не ее природа. Она учетная и транзакционная, и ее не стоит перегружать такими вещами. Поэтому мы сознательно упрощаем. Сокращаем количество переделов, объединяем однотипные сущности, работаем над структурой справочников. Чтобы было меньше, проще и легче. Это дает заметный прирост по производительности.

Что касается всяких инструментов — синхронной, асинхронной обработки, — тут все индивидуально. Где-то работает одно, где-то — другое. Под конкретного заказчика подбирается конкретное решение. Универсального рецепта здесь нет.

Про устаревшие конфигурации. У многих компаний они до сих пор используются, причем нередко критичны для бизнеса. Как вы решаете такие кейсы? Есть ли вообще мягкий сценарий перехода?

Если честно, мягких сценариев нет. Все упирается в системную простоту старых версий «1С». Они легко дорабатывались — любой начинающий программист мог сесть и что-то нарисовать в конфигураторе. Это казалось удобным, даже, я бы сказал, творческим процессом — когда у человека прямо серотонин вырабатывается от того, что он «созидает».

В результате мы получили тысячи максимально кастомизированных УПП на средних и почти крупных предприятиях. И когда сейчас приходит время переходить на ERP, начинаются сложности. Поддерживать такую же степень кастомизации в новой системе — это долго, сложно и очень дорого. Даже если внедрение типовое, уже год-полтора как бизнес трудно убедить на переход. Аргументы заказчиков понятны: «работает — не трогай».

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

А можете привести пример, где именно грамотная архитектура позволила повысить устойчивость, масштабируемость, отказоустойчивость?

Да, конечно. Я, кстати, частично уже об этом говорил в самом начале — про архитектурный стиль, где вместо одного монолита используются несколько взаимосвязанных инстансов.

Например, у нас может быть несколько систем «1С:ERP», каждая отвечает за свою группу процессов. Это дает два преимущества. Во-первых, нагрузка не концентрируется в одном месте — производительность выше. Во-вторых, у каждого блока свой ритм обновлений.

Вот простой кейс. Вышло новое законодательство по налогообложению нерезидентов. Вендор быстро выпустил релиз. Но если у вас все — от производства до бухгалтерии — в одной системе, вам придется обновлять всех. Это риски, простои, тестирование.

А если, как у нас, бухгалтерия — в одном инстансе, производство — в другом, складская логистика — в третьем, то обновляем только нужное. Финансы — обновились, а производство продолжает работать, не замирает. Все синхронизируется по шине данных, информация передается — и все живо.

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

Я понимаю, что каждый проект — это отдельная история, и о каждом можно делать целое интервью. Но все же хочу задать вопрос про отраслевые особенности. Отличается ли подход к архитектуре «1С» в промышленном секторе? Именно архитектурный — ведь вы как раз работаете с промышленными предприятиями.

Да, отличается. Причем ощутимо. Сегодня ни один серьезный промышленный заказчик не обходится без слоя MES — это уже стандарт. MES-системы, PDM, все, что связано с производственной подготовкой, с ресурсными спецификациями, с техпроцессами, — все это обязательно включается в архитектуру. Наш MES собирает в единую цифровую платформу все ключевые производственные подсистемы предприятия.

Обязательны решения по качеству. У нас есть собственная система QMS, разработанная при поддержке гранта Минпромторга. Она занимается сквозным контролем качества, так называемым цифровым следом. То есть данные об изделии собираются со всех систем, на всех этапах производства.

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

Это уже, можно сказать, “взрослая” цифровизация. Мы выделяем под такие цели отдельные инстансы — не транзакционные, а скорее библиотечные, архивные. Там не тысячи пользователей, а пара человек, которые просто обращаются к этому хранилищу по мере необходимости. Но объем данных — огромный.

Мы специализируемся на промышленности, и у нас — своя логика: системность, полнота данных и сквозная прослеживаемость.

В основном у вас заказчики — производственные компании, и для них, конечно, все это особенно важно. А еще какими собственными решениями вы можете поделиться? Вы упомянули систему по качеству — а что-то еще, на базе «1С»?

Да, мы сейчас активно развиваем то, что сами называем отраслевым шаблоном. У нас есть свой «автомотив» — это не готовая конфигурация, а скорее цифровой шаблон для автомобильной отрасли. Такой минимальный набор функционала и доработок, без которых бизнес просто не “поедет”.

Проблема вот в чем: типовая «1С», в чистом виде, бизнесу недостаточна. Но в то же время кастомизация — штука дорогая и потенциально опасная. Все говорят: «Не кастомизируйте». А бизнес в ответ: «А как жить-то без этого?»

Это как в той шутке: нужно прочитать десять книг, чтобы стать умным, но чтобы выбрать эти десять — надо прочитать десять тысяч. Так и с внедрением «1С»: чтобы понять, что действительно нужно бизнесу, надо сначала пройти через огромный список требований, пожеланий и боли.

Вот мы и решили: давайте отделим необходимое от избыточного. То, что точно нужно, — включаем в шаблон. Все остальное — можно отложить. И это не просто совет уровня «уменьшите кастомизацию», а вполне рабочий подход. Он помогает оптимизировать бюджет, быстрее стартовать и не убиться об интеграции.

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

В состав обоих шаблонов входят наши флагманские продукты. Это платформа PROF-IT MES для оперативного управления производством, уже готовая конфигурация, которая подтвердила свою эффективность у многих заказчиков. И наш новый продукт PROF-IT QMS Professional для сквозного управления качеством, который мы сейчас представляем рынку.

Все решения обкатаны, опыт есть, и мы четко понимаем, где проходит граница между «обязательно» и «можно потом».