От обезличенного Excel до управленческой HSE-аналитики. Этап 2: создаём автономный интерактивный HSE-дашборд с помощью вайб-кодинга

ИИ помогает создать программную оболочку на обезличенном Excel-шаблоне, а реальная рабочая база загружается в готовый HTML уже локально на компьютере пользователя.

Введение

В первой публикации я показал, как мы решили вопрос безопасной подготовки данных: создали локальный маскировщик и научились получать обезличенный Excel-шаблон, сохраняя структуру рабочей базы, но не передавая реальные персональные данные во внешнюю ИИ-среду.

Следующий вопрос возникает практически сразу: что делать с этим шаблоном дальше?

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

При этом сохранялось главное условие первого этапа: на этапе внешней разработки реальная рабочая база предприятия в ИИ не передаётся.

Почему вообще понадобился собственный дашборд

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

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

Первые онлайн-дашборды на базе Superset закрывают базовые количественные задачи. Но для практической работы этого недостаточно. Если руководитель видит, что проведено 500 проверок или выявлено 70 отклонений, следующий вопрос всегда один: где именно это произошло, почему и какие конкретные записи за этим стоят?

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

Шаг 1. Сначала понять данные, а не писать программу

Одна из самых распространённых ошибок при работе с ИИ — сразу просить: «Сделай мне дашборд». Красивую картинку получить можно быстро, но далеко не факт, что ей потом можно будет пользоваться.

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

Таким образом ИИ сначала выступает не программистом, а аналитиком данных.

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

Prompt 1 — анализ структуры обезличенной базы: см. приложение в конце статьи.

Поведенческие диалоги безопасности: от общей цифры к конкретной записи

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

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

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

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

Здесь я использую простое правило: если после просмотра графика непонятно, какое управленческое решение он помогает принять, скорее всего, такой график в дашборде не нужен.

Prompt 2 и Prompt 5 — структура HSE-дашборда и интерактивная детализация: см. приложение в конце статьи.

Дополнение табелем: как увидеть установленную рекомендованную частоту ПДБ

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

Сначала для разработки использовался обезличенный шаблон табеля, затем уже локально — фактический табель. Это позволило видеть не только объём проведённых ПДБ, но и выполнение установленной рекомендованной частоты их проведения.

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

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

Эта доработка не потребовала нового принципа. Мы просто развили уже созданную логику и подключили ещё один массив данных.

Prompt 6 — анализ ПДБ с учётом фактически отработанных смен: см. приложение в конце статьи.

ККР: тот же подход, но для контроля критических рисков

Аналогичная логика применяется и к ККР. Из исходной выгрузки можно увидеть, сколько ККР проведено и сколько из них содержало отклонения. Но валовое количество само по себе не отвечает на главный вопрос: насколько требование реально выполняется в каждой смене.

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

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

Все диаграммы при этом остаются кликабельными: от общего показателя можно провалиться глубже — к подразделению, затем к участку, далее к профессии и в итоге к карточке конкретного работника или конкретной записи.

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

Prompt 7 — ККР и фактический табель: расчёт выполнения и проваливание до работника: см. приложение в конце статьи.

Шаг 2. Первый прототип и последовательные доработки

После того как структура данных и логика аналитики понятны, можно переходить непосредственно к вайб-кодингу.

Задача формулируется уже достаточно конкретно: создать один автономный HTML-файл, который открывается обычным браузером, содержит KPI, фильтры, интерактивные диаграммы, таблицу исходных записей и работает без установки отдельного программного обеспечения.

На этом этапе внутри программы по-прежнему используются только обезличенные данные.

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

Вместо переписывания всего приложения задача задаётся точечно: «Сделай фильтры зависимыми», «Добавь детализацию по клику», «Исправь только диаграмму №6, остальную логику не меняй».

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

Prompt 3, Prompt 5 и Prompt 8 — создание первого HTML, детализация и исправление дефектов: см. приложение в конце статьи.

Шаг 3. Убираем шаблон и загружаем реальные данные локально

Когда интерфейс и логика отработаны на обезличенном шаблоне, из конечной версии убираются демонстрационные данные. HTML остаётся программной оболочкой.

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

То есть финальная схема проста: готовый HTML и рабочий Excel находятся на одном компьютере; рабочие данные загружаются в программу локально и во внешнюю ИИ-среду уже не передаются.

На публикационном скриншоте реальные фамилии замаскированы ретушью. Это важно: сама статья должна показывать принцип работы, а не раскрывать персональные данные.

Prompt 4 — локальная загрузка рабочей Excel-базы: см. приложение в конце статьи.

Загрузка, добавление, сброс и офлайн-копия

Отдельное внимание пришлось уделить пользовательским функциям. На практике важно не только открыть дашборд, но и быстро управлять его состоянием.

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

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

Видеоприложение 1. Трансляция экрана: от шаблона к рабочей базе — видео в конце статьи.

От аналитики — к управленческому разговору

Главная ценность дашборда проявляется не на экране, а на совещании.

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

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

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

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

Временный инструмент или будущая промышленная система

Автономный HTML-дашборд для нас не является конечной целью и не конкурирует с корпоративной ИТ-архитектурой.

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

Если прототип подтвердил полезность, его логику гораздо проще передать ИТ-разработчикам для последующей реализации на JavaScript, в Superset или в другой корпоративной среде с автоматической интеграцией данных.

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

Что получилось на выходе

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

Для специалиста по безопасности это заметно сокращает путь от идеи до работающего прототипа.

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

В следующей публикации я хочу перейти от анализа данных к другому направлению: показать, как ИИ из обычного помощника постепенно превратился во «второго эксперта», оценивающего качество пятиминуток безопасности и поведенческих диалогов по нескольким независимым критериям.

Готовые Prompt для создания автономного HSE-дашборда по ПДБ и ККР

Практическое правило: во внешнюю ИИ-среду передаётся только проверенный обезличенный шаблон. Реальные рабочие Excel-файлы, табели и персональные данные подключаются уже локально в готовой HTML-оболочке.

Как промпты связаны со статьёй

Prompt 1. Анализ структуры обезличенного Excel

Я загружаю обезличенный Excel-шаблон рабочей HSE-базы.

Сначала ничего не программируй.

Проанализируй:
1. листы файла;
2. заголовки столбцов;
3. типы данных;
4. обязательные и необязательные поля;
5. иерархические связи между предприятием, цехом, участком и другими уровнями;
6. поля, пригодные для фильтрации;
7. поля, пригодные для KPI, рейтингов и визуализаций;
8. поля, которые можно использовать как устойчивый обезличенный идентификатор работника;
9. потенциальные проблемы исходной базы: пустые значения, разные написания одного подразделения, неодинаковые форматы дат, дубли, смешение текста и чисел, неоднозначные названия столбцов.

Для базы ПДБ отдельно определи, где находятся:
- дата и время;
- предприятие;
- цех;
- участок / внутреннее подразделение;
- проводящий ПДБ;
- должность проводящего;
- работник / обезличенный идентификатор;
- вид безопасного или опасного поведения;
- процесс / вид работ;
- описание наблюдения;
- результат или реакция.

После анализа:
- кратко опиши структуру данных;
- предложи, какие связи между полями нужно сохранить;
- перечисли спорные места, которые необходимо подтвердить у пользователя;
- только после подтверждения предложи архитектуру будущего дашборда.

Не пытайся восстанавливать обезличенные значения и не делай выводов о личности конкретного работника.

Prompt 2. Архитектура дашборда по поведенческим диалогам безопасности

На основании подтверждённой структуры обезличенного Excel предложи архитектуру автономного HSE-дашборда по поведенческим диалогам безопасности.

Главный принцип: каждая визуализация должна отвечать на конкретный управленческий вопрос. Не добавляй графики только ради оформления.

Предусмотри:
1. ключевые KPI по объёму ПДБ и наблюдениям;
2. фильтры по периоду;
3. зависимую иерархию предприятие → цех → участок / внутреннее подразделение;
4. фильтр по проводящему ПДБ;
5. фильтр по должности проводящего;
6. динамику ПДБ по месяцам и/или дням;
7. сравнение предприятий;
8. ТОП подразделений / участков;
9. ТОП проводящих ПДБ;
10. структуру безопасного и опасного поведения;
11. категории опасных наблюдений;
12. анализ процессов / видов работ;
13. рейтинг работников, у которых опасное поведение фиксировалось неоднократно;
14. поиск по работнику или обезличенному идентификатору;
15. историю ПДБ по выбранному работнику;
16. возможность увидеть, повторялся ли один и тот же вид опасного поведения у одного работника в разные даты, у разных руководителей или на разных участках;
17. экспорт текущей выборки в Excel.

Для каждой визуализации отдельно укажи:
- какой вопрос руководителя она закрывает;
- какие поля используются;
- куда должен вести клик по элементу графика.

Сначала опиши архитектуру словами. Код пока не создавай.

Prompt 3. Создание первого автономного HTML

Создай на основании согласованной архитектуры первую автономную версию интерактивного HSE-дашборда.

Требования:
1. Результат — один HTML-файл.
2. Файл открывается обычным браузером без установки дополнительного ПО.
3. На этапе разработки используй только обезличенные демонстрационные данные.
4. Добавь согласованные KPI, фильтры, рейтинги, поиск, интерактивные диаграммы и таблицу исходных записей.
5. Не используй backend.
6. Не используй внешние API.
7. Не загружай библиотеки из CDN.
8. Все необходимые библиотеки должны находиться внутри HTML.
9. Дашборд должен полноценно открываться и работать при отключённом интернете.
10. Не добавляй телеметрию, аналитику посещений и сетевые обращения.
11. Код организуй так, чтобы позднее можно было удалить демонстрационный массив и подключать реальный Excel локально.
12. Существующие обезличенные идентификаторы работников не меняй без необходимости.

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

Prompt 4. Локальная загрузка рабочей базы, сброс и офлайн-копия

Доработай существующий автономный HSE-дашборд.

Цель: после завершения разработки демонстрационные данные должны быть удалены из HTML, а реальная рабочая база должна подключаться только локально на компьютере пользователя.

Добавь следующие функции.

1. «Загрузить новую таблицу»
- пользователь выбирает Excel-файл на своём компьютере;
- файл читается только локально браузером;
- данные загружаются в оперативную память текущего сеанса;
- KPI, фильтры, графики, рейтинги и таблицы полностью перестраиваются;
- структура определяется по заголовкам столбцов, а не по фиксированным номерам колонок;
- при отсутствии обязательного поля выводится понятное сообщение об ошибке.

2. «Применить фильтры»
- пересчитать все визуализации по текущей выборке.

3. «Сбросить»
- очистить только выбранные фильтры;
- вернуть отображение всей загруженной базы;
- сами данные не удалять.

4. «Удалить все данные до нуля»
- полностью удалить загруженный рабочий массив из текущего состояния приложения;
- очистить KPI, диаграммы, рейтинги, таблицы, фамилии / идентификаторы и списки фильтров;
- вернуть HTML в состояние пустой программной оболочки.

5. «Выгрузить выбранные данные в Excel»
- экспортировать только текущую отфильтрованную выборку.

6. «Сохранить офлайн-копию»
- выполнять сохранение только после явного действия пользователя;
- если в копию встраивается текущая рабочая база, показать предупреждение, что сохранённый HTML содержит рабочие данные и должен храниться как конфиденциальный файл;
- никакая информация при сохранении не должна отправляться по сети.

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

Демонстрационный массив из финальной версии удали полностью.

Prompt 5. Зависимые фильтры, кликабельность и проваливание до записи

Доработай существующий HTML-дашборд, не переписывая его полностью.

Нужно:
1. Сделать фильтры зависимыми:
   предприятие → цех → участок / внутреннее подразделение.
2. После выбора предприятия оставлять только относящиеся к нему цеха.
3. После выбора цеха оставлять только его участки.
4. Учитывать выбранный период, проводящего ПДБ и его должность.
5. Сделать основные диаграммы и рейтинги кликабельными.
6. При клике на столбец, сектор, точку, строку рейтинга или работника применять соответствующую выборку ко всему дашборду.
7. Показывать исходные записи, которые сформировали выбранный показатель.
8. Добавить возможность вернуться на уровень выше или сбросить текущую детализацию.
9. Добавить поиск по работнику / обезличенному идентификатору.
10. Для выбранного работника показывать историю ПДБ за выбранный период: даты, подразделения, проводящих ПДБ, виды поведения, процессы и исходные записи.
11. Отдельно показать работников, у которых опасное поведение фиксировалось неоднократно.
12. Дать возможность увидеть повторение однотипного опасного поведения, даже если его фиксировали разные руководители или специалисты и на разных участках.
13. Экспортировать текущую выборку в Excel.
14. Не менять уже работающие функции без необходимости.

После доработки проведи регрессионную проверку:
- все фильтры;
- клики по диаграммам;
- поиск;
- детализацию;
- экспорт;
- возврат к полной выборке.

Prompt 6. ПДБ + фактический табель: выполнение установленной рекомендованной частоты

Добавь в существующий дашборд режим анализа ПДБ с учётом фактически отработанных смен.

Источники:
- выгрузка ПДБ из Collab;
- табель рабочего времени за тот же период.

На этапе разработки используй только обезличенный шаблон табеля. Реальный табель должен подключаться позже только локально.

ВАЖНО:
не придумывай норматив проведения ПДБ самостоятельно. Перед расчётом пользователь должен задать установленную рекомендованную частоту, например:
- X ПДБ на N фактически отработанных смен;
- X ПДБ за календарный / отчётный период;
- другое правило предприятия.

Логика:
1. Определи фактически отработанные смены по табелю.
2. Отпуск, больничный и другие неявки не считай фактически отработанными сменами.
3. Сопоставь массив ПДБ и табель по устойчивому идентификатору работника, предприятию, цеху, участку, профессии и периоду — в зависимости от доступных полей.
4. Не смешивай одинаковые фамилии / идентификаторы и профессии из разных подразделений.
5. На основании заданной пользователем частоты рассчитай ожидаемое количество ПДБ для фактически отработанного времени.
6. Покажи:
   - фактически отработанные смены;
   - установленную рекомендованную частоту;
   - фактическое количество ПДБ;
   - отклонение от рекомендуемой частоты;
   - процент выполнения;
   - подразделения и работников, где имеется отставание.
7. Добавь проваливание:
   предприятие → цех → участок → профессия → конкретный работник → его записи ПДБ.
8. Дай возможность выгрузить список работников / подразделений с отклонением.

Если структура табеля или правило частоты неоднозначны, сначала покажи спорные случаи и запроси подтверждение. Расчёт до подтверждения не выполняй.

Prompt 7. ККР + фактический табель: регулярность проведения и отклонения

Добавь в дашборд отдельный режим анализа контроля критических рисков (ККР).

Источники:
- выгрузка ККР из Collab;
- фактический табель рабочего времени за тот же период.

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

Логика:
1. Определи фактически отработанные смены каждого работника.
2. Отпуск, больничный и другие неявки не считай рабочими сменами.
3. Норматив / требуемую регулярность ККР не придумывай самостоятельно. Получи её от пользователя как параметр.
4. Если в конкретном процессе подтверждено требование «1 ККР на фактически отработанную смену», используй его только после подтверждения пользователя.
5. Сопоставь ККР с фактически отработанными сменами по устойчивому идентификатору, предприятию, цеху, участку, профессии, дате и/или смене.
6. Не смешивай одинаковые профессии и идентификаторы из разных подразделений.
7. Для каждого работника покажи:
   - фактически отработанные смены;
   - количество ККР;
   - смены / периоды, где ККР отсутствует относительно заданного правила;
   - отклонение;
   - процент выполнения.
8. Добавь проваливание:
   предприятие → цех → участок → профессия → работник → конкретная смена / конкретная запись ККР.
9. Дай возможность выгрузить список работников или смен с отклонением.
10. Если в выгрузке ККР имеются выявленные опасности, критические риски, описания отклонений или причины, дополнительно покажи:
   - повторяемость по участкам;
   - повторяемость по процессам;
   - повторяемость по работникам;
   - исходные записи по клику.

Если структура данных неоднозначна, сначала покажи правила сопоставления и спорные случаи. Не выполняй итоговый расчёт до подтверждения пользователя.

Prompt 8. Диагностика дефектов и техническая самопроверка

Проведи проверку существующего автономного HTML-дашборда.

Сначала не переписывай приложение целиком.

Если после последней доработки появилась ошибка:
1. Найди конкретную причину.
2. Исправь только необходимый участок.
3. Не удаляй и не переписывай уже работающие функции без причины.
4. После исправления проведи регрессионную проверку.

Обязательно проверь сценарии:
- открытие HTML без интернета;
- загрузка обезличенного тестового Excel;
- зависимые фильтры;
- клики и проваливание;
- поиск по работнику;
- экспорт выбранной выборки;
- сброс фильтров;
- полное удаление данных;
- повторная загрузка другой таблицы;
- сохранение офлайн-копии.

После функциональной проверки проведи аудит автономности и возможных каналов передачи / хранения:
- fetch;
- XMLHttpRequest;
- WebSocket;
- EventSource;
- sendBeacon;
- внешние script src;
- CDN;
- внешние CSS и шрифты;
- API;
- iframe;
- Service Worker;
- localStorage;
- sessionStorage;
- IndexedDB;
- cookies;
- телеметрия и аналитика.

Финальная версия должна:
- полноценно работать при отключённом интернете;
- не отправлять содержимое загружаемых Excel-файлов по сети;
- не сохранять рабочую базу скрыто без явного действия пользователя;
- при полном сбросе удалять рабочие данные из текущего состояния интерфейса.

В конце дай краткий отчёт:
1. что проверено;
2. какие дефекты найдены;
3. что исправлено;
4. какие ограничения или риски остаются.

Рекомендуемый порядок использования

1. Выполнить Prompt 1 и проверить, правильно ли ИИ понял структуру обезличенного Excel.
2. После подтверждения структуры выполнить Prompt 2.
3. Выполнить Prompt 3 и получить первую автономную HTML-версию.
4. По мере доработки использовать Prompt 5 для фильтров, кликов и проваливания.
5. Когда логика готова, выполнить Prompt 4: удалить демонстрационные данные и организовать локальную загрузку рабочей базы, сбросы, экспорт и офлайн-копию.
6. Если требуется анализ рекомендуемой частоты ПДБ, подключить Prompt 6.
7. Для ККР и сопоставления с фактическим табелем использовать Prompt 7.
8. После крупных изменений и перед публикацией / передачей пользователям выполнить Prompt 8.