Заключение контракта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 2 Управление ит-персоналом

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

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