Мы уже писали о разработке международного открытого стандарта данных по контрактам (OCDS) и о том, что у России сейчас есть большой потенциал к развитию контрактной открытости. Теперь посмотрим, что собственно представляет собой этот стандарт, с какими проблемами сталкиваются его создатели, а также те, кто в принципе заинтересован в публикации открытых данных.
Что представляет собой стандарт открытых контрактов
Как и любой другой стандарт, OCDS стремится описать процесс заключения и выполнения контракта на его ключевых этапах. Для этого необходимо выявить общую структуру документов, на которые опирается этот процесс и которые в итоге должны быть опубликованы. С одной стороны, параметров описания не должно быть слишком много, чтобы стандарт получился узколокальным. С другой стороны, их должно быть достаточно, чтобы он отвечал одной из своих главных задач – обеспечению прозрачности и понятности конкретных процессов.
К стандарту прилагается подробное описание его структуры, которое фактически представляет собой справочник для пользователей и публикаторов данных. Согласно нынешней версии, публикация контракта должна включать в себя следующие метаданные и информацию о контракте. Метаданные содержат в себе информацию о публикации: дату, релизы, кто опубликовал, по какой лицензии Там же должна содержаться ссылка на документ, описывающий принципы этой публикации, и унифицированный идентификатор ресурса (URI), позволяющий ссылаться на эти данные и связывать их с другими данными.
Информация о контракте должна описывать такие параметры, как:
- уникальный идентификатор контракта;
- идентификатор релиза;
- дата публикации информации;
- тэги из прилагающегося списка, классифицирующие контракт;
- информация о подготовке контракта;
- информация о тендере;
- информация о заказчике;
- информация о вознаграждении (award);
- информация о контракте;
- указание языка.
К каждому пункту в справочнике даются подробные пояснения, чтобы публикатор точно знал, какого рода информацию от него хотят, а пользователь – какую информацию он получает. Однако уже сейчас с этим описанием и пояснениями есть проблемы, которые необходимо будет учесть при разработке дальнейших версий OCDS.
Нестыковки в разных странах
По словам главного разработчика OCDS Тима Дэвиса (Tim Davies), одна из серьезных проблем – это разница между правилами заключения контрактов и, соответственно, структурой данных, в разных юрисдикциях. «Важно, чтобы стандарт был достаточно гибким для разных типов правительств и разных систем заключения контрактов, но при этом сохранял последовательность, чтобы можно было сопоставлять данные, и больше пользователей могли их использовать. Один из способов достижения такого баланса – это разрешение на создание "расширений" стандартов: это означает, что мы помогаем публикаторам из разных стран добавить свою специфику к основному ядру стандарта. Еще у нас есть три уровня публикации - базовый, средний и продвинутый. Это позволяет использовать поступательный подход, при котором правительства постепенно публикуют всё больше данных».
С российской стороны этот момент прокомментировала Елена Минина (аналитик, НП «Инфокультура»): «Одна из основных проблем создания международного стандарта в том, что в каждой стране свои нюансы. Так, например, в России отсутствует стадия award, так как после того, как организация выигрывает конкурс/тендер, сразу заключается контракт, и нет этого промежуточного “буфера”. С другой стороны, у нас в тендере могут участвовать несколько заказчиков с разными бюджетами. В OCDS сейчас предусмотрен только один заказчик и только один бюджет (разные бюджеты на один тендер/контракт у нас встречаются довольно часто, например, бюджет области и внебюджетные средства). Еще один пример несоответствия – наши классификаторы и идентификаторы организации (вместо одного номера – два: ИНН и КПП). Все это совершенно логично, так как разработчики стандарта при написании первого релиза не знали об особенностях наших тендеров/контрактов и, соответственно, не могли их учесть. Часть таких расхождений мы уже обговорили, часть еще предстоит “утрясти”».
Для того чтобы «утрясти» и, для начала, выявить особенности, которые следует учесть в стандарте, OCP устраивает онлайн-консультации и проводит оффлайн-воркшопы. Недавно такой воркшоп проходил в Берлине. По словам участвовавшей в нем Мининой, его главной целью был «обмен информацией о специфике контрактов и данных разных стран. Что делать, если какие-то данные “не лезут” в стандарт? Что делать, если чего-то не хватает? К тому же, сам стандарт еще достаточно “сырой”, первый релиз вышел вот буквально в дни воркшопа (до этого был черновик). Документация к нему не совсем прозрачна, особенно, если какие-то поля нехарактерны для данных, с которыми работаешь. Так что во время воркшопа заодно проясняли такие вот неоднозначные места: аналитики – что чему соответствует, а разработчики – где нужно уточнить формулировки».
Здесь возникает вопрос о том, как технически происходит приспособление стандарта к международным расхождениям.
«На нынешнем этапе, - комментирует Елена Минина, - сторонники стандартизации пытаются решить проблему нестыковок путем адаптации стандарта. Разработчики из других стран, несомненно, что-то меняют в своих представлениях данных. Например, у нас поставщики указываются в контрактах, а по OCDS – в графе “awards”. Заказчики указываются и в тендерах, и в контрактах, а по OCDS – вынесены в верхний уровень. Вообще весь стандарт – это история про формат публикации».
Чтобы показать, как происходит адаптация стандарта к российским данным, Елена Минина привела следующий пример: «Про ИНН и КПП мы договорились, что в поле suppliers.identifier мы будем указывать их через “/”, потому что стандартом предусмотрена одна строка, а в поле additionalIdentifiers будем давать ИНН и КПП отдельно. Наши классификаторы, которых нет в стандарте, в него добавят. То же самое с бюджетами. Сейчас предусмотрен только один бюджет, но, скорее всего (вопрос еще обсуждается), добавят поле additionalBudgets. То есть процесс утряски выглядит так: я озвучиваю свой ребус – какие-то данные не могу в лоб перенести в стандарт. И мне или подсказывают, как можно встроиться в существующую схему (как с ИНН КПП), или говорят, что да, будем расширять стандарт (как с классификаторами и бюджетами)».
Баланс спроса и предложения
По мнению Тима Дэвиса, еще одна проблема в разработке контракта в том, чтобы понять, как установить баланс между существующим предложением данных и спросом на них. Потенциальных пользователей контрактных данных очень много, и у них всех разные потребности. «Например, - пояснил он, - компании хотят детальной классификации тендеров, в то время как наблюдатели и активисты хотят подробностей по процессу выполнения проекта и его результатам. Правительства часто не публикуют все необходимые данные в одном месте, так что при создании стандарта приходится выбирать, каким данным отдать предпочтение». Иными словами, контрактный стандарт должен в максимальной степени отвечать запросам аудитории, основываясь на том, какую информацию готовы предоставлять правительства.
Проблема спроса
Более широкая проблема, касающаяся далеко не только данных по контрактам, - это слабый спрос на открытые данные. На такую проблему жалуются многие публикаторы и активисты. Когда движение за открытые данные только набирало силу, было распространено мнение, что как только государственные данные начнут публиковаться, разработчики, активисты и журналисты сразу начнут их использовать, и появятся новые бизнесы на открытых данных. По факту оказалось, что желающих и умеющих использовать открытые данные не так много.
Дэвис считает, что слабый спрос зачастую связан с низким качеством публикуемых данных. Конечно, не во всех случаях (есть и счастливые исключения), но опубликованные данные часто оставляют желать лучшего, с точки зрения разнообразия форматов для разных пользователей, аккуратности и достоверности. По мере повышения качества данных будет возрастать и спрос.
Далее, многим пользователям просто не приходит в голову, что можно заглянуть на официальный портал, скачать оттуда данные и их использовать. Они бы и рады, но просто не знают о такой возможности. Это уже вопрос информирования, платформ публикации и интерфейсов.
Наконец, раскрытие данных должно быть стратегическим процессом. Публикуя данные, нужно учитывать, какими инструментами будут пользоваться люди, создавая что-то на их основе; какие именно данные нужны для решения тех или иных проблем. То есть это должно быть встречное движение между публикаторами и пользователями. Здесь также могут быть очень полезны открытые обучающие проекты по использованию данных.
«Но не следует и переоценивать спрос как таковой, - отмечает Дэвис. – Изменения часто наступают не за счет массовости, а через небольшое количество стратегических кейсов использования, а также через внутреннее перестраивание процессов в правительстве, к которым приводит сам факт раскрытия данных, а не только массовое использование данных, над которым работаем мы».
Проблему спроса также прокомментировал Георг Нейманн (Georg Neumann) из Open Contracting Partnership: «Одно из главных открытий, которые мы сделали в процессе публикации данных по контрактам, состоит в том, что эту модель положительно оценили все участники процесса. Особенно в получении этой информации заинтересованы компании, потому что это дает им новые возможности развития и участия в государственных проектах. Например, в Словакии, после того как открыли данные по контрактам, увеличилось число фирм, выполняющих госзаказы. Так что, я думаю, что при публикации данных нужно, в первую очередь, представлять те данные, которые могут представлять интерес в плане возможностей законного развития бизнеса».
