Закон о невыплате вознаграждения за разработку системы

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

Во-первых, необходимо убедиться, что возможно предъявить требование о вознаграждении

• Поставщик, несмотря на то, что он поставил результаты работы пользователю, пользователь не принимает поставку, и из-за этого работа по требованию вознаграждения задерживается
• Несмотря на то, что было понимание, что приемка была завершена, есть какое-то несоответствие между пониманием пользователя, и он не соглашается на оплату вознаграждения

Такие ситуации вполне могут произойти в реальности.

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

Связанная статья: Приемка разработки систем и применение положений о признанной приемке[ja]

Хотя общее объяснение приемки предоставляется в вышеупомянутой статье, с юридической точки зрения, необходимо рассмотреть, можно ли считать, что приемка пользователя завершена, учитывая положения о “признанной приемке”.

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

1. Завершена ли работа или она все еще незавершена
2. Может ли быть применена ответственность за гарантию от дефектов (статья 635 Японского гражданского кодекса)

Причина, по которой необходимо сначала проверить два вышеуказанных пункта, заключается в том, что если работа не завершена и нет применения ответственности за гарантию от дефектов (статья 635 Японского гражданского кодекса), то даже если подать иск, не стоит ожидать получения оплаты вознаграждения.

Так что конкретно должен исследовать ответственный сотрудник поставщика, чтобы рассмотреть два вышеуказанных пункта? Давайте посмотрим, какие документы следует проверить.

Какие документы необходимо проверить для определения возможности предъявления требования о вознаграждении

Как управлять изменениями в спецификациях разрабатываемой системы и как создавать документы управления изменениями, подробно описано в отдельной статье.

Связанные статьи: Как управлять изменениями в разработке систем с юридической точки зрения

Далее, проверьте, какую сумму можно запросить в качестве вознаграждения

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

Связанная статья: Возможно ли увеличение оценочной стоимости разработки системы после заключения договора?[ja]

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

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

В основном, вам нужно будет проверить, было ли согласие между вами и пользователем о том, что “заказ будет выполнен за эту сумму” (то есть, был ли заключен договор).

Наконец, рассмотрим вопросы, которые могут возникнуть при проведении судебного разбирательства

Будьте внимательны к возможности подачи встречного иска

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

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

Связанная статья: Что такое обязанности управления проектами в разработке систем[ja]

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

Также необходимо рассмотреть, есть ли реальные преимущества для бизнеса

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

Заключение

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

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