ВВЕДЕНИЕ

Корректно составленный договор с подрядчиком – это ваше ОСАГО в ИТ-проекте.

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

Настоящая проверка договора начинается, когда там начинаются проблемы и разногласия. Поэтому я и применяю такую метафору как ОСАГО – ведь он тоже никому не интересен, пока не случилось ДТП. Но если все-таки случилось, очень не хотелось бы без него оказаться.

УСЛУГИ

Первое, что необходимо понять – что вы покупаете.

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

Доработки – в случае если вам необходим ресурс для решения различных задач, перечень которых заранее не определен.

Поддержка – если ваша система уже работает, но есть множество обращений пользователей на консультацию, доработку или по ошибке.

Сервис (подписка) – если есть готовое решение, продаваемое по подписке, и оно вас полностью устраивает.

РЕЗУЛЬТАТ

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

Что обязательно должно быть детально прописано (это необходимо проверить):

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

• Документы, описывающие решение (АЗ, ТЗ, инструкции, документация для поддержки решения);
• Прототипирование в процессе создания решения, для контроля процесса, а не только результата;
• Функциональное тестирование, где вы проверяете логику работы каждого блока системы;
• Интеграционное тестирование, где вы проверяете комплексную работу решения во всех блоках автоматизации одномоментно;
• Сверка данных, где ваша задача убедиться, что данные загружены/введены в систему корректно, ведь без этого остальные труды бесполезны;

БЮДЖЕТ

Предположим, что у вас классический проектный договор, где итоговая стоимость работ зафиксирована (Fixed Price). При планировании бюджета нужно учитывать не только эту стоимость. Начнем по порядку:

• В каждом договоре Fixed Price должен быть раздел «Допущений и ограничений». Прочтите его внимательно. Это один из важнейших пунктов, в котором фиксируется информация о том, что не входит в проект. Это значит, если «за бортом» осталось что-либо важное, вы все равно будете это реализовывать, но уже за дополнительный бюджет. Рекомендую вам как минимум посчитать эти затраты, а возможно, включить работы в проект.
• Для начала, нужно заложить бюджет на неопределенные риски. Согласно проектной методологии, это должно быть около 20% от бюджета проекта. Но если вы делаете проект в первый раз и не уверенны в подрядчике и/или в своей команде, то рекомендую закладывать больше. До 50%, если есть такая возможность. При этом это именно ваш рисковый бюджет, с подрядчиком его обсуждать не требуется. Пусть старается уложиться в бюджет по договору.
• Для объективного понимания затрат на автоматизацию не достаточно посчитать затраты на проект, важно понимать и затраты после автоматизации. Если у вас появилась новая система, то кто-то ее должен обслуживать – как правило, нужна поддержка и доработка. Вам необходимо либо убедиться, что это осуществимо внутренними силами вашего ИТ, либо сделать совместно с подрядчиком расчет стоимости таких услуг в год для корректного бюджетирования. Тогда вы сможете оценить объективно совокупную стоимость автоматизации на несколько лет (TCO) – это уже достаточная информация, чтобы прийти с ней в ваш бюджетный цикл.

В случае с сервисом и поддержкой все существенно проще: вам необходимо считать стоимость ежемесячной абонентской платы за 12 месяцев. Других затрат здесь как правило нет.

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

РЕСУРСЫ

Есть весьма частое заблуждение, что проект делает подрядчик, а заказчик лишь платит и наблюдает за ходом проекта. На деле же на разных этапах проекта от участников со стороны заказчика требуется выделение до 50% ресурса. Поэтому необходимо:

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

СРОКИ

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

Чем строже ответственность за срыв срока, тем лучше заказчик будет следить за этим аспектом.

РИСКИ

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

РЕЗЮМЕ

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

Желаю удачи и порядочных подрядчиков!

Оригинал статьи размещен на сайте ФТО.