Настоящее техническое задание определяет состав, границы, требования к созданию, внедрению, приёмке и сопровождению государственной цифровой платформы «My Better School» (МБШ), предназначенной для сквозного контроля школьного строительства, реконструкции, гарантийного сопровождения и общественного мониторинга объектов образования.

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

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

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

Границы разработки зафиксированы отдельно. Нативные мобильные приложения iOS/Android не входят в скоуп; полевые сценарии реализуются через адаптивный веб/PWA и Telegram MiniApp как веб-канал, вызываемый через Telegram-бот. Telegram не является источником юридической идентичности и не заменяет OneID, E-IMZO/eMZO, SMS-OTP или утверждённые государственные механизмы аутентификации и электронной подписи.

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

Обязательная интеграционная рамка включает «Замонавий мактаб» как источник справочных данных о школах, UN Quantum для закупочных и финансовых событий, SMS-шлюз, инфраструктуру электронной подписи, видеопотоки строительных площадок, а также будущие государственные интеграции. Для каждой школы требуется внутренний school_id и связка с национальным идентификатором/ИНН (STIR), позволяющая обеспечить сопоставимость данных при передаче платформы МДшО (Министерство дошкольного и школьного образования, англ. МДшО) и масштабировании.

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

Введение

Настоящее ТЗ подготовлено для разработки информационной системы в сфере государственного управления школьной инфраструктурой и общественного контроля. Документ предназначен для использования заказчиком, UNDP, МДшО, Uzinfocom, подрядчиком-разработчиком, органами контроля, членами приёмочных комиссий и аудиторами как единый источник требований к создаваемой системе.

Структура ТЗ ориентирована на O’z DSt 1987:2018 и дополнена практиками международной инженерии требований: каждое требование должно быть однозначным, проверяемым, согласованным с другими требованиями, трассируемым к процессу или нормативному основанию и пригодным для включения в приёмочные испытания.

Требования настоящего документа имеют приоритет перед предположениями подрядчика о типовой реализации коммерческих web/SaaS-продуктов. Там, где речь идёт об идентификации, подписи, хранении персональных данных, интеграции с государственными реестрами, журналировании и информационной безопасности, применяются режимы государственной информационной системы и законодательства Республики Узбекистан.

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

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

Методика контроля качества требований

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

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

Для каждого пользовательского сценария подрядчик обязан сформировать traceability matrix: сценарий → роль → объект данных → состояние объекта → интеграция → журнал аудита → критерий приёмки → тестовый сценарий. Отсутствие такой связи считается дефектом технического проекта.

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

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

1. Общие сведения

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

1.1. Полное наименование информационной системы и условное обозначение

Полное наименование: Цифровая платформа общественного и антикоррупционного контроля над школьным строительством «My Better School».

Условное обозначение: МБШ (рус.) / MBS (англ.).

Версия пилота: Pilot v1.0.

1.2. Заказчик, бенефициар, разработчик

Заказчик: Программа развития ООН (UNDP) — Узбекистанский страновой офис.

Бенефициар: Министерство дошкольного и школьного образования Республики Узбекистан (МДшО).

Соисполнители программы: Детский фонд ООН (UNICEF) — Узбекистанский страновой офис.

Разработчик информационной системы: определяется по итогам конкурсных торгов через UN Quantum.

1.3. Источники и порядок финансирования

Финансирование осуществляется в рамках совместной программы UNDP–UNICEF–МДшО «Modelling climate resilience and WASH in 45 schools» / Ishonch 2030 Fund. Закупочные процедуры на пилоте проводятся через UN Quantum. Порядок оплаты — поэтапный, по факту приёмки этапов, с удержанием 5% retention до окончания опытной эксплуатации.

1.4. Документы-основания

Project Document Joint Programme.
ToR контракта Business Analyst for Digital Public Oversight in School Construction.
Stage 1 AS-IS Analysis Report v1.7.
Stage 2 To-Be Concept Note v5.2.
Договорные требования к подрядчикам строительных работ от 18.06.2026.

Нормативные акты Республики Узбекистан:

Постановление Кабинета Министров № 43 от 10.12.2021 «Об утверждении Положения о порядке проведения государственной экспертизы проектно-сметной документации» (далее — ПК-43).

Постановление Кабинета Министров № 206 от 21.04.2022 «О порядке формирования и реализации инвестиционных программ по строительству, реконструкции и капитальному ремонту объектов социальной сферы» (далее — ПКМ-206).

Постановление Президента Республики Узбекистан № 241 от 11.05.2022 «О мерах по совершенствованию системы государственных закупок» (далее — ПК-241).

Постановление Кабинета Министров № 55 от 05.02.2021 «Об утверждении Положения о порядке проведения электронных тендерных торгов в строительстве» (далее — ПКМ-55, обеспечивает работу платформы Шаффоф).

Постановление Кабинета Министров № 4328 от 11.04.2019 «О дополнительных мерах по обеспечению информационной безопасности государственных информационных систем» (далее — ПКМ-4328, основа трёхэтапной экспертизы кибербезопасности).

Шаҳарсозлик нормалари ва қоидалари 3.01.04-19 (ШНК 3.01.04-19) — нормы и правила приёмки в эксплуатацию законченных строительством объектов.

Закон Республики Узбекистан № ЗРУ-547 «О персональных данных» (далее — ЗРУ-547).

Стандарт O‘z DSt 1987:2018 «Информационные системы. Техническое задание. Требования к содержанию и оформлению» — основа структуры настоящего ТЗ.

Международные стандарты и руководства:

Sphere Handbook 2018 — гуманитарные минимальные стандарты для WASH в школах.

WHO–UNICEF JMP (Joint Monitoring Programme) Service Ladders for WASH in Schools — индикаторы оценки.

UNICEF MHM Operational Guidance for Schools (2019) — стандарты менструальной гигиены.

UNICEF Three Star Approach (WinS) — система оценки школ по WASH.

UNICEF Child Safeguarding Policy — защита детей при работе с медиа.

UNICEF Climate Resilient WASH Technical Guidance — климатическая устойчивость WASH-инфраструктуры.

Open Contracting Data Standard (OCDS) — международный стандарт открытых данных о закупках.

Проектные документы программы Joint Programme:

Updated Final English Schools Engineering Assessment Report — отчёт инженерной команды UNDP+UNICEF по обследованию 100+ школ Кашкадарьинской и Сурхандарьинской областей (источник методологии Kobo для модуля M3, см. также Прил. П).

1.5. Плановые сроки

Точные плановые сроки определяются после выбора разработчика и подписания контракта. Ориентировочная продолжительность 16 месяцев с детализацией по фазам в разделе 5.

1.6. Порядок оформления и предъявления результатов

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

1.7. Интеллектуальная собственность и юридические условия

1.7.1. Права на исходный код

Исходный код всех компонентов платформы, разработанных подрядчиком в рамках настоящего контракта, передаётся заказчику (UNDP) в полном объёме с правом неограниченного использования.
Подрядчик гарантирует, что не использует в коде проприетарные библиотеки и компоненты, требующие отдельных лицензионных соглашений сверх стандартных Open Source лицензий.
При использовании Open Source компонентов — только с лицензиями, совместимыми с целями платформы (MIT, Apache 2.0, BSD). Использование GPL-лицензированных компонентов запрещено.
При завершении контракта подрядчик передаёт весь исходный код в репозитории UNDP, документацию по сборке и развёртыванию.

1.7.2. Code escrow

Для защиты от ситуации, когда подрядчик прекращает существование или отказывается от поддержки: - Подрядчик депонирует копию исходного кода и документации у нейтрального третьего лица (escrow agent) — например, юридической или ИТ-компании, согласованной заказчиком. - Депонирование обновляется каждые 6 месяцев. - Условия раскрытия escrow: банкротство подрядчика, прекращение деятельности, отказ от поддержки в нарушение контракта.

1.7.3. Передача прав МДшО

После завершения программы и handover: - UNDP передаёт МДшО неисключительные права на использование платформы. - МДшО получает право модифицировать, развивать, масштабировать платформу собственными силами или с привлечением других подрядчиков. - UNDP сохраняет за собой право использовать наработки в других проектах (в обезличенном виде, без специфики Республики Узбекистан).

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

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

1.7.5. Страхование

Подрядчик обеспечивает: - Страхование профессиональной ответственности (Professional Liability) на сумму не менее 500 000 USD. - Страхование гражданской ответственности (General Liability) на сумму не менее 200 000 USD. - Страхование от киберрисков (Cyber Insurance) на период разработки и гарантийной поддержки.

1.7.6. Конфиденциальность

Подрядчик обязуется не разглашать конфиденциальную информацию, полученную в процессе работы (данные пользователей платформы, финансовая информация программы, технические детали).
Сотрудники подрядчика подписывают индивидуальные NDA.
Срок обязательств по конфиденциальности — 10 лет после завершения контракта.

1.7.7. Применимое право и разрешение споров

Применимое право: законодательство Республики Узбекистан.
Споры разрешаются путём переговоров; при недостижении согласия — в международном арбитражном суде, согласованном UNDP.

2. Назначение и цели создания информационной системы

Этот раздел отвечает на ключевой вопрос: зачем создаётся платформа и какую конкретно проблему она решает. Без чёткого понимания назначения и целей подрядчик рискует реализовать систему, которая технически работает, но не достигает заявленных результатов программы. Раздел также формулирует десять архитектурных принципов проектирования, которым обязана соответствовать каждая функция платформы. Эти принципы не являются абстрактными декларациями — они переведены в конкретные технические требования в разделе 4 и в критерии приёмки в разделе 6. Подрядчик, реализующий функцию с нарушением принципа (например, добавляющий возможность удалить запись из журнала аудита) автоматически нарушает требования ТЗ, даже если конкретный запрет отсутствует в формулировках раздела 4.

2.1. Назначение информационной системы

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

Платформа позиционируется как целевая система антикоррупционного контроля, а не универсальный инструмент управления школьной инфраструктурой.

2.2. Цели создания информационной системы

Снижение коррупционных рисков в школьном строительстве через сквозную прозрачность всех процедур.
Повышение качества выполняемых работ через многоуровневый контроль.
Обеспечение участия граждан в надзоре через QR-канал.
Создание институциональной платформы, передаваемой государству (МДшО) после завершения пилота.
Обеспечение масштабируемости от 45 пилотных школ до 11 127 школ Республики без переписывания платформы.
Прослеживаемость пятилетних гарантийных обязательств подрядчиков.
Сокращение бумажного документооборота и параллельных Excel-запросов.

2.3. Принципы проектирования системы

2.3.1. Назначение платформы

2.3.2. Принципы проектирования (обязательны к реализации)

Принцип «доверие через след». Любое действие, влияющее на освоение средств, оставляет след в системе: событие, инициатор, время, обоснование, доказательство. Удаление событий запрещено технически.
Принцип единственного источника правды. Для каждой сущности (школа, контракт, этап, выплата, акт, гарантия) определён единственный источник данных. Дубликаты невозможны.
Принцип одновременной видимости уровней. Сигнал о проблеме виден одновременно на всех уровнях управления: школа, район, область, министерство, заказчик, общественность. Скрытие, снятие с контроля или закрытие сигнала без зарегистрированного решения и аудита технически не допускается.
Принцип «деньги идут за подтверждением». Каждая выплата подрядчику привязана к подтверждённому акту, акт — к загруженным доказательствам, доказательства — к чек-листу этапа. Бесследная оплата невозможна.
Принцип конфигурируемости без релизов. Справочники работ, ролей, этапов, регионов, организаций, источников финансирования — все настраиваются администратором без программных изменений.
Принцип наименьших полномочий. Каждая роль видит только то, что необходимо для её функций. По умолчанию доступ запрещён.
Принцип «доказательство перед подписью». Электронная подпись акта возможна только после загрузки полного пакета доказательств и подтверждения всех пунктов чек-листа.
Принцип явной приоритизации. Каждое обращение, заявка, инцидент автоматически классифицируется по матрице «срочно/важно». Маршрутизация и SLA — по приоритету.
Принцип сохранения мандата. Платформа не вмешивается в полномочия государственных институтов. Действия ГАСН, КРУ, прокуратуры, хокимиятов отражаются в системе, но не подменяются ею.
Принцип масштабируемости от пилота к стране. Все механизмы изначально спроектированы для работы с 45 школами пилота и для масштабирования на 11 127 школ Республики без переписывания платформы.

2.3.3. Границы скоупа платформы

INSIDE (платформа делает)

Прозрачность тендеров и контрактов (источник на пилоте — UN Quantum)
Управление этапами работ, фотоотчётами, видеомониторингом
Электронная приёмка с цифровыми подписями (электронная Далолатнома)
Канал общественной обратной связи через QR/web + фото; SMS-OTP только для формального обращения и трекинга
Регистрация и сопровождение 5-летних гарантийных обязательств
Журнал аудита всех значимых действий
Дашборды для всех уровней управления
Публичный портал

OUTSIDE (платформа НЕ делает; внешние системы)

Закупочные процедуры на самой платформе — выполняются в UN Quantum, мы только отображаем
Государственная экспертиза ПСД — выполняется уполномоченным органом, мы фиксируем заключение
Финансовые операции (фактические выплаты) — выполняются UNDP финансовым блоком в UN Quantum, мы фиксируем факт оплаты
Идентификация граждан не является обязательной для первичного сигнала; для формального обращения используется SMS-OTP без паспортной идентификации
Учёт зарплат педагогов, успеваемости учеников — не наш скоуп
Управление документооборотом МДшО — eXudjat

3. Характеристика объекта информатизации

Этот раздел описывает то, что собственно автоматизируется — реальный процесс школьного строительства в Республике Узбекистан, его участников, текущее состояние, границы автоматизации и сквозные бизнес-процессы. Цель раздела — погрузить подрядчика-разработчика в предметную область настолько, чтобы он мог проектировать систему, понимая контекст её применения, а не как абстрактный набор экранов и кнопок. Текущее состояние процесса (AS-IS) детально описано в отдельном отчёте Stage 1 AS-IS Analysis Report v1.7; настоящий раздел даёт его сжатое представление, акцентируя те элементы, которые непосредственно влияют на проектные решения. Подраздел 3.5 устанавливает границы скоупа — что платформа делает (INSIDE) и что не делает (OUTSIDE). Этот рамочный принцип строго обязателен: добавление в платформу функций из списка OUTSIDE является изменением скоупа и требует подписания дополнительного соглашения с пересмотром цены. Подраздел 3.6 содержит описание восьми сквозных бизнес-процессов — от отбора школы до пятилетнего постгарантийного обслуживания. Каждый бизнес-процесс описан с указанием действующих лиц, последовательности шагов, бизнес-правил, выходных артефактов и исключений; реализация каждого процесса в платформе — отдельный предмет приёмки.

3.1. Объект автоматизации

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

3.2. Уровни управления

Республиканский (МДшО, Минфин, ACA, UNDP, UNICEF).
Областной (хокимияты, областные управления МДшО, инжкомпании при облхокимиятах).
Районный (РУНО).
Школьный (директор, хозяйственная часть).

3.3. Заинтересованные стороны

Государственные институты, администрация школ, подрядчики и поставщики, проектные организации, технический надзор, включая при необходимости внешнюю организацию строительного контроля, надзорные органы (ГАСН, КРУ), гражданское общество (CSAC, НКО), махалли и родительские комитеты, доноры (UNDP, UNICEF).

3.4. Текущее состояние

Текущее состояние подробно описано в отчёте Stage 1 AS-IS Analysis Report v1.7. Ключевые выявленные проблемы перечислены в разделе 2.1 Stage 1.

3.5. Границы скоупа платформы

3.5.1. INSIDE (что платформа делает)

Прозрачность тендеров и контрактов (источник на пилоте — UN Quantum).
Управление этапами работ, фотоотчётами, видеомониторингом.
Электронная приёмка с цифровыми подписями (электронная Далолатнома по ШНК 3.01.04-19).
Канал общественной обратной связи через QR/web + фото; SMS-OTP только для формального обращения и трекинга.
Регистрация и сопровождение пятилетних гарантийных обязательств.
Журнал аудита всех значимых действий.
Дашборды для всех уровней управления.
Публичный портал.

3.5.2. OUTSIDE (что платформа НЕ делает)

Закупочные процедуры выполняются в UN Quantum, не на платформе.
Государственная экспертиза ПСД — внешний процесс, платформа фиксирует заключение.
Финансовые операции выполняются финансовым блоком UNDP в UN Quantum.
Паспортная идентификация граждан не применяется; открытые сигналы принимаются без обязательной аутентификации, формальные обращения подтверждаются SMS-OTP.
Учёт зарплат, успеваемости — не входит в скоуп.
Документооборот МДшО — ведётся в eXudjat.

3.6. Сквозные бизнес-процессы

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

БП-1. Отбор школы и фиксация в реестре программы

Назначение процесса в архитектуре платформы. Это — входная точка для каждой школы в платформе МБШ. До прохождения этого процесса школа не существует в системе как объект программы, и никакие другие процессы по ней невозможны. Качественное выполнение БП-1 — основа для всей последующей работы: если на этом этапе попадают в систему школы с неполными или искажёнными данными, ошибки распространяются на все восемь процессов.

Конкретный пример. Жасур Курбанов, региональный координатор UNDP по Кашкадарье, получил от центрального офиса задание включить в программу 2027 года 18 школ Кашкадарьинской области. Из 100 школ области, обследованных инженерной командой, нужно отобрать те, где состояние инфраструктуры наиболее критическое, а финансирование укладывается в выделенный лимит 8 миллионов USD. Жасур импортирует паспорта 100 школ из Замонавий мактаб, проверяет валидированные оценки KoboToolbox (далее — Kobo) по каждой, видит распределение скоринга (от 42 до 89 баллов). По правилу «начинать с управляемого» отсеивает крупные многоэтажные школы. Симулирует три варианта программы (UC-A06), обсуждает с заместителем хокима. После двух недель переговоров финальный список из 18 школ зафиксирован в платформе.

Триггер: Решение программы Joint Programme включить школу в когорту года N.

Действующие лица: Координатор программы UNDP, инженерная команда UNDP+UNICEF, региональные координаторы UNDP, представители МДшО областных управлений.

Предусловие: Школа существует в реестре Замонавий мактаб (Uzinfocom School Passport), имеет уникальный национальный идентификатор.

Последовательность: 1. Координатор программы импортирует базовый паспорт школы из Замонавий мактаб по идентификатору (Узинфоком, ручная выгрузка Excel на пилоте, API на этапе масштабирования). 2. Инженерная команда проводит обследование школы по форме KoboToolbox — 122 параметра в восьми группах данных (общие — 29 полей, отопление — 8, электроснабжение — 14, конструктив здания — 15, текущее WASH — 14, планируемое WASH — 12, фотофиксация внутри здания — 11, фотофиксация снаружи и территории — 19). 3. Координатор импортирует оценку из Kobo в платформу (CSV/JSON), система автоматически рассчитывает 100-балльный скоринг по 8 критериям с заданными весами. 4. Координатор отмечает школу как «отобрана для программы года N», указывает источник финансирования (Joint Programme / Bridge / Capital Construction). 5. Решение об отборе фиксируется событием с привязкой к решению Президиума Кабинета Министров (если требуется по нормативу) — поле «основание включения».

Бизнес-правила: - БП-1.1. Школу нельзя включить в когорту года, если её паспорт не выгружен из Замонавий мактаб. - БП-1.2. Школу нельзя включить, если оценка Kobo не загружена в полном объёме (все 8 групп данных). - БП-1.3. При повторном включении школы в когорту следующего года скоринг пересчитывается на новых данных. - БП-1.4. Изменение источника финансирования после старта работ — только через утверждённое решение с подписью координатора программы и записью в журнал аудита.

Выходные артефакты: - Запись «school_program_inclusion» с полями: school_id, program_year, kobo_assessment_id, score, decision_reference, included_by, included_at.

Исключения: - Школа не найдена в Замонавий мактаб — блокирующее: запросить регистрацию в Узинфоком. - Оценка Kobo неполная — предупреждение: можно зарегистрировать как «черновик», но запрещён переход к следующему процессу (тендер ПСД). - Скоринг ниже порогового значения, но школа включена «по обоснованному решению» — обязателен текст обоснования и подпись координатора программы.

БП-2. Тендер на проектно-сметную документацию (ПСД)

Назначение процесса в архитектуре платформы. ПСД — это техническая основа всех последующих работ по школе. Без качественной ПСД невозможно объявить тендеры на работы (БП-4), невозможно провести государственную экспертизу (БП-3), невозможно гарантировать качество финальной приёмки (БП-6). Поэтому тендер на ПСД — не формальность, а критический процесс отбора компетентного исполнителя проектирования.

Конкретный пример. По 18 школам программы 2027 года Кашкадарьинской области требуется разработать комплексные проекты реновации. Менеджер по закупкам UNDP Бахит объявляет в UN Quantum тендер на ПСД для группы из 6 школ (компактно расположены в Камашинском и Гузарском районах, оптимально для одного проектировщика). Бюджет тендера — 380 000 USD. Подают заявки 4 проектные организации из Ташкента, Самарканда, Карши. Платформа МБШ автоматически отражает процедуру в публичной витрине. Через 30 дней закрытие тендера, побеждает ООО «КаршиПроект» с ценой 342 000 USD и сроком 4 месяца. Контракт автоматически регистрируется в МБШ (UC-A11).

Триггер: Школа включена в когорту года N (БП-1 завершён).

Действующие лица: Менеджер по закупкам UNDP CO, координатор программы, проектные организации (потенциальные участники).

Предусловие: Согласован пакет ТЗ на ПСД, утверждён бюджет, открыт тендер в UN Quantum.

Последовательность: 1. Менеджер по закупкам создаёт тендер на ПСД в UN Quantum. 2. Платформа МБШ через интеграцию (см. И-1) автоматически создаёт запись «procurement_event» с типом «PSD_TENDER», привязкой к school_id и program_year. 3. Платформа отображает тендер в публичной витрине: предмет, школы (одна или группа), сроки подачи, бюджет (если раскрыт), ссылка на UN Quantum. 4. После окончания приёма предложений UN Quantum возвращает в платформу состав участников, протокол оценки, победителя, цену контракта. 5. Платформа создаёт запись «contract» типа «PSD», привязывает к school_id, заполняет атрибуты контракта (стороны, предмет, цена, сроки, этапы выплат).

Бизнес-правила: - БП-2.1. Тендер не может быть закрыт без победителя или без аргументированного отказа. - БП-2.2. Если победитель определён, но контракт не подписан в течение N дней — автоматическое уведомление координатору программы. - БП-2.3. Цена контракта не может превышать утверждённый бюджет более чем на 0%. - БП-2.4. Изменение цены контракта после подписания — только через дополнительное соглашение, регистрируется как отдельная запись.

Выходные артефакты: - procurement_event (PSD_TENDER) — статусы: «open», «closed_with_winner», «closed_without_winner». - contract (PSD) — статусы: «draft», «signed», «in_progress», «closed», «terminated».

Исключения: - Тендер закрыт без победителя — координатор обязан отметить причину и инициировать повторный тендер. - UN Quantum не отвечает на API — деградация: запись остаётся в статусе «pending_sync», ручной ввод координатором с обязательным комментарием.

БП-3. Подготовка ПСД и государственная экспертиза

Назначение процесса в архитектуре платформы. Это самый длительный из подготовительных процессов. ПСД готовится 3–5 месяцев, государственная экспертиза занимает ещё 1–2 месяца. От качества прохождения этого процесса зависит, насколько реалистичными окажутся объёмы и сроки работ на следующих этапах. Платформа не подменяет процесс проектирования, но фиксирует все ключевые точки — что критично для дальнейшей трассируемости и аудита.

Конкретный пример. ООО «КаршиПроект» приступает к работам по ПСД для 6 школ Камашинского и Гузарского районов. Команда из 5 инженеров и архитекторов проводит полевые обследования (выезжают на каждую школу, делают замеры, фотофиксацию), затем 2 месяца разрабатывает рабочие чертежи. Платформа МБШ ведёт учёт хода работ: загружаются результаты обследования, эскизный проект, рабочая документация. По одной из школ обнаружена скрытая трещина в фундаменте, которая не была видна на первичной оценке — проектировщики предлагают усиление, которое не было заложено в смету. Это фиксируется как замечание в платформе, обсуждается с UNDP, утверждается изменение проекта. Через 4 месяца пакет ПСД по 6 школам передан на государственную экспертизу. Экспертиза возвращает 3 замечания (мелкие технические уточнения), они устраняются за 2 недели. Финальное положительное заключение фиксируется в платформе как условие перехода к БП-4.

Триггер: Контракт PSD подписан, статус «in_progress».

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

Последовательность: 1. Проектная организация создаёт в платформе план работы по этапам (типовые этапы конфигурируются в справочнике): обследование объекта, разработка эскизного проекта, разработка рабочей документации, согласование с госорганами, передача на госэкспертизу. 2. По каждому этапу — загрузка результирующих документов (чертежи, спецификации, сметы) в формате PDF и в редактируемом формате (DWG/REVIT/IFC). 3. После завершения проектирования организация инициирует передачу пакета на госэкспертизу: указывает уполномоченный орган и дату подачи. 4. Госэкспертиза возвращает заключение (положительное / с замечаниями / отрицательное). Заключение загружается в платформу как документ + структурированные поля (номер, дата, статус, перечень замечаний). 5. При замечаниях — итерация: внесение правок, повторная подача. Каждая итерация — отдельное событие. 6. Финальное положительное заключение фиксируется как условие перехода к БП-4.

Бизнес-правила: - БП-3.1. Платформа не подменяет госэкспертизу. Заключение вводится как внешний документ. - БП-3.2. Без положительного заключения госэкспертизы тендер на работы (БП-4) не может быть открыт. Блокировка системная. - БП-3.3. Изменение проектных решений после госэкспертизы возможно, но требует уведомления заказчика и при необходимости — повторной экспертизы.

Выходные артефакты: - contract_milestone (PSD) — с прикреплёнными документами. - expertise_decision — структурированная запись о заключении. - design_package — комплект проектной документации, доступный другим участникам процесса.

БП-4. Параллельные тендеры на пакеты работ

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

Конкретный пример. Для школы №18 Камашинского района утверждена ПСД. Менеджер по закупкам Бахит объявляет в UN Quantum четыре параллельных тендера: общестрой (бюджет 450 000 USD), тепловые насосы (бюджет 280 000 USD), септик с полем фильтрации (бюджет 120 000 USD), поставка гигиенических материалов (бюджет 35 000 USD). Тендеры запускаются с интервалом в 2 недели, чтобы не перегрузить рынок. Подают заявки разные компании: на общестрой — 5 строительных компаний области, на тепловые насосы — 2 производителя оборудования из Узбекистана и 1 импортёр, на септик — производитель из Ташкента, на материалы — 3 поставщика. По итогам тендеров выигрывают 4 разные компании. Подписываются 4 параллельных контракта. Платформа МБШ автоматически создаёт календарно-сетевой график, согласующий работы 4 подрядчиков на одной площадке: общестрой начинает первым с подготовительных работ, к моменту демонтажа котельной подключается подрядчик теплонасосов, септик ставится параллельно с укладкой коммуникаций, материалы поставляются к моменту сдачи. Координатор UNDP контролирует общую последовательность.

Триггер: Положительное заключение госэкспертизы по школе (БП-3 завершён).

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

Принципиальная модель: Реновация одной школы — несколько параллельных контрактов. Каждый пакет работ — самостоятельный тендер в UN Quantum.

Типовые пакеты работ (конфигурируются в справочнике): 1. Общестроительные работы (утепление стен, крыши, замена окон, дверей, полов). 2. Тепловые насосы и система отопления (производитель оборудования = подрядчик монтажа). 3. Локальная очистная система канализации — септик с полем фильтрации (производитель = монтажник). 4. Поставка гигиенических материалов (мыло, бумага, оборудование handwashing).

Последовательность для каждого пакета: 1. Менеджер по закупкам создаёт тендер пакета в UN Quantum с привязкой к school_id и work_package_type. 2. Платформа МБШ создаёт procurement_event типа «WORK_TENDER» с подтипом пакета. 3. Тендеры по разным пакетам одной школы могут проводиться параллельно или последовательно. 4. После определения победителя по каждому пакету — отдельный контракт. 5. Каждый контракт получает в платформе свой набор этапов работ из справочника типовых этапов соответствующего пакета.

Бизнес-правила: - БП-4.1. На одной школе одновременно могут быть активны до N параллельных контрактов (N — без жёсткого ограничения, проверка только конфликтов по расписанию работ). - БП-4.2. Контракты разных пакетов не могут конфликтовать по площадке — координатор обеспечивает координацию через календарно-сетевой график. - БП-4.3. Для пакетов «Тепловые насосы» и «Септик» подрядчиком обязательно является производитель оборудования или его уполномоченный представитель. - БП-4.4. Контракт пакета «Поставка материалов» отличается отсутствием стадии «выполнение работ» — только поставка и приёмка.

БП-5. Выполнение работ по контракту с поэтапной приёмкой и привязкой выплат

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

Конкретный пример. Подрядчик ООО «СтройМонтажТермез» приступает к общестрою школы №15 Ангорского района. Работы рассчитаны на 4 месяца. Первый этап — подготовительные работы (3 недели). Прораб Жасур ежедневно загружает 5–7 фотоотчётов (UC-A15), делает еженедельные видеообзоры площадки (UC-A16). Технадзор Шухрат еженедельно просматривает материалы дистанционно (UC-A34), приезжает на физический осмотр раз в 2 недели. По завершении первого этапа Жасур подаёт его на верификацию (UC-A17). Шухрат проверяет чек-лист из 7 пунктов (UC-A18), находит нарушение хранения материалов, возвращает на доработку, через день принимает. Этапный акт подписывается (UC-A19) — выплата 11 400 USD проводится через UN Quantum (UC-A24). С удержанием 5% retention (600 USD). Цикл повторяется для каждого из последующих 7 этапов общестроя. К моменту завершения общестроя параллельно работают подрядчики по теплонасосам и септику — координация через платформу обеспечивает, что работы не мешают друг другу.

Триггер: Контракт работ подписан, статус «in_progress».

Действующие лица: Подрядчик, технический надзор инжкомпании при облхокимияте, внешний контролёр строительного контроля (если назначен), инспектор ГАСН, координатор программы UNDP, директор школы.

Принципиальный поток (повторяется по каждому этапу работ):

Шаг 5.1. Подрядчик начинает работы по этапу

Подрядчик в личном кабинете отмечает «начало этапа», прикладывает стартовый фото- и видеоотчёт (фото с геометками и временной меткой, видеоконтур площадки до начала работ).
Система валидирует: геометки в пределах радиуса 50 м от паспорта школы; временная метка — дата начала этапа ± 24 часа.
Создаётся запись «work_stage_started».

Шаг 5.2. Подрядчик ведёт работы и ежедневно подаёт фотоотчёты

Ежедневно в рабочие дни подрядчик загружает не менее 5 фотографий с геометками: начало рабочего дня, ключевые операции, конец рабочего дня. Каждое фото — отдельная запись «daily_evidence».
Платформа автоматически проверяет: геометка в пределах площадки, временная метка соответствует дате загрузки, файл не повторяется (MD5/perceptual hash).
В случае несоответствия — запись помечается флагом, требует объяснения подрядчика.

Шаг 5.3. Подрядчик ведёт видеомониторинг

Камера на площадке (модель MikroTik + WireGuard, см. И-3) ведёт непрерывную трансляцию.
Платформа фиксирует доступность потока: «up» / «down» / «degraded», агрегирует по часам и суткам.
Простой потока более 4 часов в сутки — генерация события «video_outage_alert», передача координатору программы.

Шаг 5.4. Подрядчик завершает этап

Подрядчик отмечает «этап завершён», прикрепляет финальный фотоотчёт по чек-листу этапа (см. справочник чек-листов).
Каждый пункт чек-листа должен быть подтверждён минимум одной фотографией с геометкой и комментарием.
Платформа создаёт «work_stage_completion_request» и направляет на верификацию техническому надзору.

Шаг 5.5. Технический надзор верифицирует этап

Технадзор просматривает фотоотчёт и видеозаписи по этапу.
Технадзор подтверждает или отклоняет каждый пункт чек-листа отдельно. Отказ — с обязательным комментарием.

Если внешняя организация строительного контроля назначена по программе или контракту, роль EXTERNAL_CONSTRUCTION_CONTROLLER получает доступ к очереди этапов, срокам, отставаниям, фото/GPS-доказательствам, видеопотоку и SLA; может оставлять замечания, флаги риска и рекомендации для технадзора/координатора, но не переводит этап в verified и не подписывает акт вместо уполномоченных сторон, если такое право отдельно не задано маршрутом процесса.

Если все пункты подтверждены — этап получает статус «verified», запускается формирование акта приёмки этапа.
Если есть отказы — статус «rework_required», подрядчик дорабатывает и подаёт повторно.

Шаг 5.6. Формирование и подписание акта приёмки этапа

Платформа автоматически генерирует электронный акт приёмки этапа по шаблону Далолатнома по ШНК 3.01.04-19.
Акт подписывается: подрядчик, технадзор, координатор программы. При значимых этапах (фундамент, коробка, инженерные системы) — дополнительно инспектор ГАСН.
Каждая подпись фиксирует время и геолокацию подписывающего лица.

Шаг 5.7. Привязка выплаты к подписанному акту

После подписания акта платформа автоматически генерирует запись «payment_due» с привязкой к контракту, этапу, акту.
Запись передаётся в UN Quantum (через интеграцию И-1) как уведомление о готовности к оплате.
Финансовый блок UNDP осуществляет фактический платёж в UN Quantum.
UN Quantum возвращает в платформу подтверждение оплаты с реквизитами.

Бизнес-правила: - БП-5.1. Выплата по этапу возможна только при подписанном акте этапа в платформе. Внесистемная выплата — нарушение. - БП-5.2. Просрочка загрузки ежедневного фотоотчёта более 2 рабочих дней — основание для приостановки выплаты по текущему этапу. - БП-5.3. Простой видеопотока более 4 часов в сутки — основание для штрафа (фиксируется в реестре штрафов). - БП-5.4. Подрядчик не может «закрыть этап» без полного чек-листа. - БП-5.5. Технадзор не может «одобрить этап» без проверки каждого пункта чек-листа. - БП-5.6. Координатор программы не может подписать акт раньше технадзора.

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

Шаг 5.8. Реакция на отклонения и инциденты

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

БП-6. Финальная приёмка объекта и ввод в эксплуатацию

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

Конкретный пример. Школа №15 Ангорского района прошла все этапы по всем 4 контрактам. Координатор программы UNDP Дарья инициирует финальную приёмку (UC-A23). Платформа автоматически формирует pre-acceptance dossier объёмом около 300 страниц с гиперссылками на все материалы (фото, видео, акты, протоколы). 28 июня 2026 года в 10:00 многоведомственная комиссия — Дарья (председатель), 2 представителя UNDP, представитель UNICEF, представитель центрального МДшО, инспектор ГАСН, аудитор КРУ, заместитель хокима района, директор школы Анвар, представители 4 подрядчиков, представитель махалли — собирается у школы. Через адаптивный веб/PWA или Telegram MiniApp каждый член комиссии регистрирует прибытие; фиксируются геолокация, время и идентификатор сессии платформы. Комиссия физически обходит школу, проверяет 35 пунктов финального чек-листа. К 13:00 проверки завершены: 33 пункта подтверждены, 2 пункта с мелкими замечаниями (незакрашенный участок стены, неработающий смеситель). Председатель инициирует подписание электронной Далолатнома. Все 13 членов комиссии инициируют подписание на месте через адаптивный веб/PWA или Telegram MiniApp; юридически значимая подпись выполняется через E-IMZO/eMZO или иной согласованный государственный механизм ЭЦП, а геолокация фиксируется как доказательный атрибут присутствия. К 14:30 все подписи получены. Школа автоматически переводится в статус «commissioned», запускается отсчёт 5-летнего гарантийного срока до 28.06.2031.

Триггер: Все этапы всех контрактов по школе подписаны и оплачены.

Действующие лица: Многоведомственная комиссия — заказчик (UNDP), бенефициар (МДшО), подрядчики, технический надзор, ГАСН, КРУ, представители района, директор школы.

Последовательность: 1. Координатор программы инициирует процедуру финальной приёмки в платформе. 2. Платформа агрегирует все этапные акты, видеоархив, фотоотчёты, заключения экспертиз, замечания, реакции — в единый «pre-acceptance dossier». 3. Назначается дата выезда комиссии, состав подтверждается. 4. На выезде члены комиссии проходят чек-лист финальной приёмки — с подтверждением каждого пункта в платформе через Telegram MiniApp или адаптивный веб-интерфейс. 5. По итогам — формирование электронной Далолатномы и юридически значимое подписание всеми членами комиссии через E-IMZO/eMZO или иной согласованный государственный механизм ЭЦП; геолокация и время фиксируются как доказательные атрибуты. 6. Школа переводится в статус «commissioned». Запускается отсчёт 5-летнего гарантийного срока. 7. По всем контрактам инициируется процесс закрытия и выплата удержанных средств (retention).

Бизнес-правила: - БП-6.1. Финальный акт не может быть подписан, если по школе остались неподписанные этапные акты. - БП-6.2. При выявлении замечаний на финальной приёмке — отдельный реестр замечаний с указанием ответственного подрядчика и срока устранения. - БП-6.3. До устранения критических замечаний школа не переводится в «commissioned».

БП-7. Закрытие контрактов и постаудит

Назначение процесса в архитектуре платформы. Это завершение финансовой стороны контрактов и независимая внешняя проверка качества выполнения. Процесс закрывает «короткую дугу» (выплата retention) и запускает «длинную дугу» (постаудит КРУ через 6 месяцев — независимая проверка после периода эксплуатации). Корректное выполнение БП-7 защищает заказчика от ситуации «деньги выплачены, школа разваливается через год».

Конкретный пример. После финальной приёмки школы №15 (БП-6) все 4 контракта переходят в стадию закрытия. По каждому из 4 контрактов: 1. Через 60 дней (28.08.2026) координатор подтверждает устранение двух замечаний приёмки, инициирует возврат retention. По общестрою — 60 000 USD ООО «СтройМонтажТермез», по теплонасосам — 14 000 USD ООО «СамаркандЭнергоСистем», по септику — 6 000 USD ООО «АкваСистем», по материалам — 1 750 USD поставщику. UN Quantum проводит платежи. 2. Контракты переводятся в статус «closed». 3. Через 6 месяцев после приёмки (28.12.2026) платформа автоматически генерирует KRU_audit_request — приходит время постаудита КРУ. Аудитор КРУ Илхом изучает материалы (UC-A42), выезжает на школу с группой, проверяет качество выполненных работ через полгода эксплуатации, оформляет независимое заключение. Заключение положительное по 3 контрактам, по контракту общестроя — замечание о необходимости подкраски пола в одной из учебных комнат. Подрядчик устраняет замечание в рамках гарантии за свой счёт.

Триггер: Школа в статусе «commissioned».

Действующие лица: Финансовый блок UNDP, подрядчики, КРУ.

Последовательность: 1. По каждому контракту — выплата удержанной суммы (retention 5%) при отсутствии критических замечаний. 2. Контракты переводятся в статус «closed». 3. Через 6 месяцев — постаудит КРУ. Платформа автоматически генерирует «KRU_audit_request» с пакетом материалов: все акты, выплаты, фото, видео, журнал аудита. 4. КРУ возвращает заключение, оно фиксируется в платформе.

БП-8. 5-летняя гарантия и постгарантийное сопровождение

Назначение процесса в архитектуре платформы. Это самая длительная часть жизненного цикла — пять лет, в течение которых подрядчики несут гарантийные обязательства. Раньше эти обязательства массово терялись — акты приёмки уходили в бумажный архив, гарантийные случаи решались неформально через хокимият. Без БП-8 платформа теряла бы значительную часть своей долгосрочной ценности. С БП-8 каждое обращение, поступившее за 5 лет, автоматически проверяется на принадлежность к гарантийному случаю и при положительной проверке маршрутизируется подрядчику-гаранту.

Конкретный пример. Школа №15 в статусе «in_warranty» с 28.06.2026 до 28.06.2031. За первый год гарантии поступают 3 обращения через QR-канал: протечка радиатора (UC-A38 — гарантийный случай, маршрутизирован подрядчику ООО «СамаркандЭнергоСистем»), скрипящая дверь в спортзале (не подпадает под гарантию — обычное обслуживание), трещина в наружной стене после землетрясения (форс-мажор, не гарантийный случай). Подрядчики реагируют в SLA по тем случаям, которые относятся к их работам. Дополнительно в сентябре 2026 года ООО «СамаркандЭнергоСистем» проводит обязательное сезонное обслуживание теплового насоса (UC-A40) перед отопительным сезоном. За пять лет накапливается история всех событий: 15 гарантийных случаев устранено, 5 сезонных ТО проведено, общая статистика по школе и подрядчикам. 28 июня 2031 года автоматически завершается гарантия (UC-A41), формируется финальный отчёт, школа переходит в режим обычной эксплуатации.

Триггер: Школа в статусе «commissioned», начат отсчёт гарантийного срока.

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

Последовательность: 1. Платформа ведёт реестр гарантий по каждому контракту: дата начала, срок, ответственный подрядчик, контактное лицо, предмет гарантии. 2. Любая заявка/жалоба по объекту от пользователей платформы (директор, родители, махалля) автоматически проверяется на пересечение с гарантийными обязательствами. 3. Если заявка относится к гарантийному случаю — автоматическая маршрутизация подрядчику с фиксацией SLA по типу дефекта. 4. Подрядчик обязан подтвердить получение заявки в течение 24 часов, выехать в SLA-сроки, устранить дефект, отчитаться с фото и подписью школьной администрации. 5. Невыполнение SLA — автоматическое начисление штрафа, эскалация координатору программы, при систематических нарушениях — внесение в чёрный список.

Бизнес-правила: - БП-8.1. Гарантия сохраняется при реорганизации подрядчика; обязанность уведомления — на подрядчике. - БП-8.2. Сезонное обслуживание (где предусмотрено контрактом — котельные, насосы, септики) — ежегодный отчёт подрядчика в платформу. - БП-8.3. По истечении 5 лет гарантия закрывается, объект переходит в режим обычной эксплуатации.

4. Требования к информационной системе

Настоящий раздел — центральный и самый объёмный раздел ТЗ, в котором изложены все требования к создаваемой системе. Раздел разделён на три крупных подраздела согласно стандарту O’z DSt 1987:2018:

4.1 Требования к информационной системе в целом — общесистемные требования, не относящиеся к конкретному модулю: архитектура, режимы функционирования, взаимодействие с внешними системами, надёжность, безопасность, удобство использования, лицензионная чистота, защита данных и расширенный перечень нефункциональных требований.
4.2 Требования к функциям и задачам — описание ролевой модели платформы (всех 27 категорий пользователей), сквозных пользовательских сценариев и детальной функциональности каждого из 20 модулей с указанием бизнес-правил, состояний, точек интеграции и критериев приёмки.
4.3 Требования к видам обеспечения — требования к восьми видам обеспечения по стандарту: математическое (алгоритмы скоринга, приоритизации, прогнозирования), информационное (модель данных), лингвистическое (многоязычность), программное (стек, контейнеризация, CI/CD), техническое (расчёт серверной инфраструктуры), метрологическое (точность геокоординат и временных меток), организационное (регламенты эксплуатации), методическое (учебные материалы).

Подрядчик обязан реализовать все требования настоящего раздела в полном объёме. Невыполнение даже одного требования без зарегистрированного согласования с заказчиком является основанием для приостановки соответствующего этапа работ. Отсутствие в разделе явной формулировки конкретного требования не освобождает подрядчика от обязанности реализовать функциональность, без которой описанные сценарии или модули не могут работать. Например, если ТЗ не упоминает экран «список школ с фильтрами», но описывает использование «карты школ» (модуль M2, подраздел 4.2.3) и сквозной сценарий поиска школы (Приложение А), то наличие соответствующего интерфейса является обязательным.

4.1. Требования к информационной системе в целом

4.1.1. Требования к структуре и функционированию

4.1.1.1. Перечень модулей

Платформа состоит из 19 функциональных модулей. Детальное описание каждого приведено в подразделе 4.2.

ID	Наименование
M1	Управление пользователями и организациями
M2	Паспорт школы и реестр объектов
M3	Оценка и скоринг (модель KoboToolbox)
M4	Планирование программ реновации
M5	Тендеры и контракты (интеграция с UN Quantum)
M6	Видеомониторинг строительных площадок
M7	Управление контрактами и выплатами
M8	Прогресс работ и календарно-сетевые графики
M9	Доказательная база
M10	Адаптивный веб и Telegram MiniApp для полевых сценариев
M11	Канал общественной обратной связи (QR/web; открытый сигнал + SMS-OTP для формального обращения)
M12	Верификация, инспекция и утверждение
M13	Дефекты, гарантия и постпроектный мониторинг
M14	Дашборды и аналитика
M15	Открытые данные и API
M16	Integrity Pacts и независимый общественный мониторинг
M17	Уведомления и эскалация SLA
M18	Журнал аудита
M19	Публичный портал

4.1.1.2. Взаимодействующие системы

UN Quantum — основной источник данных о тендерах и контрактах.
Замонавий мактаб (Uzinfocom School Passport) — единый идентификатор школы.
Шафофф / tender.mc.uz — для фазы масштабирования.
АИС «Капитал қурилиш» — для фазы масштабирования.
Геопортал АСР — слой социальной инфраструктуры.
ГАСН — обмен видеопотоком.
Шлюз SMS — для SMS-OTP и уведомлений.
Инфраструктура электронной подписи.

4.1.1.3. Режимы функционирования

Штатный — круглосуточная доступность.
Профилактика — плановые работы не более 4 часов в месяц с объявлением за 7 дней.
Аварийный — деградация при недоступности внешних систем.
Восстановление — RTO не более 4 часов, RPO не более 1 часа.

4.1.1.4. Сценарии использования

Каталог сценариев приведён в Приложении А, сводка сквозных сценариев — в подразделе 4.2.

4.1.1.5. Программно-аппаратные средства

Контейнерная оркестрация (Docker/OCI, Kubernetes или эквивалент).
Реляционная СУБД (PostgreSQL 14+).
Объектное хранилище для медиафайлов.
Сообщения и очереди.
Поиск (Elasticsearch / OpenSearch).
Медиа-сервер для видеопотоков.

Рекомендуемый стек: backend на .NET, frontend на Angular (для совместимости с Замонавий мактаб). Окончательный выбор стека — за разработчиком с обоснованием.

4.1.2. Требования к взаимодействию с внешними системами

Спецификация интеграций — Приложение Г. Общие требования: HTTPS, REST, OAuth 2.0, OpenAPI 3.0+, JSON, OCDS для контрактных данных, обработка ошибок с буферизацией.

4.1.3. Численность и квалификация пользователей

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

4.1.4. Требования к надёжности и качеству

Платформа МБШ — это инфраструктурная система, от работоспособности которой зависит документирование процессов строительства десятков, а в перспективе — тысяч школ. Простой платформы означает, что подрядчики не могут загрузить фотоотчёты, технадзор не может верифицировать этапы, родители не могут подать обращения, выплаты приостанавливаются. Это прямой материальный ущерб программе и репутационный ущерб UNDP. Поэтому требования к надёжности сформулированы строго, в количественных метриках, с привязкой к финансовым штрафам в случае нарушения (детали — Приложение Т).

Доступность платформы (SLA): не менее 99,5% в год.
Плановые простои: не более 4 часов в месяц с объявлением за 7 дней.
RTO: не более 4 часов.
RPO: не более 1 часа.
Целостность журнала аудита: 100% (append-only с криптоцепочкой хэшей).
Соответствие модели качества ISO/IEC 25010 по 8 характеристикам.

4.1.5. Требования безопасности

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

HTTPS / TLS 1.3 обязательно для всех соединений.
Шифрование данных при хранении (AES-256) для PII и медиафайлов.
Многофакторная аутентификация для всех ролей выше CITIZEN_AUTHENTICATED.
Защита от OWASP Top 10.
Внутренний пентест перед каждым релизом.
Внешний пентест перед запуском в эксплуатацию и далее ежегодно.
Соответствие принципам ISO/IEC 27001 и 27002.
Сегментация сети, изоляция data tier.
Управление секретами через выделенный vault.

4.1.6. Требования к удобству использования

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

Многоязычный интерфейс: русский, узбекский (латиница), английский.
Адаптивный дизайн: десктоп, планшеты, мобильные.
Соответствие WCAG 2.1 уровня AA.
Единый design system и UX kit.

4.1.7. Требования к эксплуатации

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

Документированный регламент эксплуатации.
Техническая поддержка с 24/7 покрытием для критических инцидентов.
SLA на обслуживание (расширенная спецификация в Приложении Т).
Условия хранения резервных копий: 2 географически разнесённые площадки.

4.1.8. Лицензионная чистота

Платформа — институциональный актив, передаваемый бенефициару (МДшО) для долгосрочного использования и масштабирования на всю Республику. Если платформа содержит компоненты с проприетарными лицензиями, требующими ежегодных платежей, или использует библиотеки с несовместимыми лицензиями (например, GPL в коммерческом контексте), бенефициар после передачи столкнётся с непредвиденными расходами или юридическими проблемами. Поэтому требования к лицензионной чистоте формулируются строго на этапе ТЗ, чтобы избежать неприятных сюрпризов на этапе handover.

Подтверждение прав на используемые компоненты.
Преимущественное использование Open Source с совместимыми лицензиями (MIT, Apache 2.0, BSD).
Запрет на проприетарные компоненты без передачи прав заказчику.
Передача исходного кода в полном объёме при сдаче.

4.1.9. Стандартизация и унификация

Платформа взаимодействует с десятком внешних систем (UN Quantum, Замонавий мактаб, шлюз SMS, инфраструктура ЭП и др.) и будет интегрироваться с новыми системами по мере развития (Шафофф, АИС «Капитал қурилиш», Геопортал АСР). Если платформа использует нестандартные протоколы и форматы, каждая новая интеграция превратится в дорогостоящий и долгий проект. Использование общепринятых стандартов (HTTPS, REST, OAuth 2.0, OpenAPI, OCDS) гарантирует, что платформа сможет подключаться к согласованным внешним системам по формализованным контрактам интеграции, в том числе тем, которые будут определены владельцами государственных систем после ввода МБШ в эксплуатацию.

Использование стандартных протоколов (HTTPS, REST, OAuth 2.0/OpenID Connect в профилях, согласованных с владельцем интеграции, OpenAPI).
Унификация форматов обмена (JSON, XML, OCDS для закупок, GeoJSON для географии).
Соответствие международным стандартам качества ПО (ISO/IEC 25010).

4.1.10. Защита персональных данных (практическая)

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

Хэширование номеров телефонов подающих обращения.
Автоматическое обезличивание лиц на публикуемых фото/видео.
Регламент реагирования на запросы субъектов ПДн (доступ, исправление, удаление).
Назначение Data Protection Officer (DPO) разработчиком и заказчиком.

4.1.11. Расширенные нефункциональные требования

4.1.11.1. Производительность

Время отклика интерфейса (95-й перцентиль): не более 1,5 секунд для большинства операций; не более 3 секунд для тяжёлых отчётов и аналитических запросов.
Загрузка фото через адаптивный веб/PWA или Telegram MiniApp: до 5 МБ — не более 5 секунд на 4G; до 20 МБ — не более 20 секунд.
Загрузка дашборда области: не более 2 секунд при 100 школах.
Поиск по реестру школ (11 127 записей): не более 1 секунды.
Видеопотоки: одновременная поддержка не менее 50 камер с одновременным просмотром не менее 20 пользователями.

4.1.11.2. Масштабируемость

Архитектура должна поддерживать рост от пилота 45 школ до полного охвата 11 127 школ Республики без переписывания кода.
Горизонтальное масштабирование backend через увеличение количества инстансов.
Шардинг данных по регионам при необходимости.

4.1.11.3. Доступность

SLA по доступности: не менее 99,5% в год (исключая плановые простои).
Плановые простои: не более 4 часов в месяц, объявляются за 7 дней.
RTO (Recovery Time Objective): не более 4 часов.
RPO (Recovery Point Objective): не более 1 часа.

4.1.11.4. Безопасность

Полное соответствие O’z DSt ISO/IEC 27001:2016 и 27002:2016.
Соответствие O’z DSt 2814:2014 по классу защищённости от несанкционированного доступа.
HTTPS обязательно для всех соединений.
Шифрование данных при хранении (at rest) для PII и медиафайлов.
Многофакторная аутентификация для всех ролей выше CITIZEN_AUTHENTICATED.
Защита от OWASP Top 10 на уровне платформы.
Внутренний пентест перед каждым релизом.

4.1.11.5. Защита персональных данных

С учётом ЗРУ-1125 от 26.03.2026 персональные данные, подлежащие обязательному хранению на территории Республики Узбекистан, должны храниться в инфраструктуре, расположенной в Республике Узбекистан, а база персональных данных подлежит регистрации в Государственном реестре баз персональных данных. Любая трансграничная обработка допускается только при наличии отдельного правового основания, утверждённого заказчиком.

4.3.X. Классификация данных платформы. Все данные платформы подлежат классификации по уровню чувствительности и режиму обработки. Класс 1 — Публичные данные: паспорта школ, открытые тендерные данные, обезличенные ленты обращений, аналитика — публикуются по CC-BY 4.0, открытый API. Класс 2 — Служебные данные: внутренние отчёты, рабочие маршруты, статусы согласований — доступ по RBAC, без публикации. Класс 3 — Персональные данные: ФИО, телефоны, email, паспортные данные, должность, фото лиц — хранение и обработка по ЗРУ-1125, регистрация базы в Государственном реестре, хэширование при отображении на публике, удержание по политике retention. Класс 4 — Чувствительные ПДн: медицинские, семейные, биометрические, данные несовершеннолетних — повышенный режим, доступ строго по RBAC с обоснованием, шифрование at-rest и in-transit, обязательный audit log просмотров (M18). Класс 5 — UBO и Integrity Pacts: бенефициарные собственники, аффилированности, конфликты интересов — доступ ограничен ролями UNDP_PROCUREMENT, UNDP_INTEGRITY, CSAC; публикация только по решению UNDP_INTEGRITY. Класс 6 — Видео/фото со строек со школьниками: повышенный режим, размытие лиц перед публичной публикацией, ограниченное хранение, аудит каждого просмотра. Класс 7 — Audit logs (M18): неизменяемые, шифрование при хранении, доступ только UNDP_INTEGRITY, CSAC при инцидентах, регулятору по официальному запросу. Каждое поле каждого модуля обязано быть отнесено к одному из классов в модели данных. Несоответствие класса режиму обработки считается дефектом реализации.

Полное соответствие ЗРУ-1125 от 26.03.2026 «О персональных данных».
Хранение ПДн в Республике Узбекистан (если хостинг внутри страны).
Если хостинг вне РУз — соблюдение требований трансграничной передачи: согласие субъекта, договор с оператором, страна обеспечивает адекватный уровень защиты.
Хэширование номеров телефонов подающих обращения.
Обезличивание лиц на публикуемых фото/видео.
Право на доступ к своим ПДн и их удаление.
Регламент реагирования на запросы субъектов ПДн.

4.1.11.6. Журналирование и аудит

Все значимые действия в неизменяемом журнале (immutable log).
Минимальный набор полей: время, участник, роль, IP, сущность, действие, до/после.
Журнал доступен только ролям PLATFORM_AUDITOR и PLATFORM_SECURITY.
Хранение журналов: не менее 7 лет.
Соответствие требованиям внутреннего и внешнего аудита.

4.1.11.7. Удобство использования (Usability)

Многоязычность: русский, узбекский (латиница), английский. Пользователь выбирает язык в личном кабинете.
Адаптивный дизайн: десктоп, планшеты, мобильные.
Соответствие WCAG 2.1 AA.
Время первого входа нового пользователя до самостоятельной работы (после обучения 30 минут) — не более 1 часа.

4.1.11.8. Совместимость

Веб: последние 2 мажорные версии Chrome, Safari, Edge, Firefox.
Нативные мобильные приложения не разрабатываются. Мобильный доступ обеспечивается через адаптивный веб/PWA и Telegram MiniApp; поддерживаются последние две мажорные версии Chrome, Safari, Edge, Firefox, а также Telegram WebView на Android и iOS.
Базовая работа на устаревших устройствах допускается через мобильный браузер с ограничениями функциональности (например, без видеопотоков).

4.1.11.9. Сопровождаемость

Покрытие unit-тестами: не менее 70% для бэкенд, не менее 50% для фронтенд.
Интеграционные тесты для каждой внешней системы.
E2E-тесты для ключевых сценариев.
Документация API в OpenAPI/Swagger.
Документация архитектуры в формате C4 (уровни 1-3).

4.1.11.10. Переносимость

Развёртывание через контейнеры (Docker/OCI).
Оркестрация через Kubernetes (если выбран этот стек).
Базы данных — PostgreSQL.
Минимизация привязки к конкретному облачному провайдеру.

4.1.12. Требования к поиску и фильтрации

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

Общие требования к поиску: - Полнотекстовый поиск с поддержкой морфологии русского и узбекского языков (стемминг, лемматизация). - Поддержка нечёткого поиска (типографические ошибки, отсутствие диакритики). - Поиск по диакритике независимо от ввода (узбекский «ў» = «у» при поиске). - Поиск по транслитерации (запись «Сурхандарья» находит «Surxondaryo»). - Подсветка совпадений в выдаче. - Время отклика поиска не более 1 секунды для 95-го перцентиля.

Сущности и поля, по которым ведётся поиск:

Модуль	Сущность	Поисковые поля
M2	School	название (русский/узбекский/английский), national_id, school_id, регион, район, махалля, адрес, имя директора
M3	KoboAssessment	школа (через связь), оценщик, дата, версия формы
M5	ProcurementEvent	предмет, школа (через связь), тип пакета работ, статус, период
M5	Contract	школа, подрядчик, предмет, период, статус, сумма
M5	Organization	название, ИНН, тип, владелец UBO
M9	Evidence	контракт, школа, тип, дата, автор, комментарий, чек-лист
M11	CitizenFeedback	школа, категория, подкатегория, текст, статус, период, режим подачи, заявитель (если указан)
M13	WarrantyCase	школа, подрядчик, тип дефекта, статус, период
M18	AuditLog	актор, сущность, действие, период, IP

Фильтры: для каждого экрана со списками — конкретные фильтры в зависимости от сущности (статус, регион, период, тип, автор и т.д.).

Сохранение фильтров: - Пользователь может сохранить набор фильтров для повторного использования. - Системные «закладки» (Saved Views) — пример: «мои активные контракты», «обращения по моей школе без ответа», «гарантийные случаи на этой неделе». - Поиск в журнале аудита — с возможностью сохранения сложных фильтров для аудиторов.

Поиск по фотографиям: - По геометке (область на карте). - По дате съёмки. - По комментарию подрядчика. - По привязке к чек-листу.

Геопоиск: - Поиск школ в радиусе X км от точки. - Поиск школ в указанной области (рисование полигона на карте). - Поиск стройплощадок с активным видеомониторингом в регионе.

Сортировка: на каждом экране со списками — стандартные опции сортировки (по дате, по алфавиту, по статусу, по приоритету) и направление (по возрастанию / по убыванию).

Пагинация: для всех списков с потенциальным объёмом > 50 элементов — пагинация. По умолчанию 25 элементов на странице, возможные значения 10, 25, 50, 100.

4.1.13. Массовые операции

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

Массовые операции в платформе: - Массовый импорт школ из Замонавий мактаб (UC-A01). - Массовое присвоение ролей пользователям. - Массовое обновление атрибутов в справочниках. - Массовая отправка уведомлений (например, по всем директорам школ программы). - Массовый экспорт данных в Excel/CSV. - Массовая архивация устаревших записей.

Требования к массовым операциям: - Возможность выбрать множество записей в списке (через чекбоксы или фильтр). - Действие применяется ко всем выбранным. - Перед выполнением — подтверждение пользователем («Вы собираетесь обновить 247 школ. Продолжить?»). - Прогресс выполнения отображается пользователю в реальном времени. - Возможность отмены в процессе выполнения. - Атомарность: либо все записи обработаны успешно, либо ни одна (для критических операций). - Транзакционность: операция фиксируется в журнале аудита M18 как единая операция с указанием количества записей. - Откат при ошибке части записей: пользователю предлагается «откатить все изменения» или «оставить успешные, исправить остальные». - Лимит на размер операции (например, не более 10 000 записей за раз) для предотвращения перегрузки системы.

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

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

Школы и подрядчики в сёлах без интернета: - Telegram MiniApp и адаптивный веб поддерживают полноценный офлайн-режим. - Накопленные данные синхронизируются при появлении связи. - Возможность работать на стройплощадке без интернета весь день.

Граждане без смартфонов: - Веб-версия публичного портала с полным функционалом обращения (без необходимости QR-кода — с веб-формой подачи обращения по выбранной школе). - USSD-канал (для базовых функций) — на фазе масштабирования. - SMS-канал (отправка ключевых слов на короткий номер) — на фазе масштабирования.

Пользователи со старыми устройствами: - Веб-версия должна работать в браузерах с ограниченным функционалом. - Графики и интерактивные элементы — с graceful degradation в простые таблицы при ограничениях.

Лица с инвалидностью: - Соответствие WCAG 2.1 AA. - Полная работа с клавиатуры. - Совместимость с screen readers. - Высокая контрастность и крупный текст по запросу. - Альтернативные форматы для контента (subtitles для видео).

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

4.2. Требования к функциям и задачам

4.2.1. Ролевая модель платформы (общая)

4.2.2. Базовые принципы RBAC

Каждая роль определена через набор разрешений (permissions).
Пользователь имеет одну или несколько ролей. Эффективный набор разрешений — объединение.
Разрешения формулируются как пара «модуль + действие + scope».
Scope определяет границу видимости: own (только свои объекты), school (одна школа), district (район), region (область), republic (вся страна).
По умолчанию доступ запрещён. Разрешения добавляются явно.

4.2.3. Перечень ролей

Категория: Граждане

PUBLIC — анонимный посетитель публичного портала. Только просмотр публичных данных.
CITIZEN_AUTHENTICATED — гражданин, прошедший SMS-OTP идентификацию. Может подавать формальные обращения, отслеживать статус и получать официальный ответ. PUBLIC может подавать открытые civic signals без обязательной аутентификации.

Категория: Подрядчики

CONTRACTOR_REPRESENTATIVE — представитель подрядной организации с правом подавать отчёты, акты, документы по своему контракту.
CONTRACTOR_FIELD_WORKER — полевой сотрудник подрядчика, который через адаптивный веб/PWA или Telegram MiniApp загружает фотоотчёты с площадки.
CONTRACTOR_FINANCE — финансовый сотрудник подрядчика для просмотра выплат и налоговых документов.

Категория: Проектные организации

DESIGN_REPRESENTATIVE — представитель проектной организации для подачи ПСД.

Категория: Школа

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

Категория: Районный уровень

DISTRICT_EDU_HEAD — начальник районного УНО. Видит школы своего района.
DISTRICT_EDU_STAFF — сотрудник районного УНО.

Категория: Областной уровень

REGIONAL_EDU_HEAD — начальник областного управления МДшО.
REGIONAL_EDU_STAFF — сотрудник областного управления МДшО.
REGIONAL_HOKIM_DEPUTY — заместитель хокима области, курирующий программу.
REGIONAL_FINANCE — представитель областного управления финансов.
REGIONAL_ENGINEERING — технический надзор инжкомпании при облхокимияте.

Категория: Государственные надзорные органы

GASN_INSPECTOR — инспектор ГАСН.
KRU_AUDITOR — аудитор КРУ.
ACA_OFFICER — сотрудник Anti-Corruption Agency.

Категория: Центральный уровень

MOPSE_OFFICER — сотрудник центрального аппарата МДшО.
MOPSE_STRATEGY — представитель стратегического подразделения МДшО.
MOPSE_COMPLIANCE — представитель подразделения комплайнс МДшО.

Категория: UNDP

UNDP_PROGRAM_MANAGER — координатор программы UNDP.
UNDP_PROCUREMENT — менеджер по закупкам UNDP Country Office.
UNDP_FINANCE — финансовый сотрудник UNDP.
UNDP_INTEGRITY — специалист по добросовестности UNDP.

Категория: Партнёры

UNICEF_OFFICER — представитель UNICEF (WASH).
CSAC_OBSERVER — наблюдатель от Civil Society Advisory Committee.
NGO_MONITOR — наблюдатель от привлечённой НКО.

Категория: Системные

PLATFORM_ADMIN — администратор платформы (управление справочниками, ролями, пользователями).
PLATFORM_SECURITY — администратор безопасности (управление доступом, аудит).
PLATFORM_AUDITOR — аудитор платформы (просмотр всех журналов без права изменения).

4.2.4. Матрица RBAC (фрагмент — модули M2, M5, M9, M11)

Модуль / Действие	DIRECTOR	DISTRICT_EDU_HEAD	REGIONAL_EDU_HEAD	UNDP_PM	CONTRACTOR	CITIZEN_AUTH	PUBLIC
M2 Паспорт школы — просмотр	own	district	region	all	own contract	all (public)	all (public)
M2 Паспорт школы — редактирование	basic info	—	—	full	—	—	—
M5 Контракт — просмотр	own school	district	region	all	own	all (public part)	all (public part)
M5 Контракт — создание	—	—	—	all	—	—	—
M9 Доказательство — загрузка	own school comments	—	—	all	own contract	own complaint	—
M11 Жалоба — подача	own school	—	—	—	—	any school	—
M11 Жалоба — просмотр	own school	district	region	all	related	own	—
M11 Жалоба — ответ	own school	district	region	all	related	—	—

(полная матрица для всех 20 модулей и всех ролей — Приложение Б)

4.2А. Сквозной контроль бизнес-логики и отсутствия разрывов процесса

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

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

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

Обращения граждан и открытые сигналы должны быть связаны со школой, категорией, ответственным уровнем, SLA, статусом обработки и публичным обезличенным результатом. Формальные обращения дополнительно связываются с SMS-верификацией и tracking token. Открытые сигналы без телефона не исключаются из маршрутизации и контроля.

Каждый модуль обязан передавать события в журнал аудита M18 и в отчётный контур M20. Отсутствие события в аудите или невозможность построить отчёт по выполненному бизнес-действию считается дефектом реализации.

4.2.5. Сквозные пользовательские сценарии

UC-01. Подрядчик загружает ежедневный фотоотчёт

Участник: Сотрудник подрядной организации с правом «evidence_submit». Предусловие: Контракт активен, этап работ в статусе «in_progress». Триггер: Конец рабочего дня на стройплощадке.

Поток: 1. Участник открывает Telegram MiniApp или адаптивный веб-интерфейс МБШ. 2. Выбирает свой активный контракт и текущий этап. 3. Нажимает «Загрузить ежедневный отчёт». 4. Делает не менее 5 фотографий: начало дня (1), ключевые операции (2-3), конец дня (1). Каждое фото автоматически снабжается геометкой и временной меткой. 5. По каждому фото указывает короткий комментарий из преднастроенного списка («заливка фундамента», «монтаж кровли», «утепление стен», «установка окон» и т.д.) либо свободный комментарий. 6. Прикладывает короткое видео обхода площадки (опционально). 7. Подтверждает отправку. 8. Платформа в фоне проверяет: геометки в радиусе R от паспорта школы (R = 100 м для крупных объектов, 50 м для малых); файлы не дубликаты ранее загруженных; временные метки — текущая дата. 9. При прохождении валидаций — статус «accepted», запись доступна технадзору. 10. При несоответствии — статус «flagged», подрядчик уведомляется и должен дать объяснение.

Постусловие: Сегодняшний фотоотчёт зафиксирован, технадзор видит его в своей ленте.

Исключения: - Нет интернета — веб-клиент/PWA сохраняет отчёт в офлайн-очереди, отправляет автоматически при появлении связи. - Сбой геолокации — приложение требует подтверждения координат вручную, событие помечается «manual_geo».

UC-02. Родитель сканирует QR-код и подаёт жалобу на протечку крыши

Участник: Родитель ученика школы (любой гражданин с мобильным устройством). Предусловие: Директор школы разместил QR-код на здании. Триггер: Родитель видит проблему (например, протечку крыши после дождя).

Поток: 1. Родитель сканирует QR на здании школы. 2. Открывается публичная страница школы в браузере: паспорт школы, статус текущего проекта, подрядчик, этап, плановые/фактические сроки. 3. Внизу страницы кнопки действий: «Сделать фото», «Положительный отзыв», «Жалоба по инфраструктуре», «Жалоба на подрядчика». 4. Родитель нажимает «Жалоба по инфраструктуре». 5. Выбирает категорию «Крыша / протечка», описывает проблему и прикладывает фото. 6. Система предлагает выбрать режим подачи: «Открытый сигнал» без обязательной аутентификации или «Формальное обращение» с SMS-OTP, трекингом и обязательным ответом. 7. Если выбран открытый сигнал, платформа создаёт citizen_feedback с auth_level=anonymous_signal, применяет антиспам по device/browser fingerprint, IP-rate limit и модерацию контента; телефон не требуется. 8. Если выбран формальный режим, пользователь вводит телефон, получает SMS-OTP, вводит код, номер сохраняется как хэш, формируется tracking token. 9. Платформа применяет матрицу «срочно/важно»: тип «протечка крыши» = срочно × важно → high priority → SLA 24 часа. 10. Маршрутизация: директор школы, районное УНО, областное УНО, координатор программы, подрядчик при гарантийной/строительной связи, общественный наблюдатель региона. 11. По открытому сигналу публикуется обезличенный статус проверки и действие; по формальному обращению дополнительно отправляется SMS/ссылка для отслеживания и официальный ответ. 12. Если в течение SLA не зарегистрирован ответ или действие — автоматическая эскалация на уровень выше.

Постусловие: Обращение зарегистрировано, виден всем уровням управления, идёт SLA-таймер.

Бизнес-правила: - UC-02.1. Открытые civic signals принимаются без обязательной аутентификации и используются для первичной маршрутизации, проверки факта и общественного мониторинга; формальные обращения с обязательным ответом принимаются после SMS-OTP. - UC-02.2. Идентификация для формального обращения — только через SMS-OTP; платные сервисы идентификации не используются. - UC-02.3. Спам-защита: для открытых сигналов — лимиты по IP/device/browser fingerprint и поведенческие антиспам-правила; для формальных обращений — не более 5 обращений с одного подтверждённого номера в сутки. - UC-02.4. Открытая публикация допускается только после обезличивания лиц на фото, скрытия телефонов и удаления персональных данных несовершеннолетних.

UC-03. Инспектор ГАСН проверяет видеопоток по запросу

Участник: Инспектор ГАСН с правом «video_view_supervision». Триггер: Поступило обращение «работы ведутся ночью без разрешения».

Поток: 1. Инспектор открывает адаптивный веб-интерфейс МБШ, в том числе через мобильный браузер или Telegram MiniApp при наличии доступа. 2. Переходит в раздел «Видеомониторинг строек». 3. Выбирает регион → район → школу. 4. Видит интерфейс плеера: текущий поток + архив за последние 30 дней. 5. Перематывает архив к времени, указанному в обращении (например, 23:30). 6. Просматривает запись, фиксирует факт: подтверждение или опровержение нарушения. 7. Создаёт запись «inspection_finding» с прикреплённым фрагментом видео и временем. 8. Если нарушение подтверждено — переход к процедуре составления предписания (через государственные системы ГАСН, не в МБШ).

Постусловие: Результат инспекции зафиксирован, привязан к контракту и подрядчику.

Бизнес-правила: - UC-03.1. Видеоархив хранится 30 дней непрерывно, по запросу инспектора — экспорт фрагмента в файл. - UC-03.2. Все действия инспектора в МБШ фиксируются в журнале аудита.

UC-04. Заместитель хокима области изучает сводный дашборд

Участник: Заместитель хокима области с правом «regional_dashboard_view». Триггер: Подготовка к еженедельному совещанию по программам строительства.

Поток: 1. Участник открывает веб-интерфейс МБШ, авторизуется через 2FA. 2. Переходит на дашборд региона. 3. Видит карту области с маркерами школ программы (зелёные — в графике, жёлтые — лёгкое отставание, красные — критическое отставание, серые — финальная приёмка). 4. По клику на маркер — карточка школы: текущий этап, подрядчики, плановые vs фактические сроки, бюджет, % освоения, ленту последних событий, количество открытых обращений граждан с приоритетами. 5. В разделе «Регион» — агрегированные показатели: общее количество школ, число активных контрактов, освоение бюджета, средний процент готовности, рейтинг подрядчиков по соблюдению SLA. 6. Раздел «Обращения граждан» — лента жалоб с приоритетами, SLA-таймерами, ответственными. 7. Раздел «Эскалации» — обращения, по которым SLA нарушен и автоматическая эскалация поднялась на областной уровень. 8. Участник может оставить комментарий по конкретной школе или поручение конкретному ответственному.

Постусловие: Участник получил полную картину по программе в регионе, поручения зарегистрированы в системе.

4.2.6. Детальные функциональные требования по модулям

(далее приведены детальные требования по всем модулям)

M2. Паспорт школы и реестр объектов

Контекст и назначение модуля. Модуль M2 — основа предметной модели данных платформы. Каждая школа в системе — это единая запись (паспорт), к которой привязываются все остальные сущности: оценки инфраструктуры (M3), программы реновации (M4), контракты (M5), видеопотоки (M6), фотоотчёты (M9), обращения граждан (M11), гарантии (M13). Без корректной работы M2 невозможна работа ни одного другого функционального модуля.

Решаемая бизнес-проблема. Сегодня данные о школах ведутся в нескольких ведомствах одновременно (МДшО, Минфин, Минэкономики, региональные хокимияты), хранятся в Excel-таблицах с дублированием и расхождениями (см. Stage 1 раздел 6.2 «Системные пробелы процесса»). Учителя школ заполняют отчётность параллельно для 30+ ведомств. Модуль M2 устраняет эту проблему: единый паспорт школы импортируется из системы Замонавий мактаб (Узинфоком), которая ведёт государственный учёт 11 127 школ Республики, и используется как единственный источник правды.

Важная особенность. Платформа не заменяет «Замонавий мактаб» и не дублирует его функции. Она использует Замонавий мактаб как внешний справочник школ — с собственным внутренним идентификатором каждой школы (school_id), но с обязательной привязкой к национальному идентификатору. Это гарантирует, что данные платформы остаются согласованными с государственным реестром.

Цель

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

Пользователи и роли

PUBLIC, CITIZEN_AUTHENTICATED, SCHOOL_DIRECTOR, DISTRICT_EDU_, REGIONAL_EDU_, MOPSE_*, UNDP_PM, CONTRACTOR_REPRESENTATIVE.

Функции

M2.F1. Импорт паспорта школы из Замонавий мактаб - Способ 1 (пилот): ручная выгрузка Excel/CSV из Замонавий мактаб + загрузка администратором. - Способ 2 (масштабирование): прямая интеграция через API Узинфоком. - Импорт обновляет поля паспорта, но не перезаписывает поля, заполненные платформой.

M2.F2. Создание и редактирование атрибутов школы - Базовые атрибуты — заполняются из Замонавий мактаб, доступны только для чтения. - Расширенные атрибуты МБШ: фотогалерея общих видов, контактное лицо для программы реновации, текущий проект, история программ.

M2.F3. Загрузка фотогалереи школы - До и после реновации. - Каждая фотография — с метаданными (автор, дата, описание).

M2.F4. Реестр оценок Kobo по школе - История всех проведённых оценок. - Возможность сравнения двух оценок: «до» / «после реновации».

M2.F5. Активный проект - Список всех активных контрактов по школе. - Сводный таймлайн: события по контрактам в хронологическом порядке.

M2.F6. Лента событий школы - Все события: контракты, этапы, акты, фото, обращения, инциденты, ответы. - Фильтрация по типу, дате, контракту, контрагенту.

M2.F7. Поиск школы - По названию, ID, региону, району, программе, статусу. - Карточный и табличный вид результатов.

M2.F8. Карта школ - Интерактивная карта с маркерами. - Кластеризация при большом масштабе. - Цвет маркера — статус по программе.

Бизнес-правила

M2.BR1. Школу нельзя удалить из платформы. Можно только пометить как «архивирована» (например, при закрытии школы).
M2.BR2. Изменение базовых атрибутов разрешено только администратору и только при наличии соответствующего основания (реорганизация, переименование), с записью в журнал.
M2.BR3. Сравнение оценок Kobo доступно только при двух и более загруженных оценках.

Состояния школы

draft → active_in_program → in_renovation → commissioned → in_warranty → post_warranty → archived

API (логические endpoints)

GET /schools — список с фильтрами.
GET /schools/{id} — паспорт.
POST /schools/{id}/import — импорт из Замонавий мактаб.
POST /schools/{id}/photos — загрузка фото.
GET /schools/{id}/events — лента событий.

Критерии приёмки

Импорт паспорта из Замонавий мактаб занимает не более 30 секунд на школу.
Поиск по 11 127 школам выдаёт результат не более чем за 1 секунду.
Карта корректно отображает 11 127 маркеров с кластеризацией.

M2.F9 + M20.F7. BCC учётная карточка школы

Требует согласования с UNICEF. В паспорте школы фиксируется наличие назначенного учителя-наставника по гигиене, набор обучающих материалов UNICEF (загруженных в M9 evidence), журнал проведённых уроков мытья рук и гигиены (количество в квартал, охват учащихся). UNICEF_OFFICER видит сводный KPI «BCC покрытие» по программе. Школа с нулевым BCC за квартал — автоматическое уведомление M17 на UNICEF_OFFICER и SCHOOL_DIRECTOR.

M5. Тендеры и контракты

Контекст и назначение модуля. Модуль M5 — точка соприкосновения платформы с реальным денежным потоком программы. Через M5 в платформу попадают данные о всех тендерных процедурах и подписанных контрактах, на основании которых далее ведётся учёт работ (M8), фотоотчётов (M9), актов (M12), выплат (M7) и гарантий (M13). От корректности данных в M5 зависит достоверность всей последующей цепочки.

Принципиальная архитектурная развилка. В Республике Узбекистан действуют две тендерные платформы: национальная Шафофф (tender.mc.uz, оператор — Минстрой) для общих государственных закупок и корпоративная UN Quantum для закупок UNDP. На пилоте Joint Programme финансирование поступает по правилам UNDP, поэтому все тендерные процедуры проводятся через UN Quantum. Это финальное решение, подтверждённое заказчиком (см. Stage 1 раздел 10.1). Соответственно модуль M5 интегрируется в первую очередь с UN Quantum как с источником данных. Шафофф и АИС «Капитал қурилиш» остаются актуальными для будущей фазы масштабирования программы на бюджетное финансирование МДшО.

Подрядчик как ключевая сущность. В отличие от Замонавий мактаб, который содержит реестр школ, ни одна внешняя система не содержит достоверного реестра подрядчиков с раскрытым UBO, декларацией конфликта интересов, рейтингом по SLA и историей штрафов. Этот реестр впервые создаётся в M5 силами платформы. Это значит, что подрядчики, начинающие работать с UNDP в рамках программы, оставляют в M5 свой профиль для всех последующих программ — что повышает антикоррупционную устойчивость и позволяет МДшО после handover опираться на этот реестр.

Связь с другими модулями. M5 использует данные подрядчиков из M1 (организации, UBO). Создаёт контракты, на которые далее опираются M7 (выплаты), M8 (прогресс), M9 (доказательства), M11 (обращения по контракту), M12 (верификация), M13 (гарантия), M16 (Integrity Pacts).

Цель

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

Функции

M5.F1. Синхронизация тендеров с UN Quantum - Периодический pull данных по открытым и завершённым тендерам. - При создании тендера в Quantum — автоматическое появление в МБШ.

M5.F2. Карточка тендера - Предмет, школа/школы, тип пакета работ, сроки, бюджет. - Список участников (после закрытия). - Протокол оценки. - Победитель и цена. - Ссылка в UN Quantum.

M5.F3. Карточка контракта - Стороны, предмет, цена, валюта, сроки. - Этапы и график выплат. - Ссылки на оригинал и дополнения. - История изменений.

M5.F4. Регистрация подрядчика - При первом контракте — создание профиля контрагента. - UBO-сведения (бенефициарное владение). - Конфликт интересов. - Контактные лица.

M5.F5. Реестр всех контрактов по школе - Параллельные контракты разных пакетов работ. - Координация по календарно-сетевому графику.

M5.F6. Реестр контрактов по подрядчику - Все контракты подрядчика во всех школах. - Рейтинг по соблюдению SLA, штрафам, замечаниям.

M5.F7. Чёрный список подрядчиков - Подрядчики, дисквалифицированные от участия в школьных тендерах. - Срок дисквалификации. - Основание (с подтверждающими событиями в системе).

Бизнес-правила

M5.BR1. Контракт нельзя создать вручную, минуя UN Quantum или внутреннюю процедуру утверждения.
M5.BR2. Цена контракта в МБШ должна совпадать с ценой в UN Quantum. При расхождении — автоматический алерт.
M5.BR3. Подрядчик в чёрном списке не может стать стороной нового контракта. Технический блок.

Состояния тендера

draft → open → closed → awarded → contracted

Состояния контракта

draft → signed → in_progress → completed → closed → terminated → suspended

M5.F8. Compliance-дашборд подрядчика (Приложение И)

Для CONTRACTOR_REPRESENTATIVE формируется сводный экран соответствия Приложению И: 16 договорных блоков с текущим статусом (выполнен / частично / нарушение / не применимо), агрегацией доказательств M9, статусом Integrity Pact M16, актуальностью UBO M1, активными жалобами M11 и гарантийными случаями M13. По каждому блоку — ссылка на конкретный артефакт в платформе. Подача этапа на верификацию (UC-A17) блокируется при наличии «нарушений» по применимым блокам и автоматически уведомляет UNDP_INTEGRITY и UNDP_PROCUREMENT.

M5.F9. Due Diligence чек-лист контрагента

Перед подписанием контракта UNDP_PROCUREMENT проходит 24-пунктный чек-лист: 1-3 регистрация и лицензии; 4-7 UBO и аффилированности; 8-10 налоговая чистота и судебные споры; 11-14 опыт по аналогичным контрактам; 15-17 история жалоб и blacklist; 18-20 страхование и финансовая устойчивость; 21-23 Integrity Pact и этические обязательства; 24 окончательное согласование UNDP_INTEGRITY. Каждый пункт фиксируется с источником данных и автором проверки, хранится в M18. Невыполнение любого «обязательного» пункта блокирует UC-A11 (подписание контракта).

M5.F10. Bid evaluation matrix — открытая матрица оценки тендеров СМР

Для каждого тендера на строительные работы формируется матрица оценки предложений с весами критериев: цена (вес настраивается, обычно 30-50%), опыт по аналогичным контрактам (15-25%), сроки (10-15%), команда и квалификация (10-15%), история compliance и жалоб (10-15%), UBO + Integrity Pact (gate, не балл). Каждый критерий оценивается комиссией с обоснованием. По итогам публикуется обезличенный сводный балл всех участников + полное обоснование победителя в публичной витрине M19. Изменение весов после объявления тендера запрещено.

M5.F11. WASH-валидация ПСД до объявления тендера СМР

Требует согласования с UNICEF. После завершения проектирования (контракт типа «Design») UNICEF_OFFICER получает уведомление о готовности ПСД и проходит чек-лист WASH-соответствия проекта (25 пунктов: ratio туалетов по полу, гендерная сегрегация, ADA, MHM, точки питьевой воды, очистка стоков, климат-устойчивость, материалы). Без green по обязательным пунктам объявление тендера СМР заблокировано. UNICEF_OFFICER может затребовать корректировку ПСД от проектной организации.

M6. Видеомониторинг стройплощадки

Контекст и назначение модуля. Модуль M6 — один из главных антикоррупционных элементов платформы и одновременно один из самых нетривиальных технически. Сегодня основная проблема контроля строительства школ — «слепые промежутки» между плановыми проверками технадзора (раз в неделю), инспекцией ГАСН (дважды в месяц) и аудитом КРУ (раз в полгода после сдачи). Подрядчики знают эти промежутки и могут вести работы с нарушением технологии в периоды отсутствия наблюдения. Видеомониторинг устраняет этот пробел: камера ведёт непрерывную запись, к которой имеют доступ все надзорные органы.

Готовая модель из практики. Команда Единой инжиниринговой компании при хокимияте Сурхандарьинской области уже разработала и применяет архитектуру видеомониторинга школьных строек на базе оборудования MikroTik и протокола WireGuard VPN. Эта архитектура работает на практике, обкатана, документирована (типовая инструкция передана платформе). Модуль M6 переносит эту референсную модель в платформу без модификаций.

Принципиальное решение по собственности. Подрядчик закупает камеру, маршрутизатор MikroTik и UPS за свой счёт, стоимость оборудования заложена в его тендерное предложение. Оборудование остаётся в собственности подрядчика, после сдачи объекта он его демонтирует и забирает. Это решение принципиально снимает с программы (UNDP и МДшО) необходимость закупать, ставить на баланс, обслуживать и затем списывать тысячи камер по всей Республике. Платформа отвечает за серверную часть видеомониторинга — VPN-сервер, медиасервер, хранение архива, мониторинг доступности потоков, передачу потоков в ГАСН.

Двойное использование одного потока. Один и тот же физический видеопоток одновременно потребляется и Государственным архитектурно-строительным надзором (ГАСН) для проведения дистанционных проверок, и платформой «My Better School» для общественного контроля и журнала аудита. Это снимает дублирование инфраструктуры и не накладывает на подрядчика дополнительной нагрузки.

Детальная техническая спецификация. Подробное описание архитектуры, требований к камерам, конфигурации MikroTik и WireGuard, конфигурации NAT, мониторинга доступности и других технических деталей приведено в Приложении З. Подрядчик-разработчик обязан реализовать модуль M6 в соответствии со спецификацией Приложения З.

Цель

Непрерывный визуальный контроль площадки в период работ.

Принципиальная архитектура

Камера на площадке — собственность подрядчика (за счёт его тендерного предложения).
Маршрутизатор MikroTik с WireGuard VPN-клиентом.
VPN-сервер в инфраструктуре МБШ.
Один поток — два потребителя: МБШ и ГАСН.

Функции

M6.F1. Регистрация камеры в платформе - Подрядчик при первом контракте подключается к МБШ. - Платформа генерирует приватный ключ WireGuard и выделенный внутренний IP. - Подрядчик настраивает MikroTik по типовой инструкции (приложена).

M6.F2. Тестирование канала - При подключении — проверка достижимости камеры через VPN. - Тестовый снимок и тестовый видеофрагмент 30 секунд. - Подтверждение качества потока инженером МБШ.

M6.F3. Прямая трансляция (live view) - Веб-плеер с адаптивной мобильной разметкой. - Доступ по правам (контрактные стороны, ГАСН, координатор программы, общественные наблюдатели региона). - Записывается, что пользователь смотрел поток (в журнал аудита).

M6.F4. Архив видеозаписей - Запись 24/7 на серверной стороне. - Хранение 30 дней (конфигурируется в справочнике). - Перемотка, экспорт фрагментов.

M6.F5. Мониторинг доступности - Сервер каждую минуту проверяет доступность RTSP-потока. - Агрегация по часам и дням. - Дашборд «состояние камер» для оператора.

M6.F6. Алерты по простоям - Простой более 30 минут — уведомление подрядчику. - Простой более 4 часов в сутки — алерт координатору программы, основание для штрафа.

M6.F7. Передача потока в ГАСН - API/протокол для подключения ГАСН-стороны. - Учёт согласованных лимитов нагрузки.

M6.F8. Распознавание событий ИИ (опционально, Фаза 2) - Детекция: отсутствие СИЗ на рабочих, посторонние лица на площадке, ночные работы без разрешения. - Генерация события «inspection_finding» с привязкой к таймкоду.

Бизнес-правила

M6.BR1. Подрядчик не имеет доступа к интерфейсу удаления записей. Видеоархив — только в инфраструктуре МБШ.
M6.BR2. Любой просмотр архива фиксируется в журнале аудита с указанием пользователя, времени просмотра, диапазона.
M6.BR3. По окончании работ и финальной приёмки подрядчик демонтирует камеру. Запись о демонтаже — отдельное событие.

M6/M9 расширение. Child safeguarding режим обработки медиа

Требует согласования с UNICEF. В контексте школьного строительства (объект — школа) включается специальный режим обработки медиа: 1) автоматическое определение лиц на изображениях; 2) принудительное размытие лиц несовершеннолетних перед публикацией в M19 (необратимо для публичных копий); 3) специальный audit log просмотров видео и фото с детьми (метка чувствительности класс 4 «Чувствительные ПДн / дети»); 4) ограниченное хранение оригиналов с лицами детей — 90 дней с момента создания (отдельный таймер от общего 5-летнего хранения); 5) запрет публикации в M19 даже обезличенных медиа без согласования UNICEF_OFFICER или SCHOOL_DIRECTOR; 6) обязательное согласование Прил. Д контрактов с подрядчиками о child safeguarding (запрет курения, алкоголя, нарушения дисциплины на территории школы).

M9. Доказательная база (Evidence)

Контекст и назначение модуля. Модуль M9 — это хранилище всех фактических подтверждений работы платформы. Фотоотчёты подрядчиков, видеоархив со строек, проектные документы, акты, заключения экспертиз — всё это разнородные доказательства, объединённые в одном модуле для единообразного управления, поиска, валидации и публикации. Принцип «доказательство перед подписью» (см. раздел 2.3) реализован именно через M9: ни один акт (M12) не подписывается без полного пакета привязанных доказательств.

Качество доказательств важнее их количества. Подрядчики могут загружать фотографии в неограниченном количестве, но платформа автоматически проверяет каждую: геометка должна попадать в радиус 50–100 метров от паспорта школы; временная метка должна соответствовать дате загрузки; файл не должен дублировать ранее загруженные (проверка через MD5 и perceptual hash). Фотографии, не прошедшие валидацию, помечаются флагом и требуют пояснения подрядчика. Эти проверки исключают типичные манипуляции — повторное использование старых фото, фотографии с других объектов, монтаж.

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

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

Цель

Хранение всех материалов, подтверждающих выполнение работ и связанных событий.

Типы доказательств

Photo (с геометкой и временной меткой)
Video (с геометкой и временной меткой)
Document (PDF/DOCX/XLSX/DWG/IFC)
Sensor reading (показания датчиков, опционально)

Функции

M9.F1. Загрузка через адаптивный веб/PWA или Telegram MiniApp - Захват фото/видео прямо в веб-клиенте или Telegram MiniApp. - Автоматическая геометка из GPS устройства. - Автоматическая временная метка. - Контроль свежести: timestamp должен быть в пределах ± 5 минут от времени загрузки.

M9.F2. Загрузка с веб-интерфейса - Drag-and-drop. - Перетаскивание существующих файлов из устройства. - При отсутствии геометки в EXIF — обязательное указание координат вручную и пометка «manual_geo».

M9.F3. Валидация при приёме - Проверка геометки в радиусе R от паспорта школы. - Проверка временной метки в пределах разумного. - Проверка на дубликат (perceptual hash для фото, file hash для документов). - Проверка MIME-типа против разрешённого списка. - Проверка размера: фото до 20 МБ, видео до 500 МБ, документ до 100 МБ.

M9.F4. Привязка к чек-листу - При загрузке — указание, к какому пункту чек-листа относится доказательство. - Один пункт чек-листа должен иметь минимум одно доказательство.

M9.F5. Просмотр и галерея - Карточка доказательства: превью, метаданные, привязка, статус. - Галерея по контракту, этапу, чек-листу. - Поиск по дате, типу, автору.

M9.F6. Обезличивание лиц для публичной части - Автоматическое обнаружение лиц на фото при публикации на открытом портале. - Размытие лиц. - Оригинал хранится с лицами, доступен только авторизованным.

M9.F7. Аннотации - Технадзор и координатор могут оставлять комментарии и пометки на фото. - Аннотации хранятся отдельно от оригинала.

Бизнес-правила

M9.BR1. Удаление доказательства невозможно. Можно только пометить как «отозвано» с указанием причины.
M9.BR2. Подмена доказательства (загрузка нового на место старого) запрещена. Новое — новая запись.
M9.BR3. Доказательства, привязанные к подписанному акту, нельзя менять.

M9.F8. Витрина «До / После» по результатам строительных работ

Для каждой школы с завершённой реновацией формируется витрина сравнения: парные фото одних и тех же точек объекта до и после работ, метаданные оценки M3 до/после, динамика показателей инфраструктуры (WASH, климат, доступность). Витрина доступна на публичном портале M19 (после согласования SCHOOL_DIRECTOR и UNDP_PROGRAM_MANAGER). Используется как доказательная база освоения средств для отчётов донорам и публичных публикаций — антикоррупционный инструмент против фиктивных работ.

M9.F9. Офлайн-буфер фотоотчётов

Telegram MiniApp и адаптивный веб обеспечивают локальный буфер фотоотчётов CONTRACTOR_FIELD_WORKER: фото с EXIF и GPS сохраняются на устройстве при отсутствии сети, синхронизируются автоматически при появлении 3G/4G/Wi-Fi. При синхронизации валидируются временные метки (не старше 24 часов), GPS (в радиусе R от паспорта школы), дубли. Подрядчик видит индикатор «N фото в очереди на отправку». Несинхронизированные более 48 часов фото помечаются как просроченные и не принимаются как часть пакета доказательств для UC-A17/UC-A19.

M11. Канал общественной обратной связи (QR/web; открытый сигнал + SMS-OTP для формального обращения)

Контекст и назначение модуля. Модуль M11 — главный канал общественного контроля в платформе и, возможно, институционально значимый и репутационно критичный модуль. Через M11 любой гражданин может направить обращение по школе, статус её строительства или работу подрядчика. Этот канал реализует ключевой принцип Joint Programme — что инвестиции в школьное строительство должны быть подотчётны не только государственным надзорным органам, но и непосредственным бенефициарам: родителям, общинам, махаллям.

QR-код как точка входа. Каждая школа имеет уникальный QR-код, генерируемый платформой. Директор школы скачивает QR-код из своего личного кабинета и размещает на здании школы (фасад, ворота, главный вход). Любой гражданин с мобильным устройством сканирует QR и попадает на публичную страницу школы, где видит: паспорт школы, текущий проект реконструкции (если идёт), подрядчиков и этапы работ, плановые и фактические сроки, видеопоток со стройплощадки (если активен и согласован для публичного просмотра), ленту публичных событий. Внизу страницы — кнопки действий: сделать фото, оставить положительный отзыв, направить жалобу по инфраструктуре, направить жалобу на работу подрядчика.

Двухконтурная модель обратной связи — принципиальное решение настоящей редакции. QR-канал должен принимать открытый civic feedback без обязательной аутентификации: фото, сигнал о проблеме, положительный отзыв или указание на риск. Такой сигнал получает статус public_signal, публикуется после автоматической/ручной модерации, маршрутизируется ответственным и может стать основанием для внутренней проверки. Если гражданин хочет официальный ответ, трекинг статуса, участие в гарантийном случае или подаёт жалобу, требующую юридического режима обработки, платформа предлагает режим formal_appeal с SMS-OTP. Номер телефона хранится в виде хэша и не публикуется. Паспортная идентификация граждан для пилота не применяется.

Одновременная видимость на всех уровнях. Обращение, поступившее через M11, видно одновременно: директору школы, районному управлению образования, областному управлению МДшО, координатору программы UNDP, при гарантийном случае — соответствующему подрядчику, общественному наблюдателю региона. Локально «закрыть на это глаза» технически невозможно — все ответственные видят обращение и SLA-таймер. Этот принцип одновременной видимости — один из главных антикоррупционных элементов платформы.

Матрица «срочно/важно». Каждое обращение автоматически классифицируется по матрице срочности и важности. От класса зависит SLA на ответ: критическое — 24 часа, важное некритическое — 7 рабочих дней, справочное — 30 дней. Превышение SLA приводит к автоматической эскалации на следующий уровень управления.

Цель

Открытый канал общественного контроля через QR/web с возможностью подачи быстрого сигнала без обязательной аутентификации и отдельным режимом формального обращения через SMS-OTP.

Функции

Согласие на обработку персональных данных

Перед первым формальным обращением пользователя через SMS-OTP (M11.F5) платформа отображает форму согласия на обработку персональных данных в соответствии с Законом Республики Узбекистан ЗРУ-547 «О персональных данных». Форма содержит: цели обработки (приём и маршрутизация обращения, обратная связь по результату), перечень собираемых данных (номер телефона, ФИО при наличии, текст обращения и приложенные материалы), срок хранения (5 лет с даты обращения, согласно общему сроку доказательной базы), право на отзыв согласия и удаление данных через личный кабинет или запрос на info-адрес платформы. Факт согласия фиксируется в M18 с метаданными: дата, время, IP, версия политики, идентификатор пользователя. Без подтверждённого согласия формальное обращение через SMS-OTP не может быть подано. Анонимные открытые сигналы через QR без аутентификации (M11.F1) согласия не требуют, но не содержат ПДн в принципе.

M11.F1. Генерация и выдача QR-кода - Каждая школа имеет свой уникальный QR. - Директор школы скачивает QR из личного кабинета: предлагается несколько форматов (PDF для печати в формате A3, A4, A5, PNG для использования в публикациях). - В QR зашифрована ссылка на публичную страницу школы с уникальным токеном (защита от подделки).

M11.F2. Размещение QR на здании школы - Рекомендуемые места: главный вход, фасад, ворота, доска объявлений. - В личном кабинете — инструкция директору по размещению.

M11.F3. Публичная посадочная страница школы - Открывается при сканировании QR. - Содержимое: - Название школы, фотогалерея. - Паспорт (мощность, контингент, инфраструктура). - Текущий проект реконструкции: подрядчики, этапы, % готовности, плановые и фактические сроки, бюджет (агрегированно). - Лента публичных событий по школе. - Видеопоток со стройплощадки (если активен и согласован для публичного просмотра). - Кнопки действий.

M11.F4. Кнопки действий - «Сделать фото» — захват фото с камеры устройства с автоматической геометкой. - «Оставить положительный отзыв» — короткий текст + опциональное фото. - «Жалоба по инфраструктуре» — выбор категории, описание, фото. - «Жалоба на подрядчика» — выбор подрядчика из активных, категория, описание, фото.

M11.F5. Режим подачи и идентификация - Пользователь выбирает режим: «Открытый сигнал» или «Формальное обращение». - Для открытого сигнала номер телефона не обязателен; система создаёт public_signal, применяет антиспам-правила, модерацию, маршрутизацию и публичную обезличенную публикацию. - Для формального обращения требуется ввод номера телефона, SMS-код из 6 цифр, подтверждение кода, хэширование номера для хранения, выдача tracking token и отправка уведомлений о статусе. - Пользователь может позже “повысить” открытый сигнал до формального обращения, пройдя SMS-OTP и подтвердив связь с исходным сигналом.

M11.F6. Автоматическая классификация обращения - По выбранной категории и подкатегории. - По наличию ключевых слов в тексте. - Назначение приоритета по матрице «срочно/важно».

M11.F7. Маршрутизация - В зависимости от категории и приоритета — список получателей. - Минимальный набор: директор школы (всегда), районное УНО (всегда), областное УНО (всегда), координатор программы UNDP (если школа в программе), подрядчик (если относится к гарантии), общественный наблюдатель региона.

M11.F8. SLA и эскалация - Каждое обращение или открытый сигнал получает SLA по справочнику категории, приоритета и режима подачи. - Таймер обратного отсчёта отображается на дашборде первичного и вышестоящего ответственного. - Превышение SLA автоматически создаёт событие эскалации, уведомляет следующий уровень и фиксируется в M18/M20 как показатель качества реагирования.

M11.F9. Ответ и реакция - По формальному обращению ответственный обязан дать официальный ответ в SLA; подавший получает SMS-уведомление и ссылку для просмотра статуса. - По открытому сигналу ответственный фиксирует результат проверки или действие; публикация ответа в публичной ленте обязательна для прозрачности, но юридический режим индивидуального ответа не применяется. - Все ответы и действия публикуются на публичной странице школы с обезличиванием.

M11.F10. Публичная лента обращений - Открытый список всех обращений по школе с категориями, статусом, SLA, ответами. - Личные данные подающих обезличены. - Фильтрация по типу, статусу, дате.

Бизнес-правила

M11.BR1. Открытые civic signals принимаются без обязательной аутентификации и используются для первичной маршрутизации, проверки факта и общественного мониторинга; формальные обращения с обязательным ответом принимаются после SMS-OTP.
M11.BR2. Идентификация для формального обращения — только через SMS-OTP. Платные сервисы идентификации не используются. Для открытого сигнала номер телефона является опциональным.
M11.BR3. Спам-защита: для формальных обращений — не более 5 обращений в сутки с одного подтверждённого номера; для открытых сигналов — лимиты по IP/device/browser fingerprint, частоте отправки, повторяемости текста и качеству вложений. Превышение лимитов приводит к временной блокировке подачи, но не к удалению уже зарегистрированных записей.
M11.BR4. Удаление обращения невозможно. Только пометка «отклонено как спам» с обоснованием.
M11.BR5. Все обращения публикуются на открытом портале с обезличиванием лиц на фото и хэшированием номера.
M11.BR6. Локальное закрытие обращения школой или районом без зарегистрированного решения, статуса проверки, результата реагирования и записи аудита не допускается. Обращение видно всем применимым уровням одновременно.

Состояния обращения

new → acknowledged → in_progress → resolved → escalated → closed_with_response → closed_no_action → marked_as_spam

M11.F11. Категория обращения «WASH operational»

Требует согласования с UNICEF. Граждане через QR-канал (родители, учителя, дети-подростки) подают обращение с категорией «WASH operational» с подкатегориями: «нет воды», «нет мыла», «нет бумаги», «не работает туалет», «грязно / не убирается», «нет приватности / сломана дверь», «нет места для девочек (MHM)». Маршрутизация: SCHOOL_DIRECTOR (L1), UNICEF_OFFICER (одновременная видимость), подрядчик гигиенического пакета по Прил. Д.4 (если активен), DISTRICT_EDU_HEAD. SLA: «нет воды» — 4 ч, «нет мыла/бумаги» — 24 ч, остальные — 72 ч. Связано с M13 как гарантийный случай (если в гарантийный период).

M3.F9 + M11.F12. Continuous WASH monitoring

Требует согласования с UNICEF. После UC-A23 школы программа автоматически создаёт расписание обезличенных WASH-опросов через QR: 30 дней, 60 дней, 90 дней, 180 дней, далее раз в полгода до конца 5-летней гарантии M13. Опрос (5 вопросов): вода идёт?, есть мыло?, есть бумага?, туалет чистый?, чувствуешь приватность?. Респонденты — родители и учителя через QR, опционально — дети-подростки (с пометкой возраста-категории 12+). Результаты публикуются на M19 в обезличенном виде и попадают на дашборд UNICEF_OFFICER. Падение любого индикатора ниже 80% автоматически создаёт уведомление M17 на UNICEF + директора + подрядчика гигиенического пакета.

M13. Дефекты, 5-летняя гарантия, постпроектный мониторинг

Контекст и назначение модуля. Модуль M13 покрывает самую длинную, самую забываемую и одновременно самую важную часть жизненного цикла школьного объекта — пятилетний период гарантии после ввода в эксплуатацию. Сегодня гарантийные обязательства подрядчиков, установленные строительными нормами (ШНК 3.01.04-19), массово теряются: акты приёмки уходят в бумажный архив, гарантийные случаи разрешаются неформально через хокимият или вовсе игнорируются. Это означает, что подрядчик, сдавший школу с дефектами, не несёт за них ответственности в течение пяти лет — что снижает качество работ и приводит к преждевременному износу объектов.

Что меняет M13. Реестр всех гарантий в платформе с автоматическими уведомлениями о ключевых событиях: за 30 дней до истечения срока, при поступлении обращения, подпадающего под гарантию, при просрочке SLA устранения дефекта. Любая жалоба, поступившая через M11 в течение гарантийного срока и относящаяся к категории, подпадающей под гарантию (например, «протечка крыши» в школе, по которой выполнялись кровельные работы), автоматически маршрутизируется подрядчику-гаранту. Подрядчик обязан подтвердить приём в течение 24 часов, выехать в SLA-сроки (48 часов для критических случаев), устранить дефект, отчитаться. Невыполнение SLA автоматически начисляет неустойку и при систематических нарушениях приводит к внесению подрядчика в чёрный список (M5).

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

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

Цель

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

Функции

M13.F1. Регистрация гарантии - Автоматическая после подписания финальной Далолатномы. - Поля: контракт, подрядчик, ответственное лицо, контакты, предмет гарантии, дата начала, срок (по умолчанию 5 лет), дата окончания.

M13.F2. Реестр всех активных гарантий - Фильтрация по подрядчику, школе, региону, виду работ, сроку до окончания. - Дашборд «гарантии, истекающие в ближайшие 6 месяцев».

M13.F3. Регистрация гарантийного случая - Подаётся через M11 (обращение, классифицированное как гарантия) или вручную школьной администрацией / координатором. - Привязка к контракту-гаранту автоматически (по типу работ и дате ввода). - Категоризация дефекта.

M13.F4. SLA по гарантийному случаю - Критические дефекты: выезд 48 часов / устранение 7 рабочих дней. - Некритические: устранение 30 рабочих дней. - Таймеры на дашбордах ответственных.

M13.F5. Сопровождение гарантийного случая - Подрядчик подтверждает приём. - Подрядчик отчитывается о выезде, об устранении — с фото и подписью школы. - Школа подтверждает или отклоняет.

M13.F6. Автоматические штрафы - Невыполнение SLA — начисление неустойки. - Систематические нарушения — внесение в чёрный список.

M13.F7. Сезонное обслуживание - Если контракт предусматривает (котельные, насосы, септики) — ежегодный отчёт. - Платформа автоматически создаёт «seasonal_maintenance_task» с дедлайном.

M13.F8. Закрытие гарантии - По истечении срока — автоматический переход контракта в состояние post_warranty. - Финальный отчёт по гарантийному периоду: количество случаев, средний срок устранения, штрафы.

Бизнес-правила

M13.BR1. Гарантия сохраняется при реорганизации подрядчика. Обязанность уведомления — на подрядчике.
M13.BR2. Если подрядчик ликвидирован — гарантийные обязательства переходят на правопреемника или гарантийный фонд (если предусмотрено).
M13.BR3. После истечения гарантии новые гарантийные случаи не принимаются.

M1. Управление пользователями и организациями

Контекст и назначение модуля. Модуль M1 — фундамент всей системы. До регистрации первого пользователя и первой организации в платформе ничего другого работать не может. Этот модуль решает две связанные задачи: во-первых, обеспечивает безопасный вход в систему (аутентификация) и разграничение прав (авторизация), во-вторых, ведёт официальный реестр всех юридических лиц-участников программы. От качества работы M1 зависит, насколько надёжно защищена платформа от несанкционированного доступа, насколько чётко разграничены полномочия и насколько прослеживаемы действия каждого пользователя в журнале аудита (модуль M18).

Связь с антикоррупционным фокусом платформы. Раскрытие бенефициарного владения (UBO) и декларация конфликта интересов — обязательные элементы регистрации подрядных организаций. Без этих сведений новые контракты с подрядчиком технически невозможны. Эта мера — главный антикоррупционный барьер платформы на входе: компании, скрывающие реальных владельцев или находящиеся в санкционных списках, не могут пройти регистрацию и, следовательно, не могут получить контракт.

Связь с другими модулями. Все модули используют учётные записи и роли M1 для проверки прав доступа. Модуль M5 (Контракты) проверяет статус подрядчика в реестре перед созданием контракта. Модуль M16 (Integrity Pacts) использует данные UBO. Модуль M18 (Журнал аудита) фиксирует каждое действие с привязкой к пользователю M1.

Цель

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

Пользователи и роли

PLATFORM_ADMIN, PLATFORM_SECURITY (полное управление). Все остальные роли — самообслуживание профиля.

Функции

M1.F1. Регистрация организаций - Администратор регистрирует юридические лица: государственные органы, подрядные организации, проектные компании, НКО, инжкомпании, школы. - Атрибуты организации: тип, юридическое наименование, ИНН/налоговый номер, юридический адрес, контактные данные, реквизиты, лицензии (если применимо), сертификации. - Загрузка учредительных и регистрационных документов. - Верификация по справочнику ЕГРПО (государственный регистр юр. лиц) при наличии интеграции.

M1.F2. Раскрытие бенефициарного владения (UBO) - При регистрации подрядной организации — обязательное раскрытие UBO: физические лица с долей владения от 10% или контролем. - Поля по каждому UBO: ФИО, дата рождения, гражданство, ИНН, доля владения, тип контроля. - Прикрепление документов-подтверждений. - Декларация о соответствии и обязательство уведомлять об изменениях в течение 30 дней. - Автоматическая проверка UBO против санкционных списков ООН и национальных перечней лиц с ограничениями.

M1.F3. Декларация конфликта интересов - Обязательная декларация для подрядчиков, проектных компаний, технадзора, членов приёмочных комиссий. - Поля: связи (родственные, служебные, коммерческие) с заказчиком, школами, должностными лицами, другими подрядчиками, проектными компаниями. - Самоотвод от участия в процедурах при наличии конфликта. - Ежегодное обновление и обновление при изменениях.

M1.F4. Регистрация физических лиц-пользователей - Способ 1: для пользователей государственных органов — OneID/SSO либо иной согласованный государственный контур идентификации. - Способ 2: для действий с правовыми последствиями — E-IMZO/eMZO или иной согласованный государственный механизм ЭЦП. - Способ 3: для гражданского QR-канала и формальных обращений — SMS-OTP с фиксацией tracking token. - Способ 4: для UNDP, подрядчиков и внешних экспертов — служебное приглашение администратором с утверждённой процедурой верификации, паролем и обязательным вторым фактором; социальные логины и потребительские провайдеры идентичности не допускаются.

M1.F5. Привязка пользователя к организации и ролям - Один пользователь может быть привязан к одной или нескольким организациям. - В каждой организации — одна или несколько ролей. - Привязка к scope (своя школа, район, область, республика). - Делегирование полномочий другому пользователю с указанием срока (на период отпуска, болезни, командировки).

M1.F6. Многофакторная аутентификация - Все роли выше CITIZEN_AUTHENTICATED используют обязательную MFA или step-up-аутентификацию по уровню риска. - Поддерживаемые механизмы: OneID/SSO для пользователей государственных органов; E-IMZO/eMZO или иная согласованная национальная инфраструктура ЭЦП для юридически значимых действий; SMS-OTP только как дополнительный фактор для граждан и резервный канал; Telegram/web-push/in-app только как канал уведомлений, не как фактор юридической идентификации. - Подписание критических действий (акт, выплата, изменение прав, изменение справочников безопасности) требует повторного подтверждения перед действием.

M1.F6.GOV. Для государственной эксплуатации запрещается использовать потребительские приложения-аутентификаторы и социальные провайдеры идентичности в качестве обязательного или единственного механизма доступа. Базовые механизмы идентификации: OneID/SSO для пользователей государственных органов, E-IMZO/eMZO или иная согласованная инфраструктура ЭЦП для юридически значимых действий, SMS-OTP для гражданских обращений и резервных сценариев. Любой иной механизм допускается только после письменного согласования с владельцем системы, Uzinfocom/оператором интеграции и ответственным органом по информационной безопасности.

M1.F7. Управление паролями - Минимальная длина 12 символов, требования сложности. - История паролей (запрет повтора 10 последних). - Принудительная смена раз в 180 дней. - Защита от перебора (rate limit + capcha + временная блокировка после 5 неуспешных попыток). - Восстановление через подтверждённый канал (email + SMS).

M1.F8. Сессии и их управление - Время жизни активной сессии — 8 часов для рабочих ролей, 30 минут для финансовых и административных. - Автоматический выход при бездействии. - Список активных сессий пользователю в личном кабинете с возможностью завершить любую. - Принудительное завершение сессий администратором.

M1.F9. Самообслуживание профиля - Просмотр и изменение базовых атрибутов профиля (имя, контакты, фото, язык интерфейса). - Изменение пароля. - Управление вторым фактором. - История действий (последние 90 дней).

M1.F10. Жизненный цикл учётных записей - Состояния: invited (приглашение отправлено) → active → suspended (временно) → blocked (заблокирован) → deleted (удалён). - Удаление не стирает данные — пользователь помечается как deleted, его действия сохраняются в журнале аудита. - Регулярная ревизия неактивных учётных записей: 90 дней без активности → suspended, 180 дней → требование подтверждения, 365 дней → deleted.

M1.F11. Аудит доступа - Каждый вход, выход, неуспешная попытка, изменение прав, смена пароля — отдельная запись в журнале. - Алерты администратору: вход из необычного региона, множественные неуспешные попытки, MFA не пройдено.

M1.F12. Импорт и массовая регистрация - Массовый импорт пользователей из CSV (для первичного запуска и при масштабировании). - Шаблон с обязательными полями. - Валидация перед импортом. - Отчёт о результатах импорта.

Бизнес-правила

M1.BR1. Пользователь не может быть зарегистрирован без привязки к организации (кроме PUBLIC и CITIZEN_AUTHENTICATED).
M1.BR2. Подрядчик не может быть допущен к контрактам без полного раскрытия UBO и подписанной декларации о добросовестности.
M1.BR3. Лицо в санкционных списках не может быть зарегистрировано как UBO подрядчика — автоматический блок.
M1.BR4. Конфликт интересов в активной декларации — блокировка участия в соответствующих процессах (подписание актов, оценка тендера и т.п.).
M1.BR5. Удаление учётной записи невозможно физически — только пометка статуса. Все действия сохраняются.

Состояния учётной записи

invited → active ↔︎ suspended → blocked → deleted

API

POST /organizations — создание организации.
POST /users/invite — приглашение.
POST /auth/login — вход с MFA.
POST /auth/refresh — обновление сессии.
POST /auth/logout — выход.
GET /users/me — профиль текущего пользователя.
PATCH /users/me — обновление профиля.
POST /users/{id}/roles — назначение роли.
DELETE /users/{id}/roles/{role} — снятие роли.

Критерии приёмки

Регистрация новой организации с UBO и документами занимает не более 5 минут.
Вход в систему с MFA — не более 30 секунд.
Массовый импорт 500 пользователей завершается за 2 минуты с отчётом об ошибках.
При попытке регистрации UBO из санкционного списка — отказ в течение 2 секунд с указанием причины.

M3. Оценка и скоринг (на базе модели KoboToolbox)

Контекст и назначение модуля. Модуль M3 решает задачу объективной оценки состояния школьной инфраструктуры — без чего невозможно справедливо распределить ограниченный бюджет реновации между десятками тысяч школ Республики. На пилоте Joint Programme инженерная команда UNDP+UNICEF уже обследовала более 100 школ Кашкадарьинской и Сурхандарьинской областей с помощью открытого инструмента KoboToolbox, собрав по каждой школе более 70 параметров в шести группах данных (общие сведения, отопление, электроснабжение, конструктив, текущее состояние WASH, планируемые решения WASH).

Решаемая бизнес-проблема. На сегодня школы выбираются для реновации в условиях информационной асимметрии: государственные органы зачастую опираются на самоотчёты директоров школ, которые имеют стимулы как преуменьшать проблемы (показатель «отсутствие жалоб» влияет на годовую оценку), так и преувеличивать их (борьба за финансирование). Объективная инженерная оценка с фотофиксацией, заверенная независимым валидатором, устраняет эту асимметрию. Балльный скоринг (100 баллов по 8 критериям) превращает множество разнородных показателей в одно сопоставимое число, позволяющее ранжировать школы.

Принципиальное решение. Модуль M3 не использует KoboToolbox как внешний инструмент, а переносит модель оценки внутрь платформы. Это делается по двум причинам: во-первых, чтобы методика стала собственностью МДшО и не зависела от внешнего инструмента; во-вторых, чтобы оценка непосредственно связывалась с другими сущностями платформы — школой (M2), программой реновации (M4), контрактами (M5). После пилота методика M3 готова к передаче МДшО как государственный стандарт оценки школьной инфраструктуры.

Цель

Перенести внутрь платформы методологию инженерной оценки школьной инфраструктуры, разработанную командой UNDP в KoboToolbox при обследовании 100+ школ Joint Programme, обеспечить непрерывное использование, развитие и применение этой методологии без зависимости от внешнего инструмента.

Пользователи и роли

Оценщики (инженерная команда UNDP+UNICEF или назначенные региональные команды).
Школьная администрация (ответственное лицо за объект).
Валидаторы (старший инженер UNDP, региональный координатор).
Координатор программы (просмотр и использование результатов).

Функции

Источник методологии и роли заполнения

Методология объективной оценки школьной инфраструктуры разработана инженерной командой UNDP и UNICEF в марте–апреле 2026 года при обследовании 100+ школ Кашкадарьинской и Сурхандарьинской областей. Полная методология, перечень полей, шкала весов и эталонные результаты обследования зафиксированы в документе «Updated Final English Schools Engineering Assessment Report» и переданы подрядчику-разработчику как наследие при старте проекта (см. Прил. П, План миграции данных). Подрядчик не воссоздаёт методологию с нуля, а импортирует существующую форму KoboToolbox со всеми группами полей и переносит её в платформу с сохранением структуры данных и совместимости с уже собранными результатами по 100+ школам.

Дополнительная форма «Mahalla Profiles» (79 полей в 9 группах: общие сведения, экономические характеристики, социальная сфера, образование, здравоохранение, инфраструктура, экология, безопасность, фото) используется для прогнозирования нагрузки на школу через данные о контингенте детских садов и демографии прилегающих махаллей. Махалля как самостоятельная сущность фиксируется в модели данных (Прил. В).

Распределение ролей по заполнению формы оценки в платформе:

Большинство полей административного и инфраструктурного характера (общие сведения о школе, год постройки, контингент, источник энергии, состояние документации, типовой проект здания, привязка к махалле) заполняет специалист районного или областного управления образования (DISTRICT_EDU_STAFF, REGIONAL_EDU_STAFF) — на основании актуальных данных Замонавий мактаб, паспорта школы и сведений из реестров МДшО.

Школьные характеристики (фактическое состояние помещений, текущее WASH, проблемы инфраструктуры, фотофиксация изнутри) заполняет директор школы (SCHOOL_DIRECTOR) либо инженер инженерной команды при выездном обследовании.

Конструктивные и WASH-характеристики (категория аварийности, расчёты планируемого WASH, инженерные параметры) заполняет инженер с правами FIELD_INSPECTOR (на пилоте — инженерная команда UNDP+UNICEF, на масштабировании — инженер инжкомпании при хокимияте или нанятая профильная организация).

Ревизия и согласование заполненной оценки на этапе пилота производится совместно донором (UNDP_PROGRAM_MANAGER, UNICEF_OFFICER по WASH-разделу) и центральным уровнем МДшО (MOPSE_PROGRAM). После окончания пилота — без донора, по общим правилам Республики Узбекистан: предложение Кенгаша народных депутатов области → согласование МДшО → утверждение постановлением Президента → выделение средств Минфином → реализация Минстроем и МДшО. Платформа поддерживает оба сценария через единый workflow.

Возможность расширения справочников и форм средствами МДшО. Через конструктор Прил. Я центральный уровень МДшО (MOPSE_STRATEGY, MOPSE_PROGRAM) и PLATFORM_ADMIN могут: добавить новую школу за пределами пилотной когорты по упрощённой процедуре; зарегистрировать новую инженерную команду или подрядчика-обследователя; создать новую версию формы оценки (с дополнительными группами полей под отраслевые требования); изменить веса критериев скоринга; добавить новый источник финансирования помимо донорского. Все изменения версионируются, журналируются в M18, требуют согласования уполномоченной роли.

M3.F1. Реестр форм оценки - Каталог версий форм Kobo, поддерживаемых платформой. - Каждая форма — структурированный набор групп (общие, отопление, электроснабжение, конструктив, текущее WASH, планируемое WASH) с полями. - Возможность создания новой версии формы администратором: добавление/удаление полей, изменение весов в скоринге, тестовый прогон на исторических данных.

M3.F2. Импорт оценок из KoboToolbox - Способ 1 (стартовый): загрузка CSV/JSON-выгрузки из KoboToolbox. - Способ 2 (постоянный): прямая интеграция с API KoboToolbox для импорта новых записей. - Привязка к школе по national_id или GPS-координатам. - Хранение оригинала и обработанной структурированной версии.

M3.F3. Проведение оценки в платформе через адаптивный веб/PWA или Telegram MiniApp - Оценщик загружает форму на устройство, проводит обследование школы. - Поля заполняются последовательно по группам. - Обязательная фотофиксация: каждый узел инфраструктуры (стены, крыша, окна, туалеты, котельная, источник воды) — отдельные фото. - Геометки автоматически на каждом фото. - Сохранение черновика, продолжение в любой момент.

M3.F4. Валидация оценки - После завершения обследования — отправка на валидацию. - Валидатор просматривает поля, фото, проверяет на полноту и корректность. - Возможные действия: подтвердить, вернуть на доработку с комментариями, отклонить. - Подтверждённая оценка переходит в статус «validated» и становится основой для скоринга.

M3.F5. Автоматический расчёт скоринга - 100-балльная система с 8 критериями: 1. Стоимость реконструкции на ученика (вес 25). 2. Санитария (вес 12). 3. Водоснабжение (вес 11). 4. Отопление (вес 12). 5. Утепление (вес 10). 6. Риск сноса (вес 10). 7. Число зданий (вес 10). 8. Освещение (вес 10). - Веса конфигурируются администратором в справочнике (можно сохранить несколько версий «методики» для разных программ или донаций). - Формулы расчёта прозрачны, показываются в карточке оценки.

M3.F6. Сравнение оценок «до» и «после» - Если у школы несколько валидированных оценок — возможность сравнения по группам полей. - Визуализация: side-by-side, дельта. - Используется для подтверждения эффекта реновации.

M3.F7. Аналитика по когорте - Распределение скоринга по когорте программы. - Топ критичных проблем по проценту школ. - Региональные различия. - Выгрузка для отчётности донорам.

M3.F8. Передача методики МДшО - Возможность экспорта формы и методики скоринга в формате, готовом для использования МДшО как государственный стандарт. - Сопровождение пакетом методических материалов.

Бизнес-правила

M3.BR1. Скоринг рассчитывается только на валидированной оценке. Черновики не учитываются.
M3.BR2. При изменении версии формы или весов в методике — пересчёт ранее проведённых оценок не автоматический. Перерасчёт только по явному решению администратора с указанием обоснования.
M3.BR3. Оценщик не может валидировать свою собственную оценку — обязательно второе лицо.
M3.BR4. Удаление валидированной оценки невозможно. Можно только пометить как «отозвана» с обоснованием.
M3.BR5. Если у школы только одна оценка — параметр «улучшение по дельте» недоступен.

Состояния оценки

draft → submitted → returned_for_revision → submitted → validated → archived

API

GET /assessments — список с фильтрами.
GET /assessments/{id} — детали с расчётом скоринга.
POST /assessments — начать оценку.
PATCH /assessments/{id} — обновить поля.
POST /assessments/{id}/submit — подать на валидацию.
POST /assessments/{id}/validate — валидировать (с привилегией).
GET /scoring-methods — версии методики.

Критерии приёмки

Проведение полной оценки школы через адаптивный веб/PWA или Telegram MiniApp занимает не более 90 минут для опытного оценщика.
Расчёт скоринга по 8 критериям — не более 1 секунды.
Сравнение двух оценок одной школы отображается за не более 2 секунд.
Импорт CSV из KoboToolbox с 100 записями — не более 30 секунд.

M3.F10. MHM подгруппа (Menstrual Hygiene Management)

Требует согласования с UNICEF. Для школ с обучающимися девочками возраста ≥10 лет в форме оценки M3 добавляется подгруппа MHM: 1) наличие отдельной запираемой комнаты MHM; 2) дозатор для гигиенических средств; 3) утилизация менструальных отходов (контейнер с крышкой, регулярный вывоз); 4) душ или умывальник в комнате MHM; 5) информационный плакат на узбекском и русском языках; 6) обучение учителя-наставника. На UC-A23 для таких школ проверка MHM — обязательное условие сдачи WASH-раздела.

M4. Планирование программ реновации

Контекст и назначение модуля. Модуль M4 переводит результаты инженерной оценки (M3) в реалистичный план работ года с учётом бюджетных ограничений, готовности проектных решений, сезонности строительных работ и принципа «начинать с управляемого». Без M4 платформа оставалась бы пассивным наблюдателем; с M4 она становится инструментом принятия решений на уровне руководства программы.

Решаемая бизнес-проблема. Из 11 127 школ Республики невозможно реконструировать все одновременно — даже при максимальном финансировании. Выбор должен быть рациональным, прозрачным и защищённым от лоббирования. Сегодня формирование адресных списков идёт в Excel-таблицах, согласуется через многочисленные ведомства и подвержено искажениям. M4 предлагает альтернативу: симуляция нескольких вариантов программы года (максимизация числа школ / максимизация социального эффекта / максимизация cost-efficiency / географическая сбалансированность) с прозрачным выбором и подписями утверждающих лиц.

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

Цель

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

Пользователи

UNDP_PROGRAM_MANAGER, MOPSE_STRATEGY, REGIONAL_EDU_HEAD, REGIONAL_HOKIM_DEPUTY.

Функции

M4.F1. Воронка отбора - Этап «все обследованные школы» → рекомендованный список (фильтр по скорингу) → план года (фильтр по доступному бюджету и логистике). - Визуализация воронки.

M4.F2. Симуляция программы года - Пользователь выбирает источник финансирования и его лимит. - Платформа предлагает несколько вариантов состава программы: максимизация числа школ, максимизация социального эффекта, максимизация cost-efficiency, фокус на наиболее проблемных, географическая сбалансированность. - Каждый вариант — список школ с прогнозом бюджета по пакетам работ, сезонности. - Сравнение вариантов в таблице с ключевыми метриками.

M4.F3. Финализация плана года - Координатор и заинтересованные стороны обсуждают и фиксируют согласованный план. - Для каждой школы — типовой пакет работ из справочника. - Привязка к источнику финансирования. - Согласование на 2 уровнях: программа (UNDP+UNICEF+МДшО) и регион (хокимият).

M4.F4. Принцип «начинать с управляемого» - В первом году когорты автоматически предлагать школы малого и среднего размера с одним зданием. - Крупные и многозданиевые объекты переносить на последующие годы программы. - Параметры конфигурируются в справочнике.

M4.F5. Утверждение программы года - После финализации — формирование документа-программы (PDF) с подписями утверждающих лиц. - Программа становится основанием для запуска тендеров (БП-2 → БП-4).

M4.F6. Изменения программы в течение года - Возможные сценарии: исключение школы (форс-мажор), включение дополнительной (появилось финансирование). - Все изменения — через зарегистрированное решение с подписью утверждающего лица.

M4.F7. Архив программ прошлых лет - История всех когорт. - Ретроспектива: что планировали vs что реализовали. - Анализ отклонений.

Бизнес-правила

M4.BR1. Школу нельзя включить в план года, если у неё нет валидированной оценки и заполненного скоринга.
M4.BR2. Общая стоимость программы не может превышать утверждённый бюджет источника финансирования.
M4.BR3. Утверждённый план года изменяется только через зарегистрированное доп. решение.

Состояния программы года

draft → under_discussion → approved → in_execution → completed → archived

API

POST /programs/simulate — симуляция вариантов.
POST /programs — создание программы.
POST /programs/{id}/approve — утверждение.
GET /programs/{year} — программа года.

Критерии приёмки

Симуляция трёх вариантов программы по 100 школам — не более 5 секунд.
Утверждённая программа формирует пакет тендерных задач в течение 1 минуты.

M7. Управление контрактами и выплатами

Контекст и назначение модуля. Модуль M7 — самый чувствительный модуль с точки зрения антикоррупционного контроля, поскольку именно через него платформа взаимодействует с реальным денежным потоком. Каждая выплата подрядчику привязана к подтверждённому акту (M12), акт — к загруженным доказательствам (M9), доказательства — к чек-листу этапа. Бесследная оплата технически невозможна. Этот принцип — «деньги идут за подтверждением» — реализован не как декларация на бумаге, а как правило работы программного обеспечения, проверяемое при приёмке.

Что делает и не делает M7. M7 не выполняет фактические банковские транзакции — для этого используется UN Quantum и финансовый блок UNDP. M7 ведёт учёт того, какая выплата должна быть произведена (payment_due), отправляет соответствующее уведомление в UN Quantum через интеграцию И-1, получает подтверждение о фактической оплате обратно и фиксирует факт. Это разделение полномочий — намеренное: платформа не становится финансовой системой, что значительно упрощает её сертификацию и снимает множество регуляторных рисков.

Удержание (retention) и гарантии. M7 автоматически удерживает 5% от каждой выплаты этапа в качестве обеспечения устранения замечаний — эта сумма возвращается только через 60 дней после финальной приёмки при отсутствии замечаний. Дополнительно M7 ведёт реестр банковских гарантий: гарантия исполнения контракта (10% от суммы контракта на весь срок + 60 дней) и гарантия гарантийных обязательств (5% от суммы на 5 лет). За 30 дней до истечения гарантии система автоматически уведомляет ответственных.

Штрафы. M7 ведёт реестр всех штрафов по контракту с привязкой к нарушениям (просрочка фотоотчётности, просрочка сдачи этапа, нарушение видеомониторинга и др.). Платёжное поручение на удержание штрафа из ближайшей выплаты формируется автоматически. При накопленных штрафах более 10% от суммы контракта система предлагает координатору программы решение о расторжении контракта.

Цель

Сквозное управление жизненным циклом каждого контракта от подписания до закрытия с привязкой выплат к подтверждённым актам и взаимодействием с UN Quantum.

Функции

M7.F1. Жизненный цикл контракта - Состояния: draft → signed → in_progress → suspended → completed → closed → terminated. - Переходы возможны только по правилам, с записью обоснования.

M7.F2. Реестр этапов контракта - Этапы импортируются из справочника типовых этапов соответствующего пакета работ или настраиваются индивидуально. - По каждому этапу: плановые сроки, доля от общей суммы, требования (чек-лист).

M7.F3. Управление дополнительными соглашениями - Регистрация доп. соглашений (изменение цены, сроков, объёма). - Каждое доп. соглашение — отдельная запись с пакетом документов. - Влияние на общую сумму и график выплат — пересчёт автоматически.

M7.F4. Привязка выплаты к акту - После подписания этапного акта (M12) автоматически создаётся payment_due. - Уведомление в UN Quantum через интеграцию И-1. - Регистрация факта оплаты по подтверждению из UN Quantum.

M7.F5. Удержание 5% (retention) - По каждой выплате этапа удерживается 5% (конфигурируется). - Сумма удержания возвращается через 60 дней после финальной приёмки при отсутствии замечаний.

M7.F6. Реестр штрафов - Все штрафы по контракту с привязкой к нарушениям. - Автоматическое формирование платёжного поручения на удержание из ближайшей выплаты.

M7.F7. Реестр банковских гарантий - Гарантия исполнения (10%) — на весь срок контракта + 60 дней. - Гарантия гарантийных обязательств (5%) — на 5 лет с финальной приёмки. - Уведомления об истечении за 30 дней.

M7.F8. Закрытие контракта - После выполнения всех условий — финализация и подпись акта закрытия. - Передача в архив с сохранением полного пакета документов.

Бизнес-правила

M7.BR1. Выплата возможна только по подписанному этапному акту.
M7.BR2. Сумма всех выплат + удержания + штрафов = общая сумма контракта (включая доп. соглашения).
M7.BR3. Контракт нельзя закрыть, если по нему есть открытые гарантийные случаи или штрафы.
M7.BR4. При расторжении контракта — особая процедура с подписями обеих сторон и расчётом окончательного баланса.

API

GET /contracts — список.
GET /contracts/{id} — детали со связями.
POST /contracts/{id}/amendments — доп. соглашение.
POST /contracts/{id}/penalties — регистрация штрафа.
POST /contracts/{id}/close — закрытие.

Критерии приёмки

Открытие карточки контракта с историей и связями — не более 2 секунд.
Автоматическое формирование payment_due после подписания акта — в течение 1 секунды.

M8. Прогресс работ и календарно-сетевые графики

Контекст и назначение модуля. Модуль M8 — это слой визуализации и анализа того, как идут работы на стройках. Если M5 отвечает за «что и за сколько», M9 — за «что сделано» (доказательства), то M8 отвечает за «где мы относительно плана». Без M8 невозможно вовремя увидеть отставания, оценить риски срыва сроков, согласовать совместную работу нескольких параллельных подрядчиков на одной школе.

Параллельные подрядчики на одной школе. Реновация одной школы выполняется силами нескольких независимых подрядчиков с раздельными контрактами (общестрой, тепловые насосы, септик, поставка материалов). Подрядчики работают на одной площадке одновременно или последовательно. Координация осуществляется через ПСД и календарно-сетевой график. M8 визуализирует совместный график всех контрактов школы, автоматически выявляет конфликты по площадке (когда два подрядчика претендуют на одно рабочее пространство в одно время) и формирует алерты координатору программы.

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

Прогноз сроков завершения. На основании фактического темпа выполнения работ (соотношение фактической и плановой длительности завершённых этапов) M8 прогнозирует дату завершения каждого контракта и каждой школы. Прогноз отображается на дашбордах руководства (M14) и при значительных отставаниях генерируется алерт.

Цель

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

Функции

M8.F1. Календарно-сетевой график контракта - Импорт графика из MS Project / Primavera (XER, XML) или ручной ввод. - Этапы, подэтапы, зависимости, длительность, ответственные. - Критический путь автоматически.

M8.F2. Учёт факта - Подрядчик отмечает фактическое начало и завершение работ. - Платформа сопоставляет с планом, рассчитывает отклонения. - Визуализация: Ганттова диаграмма с отображением план/факт, разноцветно.

M8.F3. Прогресс по контракту - Расчёт % готовности на основе подтверждённых этапов и доли каждого. - Визуализация в карточке школы и контракта.

M8.F4. Прогноз сроков - На основе текущего темпа выполнения — прогноз даты завершения. - Сравнение с плановой датой. - Алерт при риске критического отставания.

M8.F5. Сводный календарь по школе - Все контракты, все этапы, все работы — единая лента событий. - Координация параллельных подрядчиков. - Конфликты по площадке — выделяются автоматически.

M8.F6. Сезонные ограничения - Учёт сезонности: бетонные работы зимой, теплоснабжение к отопительному сезону, кровельные — сухой период. - Алерты на этапы вне сезонного окна.

M8.F7. Отчёт «отставания» - Все контракты с фактическим отставанием более N дней. - Группировка по подрядчикам, регионам. - Используется на еженедельных совещаниях.

Бизнес-правила

M8.BR1. Прогресс не может превышать сумму подтверждённых этапов.
M8.BR2. Изменение плана возможно через зарегистрированное согласование с координатором.
M8.BR3. Критическое отставание (более 30 рабочих дней) — автоматический алерт всем уровням управления.

API

GET /contracts/{id}/schedule — график.
POST /contracts/{id}/progress — обновление факта.
GET /schools/{id}/timeline — лента событий школы.

Критерии приёмки

Импорт MS Project XML с 200 этапами — не более 30 секунд.
Визуализация Ганттовой диаграммы по контракту — не более 2 секунд.

M8.F8. Сводный календарь подрядчика

Для CONTRACTOR_REPRESENTATIVE формируется сводный календарь по всем активным контрактам подрядчика: даты этапов, плановые/фактические сроки, конфликты ресурсов (одна бригада на двух объектах в одну дату — автоматический флаг). Используется для самоконтроля сроков и подачи заявок на сдвиг этапов через UC-A12 (доп. соглашение). При обнаружении конфликта бригад уведомляется UNDP_PROGRAM_MANAGER.

M10. Telegram MiniApp для полевых пользователей + адаптивный веб

Контекст и назначение модуля. Модуль M10 — клиентский интерфейс платформы для пользователей, работающих в полевых условиях: подрядчики на стройплощадках, инженеры-оценщики, инспекторы ГАСН, наблюдатели CSAC и НКО, школьные администраторы. Для этих категорий ключевая работа — фотофиксация выполненных работ, заполнение чек-листов, подписание актов и оперативное реагирование на уведомления.

Архитектурное решение. В отличие от типичной модели «нативное приложение Android + iOS», МБШ использует веб-ориентированный подход: адаптивный веб/PWA и Telegram MiniApp как веб-клиент внутри Telegram. Отдельные нативные приложения, отдельные мобильные backend-API, публикация в магазинах нативных приложений и самостоятельная эксплуатация мобильных релизов не входят в скоуп настоящего ТЗ.

Telegram MiniApp — основной мобильный канал для полевых пользователей. MiniApp работает внутри клиента Telegram, доступен на Android и iOS без отдельной установки. Все полевые сотрудники в Республике Узбекистан уже используют Telegram — это исключает необходимость убеждать их установить ещё одно приложение, обучать новой авторизации, поддерживать публикацию в магазинах приложений.
Адаптивный веб (Responsive Web) — основной канал для офисных пользователей и резервный для полевых. Работает в браузере любого устройства (десктоп, планшет, смартфон). Все функции платформы доступны через веб; полевые сценарии (фотофиксация, чек-листы, видеомониторинг просмотра) дополнительно оптимизированы для мобильных браузеров.

Почему MiniApp, а не нативное приложение. Нативное приложение — это две кодовые базы (Android Kotlin/Java + iOS Swift), две процедуры публикации в магазинах (магазины нативных приложений с их модерацией), отдельная инфраструктура аналитики и crash reporting, обучение пользователей установке. Для пилота 45 школ отдельные нативные приложения создают несоразмерные затраты на разработку, публикацию, сопровождение, экспертизу и поддержку пользователей. Telegram MiniApp и адаптивный веб покрывают основной перечень полевых сценариев единой веб-кодовой базой и позволяют сохранить единые API, права доступа, аудит и бизнес-правила.

Цель

Обеспечить полевым пользователям адаптивный веб/PWA и Telegram MiniApp для фотофиксации, заполнения чек-листов, инициирования процедур подписания и оперативного реагирования; юридически значимые действия подтверждаются через OneID/SSO, SMS-OTP или E-IMZO/eMZO в зависимости от роли и действия.

Поддерживаемые роли

Основные пользователи Telegram MiniApp: CONTRACTOR_FIELD_WORKER (полевой работник), CONTRACTOR_REPRESENTATIVE (представитель подрядчика), оценщики M3, REGIONAL_ENGINEERING (технадзор), GASN_INSPECTOR (инспектор), CSAC_OBSERVER и NGO_MONITOR (наблюдатели), SCHOOL_DIRECTOR и SCHOOL_STAFF (школьная администрация).
Основные пользователи адаптивного веба: все остальные роли (UNDP_PROGRAM_MANAGER, UNDP_PROCUREMENT, UNDP_FINANCE, UNDP_INTEGRITY, MOPSE, REGIONAL_EDU, DISTRICT_EDU, KRU_AUDITOR, ACA_OFFICER, PLATFORM_ADMIN, PLATFORM_SECURITY).
Граждане (CITIZEN_AUTHENTICATED, PUBLIC) пользуются адаптивным вебом через QR-канал (модуль M11) или публичный портал (модуль M19).

Функции Telegram MiniApp (M10.MA)

M10.MA.1. Доступ через Telegram MiniApp. Пользователь открывает бот по служебной ссылке-приглашению. Telegram ID связывается только с уже созданной и верифицированной учётной записью платформы. Telegram используется как клиентский канал и канал уведомлений; он не является источником юридической идентичности. Для доступа к закрытым данным и критическим операциям применяется сессия платформы и step-up через OneID/SSO, SMS-OTP или E-IMZO/eMZO в зависимости от роли и действия.

M10.MA.2. Главный экран — лента работ. Активные контракты пользователя, текущие этапы работ, открытые задачи, уведомления, требующие действия.

M10.MA.3. Фото- и видеосъёмка. Захват фото и видео прямо в MiniApp через Telegram Web API. Автоматическая геометка через Telegram Web API с разрешения пользователя. Автоматическая временная метка. При фото — выбор пункта чек-листа этапа для привязки доказательства.

M10.MA.4. Чек-лист этапа. Полный список пунктов по текущему этапу с возможностью отметки каждого пункта, прикрепления доказательств, добавления комментариев, подписания подрядчиком для подачи на верификацию.

M10.MA.5. Электронная подпись. MiniApp может инициировать процедуру подписания, но юридически значимое подписание актов, решений, выплат и иных документов выполняется только через E-IMZO/eMZO или иной согласованный государственный механизм ЭЦП. Telegram ID, геолокация и временная метка фиксируются как атрибуты аудита, но не заменяют ЭЦП.

M10.MA.6. Уведомления через Telegram. Все уведомления приходят как сообщения от бота — нативные для пользователя, не требуют отдельной push-инфраструктуры. Возможность ответа из чата с ботом.

M10.MA.7. Просмотр обращений граждан по своему контракту. Подрядчик видит обращения, относящиеся к его контракту, может ответить, прикрепить документы.

M10.MA.8. Статус видеомониторинга. Подрядчик видит только статус доступности своей камеры (online/offline, uptime, последний пакет), но не получает доступ к видеопотоку или архиву. Доступ к потоку и архиву — у ГАСН, REGIONAL_ENGINEERING, EXTERNAL_CONSTRUCTION_CONTROLLER, UNDP_PM, CSAC, NGO, UNDP_INTEGRITY (Прил. З.8). Каждый просмотр фиксируется в журнале аудита M18.

M10.MA.9. Офлайн-очередь. При отсутствии связи MiniApp кэширует фотографии и действия локально. При появлении связи — автоматическая синхронизация с сервером. Индикатор количества несинхронизированных действий.

Функции адаптивного веба (M10.W)

M10.W.1. Все функции платформы. Полный функционал платформы доступен через веб для всех ролей. Все остальные функциональные модули платформы доступны через веб.

M10.W.2. Адаптивная разметка. Десктоп (≥1280px) — полный функционал в традиционной web-разметке. Планшет (768–1279px) — полный функционал с адаптированной разметкой. Мобильный (<768px) — оптимизированная разметка для удобного использования с маленького экрана.

M10.W.3. Поддержка фотозагрузки. Веб поддерживает захват фото через стандартный input[type=file] с capture=“camera” — для пользователей, у которых нет Telegram. Геометка через Geolocation API браузера.

Бизнес-правила

M10.BR1. Подписание акта через MiniApp допускается только как запуск процедуры подписания; юридически значимое подписание выполняется через E-IMZO/eMZO или иной согласованный государственный механизм ЭЦП. Геолокация и временная метка обязательны как доказательные атрибуты, но не заменяют ЭЦП.
M10.BR2. Фото с устройства, загруженное в MiniApp в офлайн-режиме, помечается флагом «sync_pending» до синхронизации.
M10.BR3. При смене Telegram-аккаунта пользователь должен запросить переподключение через администратора платформы.
M10.BR4. Все действия в MiniApp фиксируются в журнале аудита M18 с привязкой к Telegram ID и учётной записи платформы.
M10.BR5. Адаптивный веб/PWA и Telegram MiniApp используют общие backend API, общую модель прав, общий журнал аудита и общие бизнес-правила. Запрещено реализовывать отдельную бизнес-логику для MiniApp, расходящуюся с вебом.

Технические требования

Telegram MiniApp: реализация на HTML5 / TypeScript с использованием Telegram Web App SDK. Backend интеграция через Telegram Bot API. Хостинг MiniApp — на инфраструктуре платформы. Поддержка всех современных версий Telegram (Android, iOS, Desktop, Web). Адаптация под темы Telegram (светлая / тёмная).

Адаптивный веб: HTML5 / TypeScript / современный фреймворк (Angular, React или Vue по обоснованному выбору подрядчика). Поддержка браузеров: последние 2 мажорные версии Chrome, Safari, Edge, Firefox. Service Worker для офлайн-сценариев в вебе.

Распространение

Telegram MiniApp: через Telegram-бот. Координатор UNDP высылает пользователям ссылку приглашения. Пользователь нажимает, открывается бот, нажимает «Открыть MiniApp» — готово. Без публикации в магазинах приложений.
Адаптивный веб: через основной домен платформы. Авторизация через email + пароль + MFA.

Аналитика и crash reporting

Crash reporting: для веба — Sentry или эквивалент. Для MiniApp — встроенная логика отправки ошибок на сервер.
Анонимная аналитика поведения: какие функции используются чаще, где возникают сложности. Только обезличенные метрики, без PII.
Согласие пользователя: при первом запуске — явный экран с опциями выбора (можно отказаться от crash reporting, аналитики).

Безопасность

Telegram MiniApp использует встроенную аутентификацию Telegram + дополнительный MFA для критических операций.
Для веба — стандартная авторизация платформы (см. Приложение Ю).
Pinning сертификатов сервера для защиты от MITM в MiniApp.
Защита хранилища от извлечения с устройства.

Резервный механизм для пользователей без Telegram

Для категорий пользователей, не использующих Telegram (например, пожилые завхозы школ): - Адаптивный веб с полным функционалом через мобильный браузер. - Возможность временно делегировать функции другому пользователю. - Базовые операции (подтверждение акта) могут выполняться через SMS-канал.

Критерии приёмки

Telegram MiniApp открывается за 30 секунд (открытие бота + переход к MiniApp).
Время от открытия MiniApp до главного экрана — не более 3 секунд.
Загрузка фото через MiniApp — не более 10 секунд при 4G.
Офлайн-режим: запись 50 фото без интернета и синхронизация при появлении связи без потерь.
Адаптивный веб корректно отображается на устройствах от 320px ширины и выше.

M12. Верификация, инспекция и утверждение

Связь модуля с финальной приёмкой и гарантией. Финальная приёмка объекта школы (UC-A23) — заключительный артефакт модуля M12. После подписания UC-A23 запускается M13 (5-летняя гарантийная поддержка), а также — для школ с WASH-инфраструктурой — расписание continuous WASH monitoring через QR-опросы родителей и учителей (30, 60, 90, 180 дней после сдачи и далее раз в полгода). M12 связан с UC-A17 (подача этапа на верификацию), UC-A18 (верификация технадзором), UC-A19 (подписание этапного акта) и UC-A23 (финальная приёмка). Все действия M12 журналируются в M18.

Контекст и назначение модуля. Модуль M12 — сердце процессного контроля платформы. Через M12 каждый этап работ проходит формальную проверку независимым техническим надзором перед тем, как акт будет подписан и подрядчик получит выплату. Без качественной работы M12 принцип «деньги идут за подтверждением» (см. раздел 2.3) превращается в формальность. Поэтому M12 реализует строгое разделение ролей: подрядчик подаёт работу, технадзор проверяет, координатор программы утверждает. Один человек не может занимать сразу несколько ролей в этой цепочке для одного контракта.

Чек-лист как основа верификации. Каждый этап работ имеет чек-лист с конкретными пунктами, по которым технадзор должен проверить выполнение (например, для этапа «утепление стен» — пункты «материал соответствует ПСД», «толщина 100 мм», «армирующий слой выполнен» и т.д.). Шаблоны чек-листов хранятся в справочнике платформы (детальное содержание — Приложение Д) и могут конфигурироваться без программных изменений. Технадзор подтверждает каждый пункт отдельно, не может «оптом» одобрить весь этап. Отказ по любому пункту требует обязательного комментария.

Цифровая Далолатнома. Финальная приёмка школы оформляется электронной Далолатномой (по ШНК 3.01.04-19) с подписями всех членов многоведомственной комиссии. Каждая подпись фиксируется с привязкой ко времени и геолокации подписывающего лица — что подтверждает физическое присутствие на объекте. Шаблон Далолатномы приведён в Приложении Е.

Слепые промежутки между проверками. Сегодня между плановыми проверками технадзора, ГАСН и КРУ существуют значительные временные промежутки, в течение которых подрядчик работает без внешнего наблюдения. M12 не пытается заменить эти проверки, но обеспечивает доступ инспекторов к материалам платформы (фотоотчётам M9, видеоархиву M6) для проведения дистанционных проверок. Это значительно уменьшает «слепые промежутки» без изменения нормативной базы.

Цель

Управление процессом проверки и подтверждения этапов работ и инспекций на площадке независимыми участниками (технадзор, ГАСН, КРУ), с разграничением ролей подающего, верификатора, утверждающего лица.

Функции

M12.F1. Очередь верификаций для технадзора - Все этапы, поданные на верификацию по контрактам, относящимся к региону технадзора. - Сортировка по приоритету и срокам. - Фильтры.

M12.F2. Просмотр чек-листа и доказательств - По каждому пункту чек-листа — все фото-доказательства с возможностью увеличения. - Карта со всеми точками съёмки. - Видеоархив за период этапа.

M12.F3. Подтверждение / отказ по каждому пункту - Кнопки «подтвердить», «отклонить с комментарием», «требует доработки». - Возможность аннотировать фото.

M12.F4. Решение по этапу - После проработки всех пунктов — общее решение: «принять», «вернуть на доработку», «частичная приёмка». - Электронная подпись решения.

M12.F5. Инспекции ГАСН - Запланированные инспекции (2 раза в месяц по нормативу). - Внеплановые по сигналу. - Чек-лист инспекции, фотофиксация, заключение. - Интеграция с системами ГАСН (если применимо).

M12.F6. Контроль КРУ - Шестимесячный аудит после ввода объекта. - Пакет материалов автоматически генерируется (см. БП-7). - Запись заключения КРУ.

M12.F7. Конфликт мнений - Если подрядчик не согласен с отказом технадзора — процедура медиации. - Привлечение независимого эксперта или координатора программы.

Бизнес-правила

M12.BR1. Один и тот же пользователь не может быть и подающим (подрядчик), и верификатором (технадзор), и утверждающим (координатор). Разделение ролей обязательно.
M12.BR2. Технадзор не может подтвердить этап без проверки всех пунктов чек-листа.
M12.BR3. Подпись по факту инспекции ГАСН — только сотрудником ГАСН с подтверждённым доступом.

API

GET /verifications/queue — очередь.
POST /verifications/{id}/items/{n}/approve — подтверждение пункта.
POST /verifications/{id}/items/{n}/reject — отказ.
POST /verifications/{id}/decide — общее решение.

Критерии приёмки

Очередь верификаций обновляется в реальном времени.
Подтверждение чек-листа из 20 пунктов с просмотром фото — не более 10 минут для опытного технадзора.

M14. Дашборды и аналитика

Контекст и назначение модуля. Модуль M14 — это «глаза» руководства программы, областных хокимиятов, центрального аппарата МДшО и заказчика. Если детальная работа с конкретной школой или контрактом идёт в M2/M5/M8/M11, то M14 даёт агрегированную картину: где мы сейчас, где есть отставания, где сосредоточены риски, какой регион требует внимания. Без M14 руководители вынуждены опираться на доклады, презентации и Excel-отчёты — то есть на представление подчинённых о ситуации, а не на саму ситуацию.

Многоролевая аналитика. У каждой категории пользователей — свой дашборд, оптимизированный под её задачи и scope. Директор школы видит только свою школу; начальник районного УНО — школы своего района; заместитель хокима области — все школы своей области; координатор программы UNDP — все школы пилота. Это применение принципа наименьших полномочий (раздел 2.3) к аналитическим данным.

Drill-down как основной режим работы. Дашборды M14 не самоценны — они существуют для того, чтобы пользователь, заметивший проблему на агрегированном уровне (например, «в районе X высокая доля просроченных этапов»), мог за несколько кликов спуститься к конкретной школе и контракту и понять причину. Каждый показатель дашборда — кликабельный, drill-down ведёт к детальным данным.

Антикоррупционные дашборды. Отдельная категория дашбордов — для UNDP_INTEGRITY и ACA_OFFICER. На этих дашбордах отображаются специфические для антикоррупционного контроля показатели: количество флагированных доказательств (M9), просрочки фотоотчётности, аномалии в выплатах, рейтинг подрядчиков по штрафам, обращения граждан с категорией «коррупционный риск». Эти дашборды позволяют антикоррупционным сотрудникам сосредоточить ресурсы на наиболее проблемных кейсах.

Цель

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

Функции

M14.F1. Дашборды по ролям - SCHOOL_DIRECTOR: своя школа, статус проекта, открытые обращения. - DISTRICT_EDU_HEAD: район — список школ, агрегированные метрики, рейтинг. - REGIONAL_EDU_HEAD: область — карта с маркерами, агрегированные метрики, отставания, обращения. - REGIONAL_HOKIM_DEPUTY: область — высокоуровневая сводка, освоение бюджета, рейтинг подрядчиков. - MOPSE_OFFICER: республика — карта, регионы, рейтинги. - UNDP_PROGRAM_MANAGER: программа — все школы пилота, освоение, SLA, эскалации. - UNDP_INTEGRITY: антикоррупционные показатели — флагированные доказательства, штрафы, чёрный список. - CONTRACTOR_REPRESENTATIVE: свои контракты, выплаты, штрафы, рейтинг.

M14.F2. Визуализации - Карты с маркерами (цвет по статусу). - Графики: линейные (тренды), столбчатые (распределение), круговые (доли). - Таблицы с фильтрами, сортировкой, экспортом. - Тепловые карты (например, по уровню риска).

M14.F3. Drill-down - Возможность спуститься от агрегата к конкретной школе и далее к контракту, этапу, событию.

M14.F4. Сравнение периодов - Месяц к месяцу, квартал к кварталу, год к году.

M14.F5. Конструктор отчётов - Для аналитиков — возможность собрать отчёт из доступных метрик. - Сохранение шаблонов, расписание автогенерации, рассылка.

M14.F6. Экспорт - PDF (для презентаций), Excel (для дальнейшей работы), CSV (для интеграций).

Бизнес-правила

M14.BR1. Дашборд показывает только данные в пределах scope роли пользователя.
M14.BR2. Все экспорты с PII требуют подтверждения цели и фиксируются в журнале аудита.

Критерии приёмки

Загрузка дашборда области (100 школ) — не более 2 секунд.
Drill-down от региона до школы — не более 1 секунды.

M14.F7. Виджет «Дни до сдачи объекта»

Для каждой школы с активным контрактом строительства/реновации на дашборде SCHOOL_DIRECTOR и UNDP_PROGRAM_MANAGER отображается виджет: количество дней до плановой даты сдачи (из контракта M5), фактический процент готовности по этапам M8, риск-флаги по этапам с просрочкой, статус готовности к UC-A23 (финальная приёмка). При вероятности срыва >20% по календарно-сетевому графику M8 автоматически создаётся уведомление M17 уровня L2 координатору UNDP и руководителю UNDP_PM.

M14.F1. Расширение дашборда SCHOOL_DIRECTOR — «Сегодня требует моего внимания»

Дашборд SCHOOL_DIRECTOR включает блок «Сегодня требует моего внимания»: акты, ожидающие моей подписи (M12, UC-A19); обращения граждан с SLA менее 6 часов до истечения (M11+M17); запланированные контрольные визиты (M18.F6); риски срыва срока сдачи объекта (M14.F8). Каждая карточка содержит ссылку на действие.

M14.F9. Heatmap отставаний и рисков по районам

Для REGIONAL_HOKIM_DEPUTY и REGIONAL_EDU_HEAD формируется тепловая карта район области × тип проблемы: отставания этапов (M8), приостановки UC-A21, открытые жалобы M11 с высоким приоритетом, активные гарантийные случаи M13, нарушения compliance по Прил. И. Цвет ячейки агрегируется как функция количества и тяжести. Клик по ячейке открывает фильтрованный список школ. Используется для еженедельной планёрки и докладов хокиму.

M14.F10. Программный heatmap UNDP_PROGRAM_MANAGER

Сводная тепловая карта область × тип риска: освоение бюджета (под/над планом), приостановки UC-A21, открытые жалобы M11 высокого приоритета, отставания этапов M8, проблемные подрядчики (compliance Прил. И red/amber), L3 эскалации. Сравнение нескольких областей в одном экране. Клик по ячейке открывает фильтрованный список школ/контрактов. Используется для еженедельных управляющих совещаний и подготовки отчётов донору.

M14.F1 расширение для UNICEF_OFFICER — гендерный дашборд

Требует согласования с UNICEF. Специализированный дашборд UNICEF: 1) общий охват девочек по программе (абсолют + %); 2) % школ программы со Sphere-соответствием WASH; 3) % школ с MHM-инфраструктурой (для школ с девочками ≥10 лет); 4) % школ с ADA-доступом хотя бы 1 туалет; 5) непрерывность подачи воды (% дней с водой); 6) BCC-покрытие (% школ с активными уроками гигиены); 7) ratio туалетов девочки/мальчики по школам; 8) результаты continuous monitoring опросов 30/60/90 дней (динамика); 9) количество WASH operational обращений в SLA. Возможность фильтрации по областям, типам школ, возрастным группам.

M15. Открытые данные и API

Контекст и назначение модуля. Модуль M15 — это реализация одного из основополагающих принципов антикоррупционной программы: данные о расходовании государственных средств должны быть доступны не только государственным органам и UNDP, но и широкой общественности, журналистам, исследователям, неправительственным организациям. Закрытость данных порождает коррупционные риски; открытость — лучшая профилактика.

Что публикуется. Все данные платформы, не относящиеся к персональным данным и не подпадающие под государственную тайну, публикуются в машинно-читаемых форматах: школы (паспорта без ПДн), тендеры, контракты, выплаты (агрегированные), обращения граждан (обезличенные), штрафы по подрядчикам, чёрный список, гарантийные случаи (агрегированные). Лицензия — Creative Commons Attribution 4.0 (CC-BY 4.0): данные можно свободно использовать, в том числе коммерчески, при указании источника.

Соответствие международным стандартам. Контрактные данные публикуются в формате Open Contracting Data Standard (OCDS) — международного стандарта прозрачности государственных закупок. Это значительно облегчает использование данных международными исследователями и аналитиками, а также интеграцию с платформами антикоррупционного мониторинга.

API для разработчиков. Помимо периодических снэпшотов, M15 предоставляет открытый REST API. Анонимные клиенты ограничены до 100 запросов в минуту (защита от злоупотреблений), зарегистрированные разработчики — до 1000 запросов в минуту бесплатно. Это позволяет НКО, журналистам и гражданским разработчикам создавать собственные приложения, дашборды, журналистские расследования на данных платформы.

Цель

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

Функции

M15.F1. Каталог открытых данных - Перечень доступных наборов: школы (без ПДн), контракты (предмет, цена, подрядчик, сроки), тендеры (общие сведения), выплаты (агрегированные), обращения граждан (обезличенные), штрафы. - Метаданные каждого набора: описание, частота обновления, формат, лицензия.

M15.F2. Форматы - CSV, JSON, XML, GeoJSON (для географических данных). - OCDS (Open Contracting Data Standard) для контрактных данных — международный стандарт прозрачности закупок.

M15.F3. Общедоступный API - REST endpoints с лимитом запросов на анонимных клиентов. - Полный доступ для зарегистрированных разработчиков (с ключом, без оплаты).

M15.F4. Регулярные снэпшоты - Полные снэпшоты данных за день, неделю, месяц, год. - Хранение в облаке. - Возможность скачивания.

M15.F5. Документация API - OpenAPI/Swagger. - Примеры запросов на разных языках программирования. - Песочница для тестирования.

Бизнес-правила

M15.BR1. Данные с ПДн не выгружаются в открытый канал — только обезличенные.
M15.BR2. Лицензия открытых данных — Creative Commons Attribution или эквивалент.

Критерии приёмки

Доступ к открытому API без регистрации до 100 запросов в минуту на IP.
Снэпшоты обновляются ежедневно в 03:00 без сбоев.

M16. Integrity Pacts и независимый общественный мониторинг

Контекст и назначение модуля. Модуль M16 — реализация инструмента Integrity Pacts, разработанного международной антикоррупционной организацией Transparency International и применяемого UNDP в десятках стран. Integrity Pact — это соглашение трёх сторон (заказчик, подрядчик, независимый общественный наблюдатель), в котором стороны обязуются соблюдать антикоррупционные требования, а наблюдатель имеет полный доступ к материалам контракта и право публиковать периодические отчёты.

Принципиальное отличие от обычного общественного контроля. В обычной модели общественной обратной связи (M11) граждане могут подавать обращения, но не имеют прямого доступа к внутренним материалам контракта. В модели Integrity Pact независимый наблюдатель получает полный доступ к контракту, актам, фото, видео, обращениям по этому контракту — то есть может фактически проводить мониторинг изнутри. Это значительно увеличивает доверие общественности и одновременно создаёт серьёзный антикоррупционный барьер для подрядчика.

Кто может быть наблюдателем. Платформа поддерживает две категории независимых наблюдателей: представители Civil Society Advisory Committee (CSAC) — формальная общественная структура при ACA; и аккредитованные НКО, действующие в области антикоррупционного мониторинга. Аккредитация наблюдателей происходит через регистрацию в M1 с категорией «monitor» и подтверждением полномочий документом от Совета или ассоциации.

Обязательность для крупных контрактов. Платформа автоматически блокирует переход крупного контракта (выше порогового значения, конфигурируемого в справочнике) в статус «in_progress» без подписанного Integrity Pact. Это превращает Integrity Pacts из факультативного инструмента в обязательный элемент антикоррупционной архитектуры программы.

Цель

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

Функции

M16.F1. Регистрация Integrity Pact - Для каждого крупного контракта (выше порогового значения) — обязательное оформление Integrity Pact. - Стороны: заказчик (UNDP), подрядчик, независимый наблюдатель (НКО или CSAC). - Подпись всех трёх сторон в платформе.

M16.F2. Регистрация независимых наблюдателей - НКО регистрируются как организации с категорией «monitor». - Наблюдатели от CSAC — представители Civil Society Advisory Committee. - Подтверждение полномочий (документ от Совета или ассоциации).

M16.F3. Доступ наблюдателей к материалам контракта - Полный доступ к этапам, актам, фото, видео, обращениям по контракту-предмету Pact’а. - Анонимизация ПДн (если применимо).

M16.F4. Публикация отчётов наблюдателей - Периодические отчёты независимых наблюдателей публикуются на портале. - Структура отчёта: оценка соблюдения процедур, выявленные риски, рекомендации.

M16.F5. Реагирование на находки - Каждая находка наблюдателя — отдельная запись с SLA на ответ от заказчика и подрядчика.

Бизнес-правила

M16.BR1. Без подписанного Integrity Pact крупные контракты не могут переходить в статус «in_progress».
M16.BR2. Наблюдатель не имеет прав ни на одно «оперативное» действие в системе — только просмотр и публикация отчётов.

Критерии приёмки

Все крупные контракты пилота имеют активный Integrity Pact с подписанными отчётами наблюдателей не реже раза в квартал.

M17. Уведомления и эскалация SLA

Контекст и назначение модуля. Модуль M17 — нервная система платформы. Через M17 каждый ответственный получает информацию о значимых событиях, требующих его внимания: новое обращение для ответа, истекающий SLA, поступивший гарантийный случай, просрочка фотоотчёта и т.д. Без M17 даже совершенная платформа была бы пассивной — пользователю пришлось бы постоянно заходить в систему и проверять, не появилось ли что-то новое. С M17 платформа сама напоминает пользователю о его обязательствах.

Каналы доставки. M17 поддерживает четыре канала: электронная почта (для институциональных пользователей), SMS (для критических уведомлений и граждан), уведомления через Telegram-бот, web-push (M10), in-app сообщения в личном кабинете. Пользователь в своём профиле может управлять подписками — какой тип уведомлений по какому каналу предпочитает. Однако для критических уведомлений (безопасность, эскалация SLA) отписаться невозможно.

Эскалация по матрице уровней. Каждая задача / обращение / гарантийный случай имеет SLA-таймер. Если ответственный не реагирует в срок, M17 автоматически передаёт задачу на следующий уровень управления (с уведомлением вышестоящему руководителю). Эта эскалация — главный механизм борьбы с «забыли» и «не нашли времени». Четыре уровня эскалации (0 → 1 → 2 → 3) детально описаны в Приложении Ж.

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

Цель

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

Функции

M17.F1. Каналы доставки - Email (для институциональных пользователей). - SMS (для критических уведомлений и граждан). - Telegram/web-push. - In-app сообщения в личном кабинете.

M17.F2. Каталог типов уведомлений - См. часть X документа — типовые шаблоны и сценарии. - Каждый тип уведомления конфигурируется: канал по умолчанию, шаблон, частота.

M17.F3. Подписки пользователя - В личном кабинете пользователь управляет своими подписками: какие типы и какой канал предпочитает. - Обязательные уведомления (безопасность, эскалация SLA) — невозможно отписаться.

M17.F4. SLA-таймеры - Каждая задача / обращение / гарантийный случай — таймер. - Виден ответственному в его дашборде. - За 4 часа до истечения — предупреждение. - При истечении — алерт и эскалация на следующий уровень.

M17.F5. Эскалация по матрице - Уровни 0–3 (см. часть X). - При каждой эскалации — уведомление вышестоящему и архивирование предыдущего ответственного.

M17.F6. Журнал доставок - Каждое уведомление фиксируется: тип, получатель, канал, время отправки, статус доставки. - Повторная отправка при неуспехе.

Бизнес-правила

M17.BR1. Невозможно отключить эскалацию для критических случаев.
M17.BR2. Календарь учёта SLA. (a) Безопасность, аварийные обращения, инциденты 24/7 — календарные часы без приостановки. (b) Обычные обращения граждан (M11), уведомления подрядчикам — рабочие часы (Пн–Пт 09:00–18:00 по местному часовому поясу объекта) с учётом государственных праздников. (c) Гарантийные случаи (M13) — по категории дефекта: критические (протечка, отопление, электричество) — 24/7; некритические — рабочие часы. (d) Внутренние согласования и отчётность — рабочие часы. Каждое правило SLA в системе обязано иметь атрибут calendar_type ∈ {24x7, business, business_with_holidays} и сохраняться в M18.

Критерии приёмки

Доставка уведомления через все каналы — в течение 30 секунд от события.
При сбое одного канала — автоматический fallback на резервный.

M17.F7. L2 inbox регионального уровня

Для REGIONAL_EDU_HEAD, REGIONAL_HOKIM_DEPUTY формируется отдельная очередь автоэскалированных обращений (L2): обращения, по которым L1 (директор школы / УНО района) не ответил в SLA. Каждый элемент содержит: исходное обращение, школу, подрядчика, кто пропустил SLA, сколько времени до L3 (UNDP/CSAC), кнопки «Принять на себя» / «Поручить ответственному» / «Передать назад с поручением». Статусы: новое, в работе, передано L3. Журнал действий L2 — в M18.

M18. Журнал аудита и комплаенс

Контекст и назначение модуля. Модуль M18 — последняя линия защиты антикоррупционной целостности платформы. Все остальные модули могут содержать ошибки, могут быть скомпрометированы недобросовестным пользователем, могут иметь уязвимости. Модуль M18 гарантирует, что любое значимое действие — кто, что, когда, откуда сделал — навсегда сохранено в неизменяемом виде. Если в платформе совершено нарушение, M18 позволит расследовать его post factum и установить виновного.

Append-only журнал. Записи в журнале M18 никогда не удаляются и никогда не модифицируются. Технически это реализуется криптоцепочкой хэшей (каждая запись содержит хэш предыдущей, как в блокчейне): любое изменение исторической записи моментально нарушает цепочку и обнаруживается при проверке целостности. Эта архитектура делает невозможным «зачистку следов» даже системным администратором.

Что фиксируется. Все операции CRUD (создание, чтение, изменение, удаление) над значимыми сущностями (школы, контракты, акты, выплаты, обращения, гарантии). Все события аутентификации (входы, выходы, неуспешные попытки). Все изменения прав доступа. Все экспорты данных. Все подписания актов.

Доступ к журналу. Прямой доступ к M18 имеют только специальные роли: PLATFORM_AUDITOR (внутренний аудит), PLATFORM_SECURITY (безопасность платформы), ACA_OFFICER (антикоррупционные расследования), KRU_AUDITOR (финансовый аудит). Каждый просмотр журнала сам по себе записывается в журнал — это обеспечивает мета-аудит работы аудиторов.

Хранение. Большинство записей хранится не менее семи лет; записи о выплатах и актах приёмки — десять лет. Это обеспечивает достаточный временной охват для всех видов аудита, включая шестилетний период налогового учёта и пятилетний гарантийный период плюс запас.

Цель

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

Функции

M18.F1. Запись событий - Все CRUD-операции над значимыми сущностями. - Все аутентификационные события. - Все изменения прав доступа. - Все экспорты данных. - Все подписи и подтверждения. - Поля: время, участник (id, роль), IP, geo (если мобильный), сущность, действие, до/после-snapshot, request_id.

M18.F2. Защита от изменения - Append-only хранилище. - Криптографическая цепочка хэшей (как в блокчейне) — каждая запись хэширует предыдущую. - Проверка целостности по запросу.

M18.F3. Просмотр аудита - Доступ для ролей PLATFORM_AUDITOR, PLATFORM_SECURITY, ACA_OFFICER, KRU_AUDITOR. - Фильтры: по сущности, участнику, периоду, типу действия. - Экспорт в PDF и CSV для отчётности.

M18.F4. Алерты по подозрительным действиям - Множественные удаления одного пользователя — алерт. - Изменение прав в нерабочее время — алерт. - Массовый экспорт данных — алерт.

M18.F5. Соответствие требованиям - Соответствие O’z DSt ISO/IEC 27001:2016 в части регистрации событий. - Готовность к внешнему аудиту.

Бизнес-правила

M18.BR1. Запись в журнале не может быть удалена или изменена.
M18.BR2. Доступ к журналу — только специальным ролям, с записью каждого просмотра.
M18.BR3. Хранение — не менее 7 лет, для определённых событий (выплаты, акты) — 10 лет.

Критерии приёмки

Регистрация события — не более 50 мс задержки.
Проверка целостности журнала за период 1 год — не более 5 минут.

M18.F7. Журнал контрольных визитов на стройплощадку

Для каждого объекта строительства поддерживается журнал визитов контрольных лиц: дата, время прибытия и убытия, цель визита, действующее лицо и роль, артефакты по итогам (фотоотчёт, протокол, заключение, рекомендации). Регистрация прибытия осуществляется через адаптивный веб/MiniApp с фиксацией геолокации. Журнал доступен в кабинете SCHOOL_DIRECTOR (read own), DISTRICT_EDU_HEAD (read district), REGIONAL_EDU_HEAD (read region), KRU_AUDITOR (read all), UNDP_PROGRAM_MANAGER (read program). Записи неизменяемы; журнал — часть M18.

M19. Публичный портал

Контекст и назначение модуля. Модуль M19 — это «лицо» платформы для широкой общественности. Граждане, журналисты, исследователи, представители общин — все они впервые знакомятся с платформой через публичный портал. От качества M19 зависит, насколько прозрачной и подотчётной воспринимается программа.

Структура портала. Главная страница — карта Республики Узбекистан с маркерами всех школ программы. Цвет маркера показывает статус: в плане, в активной реновации, сдана, в гарантийном периоде. По клику на маркер открывается публичная страница школы с паспортом, фотогалереей, текущим проектом, контрактами и подрядчиками, лентой публичных событий, видеопотоком со стройки (если активен и согласован), кнопкой подачи обращения через QR-канал. На главной странице также — сводные показатели программы и реестр всех контрактов.

Антикоррупционный раздел. Отдельный публичный раздел портала специально посвящён антикоррупционной информации: чёрный список подрядчиков с обоснованиями, статистика штрафов, отчёты независимых наблюдателей по Integrity Pacts, открытые данные в OCDS. Этот раздел делает антикоррупционную работу платформы видимой и проверяемой со стороны общественности.

Многоязычность. Портал доступен на трёх языках: русский, узбекский (латиница), английский. Переключение языка в шапке портала. Поисковая выдача, фильтры, описания — всё переведено.

Защита персональных данных. На публичной части портала не отображаются персональные данные. Лица на фотографиях автоматически обезличиваются (размытие). Контактная информация подрядчика — только корпоративная (юридический адрес, телефон и email компании), без личных данных представителей.

M20. Отчётность и экспорт

Контекст и назначение модуля. Модуль M20 закрывает важнейший практический пробел между сырыми данными (модули M1–M19) и формализованной отчётностью, которую требуют доноры, бенефициары и регуляторы. Без M20 координаторы программы вынуждены вручную выгружать данные из дашбордов в Excel, дорабатывать в офисе, форматировать в Word — что приводит к ошибкам и увеличивает трудозатраты и риск ошибок. С M20 типовые отчёты генерируются автоматически по расписанию, а нетиповые — за минуты через конструктор.

Цель

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

Пользователи и роли

UNDP_PROGRAM_MANAGER, UNDP_FINANCE, MOPSE_OFFICER, MOPSE_STRATEGY, KRU_AUDITOR (типовые отчёты по их области), PLATFORM_ADMIN (настройка шаблонов).

Функции

M20.F1. Каталог типовых отчётов - Ежемесячный программный отчёт UNDP донору (Ishonch 2030 Fund): прогресс по школам, освоение бюджета, KPI, риски, обращения граждан. - Квартальный отчёт МДшО: реализация программы по регионам, статистика по обращениям, статус подрядчиков. - Финансовый отчёт UNDP: выплаты по периоду, удержания, штрафы, retention. - Отчёт КРУ по школе: полная история контрактов, актов, выплат для аудита. - Гарантийный отчёт по подрядчику: количество гарантийных случаев, SLA соблюдение. - Антикоррупционный отчёт ACA: статистика обращений, инциденты, штрафы. - Публичный годовой отчёт программы для размещения на портале.

M20.F2. Конструктор пользовательских отчётов - Выбор источников данных (одна или несколько связанных сущностей). - Выбор полей. - Применение фильтров. - Группировка и агрегации. - Сортировка. - Визуальные элементы (таблицы, графики, карты). - Сохранение шаблона для повторного использования.

M20.F3. Расписание автогенерации - Расписание по типовым и пользовательским шаблонам: ежедневно, еженедельно, ежемесячно, ежеквартально, ежегодно, в конкретные даты. - Привязка к получателям (email-рассылка с приложенным файлом, публикация в платформе, выгрузка в облако). - Уведомление получателей о готовности отчёта.

M20.F4. Экспорт в форматах - PDF (для публикации и презентации). - Excel/XLSX (для дальнейшей работы с данными). - CSV (для технической интеграции). - DOCX (для редактирования в Word). - HTML (для веб-публикации). - OCDS JSON (для контрактных данных).

M20.F5. История генерации - Журнал всех сгенерированных отчётов с возможностью повторного скачивания. - Версии шаблонов отчётов. - Журнал доставки получателям.

M20.F6. Брендирование отчётов - Шаблоны с логотипами UNDP, UNICEF, МДшО, программы Joint Programme. - Цветовая схема, шрифты, размещение элементов. - Локализация (RU / UZ / EN).

Бизнес-правила

M20.BR1. Пользовательский отчёт показывает только данные в пределах scope роли пользователя.
M20.BR2. Все генерации фиксируются в журнале аудита M18 — особенно если отчёт содержит PII.
M20.BR3. Отчёт, рассылаемый автоматически, не может быть удалён получателем — это только копия, оригинал хранится в платформе.
M20.BR4. Шаблоны типовых отчётов изменяются только администратором с согласованием заинтересованных сторон.

Состояния отчёта

draft (шаблон) → scheduled (запланирован) → generating (генерируется) → ready (готов) → delivered (доставлен)

API

GET /reports/templates — список шаблонов.
POST /reports/generate — генерация отчёта (синхронно или асинхронно).
GET /reports/{id} — получение отчёта.
POST /reports/schedules — расписание.

Критерии приёмки

Генерация ежемесячного программного отчёта UNDP занимает не более 60 секунд.
Конструктор отчётов позволяет аналитику собрать новый отчёт за 10 минут без обращения к разработчику.
Все типовые отчёты доступны и протестированы перед сдачей платформы.

Цель

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

Функции

M19.F1. Главная страница - Карта Республики с маркерами школ программы. - Лента последних значимых событий. - Сводные показатели программы: число школ, освоенный бюджет, реализованные работы, ответы на обращения.

M19.F2. Карта школ - Все школы программы. - Цвет маркера по статусу. - Поиск, фильтры по региону, программе, типу работ.

M19.F3. Публичная страница школы - Паспорт (мощность, контингент, инфраструктура — публичные поля). - Фотогалерея. - Текущий проект: контракты, подрядчики, этапы, % готовности. - Видеопоток (если разрешено публично). - Лента публичных событий. - Обращения граждан (обезличенные). - QR-код для печати и размещения.

M19.F4. Реестр контрактов - Все контракты программы с предметом, ценой, сроком, подрядчиком. - Открытые данные в формате OCDS.

M19.F5. Раздел «Антикоррупция» - Чёрный список подрядчиков с обоснованиями. - Штрафы по подрядчикам. - Отчёты независимых наблюдателей. - Integrity Pacts.

M19.F6. Подача обращения - Альтернатива QR-каналу — обращение через веб-интерфейс. - Все поля и процедуры идентичны UC-02.

M19.F7. Открытые данные - Раздел с каталогом наборов данных (см. M15).

M19.F8. Многоязычность - Русский, узбекский (латиница), английский. - Переключение в шапке.

Бизнес-правила

M19.BR1. На публичной части не отображаются ПДн.
M19.BR2. Контактная информация подрядчика — только корпоративная (юр. адрес, телефон, email компании), без личных данных представителей.

Критерии приёмки

Загрузка главной страницы — не более 1,5 секунды.
Поисковая выдача по школе — не более 0,5 секунды.
Соответствие WCAG 2.1 AA.

M20.F8. Donor-report generator

Типовой шаблон отчёта донору (Ishonch 2030 Fund, UN agencies, иные доноры) с фиксированной структурой: 1) executive summary; 2) прогресс по школам с фото до/после; 3) освоение бюджета с разбивкой по типам работ; 4) KPI (доступность, WASH, климат, охват детей); 5) риски и митигация; 6) обращения граждан (агрегированные обезличенные данные M11); 7) доказательная база (выборка фото и видео M9 — обезличено); 8) истории успеха; 9) приложение OCDS-данных. Готовится в PDF/DOCX с брендингом UNDP/UNICEF/МДшО. Версии хранятся в M18.

M20.F9. UNICEF WASH report generator

Требует согласования с UNICEF. Типовой отчёт UNICEF Officer по программе с разделами: 1) JMP-индикаторы (basic / limited / no service по школам); 2) Охват девочек и MHM; 3) ADA-доступность; 4) Continuous monitoring сводка опросов; 5) BCC-покрытие; 6) Гигиенические поставки (Прил. Д.4); 7) Климат-устойчивость; 8) Lessons learned. Форматы: PDF, DOCX, XLSX, JMP CSV экспорт. Расписание: ежеквартально для HQ, ежегодно для JMP, по запросу донора.

M20.F10. Lessons learned регистр

Требует согласования с UNICEF. По каждой школе программы UNICEF_OFFICER (и другие роли с правами) могут фиксировать карточки «опыта»: что сработало, что не сработало, рекомендация для следующих когорт, артефакты-доказательства (фото, видео, документы). Регистр доступен на портале M19 в обезличенном виде как «база знаний программы». Используется при формировании когорты следующего года (UC-A06/A07) и для отчётов донорам.

4.3. Требования к видам обеспечения

4.3.1. Математическое обеспечение

Алгоритмы 100-балльной скоринговой системы оценки школ (модель KoboToolbox) с конфигурируемыми весами.
Алгоритмы матрицы приоритизации обращений «срочно/важно».
Алгоритмы агрегирования показателей по уровням управления.
Алгоритмы прогнозирования сроков завершения работ.
Алгоритмы перцептивного хэширования для обнаружения дубликатов фото.

Требования к работе с финансовыми данными:

Основная валюта платформы: доллар США (USD), поскольку финансирование Joint Programme в USD.
Поддерживаемые дополнительные валюты: узбекский сум (UZS) — для отображения сумм в национальной валюте на публичном портале и в отчётах для МДшО.
Точность хранения: 4 знака после запятой для USD, 2 знака для UZS. Хранение в типе DECIMAL (не FLOAT), чтобы избежать ошибок округления.
Курсы валют: ежедневная синхронизация с курсом ЦБ Республики Узбекистан. Курс фиксируется на дату операции (для платежа — дата платежа, для отчёта — дата генерации).
Округление: банковское округление (round half to even) для всех вычислений.
Формат отображения:
- USD: «$ 1,234.56» или «USD 1 234.56» (в зависимости от локали).
- UZS: «1 234 567 сум» (без копеек, с группировкой тысяч).
Конвертация: для исторических данных всегда показывается оригинальная валюта; конвертация — опциональная функция для удобства восприятия.
Аудит финансовых операций: каждая операция с деньгами фиксируется в журнале M18 с обоими значениями (валюта операции + USD на дату).
Защита от ошибок: перед каждым финансовым действием — подтверждение пользователем с явным указанием суммы и валюты.

4.3.2. Информационное обеспечение

Модель данных описана в Приложении Е.
Полный перечень справочников — в Приложении Е.
Требования к структурам обмена — Приложение Ж.

Жизненный цикл данных:

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

Сущность	Активная фаза	Архивация	Удаление
School	до перевода в archived	при переводе в archived (закрытие школы)	никогда; только архивация
KoboAssessment	пожизненно	через 3 года после последней оценки той же школы	никогда
ProcurementEvent	до закрытия тендера	через 1 год после закрытия	никогда
Contract	до закрытия	через 1 год после закрытия	никогда
Evidence	пожизненно	через 5 лет после завершения контракта	никогда (для архивированных — экономичное хранилище)
AcceptanceAct	пожизненно	через 5 лет	никогда
Payment	пожизненно	через 7 лет (срок налогового учёта)	никогда
CitizenFeedback	до закрытия + 2 года	через 2 года после закрытия	по запросу гражданина (право на удаление)
WarrantyCase	пожизненно (до окончания гарантии)	после окончания гарантии	никогда
VideoStream	30 дней архива	старше 30 дней — автоудаление	автоматически по retention
AuditLog	10 лет	через 10 лет — в холодное хранилище	никогда

Архивация: - Активные данные — в основной БД с быстрым доступом. - Архивные данные — в отдельной БД или объектном хранилище с экономичным хранением. - Доступ к архивным данным — медленнее, но возможен.

Right to deletion: - Граждане могут запросить удаление своих PII (номер телефона, имя). - Платформа удаляет PII, оставляя обезличенные обращения (для сохранения статистики). - Запрос обрабатывается в течение 15 рабочих дней. - Невозможно удалить данные, обязательные к хранению по закону (например, факт подачи обращения для антикоррупционной статистики).

Реорганизация и переименование школ: - При переименовании сохраняется история (старое имя в архиве). - При реорганизации (слияние двух школ) данные переносятся с сохранением связей. - Никакие данные не теряются.

4.3.3. Лингвистическое обеспечение

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

Базовые требования: - Языки интерфейса: русский, узбекский (латиница), английский. - Многоязычный контент в БД (отдельные поля для каждого языка для пользовательских данных). - Локализация форматов дат, чисел, единиц. - Поддержка ввода и поиска кириллицы и латиницы.

Архитектура локализации: - Все строки интерфейса хранятся в файлах локализации (например, JSON или PO), не в исходном коде. - Каждая строка имеет уникальный ключ, под которым ссылается в коде. - При отсутствии перевода для конкретного языка — fallback на русский с пометкой «not translated».

Workflow перевода: - Подрядчик-разработчик отвечает за технический перевод базового интерфейса. - Профессиональный перевод (с грамматической и культурной экспертизой) — отдельный поток силами привлечённых переводчиков заказчика. - Workflow: разработчик передаёт строки на перевод, переводчик переводит, координатор проверяет, перевод применяется в следующем релизе. - Платформа поддерживает Translation Memory для повторного использования переводов.

Локали и форматирование:

Локаль	Дата	Число	Валюта	Часовая зона
ru-UZ	20.06.2026	1 234,56	1 234,56 USD	Asia/Tashkent
uz-UZ (Latin)	20.06.2026	1 234,56	1 234,56 USD	Asia/Tashkent
en-UZ	June 20, 2026	1,234.56	USD 1,234.56	Asia/Tashkent
en-US (для международных отчётов)	06/20/2026	1,234.56	$1,234.56	UTC

Поддержка узбекского языка: - На текущем этапе — узбекская латиница (государственная норма). - На фазе масштабирования возможна также поддержка узбекской кириллицы — при необходимости легко добавляется через дополнительный язык в архитектуре.

Поиск и сортировка: - Поиск независимо от регистра. - Сортировка с учётом правил конкретного языка (Collation). - Возможность поиска по транслитерации (например, ввод латиницей находит результаты в кириллице).

Пользовательский контент: - Пользователи могут вводить контент на любом языке. - Платформа автоматически определяет язык введённого текста (например, с помощью Cloud Translation API). - Возможность автоперевода контента для других пользователей (если они выбрали другой язык интерфейса) с пометкой «Auto-translated». Машинный перевод опционален и по умолчанию отключён для контента, содержащего ПДн (телефоны, ФИО, паспортные данные, фото лиц, медицинские/семейные сведения), а также для содержимого формальных обращений (M11.F5 «formal_appeal»). Включение автоперевода для таких категорий допустимо только при наличии правового основания и письменного согласования с владельцем данных (МДшО) и UNDP_INTEGRITY. Использование внешних cloud-сервисов перевода для контента с ПДн запрещено без подписанного DPA и соответствия ЗРУ-1125. По умолчанию автоперевод применяется только к публичному обезличенному содержимому (паспорта школ, тендерная документация, метаданные).

4.3.4. Программное обеспечение

Архитектурный стиль: микросервисы или модульный монолит (с обоснованием).
Рекомендуемый стек: .NET + Angular.
Контейнеризация: Docker/OCI; оркестрация: Kubernetes.
CI/CD с автоматизированным тестированием.
Статический анализ кода (SonarQube или аналог).
Software Composition Analysis (Snyk / Dependabot).
Покрытие unit-тестами: ≥70% backend, ≥50% frontend.

4.3.5. Техническое обеспечение

Расчёт инфраструктуры для пилота и масштабирования — Приложение Р.

4.3.6. Метрологическое обеспечение

Точность геокоординат: не хуже 6 знаков после запятой (~10 см на местности).
Точность временных меток: не хуже 1 секунды (NTP).

Требования к работе со временем:

Часовая зона хранения: все timestamps в БД хранятся в UTC.
Часовая зона отображения: Asia/Tashkent (UTC+5) по умолчанию, с возможностью переопределения пользователем в настройках профиля.
Серверы синхронизированы с NTP — точность ≤ 1 секунды.
Рабочие дни и часы: учитываются государственные праздники Республики Узбекистан (загружаются в справочник, обновляются ежегодно). Стандартные рабочие часы 09:00–18:00 в Tashkent. SLA рассчитываются с учётом этого.
Религиозные праздники: учитываются Курбан-байрам, Рамазан-хайит (даты ежегодно обновляются администратором).
Високосные годы и DST: платформа корректно обрабатывает 29 февраля. Узбекистан не применяет переход на летнее время, но интеграции с системами, использующими DST (если такие будут), должны корректно обрабатывать переход.
Исторические даты: платформа корректно работает с датами в прошлом (для гарантий, начинающихся 5 лет назад) и в будущем (планы на 2030+).
Часовая зона в API: все timestamps в API в формате ISO 8601 с указанием часовой зоны (например, «2026-06-20T14:30:00+05:00»).
Локализация формата даты:
- RU: «20.06.2026», «20 июня 2026»
- UZ Latin: «20.06.2026», «2026-yil 20-iyun»
- EN: «June 20, 2026», «2026-06-20»
Серверы и клиенты: все клиенты получают timestamps в UTC, локализация только для отображения.

4.3.7. Организационное обеспечение

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

Базовые регламенты: - Регламенты администрирования платформы. - Регламенты управления учётными записями и доступом. - Регламенты управления инцидентами. - Регламенты резервного копирования. - Регламенты управления изменениями.

Мониторинг для эксплуатационной команды: - Дашборд состояния системы в реальном времени: статус сервисов, нагрузка, ошибки, очереди. - Метрики уровня бизнеса: количество активных пользователей сейчас, обращений за последний час, выплат за день. - Метрики уровня инфраструктуры: CPU/RAM/Disk на серверах, latency БД, пропускная способность сети. - Алерты с настраиваемыми порогами и каналами доставки (email, SMS, Slack, PagerDuty).

Runbooks для типовых инцидентов: - Падение БД: как диагностировать, как переключиться на реплику, как восстановить. - DDoS-атака: как идентифицировать, как активировать защиту. - Заполнение диска: как очистить, как добавить. - Утечка PII: процедура реагирования (см. Приложение Ю). - Сбой интеграции: процедура для каждой внешней системы. - Подозрительная активность: что проверить, кого уведомить.

Развёртывание: - CI/CD pipeline с автоматизированным тестированием перед деплоем. - Canary deployment: новая версия сначала на 10% трафика, при отсутствии проблем — на 50%, затем на 100%. - Feature flags для постепенного включения новых функций. - Возможность отката (rollback) в production в течение 5 минут. - Развёртывание в нерабочее время для критических изменений. - Maintenance window: ежемесячное плановое окно для регламентных работ.

Логирование: - Centralized logging (ELK или эквивалент). - Retention: 90 дней для оперативных логов, 7 лет для аудит-логов M18. - Поиск по логам. - Алерты по паттернам в логах.

Service Level Objectives для эксплуатационной команды: - Время реакции на P1-инцидент: 15 минут. - Время восстановления при P1: ≤ 4 часов (RTO). - Время восстановления при P2: ≤ 12 часов. - Время на изменение конфигурации (без рестарта): ≤ 30 минут. - Время на деплой минорной версии: ≤ 1 час.

4.3.8. Методическое обеспечение

Руководства пользователей по каждой роли.
Руководства администраторов.
Учебные материалы (текст, видео).
Интерактивные туторы внутри платформы.

4.3.9. Требования к хостингу и инфраструктуре

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

Базовые требования: - Размещение в Республике Узбекистан: для соответствия требованиям защиты данных и упрощения handover МДшО. Допустимое исключение — резервная DR-площадка в стране ОЭСР с соответствующим соглашением о передаче данных. - Тип развёртывания: Infrastructure-as-a-Service (IaaS) или Private Cloud. Public Cloud (AWS, Azure, GCP) допустим только при условии размещения в регионе РУз и соответствия требованиям защиты данных. - Рекомендуемая опция: Узинфоком — государственный оператор корпоративных ИС, имеющий инфраструктуру в Республике, опыт работы с государственными системами, готовность к долгосрочной поддержке после handover МДшО. Это рекомендация заказчика, не обязательное требование.

Архитектура развёртывания: - Основная площадка (Primary): в Республике Узбекистан. - Резервная площадка (DR): территориально удалённая (>100 км от основной), желательно в другом ЦОД или регионе. - Backup-площадка для хранения архивов: отдельная инфраструктура для хранения долгосрочных архивов и журнала аудита.

Требования к инфраструктуре: - Доступность ЦОДа: Tier III как минимум (99.982% SLA на инфраструктуру). - Резервное питание: двойной ввод питания, ИБП, дизель-генератор. - Охлаждение: N+1 резервирование. - Связь: минимум два независимых провайдера интернета с автоматическим переключением. - Физическая безопасность: видеонаблюдение, контроль доступа, охрана 24/7.

Бюджет: - На стадии эскизного проектирования подрядчик предлагает несколько вариантов хостинга с расчётом TCO (Total Cost of Ownership) на 3 и 5 лет. - Стоимость инфраструктуры покрывается либо UNDP (на период разработки и пилота), либо МДшО (после handover) — это решение фиксируется на стадии Фазы 0.

Передача после handover: - Полная документация инфраструктуры передаётся МДшО. - Платформа должна быть портируемой — при необходимости МДшО должно иметь возможность мигрировать на другую инфраструктуру без переписывания платформы. - Использование стандартных технологий (Kubernetes, PostgreSQL, S3-совместимое хранилище) обеспечивает портируемость.

4.3.10. Жизненный цикл инфраструктуры

DEV среда: для разработчика, минимальная мощность, без резервирования.
TEST среда: для QA, с тестовыми данными.
STAGING среда: копия PROD с обезличенными данными для финального тестирования.
UAT среда: для опытной эксплуатации с реальными ограниченными данными.
PROD среда: промышленная эксплуатация с полным резервированием.
DR среда: Disaster Recovery, активная при сбое PROD.

Все среды кроме PROD/DR могут быть в одном ЦОД для экономии. PROD и DR — обязательно в разных ЦОД.

5. Состав и содержание работ по созданию информационной системы

Этот раздел — критически важный, поскольку отвечает не на вопрос «что должна делать платформа» (это раздел 4), а на вопрос «как именно подрядчик должен её создавать, в какой последовательности, какие промежуточные результаты сдавать заказчику и за что получать оплату».

Государственный стандарт O’z DSt 1986:2018 устанавливает восемь обязательных стадий создания информационной системы. Подрядчик-разработчик обязан выполнить все стадии в указанной последовательности. Перескакивание стадии (например, попытка начать рабочую документацию без сданного технического проекта) запрещено и является основанием для приостановки контракта. Каждая стадия завершается сдачей пакета документации заказчику и его согласованием; только после согласования стадии подрядчик имеет право переходить к следующей и получать соответствующую оплату.

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

5.1. Стадии создания и их содержание

В соответствии со стандартом O’z DSt 1986:2018, создание информационной системы проходит восемь обязательных стадий. Первые три стадии (формирование требований, разработка концепции, техническое задание) уже выполнены силами заказчика и его консультантов. Подрядчик-разработчик отвечает за выполнение стадий 4–8.

5.1.1. Стадия 1. Формирование требований к ИС — выполнено заказчиком

Стадия выполнена в рамках Stage 1 контракта Business Analyst, результатом стал отчёт AS-IS Analysis Report v1.7 от 18.06.2026. Подрядчик-разработчик принимает результаты этой стадии как данность и не имеет права оспаривать обоснованность сформулированных требований — для этого был отдельный этап обследования. Если в ходе разработки обнаружатся обстоятельства, которые не были видны на стадии формирования требований (например, выяснится, что некая внешняя система не предоставляет необходимые API), такие обстоятельства фиксируются как риски в реестре проекта (Приложение У) и обрабатываются через процесс управления изменениями (Приложение Х).

5.1.2. Стадия 2. Разработка концепции ИС — выполнено заказчиком

Стадия выполнена в рамках Stage 2 контракта Business Analyst, результатом стала концепция To-Be Concept Note v5.2 от 18.06.2026. Концепция фиксирует принципиальные архитектурные решения (базовые 19 модулей, ролевая модель, фазы развития, интеграции); настоящая редакция ТЗ дополнительно выделяет M20 как операционный модуль отчётности и экспорта. Подрядчик-разработчик обязан реализовать систему в соответствии с концепцией; отклонения возможны только в части способа реализации (выбор стека, конкретные технические решения), но не в части скоупа и логики системы.

5.1.3. Стадия 3. Техническое задание — выполнено заказчиком (настоящий документ)

Настоящее ТЗ является результатом третьей стадии. Дальнейшие стадии выполняет подрядчик-разработчик.

5.1.4. Стадия 4. Эскизный проект — выполняет подрядчик-разработчик

Назначение. Эскизный проект (ЭП) переводит требования ТЗ в высокоуровневые проектные решения. На этой стадии подрядчик принципиально определяет, каким именно образом будет реализована система, не погружаясь в детали реализации каждой функции. Цель ЭП — дать заказчику возможность увидеть и согласовать архитектурную канву до того, как начинается дорогостоящая стадия детального проектирования.

Состав работ: 1. Разработка общей архитектуры системы с обоснованием выбора архитектурного стиля (микросервисы / модульный монолит / смешанный подход) и обоснованием выбора технологического стека (применительно к рекомендации заказчика по стеку .NET + Angular либо обоснованное предложение альтернативы). 2. Высокоуровневое описание каждого из 20 модулей с указанием их назначения, основных функций, входов/выходов и связей. 3. Высокоуровневая модель данных с указанием ключевых сущностей и связей между ними (концептуальная ER-модель). 4. Архитектура интеграций с внешними системами (UN Quantum, Замонавий мактаб, видеомониторинг, шлюз SMS, электронная подпись). 5. Архитектура развёртывания (среды DEV / TEST / STAGING / UAT / PROD / DR) и подход к контейнеризации. 6. Концептуальные решения по обеспечению безопасности (RBAC, шифрование, аудит, защита от атак). 7. Решение по локализации (русский, узбекский, английский). 8. Макеты пяти-восьми ключевых экранов (главная страница публичного портала, страница школы, дашборд директора, экран загрузки фотоотчёта, экран обращения через QR) — на уровне wireframe. 9. Перечень рисков с описанием митигации.

Артефакты для сдачи заказчику: - Документ «Эскизный проект платформы МБШ» (объёмом не менее 60 страниц с диаграммами). - Архитектурные диаграммы в нотации C4 (уровни Context и Container) или эквивалентной. - Концептуальная ER-модель. - Wireframe-макеты ключевых экранов в редактируемом формате (Figma, Sketch или эквивалент) и в формате PDF. - Презентация результатов эскизного проектирования (45–60 минут).

Критерии приёмки стадии: - Соответствие архитектуры всем 10 принципам проектирования (раздел 2.3). - Реалистичность реализации в рамках утверждённых сроков и бюджета. - Полнота покрытия всех 20 модулей. - Корректная проработка всех интеграций. - Прохождение защиты эскизного проекта на совместном совещании заказчика, UNDP, МДшО.

Продолжительность стадии: 4–6 недель.

Привязка к оплате: 10% от стоимости контракта по подписании акта стадии «Эскизный проект».

Невыполнение стадии: Запрет на переход к стадии «Технический проект» до устранения замечаний. Полное отклонение эскизного проекта может являться основанием для расторжения контракта.

5.1.5. Стадия 5. Технический проект — выполняет подрядчик-разработчик

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

Состав работ: 1. Детальная архитектура каждого микросервиса / модуля с описанием интерфейсов, протоколов, форматов сообщений. 2. Полная физическая модель данных (DDL-скрипты для всех таблиц, индексы, ограничения, миграции). 3. Полные спецификации API в формате OpenAPI 3.0 для всех публикуемых endpoints (внутренних и внешних). 4. Детальные сценарии использования (use cases) с экранами — не менее всех 48 сценариев из Приложения А. 5. Полная матрица RBAC с указанием конкретных permission для каждой роли (как описано в Приложении Б и Приложении М). 6. Детальные регламенты информационной безопасности (управление ключами, шифрование, аутентификация, авторизация, аудит). 7. Спецификация клиентских каналов M10 (адаптивный веб/PWA и Telegram MiniApp) с экранами и пользовательскими сценариями. 8. Детальные технические спецификации интеграций (по каждой системе — endpoints, авторизация, обработка ошибок, ретраи). 9. План развёртывания (CI/CD, инфраструктура, конфигурация). 10. План тестирования (по приложению Н). 11. План миграции данных (по приложению П).

Артефакты для сдачи заказчику: - Документ «Технический проект платформы МБШ» (объёмом не менее 250 страниц). - Полная техническая документация по каждому модулю (отдельные документы M1–M20). - Архитектурные диаграммы C4 уровней Component и Code для критических модулей. - OpenAPI-спецификации в формате Swagger. - DDL-скрипты модели данных. - Прототип пользовательского интерфейса (Figma / интерактивный mockup), охватывающий все ключевые сценарии. - Презентация результатов технического проектирования (8 часов в формате воркшопа с заказчиком).

Критерии приёмки стадии: - Полное покрытие функциональных требований раздела 4.2 настоящего ТЗ. - Полное покрытие нефункциональных требований раздела 4.1. - Реалистичность реализации в рамках утверждённых сроков. - Соответствие десяти принципам проектирования. - Положительные результаты внутреннего архитектурного ревью.

Продолжительность стадии: 8–12 недель (выполняется параллельно с началом разработки прототипа).

Привязка к оплате: 15% от стоимости контракта по подписании акта стадии «Технический проект».

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

5.1.6. Стадия 6. Рабочая документация — выполняет подрядчик-разработчик

Назначение. На этой стадии создаётся сам программный продукт и сопровождающая его рабочая документация. Стадия покрывает основную часть фаз 1–3 пилотного проекта (см. подраздел 5.2). Это самая продолжительная стадия по времени и самая ресурсоёмкая по стоимости.

Состав работ: 1. Разработка backend и frontend компонентов в соответствии с техническим проектом. 2. Реализация всех интеграций. 3. Разработка адаптивного веб-клиента, PWA-сценариев и Telegram MiniApp. 4. Реализация всех видов тестов согласно плану тестирования (приложение Н). 5. Прохождение внутренних архитектурных ревью каждые 2 недели. 6. Создание рабочей документации: руководства пользователей по ролям, руководства администраторов, регламенты эксплуатации, регламент информационной безопасности, регламент резервного копирования, программа и методика испытаний. 7. Сборка контейнерных образов и помещение их в реестр. 8. Развёртывание системы в средах DEV / TEST / STAGING / UAT. 9. Поэтапная демонстрация работающих модулей заказчику (минимально — каждые 4 недели).

Артефакты для сдачи заказчику: - Исходный код всей системы (репозиторий в системе контроля версий с историей). - Контейнерные образы. - Скрипты развёртывания (Helm charts, Terraform, Ansible или эквивалент). - Полный комплект рабочей документации в форматах PDF и редактируемых форматах (DOCX, MD). - Демонстрация всех 20 модулей на средах STAGING / UAT. - Отчёты по тестированию (unit, integration, E2E, performance, security).

Критерии приёмки стадии: - Полная реализация функциональности всех 20 модулей. - Все сквозные сценарии (48+) проходят успешно. - Все NFR из подраздела 4.1.11 подтверждены тестами. - Покрытие unit-тестами не менее 70% backend и 50% frontend. - Отсутствие критических и высоких дефектов в реестре дефектов. - Прохождение внешнего пентеста с устранением всех критических и высоких уязвимостей.

Продолжительность стадии: 8–12 месяцев (фазы 1–3 проекта).

Привязка к оплате: 40% от стоимости контракта, распределяется по подэтапам — по 10% на завершение каждой из четырёх MVP-итераций.

Невыполнение стадии: Запрет на переход к стадии «Ввод в действие». Невыполнение существенной части — основание для расторжения контракта.

5.1.7. Стадия 7. Ввод в действие — выполняет подрядчик-разработчик

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

Состав работ: 1. Развёртывание системы в среде PRODUCTION. 2. Миграция данных по плану из Приложения П (импорт паспортов школ, оценок Kobo, справочников). 3. Создание учётных записей всех ключевых пользователей. 4. Подготовка и проведение обучения персонала по плану из Приложения С (от директоров школ до администраторов платформы). 5. Запуск опытной эксплуатации продолжительностью не менее 60 календарных дней с участием не менее пяти пилотных школ. 6. Сбор обратной связи от пользователей и устранение замечаний. 7. Проведение приёмочных испытаний по программе и методике (создаётся подрядчиком на стадии 6). 8. Подписание акта ввода в эксплуатацию.

Артефакты для сдачи заказчику: - Развёрнутая работающая платформа в среде PRODUCTION. - Отчёт о миграции данных. - Отчёт о проведении обучения с указанием обученного персонала. - Отчёт об опытной эксплуатации с реестром выявленных и устранённых дефектов. - Протоколы приёмочных испытаний. - Акт ввода в эксплуатацию.

Критерии приёмки стадии: - Опытная эксплуатация завершена без критических дефектов. - Доля устранённых замечаний высокой и средней категории — не менее 95%. - Подтверждение соответствия SLA на основании результатов опытной эксплуатации. - Обучение завершено с положительной оценкой не менее 80% обученного персонала.

Продолжительность стадии: 3–4 месяца (фазы 3–4 проекта).

Привязка к оплате: 20% от стоимости контракта по подписании акта ввода в эксплуатацию.

5.1.8. Стадия 8. Сопровождение ИС — выполняет подрядчик-разработчик

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

Состав работ: 1. Круглосуточная техническая поддержка с SLA согласно Приложению Т. 2. Устранение всех дефектов системы (критические — в течение 4 часов; высокие — в течение 12 часов; средние — в течение 5 рабочих дней). 3. Регулярные минор-релизы (каждые 2 недели) с исправлениями и небольшими улучшениями. 4. Мажор-релизы (каждые 3 месяца) с расширением функциональности. 5. Ежемесячные отчёты о доступности, инцидентах, выполненных работах. 6. Ежеквартальные обзоры с заказчиком. 7. Подготовка платформы к передаче институциональному владельцу (МДшО) — стадия передачи (handover) выполняется отдельно по плану.

Продолжительность стадии: не менее 12 месяцев после ввода в эксплуатацию (с возможностью продления).

Привязка к оплате: 15% от стоимости контракта распределены равномерно по месяцам сопровождения первого года.

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

Детальный план передачи платформы институциональному владельцу (МДшО) описан в подразделе 5.2.

5.2. Детальный план передачи платформы МДшО (handover)

Передача платформы институциональному владельцу — МДшО — критически важный этап, от качества которого зависит долгосрочная устойчивость инвестиций программы. Без качественного handover платформа после окончания программы UNDP может либо стать неподдерживаемой, либо потребовать привлечения внешних подрядчиков для каждого изменения.

5.2.1. Сроки и состав передачи

Handover проходит в течение последних 2 месяцев работы подрядчика (Фаза 4). За этот период:

Документация платформы передаётся МДшО в полном объёме.
Исходный код передаётся в репозиторий МДшО (с сохранением истории коммитов).
Контейнерные образы и регистр передаются.
Инфраструктура переписывается на МДшО (если ранее была на UNDP-аккаунте облачного провайдера) или передаётся доступ к существующей.
Обучение проводится для администраторов МДшО.
Знания передаются через серию workshop’ов и shadowing’а.

5.2.2. Что МДшО сможет делать самостоятельно (без программиста)

Платформа должна быть разработана так, чтобы значительная часть типичных задач решалась МДшО-администраторами без программистов:

Управление справочниками: добавление новых типов работ, регионов, ролей, шаблонов уведомлений.
Управление пользователями: добавление, изменение, отзыв учётных записей.
Настройка чек-листов: редактирование пунктов, добавление новых пунктов в чек-листы этапов.
Управление шаблонами документов: обновление шаблонов актов, отчётов.
Настройка SLA: изменение временных параметров SLA по категориям обращений.
Конфигурация интеграций: обновление endpoints, ключей при изменениях внешних систем (например, обновление credentials UN Quantum).
Расписание автогенерации отчётов.
Управление обучающими материалами.
Брендирование (логотипы, цвета).

5.2.3. Что требует обращения к разработчику

Архитектурные изменения (новые модули, существенная модификация существующих).
Изменение схемы данных.
Интеграция с новыми системами.
Исправление найденных багов в коде.
Обновление зависимостей (Open Source библиотек).
Изменения безопасности (новые угрозы, требующие обновления).

5.2.4. План обучения администраторов МДшО

Базовый курс «Введение в платформу МБШ»: 16 часов (2 рабочих дня) для всех будущих администраторов.
Углублённый курс «Администрирование МБШ»: 40 часов (5 рабочих дней) для основных администраторов.
Расширенный курс «Эксплуатация и оптимизация»: 80 часов (10 рабочих дней) для технических администраторов с практической работой.
Сертификация: после прохождения курсов — сертификация навыков. Без сертификации — не допуск к работе в production.

5.2.5. Документация для handover

Полная техническая документация (архитектура, модель данных, API).
Руководство администратора (детальное, со скриншотами).
Руководства пользователей (по ролям).
Runbooks для типовых инцидентов.
Регламент эксплуатации.
Регламент управления изменениями.
Регламент резервного копирования.
Регламент безопасности.
Описание интеграций и их особенностей.
Перечень используемых Open Source компонентов с лицензиями.
Контакты разработчиков для гарантийной поддержки.

5.2.6. Гарантийная поддержка после handover

После handover МДшО получает от подрядчика гарантийную поддержку на 12 месяцев: - Исправление критических дефектов. - Консультации администраторов МДшО. - Обновления безопасности. - При необходимости — командировки специалистов для разрешения сложных инцидентов.

Условия гарантийной поддержки фиксируются в отдельном контракте между МДшО и подрядчиком (по согласованию с UNDP).

5.3. Фазы пилотного проекта

Фаза	Содержание	Продолжительность
Фаза 0	Подготовительная: выбор разработчика, согласование архитектуры, юридические согласования	1 месяц
Фаза 1	MVP: реализация M1, M2, M3, M5, M9, M11, M18	4 месяца
Фаза 2	Расширение: реализация остальных модулей, интеграции UN Quantum + Замонавий мактаб	5 месяцев
Фаза 3	Масштабирование: подключение 45 пилотных школ, опытная эксплуатация	4 месяца
Фаза 4	Передача институциональному владельцу МДшО	2 месяца

5.4. Состав работ по фазам

5.3.1. Фаза 0 — Подготовительная

Согласование архитектурного решения с заказчиком.
Решение по хостингу (рекомендация: Узинфоком; окончательное — за заказчиком).
Согласование институциональной модели handover МДшО.
Утверждение детального плана работ.

5.3.2. Фаза 1 — MVP

Реализация инфраструктуры (Kubernetes, БД, шлюзы).
Реализация модулей M1, M2, M3, M5, M9, M11, M18.
Интеграция с UN Quantum (базовый функционал).
Интеграция с Замонавий мактаб (ручная выгрузка Excel).
Интеграция со шлюзом SMS.
Базовый адаптивный веб/PWA + Telegram MiniApp для полевых сценариев.
Базовый публичный портал.
Демонстрация MVP с 3–5 пилотными школами.

5.3.3. Фаза 2 — Расширение

Реализация всех остальных модулей.
Интеграция видеомониторинга (MikroTik + WireGuard).
Расширенная аналитика и дашборды.
Подключение Integrity Pacts.
Расширенный адаптивный веб/PWA + Telegram MiniApp для всех предусмотренных полевых ролей.
Полная функциональность публичного портала.

5.3.4. Фаза 3 — Масштабирование

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

5.3.5. Фаза 4 — Передача

Передача исходного кода МДшО.
Передача документации в полном объёме.
Обучение персонала МДшО.
План масштабирования на 11 127 школ Республики.
Подписание акта передачи.

5.5. Контрольная матрица готовности ТЗ к разработке

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

Матрица должна отдельно фиксировать государственные ограничения: OneID/SSO, E-IMZO/eMZO, SMS-OTP, запрет социальных логинов и потребительских аутентификаторов, хранение персональных данных, регистрацию базы ПДн, кибербезопасность, интеграции с государственными системами и требования к передаче платформы институциональному владельцу.

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

6. Порядок контроля и приёмки информационной системы

Этот раздел описывает, как именно заказчик контролирует ход работ и принимает их результаты. Контроль и приёмка — это не разовое событие в конце проекта, а сквозной процесс, проходящий через все восемь стадий создания ИС (раздел 5). На каждой стадии заказчик имеет право и обязанность проверить выполненные работы и принять или отклонить их. Раздел дополняется Приложением Н (Стратегия и план тестирования) и Приложением Т (Расширенное соглашение об уровне обслуживания), которые описывают детальные процедуры тестирования и обязательства подрядчика по доступности и качеству поддержки.

6.1. Виды испытаний

Предварительные испытания — после завершения каждого модуля.
Опытная эксплуатация — продолжительностью не менее 60 календарных дней с участием не менее 5 пилотных школ.
Приёмочные испытания — финальная демонстрация всей функциональности.

6.2. Состав приёмочных комиссий

6.2.1. Комиссия по приёмке этапов

Представитель UNDP Country Office (председатель).
Представитель UNICEF.
Представитель МДшО.
Независимый технический эксперт.

6.2.2. Финальная приёмочная комиссия

Все участники этапной комиссии.
Представитель ACA.
Представитель CSAC.
Представитель Узинфоком (при подключении к Замонавий мактаб).

6.3. Критерии приёмки

6.3.1. Критерии приёмки по модулям

(для каждого модуля M1–M20 — конкретные тестируемые критерии)

6.3.2. Критерии приёмки сквозных сценариев

UC-01: подрядчик загружает фотоотчёт за 60 секунд, валидация проходит автоматически, технадзор видит в ленте.
UC-02: родитель проходит путь от QR до подтверждённого обращения за 5 минут включая получение SMS.
UC-03: инспектор ГАСН находит и просматривает фрагмент архива за 30 секунд.
UC-04: заместитель хокима видит дашборд региона со всеми школами за 2 секунды.

6.3.3. Критерии приёмки нефункциональных требований

Нагрузочное тестирование 1000 одновременных пользователей с временами отклика по SLA.
Стресс-тест 5000 одновременных пользователей — деградация без отказа.
Пентест без обнаружения уязвимостей выше Medium.
Прохождение 3 этапов кибер-экспертизы.

6.3.4. Критерии приёмки документации

API полностью документирован в OpenAPI.
Архитектура в C4 уровней 1-3.
Руководства пользователей по каждой роли.
Руководства администраторов.
Регламенты эксплуатации.

6.3.5. Критерии финальной приёмки платформы

Все модули M1–M20 реализованы и приняты по критериям модулей.
Все 4 сквозных сценария проходят демонстрацию.
Все нефункциональные требования подтверждены тестами.
Документация полная.
Опытная эксплуатация в течение 60 дней с участием не менее 5 школ пилота показала отсутствие критических дефектов.

СОПУТСТВУЮЩИЕ ДОКУМЕНТЫ (составляются параллельно)

Приложение А. Полный каталог Use Cases (40+ сценариев).
Приложение Б. Полная матрица RBAC (все роли × все модули × все действия).
Приложение В. Полная модель данных (ER + словарь полей).
Приложение Г. Полная спецификация интеграций (по каждой системе).
Приложение Д. Чек-листы этапов работ по типам пакетов.
Приложение Е. Шаблоны актов и Далолатнамы.
Приложение Ж. Каталог уведомлений.
Приложение З. Спецификация требований к видеомониторингу (детально).
Приложение И. Договорные требования к подрядчикам строительных работ (отдельный документ).
Приложение К. Критерии оценки тендерных предложений разработчиков.

7. Требования к подготовке информационной системы к вводу в действие

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

7.1. Преобразование входной информации

Импорт паспортов школ из Замонавий мактаб.
Импорт оценок из KoboToolbox.
Импорт справочников.
Миграция сценариев из Stage 2 как стартовое наполнение.

Параллельная работа со старой системой (Excel-таблицы и неформальные процессы):

В момент запуска платформы существуют ещё активные процессы вне неё — координаторы программы продолжают работать с Excel-таблицами, региональные органы используют свои реестры, КРУ ведёт бумажный аудит. Резкий переход неосуществим.

Стратегия параллельной работы:

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

Подрядчики и технадзор — с первого дня (это новые процессы, не было альтернативы).
Координаторы UNDP — с первого месяца.
Региональные органы МДшО — со второго месяца.
КРУ и ГАСН — с третьего месяца.

Cutover: через 3 месяца — официальное завершение параллельной работы. Все процессы только в платформе. Старая Excel-инфраструктура остаётся как архив, но новые данные туда не вносятся.
Rollback (на крайний случай): если в течение параллельного периода обнаружатся критические проблемы платформы, может быть принято решение о возврате к старой системе на период исправления. Все данные платформы при этом архивируются для последующего переноса.

Управление коммуникацией: - Координаторы программы проводят регулярные встречи с пользователями для сбора обратной связи. - Хелп-деск с увеличенной поддержкой в первые 3 месяца. - Обучающие материалы на видео для самообучения. - Ответы на типичные вопросы (FAQ) — внутри платформы, не как отдельный раздел, а как контекстные подсказки.

7.2. Подготовка персонала

Обучение по ролям.
Сертификация ключевых пользователей.
Создание сети тренеров (train-the-trainers).
Поддержка пользователей в период опытной эксплуатации.

7.3. Опытная эксплуатация

Период не менее 60 календарных дней.
Состав участников: не менее 5 пилотных школ, ключевые подрядчики, все категории государственных пользователей.
Критерии завершения:
- Отсутствие критических дефектов.
- Доля устранённых замечаний высокой и средней категории — не менее 95%.
- Подтверждение соответствия SLA.
- Подписанный финальный акт.

8. Требования к документированию

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

8.1. Состав документации

Документ	Назначение
Технорабочий проект	Архитектурное и проектное описание
Описание программы	Описание реализованного ПО
Текст программы	Исходный код с комментариями
Описание применения	Руководство по использованию
Руководства пользователей по ролям	Для каждой категории пользователей
Руководства администраторов	Для платформенных администраторов
Регламент эксплуатации	Эксплуатационные процедуры
Регламент информационной безопасности	Меры защиты и реагирования
Регламент резервного копирования	Процедуры backup и restore
Программа и методика испытаний	Тесты приёмки
Документация API	OpenAPI 3.0
Архитектурная документация	C4 уровни 1–3

8.2. Требования к оформлению

Языки: русский (основной), узбекский (латиница), английский.
Электронные версии в форматах PDF и редактируемых форматах (DOCX, MD).
Документация API — Swagger UI с интерактивной песочницей.

Приложения

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

Назначение каждого приложения и связь с основной частью документа:

Приложение А — Каталог пользовательских сценариев. Содержит 48 сквозных сценариев использования системы различными категориями пользователей. Каждый сценарий описан с указанием действующего лица, предусловия, триггера, основного потока действий, альтернативных потоков и постусловия. Подрядчик обязан реализовать каждый сценарий и продемонстрировать его на приёмочных испытаниях. Дополняет раздел 4.2.2.
Приложение Б — Полная матрица RBAC. Содержит детальные разрешения по каждой из 29 ролей пользователей и каждому из 20 модулей платформы. Эта матрица — основа реализации ролевой модели доступа; её фрагменты приведены в подразделе 4.2.1. Полная Excel-таблица 29×20×7 поставляется отдельным файлом.
Приложение В — Расширенная модель данных. Содержит полное описание двадцати ключевых сущностей системы с указанием всех полей, типов, связей и справочников. На этой модели строится физическая схема базы данных. Дополняет раздел 4.3.2.
Приложение Г — Спецификация интеграций. Содержит детальные спецификации интеграций с десятью внешними системами (UN Quantum, Замонавий мактаб, видеомониторинг, Шафофф, АИС «Капитал қурилиш», Геопортал АСР, ГАСН, шлюз SMS, электронная подпись, Open ID). Для каждой интеграции указаны endpoints, методы, форматы, авторизация, частота, обработка ошибок. Дополняет подраздел 4.1.2 и каждый модуль, использующий внешнюю систему.
Приложение Д — Чек-листы этапов работ по типам пакетов. Содержит детальные чек-листы для пяти типов строительных работ (общестрой, тепловые насосы, септик, материалы, ПСД). Эти чек-листы реализованы в платформе как стартовое содержимое справочника и используются для проверки выполнения работ подрядчиками. Дополняет описание модуля M12.
Приложение Е — Шаблоны актов и Далолатнамы. Содержит шаблоны пяти ключевых документов: этапный акт, финальная Далолатнома (по ШНК 3.01.04-19), акт закрытия контракта, отчёт по гарантийному случаю, отчёт о сезонном обслуживании. Шаблоны реализуются в платформе как готовые формы для автоматической генерации документов. Дополняет описание модуля M12.
Приложение Ж — Каталог уведомлений. Содержит каталог 30 типов уведомлений с указанием события-триггера, получателя, канала доставки и шаблона текста. Этот каталог — основа функционирования модуля M17. Реализуется как стартовое содержимое справочника шаблонов уведомлений.
Приложение З — Техническая спецификация видеомониторинга. Содержит детальные технические спецификации видеомониторинга стройплощадок: архитектура, требования к камерам, требования к MikroTik-маршрутизаторам, конфигурация WireGuard VPN, конфигурация NAT, регистрация камер, хранение видео, доступ, мониторинг доступности. Дополняет описание модуля M6.
Приложение И — Договорные требования к подрядчикам строительных работ. Ссылка на сопутствующий документ с 16 договорными блоками для строительных подрядчиков; платформа технически поддерживает исполнение этих договорных обязательств через модули M5, M6, M9, M11, M13, M16.
Приложение К — Критерии оценки тендерных предложений на разработку. Содержит критерии оценки предложений от подрядчиков-разработчиков на разработку платформы (1000 баллов: 700 технические + 300 финансовые). Используется заказчиком при проведении конкурса.
Приложение Л — Глоссарий терминов. Содержит расшифровки терминов и аббревиатур на русском и узбекском языках. Используется для устранения неоднозначностей при чтении документа.
Приложение М — Расширенный перечень ролей и их ответственностей. Содержит детальные описания каждой из 29 ролей пользователей с пояснениями функциональных задач, типичных сценариев работы. Дополняет компактную матрицу из Приложения Б.
Приложение Н — Стратегия и план тестирования. Содержит описание двенадцати видов тестирования (от unit до accessibility), метрик качества и критериев готовности к следующим стадиям. Подрядчик обязан реализовать программу тестирования в соответствии с этим приложением и оформить программу и методику испытаний по форме O’z DSt.
Приложение О — Архитектура развёртывания и среды. Содержит описание шести сред эксплуатации (DEV/TEST/STAGING/UAT/PROD/DR), контейнерной архитектуры, конвейера CI/CD, сетевых сегментов и подхода к высокой доступности.
Приложение П — План миграции данных и начального наполнения. Содержит описание источников данных для миграции (Замонавий мактаб, KoboToolbox и др.), этапов миграции и состава начального наполнения справочников.
Приложение Р — Capacity planning. Содержит расчёт серверной инфраструктуры для пилотного режима (45 школ) и полного масштабирования (11 127 школ), а также ориентировочные бюджетные оценки.
Приложение С — План обучения и развития компетенций. Содержит план обучения восьми категорий пользователей с описанием содержания курсов, форматов и метрик.
Приложение Т — Расширенное соглашение об уровне обслуживания (SLA). Содержит детальные SLA по доступности, времени отклика, поддержке пользователей и информационной безопасности с указанием штрафов за нарушения.
Приложение У — Реестр рисков и план их митигации. Содержит топ-15 рисков проекта с указанием вероятности, влияния и плана митигации. Используется для еженедельной актуализации статуса рисков в ходе проекта.
Приложение Х — План управления изменениями. Содержит описание процедур изменения утверждённых требований в ходе разработки, включая форму Change Request и процедуры регулярных релизов.
Приложение Ц — Стратегия резервного копирования. Содержит описание пяти уровней резервирования данных, сроков хранения, целей восстановления (RTO/RPO) и защиты от ransomware.
Приложение Ч — Политика управления API. Содержит описание версионирования API, аутентификации, rate limiting, throttling и документации.
Приложение Ш — План публикации открытых данных. Содержит каталог открытых наборов данных с указанием форматов, частоты обновления и лицензии.
Приложение Щ — Диаграммы состояний ключевых сущностей. Содержит таблицы переходов между состояниями для семи ключевых сущностей платформы (School, Contract, ContractMilestone, AcceptanceAct, Payment, CitizenFeedback, WarrantyCase). Подрядчик-разработчик обязан реализовать каждое состояние и каждый переход в полном соответствии.
Приложение Э — Требования к пользовательскому интерфейсу и UX. Содержит дизайн-систему, информационную архитектуру, требования к 20 ключевым wireframes, требования к Telegram MiniApp и адаптивному вебу. Дополняет подраздел 4.1.6.
Приложение Ю — Детальные требования к информационной безопасности. Содержит парольную политику, управление сессиями, MFA, классификацию данных, регламент реагирования на инциденты. Дополняет подраздел 4.1.5.

Приложение А — КАТАЛОГ ПОЛЬЗОВАТЕЛЬСКИХ СЦЕНАРИЕВ

Это приложение — практическое продолжение раздела 4.2 основного документа. Если раздел 4.2 описывает модули платформы (что должно быть реализовано), то Приложение А показывает, как именно пользователь работает с реализованной функциональностью. Каждый сценарий — это шаг за шагом сквозной путь конкретного действующего лица к достижению конкретной цели через интерфейсы платформы.

Зачем сценарии важны. Подрядчик-разработчик может реализовать каждый модуль отдельно технически корректно, но если сценарии работы пользователей через них неудобны, лишены логики или содержат разрывы — платформа не будет использоваться. Сценарии — это контракт между заказчиком и разработчиком на уровне опыта пользователя: каждый сценарий должен быть реализуем без обращения к программисту, без чтения документации, без помощи администратора. Если пользователь, описанный в сценарии, не может выполнить указанные шаги интуитивно, реализация считается неполной.

Структура сценария. Каждый сценарий описан в едином формате: ID, название, участник (кто выполняет действие), предусловие (что должно быть верно для начала сценария), триггер (что инициирует сценарий), основной поток (последовательность шагов), альтернативные потоки (что происходит, если что-то идёт не так), постусловие (что верно после успешного завершения), бизнес-правила (ограничения и инварианты).

Девять групп. Сценарии сгруппированы по девяти функциональным областям — школы и оценки (А.1), тендеры и контракты (А.2), выполнение работ (А.3), приёмка и выплаты (А.4), общественная обратная связь (А.5), видеомониторинг (А.6), гарантия (А.7), аудит и контроль (А.8), администрирование (А.9). Группировка отражает реальный жизненный цикл проекта реновации школы — от появления школы в реестре до окончания пятилетнего гарантийного сопровождения.

Связь с критериями приёмки. На приёмочных испытаниях платформы (раздел 6) проводится демонстрация всех 48 сценариев. Сценарий считается принятым, если: (а) выполняется без ошибок и зависаний, (б) интуитивно понятен пользователю, для которого предназначен, (в) укладывается в SLA по времени отклика из подраздела 4.1.11.

Как читать сценарий. Сценарии — не должностные инструкции и не алгоритмы. Это описания живых ситуаций: родитель сканирует QR-код у школы, потому что увидел протечку крыши; подрядчик загружает фотоотчёт после рабочего дня; инспектор ГАСН ищет в архиве запись с конкретного дня по жалобе на ночные работы. Сценарий должен рассматриваться как источник проверяемых требований к ролям, данным, состояниям, интерфейсам, интеграциям, журналированию и критериям приёмки.

А.1. Группа «Школы и оценки»

UC-A01. Импорт паспорта школы из Замонавий мактаб

Сценарий. Координатор программы Joint Programme сформировал список из 45 школ, которые планируется включить в первую когорту реновации. Школы выбраны из числа уже обследованных инженерной командой UNDP+UNICEF в Кашкадарьинской и Сурхандарьинской областях. Чтобы платформа могла работать с этими школами — отображать их на карте, привязывать к ним контракты, генерировать QR-коды — нужно сначала загрузить в систему их официальные паспорта из государственного реестра. Эту задачу выполняет администратор платформы.

Участник: PLATFORM_ADMIN (администратор платформы со стороны UNDP или сертифицированного партнёра).

Предусловие: Школы существуют в государственной системе Замонавий мактаб (оператор — Узинфоком). На фазе пилота данные передаются заказчиком в виде Excel-файла, полученного из Узинфокома. На фазе масштабирования — через прямой API Замонавий мактаб (см. интеграцию И-2 в Приложении Г).

Триггер: Координатор программы передал администратору файл с данными 45 школ для импорта в платформу.

Основной поток. Администратор открывает раздел «Школы» в платформе, видит, что список школ пуст, и нажимает кнопку «Импорт». Открывается мастер импорта с пояснением, какой формат файла ожидается (национальный идентификатор школы как ключевое поле, обязательные атрибуты — название, адрес, регион, район, координаты). Администратор загружает Excel-файл, полученный от координатора. Платформа в течение нескольких секунд анализирует файл, валидирует структуру, сопоставляет поля. На экране появляется отчёт: «Готово к импорту: 43 школы; требует уточнения: 2 школы (отсутствуют координаты); пропущено: 0». Администратор видит, какие именно две школы требуют уточнения, связывается с координатором, получает недостающие данные, дополняет файл и повторяет загрузку. После успешного импорта в платформе появляются 45 записей школ — каждая со своим внутренним school_id, привязанным к национальному идентификатору. Школы становятся видимыми на карте, готовыми для дальнейших операций.

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

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

Постусловие. В платформе зарегистрированы 45 школ с актуальными базовыми атрибутами. Школы готовы к проведению инженерной оценки (UC-A03), включению в программу года (UC-A07) и созданию связанных сущностей (контрактов, фотоотчётов, обращений).

UC-A02. Создание расширенной карточки школы

Сценарий. Школа №16 Камашинского района была импортирована из Замонавий мактаб (UC-A01) с базовыми атрибутами — название, адрес, мощность 994 ученика. Но для работы программы реновации нужны дополнительные сведения, которых нет в государственном реестре: кто конкретно из координаторов UNDP курирует эту школу, кто в школе является основным контактным лицом для программы, когда планируется обследование, как выглядит школа сейчас (фотогалерея «до» — для последующего сравнения с состоянием «после»).

Участник: UNDP_PROGRAM_MANAGER (координатор программы) или REGIONAL_EDU_HEAD (начальник областного управления МДшО).

Триггер. Школа включена в программу года, нужно подготовить её к старту работ.

Основной поток. Координатор открывает карточку школы №16, переходит на вкладку «Программа». Здесь он указывает: ответственный куратор от UNDP — Джасур Курбанов (National Local Consultant, Кашкадарья); контактное лицо в школе — Зокирова Гульнара, заведующая хозяйственной частью, телефон +998-XX-XXX-XX-XX; плановая дата обследования — 03.07.2026. Под кнопкой «Загрузить фотогалерею „до”» координатор прикладывает 12 фотографий, сделанных при первом визите команды UNDP+UNICEF — общий вид школы со стороны главного входа, фасад с разных ракурсов, состояние коридоров, кабинетов, санузлов, котельной, кровли. Каждая фотография автоматически снабжается датой и геометкой. Координатор сохраняет.

Постусловие. Школа полностью подготовлена в платформе для дальнейших операций — проведения инженерной оценки (UC-A03), включения в программу года (UC-A07), привязки контрактов (UC-A09).

UC-A03. Проведение инженерной оценки школы через адаптивный веб/PWA или Telegram MiniApp

Сценарий. Бахтиёр — инженер инженерной команды UNDP+UNICEF, имеющий опыт работы с инструментом KoboToolbox. Сегодня его задача — провести обследование школы №16 Камашинского района по 122 параметрам восьми групп данных (общие сведения, отопление, электроснабжение, конструктив здания, текущее WASH, планируемое WASH, фотофиксация внутри, фотофиксация снаружи и территории). Раньше Бахтиёр заполнял такие оценки в KoboToolbox на телефоне, теперь — прямо в адаптивном веб-клиенте или Telegram MiniApp МБШ, что удобнее, поскольку оценка сразу привязывается к школе в платформе.

Участник: Оценщик — Бахтиёр, инженер UNDP+UNICEF.

Предусловие. Школа №16 зарегистрирована в платформе (UC-A01–A02), у Бахтиёра есть роль оценщика с правом проведения обследований.

Триггер. Плановое выездное обследование школы.

Основной поток. Бахтиёр приезжает в школу №16 утром в 10:00. Открывает Telegram MiniApp или адаптивный веб-интерфейс, в разделе «Оценки → Новая» выбирает школу №16 из списка. Платформа предлагает выбрать версию формы оценки — Бахтиёр выбирает актуальную «KoboToolbox v2.1». Открывается экран с группой 1 «Общие сведения»: год постройки школы, число зданий, типовой проект, состояние документации. Бахтиёр опрашивает завхоза, фотографирует обнаруженные документы, заполняет поля. Каждая фотография автоматически снабжается геометкой (платформа подтверждает: «координаты совпадают с паспортом школы») и временной меткой.

Бахтиёр переходит к группе 2 «Отопление»: тип отопления (угольный котёл), состояние котельной (требует реконструкции), радиаторы (старые, требуют замены), фотофиксация каждого элемента. Группа 3 «Электроснабжение»: тип подключения (общий трансформатор с жилым сектором), частота отключений (ежедневно по 2–3 часа), освещённость в классах (Бахтиёр измеряет люксметром — около 130 лм/м² при норме 300). Группа 4 «Конструктив»: состояние стен (трещины в одной несущей), кровля (мягкая, требует замены), полы (изношены), окна (старые деревянные, негерметичные). Группа 5 «Текущее WASH»: только наружные туалеты, водоснабжение — только подвоз грузовиками. Группа 6 «Планируемое WASH»: предлагаемые решения с фотофиксацией точек размещения санузлов и водопровода.

В обед Бахтиёр заходит в кафе в селе, нет подключения к интернету. Платформа работает в офлайн-режиме, все собранные данные сохраняются локально. Бахтиёр продолжает работу. К 16:00 все 8 групп заполнены, прикреплено 47 фотографий. Бахтиёр нажимает «Сохранить черновик» — данные сохраняются локально. Возвращается в районный центр, появляется интернет — приложение автоматически синхронизирует всё с сервером.

Вечером Бахтиёр в офисе UNDP в Карши проверяет загруженную оценку с компьютера. Все поля заполнены, фотографии на месте. Нажимает «Подать на валидацию». Оценка переходит в статус submitted и появляется в очереди валидации старшего инженера команды UNDP+UNICEF.

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

Исключения. Если оценщик пытается прикрепить фото без геометки (отключён GPS) — платформа требует подтверждения координат вручную и помечает фото как «manual_geo». Если попытаться подать на валидацию незаполненную форму — платформа указывает на конкретные пропущенные поля.

Постусловие. Оценка школы №16 находится в статусе submitted, готова к валидации (UC-A04).

UC-A04. Валидация инженерной оценки

Сценарий. Юлия — старший инженер инженерной команды UNDP+UNICEF, ответственная за качество всех проводимых оценок школ. Она получила уведомление о новой оценке, поданной Бахтиёром по школе №16. Её задача — проверить, что оценка проведена качественно, все поля заполнены правильно, фотодоказательства соответствуют заявленным параметрам, скоринг будет посчитан на достоверных данных.

Участник: Валидатор — Юлия, старший инженер UNDP+UNICEF.

Триггер. Уведомление о новой оценке в очереди валидации.

Основной поток. Юлия открывает платформу с компьютера. В разделе «Оценки → Очередь валидации» видит несколько оценок в статусе submitted. Выбирает оценку по школе №16 Камашинского района от Бахтиёра. Открывается полная карточка оценки с шестью группами параметров и 47 фотографиями.

Юлия методично проверяет каждую группу. В группе «Электроснабжение» обращает внимание на показатель освещённости 130 лм/м² — спрашивает в чате с Бахтиёром (встроенный мессенджер платформы), измерял ли он именно днём при выключенном освещении. Бахтиёр подтверждает: измерение в полдень при облачной погоде, искусственное освещение выключено. Юлия отмечает пункт как подтверждённый.

В группе «Конструктив» Юлия замечает, что фотография трещины в несущей стене сделана крупным планом, но нет общего плана для оценки масштаба. Юлия использует функцию «Замечание по пункту» — оставляет комментарий: «Прошу приложить общий план стены с трещиной для оценки масштаба и положения. Это критично для оценки риска сноса».

Юлия проходит остальные группы, всё в порядке. Принимает решение «Вернуть на доработку» с одним замечанием. Бахтиёр получает уведомление, на следующий день возвращается на школу, делает дополнительные фото, добавляет к оценке, повторно подаёт. Юлия видит обновлённую оценку, теперь подтверждает все группы. Подписывает решение электронной подписью. Оценка переходит в статус validated.

Платформа автоматически рассчитывает 100-балльный скоринг по 8 критериям. По школе №16 получается 73 балла из 100 — школа попадает в категорию «высокий приоритет реновации». Этот скоринг используется в дальнейшем при формировании программы года (UC-A06).

Постусловие. Оценка школы №16 валидирована, скоринг рассчитан, школа готова к включению в программу года.

UC-A05. Сравнение оценок «до» и «после» реновации

Сценарий. Реновация школы №15 Ангорского района завершена и принята комиссией (UC-A23). Координатор программы готовит ежегодный отчёт для донора программы (Ishonch 2030 Fund). В отчёте нужно показать конкретные результаты — что именно изменилось в каждой школе. Для этого инженерная команда провела повторное обследование школы №15 уже после реновации, и теперь координатор хочет наглядно сравнить два состояния.

Участник: UNDP_PROGRAM_MANAGER или MOPSE_OFFICER.

Основной поток. Координатор открывает карточку школы №15, переходит в раздел «Оценки». Видит две валидированные оценки: «Базовая оценка от 28.09.2025» (до начала работ) и «Постпроектная оценка от 02.07.2026» (после реновации). Выбирает обе и нажимает «Сравнить».

Платформа отображает side-by-side таблицу: по каждой группе параметров слева данные «до», справа «после», в центре — дельта. По «Отоплению»: было «угольный котёл, КПД 45%, ежегодный расход угля 30 тонн» — стало «тепловой насос, КПД 350%, потребление электроэнергии 8 000 кВт·ч в год». По «WASH»: было «наружные туалеты, подвоз воды» — стало «внутренние санузлы, септик с полем фильтрации, артезианская скважина». По «Конструктиву»: было «трещина в несущей, кровля изношена, окна старые деревянные» — стало «трещина устранена, кровля заменена, установлены энергоэффективные окна». Скоринг изменился с 73 баллов («высокий приоритет реновации») до 91 балла («полностью соответствует требованиям»).

Координатор экспортирует сравнение в PDF и включает в отчёт донору. Также добавляет фотогалерею «до» и «после» с автоматически сгенерированной коллажной сборкой.

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

UC-A06. Симуляция вариантов программы года

Сценарий. На горизонте — 2027 год программы Joint Programme. Финансирование на следующий год от Ishonch 2030 Fund составляет 12 миллионов долларов США. Координатор программы должен подготовить план реновации — какие именно школы войдут в программу 2027 года. У него есть валидированные оценки по 100+ школам Кашкадарьинской и Сурхандарьинской областей. Решение — серьёзное, поскольку от него зависит, в каких населённых пунктах дети получат улучшенные условия, а в каких — пока нет. Координатор не хочет принимать решение интуитивно или под давлением региональных лоббистов; он хочет видеть несколько обоснованных вариантов и выбрать наиболее рациональный.

Участник: UNDP_PROGRAM_MANAGER — координатор программы UNDP.

Триггер. Подготовка к утверждению программы реновации 2027 года.

Основной поток. Координатор открывает раздел «Программы», нажимает «Новая программа года». В мастере вводит: год 2027, источник финансирования «Joint Programme / Ishonch 2030 Fund», бюджетный лимит 12 миллионов USD, целевые регионы Кашкадарьинская и Сурхандарьинская области (без расширения на другие регионы в 2027). Нажимает «Запустить симуляцию».

Платформа обрабатывает данные несколько секунд и предлагает три варианта программы:

Вариант 1 «Максимальное число школ»: 28 школ в программе, средний бюджет на школу 428 тысяч USD, охват больше всего детей (≈12 500 учащихся), но в каждой школе придётся ограничиться приоритетными работами (отопление + WASH), без полной реновации.

Вариант 2 «Максимальный социальный эффект»: 18 школ, средний бюджет на школу 666 тысяч USD, полная реновация с заменой окон, утеплением и реконструкцией санузлов. Охват меньше (≈8 500 учащихся), но каждая школа получает комплексный пакет работ. Прирост среднего скоринга по программе максимальный.

Вариант 3 «Максимальная cost-efficiency»: 22 школы, средний бюджет на школу 545 тысяч USD, оптимизированный пакет работ — критические инженерные системы для всех школ, утепление и косметика для половины. Лучший показатель «стоимость улучшения на одного ученика».

Платформа отображает три варианта в виде сравнительной таблицы и на карте регионов. По каждому варианту — список конкретных школ с указанием баллов скоринга, стоимости работ, географической плотности. Координатор изучает варианты несколько дней, обсуждает с командой UNDP, региональными координаторами, представителями МДшО. Сохраняет вариант 2 «Максимальный социальный эффект» как предпочтительный.

Постусловие. Сохранён предпочтительный вариант программы 2027 года, готов к процессу утверждения (UC-A07).

UC-A07. Утверждение программы реновации года

Сценарий. Предпочтительный вариант программы 2027 года выбран (UC-A06). Теперь его нужно согласовать со всеми ключевыми заинтересованными сторонами и получить официальное утверждение перед запуском тендерных процедур. Без формального утверждения программы тендеры не могут быть открыты — это техническая блокировка платформы.

Участник: UNDP_PROGRAM_MANAGER инициирует, согласовывают MOPSE_STRATEGY и заместители хокимов областей.

Основной поток. Координатор программы открывает черновик программы 2027 года, нажимает «Отправить на согласование». Платформа предлагает указать согласующие стороны: представители центрального аппарата МДшО (стратегическое подразделение), заместители хокимов Кашкадарьинской и Сурхандарьинской областей, региональные координаторы UNDP, представители UNICEF. Координатор отмечает 8 согласующих лиц, прикладывает обоснование выбранного варианта (документ на 5 страниц), нажимает «Отправить».

Каждый согласующий получает уведомление в платформе и по email с приглашением рассмотреть программу. В течение двух недель они изучают предложенный список школ, сравнивают с собственными приоритетами. Один из заместителей хокима оставляет комментарий с предложением заменить одну школу в программе на другую (с обоснованием — школа в селе X имеет особо критическое состояние, и местные власти готовы дополнительно финансировать территориальные работы). Координатор рассматривает предложение, обсуждает с региональным координатором UNDP, принимает изменение. Корректирует список, отправляет на повторное согласование.

После того как все 8 согласующих лиц подтверждают версию, координатор нажимает «Финальное утверждение» и подписывает программу электронной подписью. Программа 2027 года переходит из статуса draft в статус approved. Платформа автоматически разблокирует возможность запускать тендеры на ПСД (БП-2) для школ, включённых в программу.

Постусловие. Программа 2027 года утверждена, разблокированы тендерные процедуры. История согласования сохранена в журнале аудита M18.

UC-A07 расширение. Симулятор когорты с весами критериев

При формировании программы года UNDP_PROGRAM_MANAGER задаёт веса 8 критериев M3 (балл WASH, балл климат, балл доступность, охват девочек, охват сельских школ, охват малокомплектных, износ конструкций, риск аварийности). Платформа вычисляет ранжированный список школ-кандидатов в пределах бюджета. Веса публикуются в M19 одновременно с утверждённой когортой. Изменение весов после утверждения когорты запрещено без согласования MOPSE_STRATEGY и REGIONAL_HOKIM_DEPUTY и публикации обоснования.

А.2. Группа «Тендеры и контракты»

UC-A08. Регистрация подрядной организации в платформе

Сценарий. Каримов Сардор — директор ООО «СамаркандЭнергоСистем», специализирующейся на монтаже теплонасосного оборудования. Компания получила приглашение от менеджера по закупкам UNDP участвовать в тендере на установку тепловых насосов в 5 школах пилотной программы. Чтобы участвовать в тендере, компания должна сначала зарегистрироваться в платформе МБШ и раскрыть полную структуру владения. Это новое для Сардора требование — раньше при работе с государственными тендерами таких процедур не было. Но он понимает, что для UNDP это обязательное условие.

Участник: CONTRACTOR_REPRESENTATIVE — Сардор, директор ООО «СамаркандЭнергоСистем».

Триггер. Приглашение от UNDP_PROCUREMENT на участие в тендере.

Основной поток. Сардор получает email-приглашение с уникальной ссылкой регистрации. Переходит по ссылке. Открывается форма регистрации организации, разделённая на пять шагов.

Шаг 1 «Профиль организации»: полное наименование, ИНН, юридический адрес, контакты, лицензии и сертификаты (Сардор прикладывает копии лицензии Министерства строительства, сертификата ISO 9001, авторизованного представителя производителя теплонасосов).

Шаг 2 «Раскрытие бенефициарного владения (UBO)»: Сардор указывает себя как единственного владельца с долей 100%, указывает дату рождения, гражданство, ИНН. Прикладывает копию паспорта. Это критичное требование — без раскрытия UBO регистрация не завершается, тендеры закрыты. Сардор понимает суть требования: UNDP хочет видеть, кто реально контролирует компанию, чтобы исключить возможность работы с подставными фирмами и компаниями, связанными с лицами под санкциями.

Шаг 3 «Декларация конфликта интересов»: Сардор отвечает на вопросы — есть ли родственные связи с сотрудниками UNDP / МДшО / директорами школ / представителями подрядных компаний-конкурентов? У него нет таких связей, отмечает соответственно.

Шаг 4 «Декларация о добросовестности (Integrity Pact)»: Сардор читает текст обязательств — не предлагать и не давать взятки, не вступать в сговор с конкурентами, добросовестно исполнять контракты. Подписывает электронной подписью.

Шаг 5 «Документы организации»: устав, выписка из ЕГРПО, налоговое свидетельство, последний аудиторский отчёт, банковские реквизиты. Сардор прикладывает.

Завершает заявку. Платформа автоматически проверяет UBO по санкционным спискам ООН и национальным перечням — Сардор не находится в списках. Создаётся профиль организации в статусе «under verification». Менеджер по закупкам UNDP получает уведомление, что ожидается верификация.

Через два дня менеджер по закупкам открывает заявку, проверяет приложенные документы, подтверждает регистрацию. Организация переходит в статус «active». Сардор получает доступ к участию в тендерах. На этот момент платформа уже знает: владелец Сардор Каримов, единственный, без конфликта интересов, подписавший Integrity Pact, не в санкционных списках.

Постусловие. ООО «СамаркандЭнергоСистем» зарегистрировано в платформе, готово участвовать в тендерах через UN Quantum.

UC-A09. Создание тендера в UN Quantum и его отражение в МБШ

Сценарий. Бахит — менеджер по закупкам UNDP Country Office в Ташкенте. Программа 2027 года утверждена, проектная документация по 18 школам готова. Теперь нужно объявить тендеры на работы. По принципам UNDP procurement все тендерные процедуры проводятся через UN Quantum — глобальную закупочную систему UNDP. Но Бахит также должен обеспечить, чтобы тендеры были видны в платформе МБШ — для общественного контроля и для последующего привязывания контрактов, актов и выплат.

Участник: UNDP_PROCUREMENT — Бахит, менеджер по закупкам UNDP CO.

Основной поток. Бахит работает в интерфейсе UN Quantum, где создаёт новый тендер на пакет «Тепловые насосы» для группы из 5 школ. Указывает предмет тендера, требования к участникам, технические спецификации, сроки подачи заявок, бюджетный лимит, документы по школам (ПСД для каждой школы). Публикует тендер в UN Quantum.

В этот момент платформа МБШ через интеграцию И-1 автоматически получает данные о новом тендере. Создаётся procurement_event с типом «WORK_TENDER», подтипом «HEAT». Однако в этот момент тендер ещё не привязан к конкретным школам в МБШ — UN Quantum знает о тендере, но не знает наших внутренних школьных идентификаторов.

Бахит переходит в платформу МБШ, открывает раздел «Тендеры». Видит новый тендер от UN Quantum со ссылкой и базовыми сведениями. Открывает его, указывает: «Привязать к школам» и выбирает из выпадающего списка 5 школ программы 2027, для которых проводится тендер. Сохраняет привязку.

Платформа автоматически публикует тендер в публичной витрине МБШ — на главной странице публичного портала появляется новый тендер с краткой информацией: «Объявлен тендер на установку тепловых насосов для 5 школ Кашкадарьинской области. Сроки подачи заявок: 01.08.2026 – 30.08.2026. Бюджет: до 1 миллиона USD. Подробности и заявки — на платформе UN Quantum (ссылка)». Эта публичная видимость — часть антикоррупционной архитектуры платформы.

Постусловие. Тендер опубликован в UN Quantum и одновременно отражён в МБШ с привязкой к 5 школам программы 2027. Общественность видит тендер на публичном портале.

UC-A10. Просмотр публичной витрины тендеров гражданином

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

Участник: PUBLIC — Икром, журналист.

Основной поток. Икром открывает публичный портал платформы. В верхнем меню переходит в раздел «Тендеры». Видит список всех тендеров программы со сводными показателями: открытых сейчас 12, закрытых с победителем 47, закрытых без победителя 3, общая стоимость заключённых контрактов 8,2 миллиона USD.

Он применяет фильтры: регион «Сурхандарьинская область», тип работ «все», статус «закрытые». Открывается список тендеров. Каждая карточка показывает: предмет, школы (с гиперссылками на публичные страницы), победитель, цена, сроки, ссылка на UN Quantum для просмотра деталей и протоколов оценки. Икром нажимает на один тендер — «Тепловые насосы для школы №15 Ангорского района». Открывается полная карточка тендера: техническое задание (краткое), даты публикации и закрытия, состав участников (3 компании), победитель (ООО «СамаркандЭнергоСистем», предложение 248 000 USD), причины выбора (в протоколе оценки). Икром использует данные для своей статьи, ссылаясь на платформу как на первоисточник.

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

UC-A11. Регистрация контракта по итогам тендера

Сценарий. Тендер на тепловые насосы для 5 школ Кашкадарьинской области закрыт. По итогам оценки заявок победителем стало ООО «СамаркандЭнергоСистем» (тот же Сардор из UC-A08) с предложением 1,2 миллиона USD. Контракт между UNDP и ООО «СамаркандЭнергоСистем» подписан в UN Quantum. Теперь этот контракт должен появиться в МБШ для дальнейшего учёта этапов работ, фотоотчётов, актов и выплат.

Участник: UN Quantum (автоматически через интеграцию И-1) + UNDP_PROCUREMENT (Бахит) для подтверждения.

Основной поток. Через несколько минут после подписания контракта в UN Quantum интеграция И-1 синхронизирует данные с МБШ. В платформе автоматически создаётся запись contract с типом «WORK_HEAT», стороны (UNDP и ООО «СамаркандЭнергоСистем»), сумма 1,2 миллиона USD, сроки 15.08.2026 – 30.04.2027, привязка к 5 школам. Статус — draft (требует подтверждения со стороны UNDP).

Бахит получает уведомление о новом контракте в МБШ. Открывает карточку, проверяет данные на соответствие подписанному документу, прикладывает скан подписанного контракта в PDF, утверждает этапы работ согласно типовому пакету «Тепловые насосы» из справочника (5 этапов по каждой школе: подготовка → демонтаж старой котельной → установка теплонасоса → замена трубопроводов и радиаторов → пусконаладка). Переводит контракт в статус «signed».

Платформа активирует все связанные процессы: подрядчик получает доступ к контракту в своём личном кабинете, может загружать данные; видеомониторинг готов к регистрации камер (UC-A33); технадзор готов к верификации этапов (UC-A18); общественный портал отражает новый контракт по каждой из 5 школ.

Постусловие. Контракт зарегистрирован в МБШ, готов к исполнению. Подрядчик может начинать работы.

UC-A12. Регистрация дополнительного соглашения к контракту

Сценарий. В ходе работ по школе №20 Камашинского района подрядчик ООО «СамаркандЭнергоСистем» обнаружил, что несущая стена котельной требует усиления — это не было предусмотрено ПСД, поскольку при предпроектном обследовании трещина была скрыта старой штукатуркой. Дополнительные работы оценены в 35 000 USD. Заказчик (UNDP) и подрядчик согласовали увеличение цены контракта на эту сумму с продлением срока на 15 дней. Подписано дополнительное соглашение №1 к контракту.

Участник: UNDP_PROCUREMENT — Бахит.

Основной поток. Бахит открывает карточку контракта с ООО «СамаркандЭнергоСистем». В разделе «Дополнительные соглашения» нажимает «Новое». Указывает: номер 1, дата подписания, тип изменения «увеличение цены + продление срока», новые значения (цена с 1,2 млн USD на 1 235 000 USD, дата окончания с 30.04.2027 на 15.05.2027), обоснование (необходимость усиления несущей стены, обнаруженная в ходе работ). Прикладывает скан подписанного дополнительного соглашения.

Платформа автоматически пересчитывает все агрегаты по контракту: общая сумма обновлена, график выплат скорректирован (этап по школе №20 получает дополнительный подэтап «усиление несущей»), сумма к выплате по этапу увеличена на 35 000 USD. Уведомления отправлены всем связанным сторонам: подрядчик, технадзор, координатор программы, финансовый блок UNDP.

Постусловие. Дополнительное соглашение №1 зарегистрировано, контракт обновлён, все связанные показатели пересчитаны.

UC-A12 расширение. Публикация существенных доп. соглашений

Если доп. соглашение к контракту увеличивает стоимость более чем на 5% или продлевает срок более чем на 10 дней, публикация на портале M19 в течение 5 рабочих дней с момента подписания обязательна. Публикация включает: исходные параметры контракта, изменения, обоснование (текст), подписантов, ссылки на подтверждающие документы. Без публикации UC-A24 (выплата) по затронутому контракту блокируется.

UC-A13. Внесение подрядчика в чёрный список

Сценарий. ООО «СтройМонтажТермез» — подрядчик с большим объёмом работ в программе Joint Programme. Однако за последний год накопились серьёзные проблемы: систематические просрочки фотоотчётности (12 случаев), нарушения SLA по гарантийным случаям (3 случая), один случай явного отсутствия видеомониторинга в течение 5 рабочих дней без уведомления. На последней встрече программы координатор обсудил ситуацию с UNDP Integrity Unit. Совместно с антикоррупционным офицером принято решение о внесении подрядчика в чёрный список UNDP на 3 года — это серьёзная санкция, которая закроет компании доступ к будущим тендерам программы.

Участник: UNDP_INTEGRITY (антикоррупционный офицер UNDP) совместно с UNDP_PROGRAM_MANAGER.

Триггер. Накопленные нарушения превысили порог терпимости. Финальная капля — попытка подрядчика влиять на технадзор для одобрения этапа с дефектами.

Основной поток. Антикоррупционный офицер UNDP открывает раздел «Подрядчики» в платформе, находит «ООО „СтройМонтажТермез”». Видит профиль организации с рейтингом «плохой» (зафиксированные нарушения, штрафы на сумму 45 000 USD, два гарантийных случая, не устранённых в SLA). Нажимает кнопку «Внести в чёрный список». Открывается форма с обязательными полями: срок дисквалификации (по умолчанию 3 года, можно увеличить), обоснование (подробный текст), привязка к конкретным событиям-нарушениям (антикоррупционный офицер выбирает 12 событий из истории контрактов организации). Прикладывает скан решения, подписанного руководством UNDP CO. Подписывает решение электронной подписью с подтверждением второго фактора.

Платформа моментально: - Переводит профиль организации в статус «blacklisted» до 20.06.2029. - Блокирует возможность подписания новых контрактов (любой UNDP_PROCUREMENT, пытающийся это сделать, получит отказ с пояснением). - Публикует факт в публичном разделе портала (M19) — общественность видит, что компания внесена в чёрный список, и причины этого. - Уведомляет ACA через интеграцию для проверки на возможные нарушения других уровней. - Сохраняет полную историю в журнале аудита M18 — кто, когда, на каком основании внёс в чёрный список.

Альтернативный поток (восстановление). Через 3 года статус автоматически снимается, но не автоматически восстанавливается — для возобновления работы компания должна пройти новую процедуру верификации с раскрытием UBO и подписанием обновлённого Integrity Pact.

Постусловие. ООО «СтройМонтажТермез» не может получать новые контракты UNDP в течение 3 лет. Информация публична. Существующие контракты компания должна доисполнить.

А.3. Группа «Выполнение работ»

UC-A14. Старт этапа работ подрядчиком

Сценарий. ООО «СтройМонтажТермез» выиграло тендер на общестроительные работы в школе №15 Ангорского района. Контракт подписан, ПСД получена, материалы доставлены. Прораб Жасур со своей бригадой готов выйти на объект в ближайший понедельник, 24 июня, и начать с первого этапа — «Подготовительные работы и установка временного ограждения». По правилам платформы перед физическим стартом этапа подрядчик должен отметить начало в системе и загрузить стартовый фотоотчёт — это формирует точку отсчёта для последующих фотоотчётов и видимый журнал прогресса.

Участник: CONTRACTOR_REPRESENTATIVE — Жасур, прораб ООО «СтройМонтажТермез».

Предусловие. Контракт между UNDP и ООО «СтройМонтажТермез» подписан и находится в статусе «in_progress». В платформе зарегистрированы этапы работ согласно типовому пакету «Общестроительные работы» (см. Приложение Д). У Жасура есть учётная запись в платформе с привязкой к этому контракту.

Триггер. Бригада прибыла на объект, готова начать первый этап работ.

Основной поток. Жасур достаёт смартфон, открывает Telegram MiniApp или адаптивный веб-интерфейс МБШ (UC-A33 для регистрации камеры он уже выполнил неделю назад). На главном экране — карточка его контракта «Общестрой школа №15 Ангорского района». Жасур открывает контракт и видит список этапов работ согласно справочнику: 1. Подготовительные работы (готов к старту), 2. Демонтажные работы (заблокирован — нужно завершить предыдущий), 3. Утепление стен (заблокирован), и т.д. Жасур нажимает на первый этап «Подготовительные работы».

Открывается экран этапа с чек-листом из семи пунктов: установлено временное ограждение, установлены информационные щиты, установлен видеомониторинг, доставлено первичное оборудование, подписан акт передачи объекта, обеспечены условия охраны труда, изолированы рабочие зоны от учебного процесса. Жасур видит кнопку «Начать этап» — большую и яркую. Нажимает.

Платформа просит сделать стартовый фотоотчёт. Открывается камера приложения. Жасур делает четыре фотографии: общий вид школы со стороны ворот, рабочая площадка до начала работ, склад материалов в углу площадки, табличка с информацией о контракте (на которой написано: «Подрядчик: ООО „СтройМонтажТермез”, Срок: 15.07.2026 – 30.09.2026, Заказчик: UNDP, Контакты для общественности: QR-код школы»). Каждое фото автоматически снабжается геометкой (координатами места съёмки) и временной меткой (точным временем съёмки).

Платформа в фоне проверяет: геометки попадают в радиус 100 метров от паспорта школы — да; временные метки соответствуют текущему времени — да; ни одно из фото не дублирует ранее загруженные — нет. Все четыре фото принимаются. Платформа создаёт событие work_stage_started с привязкой к контракту, этапу, времени, исполнителю. Жасур видит подтверждение: «Этап „Подготовительные работы” начат. Загружен стартовый фотоотчёт. Запись доступна техническому надзору, координатору программы и общественности».

Параллельно платформа автоматически обновляет публичную страницу школы №15: в ленте событий появляется запись «20.06.2026 09:14 — Начат этап „Подготовительные работы” подрядчика ООО „СтройМонтажТермез”». Эту запись видят родители, сканирующие QR-код, и общественные наблюдатели. На дашборде технического надзора (REGIONAL_ENGINEERING) появляется новое событие — теперь технадзор знает, что этап начат и должен по графику закончиться через неделю.

Альтернативный поток (отсутствие интернета на площадке). Если на площадке нет интернета (мобильная связь нестабильна в некоторых сельских районах), Жасур делает фотографии через адаптивный веб/PWA или Telegram MiniApp в офлайн-режиме. Веб-клиент сохраняет фотографии в локальной очереди с пометкой «не синхронизировано». Когда Жасур возвращается в зону покрытия (например, в районный центр после рабочего дня), веб-клиент автоматически отправляет накопленные данные на сервер.

Исключения. Если попытаться начать этап раньше планового начала по графику — платформа предупреждает, но позволяет (досрочный старт допустим). Если попытаться начать второй этап без завершения первого — платформа блокирует с пояснением: «Этап „Демонтажные работы” заблокирован, пока не подписан акт по этапу „Подготовительные работы”». Если геометка стартового фото не попадает в радиус 100 метров от школы — фото помечается флагом «manual_geo» и требует пояснения Жасура (возможно, GPS на устройстве временно отключён или работает некорректно).

Постусловие. Этап «Подготовительные работы» имеет статус «in_progress». Стартовый фотоотчёт зарегистрирован как первое доказательство по этапу. С этого момента бригада физически работает на объекте, и Жасур обязан ежедневно загружать фотоотчёты (UC-A15) до момента завершения этапа (UC-A17).

UC-A15. Ежедневный фотоотчёт подрядчика

Сценарий. Прораб Жасур из UC-A14 ежедневно работает на школе №15 Ангорского района. Каждый рабочий день перед уходом с площадки он обязан загрузить в платформу фотоотчёт о выполненных работах. Это не формальное требование, а основной механизм фиксации прогресса, на котором базируется всё последующее — выплаты, общественный контроль, оценка качества.

Участник: CONTRACTOR_FIELD_WORKER (полевой работник) или CONTRACTOR_REPRESENTATIVE — Жасур.

Триггер. Конец рабочего дня на стройплощадке.

Основной поток. Жасур открывает Telegram MiniApp или адаптивный веб-интерфейс МБШ. Видит свой активный контракт и текущий этап «Демонтажные работы». Нажимает «Загрузить ежедневный отчёт». Делает 7 фотографий: общий вид площадки в начале дня (9:00), демонтаж старых окон в спортзале (10:30), складирование демонтированных материалов (12:00), демонтаж старых радиаторов в коридоре первого этажа (14:00), вынос мусора в контейнер (15:30), общий вид площадки в конце дня (17:00), подписание дневного журнала прорабом (17:30). По каждой фотографии указывает короткий комментарий из преднастроенного списка или свободный текст.

Платформа в фоне валидирует: все геометки попадают в радиус 100 метров от паспорта школы — да; временные метки соответствуют сегодняшней дате — да; ни одно фото не дублирует ранее загруженные — да. Все 7 фотографий принимаются со статусом «accepted». Запись отражается в ленте событий школы. Технический надзор видит обновление в реальном времени.

Альтернативный поток (нет интернета). Жасур работает на стройке без устойчивого интернета. Все фотографии сохраняются в локальной очереди приложения с пометкой «не синхронизировано». Когда Жасур возвращается в районный центр после рабочего дня, веб-клиент автоматически отправляет накопленные фотографии на сервер.

Исключения. Если фотография не проходит валидацию (геометка вне радиуса школы или дубликат) — она помечается флагом «flagged». Технадзор увидит флаг и спросит Жасура о причине. Это защищает платформу от попыток подмены или подделки доказательств.

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

UC-A16. Загрузка видео обхода стройплощадки

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

Участник: CONTRACTOR_FIELD_WORKER — Жасур.

Основной поток. Жасур открывает Telegram MiniApp или адаптивный веб-интерфейс, выбирает свой контракт. Нажимает «Видео обхода». Платформа открывает камеру, начинает запись. Жасур медленно проходит по площадке, начиная от ворот школы: фиксирует ограждение, информационный щит, складскую зону, рабочую зону, торцы здания, кровлю с земли. На записи звучат его комментарии: «Сегодня 27 июня, 70% демонтажных работ завершено, материалы складированы, отходы вывезены вчера». Через 2 минуты 40 секунд останавливает запись. Платформа автоматически прикрепляет геометку точки начала записи, временную метку, начинает загрузку видео в фоне (видео сохранится в полном качестве на сервере). Когда загрузка завершена, видео появляется в ленте событий школы.

Постусловие. Еженедельное видео обхода зафиксировано в платформе, доступно технадзору, координатору и (при разрешении публичного просмотра) для общественности через QR-канал.

UC-A17. Подача этапа на верификацию техническим надзором

Сценарий. Этап «Подготовительные работы» в школе №15 фактически завершён. Жасур (UC-A14) выполнил все семь пунктов чек-листа этапа, загрузил соответствующие доказательства. Теперь нужно официально подать этап на проверку техническому надзору — Шухрату из инжкомпании Сурхандарьи (UC-A18).

Участник: CONTRACTOR_REPRESENTATIVE — Жасур или его представитель в офисе ООО «СтройМонтажТермез».

Основной поток. Жасур открывает в платформе карточку этапа «Подготовительные работы». Видит все 7 пунктов чек-листа, по каждому — индикатор «выполнено» с прикреплёнными фотографиями. Жасур ещё раз пробегает глазами все доказательства. Заполняет краткий итоговый отчёт: «Этап завершён 28.06.2026 в 16:00. Площадка готова к началу демонтажных работ. Все элементы безопасности на месте. Видеомониторинг активен с 24.06.2026». Нажимает «Подать на верификацию». Платформа подтверждает действие, переводит этап в статус «under_review», моментально уведомляет Шухрата.

Альтернатива (незакрытые пункты). Если какой-то пункт чек-листа не имеет привязанных доказательств, кнопка «Подать на верификацию» неактивна. Платформа показывает: «Перед подачей закройте оставшиеся пункты чек-листа. Пункт 7 „Изолированы рабочие зоны” не имеет фотоподтверждений». Это защита от попытки «формальной» подачи на верификацию без полного комплекта доказательств.

Постусловие. Этап подан на верификацию, ожидается решение технадзора (UC-A18).

UC-A18. Верификация этапа техническим надзором

Сценарий. Шухрат — инженер технического надзора Единой инжиниринговой компании при хокимияте Сурхандарьинской области. В его зоне ответственности — все строящиеся школы Ангорского, Термезского, Шерабадского, Сариасийского и Узунского районов. Сегодня ему пришло уведомление о том, что подрядчик ООО «СтройМонтажТермез» подал на верификацию этап «Подготовительные работы» по школе №15 Ангорского района. Шухрат должен проверить выполнение этапа — посмотреть фотоотчёты, видеоархив, оценить соответствие чек-листу — и принять решение: одобрить, отклонить или вернуть на доработку. От его решения зависит, получит ли подрядчик первый транш оплаты.

Участник: REGIONAL_ENGINEERING — Шухрат, инженер технадзора инжкомпании Сурхандарьи.

Предусловие. Подрядчик завершил этап и подал его на верификацию (UC-A17). Все пункты чек-листа имеют привязанные доказательства. Шухрат имеет роль REGIONAL_ENGINEERING с правом верификации этапов по школам Сурхандарьинской области.

Триггер. Уведомление по электронной почте и уведомление через Telegram-бот, web-push или in-app: «На верификацию подан этап „Подготовительные работы” по школе №15 Ангорского района».

Основной поток. Шухрат открывает платформу с компьютера. На главной странице — раздел «Очередь верификаций», в котором сейчас четыре этапа от разных подрядчиков с указанием срока подачи и приоритета. Этап по школе №15 — на первом месте, поскольку подан раньше других и не имеет особых пометок. Шухрат открывает его.

На экране — полная карточка этапа: контракт, подрядчик, плановые и фактические даты начала и завершения, описание этапа, чек-лист из семи пунктов. Под каждым пунктом — миниатюры прикреплённых фото с возможностью увеличения. По первому пункту «Установлено временное ограждение» подрядчик загрузил три фото с разных сторон периметра. Шухрат увеличивает каждое фото, видит ограждение из профилированных металлических панелей, установленное по всему периметру площадки, с обозначенным проходом для рабочих и въездом для техники. Геометки фото попадают в район школы. Шухрат нажимает «Подтвердить» рядом с этим пунктом — пункт окрашивается в зелёный цвет.

По второму пункту «Установлены информационные щиты с данными контракта» подрядчик прикрепил фото щита с реквизитами: подрядчик, заказчик, сроки, контакты, QR-код школы для общественности. Шухрат подтверждает.

По третьему пункту «Установлен видеомониторинг» подрядчик прикрепил фото камеры на кронштейне, фото MikroTik-маршрутизатора, а также автоматически сгенерированный платформой отчёт о тестовом подключении: «Камера зарегистрирована 15.06.2026, тестовый снимок выполнен, поток активен». Шухрат сам открывает раздел «Видеомониторинг» по этой школе и убеждается, что поток действительно идёт. Подтверждает пункт.

По четвёртому пункту «Доставлено первичное оборудование и материалы» подрядчик прикрепил фото склада на площадке с материалами и накладные на доставку. Шухрат внимательно смотрит и замечает, что часть материалов (мешки утеплителя) лежат на земле без защиты от влаги, хотя в ПСД указано: «Материалы хранить под навесом или в палатке». Шухрат нажимает «Отклонить с комментарием» и пишет: «Материалы должны храниться под навесом или в палатке (требование ПСД). Прошу организовать хранение и приложить новое фото».

По пятому пункту «Подписан акт передачи объекта подрядчику» Шухрат видит скан подписанного акта от 18.06.2026, подписи представителей школы, района, UNDP. Подтверждает.

По шестому пункту «Обеспечены условия охраны труда» подрядчик прикрепил фото бригады в касках и жилетах, аптечку первой помощи, журнал инструктажа. Шухрат подтверждает.

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

Итого: шесть пунктов подтверждено, один отклонён. Шухрат выбирает общее решение по этапу: «Вернуть на доработку», поскольку отклонён один пункт. В комментарии указывает: «Подтверждаю выполнение шести из семи пунктов. По пункту 4 требуется устранение замечания по условиям хранения материалов. После устранения и приложения нового фото — повторная подача на верификацию». Шухрат подписывает решение электронной подписью (подтверждает действие через E-IMZO/eMZO или иной согласованный механизм step-up-аутентификации).

Платформа фиксирует решение, моментально уведомляет подрядчика через Telegram/web-push, email и in-app сообщение. Дашборд подрядчика показывает: «Этап „Подготовительные работы” возвращён на доработку. Замечание: по пункту 4 (условия хранения материалов). Действие: устранить замечание, приложить новое фото, повторно подать на верификацию».

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

Платформа моментально запускает следующие действия: генерируется этапный акт по шаблону Далолатнома (UC-A19), уведомляются стороны для подписания акта, после подписания формируется payment_due на 10% от стоимости контракта (UC-A24).

Альтернативный поток (частичная приёмка). Если часть пунктов выполнена, а оставшиеся замечания не блокируют безопасный переход к следующему этапу, Шухрат может выбрать «Частичную приёмку» только при наличии классификации замечаний, срока устранения и ответственного. Оплата допускается только в объёме и порядке, разрешённом договором и правилами удержаний; критические замечания блокируют приёмку и оплату до устранения.

Исключения. Если Шухрат хочет затянуть верификацию (например, не успевает в плановые сроки), платформа автоматически эскалирует этап на координатора программы UNDP через 5 рабочих дней без действия со стороны Шухрата. Если Шухрат пытается верифицировать этап, не открыв ни одного фотоотчёта (платформа отслеживает факт открытия превью), кнопка «Подтвердить» блокируется до того, как все доказательства будут просмотрены. Это техническая защита от «формального одобрения» без реальной проверки.

Постусловие. Этап «Подготовительные работы» имеет статус «verified». Подрядчик получил подтверждение и может переходить к следующему этапу только если график, договор и чек-лист допускают переход. Запущен процесс генерации акта; выплата транша возможна только после подписания акта, прохождения финансового контроля и фиксации связи Payment с AcceptanceAct.

UC-A18 расширение. Маршрут верификации в зависимости от типа этапа

При подаче этапа на верификацию (UC-A17) платформа определяет тип этапа и направляет на соответствующего инспектора (производного от FIELD_INSPECTOR через Прил. Я.3): технический этап СМР → REGIONAL_ENGINEERING + GASN_INSPECTOR (если критический); WASH-этап → REGIONAL_ENGINEERING + UNICEF_OFFICER; финансовый возврат retention (UC-A25) → KRU_AUDITOR; этап с прицеплённой коррупционной жалобой → ACA_OFFICER; этап с участием EXTERNAL_CONSTRUCTION_CONTROLLER — параллельная нотация. В пилоте все производные роли выполняются базовым FIELD_INSPECTOR (UNDP координатор или НКО) с пометкой scope в карточке этапа.

UC-A19. Подписание этапного акта приёмки

Сценарий. Шухрат одобрил этап «Подготовительные работы» (UC-A18). Теперь требуется официальное оформление приёмки этапа — подписание этапного акта. Это юридический документ, на основании которого подрядчик получает выплату транша. Подписи требуются от подрядчика (Жасур), технадзора (Шухрат), координатора программы UNDP (Дарья). Этап «Подготовительные работы» не относится к критическим, инспектор ГАСН в подписании не участвует.

Участник: CONTRACTOR_REPRESENTATIVE (Жасур), REGIONAL_ENGINEERING (Шухрат), UNDP_PROGRAM_MANAGER (Дарья).

Основной поток. Через несколько минут после решения «Принять этап» Шухрата платформа автоматически генерирует этапный акт по шаблону Далолатнома (см. Приложение Е). В акте указаны: реквизиты школы и контракта, описание этапа, перечень выполненных работ с привязкой к чек-листу, заключение технадзора, финансовые показатели (стоимость этапа 12 000 USD, сумма к выплате 11 400 USD после удержания retention 5%). Платформа отправляет уведомления всем трём подписантам.

Жасур первым инициирует подписание акта через Telegram MiniApp или адаптивный веб-интерфейс; юридически значимая подпись выполняется через E-IMZO/eMZO или иной согласованный государственный механизм ЭЦП. Подпись фиксируется с временем (29.06.2026 09:14), проверкой сертификата и геолокацией как атрибутом аудита. Шухрат и Дарья подписывают акт через тот же контур ЭЦП из своих рабочих мест. Через два дня все три подписи получены, акт переходит в статус «signed».

В этот момент платформа автоматически создаёт запись payment_due — указание UN Quantum выплатить 11 400 USD подрядчику. Уведомление в UN Quantum отправлено через интеграцию И-1. Финансовый блок UNDP проводит платёж в течение 3 рабочих дней. После подтверждения оплаты от UN Quantum платформа фиксирует факт выплаты в платёжном реестре контракта.

Постусловие. Этап «Подготовительные работы» официально принят, акт подписан всеми сторонами, инициирована выплата транша подрядчику.

UC-A20. Регистрация инцидента на стройплощадке

Сценарий. На стройке школы №15 Ангорского района после демонтажа кровли начались работы по гидроизоляции. Сильный ветер сорвал плёнку временной защиты от дождя на крыше. Ночью пошёл дождь, и часть верхнего этажа подверглась попаданию воды. Утром Шухрат, приехавший с инспекцией, обнаруживает проблему. Это серьёзный инцидент, требующий немедленной реакции — нужно срочно зафиксировать факт, оценить ущерб, восстановить защиту, чтобы не повторилось.

Участник: REGIONAL_ENGINEERING — Шухрат (но любая роль с доступом к площадке может зарегистрировать инцидент).

Основной поток. Шухрат открывает Telegram MiniApp или адаптивный веб-интерфейс, в карточке школы №15 нажимает «Зарегистрировать инцидент». Выбирает категорию «Несоблюдение технологии работ», подкатегорию «Защита от атмосферных воздействий». Описывает: «При ночном дожде на крыше отсутствовала временная защитная плёнка (сорвало ветром). Вода попала на верхний этаж в зоне работ. Видны следы воды на полах коридора второго этажа. Подрядчик не принял меры». Делает 5 фотографий: общий вид крыши с сорванной плёнкой, вид верхнего этажа со следами воды, повреждённый кусок плёнки, наполненный мусором временный лоток для стока воды, сравнение с зоной без повреждений. Платформа автоматически классифицирует приоритет: «Срочно × Важно» — высокий приоритет, SLA на реакцию 24 часа.

Платформа маршрутизирует инцидент: подрядчику (немедленная реакция), координатору программы UNDP в Сурхандарьинской области (Норкул), координатору программы UNDP (Дарья), на дашборд UNDP_INTEGRITY (для антикоррупционного анализа). Все получают мгновенные уведомления через Telegram/web-push или in-app.

Через 2 часа представитель подрядчика реагирует: «Принимаем. Бригада выезжает в 12:00 для восстановления защиты. Оцениваем повреждения». В течение 24 часов плёнка восстановлена, повреждённые полы высушены, дополнительный отчёт с фотографиями устранения загружен в инцидент. Шухрат подтверждает закрытие инцидента. Запись остаётся в истории школы и контракта, в рейтинге подрядчика отмечается как нарушение технологии работ (не приводит сразу к штрафу, но при повторении подобных нарушений учитывается).

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

UC-A20 расширение. Альтернативный участник: SCHOOL_DIRECTOR / SCHOOL_STAFF

Если инцидент на стройплощадке зафиксирован школьной администрацией, директор регистрирует его в кабинете с фото, геометкой, кратким описанием и категорией (травма, повреждение имущества школы, нарушение охраны труда подрядчиком, доступ посторонних на стройплощадку, иное). Платформа автоматически уведомляет инспектора ГАСН, технадзор, координатора UNDP, при категории «травма» — формирует акт по форме охраны труда. SLA на первичную реакцию — 1 час.

UC-A20 расширение. Альтернативный участник: REGIONAL_EDU_HEAD / REGIONAL_ENGINEERING

Если инцидент на стройплощадке стал известен областному уровню, но не был зарегистрирован подрядчиком или директором, областной участник регистрирует инцидент с пометкой «3rd-party report» и обязательным комментарием об источнике (жалоба, видео-просмотр, выезд). Платформа автоматически уведомляет подрядчика и директора школы, помечает как red-флаг в compliance подрядчика (Прил. И блок 5 «охрана труда») и фиксирует факт несвоевременной регистрации в audit log M18.

UC-A21. Приостановка работ по контракту

Сценарий. На стройке школы №25 Гузарского района бригада подрядчика три рабочих дня выходит без касок и жилетов. Несмотря на устное замечание от технадзора, ситуация не меняется. Инспектор ГАСН после планового визита решает применить более серьёзную меру — приостановить работы до устранения нарушений охраны труда. Это серьёзный сигнал для подрядчика, что нельзя относиться к безопасности формально.

Участник: GASN_INSPECTOR или UNDP_PROGRAM_MANAGER.

Триггер. Критическое нарушение, требование надзорного органа.

Основной поток. Инспектор ГАСН Раджаббаев открывает в платформе карточку контракта по школе №25. Нажимает кнопку «Приостановить работы». Заполняет форму: причина «Систематические нарушения требований охраны труда (отсутствие СИЗ у бригады)», документальное основание «Предписание ГАСН №157 от 30.06.2026», срок приостановки «до устранения нарушений и подтверждения соответствия требованиям» (без даты окончания). Подписывает решение электронной подписью.

Платформа моментально: - Переводит контракт в статус «suspended». - Блокирует возможность загрузки новых фотоотчётов (но не блокирует доступ к ранее загруженным данным). - Блокирует подачу этапов на верификацию. - Блокирует все выплаты по контракту. - Уведомляет подрядчика, координатора программы, всех вовлечённых лиц. - Публикует факт приостановки на публичном портале школы.

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

UC-A22. Возобновление работ по контракту

Сценарий. Через 5 дней после приостановки (UC-A21) подрядчик исправил ситуацию: закупил каски и жилеты для всей бригады, провёл повторный инструктаж по охране труда, направил в платформу подтверждающие документы и фотографии бригады в СИЗ на объекте. Инспектор ГАСН Раджаббаев провёл повторный визит и подтвердил соответствие. Координатор программы UNDP получает право возобновить работы.

Участник: UNDP_PROGRAM_MANAGER (Дарья).

Основной поток. Дарья открывает карточку контракта по школе №25. Видит, что инспектор ГАСН зарегистрировал акт о соответствии устранения замечаний. Нажимает «Возобновить работы». Подтверждает причину возобновления, прикладывает ссылку на акт ГАСН. Подписывает решение электронной подписью. Контракт переходит в статус «in_progress». Подрядчик получает уведомление о возобновлении. Технадзор и общественность тоже информируются — на публичном портале школы появляется запись «Работы возобновлены после устранения нарушений охраны труда».

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

UC-A22 расширение. Альтернативный поток с участником CONTRACTOR_REPRESENTATIVE

Подрядчик подаёт заявку «Готов к возобновлению» с пакетом доказательств устранения нарушения (фото с GPS, акт инструктажа, накладные на закупку СИЗ, фотографии бригады в СИЗ на объекте). Платформа уведомляет GASN_INSPECTOR и UNDP_PROGRAM_MANAGER. Инспектор ГАСН проводит повторный визит, подтверждает в платформе соответствие; координатор UNDP принимает финальное решение «возобновить» или «отказать с обоснованием». До финального решения подрядчик не может загружать новые фотоотчёты по приостановленному этапу. SLA на решение — 5 рабочих дней.

А.4. Группа «Приёмка и выплаты»

UC-A23. Финальная приёмка объекта школы

Сценарий. Прошло восемь месяцев с момента начала работ в школе №15 Ангорского района. ООО «СтройМонтажТермез» выполнило все этапы общестроительных работ. Параллельно работающие подрядчики — производитель тепловых насосов из Самарканда и поставщик локальной очистной системы канализации из Ташкента — также завершили свои работы. Финальный этап перед сдачей школы в эксплуатацию — финальная приёмка объекта многоведомственной комиссией. Это важнейшее событие, которое запускает три критических процесса: возврат подрядчикам удержанных сумм (retention), отсчёт пятилетнего гарантийного срока и переход школы в режим обычной эксплуатации с продолжением общественного контроля.

Участник: Многоведомственная комиссия — UNDP_PROGRAM_MANAGER (председатель, инициирует процесс), а также представители UNDP, UNICEF, МДшО (центральный аппарат), Министерства цифровых технологий, представитель Anti-Corruption Agency, представитель Civil Society Advisory Committee, инспектор ГАСН, аудитор КРУ, представитель Ангорского района, директор школы Анвар Хужакулов, представители всех трёх подрядчиков, представитель махалли.

Предусловие. Все этапы всех контрактов по школе подписаны (UC-A19) и оплачены (UC-A24, кроме retention). Школа готова к сдаче. По школе нет открытых критических замечаний.

Триггер. Координатор UNDP по Сурхандарьинской области сообщил координатору программы UNDP о готовности школы к финальной приёмке.

Основной поток. Координатор программы UNDP открывает в платформе карточку школы №15 и нажимает кнопку «Инициировать финальную приёмку». Платформа автоматически собирает pre-acceptance dossier — единый документ, содержащий: все этапные акты по всем контрактам школы; полный видеоархив со стройки за весь период работ; все фотоотчёты с группировкой по контрактам и этапам; заключения государственной экспертизы по ПСД; реестр всех замечаний и их устранения; статистику обращений граждан через QR-канал; результаты независимого мониторинга от CSAC; финансовую сводку (выплачено / удержано); реестр зарегистрированных гарантийных обязательств. Документ объёмом около 300 страниц с гиперссылками на исходные материалы готов к ознакомлению членами комиссии до выезда.

Координатор предлагает дату выезда — 28 июня 2026 года, 10:00. Платформа автоматически рассылает приглашения всем членам комиссии (через email, Telegram/web-push или in-app). Члены комиссии подтверждают участие. Дата фиксируется. Платформа формирует электронный календарь и напоминания.

28 июня в 10:00 комиссия прибывает на школу №15. Каждый член комиссии открывает Telegram MiniApp или адаптивный веб-интерфейс МБШ, проходит регистрацию прибытия — приложение фиксирует геолокацию (подтверждает физическое присутствие на объекте) и время прибытия. На экране появляется чек-лист финальной приёмки (около 35 пунктов): фасад школы соответствует ПСД; внутренние помещения отремонтированы согласно сметы; система отопления работает (комиссия проверяет включение); канализация функционирует (комиссия проверяет работу санузлов); WASH-инфраструктура оборудована; территория восстановлена; нет видимых дефектов и т.д.

Комиссия физически обходит школу, проходя по чек-листу. Каждый член комиссии в адаптивном веб/PWA или Telegram MiniApp подтверждает или отклоняет пункты. По каждому пункту прикладывается фото текущего состояния. По мере прохождения комиссии платформа в реальном времени показывает прогресс на дашборде координатора.

К 13:00 чек-лист пройден. Из 35 пунктов 33 подтверждены полным составом комиссии. По двум пунктам обнаружены незначительные замечания: незакрашенный участок на стене коридора первого этажа и неработающий смеситель в санузле второго этажа. Эти замечания фиксируются как «обязательства к устранению» с указанием подрядчика (ООО «СтройМонтажТермез») и сроком — две недели после финальной приёмки. Платформа создаёт автоматические задачи по устранению.

Председатель комиссии — координатор программы UNDP — нажимает «Перейти к подписанию Далолатномы». Платформа автоматически генерирует электронную Далолатнома по форме ШНК 3.01.04-19, в которой указаны все выполненные работы, перечень замечаний к устранению, состав комиссии и подпись каждого члена. Каждый член комиссии в адаптивном веб/PWA или Telegram MiniApp видит готовый документ, читает его, при необходимости скачивает и инициирует юридически значимое подписание через E-IMZO/eMZO или иной согласованный государственный механизм ЭЦП. Каждая подпись проверяется по сертификату ЭЦП и фиксируется с привязкой к времени подписания, геолокации как доказательному атрибуту присутствия и учётной записи подписывающего.

К 14:30 все подписи получены. Платформа фиксирует финальный акт — электронная Далолатнома становится официальным документом приёмки. Школа автоматически переходит из статуса «in_renovation» в статус «commissioned». Запускается отсчёт пятилетнего гарантийного срока для каждого контракта.

Параллельно платформа автоматически инициирует возврат удержанных сумм (retention) каждому подрядчику через UN Quantum с задержкой 60 дней (срок на устранение замечаний). Создаётся задача мониторинга устранения двух замечаний — координатор UNDP получает уведомление, ему нужно будет подтвердить устранение и тогда retention будет возвращена.

Параллельно публичная страница школы обновляется: статус «Сдана в эксплуатацию 28.06.2026», лента событий дополняется записью о финальной приёмке, фотогалерея «после реновации» автоматически собирается из последних загруженных фото. Зухра и другие родители, сканирующие QR-код, увидят, что школа официально сдана. Этот же факт виден на дашбордах руководства программы — школа закрашивается зелёным маркером на карте.

Альтернативный поток (критические замечания). Если на финальной приёмке обнаружены критические замечания (например, систематические протечки, не работает отопление, нарушения безопасности) — школа не переводится в статус commissioned. Платформа создаёт акт «возврата на доработку», подрядчики получают список критических замечаний с обязательством устранить. После устранения процедура финальной приёмки повторяется.

Исключения. Если кто-то из членов комиссии не может прибыть физически на объект — у него есть возможность участвовать удалённо через видеосвязь, с просмотром записи обхода школы в реальном времени и подписанием Далолатномы дистанционно. Однако геолокация в этом случае не фиксируется, и подпись помечается особой меткой «remote».

Постусловие. Школа №15 находится в статусе commissioned. Запущен пятилетний гарантийный период до 28.06.2031. Подрядчики получают возврат retention через 60 дней при условии устранения замечаний. Школа продолжает быть объектом общественного контроля через QR-канал — теперь уже не по поводу строительства, а по гарантийным случаям (UC-A38).

UC-A23 расширение. Чек-лист WASH (Sphere / WHO–UNICEF JMP)

Требует согласования с UNICEF. На финальной приёмке UC-A23 формируется отдельный раздел «WASH-соответствие» из 15 пунктов: 1) питьевая вода 15 л/чел/день и доступна непрерывно; 2) гендерно-разделённые туалеты; 3) ratio туалетов девочки ≥1:25; 4) ratio туалетов мальчики ≥1:50; 5) ADA-доступ хотя бы 1 туалет; 6) умывальники с проточной водой ≥1:20; 7) мыло и держатель в каждом умывальнике; 8) бумага в каждой кабинке (или альтернативная гигиена с водой); 9) вентиляция в туалетах; 10) освещение в туалетах ≥150 люкс; 11) запираемые двери и приватность; 12) утилизация бытовых отходов; 13) утилизация менструальных отходов (для школ с девочками ≥10 лет); 14) питьевые фонтаны не менее 1 на этаж; 15) санитарная книга школы с журналом ежедневной проверки. Каждый пункт проверяется UNICEF_OFFICER. Если ≥3 пункта red — школа не принимается до устранения, UNICEF_OFFICER имеет vето по WASH-разделу.

UC-A23 расширение. Climate resilience чек-лист

Требует согласования с UNICEF. Дополнительный раздел акта приёмки UC-A23: 1) утепление стен и кровли соответствует ШНК; 2) энергоэффективные окна; 3) тепловой насос или альтернативный энергоэффективный источник тепла установлен и работает (КПД ≥250%); 4) питьевые фонтаны с фильтрацией; 5) локальная очистная система канализации (септик с полем фильтрации); 6) водосбор дождевой воды (где климат позволяет); 7) светодиодное освещение; 8) солнечная панель для базовых нужд (по проекту). Каждый пункт проверяется UNICEF_OFFICER совместно с инжкомпанией. Без green по применимым пунктам — UC-A23 не подписывается в части climate.

UC-A24. Регистрация выплаты по подписанному этапному акту

Сценарий. Этап «Подготовительные работы» в школе №15 принят (UC-A18) и подписан всеми сторонами (UC-A19). Теперь должна состояться фактическая выплата подрядчику ООО «СтройМонтажТермез» — 11 400 USD (12 000 USD стоимость этапа минус 5% retention). Платформа МБШ инициирует процесс, UN Quantum выполняет фактическую транзакцию.

Участник: UN Quantum + UNDP_FINANCE (автоматически).

Основной поток. Платформа МБШ автоматически генерирует запись payment_due после подписания всех сторон этапного акта. Через интеграцию И-1 это уведомление передаётся в UN Quantum: «По контракту C-2026-001 подписан этап „Подготовительные работы”, сумма к выплате 11 400 USD, получатель — банковские реквизиты ООО „СтройМонтажТермез”».

Финансовый блок UNDP в UN Quantum получает уведомление, проводит обычные процедуры платежа (проверка реквизитов, утверждение, банковский перевод). В течение 3 рабочих дней платёж выполнен. UN Quantum возвращает подтверждение в МБШ через интеграцию: «Платёж проведён 02.07.2026, банковский идентификатор транзакции X, статус — успешно».

МБШ фиксирует факт оплаты: создаётся запись Payment со статусом «paid», привязывается к этапному акту и контракту. На дашборде подрядчика появляется уведомление: «Получена оплата 11 400 USD по этапу „Подготовительные работы”. Удержано в качестве retention: 600 USD». Подрядчик может проверить детали транзакции.

Постусловие. Выплата по этапу проведена, факт зафиксирован в МБШ и UN Quantum. Удержанная сумма 600 USD будет возвращена через 60 дней после финальной приёмки школы (UC-A25).

UC-A25. Возврат удержанной суммы (retention)

Сценарий. С момента финальной приёмки школы №15 (UC-A23) прошло 60 дней. За это время два мелких замечания, зафиксированных на приёмке (незакрашенный участок стены и неработающий смеситель), были устранены подрядчиком ООО «СтройМонтажТермез» — координатор UNDP по Сурхандарьинской области подтвердил устранение. Теперь подрядчик имеет право на возврат удержанных 5% retention — это 60 000 USD, накопленные по всем выплатам за этапы контракта (всего 1,2 миллиона USD стоимости контракта).

Участник: UNDP_FINANCE (Илхом, финансовый сотрудник UNDP).

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

Основной поток. Платформа автоматически генерирует напоминание Илхому: «Контракт C-2026-001 (ООО „СтройМонтажТермез”, школа №15). 60 дней после финальной приёмки. Замечания устранены. Готов к возврату retention в размере 60 000 USD». Илхом открывает карточку контракта, проверяет: все этапы подписаны, все замечания устранены, нет открытых гарантийных случаев. Подтверждает возврат retention и подписывает решение через E-IMZO/eMZO или иной согласованный механизм ЭЦП.

Платформа передаёт указание в UN Quantum через интеграцию И-1. UN Quantum выполняет платёж 60 000 USD на счёт ООО «СтройМонтажТермез». Подтверждение возвращается в МБШ. Контракт переводится в статус «closed». Подрядчик получает уведомление о возврате retention. Запись фиксируется в реестре выплат.

Постусловие. Retention возвращён подрядчику, контракт закрыт. Гарантийные обязательства подрядчика остаются активными в течение 5 лет после финальной приёмки (UC-A38).

А.5. Группа «Общественная обратная связь»

UC-A26. Генерация и размещение QR-кода школой

Сценарий. Анвар Хужакулов — директор школы №15 Ангорского района Сурхандарьинской области. В школе как раз идёт реновация по программе Joint Programme. Координатор UNDP в Сурхандарьинской области сообщил Анвару, что в платформе «My Better School» для каждой школы генерируется уникальный QR-код, который нужно распечатать и разместить на здании школы. По этому QR-коду родители, учителя и любые проходящие мимо граждане смогут попасть на публичную страницу школы и подать обращение по статусу строительства или работе подрядчиков. Анвар знает, что школа находится под общественным контролем, и хочет правильно разместить QR-код, чтобы максимальное число людей могло им воспользоваться.

Участник: SCHOOL_DIRECTOR — Анвар Хужакулов, директор школы.

Предусловие. Школа зарегистрирована в платформе (UC-A01), у директора создана учётная запись с ролью SCHOOL_DIRECTOR (UC-A48), директор знает свои логин и пароль.

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

Основной поток. Анвар открывает платформу на своём ноутбуке, входит в личный кабинет. В боковом меню он видит раздел «QR-код школы» — этот пункт меню есть только у директоров школ. Анвар открывает раздел и видит уже сгенерированный QR-код для своей школы (платформа создаёт QR автоматически при регистрации школы и связывает его с уникальной публичной ссылкой на страницу этой школы). На экране — превью QR-кода с подписью «Школа №15 Ангорского района — публичная страница». Под превью — кнопки для скачивания в разных форматах: PDF формата A3 (для размещения у главных ворот), A4 (для информационных стендов на территории школы), A5 (для размещения внутри здания на видных местах), PNG (для использования в публикациях, например, на сайте школы или в социальных сетях). Также — инструкция по рекомендуемым местам размещения и обоснование: «QR-код должен быть виден прохожим с улицы, размещайте на фасаде здания или у ворот. Дополнительные копии — на информационных стендах внутри школы».

Анвар выбирает PDF формата A3, скачивает файл, распечатывает на принтере районного управления образования (поскольку у школы нет цветного принтера). На следующий день он закрепляет распечатанный QR-код на фасаде школы рядом с табличкой школы — таким образом, чтобы он был виден родителям, провожающим детей в школу. Дополнительные A4-копии Анвар размещает на информационных стендах внутри школы — рядом с расписанием и объявлениями.

Альтернативный поток. Если у школы нет возможности самостоятельно распечатать QR-код, директор может обратиться к координатору UNDP в регионе — координатор организует печать и доставку готовых табличек с QR-кодом централизованно для всех школ программы.

Исключения. Если у директора нет учётной записи или он потерял пароль — он обращается к региональному координатору, тот восстанавливает доступ. Если QR-код по каким-то причинам не виден в личном кабинете (техническая ошибка) — директор обращается в техническую поддержку платформы (телефон или email указаны в подвале каждой страницы личного кабинета).

Постусловие. QR-код школы размещён на здании в виде, доступном для сканирования любым прохожим со смартфоном. С момента размещения QR-кода любой человек может подать обращение по школе (UC-A27).

UC-A27. Подача гражданином жалобы через QR-канал

Сценарий. Зухра — мама второклассницы школы №15 Ангорского района. Каждое утро она провожает дочь в школу и забирает её после уроков. В прошлый понедельник Зухра обратила внимание, что в коридоре первого этажа школы — пятна потолочной воды, явные следы протечки. На улице как раз закончилась ночная гроза. Зухра понимает, что протечка может представлять опасность для детей: возможно короткое замыкание, обрушение штукатурки, скользкие полы. Она решает обратиться, но не знает, к кому именно: директор школы скажет «занят учебным процессом», районное УНО — «приходите по записи». На воротах школы Зухра замечает табличку с QR-кодом и подписью: «Сообщить о проблемах и предложениях по школе — отсканируйте QR-код». Зухра достаёт смартфон и сканирует.

Участник: PUBLIC или CITIZEN_AUTHENTICATED — Зухра, мама ученицы школы; SMS-OTP требуется только если она выбирает формальное обращение с трекингом и официальным ответом.

Предусловие. Директор школы разместил QR-код на здании школы (UC-A26). У Зухры есть смартфон с камерой и доступом к мобильному интернету (4G сеть в Ангорском районе).

Триггер. Зухра увидела протечку крыши в школе.

Основной поток. При сканировании QR-кода открывается мобильный браузер с публичной страницей школы №15. На странице Зухра видит фото школы, основные сведения (мощность 380 учеников, год постройки 2014), информацию о текущей реновации: «Подрядчик: ООО „СтройМонтажТермез”, этап „Утепление крыши и кровельные работы”, плановое завершение: 15.07.2026, фактический прогресс 68%». Внизу страницы — четыре крупные кнопки: «Сделать фото», «Положительный отзыв», «Жалоба по инфраструктуре», «Жалоба на работу подрядчика». Зухра нажимает «Жалоба по инфраструктуре». Открывается форма, где сначала нужно выбрать категорию из выпадающего списка: «Крыша / протечка», «Стены / трещины», «Окна / двери», «Отопление», «Электричество», «Санузлы», «Вода», «Иное». Зухра выбирает «Крыша / протечка».

Дальше — поле для свободного текста. Зухра вводит: «Сегодня после ночной грозы в коридоре первого этажа сильная протечка. Большие лужи на полу, дети могут поскользнуться. На потолке отслаивается штукатурка. Прошу срочно проверить». Под текстом — кнопка «Прикрепить фото». Зухра нажимает, открывается камера смартфона, она делает три фотографии: общий вид коридора с лужей, крупный план потолка с отслаивающейся штукатуркой, разводы воды на стене. Каждое фото сохраняется с автоматической геометкой (координатами места съёмки) и временной меткой.

Дальше — блок «Режим подачи». По умолчанию выбран «Открытый сигнал»: Зухра может отправить сообщение без номера телефона, а платформа предупредит, что индивидуальный официальный ответ и трекинг будут недоступны. Рядом доступен режим «Формальное обращение»: если Зухре нужен официальный ответ, она вводит мобильный номер, получает SMS с шестизначным кодом, вводит код в форму, проходит SMS-верификацию и при желании указывает имя для обратной связи. Финальная кнопка адаптирует текст под режим: «Отправить открытый сигнал» или «Отправить формальное обращение».

Платформа моментально показывает экран подтверждения. Для открытого сигнала: «Спасибо, сигнал принят и будет проверен. Статус проверки появится на публичной странице школы после модерации». Для формального обращения: «Спасибо, обращение зарегистрировано под номером CF-2026-06-20-00427. Категория: “Протечка крыши”. Приоритет: “Срочно × Важно”. SLA на ответ: 24 часа. Уведомлены: директор школы, районное УНО, областное УНО, координатор программы UNDP, подрядчик. Ответ вы получите по SMS, ссылка на полный ответ — там же».

Параллельно платформа автоматически выполняет маршрутизацию. Поскольку в системе зарегистрировано, что для школы №15 идёт активный контракт «Утепление крыши» с подрядчиком ООО «СтройМонтажТермез», и категория обращения «Крыша / протечка» относится к работам этого подрядчика, обращение маршрутизируется одновременно: на дашборд директора школы Анвара Хужакулова, на дашборд начальника районного УНО, на дашборд начальника областного УНО МДшО Сурхандарьи, на дашборд координатора UNDP в Сурхандарьинской области (Норкул Махмадиеров), на дашборд представителя подрядчика и на дашборд общественного наблюдателя по программе. На всех дашбордах включается SLA-таймер на 24 часа.

Альтернативный поток (нет камеры). Если у Зухры нет смартфона с камерой, она может попросить кого-то другого помочь, либо подать обращение через веб-сайт публичного портала с компьютера, прикрепив фотографии с камеры цифрового устройства. Этот альтернативный путь полностью функционален, но менее удобен.

Исключения. Если Зухра не может получить SMS-код, она может отправить открытый сигнал без номера телефона либо повторить попытку формального обращения через 1 минуту. После трёх неудачных попыток SMS-верификации платформа предлагает альтернативный канал техподдержки. Если с одного подтверждённого номера уже подано пять формальных обращений за сутки, новые формальные обращения временно блокируются на 24 часа; открытые сигналы дополнительно ограничиваются антиспам-правилами по IP/device/browser fingerprint.

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

UC-A28. Положительный отзыв гражданина о работе подрядчика

Сценарий. Махмуд — отец двух школьников школы №16. Он видит, как работают строители подрядчика по реновации: бригада приходит вовремя, работает быстро, поддерживает чистоту на площадке, вежливо общается с детьми и родителями. Махмуд хочет публично отметить хорошую работу — не только жалобы должны идти через платформу. Это создаёт стимулы для подрядчиков работать хорошо, а не только избегать наказаний.

Участник: PUBLIC или CITIZEN_AUTHENTICATED — Махмуд; SMS-OTP опционален и нужен только для трекинга.

Основной поток. Махмуд сканирует QR-код на воротах школы №16. На странице школы видит четыре кнопки. Нажимает «Положительный отзыв». Открывается форма: тема (выбирает «Качество работ»), подкатегория («Соблюдение чистоты и порядка»), текст: «Хочу отметить, что бригада подрядчика поддерживает порядок на площадке, не оставляет мусор, не мешает учебному процессу. Работают быстро, спорых рук видно. Спасибо за хорошую работу!». Прикладывает фото убранной площадки и табличку с инструктажем по безопасности. Может отправить как открытый сигнал без обязательной аутентификации; при желании получить трекинг и официальный ответ проходит SMS-OTP. Указывает имя.

Отзыв публикуется на публичной странице школы — другие пользователи QR-канала видят положительные отзывы наравне с жалобами. На дашборде подрядчика этот отзыв учитывается как положительный отзыв в рейтинге. Координатор программы UNDP видит, что подрядчик получает положительный feedback от общественности — это учитывается при будущих оценках.

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

UC-A29. Публикация гражданином фото проблемы

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

Участник: PUBLIC или CITIZEN_AUTHENTICATED — Дилором; быстрый фотосигнал допускается без обязательной аутентификации.

Основной поток. Дилором достаёт смартфон, сканирует QR на школьном здании. Нажимает «Сделать фото» (большая кнопка, рассчитанная на быстрое действие). Открывается камера мобильного браузера или Telegram MiniApp. Делает три фотографии: повалённое ограждение, дети рядом со стройкой, неубранные строительные материалы рядом. Краткое описание: «Ограждение повалено, дети играют рядом, опасно». Может отправить как открытый сигнал без обязательной аутентификации; при желании получить трекинг и официальный ответ проходит SMS-OTP. Отправляет. Платформа автоматически модерирует фото (проверяет на корректность контента — нет обнажённой натуры, насилия и т.п.) и публикует в ленте событий школы.

Параллельно платформа классифицирует это как срочную проблему (категория «Безопасность» + наличие риска для детей) и маршрутизирует на дашборды директора школы, районного УНО, координатора UNDP, подрядчика. SLA на реагирование — 24 часа. К концу того же дня подрядчик восстанавливает ограждение, координатор фиксирует результат в системе. Если Дилором проходила SMS-OTP, она получает индивидуальное уведомление; если сигнал был открытым, обезличенный результат публикуется в ленте школы.

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

UC-A30. Ответ ответственного на обращение гражданина

Сценарий. Дилором подала обращение с фото повалённого ограждения (UC-A29). Координатор UNDP по Сурхандарьинской области (Норкул) получает уведомление в платформе. Норкул должен оперативно ответить — это не только обязанность по SLA, но и сигнал заявителю, что её голос услышан, и обществу — что платформа работает.

Участник: UNDP_PROGRAM_MANAGER — Норкул (или другой ответственный в зависимости от типа обращения).

Основной поток. Норкул открывает обращение в платформе. Изучает приложенные фотографии, координирует с подрядчиком ситуацию. Через 1 час подрядчик прибывает на место, восстанавливает ограждение, фотографирует. Норкул возвращается к обращению, нажимает «Ответить». В поле ответа пишет: «Уважаемая Дилором, спасибо за вашу бдительность и оперативное сообщение о проблеме. Подрядчик восстановил повалённое ограждение в 16:30 сегодня. Проведён дополнительный инструктаж бригады по обеспечению безопасности на площадке. Ограждение будет дополнительно укреплено металлическими стяжками для предотвращения повторных случаев». Прикладывает фото восстановленного ограждения. Подписывает ответ электронной подписью.

Платформа автоматически отправляет Дилором SMS: «По вашему обращению CF-2026-07-15-00234 опубликован ответ. Посмотреть: https://mbs.uz/c/CF-2026-07-15-00234». Дилором переходит по ссылке, читает ответ, видит фото восстановленного ограждения. Ответ публикуется на публичной странице школы №18 в ленте событий.

Постусловие. Обращение закрыто с ответом. Заявитель проинформирован. Публичная история фиксируется.

UC-A31. Автоматическая эскалация при нарушении SLA

Сценарий. Гражданин подал обращение о неисправности отопления в школе №22, классифицированное как срочное (SLA 24 часа). Прошло 22 часа, ответственный сотрудник районного УНО не отреагировал — не открыл обращение, не назначил исполнителя. До истечения SLA остаётся 2 часа. Платформа должна автоматически реагировать на риск нарушения SLA, поскольку оставлять граждан без ответа — серьёзный антирепутационный риск программы.

Участник: Система (автоматически).

Триггер. До истечения SLA уровня 0 (первый ответственный) остаётся 4 часа без действий.

Основной поток. Платформа автоматически генерирует уведомление через Telegram/web-push или in-app и SMS первичному ответственному (Бахтиёр, специалист районного УНО Камашинского района): «Внимание: до истечения SLA по обращению CF-2026-07-20-00457 остаётся 4 часа. Обращение требует немедленной реакции».

Через 4 часа реакции не последовало. Платформа автоматически переводит обращение на уровень 1 (вышестоящий — областное УНО): создаётся уведомление начальнику областного управления МДшО Сурхандарьи. Email и SMS: «Эскалация: обращение CF-2026-07-20-00457 не обработано в районном УНО. Просьба назначить ответственного». Одновременно фиксируется запись в журнале аудита M18: «Эскалация уровня 0 → 1, причина: нарушение SLA».

Через 2 часа начальник областного управления назначает специалиста для немедленной работы по обращению — специалист отвечает, организует устранение проблемы. Обращение закрывается с ответом. Однако в рейтинге Бахтиёра (первичного ответственного) фиксируется случай нарушения SLA — что учитывается при ежегодной оценке его работы.

Постусловие. Обращение обработано на следующем уровне. История эскалации сохранена. Первичный ответственный получил отметку в свой рейтинг.

UC-A32. Модерация обращения как спам

Сценарий. По одной из школ программы поступило обращение через QR-канал с явно спам-содержимым: текст рекламы сайта продажи строительных материалов, без какого-либо отношения к школе. Это не первый случай такого спама. Платформа должна позволить модератору убрать такое содержимое с публичной ленты, чтобы не отвлекать внимание реальных пользователей. Однако само обращение должно сохраниться в журнале — для возможного расследования (если это не разовый случай, а систематическая атака).

Участник: Модератор — UNDP_INTEGRITY (антикоррупционный офицер) или специально назначенный сотрудник.

Основной поток. Модератор открывает обращение. Видит, что текст содержит рекламу с гиперссылкой на коммерческий сайт. Нажимает «Пометить как спам». Заполняет обязательное обоснование: «Рекламный спам, не относится к деятельности программы. Содержит ссылку на коммерческий сайт». Подписывает решение электронной подписью.

Платформа моментально скрывает обращение с публичной ленты школы (гражданин, заходящий по QR, не видит этот спам). Но запись сохраняется в журнале аудита M18 — кто, когда, на каком основании пометил как спам. Это защищает от попыток модераторов «зачищать» неугодные обращения под видом спама — каждое такое действие фиксируется и может быть пересмотрено вышестоящим лицом.

Дополнительно: номер телефона, с которого был спам, временно блокируется от подачи новых обращений на 30 дней. Если с этого номера будут повторные попытки спама, блокировка продлевается.

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

А.6. Группа «Видеомониторинг»

UC-A33. Регистрация камеры видеомониторинга подрядчиком

Сценарий. Подрядчик ООО «СтройМонтажТермез» получил контракт на работы в школе №15 Ангорского района. По требованиям контракта (и платформы) подрядчик обязан установить камеру видеомониторинга на стройплощадке до начала работ. Подрядчик уже закупил оборудование — IP-камеру Hikvision, маршрутизатор MikroTik и UPS. Теперь нужно зарегистрировать камеру в платформе и настроить её для передачи потока через VPN.

Участник: CONTRACTOR_REPRESENTATIVE — представитель подрядчика, отвечающий за техническое сопровождение видеомониторинга (часто это IT-специалист подрядной компании, если он есть, или сторонний интегратор по договору).

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

Основной поток. Представитель подрядчика открывает в платформе карточку контракта школы №15. В разделе «Видеомониторинг» нажимает «Добавить камеру». Открывается мастер регистрации. Указывает: модель камеры (Hikvision DS-2CD2T47G2-L), модель маршрутизатора (MikroTik hAP ac²). Платформа автоматически генерирует уникальные параметры для подключения: приватный ключ WireGuard, публичный ключ сервера МБШ, выделенный внутренний IP в подсети 12.1.0.0/16 (например, 12.1.5.47), endpoint VPN-сервера МБШ. Эти параметры отображаются на экране и доступны для скачивания в виде конфигурационного файла.

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

Возвращается в офис, открывает Telegram MiniApp или адаптивный веб-интерфейс, нажимает «Подтвердить готовность камеры», делает тестовый снимок через камеру (платформа делает запрос к камере через VPN, получает снимок, сохраняет). Также запускает тестовую запись на 30 секунд для проверки качества видео. Отправляет на проверку инженеру МБШ.

Инженер МБШ (Захид) получает уведомление, проверяет тестовый снимок и видео. Качество хорошее, угол обзора охватывает ключевые рабочие зоны площадки, поток стабилен. Захид подтверждает регистрацию камеры. Камера переходит в статус «active». С этого момента непрерывная запись потока начинается на сервере МБШ.

Альтернативный поток (плохое качество). Если тестовый снимок размытый или поток нестабилен, инженер МБШ возвращает камеру на доработку с замечаниями. Подрядчик исправляет (например, переустанавливает камеру для лучшего угла обзора, заменяет дефектную камеру) и повторяет тестирование.

Постусловие. Камера зарегистрирована, активна. Видеомониторинг площадки идёт в реальном времени, поток сохраняется в архиве 30 дней.

UC-A34. Просмотр прямой видеотрансляции стройплощадки

Сценарий. Шухрат (технадзор Сурхандарьи) получил уведомление об инциденте на одной из стройплощадок. Хочет быстро убедиться, что бригада подрядчика работает в данный момент в соответствии с восстановленным порядком. Вместо физического выезда за 80 километров он просто открывает прямой видеопоток с площадки и убеждается, что всё в порядке.

Участник: REGIONAL_ENGINEERING — Шухрат (доступ к прямой трансляции имеют также GASN_INSPECTOR, UNDP_PROGRAM_MANAGER, CSAC_OBSERVER, NGO_MONITOR).

Основной поток. Шухрат открывает раздел «Видеомониторинг» в платформе. Видит карту региона с маркерами активных камер. Цвет маркера показывает статус — зелёный (поток активен), жёлтый (есть проблемы), красный (поток недоступен). Шухрат нажимает на маркер школы №15 Ангорского района. Открывается плеер с прямой трансляцией. Видит площадку, бригаду в касках и жилетах (после устранения нарушений в UC-A21 и UC-A22), процесс работы. Через 5 минут наблюдения убеждается, что всё в порядке, закрывает плеер.

Платформа автоматически фиксирует факт просмотра в журнале аудита: «Шухрат просмотрел прямую трансляцию камеры школы №15 с 11:23 до 11:28». Это запись для будущего аудита — кто и когда обращался к видеоматериалам.

Постусловие. Шухрат получил визуальное подтверждение состояния площадки без физического выезда. Запись просмотра сохранена.

UC-A35. Просмотр видеоархива по запросу

Сценарий. Поступило обращение от родителя ученика школы №16: «По ночам со стройплощадки слышен шум работающей техники, дети не могут спать». Это серьёзное нарушение — работы в ночное время без специального разрешения запрещены. Инспектор ГАСН Раджаббаев хочет проверить факты — посмотреть видеоархив за указанный день, чтобы установить, действительно ли велись работы ночью.

Участник: GASN_INSPECTOR — Раджаббаев.

Основной поток. Раджаббаев открывает раздел «Видеомониторинг → Архив». Выбирает камеру школы №16, дату 18.07.2026 (указанная родителем дата). Открывается интерфейс перемотки по архиву. Раджаббаев перематывает к 23:00 — на видео тихая стройка без работ. К 00:30 — видны два рабочих с инструментами, разгружают что-то с грузовика. К 02:00 — снова тишина. Раджаббаев фиксирует доказательство нарушения: ночные работы действительно велись 18.07.2026 с примерно 00:30 до 01:45.

Использует функцию «Зафиксировать находку инспекции» — заполняет акт обнаружения нарушения, прикладывает экспорт фрагмента видео (UC-A36), отправляет подрядчику предписание о устранении и штраф за нарушение порядка работ. Все действия фиксируются в журнале аудита.

Постусловие. Нарушение установлено документально через видеоархив, оформлено в виде акта инспекции, подрядчик уведомлён о штрафе.

UC-A36. Экспорт фрагмента видеоархива для доказательной базы

Сценарий. Раджаббаев из UC-A35 хочет сохранить видеофрагмент с нарушением для использования в официальном предписании ГАСН. Бумажное предписание со ссылкой на платформу — не достаточно; нужен сам видеофайл, который можно приложить к делу и предоставить при необходимости в суд.

Участник: GASN_INSPECTOR — Раджаббаев.

Основной поток. Раджаббаев в архиве камеры школы №16 указывает временной диапазон с 00:25 до 01:50 18.07.2026. Нажимает «Экспорт фрагмента». Платформа в фоне готовит MP4-файл качества Full HD, длительностью 1 час 25 минут. Через несколько минут Раджаббаев получает уведомление: «Видеофрагмент готов. Скачать: [ссылка, действительна 48 часов]». Скачивает файл объёмом около 3 ГБ. В журнале аудита фиксируется: «Раджаббаев экспортировал фрагмент архива камеры школы №16, дата 18.07.2026, время 00:25-01:50».

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

Постусловие. Видеофрагмент скачан, использован в официальной документации. Факт экспорта зафиксирован в журнале.

UC-A37. Реакция координатора на простой видеопотока

Сценарий. Камера на стройплощадке школы №25 не передаёт поток более 6 часов в течение одного рабочего дня. Это серьёзное нарушение — отсутствие видеомониторинга означает «слепую зону» на стройке. Координатор UNDP программы получает автоматическое уведомление о ситуации.

Участник: UNDP_PROGRAM_MANAGER.

Основной поток. Координатор получает уведомление через Telegram/web-push или in-app и email: «Длительный простой камеры школа №25, контракт C-2026-014. Простой 6 часов 12 минут сегодня. Подрядчик уведомлён в 12:00, но проблема не устранена». Координатор открывает карточку камеры, изучает лог простоев: камера была недоступна с 06:00 до 12:12 (после уведомления подрядчика короткий период восстановления), затем снова с 14:30 до 17:00. Связывается с представителем подрядчика по телефону. Подрядчик объясняет, что отключали электричество из-за работ в здании. Координатор отмечает причину в платформе, проверяет — действительно, в журнале работ есть отметка о работах с электричеством в это время.

Однако подрядчик не уведомил платформу заранее о плановом отключении (как требуется), поэтому небольшой штраф всё-таки начисляется — 0,1% от стоимости этапа (около 80 USD) за нарушение требования уведомления. Координатор регистрирует штраф в платформе и подписывает решение через E-IMZO/eMZO или иной согласованный механизм ЭЦП. Штраф будет удержан из ближайшей выплаты по этапу.

Постусловие. Причина простоя установлена, мелкий штраф начислен за нарушение порядка уведомления, видеопоток восстановлен.

А.7. Группа «Гарантия»

UC-A38. Регистрация гарантийного случая через QR-канал

Сценарий. Прошёл год с момента сдачи школы №16 Камашинского района после реновации. Подрядчик-гарант — ООО «РемСтройКашка». Гарантийный срок по контракту — пять лет. Через месяц после первых заморозков в одной из учебных комнат на втором этаже потекли радиаторы отопления — те самые, которые меняли в ходе реновации. Школьный завхоз Бахром обнаружил проблему утром перед началом занятий. Если протечку срочно не устранить, отопление в этом крыле школы выйдет из строя, и дети окажутся в холодных классах. Бахром — пожилой человек, у него нет привычки обращаться в районное УНО (раньше это занимало недели и часто заканчивалось ничем). Зато он знает: на школе висит QR-код, и можно через него сообщить о проблеме.

Участник: SCHOOL_STAFF — Бахром, школьный завхоз. В альтернативных сценариях участником могут быть директор школы, родитель ученика или представитель махалли.

Предусловие. Школа №16 находится в гарантийном периоде по контракту с ООО «РемСтройКашка». QR-код размещён на здании школы.

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

Основной поток. Бахром сканирует QR-код у входа в школу с помощью своего телефона. Открывается публичная страница школы №16. Бахром видит, что школа находится в статусе «В гарантийном периоде, до 2031 года, подрядчик ООО „РемСтройКашка”». Бахром нажимает «Жалоба по инфраструктуре», в категории выбирает «Отопление», в подкатегории — «Протечка радиатора». В тексте описывает проблему, прикладывает фото. Платформа показывает выбор режима: быстрый открытый сигнал без телефона либо формальное гарантийное обращение с SMS-OTP. Для запуска гарантийного SLA и индивидуального трекинга Бахром выбирает формальный режим, указывает телефон, получает SMS-код и подтверждает номер; телефон хранится как хэш и не публикуется.

Платформа автоматически анализирует обращение: контракт «Замена системы отопления» по школе №16, исполнитель — ООО «РемСтройКашка», дата ввода в эксплуатацию — 15.09.2025, гарантийный срок — 5 лет, истекает 15.09.2030. Дефект «протечка радиатора» относится к категории, подпадающей под гарантию. Обращение моментально переклассифицируется из обычной жалобы в гарантийный случай. Приоритет — «критический» (отопление в учебном заведении в начале отопительного сезона). SLA на реагирование подрядчика: 24 часа на подтверждение приёма, 48 часов на выезд, 7 рабочих дней на устранение.

Маршрутизация: обращение видно на дашбордах директора школы, районного УНО, областного УНО, координатора программы UNDP, ответственного лица в ООО «РемСтройКашка» (зарегистрировано в личном кабинете подрядчика как «контактное лицо по гарантийным обязательствам» — это требование при подписании контракта). Платформа моментально отправляет уведомление через Telegram-бот, web-push или in-app представителя подрядчика и SMS на номер ответственного лица.

В течение 18 часов представитель подрядчика — Дильшод, ответственный за гарантию по контрактам в Кашкадарьинской области — открывает обращение в Telegram MiniApp или адаптивном веб-интерфейсе. Нажимает «Принимаю в работу», указывает: «Выезд завтра, 09:00, бригада из двух мастеров. Будут заменены прокладки радиатора и регулирующие краны. Предварительно понадобится отключить отопление в одном крыле на 2 часа». Платформа фиксирует приём, останавливает первый таймер SLA, включает следующий: 48 часов на выезд.

На следующий день в 09:00 бригада прибывает на школу. Дильшод через Telegram MiniApp или адаптивный веб-интерфейс отмечает «Прибыли на объект», прикладывает фото бригады и неисправного радиатора. К 13:00 работы завершены. Дильшод отмечает «Устранено», прикладывает фото отремонтированного радиатора и пол без воды. Бахром через свой личный кабинет подтверждает: «Подтверждаю устранение. Тепло идёт нормально, протечки нет». Обращение закрывается со статусом «Устранено в SLA».

Платформа фиксирует факт устранения в реестре гарантий, отмечает контракт ООО «РемСтройКашка» отметкой «Гарантийные обязательства исполнены своевременно по случаю CF-2026-10-15-00892». Это положительная отметка в рейтинге подрядчика.

Альтернативный поток (нарушение SLA). Если подрядчик не реагирует в течение 24 часов на подтверждение приёма, платформа автоматически эскалирует обращение на координатора программы UNDP и начисляет первичный штраф (0,1% от суммы контракта). Если выезд не происходит в течение 48 часов — повторная эскалация и удвоение штрафа. Систематические нарушения (три и более просрочки в году) приводят к рассмотрению вопроса о внесении подрядчика в чёрный список (UC-A13).

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

UC-A39. Реагирование подрядчика на гарантийный случай

Сценарий. Дильшод из UC-A38 — ответственный за гарантию по контрактам ООО «РемСтройКашка» в Кашкадарьинской области. Получает уведомление о гарантийном случае по школе №16 (протечка радиатора). Это требует оперативной реакции — несоблюдение SLA приведёт к штрафам, повторение случаев — к попаданию в чёрный список. У него есть отлаженная процедура работы.

Участник: CONTRACTOR_REPRESENTATIVE — Дильшод.

Основной поток. Дильшод получает SMS и уведомление через Telegram/web-push или in-app: «Гарантийный случай — школа №16, протечка радиатора. SLA на подтверждение приёма: 24 часа. SLA на выезд: 48 часов. SLA на устранение: 7 рабочих дней». Открывает обращение в Telegram MiniApp или адаптивном веб-интерфейсе. Изучает фотографии, обсуждает с дежурным мастером по телефону. Через 18 часов нажимает «Принимаю в работу», указывает: «Выезд завтра в 09:00, бригада из двух человек».

На следующий день в 09:00 бригада прибывает на школу. Дильшод отмечает «Прибыли на объект», прикладывает фото неисправного радиатора. Бригада меняет прокладку и регулирующие краны. К 13:00 работы завершены. Дильшод отмечает «Устранено», прикладывает фото отремонтированного радиатора и фото пола без воды. Бахром (завхоз) через свой личный кабинет подтверждает устранение.

Дильшод регистрирует подписанный акт устранения, который Бахром подтвердил. Гарантийный случай закрывается. В рейтинге компании ООО «РемСтройКашка» фиксируется положительное реагирование в SLA.

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

UC-A40. Сезонное обслуживание оборудования

Сценарий. В школе №15 установлен тепловой насос производителем ООО «СамаркандЭнергоСистем». По контракту производитель обязан проводить ежегодное предотопительное обслуживание оборудования. Сезон — конец сентября, перед началом отопительного сезона. Раньше такие обязательства часто игнорировались — никто не отслеживал. Платформа делает это автоматически.

Участник: CONTRACTOR_REPRESENTATIVE — Сардор, директор ООО «СамаркандЭнергоСистем».

Основной поток. В сентябре платформа автоматически создаёт seasonal_maintenance_task: «Сезонное обслуживание теплового насоса школы №15 Ангорского района. Дедлайн: 30.09.2026. Подрядчик: ООО „СамаркандЭнергоСистем”». Сардор получает уведомление по email и Telegram/web-push или in-app. Открывает задачу, планирует выезд бригады. Бригада приезжает 25 сентября, проводит ТО (промывка теплообменника, проверка элементов, диагностика), регистрирует отчёт в платформе с приложением фото и протокола работ. Школа в лице директора подтверждает выполнение. Платформа фиксирует задачу как выполненную.

Альтернатива (не выполнено в срок). Если подрядчик пропустил дедлайн, задача переходит в статус «просрочено», начисляется небольшой штраф, эскалируется на координатора программы. Систематический пропуск приводит к серьёзным санкциям.

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

UC-A41. Автоматическое завершение пятилетней гарантии

Сценарий. 28 июня 2031 года — ровно 5 лет с момента финальной приёмки школы №15 Ангорского района (UC-A23). По всем контрактам по этой школе истекает гарантийный период. Платформа автоматически инициирует процесс закрытия гарантии и формирует финальные отчёты.

Участник: Система (автоматически).

Основной поток. 28 июня 2031 года в 00:00 платформа автоматически: - Переводит все контракты по школе №15 из статуса «in_warranty» в «post_warranty». - Формирует финальный отчёт по гарантийному периоду каждого контракта: количество гарантийных случаев (15 за 5 лет), среднее время устранения (4,2 рабочих дня), штрафы (0 — все случаи устранены в SLA), общая оценка работы подрядчика по гарантии («отлично»). - Отправляет уведомления подрядчикам ООО «СтройМонтажТермез», ООО «СамаркандЭнергоСистем» и другим: «Гарантийный период по контракту C-2026-001 завершён. Поздравляем с успешным завершением гарантийных обязательств». - Публикует на странице школы статус «В режиме обычной эксплуатации». - Сохраняет полную историю гарантийного периода в архиве (хранение 10 лет).

С этого момента новые гарантийные случаи по школе не принимаются. Если в школе возникнут проблемы — она будет обрабатываться через обычные каналы общественной обратной связи и рассматриваться как объект обычного капитального ремонта.

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

А.8. Группа «Аудит и контроль»

UC-A42. Постаудит КРУ через 6 месяцев после ввода в эксплуатацию

Сценарий. Прошло 6 месяцев с момента финальной приёмки школы №15. По нормативам, КРУ должно провести шестимесячный аудит — независимую финансовую и техническую проверку выполнения работ. Это обязательная процедура, гарантирующая качество и финансовую прозрачность. КРУ-аудитор Илхом получает автоматическое уведомление от платформы о необходимости провести аудит.

Участник: KRU_AUDITOR — Илхом, аудитор Контрольно-ревизионного управления.

Основной поток. Платформа за 7 дней до даты автоматически генерирует KRU_audit_request: «Школа №15 Ангорского района. Прошло 6 месяцев с финальной приёмки 28.06.2026. Готов пакет материалов для аудита». Илхом открывает запрос, видит автоматически собранный пакет: все этапные акты (8 актов по общестрою + 5 по тепловым насосам + 4 по септику + 2 по материалам), полный фотоархив с группировкой по этапам, видеоархив 30 дней до приёмки, ссылки на видеозаписи ключевых событий, финансовая сводка (общая сумма 2,8 млн USD, выплачено 2,66 млн, удержание 140 тыс, возвращено retention 140 тыс), реестр обращений граждан, гарантийных случаев, ответов на них.

Илхом изучает материалы из офиса в Ташкенте, выбирает 3 контракта для углублённой проверки. Через 2 недели выезжает с группой на школу №15. Физически проверяет качество выполненных работ, опрашивает директора и завхоза, делает свои фотографии. Возвращается, подготавливает заключение КРУ. Загружает заключение в платформу со ссылкой на конкретные проверенные элементы. Заключение фиксируется как событие в истории школы и каждого контракта. Если есть замечания — формируется задача на устранение для соответствующего подрядчика.

Постусловие. Постаудит КРУ проведён, заключение зафиксировано. Если замечания есть — запущен процесс их устранения подрядчиками (за свой счёт, в рамках гарантийных обязательств).

UC-A43. Внешний независимый аудит платформы

Сценарий. В рамках ежегодного независимого аудита программы Joint Programme UNDP нанимает международную аудиторскую фирму PwC для проведения проверки прозрачности и целостности процессов. Один из аспектов проверки — состояние платформы МБШ: насколько надёжен журнал аудита, можно ли отследить все ключевые действия, есть ли подозрительные операции. Старший аудитор Мария получает временный доступ к платформе на 2 недели.

Участник: PLATFORM_AUDITOR — Мария, независимый аудитор PwC (с временным аккредитованным доступом).

Основной поток. Мария входит в платформу с выданными аккредитованными правами. Эти права ограниченные: только чтение журнала аудита M18, без возможности изменения данных, с обязательной фиксацией всех её действий в журнале (мета-аудит). Мария открывает раздел «Журнал аудита». Применяет фильтры: период «01.01.2026 – 30.06.2026», типы действий «выплаты», «подписания актов», «изменения прав доступа», «внесение в чёрный список». Видит около 12 тысяч записей.

Мария проводит выборочную проверку: открывает несколько случайных записей о выплатах и проверяет, действительно ли каждая выплата привязана к подписанному акту с полным комплектом доказательств. Проверяет случайные подписания актов — действительно ли все подписи получены до факта выплаты (а не задним числом). Проверяет криптоцепочку хэшей — целостность журнала. Платформа моментально подтверждает: все записи целостны, цепочка непрерывна, нет следов подделки.

Мария экспортирует выборки в Excel для своего отчёта. Все экспорты регистрируются. Через 2 недели Мария завершает аудит, сдаёт отчёт UNDP. Доступ автоматически отзывается. В журнале остаётся запись о всех её действиях за период.

Постусловие. Аудит завершён. UNDP получил независимое подтверждение целостности платформы. Все действия аудитора зафиксированы.

UC-A44. Расследование коррупционного сигнала Anti-Corruption Agency

Сценарий. В Anti-Corruption Agency (ACA) поступил анонимный сигнал о возможной коррупционной схеме: «Подрядчик X систематически получает контракты UNDP в Сурхандарьинской области, хотя есть предположения о фиктивных тендерах и сговоре с менеджером по закупкам». Это серьёзное обвинение, требующее проверки. ACA-офицер Ботир получает задание провести предварительное расследование.

Участник: ACA_OFFICER — Ботир, сотрудник Anti-Corruption Agency.

Основной поток. Ботир входит в платформу под ролью ACA_OFFICER, которая даёт ему полный read-доступ ко всем материалам платформы (без права изменения). В разделе «Подрядчики» находит указанную компанию. Видит её профиль: 7 выигранных контрактов по 7 школам Сурхандарьинской области за последний год, общая сумма 5,2 миллиона USD, рейтинг «хороший» (без штрафов, в SLA).

Ботир изучает тендерные процедуры каждого контракта: участники, оценочные критерии, протоколы решений. По всем 7 тендерам подрядчик участвовал и выиграл. По 6 тендерам было всего 2-3 участника — что не само по себе подозрительно, но может указывать на проблемы. Ботир проверяет конкурентов: они существуют, имеют опыт, но их предложения были существенно дороже (на 12-18%). Ботир переходит к проверке UBO: владелец подрядчика — Каримов Ш., не имеет официальных связей с UNDP или МДшО.

Через журнал аудита M18 Ботир проверяет действия менеджера по закупкам по этим тендерам. Все процедуры выполнены формально корректно, ничего подозрительного. Ботир также изучает доказательную базу выполненных работ по этим контрактам: фотоотчёты есть, видеомониторинг работал, акты подписаны в SLA, гарантийные случаи устраняются.

По итогам предварительного расследования Ботир делает вывод: формальных признаков коррупции не выявлено, но рекомендуется провести более глубокое разбирательство по обстоятельствам тендерных процедур (например, проверка нерабочих связей участников). Готовит отчёт для руководства ACA. Все его действия в платформе зафиксированы в мета-аудите.

При необходимости (если выявится коррупционная схема) ACA-офицер может обратиться в UNDP с просьбой приостановить активные контракты подрядчика — это делается через UNDP_PROGRAM_MANAGER (UC-A21).

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

А.9. Группа «Администрирование»

UC-A45. Управление справочниками платформы

Сценарий. В программе появился новый тип пакета работ — «Установка солнечных панелей». До этого справочник содержал 4 типа (общестрой, тепловые насосы, септик, материалы), теперь нужно добавить пятый. Это типичная задача администратора платформы — обновлять справочники по мере изменения программы.

Участник: PLATFORM_ADMIN.

Основной поток. Администратор открывает раздел «Справочники → Типы пакетов работ». Видит существующие 4 типа с возможностью добавления новых. Нажимает «Добавить». Заполняет: код «SOLAR», название «Установка солнечных панелей», описание, типовые этапы (5 этапов), привязка к производителям оборудования. Сохраняет.

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

Все действия администратора (создание, изменение, архивация справочников) записываются в журнал аудита M18 — кто, когда, что изменил.

Альтернатива (архивация). Если какой-то тип работ перестаёт быть актуальным, администратор не удаляет его, а архивирует. Существующие контракты с этим типом продолжают работать, но новые не могут быть созданы. Это защищает целостность исторических данных.

Постусловие. Новый тип пакета работ доступен в платформе. История изменения справочника сохранена.

UC-A46. Управление шаблонами чек-листов этапов работ

Сценарий. По итогам пилота 2026 года инженерная команда UNDP+UNICEF подметила, что в чек-листе этапа «Утепление стен» не хватает важного пункта — проверки качества армирующего слоя перед нанесением финишной отделки. На следующий год нужно обновить чек-лист, чтобы технадзор проверял этот аспект во всех будущих работах.

Участник: PLATFORM_ADMIN или UNDP_PROGRAM_MANAGER.

Основной поток. Координатор открывает «Справочники → Чек-листы → Общестрой → Утепление стен». Видит текущую версию чек-листа (v1.2). Добавляет новый пункт: «Армирующий слой выполнен в соответствии с ПСД (толщина, материал, отсутствие пузырей)». Указывает требование к фотодоказательству. Сохраняет как новую версию v1.3 с пометкой «действует с 01.01.2027».

Платформа применяет новую версию ко всем новым контрактам с 01.01.2027. Существующие контракты, заключённые ранее, продолжают использовать v1.2. Это защищает подрядчиков от изменения условий в ходе выполнения контракта.

Постусловие. Новая версия чек-листа активна с указанной даты. Прошлые версии сохранены и применяются к существующим контрактам.

UC-A47. Обновление шаблонов уведомлений

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

Участник: PLATFORM_ADMIN.

Основной поток. Администратор открывает «Справочники → Шаблоны уведомлений», находит шаблон «Ответ на обращение». Открывает редактор: вкладки русский, узбекский (латиница), английский. Обновляет текст на русском: «Здравствуйте! По вашему обращению опубликован ответ. Посмотреть: {link}. Спасибо за вашу активную позицию» (вместо сухого «По вашему обращению опубликован ответ»). Аналогично обновляет узбекскую и английскую версии. Запускает тестовую рассылку на собственный номер, проверяет, как выглядит сообщение. Активирует новую версию шаблона.

Все новые ответы на обращения теперь отправляются с обновлённым текстом. Старые SMS, отправленные до изменения, не пересылаются.

Постусловие. Шаблон уведомления обновлён, новая версия применяется ко всем последующим уведомлениям этого типа.

UC-A48. Регистрация нового пользователя и привязка к ролям

Сценарий. В Областное управление МДшО Сурхандарьи назначен новый специалист по программам строительства — Жасур Тошматов. Он будет работать с программой Joint Programme. Нужно зарегистрировать его в платформе с соответствующей ролью.

Участник: PLATFORM_ADMIN.

Основной поток. Администратор открывает «Пользователи → Новый». Заполняет: ФИО (Тошматов Жасур), email (служебный), мобильный телефон, должность (специалист по программам строительства), привязка к организации (Областное управление МДшО Сурхандарьи). Выбирает роль: REGIONAL_EDU_STAFF (специалист областного уровня) со scope «Сурхандарьинская область». Отправляет приглашение.

Жасур получает служебное уведомление о создании учётной записи. Активация выполняется через OneID/SSO либо через процедуру, утверждённую владельцем государственной ИС; для действий с правовыми последствиями используется E-IMZO/eMZO или иная согласованная национальная инфраструктура ЭЦП. После активации получает доступ к платформе с правами своей роли — видит школы Сурхандарьинской области, обращения граждан по этим школам, может реагировать на них в рамках своих полномочий.

Альтернатива (отзыв роли). Если сотрудник переводится на другую должность или увольняется, администратор отзывает или меняет роль. Учётная запись не удаляется (для сохранения истории действий в журнале аудита), но переводится в статус «blocked».

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

Приложение Б — ПОЛНАЯ МАТРИЦА RBAC

Б.1. Принципы

Доступ задаётся через permission в формате {module}:{action}:{scope}.
Действия: read, create, update, delete, sign, approve, reject, export.
Scope: own (только свои объекты), school (одна школа), district, region, republic, all_public.
По умолчанию — запрет.
Роль — набор разрешений.
Пользователь — одна или несколько ролей.

Б.2. Полная матрица (фрагменты по модулям)

Модуль M1 (Пользователи и организации)

Роль ↓ / Право →	organizations:read	organizations:create	organizations:update	ubo:read	ubo:update	users:read	users:invite	roles:assign
PUBLIC	—	—	—	—	—	—	—	—
CITIZEN_AUTH	—	—	—	—	—	self	—	—
CONTRACTOR_REP	own	—	own basic	own	own	own org	—	—
CONTRACTOR_FIELD	—	—	—	—	—	self	—	—
DESIGN_REP	own	—	own basic	own	own	own org	—	—
SCHOOL_DIR	own	—	—	—	—	own school	—	—
DISTRICT_EDU	district	—	—	—	—	district	district	—
REGIONAL_EDU	region	—	—	—	—	region	region	—
REGIONAL_HOKIM	region	—	—	—	—	region	—	—
MOPSE	republic	—	—	—	—	republic	republic	—
UNDP_PM	all	—	—	all	—	all	all	—
UNDP_PROC	all	all	all	all	all	all	all	—
UNDP_FIN	all	—	—	—	—	all	—	—
UNDP_INT	all	—	—	all	—	all	—	—
GASN	all	—	—	—	—	own role	—	—
KRU	all	—	—	all	—	own role	—	—
ACA	all	—	—	all	—	own role	—	—
UNICEF	all	—	—	—	—	self	—	—
CSAC	all	—	—	all	—	self	—	—
NGO	all	—	—	—	—	self	—	—
PLATFORM_ADMIN	all	all	all	all	all	all	all	all
PLATFORM_SEC	all	—	—	all	—	all	—	all
PLATFORM_AUD	all	—	—	all	—	all	—	—

Модуль M2 (Паспорт школы)

Роль ↓ / Право →	schools:read:basic	schools:read:full	schools:import	schools:update:photo	schools:update:extended	schools:archive	schools:export
PUBLIC	all_public	—	—	—	—	—	—
CITIZEN_AUTH	all_public	—	—	—	—	—	—
CONTRACTOR_REP	own contract	own contract	—	—	—	—	—
SCHOOL_DIR	own	own	—	own	—	—	own
DISTRICT_EDU	district	district	—	district	—	—	district
REGIONAL_EDU	region	region	—	region	—	—	region
UNDP_PM	all	all	all	all	all	—	all
MOPSE	republic	republic	all	all	all	all	republic

Модуль M3 (Оценка и скоринг)

Роль ↓ / Право →	assessments:create	assessments:update_own	assessments:submit	assessments:validate	assessments:read	scoring_methods:read	scoring_methods:update
EVALUATOR	yes	yes	yes	—	own	yes	—
VALIDATOR	—	—	—	yes	all	yes	—
UNDP_PM	—	—	—	—	all	yes	—
SCHOOL_DIR	—	—	—	—	own school	—	—
PUBLIC	—	—	—	—	aggregated public	—	— (только PLATFORM_ADMIN)

Модуль M5 (Тендеры и контракты)

Роль ↓ / Право →	procurement:read	procurement:create	contracts:read	contracts:sign	contracts:amend	blacklist:read	blacklist:add
PUBLIC	basic	—	basic	—	—	basic	—
CITIZEN_AUTH	basic	—	basic	—	—	basic	—
CONTRACTOR_REP	own	—	own	own	—	own status	—
DESIGN_REP	own	—	own	own	—	own status	—
UNDP_PROC	all	all	all	all	all	all	—
UNDP_PM	all	—	all	—	—	all	—
UNDP_FIN	all	—	all	—	—	all	—
UNDP_INT	all	—	all	—	—	all	all
DISTRICT_EDU	district	—	district	—	—	all	—
REGIONAL_EDU	region	—	region	—	—	all	—
MOPSE	republic	—	republic	—	—	all	—

Модуль M9 (Доказательная база)

Роль ↓ / Право →	evidence:upload	evidence:read	evidence:annotate	evidence:flag
CONTRACTOR_REP	own	own	own	—
CONTRACTOR_FIELD	own	own	—	—
REGIONAL_ENG	—	own region	own region	own region
GASN	—	own region	—	own region
UNDP_PM	—	all	all	all
UNDP_INT	—	all	all	all
KRU	—	all	—	—
PUBLIC	—	aggregated public	—	—

Модуль M11 (Обратная связь)

Роль ↓ / Право →	feedback:submit	feedback:read	feedback:respond	feedback:moderate_spam
PUBLIC	—	public_anonymized	—	—
CITIZEN_AUTH	yes	own_submitted	—	—
SCHOOL_DIR	—	own school	own school	—
DISTRICT_EDU	—	district	district	—
REGIONAL_EDU	—	region	region	—
UNDP_PM	—	all	all	—
CONTRACTOR_REP	—	own contract	own contract	—
UNDP_INT	—	all	—	yes

Модуль M12 (Верификация)

Роль ↓ / Право →	verifications:submit_stage	verifications:approve_stage	verifications:reject_stage	inspections:register	inspections:finalize
CONTRACTOR_REP	own	—	—	—	—
REGIONAL_ENG	—	own region	own region	—	—
GASN	—	—	—	own region	own region
KRU	—	—	—	own region	own region
UNDP_PM	—	own program	own program	own program	—

Модуль M18 (Журнал аудита)

Роль ↓ / Право →	audit_log:read	audit_log:export
PLATFORM_AUD	full	full
PLATFORM_SEC	full	full
ACA	filtered by entity	filtered
KRU	filtered by entity	filtered
OTHER	—	—

Полная матрица для всех 20 модулей и всех 29 ролей формируется как отдельная таблица Excel и прикладывается к ТЗ.

Приложение В — МОДЕЛЬ ДАННЫХ (РАСШИРЕННАЯ)

В.1. Глоссарий ключевых сущностей

School (Школа)

school_id (UUID, PK)
national_id (внешний ID Замонавий мактаб; уникальный)
name_ru, name_uz, name_en (TEXT)
short_name (TEXT)
region_id, district_id, mahalla_id (FK на справочники)
settlement (TEXT)
address (TEXT)
geo_lat, geo_lng (DECIMAL)
geo_polygon (GeoJSON)
school_type (PUBLIC / PRIVATE / SPECIALIZED)
capacity_official (INT)
students_count, students_male, students_female (INT)
teachers_count, teachers_male, teachers_female (INT)
year_built (INT)
building_count (INT)
buildings (JSON: массив зданий с параметрами)
contacts (JSON: имя директора, телефон, email)
official_documents (JSON: ссылки на свидетельства)
status (active / in_renovation / commissioned / in_warranty / post_warranty / archived)
created_at, updated_at (TIMESTAMP)
created_by (FK user)

KoboAssessment

assessment_id (UUID)
school_id (FK)
assessor_id (FK user)
assessment_date (DATE)
form_version (TEXT)
group_general, group_heating, group_electricity, group_construction, group_wash_current, group_wash_planned (JSON)
photos (JSON: массив фотографий с геометками и подписями)
score_total (DECIMAL)
score_by_criteria (JSON: 8 критериев)
status (draft / submitted / validated / returned_for_revision / archived)
validator_id, validated_at
comments_history (JSON)

SchoolProgramInclusion

inclusion_id (UUID)
school_id, program_year, kobo_assessment_id (FK)
score (DECIMAL)
funding_source (FK на REF_FUNDING_SOURCES)
decision_reference (TEXT)
justification (TEXT)
included_by, included_at
status (active / removed)

ProgramYear

program_id (UUID)
year (INT)
name (TEXT)
funding_source (FK)
total_budget (DECIMAL)
target_schools_count (INT)
status (draft / under_discussion / approved / in_execution / completed / archived)
approved_by, approved_at
schools (массив school_id через SchoolProgramInclusion)

ProcurementEvent

procurement_id (UUID)
type (PSD_TENDER / WORK_TENDER / SUPPLY_TENDER)
subtype (для WORK_TENDER: GENERAL / HEAT / SEPTIC / HYGIENE)
school_ids (массив; может быть один или группа)
quantum_reference (TEXT)
subject (TEXT)
budget_max (DECIMAL)
opens_at, closes_at (TIMESTAMP)
status (open / closed_with_winner / closed_without_winner)
winner_organization_id (FK)
final_price (DECIMAL)
participants (JSON: массив участников с оценками)

Contract

contract_id (UUID)
procurement_event_id (FK)
school_id (или JSON массив для группы школ)
contractor_organization_id (FK)
contract_type (PSD / WORK_GENERAL / WORK_HEAT / WORK_SEPTIC / SUPPLY)
subject (TEXT)
total_price (DECIMAL)
currency (TEXT)
start_date, end_date (DATE)
payment_schedule (JSON)
warranty_years (INT, default 5)
warranty_start, warranty_end (DATE)
status (draft / signed / in_progress / suspended / completed / closed / terminated)
documents (JSON: массив ссылок)
integrity_pact_id (FK, если применимо)
created_at, signed_at, closed_at

ContractAmendment

amendment_id (UUID)
contract_id (FK)
amendment_number (INT)
type (price_change / scope_change / schedule_change / parties_change)
description (TEXT)
old_value, new_value (JSON)
signed_at, signed_by_contractor, signed_by_undp
documents (JSON)

ContractMilestone

milestone_id (UUID)
contract_id (FK)
sequence_no (INT)
name (TEXT)
planned_start, planned_end (DATE)
actual_start, actual_end (DATE)
percent_complete (DECIMAL)
amount_due (DECIMAL)
checklist_template_id (FK)
status (pending / in_progress / submitted / under_review / verified / rejected / completed)

Evidence

evidence_id (UUID)
contract_id, milestone_id (FK)
checklist_item_ref (TEXT, если привязано к пункту)
type (photo / video / document / sensor_reading)
file_url (URL)
file_hash (TEXT)
mime_type, size_bytes (TEXT, INT)
geo_lat, geo_lng, geo_accuracy (DECIMAL)
timestamp_captured, timestamp_uploaded (TIMESTAMP)
uploaded_by (FK user)
comment (TEXT)
validation_status (pending / accepted / flagged)
flagged_reason (TEXT)
review_status (pending / verified / rejected)
reviewer_id, reviewed_at, review_comment

AcceptanceAct

act_id (UUID)
type (milestone / final_dalolatnoma)
contract_id, milestone_id, school_id (FK)
template_version (TEXT)
pdf_url, signed_pdf_url (URL)
generated_at (TIMESTAMP)
signatures (JSON: массив подписей с метаданными)
status (draft / pending_signatures / signed / cancelled)

Signature

signature_id (UUID)
act_id (FK)
signer_id (FK user)
signer_role (TEXT)
signed_at (TIMESTAMP)
geo_lat, geo_lng (DECIMAL)
signature_hash (TEXT)
esign_provider_data (JSON)

Payment

payment_id (UUID)
contract_id, milestone_id, act_id (FK)
amount (DECIMAL)
currency (TEXT)
payment_due_date, payment_actual_date (DATE)
quantum_transaction_id (TEXT, FK на UN Quantum)
retention_amount (DECIMAL, по умолчанию 5%)
penalty_amount (DECIMAL)
net_amount (DECIMAL)
status (due / pending / paid / failed / on_hold)
on_hold_reason (TEXT)

VideoStream

stream_id (UUID)
school_id, contract_id (FK)
camera_uid (TEXT)
mikrotik_router_id (TEXT)
wireguard_public_key (TEXT)
internal_ip (TEXT)
rtsp_url, http_url (URL)
status (up / down / degraded)
last_seen_at (TIMESTAMP)
storage_retention_days (INT)
registered_at, decommissioned_at

VideoStreamAvailability

record_id (UUID)
stream_id (FK)
hour (TIMESTAMP, округлённый до часа)
uptime_minutes (INT)
downtime_minutes (INT)

CitizenFeedback

Настоящая редакция уточняет модель CitizenFeedback: одна сущность покрывает open public_signal, formal_appeal, warranty_signal и positive_review. Режим подачи определяется полями auth_level и is_formal_appeal; отсутствие телефона не блокирует создание public_signal, но блокирует индивидуальный официальный ответ и трекинг до прохождения SMS-OTP.

feedback_id (UUID)
school_id (FK)
contract_id (FK, опционально)
channel (qr / responsive_web / telegram_miniapp / sms / ussd_future)
category (infrastructure_complaint / contractor_complaint / positive_review / photo_submission)
subcategory (FK на справочник)
title (TEXT)
text (TEXT)
photos (JSON: массив фото с геометками)
submitter_phone_hash (TEXT, nullable)
submitter_name (TEXT, опционально)
auth_level (anonymous_signal / sms_verified / registered_user)
is_formal_appeal (BOOL)
response_tracking_token (TEXT, nullable)
priority (urgent_important / urgent_not_important / not_urgent_important / not_urgent_not_important)
routing (JSON: список получателей)
sla_due_at (TIMESTAMP)
status (new / acknowledged / in_progress / resolved / escalated / closed_with_response / closed_no_action / marked_as_spam)
responses (JSON: массив ответов)
public_visibility (BOOL)
spam_reason (TEXT)
created_at, updated_at

WarrantyCase

warranty_case_id (UUID)
school_id, contract_id (FK)
defect_category (FK на справочник)
severity (critical / minor)
description (TEXT)
reported_by (FK user или цитата от гражданина с обезличиванием)
reported_at (TIMESTAMP)
evidence_refs (JSON)
sla_response_due, sla_resolution_due (TIMESTAMP)
contractor_acknowledged_at, contractor_visited_at, contractor_resolved_at
resolution_status (in_progress / resolved / disputed / escalated / closed)
resolution_evidence (JSON)
school_confirmation (JSON)
penalty_amount (DECIMAL)
created_at, updated_at

IntegrityPact

pact_id (UUID)
contract_id (FK)
undp_party (FK organization)
contractor_party (FK organization)
monitor_party (FK organization — CSAC или NGO)
signed_at (TIMESTAMP)
terms (JSON)
monitor_reports (JSON: массив отчётов)
status (active / completed / breached)

Notification

notification_id (UUID)
template_id (FK на REF_NOTIFICATION_TEMPLATES)
recipient_user_id (FK)
recipient_channel (email / sms / telegram / web_push / in_app)
subject (TEXT)
body (TEXT)
payload (JSON)
sent_at, delivered_at, read_at (TIMESTAMP)
status (queued / sent / delivered / failed / read)
retry_count (INT)

AuditLog

log_id (UUID)
event_time (TIMESTAMP)
event_type (TEXT)
actor_user_id, actor_role (FK, TEXT)
actor_ip (TEXT)
entity_type, entity_id (TEXT, UUID)
action (TEXT)
before_state, after_state (JSON snapshot)
request_id, session_id (TEXT)
geo_context (JSON)
prev_log_hash, current_hash (TEXT) — криптоцепочка

Penalty

penalty_id (UUID)
contract_id, contractor_id (FK)
penalty_type (FK на REF_PENALTY_RULES)
amount (DECIMAL)
reason (TEXT)
supporting_event_id (FK)
applied_at (TIMESTAMP)
applied_by (FK user)
payment_id (FK, если уже удержано)

Blacklist

blacklist_id (UUID)
organization_id (FK)
reason (TEXT)
supporting_events (JSON)
start_date, end_date (DATE)
decided_by (FK user)
decision_act_url (URL)
status (active / lifted)

В.2. Связи между сущностями (ключевые)

School ←→ KoboAssessment (1:N)
School ←→ Contract (1:N)
School ←→ CitizenFeedback (1:N)
School ←→ WarrantyCase (1:N)
Contract ←→ ContractMilestone (1:N)
Contract ←→ ContractAmendment (1:N)
Contract ←→ AcceptanceAct (1:N)
Contract ←→ Payment (1:N)
Contract ←→ VideoStream (1:N)
Contract ←→ Penalty (1:N)
Contract ←→ IntegrityPact (1:0..1)
ContractMilestone ←→ Evidence (1:N)
ContractMilestone ←→ AcceptanceAct (1:1 для milestone-актов)
AcceptanceAct ←→ Signature (1:N)
Все сущности ←→ AuditLog (1:N через event records)

В.3. Справочники (REF_*)

REF_REGIONS — справочник областей РУз с кодами.
REF_DISTRICTS — районы с привязкой к области.
REF_MAHALLAS — махалли с привязкой к району.
REF_WORK_PACKAGE_TYPES — типы пакетов работ.
REF_WORK_STAGE_TEMPLATES — типовые этапы по типу пакета.
REF_CHECKLIST_TEMPLATES — типовые чек-листы по этапам.
REF_DEFECT_CATEGORIES — категории дефектов для гарантийных случаев.
REF_FEEDBACK_CATEGORIES — категории обращений.
REF_FEEDBACK_SUBCATEGORIES — подкатегории.
REF_SLA_RULES — SLA по комбинации (категория × приоритет).
REF_PRIORITY_MATRIX — правила определения приоритета.
REF_ROLES — роли.
REF_PERMISSIONS — разрешения.
REF_DOCUMENT_TEMPLATES — шаблоны актов, далолатнамы, отчётов.
REF_FUNDING_SOURCES — источники финансирования.
REF_NOTIFICATION_TEMPLATES — шаблоны уведомлений на трёх языках.
REF_PENALTY_RULES — правила начисления штрафов.
REF_SCORING_METHODS — версии методики скоринга.
REF_LANGUAGES — поддерживаемые языки.

Приложение Г — СПЕЦИФИКАЦИЯ ИНТЕГРАЦИЙ

Это приложение детализирует требования подраздела 4.1.2 (взаимодействие со сторонними информационными системами). Платформа МБШ не существует в изоляции — она получает данные от UN Quantum (контракты, выплаты), от Замонавий мактаб (паспорта школ), от шлюзов SMS (идентификация граждан), от ГАСН (видеопотоки), и в перспективе — от Шафофф, АИС «Капитал қурилиш», Геопортала АСР. Качество этих интеграций определяет, насколько живой будет платформа: интеграция с UN Quantum обеспечивает поступление контрактных данных в реальном времени, интеграция с Замонавий мактаб — единый идентификатор школы по всей стране, интеграция с ГАСН — возможность дистанционного надзора.

Каждая интеграция описана в формате, достаточном для технической реализации: тип (REST API / файловый обмен / push), методы аутентификации, ключевые endpoints, маппинг полей, частота синхронизации, обработка ошибок. Для интеграций, по которым на момент написания ТЗ не известны конкретные API внешней системы (например, Шафофф или АИС «Капитал қурилиш»), указано минимальное требование к функциональности и обязательство подрядчика согласовать конкретные спецификации с владельцем системы на этапе разработки.

Г.1. И-1. UN Quantum

Назначение: Получение данных о тендерах, контрактах, платежах. Уведомление о готовности выплат.

Тип: REST API, синхронный и асинхронный.

Authentication: mTLS либо OAuth 2.0 client credentials в профиле, согласованном с владельцем интеграции; приоритет для межсистемного обмена — mTLS и серверные сертификаты.

Ключевые endpoints для read-only синхронизации тендеров и контрактов утверждаются совместным протоколом UN CO Procurement и подрядчика-разработчика на этапе подписания контракта на разработку. На пилоте используется ручной экспорт XLSX и периодический pull через личный кабинет закупщика UNDP.

Endpoint	Метод	Назначение	Частота
/v1/procurements	GET	Список тендеров с фильтрами (status, dateFrom, dateTo)	Каждые 15 минут
/v1/procurements/{id}	GET	Детали тендера	По требованию
/v1/procurements/{id}/participants	GET	Участники тендера	После закрытия
/v1/contracts	GET	Список контрактов	Каждые 30 минут
/v1/contracts/{id}	GET	Детали контракта	По требованию
/v1/contracts/{id}/milestones	GET	Этапы контракта (если ведутся в Quantum)	По требованию
/v1/payments	GET	Выплаты	Каждый час
/v1/payments/{id}	GET	Детали выплаты	По требованию
/v1/events/payment-ready	POST	Уведомление о готовности к оплате	По событию
/v1/events/contract-status-change	POST	Уведомление об изменении статуса	По событию

Формат запросов/ответов: JSON.

Обработка ошибок: - HTTP 4xx — логирование, не повторять. - HTTP 5xx — повтор с экспоненциальной задержкой (1, 2, 4, 8, 16 минут), не более 5 попыток. - При недоступности более 1 часа — алерт администратору, переход в ручной режим (UNDP_PROCUREMENT вводит данные с обязательным комментарием).

Маппинг полей:

UN Quantum	MBS
procurement.id	procurement_event.quantum_reference
procurement.subject	procurement_event.subject
contract.id	contract.quantum_reference
contract.totalAmount	contract.total_price
payment.id	payment.quantum_transaction_id
payment.amount	payment.amount

Г.2. И-2. Замонавий мактаб (Uzinfocom School Passport)

Назначение: Единый идентификатор школы, базовые атрибуты.

Фаза 1 (пилот): ручная выгрузка

Формат: Excel (XLSX) или CSV (UTF-8).
Обязательные поля: national_id, name_ru, name_uz, region_code, district_code, address, geo_lat, geo_lng, capacity, students_count.
Опциональные поля: type, year_built, building_count.
Импорт через интерфейс PLATFORM_ADMIN с предварительной валидацией и отчётом.

Фаза 2 (масштабирование): API

Тип: REST API на стороне Узинфоком. Authentication: mTLS либо OAuth 2.0 в согласованном государственном профиле; социальные/публичные провайдеры идентичности не допускаются.

Endpoints (запрос):

Endpoint	Метод	Назначение
/v1/schools/{national_id}	GET	Карточка школы
/v1/schools?region={code}	GET	Список по региону
/v1/schools/changes?since={timestamp}	GET	Дельта изменений

Маппинг полей определяется на встрече 11.06.2026 с Узинфоком.

Г.3. И-3. Видеомониторинг (MikroTik + WireGuard)

Полная техническая спецификация — см. Приложение З.

Г.4. И-4. Шафофф (tender.mc.uz) — Read-only при масштабировании

Назначение: Получение данных о тендерах школьного строительства при переходе на бюджетное финансирование.

Скоуп: Только тендерные процедуры (Шафофф не содержит данных о ходе строительства).

Endpoints (актуальный статус): спецификация уточняется совместно с владельцем системы на этапе подписания контракта на разработку. На пилоте используется согласованный CSV/XLSX импорт по утверждённой форме (см. Plan B).

Endpoint	Метод	Назначение
/api/tenders	GET	Список тендеров
/api/tenders/{id}	GET	Детали тендера
/api/contracts	GET	Контракты
/api/winners	GET	Победители

Authentication: открытый интеграционный риск R-05. На пилоте система работает через UN Quantum (см. И-1) без обращения к Шафофф. Acceptance criterion: после согласования с командой Шафофф (точка входа — Минстрой / DSHK через Загрутдинова М.Р.) система должна поддержать read-only integration profile с OAuth 2.0 client credentials или API key как минимум для эндпоинтов тендеров, контрактов, актов СМР. До получения API — read-only парсинг публичной части tender.mc.uz / shaffofqurilish.uz как fallback.

Г.5. И-5. АИС «Капитал қурилиш» (Минфин) — Read-only при масштабировании

Назначение: Бюджетное планирование и фактические объёмы финансирования.

Текущее состояние данных: Частично пополняется вручную из Excel-таблиц, отстаёт до месяца.

Endpoints (фактический статус на 25.06.2026): API АИС «Капитал қурилиш» в настоящее время недоступен для read-only интеграции; встреча с Сирожиддином Култлиевым (Минфин, +998 71 203 50 50 доп. 01624) перенесена. Plan B: импорт ежеквартального Excel-файла Минфина по утверждённой форме (см. Приложение Г.5.1 «Excel-шаблон импорта»). Plan A после получения API: спецификация эндпоинтов и маппинг полей утверждаются совместным протоколом UNDP–Минфин в фазе масштабирования. Открытый риск R-08 (см. реестр рисков): владелец согласования — Дарья Абдалимова (UNDP) при участии С. Култлиева.

Endpoint	Метод	Назначение
/v1/projects	GET	Объекты в реестре
/v1/projects/{id}/budget	GET	Бюджет
/v1/projects/{id}/disbursements	GET	Освоение

Г.6. И-6. Геопортал АСР (asr.gov.uz/geoportal)

Назначение: Подложка карты, слой социальной инфраструктуры (11 127 школ + другие объекты).

Тип: WMS / WFS / GeoJSON.

Endpoints:

Endpoint	Метод	Назначение	Частота
WMS endpoint		Растровые слои подложки
WFS endpoint		Векторные данные (полигоны школ)
/geojson/schools.json		Школы в формате GeoJSON

Authentication: открытый интеграционный риск R-05b. Delivery Unit (Азиза Умарова) — точка входа для согласования. Acceptance criterion: read-only integration profile с OAuth 2.0 или API key после согласования. На пилоте Delivery Unit получает данные через email-отчёты и доступ к публичному порталу M19; полноценная интеграция — фаза масштабирования.

Г.7. И-7. ГАСН — обмен видеопотоком

Назначение: Совместное использование одного видеопотока со стройплощадки между МБШ и ГАСН.

Архитектура: - Один поток RTSP от камеры через VPN. - На стороне МБШ — медиасервер с релеем для нескольких потребителей. - ГАСН подключается к релею через свой согласованный канал.

Регламент использования: Подписывается отдельный протокол с ГАСН (согласование 24.06.2026).

Г.8. И-8. SMS-шлюз

Назначение: Отправка SMS-OTP и критических уведомлений.

Требования к поставщику: - Соответствие законодательству РУз об операторских данных. - Поддержка кириллицы и латиницы. - Гарантированная доставка с подтверждением. - SLA доставки в РУз — не более 30 секунд.

Endpoints (зависят от выбранного шлюза):

Endpoint	Метод	Назначение	Частота
/send		Отправка SMS
/status/{id}		Статус доставки

Г.9. И-9. Электронная подпись

Назначение: Подписание актов приёмки (Далолатнома) квалифицированной ЭП.

Тип: API национального удостоверяющего центра.

Endpoints (зависят от провайдера):

Endpoint	Метод	Назначение	Частота
/sign/request		Создать запрос на подпись
/sign/verify		Проверить подпись
/sign/status/{id}		Статус

Альтернатива: Встроенная ЭП платформы с регистрацией в Едином реестре ЭП.

Г.10. И-10. Open ID (опционально, фаза масштабирования)

Назначение: Единый вход через национальную систему идентификации.

Детали: Уточняются на этапе разработки.

Г.11. Интеграция с Telegram Bot API (И-11)

Назначение. Авторизация полевых пользователей и работа Telegram MiniApp.

Тип: Telegram Bot API + Telegram Web App SDK.

Authentication: Telegram Bot Token (на стороне сервера платформы), Telegram WebApp initData (на стороне MiniApp).

Ключевые endpoints:

/bot{token}/sendMessage — отправка уведомлений пользователям по событию.
/bot{token}/answerCallbackQuery — обработка callback-кнопок по событию.
/bot{token}/setWebhook — регистрация webhook для входящих обновлений один раз при развёртывании.
Webhook (POST на сервер платформы) — получение сообщений и команд пользователя по событию.
Telegram WebApp SDK — авторизация пользователя в MiniApp, доступ к камере, GPS в сессии MiniApp.

Обработка ошибок: - Превышение лимитов Telegram API (30 сообщений в секунду): очередь с пропускной способностью. - Недоступность Telegram: переключение на SMS как резервный канал для критических уведомлений.

Требования к боту: - Верифицированный аккаунт (получение синей галочки от Telegram). - Команды бота: /start (регистрация), /help (справка), /miniapp (открыть MiniApp). - Inline-кнопки для типовых действий.

Г.11. Сценарии деградации при недоступности внешних систем

Платформа МБШ зависит от ряда внешних систем. Если эти системы временно недоступны, платформа должна продолжать работать в режиме деградации с сохранением максимума функциональности. Этот подраздел задаёт конкретные правила деградации для каждой интеграции.

Г.11.1. UN Quantum недоступен (интеграция И-1)

Длительность 0–1 час: Платформа продолжает работать. Не отправленные в Quantum уведомления (payment_due) сохраняются в очереди отложенных сообщений. Автоматический повтор каждые 5 минут.

Длительность 1–6 часов: Алерт системному администратору. Подрядчики могут продолжать загружать данные, технадзор может верифицировать этапы, акты могут подписываться — но новые payment_due не отправляются в Quantum (накапливаются в очереди).

Длительность 6–24 часа: Алерт UNDP_PROGRAM_MANAGER и UNDP_PROCUREMENT. Заказчик принимает решение: ждать восстановления или начать ручное оформление выплат через UN Quantum. В платформе появляется баннер «Интеграция с UN Quantum временно недоступна. Платежи задерживаются».

Длительность > 24 часов: Эскалация на Steering Committee. Активация плана непрерывности бизнеса.

Восстановление: При восстановлении соединения платформа автоматически передаёт всю накопленную очередь в UN Quantum в порядке возникновения событий. UNDP_PROCUREMENT получает отчёт о результатах синхронизации.

Что нельзя делать при недоступности UN Quantum: - Создавать вручную новые контракты (их источник всегда — UN Quantum). - Менять цены контрактов в обход стандартного процесса доп. соглашений.

Г.11.2. Замонавий мактаб недоступен (интеграция И-2)

На пилоте (ручная выгрузка Excel): Не применимо — нет автоматической интеграции.

На фазе масштабирования (API): При недоступности — платформа продолжает работать с теми данными по школам, которые есть в локальной БД. Ежесуточная синхронизация откладывается. Алерт администратору. При длительной недоступности (> 7 дней) — переход на ручную выгрузку Excel как запасной канал.

Г.11.3. Шлюз SMS недоступен (интеграция И-8)

Длительность 0–15 минут: Очередь SMS-уведомлений накапливается. Автоматический повтор.

Длительность > 15 минут: Алерт администратору. Уведомления, помеченные как критические (SLA-эскалация, истечение гарантии), переключаются на email-канал как резервный. Для обращений граждан через QR-канал — невозможна идентификация. Платформа показывает пользователю сообщение «SMS-сервис временно недоступен. Попробуйте через 5 минут или подайте обращение через веб-форму с email-идентификацией» (резервный механизм).

Длительность > 4 часов: Активация резервного SMS-провайдера (в архитектуре должно быть предусмотрено не менее двух).

Г.11.4. Инфраструктура электронной подписи недоступна (интеграция И-9)

Любая длительность: Подписание актов задерживается. Стороны акта получают уведомление «Подписание временно недоступно». Не подписанные акты остаются в статусе pending_signatures. По мере восстановления — продолжение подписания.

При недоступности > 24 часов: Альтернативный механизм — рукописная подпись с фотофиксацией страницы акта, что в дальнейшем дополняется цифровой подписью при восстановлении. Этот механизм активируется только по решению UNDP_PROGRAM_MANAGER.

Г.11.5. Видеомониторинг — поток камеры недоступен (интеграция И-3)

Длительность 0–30 минут: Системой не считается простоем. Возможны кратковременные сбои сети.

Длительность 30 минут – 4 часа: Уведомление подрядчику (M17). Подрядчик должен проверить оборудование.

Длительность > 4 часов в сутки: Считается простоем. Алерт координатору программы. Основание для штрафа (UC-A37).

Г.11.6. Геопортал АСР недоступен (интеграция И-6)

Любая длительность: Карты в платформе продолжают работать на резервной подложке (например, OpenStreetMap). Слой социальной инфраструктуры АСР отображается из локального кэша последней успешной синхронизации.

Г.11.7. Общие требования

Все нарушения доступности фиксируются в журнале аудита M18.
Ежемесячный отчёт о доступности всех интеграций доступен в M14 (Дашборды) и M20 (Отчётность).
Подрядчик-разработчик обязан реализовать механизм Circuit Breaker для каждой интеграции — при длительной недоступности система автоматически прекращает попытки соединения, чтобы не перегружать собственные ресурсы.

Г.12. Регламент сверки данных между МБШ и внешними системами

Расхождения в данных между платформой и внешними системами неизбежны — из-за временных лагов синхронизации, ошибок ручного ввода, сбоев интеграции. Без формального регламента сверки эти расхождения накапливаются и приводят к ситуациям «непонятно, какое значение правильное».

Г.12.1. Источники истины

Тип данных	Источник истины	Платформа МБШ
Паспорт школы (национальный ID, базовые атрибуты)	Замонавий мактаб	использует как зеркало
Тендер (создание, состав участников, оценка)	UN Quantum	использует как зеркало
Контракт (создание, цена, сроки)	UN Quantum	использует как зеркало
Платёж (факт оплаты)	UN Quantum	использует как зеркало
Этапы работ	МБШ	первичный источник
Доказательства (фото, видео)	МБШ	первичный источник
Акты приёмки	МБШ	первичный источник
Обращения граждан	МБШ	первичный источник

Г.12.2. Регулярная сверка

UN Quantum: ежедневная автоматическая сверка контрактов и платежей по списку активных контрактов. Отчёт о расхождениях — UNDP_PROCUREMENT.
Замонавий мактаб: еженедельная сверка паспортов школ. Отчёт — PLATFORM_ADMIN.
Прочие интеграции: еженедельная сверка по согласованному регламенту.

Г.12.3. Обнаружение расхождений

При обнаружении расхождения: 1. Расхождение фиксируется в журнале M18 с обоими значениями. 2. Создаётся задача в платформе для ответственного (PLATFORM_ADMIN или UNDP_PROCUREMENT). 3. Ответственный анализирует и принимает решение: применить значение источника истины (стандартный случай), сохранить значение МБШ с обоснованием (исключительный случай), эскалировать на руководство (сложный случай). 4. Решение фиксируется в журнале с обоснованием.

Г.12.4. Предотвращение расхождений

Все изменения в МБШ, которые могут затронуть данные источника истины (например, корректировка цены контракта в МБШ), требуют параллельного изменения в источнике истины. Платформа предупреждает пользователя об этом.
При плановом обновлении интеграции — тестовая среда для проверки совместимости.

Приложение Д — ЧЕК-ЛИСТЫ ЭТАПОВ РАБОТ ПО ТИПАМ ПАКЕТОВ

Д.1. Пакет «Общестроительные работы»

Этап 1. Подготовительные работы

Чек-лист: 1. Установлено временное ограждение площадки (фото с геометками со всех сторон). 2. Установлены информационные щиты с данными контракта. 3. Установлен видеомониторинг (камера + MikroTik + WireGuard), поток активен. 4. Доставлено первичное оборудование и материалы. 5. Подписан акт передачи объекта подрядчику. 6. Обеспечены условия охраны труда (СИЗ, аптечка, инструктаж). 7. Изолированы рабочие зоны от зон учебного процесса.

Этап 2. Демонтажные работы

Чек-лист: 1. Демонтаж старых окон (фото каждого этапа). 2. Демонтаж старых дверей. 3. Демонтаж старых радиаторов отопления (если меняются). 4. Демонтаж напольных покрытий (если меняются). 5. Утилизация строительного мусора (договор с лицензированным полигоном, фото вывоза). 6. Подписан акт демонтажа.

Этап 3. Утепление стен

Чек-лист: 1. Подготовка поверхности (очистка, ремонт трещин). 2. Установка утеплителя — материал соответствует ПСД (сертификат). 3. Армирующий слой. 4. Финишная отделка. 5. Фото каждой стены с геометками. 6. Замер термического сопротивления (если применимо).

Этап 4. Утепление крыши/потолка

Чек-лист: 1. Подготовка поверхности. 2. Гидроизоляция. 3. Утеплитель (марка, толщина по ПСД). 4. Защитный слой. 5. Фото с привязкой к зонам.

Этап 5. Замена окон

Чек-лист: 1. Демонтаж старых окон. 2. Подготовка проёмов. 3. Установка новых окон (марка, профиль, тип стеклопакета по ПСД). 4. Герметизация и отделка откосов. 5. Фото каждого окна, паспорта изделий.

Этап 6. Замена дверей

Чек-лист: 1. Демонтаж. 2. Подготовка проёмов. 3. Установка новых дверей по ПСД. 4. Герметизация, наличники. 5. Фото каждой двери.

Этап 7. Внутренняя отделка

Чек-лист: 1. Штукатурные работы. 2. Шпаклёвка. 3. Окраска / поклейка. 4. Замена напольного покрытия. 5. Фото по зонам.

Этап 8. Уборка и сдача

Чек-лист: 1. Уборка строительного мусора. 2. Восстановление прилегающей территории. 3. Сдача объекта представителям школы. 4. Подписание этапного акта.

Д.2. Пакет «Тепловые насосы»

Этап 1. Подготовительные работы

Чек-лист: 1. Площадка установки оборудования размечена. 2. Доставлено оборудование (с актом передачи и сертификатами). 3. Видеомониторинг активен.

Этап 2. Демонтаж старой котельной

Чек-лист: 1. Отключение и демонтаж старого котельного оборудования. 2. Утилизация (включая мазут, если был). 3. Очистка помещения котельной. 4. Фото каждого этапа.

Этап 3. Установка теплового насоса

Чек-лист: 1. Подключение к источнику тепла (грунтовый теплообменник / воздушный / водяной). 2. Установка теплового насоса. 3. Установка буферной ёмкости. 4. Электрическое подключение. 5. Фото с подписями.

Этап 4. Замена внутренних трубопроводов

Чек-лист: 1. Демонтаж старых трубопроводов. 2. Прокладка новых трубопроводов по ПСД. 3. Опрессовка и проверка герметичности. 4. Утепление.

Этап 5. Замена радиаторов

Чек-лист: 1. Демонтаж старых. 2. Установка новых по ПСД. 3. Подключение, регулировка. 4. Фото каждого радиатора.

Этап 6. Пусконаладка

Чек-лист: 1. Первый пуск системы. 2. Проверка работы во всех помещениях. 3. Замер температур по зонам. 4. Передача инструкций школьному персоналу. 5. Подписание акта пусконаладки.

Д.3. Пакет «Локальная очистная система канализации» (септик с полем фильтрации)

Этап 1. Подготовительные работы

Чек-лист: 1. Разметка участка установки. 2. Доставка оборудования. 3. Согласование с гидрогеологией (если применимо).

Этап 2. Земляные работы

Чек-лист: 1. Котлован под септик (фото с замерами). 2. Траншеи под трубопроводы и поле фильтрации.

Этап 3. Установка септика

Чек-лист: 1. Песчаная подушка. 2. Установка септика с проверкой уровня. 3. Подключение входящих и исходящих трубопроводов.

Этап 4. Поле фильтрации

Чек-лист: 1. Подушка из щебня. 2. Прокладка перфорированных труб. 3. Засыпка фильтрующим слоем. 4. Контрольные люки.

Этап 5. Подключение внутренней канализации

Чек-лист: 1. Прокладка внутренних трубопроводов от санузлов. 2. Установка ревизий. 3. Подключение к септику.

Этап 6. Тестирование и сдача

Чек-лист: 1. Заполнение системы водой. 2. Проверка герметичности. 3. Проверка работы (со временем — после поступления стоков). 4. Передача инструкций школьному персоналу.

Д.4. Пакет «Поставка гигиенических материалов»

Этап 1. Поставка

Чек-лист: 1. Доставка по спецификации (фото товара). 2. Передаточный акт. 3. Сертификаты соответствия.

Этап 2. Размещение и обучение

Чек-лист: 1. Размещение оборудования (мыльницы, диспенсеры, сушилки). 2. Обучение школьного персонала. 3. Подписание акта.

Д.5. Пакет «Проектно-сметная документация»

Этап 1. Обследование объекта

Чек-лист: 1. Выезд проектировщика на объект (фото). 2. Обмеры зданий. 3. Согласование с заказчиком технических заданий по школе.

Этап 2. Разработка эскизного проекта

Чек-лист: 1. Эскизные чертежи. 2. Концептуальные решения. 3. Согласование с заказчиком и инжкомпанией.

Этап 3. Разработка рабочей документации

Чек-лист: 1. Полные рабочие чертежи. 2. Спецификации материалов и оборудования. 3. Сметы.

Этап 4. Государственная экспертиза

Чек-лист: 1. Передача пакета на госэкспертизу. 2. Получение замечаний. 3. Внесение правок. 4. Положительное заключение.

Этап 5. Передача документации

Чек-лист: 1. Передача пакета ПСД заказчику в полном объёме. 2. Передача редактируемых исходников (DWG/REVIT/IFC). 3. Подписание акта передачи.

Приложение Е — ШАБЛОНЫ АКТОВ И ДАЛОЛАТНАМЫ

Е.1. Шаблон этапного акта приёмки

Заголовок: - УТВЕРЖДАЮ - Координатор программы UNDP — ФИО, должность, подпись, дата.

Реквизиты: - Школа: название, адрес, national_id, school_id. - Контракт: номер, дата, тип, стороны. - Этап: номер, наименование.

Описание работ: - Плановое и фактическое содержание этапа. - Период выполнения. - Объёмы (физические показатели).

Чек-лист: - Перечень всех пунктов чек-листа этапа с отметкой «выполнено / выполнено с замечаниями». - Ссылки на доказательства (внутренние ID в платформе, фото-номера).

Соответствие ПСД: - Подтверждение соответствия проектным решениям. - Перечень отклонений (если есть) с согласованиями.

Качество работ: - Заключение технадзора. - Замечания (если есть).

Финансовые показатели: - Стоимость этапа. - Сумма к выплате. - Удержание (retention). - Штрафы (если есть).

Подписи: - Подрядчик: ФИО, должность, подпись (ЭП), время, геолокация. - Технический надзор: ФИО, должность, подпись, время, геолокация. - Координатор программы UNDP: ФИО, должность, подпись, время. - Опционально — инспектор ГАСН.

Е.2. Шаблон финальной Далолатномы (по ШНК 3.01.04-19)

Структура (с адаптацией для МБШ):

Реквизиты школы и проекта.
Перечень выполненных работ по всем пакетам (общестрой, тепловые насосы, септик, материалы) — со ссылками на этапные акты.
Заключение о соответствии работ ПСД и нормативным требованиям.
Перечень замечаний и сроков их устранения (если есть).
Подписание членами многоведомственной комиссии:
- Председатель комиссии (UNDP).
- Заказчик (UNDP+МДшО).
- Каждый подрядчик (по своему пакету).
- Технический надзор.
- Инспектор ГАСН.
- Аудитор КРУ (либо отдельная процедура через 6 месяцев).
- Представитель района.
- Директор школы.
- Представитель махалли (опционально).
Дата и место подписания.
Каждая подпись — с временем и геолокацией.

Триггер для отсчёта 5-летней гарантии: дата подписания финальной Далолатномы всеми обязательными сторонами.

Е.3. Шаблон акта закрытия контракта

Реквизиты контракта.
Подтверждение всех этапных приёмок.
Подтверждение финальной приёмки (ссылка на Далолатнома).
Финансовая сводка: общая сумма, выплаты, удержания, штрафы, возврат retention.
Передача оборудования (видеокамера и т.п. демонтированы и забраны подрядчиком).
Подписи сторон.

Е.4. Шаблон отчёта по гарантийному случаю

Реквизиты случая.
Описание дефекта, дата возникновения, заявитель.
SLA: время реакции и устранения.
Описание устранения.
Фото «до» и «после».
Подтверждение школой.
Подписи.

Е.5. Шаблон отчёта о сезонном обслуживании

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

Приложение Ж — КАТАЛОГ УВЕДОМЛЕНИЙ

Структура: ID, событие-триггер, получатель (роль), канал по умолчанию, шаблон.

ID	Событие	Получатель	Канал	Шаблон (русский)
N01	Приглашение нового пользователя	Приглашённый	Email	«Здравствуйте, {name}. Вы приглашены в платформу МБШ как {role}. Перейдите по ссылке для активации: {link}.»
N02	Подтверждение регистрации	Новый пользователь	Email	«Регистрация завершена. Войдите: {link}.»
N03	Двухфакторный код входа	Пользователь	SMS	«Код: {code}. Действителен 5 минут.»
N04	Неуспешные попытки входа	Пользователь	Email	«По вашему аккаунту зафиксировано {n} неуспешных попыток входа. Если это не вы — смените пароль.»
N05	Обращение зарегистрировано	Заявитель	SMS	«Спасибо, ваше обращение принято. Номер: {id}. Ответ в течение {sla}.»
N06	Новое обращение	Ответственный	In-app, Email	«Новое обращение по школе {school}. Категория: {category}. Приоритет: {priority}. Открыть: {link}.»
N07	Истекает SLA через 4 часа	Ответственный	Telegram/web-push/in-app	«Срочно: обращение {id} требует ответа через 4 часа.»
N08	SLA истёк	Ответственный + вышестоящий	Email, Telegram/web-push/in-app	«Истёк срок ответа по обращению {id}. Эскалация на уровень {level}.»
N09	Ответ на обращение	Заявитель	SMS	«По вашему обращению {id} опубликован ответ: {link}.»
N10	Этап подан на верификацию	Технадзор	In-app, Email	«На верификацию подан этап {n} контракта {contract} школы {school}.»
N11	Этап одобрен	Подрядчик	In-app, Email	«Ваш этап {n} одобрен. Формируется акт для подписания.»
N12	Этап отклонён	Подрядчик	In-app, Email	«Этап {n} отклонён. Причины: {reasons}. Доработайте и подайте повторно.»
N13	Акт подписан всеми сторонами	Все стороны акта	Email	«Акт {act_id} подписан всеми сторонами. Запускается оплата.»
N14	Платёж проведён	Подрядчик	Email	«Произведена оплата по контракту {contract}, этап {n}, сумма {amount}.»
N15	Просрочка фотоотчёта 2 дня	Подрядчик	Telegram/web-push/in-app, SMS	«Внимание: пропущен ежедневный фотоотчёт по контракту {contract}.»
N16	Просрочка фотоотчёта повторная	Координатор программы	Email	«Подрядчик {contractor} систематически пропускает фотоотчёты по контракту {contract}.»
N17	Простой видеопотока > 30 минут	Подрядчик	Telegram/web-push/in-app	«Видеопоток камеры {camera} недоступен > 30 минут. Проверьте оборудование.»
N18	Простой видеопотока > 4 часов	Координатор программы	Email	«Длительный простой камеры {camera} контракта {contract}. Подрядчик уведомлён.»
N19	Гарантийный случай критический	Подрядчик-гарант	SMS, Email	«Срочно: гарантийный случай по школе {school}. SLA — выезд в 48 часов.»
N20	Просрочка гарантийного SLA	Подрядчик + координатор	Email	«Просрочка SLA по гарантийному случаю {id}. Начислен штраф.»
N21	Гарантия истекает через 6 месяцев	UNDP_PM, школа	Email	«Гарантия по школе {school} истекает {date}. Запланируйте финальный осмотр.»
N22	Истекает банковская гарантия	UNDP_PROC	Email	«Через 30 дней истекает банковская гарантия по контракту {contract}.»
N23	Запрос на верификацию по чек-листу	Технадзор	In-app	«Чек-лист этапа {n} требует проверки. Открыть: {link}.»
N24	Инцидент на стройплощадке	Координатор программы	Email, Telegram/web-push/in-app	«Зарегистрирован инцидент по контракту {contract}: {description}.»
N25	Назначена инспекция ГАСН	Подрядчик	Email	«На {date} запланирована инспекция ГАСН по контракту {contract}.»
N26	Заключение госэкспертизы получено	Проектная компания, заказчик	Email	«По проекту школы {school} получено заключение госэкспертизы: {decision}.»
N27	Изменение программы года	Утверждающие лица	Email	«Программа года {year} изменена. Просмотр: {link}.»
N28	Запрос постаудита КРУ	КРУ	Email	«По школе {school} истекли 6 месяцев. Подготовлен пакет для аудита.»
N29	Внесение в чёрный список	Подрядчик	Email	«Ваша организация внесена в чёрный список UNDP. Срок: {end_date}. Основание: {reason}.»
N30	Возврат retention	UNDP_FIN, подрядчик	Email	«По школе {school} прошло 60 дней с финальной приёмки. Запланирован возврат retention.»

Каталог расширяется по мере детализации модулей. Все шаблоны — на трёх языках.

Ж.1. Канал доставки и язык

Каналы доставки: in-app уведомление в личном кабинете (всегда), email (по согласию пользователя), Telegram MiniApp push (если пользователь привязал Telegram), SMS (только для критичных событий и публичного канала граждан M11).

Язык уведомлений: автоматически по языку учётной записи пользователя (русский / узбекский кириллица / узбекский латиница / английский для UNDP и UNICEF).

Ж.2. События и получатели — модули закупок и контрактов

N-01. Новый тендер опубликован в UN Quantum — получатели: PUBLIC (через M19), CONTRACTOR_REPRESENTATIVE подписки по типам работ, UNDP_PROCUREMENT. Канал: in-app, email.

N-02. Контракт подписан — получатели: CONTRACTOR_REPRESENTATIVE, SCHOOL_DIRECTOR школы-получателя, REGIONAL_EDU_HEAD, UNDP_FINANCE. Канал: in-app, email.

N-03. Существенное доп. соглашение (≥5% стоимости или ≥10 дней срока) — получатели: CSAC_OBSERVER, NGO_MONITOR, UNDP_INTEGRITY, публикация на M19. Канал: in-app, email, M19.

N-04. Срок контракта истекает через 60 дней — получатели: UNDP_PROCUREMENT, CONTRACTOR_REPRESENTATIVE, UNDP_PROGRAM_MANAGER. Канал: in-app, email.

N-05. Подрядчик внесён в чёрный список — получатели: UNDP_PROCUREMENT, ACA_OFFICER, CONTRACTOR_REPRESENTATIVE, публикация M19. Канал: in-app, email, M19.

Ж.3. События и получатели — модули исполнения и доказательной базы

N-06. Этап подан на верификацию — получатели: REGIONAL_ENGINEERING, GASN_INSPECTOR, FIELD_INSPECTOR (по типу этапа). Канал: in-app.

N-07. Этап подписан (UC-A19), payment_due сформирован — получатели: CONTRACTOR_FINANCE, UNDP_FINANCE. Канал: in-app, email.

N-08. Инцидент на стройплощадке (UC-A20) — получатели: GASN_INSPECTOR, UNDP_PROGRAM_MANAGER, SCHOOL_DIRECTOR; при категории «травма» — ещё и UNDP_INTEGRITY. Канал: in-app, email, SMS для критических.

N-09. Работы приостановлены (UC-A21) — получатели: CONTRACTOR_REPRESENTATIVE, UNDP_PROGRAM_MANAGER, SCHOOL_DIRECTOR, REGIONAL_EDU_HEAD. Канал: in-app, email.

N-10. Подрядчик подал заявку на возобновление (UC-A22) — получатели: GASN_INSPECTOR, UNDP_PROGRAM_MANAGER. Канал: in-app.

N-11. Фото не синхронизировано более 48 часов — получатели: CONTRACTOR_FIELD_WORKER (предупреждение), CONTRACTOR_REPRESENTATIVE. Канал: in-app, Telegram push.

N-12. Камера M6 недоступна более 30 минут — получатели: CONTRACTOR_REPRESENTATIVE. Канал: in-app, Telegram push.

N-13. Камера M6 недоступна более 4 часов в сутки — получатели: UNDP_PROGRAM_MANAGER, GASN_INSPECTOR. Канал: in-app, email.

Ж.4. События и получатели — общественная обратная связь

N-14. Новое обращение через M11 — получатели: SCHOOL_DIRECTOR (L1), копия в M19 (обезличенная). Канал: in-app, SMS для категорий «нет воды» / «травма».

N-15. SLA обращения истекает менее чем за 6 часов — получатель: ответственный L1 и его руководитель. Канал: in-app, email.

N-16. Эскалация L1 → L2 (просрочка SLA) — получатели: DISTRICT_EDU_HEAD, REGIONAL_EDU_HEAD. Канал: in-app, email.

N-17. Эскалация L2 → L3 — получатели: UNDP_PROGRAM_MANAGER, CSAC_OBSERVER. Канал: in-app, email.

N-18. Категория «WASH operational» от граждан — получатели: SCHOOL_DIRECTOR, UNICEF_OFFICER, подрядчик гигиенического пакета Прил. Д.4. Канал: in-app.

Ж.5. События и получатели — приёмка и гарантия

N-19. Готовность к финальной приёмке UC-A23 — получатели: UNDP_PROGRAM_MANAGER, UNICEF_OFFICER (WASH-раздел), REGIONAL_ENGINEERING, GASN_INSPECTOR, SCHOOL_DIRECTOR. Канал: in-app, email.

N-20. UC-A23 подписан — школа сдана — получатели: все участники программы школы, публикация M19. Канал: in-app, email, M19.

N-21. Гарантийный случай открыт (M13) — получатели: CONTRACTOR_REPRESENTATIVE, SCHOOL_DIRECTOR, UNDP_PROGRAM_MANAGER. Канал: in-app, email.

N-22. Гарантия истекает через 90 дней — получатели: SCHOOL_DIRECTOR, UNDP_PROGRAM_MANAGER, REGIONAL_EDU_HEAD. Канал: in-app, email.

N-23. Continuous WASH monitoring — опрос 30/60/90/180 дней — получатели: родители и учителя через QR (анонимно). Канал: QR на видном месте, SMS-приглашение для подписанных.

N-24. WASH KPI ниже 80% по опросам — получатели: UNICEF_OFFICER, SCHOOL_DIRECTOR, подрядчик гигиенического пакета. Канал: in-app, email.

Ж.6. События и получатели — финансы, compliance, аудит

N-25. Выплата UC-A24 заблокирована (нет evidence / нет публикации доп. соглашения / red compliance) — получатели: CONTRACTOR_REPRESENTATIVE, CONTRACTOR_FINANCE, UNDP_FINANCE, UNDP_PROCUREMENT. Канал: in-app, email.

N-26. Возврат retention UC-A25 — получатели: CONTRACTOR_FINANCE, UNDP_FINANCE. Канал: in-app, email.

N-27. Compliance подрядчика по Прил. И — статус red — получатели: UNDP_INTEGRITY, UNDP_PROCUREMENT, CONTRACTOR_REPRESENTATIVE. Канал: in-app, email.

N-28. Новый Integrity Pact подписан — получатели: UNDP_INTEGRITY, CSAC_OBSERVER, публикация M19. Канал: in-app, M19.

N-29. Конфликт интересов выявлен (совпадение UBO подрядчика и UNDP staff) — получатели: UNDP_INTEGRITY, UNDP_PROCUREMENT (блокировка UC-A11). Канал: in-app, email.

Ж.7. События и получатели — программа, отчётность, система

N-30. Когорта года утверждена (UC-A07) — получатели: все региональные координаторы, UNDP_PM, MOPSE_PROGRAM, публикация M19. Канал: in-app, email, M19.

N-31. Веса критериев скоринга M3 изменены — получатели: MOPSE_STRATEGY, MOPSE_PROGRAM, UNDP_INTEGRITY, публикация M19. Канал: in-app, email.

N-32. Donor-report сгенерирован — получатели: UNDP_PROGRAM_MANAGER. Канал: in-app.

N-33. Kobo-оценка школы старше 24 месяцев — получатели: инженерная команда, MOPSE_PROGRAM. Канал: in-app, email.

N-34. Журнал аудита M18 — critical event (попытка несанкционированного доступа, удаление журнала и т.п.) — получатели: PLATFORM_SECURITY, PLATFORM_AUDITOR. Канал: in-app, email, SMS.

N-35. OCDS-выгрузка M15 не выполнена в срок — получатели: PLATFORM_ADMIN, UNDP_PROCUREMENT. Канал: in-app, email.

Ж.8. Правила настройки уведомлений

Каждый пользователь может в личном кабинете включить/отключить категории уведомлений (кроме обязательных — критические инциденты, эскалации SLA, блокировки выплат, audit critical).

PLATFORM_ADMIN может через конструктор Прил. Я.4 добавить новые типы уведомлений, изменить шаблоны, переназначить получателей по ролям без релиза кода.

Все отправленные уведомления и попытки доставки фиксируются в M18.

Приложение З — ТЕХНИЧЕСКАЯ СПЕЦИФИКАЦИЯ ВИДЕОМОНИТОРИНГА

З.1. Архитектура

[IP-камера] --- ether3 ---> [MikroTik роутер] --- WireGuard VPN ---> [VPN-сервер МБШ]
                                                                            |
                                                              +-------------+--------------+
                                                              |             |              |
                                                       [Медиасервер]  [ГАСН-релей]   [Архив]
                                                              |
                                                  +-----------+-----------+
                                                  |                       |
                                              [МБШ-веб]            [МБШ-веб/MiniApp]

З.2. Требования к камере (минимум)

Тип: IP-камера с поддержкой HTTP (порт 80) и RTSP (порт 554).
Разрешение: не ниже 1920×1080 (Full HD).
Частота: не ниже 15 fps в режиме непрерывной записи.
Ночная съёмка: ИК-подсветка, дальность не менее 20 м.
Степень защиты: IP66 или выше.
Кронштейн: антивандальный, для уличного монтажа.
Угол обзора: 90–110° (широкий охват площадки).
PoE: желательно для упрощения монтажа.

Допустимые модели (примеры, не исчерпывающий список): - Hikvision DS-2CD2T47G2-L - Dahua IPC-HFW2431S-S - TP-Link VIGI C340.

З.3. Требования к маршрутизатору

Производитель: MikroTik (унифицировано с практикой Сурхандарьинской инжкомпании).
Модель: hAP ac², hEX, RB960PGS или эквивалент.
Поддержка WireGuard (RouterOS 7.0+).
Минимум 5 портов Ethernet.
Поддержка PoE (для питания камеры).

З.4. Конфигурация WireGuard на стороне MikroTik

/interface wireguard
add listen-port=51820 mtu=1420 name=wg-mbs private-key="<генерируется МБШ>"

/interface wireguard peers
add allowed-address=12.1.0.0/16 endpoint-address=<vpn.mbs.uz> endpoint-port=51820 \
    interface=wg-mbs public-key="<публичный ключ сервера МБШ>"

/ip address
add address=12.1.X.Y/16 interface=wg-mbs

З.5. Конфигурация NAT для проброса камеры

/ip firewall nat
add chain=dstnat in-interface=wg-mbs protocol=tcp dst-port=8000 \
    action=dst-nat to-addresses=192.168.99.99 to-ports=80

add chain=dstnat in-interface=wg-mbs protocol=tcp dst-port=8554 \
    action=dst-nat to-addresses=192.168.99.99 to-ports=554

З.6. Регистрация камеры в МБШ

Подрядчик через личный кабинет инициирует регистрацию.
МБШ генерирует приватный ключ WireGuard и выделяет внутренний IP в подсети 12.1.0.0/16.
Подрядчик получает пакет: ключ, IP, инструкцию.
После настройки — тестовый снимок и тестовый поток.
Инженер МБШ подтверждает активацию.

З.7. Хранение видеоархива

Сервер МБШ ведёт непрерывную запись.
Срок хранения: 30 дней (конфигурируется в справочнике).
Битрейт записи: 1.5–3 Мбит/с (баланс качества и объёма).
Объём хранилища: расчётно 1.5 ТБ на камеру на 30 дней.
Резервное копирование: ежедневный snapshot ключевых фрагментов.

З.8. Доступ к потоку и архиву

Прямой просмотр: RBAC — REGIONAL_ENGINEERING, EXTERNAL_CONSTRUCTION_CONTROLLER (если назначен), GASN_INSPECTOR, UNDP_PM, CSAC_OBSERVER, NGO_MONITOR, UNDP_INTEGRITY.
Архив: те же роли + KRU_AUDITOR, ACA_OFFICER; доступ внешнего контролёра ограничивается назначенными программами/регионами/контрактами и фиксируется в M18.
Каждый просмотр — запись в журнал аудита.

З.9. Мониторинг доступности

Сервер МБШ каждую минуту опрашивает каждую камеру (ping + RTSP probe).
Агрегация по часам.
Дашборд «состояние камер» для оператора.
Алерты: 30 минут — подрядчику; 4 часа в сутки суммарно — координатору программы + штраф.

З.10. Передача потока в ГАСН

ГАСН подключается к медиасерверу МБШ через выделенный API/RTSP-релей.
Отдельный аккаунт для ГАСН с минимальными правами.
Лимит одновременных подключений согласован.

З.11. ИИ-распознавание событий (опционально, Фаза 2)

Детекторы: отсутствие СИЗ (каска, жилет), посторонние лица, рабочая активность ночью без разрешения.
Базовая модель: открытые модели Computer Vision (YOLOv8 + классификатор).
Срабатывание — событие inspection_finding с таймкодом и фрагментом видео.

З.12. Демонтаж по окончании работ

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

Приложение И — ДОГОВОРНЫЕ ТРЕБОВАНИЯ К ПОДРЯДЧИКАМ СТРОИТЕЛЬНЫХ РАБОТ

Это приложение представляет собой ссылку на сопутствующий документ, разработанный параллельно с настоящим ТЗ: «Договорные требования к подрядчикам строительных работ» от 18.06.2026 (хранится в репозитории проекта как файл Договорные_требования_к_подрядчикам_2026-06-18.txt).

Документ содержит 16 договорных блоков и 12 открытых юридических вопросов, регулирующих обязательства строительных подрядчиков (общестрой, тепловые насосы, септики, поставщики материалов, проектные организации) перед заказчиком (UNDP) в части видеомониторинга, фотоотчётности, гарантийных обязательств 5 лет по ШНК 3.01.04-19, антикоррупционных деклараций (UBO, конфликт интересов, Integrity Pact), охраны труда, экологии, защиты персональных данных, страхования, разрешения споров.

Связь с настоящим ТЗ: модули M5 (Контракты), M6 (Видеомониторинг), M9 (Доказательства), M11 (Обращения), M13 (Гарантия), M16 (Integrity Pacts) реализуют техническую сторону этих договорных требований. Договорные требования юридически обязывают подрядчиков пользоваться платформой по правилам, заложенным в технические модули. Платформа без договорных обязательств — бесполезный инструмент; договорные обязательства без платформы — недостаточный механизм контроля.

При сдаче платформы подрядчик-разработчик не несёт ответственности за содержание договорных требований (это работа юридического отдела UNDP), но обязан обеспечить, чтобы платформа технически поддерживала исполнение каждого блока договорных требований.

Приложение К — КРИТЕРИИ ОЦЕНКИ ТЕНДЕРНЫХ ПРЕДЛОЖЕНИЙ НА РАЗРАБОТКУ ПЛАТФОРМЫ

К.1. Общие принципы

Двухконвертная процедура: техническая часть + финансовая часть.
Сначала вскрывается техническая, оценивается. Финансовая вскрывается только у участников, прошедших технический минимум.
Итоговая оценка: 70% технические критерии + 30% финансовые.

К.2. Технические критерии (700 баллов)

К.2.1. Опыт компании и команды (200 баллов)

Критерий	Макс. баллы
Опыт реализации аналогичных платформ (более 3 проектов в государственном секторе или для международных доноров)	60
Наличие команды с подтверждённой квалификацией (CV всех ключевых ролей: PM, архитектор, lead frontend, lead backend, DevOps, QA, security)	60
Опыт интеграции с национальными системами Узбекистана	40
Опыт работы с UNDP/UN агентствами	20
Наличие сертификаций (ISO 27001, ISO 9001)	20

К.2.2. Понимание задачи и архитектурное предложение (200 баллов)

Критерий	Макс. баллы
Соответствие предложения требованиям ТЗ	60
Качество проработки бизнес-процессов в предложении	40
Архитектурный подход (микросервисы / монолит — обоснование)	30
Технологический стек и его обоснование	30
Подход к интеграциям (UN Quantum, Замонавий мактаб, видеомониторинг)	40

К.2.3. Методология реализации (150 баллов)

Критерий	Макс. баллы
Чёткость и реалистичность плана работ	40
Применение SCRUM/Agile или иной зрелой методологии с обоснованием	30
Управление рисками	30
Подход к тестированию (unit / integration / E2E)	30
План передачи МДшО (handover)	20

К.2.4. Безопасность и комплаенс (100 баллов)

Критерий	Макс. баллы
Подход к информационной безопасности (соответствие ISO 27001, OWASP, защита ПДн)	40
План пентестов и независимого аудита безопасности	20
Подход к управлению доступом и аудиту	20
План регистрации ИС в Едином реестре	10
Соответствие ЗРУ-1125 о ПДн	10

К.2.5. Документация и сопровождение (50 баллов)

Критерий	Макс. баллы
Состав документации и стандарты оформления (соответствие O’z DSt 1985:2018)	20
Качество демо-материалов в предложении	15
Подход к сопровождению после ввода в эксплуатацию	15

К.3. Финансовые критерии (300 баллов)

Критерий	Расчёт
Цена предложения	Максимальный балл — самой низкой цене, прочие — пропорционально
Соотношение цена/объём работ	Оценка обоснованности расчёта по статьям
Структура платежей и привязка к deliverables	Качество предложенной схемы

К.4. Технический минимум для прохождения

Не менее 500 из 700 баллов по технической части.
Подтверждённый опыт реализации не менее 1 проекта на стек, аналогичный предложенному.
Команда с минимально требуемыми ролями.
Соответствие требованиям UNDP по procurement (отсутствие в санкционных списках, UBO, Integrity Pact).

К.5. Процедура

Открытие конкурса в UN Quantum.
Период сбора предложений — не менее 30 рабочих дней.
Вскрытие технических конвертов в присутствии комиссии.
Оценка техники — не менее 2 недель.
Информирование участников о результатах техники.
Вскрытие финансовых конвертов участников, прошедших минимум.
Итоговое ранжирование, объявление победителя.
Период обжалования — 7 рабочих дней.
Подписание контракта.

Приложение Л — ГЛОССАРИЙ ТЕРМИНОВ

Л.1. Государственные институты и регуляторы

Термин	Узбекский эквивалент	Описание
МДшО	МДТТ (Мактабгача ва мактаб таълими вазирлиги)	Министерство дошкольного и школьного образования Республики Узбекистан
Минцифры	Рақамли технологиялар вазирлиги	Министерство цифровых технологий Республики Узбекистан
ГАСН	ДАҚН (Давлат архитектура-қурилиш назорати)	Государственный архитектурно-строительный надзор
КРУ	НТБ (Назорат-тафтиш бошқармаси)	Контрольно-ревизионное управление
ACA	КЎККА	Anti-Corruption Agency (Коррупцияга қарши курашиш агентлиги) при Президенте РУз
CSAC	ЖМКҚ	Civil Society Advisory Committee — общественный консультативный комитет при ACA
Минфин	Иқтисодиёт ва молия вазирлиги	Министерство экономики и финансов
Минстрой	Қурилиш ва уй-жой-коммунал хўжалиги вазирлиги	Министерство строительства и ЖКХ
УНО	ХТҲО (Халқ таълими ҳудудий бошқармаси)	Управление народного образования (районный уровень)
АСР	СИА (Стратегик ислоҳотлар агентлиги)	Агентство стратегических реформ при Президенте РУз
Узинфоком	Uzinfocom	ГУП «Uzinfocom» — государственный оператор корпоративных ИС
Деливеру Юнит	Delivery Unit	Подразделение в составе АСР, владелец Геопортала

Л.2. Строительные и проектные термины (узбекский → русский)

Термин	Узбекский эквивалент	Описание
Далолатнома / Акт приёмки	Далолатнома	Акт сдачи-приёмки выполненных работ по ШНК 3.01.04-19
СНиП РУз	ШНК	Шаҳарсозлик норма ва қоидалари — национальные строительные нормы
ЛСҲ (Лойиҳа-смета ҳужжатлари)	ПСД	Проектно-сметная документация
Проектная организация	Лойиҳа ташкилоти	Юридическое лицо, разрабатывающее ПСД
Локальная очистная система канализации	Септик тизими	Септик с полем фильтрации (septic tank with infiltration field)
Тепловой насос	Иссиқлик насоси	Heat pump
Муҳандислик-консалтинг ширкати	Инжиниринговая компания	Инжкомпания при облхокимияте, осуществляет технический надзор
Вилоят ҳокимияти	Облхокимият	Областная администрация
Ҳокимият	Хокимият	Местный орган власти
Маҳалла	Махалля	Орган самоуправления граждан, единица анализа
Кенгаш	Кенгаш	Совет (Кабинет Министров, локальные кенгаши)
Тендер	Тендер	Конкурс
Шафоф (тендер.мк.уз)	Шафофф	Государственная платформа тендеров Минстроя
Капитал қурилиш	Капитал қурилиш	Капитальное строительство (название АИС Минфина)
Замонавий мактаб	Замонавий мактаб	Современная школа — система Узинфоком по School Passport
Kobo (KoboToolbox)	Кобо	Инструмент сбора данных, используемый UNDP для оценки школ

Л.3. Сущности платформы

Термин	Описание
School Passport	Цифровой паспорт школы — единый источник данных о каждой школе
Контракт (Contract)	Юридическое соглашение между UNDP и подрядчиком по одному пакету работ
Этап (Milestone)	Подкласс работ внутри контракта, оплачивается отдельно
Чек-лист (Checklist)	Перечень обязательных пунктов для подтверждения выполнения этапа
Доказательство (Evidence)	Фото, видео, документ, подтверждающий выполнение пункта чек-листа
Акт (Act)	Электронный документ приёмки — этапный или финальный (Далолатнома)
Подпись (Signature)	Электронная подпись с привязкой ко времени и геолокации
Выплата (Payment)	Денежная транзакция от UNDP подрядчику, привязанная к подписанному акту
Гарантийный случай (Warranty Case)	Дефект, подпадающий под 5-летнюю гарантию подрядчика
Обращение (Citizen Feedback)	Заявка гражданина через QR/web с категоризацией и SLA
Integrity Pact	Соглашение между UNDP, подрядчиком и независимым общественным наблюдателем

Л.4. Технические термины

Термин	Описание
RBAC	Role-Based Access Control — модель управления доступом по ролям
MFA	Multi-Factor Authentication — многофакторная аутентификация
SLA	Service Level Agreement — соглашение об уровне обслуживания
RTO	Recovery Time Objective — целевое время восстановления
RPO	Recovery Point Objective — целевая точка восстановления
UBO	Ultimate Beneficial Owner — конечный бенефициарный владелец
OCDS	Open Contracting Data Standard — стандарт открытых данных о закупках
SMS-OTP	Одноразовый код по SMS для верификации
Append-only log	Журнал только для дозаписи, изменения и удаления невозможны
Pentest	Penetration testing — тестирование на проникновение
SAST/DAST	Static/Dynamic Application Security Testing
WCAG	Web Content Accessibility Guidelines — рекомендации по доступности веб-контента
EXIF	Метаданные изображения (включая координаты и время съёмки)
RTSP	Real-Time Streaming Protocol — для видеопотоков камер
WireGuard	Современный VPN-протокол

Л.5. Принятые сокращения

KoboToolbox (Kobo) — открытая платформа сбора структурированных данных. Разработана Harvard Humanitarian Initiative совместно с UN OCHA. В Joint Programme используется инженерной командой UNDP и UNICEF для оценки школьной инфраструктуры по 122-полевой форме «Ishonch WASH Engineering Survey 100 Schools» и для профилирования махаллей по 79-полевой форме «Mahalla Profiles». Формы и собранные по 100+ школам данные передаются в платформу МБШ как наследие методологии при старте проекта.

ПСД — Проектно-сметная документация — комплект документов проектной организации с расчётом стоимости работ.

СМР — Строительно-монтажные работы — основной этап реализации строительного контракта.

ГАСН — Государственный архитектурно-строительный надзор Республики Узбекистан.

КРУ — Контрольно-ревизионное управление при Министерстве финансов.

АИС — Автоматизированная информационная система.

ШНК — Шаҳарсозлик нормалари ва қоидалари — градостроительные нормы и правила Республики Узбекистан.

ОТ — Охрана труда.

ПДн — Персональные данные (в соответствии с законом ЗРУ-547).

СИЗ — Средства индивидуальной защиты работников строительства.

API — Application Programming Interface — программный интерфейс взаимодействия систем.

RBAC — Role-Based Access Control — управление доступом на основе ролей.

SLA — Service Level Agreement — соглашение об уровне сервиса.

OCDS — Open Contracting Data Standard — международный стандарт открытых данных о закупках.

PWA — Progressive Web Application — прогрессивное веб-приложение с поддержкой офлайн-режима.

OAuth — OAuth 2.0 — открытый протокол авторизации API.

JWT — JSON Web Token — стандарт токенов для аутентификации.

TLS — Transport Layer Security — протокол защиты транспортного уровня (HTTPS).

SAML — Security Assertion Markup Language — стандарт обмена данными аутентификации.

SAST — Static Application Security Testing — статический анализ безопасности кода.

DAST — Dynamic Application Security Testing — динамический анализ безопасности приложения.

EXIF — Exchangeable Image File Format — метаданные фотографии (дата, GPS, камера).

GPS — Global Positioning System — глобальная система спутникового позиционирования.

OTP — One-Time Password — одноразовый пароль (обычно SMS).

SSO — Single Sign-On — единая точка входа в несколько систем.

MFA — Multi-Factor Authentication — многофакторная аутентификация.

KPI — Key Performance Indicator — ключевой показатель эффективности.

PII — Personally Identifiable Information — персонально идентифицируемая информация (синоним ПДн).

JMP — WHO–UNICEF Joint Monitoring Programme for Water Supply, Sanitation and Hygiene — международная система мониторинга WASH.

WASH — Water, Sanitation and Hygiene — водоснабжение, санитария и гигиена.

MHM — Menstrual Hygiene Management — управление менструальной гигиеной в школах.

BCC — Behaviour Change Communication — программа изменения поведения через коммуникацию (уроки гигиены для детей).

UBO — Ultimate Beneficial Owner — конечный бенефициарный владелец юридического лица.

MoU — Memorandum of Understanding — меморандум о взаимопонимании между сторонами.

NDA — Non-Disclosure Agreement — соглашение о неразглашении.

CSAC — Civil Society Advisory Committee — общественный консультативный совет по программе.

NGO — Non-Governmental Organisation — неправительственная организация.

ACA — Anti-Corruption Agency of the Republic of Uzbekistan — Агентство по противодействию коррупции.

STIR — Soliq toʻlovchining identifikatsiya raqami — ИНН (Идентификационный номер налогоплательщика) Республики Узбекистан.

INN — Идентификационный номер налогоплательщика (см. STIR).

Приложение М — РАСШИРЕННЫЙ ПЕРЕЧЕНЬ РОЛЕЙ И ИХ ОТВЕТСТВЕННОСТЕЙ

М.1. Принципы

Все 29 ролей × 20 модулей × 7 базовых действий (read / create / update / delete / sign / approve / export).
Scope: own / school / district / region / republic / all_public / none.
По умолчанию — «none».
Дополнительные разрешения для модулей со специфическими действиями (например, для M11 — feedback:respond).

М.2. Сводная таблица модульного доступа

Категория: Граждане

PUBLIC (анонимный посетитель): - M2 read all_public (паспорт школы без ПДн) - M5 read all_public (контракты) - M9 read all_public (обезличенные фото) - M11 read all_public (публичная лента обращений) - M15 read all_public (открытые данные) - M19 read all_public (публичный портал)

PUBLIC: - M11 create public_signal (открытый сигнал без обязательной аутентификации) - M11 read all_public. CITIZEN_AUTHENTICATED (после SMS-OTP): - M11 create formal_appeal own - M11 read own - отслеживание статуса и получение официального ответа. Остальное как PUBLIC

Категория: Подрядчики

CONTRACTOR_REPRESENTATIVE: - M1 read own org, update own org basic, ubo update - M5 read own contracts - M7 read own contracts - M8 read own contracts, update progress - M9 upload own, read own - M10 read own - M11 read own contract feedback, respond own contract - M12 submit_stage own - M13 read own warranty, respond own - M16 sign own pact - M17 read own - M18 read own actions

CONTRACTOR_FIELD_WORKER: - M9 upload own (через Telegram MiniApp или адаптивный веб-интерфейс) - M10 read own - M17 read own

CONTRACTOR_FINANCE: - M7 read own (выплаты, штрафы)

Категория: Проектные организации

DESIGN_REPRESENTATIVE: - M1 read own, update own - M5 read own contracts - M9 upload own (ПСД-документы) - M10 read own - M12 submit_stage own - M17 read own

Категория: Школа

SCHOOL_DIRECTOR: - M1 read self - M2 read own school, update own school basic, photos - M5 read own school contracts - M6 view own school stream - M8 read own school - M9 read own school - M11 generate qr own, respond own school - M12 sign acceptance - M13 confirm own school cases - M14 view own school dashboard - M17 receive own school

SCHOOL_STAFF: - M2 read own school (без редактирования) - M11 view own school - M14 view own school summary

Категория: Районный уровень

DISTRICT_EDU_HEAD: - M1 invite district users - M2 read district - M3 read district - M4 read district - M5 read district - M8 read district - M11 respond district - M13 monitor district warranty - M14 view district dashboard

DISTRICT_EDU_STAFF: - Подмножество DISTRICT_EDU_HEAD без управления пользователями.

Категория: Областной уровень

REGIONAL_EDU_HEAD: - Все аналогичные региону scope. - Дополнительно: M4 contribute region план года.

REGIONAL_EDU_STAFF: подмножество REGIONAL_EDU_HEAD.

REGIONAL_HOKIM_DEPUTY: - M2/M5/M8/M11/M13/M14 read region. - M14 view executive dashboard. - M17 escalation receiver.

REGIONAL_FINANCE: - M5/M7 read region (финансовые показатели). - M14 view financial dashboard.

REGIONAL_ENGINEERING (технадзор инжкомпании): - M6 view region streams (видеомониторинг). - M9 read region, annotate, flag. - M12 verify region (верификация этапов). - M17 receive notifications.

EXTERNAL_CONSTRUCTION_CONTROLLER (внешний контролёр / сторонняя организация строительного контроля): - M2/M5/M8/M9/M12/M14 read assigned scope. - M6 view assigned streams/archive. - M8 see schedules, delays and critical path. - M9 annotate/flag evidence. - M12 comment verification and raise risk flags, без самостоятельного перевода этапа в verified по умолчанию. - M17 receive SLA/escalation notifications. - M18 read related audit log.

Категория: Государственные надзорные органы

GASN_INSPECTOR: - M6 view all streams (полный доступ к видео). - M9 read all, flag. - M12 register/finalize inspections. - M17 receive ГАСН-уведомления. - M18 read related audit.

KRU_AUDITOR: - M5/M7 read all. - M9 read all. - M12 perform audit. - M14 view audit dashboard. - M18 read full audit log.

ACA_OFFICER: - Полный read на всё. - M11 moderate spam (опционально). - M14 view anti-corruption dashboard. - M18 read full audit log.

FIELD_INSPECTOR (универсальный шаблон инспекторской роли): базовая настраиваемая роль контроля качества работ. Назначается с настраиваемым scope (own / district / region / program / all), набором разрешённых действий (read / annotate / flag / verify / suspend), типом объектов (СМР / WASH / климат / финансы / антикоррупция). На пилоте используется UNDP-координаторами и нанятыми НКО. На масштабировании клонируется через конструктор Прил. Я.3 в производные шаблоны под конкретные ведомства (GASN, КРУ, ACA, прокуратура, инжкомпания, CSAC, НКО, внешний контролёр).

PROCURATOR_OFFICER (прокуратура Республики Узбекистан): scope all read-only; режим расследования; запрос материалов по официальному обращению. Производный шаблон от FIELD_INSPECTOR через Прил. Я.3.

MOPSE_PROGRAM (управление программами МДшО): согласование M4 планирования, M7 контрактов, M12 верификаций; read M2/M5/M11/M14 republic; доступ к интеграции School Passport Замонавий мактаб (запрос обновления паспорта школы по INN с фиксацией в M18); согласование добавления новых школ за пределами донорских когорт.

Категория: Центральный уровень (МДшО)

MOPSE_OFFICER: - M2/M5/M8/M11/M13/M14 read republic.

MOPSE_STRATEGY: - M4 contribute strategy. - M14 view strategic dashboard. - M15 manage open data policy.

MOPSE_COMPLIANCE: - M5/M7 read republic. - M16 oversee integrity pacts. - M18 read full audit log.

Категория: UNDP

UNDP_PROGRAM_MANAGER: - Полный доступ к программе (все модули, все scope в рамках программы). - M4 approve programs. - M12 sign acceptance acts. - M14 view program dashboard. - M17 receive escalations level 3.

UNDP_PROCUREMENT: - M1 invite users, manage organizations. - M5 create procurement, sign contracts. - M5 blacklist management. - M14 view procurement dashboard.

UNDP_FINANCE: - M5/M7 read all (финансовые показатели). - M7 approve retention return. - M14 view financial dashboard.

UNDP_INTEGRITY: - Полный read доступ к доказательной базе. - M5 blacklist add. - M11 moderate spam. - M14 view integrity dashboard. - M16 oversee pacts. - M18 read full audit log.

Категория: Партнёры

UNICEF_OFFICER: - M2/M5/M8/M11/M13/M14 read program (только программа JP).

CSAC_OBSERVER: - M5/M9/M12 read assigned contracts (по pactам). - M16 publish reports. - M19 publish content.

NGO_MONITOR: - M5/M9 read assigned contracts. - M16 publish reports. - M19 publish content.

Категория: Системные

PLATFORM_ADMIN: - Полный CRUD на справочники, организации, пользователей. - M1 manage users and organizations. - Системные настройки.

PLATFORM_SECURITY: - M1 manage roles and permissions. - M18 read full audit log. - M18 manage security alerts. - Управление SSL-сертификатами, ключами, MFA.

PLATFORM_AUDITOR: - M18 read-only полный доступ. - M14 view all dashboards (read-only). - Запрет на любые изменения.

М.3. Полная таблица в Excel

Полная таблица 29×20×7 = 4060 ячейка предоставляется в виде отдельного xlsx-файла RBAC_Matrix_Full.xlsx с цветовой кодировкой scope.

Приложение Н — СТРАТЕГИЯ И ПЛАН ТЕСТИРОВАНИЯ

Н.1. Виды тестирования

Вид	Цель	Покрытие	Инструмент	Ответственный
Unit-тесты	Проверка отдельных функций	≥70% backend, ≥50% frontend	xUnit / NUnit / Jest / Vitest	Разработчик
Integration-тесты	Проверка взаимодействия модулей	Все интеграции внешних систем	Postman / WireMock / Testcontainers	QA
E2E-тесты	Сквозные сценарии	48 use cases из Приложения А	Playwright / Cypress	QA
Performance-тесты	Нагрузочные сценарии	1000+ одновременных пользователей	k6 / JMeter	DevOps
Stress-тесты	Поведение под пиком	5000+ одновременных пользователей	k6	DevOps
Security-тесты	OWASP Top 10, SAST, DAST	Все endpoints API	SonarQube + OWASP ZAP	Security Engineer
Pentest	Внешний и внутренний	Полный периметр	Профессиональные пентестеры	Подрядчик пентеста
Accessibility-тесты	WCAG 2.1 AA	Все экраны	axe-core / Lighthouse	UX Engineer
Localization-тесты	RU / UZ Latin / EN	Все интерфейсы	Ручное + автоматическое	Локализатор + QA
Responsive/PWA-тесты	Мобильные браузеры iOS/Android, Telegram WebView	Все полевые веб-сценарии: фото, геолокация, чек-листы, подписи, обращения	Playwright device emulation / BrowserStack / Lighthouse PWA	QA
Compatibility-тесты	Браузеры и устройства	Матрица поддержки	BrowserStack / Sauce Labs	QA
Recovery-тесты	DR-сценарии	RTO/RPO compliance	Учения	DevOps

Н.2. Этапы тестирования по фазам разработки

Фаза 1 (MVP)

Unit + Integration для базовых модулей.
Smoke E2E (10 основных сценариев).
Базовый SAST.

Фаза 2 (Расширение)

Полные Integration по всем внешним системам.
Полные E2E (48 сценариев).
Performance baseline (1000 пользователей).
DAST.

Фаза 3 (Масштабирование)

Полный регрессионный набор перед каждым релизом.
Stress-тесты с целевыми числами для 11 127 школ.
Внутренний пентест.

Перед вводом в эксплуатацию

Внешний пентест независимым подрядчиком.
Опытная эксплуатация ≥60 дней.
Прохождение Этапа 3 экспертизы.

Н.3. Метрики качества

Bug Severity Distribution (Critical / High / Medium / Low) — еженедельный отчёт.
Test Coverage — отчёт каждого билда.
Defect Density (баги на 1000 строк кода) — норматив.
MTBF (Mean Time Between Failures) — для production.
Test Execution Time — отчёт каждого ночного прогона.
Flaky Tests Rate — не более 2% от общего числа тестов.

Н.4. Критерии готовности к Этапу 2 экспертизы кибербеза

0 уязвимостей Critical.
0 уязвимостей High.
Не более 10 уязвимостей Medium с планом устранения.
Покрытие unit-тестами ≥70%.
Все E2E сценарии успешны.
Внутренний pentest пройден.

Н.5. План регрессионного тестирования

Перед каждым релизом — полный регрессионный набор.
Ночные прогоны на dev/staging.
Smoke-тесты на production после деплоя.
Автоматизация регрессии — не менее 80%.

Приложение О — АРХИТЕКТУРА РАЗВЁРТЫВАНИЯ И СРЕДЫ

О.1. Среды

Среда	Назначение	Доступ	Данные
DEV	Разработка	Команда разработчика	Тестовые синтетические
TEST	QA-тестирование	QA + разработчики	Тестовые синтетические
STAGING	Предпродакшен	Заказчик + ограниченный круг	Анонимизированная копия production
UAT	Опытная эксплуатация	Реальные пользователи пилота	Реальные ограниченные
PRODUCTION	Промышленная эксплуатация	Все пользователи	Реальные
DR	Disaster Recovery	Активируется при сбое PROD	Гео-резервированная копия

О.2. Контейнерная архитектура

Базовая платформа: Kubernetes (или аналог) на bare metal / IaaS.
Реестр контейнеров: приватный Harbor / GitLab Registry.
Helm charts для каждого микросервиса.
ConfigMaps и Secrets для конфигурации.
Horizontal Pod Autoscaler для масштабирования.

О.3. CI/CD конвейер

[Commit] → [Build] → [Unit Tests] → [SAST] → [SCA] → [Container Build]
   ↓
[Push to Registry] → [Deploy to DEV] → [Integration Tests] → [Deploy to TEST]
   ↓
[QA E2E] → [Deploy to STAGING] → [Approval] → [Deploy to PROD]
   ↓
[Smoke Tests] → [Production Verification] → [Monitoring]

О.4. Инфраструктурные сервисы

API Gateway: Kong / Envoy.
Service Mesh: Istio (опционально).
Logging: ELK / Loki.
Monitoring: Prometheus + Grafana.
Tracing: Jaeger / Tempo.
Secrets: HashiCorp Vault.
Certificate Management: cert-manager.

О.5. Сетевые сегменты

DMZ (внешние API, веб, публичный портал).
Application tier (backend сервисы).
Data tier (базы данных, объектное хранилище).
Management tier (мониторинг, секреты, CI/CD).
VPN tier (WireGuard для видеомониторинга).
DR site (изолированный сегмент в другом ЦОД).

О.6. Высокая доступность

Active-Active для application tier (множественные инстансы).
Primary-Replica для PostgreSQL с автоматическим failover.
Гео-репликация объектного хранилища.
Load balancer (HAProxy / Nginx) перед каждым tier.
Health checks и автоматическое восстановление подов.

О.7. Disaster Recovery

RTO 4 часа: восстановление сервиса.
RPO 1 час: потеря данных не более 1 часа.
Регулярные DR-учения (раз в полгода).
Документированный runbook для каждого типа аварии.

Приложение П — ПЛАН МИГРАЦИИ ДАННЫХ И НАЧАЛЬНОГО НАПОЛНЕНИЯ

Это приложение детализирует требования раздела 7.1 (преобразование входной информации). Платформа МБШ запускается не на пустом месте — на момент её ввода в эксплуатацию уже существуют данные, собранные программой Joint Programme до создания платформы: паспорта школ в Замонавий мактаб, оценки KoboToolbox по 100+ обследованным школам, региональные реестры МДшО, перечень действующих и заключённых ранее контрактов. Эти данные должны быть перенесены в платформу с сохранением их связности и достоверности, иначе платформа после запуска окажется пустой и непригодной к использованию.

Качественный план миграции — это не «загрузить Excel в систему», а сложная задача очистки данных, разрешения конфликтов, валидации, проверки контрольных сумм. Часть данных в первичных источниках содержит ошибки или пропуски — миграция должна их выявить и устранить или явно пометить. Часть данных требует ручной верификации (например, координаты школы из Замонавий мактаб иногда указывают не на здание, а на село — это нужно проверить и при необходимости скорректировать). Подрядчик-разработчик отвечает за разработку процедур миграции; UNDP отвечает за качество исходных данных и за валидацию результатов миграции.

П.1. Источники данных для миграции

Источник	Объём	Формат	Целевая сущность
Замонавий мактаб (Узинфоком)	11 127 школ (на пилоте — 45)	Excel/XLSX	School (паспорта)
KoboToolbox UNDP	100+ оценок	CSV/JSON	KoboAssessment
Engineering Assessment Report UNDP+UNICEF	100+ школ	XLSX	Дополнение к KoboAssessment
Регистры МДшО Сурхандарьи	2 xlsx-файла	XLSX	School + дополнительные атрибуты
Реестры подрядчиков UNDP	50–100	Excel	Organization
Регламент 62 НПА	62 акта	Перечень	REF_LEGAL_ACTS

П.2. Этапы миграции

Этап 1. Подготовка

Определение маппинга полей источник → целевая БД.
Очистка данных (deduplication, normalization).
Валидация ссылочной целостности.
Создание скриптов миграции.
Тестовый прогон на staging.

Этап 2. Первичная загрузка (на старте Фазы 1)

Импорт справочников (регионы, районы, махалли).
Импорт паспортов 45 пилотных школ.
Импорт оценок KoboToolbox.
Регистрация UNDP / UNICEF / МДшО / ACA как организаций.
Создание учётных записей ключевых пользователей.

Этап 3. Текущая миграция (Фазы 2-3)

Импорт результатов тендеров из UN Quantum (через интеграцию И-1).
Регистрация подрядчиков с UBO.
Регистрация контрактов и этапов.

Этап 4. Масштабирование (Фаза 4+)

Миграция данных по 11 127 школам из Замонавий мактаб.
Региональные регистры.
Архив исторических контрактов (если есть).

П.3. Контроль качества миграции

Чек-листы валидации после каждого этапа.
Reconciliation report — сверка количества записей.
Sample audit — выборочная проверка корректности.
Roll-back план на случай сбоев.

П.4. Начальные данные (Initial Seed)

Все справочники (REF_*) заполняются на старте по согласованным шаблонам.
Шаблоны чек-листов по типам пакетов работ.
Шаблоны уведомлений на трёх языках.
Шаблоны актов и Далолатнамы.
Скоринговые методики (KoboToolbox v1 как стартовая).

Приложение Р — CAPACITY PLANNING

Это приложение детализирует требования подраздела 4.3.5 (техническое обеспечение). Capacity planning — расчёт серверных мощностей и инфраструктурных ресурсов, необходимых для работы платформы на разных стадиях её развития: пилотный режим (45 школ), масштабирование на всю Республику (11 127 школ), полная нагрузка (миллион пользователей-граждан). От качества этого расчёта зависят две практически важные вещи: реалистичная стоимость эксплуатации (которую заказчик должен заложить в бюджет программы и в бюджет МДшО на handover) и техническая готовность платформы к росту нагрузки без архитектурных изменений.

Capacity planning приведён в трёх горизонтах: пилот (45 школ — конкретный известный объём), средний масштаб (1000 школ — промежуточный этап масштабирования) и полный охват (11 127 школ — все школы Республики). По каждому горизонту указаны: необходимые ресурсы compute (количество vCPU и RAM по компонентам платформы), storage (БД и объектное хранилище), сетевая полоса, ориентировочная стоимость в год. Эти числа — основа для расчёта бюджета инфраструктуры программы; они также показывают подрядчику-разработчику, что платформа должна с самого начала быть рассчитана на горизонтальное масштабирование, а не быть монолитом, рассчитанным только на пилот.

Р.1. Целевые объёмы

Параметр	Пилот (45 школ)	Полное масштабирование (11 127 школ)
Школ в системе	45	11 127
Активных контрактов	~200	до 50 000 одновременно
Институциональных пользователей	~1 000	~50 000
Граждан-пользователей (зарегистрированных)	~10 000	~1 000 000
Обращений граждан в день	~100	~10 000
Фотографий в день	~5 000	~500 000
Видеопотоков одновременно	~45	~5 000
Размер хранилища (год)	~5 ТБ	~500 ТБ

Р.2. Расчёт серверных ресурсов

Application tier

Пилот: 4 узла × 8 vCPU / 16 ГБ.
Масштабирование: 20–40 узлов с auto-scaling по нагрузке.

Database tier

Пилот: PostgreSQL primary 16 vCPU / 32 ГБ / 1 ТБ NVMe SSD + replica.
Масштабирование: кластер с шардингом по регионам, primary 64 vCPU / 128 ГБ / 10 ТБ + read replicas.

Object storage

Пилот: 50 ТБ.
Масштабирование: 500 ТБ + 100 ТБ резерв (с автоматическим расширением).

Media servers (видеопотоки)

Пилот: 2 узла × 8 vCPU / 16 ГБ.
Масштабирование: 50 узлов с load balancer.

Cache (Redis)

Пилот: 4 vCPU / 16 ГБ.
Масштабирование: cluster mode, 16 vCPU / 64 ГБ.

Search (Elasticsearch)

Пилот: 3 узла × 8 vCPU / 32 ГБ.
Масштабирование: 9 узлов с шардингом.

Сетевая пропускная способность

Пилот: 1 Гбит/с.
Масштабирование: 10 Гбит/с с резервированием.

Р.3. Бюджетная оценка инфраструктуры (ориентировочно)

Категория	Пилот в год	Масштабирование в год
Compute (vCPU/RAM)	$30 000	$300 000
Storage (объектное + БД)	$20 000	$200 000
Network	$10 000	$80 000
Лицензии (если применимо)	$20 000	$150 000
Резерв (15%)	$12 000	$110 000
Итого	~$92 000	~$840 000

Р.4. Оптимизация затрат

Использование Open Source стека где возможно (Kubernetes, PostgreSQL, Redis, Elasticsearch).
Объектное хранилище с tier’инг (горячие/тёплые/холодные данные).
Видеоархив на холодное хранилище после 7 дней.
Шардинг по регионам для распределения нагрузки.

Приложение С — ПЛАН ОБУЧЕНИЯ

Это приложение детализирует требования раздела 7.2 (подготовка персонала). Без качественного обучения сданная платформа быстро превратится в нерабочий инструмент — пользователи либо не смогут её использовать, либо будут использовать неправильно. Особенно это касается полевых пользователей (прорабы, завхозы, оценщики, инспекторы), для которых платформа — лишь часть их рабочих обязанностей, а не специальность.

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

С.1. Категории обучаемых

Категория	Численность пилот	Численность масштабирования	Формат обучения
Директора школ	45	11 127	Видеокурс + очный семинар
Хозперсонал	90	~20 000	Видеокурс
Подрядчики (представители)	~50	~1 000	Очный + сертификация
Подрядчики (полевые)	~200	~10 000	Видеоинструкции + полевая поддержка
Технадзор	~20	~500	Очный курс
Региональные координаторы	~10	~150	Очный курс + supervision
МДшО (центральный аппарат)	~30	~30	Очный курс
Администраторы платформы	~5	~20	Сертификационная программа

С.2. Содержание курсов

Базовый курс «Знакомство с платформой» (для всех)

30 минут видео.
Регистрация и вход.
Навигация по интерфейсу.
Подача обращений.
Просмотр публичной информации.

Курс для директоров (2 часа)

Управление паспортом школы.
Размещение QR-кода.
Работа с обращениями.
Подписание актов.
Дашборд директора.

Курс для подрядчиков (4 часа + сертификация)

Регистрация в платформе.
Раскрытие UBO.
Работа с контрактами и этапами.
Загрузка фотоотчётов и видеоматериалов.
Настройка видеомониторинга (для уполномоченных).
Реагирование на обращения и гарантийные случаи.
Финансовая отчётность.

Курс для технадзора (4 часа)

Очередь верификаций.
Просмотр доказательств.
Подтверждение чек-листов.
Подписание решений.

Курс для региональных координаторов (1 день)

Все функции технадзора + дополнительно.
Управление пользователями региона.
Дашборды и аналитика.
Эскалации.

Курс для администраторов платформы (1 неделя)

Архитектура платформы.
Управление справочниками.
Управление пользователями и ролями.
Управление шаблонами.
Журнал аудита и расследования.
Резервное копирование и восстановление.
Инцидент-менеджмент.

С.3. Train-the-Trainers (TtT)

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

С.4. Учебные материалы

Видеоинструкции (на трёх языках).
PDF-руководства.
Интерактивные туторы внутри платформы (онбординг).
База знаний с поиском.
Чат-бот для частых вопросов.

С.5. Метрики обучения

% охвата обученных пользователей.
Средний балл сертификации.
Время от регистрации до самостоятельной работы (target ≤2 часа после обучения).
Количество обращений в техподдержку (как индикатор качества обучения).

Приложение Т — РАСШИРЕННОЕ SLA

Это приложение детализирует требования подразделов 4.1.4 (надёжность) и 4.1.7 (эксплуатация). SLA (Service Level Agreement) — это не просто набор технических метрик, а финансово-юридический контракт между заказчиком и подрядчиком-разработчиком (на этапе разработки и гарантийной поддержки) или между бенефициаром и провайдером эксплуатации (после handover). Без чётких SLA с конкретными числами и штрафами за нарушение, требования к надёжности остаются благими пожеланиями.

В приложении детализированы SLA по четырём аспектам: доступность платформы (с распределением по разным уровням — Платинум, Голд, Сильвер для разных типов функциональности), время отклика операций (с указанием 50, 95, 99 перцентилей по типам операций), поддержка пользователей (по приоритетам инцидентов P1–P4 с указанием времени реакции и решения), информационная безопасность (реакция на инциденты, уведомления при утечках, расследование). Для каждого нарушения SLA указан конкретный штраф в процентах от месячной стоимости поддержки — что превращает SLA из декларации в живой инструмент управления качеством.

Т.1. SLA по доступности

Уровень	Доступность	Допустимый простой в месяц	Применяется к
Платинум	99,9%	43 минуты	Платежи, ЭП, кибербезопасность
Голд	99,5%	3 часа 36 минут	Основная функциональность
Сильвер	99%	7 часов 12 минут	Аналитика, отчёты
Бронза	95%	36 часов	Открытые данные

Т.2. SLA по времени отклика

Операция	50-й перцентиль	95-й перцентиль	99-й перцентиль
Логин	<500 мс	<1 с	<2 с
Просмотр карточки школы	<300 мс	<800 мс	<1,5 с
Поиск школы (11 127)	<200 мс	<500 мс	<1 с
Загрузка фото 5 МБ (4G)	<3 с	<5 с	<10 с
Загрузка дашборда области	<1 с	<2 с	<4 с
Видеостриминг (старт)	<2 с	<5 с	<10 с
Подача обращения (web)	<500 мс	<1 с	<2 с

Т.3. SLA по поддержке пользователей

Приоритет	Время реакции	Время решения
P1 — критический (платформа недоступна)	15 минут 24/7	4 часа
P2 — высокий (частичная недоступность)	1 час 24/7	12 часов
P3 — средний (ошибки, не блокирующие)	4 часа в рабочее время	5 рабочих дней
P4 — низкий (запросы, улучшения)	8 часов в рабочее время	По согласованию

Т.4. SLA по информационной безопасности

Событие	Время реакции
Обнаружение инцидента	15 минут (мониторинг)
Уведомление администрации	1 час
Начало расследования	2 часа
Уведомление субъектов ПДн при утечке	72 часа (по ЗРУ-1125)
Уведомление Центра кибербеза при критическом инциденте	24 часа (по ЗРУ-764)

Т.5. Штрафы за нарушение SLA

Нарушение	Штраф
Простой больше Платинум норматива	5% от месячной стоимости поддержки за каждый час сверх
Простой больше Голд норматива	2% от месячной стоимости поддержки за каждый час сверх
Превышение времени реакции P1	1% от месячной стоимости
Превышение времени решения P1	3% от месячной стоимости

Т.6. Регулярная отчётность

Ежемесячный SLA-отчёт от подрядчика поддержки.
Ежеквартальный обзор с заказчиком.
Ежегодная пересмотр SLA-параметров.

Приложение У — РЕЕСТР РИСКОВ И ПЛАН МИТИГАЦИИ

Это приложение содержит ключевой документ управления проектом. Любой крупный ИКТ-проект сталкивается с рисками: технологическими (выбранный стек оказался неподходящим), организационными (ключевой специалист уволился), внешними (партнёрская система не предоставила обещанные API), регуляторными (изменилось законодательство). Реестр рисков — не пессимистичный документ, а инструмент превентивного управления: риски, выявленные заранее, можно митигировать; риски, которые выявляются только когда они уже реализовались, обходятся в разы дороже.

Реестр содержит топ-15 рисков проекта, отсортированных по баллу (вероятность × влияние). По каждому риску указаны: описание, вероятность (низкая / средняя / высокая), потенциальное влияние (низкое / среднее / высокое / критическое), балл, план митигации, ответственный за митигацию. Реестр актуализируется еженедельно в ходе разработки и ежемесячно в фазе эксплуатации. Появление новых рисков фиксируется в течение 2 рабочих дней. Риски с баллом 9 и выше эскалируются на Steering Committee программы.

У.1. Категории рисков

Технические риски.
Институциональные риски.
Финансовые риски.
Юридические и регуляторные риски.
Операционные риски.
Риски информационной безопасности.

У.2. Реестр (топ-15 рисков)

ID	Риск	Вероятность	Влияние	Балл	Митигация	Ответственный
R-01	Низкое качество ПО, обнаружение критических дефектов на финальной приёмке	Средняя	Критическое	9	Сквозной SAST/DAST в CI/CD, регулярный pentest, постоянное код-ревью	Подрядчик
R-02	Задержка интеграции с UN Quantum	Средняя	Высокое	8	Раннее согласование API с менеджером по закупкам, fallback на ручной ввод	Подрядчик
R-03	Отказ Узинфоком от интеграции School Passport	Низкая	Высокое	6	Ручная выгрузка Excel как Plan B	UNDP_PM
R-04	Утечка персональных данных	Низкая	Критическое	8	Шифрование, MFA, аудит, регулярный пентест, обучение	Security
R-05	Срыв сроков подрядчиком ИТ	Высокая	Высокое	9	Поэтапные deliverables, штрафы, удержание retention	UNDP_PROCUREMENT
R-06	Низкое качество кода	Средняя	Высокое	8	SAST, code review, метрики качества	Подрядчик
R-07	Сопротивление принятию платформы пользователями	Средняя	Высокое	8	План обучения, поэтапное внедрение, обратная связь	UNDP_PM + МДшО
R-08	Подрядчики не загружают данные	Высокая	Высокое	9	Привязка выплат к данным, штрафы, адаптивный веб/PWA и Telegram MiniApp	UNDP_PM
R-09	Видеокамеры подрядчики не устанавливают	Средняя	Высокое	8	Обязательное требование в контракте, штрафы	UNDP_PROCUREMENT
R-10	Бюджет инфраструктуры превышен	Средняя	Среднее	6	Капасити-планирование, Open Source стек, tier’инг	DevOps
R-11	Не утверждён handover МДшО	Высокая	Критическое	12	Раннее согласование, документированный план	UNDP_PM
R-12	Регулярные изменения требований в ходе разработки	Высокая	Высокое	9	Change Management процесс, согласования	UNDP_PM
R-13	Атака на платформу (DDoS, exploit)	Средняя	Высокое	8	WAF, rate limiting, DDoS protection, мониторинг	Security
R-14	Неподтверждённое качество интеграций с внешними системами	Средняя	Высокое	8	Контрактные обязательства владельцев интеграций; раннее тестирование с моками	Подрядчик
R-15	Сбой шлюза SMS	Средняя	Высокое	8	Резервный поставщик, мониторинг	DevOps

У.3. Процесс управления рисками

Реестр рисков пересматривается еженедельно на статус-митингах.
При обнаружении нового риска — внесение в реестр в течение 2 рабочих дней.
Эскалация рисков с баллом ≥9 на Steering Committee.
Постмортем по реализовавшимся рискам с обновлением митигации.

Приложение Х — ПЛАН УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ

Это приложение определяет правила управления изменениями в ходе разработки и эксплуатации. Распространённая проблема ИКТ-проектов — «scope creep», когда требования постоянно расширяются под давлением заинтересованных сторон, что приводит к срыву сроков и бюджета. С другой стороны, ригидное «всё по ТЗ, ничего не меняем» приводит к тому, что платформа оказывается негибкой и не соответствующей реальным потребностям, выявленным в ходе разработки. Хорошее управление изменениями балансирует эти крайности.

Приложение описывает категоризацию изменений (малое / среднее / большое / критическое), процедуру подачи и согласования Change Request, регулярную ритмику релизов (минор каждые 2 недели, мажор каждые 3 месяца, хотфикс по необходимости), правила обратной совместимости API. Это не бюрократическая нагрузка, а инструмент сохранения предсказуемости проекта при сохранении его гибкости.

Х.1. Категории изменений

Категория	Описание	Процедура
Малое	Bug fix, мелкая доработка	Стандартная процедура CI/CD
Среднее	Новая функция в существующем модуле	Approve UNDP_PM, тестирование, релиз
Большое	Новый модуль, изменение архитектуры	Change Request, Steering Committee
Критическое	Безопасность, P1-инцидент	Emergency change, post-mortem

Х.2. Change Request форма

Описание изменения.
Обоснование.
Влияние (модули, пользователи, данные, интеграции).
Оценка рисков.
Бюджет и сроки.
Согласования.

Х.3. Регулярные релизы

Минор-релиз: каждые 2 недели.
Мажор-релиз: каждые 3 месяца.
Хотфикс: по необходимости.

Х.4. Обратная совместимость

API версионируется (v1, v2, …).
Старые версии поддерживаются не менее 12 месяцев после релиза новой.
Уведомления о deprecation за 6 месяцев.

Приложение Ц — СТРАТЕГИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ

Это приложение детализирует требования подраздела 4.1.4 (надёжность) и 4.1.7 (эксплуатация). Платформа МБШ хранит критически важные данные: история выплат, акты приёмки, видеоархивы, журнал аудита. Утрата этих данных в результате аппаратного сбоя, программной ошибки или атаки означала бы катастрофу — невозможно было бы доказать факт расходования средств, невозможно было бы продолжать контроль гарантийных обязательств, невозможно было бы провести независимый аудит. Поэтому стратегия резервного копирования — не формальное требование, а конкретная архитектурная конструкция, отвечающая на реальные риски.

Стратегия задаёт пять уровней резервирования (от непрерывной WAL-репликации до ежемесячных архивов на холодном хранилище), сроки хранения каждого уровня (от 7 дней для логов до 10 лет для журнала аудита), цели восстановления RTO и RPO, защиту от ransomware (immutable backups, air-gapped копии). Регулярные тесты восстановления раз в квартал — обязательное условие, а не «по возможности»: backup, который никогда не тестировался, может оказаться нерабочим в момент, когда он нужен.

Ц.1. Уровни резервирования

Уровень 1 — Транзакционные логи: непрерывно (WAL архивирование).
Уровень 2 — Снэпшот БД: ежедневно.
Уровень 3 — Полная резервная копия БД: еженедельно.
Уровень 4 — Объектное хранилище (фото, видео, документы): непрерывная репликация в гео-резервированный регион.
Уровень 5 — Архив: ежемесячный архив на холодное хранилище.

Ц.2. Хранение

Тип копии	Срок хранения	Местоположение
Транзакционные логи	7 дней	Основной ЦОД + резервный
Дневные снэпшоты	30 дней	Основной + резервный
Еженедельные	12 месяцев	Резервный ЦОД
Ежемесячные	7 лет	Архив (холодное хранилище)
Журнал аудита	10 лет	Изолированный архив

Ц.3. Восстановление

RTO (Recovery Time Objective): 4 часа.
RPO (Recovery Point Objective): 1 час.
Регулярные тесты восстановления (раз в квартал).
Документированные runbook.

Ц.4. Защита от ransomware

Immutable backups (нельзя изменить или удалить в течение retention периода).
Air-gapped копии (физически изолированные).
Регулярное сканирование на признаки атак.

Приложение Ч — ПОЛИТИКА УПРАВЛЕНИЯ API

Это приложение детализирует требования подразделов 4.1.2 (интеграция со сторонними системами) и 4.2.3 (модуль M15 — открытые данные и API). API платформы используются как другими системами (UN Quantum, Замонавий мактаб, ГАСН), так и внешними разработчиками (НКО, журналисты, исследователи), создающими собственные приложения на данных платформы. Отсутствие формальной политики API создаёт риск несогласованных изменений контрактов, отказов внешних клиентов, неконтролируемого потребления ресурсов и нарушений безопасности.

Политика управления API охватывает: версионирование (семантическое, path-based, с поддержкой старых версий 12 месяцев), аутентификацию (OAuth 2.0, JWT, mTLS для интеграции с государственными системами), rate limiting (разные лимиты для разных категорий клиентов), throttling и Circuit Breaker для защиты от перегрузки, документацию (OpenAPI 3.0 + Swagger UI + примеры запросов). Это превращает API из побочного эффекта разработки в полноценный продукт с собственной дисциплиной.

Ч.1. Версионирование

Семантическое версионирование: vMAJOR.MINOR.PATCH.
Path-based: /v1/, /v2/.
Старые версии: 12 месяцев после релиза новой.
Deprecation notices в HTTP заголовках.

Ч.2. Аутентификация

OAuth 2.0/OpenID Connect допускаются только для согласованных интеграций и федеративной идентификации; социальные логины и потребительские провайдеры идентичности запрещены.
JWT токены с коротким временем жизни (1 час).
Refresh tokens (24 часа).
API keys для машинных клиентов (с возможностью отзыва).
mTLS для интеграции с государственными системами.

Ч.3. Rate limiting

Категория	Лимит
Анонимные клиенты (открытый API)	100 запросов/минуту на IP
Зарегистрированные разработчики	1000 запросов/минуту
Институциональные клиенты (UN Quantum, Замонавий мактаб)	10000 запросов/минуту
Внутренние сервисы	без лимита (через service mesh)

Ч.4. Throttling и Circuit Breaker

Throttling при пиковых нагрузках.
Circuit Breaker для интеграций (Hystrix-подобный).
Graceful degradation.

Ч.5. Документация

OpenAPI 3.0 спецификация для всех API.
Swagger UI с интерактивной песочницей.
Примеры запросов на нескольких языках.
Changelog между версиями.

Приложение Ш — ПЛАН ПУБЛИКАЦИИ ОТКРЫТЫХ ДАННЫХ

Это приложение детализирует требования к модулю M15 (раздел 4.2.3). Открытые данные являются регулируемым процессом публикации наборов данных с установленным составом, частотой обновления, лицензией, ограничениями персональных данных и контролем качества. Публикуемые данные должны быть машинно-читаемыми (CSV / JSON / OCDS, а не PDF-отчёты), регулярно обновляемыми (с известной частотой и временем публикации, чтобы потребители могли построить свои процессы), документированными (со словарём полей, описанием семантики, известными ограничениями), правомерно лицензированными (Creative Commons Attribution 4.0 — самая распространённая лицензия открытых данных).

Без качественного плана публикации открытые данные либо не используются никем (нет регулярной обновляемости, нет документации), либо используются неправильно (потребители делают ошибочные выводы из-за отсутствия информации об ограничениях). План охватывает: каталог наборов данных с указанием форматов и частоты обновления, расписание снэпшотов (ежедневно в 03:00 — единое время для всех потребителей), процедуру обновления при изменении схемы данных, регламент работы с обратной связью от потребителей.

Ш.1. Каталог наборов

Набор	Формат	Частота обновления	Лицензия
Школы (паспорта без ПДн)	JSON, CSV, GeoJSON	Еженедельно	CC-BY 4.0
Тендеры	OCDS JSON, CSV	Ежедневно	CC-BY 4.0
Контракты	OCDS JSON, CSV	Ежедневно	CC-BY 4.0
Выплаты (агрегированные)	OCDS JSON, CSV	Еженедельно	CC-BY 4.0
Обращения граждан (обезличенные)	JSON, CSV	Ежедневно	CC-BY 4.0
Штрафы и санкции	JSON, CSV	Ежедневно	CC-BY 4.0
Чёрный список подрядчиков	JSON, CSV	По изменении	CC-BY 4.0
Гарантийные случаи (агрегированные)	JSON	Еженедельно	CC-BY 4.0

Ш.2. Снэпшоты

Полный снэпшот ежедневно в 03:00.
Хранение последних 30 дней + ежемесячные за год.
Доступ по HTTP, без аутентификации.

Ш.3. API

REST endpoints для каждого набора.
OCDS-стандарт для закупочных данных.
Документация в Swagger.

КОНЕЦ ПАКЕТА ОБОГАЩЕНИЯ v0.3

Приложение Щ — Диаграммы состояний ключевых сущностей

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

Щ.1. School (Школа)

Состояния: draft, active, in_program, in_renovation, commissioned, in_warranty, post_warranty, archived.

Таблица переходов:

Из состояния	В состояние	Кто инициирует	Условие перехода	Side effects
(нет)	draft	PLATFORM_ADMIN	импорт из Замонавий мактаб	создаётся school_id, фиксируется в журнале аудита
draft	active	PLATFORM_ADMIN	заполнены обязательные поля паспорта	школа становится видимой в реестре, доступна для оценки
active	in_program	UNDP_PROGRAM_MANAGER	школа включена в утверждённую программу года	автоматический подсчёт KPI программы
in_program	in_renovation	UNDP_PROGRAM_MANAGER	подписан первый контракт работ по школе	разблокировка функций ввода данных по этапам
in_renovation	commissioned	UNDP_PROGRAM_MANAGER	подписана финальная Далолатнома (UC-A23)	автоматический запуск 5-летнего гарантийного отсчёта
commissioned	in_warranty	автоматически системой	переход через 24 часа после commissioned	активация маршрутизации гарантийных случаев
in_warranty	post_warranty	автоматически системой	истёк 5-летний гарантийный срок	формирование финального отчёта по гарантии
post_warranty	archived	MOPSE_OFFICER	школа закрыта (реорганизация / снос)	данные сохраняются в архиве, доступ только на чтение
Любое	archived	PLATFORM_ADMIN	редкий случай с зарегистрированным основанием	требуется обоснование

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

Щ.2. Contract (Контракт)

Состояния: draft, signed, in_progress, suspended, completed, closed, terminated.

Из состояния	В состояние	Кто инициирует	Условие перехода	Side effects
(нет)	draft	UN Quantum через интеграцию И-1	закрытие тендера с победителем	автоматическое уведомление UNDP_PROCUREMENT
draft	signed	UNDP_PROCUREMENT	проверка данных, прикрепление подписанного скана	разблокировка модулей M5, M6, M8, M9 для этого контракта
signed	in_progress	автоматически	старт первого этапа подрядчиком (UC-A14)	публикация в публичной витрине
in_progress	suspended	UNDP_PROGRAM_MANAGER или GASN_INSPECTOR	критическое нарушение (UC-A21)	блокировка всех выплат и подачи этапов
suspended	in_progress	UNDP_PROGRAM_MANAGER	подтверждено устранение причины (UC-A22)	разблокировка функций
in_progress	completed	автоматически	все этапы подписаны, retention возвращена	формирование акта закрытия
completed	closed	автоматически	подписан акт закрытия	архивация документации
Любое (кроме closed)	terminated	UNDP_PROGRAM_MANAGER	накопленные штрафы > 10% или коррупция	расторжение, расчёт окончательного баланса

Запреты: - Контракт нельзя закрыть, если есть открытые гарантийные случаи или непогашенные штрафы. - Из terminated возврат невозможен. - Из closed возврат возможен только в исключительном случае через PLATFORM_ADMIN с обязательным основанием (например, обнаружена ошибка закрытия).

Щ.3. ContractMilestone (Этап контракта)

Состояния: pending, in_progress, submitted, under_review, verified, rejected, completed.

Из	В	Кто	Условие
(нет)	pending	автоматически	создание этапа при подписании контракта
pending	in_progress	CONTRACTOR_REPRESENTATIVE	старт этапа (UC-A14)
in_progress	submitted	CONTRACTOR_REPRESENTATIVE	подача на верификацию (UC-A17)
submitted	under_review	автоматически	технадзор открыл этап для проверки
under_review	verified	REGIONAL_ENGINEERING	все пункты чек-листа подтверждены
under_review	rejected	REGIONAL_ENGINEERING	часть пунктов отклонена
rejected	in_progress	CONTRACTOR_REPRESENTATIVE	устранение замечаний, повторная подача
verified	completed	автоматически	подписан этапный акт

Запреты: - Этап не может быть в submitted без полного чек-листа с доказательствами. - Этап не может перейти в verified без открытия технадзором всех привязанных доказательств (фиксируется в журнале). - Из completed возврат невозможен.

Щ.4. AcceptanceAct (Акт приёмки)

Состояния: draft, pending_signatures, signed, cancelled.

Из	В	Кто	Условие
(нет)	draft	автоматически	генерация после verified этапа
draft	pending_signatures	автоматически	отправка уведомлений подписантам
pending_signatures	signed	автоматически	получены подписи всех обязательных сторон
pending_signatures	cancelled	UNDP_PROGRAM_MANAGER	выявлена ошибка до завершения подписания
signed	(терминальное)	—	переход невозможен; для отмены создаётся новый компенсирующий акт

Щ.5. Payment (Выплата)

Состояния: due, pending, paid, failed, on_hold.

Из	В	Кто	Условие
(нет)	due	автоматически	подписан этапный акт
due	pending	автоматически	уведомление в UN Quantum отправлено
pending	paid	UN Quantum через И-1	банковский платёж выполнен
pending	failed	UN Quantum через И-1	банковская операция отклонена
due	on_hold	UNDP_INTEGRITY	подозрение на нарушение, расследование
on_hold	due	UNDP_INTEGRITY	расследование закрыто, штраф наложен либо снят
failed	due	UNDP_FINANCE	повторная попытка после устранения причины

Щ.6. CitizenFeedback (Обращение гражданина)

Состояния: new, acknowledged, in_progress, resolved, escalated, closed_with_response, closed_no_action, marked_as_spam.

Из	В	Кто	Условие
(нет)	new	PUBLIC или CITIZEN_AUTHENTICATED	подача открытого сигнала или формального обращения (UC-A27)
new	acknowledged	первичный ответственный	открытие обращения
acknowledged	in_progress	ответственный	начало работы по обращению
in_progress	resolved	ответственный	устранение проблемы зафиксировано
Любое до resolved	escalated	автоматически	истечение SLA
resolved	closed_with_response	ответственный	публикация ответа заявителю
in_progress	closed_no_action	ответственный	обращение признано не требующим действий (с обоснованием)
new	marked_as_spam	модератор	очевидный спам (UC-A32)

Щ.7. WarrantyCase (Гарантийный случай)

Состояния: new, acknowledged, in_progress, resolved, disputed, escalated, closed.

Из	В	Кто	Условие	SLA
(нет)	new	автоматически	классификация обращения как гарантийного (UC-A38)	—
new	acknowledged	подрядчик	подтверждение приёма	24 часа
acknowledged	in_progress	подрядчик	выезд бригады на объект	48 часов
in_progress	resolved	подрядчик	устранение зафиксировано	7 рабочих дней (критический) или 30 рабочих дней
resolved	closed	школа	подтверждение устранения школой	5 рабочих дней
Любое	escalated	автоматически	истечение SLA	—
in_progress	disputed	подрядчик или школа	конфликт по факту дефекта	—
disputed	in_progress	UNDP_PROGRAM_MANAGER	разрешение конфликта	—

Конец Технического задания.

Приложение Э — Требования к пользовательскому интерфейсу и UX

Это приложение детализирует требования к удобству использования из подраздела 4.1.6. Без качественной UI/UX спецификации даже технически правильно реализованная платформа окажется непригодной для использования. Подрядчик-разработчик обязан создать дизайн-систему и wireframes ключевых экранов на стадии эскизного проектирования (стадия 4) и согласовать их с заказчиком до начала разработки.

Э.1. Дизайн-система

Подрядчик создаёт и поддерживает дизайн-систему платформы со следующими компонентами:

Цветовая палитра: - Основной цвет UNDP — синий (#0078D4 или близкий, по согласованию с UNDP). - Дополнительные цвета: серый, белый, акценты для статусов (зелёный — успех, жёлтый — предупреждение, красный — критическое, синий — информация). - Семантические цвета для маркеров на карте (статус школы).

Типографика: - Системные шрифты для веб (sans-serif семейства, поддерживающие кириллицу и латиницу). - Размеры и стили: H1, H2, H3, body, caption, footnote.

Компонентная библиотека: - Кнопки (primary, secondary, tertiary, danger). - Поля ввода (текст, число, дата, выпадающий список, переключатель, чекбокс). - Таблицы со стандартной структурой (заголовки, фильтры, сортировка, пагинация). - Карточки. - Модальные окна. - Уведомления (toast, banner). - Навигация (главное меню, боковая панель, breadcrumbs). - Загрузка файлов (drag-and-drop, превью). - Карта. - График. - Шкала прогресса. - Лента событий.

Э.2. Информационная архитектура

Главное меню (для авторизованного пользователя): - Главная (дашборд по роли). - Школы. - Программы. - Тендеры. - Контракты. - Обращения. - Гарантии. - Видеомониторинг. - Аналитика. - Отчёты. - Справочники (для администраторов). - Профиль.

Структура каждого раздела: - Список с фильтрами и поиском. - Карточка отдельной сущности с вкладками для разных аспектов. - Действия — кнопки на карточке. - История — отдельная вкладка с журналом всех событий по сущности.

Э.3. Wireframes ключевых экранов

Подрядчик создаёт wireframes (low-fi и hi-fi) минимум для 20 экранов:

Главная страница (публичная).
Публичная страница школы (по QR-коду).
Форма подачи обращения через QR.
Лента обращений школы (публичная).
Личный кабинет директора школы.
Личный кабинет подрядчика (главная).
Карточка контракта подрядчика.
Чек-лист этапа работ (мобильная веб-версия / Telegram MiniApp).
Загрузка фотоотчёта (мобильная веб-версия / Telegram MiniApp).
Очередь верификаций технадзора.

Дополнительный view к экрану 10 для внешнего контролёра: сроки, критический путь, отставания, pending evidence, замечания, SLA и экспорт отчёта по назначенному scope.

Карточка верификации этапа.
Дашборд координатора программы UNDP.
Карта школ региона.
Карточка школы (расширенная для координатора).
Конструктор отчёта.
Журнал аудита.
Управление пользователями и ролями.
Раскрытие UBO при регистрации подрядчика.
Подписание акта с MFA.
Просмотр прямой трансляции видеомониторинга.

Wireframes согласовываются с заказчиком и доступны в редактируемом формате (Figma или эквивалент) для будущих изменений.

Э.4. Tone of voice и формулировки

Дружелюбный, но профессиональный тон.
Прямой стиль без бюрократических оборотов.
Действия — глаголами в повелительном наклонении или инфинитиве («Загрузить отчёт», «Подписать акт»).
Сообщения об ошибках — конкретные с указанием действия для исправления.
Кнопка отмены — всегда менее заметна, чем кнопка подтверждения, но не серая (видимая).
Подсказки (tooltips) — там, где это улучшает понимание, но не на каждом элементе.

Э.5. Адаптивность

Desktop (≥1280px): полный функционал.
Tablet (768–1279px): полный функционал с адаптированной разметкой.
Mobile (<768px): фокус на полевые сценарии (загрузка фото, чек-листы, обращения через QR, дашборды просмотра).

Э.6. Доступность

Соответствие WCAG 2.1 AA как минимум.
Контрастность текста ≥ 4.5:1 для основного текста.
Полная работа с клавиатуры (без мыши).
Поддержка screen readers (ARIA-роли).
Альтернативные тексты для изображений (для photo-evidence — комментарий подрядчика).
Размеры элементов на мобильном ≥ 44×44 px для touch targets.

Э.7. Обработка пустых состояний

Каждый экран со списком имеет специальный дизайн для случая, когда список пуст: - Объяснение, почему список пуст («У вас пока нет активных контрактов»). - Подсказка, что делать («Дождитесь подписания контракта менеджером по закупкам»). - Если применимо — кнопка для действия («Начать новый отчёт»).

Э.8. Обратная связь о действиях

Любое действие пользователя получает мгновенную обратную связь.
Для быстрых операций (<200мс) — изменение состояния UI.
Для средних (200–2000мс) — индикатор загрузки (spinner на кнопке).
Для длительных (>2с) — progress bar с указанием стадии.
Завершение — toast-уведомление с подтверждением успеха или ошибки.

Э.9. Уведомления

В шапке каждого экрана — индикатор непрочитанных уведомлений (число).
При нажатии — раскрывающийся список последних уведомлений.
Полный список — отдельный раздел.
Возможность отметить как прочитанное.

Э.10. Тёмная тема (опционально)

Желательная, но не обязательная функция. Подрядчик может реализовать её во второй фазе.

Приложение Ю — Детальные требования к информационной безопасности

Это приложение детализирует требования подраздела 4.1.5 (безопасность). Платформа МБШ — антикоррупционная система, которая в случае компрометации потеряет своё главное свойство — доверенность. Поэтому требования к безопасности формулируются как абсолютные.

Ю.1. Парольная политика

Требования к паролю: - Минимальная длина: 12 символов. - Обязательные классы: латинские буквы (минимум одна заглавная, минимум одна строчная), цифры (минимум одна), специальные символы (минимум один). - Запрет использования имени пользователя, email, имени организации в пароле. - Запрет общеизвестных паролей (проверка по словарям типа «топ-1000 наиболее используемых»). - Проверка против скомпрометированных паролей (например, через интеграцию с Have I Been Pwned API).

Управление жизненным циклом: - История паролей: запрет повторного использования последних 10 паролей. - Срок действия: 180 дней с принудительной сменой. За 7 дней до истечения — напоминания. - Принудительная смена при первом входе после регистрации или сброса администратором.

Защита от перебора: - После 5 неуспешных попыток входа — временная блокировка аккаунта на 15 минут. - После 3 блокировок подряд — суточная блокировка с уведомлением администратора. - CAPTCHA после 3 неуспешных попыток. - Rate limiting на эндпоинте логина (не более 10 попыток в минуту с одного IP).

Восстановление: - Через подтверждённый email + дополнительное подтверждение через SMS. - Ссылка для сброса действительна 30 минут. - При сбросе принудительная смена пароля и инвалидация всех активных сессий.

Ю.2. Управление сессиями

Срок жизни активной сессии: 8 часов для рабочих ролей (CONTRACTOR, DIRECTOR, ENGINEER); 30 минут для критических ролей (UNDP_FINANCE, UNDP_INTEGRITY, PLATFORM_ADMIN, PLATFORM_SECURITY).
Автоматический logout при неактивности (15 минут для критических ролей, 60 минут для остальных).
Возможность видеть список активных сессий в личном кабинете с возможностью завершить любую удалённо.
Принудительное завершение всех сессий администратором при подозрении на компрометацию.
Защита от session fixation: при логине генерируется новый session ID.
HttpOnly + Secure + SameSite=Strict для cookies сессии.

Ю.3. Многофакторная аутентификация (MFA)

Обязательна для всех ролей, кроме PUBLIC и CITIZEN_AUTHENTICATED.

Поддерживаемые вторые факторы и механизмы строгой аутентификации: OneID/SSO для пользователей государственных органов; E-IMZO/eMZO или иная согласованная национальная инфраструктура ЭЦП для юридически значимых действий; SMS-OTP для граждан и резервных сценариев; аппаратные криптографические средства — только при согласовании с владельцем системы и требованиями информационной безопасности. Потребительские приложения-аутентификаторы и социальные провайдеры идентичности не допускаются.

Подписание критических действий (re-authentication): - Подписание актов и Далолатнамы. - Изменение справочников безопасности. - Внесение подрядчика в чёрный список. - Возврат retention. - Удаление пользователя.

Перед каждым таким действием — повторное подтверждение MFA.

Ю.4. Классификация данных

Класс	Описание	Меры защиты
Public	Данные, открытые для всех	базовая защита от модификации, кэширование, публикация
Internal	Данные для авторизованных пользователей	стандартное HTTPS, контроль доступа по ролям
Confidential	Финансовая информация, договоры, контактные данные сторон	HTTPS + шифрование в БД, аудит каждого доступа, ограниченный RBAC
Restricted	UBO, PII граждан, медицинские записи, журнал аудита	максимальная защита: шифрование, MFA, журнал каждого просмотра, hardware HSM для ключей

Каждое поле модели данных должно иметь явный класс защиты.

Ю.5. Управление криптографическими ключами

Все ключи хранятся в выделенном vault (HashiCorp Vault или эквивалент).
Доступ к ключам — только через service account приложения, не для пользователей.
Ротация ключей шифрования данных — каждые 12 месяцев.
Ротация ключей TLS — каждые 90 дней (или согласно требованиям CA).
Журнал каждого использования ключа.
Backup ключей — в защищённой форме в отдельном хранилище.
Разделение ключей: ключи production не используются в test/staging средах.

Ю.6. Регламент реагирования на инциденты

Классификация инцидентов: - P1 — критический: компрометация платформы, утечка данных restricted, недоступность production. - P2 — высокий: уязвимость уровня High, попытка взлома без успеха, недоступность critical функций. - P3 — средний: уязвимость уровня Medium, аномальная активность, сбои некритических функций. - P4 — низкий: уязвимости уровня Low, информационные события.

Процедура реагирования (для P1): 1. Обнаружение: автоматический алерт службе безопасности (≤ 15 минут). 2. Уведомление: руководству UNDP и заказчику (≤ 1 час). 3. Изоляция: немедленные действия по локализации (≤ 2 часов): блокировка скомпрометированных аккаунтов, отзыв сессий, изоляция затронутых сервисов. 4. Расследование: анализ причин, оценка ущерба (≤ 24 часа). 5. Уведомление субъектов ПДн при утечке: ≤ 72 часа после обнаружения. 6. Восстановление: возврат к нормальной работе. 7. Постмортем: документация инцидента, обновление мер защиты (≤ 7 дней). 8. Публичное уведомление (если применимо): через публичный портал и пресс-релиз.

Ю.7. Bug Bounty / Responsible Disclosure

Платформа поддерживает программу ответственного раскрытия уязвимостей: - Публичная страница на портале с инструкциями. - Email адрес security@… для отправки отчётов. - PGP-ключ для шифрования. - Регламент реагирования: подтверждение приёма в течение 48 часов, оценка в течение 5 рабочих дней. - Возможны денежные вознаграждения за серьёзные находки (детали — отдельной программой UNDP).

Ю.8. Регулярные проверки безопасности

SAST (Static Application Security Testing): каждый коммит в основную ветку.
SCA (Software Composition Analysis): ежедневное сканирование зависимостей.
DAST (Dynamic Application Security Testing): еженедельное сканирование staging.
Внутренний пентест: перед каждым мажор-релизом.
Внешний пентест: перед запуском в production и далее ежегодно.
Аудит конфигурации серверов и Kubernetes: ежеквартально.

Ю.9. Защита от типовых атак

OWASP Top 10: полное покрытие.
DDoS: WAF + rate limiting + Cloudflare-эквивалент (или внутренний DDoS protection).
CSRF: токены на всех state-changing операциях.
XSS: Content Security Policy, sanitization всех пользовательских входов.
SQL Injection: ORM с parameterized queries, code review.
SSRF: валидация всех URL, переданных пользователем, при работе с внешними ресурсами.
XXE: отключение DTD при парсинге XML.

Ю.10. Защита персональных данных

Все PII хранятся с пометкой класса (Restricted в большинстве случаев).
Hashing номеров телефонов с использованием криптографической соли.
Автоматическое обезличивание лиц на публикуемых фото (face detection + blurring).
Право пользователя на доступ к своим данным (через личный кабинет).
Право на удаление (с учётом юридических обязательств хранения).
Регламент реагирования на запросы субъектов ПДн (15 рабочих дней).
Уведомление об утечке (72 часа после обнаружения).
Назначение Data Protection Officer (DPO) разработчиком и заказчиком.

Приложение Я — Конструктор ролей, организаций и бизнес-процессов

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

Я.1. Назначение

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

Я.2. Настраиваемые участники и типы организаций

Минимальный справочник типов организаций должен включать: школа, районный отдел образования, региональный МДшО, центральный МДшО, UNDP, UNICEF, подрядчик, проектная организация, инженерная компания при хокимияте, сторонняя организация строительного контроля / внешний контролёр, ГАСН, КРУ, ACA / прокуратура / контрольные органы, CSAC / общественный совет, NGO Monitor, донор / HQ viewer, техоператор / Uzinfocom.
Для каждого типа организации настраиваются: область видимости данных, допустимые роли, право просмотра/создания/верификации/подписания, маршруты эскалаций, доступ к открытым и закрытым данным, ограничения по персональным данным.
Добавление нового участника должно выполняться через настройки суперадмина: тип организации, карточка организации, пользователи, роли, scope, связи с программой, журнал аудита.
Сторонняя организация строительного контроля может быть добавлена как подтип технического надзора: ей назначаются программы, регионы, школы или контракты, а также права на просмотр сроков, отставаний, доказательной базы, видеопотоков, SLA и создание замечаний/рисков без изменения контрактных и финансовых данных.

Я.3. Конфигурируемые роли и scope доступа

Ролевая модель должна поддерживать наследование и ограничение доступа по уровням: программа, республика, область, район, школа, контракт, пакет работ, обращение, гарантийный случай.
Каждая роль должна иметь настраиваемые разрешения по модулям M1-M20: просмотр, создание, редактирование, верификация, согласование, подписание, экспорт, администрирование, read-only investigation.
EXTERNAL_CONSTRUCTION_CONTROLLER должен иметь отдельный permission profile: read assigned scope, view schedule/SLA, view evidence/video, annotate, flag risk, export assigned reports; права verify/sign/approve выключены по умолчанию и могут быть включены только если это закреплено договором и маршрутом процесса.
Роли для ГАСН, КРУ, ACA / прокуратуры и иных контрольных органов должны иметь режим расследования / read-only по сигналам риска без права изменять операционные данные платформы.

Я.4. Конструктор бизнес-процессов

Сквозные бизнес-процессы должны храниться как версионируемые шаблоны: шаги, триггеры, ответственные роли, обязательные артефакты, чек-листы, SLA, блокировки, уведомления, уровни эскалации и условия перехода.
Суперадмин должен иметь возможность включать, отключать и менять маршруты согласования без изменения исходного кода, включая подключение технадзора, внешнего контролёра строительного контроля, инженерной компании при хокимияте, ГАСН, КРУ, CSAC / NGO Monitor или контрольных органов.
Изменения шаблонов бизнес-процессов должны версионироваться, логироваться в M18 и не должны ретроактивно менять уже завершённые акты, подписи и доказательства.

Я.5. Связь с макапом и UX

На макапе показываются ключевые личные кабинеты пилота, но не весь полный перечень потенциальных участников; полный перечень ролей и масштабируемая модель закрепляются настоящим приложением и Приложением М.
Интерфейс суперадмина должен предусматривать управление организациями, ролями, scope, программами, маршрутами бизнес-процессов, SLA и справочниками без привлечения разработчика.
Любая демонстрация роли в макапе должна быть связана с пунктом ТЗ или приложением, где описаны права, обязанности и ограничения этой роли.

Я.6. Критерии приёмки

В административном интерфейсе создан новый тип организации и новая роль без изменения кода и без релиза backend/frontend.
Новая роль получила ограниченный scope доступа и появилась в матрице M1/M14/M18 с журналированием всех действий.
Для пилотного бизнес-процесса изменён маршрут согласования с добавлением дополнительного участника проверки; изменение применилось только к новой версии процесса.
Контрольный орган получил read-only investigation-доступ к выбранному сигналу риска, доказательной базе, журналу аудита и связанным актам без права изменения операционных данных.

FIELD_INSPECTOR как базовый шаблон инспекторской роли

FIELD_INSPECTOR — универсальный шаблон инспекторской роли. Базовая роль контроля качества работ на стройплощадке. Назначается пользователю с настраиваемым scope (own / district / region / program / all), набором разрешённых действий (read / annotate / flag / verify / suspend), типом объектов (СМР / WASH / климат / финансы / антикоррупция), доступом к артефактам (видео M6, фото M9, акты M12, обращения M11, audit M18). Используется в пилоте для UNDP координаторов и нанятых НКО как контролёров работ. На масштабе клонируется через Прил. Я.3 в производные шаблоны под конкретные ведомства (см. ).

Карта производных шаблонов от FIELD_INSPECTOR

Платформа предоставляет PLATFORM_ADMIN типовые конфигурации производных инспекторских ролей:

1. GASN_INSPECTOR (стройнадзор) — scope: region; действия: read M6/M9/M12, suspend UC-A21, write inspection acts; объекты: СМР; маршруты: верификация безопасности перед каждым этапом.

2. KRU_AUDITOR (контрольно-ревизионное управление) — scope: all; действия: read M5/M7/M9/M12/M14/M18 full audit; объекты: финансы и контракты; маршруты: постаудит через 6 мес. после UC-A23.

3. ACA_OFFICER (антикоррупционное агентство) — scope: all; действия: read full evidence, M11 read corruption-flagged, M5 blacklist initiate; объекты: коррупционные сигналы; маршруты: расследование UC-A44.

4. PROCURATOR_OFFICER (прокуратура) — scope: all read-only; действия: read all, investigation mode; маршруты: запрос материалов по официальному обращению.

5. REGIONAL_ENGINEERING (инжкомпания при хокимияте) — scope: region; действия: M6 view, M9 annotate/flag, M12 verify; объекты: СМР; маршруты: верификация этапа после UC-A17.

6. CSAC_OBSERVER (Civil Society Advisory Committee) — scope: program (assigned contracts); действия: read M9/M11/M16 reports; маршруты: общественный мониторинг.

7. NGO_MONITOR (НКО-наблюдатель) — scope: assigned schools; действия: read M9/M11, flag issues, comment; маршруты: общественный наблюдатель региона.

8. EXTERNAL_CONSTRUCTION_CONTROLLER (внешний контролёр работ, нанимаемый отдельно) — scope: assigned contracts; действия: read evidence, video, SLA; flag risks; не verify/sign/approve по умолчанию (см. также Прил. З.8).

Каждый производный шаблон создаётся PLATFORM_ADMIN без релиза кода. Журнал всех изменений конфигурации — в M18.

Гигиенические материалы как рамочный контракт

Требует согласования с UNICEF. Пакет «Поставка гигиенических материалов» оформляется как рамочный контракт с подрядчиком на 5 лет (синхронно с гарантией M13). Регулярные поставки: квартально для расходников (мыло, бумага, перчатки уборщика, гигиенические средства MHM), полугодово для оборудования (диспенсеры, контейнеры). Каждая поставка → акт получения школой + фото → UC-A24 платёж. Невыполнение поставки в SLA → уведомление UNICEF_OFFICER + UC-A21 приостановка следующего платежа + риск UC-A13 blacklist при систематических нарушениях.

Дополнительные ролевые сценарии и acceptance criteria для системных и координационных ролей

Раздел добавлен в QA-проходе 25.06.2026 в ответ на замечание о слабом покрытии системных и центральных координационных ролей. Раздел дополняет Приложения М (роли) и Я (конструктор) краткими user journeys и acceptance criteria. Все wireframes покрываются конфигурируемым админ/аналитическим интерфейсом (Прил. Я.3) — отдельные страницы кабинетов не обязательны.

UNDP_INTEGRITY — расследование коррупционных сигналов

User journey: (1) intake — поступление сигнала через M11 категории «коррупционная жалоба» или через ACA referral; (2) формирование evidence pack — автоматическая выборка M6/M9/M12/M18 по школе, контракту, подрядчику, периоду; (3) conflict-of-interest review — сравнение UBO M1 / Integrity Pact M16 / контрактной истории M5; (4) recommendation — формирование рекомендации (blacklist UC-A13, referral ACA, no action) с обоснованием; (5) escalation — передача в ACA_OFFICER или CSAC_OBSERVER через M17 с подписью и хранением в M18.

Acceptance criteria: (а) кнопка «Создать investigation case» доступна из M11/M14 для роли UNDP_INTEGRITY; (б) evidence pack включает не менее 9 типов артефактов (контракт, UBO, IP, evidence M9, видео M6, акты M12, обращения M11, audit M18, выплаты M7) с timestamp экспорта; (в) recommendation требует подпись (электронная подпись M16) и автоматически направляется адресату; (г) все действия UNDP_INTEGRITY фиксируются в M18 с пометкой класса чувствительности «Investigation».

UNDP_FINANCE — финансовый дашборд и блокировки выплат

User journey: ежедневная сводка финансовых операций программы — pending payments (UC-A24), retention возвраты (UC-A25), failed UN Quantum sync (sync_status=error), blocked payments из-за отсутствия публикации существенного доп. соглашения, audit trail последних 30 дней с фильтром по школе/подрядчику/контракту.

Acceptance criteria: (а) дашборд UNDP_FINANCE содержит 6 виджетов — pending, retention, failed sync, blocked, recent, monthly burn rate; (б) при клике на «blocked payment» открывается карточка с причиной блокировки (ссылка на UC-A12 без публикации, отсутствующее evidence, неподписанный акт); (в) экспорт сводки в XLSX и PDF для отчёта донору; (г) запись в M18 при любом действии «принять/отклонить выплату».

DISTRICT_EDU_HEAD — координация района

User journey: районный отдел образования получает дайджест по своим школам — статус активных контрактов M5/M8, открытые обращения M11 в L1 SLA, инциденты UC-A20 за период, эскалации L1→L2, визиты на стройплощадку. Право подписи на актах приёмки этапа M12 в районном уровне (вторая подпись после школьного директора).

Acceptance criteria: (а) дашборд района показывает агрегацию по всем школам района (фильтр scope=district); (б) кнопка «Эскалировать в МДшО регион» (L1→L2) с обоснованием; (в) подписи DISTRICT_EDU_HEAD на актах M12 валидируются как обязательная вторая подпись для контрактов > порога T_district; (г) журнал действий — M18.

MOPSE_STRATEGY / MOPSE_PROGRAM / MOPSE_COMPLIANCE — республиканский уровень

MOPSE_STRATEGY (центральный отдел стратегии): просмотр сводных KPI по программе (M14), утверждение когорты года (UC-A07), согласование критериев скоринга школ (веса), просмотр публичного портала M19. Acceptance: дашборд показывает 8 республиканских KPI с фильтром по областям; при изменении весов критериев M3 → автоматическое уведомление M17 и публикация в M19.

MOPSE_PROGRAM (управление программами): просмотр и согласование M4 планирования, M7 контрактов, M12 верификаций, доступ к Прил. Г интеграциям School Passport (read INN). Acceptance: возможность запросить обновление паспорта школы из Замонавий мактаб по INN с фиксацией в M18.

MOPSE_COMPLIANCE (комплаенс/governance): просмотр compliance-дашборда, Integrity Pact M16, audit log M18, участие в handover/governance после go-live, отчётность по республике для Минцифры и Минстроя. Acceptance: (а) read M16 full; (б) read M18 без редактирования с фильтром по чувствительности; (в) ежеквартальный compliance-отчёт через M20 с автоматической рассылкой регулятору; (г) запись в Прил. Х (change management) при любом изменении нормативного контура.

PLATFORM_ADMIN — конструктор ролей и admin acceptance

User journey: создать роль из FIELD_INSPECTOR (см. Прил. Я.3) → задать scope → задать allowed actions → задать маршрут согласования → опубликовать → откатить/версировать шаблон при необходимости.

Admin acceptance tests: (а) PLATFORM_ADMIN создаёт новую роль за < 5 минут без релиза кода (см. Прил. Я.6.1); (б) изменение scope существующей роли применяется ко всем активным пользователям с этой ролью в течение 1 минуты; (в) изменение маршрута согласования бизнес-процесса (например, требование дополнительной подписи DISTRICT_EDU_HEAD) применяется только к новым экземплярам процесса, существующие остаются на старом маршруте до завершения; (г) операция «откатить шаблон роли» возвращает roles_template_version к указанной версии с журналом в M18 и уведомлением всех затронутых ролей; (д) экспорт audit log PLATFORM_ADMIN в XLSX с фильтром по периоду; (е) валидация конструктора: запрет на удаление роли, имеющей активных пользователей или активные подписи в M12.

UNICEF — open dependency и статусы требований по WASH/Climate-блоку

Раздел добавлен для явной фиксации зависимости 12 UNICEF-ADD (U01-U10, U-CS, U-KM) от официальных требований UNICEF. До получения этих требований реализация подрядчиком ведётся как configurable templates / checklists, финальные числовые нормы и критерии приёмки фиксируются совместным протоколом UNDP–UNICEF.

Документы, запрашиваемые у UNICEF

Перечень официальных документов, которые подрядчик и UNDP запрашивают у UNICEF до фазы 3 (UNICEF WASH modules):

1. Sphere Handbook 2018 + WHO–UNICEF JMP Service Ladders for WASH in Schools.

2. UNICEF MHM Operational Guidance for Schools (2019) + национальные адаптации.

3. UNICEF Three Star Approach: WASH in Schools (WinS).

4. UNICEF Behaviour Change Communication (BCC) Toolkit for Schools.

5. UNICEF Child Safeguarding Policy + UNICEF Programme Guidance on Digital Media with Children.

6. UNICEF Climate Resilient WASH Technical Guidance.

7. UNICEF Framework Agreement template для рамочных контрактов на расходники.

8. UNICEF JMP report template + JMP indicator catalogue (XLSX).

Статусы ADD U-блока

На дату 25.06.2026 все 12 ADD имеют статус «Draft pending UNICEF validation». После получения комментариев UNICEF статус каждого ADD меняется на один из: «Accepted as-is» (формулировка принята без изменений), «Changed» (формулировка скорректирована — изменения фиксируются в Прил. Х change management), «Rejected» (требование снимается из ТЗ с обоснованием). Журнал изменений статусов ведётся в M18 и публикуется в M19.

Acceptance criterion на период до согласования

До снятия пометки «Требует согласования с UNICEF» подрядчик реализует требования U-блока как configurable templates / checklists, где конкретные числовые нормы (например, ratio туалетов девочки ≥1:25, частота continuous monitoring, формат BCC-учёта) задаются через справочники Прил. Я.4 и могут быть изменены PLATFORM_ADMIN после согласования UNICEF без релиза кода. Подрядчик не может приступить к сдаче фазы 3 без подписи UNICEF_OFFICER на acceptance-протоколе по каждому из 12 ADD.

Child safeguarding — модель хранения медиа с детьми

Уточнение к требованию child safeguarding (см. M6/M9) в связи с конфликтом «90 дней оригинал» vs «5-летняя доказательная база». Модель «два контура хранения»:

Контур 1 — публичная копия. Лица несовершеннолетних автоматически и необратимо размыты (model-driven blur, уверенность ≥0.9). Хранение — 5 лет в M9/M19 согласно общему сроку доказательной базы. Доступ — все роли с правом read M9.

Контур 2 — оригинал с лицами. Хранение — 90 дней в защищённом сегменте M9 с меткой чувствительности класс 4 «Чувствительные ПДн / дети». Доступ — только UNICEF_OFFICER + SCHOOL_DIRECTOR + UNDP_INTEGRITY с обязательным обоснованием каждого просмотра в M18. По истечении 90 дней оригиналы автоматически удаляются; в M18 остаётся запись о существовании оригинала, его метаданных и пользователях, просмотревших его в течение 90-дневного окна.

Правовое основание удержания оригинала на 90 дней — расследование жалоб M11 и инцидентов UC-A20, связанных со школьниками. Продление срока хранения возможно только по запросу ACA_OFFICER или PROCURATOR_OFFICER с обязательной регистрацией в M18 и публикацией факта (без содержания) в M19.

История изменений документа

Версия 2.7.3 от 27.06.2026 — финальная вычистка документа: заполнен глоссарий, уточнены ссылки на системные роли, унифицированы названия партнёрских организаций и информационных систем, пронумерованы дополнительные функциональные требования.

Версия 2.7 от 25.06.2026 — финальная редакция технического задания с учётом замечаний заказчика и партнёров. Включает целевые дополнения по итогам проработки кабинетов пользователей: директор школы, подрядчик, региональное управление образования, закупки UNDP, координация программы UNDP, UNICEF (с пометкой о необходимости согласования), универсальная роль инспектора с производными шаблонами для отраслевых надзорных органов.

Версия 2.6 от 20.06.2026 — аудит и фиксы матрицы доступа, глоссарий, оглавление, переход к финальной структуре по стандарту O‘z DSt 1987:2018.