Для компании, внедряющей Track&Trace систему, проект не заканчивается после внедрения. Наоборот, сложности после запуска ПО только начинаются: изменения требований регулятора, технические сбои, обучение персонала.
Об опыте Navicon и Utrace в построении процессов сопровождения систем рассказывает Сергей Игнаткин, директор проектов по маркировке в компании Navicon.
«Умная» поддержка
Процесс взаимодействия с информационной системой мониторинга движения лекарственных препаратов (ИС МДЛП) не должен требовать от заказчика дополнительных усилий и тем более приводить к непредвиденным расходам. Чтобы обеспечить бесперебойную работу процессов отправки данных в МДЛП, мы вместе со специалистами Utrace разработали систему Utrace HUB, которая представляет собой SaaS-сервис (Software as a Service), предоставляемый по подписке. Сопровождение системы основано на процессах управления ИТ-услугами библиотеки ITIL и включает:
- мониторинг работы серверных и системных параметров, компонентов системы, сохранение и восстановление, решение инцидентов, исследование причин возникновения и их устранение (управление проблемами);
- решение запросов пользователей, консультации по системе;
- управление изменениями, выпуск обновлений системы в соответствии с обновлениями МДЛП.
Эффективности и прозрачности процессов мы достигаем благодаря расчету и контролю метрик качества. Мы используем три метрики качества: доступность облачной системы, оперативность решения инцидентов и запросов пользователей, взаимодействие с государственной системой мониторинга. Для каждой метрики установлены диапазоны целевых и допустимых значений.
Все три метрики сводятся в единый показатель уровня сервиса, за нарушение которого предусматривается финансовая ответственность в виде неустойки. Алгоритмы расчета метрик, целевые показатели и финансовая ответственность включаются в договор сопровождения в качестве приложения SLA (Service Level Agreement — соглашение об уровне обслуживания), который подписывается с заказчиком.
Проанализируем каждую из этих метрик качества
- Доступность системы
Эта метрика отражает процент времени, в которое система была доступна, относительно установленного периода доступности, то есть максимально возможного времени работы системы, уменьшенного на период планового сервисного интервала и других согласованных простоев.
Плановые сервисные интервалы нужны для установки обновлений на продуктивную среду. В начале 2020 года мы ожидаем частые обновления МДЛП, соответственно, готовимся к тому, чтобы вносить изменения и оперативно устанавливать обновления.
Чтобы минимизировать влияние простоя на бизнес-операции, мы осуществляем техническое обслуживание ночью, так как большинство бизнес-операций, по которым выполняется отчетность в государственную систему мониторинга, происходит в рабочее время, фармацевтические склады 3pl-операторов также в основном работают с 7.00 до 20.00.
Целевые показатели устанавливаются с учетом доступности хостинга. В нашем случае используется хостинг уровня Tier III с полным георезервированием и резервной линией электроснабжения.
- Решение инцидентов и запросов пользователей
Все поступающие данные от пользователей мы регистрируем в нашей системе Service Desk, классифицируем их на инциденты (некорректная работа системы, отказ компонентов) и запросы (нужна консультация, добавить права), ранжируем по приоритетам. Для каждого приоритета установлены целевые показатели времени реакции и решения.
Система Service Desk интегрирована с системой управления задачами разработки, поэтому мы всегда знаем, в каком статусе находится задача и когда она закрывается. В конце месяца система рассчитывает время решения по каждому из приоритетов и сравнивает с целевым значением. Далее с учетом весов (решение критического инцидента имеет больший вес, чем запрос с низким приоритетом) вычисляем итоговое значение этой метрики.
- Взаимодействие с МДЛП
На взаимодействие с МДЛП влияют следующие три фактора:
- Время отправки. Несмотря на установленный законодательством максимальный срок отправки в МДЛП: для импортных сообщений — до 20 рабочих дней, для локальных — 5 рабочих дней, мы ставим себе более жесткие целевые показатели метрики, так как, исходя из бизнес-процессов, заказчики не могут ждать отправки сообщений так долго.
- Корректность сообщения. Система не должна содержать ошибок, влияющих на отправку сообщения в МДЛП. Если сообщение не будет отправлено, это повлечет за собой цепную реакцию по остановке отправки остальных сообщений по данной упаковке лекарственного препарата, что приведет к штрафам.
- Актуальность формата сообщения. Версии МДЛП меняются довольно часто. Наша обязанность как вендора — регулярно и своевременно обновлять систему, чтобы в каждый момент времени она позволяла отправлять сообщения в том виде, в котором они будут приняты МДЛП.
Эти факторы мы сводим в единую метрику взаимодействия с МДЛП. Она зависит от попадания рассчитанного среднего времени, затраченного на корректную отправку сообщений, в целевой временной диапазон. Среднее время — это время между поступлением в Utrace HUB всех данных и периодом отправки сообщения в государственную систему мониторинга. При этом сообщения, по которым на вход были приняты некорректные данные, из расчета исключаются. Данная метрика, на наш взгляд, — самая важная.
Production-эксплуатация ИС МДЛП находится в самом начале пути. Близко общаясь с участниками рынка, мы видим, что производители маркируют только небольшую часть SKU, поэтому целевые показатели SLA и их метрики будут меняться и смогут быть определены после накопления достаточной статистики. С заказчиками у нас есть договоренность, что каждые двенадцать месяцев, а на ранних этапах — каждые шесть месяцев мы будем анализировать статистику по поддержке и корректировать SLA для улучшения уровня сервиса. Мы называем этот процесс continuous business process improvement. Его результатом станут показатели и метрики SLA, индивидуально подобранные для клиента.
Источник: Navicon
