Gap-анализ

Gap-анализ — это анализ разрывов соответствия: по каждому требованию раскрытия система определяет, насколько оно закрыто вашими данными. Эта страница объясняет три статуса покрытия, логику, по которой значение засчитывается, почему карантинные и непроверенные данные не дают полного покрытия, и как из разрывов формируется план устранения с ответственным и сроком. Она поможет прочитать таблицу gap-анализа и спланировать доработку: план устранения ведёт автор оценки, а аудитор видит его без права правки. Предварительно полезно понимать, как метрики связаны с критериями — см. привязку показателей к раскрытиям и каталог стандартов.

Что такое gap-анализ

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

Три статуса и их индикация

В блоке «Анализ разрывов соответствия» каждое требование получает один из трёх статусов с цветным бейджем:

• Покрыто (зелёный) — требование закрыто подтверждёнными достоверными данными.
• Частично (жёлтый) — данные есть, но неполны или не подтверждены; требуется доработка.
• Отсутствует (красный) — валидных данных нет; создаётся задача в плане устранения.

Логика определения статуса

Статус считается не «на глаз», а по строгим правилам:

• Покрыто — есть метрика с полнотой покрытия full и валидным достоверным (подтверждённым) значением.
• Частично — валидные данные есть, но они либо не подтверждены, либо покрытие только partial, либо раскрытие неполно.
• Отсутствует — ни по одной привязанной метрике нет валидного значения.

Почему карантин и непроверенные данные не дают «Покрыто»

Это прямое следствие правила «скоринг только по достоверным данным»:

• Значения из карантина считаются невалидными и в покрытие не входят вовсе — требование, закрытое только карантинным значением, будет «Отсутствует».
• Внесённое, но не верифицированное значение опускает статус до «Частично»: данные есть, но достоверность не подтверждена.

Достоверными система считает любой статус верификации, кроме «не проверено»: самооценка и внутренняя проверка засчитываются как достоверные. Подробнее о статусах — в материале о верификации, о карантине — в валидации и карантине.

Производные и экспертные метрики

У составных (composite) и экспертных показателей прямого введённого значения нет. Для них покрытие определяется наличием рассчитанного балла метрики и тем, включал ли этот расчёт непроверенные данные: если включал — полного покрытия не будет.

План устранения разрывов

Для статусов «Частично» и «Отсутствует» система автоматически создаёт черновик задачи в плане устранения:

• для «Отсутствует»: «Собрать данные и подтверждающие свидетельства по требованию: <код>»;
• для «Частично»: «Дополнить/подтвердить данные по требованию: <код>».

У задачи предзаполняется срок (по периоду оценки), но ответственного назначают вручную. Срок и ответственного под реальный план работы задаёт автор оценки, пока она не завершена (администратор — тоже); аудитор и другие участники видят эти поля только для чтения.

Сроки и напоминания

По приближающимся срокам устранения система отправляет уведомление «Приближается срок устранения». Управлять каналами доставки можно в настройках уведомлений.

Когда строится gap-анализ

Gap-анализ строится при расчёте оценки — он запускается вместе со скорингом на шаге результатов — и пересчитывается при изменении данных. Важная гарантия целостности: разрывы пишутся в той же транзакции, что и баллы, поэтому таблица gap всегда согласована с актуальным ESG-баллом.

Где смотреть результат

Результат виден в блоке «Анализ разрывов соответствия» на шаге 7 мастера: код требования, заголовок, текст плана устранения, срок и цветной статус-бейдж. Сводка по разрывам попадает в ESG-аудиторский отчёт под стандарт.

Разделение обязанностей

Статус «Покрыто» опирается на достоверность значения, а достоверным его делает самооценка автора или внутренняя проверка. Самооценку автор ставит своим данным сам, и требование может получить «Покрыто» без участия второго человека. Независимое подтверждение — внутренняя проверка — доступно только не тому, кто вносил данные, обычно аудитору. Поэтому, если для отчёта важна независимость, смотрите не только статус покрытия, но и статус верификации самих значений.

Что отложено

Отслеживание регуляторных дедлайнов раскрытия в полном объёме и прогноз траектории закрытия разрывов — частично или Фаза 2. В Фазе 1 предзаполненный срок устранения берётся из периода оценки, а не из реального регуляторного дедлайна стандарта.

Частые ошибки

• Ждать «Покрыто» сразу после ввода данных. Пока у значения статус «не проверено» — автор не поставил самооценку и аудитор не выполнил внутреннюю проверку, — статус остаётся «Частично».
• Думать, что значение из карантина «почти покрывает» требование. Карантинные и отклонённые данные невалидны и в покрытие не входят совсем — требование будет «Отсутствует».
• Пытаться закрыть разрыв тем же пользователем, кто вносил данные. Разделение обязанностей не даст автору подтвердить своё значение.
• Считать предзаполненный срок официальным регуляторным дедлайном. Это срок по периоду оценки; его нужно скорректировать вручную, а ответственного назначить отдельно.
• Игнорировать статус «Частично» как «почти готово». Он сигнализирует о неполноте или неподтверждённости; без доработки требование в отчёте останется незакрытым.
• Ожидать gap-анализ по всем стандартам каталога. Анализируются только требования, привязанные к метрикам данной оценки.