№ 9 Сентябрь 2015 — 02 сентября 2015

Региональная система — шаг к прозрачным закупкам

Версия для печати 1675 Материалы по теме

Архангельская область, как и Тульская, идет по пути активной автоматизации контрактной системы. О том, как осуществляется данный процесс, рассказывает Екатерина Михайловна Котова, начальник отдела мультимедиа проектов ГАУ АО «Управление информационно-коммуникационных технологий Архангельской области».

История создания информационной системы управления закупками Архангельской области началась в 2011 году. Группа активных аналитиков Управления информационно-коммуникационных технологий области предложила создать систему, предназначенную для автоматизации процессов планирования и осуществления закупок товаров, работ, услуг, мониторинга и аудита в сфере закупок, контроля за соблюдением законодательства РФ и иных нормативных правовых актов о контрактной системе в сфере закупок. Уже было разработано техническое задание, однако правительство региона эту инициативу не поддержало, и проект положили на полку.

Принятие Закона № 44‑ФЗ, который наделил дополнительными полномочиями и функциями уполномоченного органа контрольные и финансовые органы, вернуло интерес к проекту. Прежде всего внимание к данной системе проявило контрактное агентство Архангельской области, поскольку основная часть системы реализует непосредственно его функции, начиная от этапа планирования закупо­к и заканчивая формированием контракта. В связи с этим первичная деятельность по разработке технического задания начиналась именно с контрактного агентства области. Позже к этому процессу подключились контрольно-счетная палата, контрольно-ревизионная инспекция и Министерство финансов области. Поскольку создавалась модульная система, то в принципе каждое ведомство внесло свою лепту в техническое задание в рамках тех полномочий, которыми их наделил Закон № 44‑ФЗ. Разработка технического задания длилась достаточно долго, а процесс согласования занял более полугода, поскольку некоторые ведомства не могли определиться с функциями, которые бы они хотели видеть в этой системе. После согласования посредством открытого конкурса был определен исполнитель — разработчик программного продукта.

Целеполагание

При создании информационной системы помимо реализации функций, предусмотренных законодательством о контрактной системе, преследовались и иные цели. Так, в первую очередь нам хотелось избавить наших заказчиков от проблем, которые зачастую возникают при работе с официальным сайтом закупок zakupki.gov.ru. Ни для кого не секрет, что в пиковые нагрузки сайт сбоит, чем сильно осложняет работу пользователей, а до технической поддержки дозвониться очень сложно. Учитывая это, мы основную часть функций реализовали именно в региональной системе, которая интегрирована с официальным сайтом. Это позволяет нашим пользователям минимизировать контакты с федеральным сайтом.

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

Начало начал

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

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

В сентябре текущего года мы до конца внедрим систему и начнем работу по ее развитию. В наши планы входит масштабирование системы до уровня муниципальных образований, а также охват закупок, осуществляемых по нормам Закона № 223‑ФЗ. У нас уже есть муниципальные образования, которые готовы поучаствовать в пилотном проекте.

Структура системы

Как уже отмечалось выше, мы решили, что наша система должна быть модульной и чтобы каждый модуль был автономен. Схематически это выглядит так (рисунок 2).

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

Этап планирования подразу­мевает как составление плана закупок на три года, так и его детализацию до планов-графиков. Система способна выполнять и контрольные функции. Первым этапом работы в этом модуле является заведение лимитов по учреждению. Когда формируется план закупок и план-график, учреждение не может превысить закрепленные за ним лимиты бюджетных обязательств. В случае превышения учреждением лимитов система его об этом уведомляет. Также она сообщит пользователю и о том, что не все лимиты израсходованы, что остались нераспределенные средства.

Второй модуль, наиболее крупный и сложный, касается размещения извещений о закупках. В него входит этап формирования заявки. Следует отметить, что в нашем регионе все заявки, сформированные по Закону № 44‑ФЗ, проходят как через ГРБС, так и через контрактное агентство области, которое готовит всю документацию и публикует извещение о закупке на официальном сайте закупок.

Отмечу некоторые тонкости (рисунок 3). Контрактное агентство Архангельской области взяло на себя обязательство формировать детализированные коды ОКПД, которые помимо более подробного наименования закупаемого объекта содержат в себе дополнительные характеристики и прикрепляемый шаблон технического задания. Таким образом, в процессе формирования пользователем заявки на проведение закупочной процедуры в ней используется именно детализированный код, если, конечно, для указанного им в плане-графике закупок кода ОКПД есть детализация. При этом пользователь должен будет указать значения дополнительных характеристик. Все это позволяет автоматически сформировать законченное техническое задание.

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

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

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

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

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

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

Поделиться