Работа, которую заказали у нашего клиента, заключалась в адаптации и внедрении ERP-системы из 12 модулей под нужды крупного белорусского предприятия. Проект не дошёл даже до приёмочного тестирования и застопорился на этапе утверждения технической документации.
Казалось бы, у проектов по внедрению программного обеспечения те же атрибуты: есть время, есть ресурсы и есть объём задач, поставленных заказчиком. Что может пойти не так? Если исходить из этого кейса, то «не так» может пойти всё из перечисленного даже если у вас есть наработанная экспертиза по «домену» (отрасли) заказчика.
Откуда начинался спор
Как правило, требованиями клиента (как и его ожиданиями) в IT занимаются бизнес-аналитики. Это они, до корки зачитав PMBOK и книги Карла Вигерса, проводят многочисленные интервью с представителями клиента, работают с заинтересованными лицами, моделируют и прототипируют, готовят Vision&Scope и прочие документы, необходимые для старта.
Но чтобы успешно пройти этот этап, усилий одних только бизнес-аналитиков недостаточно. Необходима постоянная поддержка и взаимодействие, ориентированное на результат, со стороны команды заказчика.
Как развивался спор
Договор с заказчиком предполагал поэтапную работу с поэтапной оплатой. Изначальная предоплата включала в себя сумму на лицензию ERP-производителя и некоторый люфт, авансирующий начало работ.
Подрядчик направил своих сотрудников на предприятие заказчика. Как положено, изучать его бизнес-процессы чтобы потом составить техтребования проекта (blueprint).
Разработка blueprint’ов шла очень тяжело.
Во-первых, у команды интегратора сложилось ощущение, что нет необходимой поддержки проекта со стороны команды заказчика (низкая исполнительская дисциплина, постоянная бюрократизация проекта).
Во-вторых, языковой барьер (нанятые переводчики не справлялись с точным переводом технических аспектов).
В-третьих, подрядчик также оказался не в полной мере готовым к особенностям белорусского законодательства (по части бухгалтерского, налогового, кадрового учета).
В результате blueprint'ы были сделаны с нарушением сроков. Заказчик их не принял, ссылаясь на несоответствие требованиям.
Только не было в полной мере понятно каким требованиям, раз эти самые требования формируются заказчиком на этапе бизнес-анализа.
К барьеру
Стороны стали обмениваться досудебными претензиями и в конце концов оказались в суде. Заказчик предлагал перенести срок оплаты на финальную стадию (после выполнения всех работ). Подрядчик на это не согласился, ссылаясь на принцип поэтапного выполнения работ и поэтапной оплаты, установленный договором.
В результате заказчик ERP-системы подал иск с требованием вернуть аванс и сослался на то, что проект не был реализован по вине подрядчика.
Разобравшись в сложных перипетиях взаимоотношений сторон и большем объеме технической информации, мы подготовили позицию подрядчика, а также подали встречный иск с требованием оплатить подготовленные blueprint’ы и ссылкой на срыв проекта по вине заказчика.
Поставив под сомнения многие аргументы заказчика, мы смогли заинтересовать его войти в переговорный процесс, чтобы урегулировать спор мирным путем.
В конце концов в ходе переговоров нам удалось найти точки соприкосновения между подрядчиком и заказчиком, и судебный процесс был закончен взаимовыгодным мировым соглашением, по которому:
- у заказчика остаются результаты работ (blueprint'ы) и лицензия ERP-системы;
- у подрядчика остаётся аванс, который компенсирует затраты на подготовку blueprint’ов и приобретение лицензий у ERP-производителя.
- В этом деле не было объективности в плане поставленной задачи и полученного результата работы. Не было объективных критериев качества, одинаково понятных двум сторонам проекта.
В ситуации, когда требования качества излагаются (и утверждаются) самим заказчиком, стоит дотошно фиксировать результат каждых переговоров. Да, это не даёт вам гарантий завершённого проекта. Это даст аргументированную позицию в суде и перспективу получить заработанные деньги быстрее, чем это видится оппоненту, - резюмирует адвокат Арцингер-Атторнис Артур Скребец.

