Как нажиться на ИТ

Tема распилов при госзакупках в сфере ИТ громко зазвучала после того, как известный политик и блогер Алексей Навальный добился отмены конкурса Минздрава РФ на разработку за 16 дней «социальной сети» за 55 млн рублей. Вскоре после этого руководитель контрольного управления администрации президента РФ Константин Чуйченко, докладывая Дмитрию Медведеву о состоянии дел с госзаказом, указал, что сегодня неэффективно расходуется не менее 1 трлн рублей. (Постулировав таким образом, что при общем его объеме в 5 трлн в год нормативный процент отката сложился на уровне не менее 20%.) Также он перечислил отрасли, в которых «особенно много воруют». В список попали и информационные технологии.

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

Не так страшен распил

Любое сообщение о конкурсах на поставку тех или иных ИТ-решений за те или иные деньги в первую очередь неизбежно вызывает массу комментариев в духе «Распил! Да я такую штуку сделаю за два месяца и 50 тыс. рублей!». Такие комментарии бессмысленны, непрофессиональны и вводят читателя в заблуждение. Большинство их авторов никогда не имели опыта ни разработки крупных, серьезных, нагруженных информационных систем, ни управления большой командой, в которой помимо программистов есть множество представителей смежных специальностей (тестировщиков, документаторов, аналитиков). Они не знают структуры затрат фирмы-подрядчика (от налогов до аренды) и уровня зарплат на рынке труда квалифицированных программистов.

Между тем просчитать бюджет проекта по конкурсной документации (причем очень хорошо написанной) можно с точностью разве что плюс-минус 50%. Пытаться более точно оценить смету ИТ-проекта - все равно что лечить геморрой по фотографии: если человек говорит, что может по КД различить проект на 7 или 8 млн рублей, он шарлатан.

По документации можно опознать только очень явные и наглые распилы, где действительно цена завышена раза в три-четыре. А как отличить кристально честный конкурс от конкурса, где есть откат в 20%, я не знаю. У меня таких измерительных приборов нет. Речь же не о поставке картошки в детские дошкольные учреждения! Да и как отличить, скажем, заложенную в смету прибыль разработчика в 30% от прибыли в 10% и отката в 20%? Таким образом, цена работ является очень слабым и ненадежным индикатором коррупции, даже если она и выглядит сильно завышенной.

Гораздо легче сделать предварительную оценку не по стоимости, а по срокам. Глядя на КД, я довольно быстро могу прикинуть: этот проект на 6 - 12 месяцев, а этот - не меньше чем на полтора года. И если в КД указано 10 или 15 дней - это звоночек.

Заведомо заниженные сроки встречаются очень часто и являются надежным индикатором коррупции (но не коррупцией как таковой). Что именно они показывают? Одну вещь: подрядчик уже известен, а конкурс лишь де-юре закрепляет те отношения между заказчиком и подрядчиком, которые сложились де-факто ранее в течение года.

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

Второй - продукт будет сделан, но заранее выбранным заказчиком. Такой сценарий реализуется довольно часто, потому что нормальное техзадание для ИТ-конкурса может написать только его будущий победитель. Проблема в том, что в отрасли информационных технологий (и это ее специфика) качественная постановка задачи - зачастую более трудоемкий процесс, чем ее решение. Вспомните классическое соотношение Брукса: 1/3 бюджета времени приходится на проектирование, и только 1/6 - собственно на разработку проекта (еще по 1/4 - на тестирование модулей и продукта в целом). Конечно, эти рекомендации 1975 года отчасти устарели, но лишь отчасти. В итоге постановку задачи, как правило, пишет будущий подрядчик. И тогда, конечно, он заинтересован в том, чтобы сам конкурс не ушел у него из рук, и сжатые сроки являются лучшей защитой. Как выбирается подрядчик? Ну, как-то. На основании не конкурсной процедуры, а какой-то иной, в том числе коррупционной.

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

Коррупционные маяки

Итак, я бы предостерег делать выводы о коррупции на основании одного только сочетания цены и сроков, без исследования дополнительных обстоятельств и выявления дополнительных индикаторов.

Первый важный индикатор, позволяющий судить о честности конкурса, - настойчивость его организатора в подборе «правильного» подрядчика. Проиллюстрирую свежим примером не из области ИТ. При попытке освоения 20 млн рублей на ремонт дачи правительства Свердловской области в Малом Истоке конкурс назначался трижды, с тем чтобы обеспечить победу нужному поставщику услуг. Это уже однозначный индикатор коррупции.

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

Наконец, аспект, о котором часто забывают, - целесообразность. Например, я внимательно изучил конкурсную документацию к проекту «Электронный офис мэра Москвы». Она грамотно написана. Задача поставлена хорошо и четко, и заявленная цена в 23 млн рублей вполне адекватна объему работ. Вопрос в другом: нужен ли такой программный комплекс нам - налогоплательщикам, на деньги которых он создается? Информатизация не должна быть самоцелью, она обязана служить снижению каких-то издержек или созданию новой добавленной стоимости. Если у нас есть девочка (или мальчик), которая перекладывает бумажки из левой стопки в правую за зарплату в 10 тыс. рублей в месяц, а создание программного комплекса, автоматизирующего это перекладывание, стоит 10 млн рублей, то этот комплекс просто не следует заказывать и разрабатывать. По мне, создание заведомо бесполезного продукта, пусть даже и за адекватные деньги, тоже следует считать формой распила, причем такой, в которой наиболее ярко проявляется продажа души дьяволу. Ведь подрядчик, когда идет на такое, прекрасно знает, что его работа бессмысленна, но соглашается.

Одно окно

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

Избежать написания техзаданий подрядчиком мы все равно не сможем. Поэтому любой заказ на разработку в обязательном порядке предваряется заказом на проектирование.

Конкурс на разработку назначается только в том случае, когда по результатам конкурса на проектирование удалось получить действительно качественное ТЗ (качество оценивается экспертным советом и верифицируется ведомством).

В системе критериев оценки конкурсных заявок могут на законных основаниях присутствовать преференции. Например, компании-разработчику при проведении конкурса на сопровождение и внедрение; разработчику или внедренцу - при проведении конкурса на доработку; компании, выигравшей конкурс на проектирование, - при проведении конкурса на разработку. Размер преференции должен подбираться таким образом, чтобы предоставлять серьезное преимущество, но не быть запретительным (например, критерий весом в 10 - 20 баллов при 100-балльной шкале оценки конкурсных заявок).

Система преференций призвана, с одной стороны, обеспечить преемственность при «нормальном» поведении подрядчика (проще и лучше, когда сопровождает тот, кто написал). С другой стороны, делает смену подрядчика возможной: например, его можно наказать, если тот пытается наглеть и, подсадив заказчика на свой продукт, стричь с него деньги.

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