Что такое бизнес архитектура

Что такое бизнес-архитектура Компании?

Бизнес-архитектура предприятия – это целостная и интегрированная модель фирмы, которая связывает стратегические, структурные, информационные, технологические и операционные аспекты Компании.

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

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

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

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

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

Для более подробной информацией обратитесь к команде SILA UNION, мы с удовольствием ответим на вопросы, продемонстрируем возможности.

Источник

Содержание

Бизнес-архитектура

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

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

А преимущества от построения таких моделей лежат в двух плоскостях: дополнительных возможностях для бизнеса и уменьшении затрат. По оценкам, создание бизнес-моделей и связанная с этим оптимизация затрат даже без радикальных изменений бизнеса может дать до 10% экономии.

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

Принципы, модели и стандарты

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

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

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

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

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

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

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

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

Примеры декларируемых принципов в области ИТ-инфраструктуры:

Примеры принципов в области управления данными:

Примеры принципов, связанных с прикладными системами:

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

При разработке и использовании стандартов следует учитывать нижеперечисленные аспекты:

Источник

Архитектура системы и Бизнес-архитектура

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

Архитектура и строительные конструкции

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

Строительный проект состоит из двух основных частей: архитектурно-строительной и инженерной.

Архитектурно-строительная часть проекта включает:

… место для размышлений …

Архитектура системы

Теперь рассмотрим определение, которые ближе к IT. За основу возьму выдержки из статьи.

Архитектура – фундаментальные понятия или свойства системы в ее окружении, воплощенные в ее элементах, отношениях и принципах ее проектирования и эволюции. (Из: ISO/IEC/IEEE 42010:2011)

Архитектура – это проектные решения, которые тяжело изменить. (Мартин Фаулер)

Однако, существует тонкость с характеристикой «тяжело изменить».

Предположим, у вас есть проектное решение, которое описывает для ваших разработчиков, как они должны структурировать свой код на Java. Если у вас есть много кода, для изменения всего этого кода из одной структуры в другую потребует много работы. Другими словами, это тяжело. Следовательно, это выбранное решение является «архитектурой», в данном случае программной архитектурой. Но один разработчик может легко проигнорировать это решение и написать код, который делает всё по-другому. В конце концов, вносить «изменения» в программное обеспечение легко. Хотя всю реализованную архитектуру изменить тяжело, в ней часто достаточно легко можно изменять только отдельные части.

Нет никакой теоретической причины, что что-то трудно изменить в отношении программного обеспечения. Если вы выбираете какой-либо один аспект программного обеспечения, вы можете легко изменить его, но мы не знаем, как сделать всё легко изменяемым. Сделать что-то легким для изменения — делает общую систему немного сложнее, а сделать всё легким для изменения — делает всю систему очень сложной. (Ральф Джонсон)

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

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

Проблема

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

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

… место для размышлений …

Большая часть системных архитекторов вышло из программистов, они все технократы. Это всё придумали они. 🙂
При работе с архитектурой лучше сфокусироваться на назначение Системы.

Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.

Это проектное решение, которое колеса, двигатель, корпус и рулевое управление организует в автомобиль.

Другими словами, Архитектура – это проектное решение, которое дает эффект эмерджентности. Эмерджентность — появление у системы свойств, не присущих её элементам в отдельности; несводимость свойств системы к сумме свойств её компонентов.
Важно не смешивать уровни абстракции. Также позже, может возникнуть вопрос, что такое хорошая архитектура? Архитектура должная обеспечивать реализацию трех основные атрибутов качества системы: надежность, эффективность, гибкость. Есть и другие, например, масштабируемость, тестируемость, ремонтопригодность и др., но они не всегда так важны.

Бизнес-архитектура

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

Для описания основы бизнес-архитектуры, как любой другой архитектуры, используются три аспекта:

Концепция «Три вида деятельности»

Существуют три вида деятельности:

Концепция «Циклы Деминга»

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

Посмотрим нашу конкретную проектную работу, производство продукта или оказание услуги:

Концепция «Принятие решения»

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

Давайте сопоставим эту концепцию с нашими проектами:

Принцип «Целевое назначение должно определять архитектуру»

Тут важно напомнить определение архитектуры:

Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.

Целевым назначением обычно является основная деятельность. Управляющая деятельность направлена на основную деятельность. Поддерживающая деятельность обеспечивает ее.

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

Принцип «Архитектура должна соответствовать руководству»

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

Возможен внутренний конфликт.

… место для размышлений …

Определение Бизнес-архитектуры

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

Из существующих определений мне нравится, которое дала группа Architecture Board Special Interest Group (BASIG) (Специальный совет по архитектуре OMG)

A Blueprint Of The Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.

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

Архитектор

Если дать нормальное понятие архитектуры, то роль архитектора становится предельно понятной.

Задача сапожника изготавливать и ремонтировать обувь.

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

Какими компетенциями он должен обладать?

Архитектор должен знать архитектурные принципы и концепции на своем уровне бизнеса или системы, это его hardskills.

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

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

Источник

Методы архитектуры предприятия

В рамках урока поговорили:

об обоснованных структурных изменениях в компании в быстро меняющихся условиях;

о применении архитектурного подхода в вопросах трансформации;

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

В будущем Курс «Enterprise Architect» будет построен таким образом, что мы сформулируем бизнес-кейс для трансформации и далее последовательно будем его решать, чередуя теоретические и практические занятия.

Зачем нужна цифровая трансформация?

Понятно, что цифровая трансформация в различных индустриях продиктована разными причинами и по-разному воплощается.

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

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

Почему это происходит?

Имеют место два фактора:

Меняются клиенты, меняется рынок. Рынок становится более быстрым. Клиенты становятся более разборчивыми и требовательными.

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

И в совокупности эти факторы требуют совершенно другого от бизнеса.

Если очень коротко сформулировать идею, то в наиболее выгодном положении будет тот, кто займет место между клиентом и его решением. То есть компания, которая как бренд будет сопровождать клиента на всем его пути, и непосредственно решать его задачи end to end (от начала до конца) в той мере, в какой это возможно/необходимо.

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

Что такое цифровая трансформация, как ее измерить?

1. Неисчерпаемый перечень.

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

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

2. Скорость внедрения изменений

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

Гибкость платформы (насколько платформа поддерживает Devops, Agile Development, гибкое выделение инфраструктуры).

3. Данные dеitadreavon

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

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

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

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

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

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

6. Быть актуальными

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

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

Также фундаментом любой архитектуры являются такие параметры:

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

Поговорив о сути и направлении цифровой трансформации, следует рассказать о том, как и где принимаются решения?

с одной стороны, достаточно структурированной и системной;

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

также важна коммуникация.

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

Таким образом, если ты хочешь внести улучшение в компании:

ты знаешь, как эту идею структурировать.

Хорошо представить идею;

Понимать, каким образом компания примет решение о том, что эта идея будет запущена или не будет.

Как устроено принятие решения об изменениях в организации.

Любое изменение – это выделение бюджета.
Любое выделение бюджета – это инвестиции.

Бюджет может выделяться:

Напрямую, комитетом, в виде какой-то суммы;

Косвенно, когда есть команда работающая над каким-то направлением и она принимает решение об инвестициях. Куда направить свое время.

Важно понимать, какая «фича» более актуальна, более приоритетна, с учетом текущих ограничений, текущих планов.

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

Процесс, формирующий общий портфель изменений

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

Инвестиционная стратегия. Склонность к риску. Насколько мы готовы экспериментировать. Насколько консервативны при отборе решений, в которые мы вкладываем деньги.

Инвестиционный процесс. Жизненный цикл, последовательность шагов, как эти инвестиционные решения принимаются. Это уровень спонсора любой инициативы.

Исполнение портфеля. Управление результативностью портфеля. Качество проектной деятельности. Метрики, попадание в сроки.

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

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

Заглядываем и видим портфель изменений.

Смотрим на результативность портфеля с точки зрения обратной связи. (сдвигаются /не сдвигаются сроки, что меняется).

Участвуем в инвестиционном процессе.

TOGAF – достаточно старый стандарт, которому больше 20 лет. Пережил несколько реинкарнаций, без существенных изменений.

The Open Agile Architecture – новый стандарт. Как заниматься архитектурой в agile среде.

Почему именно ADM (Architecture Development Method)?

Стандарт Тogaf, достаточно громоздкий. Мало кто им пользовался, как методическими указаниями. Однако, помимо того, что он содержит ряд здравых базовых мыслей, связанных с декомпозицией, в нем есть жизненный цикл архитектуры предприятия, цикл разработки архитектуры. Если мы пойдем в agile без понимания этой логической последовательности действий, то можем потерять саму архитектуру.

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

Мы не будем заострять своё внимание на предварительной фазе и сразу перейдем к жизненному циклу:

A. Видение архитектуры. Исходя из того куда движется компания, понимание того, где мы находимся и куда мы хотим прийти, какой наша организация должна стать.
B. Бизнес-архитектура. Более структурированный анализ. Как должен быть устроен наш бизнес. Как должна эволюционировать наша бизнес-модель, и операционной модель.
C. Архитектура информационных систем.
D. Техническая архитектура. Как это реализуется технологически.
E. Возможности и решения. Какие технические решения нам нужны, чтобы реализовать функции в тех приложениях, которые мы у себя заложили, или которые решили развивать.
F. Планирование миграции. Планируем переход из состояния А, в состояние Б.
G. Управление реализацией. Как некая дорожная карта изменений компании последовательно/параллельно. Важно следить за отклонениями реализации от видения, архитектуры движения, которые мы нарисовали ранее.
H. Управление изменениями архитектуры. Любое событие, которое возникает в реальном мире, может повлиять на наше понимание организации, понимание того, куда эта организация должна двигаться.

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

Последовательность действий

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

Анализ бизнес-архитектуры

Первый шаг – это разработка бизнес-архитектуры в какой-то области. Бизнес-архитектура – это не только ландшафт бизнес-процесса.

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

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

В центре, в ядре бизнес-архитектуры находится – Сapability. Возможности, бизнес-компетенция организации, что организация умеет делать, как некий объект.

Value Streams – потоки ценности. Фундаментальные вещи, о том как организация доставляет ценность? Как организация работает? В чем ее бизнес состоит?

Information – то как элементы бизнес-архитектуры связаны с архитектурой информационной.

Organization – привязка всего к организационной структуре.

Vision, strategy, and tactics – мотивация компании. Видение стратегии, куда компания движется.

Stakeholder – лица, принимающие решения.

Policies, Rules, Regulations – политики.

Products & Services – продукты и услуги, то есть то, что на витрине перед клиентом.

Initiatives & Projects – инициативы и проекты, то есть объекты изменений.

Metrics & Measures – показатели. То, как мы это мерим.

Начать лучше всего с capability (компетенции).
Под компетенциями понимается совокупность:

методологий и подходов;

Компетенция – это возможность организации делать что-то.

ПРИМЕР:

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

Здесь мы видим, что на одной картинке объединены четыре сущности.

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

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

Для того чтобы реализовать этот процесс, нужно:

уметь реализовать функционал регистрации согласования компании;

должна быть реализована настройка;

должно быть моделирование;

анализ хода компаний;

обработка коммуникации в каналах коммуникаций.

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

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

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

Информационная архитектура

Для чего она нужна?

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

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

На этом уровне, пока мы не выделяем контексты, пока мы описали всю информацию, важно понимать:

какие объекты есть;

кто за них отвечает;

как эти объекты появляются и потребляются в рамках потока ценностей.

Что мы видим на рисунке?

Контекст продаж:

Источник