Материал раздела Основной
Разбираем контрактные стратегии и модели финансирования ИТ-проектов
Крупные компании запускают все больше «дорогих» ИТ-проектов. Они стремятся снизить затраты, поэтому осваивают нестандартные модели финансирования и контрактные стратегии. О самых эффективных рассказывают Виктория Бухар и Павел Сварник («Ланит-Интеграция»)
Контрактные стратегии
Выбор правильной контрактной стратегии позволяет заказчику быстро реализовать комплексный ИТ-проект и снизить совокупные затраты. Можно выделить два основных блока стратегий.
1. Стратегии для оптимизации финансирования капиталоемких проектов
Некоторые проекты по созданию инфраструктуры для «цифры» требуют единовременного привлечения значительных объемов финансирования. К таким проектам можно отнести: создание высоконагруженных вычислительных систем, систем хранения и сетей передачи данных, внедрение средств информационной безопасности, строительство сопутствующей инженерной инфраструктуры. Если вы реализуете такой проект, то стоит обратить внимание на следующие контрактные стратегии.
- Контракт с твердой ценой (Lump Sum Contract). Заказчик и исполнитель заранее договариваются о цене проекта и фиксируют ее в контракте. В этом случае заказчик получает гарантию, что его проект будет выполнен в заданный срок и по оговоренной стоимости. Значит, он точно уложится в бюджет.
- Контракт «Открытая книга» (Open Book). Исполнитель предоставляет заказчику полную информацию о себестоимости своих услуг, а также закупаемого программного и аппаратного обеспечения. Заказчик ее полностью компенсирует с оговоренной заранее премией. Например, премия на закупленное оборудование и ПО может составить 5% от входной цены, а на предоставляемые услуги — 20% от их себестоимости. Заказчик может в любой момент провести детальный аудит затрат по проекту. Главное преимущество такого контракта — исполнитель заранее прорабатывает общие технические решения, а заказчик может сам выбирать наиболее выгодные продукты или корректировать ход выполнения проекта. Эта стратегия особенно хорошо показывает себя в ситуациях, когда на старте тяжело определить бюджет проекта из-за сложности технического решения.