Эта метрика отражает процент времени, в которое система была доступна, относительно установленного периода доступности, то есть максимально возможного времени работы системы, уменьшенного на период планового сервисного интервала и других согласованных простоев.
Плановые сервисные интервалы нужны для установки обновлений на продуктивную среду. В начале 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, индивидуально подобранные для клиента.