Принципы и особенности выбора Track&Trace решений

Original Group работает на рынке Track&Trace систем с 2006 года, является разработчиком и поставщиком программных и аппаратных решений, принимает участие в проекте маркировка с самого его начала. Полученный опыт позволил сформировать свое видение по поводу стандартов ПО класса Track&Trace.

Консорциум GS1 закладывал следующую основу для построения систем Track&Trace, согласно принципам архитектуры ISA-95 она состоит из 5 отдельных слоев: L1 – это уровень оборудования, L2 – это ПО уровня цеха для оборудования сериализации, агрегации и лайн-менеджер, L3 – программное обеспечение уровня предприятия, L4 – ПО уровня холдинга и взаимодействия с прочим информационными системами внутри холдинга и иногда контрагентами, L5 – шина для обмена данными между контрагентами и государством.

Это идеология, следование которой позволяет избежать множества проблем. Разработчики этого стандарта проделали отличную работу. При принятии этой архитектуры становится просто интегрировать между собой ИС производителя, 3PL-оператора, дистрибутора, розницы. Причем это может происходить как на уровне L5, так и на уровне L4, для чего разработаны специальные протоколы.

В России сложилось так, что стоящей перед участниками оборота поставили неверно названную задачу – внедрение маркировки. Это сместило фокус их внимания в неправильную сторону. По факту, для корректного внедрения «системы маркировки» предприятие должно внедрить Track&Trace систему. В этом процессе должны участвовать несколько служб компании: в первую очередь – ИТ-отдел, отдел качества и главный механик/инженер, который занимается обслуживанием функционирования производственного оборудования.

Основополагающая роль принадлежит ИТ-службе, т.к. согласно архитектуре ISA-95 оборудование – это самый нижний уровень L1. Безусловно, это важная составляющая решения, сюда входит система печати, системы сериализации и агрегирования... Но чтобы все это работало как единый комплекс, чтобы внедренная система открывала перед предприятием новые возможности, а не доставляла непрекращающиеся сложности по ее обслуживанию, она должна быть изначально правильно построена.

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

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

По факту происходит следующее: самое трудное во внедрении Track&Trace системы – это настройка уровней L3 и L4. Чтобы облегчить этот процесс нужно использовать разработки ИТ-компаний, чья экспертиза позволяет учесть все моменты необходимой оркестровки данных между всеми системами (ERP, регулятора, СУЗ, контрагентов и лайн-менеджером). На российском рынке представлено несколько решений соответствующего уровня.

Важным аспектом также является то, что в России требования к системе маркировки сильно отличаются от западных. Они намного жестче. Во-первых, протокол информационного обмена – не EPCIS, а API, работающие через файлы обмена. Во-вторых, есть Сервер Управления Заказами, в коде маркировки должен быть криптохвост. Есть требование указывать физические адреса мест хранения товаров, регулируются бизнес-операции на предприятии, включая отборы проб, перемещение в карантин, декларирование, сертификация и т.д. В этом плане информационные системы уровня L3 от иностранных разработчиков с поставленными задачами не справляются. Они и не создавались для такой работы и не имеют нужного функционала. Чтобы выйти из ситуации некоторые поставщики оборудования в России начали самостоятельно писать разрабатывать такие решения, при этом не являясь профильными ИТ-компаниями. И происходит следующее, в техническом задании заказчик говорит о том, что ему нужно отсылать отчеты в ГИС «Честный ЗНАК», аналитики подтверждают, что такое решение можно разработать. И поставщик начинает писать ИС, которая сдает отчеты в «Честный ЗНАК». Но при таком подходе самые важные моменты упускаются: оркестровка данных и контроль их целостности на уровне L3. Такое решение должно синхронизировать данные, а не просто отправлять их на верхний уровень. Если вы просто отправлять данные, то рано или поздно они «разъедутся». И как их потом собирать?

Внедрение Track&Trace системы на предприятии должно происходить не из предпосылки, что регулятору надо отправлять отчет, а из понимания, что это мощный инструмент цифровой трансформации компании. Восприятие Track&Trace системы через призму отчетности не позволяет получить преимуществ от ее внедрения. Добавляются только сложности, связанные с необходимостью отправлять регулятору данные.

Второй аспект непонимания заключается в том, что даже систему отчетности можно выстроить по-разному, можно просто отправлять отчеты, а можно создать синхронизированную систему. Оператор тоже шлет предприятию данные, которые он получает от других контрагентов и их надо синхронизировать. Если нет понимания о целостности данных и статусов кодов маркировки, то в процессе реальной эксплуатации произойдет следующее. Предприятие выйдет из режима печати упаковки, агрегации продукции и отправки данных контрагенту, к нему начнут поступать данные, консолидироваться, отправляться, взаимодействовать с ERP-системой, и оно поймет, что ее L3 – это просто система для отчетов. Это не ПО уровня L3 (Site Manager) согласно архитектуре Track&Trace систем, который, в принципе, может работать, и не обмениваясь данными с уровнем L5.

Он должен уметь работать независимо от ЦРПТ, он должен поддерживать работу по протоколу EPCIS, чтобы обмениваться данными с Track&Trace системами других контрагентов. Не понимание этого фундаментального факта приводит к тому, что сейчас каждый поставщик оборудования считает, что он может написать ПО уровня L3. Но по факту оно таким не будет.

Это только часть проблемы, еще больше трудностей возникает при старте практической эксплуатации. Продукт, являющийся универсальным и предназначенный для работы в различных областях с поддержкой очень широкого спектра оборудования и имеющий широкое распространение, всегда будет более предпочтительным с точки зрения операционной эффективности и развития, чем узкое решение, написанное специально под заказчика. При старте реальной эксплуатации выяснится, что операционные расходы будут существенно выше, чем предприятие готово платить, потому что распределить затраты разработчика на 50 клиентов, это совсем не то же самое, что на 2000. И с течением времени функционал узкого заказного решение будет все сильнее оставаться от ведущих игроков рынка.

Как только фокус внимания сместится с вопроса, что вот есть ЦРПТ, которому нужно сдавать отчётность, все актуальнее будут становиться вопросы цифровой экономики и цифрового предприятия, какие преимущества перед конкурентами дает внедрение полноценной Track&Trace системы, и тогда появится понимание, что нужно полноценное решение с оркестровкой данных, с большим набором коннекторов к различным системам верхнего уровня, например, WMS, ERP. Пока многие видят, что ПО уровня L3 – это некое ПО для отчетов в ЦРПТ. Так работать можно, но это проигрыш конкурентам, которые видят это по-другому.

Есть еще один момент, это закрытые API для работы с оборудованием. У предприятия единый поставщик оборудования и ПО, у него закрытые протоколы. Он берет на себя обязательство написать нужное ПО, это растянутый во времени процесс, который обходится дорого. Когда процесс маркировки очередной товарной категории запускается в России, до участников рынка часто не доносится нужная информация. Компании фокусируются на выборе оборудования для сериализации и агрегации. Анализ рисков с точки зрения построения ИТ-архитектуры и использования закрытых протоколов просто не производится.

После этого поставщики оборудования часто пишут простейшие коннекторы для регулятора, это примерно 2 листа А4 с кодом про отправку XML файлов. Это мог бы написать и фрилансер, но это совсем не Track&Trace система. И если в договоре с предприятием не было напрямую указано, что поставщик оборудования должен предоставлять протоколы доступа к нему для дальнейшей интеграции с уровнем L3, то этого и не будет сделано. И в лозунге «возьмите все от одного поставщика» предприятие видит снижение рисков, т.к. будет одно окно для решения всех вопросов.

И тут упускается самое главное, в этом случае риски, наоборот, существенно возрастают: все замкнуто на одного поставщика с крайне ограниченным объемом реализации. Он не сможет провести тысячи внедрений по стране в отличие от ИТ-холдинга. А универсальные Track&Trace системы уровня L3 как раз создаются с расчетом на тысячи инсталляций. У них есть план развития, план дальнейших интеграций с информационными системами. Они делаются как часть инфраструктуры цифрового предприятия 4.0. Что становится все актуальнее и актуальнее.

Используя узкое решение от неспециализированного разработчика, предприятие само себя ограничивает, т.к. работает не с полнофункциональным решением, а коннектором для отчетов, оно сталкивается с рисками, что нанятая компания может не захотеть его развивать. Что цена техподдержки будет слишком высокой. Команда разработчиков может просто уйти от поставщика оборудования, и поддерживать ПО станет некому, и такие случаи уже были. И при закрытом API предприятие будет находиться в зоне большого риска, т.к. другой поставщик ПО уровня L3 или интегратор помочь будет не в силах. И если сейчас в заключенных договорах нет пункта об открытых протоколах, то пока не поздно, нужно настоять, чтобы он там появился. Это одна из самых важных вещей.

Сегодня единственное, что с точки зрения производителей мешает системе маркировки запуститься в России – это отсутствие адекватного ПО уровня L3, установленного у них. При наличии открытых протоколов доступа отрасль перестанет жестко зависеть от поставщиков/продавцов оборудования, т.к. другие компании смогут решить стоящую задачу. Уже есть несколько хороших, обкатанных решений такого класса на российском рынке. Причем некоторые из них работают в России уже несколько лет, они соответствуют всем местным требованиям и международным стандартам. Они многократно прошли валидацию на соответствие всем бизнес-процессам. И рынок мог бы соединить существующее оборудование с работающим ПО и запустить систему маркировки в короткие сроки, избежав рисков в будущем.