Что такое обязанности по поддержке, которые несет поставщик после завершения разработки системы?

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

Что такое обязанность поддержки

Общее понятие обязанности поддержки

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

https://monolith.law/corporate/project-management-duties[ja]

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

Обязанность поддержки становится проблемой в отношении поддержки эксплуатации для пользователя

Так что же такое обязанность поддержки? И почему она называется иначе, чем обязанность управления проектом? Обязанность поддержки обычно становится проблемой после завершения разработки системы. Проект по разработке системы, поскольку он является “разработкой”, заканчивается, когда система, которую нужно создать, завершена. То есть, проект по разработке системы начинается с определения того, что должна быть система (т.е. определение требований), и заканчивается проверкой того, была ли она действительно создана (т.е. тестирование или приемка). Кстати, о стадии приемки, которая имеет важное значение как “окончание проекта по разработке системы”, и о юридических проблемах, которые часто возникают на этом этапе, подробно рассказывается в следующей статье.

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

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

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

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

I Нарушение обязанности поддержки
(А) Представитель истца 14 июля 1997 года (Heisei 9) обратился к ответчику с просьбой “не только создать систему, но и проследить, чтобы она работала должным образом.“, “Мы – любители, поэтому, заплатив большие деньги, хотим, чтобы система работала до конца.“. В ответ на это, ответчик объяснил, что возможно создание системы, которая позволит достичь целей внедрения истца, и обещал поддерживать систему до тех пор, пока она не начнет работать должным образом. Таким образом, между истцом и ответчиком было достигнуто соглашение о том, что ответчик будет поддерживать систему до тех пор, пока истец не сможет ее полноценно использовать.
То, что ответчик несет обязанность поддержки перед истцом, очевидно из того, что в стоимости договора о разработке системы под пунктом “Поддержка внедрения пакета” учтены расходы в размере 1 726 000 иен, а в смете указано, что ежемесячная плата за обслуживание включает “бесплатное обслуживание в течение шести месяцев после внедрения”, и в документе под названием “О поддержке SE в будущем (материалы для внутренних совещаний)” подтверждено, что можно получить поддержку SE по вопросам “создания процедуры внедрения (план)” и “работы по проверке данных/эксплуатации” в отношении свежих заказов.

(Б) Таким образом, обязанность поддержки, которую ответчик несет перед истцом, конкретно включает, по меньшей мере, до тех пор, пока истец не начнет полноценно использовать систему, обязанность ответчика предоставлять истцу ①адекватные советы по использованию системы, ②присутствовать на тестировании и реагировать на проблемы с системой, возникшие во время тестирования, ③улучшать систему в соответствии с результатами тестирования, ④проводить обучение операторов.
Однако, несмотря на многочисленные проблемы во время тестирования, ответчик не старался серьезно решить их, а просто требовал оплату за обучение операторов, не предоставляя истцу никакой поддержки в подготовке к полноценной работе системы.

Решение Хачиоджи отделения Токийского окружного суда от 5 ноября 2003 года (Heisei 15)

В этом судебном решении, включая оглавление, слово “поддержка” упоминается около 30 раз. Голос пользователя, требующего адекватной поддержки, прямо отражен в тексте судебного решения, что позволяет предположить, что это был результат стремления к справедливому решению, учитывая детали дела. Особенно стоит обратить внимание на следующие моменты в понимании этого дела:

• Нарушение обязанности поддержки рассматривается как “невыполнение обязательств”, и поэтому было принято решение о возмещении ущерба, вызванного этим;
• Термин “обязанность управления проектом” ни разу не упоминается в тексте судебного решения.

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

Как следует понимать природу обязанности поддержки?

Обязанность поддержки пока не является четким понятием

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

Обязанность поддержки не признается безграничной

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

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

Решение Хачиодзи отделения Токийского окружного суда от 5 ноября 2003 года (Heisei 15)

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

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

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

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

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

Заключение

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