Операционная модель полного цикла домашних лабораторных тестов

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

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

Краткий обзор

ТИП

Операционная аналитика и математическое моделирование

Роль

Исследователь, проектировщик аналитической системы

МЕТОДЫ

Событийная модель данных, статистический контроль процесса, многокритериальная оценка

Главный вопрос исследования

Как из тысяч отдельных изменений статусов восстановить реальное состояние всей операционной системы?

Сколько времени
он проводит на
текущем этапе?

Корректно ли время для проведения теста?

Где фактически находится заказ?

Какой этап
накапливает
очередь?

Является ли
проблема единичной
или системной?

Какая лаборатория или
категория тестов формирует
наибольшую нагрузку?

ЗАЧЕМ НУЖЕН НОВЫЙ ПОДХОД?

Операционный цикл домашнего лабораторного теста выходит далеко за пределы самой лаборатории. Он начинается с отправки набора клиенту и заканчивается только после проверки и выдачи результата.

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

Новая модель объединяет историю событий в единую траекторию заказа и переводит разнородные отклонения в сопоставимые уровни операционной критичности.

Участники принятия решения

Роль

задачи

Цели

проблемы

инструменты

ключевая мысль

«Мне нужно видеть, где весь процесс начинает замедляться
и насколько серьезно это влияет
на выполнение заказов»

01/ Оценить состояние всего цикла
02/ Найти этап накопления нагрузки
03/ Определить приоритеты операционной работы

• Соблюдать сроки выполнения заказов
• Поддерживать устойчивую пропускную способность
• Снижать количество критических случаев

• Отклонения на отдельных этапах теряются в сводной отчетности
• Ухудшение процесса становится заметно слишком поздно

Сводный индикатор состояния, динамика задержек, показатели этапов, критические случаи

Руководитель
операционного
направления

01/ Контролировать движение заказов
02/ Находить случаи без новых событий
03/ Разбирать причины остановки процесса

• Быстро выделять заказы, требующие внимания
• Сократить время ручного поиска проблем

• Одинаковый статус может иметь разную критичность
• Для проверки приходится сопоставлять несколько источников

Списки заказов по этапам, заказы без движения, журнал изменений статусов, причины сбоев

«Мне важно понимать не только где находится заказ, но и почему он не переходит на следующий этап»

Операционный
менеджер

• Найти системные источники проблем
• Сопоставить партнеров на единой основе
• Показать структуру и тяжесть отклонений

• Абсолютное число проблем зависит
от размера потока
• Сложность тестов влияет на сроки
и долю отклонений

PostgreSQL, Python, событийная модель данных, показатели проблемности, аналитический дашборд

«Мне нужен не список лабораторий с ошибками, а понимание того, где отклонения действительно носят системный характер»

01/ Сравнить лаборатории и виды тестов
02/ Выявить повторяющиеся причины сбоев
03/ Объяснить изменение показателей процесса

Аналитик качества
и партнерской сети

Участники принятия решения

Руководитель операционного направления

задачи

Цели

проблемы

инструменты

Сводный индикатор состояния, динамика задержек, показатели этапов, критические случаи

ключевая мысль

Операционный менеджер

задачи

Цели

• Быстро выделять заказы, требующие внимания
• Сократить время ручного поиска проблем

проблемы

инструменты

Списки заказов по этапам, заказы без движения, журнал изменений статусов, причины сбоев

ключевая мысль

«Мне важно понимать не только где находится заказ, но и почему он не переходит на следующий этап»

Аналитик качества и партнерской сети

задачи

Цели

проблемы

• Абсолютное число проблем зависит
от размера потока
• Сложность тестов влияет на сроки
и долю отклонений

инструменты

PostgreSQL, Python, событийная модель данных, показатели проблемности, аналитический дашборд

ключевая мысль

ЗАКАЗЫ ПО ЭТАПАМ И УРОВНЮ ОТКЛОНЕНИЯ ОТ НОРМАТИВА

КАРТА ОПЕРАЦИОННЫХ СБОЕВ

Исследование

Жизненный цикл заказа как последовательность событий

Исходный процесс

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

Фокус исследования

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

Результат модели

Модель объединила события всех этапов в единый операционный цикл и определила текущее состояние каждого заказа.
На основе длительности этапов, отсутствия новых событий и тяжести отклонений сформирована единая шкала проблемности.
Результатом стал интерактивный дашборд, который связывает общее состояние процесса с конкретными заказами, этапами, лабораториями и видами тестов.