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

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

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

Например, Toyota GR86 и Subaru BRZ имеют общую технологическую базу и были разработаны совместно, но каждая компания придала своей модели свой характер и особенности управления — Toyota акцентировалась на эмоциях и выпустила своеобразный спорткар для ценителей, а Subaru сделала упор на классические преимущества машины — управляемость, технологичность и так далее

Другой яркий пример — это внедорожник Isuzu Trooper. На протяжении своей истории он продавался более чем под десятью брендами по всему миру: Acura, Honda, Chevrolet, Opel, Vauxhall, Holden, Subaru и другие. Для покупателя это были автомобили разных производителей, хотя в основе лежала одна и та же модель. Менялись логотипы, оформление и позиционирование, но не сама технологическая основа.

Современная структура мирового автопрома такова, что производители готовых автомобилей могут не производить ничего, кроме собственных кузовов. Например, все производители грузовиков Евросоюза, за исключением Volvo Trucks, используют коробки передач марки ZF, а, например, практически все грузовики США, вообще, представляют собой своеобразный «конструктор», где сам производитель машины изготовляет только раму и кабину, а все остальные компоненты поступают от разных специализированных фирм. Отсюда нередки случаи, когда два американских автомобиля разных брендов имеют до 95% общих комплектующих.

В мире корпоративного ПО происходит ровно то же самое. Только вместо двигателей, подвески и коробки передач здесь код, архитектура и ядро.

Почему переиспользование стало нормой

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

Другие на этой основе строят продукты — со своей историей, позиционированием, маркетинговой наполненностью для дальнейшей продажи.

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

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

Поэтому здесь появляются две модели, которые часто путают между собой — White Label и OEM.

White Label: готовый продукт под своим брендом

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

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

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

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

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

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

White Label: завод по сборке автомобилей

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

Выпуская новый релиз или исправление, вендор поставляет все ключевые «узлы» платформы в готовом виде, те самые двигатели, коробки передач, тормозные системы и другие компоненты. 

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

Компания, купившая White Label, не инвестирует годы в разработку собственной BI‑платформы, но при этом получает собственный конвейер выпуска продукта, соответствующего своей корпоративной архитектуре.

OEM: когда покупают не автомобиль, а двигатель

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

Хорошей автомобильной аналогией может служить использование технологий одного производителя в авто другого. Например, Aston Martin комплектуются 4,0-литровыми битурбо V8 двигателями производства Mercedes‑AMG, которые компания Aston Martin дорабатывает, настраивая фирменный выхлоп и отдачу.

При этом никто не воспринимает Aston Martin как «Mercedes с другим шильдиком», это совершенно другой автомобиль со своей конструкцией, дизайном, настройками и вайбом Джеймса Бонда.

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

Например, у компании уже есть собственный программный продукт — информационная система, ERP, отраслевое решение, платформа управления производством или любой другой специализированный продукт. В какой‑то момент в нем появляется потребность в развитой аналитике. Разрабатывать ее с нуля — все те же годы разработки, команда специалистов и деньги. Гораздо проще купить готовый аналитический модуль и встроить его в свое решение.

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

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

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

Самое сложное начинается после первого работающего дэшборда

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

Open source‑компоненты, готовые библиотеки, современные инструменты разработки позволяют достаточно быстро получить работающий результат. И с развитием ИИ этот порог действительно стал еще ниже.

И ответ — да, действительно это возможно.

Можно подключить источники данных, построить несколько графиков, добавить фильтры и довольно быстро получить продукт, который внешне уже напоминает BI. Но сделать так, чтобы через пять лет он продолжал развиваться, обновляться и оставаться корпоративной платформой — задача со звёздочкой.

Между работающим прототипом и корпоративной аналитической платформой — целая пропасть. Ведь BI‑система — это не только (и не столько) графики.

Нужно реализовать работу с различными источниками данных и механизмы их подключения. Создать систему подготовки и обработки данных. Разработать API и возможности интеграции с другими корпоративными системами. Сделать конструктор отчетов и систему визуализации.

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

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

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

Написать BI и годами быть вендором BI — две совершенно разные задачи.

К счастью, весь этот путь не нужно проходить самостоятельно.

Есть задачи, которые очень сложно быстро добавить позже

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

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

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

Использование платформы, имеющей сертификат ФСТЭК России по 4 уровню доверия, может существенно сократить путь по сравнению с разработкой продукта с нуля, а также снизить затраты на подготовку платформы к требованиям регулятора.

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

Зрелость платформы складывается из десятков незаметных деталей

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

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

Именно поэтому вместе с White Label получают не только пользовательский интерфейс и набор функций, но и всю инженерную инфраструктуру, которая создавалась и совершенствовалась годами.

Лицензирование, о котором обычно вспоминают слишком поздно

Есть еще одна задача, о которой в принципе редко думают на старте разработки — это лицензирование.

Пока заказчиков немного, управление лицензиями выглядит довольно просто — выписали лицензионный ключ, отправили письмо заказчику и в целом задача решена. Но со временем появляются новые сценарии:

• Одному заказчику нужно увеличить количество пользователей в рамках существующей лицензии;

• Другому добавить новый функциональный модуль;

• Третьему продлить техническую поддержку.

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

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

Licensing as code

В Luxms BI мы решили эту задачу через подход, который назвали Licensing as Code. Его идея достаточно проста — лицензия здесь полноценный цифровой артефакт, с которым можно работать так же, как разработчики работают с кодом.

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

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

«Мы не стали делать еще одну базу данных, отдельные сервисы и лицензионный сервер. Вместо этого применили ту же идею, которая давно используется в разработке: Configuration as Code и Infrastructure as Code, а с ней и проверенные инженерные практики — Git, версионирование и цифровые подписи. Так появилась Licensing as Code.»

Дмитрий Дорофеев, главный конструктор Luxms BI

В контексте White Label и OEM это означает, что вместе с BI‑платформой заказчик получает не только механизм проверки лицензий, но и уже готовую инфраструктуру управления ими.

Вместо того чтобы начинать с нуля

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

Автомобильные компании используют общие платформы и силовые установки — и производят классные, разнообразные машины под потребности каждого водителя.

Производители смартфонов делают устройства на одинаковых процессорах и аппаратных компонентах. И мы, как пользователи, выбираем между конкурирующими Samsung и Apple, не задумываясь, что в разных поколениях iPhone использовались OLED‑дисплеи Samsung, память и другие компоненты.

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

BI постепенно движется по тому же пути.

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

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

---

Luxms BI — платформа, которая позволяет оптимизировать процессы, расходы, а также упростить и масштабировать работу с аналитикой в компании за счет self‑service подхода и найти точки роста для компании за счет прогнозной и расширенной аналитики.