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

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

Система MTender, построенная на базе Open Government Principles, абсолютно прозрачна, доступна для всех участников рынка в любой точке мира и в любое время. Это гарантирует публичность и соблюдение единых правил всеми участниками процесса государственных закупок, а, значит, возможность для плательщиков налогов контролировать каждую процедуру.

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

С началом того, что в мире IT принято называть четвертой индустриальной революцией, все больше проявлялась разница между системами и программным обеспечением. В 2015 году стало уже недостаточно разработать «умный софт», который выполнял бы запрограммированные действия. Задача диджитализации начала все больше перерастать в задачу автоматизации. Возникла необходимость в значительно более глубоком осознании сути задач и целей функций, логик процессов и степеней влияния внутренних и внешних факторов.

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

В отрасли IT-решений для закупок подобные примеры трудно привести. Но тем не менее я точно могу отметить Prozorro — систему закупок, построенную в Украине как раз в 2015 году и, по сути, доказывающую всей отрасли, что та самая индустриальная революция докатилась и до публичной сферы; OpenPeppol — технологию, созданную примерно в то же самое время и развиваемую до сих пор Европейской комиссией как универсальный инструмент в области электронных публичных контрактов.

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

Как адепт инноваций в государстве я бы особо отметил систему, построенную и развиваемую на Кипре, но именно как систему, а не как программное решение. eAgora — это концептуальный бенчмарк (эталон - NM) в мире закупок. Именно там родились концепции, которые чаще всего наследуют в закупочных системах для других стран. Кстати, и в MTender есть несколько решений и техник, «подсмотренных» на Кипре.

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

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

Выбор между созданием собственного софта или внедрением «облачного» SAAS — это вопрос выбора инструмента. Выбирать нужно то, что наиболее эффективно решает поставленную задачу и при этом наиболее выгодно экономически с точки зрения как приобретения, так и владения системой.

MTender – самая новая из систем. И дело даже не в самой дате рождения, а в основах и жизненном цикле системы. Прежде чем начать проектировать программное решение, на котором позже была построена система МТender, мы объездили более 10 стран — лидеров в электронизации и реформирования госзакупок, изучили существующие системы и решения, как очень локальные, так и глобальные. Мы хотели понять, какую проблему решают эти системы. Оказалось, проблема во всем мире одинакова, а вот способы ее решения— разные.

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

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

Например, сейчас мы работаем над снижением технического порога входа в систему, разрабатывая более детальную и обширную документацию и средства администрирования, которые по нашим планам переведут решение в категорию «no code».

Эксперты говорят, что система MTender еще не идеальна. Более того, многие жалуются, что в ней нет нужного функционала, интерфейс неудобен и так далее. Так ли это? Что можно улучшить?

8Думаю, для начала нужно понять, как именно работает система. MTender — это трехуровневое решение, где уровень интерфейса (то, что видят конечные пользователи, сидящие по ту сторону монитора – NM.) реализован на стороне коммерческих площадок. Это сайты, разработанные внешними компаниями и подключенные к центральной компоненте MTender. Весь интерфейс, логика поведения пользователей, вординг и т.д. — все на стороне площадок. Центральная компонента MTender (ЦБД) отвечает за другие вещи: уровень логики (то, как работают процессы) и уровень данных (единая точка хранения транзакционной информации и контроль ее статусов во времени).

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

Я согласен с тем, что решение для MTender требует развития, над которым мы в принципе и работаем. После запуска системы в октябре 2018 года мы ни на один день не останавливались в разработке и развитии программной и логической составляющих. И в этом случае речь не о «дебаге» или устранении шероховатостей, а о внедрении целых пластов функциональных возможностей системы, которые все больше покрывают операционный цикл закупок. Например, сейчас в системе на уровне ЦБД реализована логика централизованных закупок: объединенные планы и бюджеты, открытые рамочные соглашения, электронные каталоги. Есть там и электронные контракты. Однако, к сожалению, не весь этот функционал реализован на стороне платформ и принят бенефициаром системы.

Далеко не каждая даже из массивных систем в мире могут похвастаться подобным функционалом. Главный вопрос – что мешает этому функционалу быть открытым для всех пользователей системы? Мы готовы запустить его хоть завтра.

Чтобы система развивалась правильно и быстро, важно сформировать в этой сети центрального игрока, который представлял бы администратора системы, собирал потребности и требования бенефициаров (публичных закупщиков), учитывал бы требования законодательства и мнение экспертного сообщества и формировал бы бизнес- и системные требования. С недавних пор министерство финансов активно начало решать эту проблему, не только формально, но и фактически определив Центр финансовых информационных технологий (CTIF) как такого игрока. Я очень надеюсь, что с появлением настоящего «хозяина» системы, CTIF, пробел между требованиями закона, пожеланиями пользователей и фактической ИТ реализацией устранят в ближайшие месяцы. Мы в этом оказываем полную поддержку.

Если у системы нет всей функциональности, нужно ли ограничивать пользователей в применении других способов организации закупок?

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

Бывает, что ограничение действительно есть, и нужно искать альтернативу. И, если государство (бизнес, отдельно взятый человек — не важно, принцип тот же) действительно нацелено на внедрение системы, то альтернативу эту стоит искать внутри самой системы: как еще можно решить эту же задачу уже имеющимися в системе инструментами? Почти всегда такая альтернатива есть.

Но иногда ограничение выдуманное или надуманное: кто-то в чем-то не разобрался, не спросил, не услышал, не понял и решил, что его специально ограничивают. Он ставит на системе клеймо «все плохо» и делает шаг назад, возвращаясь к какой-то другой, предыдущей системе, которая на самом деле ничем не лучше, просто привычнее. Но это шаг назад, это не развитие. Не бывает готовых идеальных систем из коробки. Построение любой системы — это долгий последовательный процесс, где каждый найденный пробел — возможность сделать систему лучше, а не умножить ее на ноль и вернуть, как было.

Что такое удобство для пользователя системы? Как оно влияет на ее использование?

Удобство — это очень субъективная история. Мне больше нравится термин «понятность». Если пользователю понятно, как система работает, ему комфортно с ней взаимодействовать. Понятно, что значит «вот этот термин», понятно, что произойдет, если нажать «вот эту кнопку». В сфере публичных государственных сервисов достигнуть идеального уровня понятности, как не странно, намного проще, чем в коммерческих: тут все описано, формализовано, унифицировано и стандартизировано. Нужно просто взять и внедрить, не потеряв по дороге смысл.

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

Государству важно знать, с кем оно подписывает контракт, есть ли у исполнителя полномочия. Гражданскому обществу не менее важно понимать, нет ли у этого исполнителя конфликта интересов с членами тендерного комитета, принимающего решение в его пользу. В этом, в том числе, и состоит принцип «все видят всё».

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

В практике MTender было несколько примеров, когда участники сначала загружали в систему свои паспортные данные, а потом жаловались, что «плохая система MTender» их опубликовала. Есть много способов защитить свои персональные данные. Например, не загружать их в систему, если не хотите их публикации. А, если этого требует заказчик, значит, либо это не персональные данные (и это самый частый случай), либо требование заказчика нужно обжаловать. И для этого в системе существует балансировщик: агентство по жалобам. Это, кстати, показывает разницу между инструментом и системой. В системе работают процессы. Да, иногда рутинные, иногда сложные, но процессы. А инструментом можно копать, а можно и не копать, в зависимости от ситуации, настроения или погоды.

В каких случаях можно ограничить принцип открытости данных системы «все видят всё», и как это решено в MTender?

Есть случаи, когда от полной публичности можно и даже нужно отступать — когда это связано с обороной или национальной безопасностью. Хотя и тут надо быть повнимательнее с секретностью. Иначе секретными становятся закупки новой мебели или автопарка. В остальных случаях непонятно, что, от кого и зачем прятать. Мир с каждым днем становиться все более прозрачным. И сегодня самый лучший способ защитить информацию — сделать ее публичной.

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

Открытые данные — это новая нефть. Однако говорят, что система MTender не дает доступ к данным. Так ли это?

Это в корне неверное и даже немного обидное мнение. MTender —открытая система. В ее основе — множество открытых стандартов кода, дизайна, данных. Такой ключевой стандарт — Open Contracting Data Standard — глобальный стандарт публикации процессов публичного контрактирования и их результатов — собственно публичных контрактов. Но и тут мы пошли дальше, покрыв открытым стандартом не только основы тендерных процессов и их результаты, но и каждую отдельную транзакцию — кусочек данных, описывающий бизнес-логику: уточнение условий процедуры, ответ закупающего органа, ценовое предложение, зарегистрированное обжалование, решение о квалификации каждого участника и так далее. Все это данные, описанные открытым международным стандартом и доступные в режиме реального времени через публичные API системы.

Open Contracting Partnership признает соответствие MTender их стандарту. Более того, они задокументировали пример внедрения OCDS в MTender и инициировали доработку стандарта с учетом нашего опыта.

К слову, и коммерческие площадки, о которых говорилось выше, и даже публичный портал MTender (www.mtender.gov.md) отображают данные, полученные именно из этих публичных API в соответствии с регламентом синхронизации. Вся система синхронизируется каждые пять минут, гарантируя актуальность и синхронность информации в каждом из ее узлов (как ЦБД, так и площадки).

Думаю, что мнение о недостаточной публичности системы MTender в основном базируется не на отсутствии публичных данных (мы уже выяснили, что это миф), а на отсутствии инструментов доступа и работы с этими данными для «не технарей». И тут я соглашусь: сегодня в Молдове нет инструментов публичной аналитики. Но и этот вопрос, вероятно, будет скоро решен — Open Contracting Partnership включил Молдову, а, значит, и данные из системы MTender, в перечень стран, для которых сейчас начался проект разработки глобального публичного модуля BI (business inteligence), и идет тендер на выбор компании-разработчика.

В результате этого проекта мы с вами увидим, что на самом деле представляет собой MTender как система открытых данных. Но даже сейчас я могу сказать, что количество информации, которая уже сегодня описывает в MTender каждый контрактный процесс, составляет от 600 до 700 атрибутов. Для сравнения скажу, что в украинской Prozorro таких атрибутов не более 200, в европейском TED — около 500. Рекордсмен – Казахстан, где публикуется более полутора тысяч атрибутов данных, но далеко не все касаются самих закупок. И вот эти 600-700 атрибутов MTender для каждого контракта доступны любому через публичный API в стандарте OCDS в режиме real-time.

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

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

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

Какие сейчас есть глобальные тенденции в области прозрачного контрактирования, которые каждая страна, обеспокоенная прозрачностью отношений между государством и гражданами, должна внедрить как можно скорее?

Около двух лет назад на одном из доменных мероприятий я имел честь принимать участие в панельной дискуссии с профессором юридической школы Института имени Вашингтона (США) мистером Стивом Скуннером (Steve Schooner). В какой-то момент, когда аудитории показывали динамичные и яркие графики, иллюстрирующие процесс и результат закупок одной из прогрессивных стран, профессор задал вопрос, который перевернул мое представление о публичности, системах и их назначении, подходах к построению и внедрению государственных публичных систем: «А государство реализовало свою функцию?». Понимаете? Это другой уровень видения и понимания задачи и проблематики.

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