Внедрение маркировки: как успеть в срок

Сергей Игнаткин, директор проектов по маркировке в Navicon, и Евгений Роднянский, операционный директор компании Utrace, ответили на самые сложные вопросы, с которыми сталкиваются компании-заказчики при внедрении маркировки. 

— Что такое проект по маркировке?

— Евгений Роднянский: Если говорить про проект по маркировке для производителя, то он состоит из четырех подпроектов: интеграция с облачным регистратором эмиссии для получения криптокодов, печать маркировки на потребительской упаковке, учет складских операций с детализацией по SGTIN- или SSCC-кодам, сбор данных со всех производственных и складских площадок и отчетность в ИС МДЛП. 

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

—  В чем особенности проекта внедрения ИТ-системы?

— Сергей Игнаткин: Внедрение системы уровня L4 для взаимодействия с МДЛП — трудоемкий проект из-за его технической и организационной составляющих. 

Техническая составляющая заключается в том, что нужно связать данные из нескольких источников: производственных и складских площадок, учетных систем, глобальных систем сериализации. Единого формата и спецификации обмена в отрасли пока не существует — одни используют форматы, близкие к формату МДЛП, другие — EPCIS, третьи — свой формат. Это означает, что выстраивать взаимосвязи интеграторам каждый раз приходится заново. Полученные данные нужно валидировать «на вход» — проверять на соответствие формату, на полноту, на соответствие мастер-данным; объединять «куски» данных, приходящих в асинхронном режиме, в единые события, и выстраивать их в нужной последовательности; проверять «на выход» сформированные отчеты перед отправкой в МДЛП и обрабатывать отклик. 

Организационная составляющая в том, что система уровня L4 охватывает всю логистическую цепочку продукта — от производства до продажи, из-за чего в проекте участвуют до 10 сторон: бизнес- и ИТ-подразделение компании, штаб-квартира, контрактные производители, таможенные брокеры, 3PL-оператор, глобальный ERP-провайдер, локальный ERP-провайдер, ИТ-провайдер решения L4, ЦРПТ. Причем на отдельных этапах проекта требуется практически одновременное вовлечение всех участников. 

— Что нужно делать, чтобы эти технические и организационные моменты не повлияли на сроки?

— Сергей Игнаткин: Для решения технической задачи нужно минимизировать разработку и выбирать систему с готовым ядром и большим портфолио интеграций с различными системами. Организационная задача требует заблаговременного планирования и опытного руководства проектом. Здесь на первый план выходят опыт партнера и квалификация проектной команды заказчика. 

— С чего нужно начать?

— Евгений Роднянский: Нужно определиться с тем, какая система будет внедряться, и направлять усилия на то, чтобы лица, принимающие решения, осознали масштабы и серьезность проекта. Например, в международной компании глобальная команда зачастую основывается на опыте внедрения Track&Trace в Европе или США, где требования к репортингу сильно отличаются. Этот опыт может создавать иллюзию простоты проекта: в результате мало кто ускоряет принятие решения по выбору системы и партнера и процесс растягивается на месяцы. Важно, чтобы в этой ситуации российский офис назначил руководителя проекта (РП), у которого есть опыт и авторитет, чтобы быстро устранять барьеры: нанял или начал взращивать SME (subject matter expert) по маркировке. Такой специалист необходим, чтобы разбираться в постановлениях, методических рекомендациях, участвовать в рабочих группах, помогать РП объяснять специфику российской маркировки глобальной команде. 

Также я бы отметил, что при выборе системы нужно сравнивать не только предложения по внедрению, но и условия сопровождения, где много составляющих: поддержка — решение запросов пользователей, консультации по системе; хостинг и хранение истории данных; обеспечение бесперебойной работы — мониторинг работы серверных и системных параметров и компонентов системы, резервное копирование, решение инцидентов; управление изменениями, выпуск обновлений системы в соответствии с обновлениями МДЛП. 

— Выбрали систему и партнера, что дальше? Можно довериться и наблюдать за работой?

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

Еще один из главных рисков для проекта — изменчивость регуляторных требований. У нас есть статистика изменений по версиям МДЛП, там в среднем больше 10 изменений на новую версию, а они выходят раз в 2-3 месяца. Их нужно будет учитывать в ходе проекта: корректировать документацию, дорабатывать систему, что-то в интеграции переделывать — все это может потребовать дополнительного бюджета от заказчика. Чтобы оперативно эти изменения отработать, нужно заранее согласовать со спонсорами проекта резервный бюджет, наделить РП полномочиями его использовать. Мы рекомендуем закладывать в резерв не менее 20% от стоимости проекта. 

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

— Какой этап проекта самый важный с точки зрения внимания заказчика?

— Сергей Игнаткин: Анализ — это самый важный этап, на мой взгляд, так как цена ошибки на этом этапе очень велика. В ходе анализа партнер проводит интервью и задает вопросы о бизнес-процессах и операциях, проводимых с товаром на протяжении всей логистической цепочки от производства до сбыта, о сопутствующем документообороте и об источниках данных для отправки сообщений в МДЛП. Заказчик должен выделить для участия в проекте нужных людей, освободить их от части операционной работы, чтобы ускорить процесс решения открытых вопросов и согласования документации. Также следует создать внутреннюю матрицу RACI для согласования каждого документа. 

В конце этапа анализа, когда пользовательские требования собраны, наложены на возможности системы, партнер выполнил Fit-gap анализ и оценил гэпы, то есть выстроена полная картина того, что требуется для запуска Track&Trace системы, имеет смысл разделить проект на волны. Следует помнить, что главная задача — удовлетворить требования регулятора, начать отправлять отчетность по всем операциям в МДЛП. Чтобы понять, сколько еще есть времени, нужно оценить объем страхового запаса и спланировать: 

1. Когда импортное производство изготовит первую сериализованную партию ЛП. В течение 20 дней с момента изготовления нужно отправить информацию о производстве в МДЛП.
2. Когда ЛП попадет на территорию РФ в 2020 году (после 01.10.2019 для ЛП категории 12 ВЗН). При ввозе продукции и остальных операциях на территории РФ нужно отправлять информацию в МДЛП в течение пяти дней с момента их осуществления. 

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

1. Критичность требований — все, что некритично для передачи сообщений в МДЛП, можно отложить: отчеты, отдельные уведомления, интерфейсные изменения.
2. Частоту операций. В первую очередь должны поддерживаться операции с ЛП, по которым невозможен страховой запас. Также можно отложить или планировать на первое время ручной режим работы по редким операциям, таким как передача лекарственных препаратов на уничтожение. 

Следующий шаг — постараться оптимизировать сам план проекта: 

• начать этап разработки практически одновременно с этапом дизайна, то есть после подготовки небольшой части дизайна сразу передавать его в разработку;
• вести разработку по гибкой agile-методологии, чтобы сделать процесс более управляемым и менее зависимым от внешних изменений;
• объединить интеграционное тестирование с пользовательским;
• закончить оформление документации и завершить валидацию после запуска системы. 

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

— До какого минимального срока можно сократить проект внедрения?

— Сергей Игнаткин: Минимальный срок внедрения маркировки (от начала проекта до запуска систем) — четыре месяца. Но для того, чтобы он был достижим на практике, должно сойтись много факторов: отсутствие изменений МДЛП, моментальное решение вопросов и согласование документов, возможность использования стандартных коннекторов интеграции, стопроцентная готовность других подрядчиков и немного удачи.

Источник: Navicon