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

Заметка от партнера IT-центра МАИ и организатора магистерской программы VR/AR & AI компанииPHYGITALISM.

Кратко о BI-системах и их преимуществах

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

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

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

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

Расширяются границы их применения для стратегического и тактического планирования.

Внедрение BI-систем становится все более нужным и прибыльным для компаний.

Рынок BI-систем развивается в сторону кроссплатформенности и внедрения новых подходов к аналитике. Именно поэтому важно понимать, какие тренды сейчас есть.

Тренды в развитии BI-систем: эволюция до ABI

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

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

За все время настолько изменилось представление о BI-системах, что большинство специалистов называют используемые self-service BI-системы (такие как Tableau, Power BI или Qlik Sense) просто BI-системой, хотя различия тут есть в традиционных системах в аналитику были вовлечены IT-специалисты, а в self-service пользователи сами выполняют всю работу, без обращения к IT.

Появление ABI-систем

Эволюция BI-систем не стоит на месте, появляются новые подходы к аналитике, а данных становится все больше именно поэтому возникла новая концепция Augmented Business Intelligence, которую выделили Gartner.

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

ABI это новая ступень развития BI-платформ, так как в ней есть сразу несколько преимуществ. В ней объединяется не только привычная аналитика и таблицы, но и также новые технологии: от дополненной и виртуальной реальности до решений с компьютерной графикой и 3D.

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

Тремя основными тенденциями бизнес-аналитики на 2020 год являются управление качеством данных (MD/DQ), DataViz и внедрение self-service BI-систем, и особое место занимает внедрение data-driven подхода в культуру компаний. Мы стараемся внедрять все эти подходы в наше решение с BI-системой для Ingrad, и хотели бы побольше рассказать о самых интересных, на наш взгляд.

Развитие предиктивной аналитики

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

В этом контексте также говорят о концепции DIKW: Data-Information-Knowledge-Wisdom.

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

BI-системы в этом случае выступают инструментом достижения верхушки пирамиды благодаря визуализации мы можем быстро проанализировать любые данные и информацию для получения знаний. Чтобы получить мудрость мы должны видеть всю ситуацию в пространстве, и здесь может помочь визуализация данных (Data Visualization) и 3D-технологии.

Визуализация данных (Data Visualization, DataViz)

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

Именно поэтому и существует визуализация данных (Data Visualization) ряд инструментов наподобие графиков, таблиц, диаграмм и схем, которые представляют информацию наглядно.

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

Мы все привыкли к 2D-инфографикам, и, да, они прекрасно справляются со своей задачей, но информацию можно донести и более эффективными способами. Во многих случаях 3D-визуализации позволяют передать больше информации об объекте.

Мы считаем, что 3D визуализация данных это не просто тренд, а необходимость для некоторых сфер (AEC, например). Для девелопера на рынке российской недвижимости мы разработали BI-систему аналитики с 3D визуализацией данных, которая намного более эффективна благодаря интерактивности и наглядной демонстрации данных на карте.

3D в BI-системах может использоваться и для визуализации объектов например, BIM-модели зданий помогают быстро получать нужную аналитику и информацию о строительном объекте.

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

Data Storytelling

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

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

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

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

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

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

За какими технологиями нужно следить, чтобы быть в курсе развития BI-систем?

• Искусственный интеллект и машинное обучение для создания системы предиктивной аналитики, расшифровки данных и выявления тенденций

• 3D-технологии для внедрения новых инструментов Data Visualization, показа большего числа данных, в том числе с привязкой к географии

• XR для совместной работы и визуализации аналитики в интерактивном иммерсивном формате.

Заключение

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

Проследив эволюцию BI-систем, тренды и прогнозы развития, которые делают крупные исследовательские компании, выделим целый ряд трендов:

• MD/MQ Data management

• Внедрение data-driven культуры в работу

• Внедрение self-service BI систем

• Data Visualization

• Data Storytelling

• Развитие ABI систем

• Аналитика в real time

• Data warehouse modernization

• Data governance

• Предиктивная аналитика

• Внедрение моделей машинного обучения

• Cloud BI

• Самостоятельная работа с данными

• BI-системы для мобильных устройств

• Добавление и совершенствование уведомлений в BI-системах

Можно сделать вывод, что общая тенденция в развитии BI-систем это уход в сторону упрощения аналитики и предоставления быстрого и полного взгляда на проблему для любого заинтересованного человека (включая тех, кто может не разбираться в аналитике).

Бизнес-аналитика становится проще и доступнее, и развитие технологий только способствует этому.

Всем привет! Меня зовут Юра, яBA Tech Lead вNIX, аэто первый выпуск дайджеста для бизнес-аналитиков. Внем вынайдете, намой взгляд, ценные идостойные внимания материалы за прошлый месяц. Enjoy!

В скобках возле заголовков уровень сложности статьи (Normal * Hard Expert ***) и примерное время на изучение материала.

Business Analysis

Sorting Through the Pile: Classifying Customer Requirements (*, 6 мин). Классификация требований от дедушки Вигерса для самых маленьких. Новичкам в помощь, старичкам в радость.

Tactfully rejecting feature requests (**, 9 мин). Каждый из нас попадал в ситуацию, когда приходит очередной важный запрос на фичу, а она не ложится в продукт не помогает реализации бизнес-идеи, ломает архитектуру, не приносит пользы целевой аудитории и так далее. А отказать тому же клиенту неудобно, он же клиент. Так вот, в статье есть рекомендации о том, как просящему понять, почему фича не нужна, через несколько несложных шагов и техник.

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

The 10 Attitudes of Outstanding Product Owners (**, 7 мин). Кто еще не сталкивался узнать, а кто знает вспомнить о том, что лежит в основе этой роли. К аналитикам эти принципы относятся в равной степени.

Top 7 Hybrid Business Analysis roles (*, 10 мин). Разбор наиболее частых вариантов совмещения профессий БА+. По полочкам разложено, какие варианты более удачны, а какие скорее нет.

Writing Kick-Ass User Stories (*, 7 мин). Очень короткий, но емкий гайд, расписанный на примере, который поможет быстро погрузиться в процесс написания User Stories.

The Business Value of Better Requirements (*, 6 мин). Свежий материал от дедушки Вигерса на тему почему хорошие требования очень экономят бюджет.

No One Expects the Requirements Inquisition: Asking Next-Level Questions (*, 6 мин). И еще материал от Карла (!). На этот раз о том, какие вопросы помогут углубиться в реальные needs.

Почему важно наглядно доносить информацию. Визуализация данных для бизнес-аналитика (**, 10 мин). Кирилл Белявский из SoftServe рассказывает об актуальности техник визуализации, важности для бизнеса, восприятии визуализации, а также популярных инструментах.

Build effective Minimum Viable Products with the MVP Experiment Canvas (**, 13 мин). Бесплатный фреймворк для структурирования и запуска MVP и валидации бизнес-идеи.

Расширяем кругозор

Как не надо релизить проекты. Работаем с требованиями, оценкой и оплатой (**, 15 мин). Страшные сказки на ночь о нерадивых клиентах, срывах сроков, размытых требованиях, форс-мажорных ситуациях и других бабайках, которыми только и делать, что пугать Junior'ов. Если же серьезно, то в статье много жизненных ситуаций, на которых можно поучиться не совершать чужие ошибки и предвидеть свои.

Lightning Cast: Resistance to Change (*, 4 мин). Выжимка теории по Goldratts Four Quadrants on Change почему сопротивляются изменениям и что с этим делать.

Your Product Has Too Many Features (*, 6 мин). Взгляд на возможные причины захламления фичами на примерах Facebook / Amazon, а также - что с этим делать.

Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness (*, 14 мин). Как можно догадаться из названия статьи, автор далеко не фанат SAFe, у которого пригорело. Мне довелось лишь слышать о SAFe, изучать теорию, но использовать ни разу. Тем не менее мне все казалось, что два дня планирования это перебор, ограничивающий команды, хоть мне и были озвучены весомые аргументы за. Автор статьи приводит много аргументов против, в том числе ссылки на Кена Швабера и других лиц, которые высказывали свои опасения на счет SAFe.

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

Готумо до запуску продукт. Чек-лист для Product Manager (**, 10 мин). Мария делится опытом и дает нам рабочий инструмент, которым стоит воспользоваться.

A comprehensive list of UX design methods & deliverables (*, 12 мин). Подборка техник по сабжу краткий обзор + ссылки на почитать. Пожалуй, наиболее лаконичный и полный обзор из тех, что встречал.

How to Spot and Prevent Useless Meetings (*, 4 мин). Признаки, с помощью которых вы быстро определите, откуда стоит слинять, либо, если не получится, хотя бы взять ноутбук, чтобы поработать.

IT-словарик для не-айтишников (*, 4 мин). Словарь терминов, которые стоит знать каждому :)

UI cheat sheet: Icon categories + icon style reference guide (**, 21 мин). Очередной шикарный гайд от Тессы Гадд, на этот раз о том, как правильно делать иконки.

Привет! Мое имя Юра Гомон, яBATech Lead вNIX ивот уже 8лет занимаюсь бизнес-анализом, помогая реализовывать веб- имобильные решения для бизнеса, атакже автоматизировать бизнес-процессы. Мое имя кажется Вам знакомым, т.к. недавно я опубликовал на Хабре свой BADigest.

Цель статьи напомнить бизнес-аналитикам ометоде Root Cause Analysis (далее RCA) иподелиться опытом его применения для предотвращения багов.

В сети очень много информации по RCA, потому не хочу повторяться в отношении теории. Если Вы еще не использовали Problem-solving техники и, в частности, RCA, рекомендую ознакомиться с материалами по ссылками ниже, а уже затем переходить к статье:

• ABrief History ofRoot Cause Analysis. Истоки появления техники, описание шагов, смежные подходы.

• How toConduct aRoot Cause Analysis. Разбор техники напримере.

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

Кейс первый ополитиках

Вливной enterprise-системе на200+ пользователей все было хорошо: жили нетужили, работали три года после релиза. Новодин прекрасный день при попытке перейти поссылке всистему вместо желаемого результата пользователей ждало угрожающее сообщение

Аналог сообщения, которое увидели пользователи. Оригинал несохранился :) Источник:Bytebitebit

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

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

Почему пользователи видят эту страницу?
Посмотрим А-а, так это заэкспайрился SSL-сертификат, продлим, ивсе будет впорядке.
Апочему это несделали заранее?
Никто непоставил напоминание, атри года быстро пролетели.
Резонно. Как думаете, почему непоставили?
Хм, по-моему, это первый проект, где была потребность виспользовании SSL. Это уже после вас стали сертификаты покупать идругим.
Так это ивдругих системах может случиться?
Пожалуй, пойдем везде проверим, поставим напоминалки ивгайдлайны внутренних систем добавим, что надо незабывать это делать.

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

Что изэтого стоит вынести? Ответственные, те, кто знаком сметодами RCA иFive Whys, нетолько исправили ошибку, ноначали задавать вопросы, чтобы найти истинную причину. Как только это случилось, проблему превентивно закрыли везде, где она могла произойти, тоесть предотвратили баг безопасности вдругих системах. Косвенно это привело ктому, что вкомпании стали уделять еще больше внимания безопасности.

Кейс второй олюдях

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

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

1. Менеджер задокументировал ключевые поинты разговора счеловеком названные импричины.

2. Предположил варианты сосвоего опыта.

3. Собрал доказательства существованию причин, проанализировал.

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

Граф причин проблемы, воссозданный сослов рассказчика

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

1. Сначала человек стал засиживаться вофисе после работы почти каждый день.

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

3. Следом вместо домашней еды онстал питаться подножным кормом.

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

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

Кейс третий оработе стребованиями

Когда БАвходит впроект, который идет уже некоторое время, первая задача разобраться стребованиями, тоесть провести аудит. Обэтом кейсе яделалдоклад наNIX Multiconfв2019году. Сегодня раскрою некоторые детали того случая сточки зрения применения RCA: как искали причины того, почему впроекте начало появляться много багов.

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

Коммуникация

Невозможно было найти ответ или решение через время. Обсуждение требований велось вAsana, Slack, JIRA, через почту, вонлайн- иофлайн-документах. Среди всех источников небыло единого:

• клиент писал там, где ему было удобно втекущий момент;

• остальные команды неподдержали нашу критику, поскольку имитак норм;

• бюджет наведение SRS, митинг-минуток иструктурирование информации невыделялся.

Наша команда неполучала ответов вовремя. Другие команды непонимали наших вопросов:

• трудности перевода;

• если непинговать, томогли забы(и)вать нам ответить;

• пинговать из-за большой разницы сдвумя другими таймзонами было затруднительно.

Стейкхолдеры

Наша команда получала разную информацию изразных источников.

Небыло обмена решениями сдругими командами:

• небыло четких зон ответственности вплане шаринга информации;

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

Клиент часто менял требования/ принимал решения. Настолько часто, что одна команда успевала получить одно, авторая уже другое:

• уклиента небыло четкой бизнес-идеи, онстарался быстро адаптироваться под нужды целевой аудитории;

• клиент хотел реализовать как можно больше фич, невзирая наобщий концепт приложения, атакже удовлетворить всех пользователей;

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

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

Недожидаясь правок понескольким десяткам других пунктов, ЛПРы состороны команды реорганизовали перечень каналов связи иоставили всего три: обсуждение идей велось вAsana, дизайна итребований всоответствующих каналах Slack, тамже создали канал для общих вопросов. Кроме того, все решения покаждой функции стали фиксировать вJIRA, куда перевели только тетаски, которые должны были идти вразработку. Вдополнение ввели жесткие правила понеизменности скоупа врамках спринта (либо полной приостановке ипланированию спринта снуля) идлительности спринта.

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

Ичто?

Есть вещи, которые вот уже 8лет, смомента как явошел вIT, янеперестаю евангелизировать, поскольку нахожу имприменение либо вижу отражение вокружающем мире. Среди них философияпиши-сокращай, модель Кано, принцип Парето, think out ofthe box итак далее. Как выуже догадались, RCA входит вэтот перечень. Авсе потому, что важнейшая, если непервичная задачаБА заключается втом, чтобы понять почему. Будь топроблемная функция всистеме, ошибки вбизнес-процессах, нюансы человеческого поведения, негативные события вокруг все имеет глубокие корни.

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

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

Всем привет! Встречайте дайджест ссамыми сочными статьями зафевраль.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard Expert ***) ипримерное время наизучение материала

Business Analysis

6Trends Impacting Business Analysis toWatch in2021(*, 5мин). Тренды глазами Delvin Fletcher, President and Chief Executive Officer ofthe IIBA.

Круглый стол Эффективные техники для выявления требований(*, 30мин). Запись доклада Дениса Гобова дляanalyst.by, где были раскрыты такие темы, как Фреймворк процесса выявления требований, Модель Кано иеесвязь стехниками выявления, Классификация техник иКакие техники действительно используют бизнес-аналитики (результаты опросаБА вУкраине).

Уточняем детали проекта методами практической психологии(*, 6мин). Как информация (требования) искажаются при передаче между людьми ичто сэтим делать.

System Analysis Meetup 18/02 отRaiffeisenbank(**, 186мин). Обсуждали, как аналитик может влиять напроцессы вAgile-команде, как использование Agile снижает риски проекта (нонеисключает всех) икак изменилась роль аналитика после цифровой трансформации.

Аудит технчно документац: кому, навщо, як(*, 7мин). Ирина делится снами опытом проведения аудита ивнедрения его результатов.

Чек-лист тестирования требований(*, 11мин). Встатье разобраны основные критерии качества хороших требований напримерах изреальной жизни

Как мыиспользуем Confluence для разработки требований кпродукту(*, 8мин). Шикарная статья, вкоторой рассказывается оприменяемых подходах иплагинах. Очень рекомендую кпрочтению! Апредставленные плагины самый сок, без них жить очень непросто :)

AChecklist For Business Analysis Planning(*, 6мин). Опытный аналитик-ментор делится своим чек-листом для планирования бизнес-анализа.

Расширяем кругозор

Cheatsheet Differences Scrum vsScrumban vsKanban(*, 4мин). Освежаем впамяти основные различия между одними изсамых популярных методологий.

UI-элементы ижесты вмобильных приложениях(*, 3мин). Обзор сабжа сбольшим количеством примеров.

Never Forget aPassword Again(*, 12мин). Эссе, вкотором сделан обзор важности создания сильных паролей каккаунтам, оспособах взлома иметодах защиты.

Personas: AWaste OfMoney And Time(*, 7мин). Критика техники персон, что применять вместо нее икакие риски могут из-за этого выстрелить.

Three drawingsI use toexplain agile(*, 5мин). Отличная статья за2018-й,которая поможет быстро понять суть Agile, апотом показать его ценность клиенту.

How todiscover your customers willingness topay(**, 10мин). Если высделали классный продукт, показали его фокус-группе, которой онпонравился это еще незначит, что вызаработаете много денег. Это значит, что высделали что-то хорошее. Авот будутли заэто платить... Встатье рассматриваются подходы, которые должны помочь выудить изпотенциальных клиентов информацию отом, насколько ваш продукт для них ценен иготовыли они (исколько) платить.

UI-элементы ижесты вмобильных приложениях What does afterUX even mean?(*, 5мин). Абсолютно шикарная статья, которая показывает, как может быть вреден необдуманный UX-design, если слепо повторять паттерны.

The Homer Principle(*, 6мин). Юмористическая ижизненная статья отом, счем придется столкнуться при разработке продукта вконтексте восприятия продукта конечными пользователями. Напримере Гомера Симпсона автор вывел 6принципов, скоторым нужно будет работать.

Почему, чтобы переместить кнопку, нужно две недели(*, 5мин). Навесьма простом примере показано, как впростые запросы вреальности оказываются весьма нетривиальными. Можно взять пример заоснову ипользоваться вследующий раз (применяя квашему случаю), когда клиент удивляется, почему так долго.

Product Owner vs. Business Analyst Demystifying the similarities and the differences(*, 11мин). Годнота изблога Adaptive US одного изпровайдеров обучения для сдачи экзаменов IIBA.

Нюансы общения ванглоязычной среде. Часть первая.(*, 5мин). Прокачиваем софт скилы вместе сбизнес-аналитиком, живущей вВеликобритании изнающей подноготную коммуникации сносителями языка.

Building User Trust InUXDesign(***, 19мин). Статья отом, как провести пользователя отэтапа яовас инеслышал, кто вытакие дообоже, яхочу пользоваться вашим продуктом всю жизнь! спомощью понимания пользователя инекоторых маркетинговых уловок.

Material Design Text Fields Are Badly Designed(*, 6мин). Пост критики (обоснованной, намой взгляд) material design.

State OfGDPR In2021: Key Updates And What They Mean(**, 20мин). Изменения вGDPR икак теперь сэтим жить.

Всем привет! Встречайте свежий дайджест ссамыми сочными статьями заапрель.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard ** Expert ***) ипримерное время наизучение материала.

Business Analysis

Тестирование требований: как янахожу ошибки вбизнес-логике фичи прежде, чем ихзакодят(*, 16мин). Авторка делится опытом тестирования требований через применение Use Case Scenarios.

Product Discovery IsAMindset, Not AProcess(**, 8мин). Автор поясняет, почему непрерывная Discovery-фаза (которая незаканчивается состартом проекта) залог успеха.

Requirements for Implementing Packaged Solutions(**, 6мин). Дедушка Вигерс продолжает нас радовать! Вэтот раз онподелился подходом копределению требований при выборе коробочных решений.

Локализация (адаптация) продукта для работы вновых регионах(*, 6мин). Авторка делится своим опытом поразработке требований клокализации решений напримерах продуктов E-commerce.

Нюансы общения ванглоязычной среде. Часть вторая: small talk(*, 6мин). Продолжение статьи, окоторой упоминалвпрошлом дайджесте. Впродолжении тематики культуры беседы, вовторой части авторка рассказывает обопыте применения small talk.

Что такое бизнес-анализ. Разрушаем мифы оработе BA(*, 11мин). Интересная подборка иразнос самых популярных заблуждений ороли ВА.

Новое как старое. Как провести успешный User Acceptance Testing для Reverse Engineering проекта(**, 12мин). Авторка делится вызовами иопытом работы впроектах пореализации NFR (Functionality) при переносе старой функциональности вновый продукт.

Масштабный проект повнедрению SAP S/4HANA вудаленном режиме: уроки, которые мыусвоили(***, 10мин). Внедрение продуктов, тем более таких крупных как SAP, работа спользователями дело крайне сложное. Вам мало? Добавьте кэтому удаленку! Статья отом, скакими проблемами столкнулись внедряторы икак ихрешали.

Как выбрать уровень статистической значимости для AB-теста икак интерпретировать результат(**, 12мин). Напримерах автор подробно рассматривает результаты различных A/B тестирований икак ихправильно интерпретировать.

Расширяем кругозор

SCRUM: Понимание иприменение фреймворка,часть 1(**, 15мин)ичасть 2(**, 12мин). Автор предлагает формализованный подход для оценки зрелости команды/ компании при внедрении SCRUM. Как минимум это свежий взгляд наиспользование методологии, как максимум потенциально зрелый подход квнедрению. Нужно тестить :)

The Search Before the Search: Keyword Foraging(*, 5мин). Бывалоли увас так, что прежде чем что-либо загуглить, выгуглили как это называется? Еслида, тостатья познакомит вас стермином keyword foraging, который объясняет это явление.

Bringing product thinking toany team(**, 8мин). Статья отом, как ставить потребности пользователей вцентр внимания. Автор делится опытом применения продуктового мышления для оптимизации работы команды навсех этапах проекта.

Comprehensive anatomy ofall Design Thinking workshops(*, 16мин). Встатье рассмотрены наиболее популярные виды воркшопов для создания хорошего UI/UXс применением дизайн-мышления.

IsYour UIMessy? 7Common Mistakes toAvoid(*, 12мин). Автор подробно рассказывает отом, почему нельзя игнорировать мелкие детали, как избежать грязи впользовательском интерфейсе исделать UXкомфортнее.

10Psychological rulesI used tomake users love atfirst sight(**, 8мин). Автор делится рядом подходов, которые ониспользует для расположения пользователей кпродукту навербально-психологическом уровне.

Аунас нет мышей! Амызаведём... Какая польза отархитектора решений(*, 9мин). Обзор роли архитектора решений изачем эта роль нужна.

Designing toreduce the users mental burden(*, 7мин). Хороший продукт невынуждает пользователей думать отом, как импользоваться. Карл Вигерс приводит примеры когда мелкая недоработка создает лишнюю умственную нагрузку ивызывает дискомфорт.

How ToBake Layers OfAccessibility Testing Into Your Process(**, 15мин). Accessibility-эксперты делятся опытом внедрения accessibility-тестирования впроцесс разработки цифровых продуктов.

Introducing FigJam(*, 4мин). Обзор новой коллаборативной фичи для Figma отразработчика инструмента.

Best practice for date-of-birth form fields(*, 6мин). Разбор наиболее удачных, помнению автора, паттернов реализации поля date ofbirth.

Designing for the autistic community(*, 7мин). Вовремя создания продукта, мыпомним обособенностях портрета пользователя, который заточен под большинство наших юзеров. При этом, нередко мызабываем пользователях сособыми потребностями. Встатье авторка описывает принципы создания интерфейсов сфокусом налюдей срасстройствами аутистического спектра.

Designing for Dyslexia(*, 5мин). Вкопилочку кпредыдущей статье как вразработке интерфейса учесть потребности пользователей, страдающих дислексией.

10Figma Tricks IWish IKnew Earlier(*, 4мин). Подборка хаков Figma окоторыхвы, возможно, неслышали.

The UI& UXtips collection,часть 1(*, 14мин)ичасть 2(*, 9мин). Шикарная подборка из34 + 18советов посабжу.

Этический антидизайн: как разработать продукт, невызывающий привыкания(*, 10мин). Антидизайн средство для защиты отдурака инетолько.

Best Practices For Modal Window Design(*, 9мин). Автор делится 9незамысловатыми принципами для оптимизации проектирования модальных окон.

Ближайшие события, курсы

13мая состоится бесплатный вебинарUI/UXMeetUp. Порядок тем заинтересует всех, отджуна долида. Намитапе выузнаете офундаментальной теории близости винтерфейсах, какие скилы нужны чтобы активно расти дизайнеру, атакже сюрприз вкачестве секретного спикера. Аналитикам будет полезно для расширения кругозора всфере прототипирования.

19мая состоится бесплатная онлайн-лекцияBA&UX: взаимодействие сускорением. Входе лекции выузнаете рекомендации для построения дизайн-процесса, атакже отехниках BA&UX.

29мая состоится платная конференция для бизнес-аналитиков. Вас ждут доклады 6спикеров изУкраины иЛатвии, скоторыми высможете коммуницировать иполезно провести время вкругу коллег.

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

Как главный аналитик в ADV/web-engineering co, я регулярно отвечаю на подобные вопросы коллег и соискателей на собеседованиях. Надеюсь, что эта статья поможет сформировать представление о возможном развитии и ожидания от работы аналитиком в той или иной компании.

Какие бывают аналитики

Если поискать в интернете, то найдётся куча видов таких млекопитающих:

• Аналитик (вот так, просто аналитик)

• Аналитик БД

• Аналитик бизнес-процессов

• Бизнес-аналитик

• Системный аналитик

• UX-аналитик

• Продуктовый аналитик

• Аналитик данных

• BI-аналитик

• Веб-аналитик

• Технический писатель

И это не полный список. Плюс на должности навешиваются грейды, типа старший, ведущий, главный, незаменимый и т.д.

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

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

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

Специалисты широкого спектра

Сюда отношу тех, кто как правило задействован в автоматизациях, например, в интеграторах или в разработке продукта в in house команде. Такие люди чаще решают следующие задачи:

• Сбор требований с руководителя продукта

• Формирование предложений по развитию продукта

• Проектирование бизнес-процессов

• Постановка задач дизайнерам

• Подготовка спецификаций для разработчиков

• Сопровождение разработки и тестирования

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

• Взаимодействие со специалистами узкого спектра, о них позже

• Участие в presale и предпроектных активностях

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

• Чистый бизнес-аналитик ничего не шарит в том, что и как может быть сделано, поэтому не может управлять ожиданиями заказчика при сборе бизнес-требований

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

Что пригодится такому аналитику

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

Если общие знания аналитика есть 100%, то с некоторой погрешностью для задач автоматизации будет нужен:

• Бизнес-анализ 30%

• Системный анализ 35%

• Продуктовый анализ 15%

• UX-аналитика и дизайн 10%

• Менеджмент 5%

• Прочее последние 5%

Если детальнее, то из бизнес-анализа стоит знать:

• Бизнес-процессы --- зачем они нужны, зачем их формализуют

• Нотации моделирования бизнес-процессов, базовые знания BPMN необходимы

• Логику и правила проектирования логической модели данных

• Правила сбора требований и ограничений

• Отдельно отмечу правила сбора требований к пользовательским интерфейсам

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

• Типовые архитектурные паттерны

• Навыки программирования алгоритмы, типы данных, наследование

• Знания БД, понимание концепций нормализации и денормализации, реляционных и нереляционных СУБД

• Представление о нотациях UML, умение работать с базовыми диаграммами (диаграмма последовательности, вариантов использования)

• Понимание концепции декомпозиции задач на конкретные работы, хотя бы банально на back и front

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

• Понимание работы тестирования и умение самому представлять возможные не-happy path варианты работы решения

Для решения задач продуктового анализа потребуется:

• Знание предметной области или живой ум, чтобы быстро разбираться на уровне, достаточном для решения задач

• Базовое понимание метрик и их ценностей для продукта

• Умение расставлять приоритеты между задачами и понимание концепции MVP

Для корректного взаимодействия с дизайнерами необходимы базовые знания UX/UI:

• Сложно формализуемое чувство прекрасного для интерфейса и умение поставить себя на место пользователя

• Понимание компонентного подхода при проектировании интерфейсов

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

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

Про узких специалистов

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

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

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

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

• Любишь работать с данными аналитик БД, BI или в сторону data science

• Интересно продумывать пользовательский путь и управлять им UX-аналитик, UX/UI-дизайнер

• Горишь в том, чтобы принимать решения и развивать продукт продуктовый аналитик, и далее до руководителя продукта

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

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

Итоги

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

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

Всем привет! Встречайте свежий дайджест ссамыми сочными статьями замай.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard ** Expert ***) ипримерное время наизучение материала

Business Analysis

Подкаст. MBA220: Thoughtless Design with Karl Wiegers(**, 32мин). Карл Вигерс продолжает радовать нас своим опытом. Вэтот раз онделится принципами иуроками, которые извлек изнекачественного дизайна, атакже рассказывает, чтоВы можете сделать, чтобы помочь всоздании дизайна.

Нужнали сертификация для бизнес-аналитика?(**, 10мин). Все осертификацииВА: список популярных, какие преимущества каждая даёт инужнали сертификация вообще.

Docs asCode: введение впредмет(**, 21мин). Автор делится многолетним опытом, приобретенным напути кDocs asCode, атакже рекомендациями повнедрению этого фреймворка.

Business Analyst: Tools and Principles for Professional Self-Development(*, 16мин). Структурированный набор материалов, который поможет обнаружить изаполнить пробелы всвоих навыках. Статью готовил аналитик с15+лет опыта, всоавторстве сдругими опытными БА.

Как проводить интервью сзаказчиком(*, 11мин). Кирилл Белявский делится секретом проведения успешных интервью.

User Experience inProduct(*, 8мин). Как исследования ианализ пользователей помогут увеличить значимость вашего продукта для конечных пользователей.

Моделирование данных: обзор(**, 6мин). Встатье автор раскрывает понятие моделирование данных, атакже делится оптимальной пошаговой инструкцией поприменению.

Цикл статей про бизнес-анализ напресейле. Статья первая, или почему всем нужен БА?(*, 5мин). Старт цикла статей ороли изадачах бизнес-аналитика напресейле. Впервой части: что такое пресейл, роль ивлияние бизнес-аналитика наэтом этапе, артефакты, которые могут понадобиться.

Расширяем кругозор

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

SCRUM: Гибкое управление продуктовыми направлениями(*, 9мин). Третья часть изцикла статей, окотором говорил впрошлом дайджесте. Вэтой части предложена система метрик для измерения ианализа процесса гибкого управления продуктовыми направлениями.

Frustrating Design Patterns That Need Fixing: Birthday Picker(*, 16мин). Подробный обзор неудачных шаблонов проектирования поля для выбора даты рождения.

Как работать сбэклогом иприоритизацией фич взрелом продукте(*, 8мин). CTO одной изпродуктовых компаний делится опытом приоритезации фич врамках канбан-процесса.

Three Levels ofPain Points inCustomer Experience(*, 8мин). Что такое болевые точки вклиентском опыте, накаких уровнях взаимодействия возникают ипонять какие наиболее критичны.

Left-Side Vertical Navigation onDesktop: Scalable, Responsive, and Easy toScan(*, 12мин). Статья овесьма непривычном подходе кпостроению навигации, когда она находится невшапке сайта, анаместе левой боковой панели: каким доменам подходит, преимущества ирекомендации поиспользованию.

Все, что выхотели знать про диалоговый UX/UIв проектировании чат-ботов(*, 9мин). Встатье покрыто определение диалогового UX/UI-дизайн, есть пошаговые рекомендации счего начать, атакже годные лайфхаки для проектирования сценариев для чат-бота.

Какие рефералки работают: сбонусами для себя, для того парня или для обоих? Исследование(*, 4мин). Саммари исследования видов рефералок.

The role ofpassword verification atsign up(*, 7мин). Анализ практик реализации поля ввода пароля.

UX-Roadmapping Workshops: Agenda + Activities(**, 16мин). Содержательная статья осоздании дорожных карт UX.

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

UI& UXmicro-tips: Volume five(*, 4мин). Коллекция небольших, нополезных подсказок поUI/UX.

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

На примере одной китайской компании, которую мы успешно продвинули, поделюсь опытом.

Несколько лет назад к нам обратилась китайская компания - производитель компактных видеокамер (action camera, достойные аналоги GoPro, но в разы дешевле) с просьбой обеспечить выход на рынки ЕС.

На тот момент их опыт продаж в ЕС заключался в разовых мелкооптовых поставках B2B через платформу Alibaba или розничных продажах B2C через Aliexpress.

Мы взялись за эту работу и обеспечили за полтора года впечатляющий уровень продаж.

Ниже некоторые полезные выводы:

Страна выхода в ЕС? Эстония

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

Изучение рынка? Необязательно

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

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

Объем рынка видеокамер стал понятен и перспективы их продаж тоже.

Бренд? Очень желательно!

Был зарегистрирован в ЕС новый благозвучный бренд на эстонскую компанию.

Бренд и эстонская юрисдикция компании позволили утверждать что видеокамеры имеют европейское происхождение и лишь собираются в Китае (OEM или ODM).

Европейская сертификация СЕ? Обязательно!

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

Транспорт? Авиа - быстро или морем - дешево

Сначала использовали авиадоставку DHL - быстро (несколько дней) но дорого.

Позже, когда стал понятен прогноз продаж, стали отгружать морем (поддоны, сборный груз в контейнере) - долго (месяц) но дешево.

Таможенное хранение? Очень желательно!

Видеокамеры поступали в Таллинне на таможенный склад и хранились там.

При необходимости, растаможивали требуемый объем товара (и только тогда платили пошлины и НСО) и сразу отправляли в место назначения в ЕС.

Каналы продаж? Маркетплейсы и сети магазинов

Опыт показал, что наиболее эффективным каналом продаж стали европейские маркетплейсы с обеспечением доставки (fulfillment services) конечному потребителю (Amazon UK, DE, FR, ES, IT, но не только Amazon).

Далее идет поставка на реализацию в сети магазинов.

Свой сайт оказался менее эффективным чем ожидалось.

Локализация? Есть нюансы

Если Северная Европа (и Германия) английский воспринимают хорошо, то Франция (как и Испания и Италия) предпочитают использовать свои языки. Надо учесть это при локализации продукта через маркетплейсы или онлайн сервисы.

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

Сервис-центр? Обязательно!

Статистика показала, что 5-10% онлайн продаж были возвращены только потому что Покупатель передумал (ну или попользовал, например, на лыжных каникулах или дайвинге, и больше не надо). Законы ЕС это не запрещают.

Как правило, эти видеокамеры были в рабочем состоянии и требовали переупаковки (или незначительного ремонта типа замены корпуса). Поэтому необходим ЕС-почтовый адрес для приема товара и минимальные площади для переупаковки и с последующей отправкой новому Покупателю.

Неожиданные проблемы? It happens

Например, после аварии самолета из-за возгорания аккумулятора в каком-то электронном изделии, грузовые авиакомпании усложнили требования к перевозке товаров, содержащих аккумуляторные батареи. Были проблемы с приемом к перевозке и у нас.

Что еще оказалось важным? Регистрация плательщика НСО в каждой стране ЕС!

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

Процедура сложная, в каждой стране разная, но это надо делать.

Зато факт наличия номера плательщика НСО повышает уровень продаж В2В в этой стране, так как Покупатель зачитывает НСО при покупке.

Есть что ещё сказать? Да

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

Если статья окажется интересной читателям - напишу продолжение.

Всем успехов и удачи с выходом на внешние рынки!