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

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

• Необходимо помнить, что компания будет делать только то, что за­писано в контракте.

• Предполагать негативный сценарий и анализировать контракт с этой точки зрения.

• Софтверные компании умеют не только «вспоминать» о не включен­ных в первоначальное предложение услугах и модулях, но и «падать» в ценах.

• Необходимо требовать прояснения терминологии и закрепления ее в контракте, в том числе таких понятий, как «адаптация», «доработка», «настройка», «конвертация» и т. п.

• В контракте должны быть определены ключевые точки проекта (milestones) и признаки их достижения (например, опытная и про­мышленная эксплуатация, пользовательское тестирование и приемка, поставка программного обеспечения и т. п.).

• Везде, где это только возможно, необходимо включить в контракт требование об обязательном согласовании с банком действий компа­нии — поставщика решения.

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

• Может быть предусмотрен возврат всех или части лицензионных пла­тежей при неуспехе внедрения или его задержке более чем на один год (на этот пункт поставщики решения не всегда соглашаются).

• Поддержка российской отчетности, налоговых и прочих требований должна быть рассмотрена отдельно и детально.

• Процедура отказа от старой системы должна быть также рассмотрена.

• Необходимо предусмотреть возможность по требованию банка за­мены отдельных специалистов или менеджера проекта в случае недо­статочной их квалификации или при возникновении сложностей во взаимоотношении с ними.

• Желательно определение предельных сроков и стоимости работ.

• Нужно включить в контракт процедуры разрешения споров и конфликт­ных ситуаций.

Если учесть все эти факторы, можно существенно снизить риски, сопро­вождающие выбор системы.