[drive-download] ТОМ 2.docx

Google Docs neutral 17 чанков ~25 мин чтения

Сущности

1.1. Назначение Тома 2<br> 1.1.1. Настоящий документ (далее – Том 2) устанавливает единые принципы, требования и методики расчёта индикаторов, метрик и интегральных индексов, используемых для управления работой штаба коммуникаций.<br> 1.1.2. Том 2 определяет, какие данные используются для расчётов, как они собираются и нормализуются, каким образом формируются показатели (операционные метрики, ok_rate, SSI и др.) и как результаты визуализируются в дашбордах и отчётности.<br> 1.1.3. Том 2 используется как техническая «подложка» к Тому 1: он обеспечивает количественное обоснование смены режимов Normal / Attention / Stress / Crisis, оценки нагрузки, качества отчётности и устойчивости процессов.<br> 1.1.4. Требования Тома 2 являются обязательными для аналитического блока, технического и ИТ‑блока, а также для всех сотрудников и региональных команд, формирующих и передающих данные, используемые в расчётах.<br> 1.2. Связь с Томом 1 и область применения<br> 1.2.1. Том 1 определяет архитектуру управления, режимы, роли и процессы работы штаба; Том 2 определяет, какие количественные показатели используются для оценки этих процессов и принятия решений в их рамках.<br> 1.2.2. Индикаторы и индексы, описанные в Томе 2, применяются для: оценки текущего режима работы штаба; мониторинга нагрузки и рисков; контроля качества данных и отчётности; подготовки ежедневных и недельных отчётов; поддержки решений руководства штаба.<br> 1.2.3. В случае противоречий между фактами, полученными из данных по методикам Тома 2, и субъективными оценками, приоритет имеют данные, если иное не решено руководителем штаба с фиксацией решения в журнале.<br> 1.2.4. Методики Тома 2 распространяются на центральный штаб и региональные команды в части формирования и передачи данных, влияющих на индикаторы и индексы (approval‑flow, отчётность, link‑audit и др.).<br> 1.3. Принципы работы с данными и метриками<br> 1.3.1. Единый источник данных (Single Source of Truth). Все расчёты индикаторов и индексов осуществляются на основании согласованного набора источников данных (LDataIntegrity, реестры задач, отчётность, link‑audit и др.), определённых в Томе 2 и связанных документах; параллельные «ручные» учёты и альтернативные версии показателей не допускаются.<br> 1.3.2. Прозрачность методик и воспроизводимость расчётов. Для каждого индикатора и индекса фиксируются: определение, формула, используемые поля и источники данных, периодичность расчёта, правила нормализации и сглаживания, весовые коэффициенты и пороговые значения; расчёт любого показателя должен быть воспроизводим по журналу изменений и исходным данным.<br> 1.3.3. Ограничение числа ключевых показателей для ЛПР. Для уровней руководителя штаба и операционного руководителя устанавливается ограниченный набор ключевых показателей, выносимых на главный экран дашбордов (SSI, PRS при наличии, ok_rate, LI/режим и т.п.); остальные показатели используются на аналитическом уровне и в развернутой отчётности, но не перегружают контур принятия решений.<br> 2.1. Операционные данные<br> 2.1.1. Данные таск‑трекера и approval‑flow. К операционным данным относятся записи систем постановки и исполнения задач (таск‑трекер, системы согласования), включающие идентификаторы задач и материалов, тип задачи, ответственных, временные метки создания и завершения, статусы по стадиям approval‑flow и отметки об эскалации. Эти данные используются для расчёта временных показателей (SLA по стадиям), доли возвратов, доли задач с эскалацией и других операционных метрик.<br> 2.1.2. Логи SLA и статусов задач. Логи SLA формируются на основании временных меток прохождения стадий согласования и исполнения, фиксируя факт соблюдения или нарушения нормативных сроков по каждому этапу и в целом по материалу. Логи статусов задач фиксируют переходы между состояниями (создано, в работе, на согласовании, завершено, отменено и др.) и используются для контроля очередей, идентификации узких мест и построения индексов нагрузки.<br> 2.2. Данные мониторинга информационного поля<br> 2.2.1. СМИ и онлайн‑издания. В качестве источников используются агрегаторы новостей, системы мониторинга СМИ, RSS‑ленты и иные каналы, обеспечивающие сбор публикаций по заданным тематикам, брендам, персонам и регионам. Для каждой публикации, попадающей в контур, фиксируются: источник, время выхода, ссылка, тональность (при наличии), релевантность, уровень риска (низкий/средний/высокий) и связь с материалами штаба.<br> 2.2.2. Социальные сети и мессенджеры. Данные по соцсетям и мессенджерам включают сообщения и обсуждения в приоритетных площадках, публичных каналах и группах, а также, при наличии, данные по охвату, вовлечённости и динамике негативных/позитивных реакций. Система мониторинга обеспечивает фильтрацию по ключевым словам, тегам кампании и регионам; результаты используются для идентификации инфоповодов, высокорисковых сюжетов и расчёта индексов шума и стресса.<br> 2.3. Региональная отчётность<br> 2.3.1. Регулярные отчёты регионов. Региональные штабы предоставляют стандартизированные отчёты за период (день/неделя), включающие: перечень проведённых активностей, ключевые материалы, использованные площадки, показатели охвата (если доступны), ссылки на публикации и краткую оценку рисков. Форматы отчётов и обязательные поля устанавливаются приложениями к Тому 2; отсутствие отчёта или существенные пробелы в данных фиксируются как нарушение.<br> 2.3.2. Специальные отчёты по кризисам. При кризисных событиях регионы по запросу штаба или Crisis Cell формируют специальные отчёты, которые содержат хронологию локальных событий, карту источников, реакции ключевых аудиторий, действия региональной команды и возникшие проблемы. Эти отчёты используются для уточнения индексов, анализа работы в кризис и последующего post‑mortem.<br> 2.4. Периодичность обновления и задержка данных<br> 2.4.1. Периодичность обновления по типам данных. Для каждого типа данных устанавливается норматив обновления: операционные данные и логи SLA обновляются не реже одного раза в час в рабочее время; данные мониторинга СМИ и соцсетей – в режиме близком к реальному времени с периодическим обновлением агрегатов; региональная отчётность – по суточному и недельному циклам. Конкретные параметры периодичности фиксируются в технических регламентах ИТ‑блока.<br> 2.4.2. Определение и измерение задержки (data latency). Под задержкой данных понимается интервал между моментом возникновения события (создание задачи, публикация материала, выход новости) и моментом, когда соответствующая запись становится доступной в системах для расчёта показателей и отображения в дашбордах. Для ключевых источников задержка измеряется автоматически (по временным меткам источника и приёма/обработки) и контролируется как отдельный технический показатель.<br> 2.4.3. Допустимые пороги задержки и сигналы превышения. Для каждого класса данных устанавливаются предельные значения задержки (например, для операционных данных – не более 2 часов, для мониторинга – не более 30 минут, для региональной отчётности – не более 24 часов относительно планового срока). Превышение порога задержки формирует технический сигнал (alert) и отражается в дашборде качества данных; при устойчивом превышении задержки данные помечаются как низкодостоверные для управленческих решений.<br> 2.5. Нормализация и защита от искажений<br> 2.5.1. Работа с выбросами (outliers). Для временных рядов ключевых показателей (SLA, объем задач, ok_rate и др.) применяются процедуры обнаружения аномальных значений, существенно отклоняющихся от исторических паттернов или сопоставимых выборок. Выбросы анализируются аналитическим блоком: при подтверждении технической или учётной ошибки значения корректируются или помечаются как исключённые из расчётов агрегатов и индексов.<br> 2.5.2. Минимальный объём выборки и пороги расчёта. Для каждого индикатора и индекса устанавливается минимальный объём исходных данных (N) за период, при котором расчёт считается корректным; при N ниже порога показатель либо не рассчитывается, либо помечается флагом низкой достоверности. Пороговые значения N задаются в приложениях, исходя из практики и статистической устойчивости.<br> 2.5.3. Общие принципы сглаживания (скользящие средние). Для снижения влияния случайных колебаний и повышения устойчивости индикаторов допускается использование скользящих средних и иных методов сглаживания для временных рядов показателей. Период окна и тип сглаживания (простое, взвешенное и т.п.) задаются для каждого показателя отдельно и фиксируются в таблицах формул, при этом исходные «сырые» значения сохраняются и доступны для анализа.<br> 2.6. Протокол работы при отсутствии или искажении данных<br> 2.6.1. Критические сбои обновления и “молчаливые” сбои. При отсутствии ожидаемых данных (нет обновления из системы, регион не передал отчёт, мониторинг не поступает) или при выявлении аномально «ровных» рядов (которые могут свидетельствовать о сбое) ИТ‑блок и аналитический блок инициируют проверку источника. Факт сбоя фиксируется, соответствующие показатели помечаются как недоступные или недостоверные, а использование индексов, зависящих от этих данных, ограничивается до устранения причин.<br> 2.6.2. Временные резервные оценки и дефолтные значения. В исключительных случаях, когда отсутствие данных не может быть оперативно устранено, для управленческих решений допускается использование резервных оценок (например, последнего доступного значения, медианы за период, экспертной оценки), явно помеченных как временные. Применение резервных оценок фиксируется в отчётности и журналах; после восстановления данных проводится пересчёт показателей и, при необходимости, корректировка выводов и решений.<br> 3.1. Метрики по контуру согласования<br> 3.1.1. Время прохождения стадий (T_draft, T_edit, T_sense, T_approve). Для каждой задачи/материала фиксируется длительность прохождения базовых стадий approval‑flow от момента постановки до перехода на следующую стадию (черновик → редактура → смысловая экспертиза → утверждение) в минутах/часах. По этим данным рассчитываются средние, медианные и распределения времени по стадиям, типам материалов и режимам работы штаба, а также доля задач, укладывающихся в нормативные значения SLA.<br> 3.1.2. Доля материалов с нарушением SLA по стадиям и режимам. Для каждой стадии согласования и для каждого режима (Normal / Attention / Stress / Crisis) рассчитывается показатель: число материалов, по которым срок на стадии превышал установленный SLA, делённое на общее число материалов, проходивших эту стадию за период. Отдельно может рассчитываться доля материалов с нарушением совокупного SLA (от постановки до утверждения), что позволяет видеть реальную нагрузку и узкие места контура.<br> 3.2. Метрики качества материалов<br> 3.2.1. Доля материалов без возвратов. Показатель рассчитывается как отношение количества материалов, прошедших полный approval‑flow без возврата на предыдущие стадии (доработка, переработка, исправление ошибок), к общему числу материалов, завершивших согласование за период. Высокое значение доли без возвратов указывает на хорошее качество исходных черновиков и устойчивость стандартов подготовки контента.<br> 3.2.2. Доля материалов, потребовавших эскалации. Этот показатель отражает отношение количества материалов, по которым в процессе согласования или принятия решения была задействована лестница эскалации (подъём на уровень операционного руководителя, Crisis Cell или руководителя штаба), к общему числу материалов за период. Рост доли эскалаций может свидетельствовать о недостаточности полномочий на базовом уровне, неясности правил или повышенной рискованности повестки.<br> 3.3. Метрики дисциплины и исполнения<br> 3.3.1. Количество и доля нарушений регламента и режимной дисциплины. Фиксируются все случаи нарушения требований Тома 1 и связанных регламентов (обход approval‑flow без разрешения, использование неутверждённых каналов, нарушение запретов в режимах Attention/Stress/Crisis и др.), с указанием даты, ответственных и типа нарушения. Рассчитываются: абсолютное количество нарушений за период и доля нарушений (число нарушений к числу релевантных действий/материалов), что позволяет оценивать уровень дисциплины и эффективность профилактических мер.<br> 3.3.2. Связь с журналами решений и журналом инцидентов. Все зафиксированные нарушения и ключевые случаи несоблюдения регламентов увязываются с записями в журнале решений и журнале инцидентов: указывается, какие решения были приняты по результатам нарушения (дополнительное обучение, изменение процесса, дисциплинарные меры). Это обеспечивает трассируемость от метрик дисциплины к управленческим действиям и позволяет использовать накопленную статистику для корректировки регламентов и распределения полномочий.<br> 3.4. Агрегированные операционные показатели<br> 3.4.1. Суточные сводные показатели по штабу. На ежедневной основе формируется сводка ключевых операционных показателей: объем новых задач и материалов, число завершённых материалов, среднее и медианное время согласования, доля нарушений SLA, доля материалов без возвратов, количество эскалаций, число зафиксированных нарушений регламента. Эти показатели используются в утреннем слоте для оценки нагрузки и эффективности предыдущего дня, а также в вечернем логе для фиксации итогов.<br> 3.4.2. Сопоставление с режимами работы (Normal / Attention / Stress / Crisis). Агрегированные показатели анализируются в привязке к действующему режиму работы штаба и к порогам индексов, описанных в Томе 2 (SSI и др.), что позволяет выявлять соответствие фактической нагрузки и нарушений выбранному режиму или необходимость его пересмотра. При систематическом несоответствии (например, высокие доли нарушений SLA при формально «Normal» режиме) данные используются как аргумент для изменения режима и корректировки процессов.<br> 4.1. Назначение SSI и область применения<br> 4.1.1. SSI (Stress State Index) – интегральный индекс, отражающий уровень операционного и коммуникационного стресса штаба по совокупности показателей нагрузки, рисков и нарушений регламента, в нормированной шкале (например, 0–1 или 0–100). Индекс используется для того, чтобы видеть состояние системы управления не по отдельным метрикам, а через единый показатель «перегрузки» штаба.<br> 4.1.2. SSI применяется как один из ключевых входов для принятия решения о смене режима работы штаба (Normal / Attention / Stress / Crisis) в соответствии с Томом 1, а также для оценки устойчивости процессов во времени. Значения SSI учитываются при обсуждении режима на утренних и недельных слотах и фиксируются в дашбордах руководителя.<br> 4.2. Структура и компоненты SSI<br> 4.2.1. Компонент нагрузки (объём задач и очередей) отражает текущую и накопленную нагрузку штаба: число активных задач и материалов, длину очередей на стадиях approval‑flow, среднее время ожидания, долю задач, не начатых в разумный срок. Этот компонент показывает, насколько система приближается к пределу пропускной способности.<br> 4.2.2. Компонент рисков (высокорисковые и кризисные кейсы) учитывает количество и относительную долю материалов и сюжетов, помеченных как высокорисковые, а также наличие активных кризисных кейсов и уровень негативной внешней повестки. В компонент могут входить, например, число высокорисковых сюжетов за период, интенсивность негативного упоминания и индекс социального стресса по ключевым темам.<br> 4.2.3. Компонент нарушений (SLA, дисциплина, инциденты) агрегирует долю нарушений SLA по ключевым стадиям, частоту нарушений регламентов и режимной дисциплины, а также количество значимых инцидентов (включая кризисные). Рост этого компонента указывает не только на нагрузку, но и на деградацию управляемости и качества исполнения.<br> 4.3. Формулы расчёта SSI<br> 4.3.1. Нормализация компонентов в единую шкалу. Каждый из трёх компонентов (нагрузка, риски, нарушения) сначала рассчитывается в своих единицах (количество задач, процент нарушений, число кейсов и т.п.), затем приводится к единой нормированной шкале (например, 0–1) через заранее определённые функции (линейные или кусочно‑линейные зависимости, с учётом исторических диапазонов). Нормализация должна обеспечивать сопоставимость компонентов и устойчивость к выбросам, схемы нормализации фиксируются в приложениях.<br> 4.3.2. Весовые коэффициенты компонентов. Итоговое значение SSI вычисляется как взвешенная сумма нормированных компонентов с коэффициентами, отражающими приоритет управляемости и риска (например, нагрузка – 0.4, риски – 0.3, нарушения – 0.3). Веса и возможные корректирующие коэффициенты (например, усиление влияния нарушений в режиме Stress) фиксируются в таблице формул и могут пересматриваться по процедуре изменения методики.<br> 4.4. Временная инерция и сглаживание SSI<br> 4.4.1. Расчёт SSI_today и SSI_effective. Для каждого дня (или иного базового периода) рассчитывается «сырое» значение SSI_today; далее на его основе формируется сглаженное значение SSI_effective, учитывающее динамику, например по формуле: SSI_effective = α · SSI_today + (1 – α) · SSI_effective_previous, где α задаёт степень чувствительности к последним изменениям. Это позволяет избежать «дёрганья» режима из‑за разовых всплесков, сохраняя при этом реакцию на устойчивые тренды.<br> 4.4.2. Использование сглаженного SSI_effective для управленческих решений. Для целей смены режима и стратегических решений используется именно SSI_effective, а SSI_today применяется как диагностический показатель для оценки резких изменений и возможных инцидентов. В дашбордах для руководства отображаются оба значения, но триггеры смены режима и порогов привязаны к SSI_effective, если иное не определено процедурой ручного override.<br> 4.5. Пороговые значения SSI для режимов<br> 4.5.1. Диапазоны значений для Normal / Attention / Stress / Crisis. На основе исторических данных и пилотной эксплуатации задаются диапазоны значений SSI (или SSI_effective), соответствующие режимам: условно, Normal – низкие значения, Attention – средние, Stress – повышенные, Crisis – максимальные. Конкретные численные границы (например, 0–0.5; 0.5–0.7; 0.7–0.85; 0.85–1) фиксируются в приложении и используются как ориентиры для инициирования смены режима.<br> 4.5.2. Порядок пересмотра порогов на основе накопленных данных. Пороговые значения и, при необходимости, структура SSI подлежат пересмотру по итогам пилотного периода и при существенном изменении объёма/характера работы штаба, на основании анализа накопленных временных рядов и посткризисных разборов. Решения о пересмотре порогов принимаются владельцем методики совместно с руководителем штаба и фиксируются в журнале изменений Тома 2.<br> 4.6. Ручной override режима<br> 4.6.1. Критические события, перекрывающие расчётный SSI. Вводится перечень событий и условий (например, необратимые кризисные инциденты, аварии, форс‑мажоры, внезапные политические решения), при наступлении которых руководитель штаба или Crisis Cell вправе изменить режим работы штаба вне зависимости от текущего значения SSI/SSI_effective. Такие события рассматриваются как качественные факторы, не всегда своевременно отражающиеся в индексах.<br> 4.6.2. Порядок принятия и фиксации решения об override. Решение о ручном изменении режима принимается руководителем штаба (или лицом, его замещающим) по представлению операционного руководителя либо Crisis Cell и обязательно фиксируется в журнале решений с указанием основания, предыдущего и нового режима, характера override и предполагаемого срока пересмотра. При необходимости дополнительно фиксируются сопутствующие ограничения и специальные указания для регионов и спикеров.<br> 4.6.3. Возврат к режиму по SSI_effective после override. После стабилизации ситуации и при восстановлении корректной работы индексов режим возвращается к значению, соответствующему текущему SSI_effective, по решению руководителя штаба; факт возврата также фиксируется в журнале решений. При этом рекомендуется использовать период наблюдения (несколько циклов измерения), чтобы убедиться в устойчивости показателей перед снятием ручного override.<br> 5.1. Классификация источников<br> 5.1.1. Надёжные источники (Tier A). К Tier A относятся источники с устойчивой репутацией и высоким уровнем доверия: официальные государственные ресурсы, крупные национальные и международные медиа, признанные экспертные и отраслевые площадки, а также собственные верифицированные ресурсы штаба. Для таких источников действует презумпция надёжности: их материалы могут выступать первичными ссылками при условии актуальности и отсутствия противоречий.<br> 5.1.2. Условно надёжные и рискованные источники. К условно надёжным относятся источники с ограниченной или неоднородной историей достоверности (региональные и нишевые медиа, отдельные паблики и каналы), а к рискованным – площадки без устойчивой репутации, анонимные каналы, ресурсы с признаками манипулятивного контента. Для этих групп усиливаются требования к верификации: данные используются только при наличии дополнительных подтверждений, а ссылки из рискованных источников могут не засчитываться в ok_rate или учитываться с минимальным весом.<br> 5.2. Расчёт ok_rate и weighted_ok_rate<br> 5.2.1. Базовая формула ok_rate. ok_rate определяется как отношение числа ссылок, признанных валидными по результатам автоматической и/или ручной проверки (статус «OK» в системе link‑audit), к общему числу проверенных ссылок за период; показатель рассчитывается по штабным и региональным отчётам, а также по отдельным каналам. В расчёт включаются только ссылки, прошедшие базовую техническую проверку (доступность URL, отсутствие явных ошибок, корректный формат).<br> 5.2.2. Trust‑score площадки и вес источника. Для каждой площадки (домена, аккаунта, канала) рассчитывается trust‑score – интегральная оценка надёжности, основанная на типе источника (Tier A/B/C и т.п.), истории достоверности, внешних метриках доверия (аналог trust flow / authority score) и внутренней статистике ошибок и опровержений. Trust‑score нормируется в диапазон (например, 0–1 или 0–100) и используется как вес при расчёте взвешенных показателей качества ссылок.<br> 5.2.3. Расчёт weighted_ok_rate с учётом классов площадок. Взвешенный показатель weighted_ok_rate рассчитывается как отношение суммы весов валидных ссылок (OK, умноженных на trust‑score соответствующих площадок) к суммарному весу всех проверенных ссылок за период. Таким образом, ошибки на высоконадёжных площадках (Tier A с высоким trust‑score) оказывают большее негативное влияние на показатель, чем ошибки на малоавторитетных или рискованных ресурсах.<br> 5.3. Дополнительные показатели качества данных<br> 5.3.1. Доля отсутствующих или недоступных ссылок. Рассчитывается как отношение числа ссылок со статусами технической недоступности (ошибки 404/500, приватные/удалённые материалы, истекшие ссылки, некорректные URL) к общему числу заявленных в отчётности ссылок за период. Высокое значение показателя указывает на низкое качество ведения отчётности, возможные попытки «донадувания» активности и требует работы с соответствующими командами.<br> 5.3.2. Доля ссылок, не прошедших содержательную проверку фактов. В этот показатель включаются ссылки, которые технически доступны, но по результатам содержательной проверки признаны нерелевантными, вводящими в заблуждение, содержащими недостоверные данные или не подтверждающими заявленный факт. Показатель может рассчитываться выборочно (по выборкам) и использоваться как индикатор качества факт‑чекинга и дисциплины в использовании источников.<br> 5.4. Использование ok_rate в управлении<br> 5.4.1. ok_rate как KPI для регионов и команд. Для региональных штабов и отдельных блоков (контент, аналитика) устанавливаются целевые значения ok_rate и, при необходимости, weighted_ok_rate, которые входят в систему KPI: достижение или превышение целевого уровня подтверждает качество отчётности и работы с источниками. Систематически низкий ok_rate является основанием для дополнительных проверок, обучения и корректирующих действий.<br> 5.4.2. Связь с дисциплинарным контуром и режимами. Существенные и устойчивые отклонения ok_rate и сопутствующих показателей (высокая доля недоступных или недостоверных ссылок, частые «FAIL/REVIEW» по link‑audit) могут рассматриваться как нарушение стандартов качества и служить основанием для управленческих и, при необходимости, дисциплинарных решений. В условиях повышенных режимов (Attention/Stress/Crisis) требования к ok_rate и допустимому уровню ошибок могут ужесточаться, а эпизоды грубых нарушений качества источников – эскалироваться в Crisis Cell.<br> 6.1. Общий дашборд штаба<br> 6.1.1. Набор ключевых показателей (режим, SSI, очереди, ok_rate). На общем дашборде штаба для руководителя отображается ограниченный набор ключевых метрик: текущий режим работы (Normal / Attention / Stress / Crisis), актуальное значение SSI и SSI_effective, суммарная длина очередей по approval‑flow, базовые показатели SLA, а также ok_rate / weighted_ok_rate по штабу и, при необходимости, агрегированный LI/PRS при их использовании. Дополнительно могут отображаться 1–2 индикатора по регионам (например, количество проблемных регионов) и краткая сводка по кризисным кейсам, при этом общее число «герой‑метрик» на экране не превышает 5–7.<br> 6.1.2. Цветовые и пороговые сигналы для ЛПР. Ключевые показатели дашборда снабжаются цветовой индикацией по принципу «светофора» и порогами (зелёный – норма, жёлтый – внимание, красный – критично), привязанными к целевым значениям и порогам режимов. Это позволяет руководителю видеть состояние системы «с одного взгляда» и концентрироваться на показателях, вышедших в зону риска, не углубляясь сразу в детализацию.<br> 6.2. Дашборд approval‑flow<br> 6.2.1. Очереди по стадиям согласования. Специализированный дашборд approval‑flow показывает количество материалов на каждой стадии (черновик, редактура, смысл, утверждение), среднее время нахождения на стадии и текущие очереди с разбивкой по типам материалов и уровням риска. Это позволяет операционному руководителю и ответственным за блоки оперативно видеть накопление задач и перераспределять ресурсы.<br> 6.2.2. Просрочки SLA и узкие места. На том же дашборде выделяются стадии и сегменты, где доля нарушений SLA превышает установленный порог, с визуальной маркировкой «узких мест» (например, стадия смысловой экспертизы для высокорисковых материалов). При необходимости реализуются быстрые фильтры по режиму, типу материала, блоку или региону для анализа причин задержек.<br> 6.3. Региональный дашборд<br> 6.3.1. Показатели отчётности и ok_rate по регионам. Региональный дашборд отображает для каждого региона набор ключевых показателей: своевременность и полноту отчётности, ok_rate / weighted_ok_rate, долю недоступных или проблемных ссылок, базовые показатели активности (число материалов, кейсов). Данные выводятся в виде таблицы/heatmap с возможностью сортировки и фильтрации, что позволяет быстро выявлять регионы с системными проблемами в отчётности и качестве данных.<br> 6.3.2. Маркировка проблемных регионов и динамика. Регионы с устойчивыми отклонениями от целевых значений (низкий ok_rate, частые нарушения отчётности, высокая доля ссылок со статусом FAIL/REVIEW) помечаются специальными статусами (например, P1/P2/P3) и цветовой индикацией. В дашборде предоставляются простые графики динамики по каждому региону (тренд ok_rate, количество нарушений за периоды), позволяющие оценивать эффект корректирующих мер.<br> 6.4. Технические требования к дашбордам<br> 6.4.1. Частота обновления и доступность. Для каждого дашборда определяется минимально допустимая частота обновления данных (например, общий и approval‑дашборд – не реже, чем раз в час в рабочее время; региональный – по мере поступления отчётности, с ежедневным обновлением агрегатов). Дашборды должны быть доступны через утверждённые внутренние системы, с обеспечением резервирования и устойчивости к сбоям.<br> 6.4.2. Разграничение прав доступа и уровни представления. Доступ к дашбордам и видимость отдельных показателей настраиваются по ролям: руководитель штаба, операционный руководитель, аналитический блок, региональные координаторы, и т.п. Для разных ролей могут применяться различные уровни детализации (например, руководитель видит агрегированные показатели и сигналы, аналитики – детальные таблицы и фильтры).<br> 6.5. Ограничение плотности показателей<br> 6.5.1. Максимальное число ключевых показателей на главном экране. На каждом дашборде уровня ЛПР (общий дашборд штаба, ключевой экран регионального дашборда) допускается отображение не более 5–7 ключевых метрик в одном экране без прокрутки, чтобы избежать информационной перегрузки и «расфокуса» внимания. Дополнительные показатели выносятся на второстепенные вкладки, раскрывающиеся панели или отдельные аналитические дашборды.<br> 6.5.2. Разные наборы показателей для разных ролей (руководство, операционный штаб, регионы). Состав и приоритет показателей на дашбордах адаптируются под задачи ролей: для руководителя штаба – режим, SSI, ключевые риски и качество данных; для операционного штаба – очереди, SLA, эскалации; для регионов – ok_rate, полнота отчётности, базовая активность. Это обеспечивает принцип «правильные данные – правильному уровню» и минимизирует шум для пользователей.<br> 7.1. Ежедневные отчёты<br> 7.1.1. Структура утреннего отчёта для утреннего слота. Утренний отчёт формируется к началу утреннего слота и включает: действующий режим работы штаба; ключевые индикаторы за предыдущий день (SLA, очереди, ок_rate, нарушения регламента, эскалации); актуальное значение SSI/SSI_effective; перечень активных высокорисковых и кризисных кейсов; краткий список приоритетных задач и решений, требующих внимания руководства. Формат отчёта должен позволять его просмотр и понимание в течение нескольких минут, с минимальной текстовой нагрузкой и ссылками на дашборды для детализации.<br> 7.1.2. Структура вечернего лога для вечернего слота. Вечерний лог фиксирует итоги дня: выполненные и невыполненные задачи, фактические значения ключевых операционных метрик (SLA, объём задач, ok_rate, нарушения), случаи резервного режима и ручных override, а также факты нарушений регламентов и принятые по ним решения. Лог формируется в стандартизированном формате и используется как вход для утреннего отчёта и недельного анализа (weekly reset).<br> 7.2. Недельные отчёты<br> 7.2.1. Отчёт к weekly reset (недельный срез по метрикам и индексам). Недельный отчёт готовится к совещанию weekly reset и содержит: динамику ключевых метрик и индексов за неделю (SLA, очереди, ok_rate, SSI, LI/PRS при наличии), сравнительный анализ по дням и режимам, основную статистику по нарушениям и кризисным кейсам. Отдельно выделяются тренды (улучшение/ухудшение), узкие места и рекомендации по корректировке процессов, режимов и приоритетов.<br> 7.2.2. Формат презентации для руководителя штаба. Для руководителя штаба формируется краткая презентационная версия недельного отчёта (несколько слайдов или сводный экран), концентрирующаяся на выводах: где ситуация стабильно в норме, где накапливаются риски, какие решения предлагаются. При необходимости в презентацию включаются диаграммы и тепловые карты, иллюстрирующие распределение нагрузки и качества по блокам и регионам.<br> 7.3. Специальные отчёты<br> 7.3.1. Отчёты по кризисам и After Action Review. По завершении кризисной фазы по каждому значимому кризису готовится специальный отчёт (After Action Review), включающий: хронологию событий, динамику ключевых индексов и метрик на период кризиса, оценку соблюдения протоколов, анализ успешных и проблемных решений, перечень уроков и предложений по изменениям. В отчёте фиксируются конкретные корректирующие действия, ответственные и сроки, а также при необходимости – предложения по обновлению Тома 1 и Тома 2.<br> 7.3.2. Отчёты по регионам (плановые и по запросу). Для регионов могут формироваться плановые периодические отчёты (например, ежемесячные) и отчёты по запросу руководства, содержащие агрегированные показатели активности, качества данных (ok_rate, доля недоступных ссылок), дисциплины и исполнения, а также сравнение региона с группой аналогичных регионов. Такие отчёты используются для адресной работы с региональными командами, планирования поддержки и, при необходимости, применения мер реагирования.<br> 7.4. Отражение неопределённости<br> 7.4.1. Флаги низкой достоверности (low confidence) для показателей. Для всех ключевых показателей (в том числе SSI, ok_rate, SLA‑метрики) предусмотрен механизм маркировки низкой достоверности: при наличии существенных задержек данных, малых выборок, выбросов или выявленных сбоев показатель помечается визуальным флагом (например, «low confidence») в отчётах и дашбордах. Это предотвращает некорректное использование таких значений как основание для важных управленческих решений.<br> 7.4.2. Основания для установки флагов и порядок их снятия. Основаниями для установки флага низкой достоверности являются: недостаточный объём данных (N ниже порога), превышение допустимой задержки (latency), зафиксированные технические сбои, а также значительные расхождения между источниками. Установка и снятие флагов фиксируется в логах аналитического и ИТ‑блоков; после устранения причин проводится пересчёт показателей и, при необходимости, корректировка ранее сделанных выводов в последующих отчётах.<br> 8.1. Владелец методологии и данных<br> 8.1.1. Ответственность за корректность методик расчёта. Владелец методологии и данных (data owner для индексов и метрик) отвечает за полноту и корректность описаний всех показателей Тома 2: определения, формулы, источники данных, правила нормализации и пороги. Он обеспечивает соответствие методик целям штаба и контролирует, чтобы изменения в процессах отражались в обновлении методологической части.<br> 8.1.2. Утверждение изменений в методиках и порогах. Все изменения в методиках расчёта индикаторов и индексов (веса SSI, пороговые значения, критерии ok_rate и др.) инициируются профильными блоками, но вступают в силу только после согласования и утверждения владельцем методологии и руководителем штаба по процедуре, согласованной с Томом 1. Утверждённые изменения фиксируются в журнале изменений и доводятся до всех затронутых подразделений.<br> 8.2. Ответственные за сбор и валидацию<br> 8.2.1. Аналитический блок (мониторинг, индексы, ok_rate). Аналитический блок отвечает за настройку и ежедневное ведение контуров мониторинга, расчёт индексов (SSI, PRS и др. при наличии), операционных метрик и показателей качества (ok_rate, weighted_ok_rate). В его функции входит первичная валидация данных (поиск аномалий, выбросов, провалов), применение флагов низкой достоверности и подготовка аналитических выводов для отчётности и weekly reset.<br> 8.2.2. Технический и ИТ‑блок (загрузка, интеграции, резервирование). Технический и ИТ‑блок отвечает за бесперебойную загрузку данных из источников (таск‑трекеры, системы мониторинга, реестры отчётности), корректную работу интеграций, соблюдение параметров задержки (latency), резервирование и восстановление после сбоев. Он обеспечивает наличие технических логов, необходимых для аудита качества данных и расследования инцидентов.<br> 8.3. Взаимодействие с регионами<br> 8.3.1. Ответственность регионов за своевременную и корректную отчётность. Региональные штабы несут ответственность за формирование и передачу отчётности в установленные сроки, заполнение всех обязательных полей, корректность ссылок и базовых показателей. Несоблюдение сроков, систематические ошибки в данных, высокий уровень недоступных или проблемных ссылок отражаются в региональных показателях и могут влечь управленческие последствия.<br> 8.3.2. Обратная связь по качеству данных и корректирующие меры. Аналитический и ИТ‑блоки обеспечивают регулярную обратную связь регионам по качеству и полноте предоставляемых данных (в том числе по ok_rate, доле недоступных ссылок, нарушениям форматов), с указанием типовых ошибок и рекомендаций по исправлению. При системных проблемах с конкретным регионом запускаются корректирующие меры: дополнительное обучение, сопровождение, усиленный контроль, а при необходимости – пересмотр ролей и ответственности.<br> 8.4. Порядок внесения изменений в Том 2<br> 8.4.1. Связь с процедурой изменения Тома 1. Изменения в Том 2 инициируются владельцем методологии, блоками или руководителем штаба и проходят согласование по процедуре, аналогичной установленной для Тома 1 (инициатор → рассмотрение → утверждение руководителем штаба), с обязательной оценкой влияния на действующие процессы и индексы. При изменении подходов к режимам, ролям или ключевым метрикам изменения в Том 2 согласуются с актуальной редакцией Тома 1, чтобы избежать противоречий.<br> 8.4.2. Версионирование методик и ведение журнала изменений. Для Тома 2 ведётся журнал изменений, в котором фиксируются: дата и номер версии, перечень изменённых разделов и методик, причина изменений, инициатор и утверждающее лицо. Обеспечивается доступ к предыдущим версиям методики (для аудита и сравнительного анализа), а действующая версия считается единственным источником истины для расчётов и отчётности.<br> 9.1. Таблицы формул расчёта метрик и индексов<br> 9.1.1. Формулы операционных метрик и описание переменных. В приложении приводятся формулы расчёта основных операционных показателей (время стадий, доли нарушений SLA, доля материалов без возвратов, доля эскалаций и др.) с явным перечислением всех переменных, единиц измерения, источников данных и периодичности расчёта. Для каждой метрики указывается тип агрегирования (среднее, медиана, доля) и возможные фильтры (режим, тип материала, регион).[1][2][3]<br> 9.1.2. Формулы SSI, компонентов и весов. В отдельной таблице фиксируются формулы расчёта компонентов SSI (нагрузка, риски, нарушения), функции их нормализации, применяемые весовые коэффициенты и итоговая формула индекса. При необходимости указываются альтернативные настройки (например, разные веса для пилотных сценариев) и ссылки на разделы, где описаны пороги и интерпретация значений.[3][4][5]<br> 9.2. Примеры расчётов и взаимосвязей<br> 9.2.1. Пример расчёта SSI по конкретному дню. Приводится пошаговый пример: исходные значения метрик за выбранный день (очереди, число высокорисковых кейсов, доля нарушений SLA и т.п.), расчёт нормированных компонентов, итогового SSI_today и SSI_effective, а также соответствующего ему режима. Пример демонстрирует, как отдельные показатели влияют на итоговое значение индекса.[6][3]<br> 9.2.2. Пример расчёта weighted_ok_rate по региону. На выбранном регионе показывается: перечень ссылок за период, trust‑score площадок, статусы link‑audit (OK/FAIL/REVIEW), расчёт базового ok_rate и взвешенного weighted_ok_rate с промежуточными шагами. Пример позволяет региональным командам понять, как именно качество источников отражается в их показателях.[7][8][3]<br> 9.2.3. Матрица взаимосвязей индексов, KPI и режимов. В табличной форме отражаются связи: какие метрики входят в какие индексы (например, SLA → компонент SSI, ok_rate → LDataIntegrity → PRS), какие индексы и KPI используются как триггеры смены режимов и управленческих решений. Матрица служит «картой» системы, повышающей прозрачность и объяснимость решений для участников штаба.[9][10][3]<br> 9.3. Шаблоны дашбордов<br> 9.3.1. Структура полей общего дашборда. Описывается перечень полей и визуальных элементов общего дашборда (название показателя, единицы, период, пороговые значения, цветовая индикация, ссылки на детализацию), а также их размещение на экране. Это служит техническим заданием для реализации и обеспечивает единообразие визуализации.[11][12][3]<br> 9.3.2. Структура полей регионального и approval‑дашбордов. Аналогично описываются структуры регионального и approval‑дашбордов: обязательные показатели, фильтры, уровни детализации, формат представления очередей, SLA и региональных KPI. При необходимости указываются варианты отображения для разных ролей (руководство, аналитики, регионы).[13][3][9]<br> 9.4. Чек‑лист качества данных для регионов<br> 9.4.1. Минимальные требования к отчётам и данным. Чек‑лист фиксирует, что каждый региональный отчёт должен содержать: полный набор обязательных полей, корректно оформленные ссылки, указанные периоды и метрики, соблюдение форматов и сроков подачи. Отдельно выделяются требования к полноте (отсутствие пустых ключевых полей) и согласованности данных.<br> 9.4.2. Типовые ошибки, примеры «хороших» и «плохих» отчётов. В приложении приводятся примеры отчётов с типичными ошибками (битые ссылки, несоответствие периодов, дубли, отсутствие ключевых полей) и корректно заполненные образцы, с пояснениями, какие элементы считаются критичными. Это позволяет регионам использовать чек‑лист как инструмент самопроверки перед отправкой отчётности.