При закупке программного обеспечения или цифровых интеллектуальных услуг предприятиями в тендерных документах по‑прежнему часто встречается требование: «Тендерант должен иметь в штате XX старших инженеров и обеспечить присутствие на объекте не менее XX человеко‑месяцев». В таблицах оценки применяется метод взвешенного балльного подсчёта по числу сотрудников, их квалификации и единичной цене — такой подход был обоснованным ещё десять лет назад, но…Интеллектуальный агент и доставка с поддержкой ИИВ наше время, когда распространены различные решения, нередко выбирают поставщика, у которого «больше всего людей», а не того, чьи результаты наиболее ясны.
Политический контекст: логика закупок меняется
В сентябре 2026 года Министерство промышленности и информатизации опубликовало «План реализации специальной программы „Искусственный интеллект + программное обеспечение“», в котором предлагается продвигать модернизацию программного обеспечения в направлении интеллектуализации, развитие моделей «интеллектуальный агент как услуга» и др., а также подчёркиваетсяНе смотря на то, сколько было вложено, а на то, каковы реальные результаты.Для покупателя сигнал предельно ясен: если продолжать ориентироваться лишь на человеко‑дни и количество сотрудников, находящихся на месте, можно приобрести «шумную реализацию», но не получить поддающиеся проверке улучшения бизнес‑процессов.
Оценка по результатам труда vs оценка по итогам: в чём разница?
| Размерность | Традиционная оценка тендеров по человеко‑дням/на человека | Оценка на основе результатов |
|---|---|---|
| Ключевые показатели | Количество сотрудников, уровень, количество дней присутствия на площадке, цена за единицу | Замкнутый цикл сценария, скрипт приёмки, KPI после запуска в эксплуатацию |
| Выражение потребностей | Проверка списка функций | Рабочие операции + стандарты данных + правила исключений |
| Обработка изменений | Согласование на месте: добавить сотрудников и увеличить бюджет | Какие вехи и какие KPI затрагиваются изменением? |
| ИИ/агент | Обычно не включается в оценку | Требуется указать точки повышения эффективности, этапы ручной проверки и границы прав доступа. |
| Узел оплаты | Расчёт производится ежеквартально или по человеко‑месяцам. | Оплата по мере успешного прохождения проверки по этапам выполнения |
| Суть спора | «Наличие персонала» | «Запущен ли скрипт и улучшены ли показатели» |
Бизнес‑логика: как изменить тендерную документацию
Преобразуйте документы по закупкам из формата «покупка рук» в «покупка результатов», рекомендуется переписать четыре раздела:
- Список сценариев: Записывайте «текущая проблема → целевое действие» по должностям, например: «Покупатель вместо размещения заказа по электронной почте теперь осуществляет утверждение PO в системе, завершая процесс в闭环».
- Скрипт приёмки: Каждый сценарий сопровождается тестовыми шагами, входными данными и ожидаемым результатом; участник тендера должен по каждому пункту подтвердить реализуемость.
- Обещание KPI: В течение 90 дней после запуска можно измерить количественные показатели, такие как степень сокращения сроков утверждения, уровень расхождений при сверке и точность учёта запасов — эти показатели должны быть доступны для системного сбора данных.
- Граница обслуживания: Обучение, эксплуатация и техническое обслуживание, миграция данных, а также поддержка правил интеллектуального агента — каждая из этих задач должна быть чётко распределена между соответствующими сторонами, чтобы избежать ситуации, когда «внедрение заканчивается сразу после запуска».
Рекомендации по весам оценки:Соответствие решения и результатов приёмки — 40% + эффективность аналогичных проектов — 30% + цена — 20% + компетентность команды — 10%. Команда по‑прежнему должна быть видна, но не должна доминировать; иначе снова вернёмся к переполнению штатом.
Логика проектирования: как интеллектуальные агенты и автоматизация внедряются в процесс оценки тендерных предложений
Если в предложении предусмотрены интеллектуальный клиентский сервис, автоматическое напоминание и движок правил, заказчик должен потребовать от участника торгов ответить:
- Ввод и вывод: какие документы читать, какие статусы записывать обратно, подлежит ли это аудиту.
- Права и обновления: Какие операции должны подтверждаться вручную и как осуществляется эскалация при превышении времени.
- Точность и выборочная проверка: Как измеряется базовый уровень обязательств и как выполняется откат при неправильных действиях.
- Привязка к поставщику: Можно ли экспортировать модели, правила и базу знаний, чтобы избежать полного паралича при смене производителя.
Внедрение и приёмка: третья очередь системы контроля доступа
Рекомендуется чётко прописать в договоре трёхэтапный контроль доступа, а также увязать оплату с приёмкой:
- Первый этап (4–8 недель): Сценарий ключевой сценарии прошёл проверку на 100%, обучение ключевых ролей завершено. Если не пройдёт проверка, второй этап оплаты не производится.
- Вторая фаза (8–12 недель): Настроены межотраслевые бизнес‑процессы, обеспечена стабильность интерфейсов и основных данных; запущен в эксплуатацию сбор базовых данных для KPI.
- Третья фаза (90 дней эксплуатации): По итогам выполнения KPI, указанных в договоре, при несоблюдении норм предусмотрены сроки для устранения недостатков и соответствующие штрафные санкции, а не бесконечное присутствие на объекте.
Количество сотрудников на месте может служитьСредства реализацииЗапись в приложении, но это не должно быть предметом основного договора. Предметом основного договора должны быть «какие скрипты прошли, какие показатели улучшились».
Распространённые заблуждения покупателей
Заблуждение первое: победа в тендере по низкой цене за человеко‑дни— В последующем при внесении изменений цены повышаются, а общая стоимость оказывается выше. Мера: установление предельной общей стоимости + таблица расчёта стоимости изменений.
Заблуждение №2: чем больше функций, тем лучше— Низкий уровень запуска. Меры: поэтапное внедрение сценариев, первая фаза — небольшое количество функций и замкнутый цикл.
Заблуждение третье: игнорирование мастер‑данных— После ввода системы в эксплуатацию данные оказались запутанными и некорректными, а интеллектуальные модули усугубили ошибки. Меры: проведение отдельной проверки по ключевым этапам управления мастер‑данными.
Заблуждение четвёртое: не определять методику сбора данных для KPI— Во время разборок каждый считает по‑своему. Решение: формулы показателей, источники данных и периоды учёта следует приложить в виде дополнительного документа, а информационный отдел должен подтвердить, что система способна автоматически извлекать данные.
Следующий шаг
Если вы вновь проводите тендер на внедрение ERP, OA, SRM или на индивидуальный цифровой проект, сначала уделите одну неделю «тестированию тендера»: выделите все пункты по трудоёмкости в существующем техническом задании и поэтапно перепишите их в формате сценарий + скрипт + KPI. Даже если не успеете всё доработать — это не страшно; по крайней мере, в следующей версии тендера вы уже не будете выбирать поставщика, руководствуясь логикой 2015 года.
«Техническая модернизация» в сфере программного обеспечения происходит не только на производственных площадках подрядчика, но и в отделе закупок заказчика. Тот, кто первым будет оценивать тендеры по результатам, с большей вероятностью приобретёт в эпоху интеллектуальных систем действительно работающую, отслеживающую ответственность и позволяющую проводить анализ системы управления, а не просто объёмный список сотрудников.
Дополнительные моменты, требующие внимания при государственных закупках и закупках для групповых компаний
Крупные закупки часто требуют соблюдения как нормативных требований, так и практической эффективности: в тендерной документации можно сохранить требования к квалификации и положения о противодействии мошенничеству, ноТаблица оценки технических характеристикНеобходимо установить «полноту отклика скрипта приемки» и «измеримость KPI» в качестве жёстких критериев, чтобы избежать превращения технической оценки в формальность. В условиях многофирменной структуры группы следует требовать от участников тендера разъяснений относительно того, как основные данные и права доступа поддерживают дочерние компании, а внедрение должно осуществляться после того, как на первом этапе в пилотной фирме будут успешно протестированы соответствующие сценарии, а не сразу проводить полную интеграцию всей группы.
Во время демонстрационной части комиссии по закупкам рекомендуется на месте отобрать 2–3 сценария и предоставить их для выполнения участникам тендера; члены жюри будут оценивать результаты, сопоставляя их с ожидаемыми показателями — такой подход гораздо ближе к реальному опыту после внедрения, чем простое изучение PPT‑презентаций. На этапе переговоров по контракту следует включить в основной текст положения о «периоде корректировки при невыполнении KPI и формуле удержаний» — это обеспечит более надёжную защиту интересов обеих сторон, чем последующие договорённости по принципу «взаимных связей». Реформа процедуры оценки тендерных предложений не должна ждать выхода следующего национального стандарта: уже в следующем тендере можно первым делом опробовать один сценарий, один KPI и одну фазу системы контроля доступа. Малые шаги и испытание ошибок позволят оперативно адаптироваться к изменениям как в политике, так и в технологиях, что гораздо эффективнее, чем ожидание идеального шаблона.