Глава 43. Как заключить правильный договор на внедрение

История эта произошла не со мной, с другим партнером «1С». Но я принял ее близко к сердцу.

2005 год. Молодая, но быстро развивающаяся фирма-франчайзи заключила договор с буровой компанией. На внедрение программы 1С:УПП, которая только вышла. Всех ее подсистем. Управление производством, сбытом, снабжением, кадровый и регламентированный учет, расчет зарплаты, в общем – все. Под ключ, на три миллиона рублей. До этого фирма заключала договора на десятки и сотни тысяч рублей, и три миллиона им казались бесконечной суммой, которой хватит на все. Даже если что-то пойдет не так, миллионы покроют все риски. Владелец фирмы уже присматривал себе новую квартиру. Или даже дом, такая высокая прибыль ожидалась.

Фирма получила предоплату и приступила к работе. Прошло полгода. Срок договора заканчивался, но программа все еще не была внедрена. Заказчик выдвигал все новые и новые требования, и никак не подписывал акт. Деньги заканчивались. Директор был вынужден урезать зарплату вдвое. Пара специалистов уволилась. Остальные затянули ремни потуже, но продолжали работать. Ответственные, порядочные ребята. Работы было так много, что директор решил на время отказаться от других договоров. Чтобы не отвлекаться и побыстрее автоматизировать буровиков. Прошло еще три месяца. Деньги кончились совсем, и фирма не смогла выплатить зарплату. В итоге все сотрудники разбежались, а акт так и не был подписан.

Мой партнер, который рассказал мне эту историю, спросил, а что бы я сделал в такой ситуации?

– Я бы увеличил сумму договора. Помнишь наш разговор с директором тепловозоремонтного завода?

– Помню, конечно. Он вам сказал: «Представьте, что вы пришли в булочную. Взяли батон за 20 рублей. Пока шли к кассе, цена поднялась до 40».

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

Эту историю я вспомнил в кафе, где мы встретились с директором ИТ крупного холдинга. Мы обсуждали проблемы, которые возникли на нашем договоре по внедрению 1С:ERP на одном из заводов. Ситуация могла выйти из-под контроля в самое ближайшее время. Перед заключением договора было проведено предпроектное обследование. Выявлены требования стейкхолдеров, требующие значительных доработок типовой программы. Определен примерный бюджет проекта. Заключен договор, в котором установлен следующий порядок выполнения и приемки работ. На каждую доработку разрабатывалось подробное техническое решение, после чего давалась точная оценка ее трудоемкости. По трудоемкости определялся перечень доработок в бюджете текущего месяца. После того, как доработки принимались комиссией, ежемесячно подписывался акт выполненных работ. Мы проработали по такой схеме три месяца, когда стало ясно, что бюджета проекта может и не хватить на все доработки. Руслан Анварович хотел избежать ситуации, когда деньги кончатся раньше, чем пожелания.

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

– Но у нас другая ситуация. Детальный технический проект мы не делали, делали только предпроектное обследование. В нашем договоре прямо написано, что бюджет – примерный, и что мы уточним его по мере уточнения требований. Потом – у нас есть очень важный стейкхолдер, директор по производству. Раньше он работал на заводе, где была внедрена APS-система. У нас, как вы знаете, ERP. Сейчас мы ERP переписываем так, чтобы учесть все его пожелания. Учимся размещать новые заказы в сверстанную производственную программу с учетом загрузки оборудования. Но это не все. На днях к нему подключился финансовый директор. Он хочет, чтобы мы не забыли про то, как у вас работает старая система сейчас. Нам нужно реализовать систему «канбан». Запускать в производство только те полуфабрикаты, которые нужны для выпуска конкретной продукции. Тут без эджайла нам никак не обойтись.

– Понимаю, что у вас тоже риски. Мы можем увеличить общую сумму договора на 10 %, чтобы их учесть. Но цена должна стать твердой.

– Если бы я был уверен, что разработка новых уникальных подсистем покроется этой суммой, я бы согласился. Но я, к сожалению, не уверен. Будем изо всех сил стараться уложиться в бюджет, но договор мы менять не будем. Он соответствует тому процессу, который сейчас происходит на проекте.

Руслан Анварович расстроился, пытался уговорить меня, даже повысил голос. Мне было очень трудно выдержать такое давление, но я не сдался.

За десятки лет работы в ИТ в качестве подрядчиков мои компании не получили ни одного иска со стороны заказчиков. Мы всегда выполняем взятые на себя обязательства. Не только потому, что мы хорошие подрядчики. Но и потому, что мы составляем правильные договоры. Договоры, позволяющие учитывать множество рисков, возникающих при их выполнении.

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

1. Увеличение требований заказчика без соответствующего увеличения бюджета и сроков проекта.

Такое увеличение может происходить по множеству причин. Наиболее частые случаи следующие:

• плохая фиксация границ проекта, в том числе отсутствие перечисления автоматизируемых подразделений и бизнес-процессов заказчика (плохой пример – «автоматизация управленческого учета в полном объеме»);
• плохое прояснение требований до начала проекта, отказ от предпроектного обследования, отсутствие технического задания или технического проекта («мы не будем платить за обследование, зачем нам этот отчет, мы и так знаем, что хотим»);
• появление новых стейкхолдеров по ходу проекта («а теперь согласуем это с Иваном Петровичем, его вчера назначили директором по сбыту»);
• плохое прояснение очевидных для заказчика требований, выполнение которых он ожидает получить «по умолчанию», например, требований отраслевых нормативных документов («ну вы же эксперты в нашей отрасли, вы должны были это предусмотреть и нас предупредить»);
• Требование переделать интерфейс или бизнес-процесс в типовой программе под привычные для пользователей («мне теперь приходится открывать три окошка, я не могу так работать»).

2. Невыполнение заказчиком своей части обязательств по договору.

Не каждый заказчик и не всегда понимает, что внедрение новой программы – это совместная деятельность объединенной команды, в которую входят как представители подрядчика, так и представители заказчика. А значит, и успех проекта зависит не только от подрядчика. Но и от того, как сработают члены команды со стороны заказчика.

В нашей практике встречались:

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

3. Отказ заказчика от приемки и оплаты выполненных работ.

Думаю, каждый встречался со следующими ситуациями:

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

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

1. Выбор правильной структуры и типа договора.

Управление проектом на уровне структуры и типов договоров лучше всего позволяет избежать риска увеличения требований без увеличения бюджета договора. Рассмотрим возможные подходы.

1.1. Отдельный договор – на внедрение, отдельный – на доработки. В основном договоре специально оговаривается, что «внедряется типовое решение без доработок». Если возникает необходимость в доработках, заключается договор на доработки с фиксированной ценой часа, но без указания объема доработок. Каждая доработка оценивается отдельно и выполняется после получения предоплаты за нее по отдельному счету.

1.2. Отдельный договор – на проект, отдельный – на внедрение. По первому договору разрабатывается подробный технический проект. Он включает в себя функциональную и информационную модели новой системы, набор интерфейсов, печатных форм и отчетов. По его результатам с достаточной точностью оцениваются объем доработок и стоимость услуг по внедрению. После чего заключается второй договор. Оба договора – с фиксированной ценой, но цена второго определяется только после выполнения первого.

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

1.4. Отдельный договор – на внедрение каждой подсистемы при внедрении ERP-системы. Такой подход страхует от серьезной ошибки в оценке стоимости всех работ. Поскольку реально оценивать трудозатраты на конкретном объекте удается только с опытом.

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

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

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

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

1.7. И, наконец, заключение договора по принципу «time and material», то есть без фиксации результатов, с оплатой (а еще лучше – предоплатой) потраченного времени. При этом все риски передаются заказчику или генподрядчику. В нашей практике был такой случай. Крупный интегратор заключил договор с конечным заказчиком на внедрение нашей системы «1С:Управление теплосетью 2». Нас не привлекли ни к предпроектному обследованию, ни к подготовке коммерческого предложения. Поэтому мы отказались работать по договору субподряда с фиксированной ценой и результатом. Но согласились на договор сопровождения по журналу учета времени. В итоге мы выполнили свою часть работы и получили оплату по часам за специалистов. А генподрядчик закрывал проект в целом. Он также справился со своей частью работы, благодаря большому опыту и тесным связям с заказчиком.

2. Включение в договор определенных пунктов, снижающих риски.

2.1. Примерные сроки. Вот текст, который мы включаем в договоры, которые готовим сами.

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

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

2.2. Указание не абсолютных, а относительных сроков. Текст в графе срок «в течение 20 рабочих дней с даты завершения работ по предыдущему этапу» намного безопаснее, чем «31.12.2020 г.». И вернее по сути, так как результаты предыдущего этапа работ используются, как правило, в следующем.

2.3. Указание конкретного объема работ в часах. Например, «доработка типового программного обеспечения в объеме, не превышающем 340 часов работы специалистов исполнителя». Такой пункт позволяет либо сокращать объем доработок до приемлемого, отказываясь от их части, либо подписывать дополнительные соглашения к договору.

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

«Плановые объемы и содержание выполняемых работ по договору приведены в Приложениях 1 и 2 к договору. Точные объемы и содержание выполняемых работ по каждому этапу определяются в «Заказах на выполнение работ» (далее по тексту – Заказы), оформляемых по форме Приложения № 3 к настоящему договору [...] При формировании плановых Заказов на месяц стороны уточняют перечень и содержание работ на текущий месяц [...]».

2.5. Четкое определение границ проекта. Мы добиваемся этого с помощью соответствующих приложений, в которых описываем:

• перечень автоматизируемых подразделений и рабочих мест;
• перечень автоматизируемых бизнес-процессов (функций);
• перечень внедряемых программ и их подсистем;
• перечень стейкхолдеров (ключевых пользователей).

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

2.6. Четкое определение обязательств заказчика. Вот пример этого раздела в одном из договоров:

«Заказчик обязуется:

• предоставить по предварительному письменному запросу Исполнителя необходимую информацию, организационную и техническую документацию, необходимую для оказания услуг;
• принять оказанные Исполнителем услуги согласно порядку, указанному в соответствующем разделе Договора;
• оплатить услуги Исполнителя в размере и в сроки, предусмотренные в Договоре;
• назначить приказом по предприятию:

— Руководителя проекта, обеспечивающего оперативное решение вопросов,возникающих при выполнении работ, а также ответственного за приемку выполненных работ по Актам;

— Рабочую группу, подчиненную Руководителю проекта, обеспечивающую предоставление всей информации и выполнение работ в рамках настоящего Договора;

• предоставить специалистам Исполнителя доступ к серверу базы данных и к любому из компьютеров, на которых выполняются работы;
• предоставить специалистам Исполнителя рабочие места, оборудованные столом, стулом и доступом в Интернет в случае, если работы выполняются на территории Заказчика».

2.7. Четкое определение результатов и состава работ. На рисунке приведен пример для работ на этапах контрольного примера и определения функциональных разрывов:

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

2.8. Четкое определение исключений из проекта. Казалось бы, все просто – не делаем того, что явно не написано в составе работ. Но некоторые вещи лучше оговорить заранее, чтобы избежать необоснованных ожиданий клиента. Вот, например, такой пункт:

«Исполнитель не производит обучение пользователей Заказчика компьютерной грамотности».

Он позволял нам отправлять неопытных пользователей на курсы. Нашим дорогим консультантам не приходилось учить кладовщиков пользоваться мышкой.

2.9. Возможность приостановки выполнения работ при неоплате заказчиком какого-либо этапа по договору или в случае других нарушений. Пункт может звучать так:

«Исполнитель вправе приостановить оказание услуг и потребовать пересмотра сроков оказания услуг в случае несвоевременного исполнения Заказчиком своих обязательств по Договору и при наличии у Заказчика письменного уведомления Исполнителя о таких нарушениях и о приостановке работ».

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

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

2.11. И, наконец, полное исключение из договора безумной и нереальной ответственности, к которой склоняют нас некоторые ушлые заказчики.

• Отказ от ответственности за убытки, полученные в результате использования или невозможности использования внедряемого программного обеспечения. Аргументы – «прочитайте пользовательское соглашение фирмы Microsoft, вот где настоящий отказ от ответственности, а мы готовы ее нести в рамках российского законодательства, и не более».
• Отказ от штрафных санкций, если нет симметричной ответственности со стороны заказчика. Например, мы отказываемся от штрафа в процентах за нарушение сроков выполнения работ, если нет пункта со штрафом с таким же процентом за нарушение сроков оплаты.
• Отказ от штрафных санкций, которые могут превысить весь бюджет проекта. Ограничение штрафов до приемлемых величин в 10, максимум – 15 % от суммы договора, а еще лучше – отдельного этапа, на котором произошло нарушение. Помните, что безграничный штраф в 1 % за каждый день задержки работ способен уничтожить весь бюджет проекта всего за квартал.

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

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

Одесское пароходство заключило договор с ООО «Рабинович и партнеры» на покраску судна. Через неделю принимают работу. Ну, вроде все сделано, как надо – пароход весь белый, красивый, в общем – как новенький... Подписали акт выполненных работ, оплатили оставшуюся сумму. Спустя некоторое время пароход отчаливает, разворачивается другим боком, а там – вся сторона ржавая, черная и без единого белого пятна.

Заказчик – в шоке, технадзор – в панике, нашли Рабиновича, привели к пароходу и говорят ему:

– Так, что за дела, почему половину работы не сделали?!

– Да что вы такое говорите? У нас все по договору! Вот, здесь же написано: ООО «Рабинович и партнеры», с одной стороны, и Одесское пароходство, с другой стороны, договорились покрасить пароход...

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

Отправить