Комплексная автоматизация фармацевтического холдинга — это уже не задача внедрения одной ERP-системы. В крупном производственном бизнесе необходимо одновременно решать вопросы централизации финансового и оперативного учета, прослеживаемости партий и сроков годности, контроля себестоимости и регулируемых цен, интеграции разнородных информационных систем, производительности при сотнях одновременных пользователей и управляемого выпуска изменений.
Практика проектов группы компаний «КомЛайн» показывает, что эти задачи целесообразно рассматривать как элементы единой архитектуры. В качестве одного из примеров на вебинаре «Внедрение 1С:ERP на фармпроизводстве» был представлен проект автоматизации крупного российского фармацевтического холдинга на базе 1С:ERP. Управление холдингом, а также подходы к нагрузочному тестированию, интеграции через 1С:Шину и организации DevOps-процесса для решений 1С.
Комплексная автоматизация: от набора систем к единому контуру управления
Казначейство: от фиксации платежей к управлению финансовыми рисками
Склад, серии и сроки годности: единое представление данных
Нагрузочное тестирование: 500 пользователей — это инженерная задача
1С:Шина: интеграционный слой вместо сети «точка-точка»
DevOps для 1С: четыре среды вместо разработки в продуктиве
Что получает ИТ-директор в результате
Вместо заключения: ERP-проект заканчивается не запуском, а созданием управляемой системы
Комплексная автоматизация: от набора систем к единому контуру управления
Одна из типичных проблем крупного фармхолдинга — исторически сложившийся разрозненный ИТ-ландшафт. В рассматриваемом проекте одновременно использовались SAP, 1С:УПП, 1С:ERP, а консолидация данных выполнялась с помощью Excel. Такая архитектура неизбежно увеличивает стоимость сопровождения, усложняет сверку данных и снижает оперативность управленческой отчетности.
Переход на отечественное решение был связан не только с заменой технологической платформы. Целью стало создание единого пространства первичной финансовой информации и унификация процессов между предприятиями группы.
Здесь принципиален сам подход:
ERP в холдинге должна рассматриваться не как автоматизация отдельных функций, а как единая модель данных и процессов, поверх которой строится управленческий контур.
В проекте централизованы закупки, бухгалтерский и налоговый учет, учет затрат и себестоимости, казначейство, бюджетирование. В результате финансовые данные предприятий стали доступны в единой информационной системе, а подготовка, в том числе консолидированной отчетности, была существенно ускорена.
При этом автоматизация затронула практически весь жизненный цикл фармацевтической продукции: продажи, логистику, производство, склад, управленческий и регламентированный учет, ценообразование, бюджетирование, закупки и казначейство. Всего в проекте было реализовано более 120 интеграционных потоков с внешними системами.
Себестоимость как задача не только бухгалтерского, но и управленческого учета
Для фармпроизводства особенно важен вопрос формирования реальной себестоимости. Внутригрупповые перепродажи между производственными площадками могут создавать искусственную наценку: прибыль одной компании группы становится затратами другой. В результате управленческая себестоимость готового препарата оказывается искаженной.
В проекте этот эффект устранялся за счет фиксации базовой цены сырья в момент его первого поступления в контур группы извне. При последующих перемещениях между юридическими лицами расчет управленческой себестоимости производился на основе этой исходной стоимости, а не внутренних цен перепродажи.
Для фармацевтического производства важна и более глубокая детализация: из каких партий сырья сформирована конкретная серия и какие логистические затраты вошли в ее стоимость.
Поэтому в системе был реализован механизм многосценарного моделирования себестоимости. Он позволяет оценивать стоимость будущей серии еще до размещения заказа поставщику, моделируя разные сценарии и учитывая таможенные и логистические расходы. Для дорогостоящих субстанций такая детализация особенно существенна.
Следующий уровень — факторный анализ отклонений. Вместо простого план-фактного сравнения система позволяет разделять влияние валютного курса, логистики, эффективности производства и изменения рыночных цен поставщиков. Это превращает учет себестоимости из инструмента фиксации результата в инструмент поиска причин отклонений и распределения зон ответственности.
Отдельная задача — управление рисками по ЖНВЛП. Система сопоставляет себестоимость сырья с государственной предельной ценой реализации и позволяет заранее выявлять угрозу потери рентабельности. Для бизнеса это означает возможность принимать решения еще до того, как конкретная позиция начнет приносить убыток.
Казначейство: от фиксации платежей к управлению финансовыми рисками
В крупном холдинге финансовый контур тесно связан с закупками, договорами, логистикой и производством. Поэтому автоматизация казначейства дает эффект только тогда, когда платеж можно связать с его экономическим основанием.
В рассматриваемом проекте единый цифровой контур казначейства связал спецификацию, условия оплаты, первичные документы и фактическое проведение платежа. Система автоматически формирует платежный календарь с учетом индивидуальных условий по поставкам, включая разные сроки отсрочки в рамках одного заказа.
Значимым элементом стал предплатежный контроль: заявка на оплату создается только после проверки наличия первичного документа, корректности его отражения в регламентированном учете и соответствующего статуса документа.
Для компаний с привлеченным финансированием особенно важен контроль целевого использования средств. «Умный» реестр позволяет выделять операции, финансируемые за счет заемных средств, и тем самым контролировать соблюдение банковских ковенант.
Такой подход показывает важный принцип комплексной автоматизации:
контроль должен переноситься как можно ближе к моменту возникновения риска, а не выполняться постфактум в отчетности.
Склад, серии и сроки годности: единое представление данных
Фармацевтическая специфика особенно заметна в складском контуре. Обычного количественного учета недостаточно: необходимо учитывать серии, характеристики, места хранения и сроки годности.
В проекте существовал разрыв между оперативной системой, где остатки учитывались с высокой детализацией вплоть до ячейки склада, и финансовым контуром, где использовались обобщенные данные. Для устранения этого разрыва был создан механизм оперативной сверки остатков между системами.
Отдельно автоматизировано резервирование под обесценение запасов. Процент резерва рассчитывается с учетом возраста товара и оставшегося срока годности, причем для готовой продукции и других запасов могут применяться разные шкалы. Это позволяет раньше увидеть потенциальные финансовые потери и принимать меры по реализации «стареющих» остатков.
Для ИТ-директора это еще один показатель зрелости ERP: система должна не просто хранить учетные данные, а превращать отраслевые ограничения — серии, сроки годности, маркировку, карантинные статусы — в машинно исполняемые правила бизнес-процессов.
Нагрузочное тестирование: 500 пользователей — это инженерная задача
После построения функционально насыщенной ERP возникает следующий вопрос:
готова ли инфраструктура выдержать реальную нагрузку?
На тестовой базе несколько десятков пользователей могут работать без видимых проблем. Однако промышленная система крупного холдинга одновременно обслуживает сотни сотрудников, выполняющих разные операции: проведение документов, массовые обработки, формирование отчетов, работу с нормативно-справочной информацией. Параллельно работают фоновые и регламентные задания.
Поэтому проверка производительности должна моделировать не количество подключений, а реальный профиль нагрузки. В рассматриваемом проекте требовалось подтвердить возможность одновременной работы порядка 500 пользователей в одном узле 1С:ERP.УХ.
Для этого использовался «Тест-центр» 1С:КИП (Корпоративный инструментальный пакет). Виртуальные пользователи выполняли сценарии, соответствующие реальной работе: открывали, изменяли и проводили документы, работали со списками и запускали обработки.
Но ключевым этапом перед самим тестом стало определение профиля нагрузки совместно с заказчиком: какие операции выполняются, с какой частотой, какие из них происходят одновременно и какие объемы данных обрабатываются.
Почему 500 пользователей нельзя запускать сразу
Инженерно корректный тест должен показывать не только предельное значение, но и характер деградации.
Поэтому нагрузка увеличивалась ступенчато: 100 → 200 → 300 → 500 пользователей. Такой подход позволяет увидеть, на каком этапе возникает ограничение и какой именно ресурс становится узким местом — процессор, дисковая подсистема, операции ввода-вывода или конкретные пользовательские операции.
Для ИТ-директора это принципиально: вопрос промышленной готовности системы нельзя сводить к бинарному «500 пользователей выдерживает / не выдерживает». Гораздо ценнее получить модель масштабирования, которая показывает, как система поведет себя при дальнейшем росте бизнеса.
Производительность нужно измерять глазами пользователя
Мониторинг инфраструктуры сам по себе не дает ответа на вопрос о качестве работы ERP.
В ходе тестирования необходимо одновременно измерять пользовательские показатели — время открытия формы, проведения документа, выполнения операции — и показатели инфраструктуры: загрузку CPU, очереди, оперативную память, дисковую подсистему, интенсивность чтения и записи, задержки I/O.
Для интегральной оценки пользовательского опыта может использоваться APDEX. Он позволяет свести большое количество измерений к единому показателю и при этом отдельно анализировать критичные операции. Это важно, поскольку хорошее среднее значение не гарантирует, что одна из наиболее важных операций не деградировала при высокой нагрузке.
Тест должен быть воспроизводимым
Нагрузочное тестирование имеет реальную ценность только тогда, когда его можно повторить.
В проекте после каждого прогона сохранялись показатели, удалялись тестовые документы и система возвращалась к сопоставимому исходному состоянию. Благодаря этому после оптимизации можно было запустить тот же сценарий повторно и сравнить показатели APDEX и времени выполнения.
В результате целевая нагрузка была подтверждена без обнаружения критических узких мест, а у команды появилась измеримая модель поведения системы и набор воспроизводимых тестов. В дальнейшем такой набор можно применять после изменения конфигурации, СУБД, оборудования или архитектуры.
Для крупного проекта нагрузочный тест — это не разовая приемка перед запуском, а элемент постоянного управления производительностью.
1С:Шина: интеграционный слой вместо сети «точка-точка»
Чем больше становится корпоративный ИТ-ландшафт, тем дороже обходится интеграция «точка-точка». ERP должна взаимодействовать со складскими и производственными системами, лабораторными решениями, CRM, ЭДО, системами маркировки, BI и внешними сервисами. В гетерогенном ландшафте часть этих систем может работать на 1С, часть — на SAP, а часть — на других технологических стеках.
При прямой интеграции каждая система начинает знать слишком много о соседних системах. Со временем становится трудно ответить на простые эксплуатационные вопросы: куда ушло сообщение, где оно преобразуется, почему не дошло и что произойдет при временной недоступности получателя.
1С:Шина позволяет вынести эту сложность в отдельный интеграционный слой
Вместо множества прямых соединений система-источник отправляет сообщение в шину, а дальше интеграционный слой отвечает за его маршрутизацию, преобразование и доставку.
Асинхронность и гарантированная доставка
Для крупного фармпредприятия особенно важна независимость систем друг от друга. Если внешняя система временно недоступна или работает медленнее источника, ERP не должна становиться заложником этой задержки.
Асинхронный обмен позволяет разорвать непосредственную зависимость отправителя от получателя, а механизм гарантированной доставки снижает риск потери сообщений при временных сбоях.
Другой важный механизм — маршрутизация. Одно событие ERP может потребоваться одновременно складской системе, аналитической платформе и другому корпоративному ПО. В архитектуре с шиной прикладной системе не требуется самостоятельно реализовывать все эти связи.
Интеграционный слой должен уметь «говорить» с разными технологиями
Для корпоративного ландшафта важно, что 1С:Шина не ограничивается системами на платформе 1С. В качестве механизмов взаимодействия рассматриваются HTTP, REST API, SOAP, файловый обмен, FTP, JDBC, AMQP, JMS и другие варианты.
Отдельно важна возможность взаимодействия с SAP PI через JMS. Для компаний, где SAP исторически занимает значимое место, это означает, что интеграционный ландшафт можно трансформировать постепенно: 1С:Шина может стать центром взаимодействия для части систем, сохраняя связь с существующим SAP-контуром.
Это особенно актуально для крупных холдингов: архитектурная модернизация не обязательно должна начинаться с одномоментной замены всего существующего интеграционного слоя.
Главный эффект шины — наблюдаемость
В эксплуатации ценность ESB проявляется не только в разработке новых обменов. Не менее важна централизованная диагностика.
Вместо анализа журналов нескольких приложений команда может контролировать состояние интеграционных процессов: принятые и отправленные сообщения, состояние каналов, доставленные и недоставленные сообщения.
При этом 1С:Шина не устраняет проблемы качества данных и не определяет владельца мастер-данных. Если разные системы по-разному трактуют серию, статус заказа или единицу измерения, сама по себе шина эту семантическую проблему не решит. Но она создает технологическую основу для системного управления интеграциями.
DevOps для 1С: четыре среды вместо разработки в продуктиве
Следующий уровень зрелости ИТ-процесса — управляемое изменение ERP.
Для критичной информационной системы недостаточно правила «разработчик сделал изменение, администратор установил его в продуктив». В 1С обновление затрагивает не только программный код. Могут изменяться метаданные, структура таблиц информационной базы, роли, регламентные задания, интеграционные механизмы и данные, обрабатываемые при обновлении.
Поэтому эффективный процесс строится как последовательность:
DEV → TEST → PREPROD → PROD.
DEV: качество начинается с кода
В DEV разработчики создают и изменяют объекты метаданных, пишут код и выполняют первичную отладку.
Но до передачи версии на функциональное тестирование необходим технический контроль. В рассматриваемом подходе используются штатная проверка конфигурации 1С и статический анализ BSL-кода с использованием SonarQube и BSL Language Server. Это позволяет автоматически выявлять потенциальные проблемы, нарушения правил разработки и технический долг.
Таким образом, еще до функционального тестирования появляется первый качественный барьер:
Разработка → проверка конфигурации → статический анализ.
TEST: проверяется поведение системы
В TEST акцент переносится с качества исходного кода на поведение приложения.
Для автоматизации функциональных сценариев используется Vanessa.ADD, позволяющая реализовывать сценарное, приемочное, BDD-, интеграционное и дымовое тестирование. При этом тестируется не отдельная функция, а полноценный пользовательский бизнес-процесс: например, создание заказа, заполнение реквизитов, добавление номенклатуры, проведение документа и выполнение последующих операций.
Для крупной ERP это особенно важно: чем больше функциональность системы, тем выше стоимость ручной регрессии.
PREPROD: самая недооцененная среда
Главное отличие PREPROD от обычного тестового контура — использование свежей копии продуктивной базы. В рассматриваемом подходе такая копия разворачивается ежедневно, поэтому среда содержит актуальные данные и структуру, максимально близкие к PROD.
Это позволяет воспроизводить реальные проблемы продуктивной системы, которые невозможно воссоздать на искусственно подготовленной тестовой базе. Поведение 1С может зависеть от накопленной истории документов, регистров, настроек, фоновых заданий и состояния интеграций.
Но еще важнее возможность проверить сам процесс обновления.
На PREPROD сначала разворачивается актуальная копия PROD, затем устанавливается релиз-кандидат, обновляется структура базы, выполняются обработчики обновления и проверяется запуск системы. То есть команда отвечает не только на вопрос «работает ли новый функционал?», а на вопрос:
«Может ли реальная продуктивная база корректно перейти на эту версию?»
Для больших информационных баз это принципиально. Обновление, которое без проблем выполняется на небольшой тестовой базе, может вести себя иначе на базе с реальным объемом данных.
PREPROD как полигон производительности
Эту же среду можно использовать для нагрузочного тестирования. Здесь уже есть близкие к PROD объемы данных, актуальная структура базы и именно тот релиз-кандидат, который планируется к установке.
На таком контуре можно проверять одновременную работу пользователей, длительность критичных операций, массовые обработки, регламентные задания, интеграции и запросы к СУБД. Это позволяет обнаружить ситуацию, когда функционально корректное изменение приводит к деградации производительности.
Backup и Restore: резервная копия не равна восстановлению
Для критичной ERP наличие резервных копий само по себе еще не означает готовность к аварии.
Есть принципиальная разница между утверждениями:
«У нас есть backup»
и
«Мы проверили, что из backup действительно можно восстановить работающую систему».
Поэтому DevOps-процесс должен включать контроль успешности резервного копирования, полноты и срока хранения копий, а главное — контрольное восстановление. В рассматриваемом подходе ежедневное развертывание свежей копии PROD в PREPROD одновременно становится практической проверкой цепочки Backup → Restore → Запуск 1С.
Для ИТ-директора это важный переход от формального выполнения регламента резервного копирования к управлению фактической восстановимостью системы.
PROD: промышленная эксплуатация должна быть последним этапом цепочки
В продуктивную среду должен попадать только релиз, прошедший весь предыдущий путь: DEV, TEST и PREPROD.
Перед обновлением выполняется резервное копирование, после чего устанавливается проверенный релиз, выполняется обновление информационной базы и контроль запуска. Далее проводятся короткие дымовые проверки и проверяется работоспособность ключевых функций. Для критических проблем должен существовать заранее определенный сценарий восстановления.
Иными словами,
PROD не является средой разработки и экспериментов. Это финальная точка управляемого процесса
Что получает ИТ-директор в результате
Если рассматривать перечисленные практики вместе, складывается целостная модель управления корпоративной 1С-системой.
Первый уровень — бизнес-архитектура.
ERP объединяет оперативный и финансовый контуры, централизует процессы и формирует единое информационное пространство холдинга.
Второй — интеграционная архитектура.
1С:Шина выносит маршрутизацию, доставку и преобразование сообщений в отдельный слой и снижает связанность систем.
Третий — эксплуатационная архитектура.
Нагрузочное тестирование позволяет измерять реальную производительность, а не оценивать ее субъективно.
Четвертый — инженерная архитектура.
DevOps связывает разработку, контроль качества кода, функциональное тестирование, проверку обновления, нагрузочные испытания, резервное копирование и промышленный запуск в единый процесс.
В результате DEV → TEST → PREPROD → PROD перестает быть набором четырех копий информационной базы. Это становится управляемым жизненным циклом изменения.
Вместо заключения: ERP-проект заканчивается не запуском, а созданием управляемой системы
Для крупного фармацевтического предприятия успешное внедрение ERP нельзя измерять только количеством автоматизированных рабочих мест или перечнем внедренных подсистем.
Зрелость ИТ-контура определяется тем, может ли компания:
- видеть единую картину финансов и операций холдинга;
- управлять себестоимостью на уровне партий и производственных факторов;
- учитывать отраслевые требования к сериям, срокам годности и маркировке;
- контролировать регулируемые цены и финансовые риски;
- интегрировать десятки разнородных систем без лавинообразного роста связей;
- обеспечить производительность системы под реальной нагрузкой;
- воспроизводить результаты нагрузочных тестов;
- безопасно выпускать изменения;
- проверять обновление на актуальной копии продуктивных данных;
- подтвердить не только наличие резервной копии, но и возможность восстановления.
Именно такая связка превращает 1С:ERP из отдельной учетной системы в технологическую основу операционного и стратегического управления фармхолдингом.
В представленном проекте этот эффект подтверждается и измеримыми результатами: закрытие месяца и формирование консолидированной отчетности занимают 3–5 дней, пул заказов формируется менее чем за 10 минут, скорость формирования управленческой и регламентной отчетности выросла на 25%, а операционные расходы и дебиторская задолженность снизились на 15%.
Для ИТ-директора главный вывод здесь не в выборе конкретного инструмента. ERP, интеграционная шина, нагрузочное тестирование и DevOps дают максимальный эффект тогда, когда проектируются как части одной архитектуры — архитектуры, в которой данные становятся управляемыми, производительность измеримой, интеграции контролируемыми, а изменения предсказуемыми.
