Реестр источников GRI и запрос данных

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Многие команды по подготовке отчётности начинают сбор данных с электронной таблицы, в которой указаны только 'показатель', 'значение' и 'ответственный'. Этого может быть достаточно, чтобы запросить числовое значение, но недостаточно, чтобы установить, отвечает ли это значение требованию к раскрытию, используется ли правильная граница, была ли проведена проверка и можно ли найти его в опубликованном отчёте. По мере подготовки текста методологические примечания остаются в электронной переписке, доказательства — на общих дисках, а ссылки на страницы добавляются вручную после подготовки дизайна. В следующем году возникают те же вопросы.

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

Реестр должен позволять компетентному проверяющему ответить на пять вопросов без поиска по рабочей переписке проекта: Что именно требовалось? Какие совокупность и период входили в охват? Какой источник и метод были использованы для получения информации? Какие проверка и разрешение вопросов были проведены? Где опубликована утверждённая информация? Если на один из этих вопросов нельзя ответить, строка не является полной.

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

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

Рисунок 2. Структура практической записи реестра источников GRI. В записи должно быть показано, что требуется, кто является владельцем, как определены данные, где находятся подтверждающие материалы, что остается нерешенным и где опубликовано утвержденное раскрытие.

Зафиксируйте набор источников. До разработки запросов укажите применимые Универсальные, Отраслевые и Тематические стандарты GRI, редакции и контекст вступления в силу.

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

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

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

Сопоставьте существующие источники. До направления нового запроса свяжите исходные системы, отчёты, политики, договоры, расчёты, протоколы заседаний органов управления и внешние наборы данных.

Сформируйте запрос данных. Направляйте получателю только относящиеся к нему строки с определениями, требованиями к доказательствам, крайним сроком и маршрутом эскалации.

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

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

Запрос должен преобразовывать техническую строку в инструкцию, которую владелец данных может выполнить. Запрос, содержащий только 'данные о работниках согласно GRI 2-7', предполагает, что получателю известны категории, основа подсчёта, период, требуемая разбивка, допустимость оценок и требования к доказательствам. Приведённый ниже шаблон делает эти ожидания явными.

Операционный вопрос, охват, дата, разбивки, методологический подход, сверка, подтверждающие материалы, проверяющий и срок представления указаны явно. В запросе не предлагается владельцу данных HR решать, допустимо ли отсутствие данных, или составлять Индекс содержания; эти суждения остаются за командой по подготовке отчётности и технической проверке.

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

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

Ответственный за подготовку отчётности создаёт реестр источников с одной строкой для каждого существенного информационного требования и присваивает стабильные идентификаторы. Строки GRI 2, GRI 3 и существенных тем связаны с переписью субъектов и подтверждающими документами по вопросам управления. Тематические показатели связаны с выгрузками из систем и файлами расчётов. Требования к описательной информации связаны с утверждёнными политиками, подтверждающими документами по процессам, протоколами или управленческими записями, а не только с проектом абзаца.

Каждая дочерняя компания получает отфильтрованный пакет запросов. Центральное методологическое примечание определяет категории работников, пересчёт энергии, классификацию инцидентов и приобретения. Журнал вопросов выявляет три повторяющиеся проблемы: местные определения, не соответствующие руководству группы, доказательства, хранящиеся только в электронной почте, и раскрытия на веб-сайте, URL которых не являются окончательными. Группа согласует определения до консолидации, перемещает доказательства в контролируемые папки и откладывает окончательную проверку Content Index до момента доступности опубликованного веб-сайта. В конце года утверждённый реестр блокируется и переносится на следующий цикл с пометкой изменённых строк.

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

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