Цифровизация фармацевтической отрасли в первую очередь связана с необходимостью повышения эффективности, принятии рациональных решений (Data Driven Decisions) и четком фокусе на основных направлениях бизнеса.
Комплексное и связанное внедрение систем управления информацией на фармацевтических предприятиях приобретает особую значимость. Ранее весь спектр вопросов достаточно эффективно «закрывался» иностранными IT-продуктами, для них был характерен высокий уровень цифровой зрелости и серьезная маркетинговая поддержка.
С уходом иностранных поставщиков с российского рынка и развитием политики импортозамещения возник целый ряд вопросов, в частности, связанных с необходимостью внедрения отечественных IT-решений согласно стандартам и лучшим практикам, источником которых являлись западные страны.
Компьютеризированные системы
Компьютеризированная система включает в себя ввод данных, их электронную обработку и выдачу информации, она используется либо для документального оформления, либо для автоматического управления (GMP ЕАЭС). По сути, это целый комплекс систем, в который входят, в том числе, автоматизированное производственное оборудование, контроль над процессами, управление информацией, материально-производственное планирование, программы надзора и управления документацией. Компьютеризированные системы составляют аппаратные, программные и сетевые компоненты, а также контролируемые функции и соответствующая документация (GAMP5).
На современном фармацевтическом предприятии можно выделить следующие основные используемые компьютеризированные системы:
- система планирования ресурсов предприятия – Enterprise Resource Planning (ERP),
- система управления складом – Warehouse Management System (WMS),
- система управления производственными процессами – Manufacturing Execution System (MES),
- информационно-управляющая система лаборатории – Laboratory Information Management System (LIMS),
- система управления фармацевтической системой качества Quality Management System (QMS).
Каждая из перечисленных систем может являться:
- коммерческой (типовой, настраиваемой), определяемой потребностями массового пользователя и доступной для покупки на рынке. Доказательством ее пригодности к использованию является большое количество конечных пользователей.
В англоязычной литературе применяют аббревиатуру COTS (commercial off-the-shelf, серийно выпускаемое изделие); - разработанной внутри организации (индивидуальной, заказной), то есть созданной для определенного заказчика по индивидуальному заданию так, чтобы она отвечала определенным требованиям пользователя;
- коммерческой с индивидуальными доработками под дополнительные требования заказчика.
В зависимости от типа используемой системы различаются подходы к ее валидации, но об этом немного позже. Сейчас же рассмотрим кейс самой известной в мире ERP-системы, которая сначала завоевала верхний сегмент корпоративного рынка России, стала эталоном и «законодателем мод», а затем покинула наш рынок из-за наложенных санкционных ограничений.
Невероятные приключения SAP в России
SAP – крупнейший в мире поставщик приложений для бизнеса: систем управления ресурсами предприятия (ERP), взаимоотношений с клиентами (CRM), цепочками поставок (SCM) и других. До весны 2022 года решения SAP в России использовали государственные и финансовые организации, компании из сектора торговли, логистики, промышленности, в том числе из фармы. По данным РБК, у SAP в России было около 1500 клиентов.
В марте 2022-го руководство SAP поддержало антироссийские санкции, в апреле немецкий вендор официально завершил свою деятельность в РФ. В сложившейся ситуации пользователи разделились примерно на три равные группы: часть начала переход на российские или дружественные альтернативы, другие, наоборот, стали активно развивать SAP из-за отсутствия доступа к отечественным аналогам в краткосрочной перспективе. Некоторые замерли в ожидании – остались на SAP, но приостановили разработки на платформе, а новые проекты стали запускать с использованием российских продуктов. Эти же компании после ухода технической поддержки западных партнеров оставались на их IT-решениях, получая поддержку с помощью «серых» схем через страны СНГ.
Дальше история развивалась не в пользу тех, кто ожидал возвращения SAP в РФ. Со стороны представителей компании была прекращена продажа лицензий и дополнительных модулей, остановлено обновление и развитие продуктов. У пользователей кратно выросла стоимость владения и доработки ПО, осложнилась работа с РСБУ, налоговым и кадровым учетом. Со стороны государства было запрещено применение иностранного ПО в госструктурах.
Финальные аккорды этого прощального марша звучат уже сейчас. В марте 2024 для российских клиентов был полностью закрыт доступ к облачным услугам SAP, а в июне США снова расширили санкции, распространив запрет на IT-консультирование и поддержку, в также облачные услуги ПО, предназначенного для управления предприятием.
В то же время в России есть целый ряд альтернатив для продуктов SAP: «1С:ERP Управление предприятием», «Парус», DeloPro, CoinCap, ePROMIS business suite, ERPNext, Dia$par, «Галактика ERP», «ТУРБО ERP», многие из них включены в реестр отечественного ПО.
Для себя мы выбрали переход на коммерческую систему «1С:ERP Управление предприятием». Система позволяет организовать учет и бюджетирование, контролировать достижение целевых показателей, проводить долгосрочное и краткосрочное планирование, управлять маркетингом и ассортиментом. Включает блоки CRM (менеджмент взаимоотношений с клиентами), WMS (управление складом), розничных и оптовых продаж, логистики, кадрового учета, управления ремонтом, закупками и производством.
При этом для блоков электронного документооборота, архива финансовых документов, управления проектами и некоторых других мы выбираем IT-продукты, совместимые с 1С, но не входящие в их экосистему. Про эти решения в следующий раз, а сейчас перейдем к вопросу внедрения компьютеризированной системы 1С.
Не просто миграция на другое ПО
Перевод ERP-системы работающего предприятия с SAP на 1С по уровню сложности нам представлялся как хирургическая операция на работающем сердце. Нужно было понять, как при этом «не угробить пациента», да и просто набраться смелости. Поэтому начали с риск-анализа и рассмотрели возможные сценарии перехода. Из всего множества сценариев мы выделили три основных:
- экспресс-переход через интеграцию и обмен данными новой системы 1С со старой SAP,
- поэтапный переход на 1С по отдельным контурам учета,
- полный переход на 1С по всем контурам учета.
Решение было принято в пользу третьего варианта – полного перехода, в котором определили следующий состав работ:
- разработка концепции новой системы,
- настройка и доработка типового функционала системы
(COTS, о котором шла речь в самом начале), - перенос документов и остатков в среде разработки,
- настройка интеграции и обмена данными,
- подключение лицензий,
- развертывание тестовой среды,
- обучение ключевых пользователей,
- тестирование системы,
- создание продуктивной среды,
- запуск системы в промышленную эксплуатацию.
Уже на начальных этапах проектирования пришлось столкнуться с целым комплексом связанных с уходом западных IT-компаний проблем, которые можно назвать типовыми при реализации цифровых проектов:
- практически нет IT-специалистов, имеющих опыт разработки ПО в соответствии с требованиями GMP и GAMP для отрасли фармы.
- разночтения в терминологии и понятийных аппаратах команд разработчиков,
- отсутствие у IT-специалистов опыта документирования, достаточного для формирования валидационного пакета.
В итоге было решено сосредоточиться на процессах проектирования, разработки и внедрения, релевантных опыту поставщиков 1С, а далее организовать валидационные мероприятия. Здесь мы исходим из потенциальной возможности валидировать 1С:ERP при помощи методологий, описанных в руководствах по валидации компьютеризированных систем, с учетом функциональных особенностей данной системы.
Итак, этапы перехода с SAP на 1С:
| Название этапа | Состав работ |
| Этап 1.
Экспресс-обследование процессов |
Интервьюирование ключевых сотрудников, обследование бизнес-процессов, определение необходимых доработок, оценка стоимости и длительности проекта. |
| Этап 2.
Моделирование бизнес-процессов |
Выстраивание действующей функциональной архитектуры, демонстрация работы выбранного ПО, фиксация всех требований к бизнес-процессам, планирование и моделирование новой архитектуры. |
| Этап 3.
Проектирование, разработка и внедрение |
Формирование требований к системе (ТЗ, ЧТЗ, технический проект). Доработка типового функционала 1С, реализация необходимых интеграций, перенос данных, настройка оборудования. |
| Этап 4.
Тестирование новой системы |
Запуск в тестовую эксплуатацию при нагрузках на систему, приближенных к реальным, выявление ошибок и недочетов, корректировка работы системы. |
| Этап 5.
Запуск в промышленную эксплуатацию |
Полный переход с системы SAP на 1С. Обучение ключевых пользователей работе в программе. Оптимизация и реализация дополнительных функций. |
| Этап 6.
Поддержка работоспособности системы |
Сопровождение системы специалистами. Консультации и техническая поддержка. |
В настоящее время мы находимся в стадии реализации этапа 3, но общее понимание того, что будет после внедрения, уже есть. Итак, о валидации.
Валидация компьютеризированной системы
Прежде всего вспомним, что мы имеем дело с коммерческой (типовой) и настраиваемой под пользователя IT-системой, отдельные модули которой подвергаются существенной доработке, не затрагивающей ядра системы.
Воспользуемся классификацией компьютеризированных систем на основании проекта рабочей группы по информационным технологиям (AGIT) швейцарского регулирующего органа по химическим веществам (Validation of Computerized Systems, V 2.0, 2007):
| Определение | Примеры | Действие | |
| Освобожденные от валидации системы | Нет функции калибровки, фреймворк/уровневое программное обеспечение. | Калькулятор, фото- или видеокамера, микроскоп, стандартный офисный компьютер и другие. Операционная система (Windows, Linux, Unix), сетевое ПО, ПО системы безопасности (антивирус, брандмауэр), офисное ПО (Word, Excel), системы управления базами данных (Oracle, SQL, Access). | Не требуется. |
| Простые системы | Малая часть программного обеспечения, ограниченная возможность настройки. | Лабораторное и измерительное оборудование. | Калибровка, испытание для контроля функционирования. |
| Сложные системы | ПО с дополнительным объемом функций, расширенные возможности настройки. | ERP (планирование ресурсов предприятия), СЭД (система электронного документооборота), LIMS (лабораторная информационная менеджмент-система), созданная пользователем в программе Excel таблица, созданное пользователем в программе Access приложение. | Проведение валидации. |
Основной вывод, который можно сделать – нет необходимости валидировать операционные системы, офисные приложения, базы данных и платформы (в нашем случае базовый функционал 1С подпадает под это определение). Однако пользовательские приложения, написанные в этих программных пакетах или с их помощью, валидировать следует (в нашем случае это касается существенно доработанных модулей, которые подпадают под определение сложных компьютеризированных систем).
Основой для установления требований валидации будет определение спецификации требований пользователя (URS). Понадобятся план валидации, содержащий описание запланированных действий, основанных на риск-анализе, а также функционал лиц, задействованных в проведении валидации. Затем с учетом требований пользователя и критериев приемлемости будут подготовлены протоколы испытаний для IQ, OQ и PQ. Предоставленные поставщиком ПО протоколы испытаний или контрольные списки (при их наличии) можно использовать для IQ и OQ. Если в ходе валидации будут обнаружены отклонения, необходимо будет оценить их влияние на корректную работу системы.
Валидация по стратегии «черный ящик», по нашему мнению, является подходом к проведению испытаний, достаточным для понимания, что компьютеризированная система отвечает нуждам пользователя и пригодна для использования по назначению.
Такая валидация может включать этапы:
| 1 | Проверка правильности расчетов и формул. |
| и/или | |
| 2 | Ручная проверка данных вычислений, полученных с помощью компьютеризированной системы. |
| и/или | |
| 3 | Использование второго независимого инструмента компьютеризированной системы для проверки правильности расчетов. |
| и/или | |
| 4 | Документирование моделирования ввода данных результатов, выходящих за рамки спецификации, маркировки ошибок/оповещения об ошибках. |
По итогам валидационных мероприятий составляются отчеты об испытаниях и окончательный отчет о валидации с утверждением, что компьютеризированная система пригодна к использованию по назначению.
И, конечно, стоит отметить, что наличие валидации является не единственным требованием к компьютеризированным системам, общий перечень будет включать следующие пункты:
- данные инвентаризации,
- валидация,
- журнал сбоев и ошибок,
- контроль изменений,
- проверка (периодическая),
- требования по безопасности и экологичности,
- контрольный журнал,
- электронные подписи,
- резервирование,
- архив версий,
- обучение персонала,
- документация и инструкции от пользователей.
Раздел «Документация» для сложных компьютеризированных систем (значительно доработанных блоков ПО) мы начинаем готовить уже сейчас, и он включает:
- инвентарная информация, название, идентификатор, номер версии компьютеризированной системы,
- исходные файлы и место их хранения для инсталляции, операционная среда функционирования,
- дата ввода в эксплуатацию,
- ответственное лицо,
- производитель, лицензионный/серийный номер или другой уникальный идентификатор,
- аппаратное обеспечение, операционная система (minimal requirements),
- валидационный сертификат от производителя (при наличии),
- инструкции от пользователя, ссылка на место их хранения,
- валидационные документы конфигураций и модификаций,
- имя лица, которое разработало компьютеризированную систему и провело ее валидацию, дата валидации,
- правила работы (стандартные операционные процедуры, СОП),
- документация по периодическим проверкам компьютеризированной системы и результатам аудитов,
- валидационные документы компьютеризированной системы,
- управление конфигурациями (действия по итогам обнаруженных сбоев, техническая поддержка процесса, изменения, обновленные версии),
- досье по обучению,
- записи о регулярном тестировании резервных копий (тестирование восстановления).
Источник – Сборник GDP Review 5 VI Конференции «Логистика лекарственных средств»
