Юридическое значение управленческих и количественных целей в проектах разработки систем

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

Почему цели и задачи разработки системы становятся источником конфликтов?

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

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

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

Суммируя вышеизложенное, можно выделить две важные точки.

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

Из-за этих двух обстоятельств возникает вопрос о том, в какой степени достижение управленческих и количественных целей, объясненных пользователем заранее, может стать обязанностью поставщика. То есть, с одной стороны, есть аспект, согласно которому обязанность пользователя состоит в том, чтобы сформулировать то, что должен делать поставщик (не что-то неопределенное, как цели), в виде спецификаций. С другой стороны, поставщик, как специалист, также несет обязанность предоставлять то, что пользователь действительно требует (не просто делая то, что ему говорят). Это столкновение противоположных точек зрения является характерной чертой конфликтов, связанных с “целями” и “задачами” разработки систем. С точки зрения закона, задачей на практике является предложение руководства для справедливого разрешения конфликтов между обеими сторонами.

Конкретные сценарии, в которых цели пользователя влияют на проект

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

• Сокращение затрат на персонал благодаря автоматизации
• Увеличение продаж и прибыли
• Сокращение рабочего времени

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

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

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

Случай, когда улучшение скорости работы было поставлено в качестве цели

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

• Сократить время ручного ввода на 50%
• Обеспечить выполнение делопроизводства с использованием данной IT-системы в установленные сроки

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

Таким образом, (пропуск) согласно общему смыслу доводов, ① цель данного дела – “повышение эффективности работы”, “создание основы для CRM”, “ведение “видимого управления” и т.д., является абстрактной, а целевые значения, такие как “увеличение контактов с клиентами”, “распределение трудовых ресурсов административного персонала на внутренний контроль и поддержку продаж”, “более точное прогнозирование продаж”, “сдерживание чрезмерных скидок на продажи” и т.д., в основном абстрактны, и целевые значения, такие как “сокращение времени ввода на 50%”, “сокращение времени на составление сметы на 50%”, “обеспечение законодательного раскрытия информации в установленные сроки” и т.д., зависят от управления и методов работы ответчика после внедрения SBO, и не являются такими, которые разработчик системы, поддерживающий внедрение пакетного программного обеспечения, мог бы взять на себя, ② в протоколе собрания после старта проекта не было указаний на то, что было проведено конкретное обсуждение о достижении цели и целевых значений, ③ в плане проекта были использованы выражения, такие как “стать публичной компанией”, которые не могут считаться обязательствами по договору, (пропуск) и т.д., учитывая эти обстоятельства, можно признать, что истец создал описание цели данного дела в плане проекта на основе объяснений ответчика, чтобы проект не потерпел неудачи, и чтобы получить общее понимание цели и результатов проекта, и ответчик не может признать, что он поручил истцу разработку системы для достижения цели данного дела. (пропуск) Следовательно, не может быть признано, что истец принял на себя разработку системы для достижения цели данного дела от ответчика, поэтому (пропуск) нет оснований для утверждений о неисполнении обязательств и гарантийных обязательствах.

Решение Токийского окружного суда от 28 декабря 2010 года (Heisei 22)

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

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

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

Таким образом, они получили такую юридическую оценку.

Что еще можно узнать из этого решения

В этом решении также содержится несколько интересных моментов.

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

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Важные моменты правовых вопросов, связанных с управленческими и количественными целями

Однако, следует учесть некоторые дополнительные моменты, связанные с такими “целями” и “задачами”.

Вопрос оплаты консультаций может изменить ситуацию

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

Недостатки продукта, несоответствие функций и требований к спецификациям – отдельная проблема

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

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

https://monolith.law/corporate/system-development-specs-function[ja]

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

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

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

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