Во многих IT-компаниях юридическое сопровождение до сих пор организовано довольно просто: возникает задача — ее передают штатному или внешнему юристу. Нужно проверить договор, изменить оферту, ответить на претензию, оформить разработчика или оценить новую рекламную механику — юрист получает запрос и дает ответ.
Пока компания небольшая, такая модель может работать.
Но по мере роста бизнеса количество юридических вопросов увеличивается, продукты становятся сложнее и постоянно меняются, появляется несколько юридических лиц, изменяются способы монетизации, подключаются банки и платежные сервисы, растет команда, компания получает IT-льготы, выходит на новые рынки.
И в какой-то момент проблема оказывается уже не в количестве юридических задач. Проблема в том, что у компании есть юрист, но нет юридической функции.
Классическая реактивная модель выглядит так:
возник вопрос → поставили задачу юристу → получили ответ или документ → пошли дальше.
В результате через несколько месяцев компания может обнаружить:
Юридическая функция устроена иначе. Ее задача — не только закрывать входящие запросы, а создавать систему:
бизнес-процесс → юридический вопрос → правило принятия решения → документ или инструмент → контрольная точка → ответственный → периодический контроль.
Именно поэтому результатом работы юридической функции становится не только очередной договор или правки на версию контрагента.
У компании постепенно появляются собственные юридические активы: шаблоны, плейбуки, чек-листы, реестры, база знаний, зафиксированные решения и понятные процессы.
Универсального набора не существует. Он зависит от продукта, бизнес-модели и стадии развития компании.
Но у технологического бизнеса обычно возникает несколько постоянных юридических контуров.
Как юридически устроен продукт? Кто является стороной отношений с пользователем? Как происходит акцепт? Какие документы необходимо изменить при появлении новой функции?
Особенно важно, чтобы юристы подключались не после релиза, а еще на стадии проектирования существенных изменений продукта.
Кому принадлежат права на код? Как оформлены сотрудники и подрядчики? Используется ли open source? Как учитывается ПО? Нужно ли включать продукт в реестр российского ПО?
Для IT-компании это не отдельный юридический вопрос, а один из базовых элементов стоимости бизнеса.
Компания должна понимать не только наличие политики конфиденциальности, но и реальные потоки данных: что собирается, зачем, где хранится, кому передается и на каком основании.
При изменении продукта эта карта также должна меняться.
Зрелая договорная функция — это не ситуация, когда каждый новый договор полностью проверяет юрист.
Повторяющиеся решения постепенно должны превращаться в:
Юристы должны концентрироваться на действительно нестандартных и рискованных вопросах.
Аккредитация IT-компании, реестр российского ПО, Сколково и другие режимы требуют не только первоначального получения статуса.
Необходимо постоянно контролировать критерии его сохранения и изменения бизнеса, которые могут повлиять на применение льгот.
Трудовые отношения, работа с самозанятыми, передача интеллектуальных прав, коммерческая тайна, увольнение ключевых сотрудников — это также постоянные процессы, а не набор разовых документов.
По мере усложнения продукта появляются эквайринг, платежные агенты, номинальные счета, разделение платежей, банки и другие участники.
Изменение движения денег часто означает изменение всей юридической архитектуры продукта.
Новые рекламные механики, рассылки, блогеры, акции, партнерские программы — еще одна зона, где юридическая функция должна быть встроена непосредственно в бизнес-процесс.
Зрелая функция предполагает, что компания заранее понимает:
кто принимает запрос;
кто должен быть уведомлен;
как собирается информация;
кто принимает решение;
где сохраняется позиция компании;
что необходимо изменить после завершения ситуации.
Одна из основных проблем реактивной модели — юрист узнает об изменении слишком поздно.
Компания уже разработала новую функцию.
Маркетинг уже подготовил механику акции.
Product изменил пользовательский путь.
Финансы договорились с новым платежным партнером.
А после этого возникает вопрос: «Юристы, посмотрите, все ли здесь нормально».
У зрелой юридической функции должен работать change management.
Определенные события автоматически становятся триггерами для legal review:
Тогда юридическая функция перестает быть последней инстанцией перед запуском и становится одним из участников проектирования решения.
В "Зарцын и партнеры" при комплексном сопровождении IT-компаний мы используем модель, при которой первые месяцы работы делятся на несколько этапов.
Недостаточно получить от клиента папку с договорами.
Необходимо понять:
На этой основе формируется карта юридической функции и определяются наиболее критические риски.
Следующий этап — закрытие наиболее существенных рисков.
Это могут быть:
Одновременно появляются первые шаблоны и чек-листы.
Третий этап — переход от решения отдельных вопросов к накоплению системы.
Создаются:
Компания начинает получать не только ответы юристов, но и собственную юридическую инфраструктуру.
Еще одна распространенная проблема — юридическая экспертиза хранится в головах конкретных людей и в переписке.
Например, полгода назад компания подробно разбирала определенную модель работы с партнерами. Был звонок с CEO, CFO и юристами, принималось решение, обсуждались риски.
Проходит несколько месяцев — возникает похожий вопрос.
Если решение существует только в Telegram или старой переписке, исследование фактически начинается заново.
Поэтому юридической функции нужна база знаний.
В ней могут находиться:
Ответы на регулярно возникающие вопросы бизнеса.
Алгоритмы принятия решений в ситуациях, где недостаточно ответа «можно / нельзя».
Например, плейбук проверки договора или работы с самозанятыми.
Последовательность обязательных действий: запуск продукта, рекламной акции, оформление разработчика, получение запроса государственного органа.
Только актуальные утвержденные версии документов.
Зафиксированная позиция компании:
что решили;
почему;
какие риски приняли;
когда необходимо пересмотреть решение.
Таким образом, юридическая экспертиза постепенно становится активом самой компании.
Абонентское юридическое сопровождение часто продают количеством часов.
Для расчета стоимости это удобно.
Но для оценки результата — недостаточно.
Представим две ситуации.
В первой юристы каждый месяц тратят 30 часов на проверку однотипных договоров.
Во второй после нескольких месяцев работы создан шаблон, разработан плейбук, определены допустимые отклонения, часть проверок автоматизирована — и на тот же процесс требуется пять часов.
Если смотреть только на часы, кажется, что во втором случае юридическая поддержка стала менее ценной.
На самом деле произошло обратное.
Компания получила работающий процесс и снизила стоимость повторяющейся юридической операции.
Поэтому отчетность юридической функции должна показывать прежде всего результат:
А детализация часов становится лишь одним из уровней отчета.
Создание юридической функции не обязательно означает найм большого юридического департамента.
На практике возможны разные модели.
Подходит компаниям, в которых собственной юридической команды пока нет.
Внешние юристы фактически становятся юридической функцией бизнеса.
В компании есть один или несколько внутренних юристов, а внешняя команда помогает строить процессы и берет сложные или специализированные блоки.
Для растущих IT-компаний это часто одна из наиболее эффективных моделей.
На внешнюю команду можно передать постоянный юридический контур: например, договорную работу, продуктовые вопросы, персональные данные или regulatory.
Главный вопрос в любом случае не в том, где физически работает юрист.
Главный вопрос — существует ли система управления юридическими процессами.
Есть простой тест.
Попробуйте ответить на несколько вопросов:
Можно ли быстро понять, какие юридические риски сейчас открыты?
Есть ли карта юридических процессов компании?
Понимает ли product, в какой момент необходимо подключить юриста?
Есть ли единая актуальная версия ключевых договоров и политик?
Фиксируются ли важные юридические решения?
Существуют ли плейбуки по повторяющимся задачам?
Контролируются ли обязательные сроки и специальные статусы?
Может ли новый юрист за несколько часов понять, как устроена юридическая работа компании?
Если на большинство вопросов ответ отрицательный — скорее всего, компания пока управляет отдельными юридическими задачами, а не юридической функцией.
Для растущей IT-компании юридическая функция должна становиться такой же управляемой частью бизнеса, как финансы, product или HR.
Юрист не должен появляться только тогда, когда требуется очередной договор или уже возник конфликт.
Зрелая модель работает иначе:
понимание бизнеса → карта процессов → юридические контрольные точки → ежедневная работа → накопление знаний → стандартизация → автоматизация → измеримый результат.
Именно поэтому вопрос «сколько часов юридической поддержки нам необходимо?» постепенно стоит заменить другим:
«Какую юридическую функцию необходимо построить компании на следующем этапе роста?»
17 сентября ZARLAW проведет вебинар «Юридическая функция IT-компании: задачи, процессы и система управления».
На нем мы подробно разберем архитектуру юридической функции, первые 90 дней ее построения, плейбуки, базу знаний, автоматизацию и варианты организации внешней и внутренней юридической поддержки.
Регистрация:https://zarlaw.timepad.ru/event/4149965/
Если вы хотите обсудить построение и абонентское ведение юридической функции вашего IT-проекта: напишите нам