Кастомные решения что это

Новые требования клиентов. Кастомизация в интернет-маркетинге и IT

Ещё пару десятилетий назад мы радовались любым нововведениям в компьютерной сфере и могли свыкнуться с любыми неудобствами программ. Сейчас каждый пользователь может высказать своё недовольство по поводу работы с сервисом. Одному будет не нравиться одно, второму ― другое. Вместо того чтобы угодить всем, разработчики стараются сделать интерфейс и наполнение программ изменяемыми. И для такого подхода есть свой термин ― кастомизация. Итак, что такое кастомизация?

Что значит кастомизация

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

Яркий пример кастомизации ― изменение кроссовок. Очень популярно покупать какую-либо модель кроссовок и модернизировать её на своё усмотрение (менять цвет, наносить рисунки).

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

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

Интернет-магазины и расширение возможностей кастомизации

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

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

Есть множество примеров массовой кастомизации среди марок, производящих одежду и обувь, но нам кажется, что дальше всех в этом деле убежали фастфудные заведения, а именно, пиццерии и бургерные. Если вы зайдёте на сайт или в приложение Mcdonalds, KFC или Burger King, вы увидите, что при заказе бургера можно убрать почти все составляющие бутерброда или, наоборот, удвоить каждый ингредиент. То же самое и с пиццей. Что Papa John's, что Dodo Pizza также предлагают убрать или добавить ингредиенты. Если вы с друзьями или со второй половинкой не можете решить, что заказать, то можно слепить две пиццы в одну и наслаждаться двумя вкусами.

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

Задачи кастомизации в компьютерных технологиях

Задачи кастомизации в товарной сфере немного отличаются от целей кастомизации в IT. Когда потребитель покупает кастомизированные кроссовки, он думает не об удобстве, а в первую очередь о том, как он будет выделяться среди других пользователей кроссовок. За эксклюзив человек готов платить больше, поэтому на обычном рынке кастомизацию используют как маркетинговый приём, который позволяет значительно поднять ценник на товар. Также в сфере розничных продаж кастомизация может стать УТП (уникальным торговым предложением). «Конкуренты всех под одну гребёнку гребут, а мы учитываем интересы каждого», ― говорит глава маркетингового отдела.

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

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

Разница между кастомизацией и персонализацией

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

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

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

Рассмотрим на примере электронной почты. Во многих почтовых программах вы можете менять фон интерфейса, ставить фильтры на письма, менять порядок элементов в меню. Каждая из таких настроек и есть кастомизация. Ещё один простой, но распространённый вариант кастомизации ― тёмная и светлая тема интерфейса. Такой выбор предлагают YouTube, VK, Яндекс.Браузер. Каждый пользователь сам решает, какую тему выбрать, пусть с выбором сильно не разгуляешься. Для тех, кто знаком с панелями управления хостинга, вариант с темами можно встретить в cPanel. В настройках есть возможность выбрать одну из 5 вариантов тем интерфейса. Вот для примера две из них:

Плюсы и минусы внедрения кастомизации в интернет-маркетинге и IT

Из плюсов можно выделить:

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

Минусы тут тоже найдутся:

• Дорого, дорого, дорого. Мы говорили выше, что эксклюзив нельзя создавать в среднем ценовом сегменте. Массовая кастомизация хоть и предлагает выбор по схожей для потребителя цене, однако товары-конструкторы всё же дороже обычного массового товара.
• Время производства кастомной модели больше. Серийное производство ― это чётко налаженный конвейер. Каждое действие сотрудника и техники рассчитано до секунды. Когда каждый товар создаётся индивидуально (даже если речь идёт о конструкторе), производство должно постоянно подстраивать свои процессы под заказ.
• Всегда будет бестселлеры и неликвид. Если у вас несколько цветов для футболок, всегда один цвет будет очень востребован, а другой придётся продавать на распродаже. Любители пиццы с перчиком халапеньо будут рады возможности добавить больше остроты, но вряд ли желающих такое сделать будет больше, чем любителей двойного сыра.
• Потребителя мучают муки выбора ещё больше. На некоторые покупки, даже не самые дорогие, клиенты решаются неделями. Когда выбор намного разнообразнее, времени, чтобы решиться на покупку, потребуется ещё больше.

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

О кастомизации информационных систем

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

Возможные подходы

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

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

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

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

• Entity — хранит ссылку на объект, поле которого мы описываем. Обычно это идентификатор сущности;
• Attribute — ссылка на определение атрибута (об этом ниже);
• Value — собственно значение атрибута.

• тип атрибута;
• ограничения (длина поля, регулярное выражение, которому должно соответствовать значение и пр.);
• компонент для отображения в UI;
• порядок отображения компонента в UI.

1. Реализовать механизм задания метаданных, с помощью которого мы сможем, например, указать, что к сущностям типа “Договор” добавится новый атрибут «Дата расторжения», тип поля — «Дата», компонент для отображения — DateField.
2. Реализовать механизмы отображения и ввода значений динамических атрибутов на необходимых экранах продукта. Механизм должен находить возможный набор атрибутов для данной сущности в таблице с описанием метаданных, отображать компоненты для их редактирования, а затем в таблице с данными искать и отображать их значения, сохраняя их при закрытии экрана.

Далее о недостатках. Во-первых, это ограниченность применения. Модель EAV позволит лишь добавить атрибуты в сущность и отобразить их в заранее определенном месте на экране. Не более того. Об изменении функциональности, хитрых UI-компонентах здесь речи не идет.

Во-вторых, EAV модель создает большую дополнительную нагрузку на сервер БД. Для загрузки одного экземпляра сущности без связей потребуется чтение вместо одной нескольких строк таблицы. Для загрузки списка экземпляров, например в таблицу на UI, вообще потребуется N+1 запросов, либо джойны по числу колонок таблицы. Учитывая, что база данных в корпоративных системах и так чаще всего является самым медленным и плохо масштабируемым элементом, такая дополнительная нагрузка может просто убить систему.

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

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

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

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

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

Как это делаем мы

Мы выпустили на рынок два тиражируемых продукта: ECM (или в более привычных терминах, систему электронного документооборота, СЭД) ТЕЗИС и систему для автоматизации бизнеса такси Sherlock. С самого начала было очевидно: для того, чтобы поставить конкретному клиенту максимально удобную систему, потребуются доработки продукта, и следовательно в основе продукта должна лежать легко расширяемая архитектура.

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

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

Как же мы решаем проблему создания и поддержки расширений?

Наш проект-расширение

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

• cuba — ядро приложения, содержит в себе всю инфраструктуру, средства для организации бизнес-логики, библиотеку визуальных компонентов, подсистему безопасности и пр.
• reports — подсистема генерации отчетов
• fts — подсистема полнотекстового поиска
• charts — подсистема вывода диаграмм
• workflow — подсистема управления бизнес-процессами
• ccpayments — подсистема работы с кредитными картами

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

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

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

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

• вы указываете новую версию продукта в скриптах сборки и пересобираете расширение;
• если в расширении использовался только стабильный API продукта, то на этом все — запускаете свой расширенный продукт и вперед;
• если в продукте произошли значительные изменения в тех точках, которые вы расширяли, то может потребоваться изменение кода расширения. Как правило, это происходит нечасто, и локализовать проблему просто. Багфикс-релизы продуктов всегда сохраняют совместимость с расширениями.

Добавление нового атрибута в сущность базового продукта

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

Как видите, это стандартное для JPA описание сущности и маппинга на таблицу и колонки БД.

Создаем наследника сущности в проекте-расширении:

Механизм наследования стандартен для OpenJPA за исключением аннотации @Extends , которая и представляет наибольший интерес. Именно она объявляет, что класс ExtUser будет повсеместно использоваться вместо класса User.

Теперь все операции создания сущности User будут создавать экземпляр расширенной сущности:

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

Без аннотации @Extends мы имели бы на выходе коллекцию объектов User , и для получения адреса из ExtUser пришлось бы повторно перечитать из базы результат предыдущего запроса. Но используя информацию о переопределении, которую предоставляет аннотация @Extends , механизмы платформы произведут предварительную трансформацию запроса и вернут нам коллекцию объектов расширенной сущности ExtUser . Более того, если какие-то другие сущности имели ссылки на User , то при подключении расширения эти ссылки будут возвращать объекты типа ExtUser , без какого-либо изменения исходного кода.

Сущность переопределена. Теперь хорошо бы отобразить новое поле пользователю.

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

Видим ссылку на контроллер экрана UserEditor, объявление источника данных (datasource), компонента fieldGroup, отображающего поля сущности, и фрейм со стандартными действиями “ОК” и “Отмена” (windowActions).

Совсем не хочется дублировать код базового экрана в проекте-расширении, поэтому мы добавили в платформу возможность наследования XML-дескрипторов экранов. Вот так выглядит наследник экрана из базового проекта:

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

Переопределение бизнес-логики

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

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

Создаем наследника переопределяемого компонента:

Регистрируем класс в конфигурационном файле Spring с идентификатором бина из базового продукта:

Теперь контейнер Spring будет всегда возвращать нам экземпляр ExtPriceCalculator.

Переопределение темы

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

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

Для реализации веб-UI нами был выбран популярный фреймворк Vaadin. Vaadin позволяет описывать темы на SCSS. Описание стилей для новой темы на SCSS само по себе в разы приятнее, чем на чистом CSS. Мы сделали процесс создания темы еще менее трудоемким, вынеся множество параметров в переменные.

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

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

Примеры различных визуальных тем:

Заключение

Если наш подход показался вам интересным, то можете попробовать платформу CUBA сами. Создавая продукт на платформе, вы автоматически получаете возможность кастомизировать его описанным способом. Всегда рады отзывам и комментариям!

Кастомный – что это такое, что это обозначает простыми словами

Узнайте, что такое “Кастомный” простыми словами

Довольно часто в сети или в разговоре между людьми проскальзывают слова, значение которых абсолютно не понятны. Одним из является распространённый термин “кастомный”. Это слово позаимствовано из английского языка, в оригинале оно пишется так “custom“. В переводе оно имеет несколько значений:

• Обычаи, традиции.
• Привычки.
• Клиенты, заказчики.
• Товар созданный по индивидуальному проекту.

Если писать во множественном числе – ” customs”, то это обозначает таможенные пошлины. Наиболее распространённый смысл этого слова, обозначает все сделанное по отдельному проекту, в котором отсутствует серийность и стандартные черты.

Наиболее ходовым это выражение встречается в связке с оружием (ножами), телефонами, одеждой или мототехники.

Одежда

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

Кастомное оружие

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

Что входит в понятие кастомный нож:

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

Программные решения

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

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

Плюсы прошивок:

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

Минусы кастомных прошивок:

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

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

Мото-кастом

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

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

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