Право на ошибку, или Кто заплатит за пилот

По статистике 25% ИТ-проектов терпят полную неудачу, до 50% требуют существенных доработок, а 80% выходят за рамки ранее запланированного бюджета или сроков. Ситуацию могли бы улучшить пробные варианты, если бы на них выделялись деньги. Но если бизнес хоть как-то может найти средства на эксперименты, то госорганам на «попробовать» денег не дают. На круглом столе, который прошел в первый день весны в музее связи им. А.С. Попова, члены экспертного клуба «ИТ-Диалог» - руководители ЦТ органов власти,  ИТ-директора, представители вузов и институтов развития делились опытом и обсуждали, где искать выход из ситуации. Заседание было закрытым, поэтому всё называли своими именами.

Между риском и прогрессом

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

Часто случается, что нужно автоматизировать процессы, но денег в бюджете на это нет, а задачу все равно ставят. Особенно если речь идет о государственных деньгах, которые требуют тщательного учета и обоснования. В таких случаях функциональный заказчик, то есть исполнительный орган, может не до конца понимать, что именно ему нужно. Здесь на сцену выходят вендоры с предложением своих продуктов. Однако после покупки может оказаться, что они не соответствуют задаче. Проблему могло бы решить пилотирование, но затраты на него в бюджет не заложить. В Челябинской области нашли выход. Учитывая, что это госсектор, где все должно быть официально оформлено, была разработана форма трехстороннего типового соглашения о пилотировании. Участниками являются Минцифры, обеспечивающее координацию проекта, функциональный заказчик в лице исполнительного органа и вендор. Успех пилотного проекта подтверждается актом, подписанным всеми сторонами, который доказывает, что изначальная гипотеза была верной. В пилотном проекте ключевыми критериями являются сроки выполнения, подтверждение гипотезы и выполнение KPI. Представитель администрации региона сказал, что в 2023 году в области было заключено 16 таких соглашений.

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

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

Ключ к успешному взаимодействию с вендорами, по мнению CIO, — оплата как за сам проект, так и за этапы его подготовки. Интересно, что он видит справедливость в оплате двум вендорам за проведение альтернативных пилотных проектов, что позволяет сравнивать их результаты. Однако обоснование предпроектных расходов с точки зрения технико-экономического обоснования (ТЭО) может быть затруднительным, поэтому такие затраты обычно включаются в операционные расходы (OPEX). Это упрощает процесс привлечения вендоров для качественной предпроектной работы и избавляет от необходимости детального технического обоснования на стадии, когда итоговый результат ещё не определён.

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

Реальность показывает, что обстоятельства бывают различными. К примеру, в Красноярском крае была попытка внедрить систему через пилот, который в итоге не прижился и оказался невостребованным. Однако, этот же пилотный проект привлек внимание Ленинградской области, которая в итоге заключила контракт с ИТ-компанией. Таким образом, пилот в одном регионе неожиданно стал путём к сотрудничеству с другим.

В поисках баланса

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

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

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

Представитель вендора поделился своим опытом работы в Краснодарском крае. В Сочи насчитывается примерно 1200 мест размещения, обязанных взимать с туристов сбор за проживание — суммы варьируются от 50 до 100 рублей за ночь. Вроде не дорого, но появились сомнения в честности сборов: в 2023 году было собрано всего 500 миллионов из ожидаемых 1,5 миллиарда. Администрация города встревожилась: кто-то обманывает, но кто?

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

Возник вопрос о формализации такого проекта: существующие законодательные рамки (44-ФЗ и 223-ФЗ) не позволяют реализовать его из-за отсутствия специального финансирования для пилотных инициатив. Решением стала работа через АНО и подписание с ней прямого договора, который, однако, не гарантировал будущего масштабирования проекта.

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

Плюсы и минусы пилотов

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

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

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

Есть свои сложности и для вендора. Если денег нет, то вложения могут пропасть зря. Часто вендоры берут то, что у них уже есть, и просто адаптируют под задачу заказчика, не тратясь на доработки. А если надо разрабатывать с нуля, то здесь уже идут часы работы разработчиков, и это дорого. Когда же дело доходит до оборудования, расходы растут: надо предоставить железо для тестов.

Еще один риск для вендора — заказчик может в итоге не купить систему или выбрать кого-то другого. Но вендоры считают, что для сложных систем пилоты все-таки нужны. Умный заказчик хочет убедиться на практике, что система действительно работает как надо.

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

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

Проверка на ТЗ

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

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

Другие считают, что это мечты. Найти ТЗ, которое устраивает всех и не меняется в процессе — как найти единорога. В основном, по словам одного из участников мероприятия, лошадь попадается. Особенно когда речь идет не о простой автоматизации, а о чем-то новом. Например, если всегда делали отчеты в PowerPoint, а теперь хотят перейти на BI-системы.

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

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

Закон и порядок

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

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

Кроме того чиновникам нужно не просто выбрать технологию и провести тест, но и убедиться, что все сделано по правилам. Необходимо создавать законы, которые позволят делать пилотные проекты с ИТ-компаниями, не боясь последствий. Сложность в том, что сейчас задач у многие ИТ-руководителей регионов столько, что справиться с ними трудно.

Одно из основных затруднений — сколько времени отводить на пилотные проекты. Если на поиск решений уходит более 3-6 месяцев, это может означать потерю целого года. Иногда кажется, что без искусственного интеллекта уже не обойтись, хотя ещё остается надежда на человеческий ум.

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

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

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

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

***

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

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

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