Программное обеспечение в корпоративных группах — правила использования и учёта
У меня есть маленькая профессиональная привычка: когда попадаю в большую корпоративную группу (холдинг, «дочки», общие сервисные компании, филиалы), я первым делом спрашиваю не про штат и не про продажи, а про программное обеспечение. Обычно на секунду повисает пауза, потому что у людей в голове ПО это «айтишное», а я вообще-то про интеллектуальную собственность и риски. Но в реальности именно программное обеспечение компьютера внезапно решает, будет у вас спокойный аудит или весёлый квест с объяснительными, почему на бухгалтерском ПК стоит «что-то похожее на фотошоп», а лицензии никто не видел со времён динозавров.
И ещё один сюжет, почти бытовой. Два юриста в разных компаниях одной группы спорят, можно ли «перекинуть» лицензию с головной на дочернюю. Один уверен: «мы же одна группа». Второй мрачно листает договор и ищет слово «аффилированные лица». Спор заканчивается обычно тем, что в договоре написано не то, что хотелось бы, а в учёте нет понимания, какое программное обеспечение где стоит и кто им реально пользуется. И вот тут начинается взрослая жизнь: легализация ПО, инвентаризация, пересборка доступов, а иногда и неприятные разговоры с безопасниками.
Зачем это всё и что у вас получится
Если сделать правила использования и учёта ПО по-человечески, у группы появляется ясность: какое программное обеспечение закуплено, на каких условиях, где оно установлено, кто отвечает за обновления и что происходит, когда сотрудник увольняется или когда «дочка» переезжает на другой юрлицо. Вы сможете отличать системное программное обеспечение от прикладного программного обеспечения не для галочки, а чтобы правильно разнести затраты и не путаться с правами. А ещё начнёте видеть данные программного обеспечения как актив: где оно помогает бизнесу, а где является дырой в безопасности и в бюджете. И да, станет проще отвечать на программное обеспечение вопросы от бухгалтерии, ИБ и руководства, не превращая это в ночной чат на 80 сообщений.
Пошаговый гайд для корпоративной группы
Шаг 1. Зафиксируйте границы: у кого что и на каком праве
Первое, что делаем: рисуем карту группы не красивую, а полезную. Какие юрлица, какие общие сервисы, где общий IT-отдел, где свой. Затем сразу уточняем права на ПО: это покупка лицензии, подписка SaaS, корпоративная лицензия, OEM на железе, или разработка программного обеспечения по договору (а значит, ещё вопрос, у кого исключительные права). Зачем это нужно: в корпоративных группах чаще всего ломается именно логика «мы же вместе», а договоры у поставщиков обычно мыслят иначе. Типичная ошибка тут простая: считают, что если оплатило головное юрлицо, то использовать могут все. Проверка: открываем лицензионные условия и ищем, разрешено ли использование аффилированными лицами, на какой территории и на каком количестве устройств или пользователей.
Мини-кейс: у клиента была сеть складов в Подмосковье и Татарстане, три юрлица и общий IT. Внезапно выяснилось, что часть подписок на систему программного обеспечения для управления задачами оформлена на одного сотрудника через корпоративную карту. Сотрудник ушёл, доступ восстановили через поддержку за два дня, но права на аккаунт так и висели «на физике». Мы за неделю перевели владение на корпоративный домен и прописали, кто админ со стороны группы. Эффект был не героический, а тихий: просто перестали зависеть от чужой почты и от настроения саппорта.
Шаг 2. Инвентаризация: что реально стоит и где это живёт
Дальше неприятная, но нужная часть: собираем фактическую картину. Не «по словам ИТ», а по устройствам, серверам, виртуалкам и пользовательским учёткам. Тут важно разделить системное программное обеспечение (операционные системы, драйверы, базовые компоненты) и прикладное программное обеспечение (офисные пакеты, бухгалтерия, CAD, CRM, всё, чем люди пользуются каждый день). Зачем: в учёте и рисках это разные звери, и они по-разному лицензируются. Типичная ошибка: инвентаризацию делают один раз «для галочки», а через месяц половина данных уже устарела, потому что ноутбуки мигрировали между юрлицами, а люди ставили «временно нужную утилиту».
Как проверить, что всё работает: инвентаризация должна сходиться в трёх точках. Первая: список активных устройств и пользователей. Вторая: список установок/подписок. Третья: документы на приобретение и лицензии. Если у вас «по документам 120», «по установкам 170», а «активных пользователей 90», значит, вы где-то переплачиваете, а где-то рискуете. И да, «программное обеспечение ответы» в стиле «оно само поставилось» обычно не проходят даже внутри компании.
Шаг 3. Легализация: вытащить ПО из серой зоны без истерики
Легализация программного обеспечения это не праздник, а плановая гигиена. И смысл не в том, чтобы «кого-то наказать», а в том, чтобы убрать юридические и технические риски. Переход от нелегального ПО к лицензированному снижает вероятность проблем и повышает безопасность системы, это прямо отмечают в материалах про легализацию ПО. Зачем: нелицензионное ПО часто тянет за собой обновления неизвестно откуда и сюрпризы в виде вредоносных модулей. Типичная ошибка: начать «чистку» с запретов, не дав людям альтернативы. В результате получают подпольные флешки и установки «по-тихому».
Проверка тут практичная: после легализации у каждого критичного продукта есть понятный владелец лицензии, понятный способ установки, понятная политика обновлений, и никто не боится писать в ИТ «нужно новое рабочее место». В одной группе мы делали это волнами: сначала бухгалтерия и финансы (потому что там самые чувствительные данные), затем производственные отделы, затем маркетинг. На маркетинге, кстати, всегда всплывает внезапное: «аквалор софт как использовать» или «как использовать софты для докса» в поисковой истории. Я не осуждаю, но в корпоративной сети лучше, чтобы такие желания решались через официальный каталог ПО, а не через приключения.
Шаг 4. Политика использования: простые правила вместо романа на 40 страниц
Теперь пишем правила. Не «Положение о порядке эксплуатации программных средств» (и дальше слёзы), а короткий документ и несколько понятных процессов: кто может устанавливать ПО, как согласовать новое, что нельзя ставить на рабочие компьютеры, как обращаемся с лицензиями, что делаем при увольнении и переводе между юрлицами. Зачем: политика нужна не для красоты, а чтобы пресечь несанкционированные установки и привести всё к стандартам безопасности. Типичная ошибка: написать жёстко и абстрактно, а потом самим же нарушать, потому что иначе «работа встанет».
Проверка: берёте три реальные ситуации и прогоняете по правилам. Первая: сотруднику на удалёнке нужно ПО на личный ноутбук, «только на неделю». Вторая: дочерняя компания просит доступ к подписке, которую оплатило головное юрлицо. Третья: ИТ нашёл на ПК «как использовать софты на пк» из разряда непонятных утилит (а иногда и «как использовать софт шакл», я сначала подумала, при чём тут буксировка, нет, лучше не будем углубляться). Если правила дают понятный ответ и у людей есть куда идти за решением, значит, документ живой.
Шаг 5. Учёт в бухгалтерии: не путать подписку, лицензию и права
Самый частый конфликт происходит между ИТ и бухгалтерией. ИТ говорит: «нам нужно купить». Бухгалтерия спрашивает: «что это вообще, актив, услуга, расходы будущих периодов?» Расходы на приобретение и обслуживание ПО отражаются в бухгалтерском учёте по-разному, в зависимости от права собственности и условий лицензирования, об этом прямо пишут профильные источники по учёту ПО. Зачем: если учёт ведётся на ощущениях, потом сложно объяснить проверяющим, почему у вас «вечная лицензия» оформлена как подписка, или почему оплачивает одно юрлицо, а пользуется другое. Типичная ошибка: не хранить лицензионные договоры и подтверждения прав в одном месте, а потом искать их по чатам и почте.
Проверка: у каждого продукта есть карточка, где видно, кто заказчик, кто плательщик, какой договор, какие условия использования внутри группы, срок, количество пользователей, и где хранится подтверждение права. Да, звучит скучно. Но когда руководитель спрашивает «что у нас стоит на серверах и сколько это стоит в год», вы отвечаете за 15 минут, а не за две недели с красными глазами.
Шаг 6. Централизованное управление: чтобы обновления не делались «по вдохновению»
Если группа большая, «ручной контроль» быстро превращается в театр абсурда. Здесь помогают специализированные системы: от решений управления активами и лицензиями до компьютеризированных систем управления техническим обслуживанием, которые позволяют отслеживать состояние ПО и планировать обновления. В ИТ-мире вообще виден тренд на централизованные механизмы, даже исследования по Linux-дистрибутивам отмечают популярность группового управления пакетами. Зачем: обновления и патчи должны быть предсказуемыми, иначе вы живёте в режиме «в пятницу всё обновили, в понедельник пол-офиса не работает».
Типичная ошибка: включить централизованное управление только для серверов, а рабочие станции оставить как есть. Потом ловят зоопарк версий, особенно на ноутбуках топов и региональных офисов. Проверка простая: вы можете показать, что критичные обновления раскатываются по регламенту, и что исключения фиксируются, а не живут в голове у одного админа. Мини-кейс: у группы из девяти юрлиц обновления офисного пакета делали «когда руки дойдут». Мы договорились о двух окнах в месяц, настроили автопилот и список исключений для бухгалтерии на период сдачи отчётности. Через два месяца количество обращений «после обновления пропала кнопка» стало заметно меньше, и это, честно, уже счастье.
Шаг 7. SaaS и ERP: когда софт не у вас, но ответственность ваша
Многие компании уходят в SaaS, корпоративное ПО как услуга: меньше возни с серверами, проще обновляться, быстрее запускать новые филиалы. Но с точки зрения прав и контроля это не «облако всё решит», а новый набор вопросов. Где хранятся данные программного обеспечения, кто администратор, как выгружаются данные при расторжении, можно ли дочерним компаниям использовать один аккаунт или нужен раздельный контур. Плюс всё чаще учет ПО интегрируют с ERP-системами, где уже можно привязать лицензии к подразделениям и затратам. Зачем: чтобы подписки не превращались в «чёрную дыру», где каждый отдел покупает одно и то же, а потом годами забывает отменить.
Типичная ошибка: «раз это подписка, то юридически всё просто». На практике подписка часто сложнее лицензии: условия меняются, тарифы скачут, права доступа расползаются. Проверка: у вас есть понятный регламент, кто создаёт пользователей, кто выдаёт роли, кто подтверждает оплату, и как вы проводите ревизию хотя бы раз в квартал. И ещё момент: если группа разрасталась через покупки, часто нет данных как использовать софты «по-единому», потому что в каждой бывшей компании свои привычки и свои любимые сервисы. Это нормально, просто лучше признать и аккуратно приводить к общему знаменателю, а не ломать через колено.
Подводные камни, где чаще всего ломается
Первый провал всегда человеческий: «поставил на минутку», «скачал триал», «у меня дома работало». Внутри корпоративной группы это размножается быстрее, чем котики в подъезде. Особенно если нет простого пути получить нужное ПО легально и быстро. Я видела истории, где отделу продаж срочно нужен был конвертер документов, а согласование покупки занимало две недели. Результат предсказуем: «как использовать софты для докса» и установка чего-то бесплатного и странного. Потом ИБ вычищает, ИТ ругается, бизнес злится, виноватых нет. Поэтому скорость легального получения ПО это не каприз, а профилактика хаоса.
Второй камень это «мы одна группа, значит, можно». Нельзя автоматически. Даже если у вас единый бренд и единая стратегия, лицензия может быть привязана к одному юрлицу, к одной площадке, к конкретному числу пользователей или к типу использования. И самое неприятное: иногда поставщик смотрит на «группу» и видит просто несколько клиентов, которые пытаются заплатить один раз. Это не про жадность, это про условия договора. Поэтому лучше заранее выстроить модель: где единый центр закупки, где суб-лицензирование допустимо, где нужен отдельный контракт. И держать эту логику в документах, а не в головах.
Третий камень это учёт и хранение подтверждений прав. Вроде мелочь: акт, счёт, лицензионное соглашение, письмо от поставщика. Но когда через полтора года меняется бухгалтер или ИТ-директор, и вы начинаете пересобирать картину, внезапно выясняется, что «всё было в переписке у Пети». А Петя теперь в другой компании и, честно, ему не до вас. Поэтому место хранения документов и доступ к нему важнее, чем кажется. Это та часть работы, которую никто не любит, но она спасает, когда начинается проверка или конфликт внутри группы.
Где тут интеллектуальная собственность и чем можно помочь без суеты
Когда в группе есть своя разработка программного обеспечения, вопрос «чьё это» перестаёт быть философией и становится бухгалтерским и юридическим фактом. Если продукт пишут внутри, но разработчики оформлены в одном юрлице, а пользуются все, стоит заранее продумать, как оформляются исключительные права, лицензии внутри группы и кто управляет обновлениями. Это экономит время на согласованиях и убирает риск, что ключевой модуль внезапно окажется «не наш», потому что договор с подрядчиком составили на коленке в пятницу вечером.
Если вы параллельно развиваете бренд, продукты, сервисы и хотите, чтобы их не утащили конкуренты или бывшие партнёры, обычно проще жить, когда права и регистрация собраны в порядок. Тут уместны разные форматы поддержки: разовая ревизия портфеля прав, настройка внутреннего регламента по лицензиям и разработке, сопровождение регистрации и защиты. И если хочется держать руку на пульсе новостей и практики, у нас есть Телеграмм канал Патентного бюро Лирейт», там без занудства, но по делу.
Регистрация товарного знака иногда всплывает неожиданно рядом с темой ПО, потому что названия внутренних продуктов, платформ и сервисов у групп часто начинают жить своей жизнью. А если вы строите узнаваемый бренд и хотите «чтобы было по-взрослому», бывает полезно посмотреть и на Монополия на бренд как на концепцию, а не как на лозунг. Для комплексных историй, где смешаны права на код, договоры с подрядчиками и вопросы внутри группы, помогает Юридическая защита интеллектуальной собственности, особенно когда нужно говорить с ИТ и финансами на одном языке.
Хотите защитить свою интеллектуальную собственность, быть в курсе всех новостей? Подпишитесь на наш Telegram-канал
FAQ
Вопрос: Как понять, какое программное обеспечение можно использовать во всех компаниях группы, а какое нет?
Ответ: Открываете лицензионные условия и ищете формулировки про аффилированных лиц, территорию, количество пользователей и допустимые сценарии использования. Если этого нет или написано расплывчато, лучше запросить у поставщика письмо-разъяснение или допсоглашение, иначе внутри группы начнут трактовать «как кому выгодно».
Вопрос: Чем системное программное обеспечение отличается от прикладного в контексте учёта и правил?
Ответ: Системное программное обеспечение это базовый слой для работы компьютера и серверов, а прикладное это то, чем решают бизнес-задачи. Отличие важно, потому что у них разные модели лицензирования, разные требования к обновлениям и часто разный подход в бухгалтерском отражении затрат.
Вопрос: Что делать, если нет данных как использовать софты, потому что в каждой «дочке» свои порядки?
Ответ: Начать с инвентаризации и единого каталога разрешённых программ, а затем прописать минимальные правила: кто ставит, кто согласует, где хранятся лицензии, как проходит обновление. Унифицировать всё сразу обычно больно и бесполезно, лучше вводить общие стандарты по критичным системам и постепенно расширять.
Вопрос: SaaS это проще с точки зрения легальности, чем «коробка»?
Ответ: Проще в части установки и обновлений, но не всегда проще по правам и контролю доступа. В SaaS важно, кто владелец аккаунта, как оформлена оплата, как распределены роли, где находятся данные и как вы их забираете при расторжении.
Вопрос: Кто должен отвечать за учёт лицензий: ИТ или бухгалтерия?
Ответ: Лучше, когда это совместная зона: ИТ держит фактическое использование и технический контур, бухгалтерия отвечает за документы и отражение затрат, а юристы помогают с условиями лицензий и правами внутри группы. Если назначить «одного главного» без процессов, он просто станет крайним.
Вопрос: Почему в группе всплывают странные запросы вроде «как использовать софт шакл» или «софт шаклы для буксировки как использовать», и что с этим делать?
Ответ: Потому что люди ищут быстрые решения, иногда по привычке тянут в рабочую среду то, что видели в личном использовании. Это лечится не запретами на всё подряд, а понятным каталогом разрешённых инструментов и быстрым процессом запроса нового ПО, плюс нормальной работой ИБ на уровне контроля установок.
Вопрос: Если мы заказали разработку программного обеспечения у подрядчика, права автоматически наши?
Ответ: Не автоматически. Всё зависит от договора: что написано про исключительные права, исходный код, модификации, библиотеки, и кто что может делать после сдачи. Лучше проверять это до начала работ, потому что потом исправлять дороже и обычно нервнее.