Система мониторинга строительных проектов: руководство 2026

Три подземных резервуара в одном городе. Два небольших готовы. Большой, в котором помещается основная часть воды, обещанной городу, выполнен на 74 %. Усредните три значения — и город отчитается о готовности 91,33 %. Взвесьте каждый резервуар по ёмкости, которую он даёт, — и честная цифра составит 75,70 %.

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

Это руководство для тех, кто составляет требования к таким системам, закупает или наследует их: директоров проектов в PMU или PIU и консультантов, которые пишут для них техническое задание. Мы пишем с позиции оператора. С июля 2026 года NexGenix перенесла, переработала и эксплуатирует PDP Executive Monitoring Dashboard — систему, которая отслеживает работы по канализации, водоотводу и насосным станциям Программы развития Пенджаба (Punjab Development Program) в 52 городах. Пример с резервуарами взят из методической документации самой системы.

Почему отчётность в таблицах и WhatsApp ломается в масштабе программы

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

• Фото ничего не доказывает. Пересланное изображение не говорит ничего достоверного о том, где и когда оно снято. Один и тот же недостроенный канал может всплывать три недели подряд.
• Проценты вводят, а не измеряют. «Канал — 60 %» — это мнение. Шестьдесят процентов от какой протяжённости, кто измерял и в какой день?
• Свод усредняет несопоставимое. См. резервуары.
• История исчезает. Рабочая книга показывает цифру этой недели и редко — что на прошлой неделе она была выше или кто её изменил.
• Отчёт опаздывает по определению. Два дня на консолидацию означают доклад о программе в том состоянии, в каком она была два дня назад.

Провинциальные платформы эту потребность не отменяют. В Пенджабе уже работает система Smart Monitoring of Development Projects, через которую ведомства с 2016 года подают ежемесячные отчёты о ходе работ, а также GIS-платформа Monitoring Observatory for Development Projects. Они охватывают сотни проектов сразу. Собственная система программы работает уровнем ниже: по каждому объекту, каждый день и с приложенными доказательствами.

Что должна уметь система мониторинга строительных проектов

Технические задания требуют удивительно похожих вещей, кто бы ни финансировал работы: веб- и мобильную систему мониторинга и информации, МИС с GIS, приложение для Android, передающее данные на центральную платформу, панели, руководства и обучение. Банк развития KfW даже опубликовал руководство по удалённому управлению, мониторингу и верификации. Названия важны меньше, чем поведение системы. Вот десять возможностей, на которых мы бы настаивали.

1. Полевые доказательства, защищённые от подделки

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

Одна оговорка: под плитой перекрытия или в узком переулке телефон не всегда получает GPS-координаты, поэтому фиксируйте «координат нет», а не выдумывайте их.

2. Офлайн-приложение, которое не отправит данные дважды

На объектах пропадает связь. Приложение, которому нужно постоянное подключение, приучает сотрудников заполнять записи вечером по памяти. Приложение PDP Field Progress ставит отчёты и фото в очередь на телефоне и синхронизирует их позже, а у каждой записи есть собственный идентификатор, поэтому повторная отправка никогда не учтёт один и тот же прогресс дважды.

Где можно, измеряйте, а не спрашивайте. Прогресс по канализации в приложении PDP определяется по линии, которую сотрудник рисует поверх проектной трассы с помощью GPS телефона. Никто не вводит процент.

3. Взвешенный прогресс вместо усреднённых процентов

Вернёмся к резервуарам, шаг за шагом:

1. Каждый объект получает значение в собственных единицах: выполнено к предусмотренному. Резервуар A вмещает 1 000 000 галлонов и выполнен на 74 %. Резервуары B (40 000 галлонов) и C (30 000 галлонов) завершены.
2. Простое среднее: (74 + 100 + 100) ÷ 3 = 91,33 %.
3. С весом по ёмкости: 1 000 000 × 74 + 40 000 × 100 + 30 000 × 100 = 81 000 000.
4. Делим на общую ёмкость 1 070 000 галлонов и получаем 75,70 %.

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

// Три подземных резервуара в одном городе (ёмкость в галлонах, прогресс в %)
const tanks = [
  { capacity: 1_000_000, progress: 74 },
  { capacity: 40_000, progress: 100 },
  { capacity: 30_000, progress: 100 },
];

const naive = tanks.reduce((sum, t) => sum + t.progress, 0) / tanks.length;

const weighted =
  tanks.reduce((sum, t) => sum + t.capacity * t.progress, 0) /
  tanks.reduce((sum, t) => sum + t.capacity, 0);

console.log(naive.toFixed(2), weighted.toFixed(2)); // "91.33" "75.70"

Полный свод в PDP состоит из четырёх ступеней. Объекты сводятся в компонент внутри города с весом по тому, что даёт каждый из них: галлоны для резервуаров, объём приёмного резервуара для насосных станций, погонные футы для каналов и канализации. Компоненты сводятся в город с весами, которые задаёт PMU и которые в сумме должны составлять 100, а города — в программу по утверждённой стоимости. Значения рассчитываются по запросу, а не хранятся, поэтому панель, PDF и поток данных никогда не расходятся.

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

Если поставщик не может показать формулу, стоящую за главным процентом, этот процент — просто украшение.

4. Отслеживание прогресса по S-кривой: план и факт

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

Фактической линии нужна записанная история. PDP каждую ночь сохраняет снимок всех значений, и S-кривая, и все показатели «за эту неделю» читаются из этих снимков.

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

5. GIS-карта, устроенная как административное деление

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

Карты быстро тяжелеют. Одна из первых задач в PDP Dashboard сократила объём первой загрузки карты с 37 МБ до 9 МБ, а в сети 4G от этого зависит, откроет ли её должностное лицо вообще. Спрашивайте поставщиков, сколько весит их карта.

6. Экран активности в реальном времени для офиса PMU

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

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

7. Отчёты в один клик в привычном для должностных лиц формате

У утреннего доклада уже есть своя форма и порядок страниц. Если система это игнорирует, её цифры перепечатывают в старый шаблон. PDP формирует ежедневную сводку о ходе полевых работ в один клик в виде PDF, свёрстанного как собственные слайды должностных лиц, а также отчёты в PDF и Excel по городам, типам объектов и соблюдению требований охраны труда.

8. Ролевой доступ, который ограничивает данные, а не меню

В PDP шесть ролей — от полевых сотрудников, которые видят только закреплённые за ними города, до руководителей, которые видят всю программу. Данные фильтрует сервер. Скрытый пункт меню — это не управление доступом.

9. Аудиторский след, который можно передать аудитору

В Dashboard записи о прогрессе только добавляются, а учётная запись с историей отключается, но никогда не удаляется. PMIS — система управления контрактами и платежами той же программы — ведёт четырёхслойный аудиторский след: решения, каждый запрос, состояние каждой строки «до и после» изменения и ежесуточную хеш-цепочку SHA-256, которая запечатывает журналы, так что любая последующая правка разрывает цепочку.

10. Интеграция с контрактами и платежами

Мониторинг отвечает на вопрос, сколько построено. Управление контрактами и платежами — на вопрос, сколько причитается, за вычетом каких удержаний и кем это утверждено. В PDP это разные системы. PMIS ведёт ведомость объёмов работ (BOQ) каждого договора на четыре уровня в глубину, рассчитывает на сервере девять видов удержаний и проводит каждый промежуточный платёжный сертификат (IPC; по смыслу — аналог актов КС-2/КС-3) по маршруту согласования из 11 этапов плюс один этап после утверждения. С 13 октября 2026 года у неё есть действующая связь с системой управления финансами провинции, а с 21 октября утверждённые счета передаются туда автоматически. Проведите эту границу в техническом задании с первого дня.

Архитектура и модель данных: главное

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

Выбирайте скучный стек намеренно. PDP Dashboard работает на Node.js 20, Express и MySQL 8.0: около 128 000 строк кода, примерно 210 конечных точек API и около 52 таблиц. Кто-то будет сопровождать систему ещё годы после того, как исходная команда уйдёт, и распространённые технологии расширяют круг таких специалистов. MySQL уверенно справляется с таким объёмом, если индексы продуманы, — в этом мы убедились, когда оптимизировали промышленную базу MySQL из 287 таблиц. А если полевое приложение распространяется не через магазин приложений, добавьте на сервере проверку минимальной версии.

Как принять действующую государственную систему, не останавливая отчётность

Большинство государственных систем мониторинга наследуют, а не создают заново. Именно в таком положении PDP была в июле 2026 года. Исходную платформу разработала компания Technology Hive; NexGenix приняла её, перенесла на собственный сервер правительства Пенджаба и с тех пор перерабатывает и эксплуатирует её. Переключение 24 июля 2026 года стоило одного дня сниженной отчётности. Вот порядок, которому мы последовали бы снова:

1. Аудит до любых изменений. Изучите код, схему и то, что реально работает, и запишите это.
2. Переносите полную копию. Приложение, дамп базы данных и все полевые фото, которые обычно составляют самый большой объём: в случае PDP на момент передачи это было 13 595 файлов.
3. Один источник записи в каждый момент. Зафиксируйте точный момент, когда старый сервер перестаёт принимать полевые данные, а новый начинает.
4. Сохраните работу полевого приложения. До переключения выпустите обновление, которое знает новый адрес, затем принудительно обновите старые версии.
5. Проверяйте подсчётом. Записи, фото и итоги по городам — до и после.
6. Затем улучшайте систему небольшими релизами, каждый — с предварительной резервной копией и путём отката; на этой дисциплине построен наш четырёхэтапный процесс разработки ПО на заказ.

Чек-лист для закупки: что спросить у поставщика системы мониторинга

Проводите эти проверки на демонстрации, на ваших данных и в присутствии реальных пользователей.

1. «Покажите формулу, стоящую за главным процентом». Ожидайте веса, единицы измерения и расчётный пример по одному из ваших городов.
2. «Включите авиарежим, отправьте прогресс и снова подключитесь». Отчёт должен встать в очередь, синхронизироваться один раз и прийти с отметкой сервера.
3. «Что помешает выдать фото прошлого месяца за сегодняшнее?» Отметка на стороне сервера, а не метаданные телефона.
4. «Войдите как полевой сотрудник». Только закреплённые объекты, и это обеспечивает сервер.
5. «Уменьшите прогресс по объекту». Отказ ниже подтверждённого значения — или запись в журнал: кто и почему.
6. «Откуда берётся плановая линия S-кривой?» Из утверждённого графика или из явно обозначенной модели.
7. «Сформируйте доклад за прошлую неделю в нашем формате». Если для этого нужен разработчик, в понедельник этого не случится.
8. «Может ли система работать на нашем собственном сервере?» Спросите, что ей нужно от сети.
9. «Что мы получим при передаче?» Исходный код, документацию по схеме, руководство пользователя, шаги развёртывания и обучение — и всё это прописано в договоре.
10. «Как вы выпускаете изменения в работающую систему?» Резервные копии, путь отката и журнал изменений.

Тревожные сигналы в системе мониторинга строительных проектов

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

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

PDP Пенджаб: мониторинг 52 городов

Программа развития Пенджаба (Punjab Development Program, PDP) строит канализацию, ливневый водоотвод и сооружения отведения стоков в 52 городах 25 округов Пенджаба, где живёт около 7 млн человек. По состоянию на ноябрь 2026 года она включает 394 контрактных пакета с утверждённой стоимостью программы около 308 млрд PKR. Её Отдел управления программой (Program Management Unit, PMU), созданный Департаментом местного самоуправления и развития сообществ (Local Government & Community Development, LG&CD) правительства Пенджаба, работает с двумя системами:

• PDP Executive Monitoring Dashboard (веб-платформа и полевое приложение для Android) охватывает физический прогресс, доказательства, карты и отчёты. По состоянию на ноябрь 2026 года в ней около 33 000 фото с объектов (большинство — с геометками), шесть ролей и одиннадцать модулей на 27 веб-страницах; полевое приложение — версии 2.9.0.
• PMIS — система управления проектами, контрактами и платежами (Project/Contract & Payment Management System) — ведёт BOQ, промежуточные платёжные сертификаты, удержания и связь с системой управления финансами. В ней более 70 таблиц и более 45 выпущенных релизов, а маршруты согласования настраиваются на экране с 24 октября 2026 года.

Исходную платформу обеих систем разработала компания Technology Hive. Обе были перенесены на собственный сервер правительства Пенджаба, и с июля 2026 года их перерабатывает и эксплуатирует NexGenix.

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

В кейсе PDP Executive Monitoring Dashboard — экраны и хронология. Парный кейс PMIS — системы управления контрактами и оплатой по IPC описывает маршрут согласования и связь с финансовой системой. Планируете что-то похожее? На странице разработки ПО для госсектора рассказано, как мы работаем с PMU.

Часто задаваемые вопросы

Что такое система мониторинга строительных проектов?

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

Чем мониторинг отличается от оценки в системе M&E?

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

Как фото с геометками подтверждают прогресс на государственных объектах?

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

Что такое S-кривая в мониторинге проектов?

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

Может ли система мониторинга проектов работать на собственном сервере государственного органа?

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

Чем система мониторинга отличается от системы управления контрактами и платежами?

Система мониторинга измеряет, сколько построено. Система управления контрактами и платежами, которую часто называют PMIS, ведёт BOQ, промежуточные платёжные сертификаты, удержания и согласования до того, как деньги будут перечислены. Крупным программам нужны обе.

Начинайте с доказательств, а не с панели

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

---

Рецензировано инженерной командой NexGenix. Прочтите наши редакционные принципы, чтобы узнать, как мы проверяем источники, раскрываем AI-помощь и исправляем ошибки.