В государственных ИТ-проектах произошла тихая, но очень важная перемена. Она почти не обсуждается, хотя именно она в ближайшие годы будет определять, как оценивают исполнение контрактов, кто несет ответственность за ошибки и почему всё чаще предметом споров становится не программный код, а документация.
Еще несколько лет назад многие вопросы при исполнении государственных контрактов решались в рабочем порядке. Если возникали замечания, стороны обменивались письмами, уточняли требования, оформляли дополнительные соглашения, согласовывали спорные моменты. Формальная документация существовала, но далеко не всегда именно она становилась главным доказательством исполнения обязательств.
Сегодня ситуация принципиально изменилась.
С переходом к электронному исполнению контрактов каждый этап исполнения фиксируется в Единой информационной системе. Документы о приемке, мотивированные отказы, исправления, сведения о ходе исполнения формируют единый цифровой след проекта, который сохраняется на протяжении всего жизненного цикла контракта. Именно эти сведения становятся основным объектом последующих проверок.
Если раньше основным вопросом было: «Работы выполнены или нет?», то сегодня логика контроля значительно шире.
Контролирующие органы анализируют не только конечный результат, но и всю цепочку исполнения контракта:
Фактически документация перестала быть приложением к проекту.
Она стала его доказательной базой.
Именно по ней спустя месяцы или годы будут оценивать, действительно ли контракт исполнен надлежащим образом.
Еще одна тенденция, которая пока редко обсуждается публично, — стремительное расширение возможностей автоматизированного анализа государственных закупок.
Практически вся информация о закупках, исполнении контрактов и приемке уже существует в цифровом виде. Это означает, что для выявления типовых нарушений больше не требуется вручную анализировать тысячи страниц документов.
Цифровой след позволяет значительно быстрее находить противоречия между документами, несоответствие этапов исполнения, нарушения сроков, отсутствие обязательных документов или расхождения между условиями контракта и фактическими результатами. В самих государственных организациях и контрольной практике всё шире используются инструменты анализа больших массивов данных, в том числе с применением технологий искусственного интеллекта.
Это означает, что многие нарушения, которые раньше могли остаться незамеченными, становятся значительно более заметными.
Можно предположить, что основные риски связаны именно с исполнением контракта.
Однако практика показывает обратное.
Во многих случаях предпосылки будущих проблем закладываются значительно раньше — еще на этапе подготовки технического задания.
Чтобы проверить эту гипотезу, мы проанализировали более двадцати технических заданий на создание и развитие государственных информационных систем федерального и регионального уровня, размещенных в ЕИС. Каждый документ оценивался по единому чек-листу, включающему более 200 контрольных точек на соответствие требованиям законодательства, ГОСТов и действующих нормативных документов.
Результаты оказались неожиданными.
Среднее количество замечаний составило от 43 до 76 на один документ.
Более 80 % технических заданий получили оценку «критические нарушения».
Речь идет не о единичных ошибках отдельных заказчиков.
Выявленные проблемы повторяются независимо от региона, отрасли и стоимости проекта.
Исследование показало устойчивые закономерности.
Во-первых, практически во всех технических заданиях отсутствует корректное описание жизненного цикла государственной информационной системы. Вместо отдельных стадий проектирования, разработки, испытаний, опытной эксплуатации и ввода в промышленную эксплуатацию нередко указывается один общий этап выполнения работ. Иногда опытная эксплуатация занимает всего один календарный день, а пусконаладочные работы отсутствуют вовсе.
Во-вторых, ссылки на ГОСТы далеко не всегда означают соблюдение их требований. Во многих документах отсутствуют обязательные разделы, не определены критерии приемки, отсутствуют измеримые показатели достижения целей, а порядок контроля заменяется общими ссылками на законодательство.
В-третьих, требования по импортозамещению зачастую носят декларативный характер. Формально необходимые нормативные документы упоминаются, однако конкретные требования к программному стеку, отечественным аналогам и архитектурным решениям в тексте технического задания отсутствуют либо противоречат самим себе.
В-четвертых, в значительной части документов не определен оператор информационной системы, хотя именно он несет ключевую ответственность за функционирование системы и выполнение требований законодательства.
Наконец, во многих случаях показатели надежности и SLA сформулированы настолько неопределенно, что не позволяют объективно подтвердить исполнение обязательств при приемке системы.
Наиболее интересный вывод исследования связан даже не с перечнем нарушений.
Во многих технических заданиях обнаруживаются практически одинаковые формулировки, повторяющиеся ошибки и даже идентичные логические противоречия.
Это позволяет предположить, что многие документы продолжают разрабатываться на основе устаревших шаблонов, которые годами переходят из проекта в проект без полноценной актуализации. При этом обязательная содержательная экспертиза технических заданий до публикации закупки либо отсутствует, либо носит формальный характер.
Само по себе наличие неточной формулировки в техническом задании далеко не всегда приводит к немедленным последствиям.
Но именно такие неточности впоследствии становятся причиной отказов в приемке, дополнительных соглашений, судебных споров, длительных доработок и разногласий между заказчиком и исполнителем.
Причем в условиях цифровой прослеживаемости исправить ситуацию «задним числом» становится практически невозможно.
Каждый документ уже является частью единой доказательной базы.
По сути, сегодня меняется сама философия управления ИТ-проектами.
Если раньше основное внимание уделялось контролю исполнения контракта, то теперь всё большее значение приобретает качество подготовки документации еще до публикации закупки.
Именно поэтому на первый план выходит независимая экспертиза технических заданий, проектной документации и материалов приемки.
Цель такой экспертизы — не поиск формальных замечаний, а снижение рисков, которые могут проявиться через год или даже несколько лет после завершения проекта.
Парадокс современной цифровой трансформации заключается в том, что судьба государственной информационной системы всё чаще определяется не тогда, когда разработчики начинают писать программный код.
Она определяется значительно раньше — в тот момент, когда заказчик утверждает техническое задание и формирует тот самый цифровой след, который впоследствии станет главным доказательством исполнения государственного контракта.
Автор статьи: Юлия Рыбинская-Белим — руководитель проектного офиса и направления экспертизы МДТ Цифра.
