Компания утверждает инвестиционный проект, выделяет средства и выполняет работы. Чтобы оценить результат, нужно проследить, во что превратились эти инвестиции: какие объекты построены или модернизированы, когда они введены и переданы в эксплуатацию. Статуса «проект завершён» для этого недостаточно.
В телекоммуникационной компании речь идёт о тысячах сетевых площадок с оборудованием, обеспечивающим сотовую связь и доступ в интернет, а также о линиях связи и других инфраструктурных объектах. Один проект может охватывать десятки площадок. При этом каждая площадка за время эксплуатации может участвовать в нескольких проектах: строительстве, расширении ёмкости, замене оборудования.
Для меня прослеживаемость начинается с двух задач: установить, какие объекты созданы или изменены проектом, и по выбранному объекту восстановить последовательность связанных с ним проектов. Эти сведения должны сохраняться после закрытия работ, замены оборудования и смены команды.
История объекта вместо одного кода
Площадка, сетевой элемент и участок волоконно-оптической линии связи существуют дольше отдельного проекта. За это время могут измениться их характеристики, состав оборудования, назначение и статус. Привязка только к последнему проекту оставляет за пределами учёта значительную часть этой истории.
В подобных случаях я использую модель, в которой связь проекта с объектом хранится отдельно. В ней фиксируются идентификаторы обеих сущностей и вид работ: создание, модернизация, замена, демонтаж. При необходимости добавляются этап и период действия связи.
Получаются отношения «многие ко многим»: проект затрагивает несколько объектов, объект участвует в нескольких проектах. Такая модель сохраняет историю работ. Для определения стоимости созданных или модернизированных объектов её дополняют правилами распределения инвестиций.
Важно и то, до какого уровня подтверждена связь. Проект может относиться к площадке в целом или к конкретному установленному на ней оборудованию. Из записи о площадке нельзя автоматически заключить, что всё её оборудование создано этим проектом.
Слишком подробная модель тоже имеет цену: связи придётся заполнять и поддерживать. Поэтому детализацию выбирают под задачу контроля. Если результат проекта — замена определённых сетевых элементов, одной ссылки на площадку недостаточно. Для предварительного планирования её может хватить.
Связь с проектами дополняется географией, историей состояний и документами. Вместе эти данные позволяют восстановить, где проводились работы, что изменилось и чем подтверждён результат.
Инфраструктурный объект и его проектная история
Связь проектного управления с техническим реестром
В
Для прослеживаемости инвестиций главной была интеграция с NRI (Network Resource Inventory, система учёта сетевых ресурсов). Единая NRI создавалась взамен восьми филиальных решений учёта оборудования.
Я разработал логику двусторонней связи инвестиционных проектов с площадками, сетевыми элементами и волоконно-оптическими линиями связи, а также обмен датами ввода, постановки на мониторинг и текущими статусами. До реализации этой связи сведения о проектах и физических объектах находились в разных системах и в ряде случаев не были связаны между собой.
После внедрения по проекту можно было определить, какие сетевые объекты созданы, когда они фактически введены и поставлены на мониторинг. Эти данные позволяли контролировать реализацию инвестиций и анализировать технический результат.
Через МегаГИС проект связывался с плановыми и фактическими адресами объектов, через SAP Extended ECM — с документацией. Географическое положение не заменяло запись технического реестра, а наличие документа не подменяло эксплуатационный статус.
Объект в плане и объект в эксплуатации
Будущая площадка или участок линии появляются в проекте задолго до строительства. В техническом реестре соответствующая запись может быть создана позднее. К этому моменту уже накоплены расчёты, согласования и документы, которые потребуется связать с фактическим результатом.
Я разделяю в модели планируемое и реализованное состояние. Плановая запись может иметь предварительный идентификатор. При переходе к фактическому объекту сохраняется соответствие: через изменение состояния одной записи или связь отдельных сущностей. Выбор зависит от устройства технического учёта.
Историю нужно сохранять и тогда, когда проектное решение пересматривают. Планировали один участок линии, построили два; изменили площадку; часть оборудования исключили. Перезаписывание первоначального перечня оставит конечный результат, но скроет причины расхождения с планом.
При разделении объекта важно явно связать исходную запись с получившимися объектами. При замене оборудования — сохранить сведения о прежнем и новом элементах. Иначе запрос по старому идентификатору перестанет давать результат, хотя именно он указан в проектной документации.
Отмена планового объекта и демонтаж существующего требуют разных состояний. В первом случае физического результата не было, во втором объект существовал и мог эксплуатироваться. Для анализа исполнения это существенная разница.
Завершение проекта не равно вводу всех объектов
Руководитель проекта подтверждает выполнение работ, техническая служба принимает объект, эксплуатация подключает его к мониторингу. Финансовое закрытие имеет собственные основания. Между событиями могут проходить дни и недели.
Если считать их равнозначными, отчёт покажет готовность, которую техническая служба ещё не подтвердила. Наличие записи в мониторинге тоже не означает завершения приёмки и передачи документации.
Возможна и обратная ситуация: линия вводится участками, оборудование запускается на нескольких площадках последовательно, а проект продолжается. Одного общего статуса для описания результата недостаточно.
При проектировании я закрепляю источник за каждым существенным событием: кто подтверждает приёмку, кто фиксирует ввод, откуда поступает дата постановки на мониторинг. Затем согласовываю, какие события влияют на состояние проекта, а какие отображаются в его карточке как дополнительные сведения.
У события есть собственная дата и дата регистрации в системе. Объект могли принять в пятницу, а запись внести в понедельник. Использование даты загрузки вместо даты приёмки исказит показатели задержек.
Текущий статус тоже не позволяет восстановить прошлое. Пометка «выведен из эксплуатации» не отменяет того, что объект был введён по этому проекту и несколько лет работал. Для анализа нужны сведения на выбранную дату.
География и документы как подтверждение
Адрес и координаты помогают проверить связь, но редко подходят на роль основного идентификатора. На одной площадке размещаются разные объекты, адреса меняются, протяжённая линия не описывается одной точкой.
На карте можно сопоставить плановое и фактическое размещение, увидеть участки трассы, найти объект вне ожидаемой территории. Совпадение координат служит основанием для проверки принадлежности проекту. Автоматическое объединение записей по этому признаку создаст ошибочные связи.
С документацией возникает другая трудность. Ссылка на общую папку проекта мало помогает, если в ней находятся несколько редакций схем и акты по разным этапам. Для значимых документов полезно сохранять вид, редакцию и привязку к охваченным объектам.
Акт может подтверждать приёмку одного участка линии. Приписав его всей линии, система создаст видимость документального подтверждения для работ, которые ещё не приняты.
Права доступа при интеграции сохраняются. В некоторых случаях пользователю достаточно видеть, что подтверждающий документ существует и относится к объекту. Доступ к содержимому определяется отдельно. Даже сведения о наличии документа могут быть ограничены, если этого требуют правила компании.
Где искать разрывы
Исправный обмен не гарантирует, что все объекты связаны с проектами. Для обнаружения пропусков я включаю проверки конкретных исключений:
- проект готов к закрытию, но часть ожидаемых объектов не сопоставлена с техническим реестром;
- объект связан с проектом, но вид выполненных работ не указан;
- связь установлена только с площадкой, хотя результат требует подтверждения до оборудования;
- дата ввода есть, а сведения о постановке на мониторинг отсутствуют дольше допустимого срока.
Последний случай не всегда означает ошибку. Для отдельных ресурсов мониторинг может не требоваться, между вводом и подключением может быть предусмотрена задержка. Проверка учитывает тип объекта и регламент. Иначе отчёт заполнится формальными нарушениями, которые перестанут разбирать.
Каждое исключение направляется ответственному. Техническая команда исправляет сбой обмена, владелец реестра — ошибочную карточку, участник проекта — неподтверждённый перечень объектов. Без распределения ответственности список расхождений превращается в очередную выгрузку для переписки.
Полноту связей я оцениваю по проектам и этапам, для которых определён ожидаемый состав объектов. На ранней стадии он ещё может уточняться. Доля проектов хотя бы с одной ссылкой малоинформативна: из десяти результатов могли связать только один. Полезнее проверять весь ожидаемый перечень, число неразобранных исключений и сроки их устранения.
Что можно узнать о результате инвестиций
Связанные данные позволяют установить, что создано, где находится объект, когда он введён и какие работы с ним проводились. На этой основе анализируют сроки, состав результата и передачу в эксплуатацию.
Но наличие введённого объекта ещё не подтверждает экономический эффект инвестиции. Для оценки прироста ёмкости или изменения покрытия потребуются технические показатели до и после реализации проекта. Для оценки выручки — дополнительные данные и методика, учитывающая другие факторы. Сама связь проекта с ресурсом не доказывает причинную зависимость.
После закрытия проекта его история продолжает использоваться при модернизации, разборе инцидентов и оценке инвестиций. У площадки могут смениться оборудование, ответственный и система учёта. При этом должны сохраняться сведения о том, какой проект создал объект, какие работы изменили его и какими событиями подтверждена передача в эксплуатацию.
