Два архитектурных класса программ для лаборатории
Когда лаборатория выбирает программу учёта протоколов, вопрос быстро сводится не к списку функций (у большинства решений он похож — приборы, персонал, протоколы, выгрузка в реестр), а к тому, на чём это построено. На рынке встречаются два основных подхода: надстройки поверх платформы 1С и веб-системы, работающие через браузер без установки клиентского приложения. Разница между ними — не косметическая, она определяет, как лаборатория будет жить с программой годами.
Как устроено решение на 1С
1С-надстройка — это конфигурация, которая разворачивается поверх знакомой многим бухгалтерам и экономистам платформы. Для организаций, где уже есть 1С-инфраструктура и штатный специалист, который умеет её администрировать и дорабатывать, это может быть логичным продолжением того, что уже есть. Но у этого подхода есть системная особенность: нестандартные доработки — новый отчёт, изменение бизнес-логики под специфику лаборатории — обычно требуют программиста 1С, а сама платформа исторически ориентирована на работу с рабочего места, а не «из поля» с телефона или планшета.
Как устроена веб-система
Веб-система работает через обычный браузер: сотруднику ничего не нужно устанавливать, а доступ к календарю выездов, протоколу или справочнику приборов одинаков что с рабочего компьютера, что с планшета на объекте. Обновления в облачном варианте выходят на стороне поставщика, а при развёртывании на своём сервере — применяются пересборкой образов и автоматическими миграциями при запуске, без ручной правки конфигурации.
Оборотная сторона: если у лаборатории уже отлажены процессы вокруг 1С — бухгалтерия, склад, кадры — переход на отдельную веб-систему означает, что учёт протоколов будет жить не в той же экосистеме, а рядом с ней, как самостоятельный инструмент со своей интеграцией с ФГИС.
Ещё одно практическое следствие архитектуры: у веб-системы, как правило, единая точка обновления — либо у поставщика в облаке, либо через пересборку образов на своём сервере, — а у 1С-конфигурации обновление часто означает согласование версии платформы, установленных модулей и доработок, чтобы новая версия конфигурации не сломала то, что уже настроено индивидуально под лабораторию.
Как это сказывается на работе с ФГИС
Оба класса решений в теории способны формировать XML-пакет по приказу № 704 и синхронизировать справочники из личного кабинета ФГИС — сама по себе интеграция с реестром не является привилегией одной архитектуры. Разница проявляется не в принципиальной возможности, а в скорости, с которой решение адаптируется под изменения формата или требований: у веб-системы с централизованными обновлениями это, как правило, изменение на стороне поставщика, которое лаборатория получает вместе с очередным обновлением; у 1С-конфигурации — это доработка, которую нужно инициировать и протестировать отдельно, особенно если конфигурация уже кастомизирована под конкретную лабораторию.
На что реально смотреть при выборе
Вопрос «1С или веб-система» решается не абстрактно, а через несколько конкретных вопросов к самой лаборатории:
- Есть ли в штате специалист, который может администрировать и дорабатывать 1С, или это ляжет на подрядчика по часовой ставке?
- Нужно ли инженерам вносить данные прямо на выезде — с планшета или телефона, без доступа к стационарному рабочему месту?
- Насколько быстро нужно начать пользоваться системой — от развёртывания веб-решения в облаке до первого протокола обычно проходит меньше времени, чем от закупки и настройки 1С-конфигурации под задачи конкретной лаборатории.
- Важна ли лаборатории интеграция учёта протоколов именно с остальной 1С-экосистемой организации, или это два независимых контура?
Выбор архитектуры и вопрос сервера или облака
Для веб-систем встаёт ещё один вопрос — где физически разворачивать программу: на своём сервере или в облаке поставщика. Это отдельное решение со своими компромиссами по контролю над данными, скорости старта и тому, кто отвечает за обновления; подробно оно разобрано в статье «Своё серверное решение или облако».
Как устроена ЛИМСИ
ЛИМСИ — веб-система: сотрудникам ставить нечего, достаточно браузера, в том числе на планшете в поле. Она разворачивается либо на своём сервере (Docker Compose, PostgreSQL, свой домен и HTTPS), либо в изолированном облачном пространстве лаборатории — оба варианта закрывают путь от планирования выезда до XML-пакета для реестра ФГИС без привязки к отдельной 1С-инфраструктуре. Что при этом входит в стоимость внедрения — в статье «Сколько стоит автоматизация лаборатории».
Сравнить конкретные сценарии проще на демонстрации — на своих данных виднее, какая архитектура реально экономит время, а не только красиво выглядит в презентации.
Мобильность как решающий фактор
Для многих испытательных лабораторий — особенно тех, что выполняют экологические, строительные или электротехнические измерения на выезде, — вопрос доступа «из поля» оказывается решающим сам по себе, независимо от остальных сравнений. Если инженер вносит данные измерений на месте, с планшета, а не переносит их вечером с бумажного бланка в компьютер в офисе, разница между архитектурами перестаёт быть теоретической: это либо возможно сразу через браузер, либо требует отдельного мобильного решения поверх основной системы.
Стоит ли менять архитектуру, если уже есть работающее решение
Если в лаборатории уже используется 1С-конфигурация и она в целом устраивает, смена архитектуры ради архитектуры редко оправдана — это дополнительные трудозатраты на перенос данных и переобучение сотрудников. Вопрос выбора между 1С и веб-системой актуальнее всего тогда, когда лаборатория только внедряет систему учёта протоколов впервые или когда текущее решение уже упирается в конкретные ограничения: невозможность работать из поля, долгие сроки доработок, зависимость от одного специалиста, который умеет администрировать конфигурацию.