Краеугольный камень маркировки: URS

Краеугольный камень маркировки: URS

<img width="54%" src="/bitrix/templates/itrack/images/traceway-urs.svg" class="rounded float-right img-thumbnail" style="margin: 0 0 1em 1em;"> <blockquote class="blockquote"> Аббревиатура URS означает User Requirements Specification и переводится как «Спецификация пользовательских требований». URS - это документ с параметрами оборудования и ПО, который заполняется на предприятии для закупки программно-аппаратного комплекса (ПАК). Корректность заполнения USR один из главных источников риска и частая причина провалов при внедрении маркировки. Рассмотрим, как этого избежать. </blockquote> <h2>Кто отвечает за создание URS</h2> <ol> <li><p>Часто создание URS делегируется выбранному поставщику решения. Например, системному интегратору, который берет на себя все риски, в том числе финансовые, с обязательством внедрения гарантированно работающего ПАК. Но, как правило, такая услуга оплачивается предприятием отдельно. В этом случае в URS будут детально описаны процедура внедрения и сдачи проекта, возможные риски и допущения, четко разделены зоны ответственности заказчика и исполнителя. Это рекомендуемый сценарий при котором Заказчик получает гарантированный результат.</p></li> <li><p>Другой вариант, когда у предприятия есть внутренняя проектная команда с достаточной экспертизой для заполнения URS. В нее могут входить технолог, инженер производства, представители ИТ-подразделения и службы управления качеством. На практике это редкий случай, т.к. сотрудники, как правило, будут выполнять подобную задачу в первый раз: у них нет опыта работы с описываемым оборудованием и программным обеспечением. Поэтому им может потребоваться пройти дополнительное обучение или привлечь внешних экспертов для проверки корректности заполнения URS.</p> <p>Однако менеджменту предприятия нужно понимать, что внедрение программной части системы маркировки (Track&Trace решения) согласно URS на несколько порядков сложнее, чем установка оборудования. Поэтому следует избегать ситуации, когда поставщик предлагает предприятию самостоятельно заполнить URS, а потом продать оборудование согласно этой спецификации. Есть вероятность, что Заказчик и не сможет корректно проверить точность соблюдения описанных в URS требований, доверяя продавцу, что приведет к последующим проблемам настройки связки оборудования и ПО (Track&Trace) или даже полной их несовместимости.</p></li> </ol> <h2>Как избежать рисков при создании URS и организации последующей закупки ПО и оборудования</h2> <ol><li><p>Разбивать параметры закупки на отдельные части и детально расписывать требования.</p> <p>Это позволит прозрачно контролировать исполнение URS на каждом этапе и при необходимости заменить поставщика / избежать дополнительных затрат.</p></li> <li><p>Не допускать, чтобы поставщик оборудования и ПО были в одном лице.</p> <p>С одной стороны приобретение решения под ключ от одного поставщика в теории идеальный сценарий. С другой стороны на практике это может приобретать вид монопольной поставки. Главный источник рисков заключается в том, что после поставки одной единицы оборудования или модуля ПО предприятие будет вынуждено делать повторные закупки у этого же поставщика, таким образом увеличивая свою от него зависимость. Также, будет трудной задачей найти одного поставщика с одинаково высокой экспертизой в части оборудования и ПО.<p> <p>Поэтому безопасный сценарий действий для предприятия – сначала выбрать проверенного поставщика оборудования согласно URS для уровней L1 и L2 и ПО Line Manager, обеспечивающее внутреннюю консолидацию данных.</p></li> <li><p>Не работать с поставщиками, которые предлагают закрытые протоколы доступа к оборудованию.</p> <p>Приведем яркий пример из практики когда некоторым фармацевтическим предприятиям в итоге пришлось перенести сроки внедрения обязательной маркировки лекарственных препаратов, и эта история до сих пор продолжается. Произошло следующее: поставщик продал оборудование с закрытым API, под обязательство дальнейшей поставки ПО уровня L3, но на практике сделать этого не может из-за невозможности связать работу ПО с оборудованием. В результате, заложенная в поставку оборудования стоимость разработки ПО оказалась замороженной и предприятия уже больше года ждут, когда их поставщик разработает обещанное ПО.</p> <p>Поэтому важно изначально закрепить в URS, что протоколы обмена данными и доступа к оборудованию будут открытыми на весь срок работы оборудования. При необходимости, прописать штрафные санкции за нарушение этих договоренностей и немедленные меры по восстановлению status quo. Также протоколы обмена данными (API) должны быть не просто открыты, но и находиться в публичном доступе. Иначе ни одна третья не сможет подключиться к проекту, а реалии рынка таковы, что крайне трудно выполнить проект по внедрению системы маркировки, привлекая только одного подрядчика. Кто-то хорошо делает оборудование, кто-то программное обеспечение, но нет полностью универсальной компании.</p> <p>Еще раз отметим, что дело не в конкретных производителях и поставщиках, для любой компании будет лучше, если установленное у нее оборудование для маркировки имеет открытые протоколы обмена данными. Это позволит избежать ситуации «vendor lock», когда с одной стороны поставщик навязывает свое решение, а с другой стороны не может полностью воплотить проект.</p></li></ol> <p>Подведем итог: URS — это краеугольный камень процесса внедрения системы маркировки. То, что будет в нем заложено, то и получится на выходе.</p> <ul><li>Создание URS лучше доверить внешнему поставщику с достаточной экспертизой.</li> <li>Необходимо разбивать закупки по URS и детально расписывать требования.</li> <li>Оптимально не ограничивать себя в работе с одним подрядчиком и избегать закрытых протоколов обмена данными.</li></ul>

TraceWay
Россия
Москва
+74951222335
Аббревиатура URS означает User Requirements Specification и переводится как «Спецификация пользовательских требований». URS - это документ с параметрами оборудования и ПО, который заполняется на предприятии для закупки программно-аппаратного комплекса (ПАК). Корректность заполнения USR один из главных источников риска и частая причина провалов при внедрении маркировки. Рассмотрим, как этого избежать.

Кто отвечает за создание URS

  1. Часто создание URS делегируется выбранному поставщику решения. Например, системному интегратору, который берет на себя все риски, в том числе финансовые, с обязательством внедрения гарантированно работающего ПАК. Но, как правило, такая услуга оплачивается предприятием отдельно. В этом случае в URS будут детально описаны процедура внедрения и сдачи проекта, возможные риски и допущения, четко разделены зоны ответственности заказчика и исполнителя. Это рекомендуемый сценарий при котором Заказчик получает гарантированный результат.

  2. Другой вариант, когда у предприятия есть внутренняя проектная команда с достаточной экспертизой для заполнения URS. В нее могут входить технолог, инженер производства, представители ИТ-подразделения и службы управления качеством. На практике это редкий случай, т.к. сотрудники, как правило, будут выполнять подобную задачу в первый раз: у них нет опыта работы с описываемым оборудованием и программным обеспечением. Поэтому им может потребоваться пройти дополнительное обучение или привлечь внешних экспертов для проверки корректности заполнения URS.

    Однако менеджменту предприятия нужно понимать, что внедрение программной части системы маркировки (Track&Trace решения) согласно URS на несколько порядков сложнее, чем установка оборудования. Поэтому следует избегать ситуации, когда поставщик предлагает предприятию самостоятельно заполнить URS, а потом продать оборудование согласно этой спецификации. Есть вероятность, что Заказчик и не сможет корректно проверить точность соблюдения описанных в URS требований, доверяя продавцу, что приведет к последующим проблемам настройки связки оборудования и ПО (Track&Trace) или даже полной их несовместимости.

Как избежать рисков при создании URS и организации последующей закупки ПО и оборудования

  1. Разбивать параметры закупки на отдельные части и детально расписывать требования.

    Это позволит прозрачно контролировать исполнение URS на каждом этапе и при необходимости заменить поставщика / избежать дополнительных затрат.

  2. Не допускать, чтобы поставщик оборудования и ПО были в одном лице.

    С одной стороны приобретение решения под ключ от одного поставщика в теории идеальный сценарий. С другой стороны на практике это может приобретать вид монопольной поставки. Главный источник рисков заключается в том, что после поставки одной единицы оборудования или модуля ПО предприятие будет вынуждено делать повторные закупки у этого же поставщика, таким образом увеличивая свою от него зависимость. Также, будет трудной задачей найти одного поставщика с одинаково высокой экспертизой в части оборудования и ПО.

    Поэтому безопасный сценарий действий для предприятия – сначала выбрать проверенного поставщика оборудования согласно URS для уровней L1 и L2 и ПО Line Manager, обеспечивающее внутреннюю консолидацию данных.

  3. Не работать с поставщиками, которые предлагают закрытые протоколы доступа к оборудованию.

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

    Поэтому важно изначально закрепить в URS, что протоколы обмена данными и доступа к оборудованию будут открытыми на весь срок работы оборудования. При необходимости, прописать штрафные санкции за нарушение этих договоренностей и немедленные меры по восстановлению status quo. Также протоколы обмена данными (API) должны быть не просто открыты, но и находиться в публичном доступе. Иначе ни одна третья не сможет подключиться к проекту, а реалии рынка таковы, что крайне трудно выполнить проект по внедрению системы маркировки, привлекая только одного подрядчика. Кто-то хорошо делает оборудование, кто-то программное обеспечение, но нет полностью универсальной компании.

    Еще раз отметим, что дело не в конкретных производителях и поставщиках, для любой компании будет лучше, если установленное у нее оборудование для маркировки имеет открытые протоколы обмена данными. Это позволит избежать ситуации «vendor lock», когда с одной стороны поставщик навязывает свое решение, а с другой стороны не может полностью воплотить проект.

Подведем итог: URS — это краеугольный камень процесса внедрения системы маркировки. То, что будет в нем заложено, то и получится на выходе.

  • Создание URS лучше доверить внешнему поставщику с достаточной экспертизой.
  • Необходимо разбивать закупки по URS и детально расписывать требования.
  • Оптимально не ограничивать себя в работе с одним подрядчиком и избегать закрытых протоколов обмена данными.
Бесплатная горячая линия
8 (800) 555 93 44