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

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

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

Классификация поставщиков

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

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

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

Распределение прав

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

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

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

Договор на оказание услуг является наименее приемлемым вариантом, все-таки он используется для оформления отношений с поставщиками в тех случаях, когда деятельность поставщика оплачивается на почасовой основе. Кажущаяся простота оформления отношений подобным образом скрывает в себе большое количество подводных камней, главным из которых является то, что конструкция договора на оказание услуг вообще не подразумевает создания какого-либо материального результата, а следовательно, и не предполагает распределения прав на него. Например, результатом пользования медицинскими услугами является улучшение здоровья, образовательными – повышение культурно-образовательного уровня и т. п. Поэтому законодательство не содержит механизмов распределения прав на обюекты, созданные в рамках оказания услуг, хотя и предусматривает, что к такого рода отношениям могут применяться общие положения о подряде (ст. 702-729 Гражданского кодекса РФ).

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

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

Более традиционный договор подрядного типа позволяет досконально определить права каждой из сторон на результаты работ; впрочем, далеко не всегда эта возможность используется сторонами. Дело в том, что договор подряда, в отличие от договора на оказание услуг, предполагает наличие некоего материального результата и закрепляет все права на результаты работ и относящуюся к ним документацию за заказчиком. Однако практически все нормы ГК РФ о договоре подряда (гл. 37) предполагают вещественный характер результата работ: результатом работ по созданию вещи является вещь, материальный обюект. Права на нее подрядчик передает заказчику. Подряд на создание обюектов, не являющихся вещью (к числу которых принадлежит и программное обеспечение) не был предусмотрен авторами ГК, что, впрочем, не мешает применять общие положения о подряде к такого рода отношениям.

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

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

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

Во-вторых, по авторскому договору передаются только те права, которые в нем упомянуты. В связи с тем что автором, а значит, и правообладателем будет являться поставщик, все права, не упомянутые в договоре, он сохранит за собой. Поэтому к описанию передаваемых прав в договоре необходимо подходить с особой тщательностью. Как минимум нужно проследить, чтобы в договоре были упомянуты все созданные обюекты, передаваемые права должны быть обозначены как исключительные (в противном случае они признаются неисключительными), перечислены все те правомочия, которые предусматриваются ст. 10 закона РФ «О правовой охране программ для ЭВМ и баз данных». Формулировка условия «Все права на ПО передаются заказчику» является неприемлемой.

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

Обюемы обязанностей

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

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

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

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

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

Соблюдение требований

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

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

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

Сходной с проблемой соблюдения законодательных требований к отдельным видам деятельности является проблема «очистки» результатов работ от прав других лиц. Так, например, при создании многих программных продуктов используются модули так называемого «свободного» ПО, или ПО с открытым кодом. Однако не всякое «свободное» ПО можно использовать свободно, например, программы, распространяемые на основе лицензии GNU General Public License (программы, подчиняющиеся этой лицензии, являются свободными), предусматривают только возможность свободной модификации самого программного кода, остальные же правомочия по данной лицензии пользователю не передаются или передаются в усеченном виде. Более того, пользователь обязан, во-первых, сохранять упоминание об авторе использованного модуля, во-вторых, распространять свой программный продукт, если он создан на основе модуля, лицензированного как GNU GPL, только на условиях данной лицензии, а значит, бесплатно.

Следовательно, если в программном продукте поставщика используются модули, лицензированные по GNU GPL, поставщик не имеет права брать с заказчика плату за поставку своего программного продукта. Впрочем, это легко обойти, закрепив в договоре с заказчиком условие о «раздельной» поставке модулей «свободного» ПО (которое поставляется бесплатно) и коммерческих модулей самого поставщика. Проблемы здесь носят сугубо технический характер: необходимо вычленить модуль «свободного» ПО таким образом, чтобы он мог поставляться отдельно от основного программного продукта.

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

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

Ответственность и риски

Механизмы ответственности и распределения рисков в целом требуют особого внимания. Выше уже говорилось о распределении рисков, связанных с нарушением требований законодательства и прав третьих лиц, однако этим перечень возможных рисков не исчерпывается. В частности, в договорах на поставку ИТБ??решений требуется особое внимание к разделу «Обстоятельства непреодолимой силы», чаще называемому «Форс-мажор». Обычно данный раздел не меняется специалистами компаний, в том числе и юристами, по сравнению с шаблонами договоров; однако в отношениях, связанных с использованием ИТ, обстоятельства непреодолимой силы имеют иную специфику. Например, в перечне таких обстоятельств традиционно упоминаются сбои в телекоммуникационных сетях. Действительно, значительные сбои в состоянии парализовать работу любой ИТ-компании, однако необходимо исключить из перечня обстоятельств непреодолимой силы «нормальный» уровень сбоев, который формирует обычную среду деятельности компании и который не может служить оправданием для неисполнения ею своих обязательств. Следовательно, разграничение нормальных и экстраординарных сбоев в сетях, оборудовании, программных продуктах должно быть обязательно предусмотрено в соглашениях между заказчиком и поставщиком.

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

Оформление отношений

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

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

Николай Дмитрик – юрист,ООО «Парк-Медиа-Консалтинг», dmitric@parkmedia.ru