Кто такой бизнес-аналитик и как им стать

Кто такой бизнес-аналитик и как им стать Аналитика

Что нужно уметь бизнес-аналитику

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

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

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

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

  • Теоретическую базу разработки ПО (вариации методологий — от Waterfall до Agile), для лучшей интеграции активностей анализа.
  • Навыки системного анализа для холистического подхода к анализу систем над которыми бизнес-аналитик работает.
  • Знания в области процессов разработки требований (поиск, документирование, верификация, поддержка изменений).
  • Программная архитектура для четкого понимания того, как устроены IT системы.

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

  • BABOK — самый известный стандарт роли бизнес-аналитика. Объемный, детальный и довольно абстрактный список задач и техник. Но знать про него и понимать основы основ должен любой уважающий себя бизнес-аналитик.
  • PMBOK — стандарт проектного управления, содержащий руководство правильной организации требований.
  • IREB — более предметный каркас процесса разработки требования с фокусом на разработку программного обеспечения.

Что должен знать/уметь аналитик и как этому научиться?

Читавшие упомянутую выше книгу «Путь аналитика. Практическое руководство IT-специалиста», особенно те коллеги, которые только начинают свою карьеру в ИТ, наверняка

прифигели

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

На мой скромный взгляд, там все-таки описан некий сферический аналитик в вакууме идеал, к которому можно (но не факт, что нужно) стремиться. Фанатичное стремление овладеть сразу всеми знаниями и навыками приведет, разве что, в Кащенко. Готов поспорить на бутылку Talisker 16 y.o., (с кем-нибудь одним, а то же, неровен час, найдутся Шелдоны (смайл)), что в природе нет ни одного человека, полностью соответствующего продвигаемому в книге образу (со всем описанным набором знаний и навыков), включая самого автора книги.

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

  • о жизненном цикле ПО;
  • о нескольких ключевых методологиях разработки (waterfall, RUP, что-то из Agile, лучше бы Scrum, для гос. заказчиков – ГОСТ 19 (на программы) и 34 (на автоматизированные системы));
  • об основах системного анализа (Вигерс отлично подойдет);
  • о нотациях и инструментах проектирования и моделирования (самые востребованные на рынке, пожалуй: Sparx Enterprise Architect и Rational Rose; и UML/Aris/IDEF0 и IDEF3);
  • о теории реляционных БД;
  • и т.д.

О необходимости владеть в совершенстве Word-ом или его аналогом даже не пишу (смайл). А вот о необходимости владеть хотя бы одним инструментом для проектирования макетов интерфейсов, стоит упомянуть. Выделенные интерфейс-дизайнеры – редкость, так что эта работа часто «падает» на аналитиков. Здесь кроме очевидного Visio могу посоветовать простой и удобный Evolus Pencil.


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

. «Power BI и Excel для продвинутых: DAX и Power Query»

Начать обучение

Кто проводит курс: онлайн-университет «Нетология».

Сколько длится: 2 месяца.

Что ты узнаешь и чему научишься из курса:

  • Обрабатывать данные. Работать с большими массивами данных из разных источников, не хуже программистов строить сложные запросы с множеством параметров
  • Писать сложные формулы в DAX. Создавать вычисляемые таблицы, столбцы и меры: от простых агрегатов до формул со скользящими периодами
  • Автоматизировать отчётность. Сможешь создавать легко читаемые отчёты с богатой навигацией, которые ускорят поиск ответов на вопросы бизнеса

Твои навыки после прохождения курса:

  • Знание продвинутых приёмов работы с Power Query и M
  • Составление расширенных интерактивных отчётов
  • Работа с архитектурой табличной модели
  • Выполнение сложных выражений DAX в Power BI, Power Pivot
  • Работа с текущим контекстом фильтра с помощью выражений DAX
  • Изменение отображения итогов и промежуточных итогов
  • Работа с иерархиями и связанными функциями
  • Вычисление различных скользящих средних без использования функции Time Intelligence
  • Работа с расширенными вычислениями с использованием итераторов
  • Понимание работы Bidirectional фильтров
  • What-if анализ. Глубокое погружение в CALCULATE()
  • Динамическая безопасность на уровне строк

Стоимость:

27 900 19 530 рублей (2 325 рублей в месяц).

Отзывы:

Нюансы и особенности:

  • По окончании курса ты получишь удостоверение о повышении квалификации установленного образца
  • Можно оплачивать курс в рассрочку с помощью беспроцентного кредита от «Тинькофф» или «Сбербанк»

. «Excel Google-таблицы с 0 до PRO»

Начать обучение

Кто проводит курс: онлайн-университет SkillBox.

Сколько длится: 4 месяца.

Что ты узнаешь и чему научишься из курса:

Google Таблицы базовый

Основы, интерфейс Таблиц
Совместная работа с документами. Сортировка. Фильтры и фильтрация
Сводные таблицы: основы
Визуализация данных: основы
Проверка данных
Правила работы с формулами
Типы диапазонов, связывание листов и документов между собой Функция IMPORTRANGE
Функции суммирования и подсчета
Логические функции
Текстовые функции
Функции для работы с датой и временем
Работа с диапазонами: основные функции (ВПР, ИНДЕКС, ПОИСКПОЗ, SORT, FILTER)
FILTER: введение
QUERY: введение (синтаксис, SELECT, WHERE, ORDER BY, GROUP BY, PIVOT)
Скрипты: введение

Дополнительный анализ:  "Украина лишится транзита ещё до 2024 года": Эксперт представил наихудший для Киева сценарий

Твои навыки после прохождения курса:

  • Создание сводных диаграмм, спарклайнов, группировка и настройка вычислений
  • Работа с функциями проверки данных
  • Прогнозирование ситуаций и различных показателей
  • Импорт и экспорт данных, работа с OLAP-кубами
  • Работа с диапазонами
  • Создание макросов для VBA
  • Умение быстро фильтровать большие массивы данных

Стоимость:

30 000 18 000 рублей (1 500 рублей в месяц по рассрочке).

Отзывы:

Нюансы и особенности:

  • Первым 20 участникам курса — скидка 40%
  • Доступ к курсам — навсегда
  • Бесплатная консультация для желающих приобрести курс
  • По окончании курса ты получишь диплом
  • Гарантия возврата средств — в течение 14 дней

Зачем нужны аналитики? (привет, кэп)

До сих пор от некоторых разработчиков (хотя сейчас уже очень редко) можно услышать, что аналитики (равно как руководители проектов, менеджеры по продукту и т.д.) не только не вносят полезный вклад в дело, но и просто «мешаются под ногами». Лезут, понимаешь, со своими процессами, бумажками и прочей бюрократией — не дают простому девелоперу спокойно работать (смайл).

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

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

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

  • Выслушать заказчика. Иногда уже это бывает непросто – некоторые способны говорить часами буквально ни о чем, и не всегда легко удается перевести общение в конструктив. Тут ключевым является навык активного слушания.
  • Понять иногда «птичий» язык заказчика и сформулировать его требования понятным языком, полно и без противоречий. Т.е. превратить поток сознания клиента в набор формализованных требований.
  • В некоторых случаях, когда заказчик «сам не знает, чего хочет», предложить оптимальное решение или «подвести» к нему самого заказчика;
  • Проанализировать влияния новых требований на существующую архитектуру и функционал. Здесь часто будут полезны консультации архитектора.
  • Задокументировать требования в виде документа или набора документов в требуемом виде. Затем согласовать их и утвердить.
  • Завести талоны в системе такс-трекинга и в дальнейшем отслеживать их нелегкую судьбу. Завести может и архитектор или dev. lead по ТЗ, но чаще это делает аналитик.
  • Осуществлять верхнеуровневый контроль соответствия реализованного функционала требованиям.
  • Управлять изменениями требований.
  • Осуществлять все взаимодействие с заказчиками по вопросам требований.
  • Часто – участвовать в сдаче продукта заказчику.

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

Краткое техническое отступление

Давайте сознательно прервем повествование и остановимся на самих требованиях. Что касается видов, атрибутов, характеристик, подходов к сбору и оформлению требований – пожалуй, большего «бардака» сложно найти. Состав и содержание документов с требованиями существенно различаются (взять, к примеру, наш ГОСТ и RUP, и имхо это не сравнение пушки и рогатки).

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

Не претендуя на истину в последней инстанции или какое-то ноу-хау (примерно то же написано в Википедии), сформулируем два ключевых способа классификации требований.

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

Данные требования обычно описываются в отдельном документе — «Видении проекта» (Vision) или «Бизнес-требованиях», который так же включает определение основных ролей будущих пользователей Системы и перечисление ее основных сценариев использования.

Требования пользователейОни определяют набор пользовательских задач, которые должна решать Система, с описанием сценариев решения данных задач. Требования пользователей обычно представляются в виде перечисления вариантов использования Системы и взаимосвязей между ними (как правило, в виде Use-case диаграммы языка UML).

Сами варианты использования описывается в виде составляющих их последовательностей действий со всеми возможными пред/постусловиями и ветвлениями. Часто описание является текстовым (эта тема хорошо описана в книге Алистера Коберна ” Современные методы описания функциональных требований к системам “).

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

Функциональные требования являются наиболее детализированными. Они описывают, в том числе, входные/выходные данные и их проверки, алгоритмы обработки данных и элементы пользовательского интерфейса (без дизайна).Как правило, данные требования оформляются в виде отдельного документа («Технического задания» и т.д.).

В этом же документе детализируются сценарии использования Системы (Требования пользователей), к которым обычно и привязываются функциональные требования.Пример функционального требования: «По клику на кнопке <Кнопка А> на форме <Форма Б> должно отображаться модальное диалоговое окно, содержащее <Содержание окна>».

По типу:Функциональные требованияОписывают непосредственно функционал, реализуемый Системой (пример приведен выше в описании классификации требований по их уровню в пункте «Функциональные требования»);

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

Дополнительный анализ:  Кто такие аналитики данных | Статьи SEOnews

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

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

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

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

Однако некоторые отступления, такие как включение в «Техническое задание» спроектированных макетов интерфейса (без дизайна/оформления), допустимы, т.к. выполняются теми же людьми, которые разрабатывают само техническое задание.

Порядок сбора самих требований:

  1. Сначала выявляются цели создания Системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у Исполнителя не будет возможности контролировать соответствие разработанной Системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;
  2. Далее определяются роли пользователей Системы (как людей, так и других программных систем). После этого выявляются и описываются сценарии использования Системы каждой из данных ролей. Так формируются Требования пользователей.
  3. Далее разрабатывается полный набор требований к функционалу Системы таким образом, чтобы данный функционал позволял выполнить все сценарии, описанные в Требованиях пользователей. Так же фиксируются ограничения для Системы и параметры среды ее функционирования.

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

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

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

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

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

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

Во втором случае имеются в виду:

  1. заинтересованные лица
  2. эксперты предметной области
  3. лица, участвующим в согласовании и утверждении требований
  4. технические специалисты со стороны заказчика либо других подрядчиков/субподрядчиков.


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

Кто есть кто?

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

Дата-аналитик — это человек, который работает с большим объемом информации. Основная обязанность заключается в том, чтобы извлечь нужные данные и проанализировать их для дальнейших решений. То есть этот специалист решает 3 основные задачи: сбор и анализ данных, а также разработка бизнес-решений на основе полученной информации. (wiki)

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

То есть классический бизнес-анализ — это реинжиниринг процессов. Например, если компания хочет изменить организационную структуру: из 1 департамента сделать 5.

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

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

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

Product owner — связующее звено между заказчиком и командой. Главная его задача — создать и контролировать backlog. (источник)

Product manager — специалист, который работает с продуктом, исследует рынок, анализирует финансовую часть. Фактически этот человек выступает CEO продукта. (wiki)

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

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

Кто такой бизнес-аналитик и как им стать

Кто такой бизнес-аналитик и как помогает компаниям быть на шаг впереди

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

Дополнительный анализ:  Курсы веб-аналитики: ТОП-15 по Google и Яндекс маркетологу

Маркетинговые аналитики работают с BI, оптимизируют маркетинговые кампании, экономику продаж.

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

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

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

Посмотрим, в каких командах задействованы бизнес-аналитики и какова их роль в каждой из них.

Чаще всего бизнес-аналитики работают в консалтинговом подразделении — внутреннем отделе или в консалтинговой компании. Под консалтингом подразумеваем управленческий консалтинг, среди известных представителей которого компании McKinsey, PWC, Deloitte, Ernst&Young.

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

Пример. Перед запуском системы для оплаты проезда «Тройка» в Московском метро консультанты просчитали экономику, затраты, ресурсы, схему работы.

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

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

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

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

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

Это команда, которая создаёт инструменты для сбора данных и далее для управления компанией на основе данных. Например, инструмент для сбора данных Share point для сотрудников или автоматический сбор данных.

BI — решение на собственном движке или внутри сервисов Tableau, Power BI, QlikView. Позволяет создавать автоматические отчёты, которые демонстрируют эффективность работы компании.

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

В таких случаях это смежная с менеджментом специальность.

Пример. В Яндексе операционная команда запускает бизнес в новых городах и странах.

Функция, близкая к отчётности и стратегии. Такие команды создают системы KPI, поддерживают OKR (инструменты планирования), премии, расчёт показателей эффективности, бонусы — количественные показатели, которые крупные компании используют для сохранения конкурентоспособности и развития.

Business Intelligence (BI) — бизнес-аналитика, точнее — анализ бизнес-данных для принятия управленческих решений

Нетология: продуктовая аналитика – перейти на сайт

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

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

Чему вы научитесь:

  • Строить систему метрик для конкретного товара/продукта/услуги;
  • Организации аналитического подхода;
  • Масштабированию аналитики для больших проектов;
  • Визуализации полученных данных;
  • Составлению отчетов для руководства;
  • Работать с базами данных;
  • Построению юнит-экономики продукта.

Преимущества:

  • Подходит для новичков;
  • Демо-доступ на 7 дней;
  • Работа над реальными проектами;
  • Свой центр развития карьеры.

Недостатки:

  • Скидка на обучение действует до 8.12.20;
  • Задержки обратной связи от авторов.

Мой рейтинг – 5,0

  • Цена – 5
  • Программа – 5
  • Преподаватели – 5
  • Ценность сертификата – 5
  • Трудоустройство – 5

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

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

Чему вы научитесь:

  • Оптимизации бизнес-процессов;
  • Анализу и описанию экономики бизнеса;
  • Расчёту экономического эффекта от внедрения стратегических решений;
  • Находить потенциал для развития или оптимизации бизнеса;
  • Структурировать решение текущих задач;
  • Расчету экономического потенциала.

Преимущества:

  • Помощь с трудоустройством;
  • Диплом об окончании обучения;
  • Создание портфолио во время учебы;
  • Обратная связь от преподавателей;
  • Доступна рассрочка платежей.

Недостатки:

  • Скидка на курс только до 8.12.20;
  • Долгие проверки домашних заданий.

Мой рейтинг – 5,0

  • Цена – 5
  • Программа – 5
  • Преподаватели – 5
  • Ценность сертификата – 5
  • Трудоустройство – 5

Рейтинг лучших курсов бизнес-аналитики

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

Название курса

Школа

Цена

Срок обучения

Мой рейтинг

Продуктовая аналитика

Нетология

30250 руб.

4 мес.

5,0

Профессия бизнес-аналитик

Нетология

81000 руб.

4 мес.

5,0

Профессия продуктовый аналитик

Нетология

90000 руб.

7 мес.

5,0

Профессия бизнес-аналитик

SkillBox

44000 руб.

12 мес.

5,0

Аналитика для руководителей и владельцев бизнеса

SkillBox

42930 руб.

3 мес.

5,0

Факультет бизнес-аналитики

GeekBrains

59880 руб.

12 мес.

5,0

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

GeekBrains

49580 руб.

7 мес.

5,0

Аналитика для руководителей

SkillFactory

27200 руб.

5 мес.

5,0

Продуктовая аналитика

SkillFactory

41900 руб.

4 мес.

4,8

Онлайн-курс бизнес-аналитиков

Hedu

12000 руб.

1 мес.

4,8

Профессия бизнес аналитик

Udemy

11490 руб.

1 мес.

4,6

Курс по бизнес-анализу

Академия Сухорукова

12000 руб.

4 мес.

4,4

Профессия Аналитик с 0 до PRO

ProductStar

65000 руб.

12 мес.

4,4

Профессия: Бизнес-аналитик

ProductStar

43800 руб.

6 мес.

4,2

Маркетинговая и клиентская аналитика

Синергия

15000 руб.

3 мес.

4,2

Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector